SAP HANA 高可用性プランニング ガイド

このガイドでは、高可用性(HA)SAP HANA システムを Google Cloud にデプロイする前に知っておく必要があるオプション、推奨事項、一般的なコンセプトについて説明します。

このガイドは、SAP HANA の高可用性システムの実装に必要な一般的なコンセプトと手順について理解していることを前提としています。したがって、このガイドでは主に、このようなシステムを Google Cloud に実装するために必要な知識について説明します。

SAP HANA HA システムの実装に必要な一般的なコンセプトと手順の詳細については、以下のドキュメントをご覧ください。

このプランニング ガイドでは、専ら SAP HANA の高可用性に焦点を当てて説明します。アプリケーション システムの高可用性については説明しません。SAP NetWeaver の高可用性については、Google Cloud 上での SAP NetWeaver 向け高可用性のプランニング ガイドをご覧ください。

このガイドは、SAP が提供するドキュメントに代わるものではありません。

Google Cloud 上の SAP HANA の高可用性オプション

インフラストラクチャ レベルとソフトウェア レベルの両方で障害に対応できるようにするために、SAP HANA の高可用性構成において、Google Cloud の機能と SAP の機能を組み合わせて使用できます。次の表に、高可用性を実現するために使用される SAP の機能と Google Cloud の機能を示します。

機能 説明
Compute Engine ライブ マイグレーション

Compute Engine は、基盤となるインフラストラクチャの状態をモニタリングし、インスタンスをインフラストラクチャ メンテナンス イベントから自動的に移行します。ユーザーの介入は必要ありません。

Compute Engine は、可能であれば移行中もインスタンスの実行を続行します。大規模な障害の場合、インスタンスが停止してから使用可能になるまでに少し時間がかかることがあります。

マルチホスト システムでは、デプロイガイドで使用される `/hana/shared` ボリュームなどの共有ボリュームは、マスターホストをホストする VM に接続された永続ディスクであり、ワーカーホストに NFS マウントされます。マスターホストのライブ マイグレーションが発生すると、NFS ボリュームは最大で数秒間アクセスできなくなります。マスターホストが再起動すると、NFS ボリュームはすべてのホストで再び機能し、通常の動作が自動的に再開されます。

復旧インスタンスは、インスタンス ID、プライベート IP アドレス、インスタンスのすべてのメタデータとストレージを含めて、元のインスタンスと同じになります。デフォルトでは、標準インスタンスがライブ マイグレーションに設定されています。この設定は変更しないことをおすすめします。

詳細は、ライブ マイグレーションをご覧ください。

Compute Engine の自動再起動

メンテナンス イベントの発生時にインスタンスが終了するように設定されている場合、または基盤となるハードウェアの問題でインスタンスがクラッシュした場合は、インスタンスを自動的に再起動するように Compute Engine を設定できます。

インスタンスは、デフォルトで自動的に再起動するように設定されています。この設定は変更しないことをおすすめします。

SAP HANA サービスの自動再起動

SAP HANA Service Auto-Restart は、SAP が提供する障害復旧ソリューションです。

SAP HANA には、さまざまなアクティビティのために常時実行される多くの構成済みサービスがあります。ソフトウェアの障害や人為的エラーのためにこれらのサービスのいずれかが無効になった場合、SAP HANA サービスの自動再起動ウォッチドッグ機能によって自動的に再起動します。サービスが再起動されると、必要なすべてのデータが読み込まれてメモリに戻され、オペレーションが再開されます。

SAP HANA バックアップ

SAP HANA バックアップは、データベースから特定の時点へのデータベースの再構築に使用できるデータのコピーを作成します。

Google Cloud での SAP HANA バックアップの使用の詳細については、SAP HANA オペレーション ガイドをご覧ください。

SAP HANA ストレージ レプリケーション

SAP HANA ストレージ レプリケーションは、特定のハードウェア パートナーを通じてストレージ レベルの障害復旧サポートを提供します。Google Cloud では、SAP HANA ストレージ レプリケーションはサポートされていません。その代わりに、Compute Engine の永続ディスク スナップショットの使用をご検討ください。

