Yandex.Cloud ನಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್

ಹಲೋ, ನಾನು ಸೆರ್ಗೆ ಎಲಾಂಟ್ಸೆವ್, ನಾನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇನೆ ನೆಟ್ವರ್ಕ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ Yandex.Cloud ನಲ್ಲಿ. ಹಿಂದೆ, ನಾನು ಯಾಂಡೆಕ್ಸ್ ಪೋರ್ಟಲ್‌ಗಾಗಿ ಎಲ್ 7 ಬ್ಯಾಲೆನ್ಸರ್‌ನ ಅಭಿವೃದ್ಧಿಯನ್ನು ಮುನ್ನಡೆಸಿದೆ - ನಾನು ಏನು ಮಾಡಿದರೂ ಅದು ಬ್ಯಾಲೆನ್ಸರ್ ಆಗಿ ಹೊರಹೊಮ್ಮುತ್ತದೆ ಎಂದು ಸಹೋದ್ಯೋಗಿಗಳು ತಮಾಷೆ ಮಾಡುತ್ತಾರೆ. ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು, ಈ ಗುರಿಯನ್ನು ಸಾಧಿಸಲು ನಾವು ಸೂಕ್ತವಾದ ಸಾಧನವಾಗಿ ಏನನ್ನು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಈ ಉಪಕರಣವನ್ನು ನಿರ್ಮಿಸಲು ನಾವು ಹೇಗೆ ಚಲಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ನಾನು Habr ಓದುಗರಿಗೆ ಹೇಳುತ್ತೇನೆ.

ಮೊದಲಿಗೆ, ಕೆಲವು ನಿಯಮಗಳನ್ನು ಪರಿಚಯಿಸೋಣ:

• ವಿಐಪಿ (ವರ್ಚುವಲ್ ಐಪಿ) - ಬ್ಯಾಲೆನ್ಸರ್ ಐಪಿ ವಿಳಾಸ
• ಸರ್ವರ್, ಬ್ಯಾಕೆಂಡ್, ನಿದರ್ಶನ - ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವ ವರ್ಚುವಲ್ ಯಂತ್ರ
• RIP (ರಿಯಲ್ IP) - ಸರ್ವರ್ IP ವಿಳಾಸ
• ಆರೋಗ್ಯ ತಪಾಸಣೆ - ಸರ್ವರ್ ಸಿದ್ಧತೆಯನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ
• ಲಭ್ಯತೆ ವಲಯ, AZ - ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾದ ಮೂಲಸೌಕರ್ಯ
• ಪ್ರದೇಶ - ವಿವಿಧ AZ ಗಳ ಒಕ್ಕೂಟ

ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಮೂರು ಮುಖ್ಯ ಕಾರ್ಯಗಳನ್ನು ಪರಿಹರಿಸುತ್ತಾರೆ: ಅವರು ಸಮತೋಲನವನ್ನು ಸ್ವತಃ ನಿರ್ವಹಿಸುತ್ತಾರೆ, ಸೇವೆಯ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತಾರೆ ಮತ್ತು ಅದರ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಸರಳಗೊಳಿಸುತ್ತಾರೆ. ಸ್ವಯಂಚಾಲಿತ ಟ್ರಾಫಿಕ್ ನಿರ್ವಹಣೆಯ ಮೂಲಕ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ: ಬ್ಯಾಲೆನ್ಸರ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಲೈವ್‌ನೆಸ್ ಚೆಕ್ ಅನ್ನು ರವಾನಿಸದ ಸಮತೋಲನದಿಂದ ನಿದರ್ಶನಗಳನ್ನು ಹೊರತುಪಡಿಸುತ್ತದೆ. ನಿದರ್ಶನಗಳಾದ್ಯಂತ ಲೋಡ್ ಅನ್ನು ಸಮವಾಗಿ ವಿತರಿಸುವ ಮೂಲಕ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಖಾತ್ರಿಪಡಿಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ, ಜೊತೆಗೆ ಫ್ಲೈನಲ್ಲಿ ನಿದರ್ಶನಗಳ ಪಟ್ಟಿಯನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ಸಮತೋಲನವು ಸಾಕಷ್ಟು ಏಕರೂಪವಾಗಿಲ್ಲದಿದ್ದರೆ, ಕೆಲವು ನಿದರ್ಶನಗಳು ತಮ್ಮ ಸಾಮರ್ಥ್ಯದ ಮಿತಿಯನ್ನು ಮೀರಿದ ಲೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ ಮತ್ತು ಸೇವೆಯು ಕಡಿಮೆ ವಿಶ್ವಾಸಾರ್ಹವಾಗುತ್ತದೆ.

ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಓಎಸ್ಐ ಮಾದರಿಯಿಂದ ಪ್ರೋಟೋಕಾಲ್ ಲೇಯರ್ ಮೂಲಕ ವರ್ಗೀಕರಿಸಲಾಗುತ್ತದೆ. ಕ್ಲೌಡ್ ಬ್ಯಾಲೆನ್ಸರ್ TCP ಮಟ್ಟದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ನಾಲ್ಕನೇ ಪದರ, L4 ಗೆ ಅನುರೂಪವಾಗಿದೆ.

