ಅನ್ಸಿಬಲ್ನೊಂದಿಗೆ ಡಿಸ್ಕ್ ಬದಲಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲಾಗುತ್ತಿದೆ

ಎಲ್ಲರಿಗು ನಮಸ್ಖರ. ನಾನು OK ನಲ್ಲಿ ಪ್ರಮುಖ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ ಮತ್ತು ಪೋರ್ಟಲ್‌ನ ಸ್ಥಿರ ಕಾರ್ಯಾಚರಣೆಗೆ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತೇನೆ. ಡಿಸ್ಕ್ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬದಲಾಯಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಾವು ಹೇಗೆ ನಿರ್ಮಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ ಮತ್ತು ನಂತರ ನಾವು ನಿರ್ವಾಹಕರನ್ನು ಈ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಹೇಗೆ ಹೊರಗಿಡುತ್ತೇವೆ ಮತ್ತು ಅವನನ್ನು ಬೋಟ್ನೊಂದಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ.

ಈ ಲೇಖನವು ಒಂದು ರೀತಿಯ ಲಿಪ್ಯಂತರವಾಗಿದೆ ಪ್ರದರ್ಶನಗಳು HighLoad+ 2018 ನಲ್ಲಿ

ಡಿಸ್ಕ್ ಬದಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ಮಿಸಲಾಗುತ್ತಿದೆ

ಮೊದಲು ಕೆಲವು ಸಂಖ್ಯೆಗಳು

ಸರಿ ಲಕ್ಷಾಂತರ ಜನರು ಬಳಸುವ ದೈತ್ಯ ಸೇವೆಯಾಗಿದೆ. ಇದು ಸುಮಾರು 7 ಸಾವಿರ ಸರ್ವರ್‌ಗಳಿಂದ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ, ಇದು 4 ವಿಭಿನ್ನ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿದೆ. ಸರ್ವರ್‌ಗಳು 70 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಡಿಸ್ಕ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿವೆ. ನೀವು ಅವುಗಳನ್ನು ಒಂದರ ಮೇಲೊಂದರಂತೆ ಜೋಡಿಸಿದರೆ, ನೀವು 1 ಕಿಮೀಗಿಂತ ಹೆಚ್ಚು ಎತ್ತರದ ಗೋಪುರವನ್ನು ಪಡೆಯುತ್ತೀರಿ.

ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳು ಸರ್ವರ್ ಘಟಕವಾಗಿದ್ದು ಅದು ಹೆಚ್ಚಾಗಿ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಅಂತಹ ಸಂಪುಟಗಳೊಂದಿಗೆ, ನಾವು ವಾರಕ್ಕೆ ಸುಮಾರು 30 ಡಿಸ್ಕ್ಗಳನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ, ಮತ್ತು ಈ ವಿಧಾನವು ತುಂಬಾ ಆಹ್ಲಾದಕರವಲ್ಲದ ದಿನಚರಿಯಾಗಿದೆ.

ಘಟನೆಗಳು

ನಮ್ಮ ಕಂಪನಿಯು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಘಟನೆ ನಿರ್ವಹಣೆಯನ್ನು ಪರಿಚಯಿಸಿದೆ. ನಾವು ಪ್ರತಿ ಘಟನೆಯನ್ನು ಜಿರಾದಲ್ಲಿ ದಾಖಲಿಸುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಪರಿಹರಿಸುತ್ತೇವೆ ಮತ್ತು ವಿಂಗಡಿಸುತ್ತೇವೆ. ಒಂದು ಘಟನೆಯು ಬಳಕೆದಾರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿದರೆ, ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಒಟ್ಟಿಗೆ ಸೇರುತ್ತೇವೆ ಮತ್ತು ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ ವೇಗವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು ಹೇಗೆ, ಪರಿಣಾಮವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಮತ್ತು ಮರುಕಳಿಸುವಿಕೆಯನ್ನು ಹೇಗೆ ತಡೆಯುವುದು ಎಂಬುದರ ಕುರಿತು ಯೋಚಿಸುತ್ತೇವೆ.

ಶೇಖರಣಾ ಸಾಧನಗಳು ಇದಕ್ಕೆ ಹೊರತಾಗಿಲ್ಲ. ಅವರ ಸ್ಥಿತಿಯನ್ನು Zabbix ಮೂಲಕ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ. ನಾವು Syslog ನಲ್ಲಿ ಬರೆಯುವ/ಓದುವ ದೋಷಗಳಿಗಾಗಿ ಸಂದೇಶಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ, HW/SW ದಾಳಿಗಳ ಸ್ಥಿತಿಯನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ, SMART ಅನ್ನು ಮಾನಿಟರ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು SSD ಗಳಿಗೆ ಉಡುಗೆಗಳನ್ನು ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ.

ಮೊದಲು ಡಿಸ್ಕ್ಗಳನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸಲಾಯಿತು

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

ಕೆಲಸದ ಶಿಫ್ಟ್ ಸಮಯದಲ್ಲಿ ಸಂಪೂರ್ಣ ಪೋರ್ಟಲ್ನ ಕಾರ್ಯಾಚರಣೆಗೆ ಕರ್ತವ್ಯದಲ್ಲಿರುವ ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ. ಅವರು ಘಟನೆಗಳನ್ನು ತನಿಖೆ ಮಾಡುತ್ತಾರೆ, ರಿಪೇರಿ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸಣ್ಣ ಕಾರ್ಯಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತಾರೆ. ಅವರು ಹಾರ್ಡ್ ಡ್ರೈವ್ಗಳೊಂದಿಗೆ ಮಾತ್ರ ವ್ಯವಹರಿಸುವುದಿಲ್ಲ.

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

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

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

ಹೊಸ ಬದಲಿ ವಿಧಾನ

ನಾವು ಮಾಡಿದ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಎಲ್ಲಾ ಡಿಸ್ಕ್ ಘಟನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಪ್ರಕಾರದ "HW ಡಿಸ್ಕ್" ಗೆ ಸರಿಸುವುದಾಗಿದೆ ಮತ್ತು ಅದಕ್ಕೆ "ಬ್ಲಾಕ್ ಡಿವೈಸ್ ಹೆಸರು", "ಗಾತ್ರ" ಮತ್ತು "ಡಿಸ್ಕ್ ಪ್ರಕಾರ" ಕ್ಷೇತ್ರಗಳನ್ನು ಸೇರಿಸುವುದು ಇದರಿಂದ ಈ ಮಾಹಿತಿಯನ್ನು ಟಿಕೆಟ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಚಾಟ್‌ನಲ್ಲಿ ನಿರಂತರವಾಗಿ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ.

ಒಂದು ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ನಾವು ಒಂದು ಡಿಸ್ಕ್ ಅನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸುತ್ತೇವೆ ಎಂದು ನಾವು ಒಪ್ಪಿಕೊಂಡಿದ್ದೇವೆ. ಇದು ಭವಿಷ್ಯದಲ್ಲಿ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಪ್ರಕ್ರಿಯೆ, ಅಂಕಿಅಂಶಗಳ ಸಂಗ್ರಹ ಮತ್ತು ಕೆಲಸವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸರಳಗೊಳಿಸಿತು.

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

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

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

ಹಿಂದೆ ಇದು ಹೀಗಿತ್ತು:

ಇಂಜಿನಿಯರ್‌ಗಳು ನಿರ್ವಾಹಕರ ಸಹಾಯದ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಇಂದು ಕೆಲಸ ಮಾಡುವುದನ್ನು ಮುಂದುವರೆಸುತ್ತಾರೆ.

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

ನಾವು ಸ್ಥಿತಿಯನ್ನು ಕೂಡ ಸೇರಿಸಿದ್ದೇವೆ ರೆಡಿ. ಡಿಸ್ಕ್ ಅನ್ನು ಬದಲಿಸಿದ ನಂತರ ಟಿಕೆಟ್ ಅನ್ನು ಅದಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. ಅಂದರೆ, ಎಲ್ಲವನ್ನೂ ಈಗಾಗಲೇ ಮಾಡಲಾಗಿದೆ, ಆದರೆ HW/SW RAID ಅನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿದೆ. ಇದು ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು.

ನಿರ್ವಾಹಕರು ಕೆಲಸದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡರೆ, ಯೋಜನೆಯು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತದೆ.

ಸ್ಥಿತಿಯಿಂದ ಓಪನ್ ಟಿಕೆಟ್ ಅನ್ನು ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಮತ್ತು ಇಂಜಿನಿಯರ್ ಇಬ್ಬರೂ ಅನುವಾದಿಸಬಹುದು. ಸ್ಥಿತಿಯಲ್ಲಿ ಪ್ರಗತಿಯಲ್ಲಿದೆ ನಿರ್ವಾಹಕರು ಡಿಸ್ಕ್ ಅನ್ನು ತಿರುಗುವಿಕೆಯಿಂದ ತೆಗೆದುಹಾಕುತ್ತಾರೆ ಇದರಿಂದ ಎಂಜಿನಿಯರ್ ಅದನ್ನು ಸರಳವಾಗಿ ಹೊರತೆಗೆಯಬಹುದು: ಬ್ಯಾಕ್‌ಲೈಟ್ ಅನ್ನು ಆನ್ ಮಾಡುತ್ತದೆ, ಡಿಸ್ಕ್ ಅನ್ನು ಅನ್‌ಮೌಂಟ್ ಮಾಡುತ್ತದೆ, ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್‌ಗಳ ಗುಂಪನ್ನು ಅವಲಂಬಿಸಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.

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

ಡಿಸ್ಕ್ ಅನ್ನು ಬದಲಿಸಿದ ನಂತರ, ಟಿಕೆಟ್ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ ಬದಲಾಯಿಸಲಾಗಿದೆ. ಸರಿಯಾದ ಡಿಸ್ಕ್ ಅನ್ನು ಸೇರಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ, ವಿಭಜನೆಯನ್ನು ಮಾಡಲಾಗಿದೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಮತ್ತು ಕೆಲವು ಡೇಟಾ ಮರುಪಡೆಯುವಿಕೆ ಕಾರ್ಯಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ. ಟಿಕೆಟ್ ಅನ್ನು ಸಹ ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸಬಹುದು ರೆಡಿ, ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಿರ್ವಾಹಕರು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ, ಏಕೆಂದರೆ ಅವರು ಡಿಸ್ಕ್ ಅನ್ನು ತಿರುಗಿಸುತ್ತಾರೆ. ಸಂಪೂರ್ಣ ರೇಖಾಚಿತ್ರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ.

ಹೊಸ ಕ್ಷೇತ್ರಗಳನ್ನು ಸೇರಿಸುವುದರಿಂದ ನಮ್ಮ ಜೀವನವನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸಿದೆ. ಹುಡುಗರು ರಚನಾತ್ಮಕ ಮಾಹಿತಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು, ಏನು ಮಾಡಬೇಕೆಂದು ಮತ್ತು ಯಾವ ಹಂತದಲ್ಲಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು. ಆದ್ಯತೆಗಳು ಹೆಚ್ಚು ಪ್ರಸ್ತುತವಾಗಿವೆ, ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಈಗ ನಿರ್ವಾಹಕರು ಹೊಂದಿಸಿದ್ದಾರೆ.

ಚಾಟ್‌ಗಳ ಅಗತ್ಯವಿಲ್ಲ. ಸಹಜವಾಗಿ, ನಿರ್ವಾಹಕರು ಇಂಜಿನಿಯರ್‌ಗೆ "ಇದನ್ನು ವೇಗವಾಗಿ ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ" ಅಥವಾ "ಇದು ಈಗಾಗಲೇ ಸಂಜೆಯಾಗಿದೆ, ಅದನ್ನು ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಸಮಯವಿದೆಯೇ?" ಎಂದು ಬರೆಯಬಹುದು. ಆದರೆ ನಾವು ಇನ್ನು ಮುಂದೆ ಈ ಸಮಸ್ಯೆಗಳ ಕುರಿತು ಚಾಟ್‌ಗಳಲ್ಲಿ ಪ್ರತಿದಿನ ಸಂವಹನ ಮಾಡುವುದಿಲ್ಲ.

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

