OSSで構築するNFSクラスタサーバー

[PR]

なぜ今さら、NFSサーバーのようなレガシーなものを？ とお考えの方も多いことと思われます。私の考えでは、レガシーなものが今までどおり使えることこそが、パブリッククラウド利用促進の原動力です。リレーショナル・データベースが不要になるでしょうか。ファイルサーバーはどうでしょうか。仕様が多少変わりながらも、末永く利用されるものだと思われます。

ネットワーク

24×365運営、商用利用を視野に入れた場合、冗長化構成が必須となります。SoftLayerでは、既存の技術がそのまま利用可能です。VLAN上のL2通信がブロックされていません。VLANにPortable IP Addressを割り当てれば、VIPも利用可能となります。SoftLayerが標準で用意しているルーター経由でルーティングしなくてもよいということであれば、自由にプライベートIPアドレスを割り振ることもできます。

物理サーバーも利用可能なので、通常のライセンス体系のままで、Oracle RACのサポートが受けられる構成で構築可能です。

【参考】SoftLayer で学ぶ Oracle RAC 入門、ワン・コインの自己投資（その1）

物理サーバーを利用すれば、VMware社のESXiを動かすことも可能です。この自由度こそが、パブリッククラウドに求められていたものであり、私がSoftLayerを一押しする理由です。

閉域ネットワーク

SoftLayerでは、プライベートネットワーク内で利用できるサービスがいろいろと用意されています。NTPを利用するために、インターネット上のサーバーへアクセスする必要はありません。管理コンソールやAPI発行も、プライベートネットワーク内で完結させることができます。Windows Updateやアンチウイルス用のパターン定義ファイル更新もできます。疑似VIP利用のためにインターネット接続が必要となるAWSのような弱点は、持ち合わせていません。パブリッククラウドをセキュアに利用するための基盤が整っています。データベースやファイルサーバーを、閉じたプライベートネットワーク内に配置することができます。

共有ディスク

システムの冗長化を考えた場合には、共有ディスクも必要となります。SoftLayerでは、共有ディスクがサービスとして用意されています。ブロックデバイスとしてはiSCSIが利用可能です。ファイルシステムとしては、NFS、CIFSが利用可能です。

IaaSの部分については、競合他社との競争原理が働き、特にSoftLayerの仮想サーバーは、コストパフォーマンスの良さが光ります。有名どころのパブリッククラウドで実測すれば、その優秀さが際立っています。PaaSの部分は、どのクラウドでも言えることですが、望む仕様と用意されている仕様が合致している場合には、そのお手軽さがとてもうれしいものです。そうでない場合は、IaaS上に独自構築することになります。

IaaS上に共有ディスクを構築しようとした場合、SoftLayerでは、OSとしてQuantaStorを選択可能です。数十TBクラスのストレージが必要な場合や、複数のストレージを束ねたい場合に利用すると便利だと思われます。

本稿では、OSSのDRBDを紹介します。本家Linux Kernelにも組み込まれています。ネットワーク越しのRAID1を実現するソフトウェアと考えていただければよいでしょう。LINBIT社によるオフィシャルサポートが必要な場合は、こちらよりお問い合わせください。

DRBDは、ブロックデバイスです。DRBDの上にファイルシステムを構築し、その上にデータベースを配置すれば、シェアードナッシング型HAクラスタ・データベースを構築可能です。今回は、NFSサーバーがエクスポートする領域として利用します。

DRBDを共有ディスクとするクラスタ構築は、OSSのPacemakerを利用します。専用のリソース・エージェントが用意されています。

図1：Pacemakerによるクラスタ構成の概念

構築手順

本稿で紹介する構築方法は、構築スクリプトをGitHubに用意しているので、クラスタの構築としてはとても簡単です。

まず仮想サーバーを2台発注します。注意点は次のとおりです。

• CentOS 6.xの最小構成を選ぶ
• Diskを2台以上選ぶ
• 2台のサーバーが同じDisk構成となっていること
• 2台のサーバーが同じVLANを利用すること
• 1Gbps Uplinkを選択する
• SSH Keysを指定する
• Provisioningスクリプトにhttps://raw.githubusercontent.com/pcserver-jp/SoftLayer/master/co6.shを指定する

図2：仮想マシンの構成

手順はまず、無料の64 Portable Private IP Addressesを発注します。

SSL VPN等を用意し、プライベートネットワーク内で、SSH Keysに指定した鍵を使い、ユーザーsl-admin（パスワード：sl-admin）で1号機にログインし、パスワード変更後、再ログインします。

設定ファイルを編集（sudo vi /etc/ha.d/param_cluster）します。IPアドレスは、Portable Private IP Addressesから3つ選んで指定してください。ホスト名、ドメイン名を指定します。DRBD_SIZEは、2台目のディスクサイズの80%ほどを指定してください。他は変えなくても動きます。

HA1_IP=10.110.88.60
HA2_IP=10.110.88.61
HA_VIP=10.110.88.62
HA_DOMAIN=example.com
HA1_NODE=backup11
HA2_NODE=backup12
DRBD_SIZE=80G

/etc/ha.d/mk_nfsserver_for_backupを実行します。再ログイン指示に従い、ログをチェック（sudo tail -n 1000 -f nohup.out）します。完了メッセージが出力されたら、2号機にログインします。この際、sl-adminアカウントにて2号機から1号機にsshでログインできるように、sshエージェントを起動し、秘密鍵を登録し、エージェント転送を有効化してログインします。

2号機では、VIPを引数に指定して同コマンドを実行（/etc/ha.d/mk_nfsserver_for_backup 10.110.88.62）します。再ログイン指示に従い、ログをチェック（sudo tail -n 1000 -f nohup.out）します。完了メッセージが表示されたら構築完了です。同期処理を行いますので、DRBD領域のサイズに応じた時間がかかります。

スイッチオーバーさせてみる

状態を確認（sudo crm_mon -rfA1）後、sudo /etc/ha.d/switchを実行します。スイッチオーバー（手動フェイルオーバー）させることができます。NFSクライアントからマウントし、読み書きを実行しているところでスイッチオーバーさせてみると、何ごともなかったかのように処理が継続される様子を観察することができます。

/etc/ha.d/、/rescue/ディレクトリには、他にも便利なスクリプトを用意してあるので、内容を確認の上、利用してみてください。コマンド1つでシステムバックアップを取得できたりします。

図3：冗長化NFSサーバーの構成

冗長化NFSサーバーの詳細情報

ネットワーク周りがどうなっているか説明します。

SoftLayerのサーバーは、Public VLANとPrivate VLANに接続された状態でデプロイされます。

Public VLAN側には、グローバルIPアドレスが付与されています。直接インターネットと接続されている状態です。本稿では、このグローバルIPアドレスをプライベートIPアドレスに置き換えています。SoftLayerが10.0.0.0/8を使用しているので、これ以外のプライベートIPアドレスを自由に利用できます。ただし、ルーティングはされません。DRBDによるディスクデータのリアルタイム同期と、ハートビート（死活監視）に利用しています。

Private VLAN側には、プライベートIPアドレスが付与されています。このプライベートIPアドレスは、SoftLayer側の都合で付与されるので、どのIPアドレスが付与されるかはデプロイしてみないとわかりません。VIPも使えません。使ってしまうと、あとからデプロイしたサーバーとバッティングすることになります。

無料のPortable Private IP Addressesを発注し、割り当てられたサブネットから3つのIPアドレスを選択して、それぞれのサーバーとVIPに利用しています。このプライベートIPアドレスを利用する通信についてはルーティングがなされます。NFSクライアントは、このVIPと通信を行うように設定してください。このセグメントを、2つ目のハートビートにも利用しています。

Private VLAN側には、DNS、NTP、Ping監視といった無料で利用できるサービスや、iSCSI等のストレージサービスも用意されており、インターネット側にある操作端末から無料のSSL VPN接続経由で通信できるほか、閉域利用を想定した種々のサービスも整っていて、SoftLayerの特長となっています。セキュリティ面でSoftLayerほど安心して使える大手のクラウドは他に見当たりません。

ディスク周りについても説明します。1台目のディスクはOS領域として利用します。注文画面には出てきませんが、仮想サーバーでは、2台目のディスクがswap用に用意されています。

OSから見た3台目のディスクが、2nd Diskにあたります。2nd Disk以降をLVMで束ねて、DRBDによる共有ディスク領域としています。5th Diskまで利用可能なので、最大2TB×4台の領域を利用可能です。その気になればiSCSIも利用可能なので、8TBが上限というわけでもありません。

LVMで用意した全領域をDRBDに割り当てるのではなく、スナップショット用の領域を残しておきます。スナップショットを適宜利用すれば、データの安全性が向上します。DRBDの同期は、Primary側で書き込まれた順番どおりにSecondary側に書き込むことで、データの一貫性が保たれています。ただし、障害復旧時には、Primary側とSecondary側の差分を、書き込まれた順序は無視して同期することになり、復旧作業中についてはSecondary側のデータ一貫性が保証されない状態になってしまうので、一貫性のあるデータがPrimary側にしか存在しない時間帯ができてしまいます。スナップショットを取得してから障害復旧させれば、スナップショットが、一貫性のあるバックアップとしての役割を果たしてくれます。

障害復旧とひとくくりにして述べましたが、スタンバイ側を再起動する処理や、領域拡張等も障害復旧に当たります。障害復旧中にアクティブ機が障害を起こすと、スナップショットを取得していない場合、どこにも一貫性のある状態が保存されていないことになります。レアケースと考えられるかもしれませんが、障害は起きてほしくないときに限って発生してしまうものです。

物理サーバーにおける実装例や、プロビジョニングスクリプトの解説、補助スクリプトの解説、その他詳細情報、最新情報は以下をご参照いただければ幸いです。

【参考】SoftLayerに冗長化NFSサーバを（その1）

＜編集部より＞2号機へのログイン方法について説明を補足しました（2015/2/9）

Japan SoftLayer Summit 2015
	東京データセンター開設！「IBM SoftLayer」日本初の技術カンファレンス 「Japan SoftLayer Summit 2015」は、Japan SoftLayer Summit 2015実行委員が主催する、「IBM SoftLayer」最大級の技術カンファレンスです。 SoftLayerに関わるコミュニティ、あるいは、企業や団体、それらに所属する個人が一堂に会し、情報発信や交流を行うことで、日本におけるSoftLayerのプレゼンスの向上、ならびに更なるエコシステムの活性化を目的とします。 また、SoftLayerに興味をもつ新しいユーザーに対しても、情報発信を行い、SoftLayerについて学ぶ事ができる場を提供します。