JA
English
Deutsch
Español
Français
Italiano
Português
Nederlands
Polski
Bahasa Indonesia
Русский
Українська
العربية
עברית
한국어Azure meets SAP：Microsoft Teams で解説する SAP on Azure
By Mirko Peters ·
Azure で SAP を稼働させることの実態：認定済みの仮想マシンとストレージ、最初に構築するランディングゾーン、ハイブリッド接続、3 つのデプロイメント方式、そしてサポート対象の SAP システムをサポート対象外にしてしまう失敗例を解説します。
Automatically translated with AI from the original post. Read the English original
Microsoft MVP として、私は Azure、Entra ID、Microsoft 365 を熟知している方々と多くの時間を過ごしていますが、そうした方々が突然「SAP の移行をサポートする」よう求められるケースが少なくありません。多くの人にとって SAP は、独自の用語を持つ別世界のように感じられます。しかし、良いニュースがあります。SAP on Azure は、想像よりもはるかに普通のものです。ポイントは 2 つのルールに集約されます。認定された構成の範囲内にとどまること、そして最初の SAP システムを載せる前に基盤を構築することです。本記事では、実際の作業順序に沿って両方を解説します。
SAP on Azure とは実際には何か
SAP on Azure とは、SAP システムを Microsoft Azure 上で稼働させることを意味します。SAP HANA データベース、アプリケーション サーバー、中央サービスは、Azure の仮想マシン上に配置され、Azure のストレージとネットワークを利用します。SAP ソフトウェアそのものは変わりません。SAP S/4HANA は依然として S/4HANA であり、SAP NetWeaver は依然として NetWeaver です。変わるのは、その土台だけです。
この分担により、それぞれの責任範囲が明確になります。Microsoft は、仮想マシン、ディスク、ネットワーク、ID、監視といったプラットフォームを提供します。SAP はアプリケーションとデータベースを提供し、SAP が想定する方法で運用するのはお客様です。両者が交わる部分が、中間にある認定済みインフラストラクチャです。
ここで、関連する別のテーマと切り分けておくと役立ちます。Power BI や Microsoft Fabric でのレポート用に SAP データを Azure にコピーすることは、データ統合であり、有用ではあるものの別の作業です。Azure で SAP を稼働させるとは、本番システムそのものをそこに置き、そこでトランザクションを処理し、そこからユーザーにサービスを提供することを意味します。
まず SAP 製品ファミリー全体像を把握したい場合は、M365.FM の SAP トピックページに、関連コンテンツをまとめています。
すべてを決める「認定」
SAP の世界では、「Azure 上で稼働する」は実際には「認定された Azure 上で稼働する」という意味です。SAP と Microsoft は、特定の仮想マシンの種類とストレージ オプションを、特定の SAP 製品とシナリオに対してテストしており、サポートされるのはその組み合わせだけです。Microsoft は Azure 向けの SAP 認定と構成および Azure でサポートされる SAP ソフトウェアを文書化しています。SAP HANA については、SAP 自身の HANA Hardware Directory が正式な一覧です。NetWeaver ベースのシステムについては、SAP Note 1928533 にサポートされる Azure VM の種類が記載されています。
認定は Azure 全体の特性ではありません。特定の VM、特定のストレージ オプション、特定の SAP シナリオが組み合わさって初めて成立するものです。Web アプリケーションには最適な大型 VM であっても、HANA では一覧に含まれていないことがあります。それでもその VM を選んだ場合、コストを節約したことにはなりません。どちらのベンダーも責任を負えないシステムを構築してしまったことになるのです。
ストレージも同じ考え方で選びます。Azure マネージド ディスクは日常的に使う基本の構成要素です。Azure NetApp Files は NFS ストレージを提供し、複数の SAP アーキテクチャで使われています。Premium (SSD) の Azure Files は共有ディレクトリのホストに使えます。一方、Azure Files の低コストな Standard 階層は、SAP セントラル サービスの高可用性共有には対応していません。そのため、この場面では安いほうを選ぶと誤った選択になります。Microsoft はこうした制約を、Azure VM 上の SAP ワークロードでサポートされるシナリオにまとめています。
多くのトラブルを防ぐ習慣は次のとおりです。マシンのサイズを決める前に、使用する SAP 製品とシナリオの認定一覧を確認し、その内容に沿って設計することです。
最初に構築するランディング ゾーン
Azure ランディング ゾーンは、ワークロードを配置する前に、各ワークロードのアイデンティティ、ネットワーク、セキュリティ、ガバナンスを提供する基盤です。Microsoft のクラウド導入フレームワークでは、これを次の 2 つに分けています。
- プラットフォーム ランディング ゾーン: 管理グループ、中央の接続、ID、セキュリティ、管理サービスを含む共有基盤です。
- アプリケーション (ワークロード) ランディング ゾーン: 開発、テスト、本番などの個別環境です。各環境はサブスクリプションで構成され、プラットフォームのガードレールを継承します。
SAP では、この点がほかの多くのワークロードより重要です。SAP は財務、サプライ チェーン、業務運用を担うため、最初の SAP システムを配置する前に、ポリシー、ネットワーク ルール、ID を整えておく必要があります。後から追加すると、稼働中の基幹システムのリソースを移動することになります。
Microsoft は、ハブ アンド スポーク型または Azure Virtual WAN のネットワーク トポロジに基づく参照設計を含む、SAP on Azure ランディング ゾーン アクセラレーターを提供しています。Azure Policy と管理グループの階層がガードレールを定め、すべての SAP システムはその内側に配置されます。これにより、2 つ目、3 つ目の SAP システムを追加するたびに、命名規則、アクセス許可、ネットワーク ルールを一から議論し直す必要がなくなります。
SAP をデータ センターと接続したままにする
SAP を Azure に移行しても、すべてを残さず移行することはまれです。多くのランドスケープは長期間ハイブリッドのまま運用されるため、接続はそれらをつなぐ橋渡しの役割を果たします。
主なプライベート接続の選択肢は Azure ExpressRoute です。これは、データ センターと Azure の間を公衆インターネット経由ではなく専用のプライベート接続で結ぶものです。ExpressRoute が利用できない場合は、サイト間 VPN が代替手段になります。いずれの場合も、接続は通常、中央のハブまたは Virtual WAN で終端し、SAP 仮想ネットワークはそこから接続先に到達します。Azure 内では、一般的な SAP の設計として、アプリケーション層とデータベース層を別々のサブネットに分け、ネットワーク セキュリティ グループ、ルート テーブル、ファイアウォールで保護します。
ID は慎重に確認する必要があります。ここは Microsoft のチームが前提を置きがちな部分だからです。Microsoft Entra ID は、SAP アプリケーションへのシングル サインオンに優れています。ただし、Windows 上で稼働する SAP NetWeaver と S/4HANA のシステムでは、SAP アプリケーション自体に Entra ID アカウントを使用しません。これらのシステムは依然として Active Directory Domain Services を必要とします。これはオンプレミスから拡張したものでも、Microsoft Entra Domain Services が提供するものでもかまいません。サインオンとオペレーティング システムのディレクトリは、別々の問題です。
3 つのデプロイ オプション
Azure への SAP のデプロイには、唯一の正解はありません。チームの運用方法に合った経路を選んでください。
- 通常の Azure 仮想マシン。 オペレーティング システム、SAP のインストール、パッチ適用、監視をすべて自分で管理します。制御は最大になりますが、作業量も最大になります。SAP と Azure の高度なスキルを社内に持つ場合に適しています。
- Azure Center for SAP solutions。 SAP をトップレベルのワークロードとして扱えるようにする Azure サービスです。単一サーバー構成、分散構成、分散高可用性構成の SAP システムについて、インフラストラクチャの作成と SAP ソフトウェアのインストールを行えます。また、Azure 上で既に稼働している SAP システムを登録することもできます。各システムは Virtual Instance for SAP solutions として表示されます。これは SID、中央サービス、データベース、アプリケーションサーバーを論理的にまとめたビューです。ここから、正常性と状態の確認、システムの起動と停止、ベストプラクティスに基づく品質チェックの実行、監視データの確認ができます。詳細は Azure Center for SAP solutions の概要を参照してください。
- SAP on Azure deployment automation framework。 再現性があり、バージョン管理されたデプロイと DevOps ワークフローを求めるチーム向けの、オープンソースの Infrastructure as Code アプローチです。
判断の目安は次のとおりです。完全な制御と高度なスキルがあるなら、通常の仮想マシンが適しています。一つの場所でシステムを管理できる、ガイド付きのセットアップが必要なら、Azure Center for SAP solutions が適しています。同じ方法で多数のシステムをデプロイするなら、automation framework が適しています。
よくある間違い
初回の移行で苦労するケースの多くには共通パターンがあります。それは、省略しても良さそうに思えた一つのステップです。
- 認定を形式的な手続きとみなす。 認定されていない仮想マシンやストレージの種類を使うと、サポート対象のシステムがサポート対象外になります。そして、たいてい最悪のタイミングで発覚します。
- ランディングゾーンを省略する。「ガバナンスは後で追加する」という計画が実行されることはまれです。稼働中の SAP システムの周囲で ID とネットワークのルールを後から組み込むのは、時間がかかり、リスクも高くなります。
- Windows ベースの SAP システムで、Entra ID が Active Directory を置き換えると考える。 置き換えることはありません。
- 接続性の設計を最後に回す。 SAP のアプリケーション層とデータベース層を、オンプレミスと Azure の間で分割する、または Azure リージョンをまたいで分割する構成はサポートされていません。
- すべてが Azure 上で動くと考える。 Azure VMware Solution は、一般的に SAP ワークロードをホストするためのサポート対象プラットフォームではありません。また、SAP HANA Large Instances は新規のお客様には提供されなくなりました。
- データベースに Azure Site Recovery を使う。 Azure Site Recovery は SAP のデータベース層ではサポートされていません。災害復旧には、SAP HANA System Replication などのデータベース独自のレプリケーション機能を使用してください。
これらはいずれも、Microsoft と SAP のサポート範囲が一致しなくなるポイントです。これらの制限はあなたの作業を遅らせるためのものではありません。両社がシステムを支える範囲を示すための線引きです。
結論: 作業の順序
一つだけ覚えるなら、この順序を覚えてください。まず、SAP システムに必要なパフォーマンス、可用性、復旧の要件を定義します。次に、ランディングゾーンを構築します。ネットワークとディレクトリをデータセンターまで接続します。どの程度マネージドにするかを選びます。通常の仮想マシン、Azure Center for SAP solutions、automation framework のいずれかです。認定されたコンピュートとストレージを選択します。最後に、データベース自体の機能を前提に、高可用性と災害復旧を設計します。
すべてを一度に移行する必要はありません。まず一つのシステムから始めると、影響がまだ小さいうちに、ランディングゾーンのどこが脆弱か、チームのどこに支援が必要かが分かります。Microsoft の専門家にとって、Azure 上の SAP は未知の世界ではありません。通常のエンジニアリング上の判断の集まりです。ただし、認定だけは決して曲げてはならない唯一のルールです。