自分で構築する：小規模なホスティング業者向けにAmazonスタイルのストレージを作成した方法

ますます多くのロシアのインターネットプロジェクトがクラウドサーバーを必要とし、Amazon EC2とその類似物に注目しています。 大規模な顧客の西側への逃避は、ルネットホスティング事業者にとっての課題であると考えています。 彼らはまた、好みと詩人で「彼らのアマゾン」を持っているでしょう。 比較的小さな容量で展開するための分散データウェアハウスに対するホスティング事業者の需要を満たすために、Parallels Cloud Server（PCS）を作成しました。



PCSの主要なハイライトの1つであるストレージパートのアーキテクチャについて説明します。 高価なSANストレージに匹敵する速度と耐障害性を備えた通常のハードウェアでデータストレージシステムを編成できます。 2番目の投稿（既に準備中）は、開発者にとって興味深いものであり、システムの作成とテストのプロセスで学んだことについて説明します。

イントロ

Habr読者の大半は、ParallelsがMacでWindowsを実行するためのソリューションの開発者であることを知っています。 視聴者の別の部分は、当社のコンテナ仮想化製品である有料のParallels Virtuozzo ContainersとParallels Server Bare Metal 、およびオープンソースのOpenVZについて知っています。 コンテナの根底にあるアイデアは、クラウドプロバイダーとYandexクラウドプロバイダーによってある程度使用されます。 しかし一般的に、Parallelsの長所は、小規模および/または急成長しているサービスプロバイダー向けのソフトウェアです。 コンテナを使用すると、ホスティング事業者は単一のサーバー上でオペレーティングシステムの複数のコピーを実行できます。 これにより、ハイパーバイザーの3〜4倍の密度の仮想環境が実現します。 さらに、コンテナ化された仮想化により、物理マシン間で仮想環境を移行できます。これは、ホストまたはクラウドプロバイダーが気付かないうちに発生します。



原則として、サービスプロバイダーは既存のサーバーのローカルドライブを使用してクライアントデータを保存します。 ローカルストレージには2つの問題があります。 まず、データ転送は多くの場合、仮想マシンのサイズによって複雑になります。 ファイルは非常に大きくなる可能性があります。 2番目の問題：たとえば、停電の結果としてサーバーがシャットダウンした場合、仮想マシンの高可用性を実現することは困難です。



どちらの問題も解決できますが、ソリューションの価格は非常に高くなります。 SAN / NASストレージなどのストレージシステムがあります 。 これらは、そのような大きな箱、ラック全体、そして大規模なプロバイダーの場合-多くの、多くのペタバイトのデータセンターです。 サーバーは何らかのプロトコルを使用してサーバーに接続し、そこにデータを追加するか、そこからデータを取得します。 SANストレージは、冗長データストレージ、フォールトトレランスを提供し、ディスクの状態を独自に監視し、検出されたエラーを自己修復および修正する機能を備えています。 これはすべて1つの例外を除いて非常にクールです。最も単純なSANストレージでさえ、少なくとも10万ドルの費用がかかります。これは、パートナーである小規模なホスティング事業者にとってはかなりの金額です。 同時に、彼らは似たようなものを持ちたいと思っており、常にそれについて私たちに話します。 この問題は、購入と所有の価格を大幅に引き下げて、同様の機能のソリューションを提供することから始まりました。

PCSアーキテクチャ：最初のストローク

分散ストレージの解釈は可能な限りシンプルにする必要があるという事実から始めました。 また、単純なタスクから始めました。システムは、仮想マシンとコンテナの機能を保証する必要があります。



仮想マシンとコンテナは、保存されたデータの一貫性に対して特定の要求を行います。 つまり、データに対する操作の結果は、何らかの方法で実行される順序に対応します。



ジャーナリングファイルシステムの動作を思い出してください。 彼女には日記があり、メタデータとデータそのものがあります。 ファイルシステムはデータをログに記録し、この操作の終了を待ちます。その後、データのみがハードドライブに書き込まれるべき場所に書き込まれます。 それから、新しいエントリーは雑誌で空いた場所に落ちます。そして、それはしばらくして、それに割り当てられた場所に送られます。 停電の場合、またはシステムがクラッシュした場合、ログ内のすべてのデータは保護されたポイントまで保持されます。 それらは、最終的な場所ですでに録音することによって失われる可能性があります。



