ಮುಂದಿನ HighLoad++ ಕಾನ್ಫರೆನ್ಸ್ ಏಪ್ರಿಲ್ 6 ಮತ್ತು 7, 2020 ರಂದು ಸೇಂಟ್ ಪೀಟರ್ಸ್‌ಬರ್ಗ್‌ನಲ್ಲಿ ನಡೆಯಲಿದೆ ವಿವರಗಳು ಮತ್ತು ಟಿಕೆಟ್‌ಗಳು . ಹೈಲೋಡ್ ++ ಮಾಸ್ಕೋ 2018. ಹಾಲ್ "ಮಾಸ್ಕೋ". ನವೆಂಬರ್ 9, 15:00. ಪ್ರಬಂಧಗಳು ಮತ್ತು .
* ಮಾನಿಟರಿಂಗ್ - ಆನ್‌ಲೈನ್ ಮತ್ತು ವಿಶ್ಲೇಷಣೆ.
* ZABBIX ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಮೂಲಭೂತ ಮಿತಿಗಳು.
* ಸ್ಕೇಲಿಂಗ್ ಅನಾಲಿಟಿಕ್ಸ್ ಸಂಗ್ರಹಣೆಗೆ ಪರಿಹಾರ.
* ZABBIX ಸರ್ವರ್‌ನ ಆಪ್ಟಿಮೈಸೇಶನ್.
* UI ಆಪ್ಟಿಮೈಸೇಶನ್.
* 40k NVPS ಗಿಂತ ಹೆಚ್ಚಿನ ಲೋಡ್‌ಗಳ ಅಡಿಯಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಅನುಭವ.
* ಸಂಕ್ಷಿಪ್ತ ತೀರ್ಮಾನಗಳು.
ಮಿಖಾಯಿಲ್ ಮಕುರೊವ್ (ಇನ್ನು ಮುಂದೆ - ಎಂಎಂ): - ಎಲ್ಲರಿಗು ನಮಸ್ಖರ!
ಮ್ಯಾಕ್ಸಿಮ್ ಚೆರ್ನೆಟ್ಸೊವ್ (ಇನ್ನು ಮುಂದೆ - MCH): - ಶುಭ ಅಪರಾಹ್ನ!
MM: - ನಾನು ಮ್ಯಾಕ್ಸಿಮ್ ಅನ್ನು ಪರಿಚಯಿಸುತ್ತೇನೆ. ಮ್ಯಾಕ್ಸ್ ಒಬ್ಬ ಪ್ರತಿಭಾವಂತ ಎಂಜಿನಿಯರ್, ನನಗೆ ತಿಳಿದಿರುವ ಅತ್ಯುತ್ತಮ ನೆಟ್‌ವರ್ಕರ್. ಮ್ಯಾಕ್ಸಿಮ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳು, ಅವುಗಳ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದೆ.
MCH: - ಮತ್ತು ನಾನು ಮಿಖಾಯಿಲ್ ಬಗ್ಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ಮಿಖಾಯಿಲ್ ಸಿ ಡೆವಲಪರ್. ಅವರು ನಮ್ಮ ಕಂಪನಿಗೆ ಹಲವಾರು ಹೈ-ಲೋಡ್ ಟ್ರಾಫಿಕ್ ಪ್ರೊಸೆಸಿಂಗ್ ಪರಿಹಾರಗಳನ್ನು ಬರೆದಿದ್ದಾರೆ. ನಾವು ಇಂಟರ್ಸ್ವ್ಯಾಜ್ ಕಂಪನಿಯಲ್ಲಿ ಕಠಿಣ ಪುರುಷರ ಚೆಲ್ಯಾಬಿನ್ಸ್ಕ್ ನಗರದಲ್ಲಿ ಯುರಲ್ಸ್ನಲ್ಲಿ ವಾಸಿಸುತ್ತೇವೆ ಮತ್ತು ಕೆಲಸ ಮಾಡುತ್ತೇವೆ. ನಮ್ಮ ಕಂಪನಿಯು 16 ನಗರಗಳಲ್ಲಿ ಒಂದು ಮಿಲಿಯನ್ ಜನರಿಗೆ ಇಂಟರ್ನೆಟ್ ಮತ್ತು ಕೇಬಲ್ ಟೆಲಿವಿಷನ್ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುತ್ತಿದೆ.
MM: - ಮತ್ತು ಇಂಟರ್ಸ್ವ್ಯಾಜ್ ಕೇವಲ ಪೂರೈಕೆದಾರರಿಗಿಂತ ಹೆಚ್ಚು ಎಂದು ಹೇಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ, ಇದು ಐಟಿ ಕಂಪನಿಯಾಗಿದೆ. ನಮ್ಮ ಹೆಚ್ಚಿನ ಪರಿಹಾರಗಳನ್ನು ನಮ್ಮ ಐಟಿ ಇಲಾಖೆಯಿಂದ ಮಾಡಲಾಗಿದೆ.
ಉ: ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಸರ್ವರ್‌ಗಳಿಂದ ಕಾಲ್ ಸೆಂಟರ್ ಮತ್ತು ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ. ಐಟಿ ಇಲಾಖೆಯು ಈಗ ಸುಮಾರು 80 ಜನರನ್ನು ಬಹಳ ವೈವಿಧ್ಯಮಯ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದೆ.
ಜಬ್ಬಿಕ್ಸ್ ಮತ್ತು ಅದರ ವಾಸ್ತುಶಿಲ್ಪದ ಬಗ್ಗೆ
MCH: - ಮತ್ತು ಈಗ ನಾನು ವೈಯಕ್ತಿಕ ದಾಖಲೆಯನ್ನು ಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ ಮತ್ತು ಜಬ್ಬಿಕ್ಸ್ ಏನೆಂದು ಒಂದು ನಿಮಿಷದಲ್ಲಿ ಹೇಳುತ್ತೇನೆ (ಇನ್ನು ಮುಂದೆ "ಝಬ್ಬಿಕ್ಸ್" ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ).
Zabbix ತನ್ನನ್ನು ಒಂದು ಎಂಟರ್‌ಪ್ರೈಸ್-ಲೆವೆಲ್ ಔಟ್-ಆಫ್-ದಿ-ಬಾಕ್ಸ್ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ ಆಗಿ ಇರಿಸುತ್ತದೆ. ಇದು ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸುವ ಹಲವು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದೆ: ಸುಧಾರಿತ ಏರಿಕೆ ನಿಯಮಗಳು, ಏಕೀಕರಣಕ್ಕಾಗಿ API, ಗುಂಪು ಮಾಡುವಿಕೆ ಮತ್ತು ಹೋಸ್ಟ್‌ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳ ಸ್ವಯಂ-ಪತ್ತೆಹಚ್ಚುವಿಕೆ. Zabbix ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸ್ಕೇಲಿಂಗ್ ಉಪಕರಣಗಳನ್ನು ಹೊಂದಿದೆ - ಪ್ರಾಕ್ಸಿಗಳು. Zabbix ಒಂದು ಮುಕ್ತ ಮೂಲ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ.
ವಾಸ್ತುಶಿಲ್ಪದ ಬಗ್ಗೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ. ಇದು ಮೂರು ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಎಂದು ನಾವು ಹೇಳಬಹುದು:
- ಸರ್ವರ್. ಸಿ ಯಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಬದಲಿಗೆ ಸಂಕೀರ್ಣ ಸಂಸ್ಕರಣೆ ಮತ್ತು ಥ್ರೆಡ್ಗಳ ನಡುವೆ ಮಾಹಿತಿಯ ವರ್ಗಾವಣೆಯೊಂದಿಗೆ. ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳು ಅದರಲ್ಲಿ ನಡೆಯುತ್ತದೆ: ಸ್ವೀಕರಿಸುವುದರಿಂದ ಡೇಟಾಬೇಸ್‌ಗೆ ಉಳಿಸುವವರೆಗೆ.
- ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. Zabbix MySQL, PostreSQL ಮತ್ತು Oracle ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
- ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು PHP ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಹೆಚ್ಚಿನ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಇದು ಅಪಾಚೆ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಬರುತ್ತದೆ, ಆದರೆ nginx + php ಸಂಯೋಜನೆಯಲ್ಲಿ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಇಂದು ನಾವು Zabbix ಗೆ ಸಂಬಂಧಿಸಿದ ನಮ್ಮ ಕಂಪನಿಯ ಜೀವನದಿಂದ ಒಂದು ಕಥೆಯನ್ನು ಹೇಳಲು ಬಯಸುತ್ತೇವೆ ...
ಇಂಟರ್ಸ್ವ್ಯಾಜ್ ಕಂಪನಿಯ ಜೀವನದಿಂದ ಒಂದು ಕಥೆ. ನಾವು ಏನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಮಗೆ ಏನು ಬೇಕು?
5 ಅಥವಾ 6 ತಿಂಗಳ ಹಿಂದೆ. ಕೆಲಸದ ನಂತರ ಒಂದು ದಿನ ...
MCH: - ಮಿಶಾ, ಹಲೋ! ನಾನು ನಿಮ್ಮನ್ನು ಹಿಡಿಯಲು ಯಶಸ್ವಿಯಾಗಿದ್ದೇನೆ ಎಂದು ನನಗೆ ಖುಷಿಯಾಗಿದೆ - ಸಂಭಾಷಣೆ ಇದೆ. ನಾವು ಮತ್ತೆ ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ದೊಡ್ಡ ಅಪಘಾತದ ಸಮಯದಲ್ಲಿ, ಎಲ್ಲವೂ ನಿಧಾನವಾಗಿತ್ತು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್‌ನ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಯಾವುದೇ ಮಾಹಿತಿ ಇರಲಿಲ್ಲ. ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಇದೇ ಮೊದಲ ಬಾರಿಗೆ ಸಂಭವಿಸಿಲ್ಲ. ನನಗೆ ನಿನ್ನ ಸಹಾಯ ಬೇಕು. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲೂ ನಮ್ಮ ಮಾನಿಟರಿಂಗ್ ಕೆಲಸ ಮಾಡೋಣ!
MM: - ಆದರೆ ಮೊದಲು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡೋಣ. ನಾನು ಒಂದೆರಡು ವರ್ಷಗಳಿಂದ ಅಲ್ಲಿಗೆ ನೋಡಿಲ್ಲ. ನನಗೆ ನೆನಪಿರುವಂತೆ, ನಾವು ನಾಗಿಯೋಸ್ ಅನ್ನು ತ್ಯಜಿಸಿದ್ದೇವೆ ಮತ್ತು ಸುಮಾರು 8 ವರ್ಷಗಳ ಹಿಂದೆ ಜಬ್ಬಿಕ್ಸ್‌ಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ಮತ್ತು ಈಗ ನಾವು 6 ಪ್ರಬಲ ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಸುಮಾರು ಒಂದು ಡಜನ್ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಹೊಂದಿರುವಂತೆ ತೋರುತ್ತಿದೆ. ನಾನು ಏನನ್ನಾದರೂ ಗೊಂದಲಗೊಳಿಸುತ್ತಿದ್ದೇನೆಯೇ?
MCH: - ಬಹುತೇಕ. 15 ಸರ್ವರ್‌ಗಳು, ಅವುಗಳಲ್ಲಿ ಕೆಲವು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಾಗಿವೆ. ನಮಗೆ ಹೆಚ್ಚು ಅಗತ್ಯವಿರುವ ಕ್ಷಣದಲ್ಲಿ ಅದು ನಮ್ಮನ್ನು ಉಳಿಸುವುದಿಲ್ಲ ಎಂಬುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯ. ಅಪಘಾತದಂತೆ - ಸರ್ವರ್‌ಗಳು ನಿಧಾನವಾಗುತ್ತವೆ ಮತ್ತು ನೀವು ಏನನ್ನೂ ನೋಡಲಾಗುವುದಿಲ್ಲ. ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ, ಆದರೆ ಇದು ಅತ್ಯುತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳವನ್ನು ಒದಗಿಸಲಿಲ್ಲ.
MM: - ಇದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನೀವು ಏನನ್ನಾದರೂ ನೋಡಿದ್ದೀರಾ, ನೀವು ಈಗಾಗಲೇ ರೋಗನಿರ್ಣಯದಿಂದ ಏನನ್ನಾದರೂ ಅಗೆಯಿದ್ದೀರಾ?
MCH: - ನೀವು ವ್ಯವಹರಿಸಬೇಕಾದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಡೇಟಾಬೇಸ್. MySQL ನಿರಂತರವಾಗಿ ಲೋಡ್ ಆಗುತ್ತದೆ, ಹೊಸ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು Zabbix ಈವೆಂಟ್‌ಗಳ ಗುಂಪನ್ನು ಉತ್ಪಾದಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಡೇಟಾಬೇಸ್ ಅಕ್ಷರಶಃ ಕೆಲವು ಗಂಟೆಗಳ ಕಾಲ ಓವರ್‌ಡ್ರೈವ್‌ಗೆ ಹೋಗುತ್ತದೆ. ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುವ ಬಗ್ಗೆ ನಾನು ಈಗಾಗಲೇ ನಿಮಗೆ ಹೇಳಿದ್ದೇನೆ, ಆದರೆ ಅಕ್ಷರಶಃ ಈ ವರ್ಷ ಅವರು ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ನವೀಕರಿಸಿದ್ದಾರೆ: ಸರ್ವರ್‌ಗಳು SSD RAID ಗಳಲ್ಲಿ ನೂರು ಗಿಗಾಬೈಟ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಮೆಮೊರಿ ಮತ್ತು ಡಿಸ್ಕ್ ಅರೇಗಳನ್ನು ಹೊಂದಿವೆ - ದೀರ್ಘಾವಧಿಯಲ್ಲಿ ಅದನ್ನು ರೇಖೀಯವಾಗಿ ಬೆಳೆಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ನಾವು ಏನು ಮಾಡುವುದು?
MM: - ಇದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, MySQL ಒಂದು LTP ಡೇಟಾಬೇಸ್ ಆಗಿದೆ. ಸ್ಪಷ್ಟವಾಗಿ, ನಮ್ಮ ಗಾತ್ರದ ಮೆಟ್ರಿಕ್‌ಗಳ ಆರ್ಕೈವ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲು ಇದು ಇನ್ನು ಮುಂದೆ ಸೂಕ್ತವಲ್ಲ. ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ.
MCH: - ಮಾಡೋಣ!
ಹ್ಯಾಕಥಾನ್‌ನ ಪರಿಣಾಮವಾಗಿ ಜಬ್ಬಿಕ್ಸ್ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಏಕೀಕರಣ
ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ನಾವು ಆಸಕ್ತಿದಾಯಕ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ:
ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ಹೆಚ್ಚಿನ ಸ್ಥಳವನ್ನು ಮೆಟ್ರಿಕ್ಸ್ ಆರ್ಕೈವ್ ಆಕ್ರಮಿಸಿಕೊಂಡಿದೆ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್, ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಮತ್ತು ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ 1% ಕ್ಕಿಂತ ಕಡಿಮೆ ಬಳಸಲಾಗಿದೆ. ಆ ಹೊತ್ತಿಗೆ, ನಾವು ಒಂದು ವರ್ಷಕ್ಕೂ ಹೆಚ್ಚು ಕಾಲ ಕ್ಲಿಕ್‌ಹೌಸ್ ಆಧಾರಿತ ಬಿಗ್ ಡೇಟಾ ಪರಿಹಾರವನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ. ಚಲನೆಯ ದಿಕ್ಕು ನಮಗೆ ಸ್ಪಷ್ಟವಾಗಿತ್ತು. ನಮ್ಮ ಸ್ಪ್ರಿಂಗ್ ಹ್ಯಾಕಥಾನ್‌ನಲ್ಲಿ, ನಾನು ಸರ್ವರ್ ಮತ್ತು ಮುಂಭಾಗಕ್ಕಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗೆ Zabbix ನ ಏಕೀಕರಣವನ್ನು ಬರೆದಿದ್ದೇನೆ. ಆ ಸಮಯದಲ್ಲಿ, Zabbix ಈಗಾಗಲೇ ElasticSearch ಗೆ ಬೆಂಬಲವನ್ನು ಹೊಂದಿತ್ತು ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಹೋಲಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಕ್ಲಿಕ್‌ಹೌಸ್ ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದ ಹೋಲಿಕೆ
MM: - ಹೋಲಿಕೆಗಾಗಿ, ನಾವು Zabbix ಸರ್ವರ್ ಒದಗಿಸುವ ಅದೇ ಲೋಡ್ ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ ಮತ್ತು ಸಿಸ್ಟಮ್‌ಗಳು ಹೇಗೆ ವರ್ತಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡಿದ್ದೇವೆ. ನಾವು CURL ಅನ್ನು ಬಳಸಿಕೊಂಡು 1000 ಸಾಲುಗಳ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಬರೆದಿದ್ದೇವೆ. Zabbix ಮಾಡುವ ಲೋಡ್ ಪ್ರೊಫೈಲ್‌ಗೆ ಕ್ಲಿಕ್‌ಹೌಸ್ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತದೆ ಎಂದು ನಾವು ಮೊದಲೇ ಊಹಿಸಿದ್ದೇವೆ. ಫಲಿತಾಂಶಗಳು ನಮ್ಮ ನಿರೀಕ್ಷೆಗಳನ್ನು ಮೀರಿವೆ:
ಅದೇ ಪರೀಕ್ಷಾ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚು ಡೇಟಾವನ್ನು ಬರೆದಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೇಟಾವನ್ನು ಓದುವಾಗ ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳು ಬಹಳ ಪರಿಣಾಮಕಾರಿಯಾಗಿ (ಸಂಪನ್ಮೂಲಗಳ ಸಣ್ಣ ಪ್ರಮಾಣದ) ಸೇವಿಸುತ್ತವೆ. ಆದರೆ ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡುವಾಗ ಎಲಾಸ್ಟಿಕ್‌ಗಳಿಗೆ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಪ್ರೊಸೆಸರ್ ಅಗತ್ಯವಿದೆ:
ಒಟ್ಟಾರೆಯಾಗಿ, ಪ್ರೊಸೆಸರ್ ಬಳಕೆ ಮತ್ತು ವೇಗದ ವಿಷಯದಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್ ಎಲಾಸ್ಟಿಕ್‌ಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಉತ್ತಮವಾಗಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಡೇಟಾ ಕಂಪ್ರೆಷನ್‌ನಿಂದಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ನಲ್ಲಿ 11 ಪಟ್ಟು ಕಡಿಮೆ ಬಳಸುತ್ತದೆ ಮತ್ತು ಸರಿಸುಮಾರು 30 ಪಟ್ಟು ಕಡಿಮೆ ಡಿಸ್ಕ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ:
MCH: - ಹೌದು, ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಕೆಲಸವನ್ನು ಬಹಳ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ. ಡೇಟಾಬೇಸ್‌ಗಳಿಗಾಗಿ ನೀವು ಬೃಹತ್ SATA ಡಿಸ್ಕ್‌ಗಳನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ನೂರಾರು ಸಾವಿರ ಸಾಲುಗಳ ಬರವಣಿಗೆಯ ವೇಗವನ್ನು ಪಡೆಯಬಹುದು. ಬಾಕ್ಸ್‌ನ ಹೊರಗಿನ ವ್ಯವಸ್ಥೆಯು ಶಾರ್ಡಿಂಗ್, ಪುನರಾವರ್ತನೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ. ವರ್ಷವಿಡೀ ಅದರ ಬಳಕೆಯಿಂದ ನಾವು ಹೆಚ್ಚು ತೃಪ್ತರಾಗಿದ್ದೇವೆ.
ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು, ನಿಮ್ಮ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮುಖ್ಯ ಡೇಟಾಬೇಸ್‌ನ ಪಕ್ಕದಲ್ಲಿ ನೀವು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಆ ಮೂಲಕ ಸಾಕಷ್ಟು CPU ಸಮಯ ಮತ್ತು ಡಿಸ್ಕ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಉಳಿಸಬಹುದು. ನಾವು ಮೆಟ್ರಿಕ್‌ಗಳ ಆರ್ಕೈವ್ ಅನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಲಿಕ್‌ಹೌಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ಸರಿಸಿದ್ದೇವೆ:
ನಾವು ಮುಖ್ಯ MySQL ಡೇಟಾಬೇಸ್ ಅನ್ನು ಎಷ್ಟು ನಿವಾರಿಸಿದ್ದೇವೆ ಎಂದರೆ ನಾವು ಅದನ್ನು ಒಂದು ಗಣಕದಲ್ಲಿ Zabbix ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಬಹುದು ಮತ್ತು MySQL ಗಾಗಿ ಮೀಸಲಾದ ಸರ್ವರ್ ಅನ್ನು ತ್ಯಜಿಸಬಹುದು.
Zabbix ನಲ್ಲಿ ಮತದಾನ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?
4 ತಿಂಗಳ ಹಿಂದೆ
MM: - ಸರಿ, ಬೇಸ್ನ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ನಾವು ಮರೆಯಬಹುದೇ?
MCH: - ಅದು ಖಚಿತವಾಗಿ! ನಾವು ಪರಿಹರಿಸಬೇಕಾದ ಮತ್ತೊಂದು ಸಮಸ್ಯೆ ನಿಧಾನ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯಾಗಿದೆ. ಈಗ ನಮ್ಮ ಎಲ್ಲಾ 15 ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳು SNMP ಮತ್ತು ಮತದಾನ ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಓವರ್‌ಲೋಡ್ ಆಗಿವೆ. ಮತ್ತು ಹೊಸ ಮತ್ತು ಹೊಸ ಸರ್ವರ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.
MM: - ಗ್ರೇಟ್. ಆದರೆ ಮೊದಲು, Zabbix ನಲ್ಲಿ ಮತದಾನವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಮಗೆ ತಿಳಿಸಿ?
MCH: - ಸಂಕ್ಷಿಪ್ತವಾಗಿ, 20 ವಿಧದ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಪಡೆಯಲು ಒಂದು ಡಜನ್ ಮಾರ್ಗಗಳಿವೆ. Zabbix "ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ" ಮೋಡ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು ಅಥವಾ "ಟ್ರ್ಯಾಪರ್ ಇಂಟರ್ಫೇಸ್" ಮೂಲಕ ಹೊಸ ಡೇಟಾಕ್ಕಾಗಿ ಕಾಯಬಹುದು.
ಮೂಲ Zabbix ನಲ್ಲಿ ಈ ವಿಧಾನವು (ಟ್ರ್ಯಾಪರ್) ವೇಗವಾಗಿದೆ ಎಂದು ಗಮನಿಸಬೇಕಾದ ಅಂಶವಾಗಿದೆ.
ಲೋಡ್ ವಿತರಣೆಗಾಗಿ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳಿವೆ:
ಪ್ರಾಕ್ಸಿಗಳು Zabbix ಸರ್ವರ್‌ನಂತೆಯೇ ಅದೇ ಸಂಗ್ರಹ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸಬಹುದು, ಅದರಿಂದ ಕಾರ್ಯಗಳನ್ನು ಸ್ವೀಕರಿಸಬಹುದು ಮತ್ತು ಟ್ರ್ಯಾಪರ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಸಂಗ್ರಹಿಸಿದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಕಳುಹಿಸಬಹುದು. ಲೋಡ್ ಅನ್ನು ವಿತರಿಸಲು ಇದು ಅಧಿಕೃತವಾಗಿ ಶಿಫಾರಸು ಮಾಡಲಾದ ಮಾರ್ಗವಾಗಿದೆ. NAT ಅಥವಾ ನಿಧಾನ ಚಾನಲ್ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ದೂರಸ್ಥ ಮೂಲಸೌಕರ್ಯವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಪ್ರಾಕ್ಸಿಗಳು ಸಹ ಉಪಯುಕ್ತವಾಗಿವೆ:
MM: - ವಾಸ್ತುಶಿಲ್ಪದೊಂದಿಗೆ ಎಲ್ಲವೂ ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಾವು ಮೂಲಗಳನ್ನು ನೋಡಬೇಕಾಗಿದೆ ...
ಒಂದೆರಡು ದಿನಗಳ ನಂತರ
nmap fping ಹೇಗೆ ಗೆದ್ದಿತು ಎಂಬ ಕಥೆ
MM: "ನಾನು ಏನನ್ನಾದರೂ ಅಗೆದಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ."
MCH: - ನನಗೆ ಹೇಳು!
MM: - ಲಭ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸುವಾಗ, Zabbix ಒಂದು ಸಮಯದಲ್ಲಿ ಗರಿಷ್ಠ 128 ಹೋಸ್ಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಎಂದು ನಾನು ಕಂಡುಹಿಡಿದಿದ್ದೇನೆ. ನಾನು ಈ ಸಂಖ್ಯೆಯನ್ನು 500 ಕ್ಕೆ ಹೆಚ್ಚಿಸಲು ಪ್ರಯತ್ನಿಸಿದೆ ಮತ್ತು ಅವರ ಪಿಂಗ್ (ಪಿಂಗ್) ನಲ್ಲಿ ಇಂಟರ್-ಪ್ಯಾಕೆಟ್ ಮಧ್ಯಂತರವನ್ನು ತೆಗೆದುಹಾಕಲು ಪ್ರಯತ್ನಿಸಿದೆ - ಇದು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ದ್ವಿಗುಣಗೊಳಿಸಿದೆ. ಆದರೆ ನಾನು ದೊಡ್ಡ ಸಂಖ್ಯೆಗಳನ್ನು ಬಯಸುತ್ತೇನೆ.
MCH: - ನನ್ನ ಅಭ್ಯಾಸದಲ್ಲಿ, ನಾನು ಕೆಲವೊಮ್ಮೆ ಸಾವಿರಾರು ಹೋಸ್ಟ್‌ಗಳ ಲಭ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಇದಕ್ಕಾಗಿ ನಾನು nmap ಗಿಂತ ವೇಗವಾಗಿ ಏನನ್ನೂ ನೋಡಿಲ್ಲ. ಇದು ಅತ್ಯಂತ ವೇಗವಾದ ಮಾರ್ಗ ಎಂದು ನನಗೆ ಖಾತ್ರಿಯಿದೆ. ಇದನ್ನು ಪ್ರಯತ್ನಿಸೋಣ! ನಾವು ಪ್ರತಿ ಪುನರಾವರ್ತನೆಗೆ ಹೋಸ್ಟ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಿಸಬೇಕಾಗಿದೆ.
MM: – ಐದು ನೂರಕ್ಕೂ ಹೆಚ್ಚು ಪರಿಶೀಲಿಸಿ? 600?
MCH: - ಕನಿಷ್ಠ ಒಂದೆರಡು ಸಾವಿರ.
MM: - ಸರಿ. ನಾನು ಹೇಳಲು ಬಯಸಿದ ಪ್ರಮುಖ ವಿಷಯವೆಂದರೆ ಜಬ್ಬಿಕ್ಸ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಮತದಾನವನ್ನು ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಮಾಡಲಾಗುತ್ತದೆ ಎಂದು ನಾನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ. ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಅದನ್ನು ಅಸಮಕಾಲಿಕ ಮೋಡ್‌ಗೆ ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ. ನಂತರ ನಾವು ಪೋಲರ್‌ಗಳು ಸಂಗ್ರಹಿಸಿದ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಾಟಕೀಯವಾಗಿ ಹೆಚ್ಚಿಸಬಹುದು, ವಿಶೇಷವಾಗಿ ನಾವು ಪ್ರತಿ ಪುನರಾವರ್ತನೆಗೆ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಿದರೆ.
MCH: - ಗ್ರೇಟ್! ಮತ್ತು ಯಾವಾಗ?
MM: - ಎಂದಿನಂತೆ, ನಿನ್ನೆ.
MCH: - ನಾವು fping ಮತ್ತು nmap ಎರಡೂ ಆವೃತ್ತಿಗಳನ್ನು ಹೋಲಿಸಿದ್ದೇವೆ:
ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ, nmap ಐದು ಪಟ್ಟು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. nmap ಲಭ್ಯತೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಮಾತ್ರ ಪರಿಶೀಲಿಸುವುದರಿಂದ, ನಾವು ನಷ್ಟಗಳ ಲೆಕ್ಕಾಚಾರವನ್ನು ಟ್ರಿಗ್ಗರ್‌ಗಳಿಗೆ ಸರಿಸಿದ್ದೇವೆ ಮತ್ತು ಲಭ್ಯತೆಯ ಪರಿಶೀಲನೆಯ ಮಧ್ಯಂತರಗಳನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆಗೊಳಿಸಿದ್ದೇವೆ. nmap ಗಾಗಿ ಹೋಸ್ಟ್‌ಗಳ ಅತ್ಯುತ್ತಮ ಸಂಖ್ಯೆಯು ಪ್ರತಿ ಪುನರಾವರ್ತನೆಗೆ ಸುಮಾರು 4 ಸಾವಿರ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. Nmap ಲಭ್ಯತೆಯ ಪರಿಶೀಲನೆಗಳ CPU ವೆಚ್ಚವನ್ನು ಮೂರು ಪಟ್ಟು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಮಧ್ಯಂತರವನ್ನು 120 ಸೆಕೆಂಡುಗಳಿಂದ 10 ಕ್ಕೆ ಕಡಿಮೆ ಮಾಡಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.
ಪೋಲಿಂಗ್ ಆಪ್ಟಿಮೈಸೇಶನ್
MM: "ನಂತರ ನಾವು ಪೋಲರ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಾವು ಮುಖ್ಯವಾಗಿ SNMP ಪತ್ತೆ ಮತ್ತು ಏಜೆಂಟ್‌ಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ. ಜಬ್ಬಿಕ್ಸ್‌ನಲ್ಲಿ, ಮತದಾನವನ್ನು ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ವ್ಯವಸ್ಥೆಯ ದಕ್ಷತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ವಿಶೇಷ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ. ಸಿಂಕ್ರೊನಸ್ ಮೋಡ್‌ನಲ್ಲಿ, ಹೋಸ್ಟ್ ಅಲಭ್ಯತೆಯು ಗಮನಾರ್ಹ ಮತದಾನದ ಅವನತಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ರಾಜ್ಯಗಳ ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆ ಇದೆ, ವಿಶೇಷ ಪ್ರಕ್ರಿಯೆಗಳಿವೆ - ತಲುಪಲಾಗದ ಪೋಲರ್‌ಗಳು ಎಂದು ಕರೆಯಲ್ಪಡುವ, ಇದು ತಲುಪಲಾಗದ ಹೋಸ್ಟ್‌ಗಳೊಂದಿಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:
ಇದು ಸ್ಟೇಟ್ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸುವ ವ್ಯಾಖ್ಯಾನವಾಗಿದೆ, ಸಿಸ್ಟಮ್ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಉಳಿಯಲು ಅಗತ್ಯವಿರುವ ಪರಿವರ್ತನೆಗಳ ವ್ಯವಸ್ಥೆಯ ಎಲ್ಲಾ ಸಂಕೀರ್ಣತೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸಿಂಕ್ರೊನಸ್ ಮತದಾನವು ಸಾಕಷ್ಟು ನಿಧಾನವಾಗಿದೆ:
ಅದಕ್ಕಾಗಿಯೇ ಡಜನ್ಗಟ್ಟಲೆ ಪ್ರಾಕ್ಸಿಗಳಲ್ಲಿರುವ ಸಾವಿರಾರು ಪೋಲರ್ ಸ್ಟ್ರೀಮ್‌ಗಳು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಅಸಮಕಾಲಿಕ ಅನುಷ್ಠಾನವು ಥ್ರೆಡ್ಗಳ ಸಂಖ್ಯೆಯೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಮಾತ್ರ ಪರಿಹರಿಸಲಿಲ್ಲ, ಆದರೆ ಲಭ್ಯವಿಲ್ಲದ ಹೋಸ್ಟ್‌ಗಳ ರಾಜ್ಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸರಳಗೊಳಿಸಿತು, ಏಕೆಂದರೆ ಒಂದು ಮತದಾನ ಪುನರಾವರ್ತನೆಯಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾದ ಯಾವುದೇ ಸಂಖ್ಯೆಗೆ, ಗರಿಷ್ಠ ಕಾಯುವ ಸಮಯವು 1 ಸಮಯ ಮೀರಿದೆ:
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು SNMP ವಿನಂತಿಗಳಿಗಾಗಿ ಮತದಾನ ವ್ಯವಸ್ಥೆಯನ್ನು ಮಾರ್ಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಸುಧಾರಿಸಿದ್ದೇವೆ. ಹೆಚ್ಚಿನ ಜನರು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಅನೇಕ SNMP ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದು ಸತ್ಯ. ಆದ್ದರಿಂದ, ಅದೇ ಹೋಸ್ಟ್‌ನ SNMP ಮತದಾನವನ್ನು ಅಸಮಕಾಲಿಕವಾಗಿ ಮಾಡಿದಾಗ ನಾವು ಹೈಬ್ರಿಡ್ ಮೋಡ್ ಅನ್ನು ಮಾಡಿದ್ದೇವೆ:
ಹೋಸ್ಟ್‌ಗಳ ಸಂಪೂರ್ಣ ಪ್ಯಾಕ್‌ಗಾಗಿ ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ. ಈ ಮೋಡ್ ಅಂತಿಮವಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಅಸಮಕಾಲಿಕ ಒಂದಕ್ಕಿಂತ ನಿಧಾನವಾಗಿರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಒಂದೂವರೆ ನೂರು SNMP ಮೌಲ್ಯಗಳನ್ನು ಪೋಲಿಂಗ್ ಮಾಡುವುದು ಇನ್ನೂ 1 ಸಮಯಕ್ಕಿಂತ ಹೆಚ್ಚು ವೇಗವಾಗಿರುತ್ತದೆ.
SNMP ಮತದಾನದೊಂದಿಗೆ ಒಂದು ಪುನರಾವರ್ತನೆಯಲ್ಲಿ ವಿನಂತಿಗಳ ಸೂಕ್ತ ಸಂಖ್ಯೆಯು ಸರಿಸುಮಾರು 8 ಸಾವಿರ ಎಂದು ನಮ್ಮ ಪ್ರಯೋಗಗಳು ತೋರಿಸಿವೆ. ಒಟ್ಟಾರೆಯಾಗಿ, ಅಸಮಕಾಲಿಕ ಮೋಡ್‌ಗೆ ಪರಿವರ್ತನೆಯು ಮತದಾನದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು 200 ಬಾರಿ, ಹಲವಾರು ನೂರು ಬಾರಿ ವೇಗಗೊಳಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು.
MCH: - ಫಲಿತಾಂಶದ ಮತದಾನದ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳು ನಾವು ಎಲ್ಲಾ ಪ್ರಾಕ್ಸಿಗಳನ್ನು ತೊಡೆದುಹಾಕಲು ಮಾತ್ರವಲ್ಲ, ಅನೇಕ ಚೆಕ್‌ಗಳಿಗೆ ಮಧ್ಯಂತರಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು ಮತ್ತು ಲೋಡ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಪ್ರಾಕ್ಸಿಗಳು ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ ಎಂದು ತೋರಿಸಿದೆ.
ಸುಮಾರು ಮೂರು ತಿಂಗಳ ಹಿಂದೆ
ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಬದಲಾಯಿಸಿ - ಲೋಡ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿ!
MM: - ಸರಿ, ಮ್ಯಾಕ್ಸ್, ಇದು ಉತ್ಪಾದಕತೆಯನ್ನು ಪಡೆಯುವ ಸಮಯವೇ? ನನಗೆ ಶಕ್ತಿಯುತ ಸರ್ವರ್ ಮತ್ತು ಉತ್ತಮ ಇಂಜಿನಿಯರ್ ಬೇಕು.
MCH: - ಸರಿ, ಅದನ್ನು ಯೋಜಿಸೋಣ. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 5 ಸಾವಿರ ಮೆಟ್ರಿಕ್‌ಗಳ ಡೆಡ್ ಪಾಯಿಂಟ್‌ನಿಂದ ಚಲಿಸಲು ಇದು ಉತ್ತಮ ಸಮಯ.
ನವೀಕರಣದ ನಂತರ ಬೆಳಿಗ್ಗೆ
MCH: - ಮಿಶಾ, ನಾವು ನಮ್ಮನ್ನು ನವೀಕರಿಸಿದ್ದೇವೆ, ಆದರೆ ಬೆಳಿಗ್ಗೆ ನಾವು ಹಿಂತಿರುಗಿದ್ದೇವೆ ... ನಾವು ಯಾವ ವೇಗವನ್ನು ಸಾಧಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ಊಹಿಸಿ?
MM: - ಗರಿಷ್ಠ 20 ಸಾವಿರ.
MCH: - ಹೌದು, 25! ದುರದೃಷ್ಟವಶಾತ್, ನಾವು ಪ್ರಾರಂಭಿಸಿದ ಸ್ಥಳದಲ್ಲಿಯೇ ಇದ್ದೇವೆ.
MM: - ಏಕೆ? ನೀವು ಯಾವುದೇ ರೋಗನಿರ್ಣಯವನ್ನು ನಡೆಸಿದ್ದೀರಾ?
MCH: - ಖಂಡಿತವಾಗಿಯೂ! ಇಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಆಸಕ್ತಿದಾಯಕ ಟಾಪ್:
MM: - ನೋಡೋಣ. ನಾವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಮತದಾನದ ಎಳೆಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ ಎಂದು ನಾನು ನೋಡುತ್ತೇನೆ:
ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಅವರು ವ್ಯವಸ್ಥೆಯನ್ನು ಅರ್ಧದಷ್ಟು ಮರುಬಳಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ:
ಮತ್ತು ಒಟ್ಟಾರೆ ಕಾರ್ಯಕ್ಷಮತೆಯು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 4 ಸಾವಿರ ಮೆಟ್ರಿಕ್‌ಗಳು:
ಬೇರೆ ಏನಾದರು ಇದೆಯೇ?
MCH: - ಹೌದು, ಪೋಲರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರ ಪಟ್ಟಿ:
MM: - ಇಲ್ಲಿ ನೀವು ಮತದಾನ ಪ್ರಕ್ರಿಯೆಯು "ಸೆಮಾಫೋರ್ಸ್" ಗಾಗಿ ಕಾಯುತ್ತಿದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ನೋಡಬಹುದು. ಇವು ಬೀಗಗಳು:
MCH: - ಅಸ್ಪಷ್ಟವಾಗಿದೆ.
MM: - ನೋಡಿ, ಇದು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಒಬ್ಬರು ಮಾತ್ರ ಕೆಲಸ ಮಾಡಬಹುದಾದ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಥ್ರೆಡ್ಗಳ ಗುಂಪನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಪರಿಸ್ಥಿತಿಯನ್ನು ಹೋಲುತ್ತದೆ. ನಂತರ ಅವರು ಈ ಸಂಪನ್ಮೂಲವನ್ನು ಕಾಲಾನಂತರದಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಬಹುದು:
ಮತ್ತು ಅಂತಹ ಸಂಪನ್ಮೂಲದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಒಟ್ಟು ಕಾರ್ಯಕ್ಷಮತೆಯು ಒಂದು ಕೋರ್ನ ವೇಗದಿಂದ ಸೀಮಿತವಾಗಿದೆ:
ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಎರಡು ಮಾರ್ಗಗಳಿವೆ.
ಯಂತ್ರದ ಯಂತ್ರಾಂಶವನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಿ, ವೇಗವಾದ ಕೋರ್‌ಗಳಿಗೆ ಬದಲಿಸಿ:
ಅಥವಾ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಬದಲಾಯಿಸಿ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಲೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸಿ:
MCH: - ಮೂಲಕ, ಪರೀಕ್ಷಾ ಯಂತ್ರದಲ್ಲಿ ನಾವು ಯುದ್ಧಕ್ಕಿಂತ ಕಡಿಮೆ ಕೋರ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ, ಆದರೆ ಅವು ಪ್ರತಿ ಕೋರ್‌ಗೆ ಆವರ್ತನದಲ್ಲಿ 1,5 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ!
MM: - ಸ್ಪಷ್ಟ? ನೀವು ಸರ್ವರ್ ಕೋಡ್ ಅನ್ನು ನೋಡಬೇಕಾಗಿದೆ.
Zabbix ಸರ್ವರ್‌ನಲ್ಲಿ ಡೇಟಾ ಮಾರ್ಗ
MCH: - ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು, Zabbix ಸರ್ವರ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಹೇಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ವಿಶ್ಲೇಷಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ:
ತಂಪಾದ ಚಿತ್ರ, ಸರಿ? ಹೆಚ್ಚು ಕಡಿಮೆ ಸ್ಪಷ್ಟಪಡಿಸಲು ಹಂತ ಹಂತವಾಗಿ ಅದರ ಮೂಲಕ ಹೋಗೋಣ. ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ಥ್ರೆಡ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳಿವೆ:
ಅವರು ಸಂಗ್ರಹಿಸಿದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಾಕೆಟ್ ಮೂಲಕ ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್‌ಗೆ ರವಾನಿಸುತ್ತಾರೆ, ಅಲ್ಲಿ ಅವುಗಳನ್ನು ಸರದಿಯಲ್ಲಿ ಉಳಿಸಲಾಗುತ್ತದೆ:
"ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್" ತನ್ನ ಕೆಲಸಗಾರರಿಗೆ ಡೇಟಾವನ್ನು ರವಾನಿಸುತ್ತದೆ, ಅದು ಪ್ರಿಪ್ರೊಸೆಸಿಂಗ್ ಸೂಚನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅದೇ ಸಾಕೆಟ್ ಮೂಲಕ ಅವುಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ:
ಇದರ ನಂತರ, ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್ ಅವುಗಳನ್ನು ಇತಿಹಾಸ ಸಂಗ್ರಹದಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ:
ಅಲ್ಲಿಂದ ಅವುಗಳನ್ನು ಇತಿಹಾಸ ಸಿಂಕರ್‌ಗಳು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ, ಅವರು ಸಾಕಷ್ಟು ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತಾರೆ: ಉದಾಹರಣೆಗೆ, ಟ್ರಿಗ್ಗರ್‌ಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು, ಮೌಲ್ಯದ ಸಂಗ್ರಹವನ್ನು ತುಂಬುವುದು ಮತ್ತು, ಮುಖ್ಯವಾಗಿ, ಇತಿಹಾಸ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಉಳಿಸುವುದು. ಸಾಮಾನ್ಯವಾಗಿ, ಪ್ರಕ್ರಿಯೆಯು ಸಂಕೀರ್ಣವಾಗಿದೆ ಮತ್ತು ತುಂಬಾ ಗೊಂದಲಮಯವಾಗಿದೆ.
MM: - ನಾವು ನೋಡಿದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಹೆಚ್ಚಿನ ಥ್ರೆಡ್‌ಗಳು "ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ಯಾಶ್" (ಎಲ್ಲಾ ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾದ ಮೆಮೊರಿ ಪ್ರದೇಶ) ಎಂದು ಕರೆಯಲು ಸ್ಪರ್ಧಿಸುತ್ತವೆ. ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ಥ್ರೆಡ್‌ಗಳು ವಿಶೇಷವಾಗಿ ಬಹಳಷ್ಟು ನಿರ್ಬಂಧಿಸುತ್ತವೆ:
...ಸಂರಚನೆಯು ಅವುಗಳ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಆದರೆ ಮುಂದೆ ಏನು ಮಾಡಬೇಕೆಂಬುದರ ಬಗ್ಗೆ ಪೋಲರ್‌ಗಳು ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಸರತಿಗಳನ್ನೂ ಸಹ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಅನೇಕ ಪೋಲರ್‌ಗಳು ಇದ್ದಾಗ ಮತ್ತು ಒಬ್ಬರು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಿದಾಗ, ಇತರರು ವಿನಂತಿಗಳಿಗಾಗಿ ಕಾಯುತ್ತಾರೆ:
ಮತದಾರರು ಸಂಘರ್ಷ ಮಾಡಬಾರದು
ಆದ್ದರಿಂದ, ನಾವು ಮಾಡಿದ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಸರದಿಯನ್ನು 4 ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವುದು ಮತ್ತು ಈ ಸರತಿ ಸಾಲುಗಳನ್ನು, ಈ ಭಾಗಗಳನ್ನು ಒಂದೇ ಸಮಯದಲ್ಲಿ, ಸುರಕ್ಷಿತ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ನಿರ್ಬಂಧಿಸಲು ಪೋಲರ್‌ಗಳಿಗೆ ಅವಕಾಶ ನೀಡುವುದು:
ಇದು ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ಯಾಶ್‌ಗಾಗಿ ಸ್ಪರ್ಧೆಯನ್ನು ತೆಗೆದುಹಾಕಿತು ಮತ್ತು ಪೋಲರ್‌ಗಳ ವೇಗವು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಾಯಿತು. ಆದರೆ ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್ ಉದ್ಯೋಗಗಳ ಸರದಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಎದುರಿಸಿದ್ದೇವೆ:
ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್ ಆದ್ಯತೆ ನೀಡಲು ಶಕ್ತರಾಗಿರಬೇಕು
ಅವರು ಕಾರ್ಯಕ್ಷಮತೆಯ ಕೊರತೆಯಿರುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಸಂಭವಿಸಿತು. ನಂತರ ಅವನು ಮಾಡಬಹುದಾದ ಎಲ್ಲಾ ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ ವಿನಂತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮತ್ತು ಅದು ಎಲ್ಲಾ ಮೆಮೊರಿಯನ್ನು ಸೇವಿಸುವವರೆಗೆ ಮತ್ತು ಕ್ರ್ಯಾಶ್ ಆಗುವವರೆಗೆ ಅವುಗಳ ಬಫರ್ ಅನ್ನು ಸೇರಿಸುವುದು:
ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಎರಡನೇ ಸಾಕೆಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಕಾರ್ಮಿಕರಿಗೆ ಮೀಸಲಿಟ್ಟಿದ್ದೇವೆ:
ಹೀಗಾಗಿ, ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್ ತನ್ನ ಕೆಲಸಕ್ಕೆ ಆದ್ಯತೆ ನೀಡಲು ಅವಕಾಶವನ್ನು ಹೊಂದಿದ್ದರು ಮತ್ತು ಬಫರ್ ಬೆಳೆದರೆ, ತೆಗೆದುಹಾಕುವಿಕೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುವುದು ಕಾರ್ಯವಾಗಿದೆ, ಈ ಬಫರ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಕಾರ್ಮಿಕರಿಗೆ ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ:
ನಂತರ ನಾವು ನಿಧಾನಕ್ಕೆ ಒಂದು ಕಾರಣವೆಂದರೆ ಕೆಲಸಗಾರರೇ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಅವರು ತಮ್ಮ ಕೆಲಸಕ್ಕೆ ಸಂಪೂರ್ಣವಾಗಿ ಮುಖ್ಯವಲ್ಲದ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ಸ್ಪರ್ಧಿಸುತ್ತಿದ್ದಾರೆ. ನಾವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಬಗ್-ಫಿಕ್ಸ್ ಎಂದು ದಾಖಲಿಸಿದ್ದೇವೆ ಮತ್ತು Zabbix ನ ಹೊಸ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಇದನ್ನು ಈಗಾಗಲೇ ಪರಿಹರಿಸಲಾಗಿದೆ:
ನಾವು ಸಾಕೆಟ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇವೆ - ನಾವು ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುತ್ತೇವೆ
ಇದಲ್ಲದೆ, ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್ ಸ್ವತಃ ಒಂದು ಅಡಚಣೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಒಂದು ಥ್ರೆಡ್ ಆಗಿದೆ. ಇದು ಕೋರ್ ವೇಗದ ಮೇಲೆ ನಿಂತಿದೆ, ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 70 ಸಾವಿರ ಮೆಟ್ರಿಕ್‌ಗಳ ಗರಿಷ್ಠ ವೇಗವನ್ನು ನೀಡುತ್ತದೆ:
ಆದ್ದರಿಂದ, ನಾವು ನಾಲ್ಕು ಸೆಟ್ ಸಾಕೆಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸಗಾರರನ್ನು ತಯಾರಿಸಿದ್ದೇವೆ:
ಮತ್ತು ಇದು ವೇಗವನ್ನು ಸರಿಸುಮಾರು 130 ಸಾವಿರ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಹೆಚ್ಚಿಸಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು:
ಇತಿಹಾಸದ ಸಂಗ್ರಹಕ್ಕಾಗಿ ಸ್ಪರ್ಧೆಯು ಕಾಣಿಸಿಕೊಂಡಿದೆ ಎಂಬ ಅಂಶದಿಂದ ಬೆಳವಣಿಗೆಯ ರೇಖಾತ್ಮಕತೆಯನ್ನು ವಿವರಿಸಲಾಗಿದೆ. 4 ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್‌ಗಳು ಮತ್ತು ಹಿಸ್ಟರಿ ಸಿಂಕರ್‌ಗಳು ಇದಕ್ಕಾಗಿ ಸ್ಪರ್ಧಿಸಿದರು. ಈ ಹಂತದಲ್ಲಿ, ನಾವು ಪರೀಕ್ಷಾ ಯಂತ್ರದಲ್ಲಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸರಿಸುಮಾರು 130 ಸಾವಿರ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿದ್ದೇವೆ, ಅದನ್ನು ಸರಿಸುಮಾರು 95% ಪ್ರೊಸೆಸರ್‌ನಿಂದ ಬಳಸಿಕೊಳ್ಳುತ್ತೇವೆ:
ಸುಮಾರು 2,5 ತಿಂಗಳ ಹಿಂದೆ
snmp-ಸಮುದಾಯದಿಂದ ನಿರಾಕರಣೆ NVP ಗಳನ್ನು ಒಂದೂವರೆ ಪಟ್ಟು ಹೆಚ್ಚಿಸಿತು
MM: – ಮ್ಯಾಕ್ಸ್, ನನಗೆ ಹೊಸ ಪರೀಕ್ಷಾ ಕಾರು ಬೇಕು! ನಾವು ಇನ್ನು ಮುಂದೆ ಪ್ರಸ್ತುತಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುವುದಿಲ್ಲ.
MCH: - ನೀವು ಈಗ ಏನು ಹೊಂದಿದ್ದೀರಿ?
MM: - ಈಗ - 130k NVP ಗಳು ಮತ್ತು ಶೆಲ್ಫ್-ಸಿದ್ಧ ಪ್ರೊಸೆಸರ್.
MCH: - ಅದ್ಭುತ! ಕೂಲ್! ನಿರೀಕ್ಷಿಸಿ, ನನಗೆ ಎರಡು ಪ್ರಶ್ನೆಗಳಿವೆ. ನನ್ನ ಲೆಕ್ಕಾಚಾರದ ಪ್ರಕಾರ, ನಮ್ಮ ಅವಶ್ಯಕತೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 15-20 ಸಾವಿರ ಮೆಟ್ರಿಕ್‌ಗಳು. ನಮಗೆ ಹೆಚ್ಚು ಏಕೆ ಬೇಕು?
MM: "ನಾನು ಕೆಲಸವನ್ನು ಮುಗಿಸಲು ಬಯಸುತ್ತೇನೆ." ಈ ವ್ಯವಸ್ಥೆಯಿಂದ ನಾವು ಎಷ್ಟು ಹಿಂಡಬಹುದು ಎಂಬುದನ್ನು ನೋಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ.
MCH: - ಆದರೆ ...
MM: "ಆದರೆ ಇದು ವ್ಯವಹಾರಕ್ಕೆ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ."
MCH: - ಇದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಮತ್ತು ಎರಡನೆಯ ಪ್ರಶ್ನೆ: ಡೆವಲಪರ್‌ನ ಸಹಾಯವಿಲ್ಲದೆ ನಾವು ಈಗ ನಮ್ಮದೇ ಆದದ್ದನ್ನು ಬೆಂಬಲಿಸಬಹುದೇ?
MM: - ನಾನು ಯೋಚಿಸುವುದಿಲ್ಲ. ಕಾನ್ಫಿಗರೇಶನ್ ಕ್ಯಾಶ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುವುದು ಒಂದು ಸಮಸ್ಯೆಯಾಗಿದೆ. ಇದು ಹೆಚ್ಚಿನ ಎಳೆಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು ನಿರ್ವಹಿಸಲು ತುಂಬಾ ಕಷ್ಟ. ಹೆಚ್ಚಾಗಿ, ಅದನ್ನು ನಿರ್ವಹಿಸುವುದು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ.
MCH: "ಹಾಗಾದರೆ ನಮಗೆ ಕೆಲವು ರೀತಿಯ ಪರ್ಯಾಯ ಬೇಕು."
MM: - ಅಂತಹ ಒಂದು ಆಯ್ಕೆ ಇದೆ. ಹೊಸ ಲಾಕಿಂಗ್ ವ್ಯವಸ್ಥೆಯನ್ನು ತ್ಯಜಿಸುವಾಗ ನಾವು ವೇಗದ ಕೋರ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸಬಹುದು. ನಾವು ಇನ್ನೂ 60-80 ಸಾವಿರ ಮೆಟ್ರಿಕ್‌ಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಎಲ್ಲಾ ಉಳಿದ ಕೋಡ್ ಅನ್ನು ಬಿಡಬಹುದು. ಕ್ಲಿಕ್‌ಹೌಸ್ ಮತ್ತು ಅಸಮಕಾಲಿಕ ಮತದಾನವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ಅದನ್ನು ನಿರ್ವಹಿಸಲು ಸುಲಭವಾಗುತ್ತದೆ.
MCH: - ಅದ್ಭುತ! ಇಲ್ಲಿಗೆ ನಿಲ್ಲಿಸಲು ನಾನು ಸಲಹೆ ನೀಡುತ್ತೇನೆ.
ಸರ್ವರ್ ಸೈಡ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸಿದ ನಂತರ, ನಾವು ಅಂತಿಮವಾಗಿ ಹೊಸ ಕೋಡ್ ಅನ್ನು ಉತ್ಪಾದನೆಗೆ ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ವೇಗದ ಕೋರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಯಂತ್ರಕ್ಕೆ ಬದಲಾಯಿಸುವ ಮತ್ತು ಕೋಡ್ ಬದಲಾವಣೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಪರವಾಗಿ ನಾವು ಕೆಲವು ಬದಲಾವಣೆಗಳನ್ನು ಕೈಬಿಟ್ಟಿದ್ದೇವೆ. ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸರಳಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಡೇಟಾ ಐಟಂಗಳಲ್ಲಿ ಮ್ಯಾಕ್ರೋಗಳನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಅವುಗಳು ಹೆಚ್ಚುವರಿ ಲಾಕಿಂಗ್ ಅನ್ನು ಪರಿಚಯಿಸುತ್ತವೆ.
ಉದಾಹರಣೆಗೆ, ದಸ್ತಾವೇಜನ್ನು ಮತ್ತು ಉದಾಹರಣೆಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಕಂಡುಬರುವ snmp-ಸಮುದಾಯ ಮ್ಯಾಕ್ರೋವನ್ನು ತ್ಯಜಿಸುವುದರಿಂದ, ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ NVP ಗಳನ್ನು ಸುಮಾರು 1,5 ಪಟ್ಟು ವೇಗಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿದೆ.
ಉತ್ಪಾದನೆಯಲ್ಲಿ ಎರಡು ದಿನಗಳ ನಂತರ
ಘಟನೆ ಇತಿಹಾಸ ಪಾಪ್-ಅಪ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತಿದೆ
MCH: - ಮಿಶಾ, ನಾವು ಎರಡು ದಿನಗಳವರೆಗೆ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದಾಗ ಮಾತ್ರ! ನೆಟ್‌ವರ್ಕ್‌ನ ಸಾಕಷ್ಟು ದೊಡ್ಡ ವಿಭಾಗದ ವರ್ಗಾವಣೆಯೊಂದಿಗೆ ನಾವು ಕೆಲಸವನ್ನು ಯೋಜಿಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಮತ್ತೆ ನಮ್ಮ ಕೈಗಳಿಂದ ಏನಾಯಿತು ಮತ್ತು ಏನು ಮಾಡಲಿಲ್ಲ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ.
MM: - ಸಾಧ್ಯವಿಲ್ಲ! ನಾವು ಎಲ್ಲವನ್ನೂ 10 ಬಾರಿ ಪರಿಶೀಲಿಸಿದ್ದೇವೆ. ಸರ್ವರ್ ಸಂಪೂರ್ಣ ನೆಟ್‌ವರ್ಕ್ ಅಲಭ್ಯತೆಯನ್ನು ತಕ್ಷಣವೇ ನಿಭಾಯಿಸುತ್ತದೆ.
MCH: - ಹೌದು, ನಾನು ಎಲ್ಲವನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ: ಸರ್ವರ್, ಡೇಟಾಬೇಸ್, ಟಾಪ್, ಆಸ್ಟಾಟ್, ಲಾಗ್‌ಗಳು - ಎಲ್ಲವೂ ವೇಗವಾಗಿದೆ ... ಆದರೆ ನಾವು ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿ “ಶೆಲ್ಫ್‌ನಲ್ಲಿ” ಪ್ರೊಸೆಸರ್ ಇದೆ ಮತ್ತು ಇದು:
MM: - ಇದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ವೆಬ್ ವೀಕ್ಷಿಸೋಣ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಕ್ರಿಯ ಘಟನೆಗಳಿರುವ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಹೆಚ್ಚಿನ ಲೈವ್ ವಿಜೆಟ್‌ಗಳು ಬಹಳ ನಿಧಾನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ:
ಇದಕ್ಕೆ ಕಾರಣವೆಂದರೆ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪ್ರತಿ ಐಟಂಗೆ ರಚಿಸಲಾದ ಘಟನೆಯ ಇತಿಹಾಸದ ಪಾಪ್-ಅಪ್‌ಗಳ ಪೀಳಿಗೆಯಾಗಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ಈ ವಿಂಡೋಗಳ ಉತ್ಪಾದನೆಯನ್ನು ಕೈಬಿಟ್ಟಿದ್ದೇವೆ (ಕೋಡ್‌ನಲ್ಲಿ 5 ಸಾಲುಗಳನ್ನು ಕಾಮೆಂಟ್ ಮಾಡಿದ್ದೇವೆ), ಮತ್ತು ಇದು ನಮ್ಮ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದೆ.
ವಿಜೆಟ್‌ಗಳಿಗೆ ಲೋಡ್ ಮಾಡುವ ಸಮಯವನ್ನು, ಸಂಪೂರ್ಣವಾಗಿ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೂ ಸಹ, ಹಲವಾರು ನಿಮಿಷಗಳಿಂದ ನಮಗೆ ಸ್ವೀಕಾರಾರ್ಹ 10-15 ಸೆಕೆಂಡುಗಳವರೆಗೆ ಕಡಿಮೆ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಸಮಯದ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡುವ ಮೂಲಕ ಇತಿಹಾಸವನ್ನು ವೀಕ್ಷಿಸಬಹುದು:
ಕೆಲಸದ ನಂತರ. 2 ತಿಂಗಳುಗಳ ಹಿಂದೆ
MCH: - ಮಿಶಾ, ನೀವು ಹೊರಡುತ್ತೀರಾ? ನಾವು ಮಾತನಾಡಬೇಕು.
MM: - ನಾನು ಉದ್ದೇಶಿಸಿರಲಿಲ್ಲ. ಮತ್ತೆ Zabbix ಜೊತೆ ಏನೋ?
MCH: - ಇಲ್ಲ, ವಿಶ್ರಾಂತಿ! ನಾನು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ: ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಧನ್ಯವಾದಗಳು! ನನ್ನ ಬಳಿ ಬಿಯರ್ ಇದೆ.
Zabbix ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ
Zabbix ಸಾಕಷ್ಟು ಸಾರ್ವತ್ರಿಕ ಮತ್ತು ಶ್ರೀಮಂತ ವ್ಯವಸ್ಥೆ ಮತ್ತು ಕಾರ್ಯವಾಗಿದೆ. ಪೆಟ್ಟಿಗೆಯ ಹೊರಗೆ ಸಣ್ಣ ಅನುಸ್ಥಾಪನೆಗಳಿಗೆ ಇದನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಅಗತ್ಯಗಳು ಬೆಳೆದಂತೆ, ಅದನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬೇಕು. ಮೆಟ್ರಿಕ್‌ಗಳ ದೊಡ್ಡ ಆರ್ಕೈವ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲು, ಸೂಕ್ತವಾದ ಸಂಗ್ರಹಣೆಯನ್ನು ಬಳಸಿ:
- ನೀವು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟದೊಂದಿಗೆ ಏಕೀಕರಣದ ರೂಪದಲ್ಲಿ ಅಂತರ್ನಿರ್ಮಿತ ಸಾಧನಗಳನ್ನು ಬಳಸಬಹುದು ಅಥವಾ ಪಠ್ಯ ಫೈಲ್‌ಗಳಿಗೆ ಇತಿಹಾಸವನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಬಹುದು (ಆವೃತ್ತಿ 4 ರಿಂದ ಲಭ್ಯವಿದೆ);
- ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗೆ ನಮ್ಮ ಅನುಭವ ಮತ್ತು ಏಕೀಕರಣದ ಲಾಭವನ್ನು ನೀವು ಪಡೆಯಬಹುದು.
ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ವೇಗವನ್ನು ನಾಟಕೀಯವಾಗಿ ಹೆಚ್ಚಿಸಲು, ಅಸಮಕಾಲಿಕ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಟ್ರ್ಯಾಪರ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ Zabbix ಸರ್ವರ್‌ಗೆ ರವಾನಿಸಿ; ಅಥವಾ ನೀವು Zabbix ಪೋಲರ್‌ಗಳನ್ನು ಅಸಮಕಾಲಿಕವಾಗಿಸಲು ಪ್ಯಾಚ್ ಅನ್ನು ಬಳಸಬಹುದು.
Zabbix ಅನ್ನು C ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಸಾಕಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ. ಹಲವಾರು ವಾಸ್ತುಶಿಲ್ಪದ ಅಡಚಣೆಗಳನ್ನು ಪರಿಹರಿಸುವುದರಿಂದ ಅದರ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಇನ್ನಷ್ಟು ಹೆಚ್ಚಿಸಲು ಮತ್ತು ನಮ್ಮ ಅನುಭವದಲ್ಲಿ, ಏಕ-ಪ್ರೊಸೆಸರ್ ಯಂತ್ರದಲ್ಲಿ 100 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪಡೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಅದೇ ಜಬ್ಬಿಕ್ಸ್ ಪ್ಯಾಚ್
MM: - ನಾನು ಒಂದೆರಡು ಅಂಕಗಳನ್ನು ಸೇರಿಸಲು ಬಯಸುತ್ತೇನೆ. ಸಂಪೂರ್ಣ ಪ್ರಸ್ತುತ ವರದಿ, ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳು, ಸಂಖ್ಯೆಗಳನ್ನು ನಾವು ಬಳಸುವ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ ನೀಡಲಾಗಿದೆ. ನಾವು ಈಗ ಅದರಿಂದ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸರಿಸುಮಾರು 20 ಸಾವಿರ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದ್ದೇವೆ. ಇದು ನಿಮಗಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಹೋಲಿಸಬಹುದು. ಇಂದು ಏನು ಚರ್ಚಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಪ್ಯಾಚ್ ರೂಪದಲ್ಲಿ GitHub ನಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ:
ಪ್ಯಾಚ್ ಒಳಗೊಂಡಿದೆ:
- ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗೆ ಪೂರ್ಣ ಏಕೀಕರಣ (ಜಬ್ಬಿಕ್ಸ್ ಸರ್ವರ್ ಮತ್ತು ಮುಂಭಾಗ ಎರಡೂ);
- ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್‌ನೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವುದು;
- ಅಸಮಕಾಲಿಕ ಮತದಾನ.
ಪ್ಯಾಚ್ lts ಸೇರಿದಂತೆ ಎಲ್ಲಾ ಆವೃತ್ತಿ 4 ರೊಂದಿಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ. ಹೆಚ್ಚಾಗಿ, ಕನಿಷ್ಠ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಇದು ಆವೃತ್ತಿ 3.4 ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ನಿಮ್ಮ ಕಾಳಜಿಗೆ ಧನ್ಯವಾದಗಳು.
ಪ್ರಶ್ನೆಗಳು
ಪ್ರೇಕ್ಷಕರಿಂದ ಪ್ರಶ್ನೆ (ಇನ್ನು ಮುಂದೆ - ಎ): - ಶುಭ ಮಧ್ಯಾಹ್ನ! ದಯವಿಟ್ಟು ನನಗೆ ಹೇಳಿ, Zabbix ತಂಡದೊಂದಿಗೆ ಅಥವಾ ಅವರೊಂದಿಗೆ ನಿಮ್ಮೊಂದಿಗೆ ತೀವ್ರವಾದ ಸಂವಹನಕ್ಕಾಗಿ ನೀವು ಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದ್ದೀರಾ, ಆದ್ದರಿಂದ ಇದು ಒಂದು ಪ್ಯಾಚ್ ಅಲ್ಲ, ಆದರೆ Zabbix ನ ಸಾಮಾನ್ಯ ನಡವಳಿಕೆಯಾಗಿದೆಯೇ?
MM: - ಹೌದು, ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಕೆಲವು ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುತ್ತೇವೆ. ಏನಾದರೂ ಆಗುತ್ತದೆ, ಏನಾದರೂ ಪ್ಯಾಚ್ನಲ್ಲಿ ಉಳಿಯುತ್ತದೆ.
ಉ: - ಅತ್ಯುತ್ತಮ ವರದಿಗಾಗಿ ತುಂಬಾ ಧನ್ಯವಾದಗಳು! ದಯವಿಟ್ಟು ನನಗೆ ಹೇಳಿ, ಪ್ಯಾಚ್ ಅನ್ನು ಅನ್ವಯಿಸಿದ ನಂತರ, Zabbix ನಿಂದ ಬೆಂಬಲವು ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಉನ್ನತ ಆವೃತ್ತಿಗಳಿಗೆ ನವೀಕರಿಸುವುದನ್ನು ಹೇಗೆ ಮುಂದುವರಿಸುವುದು? ನಿಮ್ಮ ಪ್ಯಾಚ್ ನಂತರ 4.2, 5.0 ಗೆ Zabbix ಅನ್ನು ನವೀಕರಿಸಲು ಸಾಧ್ಯವೇ?
MM: - ಬೆಂಬಲದ ಬಗ್ಗೆ ನಾನು ಏನನ್ನೂ ಹೇಳಲಾರೆ. ನಾನು Zabbix ತಾಂತ್ರಿಕ ಬೆಂಬಲವಾಗಿದ್ದರೆ, ನಾನು ಬಹುಶಃ ಇಲ್ಲ ಎಂದು ಹೇಳುತ್ತೇನೆ, ಏಕೆಂದರೆ ಇದು ಬೇರೊಬ್ಬರ ಕೋಡ್ ಆಗಿದೆ. 4.2 ಕೋಡ್‌ಬೇಸ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನಮ್ಮ ಸ್ಥಾನವು ಹೀಗಿದೆ: "ನಾವು ಸಮಯದೊಂದಿಗೆ ಚಲಿಸುತ್ತೇವೆ ಮತ್ತು ಮುಂದಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ನಾವು ನಮ್ಮನ್ನು ನವೀಕರಿಸುತ್ತೇವೆ." ಆದ್ದರಿಂದ, ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ನಾವು ನವೀಕರಿಸಿದ ಆವೃತ್ತಿಗಳಿಗಾಗಿ ಪ್ಯಾಚ್ ಅನ್ನು ಪೋಸ್ಟ್ ಮಾಡುತ್ತೇವೆ. ನಾನು ಈಗಾಗಲೇ ವರದಿಯಲ್ಲಿ ಹೇಳಿದ್ದೇನೆ: ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಬದಲಾವಣೆಗಳ ಸಂಖ್ಯೆ ಇನ್ನೂ ಚಿಕ್ಕದಾಗಿದೆ. 3.4 ರಿಂದ 4 ರವರೆಗೆ ಪರಿವರ್ತನೆಯು ನಮಗೆ ಸುಮಾರು 15 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಅಲ್ಲಿ ಏನೋ ಬದಲಾಗಿದೆ, ಆದರೆ ಬಹಳ ಮುಖ್ಯವಲ್ಲ.
ಉ: - ಆದ್ದರಿಂದ ನೀವು ನಿಮ್ಮ ಪ್ಯಾಚ್ ಅನ್ನು ಬೆಂಬಲಿಸಲು ಯೋಜಿಸುತ್ತಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಅದನ್ನು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸುರಕ್ಷಿತವಾಗಿ ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಕೆಲವು ರೀತಿಯಲ್ಲಿ ನವೀಕರಣಗಳನ್ನು ಸ್ವೀಕರಿಸಬಹುದೇ?
MM: - ನಾವು ಅದನ್ನು ಬಲವಾಗಿ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಇದು ನಮಗೆ ಬಹಳಷ್ಟು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.
MCH: - ಮತ್ತೊಮ್ಮೆ, ಆರ್ಕಿಟೆಕ್ಚರ್ಗೆ ಸಂಬಂಧಿಸದ ಮತ್ತು ನಿರ್ಬಂಧಿಸುವ ಅಥವಾ ಸರತಿಗೆ ಸಂಬಂಧಿಸದ ಬದಲಾವಣೆಗಳು ಮಾಡ್ಯುಲರ್ ಆಗಿರುತ್ತವೆ, ಅವು ಪ್ರತ್ಯೇಕ ಮಾಡ್ಯೂಲ್ಗಳಲ್ಲಿವೆ ಎಂಬ ಅಂಶಕ್ಕೆ ನಾನು ಗಮನ ಸೆಳೆಯಲು ಬಯಸುತ್ತೇನೆ. ಸಣ್ಣ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಸಹ ನೀವು ಅವುಗಳನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ವಹಿಸಬಹುದು.
MM: - ನೀವು ವಿವರಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ನಂತರ "ಕ್ಲಿಕ್‌ಹೌಸ್" ಇತಿಹಾಸ ಲೈಬ್ರರಿ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ. ಇದು ಬಿಚ್ಚಲಾಗಿದೆ - ಇದು ಎಲಾಸ್ಟಿಕ್ಸ್ ಬೆಂಬಲದ ನಕಲು, ಅಂದರೆ, ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಮತದಾನವು ಮತದಾರರನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸುತ್ತದೆ. ಇದು ದೀರ್ಘಕಾಲ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ನಾವು ನಂಬುತ್ತೇವೆ.
ಉ: - ತುಂಬಾ ಧನ್ಯವಾದಗಳು. ಹೇಳಿ, ಮಾಡಿದ ಬದಲಾವಣೆಗಳ ಯಾವುದೇ ದಾಖಲಾತಿ ಇದೆಯೇ?
MM: - ದಾಖಲೆಯು ಒಂದು ಪ್ಯಾಚ್ ಆಗಿದೆ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಪರಿಚಯದೊಂದಿಗೆ, ಹೊಸ ರೀತಿಯ ಪೋಲರ್‌ಗಳ ಪರಿಚಯದೊಂದಿಗೆ, ಹೊಸ ಸಂರಚನಾ ಆಯ್ಕೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ. ಕೊನೆಯ ಸ್ಲೈಡ್‌ನಿಂದ ಲಿಂಕ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದರ ಕುರಿತು ಚಿಕ್ಕ ವಿವರಣೆಯನ್ನು ಹೊಂದಿದೆ.
fping ಅನ್ನು nmap ನೊಂದಿಗೆ ಬದಲಾಯಿಸುವ ಬಗ್ಗೆ
ಉ: - ನೀವು ಅಂತಿಮವಾಗಿ ಇದನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೀರಿ? ನೀವು ನಿರ್ದಿಷ್ಟ ಉದಾಹರಣೆಗಳನ್ನು ನೀಡಬಹುದೇ: ನೀವು ಸ್ಟ್ರಾಪರ್‌ಗಳು ಮತ್ತು ಬಾಹ್ಯ ಸ್ಕ್ರಿಪ್ಟ್ ಹೊಂದಿದ್ದೀರಾ? ಇಷ್ಟು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಅತಿಥೇಯಗಳನ್ನು ಇಷ್ಟು ಬೇಗ ಪರಿಶೀಲಿಸುವುದು ಏನು? ಈ ಹೋಸ್ಟ್‌ಗಳನ್ನು ನೀವು ಹೇಗೆ ಗಣಿಗಾರಿಕೆ ಮಾಡುತ್ತೀರಿ? ನಾವು ಅವುಗಳನ್ನು ಹೇಗಾದರೂ nmap ಗೆ ತಿನ್ನಿಸಬೇಕೇ, ಎಲ್ಲಿಂದಲಾದರೂ ತರಬೇಕು, ಹಾಕಬೇಕು, ಏನಾದರೂ ಓಡಿಸಬೇಕೇ?..
MM: - ಕೂಲ್. ಬಹಳ ಸರಿಯಾದ ಪ್ರಶ್ನೆ! ಪಾಯಿಂಟ್ ಇದು. ICMP ತಪಾಸಣೆಗಾಗಿ ನಾವು ಲೈಬ್ರರಿಯನ್ನು (ICMP ಪಿಂಗ್, Zabbix ನ ಭಾಗ) ಮಾರ್ಪಡಿಸಿದ್ದೇವೆ, ಇದು ಪ್ಯಾಕೆಟ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ - ಒಂದು (1), ಮತ್ತು ಕೋಡ್ nmap ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಅಂದರೆ, ಇದು ಜಬ್ಬಿಕ್ಸ್‌ನ ಆಂತರಿಕ ಕೆಲಸವಾಗಿದೆ, ಇದು ಪಿಂಗರ್‌ನ ಆಂತರಿಕ ಕೆಲಸವಾಗಿದೆ. ಅಂತೆಯೇ, ಯಾವುದೇ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅಥವಾ ಟ್ರ್ಯಾಪರ್ನ ಬಳಕೆಯ ಅಗತ್ಯವಿಲ್ಲ. ಸಿಸ್ಟಮ್ ಅನ್ನು ಹಾಗೇ ಬಿಡಲು ಮತ್ತು ಎರಡು ಡೇಟಾಬೇಸ್ ಸಿಸ್ಟಮ್‌ಗಳ ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ನೊಂದಿಗೆ ವ್ಯವಹರಿಸಬೇಕಾಗಿಲ್ಲದ ಸಲುವಾಗಿ ಇದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮಾಡಲಾಗಿದೆ: ಏನು ಪರಿಶೀಲಿಸಬೇಕು, ಪೋಲರ್ ಮೂಲಕ ಅಪ್‌ಲೋಡ್ ಮಾಡಬೇಕು ಮತ್ತು ನಮ್ಮ ಅಪ್‌ಲೋಡ್ ಮುರಿದುಹೋಗಿದೆಯೇ?.. ಇದು ಹೆಚ್ಚು ಸರಳವಾಗಿದೆ.
ಉ: - ಇದು ಪ್ರಾಕ್ಸಿಗಳಿಗೂ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ?
MM: - ಹೌದು, ಆದರೆ ನಾವು ಪರಿಶೀಲಿಸಲಿಲ್ಲ. Zabbix ಮತ್ತು ಸರ್ವರ್ ಎರಡರಲ್ಲೂ ಮತದಾನದ ಕೋಡ್ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಕೆಲಸ ಮಾಡಬೇಕು. ನಾನು ಮತ್ತೊಮ್ಮೆ ಒತ್ತಿ ಹೇಳುತ್ತೇನೆ: ಸಿಸ್ಟಮ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯು ನಮಗೆ ಪ್ರಾಕ್ಸಿ ಅಗತ್ಯವಿಲ್ಲ.
MCH: - ಪ್ರಶ್ನೆಗೆ ಸರಿಯಾದ ಉತ್ತರವೆಂದರೆ: "ಅಂತಹ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ನಿಮಗೆ ಪ್ರಾಕ್ಸಿ ಏಕೆ ಬೇಕು?" NAT ಅಥವಾ ಕೆಲವು ರೀತಿಯ ನಿಧಾನಗತಿಯ ಚಾನೆಲ್ ಮೂಲಕ ಮೇಲ್ವಿಚಾರಣೆಯ ಕಾರಣದಿಂದಾಗಿ...
ಉ: - ಮತ್ತು ನಾನು ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡರೆ ನೀವು Zabbix ಅನ್ನು ಅಲರ್ಟರ್ ಆಗಿ ಬಳಸುತ್ತೀರಿ. ಅಥವಾ ನಿಮ್ಮ ಗ್ರಾಫಿಕ್ಸ್ (ಆರ್ಕೈವ್ ಲೇಯರ್ ಇರುವಲ್ಲಿ) ಗ್ರಾಫಾನಾದಂತಹ ಮತ್ತೊಂದು ಸಿಸ್ಟಮ್‌ಗೆ ಸರಿಸಲಾಗಿದೆಯೇ? ಅಥವಾ ನೀವು ಈ ಕಾರ್ಯವನ್ನು ಬಳಸುತ್ತಿಲ್ಲವೇ?
MM: - ನಾನು ಮತ್ತೊಮ್ಮೆ ಒತ್ತಿ ಹೇಳುತ್ತೇನೆ: ನಾವು ಸಂಪೂರ್ಣ ಏಕೀಕರಣವನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ. ನಾವು ಇತಿಹಾಸವನ್ನು Clickhouse ಗೆ ಸುರಿಯುತ್ತಿದ್ದೇವೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ನಾವು php ಮುಂಭಾಗವನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ. Php ಮುಂಭಾಗವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಎಲ್ಲಾ ಗ್ರಾಫಿಕ್ಸ್ ಮಾಡುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಅದೇ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಿಂದ, ಅದೇ Zabbix ಡೇಟಾದಿಂದ ಇತರ ಗ್ರಾಫಿಕ್ ಡಿಸ್‌ಪ್ಲೇ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ನಿರ್ಮಿಸುವ ಭಾಗವನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ.
MCH: - "ಗ್ರಾಫನ್" ನಲ್ಲಿಯೂ.
ಸಂಪನ್ಮೂಲಗಳ ಹಂಚಿಕೆಯ ಬಗ್ಗೆ ಹೇಗೆ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಯಿತು?
ಉ: - ನಿಮ್ಮ ಒಳಗಿನ ಅಡಿಗೆ ಸ್ವಲ್ಪ ಹಂಚಿಕೊಳ್ಳಿ. ಉತ್ಪನ್ನದ ಗಂಭೀರ ಸಂಸ್ಕರಣೆಗಾಗಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ಅಗತ್ಯವೆಂದು ಹೇಗೆ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ? ಇವುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವು ಅಪಾಯಗಳು. ಮತ್ತು ದಯವಿಟ್ಟು ನನಗೆ ತಿಳಿಸಿ, ನೀವು ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಬೆಂಬಲಿಸಲಿದ್ದೀರಿ ಎಂಬ ಅಂಶದ ಸಂದರ್ಭದಲ್ಲಿ: ನಿರ್ವಹಣಾ ದೃಷ್ಟಿಕೋನದಿಂದ ಈ ನಿರ್ಧಾರವು ಹೇಗೆ ಸಮರ್ಥಿಸುತ್ತದೆ?
MM: - ಸ್ಪಷ್ಟವಾಗಿ, ನಾವು ಇತಿಹಾಸದ ನಾಟಕವನ್ನು ಚೆನ್ನಾಗಿ ಹೇಳಲಿಲ್ಲ. ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾದ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ನಾವು ನಮ್ಮನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಮೂಲಭೂತವಾಗಿ ಎರಡು ಸಮಾನಾಂತರ ತಂಡಗಳೊಂದಿಗೆ ಹೋದೆವು:
- ಒಂದು ಹೊಸ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಿದೆ: ಸೇವೆಯಾಗಿ ಮಾನಿಟರಿಂಗ್, ನಾವು ಸಂಯೋಜಿಸುವ ಮುಕ್ತ ಮೂಲ ಪರಿಹಾರಗಳ ಪ್ರಮಾಣಿತ ಸೆಟ್ ಮತ್ತು ನಂತರ ಹೊಸ ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.
- ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಉತ್ಸಾಹಭರಿತ ಪ್ರೋಗ್ರಾಮರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅವರು ಇದನ್ನು ಮಾಡುತ್ತಿದ್ದಾರೆ (ತನ್ನ ಬಗ್ಗೆ). ಅವನು ಗೆದ್ದದ್ದು ಹಾಗೆ ಆಯಿತು.
ಉ: - ಮತ್ತು ತಂಡದ ಗಾತ್ರ ಏನು?
MCH: - ಅವಳು ನಿಮ್ಮ ಮುಂದೆ ಇದ್ದಾಳೆ.
ಉ: - ಆದ್ದರಿಂದ, ಯಾವಾಗಲೂ, ನಿಮಗೆ ಭಾವೋದ್ರಿಕ್ತ ಅಗತ್ಯವಿದೆಯೇ?
MM: - ಭಾವೋದ್ರಿಕ್ತ ಎಂದರೇನು ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ.
ಉ: - ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ಪಷ್ಟವಾಗಿ, ನೀವು. ತುಂಬಾ ಧನ್ಯವಾದಗಳು, ನೀವು ಅದ್ಭುತವಾಗಿದ್ದೀರಿ.
MM: - ಧನ್ಯವಾದ.
Zabbix ಗಾಗಿ ಪ್ಯಾಚ್‌ಗಳ ಬಗ್ಗೆ
ಉ: – ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಬಳಸುವ ಸಿಸ್ಟಮ್‌ಗಾಗಿ (ಉದಾಹರಣೆಗೆ, ಕೆಲವು ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ), ಪೋಲರ್‌ಗಳು, ಪ್ರಾಕ್ಸಿಗಳು ಮತ್ತು ಭಾಗಶಃ Zabbix ನ ಪ್ರಿಪ್ರೊಸೆಸರ್ ಅನ್ನು ಹೊಂದಿಕೊಳ್ಳಲು ಮತ್ತು ಪ್ಯಾಚ್ ಮಾಡಲು ಸಾಧ್ಯವೇ; ಮತ್ತು ಅವರ ಪರಸ್ಪರ ಕ್ರಿಯೆ? ಬಹು ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಹೊಂದಿರುವ ಸಿಸ್ಟಮ್‌ಗಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬೆಳವಣಿಗೆಗಳನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಸಾಧ್ಯವೇ?
MM: - ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಜಬ್ಬಿಕ್ಸ್ ಸರ್ವರ್ ಅನ್ನು ಜೋಡಿಸಲಾಗಿದೆ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ (ಕೋಡ್ ಅನ್ನು ಸಂಕಲಿಸಲಾಗಿದೆ ಮತ್ತು ಪಡೆಯಲಾಗಿದೆ). ಉತ್ಪಾದನೆಯಲ್ಲಿ ನಾವು ಇದನ್ನು ಪರೀಕ್ಷಿಸಿಲ್ಲ. ಇದರ ಬಗ್ಗೆ ನನಗೆ ಖಚಿತವಿಲ್ಲ, ಆದರೆ ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ಪ್ರಿಪ್ರೊಸೆಸರ್ ಮ್ಯಾನೇಜರ್ ಅನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಪ್ರಾಕ್ಸಿಯ ಕಾರ್ಯವೆಂದರೆ Zabbix ನಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳ ಸೆಟ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು, ಅವುಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವುದು (ಇದು ಕಾನ್ಫಿಗರೇಶನ್, ಸ್ಥಳೀಯ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಹ ದಾಖಲಿಸುತ್ತದೆ) ಮತ್ತು ಅದನ್ನು Zabbix ಸರ್ವರ್‌ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಅದನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಸರ್ವರ್ ಸ್ವತಃ ಪೂರ್ವ ಸಂಸ್ಕರಣೆಯನ್ನು ಮಾಡುತ್ತದೆ.
ಪ್ರಾಕ್ಸಿಗಳಲ್ಲಿನ ಆಸಕ್ತಿಯು ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ. ನಾವು ಅದನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಇದು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವಾಗಿದೆ.
ಉ: - ಕಲ್ಪನೆ ಹೀಗಿತ್ತು: ನೀವು ಪೋಲರ್‌ಗಳನ್ನು ಪ್ಯಾಚ್ ಮಾಡಲು ಸಾಧ್ಯವಾದರೆ, ನೀವು ಅವುಗಳನ್ನು ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ಪ್ಯಾಚ್ ಮಾಡಬಹುದು ಮತ್ತು ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಪ್ಯಾಚ್ ಮಾಡಬಹುದು ಮತ್ತು ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಪ್ರಿಪ್ರೊಸೆಸರ್ ಅನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಮಾತ್ರ ಹೊಂದಿಸಬಹುದು.
MM: - ಇದು ಇನ್ನೂ ಸರಳವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನೀವು ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಪ್ಯಾಚ್ ಅನ್ನು ಅನ್ವಯಿಸಿ, ನಂತರ ಅದನ್ನು ನಿಮಗೆ ಬೇಕಾದ ರೀತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿ - ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ (ಉದಾಹರಣೆಗೆ, ODBC ಯೊಂದಿಗೆ) ಮತ್ತು ಪ್ಯಾಚ್ ಮಾಡಿದ ಕೋಡ್ ಅನ್ನು ಸಿಸ್ಟಮ್‌ಗಳಾದ್ಯಂತ ವಿತರಿಸಿ. ಅಗತ್ಯವಿರುವಲ್ಲಿ - ಪ್ರಾಕ್ಸಿಯನ್ನು ಸಂಗ್ರಹಿಸಿ, ಅಗತ್ಯವಿರುವಲ್ಲಿ - ಸರ್ವರ್.
ಉ: - ಹೆಚ್ಚಾಗಿ, ನೀವು ಹೆಚ್ಚುವರಿಯಾಗಿ ಸರ್ವರ್‌ಗೆ ಪ್ರಾಕ್ಸಿ ಪ್ರಸರಣವನ್ನು ಪ್ಯಾಚ್ ಮಾಡಬೇಕಾಗಿಲ್ಲವೇ?
MCH: - ಇಲ್ಲ, ಇದು ಪ್ರಮಾಣಿತವಾಗಿದೆ.
MM: - ವಾಸ್ತವವಾಗಿ, ಒಂದು ಕಲ್ಪನೆಯು ಧ್ವನಿಸಲಿಲ್ಲ. ಆಲೋಚನೆಗಳ ಸ್ಫೋಟ ಮತ್ತು ಬದಲಾವಣೆಗಳ ಪ್ರಮಾಣ ಮತ್ತು ಬೆಂಬಲದ ಸುಲಭತೆಯ ನಡುವೆ ನಾವು ಯಾವಾಗಲೂ ಸಮತೋಲನವನ್ನು ಕಾಯ್ದುಕೊಂಡಿದ್ದೇವೆ.
ಕೆಲವು ಜಾಹೀರಾತುಗಳು 🙂
ನಮ್ಮೊಂದಿಗೆ ಇರುವುದಕ್ಕೆ ಧನ್ಯವಾದಗಳು. ನೀವು ನಮ್ಮ ಲೇಖನಗಳನ್ನು ಇಷ್ಟಪಡುತ್ತೀರಾ? ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವನ್ನು ನೋಡಲು ಬಯಸುವಿರಾ? ಆರ್ಡರ್ ಮಾಡುವ ಮೂಲಕ ಅಥವಾ ಸ್ನೇಹಿತರಿಗೆ ಶಿಫಾರಸು ಮಾಡುವ ಮೂಲಕ ನಮ್ಮನ್ನು ಬೆಂಬಲಿಸಿ, , ಪ್ರವೇಶ ಮಟ್ಟದ ಸರ್ವರ್‌ಗಳ ಅನನ್ಯ ಅನಲಾಗ್, ಇದನ್ನು ನಿಮಗಾಗಿ ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ: (RAID1 ಮತ್ತು RAID10, 24 ಕೋರ್‌ಗಳವರೆಗೆ ಮತ್ತು 40GB DDR4 ವರೆಗೆ ಲಭ್ಯವಿದೆ).
ಆಮ್‌ಸ್ಟರ್‌ಡ್ಯಾಮ್‌ನಲ್ಲಿರುವ Equinix Tier IV ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ Dell R730xd 2x ಅಗ್ಗವಾಗಿದೆಯೇ? ಇಲ್ಲಿ ಮಾತ್ರ ನೆದರ್ಲ್ಯಾಂಡ್ಸ್ನಲ್ಲಿ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ರಿಂದ! ಬಗ್ಗೆ ಓದು
ಮೂಲ: www.habr.com