Amazon EC2 インスタンスを1からコマンドラインで立ててみる(その2:EC2インスタンスを立てる前にすること) [Amazon AWS]
では、awsコマンドが使用出来るようになったところで、インスタンスを立てる前の準備にとりかかりたいと思います。
詳しい事は、そのスジな書籍あるいはそのスジなblogあるいはGoogle先生等を調べてもらうとして、まっさらな状態から「やっておいた方が良い作業」にとりかかります。それは以下の2点です。
その1:「ロール」を作成しておく
この作業は省略しても一向に差し支え有りません。その場合は「デフォルト」のロールを割り当てられることになります。しかし、後日「ロールを変更したいなあ」という事になった際に不便なので(そして、大抵は「変更したいなあ」ということになる)、デフォルトのロールとは別に最低1個、「自分用のデフォルトロール」を作成しておくと良いです。
なお、インスタンスにロールを割り当てたり、変更したりすることが出来るのは、今のところは「インスタンスを作成するタイミングだけ」みたいです。もし、後日「他のロールを割り当てたい」なんてことになると、インスタンスを作り直すところから始めることになってしまいます。残念ながら。
改善するといいんだけどねえ!!!
その2:「セキュリティグループ」を作成しておく
セキュリティグループはまあ要するに「ファイヤーウォール」的な何かといったところです。どのプロトコルを通すか、あるいはそのアドレスからのアクセスは通すかといったことをここで制御することになります。これも、「自分用のデフォルトセキュリティグループ」を作成しておくと良いです。
自分の会社・自宅からのsshだけ通す…みたいな感じで。
というわけで、はりきって参りたいと思います。
まずは「ロール」を新しく作成します。細かいアクセス制御は後ほど作成するとして、ひとまず「からっぽ」のロールを作成します。
JSON型式でカラッポのロールを定義します。内容はこんな感じ。
で、これをawsコマンドに読み込ませます。
aws iam create-role --role-name (ロールの名前) --assume-role-policy-document file://(ロールを書いたファイル名)
てな感じです。実行して問題が無ければこんな感じになります。
現在、どんなロールが作成済みなのかを確認するのは aws iam list-roles コマンドです。
続いて、セキュリティグループを作成します。まずはカラッポのセキュリティグループを新しく作成します。
こちらはコマンド一発です。
aws ec2 create-security-group --group-name (セキュリティグループの名前) --description (メモ)
これ、--descriptionは省略できないぽいですね??
こんな感じで実行できます。
セキュリティグループの確認は aws ec2 describe-security-groups です。
なお、EC2インスタンスに対するアクセスは、「セキュリティグループに書いたトラフィックだけ許可」されるので、このままでは誰も何も出来ないことになってしまいます。そこで、ひとまずは少なくともsshだけは出来るようにしておく必要があります。あるいは、「特定のIPアドレスからだけアクセスを許可」的な方向でも構わないと思いますが。
IPアドレスが固定出来ている場合は、次のようなコマンドを使用してセキュリティグループに定義を追加します。
aws ec2 authorize-security-group-ingress --group-name (セキュリティグループ名) --protocol tcp --port 22 --cidr アクセス元のIPアドレス
なお、IPアドレス帯で許可したい場合は、「--cidr」の部分を適切に変更してください。
ご家庭などでIPアドレスを固定出来ない場合は、残念ながら「バッチコイ」状態にする必要が出てきます。ちょっと怖いですが仕方が無いので「0.0.0.0/0」とすることになります。こんな感じ。
aws ec2 authorize-security-group-ingress --group-name sg_piro791_test --protocol tcp --port 22 --cidr 0.0.0.0/0
ちなみに、「アドレス間違えちゃった!」とか、「IPアドレスが変わったので変更したい!」という場合は、正しい(新しい)アドレスの許可を設定した後で、誤った(古い)アドレスの許可設定を削除することになります。削除するのは次のコマンド。
aws ec2 revoke-security-group-ingress --group-name (セキュリティグループ名) --protocol tcp --port 22 --cidr (許可を取り消したいアドレス
詳しい事は、そのスジな書籍あるいはそのスジなblogあるいはGoogle先生等を調べてもらうとして、まっさらな状態から「やっておいた方が良い作業」にとりかかります。それは以下の2点です。
その1:「ロール」を作成しておく
この作業は省略しても一向に差し支え有りません。その場合は「デフォルト」のロールを割り当てられることになります。しかし、後日「ロールを変更したいなあ」という事になった際に不便なので(そして、大抵は「変更したいなあ」ということになる)、デフォルトのロールとは別に最低1個、「自分用のデフォルトロール」を作成しておくと良いです。
なお、インスタンスにロールを割り当てたり、変更したりすることが出来るのは、今のところは「インスタンスを作成するタイミングだけ」みたいです。もし、後日「他のロールを割り当てたい」なんてことになると、インスタンスを作り直すところから始めることになってしまいます。残念ながら。
改善するといいんだけどねえ!!!
その2:「セキュリティグループ」を作成しておく
セキュリティグループはまあ要するに「ファイヤーウォール」的な何かといったところです。どのプロトコルを通すか、あるいはそのアドレスからのアクセスは通すかといったことをここで制御することになります。これも、「自分用のデフォルトセキュリティグループ」を作成しておくと良いです。
自分の会社・自宅からのsshだけ通す…みたいな感じで。
というわけで、はりきって参りたいと思います。
まずは「ロール」を新しく作成します。細かいアクセス制御は後ほど作成するとして、ひとまず「からっぽ」のロールを作成します。
JSON型式でカラッポのロールを定義します。内容はこんな感じ。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": { "Service": "ec2.amazonaws.com" } } ] }
で、これをawsコマンドに読み込ませます。
aws iam create-role --role-name (ロールの名前) --assume-role-policy-document file://(ロールを書いたファイル名)
てな感じです。実行して問題が無ければこんな感じになります。
[root@maya tmp]# aws iam create-role --role-name piro791_test --assume-role-policy-document file://piro791.role.json { "Role": { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" } } ] }, "RoleId": "XXXXXXXXXX", "CreateDate": "2014-08-21T06:35:24.631Z", "RoleName": "piro791_test", "Path": "/", "Arn": "arn:aws:iam::XXXXXXXXXXXX:role/piro791_test" } } [root@maya tmp]#
現在、どんなロールが作成済みなのかを確認するのは aws iam list-roles コマンドです。
[root@lelouch src]# aws iam list-roles { "Roles": [ { "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Action": "sts:AssumeRole", "Principal": { "Service": "ec2.amazonaws.com" }, "Effect": "Allow", "Sid": "" } ] }, "RoleId": "XXXXXXXXXXXXXXXXXXXXXX", "CreateDate": "2014-08-21T06:35:24Z", "RoleName": "piro791_test", "Path": "/", "Arn": "arn:aws:iam::XXXXXXXXXXXX:role/nakui_test" } ] }
続いて、セキュリティグループを作成します。まずはカラッポのセキュリティグループを新しく作成します。
こちらはコマンド一発です。
aws ec2 create-security-group --group-name (セキュリティグループの名前) --description (メモ)
これ、--descriptionは省略できないぽいですね??
[root@maya tmp]# aws ec2 create-security-group --group-name sg_piro791_test --description "My Security Group" { "return": "true", "GroupId": "sg-XXXXXXXX" }
こんな感じで実行できます。
セキュリティグループの確認は aws ec2 describe-security-groups です。
[root@lelouch src]# aws ec2 describe-security-groups { "SecurityGroups": [ { "IpPermissionsEgress": [], "Description": "My Security Group", "IpPermissions": [], "GroupName": "sg_piro791_test", "OwnerId": "XXXXXXXXXXXX", "GroupId": "sg-XXXXXXXX" } ] }
なお、EC2インスタンスに対するアクセスは、「セキュリティグループに書いたトラフィックだけ許可」されるので、このままでは誰も何も出来ないことになってしまいます。そこで、ひとまずは少なくともsshだけは出来るようにしておく必要があります。あるいは、「特定のIPアドレスからだけアクセスを許可」的な方向でも構わないと思いますが。
IPアドレスが固定出来ている場合は、次のようなコマンドを使用してセキュリティグループに定義を追加します。
aws ec2 authorize-security-group-ingress --group-name (セキュリティグループ名) --protocol tcp --port 22 --cidr アクセス元のIPアドレス
[root@maya tmp]# aws ec2 authorize-security-group-ingress --group-name sg_piro791_test --protocol tcp --port 22 --cidr 123.45.67.89/32 { "return": "true" }
なお、IPアドレス帯で許可したい場合は、「--cidr」の部分を適切に変更してください。
ご家庭などでIPアドレスを固定出来ない場合は、残念ながら「バッチコイ」状態にする必要が出てきます。ちょっと怖いですが仕方が無いので「0.0.0.0/0」とすることになります。こんな感じ。
aws ec2 authorize-security-group-ingress --group-name sg_piro791_test --protocol tcp --port 22 --cidr 0.0.0.0/0
ちなみに、「アドレス間違えちゃった!」とか、「IPアドレスが変わったので変更したい!」という場合は、正しい(新しい)アドレスの許可を設定した後で、誤った(古い)アドレスの許可設定を削除することになります。削除するのは次のコマンド。
aws ec2 revoke-security-group-ingress --group-name (セキュリティグループ名) --protocol tcp --port 22 --cidr (許可を取り消したいアドレス
[root@maya tmp]# aws ec2 revoke-security-group-ingress --group-name sg_piro791_test --protocol tcp --port 22 --cidr 123.45.67.89/32 { "return": "true" }
Amazon EC2 インスタンスを1からコマンドラインで立ててみる(その1:事前準備編) [Amazon AWS]
パブリッククラウドの雄(?)であるAmazon AWS、便利ですよねー。とっても便利ですよねー。あまりにも便利すぎてインフラ屋さんとしては堕落してしまうくらい便利ですよねー。(笑)
さて、その便利でたまらないAmazon AWSの、EC2インスタンスを1から調き…じゃない、セットアップして育ててみたいと思いますが、便利な(でもしょっちゅう改造されてイラッとさせられる)GUIをあえて使わずに、漢らしく(?)全部CLIで解決したいと思います。(笑)
で、WindowsからでもCLI操作はできるのですが、個人的な趣味嗜好・宗教上の事情によりLinux上で操作する方向でまいります。(笑)
あと、Amazon AWSアカウントのサインアップについてはどうしようもないのでブラウザからなんとかしてください。(笑)ここでは、Amazon AWSのアカウントが取得できており、
・AWSアクセスキー
・AWSシークレットキー
の取得が終わっていることを前提にしています。あ、あと自分で好き勝手なことが出来るLinux環境があると言う点も大前提です。(イマドキのMacでも良いかもしんないけど。)
手順としてはこんな感じです。なお、まずはVPCを使用しない編で参ります。VPCを使用する編は後日記事を作成したいと思います。
事前準備:
1:コマンドラインインタフェースのセットアップ
EC2インスタンスを立てる前にすること:
2:「ロール」を作成しておく
3:「セキュリティグループ」を作成する
EC2インスタンスを作成する:
4:EC2インスタンスを作成する
EC2インスタンスを作成したらすること:
5:必要な設定を入れ込む
まずは、操作に必要なコマンドラインインタフェースをインストールします。
「awscli」と呼ばれる物を使用しますが、これはpython 2.6以降が必要です。まあ、大抵入っていると思います。検証環境として、インストールしたばっかりのCentOS7 を使用しましたが、入っていました。
「pip」というコマンドを使ってインストールするのですが、まっさらな状態だとコレが入っていないようなので、コイツのインストールから始めます。
チョー簡単です。
easy_install pip
こんだけ。これでOK。easy_installはイマドキのpythonインストール済み環境なら最初から入っていると思いますが、もし入っていない場合、あるいはpythonのバージョンが古い場合、あるいはyumとかでなく手でbuildしてインストールしたような場合は、Google先生に教えを請うなり、そのスジのサイトを見るなどして自分でどうにかしてください。(笑)
こうしてpipがインストールできたら、続いてawscliのインストールにとりかかります。これもチョー簡単です。
pip install awscli
こんだけ。
いろいろゴチャゴチャーっと出力されますが、内容は気にしなくても大丈夫。タブン。
インストールが終わったら、awsコマンドが使用出来るかどうか確認しましょう。
aws help
と打ってみてヘルプが出れば今はとりあえずOK。
ただし、このままではまだawsコマンドは正常に機能しません。「アクセスキー」と「シークレットキー」を設定しなければなりません。そこで、
aws configure
を実行します。
AWS Access KEY IDとAWS Secret Access Keyは、AWSにサインアップした時に発行されているものです。Web上から確認することが出来るので確認しておいてください。上記例では「HOGEHOGE」とか「HOGEHOGEHOGEHOGE」とか書いていますが、その部分に各自のソレを当てはめてください。
Default region name は、AWSのクラウド環境は世界各地に配置されていますが、その「どこにある環境」を使うか?という指定をするものです。ここで指定しなくても良いのですが、いちいち指定するのが面倒臭いので、日本人なら東京にあるリージョンを使うだろ!という人は、上記の通りap-northeast-1と入力しておきましょう。
Default output format は何も指定せずにEnter一発で良いです。なお、ここで無指定だとJSON型式で結果が得られることになります。
ところでこのJSON型式。シェルスクリプト書きには邪悪なテキストフォーマットであると思いますので、これをよろしくパースしてくれるツールが欲しくなります。一般的には
jq
というパーサを使うとハッピーになれますので、これが無い場合はインストールしましょう。tarballを入手してbuildしてもいいし、yumやらaptでゲットできるならそれでも構いません。
さて、その便利でたまらないAmazon AWSの、EC2インスタンスを1から調き…じゃない、セットアップして育ててみたいと思いますが、便利な(でもしょっちゅう改造されてイラッとさせられる)GUIをあえて使わずに、漢らしく(?)全部CLIで解決したいと思います。(笑)
で、WindowsからでもCLI操作はできるのですが、個人的な趣味嗜好・宗教上の事情によりLinux上で操作する方向でまいります。(笑)
あと、Amazon AWSアカウントのサインアップについてはどうしようもないのでブラウザからなんとかしてください。(笑)ここでは、Amazon AWSのアカウントが取得できており、
・AWSアクセスキー
・AWSシークレットキー
の取得が終わっていることを前提にしています。あ、あと自分で好き勝手なことが出来るLinux環境があると言う点も大前提です。(イマドキのMacでも良いかもしんないけど。)
手順としてはこんな感じです。なお、まずはVPCを使用しない編で参ります。VPCを使用する編は後日記事を作成したいと思います。
事前準備:
1:コマンドラインインタフェースのセットアップ
EC2インスタンスを立てる前にすること:
2:「ロール」を作成しておく
3:「セキュリティグループ」を作成する
EC2インスタンスを作成する:
4:EC2インスタンスを作成する
EC2インスタンスを作成したらすること:
5:必要な設定を入れ込む
まずは、操作に必要なコマンドラインインタフェースをインストールします。
「awscli」と呼ばれる物を使用しますが、これはpython 2.6以降が必要です。まあ、大抵入っていると思います。検証環境として、インストールしたばっかりのCentOS7 を使用しましたが、入っていました。
[root@maya ~]# python -V Python 2.7.5
「pip」というコマンドを使ってインストールするのですが、まっさらな状態だとコレが入っていないようなので、コイツのインストールから始めます。
チョー簡単です。
easy_install pip
こんだけ。これでOK。easy_installはイマドキのpythonインストール済み環境なら最初から入っていると思いますが、もし入っていない場合、あるいはpythonのバージョンが古い場合、あるいはyumとかでなく手でbuildしてインストールしたような場合は、Google先生に教えを請うなり、そのスジのサイトを見るなどして自分でどうにかしてください。(笑)
[root@maya ~]# easy_install pip Searching for pip Reading https://pypi.python.org/simple/pip/ Best match: pip 1.5.6 Downloading https://pypi.python.org/packages/source/p/pip/pip-1.5.6.tar.gz#md5=01026f87978932060cc86c1dc527903e Processing pip-1.5.6.tar.gz Writing /tmp/easy_install-37JC3L/pip-1.5.6/setup.cfg Running pip-1.5.6/setup.py -q bdist_egg --dist-dir /tmp/easy_install-37JC3L/pip-1.5.6/egg-dist-tmp-OecBVR warning: no files found matching 'pip/cacert.pem' warning: no files found matching '*.html' under directory 'docs' warning: no previously-included files matching '*.rst' found under directory 'docs/_build' no previously-included directories found matching 'docs/_build/_sources' Adding pip 1.5.6 to easy-install.pth file Installing pip script to /usr/bin Installing pip2.7 script to /usr/bin Installing pip2 script to /usr/bin Installed /usr/lib/python2.7/site-packages/pip-1.5.6-py2.7.egg Processing dependencies for pip Finished processing dependencies for pip [root@maya ~]#
こうしてpipがインストールできたら、続いてawscliのインストールにとりかかります。これもチョー簡単です。
pip install awscli
こんだけ。
[root@maya ~]# pip install awscli Downloading/unpacking awscli Downloading awscli-1.4.2.tar.gz (239kB): 239kB downloaded Running setup.py (path:/tmp/pip_build_root/awscli/setup.py) egg_info for package awscli (以下省略) [root@maya ~]#
いろいろゴチャゴチャーっと出力されますが、内容は気にしなくても大丈夫。タブン。
インストールが終わったら、awsコマンドが使用出来るかどうか確認しましょう。
aws help
と打ってみてヘルプが出れば今はとりあえずOK。
AWS() AWS() NAME aws - DESCRIPTION The AWS Command Line Interface is a unified tool to manage your AWS services. SYNOPSIS aws [options] <command> <subcommand> [parameters] Use aws command help for information on a specific command. OPTIONS --debug (boolean) (以下略)
ただし、このままではまだawsコマンドは正常に機能しません。「アクセスキー」と「シークレットキー」を設定しなければなりません。そこで、
aws configure
を実行します。
[root@maya ~]# aws configure AWS Access Key ID [None]: HOGEHOGE AWS Secret Access Key [None]: HOGEHOGEHOGEHOGE Default region name [None]: ap-northeast-1 Default output format [None]:
AWS Access KEY IDとAWS Secret Access Keyは、AWSにサインアップした時に発行されているものです。Web上から確認することが出来るので確認しておいてください。上記例では「HOGEHOGE」とか「HOGEHOGEHOGEHOGE」とか書いていますが、その部分に各自のソレを当てはめてください。
Default region name は、AWSのクラウド環境は世界各地に配置されていますが、その「どこにある環境」を使うか?という指定をするものです。ここで指定しなくても良いのですが、いちいち指定するのが面倒臭いので、日本人なら東京にあるリージョンを使うだろ!という人は、上記の通りap-northeast-1と入力しておきましょう。
Default output format は何も指定せずにEnter一発で良いです。なお、ここで無指定だとJSON型式で結果が得られることになります。
ところでこのJSON型式。シェルスクリプト書きには邪悪なテキストフォーマットであると思いますので、これをよろしくパースしてくれるツールが欲しくなります。一般的には
jq
というパーサを使うとハッピーになれますので、これが無い場合はインストールしましょう。tarballを入手してbuildしてもいいし、yumやらaptでゲットできるならそれでも構いません。
チョーご無沙汰しております。 [その他]
なんか、すっげー長い事更新が止まっていますが、再開しようかなーと思います。
もうちょっとだけ待っててね!(タブン
もうちょっとだけ待っててね!(タブン
Asterisk 1.8 + Heartbeat 2.1.3 で社内電話ごっこを試そう その1:サーバの準備 [Linux(HA)]
ビジネスフォンって、どーしてこんなに高いんだろうね?という話から始まって、秋田県のどっかの市役所ではAtserisk入れたらしいよ?という話になって、じゃあウチでも試してみるべ?と、よくある顛末に落ち着いたので、Asteriskを試すことに。
ただ、会社で使用する電話ともなると、「ディスク飛んじゃったから電話は使えません」というのはちょっとアレなので、HA化が大前提。ということで、ついでにHeartbeatも入れましょうということに。
Heartbeatについては以前にもネタにしたが、cib.xmlを手で編集していたりと、かなりダッサイ方法を使っていたので、もっとちゃんとした方法も整理して書いておくことにした。
なお、今回は検証用の環境ということにしているので、実際の環境はもっとちゃんとしたものにしようぜ。
そして、当然ながらノンサポートなので、NTTとかメーカーとかへの問い合わせは自重しる。at your own riskで。
その0:はじめに
というわけで、今回試すのに用いた環境などについて。
・PCは社内で余っていたHPのPCとEPSONのPC
・名前は「lelouch」と「suzaku」、クラスタの名前は「zero」ということにしておく。
・NICはオンボードの1個だけ。本番で使う場合は少なくとも2個は必要だろう。いや、3個か。
・OSは諸般の事情によりCentOS 5.8(いったいいくつまで続ける気だ!?)
・heartbeat等はめんどくさいのでyum でサクッと。(←SLを使わなかったのはこの辺も理由の一つ)
・もしかするとdrbdも必要になるかも?(←SLを使わなかったのは以下略)
・電話機側は一先ずソフトフォンで実験するとして、脈有りのようなら実機を購入して試そう。
その1:Asteriskインストール前夜
では、インストール開始。Asteriskインストールまでの手順は大ざっぱに以下の通り。
1-1:CentOSをインストール
1-2:環境設定等諸々実施
1-3:Heartbeatをインストール
1-4:Heartbeatの環境設定等諸々実施
その1-1:CentOSをインストール
・ディスクは全部の領域を使わないこと。もしかするとdrbdの出番があるかも知れないので。OSの領域等20GBとか30GBとかあれば十分だろうJKということで、残りは空けておく。
・インストールパッケージは「Base」だけ。あとはyumって入れるからよしということで。
・信仰上の都合によりGRUBの起動オプションに selinux=0 を追加してた。(無くてもOKじゃね?的な。)
その1-2:環境設定等諸々実施
・yum -y install ntp net-snmp sysstat ncurses-devel postfix とかだろやっぱり。
・yum -y update をしてから
・chkconfigでどう見ても要らないサービスの類は全部止めて、
・必要ならあちこちのconfファイルをいじって、
・reboot じゃね?
その1-3:Heartbeatをインストール
相変わらず、heartbeatのインストール回りがおかしいようなので、
とか、2回実行する。大事なことなので2回実行しましたよ。(←まじで必要)
で、Heartbeatのセットアップでいちいち対向ノードのパスワード入力が面倒くさいので、sshの鍵を交換しておく。(よい子は考えてからやろうね!)両方のサーバで、ssh-keygenしてやって、/root/.ssh/authorized_keys2 に自サーバと対向サーバのid_*.pubの中身を書いてやろう。パーミッションとかオーナーに注意な!
さらに、VIP経由でログインするときにサーバ側のsshキーが違うとログイン時にいちいち怒られて面倒くさいので、両方のサーバの鍵を統一してしまう。どちらか一方のサーバで、/etc/sshの下にあるssh_host*を相手側に上書きコピーしてしまう。
うちのケースではsuzakuのキーをlelouchにコピーしている。名前は適宜変更するヨロシ。
その1-4:heartbeatの環境設定
Asteriskのインストールとかがまだなので、一先ずクラスタを構成してVIP経由でのアクセスが通るようにすること、そしてクラスタをギッタンバッコンしてみてきちんと切り替わることを確認するところまでやっておく。
まずは/etc/ha.d/ha.cfの作成から。下記のようなファイルを作成した。なお、クラスタメンバーの名前については、 uname -n で表示される名前でないといけないので要注意。適宜変更すること。両方のノードに同じものを配置すればよい。
続いて/etc/ha.d/authkeysを作成。これもやはり同じものを両方のサーバに配置する。
そしたら、/usr/lib64/heartbeat/ha_propagate を実行。(32bit環境なら /usr/lib/heartbeat/ha_propagate)
ダサいことに、chkconfigのエラーが出るので(笑)、手動で
chkconfig heartbeat on
service heartbeat start
とか実行してやる。(当然両方のサーバで実行する)
2分くらい待ってから、crm_mon を実行して↓こんな具合になっていればOK。
では、クラスタVIPのリソースをここに追加する。以前heartbeatを検証したときはcib.xmlを直接編集したが、今回はcibadminで突っ込む。
まず、以下のようなファイルを作成する。ひとまずここでは/tmp/add.xmlとかそんな名前にした。IPアドレスとかNICとかその他ネットワーク設定についてはほどよく変更するように。
間違いないことを確認したら、 cibadmin -U -x /tmp/add.xml と実行してcib.xmlに追記する。なお、これはどちらか片方のサーバで実行すればよく、もう片方のサーバにはheartbeatが自動で追記してくれる。
追加されたかどうかの確認は、 cibadmin -Q と実行すれば確認出来る。
なお、パラメータを間違えてしまった場合の修正方法としては、
てな具合で修正可能。
cibadminのmanコマンドの記述によれば、VIPのアドレスを変更したい場合は、上記の方法で変更するのではなく、VIPの定義を一旦全部削除してから、正しい設定のリソース設定を丸ごと入れ直すように…と書かれているように見えた。まだ試していないが。
VIPの設定を突っ込んだら、両方のサーバで service heartbeat restart を実行。しばらくしてからcrm_monを実行して↓みたいな状態になればOK。
ここで割り当てたVIPは「172.16.1.238」だった。ちゃんとIPアドレスがくっついている事が判る。
次に、自動フェイルバックをするかしないかの設定をする。一身上の都合により、自動フェイルバックはして欲しくないので、これを停止する設定を入れておく。なお、自動フェイルバックをさせたい場合も、導入することをお勧めしておきたい。
/tmp/add2.xmlとかそんなファイルに以下の内容を記述する。まるっとコピペで全然OK
これを先ほどと同じように cibadmin -U -x /tmp/add2.xml と実行してcib.xmlに反映してやる。
このままだと自動フェイルバックは無効になるので、「やっぱり有効にしたい」という場合は以下のようなコマンドを流してやる。
cibadmin -o crm_config -U -X '<nvpair id="cib-bootstrap-options-default-resource-stickiness" name="default-resource-stickiness" value="0"/>'
やっぱり無効にしたいという場合は以下のコマンド
cibadmin -o crm_config -U -X '<nvpair id="cib-bootstrap-options-default-resource-stickiness" name="default-resource-stickiness" value="INFINITY"/>'
なお、自動フェイルバックが無効の状態で、自動フェイルバックを有効にするコマンドを流したとき、「自動フェイルバックをする必要がある」状態だった時には、その場で直ちに自動フェイルバックが行われるので要注意のこと。
次はいよいよAsteriskのインストールなどなど。
ただ、会社で使用する電話ともなると、「ディスク飛んじゃったから電話は使えません」というのはちょっとアレなので、HA化が大前提。ということで、ついでにHeartbeatも入れましょうということに。
Heartbeatについては以前にもネタにしたが、cib.xmlを手で編集していたりと、かなりダッサイ方法を使っていたので、もっとちゃんとした方法も整理して書いておくことにした。
なお、今回は検証用の環境ということにしているので、実際の環境はもっとちゃんとしたものにしようぜ。
そして、当然ながらノンサポートなので、NTTとかメーカーとかへの問い合わせは自重しる。at your own riskで。
その0:はじめに
というわけで、今回試すのに用いた環境などについて。
・PCは社内で余っていたHPのPCとEPSONのPC
・名前は「lelouch」と「suzaku」、クラスタの名前は「zero」ということにしておく。
・NICはオンボードの1個だけ。本番で使う場合は少なくとも2個は必要だろう。いや、3個か。
・OSは諸般の事情によりCentOS 5.8(いったいいくつまで続ける気だ!?)
・heartbeat等はめんどくさいのでyum でサクッと。(←SLを使わなかったのはこの辺も理由の一つ)
・もしかするとdrbdも必要になるかも?(←SLを使わなかったのは以下略)
・電話機側は一先ずソフトフォンで実験するとして、脈有りのようなら実機を購入して試そう。
その1:Asteriskインストール前夜
では、インストール開始。Asteriskインストールまでの手順は大ざっぱに以下の通り。
1-1:CentOSをインストール
1-2:環境設定等諸々実施
1-3:Heartbeatをインストール
1-4:Heartbeatの環境設定等諸々実施
その1-1:CentOSをインストール
・ディスクは全部の領域を使わないこと。もしかするとdrbdの出番があるかも知れないので。OSの領域等20GBとか30GBとかあれば十分だろうJKということで、残りは空けておく。
・インストールパッケージは「Base」だけ。あとはyumって入れるからよしということで。
・信仰上の都合によりGRUBの起動オプションに selinux=0 を追加してた。(無くてもOKじゃね?的な。)
その1-2:環境設定等諸々実施
・yum -y install ntp net-snmp sysstat ncurses-devel postfix とかだろやっぱり。
・yum -y update をしてから
・chkconfigでどう見ても要らないサービスの類は全部止めて、
・必要ならあちこちのconfファイルをいじって、
・reboot じゃね?
その1-3:Heartbeatをインストール
相変わらず、heartbeatのインストール回りがおかしいようなので、
yum install heartbeat heartbeat-pils heartbeat-stonith yum install heartbeat heartbeat-pils heartbeat-stonith
とか、2回実行する。大事なことなので2回実行しましたよ。(←まじで必要)
で、Heartbeatのセットアップでいちいち対向ノードのパスワード入力が面倒くさいので、sshの鍵を交換しておく。(よい子は考えてからやろうね!)両方のサーバで、ssh-keygenしてやって、/root/.ssh/authorized_keys2 に自サーバと対向サーバのid_*.pubの中身を書いてやろう。パーミッションとかオーナーに注意な!
さらに、VIP経由でログインするときにサーバ側のsshキーが違うとログイン時にいちいち怒られて面倒くさいので、両方のサーバの鍵を統一してしまう。どちらか一方のサーバで、/etc/sshの下にあるssh_host*を相手側に上書きコピーしてしまう。
========== cd /etc/ssh scp ssh_host* lelouch:/etc/ssh/ ==========
うちのケースではsuzakuのキーをlelouchにコピーしている。名前は適宜変更するヨロシ。
その1-4:heartbeatの環境設定
Asteriskのインストールとかがまだなので、一先ずクラスタを構成してVIP経由でのアクセスが通るようにすること、そしてクラスタをギッタンバッコンしてみてきちんと切り替わることを確認するところまでやっておく。
まずは/etc/ha.d/ha.cfの作成から。下記のようなファイルを作成した。なお、クラスタメンバーの名前については、 uname -n で表示される名前でないといけないので要注意。適宜変更すること。両方のノードに同じものを配置すればよい。
========== # CentOS + Heartbeat + Asterisk Cluster # クラスタリソース制御 crm on # フェイルバック・フェイルオーバー関連設定 # 自動フェイルバックはしない auto_failback off # クラスタノードの自動検出機能 autojoin none # Heartbeat パケットの設定 bcast eth0 # タイムアウト値の設定 # Heartbeatパケットの遅延警告時間 warntime 5 # 対向ノードが死んだとみなす時間 deadtime 20 # Heartbeat起動時に対向ノードの応答を待つ時間 initdead 60 # Heartbeatパケットの送出間隔 keepalive 2 # クラスタメンバー情報 node lelouch.office.mycompany.co.jp node suzaku.office.mycompany.co.jp ==========
続いて/etc/ha.d/authkeysを作成。これもやはり同じものを両方のサーバに配置する。
========== auth 1 1 sha1 CodeGeass ==========
そしたら、/usr/lib64/heartbeat/ha_propagate を実行。(32bit環境なら /usr/lib/heartbeat/ha_propagate)
ダサいことに、chkconfigのエラーが出るので(笑)、手動で
chkconfig heartbeat on
service heartbeat start
とか実行してやる。(当然両方のサーバで実行する)
2分くらい待ってから、crm_mon を実行して↓こんな具合になっていればOK。
========== [root@suzaku ha.d]# crm_mon Defaulting to one-shot mode You need to have curses available at compile time to enable console mode ============ Last updated: Fri Apr 6 15:52:37 2012 Current DC: suzaku.office.mycompany.co.jp (17883139-1d04-46e8-8409-6f9c49476d17) 2 Nodes configured. ============ Node: suzaku.office.mycompany.co.jp (17883139-1d04-46e8-8409-6f9c49476d17): online Node: lelouch.office.mycompany.co.jp (6161c780-53e7-4c9d-aad8-684917590d68): online ==========
では、クラスタVIPのリソースをここに追加する。以前heartbeatを検証したときはcib.xmlを直接編集したが、今回はcibadminで突っ込む。
まず、以下のようなファイルを作成する。ひとまずここでは/tmp/add.xmlとかそんな名前にした。IPアドレスとかNICとかその他ネットワーク設定についてはほどよく変更するように。
========== <resources> <group id="zero"> <primitive class="ocf" id="ClusterVIP" provider="heartbeat" type="IPaddr2"> <instance_attributes id="ClusterVIP_inst_attr"> <attributes> <nvpair id="ClusterVIP_attr_0" name="ip" value="172.16.1.238"/> <nvpair id="ClusterVIP_attr_1" name="nic" value="eth0"/> <nvpair id="ClusterVIP_attr_2" name="cidr_netmask" value="24"/> <nvpair id="ClusterVIP_attr_3" name="broadcast" value="172.16.1.255"/> </attributes> </instance_attributes> </primitive> </group> </resources> ==========
間違いないことを確認したら、 cibadmin -U -x /tmp/add.xml と実行してcib.xmlに追記する。なお、これはどちらか片方のサーバで実行すればよく、もう片方のサーバにはheartbeatが自動で追記してくれる。
追加されたかどうかの確認は、 cibadmin -Q と実行すれば確認出来る。
なお、パラメータを間違えてしまった場合の修正方法としては、
========== cibadmin -M -X '<nvpair id="ClusterVIP_attr_2" name="cidr_netmask" value="24"/>' ==========
てな具合で修正可能。
cibadminのmanコマンドの記述によれば、VIPのアドレスを変更したい場合は、上記の方法で変更するのではなく、VIPの定義を一旦全部削除してから、正しい設定のリソース設定を丸ごと入れ直すように…と書かれているように見えた。まだ試していないが。
VIPの設定を突っ込んだら、両方のサーバで service heartbeat restart を実行。しばらくしてからcrm_monを実行して↓みたいな状態になればOK。
[root@suzaku ha.d]# crm_mon Defaulting to one-shot mode You need to have curses available at compile time to enable console mode ============ Last updated: Fri Apr 6 16:06:14 2012 Current DC: suzaku.office.mycompany.co.jp (17883139-1d04-46e8-8409-6f9c49476d17) 2 Nodes configured. 1 Resources configured. ============ Node: suzaku.office.mycompany.co.jp (17883139-1d04-46e8-8409-6f9c49476d17): online Node: lelouch.office.mycompany.co.jp (6161c780-53e7-4c9d-aad8-684917590d68): online Resource Group: zero ClusterVIP (heartbeat::ocf:IPaddr2): Started suzaku.office.mycompany.co.jp [root@suzaku ha.d]# ip addr 1: lo:mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:1b:fc:d3:46:7a brd ff:ff:ff:ff:ff:ff inet 172.16.1.239/24 brd 172.16.1.255 scope global eth0 inet 172.16.1.238/24 brd 172.16.1.255 scope global secondary eth0 ==========
ここで割り当てたVIPは「172.16.1.238」だった。ちゃんとIPアドレスがくっついている事が判る。
次に、自動フェイルバックをするかしないかの設定をする。一身上の都合により、自動フェイルバックはして欲しくないので、これを停止する設定を入れておく。なお、自動フェイルバックをさせたい場合も、導入することをお勧めしておきたい。
/tmp/add2.xmlとかそんなファイルに以下の内容を記述する。まるっとコピペで全然OK
========== <crm_config> <cluster_property_set id="cib-bootstrap-options"> <attributes> <nvpair id="cib-bootstrap-options-default-resource-stickiness" name="default-resource-stickiness" value="INFINITY"/> </attributes> </cluster_property_set> </crm_config> ==========
これを先ほどと同じように cibadmin -U -x /tmp/add2.xml と実行してcib.xmlに反映してやる。
このままだと自動フェイルバックは無効になるので、「やっぱり有効にしたい」という場合は以下のようなコマンドを流してやる。
cibadmin -o crm_config -U -X '<nvpair id="cib-bootstrap-options-default-resource-stickiness" name="default-resource-stickiness" value="0"/>'
やっぱり無効にしたいという場合は以下のコマンド
cibadmin -o crm_config -U -X '<nvpair id="cib-bootstrap-options-default-resource-stickiness" name="default-resource-stickiness" value="INFINITY"/>'
なお、自動フェイルバックが無効の状態で、自動フェイルバックを有効にするコマンドを流したとき、「自動フェイルバックをする必要がある」状態だった時には、その場で直ちに自動フェイルバックが行われるので要注意のこと。
次はいよいよAsteriskのインストールなどなど。
PCI製Wi-Fiマルチポケットルータ MZK-MF300D [小技(Linux)]
会社でスマホを使ってAdobeのShadowとかいうソフトと連携してデザインの開発作業をしたいんだけど…と言われ、事務所内の社内ネットワークにWi-Fiで接続するのはちょっとどーなのよ…と文句を言いたい気持ちをぐっとこらえ、やむなくプラネックス(PCI)製の激安な「Wi-Fiマルチポケットルータ」 MZK-MF300D なるものを買ってきた。
どうやら、スマホのWi-FiアドレスとAdobe Shadowとかいうソフトの入っているPCとが同じネットワークにある必要があるらしく、「そうしてくれ」との強い要望を受けたので、MZK-MF300Dをマニュアルガン無視でアクセスポイントモードに切り替えてセットアップ。ネットワークの設定、マルチAPの無効化、無線の設定、管理者パスワードの変更などなどを経てセットワークに接続。スマホでアクセスが出来ることを確認して引き渡した。
ところが!
「あの~。開発環境にアクセスできないんですけど~。」
という知らせが。どうも、DNSで名前解決が出来ないらしい。
アクセスポイントの設定を見直すが、よくよく見て見ると、そもそもDNSサーバのアドレスを入れる項目がどこにもない。でも、なにやらDNSは引けてる。
はあ?
どうやらMZK-MF300Dはどこか我々の知らないところに立っているDNSを参照しているもよう。社内ネットワークとかの内部DNSを見せる事はこのままでは出来ないようだ。
しかし、開発環境とかテスト環境とかいうものは外部に曝す訳にはいかないじゃないか。
そこで…iptablesでアクセス経路をひん曲げてやればよくね?
と、思い立ち以下のような作戦を立案した。
①MZK-MF300Dの全てのトラフィックを、どこか他のサーバで一旦全部受け取る
↓
②iptablesでマスカレード、本来のデフォルトゲートウェイに中継してやる
↓
③でも53/tcp、53/udpだけはDNSサーバに向かってパケットの飛び先を曲げてしまう
こうすれば、MZK-MF300Dの馬鹿DNSは騙されてくれることだろう!!
と、妄想したのだ。
ちと手頃なサーバが他に居なかったので、「セキュリティ的にちょっとどうよ!?」という懸念はあるものの、一先ず社内のDNSサーバにMZK-MF300Dのトラフィックを総受けしてもらう役割も担当してもらうこととした。
後日、忘れてなければ直す!(たぶん)
というわけで、そのDNSサーバな子で以下実行。
手順1:/etc/sysctl.confに「net.ipv4.ip_forward = 1」を書く。
手順2:sysctl -p 実行
手順3:service iptables start 実行
手順4:Wi-Fiから来たトラフィックを全部本来のデフォルトゲートウェイに飛ばすため以下実行
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
手順5:MZK-MF300Dの内蔵馬鹿DNSからの問い合わせを、社内DNSサーバで解決するため、パケットをぶんどる設定を入れるため以下実行
iptables -t nat -A PREROUTING -s (MZK-MF300Dのアドレス) -p tcp --dport 53 -j DNAT --to (社内DNSサーバのアドレス):53
iptables -t nat -A PREROUTING -s (MZK-MF300Dのアドレス) -p udp --dport 53 -j DNAT --to (社内DNSサーバのアドレス):53
で、念のためMZK-MF300Dを再起動。
Wi-Fiアクセスから適当な社内サーバの名前をnslookup するとちゃんと解決できた。(殺気はダメだった)
というわけで一先ず問題解決っぽい。デザイナーの人も大丈夫ですと言っているので大丈夫なのだろう。
教訓:安物買いのなんとやら。会社で使うものはもっとちゃんとした物を買いましょう。(笑)
どうやら、スマホのWi-FiアドレスとAdobe Shadowとかいうソフトの入っているPCとが同じネットワークにある必要があるらしく、「そうしてくれ」との強い要望を受けたので、MZK-MF300Dをマニュアルガン無視でアクセスポイントモードに切り替えてセットアップ。ネットワークの設定、マルチAPの無効化、無線の設定、管理者パスワードの変更などなどを経てセットワークに接続。スマホでアクセスが出来ることを確認して引き渡した。
ところが!
「あの~。開発環境にアクセスできないんですけど~。」
という知らせが。どうも、DNSで名前解決が出来ないらしい。
アクセスポイントの設定を見直すが、よくよく見て見ると、そもそもDNSサーバのアドレスを入れる項目がどこにもない。でも、なにやらDNSは引けてる。
はあ?
どうやらMZK-MF300Dはどこか我々の知らないところに立っているDNSを参照しているもよう。社内ネットワークとかの内部DNSを見せる事はこのままでは出来ないようだ。
しかし、開発環境とかテスト環境とかいうものは外部に曝す訳にはいかないじゃないか。
そこで…iptablesでアクセス経路をひん曲げてやればよくね?
と、思い立ち以下のような作戦を立案した。
①MZK-MF300Dの全てのトラフィックを、どこか他のサーバで一旦全部受け取る
↓
②iptablesでマスカレード、本来のデフォルトゲートウェイに中継してやる
↓
③でも53/tcp、53/udpだけはDNSサーバに向かってパケットの飛び先を曲げてしまう
こうすれば、MZK-MF300Dの馬鹿DNSは騙されてくれることだろう!!
と、妄想したのだ。
ちと手頃なサーバが他に居なかったので、「セキュリティ的にちょっとどうよ!?」という懸念はあるものの、一先ず社内のDNSサーバにMZK-MF300Dのトラフィックを総受けしてもらう役割も担当してもらうこととした。
後日、忘れてなければ直す!(たぶん)
というわけで、そのDNSサーバな子で以下実行。
手順1:/etc/sysctl.confに「net.ipv4.ip_forward = 1」を書く。
手順2:sysctl -p 実行
手順3:service iptables start 実行
手順4:Wi-Fiから来たトラフィックを全部本来のデフォルトゲートウェイに飛ばすため以下実行
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
手順5:MZK-MF300Dの内蔵馬鹿DNSからの問い合わせを、社内DNSサーバで解決するため、パケットをぶんどる設定を入れるため以下実行
iptables -t nat -A PREROUTING -s (MZK-MF300Dのアドレス) -p tcp --dport 53 -j DNAT --to (社内DNSサーバのアドレス):53
iptables -t nat -A PREROUTING -s (MZK-MF300Dのアドレス) -p udp --dport 53 -j DNAT --to (社内DNSサーバのアドレス):53
で、念のためMZK-MF300Dを再起動。
Wi-Fiアクセスから適当な社内サーバの名前をnslookup するとちゃんと解決できた。(殺気はダメだった)
というわけで一先ず問題解決っぽい。デザイナーの人も大丈夫ですと言っているので大丈夫なのだろう。
教訓:安物買いのなんとやら。会社で使うものはもっとちゃんとした物を買いましょう。(笑)
離れた場所にある2つのストレージの同期 その3のおまけ~もうちょっとハードに書き込みしてみる~ [Linux(LVM/RAID/Storage)]
「その3」でファイルを1個置いてみて確認はしてみたものの、もっとハードにファイルを書き込んでみたくなったので、reinとfineと両方で以下のようなスクリプトを実行して激しく書き込みしてみた。(笑)
これでファイルをひたすら書き込み、両方から同時にアクセスができることをしっかり確認しておこう。
もう1枚ターミナルを開いてls -la /mnt/work/testとか実行してみると…
という具合に、ファイルが同時に沢山書き込まれていることが確認できる。
while : do uname -a > /mnt/work/test/`uname -n``uuidgen` done
これでファイルをひたすら書き込み、両方から同時にアクセスができることをしっかり確認しておこう。
もう1枚ターミナルを開いてls -la /mnt/work/testとか実行してみると…
[root@fine ~]# ls -la /mnt/work/test 合計 548 drwxr-xr-x 2 root root 2048 11月 15 15:31 . drwxr-xr-x 3 root root 3864 11月 15 15:24 .. -rw-r--r-- 1 root root 93 11月 15 15:31 fine020f54e6-195b-4f24-9645-cfb0d1b87ffd -rw-r--r-- 1 root root 93 11月 15 15:30 fine09f8c760-ae39-436a-9678-d79a11630040 -rw-r--r-- 1 root root 93 11月 15 15:30 fine141393f8-5374-4623-b1cc-0566bf53f478 -rw-r--r-- 1 root root 93 11月 15 15:30 fine1cb9170c-fa5c-4429-9315-051f836cbfd0 -rw-r--r-- 1 root root 93 11月 15 15:30 fine1e54c792-ef90-44d1-b251-d160190d85e2 -rw-r--r-- 1 root root 93 11月 15 15:30 fine21b4ae78-9cc3-49ef-81ca-3bbde86d47cd -rw-r--r-- 1 root root 93 11月 15 15:30 fine2282bebc-86dd-49bd-bf0f-a06eb51a9e72 -rw-r--r-- 1 root root 93 11月 15 15:30 fine25830222-800e-4f04-af2e-8fc3dfef13df -rw-r--r-- 1 root root 93 11月 15 15:30 fine29bb8b26-163c-4451-aa00-e4019587fd16 -rw-r--r-- 1 root root 93 11月 15 15:30 fine2b41a505-be42-4b9c-8801-126f10717868 -rw-r--r-- 1 root root 93 11月 15 15:30 fine2e79bc04-1d76-4246-bd26-3f9446e504bc -rw-r--r-- 1 root root 93 11月 15 15:30 fine33310032-adbb-4212-9081-5f9f32207a3a -rw-r--r-- 1 root root 93 11月 15 15:30 fine3d34441c-1ee3-4d28-a7b9-6dcfb852829e -rw-r--r-- 1 root root 93 11月 15 15:30 fine44241d81-a746-400c-9a86-8304008e3876 -rw-r--r-- 1 root root 93 11月 15 15:30 fine4cb7414c-b143-4977-8eb7-a4222a21f3b9 -rw-r--r-- 1 root root 93 11月 15 15:30 fine4d1a967e-d6b3-40a4-8fae-526c9c47a7fd -rw-r--r-- 1 root root 93 11月 15 15:30 fine4ea833e9-6185-40ed-bd5e-7a8867f7bb4f -rw-r--r-- 1 root root 93 11月 15 15:30 fine50130551-8d1b-410e-b6c3-879f29db1fa5 -rw-r--r-- 1 root root 93 11月 15 15:30 fine50ab21ef-d75c-4ef0-81f5-73d565bfa0f3 -rw-r--r-- 1 root root 93 11月 15 15:30 fine541f2e5a-ce89-4a2e-94de-1813551491fc -rw-r--r-- 1 root root 93 11月 15 15:30 fine547ff03f-6ee9-4cfd-9497-36d10d3ee810 -rw-r--r-- 1 root root 93 11月 15 15:30 fine559116f6-f703-4bcc-b0cb-2d784ba69dc7 -rw-r--r-- 1 root root 93 11月 15 15:30 fine56a0134e-6483-4962-91f1-973db4ba5680 -rw-r--r-- 1 root root 93 11月 15 15:30 fine5ba34224-052b-4c24-b7d6-feec59d84f1d -rw-r--r-- 1 root root 93 11月 15 15:30 fine5f24a6bd-38b9-435a-887f-111e7dfa9179 -rw-r--r-- 1 root root 93 11月 15 15:30 fine6b2188a7-0f68-4927-b8b8-bac7687dca8d -rw-r--r-- 1 root root 93 11月 15 15:30 fine6d065f4f-5b80-4e3a-a07c-8e22e6b98ff0 -rw-r--r-- 1 root root 93 11月 15 15:30 fine6e156d70-32d6-4d05-81f7-ea7d2f568806 -rw-r--r-- 1 root root 93 11月 15 15:30 fine6e3bfc04-d632-4a5e-b28a-118190bd68d1 -rw-r--r-- 1 root root 93 11月 15 15:31 fine72e7d769-8a79-47ea-ad63-4e80f583d9ec -rw-r--r-- 1 root root 93 11月 15 15:30 fine758fa94f-5176-4b69-9fe0-16769f92b568 -rw-r--r-- 1 root root 93 11月 15 15:30 fine7bf6221c-8353-4133-90ff-87233df602ce -rw-r--r-- 1 root root 93 11月 15 15:30 fine7e09cb0d-2c84-475c-91df-da265b452380 -rw-r--r-- 1 root root 93 11月 15 15:30 fine7f0b8322-c08b-4fc4-9e8f-a289b91d5896 -rw-r--r-- 1 root root 93 11月 15 15:30 fine84aa99b0-c75b-448e-9e6d-294425b3a666 -rw-r--r-- 1 root root 93 11月 15 15:30 fine89e2d111-1f2e-4714-a51c-78bb4935e283 -rw-r--r-- 1 root root 93 11月 15 15:30 fine8f04106a-a478-4c47-9b0a-b0895455d7f3 -rw-r--r-- 1 root root 93 11月 15 15:30 fine94ba56a2-d0ce-43d1-a01e-8c7bc10f0f92 -rw-r--r-- 1 root root 93 11月 15 15:30 fine99a83750-05e2-44de-a417-6d5984408e16 -rw-r--r-- 1 root root 93 11月 15 15:30 fine9a90ae1c-1c61-4544-918f-d04fb52a2122 -rw-r--r-- 1 root root 93 11月 15 15:30 finea1befcf9-be98-4f65-88aa-6af070f7f6eb -rw-r--r-- 1 root root 93 11月 15 15:30 finea4f6b961-6b57-4a44-b221-9490c0557f33 -rw-r--r-- 1 root root 93 11月 15 15:30 fineaa9c5e5e-3897-482e-9b3c-8ff12c5b10b3 -rw-r--r-- 1 root root 93 11月 15 15:30 fineaac93dc6-0485-42a7-b372-bbb5b7c40329 -rw-r--r-- 1 root root 93 11月 15 15:30 fineab4680ad-a1cc-40fd-a2ad-caa366c58a05 -rw-r--r-- 1 root root 93 11月 15 15:30 fineac6cb486-26e9-4bc1-aa6e-35a36dabf85c -rw-r--r-- 1 root root 93 11月 15 15:30 finebc0295d6-a293-4fc6-807d-5e86954d29df -rw-r--r-- 1 root root 93 11月 15 15:30 finecdcf3f7f-e854-46a8-aca9-2d3a5b065eec -rw-r--r-- 1 root root 93 11月 15 15:30 finecef23114-aab5-44ed-8f79-3b52d24cf2df -rw-r--r-- 1 root root 93 11月 15 15:30 finecf2eeaec-997b-4041-8208-a8490a84beeb -rw-r--r-- 1 root root 93 11月 15 15:30 fined17dfba1-e421-4890-a385-ba6dd9f62b61 -rw-r--r-- 1 root root 93 11月 15 15:30 fined5044510-dad9-4192-8e71-291791fdedac -rw-r--r-- 1 root root 93 11月 15 15:30 fined6b62bd3-c716-48c3-bfc7-864f6de01d46 -rw-r--r-- 1 root root 93 11月 15 15:30 fined743a9c7-e90e-40ee-b855-07834e0f98e6 -rw-r--r-- 1 root root 93 11月 15 15:30 finedd23f670-5282-45db-8490-84b74d15695d -rw-r--r-- 1 root root 93 11月 15 15:30 finedf06f755-203f-4f9e-91e3-221054fef6f5 -rw-r--r-- 1 root root 93 11月 15 15:30 finedff8c296-08f0-41d1-b10e-6739980a2f2f -rw-r--r-- 1 root root 93 11月 15 15:30 finee0ce9764-dad7-4eb1-bafd-7df849bc7b2b -rw-r--r-- 1 root root 93 11月 15 15:30 finee5feaf17-8b20-4270-9f80-660a79cbada5 -rw-r--r-- 1 root root 93 11月 15 15:30 fineeafc997a-2f23-4cb6-83f7-fb1aecac5808 -rw-r--r-- 1 root root 93 11月 15 15:30 fineee0ef138-5bcc-4b24-a57b-a13a10e7b3b1 -rw-r--r-- 1 root root 93 11月 15 15:30 finef21378a2-fb69-4b9a-a14f-795f3ace7318 -rw-r--r-- 1 root root 93 11月 15 15:30 finef73891e3-8d08-4ead-9ac8-d8b6ae459df9 -rw-r--r-- 1 root root 93 11月 15 15:31 rein00f937fe-7fcf-4613-b418-2ebf56f8e175 -rw-r--r-- 1 root root 93 11月 15 15:30 rein02657eeb-1d4b-48de-a25d-082ab3c329ce -rw-r--r-- 1 root root 93 11月 15 15:30 rein057e374a-cf8e-4255-a69c-ec02a477d8de -rw-r--r-- 1 root root 93 11月 15 15:30 rein0b019417-0169-48f2-bc16-441119b362f2 -rw-r--r-- 1 root root 93 11月 15 15:31 rein128878f8-99b2-443f-a30b-2402925e96f1 -rw-r--r-- 1 root root 93 11月 15 15:30 rein131cf5c0-87e9-4f03-a78e-36045310a16e -rw-r--r-- 1 root root 93 11月 15 15:30 rein1a1cf207-7422-4073-881b-ce60a5e3f9d8 -rw-r--r-- 1 root root 93 11月 15 15:30 rein1bbe7f52-383c-4e41-97a0-697cd67398de -rw-r--r-- 1 root root 93 11月 15 15:30 rein1e6925da-9409-484b-9434-69dfc52edcd1 -rw-r--r-- 1 root root 93 11月 15 15:30 rein2230892d-54b4-4d48-995d-03f7c34c5236 -rw-r--r-- 1 root root 93 11月 15 15:30 rein250bc279-d4d0-4fe7-9378-32685229acfa -rw-r--r-- 1 root root 93 11月 15 15:30 rein27067fdd-8060-437e-80ed-b401215221fa -rw-r--r-- 1 root root 93 11月 15 15:30 rein2a7d89cb-11f6-4ba5-85a1-f53522f60a75 -rw-r--r-- 1 root root 93 11月 15 15:31 rein2aacc0ab-edd5-4b9e-93c4-8f83288c8791 -rw-r--r-- 1 root root 93 11月 15 15:30 rein2be05eb8-de21-4f9e-b6b5-c96eb05c2762 -rw-r--r-- 1 root root 93 11月 15 15:30 rein343839e2-62d3-4a75-ab0d-5520051e3c6d -rw-r--r-- 1 root root 93 11月 15 15:30 rein3a3ff93e-1c18-4d22-a5c3-ac53d8fbd6ad -rw-r--r-- 1 root root 93 11月 15 15:30 rein3c63ae8f-c595-4fad-8c54-a1b6241c8dc6 -rw-r--r-- 1 root root 93 11月 15 15:31 rein3cc0c01c-b7e3-4a86-abb0-892f527b9dc7 -rw-r--r-- 1 root root 93 11月 15 15:31 rein3ea2440d-224a-477d-b56e-a416d5c8fcfb -rw-r--r-- 1 root root 93 11月 15 15:31 rein3f9ebeed-50fc-439f-8afa-05dd01711d12 -rw-r--r-- 1 root root 93 11月 15 15:31 rein40d2e874-4f23-4047-b82b-0f0a695ea635 -rw-r--r-- 1 root root 93 11月 15 15:30 rein4c6a5a13-1751-4a81-8944-74d646cdfdb1 -rw-r--r-- 1 root root 93 11月 15 15:30 rein52a52616-33c5-432c-afe4-4b2119b48994 -rw-r--r-- 1 root root 93 11月 15 15:30 rein5319b164-4e83-4621-8f96-ff77c9e3533a -rw-r--r-- 1 root root 93 11月 15 15:31 rein58fdc617-0eef-4593-8fa1-d2ac5991c971 -rw-r--r-- 1 root root 93 11月 15 15:31 rein59c543a4-cc4f-4786-83b5-34dd8e482689 -rw-r--r-- 1 root root 93 11月 15 15:30 rein5ac6319b-6238-4136-8b48-682c36dc7313 -rw-r--r-- 1 root root 93 11月 15 15:30 rein5e0ac165-5977-4db3-a989-9add26c23e59 -rw-r--r-- 1 root root 93 11月 15 15:30 rein5ef04f24-16ff-472e-bc50-c6fa700dc639 -rw-r--r-- 1 root root 93 11月 15 15:31 rein72082469-3c28-4108-bfbd-9a22e10edd4d -rw-r--r-- 1 root root 93 11月 15 15:30 rein739fe3f6-def2-4e58-8621-095e962d6fca -rw-r--r-- 1 root root 93 11月 15 15:30 rein78adf4a3-b095-40e7-b950-03750b119e71 -rw-r--r-- 1 root root 93 11月 15 15:30 rein7d3b8e5a-34e8-485e-af0a-dca5a7ae84bd -rw-r--r-- 1 root root 93 11月 15 15:30 rein80aa70fc-3d22-4ba4-8270-24237a2e3a4b -rw-r--r-- 1 root root 93 11月 15 15:30 rein83e688c6-a1ea-4db7-a7bb-8e3ae52cf543 -rw-r--r-- 1 root root 93 11月 15 15:31 rein86ba7cdf-c6a4-4e42-aab5-917a4f563108 -rw-r--r-- 1 root root 93 11月 15 15:30 rein8c308a3d-83c3-486c-b0aa-85c41b3c5a4b -rw-r--r-- 1 root root 93 11月 15 15:30 rein8f7d2d89-8abd-4ee6-9e45-e52947a9aa88 -rw-r--r-- 1 root root 93 11月 15 15:31 rein955d927a-db6f-41b7-bb42-b00a8c4dcc18 -rw-r--r-- 1 root root 93 11月 15 15:31 rein9b1dc4b7-3458-47f2-acc7-36a541ad184c -rw-r--r-- 1 root root 93 11月 15 15:30 rein9e4f62fa-bf5a-41aa-b34b-7eecf22bd9f1 -rw-r--r-- 1 root root 93 11月 15 15:30 reina0c86554-8e99-41b6-bc95-a03a7593d044 -rw-r--r-- 1 root root 93 11月 15 15:30 reina3d80147-5463-4f45-a9d9-4534bf2163e3 -rw-r--r-- 1 root root 93 11月 15 15:30 reinadcca1a8-f8f9-4288-b825-4e695c2c9475 -rw-r--r-- 1 root root 93 11月 15 15:30 reinb2c15117-da75-4f0e-b1df-773059523e1e -rw-r--r-- 1 root root 93 11月 15 15:30 reinb504886d-f3b9-4ad1-9cb2-e0278ee064f4 -rw-r--r-- 1 root root 93 11月 15 15:30 reinb722f38e-8e57-4a8d-b8c2-e6239a57e6ba -rw-r--r-- 1 root root 93 11月 15 15:30 reinbadbd91d-5e84-4517-a36a-6f6ee3095679 -rw-r--r-- 1 root root 93 11月 15 15:31 reinbd21184a-9466-4c0a-a36a-80e77272dd1a -rw-r--r-- 1 root root 93 11月 15 15:30 reinc064282a-0da7-4079-8d2b-b0916419aecb -rw-r--r-- 1 root root 93 11月 15 15:30 reinc13881b0-f90a-4709-b7c2-bdd936ae0a62 -rw-r--r-- 1 root root 93 11月 15 15:30 reinc2256c89-e748-42f0-aa4c-9542ec6dd08b -rw-r--r-- 1 root root 93 11月 15 15:30 reinca69cf79-cf89-41c5-9f1d-661e7e708e5b -rw-r--r-- 1 root root 93 11月 15 15:30 reincf300319-f5e2-417a-a55e-d2f24b64fa77 -rw-r--r-- 1 root root 93 11月 15 15:30 reind05e880b-576a-4037-8cfc-ce165f8b564d -rw-r--r-- 1 root root 93 11月 15 15:30 reind6df0ac4-ffc1-4477-9650-6027d8cd4437 -rw-r--r-- 1 root root 93 11月 15 15:30 reind90728d1-de74-4175-b6e6-98b1395f17d9 -rw-r--r-- 1 root root 93 11月 15 15:31 reindf840098-78c1-4846-941d-f4cdcc130041 -rw-r--r-- 1 root root 93 11月 15 15:30 reindf9ed5c1-4ab5-4448-a09a-973d517435d3 -rw-r--r-- 1 root root 93 11月 15 15:30 reine117018e-76ed-415b-a650-617bf3d7f276 -rw-r--r-- 1 root root 93 11月 15 15:30 reine377bca4-c462-4587-ac0b-21de83cee585 -rw-r--r-- 1 root root 93 11月 15 15:30 reine3a886d1-64d8-4ebe-8307-b9eca2678561 -rw-r--r-- 1 root root 93 11月 15 15:31 reinead72745-0ba1-49c0-b394-4e4dc662d29e -rw-r--r-- 1 root root 93 11月 15 15:31 reinee88d638-a1d3-4da5-8827-2b7a51ad2393 -rw-r--r-- 1 root root 93 11月 15 15:30 reinf8fbf2d9-07ff-4ada-a2bf-ecf6a367d806 -rw-r--r-- 1 root root 93 11月 15 15:30 reinfca56832-b09d-4358-be90-41d3563d662d -rw-r--r-- 1 root root 93 11月 15 15:30 reinfe85813c-0aaa-4c18-a161-5f78e67ff522
という具合に、ファイルが同時に沢山書き込まれていることが確認できる。
離れた場所にある2つのストレージの同期 その3~共用アクセス可能なファイルシステムを作成する~ [Linux(LVM/RAID/Storage)]
drbdを用いて両方のサーバから同時にアクセス可能なボリュームを作成できたので、今度は、両方のサーバから同時にアクセス可能なファイルシステムを作成することとします。
細かいことは割愛しますが、ext3はダメなので他のファイルシステムを使用しなければなりません。共有ボリュームに同時アクセスの可能なファイルシステムとしてよく知られている物としては…
1:GFS2 (Global File System)
2:ocfs2 (Oracle Cluster File System)
あたり。残念なことに、今テスト環境として構築しているCentOS5.7の環境ではocfs2はサクッとyumっちゃうことが出来ないので、GFS2でいくより他はなさそう。
「No Matches found」という表示が寂しい。
GFS2ならCentOSのオリジナルにあたるRedHat Linuxが対応しているくらいなのでCentOSでも問題無くいけることでしょう。
と、いう訳で、GFS2でいくことに大決定。
手順としては以下の通りか。
① 必要なパッケージをyumでサクッとインストール
② cmanまわりの設定
③ clvmまわりの設定
④ GFS2でファイルシステムを作成
⑤ マウント
ではレッツトライ。
① 必要なパッケージをyumでサクッとインストール。
yumでインストールするなら、yum install kmod-gfs gfs2-utils cman lvm2-cluster あたりをインストール。「lvm2」は最初から入っていると思うので書いてないが、書いても特に害はないので心配性な人はlvm2も書いて差し支えない。
② cmanまわりの設定
/etc/cluster/cluster.conf を書く。XMLファイルなので面倒くさい。ちなみにGUIでサポートしてくれるものもあるが、そんなゆとり教育は(ry
RedHatの公式・英文なドキュメントに四苦八苦しながらも、以下のような内容を記述。おそらくこれが最低限の内容じゃないかと思われる。
ちなみにこのファイルは両方のサーバに設置する。
設置したら、service cman start(または「restart」)で設定を反映しておく。
あと、忘れずにchkconfig cman onとかも実行。
③ clvmまわりの設定
続いて、clvm(クラスタ対応のlvm)まわりの設定。
ロック方法の設定と、lvmの書き込みキャッシュの設定を変更すればよい。変更するファイルは/etc/lvm/lvm.confである。
デフォルトでは「locking_type = 1」と記述されている(はず)なので、これを「locking_type = 3」に変更する。
さらに、「write_cache_state = 1」と記述されている箇所を「write_cache_state = 0」と書き換える。
また、drbdより先にlvmがボリュームを握ってしまう現象を回避するため、フィルター設定も変更する。まず、オリジナルのフィルター部分の記述は…
と記述されている(はず)。これは、「全てのデバイスについてpvscanしまくる」ということを言っている。しかし、drbdの起動より先に、生のデバイスについてpvscanされてしまうと、drbdが起動する際にエラーとなってしまうので、/dev/drbd*についてはpvscanをしてほしいがdrbdが使用する領域についてはpvscanしないで欲しいのである。そこで、テスト環境の場合は
と、なっていてhda*についてはOSの起動用ディスクなのでpvscanをしてほしいがhdb*以降についてはpvscanなどしないで欲しい。しかしdrbd*についてはpvscanをして欲しいので、filterの設定を以下のように修正する必要が生じる。
変更したら、キャッシュファイルを手動で削除するため、rm -f /etc/lvm/cache/.cacheを実行し、service clvmd start(または「restart」)で設定を反映しておく。
こちらも同様にchkconfig clvmd onを忘れずに。
④ GFS2でファイルシステムを作成
いよいよ、ファイルシステムを作成する。まずはlvmの操作から。なお、drbdの公式サイトの情報では以下のコマンドを「両方のサーバで実行する」ようなことが書いてあるんだけども、個人的には片方でよくね?とも思うんだけどどうだろう…。
lvmについては通常の手順通り。
これでlvmの論理ボリュームを作成すれば、clvmが即座に相手側サーバに伝達する模様。公式サイトには「--clustered y」の記述が無いが、コレがないと同時に書き込みしたときにサーバが返事をしなくなる模様。(へんじがない。ただのしかばねのようだ。)
mkfsする際はクラスタ用にいくつかオプションが増えることに注意する。
「-t gfs2」は、ファイルシステムの指定。
「-p lock_dlm」はロックマネージャの指定。
「-t fushigiStar:ShareVolume」はロックテーブルの名前を指定する。fushigiStarは/etc/cluster/cluster.confに記述したクラスタシステム名。ShareVolumeはクラスタシステム内で一意の名前であればよいとのこと。
さあ!それでは両方で同時にマウントしてみましょう!!!!!!!!
まずはrein側!!
そしてfine側!!
というわけで、まずは同時にマウント出来ました。
/mnt/work/testというディレクトリを作成し、両方のサーバからこのディレクトリにファイルを保存して、相手側サーバで作成したファイルをそれぞれ確認してみましょう。
まずはrein側
そしてfine側
おっおっおっ ^ω^
うまくいってるくさいお ^ω^
細かいことは割愛しますが、ext3はダメなので他のファイルシステムを使用しなければなりません。共有ボリュームに同時アクセスの可能なファイルシステムとしてよく知られている物としては…
1:GFS2 (Global File System)
2:ocfs2 (Oracle Cluster File System)
あたり。残念なことに、今テスト環境として構築しているCentOS5.7の環境ではocfs2はサクッとyumっちゃうことが出来ないので、GFS2でいくより他はなさそう。
[root@rein cluster]# yum search ocfs Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: www.ftp.ne.jp * extras: www.ftp.ne.jp * updates: www.ftp.ne.jp Warning: No matches found for: ocfs No Matches found
「No Matches found」という表示が寂しい。
GFS2ならCentOSのオリジナルにあたるRedHat Linuxが対応しているくらいなのでCentOSでも問題無くいけることでしょう。
[root@rein cluster]# yum search gfs Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: www.ftp.ne.jp * extras: www.ftp.ne.jp * updates: www.ftp.ne.jp ====================================== Matched: gfs ====================================== (略) Global_File_System-ja-JP.noarch : Global File System (略) e2fsprogs.i386 : Utilities for managing the second and third extended (ext2/ext3) : filesystems e4fsprogs.i386 : Utilities for managing the fourth extended (ext4) filesystem gfs-utils.i386 : Utilities for managing the global filesystem (GFS) gfs2-utils.i386 : Utilities for managing the global filesystem (GFS) gnbd.i386 : GFS's Network Block Device kmod-gfs.i686 : gfs kernel module(s) kmod-gfs-PAE.i686 : gfs kernel module(s) kmod-gfs-xen.i686 : gfs kernel module(s)
と、いう訳で、GFS2でいくことに大決定。
手順としては以下の通りか。
① 必要なパッケージをyumでサクッとインストール
② cmanまわりの設定
③ clvmまわりの設定
④ GFS2でファイルシステムを作成
⑤ マウント
ではレッツトライ。
① 必要なパッケージをyumでサクッとインストール。
yumでインストールするなら、yum install kmod-gfs gfs2-utils cman lvm2-cluster あたりをインストール。「lvm2」は最初から入っていると思うので書いてないが、書いても特に害はないので心配性な人はlvm2も書いて差し支えない。
② cmanまわりの設定
/etc/cluster/cluster.conf を書く。XMLファイルなので面倒くさい。ちなみにGUIでサポートしてくれるものもあるが、そんなゆとり教育は(ry
RedHatの公式・英文なドキュメントに四苦八苦しながらも、以下のような内容を記述。おそらくこれが最低限の内容じゃないかと思われる。
<?xml version="1.0"?> <cluster name="fushigiStar" config_version="1"> <clusternodes> <clusternode name="rein" nodeid="1"> </clusternode> <clusternode name="fine" nodeid="2"> </clusternode> </clusternodes> </cluster>
ちなみにこのファイルは両方のサーバに設置する。
設置したら、service cman start(または「restart」)で設定を反映しておく。
あと、忘れずにchkconfig cman onとかも実行。
③ clvmまわりの設定
続いて、clvm(クラスタ対応のlvm)まわりの設定。
ロック方法の設定と、lvmの書き込みキャッシュの設定を変更すればよい。変更するファイルは/etc/lvm/lvm.confである。
デフォルトでは「locking_type = 1」と記述されている(はず)なので、これを「locking_type = 3」に変更する。
さらに、「write_cache_state = 1」と記述されている箇所を「write_cache_state = 0」と書き換える。
また、drbdより先にlvmがボリュームを握ってしまう現象を回避するため、フィルター設定も変更する。まず、オリジナルのフィルター部分の記述は…
filter = [ "a/.*/" ]
と記述されている(はず)。これは、「全てのデバイスについてpvscanしまくる」ということを言っている。しかし、drbdの起動より先に、生のデバイスについてpvscanされてしまうと、drbdが起動する際にエラーとなってしまうので、/dev/drbd*についてはpvscanをしてほしいがdrbdが使用する領域についてはpvscanしないで欲しいのである。そこで、テスト環境の場合は
[root@fine test]# cat /proc/partitions major minor #blocks name 3 0 16777152 hda 3 1 104391 hda1 3 2 16667437 hda2 3 64 16777152 hdb 3 65 16777120 hdb1 253 0 15073280 dm-0 253 1 1572864 dm-1 147 0 16776572 drbd0 253 2 16773120 dm-2
と、なっていてhda*についてはOSの起動用ディスクなのでpvscanをしてほしいがhdb*以降についてはpvscanなどしないで欲しい。しかしdrbd*についてはpvscanをして欲しいので、filterの設定を以下のように修正する必要が生じる。
filter = [ "a/drbd.*/", "a/hda.*/", "r/.*/" ]
変更したら、キャッシュファイルを手動で削除するため、rm -f /etc/lvm/cache/.cacheを実行し、service clvmd start(または「restart」)で設定を反映しておく。
こちらも同様にchkconfig clvmd onを忘れずに。
④ GFS2でファイルシステムを作成
いよいよ、ファイルシステムを作成する。まずはlvmの操作から。なお、drbdの公式サイトの情報では以下のコマンドを「両方のサーバで実行する」ようなことが書いてあるんだけども、個人的には片方でよくね?とも思うんだけどどうだろう…。
lvmについては通常の手順通り。
pvcreate /dev/drbd0 vgcreate --clustered y vgShareDrbd /dev/drbd0 lvcreate -l 100%VG -n lvData vgShareDrbd
これでlvmの論理ボリュームを作成すれば、clvmが即座に相手側サーバに伝達する模様。公式サイトには「--clustered y」の記述が無いが、コレがないと同時に書き込みしたときにサーバが返事をしなくなる模様。(へんじがない。ただのしかばねのようだ。)
mkfsする際はクラスタ用にいくつかオプションが増えることに注意する。
mkfs -t gfs2 -p lock_dlm -j 2 -t fushigiStar:ShareVolume /dev/vgShareDrbd/lvData
「-t gfs2」は、ファイルシステムの指定。
「-p lock_dlm」はロックマネージャの指定。
「-t fushigiStar:ShareVolume」はロックテーブルの名前を指定する。fushigiStarは/etc/cluster/cluster.confに記述したクラスタシステム名。ShareVolumeはクラスタシステム内で一意の名前であればよいとのこと。
さあ!それでは両方で同時にマウントしてみましょう!!!!!!!!
まずはrein側!!
[root@rein lvm]# mount -t gfs2 /dev/vgShareDrbd/lvData /mnt/work [root@rein lvm]# df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 14G 1.2G 13G 9% / /dev/hda1 99M 19M 76M 20% /boot tmpfs 379M 0 379M 0% /dev/shm /dev/mapper/vgShareDrbd-lvData 16G 259M 16G 2% /mnt/work
そしてfine側!!
[root@fine lvm]# mount -t gfs2 /dev/vgShareDrbd/lvData /mnt/work [root@fine lvm]# df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 14G 1.2G 13G 9% / /dev/hda1 99M 19M 76M 20% /boot tmpfs 379M 0 379M 0% /dev/shm /dev/mapper/vgShareDrbd-lvData 16G 259M 16G 2% /mnt/work
というわけで、まずは同時にマウント出来ました。
/mnt/work/testというディレクトリを作成し、両方のサーバからこのディレクトリにファイルを保存して、相手側サーバで作成したファイルをそれぞれ確認してみましょう。
まずはrein側
[root@rein ~]# mkdir /mnt/work/test [root@rein ~]# uname -a > /mnt/work/test/rein [root@rein ~]# cat /mnt/work/test/fine Linux fine 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:20:37 EDT 2011 i686 athlon i386 GNU/Linux
そしてfine側
[root@fine lvm]# uname -a > /mnt/work/test/fine [root@fine lvm]# cat /mnt/work/test/rein Linux rein 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:20:37 EDT 2011 i686 athlon i386 GNU/Linux
おっおっおっ ^ω^
うまくいってるくさいお ^ω^
離れた場所にある2つのストレージの同期 その2~デュアルプライマリモードに設定する~ [Linux(LVM/RAID/Storage)]
検証用環境をVirtualPCで2サーバ作成して実行しているため、drbdのディスク同期が猛烈に遅くて重いので、夜間ほったらかして同期実行をさせていたら、Windows Updateの自動更新でPCが勝手に再起動してしまい、また1から同期をすることになってしまって悲しい今日この頃、皆様いかがお過ごしでしょうか。(滝涙)
さて、前アーティクルでdrbdをごく普通にセットアップしたので今回は両方のサーバから同時に更新できるようにするためdrbdを「デュアルプライマリモード」にすることとします。
結論から言ってしまうと、物凄くあっけないです。(笑)
手順を確認しますと、以下のような感じ。
① /etc/drbd.confにデュアルプライマリモード用の設定を追加する
② 両サーバにてdrbdの切断&再接続&プライマリ昇格を実行(コマンド3発)
こんだけ。drbd.confへの追記内容も非常に簡単で拍子抜けします。(笑)
① /etc/drbd.confにデュアルプライマリモード用の設定を追加する
drbd.confに以下を追記します。場所は「resource」ブロックの中。(外でもいいみたいですが、リソースが1個しかないのでどちらでも一緒。一応ここではブロックの中に書いています。)
意味としては「net」ブロックでデュアルプライマリモードの動作を許可して、「startup」ブロックで両方のサーバが起動時にプライマリモードになるように設定しています。こんだけ。これを「resource」ブロックの中に記述するだけです。
念のため、今回のテスト環境におけるdrbd.confを晒しておくと…
という具合。
なお、このファイルはreinとfineと両方に同じファイルを置く必要がある。片方で編集したら、scpなりなんなりしてやればよろしいかと。
② 両サーバにてdrbdの切断&再接続&プライマリ昇格を実行(コマンド3発)
で、drbd.confの編集と配布が終わったら、この内容を反映させるべくコマンドを3発ほど投入する。
これらのコマンドは両方のサーバで実行する必要がある。
作業としてはたったこれだけ。簡単ですなあ。
では、drbdの状態を確認してみることにする。/proc/drbdを見れば一目瞭然。
「ro:Primary/Primary」という表示部分がソレ。ロールが両方のサーバ共に「Primary」となっている。ちなみに前アーティクルでは「ro:Primary/Secondary」となっていたので、明らかにロールが異なっていることが確認できよう。
では、両方のサーバで同じボリュームをマウントしてみよう…。
なお、先に断っておくがまだこの状態では双方のサーバから「同時に」ファイルやディレクトリのアクセス・更新は出来ないので要注意。なぜなら前アーティクルで/dev/drbd0の領域を「ext3」でフォーマットしているが、ext3は複数のサーバから同時にアクセスされることを想定していないファイルシステムなので、ファイルやディレクトリを破壊してしまう恐れがある。この対策は次アーティクルで。
…という訳なので、確認の内容としては前アーティクルでやったような「プライマリ・セカンダリの切り替えをすることなく」mount/umountできるということにとどまる。
まず、reinでマウントしてみよう。
はい。きちんと確認できました。
では、fine側でも同じ事をしてみます。この時drbdadmコマンドでprimary/secondaryの切り替えを行わないでマウント出来ることに注目。
コマンドプロンプトのサーバ名の所をエディタか何かで書き換えたんじゃないか?と思うような全く同じ結果になっていますな。(笑)
このように、両方のサーバから同じデータにアクセスできるということが確認できました。
次は両方のボリュームを同時にマウントして、同時にアクセスできるようにします。
さて、前アーティクルでdrbdをごく普通にセットアップしたので今回は両方のサーバから同時に更新できるようにするためdrbdを「デュアルプライマリモード」にすることとします。
結論から言ってしまうと、物凄くあっけないです。(笑)
手順を確認しますと、以下のような感じ。
① /etc/drbd.confにデュアルプライマリモード用の設定を追加する
② 両サーバにてdrbdの切断&再接続&プライマリ昇格を実行(コマンド3発)
こんだけ。drbd.confへの追記内容も非常に簡単で拍子抜けします。(笑)
① /etc/drbd.confにデュアルプライマリモード用の設定を追加する
drbd.confに以下を追記します。場所は「resource」ブロックの中。(外でもいいみたいですが、リソースが1個しかないのでどちらでも一緒。一応ここではブロックの中に書いています。)
net { allow-two-primaries; } startup { become-primary-on both; }
意味としては「net」ブロックでデュアルプライマリモードの動作を許可して、「startup」ブロックで両方のサーバが起動時にプライマリモードになるように設定しています。こんだけ。これを「resource」ブロックの中に記述するだけです。
念のため、今回のテスト環境におけるdrbd.confを晒しておくと…
include "/etc/drbd.d/global_common.conf"; include "/etc/drbd.d/*.res"; resource r0 { net { allow-two-primaries; } startup { become-primary-on both; } on rein { device /dev/drbd0; disk /dev/hdb1; address ***.***.***.241:7789; meta-disk internal; } on fine { device /dev/drbd0; disk /dev/hdb1; address ***.***.***.242:7789; meta-disk internal; } }
という具合。
なお、このファイルはreinとfineと両方に同じファイルを置く必要がある。片方で編集したら、scpなりなんなりしてやればよろしいかと。
② 両サーバにてdrbdの切断&再接続&プライマリ昇格を実行(コマンド3発)
で、drbd.confの編集と配布が終わったら、この内容を反映させるべくコマンドを3発ほど投入する。
drbdadm disconnect r0 drbdadm connect r0 drbdadm primary r0
これらのコマンドは両方のサーバで実行する必要がある。
作業としてはたったこれだけ。簡単ですなあ。
では、drbdの状態を確認してみることにする。/proc/drbdを見れば一目瞭然。
[root@rein ~]# cat /proc/drbd version: 8.3.8 (api:88/proto:86-94) GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:16 0: cs:SyncSource ro:Primary/Primary ds:UpToDate/Inconsistent C r---- ns:480676 nr:8 dw:76 dr:597401 al:0 bm:36 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:3399932 [=>..................] sync'ed: 12.5% (3399932/3880540)K delay_probe: 658127 finish: 1:46:14 speed: 416 (308) K/sec
「ro:Primary/Primary」という表示部分がソレ。ロールが両方のサーバ共に「Primary」となっている。ちなみに前アーティクルでは「ro:Primary/Secondary」となっていたので、明らかにロールが異なっていることが確認できよう。
では、両方のサーバで同じボリュームをマウントしてみよう…。
なお、先に断っておくがまだこの状態では双方のサーバから「同時に」ファイルやディレクトリのアクセス・更新は出来ないので要注意。なぜなら前アーティクルで/dev/drbd0の領域を「ext3」でフォーマットしているが、ext3は複数のサーバから同時にアクセスされることを想定していないファイルシステムなので、ファイルやディレクトリを破壊してしまう恐れがある。この対策は次アーティクルで。
…という訳なので、確認の内容としては前アーティクルでやったような「プライマリ・セカンダリの切り替えをすることなく」mount/umountできるということにとどまる。
まず、reinでマウントしてみよう。
[root@rein ~]# mount /dev/drbd0 /mnt/work [root@rein ~]# df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 14G 1.2G 13G 9% / /dev/hda1 99M 19M 76M 20% /boot tmpfs 379M 0 379M 0% /dev/shm /dev/drbd0 16G 222M 15G 2% /mnt/work [root@rein ~]# find /mnt/work/etc -print | head /mnt/work/etc /mnt/work/etc/fonts /mnt/work/etc/fonts/fonts.dtd /mnt/work/etc/fonts/conf.d /mnt/work/etc/fonts/conf.d/60-latin.conf /mnt/work/etc/fonts/conf.d/80-delicious.conf /mnt/work/etc/fonts/conf.d/20-fix-globaladvance.conf /mnt/work/etc/fonts/conf.d/69-unifont.conf /mnt/work/etc/fonts/conf.d/90-synthetic.conf /mnt/work/etc/fonts/conf.d/64-nonlatin-fedora.conf [root@rein ~]# umount /mnt/work
はい。きちんと確認できました。
では、fine側でも同じ事をしてみます。この時drbdadmコマンドでprimary/secondaryの切り替えを行わないでマウント出来ることに注目。
[root@fine ~]# mount /dev/drbd0 /mnt/work [root@fine ~]# df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 14G 1.2G 13G 9% / /dev/hda1 99M 19M 76M 20% /boot tmpfs 379M 0 379M 0% /dev/shm /dev/drbd0 16G 222M 15G 2% /mnt/work [root@fine ~]# find /mnt/work/etc -print | head /mnt/work/etc /mnt/work/etc/fonts /mnt/work/etc/fonts/fonts.dtd /mnt/work/etc/fonts/conf.d /mnt/work/etc/fonts/conf.d/60-latin.conf /mnt/work/etc/fonts/conf.d/80-delicious.conf /mnt/work/etc/fonts/conf.d/20-fix-globaladvance.conf /mnt/work/etc/fonts/conf.d/69-unifont.conf /mnt/work/etc/fonts/conf.d/90-synthetic.conf /mnt/work/etc/fonts/conf.d/64-nonlatin-fedora.conf [root@fine ~]# umount /mnt/work
コマンドプロンプトのサーバ名の所をエディタか何かで書き換えたんじゃないか?と思うような全く同じ結果になっていますな。(笑)
このように、両方のサーバから同じデータにアクセスできるということが確認できました。
次は両方のボリュームを同時にマウントして、同時にアクセスできるようにします。
離れた場所にある2つのストレージの同期 その1~drbdのインストールとセットアップ~ [Linux(LVM/RAID/Storage)]
離れた場所にある(隣り合っててもいいんだけど…)2つのサーバがあるとして、そのストレージ領域の内容を同期したいんだけどどうすればいいか…ということを考えるとき、まずもっともアンチョクな方法としては
定期的にrsyncすればよくね?
ってのがありますな。
1日に1回とか、数時間に1回とかにrsyncを実行すればよろしいかと。
ところが、この方法では注意しておかないと「どっちかが原本」で、「どっちかがコピー」というような運用になってしまう。しかし場合によっては「どちら側からでも原本としてアクセスできないものか」という需要もあろう。例えば会社だったら本社と支社との間をVPNでつなげておいて両方から単一の共有ディスクにアクセスさせたいが、VPNごしにアクセスすると死ぬほど遅いなんてこともあり得るので、両方の拠点にストレージサーバを置いて、そのストレージサーバ間で常時同期を取ったりできないか? みたいなケース。
これ、結構需要あるんだよねー。例えば「同じExcelのデータを両方で見たり書いたりしたい」とかさー。
そんな訳で、物は試しに、「drbdのデュアルプライマリーモード」を使って、それっぽい環境を作れないか試してみた。
まずは、何はなくともdrbdをインストールしてセットアップするところから。
まず、用意した環境は(本当に遠隔地の環境を用意するのはとっても面倒くさいので)VirtualPCにCentOSなサーバを2個用意。
サーバA:rein
サーバB:fine
ということにでもしておこうか。
まずは、両方のサーバでdrbdをインストール。
はい。インストール終了。ラクチンポンである。(笑)
ちなみに、drbdが使用する領域は独立したボリュームかパーティションである必要があるそうなので、fdiskでパーティションを作るなりしてこれを用意する。
今回はVirtualPCを使っているので、一本目のディスク/dev/hdaはOSが入っている。二本目のディスク/dev/hdbをdrbd用に用意。fdiskで/dev/hdb1を作成している。
↓こんな感じ。
次に、drbdの設定を行う。drbd公式サイトの情報を見て、ひとまず/etc/drbd.confに以下の通り記述した。
「include」はグローバル設定項目とかを読み込んでくる呪文。ひとまず詳しいことは割愛する。
「resource」で始まるブロックが、今回準備するdrbdで使用するディスクリソースの内容。「r0」と記述してあるのがリソース名。
「on」で始まるブロックが、個々のサーバで使用するリソースの設定。「rein」と「fine」がサーバ名。/etc/hostsやDNSにしっかり指定しておくこと。後の項目は空気が読める人なら説明不要かと思うが(察して!)、addressについてはIPアドレスで記述している。ここは/etc/hostsやDNSでの設定ときれいに一致させておくように。
さて、これでdrbdについては必要最低限の設定が完了したので、
①両ホストのdrbdデバイスにメタデータ領域を作成する
②両方ストのdrbdデバイス(リソース)をそれぞれアタッチする
③両ホストのdrbdデバイス(リソース)に対して同期を指示する(まだ同期しない)
④両ホストのdrbdどうしを接続させる
⑤ディスクの同期を開始する
という手順を踏む。
①両ホストのdrbdデバイスにメタデータ領域を作成する
これはコマンド一発でおわる。
②両方ストのdrbdデバイス(リソース)をそれぞれアタッチする
これもコマンド一発。
正常終了時なら何も表示されないので心配しないように。
③両ホストのdrbdデバイス(リソース)に対して同期を指示する(まだ同期しない)
これもコマンド一発。しかも無言。(笑)
④両ホストのdrbdどうしを接続させる
これも以下略
⑤ディスクの同期を開始する
さて、ここまで①~④については両方のホストで同じコマンドを実行するのだが、この項目についてはどちらか一方(原本になる方)だけで実行するので注意すること。ぶっちゃけ、まだディスクの中身は空っぽなので、どちらでやっても構わないのだが。
これを実行すると、両サーバ間でディスクの内容が同期される。イメージとしてはRAID0のミラーを最初に同期しにいくような感じだろうか。
同期の状態は/proc/drbdの中を見れば確認できる。
…。結構かかるなあ。(笑)
なお、drbdの同期が実行中であっても、mdadmと同様に直ちにこのボリュームを使用することも可能だ。
ためしに、このボリュームをフォーマットしてマウントしてみよう。
…さすがに、VirtualPCで2個サーバを起動してdrbdの同期中にこんなこと実行すると超重い。(笑)
まずはrein側で、ディスクをマウントしてみた。ちゃんと領域が見えていることが判る。
ここに何かファイルを置いてみよう。
こんな感じでファイルを置いてみた。(重い!:笑)
では、これを対向側のfineで見てみよう。
そうそう。今はext3でファイルシステムを作成しているので、対向側でマウントする前に、アンマウントしておかないといけない。同時にこのファイルシステムは使えないのだ。(対策は後ほど)
また、今回reinが「Primary」で、fineが「Secondary」になっているので、これもひっくり返さなければならない。(今はまだ「シングルプライマリモード」で動作しているため。
rein側でアンマウントと、Secondaryにするためのコマンドを投入する。
と、した後で、さっそく対向側のfineをPrimaryにしてからマウントしてみよう。
マウントできた。fine側ではファイルシステムを作成していないのにマウントできている。ということは、rein側の変更内容が確かに伝わっているということが判る。
ディスクの中身も確認してみよう。
内容も確認できている。
reinとfineは/dev/drbd0デバイスによって同じ内容が確認できる状態になった。
しかし、今はまだ同時に読み書き出来る状態にはないので、次のアーティクルでは両方から同時にアクセスが通るようにしたい。(多分その「前編」になるかな…)
それにしても…PC重いぜ…(笑)
定期的にrsyncすればよくね?
ってのがありますな。
1日に1回とか、数時間に1回とかにrsyncを実行すればよろしいかと。
ところが、この方法では注意しておかないと「どっちかが原本」で、「どっちかがコピー」というような運用になってしまう。しかし場合によっては「どちら側からでも原本としてアクセスできないものか」という需要もあろう。例えば会社だったら本社と支社との間をVPNでつなげておいて両方から単一の共有ディスクにアクセスさせたいが、VPNごしにアクセスすると死ぬほど遅いなんてこともあり得るので、両方の拠点にストレージサーバを置いて、そのストレージサーバ間で常時同期を取ったりできないか? みたいなケース。
これ、結構需要あるんだよねー。例えば「同じExcelのデータを両方で見たり書いたりしたい」とかさー。
そんな訳で、物は試しに、「drbdのデュアルプライマリーモード」を使って、それっぽい環境を作れないか試してみた。
まずは、何はなくともdrbdをインストールしてセットアップするところから。
まず、用意した環境は(本当に遠隔地の環境を用意するのはとっても面倒くさいので)VirtualPCにCentOSなサーバを2個用意。
サーバA:rein
サーバB:fine
ということにでもしておこうか。
まずは、両方のサーバでdrbdをインストール。
yum install drbd83 kmod-drbd83
はい。インストール終了。ラクチンポンである。(笑)
ちなみに、drbdが使用する領域は独立したボリュームかパーティションである必要があるそうなので、fdiskでパーティションを作るなりしてこれを用意する。
今回はVirtualPCを使っているので、一本目のディスク/dev/hdaはOSが入っている。二本目のディスク/dev/hdbをdrbd用に用意。fdiskで/dev/hdb1を作成している。
↓こんな感じ。
[root@fine ~]# fdisk -l Disk /dev/hda: 17.1 GB, 17179803648 bytes 255 heads, 63 sectors/track, 2088 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes デバイス Boot Start End Blocks Id System /dev/hda1 * 1 13 104391 83 Linux /dev/hda2 14 2088 16667437+ 8e Linux LVM Disk /dev/hdb: 17.1 GB, 17179803648 bytes 16 heads, 63 sectors/track, 33288 cylinders Units = シリンダ数 of 1008 * 512 = 516096 bytes デバイス Boot Start End Blocks Id System /dev/hdb1 1 33288 16777120+ 83 Linux
次に、drbdの設定を行う。drbd公式サイトの情報を見て、ひとまず/etc/drbd.confに以下の通り記述した。
include "/etc/drbd.d/global_common.conf"; include "/etc/drbd.d/*.res"; resource r0 { on rein { device /dev/drbd0; disk /dev/hdb1; address ***.***.***.241:7789; meta-disk internal; } on fine { device /dev/drbd0; disk /dev/hdb1; address ***.***.***.242:7789; meta-disk internal; } }
「include」はグローバル設定項目とかを読み込んでくる呪文。ひとまず詳しいことは割愛する。
「resource」で始まるブロックが、今回準備するdrbdで使用するディスクリソースの内容。「r0」と記述してあるのがリソース名。
「on」で始まるブロックが、個々のサーバで使用するリソースの設定。「rein」と「fine」がサーバ名。/etc/hostsやDNSにしっかり指定しておくこと。後の項目は空気が読める人なら説明不要かと思うが(察して!)、addressについてはIPアドレスで記述している。ここは/etc/hostsやDNSでの設定ときれいに一致させておくように。
さて、これでdrbdについては必要最低限の設定が完了したので、
①両ホストのdrbdデバイスにメタデータ領域を作成する
②両方ストのdrbdデバイス(リソース)をそれぞれアタッチする
③両ホストのdrbdデバイス(リソース)に対して同期を指示する(まだ同期しない)
④両ホストのdrbdどうしを接続させる
⑤ディスクの同期を開始する
という手順を踏む。
①両ホストのdrbdデバイスにメタデータ領域を作成する
これはコマンド一発でおわる。
drbdadm create-md r0
②両方ストのdrbdデバイス(リソース)をそれぞれアタッチする
これもコマンド一発。
drbdadm attach r0
正常終了時なら何も表示されないので心配しないように。
③両ホストのdrbdデバイス(リソース)に対して同期を指示する(まだ同期しない)
これもコマンド一発。しかも無言。(笑)
drbdadm syncer r0
④両ホストのdrbdどうしを接続させる
これも以下略
drbdadm connect r0
⑤ディスクの同期を開始する
さて、ここまで①~④については両方のホストで同じコマンドを実行するのだが、この項目についてはどちらか一方(原本になる方)だけで実行するので注意すること。ぶっちゃけ、まだディスクの中身は空っぽなので、どちらでやっても構わないのだが。
drbdadm -- --overwrite-data-of-peer primary r0
これを実行すると、両サーバ間でディスクの内容が同期される。イメージとしてはRAID0のミラーを最初に同期しにいくような感じだろうか。
同期の状態は/proc/drbdの中を見れば確認できる。
[root@rein etc]# cat /proc/drbd version: 8.3.8 (api:88/proto:86-94) GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:16 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---- ns:1792 nr:0 dw:0 dr:1792 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:16774780 [>....................] sync'ed: 0.1% (16380/16380)M delay_probe: 0 finish: 11:38:56 speed: 356 (356) K/sec
…。結構かかるなあ。(笑)
なお、drbdの同期が実行中であっても、mdadmと同様に直ちにこのボリュームを使用することも可能だ。
ためしに、このボリュームをフォーマットしてマウントしてみよう。
[root@rein etc]# mkfs -t ext3 -j /dev/drbd0 mke2fs 1.39 (29-May-2006) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 2097152 inodes, 4194143 blocks 209707 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 128 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 23 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. [root@rein etc]# mkdir -p /mnt/work [root@rein etc]# mount /dev/drbd0 /mnt/work [root@rein etc]# df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 14G 1.2G 13G 9% / /dev/hda1 99M 19M 76M 20% /boot tmpfs 379M 0 379M 0% /dev/shm /dev/drbd0 16G 173M 15G 2% /mnt/work
…さすがに、VirtualPCで2個サーバを起動してdrbdの同期中にこんなこと実行すると超重い。(笑)
まずはrein側で、ディスクをマウントしてみた。ちゃんと領域が見えていることが判る。
ここに何かファイルを置いてみよう。
[root@rein etc]# mkdir /mnt/work/etc [root@rein etc]# cp -r /etc/* /mnt/work/etc/ [root@rein etc]# find /mnt/work/etc -print | head /mnt/work/etc /mnt/work/etc/fonts /mnt/work/etc/fonts/fonts.dtd /mnt/work/etc/fonts/conf.d /mnt/work/etc/fonts/conf.d/60-latin.conf /mnt/work/etc/fonts/conf.d/80-delicious.conf /mnt/work/etc/fonts/conf.d/20-fix-globaladvance.conf /mnt/work/etc/fonts/conf.d/69-unifont.conf /mnt/work/etc/fonts/conf.d/90-synthetic.conf /mnt/work/etc/fonts/conf.d/64-nonlatin-fedora.conf
こんな感じでファイルを置いてみた。(重い!:笑)
では、これを対向側のfineで見てみよう。
そうそう。今はext3でファイルシステムを作成しているので、対向側でマウントする前に、アンマウントしておかないといけない。同時にこのファイルシステムは使えないのだ。(対策は後ほど)
また、今回reinが「Primary」で、fineが「Secondary」になっているので、これもひっくり返さなければならない。(今はまだ「シングルプライマリモード」で動作しているため。
rein側でアンマウントと、Secondaryにするためのコマンドを投入する。
[root@rein etc]# umount /mnt/work [root@rein etc]# df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 14G 1.2G 13G 9% / /dev/hda1 99M 19M 76M 20% /boot tmpfs 379M 0 379M 0% /dev/shm [root@rein etc]# drbdadm secondary r0
と、した後で、さっそく対向側のfineをPrimaryにしてからマウントしてみよう。
[root@fine ~]# drbdadm primary r0 [root@fine ~]# mkdir -p /mnt/work [root@fine ~]# mount /dev/drbd0 /mnt/work [root@fine ~]# df -h Filesystem サイズ 使用 残り 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 14G 1.2G 13G 9% / /dev/hda1 99M 19M 76M 20% /boot tmpfs 379M 0 379M 0% /dev/shm /dev/drbd0 16G 222M 15G 2% /mnt/work
マウントできた。fine側ではファイルシステムを作成していないのにマウントできている。ということは、rein側の変更内容が確かに伝わっているということが判る。
ディスクの中身も確認してみよう。
[root@fine ~]# find /mnt/work/etc -print | head /mnt/work/etc /mnt/work/etc/fonts /mnt/work/etc/fonts/fonts.dtd /mnt/work/etc/fonts/conf.d /mnt/work/etc/fonts/conf.d/60-latin.conf /mnt/work/etc/fonts/conf.d/80-delicious.conf /mnt/work/etc/fonts/conf.d/20-fix-globaladvance.conf /mnt/work/etc/fonts/conf.d/69-unifont.conf /mnt/work/etc/fonts/conf.d/90-synthetic.conf /mnt/work/etc/fonts/conf.d/64-nonlatin-fedora.conf
内容も確認できている。
reinとfineは/dev/drbd0デバイスによって同じ内容が確認できる状態になった。
しかし、今はまだ同時に読み書き出来る状態にはないので、次のアーティクルでは両方から同時にアクセスが通るようにしたい。(多分その「前編」になるかな…)
それにしても…PC重いぜ…(笑)
LSIのRAIDカード、CLIからホットスペアディスクを追加する [備忘録]
ものすごくニッチなメモだと思うが、ハマったのでメモ残しておく。(笑)
LSIのRAIDカード9650SEでRAID5のアレイを作成してあるストレージサーバで、ディスクが1本故障。ホットスペアを使用したリビルドが走って事なきを得たが、ディスクを交換後、それをホットスペアディスクとしてCLIから組み込む方法がよく判らなかった。リビルド完了後・ディスク交換作業直後の状態
p7のスロットにあるディスクが、交換作業を終えて、ホットスペアに組み込みたいディスク。
(苦手な)英語のマニュアルを読んでいくと、/cx add type=spare disk=p:-pとかいう書式でいけそうだと判った。
…が、コレがうまくいかなかった。
うーむ…。そのディスクは使えませんお(^ω^) ということ。新品ではないが問題ないはずのディスクなんだけどもなあ…。
うーむむむ。よくわからん。
そこで、ディスクを一旦抜き差ししてみた。
すると…
なんということでしょう~! p7のディスクの「Unit」の項目が「u?」から「-」に変化している。
案の定…
ホットスペアとして組み込みに成功。
「u?」という状態になってたらダメなんだねー。知りませんでした。
LSIのRAIDカード9650SEでRAID5のアレイを作成してあるストレージサーバで、ディスクが1本故障。ホットスペアを使用したリビルドが走って事なきを得たが、ディスクを交換後、それをホットスペアディスクとしてCLIから組み込む方法がよく判らなかった。リビルド完了後・ディスク交換作業直後の状態
//sunflower> /c6 show all /c6 Driver Version = 2.26.08.007-2.6.18RH /c6 Model = 9650SE-16ML /c6 Available Memory = 224MB /c6 Firmware Version = FE9X 4.08.00.006 /c6 Bios Version = BE9X 4.08.00.001 /c6 Boot Loader Version = BL9X 3.08.00.001 (略) Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 256K 16763.7 RiW ON VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 1.82 TB SATA 0 - WDC WD20EARS-00S8B1 p1 OK u0 1.82 TB SATA 1 - WDC WD20EARS-00S8B1 p2 OK u0 1.82 TB SATA 2 - WDC WD20EARS-00S8B1 p3 OK u0 1.82 TB SATA 3 - WDC WD20EARS-00S8B1 p4 OK u0 1.82 TB SATA 4 - WDC WD20EARS-00MVWB0 p5 OK u0 1.82 TB SATA 5 - WDC WD20EARS-00S8B1 p6 OK u0 1.82 TB SATA 6 - WDC WD20EARS-00MVWB0 p7 OK u? 1.82 TB SATA 7 - WDC WD20EARS-00S8B1 p8 OK u0 1.82 TB SATA 8 - WDC WD20EARS-00S8B1 p9 OK u0 1.82 TB SATA 9 - WDC WD20EARS-00MVWB0 p10 OK u0 1.82 TB SATA 10 - WDC WD20EARS-00MVWB0
p7のスロットにあるディスクが、交換作業を終えて、ホットスペアに組み込みたいディスク。
(苦手な)英語のマニュアルを読んでいくと、/cx add type=spare disk=p:-pとかいう書式でいけそうだと判った。
…が、コレがうまくいかなかった。
//sunflower> /c6 add type=spare disk=7 The following drive(s) cannot be used [7]. Error: (CLI:144) Invalid drive(s) specified.
うーむ…。そのディスクは使えませんお(^ω^) ということ。新品ではないが問題ないはずのディスクなんだけどもなあ…。
//sunflower> /c6/p7 show all /c6/p7 Status = OK /c6/p7 Model = WDC WD20EARS-00S8B1 /c6/p7 Firmware Version = 80.00A80 /c6/p7 Serial = WD-WCAVY3331147 /c6/p7 Capacity = 1.82 TB (3907029168 Blocks) /c6/p7 Reallocated Sectors = 0 /c6/p7 Power On Hours = 7284 /c6/p7 Temperature = 37 deg C /c6/p7 Spindle Speed = 5400 RPM /c6/p7 Link Speed Supported = 1.5 Gbps and 3.0 Gbps /c6/p7 Link Speed = 3.0 Gbps /c6/p7 NCQ Supported = Yes /c6/p7 NCQ Enabled = Yes /c6/p7 Identify Status = N/A /c6/p7 Belongs to Unit = N/A /c6/p7 Drive SMART Data: 10 00 01 2F 00 C8 C8 00 00 00 00 00 00 00 03 27 00 97 94 D1 24 00 00 00 00 00 04 32 00 64 64 2A 00 00 00 00 00 00 05 33 00 C8 C8 00 00 00 00 00 00 00 07 2E 00 C8 C8 00 00 00 00 00 00 00 09 32 (以下略)
うーむむむ。よくわからん。
そこで、ディスクを一旦抜き差ししてみた。
すると…
//sunflower> /c6 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 256K 16763.7 RiW ON VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 1.82 TB SATA 0 - WDC WD20EARS-00S8B1 p1 OK u0 1.82 TB SATA 1 - WDC WD20EARS-00S8B1 p2 OK u0 1.82 TB SATA 2 - WDC WD20EARS-00S8B1 p3 OK u0 1.82 TB SATA 3 - WDC WD20EARS-00S8B1 p4 OK u0 1.82 TB SATA 4 - WDC WD20EARS-00MVWB0 p5 OK u0 1.82 TB SATA 5 - WDC WD20EARS-00S8B1 p6 OK u0 1.82 TB SATA 6 - WDC WD20EARS-00MVWB0 p7 OK - 1.82 TB SATA 7 - WDC WD20EARS-00S8B1 p8 OK u0 1.82 TB SATA 8 - WDC WD20EARS-00S8B1 p9 OK u0 1.82 TB SATA 9 - WDC WD20EARS-00MVWB0 p10 OK u0 1.82 TB SATA 10 - WDC WD20EARS-00MVWB0
なんということでしょう~! p7のディスクの「Unit」の項目が「u?」から「-」に変化している。
案の定…
//sunflower> /c6 add type=spare disk=7 Creating new unit on controller /c6 ... Done. The new unit is /c6/u1. WARNING: This Spare unit may replace failed drive of same interface type only. //sunflower> /c6 show all /c6 Driver Version = 2.26.08.007-2.6.18RH /c6 Model = 9650SE-16ML /c6 Available Memory = 224MB /c6 Firmware Version = FE9X 4.08.00.006 /c6 Bios Version = BE9X 4.08.00.001 /c6 Boot Loader Version = BL9X 3.08.00.001 (略) Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy ------------------------------------------------------------------------------ u0 RAID-5 OK - - 256K 16763.7 RiW ON u1 SPARE OK - - - 1863.01 - OFF VPort Status Unit Size Type Phy Encl-Slot Model ------------------------------------------------------------------------------ p0 OK u0 1.82 TB SATA 0 - WDC WD20EARS-00S8B1 p1 OK u0 1.82 TB SATA 1 - WDC WD20EARS-00S8B1 p2 OK u0 1.82 TB SATA 2 - WDC WD20EARS-00S8B1 p3 OK u0 1.82 TB SATA 3 - WDC WD20EARS-00S8B1 p4 OK u0 1.82 TB SATA 4 - WDC WD20EARS-00MVWB0 p5 OK u0 1.82 TB SATA 5 - WDC WD20EARS-00S8B1 p6 OK u0 1.82 TB SATA 6 - WDC WD20EARS-00MVWB0 p7 OK u1 1.82 TB SATA 7 - WDC WD20EARS-00S8B1 p8 OK u0 1.82 TB SATA 8 - WDC WD20EARS-00S8B1 p9 OK u0 1.82 TB SATA 9 - WDC WD20EARS-00MVWB0 p10 OK u0 1.82 TB SATA 10 - WDC WD20EARS-00MVWB0
ホットスペアとして組み込みに成功。
「u?」という状態になってたらダメなんだねー。知りませんでした。