SAP ワークロードのための Azure Virtual Machines DBMS デプロイの考慮事項Considerations for Azure Virtual Machines DBMS deployment for SAP workload

このガイドは、Microsoft Azure 上で SAP ソフトウェアを実装およびデプロイする方法に関するドキュメントの一部です。This guide is part of the documentation on how to implement and deploy SAP software on Microsoft Azure. このガイドを読む前に、計画および実装ガイドと、計画ガイドに記載されている記事をお読みください。Before you read this guide, read the Planning and implementation guide and articles the planning guide points you to. このドキュメントでは、Azure のサービスとしてのインフラストラクチャ (IaaS) 機能を使用して Microsoft Azure 仮想マシン (VM) 上で SAP 関連の DBMS システムをデプロイする場合の一般的な側面について説明します。This document covers the generic deployment aspects of SAP-related DBMS systems on Microsoft Azure virtual machines (VMs) by using the Azure infrastructure as a service (IaaS) capabilities.

特定のプラットフォームに SAP ソフトウェアをインストールしてデプロイするときの主要なリソースである SAP インストール ドキュメントと SAP Note を補足する内容となっています。The paper complements the SAP installation documentation and SAP Notes, which represent the primary resources for installations and deployments of SAP software on given platforms.

このドキュメントでは、Azure VM で SAP 関連 DBMS システムを実行する際の考慮事項について説明します。In this document, considerations of running SAP-related DBMS systems in Azure VMs are introduced. この章では、特定の DBMS システムについてはほとんど言及していません。There are few references to specific DBMS systems in this chapter. 特定の DBMS システムについては、このドキュメントの後で説明します。Instead, the specific DBMS systems are handled within this paper, after this document.


このドキュメントでは、次の用語を使用します。Throughout the document, these terms are used:

  • IaaS:サービスとしてのインフラストラクチャ。IaaS: Infrastructure as a service.

  • PaaS:サービスとしてのプラットフォーム。PaaS: Platform as a service.

  • SaaS:サービスとしてのソフトウェア。SaaS: Software as a service.

  • SAP コンポーネント:個々の SAP アプリケーション (ERP Central Component (ECC)、Business Warehouse (BW)、Solution Manager、Enterprise Portal (EP) など)。SAP component: An individual SAP application such as ERP Central Component (ECC), Business Warehouse (BW), Solution Manager, or Enterprise Portal (EP). SAP コンポーネントは、従来の ABAP または Java テクノロジか、Business Objects などの非 NetWeaver ベース アプリケーションに基づいて作成できます。SAP components can be based on traditional ABAP or Java technologies or on a non-NetWeaver-based application such as Business Objects.

  • SAP 環境:開発、品質保証、トレーニング、ディザスター リカバリー、運用など、ビジネス機能を実行するために論理的にグループ化された、1 つまたは複数の SAP コンポーネント。SAP environment: One or more SAP components logically grouped to perform a business function such as development, quality assurance, training, disaster recovery, or production.

  • SAP ランドスケープ:この用語は、お客様の IT 環境内にある SAP 資産全体を指します。SAP landscape: This term refers to the entire SAP assets in a customer's IT landscape. SAP ランドスケープには、運用環境と非運用環境のすべてが含まれます。The SAP landscape includes all production and nonproduction environments.

  • SAP システム:DBMS レイヤーと (SAP ERP 開発システム、SAP Business Warehouse テスト システム、SAP CRM 運用システムなどの) アプリケーション レイヤーの組み合わせ。SAP system: The combination of a DBMS layer and an application layer of, for example, an SAP ERP development system, an SAP Business Warehouse test system, or an SAP CRM production system. Azure のデプロイでは、この 2 つのレイヤーをオンプレミスと Azure に分けることはできません。In Azure deployments, dividing these two layers between on-premises and Azure isn't supported. その結果、SAP システムはオンプレミスか Azure のいずれかにデプロイされます。As a result, an SAP system is either deployed on-premises or it's deployed in Azure. SAP ランドスケープの異なるシステムを Azure またはオンプレミスにデプロイすることはできます。You can deploy the different systems of an SAP landscape in Azure or on-premises. たとえば、SAP CRM の開発システムとテスト システムを Azure にデプロイし、SAP CRM 運用システムをオンプレミスにデプロイすることは可能です。For example, you could deploy the SAP CRM development and test systems in Azure but deploy the SAP CRM production system on-premises.

  • クロスプレミス:オンプレミスのデータ センターと Azure の間で、サイト間接続、マルチサイト接続、または Azure ExpressRoute 接続を利用する Azure サブスクリプションに VM をデプロイするシナリオを指します。Cross-premises: Describes a scenario where VMs are deployed to an Azure subscription that has site-to-site, multisite, or Azure ExpressRoute connectivity between the on-premises data centers and Azure. この種のデプロイは、共通の Azure ドキュメントでもクロスプレミス シナリオとして説明されています。In common Azure documentation, these kinds of deployments are also described as cross-premises scenarios.

    この接続の目的は、オンプレミスのドメイン、オンプレミスの Active Directory およびオンプレミスの DNS を、Azure 内に拡張することです。The reason for the connection is to extend on-premises domains, on-premises Active Directory, and on-premises DNS into Azure. オンプレミスのランドスケープが、サブスクリプションの Azure 資産に拡張されます。The on-premises landscape is extended to the Azure assets of the subscription. この拡張により、VM をオンプレミス ドメインに含めることができます。With this extension, the VMs can be part of the on-premises domain. オンプレミス ドメインのドメイン ユーザーは、サーバーにアクセスし、それらの VM 上でサービスを実行できます (DBMS サービスなど)。Domain users of the on-premises domain can access the servers and run services on those VMs, like DBMS services. オンプレミスにデプロイした VM 間、および Azure にデプロイした VM 間の通信および名前解決は可能です。Communication and name resolution between VMs deployed on-premises and VMs deployed in Azure is possible. これは、Azure 上に SAP 資産をデプロイするために最も一般的に使用されるシナリオです。This scenario is the most common scenario in use to deploy SAP assets on Azure. 詳細については、「VPN ゲートウェイの計画と設計」を参照してください。For more information, see Planning and design for VPN gateway.


