संदर्भ आर्किटेक्चर और रनटाइम

ग्राहक के क्लाउड में क्या-क्या निर्मित है: इनग्रेस, ज़ोन में फैला तीन-नोड वाला कुबेरनेट्स क्लस्टर, स्टैंडबाय के साथ प्रबंधित डेटाबेस, ऑब्जेक्ट स्टोरेज, इग्रेस, एयर-गैप्ड वॉल्ट और साइजिंग नॉब्स।

प्रत्येक परिनियोजन को एक ही संदर्भ आर्किटेक्चर के आधार पर एक बार डिज़ाइन किया जाता है। क्लाउड के बीच अंतर — कनेक्टिविटी उत्पाद, कुंजी प्रबंधन, डेटाबेस इंजन — फिर रीडिज़ाइन के बजाय कॉन्फ़िगरेशन विकल्प बन जाते हैं।

डिज़ाइन	निर्माण	प्रचालन	नया
प्रत्येक वित्तीय घटना के लिए एक ही डेटा मॉडल और एक ही पोस्टिंग इंजन।	तीन-नोड वाले, लोड-संतुलित कुबेरनेट्स क्लस्टर पर कंटेनरीकृत सेवाएं।	अपरिवर्तनीय पोस्टिंग और संपूर्ण ऑडिट ट्रेल को डिजाइन के अनुसार शामिल किया गया है।	ASK, TRANXACT के अपने API के माध्यम से कार्य करता है।
डिजाइन के अनुसार यह बहु-इकाई, बहु-मुद्रा और बहु-क्षेत्रीय है।	ग्राहक की पसंद का एक प्रबंधित डेटाबेस, जो उच्च उपलब्धता के लिए उपयुक्त आकार का हो।	दूसरे चालू क्षेत्र में Live DR और मानक के रूप में एयर-गैप्ड बैकअप।	एक भूमिका-जागरूक एक्शन क्यू जो यह सीखता है कि क्या महत्वपूर्ण है।

एक क्षेत्र के अंदर क्या है?

अवयव	यह क्या है	टिप्पणियाँ
लोड बैलेंसर और WAF	HTTPS प्रवेश erp.<ग्राहक डोमेन> पर; TLS 1.2 या उच्चतर; DDoS सुरक्षा।	यह एकमात्र सार्वजनिक प्रवेश द्वार है।
निजी एंडपॉइंट / आंतरिक लोड बैलेंसर	वीपीएन, निजी कनेक्शन या पीयरिंग के माध्यम से निजी ट्रैफ़िक के लिए प्रवेश द्वार।	निजी पहुंच का उपयोग करते समय मौजूद।
कुबेरनेट्स क्लस्टर	उपलब्धता क्षेत्रों में फैले कम से कम तीन वर्कर नोड्स, एंड-टू-एंड टीएलएस के साथ।	यह वेब और एपीआई, पोस्टिंग इंजन, ASK ऑपरेटर और वर्कर्स और जॉब्स को चलाता है।
प्रबंधित डेटाबेस	एक प्राइमरी जिसमें दूसरे ज़ोन में सिंक्रोनस HA स्टैंडबाय हो।	इंजन और आकार ग्राहक की पसंद पर निर्भर करते हैं।
ऑब्जेक्ट स्टोरेज	दस्तावेज़ और संलग्नक, वर्शन किए गए, क्षेत्रों में प्रतिरूपित।	दस्तावेज़ डेटाबेस में स्थायी रूप से मौजूद नहीं होते हैं।
NAT निकास	केवल चुनिंदा गंतव्यों के लिए ही आउटबाउंड ट्रैफ़िक की अनुमति है।	बैंक, कर और ई-इनवॉइसिंग, वेतन भुगतान, ईमेल, एआई इंजन।
वायु-अंतराल वाला वॉल्ट	एक अलग खाता जिसमें अपरिवर्तनीय, एक बार लिखने योग्य बैकअप रखे जाते हैं।	उत्पादन केवल इसी तक सीमित रह सकता है, और किसी अन्य चीज तक नहीं।

वर्कर नोड्स को ज़ोन में इस तरह से फैलाया गया है कि एक नोड या एक ज़ोन के बंद होने पर भी उपयोगकर्ताओं को सेवा प्रदान करने की क्षमता बनी रहे। प्रत्येक सेवा किस नोड पर चलती है, यह गाइड में उदाहरण के तौर पर बताया गया है — शेड्यूलर ही उन्हें निर्धारित करता है।

समूह के बाहर

ASK के लिए AI इंजन — प्रीमियम, बैलेंस्ड या इकोनॉमी टियर, या ग्राहक की अपनी कुंजी (BYOK)।
बाह्य सेवाएं — बैंक, कर और ई-इनवॉइसिंग, पेरोल, बीआई और डेटा प्लेटफॉर्म, ईमेल।
दूरस्थ और मोबाइल उपयोगकर्ता, ग्राहक के पहचान प्रदाता के माध्यम से साइन इन करते हैं।
ग्राहक का कॉर्पोरेट नेटवर्क: कार्यालय उपयोगकर्ता, पहचान प्रदाता, पुराने और शॉप-फ्लोर सिस्टम - निजी कनेक्टिविटी का उपयोग किए जाने पर वीपीएन या निजी लिंक के माध्यम से इन तक पहुंचा जा सकता है।

निजी कनेक्टिविटी वैकल्पिक है। जब सभी एक्सेस HTTPS पर होता है, तो VPN/निजी लिंक और आंतरिक लोड बैलेंसर स्थापित नहीं होते हैं।

साइजिंग नॉब्स

नोड का आकार।
नोड की संख्या - न्यूनतम तीन।
डेटाबेस इंजन और आकार।
Live DR क्षेत्र।
वातावरणों की संख्या।

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

कॉन्फ़िगर करें, अनुकूलित न करें

क्लस्टर में चलने वाले कार्यों पर भी यही सिद्धांत लागू होता है। मानक से परे की आवश्यकताएँ निम्न क्रम में पूरी की जाती हैं: कॉन्फ़िगरेशन द्वारा (लो-कोड/नो-कोड, प्लेटफ़ॉर्म के साथ अपग्रेड किया गया); क्लस्टर के बाहर चलने वाले TRANXACT API के माध्यम से एकीकरण द्वारा; और उसके बाद ही, सुरक्षा और इंजीनियरिंग समीक्षा के बाद, क्लस्टर के भीतर कोड या एजेंट द्वारा — जिसे यदि अनुमोदित किया जाता है, तो उसे स्वीकार किया जाता है और ग्राहक सहायता प्रदान की जाती है। अस्वीकृत कोड क्लस्टर के बाहर चलता है। वर्कबुक के X अध्याय में प्रत्येक परिणाम के लिए कार्यों की सूची दी गई है।

कॉन्फ़िगरेशन द्वारा प्राप्त की जा सकने वाली कोई भी चीज़ कस्टम कोड नहीं बननी चाहिए। कॉन्फ़िगरेशन प्रत्येक प्लेटफ़ॉर्म रिलीज़ के साथ बदलता रहता है; कस्टम कोड नहीं बदलता।

इस विषय पर आरेखों और जांच के साथ पाठ्यक्रम लें।