www.SAMURAJ-cz.com 

24.04.2024 Jiří Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Migrace CUCM z fyzického HW do VMware

Upraveno 30.01.2015 12:57 | vytvořeno 13.01.2015 16:09 | Samuraj - Petr Bouška |
V dnešní době již převažuje provozování virtuálních serverů nad přímým využitím fyzického serveru. Je to nejen z důvodů ekonomických, ale i větší spolehlivosti a lepších možností zálohování. Já používám virtualizaci již více než 8 let a poslední roky jsou téměř všechny servery virtuální. Proto jsem již delší dobu uvažoval o převodu Cisco UC na virtuální servery, ale dlouho to bylo slabší s Cisco podporou. V současnosti je již situace docela příznivá. Navíc fyzické server MCS, na kterých mi Cisco telefonie běžela, jsou již zastaralé a skončila jim podpora. V tomto článku se s vámi podělím o své zkušenosti z migrace CUCM do virtuálního prostředí VMware.

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.

Supported Servers for Releases of Cisco Unified Communications Manager (Including Business Edition 3000/5000/6000 and Session Manager Edition) and Cisco Intercompany Media Engine

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:

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.

Virtuálního prostředí v oddělené (izolované) síti

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.

CUCM migrace - install 1

Pokud není DNS server dostupný, tak celý test trvá 25 minut a pak máme možnost zvolit Ignore a pokračovat v instalaci.

CUCM migrace - install 2

Následuje nastavení času podle NTP serveru, ten musí být dostupný, jinak nemůžeme pokračovat v instalaci.

CUCM migrace - install 3

Jedinou možnost máme změnit adresu NTP server a testovat, jestli je dostupný.

CUCM migrace - install 4

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.

CUCM migrace - install subscriber

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.

CUCM migrace - Demo License

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í.

CUCM migrace - Invalid License

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.

zobrazeno: 7294krát | Komentáře [0]

Autor:

Související články:

Cisco Unified Communications - CUCM

Články z kategorie Cisco UC popisují obecně IP telefonii od Cisca. Hlavní zaměření je na ústřednu Cisco Unified Communications Manager (CUCM). Jiná kategorie se věnuje UCCX.

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

Zatím tento záznam nikdo nekomentoval.

Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách