ಪ್ರತಿಯೊಬ್ಬ ಗ್ರಾಹಕರಿಗೆ ಒಂದೇ ವಿನ್ಯಾಸವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಸಂಪರ್ಕ ಉತ್ಪನ್ನ, ಪ್ರಮುಖ ಸೇವೆ, ಡೇಟಾಬೇಸ್ ಎಂಜಿನ್ - ಕ್ಲೌಡ್-ನಿರ್ದಿಷ್ಟ ವ್ಯತ್ಯಾಸಗಳು - ಸಂರಚನಾ ಆಯ್ಕೆಗಳಾಗಿವೆ, ಮರುವಿನ್ಯಾಸವಲ್ಲ. ಅದು ಐದು ಕೆಲಸದ ದಿನಗಳಲ್ಲಿ ಕೋಡ್‌ನಿಂದ ಪರಿಸರವನ್ನು ನಿರ್ಮಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.
ಮೇಲಿನಿಂದ ಚಿತ್ರವನ್ನು ಓದುವುದು
- ಬಳಕೆದಾರರು ಮತ್ತು ಏಕೀಕರಣಗಳು erp.<customer domain> ಎಂಬ ಒಂದು ಹೆಸರಿನಲ್ಲಿ ಬರುತ್ತವೆ ಮತ್ತು HTTPS, TLS 1.2 ಅಥವಾ ಹೆಚ್ಚಿನದರಲ್ಲಿ WAF ಹೊಂದಿರುವ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ತಲುಪುತ್ತವೆ. ಇದು ಸಾರ್ವಜನಿಕವಾಗಿ ಪ್ರವೇಶಿಸಲು ಇರುವ ಏಕೈಕ ಮಾರ್ಗವಾಗಿದೆ.
- ಕನಿಷ್ಠ ಮೂರು ವರ್ಕರ್ ನೋಡ್‌ಗಳು, ಪ್ರತಿ ಲಭ್ಯತೆ ವಲಯಕ್ಕೆ ಒಂದು, ವೆಬ್ ಮತ್ತು API ರನ್, ಪೋಸ್ಟಿಂಗ್ ಎಂಜಿನ್, ASK ಆಪರೇಟರ್, ಮತ್ತು ವರ್ಕರ್‌ಗಳು ಮತ್ತು ಕೆಲಸಗಳು. ಒಂದು ನೋಡ್ ಅಥವಾ ಇಡೀ ವಲಯವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದರಿಂದ ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಸಾಮರ್ಥ್ಯ ಉಳಿಯುತ್ತದೆ.
- ನಿರ್ವಹಿಸಲಾದ ಡೇಟಾಬೇಸ್ - ಗ್ರಾಹಕರ ಆಯ್ಕೆಯ ಎಂಜಿನ್ ಮತ್ತು ಗಾತ್ರ - ಮತ್ತೊಂದು ವಲಯದಲ್ಲಿ ಸಿಂಕ್ರೊನಸ್ ಸ್ಟ್ಯಾಂಡ್‌ಬೈ ಹೊಂದಿದೆ. ವಲಯ ವೈಫಲ್ಯವು ಏನನ್ನೂ ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ: RPO ≈ 0.
- ದಾಖಲೆಗಳು ಮತ್ತು ಲಗತ್ತುಗಳು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಅಲ್ಲ, ಆವೃತ್ತಿಯ ವಸ್ತು ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ.
- NAT ಮೂಲಕ ಹೊರಹೋಗುವ ಸಂಚಾರವು ಅನುಮತಿ ಪಟ್ಟಿಗೆ ಹೋಗುತ್ತದೆ: ಬ್ಯಾಂಕ್‌ಗಳು, ತೆರಿಗೆ ಮತ್ತು ಇ-ಇನ್‌ವಾಯ್ಸಿಂಗ್, ವೇತನದಾರರ ಪಟ್ಟಿ, ಇಮೇಲ್, AI ಎಂಜಿನ್. ಬೇರೇನೂ ಇಲ್ಲ.
- ಬ್ಯಾಕಪ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಖಾತೆಯಲ್ಲಿ ಒಂದು ರೀತಿಯಲ್ಲಿ ಏರ್-ಗ್ಯಾಪ್ಡ್ ವಾಲ್ಟ್‌ಗೆ ತಳ್ಳಲಾಗುತ್ತದೆ.
ಖಾಸಗಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮತ್ತು ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಡ್ಯಾಶ್ ಮಾಡಲಾಗಿದೆ ಏಕೆಂದರೆ ಅವು ಖಾಸಗಿ ಪ್ರವೇಶವನ್ನು ಬಳಸಿದಾಗ ಮಾತ್ರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುತ್ತವೆ. HTTPS-ಮಾತ್ರ ಪ್ರವೇಶದೊಂದಿಗೆ ಅವುಗಳನ್ನು ನಿರ್ಮಿಸಲಾಗಿಲ್ಲ.
ಐದು ಗುಬ್ಬಿಗಳು, ಬೇರೇನೂ ಇಲ್ಲ
ನೋಡ್ ಗಾತ್ರ; ನೋಡ್ ಎಣಿಕೆ, ಕನಿಷ್ಠ ಮೂರು; ಡೇಟಾಬೇಸ್ ಎಂಜಿನ್ ಮತ್ತು ಗಾತ್ರ; Live DR ಪ್ರದೇಶ; ಪರಿಸರಗಳ ಸಂಖ್ಯೆ. ಉಳಿದೆಲ್ಲವೂ ಉಲ್ಲೇಖ ವಾಸ್ತುಶಿಲ್ಪ.
ಕಾನ್ಫಿಗರ್ ಮಾಡಿ, ಸಂಯೋಜಿಸಿ ಮತ್ತು ನಂತರ ಮಾತ್ರ ಕೋಡ್ ಮಾಡಿ
ಮಾನದಂಡವನ್ನು ಮೀರಿದ ಅವಶ್ಯಕತೆಯನ್ನು ಸಂರಚನೆಯ ಮೂಲಕ ಪೂರೈಸಲಾಗುತ್ತದೆ, ಅದನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನೊಂದಿಗೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ಕ್ಲಸ್ಟರ್‌ನ ಹೊರಗೆ ಚಾಲನೆಯಲ್ಲಿರುವ TRANXACT API ಗಳ ಮೂಲಕ ಏಕೀಕರಣದ ಮೂಲಕ. ಭದ್ರತೆ ಮತ್ತು ಎಂಜಿನಿಯರಿಂಗ್ ಪರಿಶೀಲನೆಯ ನಂತರ ಮಾತ್ರ ಕ್ಲಸ್ಟರ್‌ನೊಳಗಿನ ಕೋಡ್ ಅಥವಾ ಏಜೆಂಟ್ ಅನ್ನು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ; ಅನುಮೋದಿಸಿದರೆ ಅದನ್ನು ಸಹಿಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಗ್ರಾಹಕ-ಬೆಂಬಲಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ತಿರಸ್ಕರಿಸಿದರೆ ಅದು ಹೊರಗೆ ಚಲಿಸುತ್ತದೆ.
ಗ್ರಾಹಕರಿಗೆ ನೇರ ಡೇಟಾಬೇಸ್ ಪ್ರವೇಶವಿಲ್ಲ — ಇದನ್ನು ನೀಡಲಾಗಿಲ್ಲ ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ (DB_3.1.09). ವರದಿ ಮಾಡುವಿಕೆ ಮತ್ತು ಏಕೀಕರಣವು TRANXACT API ಗಳು ಮತ್ತು ಸಾರಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಅದಕ್ಕಾಗಿಯೇ BI ಉಪಕರಣವನ್ನು API ಅಥವಾ ನಿಗದಿತ ಸಾರದಿಂದ ಸಂಪರ್ಕಿಸಲಾಗುತ್ತದೆ, ಎಂದಿಗೂ ಡೇಟಾಬೇಸ್ ಲಾಗಿನ್ ಮೂಲಕ ಅಲ್ಲ.
ಕ್ಯಾಲ್ಡರ್‌ವುಡ್‌ನ BI ತಂಡವು ತಮ್ಮ ಗೋದಾಮಿಗೆ ಓದಲು-ಮಾತ್ರ ಡೇಟಾಬೇಸ್ ಬಳಕೆದಾರರನ್ನು ಕೇಳುತ್ತದೆ. ಉತ್ತರವು ಖಾಸಗಿ ಲಿಂಕ್ ಮೇಲೆ ನಿಗದಿತ ಸಾರವಾಗಿದೆ - ಅವರ ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿಯಲ್ಲಿರುವ BI ಸಾಲು "ಕೀಪ್, ನಿಗದಿತ ಸಾರ, ಖಾಸಗಿ ಲಿಂಕ್" ಆಗಿದೆ.
ಪ್ರಯತ್ನಿಸಿ ಕ್ಯಾಲ್ಡರ್‌ವುಡ್‌ನ ತಿಂಗಳಾಂತ್ಯದಲ್ಲಿ ವಲಯ 2 ರಲ್ಲಿನ ಕೆಲಸಗಾರ ನೋಡ್ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಬಳಕೆದಾರರಿಗೆ ಏನಾಗುತ್ತದೆ, ಮತ್ತು ಅದು SLA ವಿರುದ್ಧ ಎಣಿಕೆಯಾಗುತ್ತದೆಯೇ?
ಇದರ ಪಾಡ್‌ಗಳನ್ನು ವಲಯ 1 ಮತ್ತು 3 ರಲ್ಲಿರುವ ನೋಡ್‌ಗಳಿಗೆ ಮರು ನಿಗದಿಪಡಿಸಲಾಗುತ್ತದೆ, ಇವುಗಳನ್ನು ಲೋಡ್ ಅನ್ನು ಸಾಗಿಸಲು ಗಾತ್ರ ಮಾಡಲಾಗಿದೆ; ವಲಯ 2 ಪ್ರಾಥಮಿಕವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳದ ಹೊರತು ಡೇಟಾಬೇಸ್ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅದು RPO ≈ 0 ನೊಂದಿಗೆ ಸಿಂಕ್ರೊನಸ್ ಸ್ಟ್ಯಾಂಡ್‌ಬೈಗೆ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ತಿಂಗಳ ಲಭ್ಯತೆಯು ಶ್ರೇಣಿ ಗುರಿಯನ್ನು ತಪ್ಪಿಸಿಕೊಂಡರೆ ಮಾತ್ರ ಅದು SLA ವಿರುದ್ಧ ಎಣಿಕೆಯಾಗುತ್ತದೆ.