バイオリンメモリオールフラッシュデータウェアハウスへの完全なCROCクラウド転送

CROCは、2009年後半にロシアで最初のパブリッククラウドプラットフォームを立ち上げました。 年ごとに指数関数的に成長する必要がありました。 このようなダイナミクスを提供するには、クラウドプラットフォームのアーキテクチャを非常に柔軟でスケーラブルにする必要があり、プラットフォーム自体を適切に管理する必要がありました。 ある時点で、クラウドの開発の夜明けに定められたアーキテクチャ上の制限、つまりデータストレージサブシステムに我慢し始めました。



最も重要な成長目標の1つは、ディスク容量だけでなく、使用するディスクの保証されたパフォーマンスの面でも顧客のニーズを満たすことです。 ストレージネイバーの相互の影響を回避し、状況を完全に管理しやすくし、ディスクあたり400 IOPSから100,000 IOPSの範囲のSLA内のディスクのパフォーマンスを保証する必要がありました。



さらに、クラウド内の保証ディスクに関するトピックも、個人データに関する法律によってウォームアップされました。これは2015年9月1日に施行されます。 多くの顧客は、ITサービスを海外に配置しています。多くの場合、プロバイダーのデータセンターにある専用の高性能物理機器に配置しています。 現在、データをロシアの領土に転送する必要がありますが、顧客は高い保証ディスクパフォ​​ーマンスを拒否したり、まったくしたくないので、機器がロシア連邦に届けられるのを待つ方法はありません。 この場合のクラウドは、おそらくロシア連邦へのデータ転送を管理し、以前に使用されたプロバイダーの物理機器と同じ技術的なパフォーマンスパラメーターを取得する唯一の方法です。



CROCクラウドには、500を超える物理サーバーと12のデータストレージが2つのリモートサイト間で分散されています。 クラウドでホストされる仮想サーバーの約70％は、大企業のクライアントや中規模企業の生産的な環境です。 テスト環境と開発環境は約30％に過ぎません。 Oracle、SAP、およびお客様のさまざまな負荷の高いOLAPシステムのかなり重いインストールを多数ホストしています。



クラシックディスクアレイには、歴史的に開発されたアーキテクチャ機能があります。これは、パブリッククラウドプラットフォームの一部として中央リポジトリとして使用すると、マイナス面で最も明確に現れます。 ディスクシェルフと1組のコントローラーを備えた従来のディスクアレイに基づいて、私たちは最近まで起動しました。 このタイプのストレージ施設では、サービス提供の品質を管理するためのわかりやすいメカニズムは事実上ありませんでした。 通常、クラシックディスクストレージシステムでは、特定の仮想ディスクのパフォーマンスにのみ優先順位を付けることができます。 各アレイ上のそのようなディスクの数が数百および数千に達すると、優先順位の設定を忘れることがあります。 ストレージシステムでのこのようなパフォーマンス管理メカニズムは機能しなかっただけでなく、パフォーマンスと管理性の欠如により、すでに困難な状況を単純に悪化させました。



2番目の重大なアーキテクチャ上の問題は、ディスクアレイの容量とパフォーマンスのパラメータの緊密な結合でした。 簡単に言えば、回転速度15kの150 GBの物理ディスクが8つあります。 それらからRAID10を構築したいと思います。 論理ドライブの有効容量は600 GBのレベルになります。 それ自体では、各ドライブは個別に最大150 IOPSを発行します。つまり、論理ドライブは約1000 IOPSを発行します。 結果として、有効なディスク容量のTBごとに、約1500 IOPSのパフォーマンスがあるという状況になります。



