LVS-DRモード+ Keepalived理論、超詳細！

1つ：LVS-DR動作原理

1.1：DRモードの概要

• 負荷分散クラスター作業モード直接ルーティング（直接ルーティング）
  • DRモードと呼ばれ、TUNモードの構造と同様のセミオープンネットワーク構造を採用していますが、ノードはどこにでも散在しているわけではなく、スケジューラーと同じ物理ネットワークに配置されています。
  • ロードスケジューラは、ローカルネットワークを介して各ノードサーバーに接続され、専用のIPトンネルを確立する必要はありません。

1.2：データパケットフロー分析

• 原理分析を容易にするために、クライアントとクラスターマシンを同じネットワークに配置し、データパケットフローのルートは1-2-3-4です。

1.クライアントがリクエストをターゲットVIPに送信し、ディレクター（ロードバランサー）がそれを受信します。

• IPヘッダーおよびデータフレームヘッダー情報

2.ディレクタは、負荷分散アルゴリズムに従ってRealserver_1を選択し、IPメッセージを変更またはカプセル化せずに、データフレームのMACアドレスをRealServer_1のMACアドレスに変更して、LANに送信します。

• IPヘッダーおよびデータフレームヘッダー情報

3. RealServer_1はこのフレームを受信し、カプセル化解除後にターゲットIPがローカルマシンと一致することを検出します（RealServerは事前にVIPにバインドされています）。このため、このメッセージを処理します。次に、メッセージを再カプセル化して、LANに送信します。

4.クライアントは返信メッセージを受け取ります。クライアントは通常のサービスを受けていると思っていますが、どのサーバーがそれを処理するのかわかりません

注：ネットワークセグメントを通過する場合、メッセージはルーター経由でユーザーに返されます。

5.概要：同じIPアドレスの場合、MACアドレスが変更されます

1.3：LVS-DRのARP問題

• LVS-DRロードバランシングクラスターでは、ロードバランサーとノードサーバーを同じVIPアドレスで構成する必要があります

• ローカルエリアネットワークで同じIPアドレスを使用すると、各サーバーのARP通信に必然的に障害が発生します
  • ARPブロードキャストがLVS-DRクラスターに送信されると、ロードバランサーとノードサーバーが同じネットワークに接続されているため、どちらもARPブロードキャストを受信します。
  • 現時点では、フロントエンドロードバランサーのみが応答し、他のノードサーバーはARPブロードキャストに応答してはなりません
• VIPのARP要求に応答しないようにノードサーバーを処理する
  • 仮想インターフェイスlo：0を使用してVIPアドレスを伝送する
  • カーネルパラメータarp_ignore = 1を設定します。システムは、宛先IPがローカルIPであるARP要求にのみ応答します
• RealServeリターンパケット（ソースIPはVIP）はルーターによって転送され、パケットを再カプセル化するときに、ルーターのMACアドレスを最初に取得する必要があります。

• ARP要求を送信するとき、Linuxはデフォルトで、IPパケット（つまりVIP）の送信元IPアドレスを、送信インターフェース（ens33など）のIPアドレスではなく、ARP要求パケットの送信元IPアドレスとして使用します。

• ルータはARP要求を受信した後、ARPテーブルエントリを更新します
• ディレクターのMACアドレスに対応する元のVIPは、RealServerのMACアドレスに対応するⅥPに更新されます

• このとき、ルータはARPテーブルエントリに従って新しいリクエストメッセージをRealServerに転送し、その結果、

ディレクターのVIPが無効です

• 解決

ノードサーバーを処理し、カーネルパラメータarp_announce = 2を設定します。システムはIPパケットの送信元アドレスを使用してARP要求の送信元アドレスを設定しませんが、送信インターフェイスのIPアドレスを選択します

1.4：上記の2つのARP問題を解決する方法

- '修改/etc/sysctl.conf文件'
  - '对节点服务器进行处理，使其不响应针对VIP的ARP请求'
  - net.ipv4.conf.lo.arp_ignore = 1
  - net.ipv4.conf.lo.arp_announce = 2
  - '系统不使用IP包的源地址来设置ARP请求的源地址，而选择发送接口的IP地址'
  - net.ipv4.conf.all.arp_ignore = 1
  - net.ipv4.conf.all.arp_announce = 2

2：維持された実現原理

2.1：Keepalivedケース分析