ವರ್ಕ್‌ಫ್ಲೋ ನಿರ್ಮಿಸುವಾಗ ಕಲಿತ ಪಾಠಗಳು

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

ಡಿಸ್ಕ್ ಬದಲಿ ಆಟೊಮೇಷನ್

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

ಈಗಿನಿಂದ ನಮ್ಮ ಬದಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಪ್ರತಿಯೊಂದೂ ನಿರ್ದಿಷ್ಟ ಪ್ರದರ್ಶಕ ಮತ್ತು ಕ್ರಿಯೆಗಳ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದೆ, ನಾವು ಹಂತಗಳಲ್ಲಿ ಯಾಂತ್ರೀಕೃತಗೊಂಡವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು ಮತ್ತು ಏಕಕಾಲದಲ್ಲಿ ಅಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಸರಳವಾದ ಹಂತ - ರೆಡಿ (RAID/ಡೇಟಾ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ) ಅನ್ನು ಬೋಟ್‌ಗೆ ಸುಲಭವಾಗಿ ನಿಯೋಜಿಸಬಹುದು. ಬೋಟ್ ಸ್ವಲ್ಪ ಕಲಿತಾಗ, ನೀವು ಅದಕ್ಕೆ ಹೆಚ್ಚು ಮುಖ್ಯವಾದ ಕೆಲಸವನ್ನು ನೀಡಬಹುದು - ಡಿಸ್ಕ್ ಅನ್ನು ತಿರುಗುವಿಕೆಗೆ ಹಾಕುವುದು ಇತ್ಯಾದಿ.

ಝೂ ಸೆಟಪ್‌ಗಳು

ನಾವು ಬೋಟ್ ಬಗ್ಗೆ ಮಾತನಾಡುವ ಮೊದಲು, ನಮ್ಮ ಮೃಗಾಲಯದ ಅನುಸ್ಥಾಪನೆಗೆ ಒಂದು ಸಣ್ಣ ವಿಹಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ. ಮೊದಲನೆಯದಾಗಿ, ಇದು ನಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ದೈತ್ಯಾಕಾರದ ಗಾತ್ರದಿಂದಾಗಿ. ಎರಡನೆಯದಾಗಿ, ನಾವು ಪ್ರತಿ ಸೇವೆಗೆ ಸೂಕ್ತವಾದ ಹಾರ್ಡ್‌ವೇರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ನಾವು ಸುಮಾರು 20 ಹಾರ್ಡ್‌ವೇರ್ RAID ಮಾದರಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಹೆಚ್ಚಾಗಿ LSI ಮತ್ತು Adaptec, ಆದರೆ ವಿವಿಧ ಆವೃತ್ತಿಗಳ HP ಮತ್ತು DELL ಇವೆ. ಪ್ರತಿಯೊಂದು RAID ನಿಯಂತ್ರಕವು ತನ್ನದೇ ಆದ ನಿರ್ವಹಣಾ ಉಪಯುಕ್ತತೆಯನ್ನು ಹೊಂದಿದೆ. ಪ್ರತಿ RAID ನಿಯಂತ್ರಕಕ್ಕಾಗಿ ಆಜ್ಞೆಗಳ ಸೆಟ್ ಮತ್ತು ಅವುಗಳ ವಿತರಣೆಯು ಆವೃತ್ತಿಯಿಂದ ಆವೃತ್ತಿಗೆ ಭಿನ್ನವಾಗಿರಬಹುದು. HW-RAID ಅನ್ನು ಬಳಸದಿರುವಲ್ಲಿ, mdraid ಅನ್ನು ಬಳಸಬಹುದು.

ಡಿಸ್ಕ್ ಬ್ಯಾಕಪ್ ಇಲ್ಲದೆಯೇ ನಾವು ಎಲ್ಲಾ ಹೊಸ ಸ್ಥಾಪನೆಗಳನ್ನು ಮಾಡುತ್ತೇವೆ. ನಾವು ಇನ್ನು ಮುಂದೆ ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ RAID ಅನ್ನು ಬಳಸದಿರಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ನಾವು ನಮ್ಮ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಡೇಟಾ ಸೆಂಟರ್ ಮಟ್ಟದಲ್ಲಿ ಬ್ಯಾಕಪ್ ಮಾಡುತ್ತೇವೆಯೇ ಹೊರತು ಸರ್ವರ್‌ಗಳಲ್ಲ. ಆದರೆ ಸಹಜವಾಗಿ ಬೆಂಬಲಿಸಬೇಕಾದ ಅನೇಕ ಪರಂಪರೆ ಸರ್ವರ್‌ಗಳಿವೆ.

ಎಲ್ಲೋ RAID ನಿಯಂತ್ರಕಗಳಲ್ಲಿನ ಡಿಸ್ಕ್ಗಳನ್ನು ಕಚ್ಚಾ ಸಾಧನಗಳಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ, ಎಲ್ಲೋ JBOD ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಸರ್ವರ್‌ನಲ್ಲಿ ಒಂದು ಸಿಸ್ಟಮ್ ಡಿಸ್ಕ್‌ನೊಂದಿಗೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಿವೆ, ಮತ್ತು ಅದನ್ನು ಬದಲಾಯಿಸಬೇಕಾದರೆ, ನೀವು ಅದೇ ಆವೃತ್ತಿಗಳ ಓಎಸ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸ್ಥಾಪನೆಯೊಂದಿಗೆ ಸರ್ವರ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಬೇಕು, ನಂತರ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಸೇರಿಸಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿ. ಬಹಳಷ್ಟು ಸರ್ವರ್ ಗುಂಪುಗಳಿವೆ, ಅಲ್ಲಿ ಬ್ಯಾಕ್ಅಪ್ ಅನ್ನು ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯ ಮಟ್ಟದಲ್ಲಿ ನಡೆಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ನೇರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿಯೇ ಮಾಡಲಾಗುತ್ತದೆ.

