目次
S/4HANAやERPなどのSAP環境をAWS上で可用性対策を行う上で何を考慮すべき点を記載します。AWS上でのSAP環境のクラスタ化を検討されている場合には、ご参考にいただければ幸いです。
SAP環境をAWS上で運用されている企業も非常に増えています。オンプレミスでは、可用性対策としてHAクラスタ化し、サーバ停止に備えることが一般的ですが、AWS上ではHAクラスタ化以外にも可用性対策を選択することができます。例えば、クラスタ化せず単一のサーバでAWS上で使用している場合も、AWSのAuto Recoveryという機能でサーバの停止を検知し、自動的に再起動することができます。AWSではクラスタ化を行わない場合も、一定レベルの可用性対策を行うことができます。
では、次のような状況を考慮されているでしょうか？
障害発生状況の考慮
・Availability Zone(AZ)の一部または全体の障害
クラスタ化などの二重化対策がなく、AZ内のサーバ障害や通信障害が発生しEC2インスタンスにアクセスできない場合、AWS社の復旧を待つ必要があります。
・EBSの消失
データベースのEBSを消失すると、DBリストアとログ適用等が必要となり、復旧までに長時間必要となります。
・EC2インスタンス売り切れ
AZ障害時AMIから他のAZにサーバを復旧する計画としていた場合、EC2インスタンスの売り切れを考慮する必要があります。また、Auto Recovery時に再起動用のEC2インスタンスが売り切れていた場合、リカバリが失敗する場合があります。
・障害発生時の切り替え対応
実際に障害が発生し、サーバの切り替えやリストア作業を行う曜日や時間帯はいつを想定されていますか？夜間に発生した場合は、対応開始までに復旧体制が整うまでに時間がかかリます。
上記のようなことを想定で、障害発生から復旧まで想定時間が許容できない場合、マルチAZでサービスとデータを保護し、自動復旧のためHAクラスタ化を検討する必要があります。
マルチAZでのSAP クラスタ実装
マルチAZでのSAP環境のHAクラスタは、次のようなサーバ配置とレプリケーション等によるデータの保護が必要となります。この際、ディスクのレプリケーションにDataKeeper、DBのレプリケーションは各DBの機能、クラスタはWSFCやLifeKeeper、Pacemakerなどを使用します。
技術的な考慮事項
マルチAZ環境でSAP環境をクラスタ化する場合、実際に運用することを想定すると次のような考慮が必要となります。もちろん費用面の考慮も必要ですが。
データの同期と性能
プライマリ側の障害が発生した場合、最新のデータまでの復旧が必要な場合、データベースはプライマリとセカンダリで完全に同期する必要があります。(一般的にERP環境は複数システムとインターフェイス整合性などの理由により、直近データまでの復旧要件が高くなっています。)
データベース・レプリケーションを同期モードとしている場合、更新トランザクションは、DBサーバのプライマリからDBサーバのセカンダリへのトランザクションログの同期を待ってから、更新処理が行われます。AZ間は高帯域幅、低レイテンシーのネットワーキングで相互接続されていますが、それぞれ他の AZ から物理的に意味のある距離(数km～100km)離れています。これにより、同期モードでの更新による処理時間のオーバヘッドが増加します。AZ内のサーバと、AZ間のサーバでのpingを取得してみると一回あたりの遅延の目安がわかるかと思います。
オンライン処理では、このような遅延はあまり気にならない場合が多いですが、時間の限られた夜間バッチでのデータ一括取り込みやデータの洗い替えで、数千、数万件を更新する場合、同期処理による遅延時間が数千倍、数万倍に積み重なることになります。夜間バッチの時間帯を超過するなどの影響が想定されます。
対策としては、バッチ処理の並列化を増やすなどを行い、データ同期の遅延時間の合計をバッチ全体に影響しないようにする必要があります。
IPアドレスと接続性
マルチAZ間では、ネットワーク・サブネットが異なり、同一のIPアドレスを使用することができません。ERP環境は、ユーザからのアクセスだけでなく、他システムとの連携やジョブ管理サーバとの連携があります。マルチAZのクラスタを構築した場合、クラスタ化されたサービス間では異なるIPアドレスを使用することになります。例えば、SAP環境が異なるAZにフェイルオーバした場合、ユーザ・アクセスはDNSサーバのエントリ変更により切り替えることができます。ただし、システム間連携を行っている他のサーバからの通信には同一のIPアドレスが必要となる場合が多くあります。(ジョブ管理ツールやファイル転送ツールに対して、SAP環境のIPアドレス変更を反映させる場合、一般的にツールの再起動が必要となります。)
同一VPC内からのサーバから連携を行う場合のみですが、RouteTableシナリオと呼ばれる方法を使用し、固定IPアドレスを使用することができます。
SAP環境で多く使用されるWindows環境では、RouteTableシナリオの実装方法を調べてみましたが、サンプルコード等を探すことができませんでした。この実装をWindowsのクラスタと組み合わせるには、クラスタ組み込みのスクリプトを作成する必要があります。
オンプレミスやVPC外のサーバから通信を行う場合、SAP環境が異なるAZにフェイルオーバした場合には、フェイルオーバ前のIPアドレスを使用することができません。この場合、一度ジョブ管理ツールなどを停止し、DNSサーバからIPアドレスを再検索後、ツールを起動するような対応が必要となります。
上記の動きの説明
①他システムからAWSのルートテーブルに定義されたIPアドレス:aにアクセスする。
②ルートテーブルでは、IPアドレス:aのルーティング先をASCSプライマリと定義しており、ASCSプライマリに通信することができる。
まとめ
SAP環境のマルチAZでの運用を考えると、性能面や切り替えの運用等を考慮すべきことが多くあります。障害発生からの復旧時間短縮・直近までの復旧が必要な場合データベースの同期レプリケーションが必要となり、性能面でバッチ構成やプログラムの見直しの可能性があります。性能面を考えると非同期レプリケーションも考えられますが、直近までの復旧ができない場合、リカバリ処理が複雑になります。基本としてマルチAZ構成でデータベースの同期レプリケーション運用で検討・検証した上で、性能面等の課題に対処すべきと考えます。
この記事をシェアする
