AZ-120 試験対策メモ

AZ-305試験を受験後、会社の報奨金制度に目がくらみ、教材が少ないAZ-120: Planning and Administering Azure for SAP Workloads への挑戦にあたって、勉強したことの試験対策メモを作成しました。SAPについては監視オペレーターの際に一次切り分けで触ったことがあるくらいです。
2026年2月時点でのメモになりますことをご了承ください。

試験自体には3月中旬に受験しギリギリ合格することができました。
日本語版の問題集も現時点ではないことから試験勉強は少し大変でした。

SAP HANAについて

こちらの記事が大変わかりやすく参考になりました。

なぜAzureでSAPを使うのか

MSlearnだと文字が多くて何言ってるか、よくわからないがこういうところにメリットがあるらしい
①オンデマンドかつスケーラブル
②インテリジェント ソリューション
③セキュリティとコンプライアンス
④グローバル スケール
⑤エンタープライズ グレードの復元力

①.「必要な時だけ、バカでかいサーバーが使える」（オンデマンドかつスケーラブル）
SAP HANAにはメモリ数TBの超高級マシン（Mシリーズなど）が必要だが、これを自前で買うと数千万円する。
Azureなら、「本番はデカいマシン、開発用は小さいマシン」 と使い分け、不要な時は消せるのが最大の魅力。

②.「SAPのデータを死蔵させない」（インテリジェント ソリューション）
SAPの中には「宝の山（売上や在庫データ）」が眠っている。
これをAzure上のSynapse AnalyticsやPower BIにヒョイっと繋げば、今まで数日かかっていた経営レポートがリアルタイムで見られるようになる。

③.「セキュリティ設定が楽になる」（セキュリティとコンプライアンス）
Entra ID（旧Azure AD）を使って、「会社のPCにログインすれば、そのままSAPにもログインできる」という環境が作れる。セキュリティ管理がAzure側で一元化できるのが強み。

④.「世界中の拠点で同じように動かせる」（グローバル スケール）
海外拠点を持つ企業にとって、世界中にリージョンがあるAzureは最強のインフラ。現地の法律（データの国外持ち出し禁止など）を守りつつ、現地の近くにサーバーを置けるので、動作もサクサクになる。

⑤.「絶対に止めない仕組みが整っている」（エンタープライズ グレードの復元力）
「可用性ゾーン（AZ）」をまたいだ冗長構成を組むことで、SLA 99.99%（年間で数分しか止まらないレベル）を実現できます。自分たちでこのレベルのデータセンターを作るのはほぼ不可能。

⑥.「結局、安く済む」（TCOの削減）
解説: TCO（総所有コスト）とは、単なるサーバー代だけでなく、電気代、場所代、保守スタッフの人件費すべてを含んだコスト。
オンプレだと「数年後の最大負荷」を予想して高い機材を買いますが、Azureなら「今必要な分」だけで済むので、特に開発・テスト環境を夜間に止めるだけで、劇的にコストが下がる。

企業側のメリット

1.「未来の予測」にお金を使わなくていい
オンプレ: 5年後のデータ増加を見越して、最初から「一番デカくて高いサーバー」を数千万円で買わなければいけない。
Azure: 最初は「今必要なサイズ」で始め、データが増えたら管理画面からポチッと設定を変えてスペックアップ（スケールアップ）できる。無駄な先払いが発生しない。

2.「寝ている間」はタダにできる
オンプレ: 誰も使っていない夜間も、サーバーは電気を食い続け、保守費用もかかる。
Azure: 本番以外の「開発用」や「テスト用」環境を夜間や週末に停止（スヌーズ）すれば、その間のコンピューティング料金は0円になる。

3.「専門家」を雇うコストを外注できる
オンプレ: 停電対策（UPS）、空調管理、物理セキュリティ、ハードウェアの故障対応などのために専門スタッフが必要になる。
Azure: これらはすべてMicrosoftが肩代わりしてくれる。企業は「SAPの中身（業務）」だけに集中できるので、人件費という見えないコストが下がる。

4.「DR（災害対策）」が劇的に安い
オンプレ: 災害に備えて、遠く離れた場所にもう一つ同じデータセンターを作る必要があり、コストが2倍かかる。
Azure: Azure Site Recovery (ASR) などを使えば、必要な時だけ別のリージョンで動かす構成が組めます。普段はバックアップ代だけで済むので、コストを抑えて最強の復元力を手に入る。