ಕ್ಲೌಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಅವಲೋಕನಕ್ಕೆ ಹೋಗೋಣ. ನಾವು ವಿವರಗಳ ಮಟ್ಟವನ್ನು ಕ್ರಮೇಣ ಹೆಚ್ಚಿಸುತ್ತೇವೆ. ನಾವು ಬ್ಯಾಲೆನ್ಸರ್ ಘಟಕಗಳನ್ನು ಮೂರು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತೇವೆ. ಸಂರಚನಾ ಪ್ಲೇನ್ ವರ್ಗವು ಬಳಕೆದಾರರ ಸಂವಹನಕ್ಕೆ ಕಾರಣವಾಗಿದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ನ ಗುರಿ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಸಿಸ್ಟಂನ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾ ಪ್ಲೇನ್ ವರ್ಗದಿಂದ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ನಿಮ್ಮ ನಿದರ್ಶನಗಳಿಗೆ ದಟ್ಟಣೆಯನ್ನು ತಲುಪಿಸಲು ನೇರವಾಗಿ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ.

ಡೇಟಾ ಪ್ಲೇನ್

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

ಟ್ರಾಫಿಕ್ ಅನ್ನು ಇಸಿಎಂಪಿ ಮೂಲಕ ರವಾನಿಸಲಾಗುತ್ತದೆ - ಇದು ರೂಟಿಂಗ್ ತಂತ್ರವಾಗಿದ್ದು, ಅದರ ಪ್ರಕಾರ ಗುರಿಗೆ ಹಲವಾರು ಸಮಾನವಾದ ಉತ್ತಮ ಮಾರ್ಗಗಳಿವೆ (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಗುರಿಯು ಗಮ್ಯಸ್ಥಾನ ಐಪಿ ವಿಳಾಸವಾಗಿರುತ್ತದೆ) ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಕಳುಹಿಸಬಹುದು. ಕೆಳಗಿನ ಯೋಜನೆಯ ಪ್ರಕಾರ ನಾವು ಹಲವಾರು ಲಭ್ಯತೆಯ ವಲಯಗಳಲ್ಲಿ ಕೆಲಸವನ್ನು ಬೆಂಬಲಿಸುತ್ತೇವೆ: ನಾವು ಪ್ರತಿ ವಲಯದಲ್ಲಿ ವಿಳಾಸವನ್ನು ಜಾಹೀರಾತು ಮಾಡುತ್ತೇವೆ, ದಟ್ಟಣೆಯು ಹತ್ತಿರದ ಒಂದಕ್ಕೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಅದರ ಮಿತಿಗಳನ್ನು ಮೀರಿ ಹೋಗುವುದಿಲ್ಲ. ನಂತರ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ಟ್ರಾಫಿಕ್‌ಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಹೆಚ್ಚು ವಿವರವಾಗಿ ನೋಡುತ್ತೇವೆ.

ಕಾನ್ಫಿಗರ್ ಪ್ಲೇನ್

 
ಸಂರಚನಾ ಸಮತಲದ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ API, ಇದರ ಮೂಲಕ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳೊಂದಿಗೆ ಮೂಲಭೂತ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ: ರಚಿಸುವುದು, ಅಳಿಸುವುದು, ನಿದರ್ಶನಗಳ ಸಂಯೋಜನೆಯನ್ನು ಬದಲಾಯಿಸುವುದು, ಆರೋಗ್ಯ ತಪಾಸಣೆ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯುವುದು ಇತ್ಯಾದಿ. ಒಂದು ಕಡೆ, ಇದು REST API, ಮತ್ತು ಇತರ, ನಾವು ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಆಗಾಗ್ಗೆ ಫ್ರೇಮ್‌ವರ್ಕ್ gRPC ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ನಾವು REST ಅನ್ನು gRPC ಗೆ "ಅನುವಾದಿಸುತ್ತೇವೆ" ಮತ್ತು ನಂತರ gRPC ಅನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತೇವೆ. ಯಾವುದೇ ವಿನಂತಿಯು Yandex.Cloud ಕೆಲಸಗಾರರ ಸಾಮಾನ್ಯ ಪೂಲ್ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಅಸಮಕಾಲಿಕ ಐಡೆಮ್ಪೋಟೆಂಟ್ ಕಾರ್ಯಗಳ ಸರಣಿಯ ರಚನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಕಾರ್ಯಗಳನ್ನು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಅಮಾನತುಗೊಳಿಸಬಹುದು ಮತ್ತು ನಂತರ ಮರುಪ್ರಾರಂಭಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಬರೆಯಲಾಗುತ್ತದೆ. ಇದು ಕಾರ್ಯಾಚರಣೆಗಳ ಸ್ಕೇಲೆಬಿಲಿಟಿ, ಪುನರಾವರ್ತನೆ ಮತ್ತು ಲಾಗಿಂಗ್ ಅನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ.

ಪರಿಣಾಮವಾಗಿ, API ನಿಂದ ಕಾರ್ಯವು ಬ್ಯಾಲೆನ್ಸರ್ ಸೇವಾ ನಿಯಂತ್ರಕಕ್ಕೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ, ಅದನ್ನು Go ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಇದು ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ತೆಗೆದುಹಾಕಬಹುದು, ಬ್ಯಾಕೆಂಡ್‌ಗಳು ಮತ್ತು ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಸಂಯೋಜನೆಯನ್ನು ಬದಲಾಯಿಸಬಹುದು. 

