A.4.1 初期セットアップ

Sentinel用に記述されている要件およびローカルカスタマ要件に従って、マシンハードウェア、ネットワークハードウェア、ストレージハードウェア、オペレーティングシステム、ユーザアカウント、およびその他の基本的なシステムリソースを設定します。システムをテストして、正常に機能し安定していることを確認します。

A.4.2 共有ストレージのセットアップ

共有ストレージをセットアップして、そのストレージをクラスタノードごとにマウントします。FibreChannelとSANを使用している場合は、この作業に物理的な接続とその他の設定が含まれる可能性があります。共有ストレージはSentinelのデータベースおよびイベントデータを保持するために使用するので、予想されるイベント発生率およびデータ保持ポリシーに基づいて、お客様の環境に合った共有ストレージのサイズを決める必要があります。

一般的な実装では、FibreChannelですべてのクラスタノードに接続された高速SANを使用し、ローカルイベントデータを保管するために大容量RAIDアレイを設置します。低速ネットワークストレージには、別個のNASノードやiSCSIノードを使用することもできます。クラスタノードがローカルストレージを通常のブロックデバイスとしてマウントできるのであれば、この方法もソリューションに利用できます。ネットワークストレージもブロックデバイスとしてマウントできますが、NFSまたはCIFSボリュームにすることも可能です。

サンプルソリューションでは、SUSE Linux VMで設定されているiSCSI Targetを使用します。初期セットアップにリストされているように、VMはstorage03です。iSCSIデバイスは任意のファイルまたはブロックデバイスを使用して作成できますが、ここでは分かりやすくするために、そのために作成したファイルを使用することにします。

storage03に接続して、コンソールセッションを開始します。次のddコマンドを使用して、Sentinelローカルストレージ用に希望する任意のサイズのブランクファイルを作成します:

dd if=/dev/zero of=/localdata count=10240000 bs=1024

ここでは、(/dev/zero pseudo-deviceからコピーして)ゼロ(0)を埋め込んだ10GBのファイルを作成します。コマンドラインオプションの詳細については、ddの情報ページまたはマニュアルページを参照してください。たとえば、異なるサイズの「ディスク」を複数作成する場合などです。iSCSI Targetはこのファイルを1つのディスクであるかのように扱います。もちろん、実際のディスクを使用することもできます。

同様の手順を繰り返して、ネットワークストレージ用のファイルを作成します。

dd if=/dev/zero of=/networkdata count=10240000 bs=1024

このサンプルの場合、同じサイズとパフォーマンス特性を持つ2つのファイル(「ディスク」)を使用します。運用展開の場合、ローカルストレージを高速なSAN上に置き、ネットワークストレージを低速なiSCSI、NFS、またはCIFSボリューム上に置くこともできます。

作成したファイルをiSCSI Targetとして設定する:

上記の手順を行うことにより、IPアドレス10.0.0.3のサーバに2つのiSCSI Targetが公開されます。各クラスタノードで、ローカルデータ共有ストレージデバイスをマウントできることを確認してください。デバイスのフォーマットも行う必要があります(1回):

上記手順のステップ1～15を繰り返して、各クラスタノードがローカル共有ストレージをマウントできることを確認します。ただし、ステップ5のノードIPを別のIPに置き換えます(たとえばnode02 > 10.0.0.2)。

A.4.3 Sentinelのインストール

Sentinelをインストールする方法には2つのオプションがあります。Sentinelのすべての部分を共有ストレージにインストールする方法(--locationオプションを使用して、Sentinelのインストールを共有ストレージのマウント先にリダイレクトする)と、アプリケーション変数データのみを共有ストレージに配置する方法です。

サンプルソリューションでは、後者の方法を採用し、Sentinelをホストする各クラスタノードにSentinelをインストールします。初めてSentinelをインストールする際には、アプリケーションバイナリ、環境設定、およびすべてのデータストアを含む完全インストールを行います。以後、他のクラスタノードにインストールする際にはアプリケーションのみをインストールし、実際のSentinelデータはその後(共有ストレージがマウントされた後など)に利用可能になるものとします。

このサンプルソリューションでは、Sentinelを各クラスタノードにインストールし、アプリケーション可変データのみを共有ストレージに保管します。こうすることで、アプリケーションバイナリと環境設定が標準の場所に保管され、RPMの検証や特定のシナリオでのウォームパッチのサポートも可能になります。

その他のノードでインストールを繰り返します:

最初のSentinelインストーラはSentinel自体が使用するユーザアカウントを作成します。そして、インストール時点から次に使用可能なユーザIDを使用します。後続のインストールを無人モードで実行すると、アカウント作成時に使用したのと同じユーザIDを使用しようとしますが、(クラスタノードがインストール時のノードと同じでない場合には)競合が発生する可能性があります。以下のいずれかを行うことを強くお勧めします。

この処理が終わると、Sentinelがすべてのノードにインストールされているはずです。しかし、各種キーが同期されるまで、最初のノード以外のノードではSentinelが正常に動作しない可能性があります。これは、クラスタリソースを設定した場合に発生します。

