சிஸ்கோ மீட்டிங் சர்வர் 2.5.2. வீடியோ கான்ஃபரன்ஸ் ரெக்கார்டிங் செயல்பாட்டுடன், அளவிடக்கூடிய மற்றும் நெகிழ்வான முறையில் கிளஸ்டர்

இந்த இதழில் CMS சர்வரை ஃபெயில்ஓவர் கிளஸ்டர் பயன்முறையில் அமைப்பதில் உள்ள சில நுணுக்கங்களை விளக்குகிறேன்.


கோட்பாடுபொதுவாக, CMS சர்வர் வரிசைப்படுத்தலில் மூன்று வகைகள் உள்ளன:

• ஒற்றை ஒருங்கிணைந்த(ஒற்றை கூட்டு), அதாவது. தேவையான அனைத்து சேவைகளும் இயங்கும் ஒரு சேவையகம் இது. பெரும்பாலான சந்தர்ப்பங்களில், இந்த வகை வரிசைப்படுத்தல் உள் கிளையன்ட் அணுகலுக்கும், சிறிய சூழல்களில் ஒரு சேவையகத்தின் அளவிடுதல் மற்றும் பணிநீக்க வரம்புகள் ஒரு முக்கியமான பிரச்சினையாக இல்லாதபோதும் அல்லது CMS தற்காலிகம் போன்ற சில செயல்பாடுகளை மட்டுமே செய்யும் சூழ்நிலைகளிலும் மட்டுமே பொருத்தமானது. சிஸ்கோ UCM பற்றிய மாநாடுகள்.

  வேலையின் தோராயமான திட்டம்:
  

• ஒற்றை பிளவு(Single Split) வெளிப்புற அணுகலுக்காக ஒரு தனி சேவையகத்தைச் சேர்ப்பதன் மூலம் முந்தைய வரிசைப்படுத்தல் வகையை நீட்டிக்கிறது. பாரம்பரிய வரிசைப்படுத்தல்களில், இது ஒரு CMS சேவையகத்தை ஒரு இராணுவமயமாக்கப்பட்ட பிணையப் பிரிவில் (DMZ) பயன்படுத்துவதைக் குறிக்கிறது, அங்கு வெளிப்புற கிளையன்ட்கள் அதை அணுக முடியும், மேலும் உள் கிளையண்டுகள் CMS ஐ அணுகக்கூடிய பிணைய மையத்தில் ஒரு CMS சேவையகம். இந்த குறிப்பிட்ட வரிசைப்படுத்தல் மாதிரி இப்போது வகை என்று அழைக்கப்படுவதன் மூலம் மாற்றப்படுகிறது ஒற்றை விளிம்பு, இது சேவையகங்களைக் கொண்டுள்ளது சிஸ்கோ எக்ஸ்பிரஸ்வே, அதே ஃபயர்வால் பைபாஸ் திறன்களைக் கொண்டிருக்கும் அல்லது கொண்டிருக்கும், எனவே வாடிக்கையாளர்கள் ஒரு பிரத்யேக எட்ஜ் CMS சர்வரைச் சேர்க்கத் தேவையில்லை.

  வேலையின் தோராயமான திட்டம்:
  

• அளவிடக்கூடிய மற்றும் மீள்தன்மை கொண்டது(அளவிடக்கூடிய மற்றும் தவறுகளை பொறுத்துக்கொள்ளக்கூடியது) இந்த வகை ஒவ்வொரு கூறுக்கும் பணிநீக்கத்தை உள்ளடக்கியது, தோல்வியுற்றால் பணிநீக்கத்தை வழங்கும் அதே வேளையில் கணினி அதன் அதிகபட்ச திறனுடன் உங்கள் தேவைகளுடன் வளர அனுமதிக்கிறது. பாதுகாப்பான வெளிப்புற அணுகலை வழங்க இது ஒற்றை விளிம்பு கருத்தையும் பயன்படுத்துகிறது. இந்த எபிசோடில் நாம் பார்க்கப்போகும் வகை இது. இந்த வகை கிளஸ்டரை எவ்வாறு வரிசைப்படுத்துவது என்பதை நாங்கள் புரிந்து கொண்டால், மற்ற வகை வரிசைப்படுத்தல்களைப் புரிந்துகொள்வது மட்டுமல்லாமல், தேவையின் சாத்தியமான வளர்ச்சிக்கு இடமளிக்கும் வகையில் CMS சேவையகங்களின் கிளஸ்டர்களை எவ்வாறு உருவாக்குவது என்பதையும் புரிந்து கொள்ள முடியும்.

வரிசைப்படுத்தலுக்குச் செல்வதற்கு முன், நீங்கள் சில அடிப்படை விஷயங்களைப் புரிந்து கொள்ள வேண்டும், அதாவது

முக்கிய CMS மென்பொருள் கூறுகள்:

• தகவல்: டயல் திட்டம், பயனர் இடைவெளிகள் மற்றும் பயனர்கள் போன்ற சில உள்ளமைவுகளை இணைக்க உங்களை அனுமதிக்கிறது. அதிக கிடைக்கும் (சிங்கிள் மாஸ்டர்) க்ளஸ்டரிங்கை மட்டுமே ஆதரிக்கிறது.
• பாலத்தை அழைக்கவும்: அழைப்புகள் மற்றும் மல்டிமீடியா செயல்முறைகளின் மேலாண்மை மற்றும் செயலாக்கத்தின் மீது முழுக் கட்டுப்பாட்டை வழங்கும் ஆடியோ மற்றும் வீடியோ கான்பரன்சிங்கிற்கான சேவை. அதிக கிடைக்கும் தன்மை மற்றும் அளவிடுதல் ஆகியவற்றிற்கு கிளஸ்டரிங்கை ஆதரிக்கிறது.
• XMPP சர்வர்: Cisco Meeting Application மற்றும்/அல்லது WebRTC(WebRTC) மூலம் வாடிக்கையாளர்களின் பதிவு மற்றும் அங்கீகாரத்திற்கான பொறுப்புநிகழ்நேர தொடர்பு, அல்லது வெறுமனே உலாவியில்), அத்துடன் இடைக்கணிப்பு சமிக்ஞை. அதிக கிடைக்கும் தன்மைக்காக மட்டுமே கிளஸ்டர் செய்ய முடியும்.
• வலைப் பாலம்: WebRTC க்கு கிளையன்ட் அணுகலை வழங்குகிறது.
• லோட் பேலன்சர்: சிஸ்கோ மீட்டிங் ஆப்ஸிற்கான ஒற்றை இணைப்புப் புள்ளியை ஒற்றைப் பிரிப்பு பயன்முறையில் வழங்குகிறது. உள்வரும் இணைப்புகளுக்கான வெளிப்புற இடைமுகம் மற்றும் போர்ட்டைக் கேட்கிறது. சமமாக, லோட் பேலன்சர் XMPP சேவையகத்திலிருந்து உள்வரும் TLS இணைப்புகளை ஏற்றுக்கொள்கிறது, இதன் மூலம் வெளி கிளையண்டுகளிலிருந்து TCP இணைப்புகளை மாற்ற முடியும்.
  எங்கள் சூழ்நிலையில் அது தேவைப்படாது.
• டர்ன் சர்வர்: அனுமதிக்கும் ஃபயர்வால் பைபாஸ் தொழில்நுட்பத்தை வழங்குகிறது
  Cisco Meeting App அல்லது SIP சாதனங்களைப் பயன்படுத்தி வெளிப்புற வாடிக்கையாளர்களை இணைக்க ஃபயர்வால் அல்லது NATக்குப் பின்னால் எங்கள் CMS ஐ வைக்கவும். எங்கள் சூழ்நிலையில் அது தேவைப்படாது.
• இணைய நிர்வாகி: சிறப்பு ஒருங்கிணைந்த CM மாநாடுகள் உட்பட நிர்வாக இடைமுகம் மற்றும் API அணுகல்.

கட்டமைப்பு முறைகள்

மற்ற சிஸ்கோ தயாரிப்புகளைப் போலல்லாமல், சிஸ்கோ மீட்டிங் சர்வர் எந்த வகையான வரிசைப்படுத்துதலுக்கும் இடமளிக்கும் மூன்று உள்ளமைவு முறைகளை ஆதரிக்கிறது.

• கட்டளை வரி (CLI): ஆரம்ப கட்டமைப்பு மற்றும் சான்றிதழ் பணிகளுக்கு MMP எனப்படும் கட்டளை வரி இடைமுகம்.
• இணைய நிர்வாகி: முதன்மையாக CallBridge தொடர்பான உள்ளமைவுகளுக்கு, குறிப்பாக ஒரு கிளஸ்டர் அல்லாத சேவையகத்தை அமைக்கும் போது.
• REST API: மிகவும் சிக்கலான உள்ளமைவு பணிகள் மற்றும் கொத்தாக தரவுத்தளத்துடன் தொடர்புடைய பணிகளுக்குப் பயன்படுத்தப்படுகிறது.

மேலே உள்ளவற்றைத் தவிர, நெறிமுறையும் பயன்படுத்தப்படுகிறது வெளியிடுகிறீர்கள் பொதுவாக உரிமங்கள், சான்றிதழ்கள் அல்லது பதிவுகள் போன்ற கோப்புகளை CMS சேவையகத்திற்கு மாற்றவும்.

சிஸ்கோவின் வரிசைப்படுத்தல் வழிகாட்டிகளில் வெள்ளை மற்றும் ஆங்கிலத்தில் கிளஸ்டர் பயன்படுத்தப்பட வேண்டும் என்று எழுதப்பட்டுள்ளது. குறைந்தது மூன்று தரவுத்தளங்களின் சூழலில் சேவையகங்கள் (முனைகள்). ஏனெனில் ஒற்றைப்படை எண்ணிக்கையிலான முனைகளுடன் மட்டுமே புதிய தரவுத்தள மாஸ்டரைத் தேர்ந்தெடுப்பதற்கான வழிமுறை வேலை செய்யும், பொதுவாக தரவுத்தள மாஸ்டர் பெரும்பாலான CMS சேவையக தரவுத்தளத்துடன் தொடர்பைக் கொண்டுள்ளது.

நடைமுறையில் காண்பிக்கிறபடி, இரண்டு சேவையகங்கள் (முனைகள்) உண்மையில் போதுமானதாக இல்லை. மாஸ்டரை மறுதொடக்கம் செய்யும் போது தேர்வு நுட்பம் செயல்படுகிறது, மறுதொடக்கம் செய்யப்பட்ட சேவையகம் கொண்டு வரப்பட்ட பின்னரே ஸ்லேவ் சேவையகம் மாஸ்டர் ஆகிறது. இருப்பினும், இரண்டு சேவையகங்களின் கிளஸ்டரில் மாஸ்டர் சர்வர் திடீரென வெளியேறினால், ஸ்லேவ் சர்வர் மாஸ்டராக மாறாது, ஸ்லேவ் வெளியேறினால், மீதமுள்ள முதன்மை சேவையகம் ஸ்லேவ் ஆகிவிடும்.

ஆனால் XMPP இன் சூழலில், மூன்று சேவையகங்களின் தொகுப்பை ஒன்று சேர்ப்பது உண்மையில் அவசியமாக இருக்கும், ஏனெனில் எடுத்துக்காட்டாக, XMMP லீடர் நிலையில் உள்ள சேவையகங்களில் ஒன்றில் XMPP சேவையை முடக்கினால், மீதமுள்ள சர்வரில் XMPP பின்தொடர்பவர் நிலையில் இருக்கும் மற்றும் XMPPக்கான கால்பிரிட்ஜ் இணைப்புகள் செயலிழந்துவிடும், ஏனெனில் கால்பிரிட்ஜ் லீடர் அந்தஸ்துடன் XMPP உடன் பிரத்தியேகமாக இணைகிறது. மேலும் இது முக்கியமானது, ஏனென்றால்... ஒரு அழைப்பு கூட செல்லாது.

அதே வரிசைப்படுத்தல் வழிகாட்டிகளில் ஒரு XMPP சேவையகத்துடன் ஒரு கிளஸ்டர் காட்டப்படுகிறது.

மேலே உள்ளவற்றை கணக்கில் எடுத்துக்கொண்டால், ஏன் என்பது தெளிவாகிறது: இது தோல்வி பயன்முறையில் இருப்பதால் இது செயல்படுகிறது.

எங்கள் விஷயத்தில், XMPP சர்வர் மூன்று முனைகளிலும் இருக்கும்.

எங்கள் மூன்று சேவையகங்களும் செயலிழந்துவிட்டதாகக் கருதப்படுகிறது.

DNS பதிவுகள்

நீங்கள் சேவையகங்களை அமைக்கத் தொடங்குவதற்கு முன், நீங்கள் DNS பதிவுகளை உருவாக்க வேண்டும் А и எஸ்.ஆர்.வி. வகைகள்:

எங்கள் DNS பதிவுகளில் example.com மற்றும் இரண்டு டொமைன்கள் உள்ளன என்பதை நினைவில் கொள்ளவும் மொழியாக்கம் conf.example.com. Example.com என்பது அனைத்து சிஸ்கோ யுனிஃபைட் கம்யூனிகேஷன் மேனேஜர் சந்தாதாரர்களும் தங்கள் URIகளுக்காகப் பயன்படுத்தக்கூடிய ஒரு டொமைன் ஆகும், இது உங்கள் உள்கட்டமைப்பில் பெரும்பாலும் இருக்கும் அல்லது இருக்க வாய்ப்புள்ளது. அல்லது பயனர்கள் தங்கள் மின்னஞ்சல் முகவரிகளுக்கு பயன்படுத்தும் அதே டொமைனுடன் example.com பொருந்தும். அல்லது உங்கள் லேப்டாப்பில் உள்ள ஜாபர் கிளையண்டிடம் URI இருக்கலாம் [மின்னஞ்சல் பாதுகாக்கப்பட்டது]. களம் மொழியாக்கம் conf.example.com என்பது சிஸ்கோ மீட்டிங் சர்வர் பயனர்களுக்காக கட்டமைக்கப்படும் டொமைன் ஆகும். சிஸ்கோ மீட்டிங் சர்வரின் டொமைன் இருக்கும் மொழியாக்கம் conf.example.com, எனவே அதே ஜாபர் பயனருக்கு, சிஸ்கோ மீட்டிங் சர்வரில் உள்நுழைய பயனர்@ URI ஐப் பயன்படுத்த வேண்டும்.மொழியாக்கம் conf.example.com.

அடிப்படை கட்டமைப்பு

கீழே விவரிக்கப்பட்டுள்ள அனைத்து அமைப்புகளும் ஒரு சேவையகத்தில் காட்டப்பட்டுள்ளன, ஆனால் அவை கிளஸ்டரில் உள்ள ஒவ்வொரு சேவையகத்திலும் செய்யப்பட வேண்டும்.

QoS ஐ

CMS உருவாக்குவதால் நிகழ் நேர தாமதங்கள் மற்றும் பாக்கெட் இழப்புக்கு உணர்திறன் கொண்ட போக்குவரத்து, பெரும்பாலான சந்தர்ப்பங்களில் சேவையின் தரத்தை (QoS) உள்ளமைக்க பரிந்துரைக்கப்படுகிறது. இதை அடைய, CMS ஆனது அது உருவாக்கும் வேறுபட்ட சேவைக் குறியீடுகளுடன் (DSCPs) குறியிடல் பாக்கெட்டுகளை ஆதரிக்கிறது. DSCP அடிப்படையிலான போக்குவரத்து முன்னுரிமையானது, உங்கள் உள்கட்டமைப்பின் நெட்வொர்க் கூறுகளால் ட்ராஃபிக் எவ்வாறு செயலாக்கப்படுகிறது என்பதைப் பொறுத்தது என்றாலும், எங்கள் விஷயத்தில் நாங்கள் எங்கள் CMS ஐ QoS சிறந்த நடைமுறைகளின் அடிப்படையில் வழக்கமான DSCP முன்னுரிமையுடன் கட்டமைப்போம்.

ஒவ்வொரு சேவையகத்திலும் இந்த கட்டளைகளை உள்ளிடுவோம்

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 server add <server>

எங்கள் விஷயத்தில், இதுபோன்ற இரண்டு சேவையகங்கள் உள்ளன, எனவே இரண்டு அணிகள் இருக்கும்.
பார்க்கலாம்:

எங்கள் சேவையகத்திற்கான நேர மண்டலத்தை அமைக்கவும்

டிஎன்எஸ்

இது போன்ற கட்டளையுடன் DNS சேவையகங்களை CMS இல் சேர்க்கிறோம்:

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

எங்கள் விஷயத்தில், இதுபோன்ற இரண்டு சேவையகங்கள் உள்ளன, எனவே இரண்டு அணிகள் இருக்கும்.
பார்க்கலாம்:

பிணைய இடைமுக கட்டமைப்பு

இது போன்ற கட்டளையுடன் இடைமுகத்தை உள்ளமைக்கிறோம்:

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

பார்க்கலாம்:

சர்வர் பெயர் (ஹோஸ்ட் பெயர்)

சேவையக பெயரை ஒரு கட்டளையுடன் அமைக்கிறோம்:

hostname <name>

நாங்கள் மறுதொடக்கம் செய்கிறோம்.


இது அடிப்படை கட்டமைப்பை நிறைவு செய்கிறது.

சான்றிதழ்கள்

கோட்பாடுCisco Meeting Serverக்கு பல்வேறு கூறுகளுக்கு இடையே மறைகுறியாக்கப்பட்ட தொடர்பு தேவைப்படுகிறது, இதன் விளைவாக, அனைத்து CMS வரிசைப்படுத்தல்களுக்கும் X.509 சான்றிதழ்கள் தேவை. சேவைகள்/சேவையகம் மற்ற சேவையகங்கள்/சேவைகளால் நம்பப்படுவதை உறுதிசெய்ய அவை உதவுகின்றன.

ஒவ்வொரு சேவைக்கும் ஒரு சான்றிதழ் தேவை, ஆனால் ஒவ்வொரு சேவைக்கும் தனித்தனி சான்றிதழ்களை உருவாக்குவது குழப்பம் மற்றும் தேவையற்ற சிக்கலுக்கு வழிவகுக்கும். அதிர்ஷ்டவசமாக, நாங்கள் ஒரு சான்றிதழின் பொது-தனியார் விசை ஜோடியை உருவாக்கி, பல சேவைகளில் அவற்றை மீண்டும் பயன்படுத்தலாம். எங்கள் விஷயத்தில், அதே சான்றிதழ் கால் பிரிட்ஜ், எக்ஸ்எம்பிபி சர்வர், வெப் பிரிட்ஜ் மற்றும் வெப் அட்மினுக்கும் பயன்படுத்தப்படும். எனவே, கிளஸ்டரில் உள்ள ஒவ்வொரு சேவையகத்திற்கும் நீங்கள் ஒரு ஜோடி பொது மற்றும் தனிப்பட்ட சான்றிதழ் விசைகளை உருவாக்க வேண்டும்.

தரவுத்தள கிளஸ்டரிங், இருப்பினும், சில சிறப்பு சான்றிதழ் தேவைகள் உள்ளன, எனவே மற்ற சேவைகளில் இருந்து வேறுபட்ட அதன் சொந்த சான்றிதழ்கள் தேவை. CMS ஒரு சர்வர் சான்றிதழைப் பயன்படுத்துகிறது, இது பிற சர்வர்கள் பயன்படுத்தும் சான்றிதழ்களைப் போன்றது, ஆனால் தரவுத்தள இணைப்புகளுக்குப் பயன்படுத்தப்படும் கிளையன்ட் சான்றிதழும் உள்ளது. தரவுத்தள சான்றிதழ்கள் அங்கீகாரம் மற்றும் குறியாக்கம் ஆகிய இரண்டிற்கும் பயன்படுத்தப்படுகின்றன. கிளையன்ட் தரவுத்தளத்துடன் இணைக்க பயனர்பெயர் மற்றும் கடவுச்சொல்லை வழங்குவதற்குப் பதிலாக, சர்வரால் நம்பப்படும் கிளையன்ட் சான்றிதழை இது வழங்குகிறது. தரவுத்தள கிளஸ்டரில் உள்ள ஒவ்வொரு சேவையகமும் ஒரே பொது மற்றும் தனிப்பட்ட விசை ஜோடியைப் பயன்படுத்தும். ஒரே விசை ஜோடியைப் பகிர்ந்து கொள்ளும் பிற சேவையகங்களால் மட்டுமே டிக்ரிப்ட் செய்யக்கூடிய வகையில், க்ளஸ்டரில் உள்ள அனைத்து சர்வர்களும் தரவை குறியாக்கம் செய்ய இது அனுமதிக்கிறது.

