ESXiホストへのテープ装置接続

たまに、「ESXiホストにテープ装置を接続したい」「仮想マシンから直接テープ装置にバックアップを取りたい」と言われることがあります。

そのような場合に知っておきたいのが、以下のKBです。

VMware KB: Understanding support for tape devices with VMware ESX and VMware ESXi

VMware KB: Configuring vendor-supported tape drives and media changers on ESX/ESXi 4.x and later

1つ目のKBでは、テープ装置の接続に対するVMware社のスタンスが書かれています。
VMware社のスタンスとしては、「partner supported」となります。
つまり、テープ装置やバックアップ製品のベンダー側でサポートする必要があるということです。
何か問題が発生した場合、ベンダーに問い合わせることになります。

2つ目のKBでは、テープ装置を認識させる手順が書かれています。
ここでも、以下のような文言が書かれています。

VMware does not provide support for backup tape drives and tape library devices or their functionality on ESX/ESXi hosts.

結論として、ESXiホストへのテープ装置の接続はVMware社としてはサポートを提供していないということになります。
この点を理解した上で、実際に提案/構築を検討されることをおすすめします。

テープ装置へのバックアップが必要ということであれば、外部にバックアップサーバーを構築し、そこにテープ装置を接続するというのが一般的な方法になると思います。
もしくは、Hyper-VやKVMといったハイパーバイザーを採用するという方向性も考えられます。

VMware Data RecoveryとRDM

VMware Data Recovery(vDR)を使って、RDM(Raw Device Mapping)を持つ仮想マシンのバックアップ/リストアができるのか？という内容です。

vDRのマニュアルには次のような記載があります。

Data Recovery は次の項目をサポートしていません。
(中略)
■バックアップ対象の仮想マシンでの、物理互換モードの Raw デバイス マッピング （RDM） ディスク

引用元：VMware Data Recovery のシステム要件

この記述を読んで、「仮想互換モードのRDMならいいのか？」と思ってしまった人がいたようで質問を受けたのですが、結論としては次のようになります。

①仮想互換モードのRDMを持つ仮想マシンのバックアップは可能。ただし、バックアップ時にRDMの部分がvmdkに変換される。
②リストアを実施すると、RDM部分はLazy Zeroed Thick Diskのvmdkとしてリストアされる。

確かにバックアップとリストアはできますが、元通りにはならないということになります。
個人的には、このような仕様であればRDMを持つ仮想マシンのバックアップ用途としてvDRを使うのは現実的ではないと思います。

なお、vSphere 5.1からvDRに取って代わっているvSphere Data Protection(vDP)ですが、マニュアルには次のように書かれています。

When planning for backups, make sure the disks are supported by VDP. Currently, VDP does not support the following disk types:
 Independent
 RDM Independent - Virtual Compatibility Mode
 RDM Physical Compatibility Mode

引用元：vSphere Data Protection Administration Guide

「Independentでない仮想互換モードのRDMはどうなる？」という疑問が湧きますが、おそらく同じような仕様ではないかと推測します。(機会があれば確認したいと思います。)

Site Recovery Managerの注意点③

Site Recovery Managerの注意点①ストレージ製品の選定
Site Recovery Managerの注意点②SRMを構成するコンポーネント

もはや注意点でも何でもなく、単なる構成上の要件のまとめに成り下がりつつありますが、今回はネットワークの要件をまとめます。

■SRM関連コンポーネント間の通信とポートの要件

個人的に最も分かりやすいと感じたのは、以下のブログのエントリーですね。
SRM環境の各コンポーネント同士の接続と、通信で使うポートが図示されています。
図を見るとよく分かるのですが、保護サイトと復旧サイトのSRM Server同士では通信を行なっていません。vCenter Server同士についても同様です。

SRM and VR Ports Diagrams | Proudest Monkey

公式情報となると、以下のKBが出ています。

VMware KB: Port numbers that must be open for Site Recovery Manager, vSphere Replication, and vCenter Server

■vSphere Replication使用時のネットワーク帯域

vSphere Replicationは、仮想マシンに発生したブロック変更差分を復旧サイトに送信します。保護サイトと復旧サイトはWANで接続されるケースが多いため、それほど大きな帯域を確保することは難しいと思います。

vSphere Replicationで仮想マシンのレプリケーションに使われるネットワーク帯域については、以下のKBで解説されています。

VMware KB: Calculating Bandwidth Requirements for vSphere Replication


ネットワーク帯域を算出するにあたって、以下の項目を考慮する必要があるようです。

①保護対象VM群のデータサイズの合計値
②1日で発生する変更差分率
③vSphere Replicationで設定するRPO
④WAN帯域

上記のKBでは、以下のような算出例が書かれています。

①＝1TB　②=10%　③＝1時間
とすると、1TB×10%=100GBのデータが1日で転送されます。
RPOが1時間なので、1日に24回転送されることになり、1回あたり100GB/24≒4GB程度のデータがWANを流れることになります。
4GBのデータをRPOの1時間以内に流すとなると、約9MbpsのWAN帯域が必要になります。
(4096MB×8÷3600≒9.1Mbps)
実際はオーバーヘッドが少し発生するので、10Mbpsの帯域は必要になるでしょう。
したがって、④の値が10Mbpsを超えていれば、机上ではOKということになります。

次回は少し注意点らしく、SRMを使用する際の機能上の制限事項についてまとめます。

LoginVSI 3.7 と VMware View のTips

単なる自分用のメモですが・・・。

デフォルトで入っているJapanese Profileにはtypoがあるらしく、以下で修正版を入手できます。
Analyzerの修正版も入手できるようなので、併せて入手しておきましょう。

Topic: Known issues in VSI 3.7

ワークロードを流していると、プリンタの印刷保存の箇所で止まってしまう場合があります。
View側の設定を変えるか、Launcherのプリンタをすべて削除すればよいようです。

Topic: Problem with medium workload stopping to save .xps

Outlook関係でうまくいかない場合は、以下に添付されているバッチファイルを組み合わせてみましょう。

Topic: LoginVSI outlook issue with view personamanagement


LoginVSI 3.7では、VMware View環境で使う場合、View Clientを自動実行するカスタムスクリプトが必要です。
例として、以下のようなコマンドをLoginVSIの管理コンソール上の設定で入力しておきます。

"C:\Program Files\VMware\VMware View\Client\bin\wswc.exe" -ServerURL -username <ログインユーザー名> -password <パスワード> -domainName <ドメイン名> -desktopName <プール名> -standAlone -logInAsCurrentUser False -nonInteractive

ちなみに最新版のLoginVSI 4.0では、ウィザードにしたがって必要なパラメータを入力することで、上記のコマンドが自動的に生成されます。

CSVファイルにあらかじめ複数のユーザー名やプールを定義しておくことも可能です。
サンプルや用例が以下に書かれています。

Topic: spreading users across pools

Site Recovery Managerの注意点②

Site Recovery Managerの注意点①ストレージ製品の選定

本エントリーでは、SRMの環境で必要となるコンポーネントをまとめます。

参照する情報を、冒頭にまとめておきます。
実際に提案・構築をする場合には、こちらで最新の情報を確認しておきたいです。

①VMware Product Interoperability Matrixes
②Compatibility Matrices for vCenter Site Recovery Manager 5.1
③VMware vCenter Site Recovery Manager 5.0 Performance and Best Practices

■ESX/ESXiホスト
本番サイトと災対サイトの両方に必要です。
サーバーのスペックは、本番サイトと災対サイトで完全に同一である必要はありません。
サポートされるESXiのバージョンは、情報①で調べられます。

ちなみに2013/5月現在、SRM 5.1.1をサポートするESXiのバージョンはESX/ESXi4.0以降となっています。
また、ライセンスについては、情報②で調べられます。
Standard/Enterprise/Enterprise Plusに加えて、Essentials Plusもサポート対象となっています。

■vCenter Server
本番サイト災対サイトの両方に必要です。仮想マシンとして構築することもできます。
大半のケースでは、それぞれのサイトに1インスタンスあれば十分です。
ちなみに情報①によると、2013/5月現在、SRM 5.1.1をサポートするvCenterのバージョンはvCenter Server 5.1以上となっています。

■SRM Server
本番サイトと災対サイトの両方に、SRM Serverを導入するサーバーが必要です。
仮想マシンとして構築することもできます。
ハードウェア要件は、マニュアルに書かれています。

Site Recovery Manager のシステム要件

また、SRMサーバーを仮想マシンとして構築する場合のvCPU数について情報③に記載があります。(p.6)
SRM ServerとvCenter Serverを同一システムに導入することもできますが、大規模環境では分離することが推奨されています。

SRM Server のインストール

データベースサーバー
vCenter Server と SRM Server の双方にデータベースサーバーが必要です。
サポートされているデータベースは、情報①で調べられます。

vCenter ServerとSRM Serverは同一のデータベースサーバーを使用することが可能です。
ただし、情報③では分離したほうがよい、と書かれています。(p.6)
また、情報③のp.7に書かれているとおり、データベースのサイズは、以下の要素に依存します。

・保護対象のVM数
・保護グループ数
・リカバリープランの数
・リカバリー時に発生する書き込みデータ量
・リカバリープランに追加するステップ数

■ストレージレプリケーションアダプタ(SRA)
アレイベースのレプリケーションを行う場合は、各ストレージベンダーから提供されているSRAと呼ばれるコンポーネントが必要です。
これは、SRM Serverに導入するコンポーネントです。
　　 VMware社のダウンロードページから入手することが可能です。

■vSphere Replication アプライアンス
vSphere Replicationによるレプリケーションを行う場合は、このアプライアンスを構築する必要があります。
VMwareからOVF形式で提供されているので、構築手順としてはインポートするだけとなります。
仮想アプライアンスのため、仮想マシンとして稼働します。