ಸೇವೆಯು ತನ್ನ ಸ್ಥಿತಿಯನ್ನು ಯಾಂಡೆಕ್ಸ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ವಿತರಿಸಿದ ನಿರ್ವಹಿಸಿದ ಡೇಟಾಬೇಸ್ ನೀವು ಶೀಘ್ರದಲ್ಲೇ ಬಳಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. Yandex.Cloud ನಲ್ಲಿ, ನಾವು ಈಗಾಗಲೇ ಇದ್ದಂತೆ ಹೇಳಿದರು, ನಾಯಿ ಆಹಾರದ ಪರಿಕಲ್ಪನೆಯು ಅನ್ವಯಿಸುತ್ತದೆ: ನಾವು ನಮ್ಮ ಸೇವೆಗಳನ್ನು ಬಳಸಿದರೆ, ನಮ್ಮ ಗ್ರಾಹಕರು ಸಹ ಅವುಗಳನ್ನು ಬಳಸಲು ಸಂತೋಷಪಡುತ್ತಾರೆ. ಅಂತಹ ಪರಿಕಲ್ಪನೆಯ ಅನುಷ್ಠಾನಕ್ಕೆ ಯಾಂಡೆಕ್ಸ್ ಡೇಟಾಬೇಸ್ ಒಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ನಾವು YDB ನಲ್ಲಿ ನಮ್ಮ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವ ಬಗ್ಗೆ ನಾವು ಯೋಚಿಸಬೇಕಾಗಿಲ್ಲ: ಈ ಸಮಸ್ಯೆಗಳನ್ನು ನಮಗೆ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ, ನಾವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸೇವೆಯಾಗಿ ಬಳಸುತ್ತೇವೆ.

ಬ್ಯಾಲೆನ್ಸರ್ ನಿಯಂತ್ರಕಕ್ಕೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. ಬ್ಯಾಲೆನ್ಸರ್ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸುವುದು ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರದ ಸಿದ್ಧತೆಯನ್ನು ಆರೋಗ್ಯ ತಪಾಸಣೆ ನಿಯಂತ್ರಕಕ್ಕೆ ಪರೀಕ್ಷಿಸಲು ಕಾರ್ಯವನ್ನು ಕಳುಹಿಸುವುದು ಇದರ ಕಾರ್ಯವಾಗಿದೆ.

ಆರೋಗ್ಯ ತಪಾಸಣೆ ನಿಯಂತ್ರಕ

ಇದು ಚೆಕ್ ನಿಯಮಗಳನ್ನು ಬದಲಾಯಿಸಲು ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು YDB ನಲ್ಲಿ ಉಳಿಸುತ್ತದೆ, ಹೆಲ್ಟ್‌ಚೆಕ್ ನೋಡ್‌ಗಳ ನಡುವೆ ಕಾರ್ಯಗಳನ್ನು ವಿತರಿಸುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಡೇಟಾಬೇಸ್‌ಗೆ ಉಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಲೋಡ್‌ಬ್ಯಾಲೆನ್ಸರ್ ನಿಯಂತ್ರಕಕ್ಕೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಇದು ಪ್ರತಿಯಾಗಿ, ಡೇಟಾ ಪ್ಲೇನ್‌ನಲ್ಲಿನ ಕ್ಲಸ್ಟರ್‌ನ ಸಂಯೋಜನೆಯನ್ನು ಲೋಡ್‌ಬ್ಯಾಲೆನ್ಸರ್-ನೋಡ್‌ಗೆ ಬದಲಾಯಿಸಲು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಅದನ್ನು ನಾನು ಕೆಳಗೆ ಚರ್ಚಿಸುತ್ತೇನೆ.

ಆರೋಗ್ಯ ತಪಾಸಣೆಯ ಬಗ್ಗೆ ಹೆಚ್ಚು ಮಾತನಾಡೋಣ. ಅವುಗಳನ್ನು ಹಲವಾರು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು. ಲೆಕ್ಕಪರಿಶೋಧನೆಗಳು ವಿಭಿನ್ನ ಯಶಸ್ಸಿನ ಮಾನದಂಡಗಳನ್ನು ಹೊಂದಿವೆ. TCP ಚೆಕ್‌ಗಳು ನಿಗದಿತ ಸಮಯದೊಳಗೆ ಸಂಪರ್ಕವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಸ್ಥಾಪಿಸುವ ಅಗತ್ಯವಿದೆ. HTTP ಚೆಕ್‌ಗಳಿಗೆ ಯಶಸ್ವಿ ಸಂಪರ್ಕ ಮತ್ತು 200 ಸ್ಥಿತಿ ಕೋಡ್‌ನೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಎರಡೂ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಅಲ್ಲದೆ, ಚೆಕ್ಗಳು ​​ಕ್ರಿಯೆಯ ವರ್ಗದಲ್ಲಿ ಭಿನ್ನವಾಗಿರುತ್ತವೆ - ಅವು ಸಕ್ರಿಯ ಮತ್ತು ನಿಷ್ಕ್ರಿಯವಾಗಿರುತ್ತವೆ. ನಿಷ್ಕ್ರಿಯ ತಪಾಸಣೆಗಳು ಯಾವುದೇ ವಿಶೇಷ ಕ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳದೆ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಸರಳವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ. ಇದು L4 ನಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಇದು ಉನ್ನತ ಮಟ್ಟದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ತರ್ಕವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ: L4 ನಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಯು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು ಅಥವಾ ಸಂಪರ್ಕವನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದು ಒಳ್ಳೆಯದು ಅಥವಾ ಕೆಟ್ಟದ್ದೇ ಎಂಬುದರ ಕುರಿತು ಯಾವುದೇ ಮಾಹಿತಿಯಿಲ್ಲ. ಸಕ್ರಿಯ ತಪಾಸಣೆಗಳಿಗೆ ಪ್ರತಿ ಸರ್ವರ್ ನಿದರ್ಶನಕ್ಕೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಲು ಬ್ಯಾಲೆನ್ಸರ್ ಅಗತ್ಯವಿರುತ್ತದೆ.

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

