red hat storage server 2.0 on amazon ec2 導入ガイド

Red Hat Storage Server 2.0 Red Hat Storage Server 2.0 on Amazon EC2 on Amazon EC2 導入ガイド導入ガイド

レッドハット株式会社レッドハット株式会社グローバルサービス本部ソリューションアーキテクトグローバルサービス本部ソリューションアーキテクト

小島啓史小島啓史 <[email protected]><[email protected]>ver. 1.2ver. 1.220132013 年年 77 月月

2Copyright Red Hat K.K. All rights reserved.

はじめに

● 本資料は、 Red Hat Storage Server 2.0 （以降 RHS と記述）を Amazon Web Services （以降 AWS と記述）が提供するクラウドサービス Amazon EC2 上でご利用いただく方法をご紹介しています。※ 1

● 本資料は、レッドハット株式会社が実施する、ハイブリッドクラウドストレージ無料体験キャンペーンを、スムーズにご利用いただく目的で提供していました。※ 2

● 本資料は、お客様が有効な AWS のアカウント及び RHS のサブスクリプションをお持ちであることを前提としています。

● 本資料の個々の項目は、弊社の環境における正確性について検証されていますが、お客様の環境において同様の結果が得られる保証はありません。ご了承願います。

● AWS での RHS や RHEL の活用について、ご興味のある方はお問い合わせ下さい。問い合わせ先は次ページにてご案内しています。

※1. 本資料では 2013 年 7 月時点での情報をご紹介しています。そのため、一部記載内容が最新のものと異なる場合があります。※2. 2014 年 4 月現在、当キャンペーンは終了しています。


お客様からのお問い合わせ先

レッドハットの製品、サービスに関する　ご購入前の一般的なお問い合わせ

< サービス時間 > 平日 9:30 〜 18:00

セールスオペレーションセンター (SOC)

Tel. 0120-266-086( 携帯電話からは 03-5798-8510)e-mail: [email protected]


目次

● Amazon EC2 で RHS の検証環境導入のための準備● SSH の鍵作成とファイアーウォールの設定● EC2 での RHS インスタンスの起動● RHS インスタンスへの更新の適用● RHS インスタンスのデータ領域構築

● Amazon EC2 での RHS 検証ガイド● レプリケーションボリュームの作成● レプリケーションボリュームの拡張● Geo-replication を利用した遠隔バックアップ● フェイルオーバ時の挙動

● Amazon EC2 での RHS のさらなる検証について


SSH の鍵作成とファイアーウォールの設定


設定作業の概要とイメージ図● EC2 上に作成するインスタンス (EC2 上で起動する仮想マシン )

への接続は、 SSH の鍵認証の利用が必須となります。

● ここでは、 SSH の鍵作成とインスタンスへの接続を許可するためのファイアーウォールの設定方法をご紹介します。

Amazon EC2 の東京リージョン

…

インターネット

Windowsクライアント

SSH経由で操作

ファイアーウォールで指定したポート番号を開放

インスタンスインスタンスインスタンス


SSH の鍵作成方法

● EC2 インスタンスへの鍵作成は、 AWS の管理コンソールで行います。 http://console.aws.amazon.com にアクセスします。

● 「 EC2」をクリックします。

ここをクリック



● リージョンを東京と指定します。リージョンとは、 AWS のサービスを配置している各ネットワーク拠点のことを言います。

● 右上のリージョン名をクリックして、「 Asia Pacific (Tokyo)」をクリックします。





● EC2ダッシュボードにアクセスできます。 SSH の鍵を作成するために、「 Key Pairs」をクリックします。




● 「 Create Key Pair」を作成します。デフォルトでは鍵が1 つも作成されていない状態となります。




● 作成する鍵の名前を入力して、「 Create」をクリックします。鍵の名前は任意のもの ( ここでは、 rhs2u0-testkey-tokyo) を指定します。




● 鍵を作成すると、自動で秘密鍵のダウンロードをするポップアップが出てきます。保存先のディレクトリを適当に指定して保存します。

● なお、このタイミングでしか秘密鍵のダウンロードはできませんので、ご注意下さい。


ファイアーウォールの設定方法

● EC2 のインスタンスへのアクセスは、デフォルトの設定だとインスタンス同士の通信以外は全てブロックされていますので、外部からのアクセスに必要なポート番号を開放します。

● 「 Security Groups」をクリックします。




● TCP ポート番号を開放していきます。 Viewing が「 EC2 Security Groups」となっていることを確認し、「 Inbound」をクリックします。

● 「 Port range」にポート番号を入力し、「 Add Rule」をクリックします。

「 EC2 Security Groups」と指定

「 Inbound」をクリック「 Port range」に

ポート番号を入力




● 開放するポート番号の入力が一通り終了したら、「 Apply Rule Changes」をクリックして変更を適用します。


以下の TCP ポートを開放します。　 22 (SSH), 111 (portmap),

24007-24050 (Native クライアント用 ), 38465-38468 (NFS)


EC2 での RHS インスタンスの起動


設定作業の概要とイメージ図

● EC2 の東京リージョンで、 RHS インスタンスを 5台起動します。このうち 1台を RHS のクライアント、 4台を RHS のサーバとし、それぞれ固定 IPアドレス (EIP) を割り当てます。

● EC2 の各リージョンには複数のゾーンが存在します。ゾーンとはリージョンより小さい区画であり、リージョン毎に複数存在します。今回は、東京リージョンの利用可能なゾーンのうち 1つを指定して、 RHS インスタンスを起動します。


利用可能なゾーン (ap-northeast-1a)RHS クライアントRHS サーバー

EIP EIP EIP EIP EIP


RHS インスタンスの起動手順

● EC2 Dashboard で、「 Launch Instance」をクリックします。




● 「 Classic Wizard」を選択して、「 Continue」をクリックします。

ここを選択




● 「My AMIs」 -> 「 Private Images」を選択すると、 AMIのリストが表示 (※) されます。ここでは「 RHEL-6.2-RHS-2.0-x86_64-8」という名前の AMIを選択して、次に進みます。


「My AMIs」 ->「 Private Images」を選択

※「 Response contains invalid JSON 」というエラーメッセージが表示され、 AMIのリストが表示されない場合もあります。その時はリロードしてみて下さい。



● 起動するインスタンスの数を「 5」、 Instance Type を「M1 Large」、 Availability Zone を「 ap-northeast-1a」と指定して、次に進みます。

5 と入力

「M1 Large」を選択

「 ap-northeast-1a」を選択




● Advanced Instance Options は、デフォルトの設定を利用しますので、変更を加えずに先に進みます。




● Storage Device Configuration は、デフォルトの設定を利用しますので、変更を加えずに先に進みます。 RHS のデータ領域の構築は後の手順で行います。




● RHS インスタンスにタグ (key,value のペア ) を付けることができますが、ここではタグを何も付けずに次に進みます。




● 起動する RHS インスタンスへの SSH ログイン時に利用する鍵を指定できます。ここでは、前の手順で作成した「 rhs2u0-testkey-tokyo」を選択し、次に進みます。


「 rhs2u0-testkey-tokyo」を選択


RHS インスタンスの起動手順● インスタンスへのアクセスを許可するためのセキュリティグ

ループは、「 default」を選択し次に進みます。

● セキュリティグループとは、インスタンスへのアクセスを許可するためのファイアーウォールの設定群であり、この「 default」は前の手順で設定したファイアーウォールの設定を含むセキュリティグループとなります。


「 default」を選択



● 「 Launch」をクリックして、 5台の RHS インスタンスを起動します。その後メッセージが表示されるので、「 Close」をクリックします。




● 起動した RHS インスタンスのリストを確認できます。管理性の向上のため、各インスタンスに名前を付けます。

● インスタンスの Name の「 empty」をクリックして、適当な名前を入力して、「 Save」をクリックします。

インスタンスの名前を入力できます。


RHS のインスタンスの起動手順

● 5台の RHS インスタンスの起動が完了しました。ただし、このままでは RHS インスタンスを再起動すると IPアドレスが変わってしまいますので、固定 IPアドレスを各インスタンスに割り当てます。

● 「 Elastic IPs」をクリックします。




● 「 Allocate New Address」をクリックします。




● EIPが使われる場所で「 EC2」を選択し、「 Yes, Allocate」をクリックします。

ここをクリック「 EC2」を選択



● この作業を繰り返して、必要な個数の EIPを作成します。ここでは、 RHS インスタンス 5台にそれぞれ EIPを割り当てますので、 5 つの EIPを作成します。

5 つの EIPを作成



● 作成した EIPを、各インスタンスに割り当てます。対象の EIPを選択して、「 Associate Address」をクリックし、割り当てるインスタンスを選択して、「 Yes, Associate」をクリックします。



インスタンスを選択


RHS インスタンスの起動手順● 同様の作業を繰り返して、各インスタンスに EIPを割り当てます。な

