സിസ്കോ മീറ്റിംഗ് സെർവർ 2.5.2. വീഡിയോ കോൺഫറൻസ് റെക്കോർഡിംഗ് ഫംഗ്‌ഷനുള്ള സ്‌കേലബിൾ, റെസിലന്റ് മോഡിലുള്ള ക്ലസ്റ്റർ

ഈ ലക്കത്തിൽ, പരാജയ ക്ലസ്റ്റർ മോഡിൽ ഒരു CMS സെർവർ സജ്ജീകരിക്കുന്നതിന്റെ ചില സങ്കീർണതകൾ ഞാൻ കാണിക്കുകയും വിശദീകരിക്കുകയും ചെയ്യും.


സിദ്ധാന്തംപൊതുവേ, മൂന്ന് തരം CMS സെർവർ വിന്യാസം ഉണ്ട്:

• സിംഗിൾ കമ്പൈൻഡ്(ഒറ്റ സംയുക്തം), അതായത്. ആവശ്യമായ എല്ലാ സേവനങ്ങളും പ്രവർത്തിക്കുന്ന ഒരു സെർവറാണിത്. മിക്ക കേസുകളിലും, ഇത്തരത്തിലുള്ള വിന്യാസം ആന്തരിക ക്ലയന്റ് ആക്‌സസിനും ഒരു സെർവറിന്റെ സ്കേലബിളിറ്റിയും റിഡൻഡൻസി പരിമിതികളും ഒരു നിർണായക പ്രശ്‌നമല്ലാത്ത ചെറിയ പരിതസ്ഥിതികളിലും അല്ലെങ്കിൽ അഡ്‌ഹോക്ക് പോലുള്ള ചില പ്രവർത്തനങ്ങൾ മാത്രം നിർവഹിക്കുന്ന സാഹചര്യങ്ങളിലും മാത്രമേ അനുയോജ്യമാകൂ. Cisco UCM-ലെ കോൺഫറൻസുകൾ.

  ജോലിയുടെ ഏകദേശ സ്കീം:
  

• സിംഗിൾ സ്പ്ലിറ്റ്(സിംഗിൾ സ്പ്ലിറ്റ്) എക്‌സ്‌റ്റേണൽ ആക്‌സസിനായി ഒരു പ്രത്യേക സെർവർ ചേർത്തുകൊണ്ട് മുമ്പത്തെ വിന്യാസ തരം വിപുലീകരിക്കുന്നു. ലെഗസി ഡിപ്ലോയ്‌മെന്റുകളിൽ, ബാഹ്യ ക്ലയന്റുകൾക്ക് ആക്‌സസ് ചെയ്യാൻ കഴിയുന്ന ഒരു സൈനികവൽക്കരിക്കപ്പെട്ട നെറ്റ്‌വർക്ക് സെഗ്‌മെന്റിൽ (DMZ) ഒരു CMS സെർവറും ആന്തരിക ക്ലയന്റുകൾക്ക് CMS ആക്‌സസ് ചെയ്യാൻ കഴിയുന്ന നെറ്റ്‌വർക്ക് കോറിലെ ഒരു CMS സെർവറും വിന്യസിക്കുക എന്നതാണ് ഇതിനർത്ഥം. ഈ പ്രത്യേക വിന്യാസ മോഡൽ ഇപ്പോൾ തരം എന്ന് വിളിക്കപ്പെടുന്നതിനെ അസാധുവാക്കുന്നു സിംഗിൾ എഡ്ജ്, അതിൽ സെർവറുകൾ അടങ്ങിയിരിക്കുന്നു സിസ്കോ എക്സ്പ്രസ് വേ, ഒന്നുകിൽ ഒരേ ഫയർവാൾ ബൈപാസ് കഴിവുകൾ ഉള്ളതോ ഉണ്ടായിരിക്കുന്നതോ ആയതിനാൽ ക്ലയന്റുകൾക്ക് ഒരു സമർപ്പിത എഡ്ജ് CMS സെർവർ ചേർക്കേണ്ടതില്ല.

  ജോലിയുടെ ഏകദേശ സ്കീം:
  

• അളക്കാവുന്നതും പ്രതിരോധശേഷിയുള്ളതും(സ്കേലബിൾ ആൻഡ് ഫാൾട്ട് ടോളറന്റ്) ഈ തരത്തിൽ ഓരോ ഘടകത്തിനും ആവർത്തനം ഉൾപ്പെടുന്നു, പരാജയപ്പെടുമ്പോൾ ആവർത്തനം നൽകുമ്പോൾ നിങ്ങളുടെ ആവശ്യങ്ങൾക്കനുസരിച്ച് അതിന്റെ പരമാവധി ശേഷിയിലേക്ക് വളരാൻ സിസ്റ്റത്തെ അനുവദിക്കുന്നു. സുരക്ഷിതമായ ബാഹ്യ ആക്സസ് നൽകുന്നതിന് സിംഗിൾ എഡ്ജ് ആശയവും ഇത് ഉപയോഗിക്കുന്നു. ഈ എപ്പിസോഡിൽ നമ്മൾ നോക്കുന്ന തരമാണിത്. ഇത്തരത്തിലുള്ള ക്ലസ്റ്റർ എങ്ങനെ വിന്യസിക്കണമെന്ന് ഞങ്ങൾ മനസ്സിലാക്കിയാൽ, മറ്റ് തരത്തിലുള്ള വിന്യാസങ്ങൾ ഞങ്ങൾ മനസ്സിലാക്കുക മാത്രമല്ല, ഡിമാൻഡിലെ സാധ്യതയുള്ള വളർച്ചയെ ഉൾക്കൊള്ളുന്നതിനായി CMS സെർവറുകളുടെ ക്ലസ്റ്ററുകൾ എങ്ങനെ സൃഷ്ടിക്കാമെന്ന് മനസിലാക്കാനും ഞങ്ങൾക്ക് കഴിയും.

വിന്യാസത്തിലേക്ക് പോകുന്നതിന് മുമ്പ്, നിങ്ങൾ ചില അടിസ്ഥാന കാര്യങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്, അതായത്

പ്രധാന CMS സോഫ്റ്റ്വെയർ ഘടകങ്ങൾ:

