このガイドでは、高可用性（HA）SAP NetWeaver システムを Google Cloud にデプロイする前に知っておく必要があるオプション、推奨事項、一般的なコンセプトについて説明します。
このガイドは、SAP NetWeaver の高可用性システムの実装に必要な一般的なコンセプトと手順について理解していることを前提としています。したがって、このガイドでは主に、このようなシステムを Google Cloud に実装するために必要な知識について説明します。
SAP NetWeaver HA システムの実装に必要な一般的なコンセプトと手順については、以下のドキュメントをご覧ください。
- SAP のベスト プラクティス ドキュメント: Building High Availability for SAP NetWeaver and SAP HANA on Linux
- SAP NetWeaver のドキュメント
このプランニング ガイドでは、SAP NetWeaver の可用性を中心に説明します。データベース システムの高可用性については説明しません。SAP HANA の高可用性の詳細については、SAP HANA 高可用性プランニング ガイドをご覧ください。
デプロイ アーキテクチャ
次の図は、Pacemaker クラスタ ソフトウェアを使用する基本的な Linux HA クラスタを示しています。
このクラスタには、プライマリ ホストとセカンダリ ホストの 2 つのホストが存在します。各ホストは同じリージョン内の別のゾーンにあります。
クラスタでは SAP Standalone Enqueue Server 2（ENSA2）を使用します。以前のバージョンの Standalone Enqueue Server（ENSA1）を使用するクラスタの説明については、Standalone Enqueue Server（ENSA1）アーキテクチャをご覧ください。
アクティブなセントラル サービス インスタンスはプライマリ ホストにあります。アクティブな Enqueue Replication Server 2（ERS）インスタンスはセカンダリ ホストにあります。セントラル サービスと ERS にはそれぞれ固有の仮想 IP アドレス（VIP）が割り当てられています。この図で「セントラル サービス」は、ABAP SAP セントラル サービスか SAP セントラル サービス（Java スタックの場合）のいずれかを表します。
HA 構成での Standalone Enqueue Server 2 の詳細については、SAP Note 2711036 - HA 環境での Standalone Enqueue Server 2 の使用 をご覧ください。
Standalone Enqueue Server（ENSA1）アーキテクチャ
次の図では、ロック管理（エンキュー サービス）を含むアクティブなセントラル サービス インスタンスと非アクティブなエンキュー レプリケーション サーバー（ERS）インスタンスがプライマリ ホストにあります。アクティブな ERS インスタンスと非アクティブなセントラル サービス インスタンスはセカンダリ ホストにあります。セントラル サービスと ERS の各ペアには固有の仮想 IP アドレス（VIP）が割り当てられています。この図で「セントラル サービス」は、ABAP SAP セントラル サービスか SAP セントラル サービス（Java スタックの場合）のいずれかを表します。
HA クラスタリング ソフトウェアで障害が発生した場合、ロック情報を保持するには、エンキュー レプリケーション サーバーが実行されているノードにスタンドアロンのエンキュー サーバーを再配置する必要があります。ソフトウェア バージョンがサポートしている場合は、システムを更新して Standalone Enqueue Server 2 を使用することを検討してください。詳しくは、SAP Note 2630416 - Standalone Enqueue Server 2 のサポートをご覧ください。
Google Cloud インフラストラクチャの高可用性
Google Cloud は高可用性を提供する設計になっています。世界中のデータセンターに冗長インフラストラクチャが装備され、相互に独立したゾーンが設定されています。通常、ゾーンの電源、冷却、ネットワーキング、コントロール プレーンは他のゾーンから独立しています。1 つの障害イベントが発生しても、多くの場合、影響を受けるのはイベントが発生したゾーンだけです。
ハードウェア、ストレージ、ネットワークの障害に対してオンプレミスで行われている従来の保護対策をすべて実装しなくても、可用性の要件を満たし、時間とコストの両方を節約できる場合もあります。
Google Cloud の高可用性戦略を設計して実装する前に、Google Cloud のサービスレベル契約をご確認ください。
Google Cloud の信頼性、プライバシー、セキュリティの概要については、信頼性をご覧ください。
Google Cloud での SAP システムの HA クラスタリング オプション
Google Cloud で SAP NetWeaver の高可用性（HA）クラスタを定義するには、オンプレミスでのインストールに使用するのと同じタイプのサードパーティの HA クラスタ ソフトウェアを使用します。HA クラスタ ソフトウェアは、システムの状態をモニタリングし、問題発生時のフェイルオーバーを管理します。
次のような HA クラスタ ソフトウェア ソリューションを使用できます。
- Red Hat Enterprise Linux（RHEL）for SAP Solutions
- SUSE Linux Enterprise Server（SLES）for SAP Applications
- Windows Server フェイルオーバー クラスタリング
Linux HA クラスタリング ソフトウェア
RHEL と SLES の両方の最新バージョンには、Google Cloud に特化した統合 HA サポートが含まれています。Linux バージョンに Google Cloud 対応の HA サポートが含まれているかどうかを確認するには、Google Cloud 上の SAP NetWeaver に対するオペレーティング システムのサポートの表で「GCP-HA」を検索します。
Windows HA クラスタリング ソフトウェア
Windows Server の場合は、Windows Server フェイルオーバー クラスタリング（WSFC）を使用して HA クラスタを作成します。詳しくは、Windows Server フェイルオーバー クラスタリングの実行をご覧ください。
Google Cloud では、WSFC クラスタのアクティブ ノードへの受信トラフィックのルーティングは Cloud Load Balancing で管理され、エイリアス IP や静的ルートの VIP の実装は必要ありません。
Cloud Load Balancing は、ヘルスチェックでアクティブ ノードを特定します。
Google Cloud ゾーン、リージョンと SAP NetWeaver HA のデプロイ
HA クラスタのノードを同じリージョン内の複数の Compute Engine ゾーンにデプロイします。異なるゾーンにノードをデプロイすることで、ノードが異なる物理マシンに配置され、ごく低い可能性で発生するゾーン障害からも保護できます。
同じリージョン内にゾーンを維持することで、高可用性システムにおける SAP レイテンシの要件を満たすうえで地理的に十分に近接した場所にノードを配置できます。
Compute Engine 仮想マシンと SAP NetWeaver HA のデプロイ
高可用性を実現するため、Compute Engine VM はライブ マイグレーションと自動再起動に対応しています。
Compute Engine ライブ マイグレーション
Compute Engine は、基盤となるインフラストラクチャの状態をモニタリングします。インフラストラクチャでメンテナンス イベントが発生すると、Compute Engine はインスタンスを自動的に移行し、イベントを回避します。また、可能であれば、移行中もインスタンスの実行を継続します。ユーザーの操作は必要ありません。
大規模な停止の場合、インスタンスが停止してから使用可能になるまでに少し時間がかかることがあります。
ほとんどの場合、ライブ マイグレーション イベントは HA クラスタに影響を与えません。ただし、HA クラスタを設定してシステムを実行した後に、アクティブ ホストのライブ マイグレーションをシミュレートし、HA クラスタのテストを行ってください。特に HA クラスタ モニターに構成されたフェイルオーバーのしきい値が低い場合は、このテストが必要になります。ライブ マイグレーション イベントのシミュレーションの詳細については、可用性ポリシーのテストをご覧ください。
移行されたインスタンスは元のインスタンスと同じになり、インスタンス ID、プライベート IP アドレス、すべてのインスタンスのメタデータとストレージが含まれます。
デフォルトでは、標準インスタンスがライブ マイグレーションに設定されています。この設定は変更しないことをおすすめします。
詳しくは、ライブ マイグレーションをご覧ください。
Compute Engine の自動再起動
メンテナンス イベントの発生時にインスタンスが終了するように設定されている場合、または基盤となるハードウェアの問題でインスタンスがクラッシュした場合は、インスタンスを自動的に再起動するように Compute Engine を設定できます。デフォルトでは、インスタンスは自動的に再起動するように設定されています。この設定は変更しないことをおすすめします。
自動再起動の詳細については、自動再起動をご覧ください。
Google Cloud での HA SAP システムの共有ストレージ オプション
SAP NetWeaver グローバル ファイル システムは、HA システム内のすべての SAP NetWeaver インスタンスで使用可能にする必要があるため、単一障害点となります。Google Cloud でグローバル ファイル システムの可用性を維持するには、高可用性の共有ストレージ、または複製したゾーン永続ディスクを使用します。
高可用性共有ストレージ ソリューションが必要な場合は、Google Cloud Filestore や、NetApp Cloud Volumes Service for Google Cloud、NetApp Cloud Volumes ONTAP などのサードパーティのファイル共有ソリューションを使用できます。
Filestore の Enterprise ティアはマルチゾーン高可用性デプロイに使用でき、Filestore の Basic ティアはシングルゾーン デプロイに使用できます。
Linux システムでゾーン永続ディスクを複製する場合は、Distributed Replicated Block Device（DRBD）を使用して、HA クラスタのノード間の SAP グローバル ファイル システムを含む永続ディスクを複製できます。
Compute Engine リージョン永続ディスクを使用すると、ゾーン間で同期的にブロック ストレージを複製できますが、現在 SAP NetWeaver HA システムではこの機能がサポートされていません。
Google Cloud のストレージ オプションの詳細については、以下をご覧ください。
HA SAP システムのネットワーク オプション
HA クラスタのネットワークを設定する場合、ネットワークを作成するだけでなく、HA 固有の次のタスクを完了する必要があります。
- 次のセクションで説明するように、Linux システムの VIP 実装を選択します。Windows システムは内部のロードバランサを使用するため、Linux システムと同じ VIP ソリューションを使用する必要はありません。
- SAP セントラル サービス インスタンスとエンキュー レプリケーション サーバー インスタンス間の通信パスを定義します。
- 定義した通信パスをサポートするファイアウォール ルールを定義します。
Google Cloud での仮想 IP の実装
高可用性クラスタは、フローティング IP アドレスまたは仮想 IP アドレス（VIP）を使用して、予期しない障害が発生した場合や定期メンテナンスが行われる場合に、クラスタノード間でワークロードを移動します。VIP の IP アドレスは変更されないため、作業が別のノードで行われることをクライアント アプリケーションが認識することはありません。
VIP はフローティング IP アドレスとも呼ばれます。
Google Cloud の場合、VIP の実装がオンプレミス環境と若干異なります。フェイルオーバーが発生したときに、Gratuitous ARP リクエストで変更を通知できません。代わりに、次のいずれかの方法を使用して SAP HA クラスタの VIP アドレスを実装できます。
- 内部パススルー ネットワーク ロードバランサのフェイルオーバーのサポート（推奨）。
- Google Cloud の静的ルート。
- Google Cloud のエイリアス IP アドレス。
内部パススルー ネットワーク ロードバランサの VIP の実装
通常、ロードバランサはユーザーのトラフィックをアプリケーションの複数のインスタンスに分散します。複数のアクティブなシステム間でワークロードを分散し、処理速度の低下や特定のインスタンスの障害から保護します。
また、内部パススルー ネットワーク ロードバランサはフェイルオーバー サポートも提供しています。これと Compute Engine のヘルスチェックを組み合わせて使用することによって、障害の検出、フェイルオーバーのトリガー、OS ネイティブの HA クラスタ内の新しいプライマリ SAP システムへのトラフィックのルート変更を行うことができます。
フェイルオーバー サポートは、次のようなさまざまな理由から VIP の実装方法として推奨されます。
- Compute Engine でのロード バランシングは 99.99% の可用性の SLA を提供します。
- 負荷分散はマルチゾーンの高可用性クラスタをサポートしており、予測可能なクロスゾーン フェイルオーバー時間でゾーン障害から保護します。
- 負荷分散を使用すると、フェイルオーバーの検出とトリガーに必要な時間が短縮され、通常は障害発生から数秒以内に完了します。全体的なフェイルオーバー時間は、HA システム内の各コンポーネントのフェイルオーバー時間（ホスト、データベース システム、アプリケーション システムなど）によって左右されます。
- ロード バランシングを使用すると、クラスタ構成が簡素化され、依存関係が削減されます。
- ルートを使用する VIP の実装とは異なり、負荷分散では独自の VPC ネットワークの IP 範囲を使用でき、それらの IP 範囲は必要に応じて予約や構成を行うことができます。
- 負荷分散を使用すると、計画されたメンテナンスで停止する場合に、トラフィックのルートをセカンダリ システムに簡単に変更できます。
ロードバランサによる VIP の実装でヘルスチェックを作成する場合は、ホストの状態を判断するためにヘルスチェックでプローブするホストポートを指定します。SAP HA クラスタの場合は、他のサービスと競合しないように、プライベート範囲 49152～65535 のターゲット ホストポートを指定してください。ホスト VM では、socat ユーティリティや HAProxy などのセカンダリ ヘルパー サービスを使用してターゲット ポートを構成します。
データベース クラスタでセカンダリのスタンバイ システムをオンライン状態のままにしている場合、ヘルスチェックとヘルパー サービスによって負荷分散を有効にし、クラスタ内で現在プライマリ システムとして機能しているオンライン システムにトラフィックを転送できます。
ヘルパー サービスとポート リダイレクトを使用して、SAP システムの計画されたソフトウェア メンテナンスの際にフェイルオーバーをトリガーできます。
フェイルオーバーのサポートの詳細については、内部パススルー ネットワーク ロードバランサのフェイルオーバーを構成するをご覧ください。
ロードバランサによる VIP の実装を使用して HA クラスタをデプロイするには、以下をご覧ください。
静的ルートの VIP の実装
静的ルートの実装ではゾーン障害に対する保護も提供されますが、VM が存在する既存の VPC サブネットの IP 範囲外の VIP を使用する必要があります。そのため、VIP が拡張ネットワーク内の外部 IP アドレスと競合しないか確認する必要もあります。
静的ルートの実装を共有 VPC 構成とともに使用する場合は、複雑さが高まることがあります。この構成は、ネットワーク構成を分離してホスト プロジェクトに含めることを意図するものです。
VIP に静的ルートの実装を使用する場合は、ネットワーク管理者に相談して、静的ルートの実装に適した IP アドレスを決定してください。
エイリアス IP の VIP の実装
エイリアス IP の VIP の実装は、マルチゾーンの HA のデプロイにはおすすめしません。一つのゾーンに障害が発生した場合に、エイリアス IP を別のゾーンのノードに再割り振りするには時間がかかる可能性があるためです。代わりに、フェイルオーバーをサポートする内部パススルー ネットワーク ロードバランサを使用して VIP を実装してください。
SAP HA クラスタのすべてのノードを同じゾーンにデプロイしている場合は、エイリアス IP を使用して HA クラスタの VIP を実装できます。
VIP にエイリアス IP の実装を使用するマルチゾーン SAP HA クラスタがすでに存在する場合は、VIP アドレスを変更せずに内部パススルー ネットワーク ロードバランサの実装に移行できます。エイリアス IP アドレスと内部パススルー ネットワーク ロードバランサの両方で、VPC ネットワークの IP 範囲が使用されます。
エイリアス IP アドレスはマルチゾーン HA クラスタでの VIP の実装には推奨されませんが、SAP のデプロイでは他の用途があります。たとえば、SAP Landscape Management で管理されるようなフレキシブルな SAP デプロイの場合に、エイリアス IP アドレスを使用して論理ホスト名と IP 割り当てを提供できます。
Google Cloud での VIP に関する一般的なベスト プラクティス
Google Cloud での VIP の詳細については、フローティング IP アドレスのベスト プラクティスをご覧ください。
Google Cloud 上の SAP NetWeaver 用高可用性クラスタの構成
Google Cloud には Terraform 構成ファイルが用意されています。このファイルを使用して、SAP NetWeaver HA システムのデプロイを自動化できます。また、SAP NetWeaver HA システムを手動でデプロイして構成することもできます。
SAP NetWeaver HA システムのデプロイを自動化するには、Terraform 構成ファイルを作成し、標準の Terraform コマンドを使用して構成を適用します。デプロイの手順については、以下をご覧ください。
自動デプロイでは、SAP が完全にサポートし、SAP と Google Cloud の両方のベスト プラクティスを遵守している SAP NetWeaver システムに Google Cloud インフラストラクチャをデプロイします。
SAP NetWeaver の自動デプロイでは、パフォーマンスが最適化された高可用性 Linux クラスタがデプロイされます。これには以下の内容が含まれます。
- 自動フェイルオーバー。
- 自動再起動。
- 指定した仮想 IP アドレス（VIP）の予約。
- 仮想 IP アドレス（VIP）から HA クラスタのノードへのルーティングを管理する内部 TCP / UDP 負荷分散によるフェイルオーバー サポート。
- Compute Engine ヘルスチェックにクラスタ内の VM インスタンスのモニタリングを許可するファイアウォール ルール。
- Pacemaker 高可用性クラスタ リソース マネージャー。
- Google Cloud フェンシング メカニズム（
fence_gceフェンシング エージェント）。 - 各 SAP NetWeaver インスタンスに必要な永続ディスクを備えた VM。
Google Cloud に SAP NetWeaver 用 HA クラスタをデプロイして手動で構成する手順については、以下をご覧ください。