🥇Cisco ಮೀಟಿಂಗ್ ಸರ್ವರ್ 2.5.2. ವೀಡಿಯೊ ಕಾನ್ಫರೆನ್ಸ್ ರೆಕಾರ್ಡಿಂಗ್‌ನೊಂದಿಗೆ ಸ್ಕೇಲೆಬಲ್ ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಮೋಡ್‌ನಲ್ಲಿ ಕ್ಲಸ್ಟರ್

ಈ ಸಂಚಿಕೆಯಲ್ಲಿ ನಾನು ವಿಫಲವಾದ ಕ್ಲಸ್ಟರ್ ಮೋಡ್‌ನಲ್ಲಿ CMS ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಸುವ ಕೆಲವು ಜಟಿಲತೆಗಳನ್ನು ತೋರಿಸುತ್ತೇನೆ ಮತ್ತು ವಿವರಿಸುತ್ತೇನೆ.

ಸಿದ್ಧಾಂತಸಾಮಾನ್ಯವಾಗಿ, CMS ಸರ್ವರ್ ನಿಯೋಜನೆಯಲ್ಲಿ ಮೂರು ವಿಧಗಳಿವೆ:

ಏಕ ಸಂಯೋಜಿತ(ಏಕ ಸಂಯೋಜಿತ), ಅಂದರೆ. ಇದು ಎಲ್ಲಾ ಅಗತ್ಯ ಸೇವೆಗಳು ಚಾಲನೆಯಲ್ಲಿರುವ ಒಂದು ಸರ್ವರ್ ಆಗಿದೆ. ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಈ ರೀತಿಯ ನಿಯೋಜನೆಯು ಆಂತರಿಕ ಕ್ಲೈಂಟ್ ಪ್ರವೇಶಕ್ಕೆ ಮತ್ತು ಸಣ್ಣ ಪರಿಸರಗಳಲ್ಲಿ ಮಾತ್ರ ಸೂಕ್ತವಾಗಿದೆ, ಅಲ್ಲಿ ಒಂದೇ ಸರ್ವರ್‌ನ ಸ್ಕೇಲೆಬಿಲಿಟಿ ಮತ್ತು ರಿಡಂಡೆನ್ಸಿ ಮಿತಿಗಳು ನಿರ್ಣಾಯಕ ಸಮಸ್ಯೆಯಾಗಿಲ್ಲ, ಅಥವಾ CMS ಕೇವಲ ತಾತ್ಕಾಲಿಕ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಂದರ್ಭಗಳಲ್ಲಿ Cisco UCM ಕುರಿತು ಸಮ್ಮೇಳನಗಳು.
ಕೆಲಸದ ಅಂದಾಜು ಯೋಜನೆ:

ಏಕ ವಿಭಜನೆ(ಸಿಂಗಲ್ ಸ್ಪ್ಲಿಟ್) ಬಾಹ್ಯ ಪ್ರವೇಶಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಹಿಂದಿನ ನಿಯೋಜನೆ ಪ್ರಕಾರವನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ. ಪರಂಪರೆಯ ನಿಯೋಜನೆಗಳಲ್ಲಿ, ಬಾಹ್ಯ ಕ್ಲೈಂಟ್‌ಗಳು ಅದನ್ನು ಪ್ರವೇಶಿಸಬಹುದಾದ ಸೇನಾರಹಿತ ನೆಟ್‌ವರ್ಕ್ ವಿಭಾಗದಲ್ಲಿ (DMZ) CMS ಸರ್ವರ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದು ಮತ್ತು ಆಂತರಿಕ ಕ್ಲೈಂಟ್‌ಗಳು CMS ಅನ್ನು ಪ್ರವೇಶಿಸಬಹುದಾದ ನೆಟ್ವರ್ಕ್ ಕೋರ್‌ನಲ್ಲಿ ಒಂದು CMS ಸರ್ವರ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದು ಎಂದರ್ಥ. ಈ ನಿರ್ದಿಷ್ಟ ನಿಯೋಜನೆ ಮಾದರಿಯನ್ನು ಈಗ ಕರೆಯಲ್ಪಡುವ ಪ್ರಕಾರದಿಂದ ಬದಲಾಯಿಸಲಾಗುತ್ತಿದೆ ಸಿಂಗಲ್ ಎಡ್ಜ್, ಇದು ಸರ್ವರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಸಿಸ್ಕೋ ಎಕ್ಸ್‌ಪ್ರೆಸ್‌ವೇ, ಇದು ಒಂದೇ ರೀತಿಯ ಫೈರ್‌ವಾಲ್ ಬೈಪಾಸ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ ಅಥವಾ ಹೊಂದಿರುತ್ತದೆ ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್‌ಗಳು ಮೀಸಲಾದ ಎಡ್ಜ್ CMS ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.
ಕೆಲಸದ ಅಂದಾಜು ಯೋಜನೆ:

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

ನಿಯೋಜನೆಗೆ ತೆರಳುವ ಮೊದಲು, ನೀವು ಕೆಲವು ಮೂಲಭೂತ ವಿಷಯಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು, ಅವುಗಳೆಂದರೆ

ಮುಖ್ಯ CMS ಸಾಫ್ಟ್‌ವೇರ್ ಘಟಕಗಳು:

ಡೇಟಾಬೇಸ್: ಡಯಲ್ ಯೋಜನೆ, ಬಳಕೆದಾರ ಸ್ಥಳಗಳು ಮತ್ತು ಬಳಕೆದಾರರೇ ಮುಂತಾದ ಕೆಲವು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಗಾಗಿ (ಸಿಂಗಲ್ ಮಾಸ್ಟರ್) ಮಾತ್ರ ಕ್ಲಸ್ಟರಿಂಗ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
ಸೇತುವೆಗೆ ಕರೆ ಮಾಡಿ: ಕರೆಗಳು ಮತ್ತು ಮಲ್ಟಿಮೀಡಿಯಾ ಪ್ರಕ್ರಿಯೆಗಳ ನಿರ್ವಹಣೆ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಯ ಮೇಲೆ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣವನ್ನು ಒದಗಿಸುವ ಆಡಿಯೋ ಮತ್ತು ವೀಡಿಯೊ ಕಾನ್ಫರೆನ್ಸಿಂಗ್ ಸೇವೆ. ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ ಮತ್ತು ಸ್ಕೇಲೆಬಿಲಿಟಿಗಾಗಿ ಕ್ಲಸ್ಟರಿಂಗ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.
XMPP ಸರ್ವರ್: ಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು/ಅಥವಾ ವೆಬ್‌ಆರ್‌ಟಿಸಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಗ್ರಾಹಕರ ನೋಂದಣಿ ಮತ್ತು ದೃಢೀಕರಣದ ಜವಾಬ್ದಾರಿನೈಜ-ಸಮಯದ ಸಂವಹನ, ಅಥವಾ ಸರಳವಾಗಿ ಬ್ರೌಸರ್‌ನಲ್ಲಿ), ಹಾಗೆಯೇ ಇಂಟರ್ ಕಾಂಪೊನೆಂಟ್ ಸಿಗ್ನಲಿಂಗ್. ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಗಾಗಿ ಮಾತ್ರ ಕ್ಲಸ್ಟರ್ ಮಾಡಬಹುದು.
ವೆಬ್ ಸೇತುವೆ: WebRTC ಗೆ ಕ್ಲೈಂಟ್ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್: ಸಿಂಗಲ್ ಸ್ಪ್ಲಿಟ್ ಮೋಡ್‌ನಲ್ಲಿ ಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಒಂದೇ ಸಂಪರ್ಕ ಬಿಂದುವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಒಳಬರುವ ಸಂಪರ್ಕಗಳಿಗಾಗಿ ಬಾಹ್ಯ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಆಲಿಸುತ್ತದೆ. ಸಮಾನವಾಗಿ, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ XMPP ಸರ್ವರ್‌ನಿಂದ ಒಳಬರುವ TLS ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅದರ ಮೂಲಕ ಬಾಹ್ಯ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ TCP ಸಂಪರ್ಕಗಳನ್ನು ಬದಲಾಯಿಸಬಹುದು.
ನಮ್ಮ ಸನ್ನಿವೇಶದಲ್ಲಿ ಇದು ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ಟರ್ನ್ ಸರ್ವರ್: ಅನುಮತಿಸುವ ಫೈರ್ವಾಲ್ ಬೈಪಾಸ್ ತಂತ್ರಜ್ಞಾನವನ್ನು ಒದಗಿಸುತ್ತದೆ
ಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ SIP ಸಾಧನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಬಾಹ್ಯ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು ನಮ್ಮ CMS ಅನ್ನು ಫೈರ್‌ವಾಲ್ ಅಥವಾ NAT ಹಿಂದೆ ಇರಿಸಿ. ನಮ್ಮ ಸನ್ನಿವೇಶದಲ್ಲಿ ಇದು ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ವೆಬ್ ನಿರ್ವಾಹಕ: ವಿಶೇಷ ಏಕೀಕೃತ CM ಸಮ್ಮೇಳನಗಳು ಸೇರಿದಂತೆ ಆಡಳಿತಾತ್ಮಕ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು API ಪ್ರವೇಶ.

ಸಂರಚನಾ ವಿಧಾನಗಳು

ಇತರ ಸಿಸ್ಕೋ ಉತ್ಪನ್ನಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಸರ್ವರ್ ಯಾವುದೇ ರೀತಿಯ ನಿಯೋಜನೆಯನ್ನು ಸರಿಹೊಂದಿಸಲು ಮೂರು ಕಾನ್ಫಿಗರೇಶನ್ ವಿಧಾನಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ಕಮಾಂಡ್ ಲೈನ್ (CLI): ಆರಂಭಿಕ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಕಾರ್ಯಗಳಿಗಾಗಿ MMP ಎಂದು ಕರೆಯಲ್ಪಡುವ ಕಮಾಂಡ್ ಲೈನ್ ಇಂಟರ್ಫೇಸ್.
ವೆಬ್ ನಿರ್ವಾಹಕರು: ಪ್ರಾಥಮಿಕವಾಗಿ ಕಾಲ್‌ಬ್ರಿಡ್ಜ್ ಸಂಬಂಧಿತ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳಿಗಾಗಿ, ವಿಶೇಷವಾಗಿ ಒಂದು ಕ್ಲಸ್ಟರ್ ಅಲ್ಲದ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿಸುವಾಗ.
REST API ಅನ್ನು: ಅತ್ಯಂತ ಸಂಕೀರ್ಣವಾದ ಸಂರಚನಾ ಕಾರ್ಯಗಳು ಮತ್ತು ಕ್ಲಸ್ಟರ್ಡ್ ಡೇಟಾಬೇಸ್ ಸಂಬಂಧಿತ ಕಾರ್ಯಗಳಿಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಮೇಲಿನವುಗಳ ಜೊತೆಗೆ, ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ SFTP ಫೈಲ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸಲು-ಸಾಮಾನ್ಯವಾಗಿ ಪರವಾನಗಿಗಳು, ಪ್ರಮಾಣಪತ್ರಗಳು ಅಥವಾ ಲಾಗ್‌ಗಳು-CMS ಸರ್ವರ್‌ಗೆ ಮತ್ತು ಅದರಿಂದ.

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

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

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