永続ディスクのスナップショットを使用して Google Cloud で SAP HANA システムをバックアップする方法の詳細については、SAP HANA オペレーション ガイドをご覧ください。

SAP HANA ホストの自動フェイルオーバー

SAP HANA ホスト自動フェイルオーバーは、ローカルの障害復旧ソリューションであり、スケールアウト システムで 1 つ以上のスタンバイ SAP HANA ホストを必要とします。メインホストの 1 つに障害が発生すると、ホストの自動フェイルオーバーによりスタンバイ ホストが自動的にオンラインになり、障害が発生したホストがスタンバイ ホストとして再起動されます。

詳細情報

SAP HANA システム レプリケーション

SAP HANA システム レプリケーションを使用すると、高可用シナリオまたは障害復旧シナリオでプライマリ システムを引き継ぐように、1 つ以上のシステムを構成できます。レプリケーションは、パフォーマンスとフェイルオーバー時間の面のニーズに応じて調整できます。

Google Cloud 上の SAP HANA 向けの OS ネイティブ HA クラスタ

Linux オペレーティング システムのクラスタリングは、アプリケーションとゲストがアプリケーションの状態を認識できるようにし、障害発生時の復旧処理を自動化します。

一般的には、クラウド以外の環境で通用する高可用クラスタの原則は Google Cloud にも当てはまりますが、フェンシングや仮想 IP など、実装方法が異なるものもあります。

Google Cloud 上の SAP HANA の HA クラスタには、Red Hat または SUSE の高可用性 Linux ディストリビューションを使用できます。

クラスタ リソース エージェント

Red Hat と SUSE はどちらも、Pacemaker クラスタ ソフトウェアの高可用性実装を備えた Google Cloud 用のリソース エージェントを提供しています。Google Cloud 用のリソース エージェントは、STONITH フェンシング、ルートまたはエイリアス IP で実装された VIP、ストレージ アクションを管理します。

ベース OS のリソース エージェントにまだ含まれていない更新を配信するために、Google Cloud では SAP の HA クラスタ用のコンパニオン リソース エージェントを定期的に提供しています。これらのコンパニオン リソース エージェントが必要な場合は、Google Cloud のデプロイ手順にそれらをダウンロードするためのステップが記載されています。

フェンシング

フェンシングは、Google Cloud Compute Engine OS クラスタリングのコンテキストでは STONITH の形式をとり、2 ノードクラスタ内の各メンバーに他方のノードを再起動する機能を提供します。

Red Hat と SUSE が提供するどちらのリソース エージェントも、Google Cloud での STONITH フェンシングを管理します。

仮想 IP アドレス

Google Cloud 上の SAP の高可用性クラスタは、フェイルオーバーが発生すると、仮想 IP アドレス(VIP)(フローティング IP アドレスとも呼ばれる)を使用してネットワーク トラフィックを別のホストにリダイレクトします。

クラウド以外のデプロイでは通常、Gratuitous Address Resolution Protocol(ARP)リクエストを使用して、VIP が新しい MAC アドレスに移動して再割り振りされたことを通知します。

Google Cloud では、Gratuitous ARP リクエストを使用する代わりに、いくつかある方法のいずれかを使用して HA クラスタ内で VIP を移動して再割り振ります。内部 TCP / UDP ロードバランサを使用する方法をおすすめしますが、必要に応じて、ルートベースの VIP 実装、またはエイリアス IP ベースの VIP 実装も使用できます。

Google Cloud での VIP の実装の詳細については、Google Cloud での仮想 IP の実装をご覧ください。

ストレージとレプリケーション

SAP HANA の HA クラスタ構成では、同期 SAP HANA システム レプリケーションを使用して、プライマリとセカンダリの SAP HANA データベースの同期を維持します。標準の OS が提供する SAP HANA 用のリソース エージェントは、フェイルオーバー時のシステム レプリケーションを管理します。レプリケーションの開始と停止を行ったり、レプリケーション プロセスにおいてアクティブおよびスタンバイとして機能するインスタンスの切り替えを行ったりします。

共有ファイル ストレージが必要な場合は、必要な機能を NFS ベースまたは SMB ベースのファイラーが提供します。

高可用性の共有ストレージ ソリューションが必要な場合は、NetApp Cloud Volumes などのサードパーティのファイル共有ソリューションを使用できます。Google Cloud は、NFS ファイル サーバー ソリューションである Filestore を提供していますが、Filestore は現在、ゾーン間の高可用性を実現するファイル サーバーを提供していません。

Compute Engine のリージョン永続ディスクを使用すると、ゾーン間で同期的にブロック ストレージを複製できます。リージョン永続ディスクは、SAP HA システムのデータベース ストレージとしてはサポートされていませんが、NFS ファイル サーバーで使用できます。

Google Cloud のストレージ オプションの詳細については、以下をご覧ください。

タイムアウトと間隔の設定

リソース エージェントとクラスタの構成におけるタイムアウトとチェック間隔の設定は、クラスタ ソフトウェアがフェイルオーバーをトリガーする速さに影響します。Google Cloud の手順で使用される値と HA クラスタの自動化で使用される値は、クラスタ ソフトウェアのデフォルト値と若干異なる場合がありますが、ほとんどの場合はどちらの値のセットでも問題ありません。値は必要に応じて調整できます。ただし、システムを実際の使用に向けてリリースする前に、使用する値を自身の環境で必ずテストしてください。

Google Cloud によって推奨されるタイムアウトとチェック間隔の値は Google Cloud のライブ マイグレーションのメンテナンス イベントに関するものですが、その長さは使用しているマシンタイプやその他の要因に応じて若干異なる場合があります。詳細については、ライブ マイグレーションをご覧ください。

クラスタをデプロイしたら、Cloud SDK コマンド gcloud compute instances simulate-maintenance-event を使用して、プライマリ ホストでライブ マイグレーション イベントをトリガーし、設定をテストしてください。

ロギングとモニタリング

リソース エージェントには、分析のために Google Cloud のオペレーション スイートにログを伝播するロギング機能を含めることができます。各リソース エージェントには、ロギング オプションを識別する構成情報が含まれます。bash 実装の場合、ロギング オプションは gcloud logging です。

Cloud Logging エージェントをインストールして、オペレーティング システムのプロセスからログ出力を取得し、リソースの使用状況とシステム イベントを関連付けることもできます。Logging エージェントは、デフォルトのシステムログを取得します。これには Pacemaker やクラスタリング サービスからのログデータも含まれます。詳細については、Logging エージェントについてをご覧ください。

Cloud Monitoring を使用してサービス エンドポイントの可用性をモニタリングするサービス チェックを構成する方法については、稼働時間チェックの管理をご覧ください。

サービス アカウントと HA クラスタ

クラスタ ソフトウェアが Google Cloud 環境で実行できるアクションは、各ホスト VM のサービス アカウントに付与された権限によって保護されます。セキュリティの高い環境では、最小権限の原則に従って、ホスト VM のサービス アカウントの権限を制限します。

サービス アカウントの権限を制限する際には、システムが Cloud Storage などの Google Cloud サービスとやり取りする可能性があるため、ホスト VM のサービス アカウントにそれらのサービスとやり取りするための権限を含める必要があることに注意してください。

最も制限の厳しい権限を実現するには、最小限必要な権限のみを付与したカスタムロールを作成します。カスタムロールについては、カスタムロールの作成と管理をご覧ください。権限をさらに制限するには、HA クラスタ内の VM インスタンスなど、リソースの特定のインスタンスのみに権限を制限します。これを行うには、リソースの IAM ポリシーのロール バインディングで条件を追加します。

システムに必要な最小権限は、システムがアクセスする Google Cloud リソースとシステムが実行するアクションによって異なります。したがって、HA クラスタ内のホスト VM にとって必要な最小権限を決定するには、ホスト VM 上のシステムがアクセスするリソースと、システムがそれらのリソースに対して実行するアクションを正確に調べる必要があります。