次に、顧客の最も一般的なタスクを見てみましょう。クラウドに2 TBのベースを配置し、10,000〜50,000 IOPSのパフォーマンスを得たいと考えています。 このようなパフォーマンスを得るには、実際に必要な（10〜50 TB）よりもはるかに多くのディスク容量を使用する必要があることがわかります。 アレイ上にキャッシュを備えたコントローラーペアがあり、ソリッドステートドライブなどを備えたシェルフを追加できることに異議を唱えることができます。ランダム読み取り/書き込みのコントローラーキャッシュは状況を大きく改善しません。 ソリッドステートドライブはパフォーマンスの状況を部分的にしか保存せず、管理性の問題の解決策は将来にのみプッシュされます。 さらに、クラシックコントローラーでは、ソリッドステートドライブの完全なパフォーマンスを明らかにすることはできません。



CROCクラウドでのディスクパフォ​​ーマンスの状況は重要になりつつあり、顧客はディスクサブシステムのパフォーマンスの予測不可能な低下について不平を言い始めました。 クラウドのさらなる開発について決定する必要がありました。 ハイエンドアレイへの移行など、さまざまなソリューションを検討しました。 しかし、これは問題の解決策ではなく、同じような状況になるまで数年間生きることができる高価な「松葉杖」であることに気付きました。 そのような決定の「管理不能性」について、私はすでに上に書いた。 また、Hi-Endアレイは非常に頻繁にディスクムーンを作成および削除することを目的としていません。これらの操作には多くの時間がかかり、リクエストの長いキューになります。これはクラウドでの作業には適しません。 一般的に、タスクはほとんど血を流さずに行われ、クラウドにデータを保存するという点でローカル革命を行うために、最初からやり直すことを余儀なくされました。



きれいなシートから-そうきれいなシートから。 私たちは、顧客のニーズに基づいて構築することにしました。 顧客は何を望んでいますか？

1. アレイの隣同士が相互に影響を与える可能性のないパフォーマンスが保証されたドライブ。 保証はSLAまたは契約に記録する必要があります。
2. 異なるディスクを使用するための関税の変更に伴う透過的なビルドアップとディスクリソースパフォーマンスの低下。
3. クラウドで高負荷のデータベースをホストする機能（ディスクあたり20,000〜100,000 IOPS）。
4. ロシア連邦の領土における能力の提供（遅延および政治的要因）。 2015年9月1日までのロシア連邦における個人データの転送に関する法律は、奨励するのみでした。
5. データストレージの高可用性。

オールフラッシュアレイの使用に長い間注目してきました。 このクラスのソリューションに基づいて、データストレージを使用したクラウドタスクが最も美しく解決され、最も興味深いものが財政的に正当化されたことがたまたまありました。 市場で入手可能なほぼすべての企業レベルのソリューションをテストし、最も著名な新興企業とも協力しました。 ソリューションを選択する際の主な基準は次のとおりです。

• オールフラッシュ-高いパフォーマンスとIOPSの数に対するディスク容量の依存性の欠如。
• IOPSが非常に多いため、第一にすべての人に十分であり、第二に、いつでも割り当てを保証できます。
• アレイには、既存のSANに接続するためのInfinibandアダプターが必要です。 実際、クラウドプラットフォームの顧客の仮想ネットワークのSANネットワークおよびトランスポートとして、56GB Infinibandを使用しています。 同じテクノロジーを使用してアレイを接続すると、SANの均一性が維持され、プラットフォーム全体の管理が簡素化されます。 FC SANの場合のように、セットアップと操作が難しい工場を建設する必要はありません。Infinibandを使用すると、これらの問題はすべて自動的に解決されるためです。
• APIによる文書化された直感的なアレイ管理ツール。 この要件は、制御性の問題に取り組むのに役立ちます。

その結果、Violin Memory 6264アレイで停止し、要件を完全に満たしました。 その結果、合計8つの取得されたアレイは、総容量8,000,000 IOPSで、0.56 PBの原油/ 0.32 PBの有用なフラッシュ容量を受け取りました。



パフォーマンス保証は、各ディスクのハイパーバイザーレベルで個別に制限を設定することにより実装されます。 アレイ管理ソフトウェアは、それらのそれぞれの現在の廃棄を自動的に検出し、新しいディスクを配置するために最も占有されていないアレイを選択します。 配列は非常にコンパクトです。 考えてみてください：わずか3ユニットで1,000,000 IOPS！



