Mail.ru ಕ್ಲೌಡ್ ಸೊಲ್ಯೂಷನ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ದೋಷ-ಸಹಿಷ್ಣು ವೆಬ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹೇಗೆ ಅಳವಡಿಸಲಾಗಿದೆ

ಹಲೋ, ಹಬ್ರ್! ನಾನು ಆರ್ಟೆಮ್ ಕರಮಿಶೇವ್, ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಷನ್ ತಂಡದ ಮುಖ್ಯಸ್ಥ Mail.Ru ಕ್ಲೌಡ್ ಪರಿಹಾರಗಳು (MCS). ಕಳೆದ ವರ್ಷದಲ್ಲಿ ನಾವು ಅನೇಕ ಹೊಸ ಉತ್ಪನ್ನ ಬಿಡುಗಡೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. API ಸೇವೆಗಳು ಸುಲಭವಾಗಿ ಸ್ಕೇಲೆಬಲ್, ದೋಷ-ಸಹಿಷ್ಣು ಮತ್ತು ಬಳಕೆದಾರರ ಲೋಡ್‌ನಲ್ಲಿ ತ್ವರಿತ ಬೆಳವಣಿಗೆಗೆ ಸಿದ್ಧವಾಗಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ನಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ ಮತ್ತು ದೋಷ-ಸಹಿಷ್ಣು ವ್ಯವಸ್ಥೆಯನ್ನು ಪಡೆಯಲು ನಾವು ಯಾವ ಘಟಕ ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬೇಕೆಂದು ನಾನು ನಿಮಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಉತ್ಪನ್ನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರಿಗೆ ಇದು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಒಟ್ಟಾರೆ ದೋಷ ಸಹಿಷ್ಣುತೆಯು ಅದರ ಘಟಕಗಳ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಒಳಗೊಂಡಿದೆ. ಆದ್ದರಿಂದ ನಾವು ಅಪಾಯಗಳನ್ನು ಗುರುತಿಸಿದ ಮತ್ತು ಅವುಗಳನ್ನು ಮುಚ್ಚಿದ ಎಲ್ಲಾ ಹಂತಗಳ ಮೂಲಕ ಕ್ರಮೇಣವಾಗಿ ಹೋಗುತ್ತೇವೆ.

ಈ ಕಥೆಯ ವೀಡಿಯೊ ಆವೃತ್ತಿ, ಇದರ ಪ್ರಾಥಮಿಕ ಮೂಲವು ಅಪ್‌ಟೈಮ್ ಡೇ 4 ಕಾನ್ಫರೆನ್ಸ್‌ನಲ್ಲಿನ ವರದಿಯಾಗಿದೆ, ಇದನ್ನು ಆಯೋಜಿಸಲಾಗಿದೆ ITSumma, ನೀವು ನೋಡಬಹುದು ಅಪ್‌ಟೈಮ್ ಸಮುದಾಯ YouTube ಚಾನಲ್‌ನಲ್ಲಿ.

ಭೌತಿಕ ವಾಸ್ತುಶಿಲ್ಪದ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ

MCS ಕ್ಲೌಡ್‌ನ ಸಾರ್ವಜನಿಕ ಭಾಗವು ಈಗ ಎರಡು ಶ್ರೇಣಿ III ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ನೆಲೆಗೊಂಡಿದೆ, ಅವುಗಳ ನಡುವೆ ತನ್ನದೇ ಆದ ಡಾರ್ಕ್ ಫೈಬರ್ ಇದೆ, ವಿಭಿನ್ನ ಮಾರ್ಗಗಳ ಮೂಲಕ ಭೌತಿಕ ಮಟ್ಟದಲ್ಲಿ 200 Gbit/s ಥ್ರೋಪುಟ್‌ನೊಂದಿಗೆ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ. ಶ್ರೇಣಿ III ಭೌತಿಕ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಅಗತ್ಯವಾದ ಮಟ್ಟದ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಡಾರ್ಕ್ ಫೈಬರ್ ಅನ್ನು ಭೌತಿಕ ಮತ್ತು ತಾರ್ಕಿಕ ಮಟ್ಟಗಳಲ್ಲಿ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ. ಚಾನಲ್ ಕಾಯ್ದಿರಿಸುವಿಕೆ ಪ್ರಕ್ರಿಯೆಯು ಪುನರಾವರ್ತನೆಯಾಗಿದೆ, ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಿದವು ಮತ್ತು ನಾವು ಡೇಟಾ ಕೇಂದ್ರಗಳ ನಡುವೆ ಸಂವಹನವನ್ನು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸುತ್ತಿದ್ದೇವೆ.

ಉದಾಹರಣೆಗೆ, ಬಹಳ ಹಿಂದೆಯೇ, ಡೇಟಾ ಸೆಂಟರ್ ಒಂದರ ಸಮೀಪವಿರುವ ಬಾವಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ, ಅಗೆಯುವ ಯಂತ್ರವು ಪೈಪ್ ಅನ್ನು ಒಡೆದುಹಾಕಿತು ಮತ್ತು ಈ ಪೈಪ್ ಒಳಗೆ ಮುಖ್ಯ ಮತ್ತು ಬ್ಯಾಕಪ್ ಆಪ್ಟಿಕಲ್ ಕೇಬಲ್ ಎರಡೂ ಇತ್ತು. ಡೇಟಾ ಸೆಂಟರ್‌ನೊಂದಿಗಿನ ನಮ್ಮ ತಪ್ಪು-ಸಹಿಷ್ಣು ಸಂವಹನ ಚಾನಲ್ ಬಾವಿಯಲ್ಲಿ ಒಂದು ಹಂತದಲ್ಲಿ ದುರ್ಬಲವಾಗಿದೆ. ಅದರಂತೆ, ನಾವು ಮೂಲಭೂತ ಸೌಕರ್ಯದ ಭಾಗವನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ. ನಾವು ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಪಕ್ಕದ ಬಾವಿಯಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಆಪ್ಟಿಕ್ಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದು ಸೇರಿದಂತೆ ಹಲವಾರು ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ.

ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ನಾವು BGP ಮೂಲಕ ನಮ್ಮ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಪ್ರಸಾರ ಮಾಡುವ ಸಂವಹನ ಪೂರೈಕೆದಾರರ ಉಪಸ್ಥಿತಿಯ ಅಂಶಗಳಿವೆ. ಪ್ರತಿ ನೆಟ್‌ವರ್ಕ್ ನಿರ್ದೇಶನಕ್ಕಾಗಿ, ಅತ್ಯುತ್ತಮ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ, ಇದು ವಿಭಿನ್ನ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಉತ್ತಮ ಸಂಪರ್ಕ ಗುಣಮಟ್ಟವನ್ನು ಒದಗಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಒಬ್ಬ ಪೂರೈಕೆದಾರರ ಮೂಲಕ ಸಂವಹನವು ಕಡಿಮೆಯಾದರೆ, ಲಭ್ಯವಿರುವ ಪೂರೈಕೆದಾರರ ಮೂಲಕ ನಾವು ನಮ್ಮ ರೂಟಿಂಗ್ ಅನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡುತ್ತೇವೆ.

