🥇ಕೆಲಸದ ಸುತ್ತುಗಳನ್ನು ತರುವ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಎಚ್ಚರದಿಂದಿರಿ. ಭಾಗ 1: FragmentSmack/SegmentSmack

ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಡಿಮಿಟ್ರಿ ಸ್ಯಾಮ್ಸೊನೊವ್, ನಾನು ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಯಲ್ಲಿ ಪ್ರಮುಖ ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ನಾವು 7 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಭೌತಿಕ ಸರ್ವರ್‌ಗಳು, ನಮ್ಮ ಕ್ಲೌಡ್‌ನಲ್ಲಿ 11 ಸಾವಿರ ಕಂಟೈನರ್‌ಗಳು ಮತ್ತು 200 ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇದು ವಿವಿಧ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಲ್ಲಿ 700 ವಿಭಿನ್ನ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ರೂಪಿಸುತ್ತದೆ. ಬಹುಪಾಲು ಸರ್ವರ್‌ಗಳು CentOS 7 ಅನ್ನು ರನ್ ಮಾಡುತ್ತವೆ.
ಆಗಸ್ಟ್ 14, 2018 ರಂದು, FragmentSmack ದುರ್ಬಲತೆಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪ್ರಕಟಿಸಲಾಗಿದೆ
(CVE-2018-5391) ಮತ್ತು ಸೆಗ್ಮೆಂಟ್ಸ್ಮ್ಯಾಕ್ (CVE-2018-5390) ಇವುಗಳು ನೆಟ್‌ವರ್ಕ್ ಅಟ್ಯಾಕ್ ವೆಕ್ಟರ್ ಮತ್ತು ಸಾಕಷ್ಟು ಹೆಚ್ಚಿನ ಸ್ಕೋರ್‌ನೊಂದಿಗೆ ದುರ್ಬಲತೆಗಳಾಗಿವೆ (7.5), ಇದು ಸಂಪನ್ಮೂಲದ ನಿಶ್ಯಕ್ತಿ (ಸಿಪಿಯು) ಕಾರಣದಿಂದಾಗಿ ಸೇವೆಯ ನಿರಾಕರಣೆ (DoS) ಗೆ ಬೆದರಿಕೆ ಹಾಕುತ್ತದೆ. ಆ ಸಮಯದಲ್ಲಿ FragmentSmack ಗಾಗಿ ಕರ್ನಲ್ ಫಿಕ್ಸ್ ಅನ್ನು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿಲ್ಲ; ಮೇಲಾಗಿ, ಇದು ದುರ್ಬಲತೆಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯ ಪ್ರಕಟಣೆಗಿಂತ ಹೆಚ್ಚು ನಂತರ ಹೊರಬಂದಿತು. SegmentSmack ಅನ್ನು ತೊಡೆದುಹಾಕಲು, ಕರ್ನಲ್ ಅನ್ನು ನವೀಕರಿಸಲು ಸೂಚಿಸಲಾಗಿದೆ. ನವೀಕರಣ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಅದೇ ದಿನದಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಲಾಯಿತು, ಅದನ್ನು ಸ್ಥಾಪಿಸಲು ಮಾತ್ರ ಉಳಿದಿದೆ.
ಇಲ್ಲ, ನಾವು ಕರ್ನಲ್ ಅನ್ನು ನವೀಕರಿಸುವುದನ್ನು ವಿರೋಧಿಸುವುದಿಲ್ಲ! ಆದಾಗ್ಯೂ, ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ ...

ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಾವು ಕರ್ನಲ್ ಅನ್ನು ಹೇಗೆ ನವೀಕರಿಸುತ್ತೇವೆ

ಸಾಮಾನ್ಯವಾಗಿ, ಏನೂ ಸಂಕೀರ್ಣವಾಗಿಲ್ಲ:

ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ;
ಅವುಗಳನ್ನು ಹಲವಾರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸ್ಥಾಪಿಸಿ (ನಮ್ಮ ಕ್ಲೌಡ್ ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಸರ್ವರ್‌ಗಳು ಸೇರಿದಂತೆ);
ಏನೂ ಮುರಿದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ;
ಎಲ್ಲಾ ಪ್ರಮಾಣಿತ ಕರ್ನಲ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ದೋಷಗಳಿಲ್ಲದೆ ಅನ್ವಯಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ;
ಸ್ವಲ್ಪ ದಿನ ಕಾಯಿರಿ;
ಸರ್ವರ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ;
ಹೊಸ ಸರ್ವರ್‌ಗಳ ನಿಯೋಜನೆಯನ್ನು ಹೊಸ ಕರ್ನಲ್‌ಗೆ ಬದಲಾಯಿಸಿ;
ಡೇಟಾ ಕೇಂದ್ರದ ಮೂಲಕ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳನ್ನು ನವೀಕರಿಸಿ (ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಬಳಕೆದಾರರ ಮೇಲೆ ಪರಿಣಾಮವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ಡೇಟಾ ಕೇಂದ್ರ);
ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳನ್ನು ರೀಬೂಟ್ ಮಾಡಿ.

ನಾವು ಹೊಂದಿರುವ ಕರ್ನಲ್‌ಗಳ ಎಲ್ಲಾ ಶಾಖೆಗಳಿಗೆ ಪುನರಾವರ್ತಿಸಿ. ಈ ಸಮಯದಲ್ಲಿ ಅದು:

ಸ್ಟಾಕ್ CentOS 7 3.10 - ಹೆಚ್ಚಿನ ಸಾಮಾನ್ಯ ಸರ್ವರ್‌ಗಳಿಗೆ;
ವೆನಿಲ್ಲಾ 4.19 - ನಮಗಾಗಿ ಒಂದು ಮೋಡದ ಮೋಡಗಳು, ಏಕೆಂದರೆ ನಮಗೆ BFQ, BBR, ಇತ್ಯಾದಿ.
ಎಲ್ರೆಪೋ ಕರ್ನಲ್-ಮಿಲಿ 5.2 - ಫಾರ್ ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ವಿತರಕರು, ಏಕೆಂದರೆ 4.19 ಅಸ್ಥಿರವಾಗಿ ವರ್ತಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅದೇ ವೈಶಿಷ್ಟ್ಯಗಳು ಅಗತ್ಯವಿದೆ.

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

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

