ಆಧುನಿಕ ದತ್ತಾಂಶ ಕೇಂದ್ರಗಳು ನೂರಾರು ಸಕ್ರಿಯ ಸಾಧನಗಳನ್ನು ಸ್ಥಾಪಿಸಿವೆ, ವಿವಿಧ ರೀತಿಯ ಮೇಲ್ವಿಚಾರಣೆಯಿಂದ ಆವರಿಸಲ್ಪಟ್ಟಿದೆ. ಆದರೆ ಕೈಯಲ್ಲಿ ಪರಿಪೂರ್ಣ ಮೇಲ್ವಿಚಾರಣೆ ಹೊಂದಿರುವ ಆದರ್ಶ ಎಂಜಿನಿಯರ್ ಕೂಡ ಕೆಲವೇ ನಿಮಿಷಗಳಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ವೈಫಲ್ಯಕ್ಕೆ ಸರಿಯಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ನೆಕ್ಸ್ಟ್ ಹಾಪ್ 2020 ಕಾನ್ಫರೆನ್ಸ್‌ನಲ್ಲಿನ ವರದಿಯಲ್ಲಿ, ನಾನು DC ನೆಟ್ವರ್ಕ್ ವಿನ್ಯಾಸ ವಿಧಾನವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಿದ್ದೇನೆ, ಅದು ವಿಶಿಷ್ಟ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದೆ - ಡೇಟಾ ಸೆಂಟರ್ ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಸ್ವತಃ ವಾಸಿಯಾಗುತ್ತದೆ. ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಎಂಜಿನಿಯರ್ ಶಾಂತವಾಗಿ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಾರೆ, ಆದರೆ ಸೇವೆಗಳು ಅದನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ.
ಅನೇಕ ನೆಟ್ವರ್ಕ್ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ, ಡೇಟಾ ಸೆಂಟರ್ ನೆಟ್ವರ್ಕ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಸಹಜವಾಗಿ, ToR ನೊಂದಿಗೆ, ರಾಕ್‌ನಲ್ಲಿನ ಸ್ವಿಚ್‌ನೊಂದಿಗೆ. ToR ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ರೀತಿಯ ಲಿಂಕ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಸಣ್ಣವುಗಳು ಸರ್ವರ್‌ಗಳಿಗೆ ಹೋಗುತ್ತವೆ, ಇತರರು - ಅವುಗಳಲ್ಲಿ N ಪಟ್ಟು ಹೆಚ್ಚು ಇವೆ - ಮೊದಲ ಹಂತದ ಸ್ಪೈನ್ಗಳ ಕಡೆಗೆ ಹೋಗುತ್ತವೆ, ಅಂದರೆ ಅದರ ಅಪ್‌ಲಿಂಕ್‌ಗಳಿಗೆ. ಅಪ್‌ಲಿಂಕ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸಮಾನವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅಪ್‌ಲಿಂಕ್‌ಗಳ ನಡುವಿನ ದಟ್ಟಣೆಯು 5-ಟುಪಲ್‌ನಿಂದ ಹ್ಯಾಶ್ ಅನ್ನು ಆಧರಿಸಿ ಸಮತೋಲಿತವಾಗಿರುತ್ತದೆ, ಇದು ಪ್ರೊಟೊ, src_ip, dst_ip, src_port, dst_port ಒಳಗೊಂಡಿರುತ್ತದೆ. ಇಲ್ಲಿ ಆಶ್ಚರ್ಯವಿಲ್ಲ.
ಮುಂದೆ, ಪ್ಲಾನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಹೇಗಿರುತ್ತದೆ? ಮೊದಲ ಹಂತದ ಸ್ಪೈನ್ಗಳು ಒಂದಕ್ಕೊಂದು ಸಂಪರ್ಕ ಹೊಂದಿಲ್ಲ, ಆದರೆ ಸೂಪರ್ಸ್ಪೈನ್ಗಳ ಮೂಲಕ ಸಂಪರ್ಕ ಹೊಂದಿವೆ. X ಅಕ್ಷರವು ಸೂಪರ್‌ಸ್ಪೈನ್‌ಗಳಿಗೆ ಕಾರಣವಾಗಿದೆ; ಇದು ಬಹುತೇಕ ಕ್ರಾಸ್-ಕನೆಕ್ಟ್‌ನಂತಿದೆ.
ಮತ್ತು ಮತ್ತೊಂದೆಡೆ, ಟೋರಿ ಮೊದಲ ಹಂತದ ಎಲ್ಲಾ ಸ್ಪೈನ್ಗಳೊಂದಿಗೆ ಸಂಪರ್ಕ ಹೊಂದಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಈ ಚಿತ್ರದಲ್ಲಿ ಯಾವುದು ಮುಖ್ಯ? ನಾವು ರ್ಯಾಕ್ ಒಳಗೆ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಸಂವಹನವು ಸಹಜವಾಗಿ, ToR ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಮಾಡ್ಯೂಲ್ ಒಳಗೆ ಪರಸ್ಪರ ಕ್ರಿಯೆಯು ಸಂಭವಿಸಿದಲ್ಲಿ, ಮೊದಲ ಹಂತದ ಸ್ಪೈನ್ಗಳ ಮೂಲಕ ಪರಸ್ಪರ ಕ್ರಿಯೆಯು ಸಂಭವಿಸುತ್ತದೆ. ಪರಸ್ಪರ ಕ್ರಿಯೆಯು ಇಂಟರ್ ಮಾಡ್ಯುಲರ್ ಆಗಿದ್ದರೆ - ಇಲ್ಲಿರುವಂತೆ, ToR 1 ಮತ್ತು ToR 2 - ನಂತರ ಪರಸ್ಪರ ಕ್ರಿಯೆಯು ಮೊದಲ ಮತ್ತು ಎರಡನೆಯ ಹಂತಗಳ ಸ್ಪೈನ್ಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ.
ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಅಂತಹ ವಾಸ್ತುಶಿಲ್ಪವು ಸುಲಭವಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಆಗಿದೆ. ನಾವು ಪೋರ್ಟ್ ಸಾಮರ್ಥ್ಯ ಹೊಂದಿದ್ದರೆ, ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ಬಿಡುವಿನ ಸ್ಥಳ ಮತ್ತು ಪೂರ್ವ-ಲೇಯ್ಡ್ ಫೈಬರ್, ನಂತರ ಲೇನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಯಾವಾಗಲೂ ಹೆಚ್ಚಿಸಬಹುದು, ಇದರಿಂದಾಗಿ ಸಿಸ್ಟಮ್‌ನ ಒಟ್ಟಾರೆ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಕಾಗದದ ಮೇಲೆ ಇದನ್ನು ಮಾಡುವುದು ತುಂಬಾ ಸುಲಭ. ಜೀವನದಲ್ಲಿ ಹೀಗೇ ಇರುತ್ತೆ. ಆದರೆ ಇಂದಿನ ಕಥೆ ಅದರ ಬಗ್ಗೆ ಅಲ್ಲ.
ಸರಿಯಾದ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ. ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ ನಾವು ಹಲವು ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅವರು ಷರತ್ತುಬದ್ಧವಾಗಿ ಸ್ವತಂತ್ರರು. ಡೇಟಾ ಕೇಂದ್ರದ ಒಳಗಿನ ಒಂದು ಮಾರ್ಗವು ToR ಒಳಗೆ ಮಾತ್ರ ಸಾಧ್ಯ. ಮಾಡ್ಯೂಲ್ ಒಳಗೆ, ನಾವು ಲೇನ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಸಮಾನವಾದ ಮಾರ್ಗಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮಾಡ್ಯೂಲ್‌ಗಳ ನಡುವಿನ ಮಾರ್ಗಗಳ ಸಂಖ್ಯೆಯು ವಿಮಾನಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಪ್ರತಿ ಸಮತಲದಲ್ಲಿನ ಸೂಪರ್ಸ್ಪೈನ್ಗಳ ಸಂಖ್ಯೆಗೆ ಸಮಾನವಾಗಿರುತ್ತದೆ. ಅದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲು, ಪ್ರಮಾಣದ ಅರ್ಥವನ್ನು ಪಡೆಯಲು, ನಾನು Yandex ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮಾನ್ಯವಾಗಿರುವ ಸಂಖ್ಯೆಗಳನ್ನು ನೀಡುತ್ತೇನೆ.
ಎಂಟು ವಿಮಾನಗಳಿವೆ, ಪ್ರತಿ ವಿಮಾನವು 32 ಸೂಪರ್‌ಸ್ಪೈನ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಮಾಡ್ಯೂಲ್ ಒಳಗೆ ಎಂಟು ಮಾರ್ಗಗಳಿವೆ ಮತ್ತು ಇಂಟರ್ ಮಾಡ್ಯೂಲ್ ಪರಸ್ಪರ ಕ್ರಿಯೆಯೊಂದಿಗೆ ಅವುಗಳಲ್ಲಿ ಈಗಾಗಲೇ 256 ಇವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.
ಅಂದರೆ, ನಾವು ಕುಕ್‌ಬುಕ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದರೆ, ತಮ್ಮನ್ನು ತಾವು ಸರಿಪಡಿಸಿಕೊಳ್ಳುವ ದೋಷ-ಸಹಿಷ್ಣು ಡೇಟಾ ಕೇಂದ್ರಗಳನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುವುದು ಎಂದು ತಿಳಿಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದರೆ, ಪ್ಲ್ಯಾನರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಸರಿಯಾದ ಆಯ್ಕೆಯಾಗಿದೆ. ಇದು ಸ್ಕೇಲಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ಸಿದ್ಧಾಂತದಲ್ಲಿ ಇದು ಸುಲಭವಾಗಿದೆ. ಅನೇಕ ಸ್ವತಂತ್ರ ಮಾರ್ಗಗಳಿವೆ. ಪ್ರಶ್ನೆ ಉಳಿದಿದೆ: ಅಂತಹ ವಾಸ್ತುಶೈಲಿಯು ವೈಫಲ್ಯಗಳನ್ನು ಹೇಗೆ ಬದುಕಿಸುತ್ತದೆ? ವಿವಿಧ ವೈಫಲ್ಯಗಳಿವೆ. ಮತ್ತು ನಾವು ಈಗ ಇದನ್ನು ಚರ್ಚಿಸುತ್ತೇವೆ.
ನಮ್ಮ ಸೂಪರ್‌ಸ್ಪೈನ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರು "ಅನಾರೋಗ್ಯಕ್ಕೆ ಒಳಗಾಗಲಿ". ಇಲ್ಲಿ ನಾನು ಎರಡು ವಿಮಾನಗಳ ವಾಸ್ತುಶಿಲ್ಪಕ್ಕೆ ಮರಳಿದೆ. ನಾವು ಇವುಗಳೊಂದಿಗೆ ಉದಾಹರಣೆಯಾಗಿ ಅಂಟಿಕೊಳ್ಳುತ್ತೇವೆ ಏಕೆಂದರೆ ಕಡಿಮೆ ಚಲಿಸುವ ಭಾಗಗಳೊಂದಿಗೆ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಸುಲಭವಾಗುತ್ತದೆ. X11 ಅನಾರೋಗ್ಯಕ್ಕೆ ಒಳಗಾಗಲಿ. ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ವಾಸಿಸುವ ಸೇವೆಗಳ ಮೇಲೆ ಇದು ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ? ವೈಫಲ್ಯವು ನಿಜವಾಗಿ ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಬಹಳಷ್ಟು ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.
ವೈಫಲ್ಯವು ಉತ್ತಮವಾಗಿದ್ದರೆ, ಅದೇ BFD ಯ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಮಟ್ಟದಲ್ಲಿ ಅದು ಸಿಕ್ಕಿಬಿದ್ದಿದೆ, ಯಾಂತ್ರೀಕೃತಗೊಂಡವು ಸಮಸ್ಯಾತ್ಮಕ ಕೀಲುಗಳನ್ನು ಸಂತೋಷದಿಂದ ಇರಿಸುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ನಂತರ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ನಾವು ಅನೇಕ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಟ್ರಾಫಿಕ್ ಅನ್ನು ತಕ್ಷಣವೇ ಪರ್ಯಾಯ ಮಾರ್ಗಗಳಿಗೆ ಮರು-ಮಾರ್ಗಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸೇವೆಗಳು ಏನನ್ನೂ ಗಮನಿಸುವುದಿಲ್ಲ. ಇದೊಂದು ಒಳ್ಳೆಯ ಸ್ಕ್ರಿಪ್ಟ್.
ನಾವು ನಿರಂತರ ನಷ್ಟಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಕೆಟ್ಟ ಸನ್ನಿವೇಶವಾಗಿದೆ, ಮತ್ತು ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸಮಸ್ಯೆಯನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ. ಇದು ಅಪ್ಲಿಕೇಶನ್ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, TCP ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಚರ್ಚಿಸಲು ನಾವು ಸ್ವಲ್ಪ ಸಮಯವನ್ನು ಕಳೆಯಬೇಕಾಗಿದೆ.
ಈ ಮಾಹಿತಿಯೊಂದಿಗೆ ನಾನು ಯಾರಿಗೂ ಆಘಾತ ನೀಡುವುದಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ: TCP ಒಂದು ಪ್ರಸರಣ ದೃಢೀಕರಣ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಅಂದರೆ, ಸರಳವಾದ ಸಂದರ್ಭದಲ್ಲಿ, ಕಳುಹಿಸುವವರು ಎರಡು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಸಂಚಿತ ಅಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ: "ನಾನು ಎರಡು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇನೆ."
ಅದರ ನಂತರ, ಅವರು ಇನ್ನೂ ಎರಡು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ, ಮತ್ತು ಪರಿಸ್ಥಿತಿ ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಕೆಲವು ಸರಳೀಕರಣಕ್ಕಾಗಿ ನಾನು ಮುಂಚಿತವಾಗಿ ಕ್ಷಮೆಯಾಚಿಸುತ್ತೇನೆ. ವಿಂಡೋ (ವಿಮಾನದಲ್ಲಿನ ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಂಖ್ಯೆ) ಎರಡಾಗಿದ್ದರೆ ಈ ಸನ್ನಿವೇಶವು ಸರಿಯಾಗಿರುತ್ತದೆ. ಸಹಜವಾಗಿ, ಸಾಮಾನ್ಯ ಪ್ರಕರಣದಲ್ಲಿ ಇದು ಅಗತ್ಯವಾಗಿರುವುದಿಲ್ಲ. ಆದರೆ ವಿಂಡೋ ಗಾತ್ರವು ಪ್ಯಾಕೆಟ್ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಸಂದರ್ಭದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
ನಾವು ಪ್ಯಾಕೆಟ್ 3 ಅನ್ನು ಕಳೆದುಕೊಂಡರೆ ಏನಾಗುತ್ತದೆ? ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ವೀಕರಿಸುವವರು 1, 2 ಮತ್ತು 4 ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ಮತ್ತು ಅವರು SACK ಆಯ್ಕೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಕಳುಹಿಸುವವರಿಗೆ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತಾರೆ: "ನಿಮಗೆ ಗೊತ್ತಾ, ಮೂರು ಬಂದರು, ಆದರೆ ಮಧ್ಯವು ಕಳೆದುಹೋಗಿದೆ." ಅವರು ಹೇಳುತ್ತಾರೆ, "Ack 2, SACK 4."
ಈ ಕ್ಷಣದಲ್ಲಿ, ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದೆ ಕಳುಹಿಸುವವರು ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನಿಖರವಾಗಿ ಪುನರಾವರ್ತಿಸುತ್ತಾರೆ.
ಆದರೆ ವಿಂಡೋದಲ್ಲಿ ಕೊನೆಯ ಪ್ಯಾಕೆಟ್ ಕಳೆದು ಹೋದರೆ, ಪರಿಸ್ಥಿತಿಯು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿ ಕಾಣುತ್ತದೆ.
ಸ್ವೀಕರಿಸುವವರು ಮೊದಲ ಮೂರು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ಮೊದಲನೆಯದಾಗಿ ಕಾಯಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. Linux ಕರ್ನಲ್‌ನ TCP ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿನ ಕೆಲವು ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳಿಗೆ ಧನ್ಯವಾದಗಳು, ಫ್ಲ್ಯಾಗ್‌ಗಳು ಇದು ಕೊನೆಯ ಪ್ಯಾಕೆಟ್ ಅಥವಾ ಅದೇ ರೀತಿಯದ್ದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಸೂಚಿಸದ ಹೊರತು ಅದು ಜೋಡಿಯಾಗಿರುವ ಪ್ಯಾಕೆಟ್‌ಗಾಗಿ ಕಾಯುತ್ತದೆ. ಇದು ವಿಳಂಬಿತ ACK ಅವಧಿ ಮುಗಿಯುವವರೆಗೆ ಕಾಯುತ್ತದೆ ಮತ್ತು ನಂತರ ಮೊದಲ ಮೂರು ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಸ್ವೀಕೃತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಆದರೆ ಈಗ ಕಳುಹಿಸುವವರು ಕಾಯುತ್ತಾರೆ. ನಾಲ್ಕನೇ ಪ್ಯಾಕೇಜ್ ಕಳೆದುಹೋಗಿದೆಯೇ ಅಥವಾ ಬರಲಿದೆಯೇ ಎಂಬುದು ಅವನಿಗೆ ತಿಳಿದಿಲ್ಲ. ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಓವರ್‌ಲೋಡ್ ಮಾಡದಿರಲು, ಪ್ಯಾಕೆಟ್ ಕಳೆದುಹೋಗಿದೆ ಎಂಬ ಸ್ಪಷ್ಟ ಸೂಚನೆಗಾಗಿ ಅಥವಾ RTO ಅವಧಿ ಮುಗಿಯುವವರೆಗೆ ಕಾಯಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.
RTO ಕಾಲಾವಧಿ ಎಂದರೇನು? ಇದು TCP ಸ್ಟಾಕ್‌ನಿಂದ ಲೆಕ್ಕಾಚಾರ ಮಾಡಲಾದ RTT ಯ ಗರಿಷ್ಠ ಮತ್ತು ಕೆಲವು ಸ್ಥಿರವಾಗಿರುತ್ತದೆ. ಇದು ಯಾವ ರೀತಿಯ ಸ್ಥಿರವಾಗಿದೆ, ನಾವು ಈಗ ಚರ್ಚಿಸುತ್ತೇವೆ.
ಆದರೆ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ನಾವು ಮತ್ತೆ ದುರದೃಷ್ಟಕರಾಗಿದ್ದರೆ ಮತ್ತು ನಾಲ್ಕನೇ ಪ್ಯಾಕೆಟ್ ಮತ್ತೆ ಕಳೆದುಹೋದರೆ, ನಂತರ RTO ದ್ವಿಗುಣಗೊಳ್ಳುತ್ತದೆ. ಅಂದರೆ, ಪ್ರತಿ ವಿಫಲ ಪ್ರಯತ್ನವು ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ದ್ವಿಗುಣಗೊಳಿಸುವುದು ಎಂದರ್ಥ.
ಈಗ ಈ ಆಧಾರವು ಯಾವುದಕ್ಕೆ ಸಮಾನವಾಗಿದೆ ಎಂದು ನೋಡೋಣ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಕನಿಷ್ಠ RTO 200 ms ಆಗಿದೆ. ಡೇಟಾ ಪ್ಯಾಕೇಜ್‌ಗಳಿಗೆ ಇದು ಕನಿಷ್ಠ RTO ಆಗಿದೆ. SYN ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಇದು ವಿಭಿನ್ನವಾಗಿದೆ, 1 ಸೆಕೆಂಡ್. ನೀವು ನೋಡುವಂತೆ, ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮರುಕಳುಹಿಸುವ ಮೊದಲ ಪ್ರಯತ್ನವು ಡೇಟಾ ಕೇಂದ್ರದೊಳಗಿನ RTT ಗಿಂತ 100 ಪಟ್ಟು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಈಗ ನಮ್ಮ ಸನ್ನಿವೇಶಕ್ಕೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. ಸೇವೆಯಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ? ಸೇವೆಯು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಸೇವೆಯು ಮೊದಲಿಗೆ ಷರತ್ತುಬದ್ಧವಾಗಿ ಅದೃಷ್ಟಶಾಲಿಯಾಗಿರಲಿ ಮತ್ತು ಕಿಟಕಿಯ ಮಧ್ಯದಲ್ಲಿ ಏನನ್ನಾದರೂ ಕಳೆದುಕೊಳ್ಳಲಿ, ನಂತರ ಅದು SACK ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮರುಕಳುಹಿಸುತ್ತದೆ.
ಆದರೆ ದುರಾದೃಷ್ಟ ಮರುಕಳಿಸಿದರೆ, ನಮಗೆ ಆರ್‌ಟಿಒ ಇದೆ. ಇಲ್ಲಿ ಯಾವುದು ಮುಖ್ಯ? ಹೌದು, ನಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ನಾವು ಸಾಕಷ್ಟು ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದರೆ ಒಂದು ನಿರ್ದಿಷ್ಟ TCP ಸಂಪರ್ಕದ TCP ದಟ್ಟಣೆಯು ಅದೇ ಮುರಿದ ಸ್ಟಾಕ್ ಮೂಲಕ ಮುಂದುವರಿಯುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ನಷ್ಟಗಳು, ನಮ್ಮ ಈ ಮಾಂತ್ರಿಕ X11 ತನ್ನದೇ ಆದ ಮೇಲೆ ಹೋಗುವುದಿಲ್ಲ ಎಂದು ಒದಗಿಸಿದ, ಸಮಸ್ಯಾತ್ಮಕವಲ್ಲದ ಪ್ರದೇಶಗಳಿಗೆ ಟ್ರಾಫಿಕ್ ಹರಿಯುವುದಿಲ್ಲ. ನಾವು ಅದೇ ಮುರಿದ ಸ್ಟಾಕ್ ಮೂಲಕ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತಲುಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ. ಇದು ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ವೈಫಲ್ಯಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ: ದತ್ತಾಂಶ ಕೇಂದ್ರವು ಸಂವಹನ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಗುಂಪಾಗಿದೆ, ಮತ್ತು ಈ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಕೆಲವು TCP ಸಂಪರ್ಕಗಳು ಕ್ಷೀಣಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ - ಏಕೆಂದರೆ ಸೂಪರ್‌ಸ್ಪೈನ್ ಡೇಟಾ ಕೇಂದ್ರದ ಒಳಗೆ ಇರುವ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಗಾದೆ ಹೇಳುವಂತೆ: ನೀವು ಕುದುರೆಗೆ ಬೂಟು ಹಾಕದಿದ್ದರೆ, ಕುದುರೆ ಕುಂಟಾಯಿತು; ಕುದುರೆ ಕುಂಟಾಯಿತು - ವರದಿಯನ್ನು ತಲುಪಿಸಲಾಗಿಲ್ಲ; ವರದಿಯನ್ನು ತಲುಪಿಸಲಾಗಿಲ್ಲ - ನಾವು ಯುದ್ಧವನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ. ಸಮಸ್ಯೆ ಉದ್ಭವಿಸಿದ ಕ್ಷಣದಿಂದ ಸೇವೆಗಳು ಅನುಭವಿಸಲು ಪ್ರಾರಂಭವಾಗುವ ಅವನತಿಯ ಹಂತದವರೆಗೆ ಎಣಿಕೆಯು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಮಾತ್ರ. ಇದರರ್ಥ ಬಳಕೆದಾರರು ಎಲ್ಲೋ ಏನನ್ನಾದರೂ ಕಳೆದುಕೊಂಡಿರಬಹುದು.
ಪರಸ್ಪರ ಪೂರಕವಾಗಿರುವ ಎರಡು ಶ್ರೇಷ್ಠ ಪರಿಹಾರಗಳಿವೆ. ಮೊದಲನೆಯದು ಸ್ಟ್ರಾಗಳನ್ನು ಹಾಕಲು ಮತ್ತು ಈ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಸೇವೆಗಳು: “ನಾವು TCP ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಏನನ್ನಾದರೂ ತಿರುಚೋಣ. ಆಂತರಿಕ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ಅಥವಾ ದೀರ್ಘಾವಧಿಯ TCP ಸೆಷನ್‌ಗಳಲ್ಲಿ ಕಾಲಾವಧಿಯನ್ನು ಮಾಡೋಣ." ಸಮಸ್ಯೆಯೆಂದರೆ ಅಂತಹ ಪರಿಹಾರಗಳು: ಎ) ಅಳೆಯಬೇಡಿ; ಬಿ) ತುಂಬಾ ಕಳಪೆಯಾಗಿ ಪರಿಶೀಲಿಸಲಾಗಿದೆ. ಅಂದರೆ, ಸೇವೆಯು ಆಕಸ್ಮಿಕವಾಗಿ TCP ಸ್ಟಾಕ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವ ರೀತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದರೂ ಸಹ, ಮೊದಲನೆಯದಾಗಿ, ಇದು ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಎಲ್ಲಾ ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ಅನ್ವಯಿಸುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ, ಮತ್ತು ಎರಡನೆಯದಾಗಿ, ಹೆಚ್ಚಾಗಿ, ಇದನ್ನು ಮಾಡಲಾಗಿದೆ ಎಂದು ಅದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಸರಿಯಾಗಿ, ಮತ್ತು ಏನು ಅಲ್ಲ. ಅಂದರೆ, ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಅದು ಕಳಪೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅಳೆಯುವುದಿಲ್ಲ. ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಯಿದ್ದರೆ, ಯಾರನ್ನು ದೂರುವುದು? ಸಹಜವಾಗಿ, ಎನ್ಒಸಿ. NOC ಏನು ಮಾಡುತ್ತದೆ?
NOC ಕೆಲಸದಲ್ಲಿ ಈ ರೀತಿಯ ಏನಾದರೂ ನಡೆಯುತ್ತದೆ ಎಂದು ಅನೇಕ ಸೇವೆಗಳು ನಂಬುತ್ತವೆ. ಆದರೆ ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಅಷ್ಟೇ ಅಲ್ಲ.
ಶಾಸ್ತ್ರೀಯ ಯೋಜನೆಯಲ್ಲಿ NOC ಅನೇಕ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದೆ. ಇವು ಕಪ್ಪು ಪೆಟ್ಟಿಗೆ ಮತ್ತು ಬಿಳಿ ಪೆಟ್ಟಿಗೆಯ ಮೇಲ್ವಿಚಾರಣೆಯಾಗಿದೆ. ಕಪ್ಪು ಬಾಕ್ಸ್ ಬೆನ್ನುಮೂಳೆಯ ಮೇಲ್ವಿಚಾರಣೆಯ ಉದಾಹರಣೆಯ ಬಗ್ಗೆ ಕೊನೆಯ ನೆಕ್ಸ್ಟ್ ಹಾಪ್‌ನಲ್ಲಿ ಅಲೆಕ್ಸಾಂಡರ್ ಕ್ಲಿಮೆಂಕೊ. ಮೂಲಕ, ಈ ಮೇಲ್ವಿಚಾರಣೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ಆದರ್ಶ ಮಾನಿಟರಿಂಗ್ ಸಹ ಸಮಯದ ವಿಳಂಬವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಕೆಲವು ನಿಮಿಷಗಳು. ಅದು ಆಫ್ ಆದ ನಂತರ, ಕರ್ತವ್ಯದಲ್ಲಿರುವ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಅದರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಎರಡು ಬಾರಿ ಪರಿಶೀಲಿಸಲು ಸಮಯ ಬೇಕಾಗುತ್ತದೆ, ಸಮಸ್ಯೆಯನ್ನು ಸ್ಥಳೀಕರಿಸಿ ನಂತರ ಸಮಸ್ಯೆಯ ಪ್ರದೇಶವನ್ನು ನಂದಿಸಲು. ಅಂದರೆ, ಉತ್ತಮ ಸಂದರ್ಭದಲ್ಲಿ, ಸಮಸ್ಯೆಯ ಚಿಕಿತ್ಸೆಯು 5 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ, 20 ನಿಮಿಷಗಳು, ನಷ್ಟಗಳು ಎಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ ಎಂಬುದು ತಕ್ಷಣವೇ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲದಿದ್ದರೆ. ಈ ಸಮಯದಲ್ಲಿ - 5 ಅಥವಾ 20 ನಿಮಿಷಗಳು - ನಮ್ಮ ಸೇವೆಗಳು ಬಳಲುತ್ತುತ್ತಲೇ ಇರುತ್ತವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಅದು ಬಹುಶಃ ಉತ್ತಮವಾಗಿಲ್ಲ.
ನೀವು ನಿಜವಾಗಿಯೂ ಏನನ್ನು ಸ್ವೀಕರಿಸಲು ಬಯಸುತ್ತೀರಿ? ನಮ್ಮಲ್ಲಿ ಹಲವು ಮಾರ್ಗಗಳಿವೆ. ಮತ್ತು ತೊಂದರೆಗಳು ನಿಖರವಾಗಿ ಉದ್ಭವಿಸುತ್ತವೆ ಏಕೆಂದರೆ ದುರದೃಷ್ಟಕರವಾದ TCP ಹರಿವುಗಳು ಅದೇ ಮಾರ್ಗವನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತವೆ. ಒಂದೇ TCP ಸಂಪರ್ಕದಲ್ಲಿ ಅನೇಕ ಮಾರ್ಗಗಳನ್ನು ಬಳಸಲು ನಮಗೆ ಅನುಮತಿಸುವ ಏನಾದರೂ ನಮಗೆ ಅಗತ್ಯವಿದೆ. ನಮ್ಮಲ್ಲಿ ಪರಿಹಾರವಿದೆ ಎಂದು ತೋರುತ್ತದೆ. TCP ಇದೆ, ಇದನ್ನು ಮಲ್ಟಿಪಾತ್ TCP ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಅಂದರೆ ಬಹು ಪಥಗಳಿಗೆ TCP. ನಿಜ, ಇದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಕಾರ್ಯಕ್ಕಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ - ಹಲವಾರು ನೆಟ್ವರ್ಕ್ ಸಾಧನಗಳನ್ನು ಹೊಂದಿರುವ ಸ್ಮಾರ್ಟ್ಫೋನ್ಗಳಿಗಾಗಿ. ವರ್ಗಾವಣೆಯನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಲು ಅಥವಾ ಪ್ರಾಥಮಿಕ/ಬ್ಯಾಕಪ್ ಮೋಡ್ ಮಾಡಲು, ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಪಾರದರ್ಶಕವಾಗಿ ಬಹು ಎಳೆಗಳನ್ನು (ಸೆಷನ್‌ಗಳು) ರಚಿಸುವ ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳ ನಡುವೆ ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಅಥವಾ, ನಾನು ಹೇಳಿದಂತೆ, ಗೆರೆಯನ್ನು ಹೆಚ್ಚಿಸಿ.
ಆದರೆ ಇಲ್ಲಿ ಒಂದು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವಿದೆ. ಅದು ಏನೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಎಳೆಗಳನ್ನು ಹೇಗೆ ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಬೇಕು.
ಥ್ರೆಡ್ಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಮೊದಲ ಥ್ರೆಡ್ ಅನ್ನು ಮೊದಲು ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಆ ಥ್ರೆಡ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಒಪ್ಪಿಕೊಂಡಿರುವ ಕುಕೀಯನ್ನು ಬಳಸಿಕೊಂಡು ನಂತರದ ಥ್ರೆಡ್ಗಳನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ. ಮತ್ತು ಇಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ.
ಸಮಸ್ಯೆಯೆಂದರೆ ಮೊದಲ ಥ್ರೆಡ್ ಸ್ವತಃ ಸ್ಥಾಪಿಸದಿದ್ದರೆ, ಎರಡನೆಯ ಮತ್ತು ಮೂರನೇ ಎಳೆಗಳು ಎಂದಿಗೂ ಉದ್ಭವಿಸುವುದಿಲ್ಲ. ಅಂದರೆ, ಮಲ್ಟಿಪಾತ್ TCP ಮೊದಲ ಹರಿವಿನಲ್ಲಿ SYN ಪ್ಯಾಕೆಟ್ ನಷ್ಟವನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ. ಮತ್ತು SYN ಕಳೆದುಹೋದರೆ, ಮಲ್ಟಿಪಾತ್ TCP ಸಾಮಾನ್ಯ TCP ಆಗಿ ಬದಲಾಗುತ್ತದೆ. ಇದರರ್ಥ ಡೇಟಾ ಸೆಂಟರ್ ಪರಿಸರದಲ್ಲಿ ಕಾರ್ಖಾನೆಯಲ್ಲಿನ ನಷ್ಟದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಮತ್ತು ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಬಹು ಮಾರ್ಗಗಳನ್ನು ಬಳಸಲು ಕಲಿಯಲು ಇದು ನಮಗೆ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.
ನಮಗೆ ಏನು ಸಹಾಯ ಮಾಡಬಹುದು? ನಮ್ಮ ಮುಂದಿನ ಕಥೆಯಲ್ಲಿ ಪ್ರಮುಖ ಕ್ಷೇತ್ರವೆಂದರೆ IPv6 ಫ್ಲೋ ಲೇಬಲ್ ಹೆಡರ್ ಕ್ಷೇತ್ರ ಎಂದು ನಿಮ್ಮಲ್ಲಿ ಕೆಲವರು ಈಗಾಗಲೇ ಶೀರ್ಷಿಕೆಯಿಂದ ಊಹಿಸಿದ್ದಾರೆ. ವಾಸ್ತವವಾಗಿ, ಇದು v6 ನಲ್ಲಿ ಕಂಡುಬರುವ ಕ್ಷೇತ್ರವಾಗಿದೆ, ಇದು v4 ನಲ್ಲಿಲ್ಲ, ಇದು 20 ಬಿಟ್‌ಗಳನ್ನು ಆಕ್ರಮಿಸುತ್ತದೆ ಮತ್ತು ದೀರ್ಘಕಾಲದವರೆಗೆ ಅದರ ಬಳಕೆಯ ಬಗ್ಗೆ ವಿವಾದವಿದೆ. ಇದು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ - ವಿವಾದಗಳು ಇದ್ದವು, RFC ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಸರಿಪಡಿಸಲಾಗಿದೆ, ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ನಲ್ಲಿ ಒಂದು ಅನುಷ್ಠಾನವು ಕಾಣಿಸಿಕೊಂಡಿತು, ಅದನ್ನು ಎಲ್ಲಿಯೂ ದಾಖಲಿಸಲಾಗಿಲ್ಲ.
ಸ್ವಲ್ಪ ತನಿಖೆಗೆ ನನ್ನೊಂದಿಗೆ ಹೋಗಲು ನಾನು ನಿಮ್ಮನ್ನು ಆಹ್ವಾನಿಸುತ್ತೇನೆ. ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಿಂದ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ನಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.
ವರ್ಷ 2014. ಒಂದು ದೊಡ್ಡ ಮತ್ತು ಗೌರವಾನ್ವಿತ ಕಂಪನಿಯ ಎಂಜಿನಿಯರ್ ಸಾಕೆಟ್ ಹ್ಯಾಶ್‌ನಲ್ಲಿ ಫ್ಲೋ ಲೇಬಲ್ ಮೌಲ್ಯದ ಅವಲಂಬನೆಯನ್ನು ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ನ ಕ್ರಿಯಾತ್ಮಕತೆಗೆ ಸೇರಿಸುತ್ತಾರೆ. ಅವರು ಇಲ್ಲಿ ಏನು ಸರಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ? ಇದು RFC 6438 ಗೆ ಸಂಬಂಧಿಸಿದೆ, ಇದು ಈ ಕೆಳಗಿನ ಸಮಸ್ಯೆಯನ್ನು ಚರ್ಚಿಸಿದೆ. ಡೇಟಾ ಕೇಂದ್ರದ ಒಳಗೆ, IPv4 ಅನ್ನು ಹೆಚ್ಚಾಗಿ IPv6 ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ ಸುತ್ತುವರಿಯಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಕಾರ್ಖಾನೆಯೇ IPv6 ಆಗಿದೆ, ಆದರೆ IPv4 ಅನ್ನು ಹೇಗಾದರೂ ಹೊರಗೆ ನೀಡಬೇಕು. TCP ಅಥವಾ UDP ಗೆ ಹೋಗಲು ಮತ್ತು ಅಲ್ಲಿ src_ports, dst_ports ಅನ್ನು ಹುಡುಕಲು ಎರಡು IP ಹೆಡರ್‌ಗಳ ಅಡಿಯಲ್ಲಿ ನೋಡಲು ಸಾಧ್ಯವಾಗದ ಸ್ವಿಚ್‌ಗಳೊಂದಿಗೆ ದೀರ್ಘಕಾಲದವರೆಗೆ ಸಮಸ್ಯೆಗಳಿದ್ದವು. ಹ್ಯಾಶ್, ನೀವು ಮೊದಲ ಎರಡು ಐಪಿ ಹೆಡರ್‌ಗಳನ್ನು ನೋಡಿದರೆ, ಬಹುತೇಕ ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಇದನ್ನು ತಪ್ಪಿಸಲು, ಈ ಸುತ್ತುವರಿದ ದಟ್ಟಣೆಯ ಸಮತೋಲನವು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಫ್ಲೋ ಲೇಬಲ್ ಕ್ಷೇತ್ರದ ಮೌಲ್ಯಕ್ಕೆ 5-ಟುಪಲ್ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ಪ್ಯಾಕೆಟ್‌ನ ಹ್ಯಾಶ್ ಅನ್ನು ಸೇರಿಸಲು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ. ಸರಿಸುಮಾರು ಅದೇ ಕೆಲಸವನ್ನು ಇತರ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಯೋಜನೆಗಳಿಗೆ ಮಾಡಲಾಯಿತು, UDP ಗಾಗಿ, GRE ಗಾಗಿ, ಎರಡನೆಯದು GRE ಕೀ ಕ್ಷೇತ್ರವನ್ನು ಬಳಸಿತು. ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ, ಇಲ್ಲಿ ಗುರಿಗಳು ಸ್ಪಷ್ಟವಾಗಿವೆ. ಮತ್ತು ಕನಿಷ್ಠ ಆ ಸಮಯದಲ್ಲಿ ಅವು ಉಪಯುಕ್ತವಾಗಿವೆ.
2015 ರಲ್ಲಿ, ಅದೇ ಗೌರವಾನ್ವಿತ ಎಂಜಿನಿಯರ್‌ನಿಂದ ಹೊಸ ಪ್ಯಾಚ್ ಬರುತ್ತದೆ. ಅವನು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕ. ಇದು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಹೇಳುತ್ತದೆ - ನಕಾರಾತ್ಮಕ ರೂಟಿಂಗ್ ಘಟನೆಯ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಹ್ಯಾಶ್ ಅನ್ನು ಯಾದೃಚ್ಛಿಕಗೊಳಿಸುತ್ತೇವೆ. ನಕಾರಾತ್ಮಕ ರೂಟಿಂಗ್ ಈವೆಂಟ್ ಎಂದರೇನು? ಇದು ನಾವು ಮೊದಲೇ ಚರ್ಚಿಸಿದ ಆರ್‌ಟಿಒ, ಅಂದರೆ ಕಿಟಕಿಯ ಬಾಲವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ನಿಜವಾಗಿಯೂ ನಕಾರಾತ್ಮಕ ಘಟನೆಯಾಗಿದೆ. ನಿಜ, ಇದು ಎಂದು ಊಹಿಸಲು ತುಲನಾತ್ಮಕವಾಗಿ ಕಷ್ಟ.
2016, ಮತ್ತೊಂದು ಪ್ರತಿಷ್ಠಿತ ಕಂಪನಿ, ದೊಡ್ಡದು. ಇದು ಕೊನೆಯ ಊರುಗೋಲನ್ನು ಡಿಸ್ಅಸೆಂಬಲ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಾವು ಈ ಹಿಂದೆ ಯಾದೃಚ್ಛಿಕವಾಗಿ ಮಾಡಿದ ಹ್ಯಾಶ್ ಈಗ ಪ್ರತಿ SYN ಮರುಪ್ರಸಾರಕ್ಕೆ ಮತ್ತು ಪ್ರತಿ RTO ಅವಧಿ ಮುಗಿದ ನಂತರ ಬದಲಾಗುತ್ತದೆ. ಮತ್ತು ಈ ಪತ್ರದಲ್ಲಿ, ಮೊದಲ ಮತ್ತು ಕೊನೆಯ ಬಾರಿಗೆ, ಅಂತಿಮ ಗುರಿಯನ್ನು ಹೇಳಲಾಗಿದೆ - ನಷ್ಟಗಳು ಅಥವಾ ಚಾನಲ್ ದಟ್ಟಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ ದಟ್ಟಣೆಯನ್ನು ಮೃದುವಾಗಿ ಮರು-ಮಾರ್ಗಗೊಳಿಸುವ ಮತ್ತು ಬಹು ಮಾರ್ಗಗಳನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು. ಸಹಜವಾಗಿ, ಇದರ ನಂತರ ಬಹಳಷ್ಟು ಪ್ರಕಟಣೆಗಳು ಇದ್ದವು, ನೀವು ಅವುಗಳನ್ನು ಸುಲಭವಾಗಿ ಹುಡುಕಬಹುದು.
ಇಲ್ಲವಾದರೂ, ನಿಮಗೆ ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಈ ವಿಷಯದ ಬಗ್ಗೆ ಒಂದೇ ಒಂದು ಪ್ರಕಟಣೆ ಇಲ್ಲ. ಆದರೆ ನಮಗೆ ತಿಳಿದಿದೆ!
ಮತ್ತು ಏನು ಮಾಡಲಾಗಿದೆ ಎಂದು ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳದಿದ್ದರೆ, ನಾನು ಈಗ ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
ಏನು ಮಾಡಲಾಗಿದೆ, ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ಗೆ ಯಾವ ಕಾರ್ಯವನ್ನು ಸೇರಿಸಲಾಗಿದೆ? ಪ್ರತಿ RTO ಈವೆಂಟ್‌ನ ನಂತರ txhash ಯಾದೃಚ್ಛಿಕ ಮೌಲ್ಯಕ್ಕೆ ಬದಲಾಗುತ್ತದೆ. ಇದು ರೂಟಿಂಗ್‌ನ ಅತ್ಯಂತ ನಕಾರಾತ್ಮಕ ಫಲಿತಾಂಶವಾಗಿದೆ. ಹ್ಯಾಶ್ ಈ txhash ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ ಮತ್ತು ಹರಿವಿನ ಲೇಬಲ್ skb ಹ್ಯಾಶ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಇಲ್ಲಿ ಕಾರ್ಯಗಳ ಮೇಲೆ ಕೆಲವು ಲೆಕ್ಕಾಚಾರಗಳಿವೆ; ಎಲ್ಲಾ ವಿವರಗಳನ್ನು ಒಂದೇ ಸ್ಲೈಡ್‌ನಲ್ಲಿ ಇರಿಸಲಾಗುವುದಿಲ್ಲ. ಯಾರಾದರೂ ಕುತೂಹಲ ಹೊಂದಿದ್ದರೆ, ನೀವು ಕರ್ನಲ್ ಕೋಡ್ ಮೂಲಕ ಹೋಗಿ ಪರಿಶೀಲಿಸಬಹುದು.
ಇಲ್ಲಿ ಯಾವುದು ಮುಖ್ಯ? ಫ್ಲೋ ಲೇಬಲ್ ಕ್ಷೇತ್ರದ ಮೌಲ್ಯವು ಪ್ರತಿ RTO ನಂತರ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಗೆ ಬದಲಾಗುತ್ತದೆ. ಇದು ನಮ್ಮ ದುರದೃಷ್ಟಕರ TCP ಸ್ಟ್ರೀಮ್ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?
SACK ಸಂಭವಿಸಿದಲ್ಲಿ, ನಾವು ತಿಳಿದಿರುವ ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮರುಕಳುಹಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಕಾರಣ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಇಲ್ಲಿಯವರೆಗೆ ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ.
ಆದರೆ RTO ದ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ToR ನಲ್ಲಿ ಹ್ಯಾಶ್ ಫಂಕ್ಷನ್‌ಗೆ ಫ್ಲೋ ಲೇಬಲ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ, ಟ್ರಾಫಿಕ್ ಬೇರೆ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಮತ್ತು ಹೆಚ್ಚು ಲೇನ್‌ಗಳು, ನಿರ್ದಿಷ್ಟ ಸಾಧನದಲ್ಲಿ ವೈಫಲ್ಯದಿಂದ ಪ್ರಭಾವಿತವಾಗದ ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಳ್ಳುವ ಹೆಚ್ಚಿನ ಅವಕಾಶ.
ಒಂದು ಸಮಸ್ಯೆ ಉಳಿದಿದೆ - RTO. ಸಹಜವಾಗಿ, ಇನ್ನೊಂದು ಮಾರ್ಗವಿದೆ, ಆದರೆ ಇದಕ್ಕಾಗಿ ಸಾಕಷ್ಟು ಸಮಯ ವ್ಯರ್ಥವಾಗುತ್ತದೆ. 200 ಎಂಎಸ್ ಬಹಳಷ್ಟು ಆಗಿದೆ. ಎರಡನೆಯದು ಸಂಪೂರ್ಣವಾಗಿ ಕಾಡು. ಹಿಂದೆ, ಸೇವೆಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಸಮಯ ಮೀರುವಿಕೆಯ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡಿದ್ದೇನೆ. ಆದ್ದರಿಂದ, ಸೆಕೆಂಡ್ ಸಮಯ ಮೀರಿದೆ, ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ಸೇವೆಯಿಂದ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಇದರಲ್ಲಿ ಸೇವೆಯು ತುಲನಾತ್ಮಕವಾಗಿ ಸರಿಯಾಗಿರುತ್ತದೆ. ಇದಲ್ಲದೆ, ನಾನು ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ, ಆಧುನಿಕ ಡೇಟಾ ಕೇಂದ್ರದೊಳಗೆ ನಿಜವಾದ RTT ಸುಮಾರು 1 ಮಿಲಿಸೆಕೆಂಡ್ ಆಗಿದೆ.
ಆರ್‌ಟಿಒ ಅವಧಿ ಮೀರುವುದರೊಂದಿಗೆ ನೀವು ಏನು ಮಾಡಬಹುದು? ಡೇಟಾ ಪ್ಯಾಕೆಟ್‌ಗಳ ನಷ್ಟದ ಸಂದರ್ಭದಲ್ಲಿ RTO ಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಕಾಲಾವಧಿಯನ್ನು ಬಳಕೆದಾರರ ಸ್ಥಳದಿಂದ ತುಲನಾತ್ಮಕವಾಗಿ ಸುಲಭವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು: IP ಯುಟಿಲಿಟಿ ಇದೆ, ಮತ್ತು ಅದರ ಒಂದು ನಿಯತಾಂಕವು ಅದೇ rto_min ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. RTO, ಸಹಜವಾಗಿ, ಜಾಗತಿಕವಾಗಿ ಸರಿಹೊಂದಿಸಬೇಕಾಗಿಲ್ಲ ಎಂದು ಪರಿಗಣಿಸಿ, ಆದರೆ ನೀಡಿರುವ ಪೂರ್ವಪ್ರತ್ಯಯಗಳಿಗೆ, ಅಂತಹ ಕಾರ್ಯವಿಧಾನವು ಸಾಕಷ್ಟು ಕಾರ್ಯಸಾಧ್ಯವಾಗಿ ಕಾಣುತ್ತದೆ.
ನಿಜ, SYN_RTO ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಸ್ವಲ್ಪ ಕೆಟ್ಟದಾಗಿದೆ. ಇದು ಸ್ವಾಭಾವಿಕವಾಗಿ ಕೆಳಗೆ ಹೊಡೆಯಲ್ಪಟ್ಟಿದೆ. ಕರ್ನಲ್ 1 ಸೆಕೆಂಡಿನ ಸ್ಥಿರ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಅದು ಇಲ್ಲಿದೆ. ಬಳಕೆದಾರರ ಸ್ಥಳದಿಂದ ನೀವು ಅಲ್ಲಿಗೆ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ. ಒಂದೇ ದಾರಿ ಇದೆ.
eBPF ರಕ್ಷಣೆಗೆ ಬರುತ್ತದೆ. ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಇವುಗಳು ಸಣ್ಣ ಸಿ ಪ್ರೋಗ್ರಾಂಗಳಾಗಿವೆ, ಅವುಗಳನ್ನು ಕರ್ನಲ್ ಸ್ಟಾಕ್ ಮತ್ತು ಟಿಸಿಪಿ ಸ್ಟಾಕ್ನ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯಲ್ಲಿ ವಿವಿಧ ಸ್ಥಳಗಳಲ್ಲಿ ಕೊಕ್ಕೆಗಳಲ್ಲಿ ಸೇರಿಸಬಹುದು, ಅದರೊಂದಿಗೆ ನೀವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬದಲಾಯಿಸಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ, eBPF ದೀರ್ಘಾವಧಿಯ ಪ್ರವೃತ್ತಿಯಾಗಿದೆ. ಡಜನ್‌ಗಟ್ಟಲೆ ಹೊಸ sysctl ನಿಯತಾಂಕಗಳನ್ನು ಕತ್ತರಿಸುವ ಮತ್ತು IP ಉಪಯುಕ್ತತೆಯನ್ನು ವಿಸ್ತರಿಸುವ ಬದಲು, ಚಲನೆಯು eBPF ಕಡೆಗೆ ಚಲಿಸುತ್ತಿದೆ ಮತ್ತು ಅದರ ಕಾರ್ಯವನ್ನು ವಿಸ್ತರಿಸುತ್ತಿದೆ. eBPF ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನೀವು ದಟ್ಟಣೆ ನಿಯಂತ್ರಣಗಳು ಮತ್ತು ಇತರ TCP ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಬದಲಾಯಿಸಬಹುದು.
ಆದರೆ SYN_RTO ಮೌಲ್ಯಗಳನ್ನು ಬದಲಾಯಿಸಲು ಇದನ್ನು ಬಳಸಬಹುದು ಎಂಬುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ. ಇದಲ್ಲದೆ, ಸಾರ್ವಜನಿಕವಾಗಿ ಪೋಸ್ಟ್ ಮಾಡಿದ ಉದಾಹರಣೆ ಇದೆ: . ಇಲ್ಲಿ ಏನು ಮಾಡಲಾಗಿದೆ? ಉದಾಹರಣೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಆದರೆ ಸ್ವತಃ ತುಂಬಾ ಒರಟಾಗಿರುತ್ತದೆ. ಡೇಟಾ ಕೇಂದ್ರದ ಒಳಗೆ ನಾವು ಮೊದಲ 44 ಬಿಟ್‌ಗಳನ್ನು ಹೋಲಿಸುತ್ತೇವೆ ಎಂದು ಇಲ್ಲಿ ಭಾವಿಸಲಾಗಿದೆ; ಅವು ಹೊಂದಾಣಿಕೆಯಾದರೆ, ನಾವು ಡೇಟಾ ಕೇಂದ್ರದೊಳಗೆ ಇರುತ್ತೇವೆ. ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು SYN_RTO ಅವಧಿ ಮೀರುವ ಮೌಲ್ಯವನ್ನು 4ms ಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ. ಅದೇ ಕೆಲಸವನ್ನು ಹೆಚ್ಚು ನಾಜೂಕಾಗಿ ಮಾಡಬಹುದು. ಆದರೆ ಈ ಸರಳ ಉದಾಹರಣೆಯು ಇದು ಸಾಧ್ಯ ಎಂದು ತೋರಿಸುತ್ತದೆ; ಬಿ) ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳ.
ನಮಗೆ ಈಗಾಗಲೇ ಏನು ತಿಳಿದಿದೆ? ಪ್ಲೇನ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಸ್ಕೇಲಿಂಗ್‌ಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ ಎಂಬ ಅಂಶವೆಂದರೆ, ನಾವು ToR ನಲ್ಲಿ ಫ್ಲೋ ಲೇಬಲ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ ಮತ್ತು ಸಮಸ್ಯೆಯ ಪ್ರದೇಶಗಳ ಸುತ್ತಲೂ ಹರಿಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಪಡೆದಾಗ ಅದು ನಮಗೆ ಅತ್ಯಂತ ಉಪಯುಕ್ತವಾಗಿದೆ. RTO ಮತ್ತು SYN-RTO ಮೌಲ್ಯಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಉತ್ತಮ ಮಾರ್ಗವೆಂದರೆ eBPF ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ಬಳಸುವುದು. ಪ್ರಶ್ನೆ ಉಳಿದಿದೆ: ಸಮತೋಲನಕ್ಕಾಗಿ ಫ್ಲೋ ಲೇಬಲ್ ಅನ್ನು ಬಳಸುವುದು ಸುರಕ್ಷಿತವೇ? ಮತ್ತು ಇಲ್ಲಿ ಒಂದು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವಿದೆ.
ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ನೀವು ಯಾವುದಾದರೂ ಸೇವೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸೋಣ. ದುರದೃಷ್ಟವಶಾತ್, anycast ಎಂದರೇನು ಎಂಬುದರ ಕುರಿತು ವಿವರವಾಗಿ ಹೋಗಲು ನನಗೆ ಸಮಯವಿಲ್ಲ, ಆದರೆ ಇದು ಒಂದೇ IP ವಿಳಾಸದ ಮೂಲಕ ಪ್ರವೇಶಿಸಬಹುದಾದ ವಿವಿಧ ಭೌತಿಕ ಸರ್ವರ್ಗಳೊಂದಿಗೆ ವಿತರಿಸಲಾದ ಸೇವೆಯಾಗಿದೆ. ಮತ್ತು ಇಲ್ಲಿ ಸಂಭವನೀಯ ಸಮಸ್ಯೆ ಇದೆ: ಟ್ರಾಫಿಕ್ ಫ್ಯಾಬ್ರಿಕ್ ಮೂಲಕ ಹಾದುಹೋದಾಗ ಮಾತ್ರ RTO ಈವೆಂಟ್ ಸಂಭವಿಸಬಹುದು. ಇದು ToR ಬಫರ್ ಮಟ್ಟದಲ್ಲಿ ಸಹ ಸಂಭವಿಸಬಹುದು: ಇನ್‌ಕ್ಯಾಸ್ಟ್ ಈವೆಂಟ್ ಸಂಭವಿಸಿದಾಗ, ಹೋಸ್ಟ್ ಏನನ್ನಾದರೂ ಚೆಲ್ಲಿದಾಗ ಅದು ಹೋಸ್ಟ್‌ನಲ್ಲಿಯೂ ಸಹ ಸಂಭವಿಸಬಹುದು. RTO ಈವೆಂಟ್ ಸಂಭವಿಸಿದಾಗ ಮತ್ತು ಅದು ಹರಿವಿನ ಲೇಬಲ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಟ್ರಾಫಿಕ್ ಮತ್ತೊಂದು ಯಾವುದೇ ಕಾಸ್ಟ್ ನಿದರ್ಶನಕ್ಕೆ ಹೋಗಬಹುದು. ಇದು ಸ್ಟೇಟ್‌ಫುಲ್ ಅನಿಕಾಸ್ಟ್ ಎಂದು ಭಾವಿಸೋಣ, ಇದು ಸಂಪರ್ಕ ಸ್ಥಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ - ಇದು L3 ಬ್ಯಾಲೆನ್ಸರ್ ಅಥವಾ ಇತರ ಸೇವೆಯಾಗಿರಬಹುದು. ನಂತರ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ, ಏಕೆಂದರೆ RTO ನಂತರ TCP ಸಂಪರ್ಕವು ಸರ್ವರ್‌ಗೆ ಬರುತ್ತದೆ, ಅದು ಈ TCP ಸಂಪರ್ಕದ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ. ಮತ್ತು ನಾವು ಯಾವುದೇ ಕಾಸ್ಟ್ ಸರ್ವರ್‌ಗಳ ನಡುವೆ ರಾಜ್ಯ ಹಂಚಿಕೆಯನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಅಂತಹ ದಟ್ಟಣೆಯನ್ನು ಕೈಬಿಡಲಾಗುತ್ತದೆ ಮತ್ತು TCP ಸಂಪರ್ಕವು ಮುರಿದುಹೋಗುತ್ತದೆ.
ನೀವು ಇಲ್ಲಿ ಏನು ಮಾಡಬಹುದು? ನಿಮ್ಮ ನಿಯಂತ್ರಿತ ಪರಿಸರದಲ್ಲಿ, ನೀವು ಫ್ಲೋ ಲೇಬಲ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ, ಯಾವುದೇ ಕಾಸ್ಟ್ ಸರ್ವರ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸುವಾಗ ನೀವು ಫ್ಲೋ ಲೇಬಲ್‌ನ ಮೌಲ್ಯವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಅದೇ eBPF ಪ್ರೋಗ್ರಾಂ ಮೂಲಕ ಇದನ್ನು ಮಾಡುವುದು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಆದರೆ ಇಲ್ಲಿ ಬಹಳ ಮುಖ್ಯವಾದ ಅಂಶವಿದೆ - ನೀವು ಡೇಟಾ ಸೆಂಟರ್ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ನಿರ್ವಹಿಸದಿದ್ದರೆ, ಆದರೆ ಟೆಲಿಕಾಂ ಆಪರೇಟರ್ ಆಗಿದ್ದರೆ ಏನು ಮಾಡಬೇಕು? ಇದು ನಿಮ್ಮ ಸಮಸ್ಯೆಯೂ ಆಗಿದೆ: ಜುನಿಪರ್ ಮತ್ತು ಅರಿಸ್ಟಾದ ಕೆಲವು ಆವೃತ್ತಿಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಅವರು ತಮ್ಮ ಹ್ಯಾಶ್ ಕಾರ್ಯಗಳಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಫ್ಲೋ ಲೇಬಲ್ ಅನ್ನು ಸೇರಿಸುತ್ತಾರೆ - ಸ್ಪಷ್ಟವಾಗಿ, ನನಗೆ ಅಸ್ಪಷ್ಟವಾದ ಕಾರಣಕ್ಕಾಗಿ. ಇದು ನಿಮ್ಮ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಹಾದುಹೋಗುವ ಬಳಕೆದಾರರಿಂದ TCP ಸಂಪರ್ಕಗಳನ್ನು ಬಿಡಲು ಕಾರಣವಾಗಬಹುದು. ಹಾಗಾಗಿ ನಿಮ್ಮ ರೂಟರ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಇಲ್ಲಿ ಪರಿಶೀಲಿಸಲು ನಾನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ, ನಾವು ಪ್ರಯೋಗಗಳಿಗೆ ಹೋಗಲು ಸಿದ್ಧರಿದ್ದೇವೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ.
ನಾವು ToR ನಲ್ಲಿ ಫ್ಲೋ ಲೇಬಲ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ, eBPF ಏಜೆಂಟ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ, ಅದು ಈಗ ಅತಿಥೇಯಗಳ ಮೇಲೆ ವಾಸಿಸುತ್ತಿದೆ, ನಾವು ಮುಂದಿನ ದೊಡ್ಡ ವೈಫಲ್ಯಕ್ಕಾಗಿ ಕಾಯದೆ, ಆದರೆ ನಿಯಂತ್ರಿತ ಸ್ಫೋಟಗಳನ್ನು ನಡೆಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ನಾವು ನಾಲ್ಕು ಅಪ್‌ಲಿಂಕ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ToR ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಡ್ರಾಪ್‌ಗಳನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ. ಅವರು ನಿಯಮವನ್ನು ಎಳೆದು ಹೇಳಿದರು - ಈಗ ನೀವು ಎಲ್ಲಾ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಿದ್ದೀರಿ. ನೀವು ಎಡಭಾಗದಲ್ಲಿ ನೋಡುವಂತೆ, ನಾವು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದು 75% ಕ್ಕೆ ಇಳಿದಿದೆ, ಅಂದರೆ, 25% ಪ್ಯಾಕೆಟ್ಗಳು ಕಳೆದುಹೋಗಿವೆ. ಬಲಭಾಗದಲ್ಲಿ ಈ ToR ಹಿಂದೆ ವಾಸಿಸುವ ಸೇವೆಗಳ ಗ್ರಾಫ್‌ಗಳಿವೆ. ಮೂಲಭೂತವಾಗಿ, ಇವುಗಳು ರಾಕ್ ಒಳಗೆ ಸರ್ವರ್ಗಳೊಂದಿಗೆ ಇಂಟರ್ಫೇಸ್ಗಳ ಟ್ರಾಫಿಕ್ ಗ್ರಾಫ್ಗಳಾಗಿವೆ. ನೀವು ನೋಡುವಂತೆ, ಅವರು ಇನ್ನೂ ಕೆಳಕ್ಕೆ ಮುಳುಗಿದರು. ಅವರು ಏಕೆ ಕಡಿಮೆ ಮಾಡಿದರು - 25% ಅಲ್ಲ, ಆದರೆ ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ 3-4 ಬಾರಿ? TCP ಸಂಪರ್ಕವು ದುರದೃಷ್ಟಕರವಾಗಿದ್ದರೆ, ಅದು ಮುರಿದ ಜಂಕ್ಷನ್ ಮೂಲಕ ತಲುಪಲು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. DC ಯೊಳಗಿನ ಸೇವೆಯ ವಿಶಿಷ್ಟ ನಡವಳಿಕೆಯಿಂದ ಇದು ಉಲ್ಬಣಗೊಂಡಿದೆ - ಒಂದು ಬಳಕೆದಾರರ ವಿನಂತಿಗಾಗಿ, ಆಂತರಿಕ ಸೇವೆಗಳಿಗೆ N ವಿನಂತಿಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಡೇಟಾ ಮೂಲಗಳು ಪ್ರತಿಕ್ರಿಯಿಸಿದಾಗ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಸಮಯ ಮೀರಿದಾಗ ಪ್ರತಿಕ್ರಿಯೆಯು ಬಳಕೆದಾರರಿಗೆ ಹೋಗುತ್ತದೆ. ಮಟ್ಟ, ಇದು ಇನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿದೆ. ಅಂದರೆ, ಎಲ್ಲವೂ ತುಂಬಾ ಕೆಟ್ಟದಾಗಿದೆ.
ಈಗ ಅದೇ ಪ್ರಯೋಗ, ಆದರೆ ಫ್ಲೋ ಲೇಬಲ್ ಮೌಲ್ಯವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ. ನೀವು ನೋಡುವಂತೆ, ಎಡಭಾಗದಲ್ಲಿ ನಮ್ಮ ಬ್ಯಾಚ್ ಮಾನಿಟರಿಂಗ್ ಅದೇ 25% ರಷ್ಟು ಕಡಿಮೆಯಾಗಿದೆ. ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಸರಿಯಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಮರುಪ್ರಸಾರಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ತಿಳಿದಿಲ್ಲ, ಇದು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ವಿತರಿಸಿದ ಮತ್ತು ಕಳೆದುಹೋದ ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಂಖ್ಯೆಯ ಅನುಪಾತವನ್ನು ಸರಳವಾಗಿ ಎಣಿಸುತ್ತದೆ.
ಮತ್ತು ಬಲಭಾಗದಲ್ಲಿ ಸೇವಾ ವೇಳಾಪಟ್ಟಿ ಇದೆ. ಸಮಸ್ಯಾತ್ಮಕ ಜಂಟಿ ಪರಿಣಾಮವನ್ನು ನೀವು ಇಲ್ಲಿ ಕಾಣುವುದಿಲ್ಲ. ಅದೇ ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ, ಸಮಸ್ಯೆಯ ಪ್ರದೇಶದಿಂದ ಸಮಸ್ಯೆಯಿಂದ ಪ್ರಭಾವಿತವಾಗದ ಉಳಿದಿರುವ ಮೂರು ಅಪ್‌ಲಿಂಕ್‌ಗಳಿಗೆ ಸಂಚಾರವು ಹರಿಯಿತು. ನಾವು ಸ್ವತಃ ಗುಣಪಡಿಸುವ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಇದು ನನ್ನ ಕೊನೆಯ ಸ್ಲೈಡ್, ಸಾರಾಂಶದ ಸಮಯ. ಈಗ, ಸ್ವಯಂ-ಗುಣಪಡಿಸುವ ಡೇಟಾ ಸೆಂಟರ್ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುವುದು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನೀವು ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಆರ್ಕೈವ್ ಮೂಲಕ ಹೋಗಿ ಅಲ್ಲಿ ವಿಶೇಷ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಹುಡುಕುವ ಅಗತ್ಯವಿಲ್ಲ; ಈ ಸಂದರ್ಭದಲ್ಲಿ ಫ್ಲೋ ಲೇಬಲ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ, ಆದರೆ ನೀವು ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಸಂಪರ್ಕಿಸಬೇಕು. ಮತ್ತು ನೀವು ಟೆಲಿಕಾಂ ಆಪರೇಟರ್ ಆಗಿದ್ದರೆ, ನೀವು ಫ್ಲೋ ಲೇಬಲ್ ಅನ್ನು ಹ್ಯಾಶ್ ಕಾರ್ಯವಾಗಿ ಬಳಸಬಾರದು ಎಂದು ನಾನು ಮತ್ತೊಮ್ಮೆ ಒತ್ತಿಹೇಳುತ್ತೇನೆ, ಇಲ್ಲದಿದ್ದರೆ ನಿಮ್ಮ ಬಳಕೆದಾರರ ಸೆಷನ್‌ಗಳನ್ನು ನೀವು ಅಡ್ಡಿಪಡಿಸುತ್ತೀರಿ.
ನೆಟ್ವರ್ಕ್ ಎಂಜಿನಿಯರ್‌ಗಳು ಪರಿಕಲ್ಪನಾ ಬದಲಾವಣೆಗೆ ಒಳಗಾಗಬೇಕು: ನೆಟ್ವರ್ಕ್ ಪ್ರಾರಂಭವಾಗುವುದು ToR ನೊಂದಿಗೆ ಅಲ್ಲ, ನೆಟ್ವರ್ಕ್ ಸಾಧನದೊಂದಿಗೆ ಅಲ್ಲ, ಆದರೆ ಹೋಸ್ಟ್‌ನೊಂದಿಗೆ. RTO ಅನ್ನು ಬದಲಾಯಿಸಲು ಮತ್ತು ಯಾವುದೇ ಕಾಸ್ಟ್ ಸೇವೆಗಳ ಕಡೆಗೆ ಫ್ಲೋ ಲೇಬಲ್ ಅನ್ನು ಸರಿಪಡಿಸಲು ನಾವು eBPF ಅನ್ನು ಹೇಗೆ ಬಳಸುತ್ತೇವೆ ಎಂಬುದು ಸಾಕಷ್ಟು ಗಮನಾರ್ಹ ಉದಾಹರಣೆಯಾಗಿದೆ.
ಫ್ಲೋ ಲೇಬಲ್ ಮೆಕ್ಯಾನಿಕ್ಸ್ ನಿಯಂತ್ರಿತ ಆಡಳಿತ ವಿಭಾಗದ ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಖಂಡಿತವಾಗಿಯೂ ಸೂಕ್ತವಾಗಿದೆ. ಇದು ಡೇಟಾ ಕೇಂದ್ರಗಳ ನಡುವಿನ ದಟ್ಟಣೆಯಾಗಿರಬಹುದು ಅಥವಾ ಹೊರಹೋಗುವ ದಟ್ಟಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ನೀವು ಅಂತಹ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ವಿಶೇಷ ರೀತಿಯಲ್ಲಿ ಬಳಸಬಹುದು. ಆದರೆ ಈ ಬಗ್ಗೆ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ, ಮುಂದಿನ ಬಾರಿ ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನೀವು ಗಮನಹರಿಸಿದ್ದಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು.
ಮೂಲ: www.habr.com