ಅದೇ ನಿಯೋಜನೆ ಮಾರ್ಗದರ್ಶಿಗಳಲ್ಲಿ ಒಂದು XMPP ಸರ್ವರ್ ಹೊಂದಿರುವ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ.

ಮತ್ತು ಮೇಲಿನದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ಏಕೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ: ಇದು ವಿಫಲ ಮೋಡ್‌ನಲ್ಲಿರುವ ಕಾರಣ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, XMPP ಸರ್ವರ್ ಎಲ್ಲಾ ಮೂರು ನೋಡ್‌ಗಳಲ್ಲಿ ಇರುತ್ತದೆ.

ನಮ್ಮ ಮೂರೂ ಸರ್ವರ್‌ಗಳು ಅಪ್ ಆಗಿವೆ ಎಂದು ಭಾವಿಸಲಾಗಿದೆ.

DNS ದಾಖಲೆಗಳು

ನೀವು ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನೀವು DNS ದಾಖಲೆಗಳನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ А и ಎಸ್‌ಆರ್‌ವಿ ರೀತಿಯ:

ನಮ್ಮ DNS ದಾಖಲೆಗಳಲ್ಲಿ example.com ಮತ್ತು ಎರಡು ಡೊಮೇನ್‌ಗಳಿವೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ conf.example.com. Example.com ಎಂಬುದು ಎಲ್ಲಾ Cisco ಯೂನಿಫೈಡ್ ಕಮ್ಯುನಿಕೇಶನ್ ಮ್ಯಾನೇಜರ್ ಚಂದಾದಾರರು ತಮ್ಮ URI ಗಳಿಗಾಗಿ ಬಳಸಬಹುದಾದ ಡೊಮೇನ್ ಆಗಿದೆ, ಇದು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಇರುತ್ತದೆ ಅಥವಾ ಇರುವ ಸಾಧ್ಯತೆಯಿದೆ. ಅಥವಾ example.com ಬಳಕೆದಾರರು ತಮ್ಮ ಇಮೇಲ್ ವಿಳಾಸಗಳಿಗಾಗಿ ಬಳಸುವ ಅದೇ ಡೊಮೇನ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. ಅಥವಾ ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿರುವ ಜಬ್ಬರ್ ಕ್ಲೈಂಟ್ URI ಹೊಂದಿರಬಹುದು [ಇಮೇಲ್ ರಕ್ಷಿಸಲಾಗಿದೆ]. ಡೊಮೇನ್ conf.example.com ಎಂಬುದು Cisco ಮೀಟಿಂಗ್ ಸರ್ವರ್ ಬಳಕೆದಾರರಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಡೊಮೇನ್ ಆಗಿದೆ. ಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಸರ್ವರ್‌ನ ಡೊಮೇನ್ ಆಗಿರುತ್ತದೆ conf.example.com, ಆದ್ದರಿಂದ ಅದೇ ಜಬ್ಬರ್ ಬಳಕೆದಾರರಿಗೆ, ಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಸರ್ವರ್‌ಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಲು user@ URI ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆconf.example.com.

ಮೂಲ ಸಂರಚನೆ

ಕೆಳಗೆ ವಿವರಿಸಿದ ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ, ಆದರೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಅವುಗಳನ್ನು ಮಾಡಬೇಕಾಗಿದೆ.

QoS

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

ಪ್ರತಿ ಸರ್ವರ್ನಲ್ಲಿ ನಾವು ಈ ಆಜ್ಞೆಗಳನ್ನು ನಮೂದಿಸುತ್ತೇವೆ

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

ಹೀಗಾಗಿ, ಎಲ್ಲಾ ವೀಡಿಯೊ ಟ್ರಾಫಿಕ್ ಅನ್ನು AF41 (DSCP 0x22) ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ, ಎಲ್ಲಾ ಧ್ವನಿ ಸಂಚಾರವನ್ನು EF (DSCP 0x2E) ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ, SIP ಮತ್ತು XMPP ಯಂತಹ ಇತರ ರೀತಿಯ ಕಡಿಮೆ ಲೇಟೆನ್ಸಿ ಟ್ರಾಫಿಕ್ AF31 (DSCP 0x1A) ಅನ್ನು ಬಳಸುತ್ತದೆ.

ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

NTP ಯನ್ನು

ನೆಟ್‌ವರ್ಕ್ ಟೈಮ್ ಪ್ರೋಟೋಕಾಲ್ (NTP) ಕರೆಗಳು ಮತ್ತು ಕಾನ್ಫರೆನ್ಸ್‌ಗಳ ನಿಖರವಾದ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ಒದಗಿಸಲು ಮಾತ್ರವಲ್ಲದೆ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಸಹ ಮುಖ್ಯವಾಗಿದೆ.

NTP ಸರ್ವರ್‌ಗಳನ್ನು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಒಂದು ಆಜ್ಞೆಯೊಂದಿಗೆ ಸೇರಿಸಿ

ntp server add <server>

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಅಂತಹ ಎರಡು ಸರ್ವರ್‌ಗಳಿವೆ, ಆದ್ದರಿಂದ ಎರಡು ತಂಡಗಳು ಇರುತ್ತವೆ.
ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

ಮತ್ತು ನಮ್ಮ ಸರ್ವರ್‌ಗಾಗಿ ಸಮಯ ವಲಯವನ್ನು ಹೊಂದಿಸಿ

ಡಿಎನ್ಎಸ್

ನಾವು CMS ಗೆ DNS ಸರ್ವರ್‌ಗಳನ್ನು ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ ಸೇರಿಸುತ್ತೇವೆ:

dns add forwardzone <domain-name> <server ip>

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಅಂತಹ ಎರಡು ಸರ್ವರ್‌ಗಳಿವೆ, ಆದ್ದರಿಂದ ಎರಡು ತಂಡಗಳು ಇರುತ್ತವೆ.
ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್ ಕಾನ್ಫಿಗರೇಶನ್

ನಾವು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ:

ipv4 <interface> add <address>/<prefix length> <gateway>

ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

ಸರ್ವರ್ ಹೆಸರು (ಹೋಸ್ಟ್ ಹೆಸರು)

ನಾವು ಸರ್ವರ್ ಹೆಸರನ್ನು ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ ಹೊಂದಿಸಿದ್ದೇವೆ:

hostname <name>

ಮತ್ತು ನಾವು ರೀಬೂಟ್ ಮಾಡುತ್ತೇವೆ.

ಇದು ಮೂಲ ಸಂರಚನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ.

ಪ್ರಮಾಣಪತ್ರಗಳು

ಸಿದ್ಧಾಂತಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಸರ್ವರ್‌ಗೆ ವಿವಿಧ ಘಟಕಗಳ ನಡುವೆ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಸಂವಹನದ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ, ಎಲ್ಲಾ CMS ನಿಯೋಜನೆಗಳಿಗೆ X.509 ಪ್ರಮಾಣಪತ್ರಗಳ ಅಗತ್ಯವಿದೆ. ಸೇವೆಗಳು/ಸರ್ವರ್ ಅನ್ನು ಇತರ ಸರ್ವರ್‌ಗಳು/ಸೇವೆಗಳಿಂದ ನಂಬಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಅವರು ಸಹಾಯ ಮಾಡುತ್ತಾರೆ.

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

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

ಕೆಲಸ ಮಾಡಲು ಪುನರಾವರ್ತನೆಗಾಗಿ, ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳು ಕನಿಷ್ಠ 3 ಸರ್ವರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರಬೇಕು, ಆದರೆ 5 ಕ್ಕಿಂತ ಹೆಚ್ಚಿಲ್ಲ, ಯಾವುದೇ ಕ್ಲಸ್ಟರ್ ಸದಸ್ಯರ ನಡುವೆ ಗರಿಷ್ಠ ರೌಂಡ್-ಟ್ರಿಪ್ ಸಮಯ 200 ms. ಈ ಮಿತಿಯು ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಕ್ಲಸ್ಟರಿಂಗ್‌ಗಿಂತ ಹೆಚ್ಚು ನಿರ್ಬಂಧಿತವಾಗಿದೆ, ಆದ್ದರಿಂದ ಭೌಗೋಳಿಕವಾಗಿ ವಿತರಿಸಲಾದ ನಿಯೋಜನೆಗಳಲ್ಲಿ ಇದು ಹೆಚ್ಚಾಗಿ ಸೀಮಿತಗೊಳಿಸುವ ಅಂಶವಾಗಿದೆ.

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

CMS ಒಂದು ಮಾಸ್ಟರ್ ಮತ್ತು ಹಲವಾರು ಸಂಪೂರ್ಣವಾಗಿ ಒಂದೇ ರೀತಿಯ ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಒಂದು ಸಮಯದಲ್ಲಿ ಕೇವಲ ಒಂದು ಪ್ರಾಥಮಿಕ ಡೇಟಾಬೇಸ್ ಇರುತ್ತದೆ ("ಡೇಟಾಬೇಸ್ ಸರ್ವರ್"). ಕ್ಲಸ್ಟರ್‌ನ ಉಳಿದ ಸದಸ್ಯರು ಪ್ರತಿಕೃತಿಗಳು ಅಥವಾ "ಡೇಟಾಬೇಸ್ ಕ್ಲೈಂಟ್‌ಗಳು".

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

ಆದ್ದರಿಂದ, ಡೇಟಾಬೇಸ್ ಹೊರತುಪಡಿಸಿ ಎಲ್ಲಾ ಸರ್ವರ್ ಸೇವೆಗಳಿಂದ ಬಳಸಲಾಗುವ ಪ್ರಮಾಣಪತ್ರಕ್ಕಾಗಿ ನಾವು ವಿನಂತಿಯನ್ನು ರಚಿಸುತ್ತೇವೆ (ಇದಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ವಿನಂತಿ ಇರುತ್ತದೆ) ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

CN ನಲ್ಲಿ ನಾವು ನಮ್ಮ ಸರ್ವರ್‌ಗಳ ಸಾಮಾನ್ಯ ಹೆಸರನ್ನು ಬರೆಯುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಸರ್ವರ್‌ಗಳ ಹೋಸ್ಟ್ ಹೆಸರುಗಳು ಸರ್ವರ್ 01, ಸರ್ವರ್ 02, ಸರ್ವರ್ 03, ನಂತರ CN ಇರುತ್ತದೆ server.example.com

ಆಜ್ಞೆಗಳು ಅನುಗುಣವಾದ “ಹೋಸ್ಟ್ ಹೆಸರುಗಳನ್ನು” ಒಳಗೊಂಡಿರುವ ವ್ಯತ್ಯಾಸದೊಂದಿಗೆ ಉಳಿದ ಎರಡು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಾವು ಅದೇ ರೀತಿ ಮಾಡುತ್ತೇವೆ

ನಾವು ಪ್ರಮಾಣಪತ್ರಗಳಿಗಾಗಿ ಎರಡು ವಿನಂತಿಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ ಅದನ್ನು ಡೇಟಾಬೇಸ್ ಸೇವೆಯು ಈ ರೀತಿಯ ಆಜ್ಞೆಗಳೊಂದಿಗೆ ಬಳಸುತ್ತದೆ:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

ಅಲ್ಲಿ dbclusterserver и dbclusterclient ನಮ್ಮ ವಿನಂತಿಗಳ ಹೆಸರುಗಳು ಮತ್ತು ಭವಿಷ್ಯದ ಪ್ರಮಾಣಪತ್ರಗಳು, ಹೋಸ್ಟ್ ಹೆಸರು1(2)(3) ಅನುಗುಣವಾದ ಸರ್ವರ್‌ಗಳ ಹೆಸರುಗಳು.

ನಾವು ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿ ಮಾತ್ರ ನಿರ್ವಹಿಸುತ್ತೇವೆ (!), ಮತ್ತು ನಾವು ಪ್ರಮಾಣಪತ್ರಗಳು ಮತ್ತು ಅನುಗುಣವಾದ .ಕೀ ಫೈಲ್‌ಗಳನ್ನು ಇತರ ಸರ್ವರ್‌ಗಳಿಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತೇವೆ.

AD CS ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರ ಮೋಡ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ

ನೀವು ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಒಂದು ಫೈಲ್‌ಗೆ ವಿಲೀನಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ.*NIX ನಲ್ಲಿ:

cat server01.cer server02.cer server03.cer > server.cer

Windows/DOS ನಲ್ಲಿ:

copy server01.cer + server02.cer + server03.cer  server.cer

ಮತ್ತು ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ:
1. "ವೈಯಕ್ತಿಕ" ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರ.
2. ರೂಟ್ ಪ್ರಮಾಣಪತ್ರ (ಮಧ್ಯಂತರ ಜೊತೆ, ಯಾವುದಾದರೂ ಇದ್ದರೆ).
3. ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಪ್ರಮಾಣಪತ್ರಗಳು ("ಸರ್ವರ್" ಮತ್ತು "ಕ್ಲೈಂಟ್") ಮತ್ತು "ಸರ್ವರ್" ಮತ್ತು "ಕ್ಲೈಂಟ್" ಡೇಟಾಬೇಸ್ ಪ್ರಮಾಣಪತ್ರಗಳಿಗಾಗಿ ವಿನಂತಿಯನ್ನು ರಚಿಸುವಾಗ ರಚಿಸಲಾದ .ಕೀ ವಿಸ್ತರಣೆಯೊಂದಿಗೆ ಫೈಲ್‌ಗಳು. ಈ ಫೈಲ್‌ಗಳು ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದೇ ಆಗಿರಬೇಕು.
4. ಎಲ್ಲಾ ಮೂರು "ವೈಯಕ್ತಿಕ" ಪ್ರಮಾಣಪತ್ರಗಳ ಫೈಲ್.

ಪರಿಣಾಮವಾಗಿ, ನೀವು ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಈ ಫೈಲ್ ಚಿತ್ರದಂತಹದನ್ನು ಪಡೆಯಬೇಕು.

ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್

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

ಮಾಸ್ಟರ್ ಡೇಟಾಬೇಸ್

ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿಸುವ ಮೊದಲ ಹಂತವೆಂದರೆ ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಬಳಸಲಾಗುವ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು. ಈ ರೀತಿಯ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

ಆಜ್ಞೆಯೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರಿಂಗ್‌ಗಾಗಿ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬಳಸಬೇಕೆಂದು ಈಗ CMS ಗೆ ಹೇಳೋಣ:

database cluster localnode a

ನಂತರ ನಾವು ಮುಖ್ಯ ಸರ್ವರ್‌ನಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಆಜ್ಞೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ:

database cluster initialize

ಕ್ಲೈಂಟ್ ಡೇಟಾಬೇಸ್ ನೋಡ್‌ಗಳು

ನಾವು ಅದೇ ಕಾರ್ಯವಿಧಾನವನ್ನು ಮಾಡುತ್ತೇವೆ, ಆಜ್ಞೆಯ ಬದಲಿಗೆ ಮಾತ್ರ ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಈ ರೀತಿಯ ಆಜ್ಞೆಯನ್ನು ನಮೂದಿಸಿ:

database cluster join <ip address existing master>

ಅಲ್ಲಿ ip ವಿಳಾಸ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ CMS ಸರ್ವರ್‌ನ ಮಾಸ್ಟರ್ ip ವಿಳಾಸ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ, ಸರಳವಾಗಿ ಮಾಸ್ಟರ್.

ಆಜ್ಞೆಯೊಂದಿಗೆ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಮ್ಮ ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

database cluster status

ಉಳಿದ ಮೂರನೇ ಸರ್ವರ್‌ನಲ್ಲಿ ನಾವು ಅದೇ ರೀತಿ ಮಾಡುತ್ತೇವೆ.

ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮ ಮೊದಲ ಸರ್ವರ್ ಮಾಸ್ಟರ್, ಉಳಿದವರು ಗುಲಾಮರು ಎಂದು ತಿರುಗುತ್ತದೆ.

ವೆಬ್ ನಿರ್ವಾಹಕ ಸೇವೆ

ವೆಬ್ ನಿರ್ವಾಹಕರ ಸೇವೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ:

webadmin listen a 445

ಪೋರ್ಟ್ 445 ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ ಏಕೆಂದರೆ ವೆಬ್ ಕ್ಲೈಂಟ್‌ಗೆ ಬಳಕೆದಾರರ ಪ್ರವೇಶಕ್ಕಾಗಿ ಪೋರ್ಟ್ 443 ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ

ನಾವು ವೆಬ್ ನಿರ್ವಾಹಕ ಸೇವೆಯನ್ನು ಪ್ರಮಾಣಪತ್ರ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ:

webadmin certs <keyfile> <certificatefile> <ca bundle>

ಮತ್ತು ಆಜ್ಞೆಯೊಂದಿಗೆ ವೆಬ್ ನಿರ್ವಹಣೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ:

webadmin enable

ಎಲ್ಲವೂ ಸರಿಯಾಗಿದ್ದರೆ, ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರಕ್ಕಾಗಿ ವೆಬ್ ನಿರ್ವಾಹಕರನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುವ ಯಶಸ್ಸಿನ ಸಾಲುಗಳನ್ನು ನಾವು ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ನಾವು ವೆಬ್ ಬ್ರೌಸರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸೇವೆಯ ಕಾರ್ಯವನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು ವೆಬ್ ನಿರ್ವಾಹಕರ ವಿಳಾಸವನ್ನು ನಮೂದಿಸಿ, ಉದಾಹರಣೆಗೆ: cms.example.com: 445

ಬ್ರಿಡ್ಜ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಕರೆ ಮಾಡಿ

ಪ್ರತಿ CMS ನಿಯೋಜನೆಯಲ್ಲಿ ಇರುವ ಏಕೈಕ ಸೇವೆ ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಆಗಿದೆ. ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಮುಖ್ಯ ಕಾನ್ಫರೆನ್ಸಿಂಗ್ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ. ಇದು SIP ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಸಹ ಒದಗಿಸುತ್ತದೆ ಇದರಿಂದ ಕರೆಗಳನ್ನು ಅದರ ಮೂಲಕ ಅಥವಾ ಅದಕ್ಕೆ ಕಳುಹಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಸಿಸ್ಕೋ ಯುನಿಫೈಡ್ CM.

ಕೆಳಗೆ ವಿವರಿಸಿದ ಆಜ್ಞೆಗಳನ್ನು ಸೂಕ್ತ ಪ್ರಮಾಣಪತ್ರಗಳೊಂದಿಗೆ ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು.
ಆದ್ದರಿಂದ:

ನಾವು ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಸೇವೆಯೊಂದಿಗೆ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತೇವೆ:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

ನಾವು ಕಾಲ್‌ಬ್ರಿಡ್ಜ್ ಸೇವೆಗಳನ್ನು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಆಜ್ಞೆಯೊಂದಿಗೆ ಬಂಧಿಸುತ್ತೇವೆ:

callbridge listen a

ಮತ್ತು ಆಜ್ಞೆಯೊಂದಿಗೆ ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ:

callbridge restart

ಈಗ ನಾವು ನಮ್ಮ ಕರೆ ಸೇತುವೆಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೇವೆ, ನಾವು ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಕ್ಲಸ್ಟರಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಕ್ಲಸ್ಟರಿಂಗ್ ಡೇಟಾಬೇಸ್ ಅಥವಾ XMPP ಕ್ಲಸ್ಟರಿಂಗ್‌ಗಿಂತ ಭಿನ್ನವಾಗಿದೆ. ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಕ್ಲಸ್ಟರ್ ಯಾವುದೇ ನಿರ್ಬಂಧಗಳಿಲ್ಲದೆ 2 ರಿಂದ 8 ನೋಡ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಇದು ಪುನರಾವರ್ತನೆಯನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಅನ್ನು ಸಹ ಒದಗಿಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಬುದ್ಧಿವಂತ ಕರೆ ವಿತರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಸಮ್ಮೇಳನಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ವಿತರಿಸಬಹುದು. CMS ಹೆಚ್ಚುವರಿ ವೈಶಿಷ್ಟ್ಯಗಳು, ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಗುಂಪುಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ನಿರ್ವಹಣೆಗಾಗಿ ಬಳಸಬಹುದಾದ ಸಂಬಂಧಿತ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದೆ.

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