ಪೂರೈಕೆದಾರರು ವಿಫಲವಾದರೆ, ನಾವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮುಂದಿನದಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತೇವೆ. ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಒಂದರ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ, ಎರಡನೇ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ನಮ್ಮ ಸೇವೆಗಳ ಪ್ರತಿಬಿಂಬವನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ, ಅದು ಸಂಪೂರ್ಣ ಲೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಭೌತಿಕ ಮೂಲಸೌಕರ್ಯದ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ

ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ತಪ್ಪು ಸಹಿಷ್ಣುತೆಗಾಗಿ ನಾವು ಏನು ಬಳಸುತ್ತೇವೆ

ನಮ್ಮ ಸೇವೆಯನ್ನು ಹಲವಾರು ಓಪನ್ ಸೋರ್ಸ್ ಘಟಕಗಳ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ.

ExaBGP BGP ಆಧಾರಿತ ಡೈನಾಮಿಕ್ ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಹಲವಾರು ಕಾರ್ಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸೇವೆಯಾಗಿದೆ. ಬಳಕೆದಾರರು API ಅನ್ನು ಪ್ರವೇಶಿಸುವ ಮೂಲಕ ನಮ್ಮ ಶ್ವೇತಪಟ್ಟಿ ಮಾಡಲಾದ IP ವಿಳಾಸಗಳನ್ನು ಜಾಹೀರಾತು ಮಾಡಲು ನಾವು ಇದನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತೇವೆ.

ಹ್ಯಾಪ್ರೊಕ್ಸಿ ಹೆಚ್ಚಿನ-ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಆಗಿದ್ದು ಅದು OSI ಮಾದರಿಯ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ ತುಂಬಾ ಹೊಂದಿಕೊಳ್ಳುವ ಟ್ರಾಫಿಕ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ನಿಯಮಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಎಲ್ಲಾ ಸೇವೆಗಳ ಮುಂದೆ ಸಮತೋಲನ ಮಾಡಲು ನಾವು ಇದನ್ನು ಬಳಸುತ್ತೇವೆ: ಡೇಟಾಬೇಸ್‌ಗಳು, ಸಂದೇಶ ಬ್ರೋಕರ್‌ಗಳು, API ಸೇವೆಗಳು, ವೆಬ್ ಸೇವೆಗಳು, ನಮ್ಮ ಆಂತರಿಕ ಯೋಜನೆಗಳು - ಎಲ್ಲವೂ HAProxy ಹಿಂದೆ ಇದೆ.

API ಅಪ್ಲಿಕೇಶನ್ - ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲಾದ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್, ಅದರೊಂದಿಗೆ ಬಳಕೆದಾರನು ತನ್ನ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಅವನ ಸೇವೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತಾನೆ.

ಕೆಲಸಗಾರ ಅಪ್ಲಿಕೇಶನ್ (ಇನ್ನು ಮುಂದೆ ಸರಳವಾಗಿ ಕೆಲಸಗಾರ) - OpenStack ಸೇವೆಗಳಲ್ಲಿ, ಇದು ಮೂಲಸೌಕರ್ಯ ಡೀಮನ್ ಆಗಿದ್ದು ಅದು API ಆಜ್ಞೆಗಳನ್ನು ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಪ್ರಸಾರ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕೆಲಸಗಾರನಲ್ಲಿ ಡಿಸ್ಕ್ ರಚನೆಯು ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ API ನಲ್ಲಿ ಸೃಷ್ಟಿ ವಿನಂತಿಯು ಸಂಭವಿಸುತ್ತದೆ.

ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಓಪನ್‌ಸ್ಟ್ಯಾಕ್ ಅಪ್ಲಿಕೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್

OpenStack ಗಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾದ ಹೆಚ್ಚಿನ ಸೇವೆಗಳು ಒಂದೇ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ಸೇವೆಯು ಸಾಮಾನ್ಯವಾಗಿ 2 ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ: API ಮತ್ತು ಕೆಲಸಗಾರರು (ಬ್ಯಾಕೆಂಡ್ ಎಕ್ಸಿಕ್ಯೂಟರ್‌ಗಳು). ನಿಯಮದಂತೆ, API ಎಂಬುದು ಪೈಥಾನ್‌ನಲ್ಲಿನ WSGI ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ, ಇದನ್ನು ಸ್ವತಂತ್ರ ಪ್ರಕ್ರಿಯೆಯಾಗಿ (ಡೀಮನ್) ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ ಅಥವಾ ರೆಡಿಮೇಡ್ Nginx ಅಥವಾ Apache ವೆಬ್ ಸರ್ವರ್ ಬಳಸಿ. API ಬಳಕೆದಾರರ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕೆಲಸಗಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೆಚ್ಚಿನ ಸೂಚನೆಗಳನ್ನು ರವಾನಿಸುತ್ತದೆ. ಸಂದೇಶ ಬ್ರೋಕರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ವರ್ಗಾವಣೆ ಸಂಭವಿಸುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ RabbitMQ, ಇತರರು ಕಳಪೆಯಾಗಿ ಬೆಂಬಲಿಸುತ್ತಾರೆ. ಸಂದೇಶಗಳು ಬ್ರೋಕರ್‌ಗೆ ತಲುಪಿದಾಗ, ಅವುಗಳನ್ನು ಕೆಲಸಗಾರರು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಾರೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಾರೆ.

ಈ ಮಾದರಿಯು ವೈಫಲ್ಯದ ಪ್ರತ್ಯೇಕವಾದ ಸಾಮಾನ್ಯ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ: RabbitMQ ಮತ್ತು ಡೇಟಾಬೇಸ್. ಆದರೆ RabbitMQ ಒಂದು ಸೇವೆಯೊಳಗೆ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಪ್ರತಿ ಸೇವೆಗೆ ವೈಯಕ್ತಿಕವಾಗಿರಬಹುದು. ಆದ್ದರಿಂದ MCS ನಲ್ಲಿ ನಾವು ಈ ಸೇವೆಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಪ್ರತ್ಯೇಕಿಸುತ್ತೇವೆ; ಪ್ರತಿಯೊಂದು ಯೋಜನೆಗೆ ನಾವು ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ, ಪ್ರತ್ಯೇಕ RabbitMQ. ಈ ವಿಧಾನವು ಒಳ್ಳೆಯದು ಏಕೆಂದರೆ ಕೆಲವು ದುರ್ಬಲ ಸ್ಥಳಗಳಲ್ಲಿ ಅಪಘಾತದ ಸಂದರ್ಭದಲ್ಲಿ, ಸಂಪೂರ್ಣ ಸೇವೆಯು ಮುರಿದುಹೋಗುವುದಿಲ್ಲ, ಆದರೆ ಅದರ ಒಂದು ಭಾಗ ಮಾತ್ರ.

ಕೆಲಸಗಾರರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸಂಖ್ಯೆಯು ಅಪರಿಮಿತವಾಗಿದೆ, ಆದ್ದರಿಂದ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು API ಸುಲಭವಾಗಿ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳ ಹಿಂದೆ ಅಡ್ಡಲಾಗಿ ಅಳೆಯಬಹುದು.

API ಗಳು ಮತ್ತು ಕೆಲಸಗಾರರ ನಡುವೆ ಸಂಕೀರ್ಣ ಅನುಕ್ರಮ ಕಾರ್ಯಾಚರಣೆಗಳು ಸಂಭವಿಸಿದಾಗ ಕೆಲವು ಸೇವೆಗಳಿಗೆ ಸೇವೆಯೊಳಗೆ ಸಮನ್ವಯತೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಒಂದೇ ಸಮನ್ವಯ ಕೇಂದ್ರವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ರೆಡಿಸ್, ಮೆಮ್‌ಕಾಚೆ, ಇತ್ಯಾದಿಗಳಂತಹ ಕ್ಲಸ್ಟರ್ ಸಿಸ್ಟಮ್, ಈ ಕೆಲಸವನ್ನು ತನಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ಒಬ್ಬ ಕೆಲಸಗಾರನಿಗೆ ಹೇಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ ("ದಯವಿಟ್ಟು ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಡಿ"). ನಾವು ಇತ್ಯಾದಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ನಿಯಮದಂತೆ, ಕಾರ್ಮಿಕರು ಡೇಟಾಬೇಸ್ನೊಂದಿಗೆ ಸಕ್ರಿಯವಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ, ಅಲ್ಲಿಂದ ಮಾಹಿತಿಯನ್ನು ಬರೆಯುತ್ತಾರೆ ಮತ್ತು ಓದುತ್ತಾರೆ. ನಾವು mariadb ಅನ್ನು ಡೇಟಾಬೇಸ್ ಆಗಿ ಬಳಸುತ್ತೇವೆ, ಇದು ಮಲ್ಟಿಮಾಸ್ಟರ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿದೆ.

ಈ ಕ್ಲಾಸಿಕ್ ಸಿಂಗಲ್ ಸೇವೆಯನ್ನು ಸಾಮಾನ್ಯವಾಗಿ OpenStack ಗಾಗಿ ಸ್ವೀಕರಿಸಿದ ರೀತಿಯಲ್ಲಿ ಆಯೋಜಿಸಲಾಗಿದೆ. ಇದನ್ನು ಮುಚ್ಚಿದ ವ್ಯವಸ್ಥೆ ಎಂದು ಪರಿಗಣಿಸಬಹುದು, ಇದಕ್ಕಾಗಿ ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯ ವಿಧಾನಗಳು ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿವೆ. ಉದಾಹರಣೆಗೆ, API ದೋಷ ಸಹಿಷ್ಣುತೆಗಾಗಿ, ಅವುಗಳ ಮುಂದೆ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಹಾಕಲು ಸಾಕು. ಸ್ಕೇಲಿಂಗ್ ಕಾರ್ಮಿಕರನ್ನು ಅವರ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಸಾಧಿಸಲಾಗುತ್ತದೆ.

ಇಡೀ ಯೋಜನೆಯ ದುರ್ಬಲ ಅಂಶವೆಂದರೆ RabbitMQ ಮತ್ತು MariaDB. ಅವರ ವಾಸ್ತುಶಿಲ್ಪವು ಪ್ರತ್ಯೇಕ ಲೇಖನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ. ಈ ಲೇಖನದಲ್ಲಿ ನಾನು API ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ಬಯಸುತ್ತೇನೆ.

ಓಪನ್‌ಸ್ಟಾಕ್ ಅಪ್ಲಿಕೇಶನ್ ಆರ್ಕಿಟೆಕ್ಚರ್. ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಸಮತೋಲನ ಮತ್ತು ದೋಷ ಸಹಿಷ್ಣುತೆ

ExaBGP ಬಳಸಿಕೊಂಡು HAProxy balancer ಅನ್ನು ದೋಷ-ಸಹಿಷ್ಣುವನ್ನಾಗಿ ಮಾಡುವುದು

ನಮ್ಮ API ಗಳನ್ನು ಸ್ಕೇಲೆಬಲ್ ಮಾಡಲು, ವೇಗವಾಗಿ ಮತ್ತು ದೋಷ-ಸಹಿಷ್ಣುವಾಗಿಸಲು, ನಾವು ಅವುಗಳ ಮುಂದೆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಇರಿಸುತ್ತೇವೆ. ನಾವು HAProxy ಅನ್ನು ಆರಿಸಿದ್ದೇವೆ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಇದು ನಮ್ಮ ಕಾರ್ಯಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದೆ: ಹಲವಾರು OSI ಹಂತಗಳಲ್ಲಿ ಸಮತೋಲನ, ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್, ನಮ್ಯತೆ ಮತ್ತು ಸ್ಕೇಲೆಬಿಲಿಟಿ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಮತೋಲನ ವಿಧಾನಗಳು, ಅಧಿವೇಶನ ಕೋಷ್ಟಕಗಳಿಗೆ ಬೆಂಬಲ.

ಪರಿಹರಿಸಬೇಕಾದ ಮೊದಲ ಸಮಸ್ಯೆಯು ಬ್ಯಾಲೆನ್ಸರ್ನ ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯಾಗಿದೆ. ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸರಳವಾಗಿ ಸ್ಥಾಪಿಸುವುದು ವೈಫಲ್ಯದ ಬಿಂದುವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ: ಬ್ಯಾಲೆನ್ಸರ್ ಒಡೆಯುತ್ತದೆ ಮತ್ತು ಸೇವೆಯು ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ. ಇದು ಸಂಭವಿಸುವುದನ್ನು ತಡೆಯಲು, ನಾವು ExaBGP ಜೊತೆಗೆ HAProxy ಅನ್ನು ಬಳಸಿದ್ದೇವೆ.

ಸೇವೆಯ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲು ಕಾರ್ಯವಿಧಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ExaBGP ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. HAProxy ನ ಕಾರ್ಯವನ್ನು ಪರಿಶೀಲಿಸಲು ನಾವು ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿದ್ದೇವೆ ಮತ್ತು ಸಮಸ್ಯೆಗಳಿದ್ದಲ್ಲಿ, BGP ಯಿಂದ HAProxy ಸೇವೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ.

ExaBGP+HAProxy ಯೋಜನೆ

