SAP ワークロードの Azure Storage の種類

Azure には、機能、スループット、待機時間、価格が大幅に異なるさまざまな種類のストレージがあります。 ストレージの種類の中には、SAP シナリオでは使用できないものや、制限付きで使用できるものがあります。 一方、いくつかの Azure Storage の種類が、特定の SAP ワークロードのシナリオ用として適切であるか、または最適化されています。 特に SAP HANA に関して、一部の Azure Storage の種類は SAP HANA での使用の認定を受けています。 このドキュメントでは、さまざまな種類のストレージを取り上げて、SAP ワークロードと SAP コンポーネントに対する機能と使用可能性について説明します。

この記事全体を通して使用する単位について解説します。 パブリック クラウド ベンダーは、ギガバイトまたはテラバイトではなく、GiB (ギビバイト) または TiB (テビバイト) を使用するように移行しました。 そのため、Azure のすべてのドキュメントと価格で、これらの単位を使用しています。 このドキュメント全体を通して、サイズの単位として MiB、GiB、TiB という単位だけに言及します。 MB、GB、TB を使用して計画することが必要な場合もあります。 そのため、250 MiB/秒のスループットではなく、400 MiB/秒のスループットのサイズを指定する必要がある場合は、計算に少し違いがあることにご注意ください。

Microsoft Azure Storage の回復性

Standard HDD、Standard SSD、Azure Premium Storage、Premium SSD v2、Ultra Disk を使用する Microsoft Azure Storage では、ベース VHD (OS を含む) と VM にアタッチされたデータ ディスクまたは VHD (仮想ハード ディスク) が、3 つの異なるストレージ ノード上の 3 つのコピーに保持されます。 ストレージ ノード障害が発生した場合の、別のレプリカへのフェールオーバーと新しいレプリカのシード処理は透過的です。 この冗長性の結果、複数の Azure ディスクにわたるどのような種類のストレージ冗長レイヤーも使用する必要はありません。 これは、ローカル冗長ストレージ (LRS) と呼ばれます。 LRS は、Azure 内のこれらの種類のストレージの既定になっています。 Azure NetApp Files では、他のネイティブ Azure Storage と同じ SLA (サービス レベル アグリーメント) を実現する十分な冗長性が提供されます。

この他に、Azure で提供されるさまざまなストレージの種類の一部に適用されるいくつかの冗長化の方法があり、それらはすべて Azure Storage のレプリケーションに関する記事で説明されています。

「仮想マシンの SLA」でリリースされたシングル VM 可用性 SLA にさまざまな種類の Azure ストレージが影響を与えることにもご留意ください。

Azure Managed Disks

マネージド ディスクは Azure Resource Manager のリソースの種類で、Azure ストレージ アカウントに格納されている VHD の代わりに使用できます。 マネージド ディスクは、アタッチ先の仮想マシンの [可用性セット][virtual-machines-manage-availability] に自動的に配置されます。 このような配置により、仮想マシンの可用性と仮想マシンで実行されているサービスが向上します。 詳細については、概要についての記事を参照してください。

SAP ワークロードでのストレージ シナリオ

Azure にデプロイするスタックのさまざまなコンポーネント内の SAP ワークロードで、永続化されたストレージが必要です。 このようなシナリオとして、少なくとも次のようなものがあります。

• VM のベース VHD (そのディスクにインストールしたオペレーティング システムとその他のソフトウェアを保持する) を永続化します。 このディスクまたは VHD は、VM のルートです。 それに対して加えられた変更は、すべて永続化される必要があります。 そうすることで、次に VM を停止して再起動したときに、それまでに加えられたすべての変更が引き続き存在しています。 VM が最初に実行されていたものとは別のホストに Azure によってデプロイされる場合、特にそうです。
• 永続化されたデータ ディスク。 これらのディスクは、アプリケーション データを格納するためにアタッチする VHD です。 このアプリケーション データは、データベースのデータおよびログ (または再実行) ファイル、バックアップ ファイル、またはソフトウェア インストールである可能性があります。 オペレーティング システムを保持するベース VHD 以外の任意のディスクを意味します。
• NetWeaver または S/4HANA のグローバル トランスポート ディレクトリを含むファイル共有または共有ディスク。 これらの共有の内容は、複数の VM で実行されているソフトウェアによって使用されるか、高可用性フェールオーバー クラスターのシナリオを構築するために使用されます。
• EDI (電子データ交換) プロセスや類似するもの用の、/sapmnt ディレクトリまたは一般的なファイル共有。 これらの共有の内容は、複数の VM で実行されているソフトウェアによって使用されるか、高可用性フェールオーバー クラスターのシナリオを構築するために使用されます。

