Cisco Meeting Server 2.5.2. Cluster ໃນ​ຮູບ​ແບບ​ການ​ປັບ​ຂະ​ຫນາດ​ແລະ​ຄວາມ​ຢືດ​ຢຸ່ນ​ທີ່​ມີ​ຟັງ​ຊັນ​ການ​ບັນ​ທຶກ​ການ​ປະ​ຊຸມ​ວິ​ດີ​ໂອ​

ໃນບັນຫານີ້ຂ້າພະເຈົ້າຈະສະແດງແລະອະທິບາຍບາງຄວາມຊັບຊ້ອນຂອງການຕັ້ງຄ່າເຊີຟເວີ CMS ໃນຮູບແບບ cluster ລົ້ມເຫລວ.


ທິດສະດີໂດຍທົ່ວໄປ, ມີສາມປະເພດຂອງການຕິດຕັ້ງເຊີບເວີ CMS:

• ປະສົມປະສານດຽວ(ລວມດຽວ), i.e. ນີ້ແມ່ນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງທີ່ບໍລິການທີ່ຈໍາເປັນທັງຫມົດກໍາລັງແລ່ນ. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ປະເພດຂອງການໃຊ້ງານນີ້ແມ່ນເຫມາະສົມສໍາລັບການເຂົ້າເຖິງລູກຄ້າພາຍໃນແລະໃນສະພາບແວດລ້ອມຂະຫນາດນ້ອຍກວ່າທີ່ການຂະຫຍາຍແລະການຈໍາກັດການຊ້ໍາຊ້ອນຂອງເຄື່ອງແມ່ຂ່າຍດຽວບໍ່ແມ່ນບັນຫາສໍາຄັນ, ຫຼືໃນສະຖານະການທີ່ CMS ພຽງແຕ່ປະຕິບັດຫນ້າທີ່ບາງຢ່າງເຊັ່ນ: ໂຄສະນາ. ກອງປະຊຸມກ່ຽວກັບ Cisco UCM.

  ໂຄງ​ການ​ປະ​ມານ​ການ​ເຮັດ​ວຽກ​:
  

• ແຍກດ່ຽວ(Single Split) ຂະຫຍາຍປະເພດການນຳໃຊ້ກ່ອນໜ້າໂດຍການເພີ່ມເຊີບເວີແຍກຕ່າງຫາກສຳລັບການເຂົ້າເຖິງພາຍນອກ. ໃນການປະຕິບັດແບບເກົ່າ, ນີ້ຫມາຍເຖິງການນໍາໄປໃຊ້ເຄື່ອງແມ່ຂ່າຍ CMS ຢູ່ໃນພາກສ່ວນເຄືອຂ່າຍທີ່ບໍ່ມີທະຫານ (DMZ) ບ່ອນທີ່ລູກຄ້າພາຍນອກສາມາດເຂົ້າເຖິງມັນໄດ້, ແລະເຄື່ອງແມ່ຂ່າຍ CMS ຫນຶ່ງໃນຫຼັກເຄືອຂ່າຍທີ່ລູກຄ້າພາຍໃນສາມາດເຂົ້າເຖິງ CMS. ຮູບແບບການນຳໃຊ້ສະເພາະນີ້ໄດ້ຖືກປ່ຽນແທນໂດຍອັນທີ່ເອີ້ນວ່າ ແຂບດຽວ, ເຊິ່ງປະກອບດ້ວຍເຄື່ອງແມ່ຂ່າຍ Cisco ທາງດ່ວນ, ເຊິ່ງບໍ່ວ່າຈະມີຫຼືຈະມີຄວາມສາມາດໃນການຂ້າມ Firewall ດຽວກັນຫຼາຍດັ່ງນັ້ນລູກຄ້າບໍ່ຈໍາເປັນຕ້ອງເພີ່ມເຄື່ອງແມ່ຂ່າຍ CMS ທີ່ອຸທິດຕົນ.

  ໂຄງ​ການ​ປະ​ມານ​ການ​ເຮັດ​ວຽກ​:
  

• ສາມາດຂະຫຍາຍໄດ້ ແລະທົນທານ(Scalable and Fault Tolerant) ປະເພດນີ້ປະກອບມີການຊ້ໍາຊ້ອນສໍາລັບແຕ່ລະອົງປະກອບ, ອະນຸຍາດໃຫ້ລະບົບການຂະຫຍາຍຕົວກັບຄວາມຕ້ອງການຂອງທ່ານກັບຄວາມສາມາດສູງສຸດຂອງຕົນໃນຂະນະທີ່ສະຫນອງການຊ້ໍາຊ້ອນໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວ. ມັນຍັງໃຊ້ແນວຄວາມຄິດ Single Edge ເພື່ອສະຫນອງການເຂົ້າເຖິງພາຍນອກທີ່ປອດໄພ. ນີ້ແມ່ນປະເພດທີ່ພວກເຮົາຈະເບິ່ງຢູ່ໃນຕອນນີ້. ຖ້າພວກເຮົາເຂົ້າໃຈວິທີການນໍາໃຊ້ກຸ່ມປະເພດນີ້, ພວກເຮົາຈະບໍ່ພຽງແຕ່ເຂົ້າໃຈປະເພດຂອງການໃຊ້ງານອື່ນໆ, ແຕ່ພວກເຮົາຍັງສາມາດເຂົ້າໃຈວິທີການສ້າງກຸ່ມຂອງເຄື່ອງແມ່ຂ່າຍ CMS ເພື່ອຮອງຮັບການຂະຫຍາຍຕົວທີ່ມີທ່າແຮງໃນຄວາມຕ້ອງການ.

ກ່ອນທີ່ຈະກ້າວໄປສູ່ການປະຕິບັດ, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈບາງສິ່ງພື້ນຖານ, ຄື

ອົງປະກອບຊອບແວ CMS ຕົ້ນຕໍ:

• ຖານຂໍ້ມູນ: ອະນຸຍາດໃຫ້ທ່ານສົມທົບການປັບຄ່າບາງຢ່າງ, ເຊັ່ນ: ແຜນການໂທ, ພື້ນທີ່ຜູ້ໃຊ້, ແລະຜູ້ໃຊ້ເອງ. ຮອງຮັບການຈັດກຸ່ມເພື່ອຄວາມພ້ອມສູງ (ແມ່ແບບດ່ຽວ) ເທົ່ານັ້ນ.
• ໂທຫາຂົວ: ການບໍລິການສໍາລັບການປະຊຸມສຽງ ແລະວິດີໂອທີ່ສະຫນອງການຄວບຄຸມຢ່າງເຕັມທີ່ກ່ຽວກັບການຄຸ້ມຄອງແລະການປະມວນຜົນການໂທແລະມັນຕິມີເດຍຂະບວນການ. ຮອງຮັບການຈັດກຸ່ມເພື່ອຄວາມພ້ອມ ແລະຄວາມສາມາດໃນການຂະຫຍາຍໄດ້ສູງ.
• ເຊີບເວີ XMPP: ຮັບ​ຜິດ​ຊອບ​ສໍາ​ລັບ​ການ​ລົງ​ທະ​ບຽນ​ແລະ​ການ​ກວດ​ສອບ​ລູກ​ຄ້າ​ໂດຍ​ນໍາ​ໃຊ້ Cisco Meeting Application ແລະ / ຫຼື WebRTC(ການສື່ສານໃນເວລາຈິງ, ຫຼືພຽງແຕ່ຢູ່ໃນຕົວທ່ອງເວັບ), ເຊັ່ນດຽວກັນກັບສັນຍານ intercomponent. ສາມາດເປັນກຸ່ມເພື່ອຄວາມພ້ອມທີ່ສູງເທົ່ານັ້ນ.
• ຂົວເວັບ: ໃຫ້ລູກຄ້າເຂົ້າເຖິງ WebRTC.
• Loadbalancer: ສະໜອງຈຸດເຊື່ອມຕໍ່ດຽວສໍາລັບ Cisco Meeting Apps ໃນໂໝດແຍກດ່ຽວ. ຟັງສ່ວນຕິດຕໍ່ພາຍນອກແລະພອດສໍາລັບການເຊື່ອມຕໍ່ຂາເຂົ້າ. ເທົ່າທຽມກັນ, ຕົວດຸ່ນດ່ຽງການໂຫຼດຍອມຮັບການເຊື່ອມຕໍ່ TLS ເຂົ້າມາຈາກເຄື່ອງແມ່ຂ່າຍ XMPP, ໂດຍຜ່ານທີ່ມັນສາມາດປ່ຽນການເຊື່ອມຕໍ່ TCP ຈາກລູກຄ້າພາຍນອກ.
  ໃນສະຖານະການຂອງພວກເຮົາມັນຈະບໍ່ຈໍາເປັນ.
• ລ້ຽວເຊີບເວີ: ສະຫນອງເຕັກໂນໂລຊີທາງຜ່ານ Firewall ທີ່ອະນຸຍາດໃຫ້
  ວາງ CMS ຂອງພວກເຮົາໄວ້ຫຼັງ Firewall ຫຼື NAT ເພື່ອເຊື່ອມຕໍ່ລູກຄ້າພາຍນອກໂດຍໃຊ້ Cisco Meeting App ຫຼື SIP ອຸປະກອນ. ໃນສະຖານະການຂອງພວກເຮົາມັນຈະບໍ່ຈໍາເປັນ.
• ຜູ້ເບິ່ງແຍງເວັບ: ການໂຕ້ຕອບການບໍລິຫານແລະການເຂົ້າເຖິງ API, ລວມທັງການປະຊຸມພິເສດ CM Unified.

ໂໝດການຕັ້ງຄ່າ

ບໍ່ເຫມືອນກັບຜະລິດຕະພັນ Cisco ອື່ນໆສ່ວນໃຫຍ່, Cisco Meeting Server ສະຫນັບສະຫນູນສາມວິທີການຕັ້ງຄ່າເພື່ອຮອງຮັບປະເພດຂອງການນໍາໃຊ້ໃດໆ.

• ເສັ້ນຄໍາສັ່ງ (CLI): ການໂຕ້ຕອບເສັ້ນຄໍາສັ່ງທີ່ຮູ້ຈັກເປັນ MMP ສໍາລັບການຕັ້ງຄ່າເບື້ອງຕົ້ນ ແລະວຽກງານໃບຢັ້ງຢືນ.
• Web Administrator: ຕົ້ນຕໍສໍາລັບການຕັ້ງຄ່າທີ່ກ່ຽວຂ້ອງກັບ CallBridge, ໂດຍສະເພາະໃນເວລາທີ່ຕັ້ງເຄື່ອງແມ່ຂ່າຍດຽວທີ່ບໍ່ແມ່ນກຸ່ມ.
• REST API: ໃຊ້ສໍາລັບວຽກງານການຕັ້ງຄ່າທີ່ຊັບຊ້ອນທີ່ສຸດ ແລະວຽກງານທີ່ກ່ຽວຂ້ອງກັບຖານຂໍ້ມູນທີ່ເປັນກຸ່ມ.

