保管 多層ソフトウェア定義ストレージ。 例としてMIRhostingクラウドを使用して、なぜ、なぜ、どのように実装されるか

クラウドのテーマは最近ますます需要が高まっています。 現在、ロシア連邦でさえ、企業はこのクラウドを使用できる理由をますます理解し、積極的に使用し始めています。 クラウドに関心を示す企業が増えれば増えるほど、クラウドソフトウェアの開発者、新しいトレンドやテクノロジーの実装、プラットフォーム全体のフェイルセーフ運用を保証するサービスプロバイダーに疑問が生じます。



この記事では、クラウドの1つの側面についてのみ経験を共有したいと思いますが、同時に、おそらく最も複雑で重要なのはディスクスペースの実装です。 この記事は、Jelastic PaaSを使用するホスティングプロバイダーの1つであるMIRhostingのクラウドエキスパートであるAndrei Nesterenkoによって作成されました。 彼は先月、ロシアでクラウドプラットフォームの第3領域の開設を発表しました。





まず、クラウドプラットフォーム全体の動作に関する背景情報。 はい、VPSを販売してこのアクションをクラウドと命名することではなく、クラウドプラットフォームについて具体的に説明しています。 私たちの理解では、重要な違いはフォールトトレランス（特に、ローカルデータストレージの使用を自動的に除外します）、いつでも「無制限の」リソースプールへのアクセス、および制限や関税ではなく、これらのリソースを使用した事実に対する支払いです。 このようなクラウドの技術的な実装には、機器、ネットワーク、オーケストレーション、技術サポートなどのすべての要素のコラボレーションが必要です。



以下では、フォールトトレラントディスク領域という1つのコンポーネントのみを実装する方法について説明します。

ソフトウェアデファインドストレージ（SDS）

技術的には、データウェアハウスはVirtuozzo Storageによって強化されています 。 他のSDS実装と同様に、このアイデアに不慣れな人にとって最も有名なオープンソースソリューションはCephです。 CephではなくVirtuozzo Storageの選択は、主に商用サポートと開発、 パフォーマンス特性の向上、およびコンテナのライブマイグレーションの「シャープ化」に関連しており、その結果、これらのコンテナのフォールトトレランスにつながります。 もう1つの重要な理由は、JelasticがすぐにVZ SDSとの統合を提供することです。 Virtuozzo Storageについて書きますが、いくつか変更があります。 これはすべて、Cephおよび他の同様のソリューションに適用できます。



そのため、Virtuozzo Storageのアーキテクチャには、メタデータサーバーとチャンクサーバーの2つのコンポーネントがあります。 データは、いわゆるチャンク、つまり 本質的にバイナリの「ピース」。 これらの「断片」は、チャンクサーバー上に分散されます。チャンクサーバーは、できる限り多くする必要があります。 実際には、チャンクサーバーは個別のディスク（HDD、SSD、NVMEのいずれでもかまいません）です。つまり、12台のディスクを備えたサーバーが1台ある場合、RAID 0パフォーマンスを提供する12台のチャンクサーバーがあります。 もちろん、フォールトトレランスを保証するために、このような個別のサーバーをいくつか用意する必要があります。5が最小推奨量です。 サーバーとチャンクの数が多いほど、個々のチャンクサーバーに障害が発生した場合のパフォーマンスとレプリケーションの速度が向上します。



サーバーメタデータは、それぞれ、さまざまなチャンクサーバーに分散したこのデータの断片全体を管理します。 正しい操作のために必要なメタデータサーバーは1つだけですが、障害が発生すると、クラスター全体にアクセスできなくなります。 一方、メタデータサーバーが多いほど、パフォーマンスが低下します。これは、すべてのI / Oクラスターアクションをより多くのサーバーで記録する必要があるためです。 また、古典的なスプリットブレインの問題もあります。1つまたは複数のメタデータサーバーに障害が発生した場合、アクティブで一意であることが保証されるためには、残りは「多数」のままにしてください。 通常、3つのメタデータサーバーは小さなクラスター用に作成され、5つのクラスターは大きなクラスター用に作成されます。



これは、典型的なクラスターの外観です。



（Virtuozzoブログの写真、みんな気にしないと思う）