一貫性には多くの種類があります。 すべてのファイルシステムがデータを表示することを期待する順序は、即時/厳密な整合性と呼ばれます。 これを「厳密な一貫性」と訳します。 厳密な一貫性には、2つの特徴的な機能があります。 まず、すべての読み取りは、書き込まれたばかりの値を返します。古いデータは表示されません。 次に、データは記録されたのと同じ順序で表示されます。



驚くべきことに、そのようなプロパティのデータを保存するためのほとんどのクラウドソリューションは提供していません。 特に、さまざまなWeb指向のサービスに使用されるAmazon S3 Object Storageは、完全に異なる保証を提供します-いわゆる結果整合性または有限時間整合性です。 これらは、記録されたデータがすぐには見えないが、しばらくしてから保証されるようなシステムです。 仮想マシンおよびファイルシステムの場合、これは適切ではありません。



さらに、ストレージシステムに多くの優れた機能が必要でした。

• 彼女は必要に応じて成長できなければなりません。 新しいドライブが追加されると、ストレージは動的に増加するはずです。
• 彼女は、単一のドライブにあるよりも多くのスペースを割り当てることができるはずです。
• 1つのディスクに100 TBを配置することは不可能であるため、割り当てられたスペースを複数のディスクに分割できる必要があります。

いくつかのディスクの話には、落とし穴があります。 データアレイを複数のディスクに分散し始めるとすぐに、データ損失の可能性が劇的に増加します。 1つのドライブに1つのサーバーがある場合、ドライブがクラッシュする可能性はそれほど大きくありません。 しかし、ストレージに100個のディスクがある場合、少なくとも 1つのディスクが燃える可能性が大幅に増加します。 ディスクが多いほど、このリスクは高くなります。 したがって、データは複数のコピーに冗長に保存する必要があります。



多くのディスク上のデータの配布には利点があります。 たとえば、破損したディスクの元のイメージを、多数のライブディスクと同時に並行して復元できます。 通常、クラウドストレージでは、このような操作には数分または数日もかかって復旧する従来のRAIDアレイとは異なり、数分かかります。 一般に、データ損失の確率は、データの復元に必要な時間の2乗に反比例します。 したがって、データの回復が速いほど、データが失われる可能性は低くなります。



データ配列全体を固定サイズ（この場合は64〜128 MB）の断片に分割し、それらを所定のコピー数で複製してクラスター全体に分散します。



次に、すべてを最大限に簡素化することにしました。 まず第一に、通常のPOSIX互換ファイルシステムが必要ないことは明らかでした。 システムを最適化する必要があるのは、数十ギガバイトを占める大きなオブジェクト（仮想マシンのイメージ）のみです。 画像自体はめったに作成/削除/名前変更されないため、メタデータの変更はまれであり、これらの変更は最適化できません。これは非常に重要です。 コンテナまたは仮想マシンが機能するために、オブジェクトには独自のファイルシステムがあります。 メタデータの変更に最適化され、標準のPOSIXセマンティクスなどを提供します。

クローン攻撃

多くの場合、プロバイダーでは個別のクラスターノードのみが失敗するという判断を聞くことができます。 残念ながら、データセンター全体でも電力が失われる可能性があります。クラスター全体が落ちます。 当初から、このような失敗の可能性を考慮する必要があると判断しました。 少し戻って、分散データウェアハウスで保存されたデータの厳密な一貫性を確保することが難しい理由を考えてみましょう。 そして、なぜ大規模なプロバイダー（同じAmazon S3）は結果整合性のようなストレージから始めたのですか？



問題は簡単です。 オブジェクトのコピーを1つ保存する3つのサーバーがあるとします。 ある時点で、オブジェクトに変更が発生します。 これらの変更により、3台のサーバーのうち2台が記録されます。 3番目は何らかの理由で利用できませんでした。 さらに、ラックまたはデータセンターで電力が失われ、電力が回復すると、サーバーのロードが開始されます。 また、オブジェクトの変更が記録されていないサーバーが最初にロードされる場合があります。 特別な措置を講じない場合、クライアントはデータの古い、無関係なコピーにアクセスできます。