பணிநீக்கம் செய்ய, தரவுத்தள கிளஸ்டர்கள் குறைந்தபட்சம் 3 சேவையகங்களைக் கொண்டிருக்க வேண்டும், ஆனால் 5 க்கு மேல் இருக்கக்கூடாது, எந்த கிளஸ்டர் உறுப்பினர்களுக்கும் இடையே அதிகபட்ச சுற்று-பயண நேரம் 200 எம்.எஸ். இந்த வரம்பு கால் பிரிட்ஜ் க்ளஸ்டரிங்கை விட மிகவும் கட்டுப்பாடானது, எனவே இது புவியியல் ரீதியாக விநியோகிக்கப்பட்ட வரிசைப்படுத்தல்களில் பெரும்பாலும் கட்டுப்படுத்தும் காரணியாகும்.

CMSக்கான தரவுத்தளப் பங்குக்கு பல தனிப்பட்ட தேவைகள் உள்ளன. மற்ற பாத்திரங்களைப் போலல்லாமல், இதற்கு கிளையன்ட் மற்றும் சர்வர் சான்றிதழ் தேவைப்படுகிறது, அங்கு கிளையன்ட் சான்றிதழில் ஒரு குறிப்பிட்ட CN புலம் உள்ளது, அது சேவையகத்திற்கு வழங்கப்படுகிறது.

CMS ஆனது ஒரு மாஸ்டர் மற்றும் முற்றிலும் ஒரே மாதிரியான பல பிரதிகள் கொண்ட போஸ்ட்கிரெஸ் தரவுத்தளத்தைப் பயன்படுத்துகிறது. ஒரு நேரத்தில் ஒரே ஒரு முதன்மை தரவுத்தளம் மட்டுமே உள்ளது ("டேட்டாபேஸ் சர்வர்"). கிளஸ்டரின் மீதமுள்ள உறுப்பினர்கள் பிரதிகள் அல்லது "தரவுத்தள கிளையன்ட்கள்".

ஒரு தரவுத்தள கிளஸ்டருக்கு ஒரு பிரத்யேக சர்வர் சான்றிதழ் மற்றும் கிளையன்ட் சான்றிதழ் தேவை. அவர்கள் சான்றிதழ்களால் கையொப்பமிடப்பட வேண்டும், பொதுவாக ஒரு உள் தனியார் சான்றிதழ் அதிகாரம். தரவுத்தள கிளஸ்டரின் எந்தவொரு உறுப்பினரும் முதன்மையாக முடியும் என்பதால், தரவுத்தள சேவையகம் மற்றும் கிளையன்ட் சான்றிதழ் ஜோடிகள் (பொது மற்றும் தனிப்பட்ட விசைகளைக் கொண்டவை) அனைத்து சேவையகங்களுக்கும் நகலெடுக்கப்பட வேண்டும், இதனால் அவர்கள் கிளையன்ட் அல்லது தரவுத்தள சேவையகத்தின் அடையாளத்தை எடுத்துக் கொள்ளலாம். கூடுதலாக, கிளையன்ட் மற்றும் சர்வர் சான்றிதழ்கள் சரிபார்க்கப்படுவதை உறுதிசெய்ய CA ரூட் சான்றிதழ் ஏற்றப்பட வேண்டும்.

எனவே, தரவுத்தளத்தைத் தவிர அனைத்து சேவையக சேவைகளாலும் பயன்படுத்தப்படும் சான்றிதழுக்கான கோரிக்கையை நாங்கள் உருவாக்குகிறோம் (இதற்கு ஒரு தனி கோரிக்கை இருக்கும்) போன்ற கட்டளையுடன்:

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

CN இல் எங்கள் சேவையகங்களின் பொதுவான பெயரை எழுதுகிறோம். எடுத்துக்காட்டாக, எங்கள் சேவையகங்களின் ஹோஸ்ட்பெயர்கள் என்றால் server01, server02, server03, பின்னர் 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) தொடர்புடைய சேவையகங்களின் பெயர்கள்.

இந்த நடைமுறையை நாங்கள் ஒரு சேவையகத்தில் (!) மட்டுமே செய்கிறோம், மேலும் சான்றிதழ்கள் மற்றும் தொடர்புடைய .key கோப்புகளை மற்ற சேவையகங்களில் பதிவேற்றுவோம்.

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. தரவுத்தளத்திற்கான சான்றிதழ்கள் ("சர்வர்" மற்றும் "கிளையன்ட்") மற்றும் "சர்வர்" மற்றும் "கிளையன்ட்" தரவுத்தள சான்றிதழ்களுக்கான கோரிக்கையை உருவாக்கும் போது உருவாக்கப்பட்ட .key நீட்டிப்பு கொண்ட கோப்புகள். இந்த கோப்புகள் எல்லா சர்வர்களிலும் ஒரே மாதிரியாக இருக்க வேண்டும்.
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 சேவையகத்தின் முதன்மை ஐபி முகவரி, அதில் கிளஸ்டர் துவக்கப்பட்டது, வெறுமனே மாஸ்டர்.

கட்டளையுடன் அனைத்து சேவையகங்களிலும் எங்கள் தரவுத்தள கிளஸ்டர் எவ்வாறு செயல்படுகிறது என்பதை நாங்கள் சரிபார்க்கிறோம்:

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 சேவைகளை பிணைக்கிறோம்:

callbridge listen a

கட்டளையுடன் சேவையை மறுதொடக்கம் செய்யுங்கள்:

callbridge restart

இப்போது எங்களின் கால் பிரிட்ஜ்கள் உள்ளமைக்கப்பட்டதால், கால் பிரிட்ஜ் கிளஸ்டரிங்கை உள்ளமைக்கலாம். கால் பிரிட்ஜ் கிளஸ்டரிங் என்பது டேட்டாபேஸ் அல்லது எக்ஸ்எம்பிபி கிளஸ்டரிங்கிலிருந்து வேறுபட்டது. Call Bridge Cluster ஆனது 2 முதல் 8 முனைகள் வரை எந்த கட்டுப்பாடும் இல்லாமல் ஆதரிக்க முடியும். இது பணிநீக்கத்தை மட்டுமல்ல, சுமை சமநிலையையும் வழங்குகிறது, இதனால் அறிவார்ந்த அழைப்பு விநியோகத்தைப் பயன்படுத்தி கால் பிரிட்ஜ் சேவையகங்களில் மாநாடுகளை தீவிரமாக விநியோகிக்க முடியும். CMS ஆனது கூடுதல் அம்சங்களைக் கொண்டுள்ளது, கால் பிரிட்ஜ் குழுக்கள் மற்றும் தொடர்புடைய அம்சங்களை மேலும் நிர்வாகத்திற்குப் பயன்படுத்தலாம்.