ಒಟ್ಟಾರೆಯಾಗಿ, ನಾವು ಸುಮಾರು 400 ವಿಭಿನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಲಾಯಿಸುತ್ತಿರುವ 100 ಅನನ್ಯ ಸರ್ವರ್ ಗುಂಪುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅಂತಹ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಆಯ್ಕೆಗಳನ್ನು ಒಳಗೊಳ್ಳಲು, ನಮಗೆ ಬಹುಕ್ರಿಯಾತ್ಮಕ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಸಾಧನದ ಅಗತ್ಯವಿದೆ. ಮೇಲಾಗಿ ಸರಳವಾದ DSL ನೊಂದಿಗೆ, ಅದನ್ನು ಬರೆದ ವ್ಯಕ್ತಿ ಮಾತ್ರವಲ್ಲದೆ ಅದನ್ನು ಬೆಂಬಲಿಸಬಹುದು.

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

ಸಾಮಾನ್ಯ ಯೋಜನೆ

ಒಂದು ಘಟನೆಯನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಬಳಸಿಕೊಂಡು ಸಾಮಾನ್ಯ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಯೋಜನೆಯನ್ನು ನೋಡೋಣ. sdb ಡಿಸ್ಕ್ ವಿಫಲವಾಗಿದೆ ಎಂದು Zabbix ಪತ್ತೆ ಮಾಡುತ್ತದೆ, ಟ್ರಿಗರ್ ಬೆಳಗುತ್ತದೆ ಮತ್ತು ಜಿರಾದಲ್ಲಿ ಟಿಕೆಟ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ. ನಿರ್ವಾಹಕರು ಅದನ್ನು ನೋಡಿದರು, ಇದು ನಕಲಿ ಅಲ್ಲ ಮತ್ತು ತಪ್ಪು ಧನಾತ್ಮಕವಲ್ಲ ಎಂದು ಅರಿತುಕೊಂಡರು, ಅಂದರೆ, ಡಿಸ್ಕ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ಟಿಕೆಟ್ ಅನ್ನು ಪ್ರಗತಿಯಲ್ಲಿದೆ ಎಂದು ವರ್ಗಾಯಿಸಿದರು.

ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲಾದ DiskoBot ಅಪ್ಲಿಕೇಶನ್, ಹೊಸ ಟಿಕೆಟ್‌ಗಳಿಗಾಗಿ ನಿಯತಕಾಲಿಕವಾಗಿ ಜಿರಾವನ್ನು ಪೋಲ್ ಮಾಡುತ್ತದೆ. ಹೊಸ ಪ್ರಗತಿಯಲ್ಲಿರುವ ಟಿಕೆಟ್ ಕಾಣಿಸಿಕೊಂಡಿದೆ ಎಂದು ಅದು ಗಮನಿಸುತ್ತದೆ, ಅನುಗುಣವಾದ ಥ್ರೆಡ್ ಅನ್ನು ಪ್ರಚೋದಿಸಲಾಗುತ್ತದೆ, ಇದು ಪ್ಲೇಬುಕ್ ಅನ್ನು ಅನ್ಸಿಬಲ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸುತ್ತದೆ (ಜಿರಾದಲ್ಲಿನ ಪ್ರತಿ ಸ್ಥಿತಿಗೆ ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ). ಈ ಸಂದರ್ಭದಲ್ಲಿ, Prepare2change ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

ಅನ್ಸಿಬಲ್ ಅನ್ನು ಹೋಸ್ಟ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ತಿರುಗುವಿಕೆಯಿಂದ ಡಿಸ್ಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಮತ್ತು ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳ ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸ್ಥಿತಿಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ.

ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ, ಬೋಟ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಟಿಕೆಟ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ವರ್ಗಾಯಿಸುತ್ತದೆ. ಇಂಜಿನಿಯರ್ ಅಧಿಸೂಚನೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾನೆ ಮತ್ತು ಡಿಸ್ಕ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಹೋಗುತ್ತಾನೆ, ಅದರ ನಂತರ ಅವನು ಟಿಕೆಟ್ ಅನ್ನು ಚೇಂಜ್ಡ್ಗೆ ವರ್ಗಾಯಿಸುತ್ತಾನೆ.

ಮೇಲೆ ವಿವರಿಸಿದ ಯೋಜನೆಯ ಪ್ರಕಾರ, ಟಿಕೆಟ್ ಬೋಟ್‌ಗೆ ಹಿಂತಿರುಗುತ್ತದೆ, ಅದು ಮತ್ತೊಂದು ಪ್ಲೇಬುಕ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಹೋಸ್ಟ್‌ಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಡಿಸ್ಕ್ ಅನ್ನು ತಿರುಗುವಂತೆ ಮಾಡುತ್ತದೆ. ಬೋಟ್ ಟಿಕೆಟ್ ಅನ್ನು ಮುಚ್ಚುತ್ತದೆ. ಹುರ್ರೇ!

ಈಗ ಸಿಸ್ಟಮ್ನ ಕೆಲವು ಘಟಕಗಳ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ.

ಡಿಸ್ಕೋಬೋಟ್

ಈ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಇದು JQL ಪ್ರಕಾರ ಜಿರಾದಿಂದ ಟಿಕೆಟ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಟಿಕೆಟ್‌ನ ಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿ, ಎರಡನೆಯದು ಅನುಗುಣವಾದ ಹ್ಯಾಂಡ್ಲರ್‌ಗೆ ಹೋಗುತ್ತದೆ, ಅದು ಸ್ಥಿತಿಗೆ ಅನುಗುಣವಾದ ಅನ್ಸಿಬಲ್ ಪ್ಲೇಬುಕ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

JQL ಮತ್ತು ಪೋಲಿಂಗ್ ಮಧ್ಯಂತರಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ.

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

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

ಮತ್ತು ಸಿದ್ಧ ಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿರುವ ಟಿಕೆಟ್‌ಗಳಲ್ಲಿ, dbot_ignore ಲೇಬಲ್‌ನೊಂದಿಗೆ ಟಿಕೆಟ್‌ಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲಾಗುತ್ತದೆ. ಅಂದಹಾಗೆ, ಅಂತಹ ಫಿಲ್ಟರಿಂಗ್‌ಗಾಗಿ ಮತ್ತು ನಕಲಿ ಟಿಕೆಟ್‌ಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದಕ್ಕಾಗಿ ನಾವು ಜಿರಾ ಲೇಬಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ.