SAP システムのクロスプレミス デプロイは、SAP システムを実行する Azure 仮想マシンがオンプレミス ドメインのメンバーとなっていて、運用 SAP システムでサポートされるデプロイです。Cross-premises deployments of SAP systems are where Azure virtual machines that run SAP systems are members of an on-premises domain and are supported for production SAP systems. クロスプレミス構成では、Azure に SAP ランドスケープの一部または全部をデプロイする場合にサポートされます。Cross-premises configurations are supported for deploying parts or complete SAP landscapes into Azure. Azure で完全な SAP ランドスケープを実行する場合でも、これらの VM をオンプレミス ドメインと Active Directory/LDAP の一部に含める必要があります。Even running the complete SAP landscape in Azure requires those VMs to be part of an on-premises domain and Active Directory/LDAP.

ドキュメントの以前のバージョンでは、ハイブリッド IT シナリオについて言及されていました。In previous versions of the documentation, hybrid-IT scenarios were mentioned. "ハイブリッド" という用語は、オンプレミスと Azure の間にクロスプレミス接続があるという事実に基づいています。The term hybrid is rooted in the fact that there's a cross-premises connectivity between on-premises and Azure. このケースでは、ハイブリッドとは Azure の VM がオンプレミス Active Directory の一部であることも意味します。In this case, hybrid also means that the VMs in Azure are part of the on-premises Active Directory.

一部の Microsoft ドキュメントでは、クロスプレミス シナリオについて、特に DBMS 高可用性構成の場合に、少し異なる記述をしています。Some Microsoft documentation describes cross-premises scenarios a bit differently, especially for DBMS high-availability configurations. SAP 関連ドキュメントでは、クロスプレミス シナリオは、要するに、サイト間接続またはプライベート ExpressRoute 接続であり、オンプレミスと Azure の間で分散された SAP ランドスケープです。In the case of the SAP-related documents, the cross-premises scenario boils down to site-to-site or private ExpressRoute connectivity and an SAP landscape that's distributed between on-premises and Azure.


Azure 上の SAP ワークロードに関するさまざまな記事があります。There are other articles available on SAP workload on Azure. Azure 上の SAP ワークロードの作業の開始に関するページをまず確認してから、興味のある領域を選択してください。Start with SAP workload on Azure: Get started and then choose your area of interest.

次の SAP Note は、このドキュメントで扱う領域に関する SAP on Azure に関連したものです。The following SAP Notes are related to SAP on Azure in regard to the area covered in this document.

Note 番号Note number タイトルTitle
19285331928533 SAP applications on Azure: Supported products and Azure VM types (Azure 上の SAP アプリケーション: サポートされる製品と Azure VM の種類)SAP applications on Azure: Supported products and Azure VM types
20155532015553 SAP on Microsoft Azure:Support prerequisites (Microsoft Azure 上の SAP: サポートの前提条件)SAP on Microsoft Azure: Support prerequisites
19993511999351 Troubleshooting enhanced Azure monitoring for SAP (強化された Azure Monitoring for SAP のトラブルシューティング)Troubleshooting enhanced Azure monitoring for SAP
21786322178632 Key monitoring metrics for SAP on Microsoft Azure (Microsoft Azure 上の SAP 用の主要な監視メトリック)Key monitoring metrics for SAP on Microsoft Azure
14096041409604 Virtualization on Windows:Enhanced monitoring (Azure を使用した Linux 上の SAP: 拡張された監視機能)Virtualization on Windows: Enhanced monitoring
21914982191498 SAP on Linux with Azure:Enhanced monitoring (Azure を使用した Linux 上の SAP: 拡張された監視機能)SAP on Linux with Azure: Enhanced monitoring
20396192039619 SAP applications on Microsoft Azure using the Oracle database:Supported products and versions (Oracle データベースを使用した Microsoft Azure 上の SAP アプリケーション: サポートされている製品とバージョン)SAP applications on Microsoft Azure using the Oracle database: Supported products and versions
22330942233094 DB6:SAP applications on Azure using IBM DB2 for Linux, UNIX, and Windows: 関連情報DB6: SAP applications on Azure using IBM DB2 for Linux, UNIX, and Windows: Additional information
22436922243692 Linux on Microsoft Azure (IaaS) VM:SAP license issues (Microsoft Azure (IaaS) VM 上の Linux: SAP ライセンスの問題)Linux on Microsoft Azure (IaaS) VM: SAP license issues
19847871984787 SUSE LINUX Enterprise Server 12:インストールに関する注記SUSE LINUX Enterprise Server 12: Installation notes
20021672002167 Red Hat Enterprise Linux 7.x:インストールとアップグレードRed Hat Enterprise Linux 7.x: Installation and upgrade
20697602069760 Oracle Linux 7.x SAP installation and upgrade (Oracle Linux 7.x SAP のインストールとアップグレード)Oracle Linux 7.x SAP installation and upgrade
15973551597355 Linux のスワップ領域に関する推奨事項Swap-space recommendation for Linux
21718572171857 Oracle Database 12c: File system support on Linux (Oracle Database 11g: Linux でのファイル システムのサポート)Oracle Database 12c: File system support on Linux
11141811114181 Oracle Database 11g: File system support on Linux (Oracle Database 11g: Linux でのファイル システムのサポート)Oracle Database 11g: File system support on Linux

Linux に関するすべての SAP Note については、SAP コミュニティ wiki を参照してください。For information on all the SAP Notes for Linux, see the SAP community wiki.

Microsoft Azure のアーキテクチャと Microsoft Azure 仮想マシンのデプロイおよび操作方法に関する実用的な知識が必要です。You need a working knowledge of Microsoft Azure architecture and how Microsoft Azure virtual machines are deployed and operated. 詳細については、Azure のドキュメントを参照してください。For more information, see Azure documentation.

一般的に、Windows、Linux、および DBMS のインストールと構成は、オンプレミスに設置する仮想マシンまたはベア メタル マシンと本質的に同じです。In general, the Windows, Linux, and DBMS installation and configuration are essentially the same as any virtual machine or bare metal machine you install on-premises. Azure IaaS を使用する場合、アーキテクチャおよびシステム管理の実装の決定については異なる部分があります。There are some architecture and system management implementation decisions that are different when you use Azure IaaS. このドキュメントでは、Azure IaaS を使用する場合に知っておくべき特定のアーキテクチャおよびシステム管理の相違について説明します。This document explains the specific architectural and system management differences to be prepared for when you use Azure IaaS.

RDBMS デプロイ用の VM のストレージ構造Storage structure of a VM for RDBMS deployments

この章に進むにあたって、以下に記載されている情報を読んで理解しておいてください。To follow this chapter, read and understand the information presented in:

この章を読む前に、別の VM シリーズについて把握し、Standard Storage と Premium Storage の違いについて理解しておく必要があります。You need to understand and know about the different VM-Series and the differences between standard and premium storage before you read this chapter.

Azure ブロック ストレージについては、Azure Managed Disks の使用を強くお勧めします。For Azure block storage, the usage of Azure managed disks is highly recommended. Azure Managed Disks の詳細については、Azure VM のマネージド ディスクの概要に関する記事を参照してください。For details about Azure managed disks read the article Introduction to managed disks for Azure VMs.

基本的な構成では、通常、オペレーティング システム、DBMS、および最終的に導入する SAP バイナリとデータベース ファイルとを分けたデプロイ構造にすることをお勧めしています。In a basic configuration, we usually recommend a deployment structure where the operating system, DBMS, and eventual SAP binaries are separate from the database files. 以前の推奨事項を変更する場合は、次の項目に個別の Azure ディスクを使用することをお勧めします。Changing earlier recommendations, we recommend having separate Azure disks for:

  • オペレーティング システム (ベース VHD または OS VHD)The operating system (base VHD or OS VHD)
  • データベース管理システムの実行可能ファイルDatabase management system executables
  • /usr/sap のような SAP 実行可能ファイルSAP executables like /usr/sap

これらのコンポーネントを 3 つの異なる Azure ディスクに分離する構成を使用すると、DBMS または SAP 実行可能ファイルによる過剰なログまたはダンプの書き込みによって OS ディスクのディスク クォータが妨げられないため、回復性が向上します。A configuration that separates these components in three different Azure disks can result in higher resiliency since excessive log or dump writes by the DBMS or SAP executables are not interfering with the disk quotas of the OS disk.

DBMS のデータおよびトランザクションまたは再実行ログ ファイルは、Azure でサポートされているブロック ストレージまたは Azure NetApp Files に格納されます。The DBMS data and transaction/redo log files are stored in Azure supported block storage or Azure NetApp Files. これらは別個のディスクに格納され、元の Azure オペレーティング システム イメージ VM に論理ディスクとして接続されます。They're stored in separate disks and attached as logical disks to the original Azure operating system image VM. Linux のデプロイでは、特に SAP HANA に関して、異なる推奨事項がドキュメント化されています。For Linux deployments, different recommendations are documented, especially for SAP HANA. シナリオに応じたさまざまな種類のストレージの機能とサポートについては、「SAP ワークロードの Azure Storage の種類」を参照してください。Read the article Azure Storage types for SAP workload for the capabilities and the support of the different storage types for your scenario.

ディスクのレイアウトを計画するときは、次の項目間で最適なバランスを取る必要があります。When you plan your disk layout, find the best balance between these items:

  • データ ファイルの数。The number of data files.
  • ファイルが含まれているディスクの数。The number of disks that contain the files.
  • 1 つのディスクまたは NFS 共有の IOPS クォータ。The IOPS quotas of a single disk or NFS share.
  • ディスクまたは NFS 共有ごとのデータ スループット。The data throughput per disk or NFS share.
  • VM サイズに対して追加できるデータ ディスクの数。The number of additional data disks possible per VM size.
  • VM が提供できるストレージまたはネットワークの全体的なスループット。The overall storage or network throughput a VM can provide.
  • さまざまな種類の Azure Storage で考えられる待機時間。The latency different Azure Storage types can provide.
  • VM の SLA。VM SLAs.

Azure によってデータ ディスクまたは NFS 共有ごとに IOPS クォータが適用されます。Azure enforces an IOPS quota per data disk or NFS share. これらのクォータは、別の Azure ブロック ストレージ ソリューションまたは共有でホストされているディスクでは異なります。These quotas are different for disks hosted on the different Azure block storage solutions or shares. また、I/O 待機時間は、これらの異なる種類のストレージ間でも異なります。I/O latency is also different between these different storage types as well.

VM の種類ごとに、接続できるデータ ディスクの数が制限されています。Each of the different VM types has a limited number of data disks that you can attach. もう 1 つの制限は、たとえば Premium Storage を使用できるのは、特定の種類の VM のみであることです。Another restriction is that only certain VM types can use, for example, premium storage. 通常は、CPU とメモリの要件に基づいて、使用する特定の VM の種類を決定します。Typically, you decide to use a certain VM type based on CPU and memory requirements. また、通常、Premium Storage ディスクのディスク数や種類に応じてスケーリングされる IOPS、待ち時間、およびディスク スループットの要件も考慮する必要があります。You also might consider the IOPS, latency, and disk throughput requirements that usually are scaled with the number of disks or the type of premium storage disks. 特に Premium Storage では、各ディスクで実現する必要がある IOPS とスループットの値によってディスクのサイズも決まる場合があります。The number of IOPS and the throughput to be achieved by each disk might dictate disk size, especially with premium storage.


DBMS デプロイの場合は、すべてのデータ、トランザクション ログ、または再実行のファイルに対して、Azure Premium Storage、Ultra ディスク、または Azure NetApp Files ベースの NFS 共有 (SAP HANA 専用) を使用することをお勧めします。For DBMS deployments, we recommend Azure premium storage, Ultra disk or Azure NetApp Files based NFS shares (exclusively for SAP HANA) for any data, transaction log, or redo files. デプロイするシステムが運用環境システムか非運用システムかは重要ではありません。It doesn't matter whether you want to deploy production or nonproduction systems.


Azure の単一 VM の SLA を活用するには、接続されているすべてのディスクの種類が Azure Premium Storage または Azure Ultra ディスクである必要があります。これには、ベース VHD (Azure Premium Storage) が含まれます。To benefit from Azure's single VM SLA, all disks that are attached must be Azure premium storage or Azure Ultra disk type, which includes the base VHD (Azure premium storage).


SAP データベースが配置されているストレージ ハードウェアが、Azure データセンターに隣接して併置されているサードパーティ データセンター内にある場合は、その SAP データベースのメイン データベース ファイル (データ ファイルやログ ファイルなど) をホストすることはできません。Hosting main database files, such as data and log files, of SAP databases on storage hardware that's located in co-located third-party data centers adjacent to Azure data centers isn't supported. Azure VM でホストされているソフトウェア アプライアンスを通じて提供されるストレージも、このユース ケースではサポートされていません。Storage provided through software appliances hosted in Azure VMs, are also not supported for this use case. SAP DBMS ワークロードの場合、SAP データベースのデータおよびトランザクション ログ ファイル用にサポートされるストレージは、一般的にはネイティブ Azure サービスとして表現されるストレージに限られます。For SAP DBMS workloads, only storage that's represented as native Azure service is supported for the data and transaction log files of SAP databases in general. 異なる DBMS では、それぞれ異なる種類の Azure Storage がサポートされる場合があります。Different DBMS might support different Azure storage types. 詳細については、「SAP ワークロードの Azure Storage の種類」の記事を参照してください。For more details check the article Azure Storage types for SAP workload