ນອກເຫນືອໄປຈາກຂ້າງເທິງ, ໂປໂຕຄອນຖືກນໍາໃຊ້ SFTP ເພື່ອໂອນໄຟລ໌—ໂດຍປົກກະຕິແລ້ວ ໃບອະນຸຍາດ, ໃບຢັ້ງຢືນ, ຫຼືບັນທຶກ—ໄປຫາ ແລະຈາກເຊີບເວີ CMS.

ໃນຄູ່ມືການນຳໃຊ້ຈາກ Cisco ມັນຖືກຂຽນເປັນສີຂາວ ແລະ ພາສາອັງກິດທີ່ກຸ່ມຕ້ອງຖືກນຳໃຊ້ ຢ່າງ​ຫນ້ອຍ​ສາມ​ servers (nodes) ໃນບໍລິບົດຂອງຖານຂໍ້ມູນ. ເນື່ອງຈາກວ່າ ພຽງແຕ່ມີຈໍານວນຄີກຂອງ nodes ກົນໄກສໍາລັບການເລືອກໃຫມ່ Database Master ເຮັດວຽກ, ແລະໂດຍທົ່ວໄປ Database Master ມີການເຊື່ອມຕໍ່ກັບສ່ວນໃຫຍ່ຂອງຖານຂໍ້ມູນ CMS server.

ແລະເປັນການປະຕິບັດສະແດງໃຫ້ເຫັນ, ສອງເຄື່ອງແມ່ຂ່າຍ (nodes) ແມ່ນບໍ່ພຽງພໍ. ກົນໄກການຄັດເລືອກເຮັດວຽກເມື່ອ Master ຖືກ rebooted, Slave server ກາຍເປັນ Master ພຽງແຕ່ຫຼັງຈາກເຄື່ອງແມ່ຂ່າຍທີ່ rebooted ຂຶ້ນມາ. ຢ່າງໃດກໍຕາມ, ຖ້າຢູ່ໃນກຸ່ມຂອງສອງເຄື່ອງແມ່ຂ່າຍທີ່ Master server ອອກໄປຢ່າງກະທັນຫັນ, ຫຼັງຈາກນັ້ນ Slave server ຈະບໍ່ກາຍເປັນ Master, ແລະຖ້າ Slave ອອກໄປ, ຫຼັງຈາກນັ້ນເຄື່ອງແມ່ຂ່າຍ Master ທີ່ຍັງເຫຼືອຈະກາຍເປັນ Slave.

ແຕ່ໃນສະພາບການຂອງ XMPP, ມັນກໍ່ເປັນສິ່ງຈໍາເປັນທີ່ຈະລວບລວມກຸ່ມຂອງສາມເຄື່ອງແມ່ຂ່າຍ, ເພາະວ່າ ສໍາລັບຕົວຢ່າງ, ຖ້າທ່ານປິດການບໍລິການ XMPP ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງທີ່ XMMP ຢູ່ໃນສະຖານະຜູ້ນໍາ, ຫຼັງຈາກນັ້ນໃນເຄື່ອງແມ່ຂ່າຍທີ່ຍັງເຫຼືອ XMPP ຈະຍັງຄົງຢູ່ໃນສະຖານະຜູ້ຕິດຕາມແລະການເຊື່ອມຕໍ່ CallBridge ກັບ XMPP ຈະລົ້ມລົງ, ເພາະວ່າ. CallBridge ເຊື່ອມຕໍ່ສະເພາະກັບ XMPP ກັບສະຖານະຜູ້ນໍາ. ແລະນີ້ແມ່ນສໍາຄັນ, ເພາະວ່າ ... ບໍ່ແມ່ນການໂທດຽວຈະຜ່ານ.

ນອກຈາກນີ້ໃນການນໍາໃຊ້ດຽວກັນນໍາພາກຸ່ມທີ່ມີເຄື່ອງແມ່ຂ່າຍ XMPP ຫນຶ່ງແມ່ນສະແດງໃຫ້ເຫັນ.

ແລະຄໍານຶງເຖິງຂ້າງເທິງ, ມັນຈະກາຍເປັນທີ່ຈະແຈ້ງວ່າເປັນຫຍັງ: ມັນເຮັດວຽກເນື່ອງຈາກວ່າມັນຢູ່ໃນຮູບແບບການລົ້ມເຫຼວ.

ໃນກໍລະນີຂອງພວກເຮົາ, ເຄື່ອງແມ່ຂ່າຍ XMPP ຈະມີຢູ່ໃນທັງສາມ nodes.

ມັນສົມມຸດວ່າທັງສາມເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາແມ່ນຂຶ້ນ.

ບັນທຶກ DNS

ກ່ອນທີ່ທ່ານຈະເລີ່ມຕົ້ນການຕັ້ງຄ່າເຄື່ອງແມ່ຂ່າຍ, ທ່ານຈໍາເປັນຕ້ອງສ້າງບັນທຶກ DNS А и SRV ປະເພດ:

ກະລຸນາສັງເກດວ່າໃນບັນທຶກ DNS ຂອງພວກເຮົາມີສອງໂດເມນ example.com ແລະ conf.example.com. Example.com ເປັນໂດເມນທີ່ຜູ້ສະໝັກໃຊ້ Cisco Unified Communication Manager ທັງໝົດສາມາດໃຊ້ສໍາລັບ URIs ຂອງເຂົາເຈົ້າ, ເຊິ່ງມີຢູ່ໃນໂຄງສ້າງພື້ນຖານຂອງທ່ານຫຼາຍທີ່ສຸດ ຫຼືມີແນວໂນ້ມທີ່ຈະມີຢູ່. ຫຼື example.com ກົງກັບໂດເມນດຽວກັນທີ່ຜູ້ໃຊ້ໃຊ້ສໍາລັບທີ່ຢູ່ອີເມວຂອງເຂົາເຈົ້າ. ຫຼືລູກຄ້າ Jabber ໃນແລັບທັອບຂອງເຈົ້າອາດມີ URI [email protected]. ໂດເມນ conf.example.com ແມ່ນໂດເມນທີ່ຈະຖືກຕັ້ງຄ່າສໍາລັບຜູ້ໃຊ້ Cisco Meeting Server. ໂດເມນຂອງ Cisco Meeting Server ຈະເປັນ conf.example.com, ດັ່ງນັ້ນສໍາລັບຜູ້ໃຊ້ Jabber ດຽວກັນ, user@ URI ຈະຕ້ອງຖືກນໍາໃຊ້ເພື່ອເຂົ້າສູ່ລະບົບ Cisco Meeting Serverconf.example.com.

ການຕັ້ງຄ່າພື້ນຖານ

ການຕັ້ງຄ່າທັງຫມົດທີ່ອະທິບາຍຂ້າງລຸ່ມນີ້ແມ່ນສະແດງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍດຽວ, ແຕ່ພວກເຂົາຕ້ອງເຮັດໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍໃນກຸ່ມ.

QoS

ນັບຕັ້ງແຕ່ CMS ສ້າງ ເວ​ລາ​ຈິງ ການຈະລາຈອນທີ່ອ່ອນໄຫວຕໍ່ກັບຄວາມລ່າຊ້າແລະການສູນເສຍແພັກເກັດ, ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ມັນແນະນໍາໃຫ້ຕັ້ງຄ່າຄຸນນະພາບຂອງການບໍລິການ (QoS). ເພື່ອເຮັດສິ່ງນີ້, CMS ສະຫນັບສະຫນູນແພັກເກັດແທໍກທີ່ມີລະຫັດການບໍລິການທີ່ແຕກຕ່າງກັນ (DSCPs) ທີ່ມັນສ້າງ. ເຖິງແມ່ນວ່າການຈັດລໍາດັບຄວາມສໍາຄັນຂອງການຈະລາຈອນທີ່ອີງໃສ່ DSCP ແມ່ນຂຶ້ນກັບວິທີການປະຕິບັດການຈະລາຈອນໂດຍອົງປະກອບເຄືອຂ່າຍຂອງໂຄງສ້າງພື້ນຖານຂອງທ່ານ, ໃນກໍລະນີຂອງພວກເຮົາພວກເຮົາຈະກໍາຫນົດຄ່າ CMS ຂອງພວກເຮົາກັບການຈັດລໍາດັບຄວາມສໍາຄັນ DSCP ປົກກະຕິໂດຍອີງໃສ່ການປະຕິບັດທີ່ດີທີ່ສຸດຂອງ QoS.

ໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍພວກເຮົາຈະໃສ່ຄໍາສັ່ງເຫຼົ່ານີ້

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), ປະເພດອື່ນໆຂອງການຈະລາຈອນ latency ຕ່ໍາເຊັ່ນ SIP ແລະ XMPP ໃຊ້ AF31 (DSCP 0x1A).

ພວກເຮົາກວດເບິ່ງ:

NTP

Network Time Protocol (NTP) ມີຄວາມສໍາຄັນບໍ່ພຽງແຕ່ສໍາລັບການສະຫນອງເວລາທີ່ຖືກຕ້ອງຂອງການໂທແລະກອງປະຊຸມ, ແຕ່ຍັງສໍາລັບການຢັ້ງຢືນໃບຢັ້ງຢືນ.

ເພີ່ມເຄື່ອງແມ່ຂ່າຍ NTP ໃສ່ໂຄງສ້າງພື້ນຖານຂອງທ່ານດ້ວຍຄໍາສັ່ງເຊັ່ນ:

ntp server add <server>

ໃນກໍລະນີຂອງພວກເຮົາ, ມີສອງເຄື່ອງແມ່ຂ່າຍດັ່ງກ່າວ, ດັ່ງນັ້ນຈະມີສອງທີມ.
ພວກເຮົາກວດເບິ່ງ:

ແລະກໍານົດເຂດເວລາສໍາລັບເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ

DNS

ພວກເຮົາເພີ່ມເຄື່ອງແມ່ຂ່າຍ DNS ໃສ່ CMS ດ້ວຍຄໍາສັ່ງເຊັ່ນ:

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

ໃນກໍລະນີຂອງພວກເຮົາ, ມີສອງເຄື່ອງແມ່ຂ່າຍດັ່ງກ່າວ, ດັ່ງນັ້ນຈະມີສອງທີມ.
ພວກເຮົາກວດເບິ່ງ:

ການຕັ້ງຄ່າການໂຕ້ຕອບເຄືອຂ່າຍ

ພວກເຮົາ configure interface ດ້ວຍຄໍາສັ່ງເຊັ່ນ:

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

ພວກເຮົາກວດເບິ່ງ:

ຊື່ເຊີບເວີ (ຊື່ເຈົ້າພາບ)

ພວກເຮົາຕັ້ງຊື່ເຊີບເວີດ້ວຍຄໍາສັ່ງເຊັ່ນ:

hostname <name>

ແລະພວກເຮົາ reboot.


ນີ້ເຮັດສໍາເລັດການຕັ້ງຄ່າພື້ນຖານ.

ໃບຢັ້ງຢືນ

