| ■ 【ぷろじぇくと ぞうさん】 〜E-Bananaサーバ 構築日記〜
|
第７１日目：【雪だるま】anikiようやく動きました。次はIPv6・・・
|
どうも、('A`)です。
長い間日記が更新されなくてゴメンなさい。
いやあ、先週に(^_^;)さんによってテスト環境という退路を断たれてしまったので
「本番環境」しかない状況の中、あーだこーだ色々といじってました・・・
途中cサーバに繋がらなくなるというアクシデントを何回も起こしてしまいましたが、
まあ、ようやく先週木曜日に形になりました。
退路が無いという事は、何かまずいところがあれば白日の下に即晒される訳で、、、
しかも「元の状態」に以下に戻せるかを常に考えないといけない訳で、、、
まあ、いくらテスト環境という「退路」があっても、本番環境と齟齬を起こしたら
全く意味が無いのですから、むしろ環境がひとつしか無いというのは、それはそれで
作業とか思考とかはすっきりします。(でも、プレッシャーは半端じゃなかったですよ。)
第６８日目の日記でも書きましたが、ロードバランサー部分(matd)と相互監視部分(ucarp)は
連動して動くところまで確認しましたが、自動切り離し・組み込みの機能を司る「aniki」が
ちゃんと動かなくて困っていました。
で、色々と見てみたら・・・出るわ出るわ、バグというか、間違いが。
えーと、こんなところです。
・対象サーバリスト(server.list)の記述で各項目をタブで区切らないといけないのに、
スペースで区切っていた。(その為、Perlで書かれているanikiスクリプトで項目を
正しく認識できなかった。)
・anikiスクリプトを動かすシェルスクリプトのパーミッションが700ではなく、644に
なっていた。(その為、シェルが動かない状態だった。)
・matdとの連動はうまく動く様になったが、ucarpでのマスタ&バックアップの切り替え時に
設定の雛型ファイルが無くて、設定ファイル(matd.cf)が誤った内容になった。
・フロントサーバが全台ダウンした時の想定をしていなかった。。。
で、一つ一つ対応して、最終的には新しいanikiシステム(「aniki改」)となりました。
「aniki改」について、次に説明します。
1) 「aniki改」ではmatdで使われる設定ファイルを全て管理用アカウント(aniki)の
ctrlディレクトリに設置しています。
(1)matd.cf 本体 (matd.cf)
所有者権限はrootで、パーミッションは644
(2)matd.cf マスター (matd.cf.master)
所有者権限はanikiで、パーミッションは666
2) ucarpでマスタ・バックアップ切り替え処理の際に参照するmatd設定の雛型を
ctrlディレクトリに設置します。
(3)matd.cf 雛型 (matd.cf.skel)
所有者権限はanikiで、パーミッションは666
(4)matd.cf マスター雛型 (matd.cf.master.skel)
所有者権限はanikiで、パーミッションは666
3) ucarp起動時に実行される２つのスクリプトを/usr/local/etc 内に設置します。
(5)matd起動用スクリプト (zzz-matd-up.sh)
所有者権限はrootで、パーミッションは755
(6)matd停止用スクリプト (zzz-matd-down.sh)
所有者権限はrootで、パーミッションは755
えーと、以前のanikiとどこが変わったかと言いますと・・・(4)のmatd.cf マスター雛型という
ファイルを新たに設けた事です。
このファイルは 3)のucarp起動時に雛型となるファイルです。
スクリプト部分でIP部分が書き換えられるので、IPのみ変更され、フロントサーバの定義
(targets= の部分)は対象サーバが全台記述されています。
ucarp部分での制御は「マスタ・バックアップ」の切り替えをシェルスクリプトで実行してます。
そこでは「IP部分だけ書き換える」処理をしているので、フロントサーバの定義変更が
できません。
一方anikiスクリプトでは「フロントサーバの定義だけ書き換える」処理をしています。
IP部分は「既に適切な値がセットされている」事が前提となっています。
そうすると、どうしても今まで用意していたmatd.cfの雛型ではうまく設定が書き換える
事ができないのが実際の運用テストで判明した為、急きょ雛型ファイルを2つにしたのです。
とにもかくにも、現在 c.2ch.net は自動切り離し・組み込み機能がついたロードバランサーで
運用が開始されました。
考えてみると、何か月もかかってしまったのですが、本来だと段取り良く作業を進めていたら、
１か月位で完成したんだと思います。。。
完成後に社内で「反省会」(これはサーバ復旧とか様々な作業を実施した後で通常行なっています。
まあ「あの時こうすれば良かった」、「作業手順のこことここが良くなかった」、「今度同じ事が
発生すれば、こうすればもっと良くなる」など、反省と改善について話し合いをしています。
有名な某自動車メーカーを真似ている訳ではないのですが、「カイゼン」というやつです、ハイ。
で、その時に議論になったのが
・ある開発テーマが出た時に、どの程度の作業ボリュームとそこから得られる効果の
ボリュームを正しく見積もれて、全体の作業を進められるか？
という事でした。
えーと、、、「いきなり訳のわからない図を出して・・・」と言わないで下さいね。
この図ではこんな事を表しています。
・枠に囲まれた内容‥‥サーバシステムの状態(段階)
・矢印の長さ‥‥導入によって得られる効果の期待値
・矢印の太さ‥‥導入の為に必要な開発・作業量
ロードバランサーの仕組みを「どの段階で本番環境に仕組みを導入すべき」だったのか？
(システムエンジニアの人が考えると、すぐに答えが判ってしまうのでしょうが・・・)
cサーバに対して今回('A`)は 5) ができる様になった段階で本番環境に導入という手順を
踏みました。
が、この図を見る限りでは 3) の段階で本番環境に導入した方が効果(接続の快適さ)が
より早く享受できたと思います。
当時のcサーバの状況は 2) の段階まで進んでいたのですが、DNSラウンドロビンを導入しても
時々「重いよ〜」「接続しづらいよ〜」という声が上がっていました。
その状況を改善し、かつ効果が実感できるのは必ずしも 5)まで待たなくても良い訳です。
3) ロードバランサー (matd)ができる様になった時にすぐに導入すべきだったのです。
で、matdに関する開発というか作業はテスト環境下では4月上旬に「既に動く状態」まで
到達していたのです。。。(第22日目の日記を見て頂くと判ります。)
作業ボリュームもそれほどでなかった(今となってはそう思えます・・・)し、それで得られる
効果を考えると、ね。
「でも 3) の状態で導入して、 4)のucarpとかの導入の時に稼働しているサーバを
落としたりできるの？」という疑問も出てくるかもしれません。
そういう時は「新しく環境を作って、お引っ越し」すれば良い訳で・・・
じゃあ、「何で今回はできなかったの？」と言うと・・・正しく見積もれていない(把握
できていなかった)からです。
今回「ロードバランサーを作れ！」というテーマが挙がった時に当初考えていた事は
「実際「雪だるま」として稼働しているものがあるから、まずはそれに倣って同じものを
作って、後から機能を付けたそう」と考えたからです。
そして「機能が全部できてから、本番に導入」という流れで作業が進められ、かつ実際には
作業の順番も 3) -> 5) -> 4) という「迷走」を続けていました。
でも、後から考えると、、、効果が得られるものから順に投入していった方が
「みんなが早くハッピーになれた」のは明らかです。
今回結果的に
・('A`)は「システムエンジニア」としての思考が無い状態で作業していた事が判った
・で、どういう思考で全体を考えて作業すれば、もっとうまくいくのかが判った
というのが「最大の成果」でしょう・・・
そういう意味で「矢印の図」が書ける様になりました。
(今回は('A`)矢印で表しましたが、自分が判り易い例えで考えると良いと思います。
例えば各開発テーマをマンションとかビルに見立てて、「ここまでくれば何階建てに
なるよー」、と考えても良いのです。)
文章力があまりないので、うまく皆さんに伝わっているかどうか・・・
まあ、これで「ロードバランサー」については一時休憩(というか凍結)となります。
これからは本番環境の稼働状況を観察して、問題点や改良点の洗い出しとかをする事に
なります。
と、ここまで日記を書いているとroot弟(´･ω･`)が「('A`)、PIEのコアルータ
(Force10)の工事が終わったよ」と知らせてくれました。
そうです。PIEのコアルータが「IPv6に対応できる」状態となったのです。
(PIEの方の説明ではCAM(Content Addressable Memory：高速検索用のメモリ)の
プロファイル(設定の１つ)を修正した、との事。でも勉強不足なので、詳しい
意味がよく判っていなかったりします・・・)
今月になってからスレ上でも「IPv6」という言葉が飛び交っています。
で、今回root弟(´･ω･`)が頑張って「IPv6対応」というテーマに取り組んでいます。
(あ、もちろん('A`)も加わっていますが、今までロードバランサーの方に集中して
いたので、ようやく参戦、という状況です。。。)
で、IPv6を使える様にする為には、以下の3つができている事が条件となります。
1) サーバがIPv6で通信できる様になっているか(設定されているか)
2) スイッチ等の通信機器がIPv6で通信できる様になっているか(設定されているか)
3) 通信回線(プロバイダとか)がIPv6で通信できる様にルーティングされているか
で、今朝(日本時間でいうと午前6時から午前7時50分)にPIEのコアルータに対しての
工事が実施され、PIEのスイッチ群はIPv6で通信できる環境となりました。
つまり 2)が終わった訳です。
root弟(´･ω･`)と('A`)の方では現在 1)(サーバ側の設定の確立)を実施中です。
(厳しい道のりですが・・・)
2人ともIPv6のお勉強をしつつ、会社にあるサーバと回線を使って試しに環境を
作っている処です。
えーとIPv6の回線はroot兄(・∀・)がOCNに掛け合って、引いてくれていました。
(本当は別の用途で使う予定だったけどね・・・)
じゃあ 1) ができればIPv6が完全に利用できるかというと、もう１つ必要でして。
3) の回線(プロバイダ)がIPv6対応でないと、ちゃんとアクセスができないです。
この点については、引き続きDavid社長以下PIEのメンバーが交渉・対応中です。
えーと、本当なら「IPv6って何なの？」とか「IPv6だとどうなるの？」とかお話が
できると良いのですが、、、先ほどお話しした通り、('A`)もこれから勉強という
状況ですので、もう少し待ってて下さいね。
それでは、また。
|
|
|
|
|
70日目に戻る。 72日目に続く。
解析
|