SAP HANA Azure 仮想マシンのストレージ構成
Azure は、SAP HANA を実行する Azure VM に適した、異なる種類のストレージを提供します。 SAP HANA のデプロイのために検討できる SAP HANA 認定の Azure ストレージの種類は次のとおりです。
- Azure Premium SSD または Premium Storage v1/v2
- Ultra Disk
- Azure NetApp Files
これらのディスクの種類の詳細については、「SAP ワークロードの Azure Storage の種類」とディスクの種類の選択に関する記事をご覧ください。
Azure では、Azure Standard および Premium Storage v1/v2 での VHD の 2 つのデプロイ方法を提供しています。 Azure ブロック ストレージのデプロイには、Azure マネージド ディスクのご利用をお勧めします。
ストレージの種類と、IOPS およびストレージ スループットの SLA の一覧については、マネージド ディスクに関する Azure ドキュメントをご覧ください。
重要
選択した Azure ストレージの種類に関係なく、そのストレージで使用されるファイル システムは、特定のオペレーティング システムと DBMS 向けに SAP でサポートされている必要があります。 SAP サポート ノート #2972496 には、SAP HANA を含むさまざまなオペレーティング システムとデータベースでサポートされるファイル システムの一覧が示されています。 これは、任意のタスクの読み取りと書き込みのために SAP HANA がアクセスする可能性があるすべてのボリュームに適用されます。 特に Azure for SAP HANA で NFS を使用する場合は、この記事で後述するように、NFS バージョンに関する追加の制限が適用されます
各種ストレージにおける SAP HANA 認定の最低条件は次のとおりです。
- Azure Premium Storage v1 - /hana/log は、Azure 書き込みアクセラレータでサポートされている必要があります。 /hana/data ボリュームは、Azure 書き込みアクセラレータを使用しない Premium Storage v1 または Ultra Disk に配置できます。 Azure Premium Storage v2 または Azure Premium SSD v2 は、Azure 書き込みアクセラレータの使用をサポートしていません
- /hana/log ボリュームには、少なくとも Azure Ultra Disk が必要です。 /hana/data ボリュームは、Azure 書き込みアクセラレータを使用しない Premium Storage v1/v2 または再起動時間を短縮するために Ultra Disk に配置できます
- /hana/log および /hana/data には、Azure NetApp Files 上の NFS v4.1 ボリュームを使用します。 /hana/shared のボリュームでは、NFS v3 または NFS v4.1 プロトコルを使用できます。
顧客から得た経験に基づいて、 /hana/data と /hana/log の間で異なるストレージの種類を組み合わせるためサポートを変更しました。 Azure NetApp Files に基づく HANA および NFS 共有用に認定されているさまざまな Azure ブロック ストレージの使用の組み合わせがサポートされています。 たとえば、必要な待ち時間の短縮を実現するため、/hana/data を Premium Storage v1 または v2 に配置し、/hana/log を Ultra Disk ストレージに配置できます。 /hana/data に ANF に基づくボリュームを使用する場合、 /hana/log ボリュームを、HANA 認定 Azure ブロック ストレージの種類のいずれかに配置することもできます。 一方のボリューム (/hana/data など) に ANF 上の NFS を使用して、もう一方のボリューム (/hana/log など) には Azure Premium Storage v1/v2 または Ultra Disk を使用することがサポートされています。
オンプレミスでは、I/O サブシステムとその機能を気にする必要はほとんどありませんでした。 SAP HANA に対する最低限のストレージ要件が満たされていることを、アプライアンスのベンダーが保証する必要があったためです。 Azure インフラストラクチャを自身でビルドする場合は、これらの SAP が発行した要件の一部に注意する必要があります。 SAP が推奨している最小スループット特性の一部を次に示します。
- I/O サイズが 1 MB の /hana/log での、250 MB/秒の読み取り/書き込み
- I/O サイズが 16 MB および 64 MB の /hana/data での、少なくとも 400 MB/秒の読み取りアクティビティ
- I/O サイズが 16 MB および 64 MB の /hana/data での、少なくとも 250 MB/秒の書き込みアクティビティ
DBMS システムではストレージの待ち時間が短いことが重要であるため、SAP HANA のようなシステムでもデータをメモリ内に保持します。 通常、ストレージのクリティカル パスは、DBMS システムのトランザクション ログの書き込みの周辺にあります。 しかし、クラッシュ復旧後のセーブポイントの書き込みやメモリ内のデータの読み込みなどの操作も重要である場合があります。 そのため、/hana/data および /hana/log ボリュームでは、Azure Premium Storage v1/v2、Ultra Disk、または ANF の使用が必須となります。
HANA のストレージ構成を選択する際の基本原則は次のとおりです。
- 「SAP ワークロードの Azure Storage の種類」およびディスクの種類の選択に関する記事に基づいて、ストレージの種類を決定します。
- VM のサイズ設定や決定を行うときは、VM の全体的な I/O スループットと IOPS の上限を考慮します。 VM の全体的なストレージ スループットについては、「メモリ最適化済み仮想マシンのサイズ」をご覧ください。
- ストレージ構成を決定するときは、 /hana/data ボリューム構成で VM の全体的なスループットの上限を超えないようにします。 SAP HANA のセーブポイントの書き込みにより、HANA から高い頻度で I/O を発行できます。 セーブポイントを書き込むと、/hana/data ボリュームのスループットの上限にすぐに達する可能性があります。 /hana/data ボリュームが構築されているディスクのスループットが、VM で許可されるスループットよりも高い場合、セーブポイントの書き込みで使用されるスループットが、再実行ログ書き込みのスループット要求の妨げとなる状況に陥る可能性があります。 アプリケーションのスループットに影響を与える可能性のある状況
- HANA システム レプリケーションの使用を検討している場合、各レプリカの /hana/data に使用されるストレージは同じである必要があり、各レプリカの /hana/log に使用されるストレージの種類は同じである必要があります。 たとえば、1 つの VM で /hana/data に Azure Premium Storage v1 を使用し、同じ HANA システム レプリケーション構成のレプリカを実行している別の VM で /hana/data に Azure Ultra Disk を使用することはサポートされていません
重要
このドキュメントまたは今後のストレージ構成に関する提案は、最初の方向性を示すことを目的としています。 ワークロードを実行し、ストレージの使用パターンを分析すると、提供されているストレージ帯域幅または IOPS をすべて使用しているわけではないことに気付く場合があります。 その場合は、ストレージのダウンサイジングを検討してください。 逆に、これらの構成で推奨されているストレージ スループットよりも多くのスループットがワークロードに必要な場合もあります。 その結果、より多くの容量、IOPS、またはスループットをデプロイすることが必要となります。 必要なストレージ容量、必要なストレージ待ち時間、必要なストレージ スループットと IOPS、最も安価な構成のバランスの面で、ユーザーと HANA ワークロードにとって適切な妥協点を見つけ、それに合わせて調整できるように、Azure には機能や価格がそれぞれ異なるさまざまなストレージの種類が用意されています。
ストライプ セットと SAP HANA データ ボリュームのパーティション分割
Azure Premium Storage v1 を使用すると、/hana/data や /hana/log ボリュームを複数の Azure ディスクにストライピングして、最高の価格/パフォーマンス比が得られる可能性があります。 より大きなディスク ボリュームをデプロイするほど、必要な IOPS またはスループットが増え、そうしなくて済みます。 複数の Azure ディスクにまたがる 1 つのボリュームを作成するには、Linux にの一部である LVM と MDADM ボリューム マネージャーを使用できます。 ディスクをストライピングする方法は、数十年間使用され、よく知られています。 これらのストライプ ボリュームは、必要になる可能性のある IOPS またはスループットの能力を利用できるようになるためにメリットがありますが、これらのストライプ ボリュームの管理に関しては複雑さが増します。 ボリュームの容量に拡張する必要がある場合は特にそうなります。 少なくとも /hana/data に対しては、SAP は複数の Azure ディスクにまたがるストライピングと同じ目標を達成する代替方法を導入しました。 SAP HANA 2.0 SPS03 以降では、HANA IndexServer を使用してさまざまな Azure ディスクに配置されている複数の HANA データ ファイル間で I/O アクティビティをストライピングできます。 この利点は、複数の Azure ディスクにまたがるストライプ ボリュームの作成と管理を行う必要がないことです。 データ ボリュームのパーティション分割の SAP HANA 機能の詳細については、次を参照してください。
詳細を読むと、この機能を応用することで、ボリューム マネージャー ベースのストライプ セットの複雑さが解消されることが明らかになります。 また、HANA データ ボリュームのパーティション分割は、Azure Premium Storage v1/v2 などの Azure ブロック ストレージのみに対して機能するわけではないこともわかります。 この機能は、これらの共有に IOPS またはスループットの制限がある場合に備えて、NFS 共有間でストライピングするためにも使用できます。
Linux I/O Scheduler モード
Linux には、数種類の I/O スケジューリング モードがあります。 Linux ベンダーおよび SAP が一般的に推奨しているのは、ディスク ボリュームの I/O スケジューラ モードを mq-deadline または kyber モードから noop モード (マルチ キュー以外) または none モード (マルチ キューの場合) に再構成することです (SLES saptune プロファイルでまだ行っていない場合)。 詳細については、次を参照してください。
Red Hat では、さまざまな SAP アプリケーションの特定のチューニング プロファイルによって確立されたとおりの設定にします。
論理ボリューム マネージャーを使用する場合のストライプ サイズ
LVM または mdadm を使用して、複数の Azure Premium ディスクにまたがるストライプ セットを構築する場合は、ストライプ サイズを定義する必要があります。 これらのサイズは、 /hana/data と /hana/log で異なります。 推奨事項:ストライプ サイズとして、以下を使用することをお勧めします。
- /hana/data の場合は 256 KB
- /hana/log の場合は 64 KB
注意
/hana/data のストライプ サイズは、最新の Linux バージョンでのカスタマー エクスペリエンスに基づいて、64 KB または 128 KB を求めていた以前の推奨事項から 256 KB に変更されました。 256 KB のサイズではパフォーマンスが少し向上します。 I/O サイズを大きくして十分なスループットを得るために、 /hana/log の推奨ストライプ サイズも 32 KB から 64 KB に変更されました。
注意
Azure ブロック ストレージでは VHD の 3 つのイメージが保持されるので、RAID ボリュームを使用して冗長レベルを構成する必要はありません。 Azure Premium ディスクでのストライプ セットの使用は、十分な IOPS や I/O スループットを提供するボリュームの構成のみを目的としています。
複数の Azure ディスクを 1 つのストライプ セットにまとめると、IOPS とストレージ スループットの面から累積的になります。 そのため、3 個を超える P30 Azure Premium Storage v1 ディスクにストライプ セットを構成すると、単一の Azure Premium Storage v1 P30 ディスクの 3 倍の IOPS と 3 倍のストレージ スループットが得られるはずです。
重要
LVM または mdadm をボリューム マネージャーとして使用して、複数の Azure Premium ディスクにまたがるストライプ セットを作成する場合は、SAP HANA ファイルシステムの /data、/log、/shared の 3 つを既定またはルート ボリューム グループに配置しないでください。 通常は、/data、/log、および /shared 用に個々のボリューム グループを作成するという Linux ベンダーのガイダンスに従うことを強くお勧めします。
HANA 共有ファイル システムに関する考慮事項
HANA ファイル システムのサイズを決定する場合、最も注意が必要なのはデータとログ ファイルの HANA システムです。 しかし、/hana/shared は、HANA バイナリのような重要なコンポーネントをホストしているため、安定した HANA システムの運用においても重要な役割を果たしています。
サイズが小さいと、/hana/shared は過剰な読み取り/書き込み操作によって I/O が飽和状態になる可能性があります。たとえば、大きなダンプの書き込み中、集中的なトレース中、または /hana/shared ファイル システムにバックアップが書き込まれた場合などです。 また、待機時間も増加する可能性があります。
HANA システムが HA 構成の場合、共有ファイル システム (/hana/shared) からの応答が遅くなると、クラスター リソースがタイムアウトする可能性があります。 これらのタイムアウトは、HANA リソース エージェントがデータベースを利用できないと誤って判断する可能性があるため、不要なフェールオーバーにつながる可能性があります。
/hana/shared の推奨サイズの SAP ガイドラインは次のようになります。
| 体積 | 推奨サイズ |
|---|---|
| /hana/shared scale-up | 最小 (1 TB、1 x RAM) |
| /hana/shared scale-out | 1 x ワーカー ノードの RAM 4 つのワーカー ノードあたり |
詳細については、次の SAP ノートを参照してください。
3288971 - FAQ: SAP HANA システム レプリケーション環境における SUSE HAE/RedHat HAA Pacemaker Cluster Resource Manager
1999930 - FAQ: SAP HANA の I/O 分析
ベスト プラクティスとして、パフォーマンスのボトルネックを防止するために /hana/shared のサイズを指定します。 十分なサイズの /hana/shared ファイル システムは、特に HA シナリオにおいて、SAP HANA システムの安定性と信頼性に貢献することを覚えておいてください。
HANA 用 Azure Premium Storage v1 の構成
Azure Premium Storage v1 を使った HANA ストレージ構成に関するおすすめ候補の詳細については、「SAP HANA Azure 仮想マシン Premium SSD ストレージの構成」に関するドキュメントを参照してください。
HANA 用 Azure Premium SSD v2 の構成
Azure Premium SSD v2 ストレージを使った HANA ストレージ構成の推奨事項の詳細については、SAP HANA Azure 仮想マシン Premium SSD v2 ストレージの構成に関するドキュメントを参照してください。
SAP HANA 用の Azure Ultra Disk ストレージ構成
Azure Ultra Disk ストレージを使った HANA ストレージ構成の推奨事項の詳細については、SAP HANA Azure 仮想マシン Ultra Disk ストレージの構成に関するドキュメントを参照してください。
Azure NetApp Files 上の NFS v4.1 ボリューム
HANA 用 Azure NetApp Files の詳細については、「SAP HANA 用 Azure NetApp Files 上の NFS v4.1 ボリューム」を参照してください。
次のステップ
詳細については、次を参照してください。