Laboratorio práctico — AZ-120 Microsoft Azure for SAP Workloads Specialty

Descripción general

Requisitos previos

Pasos

1. 1.Proveedor, Grupo de recursos, nomenclatura

   Apertura estándar de Azure. El AZ-120 espera que elijas una región certificada para SAP y que sea compatible con las VMs de la serie M que necesitarás: eastus2, westeurope, northeurope son las apuestas más seguras.

   Copiar

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
     }
   }
   
   provider "azurerm" {
     features {}
   }
   
   locals {
     tags = {
       Project   = "certlabpro-az-120"
       ManagedBy = "terraform"
       Workload  = "SAP"
     }
   }
   
   resource "azurerm_resource_group" "main" {
     name     = "certlabpro-az-120-rg"
     location = "eastus2"
     tags     = local.tags
   }

2. 2.Construir la VNet de SAP con subredes de aplicación + base de datos

   Aprovisiona:

   • Azure Virtual Network

   Las arquitecturas de SAP en Azure separan los servidores de aplicaciones (CPU media, memoria modesta) de la base de datos HANA (memoria muy grande) en subredes distintas, generalmente con NSG más estrictos en la capa de base de datos. El AZ-120 prueba esta separación de capas: la subred de aplicación expone los servicios de SAP a los usuarios (o a un equilibrador de carga); la subred de base de datos es solo interna, accesible solo desde la capa de aplicación.

   Definimos las subredes app y db a partir de una VNet /16. Los NSG están fuera del alcance del laboratorio (sería sencillo añadirlos, el mismo patrón que el Paso 2 de AZ-104).

   Copiar

   resource "azurerm_virtual_network" "sap" {
     name                = "vnet-sap"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     address_space       = ["10.0.0.0/16"]
     tags                = local.tags
   }
   
   resource "azurerm_subnet" "app" {
     name                 = "app"
     resource_group_name  = azurerm_resource_group.main.name
     virtual_network_name = azurerm_virtual_network.sap.name
     address_prefixes     = ["10.0.1.0/24"]
   }
   
   resource "azurerm_subnet" "db" {
     name                 = "db"
     resource_group_name  = azurerm_resource_group.main.name
     virtual_network_name = azurerm_virtual_network.sap.name
     address_prefixes     = ["10.0.2.0/24"]
   }

3. 3.Crear un Grupo de ubicación por proximidad + Conjunto de disponibilidad para la capa de aplicación

   Aprovisiona:

   • Azure Compute

   Los Grupos de ubicación por proximidad (PPG) son la respuesta del AZ-120 para el diseño e implementación de infraestructura para soportar SAP con latencia ultrabaja entre los servidores de aplicaciones SAP y HANA. Las VMs coubicadas en PPG aterrizan en el mismo centro de datos (literalmente el mismo rack), ofreciendo una latencia entre VMs inferior a 1 ms, lo cual es necesario para la comunicación entre aplicaciones y HANA de SAP.

   Los Conjuntos de disponibilidad agrupan VMs en dominios de error (carriles de energía/red separados) dentro de un único centro de datos. La combinación — PPG para la latencia, Conjunto de disponibilidad para la tolerancia a fallos — es la forma de referencia del AZ-120 para la capa de aplicación de SAP. (Para la disponibilidad zonal, Azure ahora también admite la ubicación de todas las VMs en la misma Zona de disponibilidad mediante PPG + zona, el patrón más moderno).

   Copiar

   resource "azurerm_proximity_placement_group" "sap" {
     name                = "ppg-sap"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
   
     tags = local.tags
   }
   
   resource "azurerm_availability_set" "app" {
     name                         = "avset-sap-app"
     resource_group_name          = azurerm_resource_group.main.name
     location                     = azurerm_resource_group.main.location
     platform_fault_domain_count  = 2 # max for the region
     platform_update_domain_count = 5
     proximity_placement_group_id = azurerm_proximity_placement_group.sap.id
     managed                      = true
   
     tags = local.tags
   }

4. 4.Aprovisionar previamente la forma de almacenamiento SSD premium para HANA

   Aprovisiona:

   • Azure Managed Disks

   El almacenamiento de HANA requiere SSD premium o superior (nivel de la serie P) para las cargas de trabajo de producción; las especificaciones de IOPS y rendimiento certificadas por SAP asumen discos P30+ para los datos/logs de HANA. El examen AZ-120, en su sección Diseñar e implementar infraestructura para soportar SAP, evalúa la selección del nivel de disco como una compensación recurrente entre coste y rendimiento.

   Aprovisionamos un disco gestionado P10 (128 GB) como demostración de forma: pequeño y barato, pero del mismo tipo de cuenta de almacenamiento Premium_LRS que usaría un disco HANA de producción. Adjuntarlo a una VM es un paso aparte (fuera del alcance aquí). Para HANA en producción, usarías discos P30/P40 y los agruparías mediante LVM para el rendimiento que SAP exige.

   Copiar

   resource "azurerm_managed_disk" "hana_data_shape" {
     name                 = "disk-hana-data-shape"
     resource_group_name  = azurerm_resource_group.main.name
     location             = azurerm_resource_group.main.location
     storage_account_type = "Premium_LRS" # SAP-certified storage tier
     create_option        = "Empty"
     disk_size_gb         = 128 # P10 size — demonstration only; production HANA uses P30+
   
     tags = local.tags
   }

5. 5.Agregar una zona DNS privada para los nombres de host de SAP

   Aprovisiona:

   • Azure Private DNS

   Las instalaciones de SAP dependen en gran medida de nombres de host estables y predecibles (sapha01, sapha02, sapdb01). Tanto el SAPHostAgent como la replicación del sistema HANA requieren una resolución de nombres de host consistente. La sección Diseñar e implementar soluciones de cómputo y almacenamiento de Azure del examen AZ-120 evalúa Private DNS como la solución para la estabilidad de nombres de host dentro de la VNet sin edición manual de /etc/hosts.

   Creamos la zona SAP y la enlazamos a la VNet del Paso 2 con registration_enabled = true para que las VMs de SAP registren automáticamente sus nombres de host. Con esta última pieza en su lugar, el andamio está completo: VNet con subredes escalonadas, PPG que ancla la coubicación, Conjunto de disponibilidad para la tolerancia a fallos, forma de disco premium para el almacenamiento de HANA, Private DNS para la estabilidad de los nombres de host. Las VMs de SAP se despliegan en esta base mediante recursos estándar azurerm_linux_virtual_machine.

   Copiar

   resource "azurerm_private_dns_zone" "sap" {
     name                = "sap.internal"
     resource_group_name = azurerm_resource_group.main.name
   
     tags = local.tags
   }
   
   resource "azurerm_private_dns_zone_virtual_network_link" "sap" {
     name                  = "sap-vnet-link"
     resource_group_name   = azurerm_resource_group.main.name
     private_dns_zone_name = azurerm_private_dns_zone.sap.name
     virtual_network_id    = azurerm_virtual_network.sap.id
     registration_enabled  = true
   
     tags = local.tags
   }

Limpieza