본문 바로가기

Collaboration/Cisco Jabber

[대하 연재]Cisco Jabber 11.0 의 이해 - 15. 홈클러스터

글 싣는 순서
1. 멀티도메인 (Multi-Domain) 지원

2. Enterprise Group 

3. 파일전송 (일대일 및 일대다)  

4. 채팅 중 화면 공유 (일대일 및 일대다)

5. FECC & Self View

6. Bridge Escalation (그룹채팅에서 영상회의로 전환)

7. Jabber to Jabber Call (P2P 음성 및 영상 통화)

8. 채팅 히스토리 보관 및 검색

9. Call Features (통화 관련 기능)

10. IM Features (채팅 관련 기능)
11. FMC Features (재버 모바일만의 특화 기능)

12. Persistent Chat Room (채팅방)
13. Advanced Features of Cisco Jabber
14. 가상화 환경에서의 재버 (VXME)
15. 홈 클러스터
16. 
Security Features (인증서 관리 및 암호화)

17. 시스코 재버 자동 업데이트


시작하며
CUCM에서 End User 설정 페이지에서 아무생각없이 "Home Cluster"를 체크하는 엔지니어들이 있습니다. 이 옵션은 단일 클러스터로 구성하는 10,000명 이하의 기업에서는 의미가 없으나 
멀티클러스터 환경에서는 매우 효과적입니다. 

이글에서는 홈클러스터에 대한 자세한 설명과 멀티 클러스터 환경에서의 ILS에 대해 다룹니다. 


사용자에게 홈클러스터를 할당한다는 의미
일반적으로 AD와 CUCM간에 동기화를 진행 시에 모든 사용자의 Home Cluster 체크를 합니다. 


각 옵션의 내용을 자세히 살펴보겠습니다.
  • Home Cluster
    사용자가 현재 CUCM 클러스터에서 서비스 프로파일을 적용받아야 한다면 체킹합니다. 단일 클러스터에서는 반드시 체킹을 하는 것이고, 멀티 클러스터 환경에서는 자신이 속한 클러스터에서 체킹합니다.

  • Enable User for CUCM IM&P
    사용자가 Phone Only Mode로 재버를 사용하지 않는다면 체킹합니다. 

  • UC Service Profile
    서비스 프로파일을 할당합니다. 

멀티클러스터 환경에서 빛을 발하는 홈 클러스터
아래 그림과 같은 멀티 클러스터 환경을 생각해봅시다. 이 회사는 2만명의 직원이 일하고 있으며, 3개의 CUCM 클러스터를 이용합니다. Cisco Jabber for windows는 사용자 검색을 AD 서버로 직접하므로 문제가 없지만, UDS를 이용하는 모바일 기기와 맥북 사용자들은 자신의 클러스터에 없는 사용자를 Contact List 또는 Buddy List에 추가할 수 없습니다.




UDS에서 모든 직원에 대한 검색이 가능하도록 하기 위해서 모든 클러스터는 전직원 2만명의 사용자 정보를 AD와 동기화합니다. 즉, "라인하트"라는 사용자의 정보는 클러스터1, 클러스터2, 클러스터3에 존재합니다. 하지만, "라인하트"의 서비스 프로파일은 실제 서비스를 받는 단 하나의 클러스터에 있어야 합니다. 홈클러스터는 사용자가 직접 서비스를 받는 CUCM 클러스터를 가리킵니다. 

위의 그림에서 서비스 발견 매커니즘 (Service Discovery)을 통해 DNS는 클러스터 1의 SRV 값을 알려줄것이며, 재버는 클러스터 1에 물어봅니다. 클러스터1은 "라인하트"의 홈클러스터가 아니므로 ILS 프로토콜을 통해 다른 클러스터에게 물어봅니다. 클러스터 2 는 재버에게 홈클러스터임을 알려주고, 재버는 클러스터 2에서 서비스를 받습니다. 
 

ILS 개요
ILS는 Intercluster Lookup Service의 약자로 멀티 클러스터 환경에서 URI Dialing을 원활히 하기 위해 만들어 졌습니다. 단일 클러스터 환경에서는 모든 사용자에 대한 URI 정보를 알고 있으며, 클러스터를 벗어나는 외부 발신은 도메인네임으로 충분히 구분이 가능합니다. 

멀티클러스터 환경에서 alice@cisco.com과 bob@cisco.com 사용자가 어느 클러스터에 있는 지를 URI 주소만을 보고 판별할 수가 없습니다. 가장 쉬운 방법은 각 클러스터별로 계층화된 도메인네임 (호스트파트)을 사용하는 것입니다. 예를 들면, alice@cucma.cisco.com 과 bob@cucmb.cisco.com 이라고 사용한다면 각 사용자가 어느 클러스터에서 서비스를 받는 지 알 수 있습니다. 


그러나, URI 주소 체계는 회사 전체가 동일한 호스트파트 (메일주소)를 이용하므로 클러스터별로 사용자를 구분하기 어렵습니다. 시스코가 생각하는 사용자 경험을 고려한 방법은 ILS 프로토콜 이용하여 사용자마다 서비스받는 클러스터의 주소를 명기하는 테이블을 만드는 것입니다. 


CUCM 클러스터는 ILS Exchange 세션을 설립한 후에 사용자의 URI 주소와 SIP Route String을 바인딩하한 테이블을 각각 생성합니다. 클러스터간에는 URI 주소로 호 라우팅을 할 수 없으므로 SIP Route String을 이용합니다. 이제 CUCM은 URI 주소 체계를 이용하여도 사용자별 홈클러스터를 인지할 수 있으며, 인지된 경우 SIP Route String을 이용하여 호를 라우팅합니다. 


ILS가 교환하는 정보를 통해 사용자의 홈클러스터가 어디인지를 아는 것은 식은죽먹기입니다. 



마치며
홈클러스터가 생기면서 CUCM의 UDS를 이용하여 사용자 정보를 검색하더라도 웬만한 서비스가 가능해진 것입니다. 


라인하 유씨누스(UCnus) (CCIEV #18487)  --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일) 
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항) 
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스) 
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스) 
세상을 이롭게 하는 기술을 지향합니다. ________________________________________________________