SAP HANA on AWSの展開 – どのような選択肢が？

本稼働ワークロードの選択肢
インスタンスタイプ	メモリー (GiB)	vCPU	SAPS
x1.32xlarge	1,952	128	131,500
x1.16xlarge	976	64	65,750
r4.16xlarge	488	64	76,400
r3.8xlarge	244	32	31,920

非本稼働ワークロードの選択肢
インスタンスタイプ	メモリー (GiB)	vCPU	SAPS
r4.8xlarge	244	32	38,200
r4.4xlarge	122	16	19,100
r4.2xlarge	61	8	9,550
r3.4xlarge	122	16	15,960
r3.2xlarge	61	8	7,980

注 — SAP Business One, version for SAP HANAについてはこれ以外のインスタンスとメモリーサイズが利用可能です。このトピックは別のブログを参照してください。

ストレージ

AWSでは、SAP HANAの永続ブロックストレージに複数のオプションを用意しています。性能重視のデータやログボリューム用に2つのSSD-backed EBSボリュームタイプ(gp2とio1)があり、またSAP HANAバックアップ用にコスト最適化および高いスループットのHDD-backed EBSボリューム(st1)があります。

• 汎用SSD (gp2) ボリュームタイプでは、ボリュームあたり最大160MB/sのスループットを実現できます。TDIモデルの要件である最大400MB/sのスループットを達成するためには、SAP HANAのデータとログファイル用に3つのボリュームをストライピングする必要があります。
• プロビジョンドIOPS SSD (io1) ボリュームでは、ボリュームあたり最大320MB/sのスループットを提供し、スループット要件を満たすには少なくとも2つのボリュームをストライピングする必要があります。
• スループット最適化HDD (st1) ボリュームでは、大きなブロックサイズでのシーケンシャルな読み書きで最大500MB/sのスループットを実現できます。そのため、st1はSAP HANAバックアップの保存先に理想的な候補となります。

重要な点の1つとして、それぞれのEBSボリュームがAWSのアベイラビリティゾーン内で自動的に複製されることで、障害から保護され、高い可用性と耐久性を提供することがあります。 これにより、性能を最大限に引き出すためにオペレーティングシステムレベルでRAID 0アレイが構成でき、一方でボリュームの保護(RAID 10またはRAID 5)は心配する必要がなくなります。

ネットワーク

SAP HANAのネットワーク性能は、特にスケールアウト構成において重要な要素になります。すべてのEC2インスタンスは一定のネットワーク帯域幅を提供しており、X1のような最新のインスタンスファミリーでは、SAP HANAの要求に合わせて最大20 Gbpsのネットワーク帯域幅を提供します。さらに多くのインスタンスでは、Amazon EBSストレージ接続のための独立したネットワーク帯域幅を持っています。例えば、もっとも大きいX1インスタンス(x1.32xlarge)では、20 Gbpsのネットワーク帯域幅と10 Gbpsの専用ストレージ帯域幅を持ちます。 R4インスタンス(r4.16xlarge)では、20 Gbpsのネットワーク帯域幅と12 Gbpsの専用ストレージ帯域幅を持ちます。 以下はSAP認定インスタンスのネットワーク機能の簡単な概要になります。

本稼働ワークロードの選択肢

インスタンスタイプ	ネットワーク帯域幅 (Gbps)	EBS専用の帯域幅 (Gbps)
x1.32xlarge	20	10
x1.16xlarge	10	5
r4.16xlarge	20	12
r3.8xlarge	10*

* ネットワークとストレージのトラフィックは同じ10 Gbps ネットワークインターフェイスを共有

オペレーティングシステム(OS)

SAP社では、SUSE Linux Enterprise Server(SLES) またはRed Hat Enterprise Linux(RHEL)上でのSAP HANAの実行をサポートしています。どちらのOSディストリビューションもAWS上でサポートされます。さらに、お客様はAWS Marketplaceで提供されるSUSEまたはレッドハットのSAP HANA固有イメージを使って容易に開始することができます。また、お客様自身のOSサブスクリプションを持ち込むことも可能です。SAP HANA on AWSのOSに関する選択肢の詳細については、今後のブログ記事をご期待ください。

すべてをまとめて構築

