負荷分散システム運用のコツ

出典: KLablabWiki


タイトル 
負荷分散システム運用のコツ
著者名  
KLab(株) ひろせ まさあき HIROSE Masaaki
KLab(株) 安井 真伸 YASUI Masanobu
KLab(株) 勝見 祐己 KATSUMI Yuki
初出 
技術評論社刊『WEB+DB PRESS Vol.37』

目次

はじめに

　この章ではロードバランサそのものからはちょっと離れて、筆者らが手がけている負荷分散システムで実践している運用の工夫やコツをいくつか紹介したいと思います。

　文中で『DSAS』という言葉が出てきますが、これは筆者らが設計・構築・運用しているコンテンツサービス用のネットワーク・サーバインフラの名称です。『DSAS』については筆者らのブログなど[1]でも紹介していますが、その特徴のうちで、本誌の読者の方に興味を持ってもらえそうな点を列挙してみます。

  • ロードバランサやストレージサーバなども含めて、ほぼ全てLinuxベースで構築している。
  • 下まわり（物理配線など）からアプリケーションレイヤに至るまで、各所で多重化しているので障害に強い。
  • スケーラビリティも考慮して設計している。


　『DSAS』の構成についてはまた機会があれば詳しく紹介したいと思いますので、本章では日頃の運用に関するノウハウを、

  • 自動化
  • 省力化
  • ミスの減少

といった視点でいくつか紹介したいと思います。

MATRIXでサーバ集中管理

　特に分散環境において、サーバの台数が多くなってくると、

  • あのサイトのリアルサーバってどれとどれだっけ?
  • DBサーバってどれとどれだっけ?

と迷うことが、サーバ管理者、アプリケーション開発者共によくあると思います。

　また、このような情報は様々なユーティリティプログラム（例えばあるサイトのWebサーバだけを再起動するとか）でも必要になってきます。

　様々な局面で必要になるこういった情報をばらばらに管理すると、DRY原則[2]を持ち出すまでもなく、破綻するのは目に見えています。

　そこでDSASでは、MATRIX[3]と名付けた図1の様なテキスト形式のファイルで一元管理しています。

MATRIXのフォーマット

　図1を元に、MATRIXの形式を簡単にですが説明します。

　コロンの左側の「w101」や「w102」はサーバの物理名で、サーバごとに一意な名前を付与しています。

　コロンの右側がそのサーバの役割を表しています。まず、アルファベットで始まるものがサイトの名称です。図1では「usagi」と「kame」の2つのサイトがあることになり、w101はusagiサイトだけのリアルサーバ、w102はusagiとkameで相乗りしているリアルサーバとなります。

　サイトの他には角括弧と丸括弧のタグがあります。

　角括弧タグは機能割り当てを表現しています。[NANDEMOYA]はSMTPやsshの踏み台などになる、なんでもいろいろやっちゃうサーバです。[FREE]はロードバランサの分散対象にはなっていませんが、全てのサイトをデプロイしているサーバで、設定ファイルを変更したときなどに内部用の動作確認に使っています。

　丸括弧タグはネットワークブートのサーバなど、特殊なサーバを表現しています。lv1とlv2は外部ロードバランサ、ll1とll2は内部ロードバランサで、それぞれ1と2とで冗長構成になっています。また、dbXXXはDBサーバなのですが、(db101)には(db100)タグもついているのに気づいたでしょうか。(db100)のように末尾がゼロのDBタグは、浮動的に現在のマスタを示すタグとなっています。このあたりはのちほど触れたいと思います。

図1 MATRIX 
w101: usagi
w102: usagi kame
w103: [NANDEMOYA]
w104: kame
w105: kame
w106: (lv1)
w107: (lv2)
w108: (ll1)
w109: (ll2)
w110: (db101) (db100)
w111: (db102)
w112: [FREE] usagi kame

MATRIXの使い方

　さて、このMATRIXですが、このままのベタなテキスト形式では使いづらいので、各種言語用のライブラリを用意しています。そして、Webアプリケーションやユーティリティコマンドからはこれらのライブラリ関数経由でMATRIXを参照するようにしています。

　では、具体的にどのようなところでMATRIXを活用しているかを、いくつか紹介したいと思います。

シェル用の変数と関数とalias

　サーバを管理していると「全部のサーバにXXXしたい」とか「DBサーバだけにXXXしたい」ということがよくあるのですが、サーバの台数が多くなると、どれがどの役割のサーバだったかなんてことは覚えていられなくなります。

　そこでDSASでは、$ALL_SERVERSや$DB_SERVERSといったシェル変数を、MATRIXを元に定義するようにしています。さらに、リスト1のようなaliasも用意して、図2のように使えるようにしています。これらも含め、ユーティリティ的なシェル変数やシェル関数などは、/etc/dsas.confというファイルをsourceすれば全て使えるような構成にしています。


　また、シェル以外の言語、例えばPerl向けには、KLab::DSAS::MATRIXというモジュールを用意して同等のことができるようにしています。

リスト1 aliasの例 
alias  FORDB='for i in ${DB_SERVERS[@]};do '
alias FORALL='for i in ${SYNC_SERVERS[@]} ${TEST_SERVERS[@]};do '
図2 aliasの実行例 
$ FORALL echo -n "$i "; ssh $i uptime; done
w101  19:06:29 up 61 days,  6:04, 27 users,  load average: 0.58, 0.78, 0.82
w102  19:06:29 up 35 days,  6:10,  2 users,  load average: 0.12, 0.06, 0.03
w103  19:06:29 up 35 days,  6:55,  4 users,  load average: 0.10, 0.03, 0.01

あのサイトのリアルサーバは？

　「usagiサイトのリアルサーバはどれとどれだっけ？」とか「kameサイトの全てのリアルサーバを再起動したいな」といったことが多々あるのですが、前節と同様、覚えていられません。

　そこで、サイトごとのリアルサーバを意識しないで済むように、図3のようなファイルを用意しています。

　これらのファイルはまたほかの仕組みによって、自動的に最新の情報に更新されるようになっているので、図4のように、サイトとリアルサーバの関係を意識せずにオペレーションすることができるようになっています。

図3 サイトごとのリアルサーバ 
$ ls /var/lib/servers/assign/
kame  usagi

$ cat /var/lib/servers/assign/kame
ASSIGN_SERVERS=('w102' 'w104' 'w105')
図4 $ASSIGN_SERVERSの使用例 
$ source /var/lib/servers/assign/usagi
$ echo ${ASSIGN_SERVERS[@]}
w101 w102

# source /var/lib/servers/assign/kame
# for i in ${ASSIGN_SERVERS[@]}; do
> echo $i
> ssh $i "/etc/init.d/httpd restart"
> done

matrix-reflection

　MATRIXは一元管理システムの核なので、MATRIXを変更するといろいろなところにその変更を反映する必要があります。反映作業を個別に手作業で行うと、漏れやミスが発生する可能性が高いので大変危険です。

　この問題を解消すべく、一連の反映作業を一括して実行してくれるスクリプトを用意しています。このスクリプトには、「MATRIXを反映させる」の意で「matrix-reflection」[4]という名前をつけました。

　matrix-reflectionは「MATRIXを反映させる」ことに関していろいろな仕事を行っているのですが、そのいくつかを紹介します。

  • 浮動アドレスの管理
    MATRIXのフォーマットの説明のところで、DBサーバの中でマスタを示すものには、「(db100)」のように末尾がゼロのDBタグをつけると書きました。実はこのdb100という名前（とそのIPアドレス）はVIPのように浮動的にマスタに付与するものとしているのですが、その管理（浮動アドレスの付与と剥奪）も、MATRIXに基づいてmatrix-reflectionが行っています。この構成にしてよかったなと思うのは、マスタが故障してスレーブをマスタに昇格するときです。なぜなら、マスタに昇格するには、MATRIXを書き換えてmatrix-reflectionを実行するだけで、昇格作業がほぼ完了できるからです。
  • 設定ファイルの生成
    ApacheやTomcatなどの設定ファイル（httpd.confやserver.xml）を生成しています。どういうことかというと、まず、サイトごとに設定ファイルの断片を用意しておきます。この設定ファイル片には、当該サイトで必要になる設定だけを書いておきます。そしてmatrix-reflectionは、自分に割り当てられているサイトの設定ファイル片だけを合成して、完全な設定ファイルを生成します。このおかげで、不要なVirtualHostやデプロイをしなくて済む、無駄のない設定ファイルを動的に作ることができます。

