ಒನ್-ಕ್ಲೌಡ್ - ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಯಲ್ಲಿ ಡೇಟಾ ಸೆಂಟರ್ ಮಟ್ಟದ ಓಎಸ್

ಅಲೋ, ಜನರೇ! ನನ್ನ ಹೆಸರು ಒಲೆಗ್ ಅನಸ್ತಾಸ್ಯೆವ್, ನಾನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತಂಡದಲ್ಲಿ ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ಮತ್ತು ನನ್ನ ಜೊತೆಗೆ, ಓಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಯಲ್ಲಿ ಬಹಳಷ್ಟು ಹಾರ್ಡ್‌ವೇರ್ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ. ನಾವು 500 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಸುಮಾರು 8 ರ್ಯಾಕ್‌ಗಳೊಂದಿಗೆ ನಾಲ್ಕು ಡೇಟಾ ಕೇಂದ್ರಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಹಂತದಲ್ಲಿ, ಹೊಸ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯ ಪರಿಚಯವು ಉಪಕರಣಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಲೋಡ್ ಮಾಡಲು, ಪ್ರವೇಶ ನಿರ್ವಹಣೆಯನ್ನು ಸುಗಮಗೊಳಿಸಲು, ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳ (ಮರು) ವಿತರಣೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು, ಹೊಸ ಸೇವೆಗಳ ಪ್ರಾರಂಭವನ್ನು ವೇಗಗೊಳಿಸಲು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ವೇಗಗೊಳಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ. ದೊಡ್ಡ ಪ್ರಮಾಣದ ಅಪಘಾತಗಳಿಗೆ.

ಅದರಿಂದ ಏನಾಯಿತು?

ನನ್ನ ಹೊರತಾಗಿ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್‌ನ ಗುಂಪನ್ನು ಹೊರತುಪಡಿಸಿ, ಈ ಹಾರ್ಡ್‌ವೇರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಜನರಿದ್ದಾರೆ: ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ನೇರವಾಗಿ ಇರುವ ಎಂಜಿನಿಯರ್‌ಗಳು; ನೆಟ್‌ವರ್ಕ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಹೊಂದಿಸುವ ನೆಟ್‌ವರ್ಕರ್‌ಗಳು; ಮೂಲಸೌಕರ್ಯ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಒದಗಿಸುವ ನಿರ್ವಾಹಕರು ಅಥವಾ SREಗಳು; ಮತ್ತು ಅಭಿವೃದ್ಧಿ ತಂಡಗಳು, ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಪೋರ್ಟಲ್‌ನ ಕಾರ್ಯಗಳ ಭಾಗಕ್ಕೆ ಕಾರಣವಾಗಿದೆ. ಅವರು ರಚಿಸುವ ಸಾಫ್ಟ್‌ವೇರ್ ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:

ಬಳಕೆದಾರರ ವಿನಂತಿಗಳನ್ನು ಮುಖ್ಯ ಪೋರ್ಟಲ್‌ನ ಮುಂಭಾಗದಲ್ಲಿ ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ www.ok.ru, ಮತ್ತು ಇತರರ ಮೇಲೆ, ಉದಾಹರಣೆಗೆ ಸಂಗೀತ API ಮುಂಭಾಗಗಳಲ್ಲಿ. ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು, ಅವರು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಅನ್ನು ಕರೆಯುತ್ತಾರೆ, ಇದು ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ, ಅಗತ್ಯವಾದ ವಿಶೇಷ ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳನ್ನು ಕರೆಯುತ್ತದೆ - ಒಂದು-ಗ್ರಾಫ್ (ಸಾಮಾಜಿಕ ಸಂಪರ್ಕಗಳ ಗ್ರಾಫ್), ಬಳಕೆದಾರ-ಸಂಗ್ರಹ (ಬಳಕೆದಾರ ಪ್ರೊಫೈಲ್ಗಳ ಸಂಗ್ರಹ), ಇತ್ಯಾದಿ.

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

ಅದು ಏಕೆ? ಈ ವಿಧಾನವು ಹಲವಾರು ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ:

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

ಹಲವಾರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸೇವೆಗೆ ಹಲವಾರು ಸರ್ವರ್‌ಗಳನ್ನು ಹಂಚಲಾಗುತ್ತದೆ - ಪ್ರತಿಯೊಂದಕ್ಕೂ ಒಂದು. ನಂತರ ಸೇವೆಗಾಗಿ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲವನ್ನು ಬಹಳ ಸರಳವಾಗಿ ಹಂಚಲಾಗುತ್ತದೆ: ಸೇವೆಯು ಹೊಂದಿರುವ ಸರ್ವರ್ಗಳ ಸಂಖ್ಯೆ, ಅದು ಸೇವಿಸಬಹುದಾದ ಗರಿಷ್ಠ ಪ್ರಮಾಣದ ಸಂಪನ್ಮೂಲಗಳು. ಇಲ್ಲಿ "ಸುಲಭ" ಎಂದರೆ ಅದನ್ನು ಬಳಸಲು ಸುಲಭ ಎಂದು ಅರ್ಥವಲ್ಲ, ಆದರೆ ಸಂಪನ್ಮೂಲ ಹಂಚಿಕೆಯನ್ನು ಕೈಯಾರೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬ ಅರ್ಥದಲ್ಲಿ.

ಈ ವಿಧಾನವು ನಮಗೆ ಮಾಡಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು ವಿಶೇಷ ಕಬ್ಬಿಣದ ಸಂರಚನೆಗಳು ಈ ಸರ್ವರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಕಾರ್ಯಕ್ಕಾಗಿ. ಕಾರ್ಯವು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ನಾವು 4 ಡಿಸ್ಕ್ಗಳೊಂದಿಗೆ ಚಾಸಿಸ್ನೊಂದಿಗೆ 38U ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಕಾರ್ಯವು ಸಂಪೂರ್ಣವಾಗಿ ಕಂಪ್ಯೂಟೇಶನಲ್ ಆಗಿದ್ದರೆ, ನಾವು ಅಗ್ಗದ 1U ಸರ್ವರ್ ಅನ್ನು ಖರೀದಿಸಬಹುದು. ಇದು ಕಂಪ್ಯೂಟೇಶನಲ್ ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತದೆ. ಇತರ ವಿಷಯಗಳ ಪೈಕಿ, ಈ ​​ವಿಧಾನವು ಒಂದು ಸ್ನೇಹಿ ಸಾಮಾಜಿಕ ನೆಟ್ವರ್ಕ್ಗೆ ಹೋಲಿಸಬಹುದಾದ ಲೋಡ್ನೊಂದಿಗೆ ನಾಲ್ಕು ಪಟ್ಟು ಕಡಿಮೆ ಯಂತ್ರಗಳನ್ನು ಬಳಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

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

ಇದು ನಿಜವೆಂದು ಅರಿತುಕೊಂಡ ನಾವು ರಾಕ್‌ಗಳನ್ನು ಎಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸುತ್ತಿದ್ದೇವೆ ಎಂದು ಲೆಕ್ಕ ಹಾಕಲು ನಿರ್ಧರಿಸಿದೆವು.
ನಾವು ಆರ್ಥಿಕವಾಗಿ ಸಮರ್ಥನೀಯವಾದವುಗಳಿಂದ ಅತ್ಯಂತ ಶಕ್ತಿಯುತವಾದ ಸರ್ವರ್‌ನ ಬೆಲೆಯನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಅಂತಹ ಎಷ್ಟು ಸರ್ವರ್‌ಗಳನ್ನು ನಾವು ರಾಕ್‌ಗಳಲ್ಲಿ ಇರಿಸಬಹುದು, ಹಳೆಯ ಮಾದರಿಯ "ಒಂದು ಸರ್ವರ್ = ಒಂದು ಕಾರ್ಯ" ಮತ್ತು ಎಷ್ಟು ಕಾರ್ಯಗಳನ್ನು ಆಧರಿಸಿ ನಾವು ಅವುಗಳ ಮೇಲೆ ಎಷ್ಟು ಕಾರ್ಯಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ ಎಂದು ಲೆಕ್ಕ ಹಾಕಿದ್ದೇವೆ. ಕಾರ್ಯಗಳು ಉಪಕರಣಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳಬಹುದು. ಎಣಿಸಿ ಕಣ್ಣೀರು ಹಾಕಿದರು. ಚರಣಿಗೆಗಳನ್ನು ಬಳಸುವಲ್ಲಿ ನಮ್ಮ ದಕ್ಷತೆಯು ಸುಮಾರು 11% ಎಂದು ಅದು ಬದಲಾಯಿತು. ತೀರ್ಮಾನವು ಸ್ಪಷ್ಟವಾಗಿದೆ: ನಾವು ಡೇಟಾ ಕೇಂದ್ರಗಳನ್ನು ಬಳಸುವ ದಕ್ಷತೆಯನ್ನು ಹೆಚ್ಚಿಸಬೇಕಾಗಿದೆ. ಪರಿಹಾರವು ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ: ನೀವು ಒಂದೇ ಸರ್ವರ್‌ನಲ್ಲಿ ಹಲವಾರು ಕಾರ್ಯಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಚಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ. ಆದರೆ ಇಲ್ಲಿಯೇ ತೊಂದರೆಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ.

ಸಾಮೂಹಿಕ ಸಂರಚನೆಯು ನಾಟಕೀಯವಾಗಿ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ - ಸರ್ವರ್‌ಗೆ ಯಾವುದೇ ಒಂದು ಗುಂಪನ್ನು ನಿಯೋಜಿಸಲು ಈಗ ಅಸಾಧ್ಯವಾಗಿದೆ. ಎಲ್ಲಾ ನಂತರ, ಈಗ ಒಂದು ಸರ್ವರ್ನಲ್ಲಿ ವಿವಿಧ ಆಜ್ಞೆಗಳ ಹಲವಾರು ಕಾರ್ಯಗಳನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ವಿಭಿನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಕಾನ್ಫಿಗರೇಶನ್ ಸಂಘರ್ಷವಾಗಿರಬಹುದು. ರೋಗನಿರ್ಣಯವು ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ: ಸರ್ವರ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿದ CPU ಅಥವಾ ಡಿಸ್ಕ್ ಬಳಕೆಯನ್ನು ನೀವು ನೋಡಿದರೆ, ಯಾವ ಕಾರ್ಯವು ತೊಂದರೆ ಉಂಟುಮಾಡುತ್ತದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿಲ್ಲ.

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

ನಿಸ್ಸಂಶಯವಾಗಿ, ನೀವು ಕಾರ್ಯಗಳನ್ನು ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ಅಥವಾ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಲ್ಲಿ ಚಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ. ನಮ್ಮ ಬಹುತೇಕ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ಒಂದು OS (Linux) ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ ಅಥವಾ ಅದಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುವುದರಿಂದ, ನಾವು ಹಲವಾರು ವಿಭಿನ್ನ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಅಂತೆಯೇ, ವರ್ಚುವಲೈಸೇಶನ್ ಅಗತ್ಯವಿಲ್ಲ; ಹೆಚ್ಚುವರಿ ಓವರ್ಹೆಡ್ ಕಾರಣ, ಇದು ಕಂಟೈನರೈಸೇಶನ್ಗಿಂತ ಕಡಿಮೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ.

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

ಜೊತೆಗೆ, ಡಾಕರ್‌ನಲ್ಲಿ ರೆಡಿಮೇಡ್ ರಿಜಿಸ್ಟ್ರಿ ಮತ್ತು ಇಮೇಜ್ ಟ್ಯಾಗಿಂಗ್ ನಮಗೆ ಆವೃತ್ತಿ ಮಾಡಲು ಮತ್ತು ಉತ್ಪಾದನೆಗೆ ಕೋಡ್ ಅನ್ನು ತಲುಪಿಸಲು ಸಿದ್ಧ-ಸಿದ್ಧ ಮೂಲಗಳನ್ನು ನೀಡುತ್ತದೆ.

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

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

ನೀವು 8 ಸಾವಿರ ಸರ್ವರ್‌ಗಳು ಮತ್ತು 8-16 ಸಾವಿರ ಕಂಟೇನರ್‌ಗಳನ್ನು ಹೊಂದಿರುವಾಗ ಕಂಟೈನರ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ವಿತರಿಸುವುದು ಒಂದು ಆಯ್ಕೆಯಾಗಿಲ್ಲ.

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

ನಿಸ್ಸಂಶಯವಾಗಿ, ನಮಗೆ ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಡುವ ನಿಯಂತ್ರಣ ಪದರದ ಅಗತ್ಯವಿದೆ.

ಆದ್ದರಿಂದ ನಾವು ಎಲ್ಲಾ ವಾಸ್ತುಶಿಲ್ಪಿಗಳು ಆರಾಧಿಸುವ ಸರಳ ಮತ್ತು ಅರ್ಥವಾಗುವ ಚಿತ್ರಕ್ಕೆ ಬಂದಿದ್ದೇವೆ: ಮೂರು ಚೌಕಗಳು.

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

ಸಂಪನ್ಮೂಲ ಹಂಚಿಕೆ

ಈಗ ಅನೇಕ ಗುಲಾಮರಿಗೆ ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಸಂಪನ್ಮೂಲ ಹಂಚಿಕೆಯ ಸಮಸ್ಯೆಯನ್ನು ನೋಡೋಣ.

ಒಂದು-ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲ:

• ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯದಿಂದ ಸೇವಿಸುವ ಪ್ರೊಸೆಸರ್ ಶಕ್ತಿಯ ಪ್ರಮಾಣ.
• ಕಾರ್ಯಕ್ಕೆ ಲಭ್ಯವಿರುವ ಮೆಮೊರಿಯ ಪ್ರಮಾಣ.
• ನೆಟ್ವರ್ಕ್ ಸಂಚಾರ. ಪ್ರತಿಯೊಂದು ಗುಲಾಮರು ಸೀಮಿತ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನೊಂದಿಗೆ ನಿರ್ದಿಷ್ಟ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಆದ್ದರಿಂದ ಅವರು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ರವಾನಿಸುವ ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದೆ ಕಾರ್ಯಗಳನ್ನು ವಿತರಿಸುವುದು ಅಸಾಧ್ಯ.
• ಡಿಸ್ಕ್ಗಳು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಿಸ್ಸಂಶಯವಾಗಿ, ಈ ಕಾರ್ಯಗಳಿಗಾಗಿ ಜಾಗಕ್ಕೆ, ನಾವು ಡಿಸ್ಕ್ ಪ್ರಕಾರವನ್ನು ಸಹ ನಿಯೋಜಿಸುತ್ತೇವೆ: HDD ಅಥವಾ SSD. ಡಿಸ್ಕ್‌ಗಳು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸೀಮಿತ ಸಂಖ್ಯೆಯ ವಿನಂತಿಗಳನ್ನು ನೀಡಬಹುದು - IOPS. ಆದ್ದರಿಂದ, ಒಂದೇ ಡಿಸ್ಕ್ ನಿಭಾಯಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ IOPS ಅನ್ನು ಉತ್ಪಾದಿಸುವ ಕಾರ್ಯಗಳಿಗಾಗಿ, ನಾವು "ಸ್ಪಿಂಡಲ್‌ಗಳು" ಅನ್ನು ಸಹ ನಿಯೋಜಿಸುತ್ತೇವೆ - ಅಂದರೆ, ಕಾರ್ಯಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಕಾಯ್ದಿರಿಸಬೇಕಾದ ಡಿಸ್ಕ್ ಸಾಧನಗಳು.

ನಂತರ ಕೆಲವು ಸೇವೆಗಾಗಿ, ಉದಾಹರಣೆಗೆ ಬಳಕೆದಾರ-ಸಂಗ್ರಹಕ್ಕಾಗಿ, ನಾವು ಸೇವಿಸಿದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ರೆಕಾರ್ಡ್ ಮಾಡಬಹುದು: 400 ಪ್ರೊಸೆಸರ್ ಕೋರ್ಗಳು, 2,5 TB ಮೆಮೊರಿ, 50 Gbit / s ಟ್ರಾಫಿಕ್ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ, 6 TB HDD ಸ್ಪೇಸ್ ಇದೆ 100 ಸ್ಪಿಂಡಲ್ಗಳು . ಅಥವಾ ಈ ರೀತಿಯ ಹೆಚ್ಚು ಪರಿಚಿತ ರೂಪದಲ್ಲಿ:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

ಬಳಕೆದಾರ-ಸಂಗ್ರಹ ಸೇವಾ ಸಂಪನ್ಮೂಲಗಳು ಉತ್ಪಾದನಾ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳ ಒಂದು ಭಾಗವನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತವೆ. ಆದ್ದರಿಂದ, ಹಠಾತ್ತನೆ, ಆಪರೇಟರ್ ದೋಷದಿಂದಾಗಿ ಅಥವಾ ಇಲ್ಲವೇ, ಬಳಕೆದಾರ-ಸಂಗ್ರಹವು ಅದಕ್ಕೆ ನಿಗದಿಪಡಿಸಿದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ಅಂದರೆ, ನಾವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಿತಿಗೊಳಿಸಬೇಕು. ಆದರೆ ನಾವು ಕೋಟಾವನ್ನು ಯಾವುದಕ್ಕೆ ಕಟ್ಟಬಹುದು?

ಘಟಕಗಳ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ನಮ್ಮ ಅತ್ಯಂತ ಸರಳೀಕೃತ ರೇಖಾಚಿತ್ರಕ್ಕೆ ಹಿಂತಿರುಗಿ ಮತ್ತು ಹೆಚ್ಚಿನ ವಿವರಗಳೊಂದಿಗೆ ಅದನ್ನು ಪುನಃ ಬರೆಯೋಣ - ಈ ರೀತಿ:

ಯಾವುದು ನಿಮ್ಮ ಕಣ್ಣನ್ನು ಸೆಳೆಯುತ್ತದೆ:

• ವೆಬ್ ಮುಂಭಾಗ ಮತ್ತು ಸಂಗೀತವು ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನ ಪ್ರತ್ಯೇಕ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ.
• ಈ ಕ್ಲಸ್ಟರ್‌ಗಳು ಸೇರಿರುವ ತಾರ್ಕಿಕ ಪದರಗಳನ್ನು ನಾವು ಪ್ರತ್ಯೇಕಿಸಬಹುದು: ಮುಂಭಾಗಗಳು, ಸಂಗ್ರಹಗಳು, ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ನಿರ್ವಹಣೆ ಪದರ.
• ಮುಂಭಾಗವು ವೈವಿಧ್ಯಮಯವಾಗಿದೆ; ಇದು ವಿಭಿನ್ನ ಕ್ರಿಯಾತ್ಮಕ ಉಪವ್ಯವಸ್ಥೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.
• ಕ್ಯಾಶ್‌ಗಳನ್ನು ಉಪವ್ಯವಸ್ಥೆಯಾದ್ಯಂತ ಹರಡಬಹುದು, ಅದರ ಡೇಟಾವನ್ನು ಅವರು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ.

ಚಿತ್ರವನ್ನು ಮತ್ತೆ ಚಿತ್ರಿಸೋಣ:

ಬಹ್! ಹೌದು, ನಾವು ಕ್ರಮಾನುಗತವನ್ನು ನೋಡುತ್ತೇವೆ! ಇದರರ್ಥ ನೀವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ದೊಡ್ಡ ಭಾಗಗಳಲ್ಲಿ ವಿತರಿಸಬಹುದು: ಕ್ರಿಯಾತ್ಮಕ ಉಪವ್ಯವಸ್ಥೆಗೆ (ಚಿತ್ರದಲ್ಲಿರುವ "ಸಂಗೀತ" ನಂತಹ) ಅನುಗುಣವಾದ ಈ ಶ್ರೇಣಿಯ ನೋಡ್‌ಗೆ ಜವಾಬ್ದಾರಿಯುತ ಡೆವಲಪರ್ ಅನ್ನು ನಿಯೋಜಿಸಿ ಮತ್ತು ಶ್ರೇಣಿಯ ಅದೇ ಹಂತಕ್ಕೆ ಕೋಟಾವನ್ನು ಲಗತ್ತಿಸಿ. ಈ ಕ್ರಮಾನುಗತವು ನಿರ್ವಹಣೆಯ ಸುಲಭಕ್ಕಾಗಿ ಸೇವೆಗಳನ್ನು ಹೆಚ್ಚು ಮೃದುವಾಗಿ ಸಂಘಟಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಎಲ್ಲಾ ವೆಬ್ ಅನ್ನು ವಿಭಜಿಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ಇದು ಸರ್ವರ್‌ಗಳ ದೊಡ್ಡ ಗುಂಪು, ಹಲವಾರು ಸಣ್ಣ ಗುಂಪುಗಳಾಗಿ, ಚಿತ್ರದಲ್ಲಿ ಗುಂಪು1, ಗುಂಪು2 ಎಂದು ತೋರಿಸಲಾಗಿದೆ.

ಹೆಚ್ಚುವರಿ ಸಾಲುಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ, ನಾವು ನಮ್ಮ ಚಿತ್ರದ ಪ್ರತಿಯೊಂದು ನೋಡ್ ಅನ್ನು ಚಪ್ಪಟೆ ರೂಪದಲ್ಲಿ ಬರೆಯಬಹುದು: ಗುಂಪು1.ವೆಬ್.ಮುಂಭಾಗ, api.music.front, ಬಳಕೆದಾರ-cache.cache.

