Popis vychází z testované situace, kde se upgradují dva servery Cisco Unified Communications Manager (CUCM) 8.6.2.23900-10 = 8.6(2a)SU3. Publisher i Subscriber běží jako virtuální servery na VMware ESXi 5.5. Na aktuální verzi 10.5.2.12901-1 = 10.5(2)SU2a.

Pozn.: Když jsem dokončoval tento popis, tak byla zveřejněna verze CUCM 11.0. Ale asi chvíli potrvá, než budou odstraněny tradiční úvodní problémy.

Ověření kompatibility a dokumentace

V dokumentu Compatibility Information for Cisco Unified Communications Manager Release 10.x můžeme ověřit, že z verze 8.6(2a)SU3 je možný přímý upgrade na 10.5(2)SU2a. V dokumentu Virtualization for Cisco Unified Communications Manager (CUCM) se dozvíme, že CUCM 10.x je podporován na VMware vSphere ESXi 4.0 U4, 4.1 U2, 5.0 U1, 5.1 a 5.5.

Z Cisco Download můžeme stáhnout soubor UCSInstall_UCOS_10.5.2.12901-1.sgn.iso, u kterého je popis

10.5(2)SU2a US Export Restricted - full encryption capabilities (non-bootable). For upgrade from 10.0(1). Upgrades from
 6.1(4)+, 7.1(3), 7.1(5), 8.x, and 9.x need to be requested via PUT (www.cisco.com/upgrade) or purchased.  

To bych chápal, že toto ISO nelze použít na upgrade z verze 8.6, ale v praxi jsem nenarazil na žádný problém.

Oficiální dokumentace na Cisco webu

• stručné informace k poslední verzi Release Notes for Cisco Unified Communications Manager Release 10.5(2) and IM and Presence Service Release 10.5(2a)
• podrobnější informace (sic k trochu starší verzi) ohledně upgradu Upgrade Guide for Cisco Unified Communications Manager, Release 10.0(1)
• další velmi podobné informace k upgradu Cisco Unified Communications Operating System Administration Guide, Release 10.0(1) - Software Upgrades
• velmi dobrá je prezentace popisující různé možnosti a úskalí upgradu/migrace BRKUCC-2011 - Best Practices for Migrating Previous Versions of CUCM to version 10.5. (2014 San Francisco) - 2 Hours
• odkazy na řadu další dokumentace obsahuje post Cisco Unified Communications Manager 10.5(1) - Now Shipping

Využití PCD - Prime Collaboration Deployment

Cisco všude doporučuje svůj relativně nový nástroj na migrace, upgrady a další správu prostředí Unified Communications, Cisco Prime Collaboration Deployment (PCD). Když jsem jej vyzkoušel, tak jsem došel k názoru, že je lepší se obejít bez něj. PCD získáme jako virtuální aplikaci spolu s instalací CUCM z Product Upgrade Tool (PUT) (to je teoretická informace, já měl s jeho získáním trochu problémy). Může jít třeba o soubor pcd_vApp_UCOS_10.5.2.10000-5_vmv7_v1.2.ova.

Využití PCD pro upgrade asi nepřináší příliš mnoho výhod, pokud nemáme rozsáhlý cluster. PCD provádí klasický upgrade, jako bychom jej provedli ručně. Výhoda je, že tasky provede automatizovaně a postupně je spouští na členech clusteru. Nemáme ale moc přehled o tom, co se děje. Pokud upgrade selže, tak v PCD nezískáme vůbec žádné informace, k jaké chybě došlo (musíme se jedině podívat do logů přímo na CUCM server). Proto myslím, že ve většině případů je lepší provést manuální upgrade.

Nějaká oficiální dokumentace Release Notes for Cisco Prime Collaboration Deployment, Release 10.5(2), Cisco Prime Collaboration Deployment Administration Guide, Release 10.5(1), Migration to Cisco Unified Communications Manager Release 10.5(1) Using Prime Collaboration Deployment.

Na VMware ESXi server nasadíme OVA šablonu. Po spuštění virtuálního stroje musíme projít konfiguračního průvodce, který je velmi podobný instalaci CUCM. Zadáme síťové údaje, admin uživatele, údaje pro certifikát, bezpečnostní heslo a pak server nastartuje. Připojíme se na jeho webové rozhraní a to je podobné jako ostatní Cisco Prime nástroje.

Upgrade pomocí PCD

Na PCD musíme nahrát data, která použijeme pro upgrade. Na pár místech se uvádí, že virtuál PCD využívá speciální datastore a data můžeme nahrát pomocí VMware. Tak to u mne nebylo (nebo jsem nepřišel na to, jak zprovoznit) a musel jsem využít SFTP server, který běží automaticky na PCD a na něj nahrát data (třeba pomocí WinSCP). Potřeboval jsem instalační ISO a aktualizační COP soubor (viz. dále popis upgradu). Na SFTP se připojujeme na adresu PCD jako uživatel adminsftp s naším heslem admina a data nahráváme do složky upgrade.

