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