A VMware vCenter Server adatbázisa méretének csökkentése

A VMware vCenter Server adatbázisba dolgozik. Ha Windowsra telepítjük, akkor alapértelmezetten telepítve egy MS SQL 2008 R2 Express-t dob maga alá. Ez ugyan ingyenes, de vannak korlátai. Például a 10GB-os maximális adatbázisméret. A hostok, virtuális gépek stb. számától függően lassabban, vagy gyorsabban telik ez az adatbázis és akár rövid idő alatt meg is telhet. Ha megtelik, akkor a VMware VirtualCenter Server szolgáltatás lerohad (és nem is fog elindulni megfelelően, amíg nem csökkentjük az adatbázis méretét a 10GB alá), így ahhoz a klienssel nem lehet csatlakozni. Mivel a szolgáltatás nem fut, számos más dolog - pl. a VDP mentések - sem működnek. Ezért ezt a hibát illik mihamarabb elhárítani.

Vannak VMware tudásbázisos cikkek:

A megoldás:

To purge the data in the VPX_EVENT table:

1) Connect to Servername\SQL Database and log in with the appropriate credentials.
2) Click databases to expand and select VIM_VCDB > Tables.
3) Right-click the dbo.VPX_PARAMETER table and select Open.

Note: If you are using SQL Server 2008, right-click the dbo.VPX_PARAMETER table and click Edit Top 200 Rows.

4) Modify event.maxAge to 30, and modify the event.maxAgeEnabled value to true.
5) Modify task.maxAge to 30, and modify the task.maxAgeEnabled value to true.

Note: To improve the time of the data cleanup, run the preceding steps in several intervals. To do this, ensure to keep the default value of event.maxAge and task.maxAge and perform step 6 to run the cleanup. Then, reduce the event.maxAge and task.maxAge value by 60 and run the cleanup. Repeat the steps until the value is reached to 30 for the final cleanup process.

6) Run the built-in stored procedure:

  • Go to VIM_VCDB > Programmability > Stored Procedures.
  • Right-click dbo.cleanup_events_tasks_proc and select Execute Stored Procedure.

This purges the data from the vpx_event, vpx_event_arg, and vpx_task tables based on the date specified for maxAge.

7) When this has successfully completed, close SQL Management Studio and start the VMware Virtual Center Server service.

vCenter SQL adatbázis méretcsökkentés #1
A dbo.cleanup_events_tasks_proc tárolt eljárás futtatása

vCenter SQL adatbázis méretcsökkentés #2
Sikeresen lefutott

A fentieket kiegészíteném még egy adabázis shrink-eléssel:

vCenter SQL adatbázis méretcsökkentés #3

Egy hasznos blogbejegyzés, hogy ne kelljen a lényeget órákig guberálni:

Hogy elkerüljük az adatbázis ilyetén való elburjánzását, kapcsoljuk be és csökkentsük a vSphere kliensben az Administration -> vCenter Server Settings alatt retention értékeket:

vCenter Server Settings - Database Retention Policy

Ha ez nem segít (mert így is túl gyorsan nő az adatbázis, vagy szükség van régebbi adatokra), akkor marad a fullos SQL szerverre, a linuxos vCenter-re váltás stb.

Hozzászólások

Nem lehet feldobni windowsra egy másik db enginet (mondjuk amit linuxon használna), átmigrálni az adatokat, majd valahogy rávenni a vcentert, hogy ahhoz kapcsolódjon?

Win alatt MS Sql, Oracle, DB(korlátozottan) támogatott. Az MS SQL szerverrel jár a legkevesebb szívás és legjobban dokumentált. Viszont ha a megtartási időt nem veszik le az azzal jár, hogy az express betelik.
Én nem vállalnám a macerát és bizonytalanságot ami egy ilyen váltással járna. Valamint ha SQL licencre nem volt pénz a másikból is valószínűleg az ingyenesekre tudna migrálni, hacsak más miatt nem volt már telepítés ezekből(kereskedelmi).

"...meg lehetne gányolni,..."

Hogyizé? Ez sem egy enterspájz módszer, amit leírsz! :D Értem én, hogy van helyzet, amikor kis pénz, kis foci, de aki így tervez egy production VMware rendszert, hogy nincs benne a DB licencköltsége, az húzza le magát a klotyón. Vagy tervezzen más irányba, pl. XenServer (bár 5.x alatt az analyzer toolhoz ott is DB kellett).

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Ettől még az előbbi egy _vendor által támogatott_, kis rendszeres megoldás. Azzal települ, sok helyre elég. El lehet vele indulni, majd ha kinövik, akkor váltanak nagy MSSQL szerverre.

Azzal, hogy te egy nem támogatott SQL szervert teszel alá, már nem lesz az.

Az pedig, hogy két host alá egyből milliós SQL szervert pakolsz, az nem tervezés, hanem pazarlás.

A linuxos vCenter appliance-ben nincs (tudtommal) adatbázis korlát, az is egy opció lehet, ha tovább kell lépni.

--
trey @ gépház

Ne is emlegesd... Elmúlt 2 évben sokszor volt rá szükségem, amikor vettük át "az sql licence már nem futotta a közbeszből" rendszereket. Windows alatt még nincs is probléma, de a különböző verziós vCenter appliancekkel szállított kevésbé dokumentált db2 és vpostgresekkel(hát még ha db2-ről lett migrálva) már több kitartást kérnek.

Windows esetén az általad blogolt dolgokat csinálom és a megőrzési időt leveszem alacsonyra. Szerencsére ezek általában kis rendszerek voltak, ahol bőven elég az Express, csak a kivitelezőnek anno a nextnextfinish metodikán túl azért mást is kellett volna csinálnia.
Pénz/pályázat híján ezeket helyben kiváltani szinte lehetetlen(valamint ezek még általában 4.x-es rendszerek, így appliance is kilőve). Állami szférában pedig a központosítás mostanában a cél, így ilyen-olyan cél rendszerekbe ezek lassan bevándorolnak.
Magunk részére pedig 5.x-es vonalon appliance(5.0, de ezt szerintem nem kellett volna erőltetnie a VMwarenek) és "rendes" adatbázisos windowsos telepítés(5.5).

Két dolog volt, egyrészt 5.5-től van egy banner hogy az új funkciók csak web clienten.
Másrészt nem tudtad a VM beállításait szerkeszteni ha vmx10 volt a virtuális hw verzió. Erre mondjuk meg lettek köpködve szóval 5.5U2-ben "kijavították" a "hibát" és onnantól megy megint.