AZ-120の試験に出る「安くするテクニック」(AI談）

試験では「安くなるよ」という知識だけでなく、「どうやって安くするか」が問われる。
・Azure Reserved Instances (予約インスタンス): 1年または3年の利用を約束することで、最大72%割引を受ける。
・Azure Hybrid Benefit: すでに持っているWindowsやSQL ServerのライセンスをAzureに持ち込んで、料金を安くする。
・Snoozing (スヌーズ): 不要な時間の自動停止。

用語解説

・ランドスケープ
ITランドスケープ内のSAP資産全体のこと。
SAPランドスケープは、すべての本番環境と非本番環境が含まれる。

・SAPランドスケープ
システムの使用方法に基づいてSAPサーバーを異なる層に編成する方法。
一般的なSAPの導入は、DEV（開発）、QAS（品質保証）、PRD（本番）の3つの異なるランドスケープに分割され、DBMSとSAPアプリケーションの観点から見ると、ハイブリッドな構成になることがよくある。例えば、NetWeaver、S/4HANA、SAP HANA、その他のDBMSが混在しているケース。

・コンポーネント
ERP Central Component（ECC）、Business Warehouse（BW）、Solution Manager、Enterprise Portal（EP）などの個々のSAPアプリケーション。
SAPコンポーネントは、従来のABAPまたはJavaテクノロジーをベースにすることも、
Business ObjectsなどのNetWeaver以外のアプリケーションをベースにすることもできる。

・AnyDB
SAP(HANA以外)を実行するために選択された任意のサードパーティ データベース。

SAP 認定の「3段階」

レベル	内容	試験での扱い
Azure認定 VM	AzureでWindowsやLinuxが普通に動くVM。	SAPの話ではないので試験には出ないと予想される。
SAP NetWeaver 認定	SAPのアプリ層（ASCS/PAS）を動かしてOKなVM。	DシリーズやEシリーズが中心。選択肢がかなり広い。
SAP HANA認定	HANA DBを動かしてOKなVM。	Mシリーズや一部のEシリーズに限定。非常に厳しい制約がある。

なぜ NetWeaver と RDBMS（HANA以外）で分かれているのか？

SAP NetWeaver（アプリケーション層）は、主に CPU パワーと一定のメモリがあれば動きます。しかし、データベース層は「ディスクの書き込み速度」や「メモリの安定性」に極めてシビア。
NetWeaver インスタンス:アプリを動かすだけなので、比較的多くの VM シリーズ（D, E, F, Mなど）がサポートされる。
計算能力（SAPS）が足りていれば、安価な VM でも認定されることが多い。
HANA 以外の RDBMS（SQL Server, Oracle 等）:データベースなので、ストレージの I/O 性能が保証されているシリーズ（"s" シリーズ）である必要がある。

試験対策

試験問題で「どの VM を選ぶか」を考えるときは、以下の優先順位でチェックする。
HANA DB 用か？ → M シリーズ または 認定済み E シリーズ を探す。
Appサーバー（NetWeaver）用か？ → D シリーズ や E シリーズ で十分。
OS は何か？ → 最新の Mv3 などは古い OS（Windows 2012 等）をサポートしていないので、OS バージョンの指定がある場合は注意。

「SAP Note 1928533」 は NetWeaver と 非HANA DB 用。
「SAP Note 2316233」 は SAP HANA 認定用。
試験ではこの「Note 番号の使い分け」が知識として問われることがある？

Azure 上の SAP ソリューションの展開オプション

1. Azure Virtual Machines (SKU の拡充)

SAP 認定 VM は、メモリ容量や用途（HANA かそれ以外か）に応じて多様化している。
SAP HANA 認定: M シリーズ、Mv2 シリーズなど。
大容量メモリ: M208ms_v2（約 5.7 TiB）などの超大型インスタンスのサポート。
スケーラビリティ: M128 を使用したスケールアウト構成。
HANA 以外 (NetWeaver 等): D シリーズや E シリーズなど、HANA ほどメモリを要求しないワークロード向けにも選択肢が拡大。
GS5 シリーズ: ストレージ性能とスループットに特化した古い世代だが、依然として特定のシナリオで認定されている。

用途別 VM シリーズ一覧

SAP はメモリ消費が激しいため、基本的には 「メモリ最適化（Memory Optimized）」 ファミリが中心になる。

カテゴリ	シリーズ	主な用途・特徴
超大規模データベース	M / Mv2 / Mv3	SAP HANA 本番環境の本命。最大 12TB 以上のメモリを搭載可能。高価だが、HANA の巨大なデータをメモリに載せるために必須。ハイパースレッディング有効。最新の Mv3 は vCPU あたりのメモリ効率が非常に高い。
中・大規模データベース	E / Ed / Eb	HANA や SQL Server、Oracle など。メモリと CPU のバランスが良く、コストパフォーマンスが高い。S/4HANA の小〜中規模環境で多用。
アプリケーション層	D / Dd	SAP Application Server (AS) や開発環境。汎用的な計算能力が必要な NetWeaver 等に最適。DB ほどメモリを必要としない層に使う。
テスト・開発用	B	一時的な検証環境や軽量なアドオン用。「バースト可能」な安価な VM。本番環境には推奨されない。

特殊仕様

試験のひっかけ問題や設計の注意点として狙われやすいポイント。
ハイパースレッディング: Dsv3, Edsv4, Mシリーズ以降などは、ハイバイザー層でハイパースレッディングが有効になっている。
第2世代 (Gen2) 限定: D(d)sv5 や E(d)sv5 シリーズは、Gen2 VM 形式のみサポートされる。古い OS や Gen1 形式は使えない。
OS バージョンの制約: 最新の Msv3 / Mdsv3 を使う場合、OS は比較的新しいもの（例：Windows 2019/2022、SLES 15 SP4 以降）が必要です。
最小ディスクサイズ: 最新の v5 シリーズや Msv2/v3 シリーズで、一時ディスク（Temporary Disk）を持たない構成にする場合、ベース VHD は 128 GB 以上である必要があります。

シリーズ別の使い分け（NetWeaver編）

NetWeaverは、ユーザーからのリクエストを処理する「計算担当」。

シリーズ	特徴と使い分け
Dシリーズ	「標準・汎用」。CPUとメモリのバランスが良い。多くのユーザーが同時にアクセスしない小〜中規模のアプリケーションサーバーに最適。
Eシリーズ	「メモリ重視」。Dシリーズよりも1コアあたりのメモリ量が多い。メモリを大量に消費するJavaスタックのシステムや、大規模なABAPサーバーに多用される。
Gシリーズ	「巨大・モンスター」。非常に大きなメモリと高いI/Oが必要な場合に使われる（※ただし、最近はMシリーズや最新のEシリーズに取って代わられつつある「古参」の選択肢）。

まとめ：NetWeaver VM 判断基準

試験で構成図を見せられたら、こう判断する。
「とりあえずアプリサーバー置かなきゃ」 → Dシリーズ（Dsv5など）
「Javaベース（SAP Portal等）でメモリ食いそう」 → Eシリーズ（Esv5など）
「ライセンス料が高すぎるからCPUを絞りたい」 → 制約付きvCPU（E32-16sなど）

「特殊な文字（サフィックス）」の意味について

s (Storage): Premium SSD / Ultra Disk 対応（SAP 本番環境では必須）。
d (Disk): ローカルの「一時ディスク (NVMe等)」を搭載。
m (Memory): 通常の E シリーズ等よりも、さらにメモリ量が多い。
b (Bandwidth): ストレージのスループット（帯域幅）が強化されている。

選び方のフローチャート（試験対策用）

データベースは SAP HANA か？→Yes: メモリサイズを確認。
数 TB 以上の巨大環境 → M シリーズ / Mv2
数百 GB 〜 1TB 程度 → E シリーズ (Esv5 等)
アプリケーションサーバー (ASCS/PAS/AAS) か？→Yes: 汎用的な D シリーズ (Dsv5 等) を選択。
高可用性 (HA) 構成を組むか？→Yes: "s" が付く SKU（Premium SSD 対応）を選んでいるか確認。

2. SAP Cloud Appliance Library (CAL)

「素早く、簡単に、テスト環境を構築したい」場合に最適なツール。
概要: SAP が提供する事前構成済みアプライアンス（S/4HANA, BW/4HANA 等）を数クリックで Azure 上にデプロイ可能。
メリット:インフラの手動プロビジョニングが不要。
PoC（概念実証）やトレーニング、デモ環境の構築時間を大幅に短縮。
注意点: 本番環境用ではなく、主に開発・テスト・検証用として利用される。

3. RISE with SAP & SAP Managed Services

従来の「自社管理（IaaS）」とは異なる、SAP 社が主導する運用モデル。
RISE with SAP: SAP 社が Azure サブスクリプションを所有・管理するマネージドサービス。
責任範囲の変化:お客様（ユーザー）はビジネスプロセスに集中。
基盤となる Azure インフラや OS、SAP ベース層の運用は SAP 社が担当。
統合: 自社管理の Azure リソース（AD や周辺システム）と SAP 管理の環境をどう接続・統合するかが設計の鍵となります。

試験対策

本番環境で大規模 HANA を動かすなら？ → 認定済みの Mv2 シリーズ などを選択。
数日で S/4HANA を試用したいなら？ → SAP CAL を選択。
インフラ運用を SAP に任せたいなら？ → RISE with SAP を検討。

SAP サイジング手法

SAP システムのサイズを決定するには、以下の方法がある。

手法	適したシナリオ	メリット	デメリット
Quick Sizer	新規導入 (Greenfield)	業務量（伝票数等）から論理的に算出できる。	実際のプログラムの組み込み（アドオン）負荷は考慮されない。
参照ベース (ST03N)	既存システムの移行 (Brownfield)	実際の稼働実績（統計データ）に基づくため、精度が非常に高い。	既存システムのデータ収集が必要。
Early Watch Alerts (EWA)	現状分析と将来予測	過去1年間のピーク時（決算期など）の負荷傾向を把握できる。	SAPへの接続設定（Solution Manager等）が必要。
Tシャツサイズ	超初期段階の予算取り	ユーザー数だけで瞬時に概算が出せる。	精度が低いため、本番機の発注には使えない。

書き込みアクセラレータ

MシリーズのVMでPremium SSDを使用する際、OLTPやデータベースのログ書き込み（I/O）待機時間を一桁ミリ秒レベルに短縮する機能。
高性能なデータ永続化が求められるミッションクリティカルな環境（SAP HANAなど）の高速化に特化している。
この機能は、特にSAP HANAなどのログファイルへの書き込みを高速化し、トランザクションの応答性を維持するために利用される。

主な特徴と目的:

I/O待機時間の短縮: ディスクへの書き込み処理を高速化し、ログファイル等のパフォーマンスを向上させる。
適した用途: 大量の書き込みが発生するデータベース（ログファイル）や、高いストレージ応答速度が必要なワークロード。
適さない用途: SQL Serverデータファイルなど、書き込み負荷が少ない用途には不要。

技術的な要件と制限:

AzureのMシリーズ仮想マシン（VM）でのみ利用可能。
Premium SSD マネージド ディスクが必要。
VMのデータディスク数や、書き込みアクセラレータの最大IOPS制限（VMサイズに依存）がある。

SAP HANA Dynamic Tiering 2.0 (DT 2.0)

SAP HANAは本来「すべてのデータをメモリに載せる」のが理想ですが、データが増え続けるとメモリ代（AzureのVM費用）が際限なく上がってします。
そこで、「あまり使わないデータ（ウォームデータ）を、メモリから追い出してディスク（SSD）側に持たせる」のが DT 2.0 の役割。

特徴

専用VMが必須: SAP HANAと同じVMにはインストールできない。別の専用Azure VMが必要。
同一VNet内: HANA VMとDT 2.0 VMは同じ仮想ネットワーク（VNet）に配置。
高速ネットワーク（Accelerated Networking）: 最小10Gbpsのスループットを確保するため、必須。
Premium SSD必須: ストレージはStandardではなくPremium SSDを使用し、LVM/mdadmでストライピングする。
共有ディレクトリ (/hana/shared): HANA VMとDT 2.0 VMで共有する必要がある（通常はNFSを使用）。

S/4HANA および SAP BW ではサポート対象外（※これらは代わりに SAP HANA Native Storage Extension (NSE) や Extension Node を使用する）。
主なターゲットは 「ネイティブHANAアプリケーション」。

Azure VM ディスク構成：ベストプラクティス（SAPワークロード）

1.ディスク選定基準

Premium SSD/Premium SSD v2 (推奨): すべての運用環境（Production）、およびDBMSのデータ・ログファイル。
Standard SSD:SAPアプリケーション層（ASCS/ERS/PAS/AAS）や、パフォーマンス要件の低い非運用環境。
Standard HDD:SAPワークロードではサポート対象外（SAP Note 1928533）。

2.ボリューム設計の鉄則

D:ドライブ（一時ディスク）の禁止: 非永続ディスクのため、DBMSファイルやSAP関連ディレクトリには絶対に使用しない。Windowsは pagefile.sys、Linuxは swap 配置用。
データとログの分離: IOPS競合を避けるため、DBMSデータファイルとトランザクションログファイルは物理的に異なるディスクに保存する。
ストライピング (RAID 0): 合計IOPSやスループットを向上させるために、OS側の機能（Linux: mdadm/LVM, Windows: 記憶域スペース）で複数ディスクをストライピングする。Azure側で冗長化されているため、RAID 1/5等は不要。

3.キャッシュ設定（重要）

Premium Storageのホストキャッシュ設定は、ワークロード特性に合わせて以下のように設定する。

配置対象	キャッシュ設定	理由
DBMS データファイル	読み取り専用 (ReadOnly)	読み取りの高速化。書き込みは非同期のためキャッシュ不要。
DBMS ログファイル	なし (None)	書き込み遅延を最小化。Mシリーズでは書き込みアクセラレータを併用。
OS ディスク	読み取り/書き込み (Read/Write)	標準的なOSの挙動を優先。

4.SAP HANA ログ書き込みの最適化

書き込みアクセラレータ (Write Accelerator): MシリーズVMにおいて、/hana/log 用ディスクに適用。
条件: Managed Premium SSDを使用し、ホストキャッシュを「None」に設定する。

5.Linux 固有の設定

I/O スケジューラ: noop または none モードを推奨（SAP Note 1984798）。
ストライプサイズ: /hana/data は 64KB〜128KB、/hana/log は 32KB を推奨。

Azure Mシリーズ：書き込みアクセラレータとストレージ最適化

1.書き込みアクセラレータ (WA) の必須条件対象VM: Mシリーズ、Mv2シリーズのみ。

対象ディスク: マネージドディスクの Premium SSD (v1)。※Premium SSD v2 や Ultra Disk はWA非対応（単体で十分な性能があるため）。
適用ボリューム: /hana/log のみ。SAP HANAの運用環境認定には、Mシリーズ＋Premium SSD v1の構成においてWAの使用が必須条件となる。
キャッシュ設定: 「None（キャッシュなし）」に設定し、WAのみを有効化する。

2.ボリューム別のキャッシュ構成（運用環境）

ボリューム	推奨ディスク	キャッシュ設定
/hana/data	Premium SSD	なし (None)
/hana/log	Premium SSD	なし + 書き込みアクセラレータ
/hana/shared	Premium SSD	読み取りのみ (ReadOnly)

3.コスト最適化（非運用環境）の構成パターン

コストを抑える場合、パフォーマンスを犠牲にしつつディスク構成を簡略化する手法が取られる。
ボリュームの統合: /hana/data と /hana/log を一つのボリュームにまとめ、P6やP10などの安価なディスクをストライピングする。
ディスク種類の混合:性能に影響するデータ/ログには Premium SSD を使用。rootボリュームや /usr/sap には Standard SSD（旧HDDの代替）を使用。
注意点: 標準ストレージ（Standard SSD/HDD）が混在すると、Azureの単一インスタンスSLA（99.9%等）の対象外となるリスクがある。
EシリーズなどHANA認定外のVMを使用する場合、ストレージ遅延が1msを超え、パフォーマンス不足が発生する可能性あり。

4.仮想マシンごとのWA接続上限数

WAを有効にできるVHD（ディスク）の本数には、VMサイズごとに上限がある。これを考慮してストライピング（RAID 0）の本数を決定する。
M128xx / M416xx: 最大 16 本M64xx / M208xx: 最大 8 本 M32xx: 最大 4 本

5.設計上の留意点（試験での判断基準）

IOPSの制限: WAを有効にしたボリュームの合計IOPSは、VM自体のWA制限（5,000 / 10,000 / 20,000 IOPS）で頭打ちになる。
ディスクを増やしてもこの上限は超えられない。バースト機能: 小さなVMサイズ（M32tsなど）でP6ディスク等を使用する場合、クレジットに基づくバースト機能で一時的に性能が上がるが、持続的な高負荷には耐えられない可能性がある。
再起動時の注意: /hana/data に読み取りキャッシュを設定しない理由は、HANA再起動時の大規模なデータロードにおいて、キャッシュが効かず、かつキャッシュの管理オーバーヘッドが逆効果になるため。

Azure Ultra Disk による SAP HANA ストレージ設計

1.Ultra Diskの基本特性

性能の独立性:ディスクサイズ（容量）に依存せず、IOPS と スループット を個別に定義・変更可能。
動的変更:VMをシャットダウンすることなく、ワークロードに合わせてIOPSやスループットをリアルタイムに調整できる。
低遅延: Premium SSD よりも読み取り/書き込みの待機時間が短く、特に HANA の起動時間（メモリへのロード）やセーブポイントの書き込み性能が向上する。

2.設計上のメリット

構成の簡素化:Premium SSD ではIOPS/スループットを稼ぐために複数ディスクの RAID 0（LVM/mdadm）が必要だったが、Ultra Disk では 単一ディスク で高い要求性能を満たすことができる。
ハイブリッド構成: パフォーマンスがクリティカルな /hana/data と /hana/log にのみ Ultra Disk を採用し、それ以外のボリューム（OSや /usr/sap）には Premium SSD を使用してコストを最適化する構成が可能。

3.ボリューム別の適用メリット

ボリューム	Ultra Disk 採用の効果
/hana/data	セーブポイントの書き込み待機時間を短縮。再起動時のデータロードが高速化。
/hana/log	常にサブミリ秒（1ms未満）の極めて低い書込遅延を実現。

4.運用上の重要な制限事項

バックアップの制約: 現時点では Ultra Disk はストレージスナップショットに対応していない。そのため、Azure Backup サービスによる VM 全体のスナップショットバックアップが利用不可 となる点に注意が必要。
リージョン・VM制限: すべてのリージョンやVMシリーズ（M/Eシリーズの一部など）で利用できるわけではないため、事前の可用性確認が必須。
書き込みアクセラレータ (WA): Ultra Disk は単体で十分な性能を持つため、書き込みアクセラレータはサポートされない（かつ不要）。

5.パフォーマンスの目安

IOPS:容量1GiBあたり最低2IOPS。
KPI対応: 大規模VM（M416ms_v2など）では、1,500 MB/秒を超える高いスループットを単一ボリュームで設定可能。

試験対策

「ダウンタイムなしでディスク性能を上げたい」や「RAIDの構成を避けつつ高いIOPSを実現したい」という要件が出た場合は、Ultra Disk が正解となる。
一方で、「Azure Backup によるスナップショットが必要という要件がある場合は、Ultra Disk を避ける（または別のバックアップ手法を検討する）必要がある。
Ultra Disk の仕様:現時点において、Ultra Disk は Azure マネージドディスクのスナップショット機能自体をサポートしていない。

Azure NetApp Files (ANF) による SAP HANA ストレージ設計

1.プロトコル要件（NFS v4.1 の絶対条件）

ANFを使用する場合、ボリュームごとに使用可能なプロトコルが厳格に定められている。
/hana/data および /hana/log: 必ず NFS v4.1 を使用すること。NFS v3 はサポート対象外。
/hana/shared: 機能的に NFS v3 または v4.1 のいずれも使用可能。
注意: NFS 4.1 を使用する理由は、ロックメカニズムやセッション管理といった機能面で SAP HANA のデータ整合性を保証するためである。

2.ANF の基本仕様と制約

最小容量プール: 4 TiB。これが課金の最小単位となる。
最小ボリュームサイズ: 100 GiB。
ネットワーク: ANF ボリュームと VM は同一の仮想ネットワーク（VNet）、または同一リージョン内のピアリングされた VNet に存在する必要がある。また、ANF 専用の 委任されたサブネット（Delegated Subnet） が必要。
SLA: 99.99% の高い可用性を提供。

3.パフォーマンスと待機時間（1msの壁）

SAP HANA のパフォーマンス、特に Redo ログの書き込みにおいて、ストレージ待機時間を 1ms 未満 に抑えることが必須。
近接配置の重要性: VM と ANF の物理的な距離が遠いと遅延が発生する。これを解決するために以下の手法がとられる。
ゾーン配置（可用性ゾーン）: VM と ANF ボリュームを同じ可用性ゾーン（AZ）に配置する。
AVG（Application Volume Group）: SAP HANA 専用の機能。後述の 近接配置グループ（PPG） と連携し、VM に物理的に最も近い NetApp ハードウェア上にボリュームを自動配置する。

4.アプリケーションボリュームグループ (AVG) と PPG

最高レベルの低待機時間を実現するための設計パターン。
仕組み: 近接配置グループ（PPG）を使用して VM を特定のデータセンターに固定し、AVG がその PPG 情報を参照して ANF ボリュームをデプロイする。
メリット: データ用とログ用のボリュームを NetApp バックエンドの異なるコントローラーに分散配置するなど、パフォーマンスを最大化する。
デメリット: VM の場所が特定のデータセンターに固定されるため、将来的な VM サイズ変更やファミリ変更の柔軟性が低下する。
推奨: 運用環境で極めて高い IO 性能が求められるシステムに限定して採用すべき手法。

5.ID 管理の整合性（sidadm / sapsys）

ユーザーID (UID) / グループID (GID): VM 上の sidadm と sapsys の ID は、ANF 側の構成と完全に一致させる必要がある。
不一致のリスク: ID が一致しない場合、マウントしたボリューム上のファイル権限が nobody と表示され、SAP HANA が起動できない原因となる。

6.スループットの決定要因

ANFのスループットは、「ボリュームクォータ（サイズ）」と「サービスレベル（Standard/Premium/Ultra）」の掛け合わせで決定する。
SAP HANA の KPI（最小スループット要件）を満たすためには、十分なクォータを割り当てる設計が必要。

Azure NetApp Files (ANF) のサイズ設定とパフォーマンス設計

1.容量とスループットの相関関係

ANFのスループット（MB/秒）は、**「割り当て容量（TiB）」×「サービスレベルの単価」**で決定される。
Standard: 16 MB/秒 / 1 TiBPremium: 64 MB/秒 / 1 TiBUltra: 128 MB/秒 / 1 TiB
LIF（論理インターフェイス）の上限:単一のLinuxセッション（1つのVMからの接続）における最大スループットは、物理的な制限により 1.2 〜 1.4 GB/秒 で頭打ちとなる。そのため、1枚のディスクでこれ以上の性能を求めてサイズを巨大化（例：Ultraで12TB超）させても、それ以上の速度向上は見込めない。

2.SAP HANA KPIを満たすための最小サイズ

SAPが要求する最小スループット要件（読込 400MB/s、書込 250MB/s）を満たすためには、以下の容量以上のボリュームを作成しなければならない。

ボリューム	必要スループット	Premium層での必要サイズ	Ultra層での必要サイズ
/hana/log (書込)	250MB/秒	4TiB	2TiB
/hana/data(書込)	250MB/秒	4TiB	2TiB
/hana/data(読込)	400MB/秒	6.3TiB	3.2TiB

/hana/data に関する注意: 読込要件（400MB/s）の方が厳しいため、容量設計はこちらに合わせる必要がある。

3. 推奨構成まとめ（スケールアップ/スケールアウト）

ボリューム	推奨サイズ（目安）	推奨プロトコル
/hana/log	2 〜 4 TiB (KPI維持のため)	NFS v4.1
/hana/data	3.2 〜 6.3 TiB (KPI維持のため)	NFS v4.1
/hana/shared	1 x RAM (最大1TB)	NFS v4.1 (推奨) / v3
/hana/backup	2 x RAM	NFS v4.1 (推奨) / v3

4. 運用上のメリット：動的なサイズ変更

ダウンタイムなしの調整: ANFは、VMの停止やアンマウントを行わずに、オンラインのままボリューム容量を拡張・縮小できる。
柔軟なスループット管理: HANAの起動（データロード）を速くしたい時や、大規模なバックアップを行う時だけ一時的に容量を増やしてスループットを稼ぎ、完了後に元のサイズに戻すといったコスト最適化が可能。

5.バックアップボリュームの統合

/hana/logbackup や /hana/backup は、複数のHANAインスタンスで1つの大きなボリュームを共有（統合）することが可能。
統合してボリュームを大きくすることで、サービスレベルを「Standard」に下げても、トータルの容量に比例して実用的なスループットを確保でき、コスト削減に寄与する。

試験対策のアドバイス

「ANFを使っている環境で、HANAの読込性能がKPIに届かない」という問題が出た場合、解決策は　「ボリュームのクォータ（容量）を増やす」または「サービスレベルをPremiumからUltraへ上げる」 のいずれか。また、単一VMからのスループット限界（1.2〜1.4GB/s）についても、非常に高い性能を要求されるシナリオでのボトルネックとして意識しておく。

SQL Server on Azure：SAP ワークロードの設計指針

1.tempdb の配置と最適化

Azure VM 固有の「一時ドライブ（D:ドライブ）」を有効活用することが推奨される。
配置場所: tempdb のデータファイルおよびログファイルを D:ドライブ（非永続ディスク）に配置する。
メリット:D:ドライブは VM ホストのローカル SSD を使用しているため、マネージドディスクよりも低遅延かつ高スループットを期待できる。
運用上の注意:D:ドライブは再起動のたびに初期化される。
そのため、SQL Server サービスが起動する前に、tempdb 用のフォルダ構造を自動再作成する仕組み（スタートアップスクリプト等）が必要になる。
構成: パフォーマンス向上のため、複数の tempdb データファイルを使用することが推奨される。

2.ファイルシステムとブロックサイズ

ストレージの効率とパフォーマンスを最大化するための設定。
NTFS アロケーション ユニット サイズ: SQL Server のデータおよびログファイルを格納するボリュームは、必ず 64 KB でフォーマットする。
D:ドライブ:標準でフォーマット済みのため、通常はそのまま利用可能。

3.ボリュームの保守タスクを実行する権限

データベースの作成や復旧時のパフォーマンスを向上させるための設定。
データの即時初期化 (Instant File Initialization): SQL Server がデータファイルを拡張する際、ゼロ埋め（初期化）をスキップすることで処理を高速化する。
設定方法: SQL Server サービスの実行アカウントに対し、Windows のローカルセキュリティポリシーで 「ボリュームの保守タスクを実行 (Perform volume maintenance tasks)」 権限を付与する。

4.ストレージ構成の基本

SQL Server を SAP で運用する際の標準的なディスク構成は以下の通り。
OS (C:): Premium SSD。
データ (通常 F: 等): Premium SSD / Ultra Disk（書き込みアクセラレータは非推奨、ReadOnly キャッシュ推奨）。
ログ (通常 G: 等): Premium SSD / Ultra Disk（書き込みアクセラレータ推奨、キャッシュ None）。
一時 (D:): ローカル SSD（tempdb 用）。

5.注意事項：A シリーズ VM

非推奨: A シリーズ VM はパフォーマンスが低く、D: ドライブの低遅延メリットも得られないため、現在の SAP デプロイでは原則として使用しない（SAP Note 1928533 参照）。

試験対策

試験問題で「SQL Server の tempdb パフォーマンスを最大化するための適切な配置場所はどこか？」と問われたら、「ローカルの一時ドライブ（D: ドライブ）」が正解。
また、フォーマット形式について問われたら「64 KB」 という数値を即答できるようにしておくこと。

SAP on Azure：データベース圧縮の設計指針

1.推奨される圧縮手法

SQL Server を使用する場合、以下の設定を適用することが強く推奨される。
PAGE 圧縮 (PAGE Compression): SAP と Microsoft が推奨する標準的な手法。
効果: IOPS の削減: ディスクから読み書きするデータ量が減るため、IOPS の消費を抑えられる。
メモリ効率の向上: 圧縮された状態でバッファプールに保持されるため、実質的なメモリ有効活用につながる。

2.Azure 移行前の圧縮が推奨される理由

オンプレミスから Azure への移行（アップロード）前に圧縮を完了させておくべき理由は以下の通り。
データ転送量の削減: アップロードするファイルサイズそのものが小さくなり、移行時間が短縮される。
移行作業の効率化: オンプレミス側のリソース（CPU/帯域）が Azure より強力な場合、移行先で圧縮を実行するよりも短時間で完了する可能性がある。
ストレージコストの最適化: データベースサイズを最小化することで、プロビジョニングするマネージドディスクのサイズ（P30 ではなく P20 など）を下げることができ、月額コストを抑制できる。

3.I/O 制限下でのメリット

Azure VM には「VM 単位のスループット/IOPS 上限」が存在する。
スループットの拡大: データを圧縮することで、同じ 100 MB/秒の帯域でも、非圧縮時より多くの実データを転送できる。
スロットリングの回避: IOPS 消費が抑えられるため、ディスクのパフォーマンス制限（スロットリング）に達しにくくなる。

4.考慮すべきトレードオフ

CPU 負荷の増加: データの圧縮・展開には CPU リソースを消費する。
判断基準: SAP ワークロードでは一般的に CPU よりも I/O がボトルネックになりやすいため、多くの場合、CPU 負荷増よりも I/O 削減のメリットが上回る。

試験対策

試験問題で「ストレージの IOPS 上限に達しているが、VM サイズやディスクをアップグレードせずにパフォーマンスを改善したい」というシナリオが出た場合、 「データベースの PAGE 圧縮」は有力な回答候補となる。また、移行シナリオにおいて「移行時間を短縮しコストを最小化する準備作業」を問われた際も、「オンプレミス側での事前圧縮」 が正解。

Azure Blob Storage へのデータベースファイル直接格納

1.構成の概要

SQL Server 2014 以降でサポートされる機能。
通常のように「Managed Disk (VHD) を作成して VM にマウントし、その中にファイルを置く」のではなく、URLを指定して直接 Blob（ページ Blob）にファイルを配置する。
対象: ユーザーデータベースのデータファイルおよびログファイル。
対象外: SQL Server のシステムデータベース（master, model, msdb 等）はこの構成に配置できない。

2.メリットとユースケース

ディスク枚数制限の回避: 小規模な VM サイズでは接続できるディスク枚数（VHD 数）に上限がある。Blob 直接配置であれば、マウント制限に縛られず、多数のファイルに分散できる。
IOPS 制限のバイパス: VM の「ストレージ I/O クォータ」ではなく「ネットワーク帯域」を消費するため、ストレージ側のスロットリングを回避できる場合がある。

3.重大な制約とデメリット

この構成が運用環境で「非推奨」とされる理由は以下の欠点にある。
ネットワーク帯域の消費: I/O トラフィックがストレージ専用チャネルではなく、汎用ネットワークチャネルを流れる。結果として VM のネットワーク帯域を圧迫し、他の通信に影響を与える可能性がある。
キャッシュの無効化: Premium Storage 最大の利点である「ホストベースの読み取りキャッシュ（ReadOnly キャッシュ）」が利用できない。
書き込みアクセラレータ (WA) 非対応: M シリーズ VM を使用していても、Blob 直接配置では WA を有効にできないため、ログの書き込み遅延を 1ms 未満に抑えることが困難。
パフォーマンスの不確実性: Premium Storage の Blob を使用しても、通常の VHD で定義されている IOPS/スループットのパフォーマンス目標（P30 なら 5,000 IOPS など）が適用されない。

4.設計上の判断基準

運用システム (Production): 構成を避けるべきである。 パフォーマンスの安定性と SLA を確保するため、必ず Azure Premium Storage の VHD (Managed Disk) を使用する。
非運用・特殊環境: VM サイズの制限でどうしてもディスクが追加できない等の極めて限定的な状況でのみ検討する。

試験対策

「Blob 直接配置は、ストレージ帯域ではなくネットワーク帯域を消費する」
「読み取りキャッシュや書き込みアクセラレータは、Blob 直接配置では使えない」
「システムデータベースは Blob 直接配置に置けない」

Azure 仮想マシンのセキュリティ設計指針

1.ネットワークセキュリティの基本

境界ネットワーク（DMZ）の構築: Web Dispatcher 等の外向きサーバーの前面に、Azure Firewall などのマネージドファイアウォールを配置し、境界ネットワークを実装する。
暗号化通信: データの転送時（In-transit）および保存時（At-rest）の暗号化を徹底する。

2.ストレージの暗号化（Server-Side Encryption: SSE）

Azure Storage 自体が提供する標準の保護機能。
仕様: FIPS 140-2準拠の 256ビットAES暗号化を使用。
自動有効化: すべてのストレージアカウントにてデフォルトで有効化されており、無効にすることはできない。アプリケーション側の変更も不要。
キー管理: 「Microsoft マネージドキー」または、ユーザー自身が管理する「カスタマーマネージドキー (CMK)」を選択可能。
二重暗号化（インフラストラクチャレベルの暗号化）: より高い安全性を求める場合、サービスレベルとインフラレベルで異なるアルゴリズム・キーを用いた二重暗号化を有効にできる。

3.ディスクレベルの暗号化（Azure Disk Encryption: ADE）

仮想マシンの OS およびデータディスクそのものを保護する機能。
技術: Windows の BitLocker、Linux の DM-Crypt を使用。
キー管理: Azure Key Vault と連携してキーやシークレットを管理する。

4.データベース（DBMS）レベルの暗号化

SAP HANA などのデータベースソフトウェア自体が持つ暗号化機能。
推奨事項: 保存されている SAP HANA データの暗号化には、SAP HANA ネイティブの暗号化テクノロジを使用することが強く推奨される。

5.暗号化の組み合わせと「禁止事項」（試験頻出）

セキュリティを強化しようとして暗号化を重ねすぎると、パフォーマンスに悪影響を及ぼす。試験では以下の判断が求められる。
DBMS暗号化 vs ADE:
併用は非推奨: パフォーマンス低下を招くため、Azure Disk Encryption と DBMS暗号化（HANA データの暗号化）を同じサーバーで組み合わせるべきではない。
SAP HANA の場合: HANA ネイティブの暗号化のみを使用するのがベストプラクティス。
暗号化とバックアップ:
暗号化を適用した環境では、バックアップとリカバリの手順がキー管理（Key Vault）に依存するため、キーのバックアップも不可欠となる。

6.可用性ゾーン (Availability Zones) とのトレードオフ

メリット: 稼働率（SLA）が 99.9% から 99.99% へと 0.04% 向上する。
コスト・性能への影響: ゾーン間の通信によるネットワーク待機時間（レイテンシ）がわずかに増加する。
ゾーンをまたぐネットワークトラフィックに対して追加料金が発生する。

試験対策

「HANA サーバーには ADE ではなく HANA ネイティブ暗号化を適用せよ」
「Azure Storage の SSE は無効化できない既定の保護である」
「ADE と DBMS 暗号化の併用はパフォーマンス上の理由で避けるべき

SQL Server TDE (Transparent Data Encryption) の適用指針

1.SAP でのサポートと適用タイミング

サポート状況: SQL Server TDE は SAP 環境で完全にサポートされている（SAP Note 1380493）。
推奨される手順: 暗号化の処理には時間がかかるため、「空のデータベースに対して先に TDE を適用」してからデータをインポートする手順が最も効率的である。
運用中の適用回避: SAP ワークロードが稼働している状態で TDE を適用（暗号化を開始）すると、パフォーマンスに悪影響を及ぼす。そのため、暗号化は SAP ワークロードが停止している状態で実施すべきアクティビティとして扱う。

2.暗号化処理の並列数とディスク構成

スレッド数の決まり方: TDE の暗号化スレッド数はユーザーが直接指定できず、主にデータファイルとログファイルが分散されているディスクボリュームの数に依存する。
設計の矛盾: Azure では「記憶域スペース」等でボリュームを 1 つにまとめる構成（ストライピング）が推奨されるが、ボリュームが少ないと暗号化スレッドも少なくなり、処理時間が長くなる。移行時に高速な暗号化が必要な場合は、一時的にボリューム数を増やすなどの検討が必要となる。
トランザクションログへの負荷: 暗号化の進行状況はログに記録されるため、処理中はログファイルに対しても中程度の負荷が発生する。

3.バックアップ圧縮との関係

SQL Server 2016 以降: 暗号化されたデータベースでも効率的にバックアップ圧縮を適用できる新機能が導入された。
旧バージョンの制約: 古い SQL Server では、暗号化後のデータベースはバックアップ圧縮が効きにくく、オンプレミスから Azure へのバックアップ転送時間が大幅に増えるリスクがある。この場合、「オンプレミスで暗号化してから移行」するか「Azure 移行後に暗号化」するかを慎重に判断する必要がある。

4.キー管理（Azure Key Vault）

コネクタの活用: SQL Server は Azure Key Vault と連携するためのコネクタを提供しており、TDE 証明書（暗号キー）を安全に中央管理することが可能。

5.Azureの柔軟性の活用

リソースの一時増強: Azure では CPU や I/O 性能を一時的に高く設定できる。暗号化処理の間だけ VM サイズを上げ（オーバープロビジョニング）、完了後に縮小することで、ダウンタイムや処理時間の短縮を図ることができる。

まとめ：試験対策

「TDE はデータが入る前（空の DB）に適用するのが最も効率的である」
「暗号化スレッド数はボリューム数に依存し、ユーザーは指定できない」
「暗号化キーの管理には Azure Key Vault を利用するのが推奨される」

SQL Server バッファプール拡張 (BPE) の設計指針

1.バッファプール拡張の仕組み

SQL Serverのバッファプール（データページを保持するメモリ領域）を、サーバーローカルの非揮発性ストレージ（SSD）を使用して拡張する機能。
第2レベルのキャッシュ: メモリ（第1レベル）から溢れたデータを、ディスク（第2レベル）に配置することで、標準ストレージ（HDD/SSD）へ読みに行くよりも高速に処理を継続できる。
配置場所: Azure VMにおいては、　一時ドライブ（D: ドライブ）　などのローカルSSDが使用される。

2.Azure における有効性と制約

Azure環境下では、以下の理由によりBPEのメリットが限定的となる。
Premium Storage 読み取りキャッシュとの重複: Azure Premium Storage の「読み取り専用キャッシュ」も、VMホストのローカルSSDを使用している。
BPEとディスクキャッシュはどちらも同じ物理リソースを競合するため、BPEを有効にしても劇的な性能向上は見込めない。
メモリ容量の増大:現在のAzure VM（Mシリーズ等）は数TB単位のメモリを提供可能。
SAPのワーキングセットがメインメモリに収まるように設計するのが基本であり、SSDに頼るBPEは不要となるケースがほとんどである。

3.SAP ワークロードでの推奨事項

原則非推奨: SAPアプリケーションの性能を最大化するには、データが物理メモリに収まっている状態が理想。BPEを使用した際の実績は芳しくなく、稀なケースを除き使用すべきではない。
検討すべき場面: メモリが極めて制限されている古いインスタンスや、特殊なコスト制約下での非運用環境に限られる。

試験対策

「BPEはローカルSSDを第2キャッシュとして使う機能だが、Azureではメリットが薄い」
「SAP環境では、BPEよりも十分なメモリ割り当てとAzureディスクキャッシュの活用を優先すべきである」
「BPEは一時的なD: ドライブを利用するため、再起動時のフォルダ再作成が必要になる」

Oracle on Azure：SAP ワークロードの設計指針

1.ファイル配置の基本原則

OS ディスクの活用（小規模構成時）:本来、OS ドライブへの Oracle 関連ファイルの配置は避けるべきだが、ディスク枚数制限のある小規模 VM では、
I/O 負荷の低いコンポーネントを OS ディスクに配置することが推奨される。
対象: ORACLE_HOME、stage、saptrace、saparch、sapbackup、sapcheck、sapreorg。
容量: 必要に応じて OS ディスクを最大 2048 GB まで拡張して対応する。
データとログの分離: Oracle データベースファイルと、オンライン再実行ログ（Redo Log）ファイルは、必ず物理的に異なるデータディスクに格納しなければならない。

2.tempfiles の配置（一時テーブルスペース）

SQL Server 同様、一時的なデータについては Azure VM の「一時ドライブ（D: ドライブ）」を活用する。
配置場所: Oracle の tempfiles は、D: ドライブ（非永続的ドライブ） に配置可能。
メリット: ローカル SSD による低レイテンシと高スループットを享受できる。
注意: D: ドライブは再起動時に初期化されるため、起動時に必要なディレクトリ構造を再作成する運用が必要。

3.ストレージの種類とファイルシステム

推奨ディスク: Azure Managed Disks（管理ディスク） および Premium SSD の使用が強く推奨される。
ファイルシステム: NTFS でフォーマットされたディスクのみがサポートされる（Windows 環境の場合）。
構成: 単一インスタンスの Oracle のみがサポート対象となる。

4.非サポート構成の排除（重要）

試験での「誤った設計」を見抜くためのポイント。
リモート共有の禁止: Azure Files やネットワーク共有ドライブ上に Oracle データベースファイルを配置することはサポートされていない。必ず VM に直接マウントされたブロックストレージ（Managed Disk）を使用すること。

試験対策

「Oracle のデータファイルとログファイルは、必ず別々のディスクに分離せよ」
「tempfiles は D: ドライブに配置して、I/O 性能を最大化せよ」
「Oracle ファイルを Azure Files やネットワークドライブに置くことは禁止されている」

SAP RISE on Azure：責任共有モデルと統合のポイント

SAP社が提供する、企業がオンプレミス環境からクラウド（SAP S/4HANA Cloud）へ円滑に移行し、
デジタルトランスフォーメーション（DX）を実現するための包括的なソリューションパッケージ。
一言で言えば、SAP社が提供する「クラウド移行のためのオールインワン・パッケージ」。

なぜ RISE が選ばれるのか（メリット）

運用のシンプル化: サーバーのパッチ当てやバックアップといった「守り」の運用をSAPに任せ、顧客はビジネスロジックに集中できる。
「持たない」経営: インフラ資産を自社で抱えず、サブスクリプション方式で利用できる。
最新技術の追随: SAPが直接管理するため、最新のアップデートやセキュリティ対策が適用されやすい。

1. サブスクリプションの分離（境界線）

最も重要なのは、　「Azure環境が論理的に2つに分かれている」　という点。
SAP マネージド・サブスクリプション（SAP RISE側）:
所有者: SAP社。
内容: SAP S/4HANA、DBMS、バックアップ、DR用リソース。
管理: SAPがリソースのデプロイ、パッチ適用、監視、バックアップ、SLA維持を行う。
サポート: 問題発生時は SAPサポート へ連絡する（Azureサポートは閲覧権限がないため対応不可）。
所有者: 顧客
内容: VNet（ハブ/スポーク）、Web Dispatcher、Active Directory、ファイル共有、Azure Data Factory、カスタムアプリ。
管理: 顧客自身がセキュリティグループ（NSG）、ルーティング、ファイアウォールを管理する。
サポート: 問題発生時は Azureサポート へ連絡する。

2.ネットワーク統合と接続の責任

両者のサブスクリプションは、通常 VNet ピアリング または VPN/ExpressRoute で統合される。
SAPの責任: SAP側サブスクリプション内のVNet、NSG、ルーティング設定。
顧客の責任: 顧客側VNetの設計、IPアドレス空間（重複回避）、オンプレミスとの接続、DNS設定。
連携のポイント: ネットワーク統合を有効にするためには、顧客が初期要求をSAP RISEに対して行い、SAP側で接続設定（ピアリング承諾等）を実施する必要がある。

3.アーキテクチャの決定権

SAPの独占的権利: SAP RISE環境で使用されるVMサイズ、ストレージの種類、可用性構成（AS/AZ）の詳細は、SAPがSLAを遵守するために決定・検証・展開する。
ベストプラクティスの適用: MicrosoftとSAPは共同でRISE専用の最適化アーキテクチャを構築しているが、その詳細はSAPの知的財産（IP）であり、外部には完全公開されない場合がある。
カスタマイズ: 顧客の固有要件（特定のインターフェース接続など）については、SAPと個別に調整して構成をカスタマイズする。

4.ドキュメント化の推奨事項

トラブルシューティングを迅速化するため、以下の転送ポイントと所有権を明文化しておくことが不可欠である。
IPアドレス空間（サブネット分割）
ファイアウォールルールとルーティング（UDR）
ファイル共有のアクセス権
接続インターフェース（API, RFC, OData等）

5.試験対策

試験シナリオで「RISE環境のVMがダウンした」「RISE上のDBバックアップが失敗した」という状況が出た場合、正解は 「SAPサポートへチケットを作成する」 となる。
「自社のAzureポータルからリソースを確認する」という選択肢は、SAP側のリソースが見えないため誤り。

「RISE側のリソースはSAPのサブスクリプションにあり、管理はSAPが行う」
「ネットワークの疎通性は、顧客側のNSGやルート設定に依存する部分が大きい」
「Azureサポートが対応できるのは、顧客自身のサブスクリプション内のリソースのみである」

SAP RISE：仮想ネットワーク（VNet）ピアリングによる統合

1.ピアリングが推奨される理由

SAP RISE ランドスケープ（SAP所有サブスクリプション）と顧客の Azure 環境（顧客所有サブスクリプション）を接続する際、VNet ピアリングは最もパフォーマンスが高く、推奨される方法である。
低レイテンシ・高スループット: トラフィックは Microsoft のバックボーンネットワーク内のみを通り、インターネットを経由しない。
シームレスな通信: 接続された 2 つの VNet は、IP レベルで直接通信可能になり、あたかも 1 つのネットワークのように動作する。
コストと複雑さの回避: 新たに VPN ゲートウェイや ExpressRoute を SAP RISE 側に用意する必要がなく、既存の顧客ハブ（Hub VNet）を再利用できる。

2.テナント間ピアリングの仕組み

SAP RISE はSAP社の Azure テナントで実行されているため、　「異なるテナント間（Cross-Tenant）の VNet ピアリング」　を構成することになる。
構成手順:
SAP から提供される SAP 側 VNet のリソース ID を取得する。
顧客側の Azure 環境で、SAP 側のリソース ID を宛先としてピアリングを設定する。
SAP 側でそのピアリング申請を承認する（相互承認が必要）。
ユーザー管理: 設定には相手側のテナントのユーザーを「ゲストユーザー」として招待するプロセスが含まれる場合がある。詳細は SAP 担当者との連携が不可欠である。

3.ハブ・アンド・スポーク構成との統合

一般的に、顧客側は「ハブ・アンド・スポーク」アーキテクチャを採用しており、SAP RISE はその「ハブ」に接続される 1 つの「スポーク」として扱われる。
通信経路: SAP RISE（スポーク） ↔ 顧客ハブ VNet ↔ 顧客の他スポーク（AD, Appなど）やオンプレミス。
セキュリティ: 両方の VNet で ネットワークセキュリティグループ (NSG) を適切に設定し、SAP 通信に必要なポート（32xx, 33xx, 36xx, 443 など）のみを許可する。

4.グローバル VNet ピアリングの活用

同一リージョン: 待機時間とコストの面で最も有利。
グローバル（別リージョン）: 異なるリージョン間でもピアリングは可能。全世界展開する S/4HANA の集中管理などで利用されるが、リージョン間通信費用（データ転送料）が発生する点に注意が必要。

5.運用上の留意点

IP アドレスの重複禁止: ピアリングする双方の VNet で、アドレス空間が重複していると接続できない。設計段階での厳密な管理が求められる。
トランジット設定: ハブ VNet を介してオンプレミスと通信する場合、ゲートウェイの転送（Gateway Transit）設定を適切に行う必要がある。

SAP RISE：VPN（VNet 間）接続による統合

1. VPN（VNet 間）接続の概要

VNet ピアリングの代替手段として、SAP RISE の VNet と顧客のハブ VNet のそれぞれに VPN ゲートウェイ を配置し、それらの間に暗号化されたトンネル（VNet 間接続）を構築する手法である。
接続形態: SAP RISE 側の VPN ゲートウェイと、顧客側の VPN ゲートウェイを直接接続する。
リージョン柔軟性: ピアリングと同様、異なる Azure リージョン間での接続も可能である。

2.VPN 接続を選択するメリット

推奨されるのは VNet ピアリングであるが、あえて VPN 接続を採用するケースには以下の利点がある。
管理の簡素化: 異なるテナント間での複雑なピアリング承認プロセスを避け、ゲートウェイ同士の接続設定で完結できる。
明確なエントリポイント: VPN ゲートウェイが顧客ネットワークへの唯一の入り口となるため、中央のネットワークチームによる監視やセキュリティ制御が容易になる。
限定的なトラフィック: 特定のセグメント間のみを接続し、ネットワーク全体を透過的に見せない構成に適している。

3.設計上の制限と留意点

スループットの制約: VNet ピアリングは Azure バックボーンの広帯域を利用できるが、VPN は　ゲートウェイの SKU（性能レベル）　によって帯域幅が制限される。
大規模なデータ転送が発生する SAP 環境ではボトルネックになりやすい。
高可用性: 接続の信頼性を確保するため、ゾーン冗長 (Zone-redundant) 仮想ネットワークゲートウェイ の使用が不可欠である。
セキュリティ: ピアリング構成と同様に、双方の VNet で ネットワークセキュリティグループ (NSG) を使用し、SAP NetWeaver や S/4HANA に必要なポートを制限する必要がある。

4.運用と設定

設定の調整: VPN のプロトコル、事前共有キー (PSK)、暗号化アルゴリズムなどの詳細なパラメータについては、SAP 担当者と緊密に連携して決定する必要がある。

試験対策

「VPN ゲートウェイ間の接続は、ピアリングよりもスループットが制限されることに注意する」
「可用性を高めるためには、必ずゾーン冗長 SKU のゲートウェイを選択すべきである」
「ネットワーク管理の一元化や複雑なピアリングを避けたい場合に、VPN 接続は有効な選択肢となる」

オンプレミスから SAP RISE への接続設計

1.推奨される接続アーキテクチャ

既存の Azure 環境がある場合、オンプレミスと SAP RISE を接続する最も一般的かつ推奨される方法は、　「顧客のハブ VNet を介した接続」　である。
ハブ・アンド・スポークの活用: 顧客が管理する「ハブ VNet」に既存の ExpressRoute (ER) または VPN ゲートウェイを配置し、SAP RISE VNet（スポーク）をこれにピアリングで接続する。
メリット: 既存のネットワーク資産（ER 回線やゲートウェイ）を有効活用できる。
顧客側の中央ポリシーやセキュリティルールを SAP RISE ワークロードにも一貫して適用できる。
接続コストの重複を避けられる。

2.リモートゲートウェイ転送 (Gateway Transit)

ピアリング経由でオンプレミスと SAP RISE を通信させるためには、VNet ピアリングの設定で「ゲートウェイ転送」を有効にする必要がある。
仕組み: ハブ VNet 側のピアリング設定で「ゲートウェイ転送を許可する」、SAP RISE VNet 側の設定で　「リモートゲートウェイを使用する」　を有効にする。
制約（重要）: 1つの VNet は「ローカルゲートウェイ」か「リモートゲートウェイ」のいずれか一方しか持てない。
顧客のハブにあるリモートゲートウェイを使用する場合、SAP RISE VNet 内に独自の VPN/ER ゲートウェイを設置することはできない。

3.SAP RISE 直接接続（専用回線）

Azure 接続を介さず、SAP RISE ネットワークへ直接オンプレミスから ExpressRoute や VPN を引く構成も存在する。
注意点: この専用接続は SAP マネージド VNet へのアクセスに限定される。この接続を経由して顧客自身の Azure VNet（自社管理のスポーク等）にアクセスすることはできないため、構成の柔軟性に欠ける。

4.Azure Virtual WAN との統合

最新の広域ネットワーク基盤である Azure Virtual WAN も、SAP RISE との統合に対応している。
構成: SAP RISE VNet を Virtual WAN ハブに接続された一つの「スポーク」として扱う。
管理: 顧客は自身のサブスクリプションで Virtual WAN ハブを管理し、SAP RISE へのルーティングやオンプレミス接続を完全にコントロールできる。

まとめ：試験対策

「SAP RISE は、顧客ハブ VNet に接続された一つのスポークとして設計せよ」
「オンプレミス通信には、ピアリングのリモートゲートウェイ転送機能を活用せよ」
「VNet はローカルとリモートの両方のゲートウェイを同時には持てない」
「自社管理 VNet へのアクセスが必要な場合は、SAP RISE 直結の ER 回線ではなく、ハブ経由の構成を選択せよ」

SAP RISE：インターネット接続と外部連携の設計

1.通信の基本原則

SAP RISE の仮想ネットワーク（VNet）は、既定ではプライベート IP アドレスのみを使用する。インターネットとの通信（イングレス・エグレス双方）を有効にするには、SAP 担当者との調整が必須である。
イングレス（外部から SAP への接続）: SAP Fiori 等のアクセス用。
エグレス（SAP から外部への接続）: 外部 API やインターフェースとの連携用。

※SAP Fiori（フィオリ）は、SAP S/4HANAなどのSAPアプリケーション向けのモダンな設計システム（UX）。
Webブラウザベースの直感的なUIを採用しており、デスクトップ、タブレット、モバイルなど、あらゆるデバイスで一貫した操作性を実現し、ビジネスプロセスの生産性と効率を高める。

2.SAP RISE 側でのインターネット管理

SAP RISE 側でインターネット接続を有効にした場合、その通信は SAP マネージドの Azure リソースによって保護・管理される。
使用される技術: * Application Gateway: Web Application Firewall (WAF) を備え、HTTPS 経由の受信を保護する。
NSG / ASG: ネットワークおよびアプリケーションレベルのフィルタリングを実施。
プロキシサーバー: 送信通信の制御に使用される。
分離の原則: SAP RISE のインターネット通信は、SAP RISE 側の VNet 内で完結する。顧客が所有する VNet を経由して SAP RISE のインターネット通信を行うことはできない。 同様に、顧客独自のワークロードは、顧客側のインターネット出口（Azure Firewall 等）を使用する必要がある。

3.SAP BTP (Business Technology Platform) との接続

SAP BTP はパブリックエンドポイントを持つことが多いが、セキュリティを高めるための接続オプションが存在する。
送信アクセス: 顧客側の VM やサービスから BTP にアクセスする場合、顧客 VNet 側のファイアウォールや NAT Gateway を経由する。
SAP Private Link Service (推奨): インターネットを経由せず、Azure のプライベートネットワーク内で BTP サービスと顧客 VNet を接続する手法。
これにより、データの露出リスクを最小限に抑えつつ、低遅延な通信が可能になる。
SAP Cloud Connector: オンプレミスや Azure 上の SAP システムと BTP を安全に接続するために、顧客側の VM 上にインストールして運用する。

4.通信ポートとプロトコルの公開

SAP RISE へのアクセスは、SAP によって明示的に開かれたポートを通じてのみ可能となる。
プライベート接続: RFC、JDBC/ODBC、HTTPS プロトコルが使用可能。
パブリック接続: Application Gateway によって公開されたグローバル IP 経由の HTTPS 通信が一般的。
注意: ポートの開放状況や WAF の設定については、SAP ECS/RISE の担当者と詳細を詰める必要がある。

5.責任の境界点（試験頻出）

SAP RISE ワークロード: インターネット出口の管理・保護は SAP の責任。
顧客独自ワークロード: インターネット出口（Azure Firewall, NAT Gateway 等）の管理・保護は 顧客の責任。
SAP BTP への接続管理: BTP 側の設定は SAP だが、そこへアクセスする顧客環境側のルート管理は 顧客の責任。

試験対策

「SAP RISE のインターネット接続は、顧客 VNet を経由せず SAP 管理リソースで完結する」
「BTP との通信をセキュアにするには、Private Link Service の利用を検討せよ」
「Cloud Connector の運用は、顧客側のサブスクリプションにある VM で行う」

SAP on Azure における認証・承認・アクセス制御

1. Active Directory (AD) の拡張とデプロイ

Azure 上に SAP システムを構築する場合、多くの場合において従来の Windows Server Active Directory ドメインサービス（AD DS）が必要となる。
オンプレミス AD の拡張: Azure VNet 内に VM を立て、ドメインコントローラー（DC）をデプロイする。これをオンプレミスの DC とレプリケーションさせることで、認証トラフィックを Azure 内で完結させ、レイテンシを最小化する。
高可用性（HA）: DC 自体の障害に備え、少なくとも 2 台の DC を 同じ可用性セット（または可用性ゾーン） に配置し、可用性を確保しなければならない。
統合 DNS: AD 統合 DNS を使用することで、SAP システム間の名前解決を安定させる。

2.Microsoft Entra ID と 従来の AD の違い

Microsoft Entra ID はクラウドベースの ID サービスであり、従来の AD とは役割が異なる。
Microsoft Entra ID: Azure リソースの管理（プロビジョニング）や SaaS アプリ（BTP, S/4HANA Cloud 等）との連携、SSO（シングルサインオン）の基盤として機能する。
従来の AD (Windows Server AD): 完全な AD スキーマやグループポリシー（GPO）、Kerberos 認証を必要とする多くの SAP サーバーソフトウェア、および LDAP 連携に必須である。
連携: Microsoft Entra Connect を使用して、オンプレミス AD のユーザー情報を Entra ID へ同期するのが標準的な構成である。

3.シングルサインオン (SSO) の実現

Microsoft Entra ID をアイデンティティプロバイダー（IdP）として活用し、ユーザーの利便性とセキュリティを向上させる。
対象アプリ: S/4HANA Fiori Launchpad、SAP NetWeaver、SAP HANA 等。
SAP BTP との統合: SAP Business Technology Platform (BTP) 上のサービスに対しても、Entra ID を経由した SSO が可能。
プロビジョニング: SAP HANA 等では、ジャストインタイム (JIT) ユーザープロビジョニング（初回アクセス時に自動でユーザーを作成する機能）もサポートされる。

4.RBAC による最小特権原則

Azure リソースへのアクセスには RBAC を適用する。
ユーザー、グループ、サービスプリンシパルに対して、必要な範囲（サブスクリプション、リソースグループ、リソース）で最小限の権限（共同作成者、閲覧者、仮想マシン作成者等）を割り当てる。

5.試験対策

「認証の低遅延化のため、SAP サーバーと同じ VNet 内にドメインコントローラーを配置せよ」
「DC は単一障害点にならないよう、2 台以上を可用性セットに配置せよ」
「Azure リソースの管理には RBAC を、アプリのログインには SSO (Entra ID) を使い分けよ」

SAP Cloud Identity Authentication (IAS) と Microsoft Entra ID の統合

1.ID 統合の全体像（プロキシ構成）

Microsoft Entra ID を中心としたシングルサインオン（SSO）を SAP 環境に拡張する場合、IAS を 「プロキシ（仲介役）」 として配置する構成が一般的である。
主要 ID プロバイダー (Primary IdP): Microsoft Entra ID
ユーザー認証の本体。パスワード入力や多要素認証（MFA）はここで行われる。
プロキシ ID プロバイダー (Proxy IdP): SAP Cloud Identity Authentication (IAS)
SAP アプリケーション（BTP, S/4HANA 等）側から見ると認証の窓口となるが、実際には認証要求を Microsoft Entra ID へ転送する。

2.統合のメリット

運用の簡素化: Microsoft Entra Marketplace にある「SAP Cloud Platform Identity Authentication」アプリを使用することで、複雑な SAML アサーションやカスタムクレームを個別に定義することなく、容易に信頼関係を構築できる。
中央管理: ユーザーは Microsoft Entra ID のアカウント 1 つで、Azure 上のサービスと SAP 上のサービスの両方にアクセス可能となる。

3.認証と認可（承認）の分離（重要）

この構成において、アクセス制御の責任範囲は以下のように分かれる。
認証 (Authentication): Microsoft Entra ID が担当。「そのユーザーが誰であるか」を特定する。
認可 (Authorization): SAP Cloud Identity Authentication (IAS) が担当。「そのユーザーが特定の SAP アプリやサービスにアクセスしてよいか」という詳細な権限管理は、IAS 側の管理コンソールで行う。

4.通信プロトコルと制約

SAML 2.0: 一般的に Web ブラウザベースのシングルサインオン（Web SSO）に使用される。
サポート状況: Web 画面を通じた SSO は検証済みで広く利用されているが、アプリ間（App-to-App）や API 間（API-to-API）の通信フローについては、各シナリオに応じた個別の検証が必要となる場合がある。

※SAML（Security Assertion Markup Language）は、異なるインターネットドメイン間やシステム間で、XMLベースの規格を用いてユーザーの認証・属性情報（アサーション）を安全にやり取りする標準規格。主にSSO（シングルサインオン）を実現し、IdP（認証基盤）とSP（クラウドサービス）の信頼関係に基づいてセキュアなログインを提供します。

試験対策

「Microsoft Entra ID を主要 IdP とし、SAP IAS をプロキシ IdP として構成せよ」
「SAP アプリへの具体的なアクセス承認（認可）は、IAS 側のコンソールで管理せよ」
「Microsoft Entra Marketplace のテンプレートを活用して、SAML 構成の手間を削減せよ」

Microsoft Entra ID と SAP IAS の SSO 統合

1.統合の全体像と利点

Microsoft Entra ID を 主要 ID プロバイダー (IdP) とし、SAP IAS を プロキシ IdP として構成することで、一元的な ID 管理が可能になる。
一元管理: Azure ポータルからユーザーのアクセス権を一括制御できる。
ユーザー体験の向上: ユーザーは Microsoft アカウントで SAP アプリケーションへ自動サインイン（SSO）が可能となる。
プロキシ構成: SAP 側の各アプリケーション（BTP, S/4HANA 等）個別に設定するのではなく、IAS を経由させることで管理を簡素化する。

2.構成の主要ステップ

① Azure 側：アプリケーションの追加と設定
ギャラリーからの追加: Azure ポータルの「エンタープライズ アプリケーション」から、SAP Cloud Platform Identity Authentication を検索し、リストに追加する。
SAML 構成:
識別子（エンティティ ID）: SAP IAS テナントの一意の ID を入力。
応答 URL: SAML アサーションを受け取る URL。
ユーザー属性とクレーム: email や givenname など、SAP 側が必要とする属性が正しくマッピングされているか確認する。

② SAP IAS 側：コーポレート IdP の設定
Identity Provider の作成: IAS 管理コンソールで「Corporate Identity Providers」を選択し、Microsoft Entra ID を追加する。
SAML 2.0 設定: Azure からダウンロードした メタデータ XML ファイル をアップロードする。これにより、エンティティ ID や SSO エンドポイント URL が自動構成される。
署名証明書: SAML メッセージの検証に使用する証明書を登録する。

3.ID フェデレーション (Identity Federation) の選択

IAS には、ユーザー情報の持ち方に関して重要なオプションがある。
Identity Federation（既定：無効）:
無効の場合: IAS 側のユーザーストアにユーザーが存在しなくても、Microsoft Entra ID で認証されれば SSO が成功する。管理が最も容易である。
有効にした場合: Microsoft Entra ID で認証された後、同じユーザーが IAS 側のユーザーストアにも存在しているかを照合する。ユーザーが IAS にインポートされていない場合、アクセスは拒否される。より厳格なアクセス制御が必要な場合に利用する。

4.ユーザーの割り当てとロール

割り当て: Azure ポータル上で、どのユーザーやグループに SAP IAS へのアクセスを許可するかを定義する。
ロールの受け渡し: SAML アサーション内にユーザーのロール情報を含めることができ、SAP アプリケーション側での権限判断に利用される。

試験対策

「Microsoft Entra ID は SAML 2.0 モードを使用して IAS と信頼関係を構築せよ」
「設定の簡素化のため、Azure のメタデータ XML を IAS にアップロードして構成せよ」
「ユーザー情報の二重管理を避けるなら、IAS の Identity Federation オプションは無効のまま運用せよ」

SAP Fiori と Microsoft Entra ID の SSO 統合

1.事前準備と SAP 側の有効化

まず、SAP システムが SAML 通信を受け入れられる状態にする必要がある。
通信の確認: SMICM で HTTP/HTTPS ポートが正しく割り当てられているか確認する。
セッション管理: SICF_SESSIONS で HTTP セキュリティセッション管理を有効化し、必要に応じてプロファイルパラメータを調整後に再起動する。
サービスの有効化: SICF で SAML 2.0 関連のパス（/sap/public/bc/sec/saml2 など）をすべて有効にする。

2.SAP 側：ローカルプロバイダーの構成

トランザクションコード SAML2 を実行し、ブラウザベースの管理画面で設定を行う。
プロバイダー名の命名規約: デフォルトの SID-client 形式ではなく、Microsoft Entra ID が認識しやすい https:// 形式に変更して保存する。
メタデータの抽出: 「Local Provider」タブからメタデータ XML をダウンロードする。これが Azure 側に SAP の情報を伝える「名刺」となる。

3.Azure 側：SAML 設定と属性マッピング

Azure ポータルの「SAP Fiori」エンタープライズアプリケーションで設定を進める。
メタデータのアップロード: SAP からダウンロードした XML をアップロードすることで、「識別子」や「応答 URL」が自動補完される。
サインオン URL: ユーザーが最初にアクセスする Fiori Launchpad の URL（https://[instance]）を入力する。
属性の変換: SAP ユーザー名がメールアドレスのプレフィックス（例：[e-mail] の user01）と一致する場合、Azure 側のクレーム設定で ExtractMailPrefix() 関数を使用して値を整形する。

4.SAP 側：信頼できるプロバイダー（Azure）の登録

Azure から「フェデレーション メタデータ XML」をダウンロードし、再び SAP の SAML2 画面に戻る。
信頼の構築: 「Trusted Providers」タブから Azure のメタデータをアップロードし、エイリアスを付与する。
署名アルゴリズム: セキュリティ確保のため、必ず SHA-256 を選択する。
エンドポイント設定: SSO には HTTP POST、シングルログアウト（SLO）には HTTP Redirect を選択するのが標準的である。

5.ID フェデレーションの重要設定

Microsoft Entra ID のユーザーと SAP のユーザー（SU01）をどう紐付けるかを決定する。
マッピングモード:
ユーザー ID 直接指定: Azure から送る NameID を SAP のユーザー ID と直接照合する。
メールアドレス照合: SU01 に登録されたメールアドレスと Azure 側のメール属性を照合する。この場合、SAP 側の各ユーザーマスターに正しいメールアドレスの登録が必須となる。

試験対策

「SAML2 設定を開始する前に、SICF で関連サービスを必ず有効化せよ」
「Azure へのメタデータアップロードにより、手動入力による誤設定を防止せよ」
「SSO が失敗する場合は、まず SAP 側の NameID マッピング設定と Azure のクレーム内容の不一致を疑え」

SAP HANA と Microsoft Entra ID の SSO 統合

1.統合の概要とメリット

SAP HANA（特に HANA 2.0 XSA）と Microsoft Entra ID を連携させることで、企業アカウントによる安全でシームレスなアクセスが可能になる。
セキュリティ向上: Microsoft Entra ID でアクセス権を中央管理し、多要素認証（MFA）等の条件付きアクセスを適用できる。
利便性: ユーザーは HANA 専用のパスワードを覚える必要がなく、一度のログインでアクセスが可能。
運用効率: ジャストインタイム (JIT) プロビジョニングにより、初回ログイン時に自動的に HANA ユーザーを作成できる。

2.Microsoft Entra ID 側の構成ポイント

Azure ポータルの「SAP HANA」エンタープライズアプリケーションで設定を行う。
識別子と応答 URL: 識別子（HA100 等）と、HANA インスタンス固有の SAML ログイン URL（/sap/hana/xs/saml/login.xscfunc）を正確に設定する。
ユーザー属性のマッピング: SAP HANA は特定の NameID 形式を必要とする。
属性変換関数 ExtractMailPrefix() を使用し、メールアドレスのドメイン部分を除いた値を HANA ユーザー名として渡す構成が一般的である。
メタデータの取得: 設定完了後、HANA 側にインポートするための「フェデレーション メタデータ XML」をダウンロードする。

3.SAP HANA 側の構成（XSA Web コンソール）

HANA の XSA 管理画面にて、Microsoft Entra ID を「信頼できる ID プロバイダー (IdP)」として登録する。
メタデータのインポート: Azure から取得した XML を貼り付けることで、エンティティ ID や SSO URL が自動的に抽出される。
IdP の命名: 他の IdP と区別できる一意の名前を付与する。
assertion_timeout の調整: 通信遅延によるエラーを防ぐため、HANA Studio もしくは Web IDE を使用し、assertion_timeout をデフォルトの 10 秒から 120 秒 程度に引き上げることが推奨される。

4.ユーザープロビジョニングの設計

HANA におけるユーザー作成には 2つの方式。
ジャストインタイム (JIT) プロビジョニング:ユーザーが初めてログインした際に、SAML アサーションの情報に基づいて HANA ユーザーが自動作成される。
大規模な環境で個別のユーザー作成を省きたい場合に有効である。
手動プロビジョニング (HANA Studio):管理者が事前に DB ユーザーを作成し、SAML 認証を有効化する。
外部 ID のマッピング: 「Any（任意）」チェックボックスをオンにしない場合、HANA ユーザー名と Entra ID の NameID（プレフィックス）が完全に一致している必要がある。

5.権限（ロール）の割り当て

SSO 自体は認証（本人確認）のみを行うため、ログイン後に何ができるかは HANA 側での「認可」に依存する。
JIT プロビジョニングを使用する場合でも、あらかじめ適切な HANA ロール をユーザーに割り当てる設定が必要である。

試験対策

「HANA XSA 管理画面で Azure のメタデータをインポートし、信頼関係を構築せよ」
「認証タイムアウトエラーを避けるため、assertion_timeout を 120 秒に拡張せよ」
「JIT プロビジョニングを活用し、ユーザー作成運用の自動化を検討せよ」

#SAP NetWeaver と Microsoft Entra ID の SSO 統合

1.SAP システムの基盤準備

認証を開始する前に、ABAP サーバー側で Web 通信とセッション管理が正しく設定されている必要がある。
ICM 設定: SMICM で HTTP/HTTPS ポートがアクティブであることを確認する。
セッション管理: SICF_SESSIONS にて、該当するクライアントの HTTP セキュリティセッションを有効化する。
SICF サービスの有効化: SAML 通信に必須となる /sap/public/bc/sec/saml2 などのパスを有効化する。

※ICM　Internet Communication Managerの略称
　SAPアプリケーションサーバー（AS ABAP/Java）において、外部ネットワーク（インターネット）と SAP システム間の通信を仲介するコンポーネント。
※SMICM　SAPシステムの通信の要である**ICM（Internet Communication Manager）**を管理・監視するためのトランザクションコード。
※SICF　SAP Internet Communication Frameworkの略称
　SAPシステムが HTTP、HTTPS、SMTP などのインターネット標準プロトコルを介して通信するための「サービス（エンドポイント）」を管理するツール。

2.SAP 側：ローカルプロバイダーとメタデータ

SAML2 トランザクションを実行し、SAP システム自身の情報を定義する。
プロバイダー名の修正: 既定の SID-Client 形式から、https:// 形式（例: https://T01122）に変更する。これは Microsoft Entra ID が要求する URI 形式に合わせるためである。
メタデータの生成: 設定後、SAP 側のメタデータ XML をダウンロードする。

3.Azure 側：SAML 構成と属性変換

Azure ポータルで SAP NetWeaver アプリケーションを構成する。
メタデータのアップロード: SAP から取得した XML をアップロードし、「識別子」と「応答 URL」を自動入力させる。
ユーザー属性の整形: ExtractMailPrefix() 関数を使用し、user.userprincipalname（例: [e-mail]）から sato の部分だけを抽出し、これを SAP ユーザー ID としてマッピングするよう設定する。
Azure メタデータの取得: SAP 側に登録するための「フェデレーション メタデータ XML」をダウンロードする。

4.SAP側：信頼できるプロバイダーの登録と有効化

再び SAP の SAML2 画面に戻り、Entra ID との信頼関係を完結させる。
IdP の追加: Azure の XML をアップロードし、署名アルゴリズムに SHA-256 を選択する。
エンドポイント構成: SSO には HTTP POST、シングルログアウトには HTTP Redirect を指定する。
ID フェデレーション: NameID フォーマットとして Unspecified（未指定） を追加する。ここで、Azure から送られてくる値（NameID）を SAP のどのフィールド（ユーザー ID もしくはメールアドレス）と照合するかを決定する。
有効化: 設定完了後、必ずプロバイダーを 「有効化 (Enable)」 する。これを行わないと SSO は動作しない。

5.ID マッピングのシナリオ

シナリオ A（ユーザー ID マッピング）: Azure の NameID が SAP ユーザー名（SU01）と一致する場合。管理がシンプルである。
シナリオ B（メールアドレスマッピング）: SU01 のアドレスと Azure のメール属性を照合する場合。大規模組織でユーザー名の命名規則が異なる場合に有効である。

試験対策

「プロバイダー名は Microsoft Entra ID の要件に合わせ https:// 形式で定義せよ」
「SAML2 設定後は、必ずプロバイダーを有効化（Enable）する手順を忘れるな」
「SSO トラブル時は SICF サービスの有効化状態と NameID フォーマットの不一致を確認せよ」

Active Directory と SAP SSO (Kerberos-SPNEGO) の統合

1. SNC (Secure Network Communication) の役割

SNC は、SAP NetWeaver アプリケーションサーバーと SAP GUI などの外部クライアント間の通信を保護するレイヤーである。
認証の仕組み: AD が発行する Kerberos トークンを SNC インターフェース経由で SAP が受け取ることで、パスワード入力なしのログインを実現する。
暗号化: 認証だけでなく、通信経路全体の暗号化も提供する。

2.インフラ・サーバー側の設定手順

モダンな NetWeaver（7.31以降）では SNCWIZARD や SPNEGO トランザクションで自動設定が可能だが、基本原理は以下の通りである。
サービスアカウントの作成: AD 上に SAP システム用のユーザー（サービスアカウント）を作成する。パスワードは無期限に設定するのが通例である。
SPN (Service Principal Name) の登録: SETSPN コマンドを使用し、作成した AD ユーザーと SAP サービスを紐付ける。
暗号ライブラリの準備: SAP システムに CommonCryptoLib をインストールし、環境変数 SECUDIR でライブラリのパスを指定する。
プロファイルパラメータの変更: snc/enable = 1 などのパラメータを設定し、SAP インスタンスを再起動して SNC を有効化する。

3.ユーザーマッピング (SU01)

AD 上のユーザーと SAP 内部のユーザーを紐付ける作業が必要である。
SNC 名の登録: トランザクション SU01 の「SNC」タブにて、ユーザーごとに p:CN=UserPrincipalName@domain（例: p:CN=[e-mail]）という形式で SNC 名を入力する。

4.クライアント側（SAP GUI）の設定

ユーザーの PC 側でも SNC 通信を許可する設定を行う。
ソフトウェアの導入: 必要に応じて SAP Secure Login Client などのソフトウェアをインストールする。
接続設定: SAP Logon の接続プロパティにある「ネットワーク」タブで「セキュアネットワークコミュニケーション」を有効にし、サーバー側の SNC 名（例: p:CN=SAPServiceSID@domain）を入力する。

5.SPNEGO (Web 認証) との併用

Kerberos は SAP GUI だけでなく、HTTP 通信（SPNEGO）にも利用できる。
仕組み: ブラウザが AD から取得した Kerberos チケットを HTTP ヘッダーに含めて SAP (ICM) に送ることで、ポータルや Fiori への Web ログインも SSO 化が可能となる。

試験対策

「SAP GUI の SSO には、AD と連携した SNC (Kerberos) 構成が必須である」
「SECUDIR 環境変数は、暗号化チケットや PSE ファイルの保管場所を定義する重要な変数である」
「SPN の登録漏れや SU01 での SNC 名マッピング不備は、SSO 失敗の主要原因となる」

Azure 上の AD DS ドメインコントローラー（DC）

1.Azure へのデプロイが必要な理由

クラウド移行において、単に Microsoft Entra ID（旧 Azure AD）があれば済むわけではない。SAP ワークロードのように、レガシーな認証プロトコルや深いディレクトリ統合を必要とする場合、Azure VM 上に DC を立てる必要がある。
アプリケーション認証の維持: Kerberos、LDAP、SMB などのプロトコルを必要とする SAP アプリケーションやサードパーティ製ツールに対し、オンプレミスと同等の認証環境を提供する。
高可用性とディザスタリカバリ (DR): オンプレミスの DC 障害時や、オンプレミスと Azure 間のネットワーク切断時でも、Azure 内の SAP インスタンスが認証を継続できるようにする。
同期の回復力: Microsoft Entra Connect（ディレクトリ同期ツール）を Azure VM 上の DC と連携させることで、クラウド側での ID 管理の可用性を高める。

2.認証プロトコルとネットワーク特性

AD DS の主要なプロトコルは、インターネット経由の通信よりも、安定したプライベートネットワーク内での利用を前提としている。
LDAP: ディレクトリ情報の検索に使用。
Kerberos: ユーザーやサービスの認証に使用。SAP SSO（SNC）の基盤となる。
SMB: グループポリシーの適用やファイル共有に使用。

3.SAP on Azure における構成の鉄則

試験や実務で問われる「ベストプラクティス」は以下の通りである。
近接配置: 認証時のネットワーク遅延（レイテンシ）を抑えるため、SAP サーバーと同じ VNet（またはピアリングされたハブ VNet）内に DC を配置する。
可用性セット/ゾーンの利用: 単一の VM 障害で認証が止まらないよう、最低 2 台の DC を可用性セットまたは可用性ゾーンに分散して配置する。
IP アドレスの固定: DC のプライベート IP アドレスは、Azure ポータル側で「静的（Static）」に設定する必要がある。

試験対策

「SAP のシングルサインオン（SNC/Kerberos）を実現するには、Azure VM 上の AD DS が不可欠である」
「オンプレミスとの VPN/ExpressRoute が切断された場合に備え、Azure 側に DC を複製しておくべきである」
「DC の配置は、認証トラフィックの局所化と高可用性を最優先に設計せよ」

#AD DS on Azure Virtual Machines の主要シナリオ

シナリオ 1：Azure 完結型（新しいフォレスト）

オンプレミスとの接続を持たず、Azure内にのみAD DSを展開する構成。
用途: クラウドネイティブなアプリケーションや、オンプレミスから完全に独立した開発・テスト環境。
特徴: すべてのDCがAzure内に配置され、新しいフォレストが作成される。Kerberos認証やグループポリシーが利用可能だが、オンプレミスのIDとは統合されない。

フォレストの構成要素と階層

フォレストを理解するには、以下の 3 つの階層をセットで押さえる必要がある。

1. ドメイン（木 / Tree）
   ユーザー、コンピュータ、グループなどを管理する最小の単位。
   例：tokyo.example.com

2. ツリー（並んだ木）
   同じ名前（共通のルートドメイン）を持つドメインの集まり。
   例：example.com の下に sales.example.com と it.example.com がある状態。

3. フォレスト（森 / Forest）
   1 つ以上の「ツリー」をまとめたもの。
   異なるドメイン名（例：company-a.com と company-b.com）を持っていても、同じフォレスト内であれば、互いに信頼関係（信頼）を結び、リソースを共有できる。

フォレストの主な特徴
セキュリティの最終境界:
フォレストの外側とは、明示的に設定しない限り通信や認証は行われない。つまり、「フォレストが分かれている ＝ 完全に別組織」という扱いになる。

共通のスキーマ:
フォレスト内のすべてのドメインは、同じ「スキーマ（データの設計図。例えば「ユーザー」というデータにはどんな項目があるか、という定義）」を共有する。

双方向の信頼関係:
同じフォレスト内のドメイン同士は、自動的に「双方向の信頼」で結ばれる。これにより、A ドメインのユーザーが B ドメインのプリンタを使う、といったことが容易になる。
なぜ Azure や SAP の話で出てくるのか？
Azure VM に AD DS を立てる際、以下の 2 つの選択肢があるためだ。

既存フォレストの拡張:
オンプレミスにある「森」の一部（新しいドメインコントローラー）を Azure に植える。オンプレミスのユーザー情報をそのまま使える。
新しいフォレストの作成:
オンプレミスとは完全に切り離された、Azure 専用の「新しい森」を作る。セキュリティを完全に分離したい場合や、オンプレミスに依存したくない場合に使用する。

まとめ：直感的な理解
ドメイン： 1 つの部署や支店（管理の箱）。
ツリー： 本社と支社（名前が繋がっている）。
フォレスト： グループ企業全体（名前が違っても、同じルールで動く最大のまとまり）。

シナリオ 2：オンプレミスDCへの直接参照（クロスプレミス接続）

Azure上にDCを立てず、VPNやExpressRoute越しにオンプレミスのDCを利用する構成。
用途: 非常に小規模なワークロードや、一時的な利用。
課題: ネットワークの遅延（レイテンシ）が認証パフォーマンスに直結する。接続が切断されるとAzure上のワークロードが認証不能に陥るため、可用性にリスクがある。

シナリオ 3：オンプレミスの拡張（ハイブリッド構成）【推奨】

Azure VM上にオンプレミスの追加ドメインコントローラー（DC）をデプロイする構成。
用途: SAPなどのミッションクリティカルなエンタープライズワークロード。
メリット: 認証トラフィックがAzure VNet内で完結（ローカライズ）するため、最高のパフォーマンスが得られる。また、オンプレミスとの接続が切れてもAzure側で認証を継続できる（冗長性）。

設計上の重要ポイント

1. ネットワークとサイトトポロジ

接続手段: サイト間VPNまたはExpressRouteが必須。
AD サイトの定義: Azure VNetのサブネットを「別のADサイト」として定義し、サイト間レプリケーションを設定する。これにより、不要なレプリケーション通信を抑制し、認証要求が正しくAzure内のDCにルーティングされる。

2.読み取り専用ドメインコントローラー (RODC)

セキュリティ: クラウド上のDCが侵害されるリスクを懸念する場合、RODC（Read-Only Domain Controller）の配置を検討する。
コスト: 書き込みトラフィックが発生しないため、送信データ転送料（Egressコスト）を抑える効果もある。ただし、パスワードの変更頻度が高い環境などでは制約が出る場合がある。

3.グローバルカタログ (GC) の配置

原則: Azure上のすべてのDCをグローバルカタログサーバーとして構成すべきである。
理由: マルチドメイン環境などでグローバルカタログの参照が必要になった際、オンプレミスまで通信しに行く（クロスプレミス通信）のを防ぐためだ。

4.IP アドレスと DNS

静的 IP: Azureポータルで、DCとなるVMのプライベートIPアドレスを「静的（Static）」に固定しなければならない。
VNet DNS: VNetの設定で、DNSサーバーとして自前のDC（Azure上のDCのIPアドレス）を優先的に参照するよう変更する。

試験対策

「認証パフォーマンス向上のため、Azure側にDCをデプロイしてトラフィックを局所化せよ」
「Azure上のDCはすべてグローバルカタログサーバーとして有効化すべきである」
「サイト間レプリケーションのスケジュールを調整し、回線帯域を最適化せよ」

Linux と Active Directory の統合手法

1.LDAP 認証 / 認可

AD が備える標準的な LDAP プロトコルを利用する手法である。
仕組み: Linux の名前解決スイッチ（NSS）と認証モジュール（PAM）が、AD の LDAP エンドポイントと直接通信して認証を行う。
メリット: 追加の複雑なデーモンが不要で、標準プロトコルのみで動作する。
制約: Linux クライアントからパスワードの変更ができない。 パスワードの有効期限ポリシーを運用する場合、別途パスワード変更用の仕組みを導入するなどの考慮が必要である。

2.Kerberos 5 認証 / LDAP 認可（推奨・一般的）

認証に Kerberos プロトコルを使用し、属性情報の取得（認可）に LDAP を使用するハイブリッドな手法である。
仕組み: PAM は pam_krb5 モジュールを介して AD の KDC（鍵配布センター）と通信し、安全に認証を行う。
メリット: 安全性が高く、Linux 側からパスワード変更が可能である。標準的なコンポーネントのみで構成できるため、エンタープライズ環境で広く普及している。

3.Winbind 認証 / 認可

Samba スイートの一部である Winbind デーモンを使用する、より高度で複雑な手法である。
仕組み: Linux 上で Winbind デーモンを実行し、RPC や NTLM といった Windows 独自のプロトコルもサポートする。
メリット: AD 側に特別なスキーマ拡張（Services for UNIX など）をインストールする必要がない。また、SMB プロトコルによるファイル共有（Samba）を併用する場合は、この手法が最適である。
デメリット: 構成が複雑になり、Linux 側で維持すべきプロセスが増える。

SAP on Azure における選定の視点

標準的なログイン管理: 設定のシンプルさとパスワード変更機能を両立できる Kerberos 5 + LDAP（または現代的な SSSD：System Security Services Daemon）の利用が一般的である。
ファイルサーバーとの統合: Linux サーバーを Windows ネットワーク上のファイル共有サーバーとしても機能させる必要がある場合は、Winbind が選択肢となる。
Azure のマネージドサービス: 自前で DC を運用したくない場合は、Microsoft Entra Domain Services（旧 Azure AD DS）を利用することで、ドメイン参加をより容易に実現できる。

試験対策

「Kerberos 5 構成は、安全性とパスワード変更機能の双方を提供するため推奨される」
「SMB によるファイル共有を伴うシナリオでは、Winbind の採用を検討せよ」
「LDAP 認証のみの構成では、パスワード有効期限管理の運用設計が別途必要である」

Azure Virtual Machines のリモート管理

1.Azure VM への接続・管理手法

Azure 上の VM（特に SAP サーバー）へアクセスする方法は、セキュリティレベルに応じて大きく 2 つに分類される。

パブリックエンドポイント（Jumpbox 経由）

インターネット経由で「踏み台（Jumpbox/Bastion）」サーバーに接続し、そこから内部ネットワークの SAP サーバーへアクセスする手法。初期構築時や緊急時に利用されるが、運用フェーズでは最小限にすべきである。

サイト間接続（VPN / ExpressRoute）

オンプレミスと Azure を専用線や暗号化トンネルで結ぶ手法。運用環境ではこの方式が必須である。SAP GUI の利用、他システムとのデータ連携、バックアップ通信など、すべての業務トラフィックの基盤となる。

2.Azure Automation：構成管理とコスト最適化

Azure Automation は、クラウド環境の運用を自動化するマネージドサービスである。

Desired State Configuration (DSC)

Windows や Linux VM の構成（OS 設定やパッチ状況）を定義し、あるべき状態を維持する。構成が定義から逸脱した場合、自動で検知・レポートし、必要に応じて修正をかけることが可能である。

起動・停止のスケジューリング
開発・テスト環境など、24時間稼働が不要な VM をスケジュールに従って自動停止・起動させる。これにより、コンピューティングコストの大幅な削減（割り当て解除による課金停止）が実現できる。

##3.SAP Landscape Management (LaMa)
SAP LaMa は、複雑な SAP ランドスケープの管理を自動化するツールであり、Azure との親和性が極めて高い。

Azure コネクタの統合:
SAP LaMa 3.0 SP05 以降、Azure 用のコネクタが標準搭載されている。これにより、SAP の管理画面から Azure のインフラ操作を直接実行できる。

主な自動化機能:
インフラ操作: VM の起動・停止、マネージドディスクのコピー・再配置・削除。
システム操作: SAP システムのコピー（System Copy）、クローン作成、リフレッシュ、再配置（Relocation）。
メリット: 従来は手動で数日かかっていた「本番データのテスト環境へのリフレッシュ」などの作業を、インフラ操作と連携して大幅に短縮できる。

試験対策

「運用環境の SAP 接続には、VPN または ExpressRoute による専用接続が不可欠」
「Azure Automation DSC を活用し、OS 設定の整合性とガバナンスを維持」
「SAP LaMa と Azure コネクタを組み合わせ、システムコピーやリフレッシュの運用工数を削減できる」

SAP LaMa 用 Azure コネクタの設定手順

1.Azure 側：サービスプリンシパルの作成

SAP LaMa が Azure API を操作するための「専用アカウント（サービスプリンシパル）」を作成する。
アプリの登録: Microsoft Entra ID で「アプリの登録」を行い、任意の名前（例：SAP-LaMa-Connector）で登録する。

認証情報の取得:
アプリケーション ID: これが LaMa 側での「ユーザー名」となる。
クライアントシークレット（キー）: 新しいキーを作成し、値を控える。これが LaMa 側での「パスワード」となる。
テナント ID の確認: Entra ID の概要ページから「ディレクトリ（テナント）ID」を控えておく。

2.Azure 側：アクセス権限（IAM）の付与

作成したサービスプリンシパルに対し、対象のリソースグループ（SAP サーバーが配置されている場所）を操作する権限を与える。
ロール: 「共同作成者 (Contributor)」 を選択する。
範囲: SAP LaMa で管理対象とするすべてのリソースグループに対して、このロールを割り当てる必要がある。

3.SAP LaMa 側：クラウドマネージャーの設定

SAP LaMa の管理コンソールから Azure との接続を定義する。
アダプター選択: Microsoft Azure Cloud Adapter を選択。
構成情報: * ユーザー名/パスワード: 前述のアプリケーション ID とシークレットを入力。
URL: https://management.azure.com/（既定）。
監視間隔: 300 秒以上 に設定する。
ID 情報: Azure サブスクリプション ID とテナント ID を入力。
テスト: 「Test Configuration」を実行し、「Connection successful」が表示されることを確認する。

4.仮想マシン側：エージェントの準備

SAP LaMa が VM の内部状態（インスタンスの稼働状況など）を把握するためには、ターゲットとなる各 VM に以下のコンポーネントがインストールされている必要がある。

SAP Host Agent: 最新バージョンであることを推奨。

SAP Adaptive Extensions (SAPACEXT): VM のコピーや再配置などの高度な操作を実行するために必須である。

運用のポイント

管理コストの削減: SAP システムのコピー（System Copy）やリフレッシュ作業において、Azure のスナップショット機能と LaMa のオーケストレーションを組み合わせることで、手動作業の大部分を自動化できる。

ネットワーク: SAP LaMa サーバーから Azure の管理エンドポイント（management.azure.com）へ HTTPS 通信ができるよう、プロキシやファイアウォールの設定を確認しておく必要がある。

試験対策

「SAP LaMa の Azure 連携には、サービスプリンシパルへの共同作成者権限の付与が必須である」
「監視間隔は API 制限を考慮し、300 秒以上に設定すべきである」
「VM 側の操作を完結させるため、最新の SAP Host Agent と Adaptive Extensions を導入せよ」

Azure における SAP デプロイ手法

1.Azure ポータルと Azure Center for SAP Solutions (ACSS)

手動での構築や、視覚的な管理を重視する場合のデプロイ手法である。
Azure ポータル: 直感的な操作でリソースを作成できる。
Azure Center for SAP Solutions (ACSS): SAP システムを単なる VM の集まりではなく、一つの「統合されたワークロード」として管理する。デプロイの自動化だけでなく、構築後の稼働状況の監視やガバナンスの維持までサポートするエンドツーエンドのソリューションである。

2.コマンドラインによる自動化 (PowerShell / CLI)

スクリプトベースで、多数のシステムを一貫してデプロイする場合に使用される。
Azure PowerShell: Windows 管理者に馴染み深く、拡張性が高い。
Azure CLI: Linux/Bash 環境と親和性が高く、クロスプラットフォームで動作する。
必須手順: SAP NetWeaver システムのデプロイ時には、パフォーマンス情報の収集に不可欠な Azure Monitoring Extension for SAP をこれらを通じて導入する必要がある。

3.Terraform による Infrastructure as Code (IaC)

インフラの状態を構成ファイル（コード）として管理する手法である。
マルチクラウド対応: Azure 以外の環境（オンプレミス等）でも共通の言語でインフラを管理できるため、ハイブリッド環境やマルチクラウド構成で広く採用されている。
宣言型管理: 「あるべき姿」を記述することで、リソースの作成、更新、削除を Terraform が安全に制御する。

4.SAP on Azure Deployment Automation Framework

GitHub で提供されている、Azure 公式の高度な自動化テンプレート群である。以下の 2 段階で構成されている。
Terraform モジュール: 仮想ネットワーク、ストレージ、VM などの物理インフラ（土台）をプロビジョニングする。
Ansible プレイブック: Terraform で作成された VM 上に、SAP HANA やアプリケーションをインストールし、OS の最適化設定を行う。

サポートされる主な構成
HANA シングルノード: 非運用環境などのシンプルな構成。
HANA 高可用性 (HA) ペア: * HSR (HANA System Replication): プライマリからセカンダリへのデータ同期。
Pacemaker クラスタ: 障害検知時の自動切り替え。SBD (Storage-Based Fencing) や Azure リソースエージェントが自動で構成される。

試験・実務での視点

「複雑な HA クラスタのデプロイには、人為的ミスを防ぐための Automation Framework 活用が推奨される」
「ACSS を利用することで、SAP インスタンスを Azure 上で一元的に視覚化・管理せよ」
「IaC (Terraform) を導入し、インフラ構成のバージョン管理と再現性を確保すべきである」

Azure Resource Manager テンプレートを使用してデプロイする

1.2層（2-Tier）構成テンプレート

データベースとアプリケーションサーバーを同一の仮想マシン（VM）に配置する、比較的小規模な環境向け。
標準 Marketplace イメージ: 最新パッチ適用済みの OS で迅速に構築。
Managed Disks 利用: 運用管理を簡素化し、ストレージの信頼性を向上。
カスタム/プライベートイメージ: 独自の最適化を施した OS イメージからのデプロイにも対応。

2.3層（3-Tier）構成テンプレート

データベース、ASCS/SCS（セントラルサービス）、アプリケーションサーバー（DI）を個別の VM に分離するエンタープライズ向けの標準構成。

高可用性（HA）の実装
可用性セット: 各コンポーネント（DB/ASCS/DI）を複数の VM に分散配置。
ロードバランサー: 外部または内部からのトラフィックを稼働中のノードへ自動転送。
WSFC 等のサポート: Windows Server Failover Cluster 等、OS レベルのクラスタ構成が可能な土台を構築する。

3.マルチ SID 構成

複数の SAP システム（SID）を同一のインフラ上に同居させる、高度に集約された環境向けのテンプレートである。
(A)SCS サーバーの集約: 1台（またはHAペア）のサーバー上で複数の SID の ASCS をホストする構成。
柔軟な拡張: アプリケーションサーバー層のみ、あるいはデータベース層のみを個別にデプロイするための専用テンプレートが用意されている。

4.共有ファイルサーバー

SAP システムの共通ディレクトリ（/sapmnt や usr/sap/trans）をホストするための高可用性ストレージ構成。
Linux (SLES/RHEL): NFS や GlusterFS を使用したクラスタ構成。
Windows: 記憶域スペースダイレクト（S2D）を用いたスケールアウトファイルサーバー（SOFS）。

5.SAP LaMa 専用テンプレート

SAP Landscape Management (LaMa) で管理されることを前提としたテンプレート。
自動インストール: VM のデプロイと同時に、LaMa との連携に必要なアプリケーションや特定のディスクレイアウトが自動的に構成される。

まとめ：テンプレート選択の指針

「本番環境では、Managed Disks と可用性ゾーン/セットを組み合わせた 3層 HA テンプレートを選択せよ」
「運用コストを抑えつつ複数の SAP システムを統合するなら、マルチ SID テンプレートを活用すべきである」
「共有ストレージは OS の種類に合わせて、NFS クラスタまたは SOFS テンプレートから最適なものをデプロイせよ」

Azure Virtual Machines に単一インスタンスの SAP HANA を手動でインストールする

1.インストールの主要なアプローチ

HANA ベースの NetWeaver デプロイメントでは、構成に応じて以下のいずれかのツールを選択する。
SWPM (Software Provisioning Manager): 標準的な 2層（単一サーバー）または 3層（分散）インストール。HANA インストールをその一環として実行する。
HDBLCM (HANA Database Lifecycle Manager): HANA DB のインストール・管理に特化したツール。NetWeaver のインストールと組み合わせて使用する。

2.インストール手順の核心：ASCS と /sapmnt

インストールの成否を分けるのは、最初の ASCS (ABAP SAP Central Services) インスタンスのセットアップと、共有ディレクトリの構成である。
/sapmnt 共有の重要性: インストール中、データベースサーバーは SAP プロファイルディレクトリを含む /sapmnt にアクセスできなければならない。
Linux の NFS 構成: /sapmnt を NFS で共有する場合、rw（読み書き可能） および no_root_squash オプションが必須である。
注意: デフォルトの root_squash では、DB インスタンスのインストール中に権限エラーが発生し、処理が中断するリスクがある。
Windows の SMB 構成: Windows 環境では SMB プロトコルを使用して同様の共有を実現する。

3.インストール後の検証：HCMT の実行

インフラの構築とインストールが完了した後、その VM が SAP の認定基準を満たし、本番環境の負荷に耐えられるかを必ず検証しなければならない。
HCMT (SAP HANA Cloud Measurement Tool): 現在の標準ツール。CPU、メモリ、ディスク I/O のパフォーマンスを測定する。
HWCCT (Hardware Configuration Check Tool): 古いツール（HANA 1.0 等）で使用されていたが、現在は HCMT に置き換わっている。
認定の確認: HCMT の結果は専門家が検証し、SAP の公式認定を受けていることを確認する必要がある。これは本番稼働後のサポートを受けるための前提条件となる。

4.全体的な流れ

VM 展開: SAP 認定の VM サイズ（Mシリーズ等）をデプロイ。
ASCS インストール: /sapmnt を作成・共有。
データベースインストール: HDBLCM または SWPM を使用。
PAS (Primary Application Server) インストール: 最終的なアプリケーション層の構築。
確認: SAP GUI でのログイン確認および HCMT によるインフラ検証。

まとめ：試験・実務での視点

「NFS 共有設定時の no_root_squash オプションを忘れるな。権限不備はインストールの失敗に直結する」
「本番稼働前には必ず HCMT を実行し、測定結果を SAP の要件に照らして検証せよ」
「ASCS インスタンスを最初に構築し、DB サーバーがプロファイル情報を参照できる状態を作ることが先決である」

1.OS アップデートと SAP 向けイメージの利用

Azure 上での SAP HANA 構築においては、通常の Linux イメージではなく、**「for SAP」**と名の付く専用イメージ（SLES for SAP Applications や RHEL for SAP Solutions）の使用が強く推奨される。
OS 登録: インストール前に必ずベンダー（SUSE/Red Hat）のサブスクリプションに登録し、最新のパッチを適用する。
パッチ適用: zypper (SLES) などのコマンドを使用し、特に security および recommended カテゴリの重要パッチを優先的に導入して、既知の不具合を回避する。

2.ディスク構成とストレージ設定

SAP HANA の TDI（Tailored Data Center Integration）要件を満たすため、Azure では Premium SSD またはそれ以上のストレージの使用が必須である。
ストライピング (LVM/MDADM): /hana/data と /hana/log のスループットを確保するため、複数のディスクを LVM または MDADM でストライプ化する。Premium SSD は冗長性が確保されているため、RAID 1 等の冗長構成を組む必要はない。
ディスクキャッシュ: * /hana/data および /hana/log 用ディスク：None (無効)。
OS やその他のボリューム：ReadOnly。
マウント: デバイス名（/dev/sdc 等）は再起動時に変わる可能性があるため、必ず UUID を使用して /etc/fstab に記述する。

3.カーネルパラメータの最適化 (tuned-adm)

SAP HANA には特有の Linux カーネル設定が必要である。最新の Linux ディストリビューションでは、専用ツールを使用してこれを一括適用できる。
プロファイル適用: SLES 12 以降では tuned-adm を使用し、sap-hana プロファイルを有効化する。
コマンド例: tuned-adm profile sap-hana
永続化: grub2 や YaST のブートローダー設定を通じて、再起動後もこれらのパラメータが維持されるように構成する。

4.ファイルシステムとパスの確保

ルートファイルシステム（/）の容量不足はシステムの停止に直結するため、各パスを適切に分離・管理する。
XFS 形式: SAP HANA では一般的に XFS ファイルシステムが推奨される。
容量の確保: /hana および /usr/sap に十分なディスク領域を割り当てる。特に HANA のログバックアップは既定で /usr/sap（またはその配下）に保存されるため、注意が必要である。
スワップ領域: 不足する場合は dd や mkswap でスワップファイルを作成するか、Azure Linux エージェントの設定で自動作成を構成する。

5.ネットワークと名前解決 (/etc/hosts)

SAP インスタンス間の通信を円滑にするため、静的な名前解決を設定する。
/etc/hosts の編集: すべての SAP 関連 VM のプライベート IP アドレスとホスト名を記述する。
VNet の統合: 通信遅延を最小限にするため、すべての VM は同一の Azure 仮想ネットワーク（VNet）内にデプロイされるべきである。

6./etc/fstab の耐障害性

ディスク障害が VM 全体の起動不能を招かないよう、/etc/fstab には nofail オプションを付与することが推奨される。ただし、/hana ディレクトリがマウントされない場合、HANA データベース自体は起動できない点に留意が必要である。

まとめ：準備段階

「SUSE/RHEL の SAP 専用イメージを選択し、tuned-adm で HANA 向け最適化を施せ」
「HANA データ・ログボリュームには Premium SSD を使い、ディスクキャッシュは必ず無効化せよ」
「マウント設定には UUID を使用し、再起動時のデバイス名変更によるトラブルを防止せよ」

Azure 環境におけるスケールアウト実装

SAP HANA スケールアウトは、単一のサーバー（スケールアップ）では対応できない大規模なメモリ要求（数TB〜数十TB）に対し、複数のノードを組み合わせて一つのシステムとして稼働させる構成である。

1. ネットワークと基盤の準備

スケールアウト構成では、ノード間通信（インターノード通信）のパフォーマンスがシステム全体の性能を左右する。
VNet 構成: 同一の仮想ネットワーク内に配置する。ノード間、およびノードと NFS クラスター間の通信が NVA（ネットワーク仮想アプライアンス）を経由しないよう設計せよ。NVA はボトルネックや遅延の原因となる。
ディスクデプロイ: 各 VM には Managed Premium Storage を使用する。

2.共有ストレージ (NFS) の役割

スケールアウト構成では、「共有するデータ」と「各ノード固有のデータ」を明確に分ける。
/hana/shared: すべてのノードから参照可能である必要がある。Azure では、高可用性 NFS クラスター（SLES/RHEL の Pacemaker クラスタ）や Azure NetApp Files 上に配置するのが標準である。
/hana/data と /hana/log: パフォーマンス確保のため、各ノードに直接接続された非共有ディスクを使用する。

3.インストールと重要なパラメータ設定

インストールは「リーディングノード（Master）」から開始する。
リーディングノードのインストール: SAP 公式手順に従い、最初のノードを構築する。
非共有構成の有効化: global.ini に以下のパラメータを追加する。
basepath_shared = no
これにより、/hana/data と /hana/log をノード間で共有せず、ローカルディスクを利用する構成が有効になる（SAP Note #2080991）。
再起動: パラメータ反映のため、インスタンスを再起動する。

4.ワーカーノードの追加と内部通信

リーディングノードが整った後、処理を担うワーカーノードを結合する。
ノード追加: コマンドラインまたは hdblcm を使用してワーカーノードを追加する。
インターノードネットワーク: ノード間でのデータ転送用に専用の内部ネットワークを指定する。これにより、クライアントアクセス用トラフィックと DB 内部の同期トラフィックを分離し、パフォーマンスを最適化する（SAP Note #2183363）。

まとめ：スケールアウト実装

「/hana/shared は Azure NetApp Files や NFS クラスタで共有し、データ・ログは各ノードのローカル SSD に配置せよ」
「global.ini の basepath_shared = no 設定により、Azure 上での非共有ストレージ構成を正しく実現せよ」
「ノード間通信に NVA を介在させず、低遅延なネットワーク環境を維持することが運用の鍵である」

Azure Center for SAP ソリューションの詳細

1.SAP ソリューションの仮想インスタンス (VIS) とは

ACSS の中心となる概念が VIS (Virtual Instance for SAP solutions) である。これは、Azure 上における SAP システムの「論理的な分身」であり、SID を頂点とした階層構造でシステムを表現する。
階層構造: 親リソース: SID（システム ID）
子リソース: ASCS インスタンス、データベース、アプリケーションサーバー

役割: 物理的な VM と SAP の論理インスタンスを紐付けることで、「どの VM が DB で、どの VM がアプリサーバーか」を Azure が正確に把握する。これにより、SAP レイヤとインフラレイヤを一元管理できる。

2. ACSS が提供する主な価値

A.ガイド付きデプロイと自動インストール

新規構築において、Microsoft のベストプラクティスに基づいたインフラのプロビジョニングと、SAP ソフトウェアのインストールを自動化する。
サポートされる構成: 単一サーバー、分散型、高可用性 (HA) 構成。

B.既存システムの登録

すでに Azure 上で稼働している SAP システム（NetWeaver / ABAP スタック）も、ACSS に登録することで VIS として管理下に置くことができる。
対応範囲: Windows/Linux、主要なデータベース（HANA, SQL Server, Oracle 等）を幅広くカバーしている。

C.運用管理の統合

VIS を通じて、以下のような高度な運用が Azure ポータルから可能になる。
一括起動・停止: SAP アプリケーション層の起動・停止を Azure ポータルからワンクリックで実行できる。
品質チェックと分析: システム設定がベストプラクティスに適合しているかを自動評価し、改善案を提示する。
コストとメトリックの可視化: SAP システム単位での消費コストや、インフラのパフォーマンス（CPU、IOPS 等）を俯瞰できる。

3.SAP on Azure における位置づけの変化

ACSS の登場により、SAP 運用は「サーバー（VM）の管理」から、「ビジネスサービス（SAP ワークロード）の管理」 へとシフトした。

まとめ：ACSS 活用

「新規デプロイだけでなく、既存システムも VIS 登録し、Azure の管理ガバナンスを適用せよ」
「品質チェック機能を定期的に確認し、ベストプラクティスからの逸脱を早期に修正すべきである」
「SAP 単位でのコスト分析を活用し、クラウド利用の最適化（ライトサイジング）に役立てよ」

Azure Center for SAP ソリューションの展開オプションを選択する

Azure Center for SAP Solutions (ACSS) を使用して S/4HANA 環境をデプロイする際、ビジネス要件（可用性、コスト、パフォーマンス）に応じた最適なインフラストラクチャ・オプションを選択することが重要である。

1.展開オプションと SLA の選択

ACSS では、ワークロードの重要度に基づいて 3 つの主要なアーキテクチャを選択できる。

A.高可用性 (HA) を備えた分散型 【本番環境推奨】

システム停止が許されない本番環境向けの構成である。選択する SLA によって、リソースの配置戦略が異なる。

99.99% (可用性を最適化 - 可用性ゾーン利用):

配置: リージョン内の 2 つの可用性ゾーン (AZ) にリソースを分散する。
詳細: プライマリゾーンにアクティブな ASCS と DB を、セカンダリゾーンにパッシブ（待機系）を配置し、アプリケーションサーバーは両ゾーンに均等に配置される。
前提: M/E シリーズの SKU が両ゾーンで利用可能である必要がある。

99.95% (コスト最適化 - 可用性セット利用):

配置: 同一データセンター内の異なるラック（可用性セット）に分散する。
詳細: ASCS、DB、アプリサーバー用にそれぞれ独立した可用性セットが作成される。ゾーン間の通信遅延を避けたい場合や、AZ が未提供のリージョンで有効である。

B. 分散型 (非 HA)

各コンポーネントを独立したサーバーに配置するが、冗長性を持たない構成である。開発・検証環境など、コストと性能のバランスを重視する場合に適している。

C. シングルサーバー

すべてのコンポーネント（ASCS, DB, App）を 1 台の VM に集約する。非本番環境（サンドボックス等）でのみ利用可能である。

2.サポートされるソフトウェアと OS 互換性

ACSS は最新の SAP ベストプラクティスに準拠しており、以下の組み合わせをサポートしている。
SAP ソフトウェア: S/4HANA 1909 / 2020 / 2021 / 2022 (SPS/ISS 準拠)。
オペレーティングシステム: * RHEL for SAP Applications: 8.2, 8.4, 8.6 (Gen2 イメージ)。
SLES for SAP Applications: 12 SP4/SP5 (1909のみ), 15 SP3/SP4。
イメージバージョンの管理
ポータルからのデプロイでは「Latest（最新）」イメージが使用されるが、特定のバージョンを固定したい場合は CLI や PowerShell を利用する。
運用上のヒント: 最新イメージでのデプロイが失敗する場合、API を使用して一つ前の安定したバージョン（Version 履歴から取得）を指定することで、環境の再現性を担保できる。

3.デプロイの成功に向けたチェックリスト

リージョンの確認: 選択したリージョンで 99.99% SLA を実現するための可用性ゾーンと必要な VM SKU（M シリーズ等）が利用可能か。
OS イメージの選定: 導入する S/4HANA バージョンと OS（RHEL/SLES）の互換マトリクスを確認したか。
前提条件のプロビジョニング: ネットワーク (VNet/Subnet)、ストレージ、およびマネージド ID 等の ACSS 権限設定が完了しているか。

まとめ：構成選択

「本番ワークロードには、地理的な冗長性を確保できる可用性ゾーン (99.99%) を優先して採用せよ」
「可用性ゾーンが利用できないリージョンでは、可用性セット (99.95%) による可用性担保を検討すべきである」
「デプロイの安定性を高めるため、必要に応じて PowerShell を使い、検証済みの特定の OS バージョンを固定してデプロイせよ」

1.OS ごとの高可用性（HA）サポート体制

Azure VM 上で稼働する SAP インスタンスの HA 構成は、ゲスト OS の種類によってサポートされるテクノロジーが異なる。

Windows Server

技術: Windows Server フェールオーバー クラスター (WSFC) を使用。
ストレージ: Azure ネイティブでは共有ディスクが制限される場合があるため、SIOS DataKeeper 等による「非共有ストレージのレプリケーション」を介して共有ディスクをエミュレートする構成が一般的である。
サポート: Microsoft が SAP アプリケーションに対する透過性を保証しており、ガイドラインに従った構成であればフルサポートの対象となる。

SUSE Linux Enterprise Server (SLES) for SAP Applications

技術: Pacemaker クラスタフレームワークを使用。
対象: SAP HANA システムレプリケーション (HSR) および SAP NetWeaver ASCS インスタンス。
サポート: SUSE と Microsoft の強力なパートナーシップにより、専用のフェンシングエージェント（Azure STONITH 等）を用いた HA 構成が最適化・サポートされている。

Red Hat Enterprise Linux (RHEL) HA アドオン

技術: Red Hat Enterprise Linux HA アドオン（Pacemaker/Corosync）を使用。
対象: HSR および NetWeaver ASCS。
サポート: Red Hat と Microsoft の共同サポート体制により、エンタープライズレベルの信頼性が確保されている。

2.2層 vs 3層アーキテクチャと HA/DR への影響

システムの階層設計（ティアリング）は、可用性設計だけでなくパフォーマンスのサイジングにも直結する。

2層アーキテクチャ (Central Instance)

構成: データベースと NetWeaver コンポーネントを同一の VM にインストールする。
特性: ネットワーク遅延（DB・アプリ間）を排除できる。
HA/DR の課題: VM が 1 台であるため、単一障害点 (SPOF) となりやすい。HA を組む場合はサーバーごと丸ごと冗長化する必要がある。

3層アーキテクチャ (Distributed)

構成: データベース層とアプリケーション層を別々の VM に分離する。
特性: スケーラビリティに優れ、各層ごとに独立した HA 構成（DB のミラーリング、ASCS のクラスタ化、アプリサーバーの分散配置）が可能である。
サイジング: SAPS 値（SAP パフォーマンス指標）の評価が 2 層構成とは異なるため、VM SKU の選定には注意を要する。

3.ディザスターリカバリー (DR) の考え方

HA が「単一リージョン内での障害対策」であるのに対し、DR は「リージョン全体の被災」に備えるものである。
Azure Site Recovery (ASR): アプリケーション層の VM を別リージョンへレプリケーションする主要な手段。
HANA System Replication (HSR): データベース層については、ASR よりも HSR を用いて遠隔リージョンの DB インスタンスへデータを同期する手法が、データ整合性と復旧時間の観点から推奨される。

まとめ：設計

「OS ごとの認定クラスタ構成（WSFC / Pacemaker）を正しく選択し、サポート要件を遵守せよ」
「ミッションクリティカルな本番環境では、各層の独立した HA 構成が可能な 3 層アーキテクチャを採用すべきである」
「可用性ゾーン (AZ) を跨ぐ HA と、遠隔リージョンへの DR (HSR/ASR) を組み合わせた多層防御を構築せよ」

1.Windows Server フェールオーバー クラスタリング (WSFC)

Windows 環境における SAP ASCS/SCS や AnyDB の可用性を高める基盤である。

クォーラム (Quorum): 「スプリットブレイン（ノード間の通信断絶により、双方が自分を主系と誤認すること）」を防ぐための多数決の仕組み。

クラウド監視 (Cloud Witness): Azure 運用において最も推奨されるモード。Azure ストレージアカウント上の小さなファイルを「1票」として利用する。以前の手法（ディスクマジョリティ等）に比べ、追加の VM が不要でコスト効率が高い。

共有ディスクの代替: Azure ネイティブでは共有ディスクに制約があるため、SIOS DataKeeper 等を用いてローカルディスクを同期レプリケートし、仮想的な共有ストレージを構築する。

2.Linux Pacemaker とフェンシング (STONITH)

Linux 環境（SLES/RHEL）で SAP HANA や ASCS を保護するためのクラスターマネージャーである。
STONITH (Shoot The Other Node In The Head): 異常が発生したノードの電源を強制的に遮断・再起動させ、データの破損を防ぐ不可欠な機能。

フェンシングの実装手法:

Azure Fence Agent: Azure API を介して VM を再起動させる。追加インフラが不要。フェイルオーバー時間を短縮するため skipShutdown フラグ（正常なシャットダウンプロセスをスキップ）の設定が推奨される。
SBD (STONITH Block Device): iSCSI ターゲット（共有ディスク）上のメッセージ領域を監視する。API 経由よりも切り替えが高速である。
SBD の構成: 信頼性を確保するため、1 つまたは 3 つの iSCSI ターゲットサーバーを使用する。2 つでは多数決が成立せず、片方の障害時に正常なフェンシングができないリスクがある。

3.仮想サーバー名と Azure ロードバランサー

クラスター化された SAP コンポーネントへのアクセスは、特定の物理サーバーの IP ではなく、**「仮想サーバー名（仮想 IP）」**に対して行われる。
仕組み: クラスタがフェイルオーバーすると、仮想 IP も一緒に移動する。
Azure での実装: Azure Internal Load Balancer (ILB) を使用する。
フロントエンド IP: 仮想 IP として機能。
ヘルスプローブ: クラスタノードが現在アクティブかどうかを監視し、トラフィックを適切なノードに誘導する。

4.SLES 上での HA セットアップ手順 (概要)

OS と HANA の準備: SLES for SAP Applications の展開。
SBD の初期化: iSCSI 共有ディスクの準備と初期化。
クラスター初期化: ha-cluster-init による構築。
Softdog の構成: OS 停止時に自ら再起動するためのウォッチドッグ設定。
リソース登録: 仮想 IP、HANA リソース、STONITH デバイスの定義。
テスト: 意図的なノード停止によるフェイルオーバーの検証。

まとめ：クラスター設計

「Windows クラスタでは、最もシンプルかつ堅牢な『クラウド監視』を採用せよ」
「Linux では、追加 VM を抑えるなら Azure Fence Agent を、速度を優先するなら SBD を選択すべきである」
「フェイルオーバー後の接続性を担保するため、ロードバランサーのプローブ設定と仮想 IP の紐付けを正確に行え」

SAP HANA の可用性（ハイパフォーマンスと耐障害性）を確保するための構成

1.バックアップベースの回復（最も基本）

1 台目の VM で取得したバックアップを 2 台目の VM に転送し、手動で復元する手法である。
特性: スクリプトによる自動転送を行うが、復旧には「完全復元」が必要なため RTO が非常に長い。
用途: コストを最小限に抑えたい非運用環境や、誤操作によるデータ削除からの復旧シナリオに適している。他の HA 方式と組み合わせることで、論理的なデータ保護を強化できる。

2.SAP HANA システムレプリケーション (HSR)

2 台の VM 間でデータを同期し、障害時に切り替える手法である。Pacemaker による自動制御の有無で運用が変わる。

A.自動フェイルオーバーなし

コスト優先型: 2 台目の VM を小さいサイズにしたり、別インスタンスを実行したりできる。フェイルオーバー時に VM のサイズアップや他インスタンスの停止が必要なため、RTO は長くなる。
管理: Pacemaker の複雑さを回避できるが、監視と切り替えは手動となる。

B.自動フェイルオーバーあり（標準的な本番構成）

SLES または RHEL の Pacemaker クラスタ を使用し、STONITH（フェンシング）を構成する。
同期モード: プライマリでのコミット時にセカンダリの確認を待つため、RPO = 0 を実現できる。
ホットスタンバイ: データをメモリにプリロードしておくことで、極めて短い RTO を実現する。
接続性: クライアントは Azure 内部ロードバランサー (ILB) の仮想 IP を通じて接続するため、切り替え後のアプリケーション再設定は不要である。

3.ホストの自動フェイルオーバー（スタンバイノード構成）

1 つ以上のスタンバイノードを追加し、アクティブノードの障害時に処理を引き継がせる。
ストレージ: スタンバイノードが全ボリュームにアクセスできる必要があるため、Azure NetApp Files 上の NFS が一般的に使用される。
プロトコル: I/O フェンシング（ファイルリース機能）を利用するため、NFSv4.1 の使用が必須である（NFSv3 はサポート対象外）。

4.スケールアウト構成の可用性

複数のノードを組み合わせるスケールアウト環境では、インフラの堅牢性が重要となる。
サービス修復: Azure 基盤側の自己修復機能（Service Healing）と、HANA インスタンスの再起動プロセスに依存する。
共有 NFS: 構成上不可欠な共有ファイルシステム（/hana/shared）には、高可用性 NFS クラスター（現時点では主に SUSE Linux でサポート）の使用が求められる。

まとめ：HANA 可用性設計

「ミッションクリティカルな環境では、RPO=0 を実現する Pacemaker ＋ HSR 同期構成を第一選択とせよ」
「ホスト自動フェイルオーバーを組む際は、NFSv4.1 プロトコルの使用を徹底し、マウントオプションを厳守すべきである」
「コストと可用性のバランスを取るなら、データのプリロードを制限した HSR 手動フェイルオーバー構成を検討せよ」

1.可用性ゾーン (AZ) の本質

AZ は単なる論理的な区切りではなく、 「独立した電源・冷却・ネットワークを備えた物理的なデータセンター」 である。
SLA の向上: 可用性セット（99.95%）に対し、AZ を跨ぐデプロイメントは 99.99% の可用性 SLA を提供する。
物理的な分離: 火災や局所的な停電から SAP システムを保護するが、広域災害（地震など）に対する DR（災害復旧）としては不十分である点に注意が必要だ。

2.SAP 3 層アーキテクチャへの適用

AZ を利用する場合、各レイヤーで以下の配置戦略をとる。
ASCS / DBMS 層: 2 台の VM を「ゾーン 1」と「ゾーン 2」に分けて配置し、OS レベルのクラスタ（Pacemaker/WSFC）で同期レプリケーションを行う。
アプリケーション層: 複数の VM を各ゾーンに均等に分散配置する。これにより、一つのゾーンが完全にダウンしても、残りのゾーンで業務を継続できる。

3.「ネットワーク遅延」という最大の壁

AZ 構成で最も考慮すべきなのが、ゾーン間の物理的な距離によるネットワークレイテンシである。
DBMS 同期への影響: 主系（Zone 1）と副系（Zone 2）の距離が離れすぎていると、同期レプリケーションのオーバーヘッドによりデータベースの書き込み性能が低下する。
アプリ・DB 間の遅延: * アクティブ/アクティブ構成: 全ゾーンのアプリサーバーから主系 DB へ通信する。遅延が許容範囲内（通常 0.7ms 〜 1.0ms 以下）である必要がある。
アクティブ/パッシブ（ゾーン限定）構成: 遅延が大きい場合、主系 DB と同じゾーンにあるアプリサーバーのみを稼働させ、ゾーン障害時のみ他ゾーンのアプリを起動する。

4.可用性ゾーン採用時の「絶対ルール」

Managed Disks 必須: 非管理ディスクは使用できない。
可用性セットとの併用不可: 同一レイヤー（例：DB 層）において、可用性ゾーンと可用性セットを混ぜて使うことはできない。
Standard Load Balancer 必須: クラスタ構成には Basic ではなく Standard SKU のロードバランサーが必要だ。
物理マッピングの差異: サブスクリプション A の「ゾーン 1」が、サブスクリプション B の「ゾーン 1」と同じ物理場所であるとは限らない。マルチサブスクリプション環境では注意が必要である。

まとめ：AZ 設計

「可用性ゾーンを採用する際は、事前にネットワーク遅延を測定し、SAPS 値への影響を評価せよ」
「HA 構成のクラスタを組むなら、Azure Standard Load Balancer を選択し、フローティング IP 設定を有効にすべきである」
「高可用性（AZ）と災害復旧（リージョン間レプリケーション）は別物として設計し、多重の保護レイヤーを構築せよ」

SAP ワークロードの災害復旧について

1.データベース層の DR 戦略

最も重要なビジネスデータを保護するため、DBMS 固有の機能を利用した**「非同期レプリケーション」**が標準である。

HANA システムレプリケーション (HSR)

プライマリリージョン内で HA（同期）を組みつつ、遠隔リージョンの DR ノードへは非同期でデータを飛ばす「多層（マルチターゲット）レプリケーション」を構成する。

SQL Server Always On

同様に、遠隔地のノードを可用性グループのレプリカとして追加する。

手動フェイルオーバー

DR への切り替えはデータ損失（RPO > 0）の可能性があるため、システムが自動で判断するのではなく、人間が判断して実行するのが一般的である。

2.アプリケーション層の DR 戦略 (Azure Site Recovery)

アプリケーションサーバー（PAS/AAS）は状態を持たない（Stateless）ため、効率的な複製が求められる。
Azure Site Recovery (ASR):
VM 全体をブロックレベルで別リージョンへ継続的にレプリケートする推奨ソリューションである。
構成の同期:
ASR を使わない場合は、セカンダリに VM を用意して停止（シャットダウン）しておく「コールドスタンバイ」をとる。この場合、カーネルの更新や設定変更を手動でコピーし続ける運用負荷が発生する。
注意点: ASR は現時点で Ultra ディスクをサポートしていない。高性能ディスクを使っている場合は注意が必要。

3.セントラルサービス (ASCS/SCS) の DR

戦略 A (ASR 利用)

クラスタノードごと ASR で別リージョンへ飛ばす。最も管理がシンプルである。

戦略 B (Geo クラスター)

Windows のマルチサイトクラスタや Linux の高可用性拡張を使い、リージョンを跨いだ 3 ノード以上のクラスタを構成する。ただし、ネットワーク設計が非常に複雑になる。
共有ファイルの保護: /sapmnt（プロファイルやバイナリ）の内容を、rsync やロボコピー、あるいはストレージレベルのレプリケーションで DR 側にコピーしておく必要がある。

試験対策

「データベースは DBMS 独自の非同期レプリケーション（HSR 等）を使い、データの整合性を最優先せよ」
「アプリケーション層の保護には Azure Site Recovery を活用し、運用の自動化を図るべきである」
「ASR を採用する場合、Ultra ディスクの不採用など制限事項を考慮したストレージ設計を行え」

サイトリカバリ

1. データベース層：DBMS 固有のレプリケーション

データベースは ASR を使わず、DBMS 独自の高可用性・災害復旧機能を使うのがベストプラクティスである。理由は、メモリ上のデータ整合性と RPO（目標復旧時点）を最小化するため。
SQL Server: Always On 可用性グループ または ログ配布。
Oracle: Oracle Data Guard。自動切り替えを行うには「オブザーバー（FSFA）」の配置が必要である。
SAP HANA: HANA System Replication (HSR)。

2.SAP アプリケーション層：Azure Site Recovery (ASR)

DB 以外の「ステートレス（またはそれに近い）」な VM 群は Azure Site Recovery (ASR) でオーケストレーションを行う。
Web Dispatcher / アプリサーバー: ASR で VM ごと別リージョンに複製する。
ASCS/SCS (セントラルサービス): ASR で複製可能だが、注意が必要。
共有ディスク (SIOS DataKeeper) / S2D: ASR は「クラッシュ整合性」レベルの複製となる。
クラウド監視 (Cloud Witness): ASR では複製されないため、DR サイト側に別途用意する必要がある。

3.ASR による復旧の自動化と制限

DR サイトでシステムを再稼働させるには、VM を立ち上げるだけでは不十分であり、インフラの再構築が必要になる。
デプロイメントスクリプト: VM 起動後に「ロードバランサーの作成」や「IP アドレスの紐付け」を行うスクリプトを ASR のリカバリプランに組み込む。
ネットワークの設計: プライマリと DR サイトで同一の IP アドレス体系を使うか、変更するかを事前に決めておく必要がある。
高速ネットワーク (Accelerated Networking): ASR は現時点で 「高速ネットワーク設定」のレプリケーションをサポートしていない。 復旧後に手動またはスクリプトで再設定が必要な点は、試験でも問われやすいポイントの可能性。

4.全体像のチェックリスト

ASR を利用した DR 実装のフローは以下の通り。
VM 複製: ASR を有効化し、継続的レプリケーションを開始する。
ネットワーク: リカバリ用 VNet と、AD/DNS の同期（AD レプリケーション）を確保する。
DB 同期: HSR や Always On を非同期モードで構成する。
テスト: 「テストフェイルオーバー」機能を使って、本番に影響を与えず DR 訓練を実施する。