出発点として、次のリストに HA クラスタ リソースと、それらに必要な権限を示します。

  • STONITH フェンシング
    • compute.instances.list
    • compute.instances.get
    • compute.instances.reset
    • compute.instances.stop
    • compute.instances.start
    • logging.logEntries.create
    • compute.zones.list
  • エイリアス IP を使用して実装される VIP
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.instances.updateNetworkInterface
    • compute.zoneOperations.get
    • logging.logEntries.create
  • 静的ルートを使用して実装される VIP
    • compute.instances.list
    • compute.instances.get
    • compute.zones.list
    • logging.logEntries.create
    • compute.routes.get
    • compute.routes.create
    • compute.routes.delete
    • compute.routes.update
    • compute.routes.list
    • compute.networks.updatePolicy
    • compute.networks.get
    • compute.globalOperations.get
    • logging.logEntries.create
  • 内部ロードバランサを使用して実装される VIP
    • 特定の権限は不要 - ロードバランサはヘルスチェック ステータスに対して動作するため、クラスタで Google Cloud のリソースを操作または変更する必要はありません。

Google Cloud での仮想 IP の実装

高可用性クラスタは、フローティング IP アドレスまたは仮想 IP アドレス(VIP)を使用して、予期しない障害が発生した場合や定期メンテナンスが行われる場合に、クラスタノード間でワークロードを移動します。VIP の IP アドレスは変更されないため、作業が別のノードで行われることをクライアント アプリケーションが認識することはありません。

VIP はフローティング IP アドレスとも呼ばれます。

Google Cloud の場合、VIP の実装がオンプレミス環境と若干異なります。フェイルオーバーが発生したときに、Gratuitous ARP リクエストで変更を通知できません。代わりに、次のいずれかの方法を使用して SAP HA クラスタの VIP アドレスを実装できます。

内部 TCP / UDP 負荷分散の VIP の実装

通常、ロードバランサはユーザーのトラフィックをアプリケーションの複数のインスタンスに分散します。複数のアクティブなシステム間でワークロードを分散し、処理速度の低下や特定のインスタンスの障害から保護します。

また、内部 TCP / UDP 負荷分散サービスはフェイルオーバー サポートも提供しています。これと Compute Engine のヘルスチェックを組み合わせて使用することによって、障害の検出、フェイルオーバーのトリガー、OS ネイティブの HA クラスタ内の新しいプライマリ SAP システムへのトラフィックのルート変更を行うことができます。

内部 TCP / UDP 負荷分散のフェイルオーバー サポートは、次のようなさまざまな理由から VIP の実装方法として推奨されます。

  • Compute Engine での負荷分散は 99.99% の可用性の SLA を提供します。
  • 負荷分散はマルチゾーンの高可用性クラスタをサポートしており、予測可能なクロスゾーン フェイルオーバー時間でゾーン障害から保護します。
  • 負荷分散を使用すると、フェイルオーバーの検出とトリガーに必要な時間が短縮され、通常は障害発生から数秒以内に完了します。全体的なフェイルオーバー時間は、HA システム内の各コンポーネントのフェイルオーバー時間(ホスト、データベース システム、アプリケーション システムなど)によって左右されます。
  • 負荷分散を使用すると、クラスタ構成が簡素化され、依存関係が削減されます。
  • ルートを使用する VIP の実装とは異なり、負荷分散では独自の VPC ネットワークの IP 範囲を使用でき、それらの IP 範囲は必要に応じて予約や構成を行うことができます。
  • 負荷分散を使用すると、計画されたメンテナンスで停止する場合に、トラフィックのルートをセカンダリ システムに簡単に変更できます。

ロードバランサによる VIP の実装でヘルスチェックを作成する場合は、ホストの状態を判断するためにヘルスチェックでプローブするホストポートを指定します。SAP HA クラスタの場合は、他のサービスと競合しないように、プライベート範囲 49152~65535 のターゲット ホストポートを指定してください。ホスト VM では、socat ユーティリティや HAProxy などのセカンダリ ヘルパー サービスを使用してターゲット ポートを構成します。

