Help us understand the problem. What is going on with this article?

SoftLayerのベアメタルとプライベートNWを使って東京からサンパウロまで18,000kmのvSphere Replicationを試す

今回は、SoftLayerの時間課金ベアメタルサーバーを使ってvSphere Replicationを試してみます。

SoftLayerの大きな特長の1つである無料で広帯域なプライベートネットワークを使い、東京データセンターに構築した仮想マシンのDisaster Recovery(DR)サイトを海外のデータセンターに作りたいと思います。

今回の構成

今回は、下図の構成とします。

vmware03_overview.jpg

メインサイトとして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

vmware06.jpg

オーダー

東京とサンパウロに、ESXiとvCenterを1組ずつオーダーします。スペックは前回使ったものと同様です。

vmware07.jpg

海外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から注文できます。

vmware66.jpg

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

vmware04.jpg

上記の通り、互換性は問題なさそうです。

VRAのダウンロードにはmy vmwareにユーザー登録が必要ですので、まだ済んでいなければ、ユーザーを作成します。

vmware05.jpg

一点、ちょっとした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サーバー上にダウンロードし、解凍します。

vmware12.jpg

ダウンロードしたzipを解凍。
vmware29.jpg

Windowsサーバーのブラウザには、デフォルトではFlash Playerやクライアントプラグインが入っていないので、vSphere Web Clientを使うために導入します。

vmware10.jpg

vmware11.jpg

vSphere Replication Applianceデプロイ

解凍したフォルダ内のovfファイルをESXi上にデプロイします。

vmware13.jpg

vmware14.jpg

vmware15.jpg

ネットワーク構成は、DHCPでなく、Static-Manualを選びます。GatewayとNetmaskは、事前にオーダーしたPortable Private Subnetの情報を使います。
vmware17.jpg

VRA自身のIPアドレスも、Portable Private Subnetから適宜割り振ります。
vmware18.jpg

vmware19.jpg

VRAが無事にデプロイされました。
vmware20.jpg

ちなみに、SoftLayerでvSphere5.5を使っていると仮想マシンのメモリサイズに応じて課金されるため、メモリサイズが気になるところです。適当に小さく作れないかと思っていたのですが、ovfではメモリをユーザーが設定する箇所がなく、自動的に4GBで作られました。

vmware21.jpg

VRAをデプロイしてもReplicationのアイコンが出てこない問題

さて、本来であればVRAのデプロイが終わると、vCenterのホーム画面でreplicationのアイコンが出てくるはずなのですが、出てきません。。

vmware09.jpg

VRA自体は起動しているようですので、調査のため、下記URLで、VRAの管理画面にアクセスします。パスワードは、アプライアンスのデプロイ中に指定したものを使います。
https://【VRAのIPアドレス】:5480/

vmware22.jpg

VRA管理画面の VR > Configurationの画面で、VRM Service is stoppedと出ています。VRMは、vSphere Replication Managementの事です。

vmware23b.jpg

なぜか必須の欄が空欄になっていますので、入力後、"Save and Restart Service"を押しますが、下記のエラーが出て、まだVRMが起動しません。

Unable to obtain SSL certificate: Bad server response; is a vCenter server listening on the given host and port?

vmware24.jpg

このエラーメッセージで検索すると、下記が見つかりました。

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2085155

VRAからvCenterにアクセスする際に使っているFQDNと、vCenterが配布しているSSL証明書に書かれたFQDNが一致していないために発生するエラーのようです。
vCenterのFQDNを返すDNSが無いため、上記URLにあるように、VRAのコンソールにログインし、vCenterのIPアドレスを/etc/hostsに追記して名前解決できるようにしました。

vmware26.jpg

vmware25.jpg

再度、VRAの管理画面から"Save and Restart Service"を実行すると、無事にVRMが起動しました。

vmware28.jpg

そして、vCenterで、一度ログアウト&ログインをした後にホーム画面を確認すると、vSphere Replicationのアイコンが表示されました!

vmware08.jpg

メインサイトとDRサイトの両方のESXiに、VRAをデプロイします。

仮想マシン(ゲストOS)準備

レプリケーションの保護対象となる仮想マシンを作成し、ubuntuをインストールします。
詳細な手順はこちらを参照ください。

レプリケーション設定

レプリケーションの設定を行っていきます。これは、通常のVMwareの世界の設定となります。

VRAをデプロイしてvCenterが正しく認識すると、仮想マシンを右クリックした時に、レプリケーション構成のメニューが表示されるようになります。

vmware30.jpg

初期状態では自サイトのVRAしか認識していないため、DRサイト(リモートサイト)を追加します。
vmware31.jpg

DR側のvCenterの情報を入れればよいと思ったのですが、「指定されたサイトに接続できません。」というエラーになってしまいました。

