SAP on Azure: お客様およびパートナー様向け更新の概要 (2017 年 4 月)
執筆者: Cameron (MSFT SAP Program Manager)
このポストは、2017 年 5 月 4 日に投稿された SAP on Azure: General Update for Customers & Partners April 2017 の翻訳です。
SAP とマイクロソフトは、引き続き Azure クラウド プラットフォームに新機能を追加しています。Azure クラウド プラットフォームの目標は、オンプレミス ソリューションと同等のパフォーマンス、製品出荷マトリクス、可用性を実現し、さらにクラウド固有の柔軟性を提供することです。このブログでは、この数か月の更新、修正、機能強化、推奨ベスト プラクティスをまとめてご紹介します。
1. Azure 上での複数の SQL Server 可用性グループ
Azure プラットフォームでは、Linux 、 Windows いずれの高可用性ソリューションでも、クラスタリングをサポートするために Internal Load Balancer (ILB) が必要になります。
以前は、ILB ごとに IP アドレスは1つだけという制限がありました。この制限は解消され、現在は 1 つの ILB で最大 30 個の IP アドレスの負荷分散を行うことができるようになりました。また、ポート ルールは 1 つの ILB につき最大 150 個という制限があります。
これにより、オンプレミス での導入と同じように、複数の AlwaysOn リスナーを 2 つ以上のクラスター ノードに統合できます。
この構成をデプロイする前に、詳細な構成図を作成し、以下のリソース計画を策定することを強くお勧めします。
a. Premium Disk の設計、SQL データ ファイルの数、NTFS フォーマットのサイズ、SQL データファイルのAzure BLOB ストレージへの直接保存機能を使用するかどうか
b. クラスターのクォーラム モデルと投票
c. 物理および仮想ホスト名と IP アドレス
d. AlwaysOn レプリカ構成 (自動フェールオーバー ノード、同期・非同期レプリカなど)
e. 各可用性グループで SQL Server AlwaysOn リスナーが使用するポートの文書化
| IP アドレス名 | IP アドレス番号 | ホスト名 | ポート | プローブ ポート | 説明 |
| Host1 – 物理 IP | xx.xx.xx.10 | Host1 | SQL Node 1 用の IP | ||
| Host2 – 物理 IP | xx.xx.xx.11 | Host2 | SQL Node 2 用のIP | ||
| Host3 – 物理 IP | yy.yy.yy.12 | Host3 | DR DC の SQL Node 3 用の IP | ||
| SQL Listener 1 の仮想 IP | xx.xx.xx.100 | SAPDB1 | 56000 | 59998 | プライマリ DC の SQL AG #1 用クラスターによって作成された仮想 IP (ILB に割り当てる) |
| SQL Listener 2 の仮想 IP | xx.xx.xx.101 | SAPDB2 | 56001 | 59999 | プライマリ DC の SQL AG #2 用クラスターによって作成された仮想 IP (ILB に割り当てる) |
| Windows クラスターの仮想 IP | xx.xx.xx.1 | SAPCLUDB1 | プライマリ DC の内部クラスターの仮想 IP (ILB に割り当てない) | ||
| SQL Listener 1 の仮想 IP | yy.yy.yy.100 | SAPDB1 | 56000 | DR DC の SQL AG #1 用クラスターによって作成された仮想 IP (ILB に割り当てる) | |
| SQL Listener 2 の仮想 IP | yy.yy.yy.101 | SAPDB2 | 56001 | DR DC の SQL AG #1 用クラスターによって作成された仮想 IP (ILB に割り当てる) | |
| Windows クラスターの仮想 IP | yy.yy.yy.1 | SAPCLUDB1 | DR DC の内部クラスターの仮想 IP (ILB に割り当てない) |
入念な計画策定後、以下のリンクから ILB 構成用 PowerShell スクリプトを入手できます。
注: この構成では、SQL Server の最大メモリ パラメーターを設定することが推奨されます。また、この構成では、Direct Server Return (ポータルでの名称は Floating IP) を有効にすることも推奨されます。他の DBMS でも、複数のインスタンスを単一の VM に統合する同様の機能を利用できます。プローブ ポートは ILB ごとに一意である必要がありますが、同じプローブ ポート番号は別の ILB で再利用できます。
2. Azure のクラスター上の複数 ASCS
複数の ASCS クラスターを単一のクラスターに統合することができます。この Multi-SID 構成の詳細については、こちらのドキュメントを参照してください。
ASCS を構成する PowerShell スクリプトを実行する前に、ソリューションの計画を策定し、文書化しておくことが重要です。
注: このシナリオでは、同一のポート (445) が複数のフロントエンド IP アドレスで共有されるため、Direct Server Return を有効にする必要があります。「Direct Server Return」は PowerShell における用語です。Azure ポータルでは「Floating IP」と呼ばれます。
| IP アドレス名 | IP アドレス番号 | ホスト名 | ポート | プローブ ポート | 説明 |
| Host1 – 物理 IP | xx.xx.xx.20 | Host1 | ASCS Node 1 用の IP | ||
| Host2 – 物理 IP | xx.xx.xx.21 | Host2 | ASCS Node 2 用の IP | ||
| Host3 – 物理 IP | yy.yy.yy.22 | Host3 | DR DC の ASCS Node 3 用の IP | ||
| ECC ASCS の仮想 IP | xx.xx.xx.200 | SAPECC | 3200、3300、3600 | 59998 | プライマリ DC の ECC ASCS 用クラスターによって作成された仮想 IP (ILB に割り当てる) |
| BW ASCS の仮想 IP | xx.xx.xx.201 | SAPBW | 3201、3301、3601 | 59999 | プライマリ DC の BW ASCS 用クラスターによって作成された仮想 IP (ILB に割り当てる) |
| Windows クラスターの仮想 IP | xx.xx.xx.2 | SAPCLUSAP1 | プライマリ DC の内部クラスターの仮想 IP (ILB に割り当てない) | ||
| ECC ASCS の仮想 IP | yy.yy.yy.200 | SAPECC | 3200、3300、3600 | DR DC の ECC ASCS 用クラスターによって作成された仮想 IP (ILB に割り当てる) | |
| BW ASCS の仮想 IP | yy.yy.yy.201 | SAPBW | 3201、3301、3601 | DR DC の BW ASCS 用クラスターによって作成された仮想 IP (ILB に割り当てる) | |
| Windows クラスターの仮想 IP | yy.yy.yy.2 | SAPCLUSAP1 | DR DC の内部クラスターの仮想 IP (ILB に割り当てない) |
SAP ASCS on Azure に関するチェックリスト
1. ILB のタイムアウトが 30 分に設定されていることを確認します (これは、PowerShell スクリプトの既定値です)。
2. default.pfl でenque/encni/set_so_keepalive パラメーターが TRUEに設定されていることを確認します。
3. Windows で、TCP/IP レジストリ値の KeepAliveTime と KeepAliveInterval を 180000 (3 分) に設定します。
1593183 – TCP/IP networking parameters for SQL Server https://launchpad.support.sap.com/#/notes/1593183/E
4. プローブ ポートを選択します (通常は、59999)。
5. Windows クラスターのタイムアウトを設定します。
PowerShell の場合
$cluster = Get-Cluster; $cluster.CrossSubnetDelay = 1500
$cluster = Get-Cluster; $cluster.SameSubnetThreshold = 10
$cluster = Get-Cluster; $cluster.CrossSubnetDelay = 1500
$cluster = Get-Cluster; $cluster.CrossSubnetThreshold = 20
クラスター コマンドの場合
cluster /cluster:<クラスター名> /prop SameSubnetDelay=1500
cluster /cluster:<クラスター名> /prop SameSubnetThreshold=10
cluster /cluster:<クラスター名> /prop CrossSubnetDelay=1500
cluster /cluster:<クラスター名> /prop CrossSubnetThreshold=20
Windows 2016 では、既定値が正しい値に設定されています。
6. SUSE での HA のセットアップと構成については、今後のブログ記事で説明する予定です。
SAP Note 1634991 – How to install (A)SCS instance on more than 2 cluster nodes https://launchpad.support.sap.com/#/notes/0001634991
3. 内部クラスターの仮想 IP アドレスを Azure Internal Load Balancer (ILB) に割り当てる必要性
Windows クラスターには、独自の内部仮想 IP アドレスと仮想ホスト名があります。これらのリソースは各クラスターの運用に必要ですが、この内部クラスターの仮想 IP アドレスを Azure Internal Load Balancer (ILB) のフロントエンド IP アドレスとして追加する必要はありません。
クラスターの仮想 IP アドレスを ILB に追加することは必須ではありませんが、任意で追加してもかまいません。
4. Azure 関連の便利な PowerShell コマンド
SAP システムの Azure への大規模なデプロイでは、PowerShell の基本的な知識が必要となります。
ほぼすべての操作が Azure ポータルでも実行できるものの、PowerShell スクリプトを使用する方が早く、簡単で、繰り返しで実行できます。
Azure PowerShell コマンドレットを設定する方法は以下のとおりです。
PowerShell を管理者として実行し、AzureRM PowerShell コマンドレットをインストールします。
https://msdn.microsoft.com/ja-jp/library/mt125356.aspx
Windows 10 ベースのコンソールでは、PowerShell を管理者としてオープンし、以下を実行します。
PS C:\> Install-Module AzureRM
PS C:\> Install-AzureRM
Azure 管理者から提供されたアカウントを使用してログインします。通常、このアカウントの形式は username@domain.com です。
Login-AzureRmAccount
使用可能な Azure サブスクリプションの一覧を表示します。
Get-AzureRmSubscription
Set-AzureRmContext -SubscriptionName "<subscription name goes here>"
https://docs.microsoft.com/en-us/powershell/#pivot=main&panel=getstarted (英語)
/ja-jp/powershell/azure/overview?view=azurermps-3.7.0
5. SAP HANA on Azure – Virtual Machines
Azure VM GS5 でのOLAPワークロードでのSAP HANAの運用稼働は認定済みです。この VM では、SAP BW on HANA や類似のアプリケーションを運用環境で実行できます。
2017 年 4 月時点では、GS5上での運用環境の OLTP ワークロード実行は一般提供段階ではありません。
GS5 VM は、非運用環境においてはSuite on HANA、BW on HANA、S/4HANAのすべてのワークロードについて認定済みです。
https://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/iaas.html (英語)
SAP HANA アプリケーションを Azure GS5 VM にインストールする詳細な方法については、以下を参照してください。
/ja-jp/azure/virtual-machines/workloads/sap/get-started
1928533 – SAP Applications on Azure: Supported Products and Azure VM types https://launchpad.support.sap.com/#/notes/1928533
2015553 – SAP on Microsoft Azure: Support prerequisites
https://launchpad.support.sap.com/#/notes/2015553
6. SAP HANA on Azure (ラージ インスタンス)
大規模な HANA を運用している大企業顧客の場合、大規模BW on HANA または Suite on HANA実行と、1 年～ 3 年間の DB の増大に対応するために、2 TB 以上の RAM が必要となることがあります。Azure プラットフォームではこのようなシナリオに対応するために、Intel E7 Haswell または Broadwell プロセッサベースの以下の ラージインスタンスを提供しています。
- SAP HANA on Azure S72 (2 ソケット、768 GB)
- SAP HANA on Azure S72m (2 ソケット、1.5 TB)
- SAP HANA on Azure S192 (4 ソケット、2.0 TB)
- SAP HANA on Azure S192m (4 ソケット、4.0 TB)
- OLAP と OLTP (BWoH、SoH、S/4H など) のすべてのユース ケースをサポート
- 運用環境と非運用環境
- 「SAP HANA on Azure S144 (4 ソケット、1.5 TB)」と「SAP HANA on Azure S192 (4 ソケット、2.0 TB)」では、最大 15 + 1 ノード (アクティブ ノード x 15 (BW: 1 マスター、14 ワーカー) とスタンバイ ノード x 1) のスケールアウト構成が可能
HANA on Azure (ラージインスタンス) に関してよく寄せられる質問
Q1. ラージインスタンスは VM ですか。ベア メタルですか。A. ベア メタルの HANA TDI 認定アプライアンスです。
Q2. どのような HA/DR ソリューションがサポートされますか。A. HSR とストレージ レベルのレプリケーションの両方が可能です。
Q3. HANA on Azure (ラージインスタンス) を注文する方法とプロビジョニングする方法を教えてください。A. マイクロソフト アカウント チームまでご連絡ください。
Q4. Azure の毎月の請求料金に含まれる項目を教えてください。A. すべてのコンピューティング料金、HANA RAM の 4 倍に相当する高速ストレージ、SAP アプリケーション サーバー VM と HANA アプライアンス間のネットワーク料金、ストレージ ベース レプリケーション (DR ソリューションを別の Azure DR ピア データセンターにレプリケートする場合) のネットワーク使用量が含まれます。
Q5. HANA on Azure (ラージインスタンス) は、より規模の大きいサイズにアップグレードできますか。A. はい。
Q6. MCOS や MDC など、すべての HANA シナリオがサポートされますか。A. はい。一般的に、他の TDI ソリューションで利用可能な機能と同等の機能を HANA on Azure (ラージインスタンス) でも利用できます。
Q7. マイクロソフトは HANA ライセンスの再販を行ったり、HANA のサポートを提供したりしますか。A. いいえ。HANA のライセンスとサポートは SAP から提供されます。マイクロソフトは IaaS (サービスとしてのインフラストラクチャ) のみを提供します。提供される内容は、ハードウェア、ファームウェア、ストレージ、ネットワーク、SUSE for SAP Applications または Redhat の初期インストールです。その後、HANA のインストールは HANA の認定コンサルタントに依頼してください。お客様側で SUSE または Redhat ライセンスを購入し、SUSE または Redhat のサポート契約を締結する必要があります。
Q8. HANA on Azure (ラージインスタンス) の SLA について教えてください。A. 99.99% のSLAが提供されます。詳細については、こちらのページを参照してください。
Q9. マイクロソフトは、HANA ラージインスタンスの SUSE OS または Redhat OS のパッチ適用や保守を行いますか。A. いいえ。HANA ラージインスタンスは IaaS サービスです。OS より下位のレイヤーの管理とサポートをマイクロソフトが行います。
Q10. HANA ラージインスタンスでは、SUSE または Redhat のクラスタリングが完全にサポートされますか。A. はい。
2316233 – AP HANA on Microsoft Azure (Large Instances)
https://launchpad.support.sap.com/#/notes/2316233
リンク:
/ja-jp/azure/virtual-machines/workloads/sap/get-started
ラージインスタンスの HA/DR
バックアップ/リストアに関するガイド
/ja-jp/azure/virtual-machines/workloads/sap/sap-hana-backup-guide
/ja-jp/azure/virtual-machines/workloads/sap/sap-hana-backup-file-level
/ja-jp/azure/virtual-machines/workloads/sap/sap-hana-backup-storage-snapshots
7. Azure リソース グループ: 概要と使用方法
リソース グループは Azure オブジェクトの論理的なコレクションです。リソース グループの特徴は以下のとおりです。
1. グループ内のすべてのリソースは同じライフサイクルを持つ必要があります。すべてのリソースを同時にデプロイ、更新、削除します。
2. デプロイメント サイクルが異なる場合は、別のリソース グループに追加します。
3. 各リソースは 1 つのリソース グループのみに所属します。
4. リソース グループにはいつでもリソースを追加、削除できます。
5. リソースはリソース グループ間で移動できます。詳細については、「新しいリソース グループまたはサブスクリプションへのリソースの移動」を参照してください。
6. リソース グループには複数のリージョンに存在するリソースを含めることができます。
7. リソース グループは管理操作のアクセス制御の対象を定義するために使用できます。
8. リソースは他のリソース グループ内のリソースとやり取りできます。2 つのリソースが関連しているものの、ライフサイクルが異なる場合に一般的です。
SAP BASIS 管理者が疑問に思うのは次の点です。SAP ランドスケープを形成するサンドボックス、開発、検証、運用の各環境のリソース グループをどう構成すべきか。
これまでの顧客の実際の導入でのフィードバックは以下のとおりです。
1. 小規模なサンドボックス システムや開発システムは、リソース グループ１つにまとめることが可能です。小規模なサンドボックス環境または開発環境には、ECC 6.0、BW、SCM、GRC、PI、Solution Manager システムなどが含まれます。
2. 小規模なサンドボックス システムや開発システムでは、共通のストレージ アカウントを使用するか、Managed Disks を使用できます。
3. 非運用環境と運用環境には、1 つまたは多くても数個の VNET を使用します (注: リソース グループ A の VM その他のリソースをリソース グループ B の VNET上にデプロイ可能です)。
4. データセンター内に複数の VNET が存在する場合は、VNET ピアリングを使用してレイテンシを削減します。
5. 運用環境用のデータセンター A のVNETがあり、非運用環境または DR 用のデータセンター B に別のVNET を持つ場合、2 つの VNET 間に VNET 2 VNETゲートウェイをセットアップします。
6. 通常Network Security Groups で、サブネット上の SAP 特有のポート (3200 ～ 3299、3300 ～ 3399、3600 ～ 3699 など) のみを許可するように設定します。SAP ポートの一覧については、こちらのページ (英語) を参照してください。Windows ファイル共有ポート 135、139、445 は通常ブロックします。
7. Managed Disks 導入以前のストレージ アカウントに関するガイダンスの概要は以下のとおりです。
- すべてのケースにおいて、DBMS サーバーや IOPS 要件の高いスタンドアロン エンジン (TREX など) には、Premium Storage の使用が推奨されます。
- 開発システムなどの小規模なシステムでは、1 つのストレージ アカウントを共有できます。
- パフォーマンス テストを実行する大規模な QAS システムでは、環境個別のストレージ アカウントを使用することが理想的です。
- 大規模な運用環境 SAP アプリケーション (ECC、BW など) では、環境個別のストレージ アカウントを使用することが推奨されます。
- IOPS 要件の低い小規模な運用環境システム (Solution Manager、EP、PI、GRC など) では、1 つのストレージ アカウントを共有できます。
Managed Disks の導入以降は、一般的に Managed Disks の使用が推奨されます。
8. お客様によっては、運用環境で各 SAP アプリケーションを個別のリソース グループにデプロイしている場合もあります。
8. Azure Managed Disks
Managed Disks は Azure Storage の新機能です。新規に SAP をデプロイする場合には、Managed Disks を検討することをお勧めします。Managed Disks のメリットについては、こちらのドキュメントを参照してください。
主なメリットは以下のとおりです。
a. 複数のストレージ アカウントを作成してストレージ アカウントをまたがって VHD の負荷分散を行う必要がありません。ディスク数の上限はサブスクリプションごとに 10,000 個です。
b. ストレージ レベルの高可用性を確保するために特定の VHD を異なるストレージ スタンプに手動で固定する必要がありません (AlwaysOn クラスター ノードなど)。
c. Azure Backup と統合されています。
注: Azure Managed Disks では、ポート 8443 の開放が要求されます。
https://azure.microsoft.com/ja-jp/services/managed-disks/
/ja-jp/azure/storage/storage-managed-disks-overview
https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/
9. Azure のネットワーク レイテンシ
Azure データセンターは、他のどのクラウド プラットフォームよりも多数のリージョンに分散されています。各 Azure データセンターから世界各地の大半のリージョンへのネットワーク レイテンシは、SAP アプリケーションを実行する場合に十分に許容されるレベルです。
SAP を Azure にデプロイする前に、お客様のオフィスから距離的に近い Azure データセンターへのネットワーク レイテンシをテストすることをお勧めします。
以下は、シンガポールから https://azurespeed.com/ (英語) を使用したテスト結果です。
このようなテストは、有線接続で実行してください。距離的に近いデータセンターへのレイテンシはRTTで10 ～ 50 ミリ秒、大陸間のレイテンシは 100 ～ 250 ミリ秒になります。
この範囲を大幅に超える場合は、ISP にルーティングの問題が発生している可能性があります。
10. Azure パブリック クラウド上の SAP アプリケーション サーバー
Azure パブリック クラウドの VM に SAP アプリケーション サーバーをインストールする場合は、以下のデプロイ方法が推奨されます。
a. SAP アプリケーション サーバー用に追加のディスクをプロビジョニングせず、下記のコンポーネントを Windows C: ドライブまたは Linux Root にインストールします。
- ブート
- OS
- /usr/SAP (SAP 実行可能ファイル ディレクトリ)
b. OS ページ ファイルをローカルの一時ディスクに配置します (これは Windows の既定の動作です)。
c. 最新の OS リリースをデプロイします。2017 年 4 月時点では、Windows Server 2016、SUSE 12.2、Redhat 7 です。
d. Linux の FS の種類については、「405827 – Linux: Recommended file systems 」を参照してください。
e. 単一の仮想ネットワーク カードを使用します。SAP LaMa を使用する場合は、2 つ目の仮想ネットワーク カードが推奨されます。
注: いかなる場合でも、SAP アプリケーション サーバーをインターフェイス ファイル用のファイル サーバーとして使用しないでください。インターフェイス ファイルおよび SAP DVD インストール メディア用には専用の管理環境を作成してください。
11. Windows の動的ポートの範囲
Windows Server で使用される動的コールバック ポートは、SAP J2EE ポートと重複する可能性があります。
ポート 50000 ～ 50999 を SAP 用に予約することが推奨されます。
Java インスタンスをインストールしたWindows Server で、以下のコマンドを実行してください。
netsh int ipv4 set dynamicport tcp start=60000 numberofports=5536
netsh int ipv4 show dynamicport tcp
1399935 – Reservation of TCP/UDP ports in Windows https://launchpad.support.sap.com/#/notes/1399935
12. メンテナンス時の SAP アプリケーション サーバーの Autostart の無効化
Autostart の構成により、SAP アプリケーション サーバーの可用性が向上します。Azure コンポーネントで障害が発生し、Azure プラットフォームの自己復旧によって VM を別のノードに移動する場合、アプリケーション サーバーが自動で起動することで、再起動の影響を大幅に軽減できます。
SAP インスタンスの Autostart を設定するには、SAP の default.pfl に Autostart = 1 を追加します。
サポート パック、アップグレード、エンハンスメントパック、カーネル更新などのメンテナンス処理では、既定の動作として SAP システムを自動起動しないことを前提としている場合があります。
そのため、一般的にこのような作業を行う場合はこのプロファイルのパラメーターをコメントアウトすることが推奨されます。
13. DevTest Labs – サンドボックス システムの構築に最適
Azure ポータルの VM プロパティ ページには、VM を自動的にシャットダウンする機能があります。この機能は、サンドボックス システムや、アップグレードまたはサポート パックのテスト用マシンに使用すると非常に便利です。たとえば、BASIS チームがテスト用の大規模な高性能 VM をプロビジョニングする場合に使用すると、使用しない時に VM をシャットダウンしてコストを抑えることができます。HANA は非常に大規模な VM が必要となるため、HANA テスト マシンにはこの機能が特に役立ちます。
https://azure.microsoft.com/ja-jp/services/devtest-lab/
エンド ユーザーや SAP アプリチームおよび ABAP チームがアクセスする SAP システムの場合、自動停止機能に加えて、自動起動機能も設定する必要があります。
これは、以下のような方法で実現できます。
https://clemmblog.azurewebsites.net/start-stop-windows-azure-vms-according-time-schedule/ (英語)
14. ディスク キャッシュと暗号化の設定
Azure ストレージでは、ディスク キャッシュと暗号化に関して複数のオプションが用意されています。
Premium Azure Storage ディスク キャッシュの使用に関する一般的なガイダンス
| Premium ディスクの種類 | 既定のキャッシュ設定 | SAP サーバーの推奨キャッシュ設定 |
| OS ディスク | ReadWrite | ReadWrite |
| データ ディスク - 書き込み中心 | なし | なし (DB トランザクション ログなど) |
| データ ディスク - 読み取り専用 | なし | ReadOnly |
DBMS ディスクや TREX などの SAP システムに ReadWrite ディスク キャッシュ設定を使用しないでください。
暗号化の使用に関する一般的なガイダンス
1. SAP システムのリスク プロファイルを評価し、暗号化が必要かどうかを判断します。
2. Azure プラットフォームでは以下の 2 つのレイヤーで暗号化をサポートします。
- ストレージ アカウント レベル
- ディスク レベル
3. DBMS プラットフォームでも暗号化をサポートします (SQL Server TDE (英語) や HANA の暗号化 (英語) など)。
4. 一般的に、DBMS レベルの暗号化にはバックアップ ファイルも暗号化できるというメリットがあります。バックアップ ファイルはデータ盗難の標的となることがよくあります。
5. 1 つのデバイスに複数の暗号化テクノロジを使用しないことを強くお勧めします (DB レベルの暗号化、ファイル システム レベルの暗号化、暗号化されたストレージ アカウントの併用など)。これにより、パフォーマンスの問題が発生する可能性があります。
6. 推奨される構成は以下のとおりです。
- DB サーバーでは、OS /ブート ディスクの保護のみにディスク暗号化を使用します。DB ファイルとバックアップの保護には、ネイティブの DBMS レベルの暗号化を使用します。
- SAP アプリケーション サーバーでは、OS /ブート ディスクの保護にディスク暗号化を使用します。
注: 一部の DB レベルの暗号化は、VM 全体やすべてのディスクの複製に対して脆弱です。OS /ブート ディスクに Azure Disk Encryption を使用することで、VM 全体の複製を防止できます。
Azure 上の顧客導入事例
オーストラリアの大手エネルギー企業: SAP アプリケーションを最新化して Azure パブリック クラウドに移行 (英語)
PACT: シナジーによる大胆な成長戦略
https://customers.microsoft.com/en-us/story/building-on-synergy-for-a-bold-growth-strategy (英語)
AGL のイノベーション: クラウドによるエネルギーの有効活用
https://customers.microsoft.com/en-us/story/innovation-spotlight-agl-puts-energy-into-action-with (英語)
Coats UK
https://customers.microsoft.com/en-us/story/coats (英語)
The Mosaic Company
https://customers.microsoft.com/en-us/story/mosaicandcapgemini (英語)
このブログでは、近日中に新たな大企業の導入事例やお客様の運用開始事例を紹介する予定です。
第三者の Web サイト、SAP、その他のソースからのコンテンツは、Fair Use (英語) の用途 (批評、論評、報道、教育、学問、研究) に従って複製されています。