今回は、SoftLayerの時間課金ベアメタルサーバーを使ってvSphere Replicationを試してみます。
SoftLayerの大きな特長の１つである無料で広帯域なプライベートネットワークを使い、東京データセンターに構築した仮想マシンのDisaster Recovery(DR)サイトを海外のデータセンターに作りたいと思います。
今回の構成
今回は、下図の構成とします。
メインサイトとしてSoftLayerの東京DCを想定し、ESXiサーバーを1台とvCenterを立てます。ESXi上に、vSphere Replication Appliance(VRA)と、保護対象のゲストOSを1つ立てます。
DRサイトには、SoftLayerのサンパウロDCを想定します。本番業務で検討するなら、メインサイトが東京であれば、DRサイトもそれなりに東京に近い、香港・シンガポール・シドニーあたりがオーソドックスかもしれません(データ転送や、切り替え後のユーザーアクセスの観点で、近めのほうがパフォーマンスが期待できるため)。
今回は、お試しということで少しチャレンジングに、東京DCから、地球上で最も遠くにあるサンパウロDCへのレプリケーションを構成したいと思います。地球の1周が約40,000kmですので、東京→サンパウロの18,000kmは、地球のほぼ真裏という事になります。
DC間のLatencyや転送速度
予備調査として、東京DCからサンパウロDCへのLatencyと転送速度を確認しました。
送信元も送信先も1GbpsのNICを付けた仮想サーバーを使い、tempfileという名前の1GBのファイルを1つ転送した時の転送速度を見ました。
下記の通り、東京DCからサンパウロDCへのRTTは約300ms、転送速度は6.2MB/s（≒50Mbps）です。
さすがに地球の裏側まで行くと近くはないですが、オンプレの2拠点間が回線次第でもっと遅い事も珍しくありませんので、「十分使い物になる」パフォーマンスかな、という印象です。
[root@tokyo ~]# ping 10.150.143.99
PING 10.150.143.99 (10.150.143.99) 56(84) bytes of data.
64 bytes from 10.150.143.99: icmp_seq=1 ttl=54 time=296 ms
64 bytes from 10.150.143.99: icmp_seq=2 ttl=54 time=296 ms
64 bytes from 10.150.143.99: icmp_seq=3 ttl=54 time=296 ms
^C
--- 10.150.143.99 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2719ms
rtt min/avg/max/mdev = 296.234/296.401/296.728/0.500 ms
[root@tokyo ~]#
[root@tokyo ~]# scp ./tempfile root@10.150.143.99:/root/
root@10.150.143.99's password:
tempfile 100% 1024MB 6.2MB/s 02:45
[root@tokyo ~]#
参考に、東京DCに最も近い香港DCで同じことを試すと、下記の数値でした。
36.6MB/s≒300Mbpsは、早いですね。
[root@tokyo ~]# ping 10.111.6.155
PING 10.111.6.155 (10.111.6.155) 56(84) bytes of data.
64 bytes from 10.111.6.155: icmp_seq=1 ttl=56 time=45.3 ms
64 bytes from 10.111.6.155: icmp_seq=2 ttl=56 time=44.9 ms
64 bytes from 10.111.6.155: icmp_seq=3 ttl=56 time=44.9 ms
^C
--- 10.111.6.155 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2404ms
rtt min/avg/max/mdev = 44.943/45.092/45.360/0.256 ms
[root@tokyo ~]#
[root@tokyo ~]# scp ./tempfile root@10.111.6.155:/root/
root@10.111.6.155's password:
tempfile 100% 1024MB 36.6MB/s 00:28
[root@tokyo ~]#
なお、これらの通信は通信先に10.x.x.xのプライベートIPを指定している事からも分かるとおり、インターネットではなく、SoftLayerのプライベートネットワークを使った通信です。無料でセキュアなプライベートネットワークを使えるのは、SoftLayerの大きな特長ですね。
SoftLayerでは、世界28箇所のデータセンターを、無料・広帯域のプライベートネットワークで結んでいます。
http://www.softlayer.com/data-centers
オーダー
東京とサンパウロに、ESXiとvCenterを1組ずつオーダーします。スペックは前回使ったものと同様です。
海外DCのサーバーをオーダーする時も、いつものオーダー画面で、プロビジョニング先のデータセンターを変えるだけですし、オーダー後も1つの管理画面上で管理ができます。SSL VPNで東京のエンドポイントに繋げば、東京のサーバーに繋ぐのと全く同様に10.x.x.xのプライベートIPを指定すれば、どのDCのサーバーにもプライベートNW経由でアクセスできます。全世界のDCのサーバーをフラットに管理できるのも、SoftLayerの特長の1つだと思います。
ゲストOSに付与するIPアドレスとして、Portable Private IPを使いますので、東京とサンパウロに、Portable Private IPをまだ持っていなければ、オーダーします。SoftLayerの管理ポータルの、Network > IP Management > Subnets 画面のOrder IP Addressesから注文できます。
vCenter初期セットアップ
プロビジョニングが完了したら、vCenterサーバー配下にデータセンターを作成し、ESXiホストを追加します。
詳細はこちらに書きました。
vSphere Replication Applianceインストール
SoftLayerから提供されるvSphereはEnterprise plusのため、追加のライセンス無しでvSphere Replicationを利用できます。
レプリケーション機能を使うのに必要となるvSphere Replication Appliance(以下VRA)は、VMwareのサイトからovf形式でダウンロードし、ESXi上に展開します。
VRA 5.x系の最新バージョンは、5.8.1のようですので、これを使いたいと思います。
https://my.vmware.com/jp/web/vmware/details?productId=353&downloadGroup=VR581
今回の構成は、vCenter5.5 Update2とESXi5.5 Update2を使っているため、念のため互換性を確認します。
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php
上記の通り、互換性は問題なさそうです。
VRAのダウンロードにはmy vmwareにユーザー登録が必要ですので、まだ済んでいなければ、ユーザーを作成します。
一点、ちょっとしたTipsですが、VRA（に限らず大きいゲストOSのイメージファイル）のダウンロードやデプロイは、ローカルのPCにダウンロードしたのをSoftLayerのvCenterにアップロードするより、下記の要領で、vCenterを入れたSoftLayer上のWindowsサーバーにリモートデスクトップで繋いで実施するほうが早いです。
- vCenterを入れたWindowsサーバーにリモートデスクトップでログインする。
- そこのブラウザを使ってvCenterサーバーのWindows上にVRAアプライアンスをダウンロードする。
- インストールもvCenterサーバーのブラウザからvCenter自身のIPアドレスのWeb Clientにアクセスして、ローカル(vCenterサーバー自身)のovfファイルをインストールする形で行う。
vCenterサーバーにリモートデスクトップでログインし、VRAのzipファイルをWindowsサーバー上にダウンロードし、解凍します。
ダウンロードしたzipを解凍。
Windowsサーバーのブラウザには、デフォルトではFlash Playerやクライアントプラグインが入っていないので、vSphere Web Clientを使うために導入します。
vSphere Replication Applianceデプロイ
解凍したフォルダ内のovfファイルをESXi上にデプロイします。
ネットワーク構成は、DHCPでなく、Static-Manualを選びます。GatewayとNetmaskは、事前にオーダーしたPortable Private Subnetの情報を使います。
VRA自身のIPアドレスも、Portable Private Subnetから適宜割り振ります。
VRAが無事にデプロイされました。
ちなみに、SoftLayerでvSphere5.5を使っていると仮想マシンのメモリサイズに応じて課金されるため、メモリサイズが気になるところです。適当に小さく作れないかと思っていたのですが、ovfではメモリをユーザーが設定する箇所がなく、自動的に4GBで作られました。
VRAをデプロイしてもReplicationのアイコンが出てこない問題
さて、本来であればVRAのデプロイが終わると、vCenterのホーム画面でreplicationのアイコンが出てくるはずなのですが、出てきません。。
VRA自体は起動しているようですので、調査のため、下記URLで、VRAの管理画面にアクセスします。パスワードは、アプライアンスのデプロイ中に指定したものを使います。
https://【VRAのIPアドレス】:5480/
VRA管理画面の VR > Configurationの画面で、VRM Service is stoppedと出ています。VRMは、vSphere Replication Managementの事です。
なぜか必須の欄が空欄になっていますので、入力後、"Save and Restart Service"を押しますが、下記のエラーが出て、まだVRMが起動しません。
Unable to obtain SSL certificate: Bad server response; is a vCenter server listening on the given host and port?
このエラーメッセージで検索すると、下記が見つかりました。
VRAからvCenterにアクセスする際に使っているFQDNと、vCenterが配布しているSSL証明書に書かれたFQDNが一致していないために発生するエラーのようです。
vCenterのFQDNを返すDNSが無いため、上記URLにあるように、VRAのコンソールにログインし、vCenterのIPアドレスを/etc/hostsに追記して名前解決できるようにしました。
再度、VRAの管理画面から"Save and Restart Service"を実行すると、無事にVRMが起動しました。
そして、vCenterで、一度ログアウト＆ログインをした後にホーム画面を確認すると、vSphere Replicationのアイコンが表示されました！
メインサイトとDRサイトの両方のESXiに、VRAをデプロイします。
仮想マシン（ゲストOS）準備
レプリケーションの保護対象となる仮想マシンを作成し、ubuntuをインストールします。
詳細な手順はこちらを参照ください。
レプリケーション設定
レプリケーションの設定を行っていきます。これは、通常のVMwareの世界の設定となります。
VRAをデプロイしてvCenterが正しく認識すると、仮想マシンを右クリックした時に、レプリケーション構成のメニューが表示されるようになります。
初期状態では自サイトのVRAしか認識していないため、DRサイト(リモートサイト)を追加します。
DR側のvCenterの情報を入れればよいと思ったのですが、「指定されたサイトに接続できません。」というエラーになってしまいました。
ping等は疎通しているので、最初は原因が分からなかったのですが、結論としてはvCenterのSSL証明書で使われているFQDNを使って名前解決をしないといけないようです。
vcenter01、vcenter02が名前解決できるように下記に記述する事で、エラーが消えました。（vCenterにアイコンが出てこなかった件も踏まえると、これらのサーバーを名前解決できるDNSがシステム内にあるのがよいのでしょう。）
- vcenter01、vcenter02のWindowsのhostsファイル（C:\WINDOWS\system32\drivers\etc\hosts）
- VRA1号機、2号機の/etc/hosts
クイックにテストをしたいため、RPOは設定できる範囲で最短の15分としました。
転送状況確認
レプリケーションの設定を行うと、vCenterのサマリ画面にレプリケーション状況のサマリが表示されます。
サマリから詳細を表示すると、監視＞vSphere Replicationの下にある詳細画面に移動します。
初回は、初期完全同期として、フルコピーが行われます。
初回のフルコピーが終わった後は、RPOを満たすように定期的に差分レプリケーションが行われます。
また、DR側のvCenterでも、「受信レプリケーション」として同じレプリケーション処理を確認できます。
定期的にファイルを書き込む仕掛け
レプリケーションを行っても、本番サイトに何も書き込みがなければ、正しくレプリケーションが行われているかどうか分かりません。下記は何も変更が無かったときの例です。
1分ごとに20MBのファイルを書き込むようにしました。1時間で1,200MB、8時間で9,600MBですので、業務システムの書き込み量の想定として少なすぎる事はないと思います。
後ほどフェイルオーバーテストを行った時にDR先でファイルのタイムスタンプを見て、どこの時点まで戻ったかを確認したいと思います。
tama@ubuntu01:~/data$ while true
> do
> filename=`date '+%Y%m%d%H%M%S'`
> dd if=/dev/zero of="data_"$filename bs=1M count=20>/dev/null 2>&1
> sleep 60
> done
出力されたファイル。
tama@ubuntu01:~/data$ ls -la
total 1966088
drwxrwxr-x 2 tama tama 4096 3月 22 14:16 .
drwxr-xr-x 4 tama tama 4096 3月 22 14:28 ..
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:40 data_20160322124008
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:41 data_20160322124108
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:42 data_20160322124208
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:43 data_20160322124308
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:44 data_20160322124408
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:45 data_20160322124508
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:46 data_20160322124608
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:47 data_20160322124708
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:48 data_20160322124808
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:49 data_20160322124908
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:50 data_20160322125008
-rw-rw-r-- 1 tama tama 20971520 3月 22 12:51 data_20160322125108
・
・
・
生成されたファイルがレプリケーションされる事が確認できます。
なお、書き込み量が多すぎると、RPOの間隔以内にレプリケーションが完了しなくなりますので、RPOを長くするなどの対応が必要になります。
参考：転送量が多すぎ、RPO違反となった例
DRサイトに切り替え（フェイルオーバー）
いよいよ、災害を想定し、本番サイト（東京DC）からDRサイト（サンパウロ）に切り替えます。
災害を模し、仮想マシンの電源をオフにします。
レプリケーションのステータスが無効になります。
DR側でリカバリを選択します。
黄色い「リカバリ済み仮想マシンのネットワークデバイスは切断されます」のメッセージに留意して下さい。リカバリ後にネットワークデバイスを接続する必要があります。
レプリケーションのステータスがリカバリ済みになります。これで、仮想マシンがDRサイトに切り替わりました。
これまで、DR側にはVRAの仮想マシンの１つしかありませんでしたが、保護対象の仮想マシンが追加になり、仮想マシンが２つになった事が分かります。
リカバリ前
リカバリ後
しかし、まだゲストOSにはコンソール以外からはアクセスできません。
今は、東京DCで付与したPortable IPがそのまま引き継がれていますが、Portable IPは各DCのVLANと紐づいたものですので、東京DCのPortable IPを付いたままサンパウロDCで起動しても、そのまま使うことはできません（SoftLayer内をルーティングしてくれません）。
よって、ゲストOSのIPを、サンパウロのPortable IPに変更する必要があります。
コンソールでログインし、/etc/network/interfacesファイルの必要な情報を書き換えます。
また、レプリケーション直後はネットワークデバイスが切断されているため、接続します。
これで、サンパウロ側のIPを指定する事で、ゲストOSにアクセスすることができるようになりました。
ローカルPCからpingを打つと、RTTがだいぶ長くなった事が分かります。
C:\Users\ADMIN>ping 10.150.71.3
10.150.71.3 に ping を送信しています 32 バイトのデータ:
10.150.71.3 からの応答: バイト数 =32 時間 =457ms TTL=53
10.150.71.3 からの応答: バイト数 =32 時間 =464ms TTL=53
10.150.71.3 からの応答: バイト数 =32 時間 =459ms TTL=53
10.150.71.3 の ping 統計:
パケット数: 送信 = 3、受信 = 3、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 457ms、最大 = 464ms、平均 = 460ms
もし、アプリケーションがIPアドレスを意識する作りになっていれば、適宜、アプリが新しいIPで動くよう設定を行う事になります。
ゲストOSにアクセスできるようになりましたのでログインしてファイルを確認すると、災害を模して東京側の仮想サーバーを停止した時刻の直前のレプリカまでリカバリできている事が分かります。
仮想マシンのパワーオフは14:22頃に行いました。
その直前のデータ同期は、14:16です。
14:16のファイルまでサンパウロに来ている事が確認できます。
tama@ubuntu01:~/data$ ls -la
total 4259856
drwxrwxr-x 2 tama tama 12288 3月 22 19:48 .
drwxr-xr-x 4 tama tama 4096 3月 22 14:28 ..
・
・
(略)
・
・
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:08 data_20160322140809
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:09 data_20160322140909
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:10 data_20160322141009
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:11 data_20160322141109
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:12 data_20160322141209
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:13 data_20160322141310
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:14 data_20160322141410
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:15 data_20160322141510
-rw-rw-r-- 1 tama tama 0 3月 22 14:16 data_20160322141610
tama@ubuntu01:~/data$
なお、今回の方法は、整合性の観点で言うと、クラッシュ・コンシステンシーレベルの同期です。
vSphere6ではLinuxのファイルシステムレベルで同期する方法もあるようですので、より高い整合性レベルを必要とする場合は検討してもよいかと思います。
逆方向のレプリケーション設定
東京に切り戻すための準備を行います。現在、業務を行っているのはサンパウロですので、サンパウロで書き込まれたデータを東京にレプリケーションする必要があります。そのため、サンパウロ→東京の向きのレプリケーション設定を行います。東京→サンパウロの向きのレプリケーション設定を削除したあと、先ほど設定したのと逆向きに同じ設定を行えばOKです。
東京→サンパウロの向きのレプリケーション設定を削除
サンパウロで稼動するvm01に対し、レプリケーション設定を行います。先ほどとは逆に、サンパウロ側が発信レプリケーション、東京側が受信レプリケーションとなります。
サンパウロ側の発信レプリケーション
東京側の受信レプリケーション
切り戻し（フェイルバック）
初期完全同期後、しばらくDRサイトで運用を行ったと想定し、DRサイト側にも先ほどと同じく、定期的にファイルを書き込みます。
そして、フェイルバックを行います。フェイルバックの操作も、先ほど東京からサンパウロに切り替えた時と逆に、サンパウロ側の仮想サーバーをパワーオフし、東京側のレプリケーションからリカバリを行います。/etc/network/interfacesも、東京の値に戻します。
サンパウロで書き込んだファイルも、最後の同期ポイントの19:49時点のファイルまで、東京側に転送されたことが確認できました。
tama@ubuntu01:~/data$ ls -la
total 4259856
drwxrwxr-x 2 tama tama 12288 3月 22 19:48 .
drwxr-xr-x 4 tama tama 4096 3月 22 14:28 ..
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:00 data_20160322140009
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:01 data_20160322140109
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:02 data_20160322140209
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:03 data_20160322140309
-rw-rw-r-- 1 tama tama 20971520 3月 22 14:04 data_20160322140409
・
・
（略）
・
・
-rw-rw-r-- 1 tama tama 20971520 3月 22 19:40 data2_20160322194035
-rw-rw-r-- 1 tama tama 20971520 3月 22 19:41 data2_20160322194135
-rw-rw-r-- 1 tama tama 20971520 3月 22 19:42 data2_20160322194235
-rw-rw-r-- 1 tama tama 20971520 3月 22 19:43 data2_20160322194335
-rw-rw-r-- 1 tama tama 20971520 3月 22 19:44 data2_20160322194435
-rw-rw-r-- 1 tama tama 20971520 3月 22 19:45 data2_20160322194535
-rw-rw-r-- 1 tama tama 20971520 3月 22 19:46 data2_20160322194635
-rw-rw-r-- 1 tama tama 20971520 3月 22 19:47 data2_20160322194735
-rw-rw-r-- 1 tama tama 20971520 3月 22 19:48 data2_20160322194835
tama@ubuntu01:~/data$
最後に、再び通常の東京→サンパウロの向きにレプリケーション設定を行えば、元通りです。
まとめ
今回は、ベアメタルサーバーとプライベートネットワークという、SoftLayerの2大特長を活かした機能を試しました。
「海外のデータセンターに災対環境を構築する」という要件を、オンプレ環境で実現しようとすると、コストも工数も相当かかり、技術的な難易度も高いものになりますが、SoftLayerとVMwareを組み合わせることで、今回の規模のお試し環境であれば1～2日で試す事ができました。本番環境の構成を検討する際は、以下のKnowledgelayerもご参照ください。
http://knowledgelayer.softlayer.com/procedure/deploy-vmwaresoftlayer
次回は、データ保護の観点でvSphere Replicationと並んで語られる事が多いVDPを試してみたいと思います。
書きました！ 2016/5/3
SoftLayerの時間課金ベアメタルサーバーでvSphere Data Protection(VDP)を試す
http://qiita.com/y_tama/items/69ae9be34981f2aa1b1f#_reference-611604be632d05f62338