ಸಮತೋಲನ ಮತ್ತು ಆರೋಗ್ಯ ತಪಾಸಣೆಯನ್ನು ಬೇರ್ಪಡಿಸುವುದು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಹೆಲ್ತ್‌ಚೆಕ್ ನೋಡ್ ನಿದರ್ಶನಕ್ಕೆ ವಿನಂತಿಗಳನ್ನು ಮಾಡಿದರೆ, ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಿದರೆ (ಇದು ಪ್ರಸ್ತುತ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪೂರೈಸುತ್ತಿಲ್ಲ), ಆಗ ವಿಚಿತ್ರ ಪರಿಸ್ಥಿತಿ ಉದ್ಭವಿಸುತ್ತದೆ: ಸಂಪನ್ಮೂಲವು ಜೀವಂತವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ದಟ್ಟಣೆಯು ಅದನ್ನು ತಲುಪುವುದಿಲ್ಲ. ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಈ ರೀತಿ ಪರಿಹರಿಸುತ್ತೇವೆ: ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳ ಮೂಲಕ ಆರೋಗ್ಯ ತಪಾಸಣೆ ದಟ್ಟಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಾವು ಖಾತರಿಪಡಿಸುತ್ತೇವೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಮತ್ತು ಆರೋಗ್ಯ ತಪಾಸಣೆಯಿಂದ ದಟ್ಟಣೆಯೊಂದಿಗೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಚಲಿಸುವ ಯೋಜನೆಯು ಕನಿಷ್ಠವಾಗಿ ಭಿನ್ನವಾಗಿರುತ್ತದೆ: ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಪ್ಯಾಕೆಟ್‌ಗಳು ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ತಲುಪುತ್ತವೆ, ಅದು ಅವುಗಳನ್ನು ಗುರಿ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ತಲುಪಿಸುತ್ತದೆ.

ವ್ಯತ್ಯಾಸವೆಂದರೆ ಗ್ರಾಹಕರು ವಿಐಪಿಗೆ ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತಾರೆ, ಆದರೆ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳು ಪ್ರತಿಯೊಬ್ಬ ಆರ್‌ಐಪಿಗೆ ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತವೆ. ಇಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ: ನಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಬೂದು IP ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸಲು ನಾವು ಅವಕಾಶವನ್ನು ನೀಡುತ್ತೇವೆ. ಎರಡು ವಿಭಿನ್ನ ಕ್ಲೌಡ್ ಮಾಲೀಕರು ತಮ್ಮ ಸೇವೆಗಳನ್ನು ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳ ಹಿಂದೆ ಮರೆಮಾಡಿದ್ದಾರೆ ಎಂದು ಊಹಿಸೋಣ. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ 10.0.0.1/24 ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ಅದೇ ವಿಳಾಸಗಳೊಂದಿಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದೆ. ನೀವು ಹೇಗಾದರೂ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಮತ್ತು ಇಲ್ಲಿ ನೀವು Yandex.Cloud ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ನ ರಚನೆಗೆ ಧುಮುಕಬೇಕು. ನಲ್ಲಿ ಹೆಚ್ಚಿನ ವಿವರಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಉತ್ತಮ ಸುಮಾರು:ಮೇಘ ಘಟನೆಯಿಂದ ವೀಡಿಯೊ, ನೆಟ್‌ವರ್ಕ್ ಬಹು-ಪದರವಾಗಿದೆ ಮತ್ತು ಸಬ್‌ನೆಟ್ ಐಡಿಯಿಂದ ಪ್ರತ್ಯೇಕಿಸಬಹುದಾದ ಸುರಂಗಗಳನ್ನು ಹೊಂದಿದೆ ಎಂಬುದು ಈಗ ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ.

ಹೆಲ್ತ್‌ಚೆಕ್ ನೋಡ್‌ಗಳು ಕ್ವಾಸಿ-ಐಪಿವಿ6 ವಿಳಾಸಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತವೆ. ಅರೆ-ವಿಳಾಸವು IPv6 ವಿಳಾಸವನ್ನು ಹೊಂದಿರುವ IPv4 ವಿಳಾಸವಾಗಿದೆ ಮತ್ತು ಅದರೊಳಗೆ ಎಂಬೆಡ್ ಮಾಡಲಾದ ಬಳಕೆದಾರ ಸಬ್‌ನೆಟ್ ಐಡಿ. ಸಂಚಾರವು ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ತಲುಪುತ್ತದೆ, ಅದು IPv4 ಸಂಪನ್ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ, IPv6 ಅನ್ನು IPv4 ನೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಬಳಕೆದಾರರ ನೆಟ್ವರ್ಕ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ.

