LVS+Keepalivedの詳しい説明

高度に情報化された IT 時代において、企業の生産システム、業務運営、販売とサポート、日常管理はコンピューター情報とサービスへの依存度が高まっており、高可用性 (HA) テクノロジーの適用に対する需要はますます高まっています。継続的で中断のないコンピュータシステムまたはネットワークサービスを提供するため。

Keepalived は、VRRP プロトコルに基づく LVS サービスの高可用性ソリューションであり、静的ルーティングにおける単一障害点の問題を解決できます。

1. キープアライブのツールと機能

LVSおよびHA向けに特別に設計されたヘルスチェックツール

1. LVS 負荷分散ソフトウェアを管理する

keepalived は、独自の設定ファイルを読み取ることで、下位レベルのインターフェイスを通じて LVS 設定とサービスの開始および停止機能を直接管理できるため、LVS アプリケーションが容易になります。

2. 自動フェイルオーバーのサポート (フェイルオーバー)

① 両方のホストに keepalived をインストールし、サービスを同時に開始します

マスターホストは起動するとすべてのリソースを取得してユーザーにサービス（リクエスト）を提供し、カラーキャリブレーションバックアップホスト使用時はマスターホットスタンバイとして機能します。

マスターホストがハングアップして障害が発生すると、バックアップホストは、VIP リソースや対応するリソースサービスの引き継ぎを含め、マスターホストのすべての作業を自動的に引き継ぎます。

② マスターホストの障害が修復されると、マスターホストは自動的に元の処理を引き継ぎ、バックアップホストもマスターホストの障害時に引き継いだ処理を解放し、この時点で 2 台のホストは元の役割に戻ります。稼働状況

プリエンプションモード: マスターが障害から回復した後、バックアップノードから VIP を取得します。

非プリエンプション: マスターが障害から回復した後、バックアップはプリエンプトされず、バックアップはマスターの後に VIP にアップグレードされます。

3. ノードの健康状態チェックをサポート (ヘルスチェック)

keepalived.conf ファイルは、LVS の直接管理を実現するために、LVS のノード IP および関連パラメーターを構成します。

複数のノードサーバーに同時に障害が発生し、サービスを提供できない場合、keepalived サービスは、障害が発生したノードサーバーを LVS の通常転送リストから自動的に削除し、他の通常のノードサーバーへのリクエストをスケジュールして、ユーザーアクセスが影響を受けないようにします。障害が発生したノードサーバーが修復されると、キープアライブサービスによって通常の転送リストにノードサーバーが追加され、外部の顧客にサービスが提供されます。

4. LVS ロードバランシングスケジューリングサーバーノードサーバーの高可用性 (HA) を実装します。

一般に、エンタープライズクラスターには、ロードバランシング、ヘルスチェック、フェイルオーバーの 3 つの特性を満たす必要がありますが、LVS + Keepalived を使用することで、そのニーズを十分に満たすことができます。

2. 動作原理

LVSサービスクラスタには通常、マスターサーバー(MASTER)とバックアップサーバー(BACKUP)の2つの役割を持つサーバーが存在しますが、外部からは仮想IPとして見え、マスターサーバーはバックアップサーバーにVRRP通知情報を送信します。バックアップサーバーが受信できない場合、VRRPメッセージを受信した場合、つまりメインサーバーに異常が発生した場合、バックアップサーバーが仮想IPを引き継いでサービスを提供し続けることで高可用性を確保します。

キープアライブ高可用性は VRRP を介して通信します。VRRP は選択メカニズムを使用してマスターとスレーブを決定します。マスターの優先順位はスレーブよりも高くなります。そのため、動作中はマスターが最初にすべてのリソースを取得し、スレーブノードは待機状態になります。マスターノードに障害が発生すると、スタンバイノードがプライマリノードのリソースを引き継ぎ、プライマリノードを置き換えて外部サービスを提供します。

