- - PR -
WEBサーバーの冗長化
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2005-01-17 23:21
お世話になります。
WEBサーバーを冗長化しようと考えています。 現在稼動しているWEBサーバーと予備として準備しているWEBサーバーは、 設置場所、ネットワークが全く異っています。 現在稼動しているサーバーが停止した場合に、 クライアント側でURIを変更せずに予備のサーバーにアクセスが向かうようにしたいのですが、 こういった場合、どの様にDNSの設定をすれば良いのでしょうか? とりあえず、Aレコードに2台分のIPを登録したところ、 アクセスが2台に分散されてしまいました。 よい方法を御存じの方、ご教示下さい。宣しくお願いいたします。 | ||||
|
投稿日時: 2005-01-18 12:21
こんにちは。
DNSでは、ご希望の動作は無理かと思います。 DNSラウンドロビンでは、あくまでIPの振り分けしか行いません。 ヘルスチェック等を行い冗長化したい場合は、ロードバランサの 導入が必要ではないでしょうか。 | ||||
|
投稿日時: 2005-01-18 12:35
本サーバを定期的に監視しつづけ、本サーバに障害が起こった時にクーロン等で待機サーバの方へアクセスされるようにDNSの設定ファイルを更新する。
強引にこのようにしたとしても、最大TTLで設定した秒数は本サーバの方へ行ってしまうので現実問題として役に立たないでしょう。 かといって、TTLを5秒とかいうように極端に短い時間に設定するとアクセスのたびにDNS参照が起こり、DNSサーバの負荷が大きくなったりクライアントから見たレスポンスの低下が起こったりしうるので、これも現実的ではないでしょう。しかも、TTLを5秒にしたところで全てのDNSがそれに従ってくれる保証はどこにもないですからね。 | ||||
|
投稿日時: 2005-01-18 21:12
DNS Server に何をお使いかわかりませんが， bind であれば www.host.net 60 IN A a.a.a.a www.host.net 60 IN A b.b.b.b www.host.net 60 IN A c.c.c.c として， rrset-order { class IN type A name "www.host.net" order fixed; order cyclic; }; とすると，www.host.net だけは順番に， 他は cyclic に A record を介してくれると思います． default では cyclic だったと思いますが， これがいわゆる「ラウンドロビン」だったと記憶しているので， fixed だと「最初から順番」になるのではないかと． 試そうと思ってまた検証していませんでした． 間違っていたらゴメンナサイ． | ||||
|
投稿日時: 2005-01-18 21:49
そう言えば、そのようなオプションありましたね。 私も試したことはありませんが。 でも、アプリケーションレベルの停止まで考慮すると、結局ニックさんが述べられているようにロードバランサーを導入するしかないように思います。 | ||||
|
投稿日時: 2005-01-18 23:24
ご尤も． bind の機能を使っても所詮「振り分け」しか出来ませんね． ニック様言及の「ヘルスチェック」はつまり， 「負荷を分散する目的のサービスがちゃんと聴いてくれているか確認する」 ことをしてくれる機能です -> 純一郎様 負荷を分散するだけなら bind の機能で実現できるかもしれませんが， 例えば稼動系の host の http service だけが堕ちてしまっている場合， 負荷分散装置は稼動系が生きていても 待機系に http service の接続要求を回送してくれます． というわけで，「稼動系を保守する際に network から切り離すので待機系を」 という程度の話であればともかく，負荷分散装置を入れないと 真の冗長化とは言い難いというお話です． 以上，ご参考までに． | ||||
|
投稿日時: 2005-01-18 23:43
そもそも、何かの仕組みで振り分け考える場合、
振り分け先の仕組みと振り分ける仕組みの障害発生率が同程度だと仮定すると、 振り分ける仕組み自体も冗長化が必要だったりするわけです。 別ネットワークって条件を考えると、DNSで振り分けるのが無難な気がするし、 死活監視とそれに応じたDNSゾーン情報の変更を行う仕組みであれば、 httpセッションを監視する仕組みと、cronあたりのスケジューラと、 それらを連携させるためのシェルスクリプトを組んでしまえば、 そこまで難しいことしないでも実現可能だとは思います。 また、障害発生頻度が低く見積もれて、かつ死活監視後の対応をすぐに 取れるのであれば、TTLを短くしたDNSサーバだけを準備して、 障害発生したら手動でゾーン情報変更、でも十分でしょう。 金と手間かけたくないのであれば、DNSラウンドロビンのみで実装するのが良いでしょうね。 常に両サーバにアクセスが来るのと、片方死んだ際に死んだ側のアクセス発生時のエラーは許容できれば。 最後は金と手間隙をどの程度かける価値があるシステム化、です。 | ||||
|
投稿日時: 2005-01-19 01:01
DNS負荷分散だと、HTTPパケット内に含まれるCookieを元に同一のHTTPセッションを 特定のWeb(AP)サーバに割り振る、というセッションパーシステンシーの機能が 使えないですよね。Webが静的なコンテンツだけでなく動的なコンテンツ、特に HTTPセッションを利用するものである場合、これが使えると使えないとでは大きな 差になると思います。通常、L/Bではこの様な機能が提供されます。 但し、APサーバ側でHTTPセッションのレプリケーションをすれば良い、という 逃げ方もあります。ただ、これにはWebLogicなどのWebコンテナの機能を利用するのが 一般的でしょうけれど、サービス系のネットワークでセッションデータの複製を 行うので、あまりやりたくない(サービス系のトラフィックに影響が出そう)ですね。 セッションに格納するオブジェクトが肥大化しないように、アプリの設計時にも考慮が 必要になります。 私の経験では、Webサーバ、APサーバの層は単純にL/Bによる負荷分散を行い(その際 HTTPセッションのパーシステンシーは考慮します)、セッションレプリケーションは しないことが多いです。逆に、DBサーバはクラスタ化して、ディスク共有型の冗長構成 にするのが普通です。 以上、ご参考までに | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。