オペレーション「移行」: DataLine クラウドへの移行方法

約 7 年前、最初のプロジェクトはシンプルかつ気取らずにクラウドに移行されました。 仮想マシン イメージは FTP サーバーにアップロードされるか、ハード ドライブに配信されます。 次に、特別なインポート サーバーを介して、VM がクラウドにアップロードされました。

クライアントが XNUMX ～ XNUMX 日間仮想マシンをオフにしても問題ない場合 (または他にオプションがない場合)、これを実行できます。 ただし、ダウンタイムが最大 XNUMX 時間になる場合、この方法は機能しません。 今日は、最小限のダウンタイムでクラウドへの移行に役立つツールと、移行プロセス自体がどのように機能するかを説明します。

Veeam バックアップおよびレプリケーションを使用した移行

Veeam Backup and Replication は、バックアップとレプリカを作成するツールとして誰もが知っています。 これは、サイト間の移行と、クライアントをプライベート仮想化からクラウドに転送するために使用されます。 クライアントの仮想マシンは vCenter にレプリケートされ、その後エンジニアがそれらを vCloud Director に追加します。

プライマリ レプリケーションは、パワーオンされた仮想マシン上で実行されます。 合意された時刻になると、クライアント側マシンの電源がオフになります。 最初のレプリケーション以降に発生した変更を引き継ぐために、レプリケーションが再度実行されます。 この後、仮想マシンがクラウドで起動します。

通常、クライアントのインフラストラクチャでマシンの電源がオフになった瞬間から、クラウドでマシンの電源がオンになるまで、15 分以内に経過し、むしろ 20 ～ XNUMX 分かかります。

この場合、元の仮想マシンはクライアント サイトに残ります。 突然何か問題が発生した場合は、いつでもロールバックしてオンにすることができます。 この方法は、Veeam を必要としないため、クライアントにとっても便利です。

ケース1
クライアントは、VMware に基づく独自の仮想インフラストラクチャ (容量 40 TB の VM 30 台) を持っていました。 クラスターがデプロイされている機器はすでに古くなっていたため、クライアントは新しい機器を購入する手間を省き、パブリック クラウドに移行することにしました。 重要なシステムのダウンタイム要件は 30 時間以内でした。 Veeam Replication がツールとして選択されました。 もう XNUMX つの利点は、クライアントのインターネット プロバイダーが当社のデータ センターに存在しているため、優れたチャネルを編成できることです。 移行には約 XNUMX か月かかり、切り替え時のダウンタイムは仮想マシンのグループごとに最大 XNUMX 分でした。

Veeam Cloud Connect で移行する

Veeam Cloud Connect は、仮想マシンのレプリケーションを設定し、サービス プロバイダーのクラウドでレプリカを起動するのに役立つツールです。 にアップデートした後、 2019 年に、仮想マシンを vCloud Director に直接レプリケートできるようになりました。 唯一の条件は、クライアント側で Veeam Backup and Replication がバージョン 9 以上でデプロイされている必要があることです。つまり、(詳細なバージョン) ここで)、プロセス全体は次のようになります。

vCloud Director では、必要なリソースとネットワークを備えた組織が作成されます。 Veeam Cloud Connect では、アカウントを作成し、クライアントは Veeam B&R からアカウントに接続し、DataLine プロバイダーと組織を選択し、レプリケーションのタスクを構成します。 このような移行中のダウンタイムは 15 ～ 20 分以内であるという事実に加えて、クライアントはプロバイダーのテクニカル サポートに一切依存せず、プロセス全体を独立して管理します。つまり、レプリケーション タスクの作成、レプリケーション自体のオフ、マシンを削除し、新しいサイトで起動します。

ケース2
移行が計画されていたクライアントのインフラストラクチャはベラルーシにありました。 インターネット チャネルが 90 Mbit/秒であるにもかかわらず、合計 27 TB の 100 台の VM を転送する必要がありました。 バックアップを作成してすぐにクラウドにアップロードすると、VM によっては数日かかる場合があります。 この間、VM 上で大きなデルタが増加し、マシンのパフォーマンスに悪影響を及ぼす可能性があり、さらに悪いことに、データストア上のスペースが不足する可能性があります。 私たちは次のように進めました。まず、クライアントはローカルの完全バックアップを作成し、そのコピーを Veeam Cloud Connect 経由でクラウドに転送しました。 次に、増分を作成してクラウドに転送しました。 元の仮想マシンは引き続き実行されます。 VM をシャットダウンした後、クライアントはさらに増分を行い、それをクラウドに転送しました。 私たちの側では、完全バックアップから仮想マシンをデプロイし、それに 2 つの増分をロールしました。 このスキームにより、最終的にサイトに切り替える際のダウンタイムを XNUMX 時間に最小限に抑えることができました。

VMware vCloud の可用性を使用した移行