お、インスタンスを停止した場合は、再度 EIPの割り当てが必要になりますので、ご注意下さい。

● 「 Public DNS」の所に外部からインスタンスへアクセスする時に利用するホスト名の一覧が表示されます。以降、これらのホスト名をインスタンスの管理に利用します。

5 つの EIPの割り当て完了

これらのホスト名をインスタンスの管理に利用



● RHS インスタンスにログインする時に、前の手順で作成したSSH の秘密鍵を利用します。 Windows から RHS インスタンスへのログイン方法及びファイルの転送方法については、下記URL をご参照下さい。

● http://docs.aws.amazon.com/ja_ jp/AWSEC2/latest/UserGuide/putty.html

● 各インスタンスにログインした後に、 glusterd サービスが正常に起動しているかどうかを確認します。

[root@ip-10-132-143-88 ~]# service glusterd statusglusterd (pid 897) is running...[root@ip-10-132-143-88 ~]#


RHS インスタンスへの更新の適用


RHS インスタンスへの更新の適用

● EC2 上で起動する RHS インスタンスは、何も設定しなくてもRed Hat から提供する更新を適用可能な状態になっています。

● 起動した RHS インスタンスに SSH でログインして、更新を適用し、インスタンスを再起動します。この作業を、起動したRHS インスタンスの台数分実行します。以下実行例です。

[root@ip-10-132-143-88 ~]# yum -y update; reboot


RHS インスタンスのデータ領域構築



● RHS インスタンスのデータ領域は、各インスタンスに接続したブロックストレージ (EBS: Elastic Block Store) 上に作成します。

● データ領域として利用する 1 個のディレクトリ毎に、 8 個の EBS のRAID0 構成が必要になります。

● こうした構成を取ることで、インスタンスに何らかの障害が発生した場合でも、 EBS とインスタンスは独立しているのでデータが保持されたままになります。

EBS EBS EBS

EBSEBS

EBS EBS

EBS

RHS サーバー

ソフトウェア RAID0



RHS インスタンスのデータ領域構築● 各インスタンスへの EBS の接続は、 Amazon が提供している

Amazon EC2 API Tools を利用します。このツールは、次の URL からダウンロードできます。 (「 Download the Amazon EC2 API Tools 」をクリックして下さい。 )

● http://aws.amazon.com/developertools/351● ec2-api-tools.zip がダウンロードできます。このファイルを解凍し

て、 RHS クライアントに転送し、 /root/に保存します。この開発ツールに含まれるコマンドを RHS クライアントで使用出来るよう環境変数を設定します。以下設定例です。

# cat /root/.bashrc...(略 )...# User specific aliases and functionsexport JAVA_HOME=/usrexport EC2_HOME=/root/ec2-api-toolsexport PATH=$PATH:$EC2_HOME/binexport AWS_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxexport AWS_SECRET_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxexport EC2_URL=https://ec2.ap-northeast-1.amazonaws.com...(略 )...# source /root/.bashrc



● RHS インスタンスのデータ領域として利用する EBS を作成します。 RHS クライアントで次のコマンドを実行して、 ap-northeast-1a というゾーン内に、 1GBのサイズの EBS を 1 個作成します。

● 作成した EBS をインスタンスに接続します。 RHS クライアントで次のコマンドを実行して、 i-a8a03caa という IDを持つインスタンスに、 vol-014faf24という IDを持つ EBS を接続します。なお、インスタンスが扱うデバイス名を /dev/sdb と指定しています。

● 同様の手順を繰り返して、 RHS サーバとして利用予定の各インスタンスに 8個の EBS を接続します。この時適切なボリューム ID、インスタンス ID、デバイス名 (/dev/sdc, /dev/sdd など ) を指定するようにして下さい。

# ec2-create-volume -s 1 -z ap-northeast-1aVOLUME vol-014faf24 1 ap-northeast-1a creating 2013-06-09T11:38:19+0000 standard

# ec2-attach-volume vol-014faf24 -i i-a8a03caa -d /dev/sdbATTACHMENT vol-014faf24 i-a8a03caa /dev/sdb attaching 2013-06-09T11:39:54+0000



● 前の手順で 8 個の EBS を接続した RHS インスタンス上で、ソフトウェア RAID0 を構築します。構築には mdadm を利用します。次のコマンドにより、 mdadmパッケージがインストールされます。

● RHS インスタンス上にソフトウェア RAID0 を構築します。次のコマンドで、 /dev/md0 という名前の RAIDデバイスが構築できます。なお、前の手順で /dev/sdb, /dev/sdc, ... というデバイス名で接続した EBSは、インスタンスからは /dev/xvdb, /dev/xvdc, ... というデバイスファイルとして扱われます。

● 同様の手順を繰り返して、 RHS サーバとして利用予定の各インスタンス上で /dev/md0 という名前の RAIDデバイスを構築します。

# yum -y install mdadm

# mdadm –create /dev/md0 –level=0 –raid-devices=8 /dev/xvd{b,c,d,e,f,g,h,i} mdadm: Defaulting to version 1.2 metadatamdadm: array /dev/md0 started.# mdadm –examine-scan > /etc/mdadm.conf# cat /etc/mdadm.confARRAY /dev/md/0 metadata=1.2 UUID=xxxxxxxxxxxxx name=ip-10-132-150-175:0



● 各インスタンスに接続した EBS に、管理性の向上のため、タグを付けていきます。 RHS クライアントで次のコマンドを実行して、 vol-014faf24 という IDを持つ EBS にタグを付けます。

● 「 Device」は、 EBS をインスタンスに接続する時に指定したデバイス名を指定します。

● 「 Instance」は、 EBS をインスタンスに接続する時に指定したインスタンス IDを指定します。

● 「 Array」は、 /etc/mdadm.confに保存した UUIDを指定します。

● 同様の手順を繰り返して、各 EBS にタグを付けていきます。

# ec2-create-tags vol-014faf24 --tag Domain=gluster --tag Device=/dev/sdb \--tag Instance=i-a8a03ca --tag Array=xxxxxxxxxxTAG volume vol-014faf24 Domain glusterTAG volume vol-014faf24 Device /dev/sdbTAG volume vol-014faf24 Instance i-a8a03caTAG volume vol-014faf24 Array xxxxxxxxxx



● EBS に付けたタグは、 EC2 のボリューム情報を表示することで確認できます。

タグの Keyタグの Key タグの value


RHS インスタンスのデータ領域構築● RHS インスタンス上に作成した RAIDデバイス /dev/md0 を利用して、論理ボリューム及び XFS を作成し、ディレクトリにマウントします。

● RHS サーバとして利用するインスタンス上で、シェルスクリプト「 xfs-on-lvm.sh」を作成して実行します。

# cat <<EOF > xfs-on-lvm.sh> #!/bin/bash> > pvcreate /dev/md0> vgchange glustervg /dev/md0> vgchange -a y glustervg> lvcreate -a y -l 100%VG -n glusterlv glustervg> > mkfs.xfs -i size=512 /dev/glustervg/glusterlv> mkdir -p /exports/bricks> echo "/dev/glustervg/glusterlv /exports/bricks xfs defaults 0 2" >> /etc/fstab> mount /dev/glustervg/glusterlv> EOF# chmod u+x xfs-on-lvm.sh# ./xfs-on-lvm.sh


レプリケーションボリュームの作成


設定作業の概要とイメージ図● RHS サーバとして利用するインスタンスを 2台利用して、レプリ

ケーションボリュームを作成します。 RHS で作成したボリュームは、クライアントから共有ファイルシステムとして利用できます。

● 作成したレプリケーションボリュームをクライアントからマウントし、ファイルの作成を行います。

レプリケーションレプリケーションボリューム

RHS クライアントRHS サーバー

マウント




● ここで利用するインスタンスは、次の 3台となります。

RHS クライアントとして利用

RHS サーバとして利用

各インスタンスに割り当てている EIPを利用


レプリケーションボリュームの作成● 「 tokyo-1a-node01」、「 tokyo-1a-node02」と名前を付け

ているインスタンスにログインして、次のコマンドを実行し、「 replbrick」というディレクトリを作成します。

● 「 tokyo-1a-node01」上で、次のコマンドを実行し、「 tokyo-1a-node01」、「 tokyo-1a-node02」の 2台のサーバでTrusted Storage Pool(RHS サーバのクラスター ) を構成します。

# mkdir /exports/bricks/replbrick

# gluster peer statusNo peers present# gluster peer probe ec2-54-250-127-139.ap-northeast-1.compute.amazonaws.comProbe successful# gluster peer statusNumber of Peers: 1Hostname: ec2-54-250-127-139.ap-northeast-1.compute.amazonaws.comPort: 24007Uuid: xxxxxxxxxxxxxxState: Peer in Cluster (Connected)

「 tokyo-1a-node02」の EIP

クラスターの Peer を確認できます。


レプリケーションボリュームの作成● 構成した Trusted Storage Pool を利用して、「 replvol」という名前の