1. ವೆಬ್ ಮೂಲಕ ಕಾನ್ಫಿಗರೇಶನ್ > ಕ್ಲಸ್ಟರ್ ಗೆ ಹೋಗಿ.
2. ಇನ್ ಸೇತುವೆ ಗುರುತನ್ನು ಕರೆ ಮಾಡಿ ಅನನ್ಯ ಹೆಸರಾಗಿ, ಸರ್ವರ್ ಹೆಸರಿಗೆ ಅನುಗುಣವಾಗಿ ಕಾಲ್‌ಬ್ರಿಡ್ಜ್[01,02,03] ಅನ್ನು ನಮೂದಿಸಿ. ಈ ಹೆಸರುಗಳು ಅನಿಯಂತ್ರಿತವಾಗಿವೆ, ಆದರೆ ಈ ಕ್ಲಸ್ಟರ್‌ಗೆ ಅನನ್ಯವಾಗಿರಬೇಕು. ಅವು ನಿಸರ್ಗದಲ್ಲಿ ವಿವರಣಾತ್ಮಕವಾಗಿವೆ ಏಕೆಂದರೆ ಅವುಗಳು ಸರ್ವರ್ ಗುರುತಿಸುವಿಕೆಗಳು [01,02,03] ಎಂದು ಸೂಚಿಸುತ್ತವೆ.
3.ಬಿ ಕ್ಲಸ್ಟರ್ಡ್ ಕಾಲ್ ಬ್ರಿಡ್ಜ್‌ಗಳು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಮ್ಮ ಸರ್ವರ್‌ಗಳ ವೆಬ್ ನಿರ್ವಾಹಕರ URL ಗಳನ್ನು ನಮೂದಿಸಿ, ಸೆಂ[01,02,03].example.com:445, ವಿಳಾಸ ಕ್ಷೇತ್ರದಲ್ಲಿ. ಪೋರ್ಟ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಮರೆಯದಿರಿ. ನೀವು ಪೀರ್ ಲಿಂಕ್ SIP ಡೊಮೇನ್ ಅನ್ನು ಖಾಲಿ ಬಿಡಬಹುದು.
4. ಪ್ರತಿ ಸರ್ವರ್‌ನ ಕಾಲ್‌ಬ್ರಿಡ್ಜ್ ಟ್ರಸ್ಟ್‌ಗೆ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸೇರಿಸಿ, ಅದರ ಫೈಲ್ ನಮ್ಮ ಸರ್ವರ್‌ಗಳ ಎಲ್ಲಾ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ನಾವು ಈ ಫೈಲ್‌ಗೆ ಪ್ರಾರಂಭದಲ್ಲಿಯೇ ವಿಲೀನಗೊಂಡಿದ್ದೇವೆ, ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ:

callbridge trust cluster <trusted cluster certificate bundle>

ಮತ್ತು ಆಜ್ಞೆಯೊಂದಿಗೆ ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ:

callbridge restart

ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ನೀವು ಈ ಚಿತ್ರವನ್ನು ಪಡೆಯಬೇಕು:

XMPP ಕ್ಲಸ್ಟರ್

CMS ನಲ್ಲಿನ XMPP ಸೇವೆಯನ್ನು CMA WebRTC ವೆಬ್ ಕ್ಲೈಂಟ್ ಸೇರಿದಂತೆ Cisco Meeting Apps (CMA) ಗಾಗಿ ಎಲ್ಲಾ ನೋಂದಣಿ ಮತ್ತು ದೃಢೀಕರಣವನ್ನು ನಿರ್ವಹಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಸ್ವತಃ ದೃಢೀಕರಣ ಉದ್ದೇಶಗಳಿಗಾಗಿ XMPP ಕ್ಲೈಂಟ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಇತರ ಕ್ಲೈಂಟ್‌ಗಳಂತೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು. XMPP ದೋಷ ಸಹಿಷ್ಣುತೆಯು ಆವೃತ್ತಿ 2.1 ರಿಂದ ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಬೆಂಬಲಿತವಾದ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ

ನಾವು XMPP ಸೇವೆಯೊಂದಿಗೆ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತೇವೆ:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

ನಂತರ ಆಜ್ಞೆಯೊಂದಿಗೆ ಆಲಿಸುವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ:

xmpp listen a

XMPP ಸೇವೆಗೆ ಅನನ್ಯ ಡೊಮೇನ್ ಅಗತ್ಯವಿದೆ. ಇದು ಬಳಕೆದಾರರಿಗೆ ಲಾಗಿನ್ ಆಗಿದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, CMA ಅಪ್ಲಿಕೇಶನ್ ಬಳಸಿ (ಅಥವಾ WebRTC ಕ್ಲೈಂಟ್ ಮೂಲಕ) ಲಾಗಿನ್ ಮಾಡಲು ಬಳಕೆದಾರರು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಅವರು userID@logindomain ಅನ್ನು ನಮೂದಿಸುತ್ತಾರೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಇದು userid@ ಆಗಿರುತ್ತದೆconf.example.com. ಇದು ಕೇವಲ example.com ಏಕೆ ಅಲ್ಲ? ನಮ್ಮ ನಿರ್ದಿಷ್ಟ ನಿಯೋಜನೆಯಲ್ಲಿ, ಜಬ್ಬರ್ ಬಳಕೆದಾರರು ಯುನಿಫೈಡ್ ಸಿಎಮ್‌ನಲ್ಲಿ ಉದಾಹರಣೆ.ಕಾಮ್‌ನಲ್ಲಿ ಬಳಸುವ ನಮ್ಮ ಯುನಿಫೈಡ್ ಸಿಎಮ್ ಡೊಮೇನ್ ಅನ್ನು ನಾವು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಸಿಎಮ್‌ಎಸ್ ಬಳಕೆದಾರರಿಗೆ ಎಸ್‌ಐಪಿ ಡೊಮೇನ್‌ಗಳ ಮೂಲಕ ಸಿಎಮ್‌ಎಸ್‌ಗೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಕರೆಗಳನ್ನು ಮಾಡಲು ನಮಗೆ ಬೇರೆ ಡೊಮೇನ್ ಅಗತ್ಯವಿದೆ.

ಈ ರೀತಿಯ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು XMPP ಡೊಮೇನ್ ಅನ್ನು ಹೊಂದಿಸಿ:

xmpp domain <domain>

ಮತ್ತು ಆಜ್ಞೆಯೊಂದಿಗೆ XMPP ಸೇವೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ:

xmpp enable

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

ಈಗ ನಾವು XMPP ಸೇವೆಯನ್ನು ಮೊದಲ ಸರ್ವರ್‌ನಲ್ಲಿ ಮೂರು ಕಾಲ್ ಬ್ರಿಡ್ಜ್‌ಗಳು callbridge01, callbridge02 ಮತ್ತು callbridge03 ನೊಂದಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿದೆ. ಪ್ರತಿ ಖಾತೆಗೆ ಯಾದೃಚ್ಛಿಕ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ನಿಗದಿಪಡಿಸಲಾಗುತ್ತದೆ. ಈ XMPP ಸರ್ವರ್‌ಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಲು ಅವುಗಳನ್ನು ನಂತರ ಇತರ ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ನಮೂದಿಸಲಾಗುತ್ತದೆ. ಕೆಳಗಿನ ಆಜ್ಞೆಗಳನ್ನು ನಮೂದಿಸಿ:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

ಪರಿಣಾಮವಾಗಿ, ಆಜ್ಞೆಯೊಂದಿಗೆ ಏನಾಯಿತು ಎಂಬುದನ್ನು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

xmpp callbridge list

ಕೆಳಗೆ ವಿವರಿಸಿದ ಹಂತಗಳ ನಂತರ ಅದೇ ಚಿತ್ರವು ಉಳಿದ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಗೋಚರಿಸಬೇಕು.

ಮುಂದೆ, ನಾವು ಉಳಿದ ಎರಡು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತೇವೆ, ಆಜ್ಞೆಗಳೊಂದಿಗೆ ಮಾತ್ರ

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

ನಾವು ರಹಸ್ಯವನ್ನು ಬಹಳ ಎಚ್ಚರಿಕೆಯಿಂದ ಸೇರಿಸುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ, ಅದರಲ್ಲಿ ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಸ್ಥಳಗಳಿಲ್ಲ.

ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿ ಸರ್ವರ್ ಒಂದೇ ಚಿತ್ರವನ್ನು ಹೊಂದಿರಬೇಕು:

ಮುಂದೆ, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ, ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ ಈ ಹಿಂದೆ ರಚಿಸಲಾದ ಎಲ್ಲಾ ಮೂರು ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಹೊಂದಿರುವ ಫೈಲ್ ಅನ್ನು ನಾವು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ:

xmpp cluster trust <trust bundle>

ನಾವು ಆಜ್ಞೆಯೊಂದಿಗೆ ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ xmpp ಕ್ಲಸ್ಟರ್ ಮೋಡ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ:

xmpp cluster enable

ಕ್ಲಸ್ಟರ್‌ನ ಮೊದಲ ಸರ್ವರ್‌ನಲ್ಲಿ, ನಾವು ಆಜ್ಞೆಯೊಂದಿಗೆ xmpp ಕ್ಲಸ್ಟರ್‌ನ ರಚನೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ:

xmpp cluster initialize

ಇತರ ಸರ್ವರ್‌ಗಳಲ್ಲಿ, xmpp ಗೆ ಒಂದು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ ಸೇರಿಸಿ:

xmpp cluster join <ip address head xmpp server>

ಆಜ್ಞೆಗಳೊಂದಿಗೆ ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ XMPP ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸುವ ಯಶಸ್ಸನ್ನು ನಾವು ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸುತ್ತೇವೆ:

xmpp status
xmpp cluster status

ಮೊದಲ ಸರ್ವರ್:

ಎರಡನೇ ಸರ್ವರ್:

ಮೂರನೇ ಸರ್ವರ್:

XMPP ಗೆ ಕರೆ ಸೇತುವೆಯನ್ನು ಸಂಪರ್ಕಿಸಲಾಗುತ್ತಿದೆ

ಈಗ XMPP ಕ್ಲಸ್ಟರ್ ಚಾಲನೆಯಲ್ಲಿದೆ, XMPP ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ನೀವು ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಸೇವೆಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಈ ಸಂರಚನೆಯನ್ನು ವೆಬ್ ನಿರ್ವಾಹಕರ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ.

ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ, ಕಾನ್ಫಿಗರೇಶನ್> ಸಾಮಾನ್ಯ ಮತ್ತು ಕ್ಷೇತ್ರದಲ್ಲಿ ಹೋಗಿ ವಿಶಿಷ್ಟ ಕರೆ ಸೇತುವೆ ಹೆಸರು ಸರ್ವರ್‌ಗೆ ಅನುಗುಣವಾದ ಅನನ್ಯ ಕಾಲ್ ಬ್ರಿಡ್ಜ್ ಹೆಸರುಗಳನ್ನು ಬರೆಯಿರಿ ಕಾಲ್ಬ್ರಿಡ್ಜ್[01,02,03]... ಕ್ಷೇತ್ರದಲ್ಲಿ ಡೊಮೇನ್ conf.example.ru ಮತ್ತು ಅನುಗುಣವಾದ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು, ನೀವು ಅವುಗಳ ಮೇಲೆ ಕಣ್ಣಿಡಬಹುದು
ಆಜ್ಞೆಯೊಂದಿಗೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಯಾವುದೇ ಸರ್ವರ್‌ನಲ್ಲಿ:

xmpp callbridge list

"ಸರ್ವರ್" ಕ್ಷೇತ್ರವನ್ನು ಖಾಲಿ ಬಿಡಿ ಕಾಲ್ಬ್ರಿಡ್ಜ್ ಗಾಗಿ DNS SRV ಲುಕಪ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ _xmpp-component._tcp.conf.example.comಲಭ್ಯವಿರುವ XMPP ಸರ್ವರ್ ಅನ್ನು ಹುಡುಕಲು. XMPP ಗೆ ಕಾಲ್‌ಬ್ರಿಡ್ಜ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು IP ವಿಳಾಸಗಳು ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ಭಿನ್ನವಾಗಿರಬಹುದು, ಇದು ರೆಕಾರ್ಡ್ ವಿನಂತಿಗೆ ಯಾವ ಮೌಲ್ಯಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. _xmpp-component._tcp.conf.example.com ಕಾಲ್‌ಬ್ರಿಡ್ಜ್, ಇದು ನೀಡಿದ DNS ದಾಖಲೆಗಾಗಿ ಆದ್ಯತೆಯ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ಮುಂದೆ, ಕಾಲ್ ಬ್ರೈಡ್ ಸೇವೆಯು XMPP ಸೇವೆಗೆ ಯಶಸ್ವಿಯಾಗಿ ಸಂಪರ್ಕಗೊಂಡಿದೆಯೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಲು ಸ್ಥಿತಿ > ಸಾಮಾನ್ಯಕ್ಕೆ ಹೋಗಿ.

ವೆಬ್ ಸೇತುವೆ

ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ, ಆಜ್ಞೆಯೊಂದಿಗೆ ವೆಬ್ ಸೇತುವೆ ಸೇವೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ:

webbridge listen a:443

ನಾವು ವೆಬ್ ಬ್ರಿಡ್ಜ್ ಸೇವೆಯನ್ನು ಪ್ರಮಾಣಪತ್ರ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ಈ ರೀತಿಯ ಆಜ್ಞೆಯೊಂದಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

ವೆಬ್ ಸೇತುವೆ HTTPS ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. "http-redirect" ಅನ್ನು ಬಳಸಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ ಅದು HTTP ಅನ್ನು HTTPS ಗೆ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ.
HTTP ಮರುನಿರ್ದೇಶನವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು, ಈ ಕೆಳಗಿನ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ:

webbridge http-redirect enable

ವೆಬ್ ಬ್ರಿಡ್ಜ್ ಕಾಲ್ ಬ್ರಿಡ್ಜ್‌ನಿಂದ ಸಂಪರ್ಕಗಳನ್ನು ನಂಬಬಹುದು ಎಂದು ಕಾಲ್ ಬ್ರಿಡ್ಜ್ಗೆ ತಿಳಿಸಲು, ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ:

webbridge trust <certfile>

ಇದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಪ್ರತಿ ಸರ್ವರ್‌ನಿಂದ ಎಲ್ಲಾ ಮೂರು ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಹೊಂದಿರುವ ಫೈಲ್ ಆಗಿದೆ.

ಈ ಚಿತ್ರವು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಸರ್ವರ್‌ನಲ್ಲಿರಬೇಕು.

ಈಗ ನಾವು "ಅಪ್ಪಾಡ್ಮಿನ್" ಪಾತ್ರವನ್ನು ಹೊಂದಿರುವ ಬಳಕೆದಾರರನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ, ನಮಗೆ ಇದು ಅಗತ್ಯವಿದೆ ಇದರಿಂದ ನಾವು ನಮ್ಮ ಕ್ಲಸ್ಟರ್ (!) ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಸರ್ವರ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಅಲ್ಲ, ಈ ರೀತಿಯಾಗಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಸಮಾನವಾಗಿ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ ಅವರು ಒಮ್ಮೆ ಮಾಡಲಾಗುವುದು ಎಂದು ವಾಸ್ತವವಾಗಿ.

ಮತ್ತಷ್ಟು ಸೆಟಪ್ಗಾಗಿ ನಾವು ಬಳಸುತ್ತೇವೆ ಪೋಸ್ಟ್ಮ್ಯಾನ್.

ದೃಢೀಕರಣಕ್ಕಾಗಿ, ದೃಢೀಕರಣ ವಿಭಾಗದಲ್ಲಿ ಬೇಸಿಕ್ ಆಯ್ಕೆಮಾಡಿ

CMS ಸರ್ವರ್‌ಗೆ ಆಜ್ಞೆಗಳನ್ನು ಸರಿಯಾಗಿ ಕಳುಹಿಸಲು, ನೀವು ಅಗತ್ಯವಿರುವ ಎನ್‌ಕೋಡಿಂಗ್ ಅನ್ನು ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ

ನಾವು ಆಜ್ಞೆಯೊಂದಿಗೆ ವೆಬ್ಬ್ರಿಡ್ಜ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ POST ನಿಯತಾಂಕದೊಂದಿಗೆ url ಅನ್ನು ಮತ್ತು ಅರ್ಥ cms.example.com

ವೆಬ್ಬ್ರಿಡ್ಜ್ನಲ್ಲಿಯೇ, ನಾವು ಅಗತ್ಯವಿರುವ ನಿಯತಾಂಕಗಳನ್ನು ಸೂಚಿಸುತ್ತೇವೆ: ಅತಿಥಿ ಪ್ರವೇಶ, ಸಂರಕ್ಷಿತ ಪ್ರವೇಶ, ಇತ್ಯಾದಿ.

ಸೇತುವೆ ಗುಂಪುಗಳಿಗೆ ಕರೆ ಮಾಡಿ

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, CMS ಯಾವಾಗಲೂ ತನಗೆ ಲಭ್ಯವಿರುವ ಕಾನ್ಫರೆನ್ಸಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳ ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ ಬಳಕೆಯನ್ನು ಮಾಡುವುದಿಲ್ಲ.

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

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

ಮರುಸಂಪರ್ಕ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ಪ್ರತಿ ಕರೆ ಸೇತುವೆಗೆ ಮೂರು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ಲೋಡ್ ಮಿತಿಗಳನ್ನು ಪರಿಚಯಿಸಲಾಗಿದೆ:

ಲೋಡ್‌ಲಿಮಿಟ್ — ಇದು ನಿರ್ದಿಷ್ಟ ಕಾಲ್ ಬ್ರಿಡ್ಜ್‌ಗೆ ಗರಿಷ್ಠ ಸಂಖ್ಯಾತ್ಮಕ ಲೋಡ್ ಆಗಿದೆ. ಪ್ರತಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಶಿಫಾರಸು ಮಾಡಲಾದ ಲೋಡ್ ಮಿತಿಯನ್ನು ಹೊಂದಿದೆ, ಉದಾಹರಣೆಗೆ CMS96000 ಗಾಗಿ 1000 ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರಕ್ಕಾಗಿ ಪ್ರತಿ vCPU ಗೆ 1.25 GHz. ಭಾಗವಹಿಸುವವರ ರೆಸಲ್ಯೂಶನ್ ಮತ್ತು ಫ್ರೇಮ್ ದರವನ್ನು ಅವಲಂಬಿಸಿ ವಿಭಿನ್ನ ಕರೆಗಳು ನಿರ್ದಿಷ್ಟ ಪ್ರಮಾಣದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತವೆ.
ಹೊಸ ಕಾನ್ಫರೆನ್ಸ್‌ಲೋಡ್‌ಲಿಮಿಟ್ ಬೇಸಿಸ್ ಪಾಯಿಂಟ್‌ಗಳು (ಡೀಫಾಲ್ಟ್ 50% ಲೋಡ್‌ಲಿಮಿಟ್) - ಸರ್ವರ್ ಲೋಡ್ ಮಿತಿಯನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಅದರ ನಂತರ ಹೊಸ ಸಮ್ಮೇಳನಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.
ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕಾನ್ಫರೆನ್ಸ್‌ಲೋಡ್‌ಲಿಮಿಟ್ ಬೇಸಿಸ್ ಪಾಯಿಂಟ್‌ಗಳು (ಲೋಡ್‌ಲಿಮಿಟ್‌ನ ಡೀಫಾಲ್ಟ್ 80%) - ಸರ್ವರ್ ಲೋಡ್ ಮೌಲ್ಯದ ನಂತರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕಾನ್ಫರೆನ್ಸ್‌ಗೆ ಸೇರುವ ಭಾಗವಹಿಸುವವರನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.

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

ಈ ನಿಯತಾಂಕಗಳನ್ನು ಇಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ: cms.example.com:445/api/v1/system/configuration/cluster

ಮುಂದೆ, ನಾವು ಪ್ರತಿ ಕಾಲ್ಬ್ರಿಡ್ಜ್ಗೆ ಯಾವ ಕಾಲ್ಬ್ರಿಡ್ಜ್ ಗುಂಪಿಗೆ ಸೇರಿದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತೇವೆ:

ಮೊದಲ ಕಾಲ್ಬ್ರಿಡ್ಜ್

ಎರಡನೇ ಕಾಲ್ಬ್ರಿಡ್ಜ್

ಮೂರನೇ ಕಾಲ್ಬ್ರಿಡ್ಜ್

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

ಸಕ್ರಿಯ ಡೈರೆಕ್ಟರಿಯಿಂದ ಬಳಕೆದಾರರನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳಲಾಗುತ್ತಿದೆ

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

ಪ್ರವೇಶಿಸಲು URL ಅನ್ನು ಬಳಸುವುದು cms01.example.com:445/api/v1/ldapServers LDAP ಸರ್ವರ್ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ, ಅಂತಹ ನಿಯತಾಂಕಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ:

ಸರ್ವರ್ IP
ಪೋರ್ಟ್ ಸಂಖ್ಯೆ
ಬಳಕೆದಾರಹೆಸರು
ಪಾಸ್ವರ್ಡ್
ಭದ್ರತೆಗೆ

ಸುರಕ್ಷಿತ - ಪೋರ್ಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿ ಸರಿ ಅಥವಾ ತಪ್ಪು ಆಯ್ಕೆಮಾಡಿ, 389 - ಸುರಕ್ಷಿತವಲ್ಲ, 636 - ರಕ್ಷಿಸಲಾಗಿದೆ.

ಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಸರ್ವರ್‌ನಲ್ಲಿನ ಗುಣಲಕ್ಷಣಗಳಿಗೆ LDAP ಮೂಲ ನಿಯತಾಂಕಗಳನ್ನು ಮ್ಯಾಪಿಂಗ್ ಮಾಡುವುದು.
LDAP ಮ್ಯಾಪಿಂಗ್ LDAP ಡೈರೆಕ್ಟರಿಯಲ್ಲಿರುವ ಗುಣಲಕ್ಷಣಗಳನ್ನು CMS ನಲ್ಲಿನ ಗುಣಲಕ್ಷಣಗಳಿಗೆ ನಕ್ಷೆ ಮಾಡುತ್ತದೆ. ನಿಜವಾದ ಗುಣಲಕ್ಷಣಗಳು:

ಜಿಡ್ಮ್ಯಾಪಿಂಗ್
ಹೆಸರು ಮ್ಯಾಪಿಂಗ್
coSpaceNameMapping
coSpaceUriMapping
coSpaceSecondaryUriMapping

