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

はじめに

基幹系や大規模なSORでもパブリッククラウドへの期待が高まっています。一方、全面クラウド移行するとなると移行コストやシステムの見直しでなかなかに困難が付きまとうという現状もあります。

このような場合、以下のような段階的なアプローチが有効です。

1.オンプレミスにて遠隔地へデータ複製＆可用性を担保
　　　　　　　　　　　　　　↓
2.オンプレミスからパブリッククラウドへデータ複製＆可用性を担保
　　　　　　　　　　　　　　↓
3.パブリッククラウドで全てデータ複製＆可用性を担保

本稿では1.から2.に進むための技法としてベリタスを用いた方法について紹介します。

ミドルウェアの必要性

AWSは複数のアベイラビリティーゾーン（AZ）をまたいでデータのコピーを行うことにより、独自の可用性を提供します。しかし、AWSが提供するこれらの可用性はインスタンスの内側の障害を認識しません。つまりSAPアプリケーションの障害までカバーする可用性が必要な場合、インスタンス内に Veritas InfoScale のようなクラスタ化のためのミドルウェアが必要になります。

高可用性が必要なコンポーネント

SAPアプリケーションの可用性にとってクリティカルな次のコンポーネントは関連する単一障害点を排除し、高可用性を担保する必要があります。

データベースインスタンス
セントラルサービスインスタンス
エンキューレプリケーションサーバー

アプリケーションアベイラビリティの最適化

アプリケーションが停止した場合、AWSはインスタンスを再起動するか再デプロイする必要があります。これらの実施には多くの時間を要するため、目標復旧時間（RTO）を満たせない可能性があります。また、複数のSAPアプリケーションサーバーがシステム内に構成されている場合、一部の障害がシステム全体の停止に波及しないように、個別のオペレーター介入が必要になります。

お客様は通常、OS固有のカスタムスクリプトや監視ツールを使用してアプリケーションを監視します。InfoScaleは、SAPやOracle向けに開発された監視エージェントを使用する事で、そのような複雑な実装を簡素化します。インテリジェントなフェイルオーバー機能により、顧客は待機ノードの数を減らしてAWS内のインスタンス数を最適化できます。また、InfoScaleのディザスターリカバリー（DR）ソリューションは、AWSのリージョンをまたいで実装でき、本番業務に影響を与えないDRテストも提供します。

Veritas InfoScale

Veritas InfoScaleは主要なエンタープライズオペレーティングシステムとサーバー仮想化テクノロジーで動作します。InfoScaleをAWSインスタンス内にデプロイすることはAWS 環境におけるSAPの管理および保守をスムースにします。InfoScaleは、次のエージェントを使用してこれらのソリューションを提供します。

AWSIP
AWSRoute53
SAPNW
SAPComponents

Veritas InfoScaleの構成例

次の図はVeritas InfoScale を使用して作成されたさまざまな可用性のシステム構成を示しています。

図 1 – InfoScaleの構成タイプ

SAPエコシステム向けのInfoScaleの機能

InfoScaleは次のHAおよびDR機能によりSAPエコシステムの管理に適しています。

• 監視やリカバリ自動化と障害時のアプリケーションのダウンタイムを最小化
• オンプレミスからAWSへのフェールオーバーのサポート
• 開発、テスト、本番が混在したフェイルオーバー構成による使用率の最適化
• AWS上で稼働するSAPのコスト最適化、RPO/RTO要件の順守
• 災害復旧（DR）のサポート

これには以下が含まれます。

　oオンプレミスからAWSへの切り替え
　o災害時に高可用性を達成するためのAWS向けの新しいエージェントのサポート
　oオンプレミスでサポートされているSAPエージェント

　　オンプレミスと同様の実装方針
　　AWSのインスタンス間でデータを共有するための独自のFSS
　　AWSリージョンまたはオンプレミスからAWSへのVVR

Veritas InfoScaleのレプリケーション

VVRはVxVMの堅牢性、使いやすさ、高性能性やパフォーマンスの利点を享受するとともに現在のVxVMの構成をアプリケーションにほとんど影響なく透過的にレプリケーションします。VVRは、ソースボリュームに対するアプリケーションの書き込みを任意の距離にある1つ以上のリモートの拠点にレプリケーションします。リモートサイトではアプリケーションデータの一貫したコピーを提供し、本番サイトで災害が発生した場合は、レプリケーション済みデータを使ってビジネスアプリケーションを起動します。通常、本番拠点でアプリケーションが実行されているシステムはプライマリシステムと呼ばれ、レプリケーションターゲットのシステムはセカンダリシステム（もしくは待機系）と呼ばれます。プライマリシステムのボリュームは、セカンダリシステムのボリュームと最初に同期する必要があります。 VVRとネットワークを使用してプライマリロケーションとリモートロケーション間のアプリケーションデータを同期します。

Veritas InfoScale のフレキシブルストレージシェアリング

InfoScaleのフレキシブルストレージシェアリング（FSS）機能を使用すると、分散型の高可用性ファイルシステムを実現できます。FSSはパフォーマンスや可用性を犠牲にすることなく、ダイレクトアタッチストレージ(DAS)のポテンシャルを最大限に引き出します。このテクノロジーは従来のストレージエリアネットワーク（SAN）環境の20％未満のコストで最大4倍のパフォーマンスを発揮します。さらに、FSSはDASのみの環境に限定されません。AWSのEBSボリュームとの組み合わせでも使用することができます。詳細はVeritas FSS のデータシートを参照してください。

アベイラビリティゾーン間でFSSまたはVVRを使用する際の考慮事項

•AZ間でFSSまたはVVRを使用する場合は次の点を考慮してください。FSSはアプリケーションが両方のAZのデータに同時にアクセスできるアクティブ/アクティブなアプリケーションで使用できます。 VVRでは同期および非同期のレプリケーションが可能ですが、それぞれのAZからアサインしたEBSへのアクティブ/アクティブな同時アクセスはできません。

•FSSまたはVVRの同期レプリケーションを使用する場合、データを他のAZにミラーリングまたは同期する必要があるため、アプリケーションのスループットはネットワークの性能に依存します。

•ある程度のRPOを維持しながら、高いスループットが必要なアプリケーションの場合、ベリタスはVVRの非同期レプリケーションの使用を推奨します。

•従来のSANストレージ環境とは異なり、EBSボリュームなどのAmazonブロックストレージは一度に1つのEC2インスタンスにのみ接続できます。AWSでFSSを使用することにより複数のクラスター内のノードで実行されているアプリケーションに共有ストレージ環境を提供できます。VVRはAWSのリージョン間のレプリケーションに使用可能です。

AWS環境にFSSをデプロイしてより良いパフォーマンスを実現するためのベストプラクティスのいくつかは次のとおりです。

•インスタンスでAmazon Elastic Network Adapter（ENA）の拡張ネットワーキングを有効にしてFSSのデータ複製が低レイテンシになるようにスループットと秒間パケット数(PPS)を改善します。詳細はAWSのネットワーキングについてAmazonのドキュメントを参照してください。

•EBSに最適化されたインスタンスを選択して Amazon EBS のI/O とインスタンスからの別のネットワークトラフィックの競合を最小限に抑えてEBSボリュームの最高のパフォーマンスを実現します。EBSの最適化インスタンスの詳細については、Amazonのドキュメントを参照してください。

SAP NETWEAVER 対応のInfoScaleエージェント

InfoScale のエージェントは、OracleやSAPなどの代表的なエンタープライズアプリケーションのリソースを監視します。リソースのステータスを決定し、外部イベントに従ってそれらを開始または停止します。 SAP NetWeaver 対応のInfoScale エージェント（以降、SAPNWエージェントと記述）はクラスタ環境下でSAP NetWeaver の起動・停止・監視・リカバリーを行います。エージェントはSAPインスタンスをオンライン、モニター、オフラインにします。エージェントはシステムプロセスとサーバーの状態を監視し、予期せぬ障害が発生した場合にフェイルオーバーを行います。

SAP NetWeaverエージェントは次のSAPインスタンスタイプをサポートしています。

セントラルサービスインスタンス（ASCS）
プライマリアプリケーションサーバーと追加のアプリケーションサーバー
エンキューレプリケーションサーバーインスタンス（ERS）

エージェントは、次のタイプのSAPシステムをサポートします。

ABAP
Java
アドイン (ABAP + Java)

SAPライブラリおよびVERITASコネクタスクリプトによるInfoScaleとSAP NetWeaverの統合

SAP NetWeaverエージェントにより、InfoScale をSAP NetWeaver 7.xおよびSAP Kernel 7.20 DCKと統合できます。この目的で SAP のライブラリ（saphascriptco.so）とVeritas のクラスタコネクタスクリプト（sap_symc_cluster_connector）を使用します。この統合で SAP sapstartsrvコンポーネントはSAPインスタンスのステータス変更をInfoScaleへ通達することが可能となります。InfoScale との統合は SAP NetWeaver 7.xおよびSAP Kernel 7.20 DCK以降でのみサポートされます。

典型的な InfoScale のクラスターではSAP管理者がSAPクライアントを使用してSAPインスタンスのステータスを変更するとsapcontrolやstartsapなどの動作が発生します。管理者がSAPインスタンスを停止すると、InfoScale は障害を検出し、クリーン操作を実行します。また、管理者がSAPインスタンスを起動すると InfoScale はインスタンスがその制御外でオンラインになったことを検出します。

sapstartsrvとInfoScale 間の通信を有効にする必要があります。これにより、割り当てられたSAPインスタンスを開始または停止したときに、sapstartsrvがInfoScale に通知できるようになります。 これによりInfoScale はSAPインスタンスの正しいステータスを検出します。

InfoScale の AWS IPエージェント

InfoScale はAWS IPエージェントを提供します。これによりAWSの次のネットワークリソースを監視および管理できます。

Private IP
Private IPはネットワークデバイスが相互に通信するために使用するプライベートアドレスです。
Elastic IP
Elastic IPは、ダイナミッククラウドコンピューティング用に設計された静的IPv4アドレスであり、AWSアカウントに関連付けられています。
Overlay IP
AWSではトラフィックを、サブネットまたはAZが属している仮想プライベートネットワーク（VPC）のEC2インスタンスにリダイレクトできます。Overlay IPを使用するとクラスターノードが複数のサブネットまたはAZに分散している場合、クラスターノード間でIPアドレスをリダイレクトすることでフェールオーバーを実現します。

詳細については、InfoScaleのドキュメントを参照してください。

InfoScale の AWS Route53 エージェント

Amazon Route 53は可用性が高くスケーラブルなドメインネームシステム（DNS）サービスです。 InfoScale はホスト名とIPアドレス間のマッピングを更新および監視するAWS Route53エージェントを提供します。エージェントはサブネット間でノードをフェールオーバーするときにAmazon Route 53ドメインのマッピングを行います。

ホストゾーンを作成すると Amazon Route 53 はゾーンのネームサーバー（NS）レコードとStart of Authority（SOA）レコードを自動的に作成します。フェイルオーバー中にAmazon Route 53ドメインでリソースレコードを動的に追加および削除する必要がある場合は、AWS Route53エージェントを使用する必要があります。エージェントはフェールオーバー中に新しいリソースレコードマッピングでDNSを更新し、クライアントがアプリケーションのフェールオーバーインスタンスに接続できるようにします。なお、AWSRoute53エージェントを使用したくない場合は、DNSレコードを管理するためにレガシーDNSエージェントを使用できます。

おわりに

ちょっと長くなりましたが、いきなり濃いですね！次回はAWSで設計する可用性のユースケースをご紹介します。

商談のご相談はこちら

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