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 のレプリケーションに関する記事で説明されています。
Note
データベース データと再実行ログ ファイルを保存するために Azure Storage を使用する場合、LRS はこの時点でサポートされている唯一の回復性レベルです
「仮想マシンの SLA」でリリースされたシングル VM 可用性 SLA にさまざまな種類の Azure ストレージが影響を与えることにもご留意ください。
Azure Managed Disks
マネージド ディスクは Azure Resource Manager のリソースの種類で、Azure ストレージ アカウントに格納されている VHD の代わりに使用できます。 マネージド ディスクは、アタッチ先の仮想マシンの [可用性セット][virtual-machines-manage-availability] に自動的に配置されます。 このような配置により、仮想マシンの可用性と仮想マシンで実行されているサービスが向上します。 詳細については、概要についての記事を参照してください。
注意
ディスク用に Azure ブロック ストレージ (Azure NetApp Files と Azure Files を除くすべての Azure ストレージ) を使用する VM の新しい展開では、ベース VHD または OS ディスク用、SAP データベース ファイルを保存するデータ ディスク用に、Azure マネージド ディスクを使用する必要があります。 VM を可用性セット内にデプロイするか、可用性ゾーン間にデプロイするか、セットやゾーンを使用せずにデプロイするかは関係ありません。 バックアップを格納する目的に使用するディスクは、必ずしもマネージド ディスクである必要はありません。
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 ストレージ シナリオのストレージに関する推奨事項をまとめて表にすると、次のようになります。
| 使用シナリオ | Standard HDD | Standard SSD | Premium Storage | Premium SSD v2 | Ultra Disk | Azure NetApp Files | Azure Premium Files |
|---|---|---|---|---|---|---|---|
| OS ディスク | 不適合 | 制限付き適合 (非運用) | 推奨 | 不可能 | 不可能 | 不可能 | 不可能 |
| グローバル トランスポート ディレクトリ | サポートされていません | サポートされていません | 推奨 | 推奨 | 推奨 | 推奨 | 強く推奨 |
| /sapmnt | 不適合 | 制限付き適合 (非運用) | 推奨 | 推奨 | 推奨 | 推奨 | 強く推奨 |
| DBMS データ ボリューム (SAP HANA) M または Mv2 VM ファミリ | サポートされていません | サポートされていません | 推奨 | 推奨 | 推奨 | 推奨2 | サポートされていません |
| DBMS ログ ボリューム (SAP HANA) M または Mv2 VM ファミリ | サポートされていません | サポートされていません | 推奨1 | 推奨 | 推奨 | 推奨2 | サポートされていません |
| DBMS データ ボリューム (SAP HANA) Esv3 または Edsv4 VM ファミリ | サポートされていません | サポートされていません | 推奨 | 推奨 | 推奨 | 推奨2 | サポートされていません |
| DBMS ログ ボリューム (SAP HANA) Esv3 または Edsv4 VM ファミリ | サポートされていません | サポートされていません | サポートされていません | 推奨 | 推奨 | 推奨2 | サポートされていません |
| HANA 共有ボリューム | サポートされていません | サポートされていません | 推奨 | 推奨 | 推奨 | 推奨 | 推奨3 |
| DBMS データ ボリューム (HANA 以外) | サポートされていません | 制限付き適合 (非運用) | 推奨 | 推奨 | 推奨 | SLES/RHEL Linux 上の Oracle Linux、Db2、および SAP ASE 上の特定の Oracle リリースのみ | サポートされていません |
| DBMS ログ ボリューム (HANA 以外) M または Mv2 VM ファミリ | サポートされていません | 制限付き適合 (非運用) | 推奨1 | 推奨 | 推奨 | SLES/RHEL Linux 上の Oracle Linux、Db2、および SAP ASE 上の特定の Oracle リリースのみ | サポートされていません |
| DBMS ログ ボリューム (HANA 以外) M または Mv2 以外の VM ファミリ | サポートされていません | 制限付き適合 (非運用) | 中規模までのワークロードに適合 | 推奨 | 推奨 | SLES/RHEL Linux 上の Oracle Linux、Db2、および SAP ASE 上の特定の Oracle リリースのみ | サポートされていません |
1 ログまたは再実行ログ ボリューム用の M または Mv2 VM ファミリでは Azure 書き込みアクセラレータを使用します。
2 ANF を使用するには、/hana/data と /hana/log が ANF 上に存在する必要があります
3 これまでに SLES でのみテスト済み
さまざまな種類のストレージに期待できる特性は、次のようになります。
| 使用シナリオ | Standard HDD | Standard SSD | Premium Storage | Premium SSD v2 | Ultra Disk | Azure NetApp Files | Azure Premium Files |
|---|---|---|---|---|---|---|---|
| スループットまたは IOPS SLA | いいえ | 番号 | イエス | イエス | イエス | イエス | はい |
| 読み取り待機時間 | 高 | 中から高 | 低 | ミリ秒未満 | ミリ秒未満 | ミリ秒未満 | low |
| 書き込み待機時間 | 高 | 中から高 | 低 (ミリ秒未満1) | ミリ秒未満 | ミリ秒未満 | ミリ秒未満 | low |
| HANA のサポート対象 | いいえ | いいえ | はい1 | はい | イエス | 有効 | いいえ |
| ディスクのスナップショット可能 | はい | イエス | 有効 | 番号 | 番号 | イエス | いいえ |
| 可用性セット使用時の異なるストレージ クラスターへのディスクの割り当て | マネージド ディスクを使用 | マネージド ディスクを使用 | マネージド ディスクを使用 | 可用性セットを使用してデプロイした VM ではサポートされていないディスクの種類 | 可用性セットを使用してデプロイした VM ではサポートされていないディスクの種類 | いいえ3 | いいえ |
| Availability Zones を使用した配置 | はい | イエス | イエス | イエス | はい | "パブリック プレビュー段階" | いいえ |
| 同期ゾーン冗長 | マネージド ディスク非対応 | マネージド ディスク非対応 | DBMS ではサポートされていません | いいえ | 番号 | 番号 | はい |
| 非同期ゾーン冗長 | マネージド ディスク非対応 | マネージド ディスク非対応 | DBMS ではサポートされていません | いいえ | いいえ | レビュー中 | いいえ |
| geo 冗長 | マネージド ディスク非対応 | マネージド ディスク非対応 | いいえ | 番号 | いいえ | 可能 | いいえ |
1 ログまたは再実行ログ ボリューム用の M または Mv2 VM ファミリでは Azure 書き込みアクセラレータを使用します。
2 コストはプロビジョニングされた IOPS とスループットに依存します。
3 異なる ANF 容量プールを作成しても、異なるストレージ ユニットに容量プールがデプロイされる保証はありません
重要
1 ミリ秒未満の待機時間が必要な場合の NFS ボリュームと VM の近接配置に関する詳細については、このドキュメントの Azure NetApp Files のセクションを参照してください。
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 から 1024 GiB までの範囲にあるディスクでは、同じ機能と同じ月額コストが共有されます。
- GiB あたりの IOPS は、サイズ カテゴリ間で線形になりません。 32 GiB より小さいディスクの場合、GiB あたりの IOPS レートが高くなります。 32 GiB を超えて 1024 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 ワークロードの機能マトリックスは次のようになります。
| 機能 | 解説 | 注またはリンク |
|---|---|---|
| OS ベース VHD | 適合 | すべてのシステム |
| データ ディスク | 適合 | すべてのシステム - 特に SAP HANA |
| SAP グローバル トランスポート ディレクトリ | はい | サポートされています |
| SAP sapmnt | 適合 | すべてのシステム |
| バックアップ ストレージ | 適合 | 短期的なバックアップの保存 |
| ファイル共有または共有ディスク | 使用できません。 | Azure Premium Files またはサード パーティが必要 |
| 回復性 | LRS | ディスクに GRS または ZRS は利用不可 |
| Latency | 低から中 | - |
| IOPS SLA | はい | - |
| IOPS は容量に対して線形 | ブラケット内で半直線 | Managed Disks の価格 |
| ディスクあたりの最大 IOPS | 20,000 (ディスク サイズによって異なる) | VM の制限も考慮すること |
| スループット SLA | はい | - |
| スループット (容量に対して線形) | ブラケット内で半直線 | Managed Disks の価格 |
| HANA 認定 | はい | 特に SAP HANA |
| Azure 書き込みアクセラレータのサポート | いいえ | - |
| ディスク バースト | はい | - |
| ディスクのスナップショット可能 | はい | - |
| Azure Backup VM スナップショット可能 | はい | - |
| コスト | Medium | - |
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 ワークロードの機能マトリックスは次のようになります。
| 機能 | 解説 | 注またはリンク |
|---|---|---|
| OS ベース VHD | サポートされていません | システムなし |
| データ ディスク | 適合 | すべてのシステム |
| SAP グローバル トランスポート ディレクトリ | はい | すべてのシステム |
| SAP sapmnt | 適合 | すべてのシステム |
| バックアップ ストレージ | 適合 | 短期的なバックアップの保存 |
| ファイル共有または共有ディスク | 使用できません。 | Azure Premium Files または Azure NetApp Files が必要です |
| 回復性 | LRS | ディスクに GRS または ZRS は利用不可 |
| Latency | ミリ秒未満 | - |
| IOPS SLA | はい | - |
| IOPS は容量に対して線形 | 半線形 | Managed Disks の価格 |
| ディスクあたりの最大 IOPS | 80,000 (ディスク サイズによって異なる) | VM の制限も考慮すること |
| スループット SLA | はい | - |
| スループット (容量に対して線形) | 半線形 | Managed Disks の価格 |
| HANA 認定 | はい | - |
| Azure 書き込みアクセラレータのサポート | いいえ | - |
| ディスク バースト | いいえ | - |
| ディスクのスナップショット可能 | いいえ | - |
| Azure Backup VM スナップショット可能 | いいえ | - |
| コスト | Medium | - |
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 ワークロードの機能マトリックスは次のようになります。
| 機能 | 解説 | 注またはリンク |
|---|---|---|
| OS ベース VHD | 機能しません | - |
| データ ディスク | 適合 | すべてのシステム |
| SAP グローバル トランスポート ディレクトリ | はい | サポートされています |
| SAP sapmnt | 適合 | すべてのシステム |
| バックアップ ストレージ | 適合 | 短期的なバックアップの保存 |
| ファイル共有または共有ディスク | 使用できません。 | サード パーティが必要 |
| 回復性 | LRS | ディスクに GRS または ZRS は利用不可 |
| Latency | 非常に低い | - |
| IOPS SLA | はい | - |
| IOPS は容量に対して線形 | ブラケット内で半直線 | Managed Disks の価格 |
| ディスクあたりの最大 IOPS | 1,200 - 160,000 | ディスク容量に依存 |
| スループット SLA | はい | - |
| スループット (容量に対して線形) | ブラケット内で半直線 | Managed Disks の価格 |
| HANA 認定 | はい | - |
| Azure 書き込みアクセラレータのサポート | いいえ | - |
| ディスク バースト | いいえ | - |
| ディスクのスナップショット可能 | いいえ | - |
| Azure Backup VM スナップショット可能 | いいえ | - |
| コスト | Premium Storage より高い | - |
概要: Azure Ultra Disk はミリ秒未満の待機時間が少なく、すべての種類の SAP ワークロードに適切なストレージです。 これまでは、Availability Zones (ゾーン デプロイ) を使用してデプロイした VM との組み合わせでのみ、Ultra Disk を使用できました。 Ultra Disk はストレージ スナップショットをサポートしていません。 Ultra Disk は他のすべてのストレージとは逆で、ベース VHD ディスクには使用できません。 I/O ワークロードの変動が大きく、デプロイされたストレージのスループットまたは IOPS を、帯域幅と IOPS を最大使用量に合わせてサイズ変更するのではなく、ストレージのワークロード パターンに合わせて調整する場合、Ultra Disk が最適です。
Azure NetApp Files (ANF)
Azure NetApp Files は、パフォーマンスに優れた Azure ネイティブの NFS および SMB 共有を実現することを目的とした、Microsoft と NetApp の連携による成果です。 DBMS のデプロイ シナリオを実現する待機時間が少なく高帯域幅のストレージを提供すること、やがては Azure を通じて NetApp ストレージの一般的な運用機能も実現することに重点が置かれています。 NFS または SMB 共有は、ストレージのスループットと価格が区別された 3 つの異なるサービス レベルで提供されます。 それらのサービス レベルについては、「Azure NetApp Files のサービス レベル」の記事を参照してください。 SAP ワークロードの種類に応じて、次のサービス レベルを強くお勧めします。
- SAP DBMS ワークロード: パフォーマンス、理想的には Ultra
- SAPMNT 共有: パフォーマンス、理想的には Ultra
- グローバル トランスポート ディレクトリ: パフォーマンス、理想的には Ultra
注意
最小プロビジョニング サイズは、容量プールと呼ばれる 4 TiB のユニットです。 その後、この容量プールからボリュームを作成します。 一方、構築できる最小のボリュームは 100 GiB です。 TiB 単位で段階的に容量プールを拡張できます。 価格については、「Azure NetApp Files の価格」の記事をご確認ください。
現在、ANF ストレージは、いくつかの SAP ワークロード シナリオでサポートされています。
- 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 の高可用性
- /hana/data および /hana/log ボリューム用に NFS v4.1 共有を使用し、かつ (または) /hana/shared ボリューム用に NFS v4.1 か NFS v3 ボリュームを使用した SAP HANA デプロイ (「SAP HANA Azure 仮想マシンのストレージ構成」を参照)
- Suse または Red Hat Linux ゲスト OS の IBM Db2
- Oracle データと redo ログ ボリューム用に dNFS を使用した Oracle Linux ゲスト OS での Oracle のデプロイ。 詳細については、「SAP ワークロード用の Azure Virtual Machines Oracle DBMS のデプロイ」の記事を参照してください
- Suse または Red Hat Linux ゲスト OS の SAP ASE
注意
これまでのところ、DBMS ワークロードに、Azure NetApp Files に基づく SMB でサポートされているものはありません。
Azure Premium Storage の場合と同様に、スループットにおいてなんらかの最小値に従う必要がある場合は、GB あたりの固定または線形スループット サイズが問題になることがあります。 SAP HANA はこのようなケースに該当します。 ANF では、この問題が Azure Premium ディスクよりも顕著になる可能性があります。 Azure Premium ディスクを使用すると、GiB あたりのスループットが相対的に高い複数の小さいディスクを使用し、それら全体をストライピングすることでコスト効率を高め、比較的少ない容量でより高いスループットを実現できます。 この種類のストライピングは、ANF でホストされている NFS または SMB 共有では機能しません。 この制限により、結果的に次のような過剰な容量がデプロイされることがありました。
- たとえば、ANF でホストされている NFS ボリュームで 250 MiB/秒のスループットを実現するには、Ultra サービス レベルの容量 1.95 TiB をデプロイする必要があります。
- 400 MiB/秒を実現するには、容量 3.125 TiB をデプロイする必要があります。 しかし、ボリュームに必要なスループットを実現するために、容量の過剰プロビジョニングが必要になる場合があります。 この容量の過剰プロビジョニングは、より小規模な HANA インスタンスの価格に影響します。
- SAP の /sapmnt ディレクトリ用の ANF 上で NFS を使用すると、Azure NetApp Files によって適用される 100 GiB から 150 GiB までという最小容量で通常は十分です。 ただし、12.8 MiB/秒 (Ultra サービス レベルを使用) の関連スループットが十分ではなく、SAP システムの安定性に悪影響を及ぼす可能性があることが、カスタマー エクスペリエンスによって判明しました。 このような場合、お客様は /sapmnt ボリュームの容量を増やすことで問題を回避できます。それにより、そのボリュームにより多くのスループットが提供されます。
SAP ワークロードの機能マトリックスは次のようになります。
| 機能 | 解説 | 注またはリンク |
|---|---|---|
| OS ベース VHD | 機能しません | - |
| データ ディスク | 適合 | SAP HANA、Oracle on Oracle Linux、Db2、および SAP ASE on SLES/RHEL |
| SAP グローバル トランスポート ディレクトリ | はい | SMB および NFS |
| SAP sapmnt | 適合 | すべてのシステムの SMB (Windows のみ) または NFS (Linux のみ) |
| バックアップ ストレージ | 適合 | - |
| ファイル共有または共有ディスク | はい | SMB 3.0、NFS v3、および NFS v4.1 |
| 回復性 | LRS と GRS | GRS を使用可能 |
| Latency | 非常に低い | - |
| IOPS SLA | はい | - |
| IOPS は容量に対して線形 | 厳密に線形 | サービス レベルに依存 |
| スループット SLA | はい | - |
| スループット (容量に対して線形) | linear | サービス レベルに依存 |
| HANA 認定 | はい | - |
| ディスクのスナップショット可能 | はい | - |
| Azure Backup VM スナップショット可能 | いいえ | - |
| コスト | Premium Storage より高い | - |
ANF ストレージのその他の組み込み機能:
- ボリュームのスナップショットを実行する機能
- スナップショットからの ANF ボリュームの複製
- スナップショットからのボリュームの復元 (snap-revert)
- SAP HANA と Oracle のアプリケーション整合性スナップショット バックアップ
重要
特に、データベース デプロイの場合は、少なくとも再実行ログの待機時間を短くする必要があります。 特に SAP HANA の場合、小さいサイズの HANA 再実行ログ書き込みでは、SAP の待機時間が 1 ミリ秒未満である必要があります。 このような待機時間を実現するには、以下の方法を参照してください。
重要
DBMS 以外の使用の場合でも、NFS 共有をマウントする VM を配置したのと同じ Azure Availability Zones に NFS 共有を作成できるプレビュー機能を使用する必要があります。 この機能については、「Azure NetApp Files の可用性ゾーン ボリュームの配置を管理する」の記事を参照してください。 この種の可用性ゾーンのアラインメントを行う動機は、VM を実行していない別の AvZone に NFS 共有をまだ配置することで、リスクサーフェスを減らすことです。
- アプリケーション ボリューム グループを使用することで、VM と NFS 共有の最も近接した配置を実現できます。 アプリケーション ボリューム グループの利点は、最適な近接性を割り当て、それにより最短待機時間を実現できることに加えて、SAP HANA デプロイ用の異なる NFS 共有が、Azure NetApp Files バックエンド クラスター内の異なるコントローラーに分散されることです。 この方法の欠点は、固定プロセスを再度行う必要があることです。 このプロセスにより、VM の配置が単一のデータセンターに制限されることになります。 最初に紹介した可用性ゾーンに代わる方法です。 これは、NFS ボリュームがマウントされている VM の VM サイズと VM ファミリを変更する柔軟性が低くなることを意味します。
- 可用性配置グループを使用しない現在のプロセス。 これまでのところ、SAP HANA でのみ利用可能です。 このプロセスでも、可用性ボリューム グループの場合と同じように、手動での固定プロセスがとられます。 この方法は、過去 3 年間用いられてきた方法です。 可用性ボリューム グループのプロセスと同じ柔軟性の制限があります。
データベース固有の用途に応じて ANF に基づいて NFS ボリュームを割り当てるための基本設定として、まず VM と同じゾーンに NFS ボリュームを割り当てるようにしてください。 特に HANA 以外のデータベースの場合。 待機時間が不十分であることが判明した場合にのみ、手動での固定プロセスを実行する必要があります。 小規模な HANA ワークロードまたは非運用 HANA ワークロードの場合は、ゾーン割り当て方式にも従う必要があります。 パフォーマンスと待機時間が十分でない場合にのみ、アプリケーション ボリューム グループを使用する必要があります。
概要:Azure NetApp Files は、NFS と SMB のボリュームまたは共有をデプロイできる、HANA 認定の待機時間が少ないストレージです。 このストレージには、ボリュームの GiB 容量ごとに異なる線形のスループットと IOPS を提供する、3 つの異なるサービス レベルが用意されています。 ANF ストレージによって、スタンバイ ノードを使用して SAP HANA スケールアウト シナリオをデプロイできるようになります。 このストレージは、/sapmnt または SAP グローバル トランスポート ディレクトリ用に、必要に応じてファイル共有を提供するのに適しています。 ANF ストレージには、ネイティブの NetApp 機能として使用できる機能があります。
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 の使用にも適しています。
Note
現時点では、Azure Premium Files に基づく共有ボリュームでサポートされている SAP DBMS ワークロードはありません。
Azure Premium Files リストでは次のような SAP シナリオがサポートされています。
- SAP のグローバル トランスポート ディレクトリに SMB または NFS 共有を提供する
- 次のドキュメントに記載されているような高可用性シナリオでの共有 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 ワークロードの機能マトリックスは次のようになります。
| 機能 | 解説 | 注またはリンク |
|---|---|---|
| OS ベース VHD | 機能しません | - |
| データ ディスク | SAP ワークロードではサポートされていません | - |
| SAP グローバル トランスポート ディレクトリ | はい | SMB および NFS |
| SAP sapmnt | 適合 | すべてのシステムの SMB (Windows のみ) または NFS (Linux のみ) |
| バックアップ ストレージ | 適合 | - |
| ファイル共有または共有ディスク | はい | SMB 3.0、NFS v4.1 |
| 回復性 | LRS と ZRS | Azure Premium Files で使用できる GRS はありません |
| Latency | low | - |
| IOPS SLA | はい | - |
| IOPS は容量に対して線形 | 厳密に線形 | - |
| スループット SLA | はい | - |
| スループット (容量に対して線形) | 厳密に線形 | - |
| HANA 認定 | いいえ | - |
| ディスクのスナップショット可能 | いいえ | - |
| Azure Backup VM スナップショット可能 | いいえ | - |
| コスト | low | - |
概要: 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 ワークロードの機能マトリックスは次のようになります。
| 機能 | 解説 | 注またはリンク |
|---|---|---|
| OS ベース VHD | 制限付き適合 | 非運用システム |
| データ ディスク | 制限付き適合 | IOPS と待機時間の要件が低い一部の非運用システム |
| SAP グローバル トランスポート ディレクトリ | いいえ | サポートされていません |
| SAP sapmnt | 制限付き適合 | 非運用システム |
| バックアップ ストレージ | 適合 | - |
| ファイル共有または共有ディスク | 使用できません。 | サード パーティが必要 |
| 回復性 | LRS、GRS | ディスクに ZRS は利用不可 |
| Latency | high | SAP グローバル トランスポート ディレクトリまたは運用システムには高すぎる |
| IOPS SLA | いいえ | - |
| ディスクあたりの最大 IOPS | 500 | ディスクのサイズに依存しない |
| スループット SLA | いいえ | - |
| HANA 認定 | いいえ | - |
| ディスクのスナップショット可能 | はい | - |
| Azure Backup VM スナップショット可能 | はい | - |
| コスト | LOW | - |
概要: Azure Standard SSD ストレージは、非運用 VM のベース VHD (最終的には、待機時間を比較的問題にしない、かつ (または) IOPS とスループット レートが低い DBMS デプロイ) 用として最小の推奨事項です。 この Azure Storage の種類は、SAP グローバル トランスポート ディレクトリをホストするためにはサポートされなくなりました。
Azure Standard HDD ストレージ
Azure Standard HDD ストレージは、2014 年に Azure インフラストラクチャが SAP NetWeaver ワークロード用として認定を受けたときの、唯一のストレージの種類でした。 2014 年には、Azure 仮想マシンは小規模でストレージのスループットが低いものでした。 そのため、このストレージの種類で要求に対応することができました。 このストレージは待機時間を問題にしないワークロードには理想的なものですが、それは SAP 空間ではまずありえません。 Azure VM のスループットが増加し、これらの VM で生成されるワークロードが増加したことで、このストレージの種類については、SAP シナリオでの使用は考慮されなくなりました。 SAP ワークロードの機能マトリックスは次のようになります。
| 機能 | 解説 | 注またはリンク |
|---|---|---|
| OS ベース VHD | 不適合 | - |
| データ ディスク | 不適合 | - |
| SAP グローバル トランスポート ディレクトリ | いいえ | サポートされていません |
| SAP sapmnt | NO | サポートされていません |
| バックアップ ストレージ | 適合 | - |
| ファイル共有または共有ディスク | 使用できません。 | Azure Files またはサード パーティが必要 |
| 回復性 | LRS、GRS | ディスクに ZRS は利用不可 |
| Latency | high | DBMS での使用、SAP グローバル トランスポート ディレクトリ、sapmnt または saploc 用には高すぎる |
| IOPS SLA | いいえ | - |
| ディスクあたりの最大 IOPS | 500 | ディスクのサイズに依存しない |
| スループット SLA | いいえ | - |
| HANA 認定 | いいえ | - |
| ディスクのスナップショット可能 | はい | - |
| Azure Backup VM スナップショット可能 | はい | - |
| コスト | 低 | - |
概要: Standard HDD は、SAP バックアップを格納するためにのみ使用する必要がある Azure Storage の種類です。 あちこちのデータを検索するために使用される廃止されたシステムなど、かなり非アクティブなシステムのベース VHD としてのみ使用してください。 しかし、アクティブな開発、QA、運用 VM をそのストレージに基づかせることはできません。 また、そのストレージでデータベース ファイルをホストしないでください。
ストレージ トラフィックに関する Azure VM の制限
オンプレミスのシナリオとは対照的に、選択する個々の VM の種類は、実現できるストレージ帯域幅において重要な役割を果たします。 ストレージの種類に応じて、次の点を考慮する必要があります。
| ストレージの種類 | Linux | Windows | 説明 |
|---|---|---|---|
| Standard HDD | Azure の Linux 仮想マシンのサイズ | Azure の Windows 仮想マシンのサイズ | 中規模または大規模な VM のストレージの制限に触れにくい |
| Standard SSD | Azure の Linux 仮想マシンのサイズ | Azure の Windows 仮想マシンのサイズ | 中規模または大規模な VM のストレージの制限に触れにくい |
| Premium Storage | Azure の Linux 仮想マシンのサイズ | Azure の Windows 仮想マシンのサイズ | ストレージ構成により IOPS またはストレージ スループットについての VM の制限に達しやすい |
| Premium SSD v2 | Azure の Linux 仮想マシンのサイズ | Azure の Windows 仮想マシンのサイズ | ストレージ構成により IOPS またはストレージ スループットについての VM の制限に達しやすい |
| Ultra Disk Storage | Azure の Linux 仮想マシンのサイズ | Azure の Windows 仮想マシンのサイズ | ストレージ構成により IOPS またはストレージ スループットについての VM の制限に達しやすい |
| Azure NetApp Files | Azure の Linux 仮想マシンのサイズ | Azure の Windows 仮想マシンのサイズ | ストレージ トラフィックによって、ストレージの帯域幅ではなくネットワーク スループットの帯域幅が使用される |
| Azure Premium Files | Azure の Linux 仮想マシンのサイズ | Azure の Windows 仮想マシンのサイズ | ストレージ トラフィックによって、ストレージの帯域幅ではなくネットワーク スループットの帯域幅が使用される |
制限として、次のことにご注意ください。
- VM のサイズが小さいほど、アタッチできるディスクが少なくなります。 この制限は、ANF には適用されません。 NFS または SMB 共有をマウントするので、アタッチする共有ボリュームの数に制限はありません。
- VM には I/O スループットと IOPS の制限があり、Premium Storage ディスクと Ultra ディスクでは、それらを容易に超過する可能性があります。
- ANF と 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 によってデータの冗長性は既に維持されているため、VM 内に構成されたストレージは使用しないでください
- ストライプ セットが適用されるディスクは、同じサイズである必要があります。
- Premium SSD v2 と Ultra Disk では、容量、プロビジョニングされた IOPS、プロビジョニングされたスループットが同じである必要があります
Azure Premium Storage を使用して優れた価格/パフォーマンス比を実現するには、複数の小さなディスクにまたがるストライピングが最適な方法です。 ストライピングによって、追加のデプロイと管理のオーバーヘッドが発生する可能性があります。
特定のストライプ サイズに関する推奨事項については、「SAP HANA Azure 仮想マシンのストレージ構成」など、さまざまな DBMS のドキュメントを参照してください。
次のステップ
以下の記事を参照してください。