

# 14 – 最適なストレージソリューションを選択する
<a name="design-principle-14"></a>

 **SAP のワークロードに最適なストレージソリューションをどのように選択すればよいのでしょうか?** このストレージをどのように設定するかは、システムのパフォーマンスに影響します。AWS はブロック、ファイル、オブジェクトストレージなど幅広いサービスを提供し、お客様の SAP データベース、アプリケーション、バックアップのストレージニーズに応えます。SAP によってベンチマークおよび認定されたガイドラインに従うことをお勧めします。SAP HANA の場合、非常に具体的なガイドラインがあります。その他のデータベースでは、ワークロードに合わせたより多くの分析が必要になります。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-14.html)

# ベストプラクティス 14.1 – 機能に合わせてマウントポイントとボリュームの関連付けを作成する
<a name="best-practice-14-1"></a>

 SAP ファイルシステムには、独自のパフォーマンスと共有の要件があります。例えば、データベースのパフォーマンスプロファイルでは、データファイルシステムは多くの読み取り I/O オペレーションをサポートする必要がありますが、ログファイルシステムはスループットに制約される可能性が高くなります。すべてのアプリケーションサーバーがログやトランスポートファイルにアクセスできるように、 `sapmnt` と `trans` などのファイルシステムを共有する必要があります。これらの違いを認識した上で、ファイルシステムとボリュームのマッピングを検討し、パフォーマンスのボトルネックがないこと、アクセス要件が満たされていることを確認する必要があります。 

 **提案 14.1.1 – 各システムの SAP ファイルシステムおよびディレクトリの要件を確認する** 

 SAP のファイルシステムには、システムディレクトリ (ルート、ブート)、実行ファイル、ページまたはスワップ、およびアプリケーション固有の要件が含まれています。それぞれを分析して検討する必要があります。 
+ 特にルートディレクトリの場合に、ファイルシステムの容量がいっぱい (100% 使用) の場合の影響
+ 構築の一貫性 (AMI に含まれているかどうか、またはデプロイパターンに含まれているかどうかを含む)
+ 回復力の要件
+ 共有の要件
+ パフォーマンスプロファイル

コア SAP ファイルシステム要件は SAP ドキュメントに記載されています: SAP Required Filesystems and Directories.これらをベースラインとして使用し、組織固有のその他の要件を含めてください。

 **提案 14.1.2 – ファイルシステムの機能に合わせて、適切な AWS ストレージサービスをマッピングする** 

ファイルシステムは、ローカルまたは共有 (NFS/SMB) のいずれかになります。共有ファイルシステムの場合は、Amazon EFS や Amazon FSx などの AWS のサービスの使用を検討してください。これらのサービスは、ホストされている NFS サーバーと比較して信頼性と可用性の利点を提供します。

Amazon EC2 インスタンスストアは、インスタンスのための一時的なブロックレベルのストレージを提供する別のファイルシステムのオプションです。永続性、インスタンスタイプ間での可用性がなく、インスタンスの復旧を使用できないため、これを使用することは推奨しません。

 **提案 14.1.3 – サポートされているファイルシステムの種類を使用する** 

 SAP がサポートする Linux ディストリビューションは、さまざまなタイプのファイルシステムを推奨しています。それ以降のバージョンでは XFS 上で標準化していますが、OS やデータベースのバージョンによってパフォーマンスや機能に影響がないことを確認し、サポートを検討する必要があります。 