FragmentSmack/SegmentSmack. ಪರಿಹಾರೋಪಾಯ

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

FragmentSmack/SegmentSmack ಸಂದರ್ಭದಲ್ಲಿ ಪ್ರಸ್ತಾಪಿಸಲಾಯಿತು ಈ ಪರಿಹಾರ:

«ನೀವು net.ipv4.ipfrag_high_thresh ಮತ್ತು net.ipv3.ipfrag_low_thresh (ಮತ್ತು ipv4 net.ipv4.ipfrag_high_thresh ಮತ್ತು net.ipv6.ipfrag_low_thresh ಮತ್ತು net.ipv6.ipfrag_low_thresh ಮತ್ತು net.ipv6.ipfrag_low_thresh ಗಾಗಿ ಅವುಗಳ ಕೌಂಟರ್ಪಾರ್ಟ್ಸ್) 256MB ಮತ್ತು 192MB ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳನ್ನು kBB ಅಥವಾ 262144 kB ಗೆ ಬದಲಾಯಿಸಬಹುದು ಕಡಿಮೆ. ಹಾರ್ಡ್‌ವೇರ್, ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಷರತ್ತುಗಳನ್ನು ಅವಲಂಬಿಸಿ ದಾಳಿಯ ಸಮಯದಲ್ಲಿ ಸಿಪಿಯು ಬಳಕೆಯಲ್ಲಿ ಸಣ್ಣದಿಂದ ಗಮನಾರ್ಹವಾದ ಕುಸಿತಗಳನ್ನು ಪರೀಕ್ಷೆಗಳು ತೋರಿಸುತ್ತವೆ. ಆದಾಗ್ಯೂ, ipfrag_high_thresh=64 ಬೈಟ್‌ಗಳ ಕಾರಣದಿಂದಾಗಿ ಕೆಲವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರಿಣಾಮವಿರಬಹುದು, ಏಕೆಂದರೆ ಒಂದು ಸಮಯದಲ್ಲಿ ಕೇವಲ ಎರಡು XNUMXK ತುಣುಕುಗಳು ಮರುಜೋಡಣೆ ಸರದಿಯಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ದೊಡ್ಡ UDP ಪ್ಯಾಕೆಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಒಡೆಯುವ ಅಪಾಯವಿದೆ».

ನಿಯತಾಂಕಗಳು ಸ್ವತಃ ಕರ್ನಲ್ ದಾಖಲಾತಿಯಲ್ಲಿ ಈ ಕೆಳಗಿನಂತೆ ವಿವರಿಸಲಾಗಿದೆ:

ipfrag_high_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments before the kernel begins to remove incomplete fragment queues to free up resources. The kernel still accepts new fragments for defragmentation.

ಉತ್ಪಾದನಾ ಸೇವೆಗಳಲ್ಲಿ ನಾವು ದೊಡ್ಡ UDP ಗಳನ್ನು ಹೊಂದಿಲ್ಲ. LAN ನಲ್ಲಿ ಯಾವುದೇ ವಿಘಟಿತ ದಟ್ಟಣೆ ಇಲ್ಲ; WAN ನಲ್ಲಿ ವಿಭಜಿತ ಟ್ರಾಫಿಕ್ ಇದೆ, ಆದರೆ ಗಮನಾರ್ಹವಲ್ಲ. ಯಾವುದೇ ಚಿಹ್ನೆಗಳಿಲ್ಲ - ನೀವು ಪರಿಹಾರವನ್ನು ಹೊರತರಬಹುದು!

FragmentSmack/SegmentSmack. ಮೊದಲ ರಕ್ತ

ನಾವು ಎದುರಿಸಿದ ಮೊದಲ ಸಮಸ್ಯೆ ಎಂದರೆ ಕ್ಲೌಡ್ ಕಂಟೇನರ್‌ಗಳು ಕೆಲವೊಮ್ಮೆ ಹೊಸ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಭಾಗಶಃ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತವೆ (ಕೇವಲ ipfrag_low_thresh), ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಅವುಗಳನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲ - ಅವು ಪ್ರಾರಂಭದಲ್ಲಿ ಸರಳವಾಗಿ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತವೆ. ಸಮಸ್ಯೆಯನ್ನು ಸ್ಥಿರವಾಗಿ ಪುನರುತ್ಪಾದಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ (ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದೆ ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಅನ್ವಯಿಸಲಾಗಿದೆ). ಪ್ರಾರಂಭದಲ್ಲಿ ಕಂಟೇನರ್ ಏಕೆ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ತುಂಬಾ ಸುಲಭವಲ್ಲ: ಯಾವುದೇ ದೋಷಗಳು ಕಂಡುಬಂದಿಲ್ಲ. ಒಂದು ವಿಷಯ ಖಚಿತವಾಗಿತ್ತು: ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸುವುದು ಕಂಟೇನರ್ ಕ್ರ್ಯಾಶ್‌ಗಳ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

ಹೋಸ್ಟ್‌ನಲ್ಲಿ Sysctl ಅನ್ನು ಅನ್ವಯಿಸಲು ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ? ಕಂಟೇನರ್ ತನ್ನದೇ ಆದ ಮೀಸಲಾದ ನೆಟ್‌ವರ್ಕ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕನಿಷ್ಠ ನೆಟ್ವರ್ಕ್ Sysctl ನಿಯತಾಂಕಗಳ ಭಾಗ ಧಾರಕದಲ್ಲಿ ಹೋಸ್ಟ್‌ನಿಂದ ಭಿನ್ನವಾಗಿರಬಹುದು.

ಕಂಟೇನರ್‌ನಲ್ಲಿ Sysctl ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಎಷ್ಟು ನಿಖರವಾಗಿ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ? ನಮ್ಮ ಕಂಟೈನರ್‌ಗಳು ಸವಲತ್ತು ಹೊಂದಿಲ್ಲದ ಕಾರಣ, ಕಂಟೇನರ್‌ಗೆ ಹೋಗುವ ಮೂಲಕ ಯಾವುದೇ Sysctl ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ - ನೀವು ಸಾಕಷ್ಟು ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಕಂಟೇನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು, ಆ ಸಮಯದಲ್ಲಿ ನಮ್ಮ ಕ್ಲೌಡ್ ಡಾಕರ್ ಅನ್ನು ಬಳಸಿದೆ (ಈಗ ಪೋಡ್ಮನ್) ಅಗತ್ಯ Sysctl ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಒಳಗೊಂಡಂತೆ API ಮೂಲಕ ಹೊಸ ಕಂಟೇನರ್‌ನ ನಿಯತಾಂಕಗಳನ್ನು ಡಾಕರ್‌ಗೆ ರವಾನಿಸಲಾಗಿದೆ.
ಆವೃತ್ತಿಗಳ ಮೂಲಕ ಹುಡುಕುತ್ತಿರುವಾಗ, ಡಾಕರ್ API ಎಲ್ಲಾ ದೋಷಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲಿಲ್ಲ (ಕನಿಷ್ಠ ಆವೃತ್ತಿ 1.10 ರಲ್ಲಿ). ನಾವು "ಡಾಕರ್ ರನ್" ಮೂಲಕ ಕಂಟೇನರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ನಾವು ಅಂತಿಮವಾಗಿ ಕನಿಷ್ಠ ಏನನ್ನಾದರೂ ನೋಡಿದ್ದೇವೆ:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

ಪ್ಯಾರಾಮೀಟರ್ ಮೌಲ್ಯವು ಮಾನ್ಯವಾಗಿಲ್ಲ. ಆದರೆ ಯಾಕೆ? ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಮಾತ್ರ ಏಕೆ ಮಾನ್ಯವಾಗಿಲ್ಲ? Sysctl ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಅನ್ವಯಿಸುವ ಕ್ರಮವನ್ನು ಡಾಕರ್ ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ (ಇತ್ತೀಚಿನ ಪರೀಕ್ಷಿತ ಆವೃತ್ತಿ 1.13.1), ಆದ್ದರಿಂದ ಕೆಲವೊಮ್ಮೆ ipfrag_high_thresh ipfrag_low_thresh ಇನ್ನೂ 256M ಇದ್ದಾಗ 3K ಗೆ ಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸಿದೆ, ಅಂದರೆ, ಮೇಲಿನ ಮಿತಿಯು ಕಡಿಮೆಯಾಗಿದೆ ಕಡಿಮೆ ಮಿತಿಗಿಂತ, ಇದು ದೋಷಕ್ಕೆ ಕಾರಣವಾಯಿತು.

ಆ ಸಮಯದಲ್ಲಿ, ಪ್ರಾರಂಭದ ನಂತರ ಕಂಟೇನರ್ ಅನ್ನು ಮರುಸಂರಚಿಸಲು ನಾವು ಈಗಾಗಲೇ ನಮ್ಮದೇ ಆದ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿದ್ದೇವೆ (ನಂತರ ಕಂಟೇನರ್ ಅನ್ನು ಫ್ರೀಜ್ ಮಾಡುವುದು ಗುಂಪು ಫ್ರೀಜರ್ ಮತ್ತು ಮೂಲಕ ಕಂಟೇನರ್‌ನ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಆಜ್ಞೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಐಪಿ ನೆಟ್ನ್ಸ್), ಮತ್ತು ನಾವು ಈ ಭಾಗಕ್ಕೆ Sysctl ನಿಯತಾಂಕಗಳನ್ನು ಬರೆಯುವುದನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ಸಮಸ್ಯೆ ಪರಿಹಾರವಾಯಿತು.

FragmentSmack/SegmentSmack. ಮೊದಲ ರಕ್ತ 2

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

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

ಮೂರು ವಾರಗಳ ನಂತರ ಸಮಸ್ಯೆ ಮರುಕಳಿಸಿತು. ಈ ಸರ್ವರ್‌ಗಳ ಸಂರಚನೆಯು ತುಂಬಾ ಸರಳವಾಗಿತ್ತು: ಪ್ರಾಕ್ಸಿ/ಬ್ಯಾಲೆನ್ಸರ್ ಮೋಡ್‌ನಲ್ಲಿ Nginx. ಹೆಚ್ಚು ಟ್ರಾಫಿಕ್ ಇಲ್ಲ. ಹೊಸ ಪರಿಚಯಾತ್ಮಕ ಟಿಪ್ಪಣಿ: ಗ್ರಾಹಕರ ಮೇಲೆ 504 ದೋಷಗಳ ಸಂಖ್ಯೆ ಪ್ರತಿದಿನ ಹೆಚ್ಚುತ್ತಿದೆ (ಗೇಟ್ವೇ ಟೈಮ್ ಔಟ್) ಈ ಸೇವೆಗಾಗಿ ದಿನಕ್ಕೆ 504 ದೋಷಗಳ ಸಂಖ್ಯೆಯನ್ನು ಗ್ರಾಫ್ ತೋರಿಸುತ್ತದೆ:

ಎಲ್ಲಾ ದೋಷಗಳು ಒಂದೇ ಬ್ಯಾಕೆಂಡ್ ಬಗ್ಗೆ - ಕ್ಲೌಡ್‌ನಲ್ಲಿರುವ ಒಂದರ ಬಗ್ಗೆ. ಈ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಪ್ಯಾಕೇಜ್ ತುಣುಕುಗಳಿಗಾಗಿ ಮೆಮೊರಿ ಬಳಕೆ ಗ್ರಾಫ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಗ್ರಾಫ್ಗಳಲ್ಲಿನ ಸಮಸ್ಯೆಯ ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದ ಅಭಿವ್ಯಕ್ತಿಗಳಲ್ಲಿ ಇದು ಒಂದಾಗಿದೆ. ಕ್ಲೌಡ್‌ನಲ್ಲಿ, ಅದೇ ಸಮಯದಲ್ಲಿ, QoS (ಟ್ರಾಫಿಕ್ ಕಂಟ್ರೋಲ್) ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಮತ್ತೊಂದು ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ. ಪ್ಯಾಕೆಟ್ ತುಣುಕುಗಳಿಗಾಗಿ ಮೆಮೊರಿ ಬಳಕೆಯ ಗ್ರಾಫ್ನಲ್ಲಿ, ಇದು ನಿಖರವಾಗಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಊಹೆಯು ಸರಳವಾಗಿತ್ತು: ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ ಅವು ಒಂದೇ ರೀತಿ ಕಂಡುಬಂದರೆ, ಅವರಿಗೆ ಅದೇ ಕಾರಣವಿದೆ. ಇದಲ್ಲದೆ, ಈ ರೀತಿಯ ಮೆಮೊರಿಯೊಂದಿಗಿನ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳು ಅತ್ಯಂತ ಅಪರೂಪ.

ಸ್ಥಿರ ಸಮಸ್ಯೆಯ ಸಾರವೆಂದರೆ ನಾವು QoS ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ fq ಪ್ಯಾಕೆಟ್ ಶೆಡ್ಯೂಲರ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಒಂದು ಸಂಪರ್ಕಕ್ಕಾಗಿ, ಇದು ಸರದಿಯಲ್ಲಿ 100 ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸೇರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಮತ್ತು ಕೆಲವು ಸಂಪರ್ಕಗಳು, ಚಾನಲ್ ಕೊರತೆಯ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಕ್ಯೂ ಅನ್ನು ಮುಚ್ಚಲು ಪ್ರಾರಂಭಿಸಿದವು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕೈಬಿಡಲಾಗುತ್ತದೆ. tc ಅಂಕಿಅಂಶಗಳಲ್ಲಿ (tc -s qdisc) ಇದನ್ನು ಈ ರೀತಿ ಕಾಣಬಹುದು:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0) backlog 0b 0p requeues 0 1024 flows (1021 inactive, 0 throttled) 0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

“464545 flows_plimit” ಎಂಬುದು ಒಂದು ಸಂಪರ್ಕದ ಸರತಿ ಮಿತಿಯನ್ನು ಮೀರಿದ ಕಾರಣ ಕೈಬಿಡಲಾದ ಪ್ಯಾಕೆಟ್‌ಗಳು ಮತ್ತು “ಡ್ರಾಪ್ಡ್ 464545” ಎಂಬುದು ಈ ಶೆಡ್ಯೂಲರ್‌ನ ಎಲ್ಲಾ ಡ್ರಾಪ್ ಪ್ಯಾಕೆಟ್‌ಗಳ ಮೊತ್ತವಾಗಿದೆ. ಸರದಿಯ ಉದ್ದವನ್ನು 1 ಸಾವಿರಕ್ಕೆ ಹೆಚ್ಚಿಸಿದ ನಂತರ ಮತ್ತು ಕಂಟೇನರ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ಸಮಸ್ಯೆ ಸಂಭವಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿತು. ನೀವು ಹಿಂದೆ ಕುಳಿತು ಸ್ಮೂಥಿ ಕುಡಿಯಬಹುದು.

FragmentSmack/SegmentSmack. ಕೊನೆಯ ರಕ್ತ

ಮೊದಲನೆಯದಾಗಿ, ಕರ್ನಲ್‌ನಲ್ಲಿನ ದೋಷಗಳ ಪ್ರಕಟಣೆಯ ಹಲವಾರು ತಿಂಗಳ ನಂತರ, ಅಂತಿಮವಾಗಿ ಫ್ರಾಗ್‌ಮೆಂಟ್‌ಸ್ಮ್ಯಾಕ್‌ಗೆ ಫಿಕ್ಸ್ ಕಾಣಿಸಿಕೊಂಡಿತು (ಆಗಸ್ಟ್‌ನಲ್ಲಿ ಪ್ರಕಟಣೆಯ ಜೊತೆಗೆ, ಸೆಗ್ಮೆಂಟ್‌ಸ್ಮ್ಯಾಕ್‌ಗೆ ಮಾತ್ರ ಫಿಕ್ಸ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ), ಇದು ನಮಗೆ ಪರಿಹಾರವನ್ನು ತ್ಯಜಿಸಲು ಅವಕಾಶವನ್ನು ನೀಡಿತು, ಇದು ನಮಗೆ ಸಾಕಷ್ಟು ತೊಂದರೆ ಉಂಟುಮಾಡಿದೆ. ಈ ಸಮಯದಲ್ಲಿ, ನಾವು ಈಗಾಗಲೇ ಕೆಲವು ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಸ ಕರ್ನಲ್‌ಗೆ ವರ್ಗಾಯಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಈಗ ನಾವು ಮೊದಲಿನಿಂದ ಪ್ರಾರಂಭಿಸಬೇಕಾಗಿದೆ. FragmentSmack ಫಿಕ್ಸ್‌ಗಾಗಿ ಕಾಯದೆ ನಾವು ಕರ್ನಲ್ ಅನ್ನು ಏಕೆ ನವೀಕರಿಸಿದ್ದೇವೆ? ಸತ್ಯವೆಂದರೆ ಈ ದುರ್ಬಲತೆಗಳ ವಿರುದ್ಧ ರಕ್ಷಿಸುವ ಪ್ರಕ್ರಿಯೆಯು CentOS ಅನ್ನು ನವೀಕರಿಸುವ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ (ಮತ್ತು ವಿಲೀನಗೊಂಡಿದೆ) (ಇದು ಕೇವಲ ಕರ್ನಲ್ ಅನ್ನು ನವೀಕರಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ). ಹೆಚ್ಚುವರಿಯಾಗಿ, SegmentSmack ಹೆಚ್ಚು ಅಪಾಯಕಾರಿ ದುರ್ಬಲತೆಯಾಗಿದೆ, ಮತ್ತು ಅದರ ಪರಿಹಾರವು ತಕ್ಷಣವೇ ಕಾಣಿಸಿಕೊಂಡಿತು, ಆದ್ದರಿಂದ ಅದು ಹೇಗಾದರೂ ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ನಾವು CentOS ನಲ್ಲಿ ಕರ್ನಲ್ ಅನ್ನು ಸರಳವಾಗಿ ನವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಏಕೆಂದರೆ CentOS 7.5 ಸಮಯದಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡ FragmentSmack ದುರ್ಬಲತೆಯನ್ನು ಆವೃತ್ತಿ 7.6 ರಲ್ಲಿ ಮಾತ್ರ ಸರಿಪಡಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾವು ನವೀಕರಣವನ್ನು 7.5 ಗೆ ನಿಲ್ಲಿಸಬೇಕಾಗಿತ್ತು ಮತ್ತು 7.6 ಗೆ ನವೀಕರಣದೊಂದಿಗೆ ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಬೇಕಾಗಿತ್ತು. ಮತ್ತು ಇದು ಸಹ ಸಂಭವಿಸುತ್ತದೆ.

ಎರಡನೆಯದಾಗಿ, ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಅಪರೂಪದ ಬಳಕೆದಾರರ ದೂರುಗಳು ನಮಗೆ ಹಿಂತಿರುಗಿವೆ. ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ನಮ್ಮ ಕೆಲವು ಸರ್ವರ್‌ಗಳಿಗೆ ಫೈಲ್‌ಗಳ ಅಪ್‌ಲೋಡ್‌ಗೆ ಸಂಬಂಧಿಸಿವೆ ಎಂದು ಈಗ ನಮಗೆ ಖಚಿತವಾಗಿ ತಿಳಿದಿದೆ. ಇದಲ್ಲದೆ, ಒಟ್ಟು ದ್ರವ್ಯರಾಶಿಯಿಂದ ಬಹಳ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಅಪ್‌ಲೋಡ್‌ಗಳು ಈ ಸರ್ವರ್‌ಗಳ ಮೂಲಕ ಹೋದವು.

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

ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಅಂಕಿಅಂಶಗಳು ಮತ್ತು ದಾಖಲೆಗಳ ವಿಶ್ಲೇಷಣೆಯು ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಮಗೆ ಹತ್ತಿರವಾಗಲಿಲ್ಲ. ನಿರ್ದಿಷ್ಟ ಸಂಪರ್ಕವನ್ನು "ಅನುಭವಿಸಲು" ಸಮಸ್ಯೆಯನ್ನು ಪುನರುತ್ಪಾದಿಸುವ ಸಾಮರ್ಥ್ಯದ ತೀವ್ರ ಕೊರತೆಯಿದೆ. ಅಂತಿಮವಾಗಿ, ಡೆವಲಪರ್‌ಗಳು, ಅಪ್ಲಿಕೇಶನ್‌ನ ವಿಶೇಷ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಿಕೊಂಡು, Wi-Fi ಮೂಲಕ ಸಂಪರ್ಕಿಸಿದಾಗ ಪರೀಕ್ಷಾ ಸಾಧನದಲ್ಲಿ ಸಮಸ್ಯೆಗಳ ಸ್ಥಿರ ಪುನರುತ್ಪಾದನೆಯನ್ನು ಸಾಧಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರು. ತನಿಖೆಯಲ್ಲಿ ಇದೊಂದು ಮಹತ್ವದ ತಿರುವು. ನಮ್ಮ Java ಅಪ್ಲಿಕೇಶನ್‌ ಆಗಿದ್ದ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಪ್ರಾಕ್ಸಿ ಮಾಡಲಾದ Nginx ಗೆ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ.

ಸಮಸ್ಯೆಗಳ ಸಂವಾದವು ಹೀಗಿತ್ತು (Nginx ಪ್ರಾಕ್ಸಿ ಬದಿಯಲ್ಲಿ ನಿವಾರಿಸಲಾಗಿದೆ):

ಕ್ಲೈಂಟ್: ಫೈಲ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸಲು ವಿನಂತಿ.
ಜಾವಾ ಸರ್ವರ್: ಪ್ರತಿಕ್ರಿಯೆ.
ಗ್ರಾಹಕ: ಫೈಲ್‌ನೊಂದಿಗೆ ಪೋಸ್ಟ್ ಮಾಡಿ.
ಜಾವಾ ಸರ್ವರ್: ದೋಷ.

ಅದೇ ಸಮಯದಲ್ಲಿ, ಕ್ಲೈಂಟ್‌ನಿಂದ 0 ಬೈಟ್‌ಗಳ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಎಂದು ಜಾವಾ ಸರ್ವರ್ ಲಾಗ್‌ಗೆ ಬರೆಯುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಯು 30 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡಿದೆ ಎಂದು Nginx ಪ್ರಾಕ್ಸಿ ಬರೆಯುತ್ತದೆ (30 ಸೆಕೆಂಡುಗಳು ಕ್ಲೈಂಟ್ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಮಯ ಮೀರಿದೆ). ಏಕೆ ಸಮಯ ಮೀರಿದೆ ಮತ್ತು ಏಕೆ 0 ಬೈಟ್‌ಗಳು? HTTP ದೃಷ್ಟಿಕೋನದಿಂದ, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಬೇಕಾದಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಫೈಲ್‌ನೊಂದಿಗೆ POST ನೆಟ್ವರ್ಕ್ನಿಂದ ಕಣ್ಮರೆಯಾಗುತ್ತಿದೆ. ಇದಲ್ಲದೆ, ಇದು ಕ್ಲೈಂಟ್ ಮತ್ತು Nginx ನಡುವೆ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. Tcpdump ನೊಂದಿಗೆ ನಿಮ್ಮನ್ನು ಶಸ್ತ್ರಸಜ್ಜಿತಗೊಳಿಸುವ ಸಮಯ ಇದು! ಆದರೆ ಮೊದಲು ನೀವು ನೆಟ್ವರ್ಕ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. Nginx ಪ್ರಾಕ್ಸಿ L3 ಬ್ಯಾಲೆನ್ಸರ್ ಹಿಂದೆ ಇದೆ NFware. L3 ಬ್ಯಾಲೆನ್ಸರ್‌ನಿಂದ ಸರ್ವರ್‌ಗೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ತಲುಪಿಸಲು ಟನೆಲಿಂಗ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇದು ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಅದರ ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ:

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೆಟ್‌ವರ್ಕ್ ಈ ಸರ್ವರ್‌ಗೆ Vlan-ಟ್ಯಾಗ್ ಮಾಡಿದ ಟ್ರಾಫಿಕ್ ರೂಪದಲ್ಲಿ ಬರುತ್ತದೆ, ಇದು ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ತನ್ನದೇ ಆದ ಕ್ಷೇತ್ರಗಳನ್ನು ಸಹ ಸೇರಿಸುತ್ತದೆ:

ಮತ್ತು ಈ ದಟ್ಟಣೆಯನ್ನು ಸಹ ವಿಭಜಿಸಬಹುದಾಗಿದೆ (ವರ್ಕೌರೌಂಡ್‌ನಿಂದ ಅಪಾಯಗಳನ್ನು ನಿರ್ಣಯಿಸುವಾಗ ನಾವು ಮಾತನಾಡಿದ ಒಳಬರುವ ವಿಭಜಿತ ದಟ್ಟಣೆಯ ಅದೇ ಸಣ್ಣ ಶೇಕಡಾವಾರು), ಇದು ಹೆಡರ್‌ಗಳ ವಿಷಯವನ್ನು ಸಹ ಬದಲಾಯಿಸುತ್ತದೆ:

ಮತ್ತೊಮ್ಮೆ: ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವ್ಲಾನ್ ಟ್ಯಾಗ್‌ನೊಂದಿಗೆ ಸುತ್ತುವರಿಯಲಾಗುತ್ತದೆ, ಸುರಂಗದಿಂದ ಸುತ್ತುವರಿಯಲಾಗುತ್ತದೆ, ವಿಘಟನೆ ಮಾಡಲಾಗುತ್ತದೆ. ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಕ್ಲೈಂಟ್‌ನಿಂದ Nginx ಪ್ರಾಕ್ಸಿಗೆ ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗವನ್ನು ಕಂಡುಹಿಡಿಯೋಣ.

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

tcpdump ಗೆ ಇದೆಲ್ಲವನ್ನೂ ನಿಯತಾಂಕಗಳಾಗಿ ರವಾನಿಸುವುದು ಕಷ್ಟ.
ಕೊನೆಯಿಂದ ಪ್ರಾರಂಭಿಸೋಣ: ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಕ್ಲೀನ್ (ಅನಗತ್ಯ ಹೆಡರ್ ಇಲ್ಲದೆ) IP ಪ್ಯಾಕೆಟ್‌ಗಳು, vlan ಮತ್ತು ಟನಲ್ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆಯೇ?

tcpdump host <ip клиента>

ಇಲ್ಲ, ಸರ್ವರ್‌ನಲ್ಲಿ ಅಂತಹ ಯಾವುದೇ ಪ್ಯಾಕೇಜ್‌ಗಳು ಇರಲಿಲ್ಲ. ಹಾಗಾಗಿ ಸಮಸ್ಯೆ ಮೊದಲೇ ಇರಬೇಕು. Vlan ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಅನ್ನು ಮಾತ್ರ ತೆಗೆದುಹಾಕಿರುವ ಯಾವುದೇ ಪ್ಯಾಕೆಟ್‌ಗಳಿವೆಯೇ?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx ಎಂಬುದು ಹೆಕ್ಸ್ ಫಾರ್ಮ್ಯಾಟ್‌ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ಐಪಿ ವಿಳಾಸವಾಗಿದೆ.
32:4 — ಟನಲ್ ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ SCR IP ಬರೆಯಲಾದ ಕ್ಷೇತ್ರದ ವಿಳಾಸ ಮತ್ತು ಉದ್ದ.

ಕ್ಷೇತ್ರದ ವಿಳಾಸವನ್ನು ವಿವೇಚನಾರಹಿತ ಶಕ್ತಿಯಿಂದ ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗಿತ್ತು, ಏಕೆಂದರೆ ಅಂತರ್ಜಾಲದಲ್ಲಿ ಅವರು 40, 44, 50, 54 ರ ಬಗ್ಗೆ ಬರೆಯುತ್ತಾರೆ, ಆದರೆ ಅಲ್ಲಿ ಯಾವುದೇ IP ವಿಳಾಸ ಇರಲಿಲ್ಲ. ನೀವು ಹೆಕ್ಸ್‌ನಲ್ಲಿರುವ ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಸಹ ನೋಡಬಹುದು (tcpdump ನಲ್ಲಿ -xx ಅಥವಾ -XX ಪ್ಯಾರಾಮೀಟರ್) ಮತ್ತು ನಿಮಗೆ ತಿಳಿದಿರುವ IP ವಿಳಾಸವನ್ನು ಲೆಕ್ಕಹಾಕಿ.