ಈ ರೀತಿಯಾಗಿ ನಾವು "ಕ್ರಮಾನುಗತ ಕ್ಯೂ" ಎಂಬ ಪರಿಕಲ್ಪನೆಗೆ ಬರುತ್ತೇವೆ. ಇದು "group1.web.front" ನಂತಹ ಹೆಸರನ್ನು ಹೊಂದಿದೆ. ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಬಳಕೆದಾರರ ಹಕ್ಕುಗಳಿಗಾಗಿ ಕೋಟಾವನ್ನು ಅದಕ್ಕೆ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ. ನಾವು DevOps ನಿಂದ ವ್ಯಕ್ತಿಗೆ ಸರತಿ ಸಾಲಿನಲ್ಲಿ ಸೇವೆಯನ್ನು ಕಳುಹಿಸುವ ಹಕ್ಕುಗಳನ್ನು ನೀಡುತ್ತೇವೆ ಮತ್ತು ಅಂತಹ ಉದ್ಯೋಗಿ ಸರದಿಯಲ್ಲಿ ಏನನ್ನಾದರೂ ಪ್ರಾರಂಭಿಸಬಹುದು ಮತ್ತು OpsDev ನಿಂದ ವ್ಯಕ್ತಿಯು ನಿರ್ವಾಹಕ ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿರುತ್ತಾರೆ ಮತ್ತು ಈಗ ಅವರು ಸರದಿಯನ್ನು ನಿರ್ವಹಿಸಬಹುದು, ಅಲ್ಲಿ ಜನರನ್ನು ನಿಯೋಜಿಸಬಹುದು, ಈ ಜನರಿಗೆ ಹಕ್ಕುಗಳನ್ನು ನೀಡಿ, ಇತ್ಯಾದಿ. ಈ ಸರದಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸೇವೆಗಳು ಸರದಿಯ ಕೋಟಾದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸರದಿಯ ಕಂಪ್ಯೂಟಿಂಗ್ ಕೋಟಾವು ಸಾಕಾಗದೇ ಇದ್ದರೆ, ನಂತರ ಅವುಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಹೀಗಾಗಿ ಸರದಿಯು ಸ್ವತಃ ರೂಪುಗೊಳ್ಳುತ್ತದೆ.

ಸೇವೆಗಳನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ. ಸೇವೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಅರ್ಹವಾದ ಹೆಸರನ್ನು ಹೊಂದಿದೆ, ಇದು ಯಾವಾಗಲೂ ಸರದಿಯ ಹೆಸರನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ನಂತರ ಮುಂಭಾಗದ ವೆಬ್ ಸೇವೆ ಹೆಸರನ್ನು ಹೊಂದಿರುತ್ತದೆ ಸರಿ-web.group1.web.front. ಮತ್ತು ಅದು ಪ್ರವೇಶಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಸೇವೆಯನ್ನು ಕರೆಯಲಾಗುವುದು ok-app.group1.web.front. ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಹೊಂದಿದೆ, ಇದು ನಿರ್ದಿಷ್ಟ ಯಂತ್ರಗಳಲ್ಲಿ ಇರಿಸಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ: ಈ ಕಾರ್ಯವು ಎಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಅದಕ್ಕೆ ಯಾವ ಸಂರಚನೆಯ ಅಗತ್ಯವಿದೆ, ಎಷ್ಟು ಪ್ರತಿಕೃತಿಗಳು ಇರಬೇಕು, ಈ ಸೇವೆಯ ವೈಫಲ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಗುಣಲಕ್ಷಣಗಳು. ಮತ್ತು ಸೇವೆಯನ್ನು ನೇರವಾಗಿ ಯಂತ್ರಗಳಲ್ಲಿ ಇರಿಸಿದ ನಂತರ, ಅದರ ನಿದರ್ಶನಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಅವುಗಳನ್ನು ನಿಸ್ಸಂದಿಗ್ಧವಾಗಿ ಹೆಸರಿಸಲಾಗಿದೆ - ನಿದರ್ಶನ ಸಂಖ್ಯೆ ಮತ್ತು ಸೇವೆಯ ಹೆಸರು: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

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

ಈಗ ಈ ನಿದರ್ಶನಗಳು ನಿಜವಾಗಿ ಏನು ನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ: ಕಾರ್ಯಗಳು.

ಕಾರ್ಯ ಪ್ರತ್ಯೇಕತೆಯ ತರಗತಿಗಳು

ಸರಿ (ಮತ್ತು, ಬಹುಶಃ, ಎಲ್ಲೆಡೆ) ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:

• ಸಣ್ಣ ಸುಪ್ತ ಕಾರ್ಯಗಳು - ಉತ್ಪನ್ನ. ಅಂತಹ ಕಾರ್ಯಗಳು ಮತ್ತು ಸೇವೆಗಳಿಗೆ, ಪ್ರತಿಕ್ರಿಯೆ ವಿಳಂಬ (ಲೇಟೆನ್ಸಿ) ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ, ಪ್ರತಿ ವಿನಂತಿಗಳನ್ನು ಸಿಸ್ಟಮ್ ಎಷ್ಟು ಬೇಗನೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಕಾರ್ಯಗಳ ಉದಾಹರಣೆಗಳು: ವೆಬ್ ಮುಂಭಾಗಗಳು, ಕ್ಯಾಷ್‌ಗಳು, ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು, OLTP ಸಂಗ್ರಹಣೆ, ಇತ್ಯಾದಿ.
• ಲೆಕ್ಕಾಚಾರದ ಸಮಸ್ಯೆಗಳು - ಬ್ಯಾಚ್. ಇಲ್ಲಿ, ಪ್ರತಿ ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಯ ಪ್ರಕ್ರಿಯೆಯ ವೇಗವು ಮುಖ್ಯವಲ್ಲ. ಅವರಿಗೆ, ಈ ಕಾರ್ಯವು ಒಂದು ನಿರ್ದಿಷ್ಟ (ದೀರ್ಘ) ಅವಧಿಯಲ್ಲಿ (ಥ್ರೋಪುಟ್) ಎಷ್ಟು ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಮಾಡುತ್ತದೆ ಎಂಬುದು ಮುಖ್ಯವಾಗಿದೆ. ಇವುಗಳು MapReduce, Hadoop, ಯಂತ್ರ ಕಲಿಕೆ, ಅಂಕಿಅಂಶಗಳ ಯಾವುದೇ ಕಾರ್ಯಗಳಾಗಿವೆ.
• ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳು - ಐಡಲ್. ಅಂತಹ ಕಾರ್ಯಗಳಿಗೆ, ಸುಪ್ತತೆ ಅಥವಾ ಥ್ರೋಪುಟ್ ಬಹಳ ಮುಖ್ಯವಲ್ಲ. ಇದು ವಿವಿಧ ಪರೀಕ್ಷೆಗಳು, ವಲಸೆಗಳು, ಮರು ಲೆಕ್ಕಾಚಾರಗಳು ಮತ್ತು ಡೇಟಾವನ್ನು ಒಂದು ಸ್ವರೂಪದಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಪರಿವರ್ತಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಒಂದೆಡೆ, ಅವರು ಲೆಕ್ಕ ಹಾಕಿದ ಪದಗಳಿಗಿಂತ ಹೋಲುತ್ತಾರೆ, ಮತ್ತೊಂದೆಡೆ, ಅವರು ಎಷ್ಟು ಬೇಗನೆ ಪೂರ್ಣಗೊಳಿಸುತ್ತಾರೆ ಎಂಬುದು ನಮಗೆ ನಿಜವಾಗಿಯೂ ವಿಷಯವಲ್ಲ.

ಅಂತಹ ಕಾರ್ಯಗಳು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ, ಉದಾಹರಣೆಗೆ, ಕೇಂದ್ರ ಪ್ರೊಸೆಸರ್.

ಸಣ್ಣ ವಿಳಂಬ ಕಾರ್ಯಗಳು. ಅಂತಹ ಕಾರ್ಯವು ಈ ರೀತಿಯ CPU ಬಳಕೆಯ ಮಾದರಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ:

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

ಅಂತಹ ಕಾರ್ಯಕ್ಕಾಗಿ ಕನಿಷ್ಠ ಸುಪ್ತತೆಯನ್ನು ಖಾತರಿಪಡಿಸಲು, ನಾವು ಅದನ್ನು ಸೇವಿಸುವ ಗರಿಷ್ಠ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಮತ್ತು ಗುಲಾಮ (ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಯಂತ್ರ) ಮೇಲೆ ಅಗತ್ಯವಿರುವ ಸಂಖ್ಯೆಯ ಕೋರ್‌ಗಳನ್ನು ಕಾಯ್ದಿರಿಸಬೇಕು. ನಂತರ ನಮ್ಮ ಸಮಸ್ಯೆಗೆ ಮೀಸಲಾತಿ ಸೂತ್ರವು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:

alloc: cpu = 4 (max)

ಮತ್ತು ನಾವು 16 ಕೋರ್ಗಳೊಂದಿಗೆ ಗುಲಾಮ ಯಂತ್ರವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದರ ಮೇಲೆ ನಿಖರವಾಗಿ ನಾಲ್ಕು ಕಾರ್ಯಗಳನ್ನು ಇರಿಸಬಹುದು. ಅಂತಹ ಕಾರ್ಯಗಳ ಸರಾಸರಿ ಪ್ರೊಸೆಸರ್ ಬಳಕೆ ಸಾಮಾನ್ಯವಾಗಿ ತುಂಬಾ ಕಡಿಮೆ ಎಂದು ನಾವು ವಿಶೇಷವಾಗಿ ಗಮನಿಸುತ್ತೇವೆ - ಇದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಏಕೆಂದರೆ ಸಮಯದ ಗಮನಾರ್ಹ ಭಾಗವು ವಿನಂತಿಗಾಗಿ ಕಾಯುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

ಲೆಕ್ಕಾಚಾರ ಕಾರ್ಯಗಳು. ಅವರ ಮಾದರಿ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ:

ಅಂತಹ ಕಾರ್ಯಗಳಿಗಾಗಿ ಸರಾಸರಿ CPU ಸಂಪನ್ಮೂಲ ಬಳಕೆ ಸಾಕಷ್ಟು ಹೆಚ್ಚಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ ನಾವು ಲೆಕ್ಕಾಚಾರದ ಕಾರ್ಯವನ್ನು ನಿರ್ದಿಷ್ಟ ಸಮಯದಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸಲು ಬಯಸುತ್ತೇವೆ, ಆದ್ದರಿಂದ ನಾವು ಅದಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ಪ್ರೊಸೆಸರ್‌ಗಳನ್ನು ಕಾಯ್ದಿರಿಸಬೇಕು ಇದರಿಂದ ಸಂಪೂರ್ಣ ಲೆಕ್ಕಾಚಾರವು ಸ್ವೀಕಾರಾರ್ಹ ಸಮಯದಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ. ಅದರ ಮೀಸಲಾತಿ ಸೂತ್ರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

alloc: cpu = [1,*)

