SAPシステムのHyperscalerへの移行 – Part 2

[ArataOgama]

はじめに

今回のブログポストは、以下3回シリーズのPart 2となります。

Part 1: 概要とデザインアプローチ (1)

Part 2: デザインアプローチ (2)

Part 3: 移行アプローチ

 

前回はSAPにおけるIaaSとしてのHyperscalerの概要と、デザインアプローチにおけるサイジングの要素の前半としてメモリ、CPUについて記載させていただきましたが、今回はサイジング要素の後半から記載いたします。

 

デザインアプローチ (2)

実際にどのVMインスタンスがSAPにサポートされているかどうかは、各IaaSプロバイダのサポート状況について記載されたSAP Noteがありますのでそちらからご参照頂けます。以下Azure、AWS、GCPの例となります。

 

SAP Note 1928533 - SAP Applications on Azure: Supported Products and Azure VM types

 

SAP Note 1656099 - SAP Applications on AWS: Supported DB/OS and AWS EC2 products

 

SAP Note 2456432 - SAP Applications on Google Cloud Platform: Supported Products and Google VM types

 

上記SAP Noteをご確認頂くと、各VMインスタンスに対して、メモリ量の他にSAPS値が記載されています。前回お伝えした通り、メモリだけでなく、CPUベースのサイジングインプットがあれば、これらの値を参考により適切なVMインスタンスを選定することが可能となります。なお、仮想化技術特有のHypervisor層などのオーバーヘッドについては、これらのSAP Note記載のSAPS値に考慮されておりますので気にする必要はありません。

 

SAP HANAについては、下記の通り別途認定情報が記載されているサイトが用意されています。

Certified and Supporoted SAP HANA Hardware（=> IaaSでフィルタ）

 

次にディスクについてですが、各HyperscalerではSAP HANAを動作させるために認定を受けたディスクが用意されています。そのためいずれを選択しても大枠外れることはないと思いますが、例えば本番運用には本番運用に適したスループットが必要となりますので、各推奨事項の適用と、可能であればデプロイ後の早めの性能検証を行うことが望ましく思います。

 

例えばAzureでは、SAPの本番運用環境においては、インスタンスによって推奨の違いはありますが、総じてPremium Storage以上が推奨されています。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/workloads/sap/planning-guide-storage

 

また例えばAWSでは、SAP HANAの本番運用環境においては、プロビジョンドIOPS SSD (io2) が推奨されています。

https://docs.aws.amazon.com/ja_jp/quickstart/latest/sap-hana/storage.html

 

なお、SAP HANAを動作させるにあたってのストレージKPIを実際に満たしているどうかの確認や責任はお客様側にあります。以下の表は従来のオンプレミスから存在するハードウェアチェックツール（HWCCT）ガイドに記載されているSAP HANAの本番環境向けのディスクKPIになります。（注）ハードウェアチェックツールとしては、現在はHWCCT後継のHWMTツール（SAP Note 2493172）が利用可能です。

 

ネットワークについてはレイテンシーと帯域が大きな考慮要素となりますが、特にレイテンシーについてはHyperscalerの特徴であるリージョンやAvailability Zoneについて事前によく検討しておくことが必要になります。例えば、本番運用するAPやDB間が異なるAvailability Zoneにある場合にはHA構成としては非常に優れていますが、Availability Zoneをまたぐ通信が常に何度も発生することによって性能面でレスポンスタイムの要件を満たさないといった状況も起こり得ますので、そのトレードオフをどう考えるか予め方針として定め、性能評価などを経て柔軟に対応できるように考慮をしておく必要があります。

 

また、プラットフォーム定義とデプロイメントオプションの観点では、初期サイジングや各種インフラ要件を定義できたとしても、プロビジョニング・デプロイの部分で制約に引っかかってしまう場合があるため、十分に注意が必要です。

 

VM自体のサイズのリミテーションは各Hyperscalerごとに違いますし、また仮に巨大なサイズのVMが必要な場合に、予定しているHyperscalerやリージョンにそのインスタンスが配置可能か否かであったり、DRを組もうとしているリージョンに同一タイプのインスタンスを置くことができないといったケースが発生した場合、DR要件を見直すか、Hyperscalerの選択そのものを再考する必要が出てくることもあり得ます。またIaaSとしてだけでなく、周辺システムとして活用しようとしているPaaSやSaaSとの連携において、それらが近接場所に配置できないということになりますと、その物理的なネットワークの距離によって性能が犠牲になることも考えられますので、単一製品だけでなく、周辺も含めた十分な調査が必要となります。

 

HyperscalerにおけるHA/DRやバックアップの考え方はオンプレミスと大きくは変わりませんが、方式としては自動スケーリングや自動リカバリなど選択可能なオプションの数は増えています。非機能要件に基づいて、各アプリケーションごとにその業務のクリティカル度に応じてRTOやRPO、障害の種類などを整理します。また、Single Point of Failure (SPOF) となり得る部分にそれぞれどのような対策を施すかを定義することが必要となります。

 

例えばSAP HANAのレイヤであれば、HA/DRのソリューションとして、HyperscalerにおいてもSAP HANAの標準機能であるHANA System Replication（HSR）でデータの同期を実現することが可能ですが、障害を検知して自動でFailoverを行うにはオンプレミス同様にクラスタソフトウェアが別途必要となりますので、Hyperscalerにおいて対応しているクラスタソフトウェアや方式を改めて選定することが必要となります。ASCS/ERSのレイヤについても同様です。ASCS/ERSのレイヤで言えば、Standalone Enqueue Server 2 / Enqueue Replicator 2 など複数のインスタンスを使用した構成を取りたい場合、それに対応したクラスタソフトウェアの選定が必要となりますのでさらに注意が必要となります (SAP Note 2711036) 。

 

DRに関して言えば、RTOによってはHSR機能を使用せずに、取得しておいたバックアップやイメージからリカバリをするという方式もよく採用されています。この場合の注意点としては、DRサイトである異なるリージョン上に必要なサイズのインスタンスを予め確保していない場合、実際に大規模災害が発生した場合に割り当てられるクォータが取り合いとなってしまって不足し、インスタンスを確保できない可能性があるという懸念が残るのは確かで、その部分の可能性の示唆と方針の明確化をしておく必要があります。

 

PAS/AASなどのAPサーバのレイヤについては、異なるAvailability Zoneに配置させてデータセンタ障害に備えたり、自動スケーリングや自動リカバリなどの方式を採用することで比較的安価に柔軟性のある構成を組むことが可能となっておりますが、先述の通り、HA構成においてこれらのAPサーバのインスタンスがSAP HANAと異なるAvailability Zoneに配置されていると、場合によってはネットワークのレイテンシーにより、お客様の性能要件を満たさない場合があるため、その点は考慮が必要です。SAPからはその構成は決してNGと申し上げることはありませんが、可用性と性能のトレードオフの関係にあるため、どちらを選定されるかは十分な検証を含め、各お客様の要件に従って決定をお願いしているところになります。

 

以下の図はHA/DRについてアーキテクチャの検討が個々に必要なレイヤを示しています。

 

Part 2はここまでとし、次回Part 3では移行アプローチについて記載いたします。