ಗುಣಲಕ್ಷಣಗಳ ವಿವರಣೆಜೆಐಡಿ CMS ನಲ್ಲಿ ಬಳಕೆದಾರರ ಲಾಗಿನ್ ಐಡಿಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಇದು ಮೈಕ್ರೋಸಾಫ್ಟ್ ಆಕ್ಟಿವ್ ಡೈರೆಕ್ಟರಿ LDAP ಸರ್ವರ್ ಆಗಿರುವುದರಿಂದ, CMS JID LDAP ನಲ್ಲಿನ sAMAccountName ಗೆ ಮ್ಯಾಪ್ ಮಾಡುತ್ತದೆ, ಇದು ಮೂಲಭೂತವಾಗಿ ಬಳಕೆದಾರರ ಸಕ್ರಿಯ ಡೈರೆಕ್ಟರಿ ಲಾಗಿನ್ ಐಡಿಯಾಗಿದೆ. ನೀವು sAMAccountName ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೀರಿ ಮತ್ತು ಅದರ ಕೊನೆಯಲ್ಲಿ conf.pod6.cms.lab ಡೊಮೇನ್ ಅನ್ನು ಸೇರಿಸಿ ಏಕೆಂದರೆ ಇದು ನಿಮ್ಮ ಬಳಕೆದಾರರು CMS ಗೆ ಲಾಗ್ ಇನ್ ಆಗಲು ಬಳಸುವ ಲಾಗಿನ್ ಆಗಿದೆ.

ಹೆಸರು ಮ್ಯಾಪಿಂಗ್ ಆಕ್ಟಿವ್ ಡೈರೆಕ್ಟರಿ ಡಿಸ್‌ಪ್ಲೇ ನೇಮ್ ಫೀಲ್ಡ್‌ನಲ್ಲಿ ಏನಿದೆಯೋ ಅದನ್ನು ಬಳಕೆದಾರರ CMS ಹೆಸರಿನ ಕ್ಷೇತ್ರಕ್ಕೆ ಹೊಂದಿಸುತ್ತದೆ.

coSpaceNameMapping ಡಿಸ್ಪ್ಲೇ ನೇಮ್ ಕ್ಷೇತ್ರವನ್ನು ಆಧರಿಸಿ CMS ಸ್ಪೇಸ್ ಹೆಸರನ್ನು ರಚಿಸುತ್ತದೆ. ಈ ಗುಣಲಕ್ಷಣವು, coSpaceUriMapping ಗುಣಲಕ್ಷಣದ ಜೊತೆಗೆ, ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೆ ಒಂದು ಸ್ಪೇಸ್ ರಚಿಸಲು ಅಗತ್ಯವಿದೆ.

coSpaceUriMapping ಬಳಕೆದಾರರ ವೈಯಕ್ತಿಕ ಸ್ಥಳದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ URI ಯ ಬಳಕೆದಾರರ ಭಾಗವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಕೆಲವು ಡೊಮೇನ್‌ಗಳನ್ನು ಬಾಹ್ಯಾಕಾಶಕ್ಕೆ ಡಯಲ್ ಮಾಡಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಬಳಕೆದಾರರ ಭಾಗವು ಈ ಡೊಮೇನ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಈ ಕ್ಷೇತ್ರಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತಿದ್ದರೆ, ಕರೆಯನ್ನು ಆ ಬಳಕೆದಾರರ ಜಾಗಕ್ಕೆ ನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ.

coSpaceSecondaryUriMapping ಬಾಹ್ಯಾಕಾಶವನ್ನು ತಲುಪಲು ಎರಡನೇ URI ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. coSpaceUriMapping ಪ್ಯಾರಾಮೀಟರ್‌ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಆಲ್ಫಾನ್ಯೂಮರಿಕ್ URI ಗೆ ಪರ್ಯಾಯವಾಗಿ ಆಮದು ಮಾಡಿಕೊಂಡ ಬಳಕೆದಾರರ ಜಾಗಕ್ಕೆ ಕರೆಗಳನ್ನು ರೂಟಿಂಗ್ ಮಾಡಲು ಸಂಖ್ಯಾ ಅಲಿಯಾಸ್ ಅನ್ನು ಸೇರಿಸಲು ಇದನ್ನು ಬಳಸಬಹುದು.

LDAP ಸರ್ವರ್ ಮತ್ತು LDAP ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ಈಗ ನೀವು LDAP ಮೂಲವನ್ನು ರಚಿಸುವ ಮೂಲಕ ಅವುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಲಿಂಕ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ಪ್ರವೇಶಿಸಲು URL ಅನ್ನು ಬಳಸುವುದು cms01.example.com:445/api/v1/ldapSource LDAP ಮೂಲ ವಸ್ತುವನ್ನು ರಚಿಸುತ್ತದೆ, ಅಂತಹ ನಿಯತಾಂಕಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ:

ಸರ್ವರ್
ಮ್ಯಾಪಿಂಗ್
ಬೇಸ್ ಡಿಎನ್
ಫಿಲ್ಟರ್

ಈಗ LDAP ಸಂರಚನೆಯು ಪೂರ್ಣಗೊಂಡಿದೆ, ನೀವು ಹಸ್ತಚಾಲಿತ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡಬಹುದು.

ಕ್ಲಿಕ್ ಮಾಡುವ ಮೂಲಕ ಪ್ರತಿ ಸರ್ವರ್‌ನ ವೆಬ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ನಾವು ಇದನ್ನು ಮಾಡುತ್ತೇವೆ ಈಗ ಸಿಂಕ್ ಮಾಡಿ ವಿಭಾಗದಲ್ಲಿ ಸಕ್ರಿಯ ಡೈರೆಕ್ಟರಿ

ಅಥವಾ ಆಜ್ಞೆಯೊಂದಿಗೆ API ಮೂಲಕ POST ಪ್ರವೇಶಿಸಲು URL ಅನ್ನು ಬಳಸಿ cms01.example.com:445/api/v1/ldapSyncs

ತಾತ್ಕಾಲಿಕ ಸಮ್ಮೇಳನಗಳು

ಇದು ಏನು?ಸಾಂಪ್ರದಾಯಿಕ ಪರಿಕಲ್ಪನೆಯಲ್ಲಿ, ಕಾನ್ಫರೆನ್ಸ್ ಎಂದರೆ ಇಬ್ಬರು ಭಾಗವಹಿಸುವವರು ಪರಸ್ಪರ ಮಾತನಾಡುತ್ತಿರುವಾಗ ಮತ್ತು ಭಾಗವಹಿಸುವವರಲ್ಲಿ ಒಬ್ಬರು (ಏಕೀಕೃತ CM ನೊಂದಿಗೆ ನೋಂದಾಯಿಸಲಾದ ಸಾಧನವನ್ನು ಬಳಸಿ) "ಕಾನ್ಫರೆನ್ಸ್" ಗುಂಡಿಯನ್ನು ಒತ್ತಿ, ಇತರ ವ್ಯಕ್ತಿಗೆ ಕರೆ ಮಾಡಿ ಮತ್ತು ಆ ಮೂರನೇ ವ್ಯಕ್ತಿಯೊಂದಿಗೆ ಮಾತನಾಡಿದ ನಂತರ , ತ್ರಿಪಕ್ಷೀಯ ಸಮ್ಮೇಳನದಲ್ಲಿ ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರನ್ನು ಸೇರಲು "ಕಾನ್ಫರೆನ್ಸ್" ಬಟನ್ ಅನ್ನು ಮತ್ತೊಮ್ಮೆ ಒತ್ತುತ್ತದೆ.

CMS ನಲ್ಲಿ ನಿಗದಿತ ಕಾನ್ಫರೆನ್ಸ್‌ನಿಂದ ಅಡ್-ಹಾಕ್ ಕಾನ್ಫರೆನ್ಸ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಏನೆಂದರೆ, ಆಡ್-ಹಾಕ್ ಕಾನ್ಫರೆನ್ಸ್ ಕೇವಲ CMS ಗೆ SIP ಕರೆ ಅಲ್ಲ. ಎಲ್ಲರನ್ನು ಒಂದೇ ಸಭೆಗೆ ಆಹ್ವಾನಿಸಲು ಕಾನ್ಫರೆನ್ಸ್ ಇನಿಶಿಯೇಟರ್ ಎರಡನೇ ಬಾರಿಗೆ ಕಾನ್ಫರೆನ್ಸ್ ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಏಕೀಕೃತ CM CMS ಗೆ API ಕರೆಯನ್ನು ಮಾಡಬೇಕು ಮತ್ತು ನಂತರ ಎಲ್ಲಾ ಕರೆಗಳನ್ನು ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. ಭಾಗವಹಿಸುವವರು ಗಮನಿಸದೆ ಇದೆಲ್ಲವೂ ಸಂಭವಿಸುತ್ತದೆ.

ಇದರರ್ಥ ಏಕೀಕೃತ CM API ರುಜುವಾತುಗಳು ಮತ್ತು ವೆಬ್‌ಅಡ್ಮಿನ್ ವಿಳಾಸ/ಸೇವೆಯ ಪೋರ್ಟ್ ಮತ್ತು ಕರೆಯನ್ನು ಮುಂದುವರಿಸಲು ನೇರವಾಗಿ CMS ಸರ್ವರ್‌ಗೆ SIP ಟ್ರಂಕ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು.

ಅಗತ್ಯವಿದ್ದರೆ, CUCM ಕ್ರಿಯಾತ್ಮಕವಾಗಿ CMS ನಲ್ಲಿ ಜಾಗವನ್ನು ರಚಿಸಬಹುದು ಇದರಿಂದ ಪ್ರತಿ ಕರೆ CMS ಅನ್ನು ತಲುಪಬಹುದು ಮತ್ತು ಸ್ಥಳಗಳಿಗೆ ಉದ್ದೇಶಿಸಿರುವ ಒಳಬರುವ ಕರೆ ನಿಯಮವನ್ನು ಹೊಂದಿಸಬಹುದು.

CUCM ನೊಂದಿಗೆ ಏಕೀಕರಣ ಲೇಖನದಲ್ಲಿ ವಿವರಿಸಿದಂತೆ ಅದೇ ರೀತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಮೊದಲು Cisco UCM ನಲ್ಲಿ ನೀವು CMS ಗಾಗಿ ಮೂರು ಟ್ರಂಕ್‌ಗಳನ್ನು ರಚಿಸಬೇಕು, ಮೂರು ಕಾನ್ಫರೆನ್ಸ್ ಸೇತುವೆಗಳು, SIP ಭದ್ರತಾ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಮೂರು ವಿಷಯದ ಹೆಸರುಗಳು, ಮಾರ್ಗ ಗುಂಪುಗಳು, ಮಾರ್ಗ ಪಟ್ಟಿಗಳು, ಮಾಧ್ಯಮ ಸಂಪನ್ಮೂಲ ಗುಂಪುಗಳು ಮತ್ತು ಮಾಧ್ಯಮ ಸಂಪನ್ಮೂಲ ಗುಂಪು ಪಟ್ಟಿಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ ಮತ್ತು ಕೆಲವು ರೂಟಿಂಗ್ ನಿಯಮಗಳನ್ನು ಸೇರಿಸಿ ಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಸರ್ವರ್‌ಗೆ.