Keepalived サービス間では、マスターサーバーのみが常に VRRP ブロードキャストパケットを送信して、バックアップサーバーが生きていることを伝えます。このとき、バックアップサーバーはマスターをプリエンプトしません。マスターが利用できないとき、つまりバックアップサーバーがマスターによって送信されたブロードキャストパケットをリッスンできない場合は、関連サービスを開始してリソースを引き継ぎ、ビジネスの継続性を確保します。最速の引き継ぎ速度は 1 秒未満になる場合があります。

3. キープアライブの実装原則

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

4. Keepalivedの主要モジュール

keepalived アーキテクチャには、core、check、vrrp という 3 つの主要なモジュールがあります。

コアモジュール: これは keepalived の中核であり、メインプロセスの起動とメンテナンス、およびグローバル設定ファイルの読み込みと解析を担当します。

vrrp モジュール: VRRP プロトコルを実装するために使用されます。

check module: ヘルスチェックを担当し、一般的な方法にはポートチェックと URL チェックが含まれます。

5. VRRP (仮想ルーター冗長プロトコル)

ルーターのバックアップソリューションです
ホットスタンバイグループは複数のルーターで形成され、共有の仮想 IP アドレスを介して外部サービスを提供します。
各ホットスタンバイグループでは、同時にサービスを提供するメインルータは1台のみで、他のルータは冗長状態となります。
現在オンラインのルーターに障害が発生した場合、設定された優先順位に従って他のルーターが自動的に仮想 IP アドレスを引き継ぎ、サービスを提供し続けます。

VRRP通信原理：

VRRP は仮想ルーター冗長プロトコル、プロトコル番号: 112 です。静的ルーティングの単一障害点を解決するようです。

VRRP は、キャンペーンプロトコルメカニズムを使用してルーティングタスクを VRRP ルーターに割り当てます。

VRRP は、IP マルチキャスト (デフォルトのマルチキャストアドレス: 224.0.0.18) を使用して高可用性通信を実現します。

動作中は、プライマリノードがパケットを送信し、バックアップノードがパケットを受信しますが、バックアップノードがプライマリノードから送信されたデータパケットを受信できない場合、プライマリノードのリソースを引き継ぐための引き継ぎプログラムが起動されます。スタンバイノードは複数存在する可能性があり、優先順位に従って選択されますが、通常、Keepalived システムの運用および保守作業では 1 つのペアのみが存在します。

キープアライブサービスが正常に動作している場合、マスターノードは継続的に (マルチキャスト) ハートビートメッセージをバックアップノードに送信して、バックアップノードがまだ生きていることを伝えます。マスターノードに障害が発生した場合、スタンバイノードは抑止メッセージを送信できません。はプライマリノードからのハートビートを検出できないため、独自の引き継ぎプログラムを呼び出して、プライマリノードの IP リソースとサービスを引き継ぎます。プライマリノードが回復すると、スタンバイノードはプライマリノードの障害時に引き継いだ IP リソースとサービスを解放し、元のスタンバイの役割に戻ります。

VRRP は暗号化プロトコルを使用してデータを暗号化しますが、Keepalived 担当者は現在、認証タイプとパスワードをクリアテキストで構成することを推奨しています。

vrrp は、複数のルーターを仮想ルーティンググループ vrid に形成します。vrrp は、仮想ルート (仮想 IP と仮想 MAC を含む) を生成します。LAN 内のユーザーは、どれがマスターでどれがバックアップであるかを気にしません。仮想ルーティンググループのみを使用します。ゲートウェイとしての仮想ルーターの IP) 実際、仮想 IP はマスタールーターでホストされます。これは、実際のデータがマスター経由で転送されることを意味します。

バックアップは、優先度によってマスタールートを決定します。最も高い優先度を持つものがマスターです。バックアップは、マスターによって定期的に送信される vrrp メッセージを監視するためにのみ使用されます。マスターによって送信された vrrp メッセージが一定期間内に受信されなかった場合、タイムアウトになると、バックアップはマスターを捕捉すると、仮想 IP もバックアップヘッドにドリフトします。

6. フェイルオーバーメカニズム

Keepalived 高可用性サービス間のフェールオーバー転送は、VRRP を通じて実装されます。