keepalivedの運用テクニック

　keepalivedはIPVSの制御ができる上にVRRPまでサポートしている優れものですが、実サービスで安全に運用するためには少々工夫が必要です。

　これはkeepalivedがどうこう言う話ではなく、「すべてのニーズに適応できるソフトウエアは存在しない」というごく当たり前の話だったりします。

　この節では、keepalivedを使っていて使いにくいなあと感じた部分について、それをどのように改善していったかをご紹介したいと思います。

IPVS用とVRRP用に別々のkeepalivedを起動する

　たとえば、あるサービスのリアルサーバを増設したいとします。新しいサーバを設置したらkeepalived.confを書き換えて再起動すると思いますが、単に/etc/init.d/keepalived restartを実行するとVRRPの機能も再起動されてしまうのでMaster/Backupが切り替わってしまいます。VRRPの切り替わり自体はサービスに影響を与えるものではないですが、できれば不要な切り替えは避けたいところです。特に筆者らが管理しているシステム（DSAS）では、リアルサーバの追加や変更が比較的頻繁に発生するため、その度にVRRPが切り替わるのは嬉しいことではありません。

　keepalivedには--vrrp（VRRPの機能のみ利用する）と--check（ヘルスチェックとIPVSの制御機能のみ利用する）というオプションがあります。これらのオプションを使って、VRRP用とIPVS用のkeepalivedを別々に起動しておけば、VRRPには影響を与えずにIPVSの構成を変更することができるようになります。

　具体的にどのようにするかというと、/etc/init.d/keepalived[5]に少し手を加えます。オリジナルを直接書き換えるのは危険なので、まずは図5の手順でVRRP用とIPVS用のコピーを作ります。

　そして、図6と図7の通りに書き換えます。ここで注意しなければいけないのは10行目のNAMEの文字列です。「名前なんだからなんでもいいだろ」と思って適当につけないで下さいね。必ずこのように設定して下さい。こうしないと、stopの際に正しいPIDを取得できず、keepalivedを停止することができなくなってしまいます。

　書き換えが終わったら、図8のコマンドを実行して自動起動の設定をします。ここでは、オリジナルの/etc/init.d/keepalivedが実行されないようにし、その代わり新しく作ったvrrpとipvsが実行されるようにしています。

　これで、/etc/init.d/vrrp restartと/etc/init.d/ipvs restartが使えるようになりました。IPVSとVRRPがそれぞれ独立して、互いに影響を与えずに再起動することが可能になったわけです。

図5 起動スクリプトを別々にする 
# cp /etc/init.d/keepalived /etc/init.d/vrrp
# cp /etc/init.d/keepalived /etc/init.d/ipvs
図6 /etc/init.d/vrrpの変更内容 
10行目: "NAME=keepalived"                   -> "NAME=keepalived_vrrp"
21行目: "--exec $DAEMON"                    -> "--exec $DAEMON -- --vrrp"
41行目: "/var/run/$NAME.pid --exec $DAEMON" -> "/var/run/$NAME.pid --exec $DAEMON -- --vrrp"
図7 /etc/init.d/ipvsの変更内容 
10行目: "NAME=keepalived"                   -> "NAME=keepalived_checkers"
21行目: "--exec $DAEMON"                    -> "--exec $DAEMON -- --check"
41行目: "/var/run/$NAME.pid --exec $DAEMON" -> "/var/run/$NAME.pid --exec $DAEMON -- --check"
図8 自動起動設定 
# update-rc.d -f keepalived remove
# update-rc.d vrrp defaults 20
# update-rc.d ipvs defaults 20

設定ファイルのメンテナンスは結構大変

