Amazon Web Services ブログ
【SAP監視もAmazon CloudWatchでOK】SAPアプリケーション＆SAP HANAクラスタ
背景
AWS上でSAPを実行している5000以上のアクティブなお客様がおり、ワークロードは多様なSAPのリリースやバージョンで実行されています。ほとんどのお客様は、1台以上のアプリケーションサーバとデータベースで構成されたSAP NetWeaverベースの環境で作業を行っています。アプリケーションとデータベースの高可用性を実現するためのベストプラクティスは、オペレーティングシステムのクラスタリングを活用することです。クラスタリソースの可用性は、アプリケーションとデータベースの復元性を保証します。
このブログ/ドキュメントでは、Amazon CloudWatchのメトリクスとダッシュボードに基づいて、SAPアプリケーションクラスタ、HANAデータベースクラスタ、HANAレプリケーション、SAPアプリケーションコアサービスを監視する手法について説明しています。この手法により、お客様はサーバーやエージェントの導入や管理を行うことなく、低コストでSAP NetWeaverやデータベースクラスタ環境を効果的に監視することができます。このソリューションは、数分以内にシームレスに展開することができます。Amazon CloudWatchのカスタムメトリック機能を利用しています。これにより、クラスタリソースのステータスデータなど独自のメトリックを簡単に公開し、CloudWatchでしきい値やアラームを作成することができます。そして、アラームはAmazon SNSを使用して通知メールをトリガーします。
アーキテクチャ
このアーキテクチャでは、AWS CloudWatch Customのメトリクスを使用してSAPアプリケーション、SAPクラスタ、SAP HANAデータベースのコアサービスを監視するためのAWSサービスの展開を説明しています。
アーキテクチャはAWS CloudFormationテンプレートで展開しています。生成されたAmazon CloudWatchルールは、1分ごとにSSMドキュメントを呼び出します。SSMは対象のクラスタノード上でコマンドを実行し、クラスタのヘルスチェックデータをAmazon CloudWatchにプッシュします。アラームはカスタムメトリクスに設定して、しきい値の違反時に通知を生成することができます。
クラスタリソースは、開始状態を監視します。そこから逸脱した場合は、SNSの通知がトリガーされます。SAPアプリケーションクラスタの一部として、Stonith、ファイルシステム、SAPインスタンス、オーバーレイIPのステータスが監視されます。HANAクラスタの場合は、Stonith、HANAトポロジー、オーバーレイIPのステータスを監視します。
PAS / AASアプリケーションホストでは、SAPディスパッチャの状態を監視しています。ディスパッチャプロセスは、実行中のステータスを監視しています。メモリ使用率、SAPホスト上のディスク使用率、HANAデータベースのような追加のカスタムメトリクスも監視されます。
Amazon SNS通知は、Amazon CloudWatchアラームに基づいてアラートを受信するように設定することができます。
インスタンスの前提条件
インスタンスはSSMエージェントが動作していて、PutMetricDataポリシーを持つロールと、適切なリージョン情報を持つconfig(aws configure)ファイルを持っている必要があります。
モニタリングの設定
監視設定は、PAS/ASSホスト、HANAクラスタノード、SAP ASCS、SAP ERSホストのインスタンスIDをSAP SIDと一緒にキー入力するだけの簡単な作業です。
このリンクからCloudFormationテンプレートにアクセスし、ユーザーのS3バケットにコピーすることができます。モニタリングのセットアップは、monitor.yamlのS3オブジェクトのURLを使用してCloudFormationスタックを作成して開始することができます。
CloudFormationテンプレートは、SAP PASの可用性に加えて、HANAとSAPの両方のクラスタリソースの監視を設定することができます。このテンプレートでは、SAP SIDを名前にしてカスタム・ダッシュボードを作成します。カスタム・ダッシュボードは、監視セットアップの一部として監視するメトリクスのウィジェットで構成されています。ウィジェットには、SAP Application と HANA データベースクラスタの両方のクラスタリソースのステータス、HANA レプリケーションのステータス、SAP プライマリまたはセカンダリのアプリケーションリソース（ディスパッチャ、ICM、IGS、ゲートウェイ）、ディスク使用量、メモリ使用量などのリアルタイムのメトリクスが表示されます。
モニタリングをデプロイするためにCloudFormationの一部として必要なパラメータ
CloudFormation テンプレートの実行が成功すると、Amazon CloudWatch イベントルールが作成されます。このルールはそれぞれのホスト上でSSMドキュメントを実行し、クラスタリソースの状態を監視します。 各リソースのステータスは、実行中のリソース数に基づいてカスタムメトリックとしてAmazon CloudWatchダッシュボードにプッシュされます。例えば、カスタムメトリックのダッシュボードでは、クラスタごとに1つのstonithが1として表示されます。
ダッシュボードには、CloudWatchのカスタムメトリクスを使用して監視されているすべてのコアサービスが表示されます。
HANAクラスタ、SAPクラスタ、SAP Availabilityウィジェットを読む
クラスタ監視データは、HANAクラスタの両ノードを介して、ホストごとに2つの別々のウィジェットとして提供されます。HANAクラスタには3つの重要なリソースがあります。スプリットブレインの状況に対応する1つのSTONITH、1つのオーバーレイIPアドレス、そしてHANAサービスに対応する1つのクローンセットです。 時系列ベースのグラフでは、これらのメトリクスがお互いにラップしている様子を示しています。グラフにカーソルを合わせると、リソースの状態を表示できます。値1は、アクティブな状態に相当するリソースの可用性を示します。非アクティブなリソースの値は0です。
ウィジェットは監視しているHANAクラスタリソースを表し、プライマリとセカンダリのHANAノードの両方を介してアクティブなオーバーレイIP、AWS Stonith、HANAクローンセットリソースを表示します。
監視設定では、HANAシステムレプリケーションのステータスもキャプチャします。ウィジェットの値が1の場合、レプリケーションがアクティブであることを示しています。
ウィジェットは、クラスタの一部であるHANAデータベースサーバであるデータのレプリケーションの状態を表示します。
SAPクラスタリソース監視の一環として、両方のクラスタノードから同じデータがダッシュボードに供給されます。 SAPクラスタには、スプリットブレイン状況を処理するための1つのStonith、2つのSAPインスタンスリソース、2つのSAPファイルマウントポイント、2つのオーバーレイIPアドレス（ASCSとERSそれぞれ1つ）の4つの主要なリソースがあります。ウィジェットの値は、アクティブなリソースを示しています。 値が2の場合、オーバーレイIP、マウントポイント、SAPインスタンスの両方がアクティブであることを示します。 stonith の値が 1 の場合は、クラスタの一部として stonith がアクティブであることを示しています。
ウィジェットには、監視対象の SAP クラスタリソースが表示されます。この画像では、アクティブなリソースであるSAPインスタンス（ASCSとERSの両方）、ファイルシステム（ASCSとERSの両方）、2つのオーバーレイIP（ASCSとERSそれぞれに1つずつ）、AWS Stonithが表示されています。
SAP PAS / AASの可用性ステータスは、ワークプロセスがアクティブであれば数字が表示されます。何らかの理由でアプリケーションがダウンしている場合は、値は0になります。 下のスクリーンショットは、アクティブなワークプロセス、ICM、IGS、ゲートウェイサービスを示しています。
SAP PAS ディスパッチャやその他のコアサービスが稼働している状態を示しています。
SNS通知
CloudWatch Alarmは、任意のリソースに障害が発生した際に通知を受けるように設定することができます。起動状態以外のリソースはSNS通知をトリガーにします。これにより、システムの可用性を確保し問題を修正するために、素早く対応することができます。
SNSトピックの作成に必要なパラメータ
サブスクライバのサブスクリプションを作成する画面です。
メトリックの偏差に関するアラームを受信するための適切なプロトコルを選択してサブスクリプションを作成します。
画像は、サブスクライバのサブスクリプションの確認メールを示しています。
アマゾンのSNSのサブスクリプションが確定したことを表すSNSトピック
クラウドウォッチアラーム
アラーム設定に移動して、Alarm を使用して興味のあるメトリクスに Cloud Watch のアラームを作成することができます。 次の例では、STONITHリソースにアラームを設定しています。各クラスタには1つのSTONITHリソースがあり、1以下の値はそのリソースがアクティブではないことを示しています。これにより、SNSトピックを活用したメール通知を送信するアラームが発生します。
アラームの設定に必要なパラメータ
アラーム設定のしきい値タイプの選択
SNSトピックを選択したり、新規にSNSトピックを作成して通知を送信したりするためのアラーム設定の画面です。
アラームの説明とアラームの名前を入力して、アラームの設定を完了します。
アラームウィジェットの一部としてのアラームの状態。
サービス中のアラームは、SNSトピックを使用して通知メールをトリガーします。
コスト面での影響
計画外のダウンタイムは収益への大きな影響があります。ガートナーの2014年のブログに基づけば、ダウンタイムは5600ドル/分の収益損失をもたらします。 モニタリング機能は、計画外のダウンタイムに対する反応時間を向上させ、収益損失を低減します。
コストの考慮事項
カスタムメトリクスとカスタムダッシュボードのコストは地域によって異なります。このテンプレートでは、SAP HANAクラスタ、SAPクラスタ、SAPプライマリアプリケーションサーバ上に約50のカスタムメトリクス監視リソースとサービスとともにカスタムダッシュボードを展開します。メトリクスとダッシュボードのコスト見積もりはこちらで確認できます。
結論
本ブログでは、Amazon CloudWatchを活用してSAPクラスタやHANAクラスタリソースの状態を監視する方法の1つを紹介しています。このソリューションは、SAPクラスタリソース、HANAデータベースクラスタリソース、HANAレプリケーションの状態、SAPアプリケーションのコアサービスを監視するためにCloudFormationを使用して簡単にデプロイすることができます。Amazon CloudWatchの詳細については、Amazon CloudWatchのドキュメントをご覧ください。また、このブログで紹介しているSAPクラスタの監視アプローチについてお尋ねの際はこちらからご連絡ください。
翻訳はPartner SA 松本が担当しました。原文はこちらです。