Atelier pratique — AZ-120 Microsoft Azure for SAP Workloads Specialty

Présentation

Prérequis

Étapes

1. 1.Fournisseur, Groupe de ressources, dénomination

   Ouverture Azure standard. AZ-120 vous demande de choisir une région certifiée pour SAP et qui prend en charge les machines virtuelles de série M dont vous aurez besoin — eastus2, westeurope, northeurope sont les paris les plus sûrs.

   Copier

   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.Construire le VNet SAP avec les sous-réseaux d'application + base de données

   Déploie :

   • Azure Virtual Network

   Les architectures SAP sur Azure séparent les serveurs d'applications (CPU moyen, mémoire modeste) de la base de données HANA (très grande mémoire) en sous-réseaux distincts — généralement avec des NSG plus stricts sur le niveau de la base de données. AZ-120 teste cette séparation des niveaux : le sous-réseau d'application expose les services SAP aux utilisateurs (ou à un équilibreur de charge) ; le sous-réseau de base de données est uniquement interne, accessible uniquement depuis le niveau d'application.

   Nous créons les sous-réseaux app et db à partir d'un VNet en /16. Les NSG sont hors du cadre de ce labo (ils seraient simples à ajouter — même modèle qu'à l'étape 2 de l'AZ-104).

   Copier

   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.Créer un Groupe de Placement de Proximité + un Groupe à Haute Disponibilité pour le niveau applicatif

   Déploie :

   • Azure Compute

   Les Groupes de Placement de Proximité (PPG) sont la réponse de l'AZ-120 en matière de Conception et implémentation d'infrastructures pour supporter SAP pour une latence ultra-faible entre les serveurs d'applications SAP et HANA. Les machines virtuelles co-localisées via PPG atterrissent dans le même centre de données (littéralement la même baie), offrant une latence inter-VM inférieure à 1 ms — requise pour la communication SAP-HANA.

   Les Groupes à Haute Disponibilité (Availability Sets) regroupent les machines virtuelles sur plusieurs domaines de panne (rails d'alimentation/réseau distincts) au sein d'un même centre de données. La combinaison — PPG pour la latence, Groupe à Haute Disponibilité pour la tolérance aux pannes — est la forme de référence AZ-120 pour le niveau d'application SAP. (Pour la disponibilité zonale, Azure prend désormais également en charge le placement de toutes les machines virtuelles dans la même Zone de Disponibilité via PPG + zone — le modèle plus moderne.)

   Copier

   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.Pré-provisionner la forme de stockage SSD premium pour HANA

   Déploie :

   • Azure Managed Disks

   Le stockage de HANA nécessite un SSD premium ou supérieur (niveau série P) pour les charges de travail de production — les spécifications IOPS et de débit certifiées SAP supposent des disques P30+ pour les données/journaux HANA. La section Conception et implémentation d'infrastructures pour supporter SAP de l'AZ-120 teste la sélection du niveau de disque comme un compromis coût/performance récurrent.

   Nous provisionnons un disque géré P10 (128 Go) comme une démonstration de forme — petit + bon marché, mais du même type de compte de stockage Premium_LRS qu'un disque HANA de production utiliserait. L'attacher à une VM est une étape distincte (hors du cadre ici). Pour HANA de production, vous utiliseriez des disques P30 / P40 et en striperiez plusieurs via LVM pour le débit que SAP exige.

   Copier

   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.Ajouter une zone DNS privée pour les noms d'hôte SAP

   Déploie :

   • Azure Private DNS

   Les installations SAP reposent fortement sur des noms d'hôte stables et prévisibles (sapha01, sapha02, sapdb01) — le SAPHostAgent et la réplication de système HANA exigent tous deux une résolution de nom d'hôte cohérente. La section Conception et implémentation de solutions de calcul et de stockage Azure de l'AZ-120 teste le DNS privé comme réponse pour la stabilité des noms d'hôte intra-VNet sans édition manuelle de /etc/hosts.

   Nous créons la zone SAP et la lions au VNet de l'étape 2 avec registration_enabled = true afin que les machines virtuelles SAP enregistrent automatiquement leurs noms d'hôte. Avec cette dernière pièce en place, l'échafaudage est complet : VNet avec sous-réseaux étagés, PPG ancrant la co-localisation, Groupe à Haute Disponibilité pour la tolérance aux pannes, forme de disque premium pour le stockage HANA, DNS privé pour la stabilité des noms d'hôte. Les machines virtuelles SAP se déploient dans cette base via des ressources azurerm_linux_virtual_machine standard.

   Copier

   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
   }

Nettoyage