次のいくつかのセクションで、4つの SAP ワークロード シナリオに応じたさまざまな Azure Storage の種類と、それらの使用可能性について説明します。 さまざまな種類の Azure Storage の用途を表す一般的な分類については、「Azure で利用できるディスクの種類」を参照してください。 SAP ワークロードに対して使用する Azure Storage の種類が違っても、推奨事項が大きく異なることはありません。

SAP NetWeaver または S/4HANA のアプリケーション レイヤーの Azure Storage の種類に対するサポートの制限については、SAP サポートのノート 2015553 を参照してください。 SAP HANA で認定され、サポートされている Azure Storage の種類については、記事「SAP HANA Azure 仮想マシンのストレージ構成」を参照してください。

さまざまな Azure Storage の種類を説明するセクションでは、SAP でサポートされているストレージを使用した場合の制限事項と可能性について、追加の背景情報を提供します。

DBMS レプリケーション使用時のストレージ選択肢

Microsoft の参照アーキテクチャでは、SQL Server Always On、HANA System Replication、Db2 HADR、Oracle Data Guard など、DBMS (データベース管理システム) 機能の使用を予測しています。 2 つ以上の Azure 仮想マシン間でこれらのテクノロジを使用している場合、VM ごとに選択されるストレージの種類は同じにする必要があります。 つまり、DBMS HA 構成のアクティブ ノードとレプリカ ノードの間のストレージ構成は同じである必要があります。

SAP ストレージ シナリオのストレージに関する推奨事項

詳細に進む前に、ドキュメントの冒頭にあらかじめ概要と推奨事項を示します。 その一方このドキュメントでは、このセクションの後に特定の種類の Azure Storage に関する詳細を示します。 SAP ストレージ シナリオのストレージに関する推奨事項をまとめて表にすると、次のようになります。

¹ ログまたは再実行ログ ボリューム用の M または Mv2 VM ファミリでは Azure 書き込みアクセラレータを使用します。

さまざまな種類のストレージに期待できる特性は、次のようになります。

¹ ログまたは再実行ログ ボリューム用の M または Mv2 VM ファミリでは Azure 書き込みアクセラレータを使用します。

² 複数の異なる Azure NetApp Files 容量プールを作成しても、容量プールが複数の異なるストレージ ユニットにデプロイされる保証はありません

³ Premium SSD v2 または Ultra Disk の (増分) スナップショットは、作成後すぐに使用することはできません。 スナップショットからディスクを作成する前に、バックグラウンド コピーが完了している必要があります

Azure Premium Storage

Azure Premium SSD は、以下のことを実現する目的で導入されました。

• 少ない I/O 待機時間
• IOPS とスループットの SLA
• I/O 待機時間の変動の低減

この種類のストレージは、DBMS ワークロード、1 桁台前半のミリ秒の待機時間を必要とするストレージ トラフィック、IOPS とスループットに関する SLA を対象としています。 Azure Premium Storage のコスト単位はディスクに保存されている実際のデータ ボリュームではなく、ディスクのサイズ カテゴリで決まります (ディスクに保存されているデータの量には関係しません)。 なお、Premium Storage では、「Premium SSD」の記事に示されているサイズ カテゴリに直接マップされないディスクを作成することもできます。 この記事からの結論は次のとおりです。

• ストレージは範囲別に編成されています。 たとえば、容量が 513 GiB から 1,024 GiB までの範囲にあるディスクでは、同じ機能と同じ月額コストが共有されます。
• GiB あたりの IOPS は、サイズ カテゴリ間で線形になりません。 32 GiB より小さいディスクの場合、GiB あたりの IOPS レートが高くなります。 32 GiB を超えて 1,024 GiB までのディスクの場合、GiB あたりの IOPS レートは、GiB あたり 4 から 5 IOPS です。 32,767 GiB までの大容量ディスクになると、GiB あたりの IOPS レートは 1 を下回るようになります。
• このストレージの I/O スループットは、ディスク カテゴリのサイズに対して線形ではありません。 容量が 65 GiB から 128 GiB の間のカテゴリのような小容量ディスクの場合、スループットは GiB あたり約 780 KB です。 一方、32,767 GiB ディスクのような非常に大容量のディスクでは、スループットは GiB あたり約 28 KB です
• ディスクの容量を変更せずに IOPS とスループットの SLA を変更することはできません。

SAP ワークロードの機能マトリックスは次のようになります。

Azure Premium Storage では、Azure Premium Storage で提供される一般的なキャッシュの種類を使用して SAP HANA ストレージの待機時間 KPI が満たされることはありません。 SAP HANA ログ書き込みのストレージ待機時間 KPI を満たすためには、「書き込みアクセラレータを有効にする」の説明に従って、Azure 書き込みアクセラレータのキャッシュを使用する必要があります。 Azure 書き込みアクセラレータによって他のすべての DBMS システムに、トランザクション ログの書き込みと再実行ログの書き込みに関するメリットがもたらされます。 そのため、すべての SAP DBMS デプロイで使用することをお勧めします。 SAP HANA の場合、/hana/log の Azure 書き込みアクセラレータを Azure Premium Storage と組み合わせて使用することが必須です。

概要: Azure Premium Storage は、SAP ワークロード用に推奨される Azure Storage の種類の 1 つです。 この推奨事項は、非運用と運用の両方のシステムに適用されます。 Azure Premium Storage は、データベースのワークロードを処理するのに適しています。 Azure 書き込みアクセラレータの使用により、Azure Premium ディスクに対する書き込み待機時間が大幅に短縮されます。 ただし、IOPS とスループット レートが高い DBMS システムの場合は、ストレージ容量を過剰にプロビジョニングする必要があります。 または、Windows 記憶域スペースや Linux の論理ボリューム マネージャーのような機能を使用して、一方に必要な容量を付与するストライプ セットを構築する必要があります。 ただし、コスト効率を最大限に高めるには、相応な IOPS またはスループットも必要です。

Premium Storage の Azure バースト機能

容量が 512 GiB 以下の Azure Premium Storage ディスクの場合、バースト機能が提供されます。 ディスク バーストの動作の詳細については、「ディスク バースト」をご覧ください。 この記事を読むと、I/O ワークロードがディスクの公称 IOPS およびスループットを下回っているときの、IOPS とスループットの蓄積の概念を理解できます (公称スループットの詳細については、「Managed Disks の価格」をご覧ください)。 現在の使用量とディスクの公称値との差分だけ、IOPS とスループットが蓄積されます。 バーストは最大 30 分に制限されています。

このバースト機能を計画できる理想的なケースとして、別の DBMS のデータ ファイルを含むボリュームまたはディスクが考えられます。 特に、小規模から中規模のシステムで、これらのボリュームに対して予想される I/O ワークロードは次のとおりです。

• データはメモリにキャッシュされるのが理想的であるため、低から中程度の読み取りワークロード。 または、SAP HANA のように完全にメモリ内で処理される必要があります
• 定期的に発行されるデータベースのチェックポイントまたはセーブポイントによってトリガーされる書き込みのバースト
• ストレージ スナップショットを使用してバックアップが実行されない場合に、連続ストリームを読み取るバックアップ ワークロード
• SAP HANA の場合、インスタンスの再起動後のメモリへのデータの読み込み

特に、ワークロードが 1 秒あたり数百個のトランザクションしか処理しない小規模な DBMS システムでは、トランザクション ログまたは再実行ログを格納するディスクまたはボリュームでも、このようなバースト機能は意味があります。 このようなディスクまたはボリュームに対して予想されるワークロードは次のとおりです。

• アプリケーションによって発行されるすべてのコミットによって I/O 操作がトリガーされる可能性が高いため、ワークロードとワークロードの性質に依存するディスクへの定期的な書き込み
• インデックスの作成や再構築などの運用タスクでのスループットの高いワークロード
• トランザクション ログまたは再実行ログのバックアップを実行するときの読み取りバースト

Azure Premium SSD v2

Azure Premium SSD v2 ストレージは、次の目的で導入された新しいバージョンの Premium Storage です。

• I/O サイズをミリ秒未満にして読み取りと書き込みの I/O サイズを小さくする
• IOPS とスループットの SLA
• プロビジョニングされた GB 単位で容量を支払う
• ディスクごとに IOPS とストレージ スループットの既定のセットを提供する
• 各ディスクにより多くの IOPS とスループットを追加し、この追加のプロビジョニングされたリソースに対して個別に支払えるようにする
• Azure 書き込みアクセラレータや他のキャッシュなどの機能の助けを借りずに SAP HANA 認定に合格する

この種類のストレージは、DBMS ワークロード、ミリ秒未満の待機時間を必要とするストレージ トラフィック、IOPS とスループットに関する SLA を対象としています。 Premium SSD v2 ディスクは、既定の 3,000 IOPS と 125 MBps スループットのセットで提供されます。 また、個々のディスクにより多くの IOPS とスループットを追加できます。 ストレージの価格は、スループットまたは IOPS の追加が価格に大きく影響しないように構成されています。 それでも、Premium SSD v2 のストレージ構成をどうするかを決定する余地が残されています。 基本で開始するには、「SAP HANA Azure 仮想マシンの Premium SSD v2 のストレージ構成」を参照してください。

実際のリージョンでは、この新しいブロック ストレージの種類を使用できます。実際の制限については、「Premium SSD v2」のドキュメントを参照してください。

SAP ワークロードの機能マトリックスは次のようになります。

¹ Premium SSD v2 または Ultra Disk の (増分) スナップショットは、作成後すぐに使用することはできません。 スナップショットからディスクを作成する前に、バックグラウンド コピーが完了している必要があります

Azure Premium Storage とは反対に、Azure Premium SSD v2 は SAP HANA のストレージ待機時間 KPI を満たします。 その結果、「書き込みアクセラレータを有効にする」の記事の説明のとおりに Azure 書き込みアクセラレータのキャッシュを使用する必要はありません。

概要: Azure Premium SSD v2 は、SAP ワークロードに最適な価格対パフォーマンス比に適合するブロック ストレージです。 Azure Premium SSD v2 は、データベースのワークロードを処理するのに適しています。 ミリ秒未満の待機時間は、要求の厳しい DBMS ワークロードに最適なストレージです。 ただし、これは 2022 年 11 月にリリースされた新しいストレージの種類です。 したがって、今後数か月間に解決される制限がまだ存在する可能性があります。

Azure Ultra Disk

Azure Ultra Disk では、Azure IaaS VM 用に高スループット、高 IOPS、一貫性のある低待機時間のディスク ストレージが提供されます。 Ultra Disk のその他のメリットとして、仮想マシン (VM) を再起動する必要なしに、ワークロードに合わせてディスクの IOPS とスループットを動的に変更できます。 Ultra Disk は、SAP DBMS ワークロードなどのデータ量の多いワークロードに適しています。 Ultra ディスクはデータ ディスクとしてのみ使用でき、オペレーティング システムを格納するベース VHD ディスクとしては使用できません。 Azure Premium Storage をベース VHD ディスクとして使用することをお勧めします。

Ultra ディスクを作成するとき、次の 3 つのディメンションを定義できます。

• ディスクの容量。 範囲は 4 GiB から 65,536 GiB までです。
• ディスクに対してプロビジョニングされた IOPS。 ディスク容量には、さまざまな最大値が適用されます。 詳細については、「Ultra Disk」の記事を参照してください。
• プロビジョニングされたストレージ帯域幅。 ディスクの容量に応じて、さまざまな最大帯域幅が適用されます。 詳細については、「Ultra Disk」の記事を参照してください。

1 個のディスクのコストは、特定のディスクに対して個別に定義できる 3 つのディメンションによって決まります。

SAP ワークロードの機能マトリックスは次のようになります。

¹ Premium SSD v2 または Ultra Disk の (増分) スナップショットは、作成後すぐに使用することはできません。 スナップショットからディスクを作成する前に、バックグラウンド コピーが完了している必要があります

概要: Azure Ultra Disk はミリ秒未満の待機時間が少なく、すべての種類の SAP ワークロードに適切なストレージです。 これまでは、Availability Zones (ゾーン デプロイ) を使用してデプロイした VM との組み合わせでのみ、Ultra Disk を使用できました。 Ultra Disk は他のすべてのストレージとは逆で、ベース VHD ディスクには使用できません。 I/O ワークロードの変動が大きく、デプロイされたストレージのスループットまたは IOPS を、帯域幅と IOPS を最大使用量に合わせてサイズ変更するのではなく、ストレージのワークロード パターンに合わせて調整する場合、Ultra Disk が最適です。

Azure NetApp Files

Azure NetApp Files は、Azure ネイティブのファーストパーティ製でエンタープライズクラス、ハイパフォーマンスのファイル ストレージ サービスであり、SAP HANA での使用が認定されています。 NetApp アカウント、容量プール、ボリュームを作成する "サービスとしてのボリューム" が提供されます。 Azure NetApp Files を使用して、サービスとパフォーマンスのレベルを選び、データ保護を管理して、使い慣れたプロトコルとオンプレミスで使われる同じツールを使って、ハイ パフォーマンス、高可用性、スケーラブルなファイル共有を作成して管理します。

Azure NetApp Files ボリュームでは、次の種類の SAP ワークロードがサポートされています。

• SAP DBMS ワークロード
• SAPMNT 共有
• グローバル トランスポート ディレクトリ

Azure NetApp Files は、それぞれ独自のスループットと価格仕様を持つ 3 つのサービス レベルで利用できます。 どのレベルがデプロイに適しているかは、デプロイのサイズによって異なります。 カスタマイズされたサイズ設定に関する推奨事項は、SAP on Azure NetApp Files TCO 見積もりツールで入手できます。

サービス レベルの詳細については、「Azure NetApp Files のサービス レベル」を参照してください。

ボリュームのデプロイ

最適な結果を得るには、SAP HANA のアプリケーション ボリューム グループを使用してボリュームをデプロイします。 アプリケーション ボリューム グループは、アフィニティ ルールとアンチアフィニティ ルールを使用して Azure インフラストラクチャ内の最適な場所にボリュームを配置して、競合を減らし、最適なスループットと最短の待機時間を確保します。

Azure NetApp Files は、次のようにさまざまな SAP ワークロードのシナリオに対してサポートされています。

• /hana/data および /hana/log ボリュームおよび /hana/shared ボリューム用に NFS 共有を使用する SAP HANA デプロイ (「SAP HANA Azure 仮想マシンのストレージ構成」を参照)
• SAP のグローバル トランスポート ディレクトリに SMB または NFS 共有を提供する
• 次のドキュメントに記載されているような高可用性シナリオでの共有 sapmnt:
  • SAP アプリケーション用の Azure NetApp Files (SMB) を使用した Windows 上の Azure VM における SAP NetWeaver の高可用性
  • SAP アプリケーション用の Azure NetApp Files を使用した SUSE Linux Enterprise Server 上の Azure VM 上の SAP NetWeaver の高可用性
  • SAP アプリケーション用の Azure NetApp Files を使用した Red Hat Enterprise Linux 上の SAP NetWeaver 用の Azure Virtual Machines の高可用性
• Suse または Red Hat Linux ベースの Azure VM の IBM Db2
• Oracle データと redo ログ ボリューム用に dNFS を使用した Oracle Linux ゲスト OS での SAP on Oracle のデプロイ。 詳細については、「SAP ワークロード用の Azure Virtual Machines Oracle DBMS のデプロイ」の記事を参照してください
• Suse または Red Hat Linux ゲスト OS の SAP on ASE
• Suse または Red Hat Linux ゲスト OS の AP on MAXDB
• SMB ボリュームを使用した Microsoft SQL Server 上の SAP

ボリューム サイズからのスループットの切り離し

データベース アプリケーション用のストレージには一般的にスループットの要件がありますが、この要件はボリュームのサイズに応じて線形でスケーリングされるわけではありません。たとえばログ ボリュームは、サイズは比較的小さくても高いレベルのスループットが必要です。

Azure NetApp Files では、容量プールの種類として手動 QoS を使用すると、ボリューム スループットをボリューム サイズとは独立して割り当てることができます。

次に例を示します。

• データベース ファイル用のボリュームには 500 MiB/秒のスループットと 39 TiB の容量が必要
• ログ ファイル用のボリュームには 2,000 MiB/秒のスループットと 1 TiB の容量が必要

手動 QoS 容量プールをこのシナリオ用に作成して、スループットをボリューム サイズとは独立して割り当てることができます。 必要な容量の合計は 40 TiB、スループット予算の合計は 2,500 MiB/秒です。 Premium サービス レベルの容量プール (割り当て済み TiB あたり 64 MiB/秒) で、パフォーマンスと容量の両方の要件に対応できます (40 MiB * 64 iB/秒/TiB = 2,560 MiB)。

パフォーマンスを線形スケーリングする場合は、スループットの要件を達成するために、ログ ボリュームのかなりのオーバープロビジョニングが必要になります。 ログ ボリュームのスループット 2,000 MiB/秒を達成するには、Ultra レベルの容量プール (割り当て済み TiB あたり 128 MiB/秒) を 16 TiB 分デプロイする必要があり、その結果としてオーバープロビジョニングになるため、15 TiB の容量が無駄になります。

実際のシナリオについて見積もりを行うには、Azure NetApp Files パフォーマンス計算ツールを使用してください。

Azure NetApp Files 上の SAP ワークロードの機能マトリックスは次のようになります。

Azure NetApp Files ストレージには、他にも次の機能が組み込まれています。

• AzAcSnap を使用してボリュームのアプリケーション整合性スナップショットを実行する機能
• テストと開発のために Azure NetApp Files ボリュームのクローンをスナップショットから作成する
• 破損やエラーからの迅速な復元のためにスナップショットからのボリュームの復元 (snap-revert)

この種の可用性ゾーンのアラインメントを行う動機は、アプリケーション VM と同じ可用性ゾーンに NFS 共有を配置することで、リスク サーフェスを減らすことです。

• SAP HANA のアプリケーション ボリューム グループを使用して、SAP HANA デプロイ用の Azure NetApp Files ボリュームをデプロイします。 アプリケーション ボリューム グループの利点は、データ ボリュームが複数のストレージ エンドポイントにデプロイされ、ネットワークの競合を減らし、パフォーマンスを向上させることです。

概要: Azure NetApp Files は、SAP HANA の認定済みの低待機時間ストレージ ソリューションです。 このサービスは、1 つ以上の容量プールから分割されたボリュームを提供します。 容量プールは、割り当てられる合計容量とスループットを定義する 3 つのサービス レベルで使用できます。 ボリュームのサイズを変更し、割り当てられたスループットをサービスの中断なしで調整して、要件の変化に対応し、コストを制御できます。 このサービスは、ディザスター リカバリーとビジネス継続性のために、ボリュームを他のリージョンまたはゾーンにレプリケートする機能を提供します。

Azure Premium Files

Azure Premium Files は、SMB と NFS を提供する共有ストレージであり、適度な価格と十分な待機時間で SAP アプリケーション レイヤーの共有を処理します。 さらに、Azure Premium Files では、1 つのレプリカが失敗した場合に別のゾーン内の別のレプリカが引き継ぐことができる自動作用を使用して、共有の同期ゾーン レプリケーションを提供します。 Azure NetApp Files とは反対に、パフォーマンス レベルはありません。 容量プールも必要ありません。 課金は、さまざまな共有の実際のプロビジョニングされた容量に基づいています。 Azure Premium Files は、SAP ワークロード用の DBMS ストレージとしてテストされていません。 ただし、その代わりに、SAP ワークロードの使用シナリオでは、すべての種類の SMB と NFS の共有に重点が置かれます。これらは、SAP アプリケーション レイヤーで使用されるためです。 Azure Premium Files は、/hana/shared の使用にも適しています。

Azure Premium Files リストでは次のような SAP シナリオがサポートされています。

• SAP のグローバル トランスポート ディレクトリに SMB または NFS 共有を提供する
• SAP システムと EDI プロセスへのインターフェイスのための共有としての使用
• 次のドキュメントに記載されているような高可用性シナリオでの共有 sapmnt:
  • Azure Files 上の NFS を使用した SUSE Linux Enterprise Server 上の Azure VM での SAP NetWeaver の高可用性
  • Azure Files 上の NFS を使用した Red Hat Enterprise Linux 上の Azure VM での SAP NetWeaver の高可用性
  • SAP アプリケーションのための Azure Files Premium SMB を使用した Windows 上の Azure VM での SAP NetWeaver の高可用性
  • SUSE Linux Enterprise Server での HSR を使用した SAP HANA スケールアウト システムの高可用性

Azure Premium Files は、Azure NetApp Files と比較して、最小共有サイズが 100 GB の IOPS の量が多い状態から始まります。 IOPS が高いことで、容量の過剰プロビジョニングが回避され、一定の IOPS とスループットの値が実現します。 IOPS とストレージのスループットについては、Azure Files のスケーラビリティとパフォーマンスのターゲットの Azure ファイル共有ターゲットに関するセクションを参照してください。

SAP ワークロードの機能マトリックスは次のようになります。

概要: Azure Premium Files は、NFS と SMB のボリュームまたは共有をデプロイできる、待機時間が少ないストレージです。 Azure Premium Files は、SAP アプリケーション レイヤー共有に対して優れた価格対パフォーマンス比を提供します。 また、これらの共有の同期ゾーン レプリケーションも提供します。 現時点では、SAP DBMS ワークロードでは、このストレージの種類はサポートされていません。 ただし、/hana/shared ボリュームに使用できます。

Azure Standard SSD ストレージ

Azure Standard SSD は、Azure Standard HDD ストレージに比べて可用性、一貫性、信頼性、待機時間が優れています。 低い IOPS レベルで一貫性のあるパフォーマンスを必要とするワークロード用に最適化されています。 このストレージは、必要な IOPS とスループットが小さい非運用 SAP システムで使われる最小ストレージです。 SAP ワークロードの機能マトリックスは次のようになります。

まとめ: 非運用 VM のベース VHD (最終的には、待ち時間を比較的問題にしない、かつ (または) IOPS とスループット レートが低い DBMS デプロイ) 用としては、Azure Standard SSD ストレージ以上をお勧めします。 この Azure Storage の種類は、SAP グローバル トランスポート ディレクトリをホストするためにはサポートされなくなりました。

Azure Standard HDD ストレージ

Azure Standard HDD ストレージは、2014 年に Azure インフラストラクチャが SAP NetWeaver ワークロード用として認定を受けたときの、唯一のストレージの種類でした。 2014 年には、Azure 仮想マシンは小規模でストレージのスループットが低いものでした。 そのため、このストレージの種類で要求に対応することができました。 このストレージは待機時間を問題にしないワークロードには理想的なものですが、それは SAP 空間ではまずありえません。 Azure VM のスループットが増加し、これらの VM で生成されるワークロードが増加したことで、このストレージの種類については、SAP シナリオでの使用は考慮されなくなりました。 SAP ワークロードの機能マトリックスは次のようになります。

概要: Standard HDD は、SAP バックアップを格納するためにのみ使用する必要がある Azure Storage の種類です。 あちこちのデータを検索するために使用される廃止されたシステムなど、かなり非アクティブなシステムのベース VHD としてのみ使用してください。 しかし、アクティブな開発、QA、運用 VM をそのストレージに基づかせることはできません。 また、そのストレージでデータベース ファイルをホストしないでください。

ストレージ トラフィックに関する Azure VM の制限

オンプレミスのシナリオとは対照的に、選択する個々の VM の種類は、実現できるストレージ帯域幅において重要な役割を果たします。 ストレージの種類に応じて、次の点を考慮する必要があります。

制限として、次のことにご注意ください。

• VM のサイズが小さいほど、アタッチできるディスクが少なくなります。 この制限は、Azure NetApp Files には適用されません。 NFS または SMB 共有をマウントするので、アタッチする共有ボリュームの数に制限はありません。
• VM には I/O スループットと IOPS の制限があり、Premium Storage ディスクと Ultra ディスクでは、それらを容易に超過する可能性があります。
• Azure NetApp Files と Azure Premium Files では、共有ボリュームへのトラフィックにはストレージ帯域幅ではなく VM のネットワーク帯域幅が使用されます。
• 2 桁の TiB 容量空間に大容量の NFS ボリュームがある場合、1 台の VM からこのようなボリュームにアクセスする場合のスループットは、単一セッションでの共有ボリュームとの対話に関する Linux の制限に基づいて頭打ちになります。

SAP システムのライフサイクルにおいて Azure VM のサイズを大きくするときは、より容量の大きい新しい VM の種類の IOPS とストレージ スループットの制限を評価する必要があります。 場合によっては、ストレージ構成を Azure VM の新機能に合わせて調整することも意味があります。

ストライピングするかどうか

複数の Azure ディスクから 1 つの大きなボリュームにストライプ セットを作成すると、個々のディスクの IOPS とスループットを 1 つのボリュームに累積できます。 Azure Standard Storage と Azure Premium Storage にのみ使用されます。 ディスク容量に関係なくスループットと IOPS を構成できる Azure Ultra Disk では、ストライプ セットを使用する必要はありません。 NFS または SMB に基づく共有ボリュームをストライピングすることはできません。 Azure Premium Storage のスループットと IOPS には非線形という特徴があるため、大規模な単一の Azure Premium Storage ディスクと同じ IOPS とスループットを持つ、より小さな容量をプロビジョニングすることができます。 これは、Azure Premium Storage を使用して、より高いスループットまたは IOPS をより低コストで実現するための方法です。 たとえば、2 台の P15 Premium Storage ディスクをストライピングして実現できるスループットは、

• 250 MiB/秒です。このようなボリュームは、512 GiB の容量になります。 1 秒あたり 250 MiB のスループットを提供する単一のディスクを希望する場合は、2 TiB の容量を持つ P40 ディスクを選択する必要があります。
• ストライピングにより総容量 512 GiB となる 4 台の P10 Premium Storage ディスクをストライピングする方法では、400 MiB/秒です。 少なくとも 1 秒あたり 500 MiB のスループットを持つ単一のディスクを希望する場合は、8 TiB の P60 Premium Storage ディスクを選択する必要があります。 Premium Storage のコストは容量に対してほぼ線形であるため、ストライピングを使用することでコスト削減を実感できます。

ストライピングでは、いくつかのルールに従う必要があります。

• Azure Storage は、Azure Storage バックエンドにデータ ディスク冗長を既に保持しているため、VM 内で構成されたストレージ冗長性を使用しないでください
• ストライプ セットが適用されるディスクは、同じサイズである必要があります。
• Premium SSD v2 と Ultra Disk では、容量、プロビジョニングされた IOPS、プロビジョニングされたスループットが同じである必要があります

Azure Premium Storage を使用して優れた価格/パフォーマンス比を実現するには、複数の小さなディスクにまたがるストライピングが最適な方法です。 ストライピングによって、追加のデプロイと管理のオーバーヘッドが発生する可能性があります。

特定のストライプ サイズに関する推奨事項については、「SAP HANA Azure 仮想マシンのストレージ構成」など、さまざまな DBMS のドキュメントを参照してください。

次のステップ

以下の記事を参照してください。

• SAP ワークロードのための Azure Virtual Machines DBMS デプロイの考慮事項
• SAP HANA Azure 仮想マシンのストレージ構成