このトピックでは、サーバー移行後に発生するデータとシステム構成の変更について説明し、調整のためのガイダンスを提供します。
Linux インスタンスの移行後のデータ整合性の問題
システム構成の変更
Server Migration Center (SMC) は、移行されたサーバーが ECS 上で正常に動作することを保証するために、以下の変更を行います。これらの変更は、ソースサーバー上のサービスには影響しません。
自動変更
理由
ブートファイルの修正
影響を受けるファイル: /boot/grub/grub.conf、/boot/grub/grub.cfg、または /boot/grub2/grub.cfg
システムディスクの UUID が置き換えられ、オペレーティングシステムがシステムディスクを検出して起動できるようになります。
自動マウント構成ファイルの修正
影響を受けるファイル: etc/fstab
これにより、インスタンスの起動後にデータディスクが正しく検出され、自動的にマウントされるようになります。
SELinux の無効化
影響を受けるファイル: /etc/selinux/config
SELinux の厳格なアクセスメカニズムによってアプリケーションが起動に失敗するのを防ぐために、SELinux は無効化されます。
ビジネスで必要な場合は、状況を評価し、移行完了後に再度有効化できます。
cloud-init 構成の修正
影響を受けるファイル: /etc/cloud/cloud.cfg
これにより、移行されたインスタンスは、クラウドプラットフォームから初期化構成を受信して実行できるようになります。
initramfs の再構築
影響を受けるファイル: /boot/initramfs*.img
これにより、virtio ドライバーなどのクラウド環境に必要なドライバーがインストールされます。
依存モジュールのインストール
ブロックレプリケーションを有効にするために、ブロックレプリケーションコンポーネントの次の依存関係がインストールされます: gcc と make。
SMC クライアントのインストールと実行
SMC クライアントのデフォルトのインストールディレクトリは
/smcです。以下の設定項目は手動での変更が必要です。
問題
原因
SSH ツールを使用してインスタンスにリモートでログインできません。
SMC は、ソースサーバーからネットワークインターフェイスカード (NIC) 構成ファイルを直接コピーします。移行後、NIC 名が Alibaba Cloud ECS のデフォルトの NIC デバイス名の要件 (通常は eth0、eth1 など) を満たさない場合があります。これはネットワークの起動に影響を与える可能性があります。構成を手動で変更し、サービスを再起動する必要があります。
次の例は、ソース NIC 名を
ens192からeth0に変更する方法を示しています。必要に応じて名前を変更してください:移行された ECS インスタンスにログインします。
イメージに移行するには、まずカスタムイメージまたは共有イメージからインスタンスを作成する必要があります。
ECS コンソール - インスタンス に移動します。上部のナビゲーションバーで、ターゲットリージョンとリソースグループを選択します。
ターゲットインスタンスの詳細ページに移動します。[リモート接続] をクリックし、[Workbench 経由で接続] を選択します。プロンプトに従ってログインし、ターミナルページに移動します。
cd /etc/sysconfig/network-scripts/を実行して、NIC 構成ディレクトリに移動します。NIC 構成ファイル
ifcfg-ens192を見つけ、sudo mv ifcfg-ens192 ifcfg-eth0を実行して名前を変更します。sudo vi ifcfg-eth0を実行します。DEVICEパラメーターをeth0に、BOOTPROTOパラメーターをdhcpに変更します。その後、ファイルを保存して終了します。
ホスト名が変更されます。
移行後、ホスト名が変更されます。再度構成できます。
元のパスワードでログインできません。
移行後にパスワードが変更されます。
イメージへの移行: カスタムイメージまたは共有イメージからインスタンスを作成する際、購入ページの [ログオン資格情報] セクションでログオンパスワードをカスタマイズできます。
ECS インスタンスへの移行: パスワードをリセットします。
ストレージとデータの変更
問題 | 理由 |
ディスクデバイス名の変更 |
|
| デフォルトでは、SMC 移行は `--sparse` 最適化オプションを使用します。このオプションにより、ターゲットインスタンス上のスパースファイルは、必要な物理空間のみを占有します。スパースファイルは、占有する物理空間よりも大きな論理サイズを持ちます。この動作は通常の使用には影響しません。 スパースファイルの完全なコピーを実行するには、`client_data` ファイルの `sync.options` パラメーターに `--no-S` を追加してから、再度移行を実行します。 |
移行後のデータ不整合 |
|
Docker 環境が失われます | SMC は、ブロックレプリケーションを使用する場合にのみ Docker 環境の完全な移行をサポートします。詳細については、「ブロックレプリケーションを有効にする際の考慮事項」をご参照ください。 |
Windows インスタンスの移行後のデータ整合性の問題
システム構成の変更
問題 | 解決策 |
ホスト名が変更されます。 | 移行後、ホスト名が変更されます。再度構成できます。 |
元のログオンパスワードが機能しません。 | 移行後にログオンパスワードが変更されます。
|
SMC クライアントのインストールと実行 | SMC クライアントのデフォルトのインストールディレクトリは |
ストレージとデータの変更
問題 | 理由 |
ドライブ文字の変更 | インスタンスが初めて起動するとき、ドライブ文字を再検出して順次割り当てます。これにより、ドライブ文字が移行前と異なる場合があります。ドライブ文字は手動で変更できます。
|
GPT パーティションが MBR パーティションになる | この変更は、パーティション上のデータの読み取りおよび書き込み操作には影響しません。互換性を最大限に高めるため、SMC は 2 TiB 未満のデータディスクを移行する際に、パーティションテーブルのフォーマットを GPT から MBR に変換します。 将来的にディスクを 2 TiB 以上にスケールアウトするには、パーティションを GPT パーティションに変換する必要があります。 |
ダイナミックディスクの構造がコピーされない | Windows は現在、ダイナミックディスク構造のコピーをサポートしていません。移行後、それらは基本ディスクパーティションになります。 |
アイコンを右クリックし、[ディスクの管理] を選択します。