データベース ファイル、ログおよび再実行ファイルの配置と、使用する Azure Storage の種類は、IOPS、待ち時間、スループットの要件に従って決まります。The placement of the database files and the log and redo files and the type of Azure Storage you use, is defined by IOPS, latency, and throughput requirements. 特に Azure Premium Storage で十分な IOPS を確保するには、複数のディスクを使用するか、大容量の Premium Storage ディスクを使用しなければならない場合があります。Specifically for Azure premium storage to achieve enough IOPS, you might be forced to use multiple disks or use a larger premium storage disk. 複数のディスクを使用する場合は、データ ファイルか、ログおよび redo ファイルが含まれるディスク全体にソフトウェア ストライプを構築します。If you use multiple disks, build a software stripe across the disks that contain the data files or the log and redo files. この場合、結果のストライプ セットでは、基になる Premium Storage ディスクの IOPS およびディスク スループット SLA、または Standard Storage ディスクの達成可能な最大 IOPS が累積的になります。In such cases, the IOPS and the disk throughput SLAs of the underlying premium storage disks or the maximum achievable IOPS of standard storage disks are accumulative for the resulting stripe set.

IOPS の要件が 1 つの VHD で提供可能な容量を超えている場合は、複数の VHD にわたるデータベース ファイルで必要な IOPS の数のバランスを取ります。If your IOPS requirement exceeds what a single VHD can provide, balance the number of IOPS that are needed for the database files across a number of VHDs. IOPS 負荷を複数のディスクに分散する最も簡単な方法は、異なるディスク間でソフトウェア ストライプを構築することです。The easiest way to distribute the IOPS load across disks is to build a software stripe over the different disks. そして、ソフトウェア ストライプから分割した LUN に SAP DBMS のデータ ファイルの数を設定します。Then place a number of data files of the SAP DBMS on the LUNs carved out of the software stripe. ストライプ内のディスクの数は、IOPS の需要、ディスク スループットの需要、およびボリュームの需要によって決まります。The number of disks in the stripe is driven by IOPS demands, disk throughput demands, and volume demands.

Windows ストレージ ストライピング WindowsWindows

Windows 記憶域スペースを使用して複数の Azure VHD にわたってストライプ セットを作成することをお勧めします。We recommend that you use Windows Storage Spaces to create stripe sets across multiple Azure VHDs. Windows Server 2012 R2 または Windows Server 2016 以上を使用してください。Use at least Windows Server 2012 R2 or Windows Server 2016.

Linux ストレージ ストライピング LinuxLinux

Linux 上でのソフトウェア RAID の構築がサポートされているのは、MDADM および論理ボリューム マネージャー (LVM) のみです。Only MDADM and Logical Volume Manager (LVM) are supported to build a software RAID on Linux. 詳細については、次を参照してください。For more information, see:

Azure Ultra ディスクの場合、ディスクのサイズに依存しない IOPS およびディスク スループットを定義できるため、ストライピングは必要ありません。For Azure Ultra disk, striping is not necessary since you can define IOPS and disk throughput independent of the size of the disk.


Azure Storage には VHD の 3 つのイメージが保存されるため、ストライプ化するときに冗長性を構成することには意味がありません。Because Azure Storage keeps three images of the VHDs, it doesn't make sense to configure a redundancy when you stripe. 必要なのは、I/O が異なる VHD に分散されるようにストライピングを構成することだけです。You only need to configure striping so that the I/Os are distributed over the different VHDs.

マネージド ディスクか非マネージド ディスクかManaged or nonmanaged disks

Azure ストレージ アカウントは、管理の構成要素であり、制限の対象でもあります。An Azure storage account is an administrative construct and also a subject of limitations. Standard Storage アカウントと Premium Storage アカウントでは、制限事項が異なります。Limitations differ between standard storage accounts and premium storage accounts. 機能と制限については、Azure Storage のスケーラビリティとパフォーマンスのターゲットに関するページをご覧ください。For information on capabilities and limitations, see Azure Storage scalability and performance targets.

Standard Storage の場合、ストレージ アカウントごとに IOPS の制限があることに注意してください。For standard storage, remember that there's a limit on the IOPS per storage account. Azure Storage のスケーラビリティとパフォーマンスのターゲットに関する記事で、合計要求レート を含む行を参照してください。See the row that contains Total Request Rate in the article Azure Storage scalability and performance targets. Azure サブスクリプションあたりのストレージ アカウント数には初期制限もあります。There's also an initial limit on the number of storage accounts per Azure subscription. 複数のストレージ アカウントにわたる大規模な SAP ランドスケープの場合は、これらのストレージ アカウントの制限に達しないよう、VHD を分散します。Balance VHDs for the larger SAP landscape across different storage accounts to avoid hitting the limits of these storage accounts. 1,000 を超える VHD が搭載された数百台の仮想マシンでこの作業を行うのは困難です。This is tedious work when you're talking about a few hundred virtual machines with more than a thousand VHDs.

SAP ワークロードと共に DBMS デプロイに Standard Storage を使用することはお勧めしません。Using standard storage for DBMS deployments in conjunction with an SAP workload isn't recommended. したがって、Standard Storage の参照と推奨事項は、この短い記事に限定されています。Therefore, references and recommendations to standard storage are limited to this short article

複数の Azure ストレージ アカウントにわたって VHD を計画しデプロイする管理作業を回避するため、Microsoft は、2017 年に Azure Managed Disks を発表しました。To avoid the administrative work of planning and deploying VHDs across different Azure storage accounts, Microsoft introduced Azure Managed Disks in 2017. マネージド ディスクは、Standard Storage と Premium Storage で使用できます。Managed disks are available for standard storage and premium storage. 非マネージド ディスクと比較したマネージド ディスクの主なメリットは次のとおりです。The major advantages of managed disks compared to nonmanaged disks are:

  • マネージド ディスクの場合、デプロイ時に Azure によって、異なるストレージ アカウントの間で異なる VHD が自動的に分散されます。For managed disks, Azure distributes the different VHDs across different storage accounts automatically at deployment time. これにより、データ量、I/O スループット、および IOPS に関するストレージ アカウントの制限に達することがなくなります。In this way, storage account limits for data volume, I/O throughput, and IOPS aren’t hit.
  • Azure Storage は、マネージド ディスクを使用して、Azure 可用性セットの概念に対応します。Using managed disks, Azure Storage honors the concepts of Azure availability sets. VM が Azure 可用性セットの一部である場合、VM のベース VHD と接続ディスクは異なる障害ドメインと更新ドメインにデプロイされます。If the VM is part of an Azure availability set, the base VHD and attached disk of a VM are deployed into different fault and update domains.


Azure Managed Disks の利点を考えると、一般の DBMS デプロイと SAP デプロイには Azure Managed Disks を使用することを強くお勧めします。Given the advantages of Azure Managed Disks, we highly recommend that you use Azure Managed Disks for your DBMS deployments and SAP deployments in general.

アンマネージド ディスクからマネージド ディスクに変換するには、以下を参照してください。To convert from unmanaged to managed disks, see:

VM とデータ ディスクのキャッシュCaching for VMs and data disks

ディスクを VM にマウントする場合、Azure ストレージに配置されたこれらのディスクと VM 間の I/O トラフィックをキャッシュするかどうかを選択できます。When you mount disks to VMs, you can choose whether the I/O traffic between the VM and those disks located in Azure storage is cached.

以下に示す推奨事項は、次のような標準 DBMS の I/O 特性を前提にしています。The following recommendations assume these I/O characteristics for standard DBMS:

  • これは、ほとんどの場合、データベースのデータ ファイルに対する読み取りワークロードです。It's mostly a read workload against data files of a database. これらの読み取りは、DBMS システムのパフォーマンスにとって重要です。These reads are performance critical for the DBMS system.
  • データ ファイルに対する書き込みは、チェックポイントまたは一定のストリームに基づいてバーストで実行されます。Writing against the data files occurs in bursts based on checkpoints or a constant stream. 1 日の平均書き込み量は、読み取り量よりも少なくなります。Averaged over a day, there are fewer writes than reads. データ ファイルからの読み取りとは反対に、これらの書き込みは非同期で実行され、ユーザー トランザクションに悪影響を与えません。Opposite to reads from data files, these writes are asynchronous and don't hold up any user transactions.
  • トランザクション ログまたは再実行ファイルからの読み取りはほとんどありません。There are hardly any reads from the transaction log or redo files. 例外は、トランザクション ログ バックアップを実行するときのサイズの大きな I/O です。Exceptions are large I/Os when you perform transaction log backups.
  • トランザクションまたは redo ログ ファイルに対する主な負荷は、書き込みです。The main load against transaction or redo log files is writes. ワークロードの性質に応じて、I/O サイズを 4 KB まで小さくしたり、1 MB 以上にしたりできます。Dependent on the nature of the workload, you can have I/Os as small as 4 KB or, in other cases, I/O sizes of 1 MB or more.
  • すべての書き込みを信頼性の高い方法でディスク上に保存する必要があります。All writes must be persisted on disk in a reliable fashion.

Standard Storage で可能なキャッシュの種類は次のとおりです。For standard storage, the possible cache types are:

  • なしNone
  • ReadRead
  • 読み取り/書き込みRead/Write

一定の決まったパフォーマンスを得られるようにするには、DBMS 関連のデータ ファイル、ログおよび redo ファイル、およびテーブル スペースを含むすべてのディスクに対する Standard Storage のキャッシュを "なし" に設定します。To get consistent and deterministic performance, set the caching on standard storage for all disks that contain DBMS-related data files, log and redo files, and table space to NONE. ベース VHD のキャッシュは既定のままにしておくことができます。The caching of the base VHD can remain with the default.

Azure Premium Storage については、次のキャッシュ オプションが存在します。For Azure premium storage, the following caching options exist:

  • なしNone
  • ReadRead
  • 読み取り/書き込みRead/write
  • なし + 書き込みアクセラレータ (Azure M シリーズ VM の場合のみ)None + Write Accelerator, which is only for Azure M-Series VMs
  • 読み取り + 書き込みアクセラレータ (Azure M シリーズ VM の場合のみ)Read + Write Accelerator, which is only for Azure M-Series VMs

Premium Storage の場合は、SAP データベースの データ ファイルに読み取りキャッシュ を使用し、ログ ファイルのディスクにキャッシュなし を選択することをお勧めします。For premium storage, we recommend that you use Read caching for data files of the SAP database and choose No caching for the disks of log file(s).

M シリーズのデプロイでは、DBMS のデプロイに Azure 書き込みアクセラレータを使用することをお勧めします。For M-Series deployments, we recommend that you use Azure Write Accelerator for your DBMS deployment. Azure 書き込みアクセラレータの詳細、制限、およびデプロイについては、「書き込みアクセラレータを有効にする」を参照してください。For details, restrictions, and deployment of Azure Write Accelerator, see Enable Write Accelerator.

Ultra ディスクと Azure NetApp Files では、キャッシュ オプションは提供されません。For Ultra disk and Azure NetApp Files, no caching options are offered.

Azure の非永続的ディスクAzure nonpersistent disks

Azure VM は、VM がデプロイされた後に非永続ディスクを提供します。Azure VMs offer nonpersistent disks after a VM is deployed. VM が再起動された場合、これらのドライブ上のすべてのコンテンツは消去されます。データ ファイルのほか、データベースのログおよび redo ファイルは、どんな状況でもこれらのドライブに保存してはいけません。In the case of a VM reboot, all content on those drives is wiped out. It's a given that data files and log and redo files of databases should under no circumstances be located on those nonpersisted drives. 例外として、データベースによっては、tempdb や temp テーブルスペースなどにこれらの非永続ドライブが適している場合があります。There might be exceptions for some databases, where these nonpersisted drives could be suitable for tempdb and temp tablespaces. これらのドライブを A シリーズ VM に使用することは避けてください。これらの非永続ドライブのスループットは、この VM ファミリで制限されているためです。Avoid using those drives for A-Series VMs because those nonpersisted drives are limited in throughput with that VM family.

詳細については、Azure の Windows VM 上の一時ドライブの解説に関するページを参照してください。For more information, see Understand the temporary drive on Windows VMs in Azure.

Windows の非永続ディスク WindowsWindows

Azure VM の D ドライブは、Azure の計算ノード上のいくつかのローカル ディスクによってサポートされる非永続ドライブです。Drive D in an Azure VM is a nonpersisted drive, which is backed by some local disks on the Azure compute node. これは非永続的であるため、ドライブ D の内容に加えられた変更は、VM を再起動すると失われます。Because it's nonpersisted, any changes made to the content on drive D are lost when the VM is rebooted. "変更" には、保存されたファイル、作成されたディレクトリ、インストールされたアプリケーションが含まれます。Changes include files that were stored, directories that were created, and applications that were installed.

Linux の非永続ディスク LinuxLinux

Linux Azure VM は、Azure の計算ノード上のローカル ディスクによってサポートされる非永続ドライブであるドライブを /mnt/resource に自動的にマウントします。Linux Azure VMs automatically mount a drive at /mnt/resource that's a nonpersisted drive backed by local disks on the Azure compute node. これは非永続的であるため、/mnt/resource 内のコンテンツに加えられた変更は、VM を再起動すると失われます。Because it's nonpersisted, any changes made to content in /mnt/resource are lost when the VM is rebooted. "変更" には、保存されたファイル、作成されたディレクトリ、インストールされたアプリケーションが含まれます。Changes include files that were stored, directories that were created, and applications that were installed.

Microsoft Azure Storage の回復性Microsoft Azure Storage resiliency

Microsoft Azure Storage は、ベース VHD を、OS のほか、接続されているディスクまたは BLOB と共に、3 つ以上の別個のストレージ ノードに格納します。Microsoft Azure Storage stores the base VHD, with OS and attached disks or blobs, on at least three separate storage nodes. この種類のストレージは、ローカル冗長ストレージ (LRS) と呼ばれます。This type of storage is called locally redundant storage (LRS). LRS は、Azure 内のすべての種類のストレージの既定値です。LRS is the default for all types of storage in Azure.

これ以外にも冗長化の方法があります。There are other redundancy methods. 詳細については、「Azure Storage のレプリケーション」をご覧ください。For more information, see Azure Storage replication.


Azure Premium Storage、Ultra ディスク、および Azure NetApp Files (SAP HANA 専用) は、DBMS VM と、データベース、ログ、および再実行のファイルを格納するディスクに推奨される種類のストレージです。Azure premium storage, Ultra disk and Azure NetApp Files (exclusively for SAP HANA) are the recommended type of storage for DBMS VMs and disks that store database and log and redo files. これらの種類のストレージで使用できる冗長化の方法は LRS のみです。The only available redundancy method for these storage types is LRS. そのため、別の Azure リージョンまたは可用性ゾーンへのデータベース データのレプリケーションを有効にするようにデータベースの方式を構成する必要があります。As a result, you need to configure database methods to enable database data replication into another Azure region or availability zone. データベースの方式には、SQL Server Always On、Oracle Data Guard、および HANA システム レプリケーションがあります。Database methods include SQL Server Always On, Oracle Data Guard, and HANA System Replication.


DBMS デプロイの場合、Standard Storage に geo 冗長ストレージ (GRS) を使用することは推奨されません。For DBMS deployments, the use of geo-redundant storage (GRS) isn't recommended for standard storage. GRS はパフォーマンスに深刻な影響を及ぼすほか、VM に接続されている異なる VHD 間で書き込み順序を考慮しません。GRS severely affects performance and doesn't honor the write order across different VHDs that are attached to a VM. 異なる VHD 間で書き込み順序が考慮されないと、レプリケーション ターゲット側でデータベースの不整合が生じる可能性があります。Not honoring the write order across different VHDs potentially leads to inconsistent databases on the replication target side. この状況は、ソース VM 側でよくあるように、データベースとログおよび redo ファイルが複数の VHD に分散している場合に発生します。This situation occurs if database and log and redo files are spread across multiple VHDs, as is generally the case, on the source VM side.

VM ノードの回復性VM node resiliency

Azure では、VM に複数の異なる SLA を提供しています。Azure offers several different SLAs for VMs. 詳細については、「Virtual Machines の SLA」の最新リリースを参照してください。For more information, see the most recent release of SLA for Virtual Machines. DBMS レイヤーは、SAP システムにおける可用性にとって非常に重要であるため、可用性セット、Availability Zones、およびメンテナンス イベントについて理解しておく必要があります。Because the DBMS layer is critical to availability in an SAP system, you need to understand availability sets, Availability Zones, and maintenance events. これらの概念の詳細については、「Azure での Windows 仮想マシンの可用性の管理」および Azure での Linux 仮想マシンの可用性の管理に関するページを参照してください。For more information on these concepts, see Manage the availability of Windows virtual machines in Azure and Manage the availability of Linux virtual machines in Azure.

SAP ワークロードを含む運用 DBMS シナリオの最小推奨事項は、次のとおりです。The minimum recommendation for production DBMS scenarios with an SAP workload is to:

  • 同じ Azure リージョン内の別個の可用性セットに 2 つの VM をデプロイします。Deploy two VMs in a separate availability set in the same Azure region.
  • これら 2 つの VM を同じ Azure 仮想ネットワーク内で実行し、同じサブネットの NIC を接続します。Run these two VMs in the same Azure virtual network and have NICs attached out of the same subnets.
  • 2 つ目の VM のホット スタンバイを維持するためにデータベース方法を使用します。Use database methods to keep a hot standby with the second VM. 方法としては、SQL Server Alwayson、Oracle Data Guard、または HANA システム レプリケーションを使用することができます。Methods can be SQL Server Always On, Oracle Data Guard, or HANA System Replication.

別の Azure リージョンに 3 番目の VM をデプロイし、同じデータベース方式を使用して別の Azure リージョンに非同期レプリカを提供することもできます。You also can deploy a third VM in another Azure region and use the same database methods to supply an asynchronous replica in another Azure region.

Azure 可用性セットの設定方法については、このチュートリアルを参照してください。For information on how to set up Azure availability sets, see this tutorial.

Azure ネットワークに関する考慮事項Azure network considerations

大規模な SAP のデプロイでは、Azure 仮想データセンターのブループリントを使用します。In large-scale SAP deployments, use the blueprint of Azure Virtual Datacenter. これを、仮想ネットワークの構成や、組織のさまざまな部分に対するアクセス許可とロールの割り当てに使用します。Use it for your virtual network configuration and permissions and role assignments to different parts of your organization.

これらのベスト プラクティスは、数百件もの顧客デプロイの結果です。These best practices are the result of hundreds of customer deployments:

  • SAP アプリケーションがデプロイされている仮想ネットワークは、インターネットにアクセスできません。The virtual networks the SAP application is deployed into don't have access to the internet.
  • データベース VM は、アプリケーション層と同じ仮想ネットワーク内で実行され、SAP アプリケーション層とは別のサブネットに分離されます。The database VMs run in the same virtual network as the application layer, separated in a different subnet from the SAP application layer.
  • 仮想ネットワーク内の VM には、プライベート IP アドレスが静的に割り当てられます。The VMs within the virtual network have a static allocation of the private IP address. 詳しくは、「Azure における IP アドレスの種類と割り当て方法」をご覧ください。For more information, see IP address types and allocation methods in Azure.
  • DBMS VM を出入りする際のルーティングの制限は、ローカルの DBMS VM にインストールされているファイアウォールでは設定 "されません"。Routing restrictions to and from the DBMS VMs are not set with firewalls installed on the local DBMS VMs. 代わりに、トラフィック ルーティングはネットワーク セキュリティ グループ (NSG) を使用して定義されます。Instead, traffic routing is defined with network security groups (NSGs).
  • DBMS VM へのトラフィックを分離および隔離するには、異なる NIC を VM に割り当てます。To separate and isolate traffic to the DBMS VM, assign different NICs to the VM. 各 NIC は異なる IP アドレスを取得し、異なる仮想ネットワーク サブネットに割り当てられます。Every NIC gets a different IP address, and every NIC is assigned to a different virtual network subnet. サブネットごとに異なる NSG ルールがあります。Every subnet has different NSG rules. ネットワーク トラフィックを分離または隔離するのは、ルーティングのための 1 つの手段です。The isolation or separation of network traffic is a measure for routing. ネットワーク スループットのクォータを設定するためには使用されません。It's not used to set quotas for network throughput.


Azure を介して静的 IP アドレスを割り当てるということは、それらを個々の仮想 NIC に割り当てるということです。Assigning static IP addresses through Azure means to assign them to individual virtual NICs. ゲスト OS 内の静的 IP アドレスを仮想 NIC に割り当てないでください。Don't assign static IP addresses within the guest OS to a virtual NIC. Azure Backup のような一部の Azure サービスは、少なくともプライマリ仮想 NIC が静的 IP アドレスではなく DHCP に設定されているという事実に依存します。Some Azure services like Azure Backup rely on the fact that at least the primary virtual NIC is set to DHCP and not to static IP addresses. 詳細については、「Azure 仮想マシンのバックアップのトラブルシューティング」を参照してください。For more information, see Troubleshoot Azure virtual machine backup. 複数の静的 IP アドレスを 1 つの VM に割り当てるには、複数の仮想 NIC を VM に割り当てます。To assign multiple static IP addresses to a VM, assign multiple virtual NICs to a VM.


SAP NetWeaver、Hybris、または S/4HANA ベースの SAP システムの DBMS レイヤーと SAP アプリケーションの間の通信パスにネットワーク仮想アプライアンスを構成することはサポートされていません。Configuring network virtual appliances in the communication path between the SAP application and the DBMS layer of a SAP NetWeaver-, Hybris-, or S/4HANA-based SAP system isn't supported. この制限は、機能およびパフォーマンス上の理由からです。This restriction is for functionality and performance reasons. SAP アプリケーション レイヤーと DBMS レイヤーの間の通信パスは、直接的なものである必要があります。The communication path between the SAP application layer and the DBMS layer must be a direct one. アプリケーション セキュリティ グループ (ASG) および NSG ルールで直接通信パスが許可されている場合、この制限にこれらの Azure ASG および NSG ルールは含まれません。The restriction doesn't include application security group (ASG) and NSG rules if those ASG and NSG rules allow a direct communication path.

ネットワーク仮想アプライアンスがサポートされないその他のシナリオは次のとおりです。Other scenarios where network virtual appliances aren't supported are in:

通信パスにネットワーク仮想アプライアンスがあると、2 つの通信パートナー間のネットワーク待ち時間が容易に倍増する可能性があります。Network virtual appliances in communication paths can easily double the network latency between two communication partners. また、SAP アプリケーション レイヤーと DBMS レイヤーの間のクリティカル パスのスループットが制限される場合もあります。They also can restrict throughput in critical paths between the SAP application layer and the DBMS layer. 一部の顧客シナリオでは、ネットワーク仮想アプライアンスが原因で Pacemaker Linux クラスターに障害が発生することがあります。In some customer scenarios, network virtual appliances can cause Pacemaker Linux clusters to fail. Linux Pacemaker クラスター ノード間の通信において、ネットワーク仮想アプライアンス経由で SBD デバイスと通信する場合があります。These are cases where communications between the Linux Pacemaker cluster nodes communicate to their SBD device through a network virtual appliance.


サポートされて "いない" もう 1 つの設計は、SAP アプリケーション レイヤーと DBMS レイヤーを、相互に ピアリングされていない異なる Azure 仮想ネットワークに分離することです。Another design that's not supported is the segregation of the SAP application layer and the DBMS layer into different Azure virtual networks that aren't peered with each other. 異なる Azure 仮想ネットワークを使用するのではなく、Azure 仮想ネットワーク内のサブネットを使用して SAP アプリケーション レイヤーと DBMS レイヤーを分離することをお勧めします。We recommend that you segregate the SAP application layer and DBMS layer by using subnets within an Azure virtual network instead of by using different Azure virtual networks.

推奨事項に従わず、代わりに 2 つのレイヤーを異なる仮想ネットワークに分離する場合は、2 つの仮想ネットワークをピアリングする必要があります。If you decide not to follow the recommendation and instead segregate the two layers into different virtual networks, the two virtual networks must be peered.

2 つのピアリングされた Azure 仮想ネットワーク間のネットワーク トラフィックは転送コストの影響を受ける点に注意してください。Be aware that network traffic between two peered Azure virtual networks is subject to transfer costs. SAP アプリケーション レイヤーと DBMS レイヤーの間で、数テラバイトもの膨大な量のデータが交換されます。Huge data volume that consists of many terabytes is exchanged between the SAP application layer and the DBMS layer. SAP アプリケーション レイヤーと DBMS レイヤーが 2 つのピアリングされた Azure 仮想ネットワーク間で分離されている場合、相当なコストが蓄積される可能性があります。You can accumulate substantial costs if the SAP application layer and DBMS layer are segregated between two peered Azure virtual networks.

Azure 可用性セット内または 2 つの Azure Availability Zones 間で、運用 DBMS デプロイに 2 つの VM を使用します。Use two VMs for your production DBMS deployment within an Azure availability set or between two Azure Availability Zones. また、SAP アプリケーション レイヤーと、2 つの DBMS VM への管理トラフィックおよび運用トラフィック用に別個のルーティングを使用します。Also use separate routing for the SAP application layer and the management and operations traffic to the two DBMS VMs. 次の図を参照してください。See the following image:

2 つのサブネット内の 2 つの VM のダイアグラム

Azure Load Balancer を使用してトラフィックをリダイレクトするUse Azure Load Balancer to redirect traffic

SQL Server Always On または HANA システム レプリケーションなどの機能でプライベート仮想 IP アドレスを使用するには、Azure Load Balancer の構成が必要です。The use of private virtual IP addresses used in functionalities like SQL Server Always On or HANA System Replication requires the configuration of an Azure load balancer. ロード バランサーは、プローブ ポートを使用して、アクティブな DBMS ノードを特定し、そのアクティブなデータベース ノードにのみトラフィックをルーティングします。The load balancer uses probe ports to determine the active DBMS node and route the traffic exclusively to that active database node.

データベース ノードでフェールオーバーが発生した場合、SAP アプリケーションを再構成する必要はありません。If there's a failover of the database node, there's no need for the SAP application to reconfigure. 代わりに、最も一般的な SAP アプリケーション アーキテクチャにより、プライベート仮想 IP アドレスに再接続されます。Instead, the most common SAP application architectures reconnect against the private virtual IP address. その一方で、ロード バランサーはノードのフェールオーバーに反応して、プライベート仮想 IP アドレスへのトラフィックを 2 番目のノードにリダイレクトします。Meanwhile, the load balancer reacts to the node failover by redirecting the traffic against the private virtual IP address to the second node.

Azure では 2 つの異なるロード バランサーの SKU を提供します。Basic SKU と Standard SKU です。Azure offers two different load balancer SKUs: a basic SKU and a standard SKU. セットアップと機能の利点に基づいて、Azure ロード バランサーの Standard SKU を使用する必要があります。Based on the advantages in setup and functionality, you should use the Standard SKU of the Azure load balancer. Standard バージョンのロード バランサーの大きな利点の 1 つは、データ トラフィックがロード バランサー自体を経由してルーティングされないことです。One of the large advantages of the Standard version of the load balancer is that the data traffic is not routed through the load balancer itself.

内部ロード バランサーを構成する方法の例については、チュートリアル: Azure Virtual Machines での SQL Server 可用性グループの手動構成に関するページを参照してください。An example how you can configure an internal load balancer can be found in the article Tutorial: Configure a SQL Server availability group on Azure Virtual Machines manually


パブリック IP アドレスのアクセスに関連する Basic SKU と Standard SKU の動作には違いがあります。There are differences in behavior of the basic and standard SKU related to the access of public IP addresses. パブリック IP アドレスにアクセスするために Standard SKU の制限事項を回避する方法については、「SAP の高可用性シナリオにおける Azure Standard Load Balancer を使用した Virtual Machines のパブリック エンドポイント接続」のドキュメントを参照してください。The way how to work around the restrictions of the Standard SKU to access public IP addresses is described in the document Public endpoint connectivity for Virtual Machines using Azure Standard Load Balancer in SAP high-availability scenarios

Azure Accelerated NetworkingAzure Accelerated Networking

Azure VM 間のネットワーク待ち時間をさらに短縮するには、Azure 高速ネットワークを選択することをお勧めします。To further reduce network latency between Azure VMs, we recommend that you choose Azure Accelerated Networking. これを、(SAP アプリケーション レイヤーと SAP DBMS レイヤーの場合は特に) SAP ワークロード用の Azure VM をデプロイするときに使用します。Use it when you deploy Azure VMs for an SAP workload, especially for the SAP application layer and the SAP DBMS layer.


すべての種類の VM で高速ネットワークがサポートされるわけではありません。Not all VM types support Accelerated Networking. 高速ネットワークをサポートする VM の種類の一覧が前の記事に記載されています。The previous article lists the VM types that support Accelerated Networking.

Windows 高速ネットワーク WindowsWindows

Windows 用の高速ネットワークを使用して VM をデプロイする方法については、「高速ネットワークを使った Windows 仮想マシンの作成」を参照してください。To learn how to deploy VMs with Accelerated Networking for Windows, see Create a Windows virtual machine with Accelerated Networking.

Linux 高速ネットワーク LinuxLinux

Linux ディストリビューションの詳細については、「高速ネットワークを使った Linux 仮想マシンの作成」を参照してください。For more information on Linux distribution, see Create a Linux virtual machine with Accelerated Networking.


SUSE、Red Hat、および Oracle Linux の場合、Accelerated Networking は最近のリリースでサポートされています。In the case of SUSE, Red Hat, and Oracle Linux, Accelerated Networking is supported with recent releases. SLES 12 SP2、RHEL 7.2 などの以前のリリースでは、Azure 高速ネットワークはサポートされていません。Older releases like SLES 12 SP2 or RHEL 7.2 don't support Azure Accelerated Networking.

ホスト監視のデプロイDeployment of host monitoring

Azure 仮想マシンの運用環境で SAP アプリケーションを使用する場合、SAP には Azure 仮想マシンを実行している物理ホストからホスト監視データを取得する機能が必要です。For production use of SAP applications in Azure virtual machines, SAP requires the ability to get host monitoring data from the physical hosts that run the Azure virtual machines. SAPOSCOL および SAP Host Agent でこの機能を有効にする、特定の SAP Host Agent パッチ レベルが必要になります。A specific SAP Host Agent patch level is required that enables this capability in SAPOSCOL and SAP Host Agent. 正確なパッチ レベルは SAP Note 1409604に記載されています。The exact patch level is documented in SAP Note 1409604.

ホストのデータを SAPOSCOL および SAP Host Agent に配信するコンポーネントのデプロイと、それらのコンポーネントのライフサイクル管理の詳細については、デプロイ ガイドを参照してください。For more information on the deployment of components that deliver host data to SAPOSCOL and SAP Host Agent and the life-cycle management of those components, see the Deployment guide.

次のステップNext steps

特定の DBMS については、以下を参照してください。For more information on a particular DBMS, see: