目次
Introduction
昨年の春にAmazon Web Services(AWS)でWindows Failoverクラスタ(WSFC)を構築方式として、サードベンダー製品（SoftNAS）を使って共有ストレージを作成することでWSFCクラスター環境を実現する方法をご紹介しておりました。
また、今年の春にSAP環境としてWindows 2016 が正式サポートされたこともあり、Windows 2016標準機能の記憶域レプリカによるデータ複製とWSFCを組み合わせたクラスター環境は構築はできるのか？についての実験記事も掲載しておりました。
今回は、サードベンダー製品としてSIOS DataKeeper for Windows Cluster Editionを使ってリアルタイムレプリケーション（複製）機能とWSFCのフェイルオーバー機能を組み合わせたクラスター環境を構築します。ちなみに、今回の実装パターンはSAP環境として正式サポートされているのが、SoftNAS案との大きな違いです。
それでは今回作成するシステムのイメージを確認しましょう。
典型的なWSFC環境としてまず思い浮かぶイメージは左の絵で、ノードAからノードBにフェイルオーバー時には、ノードの切り替えと共有ストレージの付け替えをWSFCにて制御しています。今回作成するのは右の絵、つまりノードの切り替えはWSFCに任せますが、共有ストレージは存在せず予め常時データ複製していたストレージ上のデータを使ってノードB上でSAPが起動します。本構成ことをSANLess Clusters と呼ぶ所以は、ストレージ周りの可用性実装の違いによります。
今回はAWS上でSAP NetWeaver 7.5(ABAP)環境を、WSFCによるMulti-AZ構成即ち異なる２つのAZ跨がった2台クラスター構成による冗長化を実装します。
今回の動作検証は平たく言うとDBサーバではなく、APサーバに相当する部分です。WSFC構成のAPサーバはそもそも特殊な構成を取ることもあり、BASISコンサルの方にとっては結構有用ですが、ユーザー様は少し違和感があるかと思います。DBサーバの部分は技術的には逆にシンプルで、次回以降で掲載予定です。
参考：
SIOS LifeKeeperという製品がありますが、こちらはノードのフェイルオーバー機能を提供するものであり、DataKeeperとは目的、提供する機能とも異なります。
システム構成
WSFC構成ということで、Active Directoryに参加した環境での検証を行いました。仮想ホスト名（サービス名）の名前解決では、Active Directoryを利用しています。CDPは下図の通りです。
環境構築
主な作業工程
構成の整理が事前にできていれば、それほど難しくありません。
１．EC2インスタンスの作成
２．SAPの要件に合わせて環境設定（WSFCの機能追加も）
３．DataKeeper Cluster Editionのインストール
４．SQL Serverのインストール
５．SAPインスタンス First Cluster Nodeのインストール
６．SAPインスタンス Database Instanceのインストール
７．SAPインスタンス Additional Cluster Nodeのインストール
８．SAPインスタンス Primary Application Server Instanceのインストール
９．SAPインスタンス Additional Application Server Instanceのインストール
構築時のポイント
上記の工程ごとにポイントをまとめてみました。
工程１．EC2インスタンスの作成
WSFCのサービス用IPをEC2インスタンスに割り当てます。
今回はセカンダリプライベートIPとして割り当てています。
工程２．SAPの要件に合わせて環境設定（WSFCの機能追加も）
OSのネットワーク設定でIPv6を無効化しても、WSFCで利用するIPは標準でIPv6が利用されています。
IPv6を利用する構成かIPv4のみの構成かネットワーク構成を統一する必要があります。今回はIPv6を無効化した環境としています。（IPv6構成の場合はSAP Note 1759048を参照下さい）
regeditにて以下を登録します。
\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
名前：DisabledComponents
種類： REG_DWORD
データ：0x000000ff
工程３．DataKeeper Cluster Editionのインストール
インストール及び設定自体は非常に簡単ですが、画面で説明します。
準備したインストーラを管理者で実行します。
下記画面で少し待ちます。
インストールを進めるので「Next」をクリックします。
ライセンス要件を確認して「Yes」をクリックします。
デフォルトで全てにチェックが付いていることを確認して「Next」をクリックします。
今回はインストールパスの変更はしないので、「Next」をクリックします。
構成変更は実施するので「はい」をクリックします。
推奨のドメインユーザを準備しているので「Next」をクリックします。
「サービスユーザの権限はドメイン内の接続されたすべてのサーバで有効な、管理者権限を持つドメインアカウント (推奨)」ということで、対象サーバのAdministratorsグループに参加します。
ドメインユーザおよびパスワードを入力し「Next」をクリックします。
ライセンスファイルを指定して、ライセンスをインストールします。
インストールが終わったので「Yes」をクリックして再起動します。
同様の手順にて、同期する全てのサーバにインストールします。
以降はインストール後の設定になりますが、サービスに接続後、ジョブを作成して終わりです。
DataKeeperを起動して、「Connect to Server」をクリックします。
ServerにDataKeeperをインストール済みのホスト名を入力して「Connect」をクリックします。
「Create job」をクリックします。
任意のJob nameとJob descriptionを入力し、「Create Job」をクリックします。
同期元となるServerを指定します。
リストに表示されていない場合は「Connect to Server」でServerを追加します。
Serverに追加するホスト名を入力して「Connect」をクリックします。
ServerとIP addressを確認し、Volumeに同期元となるEBSのドライブレターを指定し「Next」をクリックします。
Serverに同期先のホスト名を指定し、IP addressを確認します。
Volumeに同期先となるEBSのドライブレターを指定し「Next」をクリックします。
任意の圧縮レベルを指定します。
同期設定では共有ディスクとして利用するため「Synchronous」を指定し「Done」をクリックします。
ポップアップで作成したJOBをWSFCのディスクに自動登録するか確認がでるので、「はい」をクリックします。
Jobsのツリーに作成したジョブが正常に登録されたことを確認します。
これでDataKeeperの設定は完了です。
フェールオーバー クラスター マネージャーのディスクにも正常にDataKeeperのVolumeが追加されていることを確認できます。
工程４．SQL Serverのインストール
今回は、SQL Serverをクラスタ構成ではなく、シングル構成にてインストールします。今回は実施していませんが、SQL ServerもDataKeeperを使用しクラスタ構成にできます。
工程５．SAPインスタンス First Cluster Nodeのインストール
SAPのインストールツール(SWPM)で、WSFCクラスタ構成としてASCSのインストールを行います。このASCSは、SAPシステムの中で、SPOF(Single Point of Failure)となる部分であり、WSFCでの保護対象としています。
仮想ホスト名(SAP Virtual Instance Host)にSWTYO-ASCSを設定し、SAP製品のクラスタ環境インストール先(Destination Driver for Clusterd Instances)としてDataKeeper Volume Dを設定しています。
工程６．SAPインスタンス Database Instanceのインストール
SQL Serverをインストールしたサーバ上で、SAP用のデータベースの設定などのため、SAPインストールツールからDatabase Instanceのインストールを行います。
工程７．SAPインスタンス Additional Cluster Nodeのインストール
インストール前にWSFCのサービス用IPを割り当てます。
WSFCの設定後、SAPのインストールツールで、追加のクラスタノード(Additional Cluster Node)として、ASCSをインストールします。
工程８．SAPインスタンス Primary Application Server Instanceのインストール
アプリケーションサーバのインストールを行います。工程9で2台目のアプリケーションサーバをインストールすることで、アプリケーションサーバを冗長構成とします。
工程９．SAPインスタンス Additional Application Server Instanceのインストール
2台目のアプリケーションサーバのインストールを行います。ユーザからのログインやバックグラウンドジョブは、2台のアプリケーションサーバに振り分けられ、処理が行われます。
WSFC動作の調整
Failover時に正常に切り替わるようにするために、WSFCの設定を調整します。
今回の環境では切替に必要な時間がポイントで、再起動の試行回数、再起動の遅延を設定しています。
再起動期間：15:00
再起動の試行回数：10
再起動の遅延：5.0
AWSインスタンスを停止して、Failoverのテストを行ったところSAP BN2 Service(OS上のASCS用サービス)の起動には、2分くらいの時間が必要でした。
共有（\\SWTYO-ASCS\sapmnt）を利用したプロファイルを認識するまでに5秒遅延の再試行を7回くらいで起動しています。（初回の起動が失敗するまでには1分くらい必要で、その後は起動直後にエラーを繰り返します）
このあたりの調整は、環境に合わせて設定が必要となりそうです。
Failoverでの注意点
オンプレミスでのWSFC構成では、通常Failover後も同一IPアドレスになるかと思います。IPアドレスの変更がなければFailover時にERSを利用することでエンキューの継続性があります。
今回のようなMulti-AZ冗長化構成ではサブネットが異なるためFailover時にIPアドレスが変わります。Failover時にPASやAASといったAPサーバの持っているIPアドレスが直ぐには書き換わらないため、ASCSに接続できずにエラーとなりました。Failover発生から10分程度でdisp+workが再起動され、自動的にASCSへ再接続されるのですが実行中の処理はエラーとなります。
AZ障害などを想定した場合には、そのAZに存在するAPサーバも停止し、またDBサーバの切り替えなども発生するため、10分程度で切り替わるのであれば、可用性としては十分といえるのではないでしょうか？
AWS上でもSingle-AZ内で冗長構成を組む場合は、同一サブネット内にて構築することが可能となります。ただしAWSの場合、仮想IPへのルーティングのためEC2のNICに仮想IPアドレスを割り当てる必要があります。よってFailoverの際は、EC２のNICの割りあて変更などの処理を追加する必要となります。今回は未検証なので机上の推論となりますが、この方法をとれば、FailoverしてもIPアドレスは同一となるためエンキューの継続性を保つ事が可能となると推察されます。本内容については別途検証後、報告いたします。
EC2障害における短時間復旧を優先させる場合は、Single－AZ内に同一IPアドレスで構築した方が良く、AZ障害が発生した場合でも早期復旧を目指すのであれば、今回のようなMulti-AZで構築した方が良いと言えます。このあたりは何を脅威として考えるかによって構成が変わってくるところになります。
- カテゴリー
この記事をシェアする