　現在のところkeepalivedの設定ファイルには、外部ファイルを取り込む機能がないため、すべての定義を一つのファイルに書かなければなりません。また、この設定ファイルはその性質上、似たようなブロックがずらずらといっぱい並ぶような構成になります。サイトが一つや二つであればまだ我慢もできますが、それ以上の規模になってくると非常に見通しが悪く、記述ミスも誘発しそうです。また、keepalivedには設定ファイルの文法チェック機能がないばかりか、記述ミスがあってもそれなりに起動してしまいます。これは、いい意味で解釈すれば「記述を間違っても無視して起動してくれる」ですが、悪い意味で解釈すれば「エラーチェックをしてくれない」です。正常に起動したと思っていたら、実は意図した通りに動いていなかった、みたいな事故が起こることは容易に想像できると思います。設定をコピペしたのはいいけど、どこか書き換えるのを忘れてしまって大変なことになることって、keepalivedに限らずとも結構あったりしますよね。

問題を解消して快適な運用を目指す

　keepalivedを運用するにあたって問題と思われる点をつらつらと書いてみましたが、これを見て「あぁ、これだと厳しいから使うのやめようかなあ」なんて思っていませんよね？

　「期待している機能が実装されるのをじっと待つ！」とか、「気力と根性で乗り切る！」という選択もありますが、ここはひとつ自分の使いやすいように運用できる仕組みを作ってみるのはいかがでしょう。keepalivedを試してみて筆者らが問題と感じたのは「設定ファイルの見通しが悪いこと」、「記述ミスを誘発しそうなこと」という2点でした。何を問題として捉えるかはニーズや環境によって様々だと思いますが、「すべての問題を解消したkeepalived相当のものを作る事」と「今のkeepalivedの問題を解消できるような運用体制や仕組みを作る事」では、ほとんどの場面において後者の方が圧倒的に楽なはずなんです。

見通しをよくするための工夫

　それではどのようにすれば設定ファイルの見通しが良くなるのでしょうか。

　いろいろ話し合った結果「設定ファイルはVSG（仮想サーバグループ）単位で別々にできればうれしい」という結論になりました。

　例えば、usagiというサイトの設定ファイルは/etc/keepalived/conf/usagiに、kameというサイトの設定ファイルは/etc/keepalived/conf/kameに記述するといった具合です。

　もしkeepalivedに外部ファイルを取り込む機能があれば、"Include conf/*"みたいな記述をkeepalived.confに書けば良さそうなものですが、残念ながら現時点ではそれができません。ないものは仕方がないので少し泥臭い事をします。とはいってもそんなに難しい事ではなく、/etc/init.d/ipvsに図9のような変更を加えるだけです。