• ഡാറ്റാബേസ്: ഡയൽ പ്ലാൻ, ഉപയോക്തൃ ഇടങ്ങൾ, ഉപയോക്താക്കൾ എന്നിവ പോലുള്ള ചില കോൺഫിഗറേഷനുകൾ സംയോജിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. ഉയർന്ന ലഭ്യതയ്ക്ക് (സിംഗിൾ മാസ്റ്റർ) മാത്രം ക്ലസ്റ്ററിംഗിനെ പിന്തുണയ്ക്കുന്നു.
• പാലം വിളിക്കുക: കോളുകളുടെയും മൾട്ടിമീഡിയ പ്രക്രിയകളുടെയും മാനേജ്മെന്റിലും പ്രോസസ്സിംഗിലും പൂർണ്ണ നിയന്ത്രണം നൽകുന്ന ഓഡിയോ, വീഡിയോ കോൺഫറൻസിംഗിനായുള്ള ഒരു സേവനം. ഉയർന്ന ലഭ്യതയ്ക്കും സ്കേലബിലിറ്റിക്കുമായി ക്ലസ്റ്ററിംഗിനെ പിന്തുണയ്ക്കുന്നു.
• XMPP സെർവർ: Cisco Meeting Application കൂടാതെ/അല്ലെങ്കിൽ WebRTC(തത്സമയ ആശയവിനിമയം, അല്ലെങ്കിൽ ബ്രൗസറിൽ), അതുപോലെ ഇന്റർകോംപോണന്റ് സിഗ്നലിംഗ്. ഉയർന്ന ലഭ്യതയ്ക്കായി മാത്രം ക്ലസ്റ്റർ ചെയ്യാൻ കഴിയും.
• വെബ് ബ്രിഡ്ജ്: WebRTC-യിലേക്ക് ക്ലയന്റ് ആക്സസ് നൽകുന്നു.
• ലോഡ്ബാലൻസർ: സിംഗിൾ സ്പ്ലിറ്റ് മോഡിൽ സിസ്കോ മീറ്റിംഗ് ആപ്പുകൾക്കായി ഒരൊറ്റ കണക്ഷൻ പോയിന്റ് നൽകുന്നു. ഇൻകമിംഗ് കണക്ഷനുകൾക്കായി ബാഹ്യ ഇന്റർഫേസും പോർട്ടും ശ്രദ്ധിക്കുന്നു. അതുപോലെ, ലോഡ് ബാലൻസർ എക്സ്എംപിപി സെർവറിൽ നിന്ന് ഇൻകമിംഗ് ടിഎൽഎസ് കണക്ഷനുകൾ സ്വീകരിക്കുന്നു, അതിലൂടെ ബാഹ്യ ക്ലയന്റുകളിൽ നിന്ന് ടിസിപി കണക്ഷനുകൾ മാറാൻ കഴിയും.
  നമ്മുടെ സാഹചര്യത്തിൽ അതിന്റെ ആവശ്യമില്ല.
• ടേൺ സെർവർ: അനുവദിക്കുന്ന ഫയർവാൾ ബൈപാസ് സാങ്കേതികവിദ്യ നൽകുന്നു
  Cisco Meeting App അല്ലെങ്കിൽ SIP ഉപകരണങ്ങൾ ഉപയോഗിച്ച് ബാഹ്യ ക്ലയന്റുകളെ ബന്ധിപ്പിക്കുന്നതിന് ഞങ്ങളുടെ CMS ഒരു ഫയർവാളിന്റെയോ NAT-ന്റെയോ പിന്നിൽ സ്ഥാപിക്കുക. നമ്മുടെ സാഹചര്യത്തിൽ അതിന്റെ ആവശ്യമില്ല.
• വെബ് അഡ്മിൻ: പ്രത്യേക ഏകീകൃത മുഖ്യമന്ത്രി കോൺഫറൻസുകൾ ഉൾപ്പെടെ അഡ്മിനിസ്ട്രേറ്റീവ് ഇന്റർഫേസും API ആക്‌സസ്സും.

കോൺഫിഗറേഷൻ മോഡുകൾ

മറ്റ് മിക്ക സിസ്കോ ഉൽപ്പന്നങ്ങളിൽ നിന്നും വ്യത്യസ്തമായി, ഏത് തരത്തിലുള്ള വിന്യാസവും ഉൾക്കൊള്ളാൻ സിസ്‌കോ മീറ്റിംഗ് സെർവർ മൂന്ന് കോൺഫിഗറേഷൻ രീതികളെ പിന്തുണയ്ക്കുന്നു.

• കമാൻഡ് ലൈൻ (CLI): പ്രാരംഭ കോൺഫിഗറേഷനും സർട്ടിഫിക്കറ്റ് ടാസ്ക്കുകൾക്കുമായി MMP എന്നറിയപ്പെടുന്ന കമാൻഡ് ലൈൻ ഇന്റർഫേസ്.
• വെബ് അഡ്മിനിസ്ട്രേറ്റർ: പ്രാഥമികമായി കോൾബ്രിഡ്ജുമായി ബന്ധപ്പെട്ട കോൺഫിഗറേഷനുകൾക്കായി, പ്രത്യേകിച്ചും ഒരൊറ്റ ക്ലസ്റ്റേർഡ് അല്ലാത്ത സെർവർ സജ്ജീകരിക്കുമ്പോൾ.
• REST API: ഏറ്റവും സങ്കീർണ്ണമായ കോൺഫിഗറേഷൻ ടാസ്ക്കുകൾക്കും ക്ലസ്റ്റേർഡ് ഡാറ്റാബേസുമായി ബന്ധപ്പെട്ട ജോലികൾക്കും ഉപയോഗിക്കുന്നു.

മുകളിൽ പറഞ്ഞവ കൂടാതെ, പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു SFTP CMS സെർവറിലേക്കും പുറത്തേക്കും ഫയലുകൾ-സാധാരണയായി ലൈസൻസുകൾ, സർട്ടിഫിക്കറ്റുകൾ അല്ലെങ്കിൽ ലോഗുകൾ കൈമാറാൻ.

സിസ്‌കോയിൽ നിന്നുള്ള വിന്യാസ ഗൈഡുകളിൽ ക്ലസ്റ്റർ വിന്യസിക്കണമെന്ന് വെള്ളയിലും ഇംഗ്ലീഷിലും എഴുതിയിട്ടുണ്ട്. കുറഞ്ഞത് മൂന്ന് ഡാറ്റാബേസുകളുടെ പശ്ചാത്തലത്തിൽ സെർവറുകൾ (നോഡുകൾ). കാരണം ഒരു പുതിയ ഡാറ്റാബേസ് മാസ്റ്റർ തിരഞ്ഞെടുക്കുന്നതിനുള്ള സംവിധാനം ഒറ്റയക്ക എണ്ണം നോഡുകളിൽ മാത്രമേ പ്രവർത്തിക്കൂ, സാധാരണയായി ഡാറ്റാബേസ് മാസ്റ്ററിന് മിക്ക CMS സെർവർ ഡാറ്റാബേസുമായും ബന്ധമുണ്ട്.

പ്രാക്ടീസ് കാണിക്കുന്നതുപോലെ, രണ്ട് സെർവറുകൾ (നോഡുകൾ) ശരിക്കും പര്യാപ്തമല്ല. മാസ്റ്റർ റീബൂട്ട് ചെയ്യുമ്പോൾ സെലക്ഷൻ മെക്കാനിസം പ്രവർത്തിക്കുന്നു, റീബൂട്ട് ചെയ്ത സെർവർ കൊണ്ടുവന്നതിന് ശേഷം മാത്രമേ സ്ലേവ് സെർവർ മാസ്റ്ററാകൂ. എന്നിരുന്നാലും, രണ്ട് സെർവറുകളുടെ ഒരു ക്ലസ്റ്ററിൽ മാസ്റ്റർ സെർവർ പെട്ടെന്ന് പുറത്തുപോകുകയാണെങ്കിൽ, സ്ലേവ് സെർവർ മാസ്റ്ററാകില്ല, സ്ലേവ് പുറത്തുപോയാൽ, ശേഷിക്കുന്ന മാസ്റ്റർ സെർവർ സ്ലേവ് ആകും.