Violin Memoryが2007年にオールフラッシュ市場を作成し、製品の改善で最も先進的であることを考えると、これは安全な選択でした。 同社は、NAND-Flashの発明者である東芝と協力してシス​​テムをゼロから開発し、フラッシュを操作するための主要な特許を保持しています。 アレイ内のディスクシステムから継承されたSASループ、バッテリー、またはその他のアーキズムはありません。SSDの形で妥協する必要はありません。 代わりに、PCIメディア上のFFAの最新アーキテクチャで、1.1 TBのネイティブメディアVIMM容量を使用します。 出力は、250μs、7桁のIOPS、3ユニットで数十TBの公称応答時間です。 製造業者によると、バイオリンメモリをキャッチすることは不可能です。既存の製品を処理する必要はありませんが、ドキュメント化されていないNAND-Flash機能へのアクセスとゼロからの長年の開発が必要です。



率直に言って、移行中、すべてがスムーズに進むわけではなく、クラウドとアレイの統合の問題に直面していました。 彼らの本質は、能力の約10％でアレイの可能性を実現できるということでした。つまり、アレイごとに作成されるディスクの最大数に達しました。 CROCクラウドでは、ストレージネットワークと仮想マシン間の通信の両方にInfinibandを使用します。 Violin Memoryアレイは、SRP（SCSI over RDMA）プロトコルを使用して、Infiniband経由でLUNをサーバーに接続します。 このプロトコルには、次の機能があります。制御コマンドは、Infinibandネットワークのサブネットマネージャーを使用します。 通常の状況では、LUNとサーバーの数、およびそれらの間の接続がそれほど多くない場合、これは問題ではありません。 しかし、クラウドの場合はそうではありません。 多くの接続、つまりサーバーとLUN間のパスがあるため、Inifinibandネットワークのサブネットマネージャーは、ネットワークトポロジを再構築するときに有効になりました。 プロセッサの能力が十分ではありませんでした。 多数のパスもストレージアクセスコントローラーに問題を引き起こしました。非常にゆっくりと動作し始め、パスが落ちたと信じていたドライバーにエラーを引き起こしました。



どのようにして問題を解決しましたか？ ベンダーと協力して、パスの数を最適化するために多くの作業を行いました：各個別のLUNを個別の物理サーバーに接続、つまりエクスポートし始めました。 難しかったのは、ReST API配列を使用して行う必要があることでしたが、これも簡単ではありませんでした。 LUNがすべてのホストおよび別の特定のホストにエクスポートされる場合、この特定のLUNからもエクスポートされます。 最終的にすべてのホストへのエクスポートを取り除くために、これにはすべてのLUNのライブマイグレーションが必要です。 サーバーがオン/オフされるたびに、アレイAPIに対して新しいリクエストが行われたため、このAPIのパフォーマンス要件が増加しました。 ここでは、ベンダーなしではできませんでした。 機器の新しいファームウェアバージョンのリリースを開始する必要がありました。



3か月以上にわたり、3人のプログラマと3人のDEVOPSがこの問題の解決に関与しました。 プログラムコード用に膨大な数のテスト（単体テスト）を作成し、自動化されたアセンブリとテストのシステムを最適化しました。 このタスクは、チームの他のメンバーによって処理されました。 その結果、数千行のテスト済みプログラムコードを追加しました。 パスの数を最適化することは簡単な作業のように思えるかもしれませんが、実際には単純なことは何もありません。それを完了するには10か月以上の時間を要しました。





VIMM（バイオリンインテリジェントメモリモジュール）-フラッシュメディア、オールフラッシュシステムの主要コンポーネント



したがって、アレイで作成できる利用可能なディスクパフォ​​ーマンスの範囲は、ディスクあたり最大100,000 IOPSです。 さらに、パブリッククラウドプラットフォームの市場で一般的なように、このパフォーマンスはフローティングではなく保証されています。

