Host és VM performancia értékek, statisztikák gyűjtése - Direkt SQL lekérdezések (1.rész)

Egy régebbi postban írtam arról, hogy milyen lehetőségeink vannak (természetesen vannak más módszerek is), ha szeretnénk hosszabb távon performancia adatokat tárolni illetve megjeleníteni úgy, hogy ez ne függjön a vCenter szerveren beállított megőrzési időktől, illetve csak az adatok egy számunkra fontos részhalmazát tartalmazzák.

Most a direkt SQL lekérdezésekről szeretnék írni. Esetemben a vCenter szerver adatbázisa egy SQL 2005-ös adatbázis szerveren fut (a neve legyen VPX). Mivel az volt a célom, hogy a lekérdezéseket majd SQL Reporting Service segítségével oldjam meg, így természetesen a kigyűjtött adatok is egy SQL adatbázisba kerülnek (a neve legyen VMware_stat). Ebben a bejegyzésben csak az adatok gyűjtéséről lesz szó, később valamikor a lekérdezésekről is írok. (talán)

A feladat behatárolása

Nem akartam egyszerre mindenre kiterjedő lekérdezéseket létrehozni, ezért a következő feltételeket szabtam magamnak.

• Csak a hostok adataira vagyok kíváncsi
• Nem bántom a vCenter beállításai között a Statistics Level értékét (marad 1)
• Külön gyűjtöm az 5 perces, félórás és 2 órás értékeket
• Az öt perces adatokat 40 napig gyűjtöm, a többinél egyelőre nem szabtam korlátot
• Mivel a Statistics Level 1 maradt, így eléggé beszűkültek a lehetőségek, így én négy különböző értéket választottam: cpu.usage(%), mem.usage(%),disk.usage(kiloBytesPerSec),net.usage(kiloBytesPerSec)
• A mért értékek köre viszonylag könnyen módosítható legyen
• Az adatbázis hasonlítson egy normálisan felépített relációs adatbázisra

A VPX adatbázis feltérképezése

Mivel nagyjából tudtam mit akarok, ezért elkezdtem böngészni a vCenter adatbázisát, hogy melyik táblát vagy nézetet tudnám legkönnyebben felhasználni. Ehhez előbb kitaláltam, hogy az én kis adatbázisom kb. hogy fog kinézni. Így:

A lekérdezéseknél szeretném, ha különálló hostokat is lehetne választani, de akár cluster-enként is indíthatóak legyenek. Ehhez a host táblámban szerepeltetni kell a cluster azonosítót is. Mivel a host-cluster összerendelés kiolvasható a vpx.dbo.vpx_entity táblából, valamint mindent megtudhatunk a hostokról a vpx.dbo.vpx_host táblából, így a kettőt felhasználva könnyen írhatunk egy query-t, ami pont azt az információt adja meg, amivel a host táblámat fel akarom tölteni.

INSERT INTO dbo.host

SELECT h.id,dns_name,

(SELECT id FROM vpx.dbo.vpx_entity p WHERE e.parent_id=p.id) p,

ip_address,product_version,product_build,host_model,cpu_model,

cpu_count,cpu_core_count,cpu_thread_count,

cast(round((cast(cpu_hz as numeric)/1000000000),1) as numeric(3,1)),

ceiling(round(cast(mem_size as numeric(13,0))/(1024*1024*1024),0)),boot_time

FROM vpx.dbo.vpx_host h,vpx.dbo.vpx_entity e WHERE h.id=e.id

Mint láthatjátok, egy al-lekérdezéssel olvastam ki a cluster azonosítóját (parent_id), illetve a memória méretének és a processzor sebességének a mértékegységét egy kicsit átalakítottam. Természetesen a cluster táblámat is feltöltöttem a megfelelő értékekkel.


insert into dbo.cluster

select id,name from vpx.dbo.vpx_entity where type_id=3

Következő lépésben azokat a statisztikákat kellett kigyűjtenem, amelyeket használni szeretnék. Ezt egyszerűen lekérdeztem a megfelelő táblákból, nézetekből, megnéztem, milyen azonosító érdekel engem, és annak megfelelő feltöltöttem a stat_def táblámat.


insert into dbo.stat_def
select id,cast(group_name+'.'+name as nvarchar(50)),cast(unit as nvarchar(15))

from vpx.dbo.vpx_stat_def

where id in (2,98,16,110)

Az elején említett négy statisztikának az azonosítója 2, 98, 16 és 110, ezért szerepelnek ezek az értékek a where feltételben.

Ezzel tulajdonképpen készen van az a három tábla, ami az alap adatokat tárolja. Ezután jön az érdekesebb rész. Mint mondtam, én az öt perces, félórás és két órás értékeket szeretném tárolni. Ezeknek létrehoztam három táblát, teljesen azonos szerkezettel. Ezek neve rendre dbo.stat_5min, dbo.stat_30min és dbo.stat_120min.

