WEB問題集
AZ120-MIG#1
ある企業が、AnyDB (Oracle) 上で稼働する SAP ERP 6.0 (SAP NetWeaver) を、現行の OS・データベース・SAP カーネルバージョンを一切変更せずに、可能な限り短期間かつ低リスクで Azure へ移行したいと考えています。最も適した移行戦略はどれですか?
解説
【正解: A】の理由
Lift & Shift (Re-host) は、OS・データベース・SAP アプリケーションを変更せず、既存システムをそのまま Azure IaaS 上の仮想マシンへ移行する戦略です。SAP カーネルや AnyDB を維持できるため変更点が最小で、短期間かつ低リスクで実施でき、現行構成をそのまま持ち込む要件に最も合致します。
【他選択肢が違う理由】
- B: Re-platform は移行と同時にデータベースを SAP HANA へ変換する戦略で、DMO の実施が必要となり「DB を変更しない」という要件に反します。
- C: Re-architect (S/4HANA Greenfield) は業務プロセスを再設計して新規実装する大規模プロジェクトで、短期・低リスクの要件に合いません。
- D: Retire はシステム自体を廃止する戦略であり、現行 SAP を Azure で継続稼働させる目的には該当しません。
【参考】
AZ120-MIG#2
SAP HANA 認定の M シリーズ VM を作成する Azure CLI コマンドを完成させます。各ドロップダウンで適切な値を選択してください。
az vm create \
--resource-group rg-sap-prod \
--name vm-hana01 \
--image {{BLANK1}} \
--size {{BLANK2}} \
--zone {{BLANK3}}| ステートメント | 選択 |
|---|---|
--image: SAP 認定 OS イメージ SAP HANA は SLES for SAP / RHEL for SAP など SAP 認定 OS が必須です。SUSE:sles-sap-15-sp5:gen2 は SAP 認定の SLES for SAP イメージです。 | |
--size: HANA 認定 VM サイズ M シリーズ (Mv1/Mv2) は大容量メモリを持つ SAP HANA 認定 VM です。Standard_M128ms は HANA OLTP/OLAP の本番に使えます。 | |
--zone: 可用性ゾーン番号 可用性ゾーンを指定すると物理的に分離した障害ドメインに配置でき、SLA と HA を高められます。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| --image: SAP 認定 OS イメージ | SUSE:sles-sap-15-sp5:gen2 |
| --size: HANA 認定 VM サイズ | Standard_M128ms |
| --zone: 可用性ゾーン番号 | 1 |
【各判定の詳細】
- 「--image: SAP 認定 OS イメージ」→ SUSE:sles-sap-15-sp5:gen2: SAP HANA は SLES for SAP / RHEL for SAP など SAP 認定 OS が必須です。SUSE:sles-sap-15-sp5:gen2 は SAP 認定の SLES for SAP イメージです。
- 「--size: HANA 認定 VM サイズ」→ Standard_M128ms: M シリーズ (Mv1/Mv2) は大容量メモリを持つ SAP HANA 認定 VM です。Standard_M128ms は HANA OLTP/OLAP の本番に使えます。
- 「--zone: 可用性ゾーン番号」→ 1: 可用性ゾーンを指定すると物理的に分離した障害ドメインに配置でき、SLA と HA を高められます。
【参考】
AZ120-MIG#3
移行後に Azure Monitor for SAP solutions を有効化する手順を順序通りに並べてください。
- Azure Monitor for SAP リソースをデプロイ
- プロバイダー (HANA DB / OS / SAP NetWeaver) を追加
- 接続情報/資格情報を構成しテレメトリ収集を開始
- ブック/アラートでパフォーマンスと可用性を監視
解説
【正しい順序】
- ステップ 1: リソースデプロイ
- ステップ 2: プロバイダー追加
- ステップ 3: テレメトリ収集開始
- ステップ 4: 監視/アラート
【各ステップの理由】
- ステップ 1 リソースデプロイ: Azure Monitor for SAP のモニターリソースを作成します。
- ステップ 2 プロバイダー追加: 監視対象 (HANA/OS/NetWeaver) のプロバイダーを登録します。
- ステップ 3 テレメトリ収集開始: 接続情報/資格情報を設定しメトリクス収集を開始します。
- ステップ 4 監視/アラート: ブックとアラートで状態を可視化し通知します。
【誤った順序の問題点】
- プロバイダー追加をリソースデプロイ前に行う: モニターリソースがないとプロバイダーを追加できません。
- アラートを最初に設定: 収集データがないとアラートが機能しません。
【参考】
AZ120-MIG#4
HANA Large Instances (HLI) から Azure VM への HANA 移行に向けて VM サイジングを行います。要件を満たす設計として正しいものを 2 つ選択してください。
2 つ選択してください
解説
【正解: A / B】の理由
HLI→VM 移行では、対象 HANA のメモリ/CPU 要件を満たす大容量メモリ VM (Mv2、M シリーズ等) を選定し (a)、その VM が SAP/HANA 用に認定されている (SAP がサポートする SKU) ことを確認します (b)。これが認定済みかつ性能要件を満たすサイジングです。
【他選択肢が違う理由】
- C: B シリーズはバースト型の小規模 VM で、HANA のメモリ/性能要件と認定要件を満たしません。
- D: HLI は新規提供が縮小・終了方向のため、移行先として追加発注するのは方針に反します。
- E: HANA を SQL Server へ変換する必要はなく、HANA のまま VM へ移すのが目的です。
【参考】
AZ120-MIG#5
各 SAP 移行ツールを主なユースケースにマッチさせてください。
項目（ドラッグしてください）
- DMO (SUM)
- SWPM
- R3load
- Azure Migrate
DB 移行+HANA 化を 1 手順で
DB/プラットフォーム変更を伴う移行
IaaS への評価/リホスト
解説
【正しいマッチング完全版】
※ DMO は移行+HANA 化を 1 手順で、SWPM/R3load はヘテロジニアス (DB/プラットフォーム変更) 移行、Azure Migrate は評価/リホストに使います。
- DMO (SUM) → DB 移行+HANA 化を 1 手順で
- SWPM → DB/プラットフォーム変更を伴う移行
- R3load → DB/プラットフォーム変更を伴う移行
- Azure Migrate → IaaS への評価/リホスト
【正解マッチング】
| 項目 | カテゴリ |
|---|---|
| DMO | DB 移行+HANA 化を 1 手順で |
| SWPM | DB/プラットフォーム変更を伴う移行 |
| R3load | DB/プラットフォーム変更を伴う移行 |
| Azure Migrate | IaaS への評価/リホスト |