30. április 2008 · Write a comment · Categories: CA, DSM · Tags: ,

A probléma eléggé egyszerû, adott egy szerver és e helyett a DSM szervert át kell telepíteni egy másik gépre. A feladatot elsõ látásra könnyû megvalósítani, de amennyiben az ember elolvassa egy régebbi verzióhoz készült dokunmentáció (TEC413416), mely az MDB backup/restore lehetõségeit írja le akkor érdekes részre akad:


The new Domain Manager must have the same host name as the old one had

Ez nagy gond, hisz a a régi és az új helyzetben a szerverek neve nem egyezik meg (hisz eddig minden egy gépen volt és most funkciók szerint is külön szerettük volna választani). E ténybõl adódóan nem tehettünk mást, mint az egész alkalmazást teljes egészében eltávolítotjuk és újratelepítjük az új gépen.

Probléma

Nos így tettünk, s minden ment is rendben szépen. A telepítést követõen elindítottuk a rendszert és ekkor következett a meglepetés nem került létrehozásra a System Engine. Tekintettel arra, hogy e komponens nélkül a rendszer nem, illetve csak részben mûködik.

Próbáltunk mindent annak érdekében, hogy a System Engine létrehozását kierõszakoljuk, de eggyik kisérletünk sem járt sikerrel (reinstall, repair, uninstall/install, stb.).

Megoldás

Bár sokat küzdöttünk érte, hogy megleljük mi is a probléma, a végén mégis alapjaiban egyszerû volt a probléma oka. Mire is jöttünk rá?

A rendszer eltávolítása során az eddig megszerzett adatok védelme érdekében azt kértük a rendszertõl, hogy az MDB-ben tárolt DSM adatokat ne törölje ki. Mit tett erre a kedves rendszer? Nem törölt az semmit kérésünknek megfelelõen az MDB-bõl semmit, még a System Engine-re vonatkozó bejegyzéseket sem. E ténynek a következtében a rendszer a továbbiakban – miután érezte – a System Engine jelenlétét, nem hozta létre a szükséges komponenst.

Ezután már egyszerû volt a probléma elhárítása, ismételten eltávolítottuk a DSM szervert, de most már minden adat eltávolítását kérve. Ezt követõen a telepített rendszer már renden létrehozta valamennyi szükséges komponenst és a rendszerünk máris teljes egészében mûködõvé vált.

Hát nem semmi küzdés volt. Sajnos e problémára a TCC-tõl nem kaptunk segítséget, igaz számukra a probléma megértése is problémát okozott, mert nem értették meg mi is történt velünk és miért. Sajnos az ismert leírások sem említettek ilyet. Feltételezem, hogy a CA telepítésekkel foglalkozó rendszermérnökei számára ez nem okozott volna problémát, de mi nem velük tárgyaltunk… Hát ez van. Végülis ez a probléma is megoldásra került, és minden mûködik tovább. Huhhh….

Felmerült az igény, hogy a Service Desk (USD), Desktop and Server Management (DSM) alkalmazásokat valamint az õket kiszolgáló SQL szervert egy-egy különálló gépre kell szétszedni, performanciális és üzemeltetési okok miatt. A rendszerek ennek lehetõségét biztosítják, csak ennek megfelelõen kell a rendszereket telepíteni.

A CA felügyeleti alkalmazásai alapvetõen egy közös menedzsment adatbázisba (MDB) dolgoznak, ezen keresztül tudják tartani a kapcsolatot is adatszinten egymással. Az adatbázist az elsõ rendszerfelügyeleti komponens telepítésekor hozzák létre, majd minden a továbbiakban telepítésre kerülõ alkalmazás ide jegyzi be saját hozzáférési adatait, csak a felhasználókat és a szerepköröket, maga az adatbázis az alkalmazások által közvetlenül nem kerül módosításra, annak önálló telepítõje van. Amennyiben az adott alkalmazás nem a lokális szerveren tárolja az adatbázisát, akkor elsõ lépésben az adatbázis szerveren kell az MDB generálását elvégezni, ezt Remote Components Install-nak hívják (az egyes termékek ettõl kicsit eltérõen is nevezhetik, nevezik). Amennyiben ez a telepítés elkészült, akkor a telepítés a tényleges alkalmazás szerveren folytatódik, s a telepítõ varázsló paraméterezésekor adjuk meg a már elõkészített MDB-t tartalmazó adatbázis szerver elérési adatait. More »