クラウド移行で資産をレプリケートする

[アーティクル]
04/15/2024

オンプレミスのデータセンターは、サーバー、アプライアンス、ネットワークデバイスなどの物理的資産を保存します。しかし、サーバーなど物理的な資産はシェルにすぎません。実際の価値はサーバー上で実行されるバイナリからもたらされます。データセンターは、移行するプライマリバイナリであるアプリケーションとデータが原因で存在します。オペレーティングシステム、ネットワークルート、ファイル、セキュリティプロトコルなどのデジタル資産やバイナリソースが、アプリケーションやデータストアを支えています。

レプリケーションプロセスは次のステップで構成されています。

レプリケーション: さまざまなバイナリの特定時点のバージョンをコピーします。
シード処理: バイナリスナップショットを新しいプラットフォームにコピーし、新しいハードウェアにデプロイします。バイナリのシード処理されたコピーは、古いハードウェア上の元のバイナリとまったく同じように動作します。しかし、バイナリのそのスナップショットは古いため、元のソースとの整合性がありません。
同期: 新しいバイナリと古いバイナリを揃えます。このプロセスにより、新しいプラットフォームに格納されているコピーが継続的に更新されます。選択した昇格モデルに従って資産が昇格させられるまで、同期は継続します。昇格した時点で、同期は停止します。

レプリケーションの前提条件

レプリケーションの前に、準備フェーズと評価フェーズでアクティビティを完了する必要があります。レプリケートを開始するには、次のものが必要です。

移行したリソースのサブスクリプション。
バイナリコピーを移動する移行ツール。
レプリケーションと同期のために準備されたソースバイナリ。それらの正確な構成は、移行ツールによって異なります。準備には、評価フェーズで見つかったレプリケーションの問題の修復が含まれます。レプリケーションを開始する方法の例については、「エージェントレス移行を使用した VMware からの移行」を参照してください。
ワークロードアーキテクチャの設計手順で特定したワークロードの依存関係。これらの依存関係には、レプリケートされた仮想マシンをデプロイするリソースグループ、仮想ネットワーク、サブネットを含めることができます。詳細については、「サポートサービスの展開」を参照してください。

レプリケーションのリスク: レプリケーションの物理的特性

バイナリソースの新しい宛先へのレプリケーションを計画して実行するときは、次の基本的な法則を考慮します。

光速: 大量のデータを移動するときは、ファイバーが最も高速なオプションです。しかし、ファイバーケーブルがデータを移動できるのは光のわずか 3 分の 2 の速度です。瞬間的に、または無制限にデータを複製する方法はありません。
WAN パイプラインの速度: データ移動の速度よりも重要なのは、アップリンク帯域幅です。会社の既存の WAN がターゲットのデータセンターに伝送する 1 秒あたりのデータ量によって、アップリンク帯域幅が定義されます。
WAN 拡張の速度: 予算が許す場合は、会社の WAN ソリューションにより多くの帯域幅を追加できます。しかし、追加のファイバー接続を調達し、準備して、統合するのに数週間から数か月かかる可能性があります。
ディスクの速度: ソースバイナリとターゲットの宛先の間に無限のデータ速度と無限の帯域幅制限がある場合でも、物理特性ではレプリケーションが制限されます。データレプリケーションは、ソースディスクがデータを読み取ることができるのと同じくらい迅速に行われます。
人間の計算速度: ディスクや光の移動は人間の意思決定プロセスより高速です。人の集団が共同作業をして共に意思決定するときは、結果が出るまで時間がかかります。レプリケーションでは人間の計算に関連する遅延は克服できません。

これらの物理法則はそれぞれ、移行計画によく影響を与える次のリスクを引き起こします。

レプリケーション時間: レプリケーションには時間と帯域幅が必要です。バイナリの複製にかかる時間を反映した現実的なタイムラインを計画に含める必要があります。

"使用可能な移行帯域幅の合計" は、より優先度が高い他のビジネスニーズが使用しないアップバウンド帯域幅の量です。アップバウンド帯域幅は、メガビット/秒 (Mbps) またはギガビット/秒 (Gbps) で測定されます。 移行ストレージの合計は、移行する資産のスナップショットを保存するために必要なディスク容量の合計で、ギガバイト (GB) またはテラバイト (TB) で測定されます。

初回の推定時間を決定するには、移行ストレージの合計を利用可能な移行帯域幅の合計で除算します。ビットからバイトへの変換に注意してください。次の項目では、時間のより正確な計算について説明します。
ディスクドリフトの累積的な影響: レプリケーションの時点から資産を実稼働に昇格するまで、ソースバイナリと複製先バイナリの同期を維持する必要があります。

バイナリにドリフトがあると、バイナリへの変更を繰り返しレプリケートする必要があるため、追加の帯域幅を消費します。同期中は、移行ストレージの合計の計算に、すべてのバイナリドリフトが含まれます。資産を運用に昇格させるまでの時間が長くなるほど、より多くの累積ドリフトが発生します。同期する資産が多いほど、より多くの帯域幅が消費されます。同期状態の資産ごとに、使用可能な移行帯域幅の合計が少なくなります。
ビジネス変更までの時間: 同期時間は、移行速度に累積的な悪影響を及ぼします。移行バックログの優先順位付けと、変更通知計画の事前準備は、移行の速度を決定的に左右します。

移行作業中、ビジネスと技術の整合性にとって最も重要な試金石は、昇格のペースです。資産を運用環境に昇格させる速度が速いほど、ディスクドリフトが帯域幅に与える影響は少なくなります。また、次のワークロードのレプリケーションにより多くの帯域幅と時間を割り当てることができます。

データ要件がネットワーク容量を超える場合の計画

クラウド移行では、資産をレプリケートし、既存のデータセンターとクラウド間をネットワーク経由で同期します。さまざまなワークロードの既存のデータサイズ要件は、ネットワーク容量を超える可能性があります。このようなシナリオでは、移行プロセスはきわめて低速になったり、場合によっては完全に停止することがあります。

評価、初期レプリケーション、またはテストで容量の問題が特定された場合は、Azure Data Box を使用して独立したデータストアを転送することを検討してください。これらのアプローチを使用して、ワークロードの移行の前にクラウドへ大量のデータを配布することができます。

Microsoft 以外の一部のパートナーソリューションでは、移行に Data Box も使用されます。これらのソリューションでは、大量のデータをオフライン転送を介して移動できますが、後からネットワーク経由でより低いスケールで同期します。

次のステップ

管理の準備