Takehiro Matsushima
takeh****@gmail*****
2015年 2月 18日 (水) 21:24:03 JST
Fork北林さん
松島です。
私はたまたま最近Pacemakerを触っているだけのいちユーザーに過ぎませんので、恐縮です。
開発者やベテランの皆様には頭が上がりません...
> ①
> 【基本稼動はfirstサーバにして、
> firstサーバで異常があった場合はsecondサーバに管理をまかせたい。
> その後、firstサーバの異常がなおって、管理をsecondからfirstに移したい時、
> secondサーバのpacemakerの再起動以外に方法はあるのか】
この場合、全てがひとつのグループに入っていますので、グループをmove(またはmigrate)すれば
まるごとリソースが移動します(もちろんcleanup後です)。
# crm resource move web-group
つぎのようにしても全く同じです。
# crm resource migrate web-group
このコマンドを叩くたびにノードを行ったり来たりします。
移動し終えたならば次のコマンドを必ず実行するようにしてください。
# crm resource unmove web-group
これを忘れると障害が起きてもフェイルオーバーしませんのでご注意ください。
moveコマンドは特定のノードでリソースが動作しないようにlocation制約を自動的に設定して
リソースを移動していますので、unmoveでこの制約を削除しないとフェイルオーバー先の
候補がなくなってしまう、という理由です。
> ②
> 【"corosync.conf.example"と"corosync.conf.example.udpu"の違いと、設定の内容】
>
> 松島様の設定を参考に、
> /etc/corosync/corosync.confを"corosync.conf.example.udpu"を元に作成していますが、
> "corosync.conf.example"との違いはなんなのでしょうか。
両者はクラスタの通信方式の違いがあります。
corosync.conf.exampleはUDPマルチキャストという通信方式をつかったサンプル、
corosync.conf.udpuはUDPユニキャストという通信方式を使ったサンプルです。
両者の違いはおおむね次のようになります。
ユニキャストは通信相手のアドレスを指定した一対一の通信になります。
ノードの数が少ない場合にはこちらで問題ありません。
それに対してマルチキャストは同じグループのホスト同士で通信する多対多の通信です。
ちょうどメーリングリストのようなイメージですね。
ノードが多い場合にはこちらのほうがネットワークのトラフィックが少なくなります。
マルチキャストとユニキャストとでは設定項目が若干変わりますが、詳細は
man corosync.confでご確認いただければと思います。
設定ファイル中の項目に関するご質問への回答もmanに詳細がございますが、
ざっくりと、とのことでしたので以下インラインで記述させていただきます。
(実はあまり細かく設定したことが無いのでよくわかっていないのですが...)
> corosync.conf
> # Please read the corosync.conf.5 manual page
> totem {
> version: 2
>
> crypto_cipher: none ※1
> crypto_hash: none ※2
これらはノード同士の通信の、認証に関わる設定です。
HMAC(Hash-based Message Authentication Code)という方法を使っています。
crypto_hashが使用するハッシュ関数の指定、crypto_cipherが通信の暗号関数の指定です。
この設定を削除すると、デフォルトでSHA1でハッシュし、AES256で暗号化されます。
ここではnoneを指定して、認証処理をしないようにしています。
ノードのなりすましや盗み見を防ぐには認証処理の有効化が必要です。
そのためにはcorosync-keygenをつかってできたauthkeyファイルをすべてのノードの
/etc/corosync/に配置し、パーミッションを400にしておきます。
>
> interface {
> ringnumber: 0
> bindnetaddr: 192.168.128.0
> mcastport: 5405
> ttl: 1
> }
> transport: udpu ※3
こちらは前述のとおり、UDP Unicastを使う、という設定です。
"udp"と書くと、UDP Multicastがつかわれます。
> }
>
> logging {
> fileline: off
> to_logfile: yes
> to_syslog: no
> logfile: /var/log/cluster/corosync.log
> debug: off
> timestamp: on
> logger_subsys { ※4
> subsys: QUORUM
> debug: off
> }
こちらはサブシステムごとのロギングを個別に設定するためのところです。
マニュアルによると、
"logger_subsys directives are optional"
となっているので、複数指定できるはずです。
サブシステムの指定は"subsys: "でしますが、指定できるサブシステムは次のもののようです。
QUORUM, APIDEF, MAIN, PLOAD, SERV, KYD, MON, SYNC, WD, CFG, CMAP, CPG, VOTEQ
(ソースをLOGSYS_DECLARE_SUBSYSでgrepしました)
loggingで設定している内容が全体で使われる内容で、logger_subsys内の設定は全体設定を
上書きします。
従って、この設定のままではあまり意味がないと思いますが、ログを分離したり、部分的に
debugログを有効・無効にしたりするのに役立つのだと思います
(やったことがないので申し訳ございません)
ログローテーションの件ですが、corosync.confで"to_logfile: yes"とした場合には、logrotateの
設定に"copytruncate"が無いと、ローテート以降ログが出なくなってしまいます。
/var/log/cluster/corosync.log{
missingok
notifempty
daily
rotate 30
compress
copytruncate
}
corosyncが開いていたログファイルを移動するか、コピーした後に切り詰めるかという違いですが、
前者はログファイルの実体が移動してしまいます。対して後者はログファイルの実体は変わりません。
ただ、RPMでインストールすると、標準で設定ファイルが作られるかと思いますが...
だいぶ遅くなってしまいましたが、以上、お答えになっておりますでしょうか。
----
Takehiro Matsushima