vmware32.jpg

vmware33.jpg

ping等は疎通しているので、最初は原因が分からなかったのですが、結論としてはvCenterのSSL証明書で使われているFQDNを使って名前解決をしないといけないようです。

vcenter01、vcenter02が名前解決できるように下記に記述する事で、エラーが消えました。(vCenterにアイコンが出てこなかった件も踏まえると、これらのサーバーを名前解決できるDNSがシステム内にあるのがよいのでしょう。)

  • vcenter01、vcenter02のWindowsのhostsファイル(C:\WINDOWS\system32\drivers\etc\hosts)
  • VRA1号機、2号機の/etc/hosts

vmware34.jpg

vmware36.jpg

クイックにテストをしたいため、RPOは設定できる範囲で最短の15分としました。
vmware38.jpg

vmware39.jpg

転送状況確認

レプリケーションの設定を行うと、vCenterのサマリ画面にレプリケーション状況のサマリが表示されます。

vmware40.jpg

vmware41.jpg

サマリから詳細を表示すると、監視>vSphere Replicationの下にある詳細画面に移動します。
初回は、初期完全同期として、フルコピーが行われます。
vmware42.jpg

vmware44.jpg

初回のフルコピーが終わった後は、RPOを満たすように定期的に差分レプリケーションが行われます。

また、DR側のvCenterでも、「受信レプリケーション」として同じレプリケーション処理を確認できます。
vmware48.jpg

定期的にファイルを書き込む仕掛け

レプリケーションを行っても、本番サイトに何も書き込みがなければ、正しくレプリケーションが行われているかどうか分かりません。下記は何も変更が無かったときの例です。
vmware46.jpg

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
・
・
・

生成されたファイルがレプリケーションされる事が確認できます。
vmware47.jpg

なお、書き込み量が多すぎると、RPOの間隔以内にレプリケーションが完了しなくなりますので、RPOを長くするなどの対応が必要になります。

参考:転送量が多すぎ、RPO違反となった例
vmware67.jpg

DRサイトに切り替え(フェイルオーバー)

いよいよ、災害を想定し、本番サイト(東京DC)からDRサイト(サンパウロ)に切り替えます。

災害を模し、仮想マシンの電源をオフにします。
vmware49.jpg

vmware50.jpg

レプリケーションのステータスが無効になります。
vmware51.jpg

DR側でリカバリを選択します。
vmware52.jpg

vmware53.jpg

黄色い「リカバリ済み仮想マシンのネットワークデバイスは切断されます」のメッセージに留意して下さい。リカバリ後にネットワークデバイスを接続する必要があります。
vmware54.jpg

レプリケーションのステータスがリカバリ済みになります。これで、仮想マシンがDRサイトに切り替わりました。
vmware55.jpg

これまで、DR側にはVRAの仮想マシンの1つしかありませんでしたが、保護対象の仮想マシンが追加になり、仮想マシンが2つになった事が分かります。

リカバリ前
vmware68.jpg

リカバリ後
vmware69.jpg

しかし、まだゲストOSにはコンソール以外からはアクセスできません。
今は、東京DCで付与したPortable IPがそのまま引き継がれていますが、Portable IPは各DCのVLANと紐づいたものですので、東京DCのPortable IPを付いたままサンパウロDCで起動しても、そのまま使うことはできません(SoftLayer内をルーティングしてくれません)。
よって、ゲストOSのIPを、サンパウロのPortable IPに変更する必要があります。

コンソールでログインし、/etc/network/interfacesファイルの必要な情報を書き換えます。

vmware58.jpg

vmware59.jpg

また、レプリケーション直後はネットワークデバイスが切断されているため、接続します。
vmware56.jpg

vmware57.jpg

これで、サンパウロ側の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です。
vmware63.jpg

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です。

東京→サンパウロの向きのレプリケーション設定を削除
vmware65.jpg

サンパウロで稼動するvm01に対し、レプリケーション設定を行います。先ほどとは逆に、サンパウロ側が発信レプリケーション、東京側が受信レプリケーションとなります。

サンパウロ側の発信レプリケーション
vmware60.jpg

東京側の受信レプリケーション
vmware61.jpg

切り戻し(フェイルバック)

初期完全同期後、しばらくDRサイトで運用を行ったと想定し、DRサイト側にも先ほどと同じく、定期的にファイルを書き込みます。

そして、フェイルバックを行います。フェイルバックの操作も、先ほど東京からサンパウロに切り替えた時と逆に、サンパウロ側の仮想サーバーをパワーオフし、東京側のレプリケーションからリカバリを行います。/etc/network/interfacesも、東京の値に戻します。

サンパウロで書き込んだファイルも、最後の同期ポイントの19:49時点のファイルまで、東京側に転送されたことが確認できました。

vmware64.jpg

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

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away