O autorovi:
Petrův web jsem nepravidelně navštěvoval jako čtenář a jednoho dne se rozhodl jej oslovit s nabídkou přispívání. Po pár e-mailech a osobním setkání jsme se domluvili na spolupráci…

Jmenuji se Lukáš Pečenka a věnuji se Unified Communications, zejména od společnosti Cisco. Cílem je publikovat o tématech z oblasti IP telefonie, videokonferenčních systémů a kolaborace na která se na českých webech obvykle nenaráží.

Můžete mne kontaktovat na e-mailu lukas.pecenka@gmail.com

Fáze plánování

Je to časově dost náročná varianta a znamená totální výpadek provozu IP telefonie na několik hodin. Ciscem doporučovaný postup je následující:

• Nahrát soubory a spustit upgrade proces na publisheru a po jeho restartu provést to samé na subscriberech
• Po restartu všech nodů počkat na správný status replikace databáze a udělat zálohu pomocí DRS
• Po úspěšném odzálohování odpojit stávající HW z provozu a začít instalovat CUCM na novém HW se stejnými IP adresami
• Po rozjetí nového clusteru s původními IP obnovit ze zálohy postupně všechny nody

Co je nutné zkontrolovat:

• Že Váš HW skutečně nepodporuje Vámi vybranou novou verzi CUCM v dokumentu Supported Servers for Releases of Cisco Unified Communications Manager. V řádcích jsou jednotlivé modely HW, ve sloupcích verze CUCM. Je-li Váš HW podporován, najdete v příslušném políčku X – existuje-li nějaké omezení, je za písmenem X v závorce číslo. Vysvětlení s číslem je pod tabulkou. Bridge upgrade je označen písmenem B a nějakým číslem v závorce.
• Že Vaše aktuální verze CUCM je přímo upgradovatelná na cílovou verzi v dokumentu Cisco Unified Communications Manager Software Compatibility Matrix

Nad rámec toho doporučuji mít sjednocené verze firmware IP telefonů, aby se minimalizovala zátěž TFTP serverů při přeregistraci telefonů.

Zní to celkem jednoduše a nijak pracně, skutečnosti je ale trochu jiná. Můj cluster sestává z publisheru a dvou subscriberů. Z hlediska HW se jednalo o HP ekvivalenty MCS-7845-h3 na kterých jsem dlouhou dobu provozoval CUCM 6.1.2, pak upgradoval standardní cestou na 7.1.3 a poté přišlo rozhodnutí přejít na 8.6.2. Ta už však není na tomto HW podporovaná a jediná cesta jak zmigrovat databázi byl bridge upgrade.

Jako nový hardware jsem nakonec zvolil virtualizační platformu Cisco UCS C-series, konkrétně model C210M2-VCD2 a hypervisor VMWARE ESXi 4.1. Z původních 3 serverů jsem se dostal na 2, každý s podporovanými 4 virtuálními instancemi. Samozřejmě, pokud neuděláte oversubscription na zdroje (RAM, cores, CPU, apod.), můžete jich provozovat daleko víc – Cisco je ale zatím alibistické a tak jsou na tomto HW podporované jen 4 a ještě omezení že se může jednat jen o Unified Communications produkty. V případě porušení těchto pravidel Vám může TAC odmítnout spolupráci při řešení problémů. Důvody pro virtualizaci byly dva. Jednak je to cesta, kterou se Cisco ubírá s UC a má velký potenciál, a druhak můžete mít na stejném železe labové prostředí pro testování (v poslední době se mi v labu kupily starší servery, které už pro nové verze CUCM nelze použít, protože jsou buď malé disky, nebo není vhodný procesor a dostatek RAM apod.).

Fáze příprava

Jak už jsem zmínil, je tento druh upgrade časově náročný a obnáší dlouhé výpadky vlastního provozu. Z tohoto důvodu jsem se domluvil s kolegy z WAN a nechal si vybudovat dočasnou separátní VPN v naší MPLS síti, která mi umožnila předinstalovat si nový cluster se stejnými adresami dopředu, nainstalovat locale (pro uživatele i pro telefony) apod. A v momentě odpojení starého HW jen přehodit VLAN na síťových kartách virtuálních strojů. Samozřejmě toto lze udělat na produkční síti s jinými adresami a pak přeadresovat po odstavení starého železa, ale jsem zastánce toho, že čím méně readresací takto složitého systému, tím lépe.