クラスター管理者は、グローバル設定で、使用可能であることが保証されるレプリカの数を設定できます。 言い換えると、データを損失することなく失敗できるサーバーチャンクの数はいくつですか？ 物理的に3つのサーバーがあり、各サーバーに3つのディスク（チャンクサーバー）があり、推奨値として3つのレプリカを設定するとします。 最初に頭に浮かぶのは、1つのサーバー全体で、それに応じて3つのチャンクサーバーで障害が発生した場合はどうなるかということです。



一部のデータの3つのレプリカが1つの物理サーバー内のこれらの3つのチャンクサーバーにのみ書き込まれた場合、6つのチャンクサーバーを備えた2つの物理サーバーがオンラインであるにもかかわらず、このデータは失われます。 この状況を管理するために、異なるレベルのレプリケーションを構成できます。チャンクサーバーのレベル（非推奨）、ホストレベル（デフォルト）、またはラックレベルと建物/場所レベルで。



上記の例に戻ると、デフォルト値を使用する場合、ホストレベルで、メタデータサーバーは同じ物理サーバー上にあるチャンクサーバーを自動的に決定し、異なる物理マシンにレプリケーションを提供します。 レプリケーションをラックまたは場所のレベルで機能させるには、どのマシンがどのラックおよび/または場所にあるかを指定する必要があります。 この場合、フォールトトレランスは異なるラックまたはデータセンターのレベルでも機能します。 これはまさにMIRhostingで行ったことです。データは2つの独立したデータセンターに分散されています。

十分な理論、本当に面白いことを教えてください

そのため、このようなSDSテクノロジーを使用すると、理論的に完全なフォールトトレランスが得られますが、理論とサイトに関するホワイトペーパーは別のものであり、実践と要求の多いクライアントは別のものです



最初に直面したのはネットワークです。 通常の状況では、チャンクサーバー間のトラフィックは約200 Mbpsであり、500 Mbpsを超えることはほとんどありません。 サーバーが多いほど、異なるサーバー間でより多くのトラフィックが「スミア」されます。 ただし、チャンクサーバーに障害が発生した場合、緊急のレプリケーションが開始され、データの正しいバランスが復元されます。 また、サーバーが多いほど、失われるデータが多くなり、より多くのデータがネットワーク上を飛び始め、5ギガバイト以上を簡単に作成します。 したがって、9000 MTU（ジャンボフレーム）と同様に、10ギガビットネットワークが最小要件です。 もちろん、非常に優れたフォールトトレランスと全体的な安定性を提供する場合は、2つの個別の10 Gbスイッチを用意し、2つのポートを介して各データストレージを接続することをお勧めします。



ちなみに、これにより、スイッチのファームウェアを更新するなどの複雑な問題も解決されます。



2番目に決定したのは、デュアルデータセンターに基づいてクラスターの動作を保証することでした。 最初は、データウェアハウスネットワークは純粋なL2で実行されていました。 ただし、クラウドプラットフォーム全体の成長と、その複合としてのデータウェアハウスのボリュームの増加により、特に、純粋なL3に切り替える必要があるという論理的な決定に至りました。 このステップは、別のトピック-デュアルデータセンターとライブマイグレーションの条件でのコンテナーの作業-に非常に関連しています。 データウェアハウスのネットワークは、統合のために、コンテナの内部および外部ネットワークと同様に作成されました。 このトピックは別の記事に値するものであり、コミュニティにとって興味深いものになることを願っています。 L3への移行によるパフォーマンスの低下はありませんでした。



3番目の、おそらく最も重要なのはパフォーマンスです。 クライアントは異なり、要件もプロジェクトも異なるため、パブリッククラウドの状況ではこれは難しい問題になります。 これ自体は、I / Oクラスターの全体的なパフォーマンスと、さまざまなクライアントに必要なさまざまなパフォーマンスの2つの部分に分かれています。 最初のものから始めましょう。



ドキュメントやVirtuozzoテクニカルサポートからの情報などのベストプラクティスは存在しないため、多くの点でパフォーマンスの問題は「pokeメソッド」を使用して解決されました。 Virtuozzoのテクニカルサポート担当者の1人が多くのことを助け、電話で30分を費やして多くのことを話しました。 利用可能なすべての情報を収集し、いくつかの頭脳を追加し、経験のザルを通過して、次のスキームに到達しました：



計算ノード（コンテナーが起動されるノード）-システムはSSD上で実行され、pfcacheはその上にあります。 2番目のSSD、最近ではNVMe-クライアントのキャッシュの下。 ローカルチャンク用の1つまたは2つのSSD / NVMe。 RAID1を使用することは可能ですが、SSDの開発のこの段階では、いずれにせよ障害（フェールオーバー）が発生した場合のコンテナの自動復旧を考えると、あまり重要ではありません。 クライアントキャッシュは、計算ノードのチャンクほど効果がありません。 システムは最も近い利用可能なチャンクを決定し、それを「ホット」データに使用しようとします。



