You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -52,6 +52,7 @@ SAP HANA on Azure (Large Instances) service based on Revision 4 stamps is availa
52
52
| Optimized for OLTP: SAP Business Suite<br /> on SAP HANA or S/4HANA (OLTP),<br /> generic OLTP | SAP HANA on Azure S72m<br /> – 2 x Intel® Xeon® Processor E7-8890 v3<br /> 36 CPU cores and 72 CPU threads | 1.5 TB | 6 TB | Not offered anymore |
53
53
|---| SAP HANA on Azure S144m<br /> – 4 x Intel® Xeon® Processor E7-8890 v3<br /> 72 CPU cores and 144 CPU threads | 3.0 TB | 12 TB | Not offered anymore |
54
54
|---| SAP HANA on Azure S192m<br /> – 4 x Intel® Xeon® Processor E7-8890 v4<br /> 96 CPU cores and 192 CPU threads | 4.0 TB | 16 TB | Not offered anymore |
55
+
| --- | SAP HANA on Azure S224m<br /> – 4 x Intel® Xeon® Platinum 8276 processor (also known as Cascade lake)<br /> 112 CPU cores and 224 CPU threads | 6.0 TB | 10.5 TB | Available in Revision3 and Revision4 stamps |
55
56
|---| SAP HANA on Azure S384m<br /> – 8 x Intel® Xeon® Processor E7-8890 v4<br /> 192 CPU cores and 384 CPU threads | 6.0 TB | 18 TB | Available in Revision4 stamps|
56
57
|---| SAP HANA on Azure S384xm<br /> – 8 x Intel® Xeon® Processor E7-8890 v4<br /> 192 CPU cores and 384 CPU threads | 8.0 TB | 22 TB | Available in Revision4 stamps |
57
58
|---| SAP HANA on Azure S576m<br /> – 12 x Intel® Xeon® Processor E7-8890 v4<br /> 288 CPU cores and 576 CPU threads | 12.0 TB | 28 TB | Available in Revision4 stamps|
@@ -87,7 +88,7 @@ The specific configurations chosen are dependent on workload, CPU resources, and
87
88
88
89
The hardware base for the offers, except units for customer-specific sizing projects, are SAP HANA TDI-certified. Two different classes of hardware divide the SKUs into:
89
90
90
-
- S72, S72m, S96, S144, S144m, S192, S192m, S192xm, and S224, which are referred to as the "Type I class" of SKUs.
91
+
- S72, S72m, S96, S144, S144m, S192, S192m, S192xm, S224, and S224m which are referred to as the "Type I class" of SKUs.
91
92
- S384, S384m, S384xm, S384xxm, S576m, S576xm S768m, S768xm, and S960m, which are referred to as the "Type II class" of SKUs.
92
93
- If you are interested in other S224 SKUs offering from 4.5TB to 9TB with Optane, contact your Microsoft account team to get more information.
@@ -35,7 +35,7 @@ Several common definitions are widely used in the Architecture and Technical Dep
35
35
Domain users of the on-premises domain can access the servers and run services on those VMs (such as DBMS services). Communication and name resolution between VMs deployed on-premises and Azure-deployed VMs is possible. This scenario is typical of the way in which most SAP assets are deployed. For more information, see [Azure VPN Gateway](../../../vpn-gateway/vpn-gateway-about-vpngateways.md?toc=%2fazure%2fvirtual-machines%2flinux%2ftoc.json) and [Create a virtual network with a site-to-site connection by using the Azure portal](../../../vpn-gateway/vpn-gateway-howto-site-to-site-resource-manager-portal.md?toc=%2fazure%2fvirtual-machines%2flinux%2ftoc.json).
36
36
-**Tenant**: A customer deployed in HANA Large Instance stamp gets isolated into a *tenant.* A tenant is isolated in the networking, storage, and compute layer from other tenants. Storage and compute units assigned to the different tenants can't see each other or communicate with each other on the HANA Large Instance stamp level. A customer can choose to have deployments into different tenants. Even then, there is no communication between tenants on the HANA Large Instance stamp level.
37
37
-**SKU category**: For HANA Large Instance, the following two categories of SKUs are offered:
38
-
-**Type I class**: S72, S72m, S96, S144, S144m, S192, S192m, S192xm, and S224
38
+
-**Type I class**: S72, S72m, S96, S144, S144m, S192, S192m, S192xm, S224, and S224m
39
39
-**Type II class**: S384, S384m, S384xm, S384xxm, S576m, S576xm, S768m, S768xm, and S960m
40
40
-**Stamp**: Defines the Microsoft internal deployment size of HANA Large Instances. Before HANA Large Instance units can get deployed, a HANA Large Instance stamp consisting out of compute, network, and storage racks need to be deployed in a datacenter location. Such a deployment is called a HANA Large instance stamp or from Revision 4 (see below) on we use the alternate of term of **Large Instance Row**
41
41
-**Revision**: There are two different stamp revisions for HANA Large Instance stamps. These differ in architecture and proximity to Azure virtual machine hosts
@@ -40,7 +40,7 @@ The minimum SAP HANA certified conditions for the different storage types are:
40
40
- Azure Ultra disk at least for the /hana/log volume. The /hana/data volume can be placed on either Premium SSD without Azure Write Accelerator or in order to get faster restart times Ultra disk
41
41
-**NFS v4.1** volumes on top of Azure NetApp Files for /hana/log **and** /hana/data. The volume of /hana/shared can use NFS v3 or NFS v4.1 protocol. The NFS v4.1 protocol is mandatory for /hana/data and/hana/log volumes.
42
42
43
-
Some of the storage types can be combined. E.g., it is possible to put /hana/data onto Premium Storage and /hana/log can be placed on Ultra disk storage in order to get the required low latency. However, if you use an NFS v4.1 volume based on ANF for /hana/data, you are required to use another NFS v4.1 volume based on ANF for /hana/log. Using NFS on top of ANF for one of the volumes (like /hana/data) and Azure Premium Storage or Ultra disk for the other volume (like /hana/log) is **not supported**.
43
+
Some of the storage types can be combined. For example, it is possible to put /hana/data onto Premium Storage and /hana/log can be placed on Ultra disk storage in order to get the required low latency. However, if you use an NFS v4.1 volume based on ANF for /hana/data, you are required to use another NFS v4.1 volume based on ANF for /hana/log. Using NFS on top of ANF for one of the volumes (like /hana/data) and Azure Premium Storage or Ultra disk for the other volume (like /hana/log) is **not supported**.
44
44
45
45
In the on-premises world, you rarely had to care about the I/O subsystems and its capabilities. Reason was that the appliance vendor needed to make sure that the minimum storage requirements are met for SAP HANA. As you build the Azure infrastructure yourself, you should be aware of some of these SAP issued requirements. Some of the minimum throughput characteristics that are required from SAP, are resulting in the need to:
46
46
@@ -52,9 +52,12 @@ Given that low storage latency is critical for DBMS systems, even as DBMS, like
52
52
53
53
**Recommendation: As stripe sizes for the RAID 0 the recommendation is to use:**
54
54
55
-
-64 KB or 128 KB for **/hana/data**
55
+
-256 KB for **/hana/data**
56
56
- 32 KB for **/hana/log**
57
57
58
+
> [!IMPORTANT]
59
+
> The stripe size for /hana/data got changed from earlier recommendations calling for 64 KB or 128 KB to 256 KB based on customer experiences with more recent Linux versions. The size of 256 KB is providing slightly better performance
60
+
58
61
> [!NOTE]
59
62
> You don't need to configure any redundancy level using RAID volumes since Azure Premium and Standard storage keep three images of a VHD. The usage of a RAID volume is purely to configure volumes that provide sufficient I/O throughput.
60
63
@@ -63,7 +66,7 @@ Accumulating a number of Azure VHDs underneath a RAID, is accumulative from an I
63
66
Also keep the overall VM I/O throughput in mind when sizing or deciding for a VM. Overall VM storage throughput is documented in the article [Memory optimized virtual machine sizes](https://docs.microsoft.com/azure/virtual-machines/linux/sizes-memory).
64
67
65
68
## Linux I/O Scheduler mode
66
-
Linux has several different I/O scheduling modes. Common recommendation through Linux vendors and SAP is to reconfigure the I/O scheduler mode for disk volumes from the **cfq** mode to the **noop** mode. Details are referenced in [SAP Note #1984787](https://launchpad.support.sap.com/#/notes/1984787).
69
+
Linux has several different I/O scheduling modes. Common recommendation through Linux vendors and SAP is to reconfigure the I/O scheduler mode for disk volumes from the **cfq** mode to the **noop**(non-multiqueue) or **none** for (multiqueue) mode. Details are referenced in [SAP Note #1984787](https://launchpad.support.sap.com/#/notes/1984787).
67
70
68
71
69
72
## Solutions with Premium Storage and Azure Write Accelerator for Azure M-Series virtual machines
@@ -180,7 +183,7 @@ Microsoft is in the process of rolling out a new Azure storage type called [Azur
180
183
181
184
Ultra disk gives you the possibility to define a single disk that fulfills your size, IOPS, and disk throughput range. Instead of using logical volume managers like LVM or MDADM on top of Azure Premium Storage to construct volumes that fulfill IOPS and storage throughput requirements. You can run a configuration mix between Ultra disk and Premium Storage. As a result, you can limit the usage of Ultra disk to the performance critical /hana/data and /hana/log volumes and cover the other volumes with Azure Premium Storage
182
185
183
-
Other advantages of Ultra disk can be the better read latency in comparison to Premium Storage. The faster read latency can have advantages when you want to reduce the HANA start up times and the subsequent load of the data into memory. Advantages of Ultra disk storage also can be felt when HANA is writing savepoints. Since Premium Storage disks for /hana/data are usually not Write Accelerator cached, the write latency to /hana/data on Premium Storage compared to the Ultra disk is higher. It can be expected that savepoint writing with Ultra disk is performing better on Ultra disk.
186
+
Other advantages of Ultra disk can be the better read latency in comparison to Premium Storage. The faster read latency can have advantages when you want to reduce the HANA startup times and the subsequent load of the data into memory. Advantages of Ultra disk storage also can be felt when HANA is writing savepoints. Since Premium Storage disks for /hana/data are usually not Write Accelerator cached, the write latency to /hana/data on Premium Storage compared to the Ultra disk is higher. It can be expected that savepoint writing with Ultra disk is performing better on Ultra disk.
184
187
185
188
> [!IMPORTANT]
186
189
> Ultra disk is not yet present in all the Azure regions and is also not yet supporting all VM types listed below. For detailed information where Ultra disk is available and which VM families are supported, check the article [What disk types are available in Azure?](https://docs.microsoft.com/azure/virtual-machines/windows/disks-types#ultra-disk).
@@ -369,7 +369,7 @@ The following items are prefixed with either:
369
369
-**[1]**: Applicable only to node 1
370
370
-**[2]**: Applicable only to node 2
371
371
372
-
**[A]**Prerequisites for Pacemaker configuration:
372
+
**[A]**Prerequisite for Pacemaker configuration:
373
373
1. Shut down both database servers with user db2\<sid> with db2stop.
374
374
1. Change the shell environment for db2\<sid> user to */bin/ksh*:
375
375
<pre><code># Install korn shell:
@@ -443,6 +443,11 @@ Daemon Status:
443
443
### Configure Azure Load Balancer
444
444
To configure Azure Load Balancer, we recommend that you use the [Azure Standard Load Balancer SKU](https://docs.microsoft.com/azure/load-balancer/load-balancer-standard-overview) and then do the following;
445
445
446
+
> [!NOTE]
447
+
> The Standard Load Balancer SKU has restrictions accessing public IP addresses from the nodes underneath the Load Balancer. The article [Public endpoint connectivity for Virtual Machines using Azure Standard Load Balancer in SAP high-availability scenarios](https://docs.microsoft.com/azure/virtual-machines/workloads/sap/high-availability-guide-standard-load-balancer-outbound-connections) is describing ways on how to enable those nodes to access public IP addresses
448
+
449
+
450
+
446
451
1. Create a front-end IP pool:
447
452
448
453
a. In the Azure portal, open the Azure Load Balancer, select **frontend IP pool**, and then select **Add**.
Copy file name to clipboardExpand all lines: articles/virtual-machines/workloads/sap/high-availability-guide.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -719,7 +719,7 @@ _**Figure 11:** Set SAP high-availability Azure Resource Manager parameters_
719
719
>
720
720
721
721
### <aname="c87a8d3f-b1dc-4d2f-b23c-da4b72977489"></a> Deploy virtual machines with corporate network connectivity (cross-premises) to use in production
722
-
For production SAP systems, deploy Azure virtual machines with [corporate network connectivity (cross-premises)][planning-guide-2.2] by using Azure Site-to-Site VPN or Azure ExpressRoute.
722
+
For production SAP systems, deploy Azure virtual machines with corporate network connectivity by using Azure Site-to-Site VPN or Azure ExpressRoute.
723
723
724
724
> [!NOTE]
725
725
> You can use your Azure Virtual Network instance. The virtual network and subnet have already been created and prepared.
@@ -864,7 +864,7 @@ To set the required DNS IP addresses, do the following steps.
864
864
865
865
1. In the Azure portal, on the **DNS servers** blade, make sure that your virtual network **DNS servers** option is set to **Custom DNS**.
866
866
2. Select your settings based on the type of network you have. For more information, see the following resources:
867
-
*[Corporate network connectivity (cross-premises)][planning-guide-2.2]: Add the IP addresses of the on-premises DNS servers.
867
+
* Add the IP addresses of the on-premises DNS servers.
868
868
You can extend on-premises DNS servers to the virtual machines that are running in Azure. In that scenario, you can add the IP addresses of the Azure virtual machines on which you run the DNS service.
869
869
* For deployments isolated in Azure: Deploy an additional virtual machine in the same Virtual Network instance that serves as a DNS server. Add the IP addresses of the Azure virtual machines that you've set up to run DNS service.
0 commit comments