Ez sajnos egy elég hosszúra nyúlt folyamat volt, részben frissítettünk próbaképp egy vCenter 5.1-et, aztán közben kijött az 5.1 Update 1, akkor még egy frissítés, aztán ESXi frissítés, aztán pedig átállás a vSphere Data Protection (VDP) mentési megoldásra a korábbi VMware Data Recovery-ről (VDR).
Tapasztalatok és hasznos leírások egyes problémákról:
- A kezdeti 5.1 kiadásnál kb. minden komponens után újabb és újabb hibaüzenetek jöttek. Nem véletlenül nagyon gyorsan kijött egy 5.1a, aztán egy 5.1b. De érdemesebb inkább egyből az 5.1 Update1-et nézni, sőt, annak is van 5.1 Update 1b verziója:)
- Jó az új linux-os appliance verzió, de az Update Manager-ből még csak windowsos verzió van, úgyhogy aki azt is szeretne használni, annak kell mindenképp egy windowsos szerver is. Sőt, az új webes kliensben csak Scan-t (frissítések keresése) lehet nyomni, a Remediate (frissítések telepítése) csak a klasszikus vastagkliensből érhető el:). Gondolom majd a következő verzióra sikerült mindent átállítani az új platformra.
- Az új Single Sign-On (SSO) komponens telepítője nem tud alapból nevesített SQL-szerver példányokhoz csatlakozni, holott az eddig vCenter verziók kapásból olyat raktak fel. Így frissítésnél az marad, hogy ha használni akarjuk a meglévő SQL Server Express példányt, akkor ki kell tölteni a szerver adatait (IP-cím, port…), majd utána bepipálni, hogy a JDBC URL-t is meg akarom adni, és ott lehet a példány nevét megadni:
-
jdbc:sqlserver://localhost:1433;databaseName=RSA;instanceName=SQLEXP_VIM
- Figyelem: NE adjuk meg a beépített hitelesítés használatát (integratedSecurity=true;), mert nekünk akkor olyat csinált, hogy megnézte, hogy be tud lépni, ment a telepítő, majd a közepén fogta, és letörölte az RSA_USER és RSA_DBA felhasználókat. Majd utána nem sokkal panaszkodott, hogy nem tud ezekkel belépni, és leállt:)
- Az MS SQL Serverhez csak SQL hitelesítési módszerrel tud csatlakozni (Troubleshooting vCenter Single Sign On installations which fail with: Error 29114. Cannot connect to DB). Értem én, hogy így könnyebb megvalósítani, meg több a közös kód a más DB-hez való csatlakozó részekkel, de azért az SQL-es hitelesítési mód MS SQL-en már vagy 10 éve nem ajánlott.
- A kezdeti 5.1 telepítő nem tudott dinamikus portokat kezelni, az 5.1 Update 1 talán már igen. [Mondjuk azért valahol irónikus, hogy pont a fő biztonsági komponens telepítése során kell kikapcsolni az adatbázis-kiszolgáló biztonsági funkcióit:]
-
- Az SSO telepítés után mi belefutottunk egy nagyon aljas hibába: Error 29102.Could not contact Lookup Service.
- Van egy kapcsolódó KB (Installing or upgrading vCenter Server 5.1 fails with the error: Could not contact Lookup Service (2035965)), ami egy nagyon banális programozói hibát sejtet [ha a ‘port’ szó benne van a szerver FQDN-ben, akkor azt nem kezeli:], de nálunk nem ez volt a gond.
- A lookupservice.log fájlban ‘JDBC URL value should not be empty’ már segített, a ‘C:\Program Files\VMware\Infrastructure\SSOServer\webapps\lookupservice\WEB-INF\classes\config.properties‘ beállításoknál tényleg üres volt. Beírva a telepítőben működő JDBC URL-t természetesen nem ment, java.sql.SQLException: No suitable driver found volt a hiba, pedig a JDBC jar ott volt a tomcat könyvtárában. Mindenféle log átnézése, trace üzemmódok bekapcsolása után jött a megvilágosodás: a telepítő és az SSO maga nem ugyanazt a JDBC könyvtárat használj, az SSO a http://jtds.sourceforge.net könyvtárat tartalmazza, abban pedig ez a formátum:
- jdbc:jtds:sqlserver:<server>[:<port>]<database>[;<property>=<value>
- Elment vele némi idő, szeretjük az ilyen sok komponensből integrált termékeket:)
- Az SSO-nál még annyit, hogy aljas módon van egy admin felhasználó, akinek jelszót kell adni a telepítéskor, de azt nem írja ki, hogy ez a jelszó lesz az SSO master password, amivel később pl. ki lehet ütni az admin jelszavát, ha nem tudunk vele belépni. Az admin jelszavának változtatásakor viszont a master password nem változik. Az admin jelszót később még ki lehet ütni az adatbázisban tárolt hash átírásával (lásd: vCenter Single Sign On master password, alul), de ha a master passwordöt nem tudjuk, akkor csak az újratelepítés segít (lásd pl. Upgrading vCentre 5.1 SSO – Password Confusion).
- Gondoltam a sikeres telepítést még megkoronázzuk azzal, hogy lecseréljük szokásos módon az alap tanúsítványokat, erre most már van egy segédeszköz is: Deploying and using the SSL Certificate Automation Tool (2041600). Azonban minden komponensnek (SSO, Inventory Service, vCenter Server, Web Client, Update Manager) különböző tanúsítvány kell, mert az alapján azonosítják egymást, ezért mindet külön kell kiállítani, majd lecserélni, majd a kölcsönös bizalmi kapcsolatokat újrakonfigurálni, úgyhogy ez most már nem egy 10 perces munka:( [a korábbi verziókban csak 1-1 fájlt kellett lecserélni és újraindítani az egészet].
- Az Update Manager esetén meglepő módon nem volt gond.
- Az ESXi-k frissítése is lement, egy vicces mozzanat azért van. Update Managerrel frissítve szépen látszik, hogy berakja Maintenance mode-ba, elkezdődik a telepítés, újraindítja, majd vár, vár, vár még mindig vár, és nem jön fel az ESXi. Még szerencse, hogy volt remote console beállítva, így látszik, hogy a szerver ezt csinálta épp. Azaz szépen még egy Enter-re vár, ahelyett, hogy újraindulna:)
- Az eddigiek azonban eltörpülnek a vSphere Data Protection telepítése és beüzemelése mellett. Szerencsére nem csak nekem volt ilyen érzésem (vDP – Sick of being a beta tester, itt kicsit elszabadultak az indulatok:). Nálam a fő probléma az volt, hogy a telepítés után az első kézzel indított mentés sikeres volt, majd az esti automatikus mentés már leállt ilyen hibával: ‘VDP: Miscellaneous error‘. Erre is van KB (Backup job fails for all virtual machines after vSphere Data Protection 5.1 deployment (2038597)), de nem ez volt nálunk a gond. Van egy régi Avamar-os hiba is (https://community.emc.com/thread/101335?start=15&tstart=0), de az sem segített. Log bundle átnézése, Wiresharkkal forgalom figyelése, sokszori próbálkozás után végül megfogadtam az itt található tanácsot: “if all else fails, reboot (the VDP appliance)”! Az első újraindítás órákig tartott, teljesen reménytelen volt, hogy egyáltalán elindul újra, de aztán jobbára talpraállt. Ekkor már másik hibát dobott (VDP: Failed to initiate a backup or restore for a virtual machine. Probable cause is the datastore for the virtual machine is not accessible.), holott látta minden host az összes datastore-t, így kapott végül másnap is egy újraindítást, és most nem akarom elkiabálni, de lefutott az automatikus mentés is:)
Hát egyelőre ezek a tapasztalatok az 5.1-es kiadással. Jó funkciók kerültek bele, meg messzire mutató az architektúra- és platformváltás, de azért nem volt egy végleges release érzésem:)