A.4.4 クラスタインストール

各ノードにクラスタソフトウェアをインストールし、各クラスタノードをクラスタマネージャに登録します。この操作の手順はクラスタ実装によって異なりますが、最終的には各クラスタノードがクラスタ管理コンソールに表示されている状態になります。

サンプルソリューションでは、SUSE Linux High Availability Extensionをセットアップし、それにSentinel固有のリソースエージェントをオーバーレイします。:

Sentinelの監視にOCFリソースエージェントを使用しない場合は、ローカルクラスタ環境用に同様の監視ソリューションを開発する必要があるでしょう。Sentinel用のOCFリソースエージェントはシンプルなシェルスクリプトで、さまざまな検査を実行してSentinelが機能しているかどうかを検証します。独自に開発する場合は、既存のリソースエージェントを参考に調べることをお勧めします(リソースエージェントはSentinelダウンロードパッケージのsentinel-ha.rpmに含まれています)。

SLE HAEクラスタの設定の仕方は数多くありますが、ここでは単純なオプションを選ぶことにします。最初のステップとして、SLE HAEコアソフトウェアをインストールします。その手順については『SLE HAE Documentation』に詳しく説明されています。SLESアドオンのインストールについては、『Deployment Guide』を参照してください。

このサンプルソリューションの場合、SLE HAEをすべてのクラスタノード(node01およびnode02)にインストールする必要があります。このアドオンをインストールすると、コアとなるクラスタ管理および通信ソフトウェアだけでなく、クラスタリソースの監視に使用される多数のリソースエージェントもインストールされます。

クラスタソフトウェアがインストールされたなら、さらにRPMをインストールしてSentinel固有のクラスタリソースエージェントを追加する必要があります。このRPMはnovell-Sentinel-ha-7.1*.rpmで、Sentinelをインストールする際にアンパックした通常のSentinelダウンロードに含まれています。

各クラスタノードで、novell-Sentinel-ha-7.1*.rpmを/tmpにコピーしてから、次のコマンドを実行します。

cd /tmp

rpm -i novell-Sentinel-ha-7.1*.rpm

A.4.5 クラスタ環境設定

クラスタソフトウェアを設定して、各クラスタノードをクラスタのメンバーとして登録する必要があります。この設定の一部として、フェンシングとSTONITHリソースもセットアップすることで、クラスタの整合性を保つことができます。

サンプルソリューションでは、基本的に、追加の冗長性や高度な機能を含めない最もシンプルな構成を使用します。また、(一般に好まれるマルチキャストアドレスではなく)ユニキャストアドレスを使用します。ネットワーク管理者とのやり取りが少なく済み、かつテスト目的には十分であるからです。加えて、シンプルなSBDベースのフェンシングリソースもセットアップします。

サンプルソリューションでは、内部クラスタ通信にプライベートIPアドレスを使用し、ネットワーク管理者へのマルチキャストアドレスの要求が最小限で済むようにユニキャストを使用します。ソリューションでは、iSCSI Targetも使用します。これは、フェンシングのためにSBDデバイスの役割を果たす共有ストレージをホストしているのと同じSUSE Linux VMに設定されます。前述のように、iSCSIデバイスは任意のファイルまたはブロックデバイスを使用して作成できますが、ここでは分かりやすくするために専用のファイルを作成して使用することにします。

以下の設定ステップは、「共有ストレージのセットアップ」のステップと非常によく似ています:

SBDのセットアップ

storage03に接続して、コンソールセッションを開始します。次のddコマンドを使用して、希望する任意のサイズのブランクファイルを作成します:

dd if=/dev/zero of=/sbd count=1024 bs=1024

ここでは、(/dev/zero pseudo-deviceからコピーして)ゼロ(0)を埋め込んだ1MBのファイルを作成します。

このファイルをiSCSI Targetとして設定します:

上記の手順を行うことにより、IPアドレス10.0.0.3(storage03)のサーバにSBDデバイスのiSCSI Targetが公開されます。

ノードの設定

クラスタノード(node01)に接続して、コンソールを開きます:

各追加クラスタノード(node02)に接続して、コンソールを開きます:

環境によっては、クラスタ通信が正しく初期化されないことがあります。クラスタが起動しない場合(openaisサービスが開始できない場合):

