मार्गदर्शिका

उत्पादन SAP HANA डेटाबेस के लिए एक VM चुनें।

→बड़े डेटाबेस (>4TB) के लिए Mv2-सीरीज या M-सीरीज VMs का उपयोग करें। छोटे उत्पादन HANA डेटाबेस (<4TB) के लिए SAP-प्रमाणित Edsv5-सीरीज VMs का उपयोग करें।

क्यों: M-सीरीज/Mv2-सीरीज बड़े मेमोरी वर्कलोड्स के लिए SAP-प्रमाणित हैं। Edsv5-सीरीज छोटे HANA इंस्टेंस के लिए एक लागत प्रभावी प्रमाणित विकल्प प्रदान करती है। अन्य सीरीज (D, F, L) उत्पादन HANA डेटाबेस के लिए प्रमाणित नहीं हैं।

संदर्भ↗

एक SAP NetWeaver एप्लीकेशन सर्वर के लिए एक VM चुनें।

→Edsv5-सीरीज या Ddsv5-सीरीज VMs का उपयोग करें। SAP EarlyWatch Alert रिपोर्ट या SAP Quick Sizer से SAPS आवश्यकताओं के आधार पर आकार निर्धारित करें।

क्यों: E-सीरीज और D-सीरीज VMs SAP एप्लीकेशन सर्वर वर्कलोड्स के लिए उपयुक्त संतुलित CPU-से-मेमोरी अनुपात प्रदान करते हैं और NetWeaver के लिए SAP-प्रमाणित हैं।

SAP एप्लीकेशन सर्वर और डेटाबेस सर्वर के बीच न्यूनतम नेटवर्क विलंबता सुनिश्चित करें।

→सभी संबंधित VMs (ऐप सर्वर, ASCS/ERS, डेटाबेस) को एक एकल Proximity Placement Group (PPG) के भीतर डिप्लॉय करें।

क्यों: PPG एक ही डेटासेंटर में VMs को भौतिक रूप से सह-स्थित करते हैं, जिससे एप्लीकेशन और डेटाबेस टियर्स के बीच SAP की सब-मिलीसेकंड विलंबता आवश्यकता को पूरा करने के लिए नेटवर्क राउंड-ट्रिप समय कम हो जाता है।

एक SAP HANA स्केल-आउट डिप्लॉयमेंट में /hana/shared वॉल्यूम के लिए एक साझा फ़ाइल सिस्टम प्रदान करें।

→NFS प्रोटोकॉल के साथ Azure NetApp Files (ANF) का उपयोग करें।

क्यों: ANF HANA स्केल-आउट कॉन्फ़िगरेशन के लिए आवश्यक SAP-प्रमाणित, उच्च-प्रदर्शन, साझा NFS स्टोरेज समाधान है। Managed Disks जैसे ब्लॉक स्टोरेज का उपयोग इस उद्देश्य के लिए नहीं किया जा सकता है।

/sapmnt और ग्लोबल ट्रांसपोर्ट डायरेक्टरी (/usr/sap/trans) के लिए एक उच्च उपलब्ध साझा फ़ाइल सिस्टम प्रदान करें।

→Azure NetApp Files (NFS) या Azure Files Premium (NFS) का उपयोग करें। Windows के लिए, Azure Files Premium (SMB) या SOFS क्लस्टर का उपयोग करें।

क्यों: ये सेवाएं आवश्यक प्रदर्शन और प्रोटोकॉल समर्थन (Linux के लिए NFS, Windows के लिए SMB) के साथ प्रबंधित, उच्च उपलब्ध फ़ाइल शेयर प्रदान करती हैं, जिससे एक अलग फ़ाइल सर्वर क्लस्टर बनाने और प्रबंधित करने की आवश्यकता समाप्त हो जाती है।

उच्च IOPS और सब-मिलीसेकंड विलंबता की आवश्यकता वाले उत्पादन SAP HANA /hana/data और /hana/log वॉल्यूम के लिए स्टोरेज डिज़ाइन करें।

→Azure Ultra Disk या Premium SSD v2 प्रबंधित डिस्क का उपयोग करें। M-सीरीज VMs पर /hana/log के लिए, Write Accelerator के साथ Premium SSD भी एक वैध विकल्प है।

क्यों: Ultra Disk और Premium SSD v2 उत्पादन HANA वर्कलोड्स के लिए SAP द्वारा परिभाषित कठोर IOPS, थ्रूपुट और सब-मिलीसेकंड विलंबता KPI को पूरा करते हैं। स्टैंडर्ड स्टोरेज टियर्स समर्थित नहीं हैं।

SAP वर्कलोड्स के लिए एक सुरक्षित नेटवर्क आर्किटेक्चर डिज़ाइन करें, जो उत्पादन को गैर-उत्पादन वातावरण से अलग करता हो।

→एक हब-स्पोक टोपोलॉजी का उपयोग करें। प्रत्येक वातावरण (उत्पादन, QA, Dev) के लिए समर्पित स्पोक VNets में SAP सिस्टम डिप्लॉय करें। सबनेट के बीच सख्त ट्रैफ़िक नियम लागू करने के लिए Network Security Groups (NSGs) का उपयोग करें।

क्यों: यह सुरक्षा सर्वोत्तम प्रथाओं और Azure Landing Zone अवधारणा का पालन करते हुए VNet स्तर पर मजबूत नेटवर्क अलगाव और NSG के साथ बारीक ट्रैफ़िक नियंत्रण प्रदान करता है।

कंसिस्टेंसी और ऑटोमेशन के लिए Infrastructure as Code (IaC) दृष्टिकोण का उपयोग करके Azure पर SAP लैंडस्केप डिप्लॉय करें।

→आधिकारिक SAP on Azure Deployment Automation Framework का उपयोग करें, जो Terraform और Ansible का लाभ उठाता है। वैकल्पिक रूप से, कस्टम Bicep या Terraform मॉड्यूल बनाएं।

क्यों: फ्रेमवर्क पूरे लैंडस्केप (कंट्रोल प्लेन, वर्कलोड ज़ोन, SAP सिस्टम) को डिप्लॉय करने के लिए पूर्व-निर्मित, SAP-मान्य टेम्प्लेट प्रदान करता है, जिससे मैन्युअल प्रयास कम होता है और सर्वोत्तम प्रथाओं का पालन सुनिश्चित होता है।

इंटरनेट पर बाहरी उपयोगकर्ताओं के लिए SAP Fiori या अन्य वेब-आधारित SAP एप्लीकेशन्स को सुरक्षित रूप से प्रकाशित करें।

→Web Application Firewall (WAF) सक्षम के साथ Azure Application Gateway का उपयोग करें।

क्यों: App Gateway लेयर 7 लोड बैलेंसिंग, SSL टर्मिनेशन और सामान्य वेब कमजोरियों के खिलाफ WAF सुरक्षा प्रदान करता है, जिससे यह वेब-आधारित SAP एप्लीकेशन्स के लिए आदर्श और सुरक्षित एंट्री पॉइंट बन जाता है।

एक अत्यंत बड़ा SAP HANA डेटाबेस (>12 TB मेमोरी) डिप्लॉय करें जो Azure VM क्षमता से अधिक हो।

→SAP HANA on Azure Large Instances (HLI) का उपयोग करें। कनेक्टिविटी के लिए एक ExpressRoute सर्किट की आवश्यकता होती है जो ExpressRoute गेटवे के माध्यम से HLI स्टैंप को एक Azure VNet से जोड़ता है।

क्यों: HLI उद्देश्य-निर्मित, बेयर-मेटल सर्वर हैं जो सबसे बड़े HANA वर्कलोड्स के लिए आवश्यक विशाल मेमोरी और प्रदर्शन प्रदान करते हैं, जो वर्तमान वर्चुअलाइज्ड इंफ्रास्ट्रक्चर के पैमाने से परे हैं।

प्रत्येक ज़ोन के भीतर विलंबता को कम करते हुए SAP सिस्टम को Availability Zones में डिप्लॉय करें।

→प्रत्येक Availability Zone में संसाधनों के लिए एक अलग Proximity Placement Group (PPG) बनाएं। प्रत्येक PPG को उसके संबंधित ज़ोन से पिन करें।

क्यों: एक एकल PPG ज़ोन में नहीं फैल सकता है। यह दृष्टिकोण एक ज़ोन *के भीतर* संसाधनों के कम-विलंबता सह-स्थान को सुनिश्चित करता है, जबकि अभी भी ज़ोन *भर में* उच्च उपलब्धता प्राप्त करता है।

कई क्षेत्रों में SAP डिप्लॉयमेंट के लिए मानकीकृत, पैच किए गए और पूर्व-कॉन्फ़िगर किए गए VM इमेज बनाएं और वितरित करें।

→एक दोहराने योग्य इमेज निर्माण प्रक्रिया को परिभाषित करने के लिए Azure Image Builder का उपयोग करें। Azure Compute Gallery का उपयोग करके परिणामी प्रबंधित इमेज को स्टोर और रेप्लिकेट करें।

क्यों: यह एक संस्करण-नियंत्रित, स्वचालित "गोल्डन इमेज" फैक्ट्री प्रदान करता है, जिससे मैन्युअल रूप से प्रत्येक नए VM को कॉन्फ़िगर करने की तुलना में कंसिस्टेंसी सुनिश्चित होती है और डिप्लॉयमेंट का समय कम होता है।

सार्वजनिक इंटरनेट पर SAP VMs को उजागर किए बिना उन्हें सुरक्षित RDP/SSH प्रशासनिक पहुंच प्रदान करें।

→SAP वर्चुअल नेटवर्क के भीतर एक समर्पित सबनेट में Azure Bastion (Standard SKU) डिप्लॉय करें। Azure पोर्टल या नेटिव क्लाइंट के माध्यम से VMs से कनेक्ट करने के लिए Bastion का उपयोग करें।

क्यों: Bastion एक सुरक्षित, प्रबंधित जंप बॉक्स के रूप में कार्य करता है, जो SAP VMs पर सार्वजनिक IP एड्रेस या प्रशासनिक पहुंच के लिए जटिल VPN सेटअप की आवश्यकता को समाप्त करता है, जिससे हमला सतह कम हो जाती है।

ग्राहक-प्रबंधित एन्क्रिप्शन कुंजी का उपयोग करके SAP डेटा वॉल्यूम को एन्क्रिप्ट करें।

→Azure Key Vault में संग्रहीत ग्राहक-प्रबंधित कुंजी (CMK) के साथ Azure Disk Encryption का उपयोग करें। इसे डीप-इन-डिफेंस के लिए SAP HANA नेटिव एन्क्रिप्शन के साथ जोड़ा जा सकता है।

क्यों: यह कॉन्फ़िगरेशन ग्राहक को डेटा एन्क्रिप्शन कुंजी पर पूर्ण नियंत्रण देता है, जो कुंजी जीवनचक्र प्रबंधन के लिए सख्त अनुपालन और सुरक्षा आवश्यकताओं को पूरा करता है।

एक ऑन-प्रिमाइसेस SAP सिस्टम को एक नॉन-HANA डेटाबेस (जैसे, Oracle, Db2) के साथ Azure पर SAP HANA में माइग्रेट करें।

→Database Migration Option (DMO) के साथ SAP Software Update Manager (SUM) का उपयोग करें। न्यूनतम डाउनटाइम के लिए, "DMO with System Move" या नियर-जीरो डाउनटाइम (nZDT) विकल्पों का उपयोग करें।

क्यों: DMO डेटाबेस रूपांतरण, सिस्टम अपग्रेड और डेटा माइग्रेशन को एक एकल, अनुकूलित प्रक्रिया में जोड़ता है। यह इस कार्य के लिए मानक SAP टूल है, जो क्लासिकल एक्सपोर्ट/इंपोर्ट की तुलना में डाउनटाइम को कम करता है।

कम से कम संभव डाउनटाइम के साथ एक ऑन-प्रिमाइसेस SAP HANA सिस्टम को Azure पर माइग्रेट करें।

→लक्ष्य Azure VM पर डेटा को लगातार रेप्लिकेट करने के लिए SAP HANA System Replication (HSR) का उपयोग करें। रखरखाव विंडो के दौरान अंतिम, संक्षिप्त कटओवर (टेकओवर) करें।

क्यों: HSR डाउनटाइम विंडो को मिनटों तक कम कर देता है, क्योंकि केवल अंतिम सिंक और टेकओवर की आवश्यकता होती है। बैकअप/रिस्टोर या एक्सपोर्ट/इंपोर्ट विधियों से बड़े डेटाबेस के लिए घंटों का डाउनटाइम होता है।

जब नेटवर्क बैंडविड्थ अपर्याप्त हो, तो प्रारंभिक माइग्रेशन लोड के लिए ऑन-प्रिमाइसेस से Azure पर बड़ी मात्रा में SAP डेटा (>10 TB) स्थानांतरित करें।

→प्रारंभिक थोक डेटा ट्रांसफर के लिए Azure Data Box का उपयोग करें। बाद के डेल्टा सिंक्रनाइज़ेशन के लिए ExpressRoute या VPN का उपयोग करें।

क्यों: Data Box सीमित बैंडविड्थ पर नेटवर्क-आधारित स्थानांतरणों की तुलना में एक तेज़ ऑफ़लाइन स्थानांतरण विधि प्रदान करता है, जिससे प्रारंभिक लोड समय काफी कम हो जाता है।

एक सरलीकृत, निर्देशित अनुभव का उपयोग करके Azure पर SAP S/4HANA सिस्टम डिप्लॉय और प्रबंधित करें।

→SAP समाधानों के लिए Azure Center (ACSS) का उपयोग करें। पूर्व-आवश्यकताओं में `Microsoft.Workloads` प्रोवाइडर को रजिस्टर करना और आवश्यक अनुमतियों के साथ एक उपयोगकर्ता-नियुक्त प्रबंधित पहचान बनाना शामिल है।

क्यों: ACSS सर्वोत्तम प्रथाओं को बंडल करके डिप्लॉयमेंट को सुव्यवस्थित करता है और बुनियादी प्रबंधन (स्टार्ट/स्टॉप, निगरानी) और गुणवत्ता जांच के लिए Azure पोर्टल में एक सिंगल फलक प्रदान करता है।

एक नए या माइग्रेटेड SAP सिस्टम के लिए सही Azure VM आकार निर्धारित करें।

→नई कार्यान्वयन के लिए SAP Quick Sizer टूल का उपयोग करें। माइग्रेशन के लिए, मौजूदा सिस्टम से SAP EarlyWatch Alert रिपोर्ट का विश्लेषण करें ताकि वर्तमान SAPS और मेमोरी उपयोग प्राप्त हो सके। इन्हें SAP-प्रमाणित Azure VMs पर मैप करें।

क्यों: ये SAP-नेटिव टूल सबसे सटीक वर्कलोड कैरेक्टरराइजेशन (SAPS, मेमोरी, I/O) प्रदान करते हैं, जो Azure संसाधनों का सही ढंग से चयन करने और प्रदर्शन तथा समर्थन सुनिश्चित करने के लिए आवश्यक है।

RISE with SAP के माध्यम से डिप्लॉय किए गए SAP S/4HANA सिस्टम के साथ एक ग्राहक-प्रबंधित Azure वातावरण को एकीकृत करें।

→SAP एक अलग सब्सक्रिप्शन में अंतर्निहित Azure इंफ्रास्ट्रक्चर का प्रबंधन करता है। VNet Peering का उपयोग करके अपने Azure VNet से SAP-प्रबंधित VNet तक कनेक्टिविटी स्थापित करें।

क्यों: RISE SAP द्वारा एक प्रबंधित सेवा पेशकश है। VNet Peering RISE वातावरण और Azure में अन्य ग्राहक वर्कलोड्स के बीच मानक, सुरक्षित और निजी नेटवर्क एकीकरण पथ प्रदान करता है।

Azure में सभी SAP डिप्लॉयमेंट में कॉर्पोरेट मानकों और सुरक्षा सर्वोत्तम प्रथाओं को लागू करें।

→नियमों को लागू करने के लिए Azure Policy का उपयोग करें, जैसे कि विशिष्ट VM SKU, प्रबंधित डिस्क एन्क्रिप्शन, NSG एसोसिएशन, या अनिवार्य टैगिंग की आवश्यकता। SAP के लिए VM एक्सटेंशन को स्वचालित रूप से स्थापित करने के लिए `DeployIfNotExists` प्रभाव का उपयोग करें।

क्यों: Azure Policy स्वचालित, बड़े पैमाने पर शासन प्रदान करता है, यह सुनिश्चित करता है कि सभी डिप्लॉयमेंट मैन्युअल जांच या व्यक्तिगत टेम्पलेट कॉन्फ़िगरेशन पर निर्भर किए बिना अनुपालन करते हैं।

गो-लाइव से पहले मान्य करें कि डिप्लॉय किया गया Azure इंफ्रास्ट्रक्चर सही ढंग से कॉन्फ़िगर किया गया है और SAP समर्थन आवश्यकताओं को पूरा करता है।

→SAP (Enhanced Monitoring) के लिए Azure VM एक्सटेंशन इंस्टॉल और सक्षम करें। GitHub से SAP on Azure Quality Check टूल चलाएं।

क्यों: VM एक्सटेंशन SAP समर्थन के लिए अनिवार्य है। क्वालिटी चेक टूल ज्ञात सर्वोत्तम प्रथाओं और आवश्यकताओं की सूची के विरुद्ध कॉन्फ़िगरेशन (स्टोरेज, नेटवर्किंग, OS सेटिंग्स) को सक्रिय रूप से मान्य करता है।

Azure VMs पर SAP HANA डेटाबेस के लिए एक एप्लीकेशन-संगत, स्वचालित बैकअप समाधान लागू करें।

→SAP-प्रमाणित Backint इंटरफ़ेस के माध्यम से एकीकृत होने वाले SAP HANA के लिए Azure Backup का उपयोग करें। पॉइंट-इन-टाइम रिकवरी के लिए फुल/डिफरेंशियल और लगातार लॉग बैकअप के साथ एक नीति कॉन्फ़िगर करें।

क्यों: Azure Backup एक देशी, एकीकृत और प्रमाणित समाधान प्रदान करता है जो कस्टम स्क्रिप्ट या अलग बैकअप इंफ्रास्ट्रक्चर की आवश्यकता के बिना बैकअप शेड्यूलिंग, प्रतिधारण और प्रबंधन को स्वचालित करता है।

Azure पर चल रहे SAP लैंडस्केप के लिए व्यापक, केंद्रीकृत निगरानी लागू करें।

→SAP Solutions के लिए Azure Monitor डिप्लॉय करें। SAP HANA, NetWeaver, OS (Linux), और High-Availability Cluster टेलीमेट्री के लिए प्रोवाइडर्स कॉन्फ़िगर करें।

क्यों: यह SAP के लिए डिज़ाइन की गई एक देशी Azure सेवा है। यह समृद्ध, SAP-जागरूक टेलीमेट्री और विज़ुअलाइज़ेशन प्रदान करता है, जो इंफ्रास्ट्रक्चर से एप्लीकेशन तक पूरे SAP स्टैक की निगरानी को केंद्रीकृत करता है।

न्यूनतम डाउनटाइम के साथ एक उच्च-उपलब्धता SAP क्लस्टर पर OS या SAP कर्नेल पैच लागू करें।

→एक रोलिंग अपडेट दृष्टिकोण का उपयोग करें। सेकेंडरी नोड को रखरखाव मोड में डालें, उसे पैच करें, फिर रीबूट करें। पैच किए गए नोड को प्राइमरी बनाने के लिए एक नियंत्रित क्लस्टर फेलओवर करें। अंत में, पूर्व प्राइमरी नोड को पैच करें।

क्यों: यह रोलिंग दृष्टिकोण सुनिश्चित करता है कि पूरे रखरखाव प्रक्रिया के दौरान SAP सेवा एक नोड पर उपलब्ध रहे, जिससे व्यावसायिक सेवा आउटेज कम हो जाता है।

SAP सिस्टम की प्रतियां बनाने या उन्हें रीफ्रेश करने की प्रक्रिया को स्वचालित करें (उदाहरण के लिए, PRD से QAS सिस्टम को रीफ्रेश करना)।

→Azure कनेक्टर के साथ SAP Landscape Management (LaMa) का उपयोग करें।

क्यों: LaMa अंत-से-अंत प्रक्रिया का ऑर्केस्ट्रेट करता है, जिसमें Azure इंफ्रास्ट्रक्चर कार्य (VM स्टॉप/स्टार्ट, डिस्क स्नैपशॉट) और SAP-विशिष्ट पोस्ट-कॉपी ऑटोमेशन (BDLS) शामिल हैं, जिससे मैन्युअल प्रयास काफी कम हो जाता है।

उत्पादन वातावरण को प्रभावित किए बिना SAP डिजास्टर रिकवरी योजना को मान्य करें।

→Azure Site Recovery के "Test Failover" फीचर का उपयोग करें जो एक अलग VNet में रेप्लिकेटेड VMs को ऊपर लाता है। HSR के लिए, एक अलग सिस्टम या एक समर्पित तृतीयक प्रतिकृति लक्ष्य पर स्नैपशॉट-आधारित रिस्टोर का उपयोग करें।

क्यों: एक अलग नेटवर्क में परीक्षण IP विरोध और उत्पादन सिस्टम या चल रही प्रतिकृति के साथ किसी भी हस्तक्षेप को रोकता है, जिससे DR रनबुक का सुरक्षित और पूरी तरह से सत्यापन संभव होता है।

Azure पर बढ़ते SAP सिस्टम के लिए भविष्य की संसाधन आवश्यकताओं (CPU, मेमोरी, स्टोरेज) की योजना बनाएं।

→ऐतिहासिक उपयोग के रुझानों का विश्लेषण करने के लिए Azure Monitor मेट्रिक्स और Log Analytics का उपयोग करें। इस डेटा का उपयोग पूर्वानुमान के लिए करें। स्टोरेज के लिए, Azure Managed Disks को ऑनलाइन रूप से गतिशील रूप से आकार बदलने की क्षमता का लाभ उठाएं।

क्यों: ऐतिहासिक डेटा पर आधारित सक्रिय क्षमता प्रबंधन प्रदर्शन में गिरावट को रोकता है और जस्ट-इन-टाइम प्रोविजनिंग की अनुमति देता है, जिससे महत्वपूर्ण अग्रिम ओवरप्रोविजनिंग की तुलना में लागत अनुकूलित होती है।

एक पूर्ण SAP लैंडस्केप चलाने के लिए Azure लागतों को कम करें।

→उत्पादन वर्कलोड्स के लिए, 1- या 3-वर्षीय Azure Reserved Instances का उपयोग करें। गैर-उत्पादन सिस्टम के लिए, Azure Automation के माध्यम से स्वचालित स्टार्ट/स्टॉप शेड्यूल लागू करें। जहाँ पात्र हों वहाँ लाइसेंस के लिए Azure Hybrid Benefit का उपयोग करें।

क्यों: Reserved Instances अनुमानित, 24/7 वर्कलोड्स के लिए बड़ी छूट प्रदान करते हैं। ऑटो-शटडाउन गैर-उत्पादन के लिए निष्क्रिय अवधि के दौरान कंप्यूट लागतों को समाप्त करता है। यह संयोजन दोनों प्रमुख लागत कारकों को संबोधित करता है।

SAP वर्कलोड्स के लिए Azure लागतों को विशिष्ट व्यावसायिक इकाइयों, परियोजनाओं, या SAP सिस्टम (SIDs) को ट्रैक और आवंटित करें।

→सभी Azure संसाधनों के लिए एक अनिवार्य टैगिंग रणनीति लागू करें। `CostCenter`, `Environment`, `SAP-SID`, और `BusinessOwner` जैसे टैग का उपयोग करें। Azure Cost Management का उपयोग करके लागतों का विश्लेषण करें।

क्यों: टैगिंग संसाधनों को वर्गीकृत करने के लिए नेटिव Azure तंत्र है। लगातार टैगिंग विस्तृत लागत विश्लेषण और चार्जबैक को सक्षम बनाती है, जो आवश्यक वित्तीय दृश्यता प्रदान करती है।

Azure में SAP VMs के बीच रुक-रुक कर नेटवर्क कनेक्टिविटी या विलंबता समस्याओं का निदान करें।

→Azure Network Watcher टूल का उपयोग करें, विशेष रूप से Connection Monitor का उपयोग पथों और विलंबता का परीक्षण करने के लिए, और NSG Flow Logs का उपयोग अवरुद्ध ट्रैफ़िक का विश्लेषण और पहचान करने के लिए करें।

क्यों: Network Watcher Azure प्लेटफॉर्म स्तर पर नेटवर्क समस्याओं का पता लगाने के लिए सक्रिय और प्रतिक्रियाशील उपकरण प्रदान करता है, जिसे अक्सर केवल गेस्ट OS के भीतर से निदान करना मुश्किल होता है।

SAP VMs के लिए OS पैचिंग को स्वचालित करें, जबकि यह सुनिश्चित करें कि एप्लीकेशन ठीक से बंद हो जाएं।

→पूर्व/पश्चात स्क्रिप्ट के साथ Azure Update Manager का उपयोग करें। पूर्व-स्क्रिप्ट SAP एप्लीकेशन और डेटाबेस को रोकती है, और पश्चात-स्क्रिप्ट पैचिंग पूरी होने के बाद उन्हें पुनः आरंभ करती है।

क्यों: यह Azure पैच प्रबंधन के ऑटोमेशन को SAP के लिए आवश्यक एप्लीकेशन-जागरूकता के साथ जोड़ता है, जिससे डेटा विसंगतियों को रोका जा सकता है जो एक चल रहे सिस्टम को पैच करने से हो सकती हैं।

SUSE/RHEL Linux VMs पर SAP Central Services (ASCS/ERS) या SAP HANA के लिए उच्च उपलब्धता लागू करें।

→एक Pacemaker क्लस्टर कॉन्फ़िगर करें। स्प्लिट-ब्रेन परिदृश्यों को रोकने के लिए STONITH (फेंसिंग) के लिए `fence_azure_arm` एजेंट का उपयोग करें, जो एक प्रबंधित पहचान के माध्यम से प्रमाणित होता है।

क्यों: Pacemaker Linux पर SAP-समर्थित क्लस्टरिंग समाधान है। `fence_azure_arm` Azure API के माध्यम से विफल नोड को मज़बूती से अलग करने के लिए Azure-देशी तंत्र है, जो एक स्थिर क्लस्टर के लिए अनिवार्य है।

Windows Server VMs पर SAP Central Services (ASCS/ERS) के लिए उच्च उपलब्धता लागू करें।

→एक Windows Server Failover Cluster (WSFC) कॉन्फ़िगर करें। क्लस्टर साझा स्टोरेज के लिए, या तो Azure Shared Disks या SIOS DataKeeper जैसे तृतीय-पक्ष प्रतिकृति समाधान का उपयोग करें।

क्यों: WSFC Windows क्लस्टरिंग के लिए मानक है। Azure Shared Disks नेटिव साझा ब्लॉक स्टोरेज प्रदान करते हैं, जबकि SIOS एक "शेयर्ड-नथिंग" क्लस्टर बनाता है, दोनों क्लाउड में पारंपरिक SAN की आवश्यकता को प्रतिस्थापित करते हैं।

SAP HANA के लिए एक उच्च उपलब्धता (HA) और डिजास्टर रिकवरी (DR) रणनीति डिज़ाइन करें।

→HA (इन-रीजन) के लिए, VMs को Availability Zones में डिप्लॉय करें और सिंक्रोनस (SYNC) SAP HANA System Replication (HSR) का उपयोग करें। DR (क्रॉस-रीजन) के लिए, एसिंक्रोनस (ASYNC) HSR का उपयोग करें।

क्यों: सिंक्रोनस प्रतिकृति शून्य RPO प्रदान करती है लेकिन कम विलंबता (<2ms) की आवश्यकता होती है, जिससे यह ज़ोन में HA के लिए आदर्श बन जाती है। एसिंक्रोनस प्रतिकृति उच्च क्रॉस-रीजन विलंबता को सहन करती है, जिससे यह DR के लिए पसंद बन जाती है।

SAP HA क्लस्टर (ASCS/ERS या HANA) के लिए वर्चुअल IP एड्रेस को प्रबंधित करने के लिए एक Azure Load Balancer कॉन्फ़िगर करें।

→एक Azure Standard Load Balancer का उपयोग करें। लोड बैलेंसिंग नियम पर Floating IP (Direct Server Return) सक्षम करें। क्लस्टर द्वारा मॉनिटर किए गए विशिष्ट पोर्ट (उदाहरण के लिए, ASCS के लिए 620xx) पर एक हेल्थ प्रोब कॉन्फ़िगर करें।

क्यों: ज़ोन-रिडंडेंसी के लिए Standard SKU आवश्यक है। क्लस्टर के वर्चुअल IP को सही ढंग से कार्य करने के लिए Floating IP आवश्यक है। विशिष्ट हेल्थ प्रोब यह सुनिश्चित करता है कि ट्रैफ़िक केवल सक्रिय नोड पर भेजा जाए।

एक SAP ASCS उच्च उपलब्धता क्लस्टर में Enqueue Replication Server (ERS) के उद्देश्य को समझें।

→ERS इंस्टेंस सक्रिय ASCS इंस्टेंस से SAP लॉक टेबल की एक प्रतिकृति बनाए रखता है।

क्यों: यदि ASCS इंस्टेंस विफल हो जाता है, तो नया शुरू किया गया ASCS इंस्टेंस ERS से रेप्लिकेटेड लॉक टेबल को पुनः प्राप्त करता है। यह ट्रांजैक्शन लॉक को सुरक्षित रखता है और उपयोगकर्ताओं को बिना किसी रुकावट के काम जारी रखने की अनुमति देता है।

एक मल्टी-टियर SAP लैंडस्केप के लिए एक पूर्ण डिजास्टर रिकवरी समाधान डिज़ाइन करें।

→डेटाबेस टियर के लिए नेटिव डेटाबेस प्रतिकृति का उपयोग करें (उदाहरण के लिए, HANA के लिए एसिंक HSR)। एप्लीकेशन टियर (ASCS/ERS और एप्लीकेशन सर्वर) के लिए Azure Site Recovery (ASR) का उपयोग करें।

क्यों: यह "बेस्ट-ऑफ-ब्रीड" दृष्टिकोण डेटाबेस के लिए अपनी नेटिव प्रतिकृति के माध्यम से एप्लीकेशन कंसिस्टेंसी सुनिश्चित करता है, जबकि ASR एप्लीकेशन सर्वर VMs को रेप्लिकेट और फेल ओवर करने का एक लागत प्रभावी और स्वचालित तरीका प्रदान करता है।

Azure VMs में Microsoft SQL Server पर चल रहे SAP डेटाबेस के लिए उच्च उपलब्धता लागू करें।

→SQL Server Always On Availability Groups का उपयोग करें, आमतौर पर एक क्षेत्र के भीतर HA के लिए सिंक्रोनस-कमिट मोड के साथ, WSFC के संयोजन में।

क्यों: Always On AG SQL Server के लिए अनुशंसित और पूरी तरह से समर्थित HA/DR समाधान है, जो डेटाबेस-स्तरीय प्रतिकृति और स्वचालित फेलओवर क्षमताएं प्रदान करता है।

दो-नोड Pacemaker क्लस्टर के लिए कोरम तंत्र के रूप में SBD (STONITH Block Device) को लागू करें।

→एक छोटी Azure Shared Disk कॉन्फ़िगर करें और इसे दोनों क्लस्टर नोड्स से संलग्न करें। वैकल्पिक रूप से, तीसरे VM पर एक समर्पित iSCSI टारगेट सर्वर सेट करें।

क्यों: जबकि `fence_azure_arm` प्राथमिक फेंसिंग एजेंट है, SBD स्प्लिट-ब्रेन को रोकने के लिए एक अतिरिक्त विटनेस/कोरम तंत्र प्रदान करता है, खासकर तीसरे वोटिंग नोड के बिना क्लस्टर में।