パート II 設定および管理 #
- 5 設定および管理の基本事項
HAクラスタの主な目的はユーザサービスの管理です。ユーザサービスの典型的な例は、Apache Webサーバまたはデータベースです。サービスとは、ユーザの観点からすると、指示に基づいて特別な何かを行うことを意味していますが、クラスタにとっては開始や停止できるリソースにすぎません。サービスの性質はクラスタには無関係なのです。
この章では、クラスタを管理するときに知っておく必要があるいくつかの基本的な概念について説明します。後続の各章では、SUSE Linux Enterprise High Availabilityが提供する各管理ツールを使用して、主要な設定および管理タスクを行う方法を説明します。
- 6 クラスタリソースの設定
クラスタの管理者は、クラスタ内のサーバ上の各リソースや、サーバ上で実行する各アプリケーションに対してクラスタリソースを作成する必要があります。クラスタリソースには、Webサイト、メールサーバ、データベース、ファイルシステム、仮想マシン、およびユーザが常時使用できるその他のサーバベースのアプリケーションまたはサービスなどが含まれます。
- 7 リソース制約の設定
すべてのリソースを設定する以外にも、多くの作業が必要です。クラスタが必要なすべてのリソースを認識しても、正しく処理できるとは限りません。リソースの制約を指定して、リソースを実行可能なクラスタノード、リソースのロード順序、特定のリソースが依存している他のリソースを指定することができます。
- 8 クラスタリソースの管理
クラスタ内でリソースを設定したら、クラスタ管理ツールを使用して、リソースを起動、停止、クリーンアップ、削除、または移行します。この章では、リソース管理タスクにHawk2またはcrmshを使用する方法について説明します。
- 9 リモートホストでのサービスの管理
リモートホストでサービスを監視および管理できることが、ここ数年の間にますます重要になってきています。SUSE Linux Enterprise High Availability 11 SP3では、監視プラグインを介したリモートホストでのサービスの詳細な監視機能を提供してきました。SUSE Linux Enterprise High Availability 15 SP6では、最近追加された
pacemaker_remote
サービスを使用すると、リモートマシンにクラスタスタックをインストールしていなくても、実際のクラスタノードと同様にリモートホストでリソースを全面的に管理および監視できます。- 10 リソースエージェントの追加または変更
クラスタによる管理が必要なすべての作業は、リソースとして使用できなければなりません。主要なグループとして、リソースエージェントとSTONITHエージェントの2つがあります。両方のカテゴリで、エージェントの追加や所有が可能で、クラスタ機能を各自のニーズに合わせて拡張することができます。
- 11 クラスタの監視
この章では、クラスタのヘルスを監視し、その履歴を表示する方法について説明します。
- 12 フェンシングとSTONITH
フェンシングはHA (High Availability)向けコンピュータクラスタにおいて重要なコンセプトです。クラスタがノードの1つの誤動作を検出し、そのノードの削除が必要となることがあります。これをフェンシングと呼び、一般にSTONITHリソースで実行されます。フェンシングは、HAクラスタを既知の状態にするための方法として定義できます。
クラスタのすべてのリソースには、それぞれ状態が関連付けられています。たとえば、「リソースr1はaliceで起動されている」などです。HAクラスタでは、このような状態は「リソースr1はalice以外のすべてのノードで停止している」ことを示します。クラスタは各リソースが1つのノードでのみ起動されるようにするためです。各ノードはリソースに生じた変更を報告する必要があります。つまり、クラスタの状態は、リソースの状態とノードの状態の集まりです。
ノードまたはリソースの状態を十分に確定することができない場合には、フェンシングが発生します。クラスタが所定のノードで起こっていることを認識しない場合でも、フェンシングによって、そのノードが重要なリソースを実行しないようにできます。
- 13 ストレージ保護とSBD
SBD (STONITH Block Device)は、共有ブロックストレージ(SAN、iSCSI、FCoEなど)を介したメッセージの交換を通じて、Pacemakerベースのクラスタのノードフェンシングメカニズムを提供します。これにより、フェンシングメカニズムが、ファームウェアバージョンの変更や特定のファームウェアコントローラへの依存から切り離されます。動作異常のノードが本当に停止したかどうかを確認するために、各ノードではウォッチドッグが必要です。特定の条件下では、ディスクレスモードで実行することにより、共有ストレージなしでSBDを使用することもできます。
クラスタブートストラップスクリプトは、フェンシングメカニズムとしてSBDを使用するオプションを使用してクラスタを設定する自動化された方法を提供します。詳細については、インストールとセットアップクイックスタートを参照してください。ただし、SBDを手動で設定する場合、個々の設定に関するオプションが増えます。
この章では、SBDの背後にある概念について説明します。スプリットブレインシナリオの場合に潜在的なデータ破損からクラスタを保護するために、SBDが必要とするコンポーネントを設定する手順を説明します。
ノードレベルのフェンシングに加えて、LVM排他アクティブ化やOCFS2ファイルロックのサポート(リソースレベルのフェンシング)など、ストレージ保護のための追加のメカニズムを使用することができます。これにより、管理上またはアプリケーション上の障害からシステムが保護されます。
- 14 QDeviceおよびQNetd
QDeviceおよびQNetdはクォーラムの決定に参加します。アービトレータ
corosync-qnetd
からの支援により、corosync-qdevice
は設定可能な投票数を提供するため、クラスタは標準のクォーラムルールで許可されているよりも多くのノード障害に耐えることができます。ノード数が偶数であるクラスタ、特に2ノードクラスタについては、corosync-qnetd
およびcorosync-qdevice
の展開をお勧めします。- 15 アクセス制御リスト
crmシェル(crmsh)またはHawk2などのクラスタ管理ツールは、
root
ユーザまたはhaclient
グループ内のユーザが使用できます。デフォルトで、これらのユーザは完全な読み込み/書き込みのアクセス権を持ちます。アクセスを制限するか、または詳細なアクセス権を割り当てるには、「アクセス制御リスト」(ACL)を使用できます。アクセス制御リストは、順序付けされたアクセスルールセットで構成されています。各ルールにより、クラスタ設定の一部への読み込みまたは書き込みアクセスの許可、またはアクセスの拒否が行われます。ルールは通常、組み合わせて特定の役割を生成し、ユーザを自分のタスクに一致する役割に割り当てることができます。
- 16 ネットワークデバイスボンディング
多くのシステムで、通常のEthernetデバイスの標準のデータセキュリティ/可用性の要件を超えるネットワーク接続の実装が望ましいことがあります。その場合、数台のEthernetデバイスを集めて1つのボンディングデバイスを設定できます。
- 17 負荷分散
「負荷分散」によって、外部のクライアントからは、サーバのクラスタが1つの大きな高速サーバであるかのように見えます。この単一サーバのように見えるサーバは、仮想サーバと呼ばれます。このサーバは、着信要求をディスパッチする1つ以上のロードバランサと実際のサービスを実行しているいくつかの実際のサーバで構成されます。SUSE Linux Enterprise High Availabilityの負荷分散設定によって、高度にスケーラブルで可用性の高いネットワークサービス(Web、キャッシュ、メール、FTP、メディア、VoIPなど)を構築できます。
- 18 仮想化のための高可用性
この章では、仮想マシンを可用性の高いクラスタリソースとして設定する方法を説明します。
- 19 Geoクラスタ(マルチサイトクラスタ)
SUSE® Linux Enterprise High Availability 15 SP6は、ローカルクラスタとメトロエリアクラスタのほかに、地理的に離れたクラスタ(Geoクラスタ。マルチサイトクラスタとも呼ばれます)もサポートしています。これは、それぞれ1つのローカルクラスタで持った複数の地理的に離れたサイトを持てることを意味します。これらクラスタ間のフェールオーバーは、より高いレベルのエンティティである
booth
によって管理されます。Geoクラスタの使用方法と設定方法の詳細については、GeoクラスタリングのクイックスタートとGeo Clustering Guideを参照してください。