今年 3.0 月、VMware は vCloud Availability XNUMX をリリースしました。これにより、異なるクラウド間 (vCloud Director - vCloud Director) およびプライベート クライアント仮想化スタンドからクラウド (vCenter - vCloud Director) への仮想マシンの移行が可能になります。 主な利便性は、vCloud Director インターフェイスとの統合です。 これにより、レプリケーション管理プロセスが大幅に簡素化され、スイッチオーバー時のダウンタイムが最小限に抑えられます。

このツールを使用して、クライアントの 18 つをモスクワのクラウドからサンクトペテルブルクのクラウドに移行しました。 合計容量 14 TB の 12 台の仮想マシンを転送する必要がありました。 サンクトペテルブルクのクラウド内にクライアント用の組織が作成され、必要なネットワークが組織されました。 次に、クライアントは vCloud Director インターフェイスから vCloud の可用性設定に移動し、レプリケーション ジョブを作成し、都合の良い時間にサンクトペテルブルクのサイトに切り替えました。 切り替え時のダウンタイムは XNUMX 分でした。

サンクトペテルブルクとモスクワの DataLine クラウド間の移行スキーム。

vCloud Availability には、クライアントのサイトからクラウドに VM を移行するメカニズムがあります。 これを行うには、特別な vCloud Availability アプリケーションがクライアントの vCenter にデプロイされます。 簡単なセットアップの後、クラウドに接続し、移行タスクを構成します。 また、クライアントはプロセス全体を独立して管理するため、移行時間は最小限に抑えられます。

仮想マシンをプライベート インストールからクラウドに移行するためのスキーム。

VMware vCloud Availability には他にも多くの使用例があります。それらについては、近いうちに別の記事で説明します。

移行の準備

ツールを選択して実際に移行を開始するには、次の点を決定する必要があります。

どこから移住するのか？ プライベート ソリューションから移行する場合は、ツールを完全に自由に選択できます。 プロバイダーから離れる場合は、さらに複雑になります。 おそらく、XNUMX つのプロバイダーのインフラストラクチャをリンクし、VM をドラッグ アンド ドロップするだけでは、セキュリティ上の理由から機能しません。 時々、クライアントが拒否しようとしているプロバイダーが悪戯を始めて、時間が止まってしまうことがあります。 VM をディスクや FTP にアップロードするか、アプリケーション レベルで移行するという、昔ながらの方法でプロバイダーから離れることができます。 後者の名前は条件付きでこんな感じです。

ケース3
ヨーロッパのプロバイダーからクライアントの SAP システム (容量 34 TB の 54 台の VM) を移行する必要がありました。 クライアントにはクラウド内のリソースが割り当てられました。 ネットワーク接続は、私たちとヨーロッパのプロバイダーのインフラストラクチャとの間で組織されました。 アプリケーション サーバーが再デプロイされ、必要な構成がロールオーバーされました。 大規模なデータベースは、バックアップをクラウドにアップロードすることで移行されました。 次に、当社のサイトと元のサイトのデータベース間でレプリケーションを構成しました。 合意された時期に、私たちはクラウド内のデータベースに切り替えました。

データ量とインターネット チャネル。 通常、クライアントには、メモリ、CPU、ディスクのパラメータを使用してシステムごとにアップロードを提供するよう依頼します。 チャネルが仮想マシンのレプリカまたはバックアップを直接送信するのに十分であるかどうかを評価します。

許容できるダウンタイム。 システムが異なると、それに応じて仮想マシンも異なり、ビジネスの重要度に応じて異なる場合があります。 通常、クライアントには移行中のダウンタイムに関する既製の要件があり、これに基づいて適切なツールと移行計画を選択します。 たとえ軽微なダウンタイムであってもクライアントのエンドユーザーに気付かれないように、最後のスイッチオーバーは夜間または週末にスケジュールするよう努めています。

このデータに基づいてツールを選択し、移行そのものを開始できます。 次に何が起こるかです。

1. ネットワーク接続のセットアップ。 当社は、クラウドとクライアントのインフラストラクチャ間のネットワーク接続を組織します。 仮想マシンはこのネットワーク経由でコピーされます。 Veeam Backup and Replication が使用されている場合、これは専用チャネルであり、VPN チャネルであることはあまりありません。 Veeam Cloud Connect の場合、すべてがインターネットまたは同じ専用チャネル経由で行われます。

   次に、クラウド内の VM 用にネットワークが構成されます。 車は通常、グループで XNUMX 日以上移動します。 VM が私たちに持ち込まれて起動されたら、元のサイトにまだ残っているマシンと通信する必要があります。

2. 移行スケジュール。 車の台数が多い場合は、複数のグループに分けてまとめて輸送するのが合理的です。 私たちはクライアントと協力して、いつ、どのマシンを移動するか、および最終的な複製と新しいサイトへの切り替えをいつ実行するかを指定する計画に同意します。
3. 移行をテストします。 テスト仮想マシンを移行し、サイト間のネットワーク接続、ソース サイト上のマシンに対する仮想マシンの可用性、アカウント権限など、すべてが正しく構成されているかどうかを確認します。 このテストは、戦闘移行段階での障害を回避するのに役立ちます。

以上です。 コメントで質問し、移行の経験について教えてください。

出所： habr.com