글 싣는 순서
1. CUCM의 Presence
2. CUP 7.x Core Components
3. CUP 8.x Core Components & Architecture
4. CUPC 개요 및 연동
5. CUPS와 3rd Party 단말 연동
1년 전 나눔 세미나에서 뱉은 말 한마디로 시작된 이 연재는 Cisco Unified Presence에 대한 이해를 돕기 위한 것입니다만, 1장과 2장을 정리한 후에 1년 동안 3장을 쓰지 못했습니다. 왜냐고 물으신 다면, CUP 서버 및 CUPC가 고객들로부터 인기가 없다 보니 의욕이 나질 않아 중도 포기했기 때문입니다. 왜 다시 연재를 이어가냐고 물으신다면, CUP 8.5 및 CUPC 8.5가 출시되어 기능 및 디자인에서 훨씬 좋아졌기 때문입니다. 이제는 Microsoft의 Office Communicator나 Lync 2010과 비교할 수 있을 정도로 발전하였습니다. 제 생각에는 그렇다는 거지요... ^^
지난 글에서 CUP 7.x의 컴포넌트에 대해 살펴보았다면, 이번 시간에는 CUP 8.x 코어 컴포넌트 및 아키택처에 대해 정리하겠습니다.
Cisco Unified Presence Architecture
CUP 8.x 서버는 SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) 과 XMPP (Extensible Messaging and Presence Protocol) 프로토콜을 동시에 지원합니다. 아래 그림에서 보듯이 SIMPLE만을 지원하는 CUP 7.x 서버와 달리 CUP 8.x 서버는 Jabber XCP (Extensible Communications Platform) 컴포넌트가 추가되었습니다. SIP Proxy는 SIMPLE 기반의 Client 메세지를 송수신하고, Jabber Session Manager는 XMPP Clinet의 메세지를 송수신합니다. 이 들의 메세지는 Presence Engine를 경유하여 교환됩니다. Presence Engine은 두 클라이언트 사이의 메세지 교환을 가능하게 할 뿐만 아니라 “사용자 기반의 Presence Database”를 이용하여 Presence 정보를 처리합니다.
CUP8.x 서버의 Jabber XCP (Extensible Communications Platform) 컴포넌트에 대한 이해를 높이고자 아래 그림을 추가하였습니다. 각 컴포넌트에 대해 간단하게 살펴보겠습니다.
- XCP (Extensible Communications Platform) Route Fabric
Server to Server 통신을 담당하며, 다른 Jabber 서버와 통신합니다. 위의 그림에서 처럼 XMPP를 이용한 Federation을 구현 시에 XCP Route Fabric이 이용됩니다.
- Jabber Session Manager
Jabber Session Manager는 XMPP환경에서 User로 인식되며, 모든 XMPP Client를 관리 및 메세지를 릴레이 합니다.
- Instant Messaging Compliance and Logging
대화 내용은 ODBC interface를 이용하여 외부 PostgreSQL 데이타베이스에 저장하거나, XDB interface를 이용하여 IM Auditing을 할 수 있습니다. 이런 기능을 제공하는 별도의 3rd Party 제품을 이용해야 합니다.
CUP 서버가 SIMPLE 및 XMPP를 듀얼 모드의 장점은 Federation에서 나타납니다. Microsoft 및 AOL과는 SIMPLE로, IBM Lotus, Cisco WebEx, Gogle Talk, 3rd party Jabber 제품과는 XMPP를 이용합니다. XMPP를 이용하게 된 CUP 서버의 장점은 CUPC 뿐만 아니라 3rd party XMPP Client를 모두 수용 가능합니다. 예를 들면, 스마트폰이나 테블릿의 “IM+”와 같은 어플리케이션을 CUP 서버에 연동하여 사용할 수 있습니다.
여기에서 XMPP 프로토콜 및 SIMPLE 프로토콜에 대해 정리하면 내용이 너무 방대해지므로 생략하고, 나중에 다시 정리하도록 하겠습니다.
구성 장비들의 연관성
이제 CUP 서버의 Component들의 역할을 살펴보았으니, CUP 서버와 CUCM 간의 역할을 살펴보겠습니다.
일반적으로 CUCM 구축 시 LDAPv3과 연동할 것을 권고합니다. LDAP을 사용하지 않으면, CUCM에 직접 사용자를 입력해야 하는 번거로움이 있습니다. 또한, CUP 서버를 사용하기 위해서는 LDAPv3 가 반드시 필요합니다. LDAPv3와 CUCM간에 LDAP Synchronization을 활성화하여 사용자 정보를 CUCM 클러스터의 Publisher DB에 저장한 후 클러스터내의 Subscriber로 Replication 됩니다. CUP 클러스터의 Publisher는 사용자 정보를 CUCM Publisher로 부터 가져온 Presence User 정보를 CUP 클러스터의 Subscriber로 Replication합니다. 따라서, 사용자 정보의 변경은 CUCM을 거쳐서 CUP 서버로 전달되므로 아래 표처럼 MCS 7845 기준 1000 명의 Presence User라면, CUCM과 Presence Publisher간의 동기화에 5분, 다시 CUP Publisher와 CUP Subscriber의 동기화에 5분이 소요되어 전체 Synchronization Time은 10분정도 소요됩니다.
아래 그림은 상호 컴포넌트에 일어나는 일련의 프로세스를 설명한 것이므로 좀더 구체적으로 이해할 수 있을 것입니다.
- 1 번 SIP/ SIMPLE 프로토콜
CUP 서버와 CUCM간의 SIP/SIPLE 를 통해 전화기의 프레즌스 정보 교환을 제어하기 위해 사용됩니다.
CUCM은 CUP서버를 어플리케이션 서버로 등록 한 후 SIP Trunk 설정하고, CUP 서버는 CUCM을 Unified Presence Gateway로 등록합니다.
- 2 번 CTI / QBE (Computer Telephony INtegration Quick Buffer Encoding) 프로토콜
이 프로토콜은 CUCM에 등록된 전화기를 제어하기 위해 CUP 서버의 Presence User에 의해 사용됩니다. CUPC나 CUCIMOC에서 Desk Phone Control 모드를 사용할 경우 이용됩니다. CTI를 이용한 통신은 CUPC와 CUCM간에 직접 통신하는 것으로 CUP 서버를 경유하지 않습니다
CUCM은 End user를 CTI Enabled Group에 할당하고, End User의 Primary Extension (주요 내선 번호)에 반드시 “CTI Control”이 활성화 되어야 합니다. 만일, MS Lync 서버 등과 연결할 경우 CUP 서버에서 CUCM을 CTI Gateway 로 등록하고, CUCM의 Application User에 의해 CTI 제어가 이루어집니다.
- 3번 AXL SOAP
CUCM을 이야기할 때 항상 나오는 프로토콜로써, CUCM과 CUP 서버간의 Database Synchronization을 위해 사용됩니다. 특정한 설정은 필요 없으며, CUP서버에서는 CUCM의 AXL User를 설정하는 것이 전부입니다.
- 4번 LDAP
CUPC 사용자의 로그인 시에 인증을 위해 사용되는 프로토콜입니다.
CUP 클러스터 구조
MCS 7845 기준 CUP 서버는 서버 당 5,000명까지 지원 가능하며, 6대까지 클러스터로 묶을 경우 30,000 명까지 지원 가능합니다. 시간 당 Device는 8번 PUBLISH를 발생하고, 사용자 당 Contact List는 200 이하를 가정한 것입니다.
최대 3만명을 지원하기 위한 클러스터는 아래와 같습니다. 최대 6대의 CUP 서버가 하나의 클러스터를 이루며, 하나의 서버당 5천명을 지원하는 구조입니다.
그러나, 위의 구조는 HA(High Availability)가 지원되지 않아 하나의 서버가 장애를 일으키면, 5000명의 사용자는 바로 Communicator를 사용할 수 없는 구조입니다.
위의 구조는 HA를 지원하는 구조로 두 대의 서버가 5,000명을 처리하는 구조로 되어 있습니다. 즉, 1번 그룹의 위 서버가 장애 발생시 아래 서버가 백업을 하는 구조입니다. 국내에는 3만명 이상 사용하는 CUCM 클러스터가 없으므로 HA가 지원되는 구조로 하는 것이 효과적입니다.
IM Logging과 Auditing을 위한 구조
CUP 서버는 다양한 채팅을 지원하며, 각각의 내용을 저장하기 위한 방안은 아래와 같습니다.
- Off-line IM
CUP 서버의 IDS에 저장되어 사용자가 로그인 시에 확인할 수 있습니다. 별도의 외부 데이타베이스가 필요 없습니다.
- Ad-hoc Group Chat
Ad-hoc Group Chat은 일대일 채팅 중에 사용자를 추가하여 그룹채팅으로 전환하는 것을 의미합니다. 기본적으로 CUP 서버의 메모리에 저장되며, 외부 데이타베이스가 있다면 외부에 저장됩니다.
.
- Native Compliance 및 Message Achiver
대화 내용 저장을 위해서는 하나의 CUP 클러스터 당 하나의 데이타베이스 인스턴스가 필요합니다.
- Persistent Grup Chat
Psersistent Chat은 채팅방과 대화내용을 저장하기 위한 외부 데이타베이스 인스턴스가 CUP 서버당 필요합니다. 데이타베이스 인스턴스는 하나의 물리적인 서버에 설정할 수 있지만, 퍼포먼스에 따라 분리할 수도 있습니다.
- Third Party Compliance
메세지 로깅 및 메세지 전달 밀 내용에 관한 정책까지 관여하는 3rd Party Compliance 제품을 사용할 경우 서버 당 필요합니다.
정리하며
이제 CUP과 CUCM 간의 관계 및 CUP 클러스터링에 대해 살펴보았습니다. 아래 그림은 Cisco Unified Presence를 설명할 때 항상 제일 처음 나오는 그림이지만, 이해하기 가장 어렵습니다. 사실 이 그림은 모든 연재가 마무리되어야 이해할 수 있을 것입니다.
간단하게 정리하면, Cisco Unieid Presence 8.0 와 CUCM은 프레즌스 정보 교환을 위해 SIP/ SIMPLE 프로토콜, 전화기 제어를 위한 CTI 프로토콜을, Data Synchronization을 위한 AXL / SOAP 프로토콜을 사용합니다. LDAPv3의 사용자 정보는 CUCM을 통해 Synchronization이 이루어지며, CUPC 사용자 인증에 사용됩니다. 또한, CUPC에서 사용자 검색 등에 사용되므로 반드시 LDAPv3가 지원되어야 합니다. Cisco Unity 및 UnityConnection은 CUP서버와 직접 통신은 없고, CUPC가 직접 IMAP을 이용하여 UnityConnection에 접속하여 녹음된 메세지 내용을 들을 수 있도록 합니다. CUP 서버는 XMPP를 이용하여 3rd Party 메신저와 연동이 가능합니다.
메신저 천하통일을 꿈꾸며
XMPP는 현재 가장 인기 있는 IETF 표준 기반의 메세징 프로토콜입니다. 국내의 메세징 시장은 기업마다 자체 개발한 메신저와 표준을 도외시한 자체 메신저가 대부분으로 한 사람이 여러개의 메신저 프로그램을 사용하는 경우가 많습니다. XMPP의 개방성은 jabber 서버간에 연동을 제공합니다.
XMPP를 통해 메신저 천하 통일이 이루어져 메일을 사용하듯이 IM & Presence를 사용할 수 있기를 기대합니다. 전자 메일나 웹이 무료이면서 꼭 필요한 서비스 였기에 전세계에 퍼져나간 것처럼 XMPP도 무료이며 꼭 필요한 서비스입니다. 자신이 사용하는 메신저에 자신이 사용하는 메신저 서버만 등록하면 채팅을 할 수 있는 시기가 그리 멀지 않으리라 생각합니다.
--------------------------------------------------------------------------
라인하트 (CCIEV #18487)
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/ucwana (라인하트의 트위터 )
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (벤더에 상관없이 UC를 공부하는 사람들이 모인 구글 구룹스)
정리하고 보니 나도 디지털 네이티브 ^____________^
