目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise High Availabilityのドキュメント / 管理ガイド / 設定および管理 / 負荷分散
適用項目 SUSE Linux Enterprise High Availability 15 SP6

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サービスが一時的に使用できないことについて緊急ページを表示します。

ldirectordipvsadmツール(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を開始し、高可用性 › IP負荷分散の順に選択します。または、コマンドラインで「root」と入力して、yast2 iplbとしてYaSTクラスタモジュールを起動します。

デフォルトのインストールには、設定ファイル/etc/ha.d/ldirectord.cfは含まれていません。このファイルは、YaSTモジュールによって作成されます。YaSTモジュール内で使用できるタブは、設定ファイル/etc/ha.d/ldirectord.cfの構造、グローバルオプションの定義、および仮想サービス用オプションの定義に対応しています。

設定例とその結果のロードバランサ/実サーバ間のプロセスについては、例17.1「単純なldirectord設定」を参照してください。

注記
注記: グローバルパラメータと仮想サーバパラメータ

特定のパラメータを仮想サーバセクションとグローバルセクションの両方で指定した場合は、仮想サーバセクションで定義した値が、グローバルセクションで定義した値に優先します。

手順 17.1: グローバルパラメータの設定

次の手順では、重要なグローバルパラメータの設定方法を示します。個々のパラメータ(および、ここに記載されていないパラメータ)の詳細については、ヘルプをクリックするか、ldirectordのマニュアルページを参照してください。

  1. チェック間隔で、ldirectordが各実サーバに接続していて、それらがまだオンラインかどうかチェックする間隔を定義します。

  2. 確認タイムアウトで、最後の確認後に実サーバが応答する期限を設定します。

  3. 失敗回数では、ldirectordが、何回、実サーバに要求すると、確認が失敗したとみなされるか定義できます。

  4. ネゴシエーションタイムアウトで、ネゴシエーション確認のタイムアウトを秒単位で定義します。

  5. フォールバックで、すべての実サーバがダウンした場合にWebサービスのリダイレクト先にするWebサーバのホスト名とIPアドレスを入力します。

  6. 実サーバへの接続ステータスが変わったら、システムにアラートを送信させたい場合は、有効な電子メールアドレスを電子メールアラートに入力します。

  7. 電子メールアラート頻度で、実サーバにアクセスできない状態が続く場合、何秒後に電子メールアラートを繰り返すか定義します。

  8. 電子メールアラートのステータスで、電子メールアラートを送信する必要のあるサーバのステータスを指定します。複数の状態を定義する場合は、カンマで区切ったリストを使用します。

  9. 自動リロードで、変更の有無について、ldirectordに設定ファイルを継続的に監視させるかどうか定義します。yesに設定した場合は、変更のたびに、設定ファイルが自動的にリロードされます。

  10. 休止スイッチで、障害が発生した実サーバをカーネルのLVSテーブルから削除するかどうか定義します。はいに設定すると、障害のあるサーバは削除されません。代わりに、それらの重み付けが0に設定され、新しい接続が受け入れられなくなります。すでに確立している接続は、タイムアウトするまで持続します。

  11. ロギングに代替パスを使用するには、ログファイルでログファイルのパスを指定します。デフォルトでは、ldirectordは、そのログファイルを/var/log/ldirectord.logに書き込みます。

YaST IP負荷分散 - グローバルパラメータ
図 17.1: YaST IP負荷分散 - グローバルパラメータ
手順 17.2: 仮想サービスの設定

仮想サービスごとに、2、3のパラメータを定義することによって、1つ以上の仮想サービスを設定できます。次の手順で、仮想サービスの重要なパラメータを設定する方法を示します。個々のパラメータ(および、ここに記載されていないパラメータ)の詳細については、ヘルプをクリックするか、ldirectordのマニュアルページを参照してください。

  1. YaST IP負荷分散モジュール内で、仮想サーバ設定タブに切り替えます。

  2. 追加で新しい仮想サーバを追加するか、編集で既存の仮想サーバを編集します。新しいダイアログに、使用可能なオプションが表示されます。

  3. 仮想サーバで、共有仮想IPアドレス(IPv4またはIPv6)とポートを入力します。これらのアドレスとポートで、ロードバランサと実サーバをLVSとしてアクセスできます。IPアドレスとポート番号の代わりに、ホスト名とサービスも指定できます。または、ファイアウォールマークを使用することもできます。ファイアウォールマークは、VIP:portサービスの任意の集まりを1つの仮想サービスにまとめる方法です。

  4. 実サーバで実際のサーバを指定するには、サーバのIPアドレス(IPv4、IPv6、またはホスト名)、ポート(またはサービス名)、および転送方法を入力する必要があります。転送方法は、gateipip、またはmasqのいずれかにする必要があります(17.2.3項 「パケット転送」を参照)。

    追加ボタンをクリックし、実サーバごとに必要な引数を入力します。

  5. 確認タイプで、実サーバがまだアクティブかどうかをテストするために実行する必要のある確認のタイプを選択します。たとえば、要求を送信し、応答に予期どおりの文字列が含まれているかどうか確認するには、Negotiateを選択します。

  6. チェック種類を[Negotiate]に設定した場合は、監視するサービスの種類も定義する必要があります。サービスドロップダウンボックスから選択してください。

  7. 要求で、確認間隔中に各実サーバで要求されるオブジェクトへのURLを入力します。

  8. 実サーバからの応答に一定の文字列(I'm aliveメッセージ)が含まれているかどうか確認する場合は、一致する必要のある正規表現を定義します。正規表現を受信に入力します。実サーバからの応答にこの表現が含まれている場合、実サーバはアクティブとみなされます。

  9. ステップ 6で選択したサービスのタイプによっては、認証のためのパラメータをさらに指定する必要があります。認証タイプタブに切り替えて、ログインパスワードデータベース、またはシークレットなどの詳細を入力します。詳細については、YaSTヘルプのテキストか、ldirectordのマニュアルページを参照してください。

  10. その他タブに切り替えます。

  11. ロードに使用するスケジューラを選択します。使用可能なスケジューラについては、ipvsadm(8)のマニュアルページを参照してください。

  12. 使用するプロトコルを選択します。仮想サービスをIPアドレスとポートとして指定する場合は、プロトコルをtcpまたはudpのどちらかにする必要があります。仮想サービスをファイアウォールマークとして指定する場合は、プロトコルをfwmにする必要があります。

  13. 必要な場合は、さらにパラメータを定義します。OKを選択して、設定を確認します。YaSTが設定を/etc/ha.d/ldirectord.cfに書き込みます。

YaST IP負荷分散 - 仮想サービス
図 17.2: YaST IP負荷分散 - 仮想サービス
例 17.1: 単純なldirectord設定

図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

1

ldirectordが変更の有無について設定ファイルを継続的に確認するように定義します。

2

実サーバがまだオンラインかどうか確認するため、ldirectordが各実サーバに接続する間隔。

3

最後の確認後、実サーバが応答しなければならない時間的な期限

4

障害が発生した実サーバをカーネルのLVSテーブルから削除せず、代わりに、それらのサーバの重み付けを0に設定します。

5

LVSの仮想IPアドレス(VIP)。LVSはポート80で使用できます。

6

実サーバがまだアクティブかどうかをテストするための確認のタイプ。

7

このサービス用のすべての実サーバがダウンしている場合に、Webサービスのリダイレクト先にするサーバ。

8

使用するプロトコル。

9

ポート80で使用できる2つの実サーバが定義されています。パケットの転送方法がgateなので、直接ルーティングが使用されます。

10

実サーバからの応答文字列内で一致する必要のある正規表現。

11

確認間隔中に、各実サーバで要求されるオブジェクトへのURI。

12

負荷分散に使用するスケジューラが選択されています。

13

監視するサービスのタイプ

この設定にすると、次のプロセスフローになります。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を設定するには、次の手順に従います。

  1. haproxyパッケージをインストールします。

  2. 次のコンテンツを含む/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

    1

    プロセスワイドでOS固有のオプションを含むセクション。

    maxconn

    プロセスあたりの同時接続の最大数。

    daemon

    HAProxyがバックグラウンドで実行する推奨モード。

    2

    セクションの宣言後に、他のすべてのセクションのデフォルトパラメータを設定するセクション。次の重要な行があります。

    redispatch

    接続が失敗した場合にセッションの再ディストリビューションを有効または無効にします。

    log

    イベントおよびトラフィックのログ記録を有効にします。

    mode http

    HTTPモードで動作します(HAProxyの推奨モード)このモードでは、サーバへの接続が実行される前に要求が分析されます。RFCに準拠しない要求は拒否されます。

    option forwardfor

    HTTP X-Forwarded-Forヘッダを要求に追加します。クライアントのIPアドレスを維持する場合は、このオプションが必要です。

    3

    サーバへの接続試行が成功するまで待機する最大時間。

    4

    クライアント側の最大非アクティブ時間。

    5

    サーバ側の最大非アクティブ時間。

    6

    フロントエンドおよびバックエンドセクションを1つに結合するセクション。

    balance leastconn

    負荷分散アルゴリズムを定義します。https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-balanceを参照してください。

    stats enable , stats auth

    (stats enableを使用して)統計レポーティングを有効にします。authオプションは、特定のアカウントに対して認証された統計のログを記録します。

    7

    HAProxy Statisticレポートページの認証情報。

    8

    負荷分散はラウンドロビン処理で動作します。

  3. 設定ファイルをテストします。

    # haproxy -f /etc/haproxy/haproxy.cfg -c
  4. Csync2の設定ファイル/etc/csync2/csync2.cfgに次の行を追加して、HAProxy設定ファイルが含まれていることを確認します。

    include /etc/haproxy/haproxy.cfg
  5. それを同期します。

    # csync2 -f /etc/haproxy/haproxy.cfg
    # csync2 -xv
    注記
    注記

    Csync2設定部分では、HAノードがcrmシェルで提供されているブートストラップスクリプトを使用して設定されていることを前提としています。詳細については、『インストールとセットアップクイックスタート』を参照してください。

  6. Pacemakerによって起動されるため、HAProxyが両方のロードバランサ(aliceおよびbob)で無効になっていることを確認します。

    # systemctl disable haproxy
  7. 新しい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
  8. 新しいCIBを確認し、エラーがあれば修正します。

    crm(haproxy-config)# verify
  9. 新しいCIBをコミットします。

    crm(haproxy-config)# cib use live
    crm(live)# cib commit haproxy-config

17.4 詳細の参照先