Keepalived サービスが正常に動作している場合、メインマスターノードは継続的に (マルチキャスト) ハートビートメッセージをバックアップノードに送信し、バックアップバックアップノードに自分がまだ生きていることを伝えます。メインマスターノードに障害が発生すると、ハートビートメッセージを送信できなくなり、バックアップノードはハートビートメッセージを送信できなくなるため、ノードはマスターノードからのハートビートを検出できなくなり、独自の引き継ぎプログラムを呼び出してマスターノードの IP リソースとサービスを引き継ぎます。

マスターノードが回復すると、バックアップノードは、マスターノードの障害時に引き継いだ IP リソースとサービスを解放し、元のバックアップの役割に戻ります。

7. キープアライブスプリットブレインとその解決策

1.キープアライブスプリットブレイン

高可用性 (HA) システムでは、2 つのノードを接続する「ハートビートライン」が切断されると、本来は全体として連携して動作していた HA システムが 2 つの独立したエンティティに分割されます。連絡が取れなくなったので、お互いに相手が故障したのではないかと思いました。2 つのノード上の HA ソフトウェアは「分割脳人間」のようなもので、「共有リソース」と「アプリケーションサービス」をめぐって競合し、深刻な結果が発生します。さもなければ、共有リソースが分割され、「サービス」が両側に存在することになります。サービスを提供できなくなります。もうすぐです。または、両側の「サービス」は稼働していますが、同時に「共有ストレージ」の読み取りと書き込みを行って、データの損傷を引き起こします（通常、オンラインログのエラーなど）データベースポーリングの）。

2. スプリットブレインの原因

高可用性サーバーペア間のハートビートリンクに障害が発生し、通常の通信が失敗しました。たとえば、ハートビートケーブルが壊れています (破損または老朽化を含む)。

ネットワークカードと関連ドライバーが壊れているため、IP 構成と競合の問題 (ネットワークカードの直接接続) が発生します。

ハートビートケーブル間に接続されている機器（ネットワークカードとスイッチ）の故障によるもの。

アービトレーションマシン (アービトレーションソリューションを使用) に問題があります。

iptables ファイアウォールが高可用性サーバーで有効になっており、ハートビートメッセージの送信がブロックされています。

Keepalived 設定内の同じ VRRP インスタンスの両端の virtual_router_id パラメータ設定が矛盾している場合も、スプリットブレイン問題が発生します。

vrrp インスタンス名は一貫していませんが、優先順位は一貫しています。

3. 解決策

「スプリットブレイン」の可能性を最小限に抑えるために、二重線 (ハートビートラインも HA) などの冗長なハートビートラインを追加します。

ディスクロックを有効にします。サーバが共有ディスクをロックしている場合、「スプリットブレイン」が発生した場合、相手は共有ディスクリソースを完全に奪うことができなくなります。ただし、ロックされたディスクの使用には大きな問題があり、共有ディスクを占有している側が積極的に「ロックを解除」しないと、相手は共有ディスクを取得することができません。実際には、サービスノードが突然フリーズしたりクラッシュしたりすると、ロック解除コマンドを実行できなくなります。バックアップノードは、共有リソースとアプリケーションサービスを引き継ぐことができません。そこで誰かが HA の「スマート」ロックを設計しました。つまり、サービス提供側は、すべてのハートビートラインが切断されていることを発見した場合 (ピアはそれに気づいていない場合) にのみディスクロックをアクティブにします。通常は施錠されていません。

仲裁メカニズムをセットアップします。たとえば、参照 IP (ゲートウェイ IP など) を設定すると、ハートビートラインが完全に切断されたときに、両方のノードがそれぞれ参照 IP に ping を実行しますが、接続がない場合は、ブレークポイントがローカルエンドにあることを意味します。「ハートビート」だけでなく、外部「サービス」のローカルネットワークリンクも切断されています。アプリケーションサービスを開始 (または継続) しても無駄です。その場合は、積極的に競争を放棄し、参照 IP に ping できる側にサービスを開始させます。サービスです。より安全にするために、参照 IP に ping を送信できない側は、単純に自身を再起動して、まだ占有されている可能性のある共有リソースを完全に解放します。