"ದಯವಿಟ್ಟು ಅದನ್ನು ಕನಿಷ್ಠ ಒಂದು ಉಚಿತ ಕೋರ್ ಇರುವ ಗುಲಾಮರ ಮೇಲೆ ಇರಿಸಿ, ಮತ್ತು ನಂತರ ಇರುವಷ್ಟು, ಅದು ಎಲ್ಲವನ್ನೂ ತಿನ್ನುತ್ತದೆ."

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

ಆದರೆ ಅದನ್ನು ಹೇಗೆ ಮಾಡುವುದು?

ಮೊದಲಿಗೆ, ಪ್ರಾಡ್ ಮತ್ತು ಅದರ ಹಂಚಿಕೆಯನ್ನು ನೋಡೋಣ: cpu = 4. ನಾವು ನಾಲ್ಕು ಕೋರ್ಗಳನ್ನು ಕಾಯ್ದಿರಿಸಬೇಕಾಗಿದೆ. ಡಾಕರ್ ರನ್ನಲ್ಲಿ ಇದನ್ನು ಎರಡು ರೀತಿಯಲ್ಲಿ ಮಾಡಬಹುದು:

• ಆಯ್ಕೆಯನ್ನು ಬಳಸುವುದು --cpuset=1-4, ಅಂದರೆ ಕಾರ್ಯಕ್ಕೆ ಯಂತ್ರದಲ್ಲಿ ನಾಲ್ಕು ನಿರ್ದಿಷ್ಟ ಕೋರ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಿ.
• ಬಳಸಲು --cpuquota=400_000 --cpuperiod=100_000, ಪ್ರೊಸೆಸರ್ ಸಮಯಕ್ಕೆ ಕೋಟಾವನ್ನು ನಿಯೋಜಿಸಿ, ಅಂದರೆ ನೈಜ ಸಮಯದ ಪ್ರತಿ 100 ms ಕಾರ್ಯವು 400 ms ಗಿಂತ ಹೆಚ್ಚು ಪ್ರೊಸೆಸರ್ ಸಮಯವನ್ನು ಬಳಸುವುದಿಲ್ಲ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಅದೇ ನಾಲ್ಕು ಕೋರ್ಗಳನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ.

ಆದರೆ ಈ ವಿಧಾನಗಳಲ್ಲಿ ಯಾವುದು ಸೂಕ್ತವಾಗಿದೆ?

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

ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ಕೋರ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಡಾಕರ್‌ನಲ್ಲಿ ಮೀಸಲಾತಿ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ. ಬ್ಯಾಚ್ ಕಾರ್ಯಗಳಿಗಾಗಿ ಕೋಟಾವು ಇನ್ನು ಮುಂದೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಗರಿಷ್ಠವನ್ನು ಮಿತಿಗೊಳಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಕನಿಷ್ಠವನ್ನು ಖಾತರಿಪಡಿಸಿದರೆ ಸಾಕು. ಮತ್ತು ಇಲ್ಲಿ ಆಯ್ಕೆಯು ಚೆನ್ನಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ docker run --cpushares.

ಬ್ಯಾಚ್‌ಗೆ ಕನಿಷ್ಠ ಒಂದು ಕೋರ್‌ಗೆ ಗ್ಯಾರಂಟಿ ಅಗತ್ಯವಿದ್ದರೆ, ನಾವು ಸೂಚಿಸುತ್ತೇವೆ ಎಂದು ನಾವು ಒಪ್ಪಿಕೊಂಡಿದ್ದೇವೆ --cpushares=1024, ಮತ್ತು ಕನಿಷ್ಠ ಎರಡು ಕೋರ್ಗಳು ಇದ್ದರೆ, ನಂತರ ನಾವು ಸೂಚಿಸುತ್ತೇವೆ --cpushares=2048. ಸಿಪಿಯು ಷೇರುಗಳು ಪ್ರೊಸೆಸರ್ ಸಮಯದ ವಿತರಣೆಯಲ್ಲಿ ಸಾಕಷ್ಟು ಇರುವವರೆಗೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಹಸ್ತಕ್ಷೇಪ ಮಾಡುವುದಿಲ್ಲ. ಹೀಗಾಗಿ, ಪ್ರಾಡ್ ಪ್ರಸ್ತುತ ಅದರ ಎಲ್ಲಾ ನಾಲ್ಕು ಕೋರ್ಗಳನ್ನು ಬಳಸದಿದ್ದರೆ, ಬ್ಯಾಚ್ ಕಾರ್ಯಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಏನೂ ಇಲ್ಲ, ಮತ್ತು ಅವರು ಹೆಚ್ಚುವರಿ ಪ್ರೊಸೆಸರ್ ಸಮಯವನ್ನು ಬಳಸಬಹುದು. ಆದರೆ ಪ್ರೊಸೆಸರ್‌ಗಳ ಕೊರತೆಯಿರುವ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಉತ್ಪನ್ನವು ಅದರ ಎಲ್ಲಾ ನಾಲ್ಕು ಕೋರ್‌ಗಳನ್ನು ಸೇವಿಸಿ ಅದರ ಕೋಟಾವನ್ನು ತಲುಪಿದ್ದರೆ, ಉಳಿದ ಪ್ರೊಸೆಸರ್ ಸಮಯವನ್ನು cpushares ಗೆ ಅನುಪಾತದಲ್ಲಿ ವಿಂಗಡಿಸಲಾಗುತ್ತದೆ, ಅಂದರೆ ಮೂರು ಉಚಿತ ಕೋರ್‌ಗಳ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಒಂದು 1024 cpushares ಹೊಂದಿರುವ ಕಾರ್ಯಕ್ಕೆ ನೀಡಲಾಗಿದೆ, ಮತ್ತು ಉಳಿದ ಎರಡನ್ನು 2048 cpushares ಹೊಂದಿರುವ ಕಾರ್ಯಕ್ಕೆ ನೀಡಲಾಗುತ್ತದೆ.

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

• SCHED_OTHER
  ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, Linux ಗಣಕದಲ್ಲಿ ಎಲ್ಲಾ ಸಾಮಾನ್ಯ ಬಳಕೆದಾರ ಪ್ರಕ್ರಿಯೆಗಳು ಸ್ವೀಕರಿಸುತ್ತವೆ.
• SCHED_BATCH
  ಸಂಪನ್ಮೂಲ-ತೀವ್ರ ಪ್ರಕ್ರಿಯೆಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಪ್ರೊಸೆಸರ್‌ನಲ್ಲಿ ಕಾರ್ಯವನ್ನು ಇರಿಸುವಾಗ, ಸಕ್ರಿಯಗೊಳಿಸುವ ಪೆನಾಲ್ಟಿ ಎಂದು ಕರೆಯಲ್ಪಡುವದನ್ನು ಪರಿಚಯಿಸಲಾಗುತ್ತದೆ: ಅಂತಹ ಕಾರ್ಯವು ಪ್ರಸ್ತುತ SCHED_OTHER ಜೊತೆಗೆ ಕಾರ್ಯದಿಂದ ಬಳಸುತ್ತಿದ್ದರೆ ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆ
• SCHED_IDLE
  ಅತ್ಯಂತ ಕಡಿಮೆ ಆದ್ಯತೆಯ ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆ, ಉತ್ತಮ -19 ಗಿಂತ ಕಡಿಮೆ. ನಾವು ನಮ್ಮ ಓಪನ್ ಸೋರ್ಸ್ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುತ್ತೇವೆ ಒಂದು-ನಿಯೋ, ಕರೆ ಮಾಡುವ ಮೂಲಕ ಕಂಟೇನರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ಅಗತ್ಯ ನೀತಿಯನ್ನು ಹೊಂದಿಸಲು

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

ಆದರೆ ನೀವು ಜಾವಾದಲ್ಲಿ ಪ್ರೋಗ್ರಾಮ್ ಮಾಡದಿದ್ದರೂ ಸಹ, chrt ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅದೇ ಕೆಲಸವನ್ನು ಮಾಡಬಹುದು:

chrt -i 0 $pid

ಸ್ಪಷ್ಟತೆಗಾಗಿ ನಮ್ಮ ಎಲ್ಲಾ ಪ್ರತ್ಯೇಕತೆಯ ಹಂತಗಳನ್ನು ಒಂದೇ ಕೋಷ್ಟಕದಲ್ಲಿ ಸಾರಾಂಶ ಮಾಡೋಣ:

ನಿರೋಧನ ವರ್ಗ
ಉದಾಹರಣೆಯನ್ನು ನಿಯೋಜಿಸಿ
ಡಾಕರ್ ರನ್ ಆಯ್ಕೆಗಳು
ಷೆಡ್_ಸೆಟ್ಶೆಡ್ಯೂಲರ್ chrt*

ಉತ್ಪನ್ನ
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

ಬ್ಯಾಚ್
ಸಿಪಿಯು = [1, *)
--cpushares=1024
SCHED_BATCH

ಐಡಲ್
Cpu= [2, *)
--cpushares=2048
SCHED_IDLE

*ನೀವು ಕಂಟೇನರ್ ಒಳಗಿನಿಂದ chrt ಮಾಡುತ್ತಿದ್ದರೆ, ನಿಮಗೆ sys_nice ಸಾಮರ್ಥ್ಯ ಬೇಕಾಗಬಹುದು, ಏಕೆಂದರೆ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಧಾರಕವನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ಡಾಕರ್ ಈ ಸಾಮರ್ಥ್ಯವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

ಆದರೆ ಕಾರ್ಯಗಳು ಪ್ರೊಸೆಸರ್ ಅನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸಹ ಬಳಸುತ್ತವೆ, ಇದು ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳ ತಪ್ಪಾದ ಹಂಚಿಕೆಗಿಂತ ಹೆಚ್ಚಾಗಿ ನೆಟ್ವರ್ಕ್ ಕಾರ್ಯದ ಸುಪ್ತತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಾವು ಸ್ವಾಭಾವಿಕವಾಗಿ ಸಂಚಾರಕ್ಕಾಗಿ ಅದೇ ಚಿತ್ರವನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತೇವೆ. ಅಂದರೆ, ಪ್ರಾಡ್ ಕಾರ್ಯವು ಕೆಲವು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಕಳುಹಿಸಿದಾಗ, ನಾವು ಗರಿಷ್ಠ ವೇಗವನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತೇವೆ (ಸೂತ್ರ ಹಂಚಿಕೆ: ಲ್ಯಾನ್=[*,500mbps) ), ಯಾವ ಉತ್ಪನ್ನದೊಂದಿಗೆ ಇದನ್ನು ಮಾಡಬಹುದು. ಮತ್ತು ಬ್ಯಾಚ್‌ಗಾಗಿ ನಾವು ಕನಿಷ್ಟ ಥ್ರೋಪುಟ್ ಅನ್ನು ಮಾತ್ರ ಖಾತರಿಪಡಿಸುತ್ತೇವೆ, ಆದರೆ ಗರಿಷ್ಠವನ್ನು ಮಿತಿಗೊಳಿಸಬೇಡಿ (ಸೂತ್ರ ಹಂಚಿಕೆ: ಲ್ಯಾನ್=[10Mbps,*) ) ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಬ್ಯಾಚ್ ಕಾರ್ಯಗಳಿಗಿಂತ ಪ್ರಾಡ್ ಟ್ರಾಫಿಕ್ ಆದ್ಯತೆಯನ್ನು ಪಡೆಯಬೇಕು.
ಇಲ್ಲಿ ಡಾಕರ್ ನಾವು ಬಳಸಬಹುದಾದ ಯಾವುದೇ ಪ್ರೈಮಿಟಿವ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಆದರೆ ಅದು ನಮ್ಮ ಸಹಾಯಕ್ಕೆ ಬರುತ್ತದೆ ಲಿನಕ್ಸ್ ಸಂಚಾರ ನಿಯಂತ್ರಣ. ಶಿಸ್ತಿನ ಸಹಾಯದಿಂದ ನಾವು ಬಯಸಿದ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಾಯಿತು ಶ್ರೇಣೀಕೃತ ನ್ಯಾಯೋಚಿತ ಸೇವಾ ಕರ್ವ್. ಅದರ ಸಹಾಯದಿಂದ, ನಾವು ಎರಡು ವರ್ಗದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತೇವೆ: ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಉತ್ಪನ್ನ ಮತ್ತು ಕಡಿಮೆ ಆದ್ಯತೆಯ ಬ್ಯಾಚ್/ಐಡಲ್. ಪರಿಣಾಮವಾಗಿ, ಹೊರಹೋಗುವ ದಟ್ಟಣೆಯ ಸಂರಚನೆಯು ಹೀಗಿದೆ:

ಇಲ್ಲಿ 1:0 hsfc ಶಿಸ್ತಿನ "ರೂಟ್ qdisc" ಆಗಿದೆ; 1:1 - 8 Gbit/s ನ ಒಟ್ಟು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮಿತಿಯನ್ನು ಹೊಂದಿರುವ hsfc ಚೈಲ್ಡ್ ಕ್ಲಾಸ್, ಅದರ ಅಡಿಯಲ್ಲಿ ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳ ಮಕ್ಕಳ ವರ್ಗಗಳನ್ನು ಇರಿಸಲಾಗುತ್ತದೆ; 1:2 - hsfc ಚೈಲ್ಡ್ ಕ್ಲಾಸ್ ಎಲ್ಲಾ ಬ್ಯಾಚ್ ಮತ್ತು ಐಡಲ್ ಟಾಸ್ಕ್‌ಗಳಿಗೆ "ಡೈನಾಮಿಕ್" ಮಿತಿಯೊಂದಿಗೆ ಸಾಮಾನ್ಯವಾಗಿದೆ, ಇದನ್ನು ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗಿದೆ. ಉಳಿದಿರುವ hsfc ಚೈಲ್ಡ್ ಕ್ಲಾಸ್‌ಗಳು ಪ್ರಸ್ತುತ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಾಡ್ ಕಂಟೈನರ್‌ಗಳಿಗೆ ಅವುಗಳ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳಿಗೆ ಅನುಗುಣವಾದ ಮಿತಿಗಳೊಂದಿಗೆ ಮೀಸಲಾದ ತರಗತಿಗಳಾಗಿವೆ - 450 ಮತ್ತು 400 Mbit/s. ಟ್ರಾಫಿಕ್ ಸ್ಫೋಟಗಳ ಸಮಯದಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ನಷ್ಟವನ್ನು ತಪ್ಪಿಸಲು ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಆವೃತ್ತಿಯನ್ನು ಅವಲಂಬಿಸಿ ಪ್ರತಿಯೊಂದು hsfc ವರ್ಗಕ್ಕೆ qdisc ಕ್ಯೂ fq ಅಥವಾ fq_codel ಅನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ.

ವಿಶಿಷ್ಟವಾಗಿ, tc ವಿಭಾಗಗಳು ಹೊರಹೋಗುವ ಸಂಚಾರಕ್ಕೆ ಮಾತ್ರ ಆದ್ಯತೆ ನೀಡುತ್ತವೆ. ಆದರೆ ಒಳಬರುವ ಟ್ರಾಫಿಕ್‌ಗೆ ಆದ್ಯತೆ ನೀಡಲು ನಾವು ಬಯಸುತ್ತೇವೆ - ಎಲ್ಲಾ ನಂತರ, ಕೆಲವು ಬ್ಯಾಚ್ ಕಾರ್ಯವು ಸಂಪೂರ್ಣ ಒಳಬರುವ ಚಾನಲ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ, ಮ್ಯಾಪ್&ಕಡಿಮೆಗಾಗಿ ಇನ್‌ಪುಟ್ ಡೇಟಾದ ದೊಡ್ಡ ಬ್ಯಾಚ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಇದಕ್ಕಾಗಿ ನಾವು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ ifb, ಇದು ಪ್ರತಿ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ifbX ವರ್ಚುವಲ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಒಳಬರುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ifbX ನಲ್ಲಿ ಹೊರಹೋಗುವ ಟ್ರಾಫಿಕ್‌ಗೆ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ. ಇದಲ್ಲದೆ, ifbX ಗಾಗಿ, ಹೊರಹೋಗುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಲು ಒಂದೇ ರೀತಿಯ ವಿಭಾಗಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಇದಕ್ಕಾಗಿ hsfc ಕಾನ್ಫಿಗರೇಶನ್ ತುಂಬಾ ಹೋಲುತ್ತದೆ:

ಪ್ರಯೋಗಗಳ ಸಮಯದಲ್ಲಿ, 1:2 ವರ್ಗದ ಆದ್ಯತೆಯಿಲ್ಲದ ಬ್ಯಾಚ್/ಐಡಲ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮಿನಿಯನ್ ಯಂತ್ರಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಉಚಿತ ಲೇನ್‌ಗಿಂತ ಹೆಚ್ಚಿಗೆ ಸೀಮಿತಗೊಳಿಸಿದಾಗ hsfc ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ತೋರಿಸುತ್ತದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಇಲ್ಲದಿದ್ದರೆ, ಆದ್ಯತೆಯಿಲ್ಲದ ದಟ್ಟಣೆಯು ಉತ್ಪನ್ನದ ಕಾರ್ಯಗಳ ಸುಪ್ತತೆಯ ಮೇಲೆ ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. miniond ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಉಚಿತ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನ ಪ್ರಸ್ತುತ ಮೊತ್ತವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ನಿರ್ದಿಷ್ಟ ಮಿನಿಯನ್‌ನ ಎಲ್ಲಾ ಉತ್ಪನ್ನ-ಕಾರ್ಯಗಳ ಸರಾಸರಿ ಸಂಚಾರ ಬಳಕೆಯನ್ನು ಅಳೆಯುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನಿಂದ ಕಳೆಯುವುದು ಸಣ್ಣ ಅಂಚುಗಳೊಂದಿಗೆ, ಅಂದರೆ.

ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಸಂಚಾರಕ್ಕಾಗಿ ಬ್ಯಾಂಡ್‌ಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಮತ್ತು ಹೊಸ ಮೌಲ್ಯಗಳ ಪ್ರಕಾರ, miniond ಆದ್ಯತೆಯಿಲ್ಲದ ವರ್ಗ ಮಿತಿಯನ್ನು 1:2 ಅನ್ನು ಮರುಸಂರಚಿಸುತ್ತದೆ.

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

ನಮ್ಮ ಎಲ್ಲಾ ಸ್ನೇಹಿತರು ವೆಬ್ и ಸಂಗೀತ ಮುಂಭಾಗಗಳನ್ನು ನಂತರ ಪ್ರೋಡ್ ಅಡಿಯಲ್ಲಿ ಕ್ರಮಾನುಗತದಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಬ್ಯಾಚ್ ಅಡಿಯಲ್ಲಿ, ಸೇವೆಯನ್ನು ಇರಿಸೋಣ ಸಂಗೀತ ಕ್ಯಾಟಲಾಗ್, ಇದು ನಿಯತಕಾಲಿಕವಾಗಿ Odnoklassniki ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾದ mp3 ಫೈಲ್‌ಗಳ ಗುಂಪಿನಿಂದ ಟ್ರ್ಯಾಕ್‌ಗಳ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡುತ್ತದೆ. ಐಡಲ್ ಅಡಿಯಲ್ಲಿ ಸೇವೆಯ ಉದಾಹರಣೆಯಾಗಿದೆ ಸಂಗೀತ ಪರಿವರ್ತಕ, ಇದು ಸಂಗೀತದ ಪರಿಮಾಣ ಮಟ್ಟವನ್ನು ಸಾಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ.

ಹೆಚ್ಚುವರಿ ಸಾಲುಗಳನ್ನು ಮತ್ತೆ ತೆಗೆದುಹಾಕುವುದರೊಂದಿಗೆ, ಪೂರ್ಣ ಸೇವೆಯ ಹೆಸರಿನ ಅಂತ್ಯಕ್ಕೆ ಕಾರ್ಯ ಪ್ರತ್ಯೇಕತೆಯ ವರ್ಗವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ನಾವು ನಮ್ಮ ಸೇವೆಯ ಹೆಸರನ್ನು ಹೊಗಳುವಂತೆ ಬರೆಯಬಹುದು: web.front.prod, catalog.music.batch, ಟ್ರಾನ್ಸ್ಫಾರ್ಮರ್.ಮ್ಯೂಸಿಕ್.ಐಡಲ್.

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

ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ, ಆದರೆ ಒಂದು ಕಹಿ ಸತ್ಯವಿದೆ. ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಕಾರ್ಯಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿಸುವುದು ಅಸಾಧ್ಯ.

