ZStack はどのようにしてハイブリッド クラウドの災害復旧を実現するのでしょうか?この記事を読めば分かるだろう

[51CTO.com からのオリジナル記事]この記事では、ZStack ハイブリッド クラウド ディザスタ リカバリの実装メカニズムを、軽快でユーモラスなスタイルで説明します。

[[204175]]

1. 「ドッグフード」災害復旧危機

弊社のエンジニアリング業務において、最も一般的な業務は「ドッグフードを食べること」です。つまり、エンジニア全員の開発環境やテスト環境はZStackによって構築されているのです。当初、エンジニアたちは 2 つの小さなオフィスに住み、とても幸せでした。ある日、エンジニアが誤ってプライマリストレージを削除してしまったことが、全員の悲しみの叫びとともに分かりました。

ZStack の設計のおかげで、環境全体が 30 分で正常に復元されました。理由は2つあります。

1. システムは自動的にバックアップ サービスを展開し、データベースは 1 時間ごとに定期的にバックアップされます。
2. ZStack 自体はステートレスであり、データベースが存在する限り環境を復元できます。

危機一髪の末、この事件は「クラウドの見出し」となった。

2. 災害復旧は重要ですが、なぜハイブリッド クラウドの災害復旧が必要なのでしょうか?

ユーザーは必然的に、ドッグフードを食べる人と同じ問題に遭遇することになります。ひいては、「データベースを削除して暴走」や「誤操作によるデータ消失」といったニュースが年中メディアを賑わせている昨今、データベースの記録だけでなく、実際のストレージシステムのデータが削除されたり、ストレージに障害が発生したりしたらどうなるのか、真剣に考える必要があります。

災害復旧は必要ですが、災害復旧は単なるデータのバックアップではありません。データのバックアップは最も自然で基本的なニーズです。データ復旧が完了した後、ユーザーが本当に復旧する必要があるのはビジネスです。プライベート クラウドのシナリオでは、ビジネス リカバリのリソースの粒度は、仮想マシンまたはクラスターにすることができます。 「キラーアプリケーションが実行されていないプラットフォームを販売することはできない」とすれば、ZStack の災害復旧機能はハイブリッド クラウド プラットフォームのキラーアプリケーションとなるでしょう。

ZStack にハイブリッド クラウド ディザスタ リカバリを導入することで、ユーザーは仮想マシン イメージと関連メタデータをパブリック クラウドにバックアップできます。ローカルデータが失われた場合でも、指定されたクラウド バックアップを取得して再構築できます。さらに、ユーザーはパブリック クラウド内にバックアップ データを含む仮想マシンを直接作成できます。災害復旧クラウド。

ハイブリッド クラウドを通じて災害復旧が実現される理由をさらに詳しく説明する前に、プライベート クラウドについて確認しましょう。

プライベートクラウド

純粋なプライベート クラウド環境は閉ループであり、システム全体のリソースはプライベート クラウド内に割り当てられます。システム管理者は、IaaS ソフトウェアを使用して、会社のさまざまな部門にアプリケーション環境を提供します。 IaaS ソフトウェアは、インフラストラクチャの監視と可視化、リソースの柔軟な割り当て、保守性の問題を解決します。

シンプルなプライベートクラウドのシナリオ

図 1 は、簡略化されたプライベート クラウドのシナリオです。プライベート クラウドは、複雑で面倒な構成から IT スタッフの生産性を解放します。それ以来、IT スタッフは、どのように提供するかよりも、実際に提供するかに重点を置くようになりました。 IaaS ソフトウェアは、システム内のすべてのリソース関係を認識します。重要な概念の 1 つは、コンピューター (仮想マシン) がもはや個別のハードウェア機能ではなく、独立した完全なリソース配信ユニットであるということです。

IaaS ソフトウェアがない環境では、災害復旧の主なリソース エンティティはストレージであり、オブジェクト ストレージ、ブロック ストレージ、またはファイル システムの形式でオフサイト バックアップを実行します。しかし、ストレージはコンピューティングの多くの側面のうちの 1 つにすぎません。復旧したデータをいかに迅速かつ効果的に活用するかは、依然として IaaS などの上位管理ソフトウェアに依存します。

ハイブリッドクラウド