ಪ್ಲೇಬುಕ್ ವಿಫಲವಾದರೆ, ಜಿರಾ dbot_failed ಲೇಬಲ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ ಇದರಿಂದ ಅದನ್ನು ನಂತರ ವಿಂಗಡಿಸಬಹುದು.

ಅನ್ಸಿಬಲ್ ಜೊತೆ ಪರಸ್ಪರ ಕಾರ್ಯಸಾಧ್ಯತೆ

ಅಪ್ಲಿಕೇಶನ್ ಅನ್ಸಿಬಲ್ ಮೂಲಕ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಅನ್ಸಿಬಲ್ ಪೈಥಾನ್ API. playbook_executor ಗೆ ನಾವು ಫೈಲ್ ಹೆಸರು ಮತ್ತು ಅಸ್ಥಿರಗಳ ಗುಂಪನ್ನು ರವಾನಿಸುತ್ತೇವೆ. ಅನ್ಸಿಬಲ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಪೈಥಾನ್ ಕೋಡ್‌ನಲ್ಲಿ ವಿವರಿಸುವ ಬದಲು ಸಾಮಾನ್ಯ yml ಫೈಲ್‌ಗಳ ರೂಪದಲ್ಲಿ ಇರಿಸಿಕೊಳ್ಳಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ಅನ್ಸಿಬಲ್‌ನಲ್ಲಿ, *extra_vars* ಮೂಲಕ, ಬ್ಲಾಕ್ ಸಾಧನದ ಹೆಸರು, ಟಿಕೆಟ್‌ನ ಸ್ಥಿತಿ, ಹಾಗೆಯೇ ಸಂಚಿಕೆ ಕೀಯನ್ನು ಒಳಗೊಂಡಿರುವ callback_url - ಇದನ್ನು HTTP ನಲ್ಲಿ ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಪ್ರತಿ ಉಡಾವಣೆಗಾಗಿ, ಒಂದು ಹೋಸ್ಟ್ ಮತ್ತು ಈ ಹೋಸ್ಟ್ ಸೇರಿರುವ ಗುಂಪನ್ನು ಒಳಗೊಂಡಿರುವ ತಾತ್ಕಾಲಿಕ ದಾಸ್ತಾನು ರಚಿಸಲಾಗುತ್ತದೆ, ಇದರಿಂದ group_var ಗಳನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ.

HTTP ಕಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಕಾರ್ಯದ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ.

ಕ್ಯಾಲಬ್ಯಾಕ್(ಗಳು) ಬಳಸಿಕೊಂಡು ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಫಲಿತಾಂಶವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ. ಅವು ಎರಡು ವಿಧಗಳಾಗಿವೆ:

• ಅನ್ಸಿಬಲ್ ಕಾಲ್‌ಬ್ಯಾಕ್ ಪ್ಲಗಿನ್, ಇದು ಪ್ಲೇಬುಕ್ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಫಲಿತಾಂಶಗಳ ಮೇಲೆ ಡೇಟಾವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದು ಪ್ರಾರಂಭಿಸಲಾದ, ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಂಡ ಅಥವಾ ವಿಫಲವಾದ ಕಾರ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಪ್ಲೇಬುಕ್ ಪ್ಲೇ ಆಗುವುದನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದಾಗ ಈ ಕಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ.
• ಪ್ಲೇಬುಕ್ ಅನ್ನು ಪ್ಲೇ ಮಾಡುವಾಗ ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸಲು HTTP ಕಾಲ್‌ಬ್ಯಾಕ್. Ansible ಕಾರ್ಯದಲ್ಲಿ ನಾವು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ POST/GET ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ.

ಪ್ಲೇಬುಕ್‌ನ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಸಮಯದಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ HTTP ಕಾಲ್‌ಬ್ಯಾಕ್(ಗಳು) ಮೂಲಕ ಅಸ್ಥಿರಗಳನ್ನು ರವಾನಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಾವು ಉಳಿಸಲು ಮತ್ತು ನಂತರದ ರನ್‌ಗಳಲ್ಲಿ ಬಳಸಲು ಬಯಸುತ್ತೇವೆ. ನಾವು ಈ ಡೇಟಾವನ್ನು sqlite ನಲ್ಲಿ ಬರೆಯುತ್ತೇವೆ.

ನಾವು ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಸಹ ನೀಡುತ್ತೇವೆ ಮತ್ತು HTTP ಕಾಲ್‌ಬ್ಯಾಕ್ ಮೂಲಕ ಟಿಕೆಟ್ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ.

HTTP ಕಾಲ್ಬ್ಯಾಕ್

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

ಒಂದೇ ರೀತಿಯ ಅನೇಕ ಕಾರ್ಯಗಳಂತೆ, ನಾವು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಸಾಮಾನ್ಯ ಫೈಲ್‌ನಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಅದನ್ನು ಸೇರಿಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ಪ್ಲೇಬುಕ್‌ಗಳಲ್ಲಿ ಅದನ್ನು ನಿರಂತರವಾಗಿ ಪುನರಾವರ್ತಿಸಬಾರದು. ಇದು ಕಾಲ್‌ಬ್ಯಾಕ್_ url ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಇದು ಸಮಸ್ಯೆಯ ಕೀ ಮತ್ತು ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಒಳಗೊಂಡಿದೆ. Ansible ಈ POST ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದಾಗ, ಇದು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಘಟನೆಯ ಭಾಗವಾಗಿ ಬಂದಿದೆ ಎಂದು ಬೋಟ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ.

ಮತ್ತು ಪ್ಲೇಬುಕ್‌ನಿಂದ ಒಂದು ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ, ಇದರಲ್ಲಿ ನಾವು MD ಸಾಧನದಿಂದ ಡಿಸ್ಕ್ ಅನ್ನು ಔಟ್‌ಪುಟ್ ಮಾಡುತ್ತೇವೆ:

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

ಈ ಕಾರ್ಯವು ಜಿರಾ ಟಿಕೆಟ್ ಅನ್ನು "ಬದಲಾಯಿಸಲು ಸಿದ್ಧ" ಸ್ಥಿತಿಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ ಮತ್ತು ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ಅಲ್ಲದೆ, mdam_data ವೇರಿಯೇಬಲ್ ಡಿಸ್ಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲಾದ md ಸಾಧನಗಳ ಪಟ್ಟಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು parted_info parted ನಿಂದ ವಿಭಜನಾ ಡಂಪ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.

