ಸೂಚನೆ. ಅನುವಾದ.: ಆಗಸ್ಟ್ ಆರಂಭದಲ್ಲಿ, Red Hat ತನ್ನ ಸೇವೆಯ ಬಳಕೆದಾರರು ಹಿಂದಿನ ತಿಂಗಳುಗಳಲ್ಲಿ ಎದುರಿಸಿದ ಪ್ರವೇಶಿಸುವಿಕೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಕುರಿತು ಸಾರ್ವಜನಿಕವಾಗಿ ಮಾತನಾಡಿತು. (ಇದು ಕಂಟೇನರ್ ಚಿತ್ರಗಳ ನೋಂದಾವಣೆಯನ್ನು ಆಧರಿಸಿದೆ, ಇದನ್ನು ಕಂಪನಿಯು CoreOS ಖರೀದಿಯೊಂದಿಗೆ ಸ್ವೀಕರಿಸಿದೆ). ಈ ಸೇವೆಯಲ್ಲಿ ನಿಮ್ಮ ಆಸಕ್ತಿಯ ಹೊರತಾಗಿಯೂ, ಕಂಪನಿಯ SRE ಎಂಜಿನಿಯರ್‌ಗಳು ಅಪಘಾತದ ಕಾರಣಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ತೊಡೆದುಹಾಕಲು ತೆಗೆದುಕೊಂಡ ಮಾರ್ಗವು ಬೋಧಪ್ರದವಾಗಿದೆ.
ಮೇ 19 ರಂದು, ಮುಂಜಾನೆ (ಈಸ್ಟರ್ನ್ ಡೇಲೈಟ್ ಟೈಮ್, EDT), quay.io ಸೇವೆಯು ಕ್ರ್ಯಾಶ್ ಆಗಿತ್ತು. ಅಪಘಾತವು quay.io ಗ್ರಾಹಕರು ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ವಿತರಿಸಲು ಒಂದು ವೇದಿಕೆಯಾಗಿ quay.io ಅನ್ನು ಬಳಸುವ ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿತು. Red Hat ಇಬ್ಬರ ನಂಬಿಕೆಯನ್ನು ಗೌರವಿಸುತ್ತದೆ.
SRE ಇಂಜಿನಿಯರ್‌ಗಳ ತಂಡವು ತಕ್ಷಣವೇ ತೊಡಗಿಸಿಕೊಂಡಿತು ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಕ್ವೇ ಸೇವೆಯನ್ನು ಸ್ಥಿರಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಿತು. ಆದಾಗ್ಯೂ, ಅವರು ಇದನ್ನು ಮಾಡುತ್ತಿರುವಾಗ, ಗ್ರಾಹಕರು ಹೊಸ ಚಿತ್ರಗಳನ್ನು ತಳ್ಳುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಳೆದುಕೊಂಡರು ಮತ್ತು ಸಾಂದರ್ಭಿಕವಾಗಿ ಮಾತ್ರ ಅವರು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಚಿತ್ರಗಳನ್ನು ಎಳೆಯಲು ಸಾಧ್ಯವಾಯಿತು. ಕೆಲವು ಅಜ್ಞಾತ ಕಾರಣಕ್ಕಾಗಿ, ಸೇವೆಯನ್ನು ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಸ್ಕೇಲ್ ಮಾಡಿದ ನಂತರ quay.io ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ.
«ಏನು ಬದಲಾಗಿದೆ?"- ಇಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಕೇಳಲಾಗುವ ಮೊದಲ ಪ್ರಶ್ನೆ ಇದು. ಸಮಸ್ಯೆಗೆ ಸ್ವಲ್ಪ ಮೊದಲು, OpenShift ಡೆಡಿಕೇಟೆಡ್ ಕ್ಲಸ್ಟರ್ (quay.io ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ) ಆವೃತ್ತಿ 4.3.19 ಗೆ ನವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ ಎಂದು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ. quay.io Red Hat OpenShift Dedicated (OSD) ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ, ನಿಯಮಿತ ನವೀಕರಣಗಳು ವಾಡಿಕೆಯಂತೆ ಮತ್ತು ಎಂದಿಗೂ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ. ಇದಲ್ಲದೆ, ಹಿಂದಿನ ಆರು ತಿಂಗಳುಗಳಲ್ಲಿ, ಸೇವೆಯಲ್ಲಿ ಯಾವುದೇ ಅಡಚಣೆಯಿಲ್ಲದೆ ನಾವು ಹಲವಾರು ಬಾರಿ ಕ್ವೇ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ನವೀಕರಿಸಿದ್ದೇವೆ.
ನಾವು ಸೇವೆಯನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವಾಗ, ಇತರ ಎಂಜಿನಿಯರ್‌ಗಳು ಸಾಫ್ಟ್‌ವೇರ್‌ನ ಹಿಂದಿನ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಹೊಸ OSD ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು, ಇದರಿಂದ ಏನಾದರೂ ಸಂಭವಿಸಿದಲ್ಲಿ, ಅವರು ಅದರ ಮೇಲೆ ಎಲ್ಲವನ್ನೂ ನಿಯೋಜಿಸಬಹುದು.
ಮೂಲ ಕಾರಣ ವಿಶ್ಲೇಷಣೆ
ವೈಫಲ್ಯದ ಮುಖ್ಯ ಲಕ್ಷಣವೆಂದರೆ ಹತ್ತಾರು ಸಾವಿರ ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕಗಳ ಹಿಮಪಾತ, ಇದು MySQL ನಿದರ್ಶನವನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿತು. ಇದು ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಕಷ್ಟವಾಯಿತು. ಸಮಸ್ಯೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು SRE ತಂಡಕ್ಕೆ ಸಹಾಯ ಮಾಡಲು ನಾವು ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳ ಮೇಲೆ ಮಿತಿಯನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ. ಡೇಟಾಬೇಸ್‌ಗೆ ಯಾವುದೇ ಅಸಾಮಾನ್ಯ ದಟ್ಟಣೆಯನ್ನು ನಾವು ಗಮನಿಸಲಿಲ್ಲ: ವಾಸ್ತವವಾಗಿ, ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳನ್ನು ಓದಲಾಗಿದೆ ಮತ್ತು ಕೆಲವು ಮಾತ್ರ ಬರೆಯಲಾಗಿದೆ.
ಡೇಟಾಬೇಸ್ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ಈ ಹಿಮಪಾತವನ್ನು ಉಂಟುಮಾಡುವ ಮಾದರಿಯನ್ನು ಗುರುತಿಸಲು ನಾವು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ಆದಾಗ್ಯೂ, ಲಾಗ್‌ಗಳಲ್ಲಿ ನಮಗೆ ಯಾವುದೇ ಮಾದರಿಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗಲಿಲ್ಲ. OSD 4.3.18 ನೊಂದಿಗೆ ಹೊಸ ಕ್ಲಸ್ಟರ್ ಸಿದ್ಧವಾಗಲು ಕಾಯುತ್ತಿರುವಾಗ, ನಾವು quay.io ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ಮುಂದುವರಿಸಿದ್ದೇವೆ. ಪ್ರತಿ ಬಾರಿ ಕ್ಲಸ್ಟರ್ ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯವನ್ನು ತಲುಪಿದಾಗ, ಡೇಟಾಬೇಸ್ ಫ್ರೀಜ್ ಆಗುತ್ತದೆ. ಇದರರ್ಥ ಎಲ್ಲಾ quay.io ಪಾಡ್‌ಗಳ ಜೊತೆಗೆ RDS ನಿದರ್ಶನವನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಅಗತ್ಯವಾಗಿದೆ.
ಸಂಜೆಯ ಹೊತ್ತಿಗೆ, ನಾವು ಸೇವೆಯನ್ನು ಓದಲು-ಮಾತ್ರ ಮೋಡ್‌ನಲ್ಲಿ ಸ್ಥಿರಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಾಧ್ಯವಾದಷ್ಟು ಅಗತ್ಯವಲ್ಲದ ಕಾರ್ಯಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, ನೇಮ್‌ಸ್ಪೇಸ್ ಕಸ ಸಂಗ್ರಹಣೆ) ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ್ದೇವೆ. ಫ್ರೀಜ್‌ಗಳು ನಿಂತಿವೆ ಆದರೆ ಕಾರಣ ಸಿಗಲೇ ಇಲ್ಲ. ಹೊಸ OSD ಕ್ಲಸ್ಟರ್ ಸಿದ್ಧವಾಗಿದೆ, ಮತ್ತು ನಾವು ಸೇವೆಯನ್ನು ಸ್ಥಳಾಂತರಿಸಿದ್ದೇವೆ, ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಮುಂದುವರೆಸಿದ್ದೇವೆ.
Quay.io ಹೊಸ OSD ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸ್ಥಿರವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಡೇಟಾಬೇಸ್ ಲಾಗ್‌ಗಳಿಗೆ ಹಿಂತಿರುಗಿದ್ದೇವೆ, ಆದರೆ ಅಡೆತಡೆಗಳನ್ನು ವಿವರಿಸುವ ಪರಸ್ಪರ ಸಂಬಂಧವನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗಲಿಲ್ಲ. Red Hat OpenShift 4.3.19 ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳು Quay ನೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು OpenShift ಎಂಜಿನಿಯರ್‌ಗಳು ನಮ್ಮೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದರು. ಆದಾಗ್ಯೂ, ಏನೂ ಕಂಡುಬಂದಿಲ್ಲ, ಮತ್ತು ಪ್ರಯೋಗಾಲಯದ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.
ಎರಡನೇ ವೈಫಲ್ಯ
ಮೇ 28 ರಂದು, ಮಧ್ಯಾಹ್ನ EDT ಗಿಂತ ಸ್ವಲ್ಪ ಮೊದಲು, quay.io ಮತ್ತೆ ಅದೇ ರೋಗಲಕ್ಷಣದೊಂದಿಗೆ ಕ್ರ್ಯಾಶ್ ಮಾಡಿತು: ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ಮತ್ತು ಮತ್ತೊಮ್ಮೆ ನಾವು ತನಿಖೆಗೆ ನಮ್ಮ ಎಲ್ಲಾ ಪ್ರಯತ್ನಗಳನ್ನು ಎಸೆದಿದ್ದೇವೆ. ಮೊದಲನೆಯದಾಗಿ, ಸೇವೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಇದು ಅಗತ್ಯವಾಗಿತ್ತು. ಆದಾಗ್ಯೂ ಈ ಬಾರಿ RDS ಅನ್ನು ರೀಬೂಟ್ ಮಾಡುವುದು ಮತ್ತು quay.io ಪಾಡ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಯಾವುದಕ್ಕೂ ಕಾರಣವಾಗಲಿಲ್ಲ: ಸಂಪರ್ಕಗಳ ಮತ್ತೊಂದು ಹಿಮಪಾತವು ಬೇಸ್ ಅನ್ನು ಮುಳುಗಿಸಿದೆ. ಆದರೆ ಯಾಕೆ?
ಕ್ವೇ ಅನ್ನು ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಪ್ರತಿ ಪಾಡ್ ಒಂದೇ ಏಕಶಿಲೆಯ ಕಂಟೇನರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಕಂಟೇನರ್ ರನ್ಟೈಮ್ ಅನೇಕ ಸಮಾನಾಂತರ ಕಾರ್ಯಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ನಡೆಸುತ್ತದೆ. ನಾವು ಗ್ರಂಥಾಲಯವನ್ನು ಬಳಸುತ್ತೇವೆ gevent ಅಡಿಯಲ್ಲಿ gunicorn ವೆಬ್ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು. ವಿನಂತಿಯು ಕ್ವೇಗೆ ಬಂದಾಗ (ನಮ್ಮದೇ API ಮೂಲಕ, ಅಥವಾ ಡಾಕರ್ API ಮೂಲಕ), ಅದಕ್ಕೆ ಗೆವೆಂಟ್ ವರ್ಕರ್ ಅನ್ನು ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ. ವಿಶಿಷ್ಟವಾಗಿ ಈ ಕೆಲಸಗಾರ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಬೇಕು. ಮೊದಲ ವೈಫಲ್ಯದ ನಂತರ, ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಗೆವೆಂಟ್ ಕೆಲಸಗಾರರು ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸುತ್ತಿದ್ದಾರೆ ಎಂದು ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ.
ಗಮನಾರ್ಹ ಸಂಖ್ಯೆಯ ಕ್ವೇ ಪಾಡ್‌ಗಳು ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಾವಿರಾರು ಒಳಬರುವ ವಿನಂತಿಗಳನ್ನು ನೀಡಿದರೆ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕಗಳು ಸೈದ್ಧಾಂತಿಕವಾಗಿ MySQL ನಿದರ್ಶನವನ್ನು ಅತಿಕ್ರಮಿಸಬಹುದು. ಮೇಲ್ವಿಚಾರಣೆಗೆ ಧನ್ಯವಾದಗಳು, ಕ್ವೇ ಸೆಕೆಂಡಿಗೆ ಸರಾಸರಿ 5 ಸಾವಿರ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಎಂದು ತಿಳಿದುಬಂದಿದೆ. ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯು ಸರಿಸುಮಾರು ಒಂದೇ ಆಗಿರುತ್ತದೆ. 5 ಸಾವಿರ ಸಂಪರ್ಕಗಳು ನಮ್ಮ RDS ನಿದರ್ಶನದ ಸಾಮರ್ಥ್ಯದೊಳಗೆ ಚೆನ್ನಾಗಿವೆ (ಹತ್ತಾರು ಸಾವಿರದ ಬಗ್ಗೆ ಹೇಳಲಾಗುವುದಿಲ್ಲ). ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಅನಿರೀಕ್ಷಿತ ಸ್ಪೈಕ್ಗಳು ಇದ್ದವು, ಆದಾಗ್ಯೂ, ಒಳಬರುವ ವಿನಂತಿಗಳೊಂದಿಗೆ ಯಾವುದೇ ಪರಸ್ಪರ ಸಂಬಂಧವನ್ನು ನಾವು ಗಮನಿಸಲಿಲ್ಲ.
ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಸಮಸ್ಯೆಯ ಮೂಲವನ್ನು ಹುಡುಕಲು ಮತ್ತು ತೊಡೆದುಹಾಕಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ರೀಬೂಟ್‌ಗೆ ನಮ್ಮನ್ನು ಸೀಮಿತಗೊಳಿಸಬಾರದು. ಕ್ವೇ ಕೋಡ್‌ಬೇಸ್‌ಗೆ ಪ್ರತಿ ಕೆಲಸಗಾರನಿಗೆ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸಲು ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಗಿದೆ ಗೆವೆಂಟ್. ಈ ಸಂಖ್ಯೆಯು ಸಂರಚನೆಯಲ್ಲಿ ಒಂದು ನಿಯತಾಂಕವಾಯಿತು: ಹೊಸ ಕಂಟೇನರ್ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸದೆ ಅದನ್ನು ಹಾರಾಡುತ್ತ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಎಷ್ಟು ಸಂಪರ್ಕಗಳನ್ನು ವಾಸ್ತವಿಕವಾಗಿ ನಿರ್ವಹಿಸಬಹುದೆಂದು ಕಂಡುಹಿಡಿಯಲು, ನಾವು ವೇದಿಕೆಯ ಪರಿಸರದಲ್ಲಿ ಹಲವಾರು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದ್ದೇವೆ, ಇದು ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಸನ್ನಿವೇಶಗಳ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಲು ವಿಭಿನ್ನ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ. ಪರಿಣಾಮವಾಗಿ, ಅದನ್ನು ಕಂಡುಹಿಡಿಯಲಾಯಿತು ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ 502 ಸಾವಿರ ಮೀರಿದಾಗ ಕ್ವೇ 10 ದೋಷಗಳನ್ನು ಎಸೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
ನಾವು ತಕ್ಷಣವೇ ಈ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸಿದ್ದೇವೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕ ವೇಳಾಪಟ್ಟಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಹಿಂದೆ, ಸುಮಾರು 20 ನಿಮಿಷಗಳ ನಂತರ ಬೇಸ್ ಅನ್ನು ಲಾಕ್ ಮಾಡಲಾಗಿದೆ. 30 ತೊಂದರೆ-ಮುಕ್ತ ನಿಮಿಷಗಳ ನಂತರ ನಾವು ಭರವಸೆ ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಒಂದು ಗಂಟೆಯ ನಂತರ ನಾವು ಆತ್ಮವಿಶ್ವಾಸ ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಸೈಟ್‌ಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪುನಃಸ್ಥಾಪಿಸಿದ್ದೇವೆ ಮತ್ತು ಮರಣೋತ್ತರ ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ನಿರ್ಬಂಧಿಸುವಿಕೆಗೆ ಕಾರಣವಾಗುವ ಸಮಸ್ಯೆಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ನಿರ್ವಹಿಸಿದ ನಂತರ, ನಾವು ಅದರ ನಿಜವಾದ ಕಾರಣಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲಿಲ್ಲ. ಓಪನ್‌ಶಿಫ್ಟ್ 4.3.19 ನಲ್ಲಿನ ಯಾವುದೇ ಬದಲಾವಣೆಗಳಿಗೆ ಇದು ಸಂಬಂಧಿಸಿಲ್ಲ ಎಂದು ದೃಢಪಡಿಸಲಾಗಿದೆ, ಏಕೆಂದರೆ ಅದೇ ವಿಷಯವು ಆವೃತ್ತಿ 4.3.18 ನಲ್ಲಿ ಸಂಭವಿಸಿದೆ, ಇದು ಹಿಂದೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಕ್ವೇಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದೆ.
ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಮತ್ತೇನೋ ಅಡಗಿರುವುದು ಸ್ಪಷ್ಟವಾಗಿತ್ತು.
ವಿವರವಾದ ಅಧ್ಯಯನ
Quay.io ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದೆ ಆರು ವರ್ಷಗಳವರೆಗೆ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬಳಸಿದೆ. ಏನು ಬದಲಾಗಿದೆ? quay.io ನಲ್ಲಿ ಈ ಸಮಯದಲ್ಲಿ ದಟ್ಟಣೆಯು ಸ್ಥಿರವಾಗಿ ಬೆಳೆಯುತ್ತಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಕೆಲವು ಮಿತಿ ಮೌಲ್ಯವನ್ನು ತಲುಪಿದಂತೆ ತೋರುತ್ತಿದೆ, ಇದು ಸಂಪರ್ಕಗಳ ಹಠಾತ್ ಪ್ರಚೋದಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು. ಎರಡನೇ ವೈಫಲ್ಯದ ನಂತರ ನಾವು ಡೇಟಾಬೇಸ್ ಲಾಗ್‌ಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಿದ್ದೇವೆ, ಆದರೆ ಯಾವುದೇ ಮಾದರಿಗಳು ಅಥವಾ ಸ್ಪಷ್ಟ ಸಂಬಂಧಗಳು ಕಂಡುಬಂದಿಲ್ಲ.
ಈ ಮಧ್ಯೆ, ಎಸ್‌ಆರ್‌ಇ ತಂಡವು ಕ್ವೇಯ ವಿನಂತಿಯ ವೀಕ್ಷಣಾ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಒಟ್ಟಾರೆ ಸೇವೆಯ ಆರೋಗ್ಯಕ್ಕೆ ಸುಧಾರಣೆಗಳನ್ನು ಮಾಡುತ್ತಿದೆ. ಹೊಸ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ, ಕ್ವೇಯ ಯಾವ ಭಾಗಗಳು ಗ್ರಾಹಕರಿಂದ ಹೆಚ್ಚು ಬೇಡಿಕೆಯಲ್ಲಿವೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
Quay.io ಜೂನ್ 9 ರವರೆಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದೆ. ಇಂದು ಬೆಳಿಗ್ಗೆ (EDT) ನಾವು ಮತ್ತೊಮ್ಮೆ ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳವನ್ನು ಕಂಡಿದ್ದೇವೆ. ಈ ಬಾರಿ ಯಾವುದೇ ಅಲಭ್ಯತೆ ಇರಲಿಲ್ಲ, ಹೊಸ ಪ್ಯಾರಾಮೀಟರ್ ಅವರ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸಿರುವುದರಿಂದ ಮತ್ತು ಅವುಗಳನ್ನು MySQL ಥ್ರೋಪುಟ್ ಅನ್ನು ಮೀರಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಸುಮಾರು ಅರ್ಧ ಘಂಟೆಯವರೆಗೆ, ಅನೇಕ ಬಳಕೆದಾರರು quay.io ನ ನಿಧಾನಗತಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಗಮನಿಸಿದರು. ಸೇರಿಸಲಾದ ಮಾನಿಟರಿಂಗ್ ಪರಿಕರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಎಲ್ಲಾ ಸಂಭವನೀಯ ಡೇಟಾವನ್ನು ತ್ವರಿತವಾಗಿ ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಒಂದು ಮಾದರಿ ಹೊರಹೊಮ್ಮಿತು.
ಸಂಪರ್ಕಗಳ ಉಲ್ಬಣಕ್ಕೆ ಸ್ವಲ್ಪ ಮೊದಲು, ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿ API ಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಿನಂತಿಗಳನ್ನು ಮಾಡಲಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿ quay.io ನ ಸ್ವಲ್ಪ ತಿಳಿದಿರುವ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ. ಶ್ರೀಮಂತ ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳು ಮತ್ತು ಕಂಟೈನರ್‌ಗಳಂತಹ ವಿಷಯಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ quay.io ಬಳಕೆದಾರರು ಈ ವೈಶಿಷ್ಟ್ಯದೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಆದರೆ Red Hat OpenShift ಇದನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತದೆ. OpenShift ನ ಭಾಗವಾಗಿ ಆಪರೇಟರ್‌ಹಬ್ ಎಲ್ಲಾ ಆಪರೇಟರ್‌ಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಈ ಆಪರೇಟರ್‌ಗಳು ಓಪನ್‌ಶಿಫ್ಟ್ ವರ್ಕ್‌ಲೋಡ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆ ಮತ್ತು ಪಾಲುದಾರ-ಕೇಂದ್ರಿತ ಕಾರ್ಯಾಚರಣಾ ಮಾದರಿಗೆ (ದಿನ 2 ಕಾರ್ಯಾಚರಣೆಗಳು) ಆಧಾರವಾಗಿದೆ.
ಪ್ರತಿ OpenShift 4 ಕ್ಲಸ್ಟರ್ ಅನುಸ್ಥಾಪನೆಗೆ ಲಭ್ಯವಿರುವ ಆಪರೇಟರ್‌ಗಳ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ಪ್ರಕಟಿಸಲು ಮತ್ತು ಈಗಾಗಲೇ ಸ್ಥಾಪಿಸಲಾದವರಿಗೆ ನವೀಕರಣಗಳನ್ನು ಒದಗಿಸಲು ಅಂತರ್ನಿರ್ಮಿತ ಆಪರೇಟರ್‌ಹಬ್‌ನಿಂದ ಆಪರೇಟರ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. OpenShift 4 ನ ಹೆಚ್ಚುತ್ತಿರುವ ಜನಪ್ರಿಯತೆಯೊಂದಿಗೆ, ಪ್ರಪಂಚದಾದ್ಯಂತ ಅದರ ಮೇಲೆ ಕ್ಲಸ್ಟರ್‌ಗಳ ಸಂಖ್ಯೆಯೂ ಹೆಚ್ಚಾಗಿದೆ. ಈ ಪ್ರತಿಯೊಂದು ಕ್ಲಸ್ಟರ್‌ಗಳು ಅಂತರ್ನಿರ್ಮಿತ ಆಪರೇಟರ್‌ಹಬ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಆಪರೇಟರ್ ವಿಷಯವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ, quay.io ಒಳಗೆ ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಬ್ಯಾಕೆಂಡ್ ಆಗಿ ಬಳಸುತ್ತದೆ. ಸಮಸ್ಯೆಯ ಮೂಲಕ್ಕಾಗಿ ನಮ್ಮ ಹುಡುಕಾಟದಲ್ಲಿ, OpenShift ಕ್ರಮೇಣ ಜನಪ್ರಿಯತೆ ಹೆಚ್ಚಾದಂತೆ, ಅಪರೂಪವಾಗಿ ಬಳಸಲಾಗುವ quay.io ಫಂಕ್ಷನ್‌ಗಳಲ್ಲಿ ಒಂದಾದ ಲೋಡ್ ಕೂಡ ಹೆಚ್ಚಾಯಿತು ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಕಳೆದುಕೊಂಡಿದ್ದೇವೆ..
ನಾವು ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿ ವಿನಂತಿಯ ದಟ್ಟಣೆಯ ಕೆಲವು ವಿಶ್ಲೇಷಣೆಯನ್ನು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ರಿಜಿಸ್ಟ್ರಿ ಕೋಡ್ ಅನ್ನು ನೋಡಿದ್ದೇವೆ. ತಕ್ಷಣವೇ, ನ್ಯೂನತೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಲಾಯಿತು, ಇದರಿಂದಾಗಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಪ್ರಶ್ನೆಗಳು ಅತ್ಯುತ್ತಮವಾಗಿ ರೂಪುಗೊಂಡಿಲ್ಲ. ಹೊರೆ ಕಡಿಮೆಯಾದಾಗ ತೊಂದರೆ ಕೊಡದಿದ್ದರೂ ಹೊರೆ ಹೆಚ್ಚಾದಾಗ ಸಮಸ್ಯೆಗಳ ಆಗರವಾದವು. ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿಯು ಎರಡು ಸಮಸ್ಯಾತ್ಮಕ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದು ಅದು ಹೆಚ್ಚುತ್ತಿರುವ ಲೋಡ್‌ಗೆ ಸರಿಯಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲಿಲ್ಲ: ಮೊದಲನೆಯದು ರೆಪೊಸಿಟರಿಯಲ್ಲಿನ ಎಲ್ಲಾ ಪ್ಯಾಕೇಜ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಒದಗಿಸಿತು, ಎರಡನೆಯದು ಪ್ಯಾಕೇಜ್‌ಗಾಗಿ ಎಲ್ಲಾ ಬ್ಲಾಬ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸಿತು.
ಕಾರಣಗಳ ನಿರ್ಮೂಲನೆ
ಮುಂದಿನ ವಾರದಲ್ಲಿ ನಾವು ಆಪ್ ರಿಜಿಸ್ಟ್ರಿಯ ಕೋಡ್ ಮತ್ತು ಅದರ ಪರಿಸರವನ್ನು ಉತ್ತಮಗೊಳಿಸಿದ್ದೇವೆ. ಸ್ಪಷ್ಟವಾಗಿ ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾದ SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಪುನಃ ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಅನಗತ್ಯ ಕಮಾಂಡ್ ಕರೆಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗಿದೆ tar (ಇದು ಪ್ರತಿ ಬಾರಿ ಬ್ಲಾಬ್‌ಗಳನ್ನು ಹಿಂಪಡೆಯಿದಾಗಲೂ ಓಡುತ್ತದೆ), ಎಲ್ಲಿ ಸಾಧ್ಯವೋ ಅಲ್ಲಿ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಯನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. ನಾವು ನಂತರ ವ್ಯಾಪಕವಾದ ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದ್ದೇವೆ ಮತ್ತು ಬದಲಾವಣೆಗಳ ಮೊದಲು ಮತ್ತು ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿಯ ವೇಗವನ್ನು ಹೋಲಿಸಿದ್ದೇವೆ.
ಈ ಹಿಂದೆ ಅರ್ಧ ನಿಮಿಷದವರೆಗೆ ತೆಗೆದುಕೊಂಡ API ವಿನಂತಿಗಳು ಈಗ ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಪೂರ್ಣಗೊಂಡಿವೆ. ಮುಂದಿನ ವಾರ ನಾವು ಉತ್ಪಾದನೆಗೆ ಬದಲಾವಣೆಗಳನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ ಮತ್ತು ಅಂದಿನಿಂದ quay.io ಸ್ಥಿರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. ಈ ಸಮಯದಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನಲ್ಲಿ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ಹಲವಾರು ತೀಕ್ಷ್ಣವಾದ ಸ್ಪೈಕ್ಗಳು ಕಂಡುಬಂದವು, ಆದರೆ ಮಾಡಿದ ಸುಧಾರಣೆಗಳು ಡೇಟಾಬೇಸ್ ಸ್ಥಗಿತಗಳನ್ನು ತಡೆಯಿತು.
ನಾವು ಏನು ಕಲಿತಿದ್ದೇವೆ?
ಯಾವುದೇ ಸೇವೆಯು ಅಲಭ್ಯತೆಯನ್ನು ತಪ್ಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇತ್ತೀಚಿನ ನಿಲುಗಡೆಗಳು quay.io ಅನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡಿದೆ ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ. ನಾವು ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸುವ ಕೆಲವು ಪ್ರಮುಖ ಪಾಠಗಳನ್ನು ನಾವು ಕಲಿತಿದ್ದೇವೆ:
- ನಿಮ್ಮ ಸೇವೆಯನ್ನು ಯಾರು ಬಳಸುತ್ತಾರೆ ಮತ್ತು ಹೇಗೆ ಬಳಸುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು ಡೇಟಾ ಎಂದಿಗೂ ಅತಿಯಾಗಿರುವುದಿಲ್ಲ. ಕ್ವೇ "ಕೇವಲ ಕೆಲಸ ಮಾಡಿರುವುದರಿಂದ," ನಾವು ಎಂದಿಗೂ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವ ಮತ್ತು ಲೋಡ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಸಮಯವನ್ನು ಕಳೆಯಬೇಕಾಗಿಲ್ಲ. ಇದೆಲ್ಲವೂ ಸೇವೆಯು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಅಳೆಯಬಹುದು ಎಂಬ ತಪ್ಪು ಭದ್ರತೆಯ ಅರ್ಥವನ್ನು ಸೃಷ್ಟಿಸಿತು.
- ಸೇವೆ ಕಡಿಮೆಯಾದಾಗ, ಅದನ್ನು ಮರಳಿ ಪಡೆಯುವುದು ಮತ್ತು ಚಾಲನೆ ಮಾಡುವುದು ಒಂದು ಪ್ರಮುಖ ಆದ್ಯತೆಯಾಗಿದೆ.. ಮೊದಲ ಸ್ಥಗಿತದ ಸಮಯದಲ್ಲಿ ಕ್ವೇ ಲಾಕ್ಡ್ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಬಳಲುತ್ತಿರುವ ಕಾರಣ, ನಮ್ಮ ಪ್ರಮಾಣಿತ ಕಾರ್ಯವಿಧಾನಗಳು ಉದ್ದೇಶಿತ ಪರಿಣಾಮವನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಅವುಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸೇವೆಯನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಇದು ಮೂಲ ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯುವ ಭರವಸೆಯಲ್ಲಿ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಮತ್ತು ಸಂಗ್ರಹಿಸಲು ಸಮಯವನ್ನು ಕಳೆಯಬೇಕಾದ ಪರಿಸ್ಥಿತಿಗೆ ಕಾರಣವಾಯಿತು - ಬದಲಿಗೆ ಕ್ರಿಯಾತ್ಮಕತೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಎಲ್ಲಾ ಪ್ರಯತ್ನಗಳನ್ನು ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ.
- ಪ್ರತಿ ಸೇವೆಯ ವೈಶಿಷ್ಟ್ಯದ ಪ್ರಭಾವವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ. ಗ್ರಾಹಕರು ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಅಪರೂಪವಾಗಿ ಬಳಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ನಮ್ಮ ತಂಡಕ್ಕೆ ಇದು ಆದ್ಯತೆಯಾಗಿರಲಿಲ್ಲ. ಕೆಲವು ಉತ್ಪನ್ನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಕೇವಲ ಬಳಸಿದಾಗ, ಅವುಗಳ ದೋಷಗಳು ವಿರಳವಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳು ಕೋಡ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತಾರೆ. ಇದು ಹೀಗಿರಬೇಕು ಎಂಬ ತಪ್ಪು ಕಲ್ಪನೆಗೆ ಬಲಿಯಾಗುವುದು ಸುಲಭ - ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಆ ಕಾರ್ಯವು ಒಂದು ಪ್ರಮುಖ ಘಟನೆಯ ಕೇಂದ್ರದಲ್ಲಿ ಕಂಡುಬರುತ್ತದೆ.
ಮುಂದಿನ ಏನು?
ಸೇವೆಯ ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಕೆಲಸವು ಎಂದಿಗೂ ನಿಲ್ಲುವುದಿಲ್ಲ ಮತ್ತು ನಾವು ಅದನ್ನು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸುತ್ತಿದ್ದೇವೆ. quay.io ನಲ್ಲಿ ಟ್ರಾಫಿಕ್ ವಾಲ್ಯೂಮ್‌ಗಳು ಬೆಳೆಯುತ್ತಲೇ ಇರುವುದರಿಂದ, ನಮ್ಮ ಗ್ರಾಹಕರ ನಂಬಿಕೆಗೆ ತಕ್ಕಂತೆ ನಾವು ಮಾಡಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ಮಾಡುವ ಜವಾಬ್ದಾರಿ ನಮ್ಮ ಮೇಲಿದೆ ಎಂದು ನಾವು ಗುರುತಿಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ನಾವು ಪ್ರಸ್ತುತ ಈ ಕೆಳಗಿನ ಕಾರ್ಯಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ:
- ಪ್ರಾಥಮಿಕ RDS ನಿದರ್ಶನದಲ್ಲಿ ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಸೂಕ್ತವಾದ ದಟ್ಟಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಸೇವೆಗೆ ಸಹಾಯ ಮಾಡಲು ಓದಲು-ಮಾತ್ರ ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿಗಳನ್ನು ನಿಯೋಜಿಸಿ.
- RDS ನಿದರ್ಶನವನ್ನು ನವೀಕರಿಸಲಾಗುತ್ತಿದೆ. ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯು ಸಮಸ್ಯೆಯಲ್ಲ. ಬದಲಿಗೆ, ನಾವು ಕೇವಲ ತಪ್ಪು ಜಾಡು ತೆಗೆದುಹಾಕಲು ಬಯಸುತ್ತೇವೆ (ನಾವು ವೈಫಲ್ಯದ ಸಮಯದಲ್ಲಿ ಅನುಸರಿಸಿದ್ದೇವೆ); ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ನವೀಕೃತವಾಗಿರಿಸುವುದು ಭವಿಷ್ಯದ ಸ್ಥಗಿತಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಮತ್ತೊಂದು ಅಂಶವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
- ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ನಾದ್ಯಂತ ಹೆಚ್ಚುವರಿ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆ. ಕ್ಯಾಶಿಂಗ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಪ್ರದೇಶಗಳನ್ನು ನಾವು ಹುಡುಕುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.
- quay.io ಗೆ ಯಾರು ಸಂಪರ್ಕಿಸುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಏಕೆ ಎಂದು ನೋಡಲು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಫೈರ್‌ವಾಲ್ (WAF) ಅನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ.
- ಮುಂದಿನ ಬಿಡುಗಡೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, Red Hat OpenShift ಕ್ಲಸ್ಟರ್‌ಗಳು quay.io ನಲ್ಲಿ ಲಭ್ಯವಿರುವ ಕಂಟೈನರ್ ಚಿತ್ರಗಳ ಆಧಾರದ ಮೇಲೆ ಆಪರೇಟರ್ ಕ್ಯಾಟಲಾಗ್‌ಗಳ ಪರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ತ್ಯಜಿಸುತ್ತವೆ.
- ಆಪ್ ರಿಜಿಸ್ಟ್ರಿಗೆ ದೀರ್ಘಾವಧಿಯ ಬದಲಿಯಾಗಿ ಓಪನ್ ಕಂಟೈನರ್ ಇನಿಶಿಯೇಟಿವ್ (ಒಸಿಐ) ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ವಿಶೇಷಣಗಳಿಗೆ ಬೆಂಬಲವಾಗಿರಬಹುದು. ಇದನ್ನು ಪ್ರಸ್ತುತ ಸ್ಥಳೀಯ ಕ್ವೇ ಕಾರ್ಯನಿರ್ವಹಣೆಯಾಗಿ ಅಳವಡಿಸಲಾಗಿದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟತೆಯನ್ನು ಸ್ವತಃ ಅಂತಿಮಗೊಳಿಸಿದಾಗ ಬಳಕೆದಾರರಿಗೆ ಲಭ್ಯವಿರುತ್ತದೆ.
ನಾವು ಸಣ್ಣ "ಸ್ಟಾರ್ಟ್‌ಅಪ್-ಸ್ಟೈಲ್" ತಂಡದಿಂದ ಪ್ರಬುದ್ಧ SRE-ಚಾಲಿತ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಚಲಿಸುವಾಗ ಮೇಲಿನ ಎಲ್ಲಾ Red Hat ನ quay.io ನಲ್ಲಿ ನಡೆಯುತ್ತಿರುವ ಹೂಡಿಕೆಯ ಭಾಗವಾಗಿದೆ. ನಮ್ಮ ಅನೇಕ ಗ್ರಾಹಕರು ತಮ್ಮ ದೈನಂದಿನ ಕೆಲಸದಲ್ಲಿ (Red Hat! ಸೇರಿದಂತೆ) quay.io ಅನ್ನು ಅವಲಂಬಿಸಿದ್ದಾರೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ ಮತ್ತು ಇತ್ತೀಚಿನ ಸ್ಥಗಿತಗಳು ಮತ್ತು ಸುಧಾರಿಸಲು ನಡೆಯುತ್ತಿರುವ ಪ್ರಯತ್ನಗಳ ಬಗ್ಗೆ ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ಪಾರದರ್ಶಕವಾಗಿರಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.
ಅನುವಾದಕರಿಂದ PS
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «».
ಮೂಲ: www.habr.com