“AWSがTDI同様にSAP HANAのビルディング・ブロックを提供するのは素晴らしいことですが、AWS上でこれらのコンポーネントをまとめてSAPの要件を満たすシステムを構築するにはどうすればよいですか？”と思うかもしれません。AWSのお客様からも数年前にこの質問を受けており、AWS Quick Start for SAP HANAを開発しました。 このクイックスタートでは、AWS CloudFormationテンプレート(Infrastructure as Code)とカスタムスクリプトを利用して、ストレージやネットワークを含むAWSインフラストラクチャ・コンポーネントの展開を支援します。クイックスタートは、SAP HANAインストールに必要となるオペレーティングシステムの設定も行います。また、お客様自身のSAP HANAソフトウェアとライセンスを持ち込むことで、SAP HANAソフトウェアのインストールもできます。クイックスタートは、世界中の多くのAWSリージョンで使用できるセルフサービスのツールです。SAP HANAシステムのインフラストラクチャの展開は、シングルノードであるかスケールアウトシステムであるかに関係なく、一貫して予測可能で繰り返し可能な方法で、1時間未満で提供されます。SAP HANAクイックスタートの実行は、AWS re:Invent 2016 カンファレンスにてSAP社との共同講演で実演した録画されたデモをご覧ください。

SAP HANAの構築には、AWSクイックスタートを利用したインフラストラクチャの展開を強く推奨します。ただし、クイックスタートを使用できない場合（たとえば、独自のOSイメージを使用する場合など）には、SAP HANA環境を手動で構築し、ビルディング・ブロックを自分で配置することができます。ストレージとインスタンスタイプについては必ずrecommendations in the Quick Start guideに従ってください。この特定の目的のために、SAP HANA on AWS – Manual Deployment Guideでステップ・バイ・ステップの手順も提供しています。(RHELを含む最新OSバージョンの手順を含む本ガイドはすぐに更新される予定です。)

バックアップとリカバリー

信頼性の高い方法でSAP HANAデータベースをバックアップおよびリストアする機能は、ビジネスデータを保護する上で非常に重要です。SAP HANA純正のツールを使用してデータベースをEBSボリュームにバックアップし、最終的にバックアップされたファイルをAmazon Simple Storage Service (Amazon S3)に移行することで、耐久性を高めることができます。Amazon S3は、スケーラビリティと耐久性に優れたオブジェクトストレージのサービスです。Amazon S3のオブジェクトは、リージョン内の複数の施設に重複して格納され、99.999999999の耐久性を実現します。Commvault、EMC NetWorker、Veritas NetBackup、IBM Spectrum Protect(Tivoli Storage Manager)などのエンタープライズクラスのバックアップソリューションを選択することもできます。これらのソリューションは、Amazon S3およびSAP HANA Backintインタフェースと統合されています。これらのパートナーソリューションは、SAP HANAデータベースをAmazon S3に直接バックアップし、エンタープライズクラスのソフトウェアを使用したバックアップ・リカバリーの管理に役立ちます。

高可用性(HA)と災害対策(DR)

HAとDRは、SAP HANA上で実行されるビジネスクリティカルなアプリケーションにとって重要です。AWSは、アップタイムとリカバリーの要件(RTO / RPO)に応じたHAとDRソリューションを構成できるよう、世界中の複数のAWSリージョンと各AWSリージョン内の複数のアベイラビリティゾーンを含むいくつかのビルディング・ブロックを提供しています。コスト最適化ソリューションまたはダウンタイム最適化ソリューションのどちらを探している場合でも、SAP HANA HA/DRアーキテクチャにいくつかの独自オプションを用意しています — これらの詳細については、SAP HANA HA/DR guideを参照してください。今後のブログ記事でこのトピックについて詳しく説明する予定です。

移行

実際の移行には、SAP標準のツールセットとして提供されるSAP Software Provisioning Manager(SWPM)やDatabase Migration Option(DMO) of the Software Update Manager(SUM)、または3rdパーティーの移行ツールを使って、任意のデータベースで実行されているSAPアプリケーションをSAP HANA on AWSに移行できます。 SAPのAWSへの移行プロセスは、一般的なオンプレミスの移行シナリオとほぼ変わりません。オンプレミスのシナリオでは、通常、同じデータセンター内にソースシステムとターゲットシステムが存在します。AWSに移行する場合の唯一の違いは、ターゲットシステムがAWS上に存在することです。そのため、AWSを自社のデータセンターの拡張と考えることができます。また、移行中に、オンプレミスのデータセンターでエクスポートされたデータをAWSに転送するための様々なオプションもあります。これらの選択肢の理解をより深めるために、Migrating SAP HANA Systems to X1 Instances on AWSを参照することをお勧めします。

その他の検討事項として、運用、サイジング、スケーリング、Amazon CloudWatchのようなAWSサービスとの統合、ビッグデータソリューションなどがあります。これらは今後のブログ記事で詳細を取り上げる予定です。それまでの間に、AWS Quick Start for SAP HANAを使ってSAP HANA on AWSを開始してみてはいかがでしょうか。AWS上で実行されるSAPワークロードの詳細については、SAP on AWS websiteのホワイトペーパーもご覧ください。

最後に、現在利用可能なシステムサイズを超えて拡張するシステムが必要な場合は、当社までご連絡ください。 私たちはお客様の要件について話し合い、その実装に関してご協力いただけることを嬉しく思います。

– Sabari