1. ನಾವು ಮೂರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಅಗತ್ಯ ಸಾಫ್ಟ್‌ವೇರ್, ExaBGP ಮತ್ತು HAProxy ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ.
2. ನಾವು ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಲೂಪ್‌ಬ್ಯಾಕ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ.
3. ಎಲ್ಲಾ ಮೂರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಾವು ಈ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಒಂದೇ ಬಿಳಿ IP ವಿಳಾಸವನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ.
4. ಬಿಳಿ IP ವಿಳಾಸವನ್ನು ExaBGP ಮೂಲಕ ಇಂಟರ್ನೆಟ್‌ಗೆ ಜಾಹೀರಾತು ಮಾಡಲಾಗುತ್ತದೆ.

ಎಲ್ಲಾ ಮೂರು ಸರ್ವರ್‌ಗಳಿಂದ ಒಂದೇ IP ವಿಳಾಸವನ್ನು ಜಾಹೀರಾತು ಮಾಡುವ ಮೂಲಕ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಸಾಧಿಸಲಾಗುತ್ತದೆ. ನೆಟ್‌ವರ್ಕ್ ದೃಷ್ಟಿಕೋನದಿಂದ, ಒಂದೇ ವಿಳಾಸವನ್ನು ಮೂರು ವಿಭಿನ್ನ ಮುಂದಿನ ಹಾಪ್‌ಗಳಿಂದ ಪ್ರವೇಶಿಸಬಹುದು. ರೂಟರ್ ಮೂರು ಒಂದೇ ಮಾರ್ಗಗಳನ್ನು ನೋಡುತ್ತದೆ, ತನ್ನದೇ ಆದ ಮೆಟ್ರಿಕ್ ಆಧಾರದ ಮೇಲೆ ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ (ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಅದೇ ಆಯ್ಕೆಯಾಗಿದೆ), ಮತ್ತು ಸಂಚಾರವು ಸರ್ವರ್ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮಾತ್ರ ಹೋಗುತ್ತದೆ.

HAProxy ಅಥವಾ ಸರ್ವರ್ ವೈಫಲ್ಯದ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿದ್ದಲ್ಲಿ, ExaBGP ಮಾರ್ಗವನ್ನು ಘೋಷಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ಸಂಚಾರವು ಸರಾಗವಾಗಿ ಮತ್ತೊಂದು ಸರ್ವರ್‌ಗೆ ಬದಲಾಗುತ್ತದೆ.

ಹೀಗಾಗಿ, ನಾವು ಬ್ಯಾಲೆನ್ಸರ್ನ ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ.

HAProxy ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳ ತಪ್ಪು ಸಹಿಷ್ಣುತೆ

ಯೋಜನೆಯು ಅಪೂರ್ಣವಾಗಿದೆ: ನಾವು HAProxy ಅನ್ನು ಹೇಗೆ ಕಾಯ್ದಿರಿಸಬೇಕೆಂದು ಕಲಿತಿದ್ದೇವೆ, ಆದರೆ ಸೇವೆಗಳಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಹೇಗೆ ವಿತರಿಸಬೇಕೆಂದು ಕಲಿಯಲಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಈ ಯೋಜನೆಯನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ವಿಸ್ತರಿಸಿದ್ದೇವೆ: ನಾವು ಹಲವಾರು ಬಿಳಿ IP ವಿಳಾಸಗಳ ನಡುವೆ ಸಮತೋಲನಕ್ಕೆ ತೆರಳಿದ್ದೇವೆ.

DNS ಜೊತೆಗೆ BGP ಆಧರಿಸಿ ಸಮತೋಲನ

ನಮ್ಮ HAProxy ಗಾಗಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಸಮಸ್ಯೆಯು ಬಗೆಹರಿಯದೆ ಉಳಿದಿದೆ. ಆದಾಗ್ಯೂ, ನಾವು ಇಲ್ಲಿ ಮಾಡಿದಂತೆ ಅದನ್ನು ಸರಳವಾಗಿ ಪರಿಹರಿಸಬಹುದು.

ಮೂರು ಸರ್ವರ್‌ಗಳನ್ನು ಸಮತೋಲನಗೊಳಿಸಲು ನಿಮಗೆ 3 ಬಿಳಿ IP ವಿಳಾಸಗಳು ಮತ್ತು ಉತ್ತಮ ಹಳೆಯ DNS ಅಗತ್ಯವಿರುತ್ತದೆ. ಈ ಪ್ರತಿಯೊಂದು ವಿಳಾಸಗಳನ್ನು ಪ್ರತಿ HAProxy ನ ಲೂಪ್‌ಬ್ಯಾಕ್ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ಗೆ ಜಾಹೀರಾತು ಮಾಡಲಾಗುತ್ತದೆ.

ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ, ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿರ್ವಹಿಸಲು, ಸೇವಾ ಡೈರೆಕ್ಟರಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇದು ನಿರ್ದಿಷ್ಟ ಸೇವೆಯ ಅಂತಿಮ ಬಿಂದು API ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಈ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ನಾವು ಡೊಮೇನ್ ಹೆಸರನ್ನು ನೋಂದಾಯಿಸುತ್ತೇವೆ - public.infra.mail.ru, ಇದು ಮೂರು ವಿಭಿನ್ನ IP ವಿಳಾಸಗಳಿಂದ DNS ಮೂಲಕ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು DNS ಮೂಲಕ ಮೂರು ವಿಳಾಸಗಳ ನಡುವೆ ಲೋಡ್ ವಿತರಣೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ.

ಆದರೆ ಬಿಳಿ IP ವಿಳಾಸಗಳನ್ನು ಪ್ರಕಟಿಸುವಾಗ ನಾವು ಸರ್ವರ್ ಆಯ್ಕೆಯ ಆದ್ಯತೆಗಳನ್ನು ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲವಾದ್ದರಿಂದ, ಇದು ಇನ್ನೂ ಸಮತೋಲನಗೊಳ್ಳುತ್ತಿಲ್ಲ. ವಿಶಿಷ್ಟವಾಗಿ, IP ವಿಳಾಸದ ಹಿರಿತನದ ಆಧಾರದ ಮೇಲೆ ಕೇವಲ ಒಂದು ಸರ್ವರ್ ಅನ್ನು ಮಾತ್ರ ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು BGP ಯಲ್ಲಿ ಯಾವುದೇ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದ ಕಾರಣ ಉಳಿದ ಎರಡು ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತದೆ.

