毎日のクラスタ・システム・アーキテクチャ、一般的に主に2種類にハートビートを使用：
1）HA（高可用性）ハートビートが達成使用してHAクラスタとも呼ばれる「ホットスタンバイ」、「デュアルアクティブ」 「デュアル」;
2）ロードバランシングクラスタ（ロードバランスクラスタ）、達成するためにLinuxの仮想サーバー（LVS）を使用しました。
ハートビート導入
ハートビートは、高可用性クラスタシステムを実装のLinux-HAプロジェクトの構成要素です。ハートビートとクラスタ通信サービスは、ハートビートモジュールが実装これら二つの機能によって、ハートビートプロジェクトで、高可用性クラスタの2つの主要な成分です。ハートビートは、それはのようなHAソフトウェアは、必要なすべての基本的な機能、提供、HAプロジェクトが成功したオープンソースの一例である、引き継ぐ、クラスタノード間で共有IPアドレスの転送をクラスタシステムサービスを監視するために、ハートビートとリソースを所有者など、今まで1999年まで以来、ハートビートは、産業界で広く使用されています。ハートビートコア関数は2つの部分、ハートビート監視およびリソース引継ぎから成ります。ハートビートは、お互いに伝えるためにお互いにメッセージを送信する、冗長リンクのネットワークリンクとシリアルポート、およびサポートを通して監視することができ、それらの間の彼らの現在の状態、他の当事者は、その後、指定された時間内に送信されたメッセージを受信しない場合他の側に障害が発生していること、そして必要性は他のホスト上のリソースやサービスの実行を引き継ぐために、モジュールを引き継ぐためにリソースを開始します。
差分Hearbeat keepalivedの
1）VRRPプロトコルはVRRP）と呼ばれる、keepalivedの形態、VRRP（仮想ルータ冗長プロトコルを使用
2）ハートビートの実施形態のホストまたはネットワークサービスの利用可能性に基づいている;
3）目標はkeepalivedのをシミュレートすることですデュアルルータ;
。4）ユーザーのデュアルのサービスハートビートオブジェクト;
。; 5）LVSの可用性のがKeepavlived示唆した
。6）ハートビートサービスの可用性を持ちます。
keepalivedのメインドリフト制御IPは、アプリケーションの構成はlayer3,4,5は、それぞれ非常に設定が簡単、シンプルですが、階層
のみのドリフトを制御することはできませんハートビートIPを、しかし、リソースとサービス、コンフィギュレーションの良好な制御は、アプリケーションがより複雑です。
HAクラスタ関連用語
。（ノード）は、ノード
ノードと呼ばれるハートビートプロセスを実行している独立したホストの、ノードはHAのコアコンポーネントであり、オペレーティングシステムとソフトウェアサービスは、クラスタハートビート内の各ノード上のハートビート実行、ノードは、それぞれ、一次および二次の点を有していますプライマリノードと代替/バックアップノードと呼ばれ、各ノードは、一意のホスト名を有しており、ディスク、ファイルシステム、ネットワークアドレスとアプリケーションサービスなどのリソースの独自のセットを持っています。通常、プライマリノードは、1つまたは複数のアプリケーションサービスを実行しています。通常監視状態でスタンバイノード。
。資源（リソース）
リソースがノードの実体を制御することが可能であり、ノードに障害が発生した場合、これらのリソースは、他のノード上で撮影することができ、ハートビート、エンティティがリソースとして使用されるべきことができます：
-ディスクパーティション、ファイルシステム
- IPアドレス
-アプリケーションサービス
- NFSファイル・システム
。イベント（イベント）
そのようなノードのシステム障害、ネットワーク接続の故障、ネットワークカードの障害、アプリケーションの障害として、クラスタ内で起こるかもしれないもの。これらのイベントは、リンパ節転移を資源化につながる、HAテストは、これらのイベントに基づいて行われます。
。アクション（行動）
イベントがHA応答方法を発生し、アクションのペースは、シェルによって制御され、故障したノードを引き継ぐ、サービスを行う、とするノードに障害が発生した場合、たとえば、バックアップノードがシャットダウンされるか、事前に設定されたスクリプトで開始します資源。
ハートビート成分
ハートビートは、例えば、基本的な機能の高可用性クラスタを提供し、ノード間の内部通信は、最新バージョンのクラスタ管理協力メカニズム、監視ツールとフェイルオーバー機能などHeartbeat2.xは、以下がHeartbeat2.xの程度であります主に次のように内部Heartbeat2.0組成物がいくつかの部分に分割されているに焦点を当て：
。ハートビート：ノード間通信検知モジュール
。HA-のlogD：クラスタイベントログサービス
。CCM（コンセンサスクラスタメンバーシップ）：一貫性クラスタメンバ管理モジュール
。LRM（ローカルリソースマネージャ）：ローカルリソース管理モジュール
。STONITHデーモン：環境から問題のクラスタからのノード
。CRM（クラスターリソース管理）：クラスタリソース管理モジュール
。クラスターポリシーエンジン：クラスタポリシーエンジン
。クラスタ遷移エンジン：クラスタ転送エンジン
次の図に示す内部構造と組成Heartbeat2.0
ハートビートはちょうどHAソフトウェアです、それだけで完了ハートビート監視およびリソース買収することができ、監視やアプリケーション・リソース、それが制御し、アプリケーションを監視するためのリソースが正常に動作している、あなたは、このようなipfail、月、Ldirectorなどのサードパーティのプラグインを使用する必要がありますしませんように。ハートビート自体は次のようにipfail、STONITHと記載Ldirectord、あるいくつかのプラグインを含んでいます。
プラグipfailハートビートは、主にネットワークの障害を検出するために使用される直接機能、および合理的応答、この機能を達成するために、ピングipfailピングノード又は障害が適時遷移するかどうかを検出するためにネットワークに接続されたノードのグループ対策。
STONITHプラグは、ノードの障害がクラスタサービスを引き起こす可能性があり、あなたはSTONITHプラグインを使用していない場合は、クラスタから削除されますが、ノードに障害が発生した場合、データの衝突を防ぐため、クラスタサービスのリソースを引き継ぐために無応答の回復と合理的とノードの後にすることができ複数のノードが実行され、それによって衝突を引き起こし、さらにはシステムがクラッシュより。このため、プラグインの使用は、データの整合性STONITH共有ストレージ環境を確保することができます。
Ldirectorプラグインは、プラグインの実行状態監視サービスノードクラスタです。Ldirectorクラスタは、このプラグは、しばしばLVS負荷分散クラスタで使用され、サービスは、それがこのノードの外部接続を遮断され、そして通常のノードがサービスを提供して、後続の要求が転送され、失敗した監視するノード場合。
同様に、独自のオペレーティングシステムの問題が発生するため、プライマリノードがメインリソースノードので、解放することができない一方で、サービスの中断をもたらすことができる一方で、システムハングを操作する場合はハートビートを監視することはできませんし、バックアップノードがプライマリノードのリソースを引き継ぎました、両方のこの時間は、リソースの競合状況が発生したノード。この問題に対処するには、ウォッチドッグがドッグがハングカーネルと考えている場合は実行するタイミングには/ dev /ウォッチドッグデバイスファイルにより、書き込み操作は、システムが正常に動作しているかどうかを判断することのLinuxカーネルモジュールである、と呼ばれるLinuxカーネルAウォッチドッグモジュールを有効にする必要があります以来、それはシステムを再起動し、ノードのリソースを解放します。
softdogと呼ばれるLinuxソフトウェアで、完全なウォッチドッグ機能は、softdogは、内部タイマを維持する過程で、書き込みは/ dev /ウォッチドッグ・デバイスの更新ファイルは、プロセスsoftdog書き込みは/ dev /ウォッチドッグ・ファイルが表示されない場合は、あなた私は、カーネルが故障している可能性がありだと思います。デフォルトのウォッチドッグタイムアウト期間は1分であり、それによってシステムはハートビートによって実行されているか否かを監視、ウォッチドッグによりハートビートに統合されてもよいです。
ハートビートの役割
ハートビートによっては、一つのコンピュータの障害からのリソース（IPおよびプログラムサービスやその他のリソース）に迅速に転送することができ、一般的に高可用性サービスとして知られているマシンの別の正常な動作、上で提供し続ける必要があります。実際の生産アプリケーションのシナリオでは、他のオープンソースソフトウェアのハートビート機能性と可用性は、当社の実際の生産事業における多くの類似点が異なっている必要がありkeepalivedの。
ハートビートがの働く
部分の一部を引き継ぐためにコアは2つの部分、心拍数モニターとリソースで構成され、心拍、心拍数モニタは、彼らがお互いに教え、相互にメッセージを送信する、冗長リンクのネットワークリンクとシリアルポート、およびサポートによって行うことができ、その相手がメッセージを受信しない場合、現在の状態は、他のホスト上のリソースやサービスの実行を引き継ぐために、モジュールを引き継ぐためにリソースを開始する必要があり、その後、他の側が失敗するように、指定された時間内に送信されます。
ハートビート： （ハートビート）自体は、その前の通信に各ノードとクラスタについての情報を維持する責任クラスタ（クラスタメッセージング層）の基礎であるだけプライマリバックアップを提供し、各ノードは、ldirectordをインストールする必要が監視することができません。
エージェントのリソース（資源ブローカー）スクリプトOCFリソースの多様で、スクリプトがリソースのLRM開始の様々な、停止、監視などを実現するために呼び出されます。
：クラスタグルー ;中間層の等価物、及び主にリンクされた心拍CRM（ペースメーカー）は二つの部分、LRMとSTONITH含む
：ldirectord 責任RealServerのヘルスチェックを自動的に機械のダウンタイムでのRealServerに除去することができます、無割り当て要求。
マスタ局としてハートビートサーバを処方することができる設定ファイルを変更することにより、ハートビートのソフトウェアは、他のステーションが自動的にホットスタンバイサーバーになります。ハートビートデーモンは、マスターサーバーからのハートビートメッセージを聞くことがホットスタンバイサーバー上に配置されました。指定された時間内にホットスタンバイサーバがホストサーバからのハートビートに耳を傾けるならば、プログラムは障害が脱出起動し、中断のないサービスを提供し続けるためにプライマリサーバを引き継ぐために、プライマリサーバ上のリソースの関連サービスの所有権を取得し、リソースが達成することになりますサービスの可用性の目的。
時間がで指定されている場合、ハートビート、上記のスタンバイモードでは、ハートビートはまた、現在の状態がお互いに自分自身を伝えるためにそれらの間で相互にメッセージを送信しますでプライマリマスタであるモード、2台のサーバー相互バックアップをサポートしています相手が送信されるハートビートメッセージ内に受信されない場合、当事者が他の当事者が失敗したか、またはダウンしていると思います、そして、それぞれが他のホスト上で実行されている引き継ぐためにモジュールを引き継ぐために、独自のリソースをホスト正常に動作を開始しますリソースやサービス、ユーザーにサービスを提供し続けること。通常の状況下では後に、それはより良いホストの障害を達成することができ、ビジネスは、サービスの中断なく提供（注：いわゆるビジネスの継続性を）続けることができます。スイッチング時間が必要とされ、フェイルオーバー時には、スイッチング時間は5〜20秒のハートビートです。（速く手動切替よりもサーバーのダウンタイムの切り替え）。
また、および高可用性ソフトウェアとしてkeepalivedの、ハートビートの高可用性オペレーティング・システム・レベルではなく、サービス（ソフトウェア）のレベルは、高可用性のサービスレベルを達成するために簡単なスクリプトで制御することができます！
一般的なフェイルオーバー条件：
1）物理ホストサーバがダウンした（壊れたハードウェア、オペレーティングシステム障害）
2）ハートビート障害サービスそれ自体が
2つのスタンバイ・サーバ間の断層線に接続されている3）
サービス障害が発生していないアプリケーション切り替え、缶ハートビートサービスは、サービスのダウンタイムによって停止しました。
ハートビート内部構造は3つの主要コンポーネントを有する
クラスタメンバ一貫管理モジュール（CCMを）メンバー間の分配ノードとリソースの間の関係を管理しながら、ハートビートモジュールを決定するために、一次および二次ノードの動作状態を検出するための責任があり、クラスタ・ノードのメンバーシップを管理しますノード障害かどうか。HA-のlogDモジュールは、クラスタ記録情報やサービス内のすべてのモジュールを実行するために使用されます。
ローカルリソースマネージャ（LRM）は、一般LRMにより、ローカルリソース、停止、およびモニターを開始する責任があるデーモンlrmd lrmdデーモンの間の通信からなる監視プロセス（STONITHデーモン）担当ノードであるノード、STONITHデーモンは通常フェンス装置であり、正常な状態のノードの状態監視のための主要なノード、ノードの問題は、IP、ディスクや他のリソースを解放するために再起動またはシャットダウンにフェンスデバイスを通過しますがある場合、リソースは常にノードですが、リソースの競合を防ぐために持っています。
三つの部分、クラスタ・ポリシー・エンジンからなるCRMデーモン、クラスタおよびクラスタポリシーエンジン転送エンジンによって同時に処理ノードとリソース間の依存関係のクラスタリソース管理モジュール（CRM）、リソースの管理ノードの用途、一般CRMD状態（クラスタポリシーエンジン）と引き継ぐために別のノード合理的リソース上のプロセスを調整するための責任を負うノードに障害が発生したCRMモジュールを監視し、これらの管理クラスタ転送エンジン（クラスタ遷移エンジン）の特定の実装に依存します。
クラスタ内のハートビート、コア部ハートビート監視部引き継ぎクラスタリソース管理モジュールとモジュール心拍、心拍数モニタは、典型的には2つのノード間で、シリアルラインを介してシリアルインタフェースによって行われ、シリアルラインを介してパケットを送信します相手が指定された時間内に送信されたメッセージを受信しない場合、他の側が失敗するだろうと、お互いに自分の現在の状態を伝えるために、モジュールは、他のホスト上のサービスの操作を引き継ぐためのリソース、またはリソースを引き継ぐために開始します。
ハートビートハートビート接続
可用性クラスタは、ハードウェアとソフトウェアを介して接続された独立したコンピュータのグループは、彼らは、ユーザーの前に単一のシステムとして振る舞うような内部コンピュータシステムを1つまたは複数のノードにサービス意志のセット作業を停止することです実行、適切に仕事に失敗したノードからノードスイッチング上でサービスの中断は発生しません。この定義からわかるように、クラスタノードとサービスは、回復が利用可能であるときに障害を検出しなければなりません。このタスクは、多くの場合、コードの「ハートビート」のグループによって行われていると呼ばれています。この機能は、ハートビートと呼ばれるプログラムによって達成されるのLinux-HAで。
上記の説明を通じて、ハートビートサービスを展開するために、あなたが完了するまでに、少なくとも二つのホストを必要としています。だから、2つのホスト間の高可用性サービスを実現するために、どのように互いを監視するために相互に通信していますか？
：ここで2つのホスト間の通信のいくつかの一般的な実用的な方法がハートビートである
）1）シリアルケーブル、即ちAいわゆるシリアルポート（好ましくは、欠点は、あまりにも遠くない
製造（直接接続されたイーサネットネットワークインターフェイスケーブルの量）2環境常法）
ラインが簡単に他のデータ送信の影響を受け、専用のハートビートないながら3）イーサネットケーブルは、増加した故障点に起因基（CI、良好なトラブルシューティングから選択されたネットワーク装置によって接続されたスイッチ、ハートビートパケットの問題）につながります
ハートビートスプリットブレイン
スプリットブレインとは何でしょうか？
特定の期間内の二つの高可用性サーバの間で、お互いにお互いを検出し、心拍フェイルオーバー機能を起動することはできませんので、それは両方の高可用性サーバがまだ生きているとメイクしている時に、資源や所有権のサービスを行っています紛争の深刻な問題は、最も深刻な2つのホストが同時にVIPアドレスを占有し、ユーザーが書き込むときのデータを個別に記述することができるということである一方、通常の操作では、これは湖の両端で同じIP統合サービスが開始につながります両端に、これはサーバー間でデータの矛盾やデータの損失につながることがあり、これはケーススプリットブレインとなり、一部の人々は、クラスタまたはパーティション垂直方向に離間脳を呼びます！
簡単に言えば、Hearbeatのスプリットブレイン発言があることで、両方のサービスが正常であるが、それはお互いに失われた接触するので、互いの鼓動（ハートビート通信障害）、スプリットブレインであるバウンドVIP、ある心拍2が検出されません、 2台のサーバーは、最も深刻な結果をリソースのための戦いを引き継ぐ本能：共有リソースが分割され、サービスが起動されていない、またはサービスがアップしていますが、共有リソースへの同時書き込みで、最終的にデータが壊れています！
これは、スプリットブレインが発生した原因：
一般的には、スプリットブレインが発生し、主に以下のいくつかの理由のために：
1）ハートビート可用性サーバ間の断層線を、通常の通信につながるありません。原因例：
1--ハートビート自体（破壊を含む老化）破壊され、
2--ネットワークカード及び関連するドライバが破壊され、IP構成の競合;
3--ハートビート接続との間の誤機器の故障（スイッチまたはNICの障害）;
問題のサーバー4--調停が発生します。
2）サーバの可用性は、ファイアウォールのブロックにハートビートメッセージの送信を開き、
サーバの可用性のハートビートネットワークカードアドレスに関する情報の3）の構成は、ハートビートを送信する故障が生じる、不正確である;
不適切4）他のサービスの構成および他の理由、等さまざまな方法のハートビート、ハートビート放送の競合は、ソフトウェアの不具合などがありました。
簡単に言えば、その理由はおそらく、スプリットブレインハートビートである：
1）適切に通信していないもたらすハートビートリンク障害;（例：ケーブルプルエラー、ハートビートが壊れているが、通信できない、中間デバイスとの間のハートビートが破壊され、アービトレーションデバイス悪い;）
2）ハートビートメッセージの送信ファイアウォールのブロックを開き、
3）心拍間違って構成されたネットワークカードアドレス、直接ネットワークを使用して、ネットワークカードドライバが壊れている、LAN IP競合;
4）ハートビートモードでは、ハートビート衝突をブロードキャストソフトウェアのバグ。
：スプリットブレインを防止するための方法が発生し
たときに、スプリットブレインの発生、およびビジネスへの影響は、深刻な、時には致命的です。
たとえば：スプリットブレインが同じIPリソースを相互に競争の中で、その結果、2台の高度に利用可能なサーバとの間で発生する、私たちのLAN IPアドレスの競合で共通として、のように、2台のマシンがユーザーに影響を与える1つまたは2つの正常でないを持っていますサーバーへの通常のアクセス。アプリケーションがデータベースまたは非常に重要なこのサービスの可用性に格納されている場合、それは断続的なデータを公開するユーザー、データ復旧、最終的に困難またはハードが再開しているために、両方のサーバーの影響で書き込みにつながる
実際の生産環境を：、我々は、以下の態様の発生は、脳分割防止することができる
シリアルケーブルやイーサネットケーブルを使用しながら、2行のハートビート、破線が、他のラインはまだ、まだ良好である）1メッセージ（推奨）送信することができる
2）を検出し、強制的にノードを閉じるスプリットブレインハートを（ノードは、STONITH、フェンスのように、特別な支援を必要とする）、ハートビート障害のスタンバイノード発見手順に対応し、主にシャットダウンコマンドを送信しますノード。
問題は人為的損失を低減、仲裁に介入することができますが発生した場合3）、など、電子メールやSMS、などスプリットブレイン（）にアラームを監視良い仕事をします。もちろん、実施形態の高可用性プログラムでは、そのような損失は、ビジネスの実際のニーズに応じて許容できるかどうかを決定します。平均的なビジネスのウェブサイトは、この損失は、制御可能（会社用）である
4）ディスクロックを有効にします。サービスでは、スプリットブレインが発生した場合、相手が完全に共有ディスクリソースを奪うことはできませんしましょう、共有ディスクロックの一つです。当事者が他の当事者は、共有ディスクを得ることはありませんロックを解除するには、共有ディスクのイニシアチブを取らない場合でも、ロックディスクを使用することは、大きな問題があります。実際に介入サービスが突然クラッシュしたりクラッシュしたノード、他の当事者は、ロック解除コマンドを実行することはできません。バックアップノードは共有リソースとアプリケーションサービスカットオフされることはありません。「スマート」ロックのHAに関わる一部の人々は、当事者がハートビートのサービスでのみ発見されたように、ロックがディスクを有効にした場合、すべての通常ロックされていない、オフになっています
5）アラームレポートは、サーバがアラーム時刻を処理するのに十分なスタッフを残すために、引き継ぐ前に1分ですが、サーバーを引き継ぐが、長い時間がかかった、5分後に引き継いません。データが失われることはありませんが、それは、ユーザーがデータを書き込むことができない原因になります。
6）アラーム後、は直接サーバが自動的に引き継ぎませんが、スタッフによって引き継が。
7）リソースを取得する必要があります誰が決定するための調停メカニズムの増加、および考慮すべきいくつかのアイデアがあります：
1--仲裁メカニズムを増やすには。このような参照IPを設定するなど、心が完全に壊れているとき、2つのノードがIPの参照について、それぞれのpingしている、それはあなたが競争をあきらめて、別のブレークポイントは、この段落に登場していることを示しているので、IPの基準端にpingを実行できますサービスを引き継ぎます。
2--リソースを取得した第三者によるソフトウェアの調停は、このアリは、同様のソフトウェアアプリケーションを持っています
簡潔には、スプリットブレインハートビート方法を防ぐ：
1）は、2つのハートビートを使用するように、シリアルケーブルやイーサネットケーブルを使用しながら、
スプリットブレインが検出された場合2）、強制停止ノードは（特別な機器のサポートが必要ハートビート障害を発見プログラムにstonishとフェンスのような）、スタンバイ・ノードの対応、マスタノードにシャットダウン指示を送信する;
3）良好に監視及び警告、（）調停装置で行われ、すなわち、良好なスプリットブレインモニタアラーム、アービトレーション停止撮影;
4）仲裁の複数（仲裁機器、ソフトウェア、サードパーティ製の調停、およびそのサービスを引き継ぐノードを決定させる）;
5）アラーム、SMSの電話通知運用・保守担当者と、サービスに自動的に担当者が操作するために、サービスを引き継ぐしないでください。
5）を有効ディスクロック。
ハートビート設定ファイル
：ハートビートメインの設定ファイル3がある
1）証明書類のauthkeys
2）メイン設定ファイルのha.cf
3）リソースファイルharesourcesは、
私たちは、次の3つの特定の機能や設定ファイルに焦点を当ててみましょう：
1）ハートビート認証プロファイルauthkeysを、次のように
認証1
1 CRC
！2 SHA1 HI
！3 MD5こんにちは
。このファイルは主に2つのクラスタノード用に使用されていますMD5、SHA1およびCRC：認証は、クラスタ内のノードで同じでなければなりませんアルゴリズムと鍵（もしあれば）を使用して、現在、3つのアルゴリズムを提供しています。
CRCが認証を提供しない、請求、それだけでパケットが破損しているかどうかを確認するために使用することができ、及びSHA1、MD5は、資源消費の観点からは、認証用の鍵を必要とする、よりMD5、SHA1がそう、その後消費しました私たちは、一般的な使用のSHA1アルゴリズムをお勧めします。
SHA1アルゴリズムを使用する場合は、単に、2 AUTHコマンド（コメント解除）をauthkeys 2と対応する行のSHA1が、後者は、そのキーを変更、コメントを解除（＃）が必要である（ノードの両方で同じでなければなりません）。設定が完了したら、あなたはファイルのプロパティを変更する必要があり、保存し、それ以外の場合は、ハートビートを開始するために失敗し、600です。
2）のメイン設定ファイルのha.cfハートビート
最初のものはha.cfこのファイルは、インストール後に作成/etc/ha.dディレクトリに格納されています。文書には、メディアを使用するために何をしてハートビートのためのアクセス情報にそれらを構成する方法を含んでいます。ソースディレクトリにHa.cfファイルは、以下に詳細に説明するように、あなたが使用できるすべてのオプションが含まれています。
debugfileは/ var / log / HA-デバッグ心拍記録するためのデバッグ情報
ログファイルは/ var / log / HA-ログログ情報の心拍を記録するための
ログファイルは上に定義されていない場合に、それはLOCAL0のログ情報を送信する（に対応＃/ var / log / messages）に 、 これらの3つのログファイルが定義されていない場合は、デフォルトでは、ハートビートは、
適切なログ情報を記録するためにログ/には/ var HA-デバッグおよびHA-ログを確立します。
あなたがある場合は秒で、デフォルトでは2の間隔でキープアライブの送信ハートビートパケットは、ミリ秒単位では、あなたは、このような1.5S表し1500msとしてms単位、続いする必要が
デッドタイム30が間隔から他のノードのヒヨスを考えて設定するために使用され
、最終的に発行したwarntime 10ハートビート警告メッセージインターバル
時間は120ネットワークブートをinitdead
UDPポート694、ブロードキャスト/ユニキャスト通信を使用UDPPORT
ハートビートで使用BCAST eth0のLinuxネットワークインタフェースを
ボー19200ボーの高速シリアル通信。
BCASTウカスト通信用ポート694および694の使用をUDPPORT。これがデフォルトであり、公式のIANAポート番号に登録されています。
MCAST eth0の225.0.0.1 694 1 0
マルチキャスト通信が使用される場合、マルチキャスト通信において、インタフェースは、マルチキャストアドレスIPバインディング＃設けられていてもよい-通信ポート（224.0.0.0で間239.255.255.255）を、 TTL（ライブまでの時間）は、（それがデータパケットを受信したとき、すなわちローカル問題）ループバックを許可するかどうか、＃ホップを経由してルーティングすることができます
ユニキャスト場合ウカストeth0の192.168.1.2、あなたはそのネットワークインタフェースとIPアドレスの使用を設定することができます
。このオプションのauto_failbackを設定する必要があります！移行は主のもの、または現在のノードの障害になるまで現在のノード上で実行し続けること：それは所有した後、リソースは回復の所有者は、リソース変更かどうかを決定するために使用されています。
共有リソースのためのSTONITH baytech /etc/ha.d/conf/stonith.baytechクラスタ環境、データの一貫性を確保するためのSTONITH防衛技術の使用
ウォッチドッグは/ dev /ウォッチドッグこのコマンドは、ノードが1分以内にハートビートされていない場合は、ウォッチドッグタイマを設定するために使用され、そのノードが再起動されます
ノードken3セットクラスタノード注：ノード名ははuname -nと一致する必要があります
ノードprimary.mydomain.comこのオプションを設定する必要があります。マシンのクラスタのホスト名は、「のuname -n」の出力は同じです。
ノードbackup.mydomain.comこのオプションを設定する必要があります。同上。
復活とはオプションの構成です：リストコマンドが実行され、監視されます。たとえば：CCMデーモンを実行するには、次の内容を追加する必要があります。
ピングの10.10.10.254
のping命令と次の命令を擬似ping_groupクラスタメンバーを確立するために使用されている、彼らは以下のipfail＃命令で使用されている必要があり、その役割は、物理リンクを、監視することで、クラスタノードとダミーデバイスの場合同じでない場合、ノードは、リソースやサービスを引き継ぐ権利はないだろう、それがリソースを解放しました。
リスポーンhaclusterは/ usr / libに/心拍 / CCM
それは死を再起動する場合は、（この場合はhaclusterとして）プロセスを実行するためのIDをユーザーIDとプロセスの実施を監視するためにハートビートを可能にします。
ipfailのために、それは次のようになります。
haclusterは/ usr / libに/ハートビート/ ipfail復活
pingdためには、次のようになります。
復活haclusterは/ usr / lib64に/ハートビート/ pingd 100 -m -d 5S
注：プロセスの終了は、終了コードが100である場合、それはプロセスを再起動しません。
apiauth pingd GID = haclientはuid = hacluster
クライアント名GID = apiauth gidlistはuid = uidlist
apiauth ipfailはuid = gidの= haclientあなたは権利のプロセスを開始するために指定した設定hacluster
3）ハートビートリソース構成ファイルharesources
構成ha.cfファイル一旦、ファイルがharesourcesあります。
文書には、サービスやクラスタ、主にクラスタを展開するためのリソースやサービスのファイルアロケーションが提供するサービスのデフォルトの所有者を示しています。
注：両方のクラスタノード上のファイルが同じでなければなりません。クラスタのIPアドレスを使用して、外部のharesourcesファイルのアドレスを設定することはできません、オプションを設定する必要がありますされ、マスターファイルには、IP、サブネットマスク、ブロードキャストアドレス、クラスタ、デュアルシステムharesourcesを指定するために使用され、サービスが開始されました。
次のようにそのアクティブラインのそれぞれをフォーマットすることである：
ノード名リソース1リソース2 ... resourceN
ノード名は、クラスタ内のノードの名前であり、同じのuname -nである必要があり
、各リソース1リソース2 ... resourceNのためのリソースのセットの後ろにリソースは、シェルスクリプト、その検索パス/etc/init.d/のと/usr/local/etc/ha.d/resource.d（パスはあなたがハートビートをインストールしたパスによって異なります）で、ハートビート申し出私たちに非常に優れたリソース拡張フレームワーク、私たちは自分のリソースを制御する必要がある場合は、サポートの開始と停止のパラメータにのみシェルスクリプトを達成する必要があることができ、現在はハートビートによってサポートされていますが、私のリソーススクリプトで提供することができますビューへのパス。
次のように説明する：
ノード名の設定・ネットワークの
ノード名は、デュアルシステムを指定し、前記マスターノードは、他のノードのホスト名のオプション設定でノードのホスト名ha.cfオプション設定ファイルの値と一致する必要がありますスレーブノードになります。指定したクラスタIP、サブネットマスク、ブロードキャストアドレスなどのネットワーク設定のためのネットワーク設定。ハートビートを設定するためのリソース・グループは、最終的にはデュアルシステムによっては、外部IPクラスタによって提供されたサービスを、開始します。この記事では、我々はあなたがApacheとサンバのためのHAサービスを設定することを前提としています。
：haresourcesに次の書類が必要
primary.mydomain.com 192.168.85.3のhttpd SMBを
ブート時にラインが、ノードlinuxha1は、IPアドレス192.168.85.3を取得し、Apacheとサンバを開始すること。停止した場合、ハートビートは、最初のピットストップのSMB、その後にApacheを停止し、最終的にIPアドレス192.168.85.3をリリースします。それは、「primary.mydomain.com」に「は、uname -n」コマンドの出力と仮定される-出力が「主」であるならば、それは「主」を使用する必要があります。
primary.mydomain.com IPADDR :: 192.168.21.107/24/eth0 drbddisk :: R0ファイルシステム ::は/ dev / drbd1 :: /データ:: ext4のNFS
適切に設定haresourcesファイル、ha.cfとharesourceにコピー/など/ ha.dディレクトリ。
注：実行可能なコマンドのリソースファイルがで/etc/ha.d/resource.d/に表示されなければなりません！