എന്നാൽ എക്സ്എംപിപിയുടെ പശ്ചാത്തലത്തിൽ, മൂന്ന് സെർവറുകളുടെ ഒരു ക്ലസ്റ്റർ കൂട്ടിച്ചേർക്കേണ്ടത് ശരിക്കും ആവശ്യമാണ്, കാരണം ഉദാഹരണത്തിന്, XMMP ലീഡർ പദവിയിലുള്ള സെർവറുകളിൽ ഒന്നിൽ XMPP സേവനം നിങ്ങൾ അപ്രാപ്‌തമാക്കുകയാണെങ്കിൽ, ശേഷിക്കുന്ന സെർവറിൽ XMPP ഫോളോവർ പദവിയിൽ തുടരുകയും XMPP-യിലേക്കുള്ള കോൾബ്രിഡ്ജ് കണക്ഷനുകൾ ഇല്ലാതാകുകയും ചെയ്യും, കാരണം കോൾബ്രിഡ്ജ് ലീഡർ സ്റ്റാറ്റസുള്ള എക്സ്എംപിപിയിലേക്ക് മാത്രമായി ബന്ധിപ്പിക്കുന്നു. ഇത് നിർണായകമാണ്, കാരണം... ഒരു വിളി പോലും പോകില്ല.

ഒരേ വിന്യാസ ഗൈഡുകളിൽ ഒരു എക്സ്എംപിപി സെർവറുള്ള ഒരു ക്ലസ്റ്റർ പ്രദർശിപ്പിച്ചിരിക്കുന്നു.

മുകളിലുള്ളവ കണക്കിലെടുക്കുമ്പോൾ, എന്തുകൊണ്ടെന്ന് വ്യക്തമാകും: ഇത് പരാജയ മോഡിൽ ആയതിനാൽ ഇത് പ്രവർത്തിക്കുന്നു.

ഞങ്ങളുടെ കാര്യത്തിൽ, മൂന്ന് നോഡുകളിലും XMPP സെർവർ ഉണ്ടായിരിക്കും.

ഞങ്ങളുടെ മൂന്ന് സെർവറുകളും പ്രവർത്തനക്ഷമമാണെന്ന് അനുമാനിക്കപ്പെടുന്നു.

DNS റെക്കോർഡുകൾ

നിങ്ങൾ സെർവറുകൾ സജ്ജീകരിക്കാൻ തുടങ്ങുന്നതിനുമുമ്പ്, നിങ്ങൾ DNS റെക്കോർഡുകൾ സൃഷ്ടിക്കേണ്ടതുണ്ട് А и എസ്.ആർ.വി തരങ്ങൾ:

ഞങ്ങളുടെ DNS റെക്കോർഡുകളിൽ example.com എന്ന രണ്ട് ഡൊമെയ്‌നുകളുണ്ടെന്ന കാര്യം ശ്രദ്ധിക്കുക conf.example.com. എല്ലാ സിസ്‌കോ യൂണിഫൈഡ് കമ്മ്യൂണിക്കേഷൻ മാനേജർ സബ്‌സ്‌ക്രൈബർമാർക്കും അവരുടെ യുആർഐകൾക്കായി ഉപയോഗിക്കാനാകുന്ന ഒരു ഡൊമെയ്‌നാണ് Example.com, അത് നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിൽ കൂടുതലായി കാണപ്പെടുന്നു അല്ലെങ്കിൽ ഉണ്ടായിരിക്കാൻ സാധ്യതയുണ്ട്. അല്ലെങ്കിൽ example.com ഉപയോക്താക്കൾ അവരുടെ ഇമെയിൽ വിലാസങ്ങൾക്കായി ഉപയോഗിക്കുന്ന അതേ ഡൊമെയ്‌നുമായി പൊരുത്തപ്പെടുന്നു. അല്ലെങ്കിൽ നിങ്ങളുടെ ലാപ്‌ടോപ്പിലെ ജാബർ ക്ലയന്റിന് ഒരു URI ഉണ്ടായിരിക്കാം [ഇമെയിൽ പരിരക്ഷിച്ചിരിക്കുന്നു]. ഡൊമെയ്ൻ confസിസ്കോ മീറ്റിംഗ് സെർവർ ഉപയോക്താക്കൾക്കായി കോൺഫിഗർ ചെയ്യുന്ന ഡൊമെയ്‌നാണ് .example.com. സിസ്കോ മീറ്റിംഗ് സെർവറിന്റെ ഡൊമെയ്ൻ ആയിരിക്കും conf.example.com, അതിനാൽ അതേ ജബ്ബർ ഉപയോക്താവിന്, Cisco Meeting Server-ലേക്ക് ലോഗിൻ ചെയ്യാൻ user@ URI ഉപയോഗിക്കേണ്ടതുണ്ട്.conf.example.com.

അടിസ്ഥാന കോൺഫിഗറേഷൻ

ചുവടെ വിവരിച്ചിരിക്കുന്ന എല്ലാ ക്രമീകരണങ്ങളും ഒരു സെർവറിൽ കാണിച്ചിരിക്കുന്നു, എന്നാൽ അവ ക്ലസ്റ്ററിലെ ഓരോ സെർവറിലും ചെയ്യേണ്ടതുണ്ട്.

QoS

CMS സൃഷ്ടിക്കുന്നതിനാൽ തൽസമയം കാലതാമസത്തിനും പാക്കറ്റ് നഷ്ടത്തിനും ട്രാഫിക് സെൻസിറ്റീവ്, മിക്ക കേസുകളിലും സേവനത്തിന്റെ ഗുണനിലവാരം (QoS) ക്രമീകരിക്കാൻ ശുപാർശ ചെയ്യുന്നു. ഇത് നേടുന്നതിന്, അത് സൃഷ്ടിക്കുന്ന ഡിഫറൻഷ്യേറ്റഡ് സർവീസസ് കോഡുകൾ (DSCPs) ഉപയോഗിച്ച് ടാഗിംഗ് പാക്കറ്റുകളെ CMS പിന്തുണയ്ക്കുന്നു. നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ നെറ്റ്‌വർക്ക് ഘടകങ്ങൾ എങ്ങനെയാണ് ട്രാഫിക് പ്രോസസ്സ് ചെയ്യുന്നത് എന്നതിനെ 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 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 എംഎസ് റൗണ്ട്-ട്രിപ്പ് സമയം. ഈ പരിധി കോൾ ബ്രിഡ്ജ് ക്ലസ്റ്ററിംഗിനെ അപേക്ഷിച്ച് കൂടുതൽ നിയന്ത്രിതമാണ്, അതിനാൽ ഭൂമിശാസ്ത്രപരമായി വിതരണം ചെയ്യുന്ന വിന്യാസങ്ങളിൽ ഇത് പലപ്പോഴും പരിമിതപ്പെടുത്തുന്ന ഘടകമാണ്.

ഒരു 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>

ക്ലസ്റ്റർ ആരംഭിച്ച സിഎംഎസ് സെർവറിന്റെ ഐപി വിലാസം നിലവിലുള്ള മാസ്റ്റർ ഐപി വിലാസം, മാസ്റ്റർ.

കമാൻഡ് ഉപയോഗിച്ച് എല്ലാ സെർവറുകളിലും ഞങ്ങളുടെ ഡാറ്റാബേസ് ക്ലസ്റ്റർ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു:

database cluster status

ശേഷിക്കുന്ന മൂന്നാമത്തെ സെർവറിലും ഞങ്ങൾ ഇത് ചെയ്യുന്നു.

തൽഫലമായി, ഞങ്ങളുടെ ആദ്യ സെർവർ മാസ്റ്ററാണെന്നും ബാക്കിയുള്ളവർ അടിമകളാണെന്നും മാറുന്നു.