ನಾವು ಏನು ಸಾಧಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ: ಬ್ಯಾಚ್ ತೀವ್ರವಾಗಿ ಸೇವಿಸಿದರೆ ಮಾತ್ರ CPU ಸಂಪನ್ಮೂಲಗಳು, ನಂತರ ಅಂತರ್ನಿರ್ಮಿತ Linux CPU ಶೆಡ್ಯೂಲರ್ ತನ್ನ ಕೆಲಸವನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರಾಡ್ ಕಾರ್ಯದ ಮೇಲೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಯಾವುದೇ ಪರಿಣಾಮವಿಲ್ಲ. ಆದರೆ ಈ ಬ್ಯಾಚ್ ಕಾರ್ಯವು ಮೆಮೊರಿಯೊಂದಿಗೆ ಸಕ್ರಿಯವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ನಂತರ ಪರಸ್ಪರ ಪ್ರಭಾವವು ಈಗಾಗಲೇ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಇದು ಸಂಭವಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಪ್ರೊಸೆಸರ್ನ ಮೆಮೊರಿ ಸಂಗ್ರಹಗಳಿಂದ ಪ್ರಾಡ್ ಕಾರ್ಯವು "ತೊಳೆದುಕೊಂಡಿದೆ" - ಪರಿಣಾಮವಾಗಿ, ಸಂಗ್ರಹವು ಹೆಚ್ಚಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರೊಸೆಸರ್ ಪ್ರಾಡ್ ಕಾರ್ಯವನ್ನು ಹೆಚ್ಚು ನಿಧಾನವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಅಂತಹ ಬ್ಯಾಚ್ ಕಾರ್ಯವು ನಮ್ಮ ವಿಶಿಷ್ಟ ಉತ್ಪನ್ನದ ಕಂಟೇನರ್‌ನ ಸುಪ್ತತೆಯನ್ನು 10% ರಷ್ಟು ಹೆಚ್ಚಿಸಬಹುದು.

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

ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಇಲ್ಲಿಯವರೆಗೆ TCP ಟ್ರಾಫಿಕ್‌ಗೆ ಆದ್ಯತೆ ನೀಡುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಮಾತ್ರ ನಿರ್ವಹಿಸಿದ್ದೇವೆ: Hsfc ವಿಧಾನವು UDP ಗಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಮತ್ತು TCP ದಟ್ಟಣೆಯ ಸಂದರ್ಭದಲ್ಲಿಯೂ ಸಹ, ಬ್ಯಾಚ್ ಕಾರ್ಯವು ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯನ್ನು ಉಂಟುಮಾಡಿದರೆ, ಇದು ಉತ್ಪನ್ನದ ಕಾರ್ಯದ ವಿಳಂಬದಲ್ಲಿ ಸುಮಾರು 10% ಹೆಚ್ಚಳವನ್ನು ನೀಡುತ್ತದೆ.

ದೋಷಸಹಿಷ್ಣುತೆ

ಒಡ್ನೋಕ್ಲಾಸ್ನಿಕಿಯ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಸುಧಾರಿಸುವುದು ಒಂದು-ಕ್ಲೌಡ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ ಗುರಿಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಆದ್ದರಿಂದ, ಮುಂದೆ ನಾನು ವೈಫಲ್ಯಗಳು ಮತ್ತು ಅಪಘಾತಗಳ ಸಂಭವನೀಯ ಸನ್ನಿವೇಶಗಳನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಪರಿಗಣಿಸಲು ಬಯಸುತ್ತೇನೆ. ಸರಳ ಸನ್ನಿವೇಶದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ - ಕಂಟೇನರ್ ವೈಫಲ್ಯ.

ಕಂಟೇನರ್ ಸ್ವತಃ ಹಲವಾರು ವಿಧಗಳಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು. ಇದು ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಪ್ರಯೋಗ, ದೋಷ ಅಥವಾ ದೋಷವಾಗಿರಬಹುದು, ಇದರಿಂದಾಗಿ ಪ್ರಾಡ್ ಕಾರ್ಯವು ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನಲ್ಲಿ ಸೂಚಿಸಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ನಾವು ಒಂದು ಪ್ರಕರಣವನ್ನು ಹೊಂದಿದ್ದೇವೆ: ಡೆವಲಪರ್ ಒಂದು ಸಂಕೀರ್ಣ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದರು, ಅದನ್ನು ಹಲವು ಬಾರಿ ಮರುಸೃಷ್ಟಿಸಿದರು, ಸ್ವತಃ ಯೋಚಿಸಿದರು ಮತ್ತು ಗೊಂದಲಕ್ಕೊಳಗಾದರು, ಅಂತಿಮವಾಗಿ ಸಮಸ್ಯೆಯು ಅತ್ಯಂತ ಕ್ಷುಲ್ಲಕ ರೀತಿಯಲ್ಲಿ ಲೂಪ್ ಮಾಡಲ್ಪಟ್ಟಿತು. ಮತ್ತು ಉತ್ಪನ್ನದ ಕಾರ್ಯವು ಒಂದೇ ಗುಲಾಮರಲ್ಲಿ ಇತರರಿಗಿಂತ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಇದು ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸಲು ಪ್ರಾರಂಭಿಸಿತು. ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಪ್ರತ್ಯೇಕತೆ ಅಥವಾ ಬದಲಿಗೆ CPU ಸಮಯದ ಕೋಟಾ, ದಿನವನ್ನು ಉಳಿಸಿತು. ಒಂದು ಕಾರ್ಯಕ್ಕೆ ಕೋಟಾವನ್ನು ನಿಗದಿಪಡಿಸಿದರೆ, ಕಾರ್ಯವು ಹೆಚ್ಚು ಸೇವಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಅದೇ ಯಂತ್ರದಲ್ಲಿ ನಡೆಯುವ ಬ್ಯಾಚ್ ಮತ್ತು ಇತರ ಪ್ರಾಡ್ ಕಾರ್ಯಗಳು ಏನನ್ನೂ ಗಮನಿಸಲಿಲ್ಲ.

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

ಸಂಪೂರ್ಣ ಗುಲಾಮರು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ನೀವು ಏನು ಮಾಡಬಹುದು?

ನಿಸ್ಸಂಶಯವಾಗಿ, ಮತ್ತೊಂದು ಯಂತ್ರದಲ್ಲಿ ಕಂಟೇನರ್ ಅನ್ನು ರನ್ ಮಾಡಿ. ಇಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ಭಾಗವೆಂದರೆ ಕಂಟೇನರ್‌ಗೆ ನಿಯೋಜಿಸಲಾದ IP ವಿಳಾಸ(ಗಳು) ಗೆ ಏನಾಗುತ್ತದೆ.

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

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

ಮತ್ತು ಇನ್ನೂ ಒಂದು ದೊಡ್ಡ ನ್ಯೂನತೆಯೆಂದರೆ: ನಮ್ಮ ಹಳೆಯ ಮೂಲಸೌಕರ್ಯವು ಹೊಸದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು, ಕೆಲವು ರೀತಿಯ ಸೇವಾ ಡಿಸ್ಕವರಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸಲು ನಾವು ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನಃ ಬರೆಯಬೇಕಾಗುತ್ತದೆ. ಬಹಳಷ್ಟು ಕೆಲಸಗಳಿವೆ, ಮತ್ತು ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿ ಓಎಸ್ ಕರ್ನಲ್ ಮಟ್ಟದಲ್ಲಿ ಅಥವಾ ನೇರವಾಗಿ ಹಾರ್ಡ್‌ವೇರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಕಡಿಮೆ-ಮಟ್ಟದ ಸಾಧನಗಳಿಗೆ ಬಂದಾಗ ಅದು ಅಸಾಧ್ಯವಾಗಿದೆ. ಸ್ಥಾಪಿತ ಪರಿಹಾರ ಮಾದರಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಅನುಷ್ಠಾನ, ಉದಾಹರಣೆಗೆ ಪಕ್ಕದ ಕಾರು ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಲೋಡ್ ಎಂದರ್ಥ, ಇತರರಲ್ಲಿ - ಕಾರ್ಯಾಚರಣೆಯ ತೊಡಕು ಮತ್ತು ಹೆಚ್ಚುವರಿ ವೈಫಲ್ಯದ ಸನ್ನಿವೇಶಗಳು. ನಾವು ವಿಷಯಗಳನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸಲು ಬಯಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಸೇವೆಯ ಅನ್ವೇಷಣೆಯನ್ನು ಐಚ್ಛಿಕವಾಗಿ ಬಳಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ಒಂದು-ಕ್ಲೌಡ್‌ನಲ್ಲಿ, IP ಕಂಟೇನರ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಅಂದರೆ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯ ನಿದರ್ಶನವು ತನ್ನದೇ ಆದ IP ವಿಳಾಸವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಈ ವಿಳಾಸವು "ಸ್ಥಿರ" ಆಗಿದೆ: ಸೇವೆಯನ್ನು ಮೊದಲು ಕ್ಲೌಡ್‌ಗೆ ಕಳುಹಿಸಿದಾಗ ಅದನ್ನು ಪ್ರತಿ ನಿದರ್ಶನಕ್ಕೆ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ. ಸೇವೆಯು ತನ್ನ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ವಿಭಿನ್ನ ಸಂಖ್ಯೆಯ ನಿದರ್ಶನಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಕೊನೆಯಲ್ಲಿ ಅದು ಗರಿಷ್ಠ ನಿದರ್ಶನಗಳಿರುವಷ್ಟು IP ವಿಳಾಸಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ.

ತರುವಾಯ, ಈ ವಿಳಾಸಗಳು ಬದಲಾಗುವುದಿಲ್ಲ: ಅವುಗಳನ್ನು ಒಮ್ಮೆ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸೇವೆಯ ಜೀವನದುದ್ದಕ್ಕೂ ಅಸ್ತಿತ್ವದಲ್ಲಿರುತ್ತದೆ. IP ವಿಳಾಸಗಳು ನೆಟ್‌ವರ್ಕ್‌ನಾದ್ಯಂತ ಧಾರಕಗಳನ್ನು ಅನುಸರಿಸುತ್ತವೆ. ಕಂಟೇನರ್ ಅನ್ನು ಮತ್ತೊಂದು ಗುಲಾಮರಿಗೆ ವರ್ಗಾಯಿಸಿದರೆ, ನಂತರ ವಿಳಾಸವು ಅದನ್ನು ಅನುಸರಿಸುತ್ತದೆ.

ಹೀಗಾಗಿ, ಸೇವೆಯ ಹೆಸರಿನ ಮ್ಯಾಪಿಂಗ್ ಅದರ ಐಪಿ ವಿಳಾಸಗಳ ಪಟ್ಟಿಗೆ ಬಹಳ ವಿರಳವಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಲೇಖನದ ಆರಂಭದಲ್ಲಿ ನಾವು ಉಲ್ಲೇಖಿಸಿದ ಸೇವಾ ನಿದರ್ಶನಗಳ ಹೆಸರನ್ನು ನೀವು ಮತ್ತೊಮ್ಮೆ ನೋಡಿದರೆ (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), ಅವು DNS ನಲ್ಲಿ ಬಳಸಲಾದ FQDN ಗಳನ್ನು ಹೋಲುತ್ತವೆ ಎಂದು ನಾವು ಗಮನಿಸುತ್ತೇವೆ. ಅದು ಸರಿ, ಸೇವಾ ನಿದರ್ಶನಗಳ ಹೆಸರುಗಳನ್ನು ಅವುಗಳ IP ವಿಳಾಸಗಳಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಲು, ನಾವು DNS ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದಲ್ಲದೆ, ಈ DNS ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳ ಎಲ್ಲಾ ಕಾಯ್ದಿರಿಸಿದ IP ವಿಳಾಸಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ - ಚಾಲನೆಯಲ್ಲಿರುವ ಮತ್ತು ನಿಲ್ಲಿಸಿದ ಎರಡೂ (ಮೂರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಬಳಸಲಾಗಿದೆ ಎಂದು ಹೇಳೋಣ, ಮತ್ತು ನಾವು ಅಲ್ಲಿ ಐದು ವಿಳಾಸಗಳನ್ನು ಕಾಯ್ದಿರಿಸಿದ್ದೇವೆ - ಎಲ್ಲಾ ಐದನ್ನು ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ). ಗ್ರಾಹಕರು, ಈ ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಎಲ್ಲಾ ಐದು ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ - ಮತ್ತು ಹೀಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವುದನ್ನು ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಲಭ್ಯತೆಯನ್ನು ನಿರ್ಧರಿಸುವ ಈ ಆಯ್ಕೆಯು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ; ಇದು ಡಿಎನ್ಎಸ್ ಅಥವಾ ಸೇವಾ ಡಿಸ್ಕವರಿಯನ್ನು ಒಳಗೊಂಡಿಲ್ಲ, ಅಂದರೆ ಈ ವ್ಯವಸ್ಥೆಗಳ ಮಾಹಿತಿಯ ಪ್ರಸ್ತುತತೆ ಮತ್ತು ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವಲ್ಲಿ ಯಾವುದೇ ಕಷ್ಟಕರ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ಇದಲ್ಲದೆ, ಸಂಪೂರ್ಣ ಪೋರ್ಟಲ್‌ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಅವಲಂಬಿಸಿರುವ ನಿರ್ಣಾಯಕ ಸೇವೆಗಳಲ್ಲಿ, ನಾವು ಡಿಎನ್‌ಎಸ್ ಅನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಐಪಿ ವಿಳಾಸಗಳನ್ನು ನಮೂದಿಸಿ.