• エンタープライズアプリケーションでは、単一のサーバーがアプリケーションの単一障害点のリスクを負います
• 単一障害点が発生すると、エンタープライズサービスが中断され、大きな損害が発生します

2.2：keepalivedツールの概要

• LVSおよびHA用に特別に設計されたヘルスチェックツール
  • 自動フェイルオーバー（フェイルオーバー）をサポート
  • サポートノードのヘルスチェック（ヘルスチェック）
  • 公式ウェブサイトhttp://www.keepalived.org

2.3：原理分析

• KeepalivedはVRRPホットバックアッププロトコルを採用して、Linuxサーバーのマルチマシンホットバックアップ機能を実現しています

• VRRP、仮想ルーティング冗長プロトコルは、ルーターのバックアップソリューションです。

• 複数のルーターがホットバックアップグループを形成し、共有仮想IPアドレスを介して外部にサービスを提供します

• 各ホットバックアップグループで同時にサービスを提供するメインルータは1つだけであり、他のルータは冗長状態です。

• 現在オンラインのルーターに障害が発生した場合、他のルーターは設定された優先順位に従って仮想IPアドレスを自動的に引き継ぎ、サービスを提供し続けます

3：Keepalievdを展開する方法

3.1：Keepalievdデプロイメントの概要

• Keepalivedはマルチマシンホットバックアップを実現でき、各ホットスタンバイグループは複数のサーバーを持つことができます。最も一般的に使用されるのはデュアルマシンホットバックアップです。

• デュアルシステムホットバックアップのフェイルオーバーは、さまざまなアプリケーションサーバーに適した仮想IPアドレスのドリフトによって実現されます。

• この展開では、Webサービスに基づくデュアルマシンホットバックアップを実装します

3.2：Keepalievdのインストールと起動

• LVSクラスター環境に適用する場合は、lipvsadm管理ツールも必要です
• YUMはKeepalivedをインストールします
• Keepalivedサービスを有効にする

3.3：Keepalievdマスターサーバーの構成

• Keepalievd設定ディレクトリは/ etc / keepalievd /にあります
• keepalievd.confはメインの構成ファイルです
  • global_defs {...}セクションはグローバルパラメータを指定します
  • vrrp_instanceインスタンス名{...}セクションは、VRRPホットスタンバイパラメータを指定します
  • コメントテキストは「！」記号で始まります
  • ディレクトリsamples /、参照として多くの構成サンプルを提供します
• 一般的な構成オプション
  • router_id HA_TEST_R1：ルーター（サーバー）の名前
  • vrrp_instance VI_1：VRRPホットスタンバイインスタンスを定義
  • 状態MASTER：ホットスタンバイ状態、MASTERはマスターサーバーを表します
  • インターフェースens33：VIPアドレスを運ぶ物理インターフェース
  • virtual_router_id 1：仮想ルーターのID番号。ホットスタンバイグループごとに一貫しています。
  • 優先度100：優先度、値が大きいほど優先度が高い
  • advert_int 1：通知間の秒数（ハートビート頻度）
  • auth_type PASS：認証タイプ
  • auth_pass 123456：パスワード文字列
  • virtual_ipaddress {vip}：ドリフトアドレス（VIP）を指定します。複数ある場合があります。複数のドリフトアドレスはコンマで区切られます

3.4：Keepalivedスレーブサーバーの設定

• Keepalivedバックアップサーバーの構成とマスター構成には、3つのオプションがあります。
  • router_id：フリー名として設定
  • 状態：バックアップに設定
  • 優先度：値がプライマリサーバーよりも低い
• 他のオプションはマスターと同じです

3.5：Keepalivedデュアルシステムホットバックアップ効果テスト

• デュアルマシンのホットバックアップの効果をテストする
  • メインマシンとスタンバイマシンでWebサービスが有効になっていて、内容が同じである
  • メインサーバーのネットワークカードを連続して無効にしてから有効にし、次のテストを実行します。
• テスト1：pingを使用して19216810.72の接続を検出する
• テスト2：htt：/192168.10.72にアクセスして、
  カードの使いやすさとコンテンツの変更を確認し、次のテストを実行します。
• テスト1：pingを使用して19216810.72の接続を検出する
• テスト2：htt：/192168.10.72にアクセスして、可用性とコンテンツの変更を確認する
• テスト3：ログファイル/ var / log / messagesの変更を表示する