SIP ಭದ್ರತಾ ಪ್ರೊಫೈಲ್:

ಕಾಂಡಗಳು:

ಪ್ರತಿಯೊಂದು ಕಾಂಡವು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಸಮ್ಮೇಳನ ಸೇತುವೆ

ಪ್ರತಿ ಸಮ್ಮೇಳನ ಸೇತುವೆಯು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಮಾರ್ಗ ಗುಂಪು

ಮಾರ್ಗ ಪಟ್ಟಿ

ಮಾಧ್ಯಮ ಸಂಪನ್ಮೂಲ ಗುಂಪು

ಮಾಧ್ಯಮ ಸಂಪನ್ಮೂಲ ಗುಂಪು ಪಟ್ಟಿ

ಕರೆ ನಿಯಮಗಳು

ಯುನಿಫೈಡ್ CM ಅಥವಾ ಎಕ್ಸ್‌ಪ್ರೆಸ್‌ವೇಯಂತಹ ಹೆಚ್ಚು ಸುಧಾರಿತ ಕರೆ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, CMS ಹೊಸ ಕರೆಗಳಿಗಾಗಿ SIP ವಿನಂತಿ-URI ಕ್ಷೇತ್ರದಲ್ಲಿ ಡೊಮೇನ್ ಅನ್ನು ಮಾತ್ರ ಹುಡುಕುತ್ತದೆ. ಆದ್ದರಿಂದ SIP ಆಹ್ವಾನವು ಸಿಪ್‌ಗಾಗಿ ಆಗಿದ್ದರೆ: [ಇಮೇಲ್ ರಕ್ಷಿಸಲಾಗಿದೆ]CMS ಕೇವಲ domain.com ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುತ್ತದೆ. ಕರೆಯನ್ನು ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕೆಂದು ನಿರ್ಧರಿಸಲು CMS ಈ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ:

1. CMS ಮೊದಲು SIP ಡೊಮೇನ್ ಅನ್ನು ಒಳಬರುವ ಕರೆ ನಿಯಮಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಡೊಮೇನ್‌ಗಳೊಂದಿಗೆ ಹೊಂದಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಈ ಕರೆಗಳನ್ನು ನಂತರ ("ಉದ್ದೇಶಿತ") ಸ್ಪೇಸ್‌ಗಳು ಅಥವಾ ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರು, ಆಂತರಿಕ IVR ಗಳು ಅಥವಾ ನೇರವಾಗಿ ಸಂಯೋಜಿತವಾದ Microsoft Lync/Skype for Business (S4B) ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ರೂಟ್ ಮಾಡಬಹುದು.
2. ಒಳಬರುವ ಕರೆ ನಿಯಮಗಳಲ್ಲಿ ಯಾವುದೇ ಹೊಂದಾಣಿಕೆ ಇಲ್ಲದಿದ್ದರೆ, ಕರೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಕೋಷ್ಟಕದಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಡೊಮೇನ್ ಅನ್ನು ಹೊಂದಿಸಲು CMS ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಹೊಂದಾಣಿಕೆಯನ್ನು ಮಾಡಿದರೆ, ನಿಯಮವು ಕರೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತಿರಸ್ಕರಿಸಬಹುದು ಅಥವಾ ಕರೆಯನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದು. ಈ ಸಮಯದಲ್ಲಿ, CMS ಡೊಮೇನ್ ಅನ್ನು ಪುನಃ ಬರೆಯಬಹುದು, ಇದು ಕೆಲವೊಮ್ಮೆ Lync ಡೊಮೇನ್‌ಗಳಿಗೆ ಕರೆ ಮಾಡಲು ಉಪಯುಕ್ತವಾಗಿದೆ. ನೀವು ಥ್ರೋ ಅನ್ನು ಪಾಸ್ ಮಾಡಲು ಸಹ ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಅಂದರೆ ಯಾವುದೇ ಕ್ಷೇತ್ರಗಳನ್ನು ಮತ್ತಷ್ಟು ಮಾರ್ಪಡಿಸಲಾಗುವುದಿಲ್ಲ ಅಥವಾ ಆಂತರಿಕ CMS ಡಯಲ್ ಯೋಜನೆಯನ್ನು ಬಳಸಿ. ಕರೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ನಿಯಮಗಳಲ್ಲಿ ಯಾವುದೇ ಹೊಂದಾಣಿಕೆ ಇಲ್ಲದಿದ್ದರೆ, ಕರೆಯನ್ನು ತಿರಸ್ಕರಿಸುವುದು ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ. CMS ನಲ್ಲಿ, ಕರೆಯನ್ನು "ಫಾರ್ವರ್ಡ್" ಮಾಡಲಾಗಿದ್ದರೂ, ಮಾಧ್ಯಮವು ಇನ್ನೂ CMS ಗೆ ಬದ್ಧವಾಗಿದೆ, ಅಂದರೆ ಅದು ಸಿಗ್ನಲಿಂಗ್ ಮತ್ತು ಮಾಧ್ಯಮ ಸಂಚಾರ ಮಾರ್ಗದಲ್ಲಿ ಇರುತ್ತದೆ.
ನಂತರ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಕರೆಗಳು ಮಾತ್ರ ಹೊರಹೋಗುವ ಕರೆ ನಿಯಮಗಳಿಗೆ ಒಳಪಟ್ಟಿರುತ್ತವೆ. ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಕರೆಗಳನ್ನು ಕಳುಹಿಸುವ ಸ್ಥಳಗಳು, ಟ್ರಂಕ್ ಪ್ರಕಾರ (ಅದು ಹೊಸ ಲಿಂಕ್ ಕರೆ ಅಥವಾ ಪ್ರಮಾಣಿತ SIP ಕರೆ ಆಗಿರಲಿ), ಮತ್ತು ಕರೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ನಿಯಮದಲ್ಲಿ ವರ್ಗಾವಣೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡದಿದ್ದರೆ ನಿರ್ವಹಿಸಬಹುದಾದ ಯಾವುದೇ ಪರಿವರ್ತನೆಗಳನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಅಡ್-ಹಾಕ್ ಸಮ್ಮೇಳನದಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ನಿಜವಾದ ಲಾಗ್ ಇಲ್ಲಿದೆ

ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ಅದನ್ನು ಕಳಪೆಯಾಗಿ ತೋರಿಸುತ್ತದೆ (ಅದನ್ನು ಹೇಗೆ ಉತ್ತಮಗೊಳಿಸಬೇಕೆಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ), ಆದ್ದರಿಂದ ನಾನು ಲಾಗ್ ಅನ್ನು ಈ ರೀತಿ ಬರೆಯುತ್ತೇನೆ:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

ಅಡ್-ಹಾಕ್ ಕಾನ್ಫರೆನ್ಸ್ ಸ್ವತಃ:

ಒಳಬರುವ ಕರೆ ನಿಯಮಗಳು
CMS ನಲ್ಲಿ ಕರೆ ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಒಳಬರುವ ಕರೆಗಳ ನಿಯತಾಂಕಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಅವಶ್ಯಕ. ನೀವು LDAP ಸೆಟಪ್‌ನಲ್ಲಿ ನೋಡಿದಂತೆ, ಎಲ್ಲಾ ಬಳಕೆದಾರರನ್ನು conf.pod6.cms.lab ಡೊಮೇನ್‌ನೊಂದಿಗೆ ಆಮದು ಮಾಡಿಕೊಳ್ಳಲಾಗಿದೆ. ಆದ್ದರಿಂದ ಕನಿಷ್ಠ, ನೀವು ಸ್ಥಳಗಳನ್ನು ಗುರಿಯಾಗಿಸಲು ಈ ಡೊಮೇನ್‌ಗೆ ಕರೆಗಳನ್ನು ಬಯಸುತ್ತೀರಿ. ಪ್ರತಿಯೊಂದು CMS ಸರ್ವರ್‌ಗಳ ಸಂಪೂರ್ಣ ಅರ್ಹ ಡೊಮೇನ್ ಹೆಸರಿಗಾಗಿ (ಮತ್ತು ಬಹುಶಃ IP ವಿಳಾಸವೂ ಸಹ) ಉದ್ದೇಶಿಸಿರುವ ಎಲ್ಲದಕ್ಕೂ ನೀವು ನಿಯಮಗಳನ್ನು ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ. ನಮ್ಮ ಬಾಹ್ಯ ಕರೆ ನಿಯಂತ್ರಣ, ಏಕೀಕೃತ CM, ಪ್ರತಿಯೊಂದು CMS ಸರ್ವರ್‌ಗಳಿಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಮೀಸಲಾಗಿರುವ SIP ಟ್ರಂಕ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ. ಈ SIP ಟ್ರಂಕ್‌ಗಳ ಗಮ್ಯಸ್ಥಾನವು IP ವಿಳಾಸವೇ ಅಥವಾ ಸರ್ವರ್‌ನ FQDN ಅದರ IP ವಿಳಾಸ ಅಥವಾ FQDN ಗೆ ನಿರ್ದೇಶಿಸಲಾದ ಕರೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲು CMS ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಒಳಬರುವ ನಿಯಮವನ್ನು ಹೊಂದಿರುವ ಡೊಮೇನ್ ಅನ್ನು ಯಾವುದೇ ಬಳಕೆದಾರರ ಸ್ಥಳಗಳಿಗೆ ಡೊಮೇನ್ ಆಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಬಳಕೆದಾರರು LDAP ಮೂಲಕ ಸಿಂಕ್ ಮಾಡಿದಾಗ, CMS ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ಪೇಸ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ, ಆದರೆ URI (coSpaceUriMapping) ನ ಬಳಕೆದಾರರ ಭಾಗ ಮಾತ್ರ, ಉದಾಹರಣೆಗೆ, user.space. ಭಾಗ ಡೊಮೇನ್ ಈ ನಿಯಮದ ಆಧಾರದ ಮೇಲೆ ಪೂರ್ಣ URI ಅನ್ನು ರಚಿಸಲಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ನೀವು ಈ ಹಂತದಲ್ಲಿ ವೆಬ್ ಸೇತುವೆಗೆ ಲಾಗ್ ಇನ್ ಆಗಿದ್ದರೆ, ಸ್ಪೇಸ್ URI ಡೊಮೇನ್ ಹೊಂದಿಲ್ಲ ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ. ಈ ನಿಯಮವನ್ನು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯಾಗಿ ಹೊಂದಿಸುವ ಮೂಲಕ, ನೀವು ರಚಿಸಲಾದ ಸ್ಪೇಸ್‌ಗಳಿಗಾಗಿ ಡೊಮೇನ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತಿರುವಿರಿ confexample.com.

