www.SAMURAJ-cz.com 

17.12.2017 Daniel Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

CUCM 8.5 Publisher - kompletní Disaster Recovery

Čtvrtek, 23.02.2012 16:10 | Samuraj - Petr Bouška |
Poprvé v životě jsem musel provést kompletní Disaster Recovery na CUCM, protože mi selhal upgrade na verzi 8.6 a skončil jsem s Publisherem, který měl zformátovaný disk. Takže zde stručně sepíšu svoje postřehy z průběhu této stresující činnosti (pokud nám v té chvíli ve firmě neběží telefony).

Vlastní proces obnovy dat jsem podrobněji popsal v novém článku CUCM obnova clusteru ze zálohy - Disaster Recovery. Podobnou situaci jako zde, také řeší článek Migrace CUCM z fyzického HW do VMware.

V mém případě jsem měl Publisher a jeden Subscriber oba běžící na HW serveru HP7825H3, což je HP Proliant DL320 G5. Instalovaná verze byla CUCM 8.5.1.11900-21. A dále v IPT také jeden server s UCCX (kontaktní centrum). Publisher byl nefunkční.

Oficiální dokument o Disaster Recovery (DR) je Disaster Recovery System Administration Guide for Release 8.5(1). Nakonec asi obsahuje všechny potřebné informace, ale na začátku jsem ho nechtěl studovat a přišlo mi, že tam není, co potřebuji. Hledal jsem tedy různá rychlá řešení, která mne napadala, ale nic se nedalo realizovat.

Dočasný provoz

Nejprve jsem potřeboval rozběhnout alespoň nějaký provoz. Volání jako takové fungovalo díky Subscriberu. Ale nefungovala Extension Mobility, což byl docela problém. Snažil jsem se najít řešení, ale patrně žádné není a je potřeba mít běžící Publisher. Minimálně jsou ve Phone Services - Extension Mobility uvedeny URL na Publisher a pokud ten neběží, tak nemůžu ani provádět žádné konfigurační změny. Dočetl jsem se v diskuzi, že když běží jen Subscriber, tak by mělo jít nastavit například přesměrování čísla (což jsem chtěl provést na nepřihlášených telefonech), ale ani to se mi nedařilo.

Jako důležitější věc jsem řešil funkčnost UCCX, kde bylo nastaveno připojení na Publisher. Takže se nedařilo ani připojení do UCCX Administration, abych tyto hodnoty mohl změnit. Naštěstí jsem našel postup, že je možno se připojit na CLI jako Platform admin a potom příkazem set uccx provider ip axl, set uccx provider ip rmcm a set uccx provider ip jtapi změnit adresy na Subsciber. Po restartu již UCCX začalo fungovat.

Hledal jsem také, jestli není možno přepnout Subscriber na Publisher, a až na informace, že se to plánuje v nějakých nových verzích, jsem nic jiného nenašel.

Stejně tak jsem hledal, jestli by nešel využít USB disk, který se vytvořil při upgradu a kde jsou veškerá data, ale také jsem nic nenalezl. Možná by to nějak šlo, protože z disku startovalo pouze malé rozhraní Linuxu a na USB disku se hned na počátku hledal Kickstart soubor pro instalaci, ale neměl jsem čas dělat pokusy, takže jsem se pustil do DR.

Disaster Recovery (DR) - Publisher

Takže jsem došel k tomu, že musím provést DR Publisheru. K tomu je potřeba

  • záloha dat z CUCM (měl jsem zálohy obou serverů)
  • bootovací DVD se stejnou verzí, z které mám provedenu zálohu

Musíme provést čistou instalaci CUCM jako Publisher. Já jsem neměl k dispozici bootovací verzi 8.5.1.11900-21, takže jsem nejprve nainstaloval 8.0.2.20000-8, pak provedl standardně upgrade z nebootovacího ISO. Potom se teprve provádí obnova dat. Při instalaci musíme zadat řadu údajů, je důležité, aby jméno, IP adresa, verze, uživatel i hesla byla stejná, jako u původního serveru.

Pozn.: Radu, jak provést rovnou instalaci z upgrade ISO, obsahuje článek CUCM 8.6 instalace Publisheru.

