はじめに
本記事では、IBM Cloudの File Storageのレプリケーション機能（リードレプリカ）の機能について記載いたします。本機能は異なるzone（データセンタ）にレプリケーションして、そのレプリケーション先のディスクを読み取り専用ディスクとして参照することが可能となる機能となります。また本機能を活用することで、IBM Cloudのゾーン障害の対策としても利用することが可能です。
File Storageの災害対策の構成イメージ
IBM Cloud上の可用性を向上させる方法として、マルチ・ゾーン（データセンター）で構成することがあげられます。データの保管先である「File Storage」に関しては、リードレプリカの機能を利用することで、ゾーン障害に備えることが可能となります。
具体的には、異なるゾーン（データセンター）にリード・レプリカを作成し、平常時には２つの異なるゾーンの仮想サーバ（VSI）からあるゾーンに存在するFile Storageを参照し、ゾーン障害時にリード・レプリカ切り離して独立したFile Storageとして扱う(スプリット)ことで、障害が発生していないVSIからFile Storageを継続利用することが可能となります。災害復旧の完了後、新しくレプリカを別ゾーンに作成することで再び災害対策の構成をとることができます。
なお、File Storageはリージョン内であれば、ゾーンを跨いで性能的にも問題なく利用することが可能です。
File Storage利用時の注意点
File Storageのレプリケーション機能を利用する際には以下の注意点があります。
- File Storageの同期処理は、リアルタイムでは行われません。最短でも1時間ごとに実施されます。
- File Storageのフェイルオーバーは自動で実行されません。切り替え作業は必ず手動で実行する必要があります。
- File Storageのメインとレプリケーションのマウントポイントに違いがあります。ゾーン障害でFile Storageを切り替える際はサーバー側のマウントポイントの設定を変更する必要があります。
- File Storageのレプリケーションはゾーン跨ぎは可能ですが、リージョンを跨いでレプリケーションを実行することができません。
フェイルオーバー機能について
災害対策の別オプションとしてFile Storageのフェイルオーバー機能(FailOver)があります。この機能を使用することでメインとレプリケーションの役割を入れ替えることができるのでレプリケーション側をメインとして扱うため、メインゾーンで災害発生時でもファイルの編集が可能になります。
また、フェイルオーバーはリソースゾーンの災害などにより操作失敗もしくはタイムアウトが起こった際の挙動として「複製関係の継続」と「複製関係の削除」の２種類の方法があります。「複製関係の継続」の場合はフェールオーバー失敗時でも複製関係を継続し、「複製関係の削除」ではフェイルオーバー失敗時に複製関係を削除してそれぞれ別のFile Storageとして機能します。災害対策の際は後者の「複製関係の削除」を使用することになると思います。
本記事の検証環境について
本記事ではこちらのdocsの手順に従って構築します。
構成の手順は以下の通りです。
事前準備: IBM Cloudの東京リージョンにVPCを作成し、その内部の２つのゾーンそれぞれに仮想サーバー, サブネット, Floating IPを用意。
- １つ目のゾーン内にFile Storageを構築
- マウントのためのマウントターゲットの作成
- 作成したFile Storageを仮想サーバーにマウント
- ２つ目のゾーン内にFile Storageのレプリカを作成(マウントターゲットの作成)
- 作成したレプリカを仮想サーバーにマウント
- フェイルオーバーの実行
- スプリットの実行
本記事の構成図は以下の通りです。
これ以降は実際に試してみた結果です。
構築方法
1. ファイル共有の作成
まずはじめにFile Storageを構築します。
ポータルの左側メニューから「VPC インフラストラクチャー」→「ファイル・ストレージ共有」を選択します。
ファイル・ストレージ共有の画面でリージョンを東京にし、右上の「作成」ボタンを押します。
ファイルストレージの作成画面でロケーションは東京リージョンの東京2を選択し、任意の名前を入力します。
プロファイルではストレージサイズを10GBから、最大IOPSを100から入力します。
マウントターゲットアクセスモードではセキュリティグループと仮想プライベートクラウドの２つから選択します。この二つはマウントターゲットを作成する際に、アクセス権限をセキュリティグループで設定するか、VPC全体でアクセス権限を付与するかを選ぶことができます。今回はセキュリティグループを選択します。
以上の入力が終わったら「ファイル共有の作成」を選択し、作成します。
2. マウントターゲットの作成
次にファイル共有のマウントターゲットを作成します。
先ほど作成したファイル共有をクリックします。
ファイル共有の画面からマウントターゲットの「作成」ボタンを選択します。
マウントターゲットの編集ではまず任意に名前を入力し、事前に作成したVPCとサブネットを入力します。
続いて予約済みIPアドレスではIPアドレスの自動選択のままにし、セキュリティーグループもデフォルトのものを選択します。
以上の入力が終わったら「作成」を押し、作成します。
作成後、マウントターゲットに作成したものが追加されていることが確認できます。右側の編集から「パスの表示」を選択することでマウントパスを表示することができます。このマウントパスは後ほど使用するので保存しておきます。
3. 仮想サーバーへのマウントの作成
次は仮想サーバー側からFile Storageのマウントを作成します。
SSHでサーバーにログインし、ツールのインストールを行います。
yum install -y nfs-utils
マウント用のディレクトリを作成します。
mkdir /share
リモートファイル共有のマウントを行います。
mount -t nfs4 -o sec=sys,nfsvers=4.1 <マウントパス> /share
今回の場合はマウントパスが10.10.0.5:/8e3628da_ec7b_411e_a4c2_5b394cba8545なので
mount -t nfs4 -o sec=sys,nfsvers=4.1 10.10.0.5:/8e3628da_ec7b_411e_a4c2_5b394cba8545 /share
となります。
マウントができているか確認します。
df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 8.6M 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/mapper/vg_virt-lv_root 98G 1.5G 97G 2% /
/dev/vda1 1014M 191M 824M 19% /boot
tmpfs 379M 0 379M 0% /run/user/0
10.10.0.5:/8e3628da_ec7b_411e_a4c2_5b394cba8545 100G 448K 100G 1% /share
/shareフォルダにマウントされていることが確認できます。
ここで試しにファイルを作成し、lsで確認してみます。
vi /share/test.txt
ls -l /share
合計 0
-rw-------. 1 nobody nobody 5 11月 16 10:32 test.txt
初期だとファイルの所有権がnobodyになっています。これを変更するためには設定ファイルにドメイン設定に変更を加える必要があります。
vi /etc/idmapd.conf
（以下を追記）
Domain = slnfsv4.com
変更後、nfsidmap -cを実行し、キャッシュをクリアすることでファイル所有者をrootに変更することができます。
vi /share/test.txt
ls -l /share
合計 0
-rw-r-----. 1 root root 5 11月 16 10:32 test.txt
4. レプリケーションの作成
次にFile Storageの別ゾーンでのレプリケーションを作成します。
ポータルのfile storageの画面の一番下の「ファイル共有の複製関係」から「レプリカの作成」を選択します。
作成画面ではレプリカの名前を任意につけ、レプリカを作成するゾーンを選択します。ゾーンは元のファイルのあるゾーン以外の東京1,3が選択できるので今回は東京1を選択します。
最大IOPSは100以上の適切な数値を入力し、マウントターゲットは右上の作成ボタンから以前作成したのと同様にセキュリティーグループを選択します。
最後に同期頻度を設定します。頻度は毎時、日次、週次、月次もしくはcron式のスケジューラーで設定できます。時間を指定する場合は時刻設定がUTCなので日本時間では9時間後になることに注意してください。
以上が必要項目となるので、「ファイル共有の作成」をおして作成します。
これでfile storegeのレプリカが作成できました。
レプリカの画面を見てみるとファイル共有の複製関係でソースとレプリカが表示されています。
5. レプリケーションのマウント
先ほど作成したレプリケーションを仮想サーバー上にマウントします。手順は3と同様です。
マウントの完了後ファイルを確認すると先ほど作成したテキストファイルが確認できます。
vi /share/test.txt
ls -l /share
合計 0
-rw-r-----. 1 root root 5 11月 16 10:32 test.txt
レプリケーション側ではreadonlyで設定されるのでファイルに変更が加えることができません。
6. フェイルオーバーの実行
レプリケーションにはメインゾーンに問題が発生した時のためにフェイルオーバーの機能があり、メインとレプリカの複製関係を切り替えることができます。また、フェイルオーバー実行時にメインゾーンのFile Storageから最終コピーが実行されるため、最新の状態で
ポータルのファイルストレージ共有で先ほど作成したレプリケーションの画面を開きます。
右上のアクションから「フェイルオーバーの実行」を選択します。
フェイルオーバーの設定項目としてはタイムアウトとフェールバックポリシーが設定できますが、今回は自由に設定して問題ないです。
フェイルオーバーを実行するとファイル共有の複製関係が入れ替わっていることが確認できます。
また、レプリケーションを保存していた側のサーバーからfile storageを確認してみると、ストレージ上のファイルが編集できるようになっています。
7. 複製関係の削除(スプリット)
最後にメインゾーンで障害が発生した時の別の選択肢としてレプリケーション関係の削除(スプリット)を行います。
メインとレプリケーションどちらかのFile Storageの画面の下にある「ファイル共有の複製関係」から「複製関係の削除」を選択します。
すると以下の確認画面が出てくるのでFile Storageの名前を入力して「関係の削除」を選択することでレプリケーション関係を削除することができます。
実行後はそれぞれが独立したFile Storageとなり、レプリケーションは行われなくなります。
実際にレプリカであったFile Storageにサーバーからアクセスして確認してみるとRead/Writeが可能になっていることが確認できます。
ただし、最後に行ったレプリケーション以降に行われた変更はレプリカ側には反映されませんので注意してください。
追記. File Storageのステータス確認方法について
レプリカの異常検知のため、ステータスを確認したい場合、IBM CloudのCLIを使用してステータスを確認することができます。
ibmcloudコマンドを使用するので事前にターミナルにibmcloudをインストールしておきます。
ibmcloudにログイン後、File Storageの一覧を表示することができます。
ibmcloud login -r jp-tok -g Default
ibmcloud is shares
ID 名前 ライフサイクルの状態 ゾーン プロファイル サイズ (GB) リソース・グループ
r022-b32e0e82-0a63-42f4-bdce-798dd7247e67 nitta-rep stable jp-tok-1 dp2 100 Default
r022-084f98be-a09f-4664-8efe-add158a4be7e nitta-fs stable jp-tok-2 dp2 100 Default
ライフサイクルの状態を見るとstableとなっていることが確認できます。File Storageのステータスに関してはこちらのdocsを参照ください。