仮想サーバーの移行計画を策定する IBM Cloud VPC

仮想マシン（ VM ）の依存関係をマッピングし、ベロシティを見積もり、アプリケーションスタックの切り替え期間をスケジュールすることで、 IBM Cloud VPC への移行フェーズを計画します。

依存計画

移行の波を開始する前に、以下のアプリケーション依存関係をマッピングする必要があります：

ティアベース：

  • ウェブ・ティア → アプリ・ティア
  • アプリ層 → データベース層
  • データベース層 → 共有ストレージとサービス

クロスアプリケーション：

  • 認証
  • モニター
  • Backup
  • ログ集計
  • DNSとNTP

発見のためのツール：

  • VMware vRealize Network Insight ( ) vRNI
  • アプリケーション依存マッピングツール
  • ネットワーク・フロー分析
  • アプリケーション所有者によるマニュアル文書

各仮想サーバーについて、以下の情報を移行計画に記録します：

  • インバウンドの依存関係
  • アウトバウンドの依存関係
  • 共有リソース

テスト移動波のデザイン

最初の移民の波は、テスト（パイロット）波である。 テストウェーブを成功させるためには、以下の情報を守る必要があります：

仮想サーバーの適切な表示

  • シングルディスクの Linux 仮想サーバー
  • マルチディスクの Linux 仮想サーバー
  • シングルディスクWindows仮想サーバー
  • マルチディスクWindows仮想サーバー
  • 依存関係を持つアプリケーション（3層アプリ）

最小リスク」のオプションを使用する：

  • 本番環境以外での移行を実施する。 あるいは、大きなメンテナンスウィンドウがある本番環境を使う。
  • アプリケーションのロールバック手順を知る。

完全な移行を行う：

  • 選択した方法の完全なエンド・ツー・エンド・テスト
  • 移籍時期と推定時期
  • テストでは見つからなかった問題の発見

移籍の成功基準：

  • すべての仮想サーバーが正常に起動
  • アプリケーションが正しく機能する
  • ネットワーク接続の確認
  • ベースライン以上のパフォーマンス
  • データの損失や破損がない
  • 移行に関する文書は完全かつ正確である

ウェーブ・ストラクチャー・ガイドライン

サブネットベースのグループ化：

VMware、VPC間でサブネットを拡張することはできません。 つまり、次のようなアクションが必要なのだ：

  • 仮想サーバーをサブネットでグループ化する
  • サブネット全体を一度に移行したり、一部の仮想サーバーのIPを変更する必要があることを把握できます
  • サブネットとVPCサブネットのマッピングを早めに計画する

多階層アプリケーションのためのアプリケーションスタックのグループ化：

  • 可能であれば、スタック全体を一度に移行する。
  • 移行規模が大きすぎる場合は、まずデータベースから移行し、次にアプリから移行する、というようにする。
  • IBM Cloud Transit Gateway を使用して、移行済みティアと未移行のティア間の接続性を維持します。

依存性を考慮したシーケンシングのためのアプリケーションスタックのグループ化：

  • インフラサービスを最初に移行する（DNS、モニタリング、バックアップ）。
  • 必要なアプリケーションの前に共有サービスを移行する。
  • 各波の影響を考慮し、失敗した場合の影響も考慮する。

並列マイグレーション機能：

方法3 ライブ・ネットワーク転送（スケールに推奨）が優れて いる：

  • 複数のワーカー仮想サーバーインスタンスをプロビジョニングする
  • 複数の仮想サーバーを同時に移行
  • ネットワーク帯域幅とワーカーの仮想サーバーインスタンスリソースによる制限
  • 典型的な例：ワーカー仮想サーバーインスタンスあたり4～8件の同時マイグレーション

テスト波の構成例

次の例は、50 台の仮想サーバーの移行を示しています。

ウェーブ0（テスト）仮想サーバー5台

  • 1x シングルディスク Linux (メソッド1テスト)
  • 1x マルチディスク Linux (方法2テスト)
  • 1x シングルディスクWindows（sysprepを使った方法1）
  • 1x マルチディスク・ウィンドウズ（ virt-v2v を使った方法2）
  • 1x 3層テストアプリ（メソッド2と3、フルスタック）

第1波（インフラ）仮想サーバー8台

  • DNS サーバー
  • モニター・サーバー
  • ジャンプホストまたは要塞サーバー
  • VPCファイルストレージに移行した共有ファイルサーバー

ウェーブ2（アプリケーションA）：12台の仮想サーバー

  • データベース層（仮想サーバー3台）
  • アプリ層（仮想サーバー6台）
  • ウェブ層（仮想サーバー3台）
  • サブネット 10.50.10.0/24 → VPCサブネット 10.240.10.0/24

第3波（アプリケーションB）：10台の仮想サーバー

  • データベースとアプリの複合ティア（4仮想サーバー）
  • ウェブ層（仮想サーバー6台）
  • サブネット 10.50.20.0/24 → VPCサブネット 10.240.20.0/24

