ಮಾಧ್ಯಮದ ವಿಷಯವಿಲ್ಲದೆ ಆಧುನಿಕ ವೆಬ್ ಬಹುತೇಕ ಯೋಚಿಸಲಾಗುವುದಿಲ್ಲ: ಬಹುತೇಕ ಪ್ರತಿ ಅಜ್ಜಿಗೆ ಸ್ಮಾರ್ಟ್ಫೋನ್ ಇದೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಸಾಮಾಜಿಕ ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿದ್ದಾರೆ ಮತ್ತು ನಿರ್ವಹಣೆಯಲ್ಲಿ ಅಲಭ್ಯತೆಯು ಕಂಪನಿಗಳಿಗೆ ದುಬಾರಿಯಾಗಿದೆ. ಕಂಪನಿಯ ಕಥೆಯ ಪ್ರತಿಲಿಪಿ ಇಲ್ಲಿದೆ ಹಾರ್ಡ್‌ವೇರ್ ಪರಿಹಾರವನ್ನು ಬಳಸಿಕೊಂಡು ಫೋಟೋಗಳ ವಿತರಣೆಯನ್ನು ಅವಳು ಹೇಗೆ ಆಯೋಜಿಸಿದಳು, ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅವಳು ಎದುರಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳು, ಅವುಗಳಿಗೆ ಕಾರಣವೇನು ಮತ್ತು ಎಲ್ಲಾ ಹಂತಗಳಲ್ಲಿ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವಾಗ Nginx ಆಧಾರಿತ ಸಾಫ್ಟ್‌ವೇರ್ ಪರಿಹಾರವನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಲಾಗಿದೆ () ಒಲೆಗ್ ಅವರ ಕಥೆಯ ಲೇಖಕರಿಗೆ ನಾವು ಧನ್ಯವಾದಗಳು ಸಮ್ಮೇಳನದಲ್ಲಿ ತಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಂಡ ಎಫಿಮೊವಾ ಮತ್ತು ಅಲೆಕ್ಸಾಂಡ್ರಾ ಡಿಮೊವಾ .
— ನಾವು ಫೋಟೋಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ಸ್ವಲ್ಪ ಪರಿಚಯದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ನಾವು ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಪದರವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಫೋಟೋಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಪದರವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಹೆಚ್ಚಿನ ಟ್ರಿಕ್ ದರವನ್ನು ಸಾಧಿಸಲು ಮತ್ತು ಸಂಗ್ರಹಣೆಯ ಮೇಲಿನ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಬಯಸಿದರೆ, ಒಬ್ಬ ವೈಯಕ್ತಿಕ ಬಳಕೆದಾರರ ಪ್ರತಿಯೊಂದು ಫೋಟೋವು ಒಂದು ಕ್ಯಾಶಿಂಗ್ ಸರ್ವರ್‌ನಲ್ಲಿರುವುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ. ಇಲ್ಲದಿದ್ದರೆ, ನಾವು ಹೆಚ್ಚು ಸರ್ವರ್ಗಳನ್ನು ಹೊಂದಿರುವಷ್ಟು ಹೆಚ್ಚು ಡಿಸ್ಕ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗುತ್ತದೆ. ನಮ್ಮ ಟ್ರಿಕ್ ದರವು ಸುಮಾರು 99% ಆಗಿದೆ, ಅಂದರೆ, ನಾವು ನಮ್ಮ ಸಂಗ್ರಹಣೆಯ ಮೇಲಿನ ಲೋಡ್ ಅನ್ನು 100 ಪಟ್ಟು ಕಡಿಮೆ ಮಾಡುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಇದನ್ನು ಮಾಡಲು, 10 ವರ್ಷಗಳ ಹಿಂದೆ, ಇವೆಲ್ಲವನ್ನೂ ನಿರ್ಮಿಸುವಾಗ, ನಾವು 50 ಸರ್ವರ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅಂತೆಯೇ, ಈ ಫೋಟೋಗಳನ್ನು ಪೂರೈಸಲು, ನಮಗೆ ಈ ಸರ್ವರ್‌ಗಳು ಸೇವೆ ಸಲ್ಲಿಸುವ 50 ಬಾಹ್ಯ ಡೊಮೇನ್‌ಗಳ ಅಗತ್ಯವಿದೆ.
ಸ್ವಾಭಾವಿಕವಾಗಿ, ಪ್ರಶ್ನೆಯು ತಕ್ಷಣವೇ ಹುಟ್ಟಿಕೊಂಡಿತು: ನಮ್ಮ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದು ಕಡಿಮೆಯಾದರೆ ಮತ್ತು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ನಾವು ದಟ್ಟಣೆಯ ಯಾವ ಭಾಗವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ? ನಾವು ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಏನಿದೆ ಎಂದು ನೋಡಿದ್ದೇವೆ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ತುಂಡು ಖರೀದಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಇದರಿಂದ ನಮ್ಮ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಆಯ್ಕೆಯು F5-ನೆಟ್‌ವರ್ಕ್ ಕಂಪನಿಯ ಪರಿಹಾರದ ಮೇಲೆ ಬಿದ್ದಿತು (ಇದು, ಇತ್ತೀಚೆಗೆ NGINX, Inc ಅನ್ನು ಖರೀದಿಸಿತು): BIG-IP ಸ್ಥಳೀಯ ಟ್ರಾಫಿಕ್ ಮ್ಯಾನೇಜರ್.
ಈ ಹಾರ್ಡ್‌ವೇರ್ ತುಣುಕು (LTM) ಏನು ಮಾಡುತ್ತದೆ: ಇದು ಕಬ್ಬಿಣದ ರೂಟರ್ ಆಗಿದ್ದು ಅದು ಅದರ ಬಾಹ್ಯ ಪೋರ್ಟ್‌ಗಳ ಕಬ್ಬಿಣದ ಪುನರುತ್ಪಾದನೆಯನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಟೋಪೋಲಜಿಯ ಆಧಾರದ ಮೇಲೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮಾರ್ಗ ಮಾಡಲು ಮತ್ತು ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಮಾಡುತ್ತದೆ. ಈ ಯಂತ್ರಾಂಶವನ್ನು ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಬಹುದೆಂಬುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿತ್ತು. ಅಂತೆಯೇ, ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರ ಛಾಯಾಚಿತ್ರಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಸಂಗ್ರಹದಿಂದ ಹೇಗೆ ನೀಡಲಾಗುತ್ತದೆ ಎಂಬ ತರ್ಕವನ್ನು ನಾವು ವಿವರಿಸಬಹುದು. ಅದು ಯಾವುದರಂತೆ ಕಾಣಿಸುತ್ತದೆ? ಒಂದು ಡೊಮೇನ್‌ನಲ್ಲಿ ಇಂಟರ್ನೆಟ್ ಅನ್ನು ನೋಡುವ ಒಂದು ಹಾರ್ಡ್‌ವೇರ್ ಇದೆ, ಒಂದು IP, ssl ಆಫ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ, http ವಿನಂತಿಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡುತ್ತದೆ, IRule ನಿಂದ ಸಂಗ್ರಹ ಸಂಖ್ಯೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕು ಮತ್ತು ಅಲ್ಲಿಗೆ ಟ್ರಾಫಿಕ್ ಹೋಗಲು ಅನುಮತಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಇದು ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಯಂತ್ರಗಳು ಲಭ್ಯವಿಲ್ಲದಿದ್ದಲ್ಲಿ, ಆ ಸಮಯದಲ್ಲಿ ನಾವು ಅದನ್ನು ಮಾಡಿದ್ದೇವೆ ಇದರಿಂದ ಟ್ರಾಫಿಕ್ ಒಂದು ಬ್ಯಾಕಪ್ ಸರ್ವರ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಕಾನ್ಫಿಗರೇಶನ್ ದೃಷ್ಟಿಕೋನದಿಂದ, ಸಹಜವಾಗಿ, ಕೆಲವು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ: ನಾವು ಕಾರ್ಡ್ ಅನ್ನು ನೋಂದಾಯಿಸುತ್ತೇವೆ, ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ನಮ್ಮ ಐಪಿಗೆ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಪತ್ರವ್ಯವಹಾರ, ನಾವು ಪೋರ್ಟ್ಗಳು 80 ನಲ್ಲಿ ಕೇಳುತ್ತೇವೆ ಎಂದು ನಾವು ಹೇಳುತ್ತೇವೆ. ಮತ್ತು 443, ಸರ್ವರ್ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಬ್ಯಾಕಪ್ ಒಂದಕ್ಕೆ ದಟ್ಟಣೆಯನ್ನು ಕಳುಹಿಸಬೇಕು ಎಂದು ನಾವು ಹೇಳುತ್ತೇವೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ 35 ನೇ, ಮತ್ತು ಈ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹೇಗೆ ಡಿಸ್ಅಸೆಂಬಲ್ ಮಾಡಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಾವು ತರ್ಕದ ಗುಂಪನ್ನು ವಿವರಿಸುತ್ತೇವೆ. ಹಾರ್ಡ್‌ವೇರ್ ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಿದ ಭಾಷೆ Tcl ಆಗಿತ್ತು ಎಂಬುದು ಒಂದೇ ಸಮಸ್ಯೆ. ಯಾರಾದರೂ ಇದನ್ನು ನೆನಪಿಸಿಕೊಂಡರೆ ... ಈ ಭಾಷೆ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ಗೆ ಅನುಕೂಲಕರ ಭಾಷೆಗಿಂತ ಹೆಚ್ಚು ಬರೆಯಲು ಮಾತ್ರ:
ನಮಗೆ ಏನು ಸಿಕ್ಕಿತು? ನಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವ, ನಮ್ಮ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಮಾರ್ಗಗಳನ್ನು, ಆರೋಗ್ಯ ಪ್ರಯೋಜನಗಳನ್ನು ಒದಗಿಸುವ ಮತ್ತು ಕೇವಲ ಕೆಲಸ ಮಾಡುವ ಹಾರ್ಡ್‌ವೇರ್‌ನ ತುಣುಕನ್ನು ನಾವು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. ಇದಲ್ಲದೆ, ಇದು ಸಾಕಷ್ಟು ಸಮಯದವರೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ಕಳೆದ 10 ವರ್ಷಗಳಲ್ಲಿ ಇದರ ಬಗ್ಗೆ ಯಾವುದೇ ದೂರುಗಳಿಲ್ಲ. 2018 ರ ಆರಂಭದ ವೇಳೆಗೆ, ನಾವು ಈಗಾಗಲೇ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 80 ಸಾವಿರ ಫೋಟೋಗಳನ್ನು ಕಳುಹಿಸುತ್ತಿದ್ದೇವೆ. ಇದು ನಮ್ಮ ಎರಡೂ ಡೇಟಾ ಕೇಂದ್ರಗಳಿಂದ ಸುಮಾರು 80 ಗಿಗಾಬಿಟ್‌ಗಳ ಸಂಚಾರವಾಗಿದೆ.
ಆದರೆ…
2018 ರ ಆರಂಭದಲ್ಲಿ, ನಾವು ಚಾರ್ಟ್‌ಗಳಲ್ಲಿ ಕೊಳಕು ಚಿತ್ರವನ್ನು ನೋಡಿದ್ದೇವೆ: ಫೋಟೋಗಳನ್ನು ಕಳುಹಿಸಲು ತೆಗೆದುಕೊಂಡ ಸಮಯವು ಸ್ಪಷ್ಟವಾಗಿ ಹೆಚ್ಚಾಗಿದೆ. ಮತ್ತು ಅದು ನಮಗೆ ಸರಿಹೊಂದುವುದನ್ನು ನಿಲ್ಲಿಸಿತು. ಸಮಸ್ಯೆಯೆಂದರೆ ಈ ನಡವಳಿಕೆಯು ದಟ್ಟಣೆಯ ಉತ್ತುಂಗದಲ್ಲಿ ಮಾತ್ರ ಗೋಚರಿಸುತ್ತದೆ - ನಮ್ಮ ಕಂಪನಿಗೆ ಇದು ಭಾನುವಾರದಿಂದ ಸೋಮವಾರದವರೆಗೆ ರಾತ್ರಿಯಾಗಿದೆ. ಆದರೆ ಉಳಿದ ಸಮಯದಲ್ಲಿ ವ್ಯವಸ್ಥೆಯು ಎಂದಿನಂತೆ ವರ್ತಿಸಿತು, ವೈಫಲ್ಯದ ಯಾವುದೇ ಲಕ್ಷಣಗಳಿಲ್ಲ.
ಅದೇನೇ ಇದ್ದರೂ, ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿತ್ತು. ನಾವು ಸಂಭವನೀಯ ಅಡಚಣೆಗಳನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಬಾಹ್ಯ ಅಪ್‌ಲಿಂಕ್‌ಗಳನ್ನು ವಿಸ್ತರಿಸಿದ್ದೇವೆ, ಆಂತರಿಕ ಅಪ್‌ಲಿಂಕ್‌ಗಳ ಸಂಪೂರ್ಣ ಆಡಿಟ್ ಅನ್ನು ನಡೆಸಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲಾ ಸಂಭಾವ್ಯ ಅಡಚಣೆಗಳನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಆದರೆ ಇದೆಲ್ಲವೂ ಸ್ಪಷ್ಟ ಫಲಿತಾಂಶವನ್ನು ನೀಡಲಿಲ್ಲ, ಸಮಸ್ಯೆ ಕಣ್ಮರೆಯಾಗಲಿಲ್ಲ.
ಮತ್ತೊಂದು ಸಂಭವನೀಯ ಅಡಚಣೆಯೆಂದರೆ ಫೋಟೋ ಸಂಗ್ರಹಗಳ ಕಾರ್ಯಕ್ಷಮತೆ. ಮತ್ತು ಬಹುಶಃ ಸಮಸ್ಯೆ ಅವರ ಮೇಲಿದೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಸರಿ, ನಾವು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ವಿಸ್ತರಿಸಿದ್ದೇವೆ - ಮುಖ್ಯವಾಗಿ ಫೋಟೋ ಕ್ಯಾಶ್‌ಗಳಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಪೋರ್ಟ್ಗಳು. ಆದರೆ ಮತ್ತೆ ಯಾವುದೇ ಸ್ಪಷ್ಟ ಸುಧಾರಣೆ ಕಂಡುಬರಲಿಲ್ಲ. ಕೊನೆಯಲ್ಲಿ, ನಾವು LTM ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಹೆಚ್ಚು ಗಮನ ಹರಿಸಿದ್ದೇವೆ ಮತ್ತು ಇಲ್ಲಿ ನಾವು ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ ದುಃಖದ ಚಿತ್ರವನ್ನು ನೋಡಿದ್ದೇವೆ: ಎಲ್ಲಾ CPU ಗಳಲ್ಲಿನ ಲೋಡ್ ಸರಾಗವಾಗಿ ಹೋಗಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಆದರೆ ನಂತರ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಪ್ರಸ್ಥಭೂಮಿಗೆ ಬರುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, LTM ಆರೋಗ್ಯ ತಪಾಸಣೆ ಮತ್ತು ಅಪ್‌ಲಿಂಕ್‌ಗಳಿಗೆ ಸಮರ್ಪಕವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಅವುಗಳನ್ನು ಆಫ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಇದು ಗಂಭೀರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವನತಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಅಂದರೆ, ನಾವು ಸಮಸ್ಯೆಯ ಮೂಲವನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ, ಅಡಚಣೆಯನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ. ನಾವು ಏನು ಮಾಡುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಉಳಿದಿದೆ.
ನಾವು ಮಾಡಬಹುದಾದ ಮೊದಲ, ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದ ವಿಷಯವೆಂದರೆ LTM ಅನ್ನು ಹೇಗಾದರೂ ಆಧುನೀಕರಿಸುವುದು. ಆದರೆ ಇಲ್ಲಿ ಕೆಲವು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ, ಏಕೆಂದರೆ ಈ ಯಂತ್ರಾಂಶವು ಸಾಕಷ್ಟು ವಿಶಿಷ್ಟವಾಗಿದೆ, ನೀವು ಹತ್ತಿರದ ಸೂಪರ್ಮಾರ್ಕೆಟ್ಗೆ ಹೋಗಿ ಅದನ್ನು ಖರೀದಿಸುವುದಿಲ್ಲ. ಇದು ಪ್ರತ್ಯೇಕ ಒಪ್ಪಂದ, ಪ್ರತ್ಯೇಕ ಪರವಾನಗಿ ಒಪ್ಪಂದ, ಮತ್ತು ಇದು ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಎರಡನೆಯ ಆಯ್ಕೆಯು ನಿಮಗಾಗಿ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸುವುದು, ನಿಮ್ಮ ಸ್ವಂತ ಘಟಕಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮ್ಮ ಸ್ವಂತ ಪರಿಹಾರದೊಂದಿಗೆ ಬನ್ನಿ, ಮೇಲಾಗಿ ತೆರೆದ ಪ್ರವೇಶ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಬಳಸುವುದು. ಇದಕ್ಕಾಗಿ ನಾವು ನಿಖರವಾಗಿ ಏನನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ನಾವು ಎಷ್ಟು ಸಮಯವನ್ನು ಕಳೆಯುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರು ಸಾಕಷ್ಟು ಫೋಟೋಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಎಲ್ಲವನ್ನೂ ಬಹಳ ಬೇಗನೆ ಮಾಡಬೇಕಾಗಿದೆ, ಒಬ್ಬರು ನಿನ್ನೆ ಹೇಳಬಹುದು.
ಕಾರ್ಯವು "ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಏನನ್ನಾದರೂ ಮಾಡಿ ಮತ್ತು ನಮ್ಮಲ್ಲಿರುವ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಬಳಸಿ" ಎಂದು ತೋರುತ್ತಿರುವುದರಿಂದ, ನಾವು ಮೊದಲು ಯೋಚಿಸಿದ ವಿಷಯವೆಂದರೆ ಮುಂಭಾಗದಿಂದ ಕೆಲವು ಶಕ್ತಿಯುತವಲ್ಲದ ಯಂತ್ರಗಳನ್ನು ಸರಳವಾಗಿ ತೆಗೆದುಹಾಕುವುದು, Nginx ಅನ್ನು ಅಲ್ಲಿ ಇರಿಸಿ, ಅದರೊಂದಿಗೆ ನಮಗೆ ಹೇಗೆ ಗೊತ್ತು ಕೆಲಸ ಮಾಡಿ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ಮಾಡಲು ಬಳಸಿದ ಅದೇ ತರ್ಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಿ. ಅಂದರೆ, ವಾಸ್ತವವಾಗಿ, ನಾವು ನಮ್ಮ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ತೊರೆದಿದ್ದೇವೆ, ನಾವು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾದ ಇನ್ನೂ 4 ಸರ್ವರ್ಗಳನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇವೆ, ಅವುಗಳಿಗೆ ಬಾಹ್ಯ ಡೊಮೇನ್‌ಗಳನ್ನು ರಚಿಸಿದ್ದೇವೆ, ಅದು 10 ವರ್ಷಗಳ ಹಿಂದೆ ಹೇಗೆ ಇತ್ತು ... ಈ ಯಂತ್ರಗಳು ಬಿದ್ದರೆ ನಾವು ಲಭ್ಯತೆಯಲ್ಲಿ ಸ್ವಲ್ಪ ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ, ಆದರೆ ಇನ್ನೂ ಕಡಿಮೆ, ಅವರು ಸ್ಥಳೀಯವಾಗಿ ನಮ್ಮ ಬಳಕೆದಾರರ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದಾರೆ.
ಅಂತೆಯೇ, ತರ್ಕವು ಒಂದೇ ಆಗಿರುತ್ತದೆ: ನಾವು Nginx ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ, ಅದು SSL-ಆಫ್‌ಲೋಡ್ ಮಾಡಬಹುದು, ನಾವು ಹೇಗಾದರೂ ರೂಟಿಂಗ್ ಲಾಜಿಕ್ ಅನ್ನು ಪ್ರೋಗ್ರಾಂ ಮಾಡಬಹುದು, ಸಂರಚನೆಯಲ್ಲಿ ಆರೋಗ್ಯ-ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ನಾವು ಮೊದಲು ಹೊಂದಿದ್ದ ತರ್ಕವನ್ನು ಸರಳವಾಗಿ ನಕಲು ಮಾಡಬಹುದು.
ಸಂರಚನೆಗಳನ್ನು ಬರೆಯಲು ಕುಳಿತುಕೊಳ್ಳೋಣ. ಮೊದಲಿಗೆ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಪ್ರತಿ ಕಾರ್ಯಕ್ಕೂ ಕೈಪಿಡಿಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ತುಂಬಾ ಕಷ್ಟ. ಆದ್ದರಿಂದ, "ಫೋಟೋಗಳಿಗಾಗಿ Nginx ಅನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು" ಎಂದು ಸರಳವಾಗಿ ಗೂಗ್ಲಿಂಗ್ ಮಾಡಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ: ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು ಉಲ್ಲೇಖಿಸುವುದು ಉತ್ತಮ, ಇದು ಯಾವ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸ್ಪರ್ಶಿಸಬೇಕೆಂದು ತೋರಿಸುತ್ತದೆ. ಆದರೆ ನಿರ್ದಿಷ್ಟ ನಿಯತಾಂಕವನ್ನು ನೀವೇ ಆರಿಸಿಕೊಳ್ಳುವುದು ಉತ್ತಮ. ಸರಿ, ನಂತರ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ: ನಾವು ಹೊಂದಿರುವ ಸರ್ವರ್ಗಳನ್ನು ನಾವು ವಿವರಿಸುತ್ತೇವೆ, ನಾವು ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ವಿವರಿಸುತ್ತೇವೆ ... ಆದರೆ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವೆಂದರೆ, ವಾಸ್ತವವಾಗಿ, ರೂಟಿಂಗ್ ಲಾಜಿಕ್ ಸ್ವತಃ.
ಮೊದಲಿಗೆ ನಾವು ನಮ್ಮ ಸ್ಥಳವನ್ನು ಸರಳವಾಗಿ ವಿವರಿಸುತ್ತೇವೆ, ಅದರಲ್ಲಿ ನಮ್ಮ ಫೋಟೋ ಸಂಗ್ರಹದ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ, ನಮ್ಮ ಕೈಗಳು ಅಥವಾ ಜನರೇಟರ್ ಬಳಸಿ ನಮಗೆ ಎಷ್ಟು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗಳು ಬೇಕು ಎಂದು ವಿವರಿಸುತ್ತೇವೆ, ಪ್ರತಿ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ನಾವು ಟ್ರಾಫಿಕ್ ಯಾವ ಸರ್ವರ್ ಅನ್ನು ಸೂಚಿಸುತ್ತೇವೆ ಹೋಗಿ, ಮತ್ತು ಬ್ಯಾಕಪ್ ಸರ್ವರ್ - ಮುಖ್ಯ ಸರ್ವರ್ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ:
ಆದರೆ, ಬಹುಶಃ, ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದ್ದರೆ, ನಾವು ಸರಳವಾಗಿ ಮನೆಗೆ ಹೋಗುತ್ತೇವೆ ಮತ್ತು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ದುರದೃಷ್ಟವಶಾತ್, ಡೀಫಾಲ್ಟ್ Nginx ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಹಲವು ವರ್ಷಗಳ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಮಾಡಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಸೂಕ್ತವಲ್ಲ... ಸಂರಚನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ಕೆಲವು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸರ್ವರ್ ವಿನಂತಿ ದೋಷ ಅಥವಾ ಸಮಯ ಮೀರಿದ್ದರೆ, Nginx ಯಾವಾಗಲೂ ಸಂಚಾರವನ್ನು ಮುಂದಿನದಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತದೆ. ಇದಲ್ಲದೆ, ಮೊದಲ ವೈಫಲ್ಯದ ನಂತರ, 10 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಸರ್ವರ್ ಅನ್ನು ತಪ್ಪಾಗಿ ಮತ್ತು ಸಮಯಾವಧಿಯಿಂದ ಆಫ್ ಮಾಡಲಾಗುತ್ತದೆ - ಇದನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಅಂದರೆ, ನಾವು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ನಿರ್ದೇಶನದಲ್ಲಿ ಸಮಯ ಮೀರುವ ಆಯ್ಕೆಯನ್ನು ತೆಗೆದುಹಾಕಿದರೆ ಅಥವಾ ಮರುಹೊಂದಿಸಿದರೆ, Nginx ಈ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದಿಲ್ಲ ಮತ್ತು ಕೆಲವು ಉತ್ತಮ ದೋಷದೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ, ಸರ್ವರ್ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ.
ಇದನ್ನು ತಪ್ಪಿಸಲು, ನಾವು ಎರಡು ಕೆಲಸಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ:
ಎ) ಅವರು Nginx ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾಡುವುದನ್ನು ನಿಷೇಧಿಸಿದ್ದಾರೆ - ಮತ್ತು ದುರದೃಷ್ಟವಶಾತ್, ಇದನ್ನು ಮಾಡಲು ಏಕೈಕ ಮಾರ್ಗವೆಂದರೆ ಗರಿಷ್ಠ ವಿಫಲ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿಸುವುದು.
ಬಿ) ಇತರ ಯೋಜನೆಗಳಲ್ಲಿ ನಾವು ಹಿನ್ನೆಲೆ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಮಾಡಲು ಅನುಮತಿಸುವ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಎಂದು ನಾವು ನೆನಪಿಸಿಕೊಂಡಿದ್ದೇವೆ - ಅದರ ಪ್ರಕಾರ, ಅಪಘಾತದ ಸಂದರ್ಭದಲ್ಲಿ ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು ಆಗಾಗ್ಗೆ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ.
ದುರದೃಷ್ಟವಶಾತ್, ಇದೆಲ್ಲವೂ ಅಲ್ಲ, ಏಕೆಂದರೆ ಅಕ್ಷರಶಃ ಈ ಯೋಜನೆಯ ಮೊದಲ ಎರಡು ವಾರಗಳ ಕಾರ್ಯಾಚರಣೆಯು TCP ಆರೋಗ್ಯ-ಪರೀಕ್ಷೆಯು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ವಿಷಯವಾಗಿದೆ ಎಂದು ತೋರಿಸಿದೆ: ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಅದು Nginx ಅಥವಾ D- ಸ್ಟೇಟ್‌ನಲ್ಲಿ Nginx ಆಗಿರಬಹುದು, ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ ಕರ್ನಲ್ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆರೋಗ್ಯ ತಪಾಸಣೆ ಹಾದುಹೋಗುತ್ತದೆ, ಆದರೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ತಕ್ಷಣ ಇದನ್ನು ಆರೋಗ್ಯ ತಪಾಸಣೆ http ನೊಂದಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ, ನಿರ್ದಿಷ್ಟವಾದದನ್ನು ಮಾಡಿದ್ದೇವೆ, ಅದು 200 ಅನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ಎಲ್ಲವೂ ಈ ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು ಹೆಚ್ಚುವರಿ ತರ್ಕವನ್ನು ಮಾಡಬಹುದು - ಉದಾಹರಣೆಗೆ, ಕ್ಯಾಶಿಂಗ್ ಸರ್ವರ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸರಿಯಾಗಿ ಜೋಡಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ:
ಮತ್ತು ಇದು ನಮಗೆ ಸರಿಹೊಂದುತ್ತದೆ, ಈ ಸಮಯದಲ್ಲಿ ಸರ್ಕ್ಯೂಟ್ ಹಾರ್ಡ್‌ವೇರ್ ಏನು ಮಾಡಿದೆ ಎಂಬುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಆದರೆ ನಾವು ಉತ್ತಮವಾಗಿ ಮಾಡಲು ಬಯಸಿದ್ದೇವೆ. ಹಿಂದೆ, ನಾವು ಒಂದು ಬ್ಯಾಕಪ್ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಇದು ಬಹುಶಃ ಉತ್ತಮವಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ನೀವು ನೂರು ಸರ್ವರ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಹಲವಾರು ಬಾರಿ ವಿಫಲವಾದಾಗ, ಒಂದು ಬ್ಯಾಕಪ್ ಸರ್ವರ್ ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸಲು ಅಸಂಭವವಾಗಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಾಯ್ದಿರಿಸುವಿಕೆಯನ್ನು ವಿತರಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ: ನಾವು ಸರಳವಾಗಿ ಮತ್ತೊಂದು ಪ್ರತ್ಯೇಕ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಮಾಡಿದ್ದೇವೆ, ಎಲ್ಲಾ ಸರ್ವರ್ಗಳನ್ನು ಅವರು ಪೂರೈಸಬಹುದಾದ ಲೋಡ್‌ಗೆ ಅನುಗುಣವಾಗಿ ಕೆಲವು ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಬರೆದಿದ್ದೇವೆ, ನಾವು ಮೊದಲು ಹೊಂದಿದ್ದ ಅದೇ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ:
ಒಂದು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಇನ್ನೊಂದು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ಹೋಗುವುದು ಅಸಾಧ್ಯವಾದ್ದರಿಂದ, ನಾವು ಸರಿಯಾದ, ಅಗತ್ಯ ಫೋಟೋ ಸಂಗ್ರಹವನ್ನು ಸರಳವಾಗಿ ರೆಕಾರ್ಡ್ ಮಾಡಿದ ಮುಖ್ಯ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ನಾವು ಫಾಲ್‌ಬ್ಯಾಕ್‌ಗೆ ದೋಷ_ಪುಟದ ಮೂಲಕ ಹೋಗಿದ್ದೇವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ನಾವು ಬ್ಯಾಕಪ್ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗೆ ಎಲ್ಲಿ ಹೋದೆವು:
ಮತ್ತು ಅಕ್ಷರಶಃ ನಾಲ್ಕು ಸರ್ವರ್ಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ, ಇದು ನಮಗೆ ಸಿಕ್ಕಿತು: ನಾವು ಲೋಡ್‌ನ ಭಾಗವನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ - ನಾವು ಅದನ್ನು LTM ನಿಂದ ಈ ಸರ್ವರ್‌ಗಳಿಗೆ ತೆಗೆದುಹಾಕಿದ್ದೇವೆ, ಪ್ರಮಾಣಿತ ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಬಳಸಿ ಅದೇ ತರ್ಕವನ್ನು ಅಲ್ಲಿ ಅಳವಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಈ ಸರ್ವರ್‌ಗಳು ಮಾಡಬಹುದಾದ ಬೋನಸ್ ಅನ್ನು ತಕ್ಷಣವೇ ಸ್ವೀಕರಿಸಿದ್ದೇವೆ. ಅಳೆಯಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅವರು ಅಗತ್ಯವಿರುವಷ್ಟು ಸರಳವಾಗಿ ಪೂರೈಸಬಹುದು. ಒಳ್ಳೆಯದು, ಬಾಹ್ಯ ಬಳಕೆದಾರರಿಗೆ ನಾವು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ ಎಂಬುದು ಕೇವಲ ನಕಾರಾತ್ಮಕವಾಗಿದೆ. ಆದರೆ ಆ ಕ್ಷಣದಲ್ಲಿ ನಾವು ಇದನ್ನು ತ್ಯಾಗ ಮಾಡಬೇಕಾಗಿತ್ತು, ಏಕೆಂದರೆ ಸಮಸ್ಯೆಯನ್ನು ತಕ್ಷಣವೇ ಪರಿಹರಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು. ಆದ್ದರಿಂದ, ನಾವು ಲೋಡ್‌ನ ಭಾಗವನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇವೆ, ಆ ಸಮಯದಲ್ಲಿ ಅದು ಸುಮಾರು 40% ಆಗಿತ್ತು, LTM ಉತ್ತಮವಾಗಿದೆ, ಮತ್ತು ಅಕ್ಷರಶಃ ಸಮಸ್ಯೆ ಪ್ರಾರಂಭವಾದ ಎರಡು ವಾರಗಳ ನಂತರ, ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 45k ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಆದರೆ 55k. ವಾಸ್ತವವಾಗಿ, ನಾವು 20% ರಷ್ಟು ಬೆಳೆದಿದ್ದೇವೆ - ಇದು ಸ್ಪಷ್ಟವಾಗಿ ನಾವು ಬಳಕೆದಾರರಿಗೆ ನೀಡದ ದಟ್ಟಣೆಯಾಗಿದೆ. ಮತ್ತು ಅದರ ನಂತರ ಅವರು ಉಳಿದ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಬೇಕೆಂದು ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು - ಹೆಚ್ಚಿನ ಬಾಹ್ಯ ಪ್ರವೇಶವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು.
ನಾವು ಸ್ವಲ್ಪ ವಿರಾಮ ಹೊಂದಿದ್ದೇವೆ, ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಇದಕ್ಕಾಗಿ ಯಾವ ಪರಿಹಾರವನ್ನು ಬಳಸುತ್ತೇವೆ ಎಂದು ಚರ್ಚಿಸಿದ್ದೇವೆ. ಕೆಲವು ಹೋಮ್ ಲಿಖಿತ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, ಡೈನಾಮಿಕ್ ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಸಹಾಯದಿಂದ ಡಿಎನ್‌ಎಸ್ ಬಳಸಿ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರಸ್ತಾಪಗಳಿವೆ ... ಹಲವು ಆಯ್ಕೆಗಳಿವೆ, ಆದರೆ ಫೋಟೋಗಳ ನಿಜವಾದ ವಿಶ್ವಾಸಾರ್ಹ ವಿತರಣೆಗಾಗಿ, ನೀವು ಇನ್ನೊಂದು ಲೇಯರ್ ಅನ್ನು ಪರಿಚಯಿಸಬೇಕಾಗಿದೆ ಎಂಬುದು ಈಗಾಗಲೇ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಇದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ. ನಾವು ಈ ಯಂತ್ರಗಳನ್ನು ಫೋಟೋ ನಿರ್ದೇಶಕರು ಎಂದು ಕರೆದಿದ್ದೇವೆ. ನಾವು ಅವಲಂಬಿಸಿರುವ ಸಾಫ್ಟ್‌ವೇರ್ Keepalived:
ಮೊದಲಿಗೆ, Keepalived ಏನು ಒಳಗೊಂಡಿದೆ? ಮೊದಲನೆಯದು VRRP ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ, ಇದು ನೆಟ್‌ವರ್ಕರ್‌ಗಳಿಗೆ ವ್ಯಾಪಕವಾಗಿ ತಿಳಿದಿದೆ, ಇದು ಕ್ಲೈಂಟ್‌ಗಳು ಸಂಪರ್ಕಿಸುವ ಬಾಹ್ಯ IP ವಿಳಾಸಕ್ಕೆ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಒದಗಿಸುವ ನೆಟ್‌ವರ್ಕ್ ಉಪಕರಣಗಳಲ್ಲಿದೆ. ಎರಡನೇ ಭಾಗವು IPVS, IP ವರ್ಚುವಲ್ ಸರ್ವರ್, ಫೋಟೋ ರೂಟರ್‌ಗಳ ನಡುವೆ ಸಮತೋಲನ ಮತ್ತು ಈ ಮಟ್ಟದಲ್ಲಿ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು. ಮತ್ತು ಮೂರನೇ - ಆರೋಗ್ಯ ತಪಾಸಣೆ.
ಮೊದಲ ಭಾಗದಿಂದ ಪ್ರಾರಂಭಿಸೋಣ: VRRP - ಅದು ಹೇಗೆ ಕಾಣುತ್ತದೆ? ಕ್ಲೈಂಟ್‌ಗಳು ಸಂಪರ್ಕಿಸುವ dns badoocdn.com ನಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ವರ್ಚುವಲ್ IP ಇದೆ. ಕೆಲವು ಸಮಯದಲ್ಲಿ, ನಾವು ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ವಿಆರ್‌ಆರ್‌ಪಿ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಕೀಪಲೈವ್ಡ್ ಪ್ಯಾಕೆಟ್‌ಗಳು ಚಲಿಸುತ್ತವೆ ಮತ್ತು ರೇಡಾರ್‌ನಿಂದ ಮಾಸ್ಟರ್ ಕಣ್ಮರೆಯಾದರೆ - ಸರ್ವರ್ ರೀಬೂಟ್ ಆಗಿದೆ ಅಥವಾ ಇನ್ನೇನಾದರೂ, ನಂತರ ಬ್ಯಾಕಪ್ ಸರ್ವರ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಈ ಐಪಿ ವಿಳಾಸವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ - ಯಾವುದೇ ಹಸ್ತಚಾಲಿತ ಕ್ರಿಯೆಗಳ ಅಗತ್ಯವಿಲ್ಲ. ಮಾಸ್ಟರ್ ಮತ್ತು ಬ್ಯಾಕ್ಅಪ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ಮುಖ್ಯವಾಗಿ ಆದ್ಯತೆಯಾಗಿದೆ: ಅದು ಹೆಚ್ಚಿನದಾಗಿದೆ, ಯಂತ್ರವು ಮಾಸ್ಟರ್ ಆಗುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. ಒಂದು ದೊಡ್ಡ ಪ್ರಯೋಜನವೆಂದರೆ ನೀವು ಸರ್ವರ್‌ನಲ್ಲಿಯೇ ಐಪಿ ವಿಳಾಸಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ, ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರ್‌ನಲ್ಲಿ ವಿವರಿಸಲು ಸಾಕು, ಮತ್ತು ಐಪಿ ವಿಳಾಸಗಳಿಗೆ ಕೆಲವು ಕಸ್ಟಮ್ ರೂಟಿಂಗ್ ನಿಯಮಗಳ ಅಗತ್ಯವಿದ್ದರೆ, ಇದನ್ನು ನೇರವಾಗಿ ಕಾನ್ಫಿಗರ್‌ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ. VRRP ಪ್ಯಾಕೇಜ್‌ನಲ್ಲಿ ವಿವರಿಸಿದಂತೆ ಅದೇ ಸಿಂಟ್ಯಾಕ್ಸ್. ನೀವು ಯಾವುದೇ ಪರಿಚಯವಿಲ್ಲದ ವಿಷಯಗಳನ್ನು ಎದುರಿಸುವುದಿಲ್ಲ.
ಇದು ಆಚರಣೆಯಲ್ಲಿ ಹೇಗೆ ಕಾಣುತ್ತದೆ? ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ? ಮಾಸ್ಟರ್ ಕಣ್ಮರೆಯಾದ ತಕ್ಷಣ, ನಮ್ಮ ಬ್ಯಾಕಪ್ ಜಾಹೀರಾತುಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಸ್ಟರ್ ಆಗುತ್ತದೆ. ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ನಾವು ಮಾಸ್ಟರ್ ಅನ್ನು ದುರಸ್ತಿ ಮಾಡಿದ್ದೇವೆ, ರೀಬೂಟ್ ಮಾಡಿದ್ದೇವೆ, Keepalived ಅನ್ನು ಹೆಚ್ಚಿಸಿದ್ದೇವೆ - ಜಾಹೀರಾತುಗಳು ಬ್ಯಾಕಪ್ಗಿಂತ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯೊಂದಿಗೆ ಬರುತ್ತವೆ, ಮತ್ತು ಬ್ಯಾಕ್ಅಪ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹಿಂತಿರುಗುತ್ತದೆ, IP ವಿಳಾಸಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಯಾವುದೇ ಹಸ್ತಚಾಲಿತ ಕ್ರಿಯೆಗಳನ್ನು ಮಾಡಬೇಕಾಗಿಲ್ಲ.
ಹೀಗಾಗಿ, ಬಾಹ್ಯ IP ವಿಳಾಸದ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಂಡಿದ್ದೇವೆ. ಮುಂದಿನ ಭಾಗವು ಬಾಹ್ಯ IP ವಿಳಾಸದಿಂದ ಈಗಾಗಲೇ ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತಿರುವ ಫೋಟೋ ರೂಟರ್‌ಗಳಿಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೇಗಾದರೂ ಸಮತೋಲನಗೊಳಿಸುವುದು. ಸಮತೋಲನ ಪ್ರೋಟೋಕಾಲ್ಗಳೊಂದಿಗೆ ಎಲ್ಲವೂ ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಇದು ಸರಳವಾದ ರೌಂಡ್-ರಾಬಿನ್, ಅಥವಾ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ವಿಷಯಗಳು, wrr, ಪಟ್ಟಿ ಸಂಪರ್ಕ ಮತ್ತು ಹೀಗೆ. ಇದನ್ನು ಮೂಲತಃ ದಸ್ತಾವೇಜನ್ನು ವಿವರಿಸಲಾಗಿದೆ, ವಿಶೇಷ ಏನೂ ಇಲ್ಲ. ಆದರೆ ವಿತರಣಾ ವಿಧಾನ ... ಇಲ್ಲಿ ನಾವು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಏಕೆ ಆರಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ. ಅವುಗಳೆಂದರೆ NAT, ಡೈರೆಕ್ಟ್ ರೂಟಿಂಗ್ ಮತ್ತು TUN. ಸತ್ಯವೆಂದರೆ ನಾವು ತಕ್ಷಣವೇ ಸೈಟ್‌ಗಳಿಂದ 100 ಗಿಗಾಬಿಟ್‌ಗಳ ದಟ್ಟಣೆಯನ್ನು ತಲುಪಿಸಲು ಯೋಜಿಸಿದ್ದೇವೆ. ನೀವು ಅಂದಾಜು ಮಾಡಿದರೆ, ನಿಮಗೆ 10 ಗಿಗಾಬಿಟ್ ಕಾರ್ಡ್‌ಗಳು ಬೇಕು, ಸರಿ? ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿ 10 ಗಿಗಾಬಿಟ್ ಕಾರ್ಡ್‌ಗಳು ಈಗಾಗಲೇ ನಮ್ಮ "ಪ್ರಮಾಣಿತ ಉಪಕರಣ" ಪರಿಕಲ್ಪನೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿದೆ. ತದನಂತರ ನಾವು ಸ್ವಲ್ಪ ದಟ್ಟಣೆಯನ್ನು ನೀಡುವುದಿಲ್ಲ, ನಾವು ಫೋಟೋಗಳನ್ನು ನೀಡುತ್ತೇವೆ ಎಂದು ನಾವು ನೆನಪಿಸಿಕೊಂಡಿದ್ದೇವೆ.
ಏನು ವಿಶೇಷ? - ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ದಟ್ಟಣೆಯ ನಡುವಿನ ಅಗಾಧ ವ್ಯತ್ಯಾಸ. ಒಳಬರುವ ದಟ್ಟಣೆ ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ, ಹೊರಹೋಗುವ ದಟ್ಟಣೆ ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ:
ನೀವು ಈ ಗ್ರಾಫ್‌ಗಳನ್ನು ನೋಡಿದರೆ, ನಿರ್ದೇಶಕರು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 200 MB ಸ್ವೀಕರಿಸುತ್ತಿರುವ ಕ್ಷಣದಲ್ಲಿ ಇದು ತುಂಬಾ ಸಾಮಾನ್ಯ ದಿನವಾಗಿದೆ ಎಂದು ನೀವು ನೋಡಬಹುದು. ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 4,500 MB ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ, ನಮ್ಮ ಅನುಪಾತವು ಸರಿಸುಮಾರು 1/22 ಆಗಿದೆ. 22 ವರ್ಕರ್ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೊರಹೋಗುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಒದಗಿಸಲು, ನಮಗೆ ಈ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುವ ಒಂದು ಮಾತ್ರ ಅಗತ್ಯವಿದೆ ಎಂಬುದು ಈಗಾಗಲೇ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಇಲ್ಲಿ ನೇರ ರೂಟಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ ನಮ್ಮ ಸಹಾಯಕ್ಕೆ ಬರುತ್ತದೆ.
ಅದು ಯಾವುದರಂತೆ ಕಾಣಿಸುತ್ತದೆ? ನಮ್ಮ ಫೋಟೋ ನಿರ್ದೇಶಕರು, ಅವರ ಟೇಬಲ್ ಪ್ರಕಾರ, ಫೋಟೋ ರೂಟರ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಗಳನ್ನು ರವಾನಿಸುತ್ತಾರೆ. ಆದರೆ ಫೋಟೋ ರೂಟರ್‌ಗಳು ರಿಟರ್ನ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನೇರವಾಗಿ ಇಂಟರ್ನೆಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತವೆ, ಅದನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಕಳುಹಿಸಿ, ಅದು ಫೋಟೋ ನಿರ್ದೇಶಕರ ಮೂಲಕ ಹಿಂತಿರುಗುವುದಿಲ್ಲ, ಹೀಗಾಗಿ, ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ಯಂತ್ರಗಳೊಂದಿಗೆ, ನಾವು ಸಂಪೂರ್ಣ ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಎಲ್ಲಾ ದಟ್ಟಣೆಯ ಪಂಪ್ ಅನ್ನು ಖಚಿತಪಡಿಸುತ್ತೇವೆ. ಸಂರಚನೆಗಳಲ್ಲಿ ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ನಾವು ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ, ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಸರಳವಾದ ಆರ್ಆರ್ ಆಗಿದೆ, ನೇರ ರೂಟಿಂಗ್ ವಿಧಾನವನ್ನು ಒದಗಿಸಿ ಮತ್ತು ನಂತರ ಎಲ್ಲಾ ನೈಜ ಸರ್ವರ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿ, ಅವುಗಳಲ್ಲಿ ಎಷ್ಟು ಇವೆ. ಯಾವುದು ಈ ಸಂಚಾರವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ನಾವು ಅಲ್ಲಿ ಒಂದು ಅಥವಾ ಎರಡು ಸರ್ವರ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಅಥವಾ ಹಲವಾರು ಸರ್ವರ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅಂತಹ ಅಗತ್ಯವು ಉದ್ಭವಿಸುತ್ತದೆ - ನಾವು ಈ ವಿಭಾಗವನ್ನು ಸಂರಚನೆಗೆ ಸೇರಿಸುತ್ತೇವೆ ಮತ್ತು ಹೆಚ್ಚು ಚಿಂತಿಸಬೇಡಿ. ನೈಜ ಸರ್ವರ್‌ಗಳ ಬದಿಯಿಂದ, ಫೋಟೋ ರೂಟರ್‌ನ ಬದಿಯಿಂದ, ಈ ವಿಧಾನಕ್ಕೆ ಅತ್ಯಂತ ಕನಿಷ್ಠ ಸಂರಚನೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ, ಇದನ್ನು ದಾಖಲಾತಿಯಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ ಮತ್ತು ಅಲ್ಲಿ ಯಾವುದೇ ಮೋಸಗಳಿಲ್ಲ.
ಅಂತಹ ಪರಿಹಾರವು ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ನ ಆಮೂಲಾಗ್ರ ಮರುವಿನ್ಯಾಸವನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ ಎಂಬುದು ವಿಶೇಷವಾಗಿ ಒಳ್ಳೆಯದು; ಇದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ; ನಾವು ಇದನ್ನು ಕನಿಷ್ಠ ವೆಚ್ಚದಲ್ಲಿ ಪರಿಹರಿಸಬೇಕಾಗಿತ್ತು. ನೀವು ನೋಡಿದರೆ , ನಂತರ ಅದು ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಇಲ್ಲಿ ನಾವು ಒಂದು ನಿರ್ದಿಷ್ಟ ವರ್ಚುವಲ್ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಪೋರ್ಟ್ 443 ನಲ್ಲಿ, ಕೇಳುತ್ತದೆ, ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಎಲ್ಲಾ ಕೆಲಸ ಮಾಡುವ ಸರ್ವರ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಸಂಪರ್ಕವು ಒಂದೇ ಆಗಿರುವುದನ್ನು ನೀವು ನೋಡಬಹುದು, ನೀಡಿ ಅಥವಾ ತೆಗೆದುಕೊಳ್ಳಿ. ನಾವು ಅದೇ ವರ್ಚುವಲ್ ಸರ್ವರ್‌ನಲ್ಲಿನ ಅಂಕಿಅಂಶಗಳನ್ನು ನೋಡಿದರೆ, ನಾವು ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳು, ಒಳಬರುವ ಸಂಪರ್ಕಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊರಹೋಗುವವುಗಳಿಲ್ಲ. ಹೊರಹೋಗುವ ಸಂಪರ್ಕಗಳು ನೇರವಾಗಿ ಕ್ಲೈಂಟ್‌ಗೆ ಹೋಗುತ್ತವೆ. ಸರಿ, ನಾವು ಅದನ್ನು ಅಸಮತೋಲನಗೊಳಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಈಗ, ನಮ್ಮ ಫೋಟೋ ರೂಟರ್‌ಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ? ಎಲ್ಲಾ ನಂತರ, ಕಬ್ಬಿಣವು ಕಬ್ಬಿಣವಾಗಿದೆ. ಇದು ಕರ್ನಲ್ ಪ್ಯಾನಿಕ್ಗೆ ಹೋಗಬಹುದು, ಅದು ಒಡೆಯಬಹುದು, ವಿದ್ಯುತ್ ಸರಬರಾಜು ಸುಟ್ಟು ಹೋಗಬಹುದು. ಯಾವುದಾದರೂ. ಅದಕ್ಕಾಗಿಯೇ ಆರೋಗ್ಯ ತಪಾಸಣೆ ಅಗತ್ಯವಿದೆ. ವ್ಯಾಪಾರದ ತರ್ಕವನ್ನು ಪರಿಶೀಲಿಸುವ ಕೆಲವು ಹೋಮ್ ಲಿಖಿತ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳವರೆಗೆ ಪೋರ್ಟ್ ಹೇಗೆ ತೆರೆದಿದೆ ಅಥವಾ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದದ್ದನ್ನು ಪರಿಶೀಲಿಸುವಷ್ಟು ಸರಳವಾಗಿರಬಹುದು.
ನಾವು ಮಧ್ಯದಲ್ಲಿ ಎಲ್ಲೋ ನಿಲ್ಲಿಸಿದ್ದೇವೆ: ನಾವು ನಿರ್ದಿಷ್ಟ ಸ್ಥಳಕ್ಕೆ https ವಿನಂತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ, ಅದು 200 ನೇ ಪ್ರತಿಕ್ರಿಯೆಯೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿದರೆ, ಈ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ, ಅದು ಜೀವಂತವಾಗಿದೆ ಮತ್ತು ಸಾಕಷ್ಟು ಆನ್ ಮಾಡಬಹುದು ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ ಸುಲಭವಾಗಿ.
ಇದು ಮತ್ತೆ ಆಚರಣೆಯಲ್ಲಿ ಹೇಗೆ ಕಾಣುತ್ತದೆ? ನಿರ್ವಹಣೆಗಾಗಿ ಸರ್ವರ್ ಅನ್ನು ಆಫ್ ಮಾಡೋಣ - BIOS ಅನ್ನು ಮಿನುಗುವುದು, ಉದಾಹರಣೆಗೆ. ಲಾಗ್‌ಗಳಲ್ಲಿ ನಾವು ತಕ್ಷಣವೇ ಕಾಲಾವಧಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಮೊದಲ ಸಾಲನ್ನು ನೋಡುತ್ತೇವೆ, ನಂತರ ಮೂರು ಪ್ರಯತ್ನಗಳ ನಂತರ ಅದನ್ನು "ವಿಫಲವಾಗಿದೆ" ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ ಮತ್ತು ಅದನ್ನು ಪಟ್ಟಿಯಿಂದ ಸರಳವಾಗಿ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.
ಎರಡನೆಯ ನಡವಳಿಕೆಯ ಆಯ್ಕೆಯು ಸಹ ಸಾಧ್ಯವಿದೆ, VS ಅನ್ನು ಶೂನ್ಯಕ್ಕೆ ಹೊಂದಿಸಿದಾಗ, ಆದರೆ ಫೋಟೋವನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಸರ್ವರ್ ಬರುತ್ತದೆ, Nginx ಅಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಸಂಪರ್ಕವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ಆರೋಗ್ಯ ತಪಾಸಣೆ ತಕ್ಷಣವೇ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ ಮತ್ತು ಸರ್ವರ್ ನಮ್ಮ ಪಟ್ಟಿಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಲೋಡ್ ಅನ್ನು ತಕ್ಷಣವೇ ಅನ್ವಯಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಕರ್ತವ್ಯ ನಿರ್ವಾಹಕರಿಂದ ಯಾವುದೇ ಹಸ್ತಚಾಲಿತ ಕ್ರಮಗಳ ಅಗತ್ಯವಿಲ್ಲ. ರಾತ್ರಿಯಲ್ಲಿ ಸರ್ವರ್ ರೀಬೂಟ್ ಆಗಿದೆ - ಮಾನಿಟರಿಂಗ್ ವಿಭಾಗವು ರಾತ್ರಿಯಲ್ಲಿ ಈ ಬಗ್ಗೆ ನಮಗೆ ಕರೆ ಮಾಡುವುದಿಲ್ಲ. ಇದು ಸಂಭವಿಸಿದೆ ಎಂದು ಅವರು ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ.
ಆದ್ದರಿಂದ, ಸಾಕಷ್ಟು ಸರಳವಾದ ರೀತಿಯಲ್ಲಿ, ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಸರ್ವರ್‌ಗಳ ಸಹಾಯದಿಂದ, ನಾವು ಬಾಹ್ಯ ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ.
ಇದೆಲ್ಲವೂ ಸಹಜವಾಗಿ ನಿಗಾ ವಹಿಸಬೇಕಾಗಿದೆ ಎಂದು ಹೇಳಲು ಉಳಿದಿದೆ. ಪ್ರತ್ಯೇಕವಾಗಿ, Keepalivede, ಬಹಳ ಹಿಂದೆಯೇ ಬರೆದ ಸಾಫ್ಟ್‌ವೇರ್‌ನಂತೆ, DBus, SMTP, SNMP ಮತ್ತು ಸ್ಟ್ಯಾಂಡರ್ಡ್ Zabbix ಮೂಲಕ ಚೆಕ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಹಲವಾರು ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ಗಮನಿಸಬೇಕು. ಜೊತೆಗೆ, ಪ್ರತಿಯೊಂದು ಸೀನುವಿಕೆಗೆ ಅಕ್ಷರಗಳನ್ನು ಬರೆಯುವುದು ಹೇಗೆ ಎಂದು ಅವನಿಗೆ ತಿಳಿದಿದೆ, ಮತ್ತು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಕೆಲವು ಸಮಯದಲ್ಲಿ ನಾವು ಅದನ್ನು ಆಫ್ ಮಾಡಲು ಸಹ ಯೋಚಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಅವರು ಯಾವುದೇ ಟ್ರಾಫಿಕ್ ಸ್ವಿಚಿಂಗ್, ಸ್ವಿಚ್ ಆನ್, ಪ್ರತಿ ಐಪಿ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಸಾಕಷ್ಟು ಪತ್ರಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ, ಮತ್ತು ಇತ್ಯಾದಿ . ಸಹಜವಾಗಿ, ಬಹಳಷ್ಟು ಸರ್ವರ್‌ಗಳು ಇದ್ದರೆ, ನೀವು ಈ ಅಕ್ಷರಗಳೊಂದಿಗೆ ನಿಮ್ಮನ್ನು ಮುಳುಗಿಸಬಹುದು. ಪ್ರಮಾಣಿತ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಫೋಟೋ ರೂಟರ್‌ಗಳಲ್ಲಿ nginx ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ಮಾನಿಟರಿಂಗ್ ದೂರ ಹೋಗಿಲ್ಲ. ಸಹಜವಾಗಿ, ನಾವು ಇನ್ನೂ ಎರಡು ವಿಷಯಗಳನ್ನು ಸಲಹೆ ಮಾಡುತ್ತೇವೆ: ಮೊದಲನೆಯದಾಗಿ, ಬಾಹ್ಯ ಆರೋಗ್ಯ ತಪಾಸಣೆ ಮತ್ತು ಲಭ್ಯತೆ, ಏಕೆಂದರೆ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದರೂ ಸಹ, ಬಾಹ್ಯ ಪೂರೈಕೆದಾರರೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ಅಥವಾ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಕಾರಣದಿಂದ ಬಳಕೆದಾರರು ಫೋಟೋಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. ಇದು ಯಾವಾಗಲೂ ಮತ್ತೊಂದು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ, ಅಮೆಜಾನ್‌ನಲ್ಲಿ ಅಥವಾ ಬೇರೆಲ್ಲಿಯಾದರೂ, ನಿಮ್ಮ ಸರ್ವರ್ಗಳನ್ನು ಹೊರಗಿನಿಂದ ಪಿಂಗ್ ಮಾಡಬಹುದಾದ ಪ್ರತ್ಯೇಕ ಯಂತ್ರವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಮತ್ತು ಟ್ರಿಕಿ ಯಂತ್ರ ಕಲಿಕೆ ಅಥವಾ ಸರಳ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿರುವವರಿಗೆ ಅಸಂಗತತೆ ಪತ್ತೆಹಚ್ಚುವಿಕೆಯನ್ನು ಬಳಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. , ಕನಿಷ್ಠ ವಿನಂತಿಗಳು ತೀವ್ರವಾಗಿ ಕುಸಿದಿದೆಯೇ ಅಥವಾ ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ಹೆಚ್ಚಿದ್ದರೆ ಟ್ರ್ಯಾಕ್ ಮಾಡಲು. ಇದು ಉಪಯುಕ್ತವೂ ಆಗಿರಬಹುದು.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳೋಣ: ನಾವು, ವಾಸ್ತವವಾಗಿ, ಕಬ್ಬಿಣದ ಹೊದಿಕೆಯ ಪರಿಹಾರವನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ, ಅದು ಕೆಲವು ಸಮಯದಲ್ಲಿ ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ, ಸಾಕಷ್ಟು ಸರಳವಾದ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಎಲ್ಲವನ್ನೂ ಒಂದೇ ರೀತಿ ಮಾಡುತ್ತದೆ, ಅಂದರೆ, ಇದು HTTPS ದಟ್ಟಣೆಯನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಮತ್ತಷ್ಟು ಸ್ಮಾರ್ಟ್ ರೂಟಿಂಗ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ ಅಗತ್ಯ ಆರೋಗ್ಯ ತಪಾಸಣೆ. ನಾವು ಈ ಸಿಸ್ಟಂನ ಸ್ಥಿರತೆಯನ್ನು ಹೆಚ್ಚಿಸಿದ್ದೇವೆ, ಅಂದರೆ, ಪ್ರತಿ ಲೇಯರ್‌ಗೆ ನಾವು ಇನ್ನೂ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಜೊತೆಗೆ ಪ್ರತಿ ಲೇಯರ್‌ನಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಅಳೆಯುವುದು ತುಂಬಾ ಸುಲಭ ಎಂಬ ಬೋನಸ್ ಅನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಇದು ಪ್ರಮಾಣಿತ ಸಾಫ್ಟ್‌ವೇರ್‌ನೊಂದಿಗೆ ಪ್ರಮಾಣಿತ ಹಾರ್ಡ್‌ವೇರ್ ಆಗಿದೆ, ಅಂದರೆ , ಸಂಭವನೀಯ ಸಮಸ್ಯೆಗಳ ರೋಗನಿರ್ಣಯವನ್ನು ನಾವು ಸರಳಗೊಳಿಸಿದ್ದೇವೆ.
ನಾವು ಏನನ್ನು ಕೊನೆಗೊಳಿಸಿದ್ದೇವೆ? 2018 ರ ಜನವರಿ ರಜಾದಿನಗಳಲ್ಲಿ ನಮಗೆ ಸಮಸ್ಯೆ ಇತ್ತು. ಮೊದಲ ಆರು ತಿಂಗಳಲ್ಲಿ ನಾವು ಈ ಯೋಜನೆಯನ್ನು ಕಾರ್ಯರೂಪಕ್ಕೆ ತಂದಾಗ, LTM ನಿಂದ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲು ನಾವು ಅದನ್ನು ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್‌ಗೆ ವಿಸ್ತರಿಸಿದ್ದೇವೆ, ನಾವು ಒಂದು ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ 40 ಗಿಗಾಬಿಟ್‌ಗಳಿಂದ 60 ಗಿಗಾಬಿಟ್‌ಗಳಿಗೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ಮಾತ್ರ ಬೆಳೆದಿದ್ದೇವೆ. ಇಡೀ 2018 ವರ್ಷವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚು ಫೋಟೋಗಳನ್ನು ಕಳುಹಿಸಲು ಸಾಧ್ಯವಾಯಿತು.
ಮೂಲ: www.habr.com