Dalším důvodem pro separátní VPN bylo, že virtualizované produkty UC skládají license MAC z parametrů Time zone, NTP server 1 (or none), NIC speed (or auto), Hostname, IP Address (or dhcp), IP Mask (or dhcp), Gateway Address (or dhcp), Primary DNS (or dhcp), SMTP server (or none), Certificate Information (Organization, Unit, Location, State, Country) a já chtěl mít licenci pro CUCM v ruce v předstihu. Opět, license MAC se dá nasimulovat pomocí Answer File Generator toolu, ale Murphyho zákony fungují a jako na potvoru by člověk uprostřed víkendu zůstal viset na tom, že nemá licenci pro SW a nenastartuje callmanager proces. Tato varianta přípravy samozřejmě znamená, že do separátní uzavřené VPN musíte dostat další stroj, který zajistí DNS, NTP a SMTP – tedy služby, které si CUCM nody osahávají při instalaci. Toto se dá ale rychle postavit na linuxu.

Já přecházel ze 7.1.3 na 8.6.2 takže bylo nutné přes PUT (Product Update Tool) požádat o upgrade. Ve finále, v případě eDelivery obdržíte mj. PDF s PAK číslem, na jehož základě vygenerujete SW licenci pro CUCM 8.x. A zároveň bylo nutné rehostovat DLU licence kvůli změně license MAC. Toto bylo kupodivu velmi rychle zprocesováno na základě e-mailu na licensing@cisco.com s uvedením důvodu, kontaktních informací, staré licence a samozřejmě číslem platného kontraktu.

Vše připraveno, jdeme na to

Vlastní upgrade jednoho HW serveru trval cca 80 minut (plus samozřejmě čas, než přes FTP, či SFTP nahrajete upgrade ISO na server - v mém případě mělo ISO přes 4 GB). Doporučuji u serveru buď sedět, nebo mít alespoň iLO (HP) či IMM (IBM), protože se po určité fázi upgrade restartuje a dlouhou dobu chroupe bez možnosti dostat se na něj přes web, či SSH.

Před započetím prací si udělejte v Disaster Recovery System zálohu pro případ kdyby se něco nepovedlo (pokud používáte servery s jedním RAIDem, nebudete mít po upgrade možnost vrátit se zpět pouhým přepnutím verzí – recovery by se muselo dělat novou instalací původní verze CUCM a poté obnovení ze zálohy před upgrade). Záloha trvá podle velikosti databáze a počtu TFTP serverů v clusteru. Mých 2,5GB verze 7.1.3 o dvou TFTP serverech zabralo cca 60 minut.

Zastavte v Unified Serviceability proces Cisco Extension Mobility na všech nodech, kde běží.

Já preferuji upgrady z CLI (přijde mi to rychlejší), ale postup se dá samozřejmě provést i z webu.

Upgrade CUCM Publisheru z 7.1.3 na 8.6.2

Před upgrade si nahrajte na FTP nebo SFTP server ISO s upgradem a také budete potřebovat soubor cop.sgn s názvem ciscocm.refresh_upgrade_v1.1 (verze souboru se mohou lišit – doporučuji použít ten, který je zmíněný v release notes verze na kterou se chystáte přejít), který zajistí přípravu cest pro aktualizaci.

Nalogujte se pomocí SSH na server a spusťte upgrade pomocí příkazu utils system upgrade initiate. Vyberte volbu Remote Filesystem a zadejte cestu spolu s přihlašovacími údaji k Vašemu FTP / SFTP serveru.

Po instalaci refresh upgrade balíku je server restartován.

Po restartu opět spustíme upgrade pomocí utils system upgrade initiate, vyplníme nutné údaje pro přístup k ISO souboru a po stažení a validaci spustíme vlastní upgrade.

U publisheru jsem raději nenechal automaticky přepnout verzi. Po upgrade se server stejně sám restartuje (ale s původní verzí).

Po restartu dostanete zprávu o limitováné funkcionalitě

A v mém případě bylo tedy potřeba verze přepnout pomocí utils system switch-version

Upgrade CUCM Subscriberu z 7.1.3 na 8.6.2

Stejný postup, refresh balíček, restart, vlastní upgrade, restart, je potřeba provést i na subscriberech. Jelikož mi callmanager služba běží na všech 3 nodech, nedělal jsem oba subscribery najednou, abych zkrátil dobu výpadku. Po upgrade posledního (v mém případě druhého) subscriberu nastává kompletní výpadek. Telefony se buď přiregistrují k SRST, nebo nefungují vůbec (v závislosti na konkrétním nasazení).

Po restartu posledního serveru jsem několik minut počkal a poté na publisheru zkontroloval příkazem utils dbreplication runtimestate stav replikace databáze po upgrade. Status u každého nodu musí mít hodnotu 2.

Záloha CUCM

Nyní se nalogujeme do Disaster Recovery System a uděláme zálohu (zde předpokládám, že máte nadefinované backup jednotky).

Z nabídnutých features jsem vybral všechny, i když jsem nechápal proč tam je UCM i CCM…

Backup zabral cca 60 minut. Po jeho dokončení jsem administrativně shodil porty na switchích vedoucích ke starému HW a změnil VLANy na síťovkách virtuálních serverů nového clusteru. Základní instalaci a konfiguraci VMWARE hypervisoru a instalaci CUCM ve virtualizovaném prostředí z OVA template si popíšeme v některém z dalších článků.

Obnova zálohy na nových serverech

V momentě uvádění nového virtualizovaného clusteru do provozu jsem měl zastavené všechny služby na všech nodech v Unified Serviceability! Opět jsem si počkal a ověřil, až si nově nainstalovaný cluster sesynchronizuje databázi pomocí utils dbreplication runtimestate. Je to vlastně jen kontrola protože změnou VLAN došlo k rozpadu komunikace.

Nyní se nalogujeme do nového publisheru do Disaster Recovery System a vytvoříme novou backup device směřující na stejný SFTP server, kde na nás čeká záloha databáze z původního železa.

Obecně pokud upgradujete z CUCM 7.1 a nižší na CUCM 8.x, buďtě obezřetní a nezmatkujte protože s příchodem CUCM 8.0 je v systému funkcionalita Security By Default (SBD), která krom jiného nativně, bez možnosti vypnutí, šifruje konfigurační soubory pro IP telefony novějších řad (např. 7911, 7942/62 ad.) a tyto se ověřují pomocí certifikátů. IP telefon si při prvním kontaktu s CUCM 8.x (uvažujme přechod z CUCM 7.1, kde se ITL nevyskytují) stáhne ITL (Identity Trust List) soubor ve kterém jsou relevantní údaje o serverech se kterými má komunikovat. Následně si z TFTP vyžádá podepsaný konfigurační soubor a klíče zpětně ověřuje u callmanagerovské služby TVS (Trust Verification Service). Princip fungování SBD je moc hezky rozebrán v článku Phone Contacts Trust Verification Service for Unknown Certificate.

Pokud v recovery uděláte chybu (a že postup v release notes není úplně dobře popsaný), můžete se dostat do stavu kdy se Vám telefony zaregistrují jen k jednomu nodu a víc s nimi nehnete dokud nějakým způsobem nesmažete ITL soubor.

Vlastní recovery by se měla provádět tak, že první uděláte pouze publisher (features UCM a CDR_CAR) a po jeho restartu pokračujete se subscribery.

Po recovery publisheru (cca 100 minut) jsem jej restartoval a pokračoval s recovery subscriberů. Tedy chtěl jsem, ale při zaškrtání UCM a CCM features obou subscriberů jsem dostával hlášku že recovery nemůže najít deployment type a restore tedy nelze dokončit.

Na žádném fóru ani videu jsem nenašel odpověď, proč jsou v recovery na výběr CCM a UCM features, takže jsem dospěl k rozhodnutí že recovery publisheru stačí. Počkal jsem, až se sesynchronizují databáze a začal spouštět služby na jednotlivých nodech. A to byla chyba, protože jeden ze subscriberů je druhým TFTP serverem a díky SBD se nepropsaly certifikáty. Zpočátku vše vypadalo OK, registrujících se telefonů přibývalo, všechny služby jely. Podivné bylo to, že telefony novějšího typu byly registrované jen k publisheru (můj první TFTP server) a odmítaly se naregistrovat k subscriberům dle pořadí CM Group v Device poolech. Začalo několikahodinové pátrání po chybě se špatným výsledkem, v ITL nejsou konzistentní údaje a proto to nejede.

Před uváděním virtualizovaného clusteru do provozu jsem si udělal ve vSphere snapshot, z něj jsem obnovil servery do čistého stavu a jal se zkusit recovery ještě jednou. Tentokrát všeho naráz, publisheru i obou subscriberů. Zaškrtal jsem ale pouze CDR_CAR a UCM features. Vyvodil jsem si, že CCM feature bude nějaký pozůstatek po CUCM 6.1, která na původních HW serverech také běžela. Teď už recovery dopadlo (trvalo to skoro 3 hodiny) a výpis show itl v konzoli ukazoval, že je vše v pořádku. Jenže jak si IP telefony jednou stáhnou ITL soubor a nedostanou update z důvěryhodného zdroje, je konec. V mém případě byly postižené IP telefony přiregistrované alespoň k publisheru a umožňovaly řízení pomocí CTI, takže se mi za pomocí software PhoneView od Britských UnifiedFX podařilo dálkově vymazat ITL soubory a uvést vše do funkčního stavu. Můžete se ale dostat i do stavu, kdy Vám nezbude než všechno obejít a ITL vymazat ručně. Takže opatrně a s rozmyslem.