Co pro mne bylo důležité. Že je potřeba provést klasickou instalaci, není možné již v průběhu použít zálohu, abychom se tak vyhnuli zadávání všech údajů. Potom také to, že po naběhnutí čistě instalovaného Publisheru nezačne docházet k žádné replikaci ani přebírání služeb (ty jsou vypnuté). Takže se nám nepoškodí běžící Subscriber a můžeme to dělat za provozu.

Když máme nově nainstalovaný Publisher (se stejnými údaji jako měl ten starý), tak provedeme obnovu dat pomocí Disaster Recovery System. Podrobný postup je uvedený v dokumentu, který je zmíněný na začátku článku. Celý proces probíhá přes webové rozhraní CUCM Disaster Recovery System.

  • Backup - Backup Device - nejprve musíme vytvořit zálohovací zařízení pro místo, kde máme uloženy zálohy (musí to být SFTP server), asi použijeme to samé nastavení, co jsme měli pro zálohování
  • Restore - Restore Wizard - začneme obnovu
  • zvolím zálohovací zařízení
  • kterou zálohu chceme použít
  • jaké vlastnosti chceme obnovit (což bude UCM)
  • a nyní se dostáváme na důležité místo, kde volíme, jaké servery chceme obnovit
CUCM Disaster Recovery System

Pozn.: First node = Publisher, Subsequent node = Subscriber

Máme několik možností, podrobně popsaných v dokumentu DRS.

  • obnovit pouze Publisher
  • obnovit Publisher i Subscriber
  • obnovit Publisher a využít ještě aktuální data na Subscriberu

Podle dokumentace bych chápal, že v mém případě se provádí pouze obnova Publisheru. Nevím, jestli by to stačilo, protože jsem provedl nejprve obnovu Publisheru a pak Subscriberu. Přímo na stránce obnovy se píše, že pokud máme čerstvě nainstalovaný Publisher, tak můžeme vybrat pouze Publisher a další servery obnovit až po obnově Publisheru.

Já jsem prováděl obnovu dvakrát, poprvé jsem asi nepostupoval správně. Abych měl jistotu, že nepřijdu o celou telefonii, tak jsem vypnul Subscriber a teprve potom provedl obnovu Publisheru. Ten po obnově fungoval bez problémů. Takže jsem potom provedl obnovu Subscriberu. Ale následně jsem měl nějaké problémy a při kontrole replikací zde byla řada chyb. Možná by se to dalo vyřešit. Ale radši jsem zkusil provést znovu obnovu a zvolil jsem oba servery najednou. Obnova proběhla opět bez chyb, a když se dokončili replikace, tak vše fungovalo.

Když jsem sledoval průběh obnovy, tak mi přišlo zajímavé, jak se obnovuje DB. Nejprve se obnovoval Publisher a když se obnovovala DB, tak po obnově Publisheru to psalo, že se obnovuje Subscriber. Pak se obnovoval Subscriber. Po upgradu je potřeba restartovat. Potom probíhá kompletní replikace dat na Subscriber, která může trvat i více než hodinu.

Obnova jednoho serveru také není nijak rychlý proces, trvala odhadem jednu hodinu. Po obnově dat je potřeba provést restart serverů. Nejprve se restartuje Subscriber a teprve když opět běží, tak Publisher.Pak musíme počkat na dokončení replikací.

Disaster Recovery (DR) - Subscriber

Jenom jako poznámku zde zmíním, že pokud máme funkční Publisher a "umře" nám Subscriber, tak sice můžeme provádět obnovu, ale není to potřeba.

Subscriber můžeme prostě nově nainstalovat, svoje údaje již má na Publisheru zadány. Automaticky se připojí do clusteru (pokud mu dáme stejné údaje, jaké měl) a začne replikovat data. Pak je potřeba doinstalovat jazykové balíčky pro telefony (locale) a případně další speciální data, která nejsou součástí běžné instalace. Spustit požadované služby a vše běží.

Kontrola replikací po DR

Potom, co se provedla obnova obou serverů následovaná restartem, je určitě dobré zkontrolovat stav serverů a hlavně jejich replikací. Musíme mít ale na paměti, že nějakou dobu po obnově probíhá plná replikace na Subscriber, takže můžeme ve stavu replikací vidět různá varování.

Pomocí reportů

Hodně důležitých informací získáme vygenerováním reportu v Cisco Unified Reporting - System Reports. Zajímavý je report Unified CM Cluster Overview a Unified CM Database Status.

Pomocí CLI

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

utils dbreplication status

Který začne shromažďovat informace o replikacích, a následně pomocí dalšího příkazu zobrazíme výsledek.

utils dbreplication runtimestate

Je tu i možnost zresetovat stav, když máme problémy.

utils dbreplication reset 

Problémy na telefonech

Pokud se po DR objeví nějaká nefunkčnost na telefonech, tak je možno vyzkoušet několik postupů.

  • obyčejný restart telefonu
  • odhlášení a nové přihlášení, pokud se využívá Extension Mobility (to nám může zobrazit chybu, pak je nutné postupovat dalším způsobem)
  • smazaní ITL (Initial Trust List) souboru
  • tovární reset nastavení

Restart telefonu z klávesnice

  • na telefonu stiskneme tlačítko Settings (nastavení)
  • pak zadáme **#**

Smazání ITL souboru

Initial Trust List soubor se používá pro zabezpečení komunikace telefonu a serveru od CUCM 8.

Pro telefony 79XX:

  • stiskneme tlačítko Settings (nastavení)
  • zvolíme Security (Konfig. zabezpečení)
  • zvolíme Trust List (Seznam certifikátů)
  • zvolíme ITL File (Soubor ITL)
  • na klávesnici zadáme kód **# (tím odemkneme nastavení)
  • stiskneme Erase (Vymazat)

Pro telefony 89XX/99XX:

  • stiskneme tlačítko Settings (nastavení)
  • zvolíme Administrator Settings
  • zvolíme Reset Settings
  • zvolíme Security Settings

Factory reset - reset do továrního nastavení

Pro telefony 79XX:

  • vypojíme napájení
  • zapojíme napájení a zároveň držíme klávesu #
  • ve chvíli, kdy začnou blikat boční tlačítka (speed dial), tak pustíme klávesu
  • postupně stiskneme všechny klávesy 123456789*0#

Pro telefony 89XX/99XX:

U nových telefonů je možné provést factory reset přímo v menu telefonu. Stiskneme tlačítko Applications (mě připadá spíš jako nastavení) - Administrator Settings (Nastavení správce) - Reset Settings (Reset nastavení) - All Settings (všechna nastavení).

zobrazeno: 4983krát | Komentáře [4]

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 Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže. Pokud chcete poradit s nějakým problémem či diskutovat na nějaké téma, tak použijte fórum.

Komentáře

  1. [1] Tucin

    Pri upgradu se prece meni data jen na jedne partition, druha zustava se starou verzi ccm. Ta ti taky zmizela?

    Nejrychlejší způsob obnovy pak spočívá v nabootování rescue & recovery a tam je prehodit zpet.

    Středa, 29.02.2012 19:35 | odpovědět
  2. [2] Samuraj

    odpověď na [1]Tucin: Kdyby sis přečetl můj předchozí článek, kde popisuji upgrade, tak by ses dozvěděl, že při upgradu na verzi 8.6 a určitém HW se provádí Refresh Upgrade, který vytváří nové partition (a dokonce i mění způsob přístupu k diskům). Takže žádná předchozí verze nezůstane.

    Čtvrtek, 01.03.2012 08:01 | odpovědět
  3. [3] Tucin

    odpověď na [2]Samuraj: Omluva, skutecne jsem cetl jen tento a zkusenosti mam jen z upgrade mezi 6 a 8.0.

    Na clanek jsem narazil pri reseni vlastnich potizi, a byl uzitecny, takze diky za nej!

    Čtvrtek, 01.03.2012 09:33 | odpovědět
  4. [4] Lobin

    odpověď na [3]Tucin: CUCM 8.6 ma pod sebou OS UCOS5.x.x.x, verze 8.5 mela jeste UCOS4.x.x.x. Refresh upgrade je treba hlavne na platformach 7825, coz jsou dle mne u nas nejrozsirenejsi :-)

    Pátek, 16.03.2012 11:05 | odpovědět
Přidat komentář

Vložit tag: strong em link

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


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

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