コンテンツに移動
Google Cloud での SAP

高可用性を優先する場合に Google Cloud で SAP を運用する方法

2022年8月1日
Google Cloud Japan Team

※この投稿は米国時間 2022 年 7 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

ここ数年にわたり、あらゆる業界の企業が、ユーザーにとって安心、安全、かつ可用性の高い自社 IT システムを維持するうえで、予期せぬ課題に直面しています。その多くが製品やサービスの需要の急増や急落を経験しており、ほとんどの企業はハイブリッドな業務環境で運営しています。このような、ビジネスの要件と期待値が常に変化する不安定な状況におけるベスト プラクティスは、IT システムのサービスレベル目標(SLO)とサービスレベル契約(SLA)を定期的に見直し、それらをビジネスニーズに合致させるような施策を採ることです。

新しい要件への適応は、SAP エンタープライズ アプリケーションをオンプレミス環境で運用している企業にとっては特に複雑な作業になる可能性があります。ビジネス クリティカルな SAP インスタンスの運用は、複雑で管理コストが高くなるため、多くの場合、このような組織ではすでに苦戦を強いられています。企業は、ユーザーのこれらシステムへの高い依存度と、計画外の停止によって引き起こされる影響の深刻さを理解しているため、高可用性(HA)システムとインフラストラクチャへの多額の投資によって支えられるオンプレミス環境を、重要なアプリケーションのセキュリティと可用性を確保するための最適な手段としてとらえています。多くの場合、オンプレミス SAP 環境の運用を担当する IT 組織は、より多くのことをより少ないリソースで実行するというプレッシャーのもとで、増え続ける他のビジネス クリティカルなアプリケーションの管理をも行うことを強いられています。

多くの組織にとって、これは持続不可能なアプローチです。実際、HA ソリューションのトレンドを調べた SIOS の調査によると、当時の企業はすでにオンプレミス アプリケーションの可用性を維持するのに苦労していました。

  • 調査対象の企業の 95% が、アプリケーションをサポートする HA サービスにおいて、時折またはそれ以上の頻度で障害が発生したと報告しています。

  • 98% が時折または定期的に、71% が月に 1 回以上、アプリケーションのパフォーマンスに問題が生じたと報告しています。

  • 調査対象の企業は、HA アプリケーションの問題が発生したとき、問題の特定と修正に平均 3~5 時間を費やしたと回答しています。

こうした企業の事態は、現在もあまり変わっていません。今日の IT 環境では、リスク、不確実性、今後の緊縮の見通しが重視されています。同時に今は、企業に不可欠なソフトウェアとして、SAP アプリケーションを安全で生産性と可用性の高い状態に保つことが特に重要です。

Google Cloud は、SAP 環境の高可用性に関する課題を解決するために綿密な思案を重ねてきました。これは、お客様にとって死活問題になり得ると考え、また、高可用性とパフォーマンスの実現を目的に、クラウド プラットフォーム上に構築されたスケーラブルで信頼性が高く、費用対効果に優れた SAP 環境の提供を優先して取り組みました。

Google Cloud では、フォールト トレラントまたは高可用性を実現するように設計されている多くのサービスを利用できます。これらのコンセプトは似ていますが、その違いを理解しておくと、アーキテクチャを設計する際の時間と労力を節約できます。

Google は、フォールト トレラントなコンポーネントとは、どのような障害が発生してもシステムの可用性に影響しないような、完全に冗長なメカニズムであると考えています。これには、ストレージ(Google Cloud Storage、Persistent Disk)とネットワーク(Google ネットワーク、Cloud DNS、Cloud ロードバランサ)などのコンポーネントが含まれます。

一方、高可用性サービスには、すべての関連アーキテクチャ コンポーネント(単一障害点ともいいます)に自動復旧メカニズムが組み込まれており、目標復旧時間(RTO)と目標復旧地点(RPO)を最小限に抑えます。通常、コンポーネントの複製とコンポーネント間のフェイルオーバー プロセスの自動化が行われます。

Google Cloud 上の SAP の 4 レベルの高可用性

SAP のお客様に適切な高可用性ソリューションを提供する方法を理解するには、まず、可用性目標の SLA はお客様によって異なり、可用性目標はビジネスニーズ、予算、SAP アプリケーションのユースケース、その他の要因に応じて異なるということを理解する必要があります。SAP の高可用性環境のインフラストラクチャ、オペレーティング システム、アプリケーション可用性という各構成要素と、SAP システムの全体的な可用性戦略の中で検討する必要がある事項について説明します。

レベル 1: インフラストラクチャ