கால் பிரிட்ஜ் கிளஸ்டரிங் முதன்மையாக இணைய நிர்வாக இடைமுகம் மூலம் கட்டமைக்கப்படுகிறது
கீழே விவரிக்கப்பட்டுள்ள செயல்முறை கிளஸ்டரில் உள்ள ஒவ்வொரு சேவையகத்திலும் மேற்கொள்ளப்பட வேண்டும்.
எனவே

1. இணையம் வழியாக கட்டமைப்பு > கிளஸ்டருக்குச் செல்லவும்.
2. தி பாலம் அடையாளத்தை அழைக்கவும் ஒரு தனிப்பட்ட பெயராக, சேவையகப் பெயருடன் தொடர்புடைய callbridge[01,02,03] ஐ உள்ளிடவும். இந்தப் பெயர்கள் தன்னிச்சையானவை, ஆனால் இந்தக் கிளஸ்டருக்குத் தனிப்பட்டதாக இருக்க வேண்டும். அவை சர்வர் அடையாளங்காட்டிகள் [01,02,03] என்பதைக் குறிப்பிடுவதால் அவை இயற்கையில் விளக்கமானவை.
3.V கிளஸ்டர்டு கால் பாலங்கள் எங்கள் சேவையகங்களின் வலை நிர்வாகி URLகளை கிளஸ்டரில் உள்ளிடவும், செ.மீ.[01,02,03].example.com:445, முகவரி புலத்தில். துறைமுகத்தைக் குறிப்பிட மறக்காதீர்கள். நீங்கள் Peer இணைப்பு 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 மட்டும் இல்லை? எங்களின் குறிப்பிட்ட வரிசைப்படுத்தலில், ஜாபர் பயனர்கள் Unified CM இல் பயன்படுத்தக்கூடிய Unified CM டொமைனை example.com ஆகத் தேர்ந்தெடுத்துள்ளோம், எனவே CMS பயனர்களுக்கு SIP டொமைன்கள் மூலம் CMS க்கு அழைப்புகளை அனுப்புவதற்கு வேறு டொமைன் தேவைப்பட்டது.

போன்ற கட்டளையைப் பயன்படுத்தி 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 callbridge, இது கொடுக்கப்பட்ட DNS பதிவிற்கான முன்னுரிமை அமைப்புகளைப் பொறுத்தது.

அடுத்து, Call Bride சேவை XMPP சேவையுடன் வெற்றிகரமாக இணைக்கப்பட்டுள்ளதா என்பதைச் சரிபார்க்க, நிலை > பொது என்பதற்குச் செல்லவும்.

வலைப் பாலம்

கிளஸ்டரில் உள்ள ஒவ்வொரு சர்வரிலும், கட்டளையுடன் வலைப் பாலம் சேவையை இயக்கவும்:

webbridge listen a:443

Web Bridge சேவையை சான்றிதழ் கோப்புகளுடன் இது போன்ற கட்டளையுடன் கட்டமைக்கிறோம்:

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

Web Bridge HTTPSஐ ஆதரிக்கிறது. "http-redirect" ஐப் பயன்படுத்தும் வகையில் கட்டமைக்கப்பட்டிருந்தால், HTTP ஐ HTTPSக்கு திருப்பிவிடும்.
HTTP திசைதிருப்பலை இயக்க, பின்வரும் கட்டளையைப் பயன்படுத்தவும்:

webbridge http-redirect enable

Call Bridge இலிருந்து Web Bridge இணைப்புகளை நம்பலாம் என்பதை Call Bridgeக்கு தெரியப்படுத்த, கட்டளையைப் பயன்படுத்தவும்:

webbridge trust <certfile>

இது க்ளஸ்டரில் உள்ள ஒவ்வொரு சர்வரிலிருந்தும் மூன்று சான்றிதழ்களையும் கொண்ட கோப்பு.

இந்த படம் கிளஸ்டரில் உள்ள ஒவ்வொரு சர்வரிலும் இருக்க வேண்டும்.


இப்போது நாம் “அப்பாட்மின்” பாத்திரத்துடன் ஒரு பயனரை உருவாக்க வேண்டும், அது நமக்குத் தேவை, அதனால் நமது கிளஸ்டரை (!) உள்ளமைக்க முடியும், மேலும் கிளஸ்டரில் உள்ள ஒவ்வொரு சேவையகத்தையும் தனித்தனியாக அல்ல, இந்த வழியில் அமைப்புகள் ஒவ்வொரு சேவையகத்திற்கும் சமமாகப் பயன்படுத்தப்படும். அவை ஒரு முறை செய்யப்படும் என்பது உண்மை.


மேலும் அமைப்பிற்கு நாங்கள் பயன்படுத்துவோம் போஸ்ட்மேன்.

அங்கீகாரத்திற்கு, அங்கீகார பிரிவில் அடிப்படை என்பதைத் தேர்ந்தெடுக்கவும்

CMS சேவையகத்திற்கு கட்டளைகளை சரியாக அனுப்ப, நீங்கள் தேவையான குறியாக்கத்தை அமைக்க வேண்டும்

Webridge ஐ கட்டளையுடன் குறிப்பிடுகிறோம் போஸ்ட் அளவுருவுடன் URL மற்றும் பொருள் cms.example.com



வெப்ரிட்ஜில், தேவையான அளவுருக்களை நாங்கள் குறிப்பிடுகிறோம்: விருந்தினர் அணுகல், பாதுகாக்கப்பட்ட அணுகல் போன்றவை.

பிரிட்ஜ் குழுக்களை அழைக்கவும்

இயல்பாக, CMS எப்போதும் தனக்குக் கிடைக்கும் கான்ஃபரன்சிங் ஆதாரங்களை மிகச் சிறப்பாகப் பயன்படுத்துவதில்லை.

எடுத்துக்காட்டாக, மூன்று பங்கேற்பாளர்களுடனான சந்திப்புக்கு, ஒவ்வொரு பங்கேற்பாளரும் மூன்று வெவ்வேறு அழைப்புப் பிரிட்ஜ்களில் முடிவடையும். இந்த மூன்று பங்கேற்பாளர்களும் ஒருவரையொருவர் தொடர்புகொள்வதற்காக, Call Bridges தானாகவே அனைத்து சேவையகங்களுக்கும் கிளையண்டுகளுக்கும் இடையே ஒரே இடத்தில் இணைப்புகளை நிறுவும், இதனால் அனைத்து வாடிக்கையாளர்களும் ஒரே சர்வரில் இருப்பது போல் தெரிகிறது. துரதிர்ஷ்டவசமாக, இதன் தீங்கு என்னவென்றால், ஒரு 3 நபர் மாநாடு இப்போது 9 மீடியா போர்ட்களை உட்கொள்ளும். இது வெளிப்படையாக வளங்களின் திறமையற்ற பயன்பாடாகும். கூடுதலாக, அழைப்புப் பிரிட்ஜ் உண்மையிலேயே ஓவர்லோட் செய்யப்படும்போது, ​​அழைப்புகளை ஏற்றுக்கொள்வதைத் தொடர்ந்து அந்த அழைப்புப் பிரிட்ஜின் அனைத்து சந்தாதாரர்களுக்கும் தரம் குறைக்கப்பட்ட சேவையை வழங்குவது இயல்பு வழிமுறையாகும்.

