第６９日目：【雪だるま】「aniki」システムをもう一度テストしてみよう・・・
|
どうも、('A`)です。
えーと、前回の日記でも書いたのですが、A-Tigerの4台のセットアップで手間取っています。
あぶらみくん( ｀э´)と一つづつパッケージをインストールしながら、どこで接続エラーが
引き起こされるのか調べているところです。
少なくともOSインストール時点では接続エラーは起こりません。
でもなあ、標準のSSHを使っているし、/etc/rc.confや/etc/resolv.confをいじらなくても
エラーになるんだよなあ、、、
各サーバによって接続エラーから自動復旧したり、そのまま「お亡くなり」になったりと
パターンもまちまちだし。
引き続きあぶらみくん( ｀э´)と色々試しながらサーバを完成させようと努めています。
で、('A`)の方はmatdのテスト環境を使ってもう一度「aniki」システムのテストを行おうと
準備し始めたのですが・・・
えーと、Love Affairスレでむむむさんから問題が出題されているなあ。
夏休み前なんだけど『むむむゼミナール』、もう始まっちゃったのか・・・
えーと、他にも色々作業があるので、後ほど日記更新しますね。
それでは、また
[追記 16:00]
今A-Tigerを3台(3510、3511、3512)再インストールしています。で、このうちtiger3512が
戻ってきたら、('A`)の方でもう一度各セットアップのステップを実行して、問題が
どの時点で再発するか、確かめてみます。
で、一方「むむむゼミナール」からの問題に対する回答を作成中です。
えーと、出題されていた問題は以下の４つです。
(問1)
>>809 の --preempt 指定は、どういう意味でしょうか。
(問2)
わざわざ外部コマンドで ifconfig を実行しているのに、ucarp で＊も＊
--addr=206.223.150.14 のようになぜ、指定する必要があるのでしょうか。
(問3)
--shutdown はなぜ指定する必要があるのでしょうか。
(問4)
ucarp 環境下において、絶対に起こってはならない致命的な状況は何か
|
で、以前第１８日目の日記でucarpの各パラメタについて簡単な説明を書いたので
それを基に('A`)なりの回答を書いてみようかな、と。
目指せ、脱ゼロ点！(目標、低過ぎ・・・orz)
まず問１について。
パラメタ --preempt ですが、「自分がバックアップとして稼働し、相手(マスタ)が
ダウンした時に、すぐに自分がマスタとして動く」事を示しています。
そう書いたのですが、ucarpのREADMEを見ると、こんな説明が書かれています。
(すごく間違っているかもしれませんが・・・、('A`)の方で訳してみます。)
Please note that by default, and if everything's ok, a master will stay a
master as long as possible. If you want a "preferred" master to immediately
become a master even if another host is already the master:
- add the --preempt (or -P) switch to *all* hosts
- use a lower skew or a lower base for the "preferred" one.
---------------------------------------------------------------------
デフォルト値に注意して下さい。そして全て正常に動いているならなら、マスタは
できるだけ<長い間マスタのままでいられるでしょう。
貴方が「都合のよい」マスタがすぐに欲しいなら、もう一方のホスト(サーバ)が既に
マスタとなっていたとしても、(そのサーバを)マスタにする事ができます。
--preemtp (または -P)を加える事で、全てのソフトを切り替えます
少ない時間差で「都合のよい」マスタを使用できます
---------------------------------------------------------------------
えーと、たぶん求められている日本語としては「死活監視」という言葉なんだと思います。
('A`)も詳しい方ではないのですが、相互監視サービスでは「サービスやネットワーク」が稼働を
しているかをチェックして、もしマスタ(メイン)が正常に稼働していない場合(例えばサーバが
重くて応答が極端に遅い、とか、サーバ自体がハングアップしている、とか)に、「代役」の
サーバに対して「主役」になる様に指示を出し、切り替えを行わせます。
で、前回はあまり触れていなかったのですが、ucarpのパラメタの１つに「advskew=128」
というのを指定しています。(バックアップとして動くサーバ側に明示的に設定しています)
明示的に値を書いていない場合は「advskew=0」となります。
これは「死活監視への応答時間」を示していて、1/256秒を掛けた値だけ遅延する様に
なっています。
で、最初に応答したホスト(サーバ)がマスタとしてサービスを提供します。
つまり「advskew=0」は「即答」するサーバ(すなわちマスタ)を意味します。
んで、advskew=128は「(128 x 1) / 256 = 0.5秒」を応答時間としています。
もしマスタがダウンしていたとした場合、監視システムでは監視対象となるサーバからの
応答結果を元に、応答があったサーバの設定をみます。もし「--preempt」という指定が
あったら、それは「監督、ウォームアップはできてます。いつでもＯＫです。」という
リリーフ投手のような存在なので、「よしっ、じゃあおまえ行ってこい！」となる訳です。
ただ、仮にマスタが復活してサービス提供可能状態になった場合には、即座に「主役」から
「代役」に戻されて、またブルペンでの投げ込みを続ける人生を歩む事になります。
(また、訳が判らん「たとえ話」を出してしまったかもしれませんね。すんません・・・)
えーと、気を取り直して、問２について。
--addr=206.223.150.14 と指定しているのは、このIPがucarpというシステムで動いている
サーバ達(まあ、マスタとバックアップですが)が使用する共通のIP(仮想IP)を示しています。
で、ifconfigコマンドで指定しているのは「物理的に」該当のIPをサーバで使用できる様に
割り当てているだけです。
もしマスタがダウンしてバックアップがマスタの「代役」を務める必要が出てきた場合は
まず物理的にIPアドレスが使用できる様にifconfigコマンドでNICに対してIPを追加します。
そしてucarpシステムでは共通のIP(仮想IP)で「追加したIPがシステム全体でサービスの
提供で使用している共通のIPアドレス」である事を認識します。
続いて、問３について。
READMEの --shutdown の項目に関する説明を見てみると、こんな事が書いています。
--shutdown (-z) will run the downscript at exit, unless ucarp is already in
the backup state.
---------------------------------------------------------------------
shutdownパラメタ(-z)はucarpが既にバックアップ状態でない限り
終了時にdownscriptを実行する
---------------------------------------------------------------------
つまりバックアップ状態で無い時とはマスタ状態の事であり、マスタ状態の時には
ifconfigコマンドで共通IP(仮想IP)が物理的にNICに割り当てられています。
で、ucarpを終了する時には、ifconfigで物理的にNICから共通IPを開放しない限り
残ってしまうので、終了時にdownscript(このスクリプトの中でifconfigコマンドで
NICからIPを開放している)を動かす様に指定しているから、と思うのですが。。。
(だんだん自信が無くなってきた。。。)
そして、最後の問４について。
> ucarp 環境下において、絶対に起こってはならない致命的な状況は何か
えーと、('A`)なりに考えてみましたが、、、これでいいのかなあ？
「マスタ・バックアップ共に共通IPを物理的に(NIC上で)有効になっている状況」に
なると、「どっちのIPが本当のIPなの？」となるので、避けるべきだと思います。
ってか、２台のサーバで同じIPがメインのNIC上で有効化されていたら、競合が
発生して、どちらか一方のサーバが外部と接続できない状況になります。
これはIPだけじゃなくて、MACアドレスが２サーバで同じ値だったりすると同様に
外部と接続できなくなるんです、ハイ。
ふー、何とか回答を書いてみましたが、合っているかなあ・・・ちょっと不安
あ、A-TigerのOS再インストールが終わった。さてこれからセットアップです。
早いところ、問題解決しなきゃ・・・
[追記 18:20]
A-Tigerのtiger3512を再度セットアップし、動作を観察しています。
今回はDNSキャッシュサーバの内包は行わず、かつ/etc/resolv.conf に指定する
DNSキャッシュサーバはbanana1004・1006という比較的負荷の低いサーバを設定
して動かしています。どうかなあ・・・
で、引き続き残りの２台(3510、3511)もこの方法でセットアップしてみよう。
あ、先日ハード故障を発生したサーバの修理も終わったので、再インストール
要請出しておこう。
[追記 18:15]
A-Tigerのtiger3510、3511を再度セットアップし、tiger3512と合わせて動作を
観察しています。
今のところは順調に動いています。
で、これから最後の１台(tiger3509)のOS再インストールを要請し、セットアップを
おこなう予定です。(現在PIEに作業要請をする準備の真っ最中です。)
あ、そうだ。これらのサーバは最低12時間はこのまま稼働させ続けて、明日午前に
再度状況(接続不能になった形跡がないか)を確認する予定です。
OS再インストールを要請したら、ようやく「aniki」システムに取り掛かれるかな？
|
|
|
|
|