Google Cloud では、プラットフォームに組み込まれており、デフォルトで高可用なセキュリティ、ネットワーキング、コンピューティング、ストレージ機能を利用できるため、多くのお客様がオンプレミスから Google Cloud に SAP システムを移行するだけで、システムの稼働時間を大幅に改善できます。

コンピューティング サービス

コンピューティング サービスについては、Google Cloud Compute Engine の特に重要な 3 つの組み込み機能によって、ハードウェア障害に起因するアプリケーションの中断を低減または回避できます。

ライブ マイグレーション: 定期メンテナンスが必要なホストシステムでお客様の VM インスタンスが稼働している場合、ライブ マイグレーションを使用すると、再起動をトリガーしたりアプリケーションを中断させたりすることなく、あるホストから別のホストに VM インスタンスを移行できます。これは、すべての Google Cloud ユーザーが追加費用なしで利用できる組み込み機能です。ユーザーのワークロードの規模や複雑さに関係なく、シームレスかつ自動的に機能します。Google Cloud がハードウェア メンテナンスを実施し、ハイパーバイザー セキュリティ パッチとアップデートをグローバルかつシームレスに適用します。ライブ マイグレーションにより、稼働中のアプリケーションはメンテナンスの影響を受けないので、お客様に VM の再起動をお願いすることはありません。

メモリ ポイズニングからの回復(MPR): 最高品質のハードウェア インフラストラクチャであっても、故障が発生する可能性があります。最もよく発生するハードウェアの故障は、メモリエラーです(メモリの信頼性に関する Google Cloud の調査をご覧ください)。最近の CPU アーキテクチャは誤り訂正符号(ECC)などのネイティブ機能を備えているため、ホストは訂正可能なエラーから回復できます。ただし、訂正不能なエラーが発生すると、ホストのすべての VM がクラッシュして再起動し、想定外のダウンタイムが発生します。

HANA データベースをご利用の場合は、データのメモリへの読み込みにかかる時間も考慮する必要があります。この場合、データベースのサイズによっては、ホストのクラッシュが原因でビジネス クリティカルなサービスが何時間にもわたり停止することがあります。

Google Cloud は、CPU のネイティブ エラー処理機能、SAP HANA、Google Cloud の機能を統合して、メモリエラーによる中断と停止時間を低減するソリューションを開発しました。MPR により、訂正不能なメモリエラーが検出され、影響を受けるホストから VM をライブ マイグレーションで移行できるようになるまでエラーが隔離されます。

SAP HANA をホストする VM で訂正不能なエラーが検出されると、高速再起動が有効になっている SAP HANA に対し、Google Cloud MPR からシグナルが送信され、影響を受けているメモリ内容のみがディスクから再読み込みされます。これにより、ほとんどの場合はダウンタイムなしで問題を解決できます。その後、影響を受けているホストのすべての VM が、ライブ マイグレーションにより正常なホストへ移行されます。これにより、これらの VM で実行されているお客様のアプリケーションの中断やダウンタイムの発生を回避できます。

自動再起動: まれに発生する、計画外のシャットダウンが不可避なケースでは、自動再起動機能により別のホストで VM インスタンスが自動的に再起動されます。必要に応じてユーザー定義の起動スクリプトを呼び出し、VM 上で実行されているアプリケーションを同時に再起動することも可能です。この機能の目標は、ユーザーにとってプロセスをできるだけシンプルで信頼性の高い状態に保ちながら、計画外のシャットダウンから可能な限り早く回復できるようにすることです。 

これらのサービスの目標は単一ノードの稼働時間の増加ですが、非常に重要なワークロードには、完全なゾーン停止などのコンピューティング関連の障害に対する耐障害性が必要です。これに対応するため、Google Cloud Compute Engine は複数ゾーンに分散するインスタンスに対し 99.99% の月間稼働率 SLA を提供します。

ネットワーク ファイル システム ストレージ(NFS)

高可用性 SAP インフラストラクチャのもう一つの重要な構成要素にネットワーク ファイル システム ストレージ(NFS)があります。これは、インターフェース ディレクトリやトランスポート管理などの SAP 共有ファイルに使用されます。Google Cloud が提供しているファイル共有ソリューションには、自社の Filestore Enterprise やサードパーティ ソリューション(NetApp CVS-Performance など)がありますが、いずれも 99.99% の可用性 SLA を提供しています(Google Cloud の NFS ソリューションの比較情報が必要な場合は、このドキュメントをご覧ください)。

レベル 2: オペレーティング システム

