Posts

Showing posts from August, 2021

SAP HANA on Azure (Large Instances) compute, network, & storage (part 1)

Image
  To read part 2 please click  here To read part 3 please click  here Compute Considerations A compute unit can equal one server or blade, and a stamp is made up of multiple servers or blades in which servers are not shared but are dedicated to running one customer's deployment of SAP HANA. A variety of SKUs are available for HANA Large Instances while supporting up to 20 TB single instance of memory for S/4 HANA or other SAP HANA workloads. Two classes of servers are provided: "Type I class" of SKUs consisting of S72, S72m, S96, S144, S144m, S192, S192m, and S192xm. "Type II class" of SKUs consisting of S384, S394m, S384xm, S384xxm, S576m, S576xm, S768m, S768xm, and S960m. As the data volume grows the memory requirement for HANA increases. You should be aware of your current memory consumption so you can predict its future. According to the memory requirements, you can map your demands into one of the HANA Large Instance SKUs.  Storage Considerations Storage la

Azure VM Authentication & Access Control Considerations

Image
  Azure VM Authentication, Authorization, & Access Control Active Directory for on-premises can be easily extended to serve as the authentication mechanism through an Azure deployed domain controller especially in cross-premises scenarios. Microsoft Azure Active Directory offers only a subset of the traditional on-premises AD features that includes identity and access management but doesn't have the full AD schema or services that many third party application take advantage of. Advantage of Azure AD can be taken to enable single-sign-on (SSO) to your S/4 HANA Fiori Launchpad. SAP HANA, and SAP NetWeaver-based applications. Control Access to resources by using a centralized identity management system at all levels: Provide access to Azure resources through role-based access control (RBAC). Grant access to Azure VMs through LDAP, Azure AD, Kerberos or another system. Support access within the app themselves through the services that SAP provides or use OAuth 2.0 & Azure AD. 

Azure VM Security Considerations

Image
  Azure VM Security  If you want to encrypt Azure VM disks, you can use Azure Disk Encryption which uses the BitLocker feature of Windows and DM-Script for Linux to provide volume encryption for the operating system as well as data disks. This solution also works with Azure Key Vault which in turn helps you to control as well as manage the disk encryption keys and secrets. However, it is recommended to use SAP HANA native encryption technology for SAP HANA data-at-rest encryption.  Note- You should not use the HANA data-at-rest encryption with Azure Disk encryption on the same server, instead use only HANA data encryption for HANA. SQL Server Transparent Data Encryption (TDE) The SQL server TDE functionality is fully supported by SAP. Applying SQL Server TDE If you want to perform a heterogeneous migration from another DBMS, running on-premise, to Windows/SQL Server running in Azure, you can create your empty target database in SQL server before time. After that, you can easily apply S

Azure VM Monitoring Considerations

Image
  Azure VM Monitoring Considerations Microsoft has decided to not generally implement the needed functionality into Azure, instead let the customers to deploy the necessary monitoring components and configurations to their Azure VMs, as the monitoring demanded by SAP were particularly specific to SAP applications. However, the deployment and lifecycle management of the monitoring components can be mostly automated by Azure. To enable SAP monitoring, the solution developed is solely based on the concept of Azure VM Agent and its extensions. The main idea behind this approach is to let (especially in cases like the Azure Monitoring Extension for SAP) the deployment of special functionality into a VM as well as the configuration of such software at deployment time, while the extension is needed for the SAP workloads to be supported on Azure VMs. The 'Azure VM Agent' that allows you to handle the specific Azure VM Extensions within the VM is introduced to the Windows VMs by default

Azure VM Backup Considerations (part 2)

Image
  To read part 1 please click  here   SQL Server Backup SQL server can be backed up by using the following: Performing conventional SQL Server backups onto direct attached Azure disks- Through this approach you can easily have the backups available swiftly for system refreshes and build up of new systems as copies of existing SAP systems. You should either use Azur Backup Services or another third party backup/recovery tool that includes access and retention management for your backups. SQL Server backup to URL- Starting with SQL server 2012 CU4, the native SQL Server backup can designate an Azure storage URL and its destination. Automated backup v2 for Azure VMs-  This one uses SQL IaaS Agent Extension to automatically configure Managed Backup to Azure storage for all existing and new databases on an Azure VM running SQL server 2016/2017 Standard, Enterprise or Developer editions. SQL Server backup in Azure VMs- It extensively uses AzureBackupWindowsWorkload VM extension, which levera

Azure VM Backup Considerations (part 1)

Image
  To read part 2 please click  here Application Backup SAP applications hosted by VMs can be easily backed up using Azure backup whose agents supports throttling utilized during backups and restores. Azure backup completes a  backup by using following ways for Azure VMs: Azure backup always start the backup job according to the backup schedule you specify for the Azure VMs selected for backups. A backup extension is installed on the VM if the VM is running during the first backup. After the backup takes the snapshot, it transfers the data to the vault. When the data transfer is complete, the snapshot is removed, and a recovery point is created.  Database Backup Azure VM-based DBMS' backup can be performed by using DBMS-specific methods which should also facilitate the ability to restore it to any point in time. To achieve this capability two types of backups must be performed: Database full & differential backups Transaction log backups Besides the full database backups perform

Azure VM High Availability & Disaster Recovery (part 4 of 4)

Image
  To read part 1 please click  here To read part 2 please click  here To read part 3 please click  here SAP HANA Disaster Recovery Simple availability between two Azure regions If you want to use sharing the DR target with a QA system in one VM scenario, you should consider the following: There are two operation modes with delta_datashipping with logreplay, which are readily available for such a scenario. Both operation modes have different memory requirements without preloading data. Delta_datashipping might require drastically less memory without the preload option that logreplay could require. The logreplay operation mode's memory requirement without preload is not deterministic and depends on the columnstore structures loaded. You can make a small change in the configuration by configuring data as preloading, but. it might not make sense to preload data because of the manual nature of the failover and the fact that the application layers also needs to move to the second region.

Azure VM High Availability & Disaster Recovery (part 3)

Image
  To read part 2 please click  here To read part 1 please click  here To read part 4 please click  here Availability Zones The following should be accounted while considering availability zones: There is no guarantee with respect to the distances between various Availability Zones within an Azure region. Availability Zones are not an ideal DR solution as natural disasters can cause widespread damage in world regions including heavy damage to power infrastructures.  The network latency across Availability Zones is not the same in all Azure regions as in some cases the SAP application layer can be deployed and run across different zones because the network latency from one zone to the active DBMS VM is acceptable. Network latency plays an important role in two areas i.e.- Latency between the two DBMS instances that need to have synchronous replication. The higher the network latency, the more likely it will affect the scalability of your workload. As the difference in network latency bet

Azure VM High Availability & Disaster Recovery (part 2)

Image
  To read part 1 please click  here To read part 3 please click  here To read part 4 please click  here High-availability of SAP application servers High-availability can be simply achieved by redundancy through installing individual application servers on separate Azure VMs with at least two SAP application instances installed in two instances of Azure VMs. An Azure availability set can ensure that: Each Azure belongs to a different upgrade domain  ensuring that Hyper-V hosts hosting these VMs aren't updated at the same time during planned maintenance events that needs a temporary downtime. Each Azure VM belongs to a different fault domain ensuring that VMs are deployed such that a localized rack-level failure does not affect the availability of all Azure VMs.  High-availability of SAP ASCS-SCS instance Additional provisions are needed by Azure VMs to implement the operating system-dependent clustering capabilities: High-availability architecture for SAP ASCS/SCS instance on Windo