Már csak azt kellett kitalálnom, hogy honnan tudnám legegyszerűbben kinyerni az értékeket. Nyílván a táblák közt is meg lehetne találni, de biztos voltam benne, hogy ők is inkább nézeteket használnak, amikor pl. a vSphere kliensben valamilyen performance diagramot megnézünk.
Sikerült is ezekre rálelni. Ezek a nézetek a következők: vpx.dbo.vpxv.hist_stat_daily, vpx.dbo.vpxv.hist_stat_weekly, vpx.dbo.vpxv.hist_stat_monthly. Létezik egy negyedik is, amiben napi összesített értékeket tárol (azaz egy nap, egy érték), de én azt nem akartam használni.

Három olyan tárolt eljárást kellett megírnom, ami a megfelelő nézetből feltölti az én tábláimat. Elsőre egyszerűnek tűnik a dolog, de azért van benne néhány dolog, amire figyelemmel kell lenni.

• A vCenter UTC idő szerint tárolja le az adatokat, így ezt bele kell kalkulálni. Ezt megtehetnénk a riportok írásánál is, de egyszerűbb már ezt figyelembe véve áttölteni az adatokat.
• Figyelembe kell venni azt is, hogy a vCenter mikorra időzíti a saját SQL job-jait, hogy ne ütközzünk.
• A következő fontos dolog, hogy ugye ezt az egészet azért csinálom, mert a vCenter csak egy bizonyos ideig őriz meg értékeket, így nekem még azelőtt át kell vennem, mielőtt azokat automatikusan törli.
• A negyedik pedig az, hogy meg kell határoznom, hogy egyszerre mekkora idő intervallum értékeit vegyem át. Minél gyakrabban töltöm át az értékeket, annál hamarabb rendelkezésre áll a riportok számára.

Az intervallumok esetében én úgy döntöttem, hogy az öt perces adatokat kétóránként, a félórás adatokat naponta, a két órásakat pedig hetente frissítem. Úgy tűnik, ez viszonylag jó választás volt a visszajelzések szerint.

Nézzük, hogy néz ki egy tárolt eljárás. A három közül azt láthatjátok, ami a félórás adatokat tölti át, és naponta egyszer fut. Azaz egy napnyi értéket másol be egyszerre az én táblámba. Az egyszerűség kedvéért a teljes eljárást bemásolom.


CREATE PROCEDURE [dbo].[felora]
AS

BEGIN

DECLARE @STARTD datetime

DECLARE @ENDD datetime

DECLARE @TIMESHIFT int

SET @TIMESHIFT=datediff(hh, getdate(), getutcdate())

SET @STARTD=DATEADD(d, -1, DATEDIFF(d, 0, GETDATE()))

SET @ENDD=DATEADD(d, 0, DATEDIFF(d, 0, GETDATE()))

SET @STARTD=dateadd(hour,@TIMESHIFT,@STARTD)

SET @ENDD=dateadd(hour,@TIMESHIFT,@ENDD)

SET NOCOUNT ON;

insert into stat_30min

select right(sw.entity,len(sw.entity)-5),stat_id,dateadd(hour,(-1*@TIMESHIFT),sample_time),

CASE

WHEN stat_id=2 or stat_id=16 THEN stat_value/100.0

ELSE stat_value

END

from [VPX].[dbo].[VPXV_HIST_STAT_WEEKLY] sw

where

entity like '%host%' and sw.stat_id in(2,98,16,110)

and sample_time >=@STARTD

and sample_time <@ENDD

END

Néhány megjegyzés a fenti eljáráshoz:

• A @TIMESHIFT tartalmazza az UTC időhöz képest mennyi az eltolódás (nyílván más a nyári és más a téli időszámításban)
• Az előző teljes napot fedik le a @STARD és @ENDD változók
• A %-os statisztikáknál (2 és 16) százszoros értékek vannak, így azt osztom százzal
• A vCenter szerver a hostok azonosítóit 'host-hostid' formában tárolja (pl. host-382), de nekem ebből csak a hostid a fontos, ezért van a lekérdezésben string manipuláció.