ストレージノード（チャンクのみに使用され、コンテナなしで使用されるノード）は明らかにSSDとNVMeで詰まっています。 HDDは、歴史的に「コールド」レプリカを提供するために実際に使用されてきました。



HDDキャッシュは使用されず、HDD自体はすでにSSDに完全に置き換えようとしています。 まだHDDが存在するストレージシステムは、書き込み操作によるキャッシングを備えた、適切なRAIDカードRAID0を介して常に機能し、これらのHDDのパフォーマンスが向上します。



利用可能なクラスターパフォーマンスの合計は、チャンクの数、つまり ドライブ。



2番目のタスクは、パブリッククラウドのI / Oおよびさまざまな顧客の要求を規制する必要性です。 クラウド内の各コンテナーについて、操作数（iops）およびスループット（io limitスループット）に対して特定のI / O制限が設定されます。 現時点では、MIRhostingクラウドはデフォルトで500 IOPSと200 Mb / sの帯域幅を提供します。これは、SATA HDDの2倍のパフォーマンスにほぼ等しくなります。 大部分の顧客にとって、これらの制限は各コンテナに与えられており、クライアントが任意の数量で作成できるため、これらの数は十分です。



ただし、一部のお客様は、I / Oパフォーマンスの向上が必要です。 明らかに、これは顧客ごとに異なる制限によって解決されます。 しかし、たとえば、コンテナあたり10,000 iopsの能力を備えたクラスター（および適切な供給量）を持ち、制限を減らしてリソースを販売することは、経済的に有益ではありません。



良い解決策があります-これは、データウェアハウスでさまざまなレベルを使用する機能です。 最初のレベルはSSD + HDD上に構築され、2番目のレベルはSSD + NVMe上に構築されるとします。

宣言された特性を提供し、経済的に実現可能にします（これはコストに直接関係します）。 コンテナをあるレベルから別のレベルに移動することは「ライブ」で行われ、他のクラウドリソースと同様に1時間ごとのレートでJelastic PaaSに実装されます。



最初のコンピュートノードにあるコンテナが1つあるとします。 そのファイルシステムは5つのチャンクに分割されます。 また、クラスターは3つのレプリカを使用するように構成されています。つまり、各チャンクは3つの異なるサーバーに配置されます。 gifの最初のスライドは、ティア0に配置されたときのチャンクの配置方法です。以下は、ティア1メディアにチャンクをクロールするプロセスを示しています。



現時点では、クラウドストレージリソースは十分に安定しており、どのように異なる生活を送ることができるか想像するのは困難です。 ディスク、さらにはノード全体に障害が発生しても、顧客に目に見える問題は発生せず、ディスクを交換および追加するための計画的なアクションが必要です。



PSすでにこの資料を準備する過程で、記事が発行されましたhabrahabr.ru/post/341168 、同様の問題とトピックについて説明します。 私たちの記事は、同じタスクと問題に対するわずかに異なる見解を反映しており、コミュニティにとって役立つことを願っています。



記事で言及されているマイナスを個別に検討するのは興味深いでしょうが、これらのマイナスのほとんどはデータウェアハウスそのものではなく、クラウドのよりグローバルな作業、特に移行の問題に関連しています。



トピックが興味深い場合、デュアルデータセンターに基づくクラウド内のコンテナーの操作に関する独自の開発を共有できます。 特に、このようなスキームのフレームワーク内でのネットワークおよびライブマイグレーションの側面から。



一般に、バグがあるというSyCraftに同意する必要があり、Virtuozzoテクニカルサポートは常に何が起こっているのか、なぜ起こっているのかを明確に伝えることはできません。 それにもかかわらず、このソリューションは、実際には、必要なサービスのセットを提供するクラスで唯一のものであり、積極的に開発されており、商業的です。つまり、開発者によってサポートされています。



ここで登録することにより、Jelastic PaaSからの特定のアプリケーションの詳細とMIRhostingインフラストラクチャのパフォーマンスを考慮して、コンテナの自動配布およびオーケストレーションと組み合わせて、このフォールトトレラントディスクスペースのソリューションを試すことができます 。 フィードバックをお待ちしています。