SAP ワークロードに Azure Premium Files NFS と SMB を使用する
このドキュメントでは、SAP ワークロードに使用される Azure Premium Files ファイル共有について説明します。 NFS ボリュームと SMB ファイル共有の両方について説明します。 SMB または NFS ボリューム用の Azure NetApp Files に関する考慮事項については、次の 2 つのドキュメントを参照してください。
重要
このドキュメントでのストレージ構成に関する提案は、最初の方向性を示すことを目的としています。 ワークロードを実行し、ストレージの使用パターンを分析すると、提供されているストレージ帯域幅または IOPS をすべて使用しているわけではないことに気付く場合があります。 その場合は、ストレージのダウンサイジングを検討してください。 逆に、これらの構成で推奨されているストレージ スループットよりも多くのスループットがワークロードに必要な場合もあります。 その結果、IOPS またはスループットを増やすために、より多くの容量をデプロイすることが必要になる場合があります。 必要なストレージ容量、必要なストレージ待ち時間、必要なストレージ スループットと IOPS、最も安価な構成のバランスの面で、ユーザーと SAP ワークロードにとって適切な妥協点を見つけ、それに合わせて調整できるように、Azure には機能や価格がそれぞれ異なるさまざまなストレージの種類が用意されています。
SAP ワークロードの場合、Azure Files 共有のサポート対象は次のとおりです。
- 分散 SAP システムの sapmnt ボリューム
- SAP ランドスケープのトランスポート ディレクトリ
- HANA スケールアウト用の /hana/shared。/hana/shared のサイズ設定に関する考慮事項を注意深く確認してください。適切にサイズ設定された /hana/shared ボリュームがシステムの安定性に寄与するためです。
- SAP ランドスケープと他のアプリケーション間のファイル インターフェイス
Note
SAP DBMS ワークロードは、Azure Premium Files ボリューム、NFS、SMB ではサポートされていません。 SAP NetWeaver または S/4HANA のアプリケーション レイヤーの Azure Storage の種類に対するサポートの制限については、SAP サポートのノート 2015553 を参照してください。
SAP による Azure Premium Files 共有に関する重要な考慮事項
Azure Files を使用したデプロイを計画する際は、次の重要な点を考慮してください。 このセクションの用語は、SMB 共有と NFS ボリュームの両方に適用されます。
- 共有の最小サイズは 100 ギビバイト (GiB) です。 Azure Premium Files では、プロビジョニングされた共有の容量に対して料金が発生します。
- 容量の要件だけでなく、IOPS とスループットの要件にも基づいてファイル共有のサイズを決定してください。 詳細については、Azure ファイル共有のターゲットに関するページを参照してください。
- ワークロードをテストしてサイズ設定を検証し、パフォーマンス目標を満たしていることを確認してください。 Azure Files 上の NFS のパフォーマンスの問題のトラブルシューティング方法については、Azure ファイル共有のパフォーマンスのトラブルシューティングに関する記事を参照してください。
- SAP システムごとに個別の
sapmnt
共有をデプロイします。 - 他のアクティビティ (インターフェイスなど) には
sapmnt
共有を使用しないでください。 - 他のアクティビティ (インターフェイスなど) には
saptrans
共有を使用しないでください。 - SAP システムのバッチ ジョブの負荷が高い場合は、ジョブ ログが数百万件になる可能性があります。 SAP のバッチ ジョブ ログがファイル システムに格納されている場合は、
sapmnt
共有のサイズ設定に特に注意してください。 SAP ノート 16083 に従って、ジョブ ログ ファイルを定期的に再編成してください。 SAP_BASIS 7.52 の時点では、バッチ ジョブ ログの既定の動作として、データベースに格納されます。 詳細については、SAP ノート 2360818 | データベースのジョブ ログに関する記事を参照してください。 - 1 つのストレージ アカウントに統合する共有の SAP システムの数が多くなり過ぎないようにします。 また、ストレージ アカウントでのスケーラビリティとパフォーマンスのターゲットもあります。 ストレージ アカウントの制限を超えないことにも注意してください。
- 一般に、1 つのストレージ アカウントに 5 つより多い SAP システムの共有を統合しないでください。 このガイドラインは、ストレージ アカウントの制限を超過しないようにするのに役立ち、パフォーマンス分析を簡略化します。
- 通常は、非実稼働と実稼働の SAP システム用の
sapmnt
のような共有は、同じストレージ アカウントに混在させないようにします。 - Azure Files を使ってプライベート エンドポイントを使用します。 万が一ゾーン障害が発生した場合、NFS セッションは自動的に正常なゾーンにリダイレクトされます。 NFS 共有を VM に再マウントする必要はありません。 プライベート リンクを使用すると、処理されたデータに対して追加料金が発生する可能性があります。プライベート リンクの価格に関するページを参照してください。
- VM を可用性ゾーンにデプロイする場合は、ZRS をサポートする Azure リージョンでストレージ アカウントと ZRS を使用します。
- Azure Premium Files では現在、ディザスター リカバリー シナリオにおけるリージョン間の自動レプリケーションはサポートされていません。 使用可能なオプションについては、SAP アプリケーションの DR に関するガイドラインを参照してください。
複数のアクティビティを 1 つのファイル共有または 1 つのストレージ アカウント内の複数のファイル共有に統合する場合は、慎重に検討してください。 これらの共有を個別のストレージ アカウントに分散させると、スループットと回復性が向上し、パフォーマンスの分析が簡単になります。 たくさんの SAP SID やファイル共有が 1 つの Azure Files Storage アカウントに統合されていて、スループットの制限に達したためにストレージ アカウントのパフォーマンスが低下した場合、問題の原因になっている SID またはボリュームを特定するのが困難になる可能性があります。
NFS に関するその他の考慮事項
- NFS クライアントの機能強化の恩恵を受けるために、SLES 15 SP2 以上、RHEL 8.4 以上にデプロイすることをお勧めします。
- マウントまたは接続の問題に使用できるトラブルシューティング情報を使用して、ドキュメントに記載されているマウント オプションを使って NFS 共有をマウントします。
- SAP J2EE システムの場合、Azure Files 上の NFS に
/usr/sap/<SID>/J<nr>
を配置することはできません。
SMB に関するその他の考慮事項
- Azure Files SMB を使用するには、SAP ソフトウェア プロビジョニング マネージャー (SWPM) バージョン 1.0 SP32、SWPM 2.0 SP09 以降が必要です。 SAPInst のパッチは 749.0.91 以降である必要があります。 SWPM/SAPInst がファイル共有サーバーについて 13 文字を超える文字を受け入れない場合は、SWPM のバージョンが古すぎます。
- SAP PAS インスタンスのインストール時に、SWPM/SAPInst によってトランスポート ホスト名の入力が要求されます。 ストレージ アカウントの FQDN は、<storage_account>.file.core.windows.net と入力されているか、プライベート エンドポイントの IP アドレス/ホスト名を使用している必要があります (使用する場合)。
- Active Directory ドメインを、SAP 高可用性デプロイ用に Azure Files SMB と統合する場合は、SAP ユーザーとグループを 'sapmnt' 共有に追加する必要があります。 SAP ユーザーには、Azure portal でアクセス許可
Storage File Data SMB Share Elevated Contributor
が設定されている必要があります。
次のステップ
詳細については、次を参照してください。