വെബ് അഡ്മിൻ സേവനം

വെബ് അഡ്മിനിസ്ട്രേറ്റർ സേവനം പ്രവർത്തനക്ഷമമാക്കുക:

webadmin listen a 445

വെബ് ക്ലയന്റിലേക്കുള്ള ഉപയോക്തൃ ആക്‌സസ്സിന് പോർട്ട് 445 ഉപയോഗിക്കുന്നതിനാലാണ് പോർട്ട് 443 തിരഞ്ഞെടുത്തത്

ഇതുപോലുള്ള ഒരു കമാൻഡ് ഉപയോഗിച്ച് ഞങ്ങൾ വെബ് അഡ്മിൻ സേവനം സർട്ടിഫിക്കറ്റ് ഫയലുകൾ ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്യുന്നു:

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

കമാൻഡ് ഉപയോഗിച്ച് വെബ് അഡ്മിൻ പ്രവർത്തനക്ഷമമാക്കുക:

webadmin enable

എല്ലാം ശരിയാണെങ്കിൽ, നെറ്റ്‌വർക്കിനും സർട്ടിഫിക്കറ്റിനുമായി വെബ് അഡ്‌മിൻ ശരിയായി കോൺഫിഗർ ചെയ്‌തിരിക്കുന്നുവെന്ന് സൂചിപ്പിക്കുന്ന SUCCESS ലൈനുകൾ ഞങ്ങൾക്ക് ലഭിക്കും. ഞങ്ങൾ ഒരു വെബ് ബ്രൗസർ ഉപയോഗിച്ച് സേവനത്തിന്റെ പ്രവർത്തനക്ഷമത പരിശോധിച്ച് വെബ് അഡ്മിനിസ്ട്രേറ്ററുടെ വിലാസം നൽകുക, ഉദാഹരണത്തിന്: cms.example.com: 445

ബ്രിഡ്ജ് ക്ലസ്റ്ററിനെ വിളിക്കുക