A fenti eljárást (és a másik kettőt) megfelelő módon beidőzítve futtatom, így már jelenleg kb. 40-50 napnyi információm van, aminek jó része már a vCenter adatbázisában nincs is meg. (De az öt perces adatok közül én is törlöm a 40 napnál régebbieket, hogy az adatbázisom mérete ne szaladjon el, illetve 40 napnál régebbi adatok esetében valószínűleg elegendő a fél vagy két órás adat is.

Röviden ennyi. Természetesen ez további statisztikákkal bővíthető, illetve a hostok mellett más dolgok (virtuális gépek, datastore-ok,stb) különböző statisztikáit is gyűjtögethetjük. A datastore-okkal kapcsolatban már elkészítettem egy hasonló rendszert, mint amit itt olvashattok, de az a fentiek alapján már mindenki számára könnyen elképzelhető.

Szívesen meghallgatnám a véleményeteket a fentiekről.

Host és VM performancia értékek, statisztikák gyűjtése

Biztosan mindenkivel előfordult már, hogy olyan statisztikai értékekre lett volna szüksége, amiket a vCenter szerver már nem őrzött meg az adatbázisban. Elméletileg lehetséges, hogy akár öt napig is megőrizzünk egy perces értékeket, de tudjuk jól, hogy ez az adatbázissal szemben komoly elvárásokat támasztana (közepes környezet esetében is több száz GB). Nem véletlen, hogy úgy lett kialakítva az adatgyűjtés, hogy hosszútávon csak két órás, vagy napi értékeket tárol le. De mi van akkor, ha van olyan hostunk, vagy vannak olyan virtuális gépeink, amik esetében ez kevés.

A következő néhány bejegyzésben szeretnék olyan módszereket bemutatni, amivel ez lehetséges. Most csak felsorolás szerűen, de két-három továbbiban a módszereket részletesebben is kifejtem.

A Statistics level és az 5 (4,3,2,1) perces értékek megőrzési idejének növelésével.

Ez az a módszer, amit mindenki szabadon alkalmazhat, feltéve, hogy az adatbázis szerverén van elég hely és teljesítményben sincs hiány.
Az alábbi képen a vCenter szerver képernyőképe látható.

Nem érdemes csak kíváncsiságból kísérletezni a beállításokkal, mert azt tapasztaltam, hogy utólag hiába állítunk be alacsonyabb Statistics Level-t, a vSphere kilensben meg fognak jelenni a nagyobb szinthez tartozó statisztikák nevei, értékek viszont nyilvánvalóan nem lesznek hozzá.
A beállítások leírása megtalálható a vSphere Monitoring and Performance dokumentum Monitoring Inventory Objects with Performance Chart fejezetében.

PowerCLI használatával

Aki használja a PowerCLI képességeit más célra is annak ez a módszer tűnhet a legalkalmasabbnak. Mielőtt ebbe bárki belekezd, tisztában kell lennie a az alapvető fogalmakkal (Statistics Level, Statistics Interval, Data Counters, Rollup Type), és persze a PowerShell megfelelő parancsait is ismerni kell. Röviden most csak annyit, hogy a PowerCLI három statisztikákhoz kapcsolódó parancsot biztosít számunkra: Get-Stat, Get-StatInterval, Get-StatType. Az elsővel a konkrét értékeket, a másik kettővel pedig információkat kapunk a lehetséges statisztikákról és intervallumokról. Ha sikerül vele megbarátkozni, akkor már csak arra van szükség, hogy a kapott értékeket valamilyen módon feldolgozzuk. Ha lesz rá időm, akkor ezzel egy külön írásban szeretnék foglalkozni.

Statfeeder használatával

Ez egy egészen új lehetőség (1-2 hetes). Egy megfelelő .xml file-t kell megírnunk, majd paraméterként a Statfeeder-nek megadni. A PowerCLI-hoz képest előnye, hogy ez akár Linux alól is futtatható. Érdekesnek tűnő megoldás, egy-két kezdeti problémával. De kipróbáltam, és teljesen jól használható. Bár a leírás szerint nem csak szöveg file-ba képes írni az adatokat, egyelőre nem tudom, hogy milyen más lehetőség érhető el. Kedvem lenne ezzel is részletesebben foglalkozni, de majd meglátom.

Direkt SQL parancsokkal

Számomra ez a legizgalmasabb, mivel hosszabb ideig foglalkoztam (illetve még mindig foglalkozom) MS SQL szerver üzemeltetéssel, fiatal koromban pedig mint fejlesztő dolgoztam. Itt lehetőségem volt használni régebbi tapasztalataimat. Tulajdonképpen én ezt a módszert használtam amikor azt a feladatot kaptam, hogy készítsek egy olyan alkalmazást, amivel pl. az IS vezetés is le tudja kérdezni az alapvető statisztikákat, akár visszamenőleg hosszabb időre is.
Készítettem egy új adatbázist, amit megfelelő SQL tárolt eljárások segítségével időzítve töltök fel adatokkal. A módszer nagy előnye, hogy esetemben SQL adatbázisból direktben töltök át SQL adatbázisba adatokat, így az azokból való lekérdezéshez semmilyen utófeldolgozás nem szükséges. Mivel ezzel nagyrészt már végeztem, erről egészen biztosan fogok részletesen írni.


Most már csak az a kérdés, hogy mit is kezdjünk az így összegyűjtött adatokkal. Az Excel biztosan mindenkinek eszébe jut, de vannak esetek, amikor már kényelmetlen a használata. De pl. a Crystal Reports, vagy az MS SQL Reporting Service használatával pofás kimutatásokat, diagrammokat tudunk készíteni. Én ez utóbbit használtam, majd bemutatok néhány megoldást ezzel kapcsolatban is.

Röviden most ennyi. Ha ezzel kapcsolatban van megjegyzésetek vagy kérdésetek, akkor szívesen veszem a megjegyzések között.