高可用性ガイド - suse linux enterprise high availability ...3.4...

高可用性ガイド

SUSE Linux Enterprise High AvailabilityExtension 11 SP4

高可用性ガイドSUSE Linux Enterprise High Availability Extension 11 SP4著者: Tanja Roth、Thomas Schraitle

発行日: 2020 年 5 月 18 日

SUSE LLC

1800 South Novell Place

Provo, UT 84606

USA

https://documentation.suse.com

Copyright © 2006–2020 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、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任

を負いかねます。

https://documentation.suse.comhttp://www.novell.com/company/legal/trademarks/tmlist.htmlhttp://www.novell.com/company/legal/trademarks/tmlist.html

目次

このガイドについて xii1 フィードバック xiii

2 マニュアルの表記規則 xiii

3 本マニュアルの作成について xiv

I インストールおよびセットアップ 1

1 製品の概要 21.1 アドオン/拡張としての可用性 2

1.2 主な機能 2広範なクラスタリングシナリオ 3 • 柔軟性 3 • ストレージとデータレプリ

ケーション 3 • 仮想化環境のサポート 4 • ローカル、メトロ、およびGeo

クラスタのサポート 4 • リソースエージェント 5 • ユーザフレンドリな管

理ツール 5

1.3 利点 6

1.4 クラスタ設定: ストレージ 9

1.5 アーキテクチャ 12アーキテクチャ層 12 • プロセスフロー 14

2 システム要件と推奨事項 162.1 ハードウェア要件 16

2.2 ソフトウェアの必要条件 16

2.3 ストレージ要件 17

2.4 その他の要件と推奨事項 17

3 インストールと基本セットアップ 213.1 用語の定義 21

iii 高可用性ガイド

3.2 概要 23

3.3 アドオンとしてのインストール 24

3.4 自動のクラスタセットアップ(sleha-bootstrap) 25

3.5 手動のクラスタセットアップ(YaST) 30YaSTクラスタモジュール 30 • 通信チャネルの定義 31 • 認証設定の定

義 36 • すべてのノードへの設定の転送 37 • クラスタノード間の接続

ステータスの同期 41 • サービスの設定 42 • クラスタをオンラインにす

る 44

3.6 AutoYaSTによる大量展開 45

II 設定および管理 47

4 設定および管理の基本事項 484.1 グローバルクラスタオプション 48

概要 48 • オプションno-quorum-policy 49 • オプションstonith-

enabled 50

4.2 クラスタリソース 50リソース管理 50 • サポートされるリソースエージェントクラス 51 • リ

ソースのタイプ 52 • リソーステンプレート 53 • 高度なリソースタイ

プ 53 • リソースオプション(メタ属性) 57 • インスタンス属性(パラメー

タ) 59 • リソース操作 61 • タイムアウト値 63

4.3 リソース監視 64

4.4 リソースの制約 65制約のタイプ 65 • スコアと無限大 68 • リソーステンプレートと制

約 68 • フェールオーバーノード 69 • フェールバックノード 70 • 負荷

インパクトに基づくリソースの配置 71 • タグの使用によるリソースのグループ

化 74

4.5 リモートホストでのサービスの管理 74Nagiosプラグインを使用したリモートホストでのサービスの監

視 74 • pacemaker_remoteを使用したリモートノードでのサービスの管

理 76

4.6 システムヘルスの監視 77

iv 高可用性ガイド

4.7 メンテナンスモード 78

4.8 その他の情報 79

5 クラスタリソースの設定と管理(Webインタフェース) 815.1 Hawk - 概要 81

Hawkの起動とログイン 81 • メイン画面: クラスタステータス 83

5.2 グローバルクラスタオプションの設定 87

5.3 クラスタリソースの設定 88セットアップウィザードでリソースを設定する 89 • 単純なクラスタリソースの

作成 90 • STONITHリソースの作成 92 • リソーステンプレートの使

用 93 • リソース制約の設定 95 • リソースフェールオーバーノードの指

定 99 • リソースフェールバックノードの指定(リソースの固着性) 100 • 負荷

インパクトに基づくリソース配置の設定 101 • リソース監視の設定 102 • ク

ラスタリソースグループの構成 104 • クローンリソースの設定 105

5.4 クラスタリソースの管理 106リソースの開始 107 • リソースのクリーンアップ 108 • クラスタリソースの削

除 109 • クラスタリソースの移行 109 • 保守モードの使用 111 • クラス

タ履歴の表示 113 • 可能性のある障害シナリオを調べる 115 • クラスタレ

ポートの生成 118

5.5 複数のクラスタの監視 118

5.6 GeoクラスタのＨａｗｋ 121

5.7 トラブルシューティング 121

6 クラスタリソースの設定と管理(GUI) 1236.1 Pacemaker GUI - 概要 123

クラスタにログインする 123 • メインウィンドウ 124


6.3 クラスタリソースの設定 127単純なクラスタリソースの作成 127 • STONITHリソースの作成 130 • リソー

ステンプレートの使用 131 • リソース制約の設定 132 • リソースフェール

オーバーノードの指定 136 • リソースフェールバックノードの指定(リソースの固

着性) 137 • 負荷インパクトに基づくリソース配置の設定 137 • リソース監視

v 高可用性ガイド

の設定 140 • クラスタリソースグループの構成 142 • クローンリソースの設

定 145

6.4 クラスタリソースの管理 146リソースの開始 147 • リソースのクリーンアップ 147 • クラスタリソースの削

除 148 • クラスタリソースの移行 149 • リソースの管理モードの変更 150

7 クラスタリソースの設定と管理(コマンドライン) 1527.1 crmsh - 概要 152

ヘルプの表示 153 • crmshのサブコマンドの実行 154 • OCFリソースエー

ジェントに関する情報の表示 155 • 設定テンプレートの使用 157 • シャドー

イング設定のテスト 159 • 設定の変更のデバッグ 159 • クラスタダイアグラ

ム 160


7.3 クラスタリソースの設定 161クラスタリソースの作成 161 • リソーステンプレートの作成 162 • STONITH

リソースの作成 163 • リソース制約の設定 164 • リソースフェールオー

バーノードの指定 167 • リソースフェールバックノードの指定(リソースの固着

性) 167 • 負荷インパクトに基づくリソース配置の設定 167 • リソース監視

の設定 170 • クラスタリソースグループの構成 170 • クローンリソースの設

定 171

7.4 クラスタリソースの管理 172新しいクラスタリソースの開始 172 • リソースのクリーンアップ 173 • クラス

タリソースの削除 173 • クラスタリソースのマイグレーション 174 • リソース

のグループ化/タグ付け 174 • 保守モードの使用 175

7.5 cib.xmlから独立したパスワードの設定 176

7.6 履歴情報の取得 176

7.7 詳細 178

8 リソースエージェントの追加または変更 1798.1 STONITHエージェント 179

8.2 OCFリソースエージェントの作成 179

8.3 OCF戻りコードと障害回復 180

vi 高可用性ガイド

9 フェンシングとSTONITH 1839.1 フェンシングのクラス 183

9.2 ノードレベルのフェンシング 184STONITHデバイス 184 • STONITHの実装 185

9.3 STONITHのリソースと環境設定 186STONITHリソースの設定例 186

9.4 フェンシングデバイスの監視 189

9.5 特殊なフェンシングデバイス 189

9.6 基本的な推奨事項 191

9.7 詳細 192

10 アクセス制御リスト 19310.1 要件と前提条件 193

10.2 クラスタでのACLの使用の有効化 194

10.3 ACLの基\'96\'7b事項 195XPath式によるACLルールの設定 195 • 短縮によるACLルールの設定 197

10.4 Pacemaker GUIによるACLの構成 197

10.5 HawkによるACLの設定 199

10.6 crmshによるACLの設定 200

11 ネットワークデバイスボンディング 20211.1 YaSTによるボンディングデバイスの設定 202

11.2 ボンディングスレーブのホットプラグ 205


12 Linux仮想サーバによる負荷分散 20812.1 概念の概要 208

Director 208 • ユーザスペースのコントローラとデーモン 209 • パケット転

送 209 • スケジューリングアルゴリズム 210

vii 高可用性ガイド

12.2 YaSTによるIP負荷分散の設定 210

12.3 追加設定 215


13 Geoクラスタ(マルチサイトクラスタ) 217

III ストレージおよびデータレプリケーション 218

14 OCFS2 21914.1 特長と利点 219

14.2 OCFS2のパッケージと管理ユーティリティ 220

14.3 OCFS2サービスとSTONITHリソースの設定 221

14.4 OCFS2ボリュームの作成 223

14.5 OCFS2ボリュームのマウント 225

14.6 OCFS2ファイルシステム上でクォータを使用する 226

14.7 詳細情報 227

15 DRBD 22815.1 概念の概要 228

15.2 DRBDサービスのインストール 230

15.3 DRBDサービスの設定 231

15.4 DRBDサービスのテスト 237

15.5 DRBDのチューニング 238

15.6 DRBDのトラブルシュート 239環境設定 239 • ホスト名 240 • TCPポート7788 240 • DRBDデバイス

が再起動後に破損した 240

15.7 詳細情報 241

16 Cluster Logical Volume Manager(cLVM) 24216.1 概念の概要 242

viii 高可用性ガイド

16.2 cLVMの環境設定 242cmirrordの構成 243 • クラスタリソースの作成 245 • シナリオ - SAN上で

iSCSIを使用するｃLVM 247 • シナリオ - DRBDを使用するｃLVM 251

16.3 有効なLVM2デバイスの明示的な設定 253

16.4 詳細 253

17 ストレージ保護 25417.1 ストレージベースのフェンシング 254

概要 254 • SBDデバイスの数 255 • ストレージベースの保護のセットアッ

プ 256

17.2 排他的ストレージアクティベーションの確保 262概要 262 • 設定 263


18 Sambaクラスタリング 26518.1 概念の概要 265

18.2 基本的な設定 266

18.3 Active Directoryドメインへの追加 269

18.4 クラスタ対応Sambaのデバッグとテスト 270


19 Rearによる障害復旧 27319.1 概念の概要 273

障害復旧プランの作成 273 • 障害復旧とは 274 • Rearによる障害復

旧 274 • Rearの要件 274 • Rearのバージョン 274 • Btrfsに伴う制限

事項 275 • シナリオとバックアップのツール 276 • 基本手順 276

19.2 Rearおよびバックアップソリューションのセットアップ 277

19.3 復旧インストールシステムの作成 278

19.4 復旧プロセスのテスト 279

19.5 障害からの復旧 279

ix 高可用性ガイド


IV 付録 281

20 トラブルシューティング 28220.1 インストールと最初のステップ 282

20.2 ログ記録 283

20.3 リソース 285

20.4 STONITHとフェンシング 287

20.5 その他 287


A 命名規則 290

B 単純なテストリソースのセットアップ例 291B.1 GUIによるリソースの設定 291

B.2 リソースの手動設定 292

C OCFS2およびcLVMの設定例 294

D クラスタ管理ツール 295

E クラスタアップグレードとソフトウェアパッケージの更新 297

E.1 用語集 297

E.2 最新の製品バージョンへのクラスタアップグレード 297SLES 10からSLE HA 11へのアップグレード 298 • SLE HA 11か

らSLE HA 11 SP1へのアップグレード 302 • SLE HA 11 SP1か

らSLE HA 11 SP2へのアップグレード 303 • SLE HA 11 SP2か

らSLE HA 11 SP3へのアップグレード 303 • SLE HA 11 SP3から

SLE HA 11 SP4へのアップグレード 304

E.3 クラスタノード上のソフトウェアパッケージの更新 305

E.4 その他の情報 306

x 高可用性ガイド

F 新機能 307F.1 バージョン10 SP3からバージョン11への変更点 307

新しく追加された機能 307 • 変更された機能 308 • 削除された機能 309

