SteelEyeProtectionSuiteforLinux v8 -...

SteelEye Protection Suite for Linux

v8.0

Technical Documentation

May 2012

This document and the information herein is the property of SIOS Technology Corp. (previouslyknown as SteelEye® Technology, Inc.) and all unauthorized use and reproduction is prohibited. SIOSTechnology Corp. makes no warranties with respect to the contents of this document and reservesthe right to revise this publication andmake changes to the products described herein without priornotification. It is the policy of SIOS Technology Corp. to improve products as new technology,components and software become available. SIOS Technology Corp., therefore, reserves the right tochange specifications without prior notice.

LifeKeeper, SteelEye and SteelEye DataKeeper are registered trademarks of SIOS TechnologyCorp.

Other brand and product names used herein are for identification purposes only andmay betrademarks of their respective companies.

Tomaintain the quality of our publications, we welcome your comments on the accuracy, clarity,organization, and value of this document.

Address correspondence to:[email protected]

Copyright © 2012By SIOS Technology Corp.SanMateo, CA U.S.A.All rights reserved

目次

Chapter 1: はじめに 1

SteelEye Protection Suite for Linuxについて 1

SPS for Linuxの統合コンポーネント 1

SteelEye Protection Suiteソフトウェアのパッケージ 1

SPS for Linuxのインストールイメージファイル 1

SPS Core Package Cluster 2

オプションのリカバリソフトウェア 2

ドキュメンテーション 2

ドキュメンテーション 2

Chapter 2: SPS のインストール 5

システム要件 5

テクニカルノート 5

SteelEye Protection Suiteソフトウェアのパッケージ 5

SPS for Linuxのインストールイメージファイル 5

SPS Core Package Cluster 6

オプションのリカバリソフトウェア 6

SPS LifeKeeper環境の計画 7

サーバ構成のマッピング 7

LifeKeeperペアに対する構成マップの例 8

ストレージとアダプタの要件 8

ストレージとアダプタのオプション 9

サポートされているストレージモデル 9

サポートされているアダプタモデル 37

SPS LifeKeeper環境のセットアップ 39

Linux OSおよび関連する通信パッケージのインストール 39

目次 i

サーバと共有ストレージの接続 39

共有ストレージの設定 39

ネットワーク設定の確認 40

VLAN インターフェースサポートマトリックス 41

切り替え可能な IPアドレスの作成 41

データベースアプリケーションのインストールとセットアップ 42

SteelEye Protection Suiteソフトウェアのインストール 43

SPSソフトウェアのインストール 43

ライセンスの取得とインストール 45

プライマリネットワークのインターフェースを変更する場合、ライセンスRehostが必要 46

インターネット /IPライセンス 47

サブスクリプションライセンス 47

サブスクリプションライセンスのトラブルシューティング 47

インターネット Host IDの取得 48

SPS LifeKeeperインストールの確認 48

LifeKeeper SPSのアップグレード 48

Chapter 3: SteelEye DataKeeper for Linux 51

はじめに 51

保護対象のリソース 51

LifeKeeper Core 52

LifeKeeper Coreソフトウェア 52

File System、Generic Application、 IP、およびRAW I/OのRecovery Kit ソフトウェア 53

LifeKeeper GUI ソフトウェア 54

LifeKeeperのマニュアルページ 54

設定の概念 54

共通のハードウェアコンポーネント 54

すべてのLifeKeeper設定に共通するコンポーネント 55

システムのグループ化の配置 55

アクティブ -アクティブのグループ化 56

アクティブ -スタンバイのグループ化 57

ii 目次

インテリジェントスイッチバックと自動スイッチバックの違い 58

syslogによるログの記録 59

リソース階層 59

リソースタイプ 59

リソースの状態 60

階層の関係 61

イクイバレンシ情報 61

リソース階層の情報 62

リソース階層の例 63

ステータスの詳細表示 63


通信ステータスの情報 66

LifeKeeperのフラグ 67

シャットダウンストラテジー 68

ステータスの簡略表示 68



障害検出とリカバリのシナリオ 69

IPローカルリカバリ 69

ローカルリカバリのシナリオ 69

コマンドラインの操作 70

リソースのエラーリカバリのシナリオ 71

サーバの障害リカバリのシナリオ 73

インストールと設定 75

LifeKeeper for Linuxのインストール 75

LifeKeeper for Linuxの設定 75

LifeKeeperの設定手順 75

TTY接続のセットアップ 76

SNMPによる LifeKeeperイベント転送 77

SNMPによる LifeKeeperイベント転送の概要 77

目次 iii

LifeKeeperイベントテーブル 77

LifeKeeperイベント転送の設定 79

前提条件 79

設定作業 80

設定の確認 80

SNMPイベント転送の無効化 81

SNMPのトラブルシューティング 81

LifeKeeperイベントメール通知 81

LifeKeeperイベントメール通知の概要 81

メールが生成される LifeKeeperのイベント 82

LifeKeeperイベントメール通知の設定 83

前提条件 83

設定作業 83

設定の確認 84

イベントメール通知の無効化 84

メール通知のトラブルシューティング 84

任意の設定作業 85

デスクトップのツールバーに LifeKeeper GUIのアイコンを追加する 85

Gnomeを使用している場合 : 85

KDEを使用している場合 : 85

アイコンの位置を変更する 86

手動フェイルオーバ確認オプションの設定 86

サーバのシャットダウンストラテジーの設定 86

LifeKeeperハートビートの調整 87

ハートビート設定項目の概要 87

例 87

ハートビートの設定 88

設定上の考慮事項 88

SPSでカスタム証明書を使用する 88

証明書の使用方法 89

iv 目次

独自の証明書の使用 89

Linuxの設定 89

データレプリケーションの設定 93

ネットワーク設定 94

アプリケーションの設定 94

ストレージとアダプタの設定 95

HPのマルチパス I/O設定 112

EMC PowerPathのマルチパス I/O設定 115

IBM SDDによるマルチパス I/O設定 117

Hitachi HDLMのマルチパス I/O設定 117

DeviceMapper Multipath I/Oの設定 129

LifeKeeper I-Oフェンシングの概要 133

リザベーションの無効化 133

非共有ストレージ 134

リザベーションを使用しない I/Oフェンシングの設定 134

I/Oフェンシング表 134

Quorum/Witness 136

Quorum/Witness Server Support Package for LifeKeeper 136

機能の概要 136

パッケージの要件 136

パッケージのインストールと設定 137

設定可能なコンポーネント 137

使用可能な quorumモード 138

使用可能な witnessモード 139

Quorumを喪失したときに利用可能なアクション 139

共有 witness トポロジーのための追加設定 140

2ノードクラスタにwitness ノードを追加する 141

期待される動作 (デフォルトモードを仮定 ) 142

シナリオ1 142

シナリオ2 142

目次 v

シナリオ3 142

シナリオ4 143

SCSI リザベーション 143

SCSI リザベーションを利用したストレージフェンシング 143

I/Oフェンシングのための代替方式 145

STONITH 145

STONITHで IPMIを使用する 145


VMware vSphere環境でのSTONITH 145



<vm_id> 147

期待される動作 148

Watchdog 148

コンポーネント 148

設定 149

アンインストール 150

リソースポリシー管理 150

概要 150

Steeleye Protection Suite/vAppKeeperのリカバリ動作 150

ポリシーによるカスタム動作およびメンテナンスモード動作 151

標準ポリシー 151

メタポリシー 152

リソースレベルのポリシーに関する重要な考慮事項 152

lkpolicyツール 153

lkpolicyの使用方法の例 153

ローカルおよびリモートサーバとの認証 153

ポリシーのリスト表示 154

現在のポリシーの表示 154

ポリシーの設定 154

vi 目次

ポリシーの削除 154

認証情報の設定 155

認証情報の追加または変更 155

ストア内の認証情報のリスト表示 155

サーバの認証情報の削除 155

追加情報 155

LifeKeeper API 156

ネットワーク設定 156

認証 156

LifeKeeper管理 157

概要 157

エラーの検出および通知 157

N-Way リカバリ 157

管理作業 158

サーバプロパティの編集 158

コミュニケーションパスの作成 158

コミュニケーションパスの削除 160

サーバのプロパティ -フェイルオーバ 160

リソース階層の作成 162

LifeKeeperアプリケーションリソース階層 162

Recovery Kitのオプション 163

ファイルシステムリソース階層の作成 163

Generic Applicationリソース階層の作成 164

Rawデバイスリソース階層の作成 165

リソースのプロパティの編集 166

リソースの優先順位の編集 167

[Up]および [Down]ボタンの使用 168

優先順位の値の編集 168

変更の適用 168

リソース階層の拡張 168

目次 vii

ファイルシステムリソース階層の拡張 169

Generic Applicationリソース階層の拡張 170

Rawデバイスリソース階層の拡張 170

階層の拡張解除 170

リソース依存関係の作成 171

リソース依存関係の削除 172

すべてのサーバからの階層の削除 173

LifeKeeper User Guide 175

LifeKeeper for Linuxの使用 176

GUI 176

GUIの概要 -全般 176

GUIサーバ 176

GUI クライアント 176

GUI クライアントの終了 177

LifeKeeper GUI ソフトウェアパッケージ 177

メニュー 178

SteelEye LifeKeeper for Linuxのメニュー 178

リソースのコンテキストメニュー 178

サーバのコンテキストメニュー 179

[File] メニュー 180

[Edit] メニュー - [Resource] 180

[Edit] メニュー - [Server] 181

[View] メニュー 181

[Help] メニュー 182

ツールバー 182

SteelEye LifeKeeper for Linuxのツールバー 182

GUIのツールバー 182

リソースのコンテキストツールバー 184

サーバのコンテキストツールバー 185

GUIの実行の準備 186

viii 目次

LifeKeeperのGUI -概要 186

GUIサーバ 186

GUI クライアント 186

GUI クライアントの開始 187

LifeKeeper GUIアプレットの開始 187

アプリケーションクライアントの開始 187

GUI クライアントの終了 187

LifeKeeperのGUIの設定 187

GUI管理用のLifeKeeperサーバの設定 187

GUIの実行 188

GUIの設定 188

GUIの制限 189

GUIサーバの開始 /停止 189

LifeKeeper GUIサーバを開始するには 189

トラブルシューティング 189

LifeKeeper GUIサーバを停止するには 190

LifeKeeper GUIサーバのプロセス 190

GUIユーザの設定 190

Javaのセキュリティポリシー 192

ポリシーファイルの場所 192

ポリシーファイルの作成と管理 192

ポリシーファイルでの権限の付与 193

ポリシーファイルの例 193

Javaプラグイン 194

Javaプラグインのダウンロード 194

Javaプラグインのトラブルシューティング 194

リモートシステムでのGUIの実行 195

リモートシステムでのGUIの設定 195

リモートシステムでのGUIの実行 196

アプレットのトラブルシューティング 196

目次 ix

LifeKeeperサーバでのGUIの実行 197

GUIアプレットを使用するためのブラウザのセキュリティパラメータ 198

Netscape NavigatorとNetscape Communicator 198

Firefox 198

Internet Explorer 198

ステータスの表 199

プロパティパネル 199

出力パネル 200

メッセージバー 200

GUIの終了 200

共通の作業 200

LifeKeeperの起動 200

LifeKeeperサーバプロセスの起動 200

LifeKeeperの停止 201

LifeKeeperプロセスの表示 201

LifeKeeper GUIサーバプロセスの表示 201

サーバのクラスタへの接続 202

クラスタからの切断 203

接続サーバの表示 203

サーバのステータスの表示 203

サーバのプロパティの表示 204

サーバのログファイルの表示 204

リソースのタグと IDの表示 205

リソースのステータスの表示 205

サーバリソースのステータス 205

グローバルリソースのステータス 206

リソースのプロパティの表示 207

[Status]ウィンドウの表示オプションの設定 207

Resource Labels 208

Resource Tree 208

x 目次

Comm Path Status 209

Row Height 209

ColumnWidth 209

メッセージ履歴の表示 210

メッセージ履歴の解釈 210

リソース階層ツリーの展開と折り畳み 211

[Cluster Connect]ダイアログ 212

[Cluster Disconnect]ダイアログ 212

[Resource Properties]ダイアログ 213

[General] タブ 213

[Relations] タブ 214

[Equivalencies] タブ 214

[Server Properties]ダイアログ 214

[General] タブ 215

[CommPaths] タブ 217

[Resources] タブ 218

オペレータの作業 219

リソースを In Serviceにする 219

リソースをOut of Serviceにする 220

高度な作業 220

LCD 220

LifeKeeper設定データベース 220

関連トピック 221

LCDIのコマンド 221

シナリオの状況 221

階層の定義 222

LCDの設定データ 224

依存関係の情報 224

リソースのステータス情報 224

サーバ間のイクイバレンシ情報 224

目次 xi

LCDのディレクトリ構造 225

LCDのリソースタイプ 225

LifeKeeperのフラグ 225

リソースのサブディレクトリ 226

リソースの動作 227

/opt/LifeKeeperのLCDのディレクトリ構造 227

LCM 228


LifeKeeperの警報とリカバリ 229

警報クラス 229

警報の処理 230

警報ディレクトリのレイアウト 230

メンテナンス作業 230

LifeKeeperの設定値の変更 230

ファイルシステムの健全性の監視 232

条件の定義 233

フル (またはほぼフル)のファイルシステム 233

アンマウントされた、または不適切にマウントされたファイルシステム 233

LifeKeeperが保護するシステムのメンテナンス 234

リソース階層のメンテナンス 234

フェイルオーバ後の復旧 235

LifeKeeperの削除 235

GnoRPMからの削除 236

コマンドラインからの削除 236

ディストリビューションの有効化パッケージの削除 236

ファイアウォールを使用した状態でのLifeKeeperの実行 236

LifeKeeperのコミュニケーションパス 237

LifeKeeper GUIの接続 237

LifeKeeperの IPアドレスリソース 237

LifeKeeper Data Replication 237

xii 目次

ファイアウォールの無効化 238

ファイアウォール経由でのLifeKeeper GUIの実行 238

LifeKeeperの起動 239

LifeKeeperサーバプロセスの起動 240

LifeKeeperの停止 240

リソース階層の転送 240


LifeKeeperの機能 240

チューニング 241

LifeKeeperの動作 243

サーバの設定 244

LifeKeeper 7.5以降のパッケージ依存リスト 244

[Confirm Failover] と [Block Resource Failover]の設定 245

Confirm Failover On: 245

Block Resource Failover On: 245

条件 /考慮事項 : 246

NFSクライアントのオプション 246

NFSクライアントをマウントするときの考慮事項 246

UDPまたは TCPの選択 246

/etc/exportsのSyncオプション 246

RedHat EL6 (およびFedora 14)クライアントとRedHat EL6 NFSサーバの使用 246

RedHat EL5 NFSクライアントとRedHat EL6 NFSサーバの使用 247

クラスタの例 247

拡張したマルチクラスタの例 247


既知の問題と制限 249

インストール 249

LifeKeeper Core 252

インターネット /IPライセンス 256

GUI 258

目次 xiii

データレプリケーション 260

IPv6 262

Apache 265

Oracle Recovery Kit 265

NFS Server Recovery Kit 266

SAP Recovery Kit 267

LVM Recovery Kit 268

DMMP Recovery Kit 269

PostgreSQLRecovery Kit 269

MD Recovery Kit 270

GUI トラブルシューティング 271

ネットワーク関連トラブルシューティング (GUI) 272

Windowsプラットフォームでの論理接続の遅延 272

Sun FAQから: 272

モデムからの実行 : 272

プライマリネットワークインターフェースのダウン: 273

ホストへのルートが存在しない例外 : 273

不明なホストの例外 : 273

Windowsから: 274

Linuxから: 275

X Window Serverに接続できない: 275

システムの日付と時刻の調整 276

コミュニケーションパスの稼働と停止 276

推奨される対策 277

不完全なリソースの作成 277

不完全なリソースの優先順位の変更 277

一貫した状態への階層のリストア 278

階層の設定中に共有ストレージが見つからない 278

LifeKeeperサーバ障害からの復旧 279

推奨される対策 : 280

xiv 目次

停止できないプロセスからの復旧 280

手動リカバリ時のパニックからの復旧 280

Out-of-Service階層の復旧 280

リソースタグ名の制限 281

Tag Name Lengthタグ名の長さ 281

有効な "特殊 "文字 281

無効な文字 281

シリアル (TTY)コンソールの警告 281

システムが init状態 Sに遷移しているという警告 281

共有ストレージでスレッドがハングしているというメッセージ 282

説明 282

推奨される対策 : 282

Chapter 4: SteelEye DataKeeper for Linux 283

はじめに 283

SteelEye DataKeeper for Linuxによるミラーリング 283

DataKeeperの特長 283

同期ミラーリングと非同期ミラーリングの違い 284

同期ミラーリング 284

非同期ミラーリング 284

Steeleye DataKeeperの仕組み 284

同期 (および再同期 ) 285

標準ミラーの構成 285

N+1の構成 286

複数ターゲットの構成 287

SteelEye DataKeeperリソース階層 287

フェイルオーバのシナリオ 288

シナリオ1 288

シナリオ2 289

シナリオ3 289

シナリオ4 289

目次 xv


SteelEye DataKeeper for Linuxのインストールと設定 291

DataKeeperリソースを設定する前に 291

ハードウェアとソフトウェアの要件 291

ハードウェアの要件 291

ソフトウェアの要件 292

全般的な設定 292

ネットワークとLifeKeeperの設定 292

データ複製パスの変更 293

ネットワーク帯域幅の要件の特定 293

Linuxシステム(物理または仮想 )での変化率の測定 293

ネットワーク帯域幅の要件の特定 294

基本変化率の測定 294

詳細変化率の測定 295

収集した詳細変化率データの解析 295

詳細変化率データのグラフ作成 300

[Confirm Failover] と [Block Resource Failover]の設定 304

[Confirm Failover On] 304

[Block Resource Failover On] 305

各サーバのフラグの設定 305

SteelEye DataKeeper for Linuxのリソースタイプ 306

Replicate New File System 306

Replicate Existing File System 306

DataKeeper Resource 307

リソースの設定作業 307

概要 307

DataKeeperリソース階層の作成 308


DataKeeperリソース階層の拡張 310

リソース階層の拡張解除 312

xvi 目次

リソース階層の削除 312

DataKeeperリソースをOut of Serviceにする 313

DataKeeperリソースを In Serviceにする 313

リソース階層のテスト 314

LifeKeeperのGUIからの手動スイッチオーバの実行 314

管理 315

SteelEye DataKeeper for Linuxの管理 315

ミラーのステータスの表示 315

GUIからのミラーの管理 316

リワインドブックマークの作成と表示 317

ミラーを強制的にオンラインにする 318

一時停止と再開 318

ミラーの一時停止 318

ミラーの再開 318

データのリワインドと復旧 318

圧縮レベルの設定 322

リワインドログの場所の設定 322

リワインドログの最大サイズの設定 322

コマンドラインからのミラー管理 322

ミラーの操作 323

例 : 323

ミラーの設定 323

例 : 323

ビットマップの管理 324

コマンドラインからのミラーステータスの監視 324

例 : 324

サーバの障害 325

再同期 325

全同期の回避 326

方法 1 327

目次 xvii

手順 327

方法 2 328

手順 328

Multi-Site Cluster 329

SteelEye Protection Suite for Linux Multi-Site Cluster 329

SteelEye Protection Suite for Linux Multi-Site Cluster 329

Multi-Site Clusterを設定する際の考慮事項 330

Multi-Site Clusterの制限 331

SteelEye Protection Suite for Linux Multi-Site Clusterリソース階層の作成 331

Replicate New File System 332

Replicate Existing File System 334

DataKeeper Resource 335


DataKeeperリソース階層の拡張 339

ディザスタリカバリシステムへの階層の拡張 339

IP リソースのリストアおよびリカバリの設定 342

Multi-Site Cluster環境へのマイグレーション 342

要件 343

始める前に 343

マイグレーションの実行 344

マイグレーションの正常な完了 352


Index 359

xviii 目次

Chapter 1: はじめに

SteelEye Protection Suite for Linuxについて

SteelEye Protection Suite (SPS) for Linuxは、高可用性のクラスタリングと革新的なデータ複製機能

をエンタープライズクラスのソリューションに統合したものです。

SPS for Linuxの統合コンポーネント

SteelEye LifeKeeper は、障害回復性の高いソフトウェアソリューションであり、お使いのサーバのファイ

ルシステム、アプリケーション、およびプロセスの高い可用性を維持します。LifeKeeperには、カスタマイ

ズした耐障害性のハードウェアは不要です。LifeKeeperを使用するには、ネットワーク内にある 2台以

上のシステムをグループ化するだけです。サイト固有の構成データが作成され、自動の障害検出とリカ

バリが実行されます。

障害が発生した場合、障害が発生したサーバから LifeKeeperが保護しているリソースを指定のバック

アップサーバに移行します。実際のスイッチオーバ時に短時間の中断が発生します。ただし、オペレータ

の介入なしに LifeKeeperがバックアップサーバに動作をリストアします。

SteelEye DataKeeperは、LifeKeeper環境に統合データミラーリング機能を提供します。この機能に

より、LifeKeeperリソースが共有 /非共有ストレージ環境で動作可能になります。

SteelEye Protection Suite ソフトウェアのパッケージ

SteelEye Protection Suite (SPS) for Linux ソフトウェアは、1つのイメージファイル (sps.img)に入ってい

ます。

オプションのLifeKeeper Recovery Kitは、Coreパッケージの後にインストールされます。

SPS for Linuxのインストールイメージファイル

SPS for Linuxのイメージファイル (sps.img)には、インストールスクリプトのセットがあり、システムにSPSをインストールするときに必要な、ユーザ対話型のシステム設定作業を実行するように設計されていま

す。インストールイメージファイルは、実行している Linuxのディストリビューションを特定し、一連のユーザ

の応答を使用して、 SPSのインストールが正常に完了するために必要なさまざまなパッケージをインス

トールします。サーバ間の通信を可能にする LifeKeeper API (steeleye-lkapi)もインストールされます。

重要な注記 :現在、このAPI は内部使用のみとして予約されていますが、将来のリリースではお客様

とサードパーティが使用できるように公開される可能性があります。

ユーザに対する質問のタイプと順序は、使用している Linuxのディストリビューションによって異なります。

それぞれの質問をよく読んで、正しく回答してください。通常の状況では、インストールイメージファイル

に必要な各手順を完了するために、それぞれの質問に [Yes]で回答してください。

SteelEye Protection Suite for Linux 1

SPS Core Package Cluster

SPS for Linuxのイメージファイルには、Coreパッケージがあり、以下のソフトウェアパッケージが含まれま

す。

SPS Core Package Clusterl LifeKeeper (steeleye-lk)。LifeKeeper Coreパッケージには、メモリ、CPU、OS、SCSIディスクサ

ブシステム、ファイルシステムなどの中核システムコンポーネント用のリカバリソフトウェアがありま

す。

l LifeKeeper GUI (steeleye-lkGUI)。LifeKeeper GUIパッケージは、LifeKeeperの管理および監

視用のグラフィカルユーザインターフェースです。

l DataKeeper (steeleye-lkDR)。DataKeeperパッケージは、インテントログ記録を使用するデータ

複製 (同期ミラーまたは非同期ミラー)を実行します。

l IP Recovery Kit (steeleye-lkIP)。LifeKeeper IP Recovery Kitは、 IPアドレスの自動リカバリ用

のスイッチオーバソフトウェアです。

l Raw I/O Recovery Kit (steeleye-lkRAW)。LifeKeeper Raw I/O Recovery Kitは、ロー I/Oを使

用してカーネルのバッファリングを迂回するアプリケーションをサポートします。

l CCISS Recovery Kit (steeleye-lkCCISS)。Hewlett-Packard (Compaq)のCCISSデバイスを

DataKeeperでサポートするオプションのパッケージ(このパッケージは SPSのインストールイメージフ

ァイル内にあり、DataKeeperと共にHPのストレージデバイス (CCISS)を使用する場合にのみイ

ンストールされる)。

l マニュアルページ (steeleye-lkMAN)。LifeKeeperマニュアルページパッケージは、LifeKeeper製品のリファレンスマニュアルです。

オプションのリカバリソフトウェア

リカバリキットは、SPS Coreソフトウェアとは別にリリースされます。使用可能なリカバリキットとパッケージ

名の最新の総合リストについては、SPSテクニカルドキュメンテーションのApplication Recovery Kitsセクションを参照してください。

ドキュメンテーション


インストール、設定、管理、およびトラブルシューティングの手順を説明する総合的な参考資料

SteelEye Protection Suite for Linux。以下のセクションで、 SPS for Linuxの各項目について説明して

います。

セクション説明

はじめにソフトウェアパッケージ、構成の概念など、 SteelEye Protection Suite for Linux製品の

入門情報を示します。

2 はじめに


セクション説明

SPS forLinuxInstallationGuide

お使いのSPS環境の計画と設定 SPSのインストールとライセンス、およびLifeKeeperのグラフィカルユーザインターフェース (GUI)の設定に役立つ情報があります。

設定クラスタ内の各サーバで LifeKeeperソフトウェアを設定するための詳細情報と手順が

あります。

管理サーバのプロパティの編集やリソースの作成などのサーバレベルの作業、およびリソース

の編集、拡張、削除などのリソースレベルの作業について説明します。

User'sGuide

実行できる多数の作業を含めて、LifeKeeperのGUIに関する詳細情報があります。

テクニカルノートセクション、および多数の高度なトピックもあります。

DataKeeper SteelEye DataKeeper for Linuxの計画とインストールの手順、および管理、設定、お

よびユーザの情報があります。

トラブルシ

ューティング

既知の問題と制限について説明し、SteelEye LifeKeeper for Linuxのインストール、

設定、および使用を行うときに発生する可能性がある問題に対する解決策を説明し

ます。

RecoveryKits

LifeKeeperで特定のアプリケーションの管理と制御を可能にする、オプションの

Recovery Kitsの計画とインストールの手順、および管理、設定、およびユーザの情

報があります。

エラーコード

の検索

SteelEye Protection Suite for Linuxの使用時に表示される可能性のあるすべてのメッ

セージのリストがあり、該当する場合は、エラーの原因およびエラー状態を解消するた

めに必要な処置についても説明しています。この総合リストから、表示されたエラー

コードを検索できます。


Chapter 2: SPS のインストール

「SteelEye Protection Suite (SPS)インストールガイド」には、SPS環境をプランニングおよびインストー

ルする方法が記載されています。サーバ、ストレージデバイス、ネットワークコンポーネントをセットアップす

るために必要な手順の他、LifeKeeperのグラフィカルユーザインターフェース( GUI)の詳しい設定につい

ても示されます。

このガイドの手順をすべて終えれば、LifeKeeperおよびDataKeeperリソースを設定できる状態になりま

す。SPS for Linuxテクニカルドキュメンテーションでは、SPS設定に必要な情報が記載されています。

システム要件

ハードウェアおよびソフトウェアの要件やバージョンの詳しいリストについては、 SPS for Linux リリースノー

トを参照してください。

また、SPSをインストールする前に、本書に記載されているプランニング作業およびハードウェア構成作

業を完了していることを確認してください。

テクニカルノート

詳しいトラブルシューティング、制限など、このソフトウェアに関連する情報については、「SPS for Linuxテクニカルドキュメンテーション」のテクニカルノートおよびトラブルシューティングを参照してください。

SteelEye Protection Suite ソフトウェアのパッケージ

SteelEye Protection Suite (SPS) for Linux ソフトウェアは、1つのイメージファイル (sps.img)に入ってい

ます。

オプションのLifeKeeper Recovery Kitは、Coreパッケージの後にインストールされます。

SPS for Linuxのインストールイメージファイル

SPS for Linuxのイメージファイル (sps.img)には、インストールスクリプトのセットがあり、システムにSPSをインストールするときに必要な、ユーザ対話型のシステム設定作業を実行するように設計されていま

す。インストールイメージファイルは、実行している Linuxのディストリビューションを特定し、一連のユーザ

の応答を使用して、 SPSのインストールが正常に完了するために必要なさまざまなパッケージをインス

トールします。サーバ間の通信を可能にする LifeKeeper API (steeleye-lkapi)もインストールされます。

重要な注記 :現在、このAPI は内部使用のみとして予約されていますが、将来のリリースではお客様

とサードパーティが使用できるように公開される可能性があります。


SPS Core Package Cluster

ユーザに対する質問のタイプと順序は、使用している Linuxのディストリビューションによって異なります。

それぞれの質問をよく読んで、正しく回答してください。通常の状況では、インストールイメージファイル

に必要な各手順を完了するために、それぞれの質問に [Yes]で回答してください。

SPS for Linuxのイメージファイルには、Coreパッケージがあり、以下のソフトウェアパッケージが含まれま

す。

SPS Core Package Clusterl LifeKeeper (steeleye-lk)。LifeKeeper Coreパッケージには、メモリ、CPU、OS、SCSIディスクサ

ブシステム、ファイルシステムなどの中核システムコンポーネント用のリカバリソフトウェアがありま

す。

l LifeKeeper GUI (steeleye-lkGUI)。LifeKeeper GUIパッケージは、LifeKeeperの管理および監

視用のグラフィカルユーザインターフェースです。

l DataKeeper (steeleye-lkDR)。DataKeeperパッケージは、インテントログ記録を使用するデータ

複製 (同期ミラーまたは非同期ミラー)を実行します。

l IP Recovery Kit (steeleye-lkIP)。LifeKeeper IP Recovery Kitは、 IPアドレスの自動リカバリ用

のスイッチオーバソフトウェアです。

l Raw I/O Recovery Kit (steeleye-lkRAW)。LifeKeeper Raw I/O Recovery Kitは、ロー I/Oを使

用してカーネルのバッファリングを迂回するアプリケーションをサポートします。

l CCISS Recovery Kit (steeleye-lkCCISS)。Hewlett-Packard (Compaq)のCCISSデバイスを

DataKeeperでサポートするオプションのパッケージ(このパッケージは SPSのインストールイメージフ

ァイル内にあり、DataKeeperと共にHPのストレージデバイス (CCISS)を使用する場合にのみイ

ンストールされる)。

l マニュアルページ (steeleye-lkMAN)。LifeKeeperマニュアルページパッケージは、LifeKeeper製品のリファレンスマニュアルです。

オプションのリカバリソフトウェア

リカバリキットは、SPS Coreソフトウェアとは別にリリースされます。使用可能なリカバリキットとパッケージ

名の最新の総合リストについては、SPSテクニカルドキュメンテーションのApplication Recovery Kitsセクションを参照してください。

6 SPSのインストール

SPS LifeKeeper環境の計画

以下のトピックは、SPS LifeKeeper for Linux クラスタ環境の定義に役立ちます。

サーバ構成のマッピング

以下のガイドラインを使用して、サーバ構成を文書化してください。

1. 使用する構成に対して、サーバ名、プロセッサの種類、メモリ、およびその他の I/Oデバイスを決

定してください。バックアップサーバを指定した場合には、プライマリサーバに障害が発生したとき

に、選択したサーバに処理を実行する能力があることを確認する必要があります。

2. 通信接続要件を決定してください。

重要 : クラスタ化された構成には、可能性として、2種類の通信要件 (クラスタ要件とユーザ要

件 )があります。

l クラスタ - LifeKeeperクラスタでは、サーバ間に少なくとも 2つのコミュニケーションパス (「ハートビー

ト」とも呼ばれます)が必要になります。この冗長性により、通信障害が原因で発生する「スプリ

ットブレイン」シナリオを回避することができます。独立した 2つのサブネットを使用する 2つの分

離した LANベースの (TCP)コミュニケーションパスが推奨され、これらの1つ以上をプライベート

ネットワークとして構成する必要があります。TCP とTTYのの組み合わせもサポートされていま

す。TTYコミュニケーションパスは、サーバのシリアルポート間で RS-232ヌルモデム通信を使用し

ます。

コミュニケーションパスを 1つしか使用しない場合、互いに通信する LifeKeeperクラスタ

内のシステムの機能に支障をきたす可能性があります。単一のコミュニケーションパスを

使用しているときに、そのコミュニケーションパスで障害が発生した場合、複数のシステム

上で同時に LifeKeeperの階層が使用可能になることがあります。これは、偽のフェイル

オーバまたは「スプリットブレイン」シナリオと呼ばれます。「スプリットブレイン」シナリオでは、

各サーバが、アプリケーションを制御できると認識しているため、データにアクセスしようとし

たり共有ストレージデバイスにデータを書き込もうとする場合があります。スプリットブレイン

シナリオを解決するために、LifeKeeperでは、サーバの電源をオフにしたり、再起動した

り、階層を使用できなくすることで、すべての共有データに対するデータの整合性を保証

することができます。また、TCPコミュニケーションパス上のネットワークトラフィックが大きくな

ると、偽のフェイルオーバやLifeKeeperが適切に初期化できなくなるなど、予期せぬ動

作が生じる可能性があります。

l ユーザ -ユーザトラフィックに対する代替のLAN接続、つまり、クラスタハートビートに使用するも

のとは別のLAN接続を用意することをお勧めします。ただし、(推奨通りに) 2つのTCPコミュニ

ケーションパスを構成した場合、これらのコミュニケーションパスのいずれかが、サーバに出入りする

その他のトラフィックとネットワークアドレスを共有することができます。

l 注記 :必要な場合にのみリソースを使用できるようにする場合は、Quorum/Witness ServerSupport Package for LifeKeeperを利用することができます。


LifeKeeperペアに対する構成マップの例

3. 共有リソースアクセス要件を確認して理解してください。共有ストレージを使用するクラスタは、

共有 SCSIバスまたはファイバチャネルループを利用できます。 LifeKeeperではリソースが1つの

サーバにロックされるため、ロックされたすべてのリソースへのアクセスが必要になるサーバは常時 1つだけであることを確認する必要があります。LifeKeeperデバイスのロックは、論理ユニット (LUN)レベルで行われます。アクティブ/アクティブ構成では、各階層が独自の一意のLUNにアクセスす

る必要があります。共通のLUNにアクセスするすべての階層は、同じサーバ上でアクティブ (稼働中 )である必要があります。

4. 共有メモリ要件を決定してください。共有メモリおよびセマフォパラメータを設定する場合

は、LifeKeeperだけでなくサードパーティ製アプリケーションの共有メモリ要件も考慮に入れてくだ

さい。LifeKeeperの共有メモリ要件については、テクニカルノートの調整を参照してください。

LifeKeeperペアに対する構成マップの例

この構成マップの例は、ディスクアレイサブシステムを共有する LifeKeeperサーバのペアを図示していま

す。通常は、Server 1がアプリケーションを実行し、Server 2がバックアップサーバまたはセカンダリサーバ

になります。このケースでは、同時に 1つのサーバがディスクアレイのディスクストレージスペース全体を保

有しているので、ディスクリソースの競合はありません。ディスクアレイコントローラは「DAC」、SCSIホスト

アダプタ (パラレルSCSI、ファイバチャネルなど)は「SCSI HA」と表記されています。

サーバのペアが、最も単純な LifeKeeper構成となります。3つ以上のサーバで構成されるクラスタを計

画する場合、複数のサーバ間が適切に接続されるようにマッピングすることが非常に重要になります。

たとえば、多方向フェイルオーバ構成では、物理的な接続が存在しない場合でも LifeKeeper内のコミ

ュニケーションパスを定義することが可能です。カスケーディングフェイルオーバ機能を実現するために、各

サーバがクラスタ内の他のすべてのサーバへの物理的な接続パスを持つ必要があります。

ストレージとアダプタの要件

以下のガイドラインを使用して、ストレージとホストアダプタの要件を決定してください。

ストレージデバイス -アプリケーションのデータストレージ要件に基づいて、構成に必要なデータストレー

ジデバイスの種類と数を決定する必要があります。共有ファイルは、ディスクアレイサブシステム (RAID :

8 SPS環境の計画

ストレージとアダプタのオプション

Redundant Array of Inexpensive Disks)上に置く必要があります。LifeKeeperは、構成に使用できる

ハードウェアRAID周辺装置を多数サポートしています。サポートされている周辺装置のリストについて

は、ストレージとアダプタのオプションを参照してください。

ストレージデバイスの構成を計画する際には、以下の点を考慮してください。

l LifeKeeperでは物理ディスクまたは論理ユニット (LUN)レベルでリソースを管理し、その構成内

では同時に 1つのサーバのみが各物理ディスクまたは LUN上のリソースを利用できます。そのた

め、LifeKeeperの構成を始める前に、ディスク割り当ての計画を立てることをお勧めします。たと

えば、アクティブ/アクティブ構成の各階層は、独自の一意のLUNにアクセスする必要があるの

で、2ノードアクティブ/アクティブ構成の場合は最低 2つのLUNが必要になります。

l 一部のモデル固有の問題およびハードウェア構成の詳細については、ストレージとアダプタの構

成を参照してください。

アダプタ -構成の種類および周辺装置の数に基づいて、必要な SCSIまたはファイバチャネルホストア

ダプタの種類と数を決定してください。選択するアダプタは、ドライバが使用できるように、LifeKeeperだけでなく使用している Linuxディストリビューションでもサポートされていることが重要です。サポートされて

いるホストアダプタのリストについては、サポートされているアダプタモデルを参照してください。参照用

に、構成マップにホストアダプタを追加する必要があります。

ストレージとアダプタのオプション

以下の表には、共有ストレージ構成で LifeKeeperが現在サポートしているディスクアレイのストレージモ

デルおよびアダプタが一覧表示されています。ストレージまたはアダプタモデルごとに、認定の種類が示さ

れています。ストレージベンダが、ストレージアダプタモデルにリストされているものに関連するその他のアダ

プタモデルをサポートしている場合、LifeKeeper for Linuxはこれらのアダプタモデルもサポートします。これ

らのアレイおよびアダプタに対するドライババージョンおよびその他の構成要件については、ストレージおよ

びアダプタの構成を参照してください。

IPフェイルオーバのみを使用する非共有ストレージを含むLifeKeeper構成あるいは SteelEye DataReplicationまたはNetwork Attached Storageの使用時には、サポートされているディスクアレイおよび

アダプタは必要ありません。

サポートされているストレージモデル

ベンダストレージモデル認定

ADTX ArrayMasStor P パートナーのテスト

ArrayMasStor L パートナーのテスト

ArrayMasStor FC-II パートナーのテスト

Altix TP9100 SIOS TechnologyCorp.のテスト




BaydelStorageArrays

DAR3/5SE68C SIOS TechnologyCorp.のテスト

DAR3/C/5SE68C SIOS TechnologyCorp.のテスト

Consan CRD5440 SIOS TechnologyCorp.のテスト

CRD7220 (f/w 3.00) SIOS TechnologyCorp.のテスト

DataCore SANsymphony SIOS TechnologyCorp.のテスト

Dell 650F (CLARiiON) SIOS TechnologyCorp.のテスト

Dell | EMCCX3−10c/CX3−40c/CX3−20c、CX3−80/CX3−40(F)/CX3−20(F)

パートナーのテスト

Dell | EMC CX300/CX600/CX400/CX700/CX500 SIOS TechnologyCorp.のテスト

PowerVault ( Dell PERC、LSI Logic MegaRAID有り) SIOS TechnologyCorp.のテスト

Dell MD3000 パートナーのテスト

Dell PowerVault MD3200/3220 パートナーのテスト




Dell EqualLogic PS5000およびPS6000 パートナーのテスト

Dell EqualLogic PS4000、PS6500、PS6010E/S/X/XV/XVSおよ

びPS6510E/Xベンダのサポートス

テートメント

Dell EqualLogic PS4100, PS4110, PS6100, PS6110 ベンダのサポートス

テートメント

EMC Symmetrix 3000 Series SIOS TechnologyCorp.のテスト

Symmetrix 8000 Series ベンダのサポートス

テートメント

Symmetrix DMX/DMX2 パートナーのテスト

Symmetrix DMX3/DMX4 パートナーのテスト

Symmetrix VMAX Series パートナーのテスト

CLARiiON CX200、CX400、CX500、CX600、およびCX700 SIOS TechnologyCorp.のテスト




CLARiiON CX300 パートナーのテスト

CLARiX CX3-20 パートナーのテスト

CLaRiiON CX3FCおよび combo 40290 パートナーのテスト

CLaRiiON CX310c パートナーのテスト

CLaRiiON AX4 SIOS TechnologyCorp.のテスト

CLaRiiON AX45 パートナーのテスト

CLaRiiON CX4-120、CX4-240、CX4-480、CX4-960 パートナーのテスト

VNX Series 5100/5300/5500/5700/750 ベンダのサポートス

テートメント

FalconStor FalconStor Network Storage Server (NSS) Version 6.15 パートナーのテスト




Fujitsu ETERNUS3000 (PG-FC105、PG-FC106、または PG-FC107有り)、シングルパスのみ


ETERNUS6000 (PG-FC106有り)、シングルパスのみパートナーのテスト

ETERNUS4000Model 80およびModel 100 (PG-FC106、PG-FC107、または PG-FC202有り)、シングルパスのみ


FibreCAT S80 (注記を参照 ) パートナーのテスト

ETERNUS SX300 (PG-FC106または PG-FC107有り)、マルチ

パスのみ


ETERNUS2000 Series:Model 50、Model 100、およびModel 200(PG-FC202有り)、シングルパスおよびマルチパス構成


ETERNUS4000 Series:Model 300およびModel 500 (PG-FC202有り)、シングルパスおよびマルチパス構成

ベンダのサポートス

テートメント

ETERNUS DX60/DX80/DX90 Fibre Channel ベンダのサポートス

テートメント




ETERNUS DX60 S2/DX80 S2/DX90 S2 Fibre Channel ベンダのサポートス

テートメント

ETERNUS DX410/DX440 Fibre Channel ベンダのサポートス

テートメント

ETERNUS DX410 S2/DX440 S2 Fibre Channel ベンダのサポートス

テートメント

ETERNUS DX8100/DX8400/DX8700 Fibre Channel ベンダのサポートス

テートメント

ETERNUS VS850 ベンダのサポートス

テートメント




Hitachi DataSystems

HDS RAID 700 (VSP) パートナーのテスト

HDS 7700 ベンダのサポートス

テートメント

HDS 5800 ベンダのサポートス

テートメント

HDS 9570V パートナーのテスト



AMS 500 SIOS TechnologyCorp.のテスト

SANRISE USP/NSC (TagmaStore USP/NSC) パートナーのテスト




BR1200 パートナーのテスト

BR1600 パートナーのテスト

BR1600E パートナーのテスト

BR1600S パートナーのテスト

AMS2010 パートナーのテスト




Hitachi Unified Storage 110 (HUS 110) ベンダのサポートス

テートメント


テートメント


テートメント




HP/Compaq RA 4100 SIOS TechnologyCorp.のテスト




MA/RA 8000 SIOS TechnologyCorp.のテスト




MSA1000 / MSA1500 (アクティブ/アクティブおよびアクティブ/パッシ

ブファームウェア構成 )SIOS TechnologyCorp.のテスト




HP MSA1000 Small Business SAN Kit SIOS TechnologyCorp.のテスト




HP P2000G3MSA FC(RHEL5.4上のDMMP有り) SIOS TechnologyCorp.のテスト

HP P2000G3MSA SAS パートナーのテスト

HP P4000/P4300G2 SIOS TechnologyCorp.のテスト




HP P4000 VSA ベンダのサポートス

テートメント

HP P4500G2 ベンダのサポートス

テートメント

HP P6300 EVA FC パートナーのテスト

HP P9500 ベンダのサポートス

テートメント

HP XP20000/XP24000 SIOS TechnologyCorp.のテスト




3PAR T400 Fibre Channel パートナーのテスト

3PAR F200/F400/T800 Fibre Channel ベンダのサポートス

テートメント

3PAR V400 パートナーのテスト

EVA3000/5000 SIOS TechnologyCorp.およびパー

トナーのテスト

EVA4X00/6X00/8X00 (XCS 6.xシリーズファームウェア) SIOS TechnologyCorp.およびパー

トナーのテスト

EVA4400 パートナーのテスト

EVA6400/8400 パートナーのテスト

EVA8100 (XCS 6.xシリーズファームウェア) パートナーのテスト

MSA2000 Fibre Channel パートナーのテスト

MSA2000 iSCSI パートナーのテスト

MSA2000 SA パートナーのテスト

MSA 2300 Fibre Channel パートナーのテスト




MSA2300 i パートナーのテスト

MSA2300 SA パートナーのテスト




IBM FAStT200 SIOS TechnologyCorp.のテスト




FAStT500 SIOS TechnologyCorp.のテスト




DS4100 * パートナーのテスト




DS4200 パートナーのテスト




DS4300 (FAStT600) * SIOS TechnologyCorp.のテスト






DS4300 (FAStT600) SIOS TechnologyCorp.のテスト

DS4400 (FAStT700) SIOS TechnologyCorp.のテスト





ESS Model 800 * SIOS TechnologyCorp.のテスト

DS6800 * SIOS TechnologyCorp.のテスト

DS8100 * SIOS TechnologyCorp.のテスト

DS400 (シングルパスのみ) SIOS TechnologyCorp.のテスト

DS3200 SIOS TechnologyCorp.のテスト







IBM eServer xSeries Storage Solution Server Type445-R forSANmelody


IBM eServer xSeries Storage Solution Server Type445-FR forSANmelody


IBM SAN VolumeController ** IBM TotalStorage Proven

SIOS TechnologyCorp.のテスト

IBM Storwize V7000 (Firmware Version 6.3.0.1) SIOS TechnologyCorp.のテスト

JetStor JetStor II SIOS TechnologyCorp.のテスト

MicroNet Genesis One ベンダのサポートス

テートメント

MTI Gladiator 2550 ベンダのサポートス

テートメント

Gladiator 3550 ベンダのサポートス

テートメント

Gladiator 3600 ベンダのサポートス

テートメント




NEC NEC iStorageM100 FC (SPS Recovery Kit使用時のシングルパ

スおよびマルチパス構成 )パートナーのテスト

NEC iStorageM10e / M300 / M500 FC (SPS Recovery Kit使用

時のシングルパスおよびマルチパス構成 )ベンダのサポートス

テートメント

NEC iStorage S500 / S1500 / S2500 (シングルパスのみ) SIOS TechnologyCorp.のテスト

NEC iStorage S Series (SPS Recovery Kit使用時のシングルパ

スおよびマルチパス構成 )ベンダのサポートス

テートメント

NEC iStorage D1-10 / D1-30 (SPS Recovery Kit使用時のシン

グルパスおよびマルチパス構成 )ベンダのサポートス

テートメント


グルパスおよびマルチパス構成 )パートナーのテスト


グルパスおよびマルチパス構成 )パートナーのテスト

NEC iStorage D8-10 / D8-20 / D8-30 (SPS Recovery Kit使用

時のシングルパスおよびマルチパス構成 )パートナーのテスト




NetworkAppliance(NetApp)

NAS ベンダのサポートス

テートメント

FAS2xx Series ベンダのサポートス

テートメント

FAS9xx Series ベンダのサポートス

テートメント

FAS2xxx Series ベンダのサポートス

テートメント


テートメント


テートメント

SAN ベンダのサポートス

テートメント

FAS3xxx Series (QLogic QLE246xおよびDMMP有り) ベンダのサポートス

テートメント

Newtech SweeperStor SATA パートナーのテスト

SweeperStor SAS パートナーのテスト

nStor NexStor 4320F パートナーのテスト

ProCom Reliant 1000 ベンダのサポートス

テートメント




RadionSystems

Rack U2W ベンダのサポートス

テートメント

Microdisk U2W ベンダのサポートス

テートメント

SGI InfiniteStorage 4600 パートナーのテスト

Linux MPP ドライバパートナーのテスト

SILVERstor Giant GT-3000シリーズパートナーのテスト

Sun StorEdge 3310 パートナーのテスト

StorEdge 3510 FC (Sun StorEdge 2Gb PCI Single FC NetworkAdapter有り)


StorEdge 6130 FC (Sun StorEdge 2Gb PCI Single FC NetworkAdapter有り)


StorageTek 2540 (Sun StorageTek 4Gb PCI-E Dual FC HostBus Adapterまたは Sun StorageTek 4Gb PCI Dual FC NetworkAdapter有り


TID MassCareRAID パートナーのテスト

MassCareRAIDⅡ パートナーのテスト

WinchesterSystems

FlashDisk OpenRAID (SCSI) SIOS TechnologyCorp.のテスト

FlashDisk OpenRAID (FC) SIOS TechnologyCorp.のテスト

Xiotech Magnitude 3D SIOS TechnologyCorp.のテスト


サポートされているアダプタモデル


アダプタ

の種類アダプタモデル認証

DifferentialSCSIAdapter

Adaptec 2944W、Adaptec 2944 UW、または

Adaptec 2940 U2W

Compaq 64bit PCI Dual Channel Wide Ultra2SCSI Adapter

Compaq SA 5i、6i、532、および642 PCI DualChannel Wide Ultra3 SCSI Adapters

Dell PERC 2/DC、PERC 4/DC

LSI Logic MegaRAID Elite 1600 (Dell PERC 3/DCはこのアダプタのOEMバージョンです)

Adaptec 39160

Adaptec ASR-2010S (Fujitsu PG-140C / CL) –注記を参照

Adaptec ASR-3200S (Fujitsu PG-142B /C /D) –注記を参照

LSI Logic MegaRAID SCSI 3200-2 (Fujitsu PC-142E) –注記を参照

注記 : IPフェイルオーバのみを使用する非共有スト

レージを含むLifeKeeper構成あるいは SteelEyeData Replicationの使用時には、これらのアダプタは

Fujitsuのテストを受けます。

SIOS Technology Corp.のテスト






ベンダのサポートステートメント





アダプタ

の種類アダプタモデル認証

FibreChannel

QLogic QLA 2100、QLogic QLA 2200、QLogic QLA2340、QLogic QLA 200 (HP Q200)

HP StorageWorks 2GB 64-bit/133MHz PCI-X toFibre Channel Host Bus Adapter (FCA2214)

Compaq 64 bit/66MHz Fibre Channel Host BusAdapter 120186-B21

Sun StorEdge 2Gb PCI Single FC NetworkAdapter (OEMedQLogic QLA 2310)

Sun StorageTek 4Gb PCI-E Dual FC Host BusAdapter

Sun StorageTek 4Gb PCI Dual FC NetworkAdapter

Emulex LP9002 (PG-FC105)、EmulexLP1050、Emulex LP10000(これらのアダプタに必要なドライバとバージョンについ

ては、Emulexのドライバを参照してください。)

HP QLogic QMH2462 4Gb FC HBA

Qlogic QLE2460 (4GbHBA)、Qlogic QLE2462(4GbHBA)

FC1142SR 4GbシングルチャネルPCI-ExpressFibre Channelアダプタ

FC1242SR 4GbデュアルチャネルPCI-ExpressFibre Channelアダプタ












SerialAttachedSCSI(SAS)

DELL SAS 5/eアダプタパートナーのテスト

SIOS Technology Corp.では、Fibre Channelのハブとスイッチを特に認証していません。これは、これら

のデバイスに対する LifeKeeper固有の既知の制限事項や要件がないためです。ストレージとアダプタ

の構成に示されたアレイについての注記が特にない限り、LifeKeeperではディスクアレイベンダがサポー

トするハブおよびスイッチを推奨します。


SPS LifeKeeper環境のセットアップ

要件が決定され、LifeKeeper設定がマップされたので、このSPS LifeKeeper環境のコンポーネントをセ

ットアップすることができます。

注記 :一部のセットアップ作業は異なる順序で実行することが可能ですが、このリストは推奨された順

序で示されています。

Linux OS および関連する通信パッケージのインストール

SPS LifeKeeper for Linux ソフトウェアのインストールを実行する前に、最初に Linuxオペレーティングシ

ステムが正常にインストールされ稼動することを確認する必要があります。完全なインストールの詳細

については、Linuxのディストリビューションに付属のLinux インストール手順書を参照してください。

注記 :

l 共有ストレージを接続して設定した後に Linuxをインストールすることも可能ですが、新しい周

辺装置を導入する前に、Linuxをインストールして実行する方が簡単な場合があります。

l SPS LifeKeeper for Linux インストールイメージファイルは、SPS LifeKeeperをシステムにインス

トールする前に必要なユーザ対話型システムセットアップタスクを実行するように設計された一連

のインストールスクリプトを提供します。

サーバと共有ストレージの接続

非共有ストレージ環境で LifeKeeperを使用することを計画している場合は、この情報をスキップできま

す。データレプリケーション (ミラーリング)環境で LifeKeeperを使用している場合は、この文書の

DataKeeperセクションを参照してください。ネットワーク接続ストレージ環境で LifeKeeperを使用してい

る場合は、LifeKeeper Network Attached Storage Recovery Kit管理ガイドを参照してください。

Linuxがインストールされたら、ホストアダプタおよび共有周辺装置のアドレスを設定する必要がありま

す。具体的な詳細については、アダプタおよびストレージデバイスに付属のドキュメンテーションを参照し

てください。

共有ストレージの設定

LifeKeeperでは、共有 SCSI (Small Computer System Interface)ホストアダプタおよび共有ディスク

ハードウェアの機能を使用して、障害が発生したサーバから指定のバックアップサーバにリソースを切り

替えるように設定できます。ファイバチャネルのストレージエリアネットワーク (SAN)も、障害の発生した

サーバから指定のバックアップサーバにリソースを切り替えるのに使用できます。

以下の作業を実行して、ディスクベースのアプリケーションリソース階層を作成し、LifeKeeperでフェイル

オーバ保護を提供できるようにしてください。


ネットワーク設定の確認

1. ディスクおよびLUNのパーティションを分割してください。LifeKeeperの保護下にあるすべてのディ

スクのパーティションを分割する必要があるので、共有ディスクアレイは論理ユニット (LUN)に設

定する必要があります。ディスクアレイ管理ソフトウェアを使用して、この設定を実行してくださ

い。詳細な手順については、ディスクアレイソフトウェアのマニュアルを参照してください。

注記 :

l LifeKeeperでは LUNレベルでディスクをロックすることに注意してください。したがって、アクティブ/スタンバイ設定では 1つのLUNが適切と考えられます。ただし、アクティブ/アクティブ設定を使用

する場合は、少なくとも 2つの別個のLUNを設定して、各階層が独自の一意のLUNにアクセ

スできるようにする必要があります。

2. 両方のサーバが共有ディスクを認識することを確認してください (fdiskコマンドなどを使用 )。作

成した LUNを Linuxが認識しない場合は、LifeKeeperも認識しません。

3. LifeKeeper階層でプライマリサーバとして使用するシステムから共有ディスク上のファイルシステム

を作成してください。ファイルシステムの管理に関する完全な手順については、Linuxのマニュア

ルを参照してください。

ネットワーク設定の確認

LifeKeeperをインストールする前に、ネットワークが適切に設定され動作することを確認することが重要

です。ネットワークの動作を確認するために、この時点で実行する必要のある作業を以下に示します。

1. サーバのインストールでファイアウォールが有効になっている場合は、LifeKeeperのポートを提供

するか、またはファイアウォールを無効にする必要があります。トピック「ファイアウォールがある場合

のLifeKeeperの実行」を参照してください。

2. 各サーバから、ローカルサーバを pingし、クラスタ内の他のサーバを pingしてください。pingが失

敗した場合には、必要なトラブルシューティングを行い、修正処置を実行してください。

3. サーバに複数のネットワークアダプタがある場合は、アダプタが異なるサブネット上にあるように設

定する必要があります。アダプタが同じサブネット上にある場合、TCP/IPは 2つ目のアダプタを

有効に利用できません。

4. localhostがクラスタ内の各サーバで解決可能であることを確認してください。DNSが実装されて

いない場合は、 /etc/hosts ファイルを編集して、 localhost名のエントリを追加してください。この

エントリは、ローカルサーバの IPアドレスをリストしたり、デフォルトのエントリ (127.0.0.1)をリストす

ることができます。 localhostが解決できない場合、LifeKeeper GUIが正常に機能しない可能

性があります。

5. DNSが実装されている場合は、LifeKeeperクラスタ内のサーバがDNSを使用して解決できる

ように設定されていることを確認してください。

6. 各サーバのホスト名が正しく、LifeKeeperをインストールした後に変更されないことを確認してく

ださい。後で LifeKeeperシステムのホスト名を変更するように決定した場合は、クラスタ内のす

べてのサーバについて以下の手順に従う必要があります。

a. 次のコマンドを使用して、クラスタ内のすべてのサーバ上のLifeKeeperを停止してくださ

い。

/opt/LifeKeeper/bin/lkstop

40 SPS環境のセットアップ

VLAN インターフェースサポートマトリックス

b. Linux hostnameコマンドを使用して、サーバのホスト名を変更してください。

c. 続行する前に、新しいホスト名がクラスタ内の各サーバで解決可能であることを確認す

る必要があります (前の項目を参照 )。

d. クラスタ内の各サーバで次のコマンドを実行して、LifeKeeperのホスト名を更新してくださ

い。(詳細については、lk_chg_value(1M)を参照してください。)

/opt/LifeKeeper/bin/lk_chg_value -o oldhostname -n

newhostname

e. 次のコマンドを使用して LifeKeeperを起動してください。

/opt/LifeKeeper/bin/lkstart

LifeKeeper for Linux v7.xでは、コミュニケーションパスおよび IP リソース用のVLAN インターフェースがサ

ポートされています。VLAN インターフェースの種類は、以下に示すように選択することができます。

VLANインターフェースサポートマトリックス

-サポートなし \ xサポートあり

LK Linux v7.1以前のバージョン

VLAN_NAME_TYPE コミュニケーションパス IP リソース

DEV_PLUS_VID (eth0.0100) - x

DEV_PLUS_VID_NO_PAD (eth0.100) - x

VLAN_PLUS_VID (vlan0100) x x

VLAN_PLUS_VID_NO_PAD (vlan100) x x

LK Linux v7.2以降のバージョン

VLAN_NAME_TYPE コミュニケーションパス IP リソース

DEV_PLUS_VID (eth0.0100) x x

DEV_PLUS_VID_NO_PAD (eth0.100) x x

VLAN_PLUS_VID (vlan0100) x x

VLAN_PLUS_VID_NO_PAD (vlan100) x x

切り替え可能な IP アドレスの作成

切り替え可能な IPアドレスとは、サーバ間で切り替えることができる「仮想的な」IPアドレスです。各

サーバのネットワークインターフェースカードに関連付けられた IPアドレスとは別個のもので

す。LifeKeeperの保護下にあるアプリケーションは、切り替え可能な IPアドレスに関連付けられていま


データベースアプリケーションのインストールとセットアップ

す。これにより、プライマリサーバで障害が発生した場合、その IPアドレスがバックアップサーバに「切り替

わり」ます。

切り替え可能な IPアドレスに対してリソース階層を設定することを計画している場合は、クラスタの各

サーバで以下の作業を実行する必要があります。

l コンピュータ名が正しく、変更されないことを確認する。

l pingコマンドを使用して切り替え可能な IPアドレスが一意であることを確認する。

l /etc/hosts ファイルを編集して、切り替え可能な IPアドレスごとにエントリを追加する。

詳細については、LifeKeeper for Linux IP Recovery Kitテクニカルドキュメンテーションを参照してくださ

い。

データベースアプリケーションのインストールとセットアップ

使用する環境に、Oracle、 Informix、DB2、MySQLなどの保護されたデータベースアプリケーションが含

まれている場合は、データベースに付属のドキュメンテーションを使用してアプリケーションをインストール

する必要があります。データベースが共有ファイルシステム上にあり、設定ファイルが共有ファイルシステ

ム上にあることを確認してください。実行可能ファイルは、ローカルまたは共有のファイルシステム上に置

くことができます。

LifeKeeperをインストールした後にアプリケーションをインストールすることも可能ですが、LifeKeeperの保護下に置く前に、適切に設定され稼動することを確認するためにアプリケーションをテストする必要が

あります。インストールおよびセットアップ時のその他の考慮事項については、特定のLifeKeeperデータ

ベースリカバリキットドキュメンテーションを参照してください。

42 SPS環境のセットアップ

SteelEye Protection Suite ソフトウェアのインストール

SPS設定の各サーバにSPSソフトウェアをインストールします。各 SPSサーバには、オプションの

LifeKeeperリカバリキットパッケージを含む、設定要件をサポートするために必要なパッケージが用意さ

れている必要があります。コアパッケージとそれに続くオプションのリカバリソフトウェアを含む、SPSインス

トールイメージファイル (sps.img)がインストールされます。

コアパッケージとそれに続くオプションのリカバリソフトウェアを含む、SPSインストールイメージファイル

(sps.img)がインストールされます。このイメージファイルは、システムへのSPSのインストール時に必要な

ユーザ対話型システムセットアップタスクを実行するように設計された一連のインストールスクリプトを提

供します。インストールイメージファイルによって、どのような Linuxディストリビューションを実行するかが識

別され、一連の質問と回答を通して、正常な SPSインストールを確保するために必要なさまざまなパ

ッケージがインストールされます。また、サーバのHost IDを取得および表示するためのユーティリティを提

供する、ライセンスユーティリティパッケージもインストールされます。Host IDは、SPSを実行するための

有効なライセンスを取得するために使用されます。

詳細については、 SPS for Linux リリースノートを参照してください。

注記 : これらのインストール手順は、読者がサーバにインストールされた Linuxオペレーティングシステム

に精通していることを前提としています。

重要 :

l 共有ストレージへのSPSのインストールはサポートされていません。各サーバのローカルディスク

に独自のコピーをインストールする必要があります。

l SPSパッケージはすべて、ディレクトリ /opt/LifeKeeperにインストールされます。

l LifeKeeperの既存バージョンを再インストールする場合、最初に、古い LifeKeeperパッケージを

削除する必要があります。標準のLifeKeeperのインストールには、既存のリソース階層の再定

義が必要になります。現在のリソース階層の定義を保持する場合は、 SPS for Linux リリース

ノートおよびSPSのアップグレードを参照して、アップグレードの手順を確認してください。

l SPSのインストール時に LifeKeeper Distribution Enablingパッケージを参照するエラーメッセージ

が表示された場合、 SPSインストールイメージファイルで setupスクリプトを実行 /再実行する必

要があります。

SPS ソフトウェアのインストール

SPSはお使いのLinuxディストリビューションに関わらず、コマンドラインでインストールされます。

1. 以下のコマンドを使用して、sps.imgファイルをマウントしてください。

mount PATH/IMAGE_NAME MOUNT_POINT -t iso9660 -o loop


SPSソフトウェアのインストール

ここで、PATHはspslk.imgファイルへのパスですIMAGE_NAMEはspslk.imgファイルの名前ですMOUNT_POINTはマウント位置へのパスです

2. sps.img マウントディレクトリに移動して、次のコマンドを入力してください。

./setup

3. インストール手順の間に何が行われるかを説明するテキストが表示されます。ここで行われる一

連の質問に対して、Yesの場合は「y」、No の場合は「n」と答えます。質問の種類と順序は、

お使いのLinuxディストリビューションによって異なります。

各質問をよく読んで、適切に回答してください。正常な SPSインストールに必要なすべての手

順を完了するために、各質問に対して Yes と答えることをお勧めします。

注記 : インストールイメージファイルは、共有ストレージデバイスまたはオプションのをサポートする

ためのカーネルモジュールをインストールすることができます。

カーネルのアップグレードに関する重要な情報 :SPSは一般的にいくつかの機能をサ

ポートするためカーネルモジュールをインストールします。 ;そのため、RedHatシステムで

カーネルパッチの適用 /カーネルのアップグレードを実施する際に、インストールメディアから

./setupスクリプトを再度実行し、SPSの一部としてインストールしたカーネルを新しい

カーネルとして有効にしてください。この操作を実施しない場合は、SPS リソースを inserviceおよび/もしくは保護できない状態のままになります。

4. ここでセットアップスクリプトが、ライセンスユーティリティのインストールを実行します。詳細について

は、ライセンスの取得とインストールを参照してください。

5. 次に、 SPSコアパッケージがインストールされます。

6. セットアップスクリプトで提示されたすべての質問に答えると、インストールが成功したことが示され

ます。

注記 :セットアップスクリプトの実行に関する追跡情報が、 /var/log/LK_install.logに保存されま

す。

注記 :アップグレードの際には、セットアップの実行前に LifeKeeperを停止するようにしてくださ

い。

7. クラスタの他のサーバにも SPSソフトウェアを適宜、同じ手順を使用してインストールしてくださ

い。

8. 次に、LifeKeeperのリカバリキットとオプションのソフトウェアパッケージを、個々のイメージファイル

から同じ手順を使用してインストールしてください。

アップグレード手順については、LifeKeeperのアップグレードを参照してください。

44 SteelEye Protection Suiteソフトウェアのインストール

ライセンスの取得とインストール

SPS LifeKeeper for Linuxでは、サーバごとに固有のライセンスが必要になります。このライセンスはラン

タイムライセンスです。つまり、ライセンスがなくても LifeKeeper SPSをインストールできますが、製品を

正常に起動して実行するには、ライセンスをインストールする必要があります。

注記 : RHEL 6.1と共に新しいハードウェアを使用する場合は、LifeKeeper SPS for Linux トラブルシ

ューティングセクションにあるRHEL 6.1の既知の問題を参照してください。

インストールスクリプトは、サーバのHost IDを取得して表示するラインセンスユーティリティパッケージをイ

ンストールします。(インストールスクリプトを介して表示されるHost IDは、常にMACアドレスのHost IDになります。 IPアドレスのHost IDを使用する場合は、インターネット Host IDの取得トピックを参照し

てください。) Host IDを、SteelEye Protection Suite LifeKeeperソフトウェアで提供された EntitlementID (認証コード )と共に使用して、 SteelEye Protection Suite LifeKeeperを実行するために必要なパー

マネントライセンスを取得します。このプロセスを以下の図に示します。

注記 : ソフトウェアパッケージごとに、サーバごとのライセンスが必要になります。

以下の手順を実行して、LifeKeeper SPSクラスタ内の各サーバに対するライセンスを取得してインス

トールしてください。

1. Host ID を取得してください。インストールセットアップスクリプトのライセンスユーティリティで表示

されるHost IDをメモしてください。Host IDは、ライセンスを取得するシステムで

/opt/LifeKeeper/bin/lmhostidを実行して取得することもできます。

2. Host ID をノートに書き留めるか、ファイルに保存してください。ファイルに保存した場合は、そ

のファイルをインターネットアクセスが可能なシステムにコピーしてください。ノートに書き留めた場


プライマリネットワークのインターフェースを変更する場合、ライセンスRehostが必要

合は、そのノートをインターネットアクセスが可能なシステムのあるところに持って行ってください。

3. LifeKeeper Entitlement ID (認証コード )があることを確認してください。ライセンスの取得に必

要な Entitlement IDを含むソフトウェアをメールで受け取っているはずです。

4. SIOS Technology Corp. ラインセンス管理ポータルでライセンスを取得してください。

a. インターネットアクセスが可能なシステムを使用して、SIOS Technology Corp. ライ

ンセンス管理ポータルにログインしてください。

b. [Manage Entitlements]を選択してください。

注記 :パスワードを変更する場合は、画面の右上隅にある [Profile]ボタ

ンを使用してください。

c. [Entitlement ID]を探して、行項目の左にあるボックスをオンにすることで、その

Entitlement IDに関連付けられた各 [Activation ID]を選択してください。

d. [Activate]タブを選択してください。

e. 必要なフィールドを定義して、[Next]を選択してください。

f. [Select Existing Host]をクリックして定義済みのホストを選択するか、[AddNew Host]を選択することで新しいホストを作成してください。

g. [Host ID]を入力して、[Okay]をクリックしてください。

h. [Host ID]の左にあるボックスをオンにして、[Generate]を選択してくださ

い。[Fulfillment ID]が [License Summary]画面に表示されます。

i. [Fulfillment ID]の左にあるボックスをオンにして、[Email License]タブを選択し

てください。

j. ラインセンスの送信先となる有効なメールアドレスを入力して、 [Send]を選択し

てください。

k. [Complete]を選択してください。

l. メールを取得してください。

m. ファイルを適切なシステムにコピーにしてください。

5. ラインセンスをインストールしてください。各システムで、ライセンスファイルを

/var/LifeKeeper/licenseにコピーするか、または各システム

で、/opt/LifeKeeper/bin/lkkeyinsを実行してファイルに対するファイル名 (フルパスを

含む)を指定してください。

プライマリネットワークのインターフェースを変更する場合、ライセンスRehostが必要

ライセンスユーティリティで使用するHost IDは、LifeKeeperサーバのプライマリネットワークインターフェー

スカード (NIC)から取得されます。LifeKeeperでは、起動するたびにライセンスが有効かどうかを確認し

ます。LifeKeeperサーバで、将来、NICの交換が必要になり、Host IDが変更されることになる場合

は、次回 LifeKeeperを停止するときに、LifeKeeperを再起動する前にライセンスRehostを実行する

46 ライセンスの取得とインストール

http://us.sios.com/support/license-keys/














インターネット /IPライセンス

必要があります。SIOS Technology Corp. ライセンス管理ポータルにログインして、[Manage Licenses]画面から [Support Actions/Rehost]を選択して、このRehostを実行してください。(注記 : Rehostは、サポートに連絡することなく、6カ月に一度実行することができます。)

インターネット /IP ライセンス

インターネット /IPライセンスに関する情報については、LifeKeeper SPS for Linux トラブルシューティング

セクションの既知の問題およびインターネット Host IDの取得を参照してください。

サブスクリプションライセンス

サブスクリプションライセンスとは、更新機能を持つ期限付きライセンスです。評価版ライセンスと同様

に、更新せずに一定期間を過ぎるとライセンスが切れます。この更新プロセスを自動的に行うようにす

るには、以下の手順に従います。(注記 :サブスクリプション更新サービスでは、TCP/IPポート 443でSIOS Technology Corp. ライセンス管理サーバにアクセスするためにインターネット接続が必要になりま

す。)

1. 次のコマンドを実行してください。/opt/LifeKeeper/bin/runSubscriptionServicestart

2. プロンプトが表示されたら、(SIOS Technology Corp. カスタマー登録で取得した)ユーザIDとパス

ワードを入力してください。

前の手順が正常に実行された場合は、サブスクリプション更新サービスが実行されるようになり、バック

グラウンドで更新ステータスのチェックが定期的に行われます。特定の日数

(90、60、30、20、10、5、4、3、2、1)後に期限が切れるライセンスが見つかると、syslog(/var/log/messages)に警告通知が送信され、ライセンスの更新が実行されます。新しいライセン

スのアクティベーションが可能な (このシステムのEntitlementに対して新しいアクティベーションが購入さ

れている)場合、自動的にアクティベーションが実行され、古いライセンスを交換するシステム上に新し

いライセンスがインストールされます。このシステムに対するライセンスが更新される (アクティベーションが

購入される)限り、このサービスにより、ユーザが操作することなく、システム上でライセンスのアップグレー

ドが確実に実行されます。

サブスクリプションライセンスのトラブルシューティング

エラーが発生した場合は、サポートに連絡する前に以下の作業を実行してください。

l LifeKeeper Logとsyslog (/var/log/messages)のエラーメッセージを確認してください。必要

に応じて、次のコマンドを実行してメッセージを取得してください。

/opt/LifeKeeper/bin/lmsubscribe --immediate

l SIOS Technology Corp. ライセンス管理ポータルにログインして、資格情報を確認してください。

l 次のコマンドを使用して資格情報を入力してください。

/opt/LifeKeeper/bin/lmsubscribe –-login

これが正常に実行された場合は、次のコマンドを実行してサービスを開始してください。

/opt/LifeKeeper/bin/runSubscriptionService start




























インターネット Host IDの取得

l ライセンス管理ポータルでパスワードを変更した場合は、次のコマンドを実行して、自動ライセ

ンス更新サービスをアップデートしてください。

/opt/LifeKeeper/bin/lmsubscribe --login

l ライセンス証明書の所有権が変更された場合は、SIOS Technology Corp.のサポート担当者

に連絡して、証明書を新しい所有者に移転してください。所有権が移転されたら、この新しい

資格情報を使用して自動ライセンス更新サービスをアップデートする必要があります。この操作

を実行するには、新しいユーザIDとパスワードを使用して次のコマンドを実行してください。

/opt/LifeKeeper/bin/lmsubscribe --login

インターネット Host IDの取得

マシンのインターネット Host IDを取得するには、 lmhostidを使用します。インターネット Host IDは、通

常、システムのプライマリネットワークインターフェースのプライマリ IPアドレスです。インターネット Host IDは、Ethernet (またはMAC) Host IDの代替として使用することができ、VMクローンのためにMACアド

レスが変更される可能性がある仮想環境において望ましいと考えられます。

1. 次のコマンドを入力してください。

# /opt/LifeKeeper/bin/lmhostid -internet -n

2. プログラムから返される IDを記録してください。

例 :

# /opt/LifeKeeper/bin/lmhostid -internet -n

"INTERNET=172.17.100.161"

注記 : この情報は、SIOS Technology Corp.から取得したパーマネントライセンスキーに記載されている

情報と一致する必要があります。

SPS LifeKeeper インストールの確認

SPS LifeKeeperパッケージが正しくインストールされていることを確認するには、コマンドラインで次のコマ

ンドを入力してください。

rpm -V <package name>

注記 :パッケージが正しくインストールされている場合、このコマンドは何も出力しません。

コマンドラインからクエリを実行するには、次のコマンドを入力してください。

rpm -qi <package name>

注記 : このコマンドの予想される出力は、パッケージ情報です。

LifeKeeper SPS のアップグレード

SPS for Linuxは、既存のリソース階層を維持しながら、将来のリリースにアップグレードすることできま

す。この情報をよく検討して、アプリケーションのダウンタイムを最小限に抑えるようにしてください。

48 ライセンスの取得とインストール

LifeKeeper SPSのアップグレード

注記 : LifeKeeperは、LifeKeeper Version 7.4または Version 7.5からVersion 8.0にアップグレードする

ことができます。7.4または 7.5以外のバージョンからアップグレードする場合は、古いバージョンをアンイン

ストールしてから、 SteelEye Protection Suite for Linuxを再インストールする必要があります。古いバー

ジョンをアンインストールする代わりに、古いバージョンを 7.4または 7.5にアップグレードしてから、8.0への

アップグレードを実行する方法もあります。

注記 :アップグレード時に lkbackupを使用する場合は、lkbackup既知の問題を参照して、詳細

を確認してください。

1. 2つのノードのみを持つSPS クラスタをアップグレードする場合は、直接手順 2に進んでくださ

い。3つ以上のノードを持つSPSクラスタをアップグレードする場合は、すべてのアプリケーション

をこれからアップグレードするサーバから切り替えてください。この操作を実行するには、手動で行

うか、または LifeKeeperシャットダウン方法を「Switchover」に設定します。これによ

り、LifeKeeperが停止したり、サーバがシャットダウンしたときにアプリケーションが切り替えられま

す。

2. 必要に応じて、LifeKeeper SPSをアップグレードする前に、Linuxオペレーティングシステムをアッ

プグレードしてください。オペレーティングシステムのアップグレードを実行する前に、アップグレード

するサーバのすべてのリソースを拡張解除することをお勧めします。

3. LifeKeeper SPSインストールイメージファイルを使用して、LifeKeeperをアップグレードしてくださ

い。次のコマンドを使用して、 SPSインストールイメージファイルをマウントしてください。

mount PATH/IMAGE_NAME MOUNT_POINT -t iso9660 -o loop

ここで、PATHはイメージへのパスですIMAGE_NAMEはイメージの名前ですMOUNT_POINTはマウント位置へのパスです

4. spslk.imgマウントディレクトリに移動して、次のコマンドを入力してください。

./setup

パッケージがアップグレードされていることを確認する情報メッセージが表示されます。

5. アップグレードが終了したら、LifeKeeper GUIを停止してから再起動し、更新されたGUI クライ

アントをロードしてください。

6. 3つ以上のノードを持つSPSクラスタをアップグレードする場合は、すべてのアプリケーションをこ

れからアップグレードするサーバから切り替えてください。

7. アップグレードするSPSクラスタのサーバごとに、この手順を繰り返してください。

注記 :同じバージョンおよびリリースのSPSは、1つのクラスタ内のすべてのシステムにインストールする必

要があります。一般的に、異なるバージョンまたはリリースのSPSの間には互換性がありません。ローリ

ングアップグレード以外の状況で、異なるバージョンまたはリリースが存在し、クラスタ内の別のシステム

で実行されている場合には、LifeKeeperを起動しないでください。


Chapter 3: SteelEye DataKeeper for Linux

はじめに

SteelEye LifeKeeper for Linuxは、さまざまなストレージ構成をサポートし、最大 32ノードの高可用性

クラスタリングを提供します。共有ストレージ(ファイバチャネルSAN、 iSCSI)、ネットワーク接続ストレー

ジ( NAS)、ホストベースの複製、HP Continuous AccessなどのアレイベースのSAN複製との統合な

どをサポートします。

保護対象のリソース

LifeKeeperファミリの製品には、多様なシステムリソースにフェイルオーバ保護を提供できるソフトウェア

があります。以下の図に、LifeKeeperの柔軟性、および自動リカバリを指定できるリソースタイプを示し

ます。

l ファイルシステム。LifeKeeperでは、ext2、ext3、ext4、reiserfs、NFS、vxfs、xfsなどのファイル

システムの指定とフェイルオーバができます。

l 通信リソース。LifeKeeperには、TCP/IPのような通信リソースの通信 Recovery Kitが用意され

ています。

l インフラストラクチャリソース。LifeKeeperには、NFS、Samba、LVM、WebSphereMQ、ソフトウェ

アRAID (md)など、Linux インフラストラクチャサービス用のオプションのRecovery Kitが用意され

ています。

l Web サーバリソース。LifeKeeperには、ApacheWebサーバリソース用のオプションのRecoveryKitが用意されています。

l メールサーバリソース。LifeKeeperには、Postfix電子メールサービス用のオプションのRecoveryKitが用意されています。

l データベースとその他のアプリケーション。LifeKeeperには、Oracle、 Informix、MySQL、DB2、PostgreSQL、Sybase、SAP DB/MaxDBなどの主要な

RDBMS製品、およびSAPやClearCaseなどのエンタープライズアプリケーション用のオプション

のRecovery Kitが用意されています。

LifeKeeperは、多様なリソースタイプについて複数の回復方法をサポートします。


LifeKeeper Core

LifeKeeper CoreLifeKeeper Coreは、以下の4つの主要コンポーネントで構成されています。

l LifeKeeper Coreソフトウェア

l File System、Generic Application、Raw I/O、および IPのRecovery Kit ソフトウェア

l LifeKeeper GUI ソフトウェア

l LifeKeeperのマニュアルページ

LifeKeeper Core ソフトウェア

LifeKeeper Coreソフトウェアは、以下のコンポーネントで構成されます。

l LifeKeeper構成データベース (LCD) - LCDは、LifeKeeperが保護するリソースの情報を保存し

ます。リソースインスタンス、依存関係、イクイバレンシ情報、リカバリの方向、LifeKeeperの動

作フラグに関する情報が含まれます。システムの起動後にデータが記憶されているように、データ

は共有メモリにキャッシュされ、ファイルに保存されます。

l LCD インターフェース (LCDI) - LCDIは、LCDに保存されているデータやデータの変更を要求す

るクエリを設定データベース (LCD)にクエリを送信します。また、リソースの状態や説明の情報を

取得するために、Application Recovery KitがLCDIを使用することもできます。

l LifeKeeper Communications Manager (LCM) - LCMは、クラスタ内にあるサーバのステータスの

特定、およびLifeKeeperのプロセス間通信 (ローカルとリモート )に使用されます。クラスタ内のあ

るサーバ上にあるすべてのコミュニケーションパスで LCM通信がないことは、サーバに障害が発

52 SteelEye DataKeeper for Linux

File System、Generic Application、 IP、およびRAW I/OのRecovery Kit ソフトウェア

生したことを示します。

l LifeKeeperアラームインターフェース - LifeKeeperアラームインターフェースは、イベントを起動する

ためのインフラストラクチャです。LifeKeeperが保護するリソースに障害が検出された場合、アプ

リケーションデーモンにより sendeventプログラムが呼び出されます。sendeventプログラムがLCDと通信し、リカバリプロセスが使用可能かどうかを判断します。

l LifeKeeperのローカルリカバリ動作と制御のインターフェース ( LRACI) - LRACIはリソースに適

切なリカバリスクリプトを判断し、リソースに適切な restore / removeスクリプトを呼び出します。

File System、Generic Application、 IP、および RAW I/O のRecoveryKit ソフトウェア

LifeKeeper Coreは、サーバ上の指定リソースを保護します。リソースを以下に示します。

l File Systems - LifeKeeperでは、共有ストレージデバイス上にあるファイルシステムの指定とフェ

イルオーバができます。ファイルシステムは、共有 SCSIバス経由で 2台のサーバからアクセス可

能なディスク上に作成できます。LifeKeeperのファイルシステムリソースは、1台目のサーバに作

成されてから、2台目のサーバに拡張されます。ファイルシステムの健全性監視がディスクフルと

不適切なマウント (またはアンマウント )のファイルシステム条件を検出します。検出した条件に

従って、Recovery Kitが警告メッセージのログ記録、ローカルリカバリの試行、またはファイルシス

テムリソースのバックアップサーバへのフェイルオーバを実行できます。

File System Recovery Kitに関連するヘルプトピックとして、ファイルシステムのリソース階層の作

成、拡張、ファイルシステムの健全性の監視などがあります。

l Generic Applications - Generic Application Recovery Kitは、リソースタイプに対して事前定義

リカバリキットが指定されていない汎用アプリケーションやユーザ定義アプリケーションを保護でき

ます。このキットを使用すると、特定アプリケーションについてカスタマイズした監視スクリプトやリカ

バリスクリプトを指定できます。

Generic Application Recovery Kitに関連するヘルプトピックとして、汎用アプリケーションのリソー

ス階層の作成、拡張などがあります。

l IP Addresses - IP Recovery Kitには、LifeKeeper環境で、障害が発生したプライマリサーバか

ら「切り替え可能な」IPアドレスをバックアップサーバにリカバリするメカニズムがあります。切り替え

可能な IPアドレスとは、サーバ間で切り替えることができる仮想 IPアドレスであり、各サーバの

ネットワークインターフェースカードに関連付けられている IPアドレスとは別のもので

す。LifeKeeperで保護されているアプリケーションは切り替え可能な IPアドレスに関連付けられ

ているので、プライマリサーバに障害が発生した場合、切り替え可能な IPアドレスはバックアップ

サーバに関連付けられます。LifeKeeperで保護されているリソースは、切り替え可能な IPアド

レスです。

特定の製品、構成、および管理に関する情報については、リカバリキットに含まれるIPRecovery Kit Technical Documentationを参照してください。

l RAW I/O - RAW I/O Recovery Kitは、カーネルのバッファリングを迂回するアプリケーションのロー

I/Oデバイスをサポートします。RAW I/O Recovery Kitでは、共有ストレージデバイスにボンディン

グされたRAWデバイスの指定とフェイルオーバができます。RAWデバイスは、リソースの作成前

に、プライマリノードに設定する必要があります。ローリソースを作成した後、追加サーバに拡張

できます。


LifeKeeper GUI ソフトウェア

LifeKeeper GUI ソフトウェア

LifeKeeper GUIは、Javaテクノロジを使用して開発されたクライアント /サーバアプリケーションであ

り、LifeKeeperおよびその設定データ用のグラフィカルな管理インターフェースです。LifeKeeper GUI クラ

イアントは、スタンドアロンのJavaアプリケーション、およびWebブラウザから呼び出される Javaアプレッ

トの両方として実装されます。

LifeKeeperのマニュアルページ

LifeKeeper製品用のLifeKeeper Coreのリファレンスマニュアルページです。

設定の概念

LifeKeeperは、2台以上のサーバを持つグループに対してユーザが定義したリソース階層に基づいて

機能します。以下のトピックで、LifeKeeperのフェイルオーバ設定の概念を説明しています。

共通のハードウェアコンポーネント

LifeKeeperのすべての設定には、以下の共通コンポーネントが含まれます。

1. サーバグループ。LifeKeeperが提供する障害回復機能は、2台以上のサーバをクラスタにグ

ループ化することを基礎にしています。サーバは、サポートする Linuxのディストリビューションを実

行するサポートするプラットフォームであれば、いずれでもかまいません。LifeKeeperには、複数の

重なり合うグループにサーバを設定する柔軟性があります。ただし、リカバリ可能なリソースにつ

いての重要な要件は、リソースの役割と優先順位が定義されたサーバのグループをリンクするこ

とです。リソースに対するサーバの優先順位は、現在実行中のサーバに障害が発生した場合

に、どのサーバがそのリソースを復旧するかを決定するために使用されます。最高の優先順位を

示す値は 1です。特定のリソースについて、最高の優先順位の値 (通常は 1)を持つサーバが

通常、そのリソースのプライマリサーバと呼ばれます。その他のサーバは、そのリソースのバックアップ

サーバとして定義されます。

2. コミュニケーションパス。LifeKeeperのハートビートは、LifeKeeperクラスタ内にあるサーバ間の定

期的なメッセージで、主要な障害検出機能です。クラスタ内のすべてのサーバには、単純な通

信障害でシステムに障害が発生しないように、冗長なハートビートコミュニケーションパス (commパス)が必要です。2つの独立したサブネットを使用する LANベース (TCP)の個別な 2つのコミ

ュニケーションパスが推奨されます (少なくとも 1つのコミュニケーションパスをプライベートネットワー

クとして設定してください)。ただし、TCP とTTYのコミュニケーションパスの組み合わせの使用も

サポートしています。TCPコミュニケーションパスは、他のシステムの通信にも使用できます。

注記 : TTYコミュニケーションパスは、クラスタ内の他のサーバがアクティブかどうかを検出するため

にのみ LifeKeeperで使用されます。LifeKeeperのGUIは、TCP/IPを使用して、保護するリ

ソースに関するステータス情報を通信します。TCPコミュニケーションパスが2つ設定されている

場合、LifeKeeperはパブリックネットワークのコミュニケーションパスをリソースステータスの通信に

使用します。このため、LifeKeeperのGUIが使用しているネットワークがダウンすると、TTY (また

は他のTCP)コミュニケーションパスが動作可能な場合でも、GUIには他のサーバのステータスが

UNKNOWN として表示されます。


すべてのLifeKeeper設定に共通するコンポーネント

3. 共有データリソース。共有ストレージの構成では、LifeKeeperクラスタ内のサーバは同一セットの

ディスクに対するアクセスを共有します。プライマリサーバに障害が発生した場合、LifeKeeperは障害が発生したサーバ上にあるディスクのロック解除、および次に使用可能なバックアップサーバ

のディスクのロックを自動管理します。

4. 共有通信。LifeKeeperは TCP/IPアドレスのような通信リソースの切り替えを自動管理できる

ので、アプリケーションが現在どのサーバでアクティブになっているかには無関係に、ユーザはアプリ

ケーションに接続できます。

すべてのLifeKeeper設定に共通するコンポーネント

システムのグループ化の配置

リソース階層は、LifeKeeperサーバのクラスタに対して定義されます。ある階層について、各サーバに優

先順位が割り当てられます。1が最高の優先順位です。プライマリ、つまり優先順位が最高のサーバ

が、それらのリソースの通常動作に使用するコンピュータです。2番目に高い優先順位を持つサーバが

バックアップサーバであり、プライマリサーバに障害が発生した場合に、LifeKeeperがリソースを切り替え


アクティブ -アクティブのグループ化

る先のサーバです。

アクティブ /アクティブのグループでは、すべてのサーバがプロセスをアクティブに実行します。ただし、他の

サーバのリソース階層ではバックアップサーバとしても機能します。アクティブ /スタンバイのグループでは、

プライマリサーバは処理を実行し、バックアップサーバはプライマリサーバに障害が発生した場合に備え

てスタンバイするように設定できます。スタンバイシステムは小型でパフォーマンスの低いシステムでもかま

いませんが、プライマリサーバに障害が発生した場合にリソースの可用性を確保できるだけの処理能

力が必要です。

共有リソースに対する物理的な接続とアクセスにより、グループ化のオプションが決まります。グループ化

するサーバには、通信とハートビートパスがインストールされ、動作可能である必要があり、すべてのサー

バが共有 SCSIまたはファイバチャネルインターフェース経由で、ディスクリソースにアクセスできる必要が

あります。例えば、以下の図では、サーバ1のリソースAppAにはグループ化オプションが1つのみありま

す。この構成で AppAデータベースへの共有アクセスを持つ他のサーバはサーバ2のみです。

ただし、サーバ3のリソースAppBは、その他 3台のいずれを含むグループにも属するように設定できま

す。これは、この例の共有 SCSIバスが、構成内の4台すべてのサーバにAppBデータベースへのアクセ

スを提供しているからです。

アクティブ - アクティブのグループ化

アクティブ / アクティブペアの設定では、すべてのサーバがプロセスをアクティブに実行します。また、他の

サーバのリソース階層ではバックアップサーバとして機能します。

以下の設定例に、2つのアクティブ /アクティブペアのサーバを示します。サーバ1は AppAを処理してい

ますが、サーバ2で実行中のAppXのバックアップサーバとして機能します。この逆も当てはまります。

サーバ2は AppXを処理していますが、サーバ1で実行中のAppAのバックアップサーバとして機能しま

す。サーバ3とサーバ4の間には、同じタイプのアクティブ/アクティブの関係があります。

サーバ1とサーバ2の設定と、サーバ3とサーバ4の設定は似ていますが、大きな違いがありま

す。AppA とAppXのアプリケーションについて、サーバ1とサーバ2のみをグループ化できます。これらの

サーバのみが、共有リソースにアクセスできます。


アクティブ -スタンバイのグループ化

ただし、AppB とAppCは、複数のグループ化オプションを持ちます。これは、4台のサーバすべてが

AppB とAppCの共有リソースにアクセスできるからです。AppB とAppCは、第 3、第 4のバックアップシ

ステムとしてサーバ1やサーバ2にフェイルオーバするように設定することもできます。

注記 : LifeKeeperはディスクレベルでロックを適用するので、AppB とAppCのディスクリソースに接続する

4つのシステムのうち、任意の時点でそれらにアクセスできるのは 1つのみです。このため、サーバ3がア

クティブにAppBを処理しているときには、サーバ1、サーバ2、およびサーバ4は物理的に接続してい

ても AppBのディスクリソースを使用できません。

アクティブ - スタンバイのグループ化

アクティブ / スタンバイのペア設定では、プライマリサーバは処理を実行し、バックアップサーバはプライマリ

サーバに障害が発生した場合に備えてスタンバイします。スタンバイシステムは小型でパフォーマンスの

低いシステムでもかまいませんが、プライマリサーバに障害が発生した場合にリソースの可用性を確保

できるだけの処理能力が必要です。


インテリジェントスイッチバックと自動スイッチバックの違い

スタンバイサーバは、複数のアクティブサーバにバックアップを提供します。例えば、上の図では、3つのア

クティブ /スタンバイのリソースペアでサーバ2がスタンバイサーバです。LifeKeeperのリソース定義が、以

下のアクティブ /スタンバイのペアの関係を指定します。

l サーバ1のAppAがサーバ2にフェイルオーバする。

l サーバ3のAppBがサーバ2にフェイルオーバする。

l サーバ4のAppCがサーバ2にフェイルオーバする。

複数のアクティブ /スタンバイグループを持つ設定を検討するときには、以下の3つの重要な設定概念

を念頭に置いてください。

l ディスクの所有権。複数の異なるアクティブなアプリケーションは、異なる複数のサーバから、同じ

共有ディスクまた LUNにあるディスクパーティションを使用できません。LifeKeeperは、ディスクま

たは LUNのレベルでロックを適用します。SCSIロックが適用された場合、共有 SCSIバス上に

あるシステム1台のみが、ディスクまたは LUNのパーティションにアクセスできます。このため、同

一ディスク上の異なるパーティションにアクセスする複数のアプリケーションは、同一サーバ上でア

クティブにする必要があります。この例では、サーバ3がAppBのディスクリソースを所有し、サーバ

4がAppCのリソースを所有します。

l 処理能力。サーバ1、サーバ3、およびサーバ4に同時に障害が発生する可能性は非常に低

いですが、複数のリソース関係をサポートするスタンバイサーバを指定するときには、複数の障害

が発生した場合にスタンバイサーバが重要な処理のすべてを処理できるように注意する必要が

あります。

l LifeKeeper の管理。この例では、サーバ2がその他 3台のサーバをバックアップします。一般的

に、LifeKeeperのデータベースを複数の論理グループで同時に管理することは望ましくありませ

ん。はじめに、予備システムと1台のアクティブなシステムとの間でリソースを作成し、次に予備シ

ステムと別のアクティブなシステムとの間、という手順を繰り返してリソースを作成する必要があり

ます。

インテリジェントスイッチバックと自動スイッチバックの違い

デフォルトでは、リソースのスイッチバック設定はインテリジェントです。これは、そのリソースについてサーバ

AからサーバBにフェイルオーバが発生すると、別の障害が発生するか、管理者がリソースを別のサーバ

にインテリジェントに切り替えるまで、リソースはサーバBに残ります。このため、サーバAが In Serviceに戻った後も、リソースはサーバBで動作を続行します。この時点では、サーバAはリソースのバックアップ

として機能します。

状況によっては、障害が発生したサーバが復旧したときに、リソースをそのサーバに自動でスイッチバック

することが望ましい場合があります。LifeKeeperには、前述したデフォルトのインテリジェントスイッチバック

動作に代わる選択肢として、自動スイッチバックオプションがあります。このオプションは、各サーバの

個々のリソース階層に設定できます。特定のサーバ上にあるリソース階層に自動スイッチバックを選択

し、そのサーバに障害が発生した場合、そのリソース階層はバックアップシステムにフェイルオーバします。

障害が発生したサーバが復旧したときに、リソース階層は元のサーバに自動的にスイッチバックします。

注記 :

l 自動スイッチバックのチェックは、LifeKeeperを起動したとき、またはクラスタに新しいサーバを追

加したときにのみ実行されます。通常のクラスタ動作中には実行されません。


syslogによるログの記録

l LifeKeeperは、優先順位が上位のサーバから下位のサーバへの自動スイッチバックを実行しま

せん。

syslogによるログの記録

LifeKeeper 8.0から、標準のsyslog機能を使用してログの記録が行われます。LifeKeeperでは、3つのsyslogの実装 (標準のsyslog、rsyslog、およびsyslog-ng)をサポートしてます。パッケー

ジのインストール時には、すべてのLifeKeeperログメッセージに対して「local6」機能を使用するように

syslogが設定されます。すべてのLifeKeeperログメッセージを /var/log/lifekeeper.logに送信する

LifeKeeper固有のルーティングを含むように、syslog設定ファイル (/etc/syslog-ng/syslog-ng.confなど)が変更されます。(元の設定ファイルは、「~」で終わる同じ名前を使用してバックアップされます。)

この機能は、インストール後に /opt/LifeKeeper/binにある lklogconfigツールを使用して変更するこ

とができます。このツールの詳細については、LifeKeeperがインストールされているシステム上の

lklogconfig(8)マニュアルページを参照してください。

注意 : LifeKeeperがサーバから削除されると、LifeKeeper固有のsyslog設定が削除されます。

リソース階層

LifeKeeperのGUIを使用すると、あるサーバにリソース階層を作成し、次にその階層を 1台以上のバ

ックアップサーバに拡張できます。その後、LifeKeeperにより、指定したすべてのサーバに指定階層が自

動作成されます。LifeKeeperは、各サーバのデータベースで階層情報を管理します。コマンドラインイン

ターフェースを使用する場合は、各サーバの階層を明示的に指定する必要があります。

リソース階層の作成後、LifeKeeperが階層内のリソースの停止と開始を管理します。以下の関連トピ

ックで、階層の指定作業の基本情報を説明しています。

リソースタイプ

リソースはハードウェアとソフトウェアのいずれかであり、リソースタイプ別に分類できます。LifeKeeperはフ

ァイルシステムとSCSIのリソースタイプに処理を提供し、リカバリキットは通信、RDBMS、その他のアプ

リケーションのリソースタイプに処理を提供します。

例えば、保護するファイルシステムの階層には、以下のタイプのリソースインスタンスが含まれます。

l filesys - Linuxのファイルシステムリソースオブジェクトで、マウントポイントにより識別されます。

l device - SCSIディスクパーティションと仮想ディスクで、デバイスファイル名で識別されます (例 :sdc1)。

l disk - SCSIディスクまたはRAIDシステム論理ユニットで、SCSIデバイス名で識別されます (例 :sd)。


リソースの状態

リソースの状態

状態意味

In Service、保護 (ISP)

リソースが動作可能です。LifeKeeperのローカルリカバリが正常に動作していま

す。LifeKeeperのサーバ間リカバリと障害検出が動作可能です。

In Service、未保護

(ISU)

リソースが動作可能です。このリソースについて、LifeKeeperのローカルリカバリ方式が

動作不能です。LifeKeeperのサーバ間リカバリと障害検出が動作可能です。

Out ofService、障

害 (OSF)

リソースが、障害によりOut of Serviceになっています。リカバリは完了していないか、

失敗しました。このリソースについて、LifeKeeperの警告機能は動作不能です。

Out ofService、障

害なし

(OSU)

リソースはOut of Serviceですが、別のサーバからリソースを引き継ぐことができます。

不正 (未定

義 )状態

(ILLSTATE)

この状態は、リソースインスタンスについて状態が設定されていない場合に表示されま

す。通常の状況では、この不正状態が長く続くことはありません。ある状態から別の状

態への移行が予測されます。LifeKeeperの情報テーブルがすべて更新される前

(LifeKeeperが初めて起動するときなど)にスイッチオーバが発生した場合に、この状態

になります。


階層の関係

階層の関係

LifeKeeperでは、リソースインスタンス間の関係を作成できます。主な関係は依存関係で、例えばあ

るリソースインスタンスが動作するために、別のリソースインスタンスに依存します。リソースインスタンスと

依存関係の組み合わせが、リソース階層です。

例えば、 /usr1の動作はディスクサブシステムに依存するので、 /usr1と、ディスクサブシステムを表すイン

スタンスとの間に順序付きの階層の関係を作成できます。

リソース階層により指定された依存関係は、リソースインスタンスを In ServiceとOut of Serviceにする

適切な順序を LifeKeeperに示します。このリソース階層の例では、disk とdeviceのインスタンスを正

常に In Serviceにするまで、LifeKeeperは /usr1リソースを In Serviceにすることができません。

イクイバレンシ情報

LifeKeeperリソース階層を作成して拡張すると、そのリソース階層はプライマリサーバとセカンダリサーバ

の両方に存在します。ほとんどのリソースインスタンスは、1台のサーバでのみ同時にアクティブにできま

す。このようなリソースについて、LifeKeeperは「イクイバレンシ情報」という第 2の種類の関係を定義し

ます。これにより、リソースがあるサーバで In Serviceになると、イクイバレンシ情報が定義されている他

のサーバではOut of Serviceになります。

以下の例に、各サーバのディスクパーティションのリソースインスタンス間のイクイバレンシ情報を示しま

す。この例では、各リソースインスタンスが類似のイクイバレンシを持ちます。


リソース階層の情報


各リソースのステータスは、ステータスの詳細表示とステータスの簡略表示で表示されます。root リソー

スを表すLifeKeeperのタグ名は、 [TAG]列の左端から開始され、階層内のリソースのタグ名は適切に

インデントされてリソース間の依存関係を表します。

以下の例は、ステータスの簡略表示のリソース階層セクションから取ったものです(デバイスとディスクの

IDは、表示領域に収まるように切り詰められている)。

LOCAL TAG ID STATE PRIO PRIMARY

svr1 app3910-on-svr1 app4238 ISP 1 svr2

svr1 filesys4083 /jrl1 ISP 1 svr2

svr1 device2126 000...300-1 ISP 1 svr2

svr1 disk2083 000...300 ISP 1 svr2

階層の図についてはリソース階層の例のトピックを参照してください。詳細については、ステータスの詳

細表示とステータスの簡略表示のトピックの「リソース階層の情報」セクションを参照してください。


リソース階層の例

リソース階層の例

ステータスの詳細表示

このトピックでは、 lcdstatus コマンドの出力例を使用してステータスの詳細表示で提供される情報のカ

テゴリについて説明します。この情報を表示する方法の詳細については、LCD (1M)のマニュアルページ

を参照してください。コマンドラインに、man lcdstatusまたはman LCD を入力できます。LifeKeeperのGUIで使用できるステータス情報については、サーバーのステータスの表示またはリソースのステータ

スの表示を参照してください。

ステータスの詳細表示の例 :

シャットダウンストラテジー

Resource hierarchies for machine "wileecoyote":

ROOT of RESOURCE HIERARCHY

apache-home.fred: id=apache-home.fred app=webserver type=apache state=ISP

initialize=(AUTORES_ISP) automatic restore to IN-SERVICE by LifeKeeper

info=/home/fred /usr/sbin/httpd

reason=restore action has succeeded

depends on resources: ipeth0-172.17.104.25,ipeth0-172.17.106.10,ipeth0-172.17.106.105

Local priority = 1


ステータスの詳細表示

SHARED equivalency with "apache-home.fred" on "roadrunner", priority = 10

FAILOVER ALLOWED

ipeth0-172.17.104.25: id=IP-172.17.104.25 app=comm type=ip state=ISP


info=wileecoyote eth0 172.17.104.25 fffffc00


these resources are dependent: apache-home.fred

Local priority = 1

SHARED equivalency with "ipeth0-172.17.104.25" on "roadrunner", priority = 10

FAILOVER ALLOWED





these resources are dependent: apache-home.fred

Local priority = 1


FAILOVER ALLOWED





These resources are dependent: apache-home.fred

Local priority = 1


FAILOVER ALLOWED

通信ステータスの情報

The following LifeKeeper servers are known:

machine=wileecoyote state=ALIVE

machine=roadrunner state=DEAD (eventslcm detected failure at Wed Jun 7 15:45:14EDT 2000)

The following LifeKeeper network connections exist:



to machine=roadrunner type=TCP addresses=192.168.1.1/192.168.105.19

state="DEAD" priority=2 #comm_downs=0

LifeKeeperのフラグThe following LifeKeeper flags are on:

shutdown_switchover


The shutdown strategy is set to: switchover.


LifeKeeperは、リソースのステータスを root リソースから表示します。表示には、リソースのすべての依存

関係についての情報が含まれます。

複数のリソースに共通する要素は、最初の root リソースの下に 1回のみ表示されます。各リソース記

述の第 1行には、リソースタグとその後に続くコロン (:)が表示されます (例 : device13557:)。階層内でリ

ソースの記述に使用できる情報要素を以下に示します。

l id - LifeKeeperが使用する一意のリソース識別文字列。

l app -アプリケーションのタイプを示します。例えば、サンプルリソースはWebサーバアプリケーショ

ンです。

l type -リソースのクラスタイプを示します。例えば、サンプルリソースは Apacheアプリケーションで

す。

l state -リソースの現在の状態。

l ISP—ローカルで In Serviceであり、保護されています。

l ISU — In Serviceであり、保護されていません。

l OSF—Out of Serviceであり、障害が発生しています。

l OSU—Out of Serviceであり、障害はありません。

l initialize -リソースの初期化方法を指定します。例えば、LifeKeeperはアプリケーションのリソー

スをリストアしますが、ホストアダプタは LifeKeeperなしで初期化します。

l info -オブジェクトの removeと restoreのスクリプトが使用する、オブジェクトに固有の情報があり

ます。

l reason -存在する場合、リソースが現在の状態にある原因を示します。例えば、あるアプリケー

ションがOSUの状態になった原因は、別のサーバでそのアプリケーションがIn Service (ISPまた

は ISU)になったからです。共有リソースは、グループ内の1台のサーバでのみ同時にアクティブに

できます。

l depends on resources -存在する場合、このリソースが依存するリソースのタグ名がリストされ



ます。

l these resources are dependent -存在する場合、このオブジェクトが直接依存するすべての

親リソースのタグ名が示されます。

l Local priority -このリソースについて、ターゲットサーバのフェイルオーバの優先順位の値を示し

ます。

l SHARED equivalency -このリソースが同等として定義されたリモートリソースのリソースタグと

サーバ名、およびこのリソースについてのフェイルオーバの優先順位の値を示します。

l FAILOVER ALLOWED -存在する場合、上の行で同等と指定されたリモートサーバで

LifeKeeperが動作可能であること、およびアプリケーションが障害に対して保護されていることを

示します。FAILOVER INHIBITEDは、LifeKeeperがシャットダウンされているかリモートサーバが

停止していることにより、アプリケーションが保護されていないことを示します。


ステータス表示のこのセクションには、LifeKeeperが認識しているサーバとその現在の状態、および各コ

ミュニケーションパスの情報がリストされます。

これらの通信情報の要素は、ステータス表示にあります。

l state -コミュニケーションパスのステータス。通信ステータスの値は以下の値をとります。

l ALIVE -通常の動作中。

l DEAD -通常の動作をしていません。

l priority -コミュニケーションパスに割り当てられた優先順位の値。この項目は TCPパスについて

のみ表示されます。

l #comm_downs -ポートに障害が発生してフェイルオーバが発生した回数。パスの障害によりフ

ェイルオーバが発生するのは、障害発生時に「ALIVE」のコミュニケーションパスが他にない場合

のみです。

さらに、ステータス表示では、TTYコミュニケーションパスについてのみ維持されている以下の統計値を

提供できます。

l wrpid -個々のTTYコミュニケーションパスが、一意の読み取りプロセスと書き込みプロセスを持

ちます。wrpidフィールドには、書き込みプロセスのプロセス IDがあります。書き込みプロセスは、

以下の2つの条件のうちいずれかが発生するまでスリープ状態です。

l ハートビートタイマの期限が切れ、書き込みプロセスにメッセージを送信させる。

l ローカルプロセスが、LifeKeeperのメンテナンスメッセージを他のサーバに送信するように書

き込みプロセスに要求する。書き込みプロセスは、関連付けられた TTYポートを使用し

て、メッセージを他のシステムのTTYポート上にある読み取りプロセスに送信します。

l rdpid -個々のTTYコミュニケーションパスが、一意の読み取りプロセスと書き込みプロセスを持

ちます。rdpidフィールドには、読み取りプロセスのプロセス IDがあります。読み取りプロセスは、

以下の2つの条件のうちいずれかが発生するまでスリープ状態です。


LifeKeeperのフラグ

l ハートビートタイマの期限が切れ、定義済みのハートビート間隔が期限切れになったかど

うかを読み取りプロセスが判断する必要がある場合。期限切れの場合、読み取りプロセ

スはコミュニケーションパスにDEAD状態のマークを付けます。これにより、ALIVE とマーク

された他のコミュニケーションパスがない場合はフェイルオーバイベントが開始されます。

l リモートシステムの書き込みプロセスがLifeKeeperのメンテナンスメッセージを送信し、読

み取りプロセスがメッセージの受信に必要なプロトコルを実行します。

l #NAKs -書き込みプロセスがnegative acknowledgment ( NAK)を受信した回数。NAK メッ

セージは、他のシステム上にある読み取りプロセスが、書き込みプロセスが送信したメッセージを

受け取らず、書き込みプロセスがメッセージパケットを再送信する必要があったことを意味しま

す。#NAKsの統計値は、回線ノイズに起因して、長期間にわたって集計できます。ただし、急

激に数値が増加した場合、通信サブシステムで診断手順を実行する必要があります。

l #chksumerr -サーバ間のチェックサムメッセージが一致しなかった回数。この統計値は、回線ノ

イズに起因して、長期間にわたって集計できます。ただし、急激に数値が増加した場合、通

信サブシステムで診断手順を実行する必要があります。

l #incmpltmes -受信メッセージパケットが予測サイズに一致しなかった回数。不一致の回数が

多い場合、コミュニケーションパスに関連付けられたハードウェアポートで診断手順の実行が必

要な可能性があります。

l #noreply -書き込みプロセスが肯定応答の待機中にタイムアウトし、メッセージを再送信しなけ

ればならなかった回数。肯定応答がない場合、サーバの過負荷、またはサーバの障害を意味

することがあります。

l #pacresent -読み取りプロセスが同一パケットを受診した回数。これは、送信サーバの書き込

みプロセスがタイムアウトし、同一メッセージを再送信する場合に発生することがあります。

l #pacoutseq -読み取りプロセスが、順序が不正のパケットを受診した回数。このフィールドの値

が大きい場合、メッセージパケットの脱落を示すことがあり、通信サブシステムで診断手順の実

行が必要な可能性があります。

l #maxretrys -特定のメッセージについて、再送信の最大回数を超えたときに増加する指標

(NAK とnoreplyのメッセージ)。#maxretrys フィールドの値が大きい場合、通信サブシステムで診

断手順を実行する必要があります。


ステータスの詳細表示の後部近くに、システムのフラグセットがあります。共通タイプは、プロセスのロック

が動作を完了するまで他のプロセスを確実に待機させるために使用する LCDのロックフラグです。LCDのロックの標準フォーマットは以下のとおりです。

!action!processID!time!machine:id.

一般的な LCDのロックフラグの例を示します。

l !action!02833!701236710!server1:filesys。ファイルシステム階層を作成すると、このフォーマット

でステータス表示にフラグが生成されます。 filesysの指定は、他のアプリケーションリソース階層

では別のリソースタイプである場合も、一般的なアプリケーションやユーザ定義アプリケーションで

は appである場合もあります。

l 他の代表的なフラグとして、 !nofailover!machine、 !notarmode!machine、shutdown_switchover



などがあります。 !nofailover!machineと !notarmode!machineのフラグは、LifeKeeperが作成と削

除を行う内部の一時フラグで、サーバのフェイルオーバを制御します。shutdown_switchoverフラ

グは、このサーバのシャットダウンストラテジーがswitchoverに設定されたことを示し、サーバのシ

ャットダウンによりスイッチオーバが発生します。使用可能なフラグの詳細については、依存関係

の作成方法については、LCDI-flag (1M)を参照してください。


ステータスの詳細表示の最後の項目は、このシステム用に選択された LifeKeeperのシャットダウンスト

ラテジーを示します。詳細については、サーバのシャットダウンストラテジーの設定を参照してください。

ステータスの簡略表示

このトピックでは、 lcdstatus -e コマンドの出力例を使用して、ステータスの簡略表示で提供される情

報のカテゴリについて説明します。この情報を表示する方法の詳細については、LCD (1M)のマニュアル

ページを参照してください。コマンドラインに、man lcdstatusまたはman LCD を入力できま

す。LifeKeeperのGUIで使用できるステータス情報については、サーバーのステータスの表示またはリ

ソースのステータスの表示を参照してください。

ステータスの簡略表示の例 :


BACKUP TAG ID STATE PRIO PRIMARY

svr1 appfs3910-on-svr1 appfs4238 ISP 1 svr2

svr1 filesys4083 /jrl1 ISP 1 svr2

svr1 device2126 000...300-1 ISP 1 svr2

svr1 disk2083 000...300 ISP 1 svr2


MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO

svr1 TCP 100.10.1.20/100.11.1.21 ALIVE 1

svr1 TTY /dev/ttyS0 ALIVE --


LifeKeeperは、各リソースのステータスを表示します。root リソースを表すLifeKeeperのタグ名

は、 [TAG]列の左端から開始され、階層内のリソースのタグ名は適切にインデントされてリソース間の

依存関係を表します。



BACKUP 列は、フェイルオーバの優先順序内で、このステータス表示の対象システムの次にあるシス

テムを示します。指定したリソースについて、ターゲットシステムが優先順位の最も低いシステムである

場合、そのリソースのBACKUP 列にはダッシュ (------)が表示されます。

l TAG 列 -リソースの root タグがあります。

l ID 列 -各リソースの識別文字列があります。

l STATE 列 -各リソースの現在の状態があります (リソースの状態を参照 )。

l PRIO 列 -各リソースについて、ローカルサーバのフェイルオーバの優先順位の値があります。

l PRIMARY 列 -各リソースについて、優先順位が最高のサーバ名があります。


表示のこのセクションには、ターゲットシステムで定義された各コミュニケーションパスのリストがあります。

各パスについて、以下の情報が表示されます。

l MACHINE -コミュニケーションパスのリモートサーバ名。

l NETWORK -コミュニケーションパスのタイプ (TCPまたは TTY)。

l ADDRESSES/DEVICE -コミュニケーションパスの IPアドレスまたはデバイス名のペア。

l STATE -コミュニケーションパスの状態 (ALIVEまたはDEAD)。

l PRIO - TCPパスの場合、パスに割り当てられた優先順位。TTYパスの場合、優先順位が割

り当てられていないので、この列にはダッシュ (----)が表示されます。

障害検出とリカバリのシナリオ

障害検出とリカバリを実行するために、LifeKeeperのさまざまなコンポーネントがどのように連携している

かを調べるには、3つのタイプのリカバリシナリオを説明する以下のトピックを参照してください。

IP ローカルリカバリ

SIOSでは、バックアップインターフェースが必要な場合、すべてのLifeKeeperリリースに含まれる標準

LinuxのNICボンディングメカニズムを使用してボンディングしたインターフェースを使用することを推奨し

ています。LifeKeeperのリリース7.4.0から、ボンディングしたインターフェースがサポートする唯一の方法

になりました。7.4.0以前のリリースでは、後述の IPキットのバックアップインターフェース機能を使用でき

ます。

IPローカルリカバリ機能を使用すると、 IP Recovery Kitが障害を検出したときに、LifeKeeperは、保護

している IPアドレスを、設定されているインターフェースから同一サーバ上の別のインターフェースに移動

できます。ローカルリカバリはオプションのバックアップ方式を提供するので、サーバで特定のインターフェー

スに障害が発生した場合、保護している IPアドレスをバックアップインターフェースで動作可能にできま

す。このため、アプリケーション/リソース階層全体がバックアップサーバにフェイルオーバすることを防ぐことが

できます。

ローカルリカバリのシナリオ


コマンドラインの操作

IPローカルリカバリを使用すると、サーバ上で LifeKeeperが保護する各 IPアドレスについて、バックアップ

ネットワークインターフェースを 1つ指定できます。バックアップインターフェースが正しく動作するためには、

プライマリインターフェースと同じ物理ネットワークに接続する必要があります。システム管理者は、有効

なインターフェースが選択されていることを確認する必要があります。バックアップインターフェースをある

サーバに指定し、クラスタ内の他のサーバには指定しないことには、正当性があります。選択されたある

サーバ上のバックアップインターフェースは、他のサーバ上のバックアップの選択に影響を与えません。

IP Recovery Kitによって IPアドレスの障害が検出されると、結果として生じる障害によって IPローカル

リカバリスクリプトが起動されます。LifeKeeperは最初に、その IPアドレスを現在のネットワークインターフ

ェース上で In Serviceに戻そうとします。この動作に失敗した場合、LifeKeeperはリソースインスタンス

をチェックして、使用可能なバックアップインターフェースの有無を調べます。使用可能なバックアップイン

ターフェースがある場合、 IPアドレスをバックアップインターフェースに移動しようとします。ローカルリカバリ

の試行がすべて失敗した場合、LifeKeeperは IPアドレスとすべての依存リソースをバックアップサーバに

フェイルオーバします。

バックアップインターフェース名は、 IP リソースインスタンスの情報フィールドに指定できます。情報フィール

ドの値はスペースで区切り、プライマリサーバ名、ネットワークインターフェース名、 IPアドレス、ネットマス

ク、バックアップインターフェース名の順に指定します。例を示します。

ServerA eth0 172.17.106.10 fffffc00 eth1

バックアップインターフェースを設定しない場合、5番目のフィールド値を noneに設定してください。

保護している IPアドレスがバックアップインターフェースに移動すると、2番目と5番目のフィールド値が

入れ替えられ、元のバックアップインターフェースがプライマリになり、元のプライマリインターフェースがバック

アップになります。この結果、LifeKeeperの起動時、スイッチオーバ時、およびフェイルオーバ時に

は、LifeKeeperは常に最後に設定されたインターフェースで IPアドレスを In Serviceにしようとします。

コマンドラインの操作

LifeKeeper for Linux v3.01以降では、既存の IP リソースインスタンスにバックアップインターフェースを追

加したり削除したりする機能は、コマンドラインユーティリティとして提供されています。この機能

は、lkipbuユーティリティが提供します。コマンドと構文は以下のとおりです。

lkipbu [-d machine] -{a|r} -t tag -f interface

このインスタンスについてバックアップインターフェースがすでに定義済みの場合、または不正なインターフ

ェース名が指定された場合、add 動作 (-aオプションで指定 )は失敗します。指定したインターフェー

スが、このDataKeeperの現在のバックアップインターフェースでない場合、削除動作 (-rオプションで指

定 )は失敗します。

コマンドライン操作で、 IPアドレスをバックアップインターフェースに手動で移動することもできます。この操

作は、以下の構文で -mオプションにより指定します。

lkipbu [-d machine] -m -t tag

このインスタンスについてバックアップインターフェースが設定されていない場合、この操作は失敗します。

指定したリソースインスタンスが現在 In Serviceである場合、現在のインスタンスから IPアドレスを設定

解除する ipaction remove動作、および IPアドレスをバックアップインターフェースに設定する

ipaction restore動作を使用して、移動が実行されます。移動後、 execute_broadcast_

pingの機能を使用して新しいインターフェース上にあるアドレスの動作が確認され、正常に動作して


リソースのエラーリカバリのシナリオ

いる場合は、 IP リソースインスタンスの INFOフィールドにあるインターフェースの値が入れ替えられます。

このコマンドの実行時に、指定した IP リソースインスタンスがOut of Serviceである場合、 INFOフィール

ドのプライマリとバックアップのインターフェースの値が単純に入れ替えられます。

lkipbu ユーティリティには、指定した IP リソースインスタンスについて現在指定されているプライマリと

バックアップのインターフェース、およびプライマリインターフェース上のリソースの状態 (動作中または停止 )を取得するオプションもあります。この操作は、以下の構文で -sオプションにより指定します。

lkipbu [-d machine] -s -t tag

出力は、以下のようになります。

IP address: 172.17.106.10

Netmask: 255.255.252.0

Primary interface: eth0 (up)

Backup interface: eth1

詳細については、 lkipbu(8)のマニュアルページを参照してください。


LifeKeeperは、LifeKeeperが保護するリソースのステータスと健全性をチェックするリアルタイムデーモン

モニタ lkcheckを装備しています。 In Serviceの各リソースについて、 lkcheckが定期的にそのリソース

タイプのquickCheckスクリプトを呼び出します。quickCheckスクリプトがリソースのクイック健全性チェッ

クを実行し、リソースが障害のある状態にあると判断すると、quickCheckスクリプトはイベント通知メカ

ニズムsendeventを呼び出します。

以下の図に、 lkcheckがプロセスを開始したときのリカバリプロセスの作業を示します。

1. lkcheckが実行されます。デフォルトでは、 lkcheckプロセスは 2分ごとに実行されま

す。 lkcheckが動作すると、システムで In Serviceの各リソースについて適切は quickCheckス



クリプトを呼び出します。

2. quickCheckスクリプトがリソースをチェックします。quickCheckスクリプトが実行するチェックの内

容は、各リソースタイプによって異なります。通常、スクリプトは、リソースのクライアントの動作を

シミュレートして、予測した応答を受信するかどうかを確認することにより、目的の作業を実行

するためにリソースが使用可能かどうかを単純に確認します。

3. quickCheckスクリプトがsendeventを呼び出します。quickCheckスクリプトが、リソースが障

害のある状態にあると判断した場合、sendeventを呼び出して、適切なクラスとタイプを持つイ

ベントを開始します。

4. リカバリ手順の検索。システムイベント通知メカニズムsendeventは、はじめに、イベントタイプま

たはコンポーネントについて、LCDがリソースまたはリカバリを持つかどうかを判断しようとします。

この判断を行うために、 is_recoverableプロセスは LCDのリソース階層をスキャンして、イベント

に対応するリソースインスタンス (この例では filesysの名前 )を検索します。

次の手順の動作は、スキャンでリソースレベルのリカバリ手順が検出されたかどうかによって異な

ります。

l 検出されない場合。リカバリ手順が見つからない場合、 is_recoverableは sendeventに戻

り、sendeventは基本イベント通知を続行します。

l 検出された場合。スキャンでリソースが検出された場合、 is_recoverableはリカバリプロセスをバ

ックグラウンドに運びます。 is_recoverableプロセスが戻り、sendeventが基本イベント通知を続

行します。推奨フラグ「-A」を基本警告イベント応答スクリプトに渡し、LifeKeeperがリカバリを実

行することを示します。

5. リカバリプロセスが開始されます。リカバリが続行していると仮定して、 is_recoverableはリカバリプ

ロセスを開始し、はじめにローカルリカバリを試行します。

6. ローカルリカバリが試行されます。インスタンスが検出された場合、リカバリプロセスは、LCD内の

リソース階層にアクセスし、階層ツリーからイベントに応答する方法を知っているリソースを検索

して、ローカルリカバリを試行します。各リソースタイプについて、イベントクラスにちなむ名前を持

つサブディレクトリ (そのイベントタイプのリカバリスクリプトを持つ)を含むリカバリサブディレクトリを検

索します。

リカバリプロセスが、リソース階層で障害が発生しているリソースから上方向に最も離れたリソー

スに関連付けられている、リカバリスクリプトを実行します。リカバリスクリプトが正常に完了した

場合、リカバリは停止します。スクリプトが失敗した場合、次のリソースに関連付けられたスクリ

プトが実行され、リカバリスクリプトが正常に完了するか、障害が発生したインスタンスに関連付

けられたリカバリスクリプトが試行されるまで続行されます。

ローカルリカバリが正常に完了した場合、リカバリは停止します。

7. サーバ間のリカバリが開始されます。ローカルリカバリに失敗した場合、イベントはサーバ間のリカ

バリにエスカレートします。

8. リカバリが続行されます。ローカルリカバリに失敗しているので、リカバリプロセスは失敗したインス

タンスをOut-of-Service-FAILED (OSF)状態にマークし、この失敗したリソースに依存するすべ

てのリソースをOut-of-Service-UNIMPAIRED (OSU)状態にマークします。リカバリプロセスは次

に、障害が発生したリソース、または障害が発生したリソースに依存するリソースが、他のシステ

ム上にあるリソースとイクイバレンシー情報を持っているかどうかを判断し、優先順位が最高の


サーバの障害リカバリのシナリオ

動作可能なサーバを選択します。同時にアクティブにできるイクイバレンシー情報を持つリソース

は 1つのみです。

イクイバレンシー情報が存在しない場合、リカバリプロセスは停止します。

イクイバレンシー情報が検出されて選択された場合、LifeKeeperはサーバ間のリカバリを開始し

ます。リカバリプロセスがLCM経由で、イクイバレンシー情報を持つリソースを持つ選択されたバ

ックアップシステムのLCDプロセスにメッセージを送信します。これは、LifeKeeperがサーバ間のリ

カバリを試行することを意味します。

9. lcdrecoverプロセスが転送を調整します。バックアップサーバのLCDプロセスが lcdrecoverプロ

セスを運び、同等リソースの転送を調整します。

10. バックアップサーバのアクティブ化。 lcdrecoverプロセスが同等のリソースを検出し、そのリソースが

Out of Serviceのリソースに依存しているかどうかを判断します。 lcdrecoverが、必要な各リ

ソースについて restoreスクリプト (リソースリカバリ動作スクリプトの一部 )を実行し、リソースを InServiceにします。

バックアップサーバでリソースをリストアすることにより、プライマリシステムからより多くの共有リソース

を転送することが必要になる場合があります。プライマリシステムとの間で、プライマリサーバ上で

のサービスから削除する必要があるリソースを示すメッセージが送受信され、次に選択したバック

アップサーバで In Serviceになり、重要なアプリケーションのすべての機能が提供されます。この

動作は、転送する追加の共有リソースがなくなり、バックアップで必要なすべてのリソースインスタ

ンスがリストアされるまで続行されます。


LifeKeeper Communications Manager (LCM)には、2つの機能があります。

l メッセージング。LCMは、LifeKeeperがリカバリ、設定、または監査の実行を行うときに送信する

メッセージの経路として機能します。

l 障害検出。また、LCMには、サーバに障害が発生しているかどうかを検出する役割もありま

す。

LifeKeeperには、構成内の各サーバに、ペアのサーバが動作していることを定期的に通知する組み込

みのハートビート信号があります。あるサーバが、いずれかのコミュニケーションパス経由でハートビートメッ

セージを受信しなかった場合、LifeKeeperはそのパスをDEAD としてマークします。サーバの障害リカバ

リのシナリオ

以下の図に、LCMハートビートメカニズムがサーバの障害を検出したときのリカバリ作業を示します。



以下の手順では、上の図で、LifeKeeperがあるサーバのすべての通信接続をDEAD としてマークした

場合のリカバリシナリオを説明します。

1. LCMがeventslcmを起動します。LifeKeeperがすべてのコミュニケーションパスをDEAD として

マークすると、LCMは eventslcmプロセスを開始します。

eventslcmプロセスを停止する活動は 1つのみです。

l コミュニケーションパスが、アクティブである。いずれかのコミュニケーションパスがハートビート信号の

送信を再開した場合、LCMは eventslcmプロセスを停止します。

通信障害に起因するフェイルオーバやシステムの障害を防止するために、各ペアのサーバ間に、

物理的に独立した冗長なコミュニケーションパスを 2つ以上設定することが重要です。

2. sendeventへのメッセージ送信。eventslcmが、イベントタイプmachfailを持つ sendeventを呼

び出して、システム障害警告を送信します。

3. sendeventがフェイルオーバリカバリを開始します。sendeventプログラムが、LifeKeeperがシステ

ム障害イベントを処理できることを判断し、LifeKeeperフェイルオーバリカバリプロセス

lcdmachfailを実行します。

4. lcdmachfailのチェック。 lcdmachfailプロセスがはじめに、応答していないサーバがシャットダウ

ンしていないことを確認します。システム障害の発生前に、他のシステムが正常にシャットダウン

している場合、フェイルオーバは禁止されます。次に、 lcdmachfail は、障害が発生したシステ

ムとイクイバレンシ情報を持つリソースをすべて特定します。これが、リカバリの関与ポイントです。

5. lcdmachfailがリソースをリストアします。 lcdmachfail が、障害が発生したシステムとイクイバレ

ンシ情報を持つ、バックアップサーバ上のリソースをすべて特定します。また、バックアップサーバが

該当するリソースが構成されている、優先順位が最高のアクティブなサーバであるかどうかを判

断します。すべてのバックアップサーバがこのチェックを実行するので、1台のサーバのみが階層のリ

カバリを試行します。このチェックに合格した個々の同等リソースについて、 lcdmachfail が、関

連付けられたリストアプログラムを呼び出します。次に、 lcdmachfailは、リストアしたリソースに

依存する各リソースもリストアします。これは、バックアップサーバ上の階層全体が In Serviceになるまで続行されます。


インストールと設定

LifeKeeper for Linuxのインストール

LifeKeeper for Linux ソフトウェアの完全なインストール手順については、SPS for Linux インストールガイ

ドを参照してください。詳細については、 SPS for Linux リリースノートを参照してください。

LifeKeeper for Linuxの設定

LifeKeeper環境がインストールされると、クラスタ内の各サーバ上で LifeKeeperソフトウェアを設定する

ことができます。LifeKeeper 設定手順トピックの手順に従ってください。ここには、詳細と共に各トピック

へのリンクが記載されています。

LifeKeeperの設定手順

SPS Installation Guideで説明されている LifeKeeper環境のインストールが完了している場合、クラス

タの各サーバのSPSソフトウェアを起動、設定する準備は整っています。

詳細を説明するトピックへのリンクを含む以下の手順を実行してください。以下の手順は、クラスタ内の

各サーバで実行します。

1. 次のコマンドを root として実行して LifeKeeperを起動します。


このコマンドによって、管理対象のサーバ上のまだ起動していないすべてのLifeKeeperデーモン

プロセスを起動します。

LifeKeeperの起動および停止に関する詳細情報については、LifeKeeperの起動および

LifeKeeperの停止を参照してください。

2. TTY通信接続をセットアップします。LifeKeeperのハートビート用に TTYコミュニケーションパスを

利用する場合は、ハートビート用の物理的な接続をセットアップする必要があります。

3. GUIを設定します。GUIの設定には多くのタスクが含まれます。GUIを実行するための準備の

中のLifeKeeper GUI -概要トピックから始めてください。詳細な手順については、GUIを実行す

るための準備を網羅するリンクの順番に従ってください。

注記 : LifeKeeper GUIを初めて実行すると、QuickStartボタンが表示され、これを押すと

LifeKeeperのリソースの設定を案内する手順とリンクを含むウィンドウが開きます。QuickStartConfiguration Assistantは [Help] メニューからいつでもアクセスできます。

4. コミュニケーションパスを作成します。LifeKeeperの保護を有効にする前に、コミュニケーションパ

ス (ハートビート )の定義を作成する必要があります。

5. 以下の設定作業を任意で実行します。


TTY接続のセットアップ

l サーバのシャットダウンストラテジーの設定

l 手動フェイルオーバ確認オプションの設定

l LifeKeeperハートビートの調整

l デスクトップのツールバーに LifeKeeper GUIのアイコンを追加する

l SNMPイベント転送の設定

l イベントメール通知の設定

l クラスタで STONITHデバイスを使用する場合は、STONITHデバイスを制御する

スクリプトを作成し、LifeKeeperの適切なイベントディレクトリに配置します。

6. LifeKeeperでアプリケーションを保護する準備ができました。以降の手順は、オプションの

LifeKeeper Recovery Kitの1つを使用するかどうかによって異なります。

l LifeKeeper Recovery Kitを使用する場合、リソース階層を作成、拡張する手順

についてはキットに関連するドキュメントを参照してください。

l 関連するRecovery Kitがないアプリケーションを使用する場合、2通りの選択肢

があります。

l シンプルなアプリケーションの場合、アプリケーションとLifeKeeperとの間の

インターフェースの作成方法を慎重に検討してください。LifeKeeper Coreに含まれるGeneric Application Recovery Kitを使用して保護することも

できます。

より複雑なアプリケーションの場合、オプションのLifeKeeper Extenderを使

用すると独自のRecovery Kitを作成できます。その手順とサンプルコード

については、LifeKeeper Extenderのドキュメントを参照してください。

TTY 接続のセットアップ

LifeKeeperのハートビート用に TTYコミュニケーションパスを利用する場合は、ハートビート用の物理的

な接続をセットアップする必要があります。単一の通信障害による誤ったフェイルオーバを抑止するため

には、複数のコミュニケーションパスが必要です。2つ以上のLANベース (TCP)のコミュニケーションパス

も使用する必要があります。

使用する各サーバのシリアルポートにシリアルハートビート用のTTYケーブルを接続します。

1. 次のコマンドを実行してシリアルパスをテストします。

/opt/LifeKeeper/bin/portio -r -p port -b baud

ここで、

l baudは、シリアルパス用に選択したボーレート (通常は 9600)l portは、サーバ1でテスト中のシリアルポート。例えば、 /dev/ttyS0

これでサーバ1は、サーバ2からの入力を待っている状態です。

2. サーバ2で portioコマンドを実行します。ペアの2番目のシステムで次のコマンドを実行しま

す。

76 設定

SNMPによる LifeKeeperイベント転送

echo Helloworld | /opt/LifeKeeper/bin/portio -p port -b baud

ここで、

l baudは、サーバ1に合わせて選択した同じボーレートl portは、サーバ2でテスト中のシリアルポート。例えば、 /dev/ttyS0。

3. コンソールを確認します。コミュニケーションパスが正常に動作する場合、サーバ1のコンソールに

は「Helloworld」が表示されます。表示されない場合は、診断、修正作業を終えてから

LifeKeeperの設定を続けてください。

SNMP による LifeKeeper イベント転送

SNMP による LifeKeeper イベント転送の概要

SNMP (Simple Network Management Protocol)は、ネットワークを管理するための、デバイスに依存し

ないフレームワークです。ネットワーク上のデバイスは、デバイスのベンダーが提供するMIB (ManagementInformation Base)変数によって記述されます。ネットワーク内の各ノード上では SNMPエージェントが

実行され、ネットワークマネージャノードと通信を行います。ネットワークマネージャは、エージェントに対す

るクエリでMIB変数の値を取得、設定することにより、エージェントノードを監視、制御します。エージェ

ントは、トラップと呼ばれるメッセージを非同期に生成して例外イベントの発生をマネージャにしらせるこ

ともできます。SNMP (Simple Network Management Protocol)を使用してネットワークを監視および管

理するアプリケーションは多数提供されています。

LifeKeeperのイベント通知機能では、特定のイベントが起きたときに通知を受信するアプリケーションを

登録することができます (sendevent(5)マニュアルページを参照 )。LifeKeeperは、LifeKeeperの動作を

監視するサードパーティのネットワーク管理コンソールに向けて LifeKeeperの重要なイベントに関する

SNMP トラップ通知を送信するように簡単に設定できます。

SNMP トラップを受信するリモート管理コンソールは、最初にそのシステムの管理用ソフトウェアを使用

して設定する必要があります。LifeKeeperは、外部のSNMPの設定機能を提供していません。リモー

ト管理サーバは、通常、LifeKeeperクラスタの外側に配置されます (つまりLifeKeeperのノードではあり

ません)

LifeKeeper イベントテーブル

以下の表では、LifeKeeperのイベントのリストと関連付けられているトラップ番号を示しています。オブジ

ェクト ID (OID)は、プリフィックスとそれに続く個別のトラップ番号から、次のフォーマットで構成されます。

prefix.0.specific trap number

プリフィックスは「.1.3.6.1.4.1.7359」であり、これはMIBツリーで

iso.org.dod.internet.private.enterprises.7359に展開されます(7359は、SteelEye (SIOSTechnology)の企業番号です。LifeKeeperを表す「1」をこれに続けます)。例えば、「LifeKeeperStartup Complete」イベントは次のOIDを生成します: .1.3.6.1.4.1.7359.1.0.100。

LifeKeeper イベント /説明トラップ

番号オブジェクト ID


LifeKeeperイベントテーブル

LifeKeeper Startup Complete

LifeKeeperが起動したノードから送信されます100 .1.3.6.1.4.1.7359.1.0.100

LifeKeeper Shutdown Initiated

LifeKeeperのシャットダウンを開始したノードから送信されます101 .1.3.6.1.4.1.7359.1.0.101

LifeKeeper Shutdown Complete

LifeKeeperのシャットダウンを完了したノードから送信されます102 .1.3.6.1.4.1.7359.1.0.102

LifeKeeper Manual Switchover Initiated on Server

手動スイッチオーバを要求したノードから送信されます110 .1.3.6.1.4.1.7359.1.0.110

LifeKeeper Manual Switchover Complete - recovered list

手動スイッチオーバを完了したノードから送信されます111 .1.3.6.1.4.1.7359.1.0.111

LifeKeeper Manual Switchover Complete - failed list

手動スイッチオーバに失敗したクラスタ内の各ノードから送信さ

れます

112 .1.3.6.1.4.1.7359.1.0.112

LifeKeeper Node Failure Detected for Server

クラスタ内のノードに障害が発生したときに、クラスタ内の各ノー

ドから送信されます

120 .1.3.6.1.4.1.7359.1.0.120

LifeKeeper Node Recovery Complete for Server -recovered list

障害ノードからのリソースをリカバリしたクラスタ内の各ノードから

送信されます

121 .1.3.6.1.4.1.7359.1.0.121

LifeKeeper Node Recovery Complete for Server - failedlist

障害ノードからのリソースのリカバリに失敗したクラスタ内の各

ノードから送信されます

122 .1.3.6.1.4.1.7359.1.0.122

LifeKeeper Resource Recovery Initiated

リソースをリカバリしているノードから送信されます。リカバリが完

了したか失敗したかを示す131または 132 トラップが必ずこれに

続きます。

130 .1.3.6.1.4.1.7359.1.0.130

LifeKeeper Resource Recovery Failed

リカバリを試みたリソースを稼働できなかったときに、トラップ 130を送信したノードから送信されます

131* .1.3.6.1.4.1.7359.1.0.131

LifeKeeper Resource Recovery Complete

リソースのリカバリが完了したときに、トラップ 130を送信したノー

ドから送信されます

132 .1.3.6.1.4.1.7359.1.0.132

78 設定

LifeKeeperイベント転送の設定

LifeKeeper Communications Path Up

ノードへのコミュニケーションパスが確立されました140 .1.3.6.1.4.1.7359.1.0.140

LifeKeeper Communications Path Down

ノードへのコミュニケーションパスがダウンしました141 .1.3.6.1.4.1.7359.1.0.141

トラップ PDU に追加情報を含めるために以下の変数が使用

されます。

Trapmessageすべて

のトラッ

プ

.1.3.6.1.4.1.7359.1.1

Resource Tag 130 .1.3.6.1.4.1.7359.1.2

Resource Tag 131 .1.3.6.1.4.1.7359.1.2

Resource Tag 132 .1.3.6.1.4.1.7359.1.2

List of recovered resources 111 .1.3.6.1.4.1.7359.1.3

List of recovered resources 121 .1.3.6.1.4.1.7359.1.3

List of failed resources 112 .1.3.6.1.4.1.7359.1.4

List of failed resources 122 .1.3.6.1.4.1.7359.1.4

*複数のバックアップサーバでリカバリに失敗すると、このトラップは複数回表示されることがあります。

LifeKeeper イベント転送の設定

前提条件

SNMPによるイベント転送機能は、LifeKeeperのコア機能の一部として含まれており、LifeKeeperの追加パッケージをインストールする必要はありません。ただし、LifeKeeperイベントのトラップ通知を生成

する LifeKeeperの各ノードにSNMPソフトウェアがインストールされている必要があります。LifeKeeperは、このSNMP トラップユーティリティを使ってトラップを生成します。このユーティリティは、ほとんどの

Linuxディストリビューションで snmp-utilsパッケージによって提供されています (SuSEでは snmpと呼ば

れます)。

以前のバージョン (4.1以前 )のsnmpの実装では、defCommunityディレクティブがサポートされていな

いため、トラップは「public」コミュニティストリングを使用して送信されます。

LifeKeeperのノードで SNMPエージェント snmpdを起動しておく必要はありません。

ネットワーク管理コンソール上のトラップハンドラおよびトラップメッセージに対するハンドラの応答に関する

設定は、LifeKeeperの本機能が提供する範囲ではありません。必要な手順については、お使いのシ

ステム管理ツールが提供するドキュメンテーションを参照してください。


設定作業

設定作業

LifeKeeper SNMPイベント転送を設定するには、以下の作業を実施します。SNMP トラップを生成す

る LifeKeeperクラスタの各ノードにおいて、最後の手順以外のすべてを繰り返す必要があります。

1. 上述のsnmptrapユーティリティが利用できることを確認します。

2. SNMP トラップを受信するネットワーク管理ノードを指定します。指定するには、コマンドラインを

使用するか、/etc/default/LifeKeeperファイルを編集します。DNSの問題に影響され

ないように、ドメイン名ではなく IPアドレスを指定してください。

l コマンドラインからは、lk_configsnmpを使用します (詳細については、lk_configsnmp

(1M)のマニュアルページを参照してください)。このユーティリティでは、 IPアドレスのみ使用できま

す。

l または、デフォルトファイル/etc/default/LifeKeeperを編集して IPアドレスを追加しま

す。LK_TRAP_MGR=エントリを見つけて「=」の右側に IPアドレスを入力します (「=」の前後には

スペースを入れません)。

3. defCommunityをサポートとしないSNMP実装の以前のバージョンをお使いの場合は、このス

テップを飛ばしてください。トラップは「public」コミュニティストリングを使用して送信されます。新し

いバージョンの場合は次の手順を実行します。

/usr/share/snmp/snmp.confでデフォルトのコミュニティを指定します。このファイル

が存在しない場合は、十分な制限付きの権限で作成します。ディレクティブ

defCommunityを値と共に追加します。これにより、トラップの送信時にSNMPバージョ

ン 2cのコミュニティストリングが指定されます。例えば、以下のような行を追加します。

defCommunity myCommunityString

この設定ファイルの詳細については、snmp.confマニュアルページを参照してください。

4. リモート管理コンソール上で、LifeKeeperのイベントから送られて来るトラップOIDを検出し応答

するために必要な設定手順をすべて実行します。管理ノードがLinuxサーバの場合、この機能

の検証を開始するために最低限必要なことは、snmptrapdを-f -Loオプション付き (メッセージ

を stdoutに出力 )で開始することです。

設定の確認

設定が正常に動作することを確認するには、LifeKeeperの処理を実行します (例えば、LifeKeeperを開始または停止する、または LifeKeeper GUIを使用して、あるリソースを手動で In Serviceの状態

にするなど)。管理コンソールでトラップメッセージを受信していることを確認します。トラップを受信してい

ない場合は、管理システムの適切なログファイルを調査し、管理ソフトウェアが提供する標準のトラブ

ルシューティング手順を実行してください。LifeKeeperのログを調べると、トラップメッセージの送信に問題

があるかどうかを判断することができます。詳細については、SNMPのトラブルシューティングを参照して

ください。

80 設定

SNMPイベント転送の無効化

SNMPイベント転送の無効化

LifeKeeperによるSNMP トラップの生成を無効にするには、ファイル /etc/default/LifeKeeper

のLK_TRAP_MGR環境変数から IPアドレスの割り当てを削除するだけです。コマンドラインで lk_

configsnmpユーティリティを「disable」オプションを付けて実行します (k_confignotifyalias(1M)マニュアルページの例を参照してください)。または、/etc/default/LifeKeeper を編集し

て、LKTRAP_MGRのエントリを LK_TRAP_MGR=に変更します (または行全体を削除します)。この手順

は、トラップメッセージの送信を無効にしたい各ノードで実行する必要があります。

SNMP のトラブルシューティング

SNMPによるイベント転送に関連して予想される問題とその解決策を以下に説明します。具体的な

エラーメッセージについては、 LifeKeeperメッセージカタログを参照してください。

問題 : LifeKeeperからSNMPのトラップメッセージが送信されない。

解決策 : snmptrapユーティリティがインストールされていることを確認します (通常は /bin/binにありま

す)。インストールされていない場合は、適切な SNMPパッケージをインストールします (前提条件を参

照 )。別の場所にインストールされている場合は、ファイル /etc/default/LifeKeeperのPATH変数に適

切なパスを追加します。

問題 :SNMPのエラーメッセージがログに記録されない。LifeKeeperサーバからSNMPのトラップメッセー

ジが送信されていないように見える。

解決策 : トラップを受信するネットワーク管理サーバの IPアドレスがLK_TRAP_MGRに設定されているこ

とを確認します。コマンドラインで、lk_configsnmpを「--query」オプション付きで使用して設定を確

認します (lk_configsnmp(1M)マニュアルページの例を参照してください)。または、ファイル

/etc/default/LifeKeeperのLK_TRAP_MGRのエントリを確認します。この変数は、SNMP トラッ

プメッセージを生成する LifeKeeperの各ノードで設定する必要があります。

LifeKeeper イベントメール通知

LifeKeeper イベントメール通知の概要

LifeKeeperイベントメール通知は、特定のイベントがLifeKeeperクラスタで発生したときに 1人以上の

ユーザがメールによる通知を受信する仕組みです。LifeKeeperのイベント通知機能では、特定のイベ

ントが起きたときに通知を受信するアプリケーションを登録することができます (sendevent(5)マニュア

ルページを参照 )。LifeKeeperは、LifeKeeperの動作を監視したいユーザのグループに向けて

LifeKeeperの重要なイベントに関するメール通知を送信するように簡単に設定できます。さらに、lk_

log(8)ユーティリティまたは LifeKeeper GUIのサーバログファイルの表示機能を使用すると、送信さ

れた各メール通知のログを参照することができます。メッセージは通常 NOTIFYログに入ります。ログの

内容をコマンドラインで表示する方法の詳細については、lk_log(8)マニュアルページを参照してくだ

さい。

デフォルトでは、LifeKeeperイベントメール通知は無効になっています。この機能を有効にするに

は、/etc/default/LifeKeeperで指定する LK_NOTIFY_ALIAS環境変数を設定する必要が


メールが生成される LifeKeeperのイベント

あります。LK_NOTIFY_ALIAS環境変数には、メールアドレスまたはエイリアスを 1つまたは複数個 (カンマ区切り)設定できます。LK_NOTIFY_ALIASを設定するには、コマンドラインからlk_

confignotify alias (lk_confignotifyalias(1M)マニュアルページで例を参照してください)を実行してイベントが発生したときにメールを受信するアドレスまたはアドレスリストを指定するか、デフォ

ルトファイル/etc/default/LifeKeeperを編集してメールアドレスまたはアドレスリストを追加しま

す。LK_NOTIFY_ALIAS=エントリを見つけて、アドレスまたはカンマ区切りのアドレスリストを入力しま

す。選択した LifeKeeperイベントについてメールを送信する必要があるクラスタのすべてのノードで以上

の手順を繰り返します。

メール通知を無効にするには、引数 -disableを付けて lk_confignotifyalias (lk_confignotifyalias(1M)マニュアルページで例を参照してください)を実行するか、デフォルトファイ

ル/etc/default/LifeKeeperを編集して LK_NOTIFY_ALIASの設定を削除します (この行を

LK_NOTIFY_ALIAS=に変更 )。

メールが生成される LifeKeeperのイベント

以下のLifeKeeperイベントが発生するとメール通知が生成されます (LK_NOTIFY_ALIASが設定され

ている場合 )。

LifeKeeper のイベン

トイベントの説明

LifeKeeper StartupComplete LifeKeeperが起動したノードから送信されます。

LifeKeeper ShutdownInitiated LifeKeeperのシャットダウンを開始したノードから送信されます。

LifeKeeper ShutdownComplete LifeKeeperのシャットダウンを完了したノードから送信されます。

LifeKeeper ManualSwitchover Initiatedon Server

手動スイッチオーバを要求されたノードから送信されます。

LifeKeeper ManualSwitchover Complete- recovered list

手動スイッチオーバが完了したノードから、リカバリに成功したリソースのリスト

と共に送信されます。

LifeKeeper ManualSwitchover Complete- failed list

手動スイッチオーバが完了したノードから、切り替えに失敗したリソースのリ

ストと共に送信されます。

LifeKeeper NodeFailure Detected

クラスタ内のノードに障害が発生したときに、クラスタ内の各ノードから送信

されます。

LifeKeeper NodeRecovery Completefor Server - recoveredlist

障害ノードからのリソースをリカバリしたクラスタ内の各ノードから、リカバリに

成功したリソースのリストと共に送信されます。

82 設定

LifeKeeperイベントメール通知の設定

LifeKeeper NodeRecovery Completefor Server - failed list

障害ノードからのリソースのリカバリに失敗したクラスタ内の各ノードから、リカ

バリに失敗したリソースのリストと共に送信されます。

LifeKeeper ResourceRecovery Initiated

リソースをリカバリしているノードから送信されます。このメールに続いて、リカ

バリが完了したか失敗したかを示すメッセージ(「Resource RecoveryComplete」または「Resource Recovery Failed」)が必ず送信されます。

LifeKeeper ResourceRecovery Complete

リソースのリカバリが成功した時点で、「LifeKeeper Resource RecoveryInitiated」メッセージを送信したノードから、リカバリに成功したリソースのリスト

と共に送信されます。

LifeKeeper ResourceRecovery Failed

リソースが In Serviceの状態になることができない場合に、「LifeKeeperResource Recovery Initiated」メッセージを送信したノードから、リカバリに成

功したリソースのリストと共に送信されます。

LifeKeeperCommunicationsPath Up

ノードへのコミュニケーションパスが確立されました。

LifeKeeperCommunicationsPath Down

ノードへのコミュニケーションパスがダウンしました。

LifeKeeper イベントメール通知の設定

前提条件

イベントメール通知機能は、LifeKeeperのコア機能の一部として含まれており、LifeKeeperの追加パッ

ケージをインストールする必要はありません。ただし、LifeKeeperイベントのメール通知を生成する

LifeKeeperの各ノードに電子メールソフトウェアがインストールされている必要があります。LifeKeeperは、mailxパッケージによってインストールされるメールユーティリティを使用して通知を送信します。

メールの設定は、LifeKeeperの本機能が提供する範囲ではありません。デフォルトでは、LifeKeeperイベントメール通知は無効になっています。

設定作業

LifeKeeperイベントメール通知を設定するには、以下の作業を実施します。

1. 上述のメールユーティリティが利用できることを確認します。

2. LifeKeeperのイベントのメール通知を受信するユーザ (1人以上 )を特定し、LifeKeeperのデフ

ォルトファイル/etc/default/LifeKeeperのLK_NOTIFY_ALIASを設定します。これを行

うには、コマンドラインを使用するか、ファイル/etc/default/LifeKeeperを編集して通知

を受信するメールアドレスまたはエイリアスを指定します。

l コマンドラインからは、lk_confignotifyaliasを使用します (詳細については、lk_

confignotifyalias (1M)のマニュアルページを参照してください)。このユーティリティ

では、カンマ区切りのメールアドレスまたはエイリアスのみ使用できます。


設定の確認

l または、デフォルトファイル/etc/default/LifeKeeperを編集してメールアドレスま

たはエイリアスを追加します。LK_NOTIFY_ALIAS=エントリを見つけて「=」の右側にメー

ルアドレスまたはエイリアス (1つまたはカンマ区切りのリスト )を入力します (「=」の前後に

はスペースを入れません)。

設定の確認

設定が正常に動作することを確認するには、LifeKeeperの処理を実行します (例えば、LifeKeeperを開始または停止する、または LifeKeeper GUIを使用して、あるリソースを手動で In Serviceの状態

にするなど)。ファイル/etc/default/LifeKeeperのLK_NOTIFY_ALIASで指定したユーザが

メールを受信していること、LifeKeeperのログファイルにメッセージが記録されていることを確認します。

メールを受信していない場合は、メール障害に対する通常のトラブルシューティング手順を実行してくだ

さい。LifeKeeperのログを調べると、メール送信に問題があるかどうかを判断することができます。詳細

については、メール通知のトラブルシューティングを参照してください。

イベントメール通知の無効化

LifeKeeperによるメール通知の生成を無効にするには、ファイル/etc/default/LifeKeeperの

LK_NOTIFY_ALIAS環境変数からメールアドレスとエイリアスの割り当てを削除するだけです。コマンド

ラインで lk_confignotifyaliasユーティリティを「--disable」オプションを付けて実行します (k_confignotifyalias (1M)マニュアルページの例を参照してください)。また

は、/etc/default/LifeKeeperを編集して、LK_NOTIFY_ALIASのエントリを LK_NOTIFY_

ALIAS =に変更します。この手順は、メール送信を無効にしたい各ノードで実行する必要がありま

す。

メール通知のトラブルシューティング

LifeKeeperイベントのメール通知に関連して予想される問題とその解決策を以下に説明します。具

体的なエラーメッセージについては、 LifeKeeperメッセージカタログを参照してください。

問題 : LifeKeeperからのメールを受信しない。

解決策 : メールユーティリティがインストールされていることを確認します (通常は /bin/mailにあります)。イ

ンストールされていない場合は、mailxパッケージをインストールします。別の場所にインストールされてい

る場合は、ファイル/etc/default/LifeKeeperPATH変数にメールユーティリティのパスを追加し

ます。

問題 : LifeKeeperからのメールを受信しない。

解決策 : メール設定を確認し、配信用のキューにメールメッセージが滞留していないことを確認します。

メール設定の問題が原因でメッセージが滞留することがあります。LK_NOTIFY_ALIASで指定している

メールアドレスが有効なアドレスであり、カンマで区切られていることを確認します。

問題 : ログファイルに「mail returned」というエラーメッセージがある。

84 設定

任意の設定作業

解決策 : メールコマンドがエラー「X」を返す場合、LifeKeeperイベントがメールを生成、送信する際に

問題 (「node failure」など)が発生しています。メール設定を確認し、LK_NOTIFY_ALIASに含まれる

メールアドレスが有効であり、アドレスのリストがカンマで区切られていることを確認します。また、LK_

NOTIFY_ALIASで指定しているメールアドレスのフォーマットを使用してコマンドラインからそれらのアド

レスにメールを送信できることを確認します。

問題 : メッセージや成功または失敗がログに何も記録されず、ノードのフェイルなどのLifeKeeperイベン

トが発生したときもメールを受信するはずのユーザがメールを受信しない。

解決策 : LK_NOTIFY_ALIASにメールアドレスが設定されており、複数の場合はカンマで区切られて

いることを確認します。コマンドラインで、lk_confignotifyaliasを「--query」オプション付きで使用

して設定を確認します (lk_confignotifyalias(1M)マニュアルページの例を参照してください)。または、ファイル/etc/default/LifeKeeperのLK_NOTIFY_ALIASで確認します。この変数

は、メール通知メッセージを生成する LifeKeeperの各ノードで設定する必要があります。ま

た、LifeKeeperイベントメール通知の概要で、そのLifeKeeperイベントがメールメッセージを生成するの

かどうかを確認します (すべてのイベントがメールメッセージを生成するわけではありません)。

任意の設定作業

デスクトップのツールバーに LifeKeeper GUI のアイコンを追加する

LifeKeeper GUIパッケージをインストールすると、LifeKeeper GUIのアイコンが自動的に [System]サブメ

ニューの下のデスクトップメニューに追加されます (アイコンが表示されない場合は、一度ログアウトして

からもう一度ログインしてください)。デスクトップのツールバーにアイコンを追加したい場合は、次の手順

を実行してください。

注記 : [System] メニューの場所は Linuxディストリビューションごとに異なります。

Gnomeを使用している場合 :1. Footprintデスクトップメニューで、 [System]を選択します。

2. [LifeKeeper GUI]を右クリックします。

3. [Add this launcher to panel]を選択します。

デスクトップのツールバーにアイコンが表示されます。

KDEを使用している場合 :1. Kデスクトップメニューで, [Panel]、 [Add Application]の順に選択します。

2. [System]、 [LifeKeeper GUI]の順に選択します。

デスクトップのツールバーにアイコンが表示されます。


アイコンの位置を変更する

アイコンの位置を変更する

ツールバー上のLifeKeeper GUIのアイコンの位置を変更したい場合は、次の手順を実行してください

(Gnome、KDE共通 )。

1. ツールバーのLifeKeeper GUIアイコンで右クリックし、 [Move] (または [Move Applet] )を選択しま

す。

2. アイコンはツールバーの任意の場所に移動させることができます。

3. 好きな場所で左クリックしてアイコンを新しい位置に固定します。

手動フェイルオーバ確認オプションの設定

構成によっては、障害を検出されたシステムのフェイルオーバリカバリを LifeKeeperが実行する前にシス

テム管理者の手動による確認を必須とすることが望ましいこともあります。この機能を使用すると、実際

には起きていないリモートシステムのクラッシュを LifeKeeperが検出した場合に、LifeKeeperがフェイル

オーバを実行するのを防ぐことができます。このような状況は、ハートビートのコミュニケーションパスが冗

長化されていない構成で発生する可能性があります。

このオプションを設定するには、フェイルオーバリカバリを実行するシステムで confirmso!unameフラグ

を設定します。ここで unameはフェイルしたリモートシステムの名前です。LCDI-flag(1M)マニュアル

ページを参照してください。

このフラグが設定された状態で LifeKeeperが該当システムがフェイルしたと判断した場合、スイッチオー

バを確認またはブロックするには、lk_confirmso(1M)コマンドを使用する必要があります。このコマン

ドの使用方法およびこの機能に関連するデフォルトのタイムアウトや動作を指定する値

(/etc/default/LifeKeeper内の設定項目 CONFIRMSOTOおよびCONFIRMSODEFで指定 )の変更方法については、lk_confirmso(1M)マニュアルページを参照してください。

サーバのシャットダウンストラテジーの設定

シャットダウンストラテジーは、サーバがシャットダウンするときにバックアップサーバにリソースをスイッチオー

バするかどうかを制御する LifeKeeperの設定オプションです。以下のオプションがあります。

DoNot Switch Over Resources(デフォルト )

LifeKeeperは、正常なシャットダウンではバックアップサーバのリ

ソースを起動しません。

Switch Over Resources LifeKeeperは、正常なシャットダウンでバックアップサーバのリソー

スを起動します。

シャットダウンストラテジーは、デフォルトでは「DoNot Switch Over Resources」に設定されています。ク

ラスタ内の各サーバでどちらのストラテジーを使用するかを決定し、必要に応じてシャットダウンストラテ

ジーを「Switch Over Resources」に変更してください。

クラスタ内の各サーバで次のようにします。

1. [Edit] メニューで [Server]を選択し、次に [Properties]をクリックします。

2. 修正するサーバを選択します。

86 設定

LifeKeeperハートビートの調整

3. [Server Properties]ダイアログの [General] タブで、[Shutdown Strategy]を選択します。

注記 :シャットダウンストラテジーが有効に機能するには、正常なシャットダウン時に LifeKeeperのプロセ

スが起動している必要があります。 LifeKeeperが起動していないか、リソースが In Serviceでない場

合、リソースはスイッチオーバされません。

LifeKeeperハートビートの調整

ハートビート設定項目の概要

LifeKeeperのハートビートは、各サーバが「生存」していることを確認するためにコミュニケーションパスを

通じて LifeKeeperのサーバ間で送受信される信号です。ハートビートに関しては、LifeKeeperが障害

を検知する速さを決定する要素が2つあります。

l 間隔 :ハートビートの間の秒数。

l ハートビート回数 : コミュニケーションパスが切断しているとLifeKeeperが判定するまでに許容さ

れるハートビートの失敗回数。

これらのハートビートの値は、LifeKeeperデフォルトファイル /etc/default/LifeKeeper内の以下の2つの

設定項目で指定します。デフォルト値を使用した場合よりも早期にサーバの障害を検知したい場合

は、設定項目を変更することができます。

l LCMHBEATTIME (間隔 )

l LCMNUMHBEATS (ハートビート回数 )

次の表は、TCPおよびTTY経由のハートビートの設定項目についてのデフォルト値と最小値の一覧

です。TTYコミュニケーションパスは、媒体として通信速度が遅いため、間隔を 2秒未満にすることはで

きません。

設定項目デフォルト値最小値

LCMHBEATTIME 5 1 (TCP) 2 (TTY)

LCMNUMHBEATS 3 2 (TCP、TTY)

重要な注記 :どちらの設定項目も、クラスタ内のすべてのサーバで必ず同じ値にする必要があります。

例

LifeKeeperのクラスタで両方の間隔がデフォルト値に設定されていると仮定します。LifeKeeperは、

サーバ間で 5秒ごとにハートビートを送信します。通信障害によって 2回のハートビートが途絶し、3回目のハートビートで再開した場合、LifeKeeperはアクションを実行しません。コミュニケーションパスの切

断継続時間がハートビート 3回分になった場合は、LifeKeeperはそのコミュニケーションパスを切断と

判定します。ただし、他方の冗長的なコミュニケーションパスも切断と判定されるまではフェイルオーバを

開始しません。


ハートビートの設定

ハートビートの設定

設定項目とその値を追加するには、 /etc/default/LifeKeeperファイルを手動で編集する必要がありま

す。通常、デフォルトファイルにはこれらの設定項目のエントリが含まれていません。設定したい値を含

めて次のような行を追加してください。

LCMHBEATTIME=x

LCMNUMHBEATS=y

最小値を下回る値を設定した場合、LifeKeeperはその値を無視して代わりに最小値を採用します。

設定上の考慮事項

l 間隔を 5秒未満に設定すると、ネットワークの中断による誤ったフェイルオーバを発生させるリス

クが高くなるため、5秒未満に設定する場合は、コミュニケーションパスをプライベートネットワーク

上で構成してください。

l 検証によると、ハートビート回数を 2未満にした場合に誤ったフェイルオーバの発生リスクが高ま

ります。このため、この値は 2以上に制限されています。

l 誤ったフェイルオーバを回避するため、間隔およびハートビート回数の値はどちらもクラスタ内のす

べてのサーバで必ず同じ値にする必要があります。このため、これらの値を編集する前に両方の

サーバで LifeKeeperを停止しておく必要があります。LifeKeeperの稼働開始後、アプリケーショ

ン保護している状態でハートビートの設定項目を編集する場合は、コマンド lkstop -fが使用で

きます。このコマンドは LifeKeeperを停止しますが、保護下のアプリケーションは停止しません。

l LCMHBEATTIMEおよびLCMNUMHBEATSの値に上限値はありません。ただし、非常に大

きい数字に値を設定すると、LifeKeeperの障害検知能力は著しく損なわれます。例えば、両

方の値を 25に設定した場合、サーバ障害を検知するまでに LifeKeeperは 625秒間 (10分間

以上 )待つことになります。これはサーバをリブートしてクラスタに再参加させるのに十分な時間

です。

注記 : TTYおよびTCPコミュニケーションパスの両方を使用する場合、各設定項目の値は両方のコミ

ュニケーションパスに適用されます。唯一の例外は、TTYコミュニケーションパスの最小値である 2未満

の値が間隔に設定された場合です。

例えば、障害をできるだけ早く検知するために、LifeKeeperで許容される最小値を指定したとします。

LCMHBEATTIME=1

LCMNUMHBEATS=2

このとき LifeKeeperは TCPコミュニケーションパスの間隔に 1秒を採用し、TTYの間隔には 2秒を採

用します。サーバ障害が発生すると、LifeKeeperは間隔の短いTCPの障害 (1秒間隔の2回のハー

トビート後 )を先に検知します。ただし、TTYの障害 (2秒間隔の2回のハートビート後 )を検知するま

では何もしません。

SPS でカスタム証明書を使用する

Steeleye Protection Suite (SPS)の7.5以降では、異なるシステムとの通信にSSL/TLSが使用されま

88 設定

証明書の使用方法

す。デフォルトでは、ノード間で一定の身元確認が可能なデフォルト証明書がSPS と共にインストール

されます。このドキュメントでは、デフォルト証明書を組織独自の認証局 (CA)が作成した証明書に置

き換える方法を説明します。

証明書の使用方法

LifeKeeperサーバ間の通信では、転送するデータを保護するためにSSL/TLSが使用されます。双方

のシステムは自身を特定する証明書を提示し、証明書を提示されたシステムは、CA証明書を使用

して提示された証明書をSSL接続経由で確認します。

以下の3種類の証明書が使用されます。

l /opt/LifeKeeper/etc/certs/LK4LinuxValidNode.pem (サーバ証明書 )

l /opt/LifeKeeper/etc/certs/LK4LinuxValidClient.pem (クライアント証明書 )

l /opt/LifeKeeper/etc/certs/LKCA.pem(認証局 )

最初の2つの証明書は、サーバが実行する検証に合格するためにCA証明書による署名が必要で

す。証明書の共通名は検証されません。証明書はCAによって署名されるのみということに注意してく

ださい。

独自の証明書の使用

運用環境によっては、デフォルト証明書を組織内部のCAまたは商用 CAが作成した証明書に置き

換える必要がある場合があります。そのような場合は、上記の3種類の証明書を、同じ証明書ファイ

ル名を持つ新しい証明書に置き換えます。これらの証明書は PEM形式で

す。LK4LinuxValidNode.pemおよびLK4LinuxValidClient.pemは、それぞれキーと証明書の両方を含

んでいます。LK4LinuxValidNode.pem証明書は、サーバタイプの証明書で

す。LK4LinuxValidClient.pemは、クライアントタイプの証明書です。

デフォルトの証明書を置換した場合、変更を反映するには LifeKeeperを再起動する必要がありま

す。証明書の設定を間違えると、steeleye-lighttpdデーモンが起動に失敗し、LifeKeeperのログファイ

ルにエラーが記録されます。問題が発生した場合、このログファイルを参照すると実行すべき完全なコ

マンドを見ることができます。

Linux の設定

オペ

レーティ

ングシ

ステム

必要なすべてのパッケージをインストールするためには、オペレーティングシステムはデフォルト

でインストールしてください。最小構成のオペレーティングシステムでは必要なすべてのパッ

ケージが含まれないため、LifeKeeperで使用することはできません。


Linuxの設定

カーネ

ルのア

ップ

デート

LifeKeeperクラスタの可用性を最大限に引き出すには、システムで使用するカーネルの

バージョンが非常に重要です。次の表は、サポート対象のディストリビューションおよびバージ

ョンと、LifeKeeper認定テストに合格したカーネルを示しています。

ディストリビューション/バージョンサポート対象カーネル

RedHat Enterprise Linux 5およびRedHatEnterprise Linux 5 Advanced Platform (x86およ

びAMD64/EM64T)

2.6.18-8.el5 2.6.18-8.1.1.el5 (デフォルトカーネル) 2.6.18-53.el5 (Update 1) 2.6.18-92.el5 (Update 2) 2.6.18-128.el5 (Update 3) 2.6.18-164.el5 (Update 4) 2.6.18-194.el5 (Update 5) 2.6.18-238.el5 (Update 6)2.6.18-274.el5 (Update 7)2.6.18-308.el5 (Update 8)

Red Hat Enterprise Linux 6 (x86および

AMD64/EM64T)

2.6.32-71.el62.6.32-131.17.1.el6 (Update 1)2.6.32-220.el6 (Update 2)

SUSE SLES 10 (x86および x86_64)

2.6.16.21-0.8 (デフォルトカーネル) 2.6.16.46-0.12 (SP1) 2.6.16.60-0.21 (SP2) 2.6.16.60-0.23 2.6.16.60-0.54 (SP3)2.6.16.60-0.85.1 (SP4)

SUSE SLES 11 (x86および x86_64) 2.6.27.19-52.6.32.12-0.7 (SP1)

Oracle Enterprise Linux 5 (x86および x86_64)

2.6.18-8.el5 2.6.18-53.0.0.0.1.el5 (Update 1) 2.6.18-92.0.0.0.1.el5 (Update 2) 2.6.18-128.0.0.0.1.el5 (Update 3) 2.6.18-164.0.0.0.1.el5 (Update 4)2.6.18-194.0.0.0.1.el5 (Update 5)2.6.18-238.0.0.0.1.el5 (Update 6)2.6.18-274.0.0.0.1.el5 (Update 7)2.6.18-308.0.0.0.1.el5 (Update 8)

The Community ENTerprise Operating System(CentOS) 5.0 (x86および x86_64)

2.6.18-8.el5 2.6.18-53.el5 (Update 1) 2.6.18-92.1.10.el5 (Update 2) 2.6.18-128.el5 (Update 3) 2.6.18-164.2.1.el5 (Update 4)2.6.18-194.el5 (Update 5) 2.6.18-238.el5 (Update 6)2.6.18-274.3.1.el5 (Update 7)2.6.18-308.el5 (Update 8)

The Community ENTerprise Operating System(CentOS) 6.0 (x86および x86_64)

2.6.32-71.el62.6.32-131.el6 (Update 1)2.6.32-220.el6 (Update 2)

注記 : このリストのサポート対象のディストリビューションおよびカーネルは、LifeKeeperのみを

考慮したものです。お使いのサーバおよびストレージハードウェアについては、各メーカーがサ

ポートするディストリビューションおよびカーネルに従ってください。

90 設定

Linuxの設定

デバイ

スの動

的な

追加

LifeKeeperが起動する前に、Linux側ですべてのデバイスの設定を完了しておく必要があり

ます。LifeKeeperの起動後に LifeKeeperの保護対象のデバイスを設定する場合、そのデ

バイスを共有する各サーバで LifeKeeperを停止して再起動する必要があります。これによ

り、デバイスを検知および検証する機能によって設定が確認され、LifeKeeperがデバイスに

アクセスできるようになります。

LUNのサ

ポート

LinuxのSCSI ドライバには、論理ユニット (LUN)の検索対象とするデバイスを制御するいく

つかのパラメータがあります。

l LUNをサポートしないデバイスのリスト -このリストのデバイスは LUNをサポートしない

ことがわかっているため、SCSI ドライバはこれらのデバイスに対して LUNを検索する

ことを許可しません。

l LUNをサポートするデバイスのリスト -このリストのデバイスは LUNをサポートすること

がわかっているため、必ずLUNを検索します。

l Probe all LUNs on each SCSI device -デバイスがどちらのリストにも存在しない場

合、検索するかどうかを指定します。このパラメータは、make configを使用し

てSCSIモジュールセクションで設定します。

(SUSEを含む)ほとんどのディストリビューションでは、Probe all LUNs設定はデフォルトで有

効になっていますが、RedHatではデフォルトで無効に設定されています。LifeKeeperの構

成でデータ保護を目的として通常使用される外部 RAID コントローラには、多くの場合、

複数のLUN (論理ユニット )が設定されます。LUNのサポートを有効にするには、このフィー

ルドを選択してカーネルを再構築する必要があります。

カーネルやモジュールを再構築せずにProbe all LUNsを有効にするには、変数 max_scsi_lunsを 255に設定します (これによって最大 255個のLUNをスキャンするようになりま

す)。SCSI ドライバがモジュールになっているカーネル (Red Hatなど)でmax_scsi_lunsを設

定するには、 /etc/modules.confに以下のエントリを追加してから、初期 RAMディスクを再

構築し、再起動してそのRAMディスクを読み込みます。

options scsi_mod max_scsi_luns=255

SCSI ドライバをカーネルにコンパイルするカーネル (SUSEなど)でmax_scsi_lunsを設定す

るには、 /etc/lilo.confに以下のエントリを追加します。

append="max_scsi_luns=255"

注記 : 255個のLUNをスキャンすると、デバイスによってはブートのパフォーマンスに悪影響を

与える可能性があります (特に、BLIST_SPARSELUNが指定されたデバイス)。DellPV650Fというアレイではそのような状況が発生しました。このパフォーマンスの問題を回避

するには、アレイ上で設定した LUNの最大数 (16または 32など)をmax_scsi_lunsに設

定します。例えば、以下のようになります。

append="max_scsi_luns=16"


Linuxの設定

libstdc-++ ライ

ブラリの

要件

SPSインストールセットアップスクリプトを実行中に、 libstdc++ ライブラリの依存関係要件の

失敗に関するメッセージが表示される場合があります。このライブラリは、いくつかのcompat-libstdc++ rpmパッケージの中で提供されており、ハードウェアプラットフォームおよび実行する

Linuxディストリビューションに依存します。64ビットシステムにおいても、LifeKeeperでは、64ビットバージョン (x86_64)ではなく、32ビットアーキテクチャのパッケージを使用する必要があり

ます。64ビットバージョンがインストールされている場合、必要なライブラリが欠落しているた

め起動に失敗します。

この問題を回避 (解決 )するには、OSのインストールメディアに含まれている 32ビットバージ

ョンのcompat-libstdc++パッケージをインストールした後、 I/Sセットアップスクリプトを実行 (再実行 )します。一部のディストリビューションでは、このパッケージの複数の32ビットバージョ

ンを用意していることに注意してください (例えば、compat-libstdc++-296-2.96-132.7.2、compat-libstdc++-33-3.2.3-47.3など)。このような場合は、単純に両方のバージョ

ンをインストールして必要なライブラリがインストールされるようにします。

libXpおよび

libXtライブラ

リの要

件

上記と同様に、 libXpおよび libXt ライブラリの依存関係要件の失敗に関するメッセージが

表示される場合もあります。LifeKeeperでは、64ビットプラットフォームでもこれらのライブラリ

の32ビットバージョンが必要です。

LifeKe-eper をインス

トール

した後

に

yumupdateを実行

する

yum updateを実行すると以下のエラーが発生する場合があります。

ksh conflicts with pdksh

LifeKeeperを正しく動作させるには、kshパッケージをインストールしたり更新したりしないで

ください。パッケージをインストールしたり更新したりした場合は、 SPSインストールセットアッ

プスクリプトを必ず再実行してください。これにより、競合する kshパッケージが削除され、必

要な pdkshパッケージが再インストールされます。

92 設定

データレプリケーションの設定

データレプリケーションの設定

項目説明

SteelEye DataKeeperの機能 / ディストリビュー

ションマトリクス

SteelEye DataKeeperは、Linux カーネルバージョン 2.6以降をサポートし

ます。一部のDataKeeper機能には、追加でカーネルの最低要件があり

ます。

次の表は、DataKeeperの各機能をサポートする Linuxディストリビューシ

ョンを「X」で示しています。

DataKeeper の機能

Red Hat SUSE

RHEL4

RHEL5+

RHEL6

SLES10

SLES11

複数ターゲットサポート (カーネル 2.6.7+) X X X X X

ビットマップインテントログ (カーネル 2.6.16+) X X X X

非同期 (WAN) レプリケー

ション (カーネル 2.6.16+) X X X X

ビットマップマージ (2.6.27+) X X X

*RHEL 5.4以降が該当します。ビットマップマージのコードは、RedHatEL5 Update 4カーネルにバックポートされました。

SteelEye DataKeeperドキュメンテーション

SteelEye DataKeeperのドキュメンテーションは、SIOS Technology Corp.のWebサイトにある「SteelEye Protection Suiteテクニカルドキュメンテー

ション」の中に収録されています。


ネットワーク設定


項目説明

ルーティン

グテーブル

に対する

IPRecoveryKitの影

響

LifeKeeperが保護する IPアドレスは、論理インターフェースとして、Linux上で実装され

ます。Linux上で論理インターフェースを設定すると、その論理インターフェースに関連付

けられたサブネットへのルートが自動的にルーティングテーブルに追加されます。例えば、

物理インターフェースによってそのサブネットへのルートがすでに存在する場合も同様で

す。この追加により、同じサブネットに対して複数のルーティングテーブルエントリが作成さ

れる可能性があります。

接続元のアドレスを検査して確認するアプリケーションの場合、複数のルーティングテー

ブルエントリがあると、LifeKeeperシステムが (LifeKeeperがインストールされていない)他のシステム上のそのようなアプリケーションに接続しようとしたときに問題が発生することが

あります。複数のルーティングテーブルエントリによって、物理インターフェースからではなく

論理インターフェースから接続が張られているように見えます。

IP サブネ

ットマスク

LifeKeeper保護下の IP設定では、物理インターフェースの IPアドレスと、LifeKeeperが保護するエイリアス IPアドレスのサブネットを同じにする場合、2つのアドレスのサブネッ

トマスクを同じにする必要があります。サブネットマスクの設定を間違えると、LifeKeeperGUIのクライアントとサーバ間の接続に遅延や障害が発生します。

EEpro100ドライバの

初期化

Intel Ethernet インターフェースを搭載するシステムでは、eepro100ドライバの初期化の

問題を解決するために、 Intel e100ドライバをインストールする必要がありま

す。eepro100ドライバを使用すると、ブート時にインターフェースが起動したときに以下の

エラーが発生し、インターフェースをシャットダウンするまでエラーを出し続けることがありま

す。

eth0: card reports no Rx buffers

eth0: card reports no resources

アプリケーションの設定

項目説明

glibc 2.2 を

使用する場

合のデータ

ベースサポート

Informix Dynamic Server 9.2は、glibc 2.1も使用します。glibc 2.2を使用するディ

ストリビューションでは、 Informix Dynamic Server 9.2.1以降が必要です。

データベース

初期化ファイ

ル

データベースの初期化ファイルは、共有デバイス上に置いてローカルファイルシステム

の指定場所にシンボリックリンクを作成するか、または個別のシステム上に保持して

変更を適用する必要がある場合に手動で両方のシステムを更新するかのいずれか

に必要があります。

94 設定

ストレージとアダプタの設定

項目説明

Oracleのロー

カルマウントポ

イント

Oracleのローカル環境は、「internal」として接続するか、「sysdba」として接続するか

によって異なります。LifeKeeperの保護下に置く場合、「connect / as

sysdba」を使用してローカルマウントポイント上にデータベースを作成する必要があ

ります。

Apacheのア

ップデート

Linuxオペレーティングシステムのアップグレードの一環として、LifeKeeperが保護する

Apacheアプリケーションをアップグレードするには、起動時のデフォルトサーバインスタ

ンスを無効にする必要があります。

設定ファイル (httpd.conf)がデフォルトのディレクトリ (/ etc / httpd / conf)にある場合、

設定ファイルはRedHatのアップグレードによって上書きされます。したがって、アップ

グレードする前にファイルのコピーを作成し、アップグレードした後にファイルをリストア

する必要があります。

また、の「Specific Configuration Considerations for ApacheWeb Server」セクション

を参照してください。ApacheWeb Server Recovery Kit Administration Guide.


項目説明

マルチパス I/Oおよび

冗長コントローラ

マルチパス I/Oのソリューションには数種類あり、すでに利用

可能なものやLinux環境向けに開発中のものなどがありま

す。SIOS Technology Corp.は、多くのサーバベンダ、アダプタ

ベンダ、およびドライバ開発者と積極的に協力すること

で、LifeKeeperとマルチパス I/Oソリューションとの協調動作を

実現しています。データの整合性を保護するために

LifeKeeperが使用するSCSI リザベーションは、特殊な要件

を必要とするため、マルチパス I/Oソリューションの最初の実装

では多くの場合要件が満たされません。

ディスクアレイサポートに関する以下の技術情報を参照し、

個別のアレイがマルチパスおよび特定のマルチパスソリューショ

ンでサポートされているかを判断してください。マルチパスおよび

特定のマルチパスソリューションと共に動作する LifeKeeperのサポート対象として一覧に指定されていないアレイは、サポー

ト対象ではないと考えてください。



項目説明

マルチパス構成での大量の I/O

マルチパス構成では、パスの操作中に大量の I/Oを実行する

と、システムが応答しなくなったように見えることがあります。マ

ルチパスのソフトウェアがLUNのアクセスをあるパスから別のパ

スに移動する場合、処理中の I/Oも新しいパスに移動させる

必要があります。この I/Oの経路変更は、その I/Oの応答時

間の遅延を発生させます。この間にさらに I/Oが発行される

と、それらはシステム内のキューとなり、システムはプロセス用の

メモリを使い果たしてしまう可能性があります。非常に高負荷

の I/Oの下では、これらの遅延と低メモリ状態によってシステム

が無応答になり、LifeKeeperがこれをサーバのダウンとして検

知し、フェイルオーバを開始することがあります。

この問題が発生する頻度には多くの要因が影響を及ぼしま

す。

l プロセッサの速度は、 I/Oがキューに保持される速さに

影響します。高速なプロセッサでは、障害が検知され

る頻度が高くなります。

l システムメモリの搭載量は、システムが無応答になるま

でにキューに保持できる I/Oの数に影響します。メモリ

が多いシステムでは、障害が検知される頻度が低くな

ります。

l 使用する LUNの数は、キューに保持できる I/Oの量

に影響します。

l I/Oの特性は、キューに保持される I/Oの量に影響し

ます。問題が発生したテストケースでは、ディスクにデー

タを無制限に書き込んでいました。ほとんどのアプリ

ケーションは、データの読み取りと書き込みの両方を行

うはずです。フェイルオーバを待って読み取りがブロックさ

れることで書き込みも抑制され、結果的に I/O速度が

減少して障害検知の頻度が低くなります。

例えば、RDACを使用した IBM DS4000のマルチパス構成

のテストでは、DS4000への I/Oスループットを毎秒 190MB以

上にしてパス障害をシミュレーションした場合に LifeKeeperは約 12回に 1回サーバの障害を (誤 )検出しました。このテスト

では、サーバとして IBM x345 (デュアルXeon 2.8GHzプロセッ

サとメモリ2GBを搭載 )を使用し、DS4400に接続して使用

サーバ当たり8ボリューム (LUN)にしました。フェイルオーバを

抑止するために、LifeKeeperのLCMNUMHBEATSパラメー

タ (/etc/default/LifeKeeper内 )は 16に増やしまし

た。このパラメータの変更により、無応答のシステムが生存し

ていないと判定するまでに LifeKeeperは、デフォルトの約 15秒ではなく、約 80秒間待機するようになります。

96 設定


項目説明

大規模ストレージ構成の場合のス

イッチオーバに関する特別な考慮事

項

いくつかの大規模ストレージ構成 (例えば、複数の論理ボリ

ュームグループがあり、各ボリュームグループ内に 10以上の

LUNを持つ構成 )では、LifeKeeperは障害を検出したときに

デフォルトの300秒のタイムアウト時間内に sendeventを完

了することができない場合があります。その結果、バックアップ

システムへのスイッチオーバが失敗します。サービス状態になら

ないリソースが生じ、LifeKeeperのログにエラーメッセージが記

録されます。

大規模ストレージ構成で

は、/etc/default/LifeKeeperファイルの

SCSIERRORを「event」から「halt」に変更することを推奨しま

す。これによりLifeKeeperは SCSIエラーの発生時に「halt」を実行します。LifeKeeperはバックアップシステムへのフェイルオー

バに成功するようになります。

HP MA8000QLogic 2200アダプタとの組み合わせで SIOS TechnologyCorp.により認定。qla2200 ドライバのバージョン 6.04.50以降

を使用してください。

HP MSA1000およびMSA1500

シングルパスおよびマルチパスの両構成において、HPFCA2214 (QLA 2340)アダプタとの組み合わせで SIOSTechnology Corp.により認定。マルチパス構成でMSA1000をサポートするための構成要件と注意事項は、HPのマルチ

パス I/Oの設定セクションで別途説明しています。

HP 3PAR F200/F400/T400/T800

HP 3PARは、SIOS Technology Corp.によってテスト済みで

す。テスト構成は次の通りです。HP 3PAR T400 (ファームウェ

ア (InForm OS)バージョン 2.3.1MU4) + HP 82Q 8GbDualPort PCI-e FC HBA AJ764A (ファームウェアバージョン

5.03.02、ドライババージョン 8.03.01.05.05.06-k) + DMMP(device-mapper-1.02.55-2.el5、device-mapper-multipath-0.4.7-42.el5)。

テストは、LifeKeeper for Linux v7.3とRHEL 5.6 (カーネル

2.6.18-238.el5)を使用して行われました。

HP 3PAR V400

HP 3PAR V400は、SIOS Technology Corp.によってテスト済

みです。テスト構成は次の通りです。HP 3PAR V400 (ファーム

ウェア (InForm OS)バージョン 3.1.1) + HP 82E 8GbDual PortPCI-e FC HBA AJ763A/AH403A (ファームウェアバージョン

1.11A5 (U3D1.11A5) sli-3、ドライババージョン 8.3.5.30.1p(RHELにバンドル) + DMMP (device-mapper-1.02.62-3、device-mapper-multipath-0.4.9-41.el6)。

テストは、LifeKeeper for Linux v7.5とRHEL 6.1を使用して

行われました。



項目説明

HP EVA 3000/5000およびEVA4X00/6X00/8X00(XCS 6.xシリーズファームウェア)

シングルパスおよびマルチパスの両構成において、HPFCA2214 (QLA 2340)アダプタとの組み合わせで SIOSTechnology Corp.により認定。マルチパス構成で EVAをサ

ポートするための構成要件と注意事項は、HPのマルチパス

I/Oの設定セクションで別途説明しています。

HP EVA4400

Hewlett-Packard社により認定。シングルパスとマルチパス構

成の両方で DMMP Recovery KitおよびHP DMMPソフトウ

ェアが必要です。EVA4400は、RedHat EL 5 Update 3および

Novell SLES 11とLifeKeeperの組み合わせで動作することが

検証済みです。Novellのテストは、HP StorageGroupによっ

て行われました。

HP EVA6400/8400



ェアが必要です。EVA6400/8400は、RedHat EL 5 Update 3およびNovell SLES 11とLifeKeeperの組み合わせで動作す

ることが検証済みです。Novellのテストは、HP StorageGroupによって行われました。

HP EVA 8100 (XCS 6.xシリーズフ

ァームウェア)

DMMPマルチパス構成において、HP FC 1142SRアダプタとの

組み合わせで SIOS Technology Corp.パートナーにより認

定。マルチパス構成で EVAをサポートするための構成要件と

注意事項は、DeviceMapper Multipath I/Oの設定セクション

で別途説明しています。

EVA 8100は、XCS v6.200ファームウェア+ device-mapper-multipath-0.4.7.-23.el5 + DMMP Recovery Kit v7.3 + RHEL5.3でテスト済みです。

HP MSA2000fc

シングルパスおよびマルチパスの両構成において、ファイバチャ

ネルとの組み合わせで Hewlett-Packard社により認定。テスト

されたモデルは、QLogic QMH2462 HBA (ドライババージョン

8.01.07.25)を使用したMSA2012fcおよびMSA2212fcのシ

ングルパス構成です。マルチパス構成のテストでは、同一モデ

ルとHP DMMPおよびLifeKeeper DMMP Recovery Kitが使

用されました。

HP MSA2000i

マルチパス構成において、 iSCSI との組み合わせで Hewlett-Packard社により認定。テストに使用されたモデル

は、MSA2012i (HP DMMP使用 )です。HPではシングルパス

構成のテストは行われていませんが、SIOS Technology Corp.は、HP DMMPおよびLifeKeeper DMMP Recovery Kitを組

み合わせたシングルパス構成をサポートします。

98 設定


項目説明

HP MSA2000sa

シングルパスおよびマルチパスの両構成において、SA との組み

合わせで Hewlett-Packard社により認定。テストに使用され

たモデルは、MSA2012saです。シングルパスとマルチパス構成

の両方で DMMP Recovery KitおよびHP DMMPソフトウェア

が必要です。現在、HPによるサポートは直接接続構成のみ

です。

HP MSA 2300fc

シングルパスおよびマルチパスの両構成において、ファイバチャ

ネルとの組み合わせで Hewlett-Packard社により認定。テスト

に使用されたモデルは、HP AE312A (FC2142SR) HBA (ドラ

イババージョン 8.02.09-d0-rhel4.7-04)を使用したMSA2324fcのシングルパス構成です。マルチパス構成のテストでは、同一

モデルとHP DMMPおよびLifeKeeper DMMP Recovery Kitが使用されました。

HP MSA 2300iHewlett-Packard社により認定。シングルパスとマルチパス構


ェアが必要です。

HP MSA 2300sa



ェアが必要です。DMMPを使用するMSA2300saラックおよび

タワー型構成のみサポートされます。LifeKeeperを使用するブ

レード構成はサポートされていません。

HP P2000G3MSA SAS

DeviceMapper Multipath Recovery Kitを使用するマルチパス

構成において、SIOS Technology Corp.により認

定。LifeKeeper for Linuxは、P2000G3 SASアレイを使用す

る単一クラスタで最大 11 LUNをサポートします。

HP P4000/P4300G2

RHEL 5.5 + LifeKeeper Coreに内蔵のSCSIサポート +iSCSI Software Initiators環境のシングルパスおよびマルチパ

スの両構成において、SIOS Technology Corp.により認定。

テストに使用されたモデルは、HP P4300G2 7.2TB SASStarter SAN BK716Aです。デフォルトキットは、シングルパスお

よび一部のマルチパスストレージをサポートします。一般的に、

マルチパスストレージは、アクティブ /パッシブ構成に限定されま

す。

HP P4500G2 Hewlett-Packard社により認定。HPでは、P4500について

P4000 (上記参照 )との互換性を保証しています。

HP P6300 EVA FCDeviceMapper Multipath Recovery Kitを使用するRHEL6.1のマルチパス構成において、SIOS Technology Corp.パー

トナーによりテスト済み。



項目説明

HP P9500/XP

SteelEye LifeKeeper for Linux v7.2以降を使用する場合に

ついて、Hewlett-Packard社により認定。テストに使用された

モデルはHP P9500/XPです。以下の環境のLifeKeeperで動作することが認定されています。

l RedHat Enterprise (32 bit、x64 (64 bit; Opteronおよ

び Intel EMT64))

RHEL 5.3、RHEL 5.4、RHEL 5.5

l SuSE Enterprise Server (32 bit、x64 (64 bit; Opteronおよび Intel EMT64))

SLES 10 SP3、SLES 11、SLES 11 SP1

l ネイティブまたは内蔵のクラスタリングソリューション:RHCSおよびSLE HA

HP XP20000/XP24000

RHEL 5、SLES10、SLES 11上で LifeKeeper for Linux +DMMP ARKを使用するマルチパス構成 (DMMP使用 )にお

いて、SIOS Technology Corp.により認定。テストに使用され

たストレージのモデル番号は、XP20000およびXP24000です。接続インターフェースは FCです。テストに使用された

HBAのモデル番号は、QLogic QMH2562 (ファームウェア

4.04.09、ドライババージョン 8.03.00.10.05.04-k)です。SIOSTechnology Corp.では、XPストレージのpath_checkerの設

定を readsector0に変更することを推奨します。

IBM DS4000 Storage (旧 IBMFAStT)

シングルパスおよびマルチパスの両構成において、QLogic2200および2340アダプタとの組み合わせで SIOSTechnology Corp.により認定。qla2200または qla2300ドライ

バのバージョン 6.03.00以降を使用してください (IBMより指

定 )。 IBM DS4000ストレージアレイシステムで Emulex FCアダ

プタを使用する場合は、下記の「Emulex Drivers」項目で指

定の lpfc ドライバを使用してください。シングルパス (=シングル

ループ)サポート :シングルパス構成では、LifeKeeperが正常

に動作するにはファイバチャネルスイッチまたはハブが必要で

す。マルチパス (=デュアルループ)サポート :マルチパス

は、RDACサポート付きでリリースされたモデル (現在のとこ

ろ、DS4300、DS4400、DS4500モデル)でサポートされていま

す。RDACを使用したマルチパス構成では、ファイバチャネル

スイッチおよびハブは必須ではありません。RDACは、アプリ

ケーションがパスの障害に影響されないように、パスのフェイル

オーバを処理するソフトウェアパッケージです。RDACをインス

トールおよび設定する手順は、使用するバージョンによって若

干異なります。インストール、ビルド、設定の手順について

は、RDACに関する IBMのドキュメンテーションを参照してくだ

さい。

100 設定


項目説明

IBM DS5000

IBM RDACを使用するマルチパス構成において、パートナー

テストにより認定。お使いのディストリビューションでサポートさ

れているRDAC ドライバについては、 IBMのWebサイトを参

照してください。

IBM DS3500(FCモデル)

Red Hat Enterprise Linux Server Release 5.5 (Tikanga)環境

のシングルパスおよびマルチパスの両構成において、SIOSTechnology Corp.により認定 (HBA:QLE2560、QLE2460、RDAC: RDAC 09.03.0C05.0331)。シ

ングルパスおよびマルチパスの両構成で RDACが必要です。

注記 :SASおよび iSCSI接続はサポートされていません。

IBM DS3400 Storage

シングルパスおよびマルチパスの両構成において、QLogic2300アダプタとの組み合わせで SIOS Technology Corp.によ

り認定。qla2200 または qla2300ドライバのバージョン 6.03.00以降を使用してください (IBMより指定 )。シングルパスおよび

マルチパスのサポートに関する詳細については、表内の「IBMDS4000 Storage」エントリを参照してください。

IBM System Storage DS3300

iSCSI Software Initiators との組み合わせで SIOSTechnology Corp.により認定。このストレージデバイスは、シン

グルパスおよびマルチパスの両構成において、2ノードの

LifeKeeperクラスタで動作します。シングルパスまたはマルチパ

スのいずれの場合も、両方のサーバに IBM RDAC ドライバを

インストールする必要があります。マルチパス構成を使用する

場合は、 /etc/default/LifeKeeperファイルで SCSIHANGMAXを 50に設定する必要があります。お使いのディストリビューショ

ンでサポートされているRDAC ドライバについては、 IBMの

Webサイトを参照してください。

IBM System Storage DS3200

IBM SAS HBA (25R8060)との組み合わせで SIOSTechnology Corp.により認定。このストレージデバイスは、シン

グルパスおよびマルチパスの両構成において、2ノードの

LifeKeeperクラスタで動作します。シングルパスまたはマルチパ

スのいずれの場合も、両方のサーバに IBM RDAC ドライバを

インストールする必要があります。お使いのディストリビューショ

ンでサポートされているSASおよびRDAC ドライバについて

は、 IBMのWebサイトを参照してください。

IBM DS400シングルパス構成の場合のみ、SIOS Technology Corp.によ

り認定。ファームウェアバージョン 7.01ビルド 0838以降を使用

してください (IBMより指定 )。

IBM San VolumeController (SVC)

シングルパス構成において、パートナーテストにより認

定。SDD Recovery KitおよびDeviceMapper MultipathRecovery Kitを使用するマルチパス構成において、SIOSTechnology Corp.により認定。



項目説明

IBM eServer xSeriesストレージソリ

ューションサーバType445-R /Type445-FR for SANmelody

マルチパス構成において、 IBM TotalStorage FC2-133ホスト

バスアダプタとの組み合わせでパートナーテストにより認

定。qla2200 ドライバのバージョン 7.00.61 (フェイルオーバなし)以降を使用してください (IBMより指定 )。マルチパスサポート :マルチパスは、Multipath Linux Driver for IBM SANmelodySolution Server (バージョン 1.0.0)を使用する IBM eServerxSeriesストレージソリューションサーバType445-R / Type445-FR for SANmelodyでサポートされています。

IBM Storwize V7000 (ファームウェア

バージョン 6.3.0.1)

SIOS Technology Corp.は、 iSCSI (iscsi-initiator-utils-6.2.0.872-34.el6.x86_64)とDMMP (device-mapper-1.02.66-6.el6、device-mapper-multipath-0.4.9-46.el6)を使用する

IBM Storwize V7000 (Firmware Version 6.3.0.1)を認定して

います。テストは、LifeKeeper for Linux v7.5とRHEL 6.2を使

用して行われました。

制限事項 : IBM Storwize V7000は、Quorum/WitnessServer KitおよびSTONITH と組み合わせて使用する必要が

あります。 /etc/default/LifeKeeper内で以下の設定によ

り、SCSI リザベーションを無効にしてください。

RESERVATIONS=none

102 設定


項目説明

Dell PERCおよびLSI LogicMegaRAID コントローラを搭載する

Dell PowerVault

SIOS Technology Corp.は、以下の構成要件を満たす場合

の、Dell PERC 2/DC、Dell PERC 4/DC、およびLSI LogicMegaRAID Elite 1600ストレージコントローラを使用する 2ノードクラスタでのDell PowerVaultストレージアレイを認定してい

ます。(Dell PERC 3/DCは、MegaRAID Elite 1600のOEMバージョンです。)以下の要件が必要となるのは、これらのホス

トベースのRAID コントローラが、LifeKeeperの通常の要件で

あるSCSI リザベーションと一意のデバイス IDをサポートしてい

ないためです。

1. Dell PowerVaultストレージは、同一クラスタ内の

LifeKeeperの管理下では他のタイプの共有ストレージ

と共存できません。

2. Dell PowerVaultストレージおよびコントローラをクラスタ

で使用するための設定方法については、ハードウェア

に付属のマニュアルに従ってください。具体的には、両

方のシステムで同時にコントローラファームウェアの設定

画面を開き、アダプタプロパティページを選

択、「Cluster Mode]」を「Enabled」に設定、「InitiatorID」を一方のシステムでは「6」に、他方のシステムで

は「7」に設定することなどが含まれます。その後、両方

のコントローラから同じ LUNが見えるこ

と、Linuxmegaraidドライバが正常にロードされているこ

とを確認します。

3. 以上のストレージ設定は SCSI リザベーションをサポー

トしないため、LifeKeeper内で SCSI リザベーションの

使用を無効にする必要があります。無効にするには、

クラスタの両ノードで、LifeKeeperのデフォルトファイル

/etc/default/LifeKeeperに「RESERVATIONS=none」を追加します。LifeKeeperによって管理される各 LUNの一意の IDは、 /opt/LifeKeeper/bin/lkIDユーティリテ

ィを使用して手動で設定する必要があります。割り当

てる IDはクラスタ内で一意にしてください。また、将来

競合が発生しないように割り当て方法を工夫してくだ

さい。 lkIDユーティリティは、一意の IDを自動的に生

成することもできます。 lkIDユーティリティの使用方法、

生成する ID、 IDが置かれる場所、制限事項などの

詳細については、 lkID(8) ヘルプページを参照してくださ

い。LVMで lkIDを使用する際の注意については、

の「既知の問題」セクションを参照してください。

4. I/Oフェンシングを提供するSTONITHデバイスを用意

して設定します。これは、上記の構成で SCSI リザベーションのサポートがないために必要です。この設定

では、STONITHデバイスが「再起動」コマンドではな

く、「電源切断」コマンドをシステムに対して実行するよ

うにします。さらに、LifeKeeperの通信が何らかの理由

で中断したとき、手動操作によって同時に両ノード上

のデバイス階層をサービス中の状態にしないように注

意してください。



項目説明

Dell | EMC (CLARiiON) CX200

EMCは、このアレイとQLA2340アダプタの環境用に次の2つのバージョンのドライバを認定しています: qla2x00-clariion-v6.03.00-1およびqla2x00-clariion-v4.47.18-1。両バージョンと

も QLogicのWebサイト (www.qlogic.com)で入手できます。

DELLMD3000

シングルパスおよびマルチパスの両構成において、DELL SAS5/eとの組み合わせでパートナーテストにより認定。テストは

RHEL4で行われましたが、LifeKeeperがサポートする他の

Linuxディストリビューションまたはバージョンを使用する場合の

既知の問題はありません。シングルパスおよびマルチパスの両

構成で RDACが必要です。シングルパス構成では、HBAホ

ストタイプに「Windows MSCS Cluster single path」を使用し

てください。マルチパス構成では、HBAホストタイプに「Linux 」を使用してください。

Dell PowerVault MD3200/3220

Dell PowerVault MD3200/3220は、SIOS Technology Corp.パートナーによってテスト済みです。テスト構成は次の通りで

す。

RHEL 5.5で DMMP とDMMP RecoveryKit。Quorum/Witness Server KitおよびSTONITH と組み合

わせて使用する必要があります。「/etc/default/LifeKeeper 」内にRESERVATIONS=noneを設定して SCSI リザベーショ

ンを無効にします。サーバには IPMI 2.0に準拠のインターフ

ェースが必須です。

Dell EqualLogic PS5000

Dell EqualLogicは、SIOS Technology Corp.パートナーによっ

てテスト済みです。テスト構成は次の通りです。

l Dell EqualLogic PS5000 + iscsi-initiator (Softwareイニシエータ)によるSCSI -2リザベーション + RedHatEnterprise Linux ES release 4 (Nahant Update 5、カー

ネル2.6.9-55.EL)。テストには、 iscsi-initiator-utils-4.0.3.0-5、マルチパス構成、active-backup (mode=1)による bondingが使用されました。

l Dell EqualLogic PS5000 + DMMP + DMMPRecovery Kit + RHEL 5 + iscsi-initiator-utils-6.2.0.865-0.8.el5。LUN数が大きい場合 (20以上 )は、 /etc/default/LifeKeeperのREMOTETIMEOUT設

定をREMOTETIMEOUT=600に変更してください。

104 設定

http://www.qlogic.com/


項目説明

Dell EqualLogicPS4000/4100/4110/6000/6010/6100/6110/6500/6510

Dell EqualLogicは、SIOS Technology Corp.パートナーによっ

てテスト済みです。テスト構成は次の通りです。DellEqualLogicPS4000/4100/4110/6000/6010/6100/6110/6500/6510 +DMMP + DMMP Recovery Kit + RHEL 5.3 + iscsi-initiator-utils-6.2.0.868-0.18.el5。LUN数が大きい場合 (20以上 )は、 /etc/default/LifeKeeperのREMOTETIMEOUT設定を

REMOTETIMEOUT=600に変更してください。

FalconStor Network Storage Server(NSS)

SIOS Technology Corp.により認

定。/etc/multipath.confに以下のパラメータを設定す

る必要があります。

polling_interval 5

no_path_retry 36

日立 HDS RAID 700 (VSP)

RAID 700 (VSP)は SIOS Technology Corp.パートナーによっ

てシングルパス構成にてテスト済みです。テスト構成は次の通

りです。 : OS: Red Hat Enterprise Linux Server Release 5.5(Tikanga) HBA: Qlogic QLE2562 (ドライバ:OS同梱

の8.03.01.04.05.05-k) / Emulex LPe12002 (ドライバ:OS同梱

の8.2.0.63.3p).注記 :マルチパス構成はまだ認定されていま

せん。



項目説明

日立 HDS 9570V、9970V、9980V

QLogic 23xxアダプタを使用するシングルパス構成におい

て、SIOS Technology Corp.により認定。qla2200 ドライバの

バージョン 6.04以降を使用してください。

注記 : これらのアレイでは、ファイバチャネルスイッチまたはハブ

を使用して、シングルコントローラ (シングルループ)のみの構成

にすることをSIOS Technology Corp.は推奨します。ただし、

各サーバのストレージへのパスが単一である限り、スイッチやハ

ブを使用することなく各サーバが日立アレイの個別のコント

ローラまたはポートに直接接続する LifeKeeperクラスタを構

成することもできます。この構成を使用する場合、LifeKeeperはスプリットブレインの状況で通常の動作とは非常に異なる

動作をすることに注意してください。通常、LifeKeeperは、ス

プリットブレインの状況でアクティブな階層のフェイルオーバを実

行し、元のプライマリノードは SCSI リザベーションを奪われた

結果としてリブートを行います。サーバを直接複数のコント

ローラまたはポートに接続する構成の日立アレイの場合、アレ

イ内の特定のタイミングに特殊性があるため、LifeKeeperはバックアップノード上で SCSI リザベーションを獲得することがで

きずにフェイルオーバに失敗します。これにより、階層の少なく

とも一部が元のプライマリノードで稼働し続けます。このため、

このような構成にあるすべてのLifeKeeperリソースがディスクリ

ソースの1つに対して直接の従属関係を持ち、ディスクリソー

スの移行ができない場合にリソースをサービス中の状態にでき

ないようにすることが重要です。このことは、階層内の IP リソー

スについて特に重要です。

日立 HDS 9980V

日立アレイには、このアレイのような直接接続の構成で

LifeKeeperを正常に動作させるために必要なある特定の「ホ

ストモード」があります。9570Vアレイの場合は以下の設定が

必要です。

ホスト接続モード 1 --> Standardmode ホスト接続モード 2 --> Target Reset mode (Bus DeviceReset)

Third Party Process Logout Spreadmode LIPポート全リセットモード --> LIP port all reset mode

9970Vおよび9980Vアレイについては、「ホストモード "」を「SUN」に設定する必要があります。HDS 9980Vは、SLES9 SP3、LSI Logic Fusion HBA、DMMPを使用する

マルチパス構成において、SIOS Technology Corp.パートナー

企業によりテスト済みです。詳細については、DeviceMapperMultipath I/Oの設定セクションを参照してください。

106 設定


項目説明

nStor NexStor 4320F

このストレージは、2ノードクラスタの各サーバがアレイ内の

別々のコントローラに直接接続するデュアルコントローラ構成

において、SIOS Technology Corp.パートナー企業によりテス

ト済みです。この構成では、スプリットブレインの状況で

LifeKeeperは日立 HDSストレージアレイについて説明した

動作と同じように動作するため、階層構成上の同じ注意事

項が当てはまります。

ADTX ArrayMasStor L and FC-II

このストレージユニットは、スイッチを使用するシングルパス構

成、および2ノードクラスタの各サーバがアレイ内の別々のコン

トローラに直接接続するデュアルコントローラ構成におい

て、SIOS Technology Corp.パートナーによりテスト済みです。

両方の構成において、スプリットブレインの状況で LifeKeeperは日立 HDSストレージアレイについて説明した動作と同じよ

うに動作するため、階層構成上の同じ注意事項が当てはま

ります。ArrayMasStor Lは、QLogic 2340および2310ホストア

ダプタ、QLogic フェイルオーバドライバ (バージョン 6.06.10)を使

用するマルチパス構成においても、SIOS Technology Corp.パートナーによってテストおよび認定済みです。

富士通 ETERNUS3000

このストレージユニットは、PG-FC105 (Emulex LP9001)、PG-FC106 (Emulex LP9802)、PG-PC107ホストバスアダプ

タ、 lpfc ドライバv7.1.14-3を使用するシングルパス構成におい

て、SIOS Technology Corp.パートナー企業によりテスト済み

です。

富士通 ETERNUS 6000

このストレージユニットは、PG-FC106 (Emulex LP9802)ホスト

バスアダプタ、 lpfc ドライバv7.1.14-3を使用するシングルパス

構成において、SIOS Technology Corp.パートナーによりテス

ト済みです。

富士通 FibreCAT S80

このアレイでは、/etc/default/LifeKeeperに次のエン

トリを追加する必要があります。

ADD_LUN_TO_DEVICE_ID=TRUE

富士通 ETERNUS SX300

このストレージユニットは、PG-FC106 (Emulex LP9802)および

PG-FC107ホストバスアダプタ、 lpfc ドライバv7.1.14を使用す

るマルチパス構成において、SIOS Technology Corp.パート

ナー企業によりテスト済みです。SX300に同梱のRDAC ドラ

イバが必要です。

富士通 ETERNUS2000Model 50

このストレージユニットは、PG-FC202 (LPe1150-F)ホストバス

アダプタ、EMPDマルチパスドライバを使用するデュアルRAIDコントローラによるマルチパス構成において、SIOS TechnologyCorp.パートナー企業によりテスト済みです。テストでは、ファー

ムウェアバージョンWS2.50A6およびドライババージョンEMPDV2.0L12が使用されました。テストは、LifeKeeper for Linuxv6.2とRHEL4 (カーネル2.6.9-67.ELsmp)およびRHEL5 (カーネル2.6.18-53.el5)を使用して行われました。



項目説明


このストレージユニットは、PG-FC202 (LPe1150-F)ホストバス

アダプタ、EMPDマルチパスドライバを使用するデュアルRAIDコントローラによるマルチパス構成において、SIOS TechnologyCorp.パートナー企業によりテスト済みです。


このストレージユニットは、PG-FC203L (Emulex LPe1250-F8)ホストバスアダプタ (ファームウェアバージョン 1.11A5、ドライバ

バージョン 8.2.0.48.2p)、EMPDマルチパスドライバ (ドライバ

バージョンV2.0L20、パッチバージョン T000973LP-1)を使用す

るマルチパス構成において、Fujitsu Limitedによりテスト済み

です。

テストは、LifeKeeper for Linux v7.1とRHEL 5 (カーネル

2.6.18-164.el5)を使用して行われました。

富士通

ETERNUS VS850

DeviceMapper Multipath Recovery Kitを使用するシングルパ

ス構成およびマルチパス構成において、ベンダサポートステート

メントにより認定。

108 設定


項目説明

NEC iStorage Storage Path SaviorMultipath I/O

マルチパスデバイスを使用するアプリケーションとファイルシステ

ムの保護 : SPSデバイスを使用するアプリケーションやファイル

システムを LifeKeeperによって設定し保護するには、SPSRecovery Kitをインストールする必要があります。

SPS Kitのインストール後は、1つ以上のマルチパスデバイス

ノードを使用するアプリケーション階層を作成するだけ

で、SPS Kitが提供する新しいリソースタイプが自動的に組み

込まれます。

マルチパスデバイスノード : SPS Kitを使用するには、すべての

ファイルシステムおよびRAWデバイスをネイティブの /dev/sd*デバイスノードではなく、マルチパスデバイスノード (/dev/dd*)上にマウントまたは設定する必要があります。

SCSI-3 Persistent Reservationsの使用 : SPS Kitは、リザ

ベーションタイプを「書き込み専用」とするSCSI-3 PersistentReservationsを使用します。この場合、クラスタの1ノードが

予約したデバイスは、クラスタの他のノードから読み取り可能

のままですが、デバイスへの書き込みはできなくなります。このこ

とは、それらの他のノード上で進行中の読み取り専用アクセ

スのためにファイルシステムをマウントできるという意味ではない

ことに注意してください。

LifeKeeperでは、sg_persistユーティリティを使用してパーシス

テントリザベーションを発行、監視します。必要であれ

ば、LifeKeeperは sg_persist(8)ユーティリティをインストールし

ます。

ハードウェア要件 : SPS Kitは、EmulexLP952、LP9802、LP1050、LP1150 HBAおよびEmulex lpfcドライバを使用するNEC iStorageディスクアレイにおいて、テ

ストおよび認定済みです。SPS Kitは、SPSがサポートする他

のNEC iStorage DおよびSでも同様に問題なく動作すると

考えられます。

マルチパスソフトウェアの要件 : SPS Kitは、SPS for Linux3.3.001を使用してテスト済みです。インストールされている

SPSパッケージに対する既知の依存関係はありません。

インストール要件 : SPS Recovery Kitをインストールする前に

SPSソフトウェアをインストールする必要があります。

SPS パスの追加または修復 : LifeKeeperは、SPS リソースを

起動する場合、パーシステントリザベーションを確立してその

時点でアクティブなパスに登録します。最初のリザベーションの

後に新しいパスが追加されるか、障害が起きたパスが修復さ

れて SPSがそのパスを自動的に再度アクティブにした場合、

そのパスは、LifeKeeperがSPS リソースに対する次の

quickCheckを実行するまでリザベーションの一部として登録

されません。その時点までにSPSがそのパスに対する書き込

みを許可した場合、リザベーション競合が発生し、システムの

メッセージファイルに競合が記録されます。SPS ドライバは、

登録されたパスでそれらの I/Oを再試行するため、アプリケー

ションにとっては検出可能な障害になりません。quickCheckによるパスの登録が完了すると、その後の書き込みは成功し

ます。



項目説明

Newtech SweeperStor SATAおよび

SAS

このストレージユニットは、QLogic PCI to Fibre Channel HostAdapter for QLE2462 (ファームウェアバージョン 4.03.01 [IP]、ド

ライババージョン 8.02.08)、ストレージファームウェア J200を使

用するデュアルRAID コントローラによるマルチパス構成におい

て、SIOS Technology Corp.パートナー企業によりテスト済み

です。テストは、LifeKeeper for Linux v6.2、DMMP RecoveryKit v6.2、および以下のディストリビューションとカーネルを使用

して行われました。

RHEL4DMMP

Emulex LP 11002 8.0.16.32以降

Emulex LPe 11002 8.0.16.32以降

Qlogic QLA 2462 8.01.07以降

Qlogic QLE 2462 8.01.07以降

RHEL5DMMP

Emulex LP 11002 8.1.10.9以降

Emulex LPe 11002 8.1.10.9以降

Qlogic QLA 2462 8.01.07.15以降

Qlogic QLE 2462 8.01.07.15以降

SLES10DMMP

Emulex LP 11002 8.1.10.9以降 Emulex LPe 11002 8.1.10.9以降 Qlogic QLA 2462 8.01.07.15以降 Qlogic QLE 2462 8.01.07.15以降

注記 :マルチパス構成ではDMMPが必要です。

TID MassCareRAID

このストレージは、SIOS Technology Corp.パートナーによって

テスト済みです。テストのシングルパス構成は次の通りです。

l ホスト 1QlogicQLE2562 (HBABIOS2.10、ドライババージョン

qla2xxx-8.03.01.04.05.05-k *)

l ホスト 2HPAE312A (HBABIOS1.26、ドライババージョンqla2xxx-8.03.01.04.05.05-k *)

l テストは、LifeKeeper for Linuxv7.3とRedHat Enterprise Linux5.5(カーネル2.6.18-194.el5)を使用して行われました。

LifeKeeper for Linuxは、TID MassCareRAID アレイを使用する単

一クラスタで最大 11 LUN をサポートします。

110 設定


項目説明

TIDMassCareRAIDⅡ

このストレージユニットは、Qlogic ドライバとSCSI-2リザベーシ

ョンを使用し、ファイバチャネルスイッチを使用しないマルチパス

構成において、SIOS Technology Corp.パートナー企業によ

りテスト済みです。RedHat Enterprise Linux ES release 4Update6 (カーネル2.6.9-67.ELsmp)が使用されまし

た。 /etc/default/LifeKeeperのFAILFASTTIMER設定を 5から 30に変更する必要があります。

Sun StorageTek 2540

このストレージユニットは、StorageTek 4Gb PCI-E Dual FCホ

ストバスアダプタおよびSun StorageTek 4Gb PCI Dual FCネッ

トワークアダプタを使用するRDAC +デュアルRAID コントロー

ラによるマルチパス構成において、SIOS Technology Corp.パートナー企業によりテスト済みです。

QLogic ドライバ

QLogicアダプタを使用するサポート対象の他のファイバチャネ

ルアレイについては、qla2200 または qla2300ドライバのバージ

ョン 6.03.00以降を使用してください。

Emulex ドライバサポート対象のEmulex HBAについては、 lpfc ドライバ

v8.0.16以降を使用してください。

Adaptec 29xx ドライバ

Adaptec 29xxを使用するサポート対象のSCSIアレイについ

ては、OSディストリビューションに付属のaic7xxx ドライババー

ジョン 6.2.0以降を使用してください。

DataCore SANsymphony

このストレージデバイスは、SUSE SLES 9 Service Pack3、DeviceMapper Multipath、およびQlogic 2340アダプタを

使用してテスト済みです。他のバージョン、ディストリビューショ

ン、アダプタを組み合わせても動作すると考えられますが、テス

トは実施されていません。この構成および他の構成について

の具体的なサポートについては、DataCoreにお問い合わせく

ださい。

高負荷でのフェイルオーバのテストで 1つの問題が見つかって

います。複数のサーバがリブートした場合に、サーバがシングル

パスのみを構成する状態になります。テストは 3ノードクラスタ

で構成され、2台のサーバが同時に切断されました。2台の

サーバがリブートした後、約半分の時間、1台のサーバがシン

グルパスのみを持つ状態になりました。この問題は、そのサー

バをリブートすれば解決します。サーバを 1台だけリブートした

ときは、この問題は見られませんでした。この問題は

DataCoreに報告済みです。最低 1つのパスが継続的に利

用できるため、この問題は深刻な問題とはみなされていませ

ん。


HPのマルチパス I/O設定

項目説明

XiotechMagnitude 3D

このストレージデバイスは、ed Hat EL 4 Update 3およびQlogic2340アダプタを使用してテスト済みです。他のバージョン、ディ

ストリビューション、アダプタを組み合わせても LifeKeeperは動

作すると考えられますが、テストは実施されていません。この構

成および他の構成についての具体的なサポートについて

は、Xiotechにお問い合わせください。

Magnitude 3Dは、シングルパス構成でテストが行われました。

セットアップ中に、OSで 8 LUN しか構成できないという構成

上の問題が1つ検出されました。これは、Magnitude 3Dが

SCSI問い合わせデータの中で、自身をSCSI-2デバイスに指

定しているためです。2.6カーネルのSCSI ドライバは、デバイ

スが例外リストに含まれていない限り、8を超える LUNを

SCSI-2デバイス上で自動で認識しません。Magnitude 3Dは

そのリストに入っていません。 /proc/scsi/scsiにコマンドを発行

して各 LUNを構成するという対応策がXiotechからテスト用

に提供されました。

HPのマルチパス I/O 設定

項目説明

Secure Pathを使用

する場合の

MSA1000および

MSA1500のマルチ

パス要件

LifeKeeperは、MSA1000およびMSA1500を使用するマルチパス I/O構成

で Secure Pathをサポートします。このサポートの要件として、Secure Pathv3.0C以降を使用する必要があります。

HP P2000 LifeKeeperは、HP P2000MSA FCの使用をサポートします。このストレージ

ユニットは、RHEL 5.4上のマルチパス構成において、SIOS TechnologyCorp.によってテスト済みです。


する場合の

EVA3000および

EVA5000のマルチパ

ス要件

Secure Pathを使用するマルチパス I/O構成で EVA3000およびEVA5000をLifeKeeperがサポートするには、次の要件があります。

1. EVA VCS v2.003または v3.00以降各サーバで Command Viewv3.00を使用して [Host OS type]を [Custom]に、 [CustomModeNumber]を [hex000000002200282E]に設定してください。詳細な手

順については、HP Secure Pathリリースノートを参照してください。

2. HP Secure Path v3.0C以降

112 設定



するマルチパスクラス

タのインストール

Secure Pathを使用するマルチパスクラスタを新規にインストール場合は、次

の手順を実行します。

1. 選択したOSを各サーバにインストールします。

2. 次のクラスタハードウェアをインストールします。FCA2214アダプタ、スト

レージ、スイッチ、およびケーブル。

3. HP Platform Kitをインストールします。

4. HP Secure Pathソフトウェアをインストールします。ここでシステムをリ

ブートする必要があります。Secure Pathからストレージへのパスを適切

に設定したことを確認します。詳細については、Secure Pathのドキュ

メンテーションを参照してください。

5. LifeKeeperをインストールします。

QLogic FailoverDriverを使用する

MSA1000および

MSA1500のマルチ

パスサポート

LifeKeeper for Linuxは、MSA1000およびMSA1500を使用するマルチパス

I/O構成でQLogic Failover Driverをサポートします。このサポートの要件とし

て、QLogic ドライバv7.00.03以降を使用する必要があります。

QLogic FailoverDriverを使用する

EVAのマルチパスサ

ポート

LifeKeeperは、EVA 3000/5000およびEVA 4X00/6X00/8X00でQLogicFailover Driverをサポートします。3000/5000ではファームウェアバージョン

4000以上が必要です。4000/6000/8000ではファームウェアバージョン 5030以上が必要です。HPが提供するQLogic ドライバの最新版 (v8.01.03以降 )を使用する必要があります。ホスト接続は「Linux 」にしてください。パス /モード設定に LifeKeeperからの制限はありません。特殊なホスト接続、パス /モードの推奨設定、および使用可能な EVAのポートなどの以前の制限

は、このバージョンのファームウェアとドライバには存在しないことに注意してくだ

さい。



MSA1000/MSA1500または EVAのシング

ルパス構成から


するマルチパス構成

へのアップグレード

シングルパスからマルチパスにクラスタをアップグレードするには、次の手順を実

行します (アップグレードはクラスタ全体で行う必要があります)。

1. 通常のアップグレード手順に従って、LifeKeeperを最新バージョンにア

ップグレードします。この手順をローリングアップグレードで行うと、クラス

タ全体の停止を回避できます。

2. すべてのノードで LifeKeeperを停止します。ハードウェアのアップグレー

ドが完了し、すべてのノードでステップ 5が完了するまでクラスタはダウ

ンした状態です。

3. 各ノードで HP Platform Kitをインストール /アップグレードします。

4. 各ノードにHP Secure Pathソフトウェアをインストールします。ここでシ

ステムをリブートする必要があります。Secure Pathからストレージへの

パスを適切に設定したことを確認します。詳細については、SecurePathのドキュメンテーションを参照してください。

5. LifeKeeperを起動します。すべての階層がアップグレード前と同様に

動作するはずです。

注記 : これは、LifeKeeperの以前のバージョンがサポートしていたアップグレー

ド方法から変更された点です。

Secure Pathによる

永続的デバイスノー

ド

Secure Pathは、 /dev/spdev/spXX (XXはデバイス名 )の形式の「永続的

な」デバイスノードをサポートします。これらのノードは、特定のSCSIデバイス

ノード /dev/sdXXへのシンボリックリンクです。LifeKeeperはこれらのノードを「

通常の」SCSIデバイスノード /dev/sdXXであるかのように認識しま

す。LifeKeeperは、デバイスが /dev/sda1か /dev/sdq1かを直接検出し、その

後正しいデバイスノードを直接使用することにより、リブートおよびクラスタノー

ドをまたがってデバイス名の永続性を独自に維持しています。

注記 : SCSIデバイスノードへのシンボリックリンクのサポートは、LifeKeeperv4.3.0で追加されました。

アクティブ /パッシブコ

ントローラおよびコン

トローラスイッチオー

バ

MSA1000では、一方のコントローラをアクティブに、他方のコントローラをスタ

ンバイモードにすることによってマルチパスを実装しています。アクティブなコント

ローラまたはアクティブなコントローラへのパスのいずれかに問題が起きた場

合、スタンバイコントローラがアクティブ化されて処理を引き継ぎます。コント

ローラをアクティブにする場合、コントローラの準備ができるまでにある程度の

時間がかかります。アレイ上で設定されている LUNの数に応じて、30～ 90秒の時間を必要とします。この間、ストレージへの I/Oは、新しくアクティブに

なるコントローラに経路変更できるようになるまでブロックされます。

起動時にシングルパ

スでも通知が発生し

ない

システムがロードされたときに、サーバがシングルパスでしかストレージにアクセス

できない場合でも、この問題に関する通知が発生しません。この問題は、シ

ステムがリブートしたときに上記のような物理的なパスの障害が起きると発生

しますが、一時的なパス障害でも発生しています。システムをロードするとき

は、管理者はストレージへのすべてのパスが正しく構成されたことを必ず確認

し、構成されていない場合は、ハードウェアの問題を修復するか、システムを

リロードして一時的な問題を解決するかいずれかのアクションを取ることを推

奨します。

114 設定

EMC PowerPathのマルチパス I/O設定

EMC PowerPathのマルチパス I/O 設定

マルチパスデ

バイスを使用

するアプリ

ケーションとフ

ァイルシステ

ムの保護

EMC PowerPathデバイスを使用するアプリケーションやファイルシステムを LifeKeeperによって設定し保護するには、PowerPath Recovery Kitをインストールする必要があ

ります。PowerPath Kitのインストール後は、1つ以上のマルチパスデバイスノードを使

用するアプリケーション階層を作成するだけで、PowerPath Kitが提供する新しいリ

ソースタイプが自動的に組み込まれます。

マルチパスデ

バイスノード

PowerPath Kitを使用するには、すべてのファイルシステムおよびRAWデバイスをネイ

ティブの /dev/sd*デバイスノードではなく、マルチパスデバイスノード (/dev/emcpower*)上にマウントまたは設定する必要があります。

SCSI-3PersistentReservationsの使用

PowerPath Kitは、リザベーションタイプを「書き込み専用」とするSCSI-3 PersistentReservationsを使用します。この場合、クラスタの1ノードが予約したデバイスは、ク

ラスタの他のノードから読み取り可能のままですが、デバイスへの書き込みはできなく

なります。このことは、それらの他のノード上で進行中の読み取り専用アクセスのため

にファイルシステムをマウントできるという意味ではないことに注意してください。

LifeKeeperでは、sg_persistユーティリティを使用してパーシステントリザベーションを

発行、監視します。必要であれば、LifeKeeperは sg_persist(8)ユーティリティをイン

ストールします。

EMC Symmetrix (VMAXを含む)アレイをマルチパスソフトウェアおよびLifeKeeperと組み合わせて使用する場合は、SCSI-3 Persistent Reservationsを LUN単位で有

効にする必要があります。このことは、DMMP とPowerPathの両方に当てはまりま

す。

ハードウェア

要件

PowerPath Kitは、QLogic QLA2340 HBA (EMCが推奨する qla2xxx ドライバを使

用 )およびEmulex LP10000 HBA (EMCが推奨する lpfc ドライバを使用 )を使用す

るEMC CLARiiON CX300ディスクアレイにおいて、テストおよび認定済みで

す。PowerPath Kitは、QLogic QLA2340 HBAを使用するEMC CLARiX CX3-20においても、テストおよび認定済みです。

注記 : RHEL 6上のLifeKeeperは、EMC Clariionに接続されているリザベーションを

サポートできません。

このキットは、EMCの他のCLARiiONモデルまたは EMCからDellや他のベンダへの

OEMのCLARiiONモデルでも同様に問題なく動作すると考えられます。

マルチパスソ

フトウェアの

要件

PowerPath Kit v6.4.0-2には、PowerPath for Linux v5.3が必要です。PowerPathKit v6.4.0-2より前のバージョンでは、PowerPath for Linuxv4.4.x、v4.5.x、v5.0.x、v5.0.xが必要です。


EMC PowerPathのマルチパス I/O設定

PowerPathv5.3ドライバ

への移行方

法

オプション A

1. 以下の手順を実行して PowerPath 5.3ドライバにアップグレードします。

a. 古いPowerPathドライバを削除 b. PowerPath 5.3ドライバをインストール

2. PowerPath 6.4.0-2 Kitにアップグレードします。

3. サーバをリブートします。

注記 :サーバをリブートするとき、PowerPath 6.4.0-2 KitがLifeKeeper PowerPathリソースとして使用されます。PowerPathドライバ5.3に問題があり、古いPowerPathドライバを使用しなければならない場合、このオプションでは、v6.4.0-2キットをインス

トールする前に使用していたバージョンのPowerPath Kitを再インストールする必要が

あります。

オプション B

1. 以下の手順を実行して PowerPath 5.3ドライバにアップグレードします。

a. 古いPowerPathドライバを削除 b. PowerPath 5.3ドライバをインストール c. サーバをリブートします。

2. PowerPath 6.4.0-2 Kitにアップグレードし、以下のいずれかを実行してアップグ

レードされたRecovery Kitを使用して PowerPathリソースを開始します。

オプション 1: PowerPathリソースをサービス休止にして再度サービス状態に戻

します。

注記 : これを行うには、PowerPathデバイスを使用するすべてのアプリケーショ

ンをいったん停止してから再起動する必要があります。このオプションの場合、

操作を順次実行することができるため、別々の時間に実行して大きな変更

を回避することが可能です。

オプション 2: LifeKeeperを停止 (lkstop)してから起動 (lkstart)します。これに

より、すべてのリソースがいったんサービス休止になった後、再度サービス状態

に戻ります。

注記 : この方法では、オプション 1と同様にすべてのアプリケーションを停止し

ますが、2つのコマンドだけですべてのPowerPathリソースが新しいキットを使う

ようにできるため、ユーザの介入が少なくて済みます。

オプション 3: LifeKeeperをすぐに停止 (lkstop)してから起動 (lkstart)します。

注記 : この方法では、アプリケーションを実行したまま、LifeKeeperにストレー

ジへのアクセス方法をリロードさせます。アプリケーションの停止時間はありませ

ん。

116 設定

IBM SDDによるマルチパス I/O設定

IBM SDDによるマルチパス I/O 設定

マルチパスデ

バイスを使用

するアプリ


ァイルシステ

ムの保護

IBM SDDデバイスを使用するアプリケーションやファイルシステムを LifeKeeperによっ

て設定し保護するには、SDD Recovery Kitをインストールする必要があります。

SDD Kitのインストール後は、1つ以上のマルチパスデバイスノードを使用するアプリ

ケーション階層を作成するだけで、SDD Kitが提供する新しいリソースタイプが自動

的に組み込まれます。

マルチパスデ

バイスノード

SDD Kitを使用するには、すべてのファイルシステムおよびRAWデバイスをネイティブ

の /dev/sd*デバイスノードではなく、マルチパスデバイスノード (/dev/vpath*)上にマウ

ントまたは設定する必要があります。


SDD Kitは、リザベーションタイプを「書き込み専用」とするSCSI-3 PersistentReservationsを使用します。この場合、クラスタの1ノードが予約したデバイスは、ク







ハードウェア

要件

SDD Kitは、QLogic QLA2340 HBA (IBMが推奨する qla2xxx ドライバを使用 )を使

用する IBM ESS、6800、8100ディスクアレイおよび IBM SAN VolumeController(SVC)において、テストおよび認定済みです。SDD Kitは、SDD ドライバがサポート

する他の IBMディスクアレイとHBAアダプタ (Emulex)でも同様に問題なく動作する

と考えられます。 IBMが推奨するHBA ドライバを必ず使用する必要があります。

マルチパスソ

フトウェアの

要件

SDD Kitには、 IBM SDD ドライバv1.6.0.1-8以降を使用する必要があります。

SDDパスの

追加または

修復

LifeKeeperは、SDD リソースを起動する場合、パーシステントリザベーションを確立し

てその時点でアクティブなパスに登録します。最初のリザベーションの後に新しいパス

が追加されるか、障害が起きたパスが修復されて SDDがそのパスを自動的に再度

アクティブにした場合、そのパスは、LifeKeeperがSDD リソースに対する次の

quickCheckを実行するまでリザベーションの一部として登録されません。その時点ま

でにSDDがそのパスに対する書き込みを許可した場合、リザベーション競合が発生

し、SDDのログファイルとシステムのメッセージファイルに競合が記録されます。SDDドライバは、登録されたパスでそれらの I/Oを再試行するため、アプリケーションにとっ

ては検出可能な障害になりません。quickCheckによる

パスの登録が完了すると、その後の書き込みは成功します。

Hitachi HDLM のマルチパス I/O 設定


Hitachi HDLMのマルチパス I/O設定

マルチパスデ

バイスを使用

するアプリ


ァイルシステ

ムの保護

HDLMデバイスを使用するアプリケーションやファイルシステムを LifeKeeperによって設

定し保護するには、HDLMRecovery Kitをインストールする必要があります。

HDLM Kitのインストール後は、1つ以上のマルチパスデバイスノードを使用するアプリ

ケーション階層を作成するだけで、HDLM Kitが提供する新しいリソースタイプが自動

的に組み込まれます。

マルチパスデ

バイスノード

HDLM Kitを使用するには、すべてのファイルシステムおよびRAWデバイスをネイティ

ブの /dev/sd*デバイスノードではなく、マルチパスデバイスノード (/dev/sddlm*)上にマ

ウントまたは設定する必要があります。


HDLM Kitは、リザベーションタイプを「書き込み専用」とするSCSI-3 PersistentReservationsを使用します。この場合、クラスタの1ノードが予約したデバイスは、ク







ハードウェア

要件

HDLM Kitは、QLogic QLA2432 HBAおよび8.02.00-k5-rhel5.2-04ドライバと、

Silkworm3800 FCスイッチを使用したHitachi AMS1000ディスクアレイにおいて、テス

トおよび認定されました。HDLM Kitは、他の日立ディスクアレイでも同様に問題なく

動作すると考えられます。HDLM Kitは、SANRISE AMSシリーズ、SANRISEUSP、Hitachi VSPにおいても認定済みです。HBAおよびHBA ドライバはHDLMがサポートするものを使用してください。 BR1200は、Hitachi Data Systemsにより

認定。シングルパスとマルチパス構成の両方で RDAC ドライバーが必要で

す。RDAC ドライバーを使用するBR1200構成のみサポートされ、HDLM(HDLMARK)を使用する構成はサポートされていません。

マルチパスソ

フトウェアの

要件

HDLM Kitは、以下の各HDLM for Linuxをサポートします。

05-80, 05-81, 05-90, 05-91, 05-92, 05-93, 05-94, 6.0.0, 6.0.1, 6.1.0, 6.1.1, 6.1.2,6.2.0, 6.2.1, 6.3.0, 6.4.0, 6.4.1, 6.5.0, 6.5.1, 6.5.2, 6.6.0, 6.6.2, 7.2.0, 7.2.1, 7.3.0.

インストールされているHDLMパッケージに対する既知の依存関係はありません。

注記 : HDLM 6.0.0以降から製品名が「Hitachi Dynamic Link Manager Software(HDLM)」に変更されました。6.0.0 (05-9X)より古いバージョンでは、「HitachiHiCommandDynamic Link Manager (HDLM)」という製品名です。

注記 : HDLM version 6.2.1以降は、HDLMRecovery Kit v6.4.0-2でサポートされて

いません。このバージョンのHDLMを使用する場合は、HDLMRecovery Kit v7.2.0-1以降とLifeKeeper Core v7.3か、より新しいバージョンのCoreを使用してください。

注記 : LVMを使用する場合は、HDLMにてサポートされているバージョンのLVMを使

用してください。また、LVMが/dev/sddlm*に紐付いた /dev/sd*デバイスを検出しな

いよう、 /etc/lvm/lvm.confにフィルターを設定する必要があります。詳細はHDLMのマ

ニュアルからLVMの設定を参照してください。

118 設定


Linuxディスト

リビューション

の要件

Linuxディストリビューションの要件

HDLM Kitは以下のディストリビューションでサポートされています。

RHEL 4 (AS/ES) (x86 or x86_64) Update 1, 2, 3, 4, Update 4 Security Fix (*2),

4.5,4.5 Security Fix(*4),4.6,4.6 Security Fix(*8),4.7,4.7 Security Fix(*9),

4.8,4.8 Security Fix(*12) (x86/x86_64)(*1)

RHEL 5, 5.1, 5.1 Security Fix(*5), 5.2, 5.2 Security Fix(*6),

5.3, 5.3 Security Fix(*10),5.4 , 5.4 Security Fix (*11), 5.5, (x86/x86_64)(*1)

RHEL 6, 6.1, 6.2 (x86/x86_64)(*1)(*15)

(*1) AMD Opteron (シングルコア、デュアルコア)またはIntel EM64Tアーキテクチャ

CPU (x86_64カーネル)

(*2)次のカーネルがサポートされています。

x86：2.6.9-42.0.3.EL,2.6.9-42.0.3.ELsmp,2.6.9-42.0.3.ELhugemem

x86_64：2.6.9-42.0.3.EL,2.6.9-42.0.3.ELsmp,2.6.9-42.0.3.Ellargesmp

(*3)日立では、RHEL4U2の環境をサポートしていません。





x86：2.6.18-53.1.13.el5,2.6.18-53.1.13.el5PAE,2.6.18-53.1.21.el5,2.6.18-53.1.21.el5PAE

x86_64：2.6.18-53.1.13.el5,2.6.18-53.1.21.el5


x86：2.6.18-92.1.6.el5,2.6.18-92.1.6.el5PAE,2.6.18-92.1.13.el5,2.6.18-92.1.13.el5PAE,2.6.18-92.1.22.el5,2.6.18-92.1.22.el5PAE

x86_64：2.6.18-92.1.6.el5,2.6.18-92.1.13.el5,2.6.18-92.1.22.el5





x86：2.6.9-67.0.7.EL,2.6.9-67.0.7.ELsmp,2.6.9-67.0.7.ELhugemem,2.6.9-67.0.22.EL,2.6.9-67.0.22.ELsmp,2.6.9-67.0.22.ELhugemem

x86_64：2.6.9-67.0.7.EL,2.6.9-67.0.7.ELsmp,2.6.9-67.0.7.ELlargesmp,2.6.9-67.0.22.EL,2.6.9-67.0.22.ELsmp,2.6.9-67.0.22.ELlargesmp


x86：2.6.9-78.0.1.EL,2.6.9-78.0.1.ELsmp,2.6.9-78.0.1.ELhugemem,2.6.9-78.0.5.EL,2.6.9-78.0.5.ELsmp,2.6.9-78.0.5.ELhugemem,2.6.9-78.0.8.EL,2.6.9-78.0.8.ELsmp,2.6.9-78.0.8.ELhugemem,2.6.9-78.0.17.EL,2.6.9-78.0.17.ELsmp,2.6.9-78.0.17.ELhugemem,2.6.9-78.0.22.EL,2.6.9-78.0.22.ELsmp,2.6.9-78.0.22.ELhugemem

x86_64：2.6.9-78.0.1.EL,2.6.9-78.0.1.ELsmp,2.6.9-78.0.1.ELlargesmp,2.6.9-78.0.5.EL,2.6.9-78.0.5.ELsmp,2.6.9-78.0.5.ELlargesmp,2.6.9-78.0.8.EL,2.6.9-78.0.8.ELsmp,2.6.9-78.0.8.ELlargesmp,2.6.9-78.0.17.EL,2.6.9-78.0.17.ELsmp,2.6.9-78.0.17.ELlargesmp,2.6.9-78.0.22.EL,2.6.9-78.0.22.ELsmp,2.6.9-78.0.22.ELlargesmp



x86_64：2.6.18-128.1.10.el5,2.6.18-128.1.14.el5,2.6.18-128.7.1.el5



x86_64：2.6.18-164.9.1.el5,2.6.18-164.11.1.el5,2.6.18-164.15.1.el5





x86：2.6.18-194.11.1.el5,2.6.18-194.11.1.el5PAE,2.6.18-194.11.3.el5,2.6.18-194.11.3.el5PAE,2.6.18-194.17.1.el5,2.6.18-194.17.1.el5PAE,2.6.18-194.32.1.el5,2.6.18-194.32.1.el5PAE

x86_64：2.6.18-194.11.1.el5,2.6.18-194.11.3.el5,2.6.18-194.17.1.el5,2.6.18-194.32.1.el5



x86_64：2.6.18-238.1.1.el5,2.6.18-238.9.1.el5,2.6.18-238.19.1.el5


x86：2.6.32-71.el6.i686,2.6.32-131.0.15.el6.i686,2.6.32-220.el6.i686

x86_64：2.6.32-71.el6.x86_64,2.6.32-131.0.15.el6.x86_64,2.6.32-220.el6.x86_64



インストール

要件

HDLMRecovery Kitをインストールする前にHDLMソフトウェアをインストールする必

要があります。また、SCSIデバイスからHDLMデバイスに環境を移行したい場合

は、HDLM環境を設定した後、インストールセットアップスクリプトを実行する必要が

あります。そのようにしないと、sg3_utilsがインストールされません。

HDLMパスの

追加または

修復

LifeKeeperは、HDLMリソースを起動する場合、Persistent Reservationsを確立し

てその時点でアクティブなパスに登録します。最初のReservationの後に新しいパス

が追加されるか、障害が起きたパスが修復されて HDLMがそのパスを自動的に再

度アクティブにした場合、そのパスは、LifeKeeperがHDLMリソースに対する次の

quickCheckを実行するまでリザベーションの一部として登録されません。その時点ま

でにHDLMがそのパスに対する書き込みを許可した場合、Reservation Conflictが発生し、システムのメッセージファイルに競合が記録されます。HDLM ドライバは、登

録されたパスでそれらの I/Oを再試行するため、アプリケーションにとっては検出可能

な障害になりません。quickCheckによるパスの登録が完了

すると、その後の書き込みは成功します。quickCheckがReservation Conflictを検

出すると、ステータスが「Offline(E)」に変更されます。ステータスが「Offline(E)」の場

合、ユーザはオンラインのHDLMコマンドを使用して手動でステータスを「Online」に変更する必要があります。

OSのバージョン /アーキテクチャ

RHEL4

120 設定


U1-U4

U-3セ

キ

ュ

リ

テ

ィ

フ

ィッ

ク

ス(*7-)

U4セキ

ュリティ

フィック

ス (*2)

4.-5

4.-5セ

キ

ュ

リ

テ

ィ

フ

ィッ

ク

ス(*4-)

4.-6

4.-6セ

キ

ュ

リ

テ

ィ

フ

ィッ

ク

ス(*8-)

4.7

4.7セキュリテ

ィ

フィック

ス (*9)

4.8

4.8セキュリ

ティ

フィック

ス

(*12)

X86/X86_64



HDLM

05-80 ,05-81 05-90 X

05-91 ,05-92 X X

05-93 X (*3) X X

05-94 X (*3) X X X X X

6.0.0 X (*3) X X X X X X X X X

6.0.1 X (*3) X X X X X X X X X

6.1.0 X (*3) X X X X X X X X X

6.1.1 X (*3) X X X X X X X X X X

6.1.2 X (*3) X X X X X X X X X X

6.2.0 X (*3) X X X X X X X X X X

122 設定


6.2.1 X (*3) X X X X X X X X X X

6.3.0 X (*3) X X X X X X X X X X

6.4.0 X (*3) X X X X X X X X X X

6.4.1 X (*3) X X X X X X X X X X

6.5.0 X (*3) X X X X X X X XX

X

6.5.1 X (*3) X X X X X X X X X X

6.5.2 X (*3) X X X X X X X X X X

6.6.0 X (*3) X X X X X X X X X X

6.6.2 X (*3) X X X X X X X X X X

7.2.0 X (*3) X X X X X X X X X X

7.2.1 X (*3) X X X X X X X X X X

7.3.0 X (*3) X X X X X X X X X X



LifeKeep-er

v6.0 (v6.0.1-2以降 ) X X X

v6.1(v6.1.0-5以降 ) X X X

v6.2(v6.2.0-5以降 ) X X X X X X X

v6.2(v6.2.2-1以降 ) X X X X X X X

v6.3(v6.3.2-1以降 ) X X X X X X X

v6.4(v6.4.0-10以降 ) X X X X X X X X X

v7.0(v7.0.0-5以降 ) X X X X X X X X X X X

V7.1(v7.1.0-8以降 ) X X X X X X X X X X X

V7.2 (v7.2.0-10以降 ) X X X X X X X X X X X

V7.3(v7.3.0-21以降 ) X X X X X X X X X X X

v7.4(v7.4.0-63以降 ) X X X X X X X X X X X

v7.5(7.5.0-3640以降 )

RHEL4のサポートはLifeKeeper v7.4までです。v7.5以降はサポー

トされません。

HDLMARK

6.0.1-2 X X X X X X X

6.1.0-4 X X X X X X X

6.2.2-3 X X X X X X X

6.2.3-1 X X X X X X X X X X X

6.4.0-2 X X X X X X X X X X X

7.0.0-1 X X X X X X X X X X X

7.2.0-1 X X X X X X X X X X X

X =サポートあり、空白 =サポートなし

124 設定


RHEL5

OSバージョン/アーキテクチャ

未

更

新

5.-1

5.-1セ

キ

ュ

リ

テ

ィ

フ

ィ

ッ

ク

ス(*-5)

5.-2

5.-2セ

キ

ュ

リ

テ

ィ

フ

ィ

ッ

ク

ス(*-6)

5.-3

5.3セ

キ

ュリ

ティ

フィ

ック

ス(*1-0)

5.-4

5.4セキュリ

ティ

フィックス

(*11)

5.-5

5.5セキ

ュリ

ティ

フィッ

クス(*1-3)

5.-6

5.-6セ

キ

ュ

リ

テ

ィ

フ

ィ

ッ

ク

ス

5.-7

5.-8

X86/X86_64



HDLM

05-80 , 05-81 ,05-90

05-91 ,05-92

05-93 X

05-94 X X

6.0.0 X X X X X

6.0.1 X X X X X

6.1.0 X X X X X

6.1.1 X X X X X

6.1.2 X X X X X X X X X X X X X X X



126 設定


LifeKee-per

v6.0 (v6.0.1-2以降 )

v6.1 (v6.1.0-5以降 ) X X

v6.2 (v6.2.0-5以降 ) X X

v6.2 (v6.2.2-1以降 ) X X X

v6.3 (v6.3.2-1以降 ) X X X X X

v6.4 (v6.4.0-10以降 ) X X X X X X X

v7.0 (v7.0.0-5以降 ) X X X X X X X X X

v7.1 (v7.1.0-8以降 ) X X X X X X X X X X X

v7.2 (v7.2.0-10以降 ) X X X X X X X X X X X

V7.3(7.3.0-21以降 ) X X X X X X X X X X X X X

v7.4(v7.4.0-63以降 ) X X X X X X X X X X X X X X

v7.5(7.5.0-3640以降 ) X X X X X X X X X X X X X X X

v8.0(8.0.0-510以降 ) X X X X X X X X X X X X X X X

HDLMARK

6.0.1-2

6.1.0-4 X X

6.2.2-3 X X X

6.2.3-1 X X X X X

6.4.0-2 X X X X X X X

7.0.0-1 X X X X X X X X X X X

7.2.0-1 X X X X X X X X X X X X X X X


128 設定

DeviceMapper Multipath I/Oの設定

RHEL6

OSバージョン/アーキテクチャ

6 6.1 6.2

X86/X86_64

HDLM

6.5.0

6.5.1

6.5.2 X

6.6.0 X

6.6.2 X

6.6.2-01 X X X

7.2.0 X X X

7.2.1 X X X

7.3.0 X X X

LifeKeeper

V7.0(v7.0.0-5以降 )

V7.1(v7.1.0-8以降 )

V7.2(v7.2.0-10以降 )

V7.3(7.3.0-21以降 ) X

v7.4(v7.4.0-63以降 ) X

v7.5(7.5.0-3640以降 ) X X X

v8.0(8.0.0-510以降 ) X X X

HDLM ARK7.0.0-1

7.2.0-1 X X X


Device Mapper Multipath I/O の設定

DeviceMapperMultipathデバイスを使用

するアプリ


ァイルシステ

ムの保護

DeviceMapper Multipathデバイスを使用するアプリケーションやファイルシステムを

LifeKeeperによって設定し保護するには、DeviceMapper Multipath (DMMP)Recovery Kitをインストールする必要があります。

DMMP Kitのインストール後は、1つ以上のマルチパスデバイスノードを使用するアプ

リケーション階層を作成するだけで、DMMP Kitが提供する新しいリソースタイプが自

動的に組み込まれます。



マルチパスデ

バイスノード

DMMP Kitを使用するには、すべてのファイルシステムおよびRAWデバイスをネイティ

ブの /dev/sd*デバイスノードではなく、マルチパスデバイスノード上にマウントまたは設

定する必要があります。ディスク全体を利用できるサポート対象のマルチパスデバイス

ノードは、 /dev/dm-#、 /dev/mapper/<uuid>、 /dev/mapper/<user_friendly_name>お

よび /dev/mpath/<uuid>です。ディスクのパーティションに対応するには、 /dev/mapperディレクトリに作成される各パーティション用のデバイスノードを使用します。


DeviceMapper Multipath Recovery Kitは、リザベーションタイプを「書き込み専用」と

するSCSI-3 Persistent Reservationsを使用します。この場合、クラスタの1ノードが

予約したデバイスは、クラスタの他のノードから読み取り可能のままですが、デバイス

への書き込みはできなくなります。このことは、それらの他のノード上で進行中の読み

取り専用アクセスのためにファイルシステムをマウントできるという意味ではないことに

注意してください。




EMC Symmetrix (VMAXを含む)アレイをマルチパスソフトウェアおよびLifeKeeperと組み合わせて使用する場合は、SCSI-3 Persistent Reservationsを LUN単位で有

効にする必要があります。このことは、DMMP とPowerPathの両方に当てはまりま

す。

130 設定


ハードウェア

要件

DeviceMapper Multipath Kitは、EMC CLARiiON CX300、HP EVA 8000、HPMSA1500、HP P2000、 IBM SAN VolumeController (SVC)、 IBM DS8100、 IBMDS6800、 IBM ESS、DataCore SANsymphony、HDS 9980Vを使用して SIOSTechnology Corp.によりテスト済みです。DeviceMapper Multipathのサポートについ

ては、ストレージベンダにお問い合わせください。

CX300でリザベーションのサポートを有効にするには、リザベーションに従うようにハー

ドウェアハンドラに通知する必要があります。このアレイ用に /etc/multipath.conf内の

次のパラメータを設定してください。

hardware_handler “3 emc 0 1"

HP MSA1500の場合、デフォルトのパスチェッカ (tur)とのリザベーション競合を返しま

す。これによりスタンバイノードは、すべてのパスを障害であると判定します。この状態

を回避するには、このアレイ用に /etc/multipath.conf内の次のパラメータを設定してく

ださい。

path_checker readsector0

HDS 9980Vの場合、以下の設定が必要です。

l Host mode: 00

l System option: 254 (有効にする必要があります。すべてのサーバに影響を与

えるグローバルな HDS設定です。)

l Device emulation: OPEN-V

HDSのDMMP設定の詳細については、HDS ドキュメンテーション「Suse LinuxDeviceMapper Multipath for HDS Storage」または「RedHat Linux DeviceMapperMultipath for HDS Storage」v1.15以降を参照してください。このドキュメンテーション

では、互換性のあるmultipath.conf ファイルも提供しています。

ファームウェアバージョン 6以降を使用するEVAストレージでは、DMMP RecoveryKit v6.1.2-3以降が必要です。これ以前のバージョンのDMMP Recovery Kitは、

バージョン 6より前のファームウェアを使用するEVAストレージでサポートされていま

す。

マルチパスソ

フトウェアの

要件

SUSEの場合、multipath-tools-0.4.5-0.14以降が必要です。

RedHatの場合、device-mapper-multipath-0.4.5-12.0.RHEL4以降が必要です。

ベンダが提供する最新のマルチパスツールの組み合わせを使用することを推奨しま

す。このマルチパス製品の機能と安定性は急速に向上しています。

Linuxディスト

リビューション

の要件

IBMなどの一部のストレージベンダは、現時点では SLES 11を使用するDMMPを

認定していません。

SIOS Technology Corp.は、DMMP、SLES 11、EMC CLARiiONおよびSymmetrixアレイの組み合わせで報告された問題を現在調査中です。



一時的なパ

ス障害

DeviceMapper Multipathデバイスで I/Oテストを実行中に、サーバのリブートなどの

SAN上の操作によって一時的なパスの障害が報告されることは珍しくありません。

ほとんどの場合、結果として単に 1つのパスだけが障害となり他のパスは I/Oを送信

するため、パフォーマンスへのわずかな影響以外に検出される障害はありません。た

だし一部のケースでは、複数のパスが障害として報告され、機能するパスがまったく

ない状態になることがあります。この状態では、ファイルシステムやデータベースなどの

アプリケーションからは I/Oエラーが発生しているように見えます。このような障害を排

除する上で、DeviceMapper Multipathおよびベンダのサポートはこれまでに大きく改

善されました。ただし、まだ問題が発生することはあります。このような状況を回避す

るため、以下の措置を検討してください。

1. ディスクアレイベンダの手順に従ってマルチパス構成が正しく設定されているこ

とを確認します。

2. 「failback」機能の設定を確認します。この機能は、パスの障害および修復

後にパスを再度アクティブにするまでの時間を指定します。「immediate」に設

定した場合、パスがオンラインに戻るとすぐに使用を再開することを意味しま

す。整数に設定した場合、パスがオンラインに戻ってから使用を再開するまで

の秒数を意味します。10～ 15に設定すると、一般的にSAN上のスラッシン

グを回避するのに十分なセトリング時間が得られます。

3. 「no_path_retry」機能の設定を確認します。この機能は、すべてのパスに障

害が発生したときにDeviceMapper Multipathがやるべきことを指定しま

す。10～ 15に設定することを推奨します。この機能によって、すべてのパスに

障害が起きた一時的なイベントを「乗り切る」方法が提供され、復旧に必要

な妥当な時間を稼ぐことができます。LifeKeeperのDMMP Kitはストレージへ

の I/Oを監視しており、4分以内に応答がなかった場合、LifeKeeperはスタ

ンバイサーバにリソースをスイッチオーバします。注記 :簡単には削除できない

I/Oが発生するため、LifeKeeperでは「no_path_retry」設定を「queue」に設

定することは推奨されません。それらを削除するためのメカニズムは、新しい

バージョンのDMに含まれており、デバイスの設定を次のように変更できます。

/sbin/dmsetup message -u 'DMid' 0 fail_if_no_path

これによって no_path_retryの設定が一時的に「fail」に変更され、未処理の

I/Oがすべて失敗します。ただし、multipathdは、no_path_retryをいつでもデ

フォルトにリセットできます。失敗した I/Oを消去するために設定が fail_if_no_pathに変更されたときは、デバイスにアクセスする前に (手動または

LifeKeeperによって)設定をデフォルトにリセットする必要があります。

「no_path_retry」が「queue」に設定されていて障害が発生した場

合、LifeKeeperはリソースをスタンバイサーバにスイッチオーバします。ただ

し、LifeKeeperは失敗した I/Oを削除しません。この I/Oを消去するための推

奨の方法はリブートですが、上記のdmsetupコマンドを使用して管理者が

消去することもできます。 I/Oを消去しておかないと、他方のサーバでリソース

がサービス休止状態になってロックを解放した場合にこの「古い」I/Oが発行さ

れる事態になってデータの破損が発生します。

132 設定

LifeKeeper I-Oフェンシングの概要

LifeKeeper I-O フェンシングの概要

I/Oフェンシングは、障害ノードをデータから切り離すことにより、共有ストレージへの非協調的なアクセ

スを防止する機能です。複数のサーバが同じデータにアクセスできる環境では、データの破損を防ぐた

めにすべての書き込みを制御された方法で行うことが不可欠です。障害検知メカニズムが破綻した場

合、この破綻によってノード障害に似た状況になるため問題が発生します。例えば、2ノードクラスタで

2つのノード間の接続に障害が発生した場合、各ノードは相手側に障害が発生したと「思い込む」た

め、両方のノードがデータに対する制御を獲得しようと試みてデータの破損につながります。 I/Oフェンシ

ングは、特定のノードからのデータアクセスをブロックすることによりこのデータ破損のリスクを排除します。

リザベーションの無効化

リザベーションを使用すると、共有ストレージに対する最高レベルのデータ保護が可能になりますが、場

合によっては、リザベーションを使用できずLifeKeeper内で無効にしなければならないことがあります。リ

ザベーションを無効にすると、複数のシステムが意図的または意図せずにストレージにアクセスしようとす

る場合にストレージが調停役として動作することがなくなります。

そのため、システムハング、システムビジー、またはサーバが停止したように見えるあらゆる状況に対応で

きるように、クラスタメンバーシップによってストレージをフェンシングする別の方法を採用することを検討す


リザベーションがなくても信頼性の高い構成を実現する鍵は、フェイルオーバが発生したとき、「他の」

サーバの電源がオフになったこと、または電源が再投入されたことを「知る」ことです。この要件を満たす

ために利用可能なフェンシングオプションは 4つあり、これらは SCSI リザベーションなしでも LifeKeeperで非常に信頼性の高い構成を実現できます。オプションは以下の通りです。

l STONITH (Shoot the Other Node in the Head) (高信頼性のインターコネクト、すなわちサーバと

STONITHデバイスとの間のシリアル接続を使用 ) - STONITHは、サーバがクラスタの一部とみな

されなくなったときに、そのサーバを物理的に停止させたり、電源を切断したりする技術で

す。LifeKeeperフェイルオーバのイベント時にサーバの電源を切断する機能をサポートしていま

す。これにより共有データへの安全なアクセスを保証します。このオプションはリザベーションと同

様の信頼性を提供できますが、利用できるのは物理的に同じ場所に配置された 2つのノード

に限定されます。

l Quorum/Witness - Quorum/Witnessサーバは、特にクラスタサーバが異なる場所に配置されて

いる場合に、クラスタ内でのメンバーシップを確認するために使用されます。このオプションはスプリ

ットブレインに対応できるもののシステムハングに対応できないため、単独での使用は推奨され

ません。

l Watchdog -Watchdogは、サーバーの状態を監視します。問題が検出されると、問題のある

サーバは再起動または電源を切断されます。このオプションではサーバーのハングからのリカバリ

はできますが、スプリットブレインには対応できません。したがって、このオプションもまた単独での

使用は推奨されません。

l CONFIRM_SO -このオプションでは自動フェイルオーバを無効にする必要があります。そのため、

信頼性が非常に高い (管理者のスキルによって異なります)一方で、可用性はあまり高くありま

せん。


非共有ストレージ

これらの代替フェンシング方式はどれも単独では十分とは言えませんが、組み合わせて使用することで

非常に信頼性の高い構成を実現できます。


非共有ストレージ環境で LifeKeeperを使用する計画の場合、共有ストレージに存在するデータ破損

のリスクは問題にならないため、リザベーションは不要です。ただし、データの部分的または完全な再同

期およびマージが必要な場合があります。信頼性と可用性を最適化するには、非共有ストレージでも

上記のオプションを検討する必要があります。

注記 :各オプションの信頼性と可用性の比較の詳細については、 I/Oフェンシング比較表を参照してく

ださい。

完全なデータ保護を実現するオプションはないことを理解することは重要です。ただし、以下のように組

み合わせるとリザベーションとほぼ同等レベルの保護を実現できます。

リザベーションを使用しない I/O フェンシングの設定

ノードフェンシングをサポートするクラスタを構成するには以下の手順を実行します。

1. LifeKeeperを停止します。

2. LifeKeeper内でのSCSI リザベーションの使用を無効にします。無効にするには、クラスタのすべ

てのノードで LifeKeeperのデフォルトファイル /etc/default/LifeKeeperを編集しま

す。Reservations変数を追加または修正して「none」にします (RESERVATIONS=”none”)。こ

のオプションはリザベーションを利用できない場合のみ使用することに注意してください。

3. I/Oフェンシングを提供するSTONITHデバイスを用意して設定します。この設定で

は、STONITHデバイスが reboot コマンドではなく、poweroff コマンドをシステムに対して実行す

るようにします。LifeKeeperの通信が何らかの理由で中断したとき、手動操作によって同時に

両ノード上のデバイス階層を In Serviceの状態にしないように注意してください。

4. 必要に応じて、quorum/witnessサーバを用意して設定します。quorum/witnessサーバを設

定、使用する詳細な手順と情報については、Quorum/Witness Server Support Package トピッ

クを参照してください。

注記 :サイトの障害時に最良の保護機能を提供するため、quorum/witnessサーバはクラスタ

内の別サーバから離れた場所にある必要があります。

5. 必要に応じて、Watchdogを設定します。詳細については、 Watchdog トピックを参照してくださ

い。

I/O フェンシング表

スプリットブレインハングしたサーバ

リザベーション有効

リザベーション単独

134 設定

I/Oフェンシング表

Quroum/Witness

Watchdog

Watchdog & Quorum/Witness

STONITH (シリアル)

リザベーション無効

フェンシングなし


CONFIRM_SO*

Quorum/Witness

Watchdog


デフォルトの機能

Quorum/Witness

CONFIRM_SO*

Watchdog


Watchdog & STONITH


Quorum/Witness

信頼性最大信頼性最小

*CONFIRM_SOは、信頼性が非常に高い (管理者のスキルによって異なります)一方で、自動フェイ

ルオーバが無効になるため可用性はあまり高くありません。

Quorum/Witness

Quorum/Witness Server Support Package for LifeKeeper

機能の概要

LifeKeeper Coreの既存のフェイルオーバプロセスにQuorum/Witness Server Support Package forLifeKeeper (steeleye-lkQWK)を組み合わせることにより、ネットワーク全体にわたる障害の恐れがある

環境において、より高い信頼度でシステムフェイルオーバを実行できます。つまり、「スプリットブレイン」の

発生リスクを大幅に軽減しながら、ローカルサイトのフェイルオーバとWAN越しのノードへのフェイルオー

バを実行することができます。このパッケージでは、多数決ベースのquorum checkを使用して 3ノード

以上のクラスタを制御できます。追加のquorumロジックは、witnessサポートパッケージをインストールし

た場合のみ有効になります。

1台以上のwitnessサーバを使用すると、通信障害後にリソースを起動する前に、障害ノードのス

テータスについて他のノードから「セカンドオピニオン」を取得できます。witnessサーバは、クラスタを構成

するサーバを判断する調停役として機能する追加的なサーバです。フェイルオーバ先となることができる

ノードは、witnessサーバが障害となったノードのステータスに関して同じ意見である場合のみ、リソース

起動が許可されます。これにより、ノード間で発生する単純な通信障害から発生するフェイルオーバを

回避し、全体のアクセスや、パフォーマンス、 In Serviceのノードに影響を与えないようにします。実際

の運用では、最初に実行されたとき、witness ノードを含め、クラスタ内の他のすべてのノードに問い合

わせをします。

パッケージの要件

すでに説明した要件に加えて、このパッケージの要件として、ライセンス認証された標準のLifeKeeperCoreがwitness serverとして機能するサーバにインストールされている必要があります。注記 : コミュニ

ケーションパスが正しく設定されている限り、複数のクラスタが単一のquorum/witness serverを共有で

きます (詳細については、下の共有 witness トポロジーのための追加設定を参照してください)。

quorum/witnessモードのクラスタに参加するすべてのノード (witness専用のノードを含む)には、Quorum/Witness Server Support Package for LifeKeeperをインストールする必要があります。 tcp_remote quorumモードを使用する場合は、 /etc/default/LifeKeeper内のQUORUM_HOSTSに設定し

たホストにはQuorum/Witness Server Support Package for LifeKeeperをインストールする必要はありま

せん。

136 設定

パッケージのインストールと設定

パッケージのインストールと設定

Quorum/Witness Server Support Package for LifeKeeperは、quorum/witnessモードのクラスタ内の各

サーバ (witness専用のサーバを含む)にインストールする必要があります。witness ノードに必要な唯

一の設定は、適切なコミュニケーションパスを作成することです。

witnessサーバを追加する一般的なプロセスには以下の手順が含まれます。

l witness ノード用のサーバをセットアップし、他のノードとのネットワーク通信ができることを確認し

ます。

l witness ノード上に LifeKeeper Coreをインストールし、適切にライセンス認証 /アクティベーション

を行います。

l クラスタ内のすべてのノードに quorum/witnessサポートパッケージをインストールします。

l witness ノードを含め、すべてのノード間でコミュニケーションパスを作成します。

上記の手順が完了すると、クラスタは quorum/witnessモードで動作するようになり、フェイルオーバが許

可される前に、witness ノードを含む他のノードにフェイルオーバの確認が行われます。パッケージインス

トール後のデフォルト設定では、多数決ベースのquorum checkおよびwitness checkが有効になって

います。

注記 : Quorum (クラスタ構成に必要な最小メンバー数 )が多数決ベースのため、クラスタを構成する

ノードの台数を奇数にすることを推奨します。

詳細な設定オプションについては、下の「設定可能なコンポーネント」セクションを参照してください。

注記 : witnessパッケージをインストールしたノードであれば、witness機能に参加できます。witness専用ノードとは、互換性のある LifeKeeperのCoreとwitnessパッケージがインストールされていて、保護

対象のリソースを持たないノードのことを単に指しています。

設定可能なコンポーネント

quorum/witnessパッケージでは、quorumとwitness という 2つのモードを設定できます。デフォルトで

は、quorum/witnessパッケージをインストールすると、quorumとwitnessの両方のモードが有効になりま

す。これは、witness機能を必要とする大部分の環境に適した動作です。

これらのモードは、 /etc/default/LifeKeeper設定ファイルでカスタマイズすることが可能

で、witnessモードは個別に調整することもできます。パッケージがインストールされると設定ファイルには

デフォルト設定が書き込まれ、majorityがデフォルトのquorumモードに、remote_verifyがデフォルトの

witnessモードになります。以下はその例です。

QUORUM_MODE=majority

WITNESS_MODE=remote_verify

注記 : クラスタの各ノードでまったく異なる quorum/witness設定をすることはできますが、予想外の状

況や診断の困難な状況になることを避けるため、すべてのノードで同じ設定にすることを推奨します。


使用可能な quorumモード

使用可能な quorum モード

quorum checkモードには次の3種類のモードが用意されています。これら

は、/etc/default/LifeKeeperのQUORUM_MODE設定を使用して設定できます。majority (デフォルト )、 tcp_remote、none/off。以下に各モードを説明します。

majority

デフォルトのmajority設定では、チェック時に可視 /生存している LifeKeeperノードの数に基づいて

Quorumが決定されます。このチェックは、単純な多数決方式です。全ノード数の過半数を見ることが

できるノードはQuorumに属します。

tcp_remote

tcp_remote quorumモードは、以下の点を除いてmajorityモードと共通です。

l 問い合わせを受けるサーバは、クラスタとそのコミュニケーションパスから独立して設定する (これら

のサーバに LifeKeeperをインストールする必要はありません)。

l サーバへの確認は、単に指定ポート上のTCP/IPサービスに接続できるかどうかによって行われ

る。

このモードでは、TCPのタイムアウト設定 (QUORUM_TIMEOUT_SECS)と問い合わせ先のホスト

(QUORUM_HOSTS)を /etc/default/LifeKeeperに追加する必要があるため、追加設定が必要

です。 tcp_remoteの設定例は以下の通りです。

QUORUM_MODE=tcp_remote

# What style of quorum verification do we do in comm_up/down

# and lcm_avail (maybe other) event handlers.

# The possible values are:

# - none/off: Do nothing, skip the check, assume all is well.

# - majority: Verify that this node and the nodes it can reach

# have more than half the cluster nodes.

# - tcp_remote: Verify that this node can reach more than half

# of the QUORUM_HOSTS via tcp/ip.

QUORUM_HOSTS=myhost:80,router1:443,router2:22

# If QUORUM_MODE eq tcp_remote, this should be a comma delimited

# list of host:port values – like

myhost:80,router1:443,router2:22.

# This doesn't matter if the QUORUM_MODE is something else.

QUORUM_TIMEOUT_SECS=20

# The time allowed for tcp/ip witness connections to complete.

# Connections that don't complete within this time are treated

# as failed/unavailable.

# This only applies when the QUORUM_MODE is tcp_remote.

WITNESS_MODE=remote_verify

# This can be either off/none or remote_verify. In remote_verify

# mode, core event handlers (comm_down) will doublecheck the

138 設定

使用可能な witnessモード

# death of a system by seeing if other visible nodes

# also think it is dead.

QUORUM_LOSS_ACTION=fastboot

# This can be one of osu, fastkill or fastboot.

# fastboot will IMMEDIATELY reboot the system if a loss of quorum

# is detected.

# fastkill will IMMEDIATELY halt/power off the system upon

# loss of quorum.

# osu will just take any in-service resources out of service.

# Note: this action does not sync disks or unmount filesystems.

QUORUM_DEBUG=

# Set to true/on/1 to enable debug messages from the Quorum

# modules.

HIDE_GUI_SYS_LIST=1

注記 : このモードは本質的に柔軟性と複雑さを備えるため、使用するには、LifeKeeperおよび関連す

る特定のネットワーク/クラスタ設定の両方に対する十分な理解と注意が必要です。

none/off

このモードでは、すべてのquorum checkが無効になっています。この設定では、クラスタの実際の状態

にかかわらず、あたかもそのノードが常にQuorumを持っているように quorum checkが動作します。

使用可能な witnessモード

witnessモードには次の2種類のモードが用意されています。これら

は、/etc/default/LifeKeeperのWITNESS_MODE設定を使用して設定できます。remote_verifyおよびnone/off。以下に各モードを説明します。

remote_verify

このデフォルトモードでは、witness checkによってノードのステータスを確認します。通常、この確認は

ノード障害が疑われるときに行われます。このモードでは、各ノードはクラスタ内の他のすべての可視

ノードに対して障害ノードのステータスに関する意見を求めることにより、疎通を二重にチェックします。

none/off

このモードでは、witness checkが無効になっています。通信障害の場合は、あたかも witness機能が

インストールされていないかのような論理で動作します。

注記 : リソースを持たずに quorum/witness専用ノードとして動作するサーバはwitness checkを実行

する必要がないため、そのようなサーバでは、witnessモードを none/offに設定する必要があります。

Quorum を喪失したときに利用可能なアクション

witnessパッケージでは、Quorumを喪失したときにシステムがどのように応答すべきかについて 3種類

のオプションを提供しています。これらのオプションは、/etc/default/LifeKeeper内のQUORUM_


共有 witness トポロジーのための追加設定

LOSS_ACTION設定によって選択できます。3つのオプションはすべてそのシステムのリソースをOut ofService状態にしますが、それぞれ異なる動作をします。quorumパッケージがインストールされている場

合のデフォルトオプションは fastbootです。以下に各オプションを説明します。

fastboot

fastbootオプションを選択している場合、(通信ができないことにより) Quorumの喪失が検出されるとシ

ステムは直ちにリブートします。これは過激な方法ですが、確実にシステムを外部のリソースから素早く

切り離すことができます。ストレージレベルのレプリケーションなど、多くの場合にリソースをこのように即座

にリリースすることが望まれます。

このオプションには、以下の2つの重要な注意点があります。

1. システムは、シャットダウン手順を最初に実行することなく直ちにハードリブートを実行します。(ディスクの同期などの)タスクは一切実行されません。

2. システムは、ストレージとのネゴシエーションやリソースへのアクセスなどを含む通常の起動ルーチ

ンを実行しながら復帰します。

fastkill

fastkillオプションは、 fastbootオプションに非常に似ていますが、システムはQuorumを喪失したときに

ハードリブートするのではなく、即座に停止します。 fastbootオプションと同様に (ディスクの同期などの)タスクは一切実行されません。システムは手動でリブートする必要があります。その後システムは、スト

レージとのネゴシエーションやリソースへのアクセスなどを含む通常の起動ルーチンを実行しながら復帰し

ます。

osu

osuオプションは、最も穏健なオプションです。Quorumを喪失したシステムはそのまま稼働しますが、シ

ステム上のリソースはOut of Service状態にされます。一部のクラスタ構成ではこの方法で十分です

が、他のクラスタ構成では保護能力不足だったり応答が遅すぎる場合があります。

共有 witness トポロジーのための追加設定

quorum/witnessサーバを複数のクラスタで共有する場合、個々のクラスタの管理を簡素化するように

設定することができます。標準的な操作では、LifeKeeper GUIを使用して最初のノードに接続しようと

すると、LifeKeeper GUIはすべてのクラスタノードとの接続を試みます。つまり、クラスタ内の各システムか

ら見えるすべてのシステムに接続します。共有 witnessサーバはすべてのクラスタに接続されているた

め、GUIはwitness ノードから見えるすべてのクラスタ内のすべてのシステムに接続することになります。

この状況を回避するには、すべてのwitnessサーバで HIDE_GUI_SYS_LIST 設定パラメータ

を「true」に設定する必要があります。この設定によって witnessサーバから見えるサーバは実質的に不

可視になり、GUIは最初に接続したサーバに関連付けられたクラスタ内のサーバにのみ接続するように

なります。注記 : この設定はwitnessサーバにのみ設定してください。

GUIは、最初に接続したサーバに関連付けられたクラスタ内のサーバにのみ接続するため、そのサーバ

がwitnessサーバで、かつHIDE_GUI_SYS_LISTが「true」に設定されている場合、GUIはコミュニ

ケーションパスが確立している他のサーバに自動的に接続することができません。この現象は

LifeKeeper GUIの典型的な動作ではないため、ネットワークまたは他の設定に問題があるとインストー

ラが間違って判断する可能性があります。この設定をしたwitnessサーバ上で LifeKeeper GUIを使用

140 設定

2ノードクラスタにwitness ノードを追加する

する場合は、クラスタ内の他のいずれかのノードに手動で接続すると、クラスタの残りのノードが正しく

GUIに表示されます。

注記 :すべてのクラスタ内のすべてのシステムで witness checkが実行されるのを防ぐには、共有する

quorum/witness専用ノードで witness_modeを常に none/offに設定してください。

2 ノードクラスタにwitness ノードを追加する以下はQuorum/Witness Server Support Package for LifeKeeperを利用する 2ノードクラスタに 3番目のノードとなるwitness ノードを追加する場合の例です。

witness ノードを持つ単純な 2 ノードクラスタ


期待される動作 (デフォルトモードを仮定 )

サーバA とサーバBは、LifeKeeper Coreを使用したセットアップがすでに完了し、サーバAで作成され

たリソース階層がサーバBに拡張されています (サーバWは、拡張されたリソース階層を持っていませ

ん)。以下の手順を使用して 3番目のノードをwitness ノードとして追加します。

1. witness用のノードをセットアップし、他の2ノードとのネットワーク通信ができることを確認しま

す。

2. witness ノード上に LifeKeeper Coreをインストールし、適切にライセンス認証 /アクティベーション

を行います。

3. 3ノードすべてにQuorum/Witness Server Support Packageをインストールします。

4. 3ノードの間すべてにコミュニケーションパスを作成します。

5. 必要な quorum checkモードを /etc/default/LifeKeeperに設定します

(majority、 tcp_remote、non/off) (この例ではmajorityを選択しています)。これらのモードの説明

については、使用可能な quorumモードを参照してください。

6. 必要な witnessモードを /etc/default/LifeKeeperに設定します (remote_verify、non/off)。これらのモードの説明については、使用可能な witnessモードを参照してくだ

さい。

期待される動作 (デフォルトモードを仮定 )シナリオ1サーバA とサーバB との間の通信に障害が発生

サーバA とサーバBの間の通信に障害が発生した場合、以下のように動作します。

l サーバA とBは、通信障害イベントの処理を開始します。ただし、全く同時とは限りません。

l 両方のサーバは簡単な quorum checkを実行し、両方共自身が多数派に属すると判断しま

す (A とBの両方からWが見えているため、既知の3ノードのうちの2ノード側にいると判断しま

す)。

l 各サーバは、まだ通信可能な他方のノードに対し、自ノードと通信できなくなったサーバの状態

について問い合わせます。このシナリオでは、サーバAがBのステータスについてWに問い合わ

せ、サーバBがAのステータスについてWに問い合わせることになります。

l サーバA とBは共にwitnessサーバへの問い合わせによって他方のサーバがまだ生存していると

判断し、フェイルオーバ処理は何も発生しません。リソースは In Serviceのままになります。

シナリオ2サーバA とW との間の通信に障害が発生

witnessパッケージがインストールされていると、すべてのノードがwitness ノードとして動作することが可

能であり、実際にそのように動作するため、このシナリオは前のシナリオと同じになります。この場合、

サーバA とwitnessサーバWは共にサーバBへの問い合わせによって他方のサーバがまだ生存してい

ると判断します。

シナリオ3サーバA と他の全ノードとの間の通信に障害が発生 (A に障害が発生 )

142 設定

シナリオ4

この場合、サーバBは以下の動作をします。

l サーバA との通信障害イベントの処理を開始します。

l witnessサーバW とまだ通信が可能であり、したがってQuorumを持っていると判断します。

l サーバAが見えないことをサーバWに確認した後、通常のフェイルオーバ動作を開始します。

l これにより保護対象のリソースはサーバB上で In Serviceになります。

B がソースとして動作している状態で、サーバA の通信が回復

前のシナリオの状態から、サーバAが通信を再開したとします。サーバBは、comm_upイベントを処理

し、Quorumを持っている (3ノードすべてが見える)ことと、 In Serviceのリソースを持っていることを判断

します。サーバAは、comm_upイベントを処理し、自身も Quorumを持っていることと、リソースが別の

場所で In Serviceであることを判断します。この時点では、サーバAはリソースを in serviceにしませ

ん。

B がソースとして動作している状態で、サーバA に電源が入れられて他のノードと通信可能

この場合、サーバBは前のシナリオと同じように応答しますが、サーバAは lcm_availイベントを処理し

ます。サーバAは、Quorumを持っていると判断し、この場合は、現在サーバBで in serviceであるリ

ソースを in serviceにしないことにより正常に応答します。

B がソースとして動作している状態で、サーバA に電源が入れられて他のノードと通信不能

この場合、サーバAは lcm_availイベントを処理し、サーバB とWはサーバA と通信できないので何も

しません。サーバAは、3ノードのうちの1ノードとしか通信できないためQuorumを持っていないと判断

します。Quorumを持たない場合、サーバAはリソースを in serviceにしません。

シナリオ4サーバA と他の全ノードとの間の通信に障害が発生 (A のネットワークに障害が発生しているが、Aは稼動中 )

この場合、サーバBは以下の動作をします。

l サーバA との通信障害イベントの処理を開始します。

l witnessサーバW とまだ通信が可能であり、したがってQuorumを持っていると判断します。

l サーバAが見えないことをサーバWに確認した後、通常のフェイルオーバ動作を開始します。

l これにより保護対象のリソースはサーバB上で In Serviceになります。

また、この場合、サーバAは以下の動作をします。

l サーバB との通信障害イベントの処理を開始します。

l サーバB とも witnessサーバW とも通信できないため、Quorumを持っていないと判断します。

l 直ちにリブートします (「fastboot」がデフォルトの動作のため、ハードリブートされます)。

SCSI リザベーション

SCSI リザベーションを利用したストレージフェンシング


SCSI リザベーションを利用したストレージフェンシング

LifeKeeper for Linuxは、リソースフェンシングとノードフェンシングの両方をサポートしますが、主要なフェ

ンシングメカニズムは、SCSI リザベーションによるストレージフェンシングです。共有ストレージに対する最

高レベルのデータ保護を提供するこのフェンシングを使用すると、非常に粒度の高い LUNレベルのロッ

クによって最大限の柔軟性と最大限のセキュリティが可能になります。このアーキテクチャでベースとなる

共有リソース (LUN)は、プライマリquorumデバイスです。 quorumは、共有ストレージに対する排他的

なアクセスと定義できます。つまり、この共有ストレージは 1度に 1台のサーバからしかアクセスできませ

ん。 quorum (排他的アクセス)を持つサーバは、「プライマリ」の役割を持ちます。 quorumの確立 (排他

的アクセスをどのサーバに与えるか)は、「quorumデバイス」によって行われます。

上述の通り、リザベーションが有効の場合、quorumデバイスはその共有リソースです。共有リソースは、

共有リソースに対するリザベーションを持つサーバを判断して quorumを確立します。これにより、ある 1つのサーバがそのLUNにアクセスできる限り、クラスタは実質的には単一のサーバで運用されることにな

ります。

SCSI リザベーションは、共有のユーザデータを保護し、LifeKeeperが指定するシステムのみデータを変

更できるようにします。クラスタ内外の他のシステムがそのデータを変更することは許可されません。さらに

SCSI リザベーションによって、クラスタ内の複数のサーバで障害が起きた場合に、LifeKeeper保護下の

アプリケーションは共有のユーザデータに安全にアクセスできます。サーバの多数派 quorumは必要あり

ません。唯一の要件は、共有データの所有権の帰属が確立していることです。

quorum/witness機能を追加すると、 quorumのメンバーシップを確立することができます。このメンバーシ

ップがない場合、スプリットブレインの状況で複数のサーバ (場合によっては全サーバ)がお互いを終了さ

せることも考えられます。リザベーションが有効になっている構成にWatchdogを追加すると、部分的に

サーバがハングしている状態からリカバリするメカニズムが提供されます。ハングしたサーバがLifeKeeperに検出されないような場合に、Watchdogはリカバリを開始します。また、サーバがハングしてさらにリザ

ベーションが奪われた場合に、Watchdogはそのサーバをリブートしてリカバリを開始することができます。

144 設定

I/Oフェンシングのための代替方式

I/O フェンシングのための代替方式

SCSI リザベーションを利用したリソースフェンシングに加えて、LifeKeeper for Linuxはリザベーションの無

効化もサポートします。リザベーションが有効か無効にかかわらず、以下の2つの点に注意すべきです。

l ストレージへのアクセスは LifeKeeperが制御する必要があります。

l ストレージへの意図しないアクセス (ファイルシステムのマウント、手動の fsckなど)が発生しない

ように細心の注意を払う必要があります。

以上の2つのルールを順守してリザベーションを有効にすると、LifeKeeperはたいていのエラーを防止で

きます。リザベーションが (単独で)無効になった状態は、保護がない状態です。したがって、この保護を

実現するには、他の選択肢を検討する必要があります。以降のセクションでは、SCSI リザベーションな

しでも LifeKeeperで非常に信頼性の高い構成を実現できる各種のフェンシングオプションと代替方式

を説明します。

STONITHSTONITH (Shoot the Other Node in the Head)は、クラスタ内のノードの電源をリモートから切断するフ

ェンシング方式です。LifeKeeperのSTONITH機能は、外部電源スイッチコントロール、 IPMI対応マ

ザーボード、およびハイパーバイザーが提供する電源機能を利用してクラスタ内の他のノードの電源を

切断します。

STONITHで IPMI を使用する

IPMI (Intelligent Platform Management Interface)は、コンピュータシステムにアクセスする共通インター

フェースのセットを提供します。 IPMIを使用すると、システムの状態を監視してシステムを管理できま

す。 IPMIをSTONITHで使用すると、故障と思われるクラスタノードの電源スイッチをクラスタソフトウェア

が制御することにより、シリアル接続またはネットワーク接続を介してノードの電源切断やリブートができ

るため、故障ノードが共有データにアクセスしたりデータを破損するのを確実に防ぎます。


l IPMIツールのパッケージ (ipmitool-1.8.11-6.el6.x86_64.rpmなど)

VMware vSphere環境でのSTONITHvCLI (vSphere Command-Line Interface)は、ESXiホストと仮想マシンを含む仮想インフラストラクチャ

を管理するためのVMwareでサポートされているコマンドラインインターフェースです。vCLI コマンドがお

使いの環境のニーズに合致する場合は、VMwareの仮想マシン間でのLifeKeeper STONITHの実装

に適用することができます。


l VMware vSphere SDK Package (例 : VMware-vSphere-SDK-4.X.X-XXXXX.i386.tar.gz)

l VMware vSphere CLI (vSphere CLIは、vSphere SDK と同じインストールパッケージに含

まれています。)



(注記 : vmware-cmdを使用する場合のみ必要 )

l VMware Tools (例 : VMwareTools-8.3.7-341836.tar.gz)


LifeKeeperをインストールし、クラスタ内の各ノードでコミュニケーションパスを設定した後、STONITHを

インストールおよび設定します。

1. 次のコマンドを実行して LifeKeeper STONITHスクリプトをインストールします。

/opt/LifeKeeper/samples/STONITH/stonith-install

2. (*IPMIを利用する場合のみ) BIOSまたは ipmitoolコマンドを使用して、以下のBMC(BaseboardManagement Controller)変数を設定します。

l 静的 IPアドレスの使用

l IPアドレス

l サブネットマスク

l ユーザ名

l パスワード

l ユーザに管理者権限を追加

l ユーザのネットワークアクセスを有効化

ipmitoolコマンドの使用例を示します。

(詳細については、 ipmitoolのマニュアルページを参照してください。)

# ipmitool lan set 1 ipsrc static# ipmitool lan set 1 ipaddr 192.168.0.1# ipmitool lan set 1 netmask 255.0.0.0# ipmitool user set name 1 root# ipmitool user set password 1 secret# ipmitool user priv 1 4# ipmitool user enable 1

3. 設定ファイルを編集します。

設定ファイルを編集し、STONITHを有効にして電源を切断するコマンドラインを追加します。

注記 :フェンシングループ (2台のマシン間で、通信は喪失しているもののお互いをまだ

STONITHできる場合に、お互いに電源オフとリブートをし続ける状態 )を回避するため、リブー

トではなく電源オフを推奨します。

/opt/LifeKeeper/config/stonith.conf

146 設定

<vm_id>

# LifeKeeper STONITH configuration## Each system in the cluster is listed below. To enable STONITH for a# given system,# remove the '#' on that line and insert the STONITH command line to poweroff# that system.

# Example1: ipmi command

# node-1 ipmitool -I lanplus -H 10.0.0.1 -U root -P secret power off

# Example2: vCLI-esxcli command

# node-2 esxcli --server=10.0.0.1 --username=root --password=secret vms vmkill --type='hard' --world-id=1234567

# Example3: vCLI-vmware_cmd command

# node-3 vmware-cmd -H 10.0.0.1 -U root -P secret <vm_id> stop hard

minute-maid ipmitool -I lanplus -H 192.168.0.1 -U root -P secret power offkool-aid ipmitool -I lanplus -H 192.168.0.2 -U root -P secret power off

vm1 esxcli --server=10.0.0.1 --username=root --password=secret vms vm kill--type='hard' --world-id=1234567vm2 vmware-cmd -H 10.0.0.1 -U root -P secret <vm_id> stop hard

<vm_id>vSphere CLI コマンドは、vSphere SDK for Perlの上で実行されます。<vm_id>は、VMの識別子とし

て使用されています。この変数によって、設定対象のVM用の設定ファイルを指定します。

設定ファイルのパスを調べるには、以下の手順を実行します。

1. 次のコマンドを実行します。

vmware-cmd -H <vmware host> -l

2. 上記のコマンドによって VMwareホストのリストが表示されます。

vmware-cmd -lの出力例を以下に示します (3台のVMを表示 )。

/vmfs/volumes/4e08c1b9-d741c09c-1d3e-0019b9cb28be/lampserver/lampserver.vmx/vmfs/volumes/4e1e1386-0b862fae-a859-0019b9cb28bc/oracle10/oracle.vmx/vmfs/volumes/4e08c1b9-d741c09c-1d3e-0019b9cb28be/lampserver02/lampserver02.vmx

出力されたリストで設定中のVMを見つけます。

3. パス名を <vm_id>変数にペーストします。上記の例では以下の通りになります。


期待される動作

vmware-cmd -H 10.0.0.1 -U root -P secret /vmfs/volumes/4e08c1b9-d741c09c-1d3e-0019b9cb28be/lampserver/lampserver.vmx stop hard

注記 :VMwareコマンドの詳細については、引数なしで vmware-cmdを実行するとすべてのオプションに

関するヘルプページが表示されます。

期待される動作

LifeKeeperがノードとの通信障害を検出すると、そのノードの電源が切断され、フェイルオーバが発生

します。問題を修復した後に、手動でそのノードの電源を入れる必要があります。

WatchdogWatchdogは、サーバが正常に動作しない場合に、問題の発生を予防する修正処置 (リブート )を確

実に実行できるようにサーバを監視する方法です。 Watchdogは、特別な Watchdogハードウェアを使

用して実装する場合と、ソフトウェアのみのオプションを使用して実装する場合があります。

(注記 : この構成は、RedHat Enterprise Linux Versions 5および6でのみ検証されています。他のオペ

レーティングシステムでは検証されていないため、現時点ではサポートされません。)

コンポーネント

l Watchdogタイマのソフトウェアドライバまたは外部ハードウェアコンポーネント

l Watchdogデーモン -該当する Linuxディストリビューションを通じて rpmが入手可能

l LifeKeeper Coreデーモン - LifeKeeperのインストールに付随

l ヘルスチェックスクリプト - LifeKeeperの監視スクリプト

LifeKeeper とWatchdogの相互運用性

148 設定

設定

次のセクションを注意深く読んでください。デーモンは、エラーからリカバリするように設計されており、注

意深く設定しないとデーモンはシステムをリセットします。インストールおよび設定を行う前に慎重に計

画してください。このセクションの目的は、 Watchdogについての説明や設定をすることではありません。

ここでは、 Watchdog構成でのLifeKeeperとの相互運用についての説明や設定のみ行います。

設定

以下の手順は、rootユーザ権限を持つ管理者が行う必要があります。管理者は、 Watchdogのリスク

および問題についてすでに熟知しているものとします。

ヘルスチェックスクリプト (LifeKeeper監視スクリプト )は、LifeKeeperの設定とWatchdogの設定

(/opt/LifeKeeper/samples/watchdog/LifeKeeper-watchdog)を関連付けるコンポーネン

トです。このスクリプトは、LifeKeeperの完全な監視を提供するものであり、一切の修正は不要です。

1. 以前にWatchdogを設定していた場合は、次のコマンドを入力してWatchdogを停止します。

そうでない場合は、手順 2に進みます。/etc/rc.d/init.d/watchdog stop

Watchdogの停止を示す以下の確認メッセージが表示されるはずです。

Stopping watchdog:[OK]

2. Watchdogソフトウェアのインストールで供給されるWatchdog設定ファイル

(/etc/watchdog.conf)を編集します。l test-binaryを次のように修正します。

test-binary = /opt/LifeKeeper/samples/watchdog/LifeKeeper-

watchdog

l test-timeoutを次のように修正します。

test-timeout = 5

l intervalを次のように修正します。

interval = 7

intervalは、LifeKeeperのコミュニケーションパスのタイムアウト (15秒 )よりも小さい値にしてくださ

い。約半分の値が妥当です。

3. LifeKeeperが起動していることを確認します。まだの場合は、LifeKeeperの起動トピックを参照

してください。

4. 次のコマンドを入力してWatchdogを起動します。

/etc/rc.d/init.d/watchdog start

Watchdogの起動を示す以下の確認メッセージが表示されるはずです。

Starting watchdog: [OK]

5. 今後の再起動の際にWatchdogを自動的に起動させるには、次のコマンドを入力します。

chkconfig --levels 35 watchdog on


アンインストール

注記 : Watchdogを設定すると、予想外のリブートがときどき発生する可能性があります。これは、

Watchdogの仕組みから来る一般的な性質です。正常に応答しないプロセスがあると、 Watchdog機能は LifeKeeper (またはオペレーティングシステム)がハングしていると判断し、(警告なしに)システムをリ

ブートします。

アンインストール

LifeKeeperをアンインストールする場合は、慎重に行ってください。以下に列記の通り、上記の手順を

逆の順で実行します。

警告 : LifeKeeperを構成するRPMパッケージを削除する方法で LifeKeeperをアンインストールする場

合は、先にWatchdog を停止してください。上記の手順 2では、LifeKeeperのWatchdogスクリプトを

呼び出すようにWatchdog設定ファイルを修正しています。したがって、先にWatchdogを停止してお

かないと、存在しないスクリプトを呼び出すことになります。リブートを実行するこのスクリプトが見つから

ない場合は、エラーが発生します。この状態はWatchdogを停止するまで継続します。

1. 次のコマンドを入力してWatchdogを停止します。/etc/rc.d/init.d/watchdog stop

Watchdogの停止を示す以下の確認メッセージが表示されるはずです。

Stopping watchdog: [OK]

2. Watchdogソフトウェアのインストールで供給されるWatchdog設定ファイル

(/etc/watchdog.conf)を編集します。l test-binaryおよび intervalの両エントリをコメントアウトします (各行の先頭に #を追加します)。

#test-binary =

#interval =

(注記 : intervalが他の機能によって以前から使用されていた場合は、そのままにしておくこともで

きます)

3. LifeKeeperをアンインストールします。LifeKeeperの削除トピックを参照してください。4. これでWatchdogを起動し直すことができます。LifeKeeperのみがWatchdogを使用していた場

合は、次のコマンドを入力するとWatchdogを永続的に無効にできます。chkconfig --levels 35 watchdog off

リソースポリシー管理

概要

Steeleye Protection Suite for LinuxおよびSteeleye vAppKeeperのリソースポリシー管理では、リソース

のローカルリカバリとフェイルオーバ (または VMware HA との統合 )の動作管理機能が提供されます。リ

ソースポリシーは、 lkpolicyコマンドラインツール (CLI)を使用して管理できます。

Steeleye Protection Suite/vAppKeeperのリカバリ動作

Steeleye Protection Suite およびSteelEye vAppKeeperには、個々のアプリケーションおよび関連し合

うアプリケーションのグループを監視する機能があり、定期的にローカルリカバリを実行したり、保護下の

150 設定

ポリシーによるカスタム動作およびメンテナンスモード動作

アプリケーションに障害が発生したときに通知することができます。関連し合うアプリケーションの例として

は、主アプリケーションが下位のストレージまたはネットワークリソースに依存する階層などがあります。ア

プリケーションまたはリソースに障害が発生した場合のデフォルトの動作は以下の通りです。

1. ローカルリカバリ:最初に、リソースまたはアプリケーションのローカルでリカバリを試みます。このとき

は、外部の介入なしにローカルサーバ上でリソースまたはアプリケーションをリストアしようとしま

す。ローカルリカバリが成功した場合、Steeleye Protection Suite/vAppKeeperは追加のアクショ

ンを実行しません。

2. フェイルオーバ (または VMware HA との連携 ):次に、ローカルリカバリでリソースまたはアプリケー

ションのリストアに失敗した (またはリソースを監視するリカバリキットがローカルリカバリをサポートし

ていない)場合、フェイルオーバは開始されません。フェイルオーバは、以下の2つの異なる形態

を取ることができます。

l Steeleye Protection Suite for Linux: この構成 (高可用性クラスタで使用 )のフェイル

オーバ処理では、クラスタ内の別のサーバ上で該当アプリケーション (および依存するすべ

てのリソース)を起動しようと試みます。

l SteelEye vAppKeeper: この構成 (VMware環境のアプリケーション監視で使用 )のフェ

イルオーバ処理では、仮想マシン (VM)ゲストでアプリケーション障害が発生したことを

VMware HAに通知します。VMware HAの通常の反応は、警告なしに、問題を是正

するためにただちにVMゲストを再起動することです。場合によって VMware HAは、VMゲストを別のVMホストに移動したり別のアクションを実行したりすることもできま

す。VMware HAが状況を処理する方法は、SteelEye vAppKeepeの構成に依存しま

せん。

リカバリ動作の詳細については、SteelEye Protection Suiteの障害検出およびリカバリシナリオまたは

vAppKeeperの障害検出およびリカバリシナリオを参照してください。

ポリシーによるカスタム動作およびメンテナンスモード動作

Steeleye Protection Suite/vAppKeeper Version 7.5以降では、デフォルトのリカバリ動作を変更する追

加ポリシーを設定する機能をサポートします。リソース単位またはサーバ単位で、4つのポリシーが設定

可能です (リソース単位のポリシーに関する注意については下のセクションを参照してください)。サーバ

レベルでポリシーを変更する方法を推奨します。

利用可能なポリシーは以下の通りです。

標準ポリシー

l Failover(vAppKeeperの場合は、VMの再起動を開始するVMware HA との連携を利用しま

す)。このポリシー設定を使用すると、リソースフェイルオーバを有効 /無効にできます。(注記 : リザベーションが適切に処理されるには、フェイルオーバは、個々のSCSI リソースで無効にするこ

とはできません。)

l LocalRecovery - Steeleye Protection Suite/vAppKeeperは、デフォルトでは、フェイルオーバを

実行する前に、個々のリソースまたは保護対象アプリケーション全体を再起動することにより、

保護対象リソースのリカバリを試みます。このポリシー設定を使用すると、ローカルリカバリを有効

/無効にできます。

l TemporalRecovery -通常、Steeleye Protection Suiteは、障害リソースのローカルリカバリを実


メタポリシー

行します。ローカルリカバリに失敗すると、Steeleye Protection Suiteは、リソース階層を別ノード

にフェイルオーバします。ローカルリカバリに成功した場合は、フェイルオーバは実行されません。

ローカルリカバリに成功した場合でも、サーバの何らかの異常によって短時間の間にローカルリカ

バリが再試行される場合があり、結果として何度も連続してローカルリカバリが試行されることに

なります。これが発生すると、問題のアプリケーションは可用性が悪化します。

この反復的なローカルリカバリ /障害サイクルを回避するために、時間的リカバリポリシーを設定

できます。時間的リカバリポリシーを使用すると、管理者は指定した時間内に試行するローカル

リカバリの回数を (成功かどうかにかかわらず)制限することができます。

例 : リソースが試行するローカルリカバリの回数を 30分間で 3回に限定するポリシー定

義をユーザが設定した場合、30分以内に 3回目のローカルリカバリが試行される

と、Steeleye Protection Suiteはフェイルオーバを実行します。

定義した時間的リカバリポリシーは有効または無効にできます。時間的リカバリポリシーが無効

の場合、時間的リカバリ処理は継続して実行され、ポリシーが適用されるはずの時間に通知

がログに表示されますが、実際のアクションは実行されません。

注記 :時間的リカバリポリシーを設定した状態で、フェイルオーバとローカルリカバリの一方または

両方を無効にすることは可能です。フェイルオーバまたはローカルリカバリを無効にした場合に、

時間的リカバリポリシーは実行されることがないため、この状態は非論理的です。

メタポリシー

「メタ」ポリシーは、他の複数のポリシーに影響を与える可能性があるポリシーです。通常、これ

らのポリシーは、標準ポリシーであれば複数個の設定が必要になるような特定のシステム動作

を実現するためのショートカットとして使用します。

l NotificationOnly -このモードでは、管理者は Steeleye Protection Suiteまたは vAppKeeperを「監視専用」状態にすることができます。1つのリソース (または、サーバ単位のポリシーの場合

はすべてのリソース)のローカルリカバリおよびフェイルオーバの両方が影響を受けます。障害が検

知されると、ユーザインターフェースには Failure状態が表示されます。ただし、リカバリもフェイル

オーバも実行されません。注記 :管理者は、障害の原因となった問題を手動で修正し、障害

が起きたリソースを復帰させて通常のSteeleye Protection Suiteの運用を継続する必要があり

ます。

リソースレベルのポリシーに関する重要な考慮事項

リソースレベルのポリシーとは、リソース階層全体またはサーバレベルのポリシーとは異なり、特定のリ

ソースにのみ適用されるポリシーです。

例 :

アプリケーション

- IP - file system

上記のリソース階層では、アプリケーションは IP とファイルシステムの両方に依存しています。ポ

リシーは、特定のリソースのローカルリカバリまたはフェイルオーバを無効にするように設定できま

す。これは、例えば、 IP リソースのローカルリカバリが失敗し、 IP リソースのフェイルオーバが無効

に設定されていた場合、 IP リソースはフェイルオーバを実行せず、他のリソースのフェイルオーバも

152 設定

lkpolicyツール

発生させないことを意味します。ただし、ファイルシステムリソースのローカルリカバリが失敗し、ファ

イルシステムリソースのポリシーのフェイルオーバが無効化されていない場合、階層全体がフェイ

ルオーバを実行します。

注記 :重要事項として、リソースレベルのポリシーは設定対象の特定のリソースにのみ適用され

ることに注意してください。

上記は単純な例です。複雑な階層を構成することもできるため、リソースレベルのポリシーを設定する

ときは注意してください。

lkpolicyツール

lkpolicyツールは、Steeleye Protection Suite for Linuxまたは SteelEye vAppKeeperが稼働するサー

バのポリシーを管理 (参照、設定、削除 )するためのコマンドラインツールです。 lkpolicyは、ポリシーの

設定および修正、ポリシーの削除、利用可能なポリシーと現在の設定値の表示をサポートします。さ

らに、設定したポリシーは、有効または無効に設定できるため、リカバリ動作に影響を与えながらリソー

ス /サーバ設定を保持できます。

全体的な使用方法は次の通りです。

lkpolicy [--list-policies | --get-policies | --set-policy | --remove-policy] <name value pair data...>

<name value pair data...>は、運用方法および対象のポリシーによって異なります (特にポリシー

を設定する場合 )。例 :有効 /無効タイプのポリシーのほとんどでは、必要なのは [--on]または [--off]のスイッチのみですが、時間的ポリシーの場合は、しきい値を設定するための値も必要で

す。

lkpolicyの使用方法の例

ローカルおよびリモートサーバとの認証

lkpolicyツールは、サーバが公開するAPIを通じて Steeleye Protection Suiteおよび vAppKeeperサー

バと通信します。このAPIは、 lkpolicyツールなどのクライアントに対して認証を要求します。 lkpolicyツールで Steeleye Protection Suiteまたは vAppKeeperサーバに最初にアクセスしようとしたときに、その

サーバに対する認証情報がまだ保存されていない場合、ユーザは認証情報を求められます。認証情

報はユーザ名とパスワードの形式であり、さらに以下の条件があります。

1. クライアントには Steeleye Protection Suite/vAppKeeperの管理者権限が必要です。したがっ

て、そのユーザ名は、(PAMによる)オペレーティングシステムの認証設定によって lkadminグルー

プに属する必要があります。必ずしも rootで実行する必要はありませんが、rootユーザはデフォ

ルトで適切なグループに属しているため、rootを使用することもできます。

2. 認証情報は認証情報ストアに保存されるため、ツールを使用してこのサーバにアクセスするたび

に手動で認証情報を入力する必要はありません。

Steeleye Protection Suiteの認証情報の設定またはを参照してください。vAppKeeperの認証情報の

設定認証情報ストアおよび credstoreユーティリティを使用した管理についての詳細な情報が掲載さ

れています。

lkpolicyによるセッションの例は以下のようになります。

[root@thor49 ~]# lkpolicy -l -d v6test4


ポリシーのリスト表示

Please enter your credentials for the system 'v6test4'.

Username: root

Password:

Confirm password:

Failover

LocalRecovery

TemporalRecovery

NotificationOnly

[root@thor49 ~]# lkpolicy -l -d v6test4

Failover

LocalRecovery

TemporalRecovery

NotificationOnly

[root@thor49 ~]#

ポリシーのリスト表示

lkpolicy --list-policy-types

現在のポリシーの表示

lkpolicy --get-policies

lkpolicy --get-policies tag=\*

lkpolicy --get-policies --verbose tag=mysql\* # mysqlで始まるすべてのポリシー

lkpolicy --get-policies tag=mytagonly

ポリシーの設定

lkpolicy --set-policy Failover --off

lkpolicy --set-policy Failover --on tag=myresource

lkpolicy --set-policy Failover --on tag=\*

lkpolicy --set-policy LocalRecovery --off tag=myresource

lkpolicy --set-policy NotificationOnly --on

lkpolicy --set-policy TemporalRecovery --on recoverylimit=5 period=15

lkpolicy --set-policy TemporalRecovery --on --force recoverylimit=5 period=10

ポリシーの削除

lkpolicy --remove-policy Failover tag=steve

注記 :NotificationOnlyはポリシーのエイリアスです。NotificationOnlyを有効にすることは、対応する

LocalRecoveryおよびFailoverポリシーを無効にすることと等価です。

154 設定

認証情報の設定

認証情報の設定

他のシステムと通信するための認証情報は、認証情報ストアを使用して管理されています。このストア

は、必要に応じて /opt/LifeKeeper/bin/credstoreユーティリティで管理できます。このユーティ

リティを使用すると、サーバアクセスに必要な認証情報をサーバごとに設定、変更、削除することができ

ます。

認証情報の追加または変更

認証情報の追加と変更は同じ方法で実行できます。代表的な例として、サーバー

server.mydomain.comに対する資格情報を追加または変更する場合は次のようになります。

/opt/LifeKeeper/bin/credstore -k server.mydomain.commyuser

この例では、server.mydomain.comへのアクセスに使用するユーザ名としてmyuser を指定してしてい

ます。パスワードを入力 /確認するプロンプト (passwdの様に)が表示されます。

注記 : LifeKeeperサーバの認証情報を格納するために使用されるキー名は、 lkpolicyなどのコマンド

で使用するホスト名と完全に一致する必要があります。コマンドで使用するホスト名がFQDNであれ

ば、認証情報のキーも FQDNでなければなりません。コマンドで使用するホスト名がショートネームであ

れば、認証情報のキーもショートネームでなければなりません。

認証情報ストアにデフォルトキーを作成することもできます。サーバキーが存在しない場合にデフォルト

の認証情報が認証に使用されます。デフォルトキーを追加、変更するには以下のコマンドを実行してく

ださい。

/opt/LifeKeeper/bin/credstore -k default myuser

ストア内の認証情報のリスト表示

現在格納されている認証情報をリスト表示するには、以下のコマンドを実行します。

/opt/LifeKeeper/bin/credstore -l

これにより、認証情報ストア内に格納されているキーが表示されます。この場合の「キー」は、認証情

報を使用する対象のサーバを示しています (認証情報自体は秘密情報のため、このコマンドが表示す

るのは、実際の認証情報の内容ではなくキー名のみです)。

サーバの認証情報の削除

特定のサーバに対する認証情報を削除するには、以下のコマンドを実行します。

/opt/LifeKeeper/bin/credstore -d -k myserver.mydomain.com

この例では、サーバmyserver.mydomain.comに対する認証情報がストアから削除されます。

追加情報

credstoreユーティリティの詳細については、以下のコマンドを実行してください。


LifeKeeper API

/opt/LifeKeeper/bin/credstore --man

コマンドのマニュアルページがすべて表示されます。

LifeKeeper APILifeKeeper APIを使用すると、LifeKeeperサーバ間の通信を行えるようになります。

重要な注記 :現在、このAPI は内部使用のみに予約されていますが、将来のリリースでは、ユーザや

サードパーティが使用できるように開放される可能性があります。


LifeKeeperの各サーバは、ポート 778のSSL接続を使用してこのAPIを提供します。このポート

は、/etc/default/LifeKeeper内の設定変数 API_SSL_PORTを使用して変更できます。

認証

LifeKeeper APIは認証にPAMを使用します。APIへのアクセス権限は、グループ

lkadmin、lkoper、lkguestのメンバーであるユーザにのみ付与されます。ユーザに権限を与えるに

は、システムのPAM設定に応じて、ローカルシステムファイル (/etc/passwdおよび/etc/group)を使用す

るか、ユーザを LDAPまたは Active Directoryのグループに追加します。

注記 : LifeKeeper APIは、lkpasswdで管理されるユーザデータベースは使用しません。

156 設定

LifeKeeper管理

概要

LifeKeeperは操作時に管理を必要としません。LifeKeeperは、保護されたリソースを監視し、障害が

発生した場合に指定されたリカバリアクションを実行するように、自動的に機能します。以下のケース

では LifeKeeper GUIを使用します。

l リソースおよび階層の定義。LifeKeeperは次のインターフェースオプションを提供します。

l LifeKeeper GUI。

l LifeKeeperコマンドラインインターフェース。

l リソース監視。LifeKeeper GUIは、リソースステータス情報およびLifeKeeperログへのアクセスを

提供します。

l 手動での処理。メンテナンスやその他の管理アクションのために、サーバまたは特定のリソースを

停止することが必要になる場合があります。LifeKeeper GUIには、特定のリソースを稼動させた

り停止させることができるメニュー機能が用意されています。アプリケーションがLifeKeeperの保

護下に置かれると、これらのLifeKeeperのインターフェースを介してのみアプリケーションを起動お

よび停止させることができます。LifeKeeperの起動および停止は、コマンドラインを介してのみ行

われます。

LifeKeeperの管理、設定、およびメンテナンス操作を実行する詳細な手順については、GUIの作業

およびメンテナンス作業を参照してください。

エラーの検出および通知

アプリケーション内の問題を検出して通知する機能は、最適な総合的耐障害性ソリューションを構築

する上で非常に重要です。すべての個々のアプリケーションは、障害発生のメカニズムと形式によって

異なるため、一般的なメカニズムを示すことはできません。ただし、一般的に、多くのアプリケーションの

設定は、LifeKeeperに用意されているCoreシステムのエラー検出機能を利用することができます。リ

ソースエラー回復シナリオおよびサーバ障害回復シナリオの各トピックでは、共通する 2つの障害状況

を使用して、LifeKeeperのコア機能を示しています。

LifeKeeperには、エラー、アラーム、およびリカバリ手順を起動するイベントを定義するための完全な環

境も用意されています。このインターフェースは、通常、システムエラーログ用のパターンマッチ定義

(/var/log/messages)、またはカスタムビルドのアプリケーション固有の監視プロセスが必要になりま

す。

N-Way リカバリ

N-Way リカバリを使用すると、異なる複数のリソースを、クラスタ内の異なるバックアップサーバにフェイル


管理作業

オーバすることができます。

保護されたリソースに戻る

管理作業

サーバプロパティの編集

1. サーバプロパティを編集するには、サーバプロパティを表示する場合と同様に、 [ServerProperties]ダイアログを表示してください。

2. 該当のサーバに適切な権限でログインした場合は、次の項目が編集可能になります。

l シャットダウン方法

l フェイルオーバ確認

3. 変更が加えられると、[Apply]ボタンが有効になります。このボタンをクリックすると変更が適用さ

れます。ウィンドウは閉じられません。

4. 完了したら、[OK]をクリックし、変更内容を保存してウィンドウを閉じるか、または [Cancel]をク

リックして、変更内容を適用せずにウィンドウを閉じます。

コミュニケーションパスの作成

サーバ間のLifeKeeperコミュニケーションパスを設定する前に、ハードウェアおよびソフトウェアのセットアッ

プを検証します。詳細については、SPS for Linux リリースノートを参照してください。

サーバのペア間にコミュニケーションパスを作成するには、両方のサーバに個別にパスを定義する必要が

あります。LifeKeeperでは、サーバのペア間に TCP (TCP/IP)とTTYの両方のコミュニケーションパスを

作成することができます。TTYパスは、所定のペア間に 1つだけ作成できます。これに対し、TCPコミュ

ニケーションパスは、パスの終点となるローカルおよびリモートのアドレスを指定することで、サーバのペア

間に複数作成することができます。所定のリモートサーバへのTCPパスを使用する順序を LifeKeeperに設定するには、優先値を使用します。

重要 :単一のコミュニケーションパスを使用した場合、互いに通信するクラスタ内のサーバの機能に支

障をきたす可能性があります。単一のコミュニケーションパスを使用しているときに、そのコミュニケーショ

ンパスで障害が発生した場合、複数のサーバ上で同時に LifeKeeperの階層が使用可能になること

があります。これは、「偽のフェイルオーバ」と呼ばれます。また、TCPコミュニケーションパス上のネットワー

クトラフィックが大きくなると、偽のフェイルオーバやLifeKeeperの初期化の問題など、予期せぬ動作が

生じる可能性があります。

1. 開始するには、次の4つの方法があります。

l サーバアイコンを右クリックして、サーバコンテキストメニューが表示されたら [CreateComm Path]をクリックしてください。

l グローバルツールバーで、[Create Comm Path]ボタンをクリックしてください。

l サーバコンテキストツールバーで (表示された場合 )、[Create Comm Path]ボタンをクリッ

158 LifeKeeper管理の概要

コミュニケーションパスの作成

クしてください。

l [Edit] メニューで、[Server]、[Create Comm Path]の順に選択してください。

2. [Create Comm Path]というタイトルのダイアログが表示されます。表示されるオプションのそれぞ

れについて、[Help]をクリックすると、選択した項目の説明が表示されます。

3. リストボックスから [Local Server]を選択し、[Next]をクリックしてください。

4. リストボックスで 1つ以上の [Remote Servers]を選択してください。リストボックスにリモートサー

バが表示されていない (つまり、クラスタにまだ接続されていない)場合は、[Add]を使用して入

力してください。ローカルとリモートの両方のサーバに対するネットワークアドレスが解決可能であ

ることを確認する必要があります (たとえば、DNSで解決するか、 /etc/hosts ファイルに追加しま

す)。[Next]をクリックしてください。

5. [Device Type]に対して [TCP]または [TTY]を選択して、[Next]をクリックしてください。

6. [Device Type]が [TCP]に設定されている場合は、1つ以上の [Local IP Addresses]を選択

してください。[Device Type]が [TTY]に設定されている場合は、[Local TTY Device]を選択

してください。[Next]をクリックしてください。

7. [Device Type]が [TCP]に設定されている場合は、[Remote IP Address]を選択してくださ

い。[Device Type]が [TTY]に設定されている場合は、[Remote TTY Device]を選択してくだ

さい。 [Next]をクリックしてください。

8. [Device Type]が [TCP]に設定されている場合は、このコミュニケーションパスに対して

[Priority]を入力または選択してください。 [Device Type]が [TTY]に設定されいる場合は、こ

のコミュニケーションパスに対して [Baud Rate]を入力または選択してください。[Next]をクリック


9. [Create]をクリックしてください。ネットワーク接続が正常に作成されたことを示すメッセージが表

示されます。[Next]をクリックしてください。

10. 複数のローカル IPアドレスまたは複数のリモートサーバを選択したときに、[Device Type]が[TCP]に設定されている場合は、手順 6に戻り、次のコミュニケーションパスの設定を続けま

す。複数のリモートサーバを選択したときに、[Device Type]が [TTY]に設定されている場合

は、手順 5に戻り、次のコミュニケーションパスの設定を続けます。

11. 終了メッセージが表示されたら、[Done]をクリックしてください。

[Server Properties]ダイアログを表示するか、またはコマンド lcdstatus -qを入力することで、コミュ

ニケーションパスを確認することができます。lcdstatusの使用方法については、LCD(1M)マニュアル

ページを参照してください。[ALIVE] ステータスが表示されます。

さらに、GUIの右ペインのサーバアイコンをチェックしてください。これが、作成済みの1つ目のコミュニケー

ションパスである場合は、1つのコミュニケーションパスが [ALIVE]であるが、冗長コミュニケーションパスが

ないことを示す黄色のハートビートがサーバアイコンに表示されます。

[ALIVE] のコミュニケーションパスが 2つ以上ある場合は、緑色のハートビートがサーバアイコンに表示

されます。


コミュニケーションパスの削除

重要 : IPv6アドレスを使用してコミュニケーションパスを作成する場合は、自動設定 /ステートレスアドレ

スではなく、静的に割り当てられたアドレスを使用してください。自動設定 /ステートレスアドレスは、時

間がたつと変更され、コミュニケーションパスが使用できなくなる可能性があります。

数分たってもコミュニケーションパスが使用可能にならない場合は、ペアのサーバのコンピュータ名が正し

いことを確認してください。TTYコミュニケーションパスを使用している場合は、2つのサーバ間のケーブル

接続が正しく、緩んでいないことを確認してください。必要に応じて、portio(1M)コマンドを使用し

て、TTY接続の動作を確認してください。

コミュニケーションパスの削除

1. 開始するには、次の4つの方法があります。

l サーバアイコンを右クリックして、サーバコンテキストメニューが表示されたら [DeleteComm Path]をクリックしてください。

l グローバルツールバーで、[Delete Comm Path]ボタンをクリックしてください。

l サーバコンテキストツールバーで (表示された場合 )、[Delete Comm Path]ボタンをクリッ


l [Edit] メニューで、 [Server]、[Delete Comm Path]の順に選択してください。

2. [Delete Comm Path] というタイトルのダイアログが表示されます。表示されるオプションのそれぞれ

について、[Help]をクリックすると、選択した項目の説明が表示されます。

3. リストから [Local Server]を選択し、[Next]をクリックしてください。このダイアログが表示されるの

は、グローバルツールバー上の [Delete Comm Path]ボタンまたは [Server]ボタンを選択する

[Edit] メニューを使用して、削除を選択した場合のみです。

4. 削除するコミュニケーションパスを選択して、[Next]をクリックしてください。

5. [Delete Comm Path(s)]をクリックしてください。出力パネルが有効な場合、ダイアログが閉じ

て、コミュニケーションパスを削除するコマンドの結果が出力パネルに表示されます。有効でない

場合は、ダイアログが表示されたままこれらの結果が表示されます。すべての結果が表示された

ら、[Done]をクリックして終了します。ネットワーク接続が正常に削除されたことを示すメッセージ

が表示されます。

6. [Done]をクリックして、ダイアログを閉じ、GUIステータス表示に戻ってください。

サーバのプロパティ - フェイルオーバ

プライマリサーバがローカルリカバリを試行して失敗した場合、または完全に機能停止した場合、ほと

んどのサーバ管理者は、LifeKeeperで保護されたリソースをバックアップサーバにリストアすることが必要

になります。これがデフォルトのLifeKeeperの動作になります。ただし管理者によっては、保護されたリ

ソースをリカバリサイトで自動的に稼動するようにしたくない場合もあります。たとえば、ディザスタリカバリ

状況においてサーバ間のネットワーク接続の信頼性が低くなるような WAN環境に LifeKeeperがインス

トールされている場合です。

デフォルトでは、保護されたすべてのリソースに対して自動フェイルオーバが有効になっています。保護さ

れたリソースに対する自動フェイルオーバを無効にしたり、バックアップサーバへの自動フェイルオーバを行


サーバのプロパティ -フェイルオーバ

わないようにするには、 [Server Properties]の [General]タブにある [Failover]セクションを使用して、以

下の通り設定してください。

クラスタ内の各サーバで次のようにします。

1. サーバのプロパティを表示する場合と同様に、[Server Properties]ダイアログを表示してくださ

い。

2. [General]タブを選択してください。 [Server Properties]ダイアログの [Failover]セクションで、シス

テムおよびリソースのフェイルオーバ機能を無効にするサーバをチェックしてください。デフォルトで

は、LifeKeeperのすべてのフェイルオーバ機能が有効になっています。

[Disable System Failover]列で、ローカルサーバの完全な機能停止に対応するバックアップ

サーバとしての資格を喪失させるサーバを選択してください。

[Disable Resource Failover]列で、このローカルサーバ上でリソース階層に障害が発生した

場合に対応するバックアップサーバとしての資格を喪失させるサーバを選択してください。最初に

システムのフェイルオーバ機能を無効にしなければ、リソースのフェイルオーバを無効にすることは

できません。

選択内容を適用するには、[Apply]ボタンを押してください。


リソース階層の作成

リソース階層の作成

1. リソース階層の作成を開始するには、次の4つの方法があります。

l サーバアイコンを右クリックして、サーバコンテキストメニューが表示されたら、[CreateResource Hierarchy]をクリックしてください。

l グローバルツールバーで、[Create Resource Hierarchy]ボタンをクリックしてください。

l サーバコンテキストツールバーで (表示された場合 )、[Create Resource Hierarchy]ボタ

ンをクリックしてください。

l [Edit]メニューで、[Server]を選択して、[Create Resource Hierarchy]をクリックしてくだ

さい。

2. [Create ResourceWizard] というタイトルのダイアログが表示され、クラスタ内にインストールされ

ているすべての認識されたリカバリキットのリストが示されます。アプリケーションを保護するために

リソース階層を構築するRecovery Kitを選択して、 [Next]をクリックしてください。

3. [Switchback Type]を選択して、 [Next]をクリックしてください。

4. [Server]を選択して、 [Next]をクリックしてください。注記 :サーバコンテキストメニューから開始し

た場合、クリックしたサーバアイコンから自動的にサーバが決定されるので、この手順はスキップさ

れます。

5. 続いて表示されるダイアログを使用して、作成しているリソース階層の種類に必要なデータを

入力してください。

LifeKeeperアプリケーションリソース階層

LifeKeeperをリカバリキット無しでインストールした場合、デフォルトでは [Select Recovery Kit] リストに、

ファイルシステムまたはGeneric Application用のオプションが含まれています。Generic Applicationのオ

プションは、関連付けられたリカバリキットがないアプリケーションに使用できます。

Raw I/O Recovery Kitまたは IP Recovery Kit (これらは両方とも、別個にパッケージ化さ

れ、LifeKeeper Coreメディアに含まれているCore Recovery Kitです)をインストールした場合、 [SelectRecovery Kit] リストはこれらのRecovery Kitに対する追加のオプションを提供します。

これらの利用可能なオプションについては、以下のトピックを参照してください。

l ファイルシステムリソース階層の作成

l Generic Applicationリソース階層の作成

l Rawデバイスリソース階層の作成

IP Recovery Kitについては、 IP Recovery Kitテクニカルドキュメンテーションを参照してください。


Recovery Kitのオプション

Recovery Kitのオプション

インストールしたオプションの各リカバリキットは、 [Select Recovery Kit] リストにエントリを追加します。た

とえば、Oracle、Apache、およびNFSのRecovery Kitがリストに表示されます。必要なリソース階層を

作成する手順については、各リカバリキットに付属の管理ガイドを参照してください。

注記 : ファイルシステムまたは論理ボリューム上に構築されるその他のアプリケーションリソース階層を作

成する場合、最初に Logical VolumeManager (LVM) Recovery Kitをインストールする必要がありま

す。

ファイルシステムリソース階層の作成

このオプションは、ファイルシステムのみを保護する場合 (たとえば、保護を必要とする共有ファイルがあ

る場合 )に使用します。

1. ファイルシステムリソース階層の作成を開始するには、次の4つの方法があります。





l [Edit] メニューで、[Server]を選択して、[Create Resource Hierarchy]をクリックしてくだ

さい。

2. [Create ResourceWizard] というタイトルのダイアログが表示され、[Recovery Kit]リストが示さ

れます。 [File System Resource]を選択して、[Next]をクリックしてください。

3. [Switchback Type]を選択して、 [Next]をクリックしてください。

4. [Server]を選択して、[Next]をクリックしてください。注意 :サーバコンテキストメニューから開始し


れます。

5. [Create gen/filesys Resource]ダイアログが表示されます。ファイルシステムリソース階層に対し

て [Mount Point]を選択し、[Next]をクリックしてください。選択したマウントポイントが、クラスタ

内の別のサーバと共有されていることを確認するには、各ストレージキットをチェックして、マウント

されたデバイスを共有として認識しているかどうかを確認します。ストレージキットがマウントされた

デバイスを認識していない場合は、次のエラーダイアログが表示されます。

<file system> is not a shared file system

[OK]を選択すると、 [Create gen/filsys Resource] ダイアログに戻ります。

注記 :

l マウントポイントを選択リストに表示するには、そのマウントポイントがマウントされ

ている必要があります。マウントポイントに対するエントリが/etc/fstabファイル

に存在する場合、階層の作成および拡張時にこのエントリが削除されま


Generic Applicationリソース階層の作成

す。NAS Recovery Kitを使用する前に (特にマウント設定が複雑な場

合 )、/etc/fstabのバックアップを作成することをお勧めしま

す。/etc/default/LifeKeeperで調整可能な

REPLACEFSTAB=true|TRUEを設定することにより、/etc/fstabのエントリが

削除されても、元に戻すように指定することができます。

l これらのリソースの多く (SteelEye DataKeeper、LVM、DeviceMapper Multipathなど)は、ファイルシステムリソースを作成するために、クラスタ内の各サーバで

LifeKeeperリカバリキットを必要とします。これらのキットが適切にインストールされ

ていない場合、クラスタ内で共有されるファイルシステムが表示されません。

6. ファイルシステムリソース階層に対するデフォルトの [Root Tag]が作成されます。(これは、ステー

タス表示でこのリソースに使用されるラベルです)。このルートタグを選択するか、独自のルートタグ

を作成して、 [Next]をクリックしてください。

7. [Create Instance]をクリックしてください。インスタンス作成のステータスを示すメッセージが、ウィン

ドウに表示されます。

8. [Next]をクリックしてください。ファイルシステム階層が正常に作成されたというメッセージが、ウィン

ドウに表示されます。

9. この時点で、ファイルシステムリソース階層の拡張に移動するには [Continue]をクリックし、GUIに戻るには [Cancel]をクリックします。[Cancel]をクリックすると、階層が1つのサーバにしか存在

しないという警告メッセージが表示され、この時点で保護されなくなります。

Generic Application リソース階層の作成

このオプションは、関連付けられたリカバリキットがないユーザ定義のアプリケーションを保護する場合に

使用します。下記のユーザ指定スクリプトに対するテンプレート

は、$LKROOT/lkadm/subsys/gen/app/templatesに用意されています。これらのテンプレート

は、保護するアプリケーション用にカスタマイズしてテストする前に、別のディレクトリにコピーしてください。

注記 : ファイルシステム、ディスクパーティション、 IPアドレスなどの他のリソースに依存するアプリケーション

については、これらの各リソースを個別に作成し、Create Dependencyを使用して適切な依存関係を

作成してください。

1. Generic Applicationリソース階層の作成を開始するには、次の4つの方法があります。


l グローバルツールバーで、 [Create Resource Hierarchy]ボタンをクリックしてください。




さい。


れます。Generic Applicationを選択して、[Next]をクリックしてください。

3. [Switchback Type]を選択して、[Next]をクリックしてください。


Rawデバイスリソース階層の作成

4. [Server]を選択して、[Next]をクリックしてください。注記 :サーバコンテキストメニューから開始し


れます。

5. 次のダイアログで、アプリケーションに対する [Restore Script]へのパスを入力し、[Next]をクリッ

クしてください。これは、アプリケーションを起動するコマンドです。テンプレートディレクトリに、テン

プレート起動スクリプト restore.templateが用意されています。この restoreスクリプトが、既に起

動されているアプリケーションに影響を与えてはなりません。

6. アプリケーションに対する [Remove Script]へのパスを入力し、[Next]をクリックしてください。これ

は、アプリケーションを停止するコマンドです。テンプレートディレクトリに、テンプレート停止スクリプ

ト remove.templateが用意されています。

7. アプリケーションに対する [quickCheck Script]へのパスを入力し、[Next]をクリックしてください。

これは、アプリケーションを監視するコマンドです。テンプレートディレクトリに、テンプレート監視ス

クリプト remove.templateが用意されています。

8. アプリケーションに対する [Local Recovery Script]へのパスを入力し、[Next]をクリックしてくださ

い。これは、ローカルサーバ上の障害が発生したアプリケーションの復元を試みるコマンドです。テ

ンプレートディレクトリに、テンプレート回復スクリプト recover.templateが用意されています。

9. [Application Information]を入力し、[Next]をクリックしてください。これは、起動、停止、回

復、監視の各スクリプトで必要になる可能性のあるアプリケーションに関するオプションの情報で

す。

10. [Bring Resource In Service]に対して [Yes]または [No]を選択し、[Next]をクリックしてくださ

い。 [No]を選択すると、リソース状態が作成後にOSUに設定されます。 [Yes]を選択すると、

あらかじめ用意された restoreスクリプトが実行されます。ファイルシステム、ディスクパーティショ

ン、 IPアドレスなどの他のリソースに依存するアプリケーションについては、適切な依存リソースを

まだ作成していない場合には、 [No]を選択してください。

11. [Root Tag]を入力してください。これは、リソースインスタンスに対する一意の名前です。(これ

は、ステータス表示でこのリソースに対して表示されるラベルです。)

12. [Create Instance]をクリックして、作成プロセスを起動してください。インスタンス作成のステータ

スを示すメッセージが、ウィンドウに表示されます。

13. [Next]をクリックしてください。階層が正常に作成されたというメッセージが、ウィンドウに表示され

ます。

14. この時点で、Generic Applicationリソース階層の拡張に移動するには [Continue]をクリック

し、GUIに戻るには [Cancel]をクリックします。 [Cancel]をクリックすると、階層が1つのサーバに

しか存在しないという警告が表示され、この時点で保護されなくなります。

Raw デバイスリソース階層の作成

このオプションは、Rawデバイスリソースを保護する場合に使用します。たとえば、既存のデータベース

階層に追加する必要があるRawデバイスに対して追加のテーブルスペースを作成する場合、このオプ

ションを使用して Rawデバイスリソースを作成します。

注記 : LifeKeeperでは、ディスク論理ユニット (または LUN)レベルのディスクパーティションリソースを、一

度に 1つのクラスタの1つのシステムにロックします。


リソースのプロパティの編集

1. Rawデバイスリソース階層の作成を開始するには、次の4つの方法があります。






さい。


れます。Rawデバイスを選択して、[Next]をクリックしてください。


4. [Server]を選択して、[Next]をクリックしてください。

注記 :サーバコンテキストメニューから開始した場合、クリックしたサーバアイコンから自動的に

サーバが決定されるので、この手順はスキップされます。

5. このリソースが配置される共有ストレージデバイスで [Raw Partition]を選択して、[Next]をクリッ


6. [Root Tag]を入力してください。これは、リソースインスタンスに対する一意の名前です。(これ

は、ステータス表示でこのリソースに対して表示されるラベルです。)

7. [Create Instance]をクリックして、作成プロセスを起動してください。作成中に何が発生したか

を示すテキストが、 [Creating scsi/raw resource] というタイトルのウィンドウに表示されます。

8. [Next]をクリックしてください。階層が正常に作成されたというメッセージが、ウィンドウに表示され

ます。

9. この時点で、Raw リソース階層の拡張に移動するには [Continue]をクリックし、GUIに戻るに

は [Cancel]をクリックします。 [Cancel]をクリックすると、階層が1つのサーバにしか存在しないと

いうことを警告するメッセージが表示され、この時点で保護されなくなります。

リソースのプロパティの編集

1. リソースのプロパティを編集するには、リソースのプロパティを表示する場合と同様に、 [ResourceProperties]ダイアログを表示してください。

2. 該当のサーバに適切な権限でログインした場合は、次の項目が編集可能になります。

l スイッチバック

l リソース設定 (特殊な設定を持つリソースの場合のみ)

l リソースの優先順位

3. 変更が加えられると、[Apply]ボタンが有効になります。このボタンをクリックすると変更が適用さ

れます。ウィンドウは閉じられません。

4. 完了したら、[OK]をクリックし、変更内容を保存してウィンドウを閉じるか、または [Cancel]をク


リソースの優先順位の編集

リックして、変更内容を適用せずにウィンドウを閉じます。

リソースの優先順位の編集

リソース階層が定義されているサーバの優先順位は、編集または変更することができます。最初に、リ

ソースのプロパティを表示する場合と同様に、Resource Propertiesダイアログを表示してください。下に

示すようにResource Propertiesダイアログの [Equivalencies] タブに、サーバ上の特定のリソースに対す

る優先順位が表示されます。

優先順位を変更するには、次の2つの方法があります。

l [Up]/[Down]ボタンを使用してイクイバレンシを移動することにより、優先順位を変更してくださ

い。または

l 優先順位の値を直接編集してください。


[Up]および [Down]ボタンの使用

[Up]および [Down]ボタンの使用

1. Equivalencies表で行をクリックして、イクイバレンシを選択してください。選択したイクイバレンシ

に応じて、[Up]または [Down]ボタンが有効になります。最も優先順位が高いサーバを選択し

た場合以外は、[Up]ボタンが有効になります。最も優先順位が低いサーバを選択した場合以

外は、[Down]ボタンが有効になります。

2. [Up]または [Down]をクリックして、優先順位リストのイクイバレンシを移動してください。

数値の優先順位の列は変更されませんが、イクイバレンシがリスト内で上下に移動します。

優先順位の値の編集

1. Equivalencies表のPriority列で優先順位の値をクリックすることにより、優先順位を選択してく

ださい。優先順位の値の周りにボックスが表示され、値が強調表示されます。

2. 必要な優先順位を入力して、Enterを押してください。

l 注記 :有効なサーバの優先順位は、1～ 999です。優先順位を編集した後、Equivalencies表が再ソートされます。

変更の適用

Equivalencies表で必要な優先順位を設定したら、[Apply] (または [OK])をクリックして変更を適用

します。[Apply]ボタンをクリックすると、加えられた変更内容が適用されます。[OK]ボタンをクリックする

と、加えられた変更内容が適用され、ウィンドウが閉じられます。[Cancel]ボタンをクリックする

と、[Apply]が直前にクリックされているので、加えられた変更内容を保存せずにウィンドウが閉じられま

す。

リソース階層の拡張

LifeKeeperの [Extend Resource Hierarchy]オプションは、あるサーバから既存の階層をコピーして、

別のLifeKeeperサーバ上に同様の階層を作成します。階層が他のサーバに拡張されると、そのリソー

スに対してカスケーディングフェイルオーバが使用可能になります。既存の階層が現在存在するサーバ

は、テンプレートサーバと呼ばれます。新たに拡張された階層が配置されるサーバは、ターゲットサーバと

呼ばれます。

ターゲットサーバは、拡張された階層をサポートすることができ、他のリモートサーバ上の同等の階層と (アクティブな LifeKeeperコミュニケーションパスを介して)通信できなければなりません。つまり、既存の階

層内のリソースに関連付けられているすべてのリカバリキットが、ターゲットサーバだけでなく、階層が現

在存在する他のすべてのサーバに既にインストールされている必要があります。

1. GUIを介してリソース階層を拡張するには、次の5つの方法があります。

l 新しいリソース階層を作成してください。階層が作成されたことがダイアログに表示された

ら、[Continue]ボタンをクリックして、Pre-ExtendWizardを介して新しい階層の拡張を

開始してください。

l グローバルまたはサーバ固有のリソースアイコンを右クリックして、リソースコンテキストメニ

ューを表示し、次に [Extend Resource Hierarchy]をクリックして、Pre-ExtendWizardを


ファイルシステムリソース階層の拡張

介して選択したリソースを拡張してください。

l グローバルツールバーで、[Extend Resource Hierarchy]ボタンをクリックしてくださ

い。 [Pre-ExtendWizard]ダイアログが表示されたら、[Template Server]および [Tag toExtend]を選択し、それぞれ選択した後に [Next]をクリックしてください。

l リソースコンテキストツールバーで (表示された場合 )、[Extend Resource Hierarchy]ボタンをクリックして、Pre-ExtendWizardを表示してください。

l [Edit] メニューで、[Resource]を選択して、[Extend Resource Hierarchy]をクリックして

ください。 [Pre-ExtendWizard]ダイアログが表示されたら、[Template Server]および

[Tag to Extend]を選択し、それぞれ選択した後に [Next]をクリックしてください。

2. デフォルトの [Target Server]を選択するか、または選択リストの中から 1つ入力して、[Next]をクリックしてください。


4. デフォルト値を選択するか、または独自の [Template Priority]を入力して、[Next]をクリックし

てください。

5. 独自の [Target Priority]を選択するか入力して、[Next]をクリックしてください。

6. ダイアログに、次に実行される拡張前のチェックが表示されます。これらのテストが成功した場

合、LifeKeeperは、拡張している特定の種類のリソースに必要な手順の実行を開始します。

[Extend Resource Hierarchy]オプションの [Accept Defaults]ボタンは、LifeKeeperの [ExtendResource Hierarchy]のデフォルト値を熟知して、値の入力や確認をしないで素早くLifeKeeperリソース階層を拡張したいユーザ向けです。GUIダイアログを使用して対話的に段階を追って

LifeKeeperリソース階層を拡張する場合は、[Next]ボタンを選択します。

注記 :マルチルート階層のすべてのルートは、まとめて拡張する必要があります。つまり、単一ルート階

層として拡張することはできません。

注記 : コマンドラインによる手順については、SAP ドキュメントのコマンドラインからのSAP リソースの拡

張を参照してください。

ファイルシステムリソース階層の拡張

この操作は、リソース階層の拡張に関するセクションで説明されているように、ファイルシステムリソース

階層の作成を完了した後に自動的に開始したり、既存のファイルシステムリソースから開始することが

できます。それが済んだら、次に以下の手順を完了します。これらの手順は、ファイルシステムリソースに

固有のものです。

1. [Extend gen/filesys Resource Hierarchy]ダイアログボックスが表示されます。ファイルシステム階

層に対して [Mount Point]を選択し、[Next]をクリックしてください。

2. LifeKeeperが提供する [Root Tag]を選択するか、またはターゲットサーバ上のリソース階層に

対する独自のタグを入力して、[Next]をクリックしてください。

3. ダイアログに拡張操作のステータスが表示され、階層が正常に拡張されたことを示すメッセージ

が表示されて終了します。同じリソース階層を別のサーバに拡張する場合は、[Next Server]をクリックしてください。その場合は、拡張の操作が繰り返されます。または、[Finish]をクリックし

て、この操作を完了してください。


Generic Applicationリソース階層の拡張

4. 拡張された階層が検証されると、確認情報がダイアログに表示されます。これが終了する

と、[Done]ボタンが有効になります。[Done]をクリックして終了してください。

Generic Application リソース階層の拡張

この操作は、リソース階層の拡張に関するセクションで説明されているように、Generic Applicationリソース階層の作成を終了した後に自動的に開始したり、既存のGeneric Applicationリソースから開

始することができます。それが済んだら、次に以下の手順を完了します。これらの手順は、GenericApplicationリソースに固有のものです。



2. 次に [Application Information] (オプション)を入力し、[Next]をクリックしてください。




4. 拡張された階層が確認されると、確認情報がダイアログに表示されます。これが終了する


Raw デバイスリソース階層の拡張

この操作は、リソース階層の拡張に関するセクションで説明されているように、Rawデバイスリソース階

層の作成を終了した後に自動的に開始したり、既存のRawデバイスリソースから開始することができ

ます。それが済んだら、次に以下の手順を完了します。これらの手順は、Rawデバイスリソースに固有

のものです。






3. 拡張された階層が検証されると、確認情報がダイアログに表示されます。これが終了する


階層の拡張解除

LifeKeeperの [Unextend Resource Hierarchy]オプションは、単一サーバから階層全体 (すべてのリ

ソースを含む)を削除します。これは、すべてのサーバから 1つの階層を削除する [Delete ResourceHierarchy]選択項目とは異なります。

[Unextend Resource Hierarchy]を使用する場合、既存の階層を削除するサーバは、ターゲットサー

バと呼ばれます。


リソース依存関係の作成

[Unextend Resource Hierarchy]選択項目は、ターゲットへのアクティブな LifeKeeperコミュニケーショ

ンパスを持つ LifeKeeperサーバから使用することができます。

1. 開始するには、次の5つの可能な方法があります。

l 拡張解除したいリソース階層 /サーバの組み合わせに対するアイコンを右クリックしてくださ

い。リソースコンテキストメニューが表示されたら、 [Unextend Resource Hierarchy]をク

リックしてください。

l 拡張解除したいグローバルリソース階層のアイコンを右クリックしてください。リソースコンテ

キストメニューが表示されたら、 [Unextend Resource Hierarchy]をクリックしてください。

ダイアログが表示されたら、リソース階層の拡張を解除するサーバを [Target Server]リストで選択し、[Next]をクリックしてください。

l グローバルツールバーで、[Unextend Resource Hierarchy]ボタンをクリックしてください。

ダイアログが表示されたら、リソース階層の拡張を解除するサーバを [Target Server]リストで選択し、[Next]をクリックしてください。次のダイアログで、[Hierarchy to Unextend]リストから拡張解除したいリソース階層を選択し、再度 [Next]をクリックしてください。

l リソースコンテキストツールバーで (表示された場合 )、[Unextend Resource Hierarchy]ボタンをクリックしてください。

l [Edit] メニューで、[Resource]をポイントして、[Unextend Resource Hierarchy]をクリッ

クしてください。ダイアログが表示されたら、リソース階層の拡張を解除するサーバを

[Target Server]リストで選択し、[Next]をクリックしてください。次のダイアログ

で、[Hierarchy to Unextend]リストから拡張解除したいリソース階層を選択し、再度

[Next]をクリックしてください。

2. 拡張解除するように指定したサーバおよびリソース階層を確認するメッセージが、ダイアログに表

示されます。[Unextend]をクリックしてアクションを実行してください。

3. 出力パネルが有効な場合、ダイアログが閉じて、リソース階層の拡張を解除するコマンドの結

果が出力パネルに表示されます。有効でない場合は、ダイアログが表示されたままこれらの結

果が表示されます。すべての結果が表示されたら、[Done]をクリックして終了します。

リソース依存関係の作成

ほとんどのRecovery Kitsでは、元のリソース階層作成タスク中にそれらの依存関係が作成されます

が、特定の条件下では、新規または追加のリソース依存関係を作成したり、既存のリソース依存関

係を削除することが必要になる場合があります。一例として、既存の IP依存関係を別の IPアドレス

に変更する場合が挙げられます。リソース階層全体を削除して、新しいリソース階層を作成する代わ

りに、既存の IP依存関係を削除して、異なる IPアドレスを持つ新しい依存関係を作成することがで

きます。


l 親子依存関係を追加したい、サーバの下の親サーバ固有のリソース、または親グローバ

ルリソースに対するアイコンを右クリックしてください。リソースコンテキストメニューが表示さ

れたら、 [Create Dependency]をクリックしてください。


リソース依存関係の削除

注記 :右ペインでサーバ固有のリソースを右クリックした場合、[Server]の値はそのサーバ

になります。左ペインでグローバルリソースを右クリックした場合、[Server]の値は、リソー

スが最も高い優先度を持つサーバになります。

l グローバルツールバーで、[Create Dependency]ボタンをクリックしてください。ダイアログが

表示されたら、リソース依存関係の作成を開始するサーバを [Server]リストで選択

し、[Next]をクリックしてください。次のダイアログで、[Parent Resource Tag]リストから親

リソースを選択し、再度 [Next]をクリックしてください。

l リソースコンテキストツールバーで (表示された場合 )、[Create Dependency]ボタンをクリ

ックしてください。

l [Edit] メニューで、[Resource]をポイントして、[Create Dependency]をクリックしてくださ

い。ダイアログが表示されたら、リソース依存関係の作成を開始するサーバを [Server]リストで選択し、[Next]をクリックしてください。次のダイアログで、[Parent Resource Tag]リストから親リソースを選択し、再度 [Next]をクリックしてください。

2. サーバ上の既存の有効なリソースのドロップダウンボックスから、[Child Resource Tag]を選択

してください。以下の例外を持つサーバ上で利用可能なすべてのリソースが、ダイアログに表示

されます。

l 親リソース、その先祖、およびその子。

l 親リソースと同じサーバに拡張されていないリソース。

l 親リソースと同じ相対優先度を持たないリソース。

l 親リソースが稼働中の場合に、親と同じサーバ上で稼働していないリソース。

[Next]をクリックして、次のダイアログに進んでください。

3. このダイアログで、依存関係の作成に対して適切な親および子のリソースタグが選択されている

ことを確認できます。[Create Dependency]をクリックして、親を拡張したクラスタ内のすべての

サーバで依存関係を作成してください。

4. 出力パネルが有効な場合、ダイアログが閉じて、依存関係を作成するコマンドの結果が出力

パネルに表示されます。有効でない場合は、ダイアログが表示されたままこれらの結果が表示さ

れます。すべての結果が表示されたら、[Done]をクリックして終了します。

リソース依存関係の削除


l 親子依存関係を削除したい、サーバの下の親サーバ固有のリソース、または親グローバ

ルリソースに対するアイコンを右クリックしてください。リソースコンテキストメニューが表示さ

れたら、 [Delete Dependency]をクリックしてください。

l グローバルツールバーで、[Delete Dependency]ボタンをクリックしてください。ダイアログが

表示されたら、リソース依存関係の削除を開始するサーバを [Server]リストで選択

し、[Next]をクリックしてください。次のダイアログで、[Parent Resource Tag]リストから親

リソースを選択し、再度 [Next]をクリックしてください。

l リソースコンテキストツールバーで (表示された場合 )、[Delete Dependency]ボタンをクリ


すべてのサーバからの階層の削除

ックしてください。

l [Edit] メニューで、[Resource]をポイントして、[Delete Dependency]をクリックしてくださ

い。ダイアログが表示されたら、リソース依存関係の削除を開始するサーバを [Server]リストで選択し、[Next]をクリックしてください。次のダイアログで、[Parent Resource Tag]リストから親リソースを選択し、再度 [Next]をクリックしてください。

2. ドロップダウンボックスから [Child Resource Tag]を選択してください。これは、削除したい依存

関係における子のタグ名である必要があります。[Next]をクリックして、次のダイアログボックスに

進んでください。

3. このダイアログで、依存関係の削除に対して適切な親および子のリソースタグが選択されている

ことを確認できます。[Delete Dependency]をクリックして、クラスタ内のすべてのサーバ上の依

存関係を削除してください。

4. 出力パネルが有効な場合、ダイアログが閉じて、依存関係を削除するコマンドの結果が出力

パネルに表示されます。有効でない場合は、ダイアログが表示されたままこれらの結果が表示さ

れます。すべての結果が表示されたら、 [Done]をクリックして終了します。

すべてのサーバからの階層の削除


l 削除を開始するサーバの下の、削除したい階層にあるリソースのアイコンを右クリックして

ください。リソースコンテキストメニューが表示されたら、 [Delete Resource Hierarchy]をクリックしてください。

l 削除したい階層にあるグローバルリソースのアイコンを右クリックしてください。リソースコン

テキストメニューが表示されたら、 [Delete Resource Hierarchy]をクリックしてください。

ダイアログが表示されたら、リソース階層の削除を開始するサーバを [Server]リストで選

択し、[Next]をクリックしてください。

l グローバルツールバーで、[Delete Resource Hierarchy]ボタンをクリックしてください。ダイ

アログが表示されたら、リソース階層の削除を開始するサーバを [Target Server]リストで

選択し、[Next]をクリックしてください。次のダイアログで、[Hierarchy to Delete]リストか

ら削除したい階層内のリソースを選択し、再度 [Next]をクリックしてください。

l プロパティパネルのリソースコンテキストツールバーで (表示された場合 )、[DeleteResource Hierarchy]ボタンをクリックしてください。

l [Edit] メニューで、[Resource]をポイントして、[Delete Resource Hierarchy]をクリックし

てください。ダイアログが表示されたら、リソース階層の削除を開始するサーバを [TargetServer]リストで選択し、[Next]をクリックしてください。次のダイアログで、[Hierarchy toDelete]リストから削除したい階層内のリソースを選択し、再度 [Next]をクリックしてくだ

さい。

2. 削除するために指定した階層を確認するメッセージが、ダイアログに表示されます。[Delete]をク

リックしてアクションを実行してください。

3. 出力パネルが有効な場合、ダイアログが閉じて、階層を削除するコマンドの結果が出力パネル

に表示されます。有効でない場合は、ダイアログが表示されたままこれらの結果が表示されま

す。すべての結果が表示されたら、[Done]をクリックして終了します。


LifeKeeper User GuideUser Guideは、検索可能な総合リソースで、LifeKeeperのGUIで実行できる多くの作業の詳細情

報があります。このドキュメントにアクセスするには、User Guideをクリックしてください。

GUIから実行できる作業は 3つの分野に分類できます。

共通の作業 -これらはどのユーザでも実行できる基本的な作業で、クラスタへの接続、サーバやリソー

スのプロパティの表示、ログファイルの表示、GUIの設定の変更などがあります。

オペレータの作業 -これらはオペレータの権限を必要とする高度な作業で、リソースをサービス中やサー

ビス停止にする操作などがあります。

管理者の作業 -これらは、管理者の権限を必要とする作業です。サーバのプロパティの編集、リソース

の作成、通信パスの作成や削除などのサーバレベルの作業、およびリソースの編集、拡張、削除など

のリソースレベルの作業があります。

以下の表に、それぞれのユーザ権限で使用できるデフォルトの作業を示します。特定のリソースタイプ

についてその他の作業が使用できることがあります。これらの作業については、関連するリソースキットの

ドキュメントで説明しています。

作業権限

ゲストオペレータ管理者

サーバとリソースの表示 ○ ○ ○

サーバへの接続と切断 ○ ○ ○

サーバのプロパティとログの表示 ○ ○ ○

サーバのプロパティの変更 ○

リソース階層の作成 ○

通信パスの作成と削除 ○

リソースのプロパティの表示 ○ ○ ○

リソースのプロパティの変更 ○

リソースのサービス中とサービス休止の切り替え ○ ○

リソース階層の拡張と拡張解除 ○

リソースの依存関係の作成と削除 ○

リソース階層の削除 ○


LifeKeeper for Linuxの使用

LifeKeeper for Linux の使用

以下のトピックでは、LifeKeeperのグラフィカルユーザインターフェース (GUI)、およびLifeKeeperのGUIから実行できる多数の作業について詳しく説明しています。

GUIGUIのコンポーネントは、LifeKeeper Coreのインストールの一部として、すでにインストールされていま

す。

LifeKeeperのGUIは、Javaテクノロジを使用して、LifeKeeperおよびその設定データ用にグラフィカル

ユーザインターフェースを提供します。LifeKeeperのGUIはクライアント /サーバアプリケーションなので、

ユーザはクライアントシステムでグラフィカルユーザインターフェースを実行して、LifeKeeperが動作中の

サーバシステムの監視や管理を行います。クライアントとサーバのコンポーネントは、同一システム上にあ

る場合も、ない場合もあります。

GUI の概要 - 全般

クラスタマシンの必要なグループメンバシップをユーザが持っている限り、GUIを使用することで、任意の

マシンから、任意のクラスタ内のサーバとリソースの管理、操作、または監視ができます (詳細について

は、GUIのユーザの設定を参照 )。GUIのサーバとクライアントのコンポーネントについて説明します。

GUIサーバ

デフォルトでは、システムの起動時に、各 LifeKeeperサーバ上にあるGUIサーバは初期化されませ

ん。GUIサーバは、ハイパーテキスト転送プロトコル (HTTP)とリモートメソッド呼び出し (RMI)を使用し

てGUI クライアントと通信します。デフォルトでは、GUIサーバは LifeKeeperの起動時に初期化されま

せんが、コアのLifeKeeperのプロセスで起動するように設定できます。GUIサーバの開始 /停止を参照


GUI クライアント

GUI クライアントは、任意のLifeKeeperサーバ上のアプリケーションとして、または Javaが有効な任意

のシステム上のWebクライアントとして実行できます。

クライアントには、以下のコンポーネントがあります。

l 左上のステータスの表には、接続しているサーバとそのリソースの上位のステータスが表示されま

す。

l 右上のプロパティパネルには、ステータスの表で直前に選択したオブジェクトの詳細情報が表示

されます。

l 下部の出力パネルには、コマンドの出力が表示されます。

l ウィンドウの最下部にあるメッセージバーには、処理のステータスメッセージが表示されます。

l コンテキストツールバー (プロパティパネル内 )とグローバルツールバーを使用すると、頻繁に使用す

176 User Guide

GUI クライアントの終了

る作業に即座にアクセスできます。

l コンテキストメニュー (ポップアップ)とグローバルメニューから、すべての作業にアクセスできます。


[File] メニューから [Exit]を選択すると、すべてのサーバから切断され、クライアントが終了します。

LifeKeeper GUI ソフトウェアパッケージ

LifeKeeper GUIは、LifeKeeper Coreパッケージクラスタにバンドルされている steeleye-lkGUI ソフトウェ

アパッケージに含まれています。steeleye-lkGUIパッケージは、以下の動作を実行します。

l JavaアーカイブフォーマットのLifeKeeper GUI クライアントをインストールする。

l LifeKeeper GUIサーバをインストールする。

l LifeKeeper管理 Webサーバをインストールする。

注記 : LifeKeeper管理 Webサーバは、パブリックWebサーバとは異なるポート 81を使用するよ

うに設定されます。

l ディレクトリ /opt/LifeKeeper/htdoc/に Javaポリシーファイルをインストールします。このファイルに

は、LifeKeeper GUIの実行に必要な最小限の権限があります。LifeKeeper GUIアプリケーショ

ンは、この場所にある java.policy ファイルを使用して、アクセスを制御します。

l GUI管理用に LifeKeeperを準備する。

続行する前に、LifeKeeperサーバに LifeKeeper GUIパッケージがインストール済みであることを確認す

る必要があります。コマンド rpm -qi steeleye-lkGUIを入力して、このパッケージがインストール

済みであるかどうかを確認できます。GUIパッケージがインストール済みである場合、出力にパッケージ

名 steeleye-lkGUIが表示されます。


メニュー

メニュー

SteelEye LifeKeeper for Linuxのメニュー

リソースのコンテキストメニュー

リソースのコンテキストメニューは、ステータスの表内にあるグローバル (クラスタ全体の)リソース (上図 )、またはサーバ固有のリソースインスタンス (下図 )を右クリックしたときに表示されます。デフォルトのリソー

スコンテキストメニューについて、ここで説明しますが、このメニューは特定のリソースタイプについてカスタ

マイズされていることがあります。この場合、メニューは該当するリソースキットのドキュメンテーションで説

明されています。

選択したリソースについて、動作が呼び出されます。特定のサーバ上にあるリソースインスタンスを選択

した場合、そのサーバについて動作が呼び出されます。一方、グローバル (クラスタ全体の)リソースを選

択した場合は、サーバを選択する必要があります。

In Service -リソース階層を in serviceにします。

Out of Service -リソース階層を out of serviceにします。

178 User Guide

サーバのコンテキストメニュー

Extend Resource Hierarchy -フェイルオーバをサポートするために、リソース階層を別のサーバに拡張し

ます。

Unextend Resource Hierarchy -1台のサーバから拡張リソース階層を削除します。

Create Dependency -2つのリソース間に親 /子の関係を作成します。

Delete Dependency -2つのリソース間にある親 /子の関係を削除します。

Delete Resource Hierarchy -リソース階層を LifeKeeperクラスタ内のすべてのサーバから削除します。

Properties -[Resource Properties]ダイアログを表示します。

サーバのコンテキストメニュー

サーバのコンテキストメニューは、ステータスの表内にあるサーバアイコンを右クリックしたときに表示されま

す。このメニューは [Edit] メニューの [Server]サブメニューと同じですが、動作は常に、最初に選択した

サーバ上で呼び出される点が異なります。

Disconnect -クラスタから切断します。

Refresh -GUIを最新情報に更新します。

View Logs -接続しているサーバについて、LifeKeeperのログメッセージを表示します。

Create Resource Hierarchy -リソース階層を作成します。

Create Comm Path -サーバ間にコミュニケーションパスを作成します。

Delete Comm Path -サーバからコミュニケーションパスを削除します。

Properties -[Server Properties]ダイアログを表示します。


[File] メニュー

[File] メニュー

Connect - LifeKeeperクラスタに接続します。LifeKeeperクラスタ内の各サーバに接続するには、その

サーバでログイン認証が必要です。

Exit -すべてのサーバから切断し、GUIのウィンドウを閉じます。

[Edit] メニュー - [Resource]



Extend Resource Hierarchy -フェイルオーバをサポートするために、リソース階層を別のサーバに拡張し

ます。

Unextend Resource Hierarchy - 1台のサーバから拡張リソース階層を削除します。

Create Dependency - 2つのリソース間に親 /子の関係を作成します。

Delete Dependency - 2つのリソース間にある親 /子の関係を削除します。

Delete Resource Hierarchy -リソース階層を LifeKeeperクラスタ内のすべてのサーバから削除します。

Properties - [Resource Properties]ダイアログを表示します。

180 User Guide

[Edit] メニュー - [Server]

[Edit] メニュー - [Server]

Disconnect -クラスタから切断します。

Refresh - GUIを最新情報に更新します。





Properties -[Server Properties]ダイアログを表示します。

[View] メニュー

Global Toolbar -チェックボックスがオンの場合、このコンポーネントを表示します。

Message Bar -チェックボックスがオンの場合、このコンポーネントを表示します。


[Help] メニュー

Properties Panel -チェックボックスがオンの場合、このコンポーネントを表示します。

Output Panel -チェックボックスがオンの場合、このコンポーネントを表示します。

Options - GUIの表示プロパティを編集します。

History -メッセージバーに表示された最新メッセージを、LifeKeeperのGUIの [Message History]ダイア

ログボックスに表示します (最大 1000行 )。

Expand Tree -リソース階層ツリー全体を展開します。

Collapse Tree -リソース階層ツリー全体を折り畳みます。

[Help] メニュー

Technical Documentation - SIOS Technology Corp.のテクニカルドキュメンテーションの開始ページを

表示します。

About... - LifeKeeper GUIのバージョン情報を表示します。

ツールバー

SteelEye LifeKeeper for Linuxのツールバー

GUI のツールバー

このツールバーは、プロパティパネルに表示されるデフォルトのサーバとリソースのコンテキストツールバーを

組み合わせたものですが、このツールバーから動作を実行するときには、サーバとリソースを選択する必


Connect -LifeKeeperクラスタに接続します。

182 User Guide

GUIのツールバー

Disconnect -LifeKeeperクラスタから切断します。




Delete Resource Hierarchy -リソース階層を LifeKeeperクラスタ内のすべてのサーバか

ら削除します。





Extend Resource Hierarchy -フェイルオーバをサポートするために、リソース階層を別の

サーバに拡張します。



リソースのコンテキストツールバー

Create Dependency -2つのリソース間に親 /子の関係を作成します。

Delete Dependency -2つのリソース間にある親 /子の関係を削除します。

Migrate Hierarchy toMulti-Site Cluster -既存の階層をMulti-Site Cluster環境に移

行します。

リソースのコンテキストツールバー

ステータスの表からサーバ固有のリソースインスタンスを選択すると、プロパティパネルにリソースのコンテキ

ストツールバーが表示されます。

選択したサーバとリソースについて、動作が呼び出されます。灰色表示のリソースについて、動作を選

択することはできません。



Extend Resource Hierarchy -フェイルオーバをサポートするために、リソース階層を別の



AddDependency - 2つのリソース間に親 /子の関係を作成します。

184 User Guide

サーバのコンテキストツールバー

Remove Dependency - 2つのリソース間にある親 /子の関係を削除します。

Delete Resource Hierarchy -リソース階層をすべてのサーバから削除します。

サーバのコンテキストツールバー

ステータスの表からサーバを選択すると、プロパティパネルにサーバのコンテキストツールバーが表示されま

す。選択したサーバについて、動作が呼び出されます。

Disconnect -LifeKeeperクラスタから切断します。




Delete Resource Hierarchy -リソース階層を LifeKeeperクラスタ内のすべてのサーバか

ら削除します。




GUIの実行の準備

GUI の実行の準備

LifeKeeperのGUI - 概要

LifeKeeperのGUIは、Javaテクノロジを使用して、LifeKeeperおよびその設定データとのグラフィカルな

ステータスのインターフェースを提供します。LifeKeeperのGUIはクライアント /サーバアプリケーションな

ので、ユーザはクライアントシステムでグラフィカルユーザインターフェースを実行して、LifeKeeperが動作

中のサーバシステムの監視や管理を行います。クライアントとサーバは、同一システム上にある場合も、

ない場合もあります。クラスタマシンの必要なグループメンバシップをユーザが持っている限り、LifeKeeperのGUIを使用することで、任意のマシンから、任意のクラスタ内のサーバとリソースの管理、操作、また

は監視ができます (詳細については、GUIのユーザの設定を参照 )。LifeKeeper GUIのサーバとクライア

ントのコンポーネントについて説明します。

GUIサーバ

システムの起動時に、LifeKeeperクラスタ内の各サーバで、LifeKeeper GUIサーバが初期化されま

す。LifeKeeper GUIサーバは、Javaネイティブインターフェース (JNI)経由で LifeKeeper Coreソフトウェ

アと、リモートメソッド呼び出し (RMI)を使用して LifeKeeper GUI と通信します。

GUI クライアント

LifeKeeper GUI クライアントは、Linuxシステム上のアプリケーションとして、またはWindowsやUnixシス

テム上のWebブラウザから呼び出し可能なアプレットとして動作するように設計されています。

LifeKeeper GUI クライアントには、以下のグラフィカルコンポーネントがあります。

l 左上のステータスの表には、接続しているサーバとそのリソースの上位のステータスが表示されま

す。

l 右上のプロパティパネルには、ステータスの表で直前に選択したオブジェクトの詳細情報が表示

されます。l 下部の出力パネルには、コマンドの出力が表示されます。l ウィンドウの最下部にあるメッセージバーには、処理のステータスメッセージが表示されます。

l サーバのコンテキストツールバーとリソースのコンテキストツールバー (プロパティパネル内 )、およびグ

ローバルツールバーからは、頻繁に使用する作業に即座にアクセスできます。

l サーバのコンテキストメニューとリソースのコンテキストメニュー (ポップアップ)およびグローバルメニ

ュー ([File]、 [Edit Server]、 [Edit Resource]、{View]、および [Help})からは、すべての作業にアク

セスできます。

グラフィックのリソース、サーバ、または表のセルを右クリックすると、コンテキストメニューが表示されます。

また、多くの作業はこれらのコンテキストメニューから開始できます。この場合、リソースとサーバは自動

的に指定されます。

186 User Guide

GUI クライアントの開始

GUI クライアントの開始

LifeKeeper GUIアプレットの開始

Webから LifeKeeper GUIアプレットを実行するには、好みのWebブラウザを開き、URL http://<servername>:81 (<server name>は LifeKeeperサーバの名前 )に移動します。これにより、そのマシン上にあ

る LifeKeeper GUIサーバから LifeKeeper GUIアプレットがロードされます。

ロードの完了後、 [Cluster Connect]ダイアログが表示されます。このダイアログで、任意のGUIサーバ

に接続できます。

注記 :アプレットの実行時に、必須のJavaプラグインがシステムにない場合、プラグインをダウンロード

するWebサイトが自動的に表示されます。また、Javaを有効にするように、ブラウザのセキュリティパラ

メータを設定する必要があります。

パラメータが設定済みでもクライアントがロードされない場合は、GUIのトラブルシューティングを参照し

てください。

アプリケーションクライアントの開始

ある LifeKeeperサーバで管理者権限を持つユーザは、そのサーバからアプリケーションクライアントを実

行できます。LifeKeeper GUIアプリケーションを開始するには、グラフィカルウィンドウから

/opt/LifeKeeper/bin/lkGUIappを実行してください。

この操作を実行してもクライアントがロードされない場合は、GUIのトラブルシューティングを参照してく

ださい。


[File] メニューから [Exit]を選択すると、すべてのサーバから切断され、クライアントが終了します。

LifeKeeperのGUI の設定

GUI管理用のLifeKeeperサーバの設定

各 LifeKeeperサーバについて、以下の手順を実行してください。各手順には、詳細手順の参照先ま

たはリンクがあります。

1. 各サーバに、Java実行時環境 (JRE)または Javaソフトウェア開発キット (JDK)をインストール

する必要があります。必要な Javaのバージョンと、必要なダウンロードにアクセスするためのURLについては、 SPS for Linux リリースノートを参照してください。注記 : JREは、 SPSのインス

トールイメージファイルから、設定スクリプトを実行し、JREのインストールのみを選択することでイ

ンストールできます (詳細については、SPS for Linux インストールガイドを参照 )。

2. 各サーバで、LifeKeeper GUIサーバを開始してください (GUIサーバの開始 /停止を参照 )。注

記 : GUIサーバが後続の初期インストールを開始した後、LifeKeeperの開始と停止は、GUIサーバを含むLifeKeeperのすべてのデーモンプロセスの開始と停止を行います。

3. root以外のユーザにGUIの使用を許可するように計画している場合は、GUIユーザの設定が

必要です。


GUIの実行

GUIの実行

LifeKeeperのGUIは、以下の場所で実行できます。

l クラスタ内のLifeKeeperサーバ

l クラスタ外のリモートシステム

LifeKeeperクラスタ内のサーバでGUIの設定と実行を行う方法については、LifeKeeperサーバでの

GUIの実行を参照してください。

LifeKeeperクラスタ外のリモートシステムでGUIの設定と実行を行う方法については、リモートシステム

でのGUIの実行を参照してください。

GUIの設定

項目説明

GUI のクラ

イアントと

サーバの通

信

LifeKeeper GUIのクライアントとサーバは、通信に Javaのリモートメソッド呼び出し

(RMI)を使用します。RMIが正しく動作するためには、クライアントとサーバは解決可

能なホスト名または IPアドレスを使用する必要があります。DNSが実装されていない

場合 (または、他の名前のルックアップメカニズムを使用して名前が解決できない場

合 )は、クライアントとサーバのそれぞれについて、 /etc/hosts ファイルを編集し、他のす

べてのLifeKeeperサーバの名前とアドレスを含めてください。

GUI サーバ

の Java プ

ラットフォー

ム

LifeKeeper GUIサーバには、Java実行時環境 (JRE) - Java仮想マシン、Javaプラッ

トフォームのコアクラス、およびサポートするファイル -をインストールする必要がありま

す。JRE 5.0 for Linuxは、 SPS for Linuxのインストールイメージファイルにあります

(SPS for Linux インストールガイドを参照 )。また

は、http://java.sun.com/javase/downloads/index_jdk5.jspから直接ダウンロードする

こともできます。注記 :デフォルトでは、LifeKeeper GUIサーバは、JREが各サーバのディレクトリ

/usr/java/j2re1.5.0_07にインストールされていると予測します。JREが見つからない場

合、GUIサーバはディレクトリ /usr/java/j2sdk1.5.0_07から Javaソフトウェア開発キット

(JDK)を探します。JREまたは JDKを別のディレクトリの場所で使用する場合

は、LifeKeeperのデフォルトファイル /etc/default/LifeKeeperのPATHを編集し、Javaインタープリタ java.exeを持つディレクトリを含めてください。このファイルの編集時に

LifeKeeperが実行中である場合は、変更内容を認識させるために LifeKeeper GUIサーバを停止し、再起動する必要があります。再起動しない場合、LifeKeeper GUIは Javaコマンドを見つけることができません。

Java リモー

トオブジェク

トレジストリ

のサーバ

ポート

LifeKeeper GUIサーバは、各 LifeKeeperサーバ上のJavaリモートオブジェクトレジスト

リ用にポート 82を使用します。これにより、サーバは、典型的なファイアウォールの後に

あるクライアントからのRMI呼び出しをサポートできます。

188 User Guide

http://java.sun.com/javase/downloads/index_jdk5.jsp

http://java.sun.com/javase/downloads/index_jdk5.jsp

GUIの制限

LifeKeeperの管理

Web サー

バ

LifeKeeper GUIサーバには、クライアントのブラウザの通信用に管理 Webサーバが必

要です。現在、LifeKeeper GUIサーバは、管理 Webサーバとして lighttpdWebサー

バのプライベートコピーを使用しています。このWebサーバは、steeleye-lighttpdパッ

ケージによりインストールと設定が実行され、他のWebサーバとの競合を避けるために

ポート 81を使用します。

GUI クライ

アントのネッ

トワークアク

セス

LifeKeeper GUI クライアントには、LifeKeeperクラスタ内のすべてのホストへのネットワー

クアクセスが必要です。LifeKeeper GUI クライアントをブラウザ内で実行する場合、アプ

レットへのネットワークアクセスを可能にするためにセキュリティレベルを低下させる必要

があります。セキュリティを低い値に設定した状態で、他のサイトを閲覧しないように注

意してください (つまり、イントラネットまたは信頼できるサイトについてのみセキュリティ設

定を変更する)。

GUIの制限

項目説明

GUI の相互

運用性の

制限

LifeKeeper for Linux クライアントは、Linuxサーバ上のLifeKeeperの管理にのみ使用

できます。LifeKeeper for LinuxのGUI とLifeKeeper forWindowsは、同時には使用

できません。

GUI サーバの開始 / 停止

LifeKeeper GUIサーバを開始するには

LifeKeeper GUIサーバが動作していない場合は、root として以下のコマンドを入力してください。

/opt/LifeKeeper/bin/lkGUIserver start

このコマンドは、管理しているサーバで LifeKeeper GUIサーバのデーモンプロセスが現在動作していな

い場合、それらのデーモンプロセスをすべて開始します。以下のようなメッセージが表示されます。

# Installing GUI Log

# LK GUI Server Startup at:

# Mon May 8 14:14:46 EDT 2006

# LifeKeeper GUI Server Startup completed at:

# Mon May 8 14:14:46 EDT 2006

LifeKeeper GUIサーバが開始した後、以降のLifeKeeperの開始操作はすべて、LifeKeeper GUIサー

バのプロセスを自動的に開始します。

トラブルシューティング

LifeKeeper GUIは、各サーバのポート 81を管理 Webサーバ用に、ポート 82を Javaリモートオブジェク

トレジストリに使用します。他のアプリケーションがそれらのポートを使用している場合、LifeKeeper GUI


LifeKeeper GUIサーバを停止するには

は正しく機能しません。これらの値は、ファイル /etc/default/LifeKeeperの以下のエントリを編集するこ

とにより変更できます。

GUI_WEB_PORT=81 GUI_RMI_PORT=82

注記 : これらのポートの値は、起動時にGUIサーバで初期化されます。ポートの値を変更した

場合、GUIサーバを停止し、再起動する必要があります。これらの値は、接続するすべてのクラ

スタ全体で同一である必要があります。

LifeKeeper GUIサーバを停止するには

LifeKeeper GUIサーバが動作している場合は、root として以下のコマンドを入力してください。

/opt/LifeKeeper/bin/lkGUIserver stop

このコマンドは、管理しているサーバで LifeKeeper GUIサーバのデーモンプロセスが現在動作している

場合、それらのデーモンプロセスをすべて停止します。以下のメッセージが表示されます。

# LifeKeeper GUI Server Shutdown at:

# Fri May 19 15:37:27 EDT 2006

# LifeKeeper GUI Server Shutdown Completed at:

# Fri May 19 15:37:28 EDT 2006

LifeKeeper GUIサーバのプロセス

LifeKeeper GUIサーバが動作していることを確認するには、以下のコマンドを入力してください。

ps -ef | grep runGuiSer

以下のような出力が表示されます。

root 2805 1 0 08:24 ? 00:00:00 sh/opt/LifeKeeper/bin/runGuiSer

現在動作している他のGUIサーバのデーモンプロセスのリストを表示するには、以下のコマンドを入力


ps -ef | grep S_LK

以下のような出力が表示されます。

root 769 764 0 Oct16 ?

00:00:00/usr/jre1.2.2/bin/i386/green_threads/rmiregistry -J-DS_

LK=true 82

root 819 764 0 Oct16 ?

00:00:00/usr/jre1.2.2/bin/i386/green_threads/java -DS_LK=true -

0ss3m -ss3m-Dcom.steeleye.Li

GUI ユーザの設定

GUIユーザには 3つのクラスがあり、それぞれ権限が異なります。

190 User Guide

GUIユーザの設定

1. クラスタ全体にわたって Administrator (管理者 )の権限を持つユーザは、GUIから可能な動

作のすべてを実行できます。

2. 1台のサーバ上でOperator (オペレータ)の権限を持つユーザは、LifeKeeperの設定やステータ

スの情報を表示でき、そのサーバ上のリソースを in serviceまたは out of serviceにすることができ

ます。

3. 1台のサーバ上でGuest (ゲスト )の権限を持つユーザは、そのサーバのLifeKeeperの設定やス

テータスの情報を表示できます。

GUIサーバは、root として起動する必要があります。GUIパッケージのインストール時に、rootのログイン

とパスワードのエントリが、Administrator の権限付きでGUIパスワードファイルに自動設定されるの

で、rootは、そのサーバからGUIアプリケーションまたはWebクライアント経由で LifeKeeperのすべての

作業を実行できます。root以外のユーザに LifeKeeper GUI クライアントの使用を許可するように計画

している場合は、LifeKeeper GUIのユーザを設定する必要があります。

最良の方法は、常にクラスタ全体を単位として許可を付与することです。サーバ単位で許可を付与す

ることもできますが、ユーザを混乱させてしまい、管理作業が実行できなくなります。

ユーザ管理は、以下に示すように、コマンドラインインターフェースから lkpasswdを使用して実行しま

す。特記ない限り、すべてのコマンドで、ユーザのパスワードを 2回入力する必要があります。変更内

容は、ユーザの次回のログイン時またはGUIサーバの再起動時 (いずれかの早い時点 )で有効になり

ます。各ユーザは、1台のサーバにつき権限を 1つ持ちます。サーバで新しい権限が指定された場合、

以前の権限エントリは削除されます。

l ユーザに LifeKeeper GUIのAdministrator 権限を付与するには、以下のコマンドを入力してく

ださい。

/opt/LifeKeeper/bin/lkpasswd -administrator <user>

l ユーザに LifeKeeper GUIのOperator 権限を付与するには、以下のコマンドを入力してくださ

い。

/opt/LifeKeeper/bin/lkpasswd -operator <user>

l ユーザに LifeKeeper GUIのGuest権限を付与するには、以下のコマンドを入力してください。

/opt/LifeKeeper/bin/lkpasswd -guest <user>

l ユーザの権限レベルを変更せずに、既存のユーザのパスワードを変更するには、以下のコマンド

を入力してください。

/opt/LifeKeeper/bin/lkpasswd <user>

l 既存のユーザに LifeKeeper GUIの使用を禁止するには、以下のコマンドを入力してください。

/opt/LifeKeeper/bin/lkpasswd -delete <user>

このコマンドでは、パスワードを入力する必要はありません。

注記 : これらのコマンドは、管理しているサーバでのみGUIパスワードファイルを更新します。LifeKeeperクラスタ内のすべてのサーバでコマンドを繰り返し入力する必要があります。


Javaのセキュリティポリシー

Java のセキュリティポリシー

LifeKeeperのGUIは、ポリシーベースのアクセス制御を使用します。GUI クライアントのロード時に、現

在有効なセキュリティポリシーに基づいて権限がGUI クライアントに割り当てられます。ポリシーはさまざ

まな署名者 /場所からのコードに提供される権限を指定し、外部から設定可能なポリシーファイルか

ら初期化されます。

デフォルトでは、システム全体のポリシーファイルとオプションのユーザポリシーファイルが1つずつあります。

システム全体でコードに権限を付与するシステムポリシーファイルが先にロードされ、次にユーザポリシー

ファイルが追加されます。LifeKeeper GUIがアプリケーションとして起動される場合は、これらのポリシー

ファイルに加えて、LifeKeeper GUIのポリシーファイルもロードされることがあります。

ポリシーファイルの場所

デフォルトでは、システムポリシーファイルは以下の場所にあります。

<JAVA.HOME>/lib/security/java.policy (Linux)

<JAVA.HOME>\lib\security\java.policy (Windows)

注記 : JAVA.HOMEは、システムのプロパティ「JAVA.HOME」の値を指し、JREまたは JDKがインス

トールされたディレクトリの場所を指定します。

ユーザポリシーファイルは「.」の文字で始まり、デフォルトでは以下の場所にあります。

<USER.HOME>\.java.policy

注記 : USER.HOMEは、システムのプロパティ「user.home」の値を指し、ユーザのホームディレクトリを指

定します。例えば、Windows NTワークステーション上にあるユーザPaulのホームディレクトリ

は、「paul.000」です。

Windowsシステムの場合、user.homeのプロパティ値のデフォルト値は以下のとおりです。

C:\WINNT\Profiles\<USER> (マルチユーザWindows NT システム)

C:\WINDOWS\Profiles\<USER> (マルチユーザWindows 95/98 システム)

C:\WINDOWS (シングル－ユーザWindows 95/98 システム)

デフォルトでは、LifeKeeper GUIのポリシーファイルは以下の場所にあります。

/opt/LifeKeeper/htdoc/java.policy (Linux)

ポリシーファイルの作成と管理

デフォルトでは、LifeKeeper GUIがアプリケーションとして起動される場合に LifeKeeper GUIのポリシー

ファイルが使用されます。LifeKeeper GUIをアプレットとして実行する場合、ホームディレクトリにユーザポ

リシーファイルを作成する必要があります (存在しない場合 )。ユーザポリシーファイルは、LifeKeeperGUIを実行するために必要な最低限の権限を指定する必要があります。このトピックの「ポリシーファイ

ルの例」セクションで後述します。

192 User Guide

ポリシーファイルでの権限の付与

ポリシーファイルの作成と管理は、単純なテキストエディタ、または Java実行時環境 (JRE)やJava開発キット (JDK)に含まれるグラフィカルな Policy Toolユーティリティから行うことができます。Policy Toolを使用すると、入力が簡略化され、ポリシーファイルに必要な構文の知識が不要になります。PolicyToolの使用方法の詳細については、http://java.sun.com/j2se/1.3/docs/tooldocs/tools.htmlにある

Policy Toolのドキュメンテーションを参照してください。

LifeKeeper GUIを実行するために必要な最低限の権限を持つユーザポリシーファイルを作成する最も

簡単な方法は、 /opt/LifeKeeper/htdoc/java.policyにある LifeKeeper GUIのポリシーファイルをホー

ムディレクトリにコピーし、ファイル名を .java.policyに変更することです (ファイル名の前にあるドットは必

須 )。Windowsシステムでは、ファイルhttp://<server name>:81/java.policy (<server name>は

LifeKeeperサーバのホスト名 )を開いてホームディレクトリに .java.policyの名前を付けて保存すること

で、LifeKeeper GUIのポリシーファイルをコピーできます。ユーザポリシーファイルの正しい場所を特定す

る必要がある場合は、Javaのコントロールパネルを使用して Javaコンソールを有効にし、LifeKeeperGUIをアプレットとして起動します。ユーザポリシーファイルのホームディレクトリのパスが、Javaコンソール

に表示されます。

ポリシーファイルでの権限の付与

権限は、システムリソースへのアクセスを表します。アプレットにリソースへのアクセスを許可するには、対

応する権限を、アクセスを試行するコードに明示的に付与する必要があります。権限は通常、名前を

持ち (「ターゲット名」として参照される)、場合によっては、1つ以上の動作を含むカンマ区切りリストを

持ちます。例えば、以下のコードは、 /tmpディレクトリのファイルabcに対する読み取りアクセスを表す

FilePermissionオブジェクトを作成します。

perm = new java.io.FilePermission("/tmp/abc","read");

この例では、ターゲット名は「/tmp/abc」、動作文字列は「read」です。

ポリシーファイルは、指定したコードソースからのコードに許可する権限を指定します。この例

で、 /home/sysadminディレクトリのコードにファイル /tmp/abcへの読み取りアクセスを付与するポリシーフ

ァイルのエントリは以下のとおりです。

grant codeBase "file:/home/sysadmin/" {

permissionjava.io.FilePermission "/tmp/abc", "read"; };

ポリシーファイルの例

このポリシーファイルの例には、LifeKeeper GUIの実行に必要な最小限の権限があります。このポリ

シーファイルは、LifeKeeper GUIパッケージにより /opt/LifeKeeper/htdoc/java.policyにインストールさ

れます。

/*

* Permissions needed by the LifeKeeper GUI. You may want to

* restrict this by codebase. However, if you do this, remember

* that the recovery kits can have an arbitrary jar component

* with an arbitrary codebase, so you'll need to alter the grant

* to cover these as well.

*/

grant {


http://java.sun.com/j2se/1.3/docs/tooldocs/tools.html

Javaプラグイン

/*

* Need to be able to do this to all machines in the

* LifeKeeper cluster. You may restrict the network

* specification accordingly.

*/

permission java.net.SocketPermission"*", "accept,connect,resolve";

/*

* We use URLClassLoaders to get remote properties files and

* jar pieces.

*/

permission java.lang.RuntimePermission"createClassLoader";

/*

* The following are needed only for the GUI to run as an

* application (the default RMI security manager is more

* restrictive than the one a browser installs for its

* applets.

*/

permission java.util.PropertyPermission "*","read";

permission java.awt.AWTPermission "*";

permission java.io.FilePermission "<<ALL FILES>>","read,execute";

};

Java プラグイン

使用しているブラウザに関係なく (サポートするブラウザを参照 )、ブラウザが初めて LifeKeeper GUIのロードを試行するときには、Javaプラグインソフトウェアを自動ダウンロードするか、Javaプラグインソフト

ウェアのダウンロードとインストールを行うWebページを表示します。その後は、Javaプラグインソフトウェ

アのテクノロジをサポートするWebページに遭遇するたびに、ブラウザは Javaプラグインソフトウェアを自

動的に起動します。

Javaプラグインのダウンロード

Javaプラグインソフトウェアは、Solaris、Linux、およびWindowsのJava実行時環境 (JRE)の一部と

して含まれています。JREのダウンロードには、お使いのネットワークとシステム設定のサイズにより、合

計で 3～ 10分かかります。ダウンロードのWebページには、JRE とJavaプラグインソフトウェアについて

の詳細なドキュメンテーションとインストール手順があります。

注記 1:プラグインのインストール後、およびプラグインのプロパティを変更するたびに、ブラウザを閉じて

再起動する必要があります。

注記 2: LifeKeeperは、Javaプラグインのバージョン 1.3.x以降のみをサポートしています。

Javaプラグインのトラブルシューティング

Netscape 6/7、Mozilla 1.x、または Firefox 1.xを使用している場合、Netscape、Mozilla、または

Firefoxのプラグインのディレクトリに、$JAVAHOMEディレクトリの libjavaplugin_oji.soファイルのパスへの

シンボリックリンクの作成が必要になることがあります。

194 User Guide

リモートシステムでのGUIの実行

例 (Firefox 1.5と jre 1.5):

cd /usr/lib/mozilla//plugins ln -s/usr/java/jre1.5.0_07/plugin/i386/ns7/libjavaplugin_oji.so

Netscape 4で、Javaプラグインを含むJava実行時環境をインストールしたにもかかわらずブラウザが

Javaプラグインを検出しない場合は、NPX_PLUGIN_PATH環境変数を Javaプラグインの場所

(javaplugin.soファイルがある場所 )に設定してください。つまり、NPX_PLUGIN_PATH=$JAVAHOME/jre/plugin/i386/ns4をエクスポートしてください ($JAVAHOMEは Java実行時環

境をインストールした最上位のディレクトリ)。

Javaプラグインは、Java 2 SDK、標準エディション v1.3のセキュリティモデルをサポートしています。アプレ

ットはすべて、標準アプレットセキュリティマネージャの下で実行されます。詳細については、Javaのセキ

ュリティのFAQ、またはGUIアプレットを使用するためのブラウザのセキュリティパラメータの設定を参照し

てください。

一部のプラットフォーム/ブラウザの組み合わせでは、Javaプラグインソフトウェアが、LifeKeeperのGUIにある Javaコンポーネント (スクロールバー、ツールバー、メニューなど)の表示と動作に影響します。これら

の多くの状況では、回避策として、ウィンドウのサイズを変更したり、最小化 /最小化解除 (強制再

表示 )したりすると問題が解決します。

リモートシステムでのGUI の実行

LifeKeeper GUIを Javaアプレットとして実行することにより、LifeKeeperクラスタ外のLinux、Unix、また

はWindowsのシステムから LifeKeeperの管理ができます。この環境でのGUIの設定と実行について、

説明します。

リモートシステムでのGUIの設定

リモートのLinux、Unix、またはWindowsのシステムで LifeKeeper GUIを実行するには、使用するブラ

ウザがJDK 1.6アプレットをフルにサポートする必要があります。LifeKeeper GUIをサポートするプラットフ

ォームとブラウザの詳細については、 SPS for Linux リリースノートを参照してください。

1. LifeKeeper GUIをアプレットとして実行する場合、ホームディレクトリにユーザポリシーファイルを作

成する必要があります (存在しない場合 )。ユーザポリシーファイルには、LifeKeeper GUIの実行

に必要な最小限の権限を指定する必要があります。

l LifeKeeper GUIを実行するために必要な最小限の権限を持つユーザポリシーフ

ァイルを作成する最も簡単な方法は、 /opt/LifeKeeper/htdoc/java.policyにあ

る LifeKeeper GUIのポリシーファイルをホームディレクトリにコピーし、ファイル名を

.java.policyに変更します (ファイル名の前にあるドットは必須 )。Windowsシステ

ムでは、ファイルhttp://<server name>:81/java.policy (<servername>は

LifeKeeperサーバのホスト名 )を開いてホームディレクトリに .java.policyの名前を

付けて保存することで、LifeKeeper GUIのポリシーファイルをコピーできます。ユー

ザポリシーファイルの正しい場所を特定する必要がある場合は、Javaのコント

ロールパネルを使用して Java コンソールを有効にし、LifeKeeper GUIをアプレット

として起動します。ユーザポリシーファイルのホームディレクトリのパスが、Javaコン

ソールに表示されます。

l ユーザポリシーファイルがすでにある場合は、LifeKeeperサーバの


http://java.sun.com/sfaq











/opt/LifeKeeper/ htdoc/java.policyに指定されている必須エントリを、単純な

テキストエディタを使用して既存のファイルに追加できます。詳細について

は、Javaのセキュリティポリシーを参照してください。

2. ブラウザのセキュリティパラメータを低に設定する必要があります。この設定では通常、JavaとJavaアプレットが有効になります。さまざまなブラウザとバージョンが存在するので、ブラウザのセキ

ュリティパラメータの設定手順はGUIアプレットを使用するためのブラウザのセキュリティパラメータ

の設定で説明しています。

注記 :セキュリティを低く設定した状態で外部サイトを閲覧するときには、注意が必要です。

3. GUIを初めて実行するときにNetscape または Internet Explorerを使用し、かつ必要な Javaプラグインがシステムにない場合、プラグインをダウンロードするWebサイトが自動的に表示され

ることがあります。必要な JavaプラグインのバージョンとダウンロードにアクセスするためのURLについては、 SPS for Linux リリースノートを参照してください。


上記の作業を完了すると、リモートシステムで LifeKeeper GUIを Javaアプレットとして実行できます。

1. LifeKeeper GUIのWebページのURL http://<server name>:81 (<server name>は

LifeKeeperの名前 )を開いてください。このWebページには、LifeKeeperのスプラッシュ画面とア

プレットがあります。Webページが開くと、以下の動作が実行されます。

l スプラッシュ画面が表示される。l アプレットがロードされる。l Java仮想マシンが開始される。l 一部のサーバファイルがダウンロードされる。l アプレットが初期化される。

ネットワークとシステムの設定によっては、これらの動作に最大 20秒かかることがあります。通

常、アプレットのロード時と初期化時に、ブラウザには最小のステータスがいくつか表示されます。

すべてのものが正しくロードされた場合、アプレット領域に [Start]ボタンが表示されます。スプラッ

シュ画面に [Start]ボタンが表示されない場合、またはアプレットのロードと初期化が失敗した

疑いがある場合は、「アプレットのトラブルシューティング」またはネットワークに関するトラブルシュー

ティングを参照してください。

2. 要求されたら、[Start]をクリックしてください。LifeKeeperのGUIが表示され、 [Cluster Connect]ダイアログが自動的に表示されます。サーバが開始され、クラスタへの接続が確立した後、GUIのウィンドウに、接続しているサーバにより保護されているリソースとステータスがグラフィックで表示

されます。GUIのメニューとツールバーのボタンから、LifeKeeperの管理機能を使用できます。

注記 :一部のブラウザでは、アプレットで作成されたウィンドウとダイアログに「Warning: AppletWindow」が表示されます。これは通常の動作であり、無視できます。

アプレットのトラブルシューティング

アプレットのロードと初期化に失敗した疑いがある場合は、以下の操作を試してください。

196 User Guide

LifeKeeperサーバでのGUIの実行

1. アプレットが失敗したことを確認してください。通常、アプレットの状態を示すブラウザウィンドウ内

に、メッセージが出力されます。Netscape と Internet Explorerでは、テキストのステータスに加

えて、アプレットの代わりにアイコンが表示されることがあります。アイコンをクリックすると、失敗の

内容が表示される場合があります。

2. Javaプラグインをインストールしていることを確認してください。問題がJavaプラグインに関連す

る場合は、Javaプラグインのトピックを参照してください。

3. ブラウザの設定要件、特にセキュリティ設定を満たしていることを確認してください。詳細につい

ては、GUIアプレットを使用するためのブラウザのセキュリティパラメータの設定を参照してくださ

い。設定について明らかな間違いが見つからない場合は、次の手順に進んでください。

4. Java コンソールを開いてください。

l Firefox、Netscape、および旧バージョンの Internet Explorerの場合は、マシン

のコントロールパネルから Java プラグインアプレットを実行し、コンソールを表示す

るオプションを選択してから、ブラウザを再起動してください。

l 最新バージョンの Internet Explorerの場合は、 [Tools] > [Sun Java Console]を選択してください。 [Sun Java Console]のメニュー項目が表示されない場合

は、 [Tools] > [Manage Add-Ons]を選択し、コンソールを有効にしてください。そ

の後、コンソールを表示するには、ブラウザの再起動が必要になることがあります。

l Mozillaの場合は、 [Tools] > [Web Development] > [Sun Java Console]を選

択してください。

5. URL http://<server name>:81 を再度開いて、GUIアプレットを開始してください。Java プラグ

インのコンソールパネルを変更した場合は、ブラウザを再起動してください。

6. コンソールに表示されたメッセージを確認してください。メッセージは、問題の解決に役立ちま

す。問題がネットワークに関連する場合は、ネットワークに関するトラブルシューティングを参照し

てください。

LifeKeeperサーバでのGUI の実行

LifeKeeper GUIを実行する最も簡単な方法は、LifeKeeperサーバでアプリケーションとして実行するこ

とです。これは、実際には、同一システム上でGUIのクライアントとサーバを実行することです。

1. GUI管理用のLifeKeeperサーバを設定した後、root として以下のコマンドを入力することによ

り、サーバ上でGUIをアプリケーションとして実行できます。

/opt/LifeKeeper/bin/lkGUIapp

2. lkGUIappスクリプトが適切な環境変数を設定して、アプリケーションを開始します。アプリケーシ

ョンのロード時に、LifeKeeperのアプリケーション指定ダイアログまたはスプラッシュ画面が表示さ

れます。

3. アプリケーションのロード後、LifeKeeperのGUIが表示され、 [Cluster Connect]ダイアログが自

動的に表示されます。接続先のサーバ名、およびログインとパスワードを入力してください。

4. クラスタへの接続が確立した後、GUIのウィンドウに、接続しているサーバにより保護されている

リソースとステータスがグラフィックで表示されます。GUIのメニューとツールバーのボタンから、管理

機能を使用できます。


GUIアプレットを使用するためのブラウザのセキュリティパラメータ

GUI アプレットを使用するためのブラウザのセキュリティパラメータ

警告 :セキュリティを低い値に設定した状態での他のサイトの閲覧には注意してください。

Netscape Navigator とNetscape Communicator1. [Edit]メニューの [Preferences]を選択してください。

2. [Preferences]ダイアログボックスの [Advanced Category]をダブルクリックしてください。

3. [Enable Java]と [Enable Java Script]のオプションを選択してください。

4. [OK]をクリックしてください。

Firefox1. [Edit]メニューの [Preferences]を選択してください。

2. [Preferences]ダイアログボックスの [Content]を選択してください。

3. [Enable Java]と [Enable Java Script]のオプションを選択してください。

4. [Close]をクリックしてください。

Internet Explorerセキュリティが最高の状態で Internet Explorerを使用するには、以下の手順で LifeKeeperサーバを信

頼済みサイトのゾーンに追加してください。

1. [Tools]メニューの [Internet Options]をクリックしてください。

2. [Security]タブをクリックしてください。

3. [Trusted Sites]ゾーンを選択し、[Custom Level]をクリックしてください。

4. [Reset custom settings]の [Medium/Low]を選択し、[Reset]をクリックしてください。

5. [Sites]をクリックしてください。

6. 接続する LifeKeeperサーバのサーバ名とポート番号を入力してください (例 : http://server1:81)。

以下の手順で行う別の方法 (セキュリティが低くなる可能性がある)もあります。

1. [Tools]メニューの [Internet Options]をクリックしてください。

2. [Internet]または [Local Intranet]を選択してください (リモートシステムとLifeKeeperクラスタが

同じイントラネット上に存在するかどうかによって異なる)。

3. [Security Level]バーを [Medium] ([Internet]を選択した場合 )、または [Medium-low] ([LocalIntranet]を選択した場合 )に調整してください。これらは、各ゾーンのデフォルト設定です。


198 User Guide

ステータスの表

ステータスの表

ステータスの表には、接続しているサーバとそのリソースのステータスがグラフィック表示されます。以下の

項目が表示されます。

l 最も上の行に、各サーバの状態。

l 左端の列に、各リソースのグローバル (サーバ全体での)状態と親 /子の関係。

l 残りのセルに、各サーバの各リソースの状態。

サーバとリソースの状態は、グラフィックス、テキスト、および色を使用して表示されます。サーバのテーブ

ルの空白セルは、特定のリソースがそのサーバで定義されていないことを示します。

ステータスの表でサーバまたはリソースを選択した場合、その項目の詳細な状態の情報とコンテキスト

依存ツールバーがプロパティパネルに表示されます。また、任意の項目のセルを右クリックすることで、該

当するサーバのコンテキストメニューまたはリソースのコンテキストメニューをポップアップ表示できます。

ステータスの表は 2つのセクションに分かれています。左右のセクションの境界を移動して、それらのセク

ションの相対サイズを変更できます。また、ステータスの表を折り畳んで、階層ツリーの上位項目のみを

表示できます。ツリーのリソース項目の折り畳み /展開を実行すると、表内にリストされる階層に対して

も折り畳み /展開が適用されます。

プロパティパネル

プロパティパネルには、ステータスの表から選択されたサーバまたはリソースのプロパティが表示されます。

プロパティパネルは、 [Server Properties]ダイアログまたは [Resource Properties]ダイアログと同じ機能

を持ち、さらに一般的に使用するコマンドに即座にアクセスできるコンテキスト依存ツールバーがありま

す。このパネルの上部には、サーバを選択した場合は server_name、リソースを選択した場合は

server_name: resource_nameがキャプションとして表示されます。

プロパティパネルに表示されるコンテキスト依存ツールバーは、サーバのコンテキストツールバーとリソース

のコンテキストツールバーです。サーバまたはリソースのツールバーもカスタマイズできます。ツールバーのカ

スタマイズの詳細については、該当するApplication Recovery Kitのドキュメンテーションを参照してくだ

さい。

プロパティパネル下部にあるボタンは、以下の機能を持ちます。

l [Apply]ボタンは、パネルの編集可能なプロパティに対する変更内容を適用します。このボタン

が有効になるのは、編集可能なプロパティを変更した場合のみです。

l [Reset]ボタンは、サーバにすべてのプロパティの現在の値を照会し、これまで変更した内容を

消去します。このボタンは常に有効です。

l [Help]ボタンは、プロパティパネルのコンテキスト依存ヘルプを表示します。このボタンは常に有

効です。

プロパティパネルのサイズを増減するには、パネルの左端にある境界を左右にスライドしてください。この

パネルを開閉するには、 [View] メニューの [Properties Panel]チェックボックスを使用してください。


http://docs.us.sios.com/linuxarks.php?ver=8.0













出力パネル

出力パネル

出力パネルは、LifeKeeper GUI クライアントが送出したコマンドの出力を収集します。コマンドの実行

開始時に、タイムスタンプ付きのラベルが出力パネルに追加され、そのラベルの下に、そのコマンドの出

力がすべて追加されます。複数のコマンドを同時に実行する場合 (通常は異なるサーバ上 )、各コマン

ドの出力が対応するセクションに送られ、各コマンドの結果が見やすくなります。

出力パネルのサイズを増減するには、パネル上部にある境界を上下にスライドしてください。このパネル

を開閉するには、 [View] メニューの[Output Panel]チェックボックスを使用してください。出力パネルを閉

じているときには、各コマンドを開始するダイアログが表示されたままになり、このダイアログを閉じるまで

出力がこのダイアログに表示されます。そして、このダイアログを閉じた後はコマンドの出力を確認でき

なくなります。出力パネルを再び開いた後は、LifeKeeperのGUIはデフォルトの動作に戻ります。

メッセージバー

メッセージバーは、 [Status]ウィンドウの下に表示されます。メッセージが1行のテキストで表示されま

す。「Connecting to Server X」や「Failure to connect to Server X」などのメッセージが表示されます。

メッセージバーを非表示にするには、 [View] メニューの [Message Bar]チェックボックスをオフにします。

メッセージバーを表示するには、 [View] メニューの [Message Bar]チェックボックスをオンにします。

メッセージバーに表示されたメッセージの履歴を表示する方法については、メッセージ履歴の表示を参


GUI の終了

[File] メニューから [Exit]を選択すると、すべてのサーバから切断され、GUIのウィンドウが閉じます。

共通の作業

以下に、すべてのユーザが実行できる基本作業を示します。

LifeKeeperの起動

デフォルトでは、すべてのSPS ソフトウェアは、ディレクトリ /opt/LifeKeeperにインストールされます。

すべての確認作業が完了すると、両方のサーバで LifeKeeperを起動する準備が整います。このセクシ

ョンでは、LifeKeeperサーバデーモンプロセスの起動について説明します。LifeKeeper GUIアプリケーショ

ンは、別個のコマンドを使用して起動され、LifeKeeper GUIの設定に説明されています。LifeKeeperには、LifeKeeperデーモンプロセスの起動と停止を行うコマンドラインインターフェースが用意されていま

す。これらのデーモンプロセスは、LifeKeeper GUIを起動する前に実行する必要があります。

LifeKeeper サーバプロセスの起動

LifeKeeperがシステムで現在実行されていない場合は、すべてのサーバに対するユーザルートとして次

のコマンドを入力してください。

200 User Guide

LifeKeeperの停止


数秒の遅延の後、情報メッセージが表示されます。

注記 : LifeKeeperを起動するときに LifeKeeper Distribution Enabling Packageを参照するエラーメ

ッセージが表示された場合は、LifeKeeperインストールイメージファイルをインストール/再インストールす


lkstart コマンドの詳細については、コマンドラインでman LCDを入力して LCD(1M)マニュアルページを

参照してください。

LifeKeeperの停止

LifeKeeperを停止する必要がある場合は、ルートとして次のコマンドを入力して停止してください。


このコマンドは、管理されているサーバ上で現在実行されているすべてのLifeKeeperデーモンプロセスを

停止します。

LifeKeeper プロセスの表示

現在実行されているすべてのLifeKeeperデーモンプロセスのリストを表示するには、次のコマンドを入

力してください。

ps -ef | grep LifeKeeper

出力の例を以下に示します。

root 947 1 0 16:25 ?00:00:00 /opt/LifeKeeper/bin/lcm

root 948 1 0 16:25 ?00:00:00/opt/LifeKeeper/bin/ttymonlcm

root 949 1 0 16:25 ?00:00:00/opt/LifeKeeper/bin/lcd

root 950 1 0 16:25 ?00:00:00/opt/LifeKeeper/bin/lkcheck

root 951 1 0 16:25 ?00:00:00/opt/LifeKeeper/bin/lkscsid

root 1104 1 0 16:26 ?00:00:00/opt/LifeKeeper/bin/lk_logmgr -1

注記 :上記のコアLifeKeeperデーモンプロセスの他にも実行される追加のGUIサーバデーモンプロセス

があります。 GUIサーバに関連するプロセスのリストについては、LifeKeeper GUIサーバプロセスの表示

を参照してください。

LifeKeeper GUI サーバプロセスの表示

LifeKeeper GUIサーバが実行されていることを確認するには、次のコマンドを入力してください。

ps -ef | grep runGuiSer

次のような出力が表示されます。

root 2805 1 0 08:24 ? 00:00:00 sh /opt/LifeKeeper/bin/runGuiSer


サーバのクラスタへの接続

現在実行されているその他のGUIサーバデーモンプロセスのリストを表示するには、次のコマンドを入

力してください。

ps -efw | grep S_LK

次のような出力が表示されます。

root 819 764 0 Oct16 ?00:00:00 java -Xint -Xss3M -DS_LK=true -

Djava.rmi.server.hostname=wake -Dcom.steeleye.LifeKeeper.rmiPort=82

-Dcom.steeleye.LifeKeeper.LKROOT=/opt/LifeKeeper -DGUI_RMI_

REGISTRY=internal -DGUI_WEB_PORT=81

com.steeleye.LifeKeeper.beans.S_LK

サーバのクラスタへの接続

1. 開始するには、以下の2つの方法があります。

l グローバルツールバーの [Connect]ボタンをクリックする。

l [File] メニューの [Connect]をクリックする。

2. [Cluster Connect]ダイアログの [Server Name]フィールドに、接続するクラスタ内のサーバ名を


注記 : IPv6アドレスを使用する場合は、このアドレスを大かっこ [ ]で囲む必要があります。これ

により、マシンの IPv6アドレス経由で接続を確立できます。別の方法として、名前をアドレスに

割り当てることができ、その名前を使用して接続できます。

3. [Login]と [Password]のフィールドに、指定のサーバ上で LifeKeeperが認証に使用するユーザ

のログイン名とパスワードを入力してください。


GUIが正常に指定サーバに接続した場合、GUIは、新しいサーバが検出されなくなるまで、クラスタ内

にあるすべての既知のサーバへの接続 (およびステータス表示への追加 )を継続します。

注記 :最初のログイン名とパスワードが、クラスタ内のサーバ上にあるクライアントで認証に失敗した場

合、そのサーバでの別のログイン名とパスワードを入力するように要求されます。 [Password]ダイアログ

202 User Guide

クラスタからの切断

で [Cancel]を選択した場合、サーバへの接続は中止され、GUIはクラスタ内の残りのコンポーネントへ

の接続を継続します。

クラスタからの切断

この作業は、選択したサーバ経由で、GUI クライアントをクラスタ内のすべてのサーバから切断します。


l グローバルツールバーの [Disconnect]ボタンをクリックする。

l [Edit] メニューの [Server]を選択し、[Disconnect]をクリックする。

l サーバのコンテキストツールバーが表示される場合は、そこにある [Disconnect]ボタンをク

リックする。

2. [Cluster Disconnect]ダイアログの [Select Server in Cluster]リストから、切断するクラスタ内の

サーバ名を選択してください。

3. [OK]をクリックしてください。クラスタ内の全サーバのリストを持つ [Confirmation]ダイアログが表

示されます。

4. [Confirmation]ダイアログの [OK]をクリックして、クラスタ内の全サーバからの切断を確定してく

ださい。

クラスタからの切断後、そのクラスタ内にあるすべてのサーバが、GUIのステータス表示から消去されま

す。

接続サーバの表示

サーバの状態は、下図に示すように、表内のサーバのグラフィック表示で表されます。サーバアイコンが

視覚的に示すサーバの状態の詳細については、サーバの状態の表示を参照してください。

サーバのステータスの表示

サーバの状態は、下図に示すように、表内のサーバのグラフィック表示で表されます。


サーバのプロパティの表示

サーバの状

態

状態の

シンボル意味

ALIVE

クライアントはサーバに有効な接続を行うことができます。

このサーバからALIVEのリモートサーバへのコミュニケーションパスがALIVEです。

DEAD とマークされたコミュニケーションパス、およびDEADのサーバをターゲ

ットとするコミュニケーションパスは無視されます。これは、DEADのサーバに

はDEADのグラフィックで表されるからです。

ALIVE

クライアントはサーバに有効な接続を行うことができます。

このサーバから指定リモートサーバへの1つ以上のコミュニケーションパスが

DEADです。

このサーバから指定リモートサーバへの間には、冗長コミュニケーションパスが

存在しません。

DEAD クラスタ内の他のサーバからDEAD として報告されました。

UNKNOWN ネットワーク接続が失われました。最後に分かっている LifeKeeperの状態

がALIVEです。

サーバのプロパティの表示


l プロパティを表示するサーバのアイコンを右クリックします。サーバのコンテキストメニューが

表示されたら、[Properties]をクリックします。サーバのプロパティは、サーバをクリックすると

プロパティパネル (有効になっている場合 )にも表示されます。

l [Edit] メニューの [Server]をポイントし、[Properties]をクリックします。ダイアログが表示さ

れたら、表示するサーバを [Server]リストから選択します。

2. 別のサーバのプロパティを表示する場合は、サーバを [Server]リストから選択してください。

3. 確認が完了したら、[OK]をクリックしてウィンドウを閉じてください。

サーバのログファイルの表示


l サーバのアイコンを右クリックしてサーバのコンテキストメニューを表示し、次に [View Log]をクリックして [LifeKeeper Log Viewer]ダイアログを表示する。

l グローバルツールバーの [View Log]ボタンをクリックし、 [LifeKeeper Log Viewer]ダイアロ

グの [Server] リストから、表示するサーバを選択する。

l サーバのコンテキストツールバーが表示される場合は、その [View Log]ボタンをクリックす

204 User Guide

リソースのタグと IDの表示

る。

l [Edit] メニューの [Server]をポイントし、[View Log]をクリックする。次に、[LifeKeeperLog Viewer]ダイアログの [Server] リストから、表示するサーバを選択する。

2. グローバルツールバーまたは [Edit] メニューから捜査を開始して、別のサーバのログを表示する

場合は、 [LifeKeeper Log Viewer]ダイアログの [Server]リストから、そのサーバを選択します。

サーバのコンテキストメニューまたはサーバのコンテキストツールバーから [View Log]を選択した

場合は、この機能は使用できません。

3. 確認が完了したら、[OK]をクリックして [Log Viewer]ダイアログを閉じてください。

リソースのタグと IDの表示

リソースのタグと IDを即座に表示するには、 [Status]ウィンドウのリソースアイコンにカーソルを合わせて、

マウスの左ボタンを 1回押します (シングルクリック)。優先順位が最も低いサーバのリソースのタグと IDが

メッセージバーに表示されます。特定サーバ上にあるリソースのタグと IDを表示する場合は、表内のリ

ソースインスタンスセルを左クリックしてください。

メッセージバーに表示されるメッセージは、以下のようになります。

Resource Tag = ipdnet0-153.98.87.73, Resource ID = IP-153.98.87.73

特定の状況では、GUIがリソース IDを特定できないことがあります。この場合は、リソースタグのみがメ

ッセージバーに表示されます。

リソースのステータスの表示

リソースのステータスつまり状態は、グローバルリソースのステータス (すべてのサーバについて)とサーバリ

ソースのステータス (1台のサーバ上 )の2つの形式で表示されます。グローバルリソースのステータス

は、[Status]ウィンドウの左ペインにあるリソース階層ツリーに表示されます。サーバリソースのステータス

は、リソースの列とサーバ行の交点にある表のセルにあります。

サーバリソースのステータス

下図に、アクティブ、スタンバイ、および不明のリソースステータスを持つサーバを示します。

l 「wallace」上のリソースはすべて、アクティブです。

l 「gromit」、「pat」、「mike」、および「batman」上のリソースはすべてスタンバイです。

l 「bullwinkle」上のリソースはすべて、不明です。


グローバルリソースのステータス

サーバリソー

スの状態

状態の

シンボル意味

アクティブこのサーバ上でリソースは動作可能であり、保護されています。 (ISP)

可用性の低

下

このサーバ上でリソースは動作可能ですが、バックアップリソースによる

保護はされていません。 (ISU)

スタンバイサーバは、リソースの動作を引き継ぐことができます。(OSU)

障害このサーバ上のリソースに問題が検出されました。例えば、リソースを

In Serviceにする試行が失敗しました。(OSF)

不明リソースが初期化されていないか (ILLSTATE)、このサーバで

LifeKeeperが動作中でありません。

空のパネ

ルサーバのリソースが定義されていません。

グローバルリソースのステータス

206 User Guide

リソースのプロパティの表示

状態の

シンボ

ル

説明意味 /原因

正常リソースがアクティブ (ISP)で、バックアップがアクティブで

す。

警告リソースがアクティブ (ISP)です。1つ以上のバックアップ

が、不明または障害 (OSF)としてマークされています。

障害。リソースが、いずれのサーバ

でもアクティブでありません (OSF)。

リソースが、通常の原因によりOut of Serviceになりま

した。

リソースが、通常ではない方法により動作が停止しま

した。

リカバリは完了していないか、失敗しました。

不明。利用可能な情報からは、

状態を特定できませんでした。

複数のサーバがアクティブであることを告げています。

サーバへの接続が遮断されました。

サーバのリソースインスタンスがすべて、不明の状態で

す。

リソースのプロパティの表示


l プロパティを表示するリソース /サーバの組み合わせのアイコンを右クリックします。リソース

のコンテキストメニューが表示されたら、[Properties]をクリックします。リソースのプロパティ

は、プロパティパネル (有効になっている場合 )にも表示されます。

l プロパティを表示するグローバルリソースのアイコンを右クリックします。リソースのコンテキス

トメニューが表示されたら、[Properties]をクリックします。ダイアログが表示されたら、表

示するリソースが存在するサーバを [Server] リストから選択します。

l [Edit] メニューの [Resource]をポイントし、[Properties]をクリックします。ダイアログが表

示されたら、プロパティを表示するリソースを [Resource]リストから選択し、表示するリ

ソースが存在するサーバを [Server]リストから選択します。

2. 別のリソースのプロパティを表示する場合は、リソースを [Resource]リストから選択してください。

3. 別のサーバ上にあるリソースのプロパティを表示する場合は、サーバを [Server]リストから選択し

てください。

4. 確認を終了したら、[OK]をクリックしてウィンドウを閉じてください。

[Status] ウィンドウの表示オプションの設定

[Options]ダイアログは、[View]メニューから表示できます。[Options]ダイアログで、LifeKeeperのさまざ


Resource Labels

まな表示形式を指定できます。これらの設定、およびチェックボックスのメニュー項目の全ての設定とさ

まざまなウィンドウサイズは、クライアントマシンのホームフォルダにあるファイル .lkGUIpreferencesで複数

のセッションにわたって保存されます。このファイルは、Webクライアントとアプリケーションクライアントの両

方が使用します。各クライアントマシンの優先設定は、他のマシンの優先設定から独立しています。2台のマシンで優先設定を同期する場合は、優先ファイルを恒常的に共有するか、一時的にマシン間

でコピーを移動します。

1. [View] メニューの [Options]をクリックしてください。 [View Options]ダイアログが表示されます。

2. [Status]ウィンドウでのリソースの表示位置を変更するには、[Display Options]タブをクリック

し、変更するオプショングループを選択してください。以下に示すオプショングループの詳細説明


3. [OK]をクリックして設定を保存し、 [Status]ウィンドウに戻ってください。

Resource Labelsこのオプショングループを使用すると、リソース階層ツリー内のリソースを、タグ名別と ID別のいずれで表

示するかを指定できます。

注記 : リソース階層ツリーに表示されるリソースタグ /IDは、優先順位が最も低い番号を持つサーバに

属します。特定サーバ上にあるリソースのタグ /IDを表示する場合は、表内のリソースインスタンスセル

を左クリックしてください。メッセージバーにそのタグ /IDが表示されます。

By tag name:

By ID:

Resource Treeこのオプショングループを使用すると、リソース階層ツリー内に表示するリソースのソート順序を指定でき

ます。

208 User Guide

Comm Path Status

l Sort By Resource -リソースラベルのみを基準にしてリソースをソートします。

l Sort By Cluster -同じサーバクラスタに属するリソースがグループ化されるように、サーバクラスタ

とリソースラベルを基準にしてソートします。

l No Sort -ソートを無効にします。リソースは、GUIが検出した順序で表示されます。

リソース階層ツリーの上位リソースは、ツリー内のリソースを左クリックして新しい位置に「ドラッグ」するこ

とで手動ソートできます。順序は、移動したリソース、およびツリー内の移動先の位置によって異なりま

す。

注記 : 「0」と「9」のキーは、リソース階層ツリーの展開 /折り畳みを即座に実行するホットキー /アクセラ

レータキーとして指定されています。マウスも、ツリー全体の展開や折り畳みに使用できます。リソース

階層ツリーのタイトル領域をクリックし、ダブルクリックするとツリーが展開します。クリックするとツリーが折り

畳まれます。

Comm Path Statusこのオプショングループを使用すると、サーバの状態のグラフィックに表示するコミュニケーションパスの状態

の形式を指定できます。

l Warn if No Redundancy - 1組のサーバ間のコミュニケーションパスが冗長コミュニケーションパス

として設定されていない場合、サーバの警告グラフィックを表示します。

l No Redundancy Required - 1組のサーバ間に冗長コミュニケーションパスがないことを無視し

ますが、コミュニケーションパスに障害が発生した場合にはサーバの警告グラフィックを表示しま

す。

Row Heightこのオプショングループを使用すると、表内の行の高さを指定できます。選択肢は [Default]、[Small]、および [Smallest]です。

注記 : 「+」と「-」のキーは、リソース階層ツリー内と表内にあるリソースのサイズを即座に変更するホット

キー /アクセラレータキーとして指定されています。

Column Widthこのオプショングループを使用すると、表内のサーバとリソースの列幅を指定できます。選択肢は以下の

とおりです。

l Default:標準の幅。

l Custom:ドロップダウンリストから幅 (ピクセル単位 )を選択できます。

l Automatic:使用可能な領域全体に収まるように、すべての列のサイズを自動変更します。

注記 : 「7」と「8」のキーは、リソース階層の表内にあるリソース列のサイズを即座に変更するホットキー /アクセラレータキーとして指定されています。


メッセージ履歴の表示

メッセージ履歴の表示

1. [View] メニューの [History]をクリックしてください。LifeKeeper GUIの [Message History]ダイアロ

グが表示されます。

2. 履歴のメッセージをすべて消去する場合は、[Clear]をクリックしてください。

3. ダイアログを閉じるには、[OK]をクリックしてください。

[Message History]ダイアログには、メッセージバーからの最新のメッセージが表示されます。履歴リスト

には、最大 1000行を表示できます。最大行数を超えた場合、新しいメッセージにより最も古いメッ

セージが「押し出され」ます。

これらのメッセージは、クライアントとサーバとの間の動作のみを表し、時系列で表示されます。最新のメ

ッセージがリストの上部に表示されます。

メッセージ履歴の解釈

<--は、メッセージがサーバから受信したことを示し、通常は以下の形式をとります。

<--"server name":"action"

<--"server name":"app res":"action"

<--"server name":"res instance":"action"

-->はメッセージがクライアントから送信されたことを示し、通常は以下の形式をとります。

-->"server name":"action"

-->"server name":"app res":"action"

-->"server name":"res instance":"action"

[Clear]ボタンをクリックすると、履歴が消去されますが、ダイアログは閉じません。

[OK]ボタンをクリックすると、履歴を消去せずにダイアログが閉じます。

210 User Guide

リソース階層ツリーの展開と折り畳み

リソース階層ツリーの展開と折り畳み

このツリーのセグメントでは、リソース file_system_2が展開されており、リソースnfs-/opt/qe_auto/NFS/export1が折り畳まれています。

展開されているリソースアイコンの左には、が表示されます。

折り畳まれているリソースアイコンの左には、が表示されます。

リソース階層ツリーを展開するには、

l をクリックするか、

l の右側にあるリソースアイコンをダブルクリックしてください。

リソース階層ツリーをすべて展開するには、

l [View] メニューの [Expand Tree]をクリックするか、

l [Status]ウィンドウの左ペインにある列ヘッダの [Resource Hierarchy Tree]ボタンをダブルクリッ


注記 : リソース階層ツリーに表示されるリソースタグ /IDは、優先順位が最も低い番号を持つサーバに

属します。特定サーバ上にあるリソースのタグ /IDを表示する場合は、表内のリソースインスタンスセル

を左クリックしてください。メッセージバーにそのタグ /IDが表示されます。

リソース階層ツリーを折り畳むには、

l をクリックするか、

l の右側にあるリソースアイコンをダブルクリックしてください。

リソース階層ツリーをすべて折り畳むには、

l [View] メニューの [Collapse Tree]をクリックするか、

l [Status]ウィンドウの左ペインにある列ヘッダの [Resource Hierarchy Tree]ボタンをダブルクリッ



[Cluster Connect]ダイアログ

注記 : 「9」と「0」のキーは、すべてのリソース階層ツリーに対して即座に展開 /折り畳みを実行するホッ

トキー /アクセラレータキーとして指定されています。

[Cluster Connect] ダイアログ

Server Name -接続先のサーバ名。

Login -接続先のサーバに LifeKeeper認証情報を持つユーザのログイン名。

Password -接続先のサーバで指定ログインを認証するパスワード。

[Cluster Disconnect] ダイアログ

Select Server in Cluster -

接続しているサーバの名前がドロップダウンリストボックスに表示されます。リストから、切断するクラスタ

のサーバを選択してください。切断されるクラスタ内のすべてのサーバが、確認ダイアログに表示されま

す。

212 User Guide

[Resource Properties]ダイアログ

[Resource Properties] ダイアログ

[Resource Properties]ダイアログは、 [Edit] メニューやリソースのコンテキストメニューから使用できます。

このダイアログには、サーバ上にある特定のリソースのプロパティが表示されます。 [Edit] メニューからアク

セスした場合は、リソースとサーバを選択できます。リソースコンテキストメニューからアクセスした場合、

はサーバを選択できます。

[General] タブl Tag -リソースインスタンスの名前。システムに対して一意で、管理者にリソースを示します。

l ID -リソースインスタンスに関連する文字列であり、リソースタイプのすべてのインスタンス間で一

意です。関連するアプリケーションソフトウェアに対して、リソースインスタンスの内部特性のいくつ

かを示します。

l Switchback (管理者権限を持つユーザは編集可能 ) - In Serviceのリソースが存在するサーバ

に障害が発生した場合に、サーバのリカバリ動作を管理する設定。この設定が [Intelligent]の場合、指定リソースの可能なバックアップとしてサーバが動作します。この設定が [Automatic]の場合、サーバはアクティブにリソースの再取得を試行します (以下の条件が満たされる場合 )。

l サーバがクラスタから離れるときには、リソース階層のサービスが既に in serviceである必


l リソース階層がすべて in serviceである場合は、低プライオリティのサーバで in serviceである必要があります。

注記 :自動スイッチバックのチェックは、LifeKeeperを起動したとき、またはクラスタに新し

いサーバを追加したときにのみ実行されます。通常のクラスタ動作中には実行されませ

ん。

l State -リソースインスタンスの現在の状態。

l Active—ローカルで In Serviceであり、保護されています。

l Warning -ローカルで In Serviceですが、ローカルリカバリは試行されません。

l Failed - Out of Service、障害。

l Standby - Out of Service、障害なし。

l LLSTATE - LifeKeeperの起動シーケンスの一部として実行されるリソース初期化プロセ

スにより適切に初期化されていません。この状態のリソースは、LifeKeeperで保護されて

いません。

l UNKNOWN -リソースの状態を特定できませんでした。GUIサーバが使用できない可能


l Reason -存在する場合、リソースが現在の状態にある原因 (つまり、最後の状態変化の原因 )を示します。例えば、galahad上にあるアプリケーションの状態がOSUである原因は、 tristan上にある共有プライマリリソースordbfsaa-on-tristanの状態が ISPか ISUであることです。共有リ

ソースは、グループ内の1つのシステムでのみ同時にアクティブにできます。


[Relations] タブ

l Initialization -起動時のリソースの初期化動作を決定する設定であり、AUTORES_

ISP、INIT_ISP、INIT_OSUなどがあります。

[Relations] タブl Parent -このリソースに直接依存するリソースのタグ名を示します。

l Child -このリソースが依存するすべてのリソースのタグ名を示します。

l Root -このリソース階層で、親を持たないリソースのタグ名。

[Equivalencies] タブl Server -リソースが定義済みの同等性を持つサーバ名。

l Priority (管理者権限を持つユーザは編集可能 ) -このリソースについて、ターゲットサーバのフェ

イルオーバの優先順位の値。

l Tag -同等のサーバ上にあるこのリソースのタグ名。

l Type -同等のタイプ (SHARED、COMMON、COMPOSITE)。

l Reorder Priorities (管理者権限を持つユーザは編集可能 ) - [Up]/[Down]ボタンを使用して、

選択した同等リソースの優先順位を並べ替えることができます。

[OK]ボタンをクリックすると、変更内容が適用されてウィンドウが閉じます。 [Apply]ボタンをクリックする

と、変更内容が適用されます。 [Cancel]ボタンをクリックすると、最後に [Apply]をクリックして以降の変

更内容を保存せずに、ウィンドウが閉じます。

[Server Properties] ダイアログ

[Server Properties]ダイアログは、サーバのコンテキストメニューや[Edit] メニューから使用できます。このダ

イアログには、特定のサーバのプロパティが表示されます。サーバのプロパティは、プロパティパネル (有効

になっている場合 )にも表示されます。

このダイアログの3つのタブについて説明します。 [OK]ボタンをクリックすると、変更内容が適用されてウ

ィンドウが閉じます。 [Apply]ボタンをクリックすると、変更内容が適用されます。 [Cancel]ボタンをクリック

すると、最後に [Apply]をクリックして以降の変更内容を保存せずに、ウィンドウが閉じます。

214 User Guide

[General] タブ

[General] タブ

l Name -選択したサーバの名前。

l State -サーバの現在の状態。サーバの状態は以下の値をとります。

l ALIVE -サーバが使用可能。

l DEAD -サーバが使用不可。



l Permission -そのサーバに現在ログインしているユーザの権限レベル。権限は以下の値をとりま

す。

l Administrator -ユーザは LifeKeeperのすべての作業を実行できます。

l Operator -ユーザは、LifeKeeperのリソースとサーバのステータスを監視でき、リソースを inserviceまたは out of serviceにすることができます。

l Guest -ユーザは LifeKeeperのリソースとサーバのステータスを監視できます。


[General] タブ

l Shutdown Strategy (管理者権限を持つユーザは編集可能 ) -サーバがシャットダウンしたとき

に、リソースがクラスタ内のバックアップサーバにスイッチオーバするかどうかを制御する設定。設

定「Switchover Resources」は、リソースがクラスタ内のバックアップサーバで in serviceになること

を示します。設定「Do not Switchover Resources」は、リソースがクラスタ内にある別のサーバで

in serviceにならないことを示します。

l Failover Strategy -この設定を使用して、LifeKeeperのクラスタ内にある特定システムからのフ

ェイルオーバをユーザに確定するよう要求できます。この設定は、LifeKeeperの管理者のみが使

用できます。オペレータとゲストには、この設定は表示されません。デフォルトでは、フェイルオーバ

はすべて、ユーザの操作を必要とせず自動実行されます。ただし、フェイルオーバ確認フラグが

設定されると、指定システムからフェイルオーバするには、以下のコマンドを実行して確定するこ

とが必要です。lk_confirmso -y system.以下のコマンドを実行して、フェイルオーバをブロ

ックできます。lk_confirmso -n system.指定期間内にこれらのコマンドのいずれかが実行

されない限り、システムは事前プログラミングされたデフォルト動作を実行します。

/etc/default/LifeKeeperファイル内にある 2つのフラグが、この自動動作を制御します。

l CONFIRMSODEF

これは、デフォルト動作を指定します。「0」に設定されている場合、デフォルト動作はフェ

イルオーバを実行します。「1」に設定されている場合、デフォルト動作はフェイルオーバを

ブロックします。

l CONFIRMSOTO

これは秒単位で設定され、デフォルト動作を実行する前に LifeKeeperが待機する時間

を示します。

216 User Guide

[CommPaths] タブ

[CommPaths] タブ

l Server -LifeKeeperのクラスタ内で、コミュニケーションパスが接続している他のサーバのサーバ

名。

l Priority - 2台のサーバ間でコミュニケーションパスを使用する順序を定義する優先順位。1が最高の優先順位で、99が最低の優先順位です。

l State -LifeKeeperの設定データベース (LCD)のコミュニケーションパスの状態。コミュニケーション

パスの状態は以下の値をとります。

l ALIVE -通常の動作をしています。

l DEAD -通常の動作をしていません。

l UNKNOWN -状態を特定できませんでした。GUIサーバが使用できない可能性があり

ます。

l Type -リスト内のサーバと、 [Server] フィールドに指定されたサーバとの間のコミュニケーションパス

の種類。TCP (TCP/IP)、または TTY。

l Address/Device -コミュニケーションパスが使用する IPアドレスまたはデバイス名。

l Comm Path Status - LifeKeeperの設定データベース (LCD)内のコミュニケーションパスの状態

に基づいて、GUIが判定したコミュニケーションパスのステータスの概要。以下に、コミュニケーショ


[Resources] タブ

ンパスのステータスの値を示します。これらの値は、下のパネルの詳細テキストの下に表示されま

す。

l NORMAL -すべてのコミュニケーションパスが通常の動作をしています。

l FAILED -指定サーバに対するすべてのコミュニケーションパスが動作していません。

l UNKNOWN -コミュニケーションパスのステータスを特定できませんでした。GUIサーバが

使用できない可能性があります。

l WARNING -指定サーバに対する 1つ以上のコミュニケーションパスが動作していませ

ん。

l DEGRADED -指定サーバに対する 1つ以上の冗長コミュニケーションパスが動作してい

ません。

l NONE DEFINED -コミュニケーションパスが定義されていません。

[Resources] タブ

218 User Guide

オペレータの作業

l Name -選択したサーバ上にあるリソースインスタンスのタグ名。

l Application -リソースタイプのアプリケーション名 (gen、scsiなど)。

l Resource Type -サービスを提供するリソースタイプ、ハードウェアのクラス、ソフトウェアのクラス、

またはシステムのエンティティのクラス (app、 filesys、nfs、device、diskなど)。

l State -リソースインスタンスの現在の状態。

l ISP—ローカルで In Serviceであり、保護されています。

l ISU -ローカルで In Serviceですが、ローカルリカバリは試行されません。

l OSF - Out of Service、障害。

l OSU - Out of Service、障害なし。

l LLSTATE - LifeKeeperの起動シーケンスの一部として実行されるリソース初期化プロセ

スにより、リソースの状態が適切に初期化されていません。この状態のリソース

は、LifeKeeperで保護されていません。



オペレータの作業

以下のトピックは、オペレータの権限を必要とする高度な作業です。

リソースを In Service にする


l in serviceにするリソース /サーバの組み合わせのアイコンを右クリックします。リソースのコ

ンテキストメニューが表示されたら、[In Service]をクリックします。

l in serviceにするグローバルリソースのアイコンを右クリックします。リソースのコンテキストメ

ニューが表示されたら、[In Service]をクリックします。ダイアログが表示されたら、 inserviceにするリソースが存在するサーバを [Server]リストから選択し、[Next]をクリックし

ます。

l グローバルツールバーの [In Service]ボタンをクリックします。ダイアログが表示されたら、 inserviceにするリソースが存在するサーバを [Server]リストから選択し、[Next]をクリックし

ます。次のダイアログで、 in serviceにするリソースを 1つ以上 [Resouce(s)]リストから選

択し、[Next]をもう一度クリックします。

l リソースのコンテキストツールバーが表示される場合は、その [In Service]ボタンをクリック

します。

l [Edit] メニューの [Resource]をポイントし、[In Service]をクリックします。ダイアログが表

示されたら、 in serviceにするリソースがあるサーバを [Server]リストから選択し、[Next]をクリックします。次のダイアログで、 in serviceにするリソースを 1つ以上 [Resouce(s)] リストから選択し、[Next]をもう一度クリックします。

2. 選択したサーバとリソースを In Serviceにすることを示すダイアログボックスが表示されます。親リ


リソースをOut of Serviceにする

ソースの in serviceにせずに依存する子リソースを in serviceにしようとする場合、このダイアログ

には警告も表示されます。[In Service]をクリックして、依存する子リソースと共にリソースを inserviceにしてください。

3. 出力パネルが有効の場合は、ダイアログが閉じ、リソースを In Serviceにするコマンドの結果が

出力パネルに表示されます。出力パネルが無効の場合は、これらの結果を表示するダイアログ

が表示されたままになり、結果がすべて表示されたら [Done]をクリックします。 in serviceになっ

た追加の依存 (子 )リソースが、ダイアログまたは出力パネルに表示されます。

4. リソースを in serviceにする動作で発生したエラーは、 in serviceにするリソースがあるサーバの

LifeKeeperログに記録されます。

リソースを Out of Service にする


l Out of Serviceにするグローバルリソース、またはリソース /サーバの組み合わせのアイコン

を右クリックします。リソースのコンテキストメニューが表示されたら、[Out of Service]をクリ

ックします。

l グローバルツールバーの [Out of Service]ボタンをクリックします。 [Out of Service]ダイアログ

が表示されたら、 Out of Serviceにするリソースを 1つ以上 [Resouce(s)] リストから選択

し、[Next]をクリックします。

l リソースのコンテキストツールバーが表示される場合は、[Out of Service]ボタンをクリック

します。

l [Edit] メニューの [Resource]をポイントし、[Out of Service]をクリックします。[Out ofService]ダイアログが表示されたら、 Out of Serviceにするリソースを 1つ以上

[Resouce(s)] リストから選択し、[Next]をクリックします。

2. 選択したリソースがOut of Serviceになることを示す [Out of Service]ダイアログボックスが表示

されます。親リソースをOut of Serviceにせずに依存する子リソースをOut of Serviceにしようとす

る場合、このダイアログには警告も表示されます。[Out of Service]をクリックして、次のダイアロ

グボックスに進みます。

3. 出力パネルが有効の場合は、ダイアログが閉じ、リソースをOut of Serviceにするコマンドの結

果が出力パネルに表示されます。出力パネルが無効の場合は、これらの結果を表示するダイア

ログが表示されたままになり、結果がすべて表示されたら [Done]をクリックします。

4. リソースをOut of Serviceにする動作で発生したエラーは、 Out of Serviceにするリソースが存在

するサーバのLifeKeeperログに記録されます。

高度な作業

LCD

LifeKeeper設定データベース

220 User Guide

関連トピック

LifeKeeper設定データベース (LCD)は、LifeKeeperが既知のすべてのリソースタイプについて、オブジェ

クト指向のリソース階層情報を管理し、リカバリ方向の情報を保存します。データは共有メモリにキャッ

シュされ、ファイルに保存されるので、システムの再起動後もデータが保持されます。LCDには、リカバリ

が必要なリソースインスタンスについての状態の情報、および特定の詳細情報もあります。

LCDのディレクトリ構造、保存されるデータタイプ、使用できるリソースタイプ、およびアプリケーションスク

リプトの使用の詳細については、以下の関連トピックを参照してください。

関連トピック

LCDI のコマンド

LifeKeeperには、アプリケーションのリソース階層を定義するためのメカニズムが2つ用意されています。

l LifeKeeperのGUI

l LifeKeeper設定データベースのインターフェース (LCDI)コマンド

LCDIは LifeKeeperが提供するインターフェースコマンドのセットで、使用するアプリケーションのニーズに

合わせてリソース階層の設定の作成とカスタマイズができます。アプリケーションが複数のリソース (例 : 2つ以上のファイルシステム)に依存する場合、コマンドインターフェースを使用します。

コマンドの詳細については、LCDIのマニュアルページを参照してください。このトピックでは、開発シナリ

オを示し、GUI とコマンドの両方の機能を使用してリソース階層を作成できる方法を説明します。

シナリオの状況

アプリケーションの例であるProjectPlanは、サーバ1とサーバ2が共有するSCSI ファイルシステムに

データを保存しています。サーバ1が、アプリケーションのプライマリ階層にあります。アプリケーションに

は、 /project-dataと /scheduleの2つのファイルシステムがあります。階層定義の最初の手順では、依

存関係を指定します。

このアプリケーションの例には、以下の依存関係があります。

l 共有ファイルシステム。アプリケーションは、 /project-dataと /scheduleのファイルシステムに依存し

ます。

l SCSI ディスクサブシステム。 .次に、ファイルシステムは、SCSIディスクサブシステム (デバイス、ディ

スク、およびホストアダプタのリソースを含む)に依存します。

結果として、階層を作成する作業は以下の図のようになります。


階層の定義

階層の定義

この例のアプリケーション階層を作成するために必要な作業を示します。

1. ファイルシステムリソースの作成。LifeKeeperのGUIには、ファイルシステムリソースを作成するメ

ニューがあります。ファイルシステムリソース階層の作成を参照してください。

この定義作業の最後で、LCDでは 2つのファイルシステムリソースが以下のように定義されま

す。

ID タグサーバ

/project-data/project-data

project-data-on-Server1project-data-from-Server1

Server1Server2

/schedule/schedule

schedule-on-Server1schedule-from-Server1

Server1Server2

注記 : LifeKeeperで使用されるタグ名には意味はありません。単なるラベルです。表内のタグ名

は LifeKeeperのデフォルト値です。

2. リソースの定義。この例では、以下の項目を定義する必要があります。

アプリケーション: projectapp

リソースタイプ: plan

インスタンス ID: 1yrplan

タグ: the-project-plan

222 User Guide

階層の定義

注記 : LifeKeeperのGUIを使用して定義の大部分を作成できますが、この例の以降ではコマ

ンドインターフェースの操作を説明します。

3. ディレクトリの作成。各システムで以下のコマンドを使用して、ディレクトリ

/opt/LifeKeeper/subsysの下に必要なアプリケーションリカバリディレクトリを作成します。

mkdir -p

/opt/LifeKeeper/subsys/projectapp/Resources/plan/actions

4. アプリケーションの定義。以下のコマンドで、アプリケーション projectappを作成します。

app_create -d Server1 -a projectapp

app_create -d Server2 -a projectapp

5. リソースタイプの定義。以下のコマンドで、リソースタイプ planを作成します。

typ_create -d Server1 -a projectapp -r plan

typ_create -d Server2 -a projectapp -r plan

6. リカバリスクリプトのインストール。restoreと removeのスクリプトを各サーバの以下のディレクトリに

コピーします。

/opt/LifeKeeper/subsys/projectapp/Resources/plan/actions

7. インスタンスの定義。以下のコマンドで、リソースのインスタンスタイプがplan、 IDが1yrplanのリ

ソースを定義します。

ins_create -d Server1 -a projectapp -r plan -I\

AUTORES_ISP -t the-project-plan -i 1yrplan

ins_create -d Server2 -a projectapp -r plan -I\

SEC_ISP -t the-project-plan -i 1yrplan

Server1に作成したインスタンスの -I AUTORES_ISP命令は、LifeKeeperの再起動時

にそのリソースを自動的に in serviceにするように LifeKeeperに指示します。この例で

は、リソースの restoreスクリプトが実行され、正常に実行された場合はリソースが ISP状態になります。この動作は、ペアのリソースがすでにサービス起動している場合は実行

されません。

Server2に作成したインスタンスの -I SEC_ISP命令は、LifeKeeperの再起動時にその

リソースを in serviceにしないように LifeKeeperに指示します。その代わり、Server2はServer1上にあるリソースのバックアップとして機能し、プライマリのリソースまたはサーバに

障害が発生したときにローカルリソースを in serviceにします。

8. 依存関係の定義。以下のコマンドは、アプリケーションとファイルシステムの依存関係を定義し

ます。

dep_create -d Server1 -p the-project-plan -c project-data-on-

System1

dep_create -d Server2 -p the-project-plan -c project-data-

from-Server1


LCDの設定データ

dep_create -d Server1 -p the-project-plan -c schedule-on-

Server1

dep_create -d Server2 -p the-project-plan -cschedule-from-

Server1

9. lcdsyncの実行。以下のlcdsyncコマンドを実行して、設定のコピーを更新するように

LifeKeeperに通知します。

lcdsync -d Server1

lcdsync -d Server2

10. リソースを In Serviceにする。プライマリサーバで LifeKeeperのGUIにアクセスし、 [Edit] >[Resource]> [In-Service]をクリックしてリソースを In Serviceにします。

LCDの設定データ

LCDには、以下の関連するデータタイプが保存されます。

l 依存関係の情報

l リソースのステータス情報

l サーバ間のイクイバレンシ情報

依存関係の情報

定義した各リソースについて、LifeKeeperは依存関係のリスト、および依存物 (あるリソースに依存す

るリソース)のリストを保持します。詳細については、LCDI_relationship (1M)とLCDI_

instances (1M)のマニュアルページを参照してください。

リソースのステータス情報

LifeKeeperは、各リソースインスタンスのステータス情報をメモリに保持します。LCDが認識するリソース

の状態は、 ISP、 ISU、OSF、OSU、および ILLSTATEです。システムイベントが発生した場合、また

は管理者が特定の操作を行った場合に、リソースがある状態から別の状態に変化することがありま

す。リソースの状態が変化した場合、ステータスの変化が、ローカルサーバのLCD、およびそのリソース

のダイアログサーバ上にあるデータベースに反映されます。

サーバ間のイクイバレンシ情報

さまざまなサーバ上にある複数のリソース間に関係が存在することがあります。イクイバレンシ情報とは、

別のサーバ上にある 2つのリソースが同一の物理エンティティであることを示す関係です。2台のサーバ

が、イクイバレンシ情報の関係にある 1つのリソースを持つ場合、LifeKeeperはその動作により、2台の

サーバ上にあるリソースの1つのみが同時に In Service、保護 (ISP)になるようにします。両方のサーバ

でそのリソースインスタンスをOut of Service (OSU またはOSF)にすることができますが、データの整合

性の理由から、同時に In Serviceにできるリソースは 1つのみです。

224 User Guide

LCDのディレクトリ構造

SCSIバス上にある複数のディスクが、同等なリソースの一例です。SCSIのロック (または予約 )メカニズ

ムにより、任意の時点でディスクデバイスのロックを所有できるのは 1台のサーバのみです。このロック所

有機能により、同時に複数のサーバによる同一ディスクリソースへのアクセスが防止されます。

さらに、階層内の依存関係により、ファイルシステムのようにディスクに依存するリソースはすべて、同時

に 1台のサーバでのみ In Serviceになります。

LCDのディレクトリ構造

/opt/LifeKeeperの下にある主なサブディレクトリを示します。

l config - LifeKeeperの設定ファイル。イクイバレンシ情報を含みます。

l bin - LifeKeeperの実行可能プログラム。 is_recoverableなどがあります。詳細については、障

害検出とリカバリのシナリオを参照してください。

l subsys -リソースとタイプ。LifeKeeperは、共有 SCSIディスクサブシステムのリソースとタイプの

定義を scsiで、汎用アプリケーションのメニュー機能を genで提供します。アプリケーションのイン

ターフェースを定義する場合は、subsysの下にディレクトリを作成してください。

l events -警報イベント。詳細については、LifeKeeperの警報とリカバリを参照してください。

/opt/LifeKeeper内のLCDディレクトリの構造については、 /opt/LifeKeeper内のLCDディレクトリの構

造のトピックを参照してください。

LCDのリソースタイプ

LCDは共有メモリ、および /opt/LifeKeeperディレクトリの両方に保持されます。ディレクトリ構造の図に

示すように、subsysには、アプリケーションインターフェースの指定に使用できるアプリケーションリソース

セットが2つあります。

l gen -汎用アプリケーションとファイルシステムの情報

l scsi - SCSIに固有のリカバリ情報

これらのサブディレクトリについてはリソースのサブディレクトリを参照してください。


ステータスの詳細表示の後部近くに、システムのフラグセットがあります。共通タイプは、プロセスのロック

が動作を完了するまで他のプロセスを確実に待機させるために使用する LCDのロックフラグです。LCDのロックの標準フォーマットは以下のとおりです。

!action!processID!time!machine:id.

一般的な LCDのロックフラグの例を示します。

l !action!02833!701236710!<servername>:filesys.ファイルシステム階層を作成す

ると、このフォーマットでステータス表示にフラグが生成されます。 filesysの指定は、他のアプリ

ケーションリソース階層では別のリソースタイプである場合も、一般的なアプリケーションやユーザ


リソースのサブディレクトリ

定義アプリケーションでは appである場合もあります。

l 他の代表的なフラグとして、!nofailover!machine and shutdown_switchoverがあり

ます。!nofailover!machineフラグは、LifeKeeperが作成と削除を行う内部の一時フラグ

で、サーバのフェイルオーバを制御します。 shutdown_switchoverフラグは、このサーバのシ

ャットダウン方針がスイッチオーバに設定されたことを示し、サーバのシャットダウンによりスイッチ

オーバが発生します。使用可能なフラグの詳細については、LCDI-flag (1M)を参照してくだ

さい。

リソースのサブディレクトリ

scsi とgen のディレクトリはそれぞれ、リソースのサブディレクトリを持ちます。これらのディレクトリの内容

は、LifeKeeperが提供するリソースタイプのリストです。

scsi のリソースタイプ。これらのリソースタイプは、 /opt/LifeKeeper/subsys/scsi/resourcesディレクトリに

あります。実際の設定によっては、その他のディレクトリが存在する場合があります。

l device -ディスクパーティション、または仮想ディスクデバイス

l disk -物理ディスク、または LUN

l hostadp -ホストアダプタ

gen のリソースタイプ。これらのリソースタイプは、 /opt/LifeKeeper/subsys/gen/resourcesディレクトリにあ

ります。

l filesys -ファイルシステム

l app -汎用またはユーザ定義のアプリケーションであり、他のリソースに依存することがある

各リソースタイプのディレクトリには、以下のものが1つ以上あります。

l インスタンス。このファイルは、LCDに保存されている、リソースインスタンスに関する恒久的な情

報を反映します。このリソースタイプに関連付けられたリソースインスタンスの記述的な情報があ

ります。

警告 :インスタンスファイル (または LCD ファイル)を直接変更しないでください。リソースインスタンスの作

成や操作を行うには、LifeKeeperのGUIの機能、または ins_create、 ins_remove、 ins_gettag、 ins_setas、 ins_setinfo、 ins_setinit、 ins_setstate、および ins_listのLifeKeeperのLCDI_instances コマン

ドのみを使用してください。これらのコマンドの詳細については、LCDI_instances (1M)のマニュアルペー

ジを参照してください。

l recovery。このオプションのディレクトリには、障害が検出されたリソースのローカルリカバリの試行

に使用されるプログラムがあります。recoveryディレクトリには、sendeventに渡されるイベントクラ

スに対応するディレクトリがあります。ディレクトリの名前は、sendeventプログラムに渡されるクラ

スパラメータ (-C)と一致する必要があります。 (LifeKeeperの警告とリカバリを参照 )。

各サブディレクトリに、アプリケーションは対応するイベントタイプを処理するリカバリプログラムを入れること

ができます。これらのプログラムの名前は、sendeventの -Eパラメータで渡される文字列と一致する必

要があります。このオプションのディレクトリは、複数のアプリケーションに使用されるように存在することは

できません。

226 User Guide

リソースの動作

l actions。このディレクトリには、特定のリソースタイプのリソースインスタンスについてのみ動作する

リカバリ実行プログラムのセットがあります。使用するアプリケーションについて、アプリケーション内

のすべてのリソースに適用する動作がある場合は、その動作を、resource typeディレクトリでは

なく、アプリケーションディレクトリのactionsサブディレクトリに入れてください。

リカバリ指示ソフトウェアが、リソースインスタンスの変更や復旧に使用されます。各リソースタイプの

actionsディレクトリに、removeと restoreの2つの動作が必要です。

リソースの動作

リソースタイプのactionsディレクトリには、特定のアプリケーションの動作を記述するプログラム (多くの

場合は shellスクリプト )があります。各リソースタイプについて、restoreと removeの2つの動作が必要

です。

removeと restoreのプログラムは、正反対の機能を実行する必要があります。つまり、相互の動作を

元に戻す必要があります。これらのスクリプトは、絶対に手動で実行しないでください。これらのスクリプ

トは、LifeKeeperのリカバリ動作と制御のインターフェース (LRACI)のperform_action shellプログラ

ムのみが実行する必要があります (LRACI-perform_action (1M)マニュアルページを参照 )。

/opt/LifeKeeperのLCDのディレクトリ構造

以下の図に、 /opt/LifeKeeperのディレクトリ構造を示します。


LCM

LCMThe LifeKeeper Communications Manager (LCM)は、1台以上のLifeKeeperサーバ上にあるプロセス

間に信頼性の高い通信を提供します。このプロセスは、システム間の冗長コミュニケーションパスを使

用できるので、1つのコミュニケーションパスに障害が発生しても、LifeKeeperやそれが保護するリソース

には障害が発生しません。LCMは、RS-232 (TTY)とTCP/IPの接続を含む多様な通信方法をサ

ポートしています。

LCMは以下の機能を提供します。

l LifeKeeper のハートビート。接続している他のLifeKeeperシステムと定期的に通信して、他の

システムが動作を継続しているかどうかを判断します。LifeKeeperはハートビート信号がないこと

を認識することにより、他の方法では検出されないシステム全体の障害を検出できます。

l 管理サービス。LifeKeeperの管理機能は、LCMの機能を使用してリモート管理を実行しま

す。この機能は、シングルポイントの管理、設定の検証、および管理動作の正常性チェックに

使用されます。

l 設定とステータスの通信。LifeKeeper設定データベース (LCD)は、リソースのステータス、可用

性、および設定を LCM機能経由で記録します。LCMの機能により、LCDはプライマリとセカン

ダリのシステム間で整合性のあるリソース情報を保持できます。

228 User Guide


l フェイルオーバリカバリ。あるシステム上のリソースに障害が発生すると、LCMは LifeKeeperに、

バックアップシステム上にリソースを復旧するように通知します。

LCMが提供する LifeKeeperのサービスに加えて、shellコマンドセットによりアプリケーションによる信頼

性の高いシステム間通信が可能です。これらのコマンドとして、snd_msg, rcv_msg、can_talkな

どがあります。これらのコマンドの詳細については、LCMI_mailboxes (1M)のマニュアルページを参

照してください。LCMはシステム上でリアルタイムプロセスとして動作し、システムのハートビートが送信さ

れるなどの重要な通信が確実に実行されるようにします。


ステータス表示の通信ステータスの情報のセクションには、LifeKeeperが認識しているサーバとその現在

の状態、および各コミュニケーションパスの情報がリストされます。

以下の例は、ステータスの簡略表示の通信ステータスのセクションのものです。

MACHINE NETWORK ADDRESSES/DEVICE STATE PRIO

tristan TCP 100.10.100.100/100.10.100.200 ALIVE 1

tristan TTY /dev/ttyS0 ALIVE --

詳細については、ステータスの詳細表示とステータスの簡略表示のトピックの「通信ステータスの情報」

セクションを参照してください。

LifeKeeperの警報とリカバリ

LifeKeeperのエラー検出と通知は、イベント警報メカニズムsendeventをベースにしていま

す。sendevent メカニズムの重要な概念は、独立したアプリケーションが重要なコンポーネントについて

警報を受信できるように登録できることです。警報を開始する側のコンポーネントと受信する側のアプリ

ケーションのいずれも、他のアプリケーションの存在を知るように変更する必要はありません。アプリケーシ

ョンに固有のエラーが、sendevent機能経由で LifeKeeperのリカバリメカニズムをトリガできます。

このセクションでは、警報クラス、警報の処理、および警報ディレクトリのレイアウトを含む警報に関連す

るトピックを説明し、次に警報の概念を示す処理シナリオを示します。

警報クラス

/opt/LifeKeeper/eventsディレクトリには、アラームクラスのセットがリストされます。これらのクラスは、イベ

ントを生成するシステムの特定サブコンポーネントに対応します (例 : filesys)。各警報クラスのサブディレ

クトリには、可能性のある警報のセットがあります (例 : badmount、diskfull)。shellスクリプトまたはプログ

ラムを適切なディレクトリに入れることで、これらの警報を受信するようにアプリケーションを登録できま

す。

LifeKeeperは基本的な警報通知機能を使用しています。この警報機能により、イベントについて登

録されたすべてのアプリケーションで、該当する警報の発生時に sendeventにより処理プログラムが非

同期で実行されます。LifeKeeperが存在する場合、sendevent プロセスははじめに、LifeKeeperのリ

ソースオブジェクトがクラスとイベントを処理できるかどうかを判断します。LifeKeeperがクラス/イベントの

一致を検出した場合、適切な復旧シナリオが実行されます。


警報の処理

sendevent警報機能の追加スクリプトを定義することは任意です。LifeKeeperリソースを定義する

と、LifeKeeperが基本的な警報機能を提供します。その詳細は、この章の処理シナリオで後述しま

す。

注記 : リソースインスタンスのローカルリカバリは、LifeKeeperの制御下にあるアプリケーションが、中断さ

れたリソースサービスを、イベントが発生したシステムのエンドユーザに返そうとする試行です。サーバ間リ

カバリでは、アプリケーションはバックアップシステムに移行できます。この種のリカバリは、ローカルリカバリ

が失敗したか、ローカルリカバリが不可能である場合に試行されます。

警報の処理

LifeKeeperの注意が必要な可能性のあるイベントを検出するアプリケーションまたはプロセス

は、sendeventプログラムを実行し、各エラークラス、エラー名、および障害のあるインスタンスの引数を

渡すことにより、イベントを報告できます。必須の詳細、オプションのパラメータ、および構文について

は、sendevent (5)のマニュアルページを参照してください。

警報ディレクトリのレイアウト

/opt/LifeKeeper/eventsディレクトリには、2種類の内容があります。

l LifeKeeper の指定クラス。LifeKeeperは、eventsディレクトリの下に lifekeeperと filesysの2つの警報クラスを用意しています。警報イベントの例として、noaccess とdiskfullがあります。警報

クラスは、sendevent コマンドの -Cオプションで渡される文字列に対応し、警報イベントは -Eオ

プションで渡される文字列に対応します。Lifekeeperの警報クラスは、LifeKeeperのサブシステ

ム内のイベント報告用に内部的に使用されます。

l アプリケーションに固有のクラス。特定のアプリケーションで警報クラスの定義が必要な場

合、eventsディレクトリに他のサブディレクトリが追加されます。アプリケーションは shellスクリプト

またはバイナリプログラムをそのサブディレクトリに入れることで、これらの警報を受信するように登

録します。これらのプログラムの名前は、属するアプリケーションパッケージの名前に由来します。

メンテナンス作業

以下に、LifeKeeperのメンテナンス作業を示します。

LifeKeeperの設定値の変更

LifeKeeperには、設定と設定を行った後に変更を要する場合がある値が多数あります。変更を要す

る場合がある値の例として、LifeKeeperサーバのuname、コミュニケーションパスの IPアドレス、 IP リソー

スのアドレス、タグ名などがあります。これらの値を変更するには、注意して以下の手順に従ってくださ

い。

1. 以下のコマンドを使用して、すべてのサーバで LifeKeeperを停止してください。

LKROOT/bin/lkstop

コミュニケーションパスを削除したり、サーバからリソース階層を拡張解除したりする必要はありま

せん。

230 User Guide

LifeKeeperの設定値の変更

2. LifeKeeperサーバのunameを変更する場合は、hostname(1)コマンドを使用してサーバのホ

スト名を変更してください。

3. 先に進む前に、新しいホスト名がクラスタ内のすべてのサーバで解決可能であることを確認して

ください。コミュニケーションパスのアドレスを変更する場合は、新しいアドレスが設定され、動作

していることを確認してください (ping と telnetのユーティリティをこの確認に使用可能 )。

4. LifeKeeperの複数の値を変更する必要がある場合は、クラスタ内の各サーバ上のファイルで、

古い値と新しい値を以下のフォーマットで指定する必要があります。

old_value1=new_value1

....

old_value9=new_value9

5. クラスタ内のすべてのサーバでlk_chg_valueコマンドを実行し、出力を確認して、予測しなか

った変更内容による副作用が発生していないことを確認してください。変更する値が複数ある

場合は、以下のコマンドを実行してください。

$LKROOT/bin/lk_chg_value -Mvf file_name

file_nameは、手順 4で作成したファイルの名前です。

変更する値が1つのみの場合は、以下のコマンドを実行してください。

$LKROOT/bin/lk_chg_value -Mvo old_value -n new_value

-M オプションは、LifeKeeperのすべてのファイルに対して変更を行わないことを指定します。

6. クラスタ内のすべてのサーバで、-Mオプションを指定せずに lk_chg_valueコマンドを実行し

て、LifeKeeperのファイルを変更してください。変更する値が複数ある場合は、以下のコマンド

を実行してください。

$LKROOT/bin/lk_chg_value -vf file_name

file_nameは、手順 4で作成したファイルの名前です。

変更する値が1つのみの場合は、以下のコマンドを実行してください。

$LKROOT/bin/lk_chg_value -vo old_value -n new_value

7. 以下のコマンドを使用して、LifeKeeperを再起動してください。

$LKROOT/bin/lkstart

LifeKeeperのGUIを使用してクラスタを表示する場合は、GUIを閉じてから再起動しなければ

ならないことがあります。

例 :

Server1とServer2は、2ノードクラスタ内にある LifeKeeperサーバのunameです。Server1は、

アドレス172.17.100.48のコミュニケーションパスを持ちます。Server2はアドレス172.17.100.220の IP リソースを持ち、この IP リソースは Server1に拡張されています。Server1について以下の

値を変更します。


ファイルシステムの健全性の監視

値旧新

uname Server1 Newserver1

コミュニケーションパスのアドレス 172.17.100.48 172.17.105.49

IP リソースのアドレス 172.17.100.220 172.17.100.221

これらの変更を行うには、以下の手順を実行する必要があります。

1. 以下のコマンドを使用して、Server1とServer2の両方で LifeKeeperを停止してください。

$LKROOT/bin/lkstop

2. 以下のコマンドを使用して、Server1のunameをNewserver1に変更してください。

hostname Newserver1

3. Newserver1とServer2の両方に、以下の内容を持つファイル /tmp/subsを作成してください。

Server1=Newserver1

172.17.100.48=172.17.105.49

172.17.100.220=172.17.100.221

4. 両方のサーバで以下のコマンドを実行し、出力を確認して、予測しなかった変更内容による

副作用が発生していないことを確認してください。

$LKROOT/bin/lk_chg_value -Mvf /tmp/subs

5. 両方のサーバで、-Mオプションを指定せずに lk_chg_valueコマンドを実行して、LifeKeeperのファイルを変更してください。

$LKROOT/bin/lk_chg_value -vf /tmp/subs

6. 以下のコマンドを使用して、両方のサーバで LifeKeeperを再起動してください。

$LKROOT/bin/lkstart

注記 :

l LifeKeeperのファイルを変更せずに lk_chg_valueによる変更内容を表示するには、-Mオプ

ションを使用してください。lk_chg_valueが調べるファイルを表示するには、-vを使用してくだ

さい。タグ名を変更しない場合は、-Tオプションを使用してください。リソース IDを変更しない場

合は、-I オプションを使用してください。

ファイルシステムの健全性の監視

ファイルシステムの健全性の監視機能は、LifeKeeperが保護する、ファイルシステム依存のアプリケー

ションで障害が発生する原因となる条件を検出します。監視は、アクティブ / In Serviceのリソース (つま

りファイルシステム)でのみ実行されます。監視する条件は、以下の2つです。

l ファイルシステムがフル (またはほぼフル)の状態になる。

l ファイルシステムが不適切にマウント (またはアンマウント )された。

232 User Guide

条件の定義

これら 2つの条件のいずれかが検出されると、いくつかの動作のいずれかが実行されることがあります。

l 警告メッセージがログ記録され、システム管理者に電子メールを送信できる。

l リソースインスタンスのローカルリカバリを試行できる。

l リソースをバックアップサーバにフェイルオーバできる。

条件の定義

フル (またはほぼフル) のファイルシステム

「ディスクがフル」の条件は検出できますが、ローカルリカバリまたはフェイルオーバの実行で解決すること

はできません。管理者の操作が必要です。デフォルトでは、メッセージがログ記録されます。追加の通

知機能を使用できます。例えば、電子メールをシステム管理者に送信できます。また、他の方法によ

り、別のアプリケーションを起動して警告メッセージを送信できます。この通知機能を有効にする方法に

ついてはLifeKeeperのイベント電子メール通知の設定のトピックを参照してください。

「ディスクフル」の条件に加えて、「ディスクがほぼフル」の条件を検出し、警告メッセージを LifeKeeperのログに記録できます。

「ディスクフル」のしきい値は以下のとおりです。

FILESYSFULLERROR=95

「ディスクがほぼフル」のしきい値は以下のとおりです。

FILESYSFULLWARN=90

デフォルト値は上記のとおりそれぞれ 90% と95%ですが、 /etc/default/LifeKeeperファイルの調整可能

なパラメータを使用して設定できます。これら 2つのしきい値の意味は以下のとおりです。

FILESYSFULLWARNING -ファイルシステムがこの割合までフルになると、メッセージが

LifeKeeperのログに表示されます。

FILESYSFULLERROR -ファイルシステムがこの割合までフルになると、メッセージがLifeKeeperのログ、およびシステムログに表示されます。ファイルシステムの通知スクリプトも呼び出されます。

アンマウントされた、または不適切にマウントされたファイルシステム

LifeKeeperは /etc/mtabファイルをチェックして、LifeKeeperが保護する In Serviceのファイルシステムが

実際にマウントされているかどうかを調べます。さらに、 filesysのリソース情報フィールドに保存されてい

るマウントオプションに対してマウントオプションをチェックし、階層の作成時に使用されていた元のマウン

トポジションと一致するかどうかを確認します。

ファイルシステムがアンマウントされているか、不適切にマウントされていることを検出した場合、ローカル

リカバリが起動され、正しいマウントオプションを使用してファイルシステムの再マウントが試行されます。

再マウントに失敗した場合、条件を解消するためにフェイルオーバが試行されます。以下のリストに、フ

ェイルオーバに進行する場合がある再マウントの障害の一般的な原因を示します。

l ファイルシステムが破損している (fsckの障害 )

l マウントポイントディレクトリの作成失敗


LifeKeeperが保護するシステムのメンテナンス

l マウントポイントがビジー

l マウントの失敗

l LifeKeeperの内部エラー

LifeKeeperが保護するシステムのメンテナンス

LifeKeeperが保護するサーバをシャットダウンしてメンテナンスを行うときには、メンテナンスの前に、バック

アップサーバでシステムのリソース階層を In Serviceにする必要があります。このプロセスにより、メンテナ

ンスが必要なシステム上にある共有ディスクの動作がすべて停止します。

記載の順序で、以下の操作を実行してください。Server Aはメンテナンスが必要なプライマリシステ

ム、Server Bはバックアップサーバです。

1. Server B で階層を in serviceにしてください。バックアップのServer Bで、LifeKeeperのGUIを使用して、現在 Server Aで in serviceであるリソース階層を in serviceにします。これによ

り、LifeKeeperの保護下にある共有ディスクに存在しているServer Aのファイルシステムがアンマ

ウントされます。詳細については、リソースを In Serviceにするを参照してください。

2. Server A で LifeKeeper を停止してください。LifeKeeperのコマンド

/opt/LifeKeeper/bin/lkstopを使用して、LifeKeeperを停止します。リソースが保護さ

れていない状態になります。

3. Linux をシャットダウンし、Server A の電源をオフにしてください。Server AのLinuxオペレーティ

ングシステムをシャットダウンし、サーバの電源をオフにします。

4. メンテナンスを実行してください。Server Aで必要なメンテナンスを実行します。

5. Server A の電源をオンにし、Linux を再起動してください。Server Aの電源をオンにし、次に

Linuxオペレーティングシステムを再起動します。

6. Server A で LifeKeeper を開始してください。LifeKeeperのコマンド /opt/LifeKeeper/bin/lkstartを使用して、LifeKeeperを開始します。リソースが保護されている状態になります。

7. 必要に応じて、Server A で階層を in serviceにしてください。Server Aで LifeKeeperのGUIを使用して、Server Bにスイッチオーバしていたすべてのリソース階層を in serviceにしてくださ

い。

リソース階層のメンテナンス

システム上のその他すべての階層を LifeKeeperで保護した状態で、あるリソース階層のメンテナンスを

実行できます。このためには、メンテナンスが必要な階層をOut of Serviceにし、メンテナンス作業の完

了後にその階層を In Serviceにします。

リソース階層のメンテナンスを実行するには、以下の手順に従ってください。

1. 階層を Out of Serviceにしてください。LifeKeeperのGUIを使用して、メンテナンスを実行する

必要があるリソース階層をすべてOut of Serviceにします。詳細については、リソースをOut ofServiceにするを参照してください。

2. メンテナンスを実行してください。リソース階層で必要なメンテナンスを実行します。

234 User Guide

フェイルオーバ後の復旧

3. 階層をリストアしてください。LifeKeeperのGUIを使用して、リソース階層を In Serviceにしま

す。詳細については、リソースを In Serviceにするを参照してください。

フェイルオーバ後の復旧

LifeKeeperがプライマリサーバ (Server A)からバックアップサーバ (Server B)にフェイルオーバリカバリを実

行した後、以下の手順を実行してください。

1. ログを確認してください。Server BのLifeKeeperがServer Aからフェイルオーバリカバリを実行す

ると、フェイルオーバ中にステータスメッセージが表示されます。

実際の出力は、設定によって異なります。マウントやアンマウントの失敗に関するいくつかのメッ

セージが表示されることが予測されますが、これらのメッセージはリカバリの失敗を示唆しません。

これらのメッセージ、およびServer Bでリソースを In Serviceにするときに発生したエラー

は、LifeKeeperのログに記録されます。

2. メンテナンスを実行してください。Server Aの障害の原因を特定し、解決します。メンテナンスを

実行するために、Server Aの電源をオフにすることが必要な場合があります。

3. 必要に応じて、Server A を再起動してください。メンテナンスが完了したら、必要に応じて

Server Aを再起動します。

4. 必要に応じて、LifeKeeper を開始してください。Server Aで LifeKeeperが動作していない場

合は、コマンド /opt/LifeKeeper/bin/lkstartを使用して、LifeKeeperを開始します。

5. アプリケーションを Server A に戻してください。都合のよい時点で、LifeKeeperのGUIを使用し

て、Server Aでアプリケーションを in serviceにします。詳細については、リソースを In Serviceにするを参照してください。Server Aでアプリケーションが [Automatic Switchback]に設定されて

いる場合は、この手順は不要なことがあります。

LifeKeeperの削除

Linux環境でのLifeKeeperパッケージのアンインストールは、rpmをサポートするグラフィカルインターフ

ェース、またはコマンドラインから実行できます。このセクションでは、コマンドラインから rpmコマンドを使

用して LifeKeeperをアンインストールする手順を詳しく説明します。rpmコマンドを使用する手順の詳

細については、rpm(8)のマニュアルページを参照してください。

rpmソフトウェアの詳細については、以下のWebサイトを参照してください。http://www.rpm.org/

以下に、LifeKeeperソフトウェアを削除するための要件を示します。

l アプリケーションの移動。LifeKeeperソフトウェアを削除する前に、サーバ上に LifeKeeperの保

護を必要とするアプリケーションがないことを確認する必要があります。アプリケーションリソース階

層が In Serviceのサーバからは、絶対に LifeKeeperを削除しないでください。LifeKeeperを削

除すると、同等性、リソース階層定義、ログファイルなどの設定データがすべて削除されます。

追加情報については、リソース階層の転送を参照してください。

l LifeKeeper の開始。LifeKeeperのリカバリキットソフトウェアを削除するときには、LifeKeeperが実行中でなければならない場合があります。LifeKeeperが実行中でない場合、削除プロセス

はクラスタ内の他のLifeKeeperサーバからリソースインスタンスを削除できず、複数のサーバが不

整合の状態になることがあります。

l すべてのパッケージの削除。LifeKeeper Coreを削除する場合、初めに LifeKeeperに依存する


http://www.rpm.org/

GnoRPMからの削除

他のパッケージ (例 : LifeKeeperのリカバリキット )を削除する必要があります。LifeKeeperのリカバ

リキットを削除する前に、まず関連するアプリケーションリソース階層を削除することが推奨されま

す。

注記 : LifeKeeperのリカバリキットソフトウェアを削除する前に、まず関連する階層をそのサーバか

ら削除することが推奨されます。この削除は、リソースの拡張解除の設定作業で実行できま

す。既存の階層の拡張解除を実行せずに LifeKeeperのリカバリキットパッケージを削除した場

合、現在定義され、このリカバリキットにより保護されている該当のリソース階層は、システムから

自動的に削除されます。一般的なルールは以下のとおりです。リソース階層が In Serviceのサーバからは、絶対にリカバリキットを削除しないでください。これにより現在の階層が破壊され、

リカバリキットの再インストール時に階層の再作成が必要になります。

GnoRPM からの削除

GnoRPMのウィンドウで、削除する各パッケージのアイコンを右クリックし、ポップアップメニューの

[Uninstall]をクリックしてください (または、パッケージアイコンを選択して [Uninstall]ボタンをクリックでき

ます)。

コマンドラインからの削除

サーバから LifeKeeperを削除するには、rpm -e <packagename> コマンドを使用して LifeKeeperのパッケージをすべて削除してください。rpmコマンドを使用する手順の詳細については、rpm(8)のマニ

ュアルページを参照してください。例えば、LifeKeeper Coreパッケージを削除するには、以下のコマンド

を入力します。

rpm -e steeleye-lk

参考として、LifeKeeper Coreパッケージクラスタに含まれるパッケージを示します。

steeleye-lksteeleye-lkGUIsteeleye-lkHLPsteeleye-lkIPsteeleye-lkMANsteeleye-lkRAWsteeleye-lkCCISS

ディストリビューションの有効化パッケージの削除

LifeKeeperパッケージを削除した後、 SPSのインストールイメージファイルに含まれる設定スクリプトがイ

ンストールしたディストリビューションに固有の有効化パッケージを削除する必要があります。お使いの

Linuxディストリビューションにより、パッケージの名前は steeleye-lk<Linux Distribution>のようになっ

ています。

steeleye-lkRedHatsteeleye-lkSuSE

ファイアウォールを使用した状態でのLifeKeeperの実行

以下のネットワークアクセス要件を満たす場合、LifeKeeper for Linuxは、同一サーバ上にファイアウォー

236 User Guide

LifeKeeperのコミュニケーションパス

ルを設定した状態で実行できます。

注記 : ファイアウォールを単に無効にする場合は、後述のファイアウォールの無効化を参照してくださ

い。

LifeKeeperのコミュニケーションパス

コミュニケーションパスは、特定の IPアドレスを使用して、LifeKeeperクラスタ内にあるサーバペアの間に

設定されます。TCPポート 7365は、作成時にデフォルトで各通信のリモート側により使用されますが、

通信の開始側のTCPポートは任意です。推奨方法は、そのシステムが既知のコミュニケーションパス

でローカルとリモートの IPアドレスの各指定ペアについて、受信と送信の両方のトラフィックを許可するよ

うに、各 LifeKeeperサーバにファイアウォールを設定することです。

LifeKeeper GUIの接続

LifeKeeper GUIは、デフォルトの初期接続ポートであるポート 81と82を含めて、特定のTCPポートを

多数使用します。また、LifeKeeper GUIは、ポート 1024以降をオブジェクトの送受信に使用するリ

モートメソッド呼び出し (RMI)も使用します。これらすべてのポートが、各 LifeKeeperサーバのファイアウ

ォールで、少なくとも GUI クライアントが動作する外部システムに対して開いている必要があります。

LifeKeeperの IPアドレスリソース

IPアドレスに関連するアプリケーションにアクセスする必要があるクライアントシステムから、LifeKeeperの階層にある IPアドレスリソースにアクセスできるように、ファイアウォールを設定する必要があります。 IPア

ドレスリソースは LifeKeeperクラスタ内のあるサーバから別のサーバに移動できるので、すべての

LifeKeeperサーバ上のファイアウォールを適切に設定する必要があります。

また、LifeKeeperは、ブロードキャスト pingのテストを使用して、 IPアドレスリソースの健全性を定期的

にチェックします。このテストでは、仮想 IPアドレスからブロードキャスト pingパケットを送信し、ローカル

サブネット上の他のいずれかのシステムが最初に応答するまで待ちます。このテストが失敗しないように

するには、各 LifeKeeperサーバ上のファイアウォールが以下のタイプのネットワーク動作を許可するよう

に設定する必要があります。

l 仮想 IPアドレスからのインターネット制御メッセージプロトコル (ICMP)パケットの送信 (アクティブ

な LifeKeeperサーバがブロードキャスト pingを送信できる)

l 仮想 IPアドレスからの ICMPパケットの受信 (他のLifeKeeperサーバがブロードキャスト pingを受信できる)

l 任意のローカルアドレスからの ICMP応答パケットの送信 (他のLifeKeeperサーバがブロードキャ

スト pingに応答できる)

l 仮想 IPアドレスでの ICMP応答パケットの受信 (アクティブな LifeKeeperサーバがブロードキャス

ト pingへの応答を受信できる)

LifeKeeper Data ReplicationLifeKeeper Data Replicationを使用する場合は、複製に ndbを使用する任意のポートへのアクセスを

許可するように、ファイアウォールを設定する必要があります。nbdが使用するポートは、以下の式で計

算できます。


ファイアウォールの無効化

10001 + <mirror number> + <256 * i>

iは 0から始まり、使用されていないポート番号が計算されるまで加算されます。 /etc/servicesに定義

されているポート、netstat -an --inetの出力に含まれるポート、または LifeKeeper Data Replicationの他

のリソースが使用中としてすでに定義されているポートは、使用中です。

例 : LifeKeeper Data Replicationリソースのミラー番号が0である場合、式は当初、使用するポートを

10001として計算しますが、この番号は、一部のLinuxディストリビューションでは SCP設定ポートとし

て /etc/servicesに定義されています。この場合、 iが1だけ増分されてポート番号 10257が得られま

す。この番号は、これらのLinuxディストリビューションの /etc/servicesには定義されていません。

ファイアウォールの無効化

ファイアウォールを無効にする場合は、以下の手順に従ってください。

1. 以下のコマンド (お使いのファイアウォールパッケージによって異なる)を使用して、ファイアウォール

を停止してください。

/etc/init.d/ipchains stop または

/etc/init.d/iptables stop

IPv6環境を使用している場合は、かならずip6tablesを考慮してください。

/etc/init.d/ip6tables stop

SuSE Linux Enterprise Serverを実行している場合

/etc/init.d/SuSEfirewall2_init stop

/etc/init.d/SuSEfirewall2_setup stop

2. パッケージを削除するか (rpm -eを使用 )、以下のいずれかのコマンド (お使いのファイアウォール

パッケージによって異なる)を使用して起動を無効にしてください。

/sbin/chkconfig --del ipchains または

/sbin/chkconfig --del iptables

/sbin/chkconfig --del ip6tables

SuSE Linux Enterprise Serverを実行している場合は、SuSEfirewall2の設定を管

理する必要があります。

ファイアウォール経由でのLifeKeeper GUI の実行

場合によっては、LifeKeeperクラスタが会社のファイアウォール内に配置され、管理者はファイアウォー

ルの外側にあるリモートシステムから LifeKeeper GUIを実行します。

LifeKeeperは、GUIのサーバとクライアントとの通信にリモートメソッド呼び出し (RMI)を使用しま

す。RMI クライアントは、それぞれの方向に通信を確立できる必要があります。RMI クライアントは動的

ポートを使用するので、クライアントには推奨ポートを使用できません。

解決法としては、以下のように sshを使用して、ファイアウォールを通過する方法があります。

238 User Guide

LifeKeeperの起動

1. 社内の IT部門が、ファイアウォール内にアクセスするために十分にセキュリティの高い shellポー

トを社内ファイアウォールに開けていることを確認します。多くの場合、 IT部門がアクセスを許可

するマシンは、実際にはクラスタ内のマシンではなく、そこからクラスタ内にアクセスできる中間マシ

ンです。このマシンは、Unixまたは Linuxが動作するマシンである必要があります。

2. 中間マシンとLifeKeeperサーバの両方が、sshd (Secure Shellデーモン)を実行していること、お

よびX11ポート転送が有効になっていること (これは通常、etc/ssh/sshd_configの`X11Forwarding yes'行にある)を確認してください。不明の場合は、 IT部門に依頼してくださ

い。

3. XのUnix クライアントから以下のコマンドを使用して、中間マシンにトンネルを作成します。

ssh -X -C <intermediate machine>

-C は「トラフィックの圧縮」を意味し、低速のインターネットリンクから受信する場合に役立つこと

が多々あります。

4. 中間マシンから以下のコマンドを使用して、LifeKeeperサーバにトンネルを作成します。

ssh -X <LifeKeeper server>

中間マシンは LifeKeeperサーバとの間にかなり高い帯域幅の接続をもつはずなので、このコマ

ンドには圧縮は不要です。

5. すべての操作が良好に完了した場合、以下のコマンドを実行してください。

echo $DISPLAY

「localhost:10.0」のような値に設定されます。値が設定されない場合、X11の転送がいずれか

のsshd設定ファイルで無効になっています。

6. 以下のコマンドを実行して、LifeKeeperサーバから単純な xtermをポップアップ表示できることを

確認してください。

/usr/X11R6/bin/xterm

7. xtermが表示された場合、以下のコマンドを使用して、LifeKeeperで lkGUIappを実行できま

す。

/opt/LifeKeeper/bin/lkGUIapp

8. GUI コンソールが表示されるまで待ってください。Javaは多くのグラフィックス動作を使用し、低

速リンクで伝播するには時間がかかります (圧縮している場合でも)。しかし、最終的にはGUIコンソールが表示されます。

LifeKeeperの起動

デフォルトでは、すべてのSPS ソフトウェアは、ディレクトリ /opt/LifeKeeperにインストールされます。

すべての確認作業が完了すると、両方のサーバで LifeKeeperを起動する準備が整います。このセクシ

ョンでは、LifeKeeperサーバデーモンプロセスの起動について説明します。LifeKeeper GUIアプリケーショ

ンは、別個のコマンドを使用して起動され、LifeKeeper GUIの設定に説明されています。LifeKeeperには、LifeKeeperデーモンプロセスの起動と停止を行うコマンドラインインターフェースが用意されていま

す。これらのデーモンプロセスは、LifeKeeper GUIを起動する前に実行する必要があります。


LifeKeeperサーバプロセスの起動

LifeKeeper サーバプロセスの起動

LifeKeeperがシステムで現在実行されていない場合は、すべてのサーバに対するユーザルートとして次

のコマンドを入力してください。


数秒の遅延の後、情報メッセージが表示されます。

注記 : LifeKeeperを起動するときに LifeKeeper Distribution Enabling Packageを参照するエラーメ

ッセージが表示された場合は、LifeKeeperインストールイメージファイルをインストール/再インストールす


lkstart コマンドの詳細については、コマンドラインでman LCDを入力して LCD(1M)マニュアルページを

参照してください。

LifeKeeperの停止

LifeKeeperを停止する必要がある場合は、ルートとして次のコマンドを入力して停止してください。


このコマンドは、管理されているサーバ上で現在実行されているすべてのLifeKeeperデーモンプロセスを

停止します。

リソース階層の転送

LifeKeeperサーバで定期的なメンテナンスやその他の作業を実行する必要がある場合、LifeKeeperのGUIを使用して In Serviceのリソースを別のサーバに移動できます。サーバAからサーバBに InServiceのリソース階層を転送するには、GUIを使用してサーバBでリソース階層を in serviceにしま

す。サーバAのリソースがすべて、対応するバックアップサービスで In Serviceになるまで、操作を繰り返

します。手順については、リソースを In Serviceにするを参照してください。

サーバAのリソースがすべて、バックアップサーバでアクティブになった後、アプリケーションの処理に影響を

与えることなく、サーバAをシャットダウンできます。ただし、メンテナンスの期間中、クラスタ内にあるサー

バ数によっては、リソースがLifeKeeperで保護されないことがあります。

テクニカルノート

お使いのLifeKeeper環境に関する設定と動作上の問題に関する以下のテクニカルノートをお読みに

なることを強く推奨します。

LifeKeeperの機能

項目説明

240 User Guide

チューニング

ライセンス

LifeKeeperを使用するには、各サーバに一意の実行時ライセンスキーが必要です。こ

れは、物理サーバと仮想サーバの両方に適用されます。ライセンスキーは、LifeKeeperCoreソフトウェア、およびLifeKeeperリカバリキットの各パッケージに必要です。インス

トールスクリプトが、サーバのHost IDを取得して表示する Licensing Utilitiesパッケー

ジをインストールします。Host ID、およびソフトウェアに付属のアクティベーション IDが、SIOS Technology Corp のWeb サイトからライセンスキーを取得するために使用

されます。 .

大型クラス

タのサポー

ト

LifeKeeperは、最大 32台のサーバを持つ大型クラスタの設定をサポートします。ただ

し、LifeKeeper以外の多くの要因が、クラスタ内でサポートされるサーバの台数に影響

することがあります。この要因として、ストレージの相互接続、オペレーティングシステム、

ストレージソフトウェアの制限などがあります。サポートされる最大クラスタサイズを調べる

には、ベンダ固有のハードウェアとソフトウェアの設定情報を参照してください。

国際化と

ローカライズ

LifeKeeper for Linux v5.2以降は、リソース名とタグ名でのワイド /マルチバイト文字の

使用をサポートしていますが、ネイティブの言語メッセージサポートは含まれていませ

ん。Javaのプロパティファイルのロケール固有バージョンを作成することによ

り、LifeKeeperのGUIをローカライズできますが、現在フルにローカライズされているのは

英語バージョンのみです。ただし、LifeKeeperのGUIに表示される多くのメッセージは

LifeKeeper Coreから来ているので、GUIのローカライズは、ユーザにとって、Coreソフト

ウェアがフルにローカライズされるまでの単なる部分的な解決法です。

追加情報については、制限または既知の問題の「言語環境の影響」も参照してくだ

さい。

LifeKeeperのMIB ファ

イル

LifeKeeperは、LifeKeeperクラスタ内で発生するイベントを記述するSNMP トラップを

送出するように設定できます。この機能の設定に関する詳細については、 lk_configsnmp(8)のマニュアルページを参照してください。LifeKeeperのトラップを記述する

MIBファイルは、 /opt/LifeKeeper/include/LifeKeeper-MIB.txtに記載されています。

WatchdogLifeKeeperは、 Watchdog機能をサポートしています。この機能は、SIOS TechnologyCorp.によりRedHat EL 5.5の64-ビット、RedHat EL 5.6の32-ビット、およびRedHatEL 6 + softdogでテスト済みです。

STONITHLifeKeeperは、STONITH機能をサポートしています。この機能は、SIOS TechnologyCorp.により IBM x3550 x86_64アーキテクチャ上のSLES 11、およびRHEL5.5の64-ビットでテスト済みです。

XFS ファイ

ルシステム

XFSファイルシステムは、ファイルシステムのチェックと修正に fsckユーティリティを使用し

ません。その代わりに、ログの再生をマウントに依存します。整合性の問題についての

懸念がある場合は、システム管理者がファイルシステムを out of serviceにしてアンマウ

ントし、xfs_check(8)とxfs_repair(8)を実行して問題を解決する必要があり

ます。

IPv6 SIOSは、 ipコマンドの使用に移行し、 ifconfigコマンドを使用しなくなりました (詳細に

ついては IPv6の既知の問題を参照 )。

チューニング

項

目説明


チューニング

IPCセマ

フォ

と

IPC共

有

メモ

リ

LifeKeeperには、プロセス間通信 (IPC)セマフォと IPC共有メモリが必要です。以下のLinuxカーネルオプションのRedHatのデフォルト値は、 /usr/src/linux/include/linux/sem.hにあ

り、LifeKeeperの多数の設定をサポートするのに十分な値です。

オプション必須 Red Hat 6.2のデフォルト値

SEMOPM 14 32SEMUME 20 32SEMMNU 60 32000SEMMAP 25 32000SEMMNI 25 128

シス

テム

ファ

イル

テー

ブル

LifeKeeperがバックアップシステムに正常にフェイルオーバするためには、システムリソースが使用

可能である必要があります。例えば、システムファイルテーブルがフルの場合、LifeKeeperが新

しいプロセスを開始してリカバリを実行することができない可能性があります。エンタプライズパッ

チを持つカーネル (LifeKeeperがサポートするものを含む)では、 file-max、つまりシステムで開い

ているファイルの最大数は、デフォルトでシステムメモリサイズの1/10に設定されます。これ

は、LifeKeeperの多数の設定をサポートするのに十分な値です。 file-max値をデフォルト値よ

りも低く設定すると、予期しない LifeKeeperの障害が発生することがあります。

file-max値は、以下のコマンドで取得できます。

cat /proc/sys/fs/file-nr

このコマンドは、3つの値を返します。1番目の値はファイルテーブルのエントリのこれまでの最大

値 (システムがこれまでに検出した最大値 )、2番目の値は現在のファイルテーブルのエントリ

数、3番目の値は file-maxの値です。

file-maxを調整するには、 /etc/sysctl.confの「fs,file-max」値を追加 (または変更 )し (フォーマ

ットについては sysctl.conf(5)を参照 )、

sysctl –p

次にこのファイルを実行して、システムを更新します。 /etc/sysctl.confの値は、再起動後も保

持されます。

242 User Guide

LifeKeeperの動作

LifeKeeperの動作

Linuxファイ

アウ

ォール

と

SELin-uxの

共存

ファイアウォールとSELinuxが、インストール時に有効になります。インストールの完了

後、SELinuxを無効にし、ファイアウォールを変更する必要があります。

SELinuxのモードが「有効」または「許可」の場合、LifeKeeperはインストールされず、機能

しません。RedHatのSELinuxを無効にするには、ホストシステムのコンソールからsystem-

config-securitylevel-tuiツールを実行してください。SELinux for SLES 11 SP1が提供されていますが、これも無効にする必要がありま

す(http://www.novell.com/linux/releasen.../SUSE-SLES/11/)。

AppArmor (このセキュリティモデルを使用するディストリビューションの場合 )は有効にすること

ができます。

ホストのファイアウォールが有効の場合、LifeKeeperは機能します。ただし、絶対に必要な

場合以外は、ファイアウォールは無効にし、LifeKeeperが保護するリソースは別の保護ファ

イアウォール内に配置してください。

LifeKeeperを、ファイアウォールを有効にしたホストと共存させる必要がある場

合、LifeKeeperはコミュニケーションパス、GUI、 IP、およびデータ複製に特定のポートを使

用します。Linuxのファイアウォール機能を使用する場合、LifeKeeperが使用する特定の

ポートを開く必要があります。

RedHatのファイアウォールを無効にしたり変更したりするには、ホストシステムのコンソールか

らsystem-config-securitylevel-tuiツールを実行してください。SUSEのファイア

ウォールを無効にしたり変更したりするには、yast2を実行し、[Security andUser]、[Firewall]を順に選択してください。詳細については、ファイアウォールを使用した状

態でのLifeKeeperの実行を参照してください。

nolo-

ck

Optio-n

ロック処理を伴うストレージアプリケーションを使用する際、以下のNFSマウントオプションの

推奨として、SPSでは nolockオプションを追加で設定する必要があります。例：rw,nolock,bg,hard,nointr,tcp,nfsvers=3,timeo=600,rsize=32768,wsi-

ze=32768,actimeo=0.

Out ofServic-eの階

層の

復旧

LifeKeeperサーバの障害発生後のリカバリの一部として、障害が発生したサーバに設定さ

れているリソース階層のうち、障害発生時にいずれかのサーバで「In Service」ではないもの

は、その時点で優先順位が最高の「alive」のサーバで復旧されます。これは、障害が発生

したサーバ、復旧するサーバ、クラスタ内のその他のサーバなど、「Out of Service」の階層が

最後に In Serviceであったサーバを問いません。

Suidマウン

トオプ

ション

suidマウントオプションは、root としてマウントするときのデフォルトであり、マウントコマンドによ

り /etc/mtabに書き込まれることはありません。LifeKeeper環境では、suidマウントオプション

は不要です。

カーネ

ルデバ

ッガ

(kdb)

init s

LifeKeeperが保護するサーバでカーネルデバッガ (kdb)を使用したり init sに移動する前

に、そのサーバで LifeKeeperをシャットダウンするか、LifeKeeperが保護するリソースをバック

アップサーバに切り替える必要があります。LifeKeeperのSCSI予約デーモン (lkscsidと

lkccissd)を有効にした状態で (デフォルトで有効になっている)、kdb を使用すると、予期し

ないパニックが発生することがあります。


http://www.novell.com/linux/releasenotes/i386/SUSE-SLES/11/

http://www.novell.com/linux/releasenotes/i386/SUSE-SLES/11/

サーバの設定

ロック

してい

る共

有デバ

イスで

のシス

テムパ

ニック

LifeKeeperはロックを使用して、共有 SCSIバス上にある他のサーバがアクセスしないように

共有データを保護します。他のサーバがデバイスをロックしたことによりLifeKeeperがデバイス

にアクセスできない場合、致命的なエラーが発生し、即座に対処する必要があります。対

処しない場合、データが破損するおそれがあります。この条件が検出された場

合、LifeKeeperはシステムにパニックを発生させる機能を有効にします。

共有デバイスが予約された状態で、LifeKeeperが「lkstop」以外の方法により停止した場

合 (これは、kdbまたは init sの実行で発生することがある)、他のサーバがリソースを復旧す

るときに LifeKeeperのロックメカニズムによりカーネルパニックのトリガになることがあります。この

方法で LifeKeeperを停止する前に、リソースをすべてOut of Serviceにする必要がありま

す。

項目説明

サーバの設定

項目説明

BIOS のアップ

デート

使用可能な最新のBIOSを常にすべてのLifeKeeperサーバにインストールする

必要があります。

LifeKeeper 7.5以降のパッケージ依存リスト

以下に、お使いのOSディストリビューションにより、LifeKeeper 7.5以降の必須パッケージに必要となる

場合がある依存関係のリストを示します。

重要 :これらのパッケージの 32-ビットバージョンが必要です。

このリストの依存関係を満たすために、追加のパッケージのインストールが必要になる場合があります。

bzip2 OR libbz2 OR bzip2-libglibciproute OR iproute2iptablesiputilslibstdc++ OR libstdc++43mktempnfs-utils OR nfs-kernel-server (NFS共有を保護する場合)pamzlib

注記 : ORは、Linux OSディストリビューションのバリエーションです。

このリストには、依存関係がすべて含まれているわけではありません。ベースパッケージとLinux OSディス

トリビューションによっては、追加のパッケージの依存関係が必要になることがあります。また、特定のオ

プションのソフトウェアコンポーネントがインストールされていることを設定スクリプトが検出した場合、追加

のパッケージの依存関係が必要になることがあります。

yumやzypperなど、リポジトリベースのパッケージマネージャの使用を検討することを推奨します。これ

らのパッケージマネージャは、定義済みのソフトウェアリポジトリを検索して依存関係を自動的に解決す

るように設計されているので、これらの必須パッケージのインストールが容易になります。

244 User Guide

[Confirm Failover] と [Block Resource Failover]の設定


以下の説明、例、および考慮事項をよく読んで理解してから、お使いのLifeKeeper環境で [ConfirmFailover]または [Block Resource Failover]を設定してください。これらの設定は、コマンドライン、ま

たは LifeKeeperのGUIの[Properties]パネルから使用できます。

Confirm Failover On:

定義 –システムAからシステムBへのフェイルオーバの手動確認を有効にします (システムAはプロパテ

ィが[Properties]パネルに表示されるサーバで、システムBはチェックボックスの左にあるシステム)。あるシ

ステムでこのオプションをオンに設定した場合、障害発生が検出されたシステムについて LifeKeeperがフェイルオーバリカバリを実行するには、システム管理者による手動確認が必要になります。

フェイルオーバを確認するには、lk_confirmsoコマンドを使用します。デフォルトでは、このコマンドを

実行するまで管理者には 10分の猶予時間があります。この時間は、 /etc/default/LifeKeeperのCONFIRMSOTO設定で変更できます。管理者が10分以内に lk_confirmso コマンドを実行し

ない場合、フェイルオーバは続行されるか、ブロックされます。デフォルトでは、フェイルオーバが続行され

ます。この動作は、 /etc/default/LifeKeeperのCOMFIRMSODEF設定で変更できます。

例 :自動フェイルオーバをすべてブロックする場合は、[Properties]パネルの [Confirm Failover On]オプションを設定し、さらにCONFIRMSODEFを 1 (フェイルオーバをブロック)、CONFIRMSOTOを 0 (フェ

イルオーバ動作が決定されるまで待機しない)に設定してください。

この設定を選択するタイミング:

この設定は、設定に冗長ハートビートコミュニケーションパスを含まない多くのディザスタリカバリ、その他

のWAN設定で使用されます。

通常のサイト (非マルチサイトクラスタ)では、あるサーバで [Properties]ページを開き、[ConfirmFailover]フラグをオンに設定するサーバを選択してください。

マルチサイト WANの設定の場合 : フェイルオーバの手動確認を有効にしてください。

マルチサイト LANの設定の場合 : フェイルオーバの手動確認を有効にしないでください。

マルチサイトクラスタ環境では、非ディザスタシステムからDRシステムを選択し、 [Set Confirm FailoverOn]チェックボックスをオンにします。クラスタ内の非ディザスタサーバのそれぞれについて、[Properties]パネルを開いてこの設定を選択する必要があります。

Block Resource Failover On:

定義 -デフォルトでは、リソースのすべての障害について復旧イベントが発生し、ローカルシステムの障

害リソースの復旧が試行されます。ローカルリカバリが失敗した場合、または有効になっていない場合

は、リソースが定義されている、優先順位が次に最も高いシステムに、LifeKeeperがローカル履歴を転

送します。ただし、宛先として指定したシステムでこの設定を選択している場合、リソース障害に起因

するリソースの転送はすべてブロックされます。

この設定が有効の場合、以下のメッセージがログに記録されます。

Local recovery failure, failover blocked, MANUAL INTERVENTION REQUIRED


条件 /考慮事項 :

条件 / 考慮事項 :

マルチサイト設定では、設定のすべてのサーバについて、フェイルオーバのブロックを選択しないでくださ

い。

注記 :この設定は、システム全体の障害が発生した場合のフェイルオーバ動作には影響しません。リ

ソースの障害に起因するフェイルオーバのみをブロックします。

NFS クライアントのオプション

LifeKeeperで保護するNFSサーバを設定するときには、NFSクライアントがこのサーバに接続する方法

が、フェイルオーバ時に再接続する速さに大きな影響を与えます。

NFS クライアントをマウントするときの考慮事項

NFSサーバは、クライアントコンピュータにネットワークベースのストレージシステムを提供します。このリ

ソースを使用するには、クライアントシステムは、NFSサーバによりエクスポートされた、既にNFSである

ファイルシステムを「マウント」する必要があります。NFSクライアントを LifeKeeperが保護するNFS リ

ソースに接続する方法について、いくつかのオプションをシステム管理者は考慮する必要があります。

UDP または TCP の選択

NFSプロトコルは、ユーザデータグラムプロトコル (UDP)と伝送制御プロトコル (TCP)のいずれかを活用

できます。 .NFSは従来、クライアント /サーバの通信にUDPプロトコルを使用してきました。この理由

の1つは、NFSがUDPプロトコルを使用してステートレス方式で動作するほうが容易だからです。こ

の「ステートレス」であることが、高可用性のクラスタ化では重要です。これは、保護されているNFSサー

バリソースがクラスタホスト間で切り替えられた場合に、クライアントを容易に認識できるからです。一般

的に、LifeKeeperが保護するNFS リソースを操作するときには、UDPプロトコルがTCPよりも良好に

動作する傾向があります。

/etc/exportsの Syncオプション

LifeKeeperが保護するNFS リソースの場合、エクスポートオプションとして「sync」を指定することが推奨

されます。「sync」オプションは、ディスクに書き込みを実行してから肯定応答をNFSクライアントに送信

するようにNFSに指示します。もう 1つのオプションである「async」も使用できますが、このオプションを使

用するとデータが破損するおそれがあります。これは、ディスクに書き込みを実行する前にNFS書き込

みの肯定応答をクライアントに送信するからです。NFSクライアントも、NFSファイルシステムのマウント

時にオプションとして「sync」を指定できます。

Red Hat EL6 (および Fedora 14) クライアントとRed Hat EL6 NFS サーバの使用

RedHat EL6用 NFSサーバのバグと思われるものにより、RedHat EL6 (およびFedora 14)を実行する

NFSクライアントは、NFSのバージョン (nfsvers)およびUDPの両方をマウントコマンドに指定できませ

ん。これと同じ動作が、Ubuntu10.10クライアントでも確認されています。この動作は、RedHat EL6NFSを使用するRedHat EL5クライアントでは確認されておらず、RedHat EL5 NFSサーバを使用す

るすべてのクライアントで確認されていません。RedHat EL6 (Fedora 14)クライアントとRedHat EL 6NFSサーバを使用するためのNFSマウントディレクトリの最善の組み合わせは以下のとおりです。

mount <protected-IP>:<export> <mount point>

-o nfsvers=2,sync,hard,intr,timeo=1

246 User Guide

RedHat EL5 NFSクライアントとRedHat EL6 NFSサーバの使用

l この組み合わせでは、LifeKeeperが保護するNFSサーバがスイッチオーバまたはフェイルオーバを

実行する場合に、クライアントの再接続時間が最短になります。

Red Hat EL5 NFS クライアントとRed Hat EL6 NFS サーバの使用

RedHat EL5を実行するNFSクライアントとRedHat EL6 NFSサーバを使用するときに、再接続時間

が短い最善のオプションの組み合わせは以下のとおりです。

mount <protected-IP>:<export> <mount point>

-o nfsvers=3,sync,hard,intr,timeo=1,udp

クラスタの例

拡張したマルチクラスタの例



メッセージカタログでは、操作、管理、GUIなど、SteelEye Protection Suite for Linuxを使用していると

きに出会う可能性がある、すべてのエラーコードを列挙します。また、エラーコードの原因に関する追加

の説明や、問題解決のために必要な処置についても、必要に応じて記載します。この完全なリストを

検索すると、受信したエラーコードを見つけることができます。また、以下の個別のメッセージカタログに

直接アクセスすることもできます。

l コアメッセージカタログl ファイルシステムキットメッセージカタログl Gen/Appキットメッセージカタログl GUI メッセージカタログl IPキットメッセージカタログl Oracle Listenerキットメッセージカタログl Oracleキットメッセージカタログl SCSIキットメッセージカタログl SDRキットメッセージカタログ

上記のメッセージカタログに加え、以下のトピックでも、直面する可能性がある問題や制限事項のトラ

ブルシューティングについて詳細を説明します。

既知の問題と制限

下記に、LifeKeeper for Linuxで明らかになっている制限または既知の問題を機能領域ごとに示しま

す。

インストール

説明

リリース 7.4以降では、SteelEye製品 RPM パッケージの再割り当てはサポートされません。

SUSE にインストールしている場合、コアでパッケージチェックエラー (rpm -V steeleye-lk)が発生しま

す。以下のエラーが発生します。

SUSEがシャットダウンスクリプトを実行する方法により (他のLinuxディストリビューションとは異なり)、以下のスクリプトがインストール後に別の場所に移動するので、実行レベルを変更するか再起動し

ているときに LifeKeeperはシャットダウンされます。以下は、steeleye-lkパッケージを確認しているとき

に発生する唯一のエラーです。

Missing /etc/rc.d/rc0.d/K01lifekeeper




インストール

GUI はデフォルトのRHEL6 64-bitでは動作しません

RedHat Enterprise Linux 6 64-bitには互換性の問題があります。

解決方法 : LifeKeeperをインストールする前に、OSのインストールメディアに含まれ

ている以下のパッケージをインストールしてください。LifeKeeperをインストールする

前にインストールされていない場合、インストール作業が正常に終了しません。

libXau-1.0.5-1.el6.i686.rpm libxcb-1.5-1.el6.i686.rpm libX11-1.3-2.el6.i686.rpm libXext-1.1-3.el6.i686.rpm libXi-1.3-3.el6.i686.rpm libXtst-1.0.99.2-3.el6.i686.rpm

新しいデバイスがスキャンされているときに nbd ドライバがロードされる

と、multipathd デーモンはエラーログにエラーを記録します

解決方法 : ログでこれらのエラーを避けるには、 /etc/multipath.confのblacklistにdevnode "^nbd"を追加します。

NFS Setup Logging が不完全です

ISOイメージ sps.imgからインストール設定スクリプトを実行する場合、NFSのスク

リプトパッチプロセスの結果は、LifeKeeperインストールログ (/var/log/LK_install.log)でキャプチャされません。対応策はありません。

Html.pm パッケージとの競合のため、7.xからのコアパッケージのアップグレードに失

敗します

LifeKeeper Coreパッケージ (steeleye-lk)をリリース7.4.0以前からリリース7.5.0以降にアップグレードしたところ、ファイル /opt/LifeKeeper/lib/perl/Html.pmに競合エ

ラーが発生しました。このエラーを解決し、コアパッケージを正常にインストールする

には、--forceオプションを rpmに使用する必要があります。

ループバックインターフェースを INTERFACELIST 設定で使用する際、ライセンスが

正常に機能しません。

ループバック (lo)インターフェースを INTERFACELIST設定で使用できません。

IP アドレスに基づくライセンスファイルが使用されている場合、 lklicmgr ツール

は「HOSTID mismatch (HOSTID が不一致です)」というメッセージを誤表示しま

す。

IPアドレスに基づくライセンスファイルが使用されている場合、 lklicmgrはHOSTID不一致エラーを誤表示します。これは lklicmgr の表示の問題に過ぎません。ライ

センスは予期したとおりに機能します。

250 トラブルシューティング

インストール

nfslock initスクリプトのパッチをあてる際、HA向けのNFS設定に失敗します

NFSのHAにはnfs-utilsパッケージが必須です。そのパッケージがシステムにイ

ンストールされていない場合は nfslock initスクリプトのHA機能を有効にするパッ

チスクリプトが失敗します。

解決方法 : nfs-utilsパッケージをインストールし、その後 SPSインストールセット

アップスクリプトを再度実行してください。


LifeKeeper Core

LifeKeeper Core


LifeKeeper Core

説明

言語環境の影響

一部のLifeKeeperスクリプトは、Linuxシステムユーティリティの出力を解析し、一定のパターンに従っ

て情報を抽出します。英語圏以外のロケールで一部のコマンドが実行されている場合、予測され

たパターンは変更され、LifeKeeperスクリプトは必要な情報の取得に失敗します。このため、言語

環境変数 LC_MESSAGESは /etc/default/LifeKeeperで POSIX “C” locale (LC_MESSAGES=C)に設定されています。言語を英語に設定して Linuxをインストールする必要はありません (インストー

ルメディアで使用可能な言語を選択できます)。 /etc/default/LifeKeeperのLC_MESSAGESの設定

は LifeKeeperにのみ影響します。 /etc/default/LifeKeeperのLC_MESSAGESの値を変更する

と、LifeKeeperの動作に悪影響を与える可能性があります。悪影響は、メッセージカタログがさまざま

な言語とユーティリティに対応してインストールされているかどうか、およびLifeKeeperが予期していな

いテキスト出力をそれらが生成するかどうかに左右されます。

ファイルシステムラベルは、大規模な設定で使用しないことを推奨します

ファイルシステムラベルを使用すると、大きなクラスタの場合、起動時にパフォーマンスが低下する可

能性があります。ラベルを使用するには、システムに接続されるすべてのデバイスをスキャンする必要

があり、通常はその結果として問題が生じます。SANに接続されているシステム、特にデバイスへの

アクセスがブロックされている LifeKeeperが導入されているシステムの場合、このスキャニングは非常

に遅くなる可能性があります。

Red Hatシステムでこのパフォーマンスの問題を防ぐには、 /etc/fstabを編集し、ラベルをパス名に置き

換えます。

SUSE SLES 10 を実行している QLogic ドライバ (qla2xxx)のリザベーションを解除できません

QLogic ドライバ (qla2xxxx)を使用しているSUSE SLES 10システムでは、フェイルオーバが機能しま

せん。ストックQLogic ドライバで SLES 10を実行している x86ボックスでは、リザベーションを解除でき

ないので、フェイルオーバは機能しません。SLES 10で配布された qla2xxx ドライバは、ハングした IOがあった場合、リセットを発行するだけです。注記 : SLES 10 SP1で配布された qla2xxx ドライバーで

問題は修正されました。

gen/app リソースで構文エラーが発生する可能性があります

コアのアップグレードをせずに、steeleye-lkGUIパッケージのみアップグレードした場合、gen/appリソー

スで構文エラーが発生します。steeleye-lkGUIパッケージには、同じバージョンまたはそれ以降のバー

ジョンのコアを必要とする gen/appGUI コンポーネントへの更新が含まれています。

注記 : LifeKeeperをアップグレードする際に、GUI とコアパッケージを最新バージョンにアップグレードす

る必要があります。GUIパッケージと一緒にコアをアップグレードした場合、エラーは発生しないはずで

す。

SLES10 システムでシャットダウンがハングします

SLES10を備えた AMD64システムでシャットダウンを実行すると、システムはロックアップし、シャットダ

ウンは完了しません。これは、 bug #294787で Novellにレポートされています。このロックアップは、

SLES10のpowersave packageが原因で発生します。

対応策 : SLES10のpowersave packageを削除し、シャットダウンが正常に完了できるようになりま

す。


LifeKeeper Core

lkscsid は、sendevent を発行するとシステムを停止します

lkscsidは、ディスク障害を検出すると、デフォルトで sendeventを LifeKeeperに発行し、障害

から復旧しようとします。sendeventはまず、ローカルで障害から復旧しようとします。それに失敗す

ると、ディスクの階層を別のサーバに切り替えて障害から復旧しようとします。一部のバージョンの

Linux (RHEL5および SLES11)では、lkscsidは sendeventを発行できないため、代わりにすぐ

にシステムを停止します。これは、/dev/sdaなどのSCSIデバイスノードを使用している階層にの

み影響します。

RHEL6 64-bitではセットアップが失敗します

RedHat Enterprise Linux 6 64-bitには互換性の問題があります。

解決方法 : LifeKeeperをインストールする前に、OSのインストールメディアに含まれている以下のパッ

ケージをインストールしてください。LifeKeeperセットアップを実行する前にインストールされていない場

合、セットアップは正常に終了しません。

rpm -i compat-libstdc++-33-3.2.3-69.el6.i686 libgcc-4.4.4-13.el6.i686rpm -i nss-softokn-freebl-3.12.7-1.1.el6.i686 glibc-2.12-1.7.el6.i686

注記 :詳細については、LifeKeeper 7.5以降のパッケージ依存関係のリストを参照してください。

DataKeeper のCreate Resourceが失敗します

Citrix XenServer (または IDEディスクエミュレーションを提供できるその他のハイパーバイザ)で実行さ

れている、完全に仮想化された VMで DataKeeperを使用している場合、createでエラーが発生し

ます。

ERROR 104052 (エラー 104052):Cannot get the hardware ID of the

device "dev/hda3" (デバイス「dev/hda3」のハードウェア ID を取得できません)

これは、完全に仮想化された VMがローカルディスクを IDE ドライバとして表示させ、getIdがこれら

のVMにある IDEディスクを適切にクエリーできないためです。

対応策 : /dev/hda*をDEVNAME device_patternファイルに追加します。次に例を示します。

# cat /opt/LifeKeeper/subsys/scsi/Resources/DEVNAME/device_

pattern

/dev/hda*

API アクセスに対するホスト名の指定

LifeKeeperサーバ認証情報の格納に使用するキー名は他のLifeKeeperサーバのホスト名と完全に

一致する必要があります (そのサーバに対する hostnameコマンドで表示されます)。ホスト名が

FQDNの場合、認証キーは FQDNである必要があります。ホスト名が短縮名の場合、キーも短縮

名にする必要があります。

対応策 : credstoreによって格納されたホスト名がホスト名と完全に一致していることを確認します。


LifeKeeper Core

8.0.0以前のバージョンの LifeKeeper の lkbackups を使用する場合は、8.0.0でリストアする場

合に /etc/default/LifeKeeper を手動で更新する必要があります

LifeKeeper/SPS 8.0.0では、ロギングなどの主要なコアコンポーネントに対して大幅な機能強化が

加えられています。これらの機能強化は /etc/default/LifeKeeperファイルの設定に影響し

ます。lkbackupが8.0.0をリストアすると、これらの設定は正しい値を持っていません。

解決方法 : LifeKeeper for Linux v8未満で取得した lkbackupを restoreする前

に、/etc/default/LifeKeeperを保存します。lkbackupから restoreしたら、以下の新しい

設定値にマージします。

LKSYSLOGTAG=LifeKeeper

LKSYSLOGSELECTOR=local6

詳細については、syslogでのロギングを参照してください。

リソースの作成後に lkbackup を restoreすると、破損したイクイバレンシが残されます

作成したリソースの設定ファイルは lkbackup中に保存されます。lkbackupでバックアップした後

で初めてリソースを作成した場合、そのリソースは、前のバックアップからリストアする際に適切に把握

されない可能性があります。

解決方法 :新しいリソースを初めて追加する前に lkbackupからリストアします。新しいリソースが

lkbackupの後で追加された場合、リストアの前に削除するか、リソースの階層のインスタンスを削

除し、リストアの後で階層を再拡張してください。注記 :特定のリソースを初めて作成する際に

lkbackupを実行することを推奨します。

フェイルオーバ時に誤った順序でリソースが remove されます

階層が共通リソースインスタンスを別のルート階層と共有している場合、カスケーディングフェイルオー

バまたはリソースフェイルオーバの間、リソースは誤った順序で removeされることがあります。

解決方法 :共通ルートを作成すると、階層のリソースの removeがトップダウンで実行されます。

1. restoreと removeを常に進める gen/appを作成します。2. 現在のルートをすべて、この新しい gen/appの子にします。

注記 : restoreおよび removeスクリプトに /bin/trueを使用すると、これが可能になります。



インターネット /IP ライセンス



INTERFACELIST 構文、 /etc/hosts設定の依存関係

/etc/hosts設定 :インターネットベースのライセンス (IPv4アドレス)を使用している場合、 /etc/hostsの設定はライセンスの検証に悪影響を与える可能性があります。LifeKeeperの起動に失敗した場合は、以下のようなメッセージが出力されます。

Error in obtaining LifeKeeper license key

(LifeKeeper ライセンスキーの取得エラー):

Invalid host. (無効なホストです。)The hostid of this system does not match the hostid

specified in the license file. (このシステムの hostid は

ライセンスファイルで指定した hostid と一致しません。)

リストされているインターネット hostidが正しい場合、 /etc/hostsの設定が原因の

可能性があります。 /etc/hostsエントリを正しく一致させるには、 IPv6エントリの前

に IPv4エントリを記載する必要があります。 /etc/hosts設定が原因かどうかを確

認するには、次のコマンドを実行します。

/opt/LifeKeeper/bin/lmutil lmhostid -internet -n

記載されている IPv4アドレスが、インストールされたライセンスファイルの IPv4アド

レスと一致しない場合、正しいアドレスを返すために、 /etc/hostsを変更し、 IPv4エントリを IPv6エントリの前に配置する必要があります。

INTERFACELIST 構文 :

デフォルトでは、LifeKeeperのライセンスはプライマリネットワークインターフェース

eth0に基づいています。インターフェースeth0の名前が変更されると、LifeKeeperインストールおよびセットアップエラーが発生します。LifeKeeperが一意のシステム

HOST IDの取得に失敗する原因になるので、名前の変更には対応していませ

ん。RedHat Enterprise Linux 6.1で導入された整合性のあるネットワークデバイス

命名規約に対応するために、RedHat Enterprise Linux 6.xでプライマリインターフ

ェースの名前を指定するための INTERFACELIST設定が追加されました。

整合性のあるインターフェースのネットワークデバイスの命名では、オンボードイン

ターフェースに em<ポート番号>、pciアドインインターフェースに pci<スロット番

号>p<ポート番号>_<仮想機能インターフェース>を使用します。RedHatEnterprise Linux 6.xシステムの場合、デフォルトでは、LifeKeeperはネットワーク

デバイスem0を探します。そのデバイスが存在しない場合、 INTERFACELIST設定を設定し、プライマリインターフェース名を指定する必要があります。設定に

は、プライマリインターフェース名のみを含めるだけで構いませんが、コロン区切りの

リストによる追加の名前 (たとえば、 INTERFACELIST=em0:em1など)には対

応していません。

注記 : INTERFACELIST設定値は /etc/default/LifeKeeperで設定す

る必要があります。LifeKeeper Coreパッケージがまだインストールされていない場

合、/etc/default/LifeKeeperは存在しません。この場合、設定スクリプト

(export INTERFACELIST=em1など)を再実行する前に、 INTERFACELISTが

環境で設定されていることを確認してください。


GUI

GUI

説明

GUI を終了した後で Web ブラウザを介して再接続すると、GUI ログインプロンプトが再表示されな

い場合があります

GUIアプレットを終了するか切断してから同じ Webブラウザセッションから再接続しようとすると、ログ

インプロンプトが表示されない場合があります。

回避策 :Webブラウザを再度開き、サーバに接続します。Firefoxブラウザを使用している際は、すべ

てのFirefoxのブラウザを閉じ、再び開きます。

RHEL5の lkGUIapp が、対応していないテーマに関するエラーをレポートします

GUIアプリケーションクライアントを起動すると、以下のコンソールメッセージが表示される場合がありま

す。このメッセージはRHEL 5およびFC6 Javaプラットフォームのルックアンドフィールに由来するもの

で、GUI クライアントの動作に悪影響を及ぼすことはありません。

/usr/share/themes/Clearlooks/gtk-2.0/gtkrc:60:Engine

"clearlooks" is unsupported, ignoring (エンジン「clearlooks」は未

対応です。無視しています)

ネットワークが切断され、再接続された後で、GUI は IP リソースの状態をすぐに更新しません

クラスタ内のサーバ間のプライマリネットワークが切断され、再接続されると、RMI/TCPレイヤーの問

題のため、リモート GUI クライアントの IP リソースの状態が更新されるまで 1分 25秒かかる場合が

あります。


GUI

説明

Java署名 /未署名混合コードの警告 - LifeKeeper Java GUI クライアントアプレットをリモートシステ

ムからロードすると、以下のセキュリティ警告が表示されることがあります。

[Run]をクリックすると、以下のダイアログが表示されます。

ブロックするかどうかを確認するメッセージが表示されます。 [No]をクリックすると、LifeKeeper GUIの動

作が可能になります。

推奨される処置 :セキュリティ警告の数を減らすには、2つのオプションがあります。

1. [Always trust content from this publisher]ボックスをチェックし、[Run]をクリックしま

す。LifeKeeper GUI Javaクライアントを次回ロードしたときに、警告メッセージは表示されなく

なります。

または

2. ブロックに関する 2番目のダイアログが表示されないようにするには、以下のエントリを Javaの「deployment.properties」ファイルに追加します。Javaクライアントをロードしたときにセキュ

リティ警告は表示されますが、アプレットはブロックされず、ブロックするかどうかを [Yes]または

[No]で確認する上記のダイアログは表示されなくなります。この設定はすべてのJavaアプレッ

トに適用されるので注意してください。

deployment.security.mixcode=HIDE_RUN

上記のメッセージが両方とも表示されないようにするには、1と2を実行してください。


データレプリケーション

説明

ポート 778が使用中の場合、steeleye-lighttpd プロセスの開始に失敗します

steeleye-lighttpdの起動時にプロセスがポート 778を使用している場合、steeleye-lighttpdの起動

に失敗し、GUIへの接続障害が発生する。

解決方法 : クラスタ内のすべてのノードで以下の設定を行い、LifeKeeperをすべてのノードで再起

動します。

以下の行を /etc/default/LifeKeeperに追加します。

API_SSL_PORT=port_number

port_numberは使用する新しいポートです。


説明

両方のサーバに重要な I/O トラフィックを持つシンメトリックなアクティブ SDR 設定で、netraid デバイ

ス (ミラー)にマウントされたファイルシステムが応答を停止し、結果的にシステム全体がハングします

Linuxバッファキャッシュの単一スレッドの特性により、バッファキャッシュフラッシングデーモンは、リモート

でコミットする必要があるバッファをフラッシュアウトしようとしてハングする可能性があります。フラッシング

デーモンがハングすると、クリアされていないバッファの数がシステムで許容されている上限

(/proc/sys/kernel/vm/bdflushで設定 )を超えると、クリアされていないバッファを持つ Linuxシステムの

すべてのアクティビティは停止します。

これは、リモートシステムがリモートバッファを消去できなくなるような事態でないかぎり、通常は深刻

な問題ではありません。LifeKeeperはネットワークの障害を検出し、そのときにレプリケーションを停止

するので、ハング状態は消去されます。ただし、リモートシステムがローカルシステムにもレプリケートさ

れた場合 (つまり、相互がシンメトリカルにレプリケートされた場合 )、このフラッシングデーモンのハング

状態に入った場合、永久にデッドロックする可能性があります。

デッドロックを解除するには、両方のシステムのnbd-clientデーモンを手動で停止します (これにより、

ミラーが切断されます)。ただし、このデッドロックを完全に防止する場合は、シンメトリックアクティブレプ

リケーションを推奨しません。

GUI は SLES 10 SP2 システム上で適切な状態が表示されません

この問題は、SLES 10 SP2カーネルのバグによるもので、更新カーネルバージョン 2.6.16.60-0.23で修正されています。SLES 10 SP2では、netstatは /proc/<PID>/fdという新しいフォーマットで切断さ

れます。

解決方法 : SLES 10 SP2を使用する場合は、カーネルバージョンを 2.6.16.60-0.23にアップグレード




圧縮レベル設定用に 32-bit zlib パッケージを RHEL 6 (64-bit)にインストールする必要があります

RHEL 6 (64-bit)で SDRを使用する場合、以下のエラーが表示されることがあります。

Could not start balance on Target when Compression Level is set on RHEL 6 (64-bit) (圧縮レベル

がRHEL 6 (64-bit)で設定された場合、ターゲットのバランスを開始できませんでした)

解決方法 : この問題を解決するには、RHEL 6 (64-bit)を使用する場合は、32-bit zlibパッケージを

インストールしてください。

ミラーが切断され、 /var/log/messages にたくさんのエラーが記述されます

この問題は、(Red Hat EL 6.xやCentOS 6で)意図的に障害を発生させるストレステストを実行し

ているとき (特に、ミラーターゲットシステムで実行されている nbd_serverプロセスを停止しているとき

に)にときおり見られます。ディストリビューションの最新カーネル (Red Hat EL 6.0または 6.1の場合は

kernel-2.6.32-131.17.1.el6など)にアップグレードすると、この問題が発生するリスクの軽減に役立つ

場合があります。ソースシステムを再起動すると、この問題はなくなります。

CentOS 6 (2.6.32-71.el6)に付属のデフォルトカーネルでは、(ミラーの過負荷に過ぎない場合でも)この問題はさらに頻繁に発生する可能性があります。残念なことに、CentOSはこの状態を改善する

カーネル (2.6.32-131.17.1)をまだリリースしていません。SIOSは、CentOS 6で入手可能になり次

第、2.6.32-131.17.1カーネルへのアップグレードを推奨しています。

カーネルのアップグレードに関する重要な情報 :SPSは一般的にいくつかの機能をサポートするため

カーネルモジュールをインストールします。 ;そのため、RedHatシステムでカーネルパッチの適用 /カーネ

ルのアップグレードを実施する際に、インストールメディアから./setupスクリプトを再度実行し、SPSの一部としてインストールしたカーネルを新しいカーネルとして有効にしてください。この操作を実施し

ない場合は、SPS リソースを in serviceおよび/もしくは保護できない状態のままになります。

大きなミラーサイズを備えた md_raid1 プロセスではトップで高い CPU 使用率がレポートされます

mdX_raid1プロセス (Xはミラー番号 )では、非常に大きなミラー (500GB以上 )を操作している際

に、一部のOSディストリビューションで高いCPU使用率がトップでレポートされることがあります。

解決方法 : CPUの使用率を減らすには、LifeKeeper設定 LKDR_CHUNK_SIZEでチャンクサイズを

1024に変更し、この新しい設定を使用するためにミラーを削除して再作成します。

DataKeeper リソースで lkbackup を使用する場合は、全同期が必要です

lkbackupでは instanceとmirror_infoファイルを保存しますが、ソースおよびターゲットの状

態として lkbackupからリストアした後で、DataKeeperミラーの全同期を実行することが最善の方

策です。


IPv6

IPv6


IPv6

説明

SIOSは、ifconfigコマンドからipコマンドの使用に移行しました。この変更のため、外部スクリ

プトを使用するお客様も、同様の変更を行うことを推奨します。ifconfigコマンドを発行し、結果

を解析して特定のインターフェースを探す代わりに、スクリプトは「ip -o addr show」を使用し、

結果を解析して、「inet」および「secondary」という語を含む行を検索します。

# ip -o addr show

1: lo:<LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state

UNKNOWN

\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

1: lo inet 127.0.0.1/8 scope host lo

1: lo inet6 ::1/128 scope host

\ valid_lft forever preferred_lft forever

2: eth0:<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_

fast state UP qlen 1000

\ link/ether d2:05:de:4f:a2:e6 brd ff:ff:ff:ff:ff:ff

2: eth0 inet 172.17.100.77/22 brd 172.17.103.255 scope global

eth0

2: eth0 inet 172.17.100.79/22 scope global secondary eth0


2: eth0 inet6 2001:5c0:110e:3364::1:2/64 scope global


2: eth0 inet6 2001:5c0:110e:3300:d005:deff:fe4f:a2e6/64 scope

global dynamic

\ valid_lft 86393sec preferred_lft 14393sec

2: eth0 inet6 fe80::d005:deff:fe4f:a2e6/64 scope link


ipコマンドの上記の結果では、以下の行に eth0インターフェースの仮想 IPアドレスが含まれます。




IPv6

/etc/sysconfig/network-scripts/ifcfg-<nicName> の「IPV6_AUTOCONF = No」が再起動または

起動の際に考慮されません

起動時に、自動設定されたステートレスな IPv6アドレスがネットワークインターフェースに割り当てら

れます。 IPV6_AUTOCONF=Noが設定されているインターフェースのステートレス IPv6アドレスでコミ

ュニケーションパスが作成された場合、任意のシステムリソースが ifdown <nicName>;ifup<nicName>などのインターフェースを管理する際にアドレスが削除されます。

IPV6_AUTOCONFが Noに設定されているので、プライマリサーバを再起動した後で、自動設定さ

れた IPv6アドレスを使用しているコミュニケーションパスは復旧せず、無効のままです。

解決方法 :スタティックな IPv6アドレスのみを使用してください。自動設定された IPv6アドレスを使

用すると、再起動後に通信が失われたり、NICが変更されたりする可能性があります。

自動設定された IPv6アドレスをコミュニケーションパス作成に使用できますが、システム管理者は以

下の条件を認識する責任があります。

l 自動設定されたステートレスな IPv6アドレスがネットワークインターフェース (NIC) MACアドレ

スに準拠していること。コミュニケーションパスが作成され、関連 NICが後で置き換えられた場

合、自動設定された IPv6アドレスは異なるものになり、LifeKeeperはコミュニケーションパス

が無効になっていることを適切に表示します。コミュニケーションパスを再作成する必要があり

ます。

l RHEL5.6では、ホスト操作のあらゆる側面で一貫した IPv6自動設定を確保するための動

作を実行するには、sysctl.conf、net.ipv6.*命令 ('if/ip'ユーティリティで参照される ifcfg-<nic>の明示的な IPV6_AUTOCONF設定、およびシステムが起動して initレベルを切り替

える際にNIC制御に影響する /etc/sysctl.conf)に加え、個々のインターフェース設定ファイ

ルを正確に設定するために、詳細かつ具体的なドメインの知識が必要になります。

IP: IPv6のソースアドレス変更設定ではソースアドレスが設定されません

IPv6 IP リソースのソースアドレスを設定しようとすると、何も変更されていない場合でも成功となりま

す。

対応策 :現在のところ、対応策はありません。今後のリリースで対応する予定です。

IP:無効な IPv6 アドレス設定が IP リソース作成で許可されます

オクテットに 4文字を超える文字が含まれている場

合、2001:5c0:110e:3368:000000:000000001:61:14 という形式の IPv6アドレスが許容されます。

対応策 :正しい形式の IPv6アドレスを入力してください。

IPv6 アドレス設定からホストに接続できません

lkGUIapp は、解決可能なホスト名または IPアドレスの場合でも、 IPv6の16進数アドレス設定か

らホストに接続できません。 lkGUIappでは、 IPv4設定ノードで接続する必要があります。 IPv6のコミ

ュニケーションパスは完全にサポートされています。


Apache

bonding NIC に割り当てられているものの、「暫定的な」状態のアドレスでは、 IPv6 リソースが ISPとしてレポートされます

LifeKeeperで IPv6に保護されているリソースは、 IPv6リソースがbondingインターフェース上にある

SLESシステムでは「In Service Protected」 (ISP: In Serviceの保護 )と不正に識別されます。これ

は、 'active-backup' (1)およびLinux カーネル2.6.21以降とは別のモードです。 IPv6のbondingリンク

は、解決できないアドレスを持つ「暫定的な」状態のままになります。

対応策 : bondingインターフェースモードを 'active-backup' (1)に設定します。または、 'active-backup'(1)以外のモードの場合、リンク状態を「tentative (暫定的 )」から「valid (有効 )」に設定する更新した

カーネルで操作します。

カーネルのアップグレードに関する重要な情報 :SPSは一般的にいくつかの機能をサポートするため

カーネルモジュールをインストールします。 ;そのため、RedHatシステムでカーネルパッチの適用 /カーネ

ルのアップグレードを実施する際に、インストールメディアから./setupスクリプトを再度実行し、SPSの一部としてインストールしたカーネルを新しいカーネルとして有効にしてください。この操作を実施し

ない場合は、SPS リソースを in serviceおよび/もしくは保護できない状態のままになります。

Apache

説明

Apacheキットは IPv6に対応していません。httpd.confで IPv6 を識別しません

httpd.conf ファイルで「Listen」命令エントリに割り当てられた IPv6アドレスが原因

で、問題が発生します。

解決方法 : Apache Recovery Kitで IPv6がサポートされるまで、リソース作成後に

IPv6アドレスを httpd.conf ファイルに指定できません。

Oracle Recovery Kit

説明

Oracle Recovery Kitには Connection Manager および Oracle Names機能の

サポートが含まれていません

LifeKeeper Oracle Recovery Kitには、Oracle ConnectionManagerとOracleNames というOracle Net機能のサポートが含まれていません。Oracle ConnectionManagerは、同じサービスにアクセスする必要がある多数の接続を管理するルーテ

ィングプロセスです。Oracle Namesはサービスアドレスの一括格納を管理する

Oracle固有の命名サービスです。

LifeKeeper Oracle Recovery Kitは、送信されてきたクライアント接続要求をリスニ

ングし、サーバへのトラフィックを管理するOracle Net Listenerプロセスを保護しま

す。Oracle Listenerに関する LifeKeeper設定固有の情報について

は、『LifeKeeper for Linux Oracle Recovery Kit管理ガイド』を参照してください。


NFS Server Recovery Kit

Oracle Recovery Kitは Oracle 10g のASM またはグリッドコンポーネント機能を

サポートしていません

以下の情報はOracle 10gデータベースインスタンスのみを対象とします。Oracle 10gで提供されているOracle Automatic StorageManager (ASM)機能は現

在、LifeKeeperではサポートされていません。また、10gのグリッドコンポーネントは

LifeKeeper Oracle Recovery Kitによって保護されていません。RAWデバイス、ファ

イルシステム、論理ボリュームに対するサポートは、現在のLifeKeeper for LinuxOracle Recovery Kitに含まれています。グリッドコンポーネントに対するサポート

は、gen/appリカバリキットを使用して LifeKeeper保護機能に追加できます。

Oracleパッケージのインストールは LifeKeeper 実行中に app および type エントリ

を追加できません

Oracleパッケージ (バージョン 7.2)のインストール時に LifeKeeperが実行されている

と、Oracleリソース階層が作成されないので、LifeKeeperを終了して再起動するま

で appおよび typエントリが作成されません。

解決方法 : LifeKeeperを停止してからOracle rpmをインストールしてください。

1. lkstop -fで LifeKeeperを停止します。

2. Oracleをインストールします。

3. LifeKeeperを再起動します。 lkstart

Oracle Recovery Kitは NFS バージョン 4 をサポートしていません

Oracle Recovery Kitは共有データベースストレージ用にNFSバージョン 3をサポー

トしています。NFSv4ファイルロッキングメカニズムのため、NFSバージョン 4は、現時

点ではサポートされていません。

NFS Server Recovery Kit

説明

最上位のNFS リソース階層は hanfs リソースのスイッチバックタイプを使用します

障害から In Service状態に復旧する際にNFS リソース階層がプライマリサーバにスイッチバックする

かどうかを制御するスイッチバックタイプは、hanfs リソースで定義されます。

一部のクライアントが nfs ファイルロックを再取得できません

NFSクライアントとして動作しているとき、一部のLinux カーネルは、NFSロックが解除されているの

で、再取得する必要があるという、NFSサーバからの通知に正常に応答しません。そのため、これら

のシステムが、LifeKeeperに保護されているNFSファイル共有のクライアントである場合、これらのク

ライアントで保持されているNFSロックは、フェイルオーバまたはスイッチオーバの際に失われます。

ロック処理を伴うストレージアプリケーションを使用する際、以下のNFSマウントオプションの推奨とし

て、SPSでは nolockオプションを追加で設定する必要があります。例：rw,nolock,bg,hard,nointr,tcp,nfsvers=3,timeo=600,rsize=32768,wsize=327-

68,actimeo=0.


SAP Recovery Kit

NFS v4の変更は SLES 11 nfsサブシステムの操作と互換性がありません

SLES 11の非 NFS v4リモートエクスポートのマウンティングによって、rpc.statdが開始されます。NFSv4ルートエクスポートを保護するクラスタ内のOut of Serviceノードでは、rpc.statdの開始に失敗し

ます。

解決方法 : NFS v4ルートエクスポートを保護しているクラスタで NFS v2/v3と混在させないでくださ

い。

IPv6では NFS v4 を設定できません

IPv6仮想 IPはNFSv4階層にまとめられます。

解決方法 : NFSv4リソースの作成時に IPv6仮想 IP リソースを使用しないでください。

NFS v4:拡張解除後に階層を再拡張できません

エクスポートポイントがすでにターゲットサーバでエクスポート済みなので、拡張に失敗します。階層が

サーバAで作成され、サーバBに拡張され、サーバBで In Serviceになり、サーバAから拡張解除

された場合、NFS v4階層のサーバAへの再拡張は失敗します。

解決方法 :サーバAで「exportfs -ra」というコマンドを実行し、残された追加エクスポート情報をクリー

ンアップします。

NFSv3: RedHat 6.xおよび CentOS 6.xではファイルロックスイッチオーバに失敗します

サーバのフェイルオーバまたはスイッチオーバでファイルロックをフェイルオーバしても、RedHat 6.xまたは

CentOS 6.xシステムでは機能しません。NFSv3のロックフェイルオーバは現在、これらのOSバージョ

ンではサポートされていません。

解決方法 : NFSv4で有効なロックフェイルオーバ機能を使用します。

Oracle Recovery Kitは NFSv4 をサポートしていません

Oracle Recovery Kitは共有データベースストレージ用にNFSv3をサポートしています。NFSv4ファイ

ルロッキングメカニズムのため、NFSv4は、現時点ではサポートされていません。

SAP Recovery Kit

説明

SAP 階層の削除または拡張解除に失敗します

同じ IP リソースを階層内の複数の場所に格納しているSAP階層を削除または拡張解除すると、

リソースが削除されず、コアダンプが発生することもあります。

この問題を修正するには、拡張解除または削除操作に失敗した後で、残ったリソースを

LifeKeeper GUIから手動で削除します。サーバからコアファイルを削除するという方法もあります。


LVM Recovery Kit

[Handle Warnings]により -e行 1で構文エラーが発生します

[Handle Warnings]のデフォルトの動作 [No]を [Yes]に変更すると、エラーを受信します。

解決方法 : このオプションをデフォルト設定の [No]のままにしてください。注記 : [Yellow]は、頻繁に

は障害を示さない一時的な状態のため、この設定をデフォルト選択の [No]のままにしておくことを強

く推奨します。

同じ設定を選択すると、Update Wizard のボタンが非表示になります

現在の設定を変更せずに [Handle Warning]を更新しようとすると、戻る必要があることを示す次の

画面で、[Done]ボタンが表示されません。

res_stateに変更を加えると、監視が無効になります

[Protection Level]を [BASIC]に設定し、SAPを手動でダウンさせた場合 (保守などの目的

で)、FAILED とマークされ、監視が停止します。

解決方法 :監視を再開する場合、LifeKeeperはリソースを手動ではなく開始する必要があります。

ERS がCore/CI の親ではない場合、 In Serviceの ERS がリモートホストで失敗します

追加 SAP リソースの依存関係なしで ERS リソースを作成すると、スイッチオーバ時に初期の InService状態が失敗します。

解決方法 : CI/Coreインスタンス (SCSまたは ASCS)の親として ERSを作成してから、 In Serviceの状態を再試行します。

LVM Recovery Kit

説明

lkID の使用はディスク全体で LVM pvcreate と互換性がありません

lkIDを使用して、LVM物理ボリュームとして設定されているディスクで一意のディス

ク IDを生成すると、 lkIDおよびLVM情報が格納されているディスク上の場所で競

合が発生します。これにより、 lkIDおよびpvcreateが使用された順番に従っ

て、 lkIDまたは LVM情報のどちらかが上書きされます。

対応策 : lkIDを LVMと組み合わせて使用する必要がある場合は、ディスクをパーテ

ィション化し、ディスク全体ではなくディスクパーティションを LVM物理ボリュームとして

使用します。

LVM のアクションがRHEL 6では遅くなります

RHEL 6で一部のLVMコマンドを実行している際、前のリリースよりもパフォーマンス

が遅くなる場合があります。これは、LVMリソースを含む階層のやや長い restoreおよび remove時間で見られます。


DMMP Recovery Kit

Raw および LVM Recovery Kitが混在した構成は RHEL 6環境ではサポートさ

れません。Raw リソースの作成時、Raw Recovery KitはRawデバイスのmajor #およびminor#に基づいてデバイスファイルを検索します。その結果、/dev/dm-*がデバイスとな

りますが、 /dev/dm-*の形式は LVM Recovery Kitが処理することができないため

"raw device not found" というエラーがGUIに表示されます。

DMMP Recovery Kit

説明

DMMP:スタンバイサーバで発行された writeがハングすることがあります

別のサーバでリザーブされているDMMPデバイスにwriteが発行されると、 IOが永

久に (またはデバイスがもう一方のサーバでリザーブされなくなるまで)ハングすることが

あります。もう一方のサーバでデバイスが解放され、writeが発行されると、データが

破損することがあります。

この問題の原因は、DMMPでの IO再試行に従ってパス確認が実行される方法

にあります。「no_path_retry」が0 (失敗 )に設定されると、このハングは発生しませ

ん。別のサーバでパスがリザーブされているときにデバイスのpath_checkerが失敗し

ても (MSA1000)、この問題は発生しません。

対応策 : 「no_path_retry」を 0 (失敗 )に設定します。しかしこれにより、一時的なパ

スの障害が原因で、 IOの障害が発生する可能性もあります。

DMMP:複数のイニシエータがATP_C をサポートする SAS アレイで正しく登録さ

れていません

LifeKeeperは、複数のSASイニシエータがSASアレイに接続される設定をサポー

トしていません。こうした設定では、各イニシエータが正常に登録されないので、1つのイニシエータのみが IOを発行できるようになります。マルチパスドライバ (DMMPな

ど)が未登録のイニシエータに IOを発行すると、エラーが発生します。

RHEL 6の場合、LifeKeeper は EMC Clariion に接続されているリザベーションを

サポートできません

PostgreSQL Recovery Kit

説明


MD Recovery Kit

SLES 10 SP2では、データベースが稼働していないまたは、dbfail が発生すると

PostgresSQL リソースがエラーとなります。

この問題は、SLES 10 SP2カーネルのバグによるもので、更新カーネルバージョン

2.6.16.60-0.23では修正されています。SLES 10 SP2では、netstatは/proc/<PID>/fdという新しいフォーマットで切断されます。netstatユーティリティは、

データベースが実行されていることを確認するためにPostgreSQLRecovery Kitで使用されます。

解決方法 : SLES 10 SP2で実行している場合は、カーネルバージョンを 2.6.16.60-0.23にアップグレードしてください。

カーネルのアップグレードに関する重要な情報 :SPSは一般的にいくつかの機能を

サポートするためカーネルモジュールをインストールします。 ;そのため、RedHatシステ

ムでカーネルパッチの適用 /カーネルのアップグレードを実施する際に、インストールメ

ディアから./setupスクリプトを再度実行し、SPSの一部としてインストールした

カーネルを新しいカーネルとして有効にしてください。この操作を実施しない場合

は、SPS リソースを in serviceおよび/もしくは保護できない状態のままになります。

MD Recovery Kit

説明

MD Recovery Kitは、「homehost」で作成されたミラーをサポートしません

LifeKeeper MD Recovery Kitは、「homehost」機能で作成されたミラーでは正常に

機能しません。「homehost」が設定された場合、LifeKeeperは、不正なフォーマット

の一意の IDを使用するので、 In Serviceの操作が失敗します。SLES 11システム

では、「homehost」はミラーの作成時にデフォルトで設定されます。「homehost」に対応しているmdadmのバージョンは、別のディストリビューションやバージョンでも使

用可能と思われます。この機能を無効にするには、ミラー作成時にコマンドラインで

--homehost=""を指定します。「homehost」設定で作成されたミラーがすでに存在

している場合は、ミラーを再作成して設定を無効にする必要がありま

す。「homehost」で作成されたミラーで LifeKeeper階層がすでに構築されている場

合、階層を削除し、「homehost」を無効にしてミラーを構築した後で再作成する


MD Recovery Kitは LVM デバイスで作成された MD デバイスをサポートしていま

せん

LifeKeeper MD Recovery Kitは、LVMデバイスで作成されたMDデバイスを正常

に処理しません。MDデバイスが作成されると、LifeKeeperが認識できない名前が

付けられます。

/etc/mdadm.confのMD Recovery Kit設定ファイルエントリがコメントアウトされて

いません

/etc/mdadm.confのLifeKeeper設定ファイルエントリ破砕起動後にコメントアウトす

る必要があります。これらのファイルエントリはコメントアウトされていません。


GUI トラブルシューティング

一部のパス障害ではコンポーネントが out of serviceにならない

いずれのパス障害でも、場合によっては、mdadmが失敗を検出し、MDquickCheckがlkscsidによる障害ディスク検出の前に復旧を開始します。これ

により、複数の復旧が同時に発生し、コンポーネントがout of serviceにならなくな

ります。

大規模な設定ではローカルリカバリが実行されません

大規模な設定 (6以上の階層 )では、ローカルリカバリがトリガされた場合

(sendevent)、すべての階層がチェックされず、ローカルリカバリが失敗することがあり

ます。

起動時にミラーが自動的に開始されます

一部のシステム (RHEL 6を実行しているシステムなど)では、起動時に自動的にミ

ラーを開始する設定ファイル (/etc/mdadm.conf)にAUTOエントリがあります (例 :AUTO +imsm +1.x –all)。

解決方法 : LifeKeeperでは、ミラーを自動的に開始しないようにする必要があるの

で、このエントリを編集し、起動時に自動的に開始しように指定する必要がありま

す。前の例 (AUTO +imsm +1.x –all)は、 imsm メタデータおよび1.x メタデータから

他のすべてを除いたものを使用して作成したミラーを自動的に開始するようにシス

テムに指示しています。このエントリを「AUTO -all」に変更し、あらゆるもの「マイナ

ス」すべてを自動的に開始するように(つまり、何も自動的に開始されないように)システムに通知する必要があります。

重要 : クリティカルなシステムリソース (rootなど)がMDを使用している場合、それら

のミラーが他の方法で開始され、LifeKeeperで保護されているミラーは開始されな

いことを確認してください。

MD リソースインスタンスは restore時に udev処理の悪影響を受けることがありま

す

udev処理中に、デバイスノードが removeされ、再作成されます。restoreの際、

ノードが再作成される前に、LifeKeeperがノードにアクセスしようとして、restoreが失敗する場合があります。

解決方法 : LifeKeeper restoreアクションを再実行してください。

GUI トラブルシューティング

LifeKeeper GUIをリモートシステムから設定する際に問題が発生した場合は、以下のいずれかのトピッ

クを参照してください。

Javaプラグイントラブルシューティング

アプレットトラブルシューティング

ネットワーク関連トラブルシューティング( GUI)


ネットワーク関連トラブルシューティング (GUI)

ネットワーク関連トラブルシューティング (GUI)LifeKeeperはGUI クライアントとサーバの通信に Java RMI (RemoteMethod Invocation)を使用しま

す。問題となりうる要素の一部はRMIに関連し、それ以外は一般的なネットワークの設定に関する

問題です。

Windowsプラットフォームでの論理接続の遅延

Sun FAQから:最も蓋然性が高いのは、ホストのネットワーク設定が誤りというものです。RMIは Java APIネットワーク

クラス、特に ava.net.InetAddressを使用します。これは、アドレスマッピングおよびホスト名へのアドレス

に対して両方のホストに TCP/IPホスト名のルックアップを実行させます。Windowsでは、ルックアップ機

能はネイティブWindows ソケットライブラリで実行されるので、遅延はRMIではなく、Windows ライブラ

リで発生するものです。ホストがDNSを使用するように設定されている場合、これは、通信に関連する

ホストについて認識しないというDNSサーバの問題となる可能性があります。その場合、DNSルックア

ップのタイムアウトが発生します。このケースに当てはまる場合は、ファイ

ル\windows\system32\drivers\etc\hostsで関連ホスト名 /アドレスをすべて指定してください。通常のホ

ストファイルのフォーマットを次に示します。

IPアドレスサーバ名称

例 :

208.2.84.61 homer.somecompany.com homer

これで、最初のルックアップにかかる時間を短縮できるはずです。

また、サブネットマスクとゲートウェイアドレスの設定が誤っていると、接続の遅延や障害を引き起こす可

能性があります。これらの設定が正しいことをネットワーク管理者に確認してください。

モデムからの実行 :サーバが存在するネットワークにモデムで (PPPまたは SLIPを使用して)接続する場合、コンピュータは

一時的な IP番号を操作用に取得します。この一時的な番号は、ホスト名がマップしたものではない

可能性があります (ホスト名が何かにマップしている場合 )。そのため、この場合は、 IPのみで通信するよ

うにサーバに指示する必要があります。これには、モデム接続ウィンドウを開いて一時的な IP番号を取

得します。この番号を使用して、GUI クライアントのホスト名プロパティを設定します。

プラグインでブラウザのホスト名を設定するには、[Java Plug-In Control Panel]を開き、[Java RunTime Parameters]に以下の値を追加してクライアントのホスト名を設定します。

-Djava.rmi.server.hostname=<MY_HOST>

HotJavaブラウザのホスト名を設定するには、hotjavaコマンドラインに以下の値を追加します。


たとえば、以下のようになります。

-Djava.rmi.server.hostname=153.66.140.1


プライマリネットワークインターフェースのダウン:

プライマリネットワークインターフェースのダウン:LifeKeeper GUIは、GUI クライアントとGUIサーバの通信を維持するためにRemoteMethodInvocation (RMI)を使用します。ほぼどのような場合でも、プライマリネットワーク・インターフェースを介し

てサーバへの接続が確立されます。つまり、サーバのプライマリイーサネットインターフェースがダウンした場

合、接続は失われ、GUI クライアントに [Unknown] というサーバの状態が表示されます。

この問題の唯一の解決策は、サーバのプライマリイーサネットインターフェースを再び有効にすることで

す。また、RMIの制限のため、マルチホームサーバ (複数のネットワークインターフェースを備えたサーバ)でこの問題を解決することはできません。

ホストへのルートが存在しない例外 :ホストに接続できなかったため、ソケットをリモートホストに接続できませんでした。これは通常、ネット

ワークのローカルサーバとリモートホストの間のリンクの一部がダウンしたか、ホストがファイアウォールの後

ろにあることを意味します。

不明なホストの例外 :LifeKeeper GUI クライアントとサーバは、通信に Java RMI (RemoteMethod Invocation)技術を使用し

ます。RMIが正常に動作するために、クライアントとサーバは解決可能なホスト名または IPアドレスを

使用する必要があります。解決不可能な名前、WINS名、修飾されていないDHCP名を使用した

場合、JavaはUnknownHostExceptionを送出します。

このエラーメッセージは、以下の条件でも発生する可能性があります。

l サーバ名が存在しない場合。サーバ名の誤記がないか確認してください。

l 設定されたDHCPサーバが、RMIサーバが実際に存在するドメインではなく、リゾルバドメイン

のドメイン名になるようにRMIサーバの完全修飾ドメイン名を設定している場合。この場合、

サーバのDHCP ドメインの外側のRMI クライアントは、不正なドメイン名のためにサーバにアク

セスできません。

l サーバが、Windows Internet Naming Service (WINS)を使用するように設定されたネットワーク

上にある場合。DNSにのみ依存しているホストは、WINSの下に登録されたホストにアクセスで

きない場合があります。

l RMI クライアントとサーバがファイアウォールをはさんだ反対側にある場合。ファイアウォールの外

側にRMI クライアント、内側にサーバがある場合、クライアントはサーバに対してリモート呼び出

しを実行できません。

LifeKeeper GUIを使用している場合、クライアントによって提供されたホスト名はサーバから解決できる

ものであり、サーバからのホスト名はクライアントによって解決できるものである必要がありま

す。LifeKeeper GUIはこの例外を捕捉し、ユーザに警告します。クライアントがサーバのホスト名を解決

できない場合、この例外が捕捉され、メッセージ 115が表示されます。サーバがクライアントのホスト名を

解決できない場合、この例外が捕捉され、メッセージ 116が表示されます。どちらのメッセージにも、実

行が試された未修飾ホスト名を指定する Java例外の一部が含まれています。


Windowsから:

下記に、ホスト名の解決が正常に機能していることをテストまたは検証するために使用できる手順をい

くつか示します。

Windowsから:1. Linuxサーバとの通信の確認

DOSプロンプトから、ホスト名を使用してターゲットを pingします。

ping <TARGET_NAME>


ping homer

ターゲットの修飾されたホスト名と IPアドレスをリストする応答が表示されるはずです。

2. 正しい設定の確認

l DNSの設定を確認するか、ネットワークにDNSサーバをインストールします。

l ControlPanel->Network->Protocols->TCP/IPの設定を確認します。これらの設

定が正しいことをネットワーク管理者に確認してください。

[DNS] タブのホスト名は、ローカルネームサーバで使用されているものと一

致している必要があります。これは、GUIエラーメッセージで指定したホスト

名とも一致している必要があります。

l ローカルホストおよびその接続先となる LifeKeeperサーバのエントリを含める形で

hosts ファイルを編集してください。Windows 95/98システムでは、hosts ファイルは以下のようになります。

%windir%\HOSTS (for example, C:\WINDOWS\HOSTS).

注記 : Windows 95/98では、hosts ファイルの最後のエントリがキャリッジリ

ターン (CR)またはラインフィード (LF)で終わっていない場合、hosts ファイ

ルはまったく読み取られません。

Windows NTシステムでは、hosts ファイルは以下のようになります。

%windir%\System32\DRIVERS\ETC\HOSTS

(for example,

C:\WINNT\System32\DRIVERS\ETC\HOSTS).

たとえば、システムがHOSTCLIENT.MYDOMAIN.COMと呼ばれ、 IPアド

レスとして 153.66.140.1を使用している場合、hosts ファイルに次のエント

リを追加します。

153.66.140.1 HOSTCLIENT.MYDOMAIN.COM HOSTCLIENT

3. GUI クライアントで使用するホスト名プロパティを設定してください。プラグインでブラウザからホスト

名を設定するには、[Java Plug-In Control Panel]を開き、[Java Run Time Parameters]に以下の値を追加してクライアントのホスト名を設定します。

Djava.rmi.server.hostname=<MY_HOST>

4. Microsoftのネットワーク関連のパッチをwww.microsoft.comで確認してください。


http://www.microsoft.com/en-us/default.aspx

Linuxから:

Linuxから:1. ホスト名または IPアドレスを使用して Linuxからターゲットサーバを pingし、他のサーバとの通信

を確認します。

ping <TARGET_NAME>


ping homer

ターゲットの修飾されたホスト名をリストする応答が表示されるはずです。

2. ホスト名または IPアドレスで pingを実行し、クラスタ内の各サーバでローカルホストが解決可能

であることを確認します。DNSが実装されていない場合、 /etc/hosts ファイルを編集し、ローカル

ホスト名のエントリを追加します。このエントリで、ローカルサーバの IPアドレスまたはデフォルトエ

ントリ (127.0.0.1)をリストできます。

3. DNSがNISの前に指定されていることを確認します。 /etc/nsswitch.confのhosts行で DNSをNISの前に置く必要があります。また、 /etc/resolv.confは正しく設定されたDNSサーバを指

す必要があります。

4. DNSを実装しない場合、または他の方法がうまくいかない場合は、 /etc/hosts ファイルを編集

し、ホスト名のエントリを追加します。

5. GUI クライアントで使用するホスト名プロパティを設定してください。これは、管理者ごとに変更す


プラグインでブラウザからホスト名を設定するには、[Java Plug-In Control Panel]を開き、[JavaRun Time Parameters]に以下の値を追加してクライアントのホスト名を設定します。


HotJavaブラウザからホスト名を設定するには、hotjavaコマンドラインに以下の値を追加しま

す。



-Djava.rmi.server.hostname=153.66.140.1

-Djava.rmi.server.hostname= homer.somecompany.com

X Window Serverに接続できない:LifeKeeper GUIアプリケーションを telnetセッションから実行している場合、GUI クライアントが

LifeKeeperサーバで XWindow Serverにアクセスできることを確認する必要があります。LifeKeeperサーバはGUI クライアントのホスト名またはネットワークアドレスを解決できる必要があります。

LifeKeeperサーバに対して telnetを実行して LifeKeeper GUIアプリケーションを実行した場

合、DISPLAY環境変数にはクライアントのホスト名と表示番号を含める必要があります。たとえ

ば、Server1というサーバにClient1というクライアントから telnetを実行した場合、DISPLAY環境変数

はClient1:0に設定される必要があります。LifeKeeper GUIアプリケーションを実行した場合、Client1


システムの日付と時刻の調整

のDISPLAY名に出力が送信されます。Client1がXWindow Serverにアクセスできない場合、例外

が発生して LifeKeeper GUIアプリケーションは失敗します。

LifeKeeper GUIをアプリケーションとして起動したときに、XWindow Serverに接続できない、またはクラ

イアント DISPLAY名を開くことができないというエラーが発生した場合は、以下の手順を実行してくだ

さい。

1. ホスト名または IPアドレスを使用して表示変数を設定します。たとえば、以下のようになりま

す。

DISPLAY=Client1.somecompany.com:0

DISPLAY=172.17.5.74:0

2. xhost または xauth コマンドを使用し、クライアントがLifeKeeperサーバで XWindowServerに接続できることを確認します。

3. クライアント用のDNSエントリを追加するか、クライアント用のエントリを LifeKeeperサーバのロー

カルホストファイルに追加します。LifeKeeperサーバからクライアントに対して、ホスト名または IPアドレスを使用して pingを実行し、クライアントとの通信を確認します。

システムの日付と時刻の調整

マルチユーザモードのときにシステムの日付 /時刻を過去に変更すると、LifeKeeperに問題が発生する

可能性があります。リソース管理の際には SCSI ha_xref_tblが使用されます。日付または時刻が過

去の時間値に変更された場合、新しい時刻よりも後のタイムスタンプが付いているリソースの管理は、

新しい時間がha_xref_tblの作成時点に達するまでフリーズする可能性もあります。この問題の結

果、フリーズしている間にリソースを作成または変更する際に問題になる可能性があります。

システムの日付 /時刻カウンタを過去に調整するには:

1. シングルユーザモードにします( LifeKeeperを停止させてから)。

2. 日付または時刻を過去のものに変更します。

3. マルチユーザモードに戻します。

4. LifeKeeperを再起動します。この操作によって、新しい現在時刻を設定した新しい ha_xref_tblが作成され、操作を続行できるようになります。

注記 : タイムゾーン( TZシェル変数 )を変更した場合、または夏時間から標準時間に変更した場

合、LifeKeeperには影響しません。Linuxは、すべての時間値を 1970年 1月 1日からの絶対秒数と

して保持します。タイムゾーンまたは夏時間 /標準時間の変更は、その絶対秒数をASCIIで解釈した

値に過ぎないので、カウンタ自体は変更されません。

コミュニケーションパスの稼働と停止

コミュニケーションパスの停止と稼働が繰り返される場合 ( LifeKeeper GUIでAlive、Dead、Aliveというよ

うに表示される場合 )、ハートビートの設定がクラスタ内のすべてのサーバで同じ値に設定されていない

可能性があります。


推奨される対策

この状態は、いずれか一方のサーバにある LifeKeeperデフォルトファイル /etc/default/LifeKeeperで設定名に誤記がある場合にも発生する可能性があります。

推奨される対策

1. クラスタ内のすべてのサーバで LifeKeeperを停止します。

2. クラスタ内の各サーバで、 /etc/default/LifeKeeperにある LCMHBEATTIME設定と

LCMNUMHBEATS設定の値とスペルを確認します。設定値、スペルミスの無いことを各ノード

で確認します。

3. クラスタ内のすべてのサーバで LifeKeeperを再起動します。

不完全なリソースの作成

インスタンスの一部のみが作成された状態で、リソース設定プロセスが中断された場合、階層を再設

定する前に、手動でクリーンアップする必要があります。LifeKeeper GUIを使用し、一部が作成された

リソースを削除してください。手順については、すべてのサーバからの階層の削除を参照してください。

階層リストにこれらのリソースが含まれていない場合、 ins_remove( LCDI-instances(1M)を参照 )およ

びdep_remove( LCDI-relationship(1M))を使用し、部分的な階層をクリーンアップしなければならない

可能性もあります。

不完全なリソースの優先順位の変更

LifeKeeperの階層は、親子の関係によって関連付けられたすべてのリソースとして定義されています。

複数の親を持つリソースの場合、GUI と階層のすべてのリソースを区別することは一概に簡単とも言え

なくなります。階層の整合性を保持するには、サーバごとに階層内のすべてのリソースに対して優先順

位を変更する必要があります。 [OK]または [Apply]ボタンを押した後で選択される階層のすべてのルー

トリソースを表示することで、GUIはこの要件を強制します。この時点で、すべてのルートを受け付ける

か、操作をキャンセルするかを選択できます。ルートのリストを受け付けた場合、新しい優先順位の値

が階層内のすべてのリソースに割り当てられます。

その階層の [Resource Properties]ダイアログが表示されている間、他の変更を階層に加えていること

を確認する必要があります。 [Resource Properties]ダイアログの優先順位を編集する前

に、LifeKeeperに加えられた変更が動的にダイアログで更新されます。ただし、変更を加えると、基本

的な変更がLifeKeeperで加えられた場合でも、ダイアログの値は凍結されます。 [Apply]または [OK]ボタンをクリックした後でのみ、変更が加えられたことが通知されるので、優先順位の変更操作は要求

どおりに進みません。

複数の優先順位の変更を伴う優先順位の変更操作時に、復旧できないエラーの可能性を最低限

に抑えるには、プログラムは、一度に 1つのサーバに対して個別に行われる一連の変更として、複数

の優先順位の変更操作を実行します。また、操作時に優先順位の競合を防ぐために、必要に応じ

て一時的な値がプロパティに割り当てられます。この一時的な値は、最大許容値 999を超えるもの

で、優先順位の変更中に一時的にGUIに表示されることもあります。操作が完了すると、一時的な

値はすべて、要求された値に置き換えられます。エラーが発生し、優先順位の値をロールバックできな

い場合、一時的な優先順位の値の一部がそのまま残る可能性もあります。この場合は、下記の推

奨手順に従って階層を修復してください。


一貫した状態への階層のリストア

一貫した状態への階層のリストア

優先順位の変更操作の間にエラーが発生し、操作を完了できない場合、優先順位は不整合の状

態のまま残る可能性があります。エラーは、システムやコミュニケーションパスの障害を含め、さまざまな

理由で発生します。操作が開始された後や完了する前にエラーが発生し、プログラムが前の優先順

位にロールバックできなかった場合、操作中にエラーがあったこと、および前の優先順位を restoreでき

なかったことを示すメッセージが表示されます。この場合、以下の処置を実行し、階層を一貫性のある

状態に restoreする必要があります。

1. 可能であれば、問題の原因を特定します。システムまたはコミュニケーションパスの障害を確認

します。優先順位管理プログラムの実行中に、その他の操作が行われていないことを確認しま

す。

2. 可能であれば、問題の原因を修正してから先に進みます。たとえば、階層を修復する前に、

障害が発生したシステムまたはコミュニケーションパスを restoreする必要があります。

3. [Resource Properties]ダイアログから操作を再試行します。

4. [Resource Properties]ダイアログから変更できない場合は、コマンドライン hry_setpriを使

用して階層を修復するとより簡単かもしれません。このスクリプトを使用すると、一度に 1つの

サーバに対して優先順位を変更できます。このスクリプトは、GUIからは実行できません。

5. 修復を実行したら、階層が存在するすべてのサーバに対して eqv_listコマンドを実行し、階

層のすべてのリソースに対して返された優先順位の値を調べ、LifeKeeperデータベースがすべて

のサーバで一貫していることを確認します。

6. 最終的に、階層を修復できない場合は、階層を削除して再作成する必要がある可能性もあ

ります。

階層の設定中に共有ストレージが見つからない

リソースの階層を設定中に、LifeKeeperが「No shared storage」(共有ストレージがありません)というメッ

セージをレポートする状況がいくつかあります。

考えられる原因 :ストレージを共有するサーバー間でコミュニケーションパスが定義されていません。共有

ストレージデバイスで階層が設定されている場合、LifeKeeperは、クラスタ内の別のサーバを少なくとも

1つ検証し、その共有ストレージにアクセスできることを確認します。

推奨される対策 : LifeKeeper GUIまたは lcdstatus (1M)を使用し、コミュニケーションパスが設定

されており、アクティブになっていることを確認します。

考えられる原因 :ストレージを共有するサーバー間でコミュニケーションパスが機能していません。

推奨される対策 : LifeKeeper GUIまたは lcdstatus (1M)を使用し、コミュニケーションパスが設定

されており、アクティブになっていることを確認します。


LifeKeeperサーバ障害からの復旧

考えられる原因 : Linuxが共有ストレージにアクセスできない。この原因としては、ドライバがロードされ

ていないことや、ドライバがロードされたときにストレージの電源が入っていないこと、あるいはストレージデ

バイスが正しく設定されていないことなどが考えられます。

推奨される対策 : /proc/scsi/scsiでデバイスが正しく定義されていることを確認します。

考えられる原因 : LifeKeeperを起動する前にストレージがLinuxで設定されていない。LifeKeeperの起

動時に、すべてのSCSIデバイスがスキャンされ、デバイスのマッピングが判別されます。LifeKeeperの起

動後にデバイスが設定された (電源がオンにされた、接続された、またはドライバがロードされた)場合、

デバイスを設定して使用できるようにするには、LifeKeeperを停止してから再起動する必要がありま

す。

推奨される対策 : $LKROOT/subsys/scsi/Resources/hostadp/device_infoにデバイスがリ

ストされていることを確認してください。$LKROOTは、デフォルトでは /opt/LifeKeeper. です。デバ

イスがこのファイルにリストされていない場合、LifeKeeperはそのデバイスを使用しません。

考えられる原因 :ストレージがサポートされていない。ストレージとアダプタのトピックでは、LifeKeeperで動作がテストされ、サポートされている具体的な SCSIデバイスが列挙されています。ただし、このリスト

に含まれているのは、すでに知られているデバイスなので注意してください。LifeKeeperの要件を満たし

ているものの、SIOS Technology Corp.がテストしていないデバイスが存在する可能性もあります。

推奨される対策 : $LKROOT/subsys/scsi/Resources/hostadp/device_infoにデバイスがリ

ストされていることを確認してください。$LKROOTは、デフォルトでは /opt/LifeKeeperです。デバイ

スがこのファイルにリストされているものの、デバイス名の後に来る IDが「NU-」で始まる場合、LifeKeeperはデバイスから一意の IDを取得できなかったことを示します。一意の IDがない場合、LifeKeeperはデ

バイスが共有されているかどうかを判別できません。

考えられる原因 :ストレージでは、デバイスを LifeKeeperで使用できるようにする前に、特定の

LifeKeeperソフトウェアをインストールする必要があります。たとえば、Raw I/Oサポートを有効にするた

めのsteeleye-lkRAWキット、データレプリケーションを有効にするためのsteeleye-lkDR ソフトウェアなど

です。

推奨される対策 :必要な LifeKeeperパッケージが各サーバにインストールされていることを確認します。

ソフトウェアの要件については、 SPS for Linux リリースノートを参照してください。

補足のヒント :

test_lk(1M) ツールを使用すると、ストレージおよび通信の問題のデバッグに役立ちます。

LifeKeeperサーバ障害からの復旧

LifeKeeperクラスタ内のサーバに、オペレーティングシステムの再インストールを (したがって LifeKeeperの再インストールも)必要とする障害が発生した場合、クラスタの各サーバからリソース階層を再拡張する

必要があります。ただし、再インストールしたサーバとの共有イクイバレンシ関係がクラスタのサーバにあ

る場合、LifeKeeperは、再インストールしたサーバへ既存のリソース階層を拡張することを許可しませ


推奨される対策 :

ん。また、再インストールされたサーバには階層が実際には存在していないため、再インストールした

サーバから階層を拡張解除することもできません。

推奨される対策 :1. リソース階層が設定されている各サーバで、eqv_list コマンドを使用してすべての共有イクイバレ

ンシのリストを取得します (詳細については、LCDI-relationshipを参照してください).

下記の例では、server1および server2に対する IP リソースの iptagのコマンドおよび結果の出

力を示します。ここでは、server2が再インストールされたサーバ、server1が設定された階層で

す。

eqv_list -f:

server1:iptag:server2:iptag:SHARED:1:10

2. リソース階層が設定された各サーバで、eqv_removeを使用して、階層の各リソースのイクイバ

レンシ関係を手動で削除します (詳細については、LCDI-relationshipを参照してくださ

い)。

たとえば、上記の手順 1の例を基に、server1に対して以下のコマンドを実行します。

eqv_remove -t iptag -S server2 -e SHARED

3. 2つ以上のサーバがあるクラスタでは、これらのリソース階層のイクイバレンシ関係が定義されてい

るクラスタ内の各サーバに対して手順 1と2を繰り返します。

4. 最後に、GUIを使用し、リソース階層が in-serviceになっているサーバから再インストールされた

サーバに各リソース階層を拡張します。

停止できないプロセスからの復旧

プロセスが停止不可の場合、LifeKeeperは共有ディスクパーティションをアンマウントできない可能性が

あります。そのため、リソースを別のシステムで In Serviceにすることができません。停止できないプロセス

から復旧する唯一の方法は、システムを再起動することです。

手動リカバリ時のパニックからの復旧

手動スイッチオーバ時にPANICになると、リカバリが不完全に終わる可能性があります。PANICまたは

その他の大きなシステム障害が手動スイッチオーバ時に発生した場合、バックアップシステムへの完全

自動リカバリは保証できなくなります。 In Serviceになる必要があるすべてのリソースが In Serviceである

ことをバックアップシステムで確認してください。 In Serviceではないリソースがあった場合は、LifeKeeperGUIを使用して、そのリソースを手動で In Serviceにします。手順については、リソースを In-Serviceするを参照してください。

Out-of-Service 階層の復旧

LifeKeeperサーバの障害からの復旧の一環として、障害が発生したサーバで設定されているものの、

サーバの障害時にどのサーバでも In Serviceではなかったリソース階層が、障害時に最優先で Aliveになったサーバで復旧されます。これは、障害が発生したサーバ、復旧中のサーバ、階層内の他の


リソースタグ名の制限

サーバを含め、Out of Serviceの階層が最後にどこで In Serviceだったかには無関係です。

リソースタグ名の制限

Tag Name Lengthタグ名の長さ

All tags within LifeKeeper may not exceed the 256 character limit.

有効な "特殊" 文字

- _ . /

しかしながらタグの先頭には以下を含むことができません。

"." or "/".

無効な文字

+ ; : ! @ # $ * = "space"

シリアル (TTY) コンソールの警告

シリアルコンソールデータパスの一部が信頼できない場合、またはOut of Serviceになった場合、シリア

ル (RS-232 TTY)コンソールを使用するユーザは LifeKeeperサービスで深刻な問題に直面する可能性

があります。操作中に、LifeKeeperはコンソールメッセージを生成します。設定に (標準的な VGAコン

ソールではなく)シリアルコンソールがある場合、これらのコンソールメッセージが確実に配信されるように

するために、LifeKeeperからエンドユーザターミナルへのデータパス全体が機能している必要があります。

ターミナルの電源オフ、モデムの未接続、ケーブルのゆるみなど、データパスがつながっていない場

合、Linux STREAMSファシリティは、コンソールメッセージをキューに入れます。STREAMSキューがいっ

ぱいになった場合、Unix カーネルは、STREAMSバッファキューにメッセージを入れる余地ができるまで

LifeKeeperを保留にします。これにより、LifeKeeperがハングすることもあります。

注記 : LifeKeeper環境のシリアルコンソールは可能なかぎり避け、VGAコンソールを使用することを推

奨します。シリアルコンソールを使用する必要がある場合、シリアルコンソールがオンになっていること、

ケーブルとオプションのモデムが正しく接続されていること、メッセージが表示されていることを必ず確認し

てください。

システムが init 状態 S に遷移しているという警告

LifeKeeperが動作している場合、システムを直接、 init状態 Sに切り替えないでください。Linuxの initシステムの操作が原因で、こうした遷移が全 LifeKeeperプロセスの即時停止につながり、突発的な

障害を発生させる可能性があります。この場合は、代わりに LifeKeeperを (lkstopで)手動停止す

るか、システムを最初に init状態 1にしてから init状態 Sにしてください。


共有ストレージでスレッドがハングしているというメッセージ

共有ストレージでスレッドがハングしているというメッセージ

デバイス確認スレッドがそれほど迅速に処理を完了していない場合、スレッドがハングしているというメッ

セージがLifeKeeperログに記録されることがあります。これにより、リソースがあるサーバから別のサーバに

移動し、さらに悪いケースでは、サーバが停止する可能性があります。

説明

(/etc/default/LifeKeeperの) FAILFASTTIMERは、各デバイスが正常に動作していること、お

よび特定のシステムによって所有されているすべてのリソースがそのシステムからアクセス可能で、そのシ

ステムに所有されていることを確認するための秒数を定義します。FAILFASTTIMERは、この所有権を

確定し、データの信頼性を最大限に確保するために、可能なかぎり小さくする必要があります。ただ

し、デバイスがビジー状態で、負荷がピークの場合、指定した時間内で応答できない可能性もありま

す。デバイスの操作がFAILFASTTIMERよりも長くかかっている場合、LifeKeeperはデバイスがハングし

ている可能性を検討します。FAILFASTTIMERの時間を 3回繰り返してもデバイスが応答しない場

合、LifeKeeperは、デバイスに障害が発生したものとみなして、リカバリを実行します。リカバリプロセス

は、SCSIERRORの設定で定義します。SCSIERRORの設定によっては、ローカルリカバリを実行し、

失敗した場合はスイッチオーバを実行するために sendeventが発行されることもあります。この操作がな

い場合、システムが停止するおそれもあります。

推奨される対策 :ハングメッセージがまれにエラーログに出力され、もうハングしていないというメッセージがそれに続く場合、

さらに括弧の数が常に 1つの場合、それほど警戒する理由はありません。ただし、このメッセージが頻

繁にログに記録され、数が2または 3の場合、以下の2つの処置が必要になる可能性があります。

l ストレージの負荷を減らすことを試みる。ストレージの処理に FAILFASTTIMER (デフォルトで

は、5秒または 15秒を 3回 )の3倍の時間がかかっている場合、ストレージに対する負荷を考

慮し、 I/Oの長い遅延を避けるために負荷を分散する必要があります。これにより、LifeKeeperは、デバイスを頻繁に確認できるようになり、さらにそのデバイスを使用しているアプリケーションの

パフォーマンスも向上します。

l 負荷を減らすことができない場合、FAILFASTTIMERをデフォルトの5秒から増やすことができま

す。この値は、できる限り低く抑える必要があります。そのため、メッセージがまったく表示されなく

なるか、まれにしか表示されなくなるまで、少しずつ値を増やしてください。

注記 : FAILFASTTIMERの値が変更された場合、新しい値を有効にするために、LifeKeeperを終了

し、再起動する必要があります。


Chapter 4: SteelEye DataKeeper for Linux

はじめに

SteelEye DataKeeper for Linuxは、LifeKeeper環境に統合データミラーリング機能を提供します。この

機能により、LifeKeeperリソースが共有 /非共有ストレージ環境で動作可能になります。

SteelEye DataKeeper for Linuxによるミラーリング

Steeleye DataKeeperの仕組み

SteelEye DataKeeper for Linux によるミラーリング

SteelEye DataKeeper for Linuxは、共有ストレージを使用せずに可用性の高いクラスタ( SteelEyeLifeKeeperを使用 )を構築したいお客様や、ビジネスに不可欠なデータをサーバ間でリアルタイムに複

製したいお客様に別の方法を提供します。

SteelEye DataKeeperは、同期または非同期のボリュームレベルのミラーリングを使用して、プライマリ

サーバ(ミラーソース)から 1台以上のバックアップサーバ(ミラーターゲット )にデータを複製します。

DataKeeperの特長

SteelEye DataKeeperには、以下の特長があります。

l TCP/IPベースのローカルエリアネットワーク( LAN)またはワイドエリアネットワーク( WAN)経由で、

リモートの場所に高い信頼性、効率、整合性でデータをミラーリングできます。

l 同期と非同期のミラーリングをサポートします。

l 複製はファイルシステムの下のブロックレベルで実行されるので、関与するアプリケーションに対し

て透過的です。

l LifeKeeperと共に使用した場合、複数ターゲットへのカスケーディングフェイルオーバも含めて、

複数ターゲットへの同時ミラーリングをサポートします。

l 特定時点のデータへのリワインドをサポートしているので、喪失したデータや破損データの復旧

ができます。

l 内蔵のネットワーク圧縮ににより、ワイドエリアネットワークでの最大スループットが向上します。

l 主要なファイルシステムをすべてサポートします(ファイルシステムのジャーナリングサポートの詳細

については、 SPS for Linux リリースノートの製品説明を参照してください)。

l ミラーリングしたデータにフェイルオーバの保護を提供します。


同期ミラーリングと非同期ミラーリングの違い

l LifeKeeperのグラフィカルユーザインターフェースに統合されています。

l 他のLifeKeeper Application Recovery Kitをフルにサポートします。

l システムリカバリ時に、プライマリサーバとバックアップサーバとの間でデータを自動的に再同期しま

す。

l 障害発生時には、仮想のシステムコンポーネントの健全性を監視し、ローカルリカバリを実行し

ます。

l I/Oフェンス用のStonithデバイスをサポートします。詳細については、STONITHのトピックを参


同期ミラーリングと非同期ミラーリングの違い

同期ミラーリングと非同期ミラーリングの違いを理解すると、アプリケーション環境に適切なミラーリング

方法を選択することができます。

同期ミラーリング

SteelEye DataKeeperは、プライマリサーバとバックアップサーバに同時にデータを書き込む同期ミラーリ

ング方法を使用して、リアルタイムミラーを実現します。書き込み動作のたびに、DataKeeperは書き込

みをターゲットデバイスに転送し、リモート確認を受信してから I/O完了を通知します。同期ミラーリング

の長所は、データの保護レベルが高いことです。これは、常にデータのすべてのコピーを確実に同一にし

ているからです。ただし、リモート確認を待つために、パフォーマンスが低下することがあり、これは特に

WAN環境で発生します。

非同期ミラーリング

非同期ミラーリングでは、それぞれの書き込みがソースデバイスに対して行われ、次に、コピーがターゲッ

トデバイスに送信されるキューに入れられます。これはつまり、任意の時点で、ソースからターゲットデバ

イスへの送信を待っている多数の書き込みトランザクションが存在する可能性があります。非同期ミ

ラーリングの長所は、書き込みがプライマリディスクに到達した時点で確認されるため、パフォーマンスが

高いことです。ただし、プライマリディスクに障害が発生した場合、非同期書き込みキュー内にある書き

込みはターゲットに送信されないため、信頼性が低くなります。この問題を緩和するために、SteelEyeDataKeeperはプライマリディスクに対する個々の書き込みについてインテントログファイルにエントリを作

成します。

インテントログとは、プライマリとターゲットのミラー間で同期していないデータブロックを示すビットマップで

す。サーバの障害発生時にインテントログを使用すると、データ全体の再同期を回避できます。

注記 : インテントログは、同期と非同期の両方のミラーモードで使用できます。ただし、非同期ミラーリ

ングのインテントログは、2.6.16以降のLinux カーネルでのみサポートされます。

Steeleye DataKeeperの仕組み

SteelEye DataKeeperは、NetRAIDデバイスを作成して保護します。NetRAIDデバイスはRAID1のデバイスであり、下図に示すようにローカルのディスクまたはパーティション、およびネットワークブロックデバ

イス( NBD)で構成されます。

284 はじめに

同期 (および再同期 )

LifeKeeperがサポートするファイルシステムは、その他すべてのストレージデバイスと同様に、NetRAIDデ

バイスにマウントできます。この場合、ファイルシステムは複製されたファイルシステムと呼ばれま

す。LifeKeeperは、NetRAIDデバイスと複製されたファイルシステムの両方を保護します。

ファイルシステムは、DataKeeper [リソース階層を作成することにより作成されます。NetRAIDデバイスを

別のサーバに拡張するとNBDデバイスが作成され、2台のサーバ間にネットワーク接続が確立されま

す。NBD接続が確立されるとただちに、SteelEye DataKeeperがデータの複製を開始します。

nbd-clientプロセスがプライマリサーバで実行され、バックアップサーバで動作している nbd-serverプロセス

と接続します。

同期 (および再同期 )DataKeeperリソース階層は作成されてから拡張されるまでの間、デグレードモードです。つまり、データ

はローカルのディスクまたはパーティションにのみ書き込まれます。階層をバックアップ(ターゲット )システム

に拡張すると、SteelEye DataKeeperが2つのシステム間でデータを同期し、以降の書き込みはすべて

ターゲットに複製されます。どの時点でもデータが「非同期」になった場合 (システムまたはネットワークの

障害が発生した場合 )、SteelEye DataKeeperはソースとターゲットのシステムでデータを自動的に再

同期します。インテントログ(ビットマップファイル)を使用するようにミラーが設定されている場

合、SteelEye DataKeeperはインテントログを使用して非同期のデータを特定するので、全体の再同

期は不要です。インテントログ(ビットマップファイル)を使用するようにミラーが設定されていない場合は、

データ複製の中断後に全体の再同期が実行されます。

標準ミラーの構成

最も一般的なミラーの構成では、下図に示すように 2台のサーバがあり、各サーバのローカルのディスク

またはパーティションとの間にミラーが確立されます。サーバ1は、ミラーソースを持つプライマリサーバで


N+1の構成

す。サーバ2は、ミラーターゲットを持つバックアップサーバです。

N+1の構成

前述した標準ミラーの構成の変形として一般的に使用される構成では、クラスタ内にある 2台以上

のサーバが共通のバックアップサーバにデータを複製します。この場合は、下図に示すように、各ミラー

ソースがバックアップサーバの個別のディスクまたはパーティションに複製する必要があります。

286 はじめに

複数ターゲットの構成

複数ターゲットの構成

適切な Linuxのディストリビューションとバージョン 2.6.7以降のカーネルと共に使用した場合、下図に示

すように、SteelEye DataKeeperは、プライマリサーバの1つのディスクまたはパーティションから複数のバッ

クアップシステムにデータを複製することもできます。

特定のソースのディスクまたはパーティションを最大 7つのミラーターゲットに複製でき、各ミラーターゲット

は別のシステムに存在する必要があります。つまり、ソースのディスクまたはパーティションを、同一ターゲ

ットシステム上にある複数のディスクまたはパーティションにミラーリングすることはできません。

このタイプの構成では、LifeKeeperのカスケーディングフェイルオーバ機能を使用でき、保護するアプリ

ケーションとそのデータに対して複数のバックアップシステムを提供できます。

SteelEye DataKeeper リソース階層

以下の例に、LifeKeeperのGUIに表示される典型的な DataKeeperリソース階層を示します。


フェイルオーバのシナリオ

リソースdatarep-ext3-sdrはNetRAID リソースであり、親リソースext3-sdrはファイルシステムリソースで

す。本書の以降の部分では、「DataKeeperリソース」は両方のリソースを合わせたものを指すことに注

意してください。ファイルシステムリソースはNetRAID リソースに依存するので、NetRAID リソースに対す

る動作はその上にあるファイルシステムにも影響します。

フェイルオーバのシナリオ

以下の4つの例で、SteelEye DataKeeperを使用するフェイルオーバで何が起きるかを説明します。こ

れらの例では、LifeKeeper for Linux クラスタは、サーバ1(プライマリサーバ)とサーバ2(バックアップサー

バ)の2台のサーバで構成されます。

シナリオ 1

サーバ1が動作不能になった後、サーバ1からサーバ2へのミラーが正常に完了している。

結果 : フェイルオーバが発生します。サーバ2がプライマリサーバの役割を担当し、サーバ1が再び動作

可能になるまでデグレードモード (バックアップなし)で動作します。サーバ1が再び動作可能になる

と、SteelEye DataKeeperがサーバ2からサーバ1への再同期を開始します。2.6.18以前のカーネルで

は、全体の再同期が実行されます。2.6.19以降のカーネル、またはRedHat Enterprise Linux 5.4の2.6.18-164以降のカーネル(またはRedHat 5.4以降のサポートする派生カーネル)では、部分的な再

同期が実行されます。つまり、ソースとターゲットにあるビットマップファイルに記録された変更部分につい

てのみ同期が必要です。

288 はじめに

シナリオ2

注記 : SteelEye DataKeeperは、現在ミラーソースとして動作しているサーバに以下のフラグをセットしま

す。

$LKROOT/subsys/scsi/resources/netraid/$TAG_last_owner

サーバ1がサーバ2にフェイルオーバすると、このフラグがサーバ2にセットされます。このため、サーバ1が動作を再開すると、SteelEye DataKeeperはこの最終オーナフラグをサーバ1から削除します。その後、

サーバ2からサーバ1にデータの再同期を開始します。

シナリオ 2

シナリオ1で、サーバ2(プライマリサーバである状態 )が、サーバ1(この時点ではバックアップサーバ)との再同期中に動作不能になる。

結果 :再同期プロセスが正常に完了しなかったので、データが破損している可能性があります。この結

果、LifeKeeperはDataKeeperリソースをサーバ1にフェイルオーバしません。サーバ2が動作可能にな

った場合にのみ、LifeKeeperはサーバ2で DataKeeperリソースを In Service ( ISP)にします。

シナリオ 3

サーバ1(プライマリ)とサーバ2(ターゲット )の両方が動作不能になる。サーバ1(プライマリ)が最初に動

作可能になる。

結果 :サーバ1は、DataKeeperリソースを In Serviceにしません。この理由は、停止してからオンライン

に戻ったソースサーバは、ターゲットと通信できないからです。ソースサーバは以下のタグをセットします。

$LKROOT/subsys/scsi/resources/netraid/$TAG_data_corrupt

これは、正しくない方向へのデータ同期を防止する安全策です。この場合、サーバ1でミラーを強制的

にオンラインにする必要があります。つまり、サーバ1のdata_corrupt フラグを削除し、リソースを InServiceにします。ミラーを強制的にオンラインにするを参照してください。

注記 : $TAG_data_corrupt フラグを削除する前に、サーバ1が最終のプライマリサーバであることを確認

する必要があります。サーバ1が最終のプライマリサーバでない場合、データが破損する可能性がありま

す。これは、 last_ownerフラグの有無で確認できます。

シナリオ 4

サーバ1(プライマリ)とサーバ2(ターゲット )の両方が動作不能になる。サーバ2(プライマリ)が最初に動

作可能になる。


シナリオ4

結果 : LifeKeeperは、サーバ2のDataKeeperリソースを ISPにしません。サーバ1が動作可能になる

と、LifeKeeperはサーバ1のDataKeeperリソースを ISPにします。

290 はじめに


SteelEye DataKeeper for Linuxのインストールと設定

ハードウェア / ソフトウェア要件

DataKeeper リソースを設定する前に

以下のトピックには、DataKeeperリソースの作成と管理を行う前に考慮が必要な情報があります。ま

た、3種類のDataKeeperリソースについても説明しています。LifeKeeper Coreのリソース階層を設定

する手順については、LifeKeeperの設定セクションを参照してください。

ハードウェアとソフトウェアの要件

SteelEye DataKeeperをインストールするには、LifeKeeperの構成が次の要件を満たしている必要が

あります。

ハードウェアの要件

l サーバ - LifeKeeper for Linuxをサポートする 2台以上のサーバ。

l IP ネットワークインターフェースカード -各サーバにネットワークインターフェースカードが1つ以上

必要です。ただし、LifeKeeperクラスタには 2つのコミュニケーションパスが必要です。独立した 2つのサブネットを使用する 2つの分離した LANベースのコミュニケーションパスが推奨され、これら

の1つ以上をプライベートネットワークとして構成する必要があります。ただし、TCP とTTYを組

み合わせて使用することもできます。

注記 : ソフトウェアミラーリングの特性により、サーバ間のネットワークトラフィックが多くなる可能性

があります。このため、SteelEye DataKeeperのデバイス用に個別のプライベートネットワークを実

装することが推奨されます。この実装には、各サーバに追加のネットワークインターフェースカード

が必要になることがあります。

l ディスクまたはパーティション -ソースとターゲットのディスクまたはパーティションとして動作する、プラ

イマリサーバとバックアップサーバのディスクまたはパーティション。ターゲットのディスクまたはパーティ

ションは、ソースのディスクまたはパーティション以上のサイズである必要があります。

注記 : SteelEye Data Replication 7.1.1のリリースから、パーティションが作成されていないディス

ク全体 ( /dev/sdd)の複製が可能になりました。旧バージョンのSteelEye Data Replicationでは、ディスクを複製するには、パーティションを作成する必要がありました( /dev/sdd1のような 1つの大きいパーティションの場合でも)。SteelEye Data Replication 7.1.1からこの制限が取り除か

れました。


ソフトウェアの要件

ソフトウェアの要件

l オペレーティングシステム– SteelEye DataKeeperは、2.6 Linux カーネルをベースにする主要な

Linuxのディストリビューションと共に使用できます。サポートしているディストリビューションのリスト

についてはSPS for Linux リリースノートを参照してください。非同期ミラーリングとインテントログ

は、2.6.16以降のLinux カーネルを使用するディストリビューションでのみサポートされます。複数

のターゲットのサポート (複数のミラーターゲットのサポート )には、2.6.7以降のLinux カーネルが

必要です。

l LifeKeeper のインストールスクリプト -多くの場合、パッケージをインストールする必要がありま

す( SteelEye DataKeeperの特定の要件については SPS for Linux リリースノートの「製品の要

件」セクションを参照してください)。

HADR-generic-2.6

SteelEye DataKeeperをインストールする前に、LifeKeeperクラスタの各サーバにこの

パッケージをインストールする必要があります。HADRパッケージは、 SPSのインストー

ルイメージファイルにあり、インストールのsetupスクリプトにより該当するパッケージが自

動的にインストールされます。

l LifeKeeper ソフトウェア -各サーバに同じバージョンのLifeKeeper Coreをインストールする必要

があります。また、使用を計画している同じバージョンのRecovery Kit も各サーバにインストール

する必要があります。SPS LifeKeeperの特定の要件については、 SPS for Linux リリースノート


l SteelEye DataKeeper ソフトウェア - SPSクラスタの各サーバには、SteelEye DataKeeperソフト

ウェアが必要です。SteelEye DataKeeperのインストールと削除の特定の手順については、SPSfor Linux インストールガイドを参照してください。

全般的な設定

l ターゲットのディスクまたはパーティションのサイズ(バックアップサーバ上 )は、ソースのディスクまたは

パーティションのサイズ(プライマリサーバ上 )以上である必要があります。

l DataKeeperリソースを作成して拡張すると、同期プロセスによりターゲットのディスクまたはパーテ

ィションに存在するデータが削除され、ソースのパーティションにあるデータに置き換えられます。

ネットワークと LifeKeeperの設定

l 各ペアのサーバ間でデータのレプリケーション用に選択するパスは、あらかじめそれらのサーバ間の

LifeKeeperコミュニケーションパスとしても設定されている必要があります。ネットワークパスを変更

する方法については、データレプリケーションパスの変更を参照してください。

l DataKeeperリソースを設定するときには、ローカルリカバリを有効にしている LifeKeeper IP リソー

スがすでに使用しているインターフェース/アドレスの使用は避けてください。例えば、LifeKeeperIP リソースがインターフェースeth1に構成されており、インターフェースeth2でのローカルリカバリが

有効にされている場合、eth1とeth2のいずれについても DataKeeperリソースによる使用を避け

る必要があります。ローカルリカバリを有効にすると、バックアップインターフェースへのスイッチオーバ

中にインターフェースが無効になるので、SteelEye DataKeeperに障害が発生することがありま

292 インストールと設定

データ複製パスの変更

す。

l このリリースのSteelEye DataKeeperは、DataKeeperリソースの自動スイッチバックをサポートし

ていません。さらに、自動スイッチバックの制限は、DataKeeperリソースの上に存在する他の

LifeKeeperリソースにも適用されます。

データ複製パスの変更

LK 7.1から、lk_chg_valueを使用して、LK 7.1からマイナーエンドポイントを変更できるようになりま

した。例えば、マイナーエンドポイントを IPアドレスの192.168.0.1から 192.168.1.1に変更するには、

以下の操作を行います

1. lkstop ( lk_chg_value は、LifeKeeperの動作中は実行できません)。

2. lk_chg_value -o 192.168.0.1 -n 192.168.1.1

3. lkstart

この IPアドレスを使用するミラーに含まれるすべてのサーバで、これらのコマンドを実行してください。

注記 : このコマンドは、該当アドレスを使用するコミュニケーションパスも変更します。

ネットワーク帯域幅の要件の特定

SteelEye DataKeeperをインストールする前に、現在の構成の複製に仮想マシンを使用するか、物理

的な Linuxサーバを使用するかによりネットワーク帯域幅の要件を特定する必要があります。仮想マシ

ン( VM)を使用する場合は、Linuxシステム(物理または仮想 )の変化率の測定方法を使用して、複

製を計画している仮想マシンの変化率を測定してください。この値は、仮想マシンの複製に必要とな

るネットワーク帯域幅を表します。

ネットワーク帯域幅の要件を特定した後、ネットワークが最大のパフォーマンスを発揮するように構成し

てください。ネットワーク帯域幅の要件が、現在使用できるネットワーク能力を超えている場合は、以

下のオプションを 1つ以上検討しなければならない可能性があります。

l SteelEye DataKeeper(または可能な場合はネットワークハードウェア)の圧縮を有効にする。

l ネットワーク能力を増強する。

l 複製するデータ量を低減する。

l 一時データおよびスワップファイル用に、複製しないローカルのストレージリポジトリを作成する。

l 毎日、ピーク時以外に複製を手動でスケジュールする。

Linux システム(物理または仮想 )での変化率の測定

DataKeeper for Linuxは、使用できるネットワーク内でデータを複製できます。マルチサイト、すなわち広

域ネットワーク( WAN)構成では、「ソースパーティションが1日中更新されるときに、パーティションを正

常に複製してミラーをミラーリング状態に維持するために十分な帯域幅があるか」という質問に対して

特別な検討が必要です。



ミラーがミラーリング状態でない場合にはパーティションのスイッチオーバは許可されないので、ミラーをミ

ラーリング状態に維持することが重要です。


SteelEye DataKeeperをインストールする前に、データを複製するネットワーク帯域幅の要件を特定す

る必要があります。以下の方法を使用して、複製を計画しているデータの変化率を測定してください。

この値は、データの複製に必要なネットワーク帯域幅の量を表します。

ネットワーク帯域幅の要件を特定した後、ネットワークが最大のパフォーマンスを発揮するように構成し

てください。ネットワーク帯域幅の要件が、現在使用できるネットワーク能力を超えている場合は、以

下のオプションを 1つ以上検討する必要があります。

l DataKeeper(または可能な場合はネットワークハードウェア)の圧縮を有効にする。

l 複製が不要な一時データおよびスワップファイル用に、複製しないローカルのストレージリポジトリ

を作成する。

l 複製するデータ量を低減する。

l ネットワーク能力を増強する。

SteelEye DataKeeperはデータを非同期キューに追加することにより、短期間に急増した書き込み動

作を処理します。ただし、長期間にわたって複製されるすべてのボリュームのディスク書き込み動作の

合計が、平均して DataKeeperとネットワークが送信できる変化量を下回ることを確認してください。

ネットワーク能力が不十分なためにディスクの変化率に対処できず、非同期キューがいっぱいになった

場合、ミラーは同期動作に戻ります。これによりソースサーバのパフォーマンスに悪影響を及ぼすことが

あります。

基本変化率の測定

以下のコマンドを使用して、ミラーリングするファイルまたはパーティションを特定してください。例えば

/dev/sda3を使用して、1日に書き込まれるデータ量を測定します。

MB_START=`awk '/sda3 / { print $10 / 2 / 1024 }'

/proc/diskstats`

1日後

MB_END=`awk '/sda3 / { print $10 / 2 / 1024 }'

/proc/diskstats`

1日の変化率 (単位 : MB)は MB_END – MB_STARTで得られます。

SteelEye DataKeeperが1日にミラーリングできるおよその量は以下のとおりです。

T1( 1.5Mbps) - 14,000MB/日 ( 14 GB)

T3( 1.5Mbps) - 410,000MB/日 ( 410GB)

ギガビット ( 1 Gbps) - 5,000,000MB/日 ( 5 TB)


詳細変化率の測定

詳細変化率の測定

変化率を収集する最良の方法は、一定期間 (例 : 1日 )ディスクの書き込み動作をログに記録して、

ディスクの書き込みのピーク期間を特定することです。

ディスクの書き込み動作を追跡するには、システムのタイムスタンプをログに記録して /proc/diskstatsのダンプを行う cronジョブを作成してください。例えば、2分間隔でディスクの統計値を収集するに

は、 /etc/crontabに以下のリンクを追加します。 :

*/2 * * * * root ( date ; cat /proc/diskstats ) >> /path_

to/filename.txt

1日、1週間などの期間が経過した後、cronジョブを無効にし、得られたデータファイルを安全な場所

に保存します。

収集した詳細変化率データの解析

roc-calc-diskstatsユーティリティは、前述の手順で収集したデータを解析します。このユーティリ

ティは、長期間ログに記録された出力を持つ /proc/diskstats出力ファイルから、データセットに含まれる

ディスクの変化率を計算します。

roc-calc-diskstats

#!/usr/bin/perl

# Copyright (c) 2011, SIOS Technology, Corp.

#作成者:Paul Clements

use strict;

sub msg {

printf STDERR @_;

}

sub dbg {

return if (!$ENV{'ROC_DEBUG'});

msg @_;

}

$0 =~ s@^.*/@@; #ベースネーム

sub usage {

msg "Usage:$0 <interval> <start-time> <iostat-data-file> [dev-list]\n";

msg "\n";

msg "This utility takes a /proc/diskstats output file that contains\n";

msg "output, logged over time, and calculates the rate of change of\n";

msg "the disks in the dataset\n";

msg "OUTPUT_CSV=1 set in env. dumps the full stats to a CSV file on

STDERR\n";

msg "\n";



msg "Example:$0 1hour \"jun 23 12pm\" steeleye-iostat.txt sdg,sdh\n";

msg "\n";

msg "interval - interval between samples\n";

msg "start time - the time when the sampling starts\n";

msg "iostat-data-file - collect this with a cron job like:\n";

msg "\t0 * * * * (date ; cat /proc/diskstats) >> /root/diskstats.txt\n";

msg "dev-list - list of disks you want ROC for (leave blank for all)\n";

exit 1;

}

usage if (@ARGV < 3);

my $interval = TimeHuman($ARGV[0]);

my $starttime = epoch($ARGV[1]);

my $file = $ARGV[2];

my $blksize = 512; # /proc/diskstats はセクタ数

my %devs = map { $_ => 1 } split /,/, $ARGV[3];

my %stat;

my $firsttime;

my $lasttime;

#日付スタンプで出力を除算

my %days = ( 'Sun' => 1, 'Mon' => 1, 'Tue' => 1, 'Wed' => 1,

'Thu' => 1, 'Fri' => 1, 'Sat' => 1);

my %fields = ( 'major' => 0,

'minor' => 1,

'dev' => 2,

'reads' => 3,

'reads_merged' => 4,

'sectors_read' => 5,

'ms_time_reading' => 6,

'writes' => 7,

'writes_merged' => 8,

'sectors_written' => 9,

'ms_time_writing' => 10,

'ios_pending' => 11,

'ms_time_total' => 12,

'weighted_ms_time_total' => 13 );

my $devfield = $fields{'dev'};

my $calcfield = $ENV{'ROC_CALC_FIELD'} || $fields{'sectors_written'};

dbg "using field $calcfield\n";

open(FD, "$file") or die "Cannot open $file:$!\n";



foreach (<FD>) {

chomp;

@_ = split;

if (exists($days{$_[0]})) { #日付スタンプの除算をスキップ

if ($firsttime eq '') {

$firsttime = join ' ', @_[0..5];

}

$lasttime = join ' ', @_[0..5];

next;

}

next if ($_[0] !~ /[0-9]/); #無視

if (!%devs || exists $devs{$_[$devfield]}) {

push @{$stat{$_[$devfield]}}, $_[$calcfield];

}

}

@{$stat{'total'}} = totals(\%stat);

printf "Sample start time:%s\n", scalar(localtime($starttime));

printf "Sample end time:%s\n", scalar(localtime($starttime +

((@{$stat{'total'}} - 1) * $interval)));

printf "Sample interval:%ss #サンプル:%s Sample length:%ss\n", $interval,

(@{$stat{'total'}} - 1), (@{$stat{'total'}} - 1) * $interval;

print "(Raw times from file:$firsttime, $lasttime)\n";

print "Rate of change for devices " .(join ', ', sort keys %stat) ."\n";

foreach (sort keys %stat) {

my @vals = @{$stat{$_}};

my ($max, $maxindex, $roc) = roc($_, $blksize, $interval, @vals);

printf "$_ peak:%sB/s (%sb/s) (@ %s) average:%sB/s (%sb/s)\n",

HumanSize($max), HumanSize($max * 8), scalar localtime($starttime +

($maxindex * $interval)), HumanSize($roc), HumanSize($roc * 8);

}

#関数

sub roc {

my $dev = shift;

my $blksize = shift;

my $interval = shift;

my ($max, $maxindex, $i, $first, $last, $total);

my $prev = -1;

my $first = $_[0];

if ($ENV{'OUTPUT_CSV'}) { print STDERR "$dev," }

foreach (@_) {



if ($prev != -1) {

if ($_ < $prev) {

dbg "wrap detected at $i ($_ < $prev)\n";

$prev = 0;

}

my $this = ($_ - $prev) * $blksize / $interval;

if ($this > $max) {

$max = $this;

$maxindex = $i;

}

if ($ENV{'OUTPUT_CSV'}) { print STDERR "$this," }

}

$prev = $_; #次回用に現在の値を保存

$last = $_;

$i++;

}

if ($ENV{'OUTPUT_CSV'}) { print STDERR "\n" }

return ($max, $maxindex, ($last - $first) * $blksize / ($interval * ($i

- 1)));

}

sub totals { #パラメータ: stat_hash

my $stat = shift;

my @totalvals;

foreach (keys %$stat) {

next if (!defined($stat{$_}));

my @vals = @{$stat{$_}};

my $i;

foreach (@vals) {

$totalvals[$i++] += $_;

}

}

return @totalvals;

}

# KB、MB などの単位に変換し、読みやすいフォームサイズで出力

sub HumanSize { #パラメータ: bytes/bits

my $bytes = shift;

my @suffixes = ( '', 'K', 'M', 'G', 'T', 'P' );

my $i = 0;

while ($bytes / 1024.0 >= 1) {



$bytes /= 1024.0;

$i++;

}

return sprintf("%.1f %s", $bytes, $suffixes[$i]);

}

#人間が理解しやすい時間間隔を秒数に変換

sub TimeHuman { #パラメータ: human_time

my $time = shift;

my %suffixes = ('s' => 1, 'm' => 60, 'h' => 60 * 60, 'd' => 60 * 60 *

24);

$time =~ /^([0-9]*)(.*?)$/;

$time = $1;

my $suffix = (split //, $2)[0]; #添え字を最初の文字にする

if (exists $suffixes{$suffix}) {

$time *= $suffixes{$suffix};

}

return $time;

}

sub epoch { #パラメータ: date

my $date = shift;

my $seconds = `date +'%s' --date "$date" 2>&1`;

if ($?!= 0) {

die "Failed to recognize time stamp:$date\n";

}

return $seconds;

}

使用法 :

# ./roc-calc-diskstats <interval> <start_time> <diskstats-data-

file> [dev-list]

使用例 (概要のみ) :

# ./roc-calc-diskstats 2m “Jul 22 16:04:01” /root/diskstats.txt

sdb1,sdb2,sdc1 > results.txt

この例は、概要 (およびディスク別のピーク I/O情報 )を results.txtにダンプします。

使用例 (概要とグラフデータ) :

# export OUTPUT_CSV=1

# ./roc-calc-diskstats 2m “Jul 22 16:04:01” /root/diskstats.txt

sdb1,sdb2,sdc1 2> results.csv > results.tx


詳細変化率データのグラフ作成

この例は、グラフデータを results.csvに、概要 (およびディスク別のピーク I/O情報 )を results.txtにダンプします。

結果の例 ( results.txt)

Sample start time: Tue Jul 12 23:44:01 2011

Sample end time: Wed Jul 13 23:58:01 2011

Sample interval: 120s #Samples: 727 Sample length: 87240s

(Raw times from file: Tue Jul 12 23:44:01 EST 2011, Wed Jul 13

23:58:01 EST 2011)

Rate of change for devices dm-31, dm-32, dm-33, dm-4, dm-5, total

dm-31 peak:0.0 B/s (0.0 b/s) (@ Tue Jul 12 23:44:01 2011)

average:0.0 B/s (0.0 b/s)

dm-32 peak:398.7 KB/s (3.1 Mb/s) (@ Wed Jul 13 19:28:01 2011)

average:19.5 KB/s (156.2 Kb/s)





dm-5 peak:2.7 MB/s (21.8 Mb/s) (@ Wed Jul 13 10:18:01 2011)

average:293.0 KB/s (2.3 Mb/s)

total peak:2.8 MB/s (22.5 Mb/s) (@ Wed Jul 13 10:18:01 2011)

average:349.8 KB/s (2.7 Mb/s)


お客様に固有の経時的な帯域幅のニーズを分かりやすくするために、テンプレートスプレッドシート

diskstats-template.xlsxが用意されています。このスプレッドシートにはサンプルデータがあり、roc-

calc-diskstatsで収集したデータで上書きできます。

diskstats-template



1. results.csvを開き、 total列を含めてすべての行を選択してください。

2. diskstats-template.xlsxを開き、diskstats.csvワークシートを選択してください。

3. セル1-Aを右クリックし、[Insert Copied Cells]を選択してください。

4. 複製用に割り当てた帯域幅の量を反映するように、ワークシートの左下にあるセルの

bandwidth値を調整してください。

単位 : メガビット /秒 ( Mb/sec)

注記 :その右側にあるセルの値は、収集した生データに合わせて自動的にバイト /秒単

位に変換されます。



5. 以下の行 /列番号を記録してください。

a. Total(下のスクリーンショットでは行 6)

b. Bandwidth(下のスクリーンショットでは行 9)

c. 最終データポイント (下のスクリーンショットでは列 R)

6. bandwidth vs ROCワークシートを選択してください。

7. グラフを右クリックし、[Select Data...]を選択してください。

a. Bandwidth 系列を調整してください。

i. 左の [Series]リストからbandwidthを選択してください。

ii. [Edit]をクリックしてください。

iii. 以下の構文を使用して、[Series Values]フィールドを調整してください。



“=diskstats.csv!$B$<row>:$<final_column>$<row>"

例 : “=diskstats.csv!$B$9:$R:$9"

iv. [OK]をクリックしてください。

b. ROC 系列を調整してください。

i. 左の [Series]リストからROCを選択してください。

ii. [Edit]をクリックしてください。

iii. 以下の構文を使用して、[Series Values]フィールドを調整してください。

“=diskstats.csv!$B$<row>:$<final_

column>$<row>"

例 : “=diskstats.csv!$B$6:$R:$6"



iv. [OK]をクリックしてください。

c. [OK]をクリックしてウィザードを終了してください。

8. Bandwidth vs ROCのグラフが更新されます。結果を解析して、データの複製をサポートするた

めに十分な帯域幅があるかどうかを判断してください。

[Confirm Failover] と [Block Resource Failover] の設定

以下の説明、例、および考慮事項をよく読んで理解してから、お使いのLifeKeeper環境で [ConfirmFailover]または [Block Resource Failover]を設定してください。これらの設定は、コマンドライン、ま

たは LifeKeeper のGUI の [Properties]パネルから使用できます。

[Confirm Failover On]定義 -システムAからシステムBへのフェイルオーバの手動確認を有効にします(ここで、システムAは

プロパティが [Properties]パネルに表示されるサーバで、システムBはチェックボックスの左にあるシステ

ム)。あるシステムでこのオプションをオンに設定した場合、障害発生が検出されたシステムについて

LifeKeeperがフェイルオーバリカバリを実行するにはシステム管理者による手動確認が必要になりま

す。

フェイルオーバを確認するには、lk_confirmso コマンドを使用します。デフォルトでは、このコマンドを

実行するまで管理者には 10分の猶予時間があります。この時間は、 /etc/default/LifeKeeperのCONFIRMSOTO設定で変更できます。管理者が10分以内に lk_confirmso コマンドを実行し

ない場合、フェイルオーバは続行されるか、ブロックされます。デフォルトでは、フェイルオーバが続行され

ます。この動作は、 /etc/default/LifeKeeperのCOMFIRMSODEF設定で変更できます。

例 :自動フェイルオーバをすべてブロックする場合は、[Properties]パネルの [Confirm Failover On]オプションを設定し、さらにCONFIRMSODEFを 1(フェイルオーバをブロック)、CONFIRMSOTOを 0(フェ

イルオーバ動作が決定されるまで待機しない)に設定してください。

この設定を選択する時期 :

この設定は、構成に冗長ハートビートコミュニケーションパスを含まない多くのディザスタリカバ

リ、XenServer、その他のWAN構成で使用されます。


[Block Resource Failover On]

通常のサイト (非マルチサイトクラスタおよび非XenServer)では、あるサーバで [Properties]ページを開

き、[Confirm Failover flag]フラグをオンに設定するサーバを選択してください。

マルチサイト WANの構成の場合 :フェイルオーバの手動確認を有効にしてください。

マルチサイト LANの構成の場合 :フェイルオーバの手動確認を有効にしないでください。

マルチサイトクラスタ環境では、非ディザスタシステムからDRシステムを選択し、 [Set Confirm FailoverOn]チェックボックスをオンにします。クラスタ内の非ディザスタサーバのそれぞれについて、[Properties]パネルを開いてこの設定を選択する必要があります。

XenServer環境では、リスト内のすべてのサーバ( DRサイトのみでなく)のチェックボックスをオンにする必


[Block Resource Failover On]定義 -デフォルトでは、リソースのすべての障害についてリカバリイベントが発生し、ローカルシステムの障

害リソースのリカバリが試行されます。ローカルリカバリが失敗した場合、または有効になっていない場

合は、リソースが定義されている、優先順位が次に最も高いシステムに、LifeKeeperがリソース階層を

転送します。ただし、宛先として指定したシステムでこの設定を選択している場合、リソース障害に起

因するリソースの転送はすべてブロックされます。

この設定が有効の場合、以下のメッセージがログに記録されます。

Local recovery failure, failover blocked, MANUAL INTERVENTION REQUIRED

条件 / 考慮事項 :

マルチサイト構成では、構成内のすべてのサーバについて、フェイルオーバのブロックを選択しないでくだ

さい。

XenServer環境では、クラスタ内の各システムについて、フェイルオーバのブロックを選択してください。

注記 : この設定は、システム全体の障害が発生した場合のフェイルオーバ動作には影響しません。

ローカルリソースの障害に起因するフェイルオーバのみをブロックします。

各サーバのフラグの設定

1. LifeKeeperのGUIにログインし、クラスタ内のサーバを選択してください。[View]メニューで

[Properties]パネルのオプションを選択した場合は、[Properties]パネルが表示されます( GUIの右端 )。

パネルの下部にある [General]タブに、システム構成が表示されます。


SteelEye DataKeeper for Linuxのリソースタイプ

2. [Set Confirm Failover On]列で、クラスタ内のその他の各サーバのチェックボックスをオンにしてく

ださい。

3. [Set Block Resource Failover On]列で、必要に応じてクラスタ内の各サーバのチェックボック

スをオンにしてください。

マルチサイトクラスタ構成での重要な考慮事項 :マルチサイトクラスタ構成のサーバについて

は、[Set Block Resource Failover On]列のチェックボックスをオンにしないでください。


SteelEye DataKeeper for Linux のリソースタイプ

DataKeeperリソース階層を作成するときに、リソースタイプを選択するように LifeKeeperから要求されま

す。DataKeeperリソースには、いくつかのタイプがあります。お使いの環境に最適なタイプを選択すると

きに、以下の情報が役立ちます。

Replicate New File SystemReplicate New File Systemを選択すると、NetRAIDデバイスが作成 /拡張され、NetRAIDデバイスに

指定のマウントポイントがマウントされます。また、LifeKeeperがサポートするファイルシステムとNetRAIDデバイスの両方が、LifeKeeperで保護されます。ローカルのディスクまたはパーティションがフォーマットされ

ます。注意 :データがすべて削除されます。

Replicate Existing File SystemReplicate Existing File Systemを選択すると、現在マウントされているディスクまたはパーティションが使

用され、ディスクまたはパーティションのデータが削除されることなくNetRAIDデバイスが作成されま

す。SteelEye DataKeeperはローカルのディスクまたはパーティションをアンマウントし、ローカルのディスクま

たはパーティションを使用して NetRAIDデバイスを作成します。そして、NetRAIDデバイスにマウントポ

イントをマウントします。次に、NetRAIDデバイスとLifeKeeperがサポートするファイルシステムの両方を

LifeKeeperで保護します。


DataKeeper Resource

重要 :SteelEye Protection Suite for Linuxのマルチサイトクラスタ階層を作成する場合、作成プロセス

中にアプリケーションが停止します。階層の作成と拡張が完了した後、アプリケーションを再起動する


DataKeeper ResourceDataKeeperリソースを選択すると、NetRAIDデバイスが作成 /拡張され、ファイルシステムは含めずに

LifeKeeperで保護されます。RAW I/Oデバイスを使用できるデータベースを使用している場合は、この

複製タイプを選択できます。

ユーザがデータアクセスを続行できるように、SteelEye DataKeeperは、現在マウントされている

NetRAIDデバイスのアンマウントと削除は実行しません。ユーザは、手動スイッチオーバの前に

NetRAIDデバイスを手動でアンマウントし、手動スイッチオーバの後に他のサーバにマウントする必要が

あります。

注記 : DataKeeperリソースの作成後に、手動マウントしたファイルシステムを LifeKeeperで保護する場

合は、以下の操作を行います。

1. LifeKeeperがサポートするファイルシステムで、NetRAIDデバイスをフォーマットしてください。

2. NetRAIDデバイスをマウントしてください。

3. NetRAIDデバイスを使用して、共有ストレージのディスクまたはパーティションにあるかのようにファ

イルシステムの階層を作成し、拡張してください。

これで、LifeKeeperのファイルシステムリカバリキットが、フェイルオーバ時のファイルシステムのマウント /アンマウントを実行します。

リソースの設定作業

SteelEye DataKeeperの設定作業はすべて、LifeKeeperのグラフィカルユーザインターフェース( GUI)から実行できます。LifeKeeperのGUIでは、SteelEye DataKeeperのリソースの設定、管理、監視の作

業をガイド付きで行うことができます。

概要

SteelEye DataKeeperの設定に関して、以下の作業を行うことができます。

l Create a Resource Hierarchy - DataKeeperリソース階層を作成します。

l Delete a Resource Hierarchy - DataKeeperリソース階層を削除します。

l Extend a Resource Hierarchy - DataKeeperリソース階層をプライマリサーバからバックアップ


l Unextend a Resource Hierarchy - LifeKeeperクラスタ内にある 1台のサーバのDataKeeperリソース階層を拡張解除 (削除 )します。

l Create Dependency -既存のリソース階層と別のリソースインスタンスとの間に子の依存関係を

作成し、クラスタ内のすべての対象サーバに依存関係の変更を伝播します。

l Delete Dependency -リソースの依存関係を削除して、クラスタ内にあるすべての対象サーバに


DataKeeperリソース階層の作成

依存関係の変更を伝播します。

l In Service -リソース階層をアクティブにします。

l Out of Service -リソース階層を非アクティブにします。

l View/Edit Properties -リソース階層のプロパティの表示または編集を行います。

DataKeeper リソース階層の作成

マルチサイトクラスタにDataKeeperリソース階層を作成する場合は、[Hierarchy Type]を選択した

後、このセクションの最後にある手順を参照してください。

プライマリサーバで以下の操作を行ってください。

1. [Edit] > [Server] > [Create Resource Hierarchy]を選択してください。

[Create Resource Wizard]ダイアログボックスが表示されます。

2. ドロップダウンリストから [Data Replication]オプションを選択し、[Next]をクリックして続行してく

ださい。

3. 以下の情報を入力するように要求されます。ダイアログボックスで [Back]ボタンが有効な場合

は、前のダイアログボックスに戻ることができます。これは、エラーが発生して、前に入力した情報

を修正する必要がある場合に便利な機能です。いつでも [Cancel]をクリックして、作成処理

全体を取り消すことができます。

フィールドヒント

SwitchbackType

[intelligent switchback]を指定する必要があります。これは、バックアップサー

バにフェイルオーバした後、管理者が手動で DataKeeperリソースをプライマリ

サーバにスイッチバックする必要があることを意味します。

注意 : このリリースのSteelEye DataKeeperは、DataKeeperリソースの自動ス

イッチバックをサポートしていません。さらに、自動スイッチバックの制限

は、DataKeeperリソースの上に存在する他のLifeKeeperリソースにも適用さ

れます。

Server作成するNetRAIDデバイスが存在するサーバ(通常はプライマリサーバ)の名

前を選択してください。ドロップダウンリストボックスには、クラスタ内のすべての

サーバが表示されます。

HierarchyType

以下のいずれかを選択して、作成するデータレプリケーションのタイプを選択し

てください。

l Replicate New File System

l Replicate Existing File System

l DataKeeper Resource




Bitmap Fileインテントログの記録に使用するビットマップファイルの名前を選択するか、入力

してください。[None]を選択すると、インテントログは使用されず、すべての再

同期が部分的ではなく全体の再同期になります。

EnableAsynchronousReplication ?

このレプリケーションリソースによるターゲットシステムへの非同期レプリケーション

のサポートを許可するには、[Yes]を選択してください。すべてのターゲットにつ

いて同期レプリケーションを使用する場合は、[No]を選択してください。後で、

レプリケーションリソースが各ターゲットサーバに拡張されるときに、実際のレプリ

ケーションタイプ(同期または非同期 )を選択するように要求されます(両方の

レプリケーションタイプの詳細については、SteelEye DataKeeperでのミラーリン

グを参照してください)。これらすべてのターゲットへのレプリケーションを非同期

で実行する場合は、他のターゲットへのレプリケーションを同期実行する場合

でもここでは [Yes]を選択する必要があります。

以降の一連のダイアログボックスは、[Hierarchy Type]で選択した項目によって異なります。一

部のダイアログボックスはすべての階層タイプで同じですが、表示される順序と必要な情報が少

し異なることがあります。以下の3つのトピックで、階層作成の残りのプロセスについて説明して

います。





この操作は [Edit]メニューから開始できます。または [Create Resource Hierarchy]オプションの動作

が完了すると自動的に開始されます。その場合は、手順 2を参照してください。

1. [Edit]メニューの [Resource]から [Extend Resource Hierarchy]を選択します。Pre-ExtendWizardが表示されます。拡張操作に慣れていない場合は、[Next]をクリックしてくださ

い。LifeKeeperの [Extend Resource Hierarchy]のデフォルト値が分かっていて、入力と確認

を省略する場合は [Accept Defaults]をクリックしてください。

2. Pre-Extend Wizardに以下の情報を入力します。

注記 :最初の2つのフィールドは [Edit]メニューから拡張を開始した場合にのみ表示されます。


TemplateServer

現在 In ServiceのDataKeeperリソース階層が存在するテンプレートサーバを選

択してください。ここで選択するテンプレートサーバと次のダイアログボックスで選択

する拡張するタグによって、 In Service (アクティブ)のリソース階層が表されることを

理解しておくことが重要です。

選択したテンプレートサーバで In Serviceでないリソースタグを選択した場合、エ

ラーメッセージが表示されます。このダイアログのドロップダウンボックスには、クラスタ

内にある全サーバの名前が表示されます。


DataKeeperリソース階層の拡張


Tag toExtend

これは、テンプレートサーバからターゲットサーバに拡張するDataKeeperインスタン

スの名前です。ドロップダウンボックスには、テンプレートサーバ上に作成したすべて

のリソースが表示されます。

TargetServer 拡張先のサーバを入力するか、選択してください。

SwitchbackType

[intelligent switchback]を指定する必要があります。これは、バックアップサーバに

フェイルオーバした後、管理者が手動で DataKeeperリソースをプライマリサーバに

スイッチバックする必要があることを意味します。

注意 : このリリースのSteelEye DataKeeperは、DataKeeperリソースの自動スイッ

チバックをサポートしていません。さらに、自動スイッチバックの制限は、SteelEyeDataKeeperリソースの上に存在する他のLifeKeeperリソースにも適用されます。

TemplatePriority

テンプレートの優先順位を選択するか、入力してください。これはサーバで現在 InServiceのDataKeeper階層の優先順位です。1～ 999の範囲で、まだ優先順

位として使用されていない値が有効で、小さい数字ほど優先順位が高くなりま

す(数値 1が最高の優先順位 )。拡張処理時に、別のシステムですでに使用中

の優先順位をこの階層に対して指定することはできません。デフォルト値をが推

奨されます。

注記 : このフィールドは、階層をはじめて拡張するときにだけ表示されます。

TargetPriority

ターゲットの優先順位を選択するか、入力してください。これは、他のサーバにあ

る同等の階層に対する、新しく拡張するDataKeeper階層の優先順位です。1～ 999の範囲で、まだ優先順位として使用されていない値が有効で、リソース

のカスケーディングフェイルオーバシーケンスにおけるサーバの優先順位を示しま

す。数値が小さいほど優先順位は高くなります(数値 1が最高の優先順

位 )。LifeKeeperのデフォルトでは、階層が作成されたサーバに「1」が割り当てら

れることに注意してください。優先順位は連続している必要はありませんが、特

定のリソースについて 2つのサーバに同じ優先順位を割り当てることはできませ

ん。

拡張前のチェックが正常に終了したというメッセージが表示されたら、 [Next]をクリックしてくださ

い。

拡張する階層に応じて、拡張されるリソースタグ(一部編集不可 )を示す一連の情報ボックス


3. [Next]をクリックして、[Extend Resource Hierarchy]の構成タスクを開始してください。

4. 次のセクションには、別のサーバにDataKeeperリソースを拡張するために必要な手順を示しま

す。

DataKeeper リソース階層の拡張

1. pre-extendスクリプトが正常に実行されたというメッセージが表示されたら、以下の情報を指定

するように要求されます。




Mount Pointターゲットサーバ上にあるファイルシステムマウントポイントを入力してくださ

い( DataKeeperリソースに関連する、LifeKeeperが保護するファイルシステムがな

い場合は、このダイアログは表示されません)。

Root Tag

ルートタグを選択するか、入力してください。これは、ターゲットサーバ上にあるファ

イルシステムリソースインスタンスの一意の名前です( DataKeeperリソースに関連

する、LifeKeeperが保護するファイルシステムがない場合は、このダイアログは表

示されません)。

Target Diskor Partition

複製するファイルシステムの配置先となる、ターゲットサーバ上のディスクまたは

パーティションを選択してください。

ドロップダウンボックスのディスクまたはパーティションのリストには、以下のものを除

いて、使用できるすべてのディスクが表示されます。

l すでにマウント済みのものl スワップディスクまたはスワップパーティションl LifeKeeperが保護するディスクまたはパーティション

ドロップダウンリストには、root (/)、boot (/boot)、 /proc, floppy、cdromなどの特殊

なディスクまたはパーティションも表示されません。

注記 : ターゲットのディスクまたはパーティションは、ソースのディスクまたはパーティシ

ョン以上のサイズである必要があります。

DataKeeperResourceTag

DataKeeperリソースタグの名前を選択するか、入力してください。

Bitmap Fileインテントログの記録に使用するビットマップファイルの名前を選択するか入力して

ください。 [None]を選択すると、インテントログは使用されず、すべての再同期が

部分的ではなく全体の再同期になります。

ReplicationPath

ターゲットサーバとクラスタ内の他の指定サーバとの間で複製に使用する、ローカ

ルとリモートの IPアドレスのペアを選択してください。有効なパスおよび対応する

IPアドレスは、このサーバのペアに対して指定した LifeKeeperコミュニケーションパ

スのセットから得られます。DataKeeperの特性により、プライベート (専用 )ネット

ワークを使用することが強く推奨されます。

DataKeeperリソースをすでに 1台以上のターゲットサーバに拡張している場合、

追加のサーバに対する拡張を実行すると、新しいターゲットサーバと既存のサーバ

との組み合わせのそれぞれについて、繰り返し複製パスを指定するように要求さ

れます。

ReplicationType

指定したサーバのペアについて使用する複製タイプとして、 [synchronous]または

[asynchronous]を選択してください。

前述の [Replication Path] フィールドと同様に、DataKeeperリソースをすでに 1台以上のターゲットサーバに拡張している場合、追加のサーバに対する拡張を実

行すると、新しいターゲットサーバと既存のサーバとの組み合わせのそれぞれについ

て、繰り返し複製タイプを指定するように要求されます。


リソース階層の拡張解除

2. [Extend]をクリックして次に進んでください。拡張が実行中であることを確認する情報ボックスが

表示されます。

3. [Finish]をクリックして、DataKeeperリソースインスタンスが正常に拡張されたことを確認してくだ

さい。

4. [Done]をクリックして、[Extend Resources Hierarchy]メニューを終了してください。

注記 : 必ずすべてのサーバでスイッチオーバを手動実行して、新しいインスタンスの機能をテス

トしてください。詳細については、リソース階層のテストを参照してください。この時点

で、SteelEye DataKeeperがソースからターゲットのディスクまたはパーティションにデータの再同期

を開始しています。LifeKeeperのGUIでは、ターゲットサーバにあるDataKeeperリソースのス

テータスは「Resyncing」になります。再同期が完了すると、ステータスは「Target」になります。こ

れは通常のスタンバイ状態です。

再同期中、DataKeeperリソース、およびそれに依存するリソースはフェイルオーバできません。こ

れは、データの破損を防止するためです。

リソース階層の拡張解除

LifeKeeperクラスタ内にある 1台のサーバからリソース階層を削除するには、次の手順を実行します。

1. [Edit]メニューの [Resource]から [Unextend Resource Hierarchy]を選択してください。

2. DataKeeperリソースを拡張解除するターゲットサーバを選択してください。DataKeeperリソース

が現在 In Service (アクティブ)のサーバは選択できません。

注記 :右側のペインから個々のリソースインスタンスを右クリックして [Unextend]作業を選択し

た場合、このダイアログボックスは表示されません。

[Next]をクリックしてください。

3. 拡張解除する DataKeeper 階層を選択し、[Next]をクリックしてください(このダイアログは、い

ずれかのペインでリソースインスタンスを右クリックして、[Unextend]を選択した場合には表示さ

れません)。

4. 選択したターゲットサーバとDataKeeperリソース階層の拡張解除を確認する情報ボックスが表

示されます。[Unextend]をクリックしてください。

5. DataKeeperリソースが正常に拡張解除されたことを確認する別の情報ボックスが表示されま

す。[Done]をクリックして、[Unextend Resource Hierarchy]メニューを終了してください。

注記 : これで、データがバックアップサーバにレプリケーションされなくなります。

リソース階層の削除

LifeKeeper構成内のすべてのサーバからDataKeeperリソースを削除するには、次の手順を実行してく

ださい。

注記 : DataKeeperリソースは、削除する前にOut of Serviceにすることが推奨されます。 Out ofServiceにしない場合、md とNetRAID のデバイスが削除されず、ファイルシステムを手動でアンマウン

トする必要があります。DataKeeperリソースをOut of Serviceにするを参照してください。


DataKeeperリソースをOut of Serviceにする

1. [Edit]メニューの [Resource]から [Delete Resource Hierarchy]を選択してください。

2. 削除するDataKeeperリソース階層が存在するターゲットサーバの名前を選択してください。

注記 :左側ペインのグローバルリソースまたは右側ペインの個々のリソースインスタンスを右クリッ

クして [Delete Resource]作業を選択した場合、このダイアログボックスは表示されません。

3. [Hierarchy to Delete]を選択してください(左右のペインのリソースインスタンスを右クリックして

[Delete Resource]作業を選択した場合、このダイアログは表示されません) [Next]をクリックし

てください。

4. 選択したターゲットサーバと、削除の対象として選択した階層を確認する情報ボックスが表示さ

れます。[Delete]をクリックしてください。

5. DataKeeperリソースが正常に削除されたことを確認する別の情報ボックスが表示されま

す。[Done]をクリックして終了してください。

注記 : リソースを削除する前にマウントされた状態のNetRAIDデバイスは、マウントされたまま残りま

す。それ以外のNetRAIDデバイスは削除されます。

DataKeeper リソースを Out of Service にする

DataKeeperリソースをOut of Serviceにすると、LifeKeeperによるリソースの保護が解除されます。ミ

ラーが解除され、ファイルシステムがアンマウントされます(該当する場合 )。md デバイスが停止し、nbdサーバとクライアントが強制終了されます。

警告 :データのミラーリングを停止して LifeKeeperの保護を解除する場合以外は、DataKeeperリソー

スをOut of Serviceにしないでください。一時停止の操作を使用して、ミラーリングを一時停止してくだ

さい。

1. LifeKeeperのGUIの右側ペインにある、 In ServiceのDataKeeper リソースを右クリックしてくだ

さい。

2. リソースのポップアップメニューの [Out of Service]をクリックしてください。

3. 選択したリソースがOut of Serviceになることを示すダイアログボックスが表示されます。この操作

に関連するリソースの依存関係がダイアログに表示されます。[Next]をクリックしてください。

4. 情報ボックスに、 Out of Serviceにするリソースの結果が表示されます。[Done]をクリックしてくだ

さい。

DataKeeper リソースを In Service にする

DataKeeperリソースを In Serviceにする操作は、リソースの作成と似ています。LifeKeeperは nbdサー

バとクライアントを起動し、ソースとターゲットのデバイス間でデータを同期するmdデバイスを起動して、

ファイルシステムをマウントします(該当する場合 )。

1. 右側のペインにあるDataKeeper リソースインスタンスを右クリックしてください。

2. ポップアップメニューの [In Service]をクリックしてください。選択したサーバとリソースを In Serviceにすることを確認するダイアログボックスが表示されます。[In Service]をクリックしてリソースを InServiceにしてください。


リソース階層のテスト

3. 情報ボックスに、 In Serviceにするりソースの結果が表示されます。この操作に関連するリソース

の依存関係が確認ダイアログに表示されます。[Done]をクリックしてください。

リソース階層のテスト

手動スイッチオーバを開始することによって、DataKeeperリソース階層をテストできます。このテストは、プ

ライマリサーバからバックアップサーバへのリソースインスタンスのフェイルオーバをシミュレートします。

LifeKeeperのGUIからの手動スイッチオーバの実行

手動スイッチオーバを開始するには、LifeKeeperのGUIで [Edit] > [Resource] > [In Service]を選択

します。例えば、バックアップサーバで In Serviceリクエストが実行されると、DataKeeperリソース階層が

バックアップサーバ側で In Serviceになり、プライマリサーバ側ではOut of Serviceになります。この時点

で、元のバックアップサーバがプライマリサーバに、元のプライマリサーバがバックアップサーバになります。

スイッチオーバ後、LifeKeeperのGUIでは、ターゲットサーバにあるDataKeeperリソースのステータス

が「Resyncing」(再同期中 )になります。再同期が完了すると、ステータスは「Target」になります。これ

は通常のスタンバイ状態です。

注記 :再同期中は、DataKeeperリソースの手動フェイルオーバはできません。

[Out of Service]要求を実行した場合、リソース階層は他のサーバで In Serviceにならずに、Out ofServiceになります。リソースを同じサーバ上で In Serviceに戻すことができるのは、再同期中にリソース

がOut of Serviceになった場合のみです。


管理

SteelEye DataKeeper for Linuxの管理

以下のトピックには、リソースを作成した後のSteelEye DataKeeper for Linuxの動作と問題を理解し、

管理するのに役立つ情報があります。

ミラーのステータスの表示

[Replication Status]ダイアログには、ミラーに関する以下の情報が表示されます。

l Mirror status:Fully Operational(フルに動作可能 )、Paused(一時停止 )、Resyncing(再同

期中 )、またはOut Of Sync(非同期 )

l Synchronization status:同期が完了した割合

l Replication type: synchronous(同期 )または asynchronous(非同期 )

l Replication direction: ソースサーバからターゲットサーバに

l Bitmap:ビットマップ / インテントログの状態

l Rewind Log: リワインドログの場所とサイズ(有効の場合 )

l Network Compression Level:圧縮レベル(有効の場合 )

[Replication Status]ダイアログを表示するには、次の手順に従います。

1. [View]メニューをクリックし、[Properties Panel]を選択します。

2. [LifeKeeper status]表示にあるDataKeeper リソースをクリックします。

または

1. [LifeKeeper status]表示にあるDataKeeper リソースを右クリックします。

2. ポップアップメニューから [Properties] を選択します。


GUIからのミラーの管理

GUI からのミラーの管理

SteelEye DataKeeperのミラーは、LifeKeeperのGUIから以下の2とおりの方法で実行できます。

1. [Properties Panel] を有効にし、ツールバーのアイコン(スクリーンショットを参照 )をクリックしま

す。

316 管理

リワインドブックマークの作成と表示

/Linux/7.5/LK4L/SAPSolution/docmap.html

以下の1ファイルで使用 :

/alllinux.php

説明を表示するには、それぞれのアイコンをクリックしてください。

または

2. DataReplication リソースを右クリックし、ポップアップメニューから動作を選択します。

リワインドブックマークの作成と表示


ミラーを強制的にオンラインにする

ブックマークとは、リワインドログファイル内に配置されるエントリです。リワインドの実行が必要な場合

に、ブックマークは重要なシステムイベント (アップグレードなど)の追跡に役立ちます。リワインドの実行

時に、ブックマークの付いたログエントリがすべて、リワインド位置の選択肢として表示されます。

ミラーを強制的にオンラインにする

[Force Mirror Online]は、両方のサーバが動作不能になり、かつプライマリサーバの再起動後にリ

ソースを In Serviceにできない場合にのみ使用してください。[Force Mirror Online]を選択する

と、data_corrupt フラグが削除され、DataKeeperリソースが In Serviceになります。詳細については、ト

ラブルシューティングセクションの「プライマリサーバがリソースを ISPにできない」を参照してください。

注記 : Mirror_settingsはターゲットシステム(ミラーのソースになるシステムには無関係に設定を有効に

する場合はすべてのシステム)で実行する必要があります。設定の変更内容を有効にするには、ミラー

を一時停止してから再起動する必要があります。

一時停止と再開

ミラーの一時停止

ミラーの再開

ミラーを一時停止して、すべての書き込みをターゲットディスクに複製する動作を一時的に停止できま

す。例えば、ミラーを一時停止して、ターゲットディスクのスナップショットを収集することも、トラフィックの

ピーク時にソースシステムの I/Oパフォーマンスを向上させることもできます。

ミラーを一時停止すると、ミラーは、ターゲットシステムの通常のファイルシステムのマウントポイントに読

み取りアクセスするように(カーネル2.6.19以降は読み取り /書き込みアクセス)マウントされます。ミラー

の一時停止中にターゲットに書き込まれたデータはすべて、ミラーの再開時に上書きされます。

データのリワインドと復旧

318 管理


リワインド機能を使用すると、ターゲットディスクのデータを以前の任意のディスク書き込みに戻すことが

できます。

手順は以下のとおりです。

1. ミラーを一時停止します。

2. 以前のディスク書き込みに対応するタイムスタンプを選択し、ディスクがその時点までリワインドさ

れます。

3. リワインドしたデータを確認し、その状態 (良好または不良 )を指定するように要求されます。

4. その後、ユーザは、現在のデータを使用することも(手順 5に移動 )、別のタイムスタンプを選択

してリワインドを続行することも(手順 2に移動 )できます。

5. ユーザは、データを手動で復旧してからミラーを再開 (リワインドしたデータを消去 )することも、ミ

ラーと任意の保護されたアプリケーションをターゲットシステムに切り替えて、リワインドしたデータ

を新規の実稼働データとして使用することもできます。

上記の手順が、一連のウィザードのダイアログとして表示されます。ダイアログを以下に示します。

1. データのリワインドを確定してください。[Continue]をクリックしてください。

2. ミラーがリワインドの準備をするために一時停止します。[Next]をクリックしてください。

3. リワインドする時点のタイムスタンプを選択するか、入力してください。ブックマーク付きのログエン

トリ、および他のログエントリのランダムサンプリングがドロップダウンリストに表示されます。ダイアロ

グ下部の進行状況バーに、良好のデータ(緑 )、不良のデータ(赤 )、不明のデータ(黄 )が表示

されます。したがって、リワインドプロセスの開始時には、進行状況バーはすべて黄で表示されま

す。データがリワインドされ、ユーザがデータの良好、不良を指定すると、それに合わせて進行状

況バーが緑と赤のセクションで更新されます。



ダイアログ 3

4. データのリワインド中です。データのリワインド後、データを検証できるようにターゲットディスクが読

み取り専用アクセス用にマウントされます。[Next]をクリックしてください。

320 管理


ダイアログ 4

5. データのコメントを入力するように要求されます。コメントを入力し(任意 )、[Next]をクリックしてく

ださい。

6. 次に、データが有効かどうかを指定するように要求されます。[Yes]または [No]をクリック

し、[Next]をクリックしてください。

7. 次に、リワインドを続行するか(ダイアログ3に戻る)、現在のリワインドされたデータを使用してリ

カバリを開始するか(ダイアログ8に進む)を尋ねられます。

8. リカバリ方法を選択するように要求されます。選択肢は以下のとおりです。

a. アプリケーションを<ターゲットシステム>に移動する(ダイアログ9に進む)

b. ソースシステムにデータを手動コピーする(ダイアログ10に進む)

c. 項目を選択し、[Next]をクリックしてください。

9. ターゲットサーバに階層がスイッチオーバされます。リワインドされたデータが、古いソースディスクと

再同期されます。[Finish]をクリックしてください。リワインドが完了しました。

10. ソースシステムにファイルを手動でコピーするように要求されます。保持するリワインドデータを安

全な場所にコピーし、[Next]をクリックしてください。


圧縮レベルの設定

11. ミラーが再開されます。ソースからターゲットへの全体の再同期が実行されます。[Finish]をクリッ

クしてください。リワインドが完了しました。

圧縮レベルの設定

ネットワークの圧縮レベルは、0～ 9の値に設定できます。値 0は、圧縮を無効にします。レベル1は最も高速で圧縮率が最も低いレベルです。一方、レベル9は最も低速ですが圧縮率が最高です。ネ

ットワーク圧縮は通常、WAN環境で利用することによって効果を発揮します。

リワインドログの場所の設定

リワインドログファイルの保存場所を選択します(システムがミラーのターゲットである場合のみ)。必要と

するログ履歴1の量を保存するために、この場所には十分な容量が必要です。ログはミラーまたは共有

ディスクに置くことができません。最大のパフォーマンスを発揮するには、ミラーとは別の物理ディスクに置

いてください。空の設定は、リワインドログを無効にします。

注記 :設定の変更内容を有効にするには、ミラーを一時停止してから再起動する必要があります。

1ログファイルはミラーディスクに書き込まれる各ディスクブロックのコピーを持つため、同一のディスクブロッ

クを複数回書き込んだ場合やファイルを変更したりファイルの最後に内容を付け加えたりした場合、ロ

グファイルがミラーディスク自体よりも大きなサイズになる可能性があります。

リワインドログの最大サイズの設定

ログファイルの最大サイズをMB単位で入力してください。空の値、または値 0は、ファイルサイズの制

限を無効にします。最大サイズまで増大するログファイルを保存するために、ログファイルディスクには十

分な容量が必要です。ただし、ディスク容量が不足したことが検出された場合、ログが折り返され、最

も古いエントリが上書きされます。

コマンドラインからのミラー管理

ミラーの管理は、LifeKeeperのGUIからの操作だけでなく、コマンドラインからも実行できま

322 管理

ミラーの操作

す。DataKeeperのリソースの管理に使用できるコマンドがいくつかあります( $LKROOT/binディレクトリを

参照 )。

ミラーの操作

mirror_action <tag> <action> <source> [target(s)]

<tag> DataKeeperリソースを表すLifeKeeperのソースタグ

<action> pause、resume、 force、 fullresyncのいずれか

<source> 現在のソースシステム

<target>操作対象のターゲットシステム(またはシステムのリスト )

例 :

ソースシステムadamからターゲットシステムeveへのミラー(名前 : datarep-ext3)を一時停止す

る。

mirror_action datarep-ext3 pause adam eve

adamから eveとsophoclesの両方のシステムへの複製を再開する。

mirror_action datarep-ext3 resume adam eve sophocles

システムeveへのオンラインミラーリングを強制実行する。

mirror_action datarep-ext3 force eve

adamから sophoclesへの複製を再開し、これらのシステム間で全体の再同期を強制実行す

る。

mirror_action datarep-ext3 fullresync adam sophocles

ミラーの設定

mirror_settings <tag> <setting> <value>

<tag> DataKeeperリソースを表すLifeKeeperのソースタグ

<setting> logdir、 logmax、compressのいずれか

<value>設定する値

注記 : mirror_settingsはターゲットシステム(ミラーのソースになるシステムには無関係に設定を

有効にする場合はすべてのシステム)で実行する必要があります。設定の変更内容を有効に

するには、ミラーを一時停止してから再起動する必要があります。

例 :

ネットワーク圧縮のレベルを 5に設定する。

mirror_settings datarep-ext3 compress 5


ビットマップの管理

ネットワーク圧縮を無効にする。

mirror_settings datarep-ext3 compress 0

リワインドログのディレクトリを設定する(そしてリワインドログを有効にする)。

mirror_settings datarep-ext3 logdir /tmp/logs

リワインドログを無効にする。

mirror_settings datarep-ext3 logdir “”

リワインドログの最大サイズを 1GBに設定する。

mirror_settings datarep-ext3 logmax 1073741824

リワインドログの最大サイズの制限を無効にする。

mirror_settings datarep-ext3 logmax 0

ビットマップの管理

bitmap -a <num>|-c|-d|-X <bitmap_file>

-a <num> ビットマップファイルに非同期書き込みのパラメータを追加します。同期ミラー

のアップグレードにより非同期ターゲットを含むようになった場合、これは必須で

す。<num>のデフォルト値は 256です。

-c ビットマップファイルをクリーニングします(すべてのビットを 0に設定 )。ソースディスクの

余分な複製がターゲットに存在する場合、これを使用することで全体の再同期を回避

できます。、このオプションは、特に注意して使用してください。

-d ビットマップファイルをダーティに設定します(すべてのビットを 1に設定 )。例えば制御

分離の状況が発生した後などに、このオプションを使用して全体の再同期を強制実行

できます。

-X<bitmap file>ビットマップファイルを調べて、ビットマップとミラーに関する有用な情

報を表示します。

さらに、mdadm コマンドを使用して、DataKeeperのリソースを管理できます。これは、DataKeeperのリ

ソースが実際にはmdデバイスに存在するためです。詳細については、mdadm(8)のマニュアルページを

参照してください。注記 : mdadmを使用するときには、オペレーティングシステムに含まれているバージョ

ンよりも新しい、$LKROOT/bin内のバージョンを必ず使用してください。

コマンドラインからのミラーステータスの監視

通常、ミラーステータスは、LifeKeeperのGUIから、[Resource Properties]ダイアログの [ReplicationStatus]を使用して確認できます。ただし、以下の操作でもミラーのステータスを監視できます。

$LKROOT/bin/mirror_status <tag>

例:# mirror_status datarep-ext3-sdr

324 管理

サーバの障害

[-] eve -> adam

Status: Paused

Type: Asynchronous

[-] eve -> sophocles

Status: Resynchronizing

[=> ] 11%

Resync Speed: 1573K/sec

Type: Synchronous

Bitmap: 4895 bits (chunks), 4895 dirty (100.0%)

以下のコマンドも役に立つことがあります。

cat /proc/mdstat

サンプルのmdstat ファイルを示します。

eve:~ # cat /proc/mdstat

Personalities : [raid1]

md1 : active raid1 nbd10[1] nbd8[3](F) sdb1[0]

313236 blocks super non-persistent [3/2] [UU_]

bitmap: 3/3 pages [12KB], 64KB chunk, file:

/opt/LifeKeeper/bitmap_ext3-sdr

unused devices: <none/></tag>

サーバの障害

プライマリサーバとバックアップサーバの両方が動作不能になった場合、DataKeeperリソースは、両方の

サーバが再び動作可能になった場合にのみ In Service /アクティブになります。これは、間違った方向へ

の再同期に起因するデータの破損を防ぐためです。動作可能なサーバが、リソースが「 In ServiceProtected」(ISP)である最後のサーバであることが確実に分かっている場合は、DataKeeperリソースを

右クリックし、[Force Mirror Online]を選択してそのリソースを強制的にオンラインにすることができま

す。

再同期

DataKeeperリソースの再同期中、ターゲットサーバにあるこのリソースインスタンスのステータス


全同期の回避

は「Resyncing」(再同期中 )になります。ただし、リソースインスタンスは、プライマリサーバの「ソー

ス」( ISP)です。LifeKeeperのGUIは、ターゲットサーバにあるDataKeeperのリソースのステータスを以

下のアイコンで表示します。

プライマリサーバにあるDataKeeperのリソースは、以下のアイコンで表示されます。

再同期が完了するとすぐに、ターゲットのリソースの状態が「ターゲット」になり、アイコンが以下のように

変化します。

再同期プロセスについて、以下の点に注意してください。

l SteelEye DataKeeperのリソースとその親リソースは、プライマリでの障害発生時に再同期プロ

セス中のターゲットにはフェイルオーバできません。

l ターゲットサーバの同期中にDataKeeperリソースがout of service /非アクティブになった場合、

そのリソースは、同じシステム、またはすでに同期済みの別のターゲット (複数のターゲットが存在

する場合 )でのみ In Service /アクティブにすることができ、再同期が続行されます。

l 再同期プロセス中にプライマリサーバが動作不能になった場合、同期プロセス中のターゲット

サーバはすべて、DataKeeperリソースを In Serviceにすることができません。プライマリサーバが再

び動作可能になった後に、ミラーの再同期が続行されます。

全同期の回避

大量のデータをWAN リンク経由で複製する場合、膨大なネットワーク帯域幅と時間を消費する可能

性がある全同期は避けることが望ましいです。新しいカーネルと共に使用する場合、SteelEyeDataKeeperはビットマップテクノロジを使用して全同期をほぼ防ぐことができます。ただし、既存のデータ

を複製する場合、ミラーの初期設定時に発生する最初の全同期を回避することはできません(新規

データの場合には SteelEyeは全同期を実行しないので以降の手順は不要です)。

既存のデータを複製するときに、全同期を回避する方法がいくつかあります。ここでは推奨する2とおり

の方法を説明します。

326 管理

方法 1

方法 11番目の方法では、RAWディスクイメージを取得してターゲットサイトに輸送します。データがターゲット

システムに到着するまで、ソースシステムのミラーをアクティブにしておくことができるので、この方法ではダ

ウンタイムが最小になります。

手順

1. ミラーを作成してください( [Replicate Existing Filesystem]を選択 )。ただし、ターゲットシステム

にミラーを拡張しないでください。

2. ミラーを out of serviceにしてください。

3. ソースディスクまたはパーティションのイメージを取得してください。この例では、選択したディスクま

たはパーティションは /dev/sda1です

root@source# dd if=/dev/sda1 of=/tmp/sdr_disk.img bs=65536

(ブロックサイズの引数65536は単に効率的にするためです)。

ディスクまたはパーティションのRAWディスクイメージを持つファイルが作成されます。

ファイルの代わりに、ハードドライブやその他の記憶デバイスも

使用できます。

4. オプション手順 -ソースディスクまたはパーティションのチェックサムを取得してください。

root@source# md5sum /dev/sda1

5. オプション手順 -ディスクイメージファイルを圧縮してください。

root@source# gzip /tmp/sdr_disk.img

6. ビットマップファイルをクリアしてください。

root@source# /opt/LifeKeeper/bin/bitmap -c

/opt/LifeKeeper/bitmap_sdr

7. ミラーと依存ファイルシステム、およびアプリケーション(存在する場合 )のサービスを開始してくださ

い。ビットマップファイルにより、データがターゲットシステムに転送される間に発生した変更内容が

追跡されます。

8. 好みの転送方法を使用して、ターゲットシステムにディスクイメージを転送してください。

9. オプション手順 -ターゲットシステムでディスクイメージファイルを圧縮解除してください。

root@target# gunzip /tmp/sdr_disk.img.gz

10. オプション手順 –イメージファイルのチェックサムが、手順 4で取得した元のチェックサムと一致す

ることを確認してください。

root@target# md5sum /tmp/sdr_disk.img

11. イメージをターゲットシステム(例 : /dev/sda2)に転送してください。

root@target# dd if=/tmp/sdr_disk.img of=/dev/sda2 bs=65536


方法 2

12. 両方のシステムで、etc/default/LifeKeeperに LKDR_NOFULL_SYNC=1を設定してください。

root@source# echo 'LKDR_NO_FULL_SYNC=1' >>

/etc/default/LifeKeeper

root@target# echo 'LKDR_NO_FULL_SYNC=1' >>

/etc/default/LifeKeeper

13. ミラーをターゲットに拡張してください。部分的な再同期が実行されます。

方法 2ターゲットシステムを簡単に輸送できる場合、またはシステムの設定時にターゲットシステムがソースと同

じ場所にある場合に、この方法を使用できます。この方法では、最初の全同期を高速なローカルネッ

トワークで実行できるように、最終的な WAN ミラーを作成するネットワークルートを LAN ミラーに一時

的に変更します。以下の例では、ソースサイトはサブネット 10.10.10.0/24にあり、ターゲットサイトがサブ

ネット10.10.20.0/24にあると仮定しています。ソースとターゲットのシステムの間に一時的に静的ルート

を設定することにより、ローカルのイーサネット接続またはループバックケーブルを使用して「WAN」トラフィ

ックをあるサーバから別のサーバに直接送信できます。

手順

1. ソースサイトでシステムをインストールし、設定してください。

2. 静的ルートを追加してください。

root@source# route add -net 10.10.20.0/24 dev eth0

root@target# route add -net 10.10.10.0/24 dev eth0

この時点で、両方のシステムがLAN上で相互に通信できる必要があります。

3. LifeKeeperでコミュニケーションパスを設定してください。

4. ミラーを作成し、ターゲットに拡張してください。全同期が実行されます。

5. ミラーをPauseにしてください。ミラーが再開されるまで、変更内容はビットマップファイルで追跡さ

れます。

6. 静的ルートを削除してください。

root@source# route del -net 10.10.20.0/24

root@target# route del -net 10.10.10.0/24

7. ターゲットシステムをシャットダウンし、恒久的に配置する場所に輸送してください。

8. ターゲットシステムを起動し、ソースとのネットワーク接続を確立してください。

9. Resume themirrorを実行してください。部分的な再同期が実行されます。

328 管理

Multi-Site Cluster

SteelEye Protection Suite for Linux Multi-Site ClusterSteelEye Protection Suite for Linux Multi-Site Clusterは別のライセンス製品であり、2台以上のサー

バ間で LifeKeeperの共有ストレージ構成を使用し、さらにSteelEye DataKeeper for Linuxを使用して

共有ディスクを 1台以上のターゲットサーバに複製する機能を持ちます。

SteelEye Protection Suite for Linux Multi-Site ClusterSteelEye Protection Suite for Linux Multi-Site Cluster は、LifeKeeperを使用して 2台以上の

サーバ間で共有ストレージを構成し、その共有ディスクをSteelEye DataKeeperを使用して、1台以上

のサーバへミラーリングを構成する付加機能のための個別ライセンス製品です。

SteelEye Protection Suite for Linux Multi-Site Clusterは、異なるサブネットに存在する複数のネット

ワークセグメントにわたって IPアドレスのフェイルオーバを提供するように構成されたワイドエリアネットワー

クに組み込むことができます。この構成には、仮想ネットワーク(仮想 LAN( VLAN) )と仮想プライベート

ネットワーク( VPN)が含まれます。

以下の画像は、SteelEye Protection Suite for Linux Multi-Site Cluster製品を構成した後の

SteelEye LifeKeeperのGUIです。階層の釣り合いが取れていないように見えますが、階層は適切に

構成されており、正しく機能します。すでにSteelEye DataKeeperを使用していて SteelEye


Multi-Site Clusterを設定する際の考慮事項

LifeKeeperのグラフィカルユーザインターフェースに慣れている場合、LifeKeeperのGUIでのSteelEyeProtection Suite Multi-Site Clusterリソース階層の表示は、旧リリースのSteelEye DataKeeperとは異

なります。

Multi-Site Cluster を設定する際の考慮事項

システムの構成を始める前に、Linuxのマルチサイトクラスタ階層の環境では避けるべき階層構成を理

解しておくことが重要です。

以下に、Linux Multi-Site Cluster環境で避ける必要のある階層構成の例を 3つ示します。これらすべ

ての例で、Linux Multi-Site Cluster階層は、下にあるデバイスを別の階層と共有しています。いずれか

の階層で障害またはスイッチオーバが起こると、関連する階層が影響を受けます。これにより、アプリ

ケーションの障害やミラーの破損など、予期しない結果が起こる可能性があります。この場合、後で全

同期プロセスを実行する必要があります。さらに、ミラーソースからDRサイトに切り替えて DRサイトか

らプライマリサイトへのミラーバックを許可すると、事態が複雑になることがあります。これは、ミラーターゲッ

トシステムが回レベルのディスクリソースを In Serviceにしているからです。すべての共有リソースも、ミラー

ターゲットと同じノードで動作可能 ( ISP)にする必要があります。

330 Multi-Site Cluster

Multi-Site Clusterの制限

例 : 説明

1 Multi-Site Cluster階層のミラーディスクリソースを、複数回、同じ階層または別の階層で使用

する。

2ミラービットマップ用に、同じ Multi-Site Clusterのファイルシステムまたはディスクリソースを、複

数のMulti-Site Cluster階層で使用する(各ミラーのビットマップファイルは、一意のLUNに存

在する必要があり、共有できない)。

3 ビットマップファイルシステム、デバイス、またはディスクリソースを、別の階層 (マルチサイトまたは

非マルチサイト )で使用する。

Multi-Site Clusterの制限

l Linux Multi-Site Clusterを使用する場合、SteelEye Logical VolumeManager Recovery Kitをディザスタリカバリノードにインストールしないでください。

SteelEye Protection Suite for Linux Multi-Site Cluster リソース階層の作成

プライマリサーバで以下の操作を行ってください。

1. [Edit] > [Server] > [Create Resource Hierarchy]を選択してください。

[Create Resource Wizard]ダイアログボックスが表示されます。

2. ドロップダウンリストから [Data Replication]オプションを選択し、[Next]をクリックして続行してく

ださい。

3. 以下の情報を入力するように要求されます。ダイアログボックスで [Back]ボタンが有効な場合

は、前のダイアログボックスに戻ることができます。これは、エラーが発生して、前に入力した情報

を修正する必要がある場合に便利な機能です。いつでも [Cancel]をクリックして、作成処理

全体を取り消すことができます。


SwitchbackType

[intelligent switchback]を指定する必要があります。これは、バックアッ

プサーバにフェイルオーバした後、管理者が手動でMulti-Site Clusterリソースをプライマリサーバにスイッチバックする必要があることを意味しま

す。

注意 : このリリースのSteelEye DataKeeperは、DataKeeperリソースの

自動スイッチバックをサポートしていません。さらに、自動スイッチバックの

制限は、Multi-Site Cluster階層を構成する LifeKeeperリソースにも適

用されます。この制限の対象として、階層の上に存在するもの、または

階層内の子が含まれます。

ServerNetRAIDデバイスを作成するサーバ(通常はプライマリサーバ)の名前

を選択してください。ドロップダウンリストボックスには、クラスタ内のすべて

のサーバが表示されます。


Replicate New File System


HierarchyType

以下のいずれかを選択して、作成するデータ複製のタイプを選択してく

ださい。




以降の一連のダイアログボックスは、[Hierarchy Type]で選択した項目によって異なります。一部のダ

イアログボックスはすべての階層タイプで同じですが、表示される順序と必要な情報が少し異なることが

あります。以下の3つのトピックで、階層作成の残りのプロセスについて説明しています。




Replicate New File Systemこのオプションは、NetRAIDデバイスを作成し、LifeKeeperがサポートするファイルシステムタイプでフォー

マットします。ファイルシステムをNetRAIDデバイスにマウントし、マウントしたファイルシステムとNetRAIDデバイスの両方を LifeKeeperで保護します。NetRAIDデバイスとローカルのディスクまたはパーティション

がフォーマットされ、既存のデータが削除されます。新しいファイルシステムにミラーを作成し、LifeKeeperで保護する場合にこのオプションを選択してください。このリソースタイプには、1つの空いているディスクま

たはパーティションが必要です。

注意 : このオプションを選択すると、ローカルのディスクまたはパーティションがフォーマットされ、既存のデー

タがすべて削除されます。

1. 要求されたら、以下の情報を入力してください。


Source Diskor Partition

[Source Disk or Partition] ドロップダウンリストには、以下のものを除いて、使用

できるすべてのディスクが表示されます。

l 現在マウントされているもの

l スワップディスクまたはスワップパーティション

l LifeKeeperが保護するディスクまたはパーティション

ドロップダウンリストには、root (/)、boot (/boot)、 /proc、 floppy、cdromなどの特

殊なディスクまたはパーティションも表示されません。

2. 非共有のソースのディスクまたはパーティションを選択した場合、以下の画面が表示されます。


Replicate New File System

3. 共有のソースのディスクまたはパーティションを選択するには、[Back]を選択してください。残りの

情報を指定して、SteelEye Protection Suite for Linux Multi-Site Clusterリソースの構成を完了



New MountPoint

新しいファイルシステムの新しいマウントポイントを入力してください。これは、複製

したディスクまたはパーティションが配置されるマウントポイントです。

New FileSystemType

ファイルシステムタイプを選択します。LifeKeeperがサポートするファイルシステムタ

イプのみを選択できます。


DataKeeperリソースインスタンスの一意のDataKeeperリソースタグ名を選択する

か、入力してください。

File SystemResourceTag

ファイルシステムリソースインスタンスのファイルシステムリソースタグを選択するか、


Bitmap File

プルダウンリストからビットマップファイルの項目を選択してください。

表示されたリストには、ビットマップファイルの保持に使用できる共有ファイルシステ

ムがあります。$LKROOT/binディレクトリを参照 )。ビットマップファイルは、階層内

のローカルノード間で切り替え可能な共有デバイスに配置する必要があります。


Replicate Existing File System

4. [Next]をクリックして、確認画面に進んでください。

5. 確認画面に、新しいファイルシステムの作成場所、およびローカルのディスクまたはパーティション

について保留中の再フォーマットに関する警告が表示されます。[Create]をクリックして、リソース

の作成を開始します。

6. リソースを新しいファイルシステムに作成するために有効なデータを指定したかどうか

が、LifeKeeperにより検証されます。LifeKeeperが問題を検知した場合は、情報ボックスにエ

ラーが表示されます。検証が正常に完了すると、リソースが作成されます。ディスクまたはパーテ

ィションのサイズにより、ファイルシステムの作成には数分かかることがあります。

[Next]をクリックして次に進んでください。

7. 新しい複製ファイルシステムのリソース階層が正常に作成されたことを示す情報ボックスが表示

されます。複製を開始してリソース階層を LifeKeeperで保護するには、クラスタ内の別のサーバ

にリソース階層を拡張する必要があります。

リソースを拡張する場合は [Next]、後でリソースを拡張する場合は [Cancel]をクリックしてくださ

い。

[Continue]をクリックすると、Pre-extend Wizardが起動します。リソース階層を別のサーバに拡

張する方法の詳細については、リソース階層の拡張の手順 2を参照してください。

Replicate Existing File Systemこのオプションは、ローカルのディスクまたはパーティションに現在マウントされているファイルシステムをアン

マウントし、NetRAIDデバイスを作成して、ファイルシステムをNetRAIDデバイスに再マウントしま

す。NetRAIDデバイスとマウントされたファイルシステムの両方が、LifeKeeperで保護されます。既存の

ファイルシステムにミラーを作成し、LifeKeeperで保護する場合にこのオプションを選択してください。


フィール

ドヒント

ExistingMountPoint

これは、プライマリサーバのNetRAIDデバイスにマウントするマウントポイントです。ロー

カルのディスクまたはパーティションがすでに、このマウントポイントにマウントされている


2. 非共有のソースのマウントポイントを選択した場合、以下の画面が表示されます。


DataKeeper Resource

3. 共有のマウントポイントを選択するには、[Back]を選択してください。残りの情報を指定し

て、SteelEye Protection Suite for Linux Multi-Site Clusterリソースの構成を完了してください。





File SystemResourceTag

ファイルシステムリソースタグの名前を選択するか、入力してください。

Bitmap File





4. [Next]をクリックして、DataKeeperリソースをプライマリサーバに作成してください。

5. DataKeeperリソースのを作成するために有効なデータを指定したかどうかが、LifeKeeperにより

検証されます。LifeKeeperが問題を検知した場合は、情報ボックスにエラーが表示されます。

検証が正常に完了すると、リソースが作成されます。[Next]をクリックしてください。

6. 既存のレプリケーションファイルシステムのリソース階層が正常に作成されたことを示す情報ボック

スが表示されます。レプリケーションを開始してリソース階層を LifeKeeperで保護するには、クラ

スタ内の別のサーバにリソース階層を拡張する必要があります。リソースを拡張する場合は [Next]、後でリソースを拡張する場合は [Cancel]をクリックしてくださ

い。



DataKeeper Resourceこのオプションは、NetRAIDデバイスのみを作成し(ファイルシステムは作成しない)、NetRAIDデバイス


DataKeeper Resource

を LifeKeeperで保護します。ディスクまたはパーティション上にDataKeeperデバイスのみを作成

し、LifeKeeperで保護する場合にこのオプションを選択してください。読み取り可能なミラーを作成する

には、このデバイス上にファイルシステムを作成し、マウントする操作を手動で行う必要があります。この

リソースタイプには、1つの空いているディスクまたはパーティションが必要です。



Source Diskor Partition

ドロップダウンボックスのソースディスクまたはパーティションのリストには、以下のも

のを除いて、使用できるすべてのディスクが表示されます。

l 現在マウントされているもの

l スワップタイプのディスクまたはパーティション




注記 : VMwareを使用する場合は、「VMwareの既知の問題」を参照してくだ

さい。

2. 非共有のソースのディスクまたはパーティションを選択した場合、以下の画面が表示されます。



3. 共有のソースのディスクまたはパーティションを選択するには、[Back]を選択してください。残りの

情報を指定して、SteelEye Protection Suite for Linux Multi-Site Clusterリソースの構成を完了






Bitmap File





4. [Next]をクリックしてください。

5. 使用する前に、ファイルシステムを手動で作成し、NetRAIDデバイス( /dev/mdX)にマウントする

必要があることを示す情報ウィンドウが表示されます。

[Create]をクリックして、DataKeeperデバイスをローカルのディスクまたはパーティションに作成して

ください。

6. 情報ボックスが表示され、DataKeeperリソースのを作成するために有効なデータを指定したか

どうかが、LifeKeeperにより検証されます。LifeKeeperが問題を検知した場合は、情報ボックス

にエラーが表示されます。検証が正常に完了すると、リソースが作成されます。

[Next]をクリックして次に進んでください。

7. DataKeeperリソースデバイスが正常に作成されたことを示す情報ボックスが表示されます。デー

タの複製を開始し、バックアップ/ターゲットサーバを LifeKeeperで保護するには、クラスタ内の別

のサーバに階層を拡張する必要があります。

リソースを拡張する場合は [Continue]、後でリソースを拡張する場合は [Cancel]をクリックして

ください。




この操作は [Edit]メニューから、プライマリサーバからセカンダリサーバに開始する必要があります。または

[Create Resource Hierarchy]オプションの動作が完了すると自動的に開始されます。その場合は、

手順 2を参照してください。







注記 :最初の2つのフィールドは [Edit]メニューから拡張を開始した場合にだけ表示されます。


TemplateServer

DataKeeperリソースが現在 In Serviceのテンプレートサーバを選択してください。

ここで選択するテンプレートサーバと次のダイアログボックスで選択する拡張するタ

グによって、 In Service (アクティブ)のリソース階層が表示されることを理解してお

くことが重要です。

選択したテンプレートサーバで In Serviceでないリソースタグを選択した場合、エ

ラーメッセージが表示されます。このダイアログのドロップダウンボックスには、クラスタ

内の全サーバの名前が表示されます。

Tag toExtend

これは、テンプレートサーバからターゲットサーバに拡張するDataKeeperインスタン

スの名前です。ドロップダウンボックスには、テンプレートサーバ上に作成したすべて

のリソースが表示されます。


SwitchbackType

[intelligent switchback]を指定する必要があります。これは、バックアップサーバ

にフェイルオーバした後、管理者が手動でMulti-Site Cluster階層のリソースをプ

ライマリサーバにスイッチバックする必要があることを意味します。

注意 : このリリースのDataKeeper for Linuxは、DataKeeperリソースの自動スイッ

チバックをサポートしていません。さらに、自動スイッチバックの制限は、Multi-SiteCluster階層を構成する LifeKeeperリソースにも適用されます。この制限の対象

として、階層の上位あるいは下位にあるリソースも含まれます。

テンプレート

の優先順

位

Template Priorityを選択または入力します。これはサーバで現在 In ServiceのDataKeeper階層の優先順位です。優先順位は、1～ 999の範囲で未使用の

値が有効で、小さい数字ほど優先順位が高くなります(数字 1が最高の優先順

位に相当します)。拡張処理時に、別のシステムですでに使用中の優先順位を

この階層に対して指定することはできません。デフォルト値を推奨します。

注記 : このフィールドは、階層をはじめて拡張するときにだけ表示されます。

ターゲットの

優先順位

Target Priorityを選択または入力します。これは、他のサーバにある同等の階層

に対する、新しく拡張するDataKeeper階層の優先順位です。1～ 999の範囲

で、まだ優先順位として使用されていない値が有効で、リソースのカスケーディン

グフェイルオーバシーケンスにおけるサーバの優先順位を示します。数値が小さい

ほど優先順位は高くなります( 1は最高の優先順位を表します)。LifeKeeperのデフォルトでは、階層が作成されたサーバに「1」が割り当てられることに注意してく

ださい。優先順位は連続している必要はありませんが、特定のリソースについて

2つのサーバに同じ優先順位を割り当てることはできません。

3. Pre-Extendのチェックが正常に終了したというメッセージが表示されたら、[Next]をクリックしてくだ

さい。

4. 拡張する階層に応じて、拡張されるリソースタグ(一部編集不可 )を示す一連の情報ボックス


リソース階層の拡張を実行する場合は、[Next]をクリックしてください。



次のセクションには、別のサーバにDataKeeperリソースを拡張するために必要な手順を示します。

DataKeeper リソース階層の拡張




Mount Pointターゲットサーバ上にあるファイルシステムのマウントポイント名を入力してくださ



Root Tag






DataKeeper リソースタグの名前を選択するか、入力してください。

Bitmap Fileインテントログの記録に使用するビットマップファイルの名前を選択してくださ

い。[None]を選択すると、インテントログは使用されず、すべての再同期が部分

的ではなく全体の再同期になります。

2. [Next]をクリックして次に進んでください。拡張が実行中であることを示す情報ボックスが表示さ

れます。


さい。


注記 :必ずすべてのサーバで手動スイッチオーバを実行して、新しいインスタンスの機能をテスト

してください。詳細については、リソース階層のテストを参照してください。この時点

で、DataKeeperがソースからターゲットのディスクまたはパーティションにデータの再同期を開始し

ています。LifeKeeperのGUIでは、ターゲットサーバにあるDataKeeperリソースのステータス

は「Resyncing」になります。再同期が完了すると、ステータスは「Target」になります。これは通

常のスタンバイ状態です。

再同期中、DataKeeperリソース、およびそれに依存するリソースはフェイルオーバできません。こ

れは、データの破損を防止するためです。

ディザスタリカバリシステムへの階層の拡張

この操作は、 ISP ノードから、または複数ノードの作成プロセスの一環として [Edit]メニューからのみ実

行できます。または [Create Resource Hierarchy]オプションの動作が完了すると自動的に開始され

ます。その場合は、手順 2を参照してください。







注記 :最初の2つのフィールドは [Edit]メニューから拡張を開始した場合にのみ表示されます。



SwitchbackType

[intelligent switchback]を指定する必要があります。これは、バックアップサーバに

フェイルオーバした後、管理者が手動でMulti-Site Cluster階層のリソースをプラ

イマリサーバにスイッチバックする必要があることを意味します。

注意 : このリリースのSteelEye DataKeeper for Linuxは、DataKeeperリソースの

自動スイッチバックをサポートしていません。さらに、自動スイッチバックの制限

は、Multi-Site Cluster階層を構成する LifeKeeperリソースにも適用されます。こ

の制限の対象として、階層の上位あるいは下位にあるリソースも含まれます。

TargetPriority

ターゲットの優先順位を選択するか、入力してください。これは、他のサーバにあ

る同等の階層に対する、新しく拡張するDataKeeper階層の優先順位です。1～ 999の範囲で、まだ優先順位として使用されていない値が有効で、リソース

のカスケーディングフェイルオーバシーケンスにおけるサーバの優先順位を示しま

す。数値が小さいほど優先順位は高くなります(数値 1が最高の優先順

位 )。LifeKeeperのデフォルトでは、階層が作成されたサーバに「1」が割り当てら

れることに注意してください。優先順位は連続している必要はありませんが、特

定のリソースについて 2つのサーバに同じ優先順位を割り当てることはできませ

ん。

TemplatePriority

テンプレートの優先順位を選択するか、入力してください。これはサーバで現在 InServiceのDataKeeper階層の優先順位です。1～ 999の範囲で、まだ優先順

位として使用されていない値が有効で、小さい数字ほど優先順位が高くなりま

す(数値 1が最高の優先順位 )。拡張処理時に、別のシステムですでに使用中

の優先順位をこの階層に対して指定することはできません。デフォルト値を推奨

します。

注記 : このフィールドは、階層を最初に拡張するときにだけ表示されます。

3. Pre-Extendのチェックが正常に終了したというメッセージが表示されたら、[Next]をクリックしてくだ

さい。

注記 :拡張する階層に応じて、拡張されるリソースタグ(一部編集不可 )を示す一連の情報ボ

ックスが表示されます。

4. [Next]をクリックして、[Extend Resource Hierarchy]の構成タスクを開始してください。

次のセクションには、別のサーバにDataKeeperリソースを拡張するために必要な手順を示します。






Mount Pointターゲットサーバ上にあるファイルシステムのマウントポイント名を入力してくださ



Root Tag





Target Diskor Partition

複製するファイルシステムの配置先となる、ターゲットサーバ上のディスクまたは

パーティションを選択してください。

ドロップダウンボックスのディスクまたはパーティションのリストには、以下のものを除

いて、使用できるすべてのディスクが表示されます。

l すでにマウント済みのもの

l スワップディスクまたはスワップパーティション




注記 : ターゲットのディスクまたはパーティションは、ソースのディスクまたはパーティシ

ョン以上のサイズである必要があります。


DataKeeper リソースタグの名前を選択するか、入力してください。

Bitmap Fileインテントログの記録に使用するビットマップファイルの名前を選択するか入力して

ください。[None]を選択すると、インテントログは使用されず、すべての再同期が

部分的ではなく全体の再同期になります。

ReplicationPath

ターゲットサーバとクラスタ内の他の指定サーバとの間で複製に使用する、ローカ

ルとリモートの IPアドレスのペアを選択してください。有効なパスおよび対応する

IPアドレスは、このサーバのペアに対して指定した LifeKeeperコミュニケーションパ

スのセットから得られます。DataKeeperの特性により、プライベート (専用 )ネット

ワークを使用することが強く推奨されます。

DataKeeperリソースをすでに 1台以上のターゲットサーバに拡張している場合、

追加のサーバに対する拡張を実行すると、新しいターゲットサーバと既存のサーバ

との組み合わせのそれぞれについて、繰り返し複製パスを指定するように要求さ

れます。


IP リソースのリストアおよびリカバリの設定


ReplicationType

指定したサーバのペアについて使用する複製タイプとして、[synchronous]また

は [asynchronous]を選択してください。

前述の [Replication Path]フィールドと同様に、DataKeeperリソースをすでに 1台以上のターゲットサーバに拡張している場合、追加のサーバに対する拡張を

実行すると、新しいターゲットサーバと既存のサーバとの組み合わせのそれぞれに

ついて、繰り返し複製タイプを指定するように要求されます。

2. [Next]をクリックして次に進んでください。拡張が実行中であることを確認する情報ボックスが表

示されます。


さい。


IP リソースのリストアおよびリカバリの設定

この設定を完了するには、 IP リソースの [Restore]と [Recovery]の設定を [Disable]にする必要があ

ります。このオプションは、[Properties]ペインに表示されます。ある IP リソースの [Properties]ペインを

開いたとき、またはある IP リソースのプロパティを表示するときには、この設定は 3つのボタンオプションの

いずれかです。このオプションの詳細については、 IP Recovery Kitを参照してください。

注記 : 必ずすべてのサーバで手動スイッチオーバを実行して、新しいインスタンスの機能をテストしてく

ださい。詳細については、リソース階層のテストを参照してください。ディザスタリカバリノードへの拡張が

完了している場合、この時点で、SteelEye DataKeeperがソースからターゲットのディスクまたはパーティ

ションにデータの再同期を開始しています。LifeKeeperのGUIでは、ターゲットサーバにある

DataKeeperリソースのステータスは「Resyncing」(再同期中 )になります。再同期が完了すると、ステー

タスは「Target」になります。これは通常のスタンバイ状態です。

再同期中、DataKeeperリソースおよびそれに依存するリソースはフェイルオーバできません。これは、

データの破損を防止するためです。

まだ実行していない場合は、必ずconfirm failoverフラグをセットしてください。この手順の詳細について

は、 [Confirm Failover] と [Block Resource Failover]の設定のセクションを参照してください。

Multi-Site Cluster環境へのマイグレーション

SteelEyeMulti-Site Migrate機能が、SteelEye Protection Suite for Linux Multi-Site Cluster製品に装

備されています。この追加機能を使用すると、管理者は既存のSteelEye Linux LifeKeeper環境を

Multi-Site Cluster環境に移行できます。移行手順により、階層のダウンタイムを最小に抑えて、選択

した共有ファイルシステムのリソースを安全に移行して複製できます。

既存のファイルシステムからMulti-Siteリソースを作成するときの重要な考慮事項をいくつか示します。

l Multi-Siteの移行手順では、作成プロセスでファイルシステムをアンマウントし、NetRAIDデバイ

スに再マウントします。

l リソースの作成手順中は、このファイルシステムに依存するアプリケーションをすべて、停止する


要件

必要があります。この操作は移行手順が処理するので、管理者からの操作は不要です。

l NAS( scsi/netstorage)、DRBD( scsi/drbd)、SDR( scsi/netraid)、およびMulti-Site Clusterリソース( scsi/disrec)のリソースタイプを含む階層は、Multi-Siteの移行機能を使用して移行す

ることはできません。

要件

マイグレーションを実行する前に、お使いのシステムが本書のインストールと設定セクションに記載されて

いる要件を満たすことを確認してください。「SDRのインストール」セクションにまとめられている一般的な

SDRの要件に加えて、クラスタ内の各システムにNovellのSLES 11、SLES 10、またはRedHatEnterprise Linux 5がインストールされている必要があります。この機能は、ストレージデバイスを共有す

る 2つのサーバがある構成のために定義されています。1台のサーバはプライマリで、プライマリサイトにあ

ります。3台目のサーバはリモートで、ディザスタリカバリサイトにあります。

SteelEye Protection Suite for Linux Multi-Site Clusterをプライマリとその他の共有ストレージノードにイ

ンストールした後は、マイグレーション機能を活用するために必要な追加のインストールや設定は不要

です。

始める前に

以下の画像に、移行を開始する前のファイルシステムのリソース階層を示します。


マイグレーションの実行


Multi-Site Migrateを構成して実行するには 3とおりの方法があります。以下の操作ができます。

l LifeKeeperのGUIのツールバーから [Migrate]アイコンを選択し、移行するリソースを選択します。

l ファイルシステムリソースを右クリックして、[Migrate Hierarchy to Multi-Site Cluster]メニューオ

プションを選択します。

l ファイルシステムリソースを選択し、[Properties Panel]ツールバーの [Migration]アイコンを選択

します。



グローバルツールバーのアイコンから移行を開始した場合、以下のダイアログボックスが表示され

ます。

1. 移行する階層が存在する、 In Serviceのサーバを選択してください。[Next]をクリックしてくださ

い。



2. 移行する root階層タグを選択し、[Next]をクリックしてください。root タグは、ファイルシステムに

することも、他のアプリケーションリソースにすることもできます。選択したタグ(ファイルシステム以

外のリソースの場合 )には、ファイルシステムに依存するリソースが含まれている必要があります。

LifeKeeperのGUIのウィンドウでファイルシステムを選択し、ポップアップウィンドウから [MigrateHierarchy to Multi-Site Cluster]を選択するか、[Properties Panel Migrate]アイコンの

[Migrate]アイコンを選択した場合、以下の初期化画面が表示されます。



3. [Continue]ボタンが有効になったらクリックしてください。以下のビットマップダイアログが表示され

ます。



4. 移行するファイルシステムのビットマップファイルを選択してください。[Next]をクリックしてください。

重要 : [Next]をクリックした後は、このファイルシステムのビットマップファイルの選択を変更できなく

なります。



5. 階層内で移行する 2番目のファイルシステムのビットマップファイルを選択してください。前のダイ

アログボックスで 1番目のビットマップファイルを選択した後、追加のファイルシステムタグが表示さ

れるので、それらの各タグについて一意のビットマップファイルを入力できます。注記 :移行するファイルシステムが1つのみの場合は、この画面は表示されません。また、移行

するファイルシステムが2つ以上の場合、この画面に似た複数の画面が表示されます。

6. [Next]をクリックしてください。以下のような概要画面が表示されます。



7. この概要画面には、移行手順で送信したすべての構成情報が表示されます。[Migrate]をクリ

ックすると、以下の画面が表示されます。



8. 移行ステータスがこのウィンドウに表示されます。[Finish]ボタンが有効になったらクリックしてくだ

さい。


マイグレーションの正常な完了


以下の画像に、Multi-Siteのマイグレーションが完了した後のファイルシステムリソース階層の例を示し

ます。これで、階層を非共有ノード ( megavolt)に拡張できます。



以下の表に、予測される問題と推奨される処置を示します。

症状推奨される処置

DataKeeperリソースを削除し

た後に

NetRAIDデバ

イスが削除され

ない。

NetRAIDデバイスがマウントされている場合、DataKeeperリソースを削除しても

NetRAIDデバイスは削除されません。以下のコマンドを使用して、手動でデバイス

をアンマウントして削除することができます。

mdadm –S <md_device> (<md_device>を調べるには cat /proc/mdstat)

インストー

ル/HADR rpmの失敗

これらのファイルを手動でインストールするための詳細手順については、インストール

セクションを参照してください。

フェイルオーバ

中のエラー

デバイスのステータスを確認してください。再同期が進行中の場合、フェイルオーバ

は実行できません。

プライマリサー

バに障害が発

生すると、セカ

ンダリサーバの

DataKeeperリソースが ISPに

なります。ただ

し、プライマリ

サーバが再起

動すると、両方

のサーバで

DataKeeperリソースがOSFになります。

DataKeeperリソース階層の作成時に選択した「スイッチバックタイプ」を確認してく

ださい。このリリースでは、DataKeeperリソースの自動スイッチバックはサポートされ

ていません。リソースプロパティのウィンドウで、スイッチバックタイプを [Intelligent]に変

更できます。

両方のサーバ

が動作不能に

なってからプラ

イマリサーバが

再起動したと

きに、リソースを

ISPにすること

ができない。

セカンダリサーバよりも前にプライマリサーバが動作可能になった場合、DataKeeperリソースを強制的にオンラインにすることができます。このためには、リソースプロパティ

のダイアログを開き、[Replication Status]タブ、[Actions]ボタンを順にクリックし、

次に [Force Mirror Online]を選択してください。[Continue]をクリックして確認し

てから、[Finish]をクリックしてください。




現在マウントし

ているNFSファ

イルシステムに

DataKeeper階層を作成する

ときのエラー

現在 NFSがエクスポートしたファイルシステムに、DataKeeper階層を作成しようと

しています。エクスポートする前に、このファイルシステムを複製する必要がありま

す。

DataKeeperのGUIのウイザー

ドに、新しく作

成したパーティ

ションがリストさ

れない。

Linux OSは、システムを次回再起動するまで、新しく作成したパーティションを認

識しないことがあります。新しく作成したパーティションのエントリを調べるに

は、 /proc/partitions ファイルを表示してください。新しく作成したパーティションがこの

ファイルに表示されない場合、システムを再起動する必要があります。

プライマリとバッ

クアップの両方

のサーバで、リ

ソースが

緑 ( ISP)で表

示される。

これは、「制御分離」のシナリオで、一時的な通信障害により発生することがありま

す。通信の再開後、両方のシステムがそれぞれ、それ自体をプライマリと見なしま

す。

いずれのシステムが最終のプライマリシステムであったかが不明なので、DataKeeperはデータを再同期しません。手動操作が必要です。

ビットマップを使用しない場合 :

最終のバックアップであったサーバを特定し、そのサーバのリソースをOut of Serviceにする必要があります。その後、DataKeeperが全体の再同期を実行します。

ビットマップを使用している場合 ( 2.6.18以前のカーネル) :

元のバックアップノードから始めて、両方のリソースをOut of Serviceにする必要があ

ります。次に、以下のコマンドを実行して、プライマリノードのビットマップをダーティに

設定する必要があります。$LKROOT/lkadm/subsys/scsi/netraid/bin/bitmap –d /opt/LifeKeeper/bitmap_filesys

( /opt/LifeKeeper/bitmap_filesysハビットマップファイルの名前 )。これにより、リソース

が In Serviceになると、全体の再同期が強制実行されます。次に、プライマリノー

ドでリソースを In Serviceにします。全体の再同期が開始されます。

ビットマップを使用する場合 ( 2.6.19以降のカーネルまたはRedHat EnterpriseLinux 5.4の2.6.18-164以降のカーネル(またはRedHat 5.4以降のサポートする派

生カーネル) :

最終のバックアップであったサーバを特定し、そのサーバのリソースをOut of Serviceにする必要があります。その後、DataKeeperが部分的な再同期を実行します。




Install -コアを

SUSEにインス

トールすると、

パッケージのチ

ェックエ

ラー( rpm -Vsteeleye-lk)がコアで発生する

以下のエラーが発生します。

SUSEがシャットダウンスクリプトを実行する方法により(他のLinuxディストリビュー

ションと比較して)、インストール後に以下のスクリプトが別の場所に移動されます。

このため、実行レベルを変更したり再起動したりすると、LifeKeeperがシャットダウン

します。これらのエラーは、steeleye-lkパッケージの検証時にのみ発生します。

不足 /etc/rc.d/rc0.d/K01lifekeeper



Core -言語環

境の影響

LifeKeeperの一部のスクリプトは Linuxのシステムユーティリティの出力を解析し、

情報を抽出するために特定のパターンに依存します。これらのコマンドのいくつかを

英語以外のロケールで実行すると、予測パターンが変更され、LifeKeeperのスクリ

プトは必要な情報を取得できません。このため、 /etc/default/LifeKeeperでは、言

語環境変数 LC_MESSAGESがPOSIX「C」のロケールに設定されています( LC_MESSAGES=C)。言語を英語にして Linuxをインストールする必要はありません(インストールメディアで使用できる任意の言語を選択可

能 )。 /etc/default/LifeKeeperのLC_MESSAGESの設定は LifeKeeperにのみ影

響します。 /etc/default/LifeKeeperのLC_MESSAGESの値を変更する場合

は、LifeKeeperの動作に悪影響を及ぼす可能性があることに注意してください。

副作用は、多様な言語とユーティリティ用にメッセージカタログがインストールされて

いるか、およびLifeKeeperが予測しないテキスト出力が生成されるかどうかによって

異なります。

Core - SLES10システムでシャ

ットダウンがハン

グする。

SLES10をインストールした AMD64システムでシャットダウンを実行すると、システム

がロックアップしてシャットダウンが完了しません。これは、バグ#294787によりNovellに報告済みです。このロックアップは、SLES10節電パッケージが原因と考えられて

います。

回避策 : SLES10節電パッケージを削除すると、シャットダウンが正常に完了するよ

うになります。

GUI - GUIの終了後にWebブラウザから再

接続したとき

に、GUIのログ

インプロンプト

が再表示され

ないことがあ

る。

GUIアプレットを終了するか切断してから、同じ Webブラウザのセッションから再接

続しようとすると、ログインプロンプトが表示されないことがあります。

回避策 :Webブラウザを閉じ、Webブラウザを開き直してからサーバに接続しま

す。Firefoxブラウザを使用している場合は、Firefoxのウィンドウをすべて閉じてか

ら、開き直します。




GUI - RHEL5の lkGUIappが未サポートの

テーマエラーを

レポートする。

GUIアプリケーションクライアントの開始時に、以下のコンソールメッセージが表示さ

れることがあります。

/usr/share/themes/Clearlooks/gtk-2.0/gtkrc:60:Engine "clearlooks" isunsupported, ignoring

このメッセージは、RHEL 5およびFC6 Javaプラットフォームの表示方式からのもの

で、GUI クライアントの動作に悪影響は及ぼしません。

DataReplication- GUIにSLES10 SP2システ

ムの正しいス

テータスが表示

されない。

SLES 10 SP2では、 /proc/<PID>/fdの新しいフォーマットによりnestatが壊れてい

ます。この問題は SLES 10 SP2カーネルのバグに起因しており、カーネルの更新

バージョン 2.6.16.60-0.23で修正済みです。

解決策 : SLES 10 SP2を実行している場合は、カーネルをバージョン 2.6.16.60-0.23にアップグレードしてください。

DataReplication -32ビットマシン

のサイズ制限

32ビットマシンで 2 TBを超えるドライブを複製しようとすると、以下のエラーが発生

することがあります。

Negotiation:..Error:Exported device is too big for me.Get 64-bit machine

解決策 : 32ビットマシンで SteelEye DataKeeperを使用する場合、2 TBを超える

ドライブの複製はできません。

VMwareのゲス

トのデバイス IDが/dev/disk/by-idにない。

DataKeeperの作成プロセスで、複製に使用できるすべてのディスクまたはパーティ

ションを表示するはずのドロップダウンボックスに、仮想ハードディスクのディスク IDが

表示されません。

VMwareのデバイス IDは /dev/disk/by-idにないので、DataKeeperはそれらの正し

い IDを特定できません。

回避策 :以下のファイルにドライブを手動で追加してください。

/opt/LifeKeeper/subsys/scsi/resources/DEVNAME/device_

pattern


Index

Index

A

API 156

B

Block Resource Failover 305

C

Confirm Failover 304

CONFIRM_SOリザベーションの無効化 133

Core 52

F

File Systems 53

G

Generic Applications 53

GUIGUIサーバプロセスの表示 201

LifeKeeperサーバでの実行 197

ソフトウェアパッケージ 177

デスクトップのツールバーにアイコンを追加する 85

ユーザの設定 190

リモートシステムでの実行 195

停止 189

概要 186

終了 200

設定 187

開始 189


Index

GUI からのミラーの管理 316

I

In Service 219

IP Addresses 53

J

Javaセキュリティポリシー 192

プラグイン 194

L

LifeKeeper Communications Manager (LCM) 228ステータスの情報 229

警報とリカバリ

LifeKeeperの警報インターフェース 229

LifeKeeper イベントメール通知

設定 83

LifeKeeper のローカルリカバリ動作と制御のインターフェース (LRACI) 53

LifeKeeper の停止 201, 240

LifeKeeper の削除 235

LifeKeeper の起動 200, 239

LifeKeeper 設定データベース (LCD) 221/opt/LifeKeeperのLCDのディレクトリ構造 227

コマンド

LCD インターフェース (LCDI) 221

ディレクトリ構造 225

フラグ 225


リソースのサブディレクトリ 226

設定データ 224


Index

lkbackupSDRによる 261

破損したイクイバレンシ 255

lkpolicy ツール 153

M

Multi-Site Cluster 329ファイルシステム

新規の複製 332

既存の複製 334

リストアおよびリカバリの設定 342

リソース階層

ディザスタリカバリシステムへの拡張 339

作成 331

拡張 337

制限 331

概要 329

移行

実行 344

正常な完了 352

要件 343

設定する際の考慮事項 330

N

N-Way リカバリ 157

O

Out of Service 220

Q

Quorum/Witness 136quorumモード 138


Index

Quorumを喪失した (多数派ではなくなった)ときのアクション 139

witnessモード 139



共有 Witness 140

設定可能なコンポーネント 137

R

RAW I/O 53

S

SNMP によるイベント転送 77SNMPのトラブルシューティング 81

概要 77

設定 79

STONITHリザベーションの無効化 133

T

Tag NameRestrictions 281

Valid Characters 281

TTY 接続 76

V

VMWare既知の問題 358

ア

アクティブ / スタンバイ 57

アクティブ/アクティブ 56

アダプタのオプション 9


Index

アップグレード 48

イ

イクイバレンシ情報 61

イベントメール通知 81トラブルシューティング 84

概要 77

インストール 43, 291コマンドライン 43

ライセンス 45

確認 48

インターネット Host ID 48

インテリジェントスイッチバック 58

ウ

ウオッチドッグ


エ

エラーの検出 157

カ

カスタム証明書 88

コ

コマンドライン

ミラーステータスの監視 324

ミラー管理 322

コミュニケーションパス

ハートビート 54

ファイアウォール 236

作成 158


Index

削除 160

サ

サーバグループ 54

サーバのプロパティ

フェイルオーバ 160

表示 204

サーバの障害 325

サーバプロパティ

編集 158

サーバ構成のマッピング 7

シ

システムの日付と時刻 276

ス

ステータスの表 199

ステータス表示

簡略 68

詳細 63

ストレージのオプション 9

ダ

ダイアログ

Cluster Connect 212

Cluster Disconnect 212

Resource Properties 213

Server Properties 214

ツ

ツールバー 182GUI 182


Index

サーバのコンテキスト 185

リソースのコンテキスト 184

デ

データベースアプリケーション 42

データ複製パス 293

テ


ト

トラブルシューティング 249, 355GUI


コミュニケーションパス 276

不完全なリソースの作成 277

不完全なリソースの優先順位の変更 277

制限 249

既知の問題 249

ネ

ネットワーク帯域幅

変化率の測定 293

要件の特定 293

ハ

ハードウェア 54

は

はじめに

ミラーリング 283

仕組み 284


Index

パ

パッケージ 1, 5

フ

ファイアウォール

ファイアウォールを使用した状態でのLifeKeeperの実行 236

ファイアウォール経由でのLifeKeeper GUIの実行 238

フェイルオーバのシナリオ 288

フェンシング

I/Oフェンシング表 134

代替方式 145

概要 133

ブ

ブラウザのセキュリティパラメータ 198

フラグ 305

プ

プロパティパネル 199

マ

マルチサイトクラスタ

始める前に 343

ミ

ミラーステータス

コマンドラインからの監視 324

ミラーのステータス

表示 315

ミラーを強制的にオンラインにする 318

ミラー管理

コマンドライン 322


Index

メ

メッセージバー 200

メニュー 178[Edit] メニュー - [Resource] 180

[Edit] メニュー - [Server] 181

File 180

Help 182

View 181

サーバのコンテキスト 179

リソースのコンテキスト 178

ラ

ライセンス 45

リ

リカバリ

Out-of-Service階層 280

サーバ障害 279

フェイルオーバ後 235

停止できないプロセス 280

手動リカバリ時のパニック 280

リザベーション

SCSI 143

無効化 133


リソースのプロパティ 166

リソースの優先順位 167

リソースの状態 60

リソースポリシー管理 150


Index

リソース依存関係

作成 171

削除 172

リソース階層 59In Service 313

Out of Service 313

ツリーの展開 211

ツリーの折り畳み 211

テスト 314

メンテナンス 234

作成 162, 308

Generic Application 164

Rawデバイス 165

ファイルシステム 163

例 63

削除 173, 312

情報 62

拡張 168, 309

Generic Application 170

Rawデバイス 170

ファイルシステム 169

拡張解除 170, 312

転送 240

階層の関係 61

リワインド

データのリワインドと復旧 318

リワインドブックマークの作成と表示 317

リワインドログの場所の設定 322

リワインドログの最大サイズの設定 322


Index

一

一時停止と再開 318

保

保護対象のリソース 51

健

健全性の監視 232

共

共有データリソース 55

共有通信 55

再

再同期 325全体の回避 326

出

出力パネル 200

切

切り替え可能な IP アドレス 41

切断 203

同

同期ミラーリング 284

圧

圧縮レベル 322

変

変化率 293

手

手動フェイルオーバー確認 86


Index

接

接続

サーバと共有ストレージ 39

サーバをクラスタに 202

環

環境

セットアップ 39

管

管理 157

自

自動スイッチバック 58

表

表示

サーバのステータス 203

サーバのプロパティ 204

サーバのログファイル 204

メッセージ履歴 210

リソースのステータス 205

リソースのタグと ID 205

リソースのプロパティ 207

接続サーバ 203

表示オプション 207

要

要件

DataKeeper 93

Quorum/Witnessパッケージ 136

STONITH 145


Index

ストレージとアダプタ 8

ソフトウェア 291

ハードウェア 291

ファイアウォール 236

設

設定 75, 291アプリケーション 94

データレプリケーション 93

ネットワーク 94

ネットワーク設定の確認 40

ネットワークとLifeKeeper 292

任意の作業 85

値 230

全般 292

共有ストレージ 39

手順 75

概念 54

認

認証情報 155

障

障害検出とリカバリ 69IPローカルリカバリ 69

サーバの障害リカバリのシナリオ 73

リソースのエラーリカバリのシナリオ 71

非

非同期ミラーリング 284


SteelEyeProtectionSuiteforLinux v8 -...

Documents

Transcript of SteelEyeProtectionSuiteforLinux v8 -...