ರಿವರ್ಸ್ ಟ್ರಾಫಿಕ್ ಅದೇ ರೀತಿಯಲ್ಲಿ ಹೋಗುತ್ತದೆ: ಆರೋಗ್ಯ ಪರೀಕ್ಷಕರಿಂದ ಗಮ್ಯಸ್ಥಾನವು ಬೂದು ನೆಟ್‌ವರ್ಕ್ ಎಂದು ಬ್ಯಾಲೆನ್ಸರ್ ನೋಡುತ್ತಾನೆ ಮತ್ತು IPv4 ಅನ್ನು IPv6 ಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ.

VPP - ಡೇಟಾ ಪ್ಲೇನ್‌ನ ಹೃದಯ

ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ವೆಕ್ಟರ್ ಪ್ಯಾಕೆಟ್ ಪ್ರೊಸೆಸಿಂಗ್ (ವಿಪಿಪಿ) ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಅಳವಡಿಸಲಾಗಿದೆ, ಇದು ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್‌ನ ಬ್ಯಾಚ್ ಪ್ರೊಸೆಸಿಂಗ್‌ಗಾಗಿ ಸಿಸ್ಕೋದಿಂದ ಫ್ರೇಮ್‌ವರ್ಕ್ ಆಗಿದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಫ್ರೇಮ್‌ವರ್ಕ್ ಬಳಕೆದಾರ-ಸ್ಪೇಸ್ ನೆಟ್‌ವರ್ಕ್ ಸಾಧನ ನಿರ್ವಹಣಾ ಗ್ರಂಥಾಲಯದ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ - ಡೇಟಾ ಪ್ಲೇನ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಕಿಟ್ (DPDK). ಇದು ಹೆಚ್ಚಿನ ಪ್ಯಾಕೆಟ್ ಪ್ರೊಸೆಸಿಂಗ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ: ಕರ್ನಲ್‌ನಲ್ಲಿ ಕಡಿಮೆ ಅಡಚಣೆಗಳು ಸಂಭವಿಸುತ್ತವೆ ಮತ್ತು ಕರ್ನಲ್ ಸ್ಥಳ ಮತ್ತು ಬಳಕೆದಾರ ಸ್ಥಳದ ನಡುವೆ ಯಾವುದೇ ಸಂದರ್ಭ ಸ್ವಿಚ್‌ಗಳಿಲ್ಲ. 

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

ಉದಾಹರಣೆಗೆ, VPP ಯಲ್ಲಿ IP ಪ್ಯಾಕೆಟ್‌ಗಳ ಪ್ರಕ್ರಿಯೆಯು ಈ ಕೆಳಗಿನ ಕ್ರಮದಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ: ಮೊದಲನೆಯದಾಗಿ, ಪ್ಯಾಕೆಟ್ ಹೆಡರ್‌ಗಳನ್ನು ಪಾರ್ಸಿಂಗ್ ನೋಡ್‌ನಲ್ಲಿ ಪಾರ್ಸ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ನೋಡ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಇದು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕಗಳ ಪ್ರಕಾರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮತ್ತಷ್ಟು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ.

ಸ್ವಲ್ಪ ಹಾರ್ಡ್ಕೋರ್. VPP ಯ ಲೇಖಕರು ಪ್ರೊಸೆಸರ್ ಕ್ಯಾಶ್‌ಗಳ ಬಳಕೆಯಲ್ಲಿ ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಸಹಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ಯಾಕೆಟ್‌ಗಳ ವೆಕ್ಟರ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ವಿಶಿಷ್ಟವಾದ ಕೋಡ್ ಹಸ್ತಚಾಲಿತ ವೆಕ್ಟರೈಸೇಶನ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ: ಒಂದು ಸಂಸ್ಕರಣಾ ಲೂಪ್ ಇದೆ, ಇದರಲ್ಲಿ "ನಾವು ಸರದಿಯಲ್ಲಿ ನಾಲ್ಕು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ" ಎಂಬಂತಹ ಪರಿಸ್ಥಿತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ, ನಂತರ ಇಬ್ಬರಿಗೆ ಒಂದೇ, ನಂತರ - ಒಬ್ಬರಿಗೆ. ನಂತರದ ಪುನರಾವರ್ತನೆಗಳಲ್ಲಿ ಅವುಗಳ ಪ್ರವೇಶವನ್ನು ವೇಗಗೊಳಿಸಲು ಕ್ಯಾಶ್‌ಗಳಿಗೆ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡಲು ಪ್ರಿಫೆಚ್ ಸೂಚನೆಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

ಆದ್ದರಿಂದ, Healthchecks IPv6 ಮೂಲಕ VPP ಗೆ ಮಾತನಾಡುತ್ತವೆ, ಅದು ಅವುಗಳನ್ನು IPv4 ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಇದನ್ನು ಗ್ರಾಫ್‌ನಲ್ಲಿ ನೋಡ್‌ನಿಂದ ಮಾಡಲಾಗುತ್ತದೆ, ಇದನ್ನು ನಾವು ಅಲ್ಗಾರಿದಮಿಕ್ NAT ಎಂದು ಕರೆಯುತ್ತೇವೆ. ರಿವರ್ಸ್ ಟ್ರಾಫಿಕ್‌ಗಾಗಿ (ಮತ್ತು IPv6 ನಿಂದ IPv4 ಗೆ ಪರಿವರ್ತನೆ) ಅದೇ ಅಲ್ಗಾರಿದಮಿಕ್ NAT ನೋಡ್ ಇದೆ.

ಬ್ಯಾಲೆನ್ಸರ್ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ನೇರ ಸಂಚಾರವು ಗ್ರಾಫ್ ನೋಡ್‌ಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಅದು ಸಮತೋಲನವನ್ನು ಸ್ವತಃ ನಿರ್ವಹಿಸುತ್ತದೆ. 

ಮೊದಲ ನೋಡ್ ಜಿಗುಟಾದ ಅವಧಿಗಳು. ಇದು ಹ್ಯಾಶ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ 5-ಟುಪಲ್ ಸ್ಥಾಪಿತ ಅವಧಿಗಳಿಗಾಗಿ. 5-tuple ಕ್ಲೈಂಟ್‌ನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದರಿಂದ ಮಾಹಿತಿಯನ್ನು ರವಾನಿಸಲಾಗುತ್ತದೆ, ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಲಭ್ಯವಿರುವ ಸಂಪನ್ಮೂಲಗಳ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್‌ಗಳು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್. 

5-ಟುಪಲ್ ಹ್ಯಾಶ್ ನಂತರದ ಸ್ಥಿರವಾದ ಹ್ಯಾಶಿಂಗ್ ನೋಡ್‌ನಲ್ಲಿ ಕಡಿಮೆ ಲೆಕ್ಕಾಚಾರವನ್ನು ನಿರ್ವಹಿಸಲು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಜೊತೆಗೆ ಬ್ಯಾಲೆನ್ಸರ್‌ನ ಹಿಂದೆ ಸಂಪನ್ಮೂಲ ಪಟ್ಟಿಯ ಬದಲಾವಣೆಗಳನ್ನು ಉತ್ತಮವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ಯಾವುದೇ ಸೆಷನ್ ಇಲ್ಲದ ಪ್ಯಾಕೆಟ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಬಂದಾಗ, ಅದನ್ನು ಸ್ಥಿರವಾದ ಹ್ಯಾಶಿಂಗ್ ನೋಡ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಸ್ಥಿರವಾದ ಹ್ಯಾಶಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಮತೋಲನವು ಇಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ: ಲಭ್ಯವಿರುವ "ಲೈವ್" ಸಂಪನ್ಮೂಲಗಳ ಪಟ್ಟಿಯಿಂದ ನಾವು ಸಂಪನ್ಮೂಲವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ. ಮುಂದೆ, ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು NAT ನೋಡ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಇದು ವಾಸ್ತವವಾಗಿ ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ಮರು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ನೀವು ನೋಡುವಂತೆ, ನಾವು VPP ಯ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುತ್ತೇವೆ - ಇಷ್ಟಪಡಲು ಇಷ್ಟಪಡುತ್ತೇವೆ, ಪ್ರೊಸೆಸರ್ ಕ್ಯಾಶ್‌ಗಳ ದಕ್ಷತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಇದೇ ರೀತಿಯ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಗುಂಪು ಮಾಡುವುದು.

ಸ್ಥಿರವಾದ ಹ್ಯಾಶಿಂಗ್

ನಾವು ಅದನ್ನು ಏಕೆ ಆರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದು ಏನು? ಮೊದಲಿಗೆ, ಹಿಂದಿನ ಕಾರ್ಯವನ್ನು ಪರಿಗಣಿಸೋಣ - ಪಟ್ಟಿಯಿಂದ ಸಂಪನ್ಮೂಲವನ್ನು ಆರಿಸುವುದು. 

ಅಸಮಂಜಸವಾದ ಹ್ಯಾಶಿಂಗ್‌ನೊಂದಿಗೆ, ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‌ನ ಹ್ಯಾಶ್ ಅನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆಯಿಂದ ಈ ಹ್ಯಾಶ್ ಅನ್ನು ಭಾಗಿಸುವ ಉಳಿದ ಭಾಗದಿಂದ ಸಂಪನ್ಮೂಲವನ್ನು ಪಟ್ಟಿಯಿಂದ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಪಟ್ಟಿಯು ಬದಲಾಗದೆ ಉಳಿಯುವವರೆಗೆ, ಈ ಯೋಜನೆಯು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ನಾವು ಯಾವಾಗಲೂ ಅದೇ 5-ಟುಪಲ್ ಹೊಂದಿರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಅದೇ ನಿದರ್ಶನಕ್ಕೆ ಕಳುಹಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳು ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದರೆ, ಹ್ಯಾಶ್‌ಗಳ ಗಮನಾರ್ಹ ಭಾಗಕ್ಕೆ ಆಯ್ಕೆಯು ಬದಲಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ನ TCP ಸಂಪರ್ಕಗಳು ಮುರಿದುಹೋಗುತ್ತವೆ: ಈ ಹಿಂದೆ ನಿದರ್ಶನ A ಅನ್ನು ತಲುಪಿದ ಪ್ಯಾಕೆಟ್ ನಿದರ್ಶನ B ಅನ್ನು ತಲುಪಲು ಪ್ರಾರಂಭಿಸಬಹುದು, ಇದು ಈ ಪ್ಯಾಕೆಟ್‌ಗೆ ಸೆಷನ್‌ಗೆ ಪರಿಚಿತವಾಗಿಲ್ಲ.