+  SAP Note: [405827 - Linux: Recommended file systems (Linux: 推奨されるファイルシステム)](https://launchpad.support.sap.com/#/notes/405827) [SAP ポータルへのアクセス権が必要] 
+  SAP Note: [2972496 - SAP HANA Filesystem Types (SAP HANA ファイルシステムのタイプ)](https://launchpad.support.sap.com/#/notes/2972496) [SAP ポータルへのアクセス権が必要] 

# ベストプラクティス 14.2 – パフォーマンス要件に沿った EBS タイプを選択し、設定する
<a name="best-practice-14-2"></a>

ファイルシステム機能とストレージサービスごとに、ストレージレイアウトのガイドラインとチューニングオプションを評価し、IOPS とスループットパフォーマンスが最適化されていることを確認します。

 **提案 14.2.1 – EBS ボリュームタイプのストレージ特性およびオプションを評価する** 

AWS には、SAP ワークロードのさまざまなパフォーマンス要件に対応するため、独自の特性を持つさまざまなボリュームタイプがあります。過去のデータ、またはサイジングを使用して、IOPS とスループットの要件を評価します。パフォーマンス、耐久性、柔軟性、コストなどを考慮し、ボリュームタイプを選択します。

 次の `gp3、` io1 `と` io2 `ボリュームタイプの` IOPS とスループットは、ボリュームサイズに依存しません。 

 次の `IOPS とスループットは、` ボリュームサイズに合わせます。必要な IOPS とスループットを確保するために、ボリュームのオーバーサイズが必要な場合があります。 
+  AWS ドキュメント: [Amazon EBS ボリュームのタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) 

 **提案 14.2.2 – LVM ストライピングメカニズムを使用して線形に拡大する** 

単一の EBS ボリュームでパフォーマンス要件を満たせない場合は、Logical Volume Management (LVM) を使用したストライピングを検討します。例えば、1 つのボリュームが 250 MiB/s のスループット容量を持つ場合、4 つのボリュームにまたがってストライプセットを持つことで 1000 MiB/s のスループットを実現できます。

ボリュームは同じサイズとパフォーマンス特性である必要があります。

SAP HANA のベンチマークテストでは、データボリュームに 256 KB のストライプサイズ、ログボリュームに 64 KB のストライプサイズを使用した場合に、最高のパフォーマンスを得ることができました。

 スループット、I/O、添付されたボリューム数などのインスタンス制限に注意してください。 
+  AWS ドキュメント: [EBS ボリュームに LVM 論理ボリュームを作成する](https://aws.amazon.com/premiumsupport/knowledge-center/create-lv-on-ebs-volume/) 
+  SAP Note: [2931808 - Usage of Logical Volume Manager (LVM) with SAP HANA (SAP HANA での Logical Volume Manager (LVM) の使用)](https://launchpad.support.sap.com/#/notes/2931808) [SAP ポータルへのアクセス権が必要] 
+  AWS ドキュメント: [オペレーティングシステムとストレージ設定 - SAP HANA on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/operating-system-and-storage-configuration.html#:~:text=Configure%20Storage%20for%20SAP%20HANA) 

 **提案 14.2.3 – SAP HANA のパフォーマンスを確保するために、AWS が提供するストレージのガイドラインに従う** 

 AWS は SAP と連携し、定義されたパフォーマンスベンチマークに従って SAP HANA ワークロード用のストレージを認証しています。AWS が提供する設定は、SAP TDI 5 Storage KPI のフレームワークの中で、パフォーマンス、コスト、耐久性のバランスを取っています。準拠しているストレージのレイアウトは、ドキュメントで詳しく説明されており、起動ウィザードやクイックスタートのデプロイで使用されています。 
+  AWS ドキュメント: [SAP HANA のストレージ設定 - SAP HANA on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/hana-ops-storage-config.html) 

 AWS の設定から逸脱する場合は、ハードウェアチェックツールを実行することをお勧めします。 
+  SAP Note: [1943937 - Hardware Configuration Check Tool - Central Note (ハードウェア設定チェックツール - Central Note)](https://launchpad.support.sap.com/#/notes/1943937) [SAP ポータルへのアクセス権が必要] 

汎用 SSD とプロビジョンド IOPS SSD のどちらを選ぶかを決める際には、汎用 SSD が SAP KPI を満たしていることを理解することが重要です。SAP HANA などのインメモリデータベースは、データベースのスタートアップ時にディスクからメモリにデータをロードする必要があります。パフォーマンスの高いストレージソリューションと設計は、スタートアップ時間を大幅に改善し、バックアップや復元など、ストレージのパフォーマンスに依存するタスクも高速化することができます。

大規模なシステムや非常に高いアップタイムが要求されるシステムでは、プロビジョンド IOPS が有効な場合があります。最適なデプロイパターンについての詳しいガイダンスは、AWS チームにお問い合わせください。

 ** 提案 14.2.4 – 低コストで高性能なローカルバックアップを実現するには、以下を使用します。 `st1` ストレージ ** 

 SAP ソリューションでバックアップを保存するためにローカルストレージが必要な場合、低コストで高いスループットを実現する `st1` インスタンスタイプの利用を検討してください。 `st1` は、アクセス頻度が高く、スループット重視のワークロード向けに設計された低コストのブロックストレージタイプです。 

SAP HANA の場合は、AWS Backint Agent for SAP HANA の使用を検討し、2 段階バックアップによるパフォーマンスとコストへの影響を回避してください。

# ベストプラクティス 14.3 - Amazon EFS と Amazon FSx のパフォーマンスが SAP のユースケースに適しているかどうかを評価する
<a name="best-practice-14-3"></a>

Amazon EFS (Linux) と Amazon FSx (Windows) は、複数のアベイラビリティーゾーンにまたがることができる、耐久性と可用性の高いファイルシステムを提供します。どちらのソリューションも高いパフォーマンスを発揮するように設計されていますが、ネットワークファイルシステムを選択する際には、アクセスパターンを検討してください。例えば、多くの小さなファイル、高度な並列書き込み、または高い書き込み/読み取り比率は適切でない場合があります。SAP ワークロードの場合、SAP HANA XSA、Java 実行ファイル、大量のジョブログやスプールログが該当する可能性があります。

 **提案 14.3.1 – スケールとパフォーマンスのオプションを評価する** 

 Amazon EFS には、パフォーマンスに関する 2 つのモード (汎用と最大 I/O) と、2 つの異なるパフォーマンスモード (バーストモードとプロビジョニング) があります。SAP アプリケーションの場合、通常、汎用パフォーマンスモードで十分な I/O が得られます。ファイルシステムのデータ量がスループット要求に対して少ない場合など、プロビジョニングスループットを検討する必要のあるシナリオがあるかもしれません。 
+  AWS ドキュメント: [Amazon Elastic File System (EFS) \$1 よくある質問 - スケールとパフォーマンス](https://aws.amazon.com/efs/faq/#Scale_and_performance) 
+  AWS ドキュメント: [Amazon FSx for Windows ファイルサーバーの特徴 \$1 スケールとパフォーマンス](https://aws.amazon.com/fsx/windows/features/#Performance_and_scale) 

 **提案 14.3.2 - 短期的な必要性に応じて、一時的なプロビジョニングを検討する** 

移行や 1 回限りのアクティビティに関連するユースケースでは、イベントの期間中、パフォーマンス特性を調整できる一時ファイルシステムが有効の場合があります。

# ベストプラクティス 14.4 – ストレージの代わりにメモリを検討する
<a name="best-practice-14-4"></a>

データベースやアプリケーションレイヤーでサポートされるシナリオにメモリを使用することによるパフォーマンス上の利点を検討します。SAP HANA はデフォルトでメモリを使用しますが、ロードを最適化したり、静的データをオフロードしたりするオプションが有効な場合があります。リレーショナルデータベースはキャッシングを利用する必要があり、アプリケーションサーバーはスワップが要件であるかどうかを検討する必要があります。

 **提案 14.4.1 – SAP HANA のメモリ使用量を最適化する** 

 SAP HANA のメモリ要件とオペレーティングシステムのメモリ指標との相関関係を把握し、メモリのボトルネックがパフォーマンスに影響を与えないようにします。 
+  SAP ドキュメント: [SAP HANA Memory Usage and the Operating System (SAP HANA のメモリ使用量とオペレーティングシステム)](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/ca10596b37f04909a96614553cb8ab1d.html#:~:text=Virtual%2C%20Physical%2C%20and%20Resident%20Memory&text=On%20most%20SAP%20HANA%20hosts,operational%20use%20by%20a%20process.) 
+  SAP Note: [1999997 - FAQ: SAP HANA Memory (よくある質問: SAP HANA メモリ)](https://launchpad.support.sap.com/#/notes/1999997) [SAP ポータルへのアクセス権が必要] 

 ホストの再起動を伴わないシナリオでデータベースのスタートアップパフォーマンスを向上させるには、SAP HANA Fast Restart オプションの使用を検討します。SAP HANA Fast Restart オプションは、RAM の一部を一時ファイルシステム ( `tempfs` ) として専用化し、オペレーティングシステムによって持続的メモリ (オペレーティングシステムの再起動まで) として扱われ、列ストアメイン部分をその `tempfs` に配置することができ、インデックスサーバーの再起動またはクラッシュまでその状態を維持します。そのため、ストレージからの再読み込み (I/O を使用) は必要ありません。 
+  SAP ドキュメント: [HANA Fast Restart ドキュメント](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/ce158d28135147f099b761f8b1ee43fc.html) 

 **提案 14.4.2 – リレーショナルデータベースでデータベースキャッシュを利用する** 

高い読み取り IOP を必要とするリレーショナルデータベースでは、データベースキャッシングにより、スループットを大幅に向上させ、データ検索のレイテンシーを低減することができます。キャッシュは、データベースの隣接データアクセスレイヤーとして機能し、読み取りパフォーマンスを向上させます。

 以下のドキュメントでは、キャッシュの使用例に関する情報を提供していますが、この詳細のほとんどは AWS データベースに関連しているため、リレーショナルデータベース構成に固有の情報については、SAP Notes を参照してください。
+  AWS ドキュメント: [キャッシュ](https://aws.amazon.com/caching/) (以下が含まれます [データベースのキャッシング](https://aws.amazon.com/caching/database-caching/) ) 

 **提案 14.4.3 – SAP アプリケーションのスワップ領域の必要性を評価する** 

物理メモリリソースが枯渇すると、SAP はスワップを使用して非アクティブなページをディスクベースの専用ストレージエリアに移動させます。スワップはメモリ不足によるアプリケーションのクラッシュを防ぐことができますが、スワップが頻繁に使用されないように設定パラメータとメモリサイジングを適用することをお勧めします。

 スワップの使用が予想される場合、割り当てられたボリュームの特性を評価し、さらなるパフォーマンスの問題を回避してください。スワップは、SAP アプリケーションでホストの物理メモリが不足した場合に、メモリ不足の状況を回避することができます。 
+  SAP Note: [153641 - Swap space requirement for R/3 64-bit kernel (R/3 64 ビットカーネルに必要なスワップ領域)](https://launchpad.support.sap.com/#/notes/153641) [SAP ポータルへのアクセス権が必要] 
+  SAP Note: [2999334 - SWAP Utilization (SWAP 使用率)](https://launchpad.support.sap.com/#/notes/2999334) (HANA 関連) [SAP ポータルアクセスが必要] 
+  SAP Note: [2488097 - FAQ: Memory usage for the ABAP Server on Windows (よくある質問: Windows 版 ABAP サーバーのメモリ使用量)](https://launchpad.support.sap.com/#/notes/2488097) [SAP ポータルへのアクセス権が必要] 

# ベストプラクティス 14.5 – 適切なバックアップソリューションとスケジュールを選択する
<a name="best-practice-14-5"></a>

バックアップの方法によっては、ストレージの読み取りと書き込みオペレーションの両方が大幅に増加する可能性があり、アプリケーションのパフォーマンスに悪影響を与える可能性があります。これは、ボリュームが大きく、期間が長いデータベースレベルのバックアップに特に当てはまります。

 **提案 14.5.1 – 適切なバックアップウィンドウを決定する** 

ビジネス要件に沿ったバックアップオペレーションを実行するために、最も適切なウィンドウを定義します。夜間バッチスケジュールや許容ランタイムなど、重要な依存関係を検討します。

 **提案 14.5.2 – バックアップのパフォーマンスへの影響を最小限に抑えるためのオプションを検討する** 

 ストレージやネットワークの制約を分析し、バックアップの影響を最小化するためのオプションを評価します。これには、データベースまたはストレージレベルでのデルタチェンジバックアップを使用することで、期間を短縮することが含まれる場合があります。信頼性の柱を参照して、バックアップの一貫性や全体の復元時間に悪影響を与えないようにしてください。 
+  SAP Lens [信頼性]: [ベストプラクティス 12.1 - ビジネスデータの一貫した復旧方法を確立する](best-practice-12-1.md) 