ທິດສະດີCisco Meeting Server ຕ້ອງການການສື່ສານແບບເຂົ້າລະຫັດລະຫວ່າງອົງປະກອບຕ່າງໆ, ແລະດ້ວຍເຫດນີ້, ໃບຢັ້ງຢືນ X.509 ແມ່ນຕ້ອງການສໍາລັບການນໍາໃຊ້ CMS ທັງໝົດ. ພວກເຂົາຊ່ວຍຮັບປະກັນວ່າການບໍລິການ / ເຊີບເວີຖືກໄວ້ວາງໃຈໂດຍເຄື່ອງແມ່ຂ່າຍ / ການບໍລິການອື່ນໆ.

ແຕ່ລະບໍລິການຕ້ອງການໃບຢັ້ງຢືນ, ແຕ່ການສ້າງໃບຢັ້ງຢືນແຍກຕ່າງຫາກສໍາລັບແຕ່ລະບໍລິການສາມາດເຮັດໃຫ້ເກີດຄວາມສັບສົນແລະຄວາມສັບສົນທີ່ບໍ່ຈໍາເປັນ. ໂຊກດີ, ພວກເຮົາສາມາດສ້າງຄູ່ຄີສາທາລະນະ-ເອກະຊົນຂອງໃບຢັ້ງຢືນແລະຫຼັງຈາກນັ້ນນໍາມາໃຊ້ຄືນໃນຫຼາຍການບໍລິການ. ໃນກໍລະນີຂອງພວກເຮົາ, ໃບຢັ້ງຢືນດຽວກັນຈະຖືກນໍາໃຊ້ສໍາລັບ Call Bridge, XMPP Server, Web Bridge ແລະ Web Admin. ດັ່ງນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງສ້າງຄູ່ຂອງລະຫັດໃບຢັ້ງຢືນສາທາລະນະແລະເອກະຊົນສໍາລັບແຕ່ລະເຄື່ອງແມ່ຂ່າຍໃນກຸ່ມ.

ການຈັດກຸ່ມຖານຂໍ້ມູນ, ຢ່າງໃດກໍຕາມ, ມີຄວາມຕ້ອງການໃບຢັ້ງຢືນພິເສດບາງຢ່າງແລະດັ່ງນັ້ນຈຶ່ງຮຽກຮ້ອງໃຫ້ມີໃບຢັ້ງຢືນຂອງຕົນເອງທີ່ແຕກຕ່າງຈາກການບໍລິການອື່ນໆ. CMS ໃຊ້ໃບຢັ້ງຢືນເຊີບເວີ, ເຊິ່ງຄ້າຍຄືກັບໃບຢັ້ງຢືນທີ່ໃຊ້ໂດຍເຄື່ອງແມ່ຂ່າຍອື່ນ, ແຕ່ຍັງມີໃບຢັ້ງຢືນລູກຄ້າທີ່ໃຊ້ສໍາລັບການເຊື່ອມຕໍ່ຖານຂໍ້ມູນ. ໃບຢັ້ງຢືນຖານຂໍ້ມູນແມ່ນໃຊ້ສໍາລັບທັງການກວດສອບຄວາມຖືກຕ້ອງແລະການເຂົ້າລະຫັດ. ແທນທີ່ຈະໃຫ້ຊື່ຜູ້ໃຊ້ແລະລະຫັດຜ່ານສໍາລັບລູກຄ້າເພື່ອເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ, ມັນສະເຫນີໃບຢັ້ງຢືນລູກຄ້າທີ່ໄວ້ວາງໃຈໂດຍເຄື່ອງແມ່ຂ່າຍ. ແຕ່ລະເຊີບເວີໃນກຸ່ມຖານຂໍ້ມູນຈະໃຊ້ຄູ່ຄີສາທາລະນະ ແລະສ່ວນຕົວດຽວກັນ. ນີ້ອະນຸຍາດໃຫ້ເຄື່ອງແມ່ຂ່າຍທັງຫມົດໃນກຸ່ມສາມາດເຂົ້າລະຫັດຂໍ້ມູນໃນລັກສະນະທີ່ມັນສາມາດຖືກຖອດລະຫັດໂດຍເຄື່ອງແມ່ຂ່າຍອື່ນໆທີ່ແບ່ງປັນຄູ່ຄີດຽວກັນ.

ເພື່ອການເຮັດວຽກຊ້ຳຊ້ອນ, ກຸ່ມຖານຂໍ້ມູນຈະຕ້ອງປະກອບດ້ວຍຢ່າງໜ້ອຍ 3 ເຊີບເວີ, ແຕ່ບໍ່ເກີນ 5, ໂດຍມີເວລາໄປກັບສູງສຸດ 200 ms ລະຫວ່າງສະມາຊິກກຸ່ມໃດນຶ່ງ. ຂອບເຂດຈໍາກັດນີ້ແມ່ນຈໍາກັດຫຼາຍກ່ວາສໍາລັບ Call Bridge clustering, ສະນັ້ນມັນມັກຈະເປັນປັດໃຈຈໍາກັດໃນການແຈກຢາຍຕາມພູມສັນຖານ.

ບົດບາດຂອງຖານຂໍ້ມູນສໍາລັບ CMS ມີຈໍານວນຂໍ້ກໍານົດທີ່ເປັນເອກະລັກ. ບໍ່ເຫມືອນກັບບົດບາດອື່ນໆ, ມັນຮຽກຮ້ອງໃຫ້ມີໃບຢັ້ງຢືນລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍ, ບ່ອນທີ່ໃບຢັ້ງຢືນລູກຄ້າມີພາກສະຫນາມ CN ສະເພາະທີ່ນໍາສະເຫນີໃຫ້ກັບເຄື່ອງແມ່ຂ່າຍ.

CMS ໃຊ້ຖານຂໍ້ມູນ postgres ທີ່ມີຕົ້ນສະບັບຫນຶ່ງແລະ replicas ຄືກັນຫມົດ. ມີພຽງແຕ່ຫນຶ່ງຖານຂໍ້ມູນຕົ້ນຕໍໃນເວລາດຽວ ("ເຄື່ອງແມ່ຂ່າຍຂອງຖານຂໍ້ມູນ"). ສະມາຊິກທີ່ຍັງເຫຼືອຂອງກຸ່ມແມ່ນ replicas ຫຼື "ລູກຄ້າຖານຂໍ້ມູນ".

ກຸ່ມຖານຂໍ້ມູນຕ້ອງການໃບຢັ້ງຢືນເຊີບເວີສະເພາະ ແລະໃບຢັ້ງຢືນລູກຄ້າ. ພວກເຂົາຕ້ອງໄດ້ຮັບການເຊັນໂດຍໃບຢັ້ງຢືນ, ໂດຍປົກກະຕິແມ່ນອົງການໃບຢັ້ງຢືນເອກະຊົນພາຍໃນ. ເນື່ອງຈາກວ່າສະມາຊິກຂອງກຸ່ມຖານຂໍ້ມູນສາມາດກາຍເປັນແມ່ແບບໄດ້, ເຄື່ອງແມ່ຂ່າຍຖານຂໍ້ມູນແລະຄູ່ໃບຢັ້ງຢືນລູກຄ້າ (ທີ່ມີລະຫັດສາທາລະນະແລະສ່ວນຕົວ) ຕ້ອງໄດ້ຮັບການຄັດລອກໄປຫາເຄື່ອງແມ່ຂ່າຍທັງຫມົດເພື່ອໃຫ້ພວກເຂົາສາມາດສົມມຸດວ່າຕົວຕົນຂອງລູກຄ້າຫຼືເຄື່ອງແມ່ຂ່າຍຖານຂໍ້ມູນ. ນອກຈາກນັ້ນ, ໃບຢັ້ງຢືນຮາກຂອງ CA ຕ້ອງໄດ້ຮັບການໂຫລດເພື່ອຮັບປະກັນວ່າໃບຢັ້ງຢືນລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍສາມາດກວດສອບໄດ້.

ດັ່ງນັ້ນ, ພວກເຮົາສ້າງຄໍາຮ້ອງຂໍສໍາລັບໃບຢັ້ງຢືນທີ່ຈະຖືກນໍາໃຊ້ໂດຍການບໍລິການເຄື່ອງແມ່ຂ່າຍທັງຫມົດຍົກເວັ້ນຖານຂໍ້ມູນ (ຈະມີຄໍາຮ້ອງຂໍແຍກຕ່າງຫາກສໍາລັບການນີ້) ດ້ວຍຄໍາສັ່ງເຊັ່ນ:

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

ໃນ CN ພວກເຮົາຂຽນຊື່ທົ່ວໄປຂອງເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ. ຕົວຢ່າງ, ຖ້າ hostnames ຂອງເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ ເຊີບເວີ 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) ຊື່ຂອງເຄື່ອງແມ່ຂ່າຍທີ່ສອດຄ້ອງກັນ.

ພວກເຮົາປະຕິບັດຂັ້ນຕອນນີ້ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍດຽວ (!), ແລະພວກເຮົາຈະອັບໂຫລດໃບຢັ້ງຢືນແລະໄຟລ໌ .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, ທ່ານສາມາດກຳນົດຄ່າ ແລະເປີດໃຊ້ການຈັດກຸ່ມຖານຂໍ້ມູນລະຫວ່າງສາມໂຫນດໄດ້. ຂັ້ນ​ຕອນ​ທໍາ​ອິດ​ແມ່ນ​ເພື່ອ​ຄັດ​ເລືອກ​ເອົາ​ຫນຶ່ງ server ເປັນ node ຕົ້ນ​ສະ​ບັບ​ຂອງ​ກຸ່ມ​ຖານ​ຂໍ້​ມູນ​ແລະ configure ມັນ​ຢ່າງ​ເຕັມ​ທີ່​.

ຖານຂໍ້ມູນຕົ້ນສະບັບ

ຂັ້ນ​ຕອນ​ທໍາ​ອິດ​ໃນ​ການ​ສ້າງ​ຕັ້ງ replication ຖານ​ຂໍ້​ມູນ​ແມ່ນ​ການ​ລະ​ບຸ​ໃບ​ຢັ້ງ​ຢືນ​ການ​ທີ່​ຈະ​ນໍາ​ໃຊ້​ສໍາ​ລັບ​ຖານ​ຂໍ້​ມູນ​. ນີ້ແມ່ນເຮັດໄດ້ໂດຍໃຊ້ຄໍາສັ່ງເຊັ່ນ:

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

ຕອນນີ້ໃຫ້ບອກ CMS ວ່າສ່ວນຕິດຕໍ່ໃດທີ່ຈະໃຊ້ສໍາລັບການລວບລວມຖານຂໍ້ມູນດ້ວຍຄໍາສັ່ງ:

database cluster localnode a

ຫຼັງຈາກນັ້ນ, ພວກເຮົາເລີ່ມຕົ້ນຖານຂໍ້ມູນກຸ່ມຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຕົ້ນຕໍດ້ວຍຄໍາສັ່ງ:

database cluster initialize

