Step 10: 2台目のクラスターノードのインストール

最初のクラスターノードのインストールは、それほど苦労せずに完了しました。すべてのクラスターノードが同じサブネット内に存在する通常のクラスターでは、2 番目のクラスターノードのインストールも同様にスムーズに実行されます。ただし、これはAWSであり、ノードは異なるサブネットに存在するため、マルチサブネットクラスター固有の要件に対処するにはいくつかの手順が必要です。

DNSのアップデート

先に進む前に、前に作成したAレコードを修正する必要があります。最初のSAPノードを適切に作成するには、これらのAレコードを作成する必要がありました。ただし、DNS内のこれらのAレコードは“static”であることがわかります。静的レコードは、マルチサブネットクラスターで必要となるWSFCでは更新できません。

WSFCマネージャーがAレコードを動的レコードとして再登録できるように、DNSからAレコードを削除します。先ほど作成した2つのAレコードをそれぞれ右クリックし、削除します。

WSFC Managerで、2つのクラスターグループのそれぞれで2つのネームリソースをオフラインにしてから、リソースをオンラインに戻します。このプロセスにより、2 つのAレコードがDNSに再登録されます。今回はダイナミックレコードになります。

DNSゾーンを更新すると、次のようになります。

TTLの変更

デフォルトでは、これらの各AレコードのTTL (time to live)は20分です。これは、クライアントがフェイルオーバー後に新しいIPアドレスを受け取るのを待つには長すぎます。代わりにTTLを15秒に調整します。

クラスターネームリソースのTTLを調整するには、ネームリソースごとに次のPowerShellコマンドを1回実行します。このコマンドは、どちらのクラスターノードからも実行できます。

Get-ClusterResource -Name “SAP DAB ERS NetName” | Set-ClusterParameter -Name HostRecordTTL -Value 15

Get-ClusterResource -Name “SAP DAB NetName” | Set-ClusterParameter -Name HostRecordTTL -Value 15

RegisterAllProvidersIP を変更する

マルチサブネットクラスターは、いくつかの方法でクライアントのリダイレクトを処理できます。違いについて説明することは、この記事の範囲を超えています。 SAPクライアントのリダイレクトを処理するには、各クラスターネームリソースのRegisterAllProvidersIPプロパティが0に設定されていることを確認する必要があります。各クラスターノードで次のPowerShellコマンドを実行します。

Get-ClusterResource -Name “SAP DAB ERS NetName” | Set-ClusterParameter RegisterAllProvidersIP 0

Get-ClusterResource -Name “SAP DAB NetName” | Set-ClusterParameter RegisterAllProvidersIP 0

最後の2つのセクションで加えた変更が確実に適用されるように、クラスターリソースの両方をオフラインにして再びオンラインにすることが重要です。

マルチサブネットクラスターをサポートするためのIPアドレスリソースの追加

SQL Serverなどのアプリケーションのクラスターを構成する場合、インストーラーはクラスターがマルチサブネットクラスターであることを認識します。ただし、SAPインストーラーはその事実を 認識しない ため、一部の構成手順を手動で実行する必要があります。それらの手順の1つは、セカンダリーノードのサブネットに存在するクラスターIPアドレスリソースを作成することです。手順は次のとおりです。

IPリソースを作成する
IPアドレスを割り当てる
「OR」の依存関係を作成する

以下のスクリーンショットに従って、2つのクラスターリソースグループの、それぞれのクラスターノードの1つでこれらの手順を完了します。

新しいIPアドレスを追加します。

IPアドレスを設定して、セカンダリーノードのネットワークに関連付けます。この記事の上部で構成した未使用のセカンダリアドレスの 1 つを指定します。

「OR」機能を使用して、サーバーネームリソースをこの追加のIPアドレスに依存させます。

以下に示すように、他のサーバーネームリソースに対しても同じプロセスを実行します。

これらのアドレスがオフラインになっているのは通常のことです。クラスターのワークロードがそのサブネットで実行されている場合にのみオンラインになります。

クラスターリソースの再起動ポリシーの変更

場合によっては スイッチオーバーまたはフェイルオーバー時にSAP ASCSサービスの開始に失敗することがあります。これが最も頻繁に発生する理由は、サービスが使用可能になるためにクラスター化されたファイル共有に依存しているためです。TTLを15秒に設定すると、ASCSサービスが開始しようとする前にファイル共有が利用できないことが時々確認されています。この問題が発生すると、オンラインに接続できなくなります。通常、障害後にリソースを再度オンラインにするだけで問題は解決します。ただし、これにはユーザーの介入が必要であり、フェイルオーバークラスタリングの目的が無効になります。

この問題の修正は、ファイルサーバーリソースのIPがまだ利用できない場合に、ASCSサービスリソースの最大再起動回数プロパティと再起動間の遅延プロパティを調整して、ASCSサービスがオンラインになるまでの時間を少し与えることです。以下に示す設定は、十分すぎる設定のサンプルです。大規模で複雑な DNS 環境がある場合は、環境のニーズを満たすためにこれらのパラメーターを増やしてください。

再接続に影響を与える可能性のあるもう1つのパラメーターはTTLです。 15秒早く設定しました。ただし、DNSゾーンの更新に時間がかかる大規模なAD環境がある場合は、TTLをさらに減らすか、より多くの再起動試行を許可して再起動間の遅延を増やす必要がある場合があります。