ನಾವು ವಿವಿಧ ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ ExaBGP ಮೂಲಕ ಮಾರ್ಗಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಪ್ರತಿ ಬ್ಯಾಲೆನ್ಸರ್ ಎಲ್ಲಾ ಮೂರು ಬಿಳಿ IP ವಿಳಾಸಗಳನ್ನು ಜಾಹೀರಾತು ಮಾಡುತ್ತದೆ, ಆದರೆ ಅವುಗಳಲ್ಲಿ ಒಂದು, ಈ ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಮುಖ್ಯವಾದದ್ದು, ಕನಿಷ್ಠ ಮೆಟ್ರಿಕ್‌ನೊಂದಿಗೆ ಜಾಹೀರಾತು ಮಾಡಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಎಲ್ಲಾ ಮೂರು ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವಾಗ, ಮೊದಲ IP ವಿಳಾಸಕ್ಕೆ ಕರೆಗಳು ಮೊದಲ ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಹೋಗುತ್ತವೆ, ಎರಡನೆಯದಕ್ಕೆ ಎರಡನೆಯದಕ್ಕೆ ಕರೆಗಳು ಮತ್ತು ಮೂರನೆಯಿಂದ ಮೂರನೆಯದಕ್ಕೆ ಕರೆಗಳು.

ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು ಬಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ? ಯಾವುದೇ ಬ್ಯಾಲೆನ್ಸರ್ ವಿಫಲವಾದರೆ, ಅದರ ಮುಖ್ಯ ವಿಳಾಸವನ್ನು ಇತರ ಎರಡರಿಂದ ಇನ್ನೂ ಜಾಹೀರಾತು ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ಸಂಚಾರವನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಹೀಗಾಗಿ, ನಾವು ಬಳಕೆದಾರರಿಗೆ DNS ಮೂಲಕ ಹಲವಾರು IP ವಿಳಾಸಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ನೀಡುತ್ತೇವೆ. DNS ಮತ್ತು ವಿಭಿನ್ನ ಮೆಟ್ರಿಕ್‌ಗಳ ಮೂಲಕ ಸಮತೋಲನ ಮಾಡುವ ಮೂಲಕ, ನಾವು ಎಲ್ಲಾ ಮೂರು ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಾದ್ಯಂತ ಲೋಡ್‌ನ ಸಮಾನ ವಿತರಣೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನಾವು ತಪ್ಪು ಸಹಿಷ್ಣುತೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ.

DNS + BGP ಆಧರಿಸಿ HAProxy ಅನ್ನು ಸಮತೋಲನಗೊಳಿಸುವುದು

ExaBGP ಮತ್ತು HAProxy ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆ

ಆದ್ದರಿಂದ, ಮಾರ್ಗಗಳ ಪ್ರಕಟಣೆಯನ್ನು ನಿಲ್ಲಿಸುವ ಆಧಾರದ ಮೇಲೆ ಸರ್ವರ್ ಹೊರಹೋಗುವ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ. ಆದರೆ HAProxy ಸರ್ವರ್ ವೈಫಲ್ಯವನ್ನು ಹೊರತುಪಡಿಸಿ ಇತರ ಕಾರಣಗಳಿಗಾಗಿ ಮುಚ್ಚಬಹುದು: ಆಡಳಿತ ದೋಷಗಳು, ಸೇವೆಯೊಳಗಿನ ವೈಫಲ್ಯಗಳು. ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಮುರಿದ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲು ನಾವು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ನಮಗೆ ಬೇರೆ ಕಾರ್ಯವಿಧಾನದ ಅಗತ್ಯವಿದೆ.

ಆದ್ದರಿಂದ, ಹಿಂದಿನ ಯೋಜನೆಯನ್ನು ವಿಸ್ತರಿಸಿ, ನಾವು ExaBGP ಮತ್ತು HAProxy ನಡುವೆ ಹೃದಯ ಬಡಿತವನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ. ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲು ExaBGP ಕಸ್ಟಮ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬಳಸುವಾಗ ಇದು ExaBGP ಮತ್ತು HAProxy ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಸಾಫ್ಟ್‌ವೇರ್ ಅನುಷ್ಠಾನವಾಗಿದೆ.

ಇದನ್ನು ಮಾಡಲು, ನೀವು ExaBGP ಸಂರಚನೆಯಲ್ಲಿ ಆರೋಗ್ಯ ಪರೀಕ್ಷಕವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಇದು HAProxy ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು HAProxy ನಲ್ಲಿ ಆರೋಗ್ಯ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ExaBGP ಕಡೆಯಿಂದ ನಾವು ಸರಳ GET ವಿನಂತಿಯೊಂದಿಗೆ ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಪ್ರಕಟಣೆಯು ಸಂಭವಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದರೆ, HAProxy ಹೆಚ್ಚಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ಜಾಹೀರಾತು ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ.

HAProxy ಆರೋಗ್ಯ ತಪಾಸಣೆ

HAProxy ಪೀರ್ಸ್: ಅಧಿವೇಶನ ಸಿಂಕ್ರೊನೈಸೇಶನ್

ಸೆಷನ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವುದು ಮುಂದಿನ ಕೆಲಸ. ವಿತರಿಸಿದ ಬ್ಯಾಲೆನ್ಸರ್ಗಳ ಮೂಲಕ ಕೆಲಸ ಮಾಡುವಾಗ, ಕ್ಲೈಂಟ್ ಸೆಷನ್ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯ ಸಂಗ್ರಹವನ್ನು ಸಂಘಟಿಸಲು ಕಷ್ಟವಾಗುತ್ತದೆ. ಆದರೆ ಪೀರ್ಸ್ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಕಾರಣದಿಂದಾಗಿ ಇದನ್ನು ಮಾಡಬಹುದಾದ ಕೆಲವು ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಲ್ಲಿ HAProxy ಒಂದಾಗಿದೆ - ವಿಭಿನ್ನ HAProxy ಪ್ರಕ್ರಿಯೆಗಳ ನಡುವೆ ಅಧಿವೇಶನ ಕೋಷ್ಟಕಗಳನ್ನು ವರ್ಗಾಯಿಸುವ ಸಾಮರ್ಥ್ಯ.

ವಿಭಿನ್ನ ಸಮತೋಲನ ವಿಧಾನಗಳಿವೆ: ಸರಳವಾದವುಗಳು ರೌಂಡ್-ರಾಬಿನ್, ಮತ್ತು ವಿಸ್ತರಿಸಲಾಗಿದೆ, ಕ್ಲೈಂಟ್‌ನ ಅಧಿವೇಶನವನ್ನು ನೆನಪಿಸಿಕೊಂಡಾಗ, ಮತ್ತು ಪ್ರತಿ ಬಾರಿಯೂ ಅವನು ಮೊದಲಿನಂತೆಯೇ ಅದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತಾನೆ. ನಾವು ಎರಡನೇ ಆಯ್ಕೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬಯಸಿದ್ದೇವೆ.

