IBM Cloud® Virtual Private Cloud (VPC) 上での SAP ワークロード HA デプロイの自動化の概要 (Terraform および Ansible )
Terraform を使って IBM Cloud VPC のプロビジョニングを自動化できる。 プロビジョンされた VPC には、ネットワーク・パフォーマンスが高い仮想サーバー・インスタンスが含まれます。 VPC インフラストラクチャーには、Virtual Serversを含む、いくつかの Infrastructure-as-a-Service (IaaS) オファリングが含まれています。 VPC がプロビジョニングされた後、スクリプトは Ansible Playbook を使用して SAP システムをインストールします。
IBM Cloud® VPCの紹介
VPC は、企業が共有パブリック・クラウドインフラストラクチャー上に独自のプライベート・クラウドのようなコンピューティング環境を確立するために使用するパブリック・クラウド・オファリングです。 VPC により、企業は、他のすべてのパブリック・クラウド・テナントから論理的に分離された仮想ネットワークを定義および制御し、パブリック・クラウド上にプライベートで安全な場所を作成することができます。
クラウド・プロバイダーのインフラストラクチャーが住宅用アパートで、複数の家族が内部に住んでいるとします。 パブリック・クラウド・テナントであることは、数人のルームメイトとアパートを共有することに似ています。 対照的に、VPC を所有することは、自分のプライベートなコンドミニアムを所有することに似ています。誰もキーを持っておらず、許可なしにスペースに入ることはできません。
VPC の論理的な分離は、仮想ネットワーク機能とセキュリティー機能を使用して実装され、企業のお客様は、どの IP アドレスまたはアプリケーションが特定のリソースにアクセスできるかをきめ細かく制御できます。 これは、ソーシャル・メディア・アカウントに対する「友情のみ」または「公開/非公開」の制御に類似しており、他の方法で投稿を閲覧できるユーザーまたは閲覧できないユーザーを制限するために使用されます。
IBM Cloud VPC では、UI、CLI、API を使用して、VPC 用の仮想サーバー・インスタンスを手動でプロビジョニングし、高いネットワーク・パフォーマンスを実現できます。 VPCインフラには、 Virtual Servers for VPC を含む多くのInfrastructure-as-a-Service（ IaaS ）が含まれています。 以下の情報を使用して、VPC のリソースを計画、作成、および構成するための単純なユース・ケースを理解し、VPC の概要と VPC チュートリアルについて学習します。 VPC について詳しくは、仮想プライベート・クラウド (VPC) の概要を参照してください。
SAP 製品アーキテクチャ IBM Cloud VPC
仮想プライベートクラウド（VPC）には、 SAP アプリケーション用の最も安全で信頼性の高いクラウド環境の 1 つが、仮想サーバーインスタンスを含む独自の VPC 内に含まれています。 これは、 IBM Cloud 内のInfrastructure as a Service ( IaaS ){: external} に相当し、 IBM からの分離された、安全で柔軟な仮想クラウドインフラストラクチャのすべての利点を提供します。 これに対し、 IBM Cloud Classic infrastructure virtual serversでは、ネイティブおよびVLANネットワーキングによる仮想インスタンスを使用して、データセンター内で相互に通信します。ただし、仮想リソースのスケールアップはポッド間で行われるため、インスタンスはサブネットおよびVLANネットワーキングを使用して、よく機能する1つのポッドに制限されます。 IBM Cloud VPC の新機能は、ポッドの境界や制限をなくすネットワーク・オーケストレーター・レイヤーのコンセプトで、この新しいコンセプトが、リージョンやゾーンをまたいでVPC内で稼働するすべての仮想インスタンスのネットワーキングを処理する。
IBM Cloud VPC上の SAP NetWeaver、高可用性システム
高可用性（HA）システムでは、各インスタンスは別々の IBM Cloud 仮想サーバーインスタンス上で実行できる。 SAP アプリケーションサーバーのクラスタ HA 構成は、2 台の仮想サーバーインスタンスで構成され、各仮想サーバーインスタンスは、シングルゾーンの場合は同一ゾーンに、マルチゾーンの場合は同一リージョン内の異なるゾーンに、配置グループを使用して配置される。 プレースメント・グループは、クラスタ・リソースとクラウド・リソースの両方が、以下のプレースメント・グループのセクションで指定されているように、異なるコンピュート・ノードに配置されていることを保証します。
SAP HAアーキテクチャの IBM Cloud VPC上の配置グループ
VPCのプレースメント・グループ（PG）には、高可用性のために2つの異なるアンチ・アフィニティ戦略がある。 配置ストラテジーを使用することで、仮想サーバーインスタンスを異なるホストに配置したり、電源とネットワーク供給が分離されたインフラに配置したりすることで、サービスが中断する可能性を最小限に抑えることができます。
この問題は、IBM Cloud 仮想サーバーの配置グループの設計によって解決されます。 配置グループを使用すると、新しいパブリック仮想サーバーが配置されるホストを制御することができます。 このリリースでは、"スプレッド "ルールが実装されています。これは、配置グループ内の仮想サーバーがすべて異なるホストにスプレッドされることを意味します。 データセンター内で可用性の高いアプリケーションを構築し、仮想サーバーが互いに隔離されていることを確認できます。
「分散」ルールによる配置グループの作成は、一部の IBM Cloud データ・センターで利用できます。 スプレッド」ルールが作成されたら、仮想サーバーをそのグループにプロビジョニングし、他の仮想サーバーと同じホストにならないようにすることができます。 最大のメリットは、 この機能は完全に無料で使用できるという点です。
配置グループを作成し、新しい仮想サーバーインスタンスを最大4台まで割り当てることができます。 「分散」ルールを使用すると、各仮想サーバーが別々の物理ホストにプロビジョンされます。 以下の設定例では、"Power Spread "オプションが使用されている。
HAシナリオに必要な SAP ：
- ABAPセントラルサービスインスタンス（ASCSインスタンス）- ABAPメッセージサーバーとABAPエンキューサーバーを含む
- ASCSインスタンスのレプリケーションサーバインスタンス（ERSインスタンス）をエンキューする
- データベース・インスタンス
- ノード1のプライマリ・アプリケーション・インスタンス（PAS）
- ノード2の追加アプリケーション・インスタンス（AAS）
ASCSインスタンスとERSインスタンスの両方をスイッチオーバークラスターインフラストラクチャで実行することをお勧めします。
IBM Cloud File Storage for VPC for HAアーキテクチャ SAP
IBM Cloud File Storage for VPC テクノロジーは、 SAP ディレクトリを SAP システムで利用できるようにするために使用される。 選ばれたテクノロジーは、 NFS、共有ディスク、クラスターファイルシステムである。 SAP システムに高可用性（HA）ソリューションを使用することを決定した場合、 SAP 環境の SAP ファイルシステムの HA 要件に適切に対処していることを確認してください。
- SAP apps HA用に両方のクラスタノードで NFS 永続ファイルシステムとしてマウントされるファイル共有：
/usr/sap/<SAPSID>/SYS/sapmnt<SAPSID>/usr/sap/trans
- SAP Apps HA 用クラスタ管理ファイルシステム: ASCS si ERS
/usr/sap/<SAPSID>/ASCS00/usr/sap/<SAPSID>/ERS01
- SAP Apps HA ノード 1 PAS インスタンスに NFS を恒久的にマウント：
/usr/sap/<SAPSID>/Dxx
- SAP Apps HA ノード 2 ダイアログインスタンスに NFS を永続的にマウントします：
/usr/sap/<SAPSID>/Dyy
前提条件
ハードウェア（ホスト、ディスク、およびネットワーク）をインストールし、データベース、 SAP インスタンス、および必要に応じてネットワーク・ファイル・システム（ NFS ）サーバをクラスタ・ノードに分散する方法を決定する必要があります。
context
SAP アプリケーションから見ると、これらは SAP ディレクトリの種類である：
- 物理的に共有されているディレクトリ:
/<sapmnt>/<SAPSID>と/usr/sap/trans /usr/sapのようなノードにバインドされている論理的に共有されたディレクトリで、以下のローカル・ディレクトリがある：/usr/sap/<SAPSID>/usr/sap/<SAPSID>/SYS/usr/sap/hostctrl
- など、 SAP インスタンスを含むローカル・ディレクトリ。
/usr/sap/<SAPSID>/ASCS<Instance_Number> - グローバルトランスポートディレクトリは、標準的な3システムのトランス ポートレイヤー構成として、別個の SAP トランスポートホスト上に存在するかもしれない。
分散されたASCSとERSインスタンスには少なくとも2つのノードと共有ファイルシステムが必要で、残りのコンポーネントは他のノードに分散されていることが前提です。
ASCSとERSのインストール
ASCSとERSインスタンスがノード間で移動できるようにするには、共有ファイルシステムにインストールし、仮想IPに基づいた仮想ホスト名を使用する必要があります。
この VPC ベースの SAP HA ソリューションでは、クラスタに必要な共有ファイルシステムは NFS でマウントされたファイルストレージに置き換えられ、仮想 IP は Application Load Balancer for VPC (ALB) に置き換えられる。
このシナリオでは、仮想IPの要件を置き換えるために、SPOF（Single Point of Failure）コンポーネントごとに1つずつ、合計3つのALBが使用される：ASCS用のALB、ERS用のALB、そしてHANA用のALBです。 各ALBは対応するクラスタサーバーのバックエンドとして構成され、フロントエンドのポートで受信したすべての通信をバックエンドプールのアクティブサーバーにリダイレクトする。
プライベート・アプリケーション・ロード・バランサー
プライベートアプリケーションロードバランサーは、ロードバランサーを作成するために設定したプライベートサブネットを通してアクセスできます。
パブリックアプリケーションロードバランサーと同様に、プライベートアプリケーションロードバランサーサービスインスタンスにはFQDNが割り当てられますが、このドメイン名は1つ以上のプライベートIPアドレスと一緒に登録されます。
割り当てられたプライベート IP アドレスの数と値は、IBM Cloud の運用により、時が経つと、メンテナンス・アクティビティーやスケーリング・アクティビティーのために変更されることがあります。 アプリケーションをホストするバックエンドの仮想サーバーインスタンスは、同じリージョンで同じVPCの下で実行する必要があります。
割り当てられた ALB FQDN を使用して、トラフィックをプライベート・アプリケーション・ロードバランサーに送信し、システムのメンテナンス中やスケールダウン中のアプリケーションへの接続の問題を回避します。
各ALBは、アプリケーション（ASCS、ERS、HANA DB）が実行されているクラスタノードにトラフィックを送信します。 クラスタのフェイルオーバー中、ALBはすべてのトラフィックをリソースが稼働している新しいノードにリダイレクトする。
DNSaaS (DNS as a Service)は、HAとFQDN(IPs)メカニズムの管理 DNSサービスである。 IBM Cloud VPC
ALBは、クライアントとサーバーのタイムアウトをデフォルトで50秒に設定しているため、50秒間操作がないと接続は終了する。 ALBを介した SAP 接続をサポートし、50秒後に接続が切れないようにするには、この値を最低300秒に変更するようリクエストする必要がある（クライアント側のアイドル接続 = 最低 300s、サーバー側のアイドル接続 = 最低 300s ）。 この変更をリクエストするには、サポートチケットを開いてください。 これはアカウント全体の変更であり、アカウント内のすべてのALBに影響します。 詳しくは、 接続タイムアウトを 参照のこと。
DNS Services VPC付き
IBM Cloud DNS Services は、VPCユーザーにプライベートDNSを提供します。 プライベート DNS のゾーンは、IBM Cloud でのみ、また、アカウント内の明示的に許可されたネットワークから要求された場合に限り、解決可能です。 始めるには、 IBM Cloud コンソールを使って DNS Services インスタンスを作成する。
DNS Services では、以下を行うことができます。
- プライベート DNS ゾーン (ドメイン・ネームを保持するためのコレクション) を作成する。
- それらの DNS ゾーンに DNS リソース・レコードを作成する。
- ゾーン単位のレベルでリソース・レコードの DNS 解決に使用するアクセス制御を指定する。
また、DNS Services は、独自の DNS リゾルバーを世界規模で一式保有しています。 IBM Cloud で IBM Cloud ネットワークにプロビジョンされたインスタンスは、 IBM Cloud DNS Services のリゾルバーを照会することで、DNS Services で構成されたリソース・レコードを使用できます。
DNS Services で構成されるリソース・レコードとゾーンには、以下の特徴があります。
- 範囲がより広いパブリック DNS およびその DNS で公開されるレコードからは分離されています。
- IBM Cloud、プライベートネットワーク外のシステムからは見えないようになっている。
- IBM Cloud プライベート・ネットワーク上で承認したシステムからのみアクセス可能。
- サービスが提供するリゾルバによってのみ解決可能。
DNSサービスは、各ALBのFQDNを、 SAP アプリケーションで使用されるASCS、ERS、HANAの仮想ホスト名にマッピングする。
VPCゾーンとリージョン間のネットワーク遅延
VPC ゾーンとリージョン間のネットワーク遅延については、 VPC Network latency dashboards のトピックを参照し、 SAP note "500235 - Network Diagnosis with NIPING" に従い、 SAP tool niping を使用して遅延チェックを実行し、独自の測定を実行してください。
報告された結果は測定されたものである。 これらの測定値によって性能が保証されることはない。 これらの統計は、すべてのリージョンとゾーン間のレイテンシーを可視化し、クラウド展開の最適な選択を計画し、データレジデンシーやパフォーマンスなどのシナリオを計画するのに役立ちます。
SAP HANA データベースの高可用性システム
最も基本的なレベルでは、アクティブ-パッシブ構成の標準的なHA HANAクラスタには2つのノードがあります。 これは単に、プライマリ・ノードがアクティブな SAP インスタンス（PASとAAS）にアクティブにサービスを提供している一方で、スタンバイ・ノードは障害が発生した場合に飛び込むために待機していることを意味する。
SAP アプリケーションインスタンス用の高可用性システム
クラスタには仮想ホスト名IPが設定されます（ホスト名はDNSを通じてHANA ALBのFQDNにマッピングされます。これは、 SAP ASCSおよびERSインスタンスについて前に説明したのと同じです）。 アプリケーション・インスタンス（PASとAAS）は、 SAP プロファイルで特定のコンポーネントを呼び出すために使用される詳細です。 クラスタはその仮想IPをアクティブノードに割り当て、ハートビートモニタを使用してコンポーネントの可用性を確認します。 プライマリ・ノードが応答しなくなると、自動フェイルオーバー・メカニズムが起動し、スタンバイ・ノードを呼び出してプライマリ・ノードになるようステップアップさせる。 ALBは変更を検出し、トラフィックを新しいアクティブノードにリダイレクトし、仮想IPを割り当て、コンポーネントの可用性を回復する。 障害ノードが修復された後、スタンバイ・ノードとしてオンラインになる。
でサポートされているHANAデータベースのレプリケーション機構です。 SAP
プライマリ・システムは、ログがセカンダリ・システムに永続化されているという応答を得るまで、トランザクションをコミットするのを待つ。 このオプションは、データ伝送とセカンダリ・システムでの永続化の時間分だけトランザクションを遅らせるという代償を払って、両システム間の即時一貫性を保証する。
セカンダリ・システムとの接続が失われた場合、プライマリ・システムはトランザクション処理を継続し、ローカル・ディスクにのみ変更を書き込む。 このシナリオでは、セカンダリシステムが接続されていれば、データの損失は発生しない。 セカンダリシステムが切断されている間にテイクオーバーが実行されると、データ損失が発生する可能性がある。
さらに、このレプリケーション・モードは、完全同期オプションで実行することもできる。 これは、ログバッファがプライマリおよびセカンダリシステムのログファイルに書き込まれたとき、ログの書き込みが成功したことを意味する。 セカンダリシステムが切断されると（例えばネットワーク障害）、プライマリシステムはセカンダリシステムとの接続が再確立されるまでトランザクション処理を中断する。 このシナリオでは、データの損失は発生しない。 システム・レプリケーションの完全同期オプションは、パラメータ
[system_replication]/enable_full_sync で設定できます。
SAP HANA システム・レプリケーションが完全同期オプションを有効にした同期レプリケーション・モードで実行され、セカンダリ・サイトへの接続が中断された場合、プライマリ・サイトへの書き込み操作はできません。 たとえばテナント・データベースを作成する操作は、セカンダリへの接続が再確立されるか、SQL文がタイムアウトするまで待機する。
この自動化は無償で提供されるが、プロビジョニングされたインフラにはコストがかかる。