ಹೊರಹೋಗುವ ಕರೆ ನಿಯಮಗಳು

ಏಕೀಕೃತ CM ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೊರಹೋಗುವ ಕರೆಗಳನ್ನು ಮಾಡಲು ಬಳಕೆದಾರರನ್ನು ಅನುಮತಿಸಲು, ನೀವು ಹೊರಹೋಗುವ ನಿಯಮಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು. ಜಬ್ಬರ್‌ನಂತಹ ಏಕೀಕೃತ CM ನೊಂದಿಗೆ ನೋಂದಾಯಿಸಲಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳ ಡೊಮೇನ್ example.com ಆಗಿದೆ. ಈ ಡೊಮೇನ್‌ಗೆ ಕರೆಗಳನ್ನು ಪ್ರಮಾಣಿತ SIP ಕರೆಗಳಂತೆ ಏಕೀಕೃತ CM ಕರೆ ಪ್ರಕ್ರಿಯೆ ನೋಡ್‌ಗಳಿಗೆ ರೂಟ್ ಮಾಡಬೇಕು. ಮುಖ್ಯ ಸರ್ವರ್ cucm-01.example.com, ಮತ್ತು ಹೆಚ್ಚುವರಿ ಸರ್ವರ್ cucm-02.example.com ಆಗಿದೆ.

ಮೊದಲ ನಿಯಮವು ಕ್ಲಸ್ಟರ್ ಸರ್ವರ್‌ಗಳ ನಡುವಿನ ಕರೆಗಳ ಸರಳ ರೂಟಿಂಗ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಕ್ಷೇತ್ರ ಡೊಮೇನ್‌ನಿಂದ ಸ್ಥಳೀಯ "@" ಚಿಹ್ನೆಯ ನಂತರ ಕರೆ ಮಾಡುವ ವ್ಯಕ್ತಿಗೆ ಕರೆ ಮಾಡುವವರ SIP-URI ನಲ್ಲಿ ಏನನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ. ನಾವು ಅದನ್ನು ಖಾಲಿ ಬಿಟ್ಟರೆ, ನಂತರ "@" ಚಿಹ್ನೆಯ ನಂತರ ಈ ಕರೆ ಹಾದುಹೋಗುವ CUCM ನ IP ವಿಳಾಸ ಇರುತ್ತದೆ. ನಾವು ಡೊಮೇನ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ, ನಂತರ "@" ಚಿಹ್ನೆಯ ನಂತರ ವಾಸ್ತವವಾಗಿ ಡೊಮೇನ್ ಇರುತ್ತದೆ. ಮರಳಿ ಕರೆ ಮಾಡಲು ಇದು ಅವಶ್ಯಕವಾಗಿದೆ, ಇಲ್ಲದಿದ್ದರೆ SIP-URI name@ip-address ಮೂಲಕ ಮರಳಿ ಕರೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಸೂಚಿಸಿದಾಗ ಕರೆ ಮಾಡಿ ಡೊಮೇನ್‌ನಿಂದ ಸ್ಥಳೀಯ

ಯಾವಾಗ ಕರೆ ಮಾಡಿ ಅಲ್ಲ ಸೂಚಿಸಲಾಗಿದೆ ಡೊಮೇನ್‌ನಿಂದ ಸ್ಥಳೀಯ

ಹೊರಹೋಗುವ ಕರೆಗಳಿಗಾಗಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾದ ಅಥವಾ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡದಿರುವುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲು ಮರೆಯದಿರಿ, ಏಕೆಂದರೆ ಸ್ವಯಂ ಪ್ಯಾರಾಮೀಟರ್‌ನೊಂದಿಗೆ ಏನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

ರೆಕಾರ್ಡಿಂಗ್

ವೀಡಿಯೊ ಕಾನ್ಫರೆನ್ಸ್‌ಗಳನ್ನು ರೆಕಾರ್ಡ್ ಸರ್ವರ್‌ನಿಂದ ರೆಕಾರ್ಡ್ ಮಾಡಲಾಗುತ್ತದೆ. ರೆಕಾರ್ಡರ್ ನಿಖರವಾಗಿ ಸಿಸ್ಕೋ ಮೀಟಿಂಗ್ ಸರ್ವರ್‌ನಂತೆಯೇ ಇರುತ್ತದೆ. ರೆಕಾರ್ಡರ್‌ಗೆ ಯಾವುದೇ ಪರವಾನಗಿಗಳ ಸ್ಥಾಪನೆ ಅಗತ್ಯವಿಲ್ಲ. ಕಾಲ್‌ಬ್ರಿಡ್ಜ್ ಸೇವೆಗಳನ್ನು ಚಾಲನೆಯಲ್ಲಿರುವ ಸರ್ವರ್‌ಗಳಿಗೆ ರೆಕಾರ್ಡಿಂಗ್ ಪರವಾನಗಿಗಳ ಅಗತ್ಯವಿದೆ, ಅಂದರೆ. ರೆಕಾರ್ಡಿಂಗ್ ಪರವಾನಗಿ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಕಾಲ್‌ಬ್ರಿಡ್ಜ್ ಘಟಕಕ್ಕೆ ಅನ್ವಯಿಸಬೇಕು ಮತ್ತು ರೆಕಾರ್ಡರ್ ಚಾಲನೆಯಲ್ಲಿರುವ ಸರ್ವರ್‌ಗೆ ಅಲ್ಲ. ರೆಕಾರ್ಡರ್ ಎಕ್ಸ್‌ಟೆನ್ಸಿಬಲ್ ಮೆಸೇಜಿಂಗ್ ಮತ್ತು ಪ್ರೆಸೆನ್ಸ್ ಪ್ರೋಟೋಕಾಲ್ (XMPP) ಕ್ಲೈಂಟ್‌ನಂತೆ ವರ್ತಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ CallBridge ಹೋಸ್ಟಿಂಗ್ ಸರ್ವರ್‌ನಲ್ಲಿ XMPP ಸರ್ವರ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು.

ಏಕೆಂದರೆ ನಾವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಮೂರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಪರವಾನಗಿಯನ್ನು "ವಿಸ್ತರಿಸುವ" ಅಗತ್ಯವಿದೆ. ನಂತರ ಪರವಾನಗಿಗಳಲ್ಲಿನ ನಿಮ್ಮ ವೈಯಕ್ತಿಕ ಖಾತೆಯಲ್ಲಿ ನಾವು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾದ ಎಲ್ಲಾ CMS ಸರ್ವರ್‌ಗಳ ಎ-ಇಂಟರ್‌ಫೇಸ್‌ಗಳ MAC ವಿಳಾಸಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತೇವೆ (ಸೇರಿಸುತ್ತೇವೆ).

ಮತ್ತು ಇದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಸರ್ವರ್‌ನಲ್ಲಿ ಇರಬೇಕಾದ ಚಿತ್ರವಾಗಿದೆ

ಸಾಮಾನ್ಯವಾಗಿ, ರೆಕಾರ್ಡರ್ ಅನ್ನು ಇರಿಸಲು ಹಲವಾರು ಸನ್ನಿವೇಶಗಳಿವೆ, ಆದರೆ ನಾವು ಇದಕ್ಕೆ ಅಂಟಿಕೊಳ್ಳುತ್ತೇವೆ:

ರೆಕಾರ್ಡರ್ ಅನ್ನು ಹೊಂದಿಸುವ ಮೊದಲು, ವೀಡಿಯೊ ಕಾನ್ಫರೆನ್ಸ್ ಅನ್ನು ವಾಸ್ತವವಾಗಿ ರೆಕಾರ್ಡ್ ಮಾಡುವ ಸ್ಥಳವನ್ನು ನೀವು ಸಿದ್ಧಪಡಿಸಬೇಕು. ವಾಸ್ತವವಾಗಿ ಇಲ್ಲಿ ಲಿಂಕ್, ಎಲ್ಲಾ ರೆಕಾರ್ಡಿಂಗ್ ಅನ್ನು ಹೇಗೆ ಹೊಂದಿಸುವುದು. ನಾನು ಪ್ರಮುಖ ಅಂಶಗಳು ಮತ್ತು ವಿವರಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇನೆ:

1. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಮೊದಲ ಸರ್ವರ್‌ನಿಂದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸ್ಲಿಪ್ ಮಾಡುವುದು ಉತ್ತಮ.
2. "ರೆಕಾರ್ಡರ್ ಲಭ್ಯವಿಲ್ಲ" ದೋಷ ಸಂಭವಿಸಬಹುದು ಏಕೆಂದರೆ ರೆಕಾರ್ಡರ್ ಟ್ರಸ್ಟ್‌ನಲ್ಲಿ ತಪ್ಪು ಪ್ರಮಾಣಪತ್ರವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ.
3. ರೆಕಾರ್ಡಿಂಗ್‌ಗಾಗಿ ಸೂಚಿಸಲಾದ NFS ಡೈರೆಕ್ಟರಿಯು ರೂಟ್ ಡೈರೆಕ್ಟರಿಯಾಗಿಲ್ಲದಿದ್ದರೆ ಬರವಣಿಗೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸದೇ ಇರಬಹುದು.

ಕೆಲವೊಮ್ಮೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರ ಅಥವಾ ಜಾಗದ ಕಾನ್ಫರೆನ್ಸ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರೆಕಾರ್ಡ್ ಮಾಡುವ ಅವಶ್ಯಕತೆಯಿದೆ.

ಇದಕ್ಕಾಗಿ, ಎರಡು ಕಾಲ್ಪ್ರೊಫೈಲ್ಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ:
ರೆಕಾರ್ಡಿಂಗ್ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ

ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ರೆಕಾರ್ಡಿಂಗ್ ಕಾರ್ಯದೊಂದಿಗೆ

ಮುಂದೆ, ನಾವು ಬಯಸಿದ ಜಾಗಕ್ಕೆ ಸ್ವಯಂಚಾಲಿತ ರೆಕಾರ್ಡಿಂಗ್ ಕಾರ್ಯದೊಂದಿಗೆ ಕಾಲ್ಪ್ರೊಫೈಲ್ ಅನ್ನು "ಲಗತ್ತಿಸುತ್ತೇವೆ".

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

ಮುಂದಿನ ಬಾರಿ ಸಂಸ್ಥೆಯ ಆಂತರಿಕ ನೆಟ್‌ವರ್ಕ್‌ನ ಹೊರಗೆ CMS ಅನ್ನು ಹೇಗೆ ಪ್ರವೇಶಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ.

ಮೂಲಗಳು:

www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-ಮತ್ತು-ನಂತರ. ಪಿಡಿಎಫ್

ಮೂಲ: www.habr.com