バックアップとDRをうまく使い分けよう（VDPとvSphere Replicationの違いについて）

仮想化基盤で悩むのはやはりバックアップですね。
VMware Data Protection Advance (通称VDPA）が無償化されましたが、やはり細かいところまでのバックアップ設定は、商用のサードパーティーバックアップソフトに比べて見劣りすることろがあるのは事実です。

そんな時に、vSphere Replciationをバックアップソフト代わりに使うことで解決できるケースもあります。

バックアップとして見たときに、VDPAとvSphere Replicationの特徴を見てみましょう。

	メリット	デメリット
VMware DataProtection Advance	・ファイルベースでのリカバリが可能 ・バックアップファイルの圧縮と重複除外機能が搭載される ・長期バックアップが可能	・VA内に接続されたVMDK内にバックアップファイルが保存される 　（別途Avamer/DataDomain連携は可能) ・細かいスケジュール設定ができない ・バックアップした仮想マシンをすぐに起動できない ・仮想マシンが多い場合1日のジョブですべてのバックアップが終わらない可能性がある
vSphere Replication	・常に差分で同期されるため、最短15分前までリカバリが可能。 ・24世代のRPOを元に希望した場所で即仮想マシンを起動可能 ・短期間のバックアップが可能	・データーは圧縮されずに保存される ・ファイルベースでのリカバリができない ・バックアップした仮想マシンを停止しないと、バックアップした仮想マシンを起動できない。

VDPは、圧縮されて重複除外されるのがメリットですが、スケジュールに従ってバックアップをとるため、直前に戻すことやバックアップにかかる時間に関してはデメリットがあります。
vSphere Replicationはその点、常に同期されるため、バックアップジョブという存在無く常に最新のデーターが保存されるため俊敏性に優れています。

これは言い換えると、バックアップとDRの違いそのものでもあります。

バックアップとDRは、リカバリの時間やどの時点でのバックアップが必要かという話しで選択が変わってきます。

バックアップから即リカバリして使いたいといった場合は、極力直前の状態まで戻して使いたいといった場合は求められる状況が異なるということをしっかり押さえておく必要があります。

vSphere Replicationなら、24世代のスナップショットを保持可能（最大24時間のRPOで24日間）

vSphere Replicationについて(3) vSphere6上で稼働するハードウェアバージョンV11の仮想マシンは、vSphere5.5上でレプリケート可能？

前回は物理的な要因で仮想マシンが構成することができないスペックのものをレプリケート＆稼働できるかを確認しました。

では、vSphere6とvSphere5.5が混在している環境で、vSphere6からサポートされた仮想マシンバージョンv11の仮想マシンを、vSphere5.5の環境下でレプリケート＆稼働できるのかを確認してみました。

結果から申しますと、レプリケートはなんらもんだ無く成功します。

では、実際にリカバって見ましょう。

リカバリ先のホストを選択する画面で、

チェックに引っかかってしまいました。vCenter Server 6で管理をしているため、レプリケートはするが、実際にリカバリする際、その仮想マシンを稼働させるホスト選択時に仮想マシンバージョンがチェックされるという動作のようです。

レプリケートされた側のストレージの中を見ると、以下のようになっています。

これをみるとわかるように、VMDKはそのままに、vmx等のファイルは拡張子の後ろに管理バージョン的なものが付与されています。このvmxのファイルの中身を開くと、普通のvmxファイルの為このファイルを直接編集して仮想マシンバージョンの値（virtualHW.version）を、10等にするとvSphere 5.5でも動作するのかもしれませんが、さすがにこれはサポート対象外ですので、仮にできたとしても自己責任にてどうぞ。

ということで、vSphere5.5のホストに接続されDataStoreにvSphere6でサポートされたハードウェアバージョン１１の仮想マシンを、vSphere Replicatinでレプリケートさせることは可能です。但し、実際にリカバリする際に、リカバリする仮想マシンを稼働させるホストを選択する際にバージョンのチェックが行われ、今回の場合ですとチェックに引っかかり、vSphere5.5のホスト上でのリカバリはできないという結果になりました。

vSphere Replicationでのレプリケーションの際には、仮想マシンバージョンの事前確認をお忘れ無く。（いざというときのDRですので・・・）

vSphere Replicationについて(2) 本番サイトで8vCPUの仮想マシンをDRサイトで2コア物理CPUしか無い環境で、レプリケート＆稼働するのか？

前回の項でvSphere ReplicationでDRサイトを構成する場合、本番サイトとDRサイトで同じスペックのマシンやストレージを用意する必要は無いと記載しました。
では、本番サイトにXeon-E5-2670などのハイエンドなCPUを搭載し、DRサイトにXeon E5220など一昔前のサーバーを利用したいケースが有るかと思います。

この場合、E5-2670は、8コア（ハイパースレッドで16コアに見える） E5220は、2コア （ハイパースレッドで4コアに見える）と、CPUのコア数がだいぶ違います。

では、本番サイトで8vCPUの仮想マシンを運用しこの仮想マシンをDRサイトにvSphere Replicationでレプリケートした場合はどうなるのか？という質問を頂きました。

想定される答えは、そもそもレプリケートできない（事前チェックでひっかかる）もしくは、レプリケートはできるが、パワーオンできないのどちらかだと思います。

が、たしかにやったことがないですし、これが前提チェックではねられるのであれば、本番環境ではハイスペックで、DRサイトだったらちょっと遅くてもよいので低スペックのサーバーで稼働をという考えはできなくなってしまいます。

今回は、検証として以下のような環境で試してみました。

 

さて、実際にやってみると、レプリケートまでのウィザードは何事もなく完了しました。

実際のレプリケートも、きちんと完了しました。

では、本番サイトの仮想マシンの電源を落として、障害が発生した状態に見立てて、
DRサイト側でリカバってみましょう。
※本番サイトの仮想マシンの電源が落ちないと、vSphere Replicationからリカバリはできません。

 最初の滑り出しは、OKですね。

ウィザードを薦めていき、リカバリする仮想マシンを稼働させるESXiの選択で、スペックの低いマシンを選択しましたが、「検証は成功しました」と出ています。

 では、リカバリ後に電源ONにチェックを入れて、リカバリさせてみましょう。

問題なく、リカバリが始まりました。

ちょっとすると、右下になんらかのメッセージが・・・

でましたね。何となく期待通りのメッセージです。4個のCPUが必要ですが、ホストハードウェアには2個しか有りません。と・・・。（今回は、2ソケット、4コアで仮想マシンを構成したからこういったメッセージが出たようです）

リカバリされた仮想マシンは、きちんとインベントリに表示されますので、仮想マシンの編集を選択します。

CPUのところで、怒られていますので、ハードウェアサポート内のCPU数に変更します。

さて、パワーオンしてみると

見事起動しました！！

仮想マシンも無事です！

ということで、結論は、本番サイトとDRサイトで、物理CPUコア数が異なり、DRサイト上で物理コア数が足りない仮想マシンを、DRサイトにレプリケートできるかというと、レプリケート自身は可能だが、リカバリ時の仮想マシンパワーオン時にエラーが出る。手でリカバリした仮想マシンを編集し、稼働可能なスペックに変更することで稼働する！

ということです。
ちなみに、VMのコミュニティサイトでは、本番サイトをintel CPUで、DRサイトをAMDのCPUで環境を構築してもきちんと稼働するという話が出ています。
ただし、ハードウェアの構成が異なっているため、ハードウェアの再検出による再起動要求や、場合によっては再アクティベーションがゲストOS上で要求されるようです。（これも理屈からするとたしかにそうですね）

（参考）
VMware Communityより
vsphere replication cpu compatibility


ちなみに、フェイルバックは、逆方向のレプリケートを手動で作成する必要がありますので、このときにスペックの低い仮想マシンが本番環境にレプリケートされてしまうことには要注意です！

vSphere Replicationについて(1) あるある都市伝説ネタのご紹介

HyperV Replicaの登場により、VMwareにおいても、vSphere5.1から、Essential Plus以降のエディションに標準搭載されるようになりました。

VMwareのDRに対する取り組みは元々、ストレージのレプリケーション機能と連携した、VMware Site Recovery Manager（SRM)という製品があります。この製品で、ストレージでコピーされた仮想マシンをDRサイトで起動するまでの管理を行い、本番サイトとDRサイトの間のデーターコピーはストレージにお任せという形になります。

しかし、本番サイトとDRサイト間にレプリケーションが可能なストレージを用意するというのはコスト面から考えても決して安いものではなく、そこでストレージに変わって仮想マシン単位でレプリケーションをする機能を作った仮想アプライアンスが「vSphere Replication」になります。

SRMを利用しつつ、ストレージレプリケーションではなく、vSphere Replicationを利用し、DRサイトを作ることで、より手軽なDRが作成できるようになりました。

さらに、先ほど書いたようにvSphere5.1の発表と同時に、vSphere ReplicationがEssential Plus以上で無償で利用できるようになったため、SRMのようにリカバリサイトでの稼働の自動化はできないももの、定期的な仮想マシンの同期ができれば、災害対策バックアップとしてだけでも十分な利用が可能です。

しかし、vSphere Replicationをあまり活用しているケースを聞きません。

ここで、私の聞いたvSphere Replication 都市伝説をご紹介します。


＜質問＞
vSphere Replicationって、別にSQL Serverが必要なんでしょ？。予算ないから無償のHyper-V Replicaのほうがいいかな...。

＜回答＞
vSphere Replicationには、EmbededのDBが用意されており、VMのドキュメントには「最低限の利用」が可能と記載があります。実際にはレプリケーションする仮想マシンのスペックやRPOによってはたしかに、外部DBが必要かもしれませんが、個人的には小規模の環境では、EmbededDBを利用することで十分ではないかと思います。ちなみに、SQL Server以外にOracleがサポートされます。

VMware vSphere Replication 6.0 ドキュメント センターより
vSphere Replication がサポートするデータベース



＜質問＞
vSphere Replicationを利用するには、本番サイトとDRサイトに１つずつ、合計２つのvCenter Serverが必要なんでしょ？Essential Plusだったら、vCenter Server Foundationが1つしかライセンスがないから追加で買わないと行けないのですよね。vCenter Serverの必要スペックもvRAM 8GBとか考えると、DRサイト側のハードスペックも足りないし、追加のvCenter Serverの費用もかかるのであきらめます・・・。

＜回答＞
この質問意外と多いんですよね。マニュアルにも1つのvSphere Replication アプライアンスと1つのvCenterが紐付くという旨の記載があります。つまり、1つのvCenterに2つ以上のvSphere Replication アプライアンスを管理できないというのは、事実です。
でも、サイトごとにvCenter Serverが必要なんていう決まりも、vSphere Replicationまたぎでのレプリケーションしかサポートされないと言うことはどこにも記載がありません。
そうです。管理された2台以上のESXiで、1つのvCenter Serverに管理した上で、vSphere Replicationを利用することで、筐体間レプリケーションが可能です。

図にすると

小規模な環境で、本番サイトとDRサイトをそれぞれ別の場所に設置して、1つのvCenter ServerでESXiのホストを管理する形でもよいですし、本番用ESXiとバックアップ用ESXiを隣において、1つのvCenter Server上で管理し、筐体間レプリケーションが可能です。
あくまでも置き場所の問題で、本番サイトとDRサイトでWAN通信が発生し、効率的な転送を行いたい場合は、それぞれのサイトにvCenter ServerとvSphere Replication Apllianceを配置し、サイト間の通信をvSphere Replication Applianceにお任せするという構成になります。
※VMwareとしては、バックアップとしてData Protectionがありますが、バックアップはバックアップで必要な機能だと思いますが、バックアップには"リストア"の作業が必要です。
vSphere Replicationは基本丸っとコピーですから一応"リストア"というタスクはありますが、バックアップデーターを戻す作業と比べると、かかる時間はごくわずかです。



＜質問＞
本番サイトとDRサイトに同じサーバーやストレージの構成なんでしょ？。本番サイトにはある程度お金がかけられても同じ環境をDRにもなんて、役員会で却下ですよ。

＜回答＞
仮想化の良さはハードウェアに依存しないことです。質問の見解は、仮想化の良さをなくすような話になってしまいます。たしかに、Site Recovery Managerが出た当時は、ストレージ間レプリケーションだったため、基本同じメーカーのストレージ（同じモデルシリーズのストレージ）だったこともあり、またストレージの種類にもよりますが基本、LUN単位でのレプリケーションがほとんどだったと思いますので、レプリケーションが不要な仮想マシンまでもレプリケートの対象になってしまうことがありました。このイメージがへんな形で残ってしまっているのだと思います。
vSphere Replicationは、仮想マシン単位でレプリケート対象を決められますし、vSphere(ESXi)が、本番とDRのそれぞれのサイトで稼働していれば、ハードウェア・ストレージの種別は問いません。

本番サイトは、仮想マシンが100台有るので、SASディスクの高級なFCストレージとXeonの4Wayの高級なサーバーを、DRサイトには最低5台の仮想マシンが稼働すればいいので、Xeonの1Wayサーバーに、SATAディスクのDASで...。という環境でもOKです！！

VMが稼働する環境であれば、本番とDRで同じサーバーモデルやスペックをそろえる必要はありません。



＜質問＞
うちの大事な仮想マシンは、10TBもあります。WAN回線はフレッツ光程度以上のものはコストが高く引くつもりもないので、レプリケーションなんて無理ですよね。

＜回答＞
必ずしも無理ではないです。まずはRPO（復旧地点）が15分前までという設定をしたときと24時間という設定をしたときでは、転送されるデーター量は異なるでしょう。また、常にマスターデーターがコピーされているわけではなく、たしかに一発目はフルローン的に全データーがコピーされますので可能であればローカルで行った上で、DRサイトの持って行けば、CBTによる変更ブロックだけの転送となるため、毎日10TBの変更があれば話は別ですが、変更分がすくなければ、余裕だと思います。また、vSphere6からは、Replicationの通信にネットワーク圧縮の機能も追加されていますので、こちらも機能的には期待できそうです。


ということで、vSphere Replicationあるある質問でした。
実は結構使い前有るんですよ。vSphere Replicationって...。
手軽ですので、vSphere6からは、vSphere Replicatioのレプリケーションにネットワークの圧縮機能やvmdkの未使用領域をレプリケート対象から外すなどの機能追加もあり、さらに適用の範囲は広くなっていると思います。

バックアップとレプリケーションをうまく使い分けることで、コストバランスのとれたDRの現実解が必ず見えてくると思います。