AWSで設計する SAP NetWeaver 可用性と災害対策その２

8700 ワード

EC2 AWS SAP InfoScale Veritas AWS テキストリンク

はじめに

前項（その１）ではSAPで可用性を担保しなければならないコンポーネントと概要、そしてVeritas InfoScale の役割について紹介しました。ベリタスの災害対策モデルを使って手堅くクラウド移行を実現することでミッションクリティカルなシステムを安心してパブリッククラウドへ移行することが可能ですし、全てのコンポーネントをAWSで構成する場合もベリタスは安心して業務が継続できるシナリオをご用意しています。

サポートされる構成例は？

InfoScale は次のシナリオでSAP NetWeaverベースのアプリケーションインスタンスを監視および制御できます。

•１つのAZにすべてのSAPインスタンスを構成するケース
•複数のAZで構成するSAPインスタンスを構成するケース
•InfoScale エージェントを使用した SAP Web Dispatcher HA 構成
•SAPインスタンスのオンプレミスからAWSへのフェールオーバー
•クロスリージョンで構成するSAP on AWS

AWSにすべてのSAPインスタンスを構成する場合

この場合、2つのEC2インスタンスがそれぞれSAPスタンドアロンエンキューサーバーとSAPエンキュー複製サーバー用に構成されています。SAPセントラルサービスインスタンス（メッセージまたはエンキュー）に障害が発生するとSAPNWエージェントはレプリケーションサーバーに切り替えます。フェイルオーバーシナリオはSAPの高可用性認定ガイドラインに従って機能します。

InfoScale SAPNWエージェントはエンキューサーバーおよびエンキューレプリケーションサーバーの以下のフェイルオーバーシナリオを実現します。

1つのAZで構成されたSAPアプリケーションインスタンスの場合

仮想ホスト名を使用してSAP Central Serviceインスタンスをインストールおよび構成し、仮想ホスト名が他のすべてのSAPインスタンスホストから解決できることを確認します。

この場合、エンキューサーバーとエンキュー複製サーバーのインスタンスは同じAZに存在します。エンキューまたはレプリケーションパラメータをTRUE（enque / server / replication = true）に設定すると、すべてのエンキューロックがエンキューサーバーにレプリケートされ、レプリケーションサーバーで使用可能になります。エンキューサーバーのインスタンスが失敗するか、利用できなくなると、SAPNWエージェントは障害を検出し、エンキューサーバーのエンキューレプリケーションサーバーノードへのフェイルオーバーを自動的にトリガします。結果、エンキューレプリケーションサーバーはエンキューサーバーに変換されます。

図-2(左)、図-3（右）です。具体的には左側でSAP A(SCS)インスタンスに障害が発生し、右側のようにフェールオーバー後にエンキューレプリケーションサーバーがエンキューサーバーに変換されます。

障害がクリアされてフェールバックが完了すると、エンキューレプリケーションサーバーはエンキューサーバーからエンキューロックのレプリケートを開始します。

複数のAZで構成された SAP アプリケーションインスタンス

このユースケースではSAP エンキューおよび SAP エンキューレプリケーションインスタンスは、最初にアベイラビリティーゾーン1で実行されます。SAP ダイアログと SAP データベースインスタンスは同じ AZ 内にあるか、複数の AZ に分散されています。

図 4 – FSSでディスクストレージをアクティブ/アクティブで同期させた複数のアベイラビリティーゾーンのSAP フェールオーバー

SAP エンキューサーバーに障害が発生すると、SAPNW エージェントは自動的にエンキューレプリケーションサーバーにフェイルオーバーさせ、レプリケートされたエンキューロックをエンキューレプリケーションサーバーからロードします。この場合、InfoScale のAWS IP および IP エージェントは仮想 IP のフェールオーバーを行います。

図 5 –　マルチAZでのエンキューサーバーのフェールオーバーが完了

次の図はエンキューレプリケーションサーバーがアクティブで、エンキュートランザクションロックがAZの2にレプリケートされていることを示しています。

図 6 - AZ2 にレプリケートされたエンキュートランザクションロック

障害が発生した状態がクリアされ、以前のエンキュー (ASCS) サーバーでメンテナンスが完了したら、前のエンキューサーバーでエンキューレプリケーションサーバーを再起動できます。SAPNW および SAPComponents エージェントを使用して、エンキュートランザクションロックを失うことなく、AZ間でエンキューレプリケーションインスタンスを切り替えることができます。InfoScaleは、SAP データベースおよび SAP ダイアログインスタンスの単一障害点を排除します。詳細については、InfoScale のマニュアル「Cluster Server Agent for SAP NetWeaver Installation and Configuration Guide」をご覧ください。

InfoScaleエージェントを使用した SAP WEB Dispatcher HA

SAPComponents エージェントと AWS Route53 エージェントは連携してAZ全体で SAP Web ディスパッチャーインスタンスを監視および制御します。このユースケースではSAP Web ディスパッチャーはエラスティックIP ではなくプライベートIP で設定および管理されます。仮想 IPは異なるAZで同じホスト名にカスタマイズされます。

SAP Web ディスパッチャーが AZ で使用できなくなった場合、SAPComponents エージェントは同じ仮想ホスト名を使用して別の AZ にフェールオーバーします。このシナリオではクライアントはAZ 間で同じホスト名で接続することができ、これは AWS Route53 エージェントによって管理されます。

次の図は複数のAZにまたがる一般的な SAP の構成パターンです。SAP Web ディスパッチャーインスタンスはAZ 1 でアクティブであり、AZ 2ではスタンバイです。

図 7 - 複数のAZにまたがる SAP 構成