レプリケーションボリュームを作成します。「 replica 2」を指定して、 2重のレプリケーション構成とします。

● 次のコマンドで、 replvol の情報 (名前、ボリュームのタイプ、状態、ブリック ) を確認できます。ブリックとはボリュームを構成する単位であり、サーバ名とディレクトリの絶対パスのペアで表示されます。

# gluster volume create replvol replica 2 \ ec2-54-250-127-131.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrick \ec2-54-250-127-139.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrickCreation of volume replvol has been successful. Please start the volume to access data.# gluster volume start replvolStarting volume replvol has been successful

# gluster volume info replvolVolume Name: replvolType: ReplicateVolume ID: xxxxxxxxxxxxxxxxxxxxxxxxxStatus: StartedNumber of Bricks: 1 x 2 = 2Transport-type:tcpBricks:Brick1: ec2-54-250-127-131.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrickBrick2: ec2-54-250-127-139.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrick

node01, node02 の EIPとディレクトリの絶対パスを指定



● RHS クライアントにログインして、作成した replvol をマウントします。 mount のタイプを glusterfs 、「 node01 のEIP:/replvol」をマウント元として指定します。

# mount -t glusterfs ec2-54-250-127-131.ap-northeast-1.compute.amazonaws.com:/replvol /mnt# df -hFilesystem Size Used Avail Use% マウント位置/dev/xvda1 99G 1.5G 97G 2% /none 3.6G 0 3.6G 0% /dev/shmec2-54-250-127-131.ap-northeast-1.compute.amazonaws.com:/replvol

8.0G 33M 8.0G 1% /mnt



● RHS クライアントで、 replvol のマウント先にファイルを作成し、ブリックとして指定した node01, node02 のディレクトリに保存されていることを確認してみて下さい。以下実行例です。

※RHS クライアントで実行# for i in /mnt/file{1..10}.txt; do date > $i; done# ls /mntfile1.txt file2.txt file4.txt file6.txt file8.txtfile10.txt file3.txt file5.txt file7.txt file9.txt

※node01 または node02 で実行# ls /exports/bricks/replbrickfile1.txt file2.txt file4.txt file6.txt file8.txtfile10.txt file3.txt file5.txt file7.txt file9.txt


レプリケーションボリュームの拡張



● 前の手順で作成しましたレプリケーションボリューム「 replvol」に、 2 つのブリックを追加して拡張します。

● 拡張した「 replvol」で、ファイルの分散配置が正常に行われること、ファイルの再配置が可能なことを確認します。

レプリケーションreplvol (Distributed-Replicate タイプのボリューム )

RHS クライアント RHS サーバー

マウント


レプリケーション



● 拡張のために利用するインスタンスは、次の 2台となります。

replvol の拡張に利用

各インスタンスに割り当てている EIPを利用



● 「 tokyo-1a-node03」、「 tokyo-1a-node04」インスタンスにログインして、 replvol の拡張に利用するディレクトリを新規に作成します。

● node03, node04 を、既存の Trusted Storage Pool に参加させます。次のコマンドを node01 上で実行します。

# mkdir /exports/bricks/replbrick

# gluster peer probe ec2-54-250-127-141.ap-northeast-1.compute.amazonaws.comProbe Successful# gluster peer probe ec2-54-250-127-152.ap-northeast-1.compute.amazonaws.comProbe Successful# gluster peer statusNumber of Peers: 3... (略 ) ...



● node01 上で次のコマンドを実行し、 node03, node04 のブリックを追加して replvol を拡張します。

● replvol は 2重のレプリケーション構成を取っているので、追加するブリックの数は 2 の倍数を指定する必要があります。例えば、 1 つだけブリックを追加すると、エラーが返ってきて追加できません。

# gluster volume add-brick replvol \ec2-54-250-127-141.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrick \ec2-54-250-127-152.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrickAdd Brick Successful# gluster volume info replvolVolume Name: replvolType: Distributed-ReplicateVolume ID: xxxxxxxxxxxxxxxxxxxxxxxxxStatus: StartedNumber of Bricks: 2 x 2 = 4Transport-type:tcpBricks:Brick1: ec2-54-250-127-131.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrickBrick2: ec2-54-250-127-139.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrickBrick3: ec2-54-250-127-141.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrickBrick4: ec2-54-250-127-152.ap-northeast-1.compute.amazonaws.com:/exports/bricks/replbrick

node03,node04 のブリックを指定

Brick1,2 、 Brick3,4 がレプリケーション構成を取っています。

作成されたファイルは、 Brick1,2 、 Brick3,4 にファイル名に応じて分散保存されます。



● node01, node02 のブリックに保存されているファイルの再配置処理を実行したい場合は、次のコマンドで rebalance を実行します。以下実行例です。

● rebalance を実行した後に node01~node04 のブリックを見ることで、ファイルの再配置が正常に行われていることを確認できます。

● これ以降作成されたファイルは、 node01~node04 のブリックに分散保存されることを確認できます。

※node01 で実行# gluster volume rebalance replvol start forceStarting rebalance on volume replvol has been successful# gluster volume rebalance replvol status

Node Rebalanced-files size scanned failures status---------- ----------------- ---- -------- -------- -------localhost 7 301 27 0 completedec2-54-250-127-139...com 0 0 20 0 completedec2-54-250-127-152...com 0 0 20 0 completedec2-54-250-127-141...com 0 0 20 0 completed

force オプションを付ける必要があります。

rebalance の完了


Geo-replication を利用した遠隔バックアップ



● これまで作成してきた「 replvol」の遠隔地へのバックアップ設定を行います。この機能を Geo-replication と言います。

● バックアップ先は、シンガポールリージョンに作成したボリューム「 slavevol」とします。「 slavevol」は、 2台のインスタンスを利用して作成しているレプリケーションボリュームです。

● バックアップは、各クラスターの代表ノードの間で行われます。設定は各代表ノードで行います。

レプリケーションreplvol ( マスター )

レプリケーションレプリケーションslavevol ( スレーブ )

代表ノード代表ノード

東京リージョンシンガポールリージョン

Geo-replication


Geo-replication を利用した遠隔バックアップ● 予め、シンガポールリージョンの同一ゾーン内で 2台の RHS インス

タンスを起動し、レプリケーションボリューム slavevol を構築しておきます。

● slavevol の容量はバックアップ元の replvolより大きくなるように、データ領域のサイズを指定して下さい。

slavevol の作成に利用

シンガポールリージョン



● Geo-replication でのデータ転送は、 SSH でトンネリングすることで暗号化されます。そのために利用する SSH の鍵を、東京リージョンの node01 で次のコマンドを実行して作成します。

● この時、パスフレーズの入力が求められますが、何も入力せずにEnter キーを押して下さい。

● 続いて、リモートコマンドを制限するために次のコマンドを実行します。

※東京リージョンの node01 で実行# ssh-keygen -f /var/lib/glusterd/geo-replication/secret.pem

※東京リージョンの node01 で実行# sed -i 's|^|command=”/usr/libexec/glusterfs/gsyncd” |' /var/lib/glusterd/geo-replication/secret.pem.pub



● シンガポールリージョンの node01 上で、 SSH接続を受けるアカウントを作成します。ユーザ名を geouser とし、所属グループを geogroup とします。

● 東京リージョンの node01 上で作成した SSH の公開鍵を、シンガポールリージョンの node01 に保存します。

※ シンガポールリージョンの node01 で実行# groupadd geogroup# useradd -G geogroup geouser# echo xxxx |passwd --stdin geouser

※ シンガポールリージョンの node01 で実行# su - geouser[geouser ~]$ mkdir /home/geouser/.ssh[geouser ~]$ touch /home/geouser/.ssh/authorized_keys※authorized_keys に作成した公開鍵 (secret.pem.pub) の内容をコピー[geouser ~]$ cat /home/geouser/.ssh/authorized_keyscommand="/usr/libexec/glusterfs/gsyncd" ssh-rsa xxxxx.......(略 )...[geouser ~]$ chmod 700 /home/geouser/.ssh[geouser ~]$ chmod 600 /home/geouser/.ssh/authorized_keys

公開鍵を保存するディレクトリとファイルのパーミッションを変更します。



● 続いて、 geouser という一般ユーザでも slavevol をマウントできるよう設定します。設定後は、変更を適用するために glusterd サービスを再起動します。

● この時、 mountbroker-root オプションによって、 /var/mountbroker-root/md_hive というディレクトリが作成されます。これが無いと Geo-replication の開始に失敗しますので、誤ってこのディレクトリを削除した際は、 glusterd サービスの再起動を行なって再作成して下さい。

※ シンガポールリージョンの node01 で実行# mkdir -p /var/mountbroker-root# cat /etc/glusterfs/glusterd.volvolume management