ಇಂಜಿನಿಯರ್ ಹೊಸ ಡಿಸ್ಕ್ ಅನ್ನು ಸೇರಿಸಿದಾಗ, ವಿಭಜನಾ ಡಂಪ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ನಾವು ಈ ಅಸ್ಥಿರಗಳನ್ನು ಬಳಸಬಹುದು, ಹಾಗೆಯೇ ಅದನ್ನು ತೆಗೆದುಹಾಕಲಾದ ಎಮ್ಡಿ ಸಾಧನಗಳಿಗೆ ಡಿಸ್ಕ್ ಅನ್ನು ಸೇರಿಸಬಹುದು.

ಆನ್ಸಿಬಲ್ ಚೆಕ್ ಮೋಡ್

ಯಾಂತ್ರೀಕರಣವನ್ನು ಆನ್ ಮಾಡಲು ಹೆದರಿಕೆಯಿತ್ತು. ಆದ್ದರಿಂದ, ನಾವು ಎಲ್ಲಾ ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ಮೋಡ್‌ನಲ್ಲಿ ಚಲಾಯಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ
ಒಣ ರನ್, ಇದರಲ್ಲಿ ಅನ್ಸಿಬಲ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಯಾವುದೇ ಕ್ರಿಯೆಗಳನ್ನು ಮಾಡುವುದಿಲ್ಲ, ಆದರೆ ಅವುಗಳನ್ನು ಮಾತ್ರ ಅನುಕರಿಸುತ್ತದೆ.

ಅಂತಹ ಉಡಾವಣೆಯು ಪ್ರತ್ಯೇಕ ಕಾಲ್ಬ್ಯಾಕ್ ಮಾಡ್ಯೂಲ್ ಮೂಲಕ ರನ್ ಆಗುತ್ತದೆ ಮತ್ತು ಪ್ಲೇಬುಕ್ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಫಲಿತಾಂಶವನ್ನು ಕಾಮೆಂಟ್ ಆಗಿ ಜಿರಾದಲ್ಲಿ ಉಳಿಸಲಾಗುತ್ತದೆ.

ಮೊದಲನೆಯದಾಗಿ, ಇದು ಬೋಟ್ ಮತ್ತು ಪ್ಲೇಬುಕ್‌ಗಳ ಕೆಲಸವನ್ನು ಮೌಲ್ಯೀಕರಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು. ಎರಡನೆಯದಾಗಿ, ಇದು ಬೋಟ್‌ನಲ್ಲಿ ನಿರ್ವಾಹಕರ ವಿಶ್ವಾಸವನ್ನು ಹೆಚ್ಚಿಸಿತು.

ನಾವು ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆಯನ್ನು ಅಂಗೀಕರಿಸಿದಾಗ ಮತ್ತು ನೀವು ಡ್ರೈ ರನ್ ಮೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಅನ್ಸಿಬಲ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದು ಎಂದು ಅರಿತುಕೊಂಡಾಗ, ಅದೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಅದೇ ವೇರಿಯೇಬಲ್‌ಗಳೊಂದಿಗೆ ಅದೇ ಪ್ಲೇಬುಕ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಾವು ಜಿರಾದಲ್ಲಿ ರನ್ ಡಿಸ್ಕೋಬಾಟ್ ಬಟನ್ ಅನ್ನು ಮಾಡಿದ್ದೇವೆ, ಆದರೆ ಸಾಮಾನ್ಯ ಮೋಡ್‌ನಲ್ಲಿ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪ್ಲೇಬುಕ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು ಬಟನ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಪ್ಲೇಬುಕ್ ರಚನೆ

ಜಿರಾ ಟಿಕೆಟ್‌ನ ಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿ, ಬೋಟ್ ವಿಭಿನ್ನ ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಿದ್ದೇನೆ.

ಮೊದಲನೆಯದಾಗಿ, ಪ್ರವೇಶವನ್ನು ಸಂಘಟಿಸುವುದು ತುಂಬಾ ಸುಲಭ.
ಎರಡನೆಯದಾಗಿ, ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಸರಳವಾಗಿ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.

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

ಪ್ರತಿಯೊಂದು ಗುಂಪಿನ ಸರ್ವರ್‌ಗಳಿಗೆ ನಾವು ಅನ್ಸಿಬಲ್ ಪಾತ್ರಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಪ್ಲೇಬುಕ್(ಗಳು) ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಹೇಗೆ ಆಯೋಜಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಇಲ್ಲಿ ನೀವು ನೋಡಬಹುದು.

ಇದು ಅನುಕೂಲಕರವಾಗಿದೆ ಏಕೆಂದರೆ ಯಾವ ಕಾರ್ಯಗಳು ಎಲ್ಲಿವೆ ಎಂಬುದು ತಕ್ಷಣವೇ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಅನ್ಸಿಬಲ್ ಪಾತ್ರಕ್ಕೆ ಇನ್‌ಪುಟ್ ಆಗಿರುವ main.yml ನಲ್ಲಿ, ನಾವು ಟಿಕೆಟ್ ಸ್ಥಿತಿ ಅಥವಾ ಎಲ್ಲರಿಗೂ ಅಗತ್ಯವಿರುವ ಸಾಮಾನ್ಯ ಕಾರ್ಯಗಳ ಮೂಲಕ ಸರಳವಾಗಿ ಸೇರಿಸಿಕೊಳ್ಳಬಹುದು, ಉದಾಹರಣೆಗೆ, ಗುರುತಿಸುವಿಕೆಯನ್ನು ರವಾನಿಸುವುದು ಅಥವಾ ಟೋಕನ್ ಸ್ವೀಕರಿಸುವುದು.

ತನಿಖೆ.yml

ತನಿಖೆ ಮತ್ತು ಮುಕ್ತ ಸ್ಥಿತಿಯಲ್ಲಿ ಟಿಕೆಟ್‌ಗಳಿಗಾಗಿ ರನ್ ಆಗುತ್ತದೆ. ಈ ಪ್ಲೇಬುಕ್‌ಗೆ ಪ್ರಮುಖ ವಿಷಯವೆಂದರೆ ಬ್ಲಾಕ್ ಸಾಧನದ ಹೆಸರು. ಈ ಮಾಹಿತಿಯು ಯಾವಾಗಲೂ ಲಭ್ಯವಿರುವುದಿಲ್ಲ.

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