データベース クラスタでセカンダリのスタンバイ システムをオンライン状態のままにしている場合、ヘルスチェックとヘルパー サービスによって負荷分散を有効にし、クラスタ内で現在プライマリ システムとして機能しているオンライン システムにトラフィックを転送できます。

ヘルパー サービスとポート リダイレクトを使用して、SAP システムの計画されたソフトウェア メンテナンスの際にフェイルオーバーをトリガーできます。

内部 TCP / UDP 負荷分散のフェイルオーバー サポートの詳細については、内部 TCP / UDP 負荷分散のフェイルオーバーの構成をご覧ください。

ロードバランサによる VIP の実装を使用して HA クラスタをデプロイするには、以下をご覧ください。

静的ルートの VIP の実装

静的ルートの実装ではゾーン障害に対する保護も提供されますが、VM が存在する既存の VPC サブネットの IP 範囲外の VIP を使用する必要があります。そのため、VIP が拡張ネットワーク内の外部 IP アドレスと競合しないか確認する必要もあります。

静的ルートの実装を共有 VPC 構成とともに使用する場合は、複雑さが高まることがあります。この構成は、ネットワーク構成を分離してホスト プロジェクトに含めることを意図するものです。

VIP に静的ルートの実装を使用する場合は、ネットワーク管理者に相談して、静的ルートの実装に適した IP アドレスを決定してください。

エイリアス IP の VIP の実装

エイリアス IP の VIP の実装は、マルチゾーンの HA のデプロイにはおすすめしません。1 つのゾーンに障害が発生した場合に、エイリアス IP を別のゾーンのノードに再割り振りするには時間がかかる可能性があるためです。代わりに、フェイルオーバーをサポートする内部 TCP / UDP 負荷分散を使用して VIP を実装してください。

SAP HA クラスタのすべてのノードを同じゾーンにデプロイしている場合は、エイリアス IP を使用して HA クラスタの VIP を実装できます。

VIP にエイリアス IP の実装を使用するマルチゾーン SAP HA クラスタがすでに存在する場合は、VIP アドレスを変更せずに内部 TCP / UDP 負荷分散の実装に移行できます。エイリアス IP と内部 TCP / UDP 負荷分散はどちらも VPC ネットワークの IP 範囲を使用します。

エイリアス IP アドレスはマルチゾーン HA クラスタでの VIP の実装には推奨されませんが、SAP のデプロイでは他の用途があります。たとえば、SAP Landscape Management で管理されるようなフレキシブルな SAP デプロイの場合に、エイリアス IP アドレスを使用して論理ホスト名と IP 割り当てを提供できます。

Google Cloud での VIP に関する一般的なベスト プラクティス

Google Cloud での VIP の詳細については、フローティング IP アドレスのベスト プラクティスをご覧ください。

Google Cloud での SAP HANA ホストの自動フェイルオーバー

Google Cloud は、SAP HANA が提供するローカル障害復旧ソリューションである SAP HANA 自動ホスト フェイルオーバーをサポートしています。ホストの自動フェイルオーバー ソリューションでは、ホスト障害が発生した場合に、マスターホストまたはワーカーホストから処理を引き継ぐように予約されている 1 つ以上のスタンバイ ホストを使用します。スタンバイ ホストにはデータが含まれず、作業も処理されません。

/hana/data ボリュームと /hana/log ボリュームは、マスターホストとワーカーホストにのみマウントされます。引き継ぎが発生すると、ホスト自動フェイルオーバー ソリューションによって、SAP HANA ストレージ コネクタ API と Compute Engine gceStorageConnector プラグインが使用され、これらのディスクの障害ホストからスタンバイホストへの切り替えが行われます。フェンシングが有効か無効かなどを表すパラメータなど、gceStorageConnector プラグインの構成パラメータが SAP HANA global.ini ファイルの storage セクションに保存されます。