お客様には、それぞれ400、1000、3000、5000、10000 IOPSのパフォーマンスのデフォルトドライブを提供します。 セルフサービスポータルを使用するお客様は、さまざまな容量のディスクを実行したり、IOPSの数のパラメーターをその場で変更したりできます。 また、テクニカルサポートサービスへの要求に応じて、10,000 IOPS〜100,000 IOPSの容量のディスクがセルフサービスポータルに追加されます。 原則として、これらは個々のストレージレベルであり、そのパラメータは負荷テストの結果に基づいて各顧客に対して個別に決定されます。 私たちはそれらを隠しませんが、本当に誰もがそのような高性能のストレージレベルを必要とするわけではありません。 申し訳ありませんが、クラウドの容量1 TBあたりのIOPSの平均数は25,000であり、これは本当に素晴らしい指標です。



アレイは、モスクワの領土にある分散データセンターの2つのCROCクラウドプラットフォーム間で分散されます。1つには5つのストレージがあり、もう1つには3つのストレージがあります。 さらに、両方のサイトのアレイの管理は、単一のセルフサービスポータルを介して実行されます。



多くの人が気づくかもしれません：「しかし、他の通信プロバイダーは、彼らがまた保証されたチャネルを持っていると言います、そして、それがSLAにどうなるか、彼らは目を落とします。」 したがって、CROCには、仮想サーバーの可用性に関する標準SLAに加えて、ディスクパフォ​​ーマンス用の完全に独立したSLAがあります。 以下は、それからの小さな抜粋です。つまり、保証されたドライブのパフォーマンスのアクセス不能性の判定です。 「フラッシュドライブのパフォーマンスが利用できない状態とは、接続先の仮想マシンのプロセッサが5分間のディスクサブシステムからのデータを5分間予期する場合、または5ミリ秒を超えるディスクサブシステムからのデータ受信の遅延と要求数のフラッシュドライブの状態です「フラッシュドライブあたりのIOPSは、宣言されたフラッシュドライブのパフォーマンスよりも3％低くなります。」



ここで宣言されているフラッシュドライブのパフォーマンスは、それぞれ標準ストレージレベル400、1000、3000、5000、10000 IOPS、または10,000 IOPSから100,000 IOPSの個々のストレージレベルを意味します。 宣言されたパフォーマンスパラメータを飛び越えてすぐに、アクセスできない状態が数分かかります。 SLA 99.9に向けて飛び立つとすぐに、罰金が科せられます。 だから私たちは、貧弱な仕事が私たちの利益にまったくならない状況に追い込まれています。



保証されたディスクパフォ​​ーマンスが不要で、大量のデータを手頃な価格で保存する必要がある場合はどうすればよいですか？ クラウドにはSATAデータストレージもあり、最適なレートで最もホットでないデータを配置できます。 また、さまざまなタイプのストレージ間の移行はその場で行われます。



ちなみに、このサービスは非常に人気があり、タイムリーであったため、4か月で8つのフラッシュアレイを60％売り上げ、さらに8つのフラッシュアレイを注文しました。 これはロシアで最初のクラウドで、1 PB以上の正しいフラッシュがあります。 そのため、新しいデータの流れを受け入れる準備が整いました。これは、個人データに関する知識の日の前夜に、夏の終わりから夏の終わり近くにあふれます。 ちなみに、多くのお客様はすでに多くの困難なくタイムリーに私たちに移動しています。 以前にAmazonの機能を使用していたユーザーにとって特に便利です。同様のアーキテクチャ、互換性のあるAPI、およびパブリッククラウドを構築するための緊密なアプローチがあります。



ロシア連邦のロードされたITシステムのディスクリソースの整理について質問がある場合は、コメントで、またはメールでのタスクの計算ミスで詳細に答える準備ができています：MBerezin@croc.ru



参照：

• サーバー保険会社のリファクタリング -データよりも物理的なスペースが少ない場合
• バイオリンの概要 -DRAMに近い速度のフラッシュストレージ