17 負荷分散 #
「負荷分散」によって、外部のクライアントからは、サーバのクラスタが1つの大きな高速サーバであるかのように見えます。この単一サーバのように見えるサーバは、仮想サーバと呼ばれます。このサーバは、着信要求をディスパッチする1つ以上のロードバランサと実際のサービスを実行しているいくつかの実際のサーバで構成されます。SUSE Linux Enterprise High Availabilityの負荷分散設定によって、高度にスケーラブルで可用性の高いネットワークサービス(Web、キャッシュ、メール、FTP、メディア、VoIPなど)を構築できます。
17.1 概念の概要 #
SUSE Linux Enterprise High Availabilityは、負荷分散の2つのテクノロジー(Linux仮想サーバ(LVS)およびHAProxy)をサポートしています。これらの主な相違点は、Linux仮想サーバがOSI第4層(トランスポート)でカーネルのネットワーク層を設定するのに対し、HAProxyは第7層(アプリケーション)のユーザスペースで実行されることにあります。このように、Linux仮想サーバは、より少ないリソースで、より高い負荷を処理します。それに対してHAProxyは、トラフィックを調査し、SSL停止を実行して、トラフィックのコンテンツに基づいたディパッチに関する決定を行います。
一方、Linux仮想サーバには、IPVS (IP Virtual Server)およびKTCPVS (Kernel TCP Virtual Server)という2つの異なるソフトウェアが組み込まれています。IPVSは第4層の負荷分散を提供するのに対し、KTCPVSは第7層の負荷分散を提供します。
この項では、高可用性と組み合わせた負荷分散について概説してから、Linux仮想サーバとHAProxyについて簡単に説明します。最後に、追加情報を紹介します。
実際のサーバとロードバランサは、高速LANまたは地理的に分散されたWANのいずれでも、相互に接続できます。ロードバランサは、さまざまなサーバに要求をディスパッチします。ロードバランサによって、クラスタのパラレルサービスが1つのIPアドレス(仮想IPアドレスまたはVIP)上の仮想サービスであるかのように見えます。要求のディスパッチでは、IP負荷分散技術か、アプリケーションレベル負荷分散技術を使用できます。クラスタ内のノードのトランスペアレントな追加または削除によって、システムのスケーラビリティが達成されます。
ノードまたはサービスの障害検出と仮想サーバシステム全体の適切な再設定によって、常に高い可用性が実現されます。
いくつかの負荷分散戦略があります。ここに、Linux仮想サーバに適した第4層の各戦略を示します。
ラウンドロビン. 最も簡単な戦略は、各接続を異なるアドレスに順番に指定することです。たとえば、DNSサーバは指定のホスト名に対するいくつかのエントリを持つことができます。DNSラウンドロビンでは、DNSサーバは循環しながらそれらのエントリすべてを順番に返します。このように、異なるクライアントは異なるアドレスを表示します。
「最良の」サーバの選択. これにはいくつかのデメリットがありますが、「応答する最初のサーバ」または「負荷の最も少ないサーバ」アプローチで分散を実装できます。
サーバごとの接続数分散. ユーザとサーバ間のロードバランサは、複数のサーバ間でユーザ数を分割できます。
地理上の場所. 近くのサーバにクライアントをダイレクトすることができます。
ここに、HAProxyに適した第7層の各戦略を示します。
URI. HTTPコンテンツを調査し、この特定のURIに最適なサーバにディスパッチします。
URLパラメータ、RDPクッキー. セッションパラメータ(ポストパラメータの場合もある)、またはRDP(リモートデスクトッププロトコル)セッションクッキーのHTTPコンテンツを調査し、このセッションを提供するサーバにディパッチします。
一部の重複はありますが、HAProxyはLVS/ipvsadm
が不十分なシナリオで使用できます(およびその逆もあり)。
SSL停止. フロントエンドロードバランサは、SSL層を処理できます。このため、クラウドノードは、SSLキーにアクセスする必要はなく、ロードバランサのSSLアクセラレータを利用できます。
アプリケーションレベル. HAProxyはアプリケーションレベルで動作するため、コンテンツストリームによって負荷分散の決定に影響を与えることができます。これにより、クッキーや他のフィルタに基づいた永続化が許可されます。
一方、LVS/ipvsadm
は、HAProxyで完全に置き換えることはできません。
LVSは、ロードバランサがインバウンドストリーム内にのみ配置される「ダイレクトルーティング」をサポートし、アウトバウンドトラフィックは直接クライアントにルーティングされます。これにより、非対称環境でのスループットがかなり向上する可能性があります。
LVSは、(
conntrackd
を介した)ステートフルな接続テーブルレプリケーションをサポートしています。これにより、クライアントおよびサーバに透過なロードバランサのフェールオーバーが可能になります。
17.2 Linux仮想サーバによる負荷分散の設定 #
以降のセクションでは、主要なLVSのコンポーネントと概念の概要を示します。次に、SUSE Linux Enterprise High AvailabilityにLinux仮想サーバを設定する方法について説明します。
17.2.1 Director #
LVSの主要コンポーネントは、ip_vs (またはIPVS)カーネルコードです。これはデフォルトカーネルの一部であり、Linuxカーネル(第4層スイッチング)内のトランスポート層負荷分散を実装します。IPVSコードを含むLinuxカーネルを実行するノードは、ディレクターと呼ばれます。ディレクターで実行されるIPVSコードは、LVSの必須機能です。
クライアントがディレクターに接続すると、着信要求はすべてのクラスタノード間で負荷分散されます。ディレクターは、パケットを実サーバに転送し、LVSを機能させる変更されたルーティングルールセットを使用します。たとえば、ディレクターは、接続の送受信端でないと、受信確認を送信しません。ディレクターは、エンドユーザから実サーバ(要求を処理するアプリケーションを実行するホスト)にパケットを転送する特殊なルータとして動作します。
17.2.2 ユーザスペースのコントローラとデーモン #
ldirectord
デーモンは、Linux仮想サーバを管理し、負荷分散型仮想サーバのLVSクラスタ内の実サーバを監視するユーザスペースデーモンです。設定ファイル(以下を参照)は、仮想サービスとそれらに関連付けられた実サーバを指定し、LVSリダイレクタとしてサーバを設定する方法をldirectord
に指示します。このデーモンは、その初期化時にクラスタの仮想サービスを生成します。
ldirectord
デーモンは、既知のURLを定期的に要求し、応答を確認することにより、実サーバのヘルスを監視します。障害が発生した実サーバは、ロードバランサで使用可能なサーバのリストから削除されます。サービス監視は、ダウンしていたサーバが回復し、再度機能していることを検出すると、そのサーバを使用可能サーバリストに戻します。すべての実サーバがダウンする場合、Webサービスのリダイレクト先にするフォールバックサーバを指定できます。通常、フォールバックサーバは、ローカルホストであり、Webサービスが一時的に使用できないことについて緊急ページを表示します。
ldirectord
はipvsadm
ツール(ipvsadmパッケージ)を使用して、Linuxカーネル内の仮想サーバテーブルを操作します。
17.2.3 パケット転送 #
ディレクターがクライアントから実サーバにパケットを送信する方法は、3つあります。
- Network Address Translation (NAT)
着信要求は仮想IPで着信します。宛先のIPアドレスとポートを、選択した実サーバのIPアドレスとポートに変更することで、着信要求は実サーバに転送されます。実サーバはロードバランサに応答を送信し、そのロードバランサが宛先IPアドレスを変更して、応答をクライアントへ転送します。その結果、エンドユーザは予期されたソースから応答を受信します。すべてのトラフィックはロードバランサを通過するので、通常、ロードバランサがクラスタのボトルネックになります。
- IPトンネリング(IP-IPカプセル化)
IPトンネリングでは、あるIPアドレスにアドレス指定されたパケットを別のアドレス(別のネットワーク上でも可能)にリダイレクトできます。LVSは、IPトンネルを介して実サーバに要求を送信し(別のIPアドレスにリダイレクト)、実サーバは、独自のルーティングテーブルを使用して、クライアントに直接応答します。クラスタメンバーは、さまざまなサブネットに属すことができます。
- 直接ルーティング
エンドユーザからのパケットを、直接、実サーバに転送します。IPパケットは変更されないので、仮想サーバのIPアドレスのトラフィックを受け付けるように、実サーバを設定する必要があります。実サーバからの応答は、直接、クライアントに送信されます。実サーバとロードバランサは、同じ物理ネットワークセグメントに属する必要があります。
17.2.4 スケジューリングアルゴリズム #
クライアントから要求された新しい接続に使用する実サーバの決定は、さまざまなアルゴリズムを使用して実装されます。それらは、モジュールとして使用可能であり、特定のニーズに合わせて調整できます。使用可能なモジュールの概要については、ipvsadm(8)
のマニュアルページを参照してください。ディレクターは、クライアントから接続要求を受信すると、スケジュールに基づいて実際のサーバをクライアントに割り当てます。スケジューラは、IPVSカーネルコードの一部として、次の新しい接続を取得する実際のサーバを決定します。
Linux仮想サーバのスケジューリングアルゴリズムの詳細については、http://kb.linuxvirtualserver.org/wiki/IPVSを参照してください。また、ipvsadm
のマニュアルページで--scheduler
を検索してください。
関連するHAProxy負荷分散戦略については、https://www.haproxy.org/download/1.6/doc/configuration.txtを参照してください。
17.2.5 YaSTによるIP負荷分散の設定 #
YaST IP負荷分散モジュールを使用して、カーネルベースのIP負荷分散を設定できます。このモジュールは、ldirectord
のフロントエンドです。
IP負荷分散ダイアログにアクセスするには、root
としてYaSTを開始し、 › の順に選択します。または、コマンドラインで「root
」と入力して、yast2 iplb
としてYaSTクラスタモジュールを起動します。
デフォルトのインストールには、設定ファイル/etc/ha.d/ldirectord.cf
は含まれていません。このファイルは、YaSTモジュールによって作成されます。YaSTモジュール内で使用できるタブは、設定ファイル/etc/ha.d/ldirectord.cf
の構造、グローバルオプションの定義、および仮想サービス用オプションの定義に対応しています。
設定例とその結果のロードバランサ/実サーバ間のプロセスについては、例17.1「単純なldirectord設定」を参照してください。
特定のパラメータを仮想サーバセクションとグローバルセクションの両方で指定した場合は、仮想サーバセクションで定義した値が、グローバルセクションで定義した値に優先します。
次の手順では、重要なグローバルパラメータの設定方法を示します。個々のパラメータ(および、ここに記載されていないパラメータ)の詳細については、ldirectord
のマニュアルページを参照してください。
ldirectord
が各実サーバに接続していて、それらがまだオンラインかどうかチェックする間隔を定義します。ldirectord
が、何回、実サーバに要求すると、確認が失敗したとみなされるか定義できます。実サーバへの接続ステータスが変わったら、システムにアラートを送信させたい場合は、有効な電子メールアドレスを
に入力します。ldirectord
に設定ファイルを継続的に監視させるかどうか定義します。yes
に設定した場合は、変更のたびに、設定ファイルが自動的にリロードされます。0
に設定され、新しい接続が受け入れられなくなります。すでに確立している接続は、タイムアウトするまで持続します。ロギングに代替パスを使用するには、
でログファイルのパスを指定します。デフォルトでは、ldirectord
は、そのログファイルを/var/log/ldirectord.log
に書き込みます。
仮想サービスごとに、2、3のパラメータを定義することによって、1つ以上の仮想サービスを設定できます。次の手順で、仮想サービスの重要なパラメータを設定する方法を示します。個々のパラメータ(および、ここに記載されていないパラメータ)の詳細については、ldirectord
のマニュアルページを参照してください。
YaST IP負荷分散モジュール内で、
タブに切り替えます。VIP:port
サービスの任意の集まりを1つの仮想サービスにまとめる方法です。gate
、ipip
、またはmasq
のいずれかにする必要があります(17.2.3項 「パケット転送」を参照)。Negotiate
を選択します。Negotiate
]に設定した場合は、監視するサービスの種類も定義する必要があります。 ドロップダウンボックスから選択してください。実サーバからの応答に一定の文字列(「I'm alive」メッセージ)が含まれているかどうか確認する場合は、一致する必要のある正規表現を定義します。正規表現を に入力します。実サーバからの応答にこの表現が含まれている場合、実サーバはアクティブとみなされます。
ステップ 6で選択した のタイプによっては、認証のためのパラメータをさらに指定する必要があります。 タブに切り替えて、 、 、 、または などの詳細を入力します。詳細については、YaSTヘルプのテキストか、
ldirectord
のマニュアルページを参照してください。ロードに使用する
を選択します。使用可能なスケジューラについては、ipvsadm(8)
のマニュアルページを参照してください。使用する
を選択します。仮想サービスをIPアドレスとポートとして指定する場合は、プロトコルをtcp
またはudp
のどちらかにする必要があります。仮想サービスをファイアウォールマークとして指定する場合は、プロトコルをfwm
にする必要があります。必要な場合は、さらにパラメータを定義します。
を選択して、設定を確認します。YaSTが設定を/etc/ha.d/ldirectord.cf
に書き込みます。
図17.1「YaST IP負荷分散 - グローバルパラメータ」と図17.2「YaST IP負荷分散 - 仮想サービス」で示された値を使用すると、次のような設定になり、/etc/ha.d/ldirectord.cf
で定義されます。
autoreload = yes 1 checkinterval = 5 2 checktimeout = 3 3 quiescent = yes 4 virtual = 192.168.0.200:80 5 checktype = negotiate 6 fallback = 127.0.0.1:80 7 protocol = tcp 8 real = 192.168.0.110:80 gate 9 real = 192.168.0.120:80 gate 9 receive = "still alive" 10 request = "test.html" 11 scheduler = wlc 12 service = http 13
| |
実サーバがまだオンラインかどうか確認するため、 | |
最後の確認後、実サーバが応答しなければならない時間的な期限 | |
障害が発生した実サーバをカーネルのLVSテーブルから削除せず、代わりに、それらのサーバの重み付けを | |
LVSの仮想IPアドレス(VIP)。LVSはポート | |
実サーバがまだアクティブかどうかをテストするための確認のタイプ。 | |
このサービス用のすべての実サーバがダウンしている場合に、Webサービスのリダイレクト先にするサーバ。 | |
使用するプロトコル。 | |
ポート | |
実サーバからの応答文字列内で一致する必要のある正規表現。 | |
確認間隔中に、各実サーバで要求されるオブジェクトへのURI。 | |
負荷分散に使用するスケジューラが選択されています。 | |
監視するサービスのタイプ |
この設定にすると、次のプロセスフローになります。ldirectord
が各実サーバに5秒に1回接続し(2)、9および11で指定されたように192.168.0.110:80/test.html
または192.168.0.120:80/test.html
を要求します。予期されたstill alive
文字列(10)を、最後の確認から3秒以内(3)に実サーバから受信しない場合は、実サーバが使用可能なサーバのプールから削除されます。ただし、quiescent=yes
が設定されているので(4)、実サーバは、LVSテーブルからは削除されません。代わりに、その重み付けが0
に設定されます。その結果、この実サーバへの新しい接続は受け付けられなくなります。すでに確立している接続は、タイムアウトするまで持続します。
17.2.6 追加設定 #
YaSTによるldirectord
の設定に加えて、LVS設定を完了するには、次の条件を満たす必要があります。
実サーバは、必要なサービスを提供するように正しく設定します。
負荷分散サーバは、IP転送を使用して実サーバにトラフィックをルーティングできる必要があります。実サーバのネットワーク設定は、選択したパケット転送方法によって左右されます。
負荷分散サーバをシステム全体のシングルポイント障害にしないため、ロードバランサのバックアップを1つ以上セットアップする必要があります。クラスタ設定では、
ldirectord
にプリミティブリソースを設定して、ハードウェア障害の場合にldirectord
が他のサーバにフェールオーバーできるようにします。ロードバランサのバックアップにも、その作業を達成するために、
ldirectord
設定ファイルが必要なので、ロードバランサのバックアップとして使用するすべてのサーバ上で/etc/ha.d/ldirectord.cf
が使用できるようにします。設定ファイルは、4.7項 「すべてのノードへの設定の転送」で説明されているように、Csync2で同期できます。
17.3 HAProxyによる負荷分散の設定 #
次のセクションでは、HAProxyの概要とHigh Availabilityでのセットアップ方法について説明します。ロードバランサは、すべての要求をそのバックエンドサーバに分配します。アクティブ/パッシブとして設定されています。つまり、1台のサーバに障害が発生すると、パッシブサーバがアクティブになります。このようなシナリオでは、ユーザは中断したことに気付きません。
このセクションでは、次のセットアップを使用します。
ロードバランサ、IPアドレス
192.168.1.99
仮想の浮動IPアドレス
192.168.1.99
サーバ(通常Webコンテンツ用)
www.example1.com
(IP:192.168.1.200
)およびwww.example2.com
(IP:192.168.1.201
)
HAProxyを設定するには、次の手順に従います。
haproxyパッケージをインストールします。
次のコンテンツを含む
/etc/haproxy/haproxy.cfg
ファイルを作成します。global 1 maxconn 256 daemon defaults 2 log global mode http option httplog option dontlognull retries 3 option redispatch maxconn 2000 timeout connect 5000 3 timeout client 50s 4 timeout server 50000 5 frontend LB bind 192.168.1.99:80 6 reqadd X-Forwarded-Proto:\ http default_backend LB backend LB mode http stats enable stats hide-version stats uri /stats stats realm Haproxy\ Statistics stats auth haproxy:password 7 balance roundrobin 8 option httpclose option forwardfor cookie LB insert option httpchk GET /robots.txt HTTP/1.0 server web1-srv 192.168.1.200:80 cookie web1-srv check server web2-srv 192.168.1.201:80 cookie web2-srv check
プロセスワイドでOS固有のオプションを含むセクション。
maxconn
プロセスあたりの同時接続の最大数。
daemon
HAProxyがバックグラウンドで実行する推奨モード。
セクションの宣言後に、他のすべてのセクションのデフォルトパラメータを設定するセクション。次の重要な行があります。
redispatch
接続が失敗した場合にセッションの再ディストリビューションを有効または無効にします。
log
イベントおよびトラフィックのログ記録を有効にします。
mode http
HTTPモードで動作します(HAProxyの推奨モード)このモードでは、サーバへの接続が実行される前に要求が分析されます。RFCに準拠しない要求は拒否されます。
option forwardfor
HTTP
X-Forwarded-For
ヘッダを要求に追加します。クライアントのIPアドレスを維持する場合は、このオプションが必要です。
サーバへの接続試行が成功するまで待機する最大時間。
クライアント側の最大非アクティブ時間。
サーバ側の最大非アクティブ時間。
フロントエンドおよびバックエンドセクションを1つに結合するセクション。
balance leastconn
負荷分散アルゴリズムを定義します。https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-balanceを参照してください。
stats enable
,stats auth
(
stats enable
を使用して)統計レポーティングを有効にします。auth
オプションは、特定のアカウントに対して認証された統計のログを記録します。
HAProxy Statisticレポートページの認証情報。
負荷分散はラウンドロビン処理で動作します。
設定ファイルをテストします。
#
haproxy -f /etc/haproxy/haproxy.cfg -c
Csync2の設定ファイル
/etc/csync2/csync2.cfg
に次の行を追加して、HAProxy設定ファイルが含まれていることを確認します。include /etc/haproxy/haproxy.cfg
それを同期します。
#
csync2 -f /etc/haproxy/haproxy.cfg
#
csync2 -xv
注記Csync2設定部分では、HAノードがcrmシェルで提供されているブートストラップスクリプトを使用して設定されていることを前提としています。詳細については、『インストールとセットアップクイックスタート』を参照してください。
Pacemakerによって起動されるため、HAProxyが両方のロードバランサ(
alice
およびbob
)で無効になっていることを確認します。#
systemctl disable haproxy
新しいCIBを設定します。
#
crm
crm(live)#
cib new haproxy-config
crm(haproxy-config)#
primitive haproxy systemd:haproxy \ op start timeout=120 interval=0 \ op stop timeout=120 interval=0 \ op monitor timeout=100 interval=5s \ meta target-role=Started
crm(haproxy-config)#
primitive vip IPaddr2 \ params ip=192.168.1.99 nic=eth0 cidr_netmask=23 broadcast=192.168.1.255 \ op monitor interval=5s timeout=120 on-fail=restart
crm(haproxy-config)#
group g-haproxy vip haproxy
新しいCIBを確認し、エラーがあれば修正します。
crm(haproxy-config)#
verify
新しいCIBをコミットします。
crm(haproxy-config)#
cib use live
crm(live)#
cib commit haproxy-config
17.4 詳細の参照先 #
http://www.linuxvirtualserver.org/にあるプロジェクトのホームページ。
ldirectord
の詳細については、その総合的なマニュアルページを参照してください。LVS Knowledge Base: http://kb.linuxvirtualserver.org/wiki/Main_Page。