クラスターは、共有ソリューションを提供するために連携して動作するコンピューター（ノード）のグループです。大まかに言えば、クラスターは3つの部分（クラスタースタックとして定義されることが多い）で構成されていると見なすことができます。
- リソース： これらが、クラスターが高可用性を維持する必要のあるサービスである理由です。
- リソースエージェント： これらは、一連のリソースパラメータを指定して、リソースを開始、停止、および監視するスクリプトオペレーティングシステムコンポーネントです。
- フェンスエージェント： これらは、ターゲットとフェンスデバイスを指定して、ノードフェンシングアクションを実行するスクリプトです。
- フェンシング： ノードを無効にする機能。
- 定足数： クラスタが安全に動作し続けることができるかどうかを判断する機能をカプセル化します。
4つのタイプは次のとおりです。
- 高可用性（HA）： フォールトトレランスに使用され、サーバーサービスを従業員または顧客が利用できるようにします。
- 負荷分散： 一度に多数のシステムでサービスを利用できるようにする必要がある場合は、複数のシステム間で負荷を分散します（他の3種類のクラスターで使用できます）。
- 分散： ジョブはさまざまなシステムによって管理されます。
- パラレル（ベオウルフ）： ジョブは、複数のシステム上の複数のプロセッサによって管理されます。
構成によっても、クラスターにはいくつかのタイプがあります。
- 手動クラスタリング： 自動スパイクソートアルゴリズムの出力が不十分な場合は、クラスターを手動で分類、マージ、分割できます。
- クラスターのマージ： 複数のクラスターが同じユニットに対応しているように見える場合。
- クラスターの分割： フィーチャビュー、振幅ビュー、テンプレート振幅ビュー、またはスパイク属性ビューのスパイクのセットの周りにポリゴンを描画することで、新しいクラスターを作成できます。
注： ここRackspaceでは、主にHAを使用し、場合によってはLBクラスターを使用します。 Rackspaceでは、RHEL6ではRedHat Cluster Suite（RHCS）という用語を使用し、RHEL7ではPacemakerConfiguration System csdデーモンデーモン（PCS）という用語を使用して、クラスターノード間の接続を提供し、クラスター化されたサービスのプラットフォームを提供します。
クラスタースイートは、クラスターを構築、構成、および制御するためのツールを提供します。
クラスターを使用する理由はいくつかあります。これらを使用して、ソリューションの復元力と可用性の高いバックエンドを提供します。これは主に、サービスがWebサーバーのフロントエンドの背後にある可能性があるMySQL、NFS、Redisなどのバックエンドサービス用です。
自動フェイルオーバーによって高可用性が提供されます。クラスターノードで障害が発生した場合、そのノードで実行されているクラスター化されたサービスは、適切に実行されているノードに自動的に再配置されます。
クラスタは通常、共有ストレージ（SAN）を使用するため、サービスがノード間を移動するときにデータが永続的になります。
ノードが応答しなくなった場合、通常、共有ストレージのデータ整合性とフローティングIPの所有権を維持するために、そのノードは他のノードによって再起動（フェンス）されます。
Linuxオープンソースの高可用性クラスタリング
一部のLinuxオペレーティングシステムベンダーは、SUSELinuxHAEなどのクラスタリングソフトウェアを提供しています。 Red Hat Enterprise Linux（RHEL）;およびOracleRealApplication Clusters（RAC）。
フェールオーバークラスターを作成することはできますが、さまざまな課題がありますが、これは非常に手動であり、人的エラーが発生しやすくなります。
LinuxのオープンソースHA拡張機能には高度な技術スキルが必要であり、ほとんどのオペレーターが直面する複雑さと信頼性の問題が発生します。
SUSE LinuxEnterpriseServerとRedHatEnterprise Linuxはどちらのソリューションも、SANとSANlessの両方の環境を提供しますが、SANless環境でのデータ複製をサポートするには、DRBDと呼ばれる複製ソフトウェアをOSにインストールして構成する必要があります。残念ながら、これには大量のカスタムスクリプトが必要であり、テストと検証に長い時間がかかる可能性があり、環境に更新が行われたときに再テストする必要があります。これらの企業は何よりもまずオペレーティングシステム企業であるため、サポートはオペレーティングシステムレベルの問題に向けられており、多くの場合、顧客の問題を支援するHAの専門知識はほとんどまたはまったくありません。
Oracle Reakアプリケーションクラスター（RAC）
Oracle RACは高可用性ソリューションですが、主にデータベース管理層向けに設計されています。つまり、アプリケーション層の監視、管理、およびリカバリを行うコンポーネントには、別のHAソリューションが必要になります。 Oracle RACも非常に高価であるため、SIOS Protection Suiteなどの他のLinuxクラスタリングソリューションと比較すると、RACオプションの料金に加えて、OracleEnterpriseEditionにアップグレードする必要があります。
Linuxクラスタリング用SIOS保護スイート
SIOS Protection Suite for Linuxは、高可用性フェールオーバークラスタリング、継続的なアプリケーションモニタリング、データレプリケーション、および構成可能なリカバリポリシーの緊密に統合された組み合わせを提供し、ビジネスクリティカルなアプリケーションをダウンタイムや災害から保護します。 SIOS Protection SuiteはSAN環境で動作して、従来のHAハードウェアベースのクラスターをサポートできますが、アーキテクチャはサーバークラスタリングに対してシェアードナッシングアプローチを採用しているため、SANなしで実行できます。さまざまなアプリケーション向けの自動および手動のフェイルオーバー/フェイルバックリカバリポリシーを備えた、堅牢で用途が広く、簡単に構成可能なソリューションを提供します。
Linux用SIOSProtectionSuiteには、次のものが含まれます。
- SIOS LifeKeeper： アプリケーションスタック全体を監視する柔軟なフェールオーバークラスタリングソフトウェアを提供します。
- SIOS DataKeeper： SANlessクラスタ構成でローカルストレージをミラーリングしたり、ディザスタリカバリのためにリモートロケーションやクラウドにレプリケーションしたりするための、高速で効率的なホストベースのブロックレベルのデータレプリケーションを提供します。
- 複数のアプリケーション回復キット（ARK）： 自動化された構成および検証ツールが製品に組み込まれており、ビジネスクリティカルなアプリケーションとデータをダウンタイムや災害から保護します。
SUSE、Red Hat、およびOracleが提供するLinuxクラスタリングソリューションと比較して、アプリケーションのリカバリとソリューションのアプリケーションの監視とリカバリの自動化に関するSIOSチームの深い知識により、使いやすく、より適切で安価な選択肢になります。
さらに、SIOS LifeKeeperは、Red Hat Enterprise Linux、SUSE Linux Enterprise Server、CentOS、およびOracle Linuxを含むすべての主要なLinuxディストリビューションをサポートし、幅広いストレージアーキテクチャに対応します。 SIOSソフトウェアは、これらのオペレーティングシステムで実行するように適合および最適化されており、コンポーネントがテストされているため、SANlessクラスターソリューションが各OSで機能することを確認してください。
最後に、SIOS Protection Suite for Linuxを使用すると、パフォーマンス、高可用性、または災害保護を犠牲にすることなく、Amazon Web Services（AWS）などの柔軟でスケーラブルなクラウド環境でビジネスクリティカルなアプリケーションを実行できます。
AWSでのLinuxクラスタリング
AWSなどのクラウドプロバイダーは高可用性オプションを提供しますが、顧客が要求し、クラウドコンピューティングの前にクラスターを使用することで達成した、アプリケーションインフラストラクチャ全体にわたる高可用性のレベルと幅広い保護を提供しません。これが、AWSがSIOSと提携している理由です。 SIOS Protection Suite for Linuxは、相互のお客様と、AWSクラウドに移行する重要なアプリケーションに対してこれらの望ましいレベルの高可用性を実現します。
SIOS Protection Suite for Linux on AWSは、2つのアベイラビリティーゾーンにまたがる単一のAWSリージョン内の仮想プライベートクラウド（VPC）に高可用性Linuxクラスターを作成するために必要なすべての要素を提供します。また、SAPシステム、Oracleデータベース、およびその他のビジネスクリティカルなアプリケーションのすぐに使用できる保護もサポートしています。
SIOSとAWSは、AWSでSIOS Protection Suiteクイックスタートを提供します。これは、完全に構成され、運用可能なLinux高可用性クラスターをいくつかの短い手順で作成するのに役立ちます。 Linux用のSIOSProtectionSuite用のAWSアーキテクチャをセットアップし、約30分でAWSアカウントにデプロイします。 AWS Marketplaceで入手できるこのクイックスタートは、SIOS Protection Suite for LinuxonAWSをテスト環境または本番環境にデプロイしたいエンタープライズユーザーを対象としています。
Linux用のSIOSクラスタリング
SIOSは、SAP、SQL、Linux、Oracle、およびその他のアプリケーション向けに特別に設計されたHAの提供に過去20年間注力してきた高可用性企業です。その経験は製品に組み込まれており、Linuxディストリビューションを使用したカスタムスクリプトと比較した場合、インストールと構成にかかる時間とコストはわずかです。さらに、SIOSは、オペレーティングシステムとアプリケーションの新しいバージョンをテストおよび検証するため、顧客はその必要がありません。顧客がSIOSにサポートを求めると、高可用性の専門家、つまりHAのみに焦点を当て、非常に長い間そうしている専門家につながります。
Linuxで最も使用されるソフトウェアは、ペースメーカーです。
高可用性アドオンクラスターインフラストラクチャは、コンピューターのグループ（ノードまたはメンバーと呼ばれる）がクラスターとして連携するための基本機能を提供します。クラスターインフラストラクチャを使用してクラスターが形成されると、他のコンポーネントを使用してクラスター化のニーズに合わせることができます（たとえば、GFS2ファイルシステムでファイルを共有するためのクラスターのセットアップやサービスフェイルオーバーのセットアップ）。クラスタインフラストラクチャは、次の機能を実行します。
- クラスター管理。
- ロック管理。
- フェンシング。
- クラスター構成管理。
Pacemakerで構成されたクラスターは、クラスターメンバーシップを監視する個別のコンポーネントデーモン、サービスを管理するスクリプト、および異種リソースを監視するリソース管理サブシステムで構成されます。次のコンポーネントがPacemakerアーキテクチャを形成します。
クラスター情報ベース（CIB）
Pacemaker情報デーモン。XMLを内部的に使用して、指定コーディネーター（DC）からの現在の構成およびステータス情報を配布および同期します。これは、CIBを使用してクラスターの状態とアクションを保存および配布するためにPacemakerによって割り当てられたノードです。
クラスターリソース管理デーモン（CRMd）
Pacemakerクラスターリソースアクションは、このデーモンを介してルーティングされます。 CRMdによって管理されるリソースは、クライアントシステムによって照会され、移動、インスタンス化され、必要に応じて変更されます。
各クラスターノードには、CRMdとリソース間のインターフェイスとして機能するローカルリソースマネージャーデーモン（LRMd）も含まれています。 LRMdは、ステータス情報の開始、停止、中継などのコマンドをCRMdからエージェントに渡します。
頭の中の他のノードを撃つ（STONITH）
多くの場合、電源スイッチと組み合わせて展開されるSTONITHは、フェンスリクエストを処理するPacemakerのクラスターリソースとして機能し、ノードの電源を強制的にオフにしてクラスターから削除し、データの整合性を確保します。 STONITHはCIBで構成されており、通常のクラスターリソースとして監視できます。
corosyncは、高可用性クラスターのコアメンバーシップとメンバー通信のニーズに対応するコンポーネント（および同じ名前のデーモン）です。高可用性アドオンが機能するために必要です。
これらのメンバーシップおよびメッセージング機能に加えて、corosyncは次の機能も備えています。
クォーラムルールと決定を管理します。
クラスタの複数のメンバー間で調整または動作するアプリケーションにメッセージング機能を提供するため、インスタンス間でステートフルまたはその他の情報を通信する必要があります。
Pacemakerは、クラスターの展開、監視、および管理のための2つの構成ツールを備えています。
PCSは、PacemakerとCorosyncハートビートデーモンのすべての側面を制御できます。コマンドラインベースのプログラムであるpcsは、次のクラスター管理タスクを実行できます。
- Pacemaker/Corosyncクラスターを作成して構成します。
- 実行中にクラスターの構成を変更します。
- PacemakerとCorosyncの両方をリモートで構成し、クラスターのステータス情報を開始、停止、表示します。
pcsd Web UI
コマンドラインベースのPCユーティリティと同じ機能を備えたPacemaker/Corosyncクラスターを作成および構成するためのグラフィカルユーザーインターフェイス。
クラスターの整合性と可用性を維持するために、クラスターシステムは、クォーラムと呼ばれる概念を使用して、データの破損と損失を防ぎます。クラスターノードの半分以上がオンラインの場合、クラスターにはクォーラムがあります。障害によるデータ破損の可能性を軽減するために、クラスターにクォーラムがない場合、Pacemakerはデフォルトですべてのリソースを停止します。
クラスタシステムでは、いくつかの重要な本番データを処理する多くのノードが存在する可能性があります。ビジーなマルチノードクラスター内のノードは、不規則に動作し始めたり、使用できなくなったりして、管理者によるアクションを促す可能性があります。誤ったクラスターノードによって引き起こされる問題は、フェンシングポリシーを確立することで軽減できます。
Pacemakerは、ノードに障害が発生したと判断すると、ノードに障害が発生したことを他のクラスターインフラストラクチャコンポーネントと通信します。 STONITHは、障害が通知されると、障害が発生したノードをフェンスします。他のクラスターインフラストラクチャコンポーネントは、実行する必要のあるリカバリの実行など、実行するアクションを決定します。たとえば、DLMとGFS2は、ノードの障害が通知されると、STONITHが障害のあるノードのフェンシングを完了したことを検出するまで、アクティビティーを一時停止します。障害が発生したノードがフェンシングされていることを確認すると、DLMとGFS2はリカバリーを実行します。 DLMは、障害が発生したノードのロックを解放します。 GFS2は、障害が発生したノードのジャーナルを回復します。
STONITHを介したノードレベルのフェンシングは、以下を含む、サポートされているさまざまなフェンスデバイスを使用して構成できます。
- 無停電電源装置（UPS）： 停電時にデバイスをフェンスするために使用できるバッテリーを含むデバイス。
- 配電ユニット（PDU）： データセンターで使用される複数の電源コンセントを備えたデバイスで、クリーンな配電、フェンシング、および電源分離サービスを提供します。
- ブレード電源制御デバイス： 障害が発生した場合にクラスターノードをフェンスするように構成されたデータセンターにインストールされた専用システム。
- 消灯デバイス： クラスタノードの可用性を管理し、フェンシング、電源のオン/オフ、および管理者によるその他のサービスをローカルまたはリモートで実行できるネットワーク接続デバイス。
RedHat高可用性アドオンリソースクラス
Red Hat高可用性アドオンでサポートされているリソースエージェントにはいくつかのクラスがあります：
- LSB： Linux Standards Baseエージェントは、LSBでサポートされている準拠サービス、つまり/etc/init.d内のサービスと、成功および失敗したサービス状態（開始、停止、実行ステータス）の関連するリターンコードを抽象化します。
- OCF： Open Cluster Frameworkは、サーバー初期化スクリプトの作成と実行、環境変数を使用したスクリプトの入力パラメーターなどの標準を設定するLSB（Linux Standards Base）のスーパーセットです。
- systemd： Linuxベースのシステム用の最新のシステムサービスマネージャーであるsystemdは、LSBやOCFのように初期化スクリプトではなく、ユニットファイルのセットを使用します。これらのユニットは、管理者が手動で作成することも、サービス自体が作成および管理することもできます。 Pacemakerは、OCFまたはLSBの初期化スクリプトを管理するのと同様の方法でこれらのユニットを管理します。
- スタートアップ： systemdと同様に、UpstartはLinuxの代替システム初期化マネージャーです。 Upstartは、systemdまたはinitスクリプトのユニットではなく、ジョブを使用します。
- STONITH： STONITHを使用するフェンシングサービスおよびフェンスエージェント専用のリソースエージェント。
- Nagios： Nagiosシステムおよびインフラストラクチャ監視ツールのプラグインを抽象化するエージェント。
リソースの正常性を維持するために、リソースの定義に監視操作を追加できます。リソースの監視操作を指定しない場合、デフォルトでは、pcsコマンドはリソースエージェントによって決定された間隔で監視操作を作成します。
制約を構成することにより、クラスター内のリソースの動作を判別できます。次のカテゴリの制約を構成できます。
- 場所の制約： 場所の制約により、リソースを実行できるノードが決まります。
- 注文の制約： 順序制約は、リソースが実行される順序を決定します。
- 場所の制約： コロケーション制約は、他のリソースと比較してリソースが配置される場所を決定します。
リソースのセットを一緒に配置し、リソースが順番に開始し、逆の順序で停止することを保証する一連の制約を構成するための省略形として、Pacemakerはリソースグループの概念をサポートします。
クラスターの最も一般的な要素の1つは、一緒に配置し、順番に開始し、逆の順序で停止する必要があるリソースのセットです。この構成を簡素化するために、Pacemakerはグループの概念をサポートしています。
pcs resourceコマンドを使用してリソースグループを作成し、グループに含めるリソースを指定します。グループが存在しない場合、このコマンドはグループを作成します。グループが存在する場合、このコマンドはグループに追加のリソースを追加します。リソースは、このコマンドで指定した順序で開始され、開始順序の逆の順序で停止します。
- クラスターコンポーネント-Clusterlabs
- スプリットブレインシンドローム-Techtarget
- Linuxクラスタリング-SIOS
- クラスタリング-phy
- Linuxクラスター-Linux.org
- クラスターの概要-LinuxBlimp
- ペースメーカーの概要-RedHat
コメントや質問をするには、[フィードバック]タブを使用します。私たちと会話を始めることもできます。