KEIS BLOGは株式会社ケイズ・ソフトウェアが運営しています。

KEIS BLOG

サーバの冗長化について②


こんにちは!丑三つ時にカップラーメンを啜りながらブログを書いております。
中薗と申します_(:3」∠)_
やはり深夜に食べるカッ〇ヌードルしょうゆ味は最高ですね!
最近お腹周りに肉がついてきたような気がするのですがきっと気のせいです。

 

さて、前回は「冗長化」という手法についてご説明させていただきました。
サービスをいつ、いかなるときでも安定して稼働させるためには、
無くてはならない手法と言えます。

それでは、サーバの冗長化には、具体的にどのような方法があるのでしょうか?
今回はそれを書いていきたいと思います。
○コールドスタンバイ

image1

これは、普段は予備機を使わずにおき、現用機が故障した場合にのみ
ネットワーク機器を予備機に繋ぎ直すことで、システムのダウンタイムを
短くする運用方針です。
ただし、このような運用方針だと、たとえばWebサーバがダウンした場合には

①予備機の電源を入れる
②予備機の各種設定を行う
③予備機をネットワークに接続する

というオペレーションを手作業で行わなければいけないため、
結局復旧までに時間がかかってしまいます。

この運用方針は、ある程度のサービス停止が許容されるような
「社内や組織内でのみ使用されているシステム」などに用いられることが多いです。

 

○ホットスタンバイ

image2

コールドスタンバイの欠点である「復旧までにかかる時間の長さ」を解消するために、
「予備機にも常に電源を入れておいて常にネットワークに接続しておけば、
切り替えがスムーズに行えるし、ダウンタイムを短く出来るのではないだろうか」
という発想が出てきます。

それを実現したものが、「ホットスタンバイ」という運用方針になります。
ホットスタンバイでは、現用機と予備機の両方に対して、
「現在このマシンが問題無く稼働しているかどうか」をチェックする処理を
数秒おきに流します。

チェックで不正な値が返ってきた場合には、
そのサーバはサービスを提供できない状態になっていると判断し、
自動的に別のサーバに仕事をバトンタッチするのです。

こうすることで、システムのダウンタイムはものの数秒程度に抑えられることになります。
しかし、理想的な運用方針に見えるホットスタンバイにも欠点はあります。

それは、
「あるサーバが仕事をしている時には、もう一方のサーバは仕事をせずに遊んでいる」
ということです。

上記の例だと、本当はサーバが2台とも同時に仕事をすれば倍の仕事が出来るはずなのに、
片方のサーバはあくまで予備機としてしか使われていないため、
サーバ資源の無駄が発生しています。
となれば、どうにかして2台を同時に稼働させることで
サーバ資源をフルに使えるようにしたいと思うのが当然のことです。

そこで登場してくるのが、「ロードバランサ」と呼ばれる機器です。
次回からは、このロードバランサの役割について述べていきたいと思います。

 

【関連記事】
サーバの冗長化について①