www.SAMURAJ-cz.com 

25.04.2024 Marek Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

CUCM 8.5 upgrade na verzi 8.6 a řešení chyb

Středa, 22.02.2012 14:41 | Samuraj - Petr Bouška |
Prováděl jsem upgrade Cisco Unified Communications Manager (CUCM) na trochu vyšší verzi, abych se zbavil jednoho bugu, a narazil jsem na spoustu problémů. Vedlo to až k tomu, že jsem musel provést Disaster Recovery (DR), kterou popíšu v dalším článku. Přitom na CUCM 6 jsem provedl mnoho upgradů a vždy šlo o bezproblémovou situaci. Takže zde jsou sepsány moje postřehy z upgradu.

S tímto článkem úzce souvisí další dva, které popisují operace, které jsem musel provést, když mi upgrade CUCM selhal. Jde o CUCM 8.5 Publisher - kompletní Disaster Recovery a CUCM 8.6 instalace Subscriberu.

Moje prostředí CUCM

Moje situace byla taková, že jsem zkusil upgrade Publisheru, ten skončil chybou. Provedl jsem kompletní obnovu clusteru postupem DR. A znovu zkusil upgrade, který tentokrát prošel. Pokračoval jsem upgradem Subscriberu a ten skončil stejnou chybou jako prve Publisher. Takže jsem provedl čistou instalaci Subscriberu do existujícího clusteru a tím jsem se konečně dostal k finálnímu stavu (dodatečně jsem se dozvěděl, že toto je striktně nedoporučeno, má se provádět upgrade všech členů clusteru!).

Výchozí verze byla CUCM 8.5.1.11900-21, při prvním upgradu, který selhal, jsem použil verzi 8.6.1.20000-1 (nebootovací ISO). Podruhé 8.6.2.20000-2 (vypálené bootovací DVD), to ne z nějakého specifického důvodu, ale protože jsem ji měl k dispozici. V síti mám Publisher a jeden Subscriber oba běží na HW serveru HP7825H3, což je HP Proliant DL320 G5. Původně zde byla verze CUCM 6, která se upgradovala na verzi 8.5. Servery mají dva zrcadlené disky 160GB, které byly při první instalaci rozděleny na dvě partition o velikosti 30GB (plus partition pro logy). Instalace 8.6 je přerozdělila na dvakrát 37GB (a logy 75GB). Při druhém pokusu o upgrade jsem pro jistotu vyměnil disky za 500GB a instalovala se čistě verze 8, která si vytvořila dvě partition 120GB (a zbytek logy).

Refresh upgrade s USB diskem

S upgradem na verzi 8.6 je zásadní problém, že na mém HW serveru je potřeba provést Refresh upgrade. To znamená, že se na disku vytvoří nové partition a provede se kompletní formát. Takže není možný návrat k předchozí verzi, která je uložena na neaktivní partition, jak je jinak běžné. Navíc je potřeba k serveru připojit minimálně 16GB velký USB disk (či flashku), kam se provede zkopírování instalace a dat ze serveru. Provádí se pak vlastně čistá instalace, kdy nemusíme zadávat žádné údaje. Celý proces trvá dlouho, mě trval více než tři hodiny, a potřebuje několikrát rebootovat server. Navíc mi server nenastartoval, pokud jsem měl připojen USB disk.

Upgrade CUCM z 8.5 na 8.6
This is a Refresh Upgrade. Refresh Upgrades require an extended service  outage and multiple reboots. Please refer 
to the Software Upgrades section of  the Cisco Unified Communications Administration Guide for more information.

This server model  requires a USB storage device in order to proceed with the upgrade. Please insert a USB storage 
device with at least 16GBytes of capacity. Note that any  existing data on the USB device will be deleted.

This Refresh Upgrade will COMPLETELY REFORMAT YOUR SERVER. Reverting to  your current version following the Refresh 
Upgrade will require a reinstall and  restore. You must have a valid backup.

Uvádí se, že USB disk je potřeba proto, že na disku není dostatek místa. Ale i když jsem měl 500GB disky a 80GB partition, tak to nepomohlo. Stejně se prováděl Refresh upgrade, testování je patrně podle HW serveru. Jako USB disk jsem použil flashdisk Kingston 32GB.

Důležitá poznámka je, že pro upgrade na 8.6 musíme mít v serveru minimálně 160GB disky (a možná, že ani ty mu nestačí, protože upgrade na nich vždy selhal, ale čistá instalace prošla). Celá instalace trvá několik hodin, takže je potřeba vyhradit dostatek času. Při velké části instalace je nedostupný instalovaný Publisher, takže sice telefony mohou běžet na Subscriberu, který ovšem dokáže provozovat omezený počet funkcí, lepší je naplánovat odstávku telefonie.

Upgrade Publisheru

Oficiální popis upgradu je v článku Release Notes for Cisco Unified Communications Manager Release 8.6(2a). Také je dobré zkontrolovat, že můžeme provést daný upgrade z naší verze v Cisco Unified Communications Manager Software Compatibility Matrix. K dispozici jsou verze upgradu Restricted, které obsahují šifrovací algoritmy a nesmí se vyvážet do některých zemí světa, a Unrestricted, které se mohou použít všude, protože neobsahují dané algoritmy.

Instalace provádíme přes webové rozhraní CUCM – Cisco Unified OS Administration – Software Upgrade – Install/Upgrade. Nejprve musíme upgradovat Publisher, pak teprve Subscriber. Stručný popis kroků:

  • nejprve si určitě zkontrolujeme, že máme zálohu!
  • v dokumentaci se dočteme, že nejprve musíme nainstalovat update ciscocm.refresh_upgrade_v1.0.cop.sgn, nevím, proč se nemůže nainstalovat automaticky s upgradem, v nastavení upgradu pak přibude možnost nastavit SMTP server a adresu, kam se posílá info o průběhu upgradu (ale při instalaci malého upgradu stejně žádné maily neposílá), pokud soubor nemáme nainstalovaný, tak by se upgrade měl zastavit v první fázi s informací
Upgrade CUCM z 8.5 na 8.6
  • obecně se má při upgrade vypnout služba Extension Mobility (dříve jsem to nedělal, ale nyní radši ano), Cisco Unified Serviceability - Tools - Service Activation
  • připojíme k serveru USB disk
  • prvně jsem prováděl upgrade přes FTP ze souboru UCSInstall_UCOS_8.6.1.20000-1.sgn.iso, podruhé jsem měl bootovací verzi vypálenou na DVD UCSInstall_UCOS_8.6.2.20000-2.sgn.iso
Upgrade CUCM z 8.5 na 8.6
  • první část instalace (ve webovém rozhraní) trvala hodinu, kontrolovaly se instalační soubory, připravovala se instalace, připravil se USB disk s Ext3, kopírovaly se instalační soubory, exportovali se informace z aktuálního systému a spouštěli další skripty
  • pokud si to nastavíme, tak upgrade posílá emaily, první přišel po 48 minutách od začátku upgradu, ve chvíli, kdy se na USB disk začala exportovat data. Byl od ucs-installer@cisco.com se subjektem Refresh-Upgrade callmanager 8.6.2.20000-2 Booting. Export dat pak trval asi 10 minut.
  • potom následoval restart serveru, o čemž jsem opět dostal email Refresh-Upgrade callmanager 8.6.2.20000-2 Booting, dále musíme instalaci sledovat přímo na konzoli serveru (třeba přes KVM)
  • a nyní jsem narazil na problém, pokud je připojen USB disk, tak se startování serveru zasekne ještě v části BIOSu, problém se mi nepodařilo odstranit žádnou úpravou nastavení v BIOSu
Upgrade CUCM z 8.5 na 8.6
  • takže jsem musel vypojit zařízení, restartovat server, a disk opět připojit hned, jak začal bootovat Linux (systém bootuje z HDD, ale hned potom načítá kickstart file z USB disku)
  • z disku se spustila instalace, která nejprve provedla kontrolu disků, je potřeba minimálně 160GB, přepnul se SATA mode v BIOSu a následoval restart (opět jsem musel odpojit disk a včas jej připojit)
Upgrade CUCM z 8.5 na 8.6
  • po restartu se znovu provedla kontrola disků a pokračovalo se
Upgrade CUCM z 8.5 na 8.6
  • další kroky probíhali pre-install scripts, formatting / file system (na 500GB disku se vytvořili 3 partition ty hlavní o velikosti 120GB + 260GB), instalace RedHat Linux
Upgrade CUCM z 8.5 na 8.6
  • při první instalaci se mi zde objevil zásadní problém. Nevím, jestli v průběhu instalace Linuxu nebo až po ní, ale zobrazila se chybová hláška, že došlo k chybě a jelikož šlo o Refresh upgrade, kdy již došlo k formátování, je jedinou cestou Disaster Recovery na předchozí verzi. Zkusil jsem restart, na serveru začal nabíhat Red Hat, ale opět skončil chybou. Možná by se dalo experimentovat s USB diskem, kde jsou všechna data (včetně kickstart souboru pro instalaci), ale není bootovací. Když jsem instalaci prováděl podruhé (po DR), tak pokračovala bez problémů.
Upgrade CUCM z 8.5 na 8.6
Error detected in pre-boot phase. Unable to revert to original version. Change in software RAID caused a hard drive 
reformat deleting the original version. Recovery requires a reinstall and DRS restore of the prior working software version.
  • a opět reboot – nyní prošel i s USB diskem, ale zastavil se o něco dále, odpojil jsem USB disk, restartoval, a znovu jej připojil, až když nabíhal systém a instalace pokračovala. Nyní uběhla opět jedna hodina, co jsem poprvé restartoval.
Upgrade CUCM z 8.5 na 8.6
  • potom probíhala, mimo jiné, instalace databázových komponent, služeb, vlastního CUCM, a na závěr post application install
Upgrade CUCM z 8.5 na 8.6
  • v tuto chvíli přišel email Refresh Upgrade callmanager 8.6.2.20000-2 Success, od posledního restartu uběhla další hodina a deset minut, bez restartu začal startovat CUCM (což trvalo řadu minut, kdy se neobjevila žádná hláška), další řadu minut trvalo, než se zobrazilo webové rozhraní (nejprve se objevovala chyba, že stránka na web serveru neexistuje)
Upgrade CUCM z 8.5 na 8.6
  • celá instalace trvala více než 3 hodiny

Upgrade Subscriberu

Instalace probíhá stejným způsobem. Musíme vložit USB disk, provede se Refresh upgrade, jsou problémy s bootováním serveru, pokud je připojen USB disk.

A instalace mi skončila stejnou chybou, jako poprvé Publisher. Zde je ovšem jednodušší řešení. Provede se čistá instalace Subscriberu rovnou na novou verzi a automaticky se zreplikují data z Publisheru. Potom je jen třeba doinstalovat lokalizace telefonů (a podobné) a spustit služby.

Kontrola replikací CUCM clusteru

Po dokončení upgradu je dobré zkontrolovat stav clusteru, tedy hlavně replikací. Replikace je dobré kontrolovat i před začátkem upgradu (či jiným větším zásahem).

Pomocí reportů

Hodně důležitých informací získáme vygenerováním reportů v Cisco Unified Reporting - System Reports. Informace o replikacích nalezneme v reportu Unified CM Database Status, další zajímavý report je Unified CM Cluster Overview.

Hned po instalaci Subscriberu uvidíme chybu ve stavu replikací databáze (RTMT Counter Information) a replikační stav některého serveru není 2 - good. Je to proto, že se po instalaci spustí replikace, která trvá třeba i hodinu, a teprve potom se vše srovná.

Pomocí CLI

Podobné informace (a více možností) získáme, když se připojíme přímo na CLI CUCM serveru (více informací poskytne Publisher). Potom můžeme použít příkaz:

utils dbreplication runtimestate

Ten nám zobrazí aktuální stav replikací včetně probíhajících oprav a resetů. Téměř na konci každého řádku je číslice v kulatých závorkách, jde o replication status a potřebujeme zde mít 2, což je good. Některé další možnosti 0 - Not Started, 1 - created, but their count is incorrect, 3 - bad in the cluster, 4 - setup did not succeed.

Pomocí následujícího příkazu můžeme vyvolat kontrolu všech tabulek (výsledek zobrazíme předchozím příkazem):

utils dbreplication status

Jestliže je v replikacích problém, tak můžeme zkusit jejich reset:

utils dbreplication reset 

Detailnější informace nalezneme třeba v článku Troubleshooting CUCM Database Replication in Linux Appliance Model.

zobrazeno: 6646krát | Komentáře [1]

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

  1. [1] Jirka

    Musim rict, ze jsem byl po precteni par prispevku na Cisco Support Community a na Tvojem webu trochu nervozni z upgradu na CUCM 8.6, ale nakonec se 2x povedlo bez vetsich komplikaci. Jak cluster, tak standalone.

    Good job, jsem zvedav co prinese upgrade na 9.0 :-)

    Neděle, 29.04.2012 19:46 | odpovědět
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