F.2 バージョン11からバージョン11 SP1への変更点 310

F.3 バージョン11 SP1からバージョン11 SP2への変更点 311



用語集 320

G GNU利用許諾契約書 326

xi 高可用性ガイド

このガイドについて

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の新機能と動作変更点が一

覧されています。クラスタを最新リリースバージョンに移行する方法を学び、単純なテストリソース

の設定例を参照してください。

xii SUSE Linux Enterp… 11 SP4

このマニュアル中の多くの章に、他の資料やリソースへのリンクが記載されています。それらは、システ

ム上で参照できる追加ドキュメントやインターネットから入手できるドキュメントなどです。

ご使用製品の利用可能なマニュアルと最新のドキュメントアップデートの概要については、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]宛のメールでも送信で

きます。ドキュメントのタイトル、製品のバージョン、およびドキュメントの発行日を明記してくださ

い。エラーの報告または機能拡張の提案では、問題について簡潔に説明し、対応するセクション

番号とページ(またはURL)をお知らせください。

2 マニュアルの表記規則本書では、次の書体を使用しています。

/etc/passwd :ディレクトリ名とファイル名

placeholder : placeholderは、実際の値で置き換えられます

PATH :環境変数PATH

ls , --help :コマンド、オプション、およびパラメータ

xiii フィードバック SUSE Linux Enterp… 11 SP4

http://www.suse.com/doc/http://www.suse.com/doc/http://www.suse.com/support/http://www.suse.com/support/http://www.suse.com/support/http://www.suse.com/doc/feedback.html

user :ユーザまたはグループ

Alt 、 Alt – F1 :押すためのキーまたはキーの組み合わせ、キーはキーボードと同様に、大文字

で表示されます

［ファイル］、［ファイル］［名前を付けて保存］:メニュー項目、ボタン

amd64, em64t この説明は、 amd64 、 em64t 、および ipfの各アーキテクチャにのみ当てはまりま

す。矢印は、テキストブロックの先頭と終わりを示します。

Dancing Penguins (「Penguins」の章、↑他のマニュアル):他のマニュアルの章への参照で

す。

3 本マニュアルの作成について本書は、DocBook(http://www.docbook.org を参照)のサブセットであるNovdocで作成されて

います。XMLソースファイルは xmllintによって検証され、 xsltprocによって処理され、Norman

Walshによるスタイルシートのカスタマイズ版を使用してXSL-FOに変換されました。最終的なPDF

は、RenderXのXEPによってフォーマットされています。

xiv 本マニュアルの作成について SUSE Linux Enterp… 11 SP4

http://www.docbook.org

I インストールおよびセットアップ

1 製品の概要 2

2 システム要件と推奨事項 16

3 インストールと基本セットアップ 21

1 製品の概要

SUSE® Linux Enterprise High Availability Extensionは、オープンソースクラスタ

化技術の統合スイートで、可用性の高い物理Linuxクラスタと仮想Linuxクラスタを実装

し、SPOF (シングルポイント障害)をなくします。データ、アプリケーション、サービスなどの重

要なネットワークリソースの高度な可用性と管理のしやすさを実現します。その結果、ミッショ

ンクリティカルなLinuxワークロードに対してビジネスの継続性維持、データ整合性の保護、

予期せぬダウンタイムの削減を行います。

基本的な監視、メッセージング、およびクラスタリソース管理の機能を標準装備し、個々の管

理対象クラスタリソースのフェールオーバー、フェールバック、およびマイグレーション(負荷

分散)をサポートします。

この章では、High Availability Extensionの主な製品機能と利点を紹介します。ここに

は、いくつかのクラスタ例が記載されており、クラスタを設定するコンポーネントについて学

ぶことができます。最後のセクションでは、アーキテクチャの概要を示し、クラスタ内の個々の

アーキテクチャ層とプロセスについて説明します。

High Availabilityクラスタのコンテキストでよく使用される用語については、用語集を参照

してください。

1.1 アドオン/拡張としての可用性High Availability Extensionは、SUSE Linux Enterprise Server 11 SP4に対するアドオンとし

て入手できます。Geo Clustering for SUSE Linux Enterprise High Availability Extensionとい

う、High Availability Extensionの個別の拡張として、地理的に離れたクラスタ(Geoクラスタ)に対す

るサポートが提供されています。

1.2 主な機能SUSE® Linux Enterprise High Availability Extensionでは、ネットワークリソースの可用性を確

保し、管理することができます。以降のセクションでは、いくつかの主要機能に焦点を合わせて説明しま

す。

2 アドオン/拡張としての可用性 SUSE Linux Enterp… 11 SP4

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クラスタリソースマネージャが標準装備されています。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)もサポート

しています。

3 広範なクラスタリングシナリオ SUSE Linux Enterp… 11 SP4

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内のクラスタリソースマネージャは、仮想サーバで実行中のサービスと物理サーバで実行

中のサービスを認識、監視、および管理できます。ゲストシステムは、クラスタにサービスとして管理され

ます。

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マイルの距離で

1.2.6 リソースエージェント

SUSE Linux Enterprise High Availability Extensionには、Apache、IPv4、IPv6、その他多数の

リソースを管理するための膨大な数のリソースエージェントが含まれています。またIBM WebSphere

Application Serverなどの一般的なサードパーティアプリケーション用のリソースエージェントも含ま

れています。ご利用の製品に含まれているOpen Cluster Framework (OCF)リソースエージェントの

概要は、7.1.3項「OCFリソースエージェントに関する情報の表示」で説明される crm raコマンドを使

用してください。

1.2.7 ユーザフレンドリな管理ツール

High Availability Extensionは、クラスタの基本的なインストールとセットアップのほか、効果的な設

定および管理に使用できる強力なツールセットを標準装備しています。

YaST

一般的なシステムインストールおよび管理用グラフィカルユーザインタフェース。3.3項「アドオン

としてのインストール」に示されているように、YaSTを使用してHigh Availability Extensionを

SUSE Linux Enterprise Serverの上にインストールします。YaSTでは、クラスタまたは個々の