ಕಂಟೇನರ್‌ಗಳ ಹಿಂದೆ ಅಂತಹ ಐಪಿ ವರ್ಗಾವಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಕ್ಷುಲ್ಲಕವಲ್ಲ - ಮತ್ತು ಈ ಕೆಳಗಿನ ಉದಾಹರಣೆಯೊಂದಿಗೆ ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ:

ಒಂದು ಕ್ಲೌಡ್ ಮಾಸ್ಟರ್ ಮಿನಿಯನ್ M1 ಗೆ ರನ್ ಮಾಡಲು ಆಜ್ಞೆಯನ್ನು ನೀಡುತ್ತದೆ ಎಂದು ಹೇಳೋಣ 1.ok-web.group1.web.front.prod 1.1.1.1 ವಿಳಾಸದೊಂದಿಗೆ. ಗುಲಾಮರ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ BIRD, ಇದು ಈ ವಿಳಾಸವನ್ನು ವಿಶೇಷ ಸರ್ವರ್‌ಗಳಿಗೆ ಜಾಹೀರಾತು ಮಾಡುತ್ತದೆ ಮಾರ್ಗ ಪ್ರತಿಫಲಕ. ಎರಡನೆಯದು ನೆಟ್‌ವರ್ಕ್ ಹಾರ್ಡ್‌ವೇರ್‌ನೊಂದಿಗೆ BGP ಸೆಶನ್ ಅನ್ನು ಹೊಂದಿದೆ, ಅದರಲ್ಲಿ M1.1.1.1 ನಲ್ಲಿ ವಿಳಾಸ 1 ರ ಮಾರ್ಗವನ್ನು ಅನುವಾದಿಸಲಾಗುತ್ತದೆ. ಲಿನಕ್ಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕಂಟೇನರ್‌ನೊಳಗೆ M1 ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರೂಟ್ ಮಾಡುತ್ತದೆ. ಮೂರು ಮಾರ್ಗ ಪ್ರತಿಫಲಕ ಸರ್ವರ್‌ಗಳಿವೆ, ಏಕೆಂದರೆ ಇದು ಒಂದು-ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯದ ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಭಾಗವಾಗಿದೆ - ಅವುಗಳಿಲ್ಲದೆ, ಒಂದು-ಕ್ಲೌಡ್‌ನಲ್ಲಿನ ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎಲ್ಲಾ ಮೂರು ವಿಫಲಗೊಳ್ಳುವ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು ಅವುಗಳನ್ನು ವಿಭಿನ್ನ ಚರಣಿಗೆಗಳಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ, ಸಾಧ್ಯವಾದರೆ ಡೇಟಾ ಕೇಂದ್ರದ ವಿವಿಧ ಕೊಠಡಿಗಳಲ್ಲಿದೆ.

ಒಂದು ಕ್ಲೌಡ್ ಮಾಸ್ಟರ್ ಮತ್ತು M1 ಮಿನಿಯನ್ ನಡುವಿನ ಸಂಪರ್ಕವು ಕಳೆದುಹೋಗಿದೆ ಎಂದು ಈಗ ಊಹಿಸೋಣ. ಒಂದು-ಕ್ಲೌಡ್ ಮಾಸ್ಟರ್ ಈಗ M1 ಸಂಪೂರ್ಣವಾಗಿ ವಿಫಲವಾಗಿದೆ ಎಂಬ ಊಹೆಯ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಅಂದರೆ, ಇದು M2 ಮಿನಿಯನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಆಜ್ಞೆಯನ್ನು ನೀಡುತ್ತದೆ web.group1.web.front.prod ಅದೇ ವಿಳಾಸದೊಂದಿಗೆ 1.1.1.1. ಈಗ ನಾವು 1.1.1.1 ಗಾಗಿ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಎರಡು ಸಂಘರ್ಷದ ಮಾರ್ಗಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ: M1 ಮತ್ತು M2 ನಲ್ಲಿ. ಅಂತಹ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಲು, ನಾವು BGP ಪ್ರಕಟಣೆಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮಲ್ಟಿ ಎಕ್ಸಿಟ್ ಡಿಸ್ಕ್ರಿಮಿನೇಟರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು ಜಾಹೀರಾತು ಮಾರ್ಗದ ತೂಕವನ್ನು ತೋರಿಸುವ ಸಂಖ್ಯೆಯಾಗಿದೆ. ಸಂಘರ್ಷದ ಮಾರ್ಗಗಳಲ್ಲಿ, ಕಡಿಮೆ MED ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಒಂದು-ಕ್ಲೌಡ್ ಮಾಸ್ಟರ್ MED ಅನ್ನು ಕಂಟೇನರ್ IP ವಿಳಾಸಗಳ ಅವಿಭಾಜ್ಯ ಅಂಗವಾಗಿ ಬೆಂಬಲಿಸುತ್ತದೆ. ಮೊದಲ ಬಾರಿಗೆ, ವಿಳಾಸವನ್ನು ಸಾಕಷ್ಟು ದೊಡ್ಡ MED = 1 ನೊಂದಿಗೆ ಬರೆಯಲಾಗಿದೆ. ಅಂತಹ ತುರ್ತು ಧಾರಕ ವರ್ಗಾವಣೆಯ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಮಾಸ್ಟರ್ MED ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು M000 000 ವಿಳಾಸವನ್ನು MED = ನೊಂದಿಗೆ ಜಾಹೀರಾತು ಮಾಡಲು ಆಜ್ಞೆಯನ್ನು ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸುತ್ತದೆ. 2. M1.1.1.1 ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ನಿದರ್ಶನವು ಈ ಸಂದರ್ಭದಲ್ಲಿ ಯಾವುದೇ ಸಂಪರ್ಕವಿಲ್ಲದೇ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಮಾಸ್ಟರ್‌ನೊಂದಿಗಿನ ಸಂಪರ್ಕವನ್ನು ಪುನಃಸ್ಥಾಪಿಸುವವರೆಗೆ ಅವನ ಮುಂದಿನ ಭವಿಷ್ಯವು ನಮಗೆ ಸ್ವಲ್ಪ ಆಸಕ್ತಿಯನ್ನುಂಟುಮಾಡುತ್ತದೆ, ನಂತರ ಅವನನ್ನು ಹಳೆಯ ಟೇಕ್‌ನಂತೆ ನಿಲ್ಲಿಸಲಾಗುತ್ತದೆ.

ಅಪಘಾತಗಳು

ಎಲ್ಲಾ ಡೇಟಾ ಸೆಂಟರ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳು ಯಾವಾಗಲೂ ಸಣ್ಣ ವೈಫಲ್ಯಗಳನ್ನು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿ ನಿರ್ವಹಿಸುತ್ತವೆ. ಕಂಟೈನರ್ ಓವರ್‌ಫ್ಲೋ ಬಹುತೇಕ ಎಲ್ಲೆಡೆ ರೂಢಿಯಾಗಿದೆ.

ಡೇಟಾ ಕೇಂದ್ರದ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಕೊಠಡಿಗಳಲ್ಲಿ ವಿದ್ಯುತ್ ವೈಫಲ್ಯದಂತಹ ತುರ್ತು ಪರಿಸ್ಥಿತಿಯನ್ನು ನಾವು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

ಡೇಟಾ ಸೆಂಟರ್ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗೆ ಅಪಘಾತದ ಅರ್ಥವೇನು? ಮೊದಲನೆಯದಾಗಿ, ಇದು ಅನೇಕ ಯಂತ್ರಗಳ ಬೃಹತ್ ಒಂದು-ಬಾರಿ ವೈಫಲ್ಯವಾಗಿದೆ, ಮತ್ತು ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಸಾಕಷ್ಟು ಕಂಟೇನರ್‌ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸುವ ಅಗತ್ಯವಿದೆ. ಆದರೆ ದುರಂತವು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಎಲ್ಲಾ ಕಾರ್ಯಗಳನ್ನು ಇತರ ಗುಲಾಮರಿಗೆ ಮರು-ಹಂಚಿಕೆ ಮಾಡಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಡೇಟಾ ಕೇಂದ್ರದ ಸಂಪನ್ಮೂಲ ಸಾಮರ್ಥ್ಯವು ಲೋಡ್‌ನ 100% ಕ್ಕಿಂತ ಕಡಿಮೆಯಾಗಿದೆ.

ಆಗಾಗ್ಗೆ ಅಪಘಾತಗಳು ನಿಯಂತ್ರಣ ಪದರದ ವೈಫಲ್ಯದಿಂದ ಕೂಡಿರುತ್ತವೆ. ಅದರ ಸಲಕರಣೆಗಳ ವೈಫಲ್ಯದಿಂದಾಗಿ ಇದು ಸಂಭವಿಸಬಹುದು, ಆದರೆ ಹೆಚ್ಚಾಗಿ ಅಪಘಾತಗಳನ್ನು ಪರೀಕ್ಷಿಸಲಾಗಿಲ್ಲ ಎಂಬ ಅಂಶದಿಂದಾಗಿ ಮತ್ತು ಹೆಚ್ಚಿದ ಹೊರೆಯಿಂದಾಗಿ ನಿಯಂತ್ರಣ ಪದರವು ಸ್ವತಃ ಬೀಳುತ್ತದೆ.

ಈ ಎಲ್ಲದರ ಬಗ್ಗೆ ನೀವು ಏನು ಮಾಡಬಹುದು?

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