大きなオブジェクト（この場合は仮想マシンのイメージ）をいくつかの部分に分割すると、すべてがより複雑になります。 分散ストレージがファイルイメージを2つのフラグメントに分割し、6つのサーバーを記録する必要があるとします。 すべてのサーバーがこれらのフラグメントに変更を加えることができない場合、停電後、サーバーのロード時に、すでに4つのフラグメントの組み合わせがあり、それらのうち2つは自然界には存在しません。 ファイルシステムは、このためにまったく設計されていません。



どういうわけか、バージョンをオブジェクトに関連付ける必要があることがわかりました。 これはいくつかの方法で実装されます。 1つ目は、トランザクションファイルシステム（たとえば、BTRFS）を使用して、データの更新と共にバージョンを更新することです。 これは正しいですが、従来の（回転する）ハードドライブを使用している場合-ゆっくり：パフォーマンスが時々低下します。 2番目のオプションは、ある種のコンセンサスアルゴリズム（たとえば、 Paxos ）を使用して、変更を行うサーバーが相互に同意するようにすることです。 これも遅いです。 データを担当するサーバー自体は、オブジェクトのフラグメントの変更のバージョン管理を追跡できません。 他の誰かがデータを変更したかどうかはわかりません。 したがって、データのバージョンは側面のどこかで更新する必要があるという結論に達しました。



バージョンは、メタデータサーバー（MDS）によって監視されます。 同時に、記録が成功したときにバージョンを更新する必要はありません。何らかの理由でサーバーの1つが記録しなかった場合にのみ必要であり、除外します。 したがって、通常モードでは、データは可能な限り最高の速度で記録されます。



実際、ソリューションアーキテクチャはこれらすべての結論から成り立っています。 次の3つのコンポーネントで構成されます。

• 通常のイーサネット経由でストレージと通信するクライアント。
• MDS。どのファイルがどこにあり、フラグメントの現在のバージョンがどこにあるかに関する情報を保存します。
• フラグメント自体は、サーバーのローカルハードドライブに分散しています。

明らかに、アーキテクチャ全体では、MDSがボトルネックです。 彼はシステムに関するすべてを知っています。 そのため、高可用性を実現する必要があります。そのため、マシンに障害が発生した場合にシステムを使用できます。 MySQLや他の一般的なデータベースなどのデータベースにMDSを「配置」するのは魅力的でした。 しかし、これは私たちの方法ではありません。SQLサーバーでは1秒あたりのクエリ数が非常に制限されているため、システムのスケーラビリティがすぐに失われてしまいます。 SQLサーバーの信頼できるクラスターを作成することはさらに困難です。GoogleFSに関する記事でソリューションを検討しました。 元のバージョンでは、GoogleFSはタスクに適合しませんでした。 検索エンジンにデータを追加することを目的としていますが、このデータを変更することは意図していないため、望ましい厳密な整合性は提供されません。 ソリューションは次のとおりです。MDSは、オブジェクトとそのバージョンに関する完全な状態をメモリ全体に保存します。 それほど多くないことが判明しました。 各フラグメントは合計128バイトを記述します。 つまり、数ペタバイトの容量を持つストレージの状態の説明は、最新のサーバーのメモリに収まります。これは許容範囲です。 MDS状態の変更は、メタデータログに記録されます。 雑誌は比較的ゆっくりですが、成長しています。



私たちのタスクは、複数のMDSが相互に何らかの形で合意できるようにし、たとえ1つがクラッシュしてもソリューションの可用性を確保することです。 ただし、問題があります。ログファイルが無期限に大きくなることはありません。ログファイルで何かをする必要があります。 これを行うには、新しいログが作成され、すべての変更がそこに書き込まれます。同時にメモリスナップショットが作成され、システムの状態がスナップショットに非同期で書き込まれます。 スナップショットが作成されたら、古いログを削除できます。 システムがクラッシュした場合、スナップショットとそのログを「失う」必要があります。 新しいログが再び大きくなると、手順が繰り返されます。

その他のヒント

分散クラウドストレージを作成するプロセスで実装したいくつかのトリックを以下に示します。



