ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ ನಮ್ಮ ಜೀವನದಲ್ಲಿ ಆಳವಾಗಿ ಮತ್ತು ಆಳವಾಗಿ ಭೇದಿಸುತ್ತಿದೆ ಮತ್ತು ಒಮ್ಮೆಯಾದರೂ ಯಾವುದೇ ಕ್ಲೌಡ್ ಸೇವೆಗಳನ್ನು ಬಳಸದ ಒಬ್ಬ ವ್ಯಕ್ತಿಯೂ ಇಲ್ಲ. ಆದಾಗ್ಯೂ, ಮೋಡವು ನಿಖರವಾಗಿ ಏನು ಮತ್ತು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಕಲ್ಪನೆಯ ಮಟ್ಟದಲ್ಲಿಯೂ ಸಹ ಕೆಲವರಿಗೆ ತಿಳಿದಿದೆ. 5G ಈಗಾಗಲೇ ರಿಯಾಲಿಟಿ ಆಗುತ್ತಿದೆ ಮತ್ತು ಟೆಲಿಕಾಂ ಮೂಲಸೌಕರ್ಯವು ಧ್ರುವ ಪರಿಹಾರಗಳಿಂದ ಕ್ಲೌಡ್ ಪರಿಹಾರಗಳಿಗೆ ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ, ಅದು ಸಂಪೂರ್ಣ ಹಾರ್ಡ್‌ವೇರ್ ಪರಿಹಾರಗಳಿಂದ ವರ್ಚುವಲೈಸ್ಡ್ "ಪಿಲ್ಲರ್‌ಗಳಿಗೆ" ಚಲಿಸಿದಾಗ ಮಾಡಿದಂತೆ.
ಇಂದು ನಾವು ಕ್ಲೌಡ್ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ನ ಆಂತರಿಕ ಪ್ರಪಂಚದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ ನಾವು ನೆಟ್ವರ್ಕ್ ಭಾಗದ ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ನೋಡುತ್ತೇವೆ.
ಮೋಡ ಎಂದರೇನು? ಅದೇ ವರ್ಚುವಲೈಸೇಶನ್ - ಪ್ರೊಫೈಲ್ ವೀಕ್ಷಣೆ?
ತಾರ್ಕಿಕ ಪ್ರಶ್ನೆಗಿಂತ ಹೆಚ್ಚು. ಇಲ್ಲ - ಇದು ವರ್ಚುವಲೈಸೇಶನ್ ಅಲ್ಲ, ಆದರೂ ಅದು ಇಲ್ಲದೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಎರಡು ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ನೋಡೋಣ:
ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ (ಇನ್ನು ಮುಂದೆ ಕ್ಲೌಡ್ ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ) ವಿತರಿಸಿದ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಬಳಕೆದಾರ ಸ್ನೇಹಿ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುವ ಮಾದರಿಯಾಗಿದೆ, ಅದನ್ನು ಸೇವೆ ಒದಗಿಸುವವರಿಗೆ ಕಡಿಮೆ ಸಂಭವನೀಯ ಸುಪ್ತತೆ ಮತ್ತು ಕನಿಷ್ಠ ವೆಚ್ಚದೊಂದಿಗೆ ಬೇಡಿಕೆಯ ಮೇಲೆ ನಿಯೋಜಿಸಬೇಕು ಮತ್ತು ಪ್ರಾರಂಭಿಸಬೇಕು.
ವರ್ಚುವಲೈಸೇಶನ್ - ಇದು ಒಂದು ಭೌತಿಕ ಘಟಕವನ್ನು (ಉದಾಹರಣೆಗೆ, ಸರ್ವರ್) ಹಲವಾರು ವರ್ಚುವಲ್ ಆಗಿ ವಿಭಜಿಸುವ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ, ಇದರಿಂದಾಗಿ ಸಂಪನ್ಮೂಲಗಳ ಬಳಕೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ನೀವು 3 ಸರ್ವರ್‌ಗಳನ್ನು 25-30 ಪ್ರತಿಶತದಷ್ಟು ಲೋಡ್ ಮಾಡಿದ್ದೀರಿ, ವರ್ಚುವಲೈಸೇಶನ್ ನಂತರ ನೀವು 1 ಸರ್ವರ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುತ್ತೀರಿ 80-90 ಪ್ರತಿಶತ). ನೈಸರ್ಗಿಕವಾಗಿ, ವರ್ಚುವಲೈಸೇಶನ್ ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ತಿನ್ನುತ್ತದೆ - ನೀವು ಹೈಪರ್ವೈಸರ್ಗೆ ಆಹಾರವನ್ನು ನೀಡಬೇಕಾಗಿದೆ, ಆದಾಗ್ಯೂ, ಅಭ್ಯಾಸವು ತೋರಿಸಿದಂತೆ, ಆಟವು ಮೇಣದಬತ್ತಿಗೆ ಯೋಗ್ಯವಾಗಿದೆ. ವರ್ಚುವಲೈಸೇಶನ್‌ನ ಆದರ್ಶ ಉದಾಹರಣೆಯೆಂದರೆ VMWare, ಇದು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧಪಡಿಸುತ್ತದೆ, ಅಥವಾ ಉದಾಹರಣೆಗೆ KVM, ನಾನು ಆದ್ಯತೆ ನೀಡುತ್ತೇನೆ, ಆದರೆ ಇದು ರುಚಿಯ ವಿಷಯವಾಗಿದೆ.
ನಾವು ಅದನ್ನು ಅರಿತುಕೊಳ್ಳದೆಯೇ ವರ್ಚುವಲೈಸೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಕಬ್ಬಿಣದ ಮಾರ್ಗನಿರ್ದೇಶಕಗಳು ಈಗಾಗಲೇ ವರ್ಚುವಲೈಸೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತವೆ - ಉದಾಹರಣೆಗೆ, ಜುನೋಸ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯಲ್ಲಿ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ನೈಜ-ಸಮಯದ ಲಿನಕ್ಸ್ ವಿತರಣೆಯ ಮೇಲೆ ವರ್ಚುವಲ್ ಯಂತ್ರವಾಗಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ (ವಿಂಡ್ ರಿವರ್ 9). ಆದರೆ ವರ್ಚುವಲೈಸೇಶನ್ ಮೋಡವಲ್ಲ, ಆದರೆ ವರ್ಚುವಲೈಸೇಶನ್ ಇಲ್ಲದೆ ಮೋಡವು ಅಸ್ತಿತ್ವದಲ್ಲಿರಲು ಸಾಧ್ಯವಿಲ್ಲ.
ವರ್ಚುವಲೈಸೇಶನ್ ಕ್ಲೌಡ್ ಅನ್ನು ನಿರ್ಮಿಸಿದ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್ಸ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.
ಒಂದು L2 ಡೊಮೇನ್‌ನಲ್ಲಿ ಹಲವಾರು ಹೈಪರ್‌ವೈಸರ್‌ಗಳನ್ನು ಸರಳವಾಗಿ ಸಂಗ್ರಹಿಸುವ ಮೂಲಕ ಕ್ಲೌಡ್ ಅನ್ನು ರಚಿಸುವುದು, ಕೆಲವು ರೀತಿಯ ಅನ್ಸಿಬಲ್ ಮೂಲಕ ಸ್ವಯಂಚಾಲಿತವಾಗಿ vlans ಅನ್ನು ನೋಂದಾಯಿಸಲು ಒಂದೆರಡು yaml ಪ್ಲೇಬುಕ್‌ಗಳನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ರಚಿಸಲು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸಿಸ್ಟಮ್‌ನಂತಹದನ್ನು ಜ್ಯಾಮ್ ಮಾಡುವುದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಇದು ಹೆಚ್ಚು ನಿಖರವಾಗಿರುತ್ತದೆ, ಆದರೆ ಪರಿಣಾಮವಾಗಿ ಫ್ರಾಂಕೆನ್‌ಸ್ಟೈನ್ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಮೋಡವಲ್ಲ, ಆದರೂ ಇದು ಇತರರಿಗೆ ಅಂತಿಮ ಕನಸಾಗಿರಬಹುದು. ಇದಲ್ಲದೆ, ನೀವು ಅದೇ ಓಪನ್‌ಸ್ಟಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಅದು ಮೂಲಭೂತವಾಗಿ ಇನ್ನೂ ಫ್ರಾಂಕೆನ್‌ಸ್ಟೈನ್ ಆಗಿದೆ, ಆದರೆ ಓಹ್, ಈಗ ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡಬೇಡಿ.
ಆದರೆ ಮೇಲೆ ಪ್ರಸ್ತುತಪಡಿಸಿದ ವ್ಯಾಖ್ಯಾನದಿಂದ ವಾಸ್ತವವಾಗಿ ಮೋಡ ಎಂದು ಕರೆಯುವುದು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ.
ಆದ್ದರಿಂದ, NIST (ನ್ಯಾಷನಲ್ ಇನ್‌ಸ್ಟಿಟ್ಯೂಟ್ ಆಫ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ಸ್ ಅಂಡ್ ಟೆಕ್ನಾಲಜಿ) ಯಿಂದ ಒಂದು ಡಾಕ್ಯುಮೆಂಟ್ ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯ ಹೊಂದಿರಬೇಕಾದ 5 ಮುಖ್ಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ:
ವಿನಂತಿಯ ಮೇರೆಗೆ ಸೇವೆಯನ್ನು ಒದಗಿಸುವುದು. ಬಳಕೆದಾರರಿಗೆ ಅವರಿಗೆ ನಿಯೋಜಿಸಲಾದ ಕಂಪ್ಯೂಟರ್ ಸಂಪನ್ಮೂಲಗಳಿಗೆ (ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ವರ್ಚುವಲ್ ಡಿಸ್ಕ್‌ಗಳು, ಮೆಮೊರಿ, ಪ್ರೊಸೆಸರ್ ಕೋರ್ಗಳು ಇತ್ಯಾದಿ) ಉಚಿತ ಪ್ರವೇಶವನ್ನು ನೀಡಬೇಕು ಮತ್ತು ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಒದಗಿಸಬೇಕು - ಅಂದರೆ, ಸೇವಾ ಪೂರೈಕೆದಾರರ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ.
ಸೇವೆಯ ವ್ಯಾಪಕ ಲಭ್ಯತೆ. ಪ್ರಮಾಣಿತ PC ಗಳು ಮತ್ತು ತೆಳುವಾದ ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಮೊಬೈಲ್ ಸಾಧನಗಳ ಬಳಕೆಯನ್ನು ಅನುಮತಿಸಲು ಪ್ರಮಾಣಿತ ಕಾರ್ಯವಿಧಾನಗಳಿಂದ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಬೇಕು.
ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪೂಲ್‌ಗಳಾಗಿ ಸಂಯೋಜಿಸುವುದು. ಸಂಪನ್ಮೂಲ ಪೂಲ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒದಗಿಸಲು ಸಮರ್ಥವಾಗಿರಬೇಕು, ಗ್ರಾಹಕರು ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತಾರೆ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಪರಸ್ಪರ ಪ್ರಭಾವ ಮತ್ತು ಸ್ಪರ್ಧೆಯಿಂದ ಮುಕ್ತರಾಗಿದ್ದಾರೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಪೂಲ್‌ಗಳಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಸಹ ಸೇರಿಸಲಾಗಿದೆ, ಇದು ಅತಿಕ್ರಮಿಸುವ ವಿಳಾಸವನ್ನು ಬಳಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಪೂಲ್‌ಗಳು ಬೇಡಿಕೆಯ ಮೇಲೆ ಅಳೆಯಲು ಶಕ್ತವಾಗಿರಬೇಕು. ಪೂಲ್‌ಗಳ ಬಳಕೆಯು ಅಗತ್ಯ ಮಟ್ಟದ ಸಂಪನ್ಮೂಲ ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಭೌತಿಕ ಮತ್ತು ವರ್ಚುವಲ್ ಸಂಪನ್ಮೂಲಗಳ ಅಮೂರ್ತತೆಯನ್ನು ಒದಗಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ - ಸೇವೆಯನ್ನು ಸ್ವೀಕರಿಸುವವರಿಗೆ ಅವರು ವಿನಂತಿಸಿದ ಸಂಪನ್ಮೂಲಗಳ ಗುಂಪನ್ನು ಸರಳವಾಗಿ ಒದಗಿಸಲಾಗುತ್ತದೆ (ಈ ಸಂಪನ್ಮೂಲಗಳು ಭೌತಿಕವಾಗಿ ಎಲ್ಲಿ ನೆಲೆಗೊಂಡಿವೆ, ಎಷ್ಟು ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಸ್ವಿಚ್‌ಗಳು - ಇದು ಕ್ಲೈಂಟ್‌ಗೆ ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ). ಆದಾಗ್ಯೂ, ಒದಗಿಸುವವರು ಈ ಸಂಪನ್ಮೂಲಗಳ ಪಾರದರ್ಶಕ ಮೀಸಲಾತಿಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು.
ವಿವಿಧ ಪರಿಸ್ಥಿತಿಗಳಿಗೆ ತ್ವರಿತ ಹೊಂದಾಣಿಕೆ. ಸೇವೆಗಳು ಹೊಂದಿಕೊಳ್ಳುವಂತಿರಬೇಕು - ಸಂಪನ್ಮೂಲಗಳ ತ್ವರಿತ ಪೂರೈಕೆ, ಅವುಗಳ ಪುನರ್ವಿತರಣೆ, ಕ್ಲೈಂಟ್ನ ಕೋರಿಕೆಯ ಮೇರೆಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇರಿಸುವುದು ಅಥವಾ ಕಡಿಮೆ ಮಾಡುವುದು ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಕಡೆಯಿಂದ ಕ್ಲೌಡ್ ಸಂಪನ್ಮೂಲಗಳು ಅಂತ್ಯವಿಲ್ಲ ಎಂಬ ಭಾವನೆ ಇರಬೇಕು. ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾಗುವಂತೆ, ಉದಾಹರಣೆಗೆ, ಆಪಲ್ ಐಕ್ಲೌಡ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಡಿಸ್ಕ್ ಜಾಗದ ಭಾಗವು ಕಣ್ಮರೆಯಾಗಿದೆ ಎಂಬ ಎಚ್ಚರಿಕೆಯನ್ನು ನೀವು ನೋಡುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಸರ್ವರ್‌ನಲ್ಲಿನ ಹಾರ್ಡ್ ಡ್ರೈವ್ ಮುರಿದುಹೋಗಿದೆ ಮತ್ತು ಡ್ರೈವ್‌ಗಳು ಒಡೆಯುತ್ತವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಿಮ್ಮ ಕಡೆಯಿಂದ, ಈ ಸೇವೆಯ ಸಾಧ್ಯತೆಗಳು ಬಹುತೇಕ ಅಪರಿಮಿತವಾಗಿವೆ - ನಿಮಗೆ 2 ಟಿಬಿ ಅಗತ್ಯವಿದೆ - ತೊಂದರೆ ಇಲ್ಲ, ನೀವು ಪಾವತಿಸಿದ್ದೀರಿ ಮತ್ತು ಸ್ವೀಕರಿಸಿದ್ದೀರಿ. ಇದೇ ರೀತಿಯ ಉದಾಹರಣೆಯನ್ನು Google.Drive ಅಥವಾ Yandex.Disk ನೊಂದಿಗೆ ನೀಡಬಹುದು.
ಒದಗಿಸಿದ ಸೇವೆಯನ್ನು ಅಳೆಯುವ ಸಾಧ್ಯತೆ. ಕ್ಲೌಡ್ ಸಿಸ್ಟಮ್‌ಗಳು ಸೇವಿಸಿದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಯಂತ್ರಿಸಬೇಕು ಮತ್ತು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಬೇಕು ಮತ್ತು ಈ ಕಾರ್ಯವಿಧಾನಗಳು ಬಳಕೆದಾರ ಮತ್ತು ಸೇವಾ ಪೂರೈಕೆದಾರರಿಗೆ ಪಾರದರ್ಶಕವಾಗಿರಬೇಕು. ಅಂದರೆ, ನೀವು ಮತ್ತು ನಿಮ್ಮ ಗ್ರಾಹಕರು ಎಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತಿರುವಿರಿ ಎಂಬುದನ್ನು ನೀವು ಯಾವಾಗಲೂ ಪರಿಶೀಲಿಸಬಹುದು.
ಈ ಅವಶ್ಯಕತೆಗಳು ಹೆಚ್ಚಾಗಿ ಸಾರ್ವಜನಿಕ ಮೋಡದ ಅವಶ್ಯಕತೆಗಳಾಗಿವೆ ಎಂಬ ಅಂಶವನ್ನು ಪರಿಗಣಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ, ಆದ್ದರಿಂದ ಖಾಸಗಿ ಮೋಡಕ್ಕಾಗಿ (ಅಂದರೆ, ಕಂಪನಿಯ ಆಂತರಿಕ ಅಗತ್ಯಗಳಿಗಾಗಿ ಪ್ರಾರಂಭಿಸಲಾದ ಮೋಡ), ಈ ಅವಶ್ಯಕತೆಗಳನ್ನು ಸ್ವಲ್ಪ ಸರಿಹೊಂದಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಅವರು ಇನ್ನೂ ಮಾಡಬೇಕಾಗಿದೆ, ಇಲ್ಲದಿದ್ದರೆ ನಾವು ಕ್ಲೌಡ್ ಕಂಪ್ಯೂಟಿಂಗ್ನ ಎಲ್ಲಾ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯುವುದಿಲ್ಲ.
ನಮಗೆ ಮೋಡ ಏಕೆ ಬೇಕು?
ಆದಾಗ್ಯೂ, ಯಾವುದೇ ಹೊಸ ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ತಂತ್ರಜ್ಞಾನ, ಯಾವುದೇ ಹೊಸ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಏನನ್ನಾದರೂ ರಚಿಸಲಾಗಿದೆ (ಅಲ್ಲದೆ, RIP-ng ಹೊರತುಪಡಿಸಿ, ಸಹಜವಾಗಿ). ಪ್ರೋಟೋಕಾಲ್‌ಗಾಗಿ ಯಾರಿಗೂ ಪ್ರೋಟೋಕಾಲ್ ಅಗತ್ಯವಿಲ್ಲ (ಅಲ್ಲದೆ, RIP-ng ಹೊರತುಪಡಿಸಿ, ಸಹಜವಾಗಿ). ಬಳಕೆದಾರ/ಕ್ಲೈಂಟ್‌ಗೆ ಕೆಲವು ರೀತಿಯ ಸೇವೆಯನ್ನು ಒದಗಿಸಲು ಕ್ಲೌಡ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ ಎಂಬುದು ತಾರ್ಕಿಕವಾಗಿದೆ. ನಾವೆಲ್ಲರೂ ಕನಿಷ್ಟ ಒಂದೆರಡು ಕ್ಲೌಡ್ ಸೇವೆಗಳೊಂದಿಗೆ ಪರಿಚಿತರಾಗಿದ್ದೇವೆ, ಉದಾಹರಣೆಗೆ ಡ್ರಾಪ್‌ಬಾಕ್ಸ್ ಅಥವಾ Google.Docs, ಮತ್ತು ಹೆಚ್ಚಿನ ಜನರು ಅವುಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಬಳಸುತ್ತಾರೆ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ - ಉದಾಹರಣೆಗೆ, ಈ ಲೇಖನವನ್ನು Google.Docs ಕ್ಲೌಡ್ ಸೇವೆಯನ್ನು ಬಳಸಿ ಬರೆಯಲಾಗಿದೆ. ಆದರೆ ನಮಗೆ ತಿಳಿದಿರುವ ಕ್ಲೌಡ್ ಸೇವೆಗಳು ಕ್ಲೌಡ್‌ನ ಸಾಮರ್ಥ್ಯಗಳ ಒಂದು ಭಾಗವಾಗಿದೆ-ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಅವು ಕೇವಲ ಸಾಸ್-ಮಾದರಿಯ ಸೇವೆಯಾಗಿದೆ. ನಾವು ಕ್ಲೌಡ್ ಸೇವೆಯನ್ನು ಮೂರು ರೀತಿಯಲ್ಲಿ ಒದಗಿಸಬಹುದು: SaaS, PaaS ಅಥವಾ IaaS ರೂಪದಲ್ಲಿ. ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಸೇವೆಯು ನಿಮ್ಮ ಆಸೆಗಳನ್ನು ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.
ಪ್ರತಿಯೊಂದನ್ನು ಕ್ರಮವಾಗಿ ನೋಡೋಣ:
ಸಾಫ್ಟ್‌ವೇರ್ ಸೇವೆಯಾಗಿ (ಸಾಸ್) ಕ್ಲೈಂಟ್‌ಗೆ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಸೇವೆಯನ್ನು ಒದಗಿಸುವ ಮಾದರಿಯಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, Yandex.Mail ಅಥವಾ Gmail ನಂತಹ ಇಮೇಲ್ ಸೇವೆ. ಈ ಸೇವೆಯ ವಿತರಣಾ ಮಾದರಿಯಲ್ಲಿ, ನೀವು ಕ್ಲೈಂಟ್ ಆಗಿ, ಸೇವೆಗಳನ್ನು ಬಳಸುವುದನ್ನು ಹೊರತುಪಡಿಸಿ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ - ಅಂದರೆ, ಸೇವೆಯನ್ನು ಹೊಂದಿಸುವ ಬಗ್ಗೆ, ಅದರ ದೋಷ ಸಹಿಷ್ಣುತೆ ಅಥವಾ ಪುನರಾವರ್ತನೆ ಬಗ್ಗೆ ನೀವು ಯೋಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ನಿಮ್ಮ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ರಾಜಿ ಮಾಡಿಕೊಳ್ಳುವುದು ಅಲ್ಲ; ಈ ಸೇವೆಯ ಪೂರೈಕೆದಾರರು ನಿಮಗಾಗಿ ಉಳಿದವನ್ನು ಮಾಡುತ್ತಾರೆ. ಸೇವಾ ಪೂರೈಕೆದಾರರ ದೃಷ್ಟಿಕೋನದಿಂದ, ಸರ್ವರ್ ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಹೋಸ್ಟ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಂದ ಡೇಟಾಬೇಸ್ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳವರೆಗೆ - ಸಂಪೂರ್ಣ ಸೇವೆಗೆ ಅವನು ಸಂಪೂರ್ಣ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ.
ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸೇವೆಯಂತೆ (ಪಾಸ್‌) - ಈ ಮಾದರಿಯನ್ನು ಬಳಸುವಾಗ, ಸೇವಾ ಪೂರೈಕೆದಾರರು ಕ್ಲೈಂಟ್‌ಗೆ ಸೇವೆಗಾಗಿ ವರ್ಕ್‌ಪೀಸ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ನಾವು ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ. ಸೇವಾ ಪೂರೈಕೆದಾರರು ಕ್ಲೈಂಟ್‌ಗೆ ವರ್ಚುವಲ್ ಸರ್ವರ್ ಅನ್ನು ಒದಗಿಸಿದ್ದಾರೆ (ವಾಸ್ತವವಾಗಿ, RAM/CPU/ಶೇಖರಣೆ/ನೆಟ್‌ಗಳು, ಇತ್ಯಾದಿ ಸಂಪನ್ಮೂಲಗಳ ಒಂದು ಸೆಟ್), ಮತ್ತು ಈ ಸರ್ವರ್‌ನಲ್ಲಿ OS ಮತ್ತು ಅಗತ್ಯ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸಹ ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಆದಾಗ್ಯೂ, ಸಂರಚನೆ ಈ ಎಲ್ಲಾ ವಿಷಯವನ್ನು ಕ್ಲೈಂಟ್ ಸ್ವತಃ ಮಾಡುತ್ತಾನೆ ಮತ್ತು ಸೇವೆಯ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ಕ್ಲೈಂಟ್ ಉತ್ತರಿಸುತ್ತಾನೆ. ಸೇವಾ ಪೂರೈಕೆದಾರರು, ಹಿಂದಿನ ಪ್ರಕರಣದಂತೆ, ಭೌತಿಕ ಉಪಕರಣಗಳು, ಹೈಪರ್‌ವೈಸರ್‌ಗಳು, ವರ್ಚುವಲ್ ಯಂತ್ರ, ಅದರ ನೆಟ್ವರ್ಕ್ ಲಭ್ಯತೆ ಇತ್ಯಾದಿಗಳ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ, ಆದರೆ ಸೇವೆಯು ಇನ್ನು ಮುಂದೆ ಅದರ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶದಲ್ಲಿ ಇರುವುದಿಲ್ಲ.
ಸೇವೆಯಾಗಿ ಮೂಲಸೌಕರ್ಯ (ಐಎಎಸ್) - ಈ ವಿಧಾನವು ಈಗಾಗಲೇ ಹೆಚ್ಚು ಆಸಕ್ತಿಕರವಾಗಿದೆ, ವಾಸ್ತವವಾಗಿ, ಸೇವಾ ಪೂರೈಕೆದಾರರು ಕ್ಲೈಂಟ್‌ಗೆ ಸಂಪೂರ್ಣ ವರ್ಚುವಲೈಸ್ಡ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ಒದಗಿಸುತ್ತಾರೆ - ಅಂದರೆ, CPU ಕೋರ್ಗಳು, RAM, ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ಇತ್ಯಾದಿ ಸಂಪನ್ಮೂಲಗಳ ಕೆಲವು ಸೆಟ್ (ಪೂಲ್) ಉಳಿದಿದೆ. ಕ್ಲೈಂಟ್ - ಕ್ಲೈಂಟ್ ನಿಗದಿಪಡಿಸಿದ ಪೂಲ್ (ಕೋಟಾ) ಒಳಗೆ ಈ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಏನು ಮಾಡಲು ಬಯಸುತ್ತಾನೆ - ಇದು ಪೂರೈಕೆದಾರರಿಗೆ ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಲ್ಲ. ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಆದ vEPC ಅನ್ನು ರಚಿಸಲು ಅಥವಾ ಮಿನಿ ಆಪರೇಟರ್ ಅನ್ನು ರಚಿಸಲು ಮತ್ತು ಸಂವಹನ ಸೇವೆಗಳನ್ನು ಒದಗಿಸಲು ಬಯಸುತ್ತಾರೆಯೇ - ಪ್ರಶ್ನೆಯಿಲ್ಲ - ಅದನ್ನು ಮಾಡಿ. ಅಂತಹ ಸನ್ನಿವೇಶದಲ್ಲಿ, ಸೇವಾ ಪೂರೈಕೆದಾರರು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒದಗಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿರುತ್ತಾರೆ, ಅವುಗಳ ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಲಭ್ಯತೆ, ಹಾಗೆಯೇ ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗೆ ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೆಚ್ಚಿಸುವ ಅಥವಾ ಕಡಿಮೆ ಮಾಡುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಅವುಗಳನ್ನು ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುವ OS ಕ್ಲೈಂಟ್ನ ಕೋರಿಕೆಯ ಮೇರೆಗೆ. ಕ್ಲೈಂಟ್ ಎಲ್ಲಾ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಮತ್ತು ಇತರ ಟಿನ್ಸೆಲ್ ಅನ್ನು ಸ್ವಯಂ-ಸೇವಾ ಪೋರ್ಟಲ್ ಮತ್ತು ಕನ್ಸೋಲ್ ಮೂಲಕ ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ, ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಹೊಂದಿಸುವುದು ಸೇರಿದಂತೆ (ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಹೊರತುಪಡಿಸಿ).
OpenStack ಎಂದರೇನು?
ಎಲ್ಲಾ ಮೂರು ಆಯ್ಕೆಗಳಲ್ಲಿ, ಸೇವಾ ಪೂರೈಕೆದಾರರಿಗೆ ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯ ರಚನೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ OS ಅಗತ್ಯವಿದೆ. ವಾಸ್ತವವಾಗಿ, SaaS ನೊಂದಿಗೆ, ತಂತ್ರಜ್ಞಾನಗಳ ಸಂಪೂರ್ಣ ಸ್ಟಾಕ್‌ಗೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ವಿಭಾಗಗಳು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ - ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಒಂದು ವಿಭಾಗವಿದೆ - ಅಂದರೆ, ಇದು ಮತ್ತೊಂದು ವಿಭಾಗಕ್ಕೆ IaaS ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಈ ವಿಭಾಗವು ಕ್ಲೈಂಟ್‌ಗೆ SaaS ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. OpenStack ಕ್ಲೌಡ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಇದು ಸ್ವಿಚ್‌ಗಳು, ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಒಂದೇ ಸಂಪನ್ಮೂಲ ಪೂಲ್‌ಗೆ ಸಂಗ್ರಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಈ ಸಾಮಾನ್ಯ ಪೂಲ್ ಅನ್ನು ಉಪಪೂಲ್‌ಗಳಾಗಿ (ಬಾಡಿಗೆದಾರರು) ವಿಭಜಿಸುತ್ತದೆ ಮತ್ತು ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಗ್ರಾಹಕರಿಗೆ ಒದಗಿಸುತ್ತದೆ.
ಓಪನ್ ಸ್ಟ್ಯಾಕ್ ಕ್ಲೌಡ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಆಗಿದ್ದು, ಇದು ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳು, ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಸಂಪನ್ಮೂಲಗಳ ದೊಡ್ಡ ಪೂಲ್‌ಗಳನ್ನು ನಿಯಂತ್ರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಪ್ರಮಾಣಿತ ದೃಢೀಕರಣ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು API ಮೂಲಕ ಒದಗಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.
ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಇದು ಕ್ಲೌಡ್ ಸೇವೆಗಳನ್ನು (ಸಾರ್ವಜನಿಕ ಮತ್ತು ಖಾಸಗಿ ಎರಡೂ) ರಚಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಉಚಿತ ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳ ಗುಂಪಾಗಿದೆ - ಅಂದರೆ, ಸರ್ವರ್ ಮತ್ತು ಸ್ವಿಚಿಂಗ್ ಉಪಕರಣಗಳನ್ನು ಒಂದೇ ಸಂಪನ್ಮೂಲಗಳ ಪೂಲ್‌ಗೆ ಸಂಯೋಜಿಸಲು, ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಸಾಧನಗಳ ಒಂದು ಸೆಟ್ ಈ ಸಂಪನ್ಮೂಲಗಳು, ಅಗತ್ಯ ಮಟ್ಟದ ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಈ ವಸ್ತುವನ್ನು ಬರೆಯುವ ಸಮಯದಲ್ಲಿ, OpenStack ರಚನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಚಿತ್ರ ತೆಗೆಯಲಾಗಿದೆ
OpenStack ನಲ್ಲಿ ಸೇರಿಸಲಾದ ಪ್ರತಿಯೊಂದು ಘಟಕಗಳು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ. ಈ ವಿತರಣಾ ವಾಸ್ತುಶಿಲ್ಪವು ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಕ್ರಿಯಾತ್ಮಕ ಘಟಕಗಳ ಸೆಟ್ ಅನ್ನು ಪರಿಹಾರದಲ್ಲಿ ಸೇರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಕೆಲವು ಘಟಕಗಳು ಮೂಲ ಘಟಕಗಳಾಗಿವೆ ಮತ್ತು ಅವುಗಳ ತೆಗೆದುಹಾಕುವಿಕೆಯು ಒಟ್ಟಾರೆಯಾಗಿ ಪರಿಹಾರದ ಸಂಪೂರ್ಣ ಅಥವಾ ಭಾಗಶಃ ಅಸಮರ್ಥತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಈ ಘಟಕಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ವರ್ಗೀಕರಿಸಲಾಗಿದೆ:
- ಡ್ಯಾಶ್ಬೋರ್ಡ್ - OpenStack ಸೇವೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ವೆಬ್ ಆಧಾರಿತ GUI
- ಕೀಸ್ಟೋನ್ ಇತರ ಸೇವೆಗಳಿಗೆ ದೃಢೀಕರಣ ಮತ್ತು ದೃಢೀಕರಣ ಕಾರ್ಯವನ್ನು ಒದಗಿಸುವ ಕೇಂದ್ರೀಕೃತ ಗುರುತಿನ ಸೇವೆಯಾಗಿದೆ, ಹಾಗೆಯೇ ಬಳಕೆದಾರರ ರುಜುವಾತುಗಳು ಮತ್ತು ಅವರ ಪಾತ್ರಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
- ನ್ಯೂಟ್ರಾನ್ - ವಿವಿಧ OpenStack ಸೇವೆಗಳ ಇಂಟರ್ಫೇಸ್ಗಳ ನಡುವೆ ಸಂಪರ್ಕವನ್ನು ಒದಗಿಸುವ ನೆಟ್ವರ್ಕ್ ಸೇವೆ (VM ಗಳ ನಡುವಿನ ಸಂಪರ್ಕ ಮತ್ತು ಹೊರಗಿನ ಪ್ರಪಂಚಕ್ಕೆ ಅವುಗಳ ಪ್ರವೇಶ ಸೇರಿದಂತೆ)
- ಸಿಂಡರ್ — ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಗೆ ಬ್ಲಾಕ್ ಸಂಗ್ರಹಣೆಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತದೆ
- ನೋವಾ - ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ಜೀವನ ಚಕ್ರ ನಿರ್ವಹಣೆ
- ನೋಟ - ವರ್ಚುವಲ್ ಯಂತ್ರ ಚಿತ್ರಗಳು ಮತ್ತು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳ ಭಂಡಾರ
- ಸ್ವಿಫ್ಟ್ - ಶೇಖರಣಾ ವಸ್ತುವಿಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತದೆ
- ಸೀಲೋಮೀಟರ್ - ಟೆಲಿಮೆಟ್ರಿಯನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ಲಭ್ಯವಿರುವ ಮತ್ತು ಸೇವಿಸಿದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅಳೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುವ ಸೇವೆ
- ಹೀಟ್ — ಸ್ವಯಂಚಾಲಿತ ರಚನೆ ಮತ್ತು ಸಂಪನ್ಮೂಲಗಳ ಪೂರೈಕೆಗಾಗಿ ಟೆಂಪ್ಲೇಟ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್
ಎಲ್ಲಾ ಯೋಜನೆಗಳ ಸಂಪೂರ್ಣ ಪಟ್ಟಿ ಮತ್ತು ಅವುಗಳ ಉದ್ದೇಶವನ್ನು ವೀಕ್ಷಿಸಬಹುದು .
ಪ್ರತಿಯೊಂದು OpenStack ಘಟಕವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುವ ಸೇವೆಯಾಗಿದೆ ಮತ್ತು ಆ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತು ಏಕೀಕೃತ ಮೂಲಸೌಕರ್ಯವನ್ನು ರಚಿಸಲು ಇತರ ಕ್ಲೌಡ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಸೇವೆಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನೋವಾ ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಪ್ರವೇಶಕ್ಕಾಗಿ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣೆ ಮತ್ತು API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಗ್ಲಾನ್ಸ್ ಇಮೇಜ್ ನಿರ್ವಹಣೆ ಮತ್ತು ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸಲು API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, Cinder ಬ್ಲಾಕ್ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಅದನ್ನು ನಿರ್ವಹಿಸಲು API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇತ್ಯಾದಿ. ಎಲ್ಲಾ ಕಾರ್ಯಗಳು ಬಹಳ ನಿಕಟ ರೀತಿಯಲ್ಲಿ ಪರಸ್ಪರ ಸಂಬಂಧ ಹೊಂದಿವೆ.
ಆದಾಗ್ಯೂ, ನೀವು ಅದನ್ನು ನೋಡಿದರೆ, OpenStack ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಸೇವೆಗಳು ಅಂತಿಮವಾಗಿ ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಪರ್ಕ ಹೊಂದಿದ ಕೆಲವು ರೀತಿಯ ವರ್ಚುವಲ್ ಯಂತ್ರ (ಅಥವಾ ಕಂಟೇನರ್) ಆಗಿರುತ್ತವೆ. ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ - ನಮಗೆ ಅನೇಕ ಅಂಶಗಳು ಏಕೆ ಬೇಕು?
ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ರಚಿಸಲು ಮತ್ತು ಅದನ್ನು ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಪರ್ಕಿಸಲು ಮತ್ತು ಓಪನ್‌ಸ್ಟಾಕ್‌ನಲ್ಲಿ ನಿರಂತರ ಸಂಗ್ರಹಣೆಗಾಗಿ ಅಲ್ಗಾರಿದಮ್ ಮೂಲಕ ಹೋಗೋಣ.
- ನೀವು ಯಂತ್ರವನ್ನು ರಚಿಸಲು ವಿನಂತಿಯನ್ನು ರಚಿಸಿದಾಗ, ಅದು ಹಾರಿಜಾನ್ (ಡ್ಯಾಶ್ಬೋರ್ಡ್) ಮೂಲಕ ವಿನಂತಿಯಾಗಿರಬಹುದು ಅಥವಾ CLI ಮೂಲಕ ವಿನಂತಿಯಾಗಿರಬಹುದು, ಕೀಸ್ಟೋನ್‌ನಲ್ಲಿ ನಿಮ್ಮ ವಿನಂತಿಯ ದೃಢೀಕರಣವು ಮೊದಲು ಸಂಭವಿಸುತ್ತದೆ - ನೀವು ಯಂತ್ರವನ್ನು ರಚಿಸಬಹುದೇ, ಅದು ಹೊಂದಿದೆಯೇ ಈ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಬಳಸುವ ಹಕ್ಕು, ನಿಮ್ಮ ಡ್ರಾಫ್ಟ್ ಕೋಟಾ, ಇತ್ಯಾದಿ.
- ಕೀಸ್ಟೋನ್ ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಸಂದೇಶದಲ್ಲಿ ದೃಢೀಕರಣ ಟೋಕನ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ, ಅದನ್ನು ಮುಂದೆ ಬಳಸಲಾಗುತ್ತದೆ. ಕೀಸ್ಟೋನ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ವಿನಂತಿಯನ್ನು ನೋವಾ (ನೋವಾ ಎಪಿಐ) ಕಡೆಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
- ಹಿಂದೆ ರಚಿಸಲಾದ ದೃಢೀಕರಣ ಟೋಕನ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕೀಸ್ಟೋನ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುವ ಮೂಲಕ Nova-api ನಿಮ್ಮ ವಿನಂತಿಯ ಸಿಂಧುತ್ವವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ
- ಕೀಸ್ಟೋನ್ ದೃಢೀಕರಣವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಈ ದೃಢೀಕರಣ ಟೋಕನ್ ಆಧಾರದ ಮೇಲೆ ಅನುಮತಿಗಳು ಮತ್ತು ನಿರ್ಬಂಧಗಳ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
- Nova-api nova-database ನಲ್ಲಿ ಹೊಸ VM ಗಾಗಿ ನಮೂದನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು nova-scheduler ಗೆ ಯಂತ್ರವನ್ನು ರಚಿಸಲು ವಿನಂತಿಯನ್ನು ರವಾನಿಸುತ್ತದೆ.
- ನೋವಾ-ಶೆಡ್ಯೂಲರ್ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು, ತೂಕಗಳು ಮತ್ತು ವಲಯಗಳ ಆಧಾರದ ಮೇಲೆ VM ಅನ್ನು ನಿಯೋಜಿಸಲಾಗುವ ಹೋಸ್ಟ್ (ಕಂಪ್ಯೂಟರ್ ನೋಡ್) ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಇದರ ದಾಖಲೆ ಮತ್ತು VM ID ಅನ್ನು nova-database ಗೆ ಬರೆಯಲಾಗಿದೆ.
- ಮುಂದೆ, ಒಂದು ನಿದರ್ಶನವನ್ನು ನಿಯೋಜಿಸಲು ವಿನಂತಿಯೊಂದಿಗೆ ನೋವಾ-ಶೆಡ್ಯೂಲರ್ ನೋವಾ-ಕಂಪ್ಯೂಟ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ. ನೋವಾ-ಕಂಪ್ಯೂಟ್ ನೋವಾ-ಕಂಡಕ್ಟರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ ಯಂತ್ರದ ನಿಯತಾಂಕಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು (ನೋವಾ-ಕಂಡಕ್ಟರ್ ನೋವಾ-ಡೇಟಾಬೇಸ್ ಮತ್ತು ನೋವಾ-ಕಂಪ್ಯೂಟ್ ನಡುವೆ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ನೋವಾ ಅಂಶವಾಗಿದೆ, ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಲು ನೋವಾ-ಡೇಟಾಬೇಸ್‌ಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ. ಸ್ಥಿರತೆ ಲೋಡ್ ಕಡಿತ).
- ನೋವಾ-ಕಂಡಕ್ಟರ್ ನೋವಾ-ಡೇಟಾಬೇಸ್‌ನಿಂದ ವಿನಂತಿಸಿದ ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ನೋವಾ-ಕಂಪ್ಯೂಟ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ.
- ಮುಂದೆ, ಚಿತ್ರ ಐಡಿಯನ್ನು ಪಡೆಯಲು ನೋವಾ-ಕಂಪ್ಯೂಟ್ ಗ್ಲಾನ್ಸ್ ಕರೆ ಮಾಡುತ್ತದೆ. ಗ್ಲೇಸ್ ಕೀಸ್ಟೋನ್‌ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಸಿದ ಮಾಹಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
- ನೆಟ್ವರ್ಕ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು ನೋವಾ-ಕಂಪ್ಯೂಟ್ ನ್ಯೂಟ್ರಾನ್ ಸಂಪರ್ಕಗಳು. ಗ್ಲಾನ್ಸ್‌ನಂತೆಯೇ, ನ್ಯೂಟ್ರಾನ್ ಕೀಸ್ಟೋನ್‌ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ, ಅದರ ನಂತರ ಅದು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಮೂದನ್ನು ರಚಿಸುತ್ತದೆ (ಪೋರ್ಟ್ ಐಡೆಂಟಿಫಯರ್, ಇತ್ಯಾದಿ), ಪೋರ್ಟ್ ರಚಿಸಲು ವಿನಂತಿಯನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಸಿದ ಮಾಹಿತಿಯನ್ನು ನೋವಾ-ಕಂಪ್ಯೂಟ್‌ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
- ವರ್ಚುವಲ್ ಗಣಕಕ್ಕೆ ಪರಿಮಾಣವನ್ನು ನಿಯೋಜಿಸಲು ವಿನಂತಿಯೊಂದಿಗೆ Nova-ಕಂಪ್ಯೂಟ್ ಸಂಪರ್ಕಗಳು ಸಿಂಡರ್. ಗ್ಲಾನ್ಸ್‌ನಂತೆಯೇ, ಸೈಡರ್ ಕೀಸ್ಟೋನ್‌ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ, ಪರಿಮಾಣ ರಚನೆಯ ವಿನಂತಿಯನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ವಿನಂತಿಸಿದ ಮಾಹಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
- Nova-compute ಸಂಪರ್ಕಗಳು libvirt ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ನಿಯೋಜಿಸಲು ವಿನಂತಿಯನ್ನು ಹೊಂದಿದೆ.
ವಾಸ್ತವವಾಗಿ, ಸರಳವಾದ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ರಚಿಸುವ ಸರಳವಾದ ಕಾರ್ಯಾಚರಣೆಯು ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಅಂಶಗಳ ನಡುವೆ API ಕರೆಗಳ ಸುಂಟರಗಾಳಿಯಾಗಿ ಬದಲಾಗುತ್ತದೆ. ಇದಲ್ಲದೆ, ನೀವು ನೋಡುವಂತೆ, ಹಿಂದೆ ಗೊತ್ತುಪಡಿಸಿದ ಸೇವೆಗಳು ಸಹ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ನಡುವೆ ಸಣ್ಣ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ಯಂತ್ರವನ್ನು ರಚಿಸುವುದು ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿಮಗೆ ಅನುಮತಿಸುವ ಒಂದು ಸಣ್ಣ ಭಾಗವಾಗಿದೆ - ದಟ್ಟಣೆಯನ್ನು ಸಮತೋಲನಗೊಳಿಸುವ ಜವಾಬ್ದಾರಿಯುತ ಸೇವೆ, ಬ್ಲಾಕ್ ಸಂಗ್ರಹಣೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಸೇವೆ, ಡಿಎನ್‌ಎಸ್‌ಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಸೇವೆ, ಬೇರ್ ಮೆಟಲ್ ಸರ್ವರ್‌ಗಳನ್ನು ಒದಗಿಸುವ ಜವಾಬ್ದಾರಿಯುತ ಸೇವೆ ಇತ್ಯಾದಿಗಳಿವೆ. ನಿಮ್ಮ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಕುರಿಗಳ ಹಿಂಡಿನಂತೆ (ವರ್ಚುವಲೈಸೇಶನ್‌ಗೆ ವಿರುದ್ಧವಾಗಿ) ಪರಿಗಣಿಸಲು ಕ್ಲೌಡ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ವರ್ಚುವಲ್ ಪರಿಸರದಲ್ಲಿ ನಿಮ್ಮ ಯಂತ್ರಕ್ಕೆ ಏನಾದರೂ ಸಂಭವಿಸಿದರೆ - ನೀವು ಅದನ್ನು ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು ಇತ್ಯಾದಿಗಳಿಂದ ಮರುಸ್ಥಾಪಿಸುತ್ತೀರಿ, ಆದರೆ ವರ್ಚುವಲ್ ಯಂತ್ರವು ಅಂತಹ ಪ್ರಮುಖ ಪಾತ್ರವನ್ನು ವಹಿಸದ ರೀತಿಯಲ್ಲಿ ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲಾಗಿದೆ - ವರ್ಚುವಲ್ ಯಂತ್ರ "ಮರಣಗೊಂಡಿದೆ" - ಸಮಸ್ಯೆ ಇಲ್ಲ. - ಹೊಸದನ್ನು ಸರಳವಾಗಿ ರಚಿಸಲಾಗಿದೆ ವಾಹನವು ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಆಧರಿಸಿದೆ ಮತ್ತು ಅವರು ಹೇಳಿದಂತೆ, ಹೋರಾಟಗಾರನ ನಷ್ಟವನ್ನು ತಂಡವು ಗಮನಿಸಲಿಲ್ಲ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಇದು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಕಾರ್ಯವಿಧಾನಗಳ ಉಪಸ್ಥಿತಿಯನ್ನು ಒದಗಿಸುತ್ತದೆ - ಹೀಟ್ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಬಳಸಿ, ನೀವು ಡಜನ್ಗಟ್ಟಲೆ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸಂಕೀರ್ಣ ಕಾರ್ಯವನ್ನು ಸುಲಭವಾಗಿ ನಿಯೋಜಿಸಬಹುದು.
ನೆಟ್ವರ್ಕ್ ಇಲ್ಲದೆ ಯಾವುದೇ ಕ್ಲೌಡ್ ಮೂಲಸೌಕರ್ಯವಿಲ್ಲ ಎಂದು ಯಾವಾಗಲೂ ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ - ಪ್ರತಿಯೊಂದು ಅಂಶವು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಇತರ ಅಂಶಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಲೌಡ್ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಿರವಲ್ಲದ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೊಂದಿದೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಅಂಡರ್‌ಲೇ ನೆಟ್ವರ್ಕ್ ಇನ್ನೂ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ - ಹೊಸ ನೋಡ್‌ಗಳು ಮತ್ತು ಸ್ವಿಚ್‌ಗಳನ್ನು ಪ್ರತಿದಿನ ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಓವರ್‌ಲೇ ಘಟಕವು ನಿರಂತರವಾಗಿ ಬದಲಾಗಬಹುದು ಮತ್ತು ಅನಿವಾರ್ಯವಾಗಿ ಬದಲಾಗಬಹುದು - ಹೊಸ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ ಅಥವಾ ಅಳಿಸಲಾಗುತ್ತದೆ, ಹೊಸ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಹಳೆಯವುಗಳು ಸಾಯುತ್ತವೆ. ಮತ್ತು ಲೇಖನದ ಪ್ರಾರಂಭದಲ್ಲಿ ನೀಡಲಾದ ಕ್ಲೌಡ್‌ನ ವ್ಯಾಖ್ಯಾನದಿಂದ ನೀವು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವಂತೆ, ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಕೆದಾರರಿಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮತ್ತು ಸೇವಾ ಪೂರೈಕೆದಾರರಿಂದ ಕನಿಷ್ಠ (ಅಥವಾ ಇನ್ನೂ ಉತ್ತಮ, ಇಲ್ಲದೆ) ಹಸ್ತಕ್ಷೇಪದೊಂದಿಗೆ ಹಂಚಬೇಕು. ಅಂದರೆ, http/https ಮೂಲಕ ಪ್ರವೇಶಿಸಬಹುದಾದ ನಿಮ್ಮ ವೈಯಕ್ತಿಕ ಖಾತೆಯ ರೂಪದಲ್ಲಿ ಮುಂಭಾಗದ ರೂಪದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನೆಟ್ವರ್ಕ್ ಸಂಪನ್ಮೂಲಗಳ ನಿಬಂಧನೆಯ ಪ್ರಕಾರ ಮತ್ತು ಆನ್-ಡ್ಯೂಟಿ ನೆಟ್ವರ್ಕ್ ಎಂಜಿನಿಯರ್ ವಾಸಿಲಿ ಬ್ಯಾಕೆಂಡ್ ಆಗಿ ಕ್ಲೌಡ್ ಅಲ್ಲ. ವಾಸಿಲಿ ಎಂಟು ಕೈಗಳನ್ನು ಹೊಂದಿದ್ದರೆ.
ನ್ಯೂಟ್ರಾನ್, ನೆಟ್ವರ್ಕ್ ಸೇವೆಯಾಗಿ, ಕ್ಲೌಡ್ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ನ ನೆಟ್ವರ್ಕ್ ಭಾಗವನ್ನು ನಿರ್ವಹಿಸಲು API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. Network-as-a-Service (NaaS) ಎಂಬ ಅಮೂರ್ತ ಪದರವನ್ನು ಒದಗಿಸುವ ಮೂಲಕ ಸೇವೆಯು ಓಪನ್‌ಸ್ಟಾಕ್‌ನ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಭಾಗವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ ಮತ್ತು ನಿರ್ವಹಿಸುತ್ತದೆ. ಅಂದರೆ, ನೆಟ್ವರ್ಕ್ ಅದೇ ವರ್ಚುವಲ್ ಅಳೆಯಬಹುದಾದ ಘಟಕವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ವರ್ಚುವಲ್ CPU ಕೋರ್ಗಳು ಅಥವಾ RAM ನ ಮೊತ್ತ.
ಆದರೆ ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನ ನೆಟ್ವರ್ಕ್ ಭಾಗದ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ತೆರಳುವ ಮೊದಲು, ಈ ನೆಟ್ವರ್ಕ್ ಓಪನ್ಸ್ಟ್ಯಾಕ್ನಲ್ಲಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಏಕೆ ಕ್ಲೌಡ್‌ನ ಪ್ರಮುಖ ಮತ್ತು ಅವಿಭಾಜ್ಯ ಭಾಗವಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸೋಣ.
ಆದ್ದರಿಂದ ನಾವು ಎರಡು RED ಕ್ಲೈಂಟ್ VM ಗಳನ್ನು ಮತ್ತು ಎರಡು GREEN ಕ್ಲೈಂಟ್ VM ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈ ಯಂತ್ರಗಳು ಈ ರೀತಿ ಎರಡು ಹೈಪರ್ವೈಸರ್ಗಳಲ್ಲಿವೆ ಎಂದು ಭಾವಿಸೋಣ:
ಈ ಸಮಯದಲ್ಲಿ, ಇದು ಕೇವಲ 4 ಸರ್ವರ್‌ಗಳ ವರ್ಚುವಲೈಸೇಶನ್ ಮತ್ತು ಹೆಚ್ಚೇನೂ ಇಲ್ಲ, ಏಕೆಂದರೆ ಇಲ್ಲಿಯವರೆಗೆ ನಾವು ಮಾಡಿರುವುದು 4 ಸರ್ವರ್‌ಗಳನ್ನು ವರ್ಚುವಲೈಸ್ ಮಾಡುವುದು, ಅವುಗಳನ್ನು ಎರಡು ಭೌತಿಕ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಇರಿಸುವುದು. ಮತ್ತು ಇಲ್ಲಿಯವರೆಗೆ ಅವರು ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಪರ್ಕ ಹೊಂದಿಲ್ಲ.
ಮೋಡವನ್ನು ಮಾಡಲು, ನಾವು ಹಲವಾರು ಘಟಕಗಳನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ. ಮೊದಲಿಗೆ, ನಾವು ನೆಟ್ವರ್ಕ್ ಭಾಗವನ್ನು ವರ್ಚುವಲೈಸ್ ಮಾಡುತ್ತೇವೆ - ನಾವು ಈ 4 ಯಂತ್ರಗಳನ್ನು ಜೋಡಿಯಾಗಿ ಸಂಪರ್ಕಿಸಬೇಕು ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳು L2 ಸಂಪರ್ಕವನ್ನು ಬಯಸುತ್ತಾರೆ. ನೀವು ಸ್ವಿಚ್ ಅನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಅದರ ದಿಕ್ಕಿನಲ್ಲಿ ಟ್ರಂಕ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಮತ್ತು ಲಿನಕ್ಸ್ ಸೇತುವೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲವನ್ನೂ ಪರಿಹರಿಸಬಹುದು ಅಥವಾ ಹೆಚ್ಚು ಮುಂದುವರಿದ ಬಳಕೆದಾರರಿಗೆ, openvswitch (ನಾವು ಇದನ್ನು ನಂತರ ಹಿಂತಿರುಗಿಸುತ್ತೇವೆ). ಆದರೆ ಸಾಕಷ್ಟು ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಇರಬಹುದು ಮತ್ತು ಸ್ವಿಚ್ ಮೂಲಕ ನಿರಂತರವಾಗಿ ಎಲ್ 2 ಅನ್ನು ತಳ್ಳುವುದು ಉತ್ತಮ ಉಪಾಯವಲ್ಲ - ವಿವಿಧ ವಿಭಾಗಗಳು, ಸೇವಾ ಮೇಜು, ಅಪ್ಲಿಕೇಶನ್ ಪೂರ್ಣಗೊಳ್ಳಲು ತಿಂಗಳುಗಳ ಕಾಯುವಿಕೆ, ವಾರಗಳ ದೋಷನಿವಾರಣೆ - ಆಧುನಿಕ ಜಗತ್ತಿನಲ್ಲಿ ಇದು ವಿಧಾನವು ಇನ್ನು ಮುಂದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಕಂಪನಿಯು ಇದನ್ನು ಎಷ್ಟು ಬೇಗನೆ ಅರ್ಥಮಾಡಿಕೊಂಡಿದೆಯೋ ಅಷ್ಟು ಸುಲಭವಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಹೈಪರ್ವೈಸರ್ಗಳ ನಡುವೆ ನಾವು ನಮ್ಮ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಸಂವಹನ ನಡೆಸುವ L3 ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಈ L3 ನೆಟ್‌ವರ್ಕ್‌ನ ಮೇಲೆ ನಾವು ವರ್ಚುವಲ್ L2 ಓವರ್‌ಲೇ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ ಅಲ್ಲಿ ನಮ್ಮ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ದಟ್ಟಣೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನೀವು GRE, Geneve ಅಥವಾ VxLAN ಅನ್ನು ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಆಗಿ ಬಳಸಬಹುದು. ಇದು ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಲ್ಲದಿದ್ದರೂ, ಇದೀಗ ಎರಡನೆಯದನ್ನು ಕೇಂದ್ರೀಕರಿಸೋಣ.
ನಾವು VTEP ಅನ್ನು ಎಲ್ಲೋ ಪತ್ತೆ ಮಾಡಬೇಕಾಗಿದೆ (ಪ್ರತಿಯೊಬ್ಬರೂ VxLAN ಪರಿಭಾಷೆಯೊಂದಿಗೆ ಪರಿಚಿತರಾಗಿದ್ದಾರೆಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ). ನಾವು ಸರ್ವರ್‌ಗಳಿಂದ ನೇರವಾಗಿ ಬರುವ L3 ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಸರ್ವರ್‌ಗಳಲ್ಲಿ VTEP ಅನ್ನು ಇರಿಸುವುದನ್ನು ಯಾವುದೂ ತಡೆಯುವುದಿಲ್ಲ ಮತ್ತು OVS (OpenvSwitch) ಇದನ್ನು ಮಾಡುವುದರಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿದೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈ ವಿನ್ಯಾಸವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ:
VM ಗಳ ನಡುವಿನ ದಟ್ಟಣೆಯನ್ನು ವಿಭಜಿಸಬೇಕಾಗಿರುವುದರಿಂದ, ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ಕಡೆಗೆ ಪೋರ್ಟ್‌ಗಳು ವಿಭಿನ್ನ vlan ಸಂಖ್ಯೆಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಟ್ಯಾಗ್ ಸಂಖ್ಯೆಯು ಒಂದು ವರ್ಚುವಲ್ ಸ್ವಿಚ್‌ನಲ್ಲಿ ಮಾತ್ರ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ, ಏಕೆಂದರೆ VxLAN ನಲ್ಲಿ ಸುತ್ತುವರಿಯಲ್ಪಟ್ಟಾಗ ನಾವು ಅದನ್ನು ಸುಲಭವಾಗಿ ತೆಗೆದುಹಾಕಬಹುದು, ಏಕೆಂದರೆ ನಾವು VNI ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಈಗ ನಾವು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ನಮ್ಮ ಯಂತ್ರಗಳು ಮತ್ತು ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು.
ಆದಾಗ್ಯೂ, ಕ್ಲೈಂಟ್ ಮತ್ತೊಂದು ಯಂತ್ರವನ್ನು ಹೊಂದಿದ್ದರೆ, ಆದರೆ ಬೇರೆ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿದ್ದರೆ ಏನು? ನಮಗೆ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ನಡುವೆ ಬೇರೂರಿಸುವ ಅಗತ್ಯವಿದೆ. ಕೇಂದ್ರೀಕೃತ ರೂಟಿಂಗ್ ಅನ್ನು ಬಳಸಿದಾಗ ನಾವು ಸರಳವಾದ ಆಯ್ಕೆಯನ್ನು ನೋಡುತ್ತೇವೆ - ಅಂದರೆ, ವಿಶೇಷ ಮೀಸಲಾದ ನೆಟ್ವರ್ಕ್ ನೋಡ್ಗಳ ಮೂಲಕ ಸಂಚಾರವನ್ನು ನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ (ಅಲ್ಲದೆ, ನಿಯಮದಂತೆ, ಅವುಗಳನ್ನು ನಿಯಂತ್ರಣ ನೋಡ್ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಒಂದೇ ವಿಷಯವನ್ನು ಹೊಂದಿರುತ್ತೇವೆ).
ಇದು ಏನೂ ಸಂಕೀರ್ಣವಾಗಿಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ - ನಾವು ಕಂಟ್ರೋಲ್ ನೋಡ್ನಲ್ಲಿ ಸೇತುವೆಯ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ತಯಾರಿಸುತ್ತೇವೆ, ಅದಕ್ಕೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅಲ್ಲಿಂದ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಸ್ಥಳಕ್ಕೆ ನಾವು ಅದನ್ನು ರವಾನಿಸುತ್ತೇವೆ. ಆದರೆ ಸಮಸ್ಯೆಯೆಂದರೆ RED ಕ್ಲೈಂಟ್ 10.0.0.0/24 ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಬಳಸಲು ಬಯಸುತ್ತದೆ ಮತ್ತು GREEN ಕ್ಲೈಂಟ್ 10.0.0.0/24 ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಬಳಸಲು ಬಯಸುತ್ತದೆ. ಅಂದರೆ, ನಾವು ವಿಳಾಸ ಸ್ಥಳಗಳನ್ನು ಛೇದಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಗ್ರಾಹಕರು ಇತರ ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮ ಆಂತರಿಕ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ ಮಾರ್ಗವನ್ನು ಹೊಂದಲು ಬಯಸುವುದಿಲ್ಲ, ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಕ್ಲೈಂಟ್ ಡೇಟಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು, ನಾವು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪ್ರತ್ಯೇಕ ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ. ನೇಮ್‌ಸ್ಪೇಸ್ ವಾಸ್ತವವಾಗಿ ಲಿನಕ್ಸ್ ನೆಟ್ವರ್ಕ್ ಸ್ಟಾಕ್‌ನ ನಕಲು ಆಗಿದೆ, ಅಂದರೆ, ನೇಮ್‌ಸ್ಪೇಸ್ RED ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್‌ಗಳು ನೇಮ್‌ಸ್ಪೇಸ್ GREEN ನಿಂದ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟಿದೆ (ಅಲ್ಲದೆ, ಈ ಕ್ಲೈಂಟ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ನಡುವೆ ರೂಟಿಂಗ್ ಅನ್ನು ಡೀಫಾಲ್ಟ್ ನೇಮ್‌ಸ್ಪೇಸ್ ಮೂಲಕ ಅಥವಾ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸಾರಿಗೆ ಸಾಧನಗಳಲ್ಲಿ ಅನುಮತಿಸಲಾಗುತ್ತದೆ).
ಅಂದರೆ, ನಾವು ಈ ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವನ್ನು ಪಡೆಯುತ್ತೇವೆ:
L2 ಸುರಂಗಗಳು ಎಲ್ಲಾ ಕಂಪ್ಯೂಟಿಂಗ್ ನೋಡ್‌ಗಳಿಂದ ನಿಯಂತ್ರಣ ನೋಡ್‌ಗೆ ಒಮ್ಮುಖವಾಗುತ್ತವೆ. ಈ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗಾಗಿ L3 ಇಂಟರ್ಫೇಸ್ ಇರುವ ನೋಡ್, ಪ್ರತಿಯೊಂದೂ ಪ್ರತ್ಯೇಕತೆಗಾಗಿ ಮೀಸಲಾದ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿದೆ.
ಆದಾಗ್ಯೂ, ನಾವು ಪ್ರಮುಖ ವಿಷಯವನ್ನು ಮರೆತಿದ್ದೇವೆ. ವರ್ಚುವಲ್ ಯಂತ್ರವು ಕ್ಲೈಂಟ್‌ಗೆ ಸೇವೆಯನ್ನು ಒದಗಿಸಬೇಕು, ಅಂದರೆ, ಅದು ತಲುಪಬಹುದಾದ ಕನಿಷ್ಠ ಒಂದು ಬಾಹ್ಯ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು. ಅಂದರೆ, ನಾವು ಹೊರಗಿನ ಪ್ರಪಂಚಕ್ಕೆ ಹೋಗಬೇಕಾಗಿದೆ. ಇಲ್ಲಿ ವಿಭಿನ್ನ ಆಯ್ಕೆಗಳಿವೆ. ಸರಳವಾದ ಆಯ್ಕೆಯನ್ನು ಮಾಡೋಣ. ನಾವು ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಒಂದು ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ, ಅದು ಪೂರೈಕೆದಾರರ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ ಮತ್ತು ಇತರ ನೆಟ್‌ವರ್ಕ್‌ಗಳೊಂದಿಗೆ ಅತಿಕ್ರಮಿಸುವುದಿಲ್ಲ. ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಛೇದಿಸಬಹುದು ಮತ್ತು ಒದಗಿಸುವವರ ನೆಟ್‌ವರ್ಕ್‌ನ ಬದಿಯಲ್ಲಿರುವ ವಿಭಿನ್ನ ವಿಆರ್‌ಎಫ್‌ಗಳನ್ನು ನೋಡಬಹುದು. ನೆಟ್ವರ್ಕ್ ಡೇಟಾವು ಪ್ರತಿ ಕ್ಲೈಂಟ್ನ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿಯೂ ಸಹ ವಾಸಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಅವರು ಇನ್ನೂ ಒಂದು ಭೌತಿಕ (ಅಥವಾ ಬಾಂಡ್, ಇದು ಹೆಚ್ಚು ತಾರ್ಕಿಕ) ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಗಿನ ಪ್ರಪಂಚಕ್ಕೆ ಹೋಗುತ್ತಾರೆ. ಕ್ಲೈಂಟ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು, ಹೊರಗೆ ಹೋಗುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ನಿಯೋಜಿಸಲಾದ VLAN ಟ್ಯಾಗ್‌ನೊಂದಿಗೆ ಟ್ಯಾಗ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈ ರೇಖಾಚಿತ್ರವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ:
ಸಮಂಜಸವಾದ ಪ್ರಶ್ನೆಯೆಂದರೆ ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ಗಳಲ್ಲಿ ಗೇಟ್‌ವೇಗಳನ್ನು ಏಕೆ ಮಾಡಬಾರದು? ಇದು ದೊಡ್ಡ ಸಮಸ್ಯೆ ಅಲ್ಲ; ಮೇಲಾಗಿ, ನೀವು ವಿತರಿಸಿದ ರೂಟರ್ (DVR) ಅನ್ನು ಆನ್ ಮಾಡಿದರೆ, ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ, ನಾವು ಕೇಂದ್ರೀಕೃತ ಗೇಟ್‌ವೇಯೊಂದಿಗೆ ಸರಳವಾದ ಆಯ್ಕೆಯನ್ನು ಪರಿಗಣಿಸುತ್ತಿದ್ದೇವೆ, ಇದನ್ನು ಓಪನ್‌ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಲೋಡ್ ಕಾರ್ಯಗಳಿಗಾಗಿ, ಅವರು ವಿತರಿಸಿದ ರೂಟರ್ ಮತ್ತು ವೇಗವರ್ಧಕ ತಂತ್ರಜ್ಞಾನಗಳಾದ SR-IOV ಮತ್ತು ಪಾಸ್‌ಥ್ರೂ ಎರಡನ್ನೂ ಬಳಸುತ್ತಾರೆ, ಆದರೆ ಅವರು ಹೇಳಿದಂತೆ, ಇದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಕಥೆಯಾಗಿದೆ. ಮೊದಲಿಗೆ, ಮೂಲ ಭಾಗದೊಂದಿಗೆ ವ್ಯವಹರಿಸೋಣ, ಮತ್ತು ನಂತರ ನಾವು ವಿವರಗಳಿಗೆ ಹೋಗುತ್ತೇವೆ.
ವಾಸ್ತವವಾಗಿ, ನಮ್ಮ ಯೋಜನೆಯು ಈಗಾಗಲೇ ಕಾರ್ಯಸಾಧ್ಯವಾಗಿದೆ, ಆದರೆ ಒಂದೆರಡು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ:
- ನಾವು ಹೇಗಾದರೂ ನಮ್ಮ ಯಂತ್ರಗಳನ್ನು ರಕ್ಷಿಸಬೇಕಾಗಿದೆ, ಅಂದರೆ, ಕ್ಲೈಂಟ್ ಕಡೆಗೆ ಸ್ವಿಚ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಫಿಲ್ಟರ್ ಅನ್ನು ಇರಿಸಿ.
- ವರ್ಚುವಲ್ ಗಣಕವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ IP ವಿಳಾಸವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಮಾಡಿ, ಆದ್ದರಿಂದ ನೀವು ಪ್ರತಿ ಬಾರಿಯೂ ಕನ್ಸೋಲ್ ಮೂಲಕ ಲಾಗ್ ಇನ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ ಮತ್ತು ವಿಳಾಸವನ್ನು ನೋಂದಾಯಿಸಬೇಕಾಗಿಲ್ಲ.
ಯಂತ್ರ ರಕ್ಷಣೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ಇದಕ್ಕಾಗಿ ನೀವು ನೀರಸ iptables ಅನ್ನು ಬಳಸಬಹುದು, ಏಕೆ ಅಲ್ಲ.
ಅಂದರೆ, ಈಗ ನಮ್ಮ ಟೋಪೋಲಜಿ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ:
ಮುಂದೆ ಸಾಗೋಣ. ನಾವು DHCP ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ. ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ DHCP ಸರ್ವರ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ಸ್ಥಳವೆಂದರೆ ಈಗಾಗಲೇ ಮೇಲೆ ತಿಳಿಸಲಾದ ನಿಯಂತ್ರಣ ನೋಡ್ ಆಗಿರುತ್ತದೆ, ಅಲ್ಲಿ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಿವೆ:
ಆದಾಗ್ಯೂ, ಒಂದು ಸಣ್ಣ ಸಮಸ್ಯೆ ಇದೆ. ಎಲ್ಲವೂ ರೀಬೂಟ್ ಆಗಿದ್ದರೆ ಮತ್ತು DHCP ನಲ್ಲಿ ವಿಳಾಸಗಳನ್ನು ಬಾಡಿಗೆಗೆ ಪಡೆಯುವ ಬಗ್ಗೆ ಎಲ್ಲಾ ಮಾಹಿತಿಯು ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ಯಂತ್ರಗಳಿಗೆ ಹೊಸ ವಿಳಾಸಗಳನ್ನು ನೀಡಲಾಗುವುದು ಎಂಬುದು ತಾರ್ಕಿಕವಾಗಿದೆ, ಅದು ತುಂಬಾ ಅನುಕೂಲಕರವಲ್ಲ. ಇಲ್ಲಿ ಎರಡು ಮಾರ್ಗಗಳಿವೆ - ಒಂದೋ ಡೊಮೇನ್ ಹೆಸರುಗಳನ್ನು ಬಳಸಿ ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ DNS ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸಿ, ನಂತರ ವಿಳಾಸವು ನಮಗೆ ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಾಗುವುದಿಲ್ಲ (k8s ನಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಭಾಗದಂತೆಯೇ) - ಆದರೆ ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ, ಏಕೆಂದರೆ DHCP ಮೂಲಕ ವಿಳಾಸಗಳನ್ನು ಸಹ ನೀಡಬಹುದು - ನಿಮಗೆ ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿನ DNS ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮತ್ತು ಬಾಹ್ಯ DNS ಸರ್ವರ್ ಅಗತ್ಯವಿದೆ, ಇದು ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದರೆ ಸಾಕಷ್ಟು ಸಾಧ್ಯ. ಅಥವಾ ಎರಡನೆಯ ಆಯ್ಕೆಯು ಮೆಟಾಡೇಟಾವನ್ನು ಬಳಸುವುದು - ಅಂದರೆ, ಯಂತ್ರಕ್ಕೆ ನೀಡಲಾದ ವಿಳಾಸದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸಿ ಇದರಿಂದ ಯಂತ್ರವು ಈಗಾಗಲೇ ವಿಳಾಸವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದರೆ ಯಂತ್ರಕ್ಕೆ ಯಾವ ವಿಳಾಸವನ್ನು ನೀಡಬೇಕೆಂದು DHCP ಸರ್ವರ್‌ಗೆ ತಿಳಿಯುತ್ತದೆ. ಎರಡನೆಯ ಆಯ್ಕೆಯು ಸರಳ ಮತ್ತು ಹೆಚ್ಚು ಮೃದುವಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ಇದು ಕಾರಿನ ಬಗ್ಗೆ ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈಗ ರೇಖಾಚಿತ್ರಕ್ಕೆ ಏಜೆಂಟ್ ಮೆಟಾಡೇಟಾವನ್ನು ಸೇರಿಸೋಣ:
ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಒಂದು ಬಾಹ್ಯ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವು ಚರ್ಚಿಸಬೇಕಾದ ಮತ್ತೊಂದು ವಿಷಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಇಡೀ ನೆಟ್‌ವರ್ಕ್‌ನಾದ್ಯಂತ ಮಾನ್ಯವಾಗಿದ್ದರೆ ಕಷ್ಟವಾಗುತ್ತದೆ - ನೀವು ಈ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ಹಂಚಿಕೆಯನ್ನು ನಿರಂತರವಾಗಿ ನಿಯೋಜಿಸಬೇಕು ಮತ್ತು ನಿಯಂತ್ರಿಸಬೇಕು. ಸಾರ್ವಜನಿಕ ಕ್ಲೌಡ್ ಅನ್ನು ರಚಿಸುವಾಗ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಒಂದೇ ಬಾಹ್ಯ ಪೂರ್ವ-ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವು ತುಂಬಾ ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ. ಇದು ಯಂತ್ರಗಳನ್ನು ನಿಯೋಜಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ ಏಕೆಂದರೆ ನಾವು ವಿಳಾಸ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಬೇಕಾಗಿಲ್ಲ ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ನ ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಾಗಿ ಅನನ್ಯ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗಿಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಬಾಹ್ಯ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಮುಂಚಿತವಾಗಿ ನೋಂದಾಯಿಸಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ನಾವು ಕ್ಲೈಂಟ್ ಯಂತ್ರಗಳೊಂದಿಗೆ ಬಾಹ್ಯ ವಿಳಾಸಗಳನ್ನು ಮಾತ್ರ ಸಂಯೋಜಿಸಬೇಕಾಗುತ್ತದೆ.
ಮತ್ತು ಇಲ್ಲಿ NAT ನಮ್ಮ ಸಹಾಯಕ್ಕೆ ಬರುತ್ತದೆ - NAT ಅನುವಾದವನ್ನು ಬಳಸಿಕೊಂಡು ಡೀಫಾಲ್ಟ್ ನೇಮ್‌ಸ್ಪೇಸ್ ಮೂಲಕ ಗ್ರಾಹಕರಿಗೆ ಹೊರಗಿನ ಪ್ರಪಂಚವನ್ನು ಪ್ರವೇಶಿಸಲು ನಾವು ಸಾಧ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತೇವೆ. ಸರಿ, ಇಲ್ಲೊಂದು ಸಣ್ಣ ಸಮಸ್ಯೆ ಇದೆ. ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ಕ್ಲೈಂಟ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದರೆ ಮತ್ತು ಸರ್ವರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸದಿದ್ದರೆ ಇದು ಒಳ್ಳೆಯದು - ಅಂದರೆ, ಇದು ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಬದಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಆದರೆ ನಮಗೆ ಅದು ತದ್ವಿರುದ್ಧವಾಗಿರುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಗಮ್ಯಸ್ಥಾನ NAT ಅನ್ನು ಮಾಡಬೇಕಾಗಿದೆ ಆದ್ದರಿಂದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವಾಗ, ಈ ದಟ್ಟಣೆಯು ಕ್ಲೈಂಟ್ A ಯ ವರ್ಚುವಲ್ ಯಂತ್ರ A ಗಾಗಿ ಉದ್ದೇಶಿಸಲಾಗಿದೆ ಎಂದು ನಿಯಂತ್ರಣ ನೋಡ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಅಂದರೆ ನಾವು ಬಾಹ್ಯ ವಿಳಾಸದಿಂದ NAT ಅನುವಾದವನ್ನು ಮಾಡಬೇಕಾಗಿದೆ, ಉದಾಹರಣೆಗೆ 100.1.1.1 .10.0.0.1, ಆಂತರಿಕ ವಿಳಾಸಕ್ಕೆ 100. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳು ಒಂದೇ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೂ, ಆಂತರಿಕ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸಂರಕ್ಷಿಸಲಾಗಿದೆ. ಅಂದರೆ, ನಾವು ನಿಯಂತ್ರಣ ನೋಡ್ನಲ್ಲಿ dNAT ಮತ್ತು sNAT ಮಾಡಬೇಕಾಗಿದೆ. ತೇಲುವ ವಿಳಾಸಗಳು ಅಥವಾ ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳೊಂದಿಗೆ ಒಂದೇ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಬಳಸಬೇಕೆ ಅಥವಾ ಎರಡನ್ನೂ ಏಕಕಾಲದಲ್ಲಿ ಬಳಸಬೇಕೆ, ನೀವು ಕ್ಲೌಡ್‌ಗೆ ಏನನ್ನು ತರಲು ಬಯಸುತ್ತೀರಿ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ನಾವು ರೇಖಾಚಿತ್ರಕ್ಕೆ ತೇಲುವ ವಿಳಾಸಗಳನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಮೊದಲೇ ಸೇರಿಸಲಾದ ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಬಿಡುತ್ತೇವೆ - ಪ್ರತಿ ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಆದ ಬಾಹ್ಯ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಹೊಂದಿದೆ (ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಅವುಗಳನ್ನು ಬಾಹ್ಯ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ vlan 200 ಮತ್ತು XNUMX ಎಂದು ಸೂಚಿಸಲಾಗುತ್ತದೆ).
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಚೆನ್ನಾಗಿ ಯೋಚಿಸಿದ ಪರಿಹಾರವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ, ಇದು ಒಂದು ನಿರ್ದಿಷ್ಟ ನಮ್ಯತೆಯನ್ನು ಹೊಂದಿದೆ ಆದರೆ ಇನ್ನೂ ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಹೊಂದಿಲ್ಲ.
ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಕೇವಲ ಒಂದು ನಿಯಂತ್ರಣ ನೋಡ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಅದರ ವೈಫಲ್ಯವು ಎಲ್ಲಾ ವ್ಯವಸ್ಥೆಗಳ ಕುಸಿತಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನೀವು ಕನಿಷ್ಟ 3 ನೋಡ್ಗಳ ಕೋರಂ ಅನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ಇದನ್ನು ರೇಖಾಚಿತ್ರಕ್ಕೆ ಸೇರಿಸೋಣ:
ಸ್ವಾಭಾವಿಕವಾಗಿ, ಎಲ್ಲಾ ನೋಡ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಸಕ್ರಿಯ ನೋಡ್ ತೊರೆದಾಗ, ಮತ್ತೊಂದು ನೋಡ್ ಅದರ ಜವಾಬ್ದಾರಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಮುಂದಿನ ಸಮಸ್ಯೆ ವರ್ಚುವಲ್ ಯಂತ್ರ ಡಿಸ್ಕ್ ಆಗಿದೆ. ಈ ಸಮಯದಲ್ಲಿ, ಅವುಗಳನ್ನು ಹೈಪರ್‌ವೈಸರ್‌ಗಳಲ್ಲಿಯೇ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಮತ್ತು ಹೈಪರ್‌ವೈಸರ್‌ನೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ - ಮತ್ತು ನಾವು ಡಿಸ್ಕ್ ಅಲ್ಲ, ಆದರೆ ಸಂಪೂರ್ಣ ಸರ್ವರ್ ಅನ್ನು ಕಳೆದುಕೊಂಡರೆ ದಾಳಿಯ ಉಪಸ್ಥಿತಿಯು ಇಲ್ಲಿ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಕೆಲವು ರೀತಿಯ ಸಂಗ್ರಹಣೆಗಾಗಿ ಮುಂಭಾಗದ ತುದಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸೇವೆಯನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ಇದು ಯಾವ ರೀತಿಯ ಸಂಗ್ರಹಣೆಯಾಗಿದೆ ಎಂಬುದು ನಮಗೆ ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಲ್ಲ, ಆದರೆ ಇದು ಡಿಸ್ಕ್ ಮತ್ತು ನೋಡ್ ಮತ್ತು ಪ್ರಾಯಶಃ ಸಂಪೂರ್ಣ ಕ್ಯಾಬಿನೆಟ್ ಎರಡರ ವೈಫಲ್ಯದಿಂದ ನಮ್ಮ ಡೇಟಾವನ್ನು ರಕ್ಷಿಸಬೇಕು. ಇಲ್ಲಿ ಹಲವಾರು ಆಯ್ಕೆಗಳಿವೆ - ಸಹಜವಾಗಿ, ಫೈಬರ್ ಚಾನೆಲ್‌ನೊಂದಿಗೆ SAN ನೆಟ್‌ವರ್ಕ್‌ಗಳಿವೆ, ಆದರೆ ಪ್ರಾಮಾಣಿಕವಾಗಿರಲಿ - FC ಈಗಾಗಲೇ ಹಿಂದಿನ ಅವಶೇಷವಾಗಿದೆ - ಸಾರಿಗೆಯಲ್ಲಿ E1 ನ ಅನಲಾಗ್ - ಹೌದು, ನಾನು ಒಪ್ಪುತ್ತೇನೆ, ಅದನ್ನು ಇನ್ನೂ ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅದು ಇಲ್ಲದೆ ಸಂಪೂರ್ಣವಾಗಿ ಅಸಾಧ್ಯವಾದ ಸ್ಥಳದಲ್ಲಿ ಮಾತ್ರ. ಆದ್ದರಿಂದ, ನಾನು 2020 ರಲ್ಲಿ ಸ್ವಯಂಪ್ರೇರಣೆಯಿಂದ FC ನೆಟ್ವರ್ಕ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದಿಲ್ಲ, ಇತರ ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ಪರ್ಯಾಯಗಳಿವೆ ಎಂದು ತಿಳಿದುಕೊಂಡಿದ್ದೇನೆ. ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ತನ್ನದೇ ಆದದ್ದಾದರೂ, ಎಫ್‌ಸಿ ಅದರ ಎಲ್ಲಾ ಮಿತಿಗಳೊಂದಿಗೆ ನಮಗೆ ಬೇಕಾಗಿರುವುದು ಎಂದು ನಂಬುವವರು ಇರಬಹುದು - ನಾನು ವಾದಿಸುವುದಿಲ್ಲ, ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮದೇ ಆದ ಅಭಿಪ್ರಾಯವನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಆದಾಗ್ಯೂ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಪರಿಹಾರವೆಂದರೆ Ceph ನಂತಹ SDS ಅನ್ನು ಬಳಸುವುದು.
ಸಂಭವನೀಯ ಬ್ಯಾಕಪ್ ಆಯ್ಕೆಗಳ ಗುಂಪಿನೊಂದಿಗೆ ಹೆಚ್ಚು ಲಭ್ಯವಿರುವ ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಪರಿಹಾರವನ್ನು ನಿರ್ಮಿಸಲು Ceph ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಪ್ಯಾರಿಟಿ ಚೆಕ್‌ನೊಂದಿಗೆ (ರೇಡ್ 5 ಅಥವಾ 6 ಗೆ ಸದೃಶವಾಗಿ) ಕೋಡ್‌ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ, ವಿಭಿನ್ನ ಡಿಸ್ಕ್‌ಗಳಿಗೆ ಪೂರ್ಣ ಡೇಟಾ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಡಿಸ್ಕ್‌ಗಳ ಸ್ಥಳವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸರ್ವರ್‌ಗಳು, ಮತ್ತು ಕ್ಯಾಬಿನೆಟ್‌ಗಳಲ್ಲಿನ ಸರ್ವರ್‌ಗಳು, ಇತ್ಯಾದಿ.
Ceph ಅನ್ನು ನಿರ್ಮಿಸಲು ನಿಮಗೆ ಇನ್ನೂ 3 ನೋಡ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ. ಬ್ಲಾಕ್, ಆಬ್ಜೆಕ್ಟ್ ಮತ್ತು ಫೈಲ್ ಶೇಖರಣಾ ಸೇವೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಸಹ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ. ಸ್ಕೀಮಾಗೆ ಸಂಗ್ರಹಣೆಯನ್ನು ಸೇರಿಸೋಣ:
ಗಮನಿಸಿ: ನೀವು ಹೈಪರ್‌ಕನ್ವರ್ಜ್ಡ್ ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ಗಳನ್ನು ಸಹ ಮಾಡಬಹುದು - ಇದು ಒಂದು ನೋಡ್ನಲ್ಲಿ ಹಲವಾರು ಕಾರ್ಯಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ - ಉದಾಹರಣೆಗೆ, ಶೇಖರಣೆ+ಕಂಪ್ಯೂಟ್ - ಸೆಫ್ ಸಂಗ್ರಹಣೆಗಾಗಿ ವಿಶೇಷ ನೋಡ್‌ಗಳನ್ನು ಮೀಸಲಿಡದೆ. ನಾವು ಅದೇ ದೋಷ-ಸಹಿಷ್ಣು ಯೋಜನೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ - SDS ನಾವು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮೀಸಲಾತಿ ಮಟ್ಟದೊಂದಿಗೆ ಡೇಟಾವನ್ನು ಕಾಯ್ದಿರಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಹೈಪರ್‌ಕನ್ವರ್ಜ್ಡ್ ನೋಡ್‌ಗಳು ಯಾವಾಗಲೂ ರಾಜಿಯಾಗಿರುತ್ತವೆ - ಏಕೆಂದರೆ ಶೇಖರಣಾ ನೋಡ್ ಮೊದಲ ನೋಟದಲ್ಲಿ ತೋರುತ್ತಿರುವಂತೆ ಗಾಳಿಯನ್ನು ಬಿಸಿ ಮಾಡುವುದಿಲ್ಲ (ಅದರ ಮೇಲೆ ಯಾವುದೇ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಲ್ಲದ ಕಾರಣ) - ಇದು SDS ಸೇವೆಗಾಗಿ CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ಖರ್ಚು ಮಾಡುತ್ತದೆ (ವಾಸ್ತವವಾಗಿ, ಅದು ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತದೆ ನೋಡ್‌ಗಳು, ಡಿಸ್ಕ್‌ಗಳು ಇತ್ಯಾದಿಗಳ ವೈಫಲ್ಯಗಳ ನಂತರ ಪುನರಾವರ್ತನೆ ಮತ್ತು ಚೇತರಿಕೆ). ಅಂದರೆ, ನೀವು ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಿದರೆ ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ನ ಕೆಲವು ಶಕ್ತಿಯನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.
ಈ ಎಲ್ಲಾ ವಿಷಯವನ್ನು ಹೇಗಾದರೂ ನಿರ್ವಹಿಸಬೇಕಾಗಿದೆ - ನಾವು ಯಂತ್ರ, ನೆಟ್ವರ್ಕ್, ವರ್ಚುವಲ್ ರೂಟರ್ ಇತ್ಯಾದಿಗಳನ್ನು ರಚಿಸುವ ಮೂಲಕ ನಮಗೆ ಏನಾದರೂ ಅಗತ್ಯವಿದೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ನಿಯಂತ್ರಣ ನೋಡ್‌ಗೆ ಸೇವೆಯನ್ನು ಸೇರಿಸುತ್ತೇವೆ - ಕ್ಲೈಂಟ್ ಈ ಪೋರ್ಟಲ್‌ಗೆ http/ https ಮೂಲಕ ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಅವನಿಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ (ಅಲ್ಲದೆ, ಬಹುತೇಕ) ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈಗ ದೋಷ-ಸಹಿಷ್ಣು ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಈ ಮೂಲಸೌಕರ್ಯದ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಹೇಗಾದರೂ ನಿರ್ವಹಿಸಬೇಕು. ಓಪನ್‌ಸ್ಟಾಕ್ ಯೋಜನೆಗಳ ಒಂದು ಸೆಟ್ ಎಂದು ಹಿಂದೆ ವಿವರಿಸಲಾಗಿದೆ, ಪ್ರತಿಯೊಂದೂ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ. ನಾವು ನೋಡುವಂತೆ, ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾದ ಮತ್ತು ನಿಯಂತ್ರಿಸಬೇಕಾದ ಸಾಕಷ್ಟು ಅಂಶಗಳಿವೆ. ಇಂದು ನಾವು ನೆಟ್ವರ್ಕ್ ಭಾಗದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ.
ನ್ಯೂಟ್ರಾನ್ ಆರ್ಕಿಟೆಕ್ಚರ್
ಓಪನ್ಸ್ಟ್ಯಾಕ್ನಲ್ಲಿ, ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಪೋರ್ಟ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯ L2 ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಪರ್ಕಿಸಲು ನ್ಯೂಟ್ರಾನ್ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ, ವಿವಿಧ L2 ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಇರುವ VM ಗಳ ನಡುವೆ ಟ್ರಾಫಿಕ್ ರೂಟಿಂಗ್ ಅನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಜೊತೆಗೆ ಹೊರಗಿನ ರೂಟಿಂಗ್, NAT, ಫ್ಲೋಟಿಂಗ್ IP, DHCP, ಇತ್ಯಾದಿ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ, ನೆಟ್ವರ್ಕ್ ಸೇವೆಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು (ಮೂಲ ಭಾಗ) ಈ ಕೆಳಗಿನಂತೆ ವಿವರಿಸಬಹುದು.
VM ಅನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ, ನೆಟ್ವರ್ಕ್ ಸೇವೆ:
- ನೀಡಿರುವ VM (ಅಥವಾ ಪೋರ್ಟ್‌ಗಳು) ಗಾಗಿ ಪೋರ್ಟ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ DHCP ಸೇವೆಗೆ ಸೂಚನೆ ನೀಡುತ್ತದೆ;
- ಹೊಸ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಸಾಧನವನ್ನು ರಚಿಸಲಾಗಿದೆ (libvirt ಮೂಲಕ);
- ಹಂತ 1 ರಲ್ಲಿ ರಚಿಸಲಾದ ಪೋರ್ಟ್ (ಗಳಿಗೆ) ಗೆ VM ಸಂಪರ್ಕಿಸುತ್ತದೆ;
ವಿಚಿತ್ರವೆಂದರೆ, ನ್ಯೂಟ್ರಾನ್ನ ಕೆಲಸವು ಲಿನಕ್ಸ್‌ಗೆ ಧುಮುಕಿರುವ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಪರಿಚಿತವಾಗಿರುವ ಪ್ರಮಾಣಿತ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಆಧರಿಸಿದೆ - ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳು, ಐಪ್ಟೇಬಲ್‌ಗಳು, ಲಿನಕ್ಸ್ ಸೇತುವೆಗಳು, ಓಪನ್‌ವಿಚ್, ಕಾಂಟ್‌ಟ್ರಾಕ್, ಇತ್ಯಾದಿ.
ನ್ಯೂಟ್ರಾನ್ SDN ನಿಯಂತ್ರಕವಲ್ಲ ಎಂದು ತಕ್ಷಣವೇ ಸ್ಪಷ್ಟಪಡಿಸಬೇಕು.
ನ್ಯೂಟ್ರಾನ್ ಹಲವಾರು ಅಂತರ್ಸಂಪರ್ಕಿತ ಘಟಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:
ಓಪನ್‌ಸ್ಟಾಕ್-ನ್ಯೂಟ್ರಾನ್-ಸರ್ವರ್ API ಮೂಲಕ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಡೀಮನ್ ಆಗಿದೆ. ಈ ರಾಕ್ಷಸವು ಯಾವುದೇ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳನ್ನು ನೋಂದಾಯಿಸುವಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿಲ್ಲ, ಆದರೆ ಇದಕ್ಕಾಗಿ ಅಗತ್ಯವಾದ ಮಾಹಿತಿಯನ್ನು ಅದರ ಪ್ಲಗಿನ್‌ಗಳಿಗೆ ಒದಗಿಸುತ್ತದೆ, ಅದು ನಂತರ ಬಯಸಿದ ನೆಟ್ವರ್ಕ್ ಅಂಶವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ. ಓಪನ್‌ಸ್ಟ್ಯಾಕ್ ನೋಡ್‌ಗಳಲ್ಲಿನ ನ್ಯೂಟ್ರಾನ್ ಏಜೆಂಟ್‌ಗಳು ನ್ಯೂಟ್ರಾನ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ ನೋಂದಾಯಿಸಿಕೊಳ್ಳುತ್ತವೆ.
ನ್ಯೂಟ್ರಾನ್-ಸರ್ವರ್ ವಾಸ್ತವವಾಗಿ ಎರಡು ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪೈಥಾನ್‌ನಲ್ಲಿ ಬರೆಯಲಾದ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ:
- REST ಸೇವೆ
- ನ್ಯೂಟ್ರಾನ್ ಪ್ಲಗಿನ್ (ಕೋರ್/ಸೇವೆ)
REST ಸೇವೆಯನ್ನು ಇತರ ಘಟಕಗಳಿಂದ API ಕರೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ (ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುವ ವಿನಂತಿ, ಇತ್ಯಾದಿ.)
ಪ್ಲಗಿನ್‌ಗಳು API ವಿನಂತಿಗಳ ಸಮಯದಲ್ಲಿ ಕರೆಯಲಾಗುವ ಪ್ಲಗ್-ಇನ್ ಸಾಫ್ಟ್‌ವೇರ್ ಘಟಕಗಳು/ಮಾಡ್ಯೂಲ್‌ಗಳಾಗಿವೆ - ಅಂದರೆ, ಸೇವೆಯ ಗುಣಲಕ್ಷಣವು ಅವುಗಳ ಮೂಲಕ ಸಂಭವಿಸುತ್ತದೆ. ಪ್ಲಗಿನ್‌ಗಳನ್ನು ಎರಡು ವಿಧಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ - ಸೇವೆ ಮತ್ತು ಮೂಲ. ನಿಯಮದಂತೆ, ಕುದುರೆ ಪ್ಲಗಿನ್ ಮುಖ್ಯವಾಗಿ ವಿಳಾಸ ಸ್ಥಳ ಮತ್ತು VM ಗಳ ನಡುವಿನ L2 ಸಂಪರ್ಕಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಜವಾಬ್ದಾರವಾಗಿದೆ ಮತ್ತು ಸೇವಾ ಪ್ಲಗಿನ್‌ಗಳು ಈಗಾಗಲೇ VPN ಅಥವಾ FW ನಂತಹ ಹೆಚ್ಚುವರಿ ಕಾರ್ಯವನ್ನು ಒದಗಿಸುತ್ತವೆ.
ಇಂದು ಲಭ್ಯವಿರುವ ಪ್ಲಗಿನ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಉದಾಹರಣೆಗೆ ವೀಕ್ಷಿಸಬಹುದು
ಹಲವಾರು ಸೇವಾ ಪ್ಲಗಿನ್‌ಗಳು ಇರಬಹುದು, ಆದರೆ ಒಂದು ಕುದುರೆ ಪ್ಲಗಿನ್ ಮಾತ್ರ ಇರಬಹುದಾಗಿದೆ.
ಓಪನ್‌ಸ್ಟಾಕ್-ನ್ಯೂಟ್ರಾನ್-ಎಂಎಲ್2 ಪ್ರಮಾಣಿತ Openstack ರೂಟ್ ಪ್ಲಗಿನ್ ಆಗಿದೆ. ಈ ಪ್ಲಗಿನ್ ಮಾಡ್ಯುಲರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹೊಂದಿದೆ (ಅದರ ಪೂರ್ವವರ್ತಿಗಿಂತ ಭಿನ್ನವಾಗಿ) ಮತ್ತು ಅದರೊಂದಿಗೆ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಡ್ರೈವರ್‌ಗಳ ಮೂಲಕ ನೆಟ್ವರ್ಕ್ ಸೇವೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ. ನಾವು ಪ್ಲಗಿನ್ ಅನ್ನು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ನೋಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ವಾಸ್ತವವಾಗಿ ಇದು ನೆಟ್ವರ್ಕ್ ಭಾಗದಲ್ಲಿ ಓಪನ್‌ಸ್ಟ್ಯಾಕ್ ಹೊಂದಿರುವ ನಮ್ಯತೆಯನ್ನು ನೀಡುತ್ತದೆ. ರೂಟ್ ಪ್ಲಗಿನ್ ಅನ್ನು ಬದಲಾಯಿಸಬಹುದು (ಉದಾಹರಣೆಗೆ, ಕಾಂಟ್ರಾಲ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಅಂತಹ ಬದಲಿಯನ್ನು ಮಾಡುತ್ತದೆ).
RPC ಸೇವೆ (rabbitmq-ಸರ್ವರ್) — ಸರದಿ ನಿರ್ವಹಣೆ ಮತ್ತು ಇತರ OpenStack ಸೇವೆಗಳೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಒದಗಿಸುವ ಸೇವೆ, ಹಾಗೆಯೇ ನೆಟ್ವರ್ಕ್ ಸೇವಾ ಏಜೆಂಟ್‌ಗಳ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆ.
ನೆಟ್ವರ್ಕ್ ಏಜೆಂಟ್‌ಗಳು - ಪ್ರತಿ ನೋಡ್ನಲ್ಲಿ ಇರುವ ಏಜೆಂಟ್‌ಗಳು, ಅದರ ಮೂಲಕ ನೆಟ್ವರ್ಕ್ ಸೇವೆಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.
ಹಲವಾರು ವಿಧದ ಏಜೆಂಟ್ಗಳಿವೆ.
ಮುಖ್ಯ ಏಜೆಂಟ್ L2 ಏಜೆಂಟ್. ನಿಯಂತ್ರಣ ನೋಡ್‌ಗಳು (ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಬಾಡಿಗೆದಾರರಿಗೆ ಯಾವುದೇ ಸೇವೆಯನ್ನು ಒದಗಿಸುವ ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ) ಸೇರಿದಂತೆ ಪ್ರತಿಯೊಂದು ಹೈಪರ್ವೈಸರ್ಗಳ ಮೇಲೆ ಈ ಏಜೆಂಟ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಸಾಮಾನ್ಯ L2 ನೆಟ್ವರ್ಕ್ಗೆ ಸಂಪರ್ಕಿಸುವುದು ಮತ್ತು ಯಾವುದೇ ಘಟನೆಗಳು ಸಂಭವಿಸಿದಾಗ ಎಚ್ಚರಿಕೆಗಳನ್ನು ರಚಿಸುವುದು ಅವರ ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿದೆ ( ಉದಾಹರಣೆಗೆ ಪೋರ್ಟ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ/ಸಕ್ರಿಯಗೊಳಿಸಿ).
ಮುಂದಿನದು, ಕಡಿಮೆ ಮುಖ್ಯವಾದ ಏಜೆಂಟ್ L3 ಏಜೆಂಟ್. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಈ ಏಜೆಂಟ್ ಪ್ರತ್ಯೇಕವಾಗಿ ನೆಟ್ವರ್ಕ್ ನೋಡ್ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ (ಸಾಮಾನ್ಯವಾಗಿ ನೆಟ್ವರ್ಕ್ ನೋಡ್ ಅನ್ನು ಕಂಟ್ರೋಲ್ ನೋಡ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗುತ್ತದೆ) ಮತ್ತು ಬಾಡಿಗೆದಾರ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ನಡುವೆ ರೂಟಿಂಗ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ (ಅದರ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಇತರ ಬಾಡಿಗೆದಾರರ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ನಡುವೆ, ಮತ್ತು ಹೊರಗಿನ ಪ್ರಪಂಚಕ್ಕೆ ಪ್ರವೇಶಿಸಬಹುದು, ಒದಗಿಸುವುದು NAT, ಹಾಗೆಯೇ DHCP ಸೇವೆ). ಆದಾಗ್ಯೂ, DVR (ವಿತರಿಸಿದ ರೂಟರ್) ಅನ್ನು ಬಳಸುವಾಗ, L3 ಪ್ಲಗಿನ್‌ನ ಅಗತ್ಯವು ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ.
L3 ಏಜೆಂಟ್ ಲಿನಕ್ಸ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಪ್ರತಿ ಬಾಡಿಗೆದಾರರಿಗೆ ತನ್ನದೇ ಆದ ಪ್ರತ್ಯೇಕ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಒದಗಿಸಲು ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮಾರ್ಗಗೊಳಿಸುವ ಮತ್ತು ಲೇಯರ್ 2 ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ ಗೇಟ್ವೇ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವ ವರ್ಚುವಲ್ ರೂಟರ್‌ಗಳ ಕಾರ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಡೇಟಾಬೇಸ್ - ನೆಟ್‌ವರ್ಕ್‌ಗಳು, ಸಬ್‌ನೆಟ್‌ಗಳು, ಪೋರ್ಟ್‌ಗಳು, ಪೂಲ್‌ಗಳು ಇತ್ಯಾದಿಗಳ ಗುರುತಿಸುವಿಕೆಗಳ ಡೇಟಾಬೇಸ್.
ವಾಸ್ತವವಾಗಿ, ನ್ಯೂಟ್ರಾನ್ ಯಾವುದೇ ನೆಟ್ವರ್ಕ್ ಘಟಕಗಳ ರಚನೆಯಿಂದ API ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ವಿನಂತಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು RPC ಮೂಲಕ (ಇದು ಕೆಲವು ಪ್ಲಗಿನ್ ಅಥವಾ ಏಜೆಂಟ್ ಅನ್ನು ಪ್ರವೇಶಿಸಿದರೆ) ಅಥವಾ REST API (ಅದು SDN ನಲ್ಲಿ ಸಂವಹನ ನಡೆಸಿದರೆ) ಏಜೆಂಟ್‌ಗಳಿಗೆ (ಪ್ಲಗಿನ್‌ಗಳ ಮೂಲಕ) ರವಾನಿಸುತ್ತದೆ ವಿನಂತಿಸಿದ ಸೇವೆಯನ್ನು ಸಂಘಟಿಸಲು ಅಗತ್ಯವಾದ ಸೂಚನೆಗಳು.
ಈಗ ನಾವು ಪರೀಕ್ಷಾ ಸ್ಥಾಪನೆಗೆ ತಿರುಗೋಣ (ಅದನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಅದರಲ್ಲಿ ಏನು ಸೇರಿಸಲಾಗಿದೆ, ನಾವು ನಂತರ ಪ್ರಾಯೋಗಿಕ ಭಾಗದಲ್ಲಿ ನೋಡುತ್ತೇವೆ) ಮತ್ತು ಪ್ರತಿಯೊಂದು ಘಟಕವು ಎಲ್ಲಿದೆ ಎಂಬುದನ್ನು ನೋಡಿ:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
ವಾಸ್ತವವಾಗಿ, ಇದು ನ್ಯೂಟ್ರಾನ್ನ ಸಂಪೂರ್ಣ ರಚನೆಯಾಗಿದೆ. ಈಗ ML2 ಪ್ಲಗಿನ್‌ನಲ್ಲಿ ಸ್ವಲ್ಪ ಸಮಯವನ್ನು ಕಳೆಯುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
ಮಾಡ್ಯುಲರ್ ಲೇಯರ್ 2
ಮೇಲೆ ತಿಳಿಸಿದಂತೆ, ಪ್ಲಗಿನ್ ಪ್ರಮಾಣಿತ OpenStack ರೂಟ್ ಪ್ಲಗಿನ್ ಆಗಿದೆ ಮತ್ತು ಮಾಡ್ಯುಲರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹೊಂದಿದೆ.
ML2 ಪ್ಲಗಿನ್‌ನ ಪೂರ್ವವರ್ತಿಯು ಏಕಶಿಲೆಯ ರಚನೆಯನ್ನು ಹೊಂದಿತ್ತು, ಉದಾಹರಣೆಗೆ, ಒಂದು ಅನುಸ್ಥಾಪನೆಯಲ್ಲಿ ಹಲವಾರು ತಂತ್ರಜ್ಞಾನಗಳ ಮಿಶ್ರಣವನ್ನು ಬಳಸುವುದನ್ನು ಅನುಮತಿಸಲಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನೀವು openvswitch ಮತ್ತು linuxbridge ಎರಡನ್ನೂ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ - ಮೊದಲ ಅಥವಾ ಎರಡನೆಯದು. ಈ ಕಾರಣಕ್ಕಾಗಿ, ಅದರ ಆರ್ಕಿಟೆಕ್ಚರ್ನೊಂದಿಗೆ ML2 ಪ್ಲಗಿನ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ.
ML2 ಎರಡು ಘಟಕಗಳನ್ನು ಹೊಂದಿದೆ - ಎರಡು ರೀತಿಯ ಡ್ರೈವರ್‌ಗಳು: ಟೈಪ್ ಡ್ರೈವರ್‌ಗಳು ಮತ್ತು ಮೆಕ್ಯಾನಿಸಂ ಡ್ರೈವರ್‌ಗಳು.
ಟೈಪ್ ಡ್ರೈವರ್‌ಗಳು ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳನ್ನು ಸಂಘಟಿಸಲು ಬಳಸಲಾಗುವ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ನಿರ್ಧರಿಸಿ, ಉದಾಹರಣೆಗೆ VxLAN, VLAN, GRE. ಅದೇ ಸಮಯದಲ್ಲಿ, ಚಾಲಕ ವಿವಿಧ ತಂತ್ರಜ್ಞಾನಗಳ ಬಳಕೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಪ್ರಮಾಣಿತ ತಂತ್ರಜ್ಞಾನವು ಓವರ್‌ಲೇ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು vlan ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗಾಗಿ VxLAN ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಆಗಿದೆ.
ಟೈಪ್ ಡ್ರೈವರ್‌ಗಳು ಈ ಕೆಳಗಿನ ನೆಟ್ವರ್ಕ್ ಪ್ರಕಾರಗಳನ್ನು ಒಳಗೊಂಡಿವೆ:
ಫ್ಲಾಟ್ - ಟ್ಯಾಗ್ ಮಾಡದೆ ನೆಟ್ವರ್ಕ್
ವಿಎಲ್ಎಎನ್ - ಟ್ಯಾಗ್ ಮಾಡಿದ ನೆಟ್ವರ್ಕ್
ಸ್ಥಳೀಯ - ಆಲ್-ಇನ್-ಒನ್ ಸ್ಥಾಪನೆಗಳಿಗಾಗಿ ವಿಶೇಷ ರೀತಿಯ ನೆಟ್ವರ್ಕ್ (ಅಂತಹ ಸ್ಥಾಪನೆಗಳು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅಥವಾ ತರಬೇತಿಗಾಗಿ ಅಗತ್ಯವಿದೆ)
GRE - ಜಿಆರ್‌ಇ ಸುರಂಗಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅತಿಕ್ರಮಣ ಜಾಲ
VxLAN - VxLAN ಸುರಂಗಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅತಿಕ್ರಮಣ ಜಾಲ
ಯಾಂತ್ರಿಕ ಚಾಲಕರು ಟೈಪ್ ಡ್ರೈವರ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ತಂತ್ರಜ್ಞಾನಗಳ ಸಂಘಟನೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಪರಿಕರಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ - ಉದಾಹರಣೆಗೆ, openvswitch, sr-iov, opendaylight, OVN, ಇತ್ಯಾದಿ.
ಈ ಡ್ರೈವರ್‌ನ ಅನುಷ್ಠಾನವನ್ನು ಅವಲಂಬಿಸಿ, ನ್ಯೂಟ್ರಾನ್‌ನಿಂದ ನಿಯಂತ್ರಿಸಲ್ಪಡುವ ಏಜೆಂಟ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಅಥವಾ ಬಾಹ್ಯ SDN ನಿಯಂತ್ರಕಕ್ಕೆ ಸಂಪರ್ಕಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇದು L2 ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಸಂಘಟಿಸಲು, ರೂಟಿಂಗ್ ಇತ್ಯಾದಿಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳನ್ನು ನೋಡಿಕೊಳ್ಳುತ್ತದೆ.
ಉದಾಹರಣೆ: ನಾವು OVS ಜೊತೆಗೆ ML2 ಅನ್ನು ಬಳಸಿದರೆ, OVS ಅನ್ನು ನಿರ್ವಹಿಸುವ ಪ್ರತಿಯೊಂದು ಕಂಪ್ಯೂಟಿಂಗ್ ನೋಡ್ನಲ್ಲಿ L2 ಏಜೆಂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ನಾವು ಬಳಸಿದರೆ, ಉದಾಹರಣೆಗೆ, OVN ಅಥವಾ OpenDayLight, ನಂತರ OVS ನ ನಿಯಂತ್ರಣವು ಅವರ ವ್ಯಾಪ್ತಿಗೆ ಬರುತ್ತದೆ - ನ್ಯೂಟ್ರಾನ್, ರೂಟ್ ಪ್ಲಗಿನ್ ಮೂಲಕ, ನಿಯಂತ್ರಕಕ್ಕೆ ಆಜ್ಞೆಗಳನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಅದು ಈಗಾಗಲೇ ಹೇಳಿದ್ದನ್ನು ಮಾಡುತ್ತದೆ.
ಓಪನ್ vSwitch ನಲ್ಲಿ ಬ್ರಶ್ ಅಪ್ ಮಾಡೋಣ
ಈ ಸಮಯದಲ್ಲಿ, OpenStack ನ ಪ್ರಮುಖ ಅಂಶಗಳಲ್ಲಿ ಒಂದು ಓಪನ್ vSwitch ಆಗಿದೆ.
ಜುನಿಪರ್ ಕಾಂಟ್ರೇಲ್ ಅಥವಾ ನೋಕಿಯಾ ನುಯೇಜ್‌ನಂತಹ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಮಾರಾಟಗಾರ SDN ಇಲ್ಲದೆ OpenStack ಅನ್ನು ಸ್ಥಾಪಿಸುವಾಗ, OVS ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕ್‌ನ ಮುಖ್ಯ ನೆಟ್ವರ್ಕ್ ಘಟಕವಾಗಿದೆ ಮತ್ತು iptables, conntrack, namespaces ಜೊತೆಗೆ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಬಹು-ಬಾಡಿಗೆ ಓವರ್‌ಲೇ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಸಂಘಟಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನೈಸರ್ಗಿಕವಾಗಿ, ಈ ಘಟಕವನ್ನು ಬದಲಾಯಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸ್ವಾಮ್ಯದ (ಮಾರಾಟಗಾರ) SDN ಪರಿಹಾರಗಳನ್ನು ಬಳಸುವಾಗ.
OVS ಒಂದು ಮುಕ್ತ ಮೂಲ ಸಾಫ್ಟ್‌ವೇರ್ ಸ್ವಿಚ್ ಆಗಿದ್ದು, ಇದನ್ನು ವರ್ಚುವಲ್ ಟ್ರಾಫಿಕ್ ಫಾರ್ವರ್ಡ್‌ನಂತೆ ವರ್ಚುವಲೈಸ್ಡ್ ಪರಿಸರದಲ್ಲಿ ಬಳಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.
ಈ ಸಮಯದಲ್ಲಿ, OVS ಬಹಳ ಯೋಗ್ಯವಾದ ಕಾರ್ಯವನ್ನು ಹೊಂದಿದೆ, ಇದು QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, ಇತ್ಯಾದಿ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.
ಗಮನಿಸಿ: OVS ಅನ್ನು ಆರಂಭದಲ್ಲಿ ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ಟೆಲಿಕಾಂ ಕಾರ್ಯಗಳಿಗಾಗಿ ಸಾಫ್ಟ್ ಸ್ವಿಚ್ ಆಗಿ ಕಲ್ಪಿಸಲಾಗಿಲ್ಲ ಮತ್ತು WEB ಸರ್ವರ್ ಅಥವಾ ಮೇಲ್ ಸರ್ವರ್‌ನಂತಹ ಕಡಿಮೆ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್-ಬೇಡಿಕೆ IT ಕಾರ್ಯಗಳಿಗಾಗಿ ಹೆಚ್ಚು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, OVS ಅನ್ನು ಮತ್ತಷ್ಟು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗುತ್ತಿದೆ ಮತ್ತು OVS ನ ಪ್ರಸ್ತುತ ಅಳವಡಿಕೆಗಳು ಅದರ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೆಚ್ಚು ಸುಧಾರಿಸಿದೆ, ಇದು ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ಕಾರ್ಯಗಳೊಂದಿಗೆ ಟೆಲಿಕಾಂ ಆಪರೇಟರ್‌ಗಳಿಂದ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, DPDK ವೇಗವರ್ಧನೆಗೆ ಬೆಂಬಲದೊಂದಿಗೆ OVS ಅನುಷ್ಠಾನವಿದೆ.
ನೀವು ತಿಳಿದಿರಬೇಕಾದ OVS ನ ಮೂರು ಪ್ರಮುಖ ಅಂಶಗಳಿವೆ:
- ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ - ನಿಯಂತ್ರಣ ಅಂಶದಿಂದ ಪಡೆದ ನಿಯಮಗಳ ಆಧಾರದ ಮೇಲೆ ಸಂಚಾರವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಕರ್ನಲ್ ಜಾಗದಲ್ಲಿ ಇರುವ ಒಂದು ಘಟಕ;
- vSwitch ಡೀಮನ್ (ovs-vswitchd) ಎನ್ನುವುದು ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮಾಡಲು ಜವಾಬ್ದಾರರಾಗಿರುವ ಬಳಕೆದಾರರ ಜಾಗದಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾದ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ - ಅಂದರೆ, ಇದು ಸ್ವಿಚ್ ಕಾರ್ಯಾಚರಣೆಯ ತರ್ಕವನ್ನು ನೇರವಾಗಿ ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
- ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ - OVS ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರತಿ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯ ಡೇಟಾಬೇಸ್ ಇದೆ, ಇದರಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. SDN ನಿಯಂತ್ರಕಗಳು OVSDB ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಮಾಡ್ಯೂಲ್ ಮೂಲಕ ಸಂವಹನ ಮಾಡಬಹುದು.
ಇದೆಲ್ಲವೂ ovs-vsctl, ovs-appctl, ovs-ofctl, ಇತ್ಯಾದಿಗಳಂತಹ ರೋಗನಿರ್ಣಯ ಮತ್ತು ನಿರ್ವಹಣಾ ಉಪಯುಕ್ತತೆಗಳ ಗುಂಪಿನೊಂದಿಗೆ ಇರುತ್ತದೆ.
ಪ್ರಸ್ತುತ, Openstack ಅನ್ನು EPC, SBC, HLR, ಇತ್ಯಾದಿಗಳಂತಹ ನೆಟ್ವರ್ಕ್ ಕಾರ್ಯಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ಟೆಲಿಕಾಂ ಆಪರೇಟರ್‌ಗಳು ವ್ಯಾಪಕವಾಗಿ ಬಳಸುತ್ತಾರೆ. ಕೆಲವು ಕಾರ್ಯಗಳು OVS ನೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಬದುಕಬಲ್ಲವು, ಆದರೆ ಉದಾಹರಣೆಗೆ, EPC ಚಂದಾದಾರರ ದಟ್ಟಣೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ - ನಂತರ ಅದು ಹಾದುಹೋಗುತ್ತದೆ. ಬೃಹತ್ ಪ್ರಮಾಣದ ದಟ್ಟಣೆ (ಈಗ ಸಂಚಾರ ಪ್ರಮಾಣಗಳು ಸೆಕೆಂಡಿಗೆ ನೂರಾರು ಗಿಗಾಬಿಟ್‌ಗಳನ್ನು ತಲುಪುತ್ತವೆ). ಸ್ವಾಭಾವಿಕವಾಗಿ, ಅಂತಹ ದಟ್ಟಣೆಯನ್ನು ಕರ್ನಲ್ ಜಾಗದ ಮೂಲಕ ಚಾಲನೆ ಮಾಡುವುದು (ಫಾರ್ವರ್ಡ್ ಮಾಡುವವರು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅಲ್ಲಿಯೇ ಇರುವುದರಿಂದ) ಉತ್ತಮ ಉಪಾಯವಲ್ಲ. ಆದ್ದರಿಂದ, OVS ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ DPDK ವೇಗವರ್ಧನೆ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಕರ್ನಲ್ ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ಮೂಲಕ NIC ಯಿಂದ ಬಳಕೆದಾರರ ಜಾಗಕ್ಕೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಬಳಕೆದಾರರ ಜಾಗದಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ.
ಗಮನಿಸಿ: ಟೆಲಿಕಾಂ ಕಾರ್ಯಗಳಿಗಾಗಿ ನಿಯೋಜಿಸಲಾದ ಕ್ಲೌಡ್‌ಗಾಗಿ, OVS ಅನ್ನು ನೇರವಾಗಿ ಸ್ವಿಚಿಂಗ್ ಉಪಕರಣಗಳಿಗೆ ಬೈಪಾಸ್ ಮಾಡುವ ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ನಿಂದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಔಟ್ಪುಟ್ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ SR-IOV ಮತ್ತು ಪಾಸ್‌ಥ್ರೂ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ನಿಜವಾದ ವಿನ್ಯಾಸದಲ್ಲಿ ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?
ಸರಿ, ಈಗ ಪ್ರಾಯೋಗಿಕ ಭಾಗಕ್ಕೆ ಹೋಗೋಣ ಮತ್ತು ಆಚರಣೆಯಲ್ಲಿ ಎಲ್ಲವೂ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.
ಮೊದಲಿಗೆ, ಸರಳವಾದ Openstack ಅನುಸ್ಥಾಪನೆಯನ್ನು ನಿಯೋಜಿಸೋಣ. ಪ್ರಯೋಗಗಳಿಗಾಗಿ ನನ್ನ ಬಳಿ ಸರ್ವರ್‌ಗಳ ಸೆಟ್ ಇಲ್ಲದಿರುವುದರಿಂದ, ನಾವು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಂದ ಒಂದು ಭೌತಿಕ ಸರ್ವರ್‌ನಲ್ಲಿ ಮೂಲಮಾದರಿಯನ್ನು ಜೋಡಿಸುತ್ತೇವೆ. ಹೌದು, ನೈಸರ್ಗಿಕವಾಗಿ, ಅಂತಹ ಪರಿಹಾರವು ವಾಣಿಜ್ಯ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಸೂಕ್ತವಲ್ಲ, ಆದರೆ ಓಪನ್ಸ್ಟ್ಯಾಕ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಉದಾಹರಣೆಯನ್ನು ನೋಡಲು, ಅಂತಹ ಅನುಸ್ಥಾಪನೆಯು ಕಣ್ಣುಗಳಿಗೆ ಸಾಕು. ಇದಲ್ಲದೆ, ಅಂತಹ ಅನುಸ್ಥಾಪನೆಯು ತರಬೇತಿ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಇನ್ನಷ್ಟು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ - ನೀವು ಸಂಚಾರವನ್ನು ಹಿಡಿಯಬಹುದು, ಇತ್ಯಾದಿ.
ನಾವು ಮೂಲಭೂತ ಭಾಗವನ್ನು ಮಾತ್ರ ನೋಡಬೇಕಾಗಿರುವುದರಿಂದ, ನಾವು ಹಲವಾರು ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ ಆದರೆ ಕೇವಲ ಎರಡು ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲವನ್ನೂ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಈ ಲೇಔಟ್‌ನಲ್ಲಿರುವ ಎರಡನೇ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಅಂಡರ್ಕ್ಲೌಡ್ ಮತ್ತು ಡಿಎನ್‌ಎಸ್ ಸರ್ವರ್‌ಗೆ ಪ್ರವೇಶಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ನಾವು ಇದೀಗ ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ - ಇದು ಪ್ರತ್ಯೇಕ ದೊಡ್ಡ ಲೇಖನಕ್ಕಾಗಿ ವಿಷಯವಾಗಿದೆ.
ಆದ್ದರಿಂದ, ಕ್ರಮವಾಗಿ ಪ್ರಾರಂಭಿಸೋಣ. ಮೊದಲಿಗೆ, ಸ್ವಲ್ಪ ಸಿದ್ಧಾಂತ. ನಾವು ಟ್ರಿಪಲ್ ಓ (ಓಪನ್‌ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಓಪನ್‌ಸ್ಟಾಕ್) ಬಳಸಿಕೊಂಡು ಓಪನ್‌ಸ್ಟಾಕ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ. TripleO ಯ ಮೂಲತತ್ವವೆಂದರೆ ನಾವು ಅಂಡರ್ಕ್ಲೌಡ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಓಪನ್‌ಸ್ಟಾಕ್ ಆಲ್-ಇನ್-ಒನ್ (ಅಂದರೆ ಒಂದು ನೋಡ್ನಲ್ಲಿ) ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಓವರ್ಕ್ಲೌಡ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಕಾರ್ಯಾಚರಣೆಗೆ ಉದ್ದೇಶಿಸಿರುವ ಓಪನ್‌ಸ್ಟಾಕ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ನಿಯೋಜಿಸಲಾದ ಓಪನ್‌ಸ್ಟಾಕ್‌ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಬಳಸುತ್ತೇವೆ. ಅಂಡರ್ಕ್ಲೌಡ್ ಭೌತಿಕ ಸರ್ವರ್‌ಗಳನ್ನು (ಬೇರ್ ಮೆಟಲ್) ನಿರ್ವಹಿಸಲು ಅದರ ಅಂತರ್ಗತ ಸಾಮರ್ಥ್ಯವನ್ನು ಬಳಸುತ್ತದೆ - ಐರೋನಿಕ್ ಪ್ರಾಜೆಕ್ಟ್ - ಕಂಪ್ಯೂಟ್, ಕಂಟ್ರೋಲ್, ಸ್ಟೋರೇಜ್ ನೋಡ್ಗಳ ಪಾತ್ರಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಹೈಪರ್‌ವೈಸರ್‌ಗಳನ್ನು ಒದಗಿಸಲು. ಅಂದರೆ, Openstack ಅನ್ನು ನಿಯೋಜಿಸಲು ನಾವು ಯಾವುದೇ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಾಧನಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ - ನಾವು Openstack ಅನ್ನು ಬಳಸಿಕೊಂಡು Openstack ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ. ಅನುಸ್ಥಾಪನೆಯು ಮುಂದುವರೆದಂತೆ ಇದು ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಅಲ್ಲಿ ನಿಲ್ಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ಮುಂದುವರಿಯುವುದಿಲ್ಲ.
ಗಮನಿಸಿ: ಈ ಲೇಖನದಲ್ಲಿ, ಸರಳತೆಗಾಗಿ, ನಾನು ಆಂತರಿಕ ಓಪನ್‌ಸ್ಟಾಕ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗಾಗಿ ನೆಟ್ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಬಳಸಲಿಲ್ಲ, ಆದರೆ ಎಲ್ಲವನ್ನೂ ಒಂದೇ ನೆಟ್ವರ್ಕ್ ಬಳಸಿ ನಿಯೋಜಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ನೆಟ್ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆಯ ಉಪಸ್ಥಿತಿ ಅಥವಾ ಅನುಪಸ್ಥಿತಿಯು ಪರಿಹಾರದ ಮೂಲಭೂತ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ - ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಬಳಸುವಾಗ ಎಲ್ಲವೂ ನಿಖರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಅದೇ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಹರಿಯುತ್ತದೆ. ವಾಣಿಜ್ಯ ಸ್ಥಾಪನೆಗಾಗಿ, ವಿಭಿನ್ನ vlans ಮತ್ತು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಬಳಸುವುದು ಸ್ವಾಭಾವಿಕವಾಗಿ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ceph ಸ್ಟೋರೇಜ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಟ್ರಾಫಿಕ್ ಮತ್ತು ಡೇಟಾ ಟ್ರಾಫಿಕ್ ಸ್ವತಃ (ಡಿಸ್ಕ್‌ಗಳಿಗೆ ಯಂತ್ರ ಪ್ರವೇಶ, ಇತ್ಯಾದಿ) ವಿಭಿನ್ನ ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು (ಶೇಖರಣಾ ನಿರ್ವಹಣೆ ಮತ್ತು ಸಂಗ್ರಹಣೆ) ಬಳಸುತ್ತದೆ ಮತ್ತು ಇದು ಈ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿಭಜಿಸುವ ಮೂಲಕ ಪರಿಹಾರವನ್ನು ಹೆಚ್ಚು ದೋಷ-ಸಹಿಷ್ಣುಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ. , ವಿಭಿನ್ನ ಪೋರ್ಟ್‌ಗಳಾದ್ಯಂತ ಅಥವಾ ವಿಭಿನ್ನ ಟ್ರಾಫಿಕ್‌ಗಾಗಿ ವಿಭಿನ್ನ QoS ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಬಳಸುವುದರಿಂದ ಡೇಟಾ ಟ್ರಾಫಿಕ್ ಸಿಗ್ನಲಿಂಗ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹಿಂಡುವುದಿಲ್ಲ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಅವರು ಒಂದೇ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಹೋಗುತ್ತಾರೆ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಇದು ನಮ್ಮನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಮಿತಿಗೊಳಿಸುವುದಿಲ್ಲ.
ಗಮನಿಸಿ: ನಾವು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ಆಧಾರದ ಮೇಲೆ ವರ್ಚುವಲ್ ಪರಿಸರದಲ್ಲಿ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಚಲಾಯಿಸಲಿರುವುದರಿಂದ, ನಾವು ಮೊದಲು ನೆಸ್ಟೆಡ್ ವರ್ಚುವಲೈಸೇಶನ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕಾಗಿದೆ.
ನೆಸ್ಟೆಡ್ ವರ್ಚುವಲೈಸೇಶನ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ಈ ರೀತಿ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ನೀವು ಪರಿಶೀಲಿಸಬಹುದು:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#ನೀವು N ಅಕ್ಷರವನ್ನು ನೋಡಿದರೆ, ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ನೀವು ಕಂಡುಕೊಳ್ಳುವ ಯಾವುದೇ ಮಾರ್ಗದರ್ಶಿಯ ಪ್ರಕಾರ ನೆಸ್ಟೆಡ್ ವರ್ಚುವಲೈಸೇಶನ್‌ಗೆ ನಾವು ಬೆಂಬಲವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ .
ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಂದ ನಾವು ಈ ಕೆಳಗಿನ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಜೋಡಿಸಬೇಕಾಗಿದೆ:
ನನ್ನ ಸಂದರ್ಭದಲ್ಲಿ, ಭವಿಷ್ಯದ ಅನುಸ್ಥಾಪನೆಯ ಭಾಗವಾಗಿರುವ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು (ಮತ್ತು ನಾನು ಅವುಗಳಲ್ಲಿ 7 ಅನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇನೆ, ಆದರೆ ನೀವು ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ನೀವು 4 ಮೂಲಕ ಪಡೆಯಬಹುದು), ನಾನು OpenvSwitch ಅನ್ನು ಬಳಸಿದ್ದೇನೆ. ನಾನು ಒಂದು ovs ಸೇತುವೆಯನ್ನು ರಚಿಸಿದೆ ಮತ್ತು ಪೋರ್ಟ್-ಗುಂಪುಗಳ ಮೂಲಕ ಅದಕ್ಕೆ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಸಂಪರ್ಕಿಸಿದೆ. ಇದನ್ನು ಮಾಡಲು, ನಾನು ಈ ರೀತಿಯ xml ಫೈಲ್ ಅನ್ನು ರಚಿಸಿದೆ:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>ಮೂರು ಪೋರ್ಟ್ ಗುಂಪುಗಳನ್ನು ಇಲ್ಲಿ ಘೋಷಿಸಲಾಗಿದೆ - ಎರಡು ಪ್ರವೇಶ ಮತ್ತು ಒಂದು ಟ್ರಂಕ್ (ಎರಡನೆಯದು DNS ಸರ್ವರ್‌ಗೆ ಅಗತ್ಯವಾಗಿತ್ತು, ಆದರೆ ನೀವು ಅದನ್ನು ಇಲ್ಲದೆ ಮಾಡಬಹುದು, ಅಥವಾ ಅದನ್ನು ಹೋಸ್ಟ್ ಯಂತ್ರದಲ್ಲಿ ಸ್ಥಾಪಿಸಬಹುದು - ಯಾವುದು ನಿಮಗೆ ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ). ಮುಂದೆ, ಈ ಟೆಂಪ್ಲೇಟ್ ಬಳಸಿ, ನಾವು ನಮ್ಮದನ್ನು ವಿರ್ಶ್ ನೆಟ್-ಡಿಫೈನ್ ಮೂಲಕ ಘೋಷಿಸುತ್ತೇವೆ:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 ಈಗ ನಾವು ಹೈಪರ್ವೈಸರ್ ಪೋರ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಸಂಪಾದಿಸುತ್ತೇವೆ:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# ಗಮನಿಸಿ: ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ, ಪೋರ್ಟ್ ovs-br1 ನಲ್ಲಿ ವಿಳಾಸವನ್ನು ಪ್ರವೇಶಿಸಲಾಗುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಅದು vlan ಟ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ. ಇದನ್ನು ಸರಿಪಡಿಸಲು, ನೀವು sudo ovs-vsctl ಸೆಟ್ ಪೋರ್ಟ್ ovs-br1 ಟ್ಯಾಗ್=100 ಆಜ್ಞೆಯನ್ನು ನೀಡಬೇಕಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ, ಈ ಟ್ಯಾಗ್ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ (ಯಾರಾದರೂ ಅದನ್ನು ಸ್ಥಳದಲ್ಲಿ ಉಳಿಯಲು ಹೇಗೆ ತಿಳಿದಿದ್ದರೆ, ನಾನು ತುಂಬಾ ಕೃತಜ್ಞರಾಗಿರುತ್ತೇನೆ). ಆದರೆ ಇದು ಅಷ್ಟು ಮುಖ್ಯವಲ್ಲ, ಏಕೆಂದರೆ ಅನುಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ ನಮಗೆ ಈ ವಿಳಾಸದ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಓಪನ್‌ಸ್ಟಾಕ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಯೋಜಿಸಿದಾಗ ಅದು ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ಮುಂದೆ, ನಾವು ಅಂಡರ್ಕ್ಲೌಡ್ ಯಂತ್ರವನ್ನು ರಚಿಸುತ್ತೇವೆ:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0ಅನುಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ, ನೀವು ಯಂತ್ರದ ಹೆಸರು, ಪಾಸ್‌ವರ್ಡ್‌ಗಳು, ಬಳಕೆದಾರರು, ಎನ್‌ಟಿಪಿ ಸರ್ವರ್‌ಗಳು ಮುಂತಾದ ಎಲ್ಲಾ ಅಗತ್ಯ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿಸಿ, ನೀವು ತಕ್ಷಣ ಪೋರ್ಟ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು, ಆದರೆ ನನಗೆ ವೈಯಕ್ತಿಕವಾಗಿ, ಅನುಸ್ಥಾಪನೆಯ ನಂತರ, ಯಂತ್ರಕ್ಕೆ ಲಾಗ್ ಇನ್ ಮಾಡುವುದು ಸುಲಭವಾಗಿದೆ. ಕನ್ಸೋಲ್ ಮತ್ತು ಅಗತ್ಯ ಫೈಲ್‌ಗಳನ್ನು ಸರಿಪಡಿಸಿ. ನೀವು ಈಗಾಗಲೇ ಸಿದ್ಧ-ಸಿದ್ಧ ಚಿತ್ರವನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಬಳಸಬಹುದು, ಅಥವಾ ನಾನು ಮಾಡಿದ್ದನ್ನು ಮಾಡಿ - ಕನಿಷ್ಠ Centos 7 ಚಿತ್ರವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು VM ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಅದನ್ನು ಬಳಸಿ.
ಯಶಸ್ವಿ ಅನುಸ್ಥಾಪನೆಯ ನಂತರ, ನೀವು ಅಂಡರ್ಕ್ಲೌಡ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬಹುದಾದ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಹೊಂದಿರಬೇಕು
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningಮೊದಲಿಗೆ, ಅನುಸ್ಥಾಪನಾ ಪ್ರಕ್ರಿಯೆಗೆ ಅಗತ್ಯವಾದ ಸಾಧನಗಳನ್ನು ಸ್ಥಾಪಿಸಿ:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
ಅಂಡರ್ಕ್ಲೌಡ್ ಸ್ಥಾಪನೆ
ನಾವು ಸ್ಟಾಕ್ ಬಳಕೆದಾರರನ್ನು ರಚಿಸುತ್ತೇವೆ, ಪಾಸ್ವರ್ಡ್ ಹೊಂದಿಸುತ್ತೇವೆ, ಅದನ್ನು ಸುಡೋಯರ್‌ಗೆ ಸೇರಿಸುತ್ತೇವೆ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ನಮೂದಿಸದೆಯೇ ಸುಡೋ ಮೂಲಕ ರೂಟ್ ಆಜ್ಞೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಅವರಿಗೆ ನೀಡುತ್ತೇವೆ:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackಈಗ ನಾವು ಹೋಸ್ಟ್‌ಗಳ ಫೈಲ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣ ಅಂಡರ್ಕ್ಲೌಡ್ ಹೆಸರನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6ಮುಂದೆ, ನಾವು ರೆಪೊಸಿಟರಿಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಮತ್ತು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleಗಮನಿಸಿ: ನೀವು ceph ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಯೋಜಿಸದಿದ್ದರೆ, ನೀವು ceph-ಸಂಬಂಧಿತ ಆಜ್ಞೆಗಳನ್ನು ನಮೂದಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ನಾನು ಕ್ವೀನ್ಸ್ ಬಿಡುಗಡೆಯನ್ನು ಬಳಸಿದ್ದೇನೆ, ಆದರೆ ನೀವು ಇಷ್ಟಪಡುವ ಯಾವುದನ್ನಾದರೂ ನೀವು ಬಳಸಬಹುದು.
ಮುಂದೆ, ಅಂಡರ್ಕ್ಲೌಡ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಬಳಕೆದಾರರ ಹೋಮ್ ಡೈರೆಕ್ಟರಿ ಸ್ಟಾಕ್‌ಗೆ ನಕಲಿಸಿ:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confಈಗ ನಾವು ಈ ಫೈಲ್ ಅನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ, ಅದನ್ನು ನಮ್ಮ ಅನುಸ್ಥಾಪನೆಗೆ ಹೊಂದಿಸಿ.
ಫೈಲ್‌ನ ಪ್ರಾರಂಭಕ್ಕೆ ನೀವು ಈ ಸಾಲುಗಳನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10ಆದ್ದರಿಂದ, ಸೆಟ್ಟಿಂಗ್ಗಳ ಮೂಲಕ ಹೋಗೋಣ:
undercloud_hostname — ಅಂಡರ್ಕ್ಲೌಡ್ ಸರ್ವರ್‌ನ ಪೂರ್ಣ ಹೆಸರು, DNS ಸರ್ವರ್‌ನಲ್ಲಿನ ನಮೂದನ್ನು ಹೊಂದಿಕೆಯಾಗಬೇಕು
ಲೋಕಲ್_ಐಪಿ - ನೆಟ್ವರ್ಕ್ ಒದಗಿಸುವಿಕೆಯ ಕಡೆಗೆ ಸ್ಥಳೀಯ ಅಂಡರ್ಕ್ಲೌಡ್ ವಿಳಾಸ
ನೆಟ್ವರ್ಕ್_ಗೇಟ್ವೇ — ಅದೇ ಸ್ಥಳೀಯ ವಿಳಾಸ, ಓವರ್ಕ್ಲೌಡ್ ನೋಡ್ಗಳ ಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ ಹೊರಗಿನ ಪ್ರಪಂಚಕ್ಕೆ ಪ್ರವೇಶಕ್ಕಾಗಿ ಗೇಟ್ವೇ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಸ್ಥಳೀಯ ಐಪಿಯೊಂದಿಗೆ ಸೇರಿಕೊಳ್ಳುತ್ತದೆ
undercloud_public_host - ಬಾಹ್ಯ API ವಿಳಾಸ, ಒದಗಿಸುವ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಯಾವುದೇ ಉಚಿತ ವಿಳಾಸವನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ
undercloud_admin_host ಆಂತರಿಕ API ವಿಳಾಸ, ಒದಗಿಸುವ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಯಾವುದೇ ಉಚಿತ ವಿಳಾಸವನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ
undercloud_nameservers - DNS ಸರ್ವರ್
ಜನರೇಟ್_ಸೇವೆ_ಪ್ರಮಾಣಪತ್ರ - ಪ್ರಸ್ತುತ ಉದಾಹರಣೆಯಲ್ಲಿ ಈ ಸಾಲು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ನೀವು ಅದನ್ನು ತಪ್ಪಾಗಿ ಹೊಂದಿಸದಿದ್ದರೆ ಅನುಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ ನೀವು ದೋಷವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ, ಸಮಸ್ಯೆಯನ್ನು Red Hat ಬಗ್ ಟ್ರ್ಯಾಕರ್‌ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ
ಸ್ಥಳೀಯ_ಇಂಟರ್ಫೇಸ್ ನೆಟ್ವರ್ಕ್ ಒದಗಿಸುವಿಕೆಯಲ್ಲಿ ಇಂಟರ್ಫೇಸ್. ಅಂಡರ್ಕ್ಲೌಡ್ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಈ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಮರುಸಂರಚಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಅಂಡರ್‌ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಎರಡು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಹೊಂದಿರಬೇಕು - ಒಂದು ಅದನ್ನು ಪ್ರವೇಶಿಸಲು, ಎರಡನೆಯದು ಒದಗಿಸುವುದಕ್ಕಾಗಿ
ಸ್ಥಳೀಯ_ಎಂಟು - MTU. ನಾವು ಪರೀಕ್ಷಾ ಪ್ರಯೋಗಾಲಯವನ್ನು ಹೊಂದಿರುವುದರಿಂದ ಮತ್ತು OVS ಸ್ವಿಚ್‌ನ ಪೋರ್ಟ್‌ಗಳಲ್ಲಿ ನಾನು 1500 MTU ಅನ್ನು ಹೊಂದಿರುವುದರಿಂದ, VxLAN ನಲ್ಲಿ ಸುತ್ತುವರಿದ ಪ್ಯಾಕೆಟ್‌ಗಳು ಹಾದುಹೋಗಲು ಅದನ್ನು 1450 ಗೆ ಹೊಂದಿಸುವುದು ಅವಶ್ಯಕ.
ನೆಟ್ವರ್ಕ್_ಸಿಡ್ರ್ - ಒದಗಿಸುವ ಜಾಲ
ಮಾಸ್ಕ್ವೆರೇಡ್ - ಬಾಹ್ಯ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು NAT ಅನ್ನು ಬಳಸುವುದು
ಮಾಸ್ಕ್ವೆರೇಡ್_ನೆಟ್ವರ್ಕ್ - ನೆಟ್ವರ್ಕ್ ಅನ್ನು NAT ಮಾಡಲಾಗುವುದು
dhcp_start - ಓವರ್ಕ್ಲೌಡ್ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ನೋಡ್‌ಗಳಿಗೆ ವಿಳಾಸಗಳನ್ನು ನಿಯೋಜಿಸಲಾಗುವ ವಿಳಾಸ ಪೂಲ್‌ನ ಆರಂಭಿಕ ವಿಳಾಸ
dhcp_end - ಓವರ್ಕ್ಲೌಡ್ ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ನೋಡ್‌ಗಳಿಗೆ ವಿಳಾಸಗಳನ್ನು ನಿಯೋಜಿಸಲಾಗುವ ವಿಳಾಸ ಪೂಲ್‌ನ ಅಂತಿಮ ವಿಳಾಸ
ತಪಾಸಣೆ_ಪ್ರದೇಶ - ಆತ್ಮಾವಲೋಕನಕ್ಕೆ ಅಗತ್ಯವಾದ ವಿಳಾಸಗಳ ಪೂಲ್ (ಮೇಲಿನ ಪೂಲ್‌ನೊಂದಿಗೆ ಅತಿಕ್ರಮಿಸಬಾರದು)
ವೇಳಾಪಟ್ಟಿ_ಗರಿಷ್ಠ_ಪ್ರಯತ್ನಗಳು - ಓವರ್ಕ್ಲೌಡ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಪ್ರಯತ್ನಗಳು (ನೋಡ್ಗಳ ಸಂಖ್ಯೆಗಿಂತ ಹೆಚ್ಚಾಗಿರಬೇಕು ಅಥವಾ ಸಮನಾಗಿರಬೇಕು)
ಫೈಲ್ ಅನ್ನು ವಿವರಿಸಿದ ನಂತರ, ನೀವು ಅಂಡರ್ಕ್ಲೌಡ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಆಜ್ಞೆಯನ್ನು ನೀಡಬಹುದು:
openstack undercloud install
ನಿಮ್ಮ ಕಬ್ಬಿಣವನ್ನು ಅವಲಂಬಿಸಿ ಕಾರ್ಯವಿಧಾನವು 10 ರಿಂದ 30 ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅಂತಿಮವಾಗಿ ನೀವು ಈ ರೀತಿಯ ಔಟ್ಪುಟ್ ಅನ್ನು ನೋಡಬೇಕು:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################ನೀವು ಅಂಡರ್ಕ್ಲೌಡ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಸ್ಥಾಪಿಸಿದ್ದೀರಿ ಎಂದು ಈ ಔಟ್ಪುಟ್ ಹೇಳುತ್ತದೆ ಮತ್ತು ನೀವು ಈಗ ಅಂಡರ್‌ಕ್ಲೌಡ್‌ನ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಓವರ್ಕ್ಲೌಡ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಮುಂದುವರಿಯಬಹುದು.
ನೀವು ifconfig ಔಟ್ಪುಟ್ ಅನ್ನು ನೋಡಿದರೆ, ಹೊಸ ಸೇತುವೆ ಇಂಟರ್ಫೇಸ್ ಕಾಣಿಸಿಕೊಂಡಿದೆ ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0ಓವರ್ಕ್ಲೌಡ್ ನಿಯೋಜನೆಯನ್ನು ಈಗ ಈ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.
ಕೆಳಗಿನ ಔಟ್ಪುಟ್ನಿಂದ ನಾವು ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಒಂದೇ ನೋಡ್ನಲ್ಲಿ ಹೊಂದಿದ್ದೇವೆ ಎಂದು ನೀವು ನೋಡಬಹುದು:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+ಅಂಡರ್ಕ್ಲೌಡ್ ನೆಟ್ವರ್ಕ್ ಭಾಗದ ಸಂರಚನೆಯನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$ಓವರ್ಕ್ಲೌಡ್ ಸ್ಥಾಪನೆ
ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಅಂಡರ್ಕ್ಲೌಡ್ ಅನ್ನು ಮಾತ್ರ ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಓವರ್ಕ್ಲೌಡ್ ಅನ್ನು ಜೋಡಿಸುವ ಸಾಕಷ್ಟು ನೋಡ್‌ಗಳನ್ನು ನಾವು ಹೊಂದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಮೊದಲನೆಯದಾಗಿ, ನಮಗೆ ಅಗತ್ಯವಿರುವ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ನಿಯೋಜಿಸೋಣ. ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ, ಅಂಡರ್ಕ್ಲೌಡ್ ಸ್ವತಃ ಓಎಸ್ ಮತ್ತು ಅಗತ್ಯ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಓವರ್ಕ್ಲೌಡ್ ಯಂತ್ರದಲ್ಲಿ ಸ್ಥಾಪಿಸುತ್ತದೆ - ಅಂದರೆ, ನಾವು ಯಂತ್ರವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಯೋಜಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ಅದಕ್ಕಾಗಿ ಡಿಸ್ಕ್ (ಅಥವಾ ಡಿಸ್ಕ್) ಅನ್ನು ಮಾತ್ರ ರಚಿಸಿ ಮತ್ತು ಅದರ ನಿಯತಾಂಕಗಳನ್ನು ನಿರ್ಧರಿಸಿ - ಅಂದರೆ , ವಾಸ್ತವವಾಗಿ, ನಾವು OS ಅನ್ನು ಸ್ಥಾಪಿಸದೆ ಬೇರ್ ಸರ್ವರ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ .
ನಮ್ಮ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ಡಿಸ್ಕ್ಗಳೊಂದಿಗೆ ಫೋಲ್ಡರ್ಗೆ ಹೋಗೋಣ ಮತ್ತು ಅಗತ್ಯವಿರುವ ಗಾತ್ರದ ಡಿಸ್ಕ್ಗಳನ್ನು ರಚಿಸೋಣ:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160Gನಾವು ರೂಟ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವುದರಿಂದ, ಹಕ್ಕುಗಳೊಂದಿಗೆ ಸಮಸ್ಯೆಯಾಗದಂತೆ ನಾವು ಈ ಡಿಸ್ಕ್‌ಗಳ ಮಾಲೀಕರನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# ಗಮನಿಸಿ: ನೀವು ಅದನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ceph ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಯೋಜಿಸದಿದ್ದರೆ, ಆಜ್ಞೆಗಳು ಕನಿಷ್ಠ ಎರಡು ಡಿಸ್ಕ್ಗಳೊಂದಿಗೆ ಕನಿಷ್ಠ 3 ನೋಡ್‌ಗಳನ್ನು ರಚಿಸುವುದಿಲ್ಲ, ಆದರೆ ಟೆಂಪ್ಲೇಟ್‌ನಲ್ಲಿ ವರ್ಚುವಲ್ ಡಿಸ್ಕ್‌ಗಳು vda, vdb, ಇತ್ಯಾದಿಗಳನ್ನು ಬಳಸಲಾಗುವುದು ಎಂದು ಸೂಚಿಸುತ್ತದೆ.
ಅದ್ಭುತವಾಗಿದೆ, ಈಗ ನಾವು ಈ ಎಲ್ಲಾ ಯಂತ್ರಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬೇಕಾಗಿದೆ:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml ಕೊನೆಯಲ್ಲಿ -print-xml > /tmp/storage-1.xml ಎಂಬ ಆದೇಶವಿದೆ, ಇದು /tmp/ ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ಪ್ರತಿ ಯಂತ್ರದ ವಿವರಣೆಯೊಂದಿಗೆ xml ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ; ನೀವು ಅದನ್ನು ಸೇರಿಸದಿದ್ದರೆ, ನೀವು ಆಗುವುದಿಲ್ಲ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಈಗ ನಾವು ಈ ಎಲ್ಲಾ ಯಂತ್ರಗಳನ್ನು ವಿರ್ಶ್‌ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಬೇಕಾಗಿದೆ:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#ಈಗ ಒಂದು ಸಣ್ಣ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸ - ಟ್ರಿಪಲ್ ಓ ಅನುಸ್ಥಾಪನೆ ಮತ್ತು ಆತ್ಮಾವಲೋಕನದ ಸಮಯದಲ್ಲಿ ಸರ್ವರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು IPMI ಅನ್ನು ಬಳಸುತ್ತದೆ.
ಆತ್ಮಾವಲೋಕನವು ನೋಡ್ಗಳ ಮತ್ತಷ್ಟು ನಿಬಂಧನೆಗೆ ಅಗತ್ಯವಾದ ಅದರ ನಿಯತಾಂಕಗಳನ್ನು ಪಡೆಯಲು ಯಂತ್ರಾಂಶವನ್ನು ಪರಿಶೀಲಿಸುವ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ಬೇರ್ ಮೆಟಲ್ ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಸೇವೆಯಾದ ವ್ಯಂಗ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ಆತ್ಮಾವಲೋಕನವನ್ನು ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ.
ಆದರೆ ಇಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ - ಹಾರ್ಡ್‌ವೇರ್ IPMI ಸರ್ವರ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಪೋರ್ಟ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ (ಅಥವಾ ಹಂಚಿದ ಪೋರ್ಟ್, ಆದರೆ ಇದು ಮುಖ್ಯವಲ್ಲ), ನಂತರ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಅಂತಹ ಪೋರ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ಇಲ್ಲಿ vbmc ಎಂಬ ಊರುಗೋಲು ನಮ್ಮ ಸಹಾಯಕ್ಕೆ ಬರುತ್ತದೆ - IPMI ಪೋರ್ಟ್ ಅನ್ನು ಅನುಕರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಒಂದು ಉಪಯುಕ್ತತೆ. ESXI ಹೈಪರ್‌ವೈಸರ್‌ನಲ್ಲಿ ಅಂತಹ ಪ್ರಯೋಗಾಲಯವನ್ನು ಸ್ಥಾಪಿಸಲು ಬಯಸುವವರಿಗೆ ಈ ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವು ಗಮನ ಕೊಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ - ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಇದು vbmc ನ ಅನಲಾಗ್ ಅನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದ್ದರಿಂದ ಎಲ್ಲವನ್ನೂ ನಿಯೋಜಿಸುವ ಮೊದಲು ಈ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಆಶ್ಚರ್ಯ ಪಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ. .
vbmc ಸ್ಥಾಪಿಸಿ:
yum install yum install python2-virtualbmcನಿಮ್ಮ OS ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗದಿದ್ದರೆ, ನಂತರ ರೆಪೊಸಿಟರಿಯನ್ನು ಸೇರಿಸಿ:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmಈಗ ನಾವು ಉಪಯುಕ್ತತೆಯನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ. ಇಲ್ಲಿ ಎಲ್ಲವೂ ನಾಚಿಕೆಗೇಡಿನ ಮಟ್ಟಕ್ಕೆ ಮಾಮೂಲಿಯಾಗಿದೆ. ಈಗ vbmc ಪಟ್ಟಿಯಲ್ಲಿ ಯಾವುದೇ ಸರ್ವರ್‌ಗಳಿಲ್ಲ ಎಂಬುದು ತಾರ್ಕಿಕವಾಗಿದೆ
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# ಅವರು ಕಾಣಿಸಿಕೊಳ್ಳಲು, ಅವುಗಳನ್ನು ಈ ರೀತಿ ಹಸ್ತಚಾಲಿತವಾಗಿ ಘೋಷಿಸಬೇಕು:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#ವಿವರಣೆಯಿಲ್ಲದೆ ಕಮಾಂಡ್ ಸಿಂಟ್ಯಾಕ್ಸ್ ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಆದಾಗ್ಯೂ, ಸದ್ಯಕ್ಕೆ ನಮ್ಮ ಎಲ್ಲಾ ಸೆಷನ್‌ಗಳು ಡೌನ್ ಸ್ಥಿತಿಯಲ್ಲಿವೆ. ಅವರು UP ಸ್ಥಿತಿಗೆ ತೆರಳಲು, ನೀವು ಅವುಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#ಮತ್ತು ಅಂತಿಮ ಸ್ಪರ್ಶ - ನೀವು ಫೈರ್ವಾಲ್ ನಿಯಮಗಳನ್ನು ಸರಿಪಡಿಸಬೇಕಾಗಿದೆ (ಅಥವಾ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
ಈಗ ಅಂಡರ್‌ಕ್ಲೌಡ್‌ಗೆ ಹೋಗೋಣ ಮತ್ತು ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ. ಆತಿಥೇಯ ಯಂತ್ರದ ವಿಳಾಸವು 192.168.255.200 ಆಗಿದೆ, ಅಂಡರ್‌ಕ್ಲೌಡ್‌ನಲ್ಲಿ ನಾವು ನಿಯೋಜನೆಗಾಗಿ ತಯಾರಿ ಮಾಡುವಾಗ ಅಗತ್ಯವಾದ ಇಪ್ಮಿಟೂಲ್ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸೇರಿಸಿದ್ದೇವೆ:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningನೀವು ನೋಡುವಂತೆ, ನಾವು vbmc ಮೂಲಕ ನಿಯಂತ್ರಣ ನೋಡ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಈಗ ಅದನ್ನು ಆಫ್ ಮಾಡಿ ಮತ್ತು ಮುಂದುವರಿಯೋಣ:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#ಮುಂದಿನ ಹಂತವು ಓವರ್ಕ್ಲೌಡ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವ ನೋಡ್ಗಳ ಆತ್ಮಾವಲೋಕನವಾಗಿದೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ನಮ್ಮ ನೋಡ್ಗಳ ವಿವರಣೆಯೊಂದಿಗೆ json ಫೈಲ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಬೇಕು. ಬೇರ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿನ ಅನುಸ್ಥಾಪನೆಯಂತಲ್ಲದೆ, ಪ್ರತಿ ಯಂತ್ರಕ್ಕೆ vbmc ಚಾಲನೆಯಲ್ಲಿರುವ ಪೋರ್ಟ್ ಅನ್ನು ಫೈಲ್ ಸೂಚಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27ಗಮನಿಸಿ: ನಿಯಂತ್ರಣ ನೋಡ್ ಎರಡು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಮುಖ್ಯವಲ್ಲ, ಈ ಅನುಸ್ಥಾಪನೆಯಲ್ಲಿ ನಮಗೆ ಸಾಕಷ್ಟು ಇರುತ್ತದೆ.
ಈಗ ನಾವು json ಫೈಲ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತೇವೆ. ನಾವು ಪೋರ್ಟ್‌ನ ಗಸಗಸೆ ವಿಳಾಸವನ್ನು ಸೂಚಿಸಬೇಕು, ಅದರ ಮೂಲಕ ಒದಗಿಸುವಿಕೆಯನ್ನು ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ, ನೋಡ್ಗಳ ನಿಯತಾಂಕಗಳು, ಅವರಿಗೆ ಹೆಸರುಗಳನ್ನು ನೀಡಿ ಮತ್ತು ipmi ಗೆ ಹೇಗೆ ಹೋಗುವುದು ಎಂಬುದನ್ನು ಸೂಚಿಸಿ:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}ಈಗ ನಾವು ವ್ಯಂಗ್ಯಕ್ಕಾಗಿ ಚಿತ್ರಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಬೇಕಾಗಿದೆ. ಇದನ್ನು ಮಾಡಲು, ಅವುಗಳನ್ನು wget ಮೂಲಕ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಸ್ಥಾಪಿಸಿ:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ಅಂಡರ್‌ಕ್ಲೌಡ್‌ಗೆ ಚಿತ್ರಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$ಎಲ್ಲಾ ಚಿತ್ರಗಳು ಲೋಡ್ ಆಗಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$ಇನ್ನೊಂದು ವಿಷಯ - ನೀವು DNS ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$ಈಗ ನಾವು ಆತ್ಮಾವಲೋಕನಕ್ಕಾಗಿ ಆಜ್ಞೆಯನ್ನು ನೀಡಬಹುದು:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$ಔಟ್ಪುಟ್ನಿಂದ ನೀವು ನೋಡುವಂತೆ, ದೋಷಗಳಿಲ್ಲದೆ ಎಲ್ಲವೂ ಪೂರ್ಣಗೊಂಡಿದೆ. ಎಲ್ಲಾ ನೋಡ್‌ಗಳು ಲಭ್ಯವಿರುವ ಸ್ಥಿತಿಯಲ್ಲಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ ನೋಡ್‌ಗಳು ವಿಭಿನ್ನ ಸ್ಥಿತಿಯಲ್ಲಿದ್ದರೆ, ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ವಹಿಸಬಹುದಾದ, ನಂತರ ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ ಮತ್ತು ನೀವು ಲಾಗ್ ಅನ್ನು ನೋಡಬೇಕು ಮತ್ತು ಇದು ಏಕೆ ಸಂಭವಿಸಿತು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು. ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ ನಾವು ವರ್ಚುವಲೈಸೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಅಥವಾ vbmc ಬಳಕೆಗೆ ಸಂಬಂಧಿಸಿದ ದೋಷಗಳು ಇರಬಹುದು ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಡಿ.
ಮುಂದೆ, ಯಾವ ನೋಡ್ ಯಾವ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಸೂಚಿಸಬೇಕಾಗಿದೆ - ಅಂದರೆ, ನೋಡ್ ಅನ್ನು ನಿಯೋಜಿಸುವ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಸೂಚಿಸಿ:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$ಪ್ರತಿ ನೋಡ್‌ಗೆ ಪ್ರೊಫೈಲ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167ನಾವು ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಮಾಡಿದ್ದೇವೆ ಎಂದು ಪರಿಶೀಲಿಸೋಣ:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ಎಲ್ಲವೂ ಸರಿಯಾಗಿದ್ದರೆ, ಓವರ್ಕ್ಲೌಡ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ನಾವು ಆಜ್ಞೆಯನ್ನು ನೀಡುತ್ತೇವೆ:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuನಿಜವಾದ ಅನುಸ್ಥಾಪನೆಯಲ್ಲಿ, ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಸ್ವಾಭಾವಿಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಚ್ಚು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಟೆಂಪ್ಲೇಟ್‌ನಲ್ಲಿನ ಪ್ರತಿ ಸಂಪಾದನೆಯನ್ನು ವಿವರಿಸಬೇಕಾಗುತ್ತದೆ. ಮೊದಲೇ ಬರೆದಂತೆ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಲು ನಮಗೆ ಸರಳವಾದ ಅನುಸ್ಥಾಪನೆಯು ಸಾಕಾಗುತ್ತದೆ.
ಗಮನಿಸಿ: --libvirt-type qemu ವೇರಿಯೇಬಲ್ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅವಶ್ಯಕವಾಗಿದೆ, ಏಕೆಂದರೆ ನಾವು ನೆಸ್ಟೆಡ್ ವರ್ಚುವಲೈಸೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಚಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ಈಗ ನೀವು ಸುಮಾರು ಒಂದು ಗಂಟೆ ಅಥವಾ ಹೆಚ್ಚಿನದನ್ನು ಹೊಂದಿದ್ದೀರಿ (ಹಾರ್ಡ್‌ವೇರ್‌ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ) ಮತ್ತು ಈ ಸಮಯದ ನಂತರ ನೀವು ಈ ಕೆಳಗಿನ ಸಂದೇಶವನ್ನು ನೋಡುತ್ತೀರಿ ಎಂದು ನೀವು ಭಾವಿಸಬಹುದು:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$ಈಗ ನೀವು ಓಪನ್‌ಸ್ಟಾಕ್‌ನ ಬಹುತೇಕ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಅದರ ಮೇಲೆ ನೀವು ಅಧ್ಯಯನ ಮಾಡಬಹುದು, ಪ್ರಯೋಗಿಸಬಹುದು, ಇತ್ಯಾದಿ.
ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ. ಬಳಕೆದಾರರ ಹೋಮ್ ಡೈರೆಕ್ಟರಿ ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಎರಡು ಫೈಲ್‌ಗಳಿವೆ - ಒಂದು ಸ್ಟಾಕರ್ಕ್ (ಅಂಡರ್ಕ್ಲೌಡ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು) ಮತ್ತು ಎರಡನೇ ಓವರ್‌ಕ್ಲೌಡ್‌ಆರ್‌ಸಿ (ಓವರ್ಕ್ಲೌಡ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು). ಈ ಫೈಲ್‌ಗಳನ್ನು ಮೂಲವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು, ಏಕೆಂದರೆ ಅವುಗಳು ದೃಢೀಕರಣಕ್ಕೆ ಅಗತ್ಯವಾದ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ನನ್ನ ಸ್ಥಾಪನೆಗೆ ಇನ್ನೂ ಒಂದು ಸಣ್ಣ ಸ್ಪರ್ಶದ ಅಗತ್ಯವಿದೆ - ನಿಯಂತ್ರಕದಲ್ಲಿ ಮಾರ್ಗವನ್ನು ಸೇರಿಸುವುದು, ಏಕೆಂದರೆ ನಾನು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಯಂತ್ರವು ಬೇರೆ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿದೆ. ಇದನ್ನು ಮಾಡಲು, ಶಾಖ-ನಿರ್ವಾಹಕ ಖಾತೆಯ ಅಡಿಯಲ್ಲಿ ನಿಯಂತ್ರಣ-1 ಗೆ ಹೋಗಿ ಮತ್ತು ಮಾರ್ಗವನ್ನು ನೋಂದಾಯಿಸಿ
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254ಸರಿ, ಈಗ ನೀವು ದಿಗಂತಕ್ಕೆ ಹೋಗಬಹುದು. ಎಲ್ಲಾ ಮಾಹಿತಿ - ವಿಳಾಸಗಳು, ಲಾಗಿನ್ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ - ಫೈಲ್ /home/stack/overcloudrc ನಲ್ಲಿದೆ. ಅಂತಿಮ ರೇಖಾಚಿತ್ರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಮೂಲಕ, ನಮ್ಮ ಅನುಸ್ಥಾಪನೆಯಲ್ಲಿ, DHCP ಮೂಲಕ ಯಂತ್ರದ ವಿಳಾಸಗಳನ್ನು ನೀಡಲಾಯಿತು ಮತ್ತು ನೀವು ನೋಡುವಂತೆ, ಅವುಗಳನ್ನು "ಯಾದೃಚ್ಛಿಕವಾಗಿ" ನೀಡಲಾಗುತ್ತದೆ. ನಿಮಗೆ ಅಗತ್ಯವಿದ್ದರೆ, ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಯಾವ ಯಂತ್ರಕ್ಕೆ ಯಾವ ವಿಳಾಸವನ್ನು ಲಗತ್ತಿಸಬೇಕು ಎಂಬುದನ್ನು ನೀವು ಟೆಂಪ್ಲೇಟ್‌ನಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು.
ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ನಡುವೆ ಸಂಚಾರ ಹೇಗೆ ಹರಿಯುತ್ತದೆ?
ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹಾದುಹೋಗಲು ಮೂರು ಆಯ್ಕೆಗಳನ್ನು ನೋಡುತ್ತೇವೆ
- ಒಂದು L2 ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಒಂದು ಹೈಪರ್‌ವೈಸರ್‌ನಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳು
- ಒಂದೇ L2 ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ವಿಭಿನ್ನ ಹೈಪರ್‌ವೈಸರ್‌ಗಳಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳು
- ವಿಭಿನ್ನ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳು (ಕ್ರಾಸ್-ನೆಟ್ವರ್ಕ್ ರೂಟಿಂಗ್)
ಬಾಹ್ಯ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಹೊರಗಿನ ಪ್ರಪಂಚಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುವ ಪ್ರಕರಣಗಳು, ತೇಲುವ ವಿಳಾಸಗಳು ಮತ್ತು ವಿತರಿಸಿದ ರೂಟಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ನಾವು ಮುಂದಿನ ಬಾರಿ ಪರಿಗಣಿಸುತ್ತೇವೆ, ಇದೀಗ ನಾವು ಆಂತರಿಕ ದಟ್ಟಣೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ.
ಪರಿಶೀಲಿಸಲು, ನಾವು ಈ ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವನ್ನು ಒಟ್ಟುಗೂಡಿಸೋಣ:
ನಾವು 4 ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ರಚಿಸಿದ್ದೇವೆ - 3 ಒಂದು L2 ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ - net-1, ಮತ್ತು 1 ಹೆಚ್ಚು net-2 ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ ರಚಿಸಿದ ಯಂತ್ರಗಳು ಯಾವ ಹೈಪರ್ವೈಸರ್ಗಳಲ್ಲಿವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(ಓವರ್ಕ್ಲೌಡ್) [ಸ್ಟಾಕ್@ಅಂಡರ್ಕ್ಲೌಡ್ ~]$
vm-1 ಮತ್ತು vm-3 ಯಂತ್ರಗಳು ಕಂಪ್ಯೂಟ್-0 ನಲ್ಲಿವೆ, ಯಂತ್ರಗಳು vm-2 ಮತ್ತು vm-4 ನೋಡ್ ಕಂಪ್ಯೂಟ್-1 ನಲ್ಲಿವೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಿರ್ದಿಷ್ಟ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ನಡುವೆ ರೂಟಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ವರ್ಚುವಲ್ ರೂಟರ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ ರೂಟರ್ ಎರಡು ವರ್ಚುವಲ್ ಪೋರ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಇದು ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ ಗೇಟ್‌ವೇಗಳಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ ಆದರೆ ದಟ್ಟಣೆಯು ಹೇಗೆ ಹರಿಯುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುವ ಮೊದಲು, ನಾವು ಪ್ರಸ್ತುತ ನಿಯಂತ್ರಣ ನೋಡ್ನಲ್ಲಿ (ಇದು ನೆಟ್ವರ್ಕ್ ನೋಡ್ ಆಗಿದೆ) ಮತ್ತು ಕಂಪ್ಯೂಟ್ ನೋಡ್ನಲ್ಲಿ ಏನನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ. ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ಈ ಸಮಯದಲ್ಲಿ, ನೋಡ್ ಮೂರು ovs ಸೇತುವೆಗಳನ್ನು ಹೊಂದಿದೆ - br-int, br-tun, br-ex. ಅವುಗಳ ನಡುವೆ, ನಾವು ನೋಡುವಂತೆ, ಇಂಟರ್ಫೇಸ್ಗಳ ಒಂದು ಸೆಟ್ ಇದೆ. ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾಗುವಂತೆ, ಈ ಎಲ್ಲಾ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ರೇಖಾಚಿತ್ರದಲ್ಲಿ ರೂಪಿಸೋಣ ಮತ್ತು ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ.
VxLAN ಸುರಂಗಗಳನ್ನು ಎತ್ತಿರುವ ವಿಳಾಸಗಳನ್ನು ನೋಡಿದಾಗ, ಒಂದು ಸುರಂಗವನ್ನು ಕಂಪ್ಯೂಟ್-1 (192.168.255.26) ಗೆ ಏರಿಸಲಾಗಿದೆ, ಎರಡನೇ ಸುರಂಗವು ನಿಯಂತ್ರಣ-1 (192.168.255.15) ಗೆ ಕಾಣುತ್ತದೆ. ಆದರೆ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವೆಂದರೆ ಬ್ರ-ಎಕ್ಸ್ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಮತ್ತು ಯಾವ ಹರಿವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಿದರೆ, ಈ ಸೇತುವೆಯು ಈ ಸಮಯದಲ್ಲಿ ದಟ್ಟಣೆಯನ್ನು ಮಾತ್ರ ಬಿಡಬಹುದು ಎಂದು ನೀವು ನೋಡಬಹುದು.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ ಔಟ್ಪುಟ್ನಿಂದ ನೀವು ನೋಡುವಂತೆ, ವಿಳಾಸವನ್ನು ನೇರವಾಗಿ ಭೌತಿಕ ಪೋರ್ಟ್‌ಗೆ ತಿರುಗಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ವರ್ಚುವಲ್ ಸೇತುವೆ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಅಲ್ಲ.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
ಮೊದಲ ನಿಯಮದ ಪ್ರಕಾರ, phy-br-ex ಪೋರ್ಟ್‌ನಿಂದ ಬಂದ ಎಲ್ಲವನ್ನೂ ತ್ಯಜಿಸಬೇಕು.
ವಾಸ್ತವವಾಗಿ, ಈ ಇಂಟರ್‌ಫೇಸ್‌ನಿಂದ (br-int ಜೊತೆಗಿನ ಇಂಟರ್ಫೇಸ್) ಹೊರತುಪಡಿಸಿ ಈ ಸೇತುವೆಯೊಳಗೆ ಟ್ರಾಫಿಕ್ ಬರಲು ಬೇರೆಲ್ಲಿಯೂ ಇಲ್ಲ, ಮತ್ತು ಡ್ರಾಪ್‌ಗಳ ಮೂಲಕ ನಿರ್ಣಯಿಸುವುದು, BUM ದಟ್ಟಣೆಯು ಈಗಾಗಲೇ ಸೇತುವೆಯೊಳಗೆ ಹಾರಿಹೋಗಿದೆ.
ಅಂದರೆ, ಸಂಚಾರವು VxLAN ಸುರಂಗದ ಮೂಲಕ ಮಾತ್ರ ಈ ನೋಡ್ ಅನ್ನು ಬಿಡಬಹುದು ಮತ್ತು ಬೇರೆ ಯಾವುದೂ ಇಲ್ಲ. ಆದಾಗ್ಯೂ, ನೀವು DVR ಅನ್ನು ಆನ್ ಮಾಡಿದರೆ, ಪರಿಸ್ಥಿತಿ ಬದಲಾಗುತ್ತದೆ, ಆದರೆ ನಾವು ಅದನ್ನು ಇನ್ನೊಂದು ಬಾರಿ ನಿಭಾಯಿಸುತ್ತೇವೆ. ನೆಟ್ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಬಳಸುವಾಗ, ಉದಾಹರಣೆಗೆ vlans ಅನ್ನು ಬಳಸುವಾಗ, ನೀವು vlan 3 ನಲ್ಲಿ ಒಂದು L0 ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಆದರೆ ಹಲವಾರು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಹೊಂದಿರುತ್ತೀರಿ. ಆದಾಗ್ಯೂ, VxLAN ಟ್ರಾಫಿಕ್ ನೋಡ್ ಅನ್ನು ಅದೇ ರೀತಿಯಲ್ಲಿ ಬಿಡುತ್ತದೆ, ಆದರೆ ಕೆಲವು ರೀತಿಯ ಮೀಸಲಾದ vlan ನಲ್ಲಿ ಸುತ್ತುವರಿಯುತ್ತದೆ.
ನಾವು ಕಂಪ್ಯೂಟ್ ನೋಡ್ ಅನ್ನು ವಿಂಗಡಿಸಿದ್ದೇವೆ, ನಾವು ನಿಯಂತ್ರಣ ನೋಡ್‌ಗೆ ಹೋಗೋಣ.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ವಾಸ್ತವವಾಗಿ, ಎಲ್ಲವೂ ಒಂದೇ ಎಂದು ನಾವು ಹೇಳಬಹುದು, ಆದರೆ IP ವಿಳಾಸವು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಇಲ್ಲ ಆದರೆ ವರ್ಚುವಲ್ ಸೇತುವೆಯಲ್ಲಿದೆ. ಈ ಬಂದರು ಹೊರಜಗತ್ತಿಗೆ ಸಂಚಾರ ನಿರ್ಗಮಿಸುವ ಬಂದರು ಆಗಿರುವುದರಿಂದ ಇದನ್ನು ಮಾಡಲಾಗಿದೆ.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ ಈ ಪೋರ್ಟ್ ಅನ್ನು br-ex ಬ್ರಿಡ್ಜ್‌ಗೆ ಕಟ್ಟಲಾಗಿದೆ ಮತ್ತು ಅದರ ಮೇಲೆ ಯಾವುದೇ vlan ಟ್ಯಾಗ್‌ಗಳಿಲ್ಲದ ಕಾರಣ, ಈ ಪೋರ್ಟ್ ಟ್ರಂಕ್ ಪೋರ್ಟ್ ಆಗಿದ್ದು, ಅದರ ಮೇಲೆ ಎಲ್ಲಾ vlanಗಳನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ, ಈಗ ಟ್ರಾಫಿಕ್ ಟ್ಯಾಗ್ ಇಲ್ಲದೆಯೇ ಹೊರಗೆ ಹೋಗುತ್ತದೆ, vlan-id 0 ನಲ್ಲಿ ಸೂಚಿಸಿದಂತೆ ಮೇಲಿನ ಔಟ್ಪುಟ್.
ಈ ಸಮಯದಲ್ಲಿ ಉಳಿದೆಲ್ಲವೂ ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ಗೆ ಹೋಲುತ್ತದೆ - ಅದೇ ಸೇತುವೆಗಳು, ಅದೇ ಸುರಂಗಗಳು ಎರಡು ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ಗಳಿಗೆ ಹೋಗುತ್ತವೆ.
ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಶೇಖರಣಾ ನೋಡ್‌ಗಳನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಈ ನೋಡ್ಗಳ ನೆಟ್ವರ್ಕ್ ಭಾಗವು ಅವಮಾನಕರ ಹಂತಕ್ಕೆ ನೀರಸವಾಗಿದೆ ಎಂದು ಹೇಳುವುದು ಅವಶ್ಯಕ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, IP ವಿಳಾಸವನ್ನು ನಿಗದಿಪಡಿಸಿದ ಒಂದು ಭೌತಿಕ ಪೋರ್ಟ್ (eth0) ಮಾತ್ರ ಇದೆ ಮತ್ತು ಅದು ಅಷ್ಟೆ. ಯಾವುದೇ VxLAN ಸುರಂಗಗಳು, ಸುರಂಗ ಸೇತುವೆಗಳು, ಇತ್ಯಾದಿಗಳಿಲ್ಲ - ಯಾವುದೇ ovs ಇಲ್ಲ, ಏಕೆಂದರೆ ಅದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ನೆಟ್ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಬಳಸುವಾಗ, ಈ ನೋಡ್ ಎರಡು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ (ಭೌತಿಕ ಪೋರ್ಟ್‌ಗಳು, ಬೊಡ್ನಿ, ಅಥವಾ ಕೇವಲ ಎರಡು vlans - ಇದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ - ಇದು ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ) - ನಿರ್ವಹಣೆಗೆ ಒಂದು, ಟ್ರಾಫಿಕ್‌ಗೆ ಎರಡನೆಯದು (VM ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯುವುದು , ಡಿಸ್ಕ್ನಿಂದ ಓದುವುದು, ಇತ್ಯಾದಿ.)
ಯಾವುದೇ ಸೇವೆಗಳ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ ನಾವು ನೋಡ್‌ಗಳಲ್ಲಿ ಏನನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಈಗ ನಾವು 4 ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಪ್ರಾರಂಭಿಸೋಣ ಮತ್ತು ಮೇಲೆ ವಿವರಿಸಿದ ಸ್ಕೀಮ್ ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ - ನಾವು ಪೋರ್ಟ್‌ಗಳು, ವರ್ಚುವಲ್ ರೂಟರ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಹೊಂದಿರಬೇಕು.
ಇಲ್ಲಿಯವರೆಗೆ ನಮ್ಮ ನೆಟ್ವರ್ಕ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ನಾವು ಪ್ರತಿ ಕಂಪ್ಯೂಟರ್ ನೋಡ್ನಲ್ಲಿ ಎರಡು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಕಂಪ್ಯೂಟ್-0 ಅನ್ನು ಉದಾಹರಣೆಯಾಗಿ ಬಳಸಿ, ಎಲ್ಲವನ್ನೂ ಹೇಗೆ ಸೇರಿಸಲಾಗಿದೆ ಎಂದು ನೋಡೋಣ.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ ಯಂತ್ರವು ಕೇವಲ ಒಂದು ವರ್ಚುವಲ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೊಂದಿದೆ - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
ಈ ಇಂಟರ್ಫೇಸ್ ಲಿನಕ್ಸ್ ಸೇತುವೆಯಲ್ಲಿ ಕಾಣುತ್ತದೆ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ ಔಟ್ಪುಟ್ನಿಂದ ನೀವು ನೋಡುವಂತೆ, ಸೇತುವೆಯಲ್ಲಿ ಕೇವಲ ಎರಡು ಇಂಟರ್‌ಫೇಸ್‌ಗಳಿವೆ - tap95d96a75-a0 ಮತ್ತು qvb95d96a75-a0.
ಇಲ್ಲಿ ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿನ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಸಾಧನಗಳ ಪ್ರಕಾರಗಳ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ವಾಸಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ:
vtap - ಒಂದು ನಿದರ್ಶನಕ್ಕೆ (VM) ಲಗತ್ತಿಸಲಾದ ವರ್ಚುವಲ್ ಇಂಟರ್ಫೇಸ್
qbr - ಲಿನಕ್ಸ್ ಸೇತುವೆ
qvb ಮತ್ತು qvo - vEth ಜೋಡಿಯನ್ನು Linux ಸೇತುವೆಗೆ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ ಮತ್ತು vSwitch ಸೇತುವೆಯನ್ನು ತೆರೆಯಿರಿ
br-int, br-tun, br-vlan — vSwitch ಸೇತುವೆಗಳನ್ನು ತೆರೆಯಿರಿ
patch-, int-br-, phy-br- - ಓಪನ್ vSwitch ಪ್ಯಾಚ್ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ಸೇತುವೆಗಳು
qg, qr, ha, fg, sg - OVS ಗೆ ಸಂಪರ್ಕಿಸಲು ವರ್ಚುವಲ್ ಸಾಧನಗಳು ಬಳಸುವ vSwitch ಪೋರ್ಟ್‌ಗಳನ್ನು ತೆರೆಯಿರಿ
ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ನಾವು ಸೇತುವೆಯಲ್ಲಿ qvb95d96a75-a0 ಪೋರ್ಟ್ ಹೊಂದಿದ್ದರೆ, ಅದು vEth ಜೋಡಿ, ಆಗ ಎಲ್ಲೋ ಅದರ ಪ್ರತಿರೂಪವಿದೆ, ಅದನ್ನು ತಾರ್ಕಿಕವಾಗಿ qvo95d96a75-a0 ಎಂದು ಕರೆಯಬೇಕು. OVS ನಲ್ಲಿ ಯಾವ ಪೋರ್ಟ್‌ಗಳಿವೆ ಎಂದು ನೋಡೋಣ.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ ನಾವು ನೋಡುವಂತೆ, ಬಂದರು br-int ನಲ್ಲಿದೆ. Br-int ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಪೋರ್ಟ್‌ಗಳನ್ನು ಕೊನೆಗೊಳಿಸುವ ಸ್ವಿಚ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. qvo95d96a75-a0 ಜೊತೆಗೆ, ಪೋರ್ಟ್ qvo5bd37136-47 ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಗೋಚರಿಸುತ್ತದೆ. ಇದು ಎರಡನೇ ವರ್ಚುವಲ್ ಯಂತ್ರಕ್ಕೆ ಪೋರ್ಟ್ ಆಗಿದೆ. ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮ ರೇಖಾಚಿತ್ರವು ಈಗ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಗಮನ ಸೆಳೆಯುವ ಓದುಗರಿಗೆ ತಕ್ಷಣವೇ ಆಸಕ್ತಿಯನ್ನುಂಟುಮಾಡುವ ಪ್ರಶ್ನೆ - ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಪೋರ್ಟ್ ಮತ್ತು OVS ಪೋರ್ಟ್ ನಡುವಿನ ಲಿನಕ್ಸ್ ಸೇತುವೆ ಯಾವುದು? ಸತ್ಯವೆಂದರೆ ಯಂತ್ರವನ್ನು ರಕ್ಷಿಸಲು, ಭದ್ರತಾ ಗುಂಪುಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಇದು iptables ಗಿಂತ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ. OVS iptables ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ "ಊರುಗೋಲು" ಅನ್ನು ಕಂಡುಹಿಡಿಯಲಾಯಿತು. ಆದಾಗ್ಯೂ, ಇದು ಬಳಕೆಯಲ್ಲಿಲ್ಲದವಾಗುತ್ತಿದೆ - ಇದು ಹೊಸ ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಕಾಂಟ್ರಾಕ್ನಿಂದ ಬದಲಾಯಿಸಲ್ಪಡುತ್ತದೆ.
ಅಂದರೆ, ಅಂತಿಮವಾಗಿ ಯೋಜನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಒಂದು L2 ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಒಂದು ಹೈಪರ್‌ವೈಸರ್‌ನಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳು
ಈ ಎರಡು VMಗಳು ಒಂದೇ L2 ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಮತ್ತು ಒಂದೇ ಹೈಪರ್‌ವೈಸರ್‌ನಲ್ಲಿ ಇರುವುದರಿಂದ, ಅವುಗಳ ನಡುವಿನ ಸಂಚಾರವು ತಾರ್ಕಿಕವಾಗಿ br-int ಮೂಲಕ ಸ್ಥಳೀಯವಾಗಿ ಹರಿಯುತ್ತದೆ, ಏಕೆಂದರೆ ಎರಡೂ ಯಂತ್ರಗಳು ಒಂದೇ VLAN ನಲ್ಲಿರುತ್ತವೆ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ ಒಂದೇ L2 ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ವಿಭಿನ್ನ ಹೈಪರ್‌ವೈಸರ್‌ಗಳಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳು
ಒಂದೇ L2 ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳ ನಡುವೆ ಟ್ರಾಫಿಕ್ ಹೇಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ಈಗ ನೋಡೋಣ, ಆದರೆ ವಿಭಿನ್ನ ಹೈಪರ್‌ವೈಸರ್‌ಗಳಲ್ಲಿದೆ. ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಏನೂ ಹೆಚ್ಚು ಬದಲಾಗುವುದಿಲ್ಲ, ಹೈಪರ್ವೈಸರ್ಗಳ ನಡುವಿನ ಸಂಚಾರವು vxlan ಸುರಂಗದ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ.
ನಾವು ಸಂಚಾರವನ್ನು ವೀಕ್ಷಿಸುವ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ವಿಳಾಸಗಳು:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ ನಾವು ಕಂಪ್ಯೂಟ್-0 ನಲ್ಲಿ br-int ನಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಟೇಬಲ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]ಟ್ರಾಫಿಕ್ ಪೋರ್ಟ್ 2 ಗೆ ಹೋಗಬೇಕು - ಅದು ಯಾವ ರೀತಿಯ ಪೋರ್ಟ್ ಎಂದು ನೋಡೋಣ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ಇದು ಪ್ಯಾಚ್-ಟುನ್ - ಅಂದರೆ, br-tun ನಲ್ಲಿ ಇಂಟರ್ಫೇಸ್. br-tun ನಲ್ಲಿ ಪ್ಯಾಕೇಜ್‌ಗೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ ಪ್ಯಾಕೆಟ್ ಅನ್ನು VxLAN ನಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಪೋರ್ಟ್ 2 ಗೆ ಕಳುಹಿಸಲಾಗಿದೆ. ಪೋರ್ಟ್ 2 ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$ಇದು ಕಂಪ್ಯೂಟ್-1 ರಲ್ಲಿನ vxlan ಸುರಂಗ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ಕಂಪ್ಯೂಟ್-1 ಗೆ ಹೋಗೋಣ ಮತ್ತು ಪ್ಯಾಕೇಜ್‌ನೊಂದಿಗೆ ಮುಂದೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac ಕಂಪ್ಯೂಟ್-1 ನಲ್ಲಿ br-int ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಕೋಷ್ಟಕದಲ್ಲಿದೆ, ಮತ್ತು ಮೇಲಿನ ಔಟ್ಪುಟ್ನಿಂದ ನೋಡಬಹುದಾದಂತೆ, ಇದು ಪೋರ್ಟ್ 2 ಮೂಲಕ ಗೋಚರಿಸುತ್ತದೆ, ಇದು br-tun ಕಡೆಗೆ ಪೋರ್ಟ್ ಆಗಿದೆ:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46ಸರಿ, ನಂತರ ಕಂಪ್ಯೂಟ್-1 ನಲ್ಲಿ br-int ನಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನ ಗಸಗಸೆ ಇದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ ಅಂದರೆ, ಸ್ವೀಕರಿಸಿದ ಪ್ಯಾಕೆಟ್ ಪೋರ್ಟ್ 3 ಗೆ ಹಾರುತ್ತದೆ, ಅದರ ಹಿಂದೆ ಈಗಾಗಲೇ ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಇನ್ಸ್ಟೆನ್ಸ್-00000003 ಇದೆ.
ವರ್ಚುವಲ್ ಮೂಲಸೌಕರ್ಯವನ್ನು ಕಲಿಯಲು ಓಪನ್‌ಸ್ಟಾಕ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದರ ಸೌಂದರ್ಯವೆಂದರೆ ನಾವು ಹೈಪರ್ವೈಸರ್ಗಳ ನಡುವೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಸೆರೆಹಿಡಿಯಬಹುದು ಮತ್ತು ಅದರೊಂದಿಗೆ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು. ಇದನ್ನೇ ನಾವು ಈಗ ಮಾಡುತ್ತೇವೆ, ಕಂಪ್ಯೂಟ್-0 ಕಡೆಗೆ vnet ಪೋರ್ಟ್‌ನಲ್ಲಿ tcpdump ಅನ್ನು ರನ್ ಮಾಡಿ:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************ವಿಳಾಸ 10.0.1.85 ರಿಂದ Patek ವಿಳಾಸ 10.0.1.88 (ICMP ಟ್ರಾಫಿಕ್) ಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಮೊದಲ ಸಾಲು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಇದು vni 22 ನೊಂದಿಗೆ VxLAN ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ ಸುತ್ತುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಹೋಸ್ಟ್ 192.168.255.19 (ಕಂಪ್ಯೂಟ್-0) ನಿಂದ ಹೋಸ್ಟ್ 192.168.255.26 ಗೆ ಹೋಗುತ್ತದೆ. .1 (ಕಂಪ್ಯೂಟ್-XNUMX). VNI ovs ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಒಂದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ ಎಂದು ನಾವು ಪರಿಶೀಲಿಸಬಹುದು.
ನಾವು ಈ ಸಾಲಿನ ಕ್ರಿಯೆಗಳಿಗೆ ಹಿಂತಿರುಗೋಣ =load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ಔಟ್ಪುಟ್:2. ಹೆಕ್ಸಾಡೆಸಿಮಲ್ ಸಂಖ್ಯೆಯ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ 0x16 vni ಆಗಿದೆ. ಈ ಸಂಖ್ಯೆಯನ್ನು 16 ನೇ ವ್ಯವಸ್ಥೆಗೆ ಪರಿವರ್ತಿಸೋಣ:
16 = 6*16^0+1*16^1 = 6+16 = 22ಅಂದರೆ, vni ವಾಸ್ತವಕ್ಕೆ ಅನುರೂಪವಾಗಿದೆ.
ಎರಡನೇ ಸಾಲು ರಿಟರ್ನ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಅಲ್ಲದೆ, ಅದನ್ನು ವಿವರಿಸುವಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ, ಎಲ್ಲವೂ ಅಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿದೆ.
ವಿಭಿನ್ನ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಎರಡು ಯಂತ್ರಗಳು (ಇಂಟರ್-ನೆಟ್ವರ್ಕ್ ರೂಟಿಂಗ್)
ಇಂದಿನ ಕೊನೆಯ ಪ್ರಕರಣವೆಂದರೆ ವರ್ಚುವಲ್ ರೂಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದು ಯೋಜನೆಯೊಳಗೆ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ನಡುವೆ ರೂಟಿಂಗ್ ಆಗಿದೆ. ನಾವು ಡಿವಿಆರ್ ಇಲ್ಲದ ಪ್ರಕರಣವನ್ನು ಪರಿಗಣಿಸುತ್ತಿದ್ದೇವೆ (ನಾವು ಅದನ್ನು ಇನ್ನೊಂದು ಲೇಖನದಲ್ಲಿ ನೋಡುತ್ತೇವೆ), ಆದ್ದರಿಂದ ನೆಟ್ವರ್ಕ್ ನೋಡ್ನಲ್ಲಿ ರೂಟಿಂಗ್ ಸಂಭವಿಸುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ನೆಟ್ವರ್ಕ್ ನೋಡ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಘಟಕದಲ್ಲಿ ಇರಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ನಿಯಂತ್ರಣ ನೋಡ್ನಲ್ಲಿದೆ.
ಮೊದಲಿಗೆ, ರೂಟಿಂಗ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನೋಡೋಣ:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msಈ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ಗೇಟ್‌ವೇಗೆ ಹೋಗಬೇಕು ಮತ್ತು ಅಲ್ಲಿಗೆ ಹೋಗಬೇಕು, ನಾವು ಗೇಟ್‌ವೇಯ ಗಸಗಸೆ ವಿಳಾಸವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು, ಇದಕ್ಕಾಗಿ ನಾವು ಉದಾಹರಣೆಯಲ್ಲಿ ARP ಟೇಬಲ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0ಗಮ್ಯಸ್ಥಾನ (10.0.1.254) fa:16:3e:c4:64:70 ನೊಂದಿಗೆ ಸಂಚಾರವನ್ನು ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಬೇಕು ಎಂದು ಈಗ ನೋಡೋಣ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ ಪೋರ್ಟ್ 2 ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ ಎಲ್ಲವೂ ತಾರ್ಕಿಕವಾಗಿದೆ, ದಟ್ಟಣೆಯು br-tun ಗೆ ಹೋಗುತ್ತದೆ. ಇದು ಯಾವ ವಿಎಕ್ಸ್‌ಲಾನ್ ಸುರಂಗದಲ್ಲಿ ಸುತ್ತುತ್ತದೆ ಎಂದು ನೋಡೋಣ:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ ಮೂರನೇ ಬಂದರು vxlan ಸುರಂಗವಾಗಿದೆ:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ ಇದು ನಿಯಂತ್ರಣ ನೋಡ್ ಅನ್ನು ನೋಡುತ್ತದೆ:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ ಟ್ರಾಫಿಕ್ ಕಂಟ್ರೋಲ್ ನೋಡ್ ಅನ್ನು ತಲುಪಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಅದಕ್ಕೆ ಹೋಗಬೇಕು ಮತ್ತು ರೂಟಿಂಗ್ ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಬೇಕು.
ನಿಮಗೆ ನೆನಪಿರುವಂತೆ, ಒಳಗಿನ ನಿಯಂತ್ರಣ ನೋಡ್ ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ನಂತೆಯೇ ಕಾಣುತ್ತದೆ - ಅದೇ ಮೂರು ಸೇತುವೆಗಳು, ಕೇವಲ br-ex ಮಾತ್ರ ಭೌತಿಕ ಪೋರ್ಟ್ ಅನ್ನು ಹೊಂದಿದ್ದು, ಅದರ ಮೂಲಕ ನೋಡ್ ಹೊರಗೆ ಸಂಚಾರವನ್ನು ಕಳುಹಿಸಬಹುದು. ನಿದರ್ಶನಗಳ ರಚನೆಯು ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ಗಳಲ್ಲಿನ ಸಂರಚನೆಯನ್ನು ಬದಲಾಯಿಸಿತು - ಲಿನಕ್ಸ್ ಸೇತುವೆ, ಐಪ್ಟೇಬಲ್‌ಗಳು ಮತ್ತು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ನೋಡ್‌ಗಳಿಗೆ ಸೇರಿಸಲಾಯಿತು. ನೆಟ್‌ವರ್ಕ್‌ಗಳ ರಚನೆ ಮತ್ತು ವರ್ಚುವಲ್ ರೂಟರ್ ಸಹ ನಿಯಂತ್ರಣ ನೋಡ್‌ನ ಸಂರಚನೆಯ ಮೇಲೆ ತನ್ನ ಗುರುತು ಬಿಟ್ಟಿದೆ.
ಆದ್ದರಿಂದ, ಗೇಟ್ವೇ MAC ವಿಳಾಸವು ಕಂಟ್ರೋಲ್ ನೋಡ್‌ನಲ್ಲಿರುವ br-int ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಟೇಬಲ್‌ನಲ್ಲಿರಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಅದು ಇದೆಯೇ ಮತ್ತು ಎಲ್ಲಿ ನೋಡುತ್ತಿದೆ ಎಂದು ಪರಿಶೀಲಿಸೋಣ:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Mac ಪೋರ್ಟ್ qr-0c52b15f-8f ನಿಂದ ಗೋಚರಿಸುತ್ತದೆ. ನಾವು Openstack ನಲ್ಲಿ ವರ್ಚುವಲ್ ಪೋರ್ಟ್‌ಗಳ ಪಟ್ಟಿಗೆ ಹಿಂತಿರುಗಿದರೆ, OVS ಗೆ ವಿವಿಧ ವರ್ಚುವಲ್ ಸಾಧನಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು ಈ ರೀತಿಯ ಪೋರ್ಟ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, qr ಎಂಬುದು ವರ್ಚುವಲ್ ರೂಟರ್‌ಗೆ ಪೋರ್ಟ್ ಆಗಿದೆ, ಇದನ್ನು ನೇಮ್‌ಸ್ಪೇಸ್‌ನಂತೆ ಪ್ರತಿನಿಧಿಸಲಾಗುತ್ತದೆ.
ಸರ್ವರ್‌ನಲ್ಲಿ ಯಾವ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಿವೆ ಎಂದು ನೋಡೋಣ:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ ಮೂರು ಪ್ರತಿಗಳಷ್ಟೆ. ಆದರೆ ಹೆಸರುಗಳ ಮೂಲಕ ನಿರ್ಣಯಿಸುವುದು, ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದರ ಉದ್ದೇಶವನ್ನು ನೀವು ಊಹಿಸಬಹುದು. ನಾವು ನಂತರ ID 0 ಮತ್ತು 1 ರೊಂದಿಗಿನ ನಿದರ್ಶನಗಳಿಗೆ ಹಿಂತಿರುಗುತ್ತೇವೆ, ಈಗ ನಾವು ನೇಮ್‌ಸ್ಪೇಸ್ qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ನಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ ಈ ನೇಮ್‌ಸ್ಪೇಸ್ ನಾವು ಮೊದಲು ರಚಿಸಿದ ಎರಡು ಆಂತರಿಕ ಪದಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಎರಡೂ ವರ್ಚುವಲ್ ಪೋರ್ಟ್‌ಗಳನ್ನು br-int ಗೆ ಸೇರಿಸಲಾಗಿದೆ. ಪೋರ್ಟ್ qr-0c52b15f-8f ನ ಮ್ಯಾಕ್ ವಿಳಾಸವನ್ನು ಪರಿಶೀಲಿಸೋಣ, ಏಕೆಂದರೆ ಟ್ರಾಫಿಕ್, ಗಮ್ಯಸ್ಥಾನದ ಮ್ಯಾಕ್ ವಿಳಾಸದಿಂದ ನಿರ್ಣಯಿಸುವುದು, ಈ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಹೋಗಿದೆ.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ ಅಂದರೆ, ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಎಲ್ಲವೂ ಪ್ರಮಾಣಿತ ರೂಟಿಂಗ್ ನಿಯಮಗಳ ಪ್ರಕಾರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೋಸ್ಟ್ 10.0.2.8 ಗೆ ಉದ್ದೇಶಿಸಲಾಗಿರುವುದರಿಂದ, ಅದು ಎರಡನೇ ಇಂಟರ್ಫೇಸ್ qr-92fa49b5-54 ಮೂಲಕ ನಿರ್ಗಮಿಸಬೇಕು ಮತ್ತು ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ಗೆ vxlan ಸುರಂಗದ ಮೂಲಕ ಹೋಗಬೇಕು:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ ಎಲ್ಲವೂ ತಾರ್ಕಿಕವಾಗಿದೆ, ಆಶ್ಚರ್ಯವಿಲ್ಲ. br-int ನಲ್ಲಿ ಹೋಸ್ಟ್ 10.0.2.8 ನ ಗಸಗಸೆ ವಿಳಾಸವು ಎಲ್ಲಿ ಗೋಚರಿಸುತ್ತದೆ ಎಂದು ನೋಡೋಣ:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ ನಿರೀಕ್ಷೆಯಂತೆ, ದಟ್ಟಣೆಯು br-tun ಗೆ ಹೋಗುತ್ತದೆ, ಮುಂದಿನ ದಟ್ಟಣೆಯು ಯಾವ ಸುರಂಗಕ್ಕೆ ಹೋಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕಂಪ್ಯೂಟ್-1 ಮಾಡಲು ಸುರಂಗದೊಳಗೆ ಹೋಗುತ್ತದೆ. ಸರಿ, ಕಂಪ್ಯೂಟ್-1 ನಲ್ಲಿ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ - br-tun ನಿಂದ ಪ್ಯಾಕೇಜ್ br-int ಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ವರ್ಚುವಲ್ ಯಂತ್ರ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಹೋಗುತ್ತದೆ:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ ಇದು ನಿಜವಾಗಿಯೂ ಸರಿಯಾದ ಇಂಟರ್ಫೇಸ್ ಎಂದು ಪರಿಶೀಲಿಸೋಣ:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
ವಾಸ್ತವವಾಗಿ, ನಾವು ಪ್ಯಾಕೇಜ್ ಮೂಲಕ ಎಲ್ಲಾ ರೀತಿಯಲ್ಲಿ ಹೋದೆವು. ಟ್ರಾಫಿಕ್ ವಿಭಿನ್ನ vxlan ಸುರಂಗಗಳ ಮೂಲಕ ಸಾಗಿದೆ ಮತ್ತು ವಿಭಿನ್ನ VNIಗಳೊಂದಿಗೆ ನಿರ್ಗಮಿಸಿದೆ ಎಂದು ನೀವು ಗಮನಿಸಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಇವು ಯಾವ ರೀತಿಯ ವಿಎನ್‌ಐ ಎಂದು ನೋಡೋಣ, ಅದರ ನಂತರ ನಾವು ನೋಡ್‌ನ ನಿಯಂತ್ರಣ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಡಂಪ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು ಮೇಲೆ ವಿವರಿಸಿದಂತೆ ದಟ್ಟಣೆಯು ನಿಖರವಾಗಿ ಹರಿಯುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ಆದ್ದರಿಂದ, ಕಂಪ್ಯೂಟ್-0 ಗೆ ಸುರಂಗವು ಈ ಕೆಳಗಿನ ಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿದೆ=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ಔಟ್ಪುಟ್:3. 0x16 ಅನ್ನು ದಶಮಾಂಶ ಸಂಖ್ಯೆಯ ವ್ಯವಸ್ಥೆಗೆ ಪರಿವರ್ತಿಸೋಣ:
0x16 = 6*16^0+1*16^1 = 6+16 = 22ಕಂಪ್ಯೂಟ್-1 ಗೆ ಸುರಂಗವು ಈ ಕೆಳಗಿನ VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],ಔಟ್ಪುಟ್:2 ಅನ್ನು ಹೊಂದಿದೆ. 0x63 ಅನ್ನು ದಶಮಾಂಶ ಸಂಖ್ಯೆಯ ವ್ಯವಸ್ಥೆಗೆ ಪರಿವರ್ತಿಸೋಣ:
0x63 = 3*16^0+6*16^1 = 3+96 = 99ಸರಿ, ಈಗ ನಾವು ಡಂಪ್ ಅನ್ನು ನೋಡೋಣ:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************ಮೊದಲ ಪ್ಯಾಕೆಟ್ ಹೋಸ್ಟ್ 192.168.255.19 (ಕಂಪ್ಯೂಟ್-0) ನಿಂದ vni 192.168.255.15 ನೊಂದಿಗೆ 1 (ನಿಯಂತ್ರಣ-22) ಗೆ ಹೋಸ್ಟ್ ಮಾಡುವ vxlan ಪ್ಯಾಕೆಟ್ ಆಗಿದೆ, ಅದರೊಳಗೆ ICMP ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಹೋಸ್ಟ್ 10.0.1.85 ರಿಂದ 10.0.2.8 ಹೋಸ್ಟ್ XNUMX ಗೆ ಪ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ. ನಾವು ಮೇಲೆ ಲೆಕ್ಕ ಹಾಕಿದಂತೆ, vni ನಾವು ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ನೋಡಿದ್ದನ್ನು ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.
ಎರಡನೇ ಪ್ಯಾಕೆಟ್ ಹೋಸ್ಟ್ 192.168.255.15 (ನಿಯಂತ್ರಣ-1) ನಿಂದ vni 192.168.255.26 ನೊಂದಿಗೆ ಹೋಸ್ಟ್ 1 (ಕಂಪ್ಯೂಟ್-99) ಗೆ vxlan ಪ್ಯಾಕೆಟ್ ಆಗಿದೆ, ಅದರೊಳಗೆ ICMP ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಹೋಸ್ಟ್ 10.0.1.85 ರಿಂದ 10.0.2.8 ಹೋಸ್ಟ್ XNUMX ಗೆ ಪ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ. ನಾವು ಮೇಲೆ ಲೆಕ್ಕ ಹಾಕಿದಂತೆ, vni ನಾವು ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ನೋಡಿದ್ದನ್ನು ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.
ಮುಂದಿನ ಎರಡು ಪ್ಯಾಕೆಟ್‌ಗಳು 10.0.2.8 ರಿಂದ 10.0.1.85 ಅಲ್ಲ ರಿಟರ್ನ್ ಟ್ರಾಫಿಕ್ ಆಗಿದೆ.
ಅಂದರೆ, ಕೊನೆಯಲ್ಲಿ ನಾವು ಈ ಕೆಳಗಿನ ನಿಯಂತ್ರಣ ನೋಡ್ ಯೋಜನೆಯನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ:
ಹಾಗೆ ನೋಡಿದರೆ ಇದೆಯೇ? ನಾವು ಎರಡು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಮರೆತಿದ್ದೇವೆ:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ ನಾವು ಕ್ಲೌಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕುರಿತು ಮಾತನಾಡಿದಂತೆ, ಯಂತ್ರಗಳು DHCP ಸರ್ವರ್‌ನಿಂದ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವಿಳಾಸಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರೆ ಒಳ್ಳೆಯದು. ಇವು ನಮ್ಮ ಎರಡು ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗಾಗಿ ಎರಡು DHCP ಸರ್ವರ್‌ಗಳಾಗಿವೆ 10.0.1.0/24 ಮತ್ತು 10.0.2.0/24.
ಇದು ನಿಜವೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ. ಈ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಒಂದೇ ಒಂದು ವಿಳಾಸವಿದೆ - 10.0.1.1 - DHCP ಸರ್ವರ್‌ನ ವಿಳಾಸ, ಮತ್ತು ಇದನ್ನು br-int ನಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0ನಿಯಂತ್ರಣ ನೋಡ್ನಲ್ಲಿ ಅವರ ಹೆಸರಿನಲ್ಲಿ qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನೋಡೋಣ:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ ಅಂತಹ ಪ್ರಕ್ರಿಯೆ ಇದೆ ಮತ್ತು ಮೇಲಿನ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾದ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ, ಉದಾಹರಣೆಗೆ, ನಾವು ಪ್ರಸ್ತುತ ಬಾಡಿಗೆಗೆ ಏನನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಬಹುದು:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$ಪರಿಣಾಮವಾಗಿ, ನಾವು ನಿಯಂತ್ರಣ ನೋಡ್ನಲ್ಲಿ ಈ ಕೆಳಗಿನ ಸೇವೆಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ:
ಒಳ್ಳೆಯದು, ನೆನಪಿನಲ್ಲಿಡಿ - ಇದು ಕೇವಲ 4 ಯಂತ್ರಗಳು, 2 ಆಂತರಿಕ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಒಂದು ವರ್ಚುವಲ್ ರೂಟರ್ ಆಗಿದೆ... ನಾವು ಈಗ ಇಲ್ಲಿ ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ವಿಭಿನ್ನ ಯೋಜನೆಗಳ ಸಮೂಹ, ಪ್ರತಿಯೊಂದೂ ತಮ್ಮದೇ ಆದ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು (ಅತಿಕ್ರಮಿಸುವ) ಮತ್ತು ನಾವು ಹೊಂದಿದ್ದೇವೆ ವಿತರಿಸಿದ ರೂಟರ್ ಅನ್ನು ಆಫ್ ಮಾಡಲಾಗಿದೆ, ಮತ್ತು ಕೊನೆಯಲ್ಲಿ, ಪರೀಕ್ಷಾ ಬೆಂಚ್‌ನಲ್ಲಿ ಕೇವಲ ಒಂದು ನಿಯಂತ್ರಣ ನೋಡ್ ಇತ್ತು (ತಪ್ಪು ಸಹಿಷ್ಣುತೆಗಾಗಿ ಮೂರು ನೋಡ್ಗಳ ಕೋರಮ್ ಇರಬೇಕು). ವಾಣಿಜ್ಯದಲ್ಲಿ ಎಲ್ಲವೂ "ಸ್ವಲ್ಪ" ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ ಎಂಬುದು ತಾರ್ಕಿಕವಾಗಿದೆ, ಆದರೆ ಈ ಸರಳ ಉದಾಹರಣೆಯಲ್ಲಿ ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ - ನೀವು 3 ಅಥವಾ 300 ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಾ ಎಂಬುದು ಸಹಜವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ, ಆದರೆ ಕಾರ್ಯಾಚರಣೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ ಸಂಪೂರ್ಣ ರಚನೆ, ಯಾವುದೂ ಹೆಚ್ಚು ಬದಲಾಗುವುದಿಲ್ಲ... ಆದರೂ ನೀವು ಕೆಲವು ಮಾರಾಟಗಾರರ SDN ಅನ್ನು ಪ್ಲಗ್ ಇನ್ ಮಾಡುವುದಿಲ್ಲ. ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಕಥೆ.
ಇದು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನೀವು ಯಾವುದೇ ಕಾಮೆಂಟ್‌ಗಳು/ಸೇರ್ಪಡೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಅಥವಾ ಎಲ್ಲೋ ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ಸುಳ್ಳು ಹೇಳಿದರೆ (ನಾನು ಮನುಷ್ಯ ಮತ್ತು ನನ್ನ ಅಭಿಪ್ರಾಯ ಯಾವಾಗಲೂ ವ್ಯಕ್ತಿನಿಷ್ಠವಾಗಿರುತ್ತದೆ) - ಏನು ಸರಿಪಡಿಸಬೇಕು / ಸೇರಿಸಬೇಕು ಎಂಬುದನ್ನು ಬರೆಯಿರಿ - ನಾವು ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸುತ್ತೇವೆ / ಸೇರಿಸುತ್ತೇವೆ.
ಕೊನೆಯಲ್ಲಿ, VMWare ನಿಂದ ಕ್ಲೌಡ್ ಪರಿಹಾರದೊಂದಿಗೆ Openstack ಅನ್ನು (ವೆನಿಲ್ಲಾ ಮತ್ತು ಮಾರಾಟಗಾರರೆರಡನ್ನೂ) ಹೋಲಿಸುವ ಬಗ್ಗೆ ನಾನು ಕೆಲವು ಮಾತುಗಳನ್ನು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ - ಕಳೆದ ಎರಡು ವರ್ಷಗಳಿಂದ ನಾನು ಈ ಪ್ರಶ್ನೆಯನ್ನು ಆಗಾಗ್ಗೆ ಕೇಳುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಾನು ಈಗಾಗಲೇ ಅದರಿಂದ ದಣಿದಿದೆ, ಆದರೆ ಇನ್ನೂ. ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಈ ಎರಡು ಪರಿಹಾರಗಳನ್ನು ಹೋಲಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ, ಆದರೆ ಎರಡೂ ಪರಿಹಾರಗಳಲ್ಲಿ ಅನಾನುಕೂಲತೆಗಳಿವೆ ಎಂದು ನಾವು ಖಂಡಿತವಾಗಿ ಹೇಳಬಹುದು ಮತ್ತು ಒಂದು ಪರಿಹಾರವನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ ನೀವು ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ಅಳೆಯಬೇಕು.
OpenStack ಒಂದು ಸಮುದಾಯ-ಚಾಲಿತ ಪರಿಹಾರವಾಗಿದ್ದರೆ, VMWare ತನಗೆ ಬೇಕಾದುದನ್ನು ಮಾತ್ರ ಮಾಡುವ ಹಕ್ಕನ್ನು ಹೊಂದಿದೆ (ಓದಿ - ಅದಕ್ಕೆ ಲಾಭದಾಯಕವಾದದ್ದು) ಮತ್ತು ಇದು ತಾರ್ಕಿಕವಾಗಿದೆ - ಏಕೆಂದರೆ ಇದು ತನ್ನ ಗ್ರಾಹಕರಿಂದ ಹಣವನ್ನು ಗಳಿಸಲು ಬಳಸುವ ವಾಣಿಜ್ಯ ಕಂಪನಿಯಾಗಿದೆ. ಆದರೆ ಒಂದು ದೊಡ್ಡ ಮತ್ತು ಕೊಬ್ಬು ಇದೆ ಆದರೆ - ನೀವು ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನಿಂದ ಹೊರಬರಬಹುದು, ಉದಾಹರಣೆಗೆ Nokia ನಿಂದ, ಮತ್ತು ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ ಪರಿಹಾರಕ್ಕೆ ಬದಲಾಯಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಜುನಿಪರ್ (ಕಾಂಟ್ರೈಲ್ ಕ್ಲೌಡ್), ಆದರೆ ನೀವು VMWare ನಿಂದ ಹೊರಬರಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. . ನನಗೆ, ಈ ಎರಡು ಪರಿಹಾರಗಳು ಈ ರೀತಿ ಕಾಣುತ್ತವೆ - ಓಪನ್‌ಸ್ಟಾಕ್ (ಮಾರಾಟಗಾರ) ಸರಳವಾದ ಪಂಜರವಾಗಿದೆ, ಇದರಲ್ಲಿ ನೀವು ಇರಿಸಿದ್ದೀರಿ, ಆದರೆ ನಿಮ್ಮ ಬಳಿ ಕೀ ಇದೆ ಮತ್ತು ನೀವು ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ಬಿಡಬಹುದು. VMWare ಒಂದು ಚಿನ್ನದ ಪಂಜರವಾಗಿದೆ, ಮಾಲೀಕರು ಪಂಜರದ ಕೀಲಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಅದು ನಿಮಗೆ ಬಹಳಷ್ಟು ವೆಚ್ಚವಾಗುತ್ತದೆ.
ನಾನು ಮೊದಲ ಉತ್ಪನ್ನ ಅಥವಾ ಎರಡನೆಯದನ್ನು ಪ್ರಚಾರ ಮಾಡುತ್ತಿಲ್ಲ - ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ನೀವು ಆರಿಸಿಕೊಳ್ಳಿ. ಆದರೆ ನಾನು ಅಂತಹ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ನಾನು ಎರಡೂ ಪರಿಹಾರಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇನೆ - IT ಕ್ಲೌಡ್‌ಗಾಗಿ VMWare (ಕಡಿಮೆ ಲೋಡ್‌ಗಳು, ಸುಲಭ ನಿರ್ವಹಣೆ), ಕೆಲವು ಮಾರಾಟಗಾರರಿಂದ OpenStack (ನೋಕಿಯಾ ಮತ್ತು ಜುನಿಪರ್ ಉತ್ತಮ ಟರ್ನ್‌ಕೀ ಪರಿಹಾರಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ) - ಟೆಲಿಕಾಂ ಕ್ಲೌಡ್‌ಗಾಗಿ. ಶುದ್ಧ ಐಟಿಗಾಗಿ ನಾನು ಓಪನ್‌ಸ್ಟಾಕ್ ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ - ಇದು ಗುಬ್ಬಚ್ಚಿಗಳನ್ನು ಫಿರಂಗಿಯಿಂದ ಶೂಟ್ ಮಾಡುವಂತಿದೆ, ಆದರೆ ಪುನರುಜ್ಜೀವನವನ್ನು ಹೊರತುಪಡಿಸಿ ಅದನ್ನು ಬಳಸಲು ಯಾವುದೇ ವಿರೋಧಾಭಾಸಗಳನ್ನು ನಾನು ಕಾಣುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಟೆಲಿಕಾಂನಲ್ಲಿ VMWare ಅನ್ನು ಬಳಸುವುದು ಫೋರ್ಡ್ ರಾಪ್ಟರ್ನಲ್ಲಿ ಪುಡಿಮಾಡಿದ ಕಲ್ಲನ್ನು ಎಳೆಯುವಂತಿದೆ - ಇದು ಹೊರಗಿನಿಂದ ಸುಂದರವಾಗಿರುತ್ತದೆ, ಆದರೆ ಚಾಲಕನು ಒಂದರ ಬದಲಿಗೆ 10 ಟ್ರಿಪ್ಗಳನ್ನು ಮಾಡಬೇಕು.
ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, VMWare ನ ದೊಡ್ಡ ಅನನುಕೂಲವೆಂದರೆ ಅದರ ಸಂಪೂರ್ಣ ಮುಚ್ಚುವಿಕೆ - ಕಂಪನಿಯು ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಿಮಗೆ ಯಾವುದೇ ಮಾಹಿತಿಯನ್ನು ನೀಡುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, vSAN ಅಥವಾ ಹೈಪರ್ವೈಸರ್ ಕರ್ನಲ್ನಲ್ಲಿ ಏನಿದೆ - ಇದು ಕೇವಲ ಲಾಭದಾಯಕವಲ್ಲ - ಅಂದರೆ, ನೀವು VMWare ನಲ್ಲಿ ಎಂದಿಗೂ ಪರಿಣಿತರಾಗಬೇಡಿ - ಮಾರಾಟಗಾರರ ಬೆಂಬಲವಿಲ್ಲದೆ, ನೀವು ಅವನತಿ ಹೊಂದುತ್ತೀರಿ (ಸಾಮಾನ್ಯ ಪ್ರಶ್ನೆಗಳಿಂದ ಗೊಂದಲಕ್ಕೊಳಗಾದ VMWare ತಜ್ಞರನ್ನು ನಾನು ಆಗಾಗ್ಗೆ ಭೇಟಿಯಾಗುತ್ತೇನೆ). ನನಗೆ, VMWare ಹುಡ್ ಲಾಕ್ ಮಾಡಲಾದ ಕಾರನ್ನು ಖರೀದಿಸುತ್ತಿದೆ - ಹೌದು, ನೀವು ಟೈಮಿಂಗ್ ಬೆಲ್ಟ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ತಜ್ಞರನ್ನು ಹೊಂದಿರಬಹುದು, ಆದರೆ ಈ ಪರಿಹಾರವನ್ನು ನಿಮಗೆ ಮಾರಾಟ ಮಾಡಿದವರು ಮಾತ್ರ ಹುಡ್ ಅನ್ನು ತೆರೆಯಬಹುದು. ವೈಯಕ್ತಿಕವಾಗಿ, ನಾನು ಹೊಂದಿಕೊಳ್ಳದ ಪರಿಹಾರಗಳನ್ನು ನಾನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ. ನೀವು ಹುಡ್ ಅಡಿಯಲ್ಲಿ ಹೋಗಬೇಕಾಗಿಲ್ಲ ಎಂದು ನೀವು ಹೇಳುತ್ತೀರಿ. ಹೌದು, ಇದು ಸಾಧ್ಯ, ಆದರೆ ನೀವು 20-30 ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು, 40-50 ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಂದ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ದೊಡ್ಡ ಕಾರ್ಯವನ್ನು ಜೋಡಿಸಬೇಕಾದಾಗ ನಾನು ನಿಮ್ಮನ್ನು ನೋಡುತ್ತೇನೆ, ಅದರಲ್ಲಿ ಅರ್ಧದಷ್ಟು ಹೊರಗೆ ಹೋಗಲು ಬಯಸುತ್ತದೆ ಮತ್ತು ದ್ವಿತೀಯಾರ್ಧವು ಕೇಳುತ್ತದೆ SR-IOV ವೇಗವರ್ಧನೆ, ಇಲ್ಲದಿದ್ದರೆ ನಿಮಗೆ ಈ ಕಾರುಗಳಲ್ಲಿ ಒಂದೆರಡು ಡಜನ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ - ಇಲ್ಲದಿದ್ದರೆ ಕಾರ್ಯಕ್ಷಮತೆ ಸಾಕಾಗುವುದಿಲ್ಲ.
ಇತರ ದೃಷ್ಟಿಕೋನಗಳಿವೆ, ಆದ್ದರಿಂದ ಯಾವುದನ್ನು ಆರಿಸಬೇಕೆಂದು ನೀವು ಮಾತ್ರ ನಿರ್ಧರಿಸಬಹುದು ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ನಿಮ್ಮ ಆಯ್ಕೆಗೆ ನೀವು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತೀರಿ. ಇದು ನನ್ನ ಅಭಿಪ್ರಾಯ ಮಾತ್ರ - ನೋಕಿಯಾ, ಜುನಿಪರ್, ರೆಡ್ ಹ್ಯಾಟ್ ಮತ್ತು ವಿಎಂವೇರ್ - ಕನಿಷ್ಠ 4 ಉತ್ಪನ್ನಗಳನ್ನು ನೋಡಿದ ಮತ್ತು ಸ್ಪರ್ಶಿಸಿದ ವ್ಯಕ್ತಿ. ಅಂದರೆ, ನಾನು ಹೋಲಿಸಲು ಏನಾದರೂ ಇದೆ.
ಮೂಲ: www.habr.com