SUSE Linux Enterprise High Availability Extensionドキュメント

SUSE Linux Enterprise
High Availability
Extension
11 SP4
2015 年 7 月 08 日
www.suse.com
高可用性ガイド
高可用性ガイド
著者: Tanja Roth, Thomas Schraitle
Copyright © 2006–2015 SUSE LLC and contributors. All rights reserved.
この文書は、GNUフリー文書ライセンスのバージョン1.2または(オプションとして)バー
ジョン1.3の条項に従って、複製、頒布、および/または改変が許可されています。ただし、
この著作権表示およびライセンスは変更せずに記載すること。ライセンスバージョン1.2の
コピーは、「GNUフリー文書ライセンス」セクションに含まれています。
SUSEおよびNovellの商標については、商標とサービスマークの一覧http://www.novell
.com/company/legal/trademarks/tmlist.htmlを参照してください。他のすべて
の第三者の商標は、各商標権者が所有しています。商標記号(®、™など) は、SUSEまたは
Novellの商標を示し、アスタリスク(*)は、サードパーティの商標を示します。
本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対
に正確であることを保証するものではありません。SUSE LLC、その関係者、著者、翻訳
者のいずれも誤りまたはその結果に対して一切責任を負いかねます。
目次
このガイドについて
xi
1 フィードバック .................................................................................. xii
2 マニュアルの表記規則 ...................................................................... xiii
3 本マニュアルの作成について ............................................................ xiii
I インストールおよびセットアップ
1
1 製品の概要
3
1.1 アドオン/拡張としての可用性 ........................................................... 3
1.2 主な機能 ............................................................................................ 4
1.3 利点 ................................................................................................... 8
1.4 クラスタ設定: ストレージ ................................................................ 12
1.5 アーキテクチャ ............................................................................... 15
2 システム要件と推奨事項
19
2.1 ハードウェア要件 ............................................................................ 19
2.2 ソフトウェアの必要条件 ................................................................. 20
2.3 ストレージ要件 ............................................................................... 20
2.4 その他の要件と推奨事項 ................................................................. 21
3 インストールと基本セットアップ
25
3.1 用語の定義 ...................................................................................... 25
3.2 概要 ................................................................................................. 29
3.3 アドオンとしてのインストール ....................................................... 30
3.4 自動のクラスタセットアップ(sleha-bootstrap) ................................... 31
3.5 手動のクラスタセットアップ(YaST) ................................................ 37
3.6 AutoYaSTによる大量展開 ................................................................. 54
II 設定および管理
57
4 設定および管理の基本事項
59
4.1 グローバルクラスタオプション ....................................................... 59
4.2 クラスタリソース ............................................................................ 62
4.3 リソース監視 ................................................................................... 79
4.4 リソースの制約 ............................................................................... 80
4.5 リモートホストでのサービスの管理 ................................................ 91
4.6 システムヘルスの監視 ..................................................................... 95
4.7 メンテナンスモード ........................................................................ 97
4.8 その他の情報 ................................................................................... 98
5 クラスタリソースの設定と管理(Webインタフェース)
101
5.1 Hawk - 概要 .................................................................................... 101
5.2 グローバルクラスタオプションの設定 ........................................... 108
5.3 クラスタリソースの設定 ................................................................ 110
5.4 クラスタリソースの管理 ................................................................ 132
5.5 複数のクラスタの監視 ................................................................... 146
5.6 GeoクラスタのＨａｗｋ ................................................................. 149
5.7 トラブルシューティング ................................................................ 150
6 クラスタリソースの設定と管理(GUI)
153
6.1 Pacemaker GUI - 概要 ...................................................................... 154
6.2 グローバルクラスタオプションの設定 ........................................... 157
6.3 クラスタリソースの設定 ................................................................ 158
6.4 クラスタリソースの管理 ................................................................ 181
7 クラスタリソースの設定と管理(コマンドライン)
189
7.1 crmsh - 概要 .................................................................................... 190
7.2 グローバルクラスタオプションの設定 ........................................... 198
7.3 クラスタリソースの設定 ................................................................ 199
7.4 クラスタリソースの管理 ................................................................ 212
7.5 cib.xmlから独立したパスワードの設定 ...................................... 217
7.6 履歴情報の取得 .............................................................................. 217
7.7 詳細 ............................................................................................... 219
8 リソースエージェントの追加または変更
221
8.1 STONITHエージェント .................................................................. 221
8.2 OCFリソースエージェントの作成 .................................................. 222
8.3 OCF戻りコードと障害回復 ............................................................ 223
9 フェンシングとSTONITH
227
9.1 フェンシングのクラス ................................................................... 227
9.2 ノードレベルのフェンシング ......................................................... 228
9.3 STONITHのリソースと環境設定 .................................................... 230
9.4 フェンシングデバイスの監視 ......................................................... 234
9.5 特殊なフェンシングデバイス ......................................................... 235
9.6 基本的な推奨事項 .......................................................................... 237
9.7 詳細 ............................................................................................... 238
10 アクセス制御リスト
239
10.1 要件と前提条件 ............................................................................ 240
10.2 クラスタでのACLの使用の有効化 ................................................ 241
10.3 ACLの基\'96\'7b事項 ..................................................................... 241
10.4 Pacemaker GUIによるACLの構成 .................................................. 244
10.5 HawkによるACLの設定 ................................................................ 246
10.6 crmshによるACLの設定 ................................................................ 248
11 ネットワークデバイスボンディング
251
11.1 YaSTによるボンディングデバイスの設定 ..................................... 251
11.2 ボンディングスレーブのホットプラグ ......................................... 255
11.3 その他の情報 ................................................................................ 257
12 Linux仮想サーバによる負荷分散
259
12.1 概念の概要 ................................................................................... 259
12.2 YaSTによるIP負荷分散の設定 ...................................................... 262
12.3 追加設定 ...................................................................................... 268
12.4 その他の情報 ............................................................................... 268
13 Geoクラスタ(マルチサイトクラスタ)
III ストレージおよびデータレプリケーション
14 OCFS2
271
273
275
14.1 特長と利点 ................................................................................... 275
14.2 OCFS2のパッケージと管理ユーティリティ .................................. 276
14.3 OCFS2サービスとSTONITHリソースの設定 ................................. 278
14.4 OCFS2ボリュームの作成 .............................................................. 280
14.5 OCFS2ボリュームのマウント ....................................................... 283
14.6 OCFS2ファイルシステム上でクォータを使用する ....................... 285
14.7 詳細情報 ...................................................................................... 285
15 DRBD
287
15.1 概念の概要 ................................................................................... 287
15.2 DRBDサービスのインストール .................................................... 289
15.3 DRBDサービスの設定 .................................................................. 290
15.4 DRBDサービスのテスト ............................................................... 297
15.5 DRBDのチューニング .................................................................. 299
15.6 DRBDのトラブルシュート ........................................................... 300
15.7 詳細情報 ...................................................................................... 302
16 Cluster Logical Volume Manager(cLVM)
303
16.1 概念の概要 ................................................................................... 303
16.2 cLVMの環境設定 .......................................................................... 304
16.3 有効なLVM2デバイスの明示的な設定 .......................................... 315
16.4 詳細 ............................................................................................. 316
17 ストレージ保護
317
17.1 ストレージベースのフェンシング ................................................ 318
17.2 排他的ストレージアクティベーションの確保 .............................. 327
17.3 その他の情報 ............................................................................... 329
18 Sambaクラスタリング
331
18.1 概念の概要 ................................................................................... 331
18.2 基本的な設定 ............................................................................... 333
18.3 Active Directoryドメインへの追加 ................................................. 335
18.4 クラスタ対応Sambaのデバッグとテスト ...................................... 337
18.5 その他の情報 ............................................................................... 339
19 Rearによる障害復旧
341
19.1 概念の概要 ................................................................................... 341
19.2 Rearおよびバックアップソリューションのセットアップ ............. 346
19.3 復旧インストールシステムの作成 ................................................ 348
19.4 復旧プロセスのテスト ................................................................. 348
19.5 障害からの復旧 ............................................................................ 349
19.6 その他の情報 ............................................................................... 350
IV 付録
20 トラブルシューティング
351
353
20.1 インストールと最初のステップ ................................................... 353
20.2 ログ記録 ...................................................................................... 354
20.3 リソース ...................................................................................... 357
20.4 STONITHとフェンシング ............................................................. 359
20.5 その他 .......................................................................................... 360
20.6 その他の情報 ............................................................................... 362
A 命名規則
363
B 単純なテストリソースのセットアップ例
365
B.1 GUIによるリソースの設定 ............................................................ 365
B.2 リソースの手動設定 ...................................................................... 367
C OCFS2およびcLVMの設定例
369
D クラスタ管理ツール
371
E クラスタアップグレードとソフトウェアパッケージの更新
375
E.1 用語集 ........................................................................................... 375
E.2 最新の製品バージョンへのクラスタアップグレード ..................... 376
E.3 クラスタノード上のソフトウェアパッケージの更新 ..................... 385
E.4 その他の情報 ................................................................................. 386
F 新機能
387
F.1 バージョン10 SP3からバージョン11への変更点 ............................. 387
F.2 バージョン11からバージョン11 SP1への変更点 ............................. 391
F.3 バージョン11 SP1からバージョン11 SP2への変更点 ....................... 393
F.4 バージョン11 SP2からバージョン11 SP3への変更点 ....................... 395
F.5 バージョン11 SP3からバージョン11 SP4への変更点 ....................... 398
用語集
......................................................................... 403
G GNU利用許諾契約書
411
G.1 GNU Free Documentation License ..................................................... 411
このガイドについて
SUSE® Linux Enterprise High Availability Extensionは、オープンソースクラスタ
化技術の統合スイートで、可用性の高い物理Linuxクラスタと仮想Linuxクラス
タを実装できます。構成と管理をすばやく効率的に行うため、High Availability
Extensionにはグラフィカルユーザインタフェース(GUI)とコマンドラインイン
タフェース(CLI)の両方が備わっています。さらに、HA Web Konsole (Hawk)も
標準装備しているので、WebインターフェイスからでもLinuxクラスタを管理
できます。
このガイドは、High Availability (HA)クラスタの設定、設定、保守を行う必要
がある管理者向けに作成されています。両方のアプローチ(GUIとCLI)につい
て詳細に記述し、管理者が主要作業の実行に必要な、適切なツールを選択で
きるよう支援します。
このガイドは、次のパートで構成されています。
インストールおよびセットアップ
このパートでは、クラスタのインストールと設定を開始する前に、クラス
タの基本とアーキテクチャをよく把握し、主要な機能と利点の概要を理解
します。必要なハードウェア/ソフトウェア要件と、以降の手順を実行す
る前に必要な準備作業について学習します。YaSTを使用してHAクラスタ
のインストールおよび基本セットアップを実行します。
設定および管理
グラフィカルユーザインタフェース(Pacemaker GUI)、Webインタフェース
(HA Web Konsole)、またはコマンドラインインタフェース(crmシェル)の
いずれかを使用して、クラスタリソースを追加、設定、管理します。クラ
スタ設定への不正アクセスを防止するには、役割を定義して、それらを特
定のユーザに割り当てることで細かく制御を行います。負荷分散および
フェンシングの使用方法を学習します。独自のリソースエージェントの作
成、または既存のエージェントの変更を検討している場合、別の種類のリ
ソースエージェントを作成する方法について背景情報を取得できます。
ストレージおよびデータレプリケーション
SUSE Linux Enterprise High Availability Extensionには、クラスタ対応のファ
イルシステムOCFS2およびボリュームマネージャcLVM (clustered Logical
Volume Manager)が標準装備されています。データをレプリケーションす
る場合は、DRBD*を使用して、High Availabilityサービスのデータをクラ
スタのアクティブノードからスタンバイノードへミラーリングします。さ
らに、クラスタ化したSambaサーバにより、異種混合環境にもHigh
Availabilityソリューションが提供されます。
付録
このパートには、最新リリース以降のHigh Availability Extensionの新機能
と動作変更点が一覧されています。クラスタを最新リリースバージョンに
移行する方法を学び、単純なテストリソースの設定例を参照してくださ
い。
このマニュアル中の多くの章に、他の資料やリソースへのリンクが記載され
ています。それらは、システム上で参照できる追加ドキュメントやインター
ネットから入手できるドキュメントなどです。
ご使用製品の利用可能なマニュアルと最新のドキュメントアップデートの概
要については、http://www.suse.com/doc/を参照してください。
1 フィードバック
次のフィードバックチャネルがあります。
バグと機能拡張の要求
ご使用の製品に利用できるサービスとサポートのオプションについては、
http://www.suse.com/support/を参照してください。
製品コンポーネントのバグを報告するには、http://www.suse.com/
support/からNovell Customer Centerにログインし、［マイサポート］ >
［サービス要求］の順に選択します。
ユーザからのコメント
本マニュアルおよびこの製品に含まれているその他のマニュアルについ
て、皆様のご意見やご要望をお寄せください。オンラインドキュメントの
各ページの下にあるユーザコメント機能を使用するか、またはhttp://
www.suse.com/doc/feedback.htmlにアクセスして、コメントを入力
してください。
メール
この製品のドキュメントについてのフィードバックは、
[email protected]宛のメールでも送信できます。ドキュメントのタイ
xii
高可用性ガイド
トル、製品のバージョン、およびドキュメントの発行日を明記してくださ
い。エラーの報告または機能拡張の提案では、問題について簡潔に説明
し、対応するセクション番号とページ(またはURL)をお知らせください。
2 マニュアルの表記規則
本書では、次の書体を使用しています。
• /etc/passwd:ディレクトリ名とファイル名
• placeholder:placeholderは、実際の値で置き換えられます
• PATH:環境変数PATH
• ls, --help:コマンド、オプション、およびパラメータ
• user:ユーザまたはグループ
• Alt、Alt + F1:押すためのキーまたはキーの組み合わせ、キーはキーボードと
同様に、大文字で表示されます
• ［ファイル］、［ファイル］ > ［名前を付けて保存］:メニュー項目、ボタ
ン
• ►amd64 em64t: この説明は、amd64、em64t、およびipfの各アーキテク
チャにのみ当てはまります。矢印は、テキストブロックの先頭と終わりを
示します。 ◄
• Dancing Penguins (「Penguins」の章、↑他のマニュアル):他のマニュアルの章
への参照です。
3 本マニュアルの作成について
本書は、DocBook(http://www.docbook.orgを参照)のサブセットである
Novdocで作成されています。XMLソースファイルはxmllintによって検証さ
れ、xsltprocによって処理され、Norman Walshによるスタイルシートのカ
このガイドについて
xiii
スタマイズ版を使用してXSL-FOに変換されました。最終的なPDFは、RenderX
のXEPによってフォーマットされています。
xiv
高可用性ガイド
パート I. インストールおよび
セットアップ
1
製品の概要
SUSE® Linux Enterprise High Availability Extensionは、オープンソースクラスタ
化技術の統合スイートで、可用性の高い物理Linuxクラスタと仮想Linuxクラス
タを実装し、SPOF (シングルポイント障害)をなくします。データ、アプリ
ケーション、サービスなどの重要なネットワークリソースの高度な可用性と
管理のしやすさを実現します。その結果、ミッションクリティカルなLinux
ワークロードに対してビジネスの継続性維持、データ整合性の保護、予期せ
ぬダウンタイムの削減を行います。
基本的な監視、メッセージング、およびクラスタリソース管理の機能を標準
装備し、個々の管理対象クラスタリソースのフェールオーバー、フェールバッ
ク、およびマイグレーション(負荷分散)をサポートします。
この章では、High Availability Extensionの主な製品機能と利点を紹介します。
ここには、いくつかのクラスタ例が記載されており、クラスタを設定するコ
ンポーネントについて学ぶことができます。最後のセクションでは、アーキ
テクチャの概要を示し、クラスタ内の個々のアーキテクチャ層とプロセスに
ついて説明します。
High Availabilityクラスタのコンテキストでよく使用される用語については、
用語集 (403 ページ)を参照してください。
1.1 アドオン/拡張としての可用性
High Availability Extensionは、SUSE Linux Enterprise Server 11 SP4に対するアド
オンとして入手できます。Geo Clustering for SUSE Linux Enterprise High
製品の概要
3
Availability Extensionという、High Availability Extensionの個別の拡張として、
地理的に離れたクラスタ(Geoクラスタ)に対するサポートが提供されていま
す。
1.2 主な機能
SUSE® Linux Enterprise High Availability Extensionでは、ネットワークリソース
の可用性を確保し、管理することができます。以降のセクションでは、いく
つかの主要機能に焦点を合わせて説明します。
1.2.1 広範なクラスタリングシナリオ
High Availability Extensionは次のシナリオをサポートしています。
• アクティブ/アクティブ設定
• アクティブ/パッシブ設定: N+1、N+M、Nから1、NからM
• ハイブリッド物理仮想クラスタ。仮想サーバを物理サーバとともにクラス
タ化できます。これによって、サービスの可用性とリソースの使用状況が
向上します。
• ローカルクラスタ
• メトロクラスタ(「ストレッチされた」ローカルクラスタ)
• Geoクラスタ(地理的に離れたクラスタ)
クラスタには、最大32のLinuxサーバを含めることができます。クラスタ内の
どのサーバも、クラスタ内の障害が発生したサーバのリソース(アプリケー
ション、サービス、IPアドレス、およびファイルシステム)を再起動すること
ができます。
1.2.2 柔軟性
High Availability Extensionには、Corosync/OpenAISメッセージングおよびメン
バーシップ層のほか、Pacemakerクラスタリソースマネージャが標準装備され
4
高可用性ガイド
ています。Pacemakerの使用によって、管理者は継続的にリソースのヘルスと
ステータスを監視し、依存関係を管理し、柔軟に設定できるルールとポリシー
に基づいてサービスを自動的に開始および停止できます。High Availability
Extensionでは、ユーザの組織に適した特定のアプリケーションおよびハード
ウェアインフラストラクチャに合わせて、クラスタのカスタマイズが可能で
す。時間依存設定を使用して、サービスを特定の時刻に修復済みのノードに
自動的にフェールバック(マイグレート)させることができます。
1.2.3 ストレージとデータレプリケーション
High Availability Extensionでは必要に応じてサーバストレージを自動的に割り
当て、再割り当てすることができます。ファイバチャネルまたはiSCSIスト
レージエリアネットワーク(SAN)をサポートしています。共有ディスクもサ
ポートされていますが、必要要件ではありません。SUSE Linux Enterprise High
Availability Extensionには、クラスタ対応のファイルシステムとボリュームマ
ネージャ(OCFS2)、cLVM (clustered Logical Volume Manager)も含まれていま
す。データのレプリケーションでは、DRBD*を使用して、High Availability
サービスのデータをクラスタのアクティブノードからスタンバイノードへミ
ラーリングできます。さらに、SUSE Linux Enterprise High Availability Extension
では、Sambaクラスタリング技術であるCTDB (Clustered Trivial Database)もサ
ポートしています。
1.2.4 仮想化環境のサポート
SUSE Linux Enterprise High Availability Extensionは、物理Linuxサーバと仮想
Linuxサーバの混合クラスタリングをサポートしています。SUSE Linux Enterprise
Server 11 SP4は、オープンソース仮想化ハイパーバイザであるXenと、ハード
ウェア仮想化拡張機能に基づく、Linuxの仮想化ソフトウェアであるKVM
(Kernel-based Virtual Machine)を標準装備しています。High Availability Extension
内のクラスタリソースマネージャは、仮想サーバで実行中のサービスと物理
サーバで実行中のサービスを認識、監視、および管理できます。ゲストシス
テムは、クラスタにサービスとして管理されます。
製品の概要
5
1.2.5 ローカル、メトロ、およびGeoクラスタ
のサポート
SUSE Linux Enterprise High Availability Extensionは、様々な地理的なシナリオ
をサポートするように拡張されています。Geo Clustering for SUSE Linux
Enterprise High Availability Extensionという、High Availability Extensionの個別
の拡張として、地理的に離れたクラスタ(Geoクラスタ)に対するサポートが提
供されています。
ローカルクラスタ
1つのロケーション内の単一のクラスタ(たとえば、すべてのノードが1つ
のデータセンターにある)。クラスタはノード間の通信にマルチキャスト
またはユニキャストを使用し、フェールオーバーを内部で管理します。
ネットワークの遅延時間は無視できます。ストレージは通常、すべての
ノードに同時にアクセスされます。
メトロクラスタ
すべてのサイトがファイバチャネルで接続された、複数の建物またはデー
タセンターにわたってストレッチできる単一のクラスタ。クラスタはノー
ド間の通信にマルチキャストまたはユニキャストを使用し、フェールオー
バーを内部で管理します。ネットワークの遅延時間は通常は短くなります
(約20マイルの距離で<5ms)。ストレージは頻繁にレプリケートされます
(ミラーリングまたは同期レプリケーション)
Geoクラスタ(マルチサイトクラスタ)
それぞれにローカルクラスタを持つ、複数の地理的に離れたサイト。サイ
トはIPによって交信します。サイト全体のフェールオーバーはより高いレ
ベルのエンティティによって調整されます。Geoクラスタは限られたネッ
トワーク帯域幅および高レイテンシに対応する必要があります。ストレー
ジは同期的にレプリケートされます。
個々のクラスタノード間の地理的距離が大きいほど、クラスタが提供するサー
ビスの高可用性を妨げる可能性のある要因が多くなります。ネットワークの
遅延時間、限られた帯域幅およびストレージへのアクセスが長距離クラスタ
の課題として残ります。
6
高可用性ガイド
1.2.6 リソースエージェント
SUSE Linux Enterprise High Availability Extensionには、Apache、IPv4、IPv6、そ
の他多数のリソースを管理するための膨大な数のリソースエージェントが含
まれています。またIBM WebSphere Application Serverなどの一般的なサード
パーティアプリケーション用のリソースエージェントも含まれています。ご
利用の製品に含まれているOpen Cluster Framework (OCF)リソースエージェン
トの概要は、7.1.3項「OCFリソースエージェントに関する情報の表
示」 (193 ページ)で説明されるcrm raコマンドを使用してください。
1.2.7 ユーザフレンドリな管理ツール
High Availability Extensionは、クラスタの基本的なインストールとセットアッ
プのほか、効果的な設定および管理に使用できる強力なツールセットを標準
装備しています。
YaST
一般的なシステムインストールおよび管理用グラフィカルユーザインタ
フェース。3.3項「アドオンとしてのインストール」 (30 ページ)に示され
ているように、YaSTを使用してHigh Availability ExtensionをSUSE Linux
Enterprise Serverの上にインストールします。YaSTでは、クラスタまたは
個々のコンポーネントの設定に役立つように、High Availabilityカテゴリ内
の次のモジュールも提供しています。
• クラスタ: 基本的なクラスタセットアップ。詳細については、3.5項
「手動のクラスタセットアップ(YaST)」 (37 ページ)を参照してく
ださい。
• DRBD: Distributed Replicated Block Deviceの設定。
• IP負荷分散: Linux仮想サーバによる負荷分散の設定。詳細について
は、第12章 Linux仮想サーバによる負荷分散 (259 ページ)を参照して
ください。
Pacemaker GUI
クラスタの設定と管理を容易にするインストール可能なグラフィカルユー
ザインタフェース。リソースの作成と設定の手順を順を追って支援し、リ
ソースの起動、中止、移行などの管理作業を容易にします。詳細について
製品の概要
7
は、第6章クラスタリソースの設定と管理(GUI) (153 ページ)を参照してく
ださい。
HA Web Konsole (Hawk)
Linux以外のマシンから、Linuxクラスタを管理できるWebベースのユーザ
インタフェース。このインタフェースは、システムにグラフィカルユーザ
インタフェースがない場合も理想的なソリューションです。リソースの作
成と設定の手順を順を追って支援し、リソースの起動、中止、移行などの
管理作業を容易にします。詳細については、第5章クラスタリソースの設
定と管理(Webインタフェース) (101 ページ)を参照してください。
crmシェル
リソースを設定し、すべての監視または管理作業を実行する、統合された
パワフルなコマンドラインインタフェースです。詳細については、第7章
クラスタリソースの設定と管理(コマンドライン) (189 ページ)を参照してく
ださい。
1.3 利点
High Availability Extensionでは最大 32台のLinuxサーバを可用性の高いクラス
タ(HAクラスタ)に設定し、クラスタ内の任意のサーバにリソースをダイナミッ
クに切り替えたり、移動することができます。サーバ障害発生時のリソース
の自動マイグレーションの設定ができます。また、ハードウェアのトラブル
シューティングやワークロードのバランスをとるために、リソースを手動で
移動することもできます。
High Availability Extensionは、コモディティコンポーネントによる高可用性を
提供しています。アプリケーションと操作をクラスタに統合することによっ
て、運用コストを削減できます。さらにHigh Availability Extensionでは、クラ
スタ全体を一元管理し、変化するワークロード要件に応じてリソースを調整
することもできます(手動でのクラスタの「負荷分散」)。3ノード以上でクラ
スタを設定すると、複数のノードが「ホットスペア」を共用できて無駄があ
りません。
その他にも重要な利点として、予測できないサービス停止を削減したり、ソ
フトウェアおよびハードウェアの保守やアップグレードのための計画的なサー
ビス停止を削減できる点が挙げられます。
次に、クラスタによるメリットについて説明します。
8
高可用性ガイド
• 可用性の向上
• パフォーマンスの改善
• 運用コストの低減
• スケーラビリティ
• 障害回復
• データの保護
• サーバの集約
• ストレージの集約
共有ディスクサブシステムにRAID を導入することによって、共有ディスクの
耐障害性を強化できます。
次のシナリオは、High Availability Extensionの利点を紹介するものです。
クラスタシナリオ例
サーバ3台でクラスタが設定され、それぞれのサーバにWebサーバをインス
トールしたと仮定します。クラスタ内の各サーバが、2つのWebサイトをホス
トしています。各Webサイトのすべてのデータ、グラフィックス、Webページ
コンテンツは、クラスタ内の各サーバに接続された、共有ディスクサブシス
テムに保存されています。次の図は、このクラスタのセットアップを示して
います。
製品の概要
9
図 1.1 3サーバクラスタ
通常のクラスタ操作では、クラスタ内の各サーバが他のサーバと常に交信し、
すべての登録済みリソースを定期的にポーリングして、障害を検出します。
Webサーバ1でハードウェアまたはソフトウェアの障害が発生したため、この
サーバを利用してインターネットアクセス、電子メール、および情報収集を
行っているユーザの接続が切断されたとします。次の図は、Webサーバ1で障
害が発生した場合のリソースの移動を表したものです。
図 1.2 1台のサーバに障害が発生した後の3サーバクラスタ
WebサイトAがWebサーバ2に、WebサイトBがWebサーバ3に移動します。IP
アドレスと証明書もWebサーバ2とWebサーバ3に移動します。
10
高可用性ガイド
クラスタを設定するときに、それぞれのWebサーバがホストしているWebサイ
トについて、障害発生時の移動先を指定します。先に説明した例では、Web
サイトAの移動先としてWebサーバ2が、WebサイトBの移動先としてWebサー
バ3が指定されています。このようにして、Webサーバ1によって処理されて
いたワークロードが、残りのクラスタメンバーに均等に分散され、可用性を
維持できます。
Webサーバ1で障害が発生すると、High Availability Extensionソフトウェアは次
の処理を実行します。
• 障害を検出し、Webサーバ 1が本当に機能しなくなっていることをSTONITH
を使用して検証。STONITHは、「Shoot The Other Node In The Head」(他の
ノードの頭を撃て)の頭字語であり、誤動作しているノードをダウンさせて、
それらがクラスタ内に問題を発生させることを防ぎます。
• Webサーバ1にマウントされていた共有データディレクトリを、Webサーバ
2およびWebサーバ3に再マウント。
• Webサーバ1で動作していたアプリケーションを、Webサーバ2およびWeb
サーバ3で再起動。
• IPアドレスをWebサーバ2およびWebサーバ3に移動。
この例では、フェールオーバープロセスが迅速に実行され、ユーザはWebサ
イトの情報へのアクセスを数秒程度で回復できます。通常、再度ログインす
る必要はありません。
ここで、Webサーバ1で発生した問題が解決し、通常に操作できる状態に戻っ
たと仮定します。WebサイトAおよびWebサイトBは、Webサーバ1に自動的に
フェールバック(復帰)することも、そのままの状態を維持することもできま
す。これは、リソースの設定方法によって決まります。Webサーバ1へのマイ
グレーションは多少のダウンタイムを伴うため、High Availability Extensionで
はサービス中断がほとんど、またはまったく発生しないタイミングまでマイ
グレーションを延期することもできます。いずれの場合でも利点と欠点があ
ります。
High Availability Extensionは、リソースマイグレーション機能も提供します。
アプリケーション、Webサイトなどをシステム管理の必要性に応じて、クラ
スタ内の他のサーバに移動することができます。
製品の概要
11
たとえば、WebサイトAまたはWebサイトBをWebサーバ1からクラスタ内の他
のサーバに手動で移動することができます。これは、Webサーバ1のアップグ
レードや定期メンテナンスを実施する場合、また、Webサイトのパフォーマ
ンスやアクセスを向上させる場合に有効な機能です。
1.4 クラスタ設定: ストレージ
High Availability Extensionでのクラスタ構成には、共有ディスクサブシステム
が含まれる場合と含まれない場合があります。共有ディスクサブシステムの
接続には、高速ファイバチャネルカード、ケーブル、およびスイッチを使用
でき、また設定にはiSCSIを使用することができます。サーバの障害時には、
クラスタ内の別の指定されたサーバが、障害の発生したサーバにマウントさ
れていた共有ディスクディレクトリを自動的にマウントします。この機能に
よって、ネットワークユーザは、共有ディスクサブシステム上のディレクト
リに対するアクセスを中断することなく実行できます。
重要: cLVMを伴う共有ディスクサブシステム
共有ディスクサブシステムをcLVMと使用する場合、クラスタ内の、アクセ
スが必要なすべてのサーバにそのサブシステムを接続する必要があります。
一般的なリソースの例としては、データ、アプリケーション、およびサービ
スなどがあります。次の図は、一般的なファイバチャネルクラスタの設定を
表したものです。
12
高可用性ガイド
図 1.3 一般的なファイバチャネルクラスタの設定
ファイバチャネルは最も高いパフォーマンスを提供しますが、iSCSIを利用す
るようにクラスタを設定することもできます。iSCSIは低コストなストレージ
エリアネットワーク(SAN)を作成するための方法として、ファイバチャネルの
代わりに使用できます。次の図は、一般的なiSCSIクラスタの設定を表したも
のです。
製品の概要
13
図 1.4 一般的なiSCSIクラスタの設定
ほとんどのクラスタには共有ディスクサブシステムが含まれていますが、共
有ディスクサブシステムなしのクラスタを作成することもできます。次の図
は、共有ディスクサブシステムなしのクラスタを表したものです。
図 1.5 共有ストレージなしの一般的なクラスタ設定
14
高可用性ガイド
1.5 アーキテクチャ
このセクションでは、High Availability Extensionアーキテクチャの概要を説明
します。アーキテクチャコンポーネントと、その相互運用方法について説明
します。
1.5.1 アーキテクチャ層
High Availability Extensionのアーキテクチャは層化されています。図1.6「アー
キテクチャ」 (15 ページ)に異なる層と関連するコンポーネントを示します。
図 1.6 アーキテクチャ
製品の概要
15
1.5.1.1 メッセージングおよびインフラストラクチャ層
プライマリまたは最初の層は、メッセージングおよびインフラストラクチャ
の層で、Corosync/OpenAIS層とも呼ばれます。この層には、「I'm alive」信号
やその他の情報を含むメッセージを送信するコンポーネントが含まれます。
High Availability Extensionのプログラムはメッセージングおよびインフラスト
ラクチャ層に常駐しています。
1.5.1.2 リソース割り当て層
次の層はリソース割り当て層です。この層は最も複雑で、次のコンポーネン
トから設定されていいます。
CRM (クラスターリソースマネージャ)
リソース割り当て層のすべてのアクションは、クラスターリソースマネー
ジャを通過します。リソース割り当て層の他のコンポーネント(または上
位層のコンポーネント)による通信の必要性が発生した場合は、ローカル
CRM経由で行います。すべてのノードで、CRMは「CIB (クラスタ情報
ベース)」を維持しています。
CIB (クラスタ情報ベース)
クラスタ情報ベースは、メモリ内でクラスタ全体の設定や現在のステータ
スをXML形式で表すものです。すべてのクラスタオプション、ノード、
リソース、制約、相互関係の定義が含まれます。CIBはすべてのクラスタ
ノードへの更新の同期化も行います。「指定コーディネータ(DC)」が維持
するマスタCIBがクラスタ内に1つあります。他のすべてのノードにはCIB
のレプリカが含まれます。
指定コーディネータ(DC)
クラスタ内のCRMはDCとして選択されます。DCは、ノードのフェンシン
グやリソースの移動など、クラスタ全体におよぶ変更が必要かどうかを判
断できる、クラスタ内で唯一のエンティティです。DCは、CIBのマスター
コピーが保持されるノードでもあります。その他すべてのノードは、現在
のDCから設定とリソース割り当て情報を取得します。DCは、メンバー
シップの変更後、クラスタ内のすべてのノードから選抜されます。
PE (ポリシーエンジン)
指定コーディネータがクラスタ全体におよぶ変更を行う(新しいCIBに対応
する)ことが必要になるたびに、ポリシーエンジンは現在の状態と設定に
16
高可用性ガイド
基づき、クラスタの次の状態を計算します。PEは(リソース)アクションの
リストと、次のクラスタ状態に移るために必要な依存性を含む遷移グラフ
も作成します。PEは常にDC上で実行されます。
LRM(ローカルリソースマネージャ)
LRMはCRMに代わってローカルリソースエージェントを呼び出します
(1.5.1.3項「リソース層」 (17 ページ)を参照)。そのため、操作の開始、停
止、監視を行い、結果をCRMに報告します。LRMはそのローカルノード
上のすべてのリソース関連情報の信頼できるソースです。
1.5.1.3 リソース層
最も上位の層はリソース層です。リソース層には1つ以上のリソースエージェ
ント(RA)が含まれます。リソースエージェントは、一定の種類のサービス(リ
ソース)を開始、停止、監視するために作成されたプログラム(通常はシェルス
クリプト)です。リソースエージェントの呼び出しはLRMだけが行います。
サードパーティはファイルシステム内の定義された場所に独自のエージェン
トを配置して、自社ソフトウェア用に、すぐに使えるクラスタ統合機能を提
供することができます。
1.5.2 プロセスフロー
SUSE Linux Enterprise High Availability Extensionは、PacemakerをCRMとして使
用します。 CRMは各クラスタノード上にインスタンスを持つデーモン(crmd)
として実装されます。Pacemakerは、マスタとして動作するcrmdインスタンス
を１つ選択することにより、クラスタのすべての意思決定を一元化します。
選択したcrmdプロセス(またはその下のノード)で障害が発生したら、新しい
crmdプロセスが確立されます。
クラスタの設定とクラスタ内のすべてのリソースの現在の状態を反映したCIB
が、各ノードに保存されます。CIBのコンテンツはクラスタ全体で自動的に同
期化されます。
クラスタ内で実行するアクションの多くは、クラスタ全体におよぶ変更を伴
います。これらのアクションにはクラスタリソースの追加や削除、リソース
制約の変更などがあります。このようなアクションを実行する場合は、クラ
スタ内でどのような変化が発生するのかを理解することが重要です。
製品の概要
17
たとえば、クラスタIPアドレスリソースを追加するとします。そのためには、
コマンドラインツールかWebインタフェースを使用してCIBを変更できます。
DC上でアクションを実行する必要はなく、クラスタ内の任意のノードでいず
れかのツールを使用すれば、DCに反映されます。そして、DCがすべてのクラ
スタノードにCIBの変更を複製します。
CIBの情報に基づき、PEがクラスタの理想的な状態と実行方法を計算し、指
示リストをDCに送ります。DCはメッセージング/インフラストラクチャ層を
介してコマンドを送信し、他のノードのcrmdピアがこれらのコマンドを受信
します。各crmdはLRM(lrmdとして実装)を使用してリソースを変更します。
lrmdはクラスタに対応しておらず、リソースエージェント(スクリプト)と直接
通信します。
すべてのピアノードは操作結果をDCに返送します。DCが、すべての必要な操
作がクラスタ内で成功したことを確認すると、クラスタはアイドル状態に戻
り、次のイベントを待機します。予定通り実行されなかった操作があれば、
CIBに記録された新しい情報を元に、PEを再度呼び出します。
場合によっては、共有データの保護や完全なリソース復旧のためにノードの
電源を切らなければならないことがあります。このPacemakerにはフェンシン
グサブシステムとしてstonithdが内蔵されています。STONITHは「Shoot The
Other Node In The Head」(他のノードの即時強制終了)の略語で、通常はリモー
ト電源スイッチを使用して実装されます。Pacemakerでは、STONITHデバイス
は、その障害を簡単に監視できるように、リソースとしてモデル化(そしてCIB
内で設定)されます。ただし、STONITHトポロジの把握はstonithdが担当し、
そのクライアントはノードのフェンシングを要求するだけであり、残りの作
業はstonithdが実行します。
18
高可用性ガイド
2
システム要件と推奨事項
次のセクションでは、SUSE® Linux Enterprise High Availability Extensionのシス
テム要件と前提条件について説明します。また、クラスタセットアップの推
奨事項についても説明します。
2.1 ハードウェア要件
次のリストは、SUSE® Linux Enterprise High Availability Extensionに基づくクラ
スタのハードウェア要件を指定しています。これらの要件は、最低のハード
ウェア設定を表しています。クラスタの使用方法によっては、ハードウェア
を追加しなければならないこともあります。
• 2.2項「ソフトウェアの必要条件」 (20 ページ)に指定されたソフトウェア
を搭載した1～32台のLinuxサーバ。各サーバが同一のハードウェア構成(メ
モリ、ディスクスペースなど)になっている必要はありませんが、アーキテ
クチャは同じである必要があります。クロスプラットフォームのクラスタ
はサポートされていません。
• クラスタノードあたり、少なくとも2つのTCP/IP通信メディア。クラスタ
ノードは、ネットワーク設備が使用したい通信手段をサポートするため、
通信にマルチキャストまたはユニキャストを使用します。通信メディアは
100Mbit/s以上のデータレートをサポートする必要があります。可能であれ
ば、第11章ネットワークデバイスボンディング (251 ページ)の説明に従って
Ethernetの各チャネルを結合します。別の方法として、Corosyncで冗長な通
信チャネルとして2つ目のインタフェースを使用することもできます。手順
3.7「冗長通信チャネルの定義」 (43 ページ)も参照してください。
システム要件と推奨事項
19
• オプション:クラスタ内の、アクセスが必要なすべてのサーバに接続された、
共有ディスクサブシステム。詳細については、2.3項「ストレージ要
件」 (20 ページ)を参照してください。
• STONITHメカニズム。STONITHデバイスとは、クライアントが停止または
誤動作しているとみなしたノードをリセットするために使用する電源スイッ
チです。これは、ハングして停止したようにしか見えないノードによるデー
タ破損を防ぐ、唯一の信頼できる方法です。
2.2 ソフトウェアの必要条件
次のソフトウェア要件を満たしていることを確認してください。
• SUSE® Linux Enterprise Server 11 SP4 (利用可能なすべてのオンラインアップ
デートを適用済み)が、クラスタを構成するすべてのノードにインストール
されていること。
• SUSE Linux Enterprise High Availability Extension 11 SP4 (利用可能なすべての
オンラインアップデートを適用済み)が、クラスを構成するすべてのノード
にインストールされていること。
• Geoクラスタを使用する場合は、Geo Clustering for SUSE Linux Enterprise High
Availability Extension11 SP4 (利用可能なすべてのオンラインアップデートを
適用済み)が、クラスタを構成するすべてのノードにインストールされてい
ること。
2.3 ストレージ要件
クラスタでデータの可用性を高めたい場合は、共有ディスクシステム(SAN:
Storage Area Network)の利用をお勧めします。共有ディスクシステムを使用す
る場合は、次の要件を満たしていることを確認してください。
• メーカーの指示のに従い、共有ディスクシステムが適切に設定され、正し
く動作していることを確認します。
• 共有ディスクシステム中のディスクを、ミラーリングまたはRAIDを使用し
て耐障害性が高められるように設定してください。ハードウェアベースの
20
高可用性ガイド
RAIDをお勧めします。ホストベースのソフトウェアRAIDはどの設定でも
サポートされていません。
• 共有ディスクシステムのアクセスにiSCSIを使用している場合、iSCSIイニシ
エータとターゲットを正しく設定していることを確認します。
• 2台のマシンにデータを配分するミラーリングRAIDシステムを実装するた
めにDRBD*を使用する際、DRBDに提供されるデバイスにのみアクセスし、
決してバッキングデバイスにはアクセスしないようにします。クラスタの
残りが提供される冗長性を利用する、同じ(ボンドされた)NICを使用しま
す。
2.4 その他の要件と推奨事項
サポートされていて、役に立つHigh Availabilityセットアップについては、次
の推奨事項を検討してください。
クラスタノード数
各クラスタは2つ以上のクラスタノードで構成される必要があります。
重要: 奇数のクラスタノード
3ノードの「最小値」で「奇数」のクラスタノードを使用することを強
くお勧めします。
クラスタではサービスの実行を維持するために、クォーラムが必要で
す。したがって、3ノードのクラスタは一度に1ノードの障害しか許容で
きませんが、5ノードのクラスタは、2ノードの障害を許容できます。
STONITH
重要: STONITHがない場合はサポートなし
STONITHがないクラスタはサポートされません。
サポートされるHigh Availabilityセットアップについては、次の点を確認し
てください。
システム要件と推奨事項
21
• High Availabilityクラスタの各ノードには、少なくとも1つのSTONITH
デバイス(通常はハードウェア)が必要です。SBDを使用しない場合
は、1ノードあたり複数のSTONITHデバイスを使用することを強く
お勧めします。SBDは、外部電源スイッチなしでクラスタ内の
STONITHとフェンシングを有効にしますが、共有ストレージは必
要とします。
• グローバルクラスタオプションstonith-enabledおよび
startup-fencingをtrueに設定する必要があります。これらの
オプションを変更すると、ただちにサポートが失われます。
冗長通信パス
High Availabilityセットアップがサポートされるには、2つ以上の冗長パス
でクラスタ通信を設定する必要があります。これは次のように実行できま
す。
• ネットワークデバイスボンディング (251 ページ)。
• Corosync内の2つ目の通信チャネル。詳細については、手順3.7「冗
長通信チャネルの定義」 (43 ページ)を参照してください。
可能であれば、ネットワークデバイスのボンディングを選択します。
時刻同期
クラスタノードはクラスタ外のNTPサーバに同期する必要があります。詳
細については、『SUSE Linux Enterprise Server 11 SP4 管理ガイド』(http://
www.suse.com/doc/から入手可能)を参照してください。特に、「Time
Synchronization with NTP」の章を参照してください。
ノードが同期されていない場合、ログファイルまたはクラスタレポートは
分析が難しくなります。
NIC名
すべてのノード上で同一である必要があります。
ホスト名およびIPアドレス
クラスタ内の各サーバの/etc/hostsファイルを編集することにより、ホ
スト名の解決を設定します。クラスタ通信の速度が落ちていない、または
DNSによって改ざんされていないことを確認するには、次を実行します。
• 静的IPアドレスを使用します。
22
高可用性ガイド
• このファイルにあるすべてのクラスタノードを、完全修飾ホスト名
およびショートホスト名で一覧表示します。クラスタのメンバーが
名前で互いを見つけられることが重要です。名前を使用できない場
合、内部クラスタ通信は失敗します。
詳細については、『SUSE Linux Enterprise Server 11 SP4 管理ガイド』
(http://www.suse.com/docから入手可能)を参照してください。「ネッ
トワークの基礎」の章、「YaSTによるネットワーク接続の設定」の「ホ
スト名とDNSの設定」セクションを参照してください。
ストレージ要件
一部のサービスでは、共有ストレージが必要な場合があります。詳細につ
いては、2.3項「ストレージ要件」 (20 ページ)を参照してください。外部
NFS共有またはDRBDを使用することもできます。外部NFS共有を使用す
る場合は、冗長通信パスを介してすべてのクラスタノードから確実にアク
セスできる必要があります。詳細については、「冗長通信パ
ス」 (22 ページ)を参照してください。
SBDをSTONITHデバイスとして使用する場合は、共有ストレージに対し
て追加の要件が適用されます。詳細については、http://linux-ha.org/
wiki/SBD_Fencing、「Requirements」セクションを参照してください。
SSH
すべてのクラスタノードはSSHによって互いにアクセスできる必要があり
ます。hb_reportまたはcrm_report (トラブルシューティング用)など
のツールおよびHawkの［履歴エクスプローラ］は、ノード間にパスワー
ド不要のSSHアクセスを必要とします。それがない場合、現在のノードか
らしかデータを収集できません。非標準のSSHポートを使用する場合は、
-Xオプションを使用します(マニュアルページを参照)。たとえば、SSH
ポートが3479の場合、次のコマンドを使用して、hb_reportを起動しま
す。
root # hb_report -X "-p 3479" [...]
注記: 規定要件
パスワード不要のSSHアクセスが規定要件に適合しない場合は、次のと
おり、hb_reportで次善策を使用できます。
システム要件と推奨事項
23
パスワードなしでログインできるユーザを作成します(例、公開鍵認証
の使用)。このユーザにsudoを設定し、rootパスワードが必要ないよ
うにします。hb_reportをコマンドラインから-uオプションで開始し、
ユーザ名を指定します。詳細については、 hb_reportのマニュアル
ページを参照してください。
履歴エクスプローラについては、現在のところ、パスワード不要のログ
インに代わる方法はありません。
24
高可用性ガイド
インストールと基本セットアッ
プ
3
この章では、SUSE® Linux Enterprise High Availability Extension 11 SP4を最初
からインストールしてセットアップする方法について説明します。自動セッ
トアップまたは手動セットアップから選択します。自動セットアップでは、
クラスタを起動して数分で実行できます(後でオプションを調整する選択あ
り)。一方、手動セットアップでは、起動時に個々のオプションを設定できま
す。
旧バージョンのSUSE Linux Enterprise High Availability Extensionを実行するク
ラスタを移行する場合や、実行中のクラスタに属するノードでソフトウェア
パッケージを更新する場合は、付録E クラスタアップグレードとソフトウェ
アパッケージの更新 (375 ページ)を参照してください。
3.1 用語の定義
この章では、次に定義されるいくつかの用語を使用します。
既存のクラスタ
「既存のクラスタ」という用語は、1つ以上のノードで構成されるクラス
タを指すものとして使用されます。既存のクラスタは、通信チャネルを定
義する基本的なCorosync設定を持ちますが、必ずしもリソース設定を持つ
とは限りません。
マルチキャスト
ネットワーク内で一対多数の通信に使用される技術で、クラスタ通信に使
用できます。Corosyncはマルチキャストとユニキャストの両方をサポート
インストールと基本セットアップ
25
しています。マルチキャストが会社のITポリシーに準拠しない場合、代わ
りにユニキャストを使用します。
注記: スイッチとマルチキャスト
クラスタ通信にマルチキャストを使用したい場合、ご使用のスイッチが
マルチキャストをサポートしていることを確認します。
マルチキャストアドレス(mcastaddr)
Corosyncエグゼクティブによるマルチキャストに使用されるIPアドレス。
このIPアドレスはIPv4またはIPv6のいずれかに設定できます。IPv6ネット
ワークを使用する場合は、ノードのIDを指定する必要があります。プライ
ベートネットワークでは、どのようなマルチキャストアドレスでも使用で
きます。
マルチキャストポート(mcastport)
クラスタ通信に使用されるポート。Corosyncでは、マルチキャストの受信
用に指定するmcastportと、マルチキャストの送信用のmcastport -1
の、2つのポートを使用します。
ユニキャスト
ひとつのあて先ネットワークにメッセージを送信する技術Corosyncはマル
チキャストとユニキャストの両方をサポートしています。Corosyncでは、
ユニキャストはUDP-unicast (UDPU)として実装されます。
バインドネットワークアドレス(bindnetaddr)
Corosyncエグゼクティブのバインド先のネットワークアドレス。クラスタ
間の設定ファイルの共有を軽減するため、OpenAISはネットワークインタ
フェースネットマスクを使用して、ネットワークのルーティングに使用さ
れるアドレスビットのみをマスクします。たとえば、ローカルインタフェー
スが192.168.5.92でネットマスクが255.255.255.0の場合、
bindnetaddrは192.168.5.0に設定します。ローカルインタフェース
が192.168.5.92でネットマスクが255.255.255.192の場合は、
bindnetaddrを192.168.5.64に設定します。
26
高可用性ガイド
注記: すべてのノードのネットワークアドレス
すべてのノード上で同じCorosync設定が使用されるため、ネットワーク
アドレスは、特定のネットワークインタフェースのアドレスではなく、
bindnetaddrとして使用します。
冗長リングプロトコル(RRP)
ネットワーク障害の一部または全体に対する災害耐性のために、複数の冗
長ローカルエリアネットワークが使用できるようになります。この方法で
は、ひとつのネットワークが作動中である限り、クラスタ通信を維持でき
ます。Corosyncはトーテム冗長リングプロトコルをサポートします。信頼
できるソートされた方式でメッセージを配信するために、論理トークンパ
スリングがすべての参加ノードに課せられます。ノードがメッセージをブ
ロードキャストできるのは、トークンを保持している場合のみです。詳細
については、http://www.rcsc.de/pdf/icdcs02.pdfを参照してく
ださい。
Corosyncに定義済みの冗長通信チャネルを持つ場合、RRPを使用してこれ
らのインタフェースの使用方法をクラスタに伝えます。RRPでは次の3つ
のモードを使用できます(rrp_mode)。
• activeに設定した場合、Corosyncは両方のインタフェースをアク
ティブに使用します。
• passiveに設定した場合、Corosyncは代わりに使用可能なネット
ワークを介してメッセージを送信します。
• noneに設定した場合、RRPは無効になります。
Csync2
クラスタ内のすべてのノード、およびGeoクラスタ全体に設定ファイルを
複製するために使用できる同期ツールです。Csync2は、同期グループ別に
ソートされた任意の数のホストを操作できます。各同期グループは、メン
バーホストの独自のリストとその包含/除外パターン(同期グループ内でど
のファイルを同期するか定義するパターン)を持っています。グループ、
各グループに属するホスト名、および各グループの包含/除外ルールは、
Csync2設定ファイル/etc/csync2/csync2.cfgで指定されます。
インストールと基本セットアップ
27
Csync2は、認証には、同期グループ内でIPアドレスと事前共有キーを使用
します。管理者は、同期グループごとに1つのキーファイルを生成し、そ
のファイルをすべてのグループメンバにコピーする必要があります。
Csync2の詳細については、http://oss.linbit.com/csync2/paper
.pdfを参照してください。
conntrackツール
カーネル内の接続トラッキングシステムとやり取りできるようにして、
iptablesでのステートフルなパケット検査を可能にします。High Availability
Extensionによって、クラスタノード間の接続ステータスを同期化するため
に使用されます。詳細については、http://conntrack-tools
.netfilter.org/を参照してください。
AutoYaST
AutoYaSTは、ユーザの介入なしで、1つ以上のSUSE Linux Enterpriseシス
テムを自動的にインストールするためのシステムです。SUSE Linux
Enterpriseでは、インストールと設定のデータを含むAutoYaSTプロファイ
ルを作成できます。このプロファイルによって、インストールする対象
と、インストールしたシステムが最終的に使用準備が整ったシステムにな
るように設定する方法がAutoYaSTに指示されます。そこでこのプロファ
イルはさまざまな方法による大量配備に使用できます(たとえば、既存の
クラスタノードのクローンなど)。
様々なシナリオでのAutoYaSTの使用手順については、http://www.suse
.com/docで入手できる『SUSE Linux Enterprise 11 SP4 導入ガイド』を参
照してください。特に、「Automated Installation」の章を参照してくださ
い。
28
高可用性ガイド
3.2 概要
次の基本手順は、インストールおよび最初のクラスタセットアップに必要で
す。
1 アドオンとしてのインストール (30 ページ):
YaSTでソフトウェアパッケージをインストールします。または、コマンド
ラインzypperからインストールできます。
root # zypper in -t pattern ha_sles
2 クラスタの初期セットアップ:
クラスタの一部になるすべてのノードにソフトウェアをインストールした
後、最初にクラスタを設定するために次の手順が必要です。
2a 通信チャネルの定義 (38 ページ)
2b オプション: 認証設定の定義 (44 ページ)
2c すべてのノードへの設定の転送 (46 ページ)。Csync2の設定がノード
でのみ行われるのに対して、サービスであるCsync2およびxinetdは
すべてのノードで開始する必要があります。
2d オプション: クラスタノード間の接続ステータスの同期 (49 ページ)
2e サービスの設定 (51 ページ)
2f クラスタをオンラインにする (53 ページ)。OpenAIS/Corosyncサービ
スはすべてのノード上で開始する必要があります。
クラスタセットアップの手順は、自動(ブートストラップスクリプトで)か、ま
たは手動(YaSTクラスタモジュールで、またはコマンドラインから)のいずれ
かで実行できます。
• 自動のクラスタセットアップを選択する場合は、3.4項「自動のクラスタ
セットアップ(sleha-bootstrap)」 (31 ページ)を参照してください。
インストールと基本セットアップ
29
• 手動のセットアップ(または自動セットアップ後のオプション調整)は、3.5
項「手動のクラスタセットアップ(YaST)」 (37 ページ)を参照してくださ
い。
たとえば、1つのノードをYaSTクラスタで設定してから、sleha-joinを使
用して他のノードを統合させるなど、両方のセットアップ方法を組み合わせ
ることもできます。
既存のノードをAutoYaSTで大量展開するためにクローンを作成することもで
きます。クローンを作成したノードには、同じパッケージがインストールさ
れ、クローンノードは同じシステム設定を持つことになります。詳細につい
ては、3.6項「AutoYaSTによる大量展開」 (54 ページ)を参照してください。
3.3 アドオンとしてのインストール
High Availability Extensionによるクラスタの設定と管理に必要なパッケージは、
High Availabilityインストールパターンに含まれています。このパター
ンは、SUSE Linux Enterprise High Availability ExtensionがアドオンとしてSUSE®
Linux Enterprise Serverにインストールされている場合のみ使用できます。アド
オン製品のインストール方法については、http://www.suse.com/docで
入手できる『SUSE Linux Enterprise 11 SP4 導入ガイド』を参照してください。
特に、「Installing Add-On Products」の章を参照してください。
手順 3.1 高可用性パターンのインストール
1 YaSTをrootユーザとして開始し、［ソフトウェア］ > ［ソフトウェア管
理］の順に選択します。
または、コマンドラインでyast2 sw_singleを使用して、YaSTモジュー
ルをrootとして起動します。
2 ［フィルタ］リストで、［パターン］を選択して、パターンリストで［高
可用性］をアクティブにします。
3 ［同意する］をクリックして、パッケージのインストールを開始します。
30
高可用性ガイド
注記: すべてのパーティへのソフトウェアパッケージのインストール
High Availabilityクラスタに必要なソフトウェアパッケージはクラスタノー
ドに自動的にコピーされません。
4 クラスタの一部になるすべてのマシンにHigh Availabilityパターンをインス
トールします。
クラスタを構成するノードのうち、一部ではSUSE Linux Enterprise Server 11
SP4とSUSE Linux Enterprise High Availability Extension 11 SP4を手動でイン
ストールしない場合は、AutoYaSTを使用して既存ノードのクローンを作成
します。詳細については、3.6項「AutoYaSTによる大量展開」 (54 ページ)
を参照してください。
3.4 自動のクラスタセットアップ
(sleha-bootstrap)
sleha-bootstrapパッケージは、1ノードクラスタを起動して実行させ、他
のノードを追加し、既存のクラスタからノードを削除するために必要なすべ
ての機能を提供します。
最初のノードの自動設定 (32 ページ)
sleha-initによって、クラスタ通信および(オプションで) STONITHメ
カニズムの設定に必要な基本パラメータを定義し、共有ストレージを保護
します。これによって1ノードクラスタの実行が可能になります。
既存のクラスタにノードを追加 (34 ページ)
sleha-joinで、他のノードをクラスタに追加します。
既存のクラスタからのノードの削除 (35 ページ)
sleha-removeで、クラスタからノードを削除します。
すべてのコマンドは、最低限の時間と手動介入しか必要のないブートストラッ
プスクリプトを実行します。初期化して追加するブートストラップスクリプ
トが、クラスタ通信に必要なファイアウォールで自動的にポートを開きます。
この設定は、/etc/sysconfig/SuSEfirewall2.d/services/cluster
インストールと基本セットアップ
31
に書きこまれます。ブートストラッププロセス中に設定されたオプションは、
YaSTクラスタモジュールで後で変更できます。
自動セットアップを開始する前に、クラスタに参加するすべてのノードで次
の前提条件が満たされていることを確認します。
前提条件
• 2.2項「ソフトウェアの必要条件」 (20 ページ)および2.4項「その他の要件
と推奨事項」 (21 ページ)にリストされている前提条件が満たされているこ
と。
• sleha-bootstrapパッケージがインストールされていること。
• ネットワークがニーズに沿って設定されていること。たとえば、プライベー
トネットワークがクラスタ通信に使用可能であり、ネットワークデバイス
のボンディングが設定されている。ボンディングに関する情報については、
第11章ネットワークデバイスボンディング (251 ページ)を参照してくださ
い。
• 共有ストレージにSBDを使用したい場合は、SBD用の共有ブロックデバイ
スが1つ必要です。ブロックデバイスはフォーマットする必要がありませ
ん。詳細については、第17章ストレージ保護 (317 ページ)を参照してくださ
い。
• すべてのノードは、同じパス(/dev/disk/by-path/...または/dev/
disk/by-id/...)を通して共有ストレージを参照できる必要があります。
手順 3.2 最初のノードの自動設定
sleha-initコマンドは、NTPの設定を確認し、クラスタ通信層(Corosync)の
設定、および(オプションで)SBDの設定に導き、共有ストレージを保護しま
す。次の手順に従います。詳細については、sleha-initマニュアルページ
を参照してください。
1 クラスタノードとして使用したい物理または仮想マシンにrootとしてログ
インします。
2 実行によって、ブートストラップスクリプトを開始します
root # sleha-init
32
高可用性ガイド
NTPがブート時に開始するよう設定されていない場合、メッセージが表示
されます。
それでも継続を選択する場合、スクリプトは自動的にSSHアクセスおよび
Csync2同期ツールのキーを生成し、両方に必要なサービスを開始します。
3 クラスタ通信層(Corosync)を設定するには、次のとおり実行します。
3a バインドするネットワークアドレスを入力します。デフォルトでは、
スクリプトはeth0のネットワークアドレスを提案します。または、
たとえばbond0のアドレスなど、別のネットワークアドレスを入力
します。
3b マルチキャストアドレスを入力します。スクリプトはデフォルトと
して使用できるランダムなアドレスを提案します。
3c マルチキャストポートを入力します。スクリプトはデフォルトとし
て5405を提案します。
4 SBDを設定するには(オプション)、SBDに使用したいブロックデバイスの
パーティションに持続的なパスを入力します。パスはクラスタ内のすべて
のノード全体で一致している必要があります。
最後に、スクリプトはOpenAISサービスを開始し、1ノードクラスタをオン
ラインにして、Web管理インタフェースHawkを有効にします。Hawkに使
用するURLが画面に表示されます。
5 セットアッププロセスの詳細については、/var/log/sleha-bootstrap
.logを確認してください。
1ノードクラスタが実行するようになります。crm statusを使用してクラス
タの状態を確認します。
root # crm status
Last updated: Thu Jul 3 11:04:10 2014
Last change: Thu Jul 3 10:58:43 2014
Current DC: alice (175704363) - partition with quorum
1 Nodes configured
0 Resources configured
Online: [ alice ]
インストールと基本セットアップ
33
重要: セキュリティ保護されたパスワード
ブートストラップの手順では、haclusterをユーザ名、パスワードをlinux
としたLinuxユーザが作成されます。これは、Hawkにログインする際に必要
です。デフォルトのパスワードはできるだけ早くセキュリティ保護された
パスワードに変更します。
root # passwd hacluster
手順 3.3 既存のクラスタにノードを追加
クラスタを(1つ上のノード上で)開始して実行する場合、sleha-joinブート
ストラップスクリプトでさらにクラスタノードを追加します。スクリプトは
既存のクラスタノードへのアクセスのみが必要で、ご使用のマシンで自動的
に基本セットアップを完了します。次の手順に従います。詳細については、
sleha-joinマニュアルページを参照してください。
既存のクラスタノードをYaSTクラスタモジュールで設定した場合、
sleha-joinを実行する前に、次の前提条件が満たされていることを確認し
ます。
• 既存のノードのrootユーザに、パスワードなしでログインするためのSSH
キーが適切に設定されている。
• Csync2が既存のノードに設定されている。詳細については、手順3.9「YaST
によるCsync2の設定」 (46 ページ)を参照してください。
Hawkによって最初のノードにログインしている場合、クラスタステータス内
の変更に従い、Webインタフェース内でアクティブ化されるリソースを表示
できます。
1 クラスタを参加させることになる物理または仮想マシンにrootとしてログ
インします。
2 実行によって、ブートストラップスクリプトを開始します。
root # sleha-join
NTPがブート時に開始するよう設定されていない場合、メッセージが表示
されます。
34
高可用性ガイド
3 それでも継続を選択する場合、既存のノードのIPアドレスが求められます。
IPアドレスを入力します。
4 両方のマシン間にパスワードなしのSSHアクセスを設定していない場合、
既存のノードのrootパスワードも求められます。
指定されたノードにログインした後、スクリプトはCorosync設定をコピー
し、SSHおよびCsync2を設定して、新しいクラスタノードとしてご使用の
マシンをオンラインにします。それとは別に、Hawkに必要なサービスを開
始します。OCFS2で共有ストレージを設定した場合、OCFS2ファイルシス
テムへのマウントポイントディレクトリも自動的に作成します。
5 クラスタを追加したいすべてのマシンにこの手順を繰り返します。
6 プロセスの詳細については、/var/log/sleha-bootstrap.logを確認
してください。
crm statusを使用してクラスタの状態を確認します。2番目のノードを正常
に追加した場合、出力は次のようになります。
root # crm status
Last updated: Thu Jul 3 11:07:10 2014
Last change: Thu Jul 3 10:58:43 2014
Current DC: alice (175704363) - partition with quorum
2 Nodes configured
0 Resources configured
Online: [ alice bob ]
重要: no-quorum-policyの確認
すべてのノードを追加した後、グローバルクラスタオプションで
no-quorum-policyの調整が必要であるかを確認します。これは特に2ノー
ドクラスタで重要です。詳細については、4.1.2項「オプション
no-quorum-policy」 (60 ページ)を参照してください。
手順 3.4 既存のクラスタからのノードの削除
(複数のノードで)クラスタを起動して実行している場合、sleha-removeブー
トストラップスクリプトによって、クラスタから1つのノードを削除すること
ができます。この場合、クラスタから削除するノードのIPアドレスまたはホ
スト名が必要です。次の手順に従います。詳細については、sleha-remove
マニュアルページを参照してください。
インストールと基本セットアップ
35
1 クラスタノードのいずれかにrootとしてログインします。
2 実行によって、ブートストラップスクリプトを開始します。
root # sleha-remove -c IP_ADDR_OR_HOSTNAME
このスクリプトはsshdを有効にし、指定したノードのOpenAISサービスを
停止させ、Csync2と同期化するためのファイルを残りのノードに伝播しま
す。
ホスト名を指定していて、削除対象のノードにアクセスできない(またはホ
スト名が解決できない)場合、スクリプトによって通知が送信され、それで
もノードを削除するかどうかを尋ねられます。IPアドレスを指定していて、
ノードにアクセスできない場合は、ホスト名を入力するように求められ、
それでもノードを削除するかどうかを尋ねられます。
3 ノードをさらに削除するには、前述の手順を繰り返します。
4 プロセスの詳細については、/var/log/sleha-bootstrap.logを確認
してください。
削除したノードを後で再度追加する必要が生じた場合は、sleha-joinを使
用して追加します。詳細については、手順3.3「既存のクラスタにノードを追
加」 (34 ページ)を参照してください。
手順 3.5 マシンからのHigh Availability Extensionソフトウェアの削除
クラスタノードとして不要になったマシンからHigh Availability Extensionソフ
トウェアを削除するには、以下の手順を実行します。
1 クラスタサービスを停止します:
root # rcopenais stop
2 High Availability Extensionアドオンを削除します:
root # zypper rm -t products sle-hae
36
高可用性ガイド
3.5 手動のクラスタセットアップ(YaST)
最初のセットアップに関するすべての手順の概要については、3.2項「概
要」 (29 ページ)を参照してください。
3.5.1 YaSTクラスタモジュール
次のセクションでは、YaSTクラスタモジュールを使用して、セットアップの
各手順を実行します。これにアクセスするには、YaSTをrootとして起動し、
［高可用性］ > ［クラスタ］の順に選択します。または、コマンドライン
yast2 clusterでモジュールを開始します。
初めてクラスタモジュールを起動した場合は、モジュールが、ウィザードの
ように、基本設定に必要なすべてのステップをガイドします。そうでない場
合は、左パネルのカテゴリをクリックして、ステップごとに設定オプション
にアクセスします。
インストールと基本セットアップ
37
図 3.1 YaSTクラスタモジュール - 概要
YaSTクラスタモジュールのオプションには、現在のノードにしか適用しない
ものと、すべてのノードに自動的に移行できるものがあることにご注意くだ
さい。これについての詳しい情報は次のセクションを参照してください。
3.5.2 通信チャネルの定義
クラスタノード間で通信を正常に機能させるには、少なくとも1つの通信チャ
ネルを定義します。
38
高可用性ガイド
重要: 冗長通信パス
クラスタ通信は、2つ以上の冗長パスによって設定することを強く推奨しま
す。これは次のように実行できます。
• ネットワークデバイスボンディング (251 ページ)。
• Corosync内の2つ目の通信チャネル。詳細については、手順3.7「冗長通信
チャネルの定義」 (43 ページ)を参照してください。
可能であれば、ネットワークデバイスのボンディングを選択します。
手順 3.6 最初の通信チャネルの定義
クラスタノード間の通信には、マルチキャスト(UDP)またはユニキャスト
(UDPU)のいずれかを使用します。
1 YaSTクラスタモジュール内で、［通信チャネル］カテゴリに切り替えま
す。
2 マルチキャストを使用するには、次のとおり実行します。
2a ［トランスポート］プロトコルをUDPに設定します。
2b ［バインドネットワークアドレス］を定義します。クラスタマルチ
キャストに使用するサブネットに値を設定します。
2c ［マルチキャストアドレス］を定義します。
2d ［マルチキャストポート］を定義します。
上で入力した値で、クラスタの通信チャネルを1つ定義したことにな
ります。マルチキャストモードでは、すべてのクラスタノードに対
して同じbindnetaddr、mcastaddr、mcastportが使用されま
す。クラスタ内のすべてのノードは同じマルチキャストアドレスを
使用することで互いを認識します。別のクラスタは、別のマルチキャ
ストアドレスを使用します。
インストールと基本セットアップ
39
図 3.2
YaSTクラスタ - マルチキャスト設定
3 ユニキャストを使用するには、次のとおり実行します。
3a ［トランスポート］プロトコルをUDPUに設定します。
3b ［バインドネットワークアドレス］を定義します。クラスタユニキャ
ストに使用するサブネットに値を設定します。
3c ［マルチキャストポート］を定義します。
40
高可用性ガイド
3d ユニキャスト通信では、Corosyncはクラスタ内のすべてのノードのIP
アドレスを認識する必要があります。クラスタの一部になる各ノー
ドで、［追加］をクリックし、次の詳細を入力します。
• ［IPアドレス］
• ［冗長IPアドレス］(Corosyncで2つ目の通信チャネルを使用する場
合にのみ必要)
• ［ノードID］(［ノードIDの自動生成］オプションが無効になって
いる場合にのみ必要)
クラスタメンバーのアドレスを変更または削除するには、［編集］
または［削除］ボタンを使用します。
インストールと基本セットアップ
41
図 3.3
YaSTクラスタ - ユニキャスト設定
4 ［ノードIDの自動生成］オプションはデフォルトで有効になっています。
IPv4アドレスを使用している場合は、ノードIDはオプションですが、IPv6
アドレスを使用している場合は必須です。各クラスタノードで固有のIDを
自動生成するには(各ノードでIDを手動で指定するよりもエラーの発生が少
ない)、このオプションを有効のままにします。
5 既存のクラスタでオプションを変更した場合、変更を確認して、クラスタ
モジュールを終了します。YaSTが設定を/etc/corosync/corosync.conf
に書き込みます。
42
高可用性ガイド
6 必要な場合は、2つ目の通信チャネルを次で説明されるとおり定義します。
または［次へ］をクリックして、手順3.8「安全な認証を有効にす
る」 (44 ページ)で続行します。
手順 3.7 冗長通信チャネルの定義
ネットワークデバイスボンディングが何らかの理由で使用できない場合、第2
の選択は、Corosyncに冗長通信チャネル(2つ目のリング)を定義することです。
この方法では、2つの物理的に分かれたネットワークが通信に使用できます。
1つのネットワークが失敗しても、クラスタノードは、もう一方のネットワー
クを介して通信できます。
重要: 冗長リングおよび/etc/hosts
複数のリングが設定されている場合は、各ノードが複数のIPアドレスを持つ
ことができます。これはすべてのノードの/etc/hostsに反映する必要が
あります。
1 YaSTクラスタモジュール内で、［通信チャネル］カテゴリに切り替えま
す。
2 ［冗長チャネル］を有効にします。冗長チャネルは、定義した最初の通信
チャネルと同じプロトコルを使用する必要があります。
3 マルチキャストを使用する場合、［バインドネットワークアドレス］、［マ
ルチキャストアドレス］、および［マルチキャストポート］を冗長チャネ
ル用に定義します。
ユニキャストを使用する場合、［バインドネットワークアドレス］［マル
チキャストポート］を定義し、クラスタの一部になるすべてのノードのIP
アドレスを入力します。
これで、Corosyncに、2つ目のトークンパスリングを形成する追加の通信
チャネルを定義したことになります。/etc/corosync/corosync.conf
で、プライマリリング(設定した最初のチャネル)にはringnumber 0が設定さ
れ、2つ目のリング(冗長チャネル)にはringnumber 1が設定されます。
4 Corosyncに、異なるチャネルを使用する方法とタイミングを伝えるには、
使用したい［rrp_mode］(activeまたはpassive)を選択します。このモー
ドに関する詳細については、「冗長リングプロトコル(RRP)」 (27 ページ)
を参照するか、［ヘルプ］をクリックしてください。RRPが使用されると
インストールと基本セットアップ
43
ただちに、デフォルトでは、ノード間の通信に、(TCPの代わりに)SCTP
(Stream Control Transmission Protocol)が使用されます。High Availability
Extensionは現在のリングステータスを監視し、不具合が起きたら冗長リン
グを自動的に再有効化します。または、corosync-cfgtoolによって、リ
ングステータスを手動で確認することもできます。使用可能なオプション
は-hで参照できます。
通信チャネルが1つだけ定義されている場合、［rrp-mode］が自動的に無効
化されます(値なし)。
5 既存のクラスタでオプションを変更した場合、変更を確認して、クラスタ
モジュールを終了します。YaSTが設定を/etc/corosync/corosync.conf
に書き込みます。
6 クラスタ設定を先に進めるには、［次へ］をクリックして、3.5.3項「認証
設定の定義」 (44 ページ)で続行します。
/etc/corosync/corosync.conf.exampleで、UDPセットアップ用にファ
イル例を見つけます。UDPセットアップの例は/etc/corosync/corosync
.conf.example.udpuで参照できます。
3.5.3 認証設定の定義
次のステップでは、クラスタの認証設定を定義します。共有シークレットが
必要なHMAC/SHA1認証を使用して、メッセージを保護し、認証することがで
きます。指定した認証キー(パスワード)が、クラスタ中のすべてのノードで使
用されます。
手順 3.8 安全な認証を有効にする
1 YaSTクラスタモジュール内で、［Security］カテゴリに切り替えます。
2 ［安全認証の有効化］をオンにします。
3 新しく作成したクラスタの場合は、［認証キーファイルの生成］をクリッ
クします。認証キーが作成され、/etc/corosync/authkeyに書き込まれ
ます。
44
高可用性ガイド
図 3.4 YaSTクラスタ - セキュリティ
ご使用のマシンを既存のクラスタに参加させたい場合、新しいキーファイ
ルは生成しないでください。代わりに、いずれかのノードから/etc/
corosync/authkeyを(手動またはCsync2によって)ご使用のマシンにコ
ピーします。
4 既存のクラスタでオプションを変更した場合、変更を確認して、クラスタ
モジュールを終了します。YaSTが設定を/etc/corosync/corosync.conf
に書き込みます。
5 クラスタ設定を先に進めるには、［次へ］をクリックして、3.5.4項「すべ
てのノードへの設定の転送」 (46 ページ)で続行します。
インストールと基本セットアップ
45
3.5.4 すべてのノードへの設定の転送
結果として生成された設定ファイルをすべてのノードに手動でコピーする代
わりに、csync2ツールを使用して、クラスタ内のすべてのノードにレプリ
ケートします。
これには、次の基本手順を必要とします。
1 YaSTによるCsync2の設定 (46 ページ)。
2 Csync2による設定ファイルの同期 (48 ページ)。
Csync2では、設定変更を追跡して、クラスタノード間でファイルの同期を取
ることができます。
• 操作に対して重要なファイルのリストを定義できます。
• (他のクラスタノードに対して)これらのファイルの変更を表示できます。
• 1つのコマンドで複数の設定済みファイルの同期を取ることができます。
• ~/.bash_logoutの単純なシェルスクリプトを使用して、システムからロ
グアウトする前に、同期化されていない変更について通知できます。
Csync2の詳細については、http://oss.linbit.com/csync2/とhttp://
oss.linbit.com/csync2/paper.pdfにアクセスしてください。
手順 3.9 YaSTによるCsync2の設定
1 YaSTクラスタモジュール内で、［Csync2］カテゴリに切り替えます。
2 同期グループを指定するには、［同期ホスト］グループで［追加］をクリッ
クし、クラスタ内のすべてのノードのローカルホスト名を入力します。ノー
ドごとに、hostnameコマンドから返された文字列を正確に使用する必要
があります。
3 ［事前共有キーの生成］をクリックして、同期グループのキーファイルを
生成します。キーファイルは、/etc/csync2/key_hagroupに書き込ま
れます。このファイルは、作成後に、クラスタのすべてのメンバーに手動
でコピーする必要があります。
46
高可用性ガイド
4 すべてのノード間で、通常、同期される必要のあるファイルを［同期ファ
イル］リストに入れるには、［推奨ファイルの追加］をクリックします。
図 3.5 YaSTクラスタ - Csync2
5 同期するファイルのリストからファイルを［編集］、［追加］、または［削
除］する場合は、該当する各ボタンを使用します。ファイルごとに絶対パ
ス名を入力する必要があります。
6 ［Csync2をオンにする］をクリックして、Csync2をアクティブにします。
これによってchkconfig csync2が実行され、ブート時にCsync2が自動的
に起動します。
7 既存のクラスタでオプションを変更した場合、変更を確認して、クラスタ
モジュールを終了します。YaSTがCsync2の設定内容を/etc/csync2/
csync2.cfgに書き込みます。ここで同期プロセスを開始するには、手順
3.10「Csync2による設定ファイルの同期」 (48 ページ)で続行します。
インストールと基本セットアップ
47
8 クラスタ設定を先に進めるには、［次へ］をクリックして、3.5.5項「クラ
スタノード間の接続ステータスの同期」 (49 ページ)で続行します。
手順 3.10 Csync2による設定ファイルの同期
Csync2でファイルを正常に同期するには、次の前提条件を満たしておく必要
があります。
• 同じCsync2設定をすべてのノードで使用できる必要があります。ファイ
ル/etc/csync2/csync2.cfgを、手順3.9「YaSTによるCsync2の設
定」 (46 ページ)で説明されるとおりに設定した後、すべてのノードに手動
でコピーします。このファイルはCsync2で同期されるファイルのリストに
含めることを推奨します。
• ステップ 3 (46 ページ)の1つのノードで作成した/etc/csync2/key
_hagroupファイルを、クラスタ内のすべてのノードにコピーしてくださ
い。このファイルは、Csync2による認証で必要になります。ただし、すべ
てのノードで同じファイルでなければならないので、他のノードではファ
イルを再生成しないでください。
• Csync2およびxinetdの両方がすべてのノード上で実行している必要があり
ます。
注記: ブート時にサービスを開始
すべてのノード上で次のコマンドを実行し、両サービスをブート時に自
動的に開始させ、すぐにxinetdを起動させます。
root # chkconfig csync2 on
chkconfig xinetd on
rcxinetd start
1 設定をコピーしたいノードから、次のコマンドを実行します。
root # csync2 -xv
これによって、すべてのファイルをその他のノードにプッシュすることで、
一度に同期を行います。すべてのファイルが正常に同期されると、Csync2
がエラーなしで終了します。
48
高可用性ガイド
同期対象の1つ以上のファイルが(現在のノードだけでなく)他のノード上で
変更されている場合は、Csync2から衝突が報告されます。次の出力とよく
似た出力が表示されます。
While syncing file /etc/corosync/corosync.conf:
ERROR from peer hex-14: File is also marked dirty here!
Finished with 1 errors.
2 現在のノードのファイルバージョンが「最良」だと確信する場合は、その
ファイルを強制して再同期を行い、競合を解決できます。
root # csync2 -f /etc/corosync/corosync.conf
csync2 -x
Csync2オプションの詳細については、csync2 -helpを実行してください。
注記: 変更後の同期のプッシュ
Csync2は変更のみをプッシュします。ノード間のファイルを絶えず同期し
ているわけではありません。
同期が必要なファイルを更新する際はいつも、変更を加えたノード上で
csync2 -xvを実行することで、変更をその他のノードにプッシュする必
要があります。変更されていないファイルを持つその他のノード上でこの
コマンドを実行しても、何も起こりません。
3.5.5 クラスタノード間の接続ステータスの
同期
iptablesに対してステートフルなパケット検査ができるようにするには、
conntrackツールを設定して使用します。
1 YaSTによるconntrackdの設定 (50 ページ)。
2 conntrackd (クラス: ocf、プロバイダ: heartbeat)のリソースの設定。
Hawkを使用する場合、Hawkによって提案されるデフォルト値を使用しま
す。
conntrackツールを設定したら、これをLinux仮想サーバによる負荷分
散 (259 ページ)に使用できます。
インストールと基本セットアップ
49
手順 3.11 YaSTによるconntrackdの設定
YaSTクラスタモジュールを使用して、ユーザスペースconntrackdを設定し
ます。これには、その他の通信チャネルに使用されていない専用のネットワー
クインタフェースが必要です。デーモンは後でリソースエージェントによっ
て起動できます。
1 YaSTクラスタモジュール内で、［conntrackdの設定］カテゴリに切り替え
ます。
2 ［専用インタフェース］を選択して、接続ステータスを同期します。選択
したインタフェースのIPv4アドレスが自動的に検出され、YaSTに表示され
ます。これはすでに設定済みで、マルチキャストをサポートしている必要
があります。
3 接続ステータスの同期に使用する［マルチキャストアドレス］を定義しま
す。
4 ［グループ番号］で、接続ステータスを同期させるグループのID番号を定
義します。
5 ［/etc/conntrackd/conntrackd.conf の生成］をクリックして、conntrackdの
設定ファイルを作成します。
6 既存のクラスタでオプションを変更した場合、変更を確認して、クラスタ
モジュールを終了します。
7 クラスタ設定を先に進めるには、［次へ］をクリックして、3.5.6項「サー
ビスの設定」 (51 ページ)で続行します。
50
高可用性ガイド
図 3.6 YaSTクラスタ - conntrackd
3.5.6 サービスの設定
YaSTクラスタモジュールは、ブート時にノード上で一定のサービスを開始す
るかどうか定義します。サービスを手動で開始または停止するためにモジュー
ルを使用することもできます。クラスタノードをオンラインにし、クラスタ
リソースマネージャを起動するには、OpenAISをサービスとして実行する必要
があります。
手順 3.12 クラスタサービスの有効化
1 YaSTクラスタモジュール内で、［サービス］カテゴリに切り替えます。
2 このクラスタノードがブートするたびにOpenAISを開始するには、［ブー
ト］グループで該当するオプションを選択します。［ブート］グループで、
［オフ］を選択する場合は、このノードがブートするたびに手動でOpenAIS
を起動する必要があります。OpenAISを手動で起動するには、
rcopenais startコマンドを使用します。
インストールと基本セットアップ
51
注記: OpenAISのNo-Start-on-Bootパラメータ
起動/停止スクリプトも含め、クラスタサービスをブート時に全般的に無
効にすると、クラスタ設定が破損することがありますが、ブート時にク
ラスタサービスを無条件に有効にした場合も、フェンシングに対して望
ましくない影響が発生する可能性があります。
このような状況を防止できるように調整するには、/etc/sysconfig/
openaisにSTART_ON_BOOTパラメータを挿入します。
START_ON_BOOT=Noに設定すると、ブート時にOpenAISサービスが起動
しなくなり、稼働中に必要に応じて手動で起動できるようになります。
デフォルトではSTART_ON_BOOT=Yesに設定されています。
3 クラスタリソースの設定、管理、および監視に、Pacemaker GUIを使用する
場合は、［mgmtdを有効にする］をオンにします。このデーモンは、GUIの
ために必要です。
4 OpenAISをただちに開始または停止するには、それぞれのボタンをクリッ
クします。
5 現在のマシン上でのクラスタ通信に必要なポートをファイアウォールで開
くには、［ファイアウォールでポートを開く］をアクティブにします。こ
の設定は、/etc/sysconfig/SuSEfirewall2.d/services/cluster
に書きこまれます。
6 既存のクラスタノードでオプションを変更した場合、変更を確認して、ク
ラスタモジュールを終了します。この設定は、すべてのクラスタノードで
はなく、ご使用のマシンにのみ適用されることにご注意ください。
YaSTクラスタモジュールでのみ最初のクラスタセットアップを完了してい
る場合、ここで基本的な設定手順が完了したことになります。3.5.7項「ク
ラスタをオンラインにする」 (53 ページ)に従って手順を進めます。
52
高可用性ガイド
図 3.7 YaSTクラスタ - サービス
3.5.7 クラスタをオンラインにする
最初のクラスタ設定が完了した後、各クラスタノード上でOpenAIS/Corosync
サービスを開始し、スタックをオンラインにします。
手順 3.13 OpenAIS/Corosyncを起動してステータスをチェック
1 既存のノードにログインします。
2 サービスがすでに実行していることを確認します。
root # rcopenais status
実行していない場合、OpenAIS/Corosyncをすぐに起動します。
root # rcopenais start
インストールと基本セットアップ
53
3 それぞれのクラスタノードに対してこの手順を繰り返します。
4 ノードの1つで、crm statusコマンドを使用してクラスタの状態を確認し
ます。すべてのノードがオンラインの場合、出力は次のようになります。
root # crm status
Last updated: Thu Jul 3 11:07:10 2014
Last change: Thu Jul 3 10:58:43 2014
Current DC: alice (175704363) - partition with quorum
2 Nodes configured
0 Resources configured
Online: [ alice bob ]
この出力は、クラスタリソースマネージャが起動し、リソースを管理でき
る状態にあることを示しています。
基本設定が完了し、ノードがオンラインになった後、crmシェルやPacemaker
GUI、HA Web Konsoleなどのクラスタ管理ツールのいずれかを使用して、ク
ラスタリソースの設定を開始できます。詳細については、次の章を参照して
ください。
3.6 AutoYaSTによる大量展開
既存ノードのクローンであるクラスタノードを展開する場合は、次の手順を
使用できます。クローンしたノードには、同じパッケージがインストールさ
れ、クローンノードは同じシステム設定を持つことになります。
手順 3.14 AutoYaSTによるクラスタノードのクローン作成
重要: 同一のハードウェアを使用している環境
このシナリオでは、同じハードウェア構成を持つ一群のマシンにSUSE Linux
Enterprise High Availability Extension 11 SP4を展開していることを前提とし
ています。
構成が互いに異なるハードウェアにクラスタノードを展開する必要がある場
合は、http://www.suse.com/docで入手できる『SUSE Linux Enterprise 11
SP4 導入ガイド』の「自動インストール」の章にあるセクション「ルールベー
スの自動インストール」を参照してください。
54
高可用性ガイド
1 クローンを作成するノードが正しくインストールされ、設定されているこ
とを確認します。詳細については、3.3項「アドオンとしてのインストー
ル」 (30 ページ)、3.4項「自動のクラスタセットアップ(slehabootstrap)」 (31 ページ)、または3.5項「手動のクラスタセットアップ
(YaST)」 (37 ページ)をそれぞれ参照してください。
2 単純な大量インストールについては、『SUSE Linux Enterprise 11 SP4 導入
ガイド』の説明に従ってください。これには、次の基本ステップがありま
す。
2a AutoYaSTプロファイルの作成AutoYaST GUIを使用して、既存のシス
テム設定をもとにプロファイルを作成し、変更します。AutoYaSTで
は、［高可用性］モジュールを選択し、［クローン］ボタンをクリッ
クします。必要な場合は、他のモジュールの設定を調整し、その結
果のコントロールファイルをXMLとして保存します。
2b AutoYaSTプロファイルのソースと、他のノードのインストールルー
チンに渡すパラメータを決定します。
2c SUSE Linux Enterprise ServerのソースとSUSE Linux Enterprise High
Availability Extensionインストールデータを決定します。
2d 自動インストールのブートシナリオを決定し、設定します。
2e パラメータを手動で追加するか、またはinfoファイルを作成するこ
とにより、インストールルーチンにコマンド行を渡します。
2f 自動インストールプロセスを開始および監視します。
クローンのインストールに成功したら、次の手順を実行して、クローンノー
ドをクラスタに加えます。
手順 3.15 クローンノードをオンラインにする
1 3.5.4項「すべてのノードへの設定の転送」 (46 ページ)の説明に従って、
Csync2を使用して、設定済みのノードからクローンノードへ重要な設定ファ
イルを転送します。
インストールと基本セットアップ
55
2 ノードをオンラインにするには、3.5.7項「クラスタをオンラインにす
る」 (53 ページ)の説明のとおり、クローンノード上でOpenAISサービスを
開始します。
これで、/etc/corosync/corosync.confファイルがCsync2を介してクロー
ンノードに適用されたので、クローンノードがクラスタに加わります。CIB
は、クラスタノード間で自動的に同期されます。
56
高可用性ガイド
パート II. 設定および管理
設定および管理の基本事項
4
HAクラスタの主な目的はユーザサービスの管理です。ユーザサービスの典型
的な例は、Apache Webサーバまたはデータベースです。サービスとは、ユー
ザの観点からすると、指示に基づいて特別な何かを行うことを意味していま
すが、クラスタにとっては開始や停止できるリソースにすぎません。サービ
スの性質はクラスタには無関係なのです。
この章では、リソースを設定しクラスタを管理する場合に知っておく必要の
ある基本概念を紹介します。後続の章では、High Availability Extensionが提供
する各管理ツールを使用して、主要な設定および管理タスクを行う方法を説
明します。
4.1 グローバルクラスタオプション
グローバルクラスタオプションは、一定の状況下でのクラスタの動作を制御
します。それらは、セットにグループ化され、Hawkやcrmシェルなどのクラ
スタ管理ツールで表示したり、変更することができます。
4.1.1 概要
すべてのグローバルクラスタオプションとそのデフォルト値の概要について
は、『Pacemaker Explained』(http://www.clusterlabs.org/doc/から入
手可)を参照してください。特に、「Available Cluster Options」のセクションを
参照してください。
設定および管理の基本事項
59
事前に定義されている値は、通常は、そのまま保持できます。ただし、クラ
スタの主要機能を正しく機能させるには、クラスタの基本的なセットアップ
後に、次のパラメータを調整する必要があります。
• オプションno-quorum-policy (60 ページ)
• オプションstonith-enabled (61 ページ)
これらのパラメータを調整する方法については、使用しているクラスタ管理
ツールに応じて次のいずれかを参照してください。
• Hawk: 手順5.3「グローバルクラスタオプションを変更する」 (108 ページ)
• Pacemaker GUI: 手順6.1「グローバルクラスタオプションを変更す
る」 (157 ページ)
• crmシェル: 7.2項「グローバルクラスタオプションの設定」 (198 ページ)
4.1.2 オプションno-quorum-policy
このグローバルオプションは、クラスタパーティションにクォーラムがない
(ノードの過半数がパーティションに含まれない)場合どうするかを定義しま
す。
許容値は、次のとおりです。
ignore
クォーラム状態がクラスタの動作に影響せず、リソース管理が続行されま
す。
この設定は、次のシナリオで有効です。
• 2ノードクラスタ: 1つのノードに障害が発生すると、常に過半数が
失われるため、通常は、構わずクラスタを続行させます。リソース
の整合性は、フェンシングの使用で確保されます。フェンシング
は、スプリットブレインシナリオも防止します。
• リソース駆動型クラスタ: 冗長な通信チャネルを持つローカルクラ
スタの場合、スプリットブレインシナリオには一定の確率しかあり
ません。したがって、ノードとの通信の喪失は、ほとんどの場合、
60
高可用性ガイド
そのノードがクラッシュしていること、残りのノードは回復して、
リソースのサービスを再開する必要があることを示します。
no-quorum-policyがignoreに設定されている場合、4ノードク
ラスタは、サービスが失われる前の3ノードの同時障害を克服でき
ますが、他の設定値では、2ノードの同時障害後はクォーラムを失
います。
freeze
クォーラムが失われた場合は、クラスタパーティションがフリーズしま
す。リソース管理は続行されます。実行中のリソースは停止されません
(ただし、イベントの監視に対応して再起動される可能性があります)。た
だし、影響を受けたパーティション内では、以後のリソースが開始されま
せん。
一定のリソースが他のノードとの通信に依存しているクラスタの場合(た
とえば、OCFS2マウントなど)は、この設定が推奨されます。この場合、
デフォルト設定no-quorum-policy=stopは、次のようなシナリオにな
るので有効でありません。つまり、ピアノードが到達不能な間はそれらの
リソースを停止できなくなります。その代わり、停止の試行は最終的にタ
イムアウトし、stop failureになり、エスカレートされた復元とフェ
ンシングを引き起こします。
stop (デフォルト値)
クォーラムが失われると、影響を受けるクラスタパーティション内のすべ
てのリソースが整然と停止します。
suicide
クォーラムが失われると、影響を受けるクラスタパーティション内のすべ
てのノードがフェンシングされます。
4.1.3 オプションstonith-enabled
このグローバルオプションは、フェンシングを適用して、STONITHデバイス
による、障害ノードや停止できないリソースを持つノードのダウンを許可す
るかどうか定義します。通常のクラスタ操作には、STONITHデバイスの使用
が必要なので、このグローバルオプションは、デフォルトでtrueに設定され
ています。デフォルト値では、クラスタは、STONITHリソースが定義されて
いない場合にはリソースの開始を拒否します。
設定および管理の基本事項
61
何らかの理由でフェンシングを無効にする必要がある場合は、
stonith-enabledをfalseに設定しますが、これはご使用の製品のサポー
トステータスに影響を及ぼすことに注意してください。また、
stonith-enabled="false"を指定すると、Distributed Lock Manager (DLM)
のようなリソースやDLMによるすべてのサービス(cLVM2、GFS2、OCFS2な
ど)は開始できません。
重要: STONITHがない場合はサポートなし
STONITHがないクラスタはサポートされません。
4.2 クラスタリソース
クラスタの管理者は、クラスタ内のサーバ上の各リソースや、サーバ上で実
行する各アプリケーションに対してクラスタリソースを作成する必要があり
ます。クラスタリソースには、Webサイト、電子メールサーバ、データベー
ス、ファイルシステム、仮想マシン、およびユーザが常時使用できるように
する他のサーバベースのアプリケーションまたはサービスなどが含まれます。
4.2.1 リソース管理
リソースは、クラスタで使用する前にセットアップする必要があります。た
とえば、Apacheサーバをクラスタリソースとして使用する場合は、まず、
Apacheサーバをセットアップし、Apacheの環境設定を完了してから、クラス
タで個々のリソースを起動します。
リソースに特定の環境要件がある場合は、それらの要件がすべてのクラスタ
ノードに存在し、同一であることを確認してください。この種の設定は、High
Availability Extensionでは管理されません。これは、管理者自身が行う必要が
あります。
注記: クラスタによって管理されるサービスには介入しないでください。
High Availability Extensionでリソースを管理しているときに、同じリソース
を他の方法(クラスタ外で、たとえば、手動、ブート、再起動など)で開始し
たり、停止してはなりません。High Availability Extensionソフトウェアが、
すべてのサービスの開始または停止アクションを実行します。
62
高可用性ガイド
サービスがクラスタ制御下ですでに実行された後にテストまたは保守タス
クを実行する必要がある場合は、リソース、ノード、またはクラスタ全体
を保守モードに設定してから、これらのいずれかに手動でタッチしてくだ
さい。詳細については、4.7項「メンテナンスモード」 (97 ページ)を参照
してください。
クラスタ内でリソースを設定したら、クラスタ管理ツールを使用して、すべ
てのリソースを手動で起動、停止、クリーンアップ、削除、または移行しま
す。これらの操作の詳細については、使用しているクラスタ管理ツールに応
じて次のいずれかを参照してください。
• Hawk: 第5章クラスタリソースの設定と管理(Webインタフェース) (101 ページ)
• Pacemaker GUI: 第6章クラスタリソースの設定と管理(GUI) (153 ページ)
• crmシェル: 第7章クラスタリソースの設定と管理(コマンドライン)(189 ページ)
4.2.2 サポートされるリソースエージェント
クラス
追加するクラスタリソースごとに、リソースエージェントが準拠する基準を
定義する必要があります。リソースエージェントは、提供するサービスを抽
象化して正確なステータスをクラスタに渡すので、クラスタは管理するリソー
スについてコミットする必要がありません。クラスタは、リソースエージェ
ントに依存して、start、stop、またはmonitorのコマンドの発行に適宜対応しま
す。
通常、リソースエージェントはシェルスクリプトの形式で配布されます。High
Availability Extensionは、次のクラスのリソースエージェントをサポートして
います。
Linux Standards Base (LSB)スクリプト
LSBリソースエージェントは一般にオペレーティングシステム/配布パッ
ケージによって提供され、/etc/init.dにあります。リソースエージェ
ントをクラスタで使用するには、それらのエージェントがLSB iniスクリ
プトの仕様に準拠している必要があります。たとえば、リソースエージェ
ントには、いくつかのアクションが実装されている必要があります。それ
らのアクションとして、少なくともstart、stop、restart、reload、
設定および管理の基本事項
63
force-reload、statusがあります。詳細については、http://
refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB
-Core-generic/iniscrptact.htmlを参照してください。
これらのサービスの構成は標準化されていません。High AvailabilityでLSB
スクリプトを使用する場合は、該当のスクリプトの設定方法を理解する必
要があります。これに関する情報は、多くの場合、/usr/share/doc/
packages/PACKAGENAME内の該当パッケージのマニュアルに記載されて
います。
Open Cluster Framework (OCF)リソースエージェント
OCF RAエージェントは、High Availabilityでの使用に最適であり、特に、
マルチステートリソースまたは特殊なモニタリング機能を必要とする場合
に適しています。それらのエージェントは、通常、/usr/lib/ocf/
resource.d/providerにあります。この機能はLSBスクリプトの機能
と同様です。ただし、環境設定では、常に、パラメータの受け入れと処理
を容易にする環境変数が使用されます。OCF仕様はhttp://www.opencf
.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt
?rev=HEAD&content-type=text/vnd.viewcvs-markupで参照でき
ます(リソースエージェントに関連するため)。OCF仕様には、アクション
終了コードの厳密な定義があります。8.3項「OCF戻りコードと障害回
復」 (223 ページ)を参照してください。クラスタは、それらの仕様に正確
に準拠します。
すべてのOCFリソースエージェントは少なくともstart、stop、status、
monitor、meta-dataのアクションを持つ必要があります。meta-data
アクションは、エージェントの設定方法についての情報を取得します。た
とえば、プロバイダheartbeatでIPaddrエージェントの詳細を知りたい
場合は、次のコマンドを使用します。
OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/IPaddr meta-data
出力は、XML形式の情報であり、いくつかのセクションを含みます(一般
説明、利用可能なパラメータ、エージェント用の利用可能なアクション)。
または、crmshを使用して、OCFリソースエージェントに関する情報を表
示します。詳細については、7.1.3項「OCFリソースエージェントに関す
る情報の表示」 (193 ページ)を参照してください。
64
高可用性ガイド
STONITH(フェンシング)リソースエージェント
このクラスは、フェンシング関係のリソース専用に使用されます。詳細に
ついては、第9章フェンシングとSTONITH (227 ページ)を参照してくださ
い。
High Availability Extensionで提供されるエージェントは、OCF仕様に従って作
成されています。
4.2.3 リソースのタイプ
次のリソースタイプを作成できます。
プリミティブ
プリミティブリソースは、リソースの中で最も基本的なタイプです。
選択したクラスタ管理ツールでプリミティブリソースを作成する方法につ
いては、次を参照してください。
• Hawk: 手順5.5「プリミティブリソースを追加する」 (112 ページ)
• Pacemaker GUI: 手順6.2「プリミティブリソースを追加す
る」 (158 ページ)
• crmシェル: 7.3.1項「クラスタリソースの作成」 (200 ページ)
グループ
グループには、一緒の場所で見つけ、連続して開始し、逆の順序で停止す
る必要のあるリソースセットが含まれます。詳細については、4.2.5.1項
「グループ」 (66 ページ)を参照してください。
クローン
クローンは、複数のホスト上でアクティブにできるリソースです。対応す
るリソースエージェントがサポートしていれば、どのようなリソースもク
ローン化できます。詳細については、4.2.5.2項「クローン」 (68 ページ)
を参照してください。
マルチステートリソース(旧称はマスタ/スレーブリソース)
マルチステートリソースは、クローンリソースの特殊なタイプで、複数の
モードを持つことができます。詳細については、4.2.5.3項「マルチステー
トリソース」 (69 ページ)を参照してください。
設定および管理の基本事項
65
4.2.4 リソーステンプレート
類似した設定のリソースを多く作成する最も簡単な方法は、リソーステンプ
レートを定義することです。定義された後でテンプレートは、プリミティブ
内で参照したり、4.4.3項「リソーステンプレートと制約」 (84 ページ)で説明
するように、特定のタイプの制約内で参照することができます。
プリミティブ内でテンプレートを参照すると、そのテンプレートで定義され
ている操作、インスタンス属性(パラメータ)、メタ属性、使用属性がすべてプ
リミティブに継承されます。さらに、プリミティブに対して特定の操作また
は属性を定義することもできます。これらのいずれかがテンプレートとプリ
ミティブの両方で定義されていた場合、プリミティブで定義した値の方が、
テンプレートで定義された値よりも優先されます。
選択したクラスタ管理ツールでリソーステンプレートを定義する方法につい
ては、次を参照してください。
• Hawk: 5.3.4項「リソーステンプレートの使用」 (116 ページ)
• crmシェル: 7.3.2項「リソーステンプレートの作成」 (200 ページ)
4.2.5 高度なリソースタイプ
プリミティブは、最も単純なタイプのリソースなので、設定が容易ですが、
クラスタ設定には、より高度なリソースタイプ(グループ、クローン、マルチ
ステートリソースなど)が必要になることがあります。
4.2.5.1 グループ
クラスタリソースの中には、他のコンポーネントやリソースに依存している
ものもあります。それぞれのコンポーネントやリソースが決められた順序で
開始され、依存しているリソースと同じサーバ上で同時に実行していなけれ
ばならない場合があります。この設定を簡素化するには、クラスタリソース
グループを使用できます。
例 4.1 Webサーバのリソースグループ
リソースグループの1例として、IPアドレスとファイルシステムを必要とする
Webサーバがあります。この場合、各コンポーネントは、個々のリソースで
66
高可用性ガイド
あり、それらが組み合わされてクラスタリソースグループを構成します。リ
ソースグループは、1つ以上のサーバで実行されます。ソフトウェアまたは
ハードウェアが機能しない場合には、個々のクラスタリソースと同様に、グ
ループはクラスタ内の別のサーバにフェールオーバーします。
図 4.1 グループリソース
グループには次のプロパティがあります。
開始/停止
リソースは認識される順序で開始し、逆の順番で停止します。
依存関係
グループ内のリソースがどこかで開始できない場合は、グループ内のその
後の全リソースは実行することができません。
コンテンツ
グループにはプリミティブクラスタリソースしか含むことができません。
グループには1つ以上のリソースを含む必要があります。空の場合は設定
は無効になります。グループリソースの子を参照するには、グループのID
ではなく子のIDを使用します。
制約
制約でグループの子を参照することはできますが、通常はグループ名を使
用することをお勧めします。
設定および管理の基本事項
67
固着性
固着性はグループ内で統合可能なプロパティです。グループ内のアクティ
ブな各メンバーは、グループの合計値に対して固着性を追加します。した
がって、デフォルトのresource-stickinessが100で、グループに7つ
のメンバーがあり、そのうち5つがアクティブな場合は、グループが全体
として、スコア500で、現在の場所を優先します。
リソース監視
グループのリソース監視を有効にするには、グループ内で監視の必要な各
リソースに対して監視を設定する必要があります。
選択したクラスタ管理ツールでグループを作成する方法については、次を参
照してください。
• Hawk: 手順5.16「リソースグループを追加する」 (129 ページ)
• Pacemaker GUI: 手順6.13「リソースグループを追加する」 (177 ページ)
• crmシェル: 7.3.9項「クラスタリソースグループの構成」 (210 ページ)
4.2.5.2 クローン
クラスタ内の複数のノードで特定のリソースを同時に実行することができま
す。このためには、リソースをクローンとして設定する必要があります。ク
ローンとして設定するリソースの1例として、STONITHや、OCFS2などのクラ
スタファイルシステムが挙げられます。提供されているどのリソースも、ク
ローンとして設定できます。これは、リソースのリソースエージェントによっ
てサポートされます。クローンリソースは、ホスティングされているノード
によって異なる設定をすることもできます。
リソースクローンには次の3つのタイプがあります。
匿名クローン
最も簡単なクローンタイプです。実行場所にかかわらず、同じ動作をしま
す。このため、マシンごとにアクティブな匿名クローンのインスタンスは
1つだけ存在できます。
68
高可用性ガイド
グローバルに固有なクローン
このリソースは独自のエントリです。1つのノードで実行しているクロー
ンのインスタンスは、別なノードの別なインスタンスとは異なり、同じ
ノードの2つのインスタンスが同一になることもありません。
ステートフルなクローン (マルチステートリソース)
このリソースのアクティブインスタンスは、アクティブとパッシブという
2つの状態に分けられます。プライマリとセカンダリ、またはマスタとス
レーブと呼ばれることもあります。ステートフルなクローンが、匿名また
はグローバルに固有の場合もあります。4.2.5.3項「マルチステートリソー
ス」 (69 ページ)も参照してください。
クローンは、グループまたは通常リソースを1つだけ含む必要があります。
リソースのモニタリングまたは制約を設定する場合、クローンには、単純な
リソースとは異なる要件があります。詳細については、『PacemakerExplained』
(http://www.clusterlabs.org/doc/から入手可)を参照してください。
特に、「Clones - Resources That Get Active on Multiple Hosts」のセクションを参
照してください。
選択したクラスタ管理ツールでクローンを作成する方法については、次を参
照してください。
• Hawk: 手順5.17「クローンを追加または変更する」 (131 ページ)
• Pacemaker GUI: 手順6.15「クローンを追加または変更する」 (181 ページ)
• crmシェル: 7.3.10項「クローンリソースの設定」 (211 ページ)
4.2.5.3 マルチステートリソース
マルチステートリソースは、クローンが得意とするところです。これにより、
インスタンスを2つの動作モード(masterまたはslaveと呼ばれているが、任
意の名前を割り当てることができる)のいずれかに設定できます。マルチス
テートリソースは、グループまたは通常リソースを1つだけ含む必要がありま
す。
リソースの監視または制約を設定する場合、マルチステートリソースには、
単純なリソースとは異なる要件があります。詳細については、『Pacemaker
Explained』(http://www.clusterlabs.org/doc/から入手可)を参照して
設定および管理の基本事項
69
ください。特に、「Multi-state - Resources That Have Multiple Modes」のセク
ションを参照してください。
4.2.6 リソースオプション(メタ属性)
追加した各リソースについて、オプションを定義できます。クラスタはオプ
ションを使用して、リソースの動作方法を決定します。CRMに特定のリソー
スの処理方法を通知します。リソースオプションは、crm_resource --meta
コマンドまたはPacemaker GUIを使用して設定できます(手順6.3「メタ属性お
よびインスタンス属性を追加または変更する」 (160 ページ)参照)。または、
Hawkを使用してください(手順5.5「プリミティブリソースを追加す
る」 (112 ページ)参照)。
表 4.1 プリミティブリソースのオプション
70
オプション
説明
デフォルト
優先度
一部のリソースをア
クティブにできない
場合、クラスタは優
先度の低いリソース
を停止して、優先度
の高いリソースをア
クティブに維持しま
す。
0
target-role
クラスタが維持しよ
うとするこのリソー
スの状態。使用でき
る値: stopped、
started、master
開始日
is-managed
クラスタがリソース
を開始して停止でき
るかどうか。使用で
きる値:true、false
値がfalseに設定さ
れる場合、リソース
true
高可用性ガイド
オプション
説明
デフォルト
のステータスは依然
として監視され、何
らかの失敗が報告さ
れます
(maintenance="true"へ
のリソースの設定と
は異なります)。
保守モードほしゅ
もーど
リソースは手動で
タッチできるかどう
か。使用できる
値:true、
falsetrueに設定す
ると、すべてのリ
ソースが非管理対象
になり、クラスタに
よる監視が停止され
るため、ステータス
は追跡されなくなり
ます。クラスタに
よってクラスタリ
ソースの再起動が試
行される代わりに、
ユーザがクラスタリ
ソースを停止または
再起動できます。
false
resource-stickiness
リソースが現在の状
態をどの程度維持し
たいか。
rsc_defaultsセク
ションの
default-resource-stickiness
のデフォルト値。
計算済み
設定および管理の基本事項
71
72
オプション
説明
デフォルト
migration-threshold
ノードがこのリソー
スをホストできなく
なるまで、このリ
ソースについてノー
ド上で発生する失敗
の回数。
INFINITY (無効)
multiple-active
複数のノードでアク
ティブなリソースを
検出した場合のクラ
スタの動作。使用で
きる値: block (リ
ソースを管理されて
いないとマークす
る)、stop_only、
stop_start
stop_start
failure-timeout
失敗が発生していな
いように動作する(リ
ソースを失敗した
ノードに戻す)前に、
待機する秒数
0 (無効)
allow-migrate
migrate_toまたは
migrate_fromのア
クションをサポート
するリソースにリ
ソース移行を許可。
false
remote-node
このリソースが定義
するリモートノード
の名前。これによ
り、リモートノード
のリソースが有効化
されるだけでなく、
リモートノードの識
なし(無効)
高可用性ガイド
オプション
説明
デフォルト
別に使用される固有
の名前が定義されま
す。他のパラメータ
が設定されていない
場合、この値は
remote-portの接続先の
ホスト名とも見なさ
れます。port.
警告: 固有のIDの使
用
この値は、既存の
リソースやノードID
とは重複させない
でください。
remote-port
pacemaker_remoteへの
ゲスト接続用のカス
タムポート。
3121
remote-addr
リモートノードの名
前がゲストのホスト
名ではない場合に接
続するIPアドレスまた
はホスト名。
remote-node (ホス
ト名として使用され
る値)
remote-connect-timeout
中断したゲスト接続
がタイムアウトする
までの時間。
60s
4.2.7 インスタンス属性(パラメータ)
すべてのリソースクラスのスクリプトでは、動作方法および管理するサービ
スのインスタンスを指定するパラメータを指定できます。リソースエージェ
設定および管理の基本事項
73
ントがパラメータをサポートする場合、それらのパラメータをcrm_resource
コマンドまたはGUIを使用して追加できます(手順6.3「メタ属性およびインス
タンス属性を追加または変更する」 (160 ページ)参照)。または、Hawkを使用
してください(手順5.5「プリミティブリソースを追加する」(112 ページ)参照)。
インスタンス属性は、crmコマンドラインユーティリティではparams、Hawk
ではParameterと呼ばれます。OCFスクリプトでサポートされているインス
タンス属性のリストは、次のコマンドをrootとして実行すると参照できま
す。
root # crm ra info [class:[provider:]]resource_agent
または(オプション部分なし):
root # crm ra info resource_agent
出力には、サポートされているすべての属性、それらの目的、およびデフォ
ルト値が一覧されます。
たとえば、次のコマンドを使用します。
root # crm ra info IPaddr
次の出力が返されます。
Manages virtual IPv4 addresses (portable version) (ocf:heartbeat:IPaddr)
This script manages IP alias IP addresses
It can add an IP alias, or remove one.
Parameters (* denotes required, [] the default):
ip* (string): IPv4 address
The IPv4 address to be configured in dotted quad notation, for example
"192.168.1.1".
nic (string, [eth0]): Network interface
The base network interface on which the IP address will be brought
online.
If left empty, the script will try and determine this from the
routing table.
Do NOT specify an alias interface in the form eth0:1 or anything here;
rather, specify the base interface only.
cidr_netmask (string): Netmask
The netmask for the interface in CIDR format. (ie, 24), or in
dotted quad notation 255.255.255.0).
74
高可用性ガイド
If unspecified, the script will also try to determine this from the
routing table.
broadcast (string): Broadcast address
Broadcast address associated with the IP. If left empty, the script will
determine this from the netmask.
iflabel (string): Interface label
You can specify an additional label for your IP address here.
lvs_support (boolean, [false]): Enable support for LVS DR
Enable support for LVS Direct Routing configurations. In case a IP
address is stopped, only move it to the loopback device to allow the
local node to continue to service requests, but no longer advertise it
on the network.
local_stop_script (string):
Script called when the IP is released
local_start_script (string):
Script called when the IP is added
ARP_INTERVAL_MS (integer, [500]): milliseconds between gratuitous ARPs
milliseconds between ARPs
ARP_REPEAT (integer, [10]): repeat count
How many gratuitous ARPs to send out when bringing up a new address
ARP_BACKGROUND (boolean, [yes]): run in background
run in background (no longer any reason to do this)
ARP_NETMASK (string, [ffffffffffff]): netmask for ARP
netmask for ARP - in nonstandard hexadecimal format.
Operations' defaults (advisory minimum):
start
stop
monitor_0
timeout=90
timeout=100
interval=5s timeout=20s
注記: グループ、クローン、またはマルチステートリソースのインスタンス
属性
グループ、クローン、およびマルチステートリソースには、インスタンス
属性がないので注意してください。ただし、インスタンス属性のセットは、
グループ、クローン、またはマルチステートリソースの子によって継承さ
れます。
設定および管理の基本事項
75
4.2.8 リソース操作
デフォルトで、クラスタはリソースが良好な状態であることを保証しません。
クラスタにこれを行わせるには、リソースの定義に監視操作を追加する必要
があります。監視操作は、すべてのクラスまたはリソースエージェントに追
加できます。詳細については、4.3項「リソース監視」 (79 ページ)を参照し
てください。
表 4.2 リソース操作のプロパティ
操作
説明
id
アクションに指定する名前。一意
にする必要があります。(IDは表示
されません)
name
実行するアクション。共通の値:
monitor、start、stop
interval
操作を実行する頻度。単位: 秒
timeout
アクションが失敗したと宣言する
前に待機する長さ。
requires
このアクションが発生する前に満
たす必要のある条件。使用できる
値: nothing、quorum、fencing
デフォルトは、フェンシングが有
効でリソースのクラスがstonith
かどうかによります。STONITHリ
ソースの場合、デフォルトは
nothingです。
on-fail
このアクションが失敗した場合に
実行するアクション。使用できる
値:
• ignore: リソースが失敗しな
かったのように動作します。
76
高可用性ガイド
操作
説明
• block: リソースにこれ以上の操
作を実行しません。
• stop: リソースを停止して、他
の場所でも開始しません。
• restart: リソースを停止して再
起動します(別のノード上で)。
• fence: リソースが失敗したノー
ドを停止します(STONITH)。
• standby: リソースが失敗した
ノードからすべてのリソースを
移動させます。
enabled
falseの場合、操作は存在してい
ない場合と同様に処理されます。
使用できる値:true、false
role
リソースにこの役割がある場合の
み操作を実行します。
record-pending
グローバルに設定したり、個々の
リソースに対して設定できます。
リソース上の「in-flight」操作の状
態をCIBに反映させます。
description
操作について説明します。
4.2.9 タイムアウト値
リソースのタイムアウト値は次の3つのパラメータの影響を受けることがあり
ます。
設定および管理の基本事項
77
• op_defaults (操作用のグローバルタイムアウト)、
• リソーステンプレートに対して定義された特定のタイムアウト値
• リソースに対して定義された特定のタイムアウト値
注記: 値の優先度
リソースに対して「特定の」値が定義される場合、グローバルデフォルト
より優先されます。また、リソースに対して定義された特定の値は、リソー
ステンプレートで定義された値より優先されます。
タイムアウト値を適切に設定することは非常に重要です。これらの値を短く
しすぎると、次のような理由で、多数の(不必要な)フェンシング処理が発生し
ます。
1. リソースでタイムアウトが発生すると、リソースは失敗し、クラスタはリ
ソースを停止しようとします。
2. リソースの停止も失敗した場合(たとえば、停止のタイムアウト設定が短す
ぎる場合)、クラスタはノードをフェンシングします。クラスタは、この
ノードが制御できなくなっていると見なすからです。
CRMはすべてのノードの各リソースに対して、probeと呼ばれる初期監視を
実行します。probeはリソースのクリーンアップ後にも実行されます。リソー
スの監視操作に対して特定のタイムアウトが設定されていない場合、CRMが
その他の監視操作を自動的にチェックします。1つのリソースに対して複数の
監視操作が定義されている場合、CRMは最も時間間隔の短い監視を1つ選択
し、そのタイムアウト値をプローブのデフォルトタイムアウトとして使用し
ます。監視操作が何も設定されていない場合は、クラスタ規模のデフォルト
が適用されます。デフォルトは、20秒です( op_defaults パラメータの設定
で別途指定されない場合)。自動計算やop_defaultsの値に依存したくない
場合は、この監視に対する特定のタイムアウトを定義します。intervalを0
に設定した状態で、監視操作をそれぞれのリソースに追加することでこの操
作を行います。たとえば次のようになります。
crm(live)configure# primitive rsc1 ocf:pacemaker:Dummy \
op monitor interval="0" timeout="60"
78
高可用性ガイド
rsc1のプローブは60sでタイムアウトになります。この値は、 op_defaults
で定義されているグローバルタイムアウトや、その他の操作で設定されてい
るタイムアウトとは無関係です。
操作に対するグローバルデフォルトを調整し、crmshおよびHawkの両方で特
定のタイムアウト値を設定できます。タイムアウト値の決定および設定のベ
ストプラクティスは次のとおりです。
手順 4.1 タイムアウト値の決定
1 負荷の下でリソースが開始および停止するためにかかる時間を確認します。
2 必要に応じて op_defaults パラメータを追加し、それに応じて(デフォル
ト)タイムアウト値を設定します。
2a たとえば、op_defaultsを60秒に設定します。
crm(live)configure#
op_defaults timeout=60
2b さらに長い時間を必要とするリソースについては、個別の値を定義
します。
3 あるリソースに対して操作を設定する場合には、個別のstartおよびstop
操作を追加します。Hawkを使用して設定する場合、これらの操作に適した
タイムアウト値候補が表示されます。
4.3 リソース監視
リソースが実行中であるかどうか確認するには、そのリソースにリソースの
監視を設定しておく必要があります。
リソースモニタが障害を検出すると、次の処理が行われます。
• /etc/corosync/corosync.confのloggingセクションで指定された設
定に従って、ログファイルメッセージが生成されます。デフォルトでは、
ログはsyslog (通常、/var/log/messages)に書き込まれます。
• 障害がクラスタ管理ツール(Pacemaker GUI、Hawk、crm_mon)と、CIBステー
タスセクションに反映されます。
設定および管理の基本事項
79
• クラスタが明瞭な復旧アクションを開始します。これらのアクションには、
リソースを停止して障害状態を修復する、ローカルまたは別のノードでリ
ソースを再起動するなどが含まれる場合があります。設定やクラスタの状
態によっては、リソースが再起動されないこともあります。
リソースの監視を設定しなかった場合、開始成功後のリソース障害は通知さ
れず、クラスタは常にリソース状態を良好として表示してしまいます。
通常、リソースは動作している限り、クラスタのみによって監視されます。
しかし、同時実行違反を検出するために、停止されるリソースの監視も設定
する必要があります。次の例をご覧ください。
primitive dummy1 ocf:heartbeat:Dummy \
op monitor interval="300s" role="Stopped" timeout="10s" \
op monitor interval="30s" timeout="10s"
この設定は、300秒ごとに、リソースdummy1に対する監視操作をトリガしま
す。これは、リソースがrole="Stopped"に入るとすぐに有効になります。
実行中には、リソースは30秒ごとに監視されます。
選択したクラスタ管理ツールでリソースに対して監視操作を追加する方法に
ついては、次を参照してください。
• Hawk: 手順5.15「監視操作を追加または変更する」 (127 ページ)
• Pacemaker GUI: 手順6.12「監視操作を追加または変更する」 (175 ページ)
• crmシェル: 7.3.8項「リソース監視の設定」 (210 ページ)
4.4 リソースの制約
すべてのリソースを設定する以外にも、多くの作業が必要です。クラスタが
必要なすべてのリソースを認識しても、正しく処理できるとは限りません。
リソースの制約を指定して、リソースを実行可能なクラスタノード、リソー
スのロード順序、特定のリソースが依存している他のリソースを指定するこ
とができます。
80
高可用性ガイド
4.4.1 制約のタイプ
使用可能な制約には3種類あります。
リソースの場所
場所の制約はリソースを実行できるノード、できないノード、または実行
に適したノードを定義するものです。
リソースのコロケーション
コロケーション制約は、ノード上で一緒に実行可能な、または一緒に実行
することが禁止されているリソースをクラスタに伝えます。
リソースの順序
アクションの順序を定義する、順序の制約です。
4.4.1.1 リソースセット
制約を定義するためにリソースセットを使用する
場所、コロケーション、または順序の制約を定義するための別のフォーマッ
トとして、resource setsを使用することができます。リソースセットで
は、プリミティブが1つのセットでグループ化されます。以前は、これはリ
ソースグループを定義するか(デザインを正確に表現できない場合もあった)、
個々の制約として各関係を定義することでこの操作が可能でした。個々の制
約として定義した場合、多数のリソースとの組み合わせが増えるにつれて、
制約が飛躍的に増加しました。リソースセットを介した設定で、冗長性が常
に低減されるわけではありませんが、次の例が示すように、定義内容の把握
と管理がより容易になります。
例 4.2 場所制約のリソースセット
たとえば、crmshでリソースセット(loc-alice)の次の設定を使用して、2つ
の仮想IP (vip1 および vip2)を同じノード、 aliceに配置できます。
crm(live)configure# primitive vip1 ocf:heartbeat:IPaddr2 params ip=192.168.1.5
crm(live)configure# primitive vip1 ocf:heartbeat:IPaddr2 params ip=192.168.1.6
crm(live)configure# location loc-alice { vip1 vip2 } inf: alice
リソースセットを使用してコロケーション制約の設定を置き換える場合は、
次の2つの例を検討します。
設定および管理の基本事項
81
例 4.3 コロケートされたリソースのチェーン
<constraints>
<rsc_colocation id="coloc-1" rsc="B" with-rsc="A" score="INFINITY"/>
<rsc_colocation id="coloc-2" rsc="C" with-rsc="B" score="INFINITY"/>
<rsc_colocation id="coloc-3" rsc="D" with-rsc="C" score="INFINITY"/>
</constraints>
リソースセットで表される同一の設定:
<constraints>
<rsc_colocation id="coloc-1" score="INFINITY" >
<resource_set id="colocated-set-example" sequential="true">
<resource_ref id="A"/>
<resource_ref id="B"/>
<resource_ref id="C"/>
<resource_ref id="D"/>
</resource_set>
</rsc_colocation>
</constraints>
リソースセットを使用して順序の制約の設定を置き換える場合は、次の2つの
例を検討します。
例 4.4 順序付けされたリソースのチェーン
<constraints>
<rsc_order id="order-1" first="A" then="B" />
<rsc_order id="order-2" first="B" then="C" />
<rsc_order id="order-3" first="C" then="D" />
</constraints>
順序付けされたリソースを持つリソースセットを使用して、同様な目的を達
成できます。
例 4.5 リソースセットとして表される順序付けされたリソースのチェーン
<constraints>
<rsc_order id="order-1">
<resource_set id="ordered-set-example" sequential="true">
<resource_ref id="A"/>
<resource_ref id="B"/>
<resource_ref id="C"/>
<resource_ref id="D"/>
</resource_set>
</rsc_order>
</constraints>
これらのセットは、順序付けされている(sequential=true)場合もあれば、
順序付けされていない場合(sequential=false)場合もあります。また、
82
高可用性ガイド
require-all属性を使用して、ANDおよびORロジック間を切り替えることが
できます。
依存関係のないコロケーション制約のリソースセット
同じノード上にリソースのグループを配置する方が役立つ場合がありますが
(コロケーション制約を定義)、リソース間に困難な依存関係を持つことはあり
ません。たとえば、同じノード上に2つのリソースを配置したいが、それらの
一方で障害が発生した場合に他方をクラスタで再起動したくない場合があり
ます。これは、weak bondコマンドを使用して、crmシェルで実行できます。
選択したクラスタ管理ツールでこれらの「弱い結合」を設定する方法につい
ては、次を参照してください。
• crmsh: 7.3.4.3項「依存性なしのリソースセットのコロケーショ
ン」 (205 ページ)
4.4.1.2 その他の情報
様々な種類の制約を追加する方法については、選択したクラスタ管理ツール
に応じて次のいずれかを参照してください。
• Hawk: 5.3.5項「リソース制約の設定」 (118 ページ)
• crmsh: 7.3.4項「リソース制約の設定」 (203 ページ)
制約の設定の詳細や、順序付けおよびコロケーションの基本的な概念につい
ての詳しいバックグラウンド情報は次のドキュメントを参照してください。
これらのドキュメントは、http://www.clusterlabs.org/doc/で入手で
きます。
• 『Pacemaker Explained』の「Resource Constraints」の章
• 『Colocation Explained』
• 『オーダーの概要』
設定および管理の基本事項
83
4.4.2 スコアと無限大
制約を定義する際は、スコアも扱う必要があります。あらゆる種類のスコア
はクラスタの動作方法と密接に関連しています。スコアの操作によって、リ
ソースのマイグレーションから、速度が低下したクラスタで停止するリソー
スの決定まで、あらゆる作業を実行できます。スコアはリソースごとに計算
され、リソースに対して負のスコアが付けられているノードは、そのリソー
スを実行できません。リソースのスコアを計算した後、クラスタはスコアが
最も高いノードを選択します。
INFINITYは現在1,000,000と定義されています。この値の増減は、次の3つ
の基本ルールに従います。
• 任意の値+ INFINITY = INFINITY
• 任意の値- INFINITY = -INFINITY
• INFINITY - INFINITY = -INFINITY
リソース制約を定義する際は、各制約のスコアを指定します。スコアはこの
リソース制約に割り当てる値を示します。スコアの高い制約は、それよりも
スコアが低い制約より先に適用されます。1つのリソースに対して場所の制約
を複数作成し、それぞれに異なるスコアを指定することで、リソースがフェー
ルオーバーするノードの順序を指定できます。
4.4.3 リソーステンプレートと制約
リソーステンプレートを定義したら(4.2.4項「リソーステンプレー
ト」 (66 ページ)を参照)、次のタイプの制約で参照できます。
• 順序の制約
• コロケーション制約
• rsc_ticket制約(Geoクラスタの場合)
ただし、コロケーション制約には、テンプレートへの参照を複数含めること
はできません。リソースセットには、テンプレートへの参照を含めることは
できません。
84
高可用性ガイド
制約内で参照されたリソーステンプレートは、そのテンプレートから派生す
るすべてのプリミティブを表します。これは、そのリソーステンプレートを
参照しているすべてのプリミティブリソースに、この制約が適用されること
を意味します。制約内でリソーステンプレートを参照すれば、リソースセッ
トの代替となり、クラスタ設定をかなりの程度単純化することができます。
リソースセットの詳細については、手順5.11「コロケーションまたは順序の制
約のためにリソースセットを使用する」 (122 ページ)を参照してください。
4.4.4 フェールオーバーノード
リソースに障害が発生すると、自動的に再起動されます。現在のノードで再
起動できない場合、または現在のノードでN回失敗した場合は、別のノードへ
のフェールオーバーが試行されます。リソースが失敗するたびに、その失敗
回数が増加します。新しいノードへのマイグレートを行う基準
(migration-threshold)となるリソースの失敗数を定義できます。クラス
タ内に3つ以上ノードがある場合、特定のリソースのフェールオーバー先の
ノードはHigh Availabilityソフトウェアが選択します。
ただし、リソースに1つ以上の場所の制約とmigration-thresholdを設定
することで、そのリソースのフェールオーバー先にするノードを指定できま
す。
選択したクラスタ管理ツールでフェールオーバーノードを指定する方法につ
いては、次を参照してください。
• Hawk: 5.3.6項「リソースフェールオーバーノードの指定」 (123 ページ)
• Pacemaker GUI: 6.3.5項「リソースフェールオーバーノードの指
定」 (169 ページ)
• crmシェル: 7.3.5項「リソースフェールオーバーノードの指定」 (206 ページ)
例 4.6 マイグレーションしきい値 - プロセスフロー
たとえば、リソース「rsc1」に場所の制約を設定し、このリソースを
「alice」で優先的に実行するように指定したと仮定します。そのノードで
実行できなかった場合は、「migration-threshold」を確認して失敗回数
と比較します。失敗回数 >= マイグレーションしきい値の場合は、リソースは
次の優先実行先として指定されているノードにマイグレートされます。
設定および管理の基本事項
85
デフォルトでは、いったんしきい値に達すると、そのノードでは、リソース
の失敗回数がリセットされるまで、失敗したリソースを実行できなくなりま
す。これは、手動でクラスタ管理者が行うか、リソースにfailure-timeout
オプションを設定することで実行できます。
たとえば、migration-threshold=2とfailure-timeout=60sを設定す
ると、リソースは、2回の失敗の後に新しいノードに移行します。そして、1
分後に復帰できます(固着性と制約のスコアによる)。
移行しきい値の概念には2つの例外があり、これらの例外は、リソースの開始
失敗か、停止失敗のどちらかで発生します。
• 起動の失敗では、失敗回数がINFINITYに設定されるので、常に、即時に移
行が行われます。
• 停止時の失敗ではフェンシングが発生します(［stonith-enabled］がデ
フォルトである「true」に設定されている場合)。
STONITHリソースが定義されていない場合は(またはstonith-enabledが
falseに設定されている場合)、リソースの移行は行われません。
選択したクラスタ管理ツールでマイグレーションしきい値を使用し、失敗回
数をリセットする方法については、次を参照してください。
• Hawk: 5.3.6項「リソースフェールオーバーノードの指定」 (123 ページ)
• Pacemaker GUI: 6.3.5項「リソースフェールオーバーノードの指
定」 (169 ページ)
• crmシェル: 7.3.5項「リソースフェールオーバーノードの指定」 (206 ページ)
4.4.5 フェールバックノード
ノードがオンライン状態に戻り、クラスタ内にある場合は、リソースが元の
ノードにフェールバックすることがあります。リソースを実行していたノー
ドにリソースをフェールバックさせたくない場合や、リソースのフェールバッ
ク先として別のノードを指定する場合は、リソースのresource stickiness
値を変更します。リソースの固着性は、リソースの作成時でも、その後でも
指定できます。
86
高可用性ガイド
リソース固着性値の指定時には、次の予想される結果について考慮してくだ
さい。
0の値:
デフォルトです。リソースはシステム内で最適な場所に配置されます。現
在よりも「状態のよい」、または負荷の少ないノードが使用可能になる
と、移動することを意味しています。このオプションは自動フェールバッ
クとほとんど同じですが、以前アクティブだったノード以外でもリソース
をフェールバックできるという点が異なります。
0より大きい値:
リソースは現在の場所に留まることを望んでいますが、状態がよいノード
が使用可能になると移動される可能性があります。値が大きくなるほど、
リソースが現在の場所に留まることを強く望んでいることを示します。
0より小さい値:
リソースは現在の場所から別な場所に移動することを望んでいます。絶対
値が大きくなるほど、リソースが移動を強く望んでいることを示します。
INFINITYの値:
ノードがリソースの実行権利がなくなったために強制終了される場合(ノー
ドのシャットダウン、ノードのスタンバイ、migration-thresholdに
到達、または設定変更)以外は、リソースは常に現在の場所に留まります。
このオプションは自動フェールバックを完全に無効にする場合とほとんど
同じです。
-INFINITYの値:
リソースは現在の場所から常に移動されます。
4.4.6 負荷インパクトに基づくリソースの配
置
すべてのリソースが同等ではありません。Xenゲストなどの一部のリソースで
は、そのホストであるノードがリソースの容量要件を満たす必要があります。
リソースの組み合わされたニーズが提供された容量より大きくなるようにリ
ソースが配置されると、リソースのパフォーマンスが低下します(あるいは失
敗することさえあります)。
設定および管理の基本事項
87
これを考慮に入れて、High Availability Extensionでは、次のパラメータを指定
できます。
1. 一定のノードが提供する容量
2. 一定のリソースが要求する容量
3. リソースの配置に関する全体的なストラテジ
選択したクラスタ管理ツールでこれらの設定を設定する方法については、次
を参照してください。
• Pacemaker GUI: 6.3.7項「負荷インパクトに基づくリソース配置の設
定」 (171 ページ)
• crmシェル: 7.3.7項「負荷インパクトに基づくリソース配置の設
定」 (207 ページ)
ノードは、リソースの要件を満たすだけの空き容量があれば、そのリソース
に対して資格があるとみなされます。High Availability Extensionにとって、容
量の性質は重要ではありません。High Availability Extensionは、リソースをノー
ドに移動する前に、リソースのすべての容量要件が満たされているかどうか
を確認するだけです。
リソースの要件とノードが提供する容量を手動で設定するには、使用属性を
使用します。使用属性に任意の名前を付け、設定に必要なだけ名前/値のペア
を定義します。ただし、属性値は、整数にする必要があります。
使用属性を持つ複数のリソースがグループ化されていたり、これらにコロケー
ション制約がある場合、High Availability Extensionではそのことを考慮に入れ
ます。可能な場合、これらのリソースは、すべての容量要件を満たすことが
できるノードに配置されます。
注記: グループの使用属性
リソースグループに対して使用属性を直接設定することはできません。た
だし、グループの設定を簡素化するために、グループ内のすべてのリソー
スに必要な合計容量を含む使用属性を追加することができます。
High Availability Extensionには、ノードの容量とリソースの要件を自動的に検
出し、設定する手段も用意されています。
88
高可用性ガイド
NodeUtilizationリソースエージェントは、ノードの容量をチェックしま
す(CPUとRAMについて)。自動検出を設定するには、クラス、プロバイダ、
タイプがocf:pacemaker:NodeUtilizationのクローンリソースを作成し
ます。このクローンのインスタンスが各ノードに1つずつ実行している必要が
あります。インスタンスが開始すると、CIBでそのノードの設定にutilizationセ
クションが追加されます。
リソースの最小要件の自動検出(RAMとCPU)に配慮し、Xenリソースエージェ
ントが改良されました。Xenリソースは、開始時点でRAMとCPUの消費状況
を反映します。リソース設定には、使用属性が自動的に追加されます。
最小要件を検出することに加え、High Availability Extensionは、
VirtualDomainリソースエージェントを通して現在の利用状況を監視する
ことができ、仮想マシンでのCPUとRAMの使用状況を検出します。この機能
を使用するには、クラス、プロバイダ、およびタイプが
ocf:heartbeat:VirtualDomainのリソースを設定します。次のインスタ
ンス属性を使用できます: autoset_utilization_cpu および
autoset_utilization_hv_memory。両方ともデフォルトはtrueです。
これにより、監視サイクルのたびにCIBで使用値が更新されます。
容量と要件を手動と自動のどちらで設定する場合でも、placement-strategy
プロパティ(グローバルクラスタオプション内)で、配置ストラテジを指定する
必要があります。次の値を使用できます。
default (デフォルト値)
使用値は考慮しません。リソースは、場所のスコアに従って割り当てられ
ます。スコアが同じであれば、リソースはノード間で均等に分散されま
す。
utilization
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する
際に、利用率を確認します。ただし、負荷分散は、まだ、ノードに割り当
てられたリソースの数に基づいて行われます。
minimal
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する
際に、利用率を確認します。できるだけ少ない数のノードにリソースを集
中しようとします(残りのノードの電力節約のため)。
設定および管理の基本事項
89
balanced
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定する
際に、利用率を確認します。リソースを均等に分散して、リソースのパ
フォーマンスを最適化しようとします。
注記: リソース優先度の設定
使用できる配置ストラテジは、最善策であり、まだ、複雑なヒューリス
ティックソルバで、常に最適な割り当て結果を得るには至っていません。
リソースの優先度を正しく設定して、最重要なリソースが最初にスケジュー
ルされるようにしてください。
例 4.7 負荷分散型配置の設定例
次の例は、同等のノードから成る3ノードクラスタと4つの仮想マシンを示し
ています。
node alice utilization memory="4000"
node bob utilization memory="4000"
node charly utilization memory="4000"
primitive xenA ocf:heartbeat:Xen utilization
params xmfile="/etc/xen/shared-vm/vm1"
meta priority="10"
primitive xenB ocf:heartbeat:Xen utilization
params xmfile="/etc/xen/shared-vm/vm2"
meta priority="1"
primitive xenC ocf:heartbeat:Xen utilization
params xmfile="/etc/xen/shared-vm/vm3"
meta priority="1"
primitive xenD ocf:heartbeat:Xen utilization
params xmfile="/etc/xen/shared-vm/vm4"
meta priority="5"
property placement-strategy="minimal"
hv_memory="3500" \
hv_memory="2000" \
hv_memory="2000" \
hv_memory="1000" \
3ノードはすべてアクティブであり、まず、リソースxenAがノードに配置さ
れ、次に、xenDが配置されます。xenBとxenCは、一緒に割り当てられるか、
またはどちらか1つがxenDとともに割り当てられます。
1つのノードに障害が発生した場合、残りのノード上で利用できるメモリ合計
が少なすぎて、これらのリソースすべてはホストできません。xenAは確実に
割り当てられ、xenDも同様です。ただし、残りのリソースxenBとxenCは、
そのどちらかしか割り当てられません。xenBとxenCの優先度は同等なので、
結果はまだ決められません。これを解決するためにも、どちらかに高い優先
度を設定する必要があります。
90
高可用性ガイド
4.4.7 タグの使用によるリソースのグループ
化
タグは最近Pacemakerに追加された新機能です。タグは、コロケーションの作
成や関係の順序付けを行わずに、複数のリソースをただちに参照する方法で
す。これは、概念的に関連するリソースをグループ化するのに役立つ場合が
あります。たとえば、データベースに関連するいくつかのリソースがある場
合、databasesというタグを作成し、データベースに関連するすべてのリ
ソースをこのタグに追加します。これにより、1つのコマンドでそれらすべて
のリソースを停止または起動できます。
タグは制約でも使用できます。たとえば、次の場所制約loc-db-preferは、
databasesでタグ付けしたリソースのセットに適用されます。
location loc-db-prefer databases 100: alice
選択したクラスタ管理ツールでタグを作成する方法については、次を参照し
てください。
• crmsh: 7.4.5項「リソースのグループ化/タグ付け」 (215 ページ)
4.5 リモートホストでのサービスの管
理
リモートホストでサービスを監視および管理できることが、ここ数年の間に
ますます重要になってきています。SUSE Linux Enterprise High Availability
Extension 11 SP3では、監視プラグインを介したリモートホスト上のサービス
の詳細な監視機能を提供してきました。SUSE Linux Enterprise High Availability
Extension 11 SP4では、最近追加されたpacemaker_remoteサービスを使用す
ると、リモートマシンにクラスタスタックをインストールしていなくても、
実際のクラスタノードと同様にリモートホスト上のリソースを全面的に管理
および監視できます。
設定および管理の基本事項
91
4.5.1 Nagiosプラグインを使用したリモート
ホストでのサービスの監視
仮想マシンの監視はVMエージェント(ハイパーバイザにゲストが出現する場
合のみチェックを行う)を使用して行うか、VirtualDomainまたはXenエージェ
ントから呼び出される外部スクリプトによって行うことができます。これま
では、精度の高い監視を行うには、仮想マシン内にHigh Availabilityスタック
を完全にセットアップするしか方法がありませんでした。
今回、High Availability Extensionでは、Nagiosプラグインに対するサポートを
提供することで、リモートホスト上のサービスを監視できるようになりまし
た。ゲストイメージを変更することなく、ゲストの外部ステータスを収集で
きます。たとえば、VMゲストはWebサービスまたは単純なネットワークリ
ソースを実行している可能性があり、これらはアクセス可能である必要があ
ります。Nagiosリソースエージェントによって、ゲスト上のWebサービスまた
はネットワークリソースを監視できるようになりました。これらのサービス
にアクセスできなくなった場合は、High Availability Extensionがそれぞれのゲ
ストの再起動またはマイグレーションをトリガします。
ゲストがサービス(そのゲストによって使用されるNFSサーバなど)に依存して
いる場合、そのサービスは、クラスタによって管理される通常のリソースか、
Nagiosリソースによって監視される外部サービスのどちらかにすることがで
きます。
Nagiosリソースを設定するには、ホスト上に次のパッケージをインストール
する必要があります:
• nagios-plugins
• nagios-plugins-metadata
必要に応じて、YaSTまたはZypperが、これ以上のパッケージに対する依存性
を解決します。
一般的な使用例としては、1つのリソースコンテナに属するリソースとして
Nagiosプラグインを設定します。このリソースコンテナは通常はVMです。い
ずれかのリソースに障害が発生したら、このコンテナが再起動されます。設
定例については、例4.8「Nagiosプラグインのリソースの設定」 (93 ページ)を
参照してください。または、Nagiosリソースエージェントを使用してネット
92
高可用性ガイド
ワーク経由でホストまたはサービスを監視する場合、このエージェントを通
常のリソースとして設定することもできます。
例 4.8 Nagiosプラグインのリソースの設定
primitive vm1 ocf:heartbeat:VirtualDomain \
params hypervisor="qemu:///system" config="/etc/libvirt/qemu/vm1.xml" \
op start interval="0" timeout="90" \
op stop interval="0" timeout="90" \
op monitor interval="10" timeout="30"
primitive vm1-sshd nagios:check_tcp \
params hostname="vm1" port="22" \
op start interval="0" timeout="120" \
op monitor interval="10"
group g-vm1-and-services vm1 vm1-sshd \
meta container="vm1"
サポートされるパラメータは、Nagiosプラグインの長いオプションと同
じです。Nagiosプラグインは、パラメータhostnameによってサービス
と接続します。したがって、この属性の値は解決可能なホスト名かIPア
ドレスである必要があります。
ゲストオペレーティングシステムが起動してサービスが実行されるまで
には少し時間がかかるので、Nagiosリソースの起動タイムアウトは十分
な長さに設定する必要があります。
タイプがocf:heartbeat:Xen、ocf:heartbeat:VirtualDomain、
またはocf:heartbeat:lxcのクラスタリソースコンテナ。VMまたは
Linuxコンテナのいずれかに設定できます。
上の例には、check_tcpプラグイン用の1つのNagiosリソースしか含まれてい
ませんが、様々なプラグインタイプ(たとえば、check_httpやcheck_udpな
ど)用に複数のNagiosリソースを設定することもできます。
複数のサービスのホスト名が同じである場合、hostnameパラメータを個別
のプリミティブに追加するのではなく、グループに対して指定することもで
きます。次に例を示します。
group g-vm1-and-services vm1 vm1-sshd vm1-httpd \
meta container="vm1" \
params hostname="vm1"
Nagiosプラグインによって監視されているいずれかのサービスに、VM内で障
害が発生した場合は、クラスタがこれを検出し、コンテナリソース(VM)を再
起動します。この場合に実行される操作は、サービスの監視操作に関する
設定および管理の基本事項
93
on-fail属性を指定することで設定できます。デフォルトでは、
restart-containerに設定されています。
VMのマイグレーションしきい値を検討する場合は、サービスの障害発生回数
が考慮されます。
4.5.2 pacemaker_remoteを使用したリモー
トノードでのサービスの管理
pacemaker_remoteサービスを使用すると、High Availabilityクラスタを仮想
ノードまたはリモートベアメタルマシンに拡張することができます。クラス
タスタックを実行して、クラスタのメンバーになる必要はありません。
High Availability Ｅｘｔｅｎｓｉonでは現在、仮想環境(KVMおよびLXC)、お
よびこれらの仮想環境内に存在するリソースを起動できるようになりました
(PacemakerまたはCorosyncの実行に仮想環境は必要としません)。
クラスタリソースとしての仮想マシンおよびVM内に存在するリソースの両方
を管理する使用例では、次の設定を使用できるようになりました。
• 「通常」(ベアメタル)クラスタノードは、High Availability Extensionを実行
します。
• 仮想マシンは、pacemaker_remoteサービスを実行します(VM側で必要な
設定はほとんどありません)。
• 「通常」クラスタノード上のクラスタスタックはVMを起動し、VM上で実
行されているpacemaker_remoteサービスに接続して、それらをリモート
ノードとしてクラスタに統合します。
リモートノードでクラスタスタックがインストールされていないときは、こ
れには次の意味があります。
• リモートノードはクォーラムに参加しません。
• リモートノードはDCになることはできません。
• リモートノードは、スケーラビリティの制約に制限されません(Corosyncに
は16ノードのメンバー制限があります)。
94
高可用性ガイド
remote_pacemakerサービスに関する詳細については(詳細な設定手順から
なる複数の使用例を含む)、『Pacemaker Remote—Extending High Availability into
Virtual Nodes』を参照してください(http://www.clusterlabs.org/doc/
から入手可能)。
4.6 システムヘルスの監視
ノードがディスク容量が使い尽くしたために、そこに割り当てられたリソー
スを管理できなくなることを避けるため、High Availability Extensionでは、
ocf:pacemaker:SysInfoというリソースエージェントが提供されていま
す。これを使用して、ディスクパーティションに関してノードのヘルスを監
視します。SysInfo RAは、#health_diskという名前のノード属性を作成し
ます。この属性は、監視対象のディスク空き容量が指定された制限を下回る
とredに設定されます。
ノードのヘルスがクリティカルな状態に達した場合のCRMの対応方法を定義
するには、グローバルなクラスタオプションであるnode-health-strategy
を使用します。
手順 4.2 システムヘルスの監視設定
ノードがディスク容量を使い尽くした場合に、リソースを自動的にノードか
ら移動させるには、次の手順に従います。
1 ocf:pacemaker:SysInfoリソースを設定します。
primitive sysinfo ocf:pacemaker:SysInfo \
params disks="/tmp /var"
min_disk_free="100M"
op monitor interval="15s"
disk_unit="M"
\
監視対象のディスクパーティション。たとえ
ば、/tmp、/usr、/var、/devなど。複数のパーティションを属性
値として指定するには、空白で区切ります。
設定および管理の基本事項
95
注記: /のファイルシステムは常に監視されます。
disksでルートパーティション(/)を指定する必要はありません。こ
れはデフォルトで常に監視されます。
これらのパーティションの必要最小限の空きディスク容量。オプショ
ンで、計測に使用する単位を指定できます(上記の例では、メガバイト
を表すMが使用されています)。指定しない場合、min_disk_freeは
disk_unitパラメータで定義されている単位にデフォルト設定されま
す。
ディスク容量をレポートする場合の単位。
2 リソース設定を完了するには、ocf:pacemaker:SysInfoのクローンを作
成し、各クラスタノードでそれを起動します。
3 node-health-strategyをmigrate-on-redに設定します。
property node-health-strategy="migrate-on-red"
#health_disk属性がredに設定されている場合、ポリシーエンジンによっ
て、そのノードのリソースのスコアに-INFが追加されます。これにより、
このノードからすべてのリソースが移動します。この処理はSTONITHリ
ソースのところで停止しますが、STONITHリソースが実行されていない場
合でも、ノードをフェンスすることができます。フェンスでCIBに直接ア
クセスすることで、動作を続行できるからです。
ノードのヘルス状態がredになったら、原因となる問題を解決します。次に
redステータスをクリアして、ノードを再びリソースの実行に適した状態に
します。クラスタノードにログインして、次のいずれかの方法を使用します。
• 次のコマンドを実行します:
root # crm node status-attr NODE delete #health_disk
• 該当するノードでPacemakerおよびCorosyncを再起動します。
• ノードを再起動します。
ノードがサービスに復帰し、再びリソースを実行できるようになります。
96
高可用性ガイド
4.7 メンテナンスモード
クラスタ設定の変更時、個々のノードに対するソフトウェアパッケージの更
新時、または上位製品バージョンへのクラスタのアップグレード時であって
も、個々のクラスタコンポーネント上、またはクラスタ全体でテストや保守
タスクを実行する必要がある場合があります。
それに関して、High Availability Extensionは、次のレベルでmaintenanceオ
プションを提供しています。
• リソース用
• ノード用
• クラスタ全体用
警告: データ損失の危険
クラスタ制御下でサービスを実行しているときにテストまたは保守タスク
を実行する必要がある場合は、次のアウトラインに従ってください。
1. 手順を開始する前に、個々のリソース、ノード、またはクラスタ全体を
保守モードに設定します。これにより、順序正しくリソースを起動でき
ないなどの望ましくない影響、クラスタノード間でCIBが同期されないリ
スク、またはデータ損失を避けることができます。
2. 保守タスクまたはテストを実行します。
3. 完了したら、保守モードを解除して、通常のクラスタ操作を開始します。
保守モードでは、ユーザがクラスタリソースを停止または再起動できます。
High Availability Extensionでは、これらのリソースが再起動されません。すべ
てのリソースは自動的に非管理対象になります。High Availability Extensionは
監視を終了するため、ステータスが追跡されなくなります。ノード上のすべ
てのPacemakerサービスを停止することもできます。その場合、Pacemakerの管
理対象クラスタリソースとして最初に起動されたすべてのデーモンとプロセ
スの実行は継続されます。クラスタが保守モードのときに、ノード上で
Pacemakerサービスを起動しようとする場合、Pacemakerはリソースごとに1つ
のワンショット監視操作(「probe」)を開始し、そのノードで現在どのリソー
設定および管理の基本事項
97
スが実行されているかを評価します。ただし、リソースのステータスを決定
する以外の操作は行いません。
選択したクラスタ管理ツールを使用して保守モードを設定または設定解除す
る方法の詳細については、次を参照してください。
• Hawk: 5.4.5項「保守モードの使用」 (137 ページ)
• crmsh: 7.4.6項「保守モードの使用」 (215 ページ)
4.8 その他の情報
http://crmsh.github.io/
crmシェル(crmsh)、High Availabilityクラスタ管理用の高度なコマンドライ
ンインタフェースのホームページ。
http://crmsh.github.io/documentation
crmshを使用した基本的なクラスタ設定の『Getting Started』チュートリア
ルとcrmシェルの包括的なマニュアルを含む、crmシェルに関するいくつ
かのドキュメント。マニュアルはhttp://crmsh.github.io/man-2
.0/で入手できます。チュートリアルはhttp://crmsh.github.io/
start-guide/に用意されています。
http://clusterlabs.org/
High Availability Extensionに含まれているクラスタリソースマネージャで
あるPacemakerのホームページ。
http://www.clusterlabs.org/doc/
いくつかの包括的なマニュアルと一般的な概念を説明するより簡潔なド
キュメント。次に例を示します。
• 『Pacemaker Explained』: 参考として包括的で詳細な情報が記載さ
れています。
• 『Configuring Fencing with crmsh』: STONITHデバイスの設定方法お
よび使用方法。
• 『Colocation Explained』
98
高可用性ガイド
• 『オーダーの概要』
http://linux-ha.org
The High Availability Linuxプロジェクトのホームページ。
設定および管理の基本事項
99
クラスタリソースの設定と管理
(Webインタフェース)
5
crmコマンドラインツールとPacemaker GUIの他に、High Availability Extension
には、管理作業用のWebベースのユーザインタフェースであるHA Web Konsole
(Hawk)も付属しています。このインタフェースを使用すれば、Linux以外のコ
ンピュータからも、Linuxクラスタを監視し、管理することができます。さら
にこれは、ご使用のシステムが最小限のグラフィカルユーザインタフェース
しか提供していない場合に最適なソリューションです。
この章では、Hawkを紹介し、グローバルクラスタオプションの変更、基本的
なリソースと高度なリソース(グループとクローン)の作成、制約の設定、フェー
ルオーバーノードとフェールバックノードの指定、リソースモニタリングの
設定、リソースの始動、クリーンアップ、または削除、および手動によるリ
ソースの移行など、クラスタリソースの設定と管理のための基本的な作業に
ついて説明します。Hawkは、クラスタステータスの詳細な分析のために、ク
ラスタレポート(hb_report)を生成します。クラスタの履歴を表示できます。
また、シミュレータにより、可能性のある障害シナリオを検討することがで
きます。
5.1 Hawk - 概要
HawkのWebインタフェースを使用すれば、Linux以外のマシンからも、Linux
クラスタを監視し、管理することができます。さらにこれは、ご使用のシス
テムが最小限のグラフィカルユーザインタフェースしか提供していない場合
に最適なソリューションです。
クラスタリソースの設定と管理(Webインタフェース)
101
5.1.1 Hawkの起動とログイン
このWebインタフェースは、hawkパッケージに含まれています。これは、
Hawkで接続するすべてのクラスタノードにインストールする必要がありま
す。Hawkを使用してクラスタノードにアクセスするマシンに必要なものは、
JavaScriptとクッキーを有効にして接続を確立できる(グラフィカル)Webブラウ
ザだけです。
Hawkを使用するには、このWebインタフェースで接続するノード上で、それ
ぞれのWebサービスが開始されている必要があります。
sleha-bootstrapパッケージのスクリプトを使用してクラスタをセットアッ
プした場合は、Hawkサービスがすでに開始されています。その場合は、手順
5.1「Hawkサービスの開始」 (102 ページ)をスキップして手順5.2「Hawk Webイ
ンタフェースへのログイン」 (103 ページ)に進みます。
手順 5.1 Hawkサービスの開始
1 接続先にするノードで、シェルを開き、rootとしてログインします。
2 次のように入力して、サービスのステータスをチェックします。
root # rchawk status
3 サービスが実行されていない場合は、次のコマンドでサービスを開始しま
す。
root # rchawk start
ブート時にHawkを自動的にブートしたい場合は、次のコマンドを実行しま
す。
root # chkconfig hawk on
注記: ユーザの認証
Hawkユーザはhaclientグループのメンバーである必要があります。イン
ストール時にhaclusterという名前のLinuxユーザが作成されますが、この
ユーザがhaclientグループに追加されます。セットアップ用に
ha-cluster-initスクリプトを使用している場合は、haclusterユーザ
に対してデフォルトパスワードが設定されます。
102
高可用性ガイド
Hawkを開始する前に、haclusterユーザのパスワードを設定するか変更し
てください。または、haclientグループのメンバーである新しいユーザを
作成してください。
Hawkを使用して接続する各ノードでこれを実行します。
手順 5.2 Hawk Webインタフェースへのログイン
Hawk Webインタフェースは、HTTPSプロトコルとポート7630を使用します。
注記: 仮想IPによるHawkへのアクセス
通常接続するクラスタノードがダウンしている場合でもHawkにアクセスで
きるようにするには、クラスタリソースとしてのHawkに仮想IPアドレス
(IPaddrまたはIPaddr2)を設定します。そのための特別な設定は不要で
す。
1 任意のコンピュータで、Webブラウザを起動し、JavaScriptとクッキーが有
効なことを確認します。
2 URLとして、Hawk Webサービスを実行するクラスタノードのIPアドレスま
たはホスト名を入力します。または、クラスタオペレータがリソースとし
て設定した可能性のある任意の仮想IPアドレスを入力します:
https://HOSTNAME_OR_IP_ADDRESS:7630/
注記: 証明書の警告
初めてURLにアクセスしようとするときに証明書の警告が表示される場
合は、自己署名証明書が使用されています。自己署名証明書は、デフォ
ルトでは信頼されません。
証明書を検証するための詳細情報については、クラスタのオペレータに
問い合わせてください。
続行するには、ブラウザに例外を追加して警告をバイパスします。
自己署名証明書を公式認証局によって署名された証明書で置き換える方
法の詳細については、「自己署名証明書の置き換え」 (150 ページ)を参照
してください。
クラスタリソースの設定と管理(Webインタフェース)
103
3 Hawkログイン画面で、haclusterユーザ(または、haclientグループの
メンバーである他の任意のユーザ)の［ユーザ名］と［パスワード］を入力
します。
4 ［ログイン］をクリックします。
［クラスタの状態］画面が開き、クラスタノードとリソースのステータス
が表示されます。表示される情報は、crmシェルのcrm statusの出力と似
ています。
5.1.2 メイン画面: クラスタステータス
ログインした後、Hawkは［クラスタステータス］画面を表示します。重要な
グローバルクラスタパラメータと、クラスタノードおよびリソースのステー
タスを示すサマリが表示されます。ノードとリソースのステータスを表示す
るのに、次のカラーコードが用いられます。
Hawkのカラーコード
• 緑: OK。たとえば、リソースが実行中か、ノードがオンラインです。
• 赤: 不良。クリーンでないたとえば、リソースに障害が発生したか、ノード
がクリーンにシャットダウンされませんでした。
• 黄: 過渡期。たとえば、現在、ノードがシャットダウン中か、またはリソー
スが起動中または停止中です。保留中のリソースをクリックして詳細を表
示すると、現在リソースが変更しようとしている先の状態も表示されます
(Starting、Stopping、Moving、Promoting、またはDemoting)。
• 灰色: 実行中でありません。ただし、クラスタは、それが実行中であること
を期待しています。たとえば、管理者が停止したか、standbyモードにし
たノードです。オフラインのノードも、灰色で表示されます(クリーンに
シャットダウンされた場合)。
カラーコードの他に、Hawkの［クラスタの状態］画面のすべてのビューに
は、ノード、リソース、チケットの状態やエラーメッセージに関するアイコ
ンも表示されます。
リソースに障害が発生した場合は、詳細を示す障害メッセージが画面上部に
赤色で表示されます。障害の原因を分析するには、エラーメッセージをクリッ
104
高可用性ガイド
クします。これにより、Hawkの［履歴エクスプローラ］が自動的に開き、20
分の時間範囲でデータの収集がトリガされます(障害の発生前10分と発生後10
分)。詳細については、手順5.27「履歴エクスプローラで遷移を表示する
」 (140 ページ)を参照してください。
図 5.1 Hawk - クラスタステータス(サマリビュー)
［クラスタステータス］画面はほぼリアルタイムで更新されます。次のビュー
の中から選択します。これらのビューには、右上隅の3つのアイコンでアクセ
スできます。
Hawkクラスタステータスビュー
サマリビュー
重要なグローバルクラスタのパラメータと、クラスタノードおよびリソー
スのステータスが同時に確認できるように表示されます。セットアップに
Geoクラスタ(マルチサイトクラスタ)が含まれている場合、サマリビュー
にはチケットも表示されます。特定のカテゴリ(チケット、ノード、また
はリソース)に属しているすべての要素に関する詳細を表示するには、リ
ンクとしてマークされているカテゴリタイトルをクリックします。それ以
外の場合は、個々の要素をクリックして詳細を表示します。
ツリービュー
重要なグローバルクラスタパラメータと、クラスタノードおよびリソース
のステータスが拡張ビューで表示されます。セットアップにGeoクラスタ
(マルチサイトクラスタ)が含まれている場合、ツリービューにはチケット
も表示されます。それぞれのカテゴリに属する要素を展開したり折りたた
クラスタリソースの設定と管理(Webインタフェース)
105
んだりするには、矢印をクリックします。［サマリビュー］とは異なり、
このビューはリソースのIDとステータスだけでなく、タイプも表示します
(たとえばプリミティブ、クローン、またはグループ)。
テーブルビュー
このビューは、現在どのリソースがどのノード上で実行されているかを簡
潔に表示するため、大きめのクラスタに特に便利です。アクティブ化され
ていないノードまたはリソースも表示されます。
メイン画面の最上位の行には、ログインに使用したユーザ名が表示されます。
Webインタフェースから［ログアウト］して、ユーザ名の隣にあるレンチア
イコンから次の［ツール］にアクセスすることもできます。
• ［シミュレータ］:詳細については、5.4.7項「可能性のある障害シナリオを
調べる」 (142 ページ)を参照してください。
• ［クラスタダイアグラム］:ノードのグラフィック表現とCIBで設定された
リソースについては、このエントリを選択します。このダイアグラムには、
リソースとノード割り当て(スコア)の間の順序とコロケーションも表示され
ます。
図 5.2 Hawk - クラスタダイアグラム
• ［クラスタレポート］(hb_report):詳細については、5.4.8項「クラスタレ
ポートの生成」 (146 ページ)を参照してください。
106
高可用性ガイド
ノードおよびリソースで基本的な操作(リソースの起動や停止、ノードのオン
ライン化、詳細の表示など)を実行するには、それぞれのノードまたはリソー
スの隣にあるレンチアイコンをクリックします。これにより、コンテキスト
メニューが表示されます。どのステータス画面でも、クローン、グループ、
またはマルチステートの子リソースについては、このコンテキストメニュー
から［親］メニュー項目を選択します。これをクリックすることで、そのプ
リミティブが属している最上位のクローンまたはグループの開始や停止など
を実行できます。
リソースの設定、制約、グローバルクラスタオプションなどより複雑な作業
については、左側のナビゲーションバーを使用します。そこから、次の画面
にアクセスできます。
• ［クラスタの状態］: 詳細については、5.1.2項「メイン画面: クラスタステー
タス」 (104 ページ)を参照してください。
• ［履歴エクスプローラ］: 詳細については、手順5.27「履歴エクスプローラ
で遷移を表示する」 (140 ページ)を参照してください。
• ［セットアップウィザード］: 詳細については、5.3.1項「セットアップウィ
ザードでリソースを設定する」 (111 ページ)を参照してください。
• ［クラスタ設定］: 詳細については、5.2項「グローバルクラスタオプショ
ンの設定」 (108 ページ)を参照してください。
• ［アクセス制御リスト］: 詳細については、第10章アクセス制御リス
ト (239 ページ)を参照してください。
• ［リソース］: 詳細については、5.3項「クラスタリソースの設
定」 (110 ページ)を参照してください。
• ［制約］: 詳細については、5.3項「クラスタリソースの設定」 (110 ページ)
を参照してください。
注記: Hawkで利用できる機能
デフォルトでは、rootまたはhaclusterとしてログインしたユーザは、す
べてのクラスタ設定作業への、完全な読み込み/書き込みのアクセス権を持
ちます。ただし、アクセス制御リスト (239 ページ)を使用すれば、より詳細
なアクセス権限を定義することができます。
クラスタリソースの設定と管理(Webインタフェース)
107
CRMでACLが有効になっている場合、Hawkで利用できる機能は、割り当て
られたユーザ役割とアクセスパーミッションごとに異なります。加えて、
Hawkの次の機能は、ユーザhaclusterだけが使用できます。
• hb_reportの生成。
• ［履歴エクスプローラ］の使用。
• ノードまたリソースの最近のイベントの表示。
5.2 グローバルクラスタオプションの
設定
グローバルクラスタオプションは、一定の状況下でのクラスタの動作を制御
します。これらは、セットにグループ化され、Pacemaker GUI、Hawk、crm
シェルなどのクラスタ管理ツールで表示し、変更することができます。事前
に定義されている値は、ほとんどの場合、そのまま保持できます。ただし、
クラスタの主要機能を正しく機能させるには、クラスタの基本的なセットアッ
プ後に、次のパラメータを調整する必要があります。
• オプションno-quorum-policy (60 ページ)
• オプションstonith-enabled (61 ページ)
手順 5.3 グローバルクラスタオプションを変更する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタのプロパティ］を選択して、グロー
バルクラスタオプションとそれらの現在の値を表示します。Hawkは、［CRM
設定］、［リソースのデフォルト］、［操作のデフォルト］に関する重要
なパラメータを表示します。
108
高可用性ガイド
図 5.3 Hawk - クラスタ設定
3 クラスタの要件に応じて、［CRM Configuration］を調整します。
3a ［no-quorum-policy］を適切な値に設定します。
3b なんらかの理由でフェンシングを無効にする必要がある場合は、
［stonith-enabled］の選択を解除します。
重要: STONITHがない場合はサポートなし
STONITHがないクラスタはサポートされません。
3c CRM設定からプロ化ティを削除するには、プロパティの横のマイナ
スアイコンをクリックします。プロパティが削除されたら、クラス
タはそのプロパティがデフォルト値に設定されているように動作し
ます。デフォルト値の詳細については、4.2.6項「リソースオプショ
ン(メタ属性)」 (70 ページ)を参照してください。
3d CRM設定に新しいプロパティを追加するには、ドロップダウンボッ
クスからプロパティを1つ選択し、プラスアイコンをクリックしま
す。
4 ［リソースのデフォルト］または［操作のデフォルト］を変更する必要が
ある場合は、次のような処理を実行します。
クラスタリソースの設定と管理(Webインタフェース)
109
4a すでに表示されているデフォルトの値を変更するには、それぞれの
入力フィールドで値を編集します。
4b 新しいリソースのデフォルトまたは操作のデフォルトを追加するに
は、空のドロップダウンリストから1つ選択し、プラスアイコンをク
リックして値を入力します。定義されたデフォルト値が存在する場
合は、Hawkから自動的に提示されます。
4c リソースまたは操作のデフォルトを削除するには、パラメータの横
のマイナスアイコンをクリックします。［リソースのデフォルト］
と［操作のデフォルト］に値が指定されていない場合、クラスタは
4.2.6項「リソースオプション(メタ属性)」 (70 ページ)および4.2.8項
「リソース操作」 (76 ページ)にドキュメントされているデフォルト
値を使用します。
5 変更内容を確認します。
5.3 クラスタリソースの設定
クラスタの管理者は、クラスタ内のサーバ上の各リソースや、サーバ上で実
行する各アプリケーションに対してクラスタリソースを作成する必要があり
ます。クラスタリソースには、Webサイト、メールサーバ、データベース、
ファイルシステム、仮想マシン、およびユーザが常時使用できるその他のサー
バベースのアプリケーションまたはサービスなどが含まれます。
作成できるリソースタイプの概要については、4.2.3項「リソースのタイ
プ」 (65 ページ)を参照してください。リソースの基本的な仕様(ID、クラス、
プロバイダ、タイプ)とは別に、リソースの作成中または作成後に次のパラ
メータを追加または変更できます。
• Instance attributes (parameters)は、リソースが制御するサービ
スのインスタンスを決定します。詳細については、4.2.7項「インスタンス
属性(パラメータ)」 (73 ページ)を参照してください。
リソースを作成する際、Hawkは必要なパラメータを自動的に表示します。
これらを編集して、有効なリソースの設定を取得します。
110
高可用性ガイド
• Meta attributesは、特定のリソースの処理方法をCRMに指示します。
詳細については、4.2.6項「リソースオプション(メタ属性)」 (70 ページ)を
参照してください。
リソースを作成する際、Hawkはそのリソースの重要なメタ属性を自動的に
リストにします(たとえばリソースの初期状態を定義するtarget-role属
性です。デフォルトではStoppedに設定されているため、リソースはすぐ
には始動しません)。
• Operations は、リソース監視に必要です。詳細については、4.2.8項「リ
ソース操作」 (76 ページ)を参照してください。
リソースを作成する際、Hawkは、重要なリソース操作を表示します
(monitor、start、およびstop)。
5.3.1 セットアップウィザードでリソースを
設定する
High Availability Extensionには、高可用性NFSサーバのセットアップなど、よ
く使われるいくつかのクラスタシナリオ用に、テンプレートの定義済みセッ
トが付属しています。定義済みテンプレートは、hawk-templatesパッケー
ジに含まれています。ユーザ独自のウィザードテンプレートを定義すること
もできます。詳細については、https://github.com/ClusterLabs/hawk/
blob/master/doc/wizard.txtを参照してください。
手順 5.4 セットアップウィザードの使用
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［セットアップウィザード］を選択します。
［クラスタセットアップウィザード］に、使用可能なリソーステンプレー
トが一覧表示されます。エントリをクリックすると、Hawkはそのテンプ
レートについての簡単なヘルプテキストを表示します。
3 設定するリソースセットを選択して、［次へ］をクリックします。
4 画面の指示に従います。オプションについての情報が必要な場合には、オ
プションをクリックすると、Hawkは簡単なヘルプテキストを表示します。
クラスタリソースの設定と管理(Webインタフェース)
111
図 5.4 Hawk - セットアップウィザード
5.3.2 単純なクラスタリソースの作成
最も基本的なタイプのリソースを作成するには、次の手順に従います。
手順 5.5 プリミティブリソースを追加する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［リソース］を選択します。［リソース］画
面に、すべてのタイプのリソースのカテゴリが表示されます。ここにはす
でに定義済みのすべてのリソースが表示されます。
3 ［プリミティブ］カテゴリを選択し、プラスアイコンをクリックします。
4 リソースを次のとおり指定します。
4a 固有の［リソースID］を入力します。
4b ［クラス］リストから、そのリソースに使用するリソースエージェ
ントクラスを選択します。［lsb］、［ocf］、［service］、または
［stonith］を選択できます。詳細については、4.2.2項「サポートさ
れるリソースエージェントクラス」 (63 ページ)を参照してくださ
い。
112
高可用性ガイド
4c ［ocf］をクラスとして選択した場合、OCFリソースエージェントの
［プロバイダ］を指定します。OCFの指定によって、複数のベンダ
が同じリソースエージェントを提供できるようになります。
4d ［タイプ］リストから、使用するリソースエージェントを選択しま
す(たとえば［IPaddr］または［Filesystem］)。このリソースエージェ
ントの簡単な説明が表示されます。
［タイプ］リストに表示される選択肢は、選択した［クラス］(OCF
リソースの場合は、［プロバイダ］も)によって異なります。
5 Hawkは、リソースに必要なパラメータと、追加パラメータを指定するため
に使用できる空のドロップダウンリストを自動的に表示します。
リソースの［パラメータ］(インスタンス属性)を定義するには次のとおり
行います。
5a それぞれ必要なパラメータの値を入力します。パラメータの隣のテ
キストボックスをクリックすると、簡単なヘルプテキストが表示さ
れます。
5b パラメータを完全に削除するには、パラメータの隣のマイナスアイ
コンをクリックします。
5c 他のパラメータを追加するには、空のドロップダウンリストをクリッ
クし、パラメータを選択して、その値を入力します。
6 Hawkは、重要なリソース［操作］を自動的に表示し、デフォルト値を提案
します。ここで設定を変更しない場合、変更を確定するとすぐに、Hawkは
提案した操作およびデフォルト値を追加します。
操作の変更または削除方法の詳細については、手順5.15「監視操作を追加
または変更する」 (127 ページ)を参照してください。
7 Hawkは、たとえばtarget-roleなど、リソースの最も重要なメタ属性を
自動的にリストにします。
［メタ属性］を変更または追加するには次のとおり行います。
クラスタリソースの設定と管理(Webインタフェース)
113
7a 属性に(別の)値を設定するには、属性の隣のドロップダウンボックス
から値を1つ選択するか、入力フィールドで値を編集します。
7b 属性を完全に削除するには、その隣のマイナスアイコンをクリック
します。
7c 他のメタ属性を追加するには、空のドロップダウンボックスをクリッ
クし、属性を選択します。属性のデフォルト値が表示されます。必
要な場合は、上述したとおり変更します。
8 ［リソースの作成］をクリックして、設定を完了します。画面上のメッセー
ジが、リソースが正常に作成されたかどうかを表示します。
図 5.5 Hawk - プリミティブリソース
5.3.3 STONITHリソースの作成
重要: STONITHがない場合はサポートなし
STONITHがないクラスタはサポートされません。
デフォルトでは、グローバルクラスタオプションstonith-enabledはtrue
に設定されています。STONITHリソースが定義されていない場合、クラスタ
はどのリソースの開始も拒否します。1つ以上のSTONITHリソースを設定し
114
高可用性ガイド
て、STONITHのセットアップを完了します。STONITHは他のリソースと同様
に設定しますが、その動作はいくつかの点で異なっています。詳細について
は、9.3項「STONITHのリソースと環境設定」 (230 ページ)を参照してくださ
い。
手順 5.6 STONITHリソースの追加
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［リソース］を選択します。［リソース］画
面には、すべてのタイプのリソースのカテゴリと、定義済みのすべてのリ
ソースが表示されます。
3 ［プリミティブ］カテゴリを選択し、プラスアイコンをクリックします。
4 リソースを次のとおり指定します。
4a 固有の［リソースID］を入力します。
4b ［クラス］リストで、リソースエージェントクラスとして［stonith］
を選択します。
4c ［タイプ］リストから、使用しているSTONITHデバイスのSTONITH
プラグインを選択します。このプラグインの簡単な説明が下に表示
されます。
5 Hawkは、自動的にそのリソースに必要な［パラメータ］を表示します。そ
れぞれのパラメータの値を入力します。
6 Hawkは、重要なリソース［操作］を表示し、デフォルト値を提案します。
ここで設定を変更しない場合、確定するとすぐに、Hawkは提案した操作お
よびデフォルト値を追加します。
7 特に変更する理由がない場合には、［メタ属性］の設定はデフォルトを採
用してください。
8 変更を確認して、STONITHリソースを作成します。
クラスタリソースの設定と管理(Webインタフェース)
115
フェンシングを設定するには、制約の追加とクローンの使用のいずれか、ま
たはその両方を行います。詳細については、第9章フェンシングと
STONITH (227 ページ)を参照してください。
5.3.4 リソーステンプレートの使用
類似した設定のリソースを多く作成する最も簡単な方法は、リソーステンプ
レートを定義することです。リソーステンプレートを定義した後は、プリミ
ティブの中や、特定のタイプの制約で参照できるようになります。リソース
テンプレートの機能と使用方法の詳細については、4.4.3項「リソーステンプ
レートと制約」 (84 ページ)を参照してください。
手順 5.7 リソーステンプレートの作成
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［リソース］を選択します。［リソース］画
面には、すべてのタイプのリソースのカテゴリに加えて、［テンプレート］
カテゴリが表示されます。
3 ［テンプレート］カテゴリを選択し、プラスアイコンをクリックします。
4 ［テンプレートID］を入力します。
5 プリミティブを指定するリソーステンプレートを指定します。手順 5.5: プ
リミティブリソースを追加するに従って、ステップ 4b (112 ページ)を開始し
ます。
6 ［リソースの作成］をクリックして、設定を完了します。画面上のメッセー
ジが、リソーステンプレートが正常に作成されたかどうかを表示します。
116
高可用性ガイド
図 5.6 Hawk - リソーステンプレート
手順 5.8 リソーステンプレートの参照
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 新しく作成したリソーステンプレートをプリミティブで参照するには、次
の手順に従います。
2a 左のナビゲーションバーで、［リソース］を選択します。［リソー
ス］画面に、すべてのタイプのリソースのカテゴリが表示されます。
定義済みのすべてのリソースが表示されます。
2b ［プリミティブ］カテゴリを選択し、プラスアイコンをクリックし
ます。
2c 固有の［リソースID］を入力します。
2d ［テンプレートの使用］をオンにして、ドロップダウンリストから
参照するテンプレートを選択します。
クラスタリソースの設定と管理(Webインタフェース)
117
2e 必要であれば、さらに［パラメータ］、［操作］、または［メタ属
性］を手順5.5「プリミティブリソースを追加する」 (112 ページ)で説
明した方法で指定します。
3 新しく作成したリソーステンプレートをコロケーションまたは順序の制約
で参照するには、手順5.10「コロケーションまたは順序の制約を追加また
は変更する」 (119 ページ)で説明する手順に従います。
5.3.5 リソース制約の設定
すべてのリソースを設定したら、クラスタがそれらを扱う方法を指定します。
リソース制約を使えば、リソースがどのクラスタノードで実行されるか、リ
ソースをどの順番でロードするか、そして特定のリソース型のどのリソース
に依存するかを指定することができます。
利用可能な制約のタイプの概要は、4.4.1項「制約のタイプ」 (81 ページ)を参
照してください。制約を定義する際には、スコアも指定する必要があります。
スコアおよびクラスタでのそれらの意味の詳細については、4.4.2項「スコア
と無限大」 (84 ページ)を参照してください。
次に、さまざまな制約タイプの作成方法について説明します。
手順 5.9 場所の制約を追加または変更する
場所の制約の場合には、制約ID、リソース、スコアおよびノードを指定しま
す。
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［制約］を選択します。［制約］画面に、す
べてのタイプの制約のカテゴリが表示されます。定義済みのすべての制約
が表示されます。
3 新しい［場所］制約を追加するには、対応するカテゴリのプラスアイコン
をクリックします。
既存の制約を変更するには、制約の隣にあるレンチアイコンをクリックし
て、［制約の編集］を選択します。
118
高可用性ガイド
4 固有の［制約ID］を入力します。既存の制約を変更する場合には、IDはす
でに定義されています。
5 制約を設定する［リソース］を選択します。リストには、そのクラスタに
設定されているすべてのリソースのIDが表示されます。
6 制約の［Score (スコア)］を設定します。正の値は、次のステップで指定す
る［ノード］でリソースを実行できることを示します。負の値は、リソー
スをそのノードで実行すべきではないことを示します。スコアをINFINITY
に設定すれば、リソースはこのノードで実行されるように強制されます。
-INFINITYに設定すれば、リソースはそのノードで実行してはならないこ
とになります。
7 制約を設定する［ノード］を選択します。
8 ［制約の作成］をクリックして、設定を完了します。画面上のメッセージ
が、制約が正常に作成されたかどうかを表示します。
図 5.7 Hawk - 場所制約
手順 5.10 コロケーションまたは順序の制約を追加または変更する
どちらの制約の場合でも、制約IDとスコアを指定してから、リソースを依存
チェーンに追加します。
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［制約］を選択します。［制約］画面には、
すべてのタイプの制約のカテゴリと、定義済みのすべての制約が表示され
ます。
クラスタリソースの設定と管理(Webインタフェース)
119
3 新しい［コロケーション］または［順序］制約を追加するには、対応する
カテゴリのプラスアイコンをクリックします。
既存の制約を変更するには、制約の隣にあるレンチアイコンをクリックし
て、［制約の編集］を選択します。
4 固有の［制約ID］を入力します。既存の制約を変更する場合には、IDはす
でに定義されています。
5 ［スコア］を定義します。
コロケーション制約の場合には、スコアは複数のリソースの場所のリレー
ションシップを決定します。正の値は、リソースを同じノードで実行する
べきであることを示します。負の値は、リソースを同じノードで実行する
べきではないことを示します。スコアをINFINITYに設定すれば、リソー
スは同じノードで実行されるように強制されます。-INFINITYに設定すれ
ば、リソースは同じノードで実行してはならないことになります。スコア
と他の要因との組み合わせによって、ノードの配置先が決定します。
順序の制約の場合、0より大きなスコアなら必須となります。そうでなけれ
ば、単なる提案として扱われます。デフォルト値は、INFINITYです。
6 順序の制約の場合、オプション［シンメトリック］は常に有効にしていて
ください。これは、リソースを停止するときには逆順で行うという指定で
す。
7 制約のリソースを定義するには、次の手順に従います。
7a ［リソースを制約に追加］リストからリソースを選択します。リス
トには、そのクラスタに設定されているすべてのリソースとリソー
ステンプレートのIDが表示されます。
7b 選択したリソースを追加するには、リストの隣のプラスアイコンを
クリックします。下に新しいリストが表示されます。次のリソース
をリストから選択します。コロケーション制約と順序の制約はどち
らもリソース間の依存関係を定義するのものなので、少なくとも2つ
のリソースが必要です。
7c ［リソースを制約に追加］リストから残りのリソースのいずれかを
選択します。リソースを追加するには、プラスアイコンをクリック
します。
120
高可用性ガイド
これで、依存チェーンに2つのリソースが追加されました。
順序の制約の場合には、一番上のリソースが最初に起動され、その
下のリソースがその次に起動される、といった順序になります。通
常、リソースを停止するときには逆順で行われます。
ただし、コロケーション制約を定義した場合、リソース間に矢印が
表示され、依存関係を示しますが、これは起動順ではありません。
最上位のリソースは次のリソースなど順に依存するため、クラスタ
はまず最後のリソースを置く場所を決め、次にその決定に基づいて
依存するものを配置していきます。制約が満たされないと、クラス
タは依存するリソースが実行しないようにすることがあります。
7d コロケーションまたは順序の制約に必要なだけ、リソースを追加し
ます。
7e 2つのリソースの順序を交換するには、リソースの右側にある二重線
の矢印をクリックすると、依存チェーンの中でリソースが交換され
ます。
8 必要であれば、リソースごとに、役割(Master、Slave、Started、
Stopped)などのパラメータをさらに指定します。
9 ［制約の作成］をクリックして、設定を完了します。画面上のメッセージ
が、制約が正常に作成されたかどうかを表示します。
図 5.8 Hawk - コロケーション制約
クラスタリソースの設定と管理(Webインタフェース)
121
コロケーションまたは順序の制約を定義するための別のフォーマットとして、
リソースセットを使用することができます。これらは、グループとして同じ
意味論に従います。
手順 5.11 コロケーションまたは順序の制約のためにリソースセットを使用
する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 手順5.10「コロケーションまたは順序の制約を追加または変更す
る」 (119 ページ)で説明した方法に従って、コロケーションまたは順序の制
約を定義します。
3 リソースを依存チェーンに追加した場合には、右側にあるチェーンアイコ
ンをクリックして、リソースをリソースセットに入れることができます。
リソースセットは、セットに属しているリソースの周囲のフレームによっ
て示されます。
4 また、リソースセットに複数のリソースを追加したり、複数のリソースセッ
トを作成したりすることもできます。
5 リソースセットからリソースを取り出すには、そのリソースの上にあるハ
サミアイコンをクリックします。
リソースはセットから除かれて、依存チェーンの中の元の場所に戻ります。
6 変更を確認して、制約の設定を完了します。
122
高可用性ガイド
制約の設定の詳細や、順序およびコロケーションの基本的な概念についての
詳細なバックグラウンド情報は、http://www.clusterlabs.org/doc/で
提供されているドキュメントを参照してください。
• 『Pacemaker Explained』の「Resource Constraints」の章
• 『Colocation Explained』
• 『オーダーの概要』
手順 5.12 制約の削除
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［制約］を選択します。［制約］画面には、
すべてのタイプの制約のカテゴリと、定義済みのすべての制約が表示され
ます。
3 制約の隣のレンチアイコンをクリックして［制約の削除］を選択します。
5.3.6 リソースフェールオーバーノードの指
定
リソースに障害が発生すると、自動的に再起動されます。現在のノードで再
起動できない場合、または現在のノードでN回失敗した場合は、別のノードへ
のフェールオーバーが試行されます。新しいノードへのマイグレートを行う
基準(migration-threshold)となるリソースの失敗数を定義できます。ク
ラスタ内に3つ以上ノードがある場合、特定のリソースのフェールオーバー先
のノードはHigh Availabilityソフトウェアにより選択されます。
リソースがフェールオーバーする特定のノードを前もって指定するには、次
の手順に従います。
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 手順5.9「場所の制約を追加または変更する」 (118 ページ)に記されている手
順に従って、そのリソースの場所の制約を設定します。
クラスタリソースの設定と管理(Webインタフェース)
123
3 手順 5.5: プリミティブリソースを追加するに説明されている手順に従って
リソースにmigration-thresholdメタ属性を追加し、ステップ
7 (113 ページ)migration-thresholdの［値］を入力します。INFINITYではない
正の値を指定する必要があります。
4 リソースの失敗回数を自動的に失効させる場合は、手順 5.5: プリミティブ
リソースを追加する、ステップ 7 (113 ページ)に記されている手順に従って
failure-timeoutメタ属性をそのリソースに追加し、失敗タイムアウト
の［値］を入力します。
5 リソースの初期設定として、追加のフェールオーバーノードを指定する場
合は、追加の場所の制約を作成します。
マイグレーションしきい値と失敗カウントに関連したプロセスフローは、例
4.6「マイグレーションしきい値 - プロセスフロー」 (85 ページ)に示されてい
ます。
リソースの失敗回数は、自動的に期限切れにする代わりに、いつでも、手動
でクリーンアップすることもできます。詳細については、5.4.2項「リソース
のクリーンアップ」 (134 ページ)を参照してください。
5.3.7 リソースフェールバックノードの指定
(リソースの固着性)
ノードがオンライン状態に戻り、クラスタ内にある場合は、リソースが元の
ノードにフェールバックすることがあります。このことを防ぐ、またはリソー
スのフェールバック先として別のノードを指定するには、リソースの固着性
の値を変更します。リソースの固着性は、リソースを作成するとき、または
作成した後のどちらでも指定できます。
さまざまなリソース固着性値の意味については、4.4.5項「フェールバックノー
ド」 (86 ページ)を参照してください。
124
高可用性ガイド
手順 5.13 リソースの固着性を指定する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 手順 5.5: プリミティブリソースを追加する、ステップ 7 (113 ページ)に従っ
て、resource-stickinessメタ属性をリソースに追加します。
3 リソースの固着性として、-INFINITYとINFINITYの間の値を指定しま
す。
5.3.8 負荷インパクトに基づくリソース配置
の設定
すべてのリソースが同等ではありません。Xenゲストなどの一部のリソースで
は、そのホストであるノードがリソースの容量要件を満たす必要があります。
配置したリソースの要件の合計が提供容量よりも大きくなった場合には、リ
ソースのパフォーマンスが低下するか、または失敗します。
これを考慮に入れて、High Availability Extensionでは、次のパラメータを指定
できます。
1. 一定のノードが提供する容量
2. 一定のリソースが要求する容量
3. リソースの配置に関する全体的なストラテジ
使用属性は、リソースの要件と、ノードが提供する容量の両方を設定するた
めに使用されます。High Availability Extensionには、ノードの容量とリソース
の要件を自動的に検出し、設定する手段も用意されています。詳細と設定例
については、4.4.6項「負荷インパクトに基づくリソースの配置」 (87 ページ)
を参照してください。
ノードの容量値(使用属性によって定義されたもの)、およびそのノードで実行
されているリソースが現在消費している容量を表示するには、Hawkの［クラ
スタの状態］画面に切り替えます。対象とするノードを選択し、そのノード
の隣のレンチアイコンをクリックして、［詳細の表示］を選択します。
クラスタリソースの設定と管理(Webインタフェース)
125
図 5.9 Hawk - ノードの容量値の表示
ノードが提供する容量とリソースが要求する容量を設定した後、グローバル
クラスタオプションで配置ストラテジを設定する必要があります。これを設
定しないと、容量の設定は有効になりません。負荷のスケジュールに使用で
きるストラテジがいくつかあります。たとえば、負荷をできるだけ少ない数
のノードに集中したり、使用可能なすべてのノードに均等に分散できます。
詳細については、4.4.6項「負荷インパクトに基づくリソースの配
置」 (87 ページ)を参照してください。
手順 5.14 配置ストラテジを設定する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタのプロパティ］を選択して、グロー
バルクラスタオプションとそれらの現在の値を表示します。
3 ［新しいプロパティの追加］ドロップダウンリストから、
placement-strategyを選択します。
4 要件に応じて、［配置ストラテジ］を適切な値に設定します。
5 プラスアイコンをクリックして、新しいクラスタプロパティ(値を含む)を
追加します。
6 変更内容を確認します。
126
高可用性ガイド
5.3.9 リソース監視の設定
High Availability Extensionは、ノードの障害を検出できるだけではなく、ノー
ドの個々のリソースで障害が発生した場合、そのことも検出できます。リソー
スが実行中であるかどうか確認するには、そのリソースにリソースの監視を
設定します。リソースを監視するには、タイムアウト、開始遅延のいずれか、
または両方と、間隔を指定します。間隔の指定によって、CRMにリソースス
テータスの確認頻度を指示します。startまたはstop操作に対するTimeout
など、特定のパラメータも設定できます。
手順 5.15 監視操作を追加または変更する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［リソース］を選択します。［リソース］画
面には、すべてのタイプのリソースのカテゴリと、定義済みのすべてのリ
ソースが表示されます。
3 変更するリソースを選択し、その隣のレンチアイコンをクリックして、［リ
ソースの編集］を選択します。リソースの定義が表示されます。Hawkは、
重要なリソース操作(monitor、start、stop)を自動的に表示し、デフォ
ルト値を提案します。
4 操作の値を変更するには
4a 操作の隣のペンアイコンをクリックします。
4b 表示されるダイアログで、次の値を指定します。
• timeout値を秒単位で入力します。指定したタイムアウトを過ぎ
ると、操作はfailedと見なされます。PEは何を行うか、あるいは
監視操作の［On Fail (障害発生時の動作)］フィールドで指定した
内容を実行するかどうかを判断します。
• 監視操作の場合には、intervalに監視の間隔を秒単位で入力しま
す。
必要な場合には、［監視］ダイアログの下部にある空のドロップダ
ウンボックスを使用して、［失敗の場合］(このアクションが失敗し
クラスタリソースの設定と管理(Webインタフェース)
127
た場合の処理)などのパラメータを追加します。または［必要］(この
アクションを発生する前に満たす必要がある条件)などのパラメータ
を追加します。
4c 変更を確認してダイアログを閉じ、［リソースの編集］画面に戻り
ます。
5 操作を完全に削除するには、その隣のマイナスアイコンをクリックします。
6 他の操作を追加するには、空のドロップダウンボックスをクリックし、操
作を選択します。操作のデフォルト値が表示されます。必要に応じて、ペ
ンアイコンをクリックしてこれを変更します。
7 ［変更の適用］をクリックして、設定を完了します。画面上のメッセージ
が、リソースが正常に更新されたかどうかを表示します。
リソースモニタが障害を検出した場合の処理については、4.3項「リソース監
視」 (79 ページ)を参照してください。
リソースの障害を表示するには、Hawkで［クラスタステータス］画面に切り
替えて、関係するリソースを選択します。リソースの隣のレンチアイコンを
クリックして、［詳細の表示］を選択します。
128
高可用性ガイド
5.3.10 クラスタリソースグループの構成
クラスタリソースの中には、他のコンポーネントやリソースに依存しており、
各コンポーネントや各リソースを特定の順序で開始することや、同じサーバ
上で一緒に実行することが必要なものもあります。この構成を簡単にするた
め、グループのコンセプトをサポートしています。
リソースグループの例と、グループとそのプロパティの詳細について、4.2.5.1
項「グループ」 (66 ページ)を参照してください。
注記: 空のグループ
グループには1つ以上のリソースを含む必要があります。空の場合は設定は
無効になります。Hawkでは、グループの作成中にプリミティブを作成した
り変更したりすることはできません。グループを追加する前に、プリミティ
ブを作成し、必要に応じて設定しておいてください。詳細については、手
順5.5「プリミティブリソースを追加する」 (112 ページ)を参照してくださ
い。
手順 5.16 リソースグループを追加する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［リソース］を選択します。［リソース］画
面には、すべてのタイプのリソースのカテゴリと、定義済みのすべてのリ
ソースが表示されます。
3 ［グループ］カテゴリを選択し、プラスアイコンをクリックします。
4 固有の［グループID］を入力します。
5 グループのメンバーを定義するには［使用可能なプリミティブ］のリスト
から1つまたは複数のエントリを選択し、< アイコンをクリックして、［グ
ループの子］リストに追加します。新しいグループメンバーは、リストの
一番下に追加されます。グループメンバーの順序を定義するには、この時
点でグループメンバーの追加および削除を必要な順序で行う必要がありま
す。
クラスタリソースの設定と管理(Webインタフェース)
129
6 必要に応じ、プリミティブリソースを追加する、ステップ 7 (113 ページ)に
説明されている手順で、［メタ属性］を変更または追加します。
7 ［グループの作成］をクリックして、設定を完了します。画面上のメッセー
ジが、グループが正常に作成されたかどうかを表示します。
図 5.10 Hawk - リソースのグループ
5.3.11 クローンリソースの設定
特定のリソースをクラスタ内の複数のノードで同時に実行することが必要な
場合には、それらのリソースをクローンとして設定します。たとえば、
STONITHのようなりソースや、OCFS2のようなクラスタファイルシステムの
クローンを作成することには意味があります。提供されているどのリソース
も、クローンとして設定できます。クローンは、リソースのリソースエージェ
ントによってサポートされます。クローンリソースは、動作しているノード
に応じて設定を変えることもできます。
利用可能なリソースクローンのタイプの概要は、4.2.5.2項「クロー
ン」 (68 ページ)を参照してください。
注記: クローンのためのサブリソース
クローンには、プリミティブまたはグループのいずれかをサブリソースと
して含めることができます。Hawkでは、クローンの作成中にプリミティブ
を作成したり変更したりすることはできません。クローンを追加する前に、
130
高可用性ガイド
プリミティブを作成し、必要に応じて設定しておいてください。詳細につ
いては、手順5.5「プリミティブリソースを追加する」 (112 ページ)または手
順5.16「リソースグループを追加する」 (129 ページ)を参照してください。
手順 5.17 クローンを追加または変更する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［リソース］を選択します。［リソース］画
面には、すべてのタイプのリソースのカテゴリと、定義済みのすべてのリ
ソースが表示されます。
3 ［クローン］カテゴリを選択し、プラスアイコンをクリックします。
4 固有の［クローンID］を入力します。
5 ［子リソース］リストから、クローンのサブリソースとして使用するプリ
ミティブまたはグループを選択します。
6 必要に応じ、手順 5.5: プリミティブリソースを追加する、ステップ
7 (113 ページ)に説明されている手順で、［メタ属性］を変更または追加し
ます。
7 ［クローンを作成］をクリックして、設定を完了します。画面上のメッセー
ジが、クローンが正常に作成されたかどうかを表示します。
クラスタリソースの設定と管理(Webインタフェース)
131
図 5.11 Hawk - クローンリソース
5.4 クラスタリソースの管理
Hawkでは、クラスタリソースを設定することに加えて、［クラスタステータ
ス］画面で既存のリソースを管理することができます。画面、それぞれの
ビュー、およびステータス情報で使用するカラーコードの一般的な概要は、
5.1.2項「メイン画面: クラスタステータス」 (104 ページ)を参照してください。
基本的なリソース操作は、クラスタステータスビューから実行できます。［ツ
リービュー］および［テーブルビュー］は、どちらからでも、個々のリソー
スに直接アクセスすることができます。ただし、［サマリビュー］では、リ
ソースの詳細を表示するのに、まずリソースカテゴリの中のリンクをクリッ
クする必要があります。詳細ビューにもそのリソースのすべての属性が表示
されます。プリミティブリソース(通常のプリミティブ、グループの子、ク
ローン、またはマルチステートリソース)については、次の情報が追加で表示
されます。
• リソースの失敗回数
最終失敗時のタイムスタンプ(失敗回数が0より大きい場合)
• 操作履歴とタイミング(コールID、操作、最終実行時のタイムスタンプ、実
行時間、キュー時間、戻りコード、最後の変更タイムスタンプ)
132
高可用性ガイド
図 5.12 リソースの詳細の表示
5.4.1 リソースの開始
クラスタリソースは、起動する前に、正しく設定されているようにします。
たとえば、Apacheサーバをクラスタリソースとして使用する場合は、まず、
Apacheサーバをセットアップし、Apacheの環境設定を完了してから、クラス
タで個々のリソースを起動します。
注記: クラスタによって管理されるサービスには介入しないでください。
High Availability Extensionでリソースを管理しているときに、同じリソース
を他の方法(クラスタ外で、たとえば、手動、ブート、再起動など)で開始し
たり、停止してはなりません。High Availability Extensionソフトウェアが、
すべてのサービスの開始または停止アクションを実行します。
ただし、サービスが適切に構成されているか確認したい場合は手動で開始
しますが、High Availabilityが起動する前に停止してください。
現在クラスタで管理されているリソースへの介入については、まず、手順
5.23「リソースへの保守モードの適用」 (138 ページ)で説明されているよう
に、リソースをmaintenance modeに設定します。
クラスタリソースの設定と管理(Webインタフェース)
133
Hawkでリソースを作成するときには、target-roleメタ属性でその初期状
態を設定することができます。その値をstoppedに設定した場合、リソース
は、作成後、自動的に開始することはありません。
手順 5.18 新しいリソースを起動する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタステータス］を選択します。
3 個々のリソースビューのいずれかで、リソースの隣のレンチアイコンをク
リックして、［開始］を選択します。継続するには、表示されるメッセー
ジに対して確認します。リソースが開始すると、Hawkはすぐにリソースの
色を緑に変え、それがどのノードで実行されているかを表示します。
5.4.2 リソースのクリーンアップ
リソースは、失敗した場合は自動的に再起動しますが、失敗のたびにリソー
スの失敗回数が増加します。
リソースに対してmigration-thresholdが設定されていた場合、失敗回数
が移行しきい値に達すると、そのリソースはそのノードでは実行されなくな
ります。
リソースの失敗回数は、(リソースにfailure-timeoutオプションを設定す
ることにより)自動的にリセットするか、または次に示すように手動でリセッ
トできます。
手順 5.19 リソースをクリーンアップする
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタステータス］を選択します。
3 個々のリソースビューのいずれかで、リソースの隣のレンチアイコンをク
リックして、［クリーンアップ］を選択します。継続するには、表示され
るメッセージに対して確認します。
134
高可用性ガイド
これによって指定したノード上の指定したリソースに対して、コマンド
crm_resource -Cおよびcrm_failcount -Dが実行されます。
詳細は、crm_resourceおよびcrm_failcountのマニュアルページを参照
してください。
5.4.3 クラスタリソースの削除
リソースをクラスタから削除する必要がある場合は、次の手順に従って、設
定エラーが発生しないようにします。
手順 5.20 クラスタリソースの削除
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタステータス］を選択します。
3 手順5.19「リソースをクリーンアップする」 (134 ページ)の説明に従って、
すべてのノードでリソースをクリーンアップします。
4 個々のリソースビューのいずれかで、リソースの隣のレンチアイコンをク
リックして、［開始］を選択します。継続するには、表示されるメッセー
ジに対して確認します。
5 変更するリソースを選択し、その隣のレンチアイコンをクリックして、［リ
ソースの削除］を選択します。
5.4.4 クラスタリソースの移行
5.3.6項「リソースフェールオーバーノードの指定」 (123 ページ)で説明したよ
うに、ソフトウェアまたはハードウェアの障害時には、クラスタは定義可能
な特定のパラメータ(たとえばマイグレーションしきい値やリソースの固着性
など)に従って、リソースを自動的にフェールオーバー(マイグレート)させま
す。それ以外に、クラスタ内の別のノードにリソースを手動で移行させるこ
ともできます。または、リソースを現在のノードから出して、どこに移動す
るかはクラスタに判断させることもできます。
クラスタリソースの設定と管理(Webインタフェース)
135
手順 5.21 リソースを手動で移行する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタステータス］を選択します。
3 個々のリソースビューのいずれかで、リソースの隣のレンチアイコンをク
リックして、［移動］を選択します。
4 新規ウィンドウで、リソースの移動先ノードを選択します。
これによって移動先ノードに対してINFINITYスコアの場所の制約が作成
されます。
5 または、リソースを［現在のノードから］移動するように選択します。
これによって現在のノードに対して-INFINITYスコアによる場所の制約が
作成されます。
6 ［OK］をクリックして、マイグレーションを確認します。
リソースを再び元に戻すには、次の手順に従います。
手順 5.22 移行制約をクリアする
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタステータス］を選択します。
136
高可用性ガイド
3 個々のリソースビューのいずれかで、リソースの隣のレンチアイコンをク
リックして、［再配置ルールを無視］を選択します。継続するには、表示
されるメッセージに対して確認します。
これによって、crm_resource -Uコマンドが使用されます。リソースは
元の場所に戻ることができます。あるいは現在の場所に残ることもありま
す(リソースの固着性によって)。
詳細は、crm_resourceのマニュアルページ、またはPacemaker Explainedを
参照してください。http://www.clusterlabs.org/doc/から入手できま
す。特に、「Resource Migration」のセクションを参照してください。
5.4.5 保守モードの使用
クラスタ設定の変更時、個々のノードに対するソフトウェアパッケージの更
新時、または上位製品バージョンへのクラスタのアップグレード時であって
も、個々のクラスタコンポーネント上、またはクラスタ全体でテストや保守
タスクを実行する必要がある場合があります。
それに関して、High Availability Extensionは、次のレベルでmaintenanceオ
プションを提供しています。
• リソースへの保守モードの適用 (138 ページ)
• ノードへの保守モードの適用 (138 ページ)
• クラスタへの保守モードの適用 (139 ページ)
警告: データ損失の危険
クラスタ制御下でサービスを実行しているときにテストまたは保守タスク
を実行する必要がある場合は、次のアウトラインに従ってください。
1. 手順を開始する前に、個々のリソース、ノード、またはクラスタ全体を
保守モードに設定します。これにより、順序正しくリソースを起動でき
ないなどの望ましくない影響、クラスタノード間でCIBが同期されないリ
スク、またはデータ損失を避けることができます。
2. 保守タスクまたはテストを実行します。
クラスタリソースの設定と管理(Webインタフェース)
137
3. 完了したら、保守モードを解除して、通常のクラスタ操作を開始します。
保守モード中にリソースおよびクラスタで何が発生するかの詳細については、
4.7項「メンテナンスモード」 (97 ページ)を参照してください。
手順 5.23 リソースへの保守モードの適用
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［リソース］を選択します。保守モードまた
は非管理対象モードにするリソースを選択し、そのリソースの隣のレンチ
アイコンをクリックして、［リソースの編集］を選択します。
3 ［メタ属性］カテゴリが開きます。
4 空のドロップダウンリストから［maintenance］属性を選択し、プラスアイ
コンをクリックして追加します。
5 maintenanceの隣のチェックボックスをオンにして、maintenance属性を
yesに設定します。
6 変更内容を確認します。
7 該当するリソースの保守作業が完了したら、そのリソースのmaintenance
属性の隣のチェックボックスをオフにします。
リソースは、この時点から再びHigh Availability Extensionソフトウェアに
よって管理されます。
手順 5.24 ノードへの保守モードの適用
1つのノードを保守モードにする必要がある場合があります。
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタステータス］を選択します。
3 個々のノードのビューのいずれかで、ノードの隣のレンチアイコンをクリッ
クして、［保守］を選択します。
138
高可用性ガイド
これにより、maintenance="true"というインスタンス属性がノードに
追加されます。保守モードのノードでこれまで実行されていたリソースは、
unmanagedになります。保守モードを終了するまで、このノードに新しい
リソースが割り当てられることはありません。
4 保守モードを無効化するには、そのノードの隣のレンチアイコンをクリッ
クして［準備完了］を選択します。
手順 5.25 クラスタへの保守モードの適用
クラスタ全体に保守モードを設定または設定解除するには、次の手順に従い
ます。
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタ設定］を選択します。
3 ［CRMの環境設定］グループで、空のドロップダウンボックスから
［maintenance-mode］属性を選択し、プラスアイコンをクリックして追加し
ます。
4 maintenance-mode=trueを設定するには、maintenance-modeの隣の
チェックボックスをオンにして、変更を確認します。
5 クラスタ全体の保守作業が完了したら、maintenance-mode属性の隣の
チェックボックスをオフにします。
この時点から、High Availability Extensionはクラスタ管理をもう一度引き継
ぎます。
5.4.6 クラスタ履歴の表示
Hawkには、クラスタの過去のイベントを表示する、次のような機能がありま
す(いくつかの詳細さのレベルがあります)。
手順 5.26 ノードまたリソースの最近のイベントの表示
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
クラスタリソースの設定と管理(Webインタフェース)
139
2 左のナビゲーションバーで、［クラスタステータス］を選択します。
3 ［ツリービュー］または［テーブルビュー］で、対象とするリソースまた
はノードの隣のレンチアイコンをクリックして、［最近のイベントを表示］
を選択します。
表示されるダイアログには、直前の1時間のイベントが表示されます。
手順 5.27 履歴エクスプローラで遷移を表示する
［履歴エクスプローラ］には、定義できるタイムフレームでの遷移情報が表
示されます。ここではこれまでの実行内容が一覧され、不必要になったレポー
トを［削除］することができます。［履歴エクスプローラ］は、hb_report
で提供される情報を使用します。
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［履歴エクスプローラ］を選択します。
3 デフォルトでは、表示する期間は直前の24時間に設定されています。これ
を変更するには、［開始時刻］および［終了時刻］を設定します。
4 ［表示］をクリックして、遷移データの収集を開始します。
図 5.13 Hawk - 履歴レポート
140
高可用性ガイド
次の情報が表示されます。
履歴エクスプローラの結果
［時刻］
クラスタ内の過去のすべての遷移のタイムライン。
［PE Input］/［Node］
それぞれの遷移とそれが生成されたノードに関するpe-input*ファイル。
遷移ごとに、クラスタは状態のコピーを保存します。これはポリシーエン
ジンに入力として提供されます。このアーカイブがログ記録されるパス。
pe-input*ファイルは指定コーディネータ(DC)上でのみ生成されますが、
DCは変更できるので、複数のノードからのpe-input*ファイルが存在す
る可能性があります。これらのファイルは、ポリシーエンジン(PE)が何を
行うよう「予定」されているかを示します。
［Details］/［Full Log］
ポップアップウィンドウが開き、その特定の遷移に属しているログ記録
データのスニペットが表示されます。さまざまな詳細レベルを表示できま
す。［詳細情報］をクリックすると、crm history transition
peinput (リソースエージェントのログメッセージを含む)の出力が表示
されますが、［ログ全体］にはpengine、crmd、lrmdの詳細も含まれて
おり、crm history transition log peinputに相当します。
［Graph］/［XML］
それぞれの遷移のグラフとXML表現。［グラフ］を表示するように選択
した場合、(pe-input*ファイルを使用して) PEが再度呼び出され、遷移
のグラフィカルな表現が生成されます。または、グラフのXML表現を表
示することもできます。
クラスタリソースの設定と管理(Webインタフェース)
141
図 5.14 Hawk履歴レポート - 遷移グラフ
［差分］
複数のpe-inputが一覧表示されている場合、pe-inputの各ペアの右側に［差
分］リンクが表示されます。これをクリックすると、設定とステータスの
差異が表示されます。
5.4.7 可能性のある障害シナリオを調べる
Hawkには［シミュレータ］が用意されており、障害シナリオを、実際に発生
する前に調べることができます。シミュレータモードに切り替える前に、ノー
ドのステータスを変更したり、リソースと制約を追加または編集したり、ク
ラスタ設定を変更したり、複数のリソース操作を実行したりして、どのよう
なクラスタの動作によってこれらのイベントが発生するのかを確認すること
ができます。シミュレータモードが有効になっている間は、［クラスタステー
タス］画面の右下隅にコントロールダイアログが表示されます。シミュレー
タはすべての画面の変更内容を収集し、イベントの内部キューにそれらを追
加します。キューに入れられたイベントによる実行シミュレーションは、コ
ントロールダイアログで手動でトリガされるまでは実行されません。シミュ
レーションの実行後、実行結果の詳細(ログスニペット、遷移グラフ、CIB状
態)を表示して分析することができます。
142
高可用性ガイド
手順 5.28 シミュレータモードに切り替える
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Web
ブラウザを起動してクラスタにログインします。
2 最上位の行(ユーザ名の横)にあるレンチアイコンをクリックし、［シミュ
レータ］を選択することで、シミュレータモードをアクティブ化しま
す。
Hawkのバックグラウンド色が変化して、シミュレータがアクティブであ
ることが示されます。［クラスタステータス］画面の右下隅にシミュ
レータのコントロールダイアログが表示されます。そのタイトル［シ
ミュレータ(初期状態)］は、まだシミュレータが実行されていないこと
を示します。
3 シミュレータのイベントキューを埋めます。
3a ノードのステータスの変更をシミュレートするには、まずシミュ
レータコントロールダイアログの［+Node］をクリックします。
操作する［ノード］を選択し、そのターゲット［状態］を選択し
ます。変更を確認して、それらをコントローラダイアログに一覧
表示されるイベントのキューに追加します。
3b リソースの操作をシミュレートするには、まずシミュレータコン
トロールダイアログの［+Op］をクリックします。操作する［リ
ソース］を選択し、シミュレートする［操作］を選択します。必
要に応じて、［間隔］を定義します。操作を実行する［ノード］
を選択し、ターゲットとする［結果］を選択します。変更を確認
して、それらをコントローラダイアログに一覧表示されるイベン
トのキューに追加します。
4 シミュレートするその他のノードのステータス変更やリソース操作に対
して、前の手順を繰り返します。
クラスタリソースの設定と管理(Webインタフェース)
143
図 5.15 Hawk - イベントが挿入されたシミュレータ
5 シミュレートするその他の変更を挿入するには:
5a ［クラスタステータス］、［セットアップウィザード］、［クラ
スタ設定］、［リソース］、または［制約］といったHawk画面の
いずれかに切り替えます。
注記: 履歴エクスプローラとシミュレータモード
［履歴エクスプローラ］タブをクリックすると、シミュレータ
モードが無効になります。
5b 必要に応じて、画面上でパラメータの追加や変更を行います。
シミュレータはすべての画面の変更内容を収集し、イベントの内
部キューにそれらを追加します。
5c シミュレータコントロールダイアログに戻るには、［クラスタス
テータス］画面に切り替えるか、もう一度最上位の行のレンチア
イコンをクリックして［シミュレータ］をクリックします。
6 ［挿入された状態］に一覧されているイベントを削除する場合は、それ
ぞれのエントリを選択して、リストのすぐ下のマイナスアイコンをク
リックします。
144
高可用性ガイド
7 シミュレータコントロールダイアログで［実行］をクリックして、シ
ミュレーションの実行を開始します。［クラスタステータス］画面に、
シミュレートされるイベントが表示されます。たとえば、あるノードを
アンクリーンとしてマークした場合、それはオフラインとして表示さ
れ、そのすべてのリソースは停止されます。シミュレータコントロール
ダイアログは、［シミュレータ(最終状態)］に変わります。
図 5.16 Hawk - 最終状態のシミュレータ
8 シミュレーションの実行に関する詳細情報を表示するには:
8a シミュレータダイアログの［詳細］リンクをクリックして、実行
結果のログスニペットを表示します。
8b ［グラフ］リンクをクリックして遷移グラフを表示します。
8c ［CIB (in)］をクリックしてCIB状態を表示します。遷移の後のCIB
を表示するには、［CIB (out)］をクリックします。
9 新しいシミュレーションを最初から開始するには、［リセット］ボタン
をクリックします。
10 シミュレーションモードを終了するには、シミュレータコントロールダ
イアログを閉じます。［クラスタステータス］画面は切り替わって、元
の色に戻り、クラスタの現在の状態を表示します。
クラスタリソースの設定と管理(Webインタフェース)
145
5.4.8 クラスタレポートの生成
クラスタで発生している問題の分析と診断のために、Hawkはクラスタレポー
トを生成することができます。これは、クラスタ内のすべてのノードからの
情報を集めたものです。
手順 5.29 hb_reportを生成する
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 最上位の行のユーザ名の隣にあるレンチアイコンをクリックして、
［hb_reportの生成］を選択します。
3 デフォルトでは、調査する期間は直前の1時間です。これを変更するには、
［開始時刻］および［終了時刻］を設定します。
4 ［生成］をクリックします。
5 レポートが作成されたら、対応するリンクをクリックして、*.tar.bz2
ファイルをダウンロードします。
hb_reportおよびcrm_reportのようなツールが対応するログファイルの詳
細については、「すべてのクラスタノードの分析を含むレポートを作成する
にはどうしたらよいですか。」 (355 ページ)を参照してくだい。
5.5 複数のクラスタの監視
複数のクラスタを監視するためのシングルポイント管理としてHawkを使用で
きます。Hawkの［クラスタダッシュボード］では、複数のクラスタのサマリ
を表示することができます。ここには各サマリのノード、リソース、チケッ
ト(Geoクラスタを使用している場合)の数と、それぞれの状態が表示されま
す。このサマリには、それぞれのクラスタで障害が発生しているかどうかも
表示されます。
［Cluster Dashboard］に表示されているクラスタ情報は、永続クッキーに保存
されます。つまり、［Cluster Dashboard］を表示するHawkインスタンスを決
定し、そのインスタンスを常に使用する必要があります。Hawkを実行するマ
146
高可用性ガイド
シンは、その目的のためにクラスタの一部である必要はなく、別個の無関係
のシステムで構いません。
手順 5.30 Hawkによる複数クラスタの監視
前提条件
• Hawkの［Cluster Dashboard］で監視するすべてのクラスタでは、SUSE Linux
Enterprise High Availability Extension 11 SP4を実行している必要があります。
それより前のバージョンのSUSE Linux Enterprise High Availability Extension
を実行しているクラスタは監視できません。
• すべてのクラスタノードにあるHawkの自己署名証明書を独自の証明書(また
は公式認証局によって署名された証明書)で置き換えていない場合は、「す
べての」クラスタの「すべての」ノードで、少なくとも1回はHawkにログ
インします。証明書を検証します(または、ブラウザで例外を追加して警告
をスキップします)。
• Mozilla Firefoxをご使用の場合は、環境設定を［サードパーティのCookieも
保存する］に変更する必要があります。そうでない場合、監視対象のクラ
スタのクッキーが設定されないため、監視しようとするクラスタにログイ
ンできなくなります。
1 複数のクラスタを監視するマシン上で、Hawk Webサービスを開始します。
2 Webブラウザを起動して、Hawkを実行するマシンのIPアドレスまたはホス
ト名を入力します。
https://IPaddress:7630/
3 Hawkのログイン画面で、右上隅の［ダッシュボード］リンクをクリックし
ます。
［クラスタの追加］ダイアログが表示されます。
クラスタリソースの設定と管理(Webインタフェース)
147
4 ［Cluster Dashboard］でクラスタを識別するためのカスタムのクラスタ名
を［クラスタ名］に入力します。
5 クラスタノードのいずれかの［ホスト名］を入力し、変更内容を確認しま
す。
［クラスタダッシュボード］が開き、追加したクラスタのサマリが表示さ
れます。
6 ダッシュボードにクラスタをさらに追加するには、プラスアイコンをクリッ
クして、次のクラスタの詳細を入力します。
148
高可用性ガイド
図 5.17 Hawk - Cluster Dashboard
7 ダッシュボードからクラスタを削除するには、クラスタのサマリの隣のxア
イコンをクリックします。
8 クラスタの詳細を表示するには、ダッシュボード上でクラスタのボックス
内の任意の場所をクリックします。
これにより、新しいブラウザウィンドウまたは新しいブラウザタブが開き
ます。クラスタに現在ログインしていない場合は、Hawkのログイン画面が
開きます。ログインしたら、Hawkのサマリビューに、そのクラスタの［ク
ラスタステータス］が表示されます。その時点から、Hawkで通常どおりに
クラスタを管理できます。
9 ［クラスタダッシュボード］は独立したブラウザウィンドウまたはタブで
開いたままになっているので、ダッシュボードとHawkによる個々のクラス
タの管理とは、簡単に切り替えることができます。
ノードまたはリソースに関するステータス変更は、［Cluster Dashboard］内で
ほぼ即時に反映されます。
5.6 GeoクラスタのＨａｗｋ
地理的に離れたクラスタ(Geoクラスタ)に関連するHawk機能の詳細について
は、『Geo Clustering for SUSE Linux Enterprise High Availability Extensionクイッ
クスタート』を参照してください。
クラスタリソースの設定と管理(Webインタフェース)
149
5.7 トラブルシューティング
Hawkログファイル
Hawkログファイルは、/srv/www/hawk/logにあります。Hawkにアクセ
スできない場合には、これらのファイルをチェックしてください。
Hawkでリソースを始動または停止する際に問題が発生した場合は、
Pacemakerのログメッセージを確認します。デフォルトでは、Pacemaker
は/var/log/messagesにログします。
認証ファイル
haclientグループのメンバーである新規ユーザでHawkにログインでき
ない(または、Hawkがこのユーザからのログインを受け入れるまでに遅延
がある)場合は、nscdデーモンをrcnscd stopで停止して、再試行して
ください。
自己署名証明書の置き換え
Hawkの最初の起動で自己署名証明書に関する警告が発行されるのを避け
るには、自動生成された証明書を、独自の証明書または公式認証局(CA)に
よって署名された証明書で置き換えてください。
証明書は/etc/lighttpd/certs/hawk-combined.pemに保存され、
キーと証明書の両方を含んでいます。
パーミッションを変更して、rootだけがファイルをアクセスできるよう
にします。
root # chown root.root /etc/lighttpd/certs/hawk-combined.pem
chmod 600 /etc/lighttpd/certs/hawk-combined.pem
新しいキーと証明書を作成した後、または受け取った後に、次のコマンド
を実行してそれらを組み合わせます。
root # cat keyfile certificatefile > /etc/lighttpd/certs/hawk-combined.pem
履歴エクスプローラ/hb_reportの使用後に、Hawkへのログインが失敗する
［履歴エクスプローラ］や［hb_report］で定義した期間、およびその期間
中にクラスタで発生したイベントによっては、Hawkが、非常に大量の情
報を集める場合があります。この情報は、/tmpディレクトリのログファ
イルに保存されます。この場合、ノードの残りディスクスペースが大きく
消費されることがあります。［履歴エクスプローラ］または［hb_report］
150
高可用性ガイド
の使用後にHawkが応答しなくなった場合には、クラスタノードのハード
ディスクを確認して、対応するログファイルを削除してください。
［Cluster Dashboard］: ホストに接続できない
Hawkのダッシュボードにクラスタが追加できない場合は、手順5.30「Hawk
による複数クラスタの監視」(147 ページ)に示されている前提条件をチェッ
クしてください。
［Cluster Dashboard］: アクセスできないノード
［Cluster Dashboard］は、ステータスについてクラスタあたり1つのノー
ドのみをポールします。ポールされたノードがダウンした場合、ダッシュ
ボードは別のノードにポールして循環させます。この場合、Hawkは、そ
のノードがアクセス不可であることに関する警告メッセージをすぐに表示
します。Hawkが交信する別のノードを見つけたら、メッセージは表示さ
れなくなります。
クラスタリソースの設定と管理(Webインタフェース)
151
クラスタリソースの設定と管理
(GUI)
6
この章では、Pacemaker GUIを紹介し、グローバルクラスタオプションの変
更、基本的なリソースと高度なリソース(グループとクローン)の作成、制約の
設定、フェールオーバーノードとフェールバックノードの指定、リソースモ
ニタリングの設定、リソースの始動、クリーンアップ、または削除、および
手動によるリソースの移行など、クラスタリソースの設定と管理に必要な基
本的な作業について説明します。
GUIのサポートは、2つのパッケージで提供されます。pacemaker-mgmtパッ
ケージには、GUIのバックエンド(mgmtdデーモン)が含まれています。この
パッケージは、GUIで接続するすべてのクラスタノードにインストールする必
要があります。GUIを実行するコンピュータには、pacemaker-mgmt-client
パッケージをインストールします。
注記: ユーザの認証
Pacemaker GUIからクラスタにログインするには、そのユーザがhaclient
グループのメンバである必要があります。インストール時にはhacluster
という名前のlinuxユーザが作成され、このユーザはhaclientグループに
追加されます。
Pacemaker GUIを使用する前に、haclusterユーザのパスワードを設定す
るか、haclientグループのメンバとして新しいユーザを作成してくださ
い。
Pacemaker GUIを使用して、接続先の各ノードでこれを実行します。
クラスタリソースの設定と管理(GUI)
153
6.1 Pacemaker GUI - 概要
Pacemaker GUIを開始するには、コマンドラインに「crm_gui」と入力しま
す。設定と管理のオプションにアクセスするには、クラスタにログインする
必要があります。
6.1.1 クラスタにログインする
クラスタに接続するには、［接続］ > ［ログイン］の順に選択します。デフォ
ルトでは、［サーバ］フィールドにローカルホストのIPアドレスとhacluster
が［ユーザ名］として表示されています。ユーザのパスワードを入力して続
行します。
図 6.1 クラスタへの接続
Pacemaker GUIをリモートで実行している場合は、クラスタノードのIPアドレ
スを［サーバ］として入力します。［ユーザ名］に、haclientグループに
属する他の任意のユーザ使用して、クラスタに接続することもできます。
154
高可用性ガイド
6.1.2 メインウィンドウ
接続後、メインウィンドウが開きます。
図 6.2 Pacemaker GUI - メインウィンドウ
注記: Pacemaker GUIで利用できる機能
デフォルトでは、rootまたはhaclusterとしてログインしたユーザは、す
べてのクラスタ設定作業への、完全な読み込み/書き込みのアクセス権を持
ちます。ただし、アクセス制御リスト (239 ページ)を使用すれば、より詳細
なアクセス権限を定義することができます。
CRMでACLが有効になっている場合、Pacemaker GUIで利用できる機能は、
割り当てられたユーザ役割とアクセスパーミッションごとに異なります。
CRM、リソース、ノード、制約などのクラスタコンポーネントを表示または
変更するには、左のペインにある［設定］カテゴリの対応するサブエントリ
を選択し、使用可能になったオプションを右のペインで使用します。さらに、
Pacemaker GUIでは、サブ項目［リソースのデフォルト］、［操作のデフォル
ト］、［ノード］、［リソース］、および［制約］に関して、CIBのXMLフ
ラグメントを容易に表示、編集、インポート、およびエクスポートできます。
［設定］のサブ項目のどれかを選択し、ウィンドウの上右隅で、［表示］ >
［XMLモード］の順に選択します。
クラスタリソースの設定と管理(GUI)
155
すでにリソースを設定済みの場合は、左ペインの［管理］カテゴリをクリッ
クして、クラスタとそのリソースのステータスを表示します。この表示画面
では、ノードをstandbyに設定したり、ノードの管理ステータス(現在、ノー
ドがクラスタで管理されているかどうか)を変更することもできます。リソー
スの主要機能(リソースの起動、停止、クイックアップ、または移行)にアクセ
スするには、右のペインでリソースを選択し、ツールバーにあるアイコンを
使用します。または、リソースを右クリックして、コンテキストメニューか
ら該当するメニュー項目を選択します。
Pacemaker GUIでは、さまざまな表示モードに切り替えて、ソフトウェアの振
る舞いを操作したり、一定の側面を表示/非表示にすることもできます。
シンプルモード
ウィザードのようなモードで、リソースを追加できます。リソースの作成
と変更では、サブオブジェクトに関して頻繁に使用されるタブが表示さ
れ、タブからそのタイプのオブジェクトを直接追加できます。
左ペインで［CRM Config］エントリを選択すると、すべての使用可能な
グローバルクラスタオプションを表示し、変更できます。右ペインには、
現在設定されている値が表示されます。オプションに特定の値が設定され
ていない場合は、デフォルト値が表示されます。
エキスパートモード
ウィザード方式またはダイアログウィンドウでリソースを追加できます。
リソースの作成および変更時には、特定タイプのサブオブジェクトがすで
にCIBに存在する場合は、該当するタブだけが表示されます。新しいサブ
オブジェクトの追加時には、オブジェクトタイプを選択するように促さ
れ、サポートされているすべてのタイプのサブオブジェクトを追加できま
す。
左ペインで［CRM Config］を選択すると、実際に設定されているグロー
バルクラスタオプションの値だけが表示されます。自動的にデフォルトを
使用するクラスタオプションは、(値が設定されていないので)すべて非表
示です。このモードでは、グローバルクラスタオプションは、個々の設定
ダイアログからのみ変更できます。
ハックモード
エキスパートモードと同じ機能があります。設定をより動的にする特定の
ルールを含む属性セットを追加できます。たとえば、リソースに、そのホ
ストノードによって異なるインスタンス属性を持たせることができます。
156
高可用性ガイド
さらに、メタ属性セットに時間ベースのルールを追加して、いつ属性を有
効にするか決定することができます。
ウィンドウのステータスバーにも、現在アクティブなモードが表示されます。
以降のセクションでは、クラスタオプションとリソースの設定時に必要な主
要作業について説明し、Pacemaker GUIでリソースを管理する方法を示しま
す。特に説明されない限り、ステップバイステップの説明は、簡易モードで
実行される手順を反映しています。
6.2 グローバルクラスタオプションの
設定
グローバルクラスタオプションは、一定の状況下でのクラスタの動作を制御
します。これらは、セットにグループ化され、Pacemaker GUIやcrmシェルな
どのクラスタ管理ツールで表示し、変更することができます。事前に定義さ
れている値は、ほとんどの場合、そのまま保持できます。ただし、クラスタ
の主要機能を正しく機能させるには、クラスタの基本的なセットアップ後に、
次のパラメータを調整する必要があります。
• オプションno-quorum-policy (60 ページ)
• オプションstonith-enabled (61 ページ)
手順 6.1 グローバルクラスタオプションを変更する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 ［表示］ > ［簡易モード］の順に選択します。
3 左ペインで、［CRM Config］を選択して、グローバルクラスタオプション
とそれらの現在の値を表示します。
4 クラスタ要件に応じて、［クォーラムなしポリシー］を適切な値に設定し
ます。
5 なんらかの理由でフェンシングを無効にする必要がある場合は、［stonithenabled］の選択を解除します。
クラスタリソースの設定と管理(GUI)
157
重要: STONITHがない場合はサポートなし
STONITHが有効でないクラスタはサポートされません。
6 ［適用］をクリックして、変更を確認します。
左ペインの［CRM Config］を選択して［デフォルト］をクリックすると、す
べてのオプションを、いつでもデフォルト値に戻すことができます。
6.3 クラスタリソースの設定
クラスタの管理者は、クラスタ内のサーバ上の各リソースや、サーバ上で実
行する各アプリケーションに対してクラスタリソースを作成する必要があり
ます。クラスタリソースには、Webサイト、電子メールサーバ、データベー
ス、ファイルシステム、仮想マシン、およびユーザが常時使用できるように
する他のサーバベースのアプリケーションまたはサービスなどが含まれます。
作成できるリソースタイプの概要については、4.2.3項「リソースのタイ
プ」 (65 ページ)を参照してください。
6.3.1 単純なクラスタリソースの作成
最も基本的なタイプのリソースを作成するには、次の手順に従います。
手順 6.2 プリミティブリソースを追加する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左側のペインで、［リソース］を選択し、［追加］ > ［プリミティブ］の
順にクリックします。
3 次のダイアログで、リソースに次のようなパラメータを設定します。
3a リソースに固有の［ID］を入力します。
3b ［クラス］リストから、そのリソースに使用するリソースエージェ
ントクラスを選択します。［lsb］、［ocf］、［service］、または
［stonith］を選択できます。詳細については、4.2.2項「サポートさ
158
高可用性ガイド
れるリソースエージェントクラス」 (63 ページ)を参照してくださ
い。
3c ［ocf］をクラスとして選択した場合、OCFリソースエージェントの
［プロバイダ］も指定します。OCFの指定によって、複数のベンダ
が同じリソースエージェントを提供できるようになります。
3d ［タイプ］リストから、使用するリソースエージェントを選択しま
す(たとえば［IPaddr］または［Filesystem］)。このリソースエージェ
ントの簡単な説明を次に表示します。
［タイプ］リストに表示される選択肢は、選択した［クラス］(OCF
リソースの場合は、［プロバイダ］も)によって異なります。
3e ［オプション］の下で、［Initial state of resource (リソースの当初の
状態)］を設定します。
3f リソースのヘルスが維持されているかどうかをクラスタに監視させ
る場合は、［Add monitor operation(モニタ操作の追加)］を有効にし
ます。
クラスタリソースの設定と管理(GUI)
159
4 ［進む］をクリックします。次のウィンドウには、そのリソースに定義し
たパラメータのサマリが表示されます。そのリソースに必要なすべての
［Instance Attributes (インスタンス属性)］が一覧が表示されます。適切な値
に設定するには、編集する必要があります。展開や設定によっては、属性
の追加が必要な場合もあります。詳細については手順6.3「メタ属性および
インスタンス属性を追加または変更する」 (160 ページ)を参照してくださ
い。
5 すべてのパラメータが希望どおりに設定されたら、［適用］をクリックし
て、そのリソースの設定を完了します。環境設定ダイアログが閉じて、メ
インウィンドウに新しく追加されたリソースが表示されます。
リソースの作成中と作成後は、次のパラメータをリソースに追加したり、変
更できます。
• Instance attributes - リソースが制御するサービスのインスタンスを
決定します。詳細については、4.2.7項「インスタンス属性(パラメー
タ)」 (73 ページ)を参照してください。
• Meta attributes - 特定のリソースの処理方法をCRMに指示します。詳
細については、4.2.6項「リソースオプション(メタ属性)」 (70 ページ)を参
照してください。
• Operations - リソース監視に必要です。詳細については、4.2.8項「リソー
ス操作」 (76 ページ)を参照してください。
手順 6.3 メタ属性およびインスタンス属性を追加または変更する
1 Pacemaker GUIのメインウィンドウの左側のペインで、［リソース］をク
リックして、そのクラスタに設定されているリソースを表示します。
2 右側のペインで、変更するリソースを選択し、［編集］をクリックします
(またはリソースをダブルクリックします)。次のウィンドウには、そのリ
ソースに定義された基本的なリソースパラメータと［メタ属性］、［イン
スタンス属性］、または［操作］が表示されます。
160
高可用性ガイド
3 新しいメタ属性またはインスタンス属性を追加するには、該当するタブを
選択して［追加］をクリックします。
4 追加する属性の［名前］を選択します。短い［説明］が表示されます。
5 必要に応じて、属性の［値］を指定します。指定しなければ、その属性の
デフォルト値が使用されます。
6 ［OK］をクリックして変更を確認します。新しく追加または変更された属
性がタブに表示されます。
7 すべてのパラメータが希望どおりに設定されたら、［OK］をクリックし
て、そのリソースの設定を完了します。環境設定ダイアログが閉じ、メイ
ンウィンドウに変更済みのリソースが表示されます。
ヒント: XMLソースコード- リソース用
Pacemaker GUIでは、定義したパラメータから生成されるXMLフラグメント
を表示できます。個々のリソースについては、リソース設定ダイアログの
右上隅で、［表示］ > ［XMLモード］の順に選択します。
設定したすべてのリソースのXML表現にアクセスするには、左ペインで［リ
ソース］をクリックし、次に、メインウィンドウの右上隅で、［表示］ >
［XMLモード］の順に選択します。
XMLコードを表示しているエディタで、XML要素を［インポート］または
［エクスポート］、あるいは手動でXMLコードを編集することができます。
クラスタリソースの設定と管理(GUI)
161
6.3.2 STONITHリソースの作成
重要: STONITHがない場合はサポートなし
STONITHを実行していないクラスタはサポートされません。
デフォルトでは、グローバルクラスタオプションstonith-enabledはtrue
に設定されています。STONITHリソースが定義されていない場合、クラスタ
はどのリソースの開始も拒否します。STONITHのセットアップを完了するに
は、1つ以上のSTONITHリソースを構成する必要があります。STONITHは他
のリソースと同様に設定しますが、その動作はいくつかの点で異なっていま
す。詳細については、9.3項「STONITHのリソースと環境設定」 (230 ページ)
を参照してください。
手順 6.4 STONITHリソースの追加
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左側のペインで、［リソース］を選択し、［追加］ > ［プリミティブ］の
順にクリックします。
3 次のダイアログで、リソースに次のようなパラメータを設定します。
3a リソースに固有の［ID］を入力します。
3b ［クラス］リストで、リソースエージェントクラスとして［stonith］
を選択します。
3c ［タイプ］リストから、使用しているSTONITHデバイスのSTONITH
プラグインを選択します。このプラグインの簡単な説明が下に表示
されます。
3d ［オプション］の下で、［Initial state of resource (リソースの当初の
状態)］を設定します。
3e クラスタにフェンシングデバイスの監視を行わせたい場合は、［Add
monitor operation (監視操の追加)］を起動します。詳細については、
9.4項「フェンシングデバイスの監視」 (234 ページ)を参照してくだ
さい。
162
高可用性ガイド
4 ［進む］をクリックします。次のウィンドウには、そのリソースに定義し
たパラメータのサマリが表示されます。選択したSTONITHプラグインに必
要なすべての［インスタンス属性］が一覧に表示されます。適切な値に設
定するには、編集する必要があります。展開と設定によっては、監視操作
のための属性を追加しなければならない場合もあります。詳細については、
手順6.3「メタ属性およびインスタンス属性を追加または変更す
る」 (160 ページ)および6.3.8項「リソース監視の設定」 (175 ページ)を参照
してください。
5 すべてのパラメータが希望どおりに設定されたら、［適用］をクリックし
て、そのリソースの設定を完了します。環境設定ダイアログが閉じて、メ
インウィンドウに新しく追加されたリソースが表示されます。
フェンシングを設定するには、制約の追加とクローンの使用のいずれか、ま
たはその両方を行います。詳細については、第9章フェンシングと
STONITH (227 ページ)を参照してください。
6.3.3 リソーステンプレートの使用
類似した設定のリソースを複数作成する最も簡単な方法は、リソーステンプ
レートを定義することです。リソーステンプレートを定義しておくと、プリ
ミティブの中や、特定のタイプの制約で参照できるようになります。リソー
ステンプレートの機能と使用方法の詳細については、4.4.3項「リソーステン
プレートと制約」 (84 ページ)を参照してください。
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左側のペインで、［リソース］を選択し、［追加］ > ［テンプレート］の
順にクリックします。
3 テンプレートに固有の［ID］を入力します。
4 プリミティブを指定するリソーステンプレートを指定します。手順 6.2: プ
リミティブリソースを追加するに従って、ステップ 3b (158 ページ)を開始し
ます。
5 すべてのパラメータが希望どおりに設定されたら、［適用］をクリックし
てリソーステンプレートの設定を完了します環境設定ダイアログが閉じて、
クラスタリソースの設定と管理(GUI)
163
メインウィンドウに新しく追加されたリソーステンプレートが表示されま
す。
手順 6.5 リソーステンプレートの参照
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 新しく作成したリソーステンプレートをプリミティブで参照するには、次
の手順に従います。
2a 左側のペインで、［リソース］を選択し、［追加］ > ［プリミティ
ブ］の順にクリックします。
2b 固有の［ID］を入力して、［クラス］、［プロバイダ］、および［タ
イプ］を指定します。
2c 参照する［テンプレート］を選択します。
2d テンプレートのものとは異なる特定のインスタンス属性、操作また
はメタ属性を設定する場合には、手順6.2「プリミティブリソースを
追加する」 (158 ページ)で説明した方法で、リソースの設定を継続し
ます。
3 新しく作成したリソーステンプレートをコロケーションまたは順序の制約
で参照するには
3a 制約を手順6.7「コロケーション制約を追加または変更す
る」 (166 ページ)または手順6.8「順序の制約を追加または変更す
る」 (167 ページ)でそれぞれ説明した方法で設定します。
3b コロケーション制約の場合には、［リソース］ドロップダウンリス
トに、設定されたすべてのリソースとリソーステンプレートのIDが
表示されます。参照するテンプレートを選択します。
3c 同様に、順序の制約の場合には、［最初］および［次］ドロップダ
ウンリストに、リソースとリソーステンプレートの両方が表示され
ます。参照するテンプレートを選択します。
164
高可用性ガイド
6.3.4 リソース制約の設定
すべてのリソースを設定する以外にも、多くの作業が必要です。クラスタが
必要なすべてのリソースを認識しても、正しく処理できるとは限りません。
リソースの制約を指定して、リソースを実行可能なクラスタノード、リソー
スのロード順序、特定のリソースが依存している他のリソースを指定するこ
とができます。
使用可能な制約タイプの概要については、4.4.1項「制約のタイプ」 (81 ページ)
を参照してください。制約を定義する際には、スコアも指定する必要があり
ます。スコアとそのクラスタにおける意味の詳細については、4.4.2項「スコ
アと無限大」 (84 ページ)を参照してください。
さまざまな制約タイプの作成方法については、次の手順を参照してください。
手順 6.6 場所の制約を追加または変更する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 Pacemaker GUIのメインウィンドウの左側のペインで、［制約］をクリッ
クして、そのクラスタに設定されている制約を表示します。
3 左側のペインで［制約］を選択し、［追加］をクリックします。
4 ［Resource Location (リソース位置)］を選択し、［OK］をクリックしま
す。
5 制約に固有の［ID］を入力します。既存の制約を変更する場合、IDはす
でに定義されているため、環境設定ダイアログに表示されます。
6 制約を設定する［リソース］を選択します。リストには、そのクラスタ
に設定されているすべてのリソースのIDが表示されます。
7 制約の［Score (スコア)］を設定します。正の値は、下で指定した［ノー
ド］でリソースを実行できることを示します。負の値は、リソースをこ
のノードで実行すべきではないことを示します。スコアをINFINITYに
設定すれば、リソースはこのノードで実行されるように強制されます。
-INFINITYに設定すれば、リソースはそのノードで実行してはならない
ことになります。
クラスタリソースの設定と管理(GUI)
165
8 制約を設定する［ノード］を選択します。
9 ［ノード］および［Score (スコア)］フィールドを空のままにしておく
と、［追加］ > ［ルール］の順にクリックしてルールを追加することも
できます。有効期間を追加するには、［追加］ > ［有効期間］の順にク
リックします。
10 すべてのパラメータが希望どおり設定されたら、［OK］をクリックし
て、制約の設定を完了します。環境設定ダイアログが閉じて、メイン
ウィンドウに新しく追加または変更された制約が表示されます。
手順 6.7 コロケーション制約を追加または変更する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 Pacemaker GUIのメインウィンドウの左側のペインで、［制約］をクリッ
クして、そのクラスタに設定されている制約を表示します。
3 左側のペインで［制約］を選択し、［追加］をクリックします。
4 ［Resource Colocation (リソースのコロケーション)］を選択し、［OK］
をクリックします。
5 制約に固有の［ID］を入力します。既存の制約を変更する場合、IDはす
でに定義されているため、環境設定ダイアログに表示されます。
6 コロケーションソースとなる［リソース］を選択します。リストには、
そのクラスタに設定されているすべてのリソースとリソーステンプレー
トのIDが表示されます。
166
高可用性ガイド
制約が満たされないと、クラスタはリソースがまったく実行しないよう
にすることがあります。
7 ［リソース］と［With Resource (対象リソース)］フィールドを両方とも
空のままにしておくと、［追加］ > ［リソースセット］の順にクリック
してリソースを追加することもできます。有効期間を追加するには、
［追加］ > ［有効期間］の順にクリックします。
8 ［With Resource (対象リソース)］には、コロケーション先を定義します。
クラスタはこのリソースの配置先を最初に決定し、次に［リソース］
フィールドのリソースを配置する場所を決定します。
9 ［Score (スコア)］を定義して、両方のリソース間の位置関係を決定しま
す。正の値は、リソースを同じノードで実行するべきであることを示し
ます。負の値は、リソースを同じノードで実行するべきではないことを
示します。スコアをINFINITYに設定すれば、リソースは同じノードで
実行されるように強制されます。-INFINITYに設定すれば、リソースは
同じノードで実行してはならないことになります。スコアと他の要因と
の組み合わせによって、ノードの配置先が決定します。
10 必要に応じて、［Resource Role (リソース役割)］などの追加のパラメー
タも指定します。
選択したパラメータとオプションに応じて、短い［説明］が表示され、
設定しているコロケーション制約の効果を確認できます。
11 すべてのパラメータが希望どおり設定されたら、［OK］をクリックし
て、制約の設定を完了します。環境設定ダイアログが閉じて、メイン
ウィンドウに新しく追加または変更された制約が表示されます。
手順 6.8 順序の制約を追加または変更する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 Pacemaker GUIのメインウィンドウの左側のペインで、［制約］をクリック
して、そのクラスタに設定されている制約を表示します。
3 左側のペインで［制約］を選択し、［追加］をクリックします。
4 ［Resource Order (リソース順序)］を選択し、［OK］をクリックします。
クラスタリソースの設定と管理(GUI)
167
5 制約に固有の［ID］を入力します。既存の制約を変更する場合、IDはすで
に定義されているため、環境設定ダイアログに表示されます。
6 ［最初］では、［次］で指定するリソースの開始前に開始するリソースを
定義します。
7 ［次］では、［最初］のリソースより後に開始するリソースを定義します。
選択したパラメータとオプションに応じて、短い［説明］が表示され、設
定している順序の制約の効果を確認できます。
8 必要な場合は、さらにパラメータを定義します。たとえば、次のように定
義します。
8a ［スコア］でスコアを指定します。制約は、ゼロより大きい場合は
必須になりますが、そうでない場合はアドバイスにすぎません。デ
フォルト値は、INFINITYです。
8b ［シンメトリック］の値を指定します。trueを指定した場合は、リ
ソースが逆の順序で停止されます。デフォルト値は、trueです。
9 すべてのパラメータが希望どおり設定されたら、［OK］をクリックして、
制約の設定を完了します。環境設定ダイアログが閉じて、メインウィンド
ウに新しく追加または変更された制約が表示されます。
Pacemaker GUIの［制約］ビューで設定したすべての制約にアクセスして変更
することができます。
168
高可用性ガイド
図 6.3 Pacemaker GUI - 制約
6.3.5 リソースフェールオーバーノードの指
定
リソースに障害が発生すると、自動的に再起動されます。現在のノードで再
起動できない場合、または現在のノードでN回失敗した場合は、別のノードへ
のフェールオーバーが試行されます。新しいノードへのマイグレートを行う
基準(migration-threshold)となるリソースの失敗数を定義できます。ク
ラスタ内に3つ以上ノードがある場合、特定のリソースのフェールオーバー先
のノードはHigh Availabilityソフトウェアが選択します。
ただし、次の手順を実行すると、リソースのフェールオーバー先のノードを
指定できます。
1 手順6.6「場所の制約を追加または変更する」 (165 ページ)に記載の手順に
従って、そのリソースの場所の制約を設定します。
2 手順6.3「メタ属性およびインスタンス属性を追加または変更す
る」 (160 ページ)に記載の手順に従って、migration-thresholdメタ属
性をそのリソースに追加し、マイグレーションしきい値の［値］を入力し
ます。INFINITY未満の正の値を指定する必要があります。
クラスタリソースの設定と管理(GUI)
169
3 リソースの失敗回数を自動的に失効させる場合は、手順6.3「メタ属性およ
びインスタンス属性を追加または変更する」 (160 ページ)に記載の手順に
従ってfailure-timeoutメタ属性をそのリソースに追加し、失敗タイム
アウトの［値］を入力します。
4 リソースの初期設定として、追加のフェールオーバーノードを指定する場
合は、追加の場所の制約を作成します。
移行しきい値と失敗回数に関するクラスタ内のプロセスフローの例について
は、例4.6「マイグレーションしきい値 - プロセスフロー」 (85 ページ)を参照
してください。
リソースの失敗回数は、自動的に期限切れにする代わりに、いつでも、手動
でクリーンアップすることもできます。詳細については、6.4.2項「リソース
のクリーンアップ」 (183 ページ)を参照してください。
6.3.6 リソースフェールバックノードの指定
(リソースの固着性)
ノードがオンライン状態に戻り、クラスタ内にある場合は、リソースが元の
ノードにフェールバックすることがあります。フェールオーバー前にリソー
スを実行していたノードにリソースをフェールバックさせたくない場合や、
リソースのフェールバック先として別のノードを指定する場合は、リソース
の固着性の値を変更する必要があります。リソースの固着性は、リソースの
作成時でも、その後でも指定できます。
さまざまなリソース固着性値の意味については、4.4.5項「フェールバックノー
ド」 (86 ページ)を参照してください。
170
高可用性ガイド
手順 6.9 リソースの固着性を指定する
1 手順6.3「メタ属性およびインスタンス属性を追加または変更す
る」 (160 ページ)に従って、resource-stickinessメタ属性をリソース
に追加します。
2 resource-stickinessの［値］として、-INFINITYからINFINITYの範囲の値
を指定します。
6.3.7 負荷インパクトに基づくリソース配置
の設定
すべてのリソースが同等ではありません。Xenゲストなどの一部のリソースで
は、そのホストであるノードがリソースの容量要件を満たす必要があります。
リソースの組み合わされたニーズが提供された容量より大きくなるようにリ
ソースが配置されると、リソースのパフォーマンスが低下します(あるいは失
敗することさえあります)。
これを考慮に入れて、High Availability Extensionでは、次のパラメータを指定
できます。
1. 一定のノードが提供する容量
2. 一定のリソースが要求する容量
3. リソースの配置に関する全体的なストラテジ
クラスタリソースの設定と管理(GUI)
171
使用属性は、リソースの要件と、ノードが提供する容量の両方を設定するた
めに使用されます。High Availability Extensionには、ノードの容量とリソース
の要件を自動的に検出し、設定する手段も用意されています。詳細と設定例
については、4.4.6項「負荷インパクトに基づくリソースの配置」 (87 ページ)
を参照してください。
リソースの要件とノードが提供する容量を手動で設定するには、手順6.10「使
用属性を追加または変更する」 (172 ページ)の手順に従ってください。使用属
性に任意の名前を付け、設定に必要なだけ名前/値のペアを定義します。
手順 6.10 使用属性を追加または変更する
次の例では、クラスタのノードとリソースの基本設定がすでに完了している
ところへ、さらに、一定のノードが提供する容量と一定のリソースが必要と
する容量の設定を行う場合を想定しています。使用属性の追加手順は、基本
的に同じであり、異なるのはステップ 2 (172 ページ)とステップ 3 (172 ページ)
だけです。
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 ノードが提供する容量を指定するには、次の手順に従います。
2a 左ペインで、［ノード］をクリックします。
2b 右ペインで、容量を設定するノードを選択し、［編集］をクリック
します。
3 リソースが要求する容量を指定するには、次の手順に従います。
3a 左ペインで、［リソース］をクリックします。
3b 右ペインで、容量を設定するリソースを選択して、［編集］をクリッ
クします。
4 ［使用］タブを選択し、［追加］をクリックして使用属性を追加します。
5 新しい属性の［名前］を入力します。使用属性には、好きな名前を付ける
ことができます。
172
高可用性ガイド
6 属性の［値］を入力し、［OK］をクリックします。属性値は整数にする必
要があります。
7 使用属性をさらに追加する場合は、ステップ 5 (172 ページ)からステップ
6 (173 ページ)まで繰り返します。
［使用］タブに、そのノードまたはリソースに定義した使用属性の要約が
表示されます。
8 すべてのパラメータが望みどおりに設定されたら、［OK］をクリックし
て、設定ダイアログを閉じます。
図6.4「ノード容量の設定例」 (173 ページ)は、8つのCPUユニットと16GBのメ
モリを、そのノードで実行中のリソースに提供するノードの設定を示してい
ます。
図 6.4 ノード容量の設定例
たとえば、ノードの4096メモリ単位と4つのCPUユニットを必要とするリソー
スの設定例は、次のようになります。
クラスタリソースの設定と管理(GUI)
173
図 6.5 リソース容量の設定例
ノードが提供する容量とリソースが要求する容量を(手動または自動で)設定し
た後、グローバルクラスタオプションで配置ストラテジを設定する必要があ
ります。これを設定しないと、容量の設定は有効になりません。負荷のスケ
ジュールに使用できるストラテジがいくつかあります。たとえば、負荷をで
きるだけ少ない数のノードに集中したり、使用可能なすべてのノードに均等
に分散できます。詳細については、4.4.6項「負荷インパクトに基づくリソー
スの配置」 (87 ページ)を参照してください。
手順 6.11 配置ストラテジを設定する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 ［表示］ > ［簡易モード］の順に選択します。
3 左ペインで、［CRM Config］を選択して、グローバルクラスタオプション
とそれらの現在の値を表示します。
4 要件に応じて、［配置ストラテジ］を適切な値に設定します。
5 何らかの理由でフェンシングを無効にする必要がある場合は、Stonith
Enabledの選択を解除します。
6 ［適用］をクリックして、変更を確認します。
174
高可用性ガイド
6.3.8 リソース監視の設定
High Availability Extensionはノード障害を検出できますが、ノード上の個々の
リソースで障害が発生した場合にも検出することができます。リソースが実
行中であるかどうか確認するには、そのリソースにリソースの監視を設定し
ておく必要があります。リソース監視は、タイムアウト、開始遅延のいずれ
か、または両方と、間隔を指定することで設定できます。間隔の指定によっ
て、CRMにリソースステータスの確認頻度を指示します。startまたはstop
操作に対するTimeoutなど、特定のパラメータも設定できます。
手順 6.12 監視操作を追加または変更する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 Pacemaker GUIのメインウィンドウの左側のペインで、［リソース］をク
リックして、そのクラスタに設定されているリソースを表示します。
3 右側のペインで、変更するリソースを選択して［編集］をクリックします。
次のウィンドウには、そのリソースに定義された基本的なリソースパラメー
タとメタ属性、インスタンス属性、および操作が表示されます。
4 新しい監視操作を追加するには、該当するタブを選択して［追加］をクリッ
クします。
既存の操作を変更するには、該当するエントリを選択して［編集］をクリッ
クします。
5 ［名前］で、monitor、start、［stop］など、実行するアクションを選
択します。
次に示すパラメータは、ここでの選択によって決まります。
クラスタリソースの設定と管理(GUI)
175
6 ［タイムアウト］フィールドに、値を秒単位で入力します。指定したタイ
ムアウトを過ぎると、操作はfailedと見なされます。PEは何を行うか、
あるいは監視操作の［On Fail (障害発生時の動作)］フィールドで指定した
内容を実行するかどうかを判断します。
7 必要な場合は、［オプション］セクションを開いて、［失敗の場合］(この
アクションが失敗した場合の処理)または［必要］(このアクションを発生
する前に満たす必要がある条件)などのパラメータを追加します。
8 すべてのパラメータが希望どおりに設定されたら、［OK］をクリックし
て、そのリソースの設定を完了します。設定ダイアログが閉じて、メイン
ウィンドウに変更されたリソースが表示されます。
リソースモニタが障害を検出した場合の処理については、4.3項「リソース監
視」 (79 ページ)を参照してください。
Pacemaker GUIでリソースの障害を表示するには、左ペインの［管理］をク
リックしてから、右ペインで、詳細を表示したいリソースを選択します。障
害が発生したリソースの場合、［失敗回数］とリソースの最後の障害が右ペ
インの中ほど(［移行しきい値］エントリの下)に表示されます。
図 6.6 リソースの失敗回数の表示
176
高可用性ガイド
6.3.9 クラスタリソースグループの構成
クラスタリソースの中には、他のコンポーネントやリソースに依存しており、
各コンポーネントや各リソースを特定の順序で開始したり、同じサーバ上で
一緒に実行しなければならないものもあります。この構成を簡単にするため、
グループのコンセプトをサポートしています。
リソースグループの例と、グループとそのプロパティの詳細について、4.2.5.1
項「グループ」 (66 ページ)を参照してください。
注記: 空のグループ
グループには1つ以上のリソースを含む必要があります。空の場合は設定は
無効になります。
手順 6.13 リソースグループを追加する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左側のペインで［リソース］を選択し、［追加］ > ［グループ］の順にク
リックします。
3 グループに固有の［ID］を入力します。
4 ［オプション］の下で、［Initial state of resource (リソースの当初の状態)］
を設定し、［転送］をクリックします。
5 次のステップでは、グループのサブリソースとしてプリミティブを追加で
きます。プリミティブは手順6.2「プリミティブリソースを追加す
る」 (158 ページ)と類似の方法で作成します。
6 すべてのパラメータが希望どおりに設定されたら、［適用］をクリックし
て、プリミティブの設定を完了します。
7 次のウィンドウでは、再度［プリミティブ］を選択し、［OK］をクリック
することで、グループのサブリソースの追加を継続できます。
グループに追加するプリミティブがなくなったら、代わりに［キャンセル］
をクリックします。次のウィンドウには、そのグループに定義したパラメー
タの概要が表示されます。グループの［メタ属性］および［プリミティブ］
クラスタリソースの設定と管理(GUI)
177
の一覧が表示されます。［プリミティブ］タブのリソースの場所は、クラ
スタ内でのリソース開始順序を示します。
8 グループ内のリソースの順序は重要なので、［上へ］ボタンと［下へ］ボ
タンを使用して、グループ内で［プリミティブ］をソートします。
9 すべてのパラメータが希望どおりに設定されたら、［OK］をクリックし
て、そのグループの設定を完了します。環境設定ダイアログが閉じ、メイ
ンウィンドウに新しく作成された、または変更されたグループが表示され
ます。
図 6.7 Pacemaker GUI - グループ
手順6.13「リソースグループを追加する」 (177 ページ)の説明どおりにリソー
スグループを作成済みであると仮定します。次の手順では、例4.1「Webサー
バのリソースグループ」 (66 ページ)と一致するようにグループを変更する方
法を示します。
178
高可用性ガイド
手順 6.14 既存のグループにリソースを追加する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左側のペインで［リソース］ビューに切り替え、右側のペインで、変更す
るグループを選択して［編集］をクリックします。次のウィンドウには、
そのリソースに定義された基本的なグループパラメータとメタ属性とプリ
ミティブが表示されます。
3 ［プリミティブ］タブをクリックして、［追加］をクリックします。
4 次のダイアログで、次のパラメータを設定してIPアドレスをグループのサ
ブリソースとして追加します。
4a 一意の［ID］を入力します(たとえば、my_ipaddress)。
4b ［クラス］リストで、リソースエージェントクラスとして［ocf］を
選択します。
4c OCFリソースエージェントの［プロバイダ］として、［heartbeat］を
選択します。
4d ［タイプ］リストで、リソースエージェントとして［IPaddr］を選
択します。
4e ［進む］をクリックします。
4f ［Instance Attribute (インスタンス属性)］タブで、［IP］エントリを
選択して［編集］をクリックします(または［IP］エントリをダブル
クリックします)。
4g ［値］として、目的のIPアドレスを入力します。たとえば
「192.168.1.180」と入力します。
4h ［OK］、［適用］の順にクリックします。グループ設定ダイアログ
には、新しく追加去れたプリミティブが表示されます。
5 再度［追加］をクリックして、次のサブリソース(ファイルシステムとWeb
サーバ)を追加します。
クラスタリソースの設定と管理(GUI)
179
6 「ステップ 4a (179 ページ)」から「ステップ 4h (179 ページ)」のような手順
に従って、グループの全サブリソースの設定を終了するまで、各サブリソー
スの該当するパラメータを設定します。
クラスタ内で開始する順序でサブリソースを設定したので、［プリミティ
ブ］タブ内の順序はすでに正しいものになっています。
7 グループのリソースの順序を変更する必要がある場合は、［上へ］ボタン
と［下へ］ボタンを使用して、［プリミティブ］タブのリソースをソート
します。
8 グループからリソースを削除するには、［プリミティブ］タブのリソース
を選択し、［削除］をクリックします。
9 ［OK］をクリックしてそのグループの設定を完了します。環境設定ダイア
ログが閉じて、メインウィンドウに変更されたグループが表示されます。
6.3.10 クローンリソースの設定
クラスタ内の複数のノードで特定のリソースを同時に実行することができま
す。このためには、リソースをクローンとして設定する必要があります。ク
ローンとして設定するリソースの1例として、STONITHや、OCFS2などのクラ
スタファイルシステムが挙げられます。提供されているどのリソースも、ク
ローンとして設定できます。これは、リソースのリソースエージェントによっ
180
高可用性ガイド
てサポートされます。クローンリソースは、ホスティングされているノード
によって異なる設定をすることもできます。
使用できるリソースクローンのタイプの概要については、4.2.5.2項「クロー
ン」 (68 ページ)を参照してください。
手順 6.15 クローンを追加または変更する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左側のペインで［リソース］を選択し、［追加］ > ［クローン］の順にク
リックします。
3 クローンに固有の［ID］を入力します。
4 ［オプション］の下で、［Initial state of resource (リソースの当初の状態)］
を設定します。
5 クローンに設定するオプションを起動し、［転送］をクリックします。
6 次のステップでは、［プリミティブ］または［グループ］をクローンのサ
ブリソースとして追加することができます。手順6.2「プリミティブリソー
スを追加する」 (158 ページ)または手順6.13「リソースグループを追加す
る」 (177 ページ)で説明している方法のように作成します。
7 クローン設定ダイアログ内のすべてのパラメータが希望どおりに設定され
たら、［適用］をクリックして、クローンの設定を完了します。
6.4 クラスタリソースの管理
Pacemaker GUIでは、クラスタリソースの設定が可能なだけでなく、既存リ
ソースを管理することもできます。管理ビューに切り替え、使用可能なオプ
ションにアクセスするには、左ペインで［管理］をクリックします。
クラスタリソースの設定と管理(GUI)
181
図 6.8 Pacemaker GUI - 管理
6.4.1 リソースの開始
クラスタリソースは、起動する前に、正しく設定されているようにします。
たとえば、Apacheサーバをクラスタリソースとして使用する場合は、まず、
Apacheサーバをセットアップし、Apacheの環境設定を完了してから、クラス
タで個々のリソースを起動します。
注記: クラスタによって管理されるサービスには介入しないでください。
High Availability Extensionでリソースを管理しているときに、同じリソース
を他の方法(クラスタ外で、たとえば、手動、ブート、再起動など)で開始し
たり、停止してはなりません。High Availability Extensionソフトウェアが、
すべてのサービスの開始または停止アクションを実行します。
ただし、サービスが適切に構成されているか確認したい場合は手動で開始
しますが、High Availabilityが起動する前に停止してください。
現在クラスタで管理されているリソースへの介入については、まず、6.4.5
項「リソースの管理モードの変更」 (186 ページ)に説明されているように、
リソースをunmanaged modeに設定します。
182
高可用性ガイド
Pacemaker GUIによるリソースの作成時に、リソースの初期状態を
target-roleメタ属性で設定できます。その値をstoppedに設定した場合、
リソースは、その作成後に自動的に起動しません。
手順 6.16 新しいリソースを起動する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左ペインで、［管理］をクリックします。
3 右ペインで、リソースを右クリックして、コンテキストメニューから［開
始］を選択します(または、ツールバーの［リソースの開始］アイコンを使
用します)。
6.4.2 リソースのクリーンアップ
リソースは、失敗した場合は自動的に再起動しますが、失敗のたびにリソー
スの失敗回数が増加します。リソースの失敗回数をPacemaker GUIで表示する
には、左ペインで［管理］をクリックしてから、右ペインでリソースを選択
します。リソースが失敗している場合は、その［失敗回数］が右ペインの中
ほど(［移行しきい値］エントリの下)に表示されます。
migration-thresholdがそのリソースに設定されている場合は、失敗の数
が移行しきい値に達するとただちに、そのリソースはノードで実行できなく
なります。
リソースの失敗回数は、(リソースにfailure-timeoutオプションを設定す
ることにより)自動的にリセットするか、または次に示すように手動でリセッ
トできます。
手順 6.17 リソースをクリーンアップする
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左ペインで、［管理］をクリックします。
クラスタリソースの設定と管理(GUI)
183
3 右ペインで、該当するリソースを右クリックし、コンテキストメニューか
ら［リソースのクリーンアップ］を選択します(またはツールバーの［リ
ソースのクリーンアップ］アイコンを使用します)。
これによって指定したノード上の指定したリソースに対して、コマンド
crm_resource -Cおよびcrm_failcount -Dが実行されます。
詳細は、crm_resourceおよびcrm_failcountのマニュアルページを参照
してください。
6.4.3 クラスタリソースの削除
リソースをクラスタから削除する必要がある場合は、次の手順に従って、設
定エラーが発生しないようにします。
注記: 参照されているリソースの削除
何らかの制約によってIDが参照されているクラスタリソースは削除できま
せん。リソースを削除できない場合は、リソースIDが参照されている場所
を確認し、最初に制約からリソースを削除します。
手順 6.18 クラスタリソースの削除
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左ペインで、［管理］をクリックします。
3 右ペインで、該当するリソースを選択します。
4 手順6.17「リソースをクリーンアップする」 (183 ページ)の説明に従って、
すべてのノードでリソースをクリーンアップします。
5 ［停止］でリソースを停止します。
6 リソースに関するすべての制約を削除します。これを行わないと、リソー
スは削除できません。
184
高可用性ガイド
6.4.4 クラスタリソースの移行
6.3.5項「リソースフェールオーバーノードの指定」 (169 ページ)で説明したよ
うに、ソフトウェアまたはハードウェアの障害時には、クラスタは定義可能
な特定のパラメータ(たとえばマイグレーションしきい値やリソースの固着性
など)に従って、リソースを自動的にフェールオーバー(マイグレート)させま
す。それ以外に、クラスタ内の別なノードにリソースを手動でマイグレート
させることもできます。
手順 6.19 リソースを手動で移行する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左ペインで、［管理］をクリックします。
3 右ペインで、該当するリソースを右クリックし、［リソースの移行］を選
択します。
4 新規ウィンドウで、［To Node (マイグレート先ノード)］で、リソースの移
動先ノードを選択します。これによって移動先ノードに対してINFINITY
スコアの場所の制約が作成されます。
5 リソースを一時的にマイグレートするには、［Duration (期間)］をアクティ
ブにしてリソースが新規ノードにマイグレートされる時間を入力します。
クラスタリソースの設定と管理(GUI)
185
指定した時間を経過したら、リソースは元の場所に戻ることができます。
あるいは、現在の場所に残ることもできます(リソースへの固着性による)。
6 リソースをマイグレートできない場合は(リソースの固着性と制約スコアの
合計が現在のノードでINFINITYを超えている場合)、［強制］オプション
を有効にします。これによって現在の場所に対するルールと-INFINITYの
スコアを作成して、リソースを強制的に移動させます。
注記
これにより、［移行制約のクリア］で制約を解除するか、期限切れにな
るまで、このノードでリソースが実行されなくなります。
7 ［OK］をクリックして、マイグレーションを確認します。
リソースを再び元に戻すには、次の手順に従います。
手順 6.20 移行制約をクリアする
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左ペインで、［管理］をクリックします。
3 右ペインで、該当するリソースを右クリックし、［移行制約のクリア］を
選択します。
これによって、crm_resource -Uコマンドが使用されます。リソースは
元の場所に戻ることができます。あるいは現在の場所に残ることもありま
す(リソースの固着性によって)。
詳細は、crm_resourceのマニュアルページ、またはPacemaker Explainedを
参照してください。http://www.clusterlabs.org/doc/から入手できま
す。特に、「Resource Migration」のセクションを参照してください。
6.4.5 リソースの管理モードの変更
リソースがクラスタで管理されているときは、他の方法で(つまり、クラスタ
外で)リソースを操作しないでください。個々のリソースの保守する場合は、
186
高可用性ガイド
各リソースをunmanaged modeに設定すると、クラスタ外でそのリソースを
変更できます。
手順 6.21 リソースの管理モードの変更
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左ペインで、［管理］をクリックします。
3 右ペインで、該当するリソースを右クリックし、コンテキストメニューか
ら、［リソースの管理解除］を選択します。
4 そのリソースの保守作業を完了したら、右ペインで、再び該当するリソー
スを右クリックして、［リソースの管理］を選択します。
リソースは、この時点から再びHigh Availability Extensionソフトウェアに
よって管理されます。
クラスタリソースの設定と管理(GUI)
187
クラスタリソースの設定と管理
(コマンドライン)
7
クラスタリソースを設定および管理するには、グラフィカルユーザインタ
フェース(Pacemaker GUI)またはcrmコマンドラインユーティリティのいずれ
かを使用します。GUIを使用する方法については、第6章クラスタリソースの
設定と管理(GUI) (153 ページ)を参照してください。
この章では、crmコマンドラインツールを紹介し、このツールの概要、テン
プレートの使用方法、そして、主にクラスタリソースの設定と管理(基本的な
リソースと高度なリソース(グループとクローン)の作成、制約の設定、フェー
ルオーバーノードとフェールバックノードの指定、リソース監視の設定、リ
ソースの開始、クリーンアップ、または削除、および手動によるリソースの
移行について説明します。
注記: ユーザの権限
クラスタを管理するには十分な権限が必要です。crmコマンドおよびそのサ
ブコマンドは、rootユーザとして、またはCRM所有者ユーザとして実行さ
れる必要があります(通常はhaclusterユーザ)。
ただし、userオプションを使用することで、crmとそのサブコマンドを一
般(権限のない)ユーザとして実行し、必要な場合はいつでもsudoを使用し
てIDを変更できます。たとえば、次のcrmコマンドは、権限のあるユーザ
IDとしてhaclusterを使用します。
root # crm options user hacluster
/etc/sudoersを設定しておいて、sudoがパスワードを要求しないように
しておく必要があることに注意してください。
クラスタリソースの設定と管理(コマンドライン)
189
7.1 crmsh - 概要
crmコマンドには、リソース、CIB、ノード、リソースエージェントなどを管
理するサブコマンドがあります。このコマンドには、例を組み込んだ詳細な
ヘルプシステムが用意されています。すべての例は、付録A (363 ページ)で説
明される命名規則に従います。
ヘルプには複数の方法でアクセスできます。
ヒント: シェルプロンプトと対話型crmプロンプトの違い
すべてのコードと例を読みやすくするために、この章では、シェルプロン
プトと対話型crmプロンプト間で次の表記を使用します。
• ユーザrootのシェルプロンプト:
root #
• 対話型crmshプロンプト(ターミナルがカラーに対応している場合は、緑
色で表示):
crm(live)#
7.1.1 ヘルプの表示
ヘルプには複数の方法でアクセスできます。
• crmとそのコマンドラインオプションの使用方法を出力するには:
root # crm --help
• 使用可能なすべてのコマンドの一覧を表示するには:
root # crm help
190
高可用性ガイド
• コマンドの参照情報だけでなく、他のヘルプセクションにアクセスするに
は:
root # crm help topics
• configureサブコマンドの詳細なヘルプテキストを表示するには:
root # crm configure help
• configureのサブコマンドの構文、使用方法、例を印刷するには:
root # crm configure help group
次の入力も可能です。
root # crm help configure group
helpサブコマンド(--helpオプションと混同しないこと)のほとんどすべての
出力によって、テキストビューアが開きます。このテキストビューアは上下
にスクロール可能で、ヘルプテキストが読みやすくなっています。テキスト
ビューアを閉じるには、Qキーを押します。
ヒント: バッシュおよび対話型シェルでタブ補完機能を使用
crmshは、対話型シェルに対してだけではなく、バッシュでの直接的で完全
なタブ補完機能をサポートしています。たとえば、crm help config<Tab>
と入力すると、対話型シェルと同様に単語が補完されます。
7.1.2 crmshのサブコマンドの実行
crmコマンドそのものは、次のように使用できます。
• 直接すべてのサブコマンドをcrmに続け、<Enter>を押すと、ただちにその
出力が表示されます。たとえば、crm help raを入力すると、raサブコマ
ンド(リソースエージェント)に関する情報を取得できます。
• crmシェルスクリプトとして使用スクリプト内でcrmとそのサブコマンド
を使用します。これには、2つの方法があります。
root # crm -f script.cli
root # crm < script.cli
クラスタリソースの設定と管理(コマンドライン)
191
スクリプトには、crmから任意のコマンドを含めることができます。例:
# A small script file for crm
status
node list
ハッシュ記号(#)で始まる行はコメントなので、無視されます。行が長すぎ
る場合は、行末にバックスラッシュ(\)を挿入し、次の行に続けます。可読
性を向上させるため、特定のサブコマンドに属する行をインデントするこ
とをお勧めします。
• 内部シェルとして対話式に使用「crm」とタイプして、内部シェルに入り
ます。プロンプトがcrm(live)に変化します。helpを使用すると、利用可
能なサブコマンドの概要を取得できます。内部シェルにはさまざまなサブ
コマンドレベルがあり、1つのサブコマンドをタイプしてEnterを押すこと
で、そのサブコマンドのレベルに「入る」ことができます。
たとえば、「resource」とタイプすると、リソース管理レベルに入りま
す。プロンプトはcrm(live)resource#に変わります。内部シェルを終了
したい場合は、コマンドquit、bye、またはexitを使用します。1レベル
戻る場合は、back、up、end、またはcdを使用します。
crm、そしてオプションを付けずにサブコマンドを入力してEnterを押すと、
そのレベルに直接入ることができます。
内部シェルは、サブコマンドとリソースのタブによる完了もサポートしま
す。コマンドの冒頭をタイプして<Tab>を押すと、crmがそのオブジェクト
を完了します。
すでに説明した方法に加えて、crmshは、同期コマンド実行もサポートしてい
ます。これを有効にするには、-wオプションを使用します。crmを-wなしで
起動した場合でも、後ほどユーザ初期設定のwaitをyesに設定すれば(options
wait yes)、有効にすることができます。このオプションが有効化される場
合、crmは遷移が終了するまで待機します。処理が開始すると毎回、進行状
況を示すための点が印刷されます。同期コマンドの実行はresource start
などのコマンドにのみ適用できます。
192
高可用性ガイド
注記: 管理サブコマンドと設定サブコマンド間の相違
crmツールには管理機能(サブコマンドresourcesおよびnode)があり、設
定に使用できます(cib、configure)。
以降のサブセクションでは、crmツールの重要な側面について、その概要を
示します。
7.1.3 OCFリソースエージェントに関する情
報の表示
リソースエージェントはクラスタ設定で常に操作する必要があるため、crm
ツールには、raコマンドが含まれています。このコマンドを使用して、リソー
スエージェントの情報を表示し、リソースエージェントを管理します(詳細は
4.2.2項「サポートされるリソースエージェントクラス」 (63 ページ)も参照)。
root # crm ra
crm(live)ra#
コマンドclassesは、すべてのクラスとプロバイダを一覧表示します。
crm(live)ra# classes
lsb
ocf / heartbeat linbit lvm2 ocfs2 pacemaker
service
stonith
クラス(およびプロバイダ)に使用できるすべてのリソースエージェントの概要
を取得するには、listコマンドを使用します。
crm(live)ra# list ocf
AoEtarget
AudibleAlarm
Delay
Dummy
Filesystem
HealthCPU
IPaddr
IPaddr2
LVM
LinuxSCSI
ManageVE
Pure-FTPd
SAPDatabase
SAPInstance
...
CTDB
EvmsSCC
HealthSMART
IPsrcaddr
MailTo
Raid1
SendArp
ClusterMon
Evmsd
ICP
IPv6addr
ManageRAID
Route
ServeRAID
リソースエージェントの概要は、infoで表示できます。
crm(live)ra# info ocf:linbit:drbd
This resource agent manages a DRBD* resource
クラスタリソースの設定と管理(コマンドライン)
193
as a master/slave resource. DRBD is a shared-nothing replicated storage
device. (ocf:linbit:drbd)
Master/Slave OCF Resource Agent for DRBD
Parameters (* denotes required, [] the default):
drbd_resource* (string): drbd resource name
The name of the drbd resource from the drbd.conf file.
drbdconf (string, [/etc/drbd.conf]): Path to drbd.conf
Full path to the drbd.conf file.
Operations' defaults (advisory minimum):
start
timeout=240
promote
timeout=90
demote
timeout=90
notify
timeout=90
stop
timeout=100
monitor_Slave_0 interval=20 timeout=20 start-delay=1m
monitor_Master_0 interval=10 timeout=20 start-delay=1m
ビューアは、「Q」を押すと終了できます。構成の例は、付録B 単純なテスト
リソースのセットアップ例 (365 ページ)を参照してください。
ヒント: crmの直接使用
前の例では、crmコマンドの内部シェルを使用しました。ただし、必ずし
も、それを使用する必要はありません。該当するサブコマンドをcrmに追加
すれば、同じ結果が得られます。たとえば、すべてのOCFリソースエージェ
ントを一覧するには、シェルに「crm ra list ocf」を入力すれば済みま
す。
7.1.4 設定テンプレートの使用
設定テンプレートは、crmシェル用の既成のクラスタ設定です。リソーステン
プレート(7.3.2項「リソーステンプレートの作成」 (200 ページ)の説明を参照)
と混同しないでください。これらはクラスタ用のテンプレートで、crmシェル
用ではありません。
設定テンプレートは、最小限の操作で、特定ユーザのニーズに合わせて調整
できます。テンプレートで設定を作成する際には、警告メッセージでヒント
194
高可用性ガイド
が与えられます。これは、後から編集することができ、さらにカスタマイズ
できます。
次の手順は、簡単ですが機能的なApache設定を作成する方法を示しています。
1 rootとしてログインし、crm対話型シェルを開始します。
root # crm configure
2 設定テンプレートから新しい設定を作成します。
2a templateサブコマンドに切り替えます。
crm(live)configure#
template
2b 使用可能な設定テンプレートを一覧します。
crm(live)configure template# list templates
gfs2-base
filesystem virtual-ip apache
clvm
ocfs2
gfs2
2c 必要な設定テンプレートを決めます。Apache設定が必要なので、
apacheテンプレートを選択し、g-intranetと名付けます。
crm(live)configure template# new g-intranet apache
INFO: pulling in template apache
INFO: pulling in template virtual-ip
3 パラメータを定義します。
3a 作成した設定を一覧表示します。
crm(live)configure template# list
g-intranet
3b 入力を必要とする最小限の変更項目を表示します。
crm(live)configure template# show
ERROR: 23: required parameter ip not set
ERROR: 61: required parameter id not set
ERROR: 65: required parameter configfile not set
クラスタリソースの設定と管理(コマンドライン)
195
3c 好みのテキストエディタを起動し、ステップ 3b (195 ページ)でエラー
として表示されたすべての行に入力します。
crm(live)configure template#
edit
4 設定を表示し、設定が有効かどうか確認します(太字のテキストは、ステッ
プ 3c (196 ページ)で入力した設定によって異なります)。
crm(live)configure template# show
primitive virtual-ip ocf:heartbeat:IPaddr \
params ip="192.168.1.101"
primitive apache ocf:heartbeat:apache \
params configfile="/etc/apache2/httpd.conf"
monitor apache 120s:60s
group g-intranet \
apache virtual-ip
5 設定を適用します。
crm(live)configure template# apply
crm(live)configure# cd ..
crm(live)configure# show
6 変更内容をCIBに送信します。
crm(live)configure#
commit
詳細がわかっていれば、コマンドをさらに簡素化できます。次のコマンドを
シェルで使用して、上記の手順を要約できます。
root # crm configure template \
new g-intranet apache params \
configfile="/etc/apache2/httpd.conf" ip="192.168.1.101"
内部crmシェルに入っている場合は、次のコマンドを使用します。
crm(live)configure template# new intranet apache params \
configfile="/etc/apache2/httpd.conf" ip="192.168.1.101"
ただし、このコマンドは、設定テンプレートから設定を作成するだけです。
設定をCIBに適用したり、コミットすることはありません。
196
高可用性ガイド
7.1.5 シャドーイング設定のテスト
シャドーイング設定は、異なる設定シナリオのテストに使用されます。複数
のシャドウ設定を作成した場合は、1つ1つテストして変更を加えた影響を確
認できます。
通常の処理は次のようになります。
1 rootとしてログインし、crm対話型シェルを開始します。
root # crm configure
2 新しいシャドウ設定を作成します。
crm(live)configure# cib new myNewConfig
INFO: myNewConfig shadow CIB created
シャドウCIBの名前を省略する場合は、一時名の@tmp@が作成されます。
3 現在のライブ設定をシャドウ設定にコピーする場合は、次のコマンドを使
用します。コピーしない場合は、このステップをスキップします。
crm(myNewConfig)# cib reset myNewConfig
このコマンドを使用すると、既存のリソースを後から編集する場合に、簡
単に編集できます。
4 通常どおり変更を行います。シャドウ設定の作成後は、すべての変更がシャ
ドウ設定に適用されます。すべての変更を保存するには、次のコマンドを
使用します。
crm(myNewConfig)# commit
5 ライブクラスタ設定が再び必要な場合は、次のコマンドでライブ設定に戻
ります。
crm(myNewConfig)configure# cib use live
crm(live)#
クラスタリソースの設定と管理(コマンドライン)
197
7.1.6 設定の変更のデバッグ
設定の変更をクラスタにロードする前に、変更内容をptestでレビューする
ことを推奨します。ptestコマンドを指定すると、変更のコミットによって
生じるアクションのダイアグラムを表示できます。ダイアグラムを表示する
には、graphvizパッケージが必要です。次の例は監視操作を追加するスク
リプトです。
root # crm configure
crm(live)configure# show fence-bob
primitive fence-bob stonith:apcsmart \
params hostlist="bob"
crm(live)configure# monitor fence-bob 120m:60s
crm(live)configure# show changed
primitive fence-bob stonith:apcsmart \
params hostlist="bob" \
op monitor interval="120m" timeout="60s"
crm(live)configure# ptest
crm(live)configure# commit
7.1.7 クラスタダイアグラム
図5.2「Hawk - クラスタダイアグラム」 (106 ページ)に示すようなクラスタダ
イアグラムを出力するには、コマンドcrm configure graphを使用します。
これにより現在の設定が現在のウィンドウに表示されるので、X11が必要にな
ります。
SVG (Scalable Vector Graphics)を使用する場合は、次のコマンドを使用します。
root # crm configure graph dot config.svg svg
7.2 グローバルクラスタオプションの
設定
グローバルクラスタオプションは、一定の状況下でのクラスタの動作を制御
します。事前に定義されている値は、通常は、そのまま保持できます。ただ
し、クラスタの主要機能を正しく機能させるには、クラスタの基本的なセッ
トアップ後に、次のパラメータを調整する必要があります。
198
高可用性ガイド
手順 7.1 crmでグローバルクラスタオプションを変更する
1 rootとしてログインし、crmツールを開始します。
root # crm configure
2 次のコマンドを使用して、2ノードクラスタだけのオプションを設定しま
す。
crm(live)configure# property no-quorum-policy=ignore
crm(live)configure# property stonith-enabled=true
重要: STONITHがない場合はサポートなし
STONITHがないクラスタはサポートされません。
3 変更内容を表示します。
crm(live)configure# show
property $id="cib-bootstrap-options" \
dc-version="1.1.1-530add2a3721a0ecccb24660a97dbfdaa3e68f51" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
no-quorum-policy="ignore" \
stonith-enabled="true"
4 変更内容をコミットして終了します。
crm(live)configure# commit
crm(live)configure# exit
7.3 クラスタリソースの設定
クラスタの管理者は、クラスタ内のサーバ上の各リソースや、サーバ上で実
行する各アプリケーションに対してクラスタリソースを作成する必要があり
ます。クラスタリソースには、Webサイト、電子メールサーバ、データベー
ス、ファイルシステム、仮想マシン、およびユーザが常時使用できるように
する他のサーバベースのアプリケーションまたはサービスなどが含まれます。
作成できるリソースタイプの概要については、4.2.3項「リソースのタイ
プ」 (65 ページ)を参照してください。
クラスタリソースの設定と管理(コマンドライン)
199
7.3.1 クラスタリソースの作成
クラスタで使用できるRA(リソースエージェント)には3種類あります(背景情
報については4.2.2項「サポートされるリソースエージェントクラ
ス」 (63 ページ)を参照)。新しいリソースをクラスタに追加するには、次の手
順に従います。
1 rootとしてログインし、crmツールを開始します。
root # crm configure
2 プリミティブIPアドレスを設定ます。
crm(live)configure# primitive myIP ocf:heartbeat:IPaddr \
params ip=127.0.0.99 op monitor interval=60s
前のコマンドは「プリミティブ」に名前myIPを設定します。クラス(ここ
ではocf)、プロバイダ(heartbeat)、およびタイプ(IPaddr)を選択する必
要があります。さらに、このプリミティブでは、IPアドレスなどのパラメー
タが必要です。自分の設定に合わせてアドレスを変更してください。
3 行った変更を表示して確認します。
crm(live)configure#
show
4 変更をコミットして反映させます。
crm(live)configure#
commit
7.3.2 リソーステンプレートの作成
類似した設定で複数のリソースを作成する場合、リソーステンプレートを使
用すれば作業が簡単になります。基本的なバックグラウンド情報については、
4.4.3項「リソーステンプレートと制約」 (84 ページ)を参照してください。こ
れらを、「通常の」テンプレート(7.1.4項「設定テンプレートの使
200
高可用性ガイド
用」 (194 ページ)で説明したもの)と混同しないでください。次の構文を知るに
は、rsc_templateコマンドを使用してください。
root # crm configure rsc_template
usage: rsc_template <name> [<class>:[<provider>:]]<type>
[params <param>=<value> [<param>=<value>...]]
[meta <attribute>=<value> [<attribute>=<value>...]]
[utilization <attribute>=<value> [<attribute>=<value>...]]
[operations id_spec
[op op_type [<attribute>=<value>...] ...]]
たとえば、次のコマンドは、ocf:heartbeat:Xenリソースと、デフォルト
値および操作に由来するBigVMの名前を持つ新しいリソーステンプレートを
作成します。
crm(live)configure# rsc_template BigVM ocf:heartbeat:Xen \
params allow_mem_management="true" \
op monitor timeout=60s interval=15s \
op stop timeout=10m \
op start timeout=10m
新しいリソーステンプレートを定義したら、それをプリミティブとして使用
すること、または順序、コロケーション、またはrsc_ticketの制約で参照する
ことができます。リソーステンプレートを参照するには、@記号を使用しま
す。
crm(live)configure# primitive MyVM1 @BigVM \
params xmfile="/etc/xen/shared-vm/MyVM1" name="MyVM1"
新しいプリミティブMy-VM1は、BigVMリソーステンプレートからすべてを
継承します。たとえば、上の2つに等しいものは次のようになります。
crm(live)configure# primitive MyVM1 ocf:heartbeat:Xen \
params xmfile="/etc/xen/shared-vm/MyVM1" name="MyVM1" \
params allow_mem_management="true" \
op monitor timeout=60s interval=15s \
op stop timeout=10m \
op start timeout=10m
オプションや操作を上書きしたい場合は、自分の(プリミティブの)定義を追加
します。たとえば、次の新しいプリミティブMy-VM2は監視操作のタイムア
ウトを2倍にしますが、その他はそのままに残します。
crm(live)configure# primitive MyVM2 @BigVM \
params xmfile="/etc/xen/shared-vm/MyVM2" name="MyVM2" \
op monitor timeout=120s interval=30s
クラスタリソースの設定と管理(コマンドライン)
201
リソーステンプレートは、そのテンプレートから派生するすべてのプリミティ
ブを表すものとして、制約で参照することができます。これにより、クラス
タ設定をいっそう簡潔かつクリアに行うことができます。リソーステンプレー
トは、場所の制約を除くすべての制約から参照することができます。コロケー
ション制約には、複数のテンプレート参照を含めることはできません。
7.3.3 STONITHリソースの作成
crmからは、STONITHデバイスは単なる1つのリソースと認識されます。
STONITHリソースを作成するには、次の手順に従います。
1 rootとしてログインし、crm対話型シェルを開始します。
root # crm configure
2 次のコマンドで、すべてのSTONITHタイプのリストを取得します。
crm(live)# ra list stonith
apcmaster
apcmastersnmp
baytech
bladehpi
drac3
external/drac5
external/hetzner
external/hmchttp
external/ibmrsa-telnet
external/ipmi
external/kdumpcheck
external/libvirt
external/rackpdu
external/riloe
external/vcenter
external/vmware
external/xen0-ha
fence_legacy
ipmilan
meatware
rcd_serial
rps10
wti_mpc
wti_nps
apcsmart
cyclades
external/dracmc-telnet
external/ibmrsa
external/ippower9258
external/nut
external/sbd
external/xen0
ibmhmc
nw_rpc100s
suicide
3 上記のリストからSTONITHタイプを選択し、利用できるオプションのリス
トを表示します。次のコマンドを実行します。
crm(live)# ra info stonith:external/ipmi
IPMI STONITH external device (stonith:external/ipmi)
ipmitool based power management. Apparently, the power off
method of ipmitool is intercepted by ACPI which then makes
a regular shutdown. If case of a split brain on a two-node
it may happen that no node survives. For two-node clusters
use only the reset method.
Parameters (* denotes required, [] the default):
hostname (string): Hostname
202
高可用性ガイド
The name of the host to be managed by this STONITH device.
...
4 stonithクラス、ステップ 3で選択したタイプ、および必要に応じて該当
するパラメータを使用して、STONITHリソースを作成します。たとえば、
次のコマンドを使用します。
crm(live)# configure
crm(live)configure# primitive my-stonith stonith:external/ipmi \
params hostname="alice" \
ipaddr="192.168.1.221" \
userid="admin" passwd="secret" \
op monitor interval=60m timeout=120s
7.3.4 リソース制約の設定
すべてのリソースを設定することは、ジョブのほんの一部分です。クラスタ
が必要なすべてのリソースを認識しても、正しく処理できるとは限りません。
たとえば、DRBDのスレーブノードにファイルシステムをマウントしないよう
にしてください(実際、DRBDでは失敗します)。このような情報をクラスタが
利用できるように、制約を定義します。
制約の詳細については、4.4項「リソースの制約」 (80 ページ)を参照してく
ださい。
7.3.4.1 場所の制約
locationコマンドは、リソースを実行できるノード、できないノード、ま
たは実行に適したノードを定義するものです。
この種類の制約は、各リソースに複数追加できます。すべてのlocation制
約は、所定のリソースに関して評価されます。fs1というIDを持つリソース
をaliceという名前のノード上で実行するプリファレンスを100にする簡単な
例を次に示します。
crm(live)configure# location loc-fs1 fs1 100: alice
もう1つの例は、pingdによる場所の設定です。
crm(live)configure# primitive pingd pingd \
params name=pingd dampen=5s multiplier=100 host_list="r1 r2"
crm(live)configure# location loc-node_pref internal_www \
クラスタリソースの設定と管理(コマンドライン)
203
rule 50: #uname eq alice \
rule pingd: defined pingd
場所の制約のもう1つの使用例は、「リソースセット」としてのプリミティブ
のグループ化です。これは、たとえば、いくつかのリソースがネットワーク
接続のping属性によって異なるときに役立つ場合があります。以前は、
-inf/pingルールを設定で何度も重複して指定する必要があったため、設定
内容が不必要に複雑でした。
次の例では、リソースセット loc-aliceを作成し、仮想IPアドレス vip1 お
よび vip2を参照します。
crm(live)configure# primitive vip1 ocf:heartbeat:IPaddr2 params ip=192.168.1.5
crm(live)configure# primitive vip1 ocf:heartbeat:IPaddr2 params ip=192.168.1.6
crm(live)configure# location loc-alice { vip1 vip2 } inf: alice
ある場合には、locationコマンドでリソースパターンを使用すると、より
効率的で便利です。リソースパターンは、2つのスラッシュ間の正規表現で
す。たとえば、前に示した仮想IPアドレスは、次とすべて一致させることが
できます。
crm(live)configure# location
loc-alice /vip.*/ inf: alice
7.3.4.2 コロケーション制約
colocationコマンドは、同じホストまたは別のホストで実行するべきリソー
スを定義するために使用します。
常に同じノードで実行する必要があるリソース、または同じノードで実行し
てはならないリソースを定義する場合には、それぞれ+infまたは-infのスコア
を設定することだけが可能です。無限大以外のスコアの使用も可能です。そ
の場合、コロケーションはadvisoryと呼ばれ、衝突が発生したときに他のリ
ソースが停止しないようにするため、クラスタがそれらの制約に従わないこ
ともあります。
たとえば、IDがfilesystem_resourceとnfs_groupのリソースを常に同
じホストで実行するには、次の制約を使用します。
crm(live)configure# colocation nfs_on_filesystem inf: nfs_group
filesystem_resource
マスタスレーブ構成では、現在のノートがマスタかどうかと、リソースをロー
カルに実行しているかどうかを把握することが必要です。
204
高可用性ガイド
7.3.4.3 依存性なしのリソースセットのコロケーション
同じノード上にリソースのグループを配置できると便利な場合がありますが
(コロケーション制約を定義)、リソース間で困難な依存性を持つことはありま
せん。
同じノード上にリソースを配置するが、これらの一方に障害が発生した場合
のアクションがない場合は、weak-bondコマンドを使用します。
root # crm configure assist weak-bond RES1 RES2
weak-bondの実装により、指定されたリソースを持つダミーリソースとコロ
ケーション制約が自動的に作成されます。
7.3.4.4 順序の制約
orderコマンドは、アクションのシーケンスを定義します。
リソースのアクションや操作の順序を指定することが必要な場合があります。
たとえば、デバイスがシステムで利用できるようになるまで、ファイルシス
テムはマウントできません。順序の制約を使用して、開始、停止、マスタへ
の昇格など、別のリソースが特殊な条件を満たす直前または直後に、サービ
スを開始または停止できます。
順序の制約を設定するには、次のようなコマンドをcrmシェルで使用します。
crm(live)configure# order nfs_after_filesystem mandatory: filesystem_resource
nfs_group
7.3.4.5 サンプル設定のための制約
このセクションで使用される例は、制約を追加しないと機能しません。すべ
てのリソースは、必ず、マスタであるDRBDリソースと同じマシンで実行され
る必要があります。DRBDリソースは、他のリソースが開始する前にマスタに
する必要があります。マスタでないときに、drbdデバイスをマウントしよう
とすると失敗します。次の制約を満たす必要があります。
• ファイルシステムは、常に、DRDBリソースのマスタと同じノード上に存在
する必要があります。
crm(live)configure# colocation filesystem_on_master inf: \
filesystem_resource drbd_resource:Master
クラスタリソースの設定と管理(コマンドライン)
205
• NFSサーバとIPアドレスは、ファイルシステムと同じノードに存在する必要
があります。
crm(live)configure# colocation nfs_with_fs inf: \
nfs_group filesystem_resource
• NFSサーバとIPアドレスは、ファイルシステムがマウントされた後に開始さ
れます。
crm(live)configure# order nfs_second mandatory: \
filesystem_resource:start nfs_group
• ファイルシステムは、drbdリソースがこのノードのマスタに昇格した後にマ
ウントされる必要があります。
crm(live)configure# order drbd_first inf: \
drbd_resource:promote filesystem_resource:start
7.3.5 リソースフェールオーバーノードの指
定
リソースフェールオーバーを判定するには、メタ属性migration-thresholdを使
用します。すべてのノードで失敗回数がmigration-thresholdを超えている場合
には、リソースは停止したままになります。例:
crm(live)configure# location rsc1-alice rsc1 100: alice
通常、rsc1はaliceで実行されます。そこで失敗すると、migration-thresholdが
チェックされ、失敗回数と比較されます。失敗回数がmigration-threshold以上
の場合、次の候補のノードにマイグレートします。
開始が失敗すると、start-failure-is-fatalオプションによっては、失
敗回数がinfに設定されます。stopの失敗により、フェンシングが発生します。
STONITHが定義されていない場合には、リソースは移行しません。
概要については、4.4.4項「フェールオーバーノード」 (85 ページ)を参照して
ください。
206
高可用性ガイド
7.3.6 リソースフェールバックノードの指定
(リソースの固着性)
ノードがオンライン状態に戻り、クラスタ内にある場合は、リソースが元の
ノードにフェールバックすることがあります。リソースを実行していたノー
ドにリソースをフェールバックさせたくない場合や、リソースのフェールバッ
ク先として別のノードを指定する場合は、リソースのresource stickiness
値を変更します。リソースの固着性は、リソースの作成時でも、その後でも
指定できます。
概要については、4.4.5項「フェールバックノード」 (86 ページ)を参照してく
ださい。
7.3.7 負荷インパクトに基づくリソース配置
の設定
一部のリソースは、メモリの最小量など、特定の容量要件を持っています。
要件が満たされていない場合、リソースは全く開始しないか、またはパフォー
マンスを下げた状態で実行されます。
これを考慮に入れて、High Availability Extensionでは、次のパラメータを指定
できます。
1. 一定のノードが提供する容量
2. 一定のリソースが要求する容量
3. リソースの配置に関する全体的なストラテジ
パラメータと設定の詳細な背景情報については、4.4.6項「負荷インパクトに
基づくリソースの配置」 (87 ページ)を参照してください。
リソースの要件とノードが提供する容量を設定するには、使用属性を使用し
ます。使用属性に任意の名前を付け、設定に必要なだけ名前/値のペアを定義
します。いくつかのエージェントは、たとえばVirtualDomainなどの使用
を更新します。
クラスタリソースの設定と管理(コマンドライン)
207
次の例では、クラスタのノードとリソースの基本設定がすでに完了している
ことを想定しています。さらに、特定のノードが提供する容量と特定のリソー
スが必要とする容量を設定します。
手順 7.2 crmで使用属性を追加または変更する
1 rootとしてログインし、crm対話型シェルを開始します。
root # crm configure
2 ノードが提供する容量を指定するには、次のコマンドを使用し、プレース
ホルダNODE_1をノードの名前に置き換えます。
crm(live)configure# node
NODE_1 utilization memory=16384 cpu=8
これらの値によって、NODE_1は16GBのメモリと8つのCPUコアをリソース
に提供すると想定されます。
3 リソースが要求する容量を指定するには、次のコマンドを使用します。
crm(live)configure# primitive xen1 ocf:heartbeat:Xen ... \
utilization memory=4096 cpu=4
これによって、リソースはnodeAからの4096のメモリ単位と4つのCPUユニッ
トを使用します。
4 propertyコマンドを使用して、配置ストラテジを設定します。
crm(live)configure# property ...
次の値を使用できます。
default (デフォルト値)
使用値は考慮しません。リソースは、場所のスコアに従って割り当て
られます。スコアが同じであれば、リソースはノード間で均等に分散
されます。
utilization
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定
する際に、利用率を確認します。ただし、負荷分散は、まだ、ノード
に割り当てられたリソースの数に基づいて行われます。
208
高可用性ガイド
minimal
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定
する際に、利用率を確認します。できるだけ少ない数のノードにリソー
スを集中しようとします(残りのノードの電力節約のため)。
balanced
リソースの要件を満たすだけの空き容量がノードにあるかどうか決定
する際に、利用率を確認します。リソースを均等に分散して、リソー
スのパフォーマンスを最適化しようとします。
注記: リソース優先度の設定
使用できる配置ストラテジは、最善策であり、まだ、複雑なヒューリス
ティックソルバで、常に最適な割り当て結果を得るには至っていません。
リソースの優先度を正しく設定して、最重要なリソースが最初にスケ
ジュールされるようにしてください。
5 変更をコミットしてから、crmshを終了します。
crm(live)configure#
commit
次の例は、同等のノードから成る3ノードクラスタと4つの仮想マシンを示し
ています。
crm(live)configure# node alice utilization memory="4000"
crm(live)configure# node bob utilization memory="4000"
crm(live)configure# node charly utilization memory="4000"
crm(live)configure# primitive xenA ocf:heartbeat:Xen \
utilization hv_memory="3500" meta priority="10" \
params xmfile="/etc/xen/shared-vm/vm1"
crm(live)configure# primitive xenB ocf:heartbeat:Xen \
utilization hv_memory="2000" meta priority="1" \
params xmfile="/etc/xen/shared-vm/vm2"
crm(live)configure# primitive xenC ocf:heartbeat:Xen \
utilization hv_memory="2000" meta priority="1" \
params xmfile="/etc/xen/shared-vm/vm3"
crm(live)configure# primitive xenD ocf:heartbeat:Xen \
utilization hv_memory="1000" meta priority="5" \
params xmfile="/etc/xen/shared-vm/vm4"
crm(live)configure# property placement-strategy="minimal"
クラスタリソースの設定と管理(コマンドライン)
209
3ノードはすべてアクティブであり、まず、xenAがノードに配置され、次に、
xenDが配置されます。xenBとxenCは、一緒に割り当てられるか、またはどち
らか1つがxenDとともに割り当てられます。
1つのノードに障害が発生した場合、残りのノード上で利用できるメモリ合計
が少なすぎて、これらのリソースすべてはホストできません。xenAは確実に
割り当てられ、xenDも同様です。ただし、xenBとxenCは、そのどちらか1つ
しか割り当てられません。xenBとxenCの優先度は同等なので、結果はまだ未
定義です。これを解決するためにも、どちらかに高い優先度を設定する必要
があります。
7.3.8 リソース監視の設定
リソースを監視するには、2つの方法(opキーワードで監視処理を定義するか、
monitorコマンドを使用するか)があります。次の例では、Apacheリソースを
設定し、opキーワードの使用で 60秒ごとに監視します。
crm(live)configure# primitive apache apache \
params ... \
op monitor interval=60s timeout=30s
同じことを次のようにしても実行できます。
crm(live)configure# primitive apache apache \
params ...
crm(live)configure# monitor apache 60s:30s
概要については、4.3項「リソース監視」 (79 ページ)を参照してください。
7.3.9 クラスタリソースグループの構成
クラスタの一般的な要素の1つは、一緒の場所で見つける必要のあるリソース
のセットです。連続的に開始し、逆の順序で停止します。この設定を簡単に
するため、グループのコンセプトをサポートしています。次の例では、2つの
プリミティブ(IPアドレスと電子メールリソース)を作成します。
1 crmコマンドをシステム管理者として実行します。プロンプトがcrm(live)
に変化します。
2 プリミティブを設定します。
210
高可用性ガイド
crm(live)# configure
crm(live)configure# primitive Public-IP ocf:IPaddr:heartbeat \
params ip=1.2.3.4 id=p.public-ip
crm(live)configure# primitive Email lsb:exim \
params id=p.lsb-exim
3 該当するIDを使用して、正しい順序で、プリミティブをグループ化します。
crm(live)configure# group g-shortcut Public-IP Email
グループメンバーの順序を変更するには、configureサブコマンドから
modgroupコマンドを使用します。プリミティブのEmailをPublic-IPの前
に移動するには、次のコマンドを使用します(このコマンドは機能のデモのみ
を目的としています)。
crm(live)configure# modgroup g-shortcut add p.lsb-exim before p.public-ip
グループ(Emailなど)からリソースを削除する場合には、次のコマンドを使用
します。
crm(live)configure# modgroup g-shortcut remove p.lsb-exim
概要については、4.2.5.1項「グループ」 (66 ページ)を参照してください。
7.3.10 クローンリソースの設定
クローンは当初、IPアドレスのN個のインスタンスを開始し、負荷分散のため
にクラスタ上に分散させる便利な方法と考えられていました。それらは、DLM
との統合、サブシステムおよびOCFS2のフェンシングなど、他の目的にも有
効であることがわかってきました。どのようなリソースでも、リソースエー
ジェントがサポートしていれば、クローン化できます。
クローンリソースの詳細については、4.2.5.2項「クローン」 (68 ページ)を参
照してください。
7.3.10.1 匿名クローンリソースの作成
匿名クローンリソースを作成するには、まずプリミティブリソースを作成し
て、それをcloneコマンドで指定することです。次の操作を実行してくださ
い:
クラスタリソースの設定と管理(コマンドライン)
211
1 rootとしてログインし、crm対話型シェルを開始します。
root # crm configure
2 次のように、プリミティブを設定します。
crm(live)configure# primitive Apache lsb:apache
3 プリミティブをクローンします。
crm(live)configure# clone cl-apache Apache
7.3.10.2 ステートフル/マルチステートクローンリソー
スの作成
ステートフルクローンリソースを作成するには、まずプリミティブリソース
を作成してから、マルチステートリソースを作成します。マルチステートリ
ソースは少なくとも、昇格および降格操作をサポートしている必要がありま
す。
1 rootとしてログインし、crm対話型シェルを開始します。
root # crm configure
2 プリミティブを作成します。必要に応じて間隔を変更します。
crm(live)configure# primitive my-rsc ocf:myCorp:myAppl \
op monitor interval=60 \
op monitor interval=61 role=Master
3 マルチステートリソースを作成します。
crm(live)configure# ms ms-rsc my-rsc
7.4 クラスタリソースの管理
crmツールでは、クラスタリソースの設定が可能なだけでなく、既存リソー
スを管理することもできます。移行のサブセクションで概要を示します。
212
高可用性ガイド
7.4.1 新しいクラスタリソースの開始
新しいクラスタリソースを開始するには、そのIDが必要です。次の手順に従
います。
1 rootとしてログインし、crm対話型シェルを開始します。
root #
crm
2 リソースレベルに切り替えます。
crm(live)#
resource
3 startでリソースを開始し、<Tab>キーを押してすべての既知のリソース
を表示します。
crm(live)resource# start ID
7.4.2 リソースのクリーンアップ
リソースは、失敗した場合は自動的に再起動しますが、失敗のたびにリソー
スの失敗回数が増加します。migration-thresholdがそのリソースに設定
されている場合は、失敗の数が移行しきい値に達するとただちに、そのリソー
スはノードで実行できなくなります。
1 シェルを開いて、rootユーザとしてログインします。
2 すべてのリソースのリストを取得します。
root # crm resource list
...
Resource Group: dlm-clvm:1
dlm:1 (ocf::pacemaker:controld) Started
clvm:1 (ocf::lvm2:clvmd) Started
cmirrord:1
(ocf::lvm2:cmirrord) Started
クラスタリソースの設定と管理(コマンドライン)
213
3 リソースdlmをクリーンアップするには、たとえば、以下の手順を実行し
ます:
root # crm resource cleanup dlm
7.4.3 クラスタリソースの削除
次の手順に従って、クラスタリソースを削除します。
1 rootとしてログインし、crm対話型シェルを開始します。
root # crm configure
2 次のコマンドを実行して、リソースのリストを取得します。
crm(live)# resource status
たとえば、出力はこのようになります(ここで、myIPはリソースの該当する
ID)。
myIP
(ocf::IPaddr:heartbeat) ...
3 該当するIDを持つリソースを削除します(これは、commitも含意します)。
crm(live)# configure delete YOUR_ID
4 変更をコミットします。
crm(live)# configure commit
7.4.4 クラスタリソースのマイグレーション
リソースは、ハードウェアまたはソフトウェアに障害が発生した場合、クラ
スタ内の他のノードに自動的にフェールオーバー(つまり移行)するよう設定さ
れていますが、Pacemaker GUIまたはコマンドラインを使用して、手動でリ
ソースをクラスタ内の別のノードに移動することもできます。
この作業を行うには、migrateコマンドを使用します。たとえば、リソース
ipaddress1をbobというクラスタノードに移行するには、次のコマンドを
使用します。
214
高可用性ガイド
root # crm resource
crm(live)resource# migrate ipaddress1 bob
7.4.5 リソースのグループ化/タグ付け
タグは、コロケーションの作成や関係の順序付けを行わずに、複数のリソー
スをただちに参照する方法です。これは、概念的に関連するリソースをグルー
プ化するのに役立つ場合があります。たとえば、データベースに関連するい
くつかのリソースがある場合、databasesというタグを作成し、データベー
スに関連するすべてのリソースをこのタグに追加します。
root # crm configure databases: db1 db2 db3
これにより、1つのコマンドですべてを起動できます。
root # crm resource start databases
同様に、すべてを停止することもできます。
root # crm resource stop databases
注記: CIB構文バージョンのアップグレード
リソースをグループ化するタグと一部のACLの機能は、pacemaker-2.0以
上のCIB構文バージョンでのみ動作します。この点に該当するタグやACLで
あるかどうかを確認して、CIBバージョンをアップグレードする方法の詳細
については、『High Availability Guide for SUSE Linux Enterprise High
Availability Extension 11 SP4』のセクション「SLE HA 11 SP3からSLE HA 11
SP4へのアップグレード」を参照してください。
7.4.6 保守モードの使用
クラスタ設定の変更時、個々のノードに対するソフトウェアパッケージの更
新時、または上位製品バージョンへのクラスタのアップグレード時であって
も、個々のクラスタコンポーネント上、またはクラスタ全体でテストや保守
タスクを実行する必要がある場合があります。
それに関して、High Availability Extensionは、次のレベルでmaintenanceオ
プションを提供しています。
クラスタリソースの設定と管理(コマンドライン)
215
クラスタへの保守モードの適用
クラスタ全体を保守モードにする場合は、次のコマンドを使用します。
root # crm configure property maintenance-mode=true
ノードへの保守モードの適用
たとえば、ノードaliceを保守モードにするには:
root # crm node maintenance alice
crm statusコマンドは、aliceの保守モードを表示し、そのノードに他の
リソースが割り当てられないことを示します。ノードから保守フラグを削
除するには、次を使用します。
root # crm node ready alice
リソースへの保守モードの適用
特定のリソースを保守モードに設定する必要がある場合は、metaコマン
ドを使用します。たとえば、リソースipaddressを保守モードにするに
は、次のコマンドを入力します。
root # crm meta ipaddress set maintenance true
警告: データ損失の危険
クラスタ制御下でサービスを実行しているときにテストまたは保守タスク
を実行する必要がある場合は、次のアウトラインに従ってください。
1. 手順を開始する前に、個々のリソース、ノード、またはクラスタ全体を
保守モードに設定します。これにより、順序正しくリソースを起動でき
ないなどの望ましくない影響、クラスタノード間でCIBが同期されないリ
スク、またはデータ損失を避けることができます。
2. 保守タスクまたはテストを実行します。
3. 完了したら、保守モードを解除して、通常のクラスタ操作を開始します。
保守モード中にリソースおよびクラスタで何が発生するかの詳細については、
4.7項「メンテナンスモード」 (97 ページ)を参照してください。
216
高可用性ガイド
7.5 cib.xmlから独立したパスワードの
設定
クラスタ設定にパスワードなどの機密の情報が含まれている場合、それらを
ローカルファイルに保存する必要があります。こうしておけば、これらのパ
ラメータがログに記録されたり、サポートレポートに漏洩することはありま
せん。
secretを使用する前に、リソースの概要を確認するため、showコマンドを
実行しておくとよいでしょう。
root # crm configure show
primitive mydb ocf:heartbeat:mysql \
params replication_user=admin ...
上記のmydbリソースに対してパスワードを設定するには、次のコマンドを使
用します。
root # crm resource secret mydb set passwd linux
INFO: syncing /var/lib/heartbeat/lrm/secrets/mydb/passwd to [your node list]
次のように、保存されたパスワードが返されます。
root # crm resource secret mydb show passwd
linux
パラメータは、ノード間で同期する必要があることに注意してください。crm
resource secretコマンドを使用すれば、この処理が実行されます。秘密
のパラメータを管理する場合には、このコマンドを使用することを強く推奨
します。
7.6 履歴情報の取得
クラスタの履歴の調査は複雑な作業です。この作業を簡素化するために、crm
シェルにはhistoryコマンドとそのサブコマンドが含まれています。これは、
SSHが正しく設定されていることが前提となります。
それぞれのクラスタは、状態を移動し、リソースを移行し、または重要なプ
ロセスを開始します。これらすべてのアクションは、historyのサブコマン
クラスタリソースの設定と管理(コマンドライン)
217
ドによって取得できます。または、手順5.27「履歴エクスプローラで遷移を表
示する」 (140 ページ)で説明するように、Hawkを使用します。
デフォルトでは、すべてのhistoryコマンドは過去1時間のイベントを確認し
ます。このタイムフレームを変更するには、limitサブコマンドを使用しま
す。構文は次のとおりです。
root # crm history
crm(live)history# limit FROM_TIME [TO_TIME]
有効な例として、次のようなものが挙げられます。
limit4:00pm , limit16:00
どちらのコマンドも同じ意味で、今日の午後4時を表しています。
limit2012/01/12 6pm
2012年1月12日の午後6時。
limit"Sun 5 20:46"
今年の今月の5日日曜日の午後8時46分。
その他の例とタイムフレームの作成方法については、http://labix.org/
python-dateutilを参照してください。
infoサブコマンドでは、crm_reportによって使用されているすべてのパラ
メータが表示されます。
crm(live)history# info
Source: live
Period: 2012-01-12 14:10:56 - end
Nodes: alice
Groups:
Resources:
crm_reportを特定のパラメータに制限するには、サブコマンドhelpで使用
可能なオプションを表示します。
詳細レベルに絞り込んでいくには、サブコマンドdetailとレベル数を使用し
ます。
crm(live)history# detail 2
数値が大きいほど、レポートが詳細になっていきます。デフォルト値は0 (ゼ
ロ)です。
218
高可用性ガイド
ここまでのパラメータを設定したら、logを使用してログメッセージを表示
します。
最後の遷移を表示するには、次のコマンドを使用します。
crm(live)history# transition -1
INFO: fetching new logs, please wait ...
このコマンドはログを取得し、dotty (graphvizパッケージから)を実行し
て、遷移グラフを表示します。シェルはログファイルを開きます。ログ内は、
↓と↑カーソルキーでブラウズできます。
遷移グラフを表示する必要がない場合には、nographオプションを使用しま
す。
crm(live)history# transition -1 nograph
7.7 詳細
• crm マニュアルページ。
• アップストリームプロジェクトマニュアルにアクセスします(http://crmsh
.github.io/documentation)。
• 詳しい例については、Highly Available NFS Storage with DRBD and Pacemaker
(↑Highly Available NFS Storage with DRBD and Pacemaker)を参照してくださ
い。
クラスタリソースの設定と管理(コマンドライン)
219
リソースエージェントの追加ま
たは変更
8
クラスタによる管理が必要なすべての作業は、リソースとして使用できなけ
ればなりません。主要なグループとして、リソースエージェントとSTONITH
エージェントの2つがあります。両方のカテゴリで、エージェントの追加や所
有が可能で、クラスタ機能を各自のニーズに合わせて拡張することができま
す。
8.1 STONITHエージェント
クラスタがノードの1つの誤動作を検出し、そのノードの削除が必要となるこ
とがあります。これをフェンシングと呼び、一般にSTONITHリソースで実行
されます。
警告: 外部SSH/STONITHはサポートされていません
SSHが他のシステムの問題にどのように反応するのかを知る方法はありませ
ん。このため、外部SSH/STONITHエージェント(stonith:external/ssh
など)は、運用環境ではサポートされていません。テスト目的でこのような
エージェントをまだ使用する場合は、libglue-develパッケージをインス
トールしてください。
現在使用可能なすべてのSTONITHデバイス(ソフトウェア側から)のリストを
入手するには、crm ra list stonithコマンドを使用します。お気に入り
のエージェントが見つからない場合は、-develパッケージをインストールし
てください。
リソースエージェントの追加または変更
221
今のところ、STONITHエージェントの作成に関するマニュアルはありません。
新しいSTONITHエージェントを作成する場合は、cluster-glueパッケージ
のソースに提供されている例を参照してください。
8.2 OCFリソースエージェントの作成
/usr/lib/ocf/resource.d/で提供されているすべてのOCFリソースエー
ジェントの詳細については、4.2.2項「サポートされるリソースエージェント
クラス」 (63 ページ)を参照してください。各リソースエージェントは、それ
を制御する次の操作をサポートしている必要があります。
start
リソースを開始または有効化します。
stop
リソースを中止または無効化します。
status
リソースのステータスを返します。
monitor
statusと同様ですが、予期しない状態もチェックします。
validate
リソースの設定を検証します。
meta-data
リソースエージェントの情報をXMLで返します。
OCF RAの作成方法の一般的な手順は、次のとおりです。
1 テンプレートとして、/usr/lib/ocf/resource.d/pacemaker/Dummy
ファイルをロードします。
2 新しいリソースエージェントごとに新しいサブディレクトリを作成して、
名前が競合しないようにします。たとえばリソースグループkitchenにリ
ソースcoffee_machineがある場合、このリソースを/usr/lib/ocf/
222
高可用性ガイド
resource.d/kitchen/ディレクトリに追加します。このRAにアクセス
するには、コマンドcrmを実行します。
configureprimitive coffee_1 ocf:coffee_machine:kitchen ...
3 異なるシェル関数を実装し、異なる名前でファイルを保存します。
OCFリソースエージェントの作成についての詳細は、http://linux-ha
.org/wiki/Resource_Agentsを参照してください。コンセプトの特別な
情報については、第1章製品の概要 (3 ページ)を参照してください。
8.3 OCF戻りコードと障害回復
OCF仕様によると、アクションが返す必要がある出口コードの厳密な定義が
あります。クラスタは常に、予期される結果に対する戻りコードを確認しま
す。結果が予期された値と一致しない場合、アクションは失敗したとみなさ
れ、回復処理が開始されます。障害回復には3種類あります。
表 8.1 障害回復の種類
回復の種類
説明
クラスタが行うアク
ション
soft
一時的なエラーが発
生しました。
リソースを再起動す
るか、新しい場所に
移動させます。
hard
一時的ではないエ
ラーが発生しまし
た。エラーは、現在
のノードに固有の場
合があります。
リソースを他の場所
に移動して、現在の
ノードで再試行され
ないようにします。
fatal
すべてのクラスタ
ノードに共通の、一
時的ではないエラー
が発生しました。こ
れは、不正な設定が
リソースを停止し
て、どのクラスタ
ノードでも開始され
ないようにします。
リソースエージェントの追加または変更
223
回復の種類
説明
クラスタが行うアク
ション
指定されたことを示
しています。
アクションが失敗したと仮定して、次の表では、エラーコードを受け取った
場合の異なるOCF戻りコードとクラスタが開始する回復の種類を概説します。
表 8.2 OCF戻りコード
224
OCF
戻り
コー
ド
OCFエイリア
ス
説明
回復の
種類
0
OCF_SUCCESS
成功。コマンドは正常に完了しま
した。これは、すべてのstart、
stop、promote、demoteコマンドの
予期された結果です。
soft
1
OCF_ERR_GENERIC
汎用の「問題が発生した」ことを
示すエラーコード。
soft
2
OCF_ERR_ARGS
リソースの設定がこのマシンで有
効ではありません(たとえば、ノー
ド上に見つからない場所/ツールを
参照している場合)。
hard
3
OCF_ERR_UNIMPLEMENTED
要求されたアクションは実行され
ていません。
hard
4
OCF_ERR_PERM
リソースエージェントに、作業を
完了できるだけの権限がありませ
ん。
hard
高可用性ガイド
OCF
戻り
コー
ド
OCFエイリア
ス
説明
回復の
種類
5
OCF_ERR_INSTALLED
リソースが必要とするツールがこ
のコンピュータにインストールさ
れていません。
hard
6
OCF_ERR_CONFIGURED
リソースの設定が無効です(たとえ
ば、必要なパラメータがないな
ど)。
fatal
7
OCF_NOT_RUNNING
リソースが実行されていません。
クラスタは、どのアクションにつ
いてもこれを返すリソースを停止
しようとしません。
N/A
このOCF戻りコードはリソース回
復を必要することも必要としない
こともあります。予期されたリ
ソースの状態に依存します。予期
されない場合は、soft回復を行い
ます。
8
OCF_RUNNING_MASTER
リソースはマスタモードで実行し
ています。
soft
9
OCF_FAILED_MASTER
リソースはマスタモードですが、
失敗しました。リソースは降格、
停止され、再度開始されます(昇格
されます)。
soft
その
他
該当なし
カスタムエラーコード。
soft
リソースエージェントの追加または変更
225
9
フェンシングとSTONITH
フェンシングはHA(High Availability)向けコンピュータクラスタにおいて、非
常に重要なコンセプトです。クラスタがノードの1つの誤動作を検出し、その
ノードの削除が必要となることがあります。これをフェンシングと呼び、一
般にSTONITHリソースで実行されます。フェンシングは、HAクラスタを既知
の状態にするための方法として定義できます。
クラスタのすべてのリソースには、それぞれ状態が関連付けられています。
たとえば、「リソースr1はaliceで起動されている」などです。HAクラスタで
は、このような状態は「リソースr1はalice以外のすべてのノードで停止してい
る」ことを示します。クラスタは各リソースが1つのノードでのみ起動される
ようにするためです。各ノードはリソースに生じた変更を報告する必要があ
ります。つまり、クラスタの状態は、リソースの状態とノードの状態の集ま
りです。
ノードまたはリソースの状態を十分に確定することができない場合には、フェ
ンシングが発生します。クラスタが所定のノードで起こっていることを認識
しない場合でも、フェンシングによって、そのノードが重要なリソースを実
行しないようにできます。
9.1 フェンシングのクラス
フェンシングには、リソースレベルとノードレベルのフェンシングという、2
つのクラスがあります。後者について、この章で主に説明します。
フェンシングとSTONITH
227
リソースレベルのフェンシング
リソースレベルのフェンシングでは、クラスタが、ノードによる1つ以上
のリソースのアクセスを不可能にできます。代表的な一例はSANで、フェ
ンシング操作によってSANスイッチのルールを変更し、ノードからのアク
セスを拒否します。
リソースレベルのフェンシングは、保護対象のリソースが依存している通
常のリソースを使用して実行できます。このようなリソースは、このノー
ド上での起動を拒否するため、それに依存するリソースは同じノード上で
実行されません。
ノードレベルのフェンシング
ノードレベルのフェンシングでは、ノードがどのリソースも実行しなくな
ります。このことは通常、そのノードをリセットする、または電源オフに
するというような、極端な手段で行われます。
9.2 ノードレベルのフェンシング
SUSE® Linux Enterprise High Availability Extensionにおけるフェンシングの実装
が、STONITH (Shoot The Other Node in the Head)です。これにより、ノードレ
ベルのフェンシングが実行されます。High Availability Extensionにはstonith
コマンドラインツールが付属し、これはクラスタ上のノードの電源をリモー
トでオフにする拡張インタフェースです。使用できるオプションの概要につ
いては、stonith --helpを実行するか、またはstonithのマニュアルペー
ジで詳細を参照してください。
9.2.1 STONITHデバイス
ノードレベルのフェンシングを使用するには、まず、フェンシングデバイス
を用意する必要があります。High Availability Extensionでサポートされている
STONITHデバイスのリストを取得するには、任意のノード上で次のコマンド
のいずれかを実行します。
root # stonith -L
または
root # crm ra list stonith
228
高可用性ガイド
STONITHデバイスは次のカテゴリに分類できます。
電源分配装置(PDU)
電源分配装置は、重要なネットワーク、サーバ、データセンター装置の電
力と機能を管理する、重要な要素です。接続した装置のリモートロード監
視と、個々のコンセントでリモート電源オン/オフのための電力制御を実
行できます。
無停電電源装置(UPS)
電力会社からの停電時に別個のソースから電力を供給することで、安定し
た電源から接続先の装置に緊急電力が提供されます。
ブレード電源制御デバイス
クラスタを一連のブレード上で実行している場合、ブレードエンクロー
ジャの電源制御デバイスがフェンシングの唯一の候補となります。当然、
このデバイスは1台のブレードコンピュータを管理できる必要があります。
ライトアウトデバイス
ライトアウトデバイス(IBM RSA、HP iLO、Dell DRAC)は急速に広まって
おり、既製コンピュータの標準装備になる可能性さえあります。ただし、
電源をホスト(クラスタノード)と共有するため、これらはUPSデバイスに
内蔵されています。ノードに電力が供給されないままでは、それを制御す
るデバイスも役に立ちません。その場合は、CRMがノードのフェンシン
グの試行を無限に継続し、他のすべてのリソース操作はフェンシン
グ/STONITH操作の完了を待機することになります。
テストデバイス
テストデバイスは、テスト専用に使用されます。通常、ハードウェアにあ
まり負担をかけないようになっています。クラスタが運用に使用される前
に、実際のフェンシングデバイスに交換される必要があります。
STONITHデバイスは、予算と使用するハードウェアの種類に応じて選択しま
す。
9.2.2 STONITHの実装
SUSE® Linux Enterprise High Availability ExtensionでのSTONITHの実装は、2つ
のコンポーネントで構成されています。
フェンシングとSTONITH
229
stonithd
stonithdは、ローカルプロセスまたはネットワーク経由でアクセスできる
デーモンです。stonithdは、フェンシング操作に対応するコマンド(rest、
power-off、power-on)を受け入れます。フェンシングデバイスのステータ
スチェックも行います。
stonithdデーモンはCRM HAクラスタの各ノードで実行されます。DCノー
ドで実行されるstonithdインスタンスは、CRMからフェンシング要求を受
け取ります。目的のフェンシング操作を実行するのは、このインスタンス
とその他のstonithdプログラムです。
STONITHプラグイン
サポートされているフェンシングデバイスごとに、そのデバイスを制御で
きるSTONITHプラグインがあります。STONITHプラグインはフェンシン
グデバイスへのインタフェースです。cluster-glueパッケージに付属
するSTONITHプラグインは、各ノード上の/usr/lib/stonith/
plugins(64ビットアーキテクチャの場合は/usr/lib64/stonith/
plugins)にあります(fence-agentsパッケージもインストールしている
場合、そのパッケージに付属する各種プラグインは、/usr/sbin/fence
_*にインストールされています)。すべてのSTONITHプラグインはstonithd
からは同一のものと認識されますが、フェンシングデバイスの性質を反映
しているため、大きな違いがあります。
一部のプラグインは、複数のデバイスをサポートします。代表的な例は
ipmilan (またはexternal/ipmi)で、IPMIプロトコルを実装し、このプ
ロトコルをサポートする任意のデバイスを制御できます。
9.3 STONITHのリソースと環境設定
フェンシングをセットアップするには、1つまたは複数のSTONITHリソースを
設定する必要があります。stonithdデーモンでは設定は不要です。すべての設
定はCIBに保存されます。STONITHリソースはクラスstonithのリソースで
す(4.2.2項「サポートされるリソースエージェントクラス」 (63 ページ)を参
照)。STONITHリソースはSTONITHプラグインのCIBでの表現です。フェンシ
ング操作の他、STONITHリソースはその他のリソースと同様、起動、停止、
監視できます。STONITHリソースの開始または停止は、ノード上でSTONITH
デバイスドライバのロードおよびアンロードが行われることを意味していま
す。開始と停止は管理上の操作であるため、フェンシングデバイス自体での
230
高可用性ガイド
操作にはなりません。ただし、監視は、デバイスのログイン操作になります
(必要な場合にデバイスが動作していることを検証するため)。STONITHリソー
スが別のノードにフェールオーバーすると、対応するドライバがロードされ
て、現在のノードがSTONITHデバイスと通信できるようにされます。
STONITHリソースはその他のリソースと同様にして設定できます。これらの
操作の詳細については、使用しているクラスタ管理ツールに応じて次のいず
れかを参照してください。
• Pacemaker GUI: 6.3.2項「STONITHリソースの作成」 (162 ページ)
• Hawk: 5.3.3項「STONITHリソースの作成」 (114 ページ)
• crmsh: 7.3.3項「STONITHリソースの作成」 (202 ページ)
パラメータ(属性)のリストは、それぞれのSTONITHの種類に依存します。特
定のデバイスのパラメータ一覧を表示するには、stonithコマンドを実行し
ます。
stonith -t stonith-device-type -n
たとえば、ibmhmcデバイスタイプのパラメータを表示するには、次のように
入力します。
stonith -t ibmhmc -n
デバイスの簡易ヘルプテキストを表示するには、-hオプションを使用します。
stonith -t stonith-device-type -h
9.3.1 STONITHリソースの設定例
以降では、crmコマンドラインツールの構文で作成された設定例を紹介しま
す。これを適用するには、サンプルをテキストファイル(sample.txtなど)に
格納して、実行します。
root # crm < sample.txt
crmコマンドラインツールでのリソースの設定については、第7章クラスタリ
ソースの設定と管理(コマンドライン) (189 ページ)を参照してください。
フェンシングとSTONITH
231
例 9.1 IBM RSAライトアウトデバイスの設定
IBM RSAライトアウトデバイスは、次のようにして設定できます。
configure
primitive st-ibmrsa-1 stonith:external/ibmrsa-telnet \
params nodename=alice ipaddr=192.168.0.101 \
userid=USERID passwd=PASSW0RD
primitive st-ibmrsa-2 stonith:external/ibmrsa-telnet \
params nodename=bob ipaddr=192.168.0.102 \
userid=USERID passwd=PASSW0RD
location l-st-alice st-ibmrsa-1 -inf: alice
location l-st-bob st-ibmrsa-2 -inf: bob
commit
この例では、location制約が使用されていますが、それは、STONITH操作が常
に一定の確率で失敗するためです。したがって、(実行側でもあるノード上の)
STONITH操作は信頼できません。ノードがリセットされていない場合、フェ
ンシング操作結果について通知を送信できません。これを実行する方法は、
操作が成功すると仮定して事前に通知を送信するほかありません。ただし操
作が失敗した場合、問題が発生することがあります。したがって、規則によっ
てstonithdはホストの終了を拒否します。
例 9.2 UPSフェンシングデバイスの設定
UPSタイプのフェンシングデバイスの設定は、上記の例と似ています。詳細
についてはここでは割愛します。すべてのUPSデバイスは、フェンシングの
ために、同じ機構を使用します。デバイスへのアクセス方法が異なる方法。
古いUPSデバイスにはシリアルポートしかなく、通常、特別のシリアルケー
ブルを使用して1200ボーで接続していました。新型の多くは、まだシリアル
ポートがありますが、USBインタフェースまたはEthernetインタフェースも使
用します。使用できる接続の種類は、プラグインが何をサポートしているか
によります。
たとえば、apcmasterをapcsmartデバイスと、stonith -t
stonith-device-type -nコマンドを使用して比較します。
stonith -t apcmaster -h
次の情報が返されます。
STONITH Device: apcmaster - APC MasterSwitch (via telnet)
NOTE: The APC MasterSwitch accepts only one (telnet)
connection/session a time. When one session is active,
subsequent attempts to connect to the MasterSwitch will fail.
For more information see http://www.apc.com/
List of valid parameter names for apcmaster STONITH device:
232
高可用性ガイド
ipaddr
login
password
今度は次のコマンドを使用します。
stonith -t apcsmart -h
次の結果が得られます。
STONITH Device: apcsmart - APC Smart UPS
(via serial port - NOT USB!).
Works with higher-end APC UPSes, like
Back-UPS Pro, Smart-UPS, Matrix-UPS, etc.
(Smart-UPS may have to be >= Smart-UPS 700?).
See http://www.networkupstools.org/protocols/apcsmart.html
for protocol compatibility details.
For more information see http://www.apc.com/
List of valid parameter names for apcsmart STONITH device:
ttydev
hostlist
最初のプラグインは、ネットワークポートとtelnetプロトコルを持つAPC UPS
をサポートします。2番目のプラグインはAPC SMARTプロトコルをシリアル
回線で使用します。これはその他多数のAPC UPS製品ラインでサポートされ
ているものです。
例 9.3 kdumpデバイスの設定
kdump機能を有効にしたノードをすべて監視するには、
stonith:fence_kdumpリソースエージェント(パッケージfence-agents
で提供)を使用します。構成の例については、以下のリソースを参照してくだ
さい。
configure
primitive st-kdump stonith:fence_kdump \
params nodename="alice "\
params pcmk_host_check="dynamic-list" \
params pcmk_reboot_action="off" \
params pcmk_monitor_action="metadata" \
params pcmk_reboot_retries="1" \
params timeout="60"
commit
フェンシングされるノードの名前。複数のノードを監視する必要がある
場合は、追加のSTONITHリソースを設定します。特定のノードでフェン
シングデバイスを使用しないようにするには、場所に対する制約を追加
します。
フェンシングとSTONITH
233
フェンシングのアクションは、リソースのタイムアウトが経過すると始まり
ます。
各ノード上の/etc/sysconfig/kdumpで、kdumpプロセスが完了したときに
すべてのノードに通知が送信されるようにKDUMP_POSTSCRIPTを設定しま
す。次に例を示します。
/usr/lib64/fence_kdump_send -i INTERVAL -p PORT -c 1 alice bob charly [...]
kdumpが完了すると、kdumpを実行するノードが自動的に再起動します。
fence_kdumpリソースで使用するポートを必ずファイアウォールで開いてお
くようにします。デフォルトポートは7410です。
9.4 フェンシングデバイスの監視
他のリソースと同様に、STONITHクラスのエージェントは、ステータスの
チェックのための監視操作もサポートします。
注記: STONITHリソースの監視
STONITHリソースの監視は定期的に行われますが、頻繁ではありません。
ほとんどのデバイスでは、少なくとも1800秒(30分)の監視間隔があれば十分
です。
フェンシングデバイスはHAクラスタの不可欠な要素ですが、使用する必要が
少ないほど好都合です。ブロードキャストトラフィックが多すぎると、しば
しば、電源管理装置が影響を受けます。1分間に10本程度の接続しか処理でき
ないデバイスもあります。2つのクライアントが同時に接続しようとすると、
混乱するデバイスもあります。大部分は、同時に複数のセッションを処理で
きません。
したがって、通常、フェンシングデバイスのステータスは数時間ごとにチェッ
クすれば十分です。フェンシング操作の実行が必要となり、電源スイッチが
故障する可能性は小さいものです。
監視操作の設定方法の詳細は、GUIアプローチについては手順6.3「メタ属性
およびインスタンス属性を追加または変更する」 (160 ページ)、コマンドライ
ンアプローチについては7.3.8項「リソース監視の設定」 (210 ページ)を参照し
てください。
234
高可用性ガイド
9.5 特殊なフェンシングデバイス
実際のSTONITHデバイスを操作するプラグインに加えて、特殊目的のSTONITH
プラグインも存在します。
警告: テスト目的のみ
次に示すSTONITHプラグインの一部は、デモとテストだけを目的としてい
ます。次のデバイスは、現実のシナリオでは使用しないでください。使用
すると、データが損なわれたり、予測できない結果が生じることがありま
す。
• external/ssh
• ssh
fence_kdump
このプラグインは、ノードでカーネルダンプが進行中かどうかをチェック
します。進行中であればtrueを返し、ノードがフェンシングされたかの
ように動作します。いずれにせよ、ダンプ中には、ノードはどのリソース
も実行できません。これによって、すでにダウンしているがダンプ中(こ
れは時間がかかります)であるノードのフェンシングを避けることができ
ます。このプラグインは、別の実際のSTONITHデバイスとともに使用す
る必要があります。
設定の詳細については、例9.3「kdumpデバイスの設定」 (233 ページ)を参
照してください。
external/sbd
これは自己フェンシングデバイスです。共有ディスクに挿入されることが
ある、いわゆる「ポイズンピル」に反応します。共有ストレージ接続が失
われた場合、このデバイスはノードの動作を停止します。このSTONITH
エージェントを使用してストレージベースのフェンシングを実装する方法
については、第17章ストレージ保護、17.1.3.5項「フェンシングリソース
の設定」 (325 ページ)を参照してください。詳細については、http://www
.linux-ha.org/wiki/SBD_Fencingも参照してください。
フェンシングとSTONITH
235
重要: external/sbdおよびDRBD
external/sbdフェンシングメカニズムは、SBDパーティションが各
ノードから直接読み取れることを要求します。そのため、SBDパーティ
ションではDRBD*デバイスを使用してはなりません。
ただし、SBDパーティションが階層配置または複製されていない共有
ディスク上にある場合には、DRBDクラスタでフェンシングメカニズム
を使用することはできます。
external/ssh
別のソフトウェアベースの「フェンシング」メカニズムです。ノードは、
rootとして、パスワードなしでお互いにログインできる必要があります。
このメカニズムは、1つのパラメータhostlistをとり、ターゲットにす
るノードを指定します。これは、本当に障害のあるノードをリセットする
ことはできないので、実際のクラスタには使用しないでください。これ
は、テストとデモの目的にのみ使用します。これを共有ストレージに使用
すると、データが破損します。
meatware
meatwareではユーザが操作を支援する必要があります。起動すると、
meatwareはノードのコンソールに表示されるCRIT重大度メッセージを
記録します。その場合、オペレータはノードがダウンしていることを確認
して、meatclient(8)コマンドを発行します。これによりmeatware
は、クラスタに対して、そのノードが機能しなくなっていることを伝え
ます。詳細については、/usr/share/doc/packages/cluster-glue/
README.meatwareを参照してください。
suicide
これはソフトウェアのみのデバイスで、rebootコマンドを使用して実行
しているノードを再起動できます。これにはノードのオペレーティングシ
ステムによる操作が必要で、特定の状況では失敗することがあります。し
たがって、このデバイスの使用は、極力避けてください。ただし、1ノー
ドクラスタで使用する場合は安全です。
suicideは、「自分のホストを停止させない」というルールに対する唯一の
例外です。
236
高可用性ガイド
9.6 基本的な推奨事項
次の推奨事項のリストをチェックして、よく発生する間違いを避けてくださ
い。
• 複数の電源スイッチを並列に接続しないでください。
• STONITHデバイスとその設定をテストする際には、各ノードからプラグを
1回抜いて、ノードのフェンシングが起こらないことを検証してください。
• リソースのテストは負荷のかかった状態で行って、タイムアウト値が適切
であるかどうかを検証してください。タイムアウト値が短すぎると、(不必
要な)フェンシング操作がトリガされることがあります。詳細については、
4.2.9項「タイムアウト値」 (77 ページ)を参照してください。
• セットアップでは適切なフェンシングデバイスを使用してください。詳細
については、9.5項「特殊なフェンシングデバイス」 (235 ページ)も参照し
てください。
• 1つ以上のSTONITHリソースを設定します。デフォルトでは、グローバルク
ラスタオプションstonith-enabledはtrueに設定されています。STONITH
リソースが定義されていない場合、クラスタはどのリソースの開始も拒否
します。
• グローバルクラスタオプションstonith-enabledをfalseに設定しない
でください。これは、次の理由によります。
• STONITHが有効でないクラスタはサポートされていません。
• DLM/OCFS2は、決して発生しないフェンシング操作を待機して、永
久にブロックし続けます。
• グローバルクラスタオプションstartup-fencingをfalseに設定しない
でください。デフォルトでは、これは次の理由でtrueに設定されていま
す。クラスタの起動時に、あるノードが不明な状態になっていると、その
ノードは、ステータスが明らかにされるまでフェンシングされます。
フェンシングとSTONITH
237
9.7 詳細
/usr/share/doc/packages/cluster-glue
インストールしたシステムのこのディレクトリには、多数のSTONITHプ
ラグインおよびデバイスのREADMEファイルが格納されています。
http://www.linux-ha.org/wiki/STONITH
STONITHに関する情報。High Availability Linux Projectのホームページにあ
ります。
http://www.clusterlabs.org/doc/
• 『Pacemakerの説明』: Pacemakerの設定に必要なコンセプトを説明
します。包括的で詳しい参照用情報です。
http://techthoughts.typepad.com/managing_computers/2007/
10/split-brain-quo.html
HAクラスタでのスプリットブレイン、クォーラム、フェンシングのコン
セプトを説明する記事。
238
高可用性ガイド
10
アクセス制御リスト
crmシェル(crmsh)、Hawk、Pacemaker GUIなどのクラスタ管理ツールは、root
ユーザまたはhaclientグループに属するユーザが使用できます。デフォル
トで、これらのユーザは完全な読み込み/書き込みのアクセス権を持ちます。
アクセスを制限するか、または詳細なアクセス権を割り当てるには、「アク
セス制御リスト」(ACL)を使用できます。
アクセス制御リストは、順序付けされたアクセスルールセットで構成されて
います。各ルールにより、クラスタ設定の一部への読み込みまたは書き込み
アクセスの許可、またはアクセスの拒否が行われます。ルールは通常、組み
合わせて特定の役割を生成し、ユーザを自分のタスクに一致する役割に割り
当てることができます。
注記: CIB検証バージョンとACLとの違い
このACLマニュアルは、pacemaker-2.0以上のCIB構文バージョンでCIBを
検証する場合にのみ適用します。この検証方法およびCIBバージョンのアッ
プグレード方法の詳細については、CIB構文バージョンのアップグレー
ド (384 ページ)を参照してください。
SUSE Linux Enterprise High Availability Extension 11 SP3からアップグレード
する一方で、それまで使用してきたCIBバージョンを保持している場合は、
『High Availability Guide for SUSE Linux Enterprise High Availability Extension
11 SP3』の「アクセス制御リスト」の章を参照してください。http://www
.suse.com/documentation/から入手できます。
アクセス制御リスト
239
10.1 要件と前提条件
クラスタでACLの使用を開始する前に、次の条件が満たされていることを確
認します。
• NIS、Active Directoryを使用するか、またはすべてのノードに同じユーザを
手動で追加して、クラスタ内のすべてのノード上に同じユーザがいること
を確認します。
• ACLでアクセス権を変更したいすべてのユーザがhaclientグループに属し
ている必要があります。
• すべてのユーザが絶対パス/usr/sbin/crmでcrmshを実行する必要があり
ます。
• 権限のないユーザがcrmshを実行する場合は、/usr/sbinを使用して、PATH
変数を展開する必要があります。
重要: デフォルトのアクセス権
• ACLはオプションの機能です。デフォルトでは、ACLの使用は無効になっ
ています。
• ACL機能が無効化された場合、rootおよびhaclientグループに属する
すべてのユーザは、クラスタ設定への完全な読み込み/書き込みアクセス
権を持ちます。
• ACLが有効化され、設定される場合でも、rootおよびデフォルトのCRM
所有者haclientは両方とも、「常に」クラスタ設定への完全なアクセス
権を持ちます。
ACLを使用するには、XPathに関するいくらかの知識が必要になります。XPath
はXMLドキュメントでノードを選択するための言語です。http://en
.wikipedia.org/wiki/XPathを参照するか、http://www.w3.org/TR/
xpath/の仕様を確認してください。
240
高可用性ガイド
10.2 クラスタでのACLの使用の有効化
ACLの設定を開始する前に、ACLの使用を「有効にする」必要があります。
有効にするには、crmshで次のコマンドを使用します。
root # crm configure property enable-acl=true
または、手順10.1「HawkでのACLの使用の有効化」 (241 ページ)で説明するよ
うに、Hawkを使用します。
手順 10.1 HawkでのACLの使用の有効化
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［クラスタのプロパティ］を選択します。
3 ［CRMの環境設定］グループで、空のドロップダウンボックスから［enableacl］属性を選択し、プラスアイコンをクリックして追加します。
4 enable-acl=trueを設定するには、enable-aclの隣のチェックボック
スをオンにして、変更内容を確認します。
10.3 ACLの基\'96\'7b事項
アクセス制御リストは、順序付けされたアクセスルールセットで構成されて
います。各ルールにより、クラスタ設定の一部への読み込みまたは書き込み
アクセスの許可、またはアクセスの拒否が行われます。ルールは通常、組み
合わせて特定の役割を生成し、ユーザを自分のタスクに一致する役割に割り
当てることができます。ACLの役割はCIBへのアクセス権を表すルールのセッ
トです。ルールは次の要素で構成されています。
• read、write、またはdenyのようなアクセス権。
• ルールを適用する場所の指定。種類、ID参照、またはXPath式を使用して指
定できます。
通常、ACLを役割にバンドルし、システムユーザ(ACLターゲット)に特定の役
割を割り当てると便利です。ACLルールを作成するためには、次の2つの方法
があります。
アクセス制御リスト
241
• 10.3.1項「XPath式によるACLルールの設定」 (242 ページ)。ACLルールを作
成するためには、その記述言語であるXMLの構造を理解している必要があ
ります。
• 10.3.2項「短縮によるACLルールの設定」 (244 ページ)。簡略構文を作成し、
ACLルールが一致するオブジェクトに適用します。
10.3.1 XPath式によるACLルールの設定
XPathによってACLルールを管理するには、その記述言語であるXMLの構造を
理解している必要があります。XMLでクラスタ設定を表示する次のコマンド
で構造を取得します(例 10.1を参照)。
root # crm configure show xml
例 10.1 XML内のクラスタ設定の例
<num_updates="59"
dc-uuid="175704363"
crm_feature_set="3.0.9"
validate-with="pacemaker-2.0"
epoch="96"
admin_epoch="0"
cib-last-written="Fri Aug 8 13:47:28 2014"
have-quorum="1">
<configuration>
<crm_config>
<cluster_property_set id="cib-bootstrap-options">
<nvpair name="stonith-enabled" value="true"
id="cib-bootstrap-options-stonith-enabled"/>
<nvpair name="no-quorum-policy" value="ignore"
id="cib-bootstrap-options-no-quorum-policy"/>
[...]
</cluster_property_set>
</crm_config>
<nodes>
<node id="175704363" uname="alice"/>
<node id="175704619" uname="bob"/>
</nodes>
<resources> [...] </resources>
<constraints/>
<rsc_defaults> [...] </rsc_defaults>
<op_defaults> [...] </op_defaults>
<configuration>
</cib>
XPath言語を使用して、このXMLドキュメント内のノードを見つけることがで
きます。たとえば、ルートノード(cib)を選択するには、XPath式/cibを使用
242
高可用性ガイド
します。グローバルクラスタ設定を見つけるには、XPath
式/cib/configuration/crm_configを使用します。
一例として、表10.1「オペレータ役割 - アクセスタイプおよびXPath
式」 (243 ページ)は、「オペレータ」の役割を作成するためのパラメータ(アク
セスタイプおよびXPath式)を示しています。この役割を持つユーザは、2番目
の列で説明されるタスクのみ実行することができ、リソースを再構成するこ
とはできません(たとえば、パラメータや操作の変更など)。また、コロケー
ションや順序の制約の設定を変更することもできません。
表 10.1 オペレータ役割 - アクセスタイプおよびXPath式
タイプ
XPath/説明
書き込み
//crm_config//nvpair[@name='maintenance-mode']
クラスタ保守モードをオンまたは
オフにします。
書き込み
//op_defaults//nvpair[@name='record-pending']
保留中の操作を記録するかを選択
します。
書き込み
//nodes/node//nvpair[@name='standby']
ノードをオンラインまたはスタン
バイモードで設定します。
書き込み
//resources//nvpair[@name='target-role']
リソースを開始、停止、昇格また
は降格します。
書き込み
//resources//nvpair[@name='maintenance']
リソースを保守モードにするかど
うかを選択します。
書き込み
//constraints/rsc_location
アクセス制御リスト
243
タイプ
XPath/説明
リソースをノードから別のノード
にマイグレート/移動します。
読み込み
/cib
クラスタのステータスを表示しま
す。
10.3.2 短縮によるACLルールの設定
XML構造を扱いたくないユーザ向には、より簡単な方法があります。
たとえば、次のXPathを検討します。
//*[@id='rsc1']
このXPathは、IDがrsc1であるXMLノードをすべて探し出します。
短縮構文はこのように書かれます。
ref:"rsc1"
これは制約にも使用できます。これが冗長なXPathです。
//constraints/rsc_location
短縮構文はこのように書かれます。
type:"rsc_location"
短縮構文はcrmshおよびHawkで使用できます。CIBデーモンは一致するオブ
ジェクトにACLルールを適用する方法を認識しています。
10.4 Pacemaker GUIによるACLの構成
次の手順は、monitor役割を定義し、それをユーザに割り当てることで、ク
ラスタ設定への読み込み専用アクセスを設定する方法を示しています。また
は、10.5項「HawkによるACLの設定」 (246 ページ)と手順10.4「監視の役割を
244
高可用性ガイド
追加して、crmshを持つユーザに割り当てる」 (248 ページ)で説明されている
ように、Hawkあるいはcrmshを使用してこの操作を実行することもできます。
手順 10.2 Pacemaker GUIを使用して、監視の役割を追加し、ユーザを割り当
てる
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してログインします。
2 ［設定］ツリー内の［ACL］エントリをクリックします。
3 ［追加］をクリックします。ダイアログボックスが表示されます。［ACL
Target (ACLターゲット)］または［ACLの役割］を選択します。
4 ACLの役割を定義するには、次のとおり実行します。
4a ［ ACLの役割］を選択します。設定オプションを追加するウィンド
ウが開きます。
4b ［ID］テキストフィールド内に固有の識別子を追加します(例［監
視］)。
4c ［追加］をクリックして、権利(［読み込み］、［書き込み］、また
は［拒否］)を選択します。ここの例では［読み込み］を選択しま
す。
4d XPath式/cibを［Xpath］テキストフィールドに入力します。［OK］
をクリックして、続行します。
傍注: リソースや制約がある場合、10.3.2項「短縮によるACLルール
の設定」 (244 ページ)で説明したように、短縮構文も使用できます。
4e その他の条件がある場合、手順(ステップ 4c (245 ページ)およびステッ
プ 4d (245 ページ))を繰り返します。この例ではあてはまらないため、
役割は完了し、［OK］をクリックしてウィンドウを閉じることがで
きます。
5 次のようにユーザに役割を割り当てます
アクセス制御リスト
245
5a ［追加］ボタンをクリックします。［ACL Target (ACLターゲット)］
または［ACLの役割］を選択するダイアログボックスが表示されま
す。
5b ［ACL Target (ACLターゲット)］を選択します。設定オプションを追
加するウィンドウが開きます。
5c ［ID］テキストフィールドにユーザ名を入力します。このユーザが
haclientグループに属することを確認します。
5d ステップ 4b (245 ページ)で指定されている役割名をクリックして使用
します。
10.5 HawkによるACLの設定
次の手順は、monitor役割を定義し、それをユーザに割り当てることで、ク
ラスタ設定への読み込み専用アクセスを設定する方法を示しています。また
は、手順10.4「監視の役割を追加して、crmshを持つユーザに割り当て
る」 (248 ページ)で説明されているように、crmshを使用してこの操作を実行
することもできます。
手順 10.3 監視の役割を追加して、Hawkを持つユーザに割り当てる
1 5.1.1項「Hawkの起動とログイン」 (102 ページ)で説明したように、Webブ
ラウザを起動してクラスタにログインします。
2 左のナビゲーションバーで、［アクセス制御リスト］を選択します。この
ビューには、すでに定義済みの［役割］と［ユーザ］が表示されます。
3 ACLの役割を定義するには、次のとおり実行します。
3a ［役割］カテゴリを選択し、プラスアイコンをクリックします。
3b 固有な［役割ID］として、monitorなどを入力します。
3c monitor役割を定義する例として、［右］ドロップダウンボックス
からreadを選択します。
246
高可用性ガイド
3d ［Xpath］テキストボックスに、Xpath式/cibを入力し、［役割の作
成］をクリックします。
この操作は、monitorの名前を持つ新しい役割を作成して、readの
権利を設定し、XPath式/cibを使用してCIB内のすべての要素に適用
します。
3e 必要に応じて、プラスアイコンをクリックして各パラメータを指定
し、さらにアクセス権およびXPath引数を追加できます。変更内容を
確認します。
4 次のようにユーザに役割を割り当てます。
4a ［ユーザ］カテゴリを選択し、プラスアイコンをクリックします。
［ユーザの作成］ビューに使用可能な役割が表示されます。この
ビューにはそのユーザの個別ACLルールを設定するための追加の行
も含まれます。このビューでは、ユーザに1つまたは複数の役割を割
り当てたり、ユーザに1つ以上の個別ルールを定義することもできま
す。役割を選択すると、個別ルールの行が非表示となり、その逆も
同様になります。役割と個別ルールを割り当てることはできません。
4b 固有な［ユーザID］として、tuxなどを入力します。このユーザが
haclientグループに属することを確認します。
4c ユーザに役割を割り当てるには、［役割］から各エントリを選択し
ます。例では、作成したmonitor役割を選択します。
1つまたは複数の役割を選択解除するには、各エントリをもう一度ク
リックします。役割が選択されていない場合は、個別ルールを定義
するための行が再表示されます。
アクセス制御リスト
247
図 10.1 Hawk—役割またはルールのユーザへの割り当て
4d 代わりに個別ルールを定義する場合は、［右］を選択し、ルールに
対する各Xpathパラメータを入力します。追加のルールを定義するに
は、プラスアイコンをクリックします。
4e 選択内容を確認し、［ユーザの作成］をクリックしてユーザに役割
またはルールを割り当てます。
リソースや制約に対するアクセス権を設定するには、10.3.2項「短縮による
ACLルールの設定」 (244 ページ)で説明したように、短縮構文も使用できま
す。
10.6 crmshによるACLの設定
次の手順は、monitor役割を定義し、それをユーザに割り当てることで、ク
ラスタ設定への読み込み専用アクセスを設定する方法を示しています。
手順 10.4 監視の役割を追加して、crmshを持つユーザに割り当てる
1 rootとしてログインします。
2 crmshの対話モードを開始します。
root # crm configure
crm(live)configure#
3 ACLの役割を次のとおり定義します。
248
高可用性ガイド
3a roleコマンドを使用して、新しい役割を定義します。
crm(live)configure# role monitor read xpath:"/cib"
前のコマンドは、monitorの名前を持つ新しい役割を作成して、
readの権利を設定し、XPath式/cibを使用してCIB内のすべての要
素に適用します。必要な場合は、アクセス権およびXPath引数をさら
に追加できます。
3b 必要に応じてさらに役割を追加します。
4 役割を1つ以上のACLターゲットに割り当てます。このACLターゲットは、
該当のシステムユーザです。これらのシステムユーザがhaclientグルー
プに属していることを確認します。
crm(live)configure# acl_target tux monitor
5 変更を確認します:
crm(live)configure#
show
6 変更をコミットします:
crm(live)configure#
commit
リソースや制約に対するアクセス権を設定するには、10.3.2項「短縮による
ACLルールの設定」 (244 ページ)で説明したように、短縮構文も使用できま
す。
アクセス制御リスト
249
ネットワークデバイスボンディ
ング
11
多くのシステムで、通常のEthernetデバイスの標準のデータセキュリティ/可用
性の要件を超えるネットワーク接続の実装が望ましいことがあります。その
場合、数台のEthernetデバイスを集めて1つのボンディングデバイスを設定で
きます。
ボンディングデバイスの設定には、ボンディングモジュールオプションを使
用します。ボンディングデバイスの振る舞いは、ボンディングデバイスのモー
ドによって決定されます。デフォルトの動作は、mode=active-backupで
あり、アクティブなスレーブに障害が発生すると、別のスレーブデバイスが
アクティブになります。
OpenAISの使用時は、クラスタソフトウェアでボンディングデバイスが管理さ
れることはありません。したがって、ボンディングデバイスにアクセスする
可能性のあるクラスタノードごとに、ボンディングデバイスを設定する必要
があります。
11.1 YaSTによるボンディングデバイス
の設定
ボンディングデバイスを設定するには、1つのボンディングデバイスに集める
ことができる数台のEthernetデバイスが必要です。次の手順に従います。
1 rootとしてYaSTを開始し、［ネットワークデバイス］ > ［ネットワーク
設定］の順に選択します。
ネットワークデバイスボンディング
251
2 ［ネットワーク設定］で、［概要］タブに切り替えて、使用可能なデバイ
スを表示します。
3 1つのボンディングデバイスに集めるEthernetデバイスにIPアドレスが割り
当てられているかどうかチェックします。割り当てられている場合は、そ
れを変更します。
3a 選択するデバイスを選択して、［編集］をクリックします。
3b 開いている［ネットワークカードのセットアップ］ダイアログの［ア
ドレス］タブで、［リンクとIPなしのセットアップ(ボンディングス
レーブ)］オプションを選択します。
3c ［次へ］をクリックして、［ネットワーク設定］ダイアログの
［Overview］タブに戻ります。
4 新しいボンディングデバイスを追加するには:
4a ［追加］をクリックして、［デバイスの型］を［ボンド］に変更し
ます。［次へ］で続行します。
252
高可用性ガイド
4b IPアドレスをボンディングデバイスに割り当てる方法を選択します。
3つの方法から選択できます。
• リンクとIPなしのセットアップ(ボンディングスレーブ)
• 可変IPアドレス(DHCPまたはZeroconf)
• 固定IPアドレス
ご使用の環境に適合する方法を使用します。OpenAISで仮想IPアドレ
スを管理する場合は、［静的割り当てIPアドレス］を選択し、イン
タフェースにIPアドレスを割り当てます。
4c ［ボンドスレーブ］タブに切り替えます。
4d ステップ 3bでボンディングスレーブとして設定したEthernetデバイス
が表示されます。ボンドに含めるEthernetデバイスを選択するため、
［ボンドスレーブ］の該当するオプションのチェックボックスをオ
ンにします。
4e ［ボンドドライバオプション］を編集します。次のモードを使用で
きます。
ネットワークデバイスボンディング
253
balance-rr
パケットが正しい順序で転送されなくなる代わりに、負荷分散と
耐障害性が提供されます。これは、TCPの再構築時などに遅延の
原因になる場合があります。
active-backup
耐障害性を提供します。
balance-xor
負荷分散と耐障害性を提供します。
ブロードキャスト
耐障害性を提供します。
802.3ad
接続されるスイッチでサポートされる場合は、ダイナミックリン
ク集合を提供します。
balance-tlb
発信トラフィックの負荷分散を提供します。
balance-alb
使用中にハードウェアアドレスの変更が可能なネットワークデバ
イスを使用する場合は、着信トラフィックと発信トラフィックの
負荷分散を提供します。
4f ［ボンドドライバオプション］には、パラメータmiimon=100を必
ず追加します。このパラメータがなければ、リンクが定期的にチェッ
クされないため、ボンディングドライバは、障害リンクで引き続き
パケットを失う可能性があります。
5 ［次へ］をクリックして、［OK］でYaSTを終了し、ボンディングデバイ
スの設定を完了します。YaSTが/etc/sysconfig/network/ifcfg
-bondDEVICENUMBERに設定を書き込みます。
254
高可用性ガイド
11.2 ボンディングスレーブのホットプ
ラグ
ボンディングスレーブのインタフェースを別のものに置き換える必要が生じ
ることがあります。たとえば、それぞれのネットワークデバイスに常に障害
が発生する場合などです。解決方法として、ボンディングスレーブのホット
プラグを設定します。デバイスをMACアドレスではなくバスIDによって一致
させるために、udevルールを変更する必要もあります。これにより、ハード
ウェアが許可する場合は、不具合のあるハードウェア(同じスロットにあるの
にMACアドレスが異なるネットワークカードなど)を置き換えることができま
す。
手順 11.1 YaSTによるボンディングスレーブのホットプラグの設定
手動の設定を行う場合は、『SUSE Linux Enterprise Server 11 Administration
Guide』の「Basic Networking」の章の「Hotplugging of Bonding Slaves」という
セクションを参照してください。
1 rootとしてYaSTを開始し、［ネットワークデバイス］ > ［ネットワーク
設定］の順に選択します。
2 ［ネットワーク設定］で、［Overview］タブに切り替えて、すでに設定済
みのデバイスを表示します。ボンディングスレーブがすでに設定済みの場
合、［メモ］列にそのことが示されます。
ネットワークデバイスボンディング
255
3 1つのボンディングデバイスに集められたEthernetデバイスのそれぞれに対
して、次の手順を実行します。
3a 選択するデバイスを選択して、［編集］をクリックします。［Network
Card Setup］ダイアログが開きます。
3b ［一般］タブに切り替えて、［デバイスのアクティブ化］が［ホッ
トプラグ］に設定されていることを確認します。
3c ［ハードウェア］タブに切り替えます。
3d ［Udevルール］で、［変更］をクリックして［BusID］オプションを
選択します。
3e ［OK］および［次へ］をクリックして、［ネットワーク設定］ダイ
アログの［Overview］タブに戻ります。この時点でEthernetデバイス
エントリをクリックすると、下のペインにバスIDを含むデバイスの
詳細が表示されます。
256
高可用性ガイド
4 ［OK］をクリックして変更を確定し、ネットワーク設定を終了します。
ブート時に/etc/init.d/networkはホットプラグスレーブを待機しません
が、ボンドの準備が整うのを待機します。これには少なくとも1つのスレーブ
が利用可能であることが必要です。スレーブインタフェースの1つがシステム
から削除されると(NICドライバからアンバインド、NICドライバのrmmod、ま
たは実際のPCIホットプラグ取り外し)、カーネルによってボンドから自動的
に削除されます。システムに新しいカードが追加されると(スロットのハード
ウェアが置換されると)、udevは、バスベースの永続名規則を適用することで
名前を変更し、ifupを呼び出します。ifup呼び出しによって、ボンドに自
動的に追加されます。
11.3 その他の情報
全モードおよびその他多数のオプションの詳細については、［Linux Ethernet
Bonding Driver HOWTO］に記載されています。これは、kernel-sourceパッ
ケージをインストールした後に参照できる/usr/src/linux/
Documentation/networking/bonding.txtファイルの内容です。
High Availabilityセットアップの場合は、そのファイルで説明されているmiimon
およびuse_carrierオプションが特に重要です。
ネットワークデバイスボンディング
257
Linux仮想サーバによる負荷分
散
12
LVS(Linux仮想サーバ)は、複数のサーバにネットワーク接続を振り分けてワー
クロードを共有させる基本フレームワークの提供を目的としています。Linux
仮想サーバは、1つ以上のロードバランサとサービス実行用の数台の実際の
サーバから成るサーバクラスタですが、外部のクライアントには1つの高速な
大型サーバのように見えます。この単一サーバのように見えるサーバは、仮
想サーバと呼ばれます。Linux仮想サーバは、高度にスケーラブルで可用性の
高いネットワークサービス(Web、キャッシュ、メール、FTP、メディア、VoIP
など)の構築に使用できます。
実際のサーバとロードバランサは、高速LANまたは地理的に分散されたWAN
のいずれでも、相互に接続できます。ロードバランサは、さまざまなサーバ
に要求をディスパッチできます。ロードバランサによって、クラスタのパラ
レルサービスが1つのIPアドレス(仮想IPアドレスまたはVIP)上の仮想サービス
であるかのようにみえます。要求のディスパッチでは、IP負荷分散技術か、
アプリケーションレベル負荷分散技術を使用できます。クラスタ内のノード
のトランスペアレントな追加または削除によって、システムのスケーラビリ
ティが達成されます。ノードまたはデーモンの障害の検出とシステムの適宜
な再設定によって、高度な可用性が提供されます。
12.1 概念の概要
以降のセクションでは、主要なLVSのコンポーネントと概念の概要を示しま
す。
Linux仮想サーバによる負荷分散
259
12.1.1 Director
LVSの主要コンポーネントは、ip_vs (またはIPVS)カーネルコードです。この
コードは、Linuxカーネル内でトランスポート層の負荷分散(レイヤ-4スイッチ
ング)を実装します。IPVSコードを含むLinuxカーネルを実行するノードは、
ディレクターと呼ばれます。ディレクターで実行されるIPVSコードは、LVS
の必須機能です。
クライアントがディレクターに接続すると、着信要求がすべてのクラスタノー
ドに負荷分散されます。つまり、ディレクターは、変更されたルーティング
ルール(LVSを機能させる)セットを使用して、パケットを実サーバに転送しま
す。たとえば、ディレクターは、接続の送受信端でないと、受信確認を送信
しません。ディレクターは、エンドユーザから実サーバ(要求を処理するアプ
リケーションを実行するホスト)にパケットを転送する特殊なルータとして動
作します。
デフォルトでは、IPVSモジュールはカーネルにインストールされている必要
はありません。IPVSカーネルモジュールは、
cluster-network-kmp-defaultパッケージに含まれています。
12.1.2 ユーザスペースのコントローラとデー
モン
ldirectordデーモンは、Linux仮想サーバを管理し、負荷分散型仮想サーバ
のLVSクラスタ内の実サーバを監視するユーザスペースデーモンです。設定
ファイル/etc/ha.d/ldirectord.cfは、仮想サービスとそれらに関連付
けられた実サーバを指定し、LVSリダイレクタとしてサーバを設定する方法
をldirecordに指示します。このデーモンは、その初期化時にクラスタの仮
想サービスを生成します。
ldirectordデーモンは、既知のURLを定期的に要求し、応答を確認するこ
とにより、実サーバのヘルスを監視します。障害が発生した実サーバは、ロー
ドバランサで使用可能なサーバのリストから削除されます。サービス監視は、
ダウンしていたサーバが回復し、再度機能していることを検出すると、その
サーバを使用可能サーバリストに戻します。すべての実サーバがダウンする
場合、Webサービスのリダイレクト先にするフォールバックサーバを指定で
260
高可用性ガイド
きます。通常、フォールバックサーバは、ローカルホストであり、Webサー
ビスが一時的に使用できないことについて緊急ページを表示します。
ldirectordはipvsadmツール(ipvsadmパッケージ)を使用して、Linuxカー
ネル内の仮想サーバテーブルを操作します。
12.1.3 パケット転送
ディレクターがクライアントから実サーバにパケットを送信する方法は、3つ
あります。
NAT (Network Address Translation)
着信要求は仮想IPで着信します。宛先のIPアドレスとポートを、選択した
実サーバのIPアドレスとポートに変更することで、着信要求は実サーバに
転送されます。実サーバはロードバランサに応答を送信し、そのロードバ
ランサが宛先IPアドレスを変更して、応答をクライアントへ転送します。
その結果、エンドユーザは予期されたソースから応答を受信します。すべ
てのトラフィックはロードバランサを通過するので、通常、ロードバラン
サがクラスタのボトルネックになります。
IPトンネリング(IP-IPカプセル化)
IPトンネリングでは、あるIPアドレスにアドレス指定されたパケットを別
のアドレス(別のネットワーク上でも可能)にリダイレクトできます。LVS
は、IPトンネルを介して実サーバに要求を送信し(別のIPアドレスにリダ
イレクト)、実サーバは、独自のルーティングテーブルを使用して、クラ
イアントに直接応答します。クラスタメンバは、さまざまなサブネットに
属すことができます。
直接ルーティング
エンドユーザからのパケットを、直接、実サーバに転送します。IPパケッ
トは変更されないので、仮想サーバのIPアドレスのトラフィックを受け付
けるように、実サーバを設定する必要があります。実サーバからの応答
は、直接、クライアントに送信されます。実サーバとロードバランサは、
同じ物理ネットワークセグメントに属する必要があります。
Linux仮想サーバによる負荷分散
261
12.1.4 スケジューリングアルゴリズム
クライアントから要求された新しい接続に使用する実サーバの決定は、さま
ざまなアルゴリズムを使用して実装されます。それらは、モジュールとして
使用可能であり、特定のニーズに合わせて調整できます。使用可能なモジュー
ルの概要については、ipvsadm(8)のマニュアルページを参照してください。
ディレクターは、クライアントから接続要求を受信すると、スケジュールに
基づいて実際のサーバをクライアントに割り当てます。スケジューラは、IPVS
カーネルコードの一部として、次の新しい接続を取得する実際のサーバを決
定します。
12.2 YaSTによるIP負荷分散の設定
YaST IP負荷分散モジュールを使用して、カーネルベースのIP負荷分散を設定
できます。このモジュールは、ldirectordのフロントエンドです。
IP負荷分散ダイアログにアクセスするには、rootとしてYaSTを開始し、［高
可用性］ > ［IP負荷分散］の順に選択します。または、コマンドラインで
「yast2 iplb」と入力して、rootとしてYaSTクラスタモジュールを起動し
ます。
YaSTモジュールは、その設定を/etc/ha.d/ldirectord.cfに書き込みま
す。YaSTモジュール内で使用できるタブは、設定ファイル/etc/ha.d/
ldirectord.cfの構造、グローバルオプションの定義、および仮想サービ
ス用オプションの定義に対応しています。
設定例とその結果のロードバランサ/実サーバ間のプロセスについては、例12.1
「単純なldirectord設定」 (267 ページ)を参照してください。
注記: グローバルパラメータと仮想サーバパラメータ
特定のパラメータを仮想サーバセクションとグローバルセクションの両方
で指定した場合は、仮想サーバセクションで定義した値が、グローバルセ
クションで定義した値に優先します。
262
高可用性ガイド
手順 12.1 グローバルパラメータを設定する
次の手順では、重要なグローバルパラメータの設定方法を示します。個々の
パラメータ(および、ここに記載されていないパラメータ)の詳細については、
［ヘルプ］をクリックするか、ldirectordのマニュアルページを参照して
ください。
1 ［確認間隔］で、ldirectordが各実サーバに接続していて、それらが
まだオンラインかどうか確認する間隔を定義します。
2 ［確認タイムアウト］で、最後の確認後に実サーバが応答する期限を設
定します。
3 ［障害発生回数］では、ldirectordが、何回、実サーバに要求する
と、確認が失敗したと見なされるか定義できます。
4 ［ネゴシエーションタイムアウト］で、ネゴシエーション確認のタイム
アウトを秒単位で定義します。
5 ［フォールバック］で、すべての実サーバがダウンした場合にWebサー
ビスのリダイレクト先にするWebサーバのホスト名とIPアドレスを入力
します。
6 実サーバへの接続ステータスが変わったら、システムにアラートを送信
させたい場合は、有効な電子メールアドレスを［電子メールアラート］
に入力します。
7 ［電子メールアラート頻度］で、実サーバにアクセスできない状態が続
く場合、何秒後に電子メールアラートを繰り返すか定義します。
8 ［電子メールアラートステータス］で、電子メールアラートを送信する
必要のあるサーバのステータスを指定します。複数の状態を定義する場
合は、カンマで区切ったリストを使用します。
9 ［自動リロード］で、変更の有無について、ldirectordに設定ファイ
ルを継続的に監視させるかどうか定義します。yesに設定した場合は、
変更のたびに、設定ファイルが自動的にリロードされます。
10 ［休止］スイッチで、障害が発生した実サーバをカーネルのLVSテーブ
ルから削除するかどうか定義します。［はい］に設定すると、障害のあ
るサーバは削除されません。代わりに、それらの重み付けが0に設定さ
Linux仮想サーバによる負荷分散
263
れ、新しい接続が受け入れられなくなります。すでに確立している接続
は、タイムアウトするまで持続します。
11 ロギングに代替パスを使用する場合は、［ログファイル］でログのパス
を指定します。デフォルトでは、ldirectordは、そのログを/var/
log/ldirectord.logに書き込みます。
図 12.1 YaST IP負荷分散 - グローバルパラメータ
手順 12.2 仮想サービスを設定する
仮想サービスごとに、2、3のパラメータを定義することによって、1つ以上の
仮想サービスを設定できます。次の手順で、仮想サービスの重要なパラメー
タを設定する方法を示します。個々のパラメータ(および、ここに記載されて
いないパラメータ)の詳細については、［ヘルプ］をクリックするか、
ldirectordのマニュアルページを参照してください。
1 YaST IP負荷分散モジュール内で、［仮想サーバ設定］タブに切り替えま
す。
264
高可用性ガイド
2 ［追加］で新しい仮想サーバを追加するか、［編集］で既存の仮想サー
バを編集します。新しいダイアログに、使用可能なオプションが表示さ
れます。
3 ［仮想サーバ］で、共有仮想IPアドレス(IPv4またはIPv6)とポートを入力
します。これらのアドレスとポートで、ロードバランサと実サーバをLVS
としてアクセスできます。IPアドレスとポート番号の代わりに、ホスト
名とサービスも指定できます。または、ファイアウォールマークを使用
することもできます。ファイアウォールマークは、VIP:portサービス
の任意の集まりを1つの仮想サービスにまとめる方法です。
4 ［実サーバ］で実際のサーバを指定するには、サーバのIPアドレス(IPv4、
IPv6、またはホスト名)、ポート(またはサービス名)、および転送方法を
入力する必要があります。転送方法は、gate、ipip、またはmasqのい
ずれかにする必要があります(12.1.3項「パケット転送」 (261 ページ)参
照)。
［追加］ボタンをクリックし、実サーバごとに必要な引数を入力しま
す。
5 ［確認タイプ］で、実サーバがまだアクティブかどうかをテストするた
めに実行する必要のある確認のタイプを選択します。たとえば、要求を
送信し、応答に予期どおりの文字列が含まれているかどうか確認するに
は、［ネゴシエーション］を選択します。
6 ［確認のタイプ］を［ネゴシエーション］に設定した場合は、監視する
サービスのタイプも定義する必要があります。［サービス］ドロップダ
ウンリストから選択してください。
7 ［要求］で、確認間隔中に各実サーバで要求されるオブジェクトへのURL
を入力します。
8 実サーバからの応答に一定の文字列(「I'm alive」メッセージ)が含まれて
いるかどうか確認する場合は、一致する必要のある正規表現を定義しま
す。正規表現を［受信］に入力します。実サーバからの応答にこの表現
が含まれている場合、実サーバはアクティブとみなされます。
9 ステップ 6 (265 ページ)で選択した［サービス］のタイプによっては、認
証のためのパラメータをさらに指定する必要があります。［認証タイ
プ］タブに切り替えて、［ログイン］、［パスワード］、［データベー
Linux仮想サーバによる負荷分散
265
ス］、または［シークレット］などの詳細を入力します。詳細について
は、YaSTヘルプのテキストか、ldirectordのマニュアルページを参照
してください。
10 ［その他］タブに切り替えます。
11 ロードに使用する［スケジューラ］を選択します。使用可能なスケジュー
ラについては、ipvsadm(8)のマニュアルページを参照してください。
12 使用する［プロトコル］を選択します。仮想サービスをIPアドレスとポー
トとして指定する場合は、プロトコルをtcpまたはudpのどちらかにす
る必要があります。仮想サービスをファイアウォールマークとして指定
する場合は、プロトコルをfwmにする必要があります。
13 必要な場合は、さらにパラメータを定義します。［OK］を選択して、設
定を確認します。YaSTが設定を/etc/ha.d/ldirectord.cfに書き込
みます。
図 12.2 YaST IP負荷分散 - 仮想サービス
266
高可用性ガイド
例 12.1 単純なldirectord設定
図12.1「YaST IP負荷分散 - グローバルパラメータ」 (264 ページ)と図12.2「YaST
IP負荷分散 - 仮想サービス」 (266 ページ)で示された値を使用すると、次のよ
うな設定になり、/etc/ha.d/ldirectord.cfで定義されます。
autoreload = yes
checkinterval = 5
checktimeout = 3
quiescent = yes
virtual = 192.168.0.200:80
checktype = negotiate
fallback = 127.0.0.1:80
protocol = tcp
real = 192.168.0.110:80 gate
real = 192.168.0.120:80 gate
receive = "still alive"
request = "test.html"
scheduler = wlc
service = http
ldirectordが変更の有無について設定ファイルを継続的に確認するよ
うに定義します。
実サーバがまだオンラインかどうか確認するため、ldirectordが各実
サーバに接続する間隔。
最後の確認後、実サーバが応答しなければならない時間的な期限
障害が発生した実サーバをカーネルのLVSテーブルから削除せず、代わ
りに、それらのサーバの重み付けを0に設定します。
LVSの仮想IPアドレス(VIP)。LVSはポート80で使用できます。
実サーバがまだアクティブかどうかをテストするための確認のタイプ。
このサービス用のすべての実サーバがダウンしている場合に、Webサー
ビスのリダイレクト先にするサーバ。
使用するプロトコル。
ポート80で使用できる2つの実サーバが定義されています。パケットの
転送方法がgateなので、直接ルーティングが使用されます。
実サーバからの応答文字列内で一致する必要のある正規表現。
確認間隔中に、各実サーバで要求されるオブジェクトへのURI。
負荷分散に使用するスケジューラが選択されています。
監視するサービスのタイプ
この設定を使用すると、次のような処理フローになります: ldirectordが、
5秒ごとに( )各実サーバに接続し、とで指定されているように、
192.168.0.110:80/test.htmlまたは192.168.0.120:80/test.html
Linux仮想サーバによる負荷分散
267
を要求します。予期されたstill alive文字列( )を、最後の確認から 3秒以
内( )に実サーバから受信しない場合は、実サーバが使用可能なサーバのプー
ルから削除されます。ただし、quiescent=yesが設定されているので( )、
実サーバは、LVSテーブルからは削除されず、代わりに、その重み付けが0に
設定されます。その結果、この実サーバへの新しい接続は受け付けられなく
なります。すでに確立されている接続は、タイムアウトするまで持続します。
12.3 追加設定
YaSTによるldirectordの設定に加えて、LVS設定を完了するには、次の条
件を満たす必要があります。
• 実サーバは、必要なサービスを提供するように正しく設定します。
• 負荷分散サーバは、IP転送を使用して実サーバにトラフィックをルーティ
ングできる必要があります。実サーバのネットワーク設定は、選択したパ
ケット転送方法によって左右されます。
• 負荷分散サーバをシステム全体のシングルポイント障害にしないため、ロー
ドバランサのバックアップを1つ以上セットアップする必要があります。ク
ラスタ設定では、ldirectordにプリミティブリソースを設定して、ハー
ドウェア障害の場合にldirectordが他のサーバにフェールオーバーでき
るようにします。
• ロードバランサのバックアップにも、その作業を達成するために、
ldirectord設定ファイルが必要なので、ロードバランサのバックアップ
として使用するすべてのサーバ上で/etc/ha.d/ldirectord.cfが使用で
きるようにします。設定ファイルは、3.5.4項「すべてのノードへの設定の
転送」 (46 ページ)で説明されているように、Csync2で同期できます。
12.4 その他の情報
Linux仮想サーバの詳細については、プロジェクトのホームページ(http://
www.linuxvirtualserver.org/)を参照してください。
268
高可用性ガイド
ldirectordの詳細については、その総合的なマニュアルページを参照して
ください。
Linux仮想サーバによる負荷分散
269
Geoクラスタ(マルチサイトク
ラスタ)
13
SUSE® Linux Enterprise High Availability Extension 11 SP4は、ローカルクラス
タとメトロエリアクラスタのほかに、地理的に離れたクラスタ(Geoクラスタ。
マルチサイトクラスタとも呼ばれます)もサポートしています。これは、それ
ぞれひとつのローカルクラスタで持った複数の地理的に離れたサイトを持て
ることを意味します。これらクラスタ間のフェールオーバーは、より高いレ
ベルのエンティティであるboothによって管理されます。Geo Clustering for
SUSE Linux Enterprise High Availability Extensionの個別の拡張として、Geoクラ
スタに対するサポートが提供されています。Geoクラスタの使用方法および設
定方法の詳細については、『Geo Clustering for SUSE Linux Enterprise High
Availability Extensionクイックスタート』を参照してください。http://www
.suse.com/documentation/または/usr/share/doc/manual/sle-ha
-geo-manuals_en/の下にあるインストール済みシステムから入手できま
す。
Geoクラスタ(マルチサイトクラスタ)
271
パート III. ストレージおよびデー
タレプリケーション
OCFS2
14
OCFS 2 (Oracle Cluster File System 2)は、Linux 2.6以降のカーネルに完全に統合
されている汎用ジャーナリングファイルシステムです。Oracle Cluster File
System 2を利用すれば、アプリケーションバイナリファイル、データファイ
ル、およびデータベースを、共有ストレージ中のデバイスに保管することが
できます。このファイルシステムには、クラスタ中のすべてのノードが同時
に読み書きすることができます。ユーザスペース管理デーモンは、クローン
リソースを介して管理され、HAスタック(特に、OpenAIS/CorosyncおよびDLM
(Distributed Lock Manager))との統合を実現します。
14.1 特長と利点
OCFS2は、たとえば、次のストレージソリューションに使用できます。
• 一般のアプリケーションとワークロード。
• クラスタ中のXENイメージ。Xen仮想マシンと仮想サーバは、クラスタサー
バによってマウントされたOCFS2ボリュームに保存できます。これによっ
て、サーバ間でXen仮想マシンを素早く容易に移植できます。
• LAMP (Linux、Apache、MySQL、およびPHP | Perl | Python)スタック。
OCF2は、高パフォーマンスでシンメトリックなパラレルクラスタファイルシ
ステムとして、次の機能をサポートします。
OCFS2
275
• アプリケーションのファイルを、クラスタ内のすべてのノードで使用でき
ます。ユーザは、クラスタ中のOracle Cluster File System 2ボリュームに1回
インストールするだけで構いません。
• すべてのノードが、標準ファイルシステムインタフェースを介して、同時
並行的に、ストレージに直接読み書きできるので、クラスタ全体に渡わたっ
て実行されるアプリケーションの管理が容易になります。
• ファイルアクセスがDLMを介して調整されます。ほとんどの場合、DLMに
よる制御は適切に機能しますが、アプリケーションの設計によっては、ア
プリケーションとDLMがファイルアクセスの調整で競合すると、スケーラ
ビリティが制限されることがあります。
• すべてのバックエンドストレージで、ストレージのバックアップ機能を利
用することができます。共有アプリケーションファイルのイメージを簡単
に作成することができるため、災害発生時でも素早くデータを復元するこ
とができます。
Oracle Cluster File System 2には、次の機能も用意されています。
• メタデータのキャッシュ処理。
• メタデータのジャーナル処理。
• ノード間にまたがるファイルデータの整合性。
• 最大4KBのマルチブロックサイズ、最大1MBのクラスタサイズ、4PB(ペタ
バイト)の最大ボリュームサイズをサポートします。
• 32台までのクラスタノードをサポート。
• データベースのパフォーマンスを向上する非同期、直接I/Oのサポート。
14.2 OCFS2のパッケージと管理ユー
ティリティ
SUSE® Linux Enterprise Server 11 SP4上のHigh Availability Extensionには、OCFS2
カーネルモジュール(ocfs2)が自動的にインストールされます。OCFS2を使用
276
高可用性ガイド
するには、ocfs2-toolsと、ご使用のカーネルに適合するocfs2-kmp-*パッ
ケージが、クラスタの各ノードにインストールされていることを確認してく
ださい。
ocfs2-toolsパッケージには、次に示すOCFS2ボリュームの管理ユーティリ
ティがあります。構文については、各マニュアルページを参照してください。
表 14.1 OCFS2ユーティリティ
OCFS2ユーティリティ
説明
debugfs.ocfs2
デバッグの目的で、Oracle Cluster
File System 2のファイルシステムの
状態を調査します。
fsck.ocfs2
ファイルシステムにエラーがない
かをチェックし、必要に応じてエ
ラーを修復します。
mkfs.ocfs2
デバイス上にOCFS2ファイルシス
テムを作成します。通常は、共有
物理/論理ディスク上のパーティ
ションに作成します。
mounted.ocfs2
クラスタシステム上のすべての
OCFS2ボリュームを検出、表示し
ます。OCFS2デバイスをマウント
しているシステム上のすべての
ノードを検出、表示するか、また
はすべてのOCFS2デバイスを表示
します。
tunefs.ocfs2
ボリュームラベル、ノードスロッ
ト数、すべてのノードスロットの
ジャーナルサイズ、およびボ
リュームサイズなど、OCFS2ファ
イルのシステムパラメータを変更
します。
OCFS2
277
14.3 OCFS2サービスとSTONITHリソー
スの設定
OCFS2ボリュームを作成する前に、次のリソースをクラスタ内のサービスと
して設定する必要があります: DLM、O2CBおよびSTONITHリソース。OCFS2
はPacemakerからのクラスタメンバーシップサービスを使用し、それらのサー
ビスはユーザスペースで実行されます。したがって、DLMとO2CBは、クラス
タ内の各ノードに存在するクローンリソースとして設定する必要があります。
次の手順では、crmシェルを使用してクラスタリソースを設定します。リソー
スの設定には、Pacemaker GUIを使用することもできます。
注記: cLVMおよびOCFS2両方のためのDLMリソース
cLVMおよびOCFS2は両方とも、クラスタ内のすべてのノード上で実行する
DLMリソースを必要とするため、通常はクローンとして設定されます。
OCFS2およびcLVMの両方を含むセットアップがある場合、OCFS2およびcLVM
の両方に1つのDLMリソースを設定することで十分です。
手順 14.1 DLMリソースおよびO2CBリソースの設定
設定は複数のプリミティブおよび1つのベースクローンを含むベースグループ
で設定されます。ベースグループとベースクローンはどちらも後でさまざま
なシナリオで使用できます(例: OCFS2およびcLVM)。必要に応じてそれぞれ
のプリミティブを持つベースグループを拡張する必要があるだけです。ベー
スグループは内部コロケーションおよび順序付けを持つため、個々のグルー
プ、クローン、その依存性をいくつも指定する必要がなく、セットアップ全
体を容易にします。
クラスタ内の1つのノードについて、次の手順を実行してください。
1 シェルを起動し、rootまたは同等のものとしてログインします。
2 crm configureを実行します。
3 次を入力して、DLMおよびO2CBのプリミティブリソースを作成します。
crm(live)configure# primitive dlm ocf:pacemaker:controld \
op monitor interval="60" timeout="60"
278
高可用性ガイド
primitive o2cb ocf:ocfs2:o2cb \
op monitor interval="60" timeout="60"
dlmクローンリソースが、分散ロックマネージャサービスを制御し、クラ
スタ内のすべてのノード上でこのサービスが開始するようにします。ベー
スグループの内部コロケーションおよび順序付けによって、o2cbサービス
は、すでに実行しているdlmサービスのコピーを持つノード上でのみ開始
されます。
4 次を入力してベースグループおよびベースクローンを作成します。
crm(live)configure# group base-group dlm o2cb
clone base-clone base-group \
meta interleave="true"
5 showで変更内容をレビューします。
6 すべて正しければ、commitで変更を送信し、exitでcrmライブ設定を終了
します。
手順 14.2 STONITHリソースの設定
注記: 必要なSTONITHデバイス
フェンシングデバイスを設定する必要があります。STONITHなしでは、設
定内に配置されたメカニズム(external/sbdなど)は失敗します。
1 シェルを起動し、rootまたは同等のものとしてログインします。
2 17.1.3.1項「SBDパーティションの作成」 (320 ページ)で説明されるとおり、
SBDパーティションを作成します。
3 crm configureを実行します。
4 external/sdbをフェンシングデバイスとして設定し、/dev/sdb2を共有
ストレージ上のハートビートとフェンシング専用のパーティションにしま
す。
crm(live)configure# primitive sbd_stonith stonith:external/sbd \
params pcmk_delay_max="15" \
op monitor interval="15" timeout="15"
OCFS2
279
5 showで変更内容をレビューします。
6 すべて正しければ、commitで変更を送信し、exitでcrmライブ設定を終了
します。
14.4 OCFS2ボリュームの作成
14.3項「OCFS2サービスとSTONITHリソースの設定」 (278 ページ)で説明され
ているように、DLMとO2CBをクラスタリソースとして設定したら、システム
がOCFS2を使用できるように設定し、OCFS2ボリュームを作成します。
注記: アプリケーションファイルとデータファイル用のOCFS2ボリューム
一般に、アプリケーションファイルとデータファイルは、異なるOCFS2ボ
リュームに保存することを推奨します。アプリケーションボリュームとデー
タボリュームのマウント要件が異なる場合は、必ず、異なるボリュームに
保存します。
作業を始める前に、OCFS2ボリュームに使用するブロックデバイスを準備し
ます。デバイスは空き領域のままにしてください。
次に、手順14.3「OCFS2ボリュームを作成し、フォーマットする」 (282 ページ)
で説明されているように、mkfs.ocfs2で、OCFS2ボリュームを作成し、
フォーマットします。そのコマンドの重要なパラメータは、表14.2「重要な
OCFS2パラメータ」 (280 ページ)に一覧されています。詳細情報とコマンド構
文については、mkfs.ocfs2のマニュアルページを参照してください。
表 14.2 重要なOCFS2パラメータ
280
OCFS2パラメータ
説明と推奨設定
ボリュームラベル(-L)
異なるノードへのマウント時に、
正しく識別できるように、一意の
わかりやすいボリューム名を指定
します。ラベルを変更するには、
tunefs.ocfs2ユーティリティを
使用します。
高可用性ガイド
OCFS2パラメータ
説明と推奨設定
クラスタサイズ(-C)
クラスタサイズは、ファイルに割
り当てられる、データ保管領域の
最小単位です。使用できるオプ
ションと推奨事項については、
mkfs.ocfs2のマニュアルページ
を参照してください。
ノードスロット数(-N)
同時にボリュームをマウントでき
る最大ノード数を指定します。各
ノードについて、OCFS2はジャー
ナルなどの個別のシステムファイ
ルを作成します。ボリュームにア
クセスするノードに、リトルエン
ディアン形式のノード(x86、x8664、およびia64など)とビッグエン
ディアン形式のノード(ppc64や
s390xなど)が混在しても構いませ
ん。
ノード固有のファイルは、ローカ
ルファイルとして参照されます。
ローカルファイルには、ノードス
ロット番号が付加されます。たと
えば、journal:0000は、スロッ
ト番号0に割り当てられたノードに
属します。
各ボリュームを同時にマウントす
ると予期されるノード数に従っ
て、各ボリュームの作成時に、そ
のボリュームの最大ノードスロッ
ト数を設定します。
tunefs.ocfs2ユーティリティを
使用して、必要に応じてノードス
ロットの数を増やします。ただ
し、この値は減らすことはできま
せん。
OCFS2
281
OCFS2パラメータ
説明と推奨設定
ブロックサイズ(-b)
ファイルシステムがアドレス可能
な領域の最小単位を指定します。
ブロックサイズは、ボリュームの
作成時に指定します。使用できる
オプションと推奨事項について
は、mkfs.ocfs2のマニュアル
ページを参照してください。
特定機能のオン/オフ
(--fs-features)
カンマで区切った機能フラグリス
トを指定できます。mkfs.ocfs2
は、そのリストに従って、それら
の機能セットを含むファイルシス
テムを作成しようとします。機能
をオンにするには、その機能をリ
ストに入れます。機能をオフにす
るには、その名前の前にnoを付け
ます。
使用できるすべてのフラグの概要
については、mkfs.ocfs2のマ
ニュアルページを参照してくださ
い。
事前定義機能
(--fs-feature-level)
事前定義されたファイルシステム
機能セットから選択できます。使
用できるオプションについては、
mkfs.ocfs2のマニュアルページ
を参照してください。
mkfs.ocfs2によるボリュームの作成およびフォーマット時に特定の機能を
指定しない場合は、次の機能がデフォルトで有効になります。
backup-super、sparse、inline-data、unwritten、metaecc、
indexed-dirs、およびxattr。
手順 14.3 OCFS2ボリュームを作成し、フォーマットする
クラスタノードの1つだけで、次の手順を実行します。
282
高可用性ガイド
1 端末ウィンドウを開いて、rootとしてログインします。
2 クラスタがオンラインであることをコマンドcrm statusで確認します。
3 mkfs.ocfs2ユーティリティを使用して、ボリュームを作成およびフォー
マットします。このコマンドの指定形式については、mkfs.ocfs2マニュ
アルページを参照してください。
たとえば、最大32台のクラスタノードをサポートする新しいOCFS2ファイ
ルシステムを/dev/sdb1上に作成するには、次のコマンドを使用します。
root #
mkfs.ocfs2 -N 32 /dev/sdb1
14.5 OCFS2ボリュームのマウント
OCFS2ボリュームは、手動でマウントするか、クラスタマネージャでマウン
トできます(手順14.5「クラスタマネージャでOCFS2ボリュームをマウントす
る」 (283 ページ)参照)。
手順 14.4 OCFS2ボリュームを手動でマウントする
1 端末ウィンドウを開いて、rootとしてログインします。
2 クラスタがオンラインであることをコマンドcrm statusで確認します。
3 コマンドラインから、mountコマンドを使ってボリュームをマウントしま
す。
警告: 手動マウントによるOCFS2デバイス
OCFS2ファイルシステムをテスト目的で手動マウントした場合、そのファイ
ルシステムは、いったんマウント解除してから、OpenAISで使用してくださ
い。
手順 14.5 クラスタマネージャでOCFS2ボリュームをマウントする
High AvailabilityソフトウェアでOCFS2ボリュームをマウントするには、クラ
スタ内でocf File Systemリソースを設定します。次の手順では、crmシェルを
OCFS2
283
使用してクラスタリソースを設定します。リソースの設定には、Pacemaker
GUIを使用することもできます。
1 シェルを起動し、rootまたは同等のものとしてログインします。
2 crm configureを実行します。
3 OCFS2ファイルシステムをクラスタ内のすべてのノードにマウントするよ
うに、Pacemakerを設定します。
crm(live)configure# primitive ocfs2-1 ocf:heartbeat:Filesystem \
params device="/dev/sdb1" directory="/mnt/shared" fstype="ocfs2"
options="acl" \
op monitor interval="20" timeout="40"
4 手順14.1「DLMリソースおよびO2CBリソースの設定」 (278 ページ)で設定
したベースグループにファイルシステムのプリミティブを追加します。
4a 入力
crm(live)configure# edit base-group
4b Viエディタが開いたら、そこに次のようにグループを変更し、変更
を保存します。
crm(live)configure# group base-group dlm o2cb ocfs2-1
ベースグループの内部コロケーションおよび順序付けによって、
Pacemakerは、すでに実行しているo2cbリソースも持つノード上で
ocfs2-1リソースのみ始動します。
5 showで変更内容をレビューします。必要なリソースをすべて設定したこと
を確認するには、付録C OCFS2およびcLVMの設定例 (369 ページ)も参照し
てください。
6 すべて正しければ、commitで変更を送信し、exitでcrmライブ設定を終了
します。
284
高可用性ガイド
14.6 OCFS2ファイルシステム上で
クォータを使用する
OCFS2ファイルシステム上でクォータを使用するには、適切なクォータ機能
またはオプションを使用して、ファイルシステムを作成し、マウントします。
オプションはursquota (個々のユーザのためのクォータ)またはgrpquota
(グループのためのクォータ)です。これらの機能は後ほど、tunefs.ocfs2
を使用して、マウントされていないファイルシステムで有効にすることもで
きます。
ファイルシステムで適切なクォータ機能が有効にされている場合、ファイル
システムは、そのメタデータで、各ユーザ(または)グループが使用しているス
ペースの量とファイルの数を追跡します。OCFS2はクォータ情報をファイル
システムの内部メタデータとして扱うので、quotacheck(8)プログラムを実
行する必要はありません。すべての機能はfsck.ocf2、およびファイルシステム
ドライバ自体に組み込まれています。
各ユーザまたはグループに課せられている制限の強制を有効にするには、他
のファイルシステムでの場合と同様に、quotaon(8)を実行します。
パフォーマンス上の理由で、各クラスタノードはクォータの計算をローカル
に行い、この情報を、10秒ごとに共通の中央ストレージに同期するようになっ
ています。この間隔は、tunefs.ocfs2と、usrquota-sync-intervalお
よびgrpquota-sync-intervalオプションで調整することができます。
クォータ情報は必ずしも常に正確というわけではないので、複数のクラスタ
ノードを並列に運用している場合、ユーザまたはグループがクォータ制限を
いくらか超えることもあります。
14.7 詳細情報
OCFS2の詳細については、次のリンクを参照してください。
http://oss.oracle.com/projects/ocfs2/
OracleサイトにあるOCFS2プロジェクトのホームページ
OCFS2
285
http://oss.oracle.com/projects/ocfs2/documentation
プロジェクトドキュメントのホームページにある『OCFS2 User's Guide』
286
高可用性ガイド
DRBD
15
分散複製ブロックデバイス(DRBD*)を使用すると、IPネットワーク内の2つの
異なるサイトに位置する2つのブロックデバイスのミラーを作成できます。
OpenAISと共に使用すると、DRBDは分散高可用性Linuxクラスタをサポート
します。この章では、DRBDのインストールとセットアップの方法を示しま
す。
15.1 概念の概要
DRBDは、プライマリデバイス上のデータをセカンダリデバイスに、データの
両方のコピーが同一に保たれるような方法で複製します。これは、ネットワー
ク型のRAID 1と考えてください。DRBDは、データをリアルタイムでミラー
リングするので、そのレプリケーションは連続的に起こります。アプリケー
ションは、実際そのデータがさまざまなディスクに保存されるということを
知る必要はありません。
重要: 暗号化されないデータ
ミラー間のデータトラフィックは暗号化されません。データ交換を安全に
するには、接続に仮想プライベートネットワーク(VPN)ソリューションを導
入する必要があります。
DRBDは、Linuxカーネルモジュールであり、下端のI/Oスケジューラと上端の
ファイルシステムの間に存在しています(図15.1「Linux内でのDRBDの位
置」 (288 ページ)参照)。DRBDと通信するには、高レベルのコマンドdrbdadm
DRBD
287
を使用します。柔軟性を最大にするため、DRBDには、低レベルのツール
drbdsetupが付いてきます。
図 15.1 Linux内でのDRBDの位置
DRBDでは、Linuxでサポートされる任意のブロックデバイスを使用できます。
通常は次のデバイスです。
• パーティションまたは完全なハードディスク
• ソフトウェアRAID
• LVM (Logical Volume Manager)
• EVMS (Enterprise Volume Management System)
DRBDは、デフォルトでは、DRBDノード間の通信にTCPポート7788以上を使
用します。使用しているポートの通信がファイアウォールで許可されている
ことを確認してください。
まず、DRBDデバイスを設定してから、その上にファイルシステムを作成する
必要があります。ユーザデータに関することはすべて、rawデバイスではな
288
高可用性ガイド
く、/dev/drbd_Nデバイスを介してのみ実行される必要があります。これ
は、DRBDが、メタデータ用にrawデバイスの最後の部分を使用するからです。
rawデバイスを使用すると、データが矛盾する原因となります。
udevの統合により、/dev/drbd/by-res/RESOURCESの形式でシンボリック
リンクも取得されます。このリンクは、より簡単に使用でき、デバイスのマ
イナー番号を誤って記憶しないように安全対策が講じられています。
たとえば、rawデバイスのサイズが1024MBの場合、DRBDデバイスは、1023MB
しかデータ用に使用できません。70KBは隠され、メタデータ用に予約されて
います。/dev/drbdNを介した既存のキロバイトへのアクセスは、それがユー
ザデータ用でないので、すべて失敗します。
15.2 DRBDサービスのインストール
DRBDに必要なパッケージをインストールするには、パートI「インストール
およびセットアップ」 (1 ページ)で説明されているように、High Availability
Extensionアドオン製品をネットワーククラスタの両方のSUSE Linux Enterprise
Serverコンピュータにインストールします。High Availability Extensionをイン
ストールすると、DRBDプログラムファイルもインストールされます。
クラスタのスタックを完了する必要がなく、DRBDを使用したいだけの場合、
表15.1「DRBD RPMパッケージ」 (289 ページ)を参照してください。DRBDの
すべてのRPMパッケージのリストが含まれています。drbdパッケージは最
近、別々のパッケージに分けられました。
表 15.1 DRBD RPMパッケージ
ファイル名
説明
drbd
いくつかに分割された便利なパッ
ケージ
drbd-bash-completion
プログラマブルbash補完のサポー
ト(drbdadm用)
drbd-heartbeat
DRBD用Heartbeatリソースエージェ
ント(Heartbeat用にのみ必要)
DRBD
289
ファイル名
説明
drbd-kmp-default
DRBD用カーネルモジュール(必要)
drbd-kmp-xen
DRBD用Xenカーネルモジュール
drbd-udev
DRBD用のudev統合スクリプ
ト。/dev/drbd/by-resと/dev/
drbd/by-diskでDRBDデバイス
へのシンボリックリンクを管理し
ます。
drbd-utils
DRBD用管理ユーティリティ(必要)
drbd-pacemaker
DRBD用Pacemakerリソースエー
ジェント
drbd-xen
DRBD用Xenブロックデバイス管理
スクリプト
yast2-drbd
YaST DRBD環境設定(推奨)
drbdadmの操作を簡素化するには、RPMパッケージdrbd-bash-completion
にあるBash補完サポートを使用します。現在のシェルセッションでこのサポー
トを有効にするには、次のコマンドを挿入します。
root # source /etc/bash_completion.d/drbdadm.sh
root用に永続的に使用するには、ファイル/root/.bashrcを拡張し、前の
行を挿入します。
15.3 DRBDサービスの設定
注記: 必要な調整
次の手順では、サーバ名としてaliceとbobを使用し、クラスタリソース名と
してr0を使用します。aliceをプライマリノードとして設定し、/dev/sda1
290
高可用性ガイド
をストレージとして設定します。必ず、手順を変更して、ご使用のノード
名とファイルの名前を使用してください。
DRBDの設定を始める前に、Linuxノード内のブロックデバイスを準備し、(必
要な場合は)パーティション分割しておいてください。次の手順では、aliceと
bobという2つのノードがあり、それぞれがTCPポート7788を使用するものと
想定しています。ファイアウォールでこのポートが開いているようにしてく
ださい。
DRBDを手動で設定するには、次の手順に従います。
手順 15.1 DRBDの手動設定
1 クラスタがすでにDRBDを使用している場合は、クラスタを保守モード
にします。
root # crm configure property maintenance-mode=true
クラスタがすでにDRBDを使用している場合に、この手順をスキップす
ると、ライブ設定の構文エラーによってサービスがシャットダウンされ
ます。
2 rootユーザとしてログインします。
3 DRBDの環境設定ファイルを変更します。
3a ファイル/etc/drbd.confを開き、次の行を挿入します(これら
の行がない場合)。
include "drbd.d/global_common.conf";
include "drbd.d/*.res";
DRBD 8.3以降、環境設定ファイルは、複数のファイルに分割さ
れ、/etc/drbd.d/ディレクトリに保存されています。
3b /etc/drbd.d/global_common.confファイルを開きます。こ
のファイルには、すでにいくつかの事前定義値が含まれています。
startupセクションに移動し、次の3行を挿入します。
startup {
# wfc-timeout degr-wfc-timeout outdated-wfc-timeout
# wait-after-sb;
wfc-timeout 100;
degr-wfc-timeout 120;
}
DRBD
291
これらのオプションは、ブート時のタイムアウトを減らすために
使用します。詳細については、http://www.drbd.org/users
-guide-emb/re-drbdconf.htmlを参照してください。
3c ファイル/etc/drbd.d/r0.resを作成し、状況に合わせて行を
変更し、ファイルを保存します。
resource r0 {
device /dev/drbd0;
disk /dev/sda1;
meta-disk internal;
on alice {
address 192.168.1.10:7788;
}
on bob {
(292 ページ)
address 192.168.1.11:7788;
}
syncer {
rate 7M;
}
}
(292 ページ)
必要なサービスへのいくつかの関連付けを許可する名前。た
とえば、nfs、http、mysql_0、postgres_walなど。
DRBD用デバイス名とそのマイナー番号。
先に示した例では、マイナー番号0がDRBDに対して使用され
ています。udev統合スクリプトは、シンボリックリンク(/dev/
drbd/by-res/nfs/0)を提供します。または、設定のデバ
イスノード名を省略し、代わりに次のラインを使用します。
drbd0 minor 0 (/dev/は必要に応じて指定します)また
は/dev/drbd0
ノード間で複製されるrawデバイス。ただし、この例では、
デバイスは両方のノードで同じです。異なるデバイスが必要
な場合は、diskパラメータをonホストに移動します。
meta-diskパラメータには、通常、値internalが含まれます
が、メタデータを保持する明示的なデバイスを指定すること
もできです。詳細については、http://www.drbd.org/
users-guide-emb/ch-internals.html#s-metadataを
参照してください。
onセクションでは、この設定文が適用されるホストを記述し
ます。
292
高可用性ガイド
それぞれのノードのIPアドレスとポート番号。リソースごと
に、通常、7788から始まる別個のポートが必要です。
同期レート。このレートは、ディスク帯域幅およびネット
ワーク帯域幅の3分の1に設定します。これは、再同期を制限
するだけで、レプリケーションは制限しません。
4 環境設定ファイルの構文をチェックします。次のコマンドがエラーを返
す場合は、ファイルを検証します。
root # drbdadm dump all
5 Csync2(デフォルト)を設定している場合、DRBD設定ファイルは、同期に
必要なファイルのリストにすでに含まれています。同期するには、次の
コマンドを使用します。
root # csync2 -xv /etc/drbd.d/
Csync2を設定していない場合(または使用しない場合)には、DRBD設定
ファイルを手動で他のノードにコピーしてください。
root # scp /etc/drbd.conf bob:/etc/
scp /etc/drbd.d/* bob:/etc/drbd.d/
6 各ノードで次のコマンドを入力することにより、両方のシステムでメタ
データを初期化します。
root # drbdadm create-md r0
root # rcdrbd start
ディスクに、必要のなくなったファイルシステムがすでに含まれている
場合は、次のコマンドでファイルシステムの構造を破壊し、このステッ
プを繰り返します。
root #
dd if=/dev/zero of=/dev/sda1 count=16 bs=1M
7 次のコマンドを各ノードで入力して、DRBDステータスをチェックしま
す。
root # rcdrbd status
次のような出力が表示されます。
[... version string omitted ...]
m:res cs
ro
ds
p
DRBD
293
mounted fstype
0:r0
Connected
Secondary/Secondary
Inconsistent/Inconsistent
C
8 プライマリにするノード(この場合はalice)で再同期プロセスを開始しま
す。
root # drbdadm -- --overwrite-data-of-peer primary r0
9 rcdrbd statusを使用して、再びステータスをチェックすると、次の
ような結果が得られます。
...
m:res
0:r0
cs
Connected
ro
Primary/Secondary
ds
UpToDate/UpToDate
p
C
mounted
fstype
ds行のステータス(ディスクステータス)は、両方のノードでUpToDateで
ある必要があります。
10 DRBDデバイスの上にファイルシステムを作成します。たとえば、次の
ように指定します。
root # mkfs.ext3 /dev/drbd/by-res/r0/0
11 ファイルシステムをマウントして使用します。
root # mount /dev/drbd /mnt/
12 クラスタの保守モードフラグをリセットします。
root # crm configure property maintenance-mode=false
または、YaSTを使用してDRBDを設定するには、次の手順を実行します。
手順 15.2 YaSTを使用してDRBDを設定
1 YaSTを起動して、設定モジュール［高可用性］ > ［DRBD］を選択します。
すでにDRBDを設定していた場合、YaSTはそのことを警告します。YaSTは
設定を変更し、古いDRBD設定ファイルを*.YaSTsaveとして保存します。
［起動設定］ > ［ブート］のブートフラグは、そのままにしてください(デ
フォルトではoff)。Pacemakerがこのサービスを管理するので変更しないで
ください。
294
高可用性ガイド
2 リソースの実際の設定は、［ソース設定］で実行されます(図15.2「リソー
ス設定」 (295 ページ)を参照)。
図 15.2 リソース設定
［追加］をクリックして、新規リソースを作成します。次のパラメータは
2度設定する必要があります。
［リソース
名］
リソースの名前(必須)。
［Name (名
前)］
関連するノードのホスト名。
［アドレス:
ポート］
それぞれのノードのIPアドレスとポート番号(デフォ
ルトは7788)。
［デバイス］
複製されたデータにアクセスするためのブロックデ
バイスパス。デバイスにマイナー番号が使用されて
いる場合は、関連付けられたブロックデバイスの名
前は/dev/drbdXになることが普通です。Xはデバ
DRBD
295
イスのマイナー番号です。デバイスにマイナー番号
が使用されていない場合は、必ずデバイス名の後に
minor 0を追記します。
［ディスク］
両方のノード間で複製されるデバイス。
［メタディス
ク］
［メタディスク］は、値internalに設定されるか、
またはインデックスで拡張された、drbdで必要なメ
タデータを保持する明示的なデバイスを指定しま
す。
複数のdrbdリソースに実際のデバイスを使用するこ
ともできます。たとえば、最初のリソースに対して
［メタディスク］が/dev/sda6[0]の場合、/dev/
sda6[1]を2番目のリソースに使用できます。ただ
し、このディスク上で各リソースについて少なくと
も128MBのスペースが必要です。メタデータの固定
サイズによって、複製できる最大データサイズが制
限されます。
これらのオプションはすべて、/usr/share/doc/packages/drbd
-utils/drbd.confファイルの例とdrbd.conf(5)のマニュアルページ
で説明されています。
3 Csync2(デフォルト)を設定している場合、DRBD設定ファイルは、同期に必
要なファイルのリストにすでに含まれています。同期するには、次のコマ
ンドを使用します。
root # csync2 -xv /etc/drbd.d/
Csync2を設定していない場合(または使用しない場合)は、DRBD設定ファイ
ルを手動で他のノードにコピーします(ここでは、bobという名前の別のノー
ドにコピーします)。
root # scp /etc/drbd.conf bob:/etc/
scp /etc/drbd.d/* bob:/etc/drbd.d/
4 各ノードで、次のように入力して、DRBDサービスを両方のシステム上で
初期化し、起動します。
296
高可用性ガイド
root # drbdadm create-md r0
root # rcdrbrd start
5 alice上で次のコマンドの入力により、aliceをプライマリノードとして
設定します。
root # drbdsetup /dev/drbd0 primary --overwrite-data-of-peer
6 各ノードで、次のコマンドを入力して、DRBDサービスのステータスを
チェックします。
rcdrbd status
続行する前に、両方のノードのブロックデバイスが完全に同期されるまで
待機します。rcdrbd statusコマンドを繰り返して、同期の進捗を追跡
します。
7 両方のノードのブロックデバイスが完全に同期されたら、希望のファイル
システムで、プライマリノード上のDRBDデバイスをフォーマットします。
任意のLinuxファイルシステムを使用できます。/dev/drbd/by
-res/RESOURCE名を使用することをお勧めします。
15.4 DRBDサービスのテスト
インストールと設定のプロシージャが予期どおりの結果となった場合は、
DRBD機能の基本的なテストを実行できます。このテストは、DRDBソフト
ウェアの機能を理解する上でも役立ちます。
1 alice上でDRBDサービスをテストします。
1a 端末コンソールを開き、rootとしてログインします。
1b aliceにマウントポイント(/srv/r0など)を作成します。
root # mkdir -p /srv/r0
1c drbdデバイスをマウントします。
root # mount -o rw /dev/drbd0 /srv/r0
DRBD
297
1d プライマリノードからファイルを作成します。
root # touch /srv/r0/from_alice
1e aliceでディスクをマウント解除します。
root # umount /srv/r0
1f aliceで次のコマンドを入力して、aliceのDRBDサービスを降格しま
す。
root # drbdadm secondary
2 bob上でDRBDサービスをテストします。
2a 端末コンソールを開き、bobでrootとしてログインします。
2b bobで、DRBDサービスをプライマリに昇格します。
root # drbdadm primary
2c bobで、bobがプライマリかどうかチェックします。
root # rcdrbd status
2d bobで、/srv/r0mountなどのマウントポイントを作成します。
root # mkdir /srv/r0mount
2e bobで、DRBDデバイスをマウントします。
root # mount -o rw /dev/drbd_r0 /srv/r0mount
2f aliceで作成したファイルが存在していることを確認します。
root # ls /srv/r0
/srv/r0mount/from_aliceファイルが一覧に表示されている必
要があります。
3 サービスが両方のノードで稼動していれば、DRBDの設定は完了です。
298
高可用性ガイド
4 再度、aliceをプライマリとして設定します。
4a bobで次のコマンドを入力して、bobのディスクをマウント解除しま
す。
root # umount /srv/r0
4b bobで次のコマンドを入力して、bobのDRBDサービスを降格します。
root # drbdadm secondary
4c aliceで、DRBDサービスをプライマリに昇格します。
root # drbdadm primary
4d aliceで、aliceがプライマリかどうかチェックします。
rcdrbd status
5 サービスを自動的に起動させ、サーバに問題が発生した場合はフェールオー
バーさせるためには、OpenAISでDRBDを高可用性サービスとして設定でき
ます。OpenAIS for SUSE Linux Enterprise 11のインストールと設定について
は、パートII「設定および管理」 (57 ページ)を参照してください。
15.5 DRBDのチューニング
DRBDをチューニングするには、いくつかの方法があります。
1. メタデータ用には外部ディスクを使用します。これは便利ですが、保守作
業は煩雑になります。
2. DRBDデバイスの先読み設定を変更するudevルールを作成します。次の行を
ファイル/etc/udev/rules.d/82-dm-ra.rulesに保存し、read_ahead_kb
値を独自のワークロードに変更します。
ACTION=="add", KERNEL=="dm-*", ATTR{bdi/read_ahead_kb}="4100"
このラインはLVMを使用する場合にのみ有効です。
DRBD
299
3. sysctlを介して受信および送信バッファ設定を変更することで、ネット
ワーク接続を調整します。
4. DRBD設定でmax-buffers、max-epoch-size、またはその両方を変更し
ます。
5. IOパターンに応じて、al-extentsの値を増やします。
6. ハードウェアRAIDコントローラとBBU (「バッテリバックアップユニット」)
を併用する場合、no-disk-flushes、no-disk-barrier、および
no-md-flushesの設定が有効な場合があります。
7. ワークロードに従って読み込みバランスを有効にします。詳細については、
http://blogs.linbit.com/p/256/read-balancing/を参照してく
ださい。
15.6 DRBDのトラブルシュート
DRBDセットアップには、多数の異なるコンポーネントが使用され、別のソー
スから問題が発生することがあります。以降のセクションでは、一般的なシ
ナリオをいくつか示し、さまざまなソリューションを推奨します。
15.6.1 環境設定
初期のDRBDセットアップが予期どおりに機能しない場合は、おそらく、環境
設定に問題があります。
環境設定の情報を取得するには:
1 端末コンソールを開き、rootとしてログインします。
2 drbdadmに-dオプションを指定して、環境設定ファイルをテストします。
入力次のコマンドを入力します。
root # drbdadm -d adjust r0
adjustオプションのドライ実行では、drbdadmは、DRBDリソースの実際
の設定を使用中のDRBD環境設定ファイルと比較しますが、コールは実行
300
高可用性ガイド
しません。出力をレビューして、エラーのソースおよび原因を確認してく
ださい。
3 /etc/drbd.d/*ファイルとdrbd.confファイルにエラーがある場合は、
そのエラーを修正してから続行してください。
4 パーティションと設定が正しい場合は、drbdadmを-dオプションなしで、
再度実行します。
root # drbdadm adjust r0
このコマンドは、環境設定ファイルをDRBDリソースに適用します。
15.6.2 ホスト名
DRBDの場合、ホスト名の大文字と小文字が区別され(Node0はnode0とは異
なるホストであるとみなされる)、カーネルに格納されているホスト名と比較
されます(uname -n出力を参照)。
複数のネットワークデバイスがあり、専用ネットワークデバイスを使用した
い場合、おそらく、ホスト名は使用されたIPアドレスに解決されません。こ
の場合は、パラメータdisable-ip-verificationを使用します。
15.6.3 TCPポート7788
システムがピアに接続できない場合は、ローカルファイアウォールに問題の
ある可能性があります。DRBDは、デフォルトでは、TCPポート7788を使用
して、もう一方のノードにアクセスします。このポートを両方のノードから
アクセスできるかどうか確認してください。
15.6.4 DRBDデバイスが再起動後に破損した
DRBDサブシステムが実際のどのデバイスが最新データを保持しているか認識
していない場合、スプリットブレイン受験に変更されます。この場合、それ
ぞれのDRBDサブシステムがセカンダリとして機動され、互いに接続しませ
ん。この場合、ログ記録データに、次のメッセージが出力されることがあり
ます。
DRBD
301
Split-Brain detected, dropping connection!
この状況を解決するには、廃棄するデータを持つノードで、次のコマンドを
入力します。
root # drbdadm secondary r0
root # drbdadm -- --discard-my-data connect r0
最新のデータを持つノードで、次のコマンドを入力します。
root # drbdadm connect r0
このコマンドは、あるノードのデータをピアのデータで上書きすることによっ
て問題を解決するため、両方のノードで一貫したビューが得られます。
15.7 詳細情報
DRBDについては、次のオープンソースリソースを利用できます。
• プロジェクトホームページhttp://www.drbd.org。
• 詳細については、Highly Available NFS Storage with DRBD and Pacemaker
(↑Highly Available NFS Storage with DRBD and Pacemaker)を参照してくださ
い。
• http://clusterlabs.org/wiki/DRBD_HowTo_1.0(Linux Pacemaker
Cluster Stack Projectによる)。
• 配布パッケージで利用できるDRBDのマニュアルページは次のとおりです。
drbd(8)、drbddisk(8)、drbdsetup(8)、drbdsetup(8)、drbdadm。
(8)、drbd.conf(5)
• コメント付きのDRBD構成例が、/usr/share/doc/packages/drbd/
drbd.confにあります。
• さらに、クラスタ間のストレージ管理を容易にするために、「DRBDManager」(http://blogs.linbit.com/p/666/drbd-manager)に関す
る最新の通知を参照してください。
302
高可用性ガイド
Cluster Logical Volume
Manager(cLVM)
16
クラスタ上の共有ストレージを管理する場合、ストレージサブシステムに行っ
た変更を各ノードに伝える必要があります。Linux Volume Manager 2 (LVM2)
はローカルストレージの管理に多用されており、クラスタ全体のボリューム
グループのトランスペアレントな管理をサポートするために拡張されていま
す。クラスタ化されたボリュームグループを、ローカルストレージと同じコ
マンドで管理できます。
16.1 概念の概要
クラスタLVMは、さまざまなツールと連携します。
分散ロックマネージャ(DLM:Distributed Lock Manager)
cLVMのためにディスクアクセスを調整します。
論理ボリュームマネージャ2(LVM2: Logical Volume Manager2)
1つのファイルシステムをいくつかのディスクに柔軟に分散することがで
きます。LVMは、ディスクスペースの仮想プールを提供します。
クラスタ化論理ボリュームマネージャ(cLVM: Clustered Logical Volume Manager)
すべてのノードが変更を知ることができるように、LVMメタデータへの
アクセスを調整します。cLVMは、共有データ自体へのアクセスは調整し
ません。これをcLVMができるようにするには、OCFS2などのクラスタ対
応アプリケーションをcLVMの管理対象ストレージの上に設定する必要が
あります。
Cluster Logical Volume Manager(cLVM)
303
16.2 cLVMの環境設定
ご使用のシナリオによっては、次のレイヤを使用して、ｃLVMでRAID 1デバ
イスを作成することができます。
• LVM ファイルシステムのサイズを増減したり、物理ストレージを追加し
たり、ファイルシステムのスナップショットを作成する場合に、高い柔軟
性を提供するソリューションです。この方法については、16.2.3項「シナリ
オ - SAN上でiSCSIを使用するｃLVM」 (309 ページ)に説明があります。
• DRBD RAID 0 (ストライピング)とRAID 1 (ミラーリング)のみを提供しま
す。最後の方式については、16.2.4項「シナリオ - DRBDを使用する
ｃLVM」 (314 ページ)に説明があります。
• MDデバイス（LinuxソフトウェアRAIDまたはmdadm）このソリューショ
ンは、すべてのRAIDレベルを提供しますが、まだクラスタはサポートして
いません。
MIDデバイス(Linux Software RAIDまたはmdadm)は、すべてのRAIDレベルを
提供しますが、まだクラスタはサポートしていません。したがって、先に挙
げたリストには含まれていません。
次の前提条件を満たしていることを確認してください。
• 共有ストレージデバイス(Fibre Channel、FCoE、SCSI、iSCSI SAN、DRBD*
で提供されているデバイスなど)が使用できること
• DRBDの場合は、両方のノードがプライマリであること(以降の手順で説明)。
• LVM2のロックタイプがクラスタを認識するかどうか確認するこ
と。/etc/lvm/lvm.conf内のキーワードlocking_typeに値 3がデフォ
ルトで含まれている必要があります。必要な場合は、この設定をすべての
ノードにコピーします。
注記: 最初にクラスタリソースを作成する
16.2.2項「クラスタリソースの作成」 (307 ページ)に説明されているように、
最初にクラスタリソースを作成してから、LVMボリュームを作成します。
そうしないと、後でボリュームを削除できなくなります。
304
高可用性ガイド
16.2.1 cmirrordの構成
クラスタのミラーログ情報を追跡するには、cmirrordデーモンを使用しま
す。このデーモンが実行されていないと、クラスタはミラーリングできませ
ん。
ここでは、/dev/sdaと/dev/sdbが共有ストレージデバイスだとします。必
要な場合は、これらを独自のデバイス名に置き換えます。次の手順に従いま
す。
1 2つ以上のノードを使用してクラスタを作成します。
2 dlm、clvmd、およびSTONITHを実行するために、クラスタを構成します。
root # crm configure
crm(live)configure# primitive clvmd ocf:lvm2:clvmd \
op stop interval="0" timeout="100" \
op start interval="0" timeout="90" \
op monitor interval="20" timeout="20"
crm(live)configure# primitive dlm ocf:pacemaker:controld \
op start interval="0" timeout="90" \
op stop interval="0" timeout="100" \
op monitor interval="60" timeout="60"
crm(live)configure# primitive sbd_stonith stonith:external/sbd
crm(live)configure# group base-group dlm clvmd
crm(live)configure# clone base-clone base-group \
meta interleave="true"
3 exitでcrmshを終了し、変更内容をコミットします。
4 クラスタ化されたボリュームグループ (VG) を作成します。
root # pvcreate /dev/sda /dev/sdb
root # vgcreate -cy vg /dev/sda /dev/sdb
5 ミラーログの論理ボリューム (LV) をクラスタ内に作成します。
root # lvcreate -nlv -m1 -l10%VG vg --mirrorlog mirrored
6 lvsを使用して進捗状況を表示します。パーセンテージの数値が100%に到
達したら、ミラーディスクは正しく同期化されたということです。
7 クラスタ化されたボリューム/dev/vg/lvをテストするには、次の手順に
従います。
Cluster Logical Volume Manager(cLVM)
305
7a /dev/vg/lvを読み込むか、ここに書き込みます。
7b lvchange -anでLVを非アクティブ化します。
7c lvchange -ayでLVをアクティブ化します。
7d lvconvertを使用してミラーログをディスクログに変換します。
8 別のクラスタVGにミラーログのLVを作成します。これは前のものとは別
のボリュームグループです。
現在のcLVMは、ミラーサイドごとに1つの物理ボリューム (PV) しか処理でき
ません。1つのミラーが実際には、連結またはストライプ化の必要がある複数
のPVで構成されている場合、lvcreateはこのことを理解できません。この
ため、lvcreateおよびcmirrordメタデータは、複数のPVを1つのサイドに
「グループ化」することを理解する必要があり、事実上RAID10をサポートす
ることになります。
cmirrordに対してRAID10をサポートするには、次の手順を使用します(/dev/
sdaと/dev/sdbは共有ストレージデバイスだとします)。
1 ボリュームグループ (VG) を作成します。
root # pvcreate /dev/sda /dev/sdb
root # vgcreate vg /dev/sda /dev/sdb
2 ファイル/etc/lvm/lvm.confを開き、allocationセクションに移動し
ます。次の行を設定して、ファイルを保存します。
mirror_legs_require_separate_pvs = 1
3 PVにタグを追加します。
root # pvchange --addtag @a /dev/sda
root # pvchange --addtag @b /dev/sdb
タグは、ストレージオブジェクトのメタデータに割り当てられる順序付け
のないキーワードまたは用語です。タグを使用すると、順序付けのないタ
グのリストをLVMストレージオブジェクトのメタデータに添付することに
よって、それらのオブジェクトのコレクションを有用になるように分類で
きます。
306
高可用性ガイド
4 タグを一覧します。
root # pvs -o pv_name,vg_name,pv_tags /dev/sd{a,b}
次の出力を受信します。
PV
VG
PV Tags
/dev/sda vgtest a
/dev/sdb vgtest b
LVMに関する詳細情報が必要な場合は、『SUSE Linux Enterprise Server 11 SP4
ストレージ管理ガイド』の「LVM設定」の章を参照してください。http://
www.suse.com/documentation/から入手できます。
16.2.2 クラスタリソースの作成
cLVMを使用するためのクラスタ準備には次の基本的な手順が含まれます。
• DLMリソースを作成する (307 ページ)
• LVMおよびcLVMリソースの作成 (308 ページ)
手順 16.1 DLMリソースを作成する
注記: cLVMおよびOCFS2両方のためのDLMリソース
cLVMおよびOCFS2は両方とも、クラスタ内のすべてのノード上で実行する
DLMリソースを必要とするため、通常はクローンとして設定されます。
OCFS2およびcLVMの両方を含むセットアップがある場合、OCFS2およびcLVM
の両方に1つのDLMリソースを設定することで十分です。
1 シェルを起動して、rootとしてログインします。
2 crm configureを実行します。
3 showでクラスタリソースの現在の設定を確認します。
4 すでにDLMリソース(および対応するベースグループおよびベースクロー
ン)を設定済みである場合、手順16.2「LVMおよびcLVMリソースの作
成」 (308 ページ)で継続します。
Cluster Logical Volume Manager(cLVM)
307
そうでない場合は、手順14.1「DLMリソースおよびO2CBリソースの設
定」 (278 ページ)で説明されているように、DLMリソース、および対応する
ベースグループとベースクローンを設定します。
5 crmライブ設定をexitで終了します。
手順 16.2 LVMおよびcLVMリソースの作成
1 シェルを起動して、rootとしてログインします。
2 crm configureを実行します。
3 次のとおり、cLVMリソースを設定します。
crm(live)configure# primitive clvm ocf:lvm2:clvmd \
params daemon_timeout="30"
4 次のとおり、ボリュームグループのLVMリソースを設定します。
crm(live)configure# primitive vg1 ocf:heartbeat:LVM \
params volgrpname="cluster-vg" \
op monitor interval="60" timeout="60"
5 ボリュームグループを1つのノード上で単独にアクティブ化する場合、以下
で説明されるようにLVMリソースを設定し、ステップ 6 (308 ページ)を省略
します。
crm(live)configure# primitive vg1 ocf:heartbeat:LVM \
params volgrpname="cluster-vg" exclusive="yes" \
op monitor interval="60" timeout="60"
この場合、cLVMは、非クラスタ化アプリケーション用の追加保護手段と
して、VG内のすべての論理ボリュームが複数のノード上でアクティブ化さ
れないよう保護します。
6 cLVMおよびLVMリソースがクラスタ全体でアクティブ化されていること
を確認するには、手順14.1「DLMリソースおよびO2CBリソースの設
定」 (278 ページ)で作成したベースグループに両方のプリミティブを追加し
ます。
6a 入力
crm(live)configure# edit base-group
308
高可用性ガイド
6b Viエディタが開いたら、そこに次のようにグループを変更し、変更
を保存します。
crm(live)configure# group base-group dlm clvm vg1 ocfs2-1
重要: OCFS2がないセットアップ
セットアップにOCFS2が含まれない場合、ベースグループから
ocfs2-1プリミティブを省略します。oc2cbプリミティブは、OCFS2
を使用する、しないに関わらず、設定してグループ内に含めるこ
とができます。
7 showで変更内容をレビューします。必要なリソースをすべて設定したこと
を確認するには、付録C OCFS2およびcLVMの設定例 (369 ページ)も参照し
てください。
8 すべて正しければ、commitで変更を送信し、exitでcrmライブ設定を終了
します。
16.2.3 シナリオ - SAN上でiSCSIを使用する
ｃLVM
次のシナリオでは、iSCSIターゲットをいくつかのクライアントにエクスポー
トする2つのSANボックスを使用します。一般的なアイデアが、図16.1「ｃLVM
によるiSCSIのセットアップ」 (310 ページ)で説明されています。
Cluster Logical Volume Manager(cLVM)
309
図 16.1 ｃLVMによるiSCSIのセットアップ
警告: データ損失
以降の手順を実行すると、ディスク上のデータはすべて破壊されます。
まず、1つのSANボックスだけ設定します。各SANボックスは、そのiSCSIター
ゲットをエクスポートする必要があります。次の手順に従います。
手順 16.3 iSCSIターゲット(SAN上)を設定する
1 YaSTを実行し、［ネットワークサービス］ > ［iSCSIターゲット］の順に
クリックしてiSCSIサーバモジュールを起動します。
2 コンピュータがブートするたびにiSCSIターゲットを起動したい場合は、
［ブート時］を選択し、そうでない場合は、［手動］を選択します。
3 ファイアウォールが実行中の場合は、［ファイアウォールでポートを開く］
を有効にします。
310
高可用性ガイド
4 ［グローバル］タブに切り替えます。認証が必要な場合は、受信または送
信(あるいはその両方の)認証を有効にします。この例では、［認証なし］
を選択します。
5 新しいiSCSIターゲットを追加します。
5a ［ターゲット］タブに切り替えます。
5b ［追加］をクリックします。
5c ターゲットの名前を入力します。名前は、次のようにフォーマット
されます。
iqn.DATE.DOMAIN
フォーマットに関する詳細は、セクション3.2.6.3.1のタイプ「iqn」
(iSCSI修飾名)(http://www.ietf.org/rfc/rfc3720.txt)を参照
してください。
5d より説明的な名前にしたい場合は、さまざまなターゲットで一意で
あれば、識別子を変更できます。
5e ［追加］をクリックします。
5f ［パス］にデバイス名を入力し、［Scsiid］を使用します。
5g ［次へ］を2回クリックします。
6 警告ボックスで［はい］を選択して確認します。
7 環境設定ファイル/etc/iscsi/iscsi.confを開き、パラメータ
node.startupをautomaticに変更します。
次の手順に従って、iSCSIイニシエータを設定します。
手順 16.4 iSCSIイニシエータを設定する
1 YaSTを実行し、［ネットワークサービス］ > ［iSCSIイニシエータ］の順
にクリックします。
Cluster Logical Volume Manager(cLVM)
311
2 コンピュータがブートするたびに、iSCSIイニシエータを起動したい場合
は、［ブート時］を選択し、そうでない場合は、［手動］を選択します。
3 ［検出］タブに切り替え、［検出］ボタンをクリックします。
4 自分のIPアドレスとiSCSIターゲットのポートを追加します(手順16.3「iSCSI
ターゲット(SAN上)を設定する」 (310 ページ)参照)。通常は、ポートを既定
のままにし、デフォルト値を使用できます。
5 認証を使用する場合は、受信および送信用のユーザ名およびパスワードを
挿入します。そうでない場合は、［認証なし］を選択します。
6 ［次へ］を選択します。検出された接続が一覧されます。
7 iSCSIイニシエータが正常に起動しているかかどうかをテストするには、表
示されたターゲットのいずれかを選択して［ログイン］をクリックします。
手順 16.5 LVMボリュームグループを作成する
1 手順16.4「iSCSIイニシエータを設定する」 (311 ページ)のiSCSIイニシエー
タを実行したノードの1つで、rootシェルを開きます。
2 ディスク/dev/sddおよび/dev/sdeでコマンドpvcreateを使用して、
LVM用に物理ボリュームを準備します。
root # pvcreate /dev/sdd
root # pvcreate /dev/sde
3 両方のディスク上でクラスタ対応のボリュームグループを作成します。
root # vgcreate --clustered y clustervg /dev/sdd /dev/sde
4 必要に応じて、論理ボリュームを作成します。
root # lvcreate --name clusterlv --size 500M clustervg
5 物理ボリュームをpvdisplayで確認します。
--- Physical volume --PV Name
VG Name
PV Size
Allocatable
PE Size (KByte)
Total PE
312
高可用性ガイド
/dev/sdd
clustervg
509,88 MB / not usable 1,88 MB
yes
4096
127
Free PE
Allocated PE
PV UUID
127
0
52okH4-nv3z-2AUL-GhAN-8DAZ-GMtU-Xrn9Kh
--- Physical volume --PV Name
/dev/sde
VG Name
clustervg
PV Size
509,84 MB / not usable 1,84 MB
Allocatable
yes
PE Size (KByte)
4096
Total PE
127
Free PE
127
Allocated PE
0
PV UUID
Ouj3Xm-AI58-lxB1-mWm2-xn51-agM2-0UuHFC
6 ボリュームグループをvgdisplayで確認します。
--- Volume group --VG Name
System ID
Format
Metadata Areas
Metadata Sequence No
VG Access
VG Status
Clustered
Shared
MAX LV
Cur LV
Open LV
Max PV
Cur PV
Act PV
VG Size
PE Size
Total PE
Alloc PE / Size
Free PE / Size
VG UUID
clustervg
lvm2
2
1
read/write
resizable
yes
no
0
0
0
0
2
2
1016,00 MB
4,00 MB
254
0 / 0
254 / 1016,00 MB
UCyWw8-2jqV-enuT-KH4d-NXQI-JhH3-J24anD
ボリュームを作成してリソースを起動すると、/dev/dm-*という名前で新し
いデバイスが作成されています。LVMリソースの上でクラスタ化されたファ
イルシステム(たとえば、OCFS)を使用することをお勧めします。詳細につい
ては、第14章 OCFS2 (275 ページ)を参照してください。
Cluster Logical Volume Manager(cLVM)
313
16.2.4 シナリオ - DRBDを使用するｃLVM
市、国、または大陸の各所にデータセンターが分散している場合は、次のシ
ナリオを使用できます。
手順 16.6 DRBDでクラスタ対応ボリュームグループを作成する
1 プライマリ/プライマリDRBDリソースを作成する
1a まず、手順15.1「DRBDの手動設定」 (291 ページ)の説明に従って、
DRBDデバイスをプライマリ/セカンダリとしてセットアップします。
ディスクの状態が両方のノードでup-to-dateであることを確認し
ます。これは、cat /proc/drbdまたはrcdrbd statusで確認しま
す。
1b 次のオプションを環境設定ファイル(通常は、/etc/drbd.d/r0.res)
に追加します。
resource r0 {
startup {
become-primary-on both;
}
net {
allow-two-primaries;
}
...
}
1c 変更した設定ファイルをもう一方のノードにコピーします。たとえ
ば、次のように指定します。
root # scp /etc/drbd.d/r0.res venus:/etc/drbd.d/
1d 両方のノードで、次のコマンドを実行します。
root # drbdadm disconnect r0
root # drbdadm connect r0
root # drbdadm primary r0
1e ノードのステータスをチェックします。
root # cat /proc/drbd
...
0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----
314
高可用性ガイド
2 clvmdリソースをペースメーカーの環境設定でクローンとして保存し、DLM
クローンリソースに依存させます。詳細については、手順16.1「DLMリソー
スを作成する」 (307 ページ)を参照してください。次に進む前に、クラスタ
でこれらのリソースが正しく機動していることを確認してください。
crm_monまたはWebインタフェースを使用して、実行中のサービスを確認
できます。
3 pvcreateコマンドで、LVM用に物理ボリュームを準備します。たとえ
ば、/dev/drbd_r0デバイスでは、コマンドは次のようになります。
root # pvcreate /dev/drbd_r0
4 クラスタ対応のボリュームグループを作成します。
root # vgcreate --clustered y myclusterfs /dev/drbd_r0
5 必要に応じて、論理ボリュームを作成します。論理ボリュームのサイズは
変更できます。たとえば、次のコマンドで、4GBの論理ボリュームを作成
します。
root # lvcreate --name testlv -L 4G myclusterfs
6 VG内の論理ボリュームは、ファイルシステムのマウントまたはraw用とし
て使用できるようになりました。論理ボリュームを使用しているサービス
にコロケーションのための正しい依存性があることを確認し、VGをアク
ティブ化したら論理ボリュームの順序付けを行います。
このような設定手順を終了すると、LVM2の環境設定は他のスタンドアロン
ワークステーションと同様に行えます。
16.3 有効なLVM2デバイスの明示的な
設定
複数のデバイスが同じ物理ボリュームの署名を共有していると思われる場合
(マルチパスデバイスやdrbdなどのように)、LVM2がPVを走査するデバイスを
明示的に設定しておくことをお勧めします。
Cluster Logical Volume Manager(cLVM)
315
たとえばコマンドvgcreateがミラーブロックデバイスの代わりに物理デバ
イスを使用すると、DRBDは混乱してしまい、DRBDのスプリットブレイン状
態が発生する場合があります。
LVM2用の単一のデバイスを非アクティブ化するには、次の手順に従います。
1 ファイル/etc/lvm/lvm.confを編集し、filterから始まる行を検索し
ます。
2 そこに記載されているパターンは正規表現として処理されます。冒頭の
「a」は走査にデバイスパターンを受け入れることを、冒頭の「r」はその
デバイスパターンのデバイスを拒否することを意味します。
3 /dev/sdb1という名前のデバイスを削除するには、次の表現をフィルタ
ルールに追加します。
"r|^/dev/sdb1$|"
完全なフィルタ行は次のようになります。
filter = [ "r|^/dev/sdb1$|", "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|",
"a/.*/" ]
DRBDとMPIOデバイスは受け入れ、その他のすべてのデバイスは拒否する
フィルタ行は次のようになります。
filter = [ "a|/dev/drbd.*|", "a|/dev/.*/by-id/dm-uuid-mpath-.*|", "r/.*/"
]
4 環境設定ファイルを書き込み、すべてのクラスタノードにコピーします。
16.4 詳細
詳細な情報は、http://www.clusterlabs.org/wiki/Help:Contents
にあるPacemakerメーリングリストから取得できます。
cLVMのFAQのオフィシャルサイトはhttp://sources.redhat.com/
cluster/wiki/FAQ/CLVMです。
316
高可用性ガイド
ストレージ保護
17
High Availabilityクラスタスタックでは、データの整合性の保護が最優先され
ます。これは、データストレージへの未調整の同時アクセスを防止すること
によって達成されます。たとえば、Ext3ファイルシステムは、クラスタに一
回だけマウントされ、OCFS2ボリュームは、他のクラスタノードとの調整が
可能になるまでマウントされません。正常に機能するクラスタでは、Pacemaker
によって、リソースがそれらの同時並行性の制限を超えてアクティブである
かどうかが検出され、復元が開始されます。さらに、そのポリシーエンジン
がそれらの制限を超えることは決してありません。
ただし、ネットワークのパーティション分割やソフトウェアの誤動作により、
いくつものコーディネータが選択される状況となる可能性があります。この
いわゆるスプリットブレインシナリオが発生した場合は、データが破損する
ことがあります。したがって、このリスクを軽減するため、クラスタスタッ
クには、いくつもの保護レイヤが追加されています。
この目的に貢献する第一のコンポーネントは、IOフェンシング/STONITHで
す。これにより、ストレージアクティベーション以前の他のすべてのアクセ
スが確実に終了されるからです。その他のメカニズムとしては、管理やアプ
リケーションの欠陥に対してシステムを保護するcLVM2の排他的アクティベー
ションやOCFS2のファイルロッキングサポートがあります。これらをご使用
のセットアップに適合するように組み合わせると、スプリットブレインシナ
リオの悪影響を確実に防止できます。
この章では、ストレージ自体を活用するIOフェンシングについて説明し、次
に、排他的ストレージアクセスを確保する追加保護レイヤについて説明しま
す。これら2つのメカニズムを組み合わせると、より高度な保護を実現できま
す。
ストレージ保護
317
17.1 ストレージベースのフェンシング
1つ以上のSTONITHブロックデバイス(SBD)、watchdogサポート、
external/sbd STONITHエージェントを使用することで、スプリットブレイ
ンシナリオを確実に回避することができます。
17.1.1 概要
すべてのノードが共有ストレージへのアクセスを持つ環境で、デバイスの小
さなパーティションをSBDで使用できるようにフォーマットします。パーティ
ションのサイズは、使用されるディスクのブロックサイズによって異なりま
す(512バイトのブロックサイズの標準SCSIディスクには1MB、4KBブロック
サイズのDASDディスクには4MB必要です)。SBDは、そのデーモンの設定後、
クラスタスタックの他のコンポーネントが起動される前に各ノードでオンラ
インになります。SBDデーモンは、他のすべてのクラスタコンポーネントが
シャットダウンされた後で終了されます。したがって、クラスタリソースが
SBDの監督なしでアクティブになることはありません。
このデーモンは、自動的に、パーティション上のメッセージスロットの1つを
自分自身に割り当て、自分へのメッセージがないかどうか、そのスロットを
絶えず監視します。デーモンは、メッセージを受信すると、ただちに要求に
従います(フェンシングのための電源切断や再起動サイクルの開始など)。
デーモンは、ストレージデバイスへの接続性を絶えず監視し、パーティショ
ンが到達不能になった場合は、デーモン自体が終了します。このため、デー
モンがフェンシングメッセージから切断されることはありません。これは、
クラスタデータが別のパーティション上の同じ論理ユニットにある場合、追
加障害ポイントになることはありません。ストレージ接続を失えば、ワーク
ロードは終了します。
保護は、watchdogサポートによって増大します。近代的なシステムは、ソ
フトウェアコンポーネントによって「チックル」または「フィード」される
必要のあるhardware watchdogをサポートします。ソフトウェアコンポー
ネント(通常はデーモン)は、watchdogに定期的にサービスパルスを書き込みま
す。デーモンがwatchdogへのフィードを停止する場合、ハードウェアはシス
テムの再起動を強制します。この機能は、SBDプロセス自体の障害(IOエラー
で終了またはスタックするなど)に対する保護を提供します。
318
高可用性ガイド
Pacemaker統合が有効になっている場合、デバイスの過半数が失われてもSBD
はセルフフェンスを行いません。たとえば、クラスタにA、B、Cの3つのノー
ドが含まれており、ネットワーク分割によってAには自分自身しか表示でき
ず、BとCはまだ通信可能な状態であるとします。この場合、2つのクラスタ
パーティションが存在し、1つは過半数(B、C)であるためにクォーラムがあ
り、もう1つにはクォーラムがない(A)ことになります。過半数のフェンシン
グデバイスに到達できないときにこれが発生した場合、ノードAはすぐに自ら
ダウンしますが、BとCは引き続き実行されます。
17.1.2 SBDデバイスの数
SBDは、1～3台のデバイスの使用をサポートします。
1台のデバイス
最も単純な実装です。すべてのデータが同じ共有ストレージ上にあるクラ
スタに適しています。
2台のデバイス
この設定は、主に、ホストベースのミラーリングを使用しているものの3
つ目のストレージデバイスが使用できない環境で役立ちます。1つのミラー
ログにアクセスできなくなっても、SBDは終了せず、クラスタは引き続き
実行できます。ただし、SBDにはストレージの非同期分割を検出できるだ
けの情報が与えられていないので、ミラーログが1つだけ使用可能なとき
にもう一方をフェンスすることはありません。つまり、ストレージアレイ
のいずれかがダウンしたときに、2つ目の障害に自動的に耐えることはで
きません。
3台のデバイス
最も信頼性の高い設定です。障害または保守による1台のデバイスの機能
停止から回復できます。SBDは複数のデバイスが失われた場合のみ自らを
終了させます。2つ以上のデバイスにまだアクセス可能であれば、フェン
シングメッセージを正しく送信することができます。
この設定は、ストレージが1つのアレイに制約されていない、比較的複雑
なシナリオに適しています。ホストベースのミラーリングソリューション
では、1つのミラーログに1つのSBDを設定し(自分自身はミラーしない)、
iSCSI上に追加のタイブレーカを設定できます。
ストレージ保護
319
17.1.3 ストレージベースの保護のセットアッ
プ
ストレージベースの保護を設定するには、次の手順に従う必要があります。
1 SBDパーティションの作成 (320 ページ)
2 ソフトウェアウォッチドッグのセットアップ (322 ページ)
3 SBDデーモンの起動 (324 ページ)
4 SBDのテスト (325 ページ)
5 フェンシングリソースの設定 (325 ページ)
次の手順は、すべてrootとして実行する必要があります。手順を開始する前
に、次の要件が満たされているかどうか確認してください。
重要: 要件
• 環境内にすべてのノードが到達できる共有ストレージが存在する必要が
あります。
• 共有ストレージセグメントが、ホストベースのRAID、cLVM2、DRBD*を
使用してはなりません。
• ただし、信頼性向上のため、ストレージベースのRAIDとマルチパスの使
用は推奨されます。
17.1.3.1 SBDパーティションの作成
デバイスの起動時に1MBのパーティションを作成することを推奨します。SBD
デバイスがマルチパスグループ上にある場合は、MPIOのパスダウン検出に
よって遅延が発生することがあるので、SBDが使用するタイムアウトを調整
する必要があります。msgwaitタイムアウト後、メッセージがノードに配信
されたと想定されます。この時間は、マルチパスの場合、MPIOがパスの障害
を検出し、次のパスに切り替えるために必要な時間です。これは、ご使用の
320
高可用性ガイド
環境でテストする必要があるかもしれません。ノード上で実行しているSBD
デーモンがウォッチドッグタイマを十分な速さで更新していない場合、ノー
ド自体が終了します。選択したタイムアウトを特定の環境でテストします。1
台のSBDデバイスしかないマルチパスストレージを使用する場合は、発生し
たフェールオーバーの遅延に特別の注意を払ってください。
注記: SBDパーティションのデバイス名
次の手順では、このSBDパーティションを/dev/SBDで参照します。これ
は、ご使用の実際のパス名で置き換えてください(たとえば、/dev/sdc1)。
重要: 既存データの上書き
SBD用に使用するデバイスには、何もデータがないようにしてください。
sdbコマンドは、さらに確認を要求せずに、デバイスを上書きします。
1 次のコマンドで、SBDデバイスを初期化します。
root # sbd -d /dev/SBD create
これによって、デバイスにヘッダが書き込まれ、デフォルトのタイミング
でこのデバイスを共有する最大255ノードのスロットが作成されます。
SBD用に複数のデバイスを使用する場合は、次のように、-dオプションを
複数回指定することでデバイスを設定します。
root # sbd -d /dev/SBD1 -d /dev/SBD2 -d /dev/SBD3 create
2 SBDデバイスがマルチパスグループ上にある場合は、SBDが使用するタイ
ムアウトを調整します。これは、SBDデバイスの初期化時に指定できます
(すべてのタイムアウトは秒単位で指定)。
root # /usr/sbin/sbd -d /dev/SBD -4 180
-1 90
create
-4オプションはmsgwaitタイムアウトを指定するために使用されま
す。上の例では、180秒に設定されます。
-1オプションはwatchdogタイムアウトを指定するために使用されま
す。上の例では、90秒に設定されます。
3 次のコマンドで、デバイスに何が書き込まれたか確認します。
ストレージ保護
321
root # sbd -d /dev/SBD dump
Header version
: 2
Number of slots
: 255
Sector size
: 512
Timeout (watchdog) : 5
Timeout (allocate) : 2
Timeout (loop)
: 1
Timeout (msgwait) : 10
ご覧のように、タイムアウトがヘッダにも保存され、それらに関するすべて
の参加ノードの合意が確保されます。
17.1.3.2 ソフトウェアウォッチドッグのセットアップ
ウォッチドッグを他のソフトウェアが使用していない場合は、ウォッチドッ
グがシステムをSBD障害から保護します。
重要: ウォッチドッグタイマへのアクセス
他のソフトウェアは、ウォッチドッグタイマにアクセスしないでください。
一部のハードウェアベンダーは、システムのリセット用にウォッチドッグ
を使用するシステム管理ソフトウェアを提供しています(たとえば、HP ASR
デーモンなど)。ウォッチドッグをSBDで使用する場合は、そのようなソフ
トウェアを無効にしてください。
SUSE Linux Enterprise High Availability Extensionでは、カーネル内のウォッチ
ドッグサポートはデフォルトで有効化されています。これは、ハードウェア
指定のウォッチドッグドライバを提供する、さまざまなカーネルモジュール
を標準装備しています。High Availability Extensionはウォッチドッグに「フィー
ド」するソフトウェアコンポーネントとしてSBDデーモンを使用します。
17.1.3.3項「SBDデーモンの起動」 (324 ページ)で説明されているとおり設定
した場合、SBDデーモンは、それぞれのノードがrcopenais startでオン
ラインにする際に自動的に開始します。
通常、ハードウェアに適したウォッチドッグドライバがシステムブート中に
自動的にロードされます。softdogが最も一般的なドライバですが、実際の
ハードウェア統合のあるドライバの使用を推奨します。例:
• HPハードウェアでは、これは、hpwdtドライバで行います。
• Intel TCOを含むシステムでは、iTCO_wdtドライバを使用できます。
322
高可用性ガイド
選択肢のリストについては、/usr/src/KERNEL_VERSION/drivers/
watchdogを参照してください。または、次のコマンドで、ご使用のカーネ
ルバージョンでインストールされたドライバをリストで表示します。
root # rpm -ql kernel-VERSION | grep watchdog
ほとんどのウォッチドッグドライバ名はwd、wdt、またはdogなどの文字列
を含むため、次のコマンドを使用して、現在ロードされているドライバを確
認します。
root # lsmod | egrep "(wd|dog)"
ウォッチドッグドライバを自動的にロードするには、ドライバ名を示した行
を含む/etc/modules-load.d/watchdog.confというファイルを作成し
ます。詳細については、modules-load.dのマニュアルページを参照してく
ださい。
ウォッチドッグのタイムアウトを変更する場合は、他の2つの値(msgwaitお
よびstonith-timeout)も変更する必要があります。ウォッチドッグタイム
アウトは主に、ストレージレイテンシに基づくものです。この値は、ほとん
どのデバイスで、このタイムフレーム内に読み込み操作を正常に完了する必
要があることを指定しています。完了しない場合、ノードは自己フェンシン
グします。
次の「」式は、これら3つの値の関係を簡潔に示しています。
例 17.1 STONITHデバイスとしてSBDを使用したクラスタのタイミング
Timeout (msgwait) = (Timeout (watchdog) * 2)
stonith-timeout = Timeout (msgwait) + 20%
たとえば、タイムアウトウォッチドッグを120に設定した場合は、msgwaitを
240に、stonith-timeoutを288に設定する必要があります。
cs_make_sbd_devicesにより出力を確認できます。
root # cs_make_sbd_devices --dump
==Dumping header on disk /dev/sdb
Header version
: 2.1
UUID
: 619127f4-0e06-434c-84a0-ea82036e144c
Number of slots
: 255
Sector size
: 512
Timeout (watchdog) : 20
Timeout (allocate) : 2
Timeout (loop)
: 1
Timeout (msgwait) : 40
==Header on disk /dev/sdb is dumped
ストレージ保護
323
新しいクラスタをセットアップした場合は、先に示した考慮事項を
sleha-initコマンドに反映できます。
SBDに関連するタイミング変数の詳細については、技術情報文書『SBD
Operation Guidelines for HAE Clusters』(https://www.suse.com/support/
kb/doc.php?id=7011346で入手可能)を参照してください。
17.1.3.3 SBDデーモンの起動
SBDデーモンは、クラスタスタックの不可欠なコンポーネントです。このデー
モンは、クラスタスタックの実行中はもちろんのこと、クラスタスタックの
一部がクラッシュしたときでも、実行されている必要があります。これによ
り、ノードのフェンシングが可能になります。
1 sleha-initを実行します。このスクリプトによりSBDが正しく設定され、
設定ファイル/etc/sysconfig/sbdが、Csync2で同期される必要のある
ファイルのリストに追加されます。
SBDを手動で設定する場合は、次の手順を実行します。
OpenAISのinitスクリプトでSBDを開始および停止するには、ファイル/etc/
sysconfig/sbdで次の行を探し出し、SBDを、使用しているSBDデバイス
に置き換えます。
SBD_DEVICE="/dev/SBD"
1行目で複数のデバイスを指定する必要がある場合は、セミコロンで区切っ
て指定します(デバイスの順序は任意で構いません)。
SBD_DEVICE="/dev/SBD1; /dev/SBD2; /dev/SBD3"
SBDデバイスがアクセス不能な場合は、SBDデーモンが開始できなくなり、
OpenAISの起動を抑止します。
注記: ブート時にサービスを開始
SBDデバイスがノードからアクセスできなくなった場合は、ノードが無
限の再起動サイクルに入ることあります。これは技術的には正しい振る
舞いですが、管理ポリシーによっては、まず間違いなく面倒な問題とな
るでしょう。そのような場合には、ブート時にOpenAISを自動的に開始
しないのがよいでしょう。
324
高可用性ガイド
2 先に進む前に、rcopenais restartを実行して、SBDがすべてのノード
上で開始しているようにします。
17.1.3.4 SBDのテスト
1 次のコマンドを使用すると、ノードスロットとそれらの現在のメッセージ
がSBDデバイスからダンプされます。
root # sbd -d /dev/SBD list
ここに、SBDとともに起動されたすべてのクラスタノードが一覧され、メッ
セージスロットにはclearが表示されるはずです。
2 ノードの1つにテストメッセージを送信してみます。
root # sbd -d /dev/SBD message alice test
3 ノードがシステムログファイルにメッセージの受信を記録します。
Aug 29 14:10:00 alice sbd: [13412]: info: Received command test from bob
これによって、SBDがノード上で実際に機能し、メッセージを受信できる
ことが確認されます。
17.1.3.5 フェンシングリソースの設定
SBDのセットアップを完了するには、SBDをCIB内でSTONITH/フェンシング
メカニズムとして設定します。
ヒント: 2ノードクラスタ用のSTONITH設定
2ノードクラスタ(およびno-quorum-policyをignoreに設定した他のク
ラスタ)では、タイミングを外したフェンシングが頻繁に発生します。これ
は、スプリットブレインが発生した状況で、両方のノードが互いをフェン
シングしようとするためです。このダブルフェンシングを避けるには、
STONITHTリソースの設定にpcmk_delay_maxパラメータを追加します。こ
れにより、機能しているネットワークカードを備えたサーバが稼動を継続
できる可能性が高くなります。
1 いずれかのノードにログインし、crm configureを使用して対話型crmsh
を起動します。
ストレージ保護
325
2 次のように入力します。
crm(live)configure# property stonith-enabled="true"
crm(live)configure# property stonith-timeout="40s"
crm(live)configure# primitive stonith_sbd stonith:external/sbd \
pcmk_delay_max="30"
リソースのクローンを作成する必要はありません。ノードスロットは自動
的に割り当てられるので、手動のホストリストを定義する必要はありませ
ん。
どの値がstonith-timeoutに設定されているかは、msgwaitタイム
アウトによって異なります。msgwaitタイムアウトは、基盤のIOシス
テムで許可されている最大タイムアウトより長い必要があります。た
とえば、プレーンなSCSIディスクの場合は、30秒です。msgwaitタイ
ムアウト値を30秒に設定する場合、stonith-timeoutを40秒に設定
すると適切です。
pcmk_delay_maxパラメータを使用すると、フェンシングデバイス上
でSTONITHアクションに対するランダム遅延が有効になります。その
値では、STONITHデバイスの起動操作が実行されるまでの最大待機時
間を指定します。リング障害を検出し、DCになったうえでSTONITH
リソースを起動するには時間がかかるため、この値を過剰に小さい値
に設定しないようにします(この値が小さすぎると、それまでのDCに
よって必ずフェンシングアクションが先に始まります)。
3 変更をコミットします。
crm(live)# configure commit
4 以前設定した他のフェンシングデバイスを無効にします。現在、この機能
にはSBDメカニズムが使用されるからです。
一度リソースが起動すれば、クラスタは共有ストレージフェンシング用に正
常に設定されます。クラスタは、ノードのフェンシングが必要になると、こ
の方法を使用します。
17.1.3.6 その他の情報
http://www.linux-ha.org/wiki/SBD_Fencing
326
高可用性ガイド
17.2 排他的ストレージアクティベー
ションの確保
このセクションでは、共有ストレージへのアクセスを1つのノードに排他的に
ロックする低レベルの追加メカニズムであるsfexを紹介します。ただし、sfex
は、STONITHと置き換えることはできないので注意してください。sfexには
共有ストレージが必要なので、上記で説明したexternal/sbdフェンシング
メカニズムは、ストレージの別のパーティションで使用することをお勧めし
ます。
設計上、sfexは、同時並行性を必要とするOCFS2のようなワークロードには使
用できませんが、従来のフェールオーバー方式のワークロードに対しては保
護層として機能できます。これは、実際にはSCSI-2予約と似ていますが、もっ
と一般的です。
17.2.1 概要
共有ストレージ環境では、ストレージの小さなパーティションが1つ以上の
ロックの保存用に確保されます。
ノードは、保護されたリソースを取得する前に、まず、保護ロックを取得す
る必要があります。順序は、Pacemakerによって強制され、sfexコンポーネン
トは、Pacemakerがスプリットブレイン条件に制約されても、ロックが2回以
上付与されないことを保証します。
ノードのダウンが永続的にロックをブロックせず、他のノードが続行できる
ように、これらのロックも定期的に更新される必要があります。
17.2.2 設定
次に、sfexで使用する共有パーティションの作成方法と、CIBでsfexロック用
にリソースを設定する方法を説明します。1つのsfexパーティションは任意の
数のロックを保持できますが、デフォルトは1に設定されています。ロックご
とに1KBのストレージスペースを割り当てる必要があります。
ストレージ保護
327
重要: 要件
• sfex用の共有パーティションは、保護するデータと同じ論理ユニットにあ
る必要があります。
• 共有されたsfexパーティションは、ホストベースのRAIDやDRBDを使用し
てはなりません。
• cLVM2論理ボリュームの使用は可能です。
手順 17.1 sfexパーティションを作成する
1 sfexで使用する共有パーティションを作成します。このパーティションの
名前を書き留め、以降の手順の/dev/sfexをこの名前で置き換えます。
2 次のコマンドで、sfexメタデータを作成します。
root # sfex_init -n 1 /dev/sfex
3 メタデータが正しく作成されたかどうか検証します。
root # sfex_stat -i 1 /dev/sfex ; echo $?
現在、ロックがかかっていないので、このコマンドは、2を返すはずです。
手順 17.2 sfexロック用リソースを設定する
1 sfexロックは、CIB内のリソースを介して表現され、次のように設定されま
す。
crm(live)configure# primitive sfex_1 ocf:heartbeat:sfex \
# params device="/dev/sfex" index="1" collision_timeout="1" \
lock_timeout="70" monitor_interval="10" \
# op monitor interval="10s" timeout="30s" on_fail="fence"
2 sfexロックによってリソースを保護するには、保護対象とsfexリソース間の
必須の順序付けと配置の制約を作成します。保護対象のリソースが
filesystem1というIDを持つ場合は、次のようになります。
crm(live)configure# order order-sfex-1 inf: sfex_1 filesystem1
crm(live)configure# colocation colo-sfex-1 inf: filesystem1 sfex_1
328
高可用性ガイド
3 グループ構文を使用する場合は、sfexリソースを最初のリソースとしてグ
ループに追加します。
crm(live)configure# group LAMP sfex_1 filesystem1 apache ipaddr
17.3 その他の情報
http://www.linux-ha.org/wiki/SBD_Fencingおよびman sbdを参照
してください。
ストレージ保護
329
18
Sambaクラスタリング
クラスタ対応のSambaサーバは、異種混合ネットワークにHigh Availabilityソ
リューションを提供します。この章では、背景情報とクラスタ対応Sambaサー
バの設定方法を説明します。
18.1 概念の概要
TDB (Trivial Database)は、長年にわたって、Sambaによって使用されてきまし
た。TDBでは、複数のアプリケーションが同時に書き込むことができます。
すべての書き込み操作を正常に実行し、互いに衝突させないため、TDBは、
内部ロッキングメカニズムを使用しています。
CTDB (Cluster Trivial Database)は、既存のTDBの小規模な拡張です。CTDBは、
プロジェクトによって、「一時データの保存のために、Sambaなどのプロジェ
クトによって使用されるTDBデータベースのクラスタ実装」として説明され
ています。
各クラスタノードは、ローカルCTDBデーモンを実行します。Sambaは、その
TDBに直接書き込むのではなく、そのローカルCTDBデーモンと通信します。
それらのデーモンは、ネットワークを介してメタデータを交換しますが、実
際の読み取り/書き込み操作は、高速ストレージでローカルコピー上で行われ
ます。CTDBの概念は、図18.1「CTDBクラスタの構造」 (332 ページ)に表示さ
れています。
Sambaクラスタリング
331
注記: Samba専用CTDB
CTDBリソースエージェントの現在の実装では、Sambaの管理のためだけに
CTDBを設定します。他の機能(IPフェールオーバーなど)はすべて、Pacemaker
で設定する必要があります。
CTDBは、完全に同種のクラスタに関してのみサポートされます。たとえ
ば、クラスタのすべてのノードが同じアーキテクチャを持つ必要があり、
i586とx86_64を混合できません。
図 18.1 CTDBクラスタの構造
クラスタ対応Sambaサーバは、一定のデータを共有する必要があります。
• UnixのユーザとグループIDをWindowsのユーザとグループに関連付けるマッ
ピングテーブル。
• ユーザデータベースをすべてのノード間で同期する必要があります。
• Windowsドメイン内のメンバサーバの参加情報をすべてのノードで利用でき
る必要があります。
• メタデータ(アクティブSMBセッション、共有接続、各種ロックなど)をすべ
てのノードで利用できる必要があります。
332
高可用性ガイド
クラスタ対応SambaサーバがN+1ノードを持っている場合、Nノードだけのサー
バより高速になることを目的としています。1つのノードは、クラスタ非対応
のSambaサーバより遅くなることはありません。
18.2 基本的な設定
注記: 変更された設定ファイル
CTDBリソースエージェントは、自動的に、/etc/sysconfig/ctdbと/etc/
samba/smb.confを変更します。crm ra info CTDBを使用して、CTDB
リソースに指定できるすべてのパラメータを一覧表示してください。
クラスタ対応Sambaサーバをセットアップするには、次の手順に従います。
手順 18.1 クラスタ対応Sambaサーバの基本セットアップ
1 クラスタを準備します。
1a 本書のパートII「設定および管理」 (57 ページ)で説明されているよ
うに、クラスタを設定します(OpenAIS、Pacemaker、OCFS2など使
用)。
1b OCFS2などの共有ファイルシステムを設定し、マウントします(たと
えば、/sharedにマウント)。
1c POSIX ACLをオンにする場合は、それを有効にします。
• 新しいOCFS2ファイルシステムの場合は、次のコマンドを使用し
ます。
root # mkfs.ocfs2 --fs-features=xattr ...
• 既存のOCFS2ファイルシステムの場合は、次のコマンドを使用し
ます。
root # tunefs.ocfs2 --fs-feature=xattrDEVICE
ファイルシステムリソースには、必ず、aclオプションを指定しま
す。次のように、crmシェルを使用します。
Sambaクラスタリング
333
crm(live)configure#
options="acl" ...
primary ocfs2-3 ocf:heartbeat:Filesystem
1d ctdb、smb、nmb、winbindの各サービスが無効になるようにしま
す。
root # chkconfig ctdb off
chkconfig smb off
chkconfig nmb off
chkconfig winbind off
2 共有ファイルシステムにCTDBロックのディレクトリを作成します。
root # mkdir -p /shared/samba/
3 /etc/ctdb/nodesに、クラスタ内の各ノードの全プライベートIPアドレ
スを含むすべてのノードを挿入します。
192.168.1.10
192.168.1.11
4 csync2を使用して、設定ファイルをすべてのノードにコピーします。
root # csync2 -xv
詳細については、手順3.10「Csync2による設定ファイルの同期」 (48 ページ)
を参照してください。
5 CTDBリソースをクラスタに追加します。
crm configure
crm(live)configure# primitive ctdb ocf:heartbeat:CTDB params \
ctdb_manages_winbind="false" \
ctdb_manages_samba="true" \
ctdb_recovery_lock="/shared/samba/ctdb.lock" \
op monitor interval="10" timeout="20" \
op start interval="0" timeout="90" \
op stop interval="0" timeout="100"
crm(live)configure# clone ctdb-clone ctdb \
meta globally-unique="false" interleave="true"
crm(live)configure# colocation ctdb-with-fs inf: ctdb-clone fs-clone
crm(live)configure# order start-ctdb-after-fs inf: fs-clone ctdb-clone
crm(live)configure# commit
6 クラスタ対応のIPアドレスを追加します。
334
高可用性ガイド
crm(live)configure# primitive ip ocf:heartbeat:IPaddr2 params
ip=192.168.2.222 \
clusterip_hash="sourceip-sourceport" op monitor interval=60s
crm(live)configure# clone ip-clone ip meta globally-unique="true"
crm(live)configure# colocation ip-with-ctdb inf: ip-clone ctdb-clone
crm(live)configure# order start-ip-after-ctdb inf: ctdb-clone ip-clone
crm(live)configure# commit
7 結果を確認します。
root # crm status
Clone Set: dlm-clone
Started: [ hex-14 hex-13 ]
Clone Set: o2cb-clone
Started: [ hex-14 hex-13 ]
Clone Set: c-ocfs2-3
Started: [ hex-14 hex-13 ]
Clone Set: ctdb-clone
Started: [ hex-14 hex-13 ]
Clone Set: ip-clone (unique)
ip:0
(ocf::heartbeat:IPaddr2):
ip:1
(ocf::heartbeat:IPaddr2):
Started hex-13
Started hex-14
8 クライアントコンピュータからテストを行います。Linuxクライアントで、
Sambaアクセス用のユーザを追加します。
root # smbpasswd -a USERNAME
9 新しいユーザのホームディレクトリにアクセスできるかどうかをテストし
ます。
root # smbclient -u USERNAME//192.168.2.222/USERNAME
18.3 Active Directoryドメインへの追
加
Active Directory (AD)は、Windowsサーバシステムのディレクトリサービスで
す。
次の手順は、CTDBクラスタをActive Directoryドメインに追加する方法を概説
しています。
Sambaクラスタリング
335
1 Active Directoryドメインのセットアップ方法については、Windows Serverの
マニュアルを参照してください。この例では、次のパラメータを使用しま
す。
ADおよびDNSサーバ
win2k3.2k3test.example.com
ADドメイン
2k3test.example.com
クラスタADメンバーのNETBIOS
名
CTDB-SERVER
2 手順18.2「CTDBの設定」 (336 ページ)
3 手順18.3「Active Directoryへの参加」 (337 ページ)
次のステップは、CTDBの設定です。
手順 18.2 CTDBの設定
1 クラスタが、18.2項「基本的な設定」 (333 ページ)に示されているとおり設
定されていることを確かめます。
2 1つのノードでCTDBリソースを停止します。
root #
crm resource stop ctdb-clone
3 /etc/samba/smb.conf設定ファイルを開き、NetBIOS名を追加して、ファ
イルを閉じます。
[global
netbios name = CTDB-SERVER
セキュリティやワークグループなどのその他の設定は、YaSTウィザードで
追加されます。
4 すべてのノードで/etc/samba.confファイルを更新します。
root # csync2 -xv
5 CTDBリソースをリスタートします。
336
高可用性ガイド
root # crm resource start ctdb-clone
最後に、クラスタをActive Directoryサーバに参加させます。
手順 18.3 Active Directoryへの参加
1 次のファイルが、すべてのクラスタホストにインストールされるように、
Csync2設定に含まれていることを確認します。
/etc/samba/smb.conf
/etc/security/pam_winbind.conf
/etc/krb5.conf
/etc/nsswitch.conf
/etc/security/pam_mount.conf.xml
/etc/pam.d/common-session
この作業には、YaSTの［Csync2の設定］モジュールをっ使用することもで
きます。3.5.4項「すべてのノードへの設定の転送」 (46 ページ)を参照して
ください。
2 手順18.1「クラスタ対応Sambaサーバの基本セットアップ」 (333 ページ)の
説明に従って、CTDBリソースを作成します。
3 YaSTを実行し、［ネットワークサービス］エントリから［Windowsドメイ
ンメンバーシップ］モジュールを開きます。
4 ドメインまたはワークグループの設定を入力して、［OK］をクリックして
終了します。
18.4 クラスタ対応Sambaのデバッグと
テスト
クライアント対応Sambaサーバのデバッグには、次のツールを使用できます。
これらのツールは、さまざまなレベルで動作します。
ctdb_diagnostics
このツールを実行して、クラスタ対応Sambaサーバを診断します。詳細な
デバッグメッセージが出力されるので、発生している問題を追跡するのに
役立ちます。
Sambaクラスタリング
337
ctdb_diagnosticsコマンドは、次のファイルを検索します。これらの
ファイルは、すべてのノードで利用できる必要があります。
/etc/krb5.conf
/etc/hosts
/etc/ctdb/nodes
/etc/sysconfig/ctdb
/etc/resolv.conf
/etc/nsswitch.conf
/etc/sysctl.conf
/etc/samba/smb.conf
/etc/fstab
/etc/multipath.conf
/etc/pam.d/system-auth
/etc/sysconfig/nfs
/etc/exports
/etc/vsftpd/vsftpd.conf
/etc/ctdb/public_addressesファイルと/etc/ctdb/static
-routesファイルが存在する場合は、それらもチェックされます。
ping_pong
ping_pongでは、ファイルシステムがCTDBに適合しているかどうかチェッ
クできます。このコマンドは、クラスタファイルシステムの一定のテスト
(コヒーレンスやパフォーマンスなどのテスト)を実行して(http://wiki
.samba.org/index.php/Ping_pong参照)、高負荷の状況下における
クラスタの動作を示す情報を提供します。
send_arpツールおよびSendArpリソースエージェント
SendArpリソースエージェントは、/usr/lib/heartbeat/send_arp(ま
たは/usr/lib64/heartbeat/send_arp)にあります。send_arpツー
ルはGratuitous ARP (余計なアドレス解決プロトコル)パケットを送信し、
他のマシンのARPテーブルを更新するために使用できます。これは、フェー
ルオーバープロセス後の通信問題の識別に役立ちます。Sambaのクラスタ
化されたIPアドレスを表示しているのにも関わらず、ノードに接続または
pingできない場合は、send_arpコマンドを使用して、ノードはARPテー
ブルの更新のみが必要であるのかをテストします。
詳細については、http://wiki.wireshark.org/Gratuitous_ARPを
参照してください。
クラスタファイルシステムの特定の側面をテストするには、次の手順に従い
ます。
338
高可用性ガイド
手順 18.4 クラスタファイルシステムのコヒーレンスとパフォーマンスをテ
ストする
1 1つのノードでping_pongコマンドを開始します。プレースホルダNはノー
ド数+1で置き換えます。共有ストレージではABSPATH/data.txtファイ
ルが使用可能で、すべてのノード上でアクセスできます(ABSPATHは絶対パ
スを示しています)。
ping_pong ABSPATH/data.txt N
1つのノードでだけ実行しているので、ロッキングレートは非常に高いと予
想してください。プログラムがロッキングレートを出力しない場合は、ク
ラスタファイルシステムを置き換えます。
2 同じパラメータを使用して、別のノードでping_pongの2つ目のコピーを
開始します。
ロッキングレートが大幅に下がることを予想できます。使用しているクラ
スタファイルシステムに次のどれかが当てはまる場合は、クラスタファイ
ルシステムを置き換えます。
• ping_pongがロッキングレート(秒単位)を出力しない。
• 2つのインスタンスのロッキングレートがほぼ同じではない。
• 2つ目のインスタンスの開始後にロッキングレートが下がらなかった。
3 ping_pongの3つ目のコピーを開始します。もう1つノードを追加し、ロッ
キングレートの変化に注目します。
4 ping_pongコマンドを1つずつ終了させます。単一ノードの状態に戻るま
で、ロッキングレートの増加が観察されるはずです。予想したような振る
舞いが見られなかった場合には、第14章 OCFS2 (275 ページ)に記されている
詳細を参照してください。
18.5 その他の情報
• http://linux-ha.org/wiki/CTDB_(resource_agent)
Sambaクラスタリング
339
• http://wiki.samba.org/index.php/CTDB_Setup
• http://ctdb.samba.org
• http://wiki.samba.org/index.php/Samba_%26_Clustering
340
高可用性ガイド
19
Rearによる障害復旧
Relax-and-Recover (旧称「ReaR」。この章ではRearと略記)は、システム管理者
による使用を意図した障害復旧フレームワークです。Rearは、障害発生時に
保護対象となる特定の運用環境に合わせて調整する必要があるBashスクリプ
トのコレクションです。
特別な設定を必要とせずにそのまま使用できる障害復旧ソリューションはあ
りません。したがって、障害が発生する前に準備しておくことが不可欠です。
19.1 概念の概要
以降のセクションでは、障害復旧の一般的な概念を述べ、Rearを使用した復
旧を実現するために必要となる基本的な手順について説明します。また、Rear
の要件に関するいくつかの指針、現在の製品に付属しているRearのバージョ
ン、知っておくべき制限事項、およびシナリオとバックアップツールについ
ても紹介します。
19.1.1 障害復旧プランの作成
最悪のシナリオが発生する前に、ITインフラストラクチャに重大なリスクが
あるかどうかの分析、予算の見積もり、障害復旧プランの作成などの対応策
を講じます。障害復旧プランを手元に用意していない場合は、以下の手順ご
とに情報を入手します。
Rearによる障害復旧
341
• リスクの分析インフラの確かなリスク分析を実施します。可能性のあるす
べての脅威を一覧表示し、深刻度を評価します。これらの脅威が発生する
可能性を判断し、優先順位を設定します。可能性と影響の簡単な分類を使
用することを推奨します。
• 予算のプラニング分析結果には、どのリスクが耐えうるもので、どれがビ
ジネスにとって致命的であるかを全般的に示します。リスクを最小限にす
る方法およびそれに要するコストを自問して検討します。会社の規模に応
じて、IT予算全体の2～15%を障害復旧に使用します。
• 障害復旧プランの作成チェックリストの作成、手順のテスト、優先順位の
設定と割り当て、ITインフラのインベントリ調査を行います。インフラの
サービスが失敗した際、問題に対処する方法を定義します。
• テスト念入りなプランを定義したら、それをテストします。最低でも1年
に1度テストします。ご使用のメインITインフラと同じテストハードウェア
を使用します。
19.1.2 障害復旧とは
運用環境に存在するシステムが、ハードウェアの損傷、誤設定、ソフトウェ
ア上の問題など、原因がどのようなものであっても破損した場合は、システ
ムを再作成する必要があります。再作成は、同じハードウェア上または互換
性のある代替ハードウェア上で実行できます。単にバックアップからファイ
ルを復元するだけでは、システムを再作成することにはなりません。システ
ムの再作成では、ファイルシステム、パーティション、マウントポイントの
面からのシステムのストレージ作成や、ブートローダの再インストールなど
の作業も必要になります。
19.1.3 Rearによる障害復旧
システムが正常に稼働しているときに、ファイルのバックアップを作成し、
復旧メディア上に復旧システムを作成します。復旧システムには、復旧イン
ストーラが収められています。
システムが破損した場合は、損傷したハードウェアを必要に応じて交換し、
復旧メディアから復旧システムをブートして復旧インストーラを起動します。
復旧インストーラによるシステムの再作成では、まず、ストレージにパーティ
342
高可用性ガイド
ション、ファイルシステム、マウントポイントを作成し、続いてバックアッ
プからファイルを復元します。最後に、ブートローダを再インストールしま
す。
19.1.4 Rearの要件
Rearを使用するには、運用環境を実行するマシンおよびそれと同一のテスト
マシンが必要です。つまり、同一のシステムが2台以上必要になります。ここ
でいう「同一」とは、たとえば、ネットワークカードを、同じカーネルドラ
イバを使用する他のネットワークカードに置き換えることができるというこ
とです。
警告: 同一のドライバが必要
運用環境のドライバと同じドライバを使用していないハードウェアコンポー
ネントは、Rearでは同一のコンポーネントとは見なされません。
19.1.5 Rearのバージョン
SUSE Linux Enterprise High Availability Extension 11 SP4には、以下に挙げる2つ
のバージョンのReaが付属しています。
• RPMパッケージ: rearに付属するRearバージョン1.10.0。このRearバー
ジョンのマニュアルについては、『High Availability Guide for SUSE Linux
Enterprise High Availability Extension 11 SP3』を参照してください。http://
www.suse.com/documentation/から入手できます。
• RPMパッケージrear116に付属するRearバージョン1.16。ここでは、この
バージョンのRearを取り上げています。
重要
Rearバージョン1.10.0による障害復旧手順をテスト済みで、その手順が十分
に機能しているのであれば、アップグレードの必要はありません。その場
合は、Rearパッケージをそのまま保持し、障害復旧手法を変更しないよう
にします。
Rearによる障害復旧
343
一方、Rearバージョン1.10.0では固有のニーズに対応できない場合は(19.1.6
項 (344 ページ)も参照)、Rearバージョン1.16に手動でアップグレードしま
す。インストール済みのバージョンが誤って別のバージョンに置き換わら
ないように、パッケージrearとrear116は意図的に互いに衝突するように
なっています。
Rearバージョンをアップグレードするたびに、各自の障害復旧手順が引き
続き機能していることを慎重に再検証する必要があります。
19.1.6 Btrfsに伴う制限事項
Btrfsを使用する場合は次の制限事項が発生します。
システムにサブボリュームは存在しても、スナップショットのサブボリュー
ムが存在しない場合
Rearバージョン1.16が必要です。このバージョンは、スナップショットの
サブボリュームが存在しない「通常の」Btrfsサブボリューム構造の再作成
をサポートしています。
システムにスナップショットのサブボリュームが存在する場合
警告
ファイルベースのバックアップソフトウェアでは、Btrfsスナップショッ
トのサブボリュームを通常どおりにはバックアップできず、復元するこ
ともできません。
Btrfsにはコピーオンライト機能があることから、Btrfsファイルシステム上
のサブボリュームにある最近のスナップショットはディスク容量をほとん
ど必要としません。一方、ファイルベースのバックアップソフトウェアを
使用すると、これらのファイルは完全なファイルとしてバックアップされ
ます。最終的に、これらのファイルはその本来のファイルサイズで2回バッ
クアップされることになります。したがって、元のシステム上に以前に存
在していたときと同じ状態にスナップショットを復元することができませ
ん。
344
高可用性ガイド
19.1.7 シナリオとバックアップのツール
Rearでは、ハードディスク、フラッシュディスク、DVD/CD-Rなどのローカル
メディアからのブートやPXEを介したブートが可能な障害復旧システム(固有
の復旧インストーラなど)を作成できます。バックアップデータは、
例 19.1 (347 ページ)に説明があるNFSなどのネットワークファイルシステムに
保存できます。
Rearは、ファイルのバックアップに取って代わるツールではなく、それを補
完するツールです。Rearは、汎用的なtarコマンドのほか、いくつかのサード
パーティのバックアップツールをデフォルトでサポートしています。このよ
うなバックアップツールとして、Tivoli Storage Manager、QNetix Galaxy、
Symantec NetBackup、EMC NetWorker、HP DataProtectorなどがあります。バッ
クアップツールとしてEMC NetWorkerを使用したRearの設定例については
例 19.2 (347 ページ)を参照してください。
19.1.8 基本手順
障害発生時にRearを使用して効果的な復旧を実現するには、以下の基本手順
を実行する必要があります。
Rearおよびバックアップソリューションのセットアップ (346 ページ)
この手順では、Rear設定ファイルの編集、Bashスクリプトの調整、使用す
るバックアップソリューションの設定などのタスクを実行します。
復旧インストールシステムの作成 (348 ページ)
保護対象のシステムが稼働しているときに、rear mkbackupコマンドを
使用して、ファイルのバックアップを作成し、システム固有のRear復旧イ
ンストーラなどの復旧システムを生成します。
復旧プロセスのテスト (348 ページ)
Rearを使用して障害復旧メディアを作成した場合は、その障害復旧プロセ
スを必ず十分にテストしておくようにします。ここでは、運用環境を構成
するハードウェアと同一のハードウェアを備えたテストマシンの使用が不
可欠です。詳細については、19.1.4項「Rearの要件」 (343 ページ)を参照し
てください。
Rearによる障害復旧
345
障害からの復旧 (349 ページ)
障害が発生した場合は、必要に応じて損傷したハードウェアを交換しま
す。続いて、Rear復旧システムをブートし、rear recoverコマンドで
復旧インストーラを起動します。
19.2 Rearおよびバックアップソリュー
ションのセットアップ
Rearをセットアップするには、少なくともRear設定ファイル/etc/rear/local
.confを編集する必要があります。さらに、Rearフレームワークを構成する
Bashスクリプトも必要に応じて編集します。
特に、Rearが実行する以下のタスクの定義が必要です。
• ファイルをバックアップする方法および障害復旧システムを作成して保存
する方法これは、/etc/rear/local.confで設定する必要があります。
• 正確な再作成を必要とする対象(パーティション、ファイルシステム、マウ
ントポイントなど) これは、/etc/rear/local.confで定義できます(た
とえば、除外対象を定義できます)。標準とは異なるシステムを再作成する
には、Bashスクリプトの拡張が必要になることがあります。
• 復旧プロセスの仕組み Rearで復旧インストーラを生成する方法の変更やRear
復旧インストーラによる実行タスクとの適合を可能にするには、Bashスク
リプトの編集が必要です。
Rearを設定するには、/etc/rear/local.conf設定ファイルに目的のオプ
ションを追加します(これまで使用されてきた設定ファイル/etc/rear/sites
.confは、パッケージから削除されました。なお、このファイルを前回のセッ
トアップから引き継いでいる場合、Rearでは引き続きこのファイルが使用さ
れます)。
参考となるデフォルトのRear設定は/usr/share/rear/conf/default.conf
にあります。他の設定例(*example.conf)も同じディレクトリにあります。
詳細については、Rearのマニュアルで該当のページを参照してください。
346
高可用性ガイド
Rear設定ファイルを変更した場合は、次のコマンドを実行して、その出力を
確認します。
rear dump
例 19.1 NFSサーバを使用したファイルバックアップの保存
Rearはさまざまなシナリオで使用できます。以下の例では、ファイルのバッ
クアップを収めるストレージとしてNFSサーバを使用しています。
1 『SUSE Linux Enterprise Server 11 SP4 管理ガイド』の「NFSでのファイルシ
ステムの共有」の章の説明に従って、YaSTでNFSサーバを設定します。
http://www.suse.com/documentation/から入手できます。
2 目的のNFSサーバの設定を/etc/exportsファイルで定義します。NFSサー
バ上でバックアップデータの保存先とするディレクトリに、適切なマウン
トオプショが設定されていることを確認します。次に例を示します。
/srv/nfs *(fsid=0,crossmnt,rw,no_root_squash,sync,no_subtree_check)
必要に応じて、/srv/nfsをNFSサーバ上のバックアップデータへのパスに
置き換えて、マウントオプションを調整します。バックアップデータにア
クセスするには、no_root_squashの指定が必要になることが普通です。
これは、rear mkbackupコマンドがrootとして実行されるためです。
3 さまざまな BACKUP パラメータ(設定ファイル/etc/rear/local.confに
記述されています)を調整して、該当のNFSサーバ上にRearからファイルの
バックアップを保存できるようにします。この例は、インストールしたシ
ステムの/usr/share/rear/conf/SLE11-ext3-example.confにあり
ます。
例 19.2 サードパーティのバックアップツール(EMC NetWorkerなど)の使用
tarの代わりにサードパーティのバックアップツールを使用するには、Rear設
定ファイルを適切に設定する必要があります。
以下は、EMC NetWorkerを使用する場合の設定例です。この設定スニペット
を/etc/rear/local.confに追加し、それぞれのセットアップに応じて調
整します。
BACKUP=NSR
OUTPUT=ISO
BACKUP_URL=nfs://host.example.com/path/to/your/rear/backup
OUTPUT_URL=nfs://host.example.com/path/to/your/rear/backup
Rearによる障害復旧
347
NSRSERVER=backupserver.example.com
RETENTION_TIME="Month"
19.3 復旧インストールシステムの作成
19.2項 (346 ページ)の説明に従ってRearを設定した後、Rear復旧インストーラ
を持つ復旧インストールシステムを作成したうえで、以下のコマンドを使用
してファイルのバックアップを作成します。
rear -d
-D mkbackup
このコマンドでは以下の手順が実行されます。
1. ターゲットシステムを分析し、ディスクのレイアウト(パーティション、
ファイルシステム、マウントポイント)やブートローダに関する情報を中心
として必要な情報を収集する。
2. 最初の手順で収集した情報を使用して、ブート可能な復旧システムを作成
する。ここで得られるRear復旧インストーラは、障害から保護する個々の
システム専用のインストーラです。このインストーラは、この固有のシス
テムを再作成する目的でのみ使用できます。
3. 設定済みのバックアップツールを呼び出し、システムとユーザファイルを
バックアップする。
19.4 復旧プロセスのテスト
復旧システムを作成した後、運用マシンと同一のハードウェアを備えたテス
トマシンで復旧プロセスをテストします。19.1.4項「Rearの要件」 (343 ページ)
も参照してください。テストマシンの設定が適切で、メインマシンの代わり
として機能できることを確認します。
警告: 運用マシンと同一のハードウェア上での包括的なテスト
マシン上で障害復旧プロセスを十分にテストする必要があります。復旧手
順を定期的にテストし、すべてが想定どおりに機能することを確認します。
348
高可用性ガイド
手順 19.1 テストマシン上での障害復旧の実行
1 19.3項 (348 ページ)で作成した復旧システムをDVDやCDに書き込み、復旧
メディアを作成します。PXEを介したネットワークブートとすることもで
きます。
2 復旧メディアからテストマシンをブートします。
3 メニューから［Recover (復旧)］を選択します。
4 rootとしてログインします(パスワードは必要なし)。
5 次のコマンドを入力して復旧インストーラを起動します。
rear -d -D recover
このプロセスでRearが実行する手順の詳細については回復プロセ
ス (349 ページ)を参照してください。
6 復旧プロセスが完了した後、システムが正常に再作成されたかどうか、お
よび運用環境で元のシステムの代替として機能するかどうかを確認します。
19.5 障害からの復旧
障害が発生した場合には、必要に応じて損傷したハードウェアを交換します。
次に、手順 19.1 (349 ページ)の説明に従って、修復したマシンまたは元のシス
テムの代替として機能することをテスト済みの同一構成のマシンを使用して
手順を進めます。
rear recoverコマンドでは以下の手順が実行されます。
回復プロセス
1. ディスクのレイアウト(パーティション、ファイルシステム、およびマウン
トポイント)を復元する。
2. バックアップからシステムとユーザファイルを復元する。
3. ブートローダを復元する。
Rearによる障害復旧
349
19.6 その他の情報
• http://en.opensuse.org/SDB:Disaster_Recovery
• rearマニュアルページ
• /usr/share/doc/packages/rear/README
350
高可用性ガイド
パート IV. 付録
20
トラブルシューティング
時として理解しにくい奇妙な問題が発生することがあります。High Availability
での実験を開始したときには、特にそうです。それでも、High Availabilityの
内部プロセスを詳しく調べるために使用できる、いくつかのユーティリティ
があります。この章では、さまざまなソリューションを推奨します。
20.1 インストールと最初のステップ
パッケージのインストールやクラスタのオンライン化では、次のように問題
をトラブルシュートします。
HAパッケージはインストールされているか
クラスタの構成を管理に必要なパッケージは、High Availability Extension
で使用できるHigh Availabilityインストールパターンに付属してい
ます。
High Availability Extensionが各クラスタノードにアドオンとしてSUSE Linux
Enterprise Server 11 SP4にインストールされているか、［High Availability］
パターンが3.3項「アドオンとしてのインストール」 (30 ページ)で説明す
るように各マシンにインストールされているか、確認します。
初期設定がすべてのクラスタノードについて同一か
相互に通信するため、で説明するように、同じクラスタに属するすべての
ノードは同じbindnetaddr、mcastaddr、mcastport3.5項「手動のクラスタセッ
トアップ(YaST)」 (37 ページ)を使用する必要があります。
トラブルシューティング
353
/etc/corosync/corosync.confで設定されている通信チャネルとオ
プションがすべてのクラスタノードに関して同一かどうか確認します。
暗号化通信を使用する場合は、/etc/corosync/authkeyファイルがす
べてのクラスタノードで使用可能かどうかを確認します。
すべてのcorosync.conf設定(nodeid以外)が同一で、すべてのノードの
authkeyファイルが同一でなければなりません。
ファイアウォールでmcastportによる通信が許可されているか
クラスタノード間の通信に使用されるmcastportがファイアウォールでブ
ロックされている場合、ノードは相互に認識できません。3.5項「手動の
クラスタセットアップ(YaST)」 (37 ページ)と3.4項「自動のクラスタセッ
トアップ(sleha-bootstrap)」 (31 ページ)で説明されているように、YaSTま
たはブートストラップスクリプトで初期セットアップを設定しているとき
に、ファイアウォール設定は通常、自動的に調整されます。
mcastportがファイアウォールでブロックされないようにするには、各ノー
ドの/etc/sysconfig/SuSEfirewall2の設定を確認します。または、
各クラスタノードのYaSTファイアウォールモジュールを起動します。［許
可されるサービス］ > ［詳細］をクリックして、mcastportを許可された
［UDPポート］のリストに追加し、変更を確定します。
OpenAISが各クラスタノードで起動しているか
各クラスタノードのOpenAISのステータスを/etc/init.d/openais
statusで確認します。OpenAISが実行されていない場
合、/etc/init.d/openais startを実行して起動します。
20.2 ログ記録
監視を有効にしているのに、ログファイルに監視操作の記録が残っていない
のはなぜですか。
lrmdデーモンは、エラーが発生しない限り、複数の監視操作はログに記
録しません。複数の監視操作をすべてログ記録すると、多量のノイズが発
生してしまいます。そのため、複数の監視操作は、1時間に1度だけ記録さ
れます。
354
高可用性ガイド
failedメッセージだけが出ました。詳細情報を取得できますか。
コマンドに--verboseパラメータを追加してください。これを複数回行
うと、デバッグ出力が非常に詳細になります。/var/log/messagesに
は、役に立つヒントが記録されます。
ノードとリソースすべての概要を確認するにはどうしたらよいですか。
crm_monコマンドを使用してください。次のコマンドは、リソース操作
履歴(-oオプション)と非アクティブなリソース(-r)を表示します。
root # crm_mon -o -r
表示内容は、ステータスが変わると、更新されます(これをキャンセルす
るには、Ctrl + Cを押します)。次に例を示します
例 20.1 停止されたリソース
Last updated: Fri Aug 15 10:42:08 2014
Last change: Fri Aug 15 10:32:19 2014
Stack: corosync
Current DC: bob (175704619) - partition with quorum
Version: 1.1.12-ad083a8
2 Nodes configured
3 Resources configured
Online: [ alice bob ]
Full list of resources:
my_ipaddress
my_filesystem
my_webserver
(ocf::heartbeat:Dummy): Started barett-2
(ocf::heartbeat:Dummy): Stopped
(ocf::heartbeat:Dummy): Stopped
Operations:
* Node bob:
my_ipaddress: migration-threshold=3
+ (14) start: rc=0 (ok)
+ (15) monitor: interval=10000ms rc=0 (ok)
* Node alice:
『 Explained (Pacemaker )』PDF (http://www.clusterlabs.org/doc/
から入手可能)では、「How are OCF Return Codes Interpreted?」セクション
で3つの異なる復元タイプを説明しています。
すべてのクラスタノードの分析を含むレポートを作成するにはどうしたらよ
いですか。
crmシェルで、crm_reportまたはhb_reportを使用してレポートを作成
します。ツールを使用して次のリソースをコンパイルします。
トラブルシューティング
355
• クラスタ全体のログファイル
• パッケージ状態
• DLM/OCFS2状態
• システム情報
• CIB履歴
• コアダンプレポートの解析(debuginfoパッケージがインストールさ
れている場合)
通常は、次のコマンドでcrm_reportを実行します。
root # crm_report -f 0:00 -n jupiter -n venus
このコマンドは、ホストjupiterおよびvenus上の午前0時以降のすべての情
報を抽出し、現在のディレクトリにcrm_report-DATE.tar.bz2という
名前の*.tar.bz2アーカイブを作成します(例: crm_report-Wed-03
-Mar-2012)。特定のタイムフレームのみを対象とする場合は、-tオプ
ションを使用して終了時間を追加します。
警告: 機密の情報は削除してください
crm_reportツールは、CIBと入力ファイルから機密の情報を削除しよ
うと試みますが、完全に削除できるわけではありません。他にも機密の
情報が含まれている場合には、付加的なパターンを指定してください。
ログファイルとcrm_mon、ccm_tool、およびcrm_verifyの出力は、
フィルタされません。
データをいずれの方法でも共有する前に、アーカイブをチェックして、
公表したくない情報があればすべて削除してください。
さらに追加のオプションを使用して、コマンドの実行をカスタマイズしま
す。たとえば、OpenAISクラスタがある場合は、確実にオプション-Aを追
加する必要があるでしょう。別のユーザがクラスタに対するパーミッショ
ンを持っている場合は、(rootおよびhaclusterに加えて)-uオプション
を使用してこのユーザを指定します。非標準のSSHポートを使用する場合
は、-Xオプションを使用して、ポートを追加します(たとえば、ポート3479
356
高可用性ガイド
では、-X "-p 3479"を使用)。その他のオプションは、crm_reportの
マニュアルページに記載されています。
crm_reportで、関連するすべてのログファイルを分析し、ディレクトリ
(またはアーカイブ)を作成したら、ERRORという文字列(大文字)があるか
どうかログファイルをチェックします。レポートの最上位ディレクトリに
ある最も重要なファイルは次のとおりです。
analysis.txt
すべてのノードで同一である必要があるファイルを比較します。
crm_mon.txt
crm_monコマンドの出力を格納します。
corosync.txt
Corosync設定ファイルのコピーを格納します。
description.txt
ノード上のすべてのクラスタパッケージのバージョンを格納します。
ノード固有のsysinfo.txtファイルもあります。これは最上位ディ
レクトリにリンクしています。
ノード固有のファイルは、ノードの名前を持つサブディレクトリに保存さ
れます。
20.3 リソース
リソースはどのようにクリーンアップしますか。
次のコマンドを使用してください。
root # crm resource list
crm resource cleanup rscid [node]
ノードを指定しないと、すべてのノードでリソースがクリーンアップされ
ます。詳細については、7.4.2項「リソースのクリーンアップ」 (213 ページ)
を参照してください。
トラブルシューティング
357
現在既知のリソースを一覧表示するにはどうしたらよいですか。
コマンドcrm_resource listを使用して、現在のリソースの情報を表
示できます。
リソースを設定しましたが、いつも失敗します。なぜですか。
OCFスクリプトを確認するには、たとえば、次のocf-testerコマンドを
使用します。
ocf-tester -n ip1 -o ip=YOUR_IP_ADDRESS \
/usr/lib/ocf/resource.d/heartbeat/IPaddr
パラメータを増やすには、-oを複数回使用します。必須パラメータとオ
プションパラメータのリストは、crm ra info AGENTの実行によって取
得できます。たとえば、次のようにします。
root # crm ra info ocf:heartbeat:IPaddr
ocf-testerを実行する場合は、その前に、リソースがクラスタで管理されて
いないことを確認してください。
リソースがフェールオーバーせず、エラーが出ないのはなぜですか。
クラスタが2ノードクラスタの場合、一方のノードを強制停止すると、残
りのノードがクォーラムのない状態になります。no-quorum-policyプ
ロパティをignoreに設定していない限り、何も起こりません。2ノード
クラスタの場合、次のように設定することが必要です。
property no-quorum-policy="ignore"
もう一つの可能性として、終了されたノードがクリーンでないと見なされ
ている場合があります。その場合には、それをフェンシングする必要があ
ります。STONITHリソースが動作していない、または存在しない場合、
残りのノードはフェンシングが実行されるのを待機することになります。
フェンシングのタイムアウトは通常長いので、問題の兆候がはっきりと現
れるまでには(仮に現れたとしても)、かなり長い時間がかかることがあり
ます。
さらに別の可能性としては、単にこのノードでのリソースの実行が許可さ
れていないという場合があります。このことは、過去にエラーが発生し、
それが正しく「解決」されていないために生じることがあります。また
は、以前に行った管理上の操作が原因である場合もあります。つまり、負
のスコアを持つ場所の制約のためです。そのような場所の制約は、たとえ
358
高可用性ガイド
ば、crm resource migrateコマンドによって挿入されることがありま
す。
リソースがどこで実行されるかを予測できないのはなぜですか。
リソースに対して場所の制約が設定されていない場合、その配置は、(ほ
とんど)ランダムなノード選択によって決まります。どのノードでリソー
スを実行することが望ましいか、常に明示的に指定することをお勧めしま
す。このことは、すべてのリソースに対して、場所の初期設定を行う必要
があるという意味ではありません。関連する(コロケーション)リソースの
セットに対して優先指定を設定すれば十分です。ノードの優先指定は次の
ようになります。
location rsc-prefers-alice rsc 100: alice
20.4 STONITHとフェンシング
STONITHリソースが開始しないのはなぜですか。
開始(または有効化)操作には、デバイスのステータスのチェックが含まれ
ます。デバイスの準備ができていない場合、STONITHリソースの開始は
失敗します。
同時に、STONITHプラグインは、ホストリストを生成するように要求さ
れます。リストが空の場合、STONITHリソースが対象にできるものがな
いことになるので、いずれにせよシューティングは行われません。
STONITHが動作しているホストの名前は、リストから除外されます。ノー
ドが自分自身をシューティングすることはできないからです。
停電デバイスのような、シングルホスト管理デバイスを使用する場合、
フェンシングの対象とするデバイスではSTONITHリソースの動作を許可
しないようにしてください。-INFINITYの、ノードの場所優先設定(制約)
を使用してください。クラスタは、STONITHリソースを、起動できる別
の場所に移動します。その際にはそのことが通知されます。
STONITHリソースを設定したのにフェンシングが行われないのはなぜですか。
それぞれのSTONITHリソースは、ホストリストを持つ必要があります。
このリストは、手動でSTONITHリソースの設定に挿入される場合、また
はデバイス自体から取得される場合があります(たとえば出力名から)。こ
の点は、STONITHプラグインの性質に応じて決まります。stonithdは、
このリストを基に、どのSTONITHリソースがターゲットノードのフェン
トラブルシューティング
359
シングを行えるかを判断します。ノードがリストに含まれれている場合に
限って、STONITHリソースはノードのシューティング(フェンシング)を行
えます。
stonithdは、動作しているSTONITHリソースから提供されたホストリ
スト内にノードを見つけられなかった場合、他のノードのstonithdイン
スタンスに問い合わせます。他のstonithdインスタンスのホストリスト
にもターゲットノードが含まれていなかった場合、フェンシング要求は、
開始ノードでタイムアウトのために終了します。
STONITHリソースが失敗することがあるのはなぜですか。
ブロードキャストトラフィックが多すぎると、電源管理デバイスが機能し
なくなることがあります。監視操作を少なくして、余裕を持たせてくださ
い。フェンシングが一時的にのみ必要な場合(必要が生じないのが最善で
すが)、デバイスのステータスは数時間に1回チェックすれば十分です。
また、この種のデバイスの中には、同時に複数の相手と通信するのを拒否
するものもあります。このことは、ユーザが端末またはブラウザセッショ
ンを開いたままにしていて、クラスタがステータスのテストを行おうとし
た場合には、問題となり得ます。
20.5 その他
すべてのクラスタノードでコマンドを実行するにはどうしたらよいですか。
この作業を実行するには、psshコマンドを使用します。必要であれば、
psshをインストールしてください。ファイル(たとえばhosts.txt)を作
成し、その中に操作する必要のあるノードのIPアドレスまたはホスト名を
含めます。sshを使用してhosts.txtファイルに含まれている各ホスト
にログインしていることを確認します。準備ができたら、psshを実行し
ます。hosts.txtファイルを(オプション-hで)指定し、対話モードを使
用してください(オプション-i)。次のようになります。
pssh -i -h hosts.txt "ls -l /corosync/*.conf"
[1] 08:28:32 [SUCCESS] [email protected]
-rw-r--r-- 1 root root 1480 Nov 14 13:37 /etc/corosync/corosync.conf
[2] 08:28:32 [SUCCESS] [email protected]
-rw-r--r-- 1 root root 1480 Nov 14 13:37 /etc/corosync/corosync.conf
360
高可用性ガイド
クラスタはどのような状態でしょうか。
クラスタの現在のステータスを確認するには、crm_monかcrm statusの
どちらかを使用します。これによって、現在のDCと、現在のノードに認
識されているすべてのノードとリソースが表示されます。
クラスタ内の一部のノードが相互に通信できないのはなぜですか。
これにはいくつかの理由が考えられます。
• まず設定ファイル/etc/corosync/corosync.confを調べます。
マルチキャストまたはユニキャストアドレスがクラスタ内のすべて
のノードで同一かどうか確認します(キーmcastaddrを含む
interfaceセクションを調べてください)。
• ファイアウォール設定を確認します。
• スイッチがマルチキャストまたはユニキャストアドレスをサポート
しているか確認します。
• ノード間の接続が切断されていないかどうか確認します。その原因
の大半は、ファイアウォールの設定が正しくないことです。また、
これはスプリットブレインの理由にもなり、クラスタがパーティ
ション化されます。
OCFS2デバイスをマウントできないのはなぜですか。
/var/log/messagesに次の行があるか確認してください。
Jan 12 09:58:55 alice lrmd: [3487]: info: RA output: [...]
ERROR: Could not load ocfs2_stackglue
Jan 12 16:04:22 alice modprobe: FATAL: Module ocfs2_stackglue not found.
この場合、カーネルモジュールocfs2_stackglue.koがありません。イ
ンストールしたカーネルに応じて、パッケージocfs2-kmp-default、
ocfs2-kmp-pae、またはocfs2-kmp-xenをインストールします。
エラー: RNGスキーマでサポートされていないタグ
詳細については、CIB構文バージョンのアップグレード (384 ページ)を参照
してください。
トラブルシューティング
361
20.6 その他の情報
クラスタリソースの設定、およびHigh Availabilityクラスタの管理とカスタマ
イズなど、Linuxの高可用性に関するその他の情報については、http://
clusterlabs.org/wiki/Documentationを参照してください。
362
高可用性ガイド
A
命名規則
このガイドでは、クラスタノードと名前、クラスタリソース、および制約に
次の命名規則を使用します。
クラスタノード
クラスタノードは名を使用します:
alice、bob、charly、doro、およびeris
クラスタサイトの名前
クラスタサイトには、都市の名前が付けられます:
アムステルダム、ベルリン、キャンベラ、福岡、ギザ、ハノイ、およびイ
スタンブール
クラスタリソース
プリミティブ
プレフィックスなし
グループ
プレフィックスg-
クローン
プレフィックスcl-
マルチステートリソース
プレフィックスms-
制約
364
順序の制約
プレフィックスo-
場所の制約
プレフィックスloc-
コロケーション制約
プレフィックスcol-
高可用性ガイド
単純なテストリソースのセット
アップ例
この章では、単純なリソース(IPアドレス)を設定する基本的な例を示します。
Pacemaker GUIまたはcrmコマンドラインツールをのいずれかを使用した、両
方の方法を紹介します。
次の例では、第3章インストールと基本セットアップ (25 ページ)で説明され
ているようにクラスタが設定され、クラスタが2つ以上のノードで設定されて
いると想定します。Pacemaker GUIとcrmシェルでクラスタリソースを設定す
る方法の紹介と概要については、次の各章を参照してください。
• クラスタリソースの設定と管理(GUI) (153 ページ)
• クラスタリソースの設定と管理(コマンドライン) (189 ページ)
B.1 GUIによるリソースの設定
サンプルのクラスタリソースを作成して別のサーバにマイグレートすると、
クラスタが正常に機能していることの確認に役立ちます。設定とマイグレー
トのシンプルなリソースは、IPアドレスです。
手順 B.1 IPアドレスクラスタリソースを作成する
1 6.1.1項「クラスタにログインする」 (154 ページ)の説明に従い、Pacemaker
GUIを起動してクラスタにログインします。
2 左側のペインで［リソース］ビューに切り替え、右側のペインで、変更す
るグループを選択して［編集］をクリックします。次のウィンドウには、
B
そのリソースに定義された基本的なグループパラメータとメタ属性とプリ
ミティブが表示されます。
3 ［プリミティブ］タブをクリックして、［追加］をクリックします。
4 次のダイアログで、次のパラメータを設定してIPアドレスをグループのサ
ブリソースとして追加します。
4a 固有の［ID］を入力します。たとえば、「myIP」です。
4b ［クラス］リストで、リソースエージェントクラスとして［ocf］を
選択します。
4c OCFリソースエージェントの［プロバイダ］として、［heartbeat］を
選択します。
4d ［タイプ］リストで、リソースエージェントとして［IPaddr］を選
択します。
4e ［進む］をクリックします。
4f ［Instance Attribute (インスタンス属性)］タブで、［IP］エントリを
選択して［編集］をクリックします(または［IP］エントリをダブル
クリックします)。
4g ［値］として、目的のIPアドレスを入力します。たとえば、
「10.10.0.1」と入力して、［OK］をクリックします。
4h 新規インスタンス属性を［追加］して、nicを［名前］に、eth0を
［値］に指定して［OK］をクリックします。
名前と値は、ハードウェア構成、およびHigh Availability Extensionソ
フトウェアのインストール中に選択したメディア構成とは独立して
います。
5 すべてのパラメータを目的どおりに設定したら、［OK］をクリックして、
そのリソースの設定を完了します。設定ダイアログが閉じて、メインウィ
ンドウに変更されたリソースが表示されます。
366
高可用性ガイド
リソースをPacemaker GUIで起動するには、左側のペインの［管理］を選択し
ます。右側のペインで、リソースを右クリックして［開始］を選択します(ま
たはツールバーから開始します)。
IPアドレスリソースを別のノード(satum)にマイグレートするには、次のよう
にします。
手順 B.2 リソースを他のノードへマイグレートする
1 左側のペインの［管理］ビューに切り替え、次に右側のペインのIPアドレ
スリソースを右クリックして［Migrate Resource (リソースのマイグレート)］
を選択します。
2 新規ウィンドウで、［To Node (マイグレート先ノード)］ドロップダウンリ
ストでsatumを選択し、選択したリソースをノードsatumに移動します。
3 リソースを一時的にマイグレートするには、［Duration (期間)］をアクティ
ブにしてリソースが新規ノードにマイグレートされる時間を入力します。
4 ［OK］をクリックして、マイグレーションを確認します。
B.2 リソースの手動設定
リソースは、コンピュータが提供するあらゆる種類のサービスです。リソー
スは、LSBスクリプトまたはOCFスクリプトであるRA (リソースエージェン
ト)によって制御されている場合、High Availabilityに認識されます。すべての
リソースはcrmコマンドで、またはXMLとしてCIB(Cluster Information Base)の
resourcesセクションで設定されます。
IPアドレス10.10.0.1をリソースとして現在の設定に追加するには、crmコ
マンドを使用します。
手順 B.3 IPアドレスクラスタリソースを作成する
1 シェルを開きrootになります。
2 「crm configure」と入力して、内部シェルを開きます。
3 IPアドレスリソースを作成します。
単純なテストリソースのセットアップ例
367
crm(live)configure# resourceprimitive myIP ocf:heartbeat:IPaddr params
ip=10.10.0.1
注記
リソースをHigh Availabilityで構成する場合、同じリソースをinitで初期化
できません。高可用性はすべてのサービスのstartまたはstopアクションを実
施します。
設定が正常に終了した場合、新規リソースはクラスタのランダムノードで始
動されたcrm_monに表示されます。
リソースを別のノードにマイグレートするには、次のようにします。
手順 B.4 リソースを他のノードへマイグレートする
1 シェルを起動してrootユーザになります。
2 リソースmyipをノードsaturnにマイグレートします。
crm resource migrate myIP saturn
368
高可用性ガイド
OCFS2およびcLVMの設定例
次の設定例は、OCFS2、cLVM、または両方を使用するためのリソースを設定
するのに役立ちます。下の設定は完全なクラスタ設定を表すものではなく、
抽出のみで、OCFS2およびcLVMに必要なすべてのリソースを含み、その他必
要な可能性のあるリソースは無視しています。属性および属性の値は個々の
セットアップに合わせて調整する必要がある場合があります。
例 C.1 CFS2およびcLVMのクラスタ設定
primitive clvm ocf:lvm2:clvmd \
params daemon_timeout="30"
primitive dlm ocf:pacemaker:controld \
op monitor interval="60" timeout="60"
primitive o2cb ocf:ocfs2:o2cb \
op monitor interval="60" timeout="60"
primitive ocfs2-1 ocf:heartbeat:Filesystem \
params device="/dev/sdb1" directory="/mnt/shared" fstype="ocfs2"
options="acl" \
op monitor interval="20" timeout="40"
primitive sbd_stonith stonith:external/sbd \
params pcmk_delay_max="15" \
op monitor interval="15" timeout="15"
primitive vg1 ocf:heartbeat:LVM \
params volgrpname="cluster-vg" \
op monitor interval="60" timeout="60"
group base-group dlm o2cb clvm vg1 ocfs2-1
clone base-clone base-group \
meta interleave="true"
ベースグループ(複数のプリミティブを含む)およびベースクローンを使っての
設定により、セットアップ全体が簡略化され、ベースグループは内部コロケー
ションと順序付けを持ち、次の2つのリソースを別として、常に同じ状態が保
たれます。
C
• vg1 - ボリュームグループのリソース。セットアップがcVLMを含む場合、
このリソースのみ設定します。それ以外の場合は、これはクラスタ設定お
よびベースグループから省略します。
• ocfs2-1 - OCFS2ファイルシステム取付けのリソース。セットアップが
OCFS2を含む場合、このリソースのみ設定します。それ以外の場合は、こ
れはクラスタ設定およびベースグループから省略します。
例C.1「CFS2およびcLVMのクラスタ設定」 (369 ページ)で言及されるその他す
べてのリソースはセットアップに関係なくクラスタ内で設定でき、実行しま
す。
370
高可用性ガイド
クラスタ管理ツール
High Availability Extensionには、クラスタをコマンドラインから管理する際に
役立つ、包括的なツールセットが付属しています。この章では、CIBおよびク
ラスタリソースでのクラスタ構成を管理するために必要なツールを紹介しま
す。リソースエージェントを管理する他のコマンドラインツールや、セット
アップのデバッグ(およびトラブルシューティング)に使用するツールについて
は、第20章トラブルシューティング (353 ページ)で説明されています。
注記: crmshの使用
これは、エキスパート専用のツールです。通常、crmシェル(crmsh)を使用
したクラスタ管理が推奨されている方法です。
次のリストは、クラスタ管理に関連するいくつかの作業を示しており、これ
らの作業を実行するために使用するツールを簡単に説明しています。
クラスタのステータスの監視
crm_monコマンドでは、クラスタのステータスと設定を監視できます。
出力には、ノード数、uname、uuid、ステータス、クラスタで設定された
リソース、それぞれの現在のステータスが含まれます。crm_monの出力
は、コンソールに表示したり、HTMLファイルに出力したりできます。
statusセクションのないクラスタ設定ファイルが指定された場合、crm_mon
はファイルに指定されたノードとリソースの概要を作成します。このツー
ルの使用法およびコマンド構文に関する詳細については、crm_monマニュ
アルページを参照してください。
D
CIBの管理
cibadminコマンドは、CIBを操作するための低レベル管理コマンドです。
CIBのすべてまたは一部のダンプ、CIBのすべてまたは一部の更新、すべ
てまたは一部の変更、CIB全体の削除、その他のCIB管理操作に使用でき
ます。このツールの使用法およびコマンド構文に関する詳細については、
cibadminマニュアルページを参照してください。
設定の変更の管理
crm_diffコマンドは、XMLパッチの作成と適用をサポートします。クラ
スタの環境設定の2つのバージョンの違いを視覚的に確認する場合や、変
更を保存しておき、後でcibadminを使用して適用する場合には便利で
す。このツールの使用法およびコマンド構文に関する詳細については、
crm_diffマニュアルページを参照してください。
CIB属性の操作
crm_attributeコマンドで、CIBで使用されているノード属性およびク
ラスタ設定オプションを問い合わせて操作できます。このツールの使用法
およびコマンド構文に関する詳細については、crm_attributeマニュア
ルページを参照してください。
クラスタ設定の検証
crm_verifyコマンドは、設定データベース(CIB)の整合性およびその他
の問題を確認します。設定を含むファイルを確認したり、実行中のクラス
タに接続したりできます。2種類の問題を報告します。エラーを解決しな
いと High Availability Extensionが正常に機能できず、警告の解決は管理者
が担当します。cm_verifyは新規または変更された設定の作成を支援し
ます。実行中のクラスタのCIBのローカルコピーを作成し、編集し、
crm_verifyを使用して検証し、新規設定をcibadminを使用して適用で
きます。このツールの使用法およびコマンド構文に関する詳細について
は、crm_verifyマニュアルページを参照してください。
リソース設定の管理
crm_resourceコマンドは、クラスタ上でリソース関連のさまざまなア
クションを実行します。設定されたリソースの定義の変更、リソースの始
動と停止、リソースの削除およびノード間でのマイグレートを実行できま
す。このツールの使用法およびコマンド構文に関する詳細については、
crm_resourceマニュアルページを参照してください。
372
高可用性ガイド
リソースの失敗回数の管理
crm_failcountコマンドは、所定のノードのリソースごとの失敗回数を
問い合わせます。このツールは、失敗回数のリセットにも使用でき、リ
ソースが頻繁に失敗したノード上で再度実行できるようにします。この
ツールの使用法およびコマンド構文に関する詳細については、
crm_failcountマニュアルページを参照してください。
ノードのスタンバイステータスの管理
crm_standbyコマンドは、ノードのスタンバイ属性を操作します。スタ
ンバイモードのノードはすべて、リソースをホストすることができず、そ
のノードにあるリソースは削除する必要があります。スタンバイモードは
カーネルの更新などの保守作業を行う場合に便利です。ノードを再びクラ
スタの完全にアクティブなメンバーにするには、ノードからスタンバイ属
性を削除します。このツールの使用法およびコマンド構文に関する詳細に
ついては、crm_standbyマニュアルページを参照してください。
クラスタ管理ツール
373
クラスタアップグレードとソフ
トウェアパッケージの更新
この章では、SUSE® Linux Enterprise High Availability Extensionの別バージョン
(メジャーリリースまたはサービスパック)にクラスタをアップグレードするシ
ナリオおよびクラスタノード上でパッケージを個別に更新するシナリオの2種
類を取り上げます。
E.1 用語集
次に、この章で使用される最も重要な用語の定義を示します。
メジャーリリース , 一般出荷(GA)バージョン
SUSE Linux Enterprise (または任意のソフトウェア製品)のメジャーリリー
スとは、新しい機能やツールを導入する、非推奨になっていたコンポーネ
ントを削除する、後方互換性のない変更が存在する、などの特徴を持った
新バージョンです。
サービスパック(SP)
複数のパッチを組み合わせて、インストールまたは展開しやすい形式にし
ます。サービスパックには番号が付けられ、通常、プログラムのセキュリ
ティ修正、更新、アップグレード、または拡張機能が含まれます。
アップデート
パッケージの新しいマイナーバージョンのインストール。
E
アップグレード
パッケージまたは配布の新しい主要バージョンのインストール。これによ
り新機能がもたらされます。
E.2 最新の製品バージョンへのクラス
タアップグレード
サポートされるアップグレードパスおよびアップグレードの実行方法は、ク
ラスタが実行されている現在の製品バージョンおよび移行したいターゲット
バージョンによって異なります。アップグレードに関する一般的な情報につ
いては、『SUSE Linux Enterprise Server 11 導入ガイド』の「SUSE Linux
Enterpriseのアップデート」の章を参照してください。http://www.suse
.com/documentation/で入手できます。
重要: アップグレード前に必要な準備
• システムバックアップが最新で、復元可能かどうかを確認します。
• 運用環境で実行する前に、まず、クラスタセットアップのステージング
インスタンスでアップグレード手順をテストします。
これにより、メンテナンス期間に要するタイムフレームを予測できます。
発生する可能性のある予期しない問題を検出し、解決するのにも役立ち
ます。
E.2.1 SLES 10からSLE HA 11へのアップグレー
ド
重要: クラスタのオフライン化が必要
SUSE Linux Enterprise Server 10からSUSE Linux Enterprise Server 11 (任意の
サービスパック)にマイグレートするには、すべてのクラスタノードをオフ
ラインにして、クラスタ全体をマイグレートする必要があります。SUSE
376
高可用性ガイド
Linux Enterprise Server 10とSUSE Linux Enterprise Server 11が混在した状態で
のマイグレートはサポートされていません。
運用上の便宜を考慮して、SUSE Linux Enterprise High Availability Extensionに
はhb2openais.shスクリプトが付属しています。このスクリプトを使用す
ると、HeartbeatからOpenAISクラスタスタックにデータを移動しながら、その
データを変換できます。このスクリプトは、/etc/ha.d/ha.cfに保存され
ている環境設定を解析し、OpenAISクラスタスタック用の新しい環境設定ファ
イルを生成します。さらに、CIBを調整してOpenAIS表記規則と一致させ、
OCFS2ファイルシステムを変換し、EVMSをcLVMで置き換えます。EVMS2コ
ンテナは、すべて、cLVM2ボリュームに変換されます。CIB内の既存リソー
スで参照されるボリュームグループの場合は、新しいLVMリソースが作成さ
れます。
クラスタをSUSE Linux Enterprise Server 10 SP4からSUSE Linux Enterprise Server
11に正しくマイグレートするには、次の手順を実行する必要があります。
1. SUSE Linux Enterprise Server 10 SP4クラスタを準備する (378 ページ)
2. SUSE Linux Enterprise 11にアップグレードする (379 ページ)
3. 変換をテストする (379 ページ)
4. データの変換 (380 ページ)
変換が正常に完了したら、アップグレード後のクラスタを再度オンラインに
することができます。
注記: アップグレード後の復帰
SUSE Linux Enterprise Server 11へのアップグレードプロセスの完了後に、
SUSE Linux Enterprise Server 10に戻ることはできません。
E.2.1.1 準備とバックアップ
クラスタを次の製品バージョンへアップグレードし、適宜、データを変換す
るには、その前に、現在のクラスタを準備する必要があります。
クラスタアップグレードとソフトウェアパッケージの更新
377
手順 E.1 SUSE Linux Enterprise Server 10 SP4クラスタを準備する
1 クラスタにログインします。
2 Heartbeat環境設定ファイル/etc/ha.d/ha.cfをレビューし、すべての通
信メディアがマルチキャストをサポートしているかどうかチェックします。
3 次のファイルがすべてのノードで等しいことを確認します。/etc/ha.d/
ha.cfおよび/var/lib/heartbeat/crm/cib.xml
4 各ノードでrcheartbeat stopを実行することで、すべてのノードをオフ
ラインにします。
5 最新バージョンへの更新前の一般的なシステムバックアップ(推奨)に加え
て、次のファイルをバックアップします。これらのファイルは、SUSE Linux
Enterprise Server 11へのアップグレード後の変換スクリプトの実行で必要に
なります。
• /var/lib/heartbeat/crm/cib.xml
• /var/lib/heartbeat/hostcache
• /etc/ha.d/ha.cf
• /etc/logd.cf
6 EVMS2リソースがある場合は、非LVM EVMS2ボリュームをSUSE Linux
Enterprise Server 10上の互換ボリュームに変換します。これらは、変換処理
中(E.2.1.3項「データの変換」 (379 ページ)参照)に、LVM2ボリュームグルー
プになります。変換後は、vgchange -c yを使用して、各ボリュームグ
ループをHigh Availabilityクラスタのメンバとして必ずマークしてください。
E.2.1.2 アップグレード/インストール
クラスタを準備してファイルをバックアップしたら、クラスタノード上でSUSE
Linux Enterprise 11のフレッシュインストールを行います。
378
高可用性ガイド
手順 E.2 SUSE Linux Enterprise 11にアップグレードする
1 すべてのクラスタノードにSUSE Linux Enterprise Server 11をフレッシュイン
ストールします。
2 すべてのクラスタノードで、SUSE Linux Enterprise High Availability Extension
11を、SUSE Linux Enterprise Server上のアドオンとしてインストールしま
す。詳細については、3.3項「アドオンとしてのインストール」 (30 ページ)
を参照してください。
E.2.1.3 データの変換
SUSE Linux Enterprise Server 11およびHigh Availability Extensionのインストー
ルが完了したら、データ変換を開始できます。High Availability Extensionとと
もに出荷される変換スクリプトは、注意深く設定されていますが、完全な自
動モードですべての設定を行うことはできません。このスクリプトでは、実
行する変更について管理者に警告し、対話と管理者側での決定を必要としま
す。管理者は、クラスタの詳細を知っている必要があり、変更の妥当性を検
証する責任があります。変換スクリプトは、/usr/lib/heartbeat(64ビッ
トマシンの場合は、/usr/lib64/heartbeat)に格納されています。
注記: テストランの実行
変換プロセスをよく知るために、まず、変換をテストすること(変更なしで)
を強くお勧めします。同じテストディレクトリを使用すると、ファイルを1
回コピーするだけで、テストランを繰り返すことができます。
手順 E.3 変換をテストする
1 ノードの1つで、テストディレクトリを作成し、そのテストディレクトリに
バックアップファイルをコピーします。
$
$
$
$
$
mkdir /tmp/hb2openais-testdir
cp /etc/ha.d/ha.cf /tmp/hb2openais-testdir
cp /var/lib/heartbeat/hostcache /tmp/hb2openais-testdir
cp /etc/logd.cf /tmp/hb2openais-testdir
sudo cp /var/lib/heartbeat/crm/cib.xml /tmp/hb2openais-testdir
2 次のコマンドで、テストランを開始します。
$ /usr/lib/heartbeat/hb2openais.sh -T /tmp/hb2openais-testdir -U
64ビットシステムを使用する場合は、次のコマンドを使用します。
クラスタアップグレードとソフトウェアパッケージの更新
379
$ /usr/lib64/heartbeat/hb2openais.sh -T /tmp/hb2openais-testdir -U
3 結果として生成されたopenais.confファイルとcib-out.xmlファイル
を読んで検証します。
$ cd /tmp/hb2openais-testdir
$ less openais.conf
$ crm_verify -V -x cib-out.xml
変換段階の詳細については、インストールしたHigh Availability Extension
の/usr/share/doc/packages/pacemaker/README.hb2openaisを参照
してください。
手順 E.4 データの変換
テストランを実行し、出力をチェックしたら、データ変換を開始できます。
変換は、1つのノードで実行するだけで済みます。メインクラスタ設定(CIB)
が自動的にその他のノードにレプリケートされます。レプリケートの必要が
ある他のすべてのファイルは、変換スクリプトによって自動的にコピーされ
ます。
1 変換スクリプトで他のクラスタノードにファイルを正常にコピーするため、
rootに許可されたアクセスでsshdがすべてのノードで実行されているこ
とを確認します。
2 すべてのOCFS2ファイルシステムがマウント解除されていることを確認し
ます。
3 High Availability ExtensionにはデフォルトのOpenAIS設定ファイルが付属し
ています。以降の手順で、デフォルトの環境設定を上書きしたくない場合
は、/etc/ais/openais.conf環境設定ファイルのコピーを作成します。
4 変換スクリプトをrootとして起動します。sudoを使用する場合は、-uオプ
ションで特権ユーザを指定します。
$ /usr/lib/heartbeat/hb2openais.sh -u root
/etc/ha.d/ha.cfに保存されている環境設定に基づいて、スクリプトは、
OpenAISクラスタスタック用の新しい環境設定ファイル/etc/ais/openais
.confを生成します。スクリプトは、CIBの設定を分析し、Heartbeatから
OpenAISへの変更に伴いクラスタ設定の変更が必要かどうか通知してきま
380
高可用性ガイド
す。すべてのファイル処理は、変換が実行されるノードで行われ、他のノー
ドにレプリケートされます。
5 画面の指示に従います。
変換が正常に完了したら、新しいクラスタスタックを「3.5.7項「クラスタを
オンラインにする」 (53 ページ)」の説明に従って起動します。
アップグレードプロセスの完了後、SUSE Linux Enterprise Server 10に戻ること
はできません。
E.2.1.4 その他の情報
変換スクリプトおよび変換の各段階の詳細については、インストールしたHigh
Availability Extensionの/usr/share/doc/packages/pacemaker/README
.hb2openaisを参照してください。
E.2.2 SLE HA 11からSLE HA 11 SP1へのアッ
プグレード
注記: サービスパックのバージョン間のローリングアップグレード
既存のクラスタを、あるサービスパックバージョンから次のサービスパッ
クバージョンへ適切に移行するには、各ノードを次々にアップグレードす
る「ローリングアップグレード」を実行します。
SUSE Linux Enterprise High Availability Extension 11 SP1で、主要なクラスタ設
定ファイルが/etc/ais/openais.confから/etc/corosync/corosync
.confへ変更されるときに、スクリプトが必要な変換を実行します。それら
は、openaisパッケージの更新時に自動的に実行されます。
手順 E.5 ローリングアップグレードを実行する
警告: 更新中のアクティブなクラスタスタック
実行中のクラスタに属するノード上でソフトウェアパッケージを更新する
には、そのノードでクラスタスタックを停止してから、ソフトウェアの更
クラスタアップグレードとソフトウェアパッケージの更新
381
新を開始します。状況によっては(クラスタスタックを停止する条
件 (385 ページ)を参照)、クラスタを保守モードにしてこの更新を実行できる
こともあります(この機能はSUSE Linux Enterprise High Availability Extension
11 SP4以降で使用可能です)。
ソフトウェアの更新中にノード上のクラスタリソースマネージャがアクティ
ブな場合、アクティブノードのフェンシングのような予期しない結果を招
く場合があります。
1 アップグレードするノードでrootとしてログインし、OpenAISを停止しま
す。
rcopenais stop
2 システムバックアップが最新で、復元可能かどうか確認します。
3 SUSE Linux Enterprise Server 11からSUSE Linux Enterprise Server 11 SP1、お
よびSUSE Linux Enterprise High Availability Extension 11からSUSE Linux
Enterprise High Availability Extension 11 SP1へのアップグレードを実行しま
す。お使いの製品のアップグレード方法の詳細については、『SUSE Linux
Enterprise Server 11 SP1 Deployment Guide』の「Updating SUSE Linux
Enterprise」の章を参照してください。
4 アップグレードしたノードでOpenAIS/Corosyncを再起動して、ノードをク
ラスタに再加入させます。
rcopenais start
5 次のノードをオフラインにし、そのノードに関して手順を繰り返します。
E.2.3 SLE HA 11 SP1からSLE HA 11 SP2への
アップグレード
SUSE Linux Enterprise High Availability Extension 11 SP1から11 SP2への既存の
クラスタのマイグレートはローリングアップグレードで行います。これは、
バージョン11から11 SP1へのアップグレード手順と同様です。
手順E.5「ローリングアップグレードを実行する」 (381 ページ)で説明したよう
に実行します。ただし、次の2つの点は異なります。
382
高可用性ガイド
• ステップ 3 (382 ページ)で、SUSE Linux Enterprise Server 11 SP1からSUSE
Linux Enterprise Server 11 SP2、およびSUSE Linux Enterprise High Availability
Extension 11 SP1からSUSE Linux Enterprise High Availability Extension 11 SP2
へのアップグレードを実行します。
32ビットアーキテクチャ用のXen Hypervisorは廃止されたので、パッケージ
drbd-xenの依存関係を手動で解決することが必要になる場合があります。
クロスプラットフォームクラスタはサポートされていないことに注意して
ください。
• SP2に付属するカーネルアップデートのため、ステップ 3 (382 ページ)とス
テップ 4 (382 ページ)の間でノードを再起動します。
重要: ローリングアップグレードの時間制限
SUSE Linux Enterprise High Availability Extension 11 SP2に装備されている新
機能は、すべてのクラスタノードが最新の製品バージョンにアップグレー
ドされた後でないと使用できません。SP1/SP2の混合クラスタは、ローリン
グアップグレード中の短いタイムフレームのみ、サポートされます。ロー
リングアップグレードは1週間以内に完了してください。
E.2.4 SLE HA 11 SP2からSLE HA 11 SP3への
アップグレード
SUSE Linux Enterprise High Availability Extension 11 SP2から 11 SP3への既存の
クラスタのマイグレートはローリングアップグレードで行います。これは、
バージョン 11から 11 SP1へのアップグレード手順と同様です。
手順E.5「ローリングアップグレードを実行する」 (381 ページ)で説明したよう
に実行しますが、次の点が異なります。ステップ 3 (382 ページ)で、SUSE Linux
Enterprise Server 11 SP2からSUSE Linux Enterprise Server 11 SP3、およびSUSE
Linux Enterprise High Availability Extension 11 SP2からSUSE Linux Enterprise High
Availability Extension 11 SP3へのアップグレードを実行します。
重要: ローリングアップグレードの時間制限
SUSE Linux Enterprise High Availability Extension 11 SP3に装備されている新
機能は、すべてのクラスタノードが最新の製品バージョンにアップグレー
クラスタアップグレードとソフトウェアパッケージの更新
383
ドされた後でないと使用できません。SP2/SP3の混合クラスタは、ローリン
グアップグレード中の短いタイムフレームのみ、サポートされます。ロー
リングアップグレードは1週間以内に完了してください。
E.2.5 SLE HA 11 SP3からSLE HA 11 SP4への
アップグレード
SUSE Linux Enterprise High Availability Extension 11 SP3から 11 SP4への既存の
クラスタのマイグレートはローリングアップグレードで行います。これは、
バージョン 11から 11 SP1へのアップグレード手順と同様です。
手順E.5「ローリングアップグレードを実行する」 (381 ページ)で説明したよう
に実行しますが、次の点が異なります。ステップ 3 (382 ページ)で、SUSE Linux
Enterprise Server 11 SP3からSUSE Linux Enterprise Server 11 SP4、およびSUSE
Linux Enterprise High Availability Extension 11 SP3からSUSE Linux Enterprise High
Availability Extension 11 SP4へのアップグレードを実行します。
注記: CIB構文バージョンのアップグレード
リソースをグループ化するタグと一部のACLの機能は、pacemaker-2.0以
上のCIB構文バージョンでのみ動作します。(現在のバージョンを確認するに
は、cibadmin -Q |grep validate-withを実行します)。SUSE Linux
Enterprise High Availability Extension 11 SP3からアップグレードした場合、
デフォルトではCIBバージョンがアップグレードされません。最新のCIBバー
ジョンに手動でアップグレードするには、以下のコマンドのいずれかを使
用します:
root # cibadmin --upgrade --force
または
root # crm configure upgrade force
重要: ローリングアップグレードの時間制限
SUSE Linux Enterprise High Availability Extension 11 SP4に装備されている新
機能は、すべてのクラスタノードが最新の製品バージョンにアップグレー
ドされた後でないと使用できません。SP3/SP4の混合クラスタは、ローリン
384
高可用性ガイド
グアップグレード中の短いタイムフレームのみ、サポートされます。ロー
リングアップグレードは1週間以内に完了してください。
E.3 クラスタノード上のソフトウェア
パッケージの更新
警告: 更新中のアクティブなクラスタスタック
実行中のクラスタに属するノード上でソフトウェアパッケージを更新する
には、そのノードでクラスタスタックを停止してから、ソフトウェアの更
新を開始します。状況によっては(クラスタスタックを停止する条
件 (385 ページ)を参照)、クラスタを保守モードにしてこの更新を実行できる
こともあります(この機能はSUSE Linux Enterprise High Availability Extension
11 SP4以降で使用可能です)。
ソフトウェアの更新中にノード上のクラスタリソースマネージャがアクティ
ブな場合、アクティブノードのフェンシングのような予期しない結果を招
く場合があります。
ノード上にパッケージ更新をインストールする前に、次の内容を確認してく
ださい。
クラスタスタックを停止する条件
• その更新は、SUSE Linux Enterprise High Availability ExtensionまたはGeo
Clustering for SUSE Linux Enterprise High Availability Extensionアドオンに属す
るパッケージに影響しますか。影響する場合は、ソフトウェアの更新を開
始する前に、ノード上でクラスタスタックを停止します。
root # rcopenais stop
• パッケージ更新には再起動が必要ですか。必要な場合は、ソフトウェアの
更新を開始する前に、ノード上でクラスタスタックを停止します。
root # rcopenais stop
クラスタアップグレードとソフトウェアパッケージの更新
385
これらの状況のいずれにも該当しない場合は、クラスタスタックを停止する
必要はありません。その場合は、ソフトウェアの更新を開始する前に、クラ
スタを保守モードにします。
root # crm configure property maintenance-mode=true
保守モードの詳細については、4.7項「メンテナンスモード」 (97 ページ)を
参照してください。
更新が正常にインストールされたら、次のコマンドを使用して、クラスタの
保守モードを解除してください。
root # crm configure property maintenance-mode=true
または、次のコマンドを使用して、各ノード上でクラスタスタックを再起動
してください。
root # rcopenais start
E.4 その他の情報
アップグレード先の製品の変更点と新機能の詳細については、それぞれのリ
リースノートを参照してください。リリースノートは、https://www.suse
.com/releasenotes/で入手できます。
386
高可用性ガイド
新機能
以降のセクションでは、バージョン移行に伴う重要なソフトウェア変更の概
要を示します。この概要では、たとえば、基本設定の完全な再設定が行われ
たか、設定ファイルが他の場所へ移動されたか、または他の顕著な変更が行
われたかどうかを示しています。
詳細と最新情報については、それぞれのプロダクトバージョンのリリースノー
トを参照してください。これらは、/usr/share/doc/release-notesに
あるインストール済みシステム、またはオンライン(https://www.suse
.com/releasenotes/)で入手できます。
F.1 バージョン10 SP3からバージョン
11への変更点
SUSE Linux Enterprise Server 11では、クラスタスタックがHeartbeatからOpenAIS
に変更されています。OpenAISは、業界標準のAPIとしてService Availability
Forumが発行しているApplication Interface Specification (AIS)を実装しています。
SUSE Linux Enterprise Server 10のクラスタリソースマネージャも残っています
が、大幅に機能が強化され、OpenAISに移植され、現在はPacemakerと呼ばれ
ています。
SUSE® Linux Enterprise Server 10 SP3からSUSE Linux Enterprise Server 11への
High Availabilityコンポーネントの変更内容の詳細については、以降のセクショ
ンを参照してください。
F
F.1.1 新しく追加された機能
マイグレーションのしきい値と失敗タイムアウト
High Availability Extensionに、マイグレーションのしきい値と失敗タイム
アウトの概念が含まれるようになりました。新しいノードへのマイグレー
トを行う基準となるリソースの失敗回数を定義できます。デフォルトで
は、管理者がリソースの失敗回数を手動でリセットするまで、ノードは失
敗したリソースを実行できなくなります。ただし、リソースの
failure-timeoutオプションを設定することで、リソースの失敗回数を
失効させることができます。
リソースと操作のデフォルト
リソースオプションと操作にグローバルなデフォルトを設定できるように
なりました。
オフラインの設定変更のサポート
設定をアトミックに更新する前に、一連の変更の影響をプレビューするこ
とが望ましい場合が多くあります。設定の「シャドーイング」コピーを作
成して、実行前にコマンドラインインタフェースで編集し、アクティブな
クラスタ設定を個別に変更できるようになりました。
ルール、オプション、操作セットの再利用
ルール、instance_attributes、meta_attributes、および操作セットは、1度定
義しておけば、複数の箇所で参照できます。
CIB内の特定操作に対するXPath式の使用
CIBでXPathベースのcreate、modify、delete操作が使用できるように
なりました。詳細は、cibadminのヘルプテキストを参照してください。
多次元のコロケーションと順序の制約
一連のコロケーションリソースを作成する場合、これまではリソースグ
ループを定義するか(設計を必ずしも正確に表現していない場合があった)、
個別の制約として各関係を定義するかのいずれかが可能でした。その結
果、リソースや組み合わせの数が増加するにつれて、制約も膨大なものに
なることもありました。今回、resource_setsの定義によって別な形式
でコロケーションの制約を指定できるようになりました。
クラスタ化されていないマシンからのCIBへの接続
Pacemakerがマシンにインストールされていれば、マシン自体がクラスタ
に属していない場合でもクラスタに接続できます。
388
高可用性ガイド
反復アクションを既知の回数トリガ
デフォルトでは、リソースの開始時刻に対して相対的に反復アクションが
スケジュールされますが、これが適切ではない場合がありました。操作を
相対的に実施する日付/時刻を指定するため、操作の間隔開始時刻を設定
します。クラスタはこの時刻を使用して、開始時刻+(間隔 * N)で操作を開
始するように、適切な開始遅延を計算します。
F.1.2 変更された機能
リソースとクラスタオプションに関する命名規則
すべてのリソースとクラスタオプションには、アンダースコア(_)の代わ
りにダッシュ(-)を使用するようになりました。たとえばmaster_maxメタ
オプションは、master-maxという名前に変更されました。
master_slaveリソースの名前変更
master_slaveリソースは、masterという名前に変更されました。マス
タリソースは、2つのモードのいずれかで実行可能な特殊なクローンタイ
プです。
属性のコンテナタグ
attributesコンテナタグは削除されました。
前提条件の操作フィールド
pre-req操作フィールドは、requiresという名前に変更されました。
操作間隔
すべての操作に間隔を指定する必要があります。開始および停止操作の場
合、間隔は0(ゼロ)に設定する必要があります。
コロケーション属性と順序の制約
コロケーション属性および順序の制約の名前をわかりやすく変更しまし
た。
障害によるマイグレーションのためのクラスタオプション
resource-failure-stickinessクラスタオプションは、
migration-thresholdクラスタオプションに替わりました。「マイグ
レーションのしきい値と失敗タイムアウト」 (388 ページ)も参照してくだ
さい。
新機能
389
コマンドラインツールの引数
コマンドラインツールの引数が一定になりました。「リソースとクラスタ
オプションに関する命名規則」 (389 ページ)も参照してください。
XMLの検証と解析
クラスタ設定はXMLで作成されます。従来のDTD(文書型定義)の代わり
に、より強力なRELAX NGスキーマを使用して、構造とコンテンツのパ
ターンを定義するようになりました。libxml2はパーサとして使用しま
す。
idフィールド
idフィールドは、次の制限を持つXML IDになりました。
• IDにコロンを含めることはできません。
• IDは数字から開始できません。
• IDはグローバルに固有なものでなければなりません(そのタグで固
有なだけではなく)。
他のオブジェクトの参照
一部のフィールド(リソースへの参照が制約されるフィールドなど)はIDREF
です。これは、設定を有効にするためには、それらのフィールドが既存の
リソースまたはオブジェクトを参照する必要があることを意味します。そ
のため、別な場所で参照されているオブジェクトの削除は失敗します。
F.1.3 削除された機能
リソースメタオプションの設定
リソースメタオプションを最上位の属性として設定できなくなりました。
代わりにメタ属性を使用してください。crm_resourceのマニュアルペー
ジも参照してください。
グローバルデフォルトの設定
リソースと操作デフォルトはcrm_configから読み込まれなくなりました。
390
高可用性ガイド
F.2 バージョン11からバージョン11 SP1
への変更点
クラスタ設定ファイル
主要なクラスタ設定ファイルが/etc/ais/openais.confから/etc/
corosync/corosync.confへ変更されました。両方のファイルは非常
によく似ています。SUSE Linux Enterprise High Availability Extension 11か
らSP1にアップグレードするときに、スクリプトがこれらのファイル間の
わずかな違いを処理します。
ローリングアップグレード
既存のクラスタを最小限のダウンタイムでマイグレートするために、SUSE
Linux Enterprise High Availability Extensionでは、SUSE Linux Enterprise High
Availability Extension 11から11 SP1への「ローリングアップグレード」を
実行できます。クラスタをオンラインにしたまま、次々とノードをアッ
プグレードします。
自動クラスタ展開
クラスタの展開を容易にするため、AutoYaSTでは、既存ノードをクロー
ンできます。AutoYaSTは、インストールデータと設定データを含む
AutoYaSTロファイルを使用して、ユーザの介入なしで、自動的に、1つ以
上のSUSE Linux Enterpriseシステムをインストールするためのシステムで
す。このプロファイルによって、インストールする対象と、インストール
したシステムが最終的に完全に使用準備が整ったシステムになるように設
定する方法がAutoYaSTに指示されます。このプロファイルは、さまざま
な方法で、大量展開に使用できます。
設定ファイルの転送
SUSE Linux Enterprise High Availability Extensionには、クラスタ内の全ノー
ド間で設定ファイルを複製するためのツール、Csync2が付属しています。
このツールは、多数のホストを処理できます。また、一定のサブグループ
のホストだけでファイルを同期することも可能です。Csync2との同期を必
要とするファイルとホスト名を設定するにはYaSTを使用します。
クラスタ管理用Webインターフェイス
High Availability Extensionには、管理作業用のWebベースのユーザインタ
フェースであるHA Web Konsole (Hawk)も付属しています。このインター
フェイスを使用すると、Linux以外のコンピュータからも、Linuxクラスタ
新機能
391
を監視および管理できます。このインタフェースは、システムにグラフィ
カルユーザインタフェースがなかったり、使用できない場合も理想的なソ
リューションです。
リソース設定用テンプレート
コマンドラインインターフェイスを使用してリソースを作成および設定す
る際に、さまざまなリソーステンプレートから選択して、素早く容易に設
定できるようになりました。
負荷ベースのリソース配置
特定のノードが提供する容量と特定のリソースが要求する容量を定義し、
クラスタで配置ストラテジの1つを選択することによって、リソースをそ
れらの負荷インパクトに従って配置して、クラスタパフォーマンスの低下
を防ぐことができます。
クラスタ対応型アクティブ/アクティブRAID 1
cmirrordの使用によって、2つの独立したSANから回復力の早いストレー
ジ設定を作成できるようになりました。
読み取り専用GFS2のサポート
GFS2からOCFS2への移行を容易にするため、GFS2ファイルシステムを読
み取り専用モードでマウントして、OCFS2ファイルシステムにデータをコ
ピーできます。OCFS2はSUSE Linux Enterprise High Availability Extensionに
よって完全にサポートされています。
OCFS2用SCTPサポート
冗長リングが設定されている場合、OCFS2とDLMは、自動的に、ネット
ワークデバイスボンディングから独立したSCTPによる冗長通信パスを使
用します。
ストレージ保護
データ破損からストレージを保護するためにセキュリティレイヤを追加す
るには、IOフェンシング(external/sbdフェンシングデバイスによる)と
sfexリソースエージェントの組み合わせを使用して、排他的なストレー
ジアクセスを確保できます。
Sambaクラスタリング
High Availability Extensionが、トリビアルデータベースのクラスタ実装で
あるCTDBをサポートするようになりました。これにより、クラスタ化さ
392
高可用性ガイド
れたSambaサーバを設定できるようになり、異機種環境にもHigh Availability
ソリューションを提供できるようになりました。
IP負荷分散用YaSTモジュール
新しいモジュールでは、グラフィカルユーザインタフェースによるカーネ
ルベースの負荷分散の設定が可能です。これは、Linux仮想サーバを管理
し、実サーバを監視するユーザスペースデーモンldirectordのフロント
エンドです。
F.3 バージョン11 SP1からバージョン
11 SP2への変更点
Geoクラスタ(マルチサイトクラスタ) (271 ページ)
ローカルクラスタとメトロエリアクラスタの他に、SUSE® Linux Enterprise
High Availability Extension 11 SP4は、マルチサイトクラスタもサポートし
ています。これは、それぞれひとつのローカルクラスタで持った複数の地
理的に離れたサイトを持てることを意味します。これらクラスタ間のフェー
ルオーバーは、より高いレベルのエンティティであるboothによって管理
されます。SUSE Linux Enterprise High Availability Extensionの個別オプショ
ンとして、マルチサイトクラスタに対するサポートが提供されています。
アクセス制御リスト (239 ページ)
クラスタ設定の任意の部分に対してきめ細かいアクセス権を定義するため
の、ACLがサポートされました。この機能をCRMで有効にした場合、ク
ラスタ管理ツールで利用できる機能は、ユーザに割り当てられた役割とア
クセス権によって決まります。
自動のクラスタセットアップ(sleha-bootstrap) (31 ページ)
クラスタセットアップを短時間で容易に行えるようにするための、ブート
ストラップスクリプトsleha-initおよびsleha-joinを使用できます。
これらはそれぞれ、1ノードクラスタを数分程度で設定して動作させるた
めのもの、そして他のノードを参加させるためのものです。ブートスト
ラッププロセス中に設定されたオプションは、YaSTクラスタモジュール
で後で変更できます。
新機能
393
Corosyncユニキャストモード
デフォルトは依然マルチキャストですが、ノード間の通信のためにユニ
キャストを使用することもサポートされました。詳細については、3.5.2項
「通信チャネルの定義」 (38 ページ)を参照してください。
HA Web Konsole (Hawk)
Hawkの機能が大幅に強化されました。グローバルクラスタのプロパティ、
基本タイプと詳細タイプのリソース、制約およびリソース監視を設定でき
るようになりました。Hawkは、クラスタステータスの詳細な分析のため
に、クラスタレポート(hb_report)を生成します。クラスタの履歴を表示
できます。また、シミュレータにより、可能性のある障害シナリオを検討
することができます。詳細については、第5章クラスタリソースの設定と
管理(Webインタフェース) (101 ページ)を参照してください。
リソーステンプレート (66 ページ)
よく似たリソースの設定を容易にするため、どのクラスタ管理ツールで
も、リソーステンプレートを定義して、プリミティブや特定のタイプの制
約で参照できるようになりました。
仮想化とクラウドの統合
リソースを負荷インパクトに基づいて配置できるよう、High Availability
Extensionは、ノードの容量とリソースの要件の両方を自動的に検出するよ
うになりました。仮想マシンの最小要件(たとえば、XenまたはKVMゲス
トに割り当てられるメモリまたはCPUコア数)は、リソースエージェント
が検出できます。使用属性(要件または容量を定義するために使用される)
は、自動的にCIBに追加されます。詳細については、4.4.6項「負荷インパ
クトに基づくリソースの配置」 (87 ページ)を参照してください。
ノードのネットワーク接続が、多数の並列XenまたはKVMのライブ移行の
ために過負荷になるのを防ぐため、新しいグローバルクラスタプロパティ、
migration-limitが導入されました。これにより、TEが1つのノードで
並列に実行できるマイグレーションジョブの数を制限することができま
す。デフォルトは-1に設定されていますが、これは、並列移行数の制限
はないことを示しています。
conntrackツール
クラスタノード間の接続ステータスを同期するため、High Availability
Extensionはconntrack-toolsを使用します。これによって、カーネル内
の接続トラッキングシステムとやり取りでき、iptablesでのステートフル
394
高可用性ガイド
なパケット検査を可能になります。詳細については、3.5.5項「クラスタ
ノード間の接続ステータスの同期」 (49 ページ)を参照してください。
並列SSH (pssh)
ノードごとにログインせずにすべてのクラスタノードでコマンドを実行す
るには、psshを使用します。詳細については、20.5項「その
他」 (360 ページ)を参照してください。
crm resource secret
STONITHまたは他のリソースのパスワードを、cib.xmlとは独立に設定
するには、crm resource secretを使用します。詳細については、7.5
項「cib.xmlから独立したパスワードの設定」 (217 ページ)を参照してく
ださい。
Sambaクラスタリング
Active Directoryドメインに参加するCTDBの機能は改良されました。詳細
については、18.3項「Active Directoryドメインへの追加」 (335 ページ)を
参照してください。
Rearによる障害復旧 (341 ページ)
Rear (Relaxおよび回復)は、障害復旧イメージを作成するための管理者ツー
ルセットです。障害復旧情報はネットワークを通して、またはローカルで
ハードディスク、USBデバイス、DVD/CD-R、テープなどに保存できま
す。バックアップデータはNFS (Network File System)に保存されます。
OCFS2上のクォータ
OCFS2ファイルシステム上でクォータを使用するには、適切なクォータ機
能またはオプションを使用して、ファイルシステムを作成し、マウントし
ます。オプションはursquota (個々のユーザのためのクォータ)または
grpquota (グループのためのクォータ)です。
F.4 バージョン11 SP2からバージョン
11 SP3への変更点
クラスタリソースの設定と管理(Webインタフェース) (101 ページ)
ここでもHawkの機能が強化されています。たとえば、Hawkによる新機能
の［Cluster Dashboard］を使用して、複数のクラスタを監視できます。
新機能
395
Hawkのシミュレータでも、ノードのステータスを変更したり、リソース
や制約を追加または編集したり、シミュレータ実行のためのクラスタ設定
を変更したりできるようになりました。これ以外にも、HA Web Konsole
では多くの詳細な機能が強化されています。
Pacemaker GUI
X11ベースのPacemaker GUIは保守モードに移行し、SUSE Linux Enterprise
High Availability Extension 11のライフサイクル間で新機能を受け取ること
はスケジュールされていません。SUSE Linux Enterprise High Availability
Extension 12では、HA Web Konsole (Hawk)がHigh Availability Extensionのデ
フォルトのグラフィカルユーザインタフェースになる予定です。
既存のクラスタからのノードの削除 (35 ページ)
sleha-removeブートストラップスクリプトにより、クラスタから1つの
ノードを簡単に削除できるようになりました。
保守モードの使用 (137 ページ)
1つのノードを保守モードにする必要がある場合があります。クラスタが
4つ以上のノードで構成されている場合は、1つのノードを保守モードにし
て、その他のノードで通常の操作を続行することが簡単にできます。
クラスタリソースグループの構成 (210 ページ)
crmシェルのグループコマンドが強化されグループの変更が可能になりま
した。リソースのグループへの追加、リソースのグループからの削除、グ
ループメンバーの順序変更が可能になっています。
グループの使用属性
使用属性を持つ複数のリソースがグループ化されていたり、これらにコロ
ケーション制約がある場合、High Availability Extensionではそのことを考
慮に入れます。可能な場合、これらのリソースは、すべての容量要件を満
たすことができるノードに配置されます。使用属性の詳細については、
4.4.6項「負荷インパクトに基づくリソースの配置」 (87 ページ)を参照し
てください。
デフォルトのプローブタイムアウト
リソースの監視操作に特定のタイムアウトが設定されていない場合、CRM
がプローブのタイムアウトを自動的に計算するようになりました。詳細に
ついては、4.2.9項「タイムアウト値」 (77 ページ)を参照してください。
これまでは、特定のタイムアウトが設定されていない場合、プローブのデ
396
高可用性ガイド
フォルトのタイムアウトはクラスタ全体のデフォルトの操作タイムアウト
を継承していました。
システムヘルスの監視 (95 ページ)
ノードがディスク容量が使い尽くしたために、そこに割り当てられたリ
ソースを適切に管理できなくなることを避けるため、High Availability
Extensionでは、ocf:pacemaker:SysInfoというリソースエージェント
が提供されています。これを使用して、ディスクパーティションに関する
ノードのヘルスを監視します。
4.5.1項「Nagiosプラグインを使用したリモートホストでのサービスの監
視」 (92 ページ)
クラスタダイアグラム
crmシェルとHawkの両方で、CIB内で設定されたノードとリソースのグラ
フィカル表現の表示機能が提供されるようになりました。詳細について
は、7.1.7項「クラスタダイアグラム」 (198 ページ)と5.1.2項「メイン画面:
クラスタステータス」 (104 ページ)を参照してください。
ボンディングスレーブのホットプラグ (255 ページ)
ボンディングスレーブのインタフェースを別のものに置き換える必要が生
じることがあります。たとえば、それぞれのネットワークデバイスに常に
障害が発生する場合などです。このソリューションはボンディングスレー
ブのホットプラグを設定するためのもので、YaSTによってサポートされ
るようになりました。
cmirrordの構成 (305 ページ)
High Availability ExtensionはcmirrordでRAID 10をサポートします。1つ
のミラーログに複数の物理ボリュームを追加できるようになりました。
さらに、lvcreateコマンドのmirroredオプションもサポートされ、一
時的に切断されたミラーを非常に速く再同期できるようになりました。
Active Directoryドメインへの追加 (335 ページ)
YaSTは、Active Directoryドメインを追加するためのCTDB機能をサポート
するようになりました。
新機能
397
F.5 バージョン11 SP3からバージョン
11 SP4への変更点
全般
• クラスタ名、ノード名、クラスタリソース、および制約で一貫性の
ある命名スキームを導入し、それをマニュアルに適用しました付録
A 命名規則 (363 ページ)を参照してください。(Fate#314938)。
• crmシェル例の一貫性を改善しました。
• エージェントリストを記述した「HA OCFエージェント」の章を削
除しました。この削除に伴い、「トラブルシューティングとリファ
レンス」の部分も削除し、トラブルシューティング (353 ページ)の
章を付録に移動しました。
• Geo Clustering for SUSE Linux Enterprise High Availability Extensionの
マニュアルを別のドキュメントに移動しました(Fate#316120)。地理
的に離れたクラスタの使用方法および設定方法の詳細については、
『Geo Clustering for SUSE Linux Enterprise High Availability Extension
クイックスタート』を参照してください。http://www.suse.com/
documentation/または/usr/share/doc/manual/sle-ha-geo
-manuals_en/の下にあるインストール済みシステムから入手で
きます。
• master-slaveリソースの用語を変更しました。現在はアップス
トリームマニュアルでmulti-stateリソースと呼ばれています。
• スクリーンショットを更新しました。
• hb_reportとcrm_reportの両方を詳細なクラスタレポートを作
成するためのコマンドラインツールとして記載しました。
• テクニカルフィードバックに基づいて、マニュアルに対してさまざ
まなバグの修正と追加を行いました。
398
高可用性ガイド
第1章製品の概要
(3 ページ)
• 一貫性の理由から、マルチサイトクラスタから地理的に離れた(ま
たはGeo)クラスタに用語を変更しました。
• アドオン製品としてのSUSE Linux Enterprise High Availability Extension
およびGeo Clustering for SUSE Linux Enterprise High Availability
Extensionの可用性に関するセクションを追加しました(1.1項「アド
オン/拡張としての可用性」 (3 ページ))。
第2章システム要件と推奨事項
(19 ページ)
• コンテンツを再構築しました。
• 非標準のSSHポート使用時におけるクラスタレポートの作成方法を
記載しました(Fate#314906)。詳細については、「SSH」 (23 ページ)
を参照してください。
第3章インストールと基本セットアップ
(25 ページ)
• No-Start-on-Bootパラメータに関するメモを追加しました
(Fate#317778)。
第4章設定および管理の基本事項
(59 ページ)
• 4.1.3項「オプションstonith-enabled」 (61 ページ)では、グロー
バルクラスタオプションstonith-enabledがfalseに設定される
場合のDLMサービスのポリシー変更について記載しています
(Fate#315195)。
• 4.4.7項「タグの使用によるリソースのグループ化」 (91 ページ)で
は、コロケーションや、それらの間の順序関係を作成しないで、概
念的に関連するリソースをグループ化する新しいオプションについ
て説明しています(Fate#318109)。
• 4.4.1.1項「リソースセット」 (81 ページ)では、制約を定義するた
めの別のフォーマットとしてリソースセットの概念について説明し
ています。
• クラスタ全体を保守モードに設定するオプションも記載するため、
4.7項「メンテナンスモード」 (97 ページ)を再構築しました。
新機能
399
• pacemaker_remoteサービスの属性を表4.1「プリミティブリソー
スのオプション」 (70 ページ)に追加し、新しいセクションとして
4.5項「リモートホストでのサービスの管理」 (91 ページ)を追加し
ました。
第5章クラスタリソースの設定と管理(Webインタフェース)
(101 ページ)
• 第4章設定および管理の基本事項 (59 ページ)で説明されている新機
能を反映させるため、章を更新しました。
• Geoクラスタに関連するすべてのHawk機能の説明を別のドキュメン
トに移動しました。新しい『Geo Clustering for SUSE Linux Enterprise
High Availability Extensionクイックスタート』(http://www.suse
.com/documentation/から入手可能)を参照してください。
第7章クラスタリソースの設定と管理(コマンドライン)
(189 ページ)
• 7.3.4.3項「依存性なしのリソースセットのコロケーショ
ン」 (205 ページ)を追加しました(Fate#314917)。
• リソースのタグ付けに関するセクションを追加しました
(Fate#318109): 7.4.5項「リソースのグループ化/タグ付
け」 (215 ページ)。
• 第4章設定および管理の基本事項 (59 ページ)で説明されている新機
能を反映させるため、章を更新しました。
第9章フェンシングとSTONITH (227 ページ)
• STONITHリソースのクローン作成が不要になったので、例から削
除しました。
• テスト専用のSTONITHデバイスをいくつか削除しました。
• external/kdumpcheckリソースエージェントを削除し、代わり
にfence_kdumpリソースエージェントの設定例を追加しました。
第10章アクセス制御リスト
(239 ページ)
• 10.5項「HawkによるACLの設定」 (246 ページ)を追加しました。
400
高可用性ガイド
• CIB検証バージョンのアップグレード後に使用可能になる新しい
ACL機能に従って章を更新しました。詳細については、CIB構文
バージョンのアップグレード (384 ページ)を参照してください。
SUSE Linux Enterprise High Availability Extension 11 SP3からアップグ
レードする一方で、それまで使用してきたCIBバージョンを保持し
ている場合は、『High Availability Guide for SUSE Linux Enterprise
High Availability Extension 11 SP3』の「アクセス制御リスト」の章
を参照してください。http://www.suse.com/documentation/
から入手できます。
第17章ストレージ保護
(317 ページ)
• 17.1.3.2項「ソフトウェアウォッチドッグのセットアッ
プ」 (322 ページ): ウォッチドッグおよびウォッチドッグタイマにア
クセスする他のソフトウェアに関するメモを追加しました
(https://bugzilla.suse.com/show_bug.cgi?id=891340)。
• 17.1.3.2項「ソフトウェアウォッチドッグのセットアッ
プ」 (322 ページ): ブート時にウォッチドッグドライバをロードする
方法を追加しました(https://bugzilla.suse.com/show_bug
.cgi?id=892344)。
• 17.1.3.5項「フェンシングリソースの設定」 (325 ページ): msgwait
タイムアウト(https://bugzilla.suse.com/show_bug.cgi
?id=891346)に関連したstonith-timeoutの長さに関するアド
バイスを追加しました。
• 17.1.3.3項「SBDデーモンの起動」 (324 ページ)を調整しました
(https://bugzilla.suse.com/show_bug.cgi?id=891499)。
• no-quorum-policy=ignoreによってクラスタに発生するダブル
フェンシングを、STONITHリソース設定にpcmk_delay_maxパラ
メータを使用することで回避する方法について説明しています
(Fate#31713)。
第19章 Rearによる障害復旧 (341 ページ)
この章は全面的に改訂され、Rearバージョン1.16に更新されました。
新機能
401
SUSE Linux Enterprise High Availability Extension 11 SP4には、RPMパッケー
ジrearに付属するバージョン1.10.0およびRPMパッケージrear116に
付属するバージョン1.16の2つのバージョンのRearが付属しています。
Rearバージョン1.10.0のマニュアルについては、『High Availability Guide
for SUSE Linux Enterprise High Availability Extension 11 SP3』を参照してく
ださい。http://www.suse.com/documentation/から入手できます。
第20章トラブルシューティング
(353 ページ)
• 非標準のSSHポート使用時におけるクラスタレポートの作成方法を
記載しました(Fate#314906)。詳細については、「すべてのクラスタ
ノードの分析を含むレポートを作成するにはどうしたらよいです
か。」 (355 ページ)を参照してください。
HA OCFエージェント
この章は削除されました。OCFリソースエージェントに関する最新情報
は、7.1.3項「OCFリソースエージェントに関する情報の表示」 (193 ページ)
で説明されているように、インストール済みシステムで表示できます。
付録A 命名規則 (363 ページ)
• このマニュアルで使用する命名スキームについて説明している新し
い付録。
付録E クラスタアップグレードとソフトウェアパッケージの更新 (375 ページ)
• 用語の定義が追加されました: E.1項「用語集」 (375 ページ)。
• E.2.5項「SLE HA 11 SP3からSLE HA 11 SP4へのアップグレー
ド」 (384 ページ)がE.2項「最新の製品バージョンへのクラスタアッ
プグレード」 (376 ページ)に追加されました。
• E.3項「クラスタノード上のソフトウェアパッケージの更
新」 (385 ページ)が追加されました。
402
高可用性ガイド
用語集
アクティブ/アクティブ、アクティブ/パッシブ
サービスがノード上で実行される方法の概念。アクティブ/パッシブシナ
リオでは、1つ以上のサービスがアクティブノード上で実行され、パッシ
ブノードはアクティブノードの失敗を待機します。アクティブ/アクティ
ブでは、各ノードがアクティブであると同時にパッシブです。たとえば、
一部のサービスは実行されていますが、それ以外のサービスは他のノード
から引き継ぐことができます。DRBDのプライマリ/セカンダリとデュアル
プライマリに類似しています。
アービトレータ
Geoクラスタ内の追加インスタンスで、サイト間にまたがるリソースの
フェールオーバーなどの決定に関する合意の形成を手助けします。アービ
トレータは専用モードで1つまたは複数のブースインスタンスを実行する
単一のマシンです。
AutoYaST
AutoYaSTは、ユーザの介入なしで、1つ以上のSUSE Linux Enterpriseシス
テムを自動的にインストールするためのシステムです。
bindnetaddr (バインドネットワークアドレス)
Corosyncエグゼクティブのバインド先のネットワークアドレス。
ブース
Geoクラスタのサイト間のフェールオーバープロセスを管理するインスタ
ンス。その目的は、1つのサイトのみでマルチサイトリソースをアクティ
ブにすることです。これは、サイトをダウンする必要のある場合、クラス
タサイト間のフェールオーバードメインとして処理される、いわゆるチ
ケットを使用することで可能になります。
boothd (ブースデーモン)
Geoクラスタ内のそれぞれの参加クラスタおよびアービトレータが、サー
ビスであるboothdを実行します。これは、別のサイトで実行している
ブースデーモンに接続し、接続性の詳細を交換します。
CCM (コンセンサスクラスタメンバーシップ)
CCMは、どのノードがクラスタを設定するか決定し、この情報をクラス
タで共有します。ノードまたはクォーラムの新規追加および損失は、CCM
によって通知されます。CCMモジュールはクラスタの各ノード上で実行
されます。
CIB (クラスタ情報ベース)
クラスタの設定とステータス(クラスタオプション、ノード、リソース、
制約、相互の関係性)の全体的な表現。XMLで作成され、メモリに常駐し
ます。マスタCIBは、DC (指定コーディネータ)で保持および保守され、他
のノードに複製されます。CIBに対する通常の読み書き操作は、マスタCIB
によってシリアルに処理されます。
クラスタ
「ハイパフォーマンス」クラスタは、結果を早く出すためにアプリケー
ション負荷を共有するコンピュータ(実際または仮想のコンピュータ)のグ
ループです。高可用性クラスタは、サービスの可用性を最大にすることを
第一に設計されています。
クラスタパーティション
1つ以上のノードとその他のクラスタ間で通信が失敗した場合は、常にク
ラスタパーティションが発生します。クラスタのノードはパーティション
に分割されますが、アクティブなままです。これらは同じパーティション
内のノードのみと通信可能で、切り離されたノードは認識しません。つま
り、他のパーティションのノードの損失は確認できないため、スプリット
ブレインシナリオが作成されます(スプリットブレイン (409 ページ)も参
照)。
同時実行違反
クラスタ内の1つのノードだけで実行する必要があるリソースが、複数の
ノード上で実行されています。
conntrackツール
カーネル内の接続トラッキングシステムとやり取りできるようにして、
iptablesでのステートフルなパケット検査を可能にします。High Availability
Extensionによって、クラスタノード間の接続ステータスを同期化するため
に使用されます。
CRM (クラスタリソースマネージャ)
すべての非ローカルインタラクションの調整に責任を負う主要管理エン
ティティ。High Availability Extensionでは、PacemakerをCRMとして使用し
ます。クラスタの各ノードにはノード独自のCRMインスタンスがありま
すが、DC上で実行されるCRMインスタンスは、決定を他の非ローカル
404
高可用性ガイド
CRMに中継し、それらからの入力を処理するために選択されたものです。
CRMは、いくつかのコンポーネント(CRM自身のノードとその他のノード
両方のローカルリソースマネージャ、非ローカルCRM、管理コマンド、
フェンシング機能、メンバーシップ層、およびブース)と対話します。
crmd (クラスタリソースマネージャデーモン)
CRMは、crmdというデーモンとして実装されます。 crmdは各クラスタ
ノード上にインスタンスを持ちます。マスタとして動作するcrmdインスタ
ンスを1つ選択することにより、クラスタのすべての意思決定が一元化さ
れます。選択したcrmdプロセス(またはそのプロセスが実行されているノー
ド)で障害が発生したら、新しいcrmdプロセスが確立されます。
crmsh
コマンドラインユーティリティcrmshは、クラスタ、ノード、およびリソー
スを管理します。
詳細については、第7章クラスタリソースの設定と管理(コマンドライ
ン) (189 ページ)を参照してください。
Csync2
クラスタ内のすべてのノード、およびGeoクラスタ全体に設定ファイルを
複製するために使用できる同期ツールです。
DC (指定コーディネータ)
クラスタ内のCRMは、指定コーディネータ(DC)として選択されます。DC
は、ノードのフェンシングやリソースの移動など、クラスタ全体におよぶ
変更が必要かどうかを判断できる、クラスタ内で唯一のエンティティで
す。DCは、CIBのマスターコピーが保持されるノードでもあります。その
他すべてのノードは、現在のDCから設定とリソース割り当て情報を取得
します。DCは、メンバーシップの変更後、クラスタ内のすべてのノード
から選抜されます。
障害
自然、人、ハードウェアのエラー、ソフトウェアのバグなどによって引き
起こされる重要なインフラストラクチャの想定外の障害
障害復旧
障害復旧は、障害発生後、ビジネス機能を通常どおりの、安定した状態に
修復するプロセスです。
用語集
405
障害復旧プラン
ITインフラストラクチャへの影響を最小限に抑えながら障害から復旧する
戦略。
DLM (分散ロックマネージャ)
DLMは、クラスタファイルシステムのディスクアクセスを調整し、ファ
イルロッキングを管理して、パフォーマンスと可用性を向上します。
DRBD
DRBDは、高可用性クラスタを構築するためのブロックデバイスです。®
ブロックデバイス全体が専用ネットワーク経由でミラーリングされ、ネッ
トワークRAID-1として認識されます。
既存のクラスタ
「既存のクラスタ」という用語は、1つ以上のノードで構成されるクラス
タを指すものとして使用されます。既存のクラスタは、通信チャネルを定
義する基本的なCorosync設定を持ちますが、必ずしもリソース設定を持つ
とは限りません。
フェールオーバー
リソースまたはノードが1台のマシンで失敗し、影響を受けるリソースが
別のノードで起動されたときに発生します。
フェールオーバードメイン
ノード障害の発生時にクラスタサービスを実行することができる、指定さ
れたクラスタノードのサブセット。
フェンシング
孤立または失敗したクラスタメンバーによる共有リソースへのアクセス防
止の概念を示しています。クラスタノードが失敗した場合は、シャットダ
ウンまたはリセットすることで問題の発生を防止します。つまり、ステー
タスが不明なノードからリソースがロックアウトされます。
geoクラスタ(地理的に離れたクラスタ)
詳細については、Geoクラスタ (407 ページ)を参照してください。
負荷分散
複数のサーバを同じサービスに参加させて、同じ作業を行わせる機能。
406
高可用性ガイド
ローカルクラスタ
1つのロケーション内の単一のクラスタ(たとえば、すべてのノードが1つ
のデータセンターにある)。ネットワークの遅延時間は無視できます。ス
トレージは通常、すべてのノードに同時にアクセスされます。
LRM (ローカルリソースマネージャ)
リソースに対する操作の実行を担当します。リソースエージェントスクリ
プトを使用してこれらの操作を実行します。LRMはポリシーを認識して
いないという点で、「ダム」です。何をすべきか認識させるにはDCが必
要です。
mcastaddr (マルチキャストアドレス)
Corosyncエグゼクティブによるマルチキャストに使用されるIPアドレス。
このIPアドレスはIPv4またはIPv6のいずれかに設定できます。
mcastport (マルチキャストポート)
クラスタ通信に使用されるポート。
メトロクラスタ
すべてのサイトがファイバチャネルで接続された、複数の建物またはデー
タセンターにわたってストレッチできる単一のクラスタ。ネットワークの
遅延時間は通常は短くなります(約20マイルの距離で<5ms)。ストレージ
は頻繁にレプリケートされます(ミラーリングまたは同期レプリケーショ
ン)
multicast (マルチキャスト)
ネットワーク内で一対多数の通信に使用される技術で、クラスタ通信に使
用できます。Corosyncはマルチキャストとユニキャストの両方をサポート
しています。
Geoクラスタ
それぞれにローカルクラスタを持つ、複数の地理的に離れたサイトで構成
されます。サイトはIPによって交信します。サイト全体のフェールオー
バーはより高いレベルのエンティティ(ブース)によって調整されます。Geo
クラスタは限られたネットワーク帯域幅および高レイテンシに対応する必
要があります。ストレージは同期的にレプリケートされます。
ノード
クラスタのメンバで、ユーザには見えない(実際または仮想の)コンピュー
タ。
用語集
407
PE (ポリシーエンジン)
ポリシーエンジンはCIBでのポリシー変更を実装するために必要な処理を
計算します。PEは(リソース)アクションのリストと、次のクラスタ状態に
移るために必要な依存性を含む遷移グラフも作成します。PEは常にDC上
で実行されます。
クォーラム
クラスタでは、クラスタパーティションは、ノード(投票)の大多数を保有
する場合、クォーラムを持つ(「定数に達している」)と定義されます。
クォーラムはただ1つのパーティションで識別されます。複数の切断され
たパーティションまたはノードが処理を続行してデータおよびサービスが
破損されないようにする、アルゴリズムの一部です(スプリットブレイン)。
クォーラムはフェンシングの前提条件で、このためクォーラムは一意にな
ります。
RA (リソースエージェント)
プロキシとして機能してリソースを管理する(リソースの開始、停止、監
視などを行う)スクリプト。High Availability Extensionは、OCF (Open Cluster
Framework)リソースエージェント、LSB (Linux Standards Base)リソースエー
ジェント(標準のLSB initスクリプト)、Heartbeatリソースエージェントとい
う3種類のリソースエージェントをサポートしています。詳細については、
4.2.2項「サポートされるリソースエージェントクラス」 (63 ページ)を参
照してください。
Rear (Relaxおよび回復)
障害復旧イメージを作成するための管理ツールセット。
リソース
Pacemakerに認識されている、任意のタイプのサービスまたはアプリケー
ション。IPアドレス、ファイルシステム、データベースなどです。
「リソース」という用語は、DRBDでも使用されており、レプリケーショ
ン用の一般的な接続を使用しているブロックデバイスのセットの名前を表
します。
RRP (冗長リングプロトコル)
ネットワーク障害の一部または全体に対する災害耐性のために、複数の冗
長ローカルエリアネットワークが使用できるようになります。この方法で
は、ひとつのネットワークが作動中である限り、クラスタ通信を維持でき
ます。Corosyncはトーテム冗長リングプロトコルをサポートします。
408
高可用性ガイド
SBD (STONITHブロックデバイス)
すべてのノードが共有ストレージへのアクセスを持つ環境で、小さなパー
ティションを使用してディスクベースのフェンシングを行います。
SFEX (共有ディスクファイル排他制御)
SFEXはSANにおけるストレージ保護機能を提供します。
スプリットブレイン
クラスタノードが(ソフトウェアまたはハードウェア障害によって)互いに
認識しない2つ以上のグループに分割される場合のシナリオです。STONITH
によって、スプリットブレインがクラスタ全体に悪影響をおよぼさなくな
ります。「パーティションされたクラスタ」シナリオとも呼ばれます。
スプリットブレインという用語は、DRBDでも使用されますが、2つのノー
ドに異なるデータが含まれることを意味します。
SPOF (シングルポイント障害)
失敗するとクラスタ全体の障害をトリガしてしまう、クラスタのコンポー
ネント。
STONITH
「Shoot the other node in the head」の略です。動作異常のノードをシャット
ダウンすることでクラスタに問題を発生させないようにするフェンシング
メカニズムを指しています。
スイッチオーバー
クラスタ内の他のノードへの、予定されたオンデマンドのサービス移動。
詳細については、フェールオーバー (406 ページ)を参照してください。
チケット
Geoクラスタで使用されるコンポーネント。チケットは指定のクラスタサ
イトの特定のリソースを実行する権利を付与します。チケットは1度に1つ
のサイトだけが所有できます。リソースを特定のチケットに依存させるこ
とができます。定義されたチケットがサイトで使用できる場合のみそれぞ
れのリソースが始動します。その逆に、チケットが削除されると、そのチ
ケットに依存するリソースが自動的に停止します。
ユニキャスト
ひとつのあて先ネットワークにメッセージを送信する技術Corosyncはマル
チキャストとユニキャストの両方をサポートしています。Corosyncでは、
ユニキャストはUDP-unicast (UDPU)として実装されます。
用語集
409
GNU利用許諾契約書
この付録には、GNU Free Documentation Licenseバージョン1.2が含まれていま
す。
GNU Free Documentation License
Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to
copy and distribute verbatim copies of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone
the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License
preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the
GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should
come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any
textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose
is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed
under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions
stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You
accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or
translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or
authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject.
(Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter
of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
G
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the
Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant.
The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document
is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public,
that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for
drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats
suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to
thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of
text. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML
using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent
image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors,
SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced
by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License
requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent
appearance of the work's title, preceding the beginning of the body of the text.
A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text
that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications",
"Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ"
according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers
are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty
Disclaimers may have is void and has no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices,
and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to
those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute.
However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions
in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's
license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on
the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The
front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim
copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover,
and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy
along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has
access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter
option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will
remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or
retailers) of that edition to the public.
412
高可用性ガイド
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a
chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified
Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the
Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there
were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version
gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together
with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this
requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this
License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified
Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher
of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network
locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location
for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and
tone of each of the contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered
part of the section titles.
M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the
Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the
Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for
example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover
Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made
by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same
entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that
added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement
of any Modified Version.
GNU利用許諾契約書
413
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions,
provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant
Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there
are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section
titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise
combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim
copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License
into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT
WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution
medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond
what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which
are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate,
the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the
Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant
Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections
in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document,
and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and
disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will
prevail.
If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1)
will typically require changing the actual title.
414
高可用性ガイド
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy,
modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have
received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
10. FUTURE REVISIONS OF THIS
LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or
any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has
been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose
any version ever published (not as a draft) by the Free Software Foundation.
ADDENDUM: How to use this License
for your documents
Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled “GNU
Free Documentation License”.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with...Texts.” line with this:
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software
license, such as the GNU General Public License, to permit their use in free software.
GNU利用許諾契約書
415

Download Report