ハイブリッドクラウド災害復旧が誕生しました。まず、パブリック クラウドと比較すると、一般的なプライベート クラウドでは十分な大きさのリソース プールを持つことが困難です。リソースが多すぎると無駄が生じますが、これは企業が望まないことです。リソースが少なすぎると突然の需要に対応できなくなり、これも企業にとっての悩みの種となります。第二に、パブリック クラウドは完全な IaaS アプリケーション プログラミング インターフェイスを提供し、プライベート クラウドはプログラミング インターフェイスを通じて IaaS フレームワーク内のさまざまなリソース要件を拡張できます。パブリック クラウドのデータ層とネットワーク層が接続されると、パブリック クラウドは突然のコンピューティング ニーズに対応できるだけでなく、災害復旧キャリアとしても非常に適していることがわかります。主な理由は次のとおりです。

1. 完全なアプリケーションプログラミングインターフェース
2. 優れた弾力性のあるコンピューティング機能。
3. ほぼ無制限のストレージスペース。

ハイブリッドクラウドのシナリオ

図 2 は、パブリック クラウドに接続した後のハイブリッド クラウドのシナリオを示しています。図 1 と図 2 を比較すると、2 つの違いは、システム リソースへのアクセスが集中化されているかどうかという、Subversion と Git の違いに多少似ていることがわかります。

3. ハイブリッド クラウドの災害復旧を実現するにはどうすればよいでしょうか?

ZStack 独自のイメージ リポジトリ設計は、ハイブリッド クラウドの災害復旧の中核です。

ミラーリポジトリの設計アイデア

図 3 は、ZStack イメージ リポジトリの高レベル アーキテクチャを示しています。 Opentack Glance や Docker Registry と同様に、ZStack Image Repository (以下、Image Repository) は実際のストレージを担当せず、イメージ管理とメタデータのメンテナンスのみを実行します。

ZStack イメージリポジトリアーキテクチャ

ただし、イメージリポジトリで使用されるデータ編成方法は、前述の 2 つとはまったく異なります。簡単に言えば、イメージリポジトリのデータ保存方法は、コンテンツアドレス可能なストレージである git に似ています。すべてのストレージ エントリはミドルウェアのレイヤーを通じてカプセル化され、実際のストレージ作業はバックグラウンド ストレージ プラグインによって完了します。ローカルストレージやAliyun OSSなどのクラウドストレージに接続できます。

この設計には次の利点があります。

1. データ保存と管理ロジックの分離。
2. コンテンツはアドレス指定可能であるため、クライアントとサーバーは相互に信頼することなく、すべてのデータ (メタデータを含む) に対して個別にハッシュ検証を実行できます。
3. データは変更できません (メタデータを含む)。変更するとハッシュ値も変更されます。

画像の整理に関しては、ZStack 画像リポジトリはメタデータを通じて画像間の関係を維持し、画像形式を気にしません。リポジトリ内のイメージ ソースは、qcow2 ファイルまたは RBD イメージにすることができます。イメージ全体を再構築するのはクライアントの責任です。たとえば、qcow2 ファイルには qemu-img ツールを使用し、RBD イメージには rbd ツールを使用できます。

イメージ ウェアハウスを使用してハイブリッド クラウドの災害復旧を実現する方法

次に、イメージ リポジトリを使用してハイブリッド クラウドの災害復旧を実現する方法を見てみましょう。

具体的には、イメージ リポジトリにプッシュ操作とプル操作を実装し、異なるイメージ リポジトリ間で指定されたイメージを簡単に同期できるようにしました。 git と同様:

• プッシュはローカルイメージをリモートにプッシュすることです。
• Pull は、リモート イメージをローカルに取得することです。

ZStack イメージ リポジトリのプッシュとプル

パブリック クラウドにバックアップされたイメージ リポジトリの場合、そこに含まれるイメージは、ローカル イメージ リポジトリ内のイメージと変わりません。また、コンテンツはアドレス指定可能であるため、画像転送プロセス中に大量の不要なデータ転送を回避できます。これは非常に重要です:

1. データの整合性は簡単に検証できます。
2. 画像転送速度が大幅に向上し、時間を節約します。
3. データセンターからのトラフィックが削減され、顧客のコストが削減されます。

具体的な実装では、読み取りと書き込みの競合、書き込みと書き込みのマージ、水平方向の拡張をどのように処理するかについても考慮する必要があります。スペースの制限により、詳細は説明できません。

以下は、イメージ リポジトリに基づく ZStack のいくつかの一般的な災害復旧戦略です。

バックアップ戦略

ユーザーは、バックアップが必要な仮想マシンの手動バックアップを実行したり、バックアップ ポリシーを指定して自動バックアップを実行したりできます。たとえば、バックアップ間隔など。手動バックアップ機能が必要です。これにより、ユーザーは仮想マシンをタイムリーにバックアップし、時間枠のリスクを回避できます。

仮想マシンの回復

ユーザーがルート クラウド ディスクをバックアップした後、仮想マシンを復元するには、リモート バックアップをローカル イメージ リポジトリに取得し、仮想マシンを作成するだけです。タイム トンネルを開くのと同じように、ユーザーは仮想マシンを任意のバックアップ ポイントに戻すことができます。

リカバリデータディスク

同じロジックがデータ ディスクにも適用されます。イメージ リポジトリでは、ルート クラウド ディスクとデータ ディスクは区別されません。データ ディスクを復元するには、リモート バックアップをローカル コンピューターに取得し、それを仮想マシンにロードするだけです。

[[204180]]

ミラーリポジトリは「リング」です

要約すると、イメージ リポジトリは、ローカル、リモート、rbd、qcow2、およびさまざまなストレージ バックエンド用の統合されたサービス インターフェイスを提供します。これはポリシーとメカニズムの分離の典型的な応用例です。イメージ リポジトリは、イメージの保存とメンテナンスのメカニズムのみを提供し、イメージの使用方法については考慮しません。また、ミラーリポジトリのデータ構成特性により、必要に応じてリソースを指定してリポジトリ間のデータを同期することができます。この柔軟な設計により、ZStack の災害復旧機能に強固な基盤が提供されます。

パブリッククラウドなし

一歩引いて考えると、ユーザーがパブリック クラウド環境に接続していない場合でも、データ チャネルの速度が完全に保証されていれば、ユーザーはイメージ ウェアハウスをオフサイト (IDC コンピューター ルームなど) に展開でき、オフサイト バックアップも簡単に実現できます。唯一の欠点は、ローカルのプライベート クラウドで突然災害が発生した場合、パブリック クラウドの機能を活用して重要なアプリケーションを迅速に復元する方法がないことです。

まとめ

すべての卵を 1 つのバスケットに入れることはできないのと同様に、重要なデータをすべてローカルに保存することはできません。ハードウェアの機能が継続的に向上するにつれて、ユーザーのリソース単位あたりのコストは低下しますが、データの潜在的な価値は増大します。データが大きくなればなるほど、また事業規模が大きくなればなるほど、コストは高くなります。災害復旧機能とビジネスを体系的に回復する能力があってこそ、心配は無用です。クラウドの世界には、「後悔の薬」が実際に存在します。

ZStack のチーフエンジニア、Li Qun 氏。彼は ZStack の開発全体を担当しており、クラウド コンピューティングとセキュリティの分野で豊富な研究開発経験を持っています。 2007 年に EMC クラウド コンピューティング インフラストラクチャ部門に入社し、一般的なアプライアンス プラットフォームの研究開発を担当しました。 2010 年に Intel 開発製品部門に入社し、SGX 命令セットの SDK 開発を担当しました。 2015 年に Microsoft China Cloud Computing Innovation Center に入社し、Azure China CDN サービスの研究開発を担当しました。

【著者について】

[[204181]]

ZStack のチーフエンジニア、Li Qun氏。彼は ZStack の開発全体を担当しており、クラウド コンピューティングとセキュリティの分野で豊富な研究開発経験を持っています。 2007 年に EMC クラウド コンピューティング インフラストラクチャ部門に入社し、一般的なアプライアンス プラットフォームの研究開発を担当しました。 2010 年に Intel 開発製品部門に入社し、SGX 命令セットの SDK 開発を担当しました。 2015 年に Microsoft China Cloud Computing Innovation Center に入社し、Azure China CDN サービスの研究開発を担当しました。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]