Red Hat Enterprise Linux LVSクラスタ処理では、アクティブルータと呼ばれる Linuxマシンを使用して、インターネットからの要求をサーバーのプールに送ります。これは、LVSクラスタを2種類の基本的なマシン分類で構成することにより、実現されています。 — LVSルータ(アクティブルータ1台とバックアップ用1台)と、 重要なサービスを提供するリアルサーバーのプール
アクティブルータは、クラスタ内で以下の2つの役割を果たします。
リアルサーバー間の負荷を調整します。
各リアルサーバー上のサービスの整合性を検査します。
バックアップルータの仕事は、アクティブルータを監視して、障害の発生時にはその役割を引き受けることです。
図9-1 は、2つの層で構成されている単純なLVSクラスタです。第1層は、2台のLVSルータ(1台はアクティブルータで、もう1台はバックアップルータ)です。各LVSルータには、2つのネットワークインターフェイスがあり、 1つはインターネットと、もう1つは私設ネットワークと接続し、2つのネットワーク間のトラフィックを調整します。この例では、アクティブルータはネットワークアドレス変換またはNAT(Network Address Translation) を使用してトラフィックをインターネットから第2層にある台数が可変のリアルサーバーに送り、 リアルサーバーが必要なサービスを提供しています。したがって、この例のリアルサーバーは、 専用の私設ネットワークセグメントに接続されており、すべてのパブリックトラフィックを アクティブ LVS ルータ経由でやり取りします。 外部に対しては、サーバークラスタは1つのエンティティと見なされます。
LVS クラスタに到着したサービス要求は、仮想IPアドレス または VIP (Virtual IP)宛に送られます。 VIPはサイトの管理者が完全修飾ドメイン名と関連付けた公開アドレス(例、www.example.com)であり、1台以上の仮想サーバーが割り当てられています。 [1] 重要なことは、フェイルオーバー中にVIPアドレスがLVSルータから他に移植されるので、 浮動IPアドレスとも呼ばれる、そのIPアドレスの存在が維持されるということです。
VIPアドレスはLVSルータをインターネットに接続するのと同じデバイスにエイリアスを 設定することができます。たとえば、eh0がインターネットに接続されている場合、複数の仮想サーバーにeth0:1という別名を設定することができます。代わりに、各仮想サーバーをサービスごとに別のデバイスと関連付けることもできます。たとえば、HTTPトラフィックをeth0:1で処理し、FTPトラフィックをeth0:2で処理することができます。
同時にアクティブになるLVSルータは1台だけです。アクティブルータの役割は、仮想IPアドレスからのサービス要求をリアルサーバーに送ることです。この振り分けは、項9.3 で説明する8つの負荷分散アルゴリズムのうち、1つに基づいて行われます。
また、アクティブルータは、リアルサーバー上の特定のサービスの稼働状況全体を、簡単なsend/expectスクリプトを使って動的に監視します。HTTPSやSSLなど動的データを必要とする簡潔な稼働状況による、リアルサーバー上の特定のサービスの検出を支援するため、管理者は外部実行形式ファイルを呼び出すこともできます。リアルサーバー上のサービスに障害が発生した場合、アクティブルータはそのサーバーに対するジョブの送信を、そのサーバーが通常の稼働状態に戻るまで停止します。
バックアップルータは、スタンバイシステムの役割を果たしています。 定期的に、LVSルータはハートビートメッセージをプライマリの外部公衆インターフェイス経由でやり取りし、フェルオーバー状況が発生した場合には、私設インターフェイスとやり取りします。バックアップノードは、予想期間内にハートビートメッセージを受信できなかった場合、フェイルオーバーを初期化して、アクティブルータの役割を引き受けます。フェイルオーバー処理時に、バックアップルータは障害の発生したルータがサービスを提供していたVIPアドレスを、ARPスプーフィングというテクニックを使って引き継ぎます。ここで、バックアップ LVS ルータは、障害の発生したノード宛のIPパケットの宛先として、そのルータ自体を公開します。障害が発生したノードがアクティブサービスに復帰すると、バックアップノードはホットバックアップロールに戻ります。
図9-1 で使用した単純な2層の構成は、静的Webページなどデータのやり取りがあまり行われないクラスタに最適です。 個別のリアルサーバーがノード間のデータの同期(sync)を自動的に行わないからです。
LVSクラスタ処理には、リアルサーバー間で同じデータを共用するための、組み込みコンポーネントはないので、管理者には2つの選択肢があります。
リアルサーバープール全体でデータを同期させる
共有データアクセス用の第3層をトポロジに追加する
1番目の選択肢は、多数のユーザにリアルサーバー上のデータのアップロードや変更を許可していないサーバーに適しています。eコマースWebサイトなど、クラスタで多数のユーザにデータの変更を許可している場合は、第3層の追加が適しています。
リアルサーバーのプール全体でデータを同期させるために、管理者が採ることができる方法は多数あります。たとえば、Webエンジニアがページを更新した場合に、ページをすべてのサーバーに同時に送るシェルスクリプトを利用することができます。また、rsyncなどのプログラムを使って、設定期間内に変更されたデータをすべてのノードにクラスタ管理者が複製することもできます。
ただし、この種のデータの同期は、ユーザによるファイルのアップロードやデータベーストランザクションの実行が常に行なわれることによってクラスタがオーバーロードする場合には、 うまく機能しません。負荷の高いクラスタの場合の解決策としては、3層トポロジが最適です。
[1] | 仮想サーバーは、特定の仮想IP上で、サービスをリッスン(listen)するよう設定されているサービスです。Piranha 設定ツールによる仮想サーバーの設定に関する詳細は、項12.6を参照してください。 |