Vlan ಮತ್ತು ಟನಲ್ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಷನ್ ಅನ್ನು ತೆಗೆದುಹಾಕದೆಯೇ ಪ್ಯಾಕೆಟ್ ತುಣುಕುಗಳಿವೆಯೇ?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
ಈ ಮ್ಯಾಜಿಕ್ ನಮಗೆ ಕೊನೆಯದನ್ನು ಒಳಗೊಂಡಂತೆ ಎಲ್ಲಾ ತುಣುಕುಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಬಹುಶಃ, ಅದೇ ವಿಷಯವನ್ನು ಐಪಿ ಮೂಲಕ ಫಿಲ್ಟರ್ ಮಾಡಬಹುದು, ಆದರೆ ನಾನು ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ, ಏಕೆಂದರೆ ಅಂತಹ ಹೆಚ್ಚಿನ ಪ್ಯಾಕೆಟ್‌ಗಳಿಲ್ಲ, ಮತ್ತು ನನಗೆ ಅಗತ್ಯವಿರುವವುಗಳು ಸಾಮಾನ್ಯ ಹರಿವಿನಲ್ಲಿ ಸುಲಭವಾಗಿ ಕಂಡುಬರುತ್ತವೆ. ಅವು ಇಲ್ಲಿವೆ:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500) 11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500) 33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448 0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A.... 0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8} 0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected]. 0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@.. 0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W....... 0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx 0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40) 11.11.11.11 > 22.22.22.22: ip-proto-4 0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A.... 0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8} 0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C 0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q 0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

ಇವುಗಳು ಒಂದು ಪ್ಯಾಕೇಜಿನ ಎರಡು ತುಣುಕುಗಳಾಗಿವೆ (ಅದೇ ID 53652) ಛಾಯಾಚಿತ್ರದೊಂದಿಗೆ (ಎಕ್ಸಿಫ್ ಪದವು ಮೊದಲ ಪ್ಯಾಕೇಜ್‌ನಲ್ಲಿ ಗೋಚರಿಸುತ್ತದೆ). ಈ ಮಟ್ಟದಲ್ಲಿ ಪ್ಯಾಕೇಜುಗಳಿವೆ, ಆದರೆ ಡಂಪ್‌ಗಳಲ್ಲಿ ವಿಲೀನಗೊಂಡ ರೂಪದಲ್ಲಿಲ್ಲ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ, ಸಮಸ್ಯೆಯು ಜೋಡಣೆಯೊಂದಿಗೆ ಸ್ಪಷ್ಟವಾಗಿ ಇದೆ. ಅಂತಿಮವಾಗಿ ಇದಕ್ಕೆ ಸಾಕ್ಷ್ಯಚಿತ್ರ ಸಾಕ್ಷ್ಯವಿದೆ!

ಪ್ಯಾಕೆಟ್ ಡಿಕೋಡರ್ ನಿರ್ಮಾಣವನ್ನು ತಡೆಯುವ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಲಿಲ್ಲ. ಇಲ್ಲಿ ಪ್ರಯತ್ನಿಸಿದೆ: hpd.gasmi.net. ಮೊದಲಿಗೆ, ನೀವು ಅಲ್ಲಿ ಏನನ್ನಾದರೂ ತುಂಬಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಡಿಕೋಡರ್ ಪ್ಯಾಕೆಟ್ ಸ್ವರೂಪವನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ. Srcmac ಮತ್ತು Ethertype (ತುಣುಕು ಮಾಹಿತಿಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ) ನಡುವೆ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಎರಡು ಆಕ್ಟೆಟ್‌ಗಳಿವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಅವುಗಳನ್ನು ತೆಗೆದುಹಾಕಿದ ನಂತರ, ಡಿಕೋಡರ್ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು. ಆದಾಗ್ಯೂ, ಇದು ಯಾವುದೇ ತೊಂದರೆಗಳನ್ನು ತೋರಿಸಲಿಲ್ಲ.
ಒಬ್ಬರು ಏನು ಹೇಳಿದರೂ, ಆ Sysctl ಹೊರತುಪಡಿಸಿ ಬೇರೇನೂ ಕಂಡುಬಂದಿಲ್ಲ. ಸ್ಕೇಲ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಮುಂದಿನ ಕ್ರಮಗಳನ್ನು ನಿರ್ಧರಿಸಲು ಸಮಸ್ಯೆಯ ಸರ್ವರ್‌ಗಳನ್ನು ಗುರುತಿಸುವ ಮಾರ್ಗವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ. ಅಗತ್ಯವಿರುವ ಕೌಂಟರ್ ಸಾಕಷ್ಟು ಬೇಗನೆ ಕಂಡುಬಂದಿದೆ:

netstat -s | grep "packet reassembles failed”

ಇದು OID=1.3.6.1.2.1.4.31.1.1.16.1 ಅಡಿಯಲ್ಲಿ snmpd ನಲ್ಲಿಯೂ ಇದೆ (ipSystemStatsReasmFails).

"ಐಪಿ ಮರು-ಜೋಡಣೆ ಅಲ್ಗಾರಿದಮ್‌ನಿಂದ ಪತ್ತೆಯಾದ ವೈಫಲ್ಯಗಳ ಸಂಖ್ಯೆ (ಯಾವುದೇ ಕಾರಣಕ್ಕಾಗಿ: ಸಮಯ ಮೀರಿದೆ, ದೋಷಗಳು, ಇತ್ಯಾದಿ)."

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

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

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

ಪ್ರಮುಖ ಪ್ರಶ್ನೆಗಳು

ನಮ್ಮ L3 ಬ್ಯಾಲೆನ್ಸರ್‌ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಏಕೆ ವಿಭಜಿಸಲಾಗಿದೆ? ಬಳಕೆದಾರರಿಂದ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಿಗೆ ಬರುವ ಹೆಚ್ಚಿನ ಪ್ಯಾಕೆಟ್‌ಗಳು SYN ಮತ್ತು ACK ಆಗಿರುತ್ತವೆ. ಈ ಪ್ಯಾಕೇಜುಗಳ ಗಾತ್ರಗಳು ಚಿಕ್ಕದಾಗಿದೆ. ಆದರೆ ಅಂತಹ ಪ್ಯಾಕೆಟ್‌ಗಳ ಪಾಲು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ, ಅವುಗಳ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್‌ಗಳ ಉಪಸ್ಥಿತಿಯನ್ನು ನಾವು ಗಮನಿಸಲಿಲ್ಲ, ಅದು ತುಂಡಾಗಲು ಪ್ರಾರಂಭಿಸಿತು.