type mgmt/glusterdoption working-directory /var/lib/glusterdoption transport-type socket,rdmaoption transport.socket.keepalive-time 10option transport.socket.keepalive-interval 2option transport.socket.read-fail-log off

option mountbroker-root /var/mountbroker-rootoption mountbroker-geo-replication.geouser slavevoloption geo-replication-group geogroup

end-volume# service glusterd restart

この 3 つの option が追加部分となります。

ユーザ名、グループ名、ボリューム名を、

geouser, geogroup, slavevolと指定します。



● 東京リージョンの node01 上で、次のコマンドを実行して Geo-replication を開始します。バックアップ元のボリューム名を「 replvol」、バックアップ先を、「 geouser@ シンガポールリージョンの node01 の EIP::slavevol」、と指定します。

※東京リージョンの node01 で実行# gluster volume geo-replication replvol [email protected].\compute.amazonaws.com::slavevol startStarting geo-replication session between replvol & [email protected]::slavevolhas been successful# gluster volume geo-replication replvol [email protected].\compute.amazonaws.com::slavevol statusMASTER SLAVE STATUS----------------------------------------------------------------------------replvol [email protected]::slavevol starting...

※ しばらく待ちます…。# gluster volume geo-replication replvol [email protected].\compute.amazonaws.com::slavevol statusMASTER SLAVE STATUS----------------------------------------------------------------------------replvol [email protected]::slavevol OK

Geo-replication を開始しています。

Geo-replication が無事開始されました。



● マスターボリュームとなる「 replvol」、スレーブボリュームとなる「 slavevol」を、東京リージョンの RHS クライアントの適当なディレクトリにマウントします。

● replvol のマウント先 (/mnt/master) で保存されているファイルと同じものが、 slavevol のマウント先 (/mnt/slave) に保存されていることを確認します。

● replvol のマウント先 (/mnt/master) でファイルの作成 / 削除が発生すると、 slavevol のマウント先 (/mnt/slave) でも同じファイルが作成 / 削除されることを確認できます。

※東京リージョンの RHS クライアントで実行# umount /mnt# mkdir -p /mnt/{master,slave}# mount -t glusterfs ec2-54-250-127-131.ap-northeast-1.compute.amazonaws.com:/replvol /mnt/master# mount -t glusterfs ec2-46-137-207-232.ap-southeast-1.compute.amazonaws.com:/slavevol /mnt/slave


フェイルオーバ時の挙動



● レプリケーション構成を取っていて、 RHS サーバに障害が発生した時のフェイルオーバ時の挙動を確認します。

● 東京リージョンの RHS サーバを停止しても、継続してファイルへのアクセスが出来るかどうか、また RHS サーバの再び起動した時に、ファイルの再レプリケーションが正常に出来るかどうか確認します。

レプリケーションreplvol (マスター )

レプリケーションレプリケーションslavevol ( スレーブ )

代表ノード代表ノード


Geo-replication

停止 -> 起動を実行してみます。



● 停止 /起動の対象とするのは、東京リージョンの node01とします。この node01 は、前の手順で設定した Geo-replication を実行するための代表ノードです。

node01 を対象とします。



● node01 を停止します。「 Actions」をクリックします。ここをクリック



● 「 Stop」をクリックします。




● インスタンスを止めていいかどうか確認するメッセージが表示されますので、「 Yes, Stop」をクリックします。しばらく待つと、 node01 が停止します。




● なお、マウント元のサーバが落ちた状態でもマウント出来るよう、バックアップ先のサーバを backupvolfile-server で指定できます。以下のコマンドでは、東京リージョンの node02 をバックアップ先のサーバとして指定しています。

● backupvolfile-server オプションは、 RHS の native クライアント (glusterfs) 利用時のみ指定できます。 NFS/CIFS クライアント利用時には指定できません。

※東京リージョンの RHS クライアントで実行# mkdir -p /mntpoints# mount -t glusterfs -o backupvolfile-server=ec2-54-250-127-139...com \ec2-54-250-127-131...com:/replvol /mntpoints# df -h...(略 )...ec2-54-250-127-131...com:/replvol 16G 66M 16G 1% /mnt/masterec2-54-250-127-139...com:/replvol 16G 66M 16G 1% /mntpoints...(略 )...

node02 のEIPを指定



● 東京リージョンの node01 が停止した状態でも、 replvol のマウント先 (/mnt/master) にファイルを正常に作成できることを確認します。

● 東京リージョンの node02, node03 にログインし、各サーバのブリックに保存されているファイルを確認します。ファイルが分散保存されていることを確認します。