次の図はSAPComponents エージェントが障害を検出し、インスタンスを別の AZ にフェールオーバーする準備ができていることを示しています。

図 8 – SAP Webディスパッチャーのフェールオーバー

次の図はSAP Web ディスパッチャーがアベイラビリティーゾーン 2 にフェールオーバーしたことを示しています。AWS　Route53 エージェントはフェールオーバーポリシーに従い、Web ディスパッチャーホスト名の DNS レコードを変更します。これにより、Web ベースのクライアントの接続が容易になります。

図 9 – AWS　Route53 エージェントのフェールオーバー

オンプレミスのSAPから AWS へのフェールオーバー

このユースケースは、すべての SAP アプリケーションインスタンスをプライマリサイトとしてオンプレミスに構成しています。 sapmnt、トランス、データベース・データ・ボリューム、ログ・ボリュームなどの共有ディスクコンポーネントは InfoScale CFS で構成されます。VVR はサイト間でのデータのレプリケーションを管理します。AWS (セカンダリサイト) では、ストレージボリュームは Amazon EBS に割り当てられ、冗長化を実現するために FSS を使用しています。次の図はVVR によるオンプレミスと AWS の間のレプリケーションを使った DR のシナリオを示しています。

図 10 – 本番サイトからAWSへのDRを実現するためのプリケーション

プライマリサイトで障害が発生するとすべての SAP アプリケーションインスタンスとデータベースインスタンスが AWS にフェイルオーバーされます。なお、障害発生時でなくても、手動でAWSに切り替えることも可能です。AWS IP および AWS Route53 エージェントはAWS で仮想 IP と仮想ホスト名を管理します。次の図はフェールオーバー後の環境を示しています。

図 11 – DR フェールオーバー後のAZでの起動

オンプレミスと AWS 間での DR の設定
オンプレミスサイトと AWS間で DR 環境を構成する為のステップは、以下のようになります。
1. オンプレミスと AWSを接続する VPN を構成します。
2. クラスタを構成する全てのシステムに Veritas InfoScaleをインストールしてセットアップします。具体的な手順については、Veritas InfoScale のインストールガイドを参照してください。
3. SAP の推奨するLUNを割り当て、VxVMおよびVxFSのコマンドを使用してCFSディスクグループとボリュームを作成します。
4. SAP のデータ領域様に次のファイルシステムをオンプレ上の稼働系システムでマウントします。

/sapmnt/<SID>
/usr/sap/trans
/usr/sap/<SID>/ASCSxx
/usr/sap/<SID>/ERSxx
/usr/sap/<SID>/DVEBMGSxx
/usr/sap/<SID>/Dxx

5.オンプレミスのシステムに SAP関連コンポーネントをインストールしてセットアップします。ERP、CRM、SCM、SRMなどのSAPアプリケーションを実行できる事を確認します。SAP NetWeaver の導入時には、次のように仮想ホスト名を使用して高可用性オプションを選択する必要があります。

SAPINST_USE_HOSTNAME=<virtual_host_name>

個々のインスタンスが異なるホスト名で構成されていることを確認し、仮想ホスト名を用いることを確認します。

オンプレミスと AWS 間のレプリケーションを構成します。データセンターから AWS までのレプリケーションに必要なすべてのポートが有効になっていることを確認します。具体的な手順については Veritas InfoScale Replication Administrator's Guideを参照してください。
次のような次の環境を準備します。

a. Amazon EC2 インスタンスを作成します。
b. 必要な SSD または標準の Amazon EBS ボリュームを接続します。
c. VxVM/VxFS および FSSを使用してディスクグループとボリュームを構成します。
d. 異なるEC2 インスタンスの EBS ボリューム間のデータ共有のために FSS を設定します。
e. すべての SAP 共有ボリュームと SAP データベースボリュームをマウントします。

具体的な手順についてはStorage Foundation Cluster File System High Availability 管理者ガイドを参照してください。ベリタスは、AWS で SAP NetWeaver の設定を確認するために次の EBS ボリュームタイプをテストしています。

• gp2 (SSD)
• Standard (magnetic disks)

※FSS はすべての EBS ボリュームタイプをサポートします

SAP アプリケーションインスタンス、AWS IP エージェント、および AWS Route53 エージェントの InfoScale クラスターサービスグループとリソースを設定します。
最初はオンプレミスのデータセンターで SAP に関連するコンポーネント全体をオンラインにします。
初期データ同期が完了し、VVR が AWS (セカンダリサイト) にデータのレプリケートを開始したことを確認します。

AWSリージョン間をフェールオーバーするSAP

AWSの異なるリージョンを跨ってのフェールオーバーシナリオは、オンプレミスと AWS の間のフェールオーバーシナリオと同等です。したがって、AWS リージョン間でのフェールオーバーを同様に設定し、データのレプリケーションと冗長化に VVR を使用することもできます。これによりアクティブなサイト (リージョン) で障害が発生した場合に、より優れた RPO と RTO を実現できます。引き続き FSS を使用してAWS リージョン内のストレージを管理します。

おわりに

いかがでしたでしょうか。ちょっと長かったですね。５つのユースケースについてご理解いただけたでしょうか。次回はインスタンスの最適化と実際のコードスニペットについてお送りします。前置きが長い！

商談のご相談はこちら

本稿からのお問合せをご記入の際には「コメント/通信欄」に#GWCのタグを必ずご記入ください。
ご記入いただきました内容はベリタスのプライバシーポリシーに従って管理されます。

Author And Source

この問題について(AWSで設計する SAP NetWeaver 可用性と災害対策その２), 我々は、より多くの情報をここで見つけました https://qiita.com/vxse_japan/items/4763be40357dc0cbc5d4

著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。

Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .