| स्तर (प्रस्तावित) | उपलब्धता | नमुना | आरपीओ / आरटीओ |
|---|---|---|---|
| मानक | ९९.७% | मल्टी-झोन, एचए डेटाबेस, एअर-गॅप्ड बॅकअप्स | झोन: RPO ≈ 0. प्रदेश: व्हॉल्टमधून पुनर्संचयित करा. |
| Live DR | ९९.९% | दुसरा प्रदेश थेट कार्यरत आहे | RPO सेकंद, RTO ≤ १५ मिनिटे |
| Live DR प्रीमियम | ९९.९५% | दोन्ही प्रदेशांतील वाहतूक, २४×७ प्राधान्य | RPO सेकंद, RTO ≤ ५ मिनिटे |
उत्पादन नसण्याचे प्रमाण ९५% आहे. उपलब्धता दरमहा TRANXACT इनग्रेसवर मोजली जाते, ज्यामध्ये मान्य केलेली देखभाल वेळ (महिन्यातून प्रस्तावित ४ तास) वगळण्यात येते.
आकार निश्चित करण्यापूर्वी स्तर निश्चित करा. Live DR हा एक पूर्ण आकाराचा दुसरा प्रदेश आहे आणि त्यामुळे रनटाइम पायाभूत सुविधांचा खर्च अंदाजे दुप्पट होतो; त्यामुळे कमी होणाऱ्या डाउनटाइम खर्चाच्या तुलनेत, हा खर्च एक स्वतंत्र ओळ म्हणून दाखवा.
जगा, निष्क्रिय राहू नका.
पॅसिव्ह स्टँडबाय निष्क्रिय असतो, त्याची चाचणी वर्षातून एकदाच केली जाते आणि रिस्टोअर व स्केलिंग अपद्वारे फेलओव्हर होतो. Live DR एक पूर्ण-आकाराचा क्लस्टर आणि सतत प्रतिकृती केलेला डेटाबेस चालवतो, जे दिवसभर रीड्स, रिपोर्टिंग, ASK आणि सिंथेटिक पोस्टिंगसाठी सेवा देतात. फेलओव्हर म्हणजे प्रमोशन — काहीही पुन्हा तयार केले जात नाही — आणि त्याची कार्यक्षमता प्रत्येक मिनिटाला तपासली जाते.
| चाचणी | प्रभाव | किती वेळा | श्रेणी |
|---|---|---|---|
| सतत पडताळणी — सिंथेटिक पोस्टिंग, लॅग अलर्ट, क्रॉस-रिजन लेजर चेकसम | काहीही नाही | प्रत्येक मिनिट | मानक (टीओ_४.१०.०१) |
| नियोजित पदबदल सराव — लेखन थांबवा, पदोन्नती करा, बदली करा, पडताळणी करा; भूमिकांची अदलाबदल होते. | लिखाण काही सेकंदांसाठी थांबले. | त्रैमासिक | मानक (टीओ_४.१०.०३) |
| अतिरिक्त स्विचओव्हर ड्रिल | लिखाण काही सेकंदांसाठी थांबले. | विनंतीनुसार, २ आठवडे आधी | अतिरिक्त (टीओ_४.१०.०४) |
| विलग ड्रिल — एकीकरण अक्षम केलेला एक कुंपणयुक्त क्लोन | उत्पादनावर काहीही नाही | विनंतीनुसार, २ आठवडे आधी | अतिरिक्त (टीओ_४.१०.०५) |
| स्वच्छ-खोली पुनर्स्थापना चाचणी | उत्पादनावर काहीही नाही | वार्षिक | मानक (टीओ_४.९.०७) |
| सरावानंतर व्यवसायाची पडताळणी | ग्राहक प्रयत्न | प्रत्येक सराव | वगळले (TO_4.10.06) |
बॅकअप
| उत्पादन डीबी | नॉन-प्रोड डीबी | |
|---|---|---|
| घेतले | दैनंदिन स्नॅपशॉट + सतत लॉग | दैनंदिन स्नॅपशॉट |
| बरे होण्यासाठी | ३० दिवसांत कोणत्याही वेळी | शेवटचा स्नॅपशॉट, १४ दिवस |
| व्हॉल्ट प्रत | दैनिक, अपरिवर्तनीय, ९० दिवस | साप्ताहिक, अपरिवर्तनीय, ३० दिवस |
दस्तऐवजांची आवृत्ती सातत्याने तयार केली जाते आणि उत्पादनासाठी दररोज व्हॉल्टमध्ये कॉपी केली जाते. इन्फ्रास्ट्रक्चर-ॲज-कोड आणि कॉन्फिगरेशन देखील व्हॉल्टमध्ये असतात, त्यामुळे रनटाइम पुनर्संचयित करण्याऐवजी कोडमधून पुनर्निर्मित केला जातो.
तिजोरी का?
रेप्लिकेशन हे आउटेजपासून संरक्षण करते, डेटा करप्ट होण्यापासून नाही. रॅन्समवेअर किंवा खराब डेटा काही सेकंदातच स्टँडबाय आणि DR रिजनमध्ये रेप्लिकेट होतो. व्हॉल्ट हे स्वतंत्र आयडेंटिटी आणि कीज असलेले एक स्वतंत्र अकाउंट आहे, प्रोडक्शनपासून कोणताही नेटवर्क मार्ग नाही, एकदाच लिहिण्याची रिटेन्शन (write-once retention) आहे जी प्रशासकसुद्धा कमी करू शकत नाहीत, आणि डिलीशनसाठी दुहेरी मंजुरीची आवश्यकता असते. त्यातून रिस्टोअर केलेला डेटा एका आयसोलेटेड एन्व्हायर्नमेंटमध्ये जातो — स्कॅन, रिकन्साइल, आणि मग प्रमोट — तो कधीही थेट प्रोडक्शनवर पाठवला जात नाही.
एकदा सेट केलेला रिटेन्शन लॉक कमी करता येत नाही. ऑडिट किंवा कायदेशीर होल्डसाठी गरज असल्यास तो आधीच वाढवा, आणि दीर्घकालीन प्रतींचा आकार आजच्या डेटाबेसच्या आकारावरून नव्हे, तर लेजरच्या वाढीनुसार आणि कागदपत्रांच्या संख्येनुसार निश्चित करा.
कॅल्डरवुडने त्याच अधिकारक्षेत्रातील दुसऱ्या अझूर प्रदेशात ९९.९% वर Live DR निवडले. गो-लाइव्ह होण्यापूर्वी, सज्जता टप्पे म्हणून त्याचा पहिला स्विचओव्हर सराव आणि क्लीन-रूम रिस्टोअर नियोजित आहेत. त्याचे बँक आणि पेरोल भागीदार स्विचओव्हर योजनेत समाविष्ट आहेत, जेणेकरून त्यांचे एंडपॉइंट्स ट्रॅफिक मॅनेजरला अनुसरतील.
हे वापरून पहा १४:०५ वाजता एका बॅच जॉबमुळे कॅल्डरवुडची ४,००० बिले खराब होतात. Live DR व्यवस्थित चालू आहे, फक्त त्यात २ सेकंदांचा लॅग आहे. डीआर रिजनवर फेलओव्हर करणे हा यावर उपाय आहे का?
नाही. डेटा करप्शन घडल्यानंतर काही सेकंदातच ते स्टँडबाय आणि DR रिजनमध्ये रेप्लिकेट झाले — फेलओव्हर केल्याने तुम्ही त्याच खराब डेटावर जाता. यावर उपाय म्हणजे १४:०४ वाजता पॉइंट-इन-टाइम रिस्टोअर करणे (TO_4.9.05, स्टँडर्ड) किंवा, जर हिस्ट्रीमध्येच काही शंका असेल, तर व्हॉल्टमधून क्लीन-रूम रिस्टोअर करणे (TO_4.9.06), आणि रिस्टोअर केलेल्या डेटाला फायनान्स कंट्रोलरची मंजुरी घेणे (TO_4.9.11).