※東京リージョンの RHS クライアントで実行# for i in /mnt/master/file{11..20}.txt; do date > $i; done# ls /mnt/masterfile1.txt file13.txt file17.txt file20.txt file6.txtfile10.txt file14.txt file18.txt file3.txt file7.txtfile11.txt file15.txt file19.txt file4.txt file8.txtfile12.txt file16.txt file2.txt file5.txt file9.txt

※東京リージョンの node02 で実行# ls /exports/bricks/replbrickfile12.txt file17.txt file20.txt file6.txtfile13.txt file18.txt file4.txt file8.txt

※東京リージョンの node03 で実行# ls /exports/bricks/replbrickfile1.txt file11.txt file15.txt file19.txt file3.txt file7.txtfile10.txt file14.txt file16.txt file2.txt file5.txt file9.txt



● 東京リージョンの node01 を再び起動します。 node01 のチェックボックスにチェックを入れて、「 Actions」をクリックします。




● 「 Start」をクリックします。



フェイルオーバ時の挙動● インスタンスを起動していいか確認するメッセージが表示されますの

で、「 Yes, Start」をクリックします。作成済みの EIPを node01 に割り当てて、 node01 の起動が完了するまで待ちます。



フェイルオーバ時の挙動● 東京リージョンの node01 にログインして、 node01 が停止し

ていた時に作成されたファイルは、 node01 のブリックに作成されていないことを確認します。

● replvol はレプリケーション構成を取っているので、ファイルの再レプリケーションを次のコマンドで実行できます。

※東京リージョンの node01 で実行# gluster volume heal replvol fullHeal operation on volume replvol has been successful # gluster volume heal replvol infoHeal operation on volume replvol has been successful

Brick ec2-54-250-127-131...com:/exports/bricks/replbrickNumber of entries: 0





フェイルオーバ時の挙動● もし、再レプリケーションが正常に行われなかった場合、以下のよう

なメッセージが表示されることがあります。その場合は、復旧サーバ( ここでは東京リージョンの node01) で glusterd サービスを再起動した後に、再レプリケーションを実行してみて下さい。

● また、 slavevol(replvol のバックアップ先 ) のマウント先のディレクトリを見ることで、 replvol のファイルと同じものが保存されていることを確認できます。これにより、前の手順で設定した Geo-replication が継続して動作していることを確認できます。

※東京リージョンの node01 で実行# gluster volume heal replvol fullHeal operation on volume replvol has been unsuccessful # gluster volume heal replvol infoHeal operation on volume replvol has been successful

Brick ec2-54-250-127-131...com:/exports/bricks/replbrickNumber of entries: 0Status Brick is Not connected...(略 )...

# service glusterd restart# gluster volume heal replvol fullHeal operation on volume replvol has been successful

node01 のブリックが正常に接続されていないというメッセージが表示されています。


Amazon EC2 での RHS のさらなる検証について


概要とイメージ図

● 今まで紹介してきた手順は、全てのインスタンスをリージョン内の同一ゾーン内で起動することを前提としてきました。

● さらに進んだ検証構成として、レプリケーション構成を取るインスタンスを、それぞれ違うゾーンで起動する構成があります。各ゾーンは物理的に独立しているので、より冗長性を高めることができます。こちらの構成もぜひお試し下さい。

レプリケーションreplvol ( マスター )

レプリケーション

レプリケーションslavevol ( スレーブ )


Geo-replication

ap-southeast-1aap-northeast-1bap-northeast-1a ap-southeast-1b


動画

● 本資料でご紹介しました作業手順を、字幕付きの動画として収録したものを YouTube にアップロードしていますので、合わせてご参照下さい。

● https://www.youtube.com/playlist?list=PLgT9pz799l7FSOcww8diEs3h_VH_zrNic


参考文献● RHS の製品ドキュメント

● http://access.redhat.com/site/documentation/Red_Hat_Storage/

● How to Use Red Hat Storage Server Subscriptions for Public and Hybrid Cloud in AWS

● RHS のサブスクリプションを AWS 上で有効にする方法を記載しています。

● https://access.redhat.com/site/articles/145693

● Red Hat Storage Server Knowledge Base

● RHS に関する Knowledge Base の一覧です。

● https://access.redhat.com/site/products/red-hat-storage-server

● Amazon EC2 の CLI Tools のセットアップ手順です。

● http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SettingUp_CommandLine.html

● Amazon EC2 の CLI Tools のコマンド一覧です。

● http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/command-reference.html

red hat storage server 2.0 on amazon ec2 導入ガイド

Technology