web-dev-qa-db-ja.com

VMテンプレートをvSphereデータセンター間でコピーするにはどうすればよいですか?

背景/環境アーキテクチャ:

現在の$corp_overlords$の環境は、技術的に優れたホームオフィスハブ(SAN、bladecenter/bladesystem ESXiクラスター、ファイバーインターネット接続など)が多数に接続されたハブアンドスポークモデルでセットアップされています。リモートサイトのスポークはそれほどうまく機能せず、通常は単一のESXiホストサーバーを含み、T1経由でホームオフィスハブに接続します。リモートサイトで発生するすべてのトラフィックは、「MPLSネットワーク」(実際には、リモートサイトをホームオフィスに接続している単なるT1)を介してホームオフィスにルーティングされます。

ホームオフィスのSAN上には、VMの展開元として作成したいくつかのVMテンプレートがあります。これらは、vSphereデータストアであるNFSボリュームに保存され、vSphere内のホームオフィスデータセンターオブジェクトに接続されます。

各リモートサイトには、対応するvSphereデータセンターオブジェクトがあり、リモートサイトに物理的に配置されているESXiホストサーバー上のローカル接続ストレージに接続されているデータストアオブジェクトが含まれています。

これらのVMテンプレートはNFSボリューム上に存在するため、約40 GiB(シンプロビジョニング)を占有します。 NTFS(またはLinux FS)上のファイルとして、それらは〜100 GiBを占有します。

質問:

サイト間で、この40 GiBのシンプロビジョニングされたデータ(ファイルシステム領域の100 GiBを占める)をどのようにコピーすればよいですか?

私には約5日間の制限があり、「通常のネットワークトラフィック」に(特に)干渉することはできません。

9
HopelessN00b

ホスト間でテンプレートを直接コピーするためにovftoolを使用するのはどうですか?

これは以前にVMに使用したことがあり、かなりうまくいきます。それがテンプレートでも機能するかどうかはわかりませんが、機能しない場合は、テンプレートを一時的にVMに変換してコピーすることができます。

説明、例はこちら

Ovftoolを使用してテンプレートを.ovfパッケージに変換することもできます。これは非常にコンパクトなはずであり、パッケージをデータセンター間でBITSまたはFTPまたはSCPまたは任意のプロトコルで転送します。 。

13
VFrontDe

オプション:

私の見方では、私は3つの可能なアプローチを持っていますが、ここにいる誰かが私を指摘することができるより良いものがないことを心から望んでいます。 (理想的には、40 GiB ofactualdata)と、再開可能な「バックグラウンド」のみを移動させているまたは速度を絞った方法。)

  1. VSphereクライアントを介して、データストア間でファイルをコピーします。
    • 利点:100 GiBではなく、40 GiBのみを移動します。
    • 欠点:その他すべて-再開不可、バックグラウンド/スピードスロットルなし、インターフェイス[〜#〜] sucks [〜#〜]

  2. BITS を使用してWindowsゲスト間でファイルをコピーします
    • 利点:再開可能なバックグラウンド転送。
    • 短所:存在しないデータの〜60 GiBの移動。
    • ボーナス:PowerShellを使用します。 <3
    • ダブルシークレット 保護観察 おまけ:PowerShell Remotingでは、これを1つのコマンドで実行できます。

  3. SCP を介してESXiホスト間でファイルをコピーします
    • 利点:速度が制限され、再開できる可能性があります。
    • 短所:移動〜60 GiB実際には存在しないデータ。バックグラウンド転送ではありません。
    • おまけ:首ひげ。再開可能性のための余分なひげ。

  4. サーバーの障害についてより適切なオプションが提案されています。
    • 利点:存在するデータの〜40 GiB)のみを移動する、再開可能な高速スロットルのバックグラウンド転送。
    • 短所:賞金の授与は担当者にかかります。
    • おまけ:新しいことを学び、職場でServerFaultをプレイすることを正当化します。
8
HopelessN00b

ここにあなたのためのやや興味深いアイデアがあります。最初のシードには役立ちませんが、Crashplanの無料の製品のようなものを使用すると、テンプレートの作成に役立つかどうか疑問に思います。

https://www.code42.com/store/

重複排除とブロックレベルの差分を行うため、本社の1台のローカルサーバーに「シーダー」としてインストールし、各スポークサーバーに(VMと思います)として)インストールできます。 HQサーバー上のテンプレートが保存されるフォルダーのみを含むようにバックアップをセットアップします。複数の宛先(各「スポーク」など)にバックアップすることもできます https://support.code42.com/CrashPlan/Latest/Getting_Started/Choosing_Destinations

手順(両側にCrashplanアプリを設定した後)は次のように機能します。

  1. テンプレートをデータストアから「シード」サーバーに、Crashplanが監視しているディレクトリにコピーします。ギガビットネットワークではこれには少し時間がかかるかもしれませんが、悪くないはずです。
  2. クラッシュプランは、ファイルを監視し、スポーク/レシーバーへのバックアップを開始する必要があります。これには明らかにかなり時間がかかります。
  3. 最初のシード/バックアップの後、将来のテンプレートが変更されたときに、それらを実際のデータストアから「シード」サーバーのディレクトリにコピーします。Crashplanが監視し、元のテンプレートのコピーを上書きします。その後、クラッシュプランは重複排除を行い、ブロックレベルの変更のみをスポークに反映します。

ただのアイデア...これらのファイルだけの貧しい人の重複排除/ブロックレベルのレプリケーションとして機能するかどうかを調べてみるのは興味深い道かもしれません。

5
TheCleaner

私はこのタイプの移動をいくつかの方法で行いましたが、あなたが説明したことを考えると...

FedExまたはUPS、ひねりを加えた...

使用しているサーバーはHP ProLiantおよびDell PowerEdgeサーバーであることを知っています。 VMwareは、データストアターゲットとしてのリムーバブルデバイス(USBなど)を適切にサポートしていません。ただし、メインサイトで単一のドライブRAID 0論理ドライブ(HPで言えば)を使用すると機能します。 HPおよびDellシステムでローカルに接続されたディスクを追加および削除し、それをデータストアを転送する手段として使用できます。

テンプレートなので、vCenter経由でローカルディスクに移動/コピーできます。ディスクを発送します。受信スタンドアロンサーバーに挿入します。アレイとデータストアは、ストレージシステムの再スキャンによって認識されます。データをコピーします。利益。

これは、vSphereレプリケーションのコピーをシードする手段としても使用しました。24時間の差分は、複数の完全同期よりも管理がはるかに簡単だからです。

5
ewwhite

これは、この種のシナリオでかなり頻繁に使用する方法です。データストアに保存されているVM内からデータストア自体にファイルをアップロードしているため、直感に反するようです。ただし、これにより、転送の実行方法をより詳細に制御できます。

  • WinRARまたは7Zipを使用して、テンプレートを1GB〜2GBのチャンクに分割します。
  • 各リモートサイトのESXiサーバーにVMを作成します。最小限のリソースが必要です。これは単なるステージング領域です。
  • これらの各VMに、転送するデータを保持するのに十分な大きさのVMDKを接続します。
  • 任意のOSと転送ツールをインストールします(これにはSFTPサーバーを使用します)。
  • RARされたテンプレートをステージングVMにアップロードします。
  • RAR化されたテンプレートを解凍します。
  • VSphereまたはWeb UIを使用して、ステージングVMからESXIデータストアにテンプレートをアップロードします(これはFAST転送になります)。

長所:

テンプレートを細かく分割することで、転送中にデータが破損するリスクを軽減できます。 (ファイルが破損した場合は、40GBファイル全体ではなく、RARのその部分のみを再アップロードする必要があります。)

転送するのは40GBのみです(RAR処理するとさらに圧縮されるため、おそらくそれより少なくなります)。

選択したOS内で転送を行うと、転送ユーティリティを選択できます。

短所:

ステージングVMを作成する必要があります。私はこれを簡単にするために、1GB未満で、ベアOSインストール+ SFTPサーバーだけのテンプレートを事前に作成します。

40GBテンプレートの圧縮/解凍には、CPUリソースによって異なりますが、最大4〜6時間かかります。

3
jlehtinen

私はこの同じ問題に何度も対処しましたが、約半分の時間で、離れた場所に新しいマシンを構築するだけの方がはるかに良いと感じています。これは、私が「テンプレート」マシンと呼ぶものに特に当てはまります。それの私のバージョンはかなり基本的なマシンです。あなたのバージョンは少し違うかもしれません。

1
Keith Stokes