ಕಾರಣ ಮುರಿದ ಕಾನ್ಫಿಗರೇಶನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿತ್ತು advmss Vlan ಇಂಟರ್ಫೇಸ್‌ಗಳೊಂದಿಗಿನ ಸರ್ವರ್‌ಗಳಲ್ಲಿ (ಆ ಸಮಯದಲ್ಲಿ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಟ್ಯಾಗ್ ಮಾಡಲಾದ ಟ್ರಾಫಿಕ್‌ನೊಂದಿಗೆ ಕೆಲವೇ ಸರ್ವರ್‌ಗಳು ಇದ್ದವು). ನಮ್ಮ ದಿಕ್ಕಿನಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳು ಗಾತ್ರದಲ್ಲಿ ಚಿಕ್ಕದಾಗಿರಬೇಕು ಎಂಬ ಮಾಹಿತಿಯನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ತಿಳಿಸಲು Advmss ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಆದ್ದರಿಂದ ಅವುಗಳಿಗೆ ಸುರಂಗ ಹೆಡರ್‌ಗಳನ್ನು ಜೋಡಿಸಿದ ನಂತರ ಅವುಗಳನ್ನು ವಿಭಜಿಸಬೇಕಾಗಿಲ್ಲ.

Sysctl ರೋಲ್‌ಬ್ಯಾಕ್ ಏಕೆ ಸಹಾಯ ಮಾಡಲಿಲ್ಲ, ಆದರೆ ರೀಬೂಟ್ ಮಾಡಿತು? ರೋಲಿಂಗ್ ಬ್ಯಾಕ್ Sysctl ಪ್ಯಾಕೇಜುಗಳನ್ನು ವಿಲೀನಗೊಳಿಸಲು ಲಭ್ಯವಿರುವ ಮೆಮೊರಿಯ ಪ್ರಮಾಣವನ್ನು ಬದಲಾಯಿಸಿತು. ಅದೇ ಸಮಯದಲ್ಲಿ, ತುಣುಕುಗಳಿಗೆ ಮೆಮೊರಿ ಉಕ್ಕಿ ಹರಿಯುವ ಅಂಶವು ಸಂಪರ್ಕಗಳ ನಿಧಾನಕ್ಕೆ ಕಾರಣವಾಯಿತು, ಇದು ಸರದಿಯಲ್ಲಿ ದೀರ್ಘಕಾಲ ವಿಳಂಬವಾಗಲು ಕಾರಣವಾಯಿತು. ಅಂದರೆ, ಪ್ರಕ್ರಿಯೆಯು ಚಕ್ರಗಳಲ್ಲಿ ಹೋಯಿತು.
ರೀಬೂಟ್ ಮೆಮೊರಿಯನ್ನು ತೆರವುಗೊಳಿಸಿತು ಮತ್ತು ಎಲ್ಲವೂ ಕ್ರಮಕ್ಕೆ ಮರಳಿತು.

ಪರಿಹಾರವಿಲ್ಲದೆ ಮಾಡಲು ಸಾಧ್ಯವೇ? ಹೌದು, ಆದರೆ ದಾಳಿಯ ಸಂದರ್ಭದಲ್ಲಿ ಸೇವೆಯಿಲ್ಲದೆ ಬಳಕೆದಾರರನ್ನು ಬಿಡುವ ಹೆಚ್ಚಿನ ಅಪಾಯವಿದೆ. ಸಹಜವಾಗಿ, ವರ್ಕ್‌ರೌಂಡ್‌ನ ಬಳಕೆಯು ಬಳಕೆದಾರರಿಗೆ ಸೇವೆಗಳಲ್ಲಿ ಒಂದನ್ನು ನಿಧಾನಗೊಳಿಸುವುದು ಸೇರಿದಂತೆ ವಿವಿಧ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಯಿತು, ಆದರೆ ಅದೇನೇ ಇದ್ದರೂ ಕ್ರಮಗಳು ಸಮರ್ಥನೆಯಾಗಿದೆ ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ.

ಆಂಡ್ರೆ ಟಿಮೊಫೀವ್ ಅವರಿಗೆ ತುಂಬಾ ಧನ್ಯವಾದಗಳು (ಅಟಿಮೋಫೀವ್) ತನಿಖೆ ನಡೆಸುವಲ್ಲಿ ಸಹಾಯಕ್ಕಾಗಿ, ಹಾಗೆಯೇ ಅಲೆಕ್ಸಿ ಕ್ರೆನೆವ್ (ಸಾಧನx) - ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸೆಂಟೋಸ್ ಮತ್ತು ಕರ್ನಲ್‌ಗಳನ್ನು ನವೀಕರಿಸುವ ಟೈಟಾನಿಕ್ ಕೆಲಸಕ್ಕಾಗಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಮೊದಲಿನಿಂದಲೂ ಹಲವಾರು ಬಾರಿ ಪ್ರಾರಂಭಿಸಬೇಕಾದ ಪ್ರಕ್ರಿಯೆಯು ಹಲವು ತಿಂಗಳುಗಳವರೆಗೆ ಎಳೆಯಲ್ಪಟ್ಟಿತು.

ಮೂಲ: www.habr.com

ಕೆಲಸದ ಸುತ್ತುಗಳನ್ನು ತರುವ ದುರ್ಬಲತೆಗಳ ಬಗ್ಗೆ ಎಚ್ಚರದಿಂದಿರಿ. ಭಾಗ 1: FragmentSmack/SegmentSmack