Please enable JavaScript.

Coggle requires JavaScript to display documents.

Microsoft Certified: Azure for SAP Workloads Specialty - Coggle Diagram

- - - - General purpose
        
        providing balanced CPU-to-memory ratio, ideal for testing and development, small to medium databases, and low to medium traffic web servers.
      - Compute optimized
        
        providing high CPU-to-memory ratio, good for medium traffic web servers, network appliances, batch processes, and application servers.
      - Memory optimized
        
        providing high memory-to-CPU ratio, great for relational database servers, medium to large caches, and in-memory analytics.
      - Storage optimized
        
        providing high disk throughput and IO, ideal for Big Data, SQL, NoSQL databases, data warehousing, and large transactional databases.
      - GPU
        
        roviding specialized virtual machines targeted for heavy graphic rendering and video editing, as well as model training and inferencing (ND) with deep learning, available with single or multiple GPUs.
      - High performance compute
        
        providing the fastest and most powerful CPU Azure VMs with optional high-throughput network interfaces (RDMA).
    - - Number of vCPUs
      - Amount of memory
      - Maximum number of data disks
      - Maximum network and storage throughput
      - Limits
        
        There is a 2 terabyte (TB) size limit on a virtual disk hosting the operating system of an Azure VM and a 32-TB size limit on any additional virtual disk that users attach to an Azure VM (Ultra SSD disks, in preview at the time of authoring of this content, will offer disk sizes of up to 64 TB).
        
        A limit also exists on the throughput and input/output operations per second (IOPS) that individual disks support. With Standard HDD storage, users can expect about 60 megabytes per second (MBps) or 500 8 kilobyte (KB) IOPS. With Azure Premium SSD storage, performance depends on the disk size, with 32-TB disks supporting up to 900 MBps and 20,000 256-KB IOPS (Ultra SSD storage will offer 2,000 MBps and 160,000 IOPS per disk, regardless of its size).
    - - Azure VMs:
        
        There is a growing number of Azure VM SKUs certified for hosting SAP HANA including GS5
      - SAP HANA on Azure (Large Instances):
        
        There are several SKUs ranging from 2 TiB per node (S192 with scale-out support) to 20 TiB per node (S960m). Two different classes of hardware divide the SKUs into:
        
        "Type I class" of SKUs.
        
        "Type II class" of SKUs.
      - SAP Cloud Appliance Library (CAL):
        
        SAP CAL offers pre-configured software appliances on different public clouds, including Azure. The primary benefit of SAP CAL is that it provides an easy way to deploy and test pre-configured SAP solutions offered by SAP without having to provision underlying infrastructure. SAP CAL on Azure includes support for SAP S/4HANA or BW/4HANA.
  - - - ailing over to another replica and seeding of a new replica in case of a storage node failure is transparent. As a result of this redundancy, it is NOT required to use any kind of storage redundancy layer across multiple Azure disks. This is called Local Redundant Storage (LRS). LRS is the default for these types of storage in Azure.
    - - Managed Disks automatically align with the availability set of the virtual machine they are attached to and therefore increase the availability of your virtual machine and the services that are running on the virtual machine.
    - - Persisted storage for the base VHD of your VM that holds the operating system and other software you install in that disk.
      - Persisted data disks. These disks are VHDs you attach to store application data in. This application data could be data and log/redo files of a database, backup files, or software installations
      - File shares or shared disks that contain your global transport directory for NetWeaver or S/4HANA.
      - The /sapmnt directory or common file shares for EDI processes or similar. Content of those shares is either consumed by software running in multiple VMs or is used to build high-availability failover cluster scenarios.
    - - Azure premium storage is one of the Azure storage types recommended for SAP workload. This recommendation applies for non-production as well as production systems. Azure premium storage is suited to handle database workloads
    - - For Azure premium storage disks smaller or equal to 512 GiB in capacity, burst functionality is offered.
        
        Low to moderate read workload since data ideally is cached in memory, or like in the case of HANA should be completely in memory
        
        Bursts of write triggered by database checkpoints or savepoints that are issued on a regular basis
        
        Backup workload that reads in a continuous stream in cases where backups are not executed via storage snapshots
        
        For SAP HANA, load of the data into memory after an instance restart
        
        Regular writes to the disk that are dependent on the workload and the nature of workload since every commit issued by the application is likely to trigger an I/O operation
        
        Higher workload in throughput for cases of operational tasks, like creating or rebuilding indexes
        
        Read bursts when performing transaction log or redo log backups
    - - Azure ultra disks are a suitable storage with low latency for all kinds of SAP workload. So far, Ultra disk can only be used in combinations with VMs that have been deployed through Availability Zones (zonal deployment). Ultra disk does not support storage snapshots at this time. Unlike other storage, Ultra disk cannot be used for the base VHD disk. Ultra disk is ideal for cases where I/O workload fluctuates a lot and you want to adapt deployed storage throughput or IOPS to storage workload patterns instead of sizing for maximum usage of bandwidth and IOPS.
    - - Azure standard SSD storage is the minimum recommendation for non-production VMs for base VHD, eventual DBMS deployments with relative latency insensitivity and/or low IOPS and throughput rates.
    - - Standard HDD is an Azure storage type that should only be used to store SAP backups. It should only be used as base VHD for rather inactive systems, like retired systems used for looking up data here and there. But no active development, QA or production VMs should be based on that storage. Nor should database files being hosted on that storage
    - - The smaller the VM, the fewer disks you can attach. This does not apply to ANF. Since you mount NFS or SMB shares, you don't encounter a limit of number of shared volumes to be attached
        
        VMs have I/O throughput and IOPS limits that easily could be exceeded with premium storage disks and Ultra disks
        
        With ANF, the traffic to the shared volumes is consuming the VM's network bandwidth and not storage bandwidth
        
        With large NFS volumes in the double digit TiB capacity space, the throughput accessing such a volume out of a single VM is going to plateau based on limits of Linux for a single session interacting with the shared volume.
    - - WHAT?