コンポーネントの設定に役立つように、High Availabilityカテゴリ内の次のモジュールも提供し

ています。

クラスタ: 基本的なクラスタセットアップ。詳細については、3.5項「手動のクラスタセットアッ

プ(YaST)」を参照してください。

DRBD: Distributed Replicated Block Deviceの設定。

IP負荷分散: Linux仮想サーバによる負荷分散の設定。詳細については、第12章「Linux

仮想サーバによる負荷分散」を参照してください。

Pacemaker GUI

クラスタの設定と管理を容易にするインストール可能なグラフィカルユーザインタフェース。リソー

スの作成と設定の手順を順を追って支援し、リソースの起動、中止、移行などの管理作業を容易

にします。詳細については、第6章「クラスタリソースの設定と管理(GUI)」を参照してください。

HA Web Konsole (Hawk)

Linux以外のマシンから、Linuxクラスタを管理できるWebベースのユーザインタフェース。この

インタフェースは、システムにグラフィカルユーザインタフェースがない場合も理想的なソリュー

ションです。リソースの作成と設定の手順を順を追って支援し、リソースの起動、中止、移行などの

管理作業を容易にします。詳細については、第5章「クラスタリソースの設定と管理(Webインタ

フェース)」を参照してください。

5 リソースエージェント SUSE Linux Enterp… 11 SP4

crmシェル

リソースを設定し、すべての監視または管理作業を実行する、統合されたパワフルなコマンドラ

インインタフェースです。詳細については、第7章「クラスタリソースの設定と管理(コマンドライ

ン)」を参照してください。

1.3 利点High Availability Extensionでは最大 32台のLinuxサーバを可用性の高いクラスタ(HAクラスタ)

に設定し、クラスタ内の任意のサーバにリソースをダイナミックに切り替えたり、移動することができま

す。サーバ障害発生時のリソースの自動マイグレーションの設定ができます。また、ハードウェアのトラ

ブルシューティングやワークロードのバランスをとるために、リソースを手動で移動することもできます。

High Availability Extensionは、コモディティコンポーネントによる高可用性を提供しています。

アプリケーションと操作をクラスタに統合することによって、運用コストを削減できます。さらにHigh

Availability Extensionでは、クラスタ全体を一元管理し、変化するワークロード要件に応じてリソース

を調整することもできます(手動でのクラスタの「負荷分散」)。3ノード以上でクラスタを設定すると、複

数のノードが「ホットスペア」を共用できて無駄がありません。

その他にも重要な利点として、予測できないサービス停止を削減したり、ソフトウェアおよびハードウェ

アの保守やアップグレードのための計画的なサービス停止を削減できる点が挙げられます。

次に、クラスタによるメリットについて説明します。

可用性の向上

パフォーマンスの改善

運用コストの低減

スケーラビリティ

障害回復

データの保護

サーバの集約

ストレージの集約

共有ディスクサブシステムにRAID を導入することによって、共有ディスクの耐障害性を強化できます。

次のシナリオは、High Availability Extensionの利点を紹介するものです。

6 利点 SUSE Linux Enterp… 11 SP4

クラスタシナリオ例

サーバ3台でクラスタが設定され、それぞれのサーバにWebサーバをインストールしたと仮定します。

クラスタ内の各サーバが、2つのWebサイトをホストしています。各Webサイトのすべてのデータ、グラ

フィックス、Webページコンテンツは、クラスタ内の各サーバに接続された、共有ディスクサブシステム

に保存されています。次の図は、このクラスタのセットアップを示しています。

図 1.1: 3サーバクラスタ

通常のクラスタ操作では、クラスタ内の各サーバが他のサーバと常に交信し、すべての登録済みリソー

スを定期的にポーリングして、障害を検出します。

Webサーバ1でハードウェアまたはソフトウェアの障害が発生したため、このサーバを利用してインター

ネットアクセス、電子メール、および情報収集を行っているユーザの接続が切断されたとします。次の図

は、Webサーバ1で障害が発生した場合のリソースの移動を表したものです。

7 クラスタシナリオ例 SUSE Linux Enterp… 11 SP4

図 1.2: 1台のサーバに障害が発生した後の3サーバクラスタ

WebサイトAがWebサーバ2に、WebサイトBがWebサーバ3に移動します。IPアドレスと証明書もWeb

サーバ2とWebサーバ3に移動します。

クラスタを設定するときに、それぞれの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に移動。

8 クラスタシナリオ例 SUSE Linux Enterp… 11 SP4

この例では、フェールオーバープロセスが迅速に実行され、ユーザはWebサイトの情報へのアクセスを

数秒程度で回復できます。通常、再度ログインする必要はありません。

ここで、Webサーバ1で発生した問題が解決し、通常に操作できる状態に戻ったと仮定します。Webサ

イトAおよびWebサイトBは、Webサーバ1に自動的にフェールバック(復帰)することも、そのままの状

態を維持することもできます。これは、リソースの設定方法によって決まります。Webサーバ1へのマイグ

レーションは多少のダウンタイムを伴うため、High Availability Extensionではサービス中断がほと

んど、またはまったく発生しないタイミングまでマイグレーションを延期することもできます。いずれの場

合でも利点と欠点があります。

High Availability Extensionは、リソースマイグレーション機能も提供します。アプリケーション、Web

サイトなどをシステム管理の必要性に応じて、クラスタ内の他のサーバに移動することができます。

たとえば、WebサイトAまたはWebサイトBをWebサーバ1からクラスタ内の他のサーバに手動で移

動することができます。これは、Webサーバ1のアップグレードや定期メンテナンスを実施する場合、ま

た、Webサイトのパフォーマンスやアクセスを向上させる場合に有効な機能です。

1.4 クラスタ設定: ストレージHigh Availability Extensionでのクラスタ構成には、共有ディスクサブシステムが含まれる場合と含

まれない場合があります。共有ディスクサブシステムの接続には、高速ファイバチャネルカード、ケーブ

ル、およびスイッチを使用でき、また設定にはiSCSIを使用することができます。サーバの障害時には、ク

ラスタ内の別の指定されたサーバが、障害の発生したサーバにマウントされていた共有ディスクディレ

クトリを自動的にマウントします。この機能によって、ネットワークユーザは、共有ディスクサブシステム上

のディレクトリに対するアクセスを中断することなく実行できます。

重要: cLVMを伴う共有ディスクサブシステム共有ディスクサブシステムをcLVMと使用する場合、クラスタ内の、アクセスが必要なすべての

サーバにそのサブシステムを接続する必要があります。

一般的なリソースの例としては、データ、アプリケーション、およびサービスなどがあります。次の図は、一

般的なファイバチャネルクラスタの設定を表したものです。

9 クラスタ設定: ストレージ SUSE Linux Enterp… 11 SP4

図 1.3: 一般的なファイバチャネルクラスタの設定

ファイバチャネルは最も高いパフォーマンスを提供しますが、iSCSIを利用するようにクラスタを設定す

ることもできます。iSCSIは低コストなストレージエリアネットワーク(SAN)を作成するための方法として、

ファイバチャネルの代わりに使用できます。次の図は、一般的なiSCSIクラスタの設定を表したもので

す。


図 1.4: 一般的なISCSIクラスタの設定

ほとんどのクラスタには共有ディスクサブシステムが含まれていますが、共有ディスクサブシステムなし

のクラスタを作成することもできます。次の図は、共有ディスクサブシステムなしのクラスタを表したもの

です。

図 1.5: 共有ストレージなしの一般的なクラスタ設定


1.5 アーキテクチャこのセクションでは、High Availability Extensionアーキテクチャの概要を説明します。アーキテク

チャコンポーネントと、その相互運用方法について説明します。

1.5.1 アーキテクチャ層

High Availability Extensionのアーキテクチャは層化されています。図1.6「アーキテクチャ」に異な

る層と関連するコンポーネントを示します。

図 1.6: アーキテクチャ

12 アーキテクチャ SUSE Linux Enterp… 11 SP4

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に対応する)ことが必要にな

るたびに、ポリシーエンジンは現在の状態と設定に基づき、クラスタの次の状態を計算します。PE

は(リソース)アクションのリストと、次のクラスタ状態に移るために必要な依存性を含む遷移グラ

フも作成します。PEは常にDC上で実行されます。

LRM(ローカルリソースマネージャ)

LRMはCRMに代わってローカルリソースエージェントを呼び出します(1.5.1.3項「リソース

層」を参照)。そのため、操作の開始、停止、監視を行い、結果をCRMに報告します。LRMはその

ローカルノード上のすべてのリソース関連情報の信頼できるソースです。

13 アーキテクチャ層 SUSE Linux Enterp… 11 SP4

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のコンテンツはクラスタ全体で自動的に同期化されます。

クラスタ内で実行するアクションの多くは、クラスタ全体におよぶ変更を伴います。これらのアクションに

はクラスタリソースの追加や削除、リソース制約の変更などがあります。このようなアクションを実行する

場合は、クラスタ内でどのような変化が発生するのかを理解することが重要です。

たとえば、クラスタ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デバイス

14 プロセスフロー SUSE Linux Enterp… 11 SP4

は、その障害を簡単に監視できるように、リソースとしてモデル化(そしてCIB内で設定)されます。ただ

し、STONITHトポロジの把握はstonithdが担当し、そのクライアントはノードのフェンシングを要求す

るだけであり、残りの作業はstonithdが実行します。

15 プロセスフロー SUSE Linux Enterp… 11 SP4

2 システム要件と推奨事項

次のセクションでは、SUSE® Linux Enterprise High Availability Extensionのシステ

ム要件と前提条件について説明します。また、クラスタセットアップの推奨事項についても説

明します。

2.1 ハードウェア要件次のリストは、SUSE® Linux Enterprise High Availability Extensionに基づくクラスタのハード

ウェア要件を指定しています。これらの要件は、最低のハードウェア設定を表しています。クラスタの使

用方法によっては、ハードウェアを追加しなければならないこともあります。

2.2項「ソフトウェアの必要条件」に指定されたソフトウェアを搭載した1〜32台のLinuxサーバ。

各サーバが同一のハードウェア構成(メモリ、ディスクスペースなど)になっている必要はありませ

んが、アーキテクチャは同じである必要があります。クロスプラットフォームのクラスタはサポートさ

れていません。

クラスタノードあたり、少なくとも2つのTCP/IP通信メディア。クラスタノードは、ネットワーク設備

が使用したい通信手段をサポートするため、通信にマルチキャストまたはユニキャストを使用しま

す。通信メディアは100Mbit/s以上のデータレートをサポートする必要があります。可能であれ

ば、第11章「ネットワークデバイスボンディング」の説明に従ってEthernetの各チャネルを結合し

ます。別の方法として、Corosyncで冗長な通信チャネルとして2つ目のインタフェースを使用する

こともできます。手順3.7「冗長通信チャネルの定義」も参照してください。

オプション:クラスタ内の、アクセスが必要なすべてのサーバに接続された、共有ディスクサブシス

テム。詳細については、2.3項「ストレージ要件」を参照してください。

STONITHメカニズム。STONITHデバイスとは、クライアントが停止または誤動作しているとみな

したノードをリセットするために使用する電源スイッチです。これは、ハングして停止したようにしか

見えないノードによるデータ破損を防ぐ、唯一の信頼できる方法です。

2.2 ソフトウェアの必要条件次のソフトウェア要件を満たしていることを確認してください。

16 ハードウェア要件 SUSE Linux Enterp… 11 SP4

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を使用して耐障害性が高められ

るように設定してください。ハードウェアベースのRAIDをお勧めします。ホストベースのソフトウェ

アRAIDはどの設定でもサポートされていません。

共有ディスクシステムのアクセスにiSCSIを使用している場合、iSCSIイニシエータとターゲットを

正しく設定していることを確認します。

2台のマシンにデータを配分するミラーリングRAIDシステムを実装するためにDRBD*を使用す

る際、DRBDに提供されるデバイスにのみアクセスし、決してバッキングデバイスにはアクセスし

ないようにします。クラスタの残りが提供される冗長性を利用する、同じ(ボンドされた)NICを使用

します。

2.4 その他の要件と推奨事項サポートされていて、役に立つHigh Availabilityセットアップについては、次の推奨事項を検討してく

ださい。

クラスタノード数

各クラスタは2つ以上のクラスタノードで構成される必要があります。

17 ストレージ要件 SUSE Linux Enterp… 11 SP4

重要: 奇数のクラスタノード3ノードの「最小値」で「奇数」のクラスタノードを使用することを強くお勧めします。

クラスタではサービスの実行を維持するために、クォーラムが必要です。したがって、3ノー

ドのクラスタは一度に1ノードの障害しか許容できませんが、5ノードのクラスタは、2ノード

の障害を許容できます。

STONITH

重要: STONITHがない場合はサポートなしSTONITHがないクラスタはサポートされません。

サポートされるHigh Availabilityセットアップについては、次の点を確認してください。

High Availabilityクラスタの各ノードには、少なくとも1つのSTONITHデバイス(通常は

ハードウェア)が必要です。SBDを使用しない場合は、1ノードあたり複数のSTONITHデ

バイスを使用することを強くお勧めします。SBDは、外部電源スイッチなしでクラスタ内の

STONITHとフェンシングを有効にしますが、共有ストレージは必要とします。

グローバルクラスタオプション stonith-enabledおよび startup-fencingを trueに設

定する必要があります。これらのオプションを変更すると、ただちにサポートが失われます。

冗長通信パス

High Availabilityセットアップがサポートされるには、2つ以上の冗長パスでクラスタ通信を設

定する必要があります。これは次のように実行できます。

ネットワークデバイスボンディング。

Corosync内の2つ目の通信チャネル。詳細については、手順3.7「冗長通信チャネルの定

義」を参照してください。

可能であれば、ネットワークデバイスのボンディングを選択します。

時刻同期

クラスタノードはクラスタ外のNTPサーバに同期する必要があります。詳細については、『SUSE

Linux Enterprise Server 11 SP4 管理ガイド』(http://www.suse.com/doc/ から入手可

能)を参照してください。特に、「Time Synchronization with NTP」の章を参照してください。

ノードが同期されていない場合、ログファイルまたはクラスタレポートは分析が難しくなります。

NIC名

18 その他の要件と推奨事項 SUSE Linux Enterp… 11 SP4

http://www.suse.com/doc/

すべてのノード上で同一である必要があります。

ホスト名およびIPアドレス

クラスタ内の各サーバの /etc/hostsファイルを編集することにより、ホスト名の解決を設定しま

す。クラスタ通信の速度が落ちていない、またはDNSによって改ざんされていないことを確認する

には、次を実行します。

静的IPアドレスを使用します。

このファイルにあるすべてのクラスタノードを、完全修飾ホスト名およびショートホスト名で

一覧表示します。クラスタのメンバーが名前で互いを見つけられることが重要です。名前を

使用できない場合、内部クラスタ通信は失敗します。

詳細については、『SUSE Linux Enterprise Server 11 SP4 管理ガイド』(http://

www.suse.com/doc から入手可能)を参照してください。「ネットワークの基礎」の章、「YaST

によるネットワーク接続の設定」の「ホスト名とDNSの設定」セクションを参照してください。

ストレージ要件

一部のサービスでは、共有ストレージが必要な場合があります。詳細については、2.3項「スト

レージ要件」を参照してください。外部NFS共有またはDRBDを使用することもできます。外部

NFS共有を使用する場合は、冗長通信パスを介してすべてのクラスタノードから確実にアクセス

できる必要があります。詳細については、冗長通信パスを参照してください。

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で次善策を使用できます。


http://www.suse.com/dochttp://www.suse.com/dochttp://linux-ha.org/wiki/SBD_Fencing

パスワードなしでログインできるユーザを作成します(例、公開鍵認証の使用)。このユーザ

に sudoを設定し、 rootパスワードが必要ないようにします。 hb_reportをコマンドライン

から -uオプションで開始し、ユーザ名を指定します。詳細については、 hb_reportのマ

ニュアルページを参照してください。

履歴エクスプローラについては、現在のところ、パスワード不要のログインに代わる方法は

ありません。


3 インストールと基本セットアップ

この章では、SUSE® Linux Enterprise High Availability Extension 11 SP4を最初

からインストールしてセットアップする方法について説明します。自動セットアップまたは手

動セットアップから選択します。自動セットアップでは、クラスタを起動して数分で実行できま

す(後でオプションを調整する選択あり)。一方、手動セットアップでは、起動時に個々のオプ

ションを設定できます。

旧バージョンのSUSE Linux Enterprise High Availability Extensionを実行するクラ

スタを移行する場合や、実行中のクラスタに属するノードでソフトウェアパッケージを更新

する場合は、付録E クラスタアップグレードとソフトウェアパッケージの更新を参照してくださ

い。

3.1 用語の定義この章では、次に定義されるいくつかの用語を使用します。

既存のクラスタ

「既存のクラスタ」という用語は、1つ以上のノードで構成されるクラスタを指すものとして使用さ

れます。既存のクラスタは、通信チャネルを定義する基本的なCorosync設定を持ちますが、必ず

しもリソース設定を持つとは限りません。

マルチキャスト

ネットワーク内で一対多数の通信に使用される技術で、クラスタ通信に使用できます。Corosync

はマルチキャストとユニキャストの両方をサポートしています。マルチキャストが会社のITポリシー

に準拠しない場合、代わりにユニキャストを使用します。

注記: スイッチとマルチキャストクラスタ通信にマルチキャストを使用したい場合、ご使用のスイッチがマルチキャストをサ

ポートしていることを確認します。

マルチキャストアドレス( mcastaddr )

