एकच डिझाइन, जे प्रत्येक ग्राहकासाठी वापरले जाते. क्लाउड-विशिष्ट फरक — जसे की कनेक्टिव्हिटी उत्पादन, मुख्य सेवा, डेटाबेस इंजिन — हे कॉन्फिगरेशनचे पर्याय आहेत, पुनर्रचना नव्हे. यामुळेच पाच कामकाजाच्या दिवसांत कोडमधून एक वातावरण तयार करणे शक्य होते.
चित्र वरून वाचणे
- वापरकर्ते आणि इंटिग्रेशन्स erp.<customer domain> या एकाच नावाने येतात आणि HTTPS, TLS 1.2 किंवा त्याहून उच्च आवृत्तीवर WAF असलेल्या लोड बॅलन्सरपर्यंत पोहोचतात. आत येण्याचा हा एकमेव सार्वजनिक मार्ग आहे.
- किमान तीन वर्कर नोड्स, प्रत्येक अवेलेबिलिटी झोनसाठी एक, वेब आणि API, पोस्टिंग इंजिन, ASK ऑपरेटर, तसेच वर्कर्स आणि जॉब्स चालवतात. एक नोड किंवा संपूर्ण झोन बंद पडल्यास वापरकर्त्यांना सेवा देण्याची क्षमता शिल्लक राहते.
- व्यवस्थापित डेटाबेस — ग्राहकाच्या पसंतीचे इंजिन आणि आकार — दुसऱ्या झोनमध्ये एक सिंक्रोनस स्टँडबाय ठेवतो. झोन निकामी झाल्यास काहीही नुकसान होत नाही: RPO ≈ 0.
- दस्तऐवज आणि संलग्नक डेटाबेसमध्ये नसून, व्हर्जन्ड ऑब्जेक्ट स्टोरेजमध्ये साठवले जातात.
- बाहेर जाणारी रहदारी (आउटबाउंड ट्रॅफिक) NAT मधून एका अनुमत-सूचीकडे (allow-list) जाते: बँका, कर आणि ई-इनव्हॉइसिंग, वेतनपट (पेरोल), ईमेल, एआय इंजिन. याव्यतिरिक्त दुसरे काहीही नाही.
- बॅकअप एका वेगळ्या खात्यातील एअर-गॅप्ड व्हॉल्टमध्ये एकतर्फी पाठवले जातात.
खाजगी एंडपॉइंट आणि अंतर्गत लोड बॅलेंसर तुटक रेषेने दर्शवले आहेत, कारण ते केवळ खाजगी प्रवेश वापरला जातो तेव्हाच अस्तित्वात असतात. केवळ HTTPS प्रवेशासह ते तयार केलेले नसतात.
पाच नॉब, बाकी काही नाही.
नोडचा आकार; नोडची संख्या, किमान तीन; डेटाबेस इंजिन आणि त्याचा आकार; Live DR रिजन; एन्व्हायर्नमेंटची संख्या. बाकी सर्व काही रेफरन्स आर्किटेक्चर आहे.
कॉन्फिगर करा, एकीकृत करा आणि त्यानंतरच कोडिंग करा.
मानकांच्या पलीकडील एखादी आवश्यकता, जर ती प्लॅटफॉर्मसोबत अपग्रेड करता येत असेल तर, कॉन्फिगरेशनद्वारे पूर्ण केली जाते. तसे नसल्यास, क्लस्टरच्या बाहेर चालणाऱ्या TRANXACT API द्वारे इंटिग्रेशन करून ती पूर्ण केली जाते. केवळ त्यानंतरच, सुरक्षा आणि अभियांत्रिकी पुनरावलोकनानंतर, क्लस्टरमधील कोड किंवा एजंटचा विचार केला जातो; मंजूर झाल्यास, त्याला परवानगी दिली जाते आणि ग्राहकांकडून समर्थन पुरवले जाते, आणि नामंजूर झाल्यास ते बाहेर चालवले जाते.
ग्राहकाला थेट डेटाबेस ऍक्सेस उपलब्ध नाही — तो 'उपलब्ध नाही' (DB_3.1.09) असे चिन्हांकित आहे. रिपोर्टिंग आणि इंटिग्रेशन हे TRANXACT APIs आणि एक्स्ट्रॅक्ट्सद्वारे होते, आणि म्हणूनच BI टूल कधीही डेटाबेस लॉगिनद्वारे न जोडता, API किंवा शेड्युल्ड एक्स्ट्रॅक्टद्वारे जोडले जाते.
कॅल्डरवुडची BI टीम त्यांच्या वेअरहाऊससाठी एका रीड-ओन्ली डेटाबेस युझरची मागणी करते. याचे उत्तर म्हणजे प्रायव्हेट लिंकद्वारे शेड्युल्ड एक्स्ट्रॅक्ट करणे — त्यांच्या इंटरफेस लिस्टमधील BI रो "कीप, शेड्युल्ड एक्स्ट्रॅक्ट, प्रायव्हेट लिंक" असा आहे.
हे वापरून पहा कॅल्डरवुडच्या महिन्याच्या अखेरीस झोन २ मधील एक वर्कर नोड निकामी होतो. याचा वापरकर्त्यांवर काय परिणाम होतो, आणि ही कारवाई एसएलए (SLA) मध्ये गणली जाते का?
त्याचे पॉड्स झोन १ आणि ३ मधील नोड्सवर पुन्हा शेड्यूल केले जातात, जे भार पेलण्यासाठी सुसज्ज होते; जर झोन २ मध्ये प्रायमरी नसेल तर डेटाबेसवर कोणताही परिणाम होत नाही, अशावेळी तो RPO ≈ 0 सह सिंक्रोनस स्टँडबायवर फेलओव्हर होतो. जर महिन्याची उपलब्धता टियर टार्गेट पूर्ण करू शकली नाही, तरच याची गणना SLA मध्ये केली जाते.