2015年4月8日水曜日

VMware NSX @SoftLayer - その5 【管理クラスタ構築】


vSphereでクラスタを構築するには、2つ以上の共有ディスクが欲しいところです。

SoftLayerがサービスとして提供している共有ストレージは利用しません。リファレンスによると下記のように非推奨となっています。

iSCSI Storage: Can be ordered & added when provisioning a physical server or by navigating to https://control.softlayer.com/storage/iscsi. This storage is actually provisioned as specific Equalogic Targets on a SoftLayer Private internal service network. These iSCSI targets are not made available directly on tenant Private Networks. This requires routing from a vmk ip and using vSphere teaming for HA connectivity. VMware support does not recommend this option (iSCSI routing) since it requires specific physical switch security settings and is generally limited to fail over.

実際に試してみたところ、東京データセンタでは用意されていないLegacy iSCSIは何ら問題なく利用できましたが、Consistent Performance iSCSIやEndurance iSCSIはマウントできませんでした。Private Portable IP Addressを利用せずに、Private Primary IP Addressで接続してみましたが、それでもうまくいきません。Consistent Performance NFSやEndurance NFSはマウントできました。私が何らかの勘違いをしているだけかもしれないので、これらを利用したい場合には、SoftLayerのサポートに問い合わせながら解決策を見つけていただければと思います。かなり頑張ってみたつもりですが、私の拙い技術力ではあきらめるしかないようです。

SoftLayerがvSphere用の共有ストレージとして推奨しているのは、物理サーバーにQuantaStorをインストールしてiSCSI Targetとして利用することです。MPIOによるマルチパス接続が紹介されています。筐体間ミラーの設定方法をどこかでわかりやすく解説してくれていれば有難いのですが、まだ探していません。DRBDを利用可能という話を東京の第2回勉強会でアファーム・ビジネスパートナーズの方が話していたと記憶しています。共有ストレージが障害を起こすと、基本的にシステムが全損状態に陥ってしまう状況となりがちなので、筐体間ミラーによるクラスタ化は必須です。

DRBDを使うのであれば、「SoftLayerに冗長化NFSサーバを(その1)」で紹介したNFSサーバーを利用するのがお手軽です。Oracle Linuxで構築してサポートに入っておけば、Pacemakerによるクラスタ等もサポート範囲に入ってくるので安くて安心です。構築方法のダイジェストがThinkITの「OSSで構築するNFSクラスタサーバー」という記事にまとめられているので、こちらを参照しながら、2セットのNFSクラスタを構築します。
耐障害性を考えれば、同一のストレージを使うよりも別のソリューションと組み合わせておくべきであり、1つ目のストレージはQuantaStorを、2つ目のストレージはこちらを利用するのが最適だと思っております。時間が取れれば、もしくはスポンサーからの提供があれば、QuantaStorも利用してみたいと考えています。


このNFSサーバーをESXiから利用できるようにマウントします。
本来は、「その2 【1台目のESXi構築】」の中で行うべき作業だと思いますが、DNSサーバーの構築より後だと思うので、管理クラスタ2台目以降のESXiサーバー構築時には⑭の位置に以下の手順を付け加えていただければと思います。


⑭NFSサーバーをマウントする。
esxcli storage nfs add --host nfs1.pod1.example.com --share /nfs1 --volume-name nfs1
esxcli storage nfs add --host nfs2.pod1.example.com --share /nfs2 --volume-name nfs2



mgesxi02, mgesxi03を発注し、設定します。
mgesxi01との違いは、発注時に、mgesxi01と同じVLANに接続するように明示すること、ホスト名、IPアドレスが異なることです。

設定が終わったら、以下のコマンドで疎通確認しておきます。


esxcli network diag ping --count 1 --df --size 8972 --host gw-mng.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host mgesxi01.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host mgesxi02.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host mgesxi03.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host gw-vmt.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host mgesxi01-vmt.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host mgesxi02-vmt.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host mgesxi03-vmt.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host gw-san.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host mgesxi01-san.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host mgesxi02-san.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host mgesxi03-san.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host nsxvca01.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host nsxdns01.pod1.example.com; echo ; \
esxcli network diag ping --count 1 --df --size 8972 --host nsxdns02.pod1.example.com


これが通らないようだと、どこかに設定ミスがあります。


NSX1データセンターにmgesxi01, mgesxi02, mgesxi03ホストを追加します。
必要に応じてライセンスの割り当てを行います。

NSX1データセンターに新規スラスタを追加します。


【管理クラスタ作成】

名前: cl-manage
場所: NSX1
DRS: オンにする
自動化レベル: 完全自動化
移行のしきい値: 3
vSphere HA: オンにする
ホストの監視: 有効化
アドミッション コントロール: 有効化
ポリシー: ホスト障害のクラスタ許容: 1
仮想マシンの監視ステータス: 無効
監視感度: 2
EVC: Intel "Sandy Bridge" Generation
仮想 SAN: オフ


NSXでは、DRSがオンになっている前提でインストールされると考えておいた方がよいです。
vCenter Server Applianceを配置しているので、vSphere HAをオンにする必要があります。
EVCの設定は必須です。SoftLayerで物理サーバーを発注した場合、意図したCPUより上位のCPUが支給されることがあるので、vMotionを利用したい場合にエラーとならないよう設定しておきます。

mgesxi01, mgesxi02, mgesxi03ホストを管理クラスタに移動します。
ドラッグアンドドロップで順次移動した後、画面表示を更新し、エラーや警告がなくなることを確認します。

nsxvca01仮想マシンの配置を変更します。データストアをローカルディスクのmgesxi01-das01から共有ディスクnfs1に移行します。

nsxdns02-real仮想マシンの配置を変更します。1号機のローカルディスクのmgesxi01-das01から2号機のローカルディスクのmgesxi02-das01に移行します。ホストとデータストアの両方を同時に移行します。vSphere HAによる保護に関する警告が出ますが無視します。保護すべき動的なデータとしては基本的に/etc/hostsだけであり、動的というほど頻繁に変更が加えられることもなさそうであり、keepalivedで冗長化しているので、vSphere HAによる保護は不要と判断しました。DRSについてもDNSサーバーの位置が確定している方がネットワーク診断には有利だと考えられます。

nsxlog02仮想マシンの配置をどうするかは設計判断が分かれるところだと思います。安くて速いローカルディスクに配置し、vSphere HAによる保護を不要と考えるか、1号機、2号機ともに共有ディスクに配置し、vSphere HAの保護を享受するか。ログデータの保護もローカルディスクより共有ディスクの方が安心(ローカルRAID1とDRBDによる筐体間ミラー、1号機と2号機に書き込む計8重化)だと考えるか、1号機と2号機の両方に保存しており、問題さえなければローテーションのタイミングで消してよいものでしかないと考えるか。
本稿では、できるだけローカルディスクを利用する方針なので、nsxdns02-real仮想マシンと同じ対応とします。

rhel6-template仮想マシンの配置を変更します。データストアをローカルディスクのmgesxi01-das01から共有ディスクのnfs2に移行します。クローン元となる仮想マシンなので通常は電源をオフにしており、ホストの配置自体はどこにあってもいいです。データ保護の観点から、共有ディスクへ配置することにします。

3号機にはData Protectionの仮想アプライアンスを導入し、vCenterがこの仮想アプライアンスと同居しない制約を入れるというのもよいと思っています。
時間が取れれば、このあたりのバックアップについても取り組んでいきたいと思います。

0 件のコメント:

コメントを投稿