Výchozím bodem jsou dva servery Cisco Unified Communications Manager (CUCM) 8.6.2.23900-10 = 8.6(2a)SU3, Publisheru a Subscriberu. Oba běžely na fyzickém serveru Cisco MCS 7825 H3 (HP7825H3), což je HP Proliant DL320 G5. Tomuto serveru již skončila podpora (End of Life), takže jasné řešení byl převod do virtuálního prostředí na VMware. Kde se dá uvažovat i o dalších upgradech na aktuální verzi CUCM 10.5.
Informace o podpoře, kompatibilitě apod.
Server Cisco MCS 7825 H3 je podporován pro software až do verze CUCM 9.x, musí ale mít 4GB RAM a minimálně 160 GB velké disky.
Serveru Cisco MCS 7825 H3 skončila podpora 30. 6. 2014.
End-of-Sale and End-of-Life Announcement for the Cisco MCS 7825-H3 Media Convergence Server
Podpora virtuálních serverů VMware pro CUCM. Verze CUCM 8.6(x) je podporována na VMware vSphere ESXi 4.0 U1, 4.1, 5.0, 5.1. Požadavek je fyzický server s procesorem Intel Xeon a minimálně 2 vCPU, 4 GB vRAM, 1x 80 GB vDisk, 1x vNIC. Verze CUCM 10.x je podporována na VMware vSphere ESXi 4.0 U4, 4.1 U2, 5.0 U1, 5.1, 5.5.
Virtualization for Cisco Unified Communications Manager (CUCM)
Unified Communications in a Virtualized Environment
Podrobnější požadavky na virtualizaci jsou popsány v Unified Communications VMware Requirements, UC Virtualization Supported Hardware.
Možnosti upgradů verzí uvádí dokument Cisco Unified Communications Manager Software Compatibility Matrix.
Migrace do virtuálního prostředí
Migraci můžeme provést několika způsoby a různě ji spojit s upgradem na vyšší verzi. Hlavní možnosti jsou
- čistá instalace a obnova ze zálohy
- využití Cisco Prime Collaboration Deployment (PCD)
Zde se budeme věnovat první možnosti, takže pouze zmínka o PCD. Jedná se o virtuální stroj, který získáme zdarma spolu s instalačním media kitem pro CUCM 10. Umožňuje provádět řadu úloh, včetně migrace z fyzického prostředí do virtuálního, čisté instalace, aktualizace, apod. Základní info Simplifying CUCM Upgrade and Migration Tasks Using Cisco PCD - Prime Collaboration Deployment, více v oficiální dokumentaci Cisco Prime Collaboration Deployment Administration Guide, Release 10.5(1).
Pozn.: Instalační/upgradovací DVD nemůžeme přímo stáhnout z Cisco download, ale pokud máme zaplacenu odpovídající podporu, tak o něj můžeme požádat na Product Upgrade Tool (PUT).
Oficiální materiály, které se týkají migrace:
- Release Notes for Cisco Unified Communications Manager Release 8.6(2a)
- Installing Cisco Unified Communications Manager Release 8.6(1)
- Disaster Recovery System Administration Guide for Release 8.6(1)
- Cisco Unified Communications Manager 9.1 Migration and Upgrade Guide
Proces migrace
Možnost, kterou zde využijeme, spočívá v přípravě celého virtuálního prostředí v oddělené (izolované) síti a pak v jeden okamžik vypneme fyzické servery a síťově přepojíme nové prostředí.
Izolovanou sít vytvoříme na VMware vSphere snadno, třeba jako samostatný (nepřipojený) virtuální switch. Ale může se nám hodit vytvořit si speciální izolovanou VLAN, do které můžeme při testování zapojit fyzické telefony a jednoduše ověřovat funkčnost. Do izolované sítě umístíme připravované UC servery. Budeme ale potřebovat ještě nějakou pomocnou infrastrukturu. Při instalaci musíme použít stejné adresy (a vůbec vše stejné) jako v provozním prostředí a některé věci si CUCM při instalaci kontroluje (hlavně NTP).
Já jsem využil jeden malý Linuxový server, který sloužil jako NTP server, ale protože ten má adresu v jiném subnetu než UC servery, tak také sloužil jako router (i když routoval pouze sám na sebe). Další služba, kterou na něm můžeme použít, je DNS (i když ověřování komunikace na DNS můžeme při instalaci ignorovat). Až UC servery nainstalujeme, tak na ně budeme obnovovat zálohu. Proto potřebujeme přístup na webové rozhraní a SFTP server. Já jsem využil druhý virtuální stroj s Windows, ale vystačili bychom i s tím Linuxem, který již máme.
Na Linux serveru musíme zapnout routování, může stačit jednoduchý zásah.
echo 1 > /proc/sys/net/ipv4/ip_forward
Pokud NTP server nemá dostupný synchronizační zdroj, tak po chvíli přestane poskytovat čas. Řešením je nastavit, aby se synchronizoval sám se sebou. Využívá se na to speciální adresa (nikoliv jeho vlastní) 127.127.1.0
.
vi /etc/ntp.conf server 127.127.1.0 # local clock
Celý proces migrace vypadá stručně takto:
- příprava virtuálního prostředí s izolovanou sítí a pomocných strojů
- kontrola CUCM (že je jeho stav OK, není chyba v replikacích, apod.) a ověření, že máme aktuální zálohu (nebo provedení manuální zálohy), od doby zálohy se nesmí provádět změny konfigurace
- vytvoření virtuálních strojů z OVA šablony a čistá instalace se stejnými hodnotami jako mají provozní servery
- obnova zálohy
- přesun (rehost) licence pro novou licenční MAC
- vypnutí fyzického prostředí a přepojení virtuálního
Pozn.: V průběhu je dobré vytvářet Snapshoty, abychom se v různých případech mohli vrátit o krok zpět.
Pozn.: Zde je popisována konfigurace s clusterem dvou CUCM. Mohli bychom připravit pouze Publisher a Subscriber dodatečně čistě nainstalovat a nechat zreplikovat. Ale asi bychom narazili na problémy s funkcionalitou Security By Default (SBD), což v praxi znamená soubory ITL (Identity Trust List). Proto jsem zvolil instalaci obou serverů a následnou obnovu dat na oba. Narazil jsem i na popis u Cisca, kde doporučují tento postup. SBD popisuje článek CUCM Security By Default and ITL Operation and Troubleshooting.
Instalace CUCM Publisher
Z Cisco download stáhneme OVA template (dle verze VMware) cucm_8.6_vmv8_v1.5.ova
a z něj vytvoříme virtuální stroj. Při vytváření volíme verzi (nastaví HW parametry) dle počtu uživatelů, verze pro 2500 uživatelů má v šabloně pouze 1 vCPU, ale doporučuje se změnit na 2.
Pozn.: Cisco doporučuje, pokud plánujeme provést v budoucnu upgrade (což asi může nastat vždy), tak použít rovnou OVA šablonu pro cílovou verzi (v podstatě nejnovější, která je k dispozici), v současnosti jde o cucm_10.5_vmv8_v1.8.ova
.
Průběh standardní instalace mapuje v obrázcích článek CUCM 8.6 instalace Publisheru. Do virtuální mechaniky připojíme instalační ISO, já jsem použil Bootable_UCSInstall_UCOS_8.6.2.20000-2.sgn.iso
. A započneme instalaci, kdy v průvodci vyplníme údaje o serveru. Je důležité, aby byly naprosto stejné, jako u stávajícího serveru, který chceme migrovat. Na stávajícím serveru můžeme, pomocí CLI, vygenerovat XML soubor, který obsahuje aktuální konfiguraci.
utils create report platform
Po té, co vyplníme všechny údaje pro instalaci, tak se naformátuje disk a nainstaluje OS. Další krok je Checking Network Connectivity, kde se kontroluje dostupnost DNS.
Pokud není DNS server dostupný, tak celý test trvá 25 minut a pak máme možnost zvolit Ignore a pokračovat v instalaci.
Následuje nastavení času podle NTP serveru, ten musí být dostupný, jinak nemůžeme pokračovat v instalaci.
Jedinou možnost máme změnit adresu NTP server a testovat, jestli je dostupný.
Instalace CUCM Subscriber
Pokud máme cluster, tak potřebujeme nainstalovat i Subscriber. Obrázky z průběhu instalace obsahuje článek CUCM 8.6 instalace Subscriberu. Instalace probíhá podobně jako u Publisheru, ale v průběhu zadávání údajů odpovíme na dotaz, zda jde o první server clusteru, záporně. Pak zadáme údaje o Publisheru (Host Name, IP adresa, Security heslo) a provádí se jeho test. Kontroluje se verze, instalovaná verze musí být přesně stejná, jako je na Publisheru (není možné nainstalovat nižší a pak udělat upgrade). Dále se kontroluje, jestli konfigurace Publisheru obsahuje záznam o tomto Subscriberu.
Takový záznam můžeme lehce doplnit na Publisheru v Cisco Unified CM Administration - System - Server.
Upgrade na potřebnou verzi
Protože já mám provozní servery na vyšší verzi, než pro jakou jsem měl instalační ISO, tak hned po nainstalování obou serverů jsem provedl upgrade na správnou verzi. Nejprve je dobré ověřit, že fungují správně replikace (a tedy vlastní cluster), pomocí CLI příkazu:
utils dbreplication runtimestate
Poté se provede upgrade Publisheru, následně Subscriberu. K virtuálu jsem připojil ISO UCSInstall_UCOS_8.6.2.23900-10.sgn.iso
. Pomocí Windows stanice jsem otevřel webové rozhraní Cisco Unified OS Administration a provedl upgrade z DVD/CD (upgrade můžeme provést i pomocí CLI). Upgrade popisuje článek CUCM proces standardního upgradu. Ve virtuálu proběhlo povýšení verze o něco rychleji než v článku (vlastní upgrade Publisheru 1 hodina 18 minut, zvolil jsem automatické přepnutí verze, restart trval 15 minut, pak jsem pokračoval Subscriberem).
Po přihlášení do webového rozhraní Cisco Unified CM Administration vidíme, že máme čistě nainstalovaný CUCM server, který používá Demo licenci. Systém také detekuje, že běží ve virtuálním prostředí a zobrazuje informace o HW prostředcích.
Pozn.: Až dodatečně mi jeden člověk poradil velmi zajímavou věc. Žil jsem v představě, že ISO obrazy, které jsou určeny pro instalaci, jsou bootovací a název souboru začíná slovem Bootable_
, jsou obsahově odlišné od upgradovacích ISO. Ale prakticky je prý jediný rozdíl, že instalační ISO obsahuje boot sektor. Přitom upgradovací ISO můžeme stahovat z Cisco Downloads, ale instalační ne, takže přibývají komplikace. Přidání boot sektoru k upgradovacímu disku není velký problém a potřebný boot file se nachází přímo v každém obrazu v \isolinux\isolinux.bin
. Přidání je možné provést pomocí programu UltraISO. Popis v článku Make a non-bootable ISO image bootable. Pokud používáme ISO pro upgrade, tak v názvu nesmí být Bootable_
, jinak jej systém nenalezne.
Problém se zálohou - Backup
Nyní potřebujeme mít kompletní zálohu (Disaster Recovery System (DRS) backup). Při této příležitosti jsem zjistil, že sice zálohy mám, ale nekompletní. Při každé záloze došlo k chybě, takže se uložila pouze část. Vidím jako nedostatek, že CUCM neumí o průběhu zálohy zaslat například kontrolní email. Pro kontrolu zálohy používám skript, který ověřuje, že se v době zálohy nahrála nová data, což se ukazuje nedostatečné.
Zkusil jsem zálohu spustit manuálně a dostal jsem chybu:
ERROR: SFTP transfer failed as backup size was not increasing for the past 15 minutes. Either there is not enough disk space or network transfer rate is too slow with the configured SFTP Server. Please either free some space on SFTP device or check network connectivity and then run a fresh backup, Backup Completed.
Na internetu jsem našel řadu diskuzí, kde se tento problém řeší. Uvádí se, že jde o oficiální bug, který je na verzi CUCM 8.6. Jde o to, že pokud je SFTP server na Windows, tak se při kopírování velkého souboru (TFTP) neaktualizuje údaj o velikosti. CUCM má interval 15 minut a pokud nevidí změnu, tak si myslí, že se nekopíruje. Řešením je aktualizovat tuto informaci ručně, to můžeme provést například pomocí
dir /R
Což můžeme vložit do naplánované úlohy. Nebo použít SFTP na Linuxu. Problém lidé popisují na Windows 7 a Windows Server 2008, já jsem na něj narazil na Windows 8.1 a Windows Server 2012. Zajímavé je, že od té doby, co se mi jednou podařilo zálohu provést, již další probíhaly bez chyby. Tento problém se popisuje třeba v diskusích CUCM 8.6 backup SFTP timeout issue, DRS back up fails.
Ověřit, že je tento problém u nás, můžeme tak, že se na serveru, kam kopírujeme zálohu, přepneme do složky s daty. Spustíme zálohování a několikrát si pomocí dir
vypíšeme obsah složky a vidíme, že velikost souboru je stále 0. Zkusíme dvakrát dir /R
a vidíme, že se zvětšila. Když to uděláme několikrát, tak navíc celá záloha proběhne do konce.
Obnova zálohy - Restore
Pro obnovu potřebujeme SFTP server, já jsem použil freeFTPd, který jsem nainstaloval na servisní stroj s Windows. Také potřebujeme dostat zálohovaná data na tuto stanici, která je v izolované síti. Jedna z možností je vytvořit ISO soubor a ten připojit do virtuální mechaniky. Pro vytvoření ISO jsem využil aplikaci IsoCreator. Proces obnovy zálohy jsem popisoval v článku CUCM obnova clusteru ze zálohy - Disaster Recovery a částečně v CUCM 8.5 Publisher - kompletní Disaster Recovery.
Obnova se provádí přes webové rozhraní CUCM - Disaster Recovery System. Nejprve musíme definovat Backup Device, což je SFTP server na naší stanici, menu Backup - Backup Device.
Poté zahájíme obnovu pomocí průvodce Restore - Restore Wizard. Zvolíme náš server (freeFTPd defaultně používá jako root nastavenou složku / jméno uživatele), nabídnou se nalezené zálohy, volíme vlastnosti, které chceme obnovit. Poslední krok je zvolit servery, které chceme obnovit, kde zvolíme oba členy našeho clusteru.
Obnoví se Publisher (asi za 23 minut) a hned se pokračuje obnovou Subscriberu (dalších cca 15 minut). Následně je třeba provést restart. Důležité je, že se nejprve restartuje Subscriber a teprve když kompletně naběhne (u mne 7 minut), tak se restartuje Publisher.
Pozn.: Stalo se mi, že po obnově a připojení telefonu, nebylo pár položek v češtině. Pár pokusů ověřilo, že jedna možnost byla, vrátit se ke Snapshotu před obnovou, nainstalovat aktuální Locale soubor a znovu provést obnovu. Pak již bylo vše OK. Instalace Locale se může provést i po obnově, ale server musí být správně zalicencovaný, pokud běží Grace Period, tak nelze instalovat.
Po nastartování Publisheru se provádí replikace dat, kterou můžeme opět kontrolovat z příkazové řádky.
utils dbreplication runtimestate
Čekáme, dokud nebudou oba servery ve stavu 2 - Good
. Jako další krok je dobré ověřit ITL (důležité je, aby se ze zálohy správně obnovily certifikáty CallManager.pem
a TVS.pem
). Různé problémy popisuje článek CUCM Security By Default and ITL Operation and Troubleshooting. Kontrolu provedeme opět pomocí CLI příkazu
show itl
Výstup by měl obsahovat několik záznamů a na konci:
The ITL file was verified successfully.
Ověření funkčnosti
Pokud jsme izolovanou síť vytvořili jako speciální VLAN v síti, tak můžeme do této sítě připojit dva Cisco IP Phone a ověřit, že se v pořádku zaregistrují a mohou vzájemně uskutečňovat hovory.
Pozn.: Můžeme potřebovat na telefonu změnit nastavení z DHCP na ručně zadanou adresu. Na telefonu v konfiguraci sítě musíme nejprve odemknout možnost měnit hodnoty pomocí **#
Získání licence
Po obnovení zálohy systém detekuje, že má neplatnou licenci. Máme 30 dní (grace period) na nahrání korektní licence, jinak se služby Call Manageru zastaví.
Pro vytvoření licenčního souboru se u fyzických serverů používala MAC adresa. Ve virtuálním prostředí se licenční MAC začala skládat z řady hodnot. Jde o Time Zone, NTP Server 1, NIC Speed, NIC Duplex, Host Name, IP Address a IP Mask a Gateway Address a Primary DNS nebo DHCP, SMTP server a údaje o certifikátu. Informace uvádí například kapitola Customer Impact from New Licensing Procedures.
Takto vygenerovanou licenční MAC si můžeme zobrazit na nainstalovaném serveru nebo ji můžeme připravit dopředu pomocí webové stránky Online Answer File Generator. Zde zadáme instalační údaje a vygeneruje se nám odpovědní XML soubor, který můžeme použít pro bezobslužnou instalaci. Pokud zvolíme, že instalace je do virtuálního prostředí, tak se nám také vygeneruje licenční MAC.
Na nainstalovaném serveru můžeme využít CLI a získat licenční MAC.
admin:show status Host Name : cucm Date : Thu Dec 18, 2014 13:55:23 Time Zone : Central European Time (Europe/Prague) Locale : en_US.UTF-8 Product Ver : 8.6.2.23900-10 OS Ver : 5.0.0.0-2 License MAC : d5581ae3cd85
Druhá možnost (na virtuálním serveru) je webové rozhraní CUCM - Cisco Unified OS Administration - Show - System. Zde vidíme stejné údaje jako v CLI.
Poté můžeme na Cisco stránce Product License Registration zadat žádost o Rehost licence. Proces přesunu licence se asi v čase mění, protože někde dokumentace uvádí, že se žádá pomocí případu na licenční tým. Jinde, že se na licenční stránce má nacházet menu Transfer - License for Rehost-initiate. Nyní máme v sekci Manage záložku Licenses nebo Devices, když se zvolí licence, tak je možné v menu Actions zvolit Rehost/Transfer. Zadáme licenční MAC, volíme licenci do virtuálního prostředí a vložíme svůj email.
Na úvodní stránce licenčního portálu si můžeme přehrát video o procesu rehost licence. Někteří se pro přesun licence musí obrátit na svého dodavatele.
Po té, co získáme licenční soubor, jej jednoduše nahrajeme na CUCM Publisher. Můžeme využít webové rozhraní CUCM - Cisco Unified CM Administration - System - Licensing - License File Upload pomocí tlačítka Upload License File. Je doporučeno provést restart, ale v praxi vše funguje i bez něj.
Zatím zde nejsou žádné komentáře.