図9 起動時に設定ファイルの断片を結合する仕掛け 
NAME=keepalived_checkers
DESC=keepalived
CONFIG=/etc/keepalived/keepalived.conf
cat /etc/keepalived/conf/* > $CONFIG    ←この行を追加

もっと運用を楽にしたい

　ここまでで、「設定ファイルの見通しの悪さ」は解消することができました。しかし、このままではconf/usagiにリアルサーバの定義を書かなければいけません。つまり、リアルサーバを増設したり変更したい場合に中身を書き換える必要があるわけです。これらのファイルを運用担当者が書き換えるのは精神衛生上あまりよろしくありません。記述ミス等で障害を引き起こしそうな要因はできるだけ排除したいものです。それでは「設定ファイルの記述ミス」をなくすためにはどうすればよいのでしょうか。

設定ファイルを動的に生成する

　前節で、MATRIXという共通の定義ファイルでサーバ割り当てを一元管理している例を紹介しましたが、keepalivedの設定ファイルもMATRIXを利用して動的に生成することができれば、運用はぐっと楽になるはずです。

　これを実現するため、まずは/etc/init.d/ipvsを図10のように変更します。さらにconf/usagiは設定ファイルの断片ではなく、図11のような結果を出力するスクリプトにします。このスクリプトはVSGに割り当てられているリアルサーバをMATRIXから取得し、real_serverブロックを動的に生成するものです。

図10 設定ファイルの動的生成 
NAME=keepalived_checkers
DESC=keepalived
CONFIG=/etc/keepalived/keepalived.conf
cd /etc/keepalived/conf/ && \
for i in *;do source $i;done > $CONFIG
図11 conf/usagiの実行結果 
$ source /etc/keepalived/conf/usagi
virtual_server_group usagi {
  10.0.0.100 80
}
virtual_server group usagi {
  delay_loop  3
  lvs_sched   wlc
  lvs_method  DR
  protocol    TCP
  virtualhost  health.example.org
  sorry_server 192.168.31.100 80
  real_server  192.168.31.101 80 { 
    weight 1
    inhibit_on_failure 
    HTTP_GET {
      url {
        path /health.html
        status_code 200
      }
      connect_timeout 3
    }
  }
  real_server  192.168.31.102 80 {
    weight 1
    inhibit_on_failure
    HTTP_GET {
      url {
        path /health.html
        status_code 200
      }
      connect_timeout 3
    }
  }
}

楽をするための苦労は惜しまない！

　「MATRIXを参照して動的に生成・・・」って簡単に言ってしまいましたが、実際にここまでの仕組みを作り込むのはそれなりに手間がかかります[6]。しかし、この仕組みさえできてしまえば、リアルサーバの追加や変更の手順は「MATRIXを書き換えて/etc/init.d/ipvs restartを実行するだけ」になります。その結果、運用フェーズにおいて手作業でkeepalivedの設定ファイルを編集する必要がなくなります。

　「keepalivedの設定ファイルはいじりたくないねぇ」という思いからこのような仕組みを考えてみましたが、「何も考えずに運用するために一生懸命考える」というのはなかなか楽しいものです。今回紹介させていただいた仕組みは、説明の都合上、著者らが運用しているシステム（DSAS）のものと若干異なりますが、構築をしていく流れというか考え方は一緒です。目の前にあるものをそのまま使うだけでなく、使いやすいように工夫をしてみることは、どのようなシステムにおいても有益なことと考えています。

SSH以外のリモートメンテナンス手段

　普段のマシンのメンテナンス作業は、SSHを使ってリモートから行いますが、トラブルが発生した場合は、SSHでログインできなくなることもあります。また、そもそもSSHログインするには、OSが起動していることが大前提です。

　この節では、OSは起動しているけれどもSSHでログインできない時や、そもそもOSが起動していない場合にも、リモートからメンテナンスするための仕組みを、2つ紹介します。

シリアルコンソール

　シリアルコンソールとは具体的に言うと、サーバに直接接続されたディスプレイとキーボードの代わりに、シリアルインタフェース[7]を通じて接続されたマシンを使って実現するコンソール、になります。つまり、そのマシンを通じて（普通のコンソールを使うのと概ね同じように）サーバの操作ができます[8]。

ログイン

　シリアルコンソールの活用例の1つは、ネットワーク接続できない時のための、サーバへのログイン手段です。シリアルコンソールは、ネットワークとは全く無関係です。ですので、ネットワークが不通の場合や、SSHのサーバが死んでしまってる場合でも、シリアルコンソールからはログインできます。

　トラブル時以外に威力を発揮するのが、ネットワークのフィルタリング設定やIPアドレスの変更など、ネットワーク接続が中断してしまう様なメンテナンスをする場合です。またSSHログインして設定を弄っていて、うっかり繋がらなくしてしまったときにも、慌てずに済みます。

BIOSにアクセス

　シリアルコンソールを通じて、マシンの起動時のBIOSのメッセージを見たり、BIOSの設定を変更することも可能です[9]。

　これが活躍するのは、例えば、前節で紹介したネットワークブートの利用例で、普段はハードディスクから起動しているマシンをネットワークブートで起動する際に、BIOSの起動デバイスを変更するのに使います。

ブートローダの制御

　シリアルコンソールを通じて、OSを起動するブートローダを制御することもできます[10]。

　最近のブートローダは、メニュー形式で起動するカーネルの種類や設定を選択できるようになっていますが、このメニューにも、シリアルコンソールを通じてアクセスできます。ネットワークブートする際に、ブートするシステムの種類等を選択することがありますが、ここでもシリアルコンソールが活躍します。

IPMI

　トラブルが発生すると、シリアルコンソールからもログインできなくなることがあります。そのような状況に陥った場合、リモートからリセットボタンを押せればと、切に願うこともよくあります。そんな時の強い味方がIPMIです。

　IPMI（Intelligent Platform Management Interfaceの略）はIntel社などが規格化した、ハードウェアのための、リモートメンテナンスの仕組みの規格です。IPMIに対応したマシンには、ネットワークを経由して接続できます。このIPMIの接続は、ハードウェアによって処理されます。つまり、接続される側のOSの動作状態に依存せずに、リモート接続ができるのです。

　以下の話は、SuperMicroのサーバとIPMIカードを使った経験に基づくものです。他のメーカの場合、できることが少し変わるかもしれませんが、参考にはなると思います。

IPMIと電源制御

　IPMIを使えば、ネットワーク越しにマシンをハードウェアリセットしたり、電源をon/offしたりできます。

　IPMIが強力なのは、電源のonもできる点です。即ち、起動していないマシンでも、電源ケーブルが刺さっていればIPMIは使えるのです。これにより、例えば代替マシンを用意して設置だけ完全に済ませておけば、電源を入れておかなくても、必要な時に起動してサービスに投入することができるようになります。

IPMIとシリアルコンソール

　IPMIのインタフェースを通じて、シリアルコンソールを利用できます。シリアル接続によるシリアルコンソールとは違って、IPMIを経由するシリアルコンソールは、ネットワーク上のどのマシンからでも利用できます。但し、IPMIからシリアルコンソールが使えるからといって、シリアル接続のシリアルコンソールが要らなくなるかと言うと、そうではありません。IPMIはネットワークを経由して接続しますので、ネットワークトラブルには無力です。どちらかがあれば済むものではありません。相補的なものになります。


　IPMIとシリアルコンソールを使えば、電源の投入からサーバの起動、そしてログインまでが、あたかもマシンの前に座っているかのようにできます。これらが特に威力を発揮するのはトラブル発生時です。問題が起こったときに、その場で全ての作業を済ませられるのは、大変ありがたいものです。

ネットワークブート

　筆者らの環境（DSAS）では、幾つかのシステムはネットワークブートしています。

　ネットワークブートとは、OSを起動するのに必要なブートローダ[11]やカーネル等を、ネットワーク上の別のマシンから取得して、起動することを言います。

ネットワークブートの利点

　ネットワークブートを使うのは、次の様な理由からです。

  • OSのインストールが不要
    ネットワークブートする場合、ブートする度に起動するシステムのためのカーネルを取得するので、OSのインストール作業が必要なくなります。そのため、ネットワークブートするシステムは、マシンに縛られにくくなります。
  • マシンの交換が容易
    重要なシステムを担っているマシンが壊れた場合、代わりのマシンを使って復旧することはよくあります。そのような場合にOSのインストールから始めていたのでは、復旧するのに時間がかかってしまいます。ネットワークブートを使っていれば、OSのインストール作業は不要になるので、すぐに復旧できます。またIPMI（後の節で出てきます）と組み合わすと、この作業が遠隔からできてしまいます。すなわちシステムの復旧作業が、サーバの設置場所に行かずとも、できてしまいます[12]。

ネットワークブートの利用例

LVS

　ロードバランサには、当然ですがLVSを使っています。これは全てのサービスの要なので、万が一壊れた場合は直ぐにでも代わりのマシンを投入しなければなりません。こんな場合DSASでは、Webサービス用のリアルサーバを1台選んでネットワークブートし、代わりマシンとして使います[13]。

　こんな運用方法がとれるのは、実は、リアルサーバとLVS用のマシンは全く同じものを使っている上に、ネットワークの物理的な接続も全く同じになっているからです（これもDSASの大な特徴なのですが、この話は、また機会を改めてできればと思います）。

　そんなわけで、LVS用のマシンが故障しても慌てる必要はありません。リアルサーバの中から1台を選び出してリブートし、LVSシステムとしてネットワークブートするだけ、復旧できます。OSのインストール作業が要らないので、たったこれだけです。もちろん、この作業もリモートから済ませられます。

DBサーバとファイルサーバ

　ロードバランサ以外の重要なシステムとして、ファイルサーバとDBサーバがあります。これらは両方とも、壊れないディスク領域が必要になります。ですので、これらのシステム用に使うマシンには、3台のハードディスクをRAID1構成（1台はホットスペアディスク）にしたものを搭載しています。

　ハードディスクはRAID構成にしたとしても、それ以外の部品が壊れることもあります。そんな場合に備えて、代替マシンを用意しておかなければなりません。けれども、普段は使わない代替マシンを、DBサーバ用とファイルサーバ用にそれぞれ用意しておくのももったいない話です。折角マシン自体は同じ構成のものを使っているので、それぞれのシステムのための代替サーバを、まとめて1台でまかないたいところです。

　ここで、ネットワークブートの出番です。

　DBサーバ用のシステムも、ファイルサーバ用のシステムも、ネットワークブートで起動できるようにしてしまいます。そうすれば、事前にOSをインストールしておかなくても、代替マシンが1台あれば、DBサーバ用としてもファイルサーバ用としても、必要なときに直ぐに起動できます。


　重要なシステムは、壊れた際には直ぐに復旧させなければなりません。ネットワークブートを使えば、素早く代わりのマシンを立ち上げられます。イライラしながらインストール作業する必要は、全くありません。他にも、今回紹介した様なミッションクリティカルなシステムだけでなく、OSのインストール作業用（!）や、メモリテスト用などのシステムもネットワークブートできるようにして、便利に使っています。

脚註

  1. ↑ http://dsas.blog.klab.org/ , http://www.klab.org/dsas/
  2. ↑ Don't Repeat Yourselfの略。 重複を排除することにより、変化に強く、保守性も高いシステムにすること。
  3. ↑ 『MATRIX』という名前は、サーバ名と個々のサーバに割り当てられる役割情報が、まるで行列のように並んでいるところに由来します。20世紀末期に北米で発生した仮想世界と現実世界を舞台とした救世主伝説とはなんら関係ありません。
  4. ↑ matrix-reloadedという名前も候補にあがったですが採用されませんでした。
  5. ↑ ここではDebianのkeepalivedパッケージ付属の起動スクリプトをベースにしています。
  6. ↑ 処理が少々複雑になるため、今回は/etc/keepalived/conf/usagiの詳細については割愛させて下さい。
  7. ↑ 世の中には色々なシリアルインタフェースがありますが、シリアルコンソールに使われるのは、主にRS-232Cと呼ばれるインタフェースです。
  8. ↑ シリアルコンソールに関する具体的な設定方法などは、Linux Document Project（LDP）の「Remote Serial Console HOWTO」を参考にしてください。 オリジナルはhttp://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/ に、JFプロジェクトによる日本語訳はhttp://www.linux.or.jp/JF/JFdocs/Remote-Serial-Console-HOWTO/ にあります。
  9. ↑ BIOSがコンソールリダイレクションをサポートしている必要があります。
  10. ↑ ブートローダの対応が必要ですが、liloやGRUB、SYSLINUXといったよく使われるものは皆対応しています。
  11. ↑ OS（カーネル）を起動するための、ちっちゃなプログラムのことです。
  12. ↑ もちろん、壊れたマシンを修理する必要はありますが、システムとしての復旧作業は、遠隔から済ませられます。
  13. ↑ リアルサーバは一杯ありますから、少しの間でしたら1台くらい少なくても何とかなります。
"http://lab.klab.org/wiki/%E8%B2%A0%E8%8D%B7%E5%88%86%E6%95%A3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%81%8B%E7%94%A8%E3%81%AE%E3%82%B3%E3%83%84" より作成
■このサイトについて

このサイトはKLab株式会社が開発したソフトウェアやノウハウ、実験的なサービスを公開していきます。

 RSS Feed

■メニュー