Používání PCD je velice jednoduché (níže stručně bodově popsáno). Před začátkem je dobré ověřit, že na CUCM je aktivovaná služba Platform SOAP Services. V opačném případě se při vytváření Upgrade Task (a hledání souborů na SFTP) vrátí chyba The Platform Administrative Web Services (PAWS) is not available.

• na novém PCD musíme nastavit náš CUCM cluster - Inventory - Clusters - Discover Cluster
• jednoduše vytvoříme Upgrade Task - Task - Upgrade - Add Upgrade Task
• instalace COP souboru se provádí také v rámci tasku Upgrade, takže nejprve zvolíme aktualizační COP soubor a pak vytvoříme další task, kde zvolíme instalační ISO
• jedním z kroků vytváření tasku je Set Start Time & Upgrade Options, kde volíme, jestli se task spustí hned po vytvoření, manuálně nebo v naplánovaný čas, také zde volíme, jestli se po upgradu rovnou provede přepnutí verze, to jinak můžeme provést pomocí Switch Versions Task
• můžeme také měnit pořadí sekvence serverů, kde se provádí upgrade, ale první musí být Publisher

Pokud nám upgrade selže (například proto, že je málo místa na disku), tak se dozvíme pouze informaci Upgrade job for node CUCM failed. Log žádné detailnější informace neobsahuje, podívat se musíme jedině složitě přímo na CUCM.

Standardní upgrade CUCM

Upgrade minoritních verzí jsme si popsali v článku CUCM proces standardního upgradu, tento majoritní upgrade se od něj zas tak moc neliší, ale popíšeme si jej podrobně celý znovu.

Druhy upgradu

Cisco dělí upgrade CUCM do řady typů, které jsou dány tím, co na co aktualizujeme. Vyplívá z nich různá složitost celého procesu. Hlavní typy upgradu jsou (ve chvíli kdy spustíme upgrade, tak se automaticky detekuje a použije potřebný typ):

• L2 Upgrade - Linux to Linux upgrade je nejjednodušší možnost, instalace probíhá do druhého (neaktivního) oddílu (partition) a server stále běží a obsluhuje klienty. Po instalaci se rozhodneme, kdy chceme přepnout verzi a provedeme restart serveru.
• Refresh Upgrade - tento upgrade se provádí ve chvíli, kdy existuje nekompatibilita mezi starou a novou verzí OS a musí se nově instalovat operační systém. V průběhu instalace dojde (několikrát) k restartu a služby serveru jsou mimo provoz. Nově se formátují oddíly, v některých případech přicházíme o data na druhém oddílu, takže nám nezůstává záloha pro krok zpět. Upgrade probíhá obdobně jako čistá instalace. Tento upgrade probíhal prve ze starších verzí než 8.5(x) na 8.6(1) a novější, a pak vždy když se mění majoritní verze operačního systému.
• Bridge Upgrade - pokud náš MCS server nepodporuje novou verzi CUCM, tak ještě může podporovat Bridge Mode. To znamená, že dovolí udělat upgrade, ale následně nepracuje, dovolí pouze provést DRS zálohu. Na nový server nebo do virtuálního prostředí nainstalujeme danou verzi a obnovíme zálohu.

Refresh Upgrade se použije, když jde o upgrade majoritní verze RedHatu (Cisco označuje operační systém jako Cisco UC Operating System - UCOS). CUCM 7.0 až 8.5 je Red Hat Enterprise Linux (RHEL) 4, CUCM 8.6 až 9.x je RHEL 5, CUCM 10.x až 11.0 je RHEL 6. Upgrade z 8.6(2a) na 10.5(2) je Refresh Upgrade.

Příprava na upgrade

Předtím, než se pustíme do upgradu, je potřeba si ověřit a připravit řadu věcí. Ty hlavní jsou:

• Ověřit, že máme k dispozici aktuální a kompletní DRS zálohu CUCM clusteru! (ve virtuálním prostředí, pokud provádíme upgrade na kopii, to již není tak důležité, ale stejně doporučuji před jakýmkoliv zásahem zkontrolovat, že máme aktuální zálohu - stát se může cokoliv)
• Ověřit, že jsou v pořádku replikace clusteru (pomocí CLI utils dbreplication runtimestate mají hodnotu 2 nebo v GUI pomocí reportů), více informací v Kontrola replikací CUCM clusteru
• Není špatné obecně ověřit, že všechny služby na serverech běží a vše je OK
• Připravit se, že budeme muset do 60 dní po upgradu nainstalovat nový licenční soubor (budeme muset upgradovat stávající licence), a pokud máme nějakou neinstalovanou licenci, tak ji musíme před upgradem aplikovat (nainstalovat)
• Pokud byl virtuální stroj vytvořen pro starší verzi CUCM (pomocí starší OVA template), tak se doporučuje, ještě před upgradem (v jiných materiálech se uvádí po upgradu a tak je to uvedeno i u UCCX upgradu), změnit Guest OS na RHEL 6 (64 bit) a síťový adaptér na VMXNet3
• Před upgradem CUCM se doporučuje nainstalovat poslední Device Pack pro aktuální verzi CUCM, tedy provést upgrade firmwaru telefonů, pro podporu češtiny můžeme potřebovat Locale Installer pro náš jazyk, info CUCM a UCCX instalace COP souboru, Locale, Device Pack
• Ověřit, že všechny telefony jsou kompatibilní s verzí 10.5 (Cisco Unified Communications System Release Summary Matrix for IP Telephony, Cisco Unified Communications Compatibility Tool, Compatibility Information for Cisco Unified Communications Manager Release 10.x, Cisco Unified Communications Manager Software Compatibility Matrix), aby nás nečekalo nemilé překvapení. Běžné telefony jako 79x5G jsou podporovány. Podpora Cisco ATA 186 byla poslední verze 3.02.04 (090202A) SCCP, která byla podporována na CUCM 8.0 (oficiálně nahrazeno pomocí ISR G2), ale dle diskusí stále funguje i na 10.5 (ATA-186 can be registered with CUCM v10.5) - ověřeno v praxi
• Pokud máme další software (i třetích stran), který spolupracuje s CUCM, tak je také třeba ověřit jeho kompatibilitu. Příkladem je Cisco IM and Presence Service nebo třeba Cisco Contact Center Express (UCCX), z informací Compatibility Matrix for Unified CCX se dozvíme, že UCCX 8.5(1) SU4 je kompatibilní s CUCM 8.0(1) až 9.1(2)SU3 a UCCX 10.6(1) je kompatibilní s CUCM 9.1(1) až 10.5(2)SU1
• Poznámka z oficiální dokumentace. Za některých podmínek může telefon, který má přiřazeného uživatele v položce Owner User ID, spotřebovat méně licencí na CUCM 10. Asociace se doporučuje dělat před upgradem, může se použít BAT export a import. Více informací v kapitole o licencování.
• Před upgradem se doporučuje použít License Count Utility a vytvořit report pro migraci licencí (popsáno dále u licencí)
• Je dobré mít dokumentovánu UC infrastrukturu, v podstatě věci, které potřebujeme při čisté instalaci (síťové nastavení, všechny admin uživatelské účty, apod.), kdyby došlo k nějakému problému (info o účtech Účty na CUCM)
• Cisco uvádí doporučení vymazat Call Detail Records (CDRs), logy a případně také staré a nepoužívané firmwary z TFTP, aby se zrychlil proces upgradu, díky virtuálnímu prostředí a možnosti upgradovat paralelně to nepovažuji za nutné. Můžeme se ale dostat do situace, kdy potřebujeme uvolnit místo na disku (podrobněji popsáno dále) a promazáním TFTP se nám zmenší zálohy

Proces upgradu

Velká výhoda je, že máme CUCM ve virtuálu. Můžeme tedy jednoduše vytvořit kopii a provádět testování, zatímco nám produkce běží. Pokud na produkci neprovedeme konfigurační změny, tak můžeme provést upgrade bokem a pak pouze přepnout (vyměnit) virtuální servery. I když je toto Ciscem nedoporučované! K tomu se nám bude hodit síťově oddělené virtuální prostředí, které jsme si popsali v Migrace CUCM z fyzického HW do VMware kapitole Proces migrace.

Již jsme si uvedli, že v našem případě jde o Refresh Upgrade. Při běžnějším L2 upgrade bývá obecný postup (protože v průběhu upgradu je systém stále funkční):

• upgrade Publisher > upgrade (všech) Subscriber > přepnutí a restart Publisher > přepnutí a restart (všech) Subscriber

V případě Refresh Upgrade dochází k několika restartům a systém je skoro od začátku nedostupný (trvá okolo 2 hodin), takže se používá postup:

• upgrade Publisher > přepnutí Publisher > upgrade (všech) Subscriber > přepnutí (všech) Subscriber

Stručně popsaný postup upgradu je následující:

• splněné podmínky z předchozí kapitoly Příprava na upgrade (hlavně záloha a ověření funkčnosti)
• v oficiální dokumentaci se vždy uváděl krok - vypneme službu Extension Mobility (EM) na všech nodech, je to proto, aby nedocházelo k zápisu do DB (pokud se EM nemění, tak nám v praxi projde upgrade i bez vypínání služby), což může způsobit selhání upgradu, podle informací při upgradu na 10.x již není vypínání služby třeba
• nainstalujeme potřebný COP soubor ciscocm.version3-keys.cop.sgn - popsáno v článku CUCM a UCCX instalace COP souboru, Locale, Device Pack
• zkontrolujeme a případně uvolníme místo na Common partition
• instalační ISO soubor buď nahrajeme na FTP/SFTP server nebo jednoduše připojíme do virtuální mechaniky našeho CUCM VM pomocí VMware
• první se provádí upgrade Publisheru (Subscriber nás ani nenechá upgradovat, dokud Publisher nemá danou verzi na aktivní nebo neaktivní partition)
• přepneme Publisher na novou verzi (můžeme to provést automaticky jako součást instalace)
• poté se upgraduje Subscriberu (pokud jich je více, tak můžeme paralelně). Cisco striktně doporučuje provést upgrade všech serverů a ne instalovat Subscriber nově a nechat replikovat data (Rebuilding Subscriber), v té situaci dochází ke ztrátě dat specifických pro Subscriber
• přepneme Subscriber na novou verzi (můžeme to provést automaticky jako součást instalace)
• pokud jsme vypnuli EM, tak zapneme službu Extension Mobility na všech nodech
• pokračujeme akcemi po upgradu

