WEB問題集
ある企業が、AnyDB (Oracle) 上で稼働する SAP ERP 6.0 (SAP NetWeaver) を、現行の OS・データベース・SAP カーネルバージョンを一切変更せずに、可能な限り短期間かつ低リスクで Azure へ移行したいと考えています。最も適した移行戦略はどれですか?
解説
【正解: C】の理由
Lift & Shift (Re-host) は、OS・データベース (AnyDB)・SAP アプリケーションおよびカーネルを変更せず、稼働中のシステムをそのまま Azure IaaS の仮想マシンへ移設する移行戦略です。SAP ERP 6.0 (NetWeaver) を Oracle のまま持ち込めるため、アプリケーションの再テスト範囲が最小で済み、DMO や再実装のような大掛かりな変換作業が不要です。結果として移行期間が短く、コストとリスクも低く抑えられ、「現行の OS・DB・カーネルを一切変更しない・短期・低リスク」という要件すべてに最も合致します。移行後に HANA 化などの近代化を段階的に進めることもできます。
【他選択肢が違う理由】
- A: Re-architect (S/4HANA Greenfield) は業務プロセスを再設計して新規実装する大規模プロジェクトで、短期・低リスクの要件に合いません。
- B: Retire はシステム自体を廃止する戦略で、現行 SAP を Azure で継続稼働させたいという目的には該当しません。
- D: Re-platform は移行と同時に DB を SAP HANA へ変換 (DMO) する戦略で、「DB を変更しない」という要件に反します。
【参考】
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 イメージ
|
|
|
--size: HANA 認定 VM サイズ
|
|
|
--zone: 可用性ゾーン番号
|
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| --image: SAP 認定 OS イメージ | SUSE:sles-sap-15-sp5:gen2 |
| --size: HANA 認定 VM サイズ | Standard_M128ms |
| --zone: 可用性ゾーン番号 | 1 |
【ポイント】
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 イメージです。M シリーズ (Mv1/Mv2) は大容量メモリを持つ SAP HANA 認定 VM です。Standard_M128ms は HANA OLTP/OLAP の本番に使えます。可用性ゾーンを指定すると物理的に分離した障害ドメインに配置でき、SLA と HA を高められます。
【参考】
移行後に Azure Monitor for SAP solutions を有効化する手順を順序通りに並べてください。
- プロバイダー (HANA DB / OS / SAP NetWeaver) を追加
- 接続情報/資格情報を構成しテレメトリ収集を開始
- ブック/アラートでパフォーマンスと可用性を監視
- Azure Monitor for SAP リソースをデプロイ
解説
【正しい順序】
- Azure Monitor for SAP リソースをデプロイ
- プロバイダー (HANA DB / OS / SAP NetWeaver) を追加
- 接続情報/資格情報を構成しテレメトリ収集を開始
- ブック/アラートでパフォーマンスと可用性を監視
【ポイント】
- ステップ 1 リソースデプロイ: Azure Monitor for SAP のモニターリソースを作成します。
- ステップ 2 プロバイダー追加: 監視対象 (HANA/OS/NetWeaver) のプロバイダーを登録します。
- ステップ 3 テレメトリ収集開始: 接続情報/資格情報を設定しメトリクス収集を開始します。
- ステップ 4 監視/アラート: ブックとアラートで状態を可視化し通知します。
【誤った順序の問題点】
- プロバイダー追加をリソースデプロイ前に行う: モニターリソースがないとプロバイダーを追加できません。
- アラートを最初に設定: 収集データがないとアラートが機能しません。
【参考】
解説
【正解: A / C】の理由
HANA Large Instances (HLI) から Azure VM への移行では、まず対象 HANA システムのメモリと CPU の要件を正確に見積もり、それを満たす大容量メモリ VM (Mv2 や M シリーズなど) を選定することが出発点になります (C)。SAP HANA はインメモリ DB のため、稼働中データセットとワークエリアを収容できる十分な物理メモリを持つ SKU でなければ性能も安定稼働も得られません。さらに、選定した VM が SAP/HANA 用に認定されている (SAP Note 1928533 の認定 SKU リストに掲載されている) ことを必ず確認します (A)。Azure の VM でも SAP のサポート対象は認定済み SKU に限られるため、この確認を怠るとサポート外構成になります。要件充足と認定確認の両輪が正しいサイジング設計です。
【他選択肢が違う理由】
- B: HANA を SQL Server へ変換してから VM に載せる必要はなく、移行の目的は HANA を HANA のまま Azure VM 上で稼働させることであり、DB 種別の変換は要件に含まれません。
- D: HLI を移行先として新規追加発注する案は、VM への移行という設計方針に反するうえ、HLI は新規提供が縮小方向にあり、対象の移行先として妥当ではありません。
- E: メモリ要件を無視して最も安価な B シリーズ VM を選ぶと、バースト型で恒常性能が低く HANA のメモリ・性能要件も認定要件も満たせず、本番 HANA には使用できません。
【参考】
各 SAP 移行ツールを主なユースケースにマッチさせてください。
- R3load
- Azure Migrate
- SWPM
- DMO (SUM)
解説
【正解マッチング】
| 項目 | 説明 |
|---|---|
| DMO (SUM) | DB 移行+HANA 化を 1 手順で |
| SWPM | DB/プラットフォーム変更を伴う移行 |
| R3load | DB/プラットフォーム変更を伴う移行 |
| Azure Migrate | IaaS への評価/リホスト |
【ポイント】
SAP 移行では目的に応じて専用ツールを使い分ける。DMO (Database Migration Option、SUM=Software Update Manager の一機能) は SAP システムのアップグレードと anyDB から HANA へのデータベース変換を単一の手順に統合でき、ダウンタイムを抑えつつ HANA 化できるため「DB 移行+HANA 化を 1 手順で」に対応する。SWPM (Software Provisioning Manager) はエクスポート/インポートを制御して DB やプラットフォームの変更を伴うシステムコピー・移行を実行するツールであり「DB/プラットフォーム変更を伴う移行」に該当する。R3load は SWPM が内部で呼び出す実体で、DB 固有形式に依存しない中間ファイルへデータをアンロード/ロードして異種 DB へ移せるため、同じく「DB/プラットフォーム変更を伴う移行」に対応する。Azure Migrate はオンプレミス環境の検出・評価 (アセスメント) と VM のリホスト (lift-and-shift) を支援するサービスで、SAP アプリ内部を変換せず IaaS へそのまま移すため「IaaS への評価/リホスト」に位置づけられる。移行の目的が HANA 化か、DB 変更か、単純なリホストかでツールを選択することが要点となる。