מדריך

בחירת VM עבור מסד נתונים של SAP HANA בסביבת ייצור.

→השתמש במכונות וירטואליות מסדרת Mv2 או M עבור מסדי נתונים גדולים (>4TB). השתמש במכונות וירטואליות מסדרת Edsv5 המאושרות על ידי SAP עבור מסדי נתונים קטנים יותר של HANA בסביבת ייצור (<4TB).

למה: סדרות M/Mv2 מאושרות על ידי SAP לעומסי עבודה עם זיכרון גדול. סדרת Edsv5 מציעה אפשרות מאושרת וחסכונית עבור מופעי HANA קטנים יותר. סדרות אחרות (D, F, L) אינן מאושרות עבור מסדי נתונים של HANA בסביבת ייצור.

מקור↗

בחירת VM עבור שרת יישומים של SAP NetWeaver.

→השתמש במכונות וירטואליות מסדרת Edsv5 או Ddsv5. קבע גודל בהתבסס על דרישות SAPS מדוחות SAP EarlyWatch Alert או SAP Quick Sizer.

למה: מכונות וירטואליות מסדרות E ו-D מספקות יחס מאוזן בין מעבד לזיכרון המתאים לעומסי עבודה של שרתי יישומים של SAP, והן מאושרות על ידי SAP עבור NetWeaver.

הבטחת השהיה מינימלית ברשת בין שרתי יישומים של SAP לשרת מסד הנתונים.

→פרוס את כל המכונות הוירטואליות הקשורות (שרתי יישומים, ASCS/ERS, מסד נתונים) בתוך קבוצת מיקום בקרבה (PPG) יחידה.

למה: קבוצות PPG ממקמות פיזית מכונות וירטואליות באותו מרכז נתונים, ממזערות את זמן ההלוך והחזור ברשת כדי לעמוד בדרישת ההשהיה של SAP מתחת למילישנייה בין שכבות היישומים למסד הנתונים.

ספק מערכת קבצים משותפת עבור נפח /hana/shared בפריסה מרובת צמתים (scale-out) של SAP HANA.

→השתמש ב-Azure NetApp Files (ANF) עם פרוטוקול NFS.

למה: ANF הוא פתרון האחסון המשותף ב-NFS, מאושר על ידי SAP ובעל ביצועים גבוהים, הנדרש עבור תצורות HANA scale-out. אחסון בלוקים כמו Managed Disks לא יכול לשמש למטרה זו.

ספק מערכת קבצים משותפת וזמינה ביותר עבור /sapmnt וספריית ההעברה הגלובלית (/usr/sap/trans).

→השתמש ב-Azure NetApp Files (NFS) או ב-Azure Files Premium (NFS). עבור Windows, השתמש ב-Azure Files Premium (SMB) או באשכול SOFS.

למה: שירותים אלה מספקים שיתופי קבצים מנוהלים וזמינים ביותר עם הביצועים ותמיכת הפרוטוקולים הנדרשים (NFS עבור Linux, SMB עבור Windows), ומבטלים את הצורך לבנות ולנהל אשכול שרתי קבצים נפרד.

תכנן אחסון עבור נפחי /hana/data ו-/hana/log של SAP HANA בסביבת ייצור הדורשים IOPS גבוה והשהיה מתחת למילישנייה.

→השתמש ב-Azure Ultra Disk או ב-Premium SSD v2 managed disks. עבור /hana/log במכונות וירטואליות מסדרת M, Premium SSD עם Write Accelerator הוא גם אפשרות תקפה.

למה: Ultra Disk ו-Premium SSD v2 עומדים בדרישות המחמירות של IOPS, תפוקה והשהיה מתחת למילישנייה המוגדרות על ידי SAP עבור עומסי עבודה של HANA בסביבת ייצור. רמות אחסון סטנדרטיות אינן נתמכות.

תכנן ארכיטקטורת רשת מאובטחת עבור עומסי עבודה של SAP, מבודדת סביבות ייצור מסביבות שאינן ייצור.

→השתמש בטופולוגיית hub-spoke. פרוס מערכות SAP ברשתות וירטואליות (VNets) ייעודיות מסוג spoke לכל סביבה (Prod, QA, Dev). השתמש בקבוצות אבטחת רשת (NSGs) כדי לאכוף כללי תעבורה מחמירים בין רשתות משנה.

למה: זה מספק בידוד רשת חזק ברמת ה-VNet ובקרת תעבורה מדויקת עם NSGs, בהתאם לשיטות עבודה מומלצות לאבטחה ולתפיסת ה-Azure Landing Zone.

פרוס סביבות SAP ב-Azure תוך שימוש בגישת Infrastructure as Code (IaC) לעקביות ואוטומציה.

→השתמש ב-SAP on Azure Deployment Automation Framework הרשמי, הממנף את Terraform ו-Ansible. לחלופין, בנה מודולי Bicep או Terraform מותאמים אישית.

למה: המסגרת מספקת תבניות מוכנות ומאושרות על ידי SAP לפריסת כלל הסביבה (control plane, workload zones, מערכות SAP), מצמצמת מאמץ ידני ומבטיחה עמידה בשיטות עבודה מומלצות.

פרסם בצורה מאובטחת יישומי SAP Fiori או יישומי SAP מבוססי אינטרנט אחרים למשתמשים חיצוניים דרך האינטרנט.

→השתמש ב-Azure Application Gateway עם Web Application Firewall (WAF) מופעל.

למה: App Gateway מספק איזון עומסים בשכבה 7, סיום SSL והגנת WAF מפני פגיעויות אינטרנט נפוצות, מה שהופך אותו לנקודת כניסה אידיאלית ומאובטחת ליישומי SAP מבוססי אינטרנט.

פרוס מסד נתונים גדול במיוחד של SAP HANA (מעל 12 TB זיכרון) החורג מקיבולת מכונות וירטואליות של Azure.

→השתמש ב-SAP HANA on Azure Large Instances (HLI). קישוריות דורשת מעגל ExpressRoute המחבר את יחידת ה-HLI ל-Azure VNet דרך שער ExpressRoute.

למה: HLI הם שרתי bare-metal שנבנו במיוחד, המספקים את הזיכרון והביצועים העצומים הנדרשים לעומסי העבודה הגדולים ביותר של HANA, שהם מעבר לקנה המידה של תשתית וירטואלית קיימת.

פרוס מערכת SAP על פני אזורי זמינות תוך מזעור השהיה בתוך כל אזור.

→צור קבוצת מיקום בקרבה (PPG) נפרדת עבור המשאבים בכל אזור זמינות. הצמד כל PPG לאזור המתאים לו.

למה: PPG יחידה אינה יכולה להתפרס על פני אזורים. גישה זו מבטיחה מיקום משותף עם השהיה נמוכה של משאבים *בתוך* אזור, תוך השגת זמינות גבוהה *על פני* אזורים.

צור והפץ תמונות VM סטנדרטיות, מתוקנות ומוגדרות מראש עבור פריסות SAP על פני מספר אזורים.

→השתמש ב-Azure Image Builder כדי להגדיר תהליך יצירת תמונה שניתן לחזור עליו. אחסן ושכפל את התמונות המנוהלות המתקבלות באמצעות Azure Compute Gallery.

למה: זה מספק מפעל "תמונת זהב" אוטומטי ומבוקר גרסאות, המבטיח עקביות ומקצר את זמן הפריסה בהשוואה להגדרת כל VM חדש באופן ידני.

ספק גישת ניהול מאובטחת באמצעות RDP/SSH למכונות וירטואליות של SAP מבלי לחשוף אותן לאינטרנט הציבורי.

→פרוס את Azure Bastion (Standard SKU) לרשת משנה ייעודית בתוך הרשת הווירטואלית של SAP. השתמש ב-Bastion כדי להתחבר למכונות וירטואליות דרך פורטל Azure או לקוחות מקוריים.

למה: Bastion פועל כ-jump box מאובטח ומנוהל, ומבטל את הצורך בכתובות IP ציבוריות במכונות וירטואליות של SAP או בהגדרות VPN מורכבות לגישת ניהול, ובכך מצמצם את שטח התקיפה.

הצפן נפחי נתוני SAP באמצעות מפתחות הצפנה מנוהלים על ידי הלקוח.

→השתמש ב-Azure Disk Encryption עם מפתח מנוהל על ידי לקוח (CMK) המאוחסן ב-Azure Key Vault. ניתן לשלב זאת עם הצפנה מקורית של SAP HANA להגנה רב-שכבתית (defense-in-depth).

למה: תצורה זו מעניקה ללקוח שליטה מלאה על מפתחות הצפנת הנתונים, ועומדת בדרישות תאימות ואבטחה מחמירות לניהול מחזור חיי המפתחות.

העברת מערכת SAP מקומית עם מסד נתונים שאינו HANA (לדוגמה, Oracle, Db2) ל-SAP HANA ב-Azure.

→השתמש ב-SAP Software Update Manager (SUM) עם Database Migration Option (DMO). עבור זמן השבתה מינימלי, השתמש באפשרויות "DMO עם העברת מערכת" או nZDT (זמן השבתה קרוב לאפס).

למה: DMO משלב המרת מסד נתונים, שדרוג מערכת והעברת נתונים לתהליך אחד אופטימלי. זהו כלי ה-SAP הסטנדרטי למשימה זו, הממזער זמן השבתה בהשוואה לייצוא/ייבוא קלאסי.

העברת מערכת SAP HANA מקומית ל-Azure עם זמן ההשבתה הנמוך ביותר האפשרי.

→השתמש ב-SAP HANA System Replication (HSR) כדי לשכפל נתונים באופן רציף למכונה הוירטואלית היעד ב-Azure. בצע מעבר קצר וסופי (takeover) במהלך חלון התחזוקה.

למה: HSR ממזער את חלון זמן ההשבתה לדקות, מכיוון שנדרשים רק סנכרון סופי ו-takeover. שיטות גיבוי/שחזור או ייצוא/ייבוא גורמות לשעות של זמן השבתה עבור מסדי נתונים גדולים.

העברת נפח גדול של נתוני SAP (>10 TB) מהאתר המקומי ל-Azure עבור עומס ההעברה הראשוני כאשר רוחב הפס של הרשת אינו מספק.

→השתמש ב-Azure Data Box להעברת הנתונים הגדולה הראשונית. השתמש ב-ExpressRoute או VPN לסנכרון הדלתא העוקב.

למה: Data Box מספק שיטת העברה לא מקוונת מהירה יותר מהעברות מבוססות רשת ברוחב פס מוגבל, ומקצר משמעותית את זמן הטעינה הראשוני.

פרוס ונהל מערכות SAP S/4HANA ב-Azure באמצעות חוויה פשוטה ומודרכת.

→השתמש ב-Azure Center for SAP solutions (ACSS). דרישות קדם כוללות רישום הספק `Microsoft.Workloads` ויצירת זהות מנוהלת המוקצית למשתמש עם ההרשאות הנדרשות.

למה: ACSS מייעל את הפריסה על ידי איגוד שיטות עבודה מומלצות ומספק "single pane of glass" בפורטל Azure לניהול בסיסי (הפעלה/עצירה, ניטור) ובדיקות איכות.

קבע את הגדלים הנכונים של מכונות וירטואליות של Azure עבור מערכת SAP חדשה או מועברת.

→השתמש בכלי SAP Quick Sizer עבור הטמעות חדשות. עבור העברות, נתח דוחות SAP EarlyWatch Alert מהמערכת הקיימת כדי לקבל את השימוש הנוכחי ב-SAPS ובזיכרון. מפה אותם למכונות וירטואליות של Azure המאושרות על ידי SAP.

למה: כלים מקוריים אלו של SAP מספקים את אפיון עומסי העבודה המדויק ביותר (SAPS, זיכרון, I/O), החיוני לבחירה נכונה של משאבי Azure ולהבטחת ביצועים ותמיכה.

שלב סביבת Azure מנוהלת על ידי לקוח עם מערכת SAP S/4HANA הפרוסה באמצעות RISE with SAP.

→SAP מנהלת את תשתית ה-Azure הבסיסית במנוי נפרד. צור קישוריות מ-VNet ה-Azure שלך ל-VNet המנוהלת על ידי SAP באמצעות VNet Peering.

למה: RISE היא הצעת שירות מנוהלת מ-SAP. VNet Peering מספק את נתיב האינטגרציה הרשתי הסטנדרטי, המאובטח והפרטי בין סביבת RISE לעומסי עבודה אחרים של לקוחות ב-Azure.

אכוף סטנדרטים ארגוניים ושיטות עבודה מומלצות לאבטחה על פני כל פריסות SAP ב-Azure.

→השתמש ב-Azure Policy כדי לאכוף כללים, כגון דרישה למכונות וירטואליות SKUs ספציפיות, הצפנת דיסקים מנוהלים, שיוך NSG או תיוג חובה. השתמש באפקט `DeployIfNotExists` להתקנה אוטומטית של הרחבת ה-VM עבור SAP.

למה: Azure Policy מספקת ניהול אוטומטי בקנה מידה גדול, המבטיח שכל הפריסות תואמות ללא הסתמכות על בדיקות ידניות או תצורות תבנית בודדות.

אמת שתשתית Azure הפרוסה מוגדרת נכון ועומדת בדרישות התמיכה של SAP לפני העלייה לאוויר (go-live).

→התקן ואפשר את Azure VM Extension for SAP (ניטור משופר). הפעל את כלי ה-SAP on Azure Quality Check מ-GitHub.

למה: הרחבת ה-VM היא חובה לתמיכה ב-SAP. כלי בדיקת האיכות מאמת באופן יזום תצורות (אחסון, רשת, הגדרות מערכת הפעלה) מול רשימה של שיטות עבודה מומלצות ודרישות ידועות.

הטמע פתרון גיבוי אוטומטי ועקבי יישומית עבור מסדי נתונים של SAP HANA במכונות וירטואליות של Azure.

→השתמש ב-Azure Backup עבור SAP HANA, המשתלב באמצעות ממשק ה-Backint המאושר על ידי SAP. הגדר מדיניות עם גיבויים מלאים/דיפרנציאליים וגיבויי יומן תכופים לשחזור לנקודת זמן.

למה: Azure Backup מספק פתרון מקורי, משולב ומאושר המבצע אוטומציה של תזמון גיבויים, שמירה וניהול, מבלי לדרוש סקריפטים מותאמים אישית או תשתית גיבוי נפרדת.

הטמע ניטור מקיף ומרכזי עבור סביבת SAP הפועלת ב-Azure.

→פרוס את Azure Monitor for SAP Solutions. הגדר ספקים עבור SAP HANA, NetWeaver, מערכת הפעלה (Linux) וטלמטריה של אשכול זמינות גבוהה.

למה: זהו שירות Azure מקורי המיועד ל-SAP. הוא מספק טלמטריה עשירה ומודעת ל-SAP והדמיות, המרכזת את הניטור של כל ערימת ה-SAP מהתשתית ועד ליישום.

החל עדכוני מערכת הפעלה או ליבת SAP על אשכול SAP בזמינות גבוהה עם זמן השבתה מינימלי.

→השתמש בגישת עדכון מתגלגל (rolling update). העבר את הצומת המשני למצב תחזוקה, עדכן אותו, ולאחר מכן הפעל מחדש. בצע מעבר כשל מבוקר של האשכול כדי להפוך את הצומת המעודכן לראשי. לבסוף, עדכן את הצומת הראשי הקודם.

למה: גישה מתגלגלת זו מבטיחה ששירות ה-SAP יישאר זמין על צומת אחד לאורך כל תהליך התחזוקה, ובכך ממזערת את הפסקת השירות העסקי.

בצע אוטומציה של תהליך יצירת עותקים או רענון של מערכות SAP (לדוגמה, רענון מערכת QAS ממערכת PRD).

→השתמש ב-SAP Landscape Management (LaMa) עם מחבר ה-Azure.

למה: LaMa מתזמר את התהליך מקצה לקצה, כולל משימות תשתית של Azure (עצירה/הפעלה של VM, תמונות מצב של דיסקים) ואוטומציה ספציפית ל-SAP לאחר העתקה (BDLS), ומפחיתה משמעותית את המאמץ הידני.

אמת את תוכנית ההתאוששות מאסון של SAP מבלי להשפיע על סביבת הייצור.

→השתמש בתכונת "Test Failover" של Azure Site Recovery המעלה מכונות וירטואליות משוכפלות ב-VNet מבודדת. עבור HSR, השתמש בשחזורים מבוססי תמונות מצב למערכת מבודדת או ליעד שכפול שלישוני ייעודי.

למה: בדיקה ברשת מבודדת מונעת התנגשויות IP וכל הפרעה למערכות ייצור או לשכפול מתמשך, ומאפשרת אימות בטוח ויסודי של תוכנית ה-DR.

תכנן דרישות משאבים עתידיות (מעבד, זיכרון, אחסון) עבור מערכת SAP צומחת ב-Azure.

→השתמש במדדי Azure Monitor וב-Log Analytics לניתוח מגמות שימוש היסטוריות. השתמש בנתונים אלה לחיזוי. עבור אחסון, נצל את היכולת לשנות באופן דינמי את גודל ה-Azure Managed Disks באופן מקוון.

למה: ניהול קיבולת יזום המבוסס על נתונים היסטוריים מונע ירידה בביצועים ומאפשר הקצאה בזמן אמת (just-in-time provisioning), ומייעל עלויות בהשוואה להקצאת יתר משמעותית מראש.

צמצם למינימום את עלויות Azure עבור הפעלת סביבת SAP מלאה.

→עבור עומסי עבודה בסביבת ייצור, השתמש ב-Azure Reserved Instances לשנה או שלוש שנים. עבור מערכות שאינן ייצור, הטמע לוחות זמנים אוטומטיים להפעלה/עצירה באמצעות Azure Automation. השתמש ב-Azure Hybrid Benefit עבור רישיונות כאשר הדבר מתאים.

למה: Reserved Instances מספקים הנחות גדולות עבור עומסי עבודה צפויים וקבועים (24/7). כיבוי אוטומטי מבטל עלויות חישוב במהלך תקופות סרק עבור סביבות שאינן ייצור. שילוב זה מטפל בשני גורמי העלות העיקריים.

עקוב והקצה עלויות Azure עבור עומסי עבודה של SAP ליחידות עסקיות ספציפיות, פרויקטים או מערכות SAP (SIDs).

→הטמע אסטרטגיית תיוג חובה עבור כל משאבי Azure. השתמש בתגים כמו `CostCenter`, `Environment`, `SAP-SID` ו-`BusinessOwner`. נתח עלויות באמצעות Azure Cost Management.

למה: תיוג הוא המנגנון המקורי של Azure לקטגוריית משאבים. תיוג עקבי מאפשר ניתוח עלויות מפורט וחיוב חוזר (chargeback), ומספק שקיפות פיננסית חיונית.

אבחן בעיות קישוריות רשת או השהיה לסירוגין בין מכונות וירטואליות של SAP ב-Azure.

→השתמש בכלי Azure Network Watcher, ובפרט ב-Connection Monitor לבדיקת נתיבים והשהיה, וב-NSG Flow Logs לניתוח וזיהוי תעבורה חסומה.

למה: Network Watcher מספק כלים יזומים ותגובתיים לאיתור בעיות רשת ברמת פלטפורמת Azure, שלעתים קרובות קשה לאבחן מתוך מערכת ההפעלה האורחת בלבד.

בצע אוטומציה של עדכוני מערכת הפעלה עבור מכונות וירטואליות של SAP תוך הבטחת כיבוי מסודר של היישומים.

→השתמש ב-Azure Update Manager עם סקריפטים לפני/אחרי. הסקריפט שלפני עוצר את יישום ה-SAP ומסד הנתונים, והסקריפט שלאחר מכן מפעיל אותם מחדש לאחר השלמת העדכון.

למה: זה משלב את האוטומציה של ניהול העדכונים של Azure עם המודעות ליישומים הנדרשת עבור SAP, ומונע חוסר עקביות בנתונים שעלול להתרחש כתוצאה מעדכון מערכת פועלת.

הטמע זמינות גבוהה עבור שירותי SAP מרכזיים (ASCS/ERS) או SAP HANA במכונות וירטואליות של SUSE/RHEL Linux.

→הגדר אשכול Pacemaker. השתמש בסוכן `fence_azure_arm` עבור STONITH (fencing) כדי למנוע תרחישי split-brain, מאומת באמצעות זהות מנוהלת (managed identity).

למה: Pacemaker הוא פתרון האשכולות הנתמך על ידי SAP ב-Linux. `fence_azure_arm` הוא המנגנון המקורי של Azure לבידוד אמין של צומת כושל באמצעות ממשקי API של Azure, והוא חובה עבור אשכול יציב.

הטמע זמינות גבוהה עבור שירותי SAP מרכזיים (ASCS/ERS) במכונות וירטואליות של Windows Server.

→הגדר Windows Server Failover Cluster (WSFC). עבור אחסון משותף באשכול, השתמש ב-Azure Shared Disks או בפתרון שכפול של צד שלישי כמו SIOS DataKeeper.

למה: WSFC הוא הסטנדרט עבור אשכולות Windows. Azure Shared Disks מספקים אחסון בלוקים משותף מקורי, בעוד SIOS יוצר אשכול "shared-nothing", ושניהם מחליפים את הצורך ב-SANs מסורתיים בענן.

תכנן אסטרטגיה לזמינות גבוהה (HA) והתאוששות מאסון (DR) עבור SAP HANA.

→עבור HA (באזור), פרוס מכונות וירטואליות על פני אזורי זמינות והשתמש ב-SAP HANA System Replication (HSR) סינכרוני (SYNC). עבור DR (בין אזורים), השתמש ב-HSR אסינכרוני (ASYNC).

למה: שכפול סינכרוני מספק RPO אפס אך דורש השהיה נמוכה (<2ms), מה שהופך אותו לאידיאלי עבור HA בין אזורים. שכפול אסינכרוני סובל השהיה גבוהה יותר בין אזורים, מה שהופך אותו לבחירה עבור DR.

הגדר Azure Load Balancer לניהול כתובת ה-IP הווירטואלית עבור אשכול SAP HA (ASCS/ERS או HANA).

→השתמש ב-Azure Standard Load Balancer. אפשר Floating IP (Direct Server Return) על כלל איזון העומסים. הגדר בדיקת תקינות (health probe) על היציאה הספציפית המנוטרת על ידי האשכול (לדוגמה, 620xx עבור ASCS).

למה: נדרש Standard SKU עבור יתירות אזורים (zone-redundancy). Floating IP נחוץ כדי שכתובת ה-IP הווירטואלית של האשכול תפעל כהלכה. בדיקת התקינות הספציפית מבטיחה שתעבורה תישלח רק לצומת הפעיל.

הבן את מטרת Enqueue Replication Server (ERS) באשכול זמינות גבוהה של SAP ASCS.

→מופע ה-ERS שומר על עותק משוכפל של טבלת הנעילה של SAP ממופע ה-ASCS הפעיל.

למה: אם מופע ה-ASCS נכשל (fails over), מופע ה-ASCS שהופעל מחדש מאחזר את טבלת הנעילה המשוכפלת מה-ERS. זה משמר את נעילות העסקאות ומאפשר למשתמשים להמשיך לעבוד ללא הפרעה.

תכנן פתרון התאוששות מאסון מלא עבור סביבת SAP מרובת שכבות.

→השתמש בשכפול מסד נתונים מקורי עבור שכבת מסד הנתונים (לדוגמה, HSR אסינכרוני עבור HANA). השתמש ב-Azure Site Recovery (ASR) עבור שכבת היישומים (ASCS/ERS ושרתי יישומים).

למה: גישת "best-of-breed" זו מבטיחה עקביות יישומים עבור מסד הנתונים באמצעות השכפול המקורי שלו, בעוד ASR מספקת דרך חסכונית ואוטומטית לשכפל ולהעביר (fail over) את המכונות הוירטואליות של שרתי היישומים.

הטמע זמינות גבוהה עבור מסד נתונים של SAP הפועל על Microsoft SQL Server במכונות וירטואליות של Azure.

→השתמש ב-SQL Server Always On Availability Groups, בדרך כלל עם מצב synchronous-commit עבור HA בתוך אזור, בשילוב עם WSFC.

למה: Always On AG הוא פתרון ה-HA/DR המומלץ והנתמך במלואו עבור SQL Server, המספק שכפול ברמת מסד הנתונים ויכולות מעבר כשל אוטומטיות.

הטמע SBD (STONITH Block Device) כמנגנון קוורום עבור אשכול Pacemaker דו-צומתי.

→הגדר Azure Shared Disk קטן וצרף אותו לשני צמתי האשכול. לחלופין, הגדר שרת iSCSI target ייעודי על VM שלישית.

למה: בעוד `fence_azure_arm` הוא סוכן ה-fencing העיקרי, SBD מספק מנגנון witness/quorum נוסף למניעת split-brain, במיוחד באשכולות ללא צומת הצבעה שלישי.