கால் பிரிட்ஜ் குழு அம்சத்தைப் பயன்படுத்தி இந்தப் பிரச்சனைகள் தீர்க்கப்படுகின்றன. இந்த அம்சம் Cisco Meeting Server மென்பொருளின் பதிப்பு 2.1 இல் அறிமுகப்படுத்தப்பட்டது மற்றும் WebRTC பங்கேற்பாளர்கள் உட்பட உள்வரும் மற்றும் வெளிச்செல்லும் Cisco Meeting App (CMA) அழைப்புகளுக்கு சுமை சமநிலையை ஆதரிக்கும் வகையில் நீட்டிக்கப்பட்டுள்ளது.

மறு இணைப்புச் சிக்கலைத் தீர்க்க, ஒவ்வொரு அழைப்புப் பாலத்திற்கும் மூன்று கட்டமைக்கக்கூடிய சுமை வரம்புகள் அறிமுகப்படுத்தப்பட்டுள்ளன:

LoadLimit - இது ஒரு குறிப்பிட்ட கால் பிரிட்ஜிற்கான அதிகபட்ச எண் சுமையாகும். ஒவ்வொரு இயங்குதளமும் CMS96000 க்கு 1000 மற்றும் மெய்நிகர் இயந்திரத்திற்கு ஒரு vCPU க்கு 1.25 GHz போன்ற பரிந்துரைக்கப்பட்ட சுமை வரம்பைக் கொண்டுள்ளது. பங்கேற்பாளரின் தீர்மானம் மற்றும் பிரேம் வீதத்தைப் பொறுத்து வெவ்வேறு அழைப்புகள் ஒரு குறிப்பிட்ட அளவு ஆதாரங்களைப் பயன்படுத்துகின்றன.
NewConferenceLoadLimitBasisPoints (இயல்புநிலை 50% loadLimit) - சேவையக சுமை வரம்பை அமைக்கிறது, அதன் பிறகு புதிய மாநாடுகள் நிராகரிக்கப்படும்.
தற்போதுள்ள மாநாட்டு சுமை வரம்பு அடிப்படை புள்ளிகள் (இயல்புநிலை 80% loadLimit) - ஏற்கனவே உள்ள மாநாட்டில் சேரும் பங்கேற்பாளர்கள் நிராகரிக்கப்படும் சேவையக ஏற்ற மதிப்பு.

இந்த அம்சம் அழைப்பு விநியோகம் மற்றும் சுமை சமநிலைக்காக வடிவமைக்கப்பட்டிருந்தாலும், டர்ன் சர்வர்கள், வெப் பிரிட்ஜ் சர்வர்கள் மற்றும் ரெக்கார்டர்கள் போன்ற பிற குழுக்களும் கால் பிரிட்ஜ் குழுக்களுக்கு ஒதுக்கப்படலாம், இதனால் அவை உகந்த பயன்பாட்டிற்காக ஒழுங்காக குழுவாக இருக்கும். இந்த பொருள்களில் ஏதேனும் ஒரு அழைப்புக் குழுவிற்கு ஒதுக்கப்படவில்லை என்றால், அவை எந்த குறிப்பிட்ட முன்னுரிமையும் இல்லாமல் அனைத்து சேவையகங்களுக்கும் கிடைக்கும் என்று கருதப்படுகிறது.

இந்த அளவுருக்கள் இங்கே கட்டமைக்கப்பட்டுள்ளன: cms.example.com:445/api/v1/system/configuration/cluster

அடுத்து, ஒவ்வொரு கால்பிரிட்ஜ் எந்த கால்பிரிட்ஜ் குழுவிற்கு சொந்தமானது என்பதைக் குறிப்பிடுகிறோம்:

முதல் கால்பிரிட்ஜ்

இரண்டாவது கால்பிரிட்ஜ்

மூன்றாவது கால்பிரிட்ஜ்


எனவே, Cisco Meeting Server க்ளஸ்டரின் வளங்களை மிகவும் திறமையாகப் பயன்படுத்த, Call Brdige குழுவை உள்ளமைத்தோம்.

செயலில் உள்ள கோப்பகத்திலிருந்து பயனர்களை இறக்குமதி செய்கிறது

வலை நிர்வாகி சேவையானது எல்டிஏபி உள்ளமைவுப் பிரிவைக் கொண்டுள்ளது, ஆனால் அது சிக்கலான உள்ளமைவு விருப்பங்களை வழங்காது, மேலும் தகவல் கிளஸ்டர் தரவுத்தளத்தில் சேமிக்கப்படுவதில்லை, எனவே உள்ளமைவு ஒவ்வொரு சேவையகத்திலும் கைமுறையாக இணைய இடைமுகம் வழியாகவோ அல்லது அதன் மூலமாகவோ செய்யப்பட வேண்டும். API, மற்றும் "மூன்று முறை "எழுந்திராதே" என்று நாங்கள் API வழியாக தரவை அமைப்போம்.

அணுக URL ஐப் பயன்படுத்துதல் cms01.example.com:445/api/v1/ldapServers ஒரு LDAP சர்வர் பொருளை உருவாக்குகிறது, இது போன்ற அளவுருக்களைக் குறிப்பிடுகிறது:

• சர்வர் ஐபி
• போர்ட் எண்
• பயனர் பெயர்
• கடவுச்சொல்லை
• பாதுகாக்க

பாதுகாப்பானது - போர்ட்டைப் பொறுத்து சரி அல்லது தவறு என்பதைத் தேர்ந்தெடுக்கவும், 389 - பாதுகாப்பானது அல்ல, 636 - பாதுகாக்கப்பட்டது.


சிஸ்கோ மீட்டிங் சர்வரில் உள்ள பண்புக்கூறுகளுக்கு LDAP மூல அளவுருக்களை மேப்பிங் செய்தல்.
LDAP மேப்பிங் ஆனது LDAP கோப்பகத்தில் உள்ள பண்புகளை CMS இல் உள்ள பண்புகளுடன் வரைபடமாக்குகிறது. உண்மையான பண்புகள்:

• ஜிட்மேப்பிங்
• பெயர் வரைபடம்
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

பண்புகளின் விளக்கம்IADB 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 மூலப் பொருளை உருவாக்குகிறது, இது போன்ற அளவுருக்களைக் குறிப்பிடுகிறது:

• சர்வர்
• மேப்பிங்
• அடிப்படைDn
• வடிகட்டி

இப்போது LDAP கட்டமைப்பு முடிந்தது, நீங்கள் கைமுறையாக ஒத்திசைவு செயல்பாட்டைச் செய்யலாம்.

கிளிக் செய்வதன் மூலம் ஒவ்வொரு சேவையகத்தின் வலை இடைமுகத்திலும் இதைச் செய்கிறோம் இப்போது ஒத்திசைக்கவும் பிரிவில் செயலில் உள்ள அடைவு


அல்லது கட்டளையுடன் API வழியாக போஸ்ட் அணுக URL ஐப் பயன்படுத்தவும் cms01.example.com:445/api/v1/ldapSyncs

தற்காலிக மாநாடுகள்

இது என்ன?பாரம்பரிய கருத்தாக்கத்தில், இரண்டு பங்கேற்பாளர்கள் ஒருவருக்கொருவர் பேசுவதை மாநாடு ஆகும், மேலும் பங்கேற்பாளர்களில் ஒருவர் (ஒருங்கிணைந்த CM உடன் பதிவுசெய்யப்பட்ட சாதனத்தைப் பயன்படுத்தி) "மாநாட்டு" பொத்தானை அழுத்தி, மற்ற நபரை அழைத்து, அந்த மூன்றாம் தரப்பினருடன் பேசிய பிறகு. , முத்தரப்பு மாநாட்டில் பங்கேற்பாளர்கள் அனைவரையும் இணைக்க, "மாநாடு" பொத்தானை மீண்டும் அழுத்தவும்.

CMS இல் திட்டமிடப்பட்ட மாநாட்டிலிருந்து Ad-Hoc மாநாட்டை வேறுபடுத்துவது என்னவென்றால், Ad-Hoc மாநாடு என்பது CMSக்கான SIP அழைப்பு மட்டுமல்ல. அனைவரையும் ஒரே மீட்டிங்கிற்கு அழைக்க, கான்ஃபரன்ஸ் துவக்குபவர் இரண்டாவது முறையாக கான்ஃபரன்ஸ் பட்டனைக் கிளிக் செய்யும் போது, ​​அனைத்து அழைப்புகளும் மாற்றப்படும் விமானத்தில் மாநாட்டை உருவாக்க, ஒருங்கிணைந்த CM CMSக்கு API அழைப்பை மேற்கொள்ள வேண்டும். இவை அனைத்தும் பங்கேற்பாளர்களால் கவனிக்கப்படாமல் நடக்கும்.

அழைப்பைத் தொடர, யுனிஃபைட் CM ஆனது API நற்சான்றிதழ்கள் மற்றும் WebAdmin முகவரி/சேவையின் போர்ட் மற்றும் SIP ட்ரங்கை நேரடியாக CMS சேவையகத்திற்கு உள்ளமைக்க வேண்டும்.

தேவைப்பட்டால், CUCM ஆனது CMS இல் ஒரு இடத்தை மாறும் வகையில் உருவாக்க முடியும், இதனால் ஒவ்வொரு அழைப்பும் CMS ஐ அடையலாம் மற்றும் இடைவெளிகளுக்கான உள்வரும் அழைப்பு விதியுடன் பொருந்தும்.

CUCM உடன் ஒருங்கிணைப்பு கட்டுரையில் விவரிக்கப்பட்டுள்ள அதே வழியில் கட்டமைக்கப்பட்டுள்ளது முந்தைய Cisco UCM இல் நீங்கள் CMSக்கு மூன்று டிரங்குகளை உருவாக்க வேண்டும், மூன்று மாநாட்டுப் பாலங்கள், SIP பாதுகாப்பு சுயவிவரத்தில் மூன்று தலைப்புப் பெயர்கள், வழிக் குழுக்கள், வழிப் பட்டியல்கள், மீடியா ரிசோர்ஸ் குழுக்கள் மற்றும் மீடியா ரிசோர்ஸ் குழுப் பட்டியல்களைக் குறிப்பிடவும், மேலும் சில ரூட்டிங் விதிகளைச் சேர்க்கவும். சிஸ்கோ மீட்டிங் சர்வருக்கு.

SIP பாதுகாப்பு சுயவிவரம்:


டிரங்குகள்:


ஒவ்வொரு உடற்பகுதியும் ஒரே மாதிரியாக இருக்கும்:




மாநாட்டு பாலம்


ஒவ்வொரு மாநாட்டுப் பாலமும் ஒரே மாதிரியாகத் தெரிகிறது:


பாதை குழு


பாதை பட்டியல்


ஊடக வள குழு


ஊடக வள குழு பட்டியல்

அழைப்பு விதிகள்

யுனிஃபைட் CM அல்லது எக்ஸ்பிரஸ்வே போன்ற மேம்பட்ட அழைப்பு மேலாண்மை அமைப்புகளைப் போலன்றி, புதிய அழைப்புகளுக்கான SIP கோரிக்கை-URI புலத்தில் மட்டுமே CMS டொமைனைப் பார்க்கிறது. எனவே SIP INVITE 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 என்பதைப் பொறுத்து, CMS அதன் IP முகவரி அல்லது FQDNக்கு அனுப்பப்படும் அழைப்புகளை ஏற்க உள்ளமைக்கப்பட வேண்டுமா என்பதைத் தீர்மானிக்கும்.

அதிக முன்னுரிமை உள்வரும் விதியைக் கொண்ட டொமைன் எந்தப் பயனர் இடங்களுக்கும் டொமைனாகப் பயன்படுத்தப்படுகிறது. பயனர்கள் LDAP வழியாக ஒத்திசைக்கும்போது, ​​CMS தானாகவே இடைவெளிகளை உருவாக்கும், ஆனால் URI (coSpaceUriMapping) இன் பயனர் பகுதி மட்டுமே, எடுத்துக்காட்டாக, user.space. பகுதி டொமைன் இந்த விதியின் அடிப்படையில் முழு URI உருவாக்கப்படுகிறது. உண்மையில், நீங்கள் இந்த கட்டத்தில் Web Bridge இல் உள்நுழைந்தால், Space URI க்கு டொமைன் இல்லை என்பதை நீங்கள் காண்பீர்கள். இந்த விதியை அதிக முன்னுரிமையாக அமைப்பதன் மூலம், உருவாக்கப்படும் இடங்களுக்கான டொமைனை அமைக்கிறீர்கள் confஉதாரணம்.காம்.


வெளிச்செல்லும் அழைப்பு விதிகள்

யூனிஃபைட் CM கிளஸ்டருக்கு வெளிச்செல்லும் அழைப்புகளைச் செய்ய பயனர்களை அனுமதிக்க, நீங்கள் வெளிச்செல்லும் விதிகளை உள்ளமைக்க வேண்டும். ஜாபர் போன்ற ஒருங்கிணைந்த CM இல் பதிவுசெய்யப்பட்ட எண்ட்பாயிண்ட்களின் டொமைன் example.com ஆகும். இந்த டொமைனுக்கான அழைப்புகள் நிலையான SIP அழைப்புகளாக ஒருங்கிணைந்த CM அழைப்பு செயலாக்க முனைகளுக்கு அனுப்பப்பட வேண்டும். முக்கிய சர்வர் cucm-01.example.com மற்றும் கூடுதல் சர்வர் cucm-02.example.com.

முதல் விதி, கிளஸ்டர் சர்வர்களுக்கிடையேயான அழைப்புகளின் எளிமையான ரூட்டிங் பற்றி விவரிக்கிறது.

துறையில் டொமைனில் இருந்து உள்ளூர் "@" சின்னத்திற்குப் பிறகு அழைக்கப்படும் நபருக்கு அழைப்பாளரின் SIP-URI இல் காட்டப்படுவதற்கு பொறுப்பாகும். நாம் அதை காலியாக விட்டால், “@” சின்னத்திற்குப் பிறகு இந்த அழைப்பு கடந்து செல்லும் CUCM இன் ஐபி முகவரி இருக்கும். நாங்கள் ஒரு டொமைனைக் குறிப்பிட்டால், "@" சின்னத்திற்குப் பிறகு உண்மையில் ஒரு டொமைன் இருக்கும். மீண்டும் அழைக்க இது அவசியம், இல்லையெனில் SIP-URI name@ip-address மூலம் திரும்ப அழைக்க முடியாது.

குறிப்பிடும்போது அழைக்கவும் டொமைனில் இருந்து உள்ளூர்


எப்போது அழைக்கவும் НЕ சுட்டிக்காட்டப்பட்டது டொமைனில் இருந்து உள்ளூர்


வெளிச்செல்லும் அழைப்புகளுக்கு மறைகுறியாக்கப்பட்ட அல்லது மறைகுறியாக்கப்படாததை வெளிப்படையாகக் குறிப்பிடுவதை உறுதிப்படுத்திக் கொள்ளுங்கள், ஏனெனில் ஆட்டோ அளவுருவுடன் எதுவும் செயல்படாது.

பதிவு

வீடியோ மாநாடுகள் பதிவு சேவையகத்தால் பதிவு செய்யப்படுகின்றன. ரெக்கார்டர் என்பது சிஸ்கோ மீட்டிங் சர்வரைப் போலவே உள்ளது. ரெக்கார்டருக்கு எந்த உரிமமும் நிறுவ தேவையில்லை. CallBridge சேவைகளை இயக்கும் சேவையகங்களுக்கு பதிவு உரிமங்கள் தேவை, அதாவது. ஒரு ரெக்கார்டிங் உரிமம் தேவை, அது CallBridge பாகத்திற்குப் பயன்படுத்தப்பட வேண்டும், சர்வரில் இயங்கும் ரெக்கார்டருக்கு அல்ல. ரெக்கார்டர் ஒரு எக்ஸ்டென்சிபிள் மெசேஜிங் மற்றும் பிரசன்ஸ் புரோட்டோகால் (XMPP) கிளையண்டாக செயல்படுகிறது, எனவே XMPP சேவையகம் CallBridge ஹோஸ்டிங் சர்வரில் இயக்கப்பட்டிருக்க வேண்டும்.

ஏனெனில் எங்களிடம் ஒரு கிளஸ்டர் உள்ளது மற்றும் கிளஸ்டரில் உள்ள மூன்று சேவையகங்களிலும் உரிமம் "நீட்டப்பட வேண்டும்". உரிமங்களில் உங்கள் தனிப்பட்ட கணக்கில், கிளஸ்டரில் உள்ள அனைத்து CMS சேவையகங்களின் a-இடைமுகங்களின் MAC முகவரிகளை நாங்கள் இணைக்கிறோம் (சேர்க்கிறோம்).

மேலும் இது கிளஸ்டரில் உள்ள ஒவ்வொரு சர்வரிலும் இருக்க வேண்டிய படம்

பொதுவாக, ரெக்கார்டரை வைப்பதற்கு பல காட்சிகள் உள்ளன, ஆனால் நாங்கள் இதை கடைபிடிப்போம்:


ரெக்கார்டரை அமைப்பதற்கு முன், வீடியோ மாநாடுகள் உண்மையில் பதிவு செய்யப்படும் இடத்தை நீங்கள் தயார் செய்ய வேண்டும். உண்மையில் இங்கே ссылка, அனைத்து பதிவுகளையும் எவ்வாறு அமைப்பது. நான் முக்கியமான புள்ளிகள் மற்றும் விவரங்களில் கவனம் செலுத்துகிறேன்:

1. கிளஸ்டரில் உள்ள முதல் சர்வரில் இருந்து சான்றிதழை நழுவ விடுவது நல்லது.
2. ரெக்கார்டர் அறக்கட்டளையில் தவறான சான்றிதழ் குறிப்பிடப்பட்டுள்ளதால், “ரெக்கார்டர் கிடைக்கவில்லை” பிழை ஏற்படலாம்.
3. பதிவு செய்வதற்குக் குறிப்பிடப்பட்ட NFS கோப்பகம் ரூட் கோப்பகமாக இல்லாவிட்டால் எழுதுவது வேலை செய்யாமல் போகலாம்.

சில நேரங்களில் ஒரு குறிப்பிட்ட பயனர் அல்லது இடத்தின் மாநாட்டை தானாகவே பதிவு செய்ய வேண்டிய அவசியம் உள்ளது.

இதற்காக, இரண்டு கால்புரோஃபைல்கள் உருவாக்கப்படுகின்றன:
பதிவு முடக்கப்பட்ட நிலையில்


மற்றும் தானியங்கி பதிவு செயல்பாடு


அடுத்து, தேவையான இடத்தில் தானியங்கி பதிவுச் செயல்பாடு கொண்ட கால்ப்ரோஃபைலை "இணைக்கிறோம்".


CMS இல், CallProfile வெளிப்படையாக ஏதேனும் இடம் அல்லது இடத்துடன் இணைக்கப்பட்டிருந்தால், இந்த CallProfile இந்த குறிப்பிட்ட இடைவெளிகளுடன் தொடர்புடையதாக மட்டுமே செயல்படும். மேலும் CallProfile எந்த இடத்துடனும் பிணைக்கப்படவில்லை என்றால், முன்னிருப்பாக எந்த CallProfile வெளிப்படையாக பிணைக்கப்படவில்லையோ அந்த இடைவெளிகளுக்கு அது பயன்படுத்தப்படும்.

அடுத்த முறை நிறுவனத்தின் உள் நெட்வொர்க்கிற்கு வெளியே 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-மற்றும்-பின்னர். pdf

ஆதாரம்: www.habr.com