एक ही डिज़ाइन, हर ग्राहक के लिए। क्लाउड से संबंधित अंतर — कनेक्टिविटी उत्पाद, मुख्य सेवा, डेटाबेस इंजन — कॉन्फ़िगरेशन विकल्प हैं, न कि रीडिज़ाइन। यही कारण है कि कोड से पांच कार्यदिवसों में एक वातावरण का निर्माण संभव है।
चित्र को ऊपर से पढ़ना
- उपयोगकर्ता और इंटीग्रेशन एक ही नाम, erp.<customer domain>, पर पहुंचते हैं और HTTPS, TLS 1.2 या उससे उच्चतर के माध्यम से WAF वाले लोड बैलेंसर तक पहुंचते हैं। यही एकमात्र सार्वजनिक प्रवेश द्वार है।
- कम से कम तीन वर्कर नोड, प्रत्येक उपलब्धता क्षेत्र में एक, वेब और एपीआई, पोस्टिंग इंजन, ASK ऑपरेटर और वर्कर और जॉब चलाते हैं। किसी नोड या पूरे क्षेत्र के निष्क्रिय होने पर भी क्षमता उपयोगकर्ताओं की सेवा में बनी रहती है।
- ग्राहक की पसंद के इंजन और आकार वाले प्रबंधित डेटाबेस का दूसरे ज़ोन में सिंक्रोनस स्टैंडबाय मोड होता है। ज़ोन फेल होने पर कोई नुकसान नहीं होता: RPO ≈ 0।
- दस्तावेज़ और संलग्नक वर्ज़न्ड ऑब्जेक्ट स्टोरेज में रहते हैं, डेटाबेस में नहीं।
- आउटबाउंड ट्रैफिक NAT के माध्यम से एक अलाउ-लिस्ट तक जाता है: बैंक, टैक्स और ई-इनवॉइसिंग, पेरोल, ईमेल, एआई इंजन। इसके अलावा कुछ नहीं।
- बैकअप को एक अलग खाते में स्थित एयर-गैप्ड वॉल्ट में एक ही दिशा में भेजा जाता है।
प्राइवेट एंडपॉइंट और इंटरनल लोड बैलेंसर को डैश वाली रेखा से दर्शाया गया है क्योंकि ये केवल प्राइवेट एक्सेस के इस्तेमाल पर ही मौजूद होते हैं। HTTPS-ओनली एक्सेस के साथ ये नहीं बनते।
पांच घुंडी, और कुछ नहीं।
नोड का आकार; नोड की संख्या (कम से कम तीन); डेटाबेस इंजन और उसका आकार; Live DR क्षेत्र; वातावरणों की संख्या। बाकी सब संदर्भ आर्किटेक्चर है।
पहले कॉन्फ़िगर करें, एकीकृत करें, और फिर कोड लिखें।
मानक आवश्यकताओं से परे किसी आवश्यकता को प्लेटफ़ॉर्म के साथ अपग्रेड किए जाने पर कॉन्फ़िगरेशन द्वारा पूरा किया जाता है। यदि ऐसा संभव नहीं है, तो क्लस्टर के बाहर चलने वाले TRANXACT API के माध्यम से एकीकरण द्वारा पूरा किया जाता है। सुरक्षा और इंजीनियरिंग समीक्षा के बाद ही क्लस्टर के भीतर कोड या एजेंट पर विचार किया जाता है; यदि अनुमोदित हो जाता है तो इसे स्वीकार किया जाता है और ग्राहक सहायता प्रदान की जाती है, और यदि अस्वीकृत हो जाता है तो यह क्लस्टर के बाहर चलता है।
ग्राहक के लिए डेटाबेस तक सीधी पहुंच उपलब्ध नहीं है — इसे अनुपलब्ध के रूप में चिह्नित किया गया है (DB_3.1.09)। रिपोर्टिंग और एकीकरण TRANXACT API और एक्सट्रैक्ट के माध्यम से होते हैं, यही कारण है कि BI टूल API या निर्धारित एक्सट्रैक्ट के माध्यम से कनेक्ट होता है, न कि डेटाबेस लॉगिन के माध्यम से।
कैल्डरवुड की BI टीम अपने वेयरहाउस के लिए एक रीड-ओनली डेटाबेस उपयोगकर्ता की मांग करती है। इसका उत्तर एक प्राइवेट लिंक के माध्यम से निर्धारित एक्सट्रैक्ट है - उनकी इंटरफ़ेस सूची में BI पंक्ति "कीप, निर्धारित एक्सट्रैक्ट, प्राइवेट लिंक" के रूप में मौजूद है।
इसे अजमाएं कैल्डरवुड के महीने के अंत में ज़ोन 2 का एक वर्कर नोड फेल हो जाता है। उपयोगकर्ताओं पर क्या असर पड़ेगा, और क्या यह SLA के विरुद्ध माना जाएगा?
इसके पॉड्स को ज़ोन 1 और 3 के नोड्स पर पुनः शेड्यूल किया जाता है, जिन्हें लोड वहन करने के लिए आकार दिया गया था; डेटाबेस अप्रभावित रहता है जब तक कि ज़ोन 2 प्राथमिक नोड न हो, ऐसी स्थिति में यह RPO ≈ 0 के साथ सिंक्रोनस स्टैंडबाय पर फ़ेलओवर हो जाता है। यह SLA के विरुद्ध तभी गिना जाता है जब महीने की उपलब्धता टियर लक्ष्य से कम हो।