Z praxe jsem slyšel doporučení, abychom se do budoucna vyhnuli možným problémům, pokračovat dále.

• na upgradovaných serverech provést DRS zálohu
• nainstalovat čistě virtuální servery v cílové verzi
• provést obnovu zálohy

Nejsem si nutností tohoto postupu jistý, protože Refresh Upgrade provádí čistou instalaci za pomocí odpovědního souboru a uložených dat.

Málo místa na Common partition

Virtuální server s CUCM má standardně (záleží na konfiguraci) jeden vDisk o velikosti 80 GB. Ten se při instalaci rozdělí na tři oddíly, jde o Active 15GB, Inactive 15GB a Logging (common) 50GB. Na prvních dvou se nachází vlastní nainstalovaný CUCM aktivní verze a případně neaktivní (která byla upgradovaná). Poslední největší oddíl je určen pro logy a další společná data, jako jsou také instalační soubory.

Když spustíme upgrade, tak se může stát, že skončí chybou a v detailech se dozvíme, že není dostatek místa na oddíle Common. Cisco uvádí, že pro upgrade může být potřeba až 25 GB volného místa (pokud máme opravdu hodně dat na TFTP serveru, tak i více).

There is not enough disk space in the common partition to perform the upgrade. Please use either the Platform Command Line
 Interface or the Real-Time Monitoring Tool (RTMT) to free space on the common partition.

Pozn.: Více volného místa na disku je potřeba, pokud provádíme upgrade z FTP/SFTP serveru, protože se celý soubor musí nahrát na CUCM a tam rozbalit. Pokud provádíme upgrade z CD/DVD (třeba mapovaný ISO soubor k virtuálu), tak nám postačí o něco méně místa.

Pomocí CLI se na CUCM můžeme podívat na volné místo na jednotlivých oddílech (níže pouze část výpisu).

admin:show status
Host Name    : cucm
...
Total            Free            Used
Disk/active         14643120K        2512220K       11982136K (83%)
Disk/inactive       14410496K        2650244K       11611488K (82%)
Disk/logging        50179664K       10596376K       36993112K (78%)

Jiným příkazem můžeme zjistit, které složky nebo soubory zabírají nejvíce místa.

admin:show diskusage common sort
This command can take significantly long time,
and can also effect the system wide IOWAIT on your system.
Continue (y/n)?y
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda6             50179664  37007408  10582080  78% /common
36953332        /common/
36809672        /common/log
23099436        /common/log/taos-log-b
13511236        /common/log/taos-log-a
...

Podobně můžeme vypsat jen některé části využitím activelog, inactivelog, install, tftp, tmp. Pro podrobnější přehled také můžeme využít

file list activelog /
show diskusage activelog directories sort

Při upgradu na verzi CUCM 9 byl nedostatek místa uveden jako bug a popsaný v Upgrade to 9.1(1) Fails with Insufficient Disk Space. V upgradu na CUCM 10 je již tato situace popsána v oficiální dokumentaci upgradu a máme si na ni dát pozor CUCM 10.0 Pre-Upgrade Tasks.

Běžným řešením situace s nedostatkem místa je nainstalování Free Common Space COP souboru ciscocm.free_common_space_v1.2.k3.cop.sgn. Ten odstraní z common oddílu určité soubory, které se týkají neaktivní verze (spouští se pouze, pokud je méně volného místa než 25 GB). Není pak možno přepnout verzi a Cisco uvádí, že po použití tohoto souboru musíme provést upgrade. Po aplikaci není potřeba restart, ale v průběhu může být ovlivněn výkon serveru.

Pozn.: U mne se touto metodou uvolnilo 13 GB, takže celkové volné místo bylo 23 GB. Upgrade jsem zkoušel mnohokrát a prve instalace proběhla, ale při dalších pokusech v první fázi skončila upozorněním na nedostatek místa. Řešením bylo rozšíření velikosti disku o 10GB, což je popsáno dále.

Pozn.: Při stahování tohoto COP souboru z Cisco Download mi přijde zavádějící popis "VMware Disk Size Reallocation COP file: This COP file allows UCM VMs to increase the size of their vDisk(s) without requiring a system rebuild." To vypadá, jako by patřilo k druhému COP souboru ciscocm.vmware-disk-size-reallocation-1.0.cop.sgn.

Další možnost je použít Disk Expansion COP soubor ciscocm.vmware-disk-size-reallocation-1.0.cop.sgn. Pak můžeme ve WMvare zvětšit velikost vDisku, abychom získali dostatek volného místa (soubor je potřeba pro CUCM 9.1 a starší, novější verze změnu disku podporují). Popis použití je v ciscocm.vmware_disk_size_reallocation_v1.0.pdf, který stáhneme spolu s COP souborem (najetím na položku a volba Readme). Nainstalujeme COP soubor, vypneme VM, zvětšíme disk, zapneme VM. Server se po zapnutí dvakrát restartuje (provádí rozšíření oddílu) a pak naběhne s novou velikostí disku.

Jiná možnost pro zjištění (System - Server - Disk Usage) i uvolnění místa je využití Real-Time Monitoring Tool (RTMT) na shromáždění a smazání Core and Trace souborů Tools - Trace & Log Files - Collect Files.

Alternativa na odmazání logů je snížit jejich limit, třeba pomocí RTMT - Alert Central, pravým tlačítkem Set Alert/Properties na LogPartitionLowWaterMarkexceeded a snížit hodnotu z 90% na třeba 40% a to samé na LogPartitionHighWaterMarkexceedes, kde změnit 95% třeba na 50%. Pak je třeba na CUCM restartovat službu Network Services - Cisco Log Partition Monitoring Tool, následně se začnou odmazávat logy.

Na TFTP serveru můžeme mít mnoho starých a nepoužívaných verzí firmwarů, ty můžeme pomocí GUI nebo CLI CUCM promazat. Dopředu je ale dobré udělat zálohu TFTP souborů pomocí CLI příkazu file get tftp * recurs, soubory se odešlou na zadaný SFTP server (ale nevytváří se podsložky a stejné soubory se přepíší).

Průběh vlastního upgradu serveru

• Instalační ISO UCSInstall_UCOS_10.5.2. 12901-1.sgn.iso připojíme do virtuální mechaniky našeho CUCM VM
• pomocí GUI CUCM zahájíme upgrade - Cisco Unified OS Administration - Software Upgrade - Install/Upgrade
• zvolíme zdroj instalace (Source) DVD/CD, kořenový adresář (Directory) / a můžeme zadat SMTP server pomocí kterého dostaneme nějaké informace o průběhu upgradu

• v zadané lokalitě se hledají akceptovatelné soubory, pokud se nějaké naleznou, tak se nabídnou k výběru
• přečteme si upozornění, že jde o Refresh Upgrade a že musíme nainstalovat všechny licence, zvolíme Switch to new version after upgrade

• zahájí se instalace a zobrazuje log v textovém okně, trvá to několik minut (cca 15) a pak se zobrazí informace, že příprava Refresh Upgrade proběhla, systém se restartuje a bude pokračovat v instalaci

• připojíme se pomocí VMware Virtual Machine Console na daný virtuál a sledujeme instalaci

• důležitý krok, na který jsem přišel až při testech, pokud jsme připojili ISO do virtuální mechaniky, tak jej v průběhu restartu musíme odpojit, jinak nám instalace hned na počátku skončí chybou (patrně se nabootuje z tohoto DVD místo z disku). Poznáme to tak, že se hned při startu zobrazí dialog (na kterém se instalace zastaví), jestli chceme zkontrolovat instalační médium. Pokud pokračujeme dále, tak se zobrazí chyba.

Pozn.: Pokud nestihneme odpojit médium hned na začátku a naběhne nám stránka s testem média, tak jej odpojíme nyní a restartujeme.

• automaticky (bez našeho zásahu) pak probíhá instalace, která je stejná, jako při čisté instalaci CUCM a trvá stejně dlouho (tedy běžně 2 až 3 hodiny)

Pozn.: Náhodou jsem narazil na to, že při určitých fázích instalace (hlavně, když narazíme na error) můžeme využít klávesové zkratky Alt+F1 až F4, čímž se přepínají konzole Linuxu. Takže pomocí Alt+F2 se dostaneme na příkazový řádek a můžeme si třeba vypsat logy.

Pozn.: Průběh Refresh Upgrade se ukládá do install_log_<timestamp>, takže pokud se dostaneme na CLI, tak si můžeme vypsat nebo zkopírovat file get install *.

Operace po upgradu

Několik administračních zásahů je doporučeno provést hned po upgradu CUCM.

• zkontrolovat, že se nám aktualizovali VMWare Tools a případně upravit vlastnosti VM
• nainstalovat aktuální verzi Locale (obsahuje přeložené texty a zvuky) na všechny členy clusteru pro jazyky, které využíváme (mimo angličtiny), ta musí odpovídat majoritní.minoritní verzi CUCM, jde o COP soubor, popis v článku CUCM a UCCX instalace COP souboru, Locale, Device Pack
• volitelně můžeme nainstalovat nový Device Pack, který obsahuje firmware a konfigurační soubory pro Cisco zařízení, jde o COP soubor

Problém s VMware Tools

Pokud nám vSphere Client po upgradu ukazuje, že server má VMware Tools ve stavu Not installed nebo Out of date a nedaří se je aktualizovat, tak je třeba provést níže uvedený postup s vypnutím CCM Firewallu.

Na CLI zadáme příkaz, který vypne CCM FW

utils os secure permissive

Pokud jsou Tools Not installed, tak nejprve server restartujeme, až budou Out of date, tak provedeme automatickou instalaci. Ta by již měla proběhnout, není třeba restart, a Tools se začnou hlásit jako Current. Opět aktivujeme CCM FW

utils os secure enforce

Instalace VMware Tools

Na virtuálu je dobré mít v nastavení na záložce Options – VMware Tools zatrženo Check and upgrade Tools during power cycling. Pak by se Tools měly aktualizovat samy.

Pokud ve virtuálu nemáme VMware Tools, tak ve vSphere Client u VM zvolíme v menu Guest – Install/Upgrade VMware Tools. Tím se k serveru připojí CD s instalací. Na CLI CUCM serveru pak zadáme příkaz

utils vmtools refresh

Pokud máme neaktuální VMware Tools, tak můžeme provést Automatic Tools Upgrade. Ve vSphere Client u VM zvolíme v menu Guest – Install/Upgrade VMware Tools. Nyní se nabídnou dvě možnosti Interactive Tools Upgrade a právě Automatic Tools Upgrade, který použijeme.

Otestování po upgradu

Je dobré mít připravený seznam operací, které otestujeme hned po upgradu, abychom věděli, že se vše zdařilo. Při testovacím upgradu v oddělené síti je možno otestovat několik věcí navíc.

• pomocí Cisco Unified Real Time Monitoring Tool (RTMT) ověřit stav serverů (Critical Services, Alert Central, případně další)
• ověřit replikace clusteru
• připojit telefon, který správně nastartuje a zaregistruje se
• připojit druhý telefon a ověřit volání mezi nimi
• ověřit přihlášení/odhlášení Extension Mobility
• v testovacím prostředí můžeme vyzkoušet všechny typy zařízení, které využíváme, že jsou funkční na nové verzi
• otestovat volání z/do PSTN
• vyzkoušet všechny speciální funkce, které na CUCM používáme

Licencování CUCM

Oblast licencování je u Cisco většinou složitá a při upgradu CUCM z verze 8.6 na 10.5 dochází k velkým změnám. Nutno hned na začátku podotknout, že migrace licencí na nový model je (minimálně pro mne, ale řekl bych, že také pro většinu ostatních) značně nevýhodná. Různá dokumentace se nachází v článcích

• Release Notes for Cisco Prime License Manager Release 10.5(1)
• Cisco Prime License Manager User Guide, Release 10.5(2)
• Understanding Cisco Prime License Manager(PLM)
• Licensing CUCM 10.x using Cisco Prime License Manager
• Features and Services Guide for Cisco Unified Communications Manager, Release 10.0(1) - Licensing

Licencování starších verzí

Do CUCM 9 se prováděla správa a vynucení (kontrola) licencí přímo na CUCM Publisheru pro daný cluster. Stručně popsané používané licence:

• verze 5.0 až 7.1(3) - Node license pro každý server, Device License Unit (DLU) pro každé zařízení (hlavně telefon, běžný typ konzumuje 4 DLU), záleží na typu a vlastnostech, Software Feature license podpora pro povýšení major verze (ESW/UCSS), licence jsou generovány dle MAC adresy Publisheru
• verze 7.1(5) až 8.6 - Cisco chtělo změnit licencování, ale úplně to nezvládlo, takže technicky jde pořád o Node, DLU a Software Feature (tedy licence jsou Device based), ale objednává se podle uživatelů (tedy User based), u fyzických serverů (MCS) je pořád licence dle MAC adresy Publisheru, u virtuálních licenční MAC adresa Publisheru (vytváří se z řady hodnot)

Licencování v CUCM 9 a 10

S příchodem CUCM 9 se začal používat Enterprise License Manager (ELM). U CUCM 10 byl nahrazen pomocí Prime License Manager (PLM), ale základní funkce a využití je stejné. Má se jednat o zjednodušenou, centralizovanou, enterprise správu licencí (User based) pro Cisco UC aplikace (ale UCCX podporován není). Automaticky se instaluje na každý CUCM server (nebo Cisco Unity Connection, nově také Cisco Emergency Responder a Cisco WebEx Meetings Server) a my jej můžeme na jednom z nich (patrně Publisheru) aktivovat. Máme také možnost využít samostatné PLM OVA a ISO a nainstalovat malý samostatný virtuál.

ELM/PLM dokáže obsluhovat všechny UC clustery v organizaci. PLM 10.x podporuje licence CUCM 9.x i CUCM 10.x. ELM 9.x podporuje CUCM 9.x a pomocí COP souboru (elm_LicenseDef_9_1_v1.cop.sgn) můžeme přidat i podporu CUCM 10.x. Při využití PLM nebo ELM se licence nenahrává přímo na CUCM, ale právě na licenční manager, který je spravuje a přiděluje jednotlivým clusterům. Licence je založena na PLM/ELM MAC adrese a host ID. CUCM vyhodnocuje využívání licencí a posílá data na PLM/ELM, ten vyhodnotí všechny požadavky a licence, a odpovídá validní nebo nevalidní licencí.

Licence pro CUCM verze 9.x a verze 10.x se určují podle celkového počtu uživatelů, uživatelských vlastností a konfigurovaných zařízení. Jsou buď typu Cisco User Connect Licensing (UCL), uživatelům se licencují individuální produkty, nebo Cisco Unified Workspace Licensing (UWL), balík, který obsahuje více aplikací. Všechny licence podporují Extension Mobility (EM), Jabber IM/Presence a až na UCL Essential také Mobile Connect (SNR). Podrobněji jde o (vyšší licence obsahuje funkce nižší):

• UCL Essential - 1 zařízení se základními hlasovými a analogovými funkcemi (třeba analogový telefon, ATA 186, Cisco 3905)
• UCL Basic - 1 zařízení se základními hlasovými a video funkcemi (třeba Cisco 6911, Cisco 6921)
• UCL Enhanced - 1 zařízení s rozšířenými hlasovými a video funkcemi (skoro všechny telefony, třeba Cisco 79xx, Cisco 89xx, Cisco 99xx, Cisco TelePresence EX60), včetně mobilního a desktop Jabber klienta
• UCL Enhanced Plus - 2 zařízení, ostatní jako UCL Enhanced
• CUWL Standard - 10 zařízení s rozšířenými hlasovými a video funkcemi, včetně mobilního a desktop Jabber klienta a hlasové schránky Unity Connection
• CUWL Professional - 10 zařízení, přidává professional collaboration workspace application (WebEx Meetings, WebEx Social)
• TelePresence Room - speciální licence pro TelePresence místnosti

Popsané licence přiřazujeme různým způsobem, dle nastavení (asociace uživatele a zařízení), což můžeme provádět dle výhodnosti:

• Pouze uživatel (User Only) - pokud je uživatel konfigurovaný v systému, ale nemá asociované žádné zařízení (není jeho vlastník, což znamená zadání User ID do položky Owner User ID u zařízení), uživatel s Extension mobility (EM) nevyžaduje žádnou licenci, EM s Unified Mobility potřebuje jednu Basic UCL, uživatel, který nevyužívá žádnou licencovanou funkci, nepotřebuje žádnou licenci
• Pouze telefon (zařízení) (Device Only) - zařízení, které nemá vyplněné přirazení Owner User ID, licence záleží na modelu (pro většinu telefonů jde o Enhanced UCL)
• Uživatel a telefon (zařízení) (User and Device) - když je k zařízení přiřazen uživatel v Owner User ID, tak se potřebná licence určuje podle typu zařízení a počtu zařízení přirazených uživateli, tedy uživatel s jedním běžným telefonem potřebuje Enhanced UCL, uživatel s libovolnými dvěma zařízeními potřebuje UCL Enhanced Plus, pro více zařízení je třeba CUWL Standard

Jak já to chápu, tak v běžném případě, kdy uživatelé používají jeden telefon (a žádného SW klienta) s Extension mobility, tak je jedno, jestli využijeme User Only + Device Only nebo přiřadíme uživatele a máme User and Device, v obou případech potřebujeme jednu Enhanced UCL licenci. Ale například uživatel s Extension mobility a Unified Mobility je výhodnější User and Device, protože si vystačí s jednou licencí místo dvou (Basic UCL pro uživatele a Enhanced UCL pro telefon).

Využití licencí

Tím, že se licencování primárně přesunulo z CUCM na PLM, tak nám v menu CUCM Cisco Unified CM Administration - System - Licensing zmizela většina položek.

Nachází se zde pouze jedna nová a docela důležitá, a to License Usage Report.

Původní License Unit Report ukazoval počet instalovaných a použitých DLU licencí, plus Node licence.

Nový License Usage Report se generuje jedenkrát denně (generování můžeme spustit i ručně) a zobrazuje požadavky na jednotlivé licence, které odesílá na PLM. Detailně si můžeme vypsat uživatele a zařízení, která potřebují daný typ licence. Také zde vidíme PLM, ke kterému je CUCM server připojen a kdy naposled došlo k synchronizaci (musí k ní dojít alespoň jednou za 24 hodin).

Kvůli licencím můžeme také využít reporty a zjistit statistiky o uživatelích a zařízeních. Na CUCM Cisco Unified Reporting - System Reports a třeba reporty Unified CM Device Counts Summary, Unified CM User Device Count.

Cisco Prime License Manager (PLM)

Když jsme provedli upgrade CUCM, tak se automaticky na každý nainstaloval PLM. Můžeme provést samostatnou instalaci PLM, ale v řadě případů asi využijeme ten na CUCM Publisheru. Když se připojíme na adresu CUCM server, tak se zde nachází rozcestník, a nový odkaz Cisco Prime License Manager. Je dostupný na adrese https://dns-cucm/elm-admin.

Pro přihlášení se automaticky nastavil účet Platform Administrator z CUCM (při samostatné instalaci účet zadáváme v průběhu instalace). Pokud si nejsme jisti, tak si můžeme vypsat uživatele, pomocí CLI příkazu na CUCM

license management list users

případně mu resetovat heslo

license management reset user password

Práce s PLM je velice jednoduchá

• přidáme instanci produktu - CUCM Publisher
  • menu Product Instances - Add (zadáváme uživatele a heslo, jde o účet Platform Administrator (OS Admin))
  • po přidání zvolíme Synchronize Now
• nainstalujeme licence
  • menu Licenses - Fulfillment - Other Fulfillment Options - Fulfill Licenses from File nebo Fulfill Licenses from PAK
  • máme zde i možnost vytvořit žádost o licence Generate License Request nebo provést migraci licencí Migrate Licenses
• kontrolujeme požadované/instalované licence
  • menu Licenses - Usage

License Count Utility (LCU)

Cisco má nástroj pro plánování konverze licencí při upgradu, který se připojí k CUCM clusterům a zjistí naše požadavky na licence, kdy vychází z aktuálních DLU. Jmenuje se License Count Utility momentálně v poslední verzi 9.1(2), umí pracovat s CUCM 6.x, 7.x a 8.x. Oficiální dokumentace Using Cisco Unified Communications Manager License Count Utility, Release 9.1(2). Stáhneme na Cisco download u libovolné verze CUCM v sekci Unified Communications Manager / CallManager / Cisco Unity Connection Utilities-LCU.

Jde o Java aplikaci, kde zadáme adresu našeho CUCM clusteru a credentials Platform Administratora. Zvolíme Generate Report a během chvilky se načtou údaje z CUCM. Na internetu najdeme mnoho screenshotů a dokumentace, která uvádí, že v reportu máme sekci License Conversion Worksheet. Zde vidíme přepočty DLU na uživatelské licence, potřebné počty licencí, zbývající DLU a můžeme upravovat množství. Tato část byla v poslední verzi aplikace LCU odstraněna (a starší verzi nestáhneme), takže pouze můžeme uložit report a v CSV souboru vidíme naše DLU a požadované licence.

Migrace licencí

Doporučený postup je následující:

• před upgradem vytvoříme report pomocí License Count Utility
• po upgradu použijeme Prime License Manager (nejprve přidáme nás cluster) a vytvoříme žádost o migraci licencí
  • Licenses - Fulfillment - Other Fulfillment Options - Migrate Licenses
  • projdeme průvodce, kde v několika krocích vyplníme základní údaje
  • zvolíme produkt Unified CM, verzi 10.x
  • nabídne se nám náš upgradovaný cluster, který zvolíme pro migraci
  • z něj se načtou údaje (jako původní licenční MAC a DLU), zadáme počet veřejných telefonů (Public Space Phones), kde můžeme dát i 0, a pokud máme, tak připojíme LCU report (případně i číslo případu, pokud jsme jej založili)
  • v posledním kroku uvedeme informace o kontraktu, společnosti, CCO, případně další
  • vytvoří se zazipovaný soubor s informacemi, který odešleme licenčnímu týmu
• zpět obdržíme licenci (zazipovaný binární soubor), kterou nainstalujeme
  • Licenses - Fulfillment - Other Fulfillment Options - Fulfill License from File
  • zvolíme zip soubor a uložený licenční plán (ten se vytvořil při vytváření migrační žádosti)
  • po kliknutí na Install dojde k nainstalování licence
• zkontrolujeme stav licencí
  • Licenses - Usage
  • můžeme se přepínat mezi zobrazením v tabulce a grafu, licenci můžeme rozkliknout pro detaily
  • pod Licenses - Fulfillment vidíme naši nainstalovanou licenci

Neoficiální požadavky pro konverzi DLU na uživatelské licence:

• CUWL Professional - 12 DLU
• CUWL Standard - 11 DLU
• Enhanced Plus - 9 DLU
• Enhanced - 6 DLU
• Basic - 4 DLU
• Essential - 0 DLU
• Telepresence Room - 11 DLU

Na základě naší žádosti nám Cisco vytvoří migrovanou licenci. Dříve byl v LCU vidět přepočet licencí, takže se dala sestavit výše uvedená tabulka. Dnes to Cisco tají, ale konverze bude nějakým hodně podobným způsobem. Jelikož pro většinu situací potřebujeme Enhanced UCL licence (6 DLU) a dříve jsme pro většinu telefonů potřebovali 4 DLU, tak vidíme, že po konverzi potřebujeme o třetinu licencí více! Klasický přístup firmy Cisco.

Pozn.: Cisco asi nějakým způsobem přihlíží ke stavu u zákazníků. Já jsem měl téměř třetinu DLU volných, když bych použil výše uvedený přepočet, tak by mi pořád ještě 54 DLU chybělo. Cisco vystavilo novou licenci dokonce s malou rezervou 16 Enhanced UCL licence. Samozřejmě jsem pořád přišel o licenci pro spoustu telefonů (které jsme na počátku koupili pro budoucí rozvoj).