第4波（アプリケーションC）：15台の仮想サーバー

  • 大規模な多階層アプリケーション
  • サブネット 10.50.30.0/24 → VPCサブネット 10.240.30.0/24

カットオーバー期間の設計

それぞれの波には、明確なカットオーバー・ウィンドウが必要だ。

カットオーバー前のスケジュール（7日から移行日まで）：

  • ウェーブプランとランブックの最終決定
  • Transit Gateway 接続の確認
  • ワーカー仮想サーバーインスタンスとターゲットボリュームのプロビジョニング
  • カットオーバーウィンドウを関係者に伝える
  • 移行するサービスのDNS TTLを減らす
  • メンテナンスのお知らせ

カットオーバーの実行 ( T-0 )

以下の情報は、カットオーバーフェーズについて説明したものである。

フェーズ1：一時中断と移行（0～4時間）

  1. 接続を切断する - ロードバランサーから接続を切断し、セッションが閉じるのを待つ。
  2. アプリケーションの停止
  3. 仮想サーバーをシャットダウンするか、ライブISOから起動する
  4. ディスク転送開始
  5. 移籍の進捗状況を監視する

第2段階：変換と提供（4～6時間）

  1. 必要に応じて virt-v2v を実行し、ドライバーを注入する
  2. ディスク転送の検証（fdisk、チェックサム）
  3. バッファをフラッシュし、ボリュームをワーカーから切り離す
  4. 移行したボリュームから仮想サーバーインスタンスを作成する
  5. 仮想サーバーインスタンスを起動する

フェーズ3：検証とカットオーバー（6～8時間）

  1. 仮想サーバーインスタンスを起動し、必要に応じてVNCコンソールからアクセスする
  2. ネットワーク構成を確認し、必要に応じて調整する
  3. 申し込み開始
  4. 機能テスト（アプリケーションの動作、データへのアクセス）
  5. ロードバランサーへの追加とDNSの更新
  6. アプリケーション・パフォーマンスのモニター

第4段階：安定させる（8～12時間目）

  1. 問題の監視
  2. 外部接続の確認
  3. アプリケーションのログを確認してエラーがないか確認してください
  4. パフォーマンスをベースラインと比較する

マイグレーション・ロールバックの決定ポイント

  • フェーズ 1 の後: 簡単なロールバック ( VMware 仮想サーバーを再起動)
  • フェーズ 2 以降：難易度「中」（仮想サーバーインスタンスの破棄、 VMware 仮想サーバーの再起動、DNS のリストア）
  • フェーズ3以降：困難（VPCに新しいデータがある可能性があり、 VMware へのデータ同期が必要）

設計の推奨ゴー、ノーのチェックポイントを明確に定義する。 例:

  • フェーズ 2 の後、仮想サーバーインスタンスの 20% 以上が起動に失敗したら、ロールバックを実施する。
  • フェーズ 3 の後、アプリケーションの機能テストが失敗したら、ロールバックを実施する。
  • フェーズ4の後、パフォーマンスがベースラインより30％以上低い場合は、調査するが、ロールバックは実施しない。

移動速度の推定

仮想サーバーごとの移行時間を見積もり、現実的なウェーブサイズとウィンドウを計画します。 以下のスケジュールは達成可能だが、実際の移行の前に PoC。

時間の構成要素：

方法1-2を使用した輸出時間の見積もり：

  • 100GBの仮想サーバー20～30分
  • 500GBの仮想サーバー2～3時間
  • VMware ストレージ性能に依存

移動時間の目安

  • ネットワーク100 GB = 20-25分
  • ネットワーク500 GB = 90-120分
  • 圧縮を使用する方法3：圧縮により2～3倍速くなることが多い

による変換時間の見積もり virt-v2v:

  • Linux:5～10分
  • ウィンドウズ10～20分
  • ワーカー仮想サーバーインスタンスのパフォーマンスに依存

プロビジョニング時間の見積もり：

  • 仮想サーバーインスタンスの作成5分
  • ブートとネットワーク設定5～10分

時間の見積もり例：

小規模 Linux 仮想サーバー（1 ディスク、100 GB、方法 3）：

  • 輸出なし：0分
  • 圧縮を伴う移送：25分
  • 変身：5分
  • プロビジョニング：10分
  • 合計：40分

ディスク4本、合計1TBを使用した方法2による大規模なWindows仮想サーバーの時間見積もり：

  • 輸出：3時間
  • 移動：2時間
  • 変身 ( virt-v2v )：20分
  • プロビジョニング：10分
  • 合計： 5.5 時間

方法3,4の両方の時間見積もりによる並列移動効率：

  • 4x 並行して移行される100GBの仮想サーバー
  • 各30分
  • 波の総時間：35分（スタートアップとシャットダウンの時間を含む

4x 100GBの仮想サーバーを連続的に移行する場合と比較すると：

波の合計時間は120分

パラレリズムは、このシナリオで3倍から4倍の改善をもたらす。