Corosyncエグゼクティブによるマルチキャストに使用されるIPアドレス。このIPアドレスはIPv4ま

たはIPv6のいずれかに設定できます。IPv6ネットワークを使用する場合は、ノードのIDを指定す

る必要があります。プライベートネットワークでは、どのようなマルチキャストアドレスでも使用でき

ます。

21 用語の定義 SUSE Linux Enterp… 11 SP4

マルチキャストポート( 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に設定します。

注記: すべてのノードのネットワークアドレスすべてのノード上で同じCorosync設定が使用されるため、ネットワークアドレスは、特定

のネットワークインタフェースのアドレスではなく、 bindnetaddrとして使用します。

冗長リングプロトコル(RRP)

ネットワーク障害の一部または全体に対する災害耐性のために、複数の冗長ローカルエリアネッ

トワークが使用できるようになります。この方法では、ひとつのネットワークが作動中である限り、

クラスタ通信を維持できます。Corosyncはトーテム冗長リングプロトコルをサポートします。信頼

できるソートされた方式でメッセージを配信するために、論理トークンパスリングがすべての参加

ノードに課せられます。ノードがメッセージをブロードキャストできるのは、トークンを保持している

場合のみです。詳細については、http://www.rcsc.de/pdf/icdcs02.pdf を参照してくださ

い。

Corosyncに定義済みの冗長通信チャネルを持つ場合、RRPを使用してこれらのインタフェース

の使用方法をクラスタに伝えます。RRPでは次の3つのモードを使用できます( rrp_mode )。

activeに設定した場合、Corosyncは両方のインタフェースをアクティブに使用します。

passiveに設定した場合、Corosyncは代わりに使用可能なネットワークを介してメッセー

ジを送信します。

noneに設定した場合、RRPは無効になります。

22 用語の定義 SUSE Linux Enterp… 11 SP4

http://www.rcsc.de/pdf/icdcs02.pdf

Csync2

クラスタ内のすべてのノード、およびGeoクラスタ全体に設定ファイルを複製するために使用で

きる同期ツールです。Csync2は、同期グループ別にソートされた任意の数のホストを操作でき

ます。各同期グループは、メンバーホストの独自のリストとその包含/除外パターン(同期グルー

プ内でどのファイルを同期するか定義するパターン)を持っています。グループ、各グループに属

するホスト名、および各グループの包含/除外ルールは、Csync2設定ファイル /etc/csync2/

csync2.cfgで指定されます。

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」の章を参照してください。

3.2 概要次の基本手順は、インストールおよび最初のクラスタセットアップに必要です。

1. アドオンとしてのインストール:

YaSTでソフトウェアパッケージをインストールします。または、コマンドライン zypperからインス

トールできます。

root # zypper in -t pattern ha_sles

23 概要 SUSE Linux Enterp… 11 SP4

http://oss.linbit.com/csync2/paper.pdfhttp://conntrack-tools.netfilter.org/http://conntrack-tools.netfilter.org/http://www.suse.com/doc

2. クラスタの初期セットアップ:

クラスタの一部になるすべてのノードにソフトウェアをインストールした後、最初にクラスタを設定

するために次の手順が必要です。

a. 通信チャネルの定義

b. オプション: 認証設定の定義

c. すべてのノードへの設定の転送。Csync2の設定がノードでのみ行われるのに対して、サー

ビスであるCsync2および xinetdはすべてのノードで開始する必要があります。

d. オプション: クラスタノード間の接続ステータスの同期

e. サービスの設定

f. クラスタをオンラインにする。OpenAIS/Corosyncサービスはすべてのノード上で開始す

る必要があります。

クラスタセットアップの手順は、自動(ブートストラップスクリプトで)か、または手動(YaSTクラスタモ

ジュールで、またはコマンドラインから)のいずれかで実行できます。

自動のクラスタセットアップを選択する場合は、3.4項「自動のクラスタセットアップ(sleha-

bootstrap)」を参照してください。

手動のセットアップ(または自動セットアップ後のオプション調整)は、3.5項「手動のクラスタセッ

トアップ(YaST)」を参照してください。

たとえば、1つのノードをYaSTクラスタで設定してから、 sleha-joinを使用して他のノードを統合させ

るなど、両方のセットアップ方法を組み合わせることもできます。

既存のノードをAutoYaSTで大量展開するためにクローンを作成することもできます。クローンを作成し

たノードには、同じパッケージがインストールされ、クローンノードは同じシステム設定を持つことになりま

す。詳細については、3.6項「AutoYaSTによる大量展開」を参照してください。

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」の章を参照してください。

24 アドオンとしてのインストール SUSE Linux Enterp… 11 SP4

http://www.suse.com/dochttp://www.suse.com/doc

手順 3.1: 高可用性パターンのインストール

1. YaSTを rootユーザとして開始し、［ソフトウェア］［ソフトウェア管理］の順に選択します。

または、コマンドラインで yast2 sw_singleを使用して、YaSTモジュールを rootとして起動し

ます。

2. ［フィルタ］リストで、［パターン］を選択して、パターンリストで［高可用性］をアクティブにします。

3. ［同意する］をクリックして、パッケージのインストールを開始します。

注記: すべてのパーティへのソフトウェアパッケージのインストールHigh Availabilityクラスタに必要なソフトウェアパッケージはクラスタノードに自動的に

コピーされません。

4. クラスタの一部になるすべてのマシンにHigh Availabilityパターンをインストールします。

クラスタを構成するノードのうち、一部ではSUSE Linux Enterprise Server 11 SP4とSUSE

Linux Enterprise High Availability Extension 11 SP4を手動でインストールしない

場合は、AutoYaSTを使用して既存ノードのクローンを作成します。詳細については、3.6項

「AutoYaSTによる大量展開」を参照してください。

3.4 自動のクラスタセットアップ(sleha-bootstrap)sleha-bootstrapパッケージは、1ノードクラスタを起動して実行させ、他のノードを追加し、既存のク

ラスタからノードを削除するために必要なすべての機能を提供します。

最初のノードの自動設定

sleha-initによって、クラスタ通信および(オプションで) STONITHメカニズムの設定に必要

な基本パラメータを定義し、共有ストレージを保護します。これによって1ノードクラスタの実行が

可能になります。

既存のクラスタにノードを追加

sleha-joinで、他のノードをクラスタに追加します。

既存のクラスタからのノードの削除

sleha-removeで、クラスタからノードを削除します。

25 自動のクラスタセットアップ(sleha-bootstrap) SUSE Linux Enterp… 11 SP4

すべてのコマンドは、最低限の時間と手動介入しか必要のないブートストラップスクリプトを実行しま

す。初期化して追加するブートストラップスクリプトが、クラスタ通信に必要なファイアウォールで自動的

にポートを開きます。この設定は、 /etc/sysconfig/SuSEfirewall2.d/services/clusterに書き

こまれます。ブートストラッププロセス中に設定されたオプションは、YaSTクラスタモジュールで後で変

更できます。

自動セットアップを開始する前に、クラスタに参加するすべてのノードで次の前提条件が満たされてい

ることを確認します。

前提条件

2.2項「ソフトウェアの必要条件」および2.4項「その他の要件と推奨事項」にリストされている前

提条件が満たされていること。

sleha-bootstrapパッケージがインストールされていること。

ネットワークがニーズに沿って設定されていること。たとえば、プライベートネットワークがクラスタ

通信に使用可能であり、ネットワークデバイスのボンディングが設定されている。ボンディングに

関する情報については、第11章「ネットワークデバイスボンディング」を参照してください。

共有ストレージにSBDを使用したい場合は、SBD用の共有ブロックデバイスが1つ必要です。

ブロックデバイスはフォーマットする必要がありません。詳細については、第17章「ストレージ保

護」を参照してください。

すべてのノードは、同じパス( /dev/disk/by-path/...または /dev/disk/by-id/... )を通し

て共有ストレージを参照できる必要があります。

手順 3.2: 最初のノードの自動設定

sleha-initコマンドは、NTPの設定を確認し、クラスタ通信層(Corosync)の設定、および(オ

プションで)SBDの設定に導き、共有ストレージを保護します。次の手順に従います。詳細につい

ては、 sleha-initマニュアルページを参照してください。

1. クラスタノードとして使用したい物理または仮想マシンに rootとしてログインします。

2. 実行によって、ブートストラップスクリプトを開始します

root # sleha-init

NTPがブート時に開始するよう設定されていない場合、メッセージが表示されます。

それでも継続を選択する場合、スクリプトは自動的にSSHアクセスおよびCsync2同期ツールの

キーを生成し、両方に必要なサービスを開始します。

3. クラスタ通信層(Corosync)を設定するには、次のとおり実行します。


a. バインドするネットワークアドレスを入力します。デフォルトでは、スクリプトは eth0のネット

ワークアドレスを提案します。または、たとえば bond0のアドレスなど、別のネットワークアド

レスを入力します。

b. マルチキャストアドレスを入力します。スクリプトはデフォルトとして使用できるランダムなア

ドレスを提案します。

c. マルチキャストポートを入力します。スクリプトはデフォルトとして 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 ]

重要: セキュリティ保護されたパスワードブートストラップの手順では、 haclusterをユーザ名、パスワードを linuxとしたLinuxユーザ

が作成されます。これは、Hawkにログインする際に必要です。デフォルトのパスワードはできる

だけ早くセキュリティ保護されたパスワードに変更します。

root # passwd hacluster

手順 3.3: 既存のクラスタにノードを追加

クラスタを(1つ上のノード上で)開始して実行する場合、 sleha-joinブートストラップスクリプト

でさらにクラスタノードを追加します。スクリプトは既存のクラスタノードへのアクセスのみが必要

で、ご使用のマシンで自動的に基本セットアップを完了します。次の手順に従います。詳細につい

ては、 sleha-joinマニュアルページを参照してください。


既存のクラスタノードをYaSTクラスタモジュールで設定した場合、 sleha-joinを実行する前

に、次の前提条件が満たされていることを確認します。

既存のノードの rootユーザに、パスワードなしでログインするためのSSHキーが適切に設

定されている。

Csync2が既存のノードに設定されている。詳細については、手順3.9「YaSTによる

Csync2の設定」を参照してください。

Hawkによって最初のノードにログインしている場合、クラスタステータス内の変更に従い、Web

インタフェース内でアクティブ化されるリソースを表示できます。

1. クラスタを参加させることになる物理または仮想マシンに rootとしてログインします。

2. 実行によって、ブートストラップスクリプトを開始します。

root # sleha-join

NTPがブート時に開始するよう設定されていない場合、メッセージが表示されます。

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」を参照してください。

手順 3.4: 既存のクラスタからのノードの削除

(複数のノードで)クラスタを起動して実行している場合、 sleha-removeブートストラップス

クリプトによって、クラスタから1つのノードを削除することができます。この場合、クラスタから

削除するノードのIPアドレスまたはホスト名が必要です。次の手順に従います。詳細について

は、 sleha-removeマニュアルページを参照してください。

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「既存のクラスタにノードを追加」を参照してください。

手順 3.5: マシンからのHIGH AVAILABILITY EXTENSIONソフトウェアの削除

クラスタノードとして不要になったマシンからHigh Availability Extensionソフトウェアを削除

するには、以下の手順を実行します。

1. クラスタサービスを停止します:

root # rcopenais stop


2. High Availability Extensionアドオンを削除します:

root # zypper rm -t products sle-hae

3.5 手動のクラスタセットアップ(YaST)最初のセットアップに関するすべての手順の概要については、3.2項「概要」を参照してください。

3.5.1 YaSTクラスタモジュール

次のセクションでは、YaSTクラスタモジュールを使用して、セットアップの各手順を実行します。これに

アクセスするには、YaSTを rootとして起動し、［高可用性］［クラスタ］の順に選択します。または、コ

高可用性ガイド - suse linux enterprise high availability ...3.4...

Documents