ಬ್ಲಾಕ್ ಸಾಧನದ ಹೆಸರನ್ನು ಕಂಡುಹಿಡಿದ ನಂತರ, ಜಿರಾದಲ್ಲಿನ ಕ್ಷೇತ್ರಗಳನ್ನು ಭರ್ತಿ ಮಾಡಲು ನಾವು ಅದರಿಂದ ಡಿಸ್ಕ್ನ ಪ್ರಕಾರ ಮತ್ತು ಗಾತ್ರದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ನಾವು ಮಾರಾಟಗಾರರು, ಮಾದರಿ, ಫರ್ಮ್‌ವೇರ್, ID, SMART ಕುರಿತು ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತೇವೆ ಮತ್ತು ಜಿರಾ ಟಿಕೆಟ್‌ನಲ್ಲಿ ಕಾಮೆಂಟ್‌ಗೆ ಎಲ್ಲವನ್ನೂ ಸೇರಿಸುತ್ತೇವೆ. ನಿರ್ವಾಹಕರು ಮತ್ತು ಎಂಜಿನಿಯರ್ ಇನ್ನು ಮುಂದೆ ಈ ಡೇಟಾವನ್ನು ಹುಡುಕುವ ಅಗತ್ಯವಿಲ್ಲ. 🙂

ತಯಾರು2change.yml

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

ಸರಳವಾದ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು HW/MD RAID ನಿಂದ ಡಿಸ್ಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ.

ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಸಂದರ್ಭಗಳಲ್ಲಿ (ನಮ್ಮ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ), ಬ್ಯಾಕ್ಅಪ್ ಅನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ ನಿರ್ವಹಿಸಿದಾಗ, ನೀವು API ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಹೋಗಬೇಕಾಗುತ್ತದೆ, ಡಿಸ್ಕ್ ಔಟ್ಪುಟ್ ಅನ್ನು ವರದಿ ಮಾಡಿ, ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಮತ್ತು ಮರುಪಡೆಯುವಿಕೆ ಪ್ರಾರಂಭಿಸಿ.

ನಾವು ಈಗ ಸಾಮೂಹಿಕವಾಗಿ ವಲಸೆ ಹೋಗುತ್ತಿದ್ದೇವೆ ಮೋಡ, ಮತ್ತು ಸರ್ವರ್ ಕ್ಲೌಡ್-ಆಧಾರಿತವಾಗಿದ್ದರೆ, ಡಿಸ್ಕೋಬಾಟ್ ಕ್ಲೌಡ್ API ಗೆ ಕರೆ ಮಾಡುತ್ತದೆ, ಅದು ಈ ಮಿನಿಯನ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ - ಸರ್ವರ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಕಂಟೇನರ್‌ಗಳು - ಮತ್ತು "ಈ ಮಿನಿಯನ್‌ನಿಂದ ಎಲ್ಲಾ ಕಂಟೇನರ್‌ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಿ" ಎಂದು ಕೇಳುತ್ತದೆ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, ಡಿಸ್ಕ್ನ ಹಿಂಬದಿ ಬೆಳಕನ್ನು ಆನ್ ಮಾಡುತ್ತದೆ ಇದರಿಂದ ಎಂಜಿನಿಯರ್ ತಕ್ಷಣವೇ ಏನನ್ನು ಹೊರತೆಗೆಯಬೇಕು ಎಂಬುದನ್ನು ನೋಡಬಹುದು.

ಬದಲಾಗಿದೆ.yml

ಡಿಸ್ಕ್ ಅನ್ನು ಬದಲಿಸಿದ ನಂತರ, ನಾವು ಮೊದಲು ಅದರ ಲಭ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

ಎಂಜಿನಿಯರ್‌ಗಳು ಯಾವಾಗಲೂ ಹೊಸ ಡ್ರೈವ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ನಮ್ಮನ್ನು ತೃಪ್ತಿಪಡಿಸುವ SMART ಮೌಲ್ಯಗಳಿಗಾಗಿ ಚೆಕ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ.

ನಾವು ಯಾವ ಗುಣಲಕ್ಷಣಗಳನ್ನು ನೋಡುತ್ತಿದ್ದೇವೆ?ಮರುಹಂಚಿಕೆ ಮಾಡಿದ ವಲಯಗಳ ಎಣಿಕೆ (5) < 100
ಪ್ರಸ್ತುತ ಬಾಕಿ ಇರುವ ವಲಯದ ಎಣಿಕೆ (107) == 0

ಡ್ರೈವ್ ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಫಲವಾದಲ್ಲಿ, ಅದನ್ನು ಮತ್ತೊಮ್ಮೆ ಬದಲಾಯಿಸಲು ಎಂಜಿನಿಯರ್‌ಗೆ ಸೂಚಿಸಲಾಗುತ್ತದೆ. ಎಲ್ಲವೂ ಕ್ರಮದಲ್ಲಿದ್ದರೆ, ಬ್ಯಾಕ್ಲೈಟ್ ಆಫ್ ಆಗುತ್ತದೆ, ಗುರುತುಗಳನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಡಿಸ್ಕ್ ಅನ್ನು ತಿರುಗಿಸಲಾಗುತ್ತದೆ.

ಸಿದ್ಧ.yml

ಸರಳವಾದ ಪ್ರಕರಣ: HW/SW ರೈಡ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಡೇಟಾ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದು.

ಅಪ್ಲಿಕೇಶನ್ API

ಬಾಟ್ ಆಗಾಗ್ಗೆ ಅಪ್ಲಿಕೇಶನ್ API ಗಳನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ ಎಂದು ನಾನು ಹಲವಾರು ಬಾರಿ ಉಲ್ಲೇಖಿಸಿದ್ದೇನೆ. ಸಹಜವಾಗಿ, ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಅಗತ್ಯ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಮಾರ್ಪಡಿಸಬೇಕಾಗಿತ್ತು. ನಾವು ಬಳಸುವ ಪ್ರಮುಖ ವಿಧಾನಗಳು ಇಲ್ಲಿವೆ:

• ಸ್ಥಿತಿ. ಕ್ಲಸ್ಟರ್ ಅಥವಾ ಡಿಸ್ಕ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದೇ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅದರ ಸ್ಥಿತಿ;
• ಪ್ರಾರಂಭಿಸಿ / ನಿಲ್ಲಿಸಿ. ಡಿಸ್ಕ್ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ/ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವಿಕೆ;
• ವಲಸೆ/ಮರುಸ್ಥಾಪಿಸು. ಬದಲಿ ಸಮಯದಲ್ಲಿ ಮತ್ತು ನಂತರ ಡೇಟಾ ವಲಸೆ ಮತ್ತು ಚೇತರಿಕೆ.

ಅನ್ಸಿಬಲ್ ಅವರಿಂದ ಕಲಿತ ಪಾಠಗಳು

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

ಅನ್ಸಿಬಲ್ - ಮಾಡ್ಯುಲಾರಿಟಿಯ ಪ್ರಯೋಜನವನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲವನ್ನೂ ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳಗೊಳಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ ಪ್ಲೇಬುಕ್‌ಗಳಿವೆ; ಅವುಗಳನ್ನು ಯಾವುದೇ ನಿರ್ವಾಹಕರು, ಸ್ವಲ್ಪ ಅನ್ಸಿಬಲ್ ತಿಳಿದಿರುವ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಡೆವಲಪರ್‌ನಿಂದ ಬರೆಯಬಹುದು.

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

ಪ್ಲೇಬುಕ್‌ಗಳಲ್ಲಿ ಕೆಲವು ತರ್ಕಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕಷ್ಟವಾಗಿದ್ದರೆ, ನಾವು ಅದನ್ನು ಅನ್ಸಿಬಲ್ ಮಾಡ್ಯೂಲ್ ಅಥವಾ ಫಿಲ್ಟರ್‌ಗೆ ಸರಿಸುತ್ತೇವೆ. ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಪೈಥಾನ್ ಅಥವಾ ಇನ್ನಾವುದೇ ಭಾಷೆಯಲ್ಲಿ ಬರೆಯಬಹುದು.

ಅವರು ಬರೆಯಲು ಸುಲಭ ಮತ್ತು ತ್ವರಿತ. ಉದಾಹರಣೆಗೆ, ಡಿಸ್ಕ್ ಬ್ಯಾಕ್‌ಲೈಟ್ ಮಾಡ್ಯೂಲ್, ಅದರ ಉದಾಹರಣೆಯನ್ನು ಮೇಲೆ ತೋರಿಸಲಾಗಿದೆ, 265 ಸಾಲುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಕೆಳಮಟ್ಟದಲ್ಲಿ ಗ್ರಂಥಾಲಯವಿದೆ. ಈ ಯೋಜನೆಗಾಗಿ, ನಾವು ಒಂದು ಪ್ರತ್ಯೇಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ, ಅನುಗುಣವಾದ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ RAID ಗಳ ಮೇಲೆ ಒಂದು ರೀತಿಯ ಅಮೂರ್ತತೆ.

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

Ansible API ನೊಂದಿಗೆ ನಮ್ಮ ಅನುಭವವನ್ನು ಪುನರಾವರ್ತಿಸಲು ನೀವು ಬಯಸಿದರೆ, ಎರಡು ವಿಷಯಗಳನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ:

• ಪ್ಲೇಬುಕ್_ಎಕ್ಸಿಕ್ಯೂಟರ್ ಮತ್ತು ಪ್ಲೇಬುಕ್‌ಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಕಾಲಾವಧಿಯನ್ನು ನೀಡಲಾಗುವುದಿಲ್ಲ. ssh ಸೆಷನ್‌ನಲ್ಲಿ ಸಮಯ ಮೀರಿದೆ, ಆದರೆ ಪ್ಲೇಬುಕ್‌ನಲ್ಲಿ ಯಾವುದೇ ಸಮಯ ಮೀರುವುದಿಲ್ಲ. ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಇನ್ನು ಮುಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಡಿಸ್ಕ್ ಅನ್ನು ಅನ್‌ಮೌಂಟ್ ಮಾಡಲು ನಾವು ಪ್ರಯತ್ನಿಸಿದರೆ, ಪ್ಲೇಬುಕ್ ಅಂತ್ಯವಿಲ್ಲದೆ ರನ್ ಆಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಅದರ ಉಡಾವಣೆಯನ್ನು ಪ್ರತ್ಯೇಕ ಹೊದಿಕೆಯಲ್ಲಿ ಸುತ್ತುವಂತೆ ಮತ್ತು ಕಾಲಾವಧಿಯೊಂದಿಗೆ ಅದನ್ನು ಕೊಲ್ಲಬೇಕಾಗಿತ್ತು.
• ಅನ್ಸಿಬಲ್ ಫೋರ್ಕ್ ಮಾಡಿದ ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ ಚಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ API ಥ್ರೆಡ್ ಸುರಕ್ಷಿತವಾಗಿಲ್ಲ. ನಾವು ನಮ್ಮ ಎಲ್ಲಾ ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ಏಕ-ಥ್ರೆಡ್‌ನಲ್ಲಿ ರನ್ ಮಾಡುತ್ತೇವೆ.

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಸುಮಾರು 80% ಡಿಸ್ಕ್ಗಳ ಬದಲಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಒಟ್ಟಾರೆ, ಬದಲಿ ದರ ದ್ವಿಗುಣಗೊಂಡಿದೆ. ಇಂದು, ನಿರ್ವಾಹಕರು ಕೇವಲ ಘಟನೆಯನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ಡಿಸ್ಕ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಕೆ ಅಥವಾ ಬೇಡವೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಒಂದು ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ.

ಆದರೆ ಈಗ ನಾವು ಮತ್ತೊಂದು ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದೇವೆ: ಕೆಲವು ಹೊಸ ನಿರ್ವಾಹಕರು ಡ್ರೈವ್‌ಗಳನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸಬೇಕೆಂದು ತಿಳಿದಿಲ್ಲ. 🙂

ಮೂಲ: www.habr.com