എല്ലാ CMS വിന്യാസത്തിലും നിലവിലുള്ള ഒരേയൊരു സേവനമാണ് കോൾ ബ്രിഡ്ജ്. കോൾ ബ്രിഡ്ജാണ് പ്രധാന കോൺഫറൻസിംഗ് സംവിധാനം. ഇത് ഒരു SIP ഇന്റർഫേസും നൽകുന്നു, അതിലൂടെ കോളുകൾ അതിലേക്കോ അതിൽ നിന്നോ റൂട്ട് ചെയ്യാൻ കഴിയും, ഉദാഹരണത്തിന്, ഒരു Cisco Unified 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-കൾ നൽകുക, CMS[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 ക്ലയന്റ് ആയി പ്രവർത്തിക്കുന്നു, അതിനാൽ മറ്റ് ക്ലയന്റുകളെപ്പോലെ കോൺഫിഗർ ചെയ്യണം. പതിപ്പ് 2.1 മുതൽ പ്രൊഡക്ഷൻ എൻവയോൺമെന്റുകളിൽ പിന്തുണയ്ക്കുന്ന ഒരു സവിശേഷതയാണ് XMPP തെറ്റ് സഹിഷ്ണുത

താഴെ വിവരിച്ചിരിക്കുന്ന കമാൻഡുകൾ ഓരോ സെർവറിലും ഉചിതമായ സർട്ടിഫിക്കറ്റുകൾ സഹിതം എക്സിക്യൂട്ട് ചെയ്യണം.
അങ്ങനെ:

ഇതുപോലുള്ള ഒരു കമാൻഡ് ഉപയോഗിച്ച് ഞങ്ങൾ സർട്ടിഫിക്കറ്റുകളെ XMPP സേവനവുമായി ബന്ധപ്പെടുത്തുന്നു:

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

തുടർന്ന് കമാൻഡ് ഉപയോഗിച്ച് ലിസണിംഗ് ഇന്റർഫേസ് നിർവചിക്കുക:

xmpp listen a

XMPP സേവനത്തിന് ഒരു അദ്വിതീയ ഡൊമെയ്ൻ ആവശ്യമാണ്. ഇത് ഉപയോക്താക്കൾക്കുള്ള ലോഗിൻ ആണ്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഒരു ഉപയോക്താവ് CMA ആപ്പ് (അല്ലെങ്കിൽ WebRTC ക്ലയന്റ് വഴി) ഉപയോഗിച്ച് ലോഗിൻ ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ, അവർ userID@logindomain നൽകുക. ഞങ്ങളുടെ കാര്യത്തിൽ അത് userid@ ആയിരിക്കും.conf.example.com. എന്തുകൊണ്ട് അത് example.com മാത്രമല്ല? ഞങ്ങളുടെ പ്രത്യേക വിന്യാസത്തിൽ, ജാബർ ഉപയോക്താക്കൾ Unified CM-ൽ ഉദാഹരണം.com എന്നതിൽ ഉപയോഗിക്കുന്ന ഞങ്ങളുടെ ഏകീകൃത CM ഡൊമെയ്‌ൻ ഞങ്ങൾ തിരഞ്ഞെടുത്തു, അതിനാൽ CMS ഉപയോക്താക്കൾക്ക് SIP ഡൊമെയ്‌നുകൾ വഴി CMS-ലേക്ക് കോളുകൾ റൂട്ട് ചെയ്യുന്നതിന് ഞങ്ങൾക്ക് മറ്റൊരു ഡൊമെയ്‌ൻ ആവശ്യമാണ്.

ഇതുപോലുള്ള ഒരു കമാൻഡ് ഉപയോഗിച്ച് ഒരു XMPP ഡൊമെയ്ൻ സജ്ജീകരിക്കുക:

xmpp domain <domain>

കമാൻഡ് ഉപയോഗിച്ച് XMPP സേവനം പ്രവർത്തനക്ഷമമാക്കുക:

xmpp enable

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-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 സെർവറിലേക്ക് കമാൻഡുകൾ ശരിയായി അയയ്ക്കുന്നതിന്, ആവശ്യമായ എൻകോഡിംഗ് നിങ്ങൾ സജ്ജമാക്കേണ്ടതുണ്ട്

കമാൻഡ് ഉപയോഗിച്ച് ഞങ്ങൾ വെബ്ബ്രിഡ്ജ് വ്യക്തമാക്കുന്നു പോസ്റ്റ് പരാമീറ്റർ ഉപയോഗിച്ച് URL അർത്ഥവും cms.example.com



വെബ്ബ്രിഡ്ജിൽ തന്നെ, ആവശ്യമായ പാരാമീറ്ററുകൾ ഞങ്ങൾ സൂചിപ്പിക്കുന്നു: അതിഥി പ്രവേശനം, സംരക്ഷിത ആക്സസ് മുതലായവ.

ബ്രിഡ്ജ് ഗ്രൂപ്പുകളെ വിളിക്കുക

സ്ഥിരസ്ഥിതിയായി, CMS എല്ലായ്‌പ്പോഴും അതിന് ലഭ്യമായ കോൺഫറൻസിംഗ് ഉറവിടങ്ങൾ ഏറ്റവും കാര്യക്ഷമമായി ഉപയോഗിക്കുന്നില്ല.

ഉദാഹരണത്തിന്, മൂന്ന് പങ്കാളികളുമായുള്ള മീറ്റിംഗിൽ, ഓരോ പങ്കാളിയും മൂന്ന് വ്യത്യസ്ത കോൾ ബ്രിഡ്ജുകളിൽ അവസാനിച്ചേക്കാം. ഈ മൂന്ന് പങ്കാളികൾക്കും പരസ്പരം ആശയവിനിമയം നടത്തുന്നതിന്, കോൾ ബ്രിഡ്ജുകൾ എല്ലാ സെർവറുകളും ക്ലയന്റുകളും തമ്മിൽ ഒരേ സ്‌പെയ്‌സിൽ സ്വയമേവ കണക്ഷനുകൾ സ്ഥാപിക്കും, അതുവഴി എല്ലാ ക്ലയന്റുകളും ഒരേ സെർവറിലാണെന്ന് തോന്നുന്നു. നിർഭാഗ്യവശാൽ, ഒരു 3 വ്യക്തി കോൺഫറൻസ് ഇപ്പോൾ 9 മീഡിയ പോർട്ടുകൾ ഉപയോഗിക്കും എന്നതാണ് ഇതിന്റെ പോരായ്മ. ഇത് വ്യക്തമായും വിഭവങ്ങളുടെ കാര്യക്ഷമമല്ലാത്ത ഉപയോഗമാണ്. കൂടാതെ, ഒരു കോൾ ബ്രിഡ്ജ് ശരിക്കും ഓവർലോഡ് ചെയ്യുമ്പോൾ, കോളുകൾ സ്വീകരിക്കുന്നത് തുടരുകയും ആ കോൾ ബ്രിഡ്ജിന്റെ എല്ലാ വരിക്കാർക്കും കുറഞ്ഞ നിലവാരത്തിലുള്ള സേവനം നൽകുകയും ചെയ്യുക എന്നതാണ് ഡിഫോൾട്ട് മെക്കാനിസം.

കോൾ ബ്രിഡ്ജ് ഗ്രൂപ്പ് ഫീച്ചർ ഉപയോഗിച്ചാണ് ഈ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നത്. Cisco Meeting Server സോഫ്‌റ്റ്‌വെയറിന്റെ പതിപ്പ് 2.1-ൽ ഈ ഫീച്ചർ അവതരിപ്പിച്ചു, WebRTC പങ്കാളികൾ ഉൾപ്പെടെ ഇൻബൗണ്ട്, ഔട്ട്‌ബൗണ്ട് Cisco Meeting App (CMA) കോളുകൾക്കായി ലോഡ് ബാലൻസിംഗ് പിന്തുണയ്ക്കുന്നതിനായി ഇത് വിപുലീകരിച്ചു.

വീണ്ടും കണക്ഷൻ പ്രശ്നം പരിഹരിക്കാൻ, ഓരോ കോൾ ബ്രിഡ്ജിനും കോൺഫിഗർ ചെയ്യാവുന്ന മൂന്ന് ലോഡ് പരിധികൾ അവതരിപ്പിച്ചു:

ലോഡ്ലിമിറ്റ് - ഇത് ഒരു പ്രത്യേക കോൾ ബ്രിഡ്ജിനുള്ള പരമാവധി സംഖ്യാ ലോഡാണ്. ഓരോ പ്ലാറ്റ്‌ഫോമിനും CMS96000-ന് 1000, വെർച്വൽ മെഷീന് ഓരോ vCPU-ന് 1.25 GHz എന്നിങ്ങനെയുള്ള ഒരു ശുപാർശിത ലോഡ് പരിധിയുണ്ട്. പങ്കെടുക്കുന്നയാളുടെ റെസല്യൂഷനും ഫ്രെയിം റേറ്റും അനുസരിച്ച് വ്യത്യസ്‌ത കോളുകൾ ഒരു നിശ്ചിത അളവ് ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്നു.
NewConferenceLoadLimitBasisPoints (ഡിഫോൾട്ട് 50% ലോഡ്ലിമിറ്റ്) - സെർവർ ലോഡ് പരിധി സജ്ജീകരിക്കുന്നു, അതിനുശേഷം പുതിയ കോൺഫറൻസുകൾ നിരസിക്കുന്നു.
നിലവിലുള്ള കോൺഫറൻസ് ലോഡ്ലിമിറ്റ് ബേസിസ് പോയിന്റുകൾ (ലോഡ്ലിമിറ്റിന്റെ ഡിഫോൾട്ട് 80%) - നിലവിലുള്ള കോൺഫറൻസിൽ ചേരുന്ന പങ്കാളികൾ നിരസിക്കപ്പെടുന്നതിന് ശേഷം സെർവർ ലോഡ് മൂല്യം.

കോൾ ഡിസ്ട്രിബ്യൂഷനും ലോഡ് ബാലൻസിംഗിനും വേണ്ടി ഈ ഫീച്ചർ രൂപകൽപ്പന ചെയ്‌തിരിക്കുമ്പോൾ, മറ്റ് ഗ്രൂപ്പുകളായ TURN സെർവറുകൾ, വെബ് ബ്രിഡ്ജ് സെർവറുകൾ, റെക്കോർഡറുകൾ എന്നിവയും കോൾ ബ്രിഡ്ജ് ഗ്രൂപ്പുകൾക്ക് അസൈൻ ചെയ്യാനാകും, അങ്ങനെ അവ ഒപ്റ്റിമൽ ഉപയോഗത്തിനായി ശരിയായി ഗ്രൂപ്പുചെയ്യാനും കഴിയും. ഈ ഒബ്‌ജക്‌റ്റുകളിൽ ഏതെങ്കിലും ഒരു കോൾ ഗ്രൂപ്പിന് അസൈൻ ചെയ്‌തിട്ടില്ലെങ്കിൽ, അവ പ്രത്യേക മുൻഗണനകളൊന്നുമില്ലാതെ എല്ലാ സെർവറുകളിലും ലഭ്യമാകുമെന്ന് അനുമാനിക്കപ്പെടുന്നു.

ഈ പരാമീറ്ററുകൾ ഇവിടെ ക്രമീകരിച്ചിരിക്കുന്നു: cms.example.com:445/api/v1/സിസ്റ്റം/കോൺഫിഗറേഷൻ/ക്ലസ്റ്റർ

അടുത്തതായി, ഓരോ കോൾബ്രിഡ്ജിനും അത് ഏത് കോൾബ്രിഡ്ജിൽ ഉൾപ്പെട്ടതാണെന്ന് ഞങ്ങൾ സൂചിപ്പിക്കുന്നു:

ആദ്യത്തെ കോൾബ്രിഡ്ജ്

രണ്ടാമത്തെ കോൾബ്രിഡ്ജ്

മൂന്നാമത്തെ കോൾബ്രിഡ്ജ്


അങ്ങനെ, സിസ്കോ മീറ്റിംഗ് സെർവർ ക്ലസ്റ്ററിന്റെ ഉറവിടങ്ങൾ കൂടുതൽ കാര്യക്ഷമമായി ഉപയോഗിക്കുന്നതിന് ഞങ്ങൾ കോൾ ബ്രിഡിജ് ഗ്രൂപ്പ് കോൺഫിഗർ ചെയ്തു.

സജീവ ഡയറക്ടറിയിൽ നിന്ന് ഉപയോക്താക്കളെ ഇറക്കുമതി ചെയ്യുന്നു

വെബ് അഡ്മിൻ സേവനത്തിന് ഒരു LDAP കോൺഫിഗറേഷൻ വിഭാഗമുണ്ട്, എന്നാൽ ഇത് സങ്കീർണ്ണമായ കോൺഫിഗറേഷൻ ഓപ്ഷനുകൾ നൽകുന്നില്ല, കൂടാതെ വിവരങ്ങൾ ക്ലസ്റ്റർ ഡാറ്റാബേസിൽ സംഭരിക്കുന്നില്ല, അതിനാൽ ഓരോ സെർവറിലും വെബ് ഇന്റർഫേസ് വഴിയോ അല്ലെങ്കിൽ മുഖേനയോ സ്വമേധയാ കോൺഫിഗറേഷൻ നടത്തേണ്ടതുണ്ട്. API, അതിനാൽ ഞങ്ങൾ "മൂന്ന് തവണ "എഴുന്നേൽക്കരുത്" എന്നതിനാൽ ഞങ്ങൾ API വഴി ഡാറ്റ സജ്ജീകരിക്കും.

ആക്‌സസ് ചെയ്യാൻ URL ഉപയോഗിക്കുന്നു cms01.example.com:445/api/v1/ldapServers ഒരു LDAP സെർവർ ഒബ്‌ജക്റ്റ് സൃഷ്‌ടിക്കുന്നു, ഇനിപ്പറയുന്നതുപോലുള്ള പാരാമീറ്ററുകൾ വ്യക്തമാക്കുന്നു:

• സെർവർ ഐ.പി
• പോർട്ട് നമ്പർ
• ഉപയോക്തൃനാമം
• പാസ്വേഡ്
• സുരക്ഷിത

സുരക്ഷിതം - പോർട്ട് അനുസരിച്ച് ശരിയോ തെറ്റോ തിരഞ്ഞെടുക്കുക, 389 - സുരക്ഷിതമല്ല, 636 - പരിരക്ഷിതം.


സിസ്കോ മീറ്റിംഗ് സെർവറിലെ ആട്രിബ്യൂട്ടുകളിലേക്ക് LDAP സോഴ്സ് പാരാമീറ്ററുകൾ മാപ്പിംഗ് ചെയ്യുന്നു.
LDAP മാപ്പിംഗ്, LDAP ഡയറക്‌ടറിയിലെ ആട്രിബ്യൂട്ടുകളെ CMS-ലെ ആട്രിബ്യൂട്ടുകളിലേക്ക് മാപ്പ് ചെയ്യുന്നു. യഥാർത്ഥ ആട്രിബ്യൂട്ടുകൾ:

• ജിഡ്മാപ്പിംഗ്
• നെയിംമാപ്പിംഗ്
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecendaryUriMapping

ആട്രിബ്യൂട്ടുകളുടെ വിവരണംജെ.ഐ.ഡി. CMS-ൽ ഉപയോക്താവിന്റെ ലോഗിൻ ഐഡിയെ പ്രതിനിധീകരിക്കുന്നു. ഇതൊരു Microsoft Active Directory LDAP സെർവർ ആയതിനാൽ, CMS JID, LDAP-ലെ sAMAccountName-ലേക്ക് മാപ്പ് ചെയ്യുന്നു, അത് പ്രധാനമായും ഉപയോക്താവിന്റെ സജീവ ഡയറക്ടറി ലോഗിൻ ഐഡിയാണ്. നിങ്ങൾ sAMAccountName എടുത്ത് അതിന്റെ അവസാനം conf.pod6.cms.lab എന്ന ഡൊമെയ്‌ൻ ചേർക്കുക എന്നതും ശ്രദ്ധിക്കുക, കാരണം നിങ്ങളുടെ ഉപയോക്താക്കൾ CMS-ലേക്ക് ലോഗിൻ ചെയ്യാൻ ഉപയോഗിക്കുന്ന ലോഗിൻ ഇതാണ്.

നെയിംമാപ്പിംഗ് സജീവ ഡയറക്‌ടറി ഡിസ്‌പ്ലേ നെയിം ഫീൽഡിൽ അടങ്ങിയിരിക്കുന്നത് ഉപയോക്താവിന്റെ CMS നെയിം ഫീൽഡുമായി പൊരുത്തപ്പെടുത്തുന്നു.

coSpaceNameMapping ഡിസ്പ്ലേ നെയിം ഫീൽഡിനെ അടിസ്ഥാനമാക്കി ഒരു CMS സ്പേസ് നാമം സൃഷ്ടിക്കുന്നു. ഈ ആട്രിബ്യൂട്ട്, coSpaceUriMapping ആട്രിബ്യൂട്ടിനൊപ്പം, ഓരോ ഉപയോക്താവിനും ഒരു സ്പേസ് സൃഷ്ടിക്കാൻ ആവശ്യമാണ്.

coSpaceUriMapping ഉപയോക്താവിന്റെ സ്വകാര്യ ഇടവുമായി ബന്ധപ്പെട്ട URI-യുടെ ഉപയോക്തൃ ഭാഗം നിർവചിക്കുന്നു. ചില ഡൊമെയ്‌നുകൾ ബഹിരാകാശത്തേക്ക് ഡയൽ ചെയ്യുന്നതിനായി കോൺഫിഗർ ചെയ്യാവുന്നതാണ്. ഈ ഡൊമെയ്‌നുകളിലൊന്നിൽ ഉപയോക്തൃ ഭാഗം ഈ ഫീൽഡുമായി പൊരുത്തപ്പെടുന്നുവെങ്കിൽ, കോൾ ആ ഉപയോക്താവിന്റെ സ്‌പെയ്‌സിലേക്ക് നയിക്കപ്പെടും.

coSpaceSecendaryUriMapping ബഹിരാകാശത്ത് എത്താനുള്ള രണ്ടാമത്തെ URI നിർവചിക്കുന്നു. coSpaceUriMapping പാരാമീറ്ററിൽ നിർവചിച്ചിരിക്കുന്ന ആൽഫാന്യൂമെറിക് URI-ക്ക് പകരമായി ഇറക്കുമതി ചെയ്ത ഉപയോക്താവിന്റെ സ്‌പെയ്‌സിലേക്ക് കോളുകൾ റൂട്ട് ചെയ്യുന്നതിന് ഒരു സംഖ്യാ അപരനാമം ചേർക്കാൻ ഇത് ഉപയോഗിക്കാം.

LDAP സെർവറും LDAP മാപ്പിംഗും ക്രമീകരിച്ചിരിക്കുന്നു. ഇപ്പോൾ നിങ്ങൾ ഒരു LDAP ഉറവിടം സൃഷ്ടിച്ചുകൊണ്ട് അവയെ ഒന്നിച്ച് ലിങ്ക് ചെയ്യേണ്ടതുണ്ട്.

ആക്‌സസ് ചെയ്യാൻ URL ഉപയോഗിക്കുന്നു cms01.example.com:445/api/v1/ldapSource ഒരു LDAP ഉറവിട ഒബ്‌ജക്റ്റ് സൃഷ്‌ടിക്കുന്നു, ഇനിപ്പറയുന്നതുപോലുള്ള പാരാമീറ്ററുകൾ വ്യക്തമാക്കുന്നു:

• സെർവർ
• മാപ്പിംഗ്
• അടിസ്ഥാന ഡിഎൻ
• ഫിൽറ്റർ ചെയ്യുക

ഇപ്പോൾ LDAP കോൺഫിഗറേഷൻ പൂർത്തിയായി, നിങ്ങൾക്ക് മാനുവൽ സിൻക്രൊണൈസേഷൻ പ്രവർത്തനം നടത്താം.

ക്ലിക്ക് ചെയ്തുകൊണ്ട് ഓരോ സെർവറിന്റെയും വെബ് ഇന്റർഫേസിൽ ഞങ്ങൾ ഇത് ചെയ്യുന്നു ഇപ്പോൾ സമന്വയിപ്പിക്കുക വിഭാഗം ആക്ടീവ് ഡയറക്ടറി


അല്ലെങ്കിൽ കമാൻഡ് ഉള്ള API വഴി പോസ്റ്റ് ആക്സസ് ചെയ്യാൻ URL ഉപയോഗിക്കുന്നു cms01.example.com:445/api/v1/ldapSyncs

അഡ്-ഹോക്ക് കോൺഫറൻസുകൾ

ഇത് എന്താണ്?പരമ്പരാഗത സങ്കൽപ്പത്തിൽ, രണ്ട് പങ്കാളികൾ പരസ്പരം സംസാരിക്കുന്നതും പങ്കെടുക്കുന്നവരിൽ ഒരാൾ (യൂണിഫൈഡ് CM-ൽ രജിസ്റ്റർ ചെയ്ത ഒരു ഉപകരണം ഉപയോഗിച്ച്) "കോൺഫറൻസ്" ബട്ടൺ അമർത്തി മറ്റേ വ്യക്തിയെ വിളിച്ച് ആ മൂന്നാം കക്ഷിയുമായി സംസാരിച്ചതിന് ശേഷമാണ് കോൺഫറൻസ്. , ത്രികക്ഷി കോൺഫറൻസിൽ പങ്കെടുക്കുന്ന എല്ലാവരോടും ചേരാൻ "കോൺഫറൻസ്" ബട്ടൺ വീണ്ടും അമർത്തുക.

ഒരു CMS-ലെ ഷെഡ്യൂൾ ചെയ്‌ത കോൺഫറൻസിൽ നിന്ന് ഒരു അഡ്-ഹോക്ക് കോൺഫറൻസിനെ വ്യതിരിക്തമാക്കുന്നത് ഒരു അഡ്-ഹോക്ക് കോൺഫറൻസ് CMS-ലേക്കുള്ള ഒരു SIP കോൾ മാത്രമല്ല എന്നതാണ്. ഒരേ മീറ്റിംഗിലേക്ക് എല്ലാവരേയും ക്ഷണിക്കുന്നതിനായി കോൺഫറൻസ് ഇനീഷ്യേറ്റർ രണ്ടാമതും കോൺഫറൻസ് ബട്ടണിൽ ക്ലിക്കുചെയ്യുമ്പോൾ, എല്ലാ കോളുകളും കൈമാറ്റം ചെയ്യപ്പെടുന്ന ഒരു ഓൺ-ദി-ഫ്ലൈ കോൺഫറൻസ് സൃഷ്‌ടിക്കാൻ ഏകീകൃത മുഖ്യമന്ത്രി CMS-ലേക്ക് ഒരു API കോൾ ചെയ്യണം. പങ്കെടുക്കുന്നവർ ശ്രദ്ധിക്കാതെയാണ് ഇതെല്ലാം സംഭവിക്കുന്നത്.

കോൾ തുടരുന്നതിന് ഏകീകൃത മുഖ്യമന്ത്രി API ക്രെഡൻഷ്യലുകളും വെബ്അഡ്‌മിൻ വിലാസവും സേവനത്തിന്റെ പോർട്ടും SIP ട്രങ്കും നേരിട്ട് CMS സെർവറിലേക്ക് കോൺഫിഗർ ചെയ്യണം എന്നാണ് ഇതിനർത്ഥം.

ആവശ്യമെങ്കിൽ, CUCM-ന് ചലനാത്മകമായി CMS-ൽ ഒരു സ്പേസ് സൃഷ്ടിക്കാൻ കഴിയും, അതുവഴി ഓരോ കോളിനും CMS-ൽ എത്താനും സ്‌പെയ്‌സുകൾക്കായി ഉദ്ദേശിച്ചിട്ടുള്ള ഇൻകമിംഗ് കോൾ റൂളുമായി പൊരുത്തപ്പെടാനും കഴിയും.

CUCM-മായി സംയോജനം ലേഖനത്തിൽ വിവരിച്ചിരിക്കുന്ന അതേ രീതിയിൽ ക്രമീകരിച്ചിരിക്കുന്നു നേരത്തെ Cisco UCM-ൽ നിങ്ങൾ CMS-നായി മൂന്ന് ട്രങ്കുകൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്, മൂന്ന് കോൺഫറൻസ് ബ്രിഡ്ജുകൾ, SIP സുരക്ഷാ പ്രൊഫൈലിൽ മൂന്ന് വിഷയ നാമങ്ങൾ, റൂട്ട് ഗ്രൂപ്പുകൾ, റൂട്ട് ലിസ്റ്റുകൾ, മീഡിയ റിസോഴ്‌സ് ഗ്രൂപ്പുകൾ, മീഡിയ റിസോഴ്‌സ് ഗ്രൂപ്പ് ലിസ്റ്റുകൾ എന്നിവ വ്യക്തമാക്കുകയും കുറച്ച് റൂട്ടിംഗ് നിയമങ്ങൾ ചേർക്കുകയും വേണം. സിസ്കോ മീറ്റിംഗ് സെർവറിലേക്ക്.

SIP സുരക്ഷാ പ്രൊഫൈൽ:


തുമ്പികൾ:


ഓരോ തുമ്പിക്കൈയും ഒരുപോലെ കാണപ്പെടുന്നു:




കോൺഫറൻസ് പാലം


ഓരോ കോൺഫറൻസ് പാലവും ഒരേപോലെ കാണപ്പെടുന്നു:


റൂട്ട് ഗ്രൂപ്പ്


റൂട്ട് ലിസ്റ്റ്


മീഡിയ റിസോഴ്സ് ഗ്രൂപ്പ്


മീഡിയ റിസോഴ്സ് ഗ്രൂപ്പ് ലിസ്റ്റ്

കോൾ നിയമങ്ങൾ

യൂണിഫൈഡ് CM അല്ലെങ്കിൽ എക്‌സ്‌പ്രസ്‌വേ പോലുള്ള കൂടുതൽ വിപുലമായ കോൾ മാനേജ്‌മെന്റ് സിസ്റ്റങ്ങളിൽ നിന്ന് വ്യത്യസ്തമായി, പുതിയ കോളുകൾക്കായി SIP അഭ്യർത്ഥന-URI ഫീൽഡിൽ മാത്രമേ CMS ഡൊമെയ്‌ൻ നോക്കൂ. അതിനാൽ SIP INVITE സിപ്പിനുള്ളതാണെങ്കിൽ: [ഇമെയിൽ പരിരക്ഷിച്ചിരിക്കുന്നു]CMS domain.com-നെക്കുറിച്ച് മാത്രമാണ് ശ്രദ്ധിക്കുന്നത്. ഒരു കോൾ എവിടേക്കാണ് റൂട്ട് ചെയ്യേണ്ടതെന്ന് നിർണ്ണയിക്കാൻ CMS ഈ നിയമങ്ങൾ പാലിക്കുന്നു:

1. ഇൻകമിംഗ് കോൾ നിയമങ്ങളിൽ കോൺഫിഗർ ചെയ്‌തിരിക്കുന്ന ഡൊമെയ്‌നുകളുമായി SIP ഡൊമെയ്‌നുമായി പൊരുത്തപ്പെടുത്താൻ CMS ആദ്യം ശ്രമിക്കുന്നു. ഈ കോളുകൾ പിന്നീട് (“ടാർഗെറ്റഡ്”) സ്‌പെയ്‌സുകളിലേക്കോ നിർദ്ദിഷ്‌ട ഉപയോക്താക്കൾക്കോ ​​ഇന്റേണൽ IVR-കളിലേക്കോ നേരിട്ട് സംയോജിപ്പിച്ച Microsoft Lync/Skype for Business (S4B) ലക്ഷ്യസ്ഥാനങ്ങളിലേക്കോ നയിക്കാനാകും.
2. ഇൻകമിംഗ് കോൾ നിയമങ്ങളിൽ പൊരുത്തമില്ലെങ്കിൽ, കോൾ ഫോർവേഡിംഗ് ടേബിളിൽ കോൺഫിഗർ ചെയ്‌തിരിക്കുന്ന ഡൊമെയ്‌നുമായി പൊരുത്തപ്പെടാൻ CMS ശ്രമിക്കും. ഒരു പൊരുത്തമുണ്ടായാൽ, നിയമത്തിന് കോൾ വ്യക്തമായി നിരസിക്കാനോ കോൾ ഫോർവേഡ് ചെയ്യാനോ കഴിയും. ഈ സമയത്ത്, CMS ഡൊമെയ്‌ൻ മാറ്റിയെഴുതിയേക്കാം, ഇത് ചിലപ്പോൾ ലിങ്ക് ഡൊമെയ്‌നുകളെ വിളിക്കുന്നതിന് ഉപയോഗപ്രദമാണ്. നിങ്ങൾക്ക് പാസ് ത്രോ തിരഞ്ഞെടുക്കാനും കഴിയും, അതായത് ഫീൽഡുകളൊന്നും കൂടുതൽ പരിഷ്‌ക്കരിക്കില്ല, അല്ലെങ്കിൽ ഒരു ആന്തരിക CMS ഡയൽ പ്ലാൻ ഉപയോഗിക്കുക. കോൾ ഫോർവേഡിംഗ് നിയമങ്ങളിൽ പൊരുത്തമില്ലെങ്കിൽ, കോൾ നിരസിക്കുക എന്നതാണ് സ്ഥിരസ്ഥിതി. CMS-ൽ, കോൾ "ഫോർവേഡ്" ആണെങ്കിലും, മീഡിയ ഇപ്പോഴും CMS-ലേക്ക് ബന്ധിക്കപ്പെട്ടിരിക്കുന്നു, അതായത് അത് സിഗ്നലിംഗ്, മീഡിയ ട്രാഫിക് പാതയിലായിരിക്കും.
അപ്പോൾ ഫോർവേഡ് കോളുകൾ മാത്രമേ ഔട്ട്ഗോയിംഗ് കോൾ നിയമങ്ങൾക്ക് വിധേയമാകൂ. കോളുകൾ അയയ്‌ക്കുന്ന ലക്ഷ്യസ്ഥാനങ്ങൾ, ട്രങ്ക് തരം (അതൊരു പുതിയ Lync കോളോ സാധാരണ 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 സെർവറുകളുടെയും പൂർണ്ണ യോഗ്യതയുള്ള ഡൊമെയ്ൻ നാമത്തിന് (ഒരുപക്ഷേ ഐപി വിലാസം പോലും) ഉദ്ദേശിച്ചിട്ടുള്ള എല്ലാത്തിനും നിങ്ങൾ നിയമങ്ങൾ സജ്ജീകരിക്കേണ്ടതുണ്ട്. ഞങ്ങളുടെ ബാഹ്യ കോൾ നിയന്ത്രണം, ഏകീകൃത CM, ഓരോ CMS സെർവറുകൾക്കും പ്രത്യേകം സമർപ്പിച്ചിരിക്കുന്ന SIP ട്രങ്കുകൾ കോൺഫിഗർ ചെയ്യും. ഈ SIP ട്രങ്കുകളുടെ ലക്ഷ്യസ്ഥാനം ഒരു IP വിലാസമാണോ അതോ സെർവറിന്റെ FQDN ആണോ എന്നതിനെ ആശ്രയിച്ച്, CMS അതിന്റെ IP വിലാസത്തിലേക്കോ FQDN ലേക്ക് നയിക്കുന്ന കോളുകൾ സ്വീകരിക്കുന്നതിന് കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ടോ എന്ന് നിർണ്ണയിക്കും.

ഏറ്റവും കൂടുതൽ മുൻഗണനയുള്ള ഇൻബൗണ്ട് റൂൾ ഉള്ള ഡൊമെയ്‌ൻ ഏതൊരു ഉപയോക്തൃ ഇടങ്ങൾക്കുമുള്ള ഡൊമെയ്‌നായി ഉപയോഗിക്കുന്നു. LDAP വഴി ഉപയോക്താക്കൾ സമന്വയിപ്പിക്കുമ്പോൾ, CMS യാന്ത്രികമായി സ്‌പെയ്‌സുകൾ സൃഷ്‌ടിക്കുന്നു, എന്നാൽ URI-യുടെ (coSpaceUriMapping) ഉപയോക്തൃ ഭാഗം മാത്രം, ഉദാഹരണത്തിന്, user.space. ഭാഗം ഡൊമെയ്ൻ ഈ നിയമത്തെ അടിസ്ഥാനമാക്കിയാണ് പൂർണ്ണ യുആർഐ സൃഷ്ടിക്കുന്നത്. വാസ്തവത്തിൽ, നിങ്ങൾ ഈ സമയത്ത് വെബ് ബ്രിഡ്ജിലേക്ക് ലോഗിൻ ചെയ്യുകയാണെങ്കിൽ, സ്പേസ് യുആർഐക്ക് ഒരു ഡൊമെയ്ൻ ഇല്ലെന്ന് നിങ്ങൾ കാണും. ഈ നിയമം ഏറ്റവും ഉയർന്ന മുൻഗണനയായി സജ്ജീകരിക്കുന്നതിലൂടെ, ജനറേറ്റ് ചെയ്‌ത സ്‌പെയ്‌സുകൾക്കായി നിങ്ങൾ ഡൊമെയ്‌ൻ സജ്ജമാക്കുകയാണ് conf.example.com.


ഔട്ട്ഗോയിംഗ് കോൾ നിയമങ്ങൾ

യൂണിഫൈഡ് 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-ൽ, ഒരു കോൾപ്രൊഫൈൽ ഏതെങ്കിലും സ്‌പെയ്‌സുമായോ സ്‌പെയ്‌സുമായോ വ്യക്തമായി ബന്ധിപ്പിച്ചിട്ടുണ്ടെങ്കിൽ, ഈ പ്രത്യേക സ്‌പെയ്‌സുകളുമായി ബന്ധപ്പെട്ട് മാത്രമേ ഈ കോൾപ്രൊഫൈൽ പ്രവർത്തിക്കൂ. കൂടാതെ, 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