場合によっては、xinetdサービスが新規csync2サービスを正しく追加できないために、スクリプトが失敗する可能性があります。他方のノードがクラスタ設定ファイルをこのノードに同期できるようにするためには、このサービスが必須です。csync2 run failed (csync2の実行が失敗しました)のようなエラーが表示されるときは、この問題である可能性があります。この問題を修復するには、kill -HUP `cat /var/run/xinetd.init.pidを実行してから、sleha-joinスクリプトを再実行します。

この時点で、各クラスタノードでcrm_monを実行できるようになっており、クラスタが正常に実行していることを確認できるはずです。または、Webコンソール'hawk'を使用することもできます。デフォルトのログイン資格情報は'hacluster / linux'です。

この例では、さらに2つのパラメータを微調整する必要があります。この調整がお客様の運用クラスタに適用されるかどうかは、お客様のクラスタ設定により異なります。

A.4.6 リソースの設定

「クラスタのインストール」で説明したように、このソリューションではSLE HAEで実行するコアサービスを監視するためにOCFリソースエージェントが使用されていますが、必要に応じてその代わりになるものも作成できます。また、このソフトウェアは他のいくつかのリソースに依存しています。そのために、SLE HAEにはリソースエージェントがデフォルトで使用されるようになっています。SLE HAEを使用しない場合は、何か他のテクノロジを使用して以下の追加リソースを監視する必要があります。

他にもセキュリティインテリジェンス用に使用されるMongoDBやActiveMQメッセージバスなどのリソースがあり、少なくとも現時点ではコアサービスの一部として監視されています。

サンプルソリューションでは、シンプルなファイルシステムリソースエージェントなど、必須リソースは単純なものになっています。必要であれば、cLVM(論理ボリューム対応のファイルシステム)のようなより高性能なクラスタリソースを使用することもできます。

サンプルソリューションでは、クラスタ設定に役立つようにcrmスクリプトが提供されています。スクリプトは、Sentinelインストールの途中で生成される無人セットアップファイルから必要な設定変数を取り出します。セットアップファイルを生成していない場合、またはリソースの設定を変更する場合は、それに応じてスクリプトを編集できます。

Sentinelをインストールした元のノード(Sentinelの完全インストールを実行したノード)に接続し、次のコマンドを実行します(<SHARED1>は上記の作業で作成した共有ボリューム):

mount /dev/<SHARED1> /var/opt/novell

cd /usr/lib/ocf/resource.d/novell

./install-resources.sh

クラスタ内に生成される新規リソースに問題がある可能性もあります。その場合は、node02上で/etc/rc.d/openais restartを実行します。

install-resources.shスクリプトは、2つの値、すなわち一般ユーザがSentinelにアクセスするときに使用する仮想IPおよび共有ストレージのデバイス名の入力を要求し、その後必要なクラスタリソースを自動生成します。スクリプトに指定する共有ボリュームは既にマウント済みのものでなければならないこと、およびSentinelインストール時に作成された無人インストールファイル(/tmp/install.props)も必要であることに注意してください。このスクリプトは最初にインストールを実行したノードのみで実行すればよく、必要なすべての設定ファイルは他のノードに自動的に同期されます。

お客様の環境がこのサンプルソリューションとは異なる場合は、同一ディレクトリにあるresources.cliファイルを編集し、その中のプリミティブ定義を変更してください。たとえば、サンプルソリューションではシンプルなファイルシステムリソースを使用していますが、もっとクラスタ指向のcLVMリソースを望むお客様もおられるでしょう。

シェルスクリプトを実行した後、crmステータスコマンドを実行することができます。出力は次のように表示されます。

crm status

Last updated: Thu Jul 26 16:34:34 2012
Last change: Thu Jul 26 16:28:52 2012 by hacluster via crmd on node01
Stack: openais
Current DC: node01 - partition with quorum
Version: 1.1.6-b988976485d15cb702c9307df55512d323831a5e
2 Nodes configured, 2 expected votes
5 Resources configured.

Online: [ node01, node02 ]
stonith-sbd    (stonith:external/sbd):    Started node01
 Resource Group: sentinelgrp
     sentinelip    (ocf::heartbeat:IPaddr2):    Started node01
     sentinelfs    (ocf::heartbeat:Filesystem):    Started node01
     sentineldb    (ocf::novell:pgsql):    Started node01
     sentinelserver    (ocf::novell:sentinel):    Started node01

この時点で、関係するSentinelリソースがクラスタに設定されています。クラスタ管理ツールでcrm statusを実行するなどして、リソースがどのように設定およびグループ化されているかを確認できます。

A.4.7 ネットワークストレージの設定

一連の作業の最後のステップとして、ネットワークストレージを設定して、Sentinelがイベントパーティションを低コストなストレージに移行できるようにします。このステップは省略可能です。実際、ネットワークストレージに対してシステムの他の部分に行ったのと同じように高可用性を持たせる必要はありません。NFSボリュームでも、CIFSボリュームでも、どのディレクトリでも(SANにマウントされているかどうかに係わりなく)使用可能です。

上部メニューバーの［ストレージ］をクリックしてから［環境設定］を選択し、［Network storage(ネットワークストレージ)］から未設定のネットワークストレージのラジオボタンを1つ選択してセットアップします。

サンプルソリューションでは、ネットワーク共有ストレージの場所としてシンプルなiSCSI Targetを、ローカルストレージとほぼ同じ設定で使用します。運用実装では、これとは異なるストレージテクノロジを使用することもあり得ます。

以下の手順に従って、Sentinelが使用するネットワークストレージを設定します。

サンプルソリューションでは、シンプルなファイルシステムリソースエージェントなど、必要なリソースには単純なものを使用しています。お客様のご希望によっては、cLVM(論理ボリューム対応のファイルシステム)のようなより高性能なクラスタリソースを使用することも可能です。