मेट्रो वर्चुअल डेटा सेंटर: व्यवसाय निरंतरता के लिए विश्वसनीय, स्केलेबल IT समाधान

जैसे-जैसे IT बढ़ता जा रहा है, सूचना प्रणालियाँ विभिन्न उद्योगों में अधिक महत्वपूर्ण होती जा रही हैं। सूचना प्रणालियों में सेवा रुकावट से आर्थिक नुकसान, महत्वपूर्ण डेटा हानि, और बाजार में ब्रांड छवि पर प्रभाव पड़ सकता है, विशेष रूप से संचार, वित्त, चिकित्सा देखभाल, ई-कॉमर्स, लॉजिस्टिक्स, और सरकार जैसे उद्योगों के लिए। इसलिए, सेवा निरंतरता सूचना प्रणालियों के निर्माण के लिए महत्वपूर्ण है। वर्तमान में, सेवा निरंतरता को आमतौर पर डिजास्टर रिकवरी (DR) सेंटर बनाकर सुधारा जाता है जहां उत्पादन डेटा की प्रतियां सहेजी जाती हैं।

परिचय

पारंपरिक DR समाधान में, प्रत्येक उत्पादन डेटा सेंटर (DC) के लिए एक DR सेंटर तैनात किया जाता है। DR सेंटर सेवा पहुंच प्रदान नहीं करता जब तक कि उत्पादन DC को किसी आपदा का सामना न करना पड़े जो सेवा ब्रेकडाउन की ओर ले जाए, जिसे कम समय में ठीक नहीं किया जा सकता। इसलिए, DR सेंटर निम्नलिखित चुनौतियों का सामना करते हैं:

जब उत्पादन केंद्र को बिजली आपूर्ति विफलता, आग, बाढ़, या भूकंप का सामना करना पड़ता है, तो सेवाओं को DR सेंटर पर स्विच करने के लिए मैन्युअल ऑपरेशन आवश्यक है। पेशेवर रिकवरी उपाय और डीबगिंग भी आवश्यक हैं। ये आपदाएं दीर्घकालिक सेवा रुकावट और सेवा असंतति का कारण बन सकती हैं।
DR सेंटर सेवाएं प्रदान नहीं करता और अधिकांश समय बेकार रहता है, जो संसाधन उपयोग को कम करता है।

ग्राहकों की कुशल संसाधन उपयोग, लोड बैलेंसिंग, और दो DCs के बीच स्वचालित स्विचओवर की आवश्यकताओं को पूरा करने के लिए, Oracle® ने एंड-टू-एंड एक्टिव-एक्टिव DC समाधान लॉन्च किया। यह समाधान दोनों DCs को समवर्ती रूप से चलाने और सेवा लोड साझा करने में सक्षम बनाता है ताकि समग्र सेवा क्षमता और संसाधन उपयोग में सुधार हो सके। समाधान डिवाइस विफलताओं या एकल-DC विफलता के मामले में शून्य सेवा जागरूकता के साथ स्वचालित फेलओवर भी सुनिश्चित करता है। इसके अलावा, यह शून्य रिकवरी पॉइंट ऑब्जेक्टिव (RPO) और शून्य रिकवरी टाइम ऑब्जेक्टिव (RTO) का दावा करता है। नोट: RTO एप्लिकेशन सिस्टम और तैनाती मोड पर निर्भर करता है।

वर्तमान स्टोरेज उद्योग में दो उपलब्धता मोड हैं:

एक्टिव-पैसिव (AP) या एक्टिव-स्टैंडबाय
एक्टिव-एक्टिव (AA) या मेट्रो वर्चुअल डेटा सेंटर (MVDC)

डेटाबेस लेयर के महत्वपूर्ण घटक

डेटाबेस (DB) को शून्य डेटा हानि विकल्प के साथ एक्टिव-स्टैंडबाय मोड में सेट किया जाना चाहिए। निम्नलिखित आइटम महत्वपूर्ण घटक हैं:

Oracle Data Guard Broker: डेटा गार्ड कॉन्फ़िगरेशन को स्वचालित और केंद्रीकृत करता है और जटिल भूमिका परिवर्तनों के लिए एकल कमांड के साथ स्विचओवर या फेलओवर को लागू करने में मदद करता है।
फ्लैशबैक डेटाबेस: DB के लिए रिवाइंड, या रिवर्ट प्रदान करता है, और फ्लैश रिकवरी क्षेत्र में फ्लैशबैक लॉग जानकारी संग्रहीत करता है।
फास्ट-स्टार्ट फेलओवर (FSFO): शून्य डेटा हानि के साथ फेलओवर सक्षम करता है। FSFO तब तक ट्रिगर नहीं करता जब तक कि स्टैंडबाय DB प्राथमिक DB के साथ सिंक में न हो।
ऑब्जर्वर: डेटा गार्ड कमांड-लाइन इंटरफेस, dgmgrl में शामिल एक अलग प्रक्रिया प्रदान करता है, जो संभावित विफलता स्थितियों के लिए प्राथमिक और स्टैंडबाय DBs की स्थिति की निगरानी करता है।

डेटा गार्ड कॉन्फ़िगरेशन

निम्न छवि डेटा गार्ड कॉन्फ़िगरेशन दिखाती है:

मेट्रो वर्चुअल डेटा सेंटर: व्यवसाय निरंतरता के लिए विश्वसनीय, स्केलेबल IT समाधान

छवि स्रोत: https://neeraj-dba.blogspot.com/2011/10/dataguard-broker-and-its-benefits_05.html

प्राथमिक DB पर, लॉग राइटर (LGWR) प्रक्रिया एक या अधिक लॉग नेटवर्क सर्वर (LNSn) प्रक्रियाओं को रीडो डेटा सबमिट करती है, जो तब कई रिमोट डेस्टिनेशन पर समानांतर में नेटवर्क I/O आरंभ करती है। ट्रांजैक्शन प्राथमिक डेटाबेस पर तब तक कमिट नहीं होते जब तक कि ट्रांजैक्शन को पुनर्प्राप्त करने के लिए आवश्यक रीडो डेटा सभी LGWR SYNC डेस्टिनेशन द्वारा प्राप्त नहीं हो जाता।

स्टैंडबाय DB पर, रिमोट फाइल सर्वर (RFS) LGWR प्रक्रिया से नेटवर्क पर रीडो डेटा प्राप्त करता है और रीडो डेटा को स्टैंडबाय रीडो लॉग फ़ाइलों में लिखता है।

अधिकतम उपलब्धता आर्किटेक्चर

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

अनियोजित डाउनटाइम में निम्नलिखित आइटम के लिए अप्रत्याशित रुकावट शामिल है:

सर्वर उपलब्धता: आपको हार्डवेयर या सॉफ़्टवेयर दोष के कारण DB सर्वर की मेजबानी करने वाली एक या अधिक मशीनों की अप्रत्याशित विफलता के बावजूद DB सेवाओं तक निर्बाध पहुंच सुनिश्चित करने की आवश्यकता है। Oracle रियल एप्लिकेशन क्लस्टर (RAC) ऐसी विफलताओं के खिलाफ सबसे प्रभावी सुरक्षा प्रदान करते हैं।
डेटा उपलब्धता: डेटा विफलताओं को कम करने के लिए, जैसे व्यवसाय-महत्वपूर्ण डेटा की हानि, क्षति या भ्रष्टाचार, आपकी योजना को यह सुनिश्चित करने की आवश्यकता है कि आपके पास हमेशा आपके डेटा तक पहुंच हो।

नियोजित डाउनटाइम में निम्नलिखित आइटम सहित एक्सेस के लिए निर्धारित रुकावट शामिल है:

सिस्टम परिवर्तन
डेटा परिवर्तन
ऐप परिवर्तन

MVDC के लिए स्विचओवर टेस्टिंग परिदृश्य

एक स्विचओवर एक नियंत्रित, नियोजित भूमिका उलट ऑपरेशन है जहां डेटा गार्ड कॉन्फ़िगरेशन में प्राथमिक और स्टैंडबाय DB अपनी भूमिकाओं को स्विच करते हैं। स्विचओवर के बाद, प्रत्येक डेटाबेस अपनी नई भूमिका में डेटा गार्ड कॉन्फ़िगरेशन में भाग लेना जारी रखता है।

स्विचओवर प्रक्रिया

स्विचओवर निम्न क्रम में होता है:

मूल प्राथमिक DB स्टैंडबाय भूमिका में बदल जाता है।
मूल स्टैंडबाय DB प्राथमिक भूमिका में परिवर्तित हो जाता है।

जब आप स्विचओवर करते हैं तो डेटा गार्ड ब्रोकर निम्नलिखित गतिविधियों का स्वचालित रूप से ख्याल रखता है:

सत्यापित करता है कि प्राथमिक और लक्ष्य स्टैंडबाय DB ऑनलाइन हैं और कोई त्रुटि नहीं है।
प्राथमिक और स्टैंडबाय DB दोनों के लिए RAC कॉन्फ़िगरेशन में एक को छोड़कर सभी इंस्टेंस को बंद कर देता है।
प्राथमिक और स्टैंडबाय DB की भूमिकाओं को स्विच करता है। डेटा गार्ड ब्रोकर पहले मूल प्राथमिक DB को स्टैंडबाय भूमिका में चलाने के लिए परिवर्तित करता है। फिर, ब्रोकर लक्ष्य स्टैंडबाय DB को प्राथमिक भूमिका में परिवर्तित करता है। यह भूमिकाओं में परिवर्तन रिकॉर्ड करने के लिए ब्रोकर कॉन्फ़िगरेशन फ़ाइल को भी अपडेट करता है ताकि यह सुनिश्चित हो सके कि प्रत्येक DB रीस्टार्ट के बाद सही भूमिका में चलता है।
नई स्टैंडबाय (पूर्व प्राथमिक) DB को रीस्टार्ट करता है और रीडो अप्लाई प्रक्रिया शुरू करता है, नई प्राथमिक DB से रीडो डेटा लागू करता है। यदि यह RAC DB है, तो ब्रोकर स्विचओवर से पहले बंद किए गए इंस्टेंस को रीस्टार्ट करता है।
नई प्राथमिक DB को रीस्टार्ट करता है, खोलता है, और रीडो ट्रांसपोर्ट सेवाएं शुरू करता है, स्टैंडबाय DB को रीडो डेटा प्रसारित करता है। यदि यह RAC DB है, तो ब्रोकर स्विचओवर से पहले बंद किए गए इंस्टेंस को रीस्टार्ट करता है।

स्विचओवर से पहले:

छवि स्रोत: https://docs.oracle.com/cd/E11882_01/server.112/e41134/role_management.htm#SBYDB00615

स्विचओवर के बाद:

छवि स्रोत: https://docs.oracle.com/cd/E11882_01/server.112/e41134/role_management.htm#SBYDB00615

स्विचओवर करने के चरण

स्विचओवर करने के लिए, निम्न चरणों को निष्पादित करें:

सुनिश्चित करें कि एप्लिकेशन पूरी तरह से बंद है, और कोई उपयोगकर्ता डेटाबेस से जुड़ा नहीं है।
स्विचओवर शुरू होने से कम से कम 30 मिनट पहले दोनों DCs में चल रहे आर्काइव UTL स्क्रिप्ट को अक्षम करें। टेस्टिंग पूरी होने और DB पसंदीदा स्थान में चलने के बाद, आर्काइव्ड यूटिलिटी स्क्रिप्ट को अनकमेंट करें।

वर्तमान प्राथमिक DB में निम्न SQL क्वेरी चलाएं:

SELECT * FROM DBA_JOBS_RUNNING; (कोई भी sys स्वामित्व वाली जॉब नहीं चलनी चाहिए) 
SELECT OWNER, JOB_NAME, START_DATE, END_DATE, ENABLED FROM DBA_SCHEDULER_JOBS WHERE ENABLED='TRUE' AND OWNER <> 'SYS'; (डेटा गार्ड ब्रोकर sys के स्वामित्व वाली जॉब को नहीं मारता।)

job_queue_processes और aq_tm_processes को 0 पर सेट करें। मूल मूल्य को नोट करें क्योंकि स्विचओवर टेस्टिंग पूरी होने के बाद आपको इसे मूल मूल्य पर रीसेट करना होगा।
प्राथमिक DB पर चल रहे emagent को रोकें।

वर्तमान प्राथमिक DB में निम्न SQL क्वेरी चलाएं:

SELECT sid, username, status, program, inst_id FROM gv$session WHERE username is not null and status='ACTIVE' order by inst_id; (सक्रिय कनेक्शन की संख्या मान्य करें और जांचें; बड़ी संख्या में सक्रिय कनेक्शन स्विचओवर में अधिक समय लगने का कारण बन सकते हैं।)

उन सभी sqlplus सत्रों से लॉग आउट करें जहां आप sys के रूप में जुड़े हुए हैं।

वर्तमान प्राथमिक DB में निम्न SQL क्वेरी चलाएं:

set linesize to 132 col value format a35 SELECT inst_id,name,value from gv$parameter WHERE name in ('job_queue_processes','aq_tm_processes'); (job_queue_processes और aq_tm_processes के मान की जांच और मान्य करें, जो शून्य होना चाहिए।)

डेटा गार्ड कॉन्फ़िगरेशन को मान्य करने के लिए निम्न कमांड चलाएं:

DGMGRL> show configuration verbose ** STATUS को सफल दिखाना चाहिए, यदि स्थिति "सफल" नहीं है तो आगे न बढ़ें।

क्लस्टर रेडी सर्विसेज (CRS) स्थिति की जांच करें ताकि यह सुनिश्चित हो सके कि सभी संसाधन ऑनलाइन पंजीकृत हैं क्योंकि ब्रोकर इस प्रक्रिया के दौरान DB को माउंट और शटडाउन करने के लिए CRS को हैंडओवर देता है।
प्राथमिक DB पर कुछ लॉग स्विचओवर करें और सत्यापित करें कि वे स्टैंडबाय DB पर लागू हो गए हैं।
आगे बढ़ने से पहले, स्विचओवर करें और किसी भी विफलता के लिए DRC लॉग और अलर्ट लॉग की निगरानी करें। निम्न कमांड पुराने प्राथमिक को स्टैंडबाय में और फिर पुराने स्टैंडबाय को प्राथमिक में परिवर्तित करता है:
```
DGMGRL> switchover to 'DDMPROD_STANDBY';
```
स्विचओवर पूरा होने के बाद, सुनिश्चित करें कि लॉग ट्रांसपोर्ट और लॉग अप्लाई सेवाएं चालू हैं और ठीक से काम कर रही हैं।

MVDC के लिए फेलओवर टेस्टिंग परिदृश्य

एक फेलओवर तब होता है जब प्राथमिक DB (RAC प्राथमिक DB के सभी इंस्टेंस) विफल हो जाता है और स्टैंडबाय DB प्राथमिक भूमिका संभालने के लिए परिवर्तित हो जाता है। फेलओवर निम्नलिखित मामलों में किया जाता है:

प्राथमिक DB की विनाशकारी विफलता जिसमें प्राथमिक DB को समय पर पुनर्प्राप्त करने की कोई संभावना नहीं है।
जब ऑब्जर्वर और स्टैंडबाय DB दोनों प्राथमिक DB से अपना नेटवर्क कनेक्शन खो देते हैं, और जब स्टैंडबाय DB पुष्टि करता है कि यह सिंक्रनाइज़्ड स्थिति में है।

फेलओवर परिदृश्य

निम्नलिखित DB स्थितियां फास्ट-स्टार्ट फेलओवर को ट्रिगर करती हैं:

प्राथमिक साइट विफलता
प्राथमिक DB स्थितियां, जिनमें निम्न शामिल हैं:
इंस्टेंस विफलता
अंतिम जीवित इंस्टेंस, यदि RAC
अंतिम उपलब्ध इंस्टेंस का शटडाउन अबॉर्ट
I/O त्रुटियों के कारण डेटा फ़ाइलों को ऑफ़लाइन ले जाया गया (ऑफ़लाइन डेटा फ़ाइलों के कारण फेलओवर करते समय थ्रेशोल्ड नज़रअंदाज किया जाता है)

नेटवर्क-संबंधी स्थितियां फेलओवर का कारण बन सकती हैं केवल यदि प्राथमिक और ऑब्जर्वर के बीच लिंक, साथ ही प्राथमिक और लक्ष्य स्टैंडबाय DBs के बीच लिंक, डाउन हैं। ऑब्जर्वर और स्टैंडबाय के बीच एक कनेक्शन आवश्यक है ताकि ऑब्जर्वर यह पुष्टि कर सके कि कॉन्फ़िगरेशन सिंक्रनाइज़्ड स्थिति में है।

छवि स्रोत: https://docs.oracle.com/cd/E11882_01/server.112/e41134/role_management.htm#SBYDB00615

निष्कर्ष

एक MVDC कुशल संसाधन उपयोग, लोड बैलेंसिंग, उच्च उपलब्धता, और दो DCs के बीच स्वचालित स्विचओवर में मदद करता है। दोनों DCs समवर्ती रूप से चलते हैं (एक्टिव-एक्टिव) सेवा लोड साझा करने और समग्र सेवा क्षमता में सुधार करने के लिए। एक MVDC डिजास्टर रिकवरी फेलओवर या अपग्रेड/रखरखाव स्विचओवर के लिए डेटाबेस के बीच स्विच करने के लिए आवश्यक मानवीय हस्तक्षेप को कम करता है।

टिप्पणी करने या प्रश्न पूछने के लिए फीडबैक टैब का उपयोग करें।

विशेषज्ञ प्रशासन, प्रबंधन और कॉन्फ़िगरेशन के साथ अपने वातावरण को अनुकूलित करें

Rackspace के एप्लिकेशन सर्विसेज (RAS) विशेषज्ञ अनुप्रयोगों के एक विस्तृत पोर्टफोलियो में निम्नलिखित पेशेवर और प्रबंधित सेवाएं प्रदान करते हैं:

ईकॉमर्स और डिजिटल एक्सपीरियंस प्लेटफॉर्म
एंटरप्राइज रिसोर्स प्लानिंग (ERP)
बिजनेस इंटेलिजेंस
सेल्सफोर्स कस्टमर रिलेशनशिप मैनेजमेंट (CRM)
डेटाबेस
ईमेल होस्टिंग और उत्पादकता

हम प्रदान करते हैं:

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

अभी चैट करें शुरू करने के लिए।