オペレーティング システム レベルでのコンピューティング コンポーネントのクラスタリングは、フェイルオーバー メカニズムにおける重要な要素です。これにより、コンポーネント障害を迅速に検出でき、フェイルオーバー手順が開始されます。その結果、アプリケーションのダウンタイムを最小限に抑えることができます。

Google Cloud における OS レベルでのクラスタリングは、オンプレミスでのクラスタリングに似ていますが、いくつかの機能が向上しています。

SUSE Enterprise Linux(SLES)と Red Hat Enterprise Linux(RHEL)のいずれでも、Pacemaker がクラスタリング リソース マネージャーとして実装され、Google Cloud に対応して設計されたクラスタ エージェントが提供されるので、STONITH フェンシング、VIP ルート、ストレージ操作などの機能をシームレスに管理できるようになります。お客様は、Google Cloud に OS クラスタをデプロイするときに HA / DR プロバイダ フックを利用できます。HA / DR プロバイダ フックにより、SAP HANA は通知を送信して、データを失うことなく、フェイルオーバーを確実に正常完了させることができます。詳細については、SAP 高可用性デプロイガイドの RHEL および SLES での HA クラスタの構成を詳しく説明したドキュメントを参照してください。

Windows ベースのワークロードは Microsoft のフェイルオーバー クラスタリング テクノロジーを使用します。また、クラスタを有効にして構成するための特別な機能が Google Cloud にあります。詳しいドキュメントはこちらで確認できます。

レベル 3: データベース

すべての SAP 環境は、ビジネスに不可欠なデータを格納して管理する中央データベース システムに依存しています。SAP 高可用性ソリューションでは、このデータベース レイヤの可用性と整合性を維持する方法を提供する必要があります。また、SAP システムはさまざまなデータベース システムをサポートしており、その多くは高可用性パフォーマンスの実現にそれぞれ異なるメカニズムを採用しています。SAP HANAMaxDBSAP ASEIBM Db2Microsoft SQL ServerOracle(Google の Bare Metal Solution を使用、HA 認定ハードウェアを使用して Oracle RAC ソリューションをインストールすることも可能)の各ワークロードでの HA アーキテクチャの使用をサポートおよび文書化することで、Google Cloud は SAP データベースの HA の費用とメリットのバランスをとる方法をお客様が自由に決定できるようにしています。

SAP HANA システム レプリケーション(HSR)は、すべての SAP HANA システムの HA を保証するうえで最も重要なアプリケーション ネイティブ テクノロジーの一つです。プライマリ システムのデータを 1 つ以上のセカンダリ システムに継続的に複製し、データをメモリにプリロードして障害が発生した場合の迅速なフェイルオーバーを可能にします。

Google Cloud は、同じリージョン内の任意のゾーンに存在する SAP インスタンスを同期的に複製できるようにすることで、HSR をサポートおよび補完します。これで、プライマリ インスタンスとセカンダリ インスタンスを異なるゾーンに配置し、いずれのゾーンで単一障害点が発生してもインスタンスを保護できます。

その他のデータベース システム(SAP ASE や IBM Db2 など)でも、Google Cloud インフラストラクチャでの実行をサポートする同様の機能が提供されています。同一リージョン内のゾーン間での低ネットワーク レイテンシと、Google の自動デプロイツールの組み合わせにより、お客様は現在のビジネスニーズに合わせて調整されたさまざまなデータベース HA オプションを実行できます。サポートされているデータベース システムとリファレンス アーキテクチャの最新リストについては、最新のドキュメントをご覧ください。

レベル 4: アプリケーション サーバー

SAP の NetWeaver アーキテクチャは、HA 稼働時間要件を脅かす可能性のあるアプリサーバーのボトルネックを回避するのに役立ちます。Google Cloud は、NetWeaver のそのような利点を活かしながら、同期化によりデータ損失に対処し、および SAP NetWeaver から最大限の信頼性とパフォーマンスを引き出すために必要なコンピューティングおよびネットワーキング機能を高い可用性でお客様に提供します。1 つの OS レベルクラスタ(SLES または RHEL)を使用し、クラスタでは Pacemaker クラスタ リソース マネージャーに加えて ABAP SAP Central Services(ASCS)とエンキュー レプリケーション サーバー(ERS)向けに STONITH フェンシングが用意され、それぞれが仮想 IP のための専用の内部ロードバランサ(ILB)を持ちます。HA クラスタのデプロイと構成の詳細については、NetWeaver 高可用性プランニング ガイドの RHEL に関するセクションSLES に関するセクションをご覧ください。