ನಮಗೆ ಪರಿಚಿತವಾಗಿರುವ ಸೇವೆಗಳ ಕ್ರಮಾನುಗತವನ್ನು ಮತ್ತೊಮ್ಮೆ ನೋಡೋಣ ಮತ್ತು ನಾವು ಮೊದಲು ಯಾವ ಕಾರ್ಯಗಳನ್ನು ಚಲಾಯಿಸಲು ಬಯಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಪ್ರಯತ್ನಿಸಿ.

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

ಉತ್ಪನ್ನದಲ್ಲಿ ನಾವು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ, 0; ಬ್ಯಾಚ್ನಲ್ಲಿ - ಸ್ವಲ್ಪ ಕಡಿಮೆ, 100; ಐಡಲ್‌ನಲ್ಲಿ - ಇನ್ನೂ ಕಡಿಮೆ, 200. ಆದ್ಯತೆಗಳನ್ನು ಕ್ರಮಾನುಗತವಾಗಿ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಕ್ರಮಾನುಗತದಲ್ಲಿ ಕೆಳಗಿರುವ ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ಅನುಗುಣವಾದ ಆದ್ಯತೆಯನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಪ್ರೊಡ್‌ನ ಒಳಗಿನ ಕ್ಯಾಶ್‌ಗಳನ್ನು ಮುಂಭಾಗದ ಮೊದಲು ಪ್ರಾರಂಭಿಸಬೇಕೆಂದು ನಾವು ಬಯಸಿದರೆ, ನಂತರ ನಾವು ಕ್ಯಾಶ್ = 0 ಮತ್ತು ಫ್ರಂಟ್ ಸಬ್‌ಕ್ಯೂಗಳು = 1 ಗೆ ಆದ್ಯತೆಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಮುಖ್ಯ ಪೋರ್ಟಲ್ ಅನ್ನು ಮೊದಲು ಮುಂಭಾಗಗಳಿಂದ ಪ್ರಾರಂಭಿಸಲು ಬಯಸಿದರೆ ಮತ್ತು ಸಂಗೀತದ ಮುಂಭಾಗ ಮಾತ್ರ ನಂತರ, ನಂತರ ನಾವು ಎರಡನೆಯದಕ್ಕೆ ಕಡಿಮೆ ಆದ್ಯತೆಯನ್ನು ನಿಯೋಜಿಸಬಹುದು - 10.

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

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

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

ಸಂಪೂರ್ಣ DC ಅಪಘಾತಗಳು

ಇಡೀ ಡೇಟಾ ಸೆಂಟರ್ ಏಕೆ ವಿಫಲವಾಗಬಹುದು? ಅಂಶ. ಒಳ್ಳೆಯ ಪೋಸ್ಟ್ ಆಗಿತ್ತು ಚಂಡಮಾರುತವು ಡೇಟಾ ಕೇಂದ್ರದ ಕೆಲಸದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿತು. ಅಂಶಗಳನ್ನು ಒಮ್ಮೆ ಮ್ಯಾನಿಫೋಲ್ಡ್ನಲ್ಲಿ ದೃಗ್ವಿಜ್ಞಾನವನ್ನು ಸುಟ್ಟುಹೋದ ಮನೆಯಿಲ್ಲದ ಜನರು ಎಂದು ಪರಿಗಣಿಸಬಹುದು ಮತ್ತು ಡೇಟಾ ಸೆಂಟರ್ ಸಂಪೂರ್ಣವಾಗಿ ಇತರ ಸೈಟ್ಗಳೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಕಳೆದುಕೊಂಡಿತು. ವೈಫಲ್ಯದ ಕಾರಣವು ಮಾನವ ಅಂಶವಾಗಿರಬಹುದು: ಆಪರೇಟರ್ ಅಂತಹ ಆಜ್ಞೆಯನ್ನು ನೀಡುತ್ತಾನೆ, ಅದು ಸಂಪೂರ್ಣ ಡೇಟಾ ಸೆಂಟರ್ ಬೀಳುತ್ತದೆ. ದೊಡ್ಡ ದೋಷದಿಂದಾಗಿ ಇದು ಸಂಭವಿಸಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ, ಡೇಟಾ ಕೇಂದ್ರಗಳ ಕುಸಿತವು ಸಾಮಾನ್ಯವಲ್ಲ. ಪ್ರತಿ ಕೆಲವು ತಿಂಗಳಿಗೊಮ್ಮೆ ಇದು ನಮಗೆ ಸಂಭವಿಸುತ್ತದೆ.

ಮತ್ತು ಯಾರಾದರೂ #ಜೀವಂತವಾಗಿ ಟ್ವೀಟ್ ಮಾಡುವುದನ್ನು ತಡೆಯಲು ನಾವು ಇದನ್ನು ಮಾಡುತ್ತೇವೆ.

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

ಈ ವಿಧಾನವು ದೈಹಿಕ ವೈಫಲ್ಯದಿಂದ ರಕ್ಷಿಸುತ್ತದೆ, ಆದರೆ ಆಪರೇಟರ್ ದೋಷದಿಂದ ರಕ್ಷಿಸುತ್ತದೆ.

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

ಫಲಿತಾಂಶಗಳು

ಒಂದು ಮೋಡದ ವಿಶಿಷ್ಟ ಲಕ್ಷಣಗಳು:

• ಸೇವೆಗಳು ಮತ್ತು ಕಂಟೈನರ್‌ಗಳಿಗೆ ಶ್ರೇಣೀಕೃತ ಮತ್ತು ದೃಶ್ಯ ಹೆಸರಿಸುವ ಯೋಜನೆ, ಇದು ಕಾರ್ಯ ಯಾವುದು, ಅದು ಏನು ಸಂಬಂಧಿಸಿದೆ ಮತ್ತು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಯಾರು ಜವಾಬ್ದಾರರು ಎಂಬುದನ್ನು ತ್ವರಿತವಾಗಿ ಕಂಡುಹಿಡಿಯಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
• ನಾವು ನಮ್ಮ ಅನ್ವಯಿಸುತ್ತೇವೆ ಉತ್ಪನ್ನ ಮತ್ತು ಬ್ಯಾಚ್ ಅನ್ನು ಸಂಯೋಜಿಸುವ ತಂತ್ರಯಂತ್ರ ಹಂಚಿಕೆಯ ದಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸಲು ಗುಲಾಮರ ಮೇಲೆ ಕಾರ್ಯಗಳು. cpuset ಬದಲಿಗೆ ನಾವು CPU ಕೋಟಾಗಳು, ಷೇರುಗಳು, CPU ಶೆಡ್ಯೂಲರ್ ನೀತಿಗಳು ಮತ್ತು Linux QoS ಅನ್ನು ಬಳಸುತ್ತೇವೆ.
• ಒಂದೇ ಗಣಕದಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಕಂಟೇನರ್‌ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಆದರೆ ಅವುಗಳ ಪರಸ್ಪರ ಪ್ರಭಾವವು 20% ಒಳಗೆ ಉಳಿದಿದೆ.
• ಸೇವೆಗಳನ್ನು ಕ್ರಮಾನುಗತವಾಗಿ ಸಂಘಟಿಸುವುದು ಸ್ವಯಂಚಾಲಿತ ವಿಪತ್ತು ಮರುಪಡೆಯುವಿಕೆಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ನಿಯೋಜನೆ ಮತ್ತು ಪೂರ್ವಭಾವಿ ಆದ್ಯತೆಗಳು.

FAQ

ನಾವು ಸಿದ್ಧ ಪರಿಹಾರವನ್ನು ಏಕೆ ತೆಗೆದುಕೊಳ್ಳಲಿಲ್ಲ?

• ಗುಲಾಮರನ್ನು ಇರಿಸಿದಾಗ ವಿಭಿನ್ನ ವರ್ಗದ ಕಾರ್ಯ ಪ್ರತ್ಯೇಕತೆಗೆ ವಿಭಿನ್ನ ತರ್ಕ ಅಗತ್ಯವಿರುತ್ತದೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸರಳವಾಗಿ ಕಾಯ್ದಿರಿಸುವ ಮೂಲಕ ಉತ್ಪನ್ನ ಕಾರ್ಯಗಳನ್ನು ಇರಿಸಬಹುದಾದರೆ, ಬ್ಯಾಚ್ ಮತ್ತು ಐಡಲ್ ಕಾರ್ಯಗಳನ್ನು ಇರಿಸಬೇಕು, ಮಿನಿಯನ್ ಯಂತ್ರಗಳಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳ ನಿಜವಾದ ಬಳಕೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕು.
• ಕಾರ್ಯಗಳಿಂದ ಸೇವಿಸುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಅವಶ್ಯಕತೆ, ಉದಾಹರಣೆಗೆ:
  • ನೆಟ್ವರ್ಕ್ ಬ್ಯಾಂಡ್ವಿಡ್ತ್;
  • ವಿಧಗಳು ಮತ್ತು ಡಿಸ್ಕ್ಗಳ "ಸ್ಪಿಂಡಲ್ಗಳು".
• ತುರ್ತು ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ ಸೇವೆಗಳ ಆದ್ಯತೆಗಳನ್ನು ಸೂಚಿಸುವ ಅಗತ್ಯತೆ, ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಆಜ್ಞೆಗಳ ಹಕ್ಕುಗಳು ಮತ್ತು ಕೋಟಾಗಳು, ಇದನ್ನು ಒಂದು-ಕ್ಲೌಡ್ನಲ್ಲಿ ಕ್ರಮಾನುಗತ ಕ್ಯೂಗಳನ್ನು ಬಳಸಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ.
• ಅಪಘಾತಗಳು ಮತ್ತು ಘಟನೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಕಂಟೈನರ್‌ಗಳಿಗೆ ಮಾನವ ಹೆಸರಿಡುವ ಅಗತ್ಯತೆ
• ಸೇವೆಯ ಅನ್ವೇಷಣೆಯ ಒಂದು-ಬಾರಿ ವ್ಯಾಪಕ ಅನುಷ್ಠಾನದ ಅಸಾಧ್ಯತೆ; ಹಾರ್ಡ್‌ವೇರ್ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಕಾರ್ಯಗಳೊಂದಿಗೆ ದೀರ್ಘಕಾಲ ಸಹಬಾಳ್ವೆ ನಡೆಸುವ ಅಗತ್ಯತೆ - ಕಂಟೈನರ್‌ಗಳನ್ನು ಅನುಸರಿಸುವ “ಸ್ಥಿರ” IP ವಿಳಾಸಗಳಿಂದ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ, ದೊಡ್ಡ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ಅನನ್ಯ ಏಕೀಕರಣದ ಅಗತ್ಯತೆ.

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

ಕೊನೆಯ ಸಾಲುಗಳನ್ನು ಓದಿದವರಿಗೆ, ನಿಮ್ಮ ತಾಳ್ಮೆ ಮತ್ತು ಗಮನಕ್ಕೆ ಧನ್ಯವಾದಗಳು!

ಮೂಲ: www.habr.com