すべてのリソースをリモートで展開しました
この投稿では、プロジェクトの技術面、発生した問題、および得られた結果について説明します。
目的
主な目標は、サーバーの顧客とそれに応じて機器が故障した場合に、ITインフラストラクチャと重要な企業情報の安全性を確保することです。
注：残念ながら、私は秘密保持契約の署名に関連して機器と顧客サービスの完全なリストを公開する権利はありません。 それでも、顧客のITインフラストラクチャは中規模の企業に対応していると言えます。まず、MS Exchangeメールサーバー、つまり企業にとって重要な仮想サーバーのインフラストラクチャです。
挑戦する
私たちが直面した主なタスクは、ITインフラストラクチャと重要な顧客情報の継続的なバックアップをクラウドに提供することでした。 自社の機器に障害が発生した場合、顧客はCloud4Yクラウド内の同様のITインフラストラクチャで作業できる必要があります。 主な制限は仮想環境の互換性であり、これに基づいて顧客の仮想サーバーインフラストラクチャはCloud4Yクラウドインフラストラクチャと同期されます。 私たちと顧客には互換性のある仮想化環境があったため、Asigra-VDRベースのソリューションを使用することにしました。 同期された仮想リソースの量の一般的なビューの場合：データの合計量は1.5 TBでした。
解決策
すべての作業は、顧客の技術専門家と連携してリモートで実行されました。 Asigra Backupは、増分バックアップ、圧縮、暗号化テクノロジーを備えたソリューションとして選択されました。 Asigra Remote DS-VDR Incremental Restore操作スキームが使用され、仮想マシンの変更されたブロックのみを転送できました。
仕組み
Asigra Remote DS-VDRの増分復元操作スキームは次のとおりです。
1）DSクライアント（Asigraエージェント）は、仮想マシンの変更されたブロックのみを受け取ります。
2）DSクライアントは、変更されたブロックを重複排除、圧縮、暗号化し、WAN経由でDSシステムに送信します。
3）DSシステムはDSクライアントからファイルを受信します。
4）DSシステムは、圧縮、暗号化、および重複排除の形式でファイルをバックアップストレージに保存します。
5）リモートVDRは、変更されたブロックをDSシステムから受信し、バックアップ仮想マシンの変更されたブロックを元の形式で復号化、アンパック、および更新します。
6）リモートDS-VDRは、対応するディスクパーティションに変更されたブロックを書き込むことにより、ESXiサーバーのスタンバイモードの仮想マシンから増分リカバリを実行します。
7）顧客が機器の故障に遭遇すると、Cloud4Yクラウドに展開されているバックアップITインフラストラクチャと企業データにアクセスできるようになります。
圧縮率が高いことに注意してください。1.5TBの有用なデータのボリュームで、アーカイブは約450 GBでした。
問題
軍事作戦によるドネツクの上位3つの特定のリスク：シェルが部屋に入る脅威、停電、ケーブルインフラストラクチャの破壊。 残りのリスクは典型的です。法律に違反した場合のサーバーの押収、所有権の州所有権への移転-この問題は、データセンターの即時の物理的破壊として一般化できます。
クライアントの最も一般的な問題は、通信チャネルの低下です。 近くの建物が砲撃されたため、顧客のインターネットはオフィスで絶えず姿を消しました。 さらに、UPSの持続時間はわずか8時間でしたが、定期的に電源が切れました。 これらの理由により、顧客のITインフラストラクチャをクラウドと同期するのに3日かかりました。
タスクの成功への鍵、すなわち：「クライアントの効率を確保するために、彼の重要なリソースのすべてをできるだけ早く」-は準備段階でした。
Cloud4Yの同僚の助けを借りて、Asigra DS-Client Agentが顧客の責任範囲に導入され、クライアントの仮想マシンの増分バックアップの技術を実装できるようになりました。 顧客データの構成には特に触れませんでした。 Asigra DS-Client Agentの直感的なインターフェースは、クライアントの専門家とのデモ相談の後、すべての重要なクライアント仮想サーバーを迅速にバックアップすることを可能にしました。
正常な操作を開始するための重要なコンポーネントは、仮想リソースの最初のバックアップサイクルです。これは正常に完了する必要があります。 クライアントが位置する都市では、軍事作戦が絶えず進行しているため（通信が中断され、定期的に電力が供給されない）、この段階はいくつかのアプローチで完了しました。 Asigraによって実装されたデータ重複排除と圧縮の効率により、最初のバックアップサイクルを強制し、増分モードに切り替えることができました。 参考までに、圧縮と重複排除の効率が1：4から1:10に達したと報告できます（つまり、実際の転送されたボリュームは、フルバックアップの最初の段階でさえ、元のインフラストラクチャよりも数倍少なかったため）、外部チャネルを過負荷にしないこともできましたクライアントの通信（クラウドから遠く離れた場所にある）、およびクライアントのインフラストラクチャの現在の作業を妨げることもありません。
Cloud4Y側では、Asigra VDRエージェントが並行して展開され、次のバックアップサイクルが終了するとすぐに、お客様の仮想マシンが自動的に復元されました。
バックアップの実際的な側面の要約：Cloud4Yクラウド内の仮想リソースのコピーは、最大3時間遅れて展開され、理論的には即座に作業の準備ができていました。 しかし、これは「理論的に」実用的な側面でもあり、クラウドプロバイダー側で慎重に準備する必要があります。
私たちは、VMWare vCloudDirectorクラウドインフラストラクチャ管理インターフェイスを使用しました。 このプラットフォームの主な実用上の利点は、仮想クライアントデータセンター（VDC）インフラストラクチャのフレームワーク内とvApp（仮想インフラストラクチャ）インフラストラクチャのフレームワーク内の両方で分離されたネットワークを自由に実装できることです。
自動リカバリの次のサイクルの後、仮想マシンはお客様の場所に直接配置された構成と構成で「来ます」。 つまり、最初のリカバリサイクルでは、仮想マシンのネットワークインターフェイスを、元々顧客にあったものとして規定します。 その後の顧客のインフラストラクチャの緊急アップグレードの時間を短縮するには、vCloudDirectorで仮想隔離ネットワークを事前に準備し、クライアントが使用する実際のアドレス指定を登録する必要があります。 このステップは、顧客の技術専門家との対話でも行われました。
仮想インフラストラクチャのコピーを作成する準備の最後の仕上げは、Cloud4Yクラウドの「外部」でクライアント仮想マシンアクセスを実装する仮想ゲートウェイを準備し、クライアントのクローズドインフラストラクチャのファイアウォールを実現することです。
結果
1.クラウドには、常に3時間の遅延（最大）を伴う顧客のインフラストラクチャのコピーがあります。
2.クライアントのインフラストラクチャの災害復旧は、クラウドでインフラストラクチャを起動するだけで行われます（顧客自身が仮想データセンターのvCloudDirectorインターフェイスを介して実行できます）。
3.外部クライアントサービスは、dnsに変更を加えることにより再構成されます。
その後、同じAsigraバックアップテクノロジーを使用しているクライアントは、Asigra DS Client Agentを使用して、必要に応じてインフラストラクチャを常に元の場所または新しい場所に復元できます。
その結果、非常に有害なイベント（インフラストラクチャの完全な破壊まで）が発生した場合のクライアントの緊急作業が保証されます。
ご清聴ありがとうございました。ご質問にお答えさせていただきます。