高速記録フラグメントを達成する方法は？ 通常、分散リポジトリはデータの3つのコピーを使用します。 「額」を書き込む場合、クライアントは新しいデータを使用して3つのサーバーに書き込む要求を送信する必要があります。 ゆっくりと、つまりネットワーク帯域幅の3倍遅くなります。 ギガビットイーサネットを使用している場合は、コピーごとに30〜40 MBのデータのみを転送しますが、これは顕著な結果ではありません。HDDでも書き込み速度が非常に速いためです。 鉄とネットワークリソースをより効率的に使用するために、チェーンレプリケーションを使用しました。 クライアントは、最初のサーバーにデータを渡します。 最初の部分（64 Kb）を受け取った彼は、それをディスクに書き込み、チェーンに沿って並行して他のサーバーに送信します。 その結果、大きなリクエストはできるだけ早く書き込まれ始め、他の参加者に非同期で送信されます。 データの3つのコピーについて話している場合でも、鉄は最大パフォーマンスの80％で使用されることがわかります。 また、イーサネットはデータを同時に送受信できるため（全二重）、つまり、 実際には、1秒間ではなく1秒間に2ギガビットを生成します。 また、クライアントからデータを受信したサーバーは、同じ速度でチェーンに沿ってさらにデータを送信します。



SSDキャッシング。 SSDはあらゆるストレージの高速化に役立ちます。 この考え方は新しいものではありませんが、オープンソースには本当に良い解決策がないことに注意する必要があります。 SANストレージは、このようなキャッシュを長い間使用しています。 ヒントは、HDDが生成できるよりも桁違いに高いランダムアクセスパフォーマンスを発行するSSDの機能に基づいています。 SSDでデータのキャッシュを開始すると、速度が10倍速くなります。 さらに、すべてのデータのチェックサムを考慮し、SSDにも保存します。 すべてのデータを定期的に減算し、それらの可用性とチェックサムの順守を確認します。 後者はスクラブとも呼ばれ（覚えている場合、スキンスクラブはそこから遊離粒子を除去します）、システムの信頼性を高め、実際にデータが必要になる前にエラーを検出することもできます。



仮想マシンにとってSSDキャッシングが重要であるもう1つの理由があります。 実際には、たとえばAmazon S3やその類似物などのオブジェクトストアでは、オブジェクトへのアクセスの遅延はそれほど重要ではありません。 原則として、それらへのアクセスはインターネット経由で行われ、10ミリ秒の遅延はそこでは目立ちません。 ホスティングプロバイダーのサーバー上の仮想マシンについて話している場合、OSが一連の連続した同期要求を実行すると、遅延が累積し、非常に顕著になります。 さらに、すべてのスクリプトとほとんどのアプリケーションは本質的に同期しています。 並行してではなく、操作後に操作を実行します。 その結果、ユーザーインターフェイスまたはユーザーアクションへの応答で、数秒、さらには数十秒がすでに顕著になっています。

結果と結論

その結果、データストレージシステムを取得しました。これは、プロパティによって次のプロパティがあるため、ホスティング事業者がインフラストラクチャに展開するのに適しています。

• 次のように、ストレージから仮想マシンとコンテナを直接実行する機能 私たちのシステムは、強力な一貫性セマンティクスを提供します。
• 複数のサーバーとドライブでペタバイトのボリュームに拡張する機能。
• データチェックサムとSSDキャッシングのサポート。

パフォーマンスについて一言。 entreezaストレージ施設のパフォーマンスに匹敵することが判明しました。 Intelの4x HDDを備えた14台のサーバーのクラスターを使用し、通常のSATAハードドライブ上の非常に小さな（4 KB）ファイルで1秒あたり13,000のランダムI / O操作を受け取りました。 これはかなりたくさんあります。 SSDキャッシングは、同じストレージの作業をほぼ2桁加速しました。1秒あたり100万回のI / O操作に近づきました。 1テラバイトのデータの回復速度は10分で、ディスクの数が多いほど、回復は速くなりました。



同様のSANストレージは、数十万ドルの費用がかかります。 はい、大企業は購入とメンテナンスを行う余裕がありますが、同じパラメーターのソリューションをはるかに少ないお金と既存の機器で入手したいホスティング業者向けに独自の分散ストレージを作成しました。



***



冒頭で述べたように、「継続する」。 Parallels Cloud Serverのストレージ部分の開発方法に関する投稿を準備中です。 コメントで提案を受け付けています。コメントを読んでください。 それらを考慮に入れようとします。