Blogs by Ashwin

  To read part 2 please click  here To read part 3 please click  here To read part 4 please click  here   High Availability of SAP Workloads High availability of SAP workloads on azure VMs can be analyzed by two different ways: High availability of SAP workloads consists of- SAP application servers SAP ASCS/SCS instance DBMS server  High availability capabilities of Azure infrastructure includes- Azure VM restart capability (significantly important in single-VM scenarios). High availability of compute (VMs), network, and storage, based on availability sets and zones. Note- As these two context compliments each other, then you should design by combining the benefits of both of them.  Failover Clustering A failover cluster is known as a group of independent servers that works together to increase the availability of applications as well as services, and if a node failure occurs, it can perform node arbitration which will transfer the workload to one of t...

  Ultra Disk A new Azure storage type called Azure Ultra Disk will be soon introduced by Microsoft whose capabilities are not bound to the disk size anymore and you can define these capabilities as follows: Size of a disk ranging from 4 GiB to 65,536 GiB IOPS range from 100 IOPS  to 160K IOPS (maximum depends on the VM types as well) Storage throughput from 300 MB/sec to 2000 MB/sec  It allows you to define a single disk that fulfills your size, IOPS, as well as disk throughput range while running a configuration mix between Ultra disk and Premium Storage which also results in limiting the usage of Ultra Disk to the performance critical /hana/data as well as /hana/log volumes while covering the other volumes with Azure Premium Storage. It also offers better read latency as compared to Premium Storage which is advantageous when you want to reduce the HANA startup time and the subsequent load of the data into memory.  Production recommended storage solution with pure U...

  SAP HANA Azure VM Storage Configurations Azure offers different SAP HANA certified Azure Storage types for SAP HANA deployments such as Azure Premium SSD, Ultra Disk, and  Azure NetApp Files while also providing two deployment methods for VHDs on Azure Standard and Premium Storage. The minimum requirement of SAP HANA certified for different storage types are as follows: Azure Premium SSD- /hana/log can be cached with Azure Write Accelerator whereas /hana/data volume can be placed on Premium SSD without Azure Write Accelerator or on Ultra Disk. vAzure Ultra disk at least for the /hana/log volume- It can be palced on either Premium SSD without Azure Write Accelerator or in order to get faster restart times Ultra Disk. NFS v4.1- Volumes on top of Azure NetApp Files for /hana/log and /hana/data. In an on-premises world you rarely care about I/O subsystems and its capabilities because the appliance vendor has to make sure that the minimum storage requirements are met for SAP HANA...

  To read part 1 please click  here To read part 2 please click  here To read part 3 please click  here To read part 4 please click  here SQL Server 2014 Buffer Pool Extension It introduced a new feature which is called Buffer Pool Extension whose functionality extends the buffer pool of SQL Server, which is kept in memory with a second-level cache that is backed by local SSDs of a server or VM. If we compare Buffer Pool Extension to Azure Premium Storage Read Cache, no significant advantages are expected for Buffer Pool Extensions, as recommended for (SQL Server data files) because both caches are using the local disks of the Azure compute node. SQL Server Buffer Pool Extension's experiences with SAP workloads is mixed an does not give any clear recommendation on whether to use it on all cases. Hence, its usage is limited to some rare cases and should not be a mainstream case. Oracle According the SAP installation manual, Oracle-related files shouldn't be insta...

  To read part 1 please click  here To read part 2 please click  here To read part 3 please click  here To read part 5 please click  here Ultra SSD A new Azure Storage type called Azure Ultra SSD is in the process of introduction by Microsoft and its disk capabilities are not bound to the disk size which mainly differentiate it from Azure Storage. You can also define the following capabilities for Ultra SSD: Size of a disk ranging from 4 GiB to 65,536 GiB IOPS range from 100 IOPS to 160K IOPS (maximum depends on the VM SKU) Storage throughput from 300 MB/sec to 2,000 MB/sec  You have an option of attaching both UltraSSD and Premium Storage disks to the same Azure VMs which helps you to restrict the usage of UltraSSD for the performance critical/hana/data and /hana/log/volumes as well as implement other volumes with Premium Storage. SAP HANA Dynamic Tiering 2.0 It provides the ability to offload less frequently access data from memory into extended storage, ...

  To read part 1 please click  here To read part 2 please click  here To read part 4 please click  here To read part 5 please click  here Azure VM Storage Considerations While planning your disk layout you can find optimal configuration with the help of following factors: The number of data files The number of disks that contain the files The IOPS quotas of a single disk The data throughput per disk The number of additional data disks possible per VM size The number of storage throughput a VM can provide The latency difference an Azure Storage type can provide VM SLAs Paging/Swap Files While configuring the paging/swap files you should use the following recommendations: Windows operating system pagefile should reside on the D: drive (i.e. non-persistent disk) Linux swapfile should reside under/mnt/resource and can be configured in the configuration file of the Linux Agent/etc/waagent.conf; you can also add or change the following settings- ResourceDisk.EnableSwa...

  To read part 1 please click  here To read part 3 please click  here To read part 4 please click  here To read part 5 please click  here Load Balancing The load balancer uses probe ports to determine as well as route the traffic to an active DBMS node, but of there's any failover then the most common SAP application architecture can automatically reconnect against the private virtual IP address without the need for the SAP application to reconfigure it, while the load balancer redirect the traffic against the private virtual IP address without any need for the SAP application to reconfigure. The loaf balancer also offers an option of DirectServerReturn which if configured, can help in directing the traffic from the DBMS VM to the SAP application layer directly to the application layer without routing through the load balancer. But, if it isn't configured, then the return traffic to the SAP application layer is routed through the load balancer. You can also use ...