Client Database Nodes

ພວກເຮົາເຮັດຂັ້ນຕອນດຽວກັນ, ພຽງແຕ່ແທນທີ່ຈະເປັນຄໍາສັ່ງ ເລີ່ມຕົ້ນກຸ່ມຖານຂໍ້ມູນ ໃສ່ຄໍາສັ່ງເຊັ່ນ:

database cluster join <ip address existing master>

ບ່ອນທີ່ ip ທີ່ຢູ່ ip ຕົ້ນສະບັບທີ່ມີຢູ່ແລ້ວຂອງເຄື່ອງແມ່ຂ່າຍ CMS ທີ່ກຸ່ມໄດ້ຖືກເລີ່ມຕົ້ນ, ພຽງແຕ່ Master.

ພວກເຮົາກວດເບິ່ງວິທີການທີ່ກຸ່ມຖານຂໍ້ມູນຂອງພວກເຮົາເຮັດວຽກຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທັງຫມົດດ້ວຍຄໍາສັ່ງ:

database cluster status

ພວກເຮົາເຮັດເຊັ່ນດຽວກັນໃນເຄື່ອງແມ່ຂ່າຍທີສາມທີ່ຍັງເຫຼືອ.

ດັ່ງນັ້ນ, ມັນ turns ໃຫ້ເຫັນວ່າເຄື່ອງແມ່ຂ່າຍທໍາອິດຂອງພວກເຮົາແມ່ນແມ່ບົດ, ສ່ວນທີ່ເຫຼືອແມ່ນ Slaves.

ບໍລິການຜູ້ເບິ່ງແຍງເວັບ

ເປີດໃຊ້ການບໍລິການຜູ້ເບິ່ງແຍງເວັບ:

webadmin listen a 445

ພອດ 445 ຖືກເລືອກເພາະວ່າພອດ 443 ຖືກໃຊ້ເພື່ອເຂົ້າເຖິງລູກຄ້າເວັບ

ພວກເຮົາກຳນົດຄ່າບໍລິການ Web Admin ດ້ວຍໄຟລ໌ໃບຢັ້ງຢືນດ້ວຍຄຳສັ່ງເຊັ່ນ:

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

ແລະເປີດໃຊ້ Web Admin ດ້ວຍຄໍາສັ່ງ:

webadmin enable

ຖ້າທັງຫມົດແມ່ນດີ, ພວກເຮົາຈະໄດ້ຮັບເສັ້ນ SUCCESS ທີ່ຊີ້ບອກວ່າ Web Admin ຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງສໍາລັບເຄືອຂ່າຍແລະໃບຢັ້ງຢືນ. ພວກເຮົາກວດເບິ່ງການເຮັດວຽກຂອງການບໍລິການໂດຍໃຊ້ຕົວທ່ອງເວັບແລະໃສ່ທີ່ຢູ່ຂອງຜູ້ເບິ່ງແຍງເວັບ, ຕົວຢ່າງ: cms.example.com: 445

ໂທຫາ Bridge Cluster

Call Bridge ເປັນບໍລິການດຽວທີ່ມີຢູ່ໃນທຸກໆການນຳໃຊ້ CMS. ຂົວໂທຫາແມ່ນກົນໄກການປະຊຸມຕົ້ນຕໍ. ມັນຍັງສະຫນອງການໂຕ້ຕອບ SIP ເພື່ອໃຫ້ການໂທສາມາດຖືກສົ່ງໄປຫາຫຼືຈາກມັນໂດຍ, ສໍາລັບການຍົກຕົວຢ່າງ, Cisco Unified CM.

ຄໍາສັ່ງທີ່ອະທິບາຍຂ້າງລຸ່ມນີ້ຕ້ອງໄດ້ຮັບການປະຕິບັດໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍທີ່ມີໃບຢັ້ງຢືນທີ່ເຫມາະສົມ.
ດັ່ງນັ້ນ:

ພວກເຮົາເຊື່ອມໂຍງໃບຢັ້ງຢືນກັບການບໍລິການ Call Bridge ດ້ວຍຄໍາສັ່ງເຊັ່ນ:

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

ພວກເຮົາຜູກມັດການບໍລິການ CallBridge ກັບການໂຕ້ຕອບທີ່ພວກເຮົາຕ້ອງການດ້ວຍຄໍາສັ່ງ:

callbridge listen a

ແລະເປີດບໍລິການຄືນໃໝ່ດ້ວຍຄຳສັ່ງ:

callbridge restart

ຕອນນີ້ພວກເຮົາມີການຕັ້ງຄ່າ Call Bridges ຂອງພວກເຮົາແລ້ວ, ພວກເຮົາສາມາດກຳນົດຄ່າ Call Bridge clustering ໄດ້. Call Bridge clustering ແຕກຕ່າງຈາກຖານຂໍ້ມູນ ຫຼື XMPP clustering. Call Bridge Cluster ສາມາດສະຫນັບສະຫນູນຈາກ 2 ຫາ 8 nodes ໂດຍບໍ່ມີຂໍ້ຈໍາກັດໃດໆ. ມັນບໍ່ພຽງແຕ່ສະຫນອງການຊ້ໍາຊ້ອນ, ແຕ່ຍັງມີການດຸ່ນດ່ຽງການໂຫຼດເພື່ອໃຫ້ກອງປະຊຸມສາມາດແຈກຢາຍຢ່າງຫ້າວຫັນໃນທົ່ວເຄື່ອງແມ່ຂ່າຍຂອງ Call Bridge ໂດຍໃຊ້ການແຈກຢາຍການໂທອັດສະລິຍະ. CMS ມີລັກສະນະເພີ່ມເຕີມ, ກຸ່ມ Call Bridge ແລະລັກສະນະທີ່ກ່ຽວຂ້ອງທີ່ສາມາດນໍາໃຊ້ໃນການຄຸ້ມຄອງຕື່ມອີກ.

ການສ້າງກຸ່ມຂົວການໂທແມ່ນຖືກຕັ້ງຄ່າຕົ້ນຕໍຜ່ານສ່ວນຕິດຕໍ່ຜູ້ເບິ່ງແຍງເວັບ
ຂັ້ນຕອນທີ່ອະທິບາຍຂ້າງລຸ່ມນີ້ຈະຕ້ອງຖືກປະຕິບັດໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍໃນກຸ່ມ.
ດັ່ງ​ນັ້ນ

1. ໄປຜ່ານເວັບໄປທີ່ການຕັ້ງຄ່າ > Cluster.
2. ໃນ ໂທຫາຕົວຕົນຂອງຂົວ ເປັນຊື່ທີ່ເປັນເອກະລັກ, ໃສ່ callbridge[01,02,03] ທີ່ສອດຄ້ອງກັບຊື່ເຊີບເວີ. ຊື່ເຫຼົ່ານີ້ແມ່ນເປັນຕົວຕົນ, ແຕ່ຕ້ອງເປັນເອກະລັກສະເພາະສໍາລັບກຸ່ມນີ້. ພວກມັນຖືກອະທິບາຍໃນລັກສະນະເພາະວ່າພວກເຂົາຊີ້ບອກວ່າພວກເຂົາເປັນຕົວລະບຸເຄື່ອງແມ່ຂ່າຍ [01,02,03].
3. ບ ຂົວການໂທເປັນກຸ່ມ ໃສ່ URL ຂອງຜູ້ເບິ່ງແຍງເວັບຂອງເຊີບເວີຂອງພວກເຮົາໃນກຸ່ມ, cms[01,02,03].example.com:445, ໃນຊ່ອງທີ່ຢູ່. ໃຫ້ແນ່ໃຈວ່າລະບຸພອດ. ທ່ານສາມາດປ່ອຍໃຫ້ Peer link SIP ໂດເມນຫວ່າງເປົ່າ.
4. ເພີ່ມໃບຢັ້ງຢືນໃຫ້ກັບ CallBridge ຄວາມໄວ້ວາງໃຈຂອງແຕ່ລະເຊີບເວີ, ໄຟລ໌ທີ່ມີໃບຢັ້ງຢືນທັງຫມົດຂອງເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ, ເຊິ່ງພວກເຮົາລວມເຂົ້າໄປໃນໄຟລ໌ນີ້ໃນຕອນເລີ່ມຕົ້ນ, ດ້ວຍຄໍາສັ່ງເຊັ່ນ:

callbridge trust cluster <trusted cluster certificate bundle>

ແລະເປີດບໍລິການຄືນໃໝ່ດ້ວຍຄຳສັ່ງ:

callbridge restart

ດັ່ງນັ້ນ, ໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍທ່ານຄວນໄດ້ຮັບຮູບພາບນີ້:

XMPP Cluster

ບໍລິການ XMPP ໃນ CMS ແມ່ນໃຊ້ເພື່ອຈັດການການລົງທະບຽນ ແລະການກວດສອບຄວາມຖືກຕ້ອງທັງໝົດສໍາລັບ Cisco Meeting Apps (CMA), ລວມທັງລູກຄ້າເວັບ CMA WebRTC. ຂົວ Call ຕົວມັນເອງຍັງເຮັດຫນ້າທີ່ເປັນລູກຄ້າ 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 ຂອງພວກເຮົາທີ່ຜູ້ໃຊ້ Jabber ຈະໃຊ້ໃນ Unified CM ເປັນ example.com, ດັ່ງນັ້ນພວກເຮົາຕ້ອງການໂດເມນທີ່ແຕກຕ່າງກັນສໍາລັບຜູ້ໃຊ້ CMS ເພື່ອສົ່ງເສັ້ນທາງການໂທໄປຫາແລະຈາກ CMS ຜ່ານໂດເມນ SIP.

ຕັ້ງຄ່າໂດເມນ XMPP ໂດຍໃຊ້ຄໍາສັ່ງເຊັ່ນ:

xmpp domain <domain>

ແລະເປີດໃຊ້ບໍລິການ XMPP ດ້ວຍຄໍາສັ່ງ:

xmpp enable

ໃນການບໍລິການ XMPP, ທ່ານຕ້ອງສ້າງຂໍ້ມູນປະຈໍາຕົວສໍາລັບແຕ່ລະ Call Bridge ທີ່ຈະຖືກນໍາໃຊ້ໃນເວລາລົງທະບຽນກັບບໍລິການ XMPP. ຊື່ເຫຼົ່ານີ້ແມ່ນເປັນຕົວຕົນ (ແລະບໍ່ກ່ຽວຂ້ອງກັບຊື່ທີ່ເປັນເອກະລັກທີ່ທ່ານກໍາຫນົດຄ່າສໍາລັບການເອີ້ນຂົວ clustering). ທ່ານຕ້ອງເພີ່ມຂົວການໂທສາມອັນຢູ່ໃນເຊີບເວີ XMPP ໜ່ວຍໜຶ່ງແລະຫຼັງຈາກນັ້ນໃສ່ຂໍ້ມູນປະຈຳຕົວເຫຼົ່ານັ້ນຢູ່ໃນເຊີບເວີ XMPP ອື່ນໆໃນກຸ່ມ ເພາະວ່າການຕັ້ງຄ່ານີ້ບໍ່ເໝາະສົມກັບຖານຂໍ້ມູນຂອງກຸ່ມ. ຕໍ່ມາພວກເຮົາຈະປັບຄ່າແຕ່ລະ Call Bridge ເພື່ອໃຊ້ຊື່ນີ້ ແລະຄວາມລັບເພື່ອລົງທະບຽນກັບບໍລິການ XMPP.

ໃນປັດຈຸບັນພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ກໍາຫນົດຄ່າບໍລິການ XMPP ໃນເຄື່ອງແມ່ຂ່າຍທໍາອິດທີ່ມີສາມ Call Bridges callbridge01, callbridge02 ແລະ callbridge03. ແຕ່ລະບັນຊີຈະຖືກມອບຫມາຍລະຫັດຜ່ານແບບສຸ່ມ. ຕໍ່ມາພວກມັນຈະຖືກໃສ່ໃນເຊີບເວີ Call Bridge ອື່ນໆເພື່ອເຂົ້າສູ່ລະບົບເຊີບເວີ 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 cluster mode ໃນທຸກ server cluster ດ້ວຍຄໍາສັ່ງ:

xmpp cluster enable

ໃນເຊີບເວີທໍາອິດຂອງກຸ່ມ, ພວກເຮົາເລີ່ມຕົ້ນການສ້າງກຸ່ມ xmpp ດ້ວຍຄໍາສັ່ງ:

xmpp cluster initialize

ໃນເຊີບເວີອື່ນ, ເພີ່ມກຸ່ມໃສ່ xmpp ດ້ວຍຄໍາສັ່ງເຊັ່ນ:

xmpp cluster join <ip address head xmpp server>

ພວກເຮົາກວດເບິ່ງແຕ່ລະເຄື່ອງແມ່ຂ່າຍຂອງຜົນສໍາເລັດຂອງການສ້າງກຸ່ມ XMPP ໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍດ້ວຍຄໍາສັ່ງ:

xmpp status
xmpp cluster status

ເຊີບເວີທໍາອິດ:

ເຊີບເວີທີສອງ:

ເຊີບເວີທີສາມ:

ການເຊື່ອມຕໍ່ Call Bridge ກັບ XMPP

ຕອນນີ້ກຸ່ມ XMPP ກໍາລັງເຮັດວຽກຢູ່, ທ່ານຈໍາເປັນຕ້ອງຕັ້ງຄ່າບໍລິການ Call Bridge ເພື່ອເຊື່ອມຕໍ່ກັບກຸ່ມ XMPP. ການຕັ້ງຄ່ານີ້ແມ່ນເຮັດຜ່ານຜູ້ເບິ່ງແຍງເວັບ.

ຢູ່ໃນແຕ່ລະເຊີບເວີ, ໄປທີ່ການຕັ້ງຄ່າ > ທົ່ວໄປ ແລະໃນພາກສະຫນາມ ເປັນເອກະລັກ Call Bridge ຊື່ ຂຽນຊື່ Call Bridge ທີ່ເປັນເອກະລັກທີ່ສອດຄ້ອງກັບເຄື່ອງແມ່ຂ່າຍ callbridge[01,02,03]. лоле ໂດເມນ conf.example.ru ແລະລະຫັດຜ່ານທີ່ສອດຄ້ອງກັນ, ທ່ານສາມາດ spy ກ່ຽວກັບພວກເຂົາ
ໃນເຊີບເວີໃດນຶ່ງໃນກຸ່ມດ້ວຍຄຳສັ່ງ:

xmpp callbridge list

ປ່ອຍໃຫ້ຊ່ອງໃສ່ "ເຊີບເວີ" ຫວ່າງເປົ່າ Callbridge ຈະດໍາເນີນການຊອກຫາ DNS SRV ສໍາລັບ _xmpp-component._tcp.conf.example.comເພື່ອຊອກຫາເຄື່ອງແມ່ຂ່າຍ XMPP ທີ່ມີຢູ່. ທີ່ຢູ່ IP ສໍາລັບການເຊື່ອມຕໍ່ callbridges ກັບ XMPP ອາດຈະແຕກຕ່າງກັນໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍ, ມັນຂຶ້ນກັບວ່າຄ່າໃດຖືກສົ່ງກັບຄໍາຮ້ອງຂໍການບັນທຶກ. _xmpp-component._tcp.conf.example.com callbridge, ເຊິ່ງແມ່ນຂຶ້ນກັບການຕັ້ງຄ່າບູລິມະສິດສໍາລັບບັນທຶກ DNS ທີ່ໃຫ້.

ຕໍ່ໄປ, ໃຫ້ໄປທີ່ສະຖານະ > ທົ່ວໄປເພື່ອກວດສອບວ່າການບໍລິການ Call Bride ໄດ້ຖືກເຊື່ອມຕໍ່ກັບບໍລິການ XMPP ສຳເລັດຫຼືບໍ່.

ຂົວເວັບ

ໃນແຕ່ລະເຊີບເວີໃນກຸ່ມ, ເປີດໃຊ້ບໍລິການ Web Bridge ດ້ວຍຄຳສັ່ງ:

webbridge listen a:443

ພວກເຮົາກຳນົດຄ່າບໍລິການ Web Bridge ດ້ວຍໄຟລ໌ໃບຢັ້ງຢືນດ້ວຍຄຳສັ່ງເຊັ່ນ:

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

Web Bridge ຮອງຮັບ HTTPS. ມັນຈະປ່ຽນເສັ້ນທາງ HTTP ໄປ HTTPS ຖ້າຖືກຕັ້ງຄ່າໃຫ້ໃຊ້ "http-redirect".
ເພື່ອເປີດໃຊ້ການປ່ຽນເສັ້ນທາງ HTTP, ໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້:

webbridge http-redirect enable

ເພື່ອໃຫ້ Call Bridge ຮູ້ວ່າ Web Bridge ສາມາດໄວ້ວາງໃຈການເຊື່ອມຕໍ່ຈາກ Call Bridge, ໃຊ້ຄໍາສັ່ງ:

webbridge trust <certfile>

ບ່ອນທີ່ນີ້ແມ່ນໄຟລ໌ທີ່ມີໃບຢັ້ງຢືນທັງສາມຈາກແຕ່ລະເຄື່ອງແມ່ຂ່າຍໃນກຸ່ມ.

ຮູບນີ້ຄວນຈະຢູ່ໃນທຸກເຊີບເວີໃນກຸ່ມ.


ດຽວນີ້ພວກເຮົາຕ້ອງການສ້າງຜູ້ໃຊ້ທີ່ມີບົດບາດ "appadmin", ພວກເຮົາຕ້ອງການມັນເພື່ອໃຫ້ພວກເຮົາສາມາດຕັ້ງຄ່າ cluster ຂອງພວກເຮົາ (!), ແລະບໍ່ແມ່ນແຕ່ລະເຄື່ອງແມ່ຂ່າຍໃນ cluster ແຍກຕ່າງຫາກ, ວິທີການນີ້ການຕັ້ງຄ່າຈະຖືກນໍາໃຊ້ເທົ່າທຽມກັນກັບແຕ່ລະເຄື່ອງແມ່ຂ່າຍເຖິງວ່າຈະມີ. ຄວາມຈິງທີ່ວ່າພວກເຂົາຈະເຮັດຄັ້ງດຽວ.


ສໍາລັບການຕິດຕັ້ງຕໍ່ໄປພວກເຮົາຈະໃຊ້ ນັກໄປສະນີ.

ສໍາລັບການອະນຸຍາດ, ເລືອກພື້ນຖານໃນພາກສ່ວນການອະນຸຍາດ

ເພື່ອສົ່ງຄໍາສັ່ງຢ່າງຖືກຕ້ອງໄປຫາເຄື່ອງແມ່ຂ່າຍ CMS, ທ່ານຈໍາເປັນຕ້ອງກໍານົດການເຂົ້າລະຫັດທີ່ຈໍາເປັນ

ພວກເຮົາກໍານົດ Webbridge ດ້ວຍຄໍາສັ່ງ POST ກັບພາລາມິເຕີ url ແລະຄວາມຫມາຍ cms.example.com



ໃນ webbridge ຕົວຂອງມັນເອງ, ພວກເຮົາຊີ້ບອກຕົວກໍານົດການທີ່ຕ້ອງການ: ການເຂົ້າເຖິງແຂກ, ການເຂົ້າເຖິງທີ່ຖືກປົກປ້ອງ, ແລະອື່ນໆ.

ໂທຫາກຸ່ມຂົວ

ໂດຍຄ່າເລີ່ມຕົ້ນ, CMS ບໍ່ໄດ້ໃຊ້ຊັບພະຍາກອນການປະຊຸມທີ່ມີປະສິດຕິພາບສູງສຸດສະເໝີໄປ.

ຕົວຢ່າງ, ສໍາລັບກອງປະຊຸມທີ່ມີສາມຜູ້ເຂົ້າຮ່ວມ, ຜູ້ເຂົ້າຮ່ວມແຕ່ລະຄົນອາດຈະສິ້ນສຸດໃນສາມ Call Bridges ທີ່ແຕກຕ່າງກັນ. ເພື່ອໃຫ້ຜູ້ເຂົ້າຮ່ວມສາມຄົນນີ້ຕິດຕໍ່ສື່ສານກັບກັນແລະກັນ, Call Bridges ຈະສ້າງການເຊື່ອມຕໍ່ລະຫວ່າງເຄື່ອງແມ່ຂ່າຍແລະລູກຄ້າທັງຫມົດໃນ Space ດຽວກັນໂດຍອັດຕະໂນມັດ, ເພື່ອໃຫ້ມັນເບິ່ງຄືວ່າລູກຄ້າທັງຫມົດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍດຽວກັນ. ແຕ່ຫນ້າເສຍດາຍ, ການຫຼຸດລົງຂອງນີ້ແມ່ນວ່າກອງປະຊຸມ 3 ຄົນດຽວໃນປັດຈຸບັນຈະບໍລິໂພກ 9 ພອດສື່. ນີ້​ແມ່ນ​ແນ່​ນອນ​ວ່າ​ເປັນ​ການ​ນໍາ​ໃຊ້​ຊັບ​ພະ​ຍາ​ກອນ​ທີ່​ບໍ່​ມີ​ປະ​ສິດ​ທິ​ພາບ​. ນອກຈາກນັ້ນ, ເມື່ອ Call Bridge ແມ່ນ overloaded ຢ່າງແທ້ຈິງ, ກົນໄກເລີ່ມຕົ້ນແມ່ນການສືບຕໍ່ຮັບສາຍແລະໃຫ້ບໍລິການທີ່ມີຄຸນນະພາບຫຼຸດລົງໃຫ້ກັບຜູ້ຈອງທັງຫມົດຂອງ Call Bridge.