同一リージョンの複数ゾーンにアプリケーション サーバー インスタンスを分散することで、ゾーン障害に対する最適な保護を実現し、エンドユーザーに対しては高いパフォーマンスが提供されます。自動デプロイにより、IT チームは需要の変化に迅速に対応し、追加のインスタンスをすぐに起動できます。これにより、ピーク時でも SAP システムを稼働し続けることができます。

Google Cloud が高可用性 SAP システムをサポートするその他の方法

最も困難な状況においても、SAP アプリケーションの稼働時間を最大限に引き上げるために Google Cloud を活用する方法は他にもたくさんあります。下記の例をご覧ください。企業の規模にかかわらず、手頃な費用で同様の機能を実装することがどれほど難しいかということをご理解いただけると思います。

地理的分布と冗長性。Google Cloud はグローバルに展開しており、現在 30 リージョン、91 ゾーンに 140 以上のポイント オブ プレゼンスがあります。主要な Google Cloud サービスを 1 つのリージョン内の複数のゾーンに分散することで、ほとんどの SAP ユーザーが手頃な費用で優れたパフォーマンスを実現し、目指す可用性を達成しています。

強力で汎用性の高いロード バランシング機能。多くの企業にとって、SAP アプリケーションの可用性維持に重要となるもう一つの項目が、ロード バランシングと分散処理です。Google Cloud は、ユーザーに最も近い健全なリージョンにトラフィックを転送できるグローバルなロード バランシングなど、さまざまなロード バランシング オプションを提供し、このニーズに応えます。Google Cloud Load Balancing は、ユーザー、トラフィック、ネットワーク、バックエンドの健全性、その他の関連条件の変化に瞬時に対応します。また、ソフトウェア定義サービスであるため、物理的なロード バランシング インフラストラクチャで多くの企業が直面するスケーラビリティと管理の問題を回避します。高可用性 SAP システム向けのもう一つの重要なロードバランサ サービスとして、内部ロードバランサがあります。内部ロードバランサを使用して、プライマリ システムとセカンダリ システムの間で仮想 IP(VIP)実装を自動化できます。

開発者が本来の業務に集中できる時間と生産性を維持するツール。Google Cloud のサーバーレス プラットフォームには、冗長性とロード バランシングの組み込み機能を備えたマネージド コンピューティングとデータベース プロダクトが用意されています。これにより、企業の SAP 開発チームは、基盤となるインフラストラクチャを気にすることなく Side-by-Syde 拡張を SAP システムにデプロイできます。Apigee API 管理を使用して、SAP システムにこれらの拡張機能のスケーラブルなインターフェースを提供できます。このインターフェースは、トラフィック ピークと悪質な攻撃からバックエンド システムを保護します。Google Cloud はまた、よく使用されているオープンソース テクノロジーとの統合とネイティブ ツールを通じてCI / CD をサポートし、現代の DevOps 組織にソフトウェアをより迅速かつ安全に提供するために必要なツールを提供します。また、Google Cloud の Cortex Framework には、SAP と連携してイノベーションを進める際のリスク、複雑さ、費用を削減するためのアクセラレータとベスト プラクティスが用意されており、シームレスレスな環境で Google Cloud のアナリティクスを最大限に活用できます。これにより、ビジネスに対してさらに価値がもたらされます。

柔軟なフルスタック モニタリング。Google Cloud Monitoring を使用すると、企業は SAP 環境のパフォーマンス、稼働時間、全体的な動作状況を詳細に把握できます。Google Cloud、アマゾン ウェブ サービス(AWS)、ホスト型稼働時間プローブ、アプリケーション インストルメンテーション、さらには Cassandra、Nginx、Apache ウェブサーバー、Elasticsearch などのさまざまなアプリケーション コンポーネントから指標、イベント、メタデータを収集します。Cloud Monitoring は、SAP HANA のカスタム モニタリング エージェントと Cloud Operations の Ops エージェントから得られたデータによって柔軟なダッシュボードと豊富な可視化ツールを強化します。これにより、新たな問題による影響がビジネスに及ぶ前に、SAP チームがその問題を特定して修正できます。

貴社に適した HA の選択肢を探る

Google Cloud が SAP インスタンスの HA をサポート、拡張する方法は数多くありますが、ここではほんの一部をご紹介しました。さらに詳しく知りたいとお考えの方は、Google のドキュメントをご覧ください。このドキュメントには、Google Cloud サービスを使用して SAP 環境向けに高可用性アーキテクチャを設定する方法について、技術的な詳細が記載されています。

- SAP ソリューション管理担当責任者、Joe Darlak

- SAP ソリューション担当カスタマー エンジニア、Osmar Vinci
投稿先