ಸ್ಥಿರವಾದ ಹ್ಯಾಶಿಂಗ್ ವಿವರಿಸಿದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಈ ಪರಿಕಲ್ಪನೆಯನ್ನು ವಿವರಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವೆಂದರೆ: ನೀವು ಹ್ಯಾಶ್ ಮೂಲಕ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿತರಿಸುವ ಉಂಗುರವನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಊಹಿಸಿ (ಉದಾಹರಣೆಗೆ, IP: ಪೋರ್ಟ್ ಮೂಲಕ). ಒಂದು ಸಂಪನ್ಮೂಲವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಚಕ್ರವನ್ನು ಕೋನದಿಂದ ತಿರುಗಿಸುವುದು, ಇದು ಪ್ಯಾಕೆಟ್ನ ಹ್ಯಾಶ್ನಿಂದ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತದೆ.

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

ಬ್ಯಾಲೆನ್ಸರ್ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳ ನಡುವಿನ ನೇರ ಸಂಚಾರಕ್ಕೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನಾವು ನೋಡಿದ್ದೇವೆ. ಈಗ ರಿಟರ್ನ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನೋಡೋಣ. ಇದು ಚೆಕ್ ಟ್ರಾಫಿಕ್‌ನಂತೆಯೇ ಅದೇ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ - ಅಲ್ಗಾರಿದಮಿಕ್ NAT ಮೂಲಕ, ಅಂದರೆ, ಕ್ಲೈಂಟ್ ಟ್ರಾಫಿಕ್‌ಗಾಗಿ ರಿವರ್ಸ್ NAT 44 ಮೂಲಕ ಮತ್ತು ಆರೋಗ್ಯ ತಪಾಸಣೆ ಟ್ರಾಫಿಕ್‌ಗಾಗಿ NAT 46 ಮೂಲಕ. ನಾವು ನಮ್ಮ ಸ್ವಂತ ಯೋಜನೆಗೆ ಬದ್ಧರಾಗಿದ್ದೇವೆ: ನಾವು ಆರೋಗ್ಯ ತಪಾಸಣೆ ಟ್ರಾಫಿಕ್ ಮತ್ತು ನೈಜ ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಏಕೀಕರಿಸುತ್ತೇವೆ.

ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್-ನೋಡ್ ಮತ್ತು ಜೋಡಿಸಲಾದ ಘಟಕಗಳು

VPP ಯಲ್ಲಿ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳ ಸಂಯೋಜನೆಯನ್ನು ಸ್ಥಳೀಯ ಸೇವೆಯಿಂದ ವರದಿ ಮಾಡಲಾಗಿದೆ - ಲೋಡ್‌ಬ್ಯಾಲೆನ್ಸರ್-ನೋಡ್. ಇದು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್-ನಿಯಂತ್ರಕದಿಂದ ಈವೆಂಟ್‌ಗಳ ಸ್ಟ್ರೀಮ್‌ಗೆ ಚಂದಾದಾರರಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರಸ್ತುತ VPP ಸ್ಥಿತಿ ಮತ್ತು ನಿಯಂತ್ರಕದಿಂದ ಸ್ವೀಕರಿಸಿದ ಗುರಿ ಸ್ಥಿತಿಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಯೋಜಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ನಾವು ಮುಚ್ಚಿದ ವ್ಯವಸ್ಥೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ: API ಯಿಂದ ಈವೆಂಟ್‌ಗಳು ಬ್ಯಾಲೆನ್ಸರ್ ನಿಯಂತ್ರಕಕ್ಕೆ ಬರುತ್ತವೆ, ಇದು ಸಂಪನ್ಮೂಲಗಳ "ಲೈವ್ನೆಸ್" ಅನ್ನು ಪರಿಶೀಲಿಸಲು ಆರೋಗ್ಯ ತಪಾಸಣೆ ನಿಯಂತ್ರಕಕ್ಕೆ ಕಾರ್ಯಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಅದು ಪ್ರತಿಯಾಗಿ, ಆರೋಗ್ಯ ತಪಾಸಣೆ-ನೋಡ್‌ಗೆ ಕಾರ್ಯಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ, ನಂತರ ಅದು ಅವುಗಳನ್ನು ಬ್ಯಾಲೆನ್ಸರ್ ನಿಯಂತ್ರಕಕ್ಕೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್-ನೋಡ್ ನಿಯಂತ್ರಕದಿಂದ ಈವೆಂಟ್‌ಗಳಿಗೆ ಚಂದಾದಾರರಾಗುತ್ತದೆ ಮತ್ತು VPP ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಅಂತಹ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಪ್ರತಿ ಸೇವೆಯು ನೆರೆಯ ಸೇವೆಗಳ ಬಗ್ಗೆ ಅಗತ್ಯವಿರುವದನ್ನು ಮಾತ್ರ ತಿಳಿದಿದೆ. ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ ಸೀಮಿತವಾಗಿದೆ ಮತ್ತು ನಾವು ಸ್ವತಂತ್ರವಾಗಿ ವಿವಿಧ ವಿಭಾಗಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಮತ್ತು ಅಳೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಲಾಯಿತು?

