As documented here: , Azure enforces an IOPS quota per VHD. Dependent on the VM type, the Step 4: number of VHDs which can be mounted varies. As a result you can calculate a maximum IOPS number that can be achieved with each of the different VM types. Dependent on the database file layout you can stripe VHDs to become one volume in the guest OS. However if the current IOPS volume of a deployed SAP system is exceeding the calculated limits of the largest VM type of Azure and if there is no chance to compensate with more memory, the workload of the SAP system can be impacted severely. In such cases, you can hit a point where you should not deploy the system on Azure. Step 5: Especially in SAP systems which are deployed on-premise in 2-Tier configurations, chances are high, that the system might need to be configured on Azure in a 3-Tier configuration. In this step, you need to check whether there is a component in the SAP application layer which can’t be scaled out and which would not fit into the CPU and memory resources the different Azure VM types offer. If here indeed is such a component, the SAP system and its workload can’t be deployed into Azure. If you can scale-out the SAP application components into multiple Azure VMs, the system can be deployed into Azure. Step 6: If the DBMS and SAP application layer components can be run in Azure VMs, the configuration needs to be defined in regards to: Number of Azure VMs, VM types for the individual components, Number of VHDs in DBMS VM to provide enough IOPS. It is reasonable to assume that SAP systems in 2-tier configurations that run well within the resource capabilities on servers or large VMs will need to be configured as 3-Tier SAP systems with a dedicated DBMS VM and several VMs representing the SAP NetWeaver application layer.
Step 4: As documented here: , Azure enforces an IOPS quota per VHD. Dependent on the VM type, the number of VHDs which can be mounted varies. As a result you can calculate a maximum IOPS number that can be achieved with each of the different VM types. Dependent on the database file layout you can stripe VHDs to become one volume in the guest OS. However if the current IOPS volume of a deployed SAP system is exceeding the calculated limits of the largest VM type of Azure and if there is no chance to compensate with more memory, the workload of the SAP system can be impacted severely. In such cases, you can hit a point where you should not deploy the system on Azure. Step 5: Especially in SAP systems which are deployed on-premise in 2-Tier configurations, chances are high, that the system might need to be configured on Azure in a 3-Tier configuration. In this step, you need to check whether there is a component in the SAP application layer which can’t be scaled out and which would not fit into the CPU and memory resources the different Azure VM types offer. If here indeed is such a component, the SAP system and its workload can’t be deployed into Azure. If you can scale-out the SAP application components into multiple Azure VMs, the system can be deployed into Azure. Step 6: If the DBMS and SAP application layer components can be run in Azure VMs, the configuration needs to be defined in regards to: Number of Azure VMs, VM types for the individual components, Number of VHDs in DBMS VM to provide enough IOPS. It is reasonable to assume that SAP systems in 2-tier configurations that run well within the resource capabilities on servers or large VMs will need to be configured as 3-Tier SAP systems with a dedicated DBMS VM and several VMs representing the SAP NetWeaver application layer.