נבדק לאחרונה: מאי 2026
בנו את שירותי AWS של בחינת AZ-120 עם Terraform פשוט — בלוק אחד בכל פעם, כאשר כל אחד מהם מקושר בחזרה לתחום במבחן. אותו הקוד עובד גם ב-OpenTofu.
עד סוף מעבדת ההדגמה הזו, תקצה, באמצעות Terraform רגיל, את שלד ארכיטקטורת הייחוס של Azure SAP — רשת וירטואלית (VNet) עם תתי-רשתות עבור אפליקציות ובסיסי נתונים (DB), קבוצת מיקום קרובה (Proximity Placement Group) המעגנת משאבים משותפים לתעבורת SAP <-> HANA עם שיהוי נמוך, קבוצת זמינות (Availability Set) עבור תחומי התקלה של שכבת היישומים, תצורת דיסק מנוהל פרימיום SSD עבור דרישות האחסון של HANA, ואזור DNS פרטי עבור שמות המארח של SAP.
אנו נמנעים בכוונה מהקצאת ה-VMs הגדולים המאושרים על ידי SAP (סדרות Mv2 / E, בקלות $1000+ לחודש). לאחר ששלד זה קיים, מכונות SAP VM מתחברות לקבוצת הזמינות + קבוצת המיקום הקרובה + תצורת הדיסק באמצעות משאבי azurerm_linux_virtual_machine סטנדרטיים בגודל מתאים.
הכנס את הקטעים לקובץ main.tf יחיד, הפעל terraform init, ולאחר מכן terraform apply צעד אחר צעד.
>= 1.5 או OpenTofu >= 1.6.az login).שלד המעבדה הוא למעשה בחינם (אין VMs):
כ-20$ לחודש במצב סרק עבור הדיסק בלבד. אם תפרוס בפועל VMs מאושרים על ידי SAP (לסדרת Mv2 יש 2-12 TB RAM, לסדרת E יש 64+ GB RAM), צפה ל-$1,000–$15,000 לחודש ל-VM. אל תספק VMs של SAP במנויי מעבדה אלא אם חתמת על התחייבות תקציב Azure אמיתית.
פתיחה סטנדרטית של Azure. AZ-120 מצפה ממך לבחור אזור המאושר עבור SAP ותומך במכונות וירטואליות מסוג M-series שתזדקק להן — eastus2, westeurope, northeurope הם ההימורים הבטוחים ביותר.
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
}ארכיטקטורות SAP ב-Azure מפרידות שרתי יישומים (CPU בינוני, זיכרון צנוע) מבסיס הנתונים של HANA (זיכרון גדול מאוד) לתתי-רשתות נפרדות — לרוב עם NSGs מחמירים יותר בשכבת ה-DB. AZ-120 בודק הפרדת שכבות זו: תת-רשת האפליקציה חושפת שירותי SAP למשתמשים (או למאזן עומסים); תת-רשת ה-DB היא פנימית בלבד, נגישה רק משכבת האפליקציה.
אנו מקצים תתי-רשתות app ו-db מתוך VNet בגודל /16. NSGs אינם כלולים בהיקף המעבדה (ניתן יהיה להוסיף אותם בקלות — באותו דפוס כמו שלב 2 ב-AZ-104).
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"]
}קבוצות מיקום קרובות (PPGs) הן התשובה של AZ-120 ל-תכנון ויישום תשתית לתמיכה ב-SAP עבור שיהוי נמוך במיוחד בין שרתי יישומים של SAP ל-HANA. VMs הממוקמים יחד ב-PPG נוחתים באותו מרכז נתונים (פשוטו כמשמעו באותו מתקן), ומעניקים שיהוי של פחות מ-1ms בין VMs — נדרש לתקשורת HANA-אפליקציה של SAP.
קבוצות זמינות (Availability Sets) מקבצות VMs על פני תחומי תקלות (מסילות חשמל/רשת נפרדות) בתוך מרכז נתונים יחיד. השילוב — PPG לשיהוי, Availability Set לסבילות תקלות — הוא תצורת הייחוס של AZ-120 עבור שכבת היישומים של SAP. (עבור זמינות אזורית, Azure תומך כעת גם במיקום כל ה-VMs באותו אזור זמינות באמצעות PPG + אזור — התבנית המודרנית יותר).
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
}האחסון של HANA דורש SSD פרימיום או גבוה יותר (שכבת P-series) עבור עומסי עבודה של ייצור — מפרטי ה-IOPS והתפוקה המאושרים על ידי SAP מניחים דיסקים P30+ עבור נתוני/יומן HANA. AZ-120 בוחן את בחירת שכבת הדיסק כפשרה בין עלות מתמשכת לביצועים במסגרת תכנון ויישום תשתית לתמיכה ב-SAP.
אנו מקצים דיסק מנוהל P10 אחד (128 GB) כהדגמת תצורה — קטן + זול, אך מאותו סוג חשבון אחסון Premium_LRS שדיסק HANA בייצור ישתמש בו. חיבורו למכונה וירטואלית הוא שלב נפרד (מחוץ להיקף כאן). עבור HANA בייצור, תשתמש בדיסקים P30 / P40 ותפספס מספר דיסקים יחד באמצעות LVM עבור התפוקה ש-SAP דורשת.
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
}התקנות SAP מסתמכות במידה רבה על שמות מארח יציבים וצפויים (sapha01, sapha02, sapdb01) — גם ה-SAPHostAgent וגם ה-HANA System Replication דורשים פתרון שמות מארח עקבי. AZ-120 בוחן את Private DNS במסגרת תכנון ויישום פתרונות מחשוב ואחסון של Azure כתשובה ליציבות שמות מארח בתוך VNet ללא עריכה ידנית של /etc/hosts.
אנו יוצרים את אזור SAP ומקשרים אותו ל-VNet משלב 2 עם registration_enabled = true כך שמכונות SAP VM ירשמו את שמות המארח שלהן באופן אוטומטי. עם החלק האחרון הזה במקום, השלד הושלם: VNet עם תתי-רשתות מדורגות, PPG המעגן מיקום משותף, Availability Set לסבילות תקלות, תצורת דיסק פרימיום לאחסון HANA, Private DNS ליציבות שמות מארח. מכונות SAP VM נפרסות לבסיס זה באמצעות משאבי azurerm_linux_virtual_machine סטנדרטיים.
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
}terraform destroy מפרק הכל. הדיסק המנוהל הפרימיום (20$ לחודש) הוא פריט החיוב היחיד שפועל 24/7 — מחק אותו במהירות. PPG ו-Availability Set הם מטא-דאטה בלבד ונמחקים באופן מיידי. אזורי Private DNS ללא רשומות נמחקים בצורה נקייה.
AZ-120 מכסה נושאים ספציפיים ל-SAP שמעבדה זו אינה יכולה להכיל — מכונות ה-VM בפועל של SAP (סדרת Mv2 עבור HANA במחיר של 5,000–15,000$ לחודש כל אחת, סדרת E עבור שרתי יישומים), HANA Large Instances (HANA חשוף-מתכת על חומרה מנוהלת על ידי Azure), SAP על Azure HA + DR (אשכולות Pacemaker של ASCS/ERS), Azure NetApp Files (NFS ברמת פרימיום עבור /hana/shared), ExpressRoute לקישוריות היברידית, Azure Site Recovery ל-DR בין אזורים, Azure Backup עבור SAP HANA, Azure Monitor עבור פתרונות SAP (הרחבת הניטור הספציפית ל-SAP), ואוטומציית ההקצאה של Azure Center for SAP Solutions (ACSS).
אנו נצמדים לשלד התשתית מכיוון שמק"ט ה-VM הספציפיים ל-SAP יקרים מדי עבור מנוי מעבדה. השלד לעיל (VNet, PPG, Availability Set, דיסק פרימיום, Private DNS) הוא בדיוק מה שכל ארכיטקטורת ייחוס של AZ-120 מתחילה ממנו — מכונות ה-VM של SAP מתחברות לבסיס זה.
עבור תבניות ספציפיות למכונות VM של SAP, עיין במקטעי עיון, מדריך, ו-Editorial בדף אישור זה.