大多数の企業にとって、自社のサイトを2つ以上持つことは、依然として容認できない贅沢です。 この状況でITサービスの提供の継続性を確保するにはどうすればよいでしょうか？ 結論は明らかです：何らかの理由でパブリックプラットフォームをメインプラットフォームとして使用できない場合-バックアップとして正常に使用できます！
クラウドテクノロジーの開発により、 パブリッククラウドで仮想マシンをホストするためのアクセス性の高いサービスを優先して、独自のインフラストラクチャを放棄する組織が増えています。
ただし、会社の活動の詳細、プライベートクラウドを構築するために既に完了したプロジェクトの可用性、パフォーマンス、セキュリティなどの特定の要件のために状況が残っています。これらは一時的なものですが、パブリッククラウドを使用してITサービスをホストすることはできません。
バックアップサイトをパブリッククラウドに配置する技術的な可能性はありますか？ プロジェクトを実装する際にどんな困難に遭遇しますか？ このような質問は、ネットワークの広大さ、およびクラウドサービスの潜在的な消費者の間でますます生じています。 サービスプロバイダーは、マルチテナンシー、リソース効率、互換性、およびネットワークインフラストラクチャ要件に関するこの質問に追加します。
クラシックDRSソリューション
バックアップサイトまたはデータリカバリサイトを作成するための従来のソリューションは、その複雑さにより、常に素人の想像力をかきたてました。 まず第一に、これはデータ複製に関するものであり、これはストレージによって実行されることになっており、ストレージは次のようになります。
- ストレージ機能の基準を大幅に引き上げ、
- 互換性を確保するために、ストレージメーカーの選択に制限を課しました。
- 高価なライセンスの購入が必要でした。
そして、バックアップとリカバリを管理するためのソフトウェア自体には、かなりのコストがかかっていました（そして現在のところ）。 このようなソリューションの顕著な例は、VMware Site Recovery Managerです。 しかし、技術はまだ止まっておらず、市場での競争の激化により、メーカーは古い問題を解決するための新たな機会を開かざるを得ません。
新しいアプローチ-ハイパーバイザーレベルのレプリケーション
これらの新機能の1つにVMware vSphere Replicationテクノロジがあり、これはVMware Site Recovery Managerバージョン5.0の一部としてデビューし、vSphere 5.1仮想化プラットフォームに無料で、ほぼすべてのエディションに含まれました。
このテクノロジーは、特別なストレージ機能を使用せずに、ハイパーバイザーレベルでサイト間でデータを複製する機能を提供しました。 そして、ほぼ即座に、vSphereに基づいた独自の仮想インフラストラクチャを持つ企業の関心は、情報システムのバックアップを「小さな血」で編成する潜在的な機会に生じました。
しかし、ストレージから切り離すことは、レプリケーションシステムのコストと簡素化を削減するだけでなく、「一貫性のない」ストレージシステムと独立して管理されるインフラストラクチャ間のレプリケーションにとって重要な機会を提供しました。 そして実際、クラウド内でのバックアップサイトのシンプルで効果的な実装への道を開きました。
vSphereレプリケーションテクノロジー
vSphere Replicationテクノロジは、ユーザーの観点から見ると非常に単純です。 メインサイトの仮想マシンディスクに加えられた変更はハイパーバイザーによって監視され、指定されたRPO（回復ポイント目標）ポリシーに従って、定期的にバックアップサイトと同期されます。 この場合、同期は両方のサイトにあるVRアプライアンスのサービス仮想マシンによって制御され、サイト間のデータはメインサイトのハイパーバイザーからバックアップサイトのVRアプライアンスに転送されます。
同時に、この技術は、手動データレプリケーションを整理するためにvSphereプラットフォームの一般ユーザーにも、Site Recovery Managerの一部としても利用できます。これにより、対応する自動ネットワーク再構成、定期的な非破壊テストなどにより、フェイルオーバーおよびギブバックプロセスを柔軟に制御できます.p。
vSphere Replicationを実際に使用する
別のクライアントがバックアップサイトの編成を提案して当社に来たとき、vSphere 5.1のリリースから1か月も経っていません。 しかし、ほとんどすぐに、このような複製技術がこのプロジェクトで検討された主な選択肢になりました。
vSphereを両側の仮想化プラットフォームとして使用し、使用するストレージシステムの違いにより、レプリケーションテクノロジーの選択が決定され、SRMを使用するための追加費用なしで実行できる自動フェイルオーバーを実装するビジネスニーズがなくなりました。
プロジェクトの最初の段階は、専用チャネルを介した複製データの安全かつ高速な送信を提供するネットワークスキームの形成と実装であり、フェールオーバーの場合、バックアップサイトで作業するためのユーザーの簡単な移行です。
チャネルの編成は、プロバイダーに基づいて実行されました。プロバイダーは、既存の顧客インフラストラクチャへのバックアップサイトのルーティングと「統合」を保証するために、サービスプロバイダーへの新しいリンクが追加された「仮想スイッチ」に基づいてブランチを結合するサービスを既にクライアントに提供していました。
このようなスキームでレプリケーションが機能している場合（直接または逆）、ルーターを使用するトラフィックはサービスプロバイダーのサイトまたはクライアントの本社に送信されます。フェイルオーバーの場合、仮想マシンが配置されているクライアントのサーバーネットワークへのゲートウェイはクライアントのサイトで変更されます したがって、仮想マシンでネットワークを再構成することなく、インフラストラクチャ全体がサービスプロバイダーのサイトで機能します。
プロジェクトの第2段階は、このタスクに関連するvSphere Replication自体の構成とテストでした。 本質的に2回目のリリースで生き残ったこのテクノロジーは、標準構成で「箱から出して」正常に機能すると言う必要があります。 ただし、この実装の詳細-レプリケーション "リンク"の両側の独立したインフラストラクチャ、サービスプロバイダーのインフラストラクチャでユーザー権限を区別する必要があるため、設定を変更したり、以前は使用されていなかったテクノロジーが機能するようにしたインフラストラクチャに変更を加えたりするのにかなりの時間が必要でした
テスト中、回路の機能テストだけでなく、実際のデータのストレステストにも注意が払われました。選択されたチャネル幅でRPOに確実に準拠する必要がありました。 その結果、以前は100 Mbitに構成されていたチャネルを1 Gbitに拡張して、クライアントサーバーでの定期的なメンテナンス操作中にレプリケーション速度のマージンを提供することが決定されました（たとえば、変更のボリュームを増やすデータベースの再インデックス付けと再構築）。
プロジェクトの3番目の最終段階は、10 TBを超えるデータをサービスプロバイダーのサイトに最初に複製し、産業用システムを立ち上げることでした。 さらに、インフラストラクチャの復元の可能性を定期的にテストするために、追加のルーティングスキームが作成されました。このスキームでは、ユーザーの人工グループのみがサービスプロバイダにあるプライベートネットワークで発生したインフラストラクチャを使用します。
おわりに
現在、クラウド内のバックアップサイトは可能ですか？
基本的な答えは、はい、可能です。
これまでのところ、クライアントは、そのようなソリューションと「クラウド」のイデオロギーとの非互換性など、いくつかの仮定を考慮する必要があります。たとえば、弾力性が不十分で、場合によってはセルフサービスインターフェイスの代わりにサービスプロバイダーのサポートサービスを使用する必要があります。 一方、サービスプロバイダーは、マルチテナント環境でのテクノロジーの適用性が限られていることを考慮する必要がありますが、さまざまな仮想化プラットフォームの互換性にはまだ制限があります。
しかし、世界は止まっておらず、最初のプロジェクトの後には通常新しいプロジェクトが続きます。また、ベンダーのサポートにより、クラウドでバックアップサイトを整理する慣行がまもなく広まると確信しています。