ບັນຫາເຫຼົ່ານີ້ແມ່ນໄດ້ຮັບການແກ້ໄຂໂດຍໃຊ້ຄຸນສົມບັດ Call Bridge Group. ຄຸນນະສົມບັດນີ້ໄດ້ຖືກນໍາສະເຫນີໃນສະບັບ 2.1 ຂອງຊອບແວ Cisco Meeting Server ແລະໄດ້ຂະຫຍາຍອອກໄປເພື່ອສະຫນັບສະຫນູນການດຸ່ນດ່ຽງການໂຫຼດສໍາລັບການໂທທັງ inbound ແລະ outbound Cisco Meeting App (CMA), ລວມທັງຜູ້ເຂົ້າຮ່ວມ WebRTC.

ເພື່ອແກ້ໄຂບັນຫາການເຊື່ອມຕໍ່ຄືນ, ສາມຂໍ້ຈໍາກັດການໂຫຼດທີ່ສາມາດກໍານົດໄດ້ໄດ້ຖືກນໍາສະເຫນີສໍາລັບແຕ່ລະ Call Bridge:

ໂຫຼດຈຳກັດ — ນີ້ແມ່ນການໂຫຼດຕົວເລກສູງສຸດສຳລັບ Call Bridge ໂດຍສະເພາະ. ແຕ່ລະແພລະຕະຟອມມີຂອບເຂດຈໍາກັດການໂຫຼດທີ່ແນະນໍາ, ເຊັ່ນ: 96000 ສໍາລັບ CMS1000 ແລະ 1.25 GHz ຕໍ່ vCPU ສໍາລັບເຄື່ອງ virtual. ການໂທທີ່ແຕກຕ່າງກັນບໍລິໂພກຈໍານວນທີ່ແນ່ນອນຂອງຊັບພະຍາກອນໂດຍອີງຕາມການແກ້ໄຂແລະອັດຕາເຟຣມຂອງຜູ້ເຂົ້າຮ່ວມ.
NewConferenceLoadLimitBasisPoints (default 50% loadLimit) - ກໍານົດຂອບເຂດການໂຫຼດຂອງເຄື່ອງແມ່ຂ່າຍ, ຫຼັງຈາກນັ້ນກອງປະຊຸມໃຫມ່ຖືກປະຕິເສດ.
ConferenceLoadLimitBasisPoints ທີ່ມີຢູ່ແລ້ວ (ຄ່າເລີ່ມຕົ້ນ 80% ຂອງ loadLimit) - ມູນຄ່າການໂຫຼດຂອງເຄື່ອງແມ່ຂ່າຍຫຼັງຈາກນັ້ນຜູ້ເຂົ້າຮ່ວມທີ່ເຂົ້າຮ່ວມກອງປະຊຸມທີ່ມີຢູ່ແລ້ວຈະຖືກປະຕິເສດ.

ໃນຂະນະທີ່ຄຸນສົມບັດນີ້ຖືກອອກແບບມາສໍາລັບການແຈກຢາຍການໂທແລະການດຸ່ນດ່ຽງການໂຫຼດ, ກຸ່ມອື່ນໆເຊັ່ນ: ເຊີບເວີ TURN, ເຊີບເວີຂົວເວັບແລະຕົວບັນທຶກຍັງສາມາດຖືກມອບຫມາຍໃຫ້ກຸ່ມ Call Bridge ເພື່ອໃຫ້ພວກເຂົາຖືກຈັດກຸ່ມຢ່າງຖືກຕ້ອງສໍາລັບການນໍາໃຊ້ທີ່ດີທີ່ສຸດ. ຖ້າວັດຖຸເຫຼົ່ານີ້ບໍ່ໄດ້ຖືກມອບຫມາຍໃຫ້ກຸ່ມການໂທ, ຄາດວ່າພວກມັນມີຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທັງຫມົດໂດຍບໍ່ມີຄວາມສໍາຄັນໂດຍສະເພາະ.

ຕົວກໍານົດການເຫຼົ່ານີ້ຖືກຕັ້ງຄ່າຢູ່ທີ່ນີ້: cms.example.com:445/api/v1/system/configuration/cluster

ຕໍ່ໄປ, ພວກເຮົາຊີ້ບອກແຕ່ລະ callbridge ທີ່ກຸ່ມ callbridge ມັນເປັນຂອງ:

ຂົວໂທທໍາອິດ

ຂົວສາຍທີສອງ

ຂົວສາຍທີສາມ


ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ກຳນົດຄ່າກຸ່ມ Call Brdige ເພື່ອນຳໃຊ້ຊັບພະຍາກອນຂອງກຸ່ມເຊີບເວີ Cisco Meeting ຢ່າງມີປະສິດທິພາບຫຼາຍຂຶ້ນ.

ການນໍາເຂົ້າຜູ້ໃຊ້ຈາກ Active Directory

ການບໍລິການຜູ້ເບິ່ງແຍງເວັບມີພາກສ່ວນການຕັ້ງຄ່າ LDAP, ແຕ່ມັນບໍ່ໄດ້ສະຫນອງທາງເລືອກໃນການຕັ້ງຄ່າທີ່ຊັບຊ້ອນ, ແລະຂໍ້ມູນບໍ່ໄດ້ຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນຂອງກຸ່ມ, ດັ່ງນັ້ນການຕັ້ງຄ່າຈະຕ້ອງເຮັດ, ດ້ວຍຕົນເອງໃນແຕ່ລະເຄື່ອງແມ່ຂ່າຍຜ່ານທາງຕິດຕໍ່ເວັບ, ຫຼືຜ່ານ. API, ແລະດັ່ງນັ້ນພວກເຮົາ "ສາມເທື່ອ "ບໍ່ລຸກຂຶ້ນ" ພວກເຮົາຍັງຈະກໍານົດຂໍ້ມູນຜ່ານ API.

ການນໍາໃຊ້ URL ເພື່ອເຂົ້າເຖິງ cms01.example.com:445/api/v1/ldapServers ສ້າງວັດຖຸເຊີບເວີ LDAP, ລະບຸພາລາມິເຕີເຊັ່ນ:

• IP ຂອງເຊີບເວີ
• ໝາຍເລກຜອດ
• ຊື່ຜູ້ໃຊ້
• ລະຫັດຜ່ານ
• ຮັບປະກັນ

Secure - ເລືອກ true ຫຼື false ຂຶ້ນກັບພອດ, 389 - ບໍ່ປອດໄພ, 636 - ປ້ອງກັນ.


ການສ້າງແຜນທີ່ແຫຼ່ງທີ່ມາຂອງ LDAP ກັບຄຸນລັກສະນະຕ່າງໆໃນ Cisco Meeting Server.
ແຜນທີ່ LDAP ເຮັດແຜນທີ່ຄຸນສົມບັດໃນໄດເລກະທໍລີ LDAP ກັບຄຸນລັກສະນະໃນ CMS. ຄຸນ​ລັກ​ສະ​ນະ​ທີ່​ແທ້​ຈິງ​:

• jidMapping
• ການສ້າງແຜນທີ່ຊື່
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

ລາຍລະອຽດຂອງຄຸນລັກສະນະIADB ເປັນຕົວແທນຂອງ ID ເຂົ້າສູ່ລະບົບຂອງຜູ້ໃຊ້ໃນ CMS. ເນື່ອງຈາກນີ້ແມ່ນເຊີບເວີ Microsoft Active Directory LDAP, CMS JID ແຜນທີ່ກັບ sAMAccountName ໃນ LDAP, ເຊິ່ງເປັນສິ່ງຈໍາເປັນ ID ເຂົ້າສູ່ລະບົບ Active Directory ຂອງຜູ້ໃຊ້. ໃຫ້ສັງເກດວ່າທ່ານເອົາ sAMAccountName ແລະເພີ່ມໂດເມນ conf.pod6.cms.lab ໃສ່ທ້າຍຂອງມັນເພາະວ່ານີ້ແມ່ນການເຂົ້າສູ່ລະບົບທີ່ຜູ້ໃຊ້ຂອງທ່ານຈະໃຊ້ເພື່ອເຂົ້າສູ່ລະບົບ CMS.

ການສ້າງແຜນທີ່ຊື່ ກົງກັບສິ່ງທີ່ຢູ່ໃນຊ່ອງ Active Directory displayName ກັບຊ່ອງໃສ່ຊື່ CMS ຂອງຜູ້ໃຊ້.

coSpaceNameMapping ສ້າງຊື່ຊ່ອງ CMS ໂດຍອີງໃສ່ຊ່ອງສະແດງຊື່. ຄຸນລັກສະນະນີ້, ພ້ອມກັບຄຸນລັກສະນະ coSpaceUriMapping, ແມ່ນສິ່ງທີ່ຕ້ອງການເພື່ອສ້າງພື້ນທີ່ສໍາລັບຜູ້ໃຊ້ແຕ່ລະຄົນ.

coSpaceUriMapping ກໍານົດສ່ວນຂອງຜູ້ໃຊ້ຂອງ URI ທີ່ກ່ຽວຂ້ອງກັບພື້ນທີ່ສ່ວນຕົວຂອງຜູ້ໃຊ້. ບາງໂດເມນສາມາດຖືກຕັ້ງຄ່າໃຫ້ໂທຫາຊ່ອງຫວ່າງໄດ້. ຖ້າພາກສ່ວນຂອງຜູ້ໃຊ້ກົງກັບຊ່ອງຂໍ້ມູນນີ້ສໍາລັບຫນຶ່ງໃນໂດເມນເຫຼົ່ານີ້, ການໂທຈະຖືກນໍາໄປຫາພື້ນທີ່ຂອງຜູ້ໃຊ້ນັ້ນ.

coSpaceSecondaryUriMapping ກໍານົດ URI ທີສອງເພື່ອໄປເຖິງອາວະກາດ. ນີ້ສາມາດຖືກນໍາໃຊ້ເພື່ອເພີ່ມນາມແຝງຕົວເລກເພື່ອກໍານົດເສັ້ນທາງການໂທໄປຫາພື້ນທີ່ຂອງຜູ້ໃຊ້ທີ່ນໍາເຂົ້າເປັນທາງເລືອກກັບ URI ຕົວເລກແລະຕົວເລກທີ່ກໍານົດໄວ້ໃນພາລາມິເຕີ coSpaceUriMapping.

ເຊີບເວີ LDAP ແລະການສ້າງແຜນທີ່ LDAP ຖືກຕັ້ງຄ່າ. ຕອນນີ້ທ່ານຈໍາເປັນຕ້ອງເຊື່ອມໂຍງພວກມັນເຂົ້າກັນໂດຍການສ້າງແຫຼ່ງ LDAP.

ການນໍາໃຊ້ URL ເພື່ອເຂົ້າເຖິງ cms01.example.com:445/api/v1/ldapSource ສ້າງວັດຖຸ LDAP Source, ລະບຸພາລາມິເຕີເຊັ່ນ:

• ເຄື່ອງແມ່ຂ່າຍ
• ແຜນທີ່
• ພື້ນຖານDn
• ການກັ່ນຕອງ

ໃນປັດຈຸບັນທີ່ການຕັ້ງຄ່າ LDAP ສໍາເລັດແລ້ວ, ທ່ານສາມາດດໍາເນີນການ synchronization ຄູ່ມື.

ພວກເຮົາເຮັດອັນນີ້ຢູ່ໃນສ່ວນຕິດຕໍ່ເວັບຂອງແຕ່ລະເຊີບເວີໂດຍການຄລິກ ຊິ້ງຂໍ້ມູນດຽວນີ້ ໃນບົດ Active Directory


ຫຼືຜ່ານ API ດ້ວຍຄໍາສັ່ງ POST ໃຊ້ URL ເພື່ອເຂົ້າເຖິງ cms01.example.com:445/api/v1/ldapSyncs

ກອງ​ປະ​ຊຸມ Ad-Hoc

ນີ້ແມ່ນຫຍັງ?ໃນແນວຄວາມຄິດພື້ນເມືອງ, ກອງປະຊຸມແມ່ນເວລາທີ່ຜູ້ເຂົ້າຮ່ວມສອງຄົນກໍາລັງລົມກັນ, ແລະຫນຶ່ງໃນຜູ້ເຂົ້າຮ່ວມ (ໃຊ້ອຸປະກອນທີ່ລົງທະບຽນກັບ Unified CM) ກົດປຸ່ມ "ກອງປະຊຸມ", ໂທຫາຄົນອື່ນ, ແລະຫຼັງຈາກເວົ້າກັບພາກສ່ວນທີສາມນັ້ນ. ກົດປຸ່ມ "ກອງປະຊຸມ" ອີກເທື່ອຫນຶ່ງເພື່ອເຂົ້າຮ່ວມຜູ້ເຂົ້າຮ່ວມທັງຫມົດໃນກອງປະຊຸມສາມຝ່າຍ.

ສິ່ງທີ່ແຕກຕ່າງຈາກກອງປະຊຸມ Ad-Hoc ຈາກກອງປະຊຸມທີ່ກໍານົດໄວ້ໃນ CMS ແມ່ນວ່າກອງປະຊຸມ Ad-Hoc ບໍ່ແມ່ນພຽງແຕ່ການໂທຫາ SIP ກັບ CMS. ເມື່ອຜູ້ລິເລີ່ມກອງປະຊຸມກົດປຸ່ມປະຊຸມເປັນຄັ້ງທີສອງເພື່ອເຊີນທຸກຄົນເຂົ້າຮ່ວມກອງປະຊຸມດຽວກັນ, Unified CM ຕ້ອງໄດ້ໂທຫາ API ໄປຫາ CMS ເພື່ອສ້າງກອງປະຊຸມໃນການບິນເຊິ່ງການໂທທັງຫມົດຈະຖືກໂອນ. ທັງຫມົດນີ້ເກີດຂື້ນໂດຍຜູ້ເຂົ້າຮ່ວມໂດຍບໍ່ໄດ້ສັງເກດເຫັນ.

ນີ້ຫມາຍຄວາມວ່າ Unified CM ຕ້ອງກໍາຫນົດຄ່າຂໍ້ມູນປະຈໍາຕົວ API ແລະທີ່ຢູ່ WebAdmin / ພອດຂອງການບໍລິການເຊັ່ນດຽວກັນກັບ SIP Trunk ໂດຍກົງກັບເຄື່ອງແມ່ຂ່າຍ CMS ເພື່ອສືບຕໍ່ການໂທ.

ຖ້າຈໍາເປັນ, CUCM ສາມາດສ້າງຊ່ອງຫວ່າງໃນ CMS ແບບເຄື່ອນໄຫວເພື່ອໃຫ້ແຕ່ລະການໂທສາມາດບັນລຸ CMS ແລະກົງກັບກົດລະບຽບການໂທເຂົ້າມາທີ່ມີຈຸດປະສົງສໍາລັບຊ່ອງຫວ່າງ.

ການປະສົມປະສານກັບ CUCM ຕັ້ງຄ່າໃນແບບດຽວກັນກັບທີ່ໄດ້ອະທິບາຍໄວ້ໃນບົດຄວາມ ກ່ອນຫນ້ານີ້ ຍົກເວັ້ນວ່າໃນ Cisco UCM ທ່ານຈໍາເປັນຕ້ອງສ້າງສາມລໍາສໍາລັບ CMS, ສາມຂົວກອງປະຊຸມ, ໃນ SIP Security Profile ລະບຸສາມຊື່ຫົວຂໍ້, ກຸ່ມເສັ້ນທາງ, ລາຍຊື່ເສັ້ນທາງ, ກຸ່ມຊັບພະຍາກອນສື່ແລະລາຍຊື່ກຸ່ມຊັບພະຍາກອນສື່, ແລະເພີ່ມກົດລະບຽບການກໍານົດເສັ້ນທາງຈໍານວນຫນຶ່ງ. ກັບ Cisco Meeting Server.

ໂປຣໄຟລ໌ຄວາມປອດໄພ SIP:


ລຳຕົ້ນ:


ແຕ່ລະລໍາມີລັກສະນະຄືກັນ:




ຂົວປະຊຸມ


ຂົວ​ກອງ​ປະ​ຊຸມ​ແຕ່​ລະ​ເບິ່ງ​ຄື​ກັນ​:


ກຸ່ມເສັ້ນທາງ


ລາຍຊື່ເສັ້ນທາງ


ກຸ່ມຊັບພະຍາກອນສື່


ລາຍຊື່ກຸ່ມຊັບພະຍາກອນສື່

ກົດລະບຽບການໂທ

ບໍ່ເຫມືອນກັບລະບົບການຄຸ້ມຄອງການໂທທີ່ກ້າວຫນ້າເຊັ່ນ Unified CM ຫຼືທາງດ່ວນ, CMS ພຽງແຕ່ຊອກຫາໂດເມນໃນພາກສະຫນາມ SIP Request-URI ສໍາລັບການໂທໃຫມ່. ດັ່ງນັ້ນຖ້າ SIP ເຊີນແມ່ນສໍາລັບການ sip: [email protected]CMS ພຽງແຕ່ສົນໃຈກ່ຽວກັບ domain.com. CMS ປະຕິບັດຕາມກົດລະບຽບເຫຼົ່ານີ້ເພື່ອກໍານົດບ່ອນທີ່ຈະສົ່ງສາຍໂທ:

1. CMS ທໍາອິດພະຍາຍາມຈັບຄູ່ໂດເມນ SIP ກັບໂດເມນທີ່ກໍານົດໄວ້ໃນກົດລະບຽບການໂທເຂົ້າມາ. ຫຼັງຈາກນັ້ນ, ການໂທເຫຼົ່ານີ້ສາມາດຖືກສົ່ງໄປຫາ (“ເປົ້າໝາຍ”) ສະຖານທີ່ ຫຼືຜູ້ໃຊ້ສະເພາະ, IVRs ພາຍໃນ, ຫຼືຈຸດໝາຍປາຍທາງຂອງ Microsoft Lync/Skype for Business (S4B).
2. ຖ້າບໍ່ມີຄໍາທີ່ກົງກັນໃນກົດລະບຽບການໂທເຂົ້າມາ, CMS ຈະພະຍາຍາມກົງກັບໂດເມນທີ່ກໍານົດໄວ້ໃນຕາຕະລາງການສົ່ງຕໍ່ການໂທ. ຖ້າມີການແຂ່ງຂັນກັນ, ກົດລະບຽບສາມາດປະຕິເສດການໂທຫຼືໂອນສາຍໄດ້ຢ່າງຊັດເຈນ. ໃນເວລານີ້, CMS ອາດຈະຂຽນຄືນໂດເມນ, ເຊິ່ງບາງຄັ້ງກໍ່ເປັນປະໂຫຍດສໍາລັບການໂທຫາໂດເມນ Lync. ນອກນັ້ນທ່ານຍັງສາມາດເລືອກທີ່ຈະຜ່ານການຖິ້ມ, ຊຶ່ງຫມາຍຄວາມວ່າບໍ່ມີພາກສະຫນາມໃດຈະໄດ້ຮັບການດັດແກ້ເພີ່ມເຕີມ, ຫຼືນໍາໃຊ້ແຜນການໂທຫາ CMS ພາຍໃນ. ຖ້າບໍ່ມີກົງກັນໃນກົດລະບຽບການສົ່ງຕໍ່ການໂທ, ຄ່າເລີ່ມຕົ້ນແມ່ນການປະຕິເສດການໂທ. ຈົ່ງຈື່ໄວ້ວ່າຢູ່ໃນ CMS, ເຖິງແມ່ນວ່າການໂທແມ່ນ "ສົ່ງຕໍ່", ສື່ມວນຊົນຍັງຖືກຜູກມັດກັບ CMS, ຊຶ່ງຫມາຍຄວາມວ່າມັນຈະຢູ່ໃນເສັ້ນທາງສັນຍານແລະການຈະລາຈອນສື່.
ຫຼັງຈາກນັ້ນ, ມີພຽງແຕ່ການສົ່ງຕໍ່ການໂທແມ່ນຂຶ້ນກັບກົດລະບຽບການໂທອອກ. ການຕັ້ງຄ່າເຫຼົ່ານີ້ກໍານົດຈຸດຫມາຍປາຍທາງທີ່ການໂທຖືກສົ່ງ, ປະເພດລໍາຕົ້ນ (ບໍ່ວ່າຈະເປັນການໂທ Lync ໃຫມ່ຫຼືການໂທ SIP ມາດຕະຖານ), ແລະການແປງໃດໆທີ່ສາມາດປະຕິບັດໄດ້ຖ້າການໂອນບໍ່ໄດ້ເລືອກໃນກົດລະບຽບການສົ່ງຕໍ່ການໂທ.

ນີ້ແມ່ນບັນທຶກຕົວຈິງຂອງສິ່ງທີ່ເກີດຂຶ້ນໃນລະຫວ່າງການປະຊຸມ Ad-Hoc

ພາບຫນ້າຈໍສະແດງໃຫ້ເຫັນມັນບໍ່ດີ (ຂ້ອຍບໍ່ຮູ້ວິທີເຮັດໃຫ້ມັນດີຂຶ້ນ), ດັ່ງນັ້ນຂ້ອຍຈະຂຽນບັນທຶກເຊັ່ນນີ້:

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

ກອງປະຊຸມ Ad-Hoc ຕົວຂອງມັນເອງ:


ກົດລະບຽບການໂທເຂົ້າ
ການຕັ້ງຄ່າພາລາມິເຕີຂອງສາຍໂທເຂົ້າແມ່ນມີຄວາມຈໍາເປັນເພື່ອໃຫ້ສາມາດຮັບສາຍໃນ CMS ໄດ້. ດັ່ງທີ່ເຈົ້າເຫັນໃນການຕັ້ງຄ່າ LDAP, ຜູ້ໃຊ້ທັງໝົດຖືກນຳເຂົ້າດ້ວຍໂດເມນ conf.pod6.cms.lab. ດັ່ງນັ້ນຢ່າງຫນ້ອຍ, ທ່ານຕ້ອງການໂທຫາໂດເມນນີ້ເພື່ອເປົ້າຫມາຍສະຖານທີ່. ທ່ານຍັງຈະຕ້ອງກໍານົດກົດລະບຽບສໍາລັບທຸກສິ່ງທຸກຢ່າງທີ່ມີຈຸດປະສົງສໍາລັບຊື່ໂດເມນທີ່ມີຄຸນສົມບັດຢ່າງເຕັມທີ່ (ແລະອາດຈະເປັນທີ່ຢູ່ IP) ຂອງແຕ່ລະເຄື່ອງແມ່ຂ່າຍ CMS. ການຄວບຄຸມການໂທພາຍນອກຂອງພວກເຮົາ, Unified CM, ຈະຕັ້ງຄ່າ SIP trunks ອຸທິດຕົນເພື່ອແຕ່ລະເຄື່ອງແມ່ຂ່າຍຂອງ CMS ເປັນສ່ວນບຸກຄົນ. ຂຶ້ນຢູ່ກັບວ່າຈຸດຫມາຍປາຍທາງຂອງ SIP trunks ເຫຼົ່ານີ້ແມ່ນທີ່ຢູ່ IP ຫຼື FQDN ຂອງເຄື່ອງແມ່ຂ່າຍຈະກໍານົດວ່າ CMS ຕ້ອງໄດ້ຮັບການກໍາຫນົດຄ່າເພື່ອຮັບເອົາການໂທໄປຫາທີ່ຢູ່ IP ຂອງມັນຫຼື FQDN.

ໂດເມນທີ່ມີກົດລະບຽບຂາເຂົ້າທີ່ມີບູລິມະສິດສູງສຸດແມ່ນໃຊ້ເປັນໂດເມນສໍາລັບພື້ນທີ່ຜູ້ໃຊ້ໃດໆ. ເມື່ອຜູ້ໃຊ້ sync ຜ່ານ LDAP, CMS ຈະສ້າງຊ່ອງຫວ່າງໂດຍອັດຕະໂນມັດ, ແຕ່ວ່າພຽງແຕ່ສ່ວນຂອງຜູ້ໃຊ້ຂອງ URI (coSpaceUriMapping), ຕົວຢ່າງ, user.space. ສ່ວນ ໂດເມນ URI ເຕັມແມ່ນຖືກສ້າງຂຶ້ນໂດຍອີງໃສ່ກົດລະບຽບນີ້. ໃນຄວາມເປັນຈິງ, ຖ້າທ່ານເຂົ້າສູ່ລະບົບ Web Bridge ໃນຈຸດນີ້, ທ່ານຈະເຫັນວ່າ Space URI ບໍ່ມີໂດເມນ. ໂດຍການຕັ້ງກົດລະບຽບນີ້ເປັນບູລິມະສິດສູງສຸດ, ທ່ານກໍາລັງຕັ້ງໂດເມນສໍາລັບພື້ນທີ່ທີ່ສ້າງຂຶ້ນ conf.ຕົວຢ່າງ.com.


ກົດລະບຽບການໂທອອກ

ເພື່ອໃຫ້ຜູ້ໃຊ້ສາມາດໂທອອກໄປຫາກຸ່ມ Unified CM, ທ່ານຕ້ອງກໍານົດກົດລະບຽບການອອກນອກ. ໂດເມນຂອງຈຸດສິ້ນສຸດທີ່ລົງທະບຽນກັບ Unified CM, ເຊັ່ນ Jabber, ແມ່ນ example.com. ການໂທໄປຫາໂດເມນນີ້ຄວນຈະຖືກສົ່ງຕໍ່ເປັນການໂທ SIP ມາດຕະຖານໄປຫາ nodes ການປະມວນຜົນການໂທ Unified CM. ເຊີບເວີຫຼັກແມ່ນ cucm-01.example.com, ແລະອີກອັນໜຶ່ງແມ່ນ cucm-02.example.com.

ກົດລະບຽບທໍາອິດອະທິບາຍເສັ້ນທາງທີ່ງ່າຍດາຍທີ່ສຸດຂອງການໂທລະຫວ່າງເຄື່ອງແມ່ຂ່າຍຂອງກຸ່ມ.

ພາກສະຫນາມ ທ້ອງຖິ່ນຈາກໂດເມນ ຮັບຜິດຊອບຕໍ່ສິ່ງທີ່ຈະສະແດງຢູ່ໃນ SIP-URI ຂອງຜູ້ໂທສໍາລັບບຸກຄົນທີ່ຖືກເອີ້ນຫຼັງຈາກສັນຍາລັກ “@”. ຖ້າພວກເຮົາປ່ອຍໃຫ້ມັນຫວ່າງເປົ່າ, ຫຼັງຈາກນັ້ນຫຼັງຈາກສັນຍາລັກ "@" ຈະມີທີ່ຢູ່ IP ຂອງ CUCM ທີ່ການໂທນີ້ຜ່ານ. ຖ້າພວກເຮົາລະບຸໂດເມນ, ຫຼັງຈາກນັ້ນຫຼັງຈາກສັນຍາລັກ "@" ຕົວຈິງແລ້ວຈະມີໂດເມນ. ນີ້ແມ່ນສິ່ງຈໍາເປັນເພື່ອໃຫ້ສາມາດໂທກັບໄດ້, ຖ້າບໍ່ດັ່ງນັ້ນມັນຈະບໍ່ສາມາດໂທຫາກັບຄືນຜ່ານ SIP-URI name@ip-address.

ໂທຫາເມື່ອລະບຸ ທ້ອງຖິ່ນຈາກໂດເມນ


ໂທຫາເວລາໃດ ບໍ່ແມ່ນ ຊີ້ບອກ ທ້ອງຖິ່ນຈາກໂດເມນ


ໃຫ້ແນ່ໃຈວ່າໄດ້ລະບຸຢ່າງຈະແຈ້ງທີ່ເຂົ້າລະຫັດ ຫຼືບໍ່ໄດ້ເຂົ້າລະຫັດລັບສໍາລັບການໂທອອກ, ເພາະວ່າບໍ່ມີຫຍັງເຮັດວຽກກັບພາລາມິເຕີອັດຕະໂນມັດ.

ການບັນທຶກ

ການປະຊຸມວິດີໂອຖືກບັນທຶກໂດຍເຊີບເວີ Record. ເຄື່ອງບັນທຶກແມ່ນຄືກັນກັບ Cisco Meeting Server. ເຄື່ອງບັນທຶກບໍ່ຈໍາເປັນຕ້ອງມີການຕິດຕັ້ງໃບອະນຸຍາດໃດໆ. ໃບອະນຸຍາດການບັນທຶກແມ່ນຈໍາເປັນສໍາລັບເຄື່ອງແມ່ຂ່າຍທີ່ໃຫ້ບໍລິການ CallBridge, i.e. ໃບອະນຸຍາດການບັນທຶກແມ່ນຈໍາເປັນແລະຕ້ອງຖືກນໍາໃຊ້ກັບອົງປະກອບ CallBridge, ແລະບໍ່ແມ່ນກັບເຄື່ອງແມ່ຂ່າຍທີ່ແລ່ນ Recorder. ຕົວບັນທຶກປະຕິບັດຕົວເປັນລູກຄ້າ Extensible Messaging and Presence Protocol (XMPP), ດັ່ງນັ້ນເຊີບເວີ XMPP ຕ້ອງຖືກເປີດໃຊ້ໃນເຊີບເວີທີ່ໂຮດ CallBridge.

ເນື່ອງຈາກວ່າ ພວກເຮົາມີກຸ່ມແລະໃບອະນຸຍາດຕ້ອງໄດ້ຮັບການ "ຍືດຍາວ" ໃນທົ່ວສາມເຄື່ອງແມ່ຂ່າຍໃນກຸ່ມ. ຫຼັງຈາກນັ້ນ, ພຽງແຕ່ຢູ່ໃນບັນຊີສ່ວນຕົວຂອງທ່ານໃນໃບອະນຸຍາດທີ່ພວກເຮົາເຊື່ອມໂຍງ (ເພີ່ມ) ທີ່ຢູ່ MAC ຂອງ a-interfaces ຂອງເຄື່ອງແມ່ຂ່າຍ CMS ທັງຫມົດລວມຢູ່ໃນກຸ່ມ.

ແລະນີ້ແມ່ນຮູບທີ່ຄວນຈະຢູ່ໃນທຸກເຄື່ອງແມ່ຂ່າຍໃນກຸ່ມ

ໂດຍທົ່ວໄປ, ມີຫຼາຍສະຖານະການສໍາລັບການວາງ Recorder, ແຕ່ພວກເຮົາຈະຕິດກັບນີ້:


ກ່ອນ​ທີ່​ຈະ​ຕັ້ງ​ການ​ບັນ​ທຶກ​, ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ກະ​ກຽມ​ສະ​ຖານ​ທີ່​ທີ່​ຈະ​ບັນ​ທຶກ​ການ​ປະ​ຊຸມ​ວິ​ດີ​ໂອ​. ແທ້ຈິງແລ້ວຢູ່ທີ່ນີ້ ຫນ້າທໍາອິດ, ວິທີການຕັ້ງຄ່າການບັນທຶກທັງຫມົດ. ຂ້ອຍເນັ້ນໃສ່ຈຸດສຳຄັນ ແລະລາຍລະອຽດ:

1. ມັນດີກວ່າທີ່ຈະເລື່ອນໃບຢັ້ງຢືນຈາກເຄື່ອງແມ່ຂ່າຍທໍາອິດໃນກຸ່ມ.
2. ຄວາມຜິດພາດ “Recorder unavailable” ອາດຈະເກີດຂຶ້ນເພາະວ່າໃບຮັບຮອງຜິດຖືກລະບຸໄວ້ໃນ Recorder Trust.
3. ການຂຽນອາດຈະບໍ່ເຮັດວຽກຖ້າໄດເລກະທໍລີ NFS ທີ່ລະບຸໄວ້ສໍາລັບການບັນທຶກບໍ່ແມ່ນໄດເລກະທໍລີຮາກ.

ບາງຄັ້ງມີຄວາມຕ້ອງການທີ່ຈະບັນທຶກອັດຕະໂນມັດກອງປະຊຸມຂອງຜູ້ໃຊ້ຫຼືພື້ນທີ່ສະເພາະ.

ເພື່ອເຮັດສິ່ງນີ້, ສອງ CallProfiles ຖືກສ້າງຂື້ນ:
ດ້ວຍການປິດການບັນທຶກ


ແລະມີຟັງຊັນການບັນທຶກອັດຕະໂນມັດ


ຕໍ່ໄປ, ພວກເຮົາ "ແນບ" CallProfile ທີ່ມີຫນ້າທີ່ບັນທຶກອັດຕະໂນມັດໃສ່ພື້ນທີ່ທີ່ຕ້ອງການ.


ໃນ 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-and-later. pdf

ແຫຼ່ງຂໍ້ມູນ: www.habr.com