ನಿಯಂತ್ರಣ ಸಮತಲದಲ್ಲಿರುವ ನಮ್ಮ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು Go ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಉತ್ತಮ ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿವೆ. ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ಗೋ ಅನೇಕ ತೆರೆದ ಮೂಲ ಗ್ರಂಥಾಲಯಗಳನ್ನು ಹೊಂದಿದೆ. ನಾವು GRPC ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತೇವೆ, ಎಲ್ಲಾ ಘಟಕಗಳು ಸೇವಾ ಅನ್ವೇಷಣೆಯ ತೆರೆದ ಮೂಲ ಅನುಷ್ಠಾನವನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ - ನಮ್ಮ ಸೇವೆಗಳು ಪರಸ್ಪರರ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತವೆ, ಅವುಗಳ ಸಂಯೋಜನೆಯನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಬದಲಾಯಿಸಬಹುದು ಮತ್ತು ನಾವು ಇದನ್ನು GRPC ಸಮತೋಲನದೊಂದಿಗೆ ಲಿಂಕ್ ಮಾಡಿದ್ದೇವೆ. ಮೆಟ್ರಿಕ್‌ಗಳಿಗಾಗಿ, ನಾವು ಮುಕ್ತ ಮೂಲ ಪರಿಹಾರವನ್ನು ಸಹ ಬಳಸುತ್ತೇವೆ. ಡೇಟಾ ಪ್ಲೇನ್‌ನಲ್ಲಿ, ನಾವು ಯೋಗ್ಯವಾದ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ದೊಡ್ಡ ಸಂಪನ್ಮೂಲ ಮೀಸಲು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ: ಕಬ್ಬಿಣದ ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಡ್‌ಗಿಂತ ಹೆಚ್ಚಾಗಿ ನಾವು VPP ಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅವಲಂಬಿಸಿರುವ ಸ್ಟ್ಯಾಂಡ್ ಅನ್ನು ಜೋಡಿಸುವುದು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿದೆ.

ತೊಂದರೆಗಳು ಮತ್ತು ಪರಿಹಾರಗಳು

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

ಅಲ್ಲದೆ, ಕ್ರಿಯಾತ್ಮಕ ಪರೀಕ್ಷೆಗಳಿಗೆ ಗೋ ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆಯಾಗಿರುವುದಿಲ್ಲ. ಅವರು ಸಾಕಷ್ಟು ಮಾತಿನವರಾಗಿದ್ದಾರೆ, ಮತ್ತು "ಸಿಐನಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಬ್ಯಾಚ್ನಲ್ಲಿ ಚಾಲನೆ ಮಾಡುವ" ಪ್ರಮಾಣಿತ ವಿಧಾನವು ಅವರಿಗೆ ತುಂಬಾ ಸೂಕ್ತವಲ್ಲ. ವಾಸ್ತವವೆಂದರೆ ಕ್ರಿಯಾತ್ಮಕ ಪರೀಕ್ಷೆಗಳು ಹೆಚ್ಚು ಸಂಪನ್ಮೂಲ-ಬೇಡಿಕೆಯ ಮತ್ತು ನೈಜ ಸಮಯಾವಧಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಈ ಕಾರಣದಿಂದಾಗಿ, CPU ಯುನಿಟ್ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಕಾರ್ಯನಿರತವಾಗಿರುವ ಕಾರಣ ಪರೀಕ್ಷೆಗಳು ವಿಫಲವಾಗಬಹುದು. ತೀರ್ಮಾನ: ಸಾಧ್ಯವಾದರೆ, ಘಟಕ ಪರೀಕ್ಷೆಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ "ಭಾರೀ" ಪರೀಕ್ಷೆಗಳನ್ನು ನಿರ್ವಹಿಸಿ. 

ಮೈಕ್ರೋಸರ್ವೀಸ್ ಈವೆಂಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಏಕಶಿಲೆಗಿಂತ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ: ಡಜನ್ಗಟ್ಟಲೆ ವಿಭಿನ್ನ ಯಂತ್ರಗಳಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ತುಂಬಾ ಅನುಕೂಲಕರವಲ್ಲ. ತೀರ್ಮಾನ: ನೀವು ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳನ್ನು ಮಾಡಿದರೆ, ತಕ್ಷಣವೇ ಪತ್ತೆಹಚ್ಚುವ ಬಗ್ಗೆ ಯೋಚಿಸಿ.

ನಮ್ಮ ಯೋಜನೆಗಳು

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

ಇತ್ತೀಚೆಗೆ, ಯಾಂಡೆಕ್ಸ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನ ಸಾರ್ವಜನಿಕ ಬಿಡುಗಡೆ ನಡೆಯಿತು. ಅನ್ವೇಷಿಸಿ ದಸ್ತಾವೇಜನ್ನು ಸೇವೆಗೆ, ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ನಿಮಗೆ ಅನುಕೂಲಕರ ರೀತಿಯಲ್ಲಿ ನಿರ್ವಹಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಯೋಜನೆಗಳ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಹೆಚ್ಚಿಸಿ!

ಮೂಲ: www.habr.com