/hana/shared ボリュームと /hanabackup ボリュームは NFS サーバーに保存され、マスターホストによって管理され、スタンバイ ホストを含むすべてのホストにマウントされます。

フェイルオーバーが完了すると、障害が発生したホストはスタンバイ ホストとして再起動されます。

SAP では、Google Cloud 上のスケールアウト システムで最大 3 つのスタンバイ ホストがサポートされます。スタンバイ ホストは、Google Cloud のスケールアウト システムで SAP がサポートする最大 16 個のアクティブ ホストにはカウントされません。

現在、Google Cloud は、sles-12-sp3-sap および sles-12-sp2-sap のイメージ ファミリーの Compute Engine から利用可能な SUSE Linux Enterprise Server(SLES)for SAP の公開イメージでのみ、SAP HANA ホストの自動フェイルオーバーをサポートしています。Compute Engine から利用できる公開イメージを確認するには、イメージをご覧ください。

次の図は、SAP HANA ホストの自動フェイルオーバーのサポートが含まれる Google Cloud のマルチホスト アーキテクチャを示しています。この図では、ワーカーホスト 2 に障害が発生したためスタンバイ ホストが引き継いでいます。gceStorageClient プラグインは、SAP Storage Connector API(図には示されていない)と連携して、/hana/data および /hana/logs ボリュームを含むディスクを障害発生のワーカーから切り離し、スタンバイ ホストに再マウントしてワーカーホスト 2 としています。その際、障害が発生したホストが代わってスタンバイ ホストになります。

図はホストの自動フェイルオーバーのサポートを含むスケールアウト SAP HANA システムのアーキテクチャを示しています

SAP HANA 高可用性構成のデプロイ オプション

Google Cloud では Deployment Manager テンプレートが用意されており、これを使用して SAP HANA HA システムのデプロイを自動化したり、SAP HANA HA システムを手動でデプロイ、構成したりすることができます。

Google Cloud が提供する Deployment Manager テンプレートには template.yaml 構成ファイルが含まれており、利用者がこのファイルを編集して完成させます。Deployment Manager は構成ファイルを読み取り、SAP HANA システムをデプロイします。このシステムは SAP によって完全にサポートされ、SAP と Google Cloud の両方のベスト プラクティスに従っています。

SAP HANA 用の Linux 高可用性クラスタの自動デプロイ

Deployment Manager は、SAP HANA 用としてパフォーマンスが最適化された高可用性 Linux クラスタをデプロイします。これには以下が含まれます。

  • 自動フェイルオーバー
  • 自動再起動
  • 同期レプリケーション
  • メモリ プリロード
  • Pacemaker 高可用クラスタ リソース マネージャー
  • Google Cloud フェンシング メカニズム
  • 各 SAP HANA インスタンスに必要な永続ディスクを備えた VM
  • 各 VM 上の SAP HANA インスタンス

詳しくは、SAP HANA 高可用性クラスタのデプロイガイドをご覧ください。

SAP HANA ホスト自動フェイルオーバーを備えた SAP HANA スケールアウト システムの自動デプロイ

SAP HANA 高可用性クラスタの手動デプロイ

HA クラスタを手動で構成する場合は、SAP HANA システムが SAP のサポートの要件とベスト プラクティスを満たすようにするため、最初に Google Cloud が提供する Deployment Manager テンプレートを使用して VM と SAP HANA インスタンスをデプロイしてください。

Google Cloud に SAP HANA 用の HA クラスタをデプロイして手動で構成する手順については、以下を参照してください。

次のステップ

Google Cloud と SAP はどちらも高可用性に関する詳細情報を提供しています。

Google Cloud が提供する高可用性に関する詳細情報

Google Cloud 上の SAP HANA の高可用性の詳細については、以下をご覧ください。

Google Cloud において、さまざまな障害シナリオからシステムを保護するための一般的な情報については、堅牢なシステムの設計をご覧ください。

SAP が提供する SAP HANA 高可用性機能の詳細情報

SAP が提供する SAP HANA 高可用性機能の詳細情報については、次のドキュメントをご覧ください。