HAProxy ಈ ಕಾರ್ಯವಿಧಾನದ ಕ್ಲೈಂಟ್ ಸೆಷನ್‌ಗಳನ್ನು ಉಳಿಸಲು ಸ್ಟಿಕ್-ಟೇಬಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಅವರು ಕ್ಲೈಂಟ್‌ನ ಮೂಲ IP ವಿಳಾಸ, ಆಯ್ದ ಗುರಿ ವಿಳಾಸ (ಬ್ಯಾಕೆಂಡ್) ಮತ್ತು ಕೆಲವು ಸೇವಾ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸುತ್ತಾರೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಮೂಲ-ಐಪಿ + ಡೆಸ್ಟಿನೇಶನ್-ಐಪಿ ಜೋಡಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಸ್ಟಿಕ್ ಟೇಬಲ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇದು ಮತ್ತೊಂದು ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಬದಲಾಯಿಸುವಾಗ ಬಳಕೆದಾರ ಸೆಶನ್ ಸಂದರ್ಭವನ್ನು ವರ್ಗಾಯಿಸಲು ಸಾಧ್ಯವಾಗದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ರೌಂಡ್‌ರಾಬಿನ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮೋಡ್‌ನಲ್ಲಿ.

ವಿವಿಧ HAProxy ಪ್ರಕ್ರಿಯೆಗಳ ನಡುವೆ ಚಲಿಸಲು ಸ್ಟಿಕ್ ಟೇಬಲ್ ಅನ್ನು ಕಲಿಸಿದರೆ (ಸಮತೋಲನ ಸಂಭವಿಸುವ ನಡುವೆ), ನಮ್ಮ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಸ್ಟಿಕ್ ಟೇಬಲ್‌ಗಳ ಒಂದು ಪೂಲ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು ವಿಫಲವಾದಲ್ಲಿ ಕ್ಲೈಂಟ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಮನಬಂದಂತೆ ಬದಲಾಯಿಸಲು ಇದು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ; ಕ್ಲೈಂಟ್ ಸೆಷನ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸವು ಹಿಂದೆ ಆಯ್ಕೆ ಮಾಡಿದ ಅದೇ ಬ್ಯಾಕೆಂಡ್‌ಗಳಲ್ಲಿ ಮುಂದುವರಿಯುತ್ತದೆ.

ಸರಿಯಾದ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ, ಅಧಿವೇಶನವನ್ನು ಸ್ಥಾಪಿಸಿದ ಬ್ಯಾಲೆನ್ಸರ್ನ ಮೂಲ IP ವಿಳಾಸದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬೇಕು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಲೂಪ್‌ಬ್ಯಾಕ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಡೈನಾಮಿಕ್ ವಿಳಾಸವಾಗಿದೆ.

ಗೆಳೆಯರ ಸರಿಯಾದ ಕೆಲಸವನ್ನು ಕೆಲವು ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಮಾತ್ರ ಸಾಧಿಸಲಾಗುತ್ತದೆ. ಅಂದರೆ, TCP ಅವಧಿಯು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿರಬೇಕು ಅಥವಾ ಸ್ವಿಚಿಂಗ್ ಸಾಕಷ್ಟು ವೇಗವಾಗಿರಬೇಕು ಆದ್ದರಿಂದ TCP ಸೆಶನ್ ಅಂತ್ಯಗೊಳ್ಳಲು ಸಮಯವನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಇದು ತಡೆರಹಿತ ಸ್ವಿಚಿಂಗ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

IaaS ನಲ್ಲಿ ನಾವು ಅದೇ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಿಕೊಂಡು ನಿರ್ಮಿಸಿದ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈ OpenStack ಗಾಗಿ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸೇವೆಯಾಗಿ ಲೋಡ್ ಮಾಡಿ, ಇದನ್ನು ಆಕ್ಟೇವಿಯಾ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಎರಡು HAProxy ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಆಧರಿಸಿದೆ ಮತ್ತು ಆರಂಭದಲ್ಲಿ ಗೆಳೆಯರಿಗೆ ಬೆಂಬಲವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಅವರು ಈ ಸೇವೆಯಲ್ಲಿ ತಮ್ಮನ್ನು ತಾವು ಅತ್ಯುತ್ತಮವೆಂದು ಸಾಬೀತುಪಡಿಸಿದ್ದಾರೆ.

ಚಿತ್ರವು ಮೂರು HAProxy ನಿದರ್ಶನಗಳ ನಡುವಿನ ಪೀರ್ ಕೋಷ್ಟಕಗಳ ಚಲನೆಯನ್ನು ಕ್ರಮಬದ್ಧವಾಗಿ ತೋರಿಸುತ್ತದೆ, ಇದನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಎಂಬುದರ ಕುರಿತು ಒಂದು ಸಂರಚನೆಯನ್ನು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ:

HAProxy ಪೀರ್ಸ್ (ಸೆಶನ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್)

ನೀವು ಅದೇ ಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದರೆ, ಅದರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಪರೀಕ್ಷಿಸಬೇಕು. ಇದು 100% ಸಮಯ ಅದೇ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು ಸತ್ಯವಲ್ಲ. ಆದರೆ ಕ್ಲೈಂಟ್‌ನ ಮೂಲ IP ಅನ್ನು ನೀವು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕಾದಾಗ ಕನಿಷ್ಠ ನೀವು ಸ್ಟಿಕ್ ಟೇಬಲ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ.

ಒಂದೇ ಕ್ಲೈಂಟ್‌ನಿಂದ ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುವುದು

ನಮ್ಮ API ಗಳು ಸೇರಿದಂತೆ ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರುವ ಯಾವುದೇ ಸೇವೆಗಳು, ವಿನಂತಿಗಳ ಹಠಾತ್‌ಗೆ ಒಳಪಡಬಹುದು. ಬಳಕೆದಾರರ ದೋಷಗಳಿಂದ ಉದ್ದೇಶಿತ ದಾಳಿಗಳವರೆಗೆ ಅವುಗಳ ಕಾರಣಗಳು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿರಬಹುದು. ನಾವು ನಿಯತಕಾಲಿಕವಾಗಿ IP ವಿಳಾಸಗಳಿಂದ DDoSed ಮಾಡಲಾಗುತ್ತದೆ. ಗ್ರಾಹಕರು ಸಾಮಾನ್ಯವಾಗಿ ತಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಲ್ಲಿ ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ನಮಗೆ ಮಿನಿ-ಡಿಡಿಒಎಸ್‌ಗಳನ್ನು ನೀಡುತ್ತಾರೆ.

ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ, ಹೆಚ್ಚುವರಿ ರಕ್ಷಣೆಯನ್ನು ಒದಗಿಸಬೇಕು. API ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುವುದು ಮತ್ತು ದುರುದ್ದೇಶಪೂರಿತ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು CPU ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡದಿರುವುದು ಸ್ಪಷ್ಟ ಪರಿಹಾರವಾಗಿದೆ.

ಅಂತಹ ನಿರ್ಬಂಧಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ನಾವು ಅದೇ ಸ್ಟಿಕ್ ಟೇಬಲ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು HAProxy ಆಧಾರದ ಮೇಲೆ ಆಯೋಜಿಸಲಾದ ದರ ಮಿತಿಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸುವುದು ತುಂಬಾ ಸರಳವಾಗಿದೆ ಮತ್ತು API ಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯಿಂದ ಬಳಕೆದಾರರನ್ನು ಮಿತಿಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಅಲ್ಗಾರಿದಮ್ ವಿನಂತಿಗಳನ್ನು ಮಾಡಲಾದ ಮೂಲ IP ಅನ್ನು ನೆನಪಿಸುತ್ತದೆ ಮತ್ತು ಒಬ್ಬ ಬಳಕೆದಾರರಿಂದ ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ. ಸಹಜವಾಗಿ, ನಾವು ಪ್ರತಿ ಸೇವೆಗೆ ಸರಾಸರಿ API ಲೋಡ್ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಲೆಕ್ಕ ಹಾಕಿದ್ದೇವೆ ಮತ್ತು ಈ ಮೌಲ್ಯದ ≈ 10 ಪಟ್ಟು ಮಿತಿಯನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ. ನಾವು ಪರಿಸ್ಥಿತಿಯನ್ನು ನಿಕಟವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ ಮತ್ತು ನಮ್ಮ ಬೆರಳನ್ನು ನಾಡಿಗೆ ಇಡುತ್ತೇವೆ.

ಇದು ಆಚರಣೆಯಲ್ಲಿ ಹೇಗೆ ಕಾಣುತ್ತದೆ? ನಮ್ಮ ಆಟೋಸ್ಕೇಲಿಂಗ್ API ಗಳನ್ನು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಬಳಸುವ ಗ್ರಾಹಕರನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಅವರು ಬೆಳಿಗ್ಗೆ ಸರಿಸುಮಾರು ಇನ್ನೂರರಿಂದ ಮುನ್ನೂರು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ ಮತ್ತು ಸಂಜೆ ಅವುಗಳನ್ನು ಅಳಿಸುತ್ತಾರೆ. OpenStack ಗಾಗಿ, PaaS ಸೇವೆಗಳೊಂದಿಗೆ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ರಚಿಸಲು ಕನಿಷ್ಠ 1000 API ವಿನಂತಿಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಸೇವೆಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆಯು API ಮೂಲಕವೂ ಸಂಭವಿಸುತ್ತದೆ.

ಕಾರ್ಯಗಳ ಅಂತಹ ವರ್ಗಾವಣೆಯು ಸಾಕಷ್ಟು ದೊಡ್ಡ ಹೊರೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ನಾವು ಈ ಹೊರೆಯನ್ನು ನಿರ್ಣಯಿಸಿದ್ದೇವೆ, ದೈನಂದಿನ ಶಿಖರಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ, ಅವುಗಳನ್ನು ಹತ್ತು ಪಟ್ಟು ಹೆಚ್ಚಿಸಿದ್ದೇವೆ ಮತ್ತು ಇದು ನಮ್ಮ ದರ ಮಿತಿಯಾಗಿದೆ. ನಾವು ನಮ್ಮ ಬೆರಳನ್ನು ನಾಡಿಗೆ ಇಡುತ್ತೇವೆ. ನಾವು ರನ್ ಮಾಡಬಹುದಾದ ಯಾವುದೇ CGA ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಾ ಎಂದು ನೋಡಲು ನಮ್ಮನ್ನು ನೋಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಬಾಟ್‌ಗಳು ಮತ್ತು ಸ್ಕ್ಯಾನರ್‌ಗಳನ್ನು ನಾವು ಆಗಾಗ್ಗೆ ನೋಡುತ್ತೇವೆ, ನಾವು ಅವುಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ಕತ್ತರಿಸುತ್ತಿದ್ದೇವೆ.

ಬಳಕೆದಾರರು ಗಮನಿಸದೆ ನಿಮ್ಮ ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ಹೇಗೆ ನವೀಕರಿಸುವುದು

ಕೋಡ್ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಗಳ ಮಟ್ಟದಲ್ಲಿ ನಾವು ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಅಳವಡಿಸುತ್ತೇವೆ. ರೋಲ್‌ಔಟ್‌ಗಳ ಸಮಯದಲ್ಲಿ ಗ್ಲಿಚ್‌ಗಳು ಇರಬಹುದು, ಆದರೆ ಸೇವೆಯ ಲಭ್ಯತೆಯ ಮೇಲೆ ಅವುಗಳ ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

ನಾವು ನಿರಂತರವಾಗಿ ನಮ್ಮ ಸೇವೆಗಳನ್ನು ನವೀಕರಿಸುತ್ತೇವೆ ಮತ್ತು ಬಳಕೆದಾರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. HAProxy ನ ನಿರ್ವಹಣಾ ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ನಮ್ಮ ಸೇವೆಗಳಲ್ಲಿ ಗ್ರೇಸ್‌ಫುಲ್ ಶಟ್‌ಡೌನ್ ಅನುಷ್ಠಾನವನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ.

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ಬ್ಯಾಲೆನ್ಸರ್ ನಿಯಂತ್ರಣ ಮತ್ತು ಸೇವೆಗಳ "ಸರಿಯಾದ" ಸ್ಥಗಿತವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿತ್ತು:

• HAProxy ಸಂದರ್ಭದಲ್ಲಿ, ನಿಯಂತ್ರಣವನ್ನು ಅಂಕಿಅಂಶಗಳ ಫೈಲ್ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ, ಇದು ಮೂಲಭೂತವಾಗಿ ಸಾಕೆಟ್ ಆಗಿದೆ ಮತ್ತು HAProxy ಸಂರಚನೆಯಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ನೀವು stdio ಮೂಲಕ ಇದಕ್ಕೆ ಆಜ್ಞೆಗಳನ್ನು ಕಳುಹಿಸಬಹುದು. ಆದರೆ ನಮ್ಮ ಮುಖ್ಯ ಕಾನ್ಫಿಗರೇಶನ್ ನಿಯಂತ್ರಣ ಸಾಧನವು ಅನ್ಸಿಬಲ್ ಆಗಿದೆ, ಆದ್ದರಿಂದ ಇದು HAProxy ಅನ್ನು ನಿರ್ವಹಿಸಲು ಅಂತರ್ನಿರ್ಮಿತ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಹೊಂದಿದೆ. ನಾವು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತೇವೆ.
• ನಮ್ಮ ಹೆಚ್ಚಿನ API ಮತ್ತು ಇಂಜಿನ್ ಸೇವೆಗಳು ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ: ಸ್ಥಗಿತಗೊಳಿಸುವಾಗ, ಪ್ರಸ್ತುತ ಕಾರ್ಯವು ಪೂರ್ಣಗೊಳ್ಳಲು ಅವರು ಕಾಯುತ್ತಾರೆ, ಅದು http ವಿನಂತಿ ಅಥವಾ ಕೆಲವು ಸೇವಾ ಕಾರ್ಯವಾಗಿರಬಹುದು. ಕೆಲಸಗಾರನ ವಿಷಯದಲ್ಲೂ ಅದೇ ಸಂಭವಿಸುತ್ತದೆ. ಅದು ತಾನು ಮಾಡುತ್ತಿರುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ತಿಳಿದಿರುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳಿಸಿದಾಗ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಈ ಎರಡು ಅಂಶಗಳಿಗೆ ಧನ್ಯವಾದಗಳು, ನಮ್ಮ ನಿಯೋಜನೆಗಾಗಿ ಸುರಕ್ಷಿತ ಅಲ್ಗಾರಿದಮ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.

1. ಡೆವಲಪರ್ ಕೋಡ್‌ನ ಹೊಸ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಜೋಡಿಸುತ್ತಾರೆ (ನಮಗೆ ಇದು RPM ಆಗಿದೆ), ಅದನ್ನು ದೇವ್ ಪರಿಸರದಲ್ಲಿ ಪರೀಕ್ಷಿಸುತ್ತದೆ, ಅದನ್ನು ಹಂತದಲ್ಲಿ ಪರೀಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಸ್ಟೇಜ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಬಿಡುತ್ತದೆ.
2. ಡೆವಲಪರ್ "ಕಲಾಕೃತಿಗಳ" ಅತ್ಯಂತ ವಿವರವಾದ ವಿವರಣೆಯೊಂದಿಗೆ ನಿಯೋಜನೆಗಾಗಿ ಕಾರ್ಯವನ್ನು ಹೊಂದಿಸುತ್ತದೆ: ಹೊಸ ಪ್ಯಾಕೇಜ್‌ನ ಆವೃತ್ತಿ, ಹೊಸ ಕ್ರಿಯಾತ್ಮಕತೆಯ ವಿವರಣೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ನಿಯೋಜನೆಯ ಕುರಿತು ಇತರ ವಿವರಗಳು.
3. ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ನವೀಕರಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಅನ್ಸಿಬಲ್ ಪ್ಲೇಬುಕ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಅದು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡುತ್ತದೆ:
   • ಸ್ಟೇಜ್ ರೆಪೊಸಿಟರಿಯಿಂದ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಉತ್ಪನ್ನ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಪ್ಯಾಕೇಜ್‌ನ ಆವೃತ್ತಿಯನ್ನು ನವೀಕರಿಸಲು ಅದನ್ನು ಬಳಸುತ್ತದೆ.
   • ನವೀಕರಿಸಿದ ಸೇವೆಯ ಬ್ಯಾಕೆಂಡ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಕಂಪೈಲ್ ಮಾಡುತ್ತದೆ.
   • HAProxy ನಲ್ಲಿ ನವೀಕರಿಸಬೇಕಾದ ಮೊದಲ ಸೇವೆಯನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಪ್ರಕ್ರಿಯೆಗಳು ರನ್ ಆಗುವವರೆಗೆ ಕಾಯುತ್ತದೆ. ಆಕರ್ಷಕವಾದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಗೆ ಧನ್ಯವಾದಗಳು, ಎಲ್ಲಾ ಪ್ರಸ್ತುತ ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತವೆ ಎಂದು ನಮಗೆ ವಿಶ್ವಾಸವಿದೆ.
   • API ಮತ್ತು ಕೆಲಸಗಾರರನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಲ್ಲಿಸಿದ ನಂತರ ಮತ್ತು HAProxy ಅನ್ನು ಆಫ್ ಮಾಡಿದ ನಂತರ, ಕೋಡ್ ಅನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ.
   • ಅನ್ಸಿಬಲ್ ಸೇವೆಗಳನ್ನು ನಡೆಸುತ್ತದೆ.
   • ಪ್ರತಿ ಸೇವೆಗೆ, ಕೆಲವು "ಹಿಡಿಕೆಗಳು" ಎಳೆಯಲಾಗುತ್ತದೆ, ಇದು ಹಲವಾರು ಪೂರ್ವ-ನಿರ್ಧರಿತ ಪ್ರಮುಖ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಘಟಕ ಪರೀಕ್ಷೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಹೊಸ ಕೋಡ್‌ನ ಮೂಲಭೂತ ಪರಿಶೀಲನೆ ನಡೆಯುತ್ತದೆ.
   • ಹಿಂದಿನ ಹಂತದಲ್ಲಿ ಯಾವುದೇ ದೋಷಗಳು ಕಂಡುಬಂದಿಲ್ಲವಾದರೆ, ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ.
   • ಮುಂದಿನ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಹೋಗೋಣ.
4. ಎಲ್ಲಾ ಬ್ಯಾಕೆಂಡ್‌ಗಳನ್ನು ನವೀಕರಿಸಿದ ನಂತರ, ಕ್ರಿಯಾತ್ಮಕ ಪರೀಕ್ಷೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ. ಅವರು ಕಾಣೆಯಾಗಿದ್ದರೆ, ಡೆವಲಪರ್ ಅವರು ರಚಿಸಿದ ಯಾವುದೇ ಹೊಸ ಕಾರ್ಯವನ್ನು ನೋಡುತ್ತಾರೆ.

ಇದು ನಿಯೋಜನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ.

ಸೇವಾ ನವೀಕರಣ ಚಕ್ರ

ನಾವು ಒಂದು ನಿಯಮವನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಈ ಯೋಜನೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಯುದ್ಧದಲ್ಲಿ ನಾವು ಹಳೆಯ ಮತ್ತು ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತೇವೆ. ಮುಂಚಿತವಾಗಿ, ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಹಂತದಲ್ಲಿ, ಸೇವಾ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಬದಲಾವಣೆಗಳಿದ್ದರೂ ಸಹ, ಅವರು ಹಿಂದಿನ ಕೋಡ್ ಅನ್ನು ಮುರಿಯುವುದಿಲ್ಲ ಎಂದು ಹಾಕಲಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಕೋಡ್ ಬೇಸ್ ಅನ್ನು ಕ್ರಮೇಣ ನವೀಕರಿಸಲಾಗುತ್ತದೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ದೋಷ-ಸಹಿಷ್ಣು ವೆಬ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕುರಿತು ನನ್ನ ಸ್ವಂತ ಆಲೋಚನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಾ, ನಾನು ಮತ್ತೊಮ್ಮೆ ಅದರ ಪ್ರಮುಖ ಅಂಶಗಳನ್ನು ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ:

• ದೈಹಿಕ ದೋಷ ಸಹಿಷ್ಣುತೆ;
• ನೆಟ್ವರ್ಕ್ ದೋಷ ಸಹಿಷ್ಣುತೆ (ಸಮತೋಲನಕಾರರು, ಬಿಜಿಪಿ);
• ಬಳಸಿದ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ತಪ್ಪು ಸಹಿಷ್ಣುತೆ.

ಎಲ್ಲರಿಗೂ ಸ್ಥಿರವಾದ ಅಪ್ಟೈಮ್!

ಮೂಲ: www.habr.com