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の現実解が必ず見えてくると思います。
