2013. augusztus 31., szombat

Elérhető VMworld 2013 előadások

Nem emlékszem, hogy az előző években hogy volt, de a mostani rendezvény után közvetlenül elérhetővé tettek néhány előadást.

A kedvencem, bár bevallom még nem néztem végig, a PowerCLI-t bemutató, a megszokottól mélyebb szakmai előadás, természetesen Luc Dekens és Alan Renouf előadásában.

Session VSVC4944- PowerCLI Best Practices: A Deep Dive


A következő a VMware új Log Insight alkalmazásáról szól. Splunk szerű felület, főleg VMware termékekre kihegyezve.

Session VCM7369-S- Uncovering the Hidden Truth in Log Data


Következő kurrens téma a Network virtualization, a VMware NSX.


Session NET5847- NSX: Introducing the World to VMware NSX


Vannak még más témák is, de azoknak a felfedezését rátok bízom. Viszont a két general sesssion-t még beszúrom ide.

Augusztus 26.


Augusztus 27.


Ha keresgéltek, még 3-4 további előadásra is rá lehet lelni.

És a végére egy kérés: Ha még esetleg nem lenne Dropbox accountotok, és szeretnétek, akkor legyetek szívesek ezen a linken keresztül regisztrálni, így segítenétek abban, hogy egy picit növeljem a rendelkezésre álló tárhelyemet: http://db.tt/xKQZXXIt

2013. augusztus 26., hétfő

vSphere 5.5

Mostanság ért véget az amerikai VMworld-ön az első Keynote, amit nagyrészt Pat Gelsinger tartott (CEO). Élóben közvetítették, így meg lehetett nézni/hallgatni.
Úgy tűnik, most már biztosan a Software-Defined Datacenter lesz az az új fogalom, amit nagyon gyakran fogunk hallani. Már egy éve is volt róla szó, de most már sokkal jobban körvonalazódik, mit is jelent ez majd a közeljövőben.
De ami sokunk számára leginkább érdekes lehet, hogy bejelentette a vCloud Suit 5.5-öt, amiben természetesen új Hypervisor is lesz, mégpedig a vSphere 5.5.
Szerintem nem véletlen, hogy csak 5.5 és nem 6.0. Legalábbis abból, ami ott elhangzott, túl nagy újdonságok nem derültek ki. Az biztos, hogy az eddigekhez képest kétszer annyi CPU és memória lehet egy hostban (256 és 4TB). Ez igen soknak tűnik, de a jövőben megjelenő új processzorokkal szerelt szerverekben már simán lehet annyi CPU szál, amit a vSphere 5.1 nem tudna kihasználni. Másrészt pedig lehetővé akarják tenni, hogy "minden" alkalmazás futhasson virtuális gépeken függetlenül attól, hogy mekkora erőforrás igénye is van. Itt is elhagzot egy jelmondat: Apps Love vSphere.
Virtuális gép szinten pedig az eddigi 2TB VMDK méretet növelték meg 64TB-ra.
Bekerül egy új, alkalmazás szintű HA funkció is, de sokat méf arról sem lehet tudni. Az FT sajnos továbbra is csak egy vCPU-t támogat, talán majd a 6.0-ban.
További új funkció a vSphere Flash Read Cache, ami a hostokban lokálisan jelenlévő SSD-k használatát bővíti ki.
Kb. ennyit tudtam kihámozni.
A fentieekn túl volt szó a Software-Defined Storage fogalomról, a virtual SAN-ról, a hálózat virtualizálásról, a Hybrid Service-ről, az új management termékekről (pl. Log Insight)
 
Két érdekes blog bejegyzés a leendő újdonságokról:
 
 
 Illetve itt is sok minden megtalálható: Vladan Seget blogja

2013. június 6., csütörtök

CPU Ready Time (%RDY)

Ha egy virtuális gépnek CPU-hoz köthető teljesítmény problémái vannak, akkor minden ezzel foglalkozó cikk, leírás első helyen említi a CPU Ready Time értékének ellenőrzését. De mit is jelent ez?

A virtualizáció egyik sajátsága, hogy az egy hoston futó virtuális CPU-knak (vCPU) a hypervisor-ban futó scheduler osztja ki a fizikia CPU-kat (pCPU). Ha több vCPU van, mint pCPU, akkor előfordulhat, hogy az egyik virtuális gépben futó vCPU-nak lenne dolga, de mégis várakoznia kell, mivel az őket kiszolgáló pCPU-kat a scheduler éppen másik virtuális gépnek osztotta ki. A várakozással töltött időt nevezzük CPU Ready Time-nak a VMware terminológiában.

Az teljesen természetes, hogy ez az érték nagyobb mint nulla. Az is igaz, hogy kicsi értékek esetén sincs semmilyen észlelhető hatása a teljesítményre. Már csak az a kérdés, hogy mekkora érték esetén kell elkezdenünk aggódni, és keresni a megoldást a nagy érték csökkentésére. Mint általában lenni szokott, itt sem határozható meg konkrét érték. Természetesen szamárvezető van, ami azt mondja, hogy 5%/vCPU fölött már oda kell figyelni, 10%/vCPU fölött pedig már kifejezetten rossz a helyzet.

Ha meg szeretnénk határozni egy konkrét virtuális gép esetében ezt az értéket, akkor ez nem is olyan egyszerű dolog. Nézzük meg, hogy mit látunk, ha a vSphere kliensben a performancia fülön megjelenítjük egy konkrét virtuális gép CPU Ready Time értékét.

Itt bizony ezres nagyságrendű értékeket látunk. Hogy lehet ebből %-ban kifejezni, hogy mennyi a CPU Ready Time egy vCPU esetében? Pirossal bekarikáztam a fontosabb információkat. Ezek szerint a fenti diagram 20 másodpercenként frissül, összegzett értékeket tartalmaz a 20 másodperce vonatkoztatva, és ezredmásodpercben jeleníti meg. Ezek szerint a legutóbbi 20 másodpercből 3806 ezredmásodperc volt a Ready Time értéke. Ha ezt %-ban kifejezzük, akkor  
3806/(20*1000))*100=19.3 értéket kapunk. A 19.3% jóval több, mint az 5%, de még a 10%-ot is jóval meghaladja. Akkor ez a gép most rossz állapotban van? Ehhez tudnunk kell azt is, hogy ebben a virtuális gépben mennyi vCPU van, ugyanis ez a 3806 ezredmásodperc az összes vCPU Ready Time értékének összegét tartalmazza. Lehetőség van arra is, hogy a fenti értéket processzoronként is megnézzük. Látható a lenti ábrán, hogy ebben a gépben 8 virtuális CPU van.
 
 

Végezzük el a számítást egy vCPU-ra is, mondjuk arra, amelyiken ez az érték a legnagyobb.  608/(20*1000))*100=3.04, azaz megközelítőleg 3%. Ez már így sokkal jobban mutat.

A VMware adminoknak van más lehetősége is. A vMA-n keresztül futtathatjuk az resxtop utility-t, amivel mindenféle értéket ki tudunk nyerni a hostból. A lenti képen ugyanezt a virtuális gépet (is) láthatjuk.

 
Itt már egy kicsit gyorsabban juthatunk információhoz, hiszen egyből %-ban látjuk az értékeket. Viszont itt is jó nagy a Ready Time értéke, mivel alapból a nyolc processzor összegét mutatja. Viszont ha megnézzük a virtuális gép részleteit, akkor már itt is barátságosabb számokat látunk.


Adódik a kérdés, hogy mit tehetünk akkor, ha ez az érték tartósan nagy, és ez már érezhető lassulást is okoz. Ezt nem feltétlenül egyszerű megválaszolni, de van néhány lehetőség. Pl.

  • Ha kevesebb vCPU is elég, akkor csökkentsük a vCPU-k számát egy adott virtuális gépben
  • Ha van rá lehetőség, akkor csökkentsük a vCPU/pCPU arányt (mondjuk virtuális gépek áthelyezésével)
  • Nem teszteltem, de azt olvastam, hogy inkább két darab sok vCPU-t tartalmazó gépet futtassunk egy hoston, mint egy darab sok vCPU-s gépet több darab 1-2 vCPU-s géppel
  • Növeljük a fizikai processzorok számát:)

 

 

2013. június 5., szerda

Túlzott erőforrás igények negatív hatásai


Virtuális gépek igénylésekor mindenki igyekszik sok erőforrást kérni a saját szervere számára. Legtöbb esetben többet, mint amire szükség lenne. A fizikai világban nincs semmi negatív hatása annak, ha egy szerverben pl. 4 processzor van, de a rajta futó rendszer megelégedne akár egy processzor is (Maximum a szerver fogyasztása megnő). Sőt itt valóban érdemes már az elején telerakni a gépet processzorral vagy memóriával, mert ki tudja mi lesz akkor, ha bővíteni kellene, de nem lesz rá pénz a későbbiekben.

Sajnos ez a hozzáállás nem változott meg a virtualizáció bevezetése után sem. Nyílván az alkalmazások erőforrás igényeinél is igyekeznek olyan értékeket megadni, amik túl vannak a valós igényeken. Nem egyszer fordult már elő, hogy pl. túlzott lemez igény esetében alkudoztam, végül lényegesen kevesebben egyeztünk meg, és a gép a mai napig üzemel.

Milyen negatív hatása van, ha több erőforrást kérünk a gépünk számára, mint ami szükséges? Fontos dolog, hogy akkor beszélhetünk csak negatív hatásról, ha valamelyik erőforrást túlfoglaltuk. Azaz több memória van kiosztva, mint ami fizikailag a hostban van, vagy több virtuális CPU van az egy hoston futó virtuális gépekben, mint amennyi fizikai mag van bennük.

Túl sok vCPU


Egy operációs rendszer általában feltételezi, hogy az általa kezelt processzorok megközelítőleg azonos órajelen működnek. Ez a fizikai világban nyilvánvaló. Virtualizáció esetén viszont a hypervisor-nak kell biztosítania, hogy az operációs rendszer „azt higgye” hogy minden általa kezelt processzor azonos órajelen működik. Abban az esetben, ha az összes virtuális CPU száma <= mint a fizikai magok száma, akkor ez nem tűnik nehéz feladatnak, hiszen akkor minden vCPU megkap egy fizikai magot, nem kell osztoznia más gépekkel. De a virtualizáció egyik lényege pont az, hogy a meglévő erőforrásokat minél jobban kihasználjuk, ezért egy fizikai CPU-t 2,3,4 vagy még több vCPU-t kiszolgál. Ebben az esetben a hypervisor CPU scheduler-ének a feladata, hogy egy bizonyos algoritmus alapján kiszolgálja az összes virtuális gépet. Nem nehéz belátni, hogy ha több vCPU van, mint pCPU, akkor előfordulhat az, hogy egy több vCPU-t tartalmazó virtuális gép egyik processzora tudna dolgozni, de egy másik vCPU éppen akkor nem kap a scheduler-től processzor erőforrást, így az előző is várakozni kényszerül. Minél több vCPU van egy virtuális gépben, ez annál valószínűbb. Ebből pedig következik, hogy feleslegesen kért több processzor negatívan befolyásolja (befolyásolhatja)a hoston futó összes virtuális gép teljesítményét. Ez nyílván egy bizonyos mértékig nem észlelhető, de eljuthat egy olyan mértékig, amikor már a gép működésén is észre lehet venni.

A másik negatív hatás, hogy a virtuális gép memória overhead-je megnő (több vCPU, több memória igény), ezáltal feleslegesen vesz el memóriát más gépek elől. Ráadásul ez a memória hozzá lesz rendelve a géphez, nem vesz részt a különböző memória optimalizáló eljárásokban.

Sok ilyan igénnyel találkozok, ahol több processzort kérnek a gépbe. Pedig a helyes módszer az lenne (leszámítva persze néhány kivételt), ha egy processzorral indulna a gép, és ha ez a későbbiekben kevésnek bizonyul, lehet növelni a számát. Az újabb operációs rendszerek esetén nem probléma persze a több processzorról átállni egy processzorra, de a régebbiek esetében ezzel lehetnek problémák, így inkább mindig a kevéstől a több felé kellene haladni.

 Túl sok RAM


Itt is igaz amit az előző pont végén írtam, azaz minél több memóriát adunk egy virtuális gépnek, annál nagyobb lesz a memória overhead. (Az a memória mennyiség, amit a virtuális gép futtatásához használ a hypervisor)

Ezen kívül megnő a virtuális gép diszk igénye is. Ráadásul ez két helyen is jelentkezik.
  • az operációs rendszer lapozó file mérete függ a memória mérettől (ez persze szabadon állítható, de pl. egy Windows 2008 R2, ha mást nem mondunk akkor a RAM méretének kb. 150%-át is képes lefoglalni).  Azaz egy 20GB RAM esetén biztosítanunk kell, hogy alapesetben 30GB-os lapozó file-nak legyen hely.
  • a másik pedig az a diszk terület, amit a fizikai host használ abban az esetben ha már semmilyen módszerrel nem tudja kielégíteni a virtuális gépek memória igényét a fizikai memóriájából, ezért kénytelen a virtuális gépnek egy swap területből „memóriát” biztosítani, hasonlóan mint ahogy az általános operációs rendszerek használják a lapozó file-t. Azért, hogy a host ezt minden esetben meg tudja tenni, minden virtuális gép esetében biztosít egy a virtuális gép RAM méretével megegyező diszk területet. Ez talán nem tűnik soknak elsőre, de ha pl. van 15 db 4GB-os gépünk, akkor ez már 60GB. Ha nem bővelkedünk storage területben, akkor igen is számítani tud 10-20GB is.

Túl nagy diszkek


Talán ez a legnyilvánvalóbb. Ha több diszket kérünk egy virtuális géphez, akkor kevesebb marad a többinek. Illetve az olcsónak nem nevezhető SAN-os diszkekből többet kell használni, mint ami valójában szükséges lenne.

Szerencsére a VMware nyújt erre is megoldást. Ez pedig a Thin provisioned diszkek használata. Ez a következőképen működik. Valaki kér a virtuális géphez egy 100GB-os diszket, és persze kap is. Az operációs rendszer számára látszik a 100GB. Viszont a tényleges foglalása a storage-on annyi, amennyit valóban elfoglalnak az állományok, mappák a lemezen. Ha ez 10GB, akkor a tényleges foglalás 10GB. Természetesen ennek vannak előnyei és hátrányai is.
  • nem bánunk pazarlóan a tárterülettel
  • ki tudunk osztani a ténylegesnél több diszket is (pl. egy 500GB-os storage területen akár 1TB szumma diszk igényű virtuális gépet ), viszont
  • monitorozni kell a tényleges helyfoglalást, mert ha az összes hely elfogy, leállnak az azon a területen futó virtuális gépek (storage DRS jól jön ilyen esetben, feltéve ha a legdrágább licensszel rendelkezünk)
  • ha a fentebb említett 100GB-os diszkre a rendszergazda felmásol egy 90GB-os mappát, majd törli azt, akkor ez a törölt terület a storage számára már foglalt marad. (A következő ESX verziók már biztosan fognak erre is megoldást biztosítani a VMware tools-on keresztül)
  • amikor először írunk egy eddig nem használt diszk területre, az lassabban fog megtörténni, mint egy nem Thin provisioned diszk esetében
  • nem mindig használhatunk ilyen diszket (Fault Tolerance és MSCS cluster megköveteli a Thick diszk használatát

Összefoglalva, igyekezzünk mindig csak annyi erőforrást kérni, amennyire szükségünk van. Ha alulméreteztünk valamit, biztosan kérni fogjuk a bővítést, de ha valamiből sok van, szinte biztos hogy nehéz meggyőzni a szerver gazdáit, hogy kevesebbel is hasonló teljesítményre lenne képes a gépe.

2013. május 9., csütörtök

CloudCred

A VMware kb. két hónappal ezelőtt elindított egy "játékot", aminek az a célja, hogy a részt vevők játszva szerezzenek információkat a Cloud technológiáról, miközben kisebb-nagyobb ajándékokhoz is hozzá lehet jutni.
A fődíj nagyon vonzó, hiszen egy komplett két személyes út Barcelonába a VMworld-re, szálással, repülőjeggyel, és némi költőpénzzel. Sajnos ebben az esetben nem a szerencse dönti el a nyertes személyét, hanem a legtöbb pontot elért játékos kapja. Az meg teljesen lehetetlen küldetés. Bevallom én belekezdtem, mint sok minden másba is. Sajnos elég időigényes, és nagy a csábítás, hogy ne csináljak meg mindent teljesen becsületesen. Főleg ha az adott téma nem is nagyon érdekel.
Ha valaki kedvet kapna hozzá, itt nézzen szét: www.cloudcredibility.com



2013. május 2., csütörtök

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

Miután az adatainkat már egy ideje gyűjtögetjük, jó lenne abból olyan riportokat generálni, ami mindenki számára elérhetővé tehető. Ennek nagyon sok módja van, attól függően hogy milyen alkalmazás áll rendelkezésünkre.

Röviden azt szeretném veletek megosztani, hogy Microsoft SQL 2005 Reporting Service használatával én ezt hogy oldottam meg.
Emlékeztetőül, van három táblám, amiben különböző idő intervallumokból származó értékek vannak, van egy tábla ami tartalmazza, hogy milyen statisztikákat gyűjtök, illetve a hostokról és clusterekről vannak információim.

Mivel a táblák csak kódokat tartalmaznak, készítettem három view-t (nézetet), amiben már úgy szerepelnek az adatok, hogy a riportokban könnyen meg tudjam jeleníteni azokat.

Pl. a 30 perces adatok esetében így néz ki:


CREATE VIEW [dbo].[VIEW_STAT_30MIN]
AS
SELECT dbo.CLUSTER.NAME AS Cluster, dbo.HOST.NAME AS Host, dbo.STAT_30MIN.SAMPLE_TIME,
dbo.STAT_30MIN.STAT_VALUE, dbo.STAT_DEF.STAT_NAME,

dbo.STAT_DEF.STAT_UNIT

FROM dbo.CLUSTER ,dbo.HOST, dbo.STAT_30MIN,dbo.STAT_DEF
WHERE dbo.STAT_30MIN.HOST_ID=dbo.HOST.ID and
dbo.HOST.CLUSTER_ID=dbo.CLUSTER.ID and
dbo.STAT_30MIN.STAT_ID=dbo.STAT_DEF.STAT_ID

Ezután már át lehet térni a riport gyártásra. Ehhez az SQL Server Bussines Intelligence Development Studio-t használtam. Indulásként létrehoztam egy új Report Server projektet.

Első lépésként egy Shared Data Source objektumot hoztam létre, ami tartalmazza az adatbázis szerver elérhetőségét, az adatbázisom nevét, és egy olyan accountot, amivel olvasási jogom van az adatbázishoz.


Amikor egy új riport tervezésébe kezdek, meg kell határozni, hogy milyen lekérdezések fogják majd szolgáltatni az adatokat akár a riportban megjelenő adatok számára, akár a riport paramétereinek meghatározásához. Ezeket a lekérdezéseket hívja a riport szerver dataseteknek.
Példként az 5 perces adatok lekérdezését megvalósító riportról írok.

A riport adatait a következő dataset határozza meg:

select * from view_stat_5min where host in (@HOST)
and sample_time>=dateadd("hh",CAST(@START_HOUR as integer),@START)
and sample_time<=dateadd("hh",CAST(@END_HOUR as integer),@END) and stat_name=@STAT order by host,sample_time


A riport paramétereihez pedig a következő kettőt használom:

select HOST.name as H_name from HOST,CLUSTER where HOST.cluster_id=CLUSTER.id
order by CLUSTER.name,HOST.name


select stat_name from stat_def


Az első datasetben a @név olyan változókat definiál, amiknek majd már a konkrét futtatáskor a felhasználó értéket tud adni, így azzal tudja testre szabni a riportot. Látható, hogy vannak @HOST,@START_HOUR,@START,@END_HOUR,@END,@STAT változóim, azaz futtatáskor meg tudjuk majd adni, hogy melyik hostokra, mikortól, meddig és milyen statisztikát szeretnénk megjeleníteni.

Ezeknek a változóknak tudunk kezdeti értéket adni, illetve megadhatjuk azt is, hogy melyik dataset legyen a forrása. Ebben a példában a @HOST változónak az első, míg a @STAT változónak a második dataset szolgáltatja az értékeket.
A kezdeti érték megadásával elérhetjük, hogy a riport indításakor a vélhetően leggyakrabban használatos értékek legyenek előre beállítva. A lenti képen látható, hogy ebben a konkrét esetben az előző nap 8 és 18 óra közti időszak, valamint a cpu.usage statisztika van beállítva.


A fél órás riportok esetén az előző teljes nap (0-24 óra), míg a két órás riportok esetében az előző teljes hét a default intervallum.
A vonal diagram az a típus, ami ebben az esetben a leginkább használható. A lenti képen látható egy konkrét riport, ami három host processzor kihasználtságát mutatja a fenti default idő intervallumban.


A következő képen azt lehet látni, hogy az egyik clusterben lévő hostok memória használatát éppen kiegyenlítette a DRS. Azt hiszem, ilyen ábrát nem is lehet kinyerni a vSphere kliensen keresztül. De javítsatok ki, ha tévednék.



Nagyon jól össze lehet fogni szinte az összes riportot úgy, hogy készítünk egy hagyományos táblázatos lekérdezést a clusterekről és a benne lévő hostokról úgy, hogy tartalmazzon processzor, memória, diszk és hálózati információkat, majd azokat link-ként használva direktben tudunk az egyes riportokra ugrálni.

Mint az elején említettem, eredetileg csak a hostokról készült ilyen módon adat gyűjtés, de azóta már a datastore-ok néhány paraméterét is letárolom, és alkalmas riportokon keresztül lehetőséget biztosítok, hogy akit érint információkat kapjon a VMware környezet ilyen tulajdonságairól is. A lenti példán jól látható, hogy volt storage bővítés, illetve hogyan viszonyul a provisioned kapacitás a ténylegesen használt kapacitáshoz képest egy adott Datacenterben.


Természetesen még mindenféle jópofa diagramot el lehet készíteni, ha van rá igény. Főleg úgy, hogy a kezdeti nagyobb energia és idő ráfordítás után a bővítés már sokkal egyszerűbb.

Végére még egy érdekesség. Természetesen Excelből is el lehet éni az adatokat, ott pedig a Pivot Chart funkciót használva nagyon tetszetős ábrákat lehet gyártani, mint ahogy a lenti ábra is bizonyítja.



Remélem van olyan köztetek, akinek hasznos volt ez a két bejegyzés. Ha mégsem, akkor legalább magamnak lejegyeztem, hogy hogyan is működik ez az egész:)


2013. április 29., hétfő

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.

2013. április 26., péntek

Megjelent a VMware vSphere 5.1 Update 1

Aki arra várt az 5.1 upgrade előtt, hogy megjelenjen az első nagyobb "SP" a vSphere 5.1-hez, annak már nem kell tovább várnia, tegnaptól letölthető az 5.1 U1.

A javítás  a következő komponenseket tartalmazza:

  • VMware ESXi 5.1.0 U1 (release notes)
  • VMware vCenter Server 5.1.0 U1 (release notes)
  • VMware vSphere Data Protection 5.1.10 (release notes)
  • VMware vSphere Replication 5.1.1
  • vSphere Storage Appliance 5.1.3
  • VMware vCenter Orchestrator Appliance 5.1.1
  • VMware vCloud Director 5.1.2
  • VMware vCenter Site Recovery Manager 5.1.1
Úgy gondolom ebből a legtöbbünknek az első három komponens a legfontosabb.

Az ESXi 5.1U1 a számos hibajavítás mellet még több guest operációs rendszert támogat, bár ha ezt meg szeretnénk nézni a VMware Compatibility Guide-ban, akkor még ott nem található hivatkozás az ESXi5.1U1-re.

A vCenter vonatkozásában ugyancsak a számos javítás mellett bekerült új adatbázisok támogatása (pl. MS SQL 2012), illetve most már megadhatunk Custumization Specification-t Windows 8 és 2012-es guest-eknek is.

Régebben írtam többször a VMware VDP-ről, hogy milyen szép meg milyen jó, de sajnos azóta vannak vele rossz tapasztalataim is. Remélhetőleg ez már jobban fog működni. Pl. eddig a felületén nem lehetett a logokból semmit látni. Ha látni akartam, hogy milyen hiba volt, akkor a WinSCP-vel kellett direktben megnézni az appliance-en. Most ez javították.

Van köztetek olyan, aki tényleg az U1 megjelenésére várt az upgrade előtt?

2013. április 23., kedd

VMDK műveletek

Mivel viszonylag még nem túl régen foglalkozok VMware szerver virtualizációval, így biztosan ezért nem találkoztam eddig trükkösebb igényekkel a virtuális gépek diszkjeivel kapcsolatban. Általában a kérések kimerülnek abban, hogy adjak még egy diszket a géphez, vagy növeljem meg valamelyik méretét. Ez utóbbi persze egy Windows 2003-as szerver rendszer partíciója esetében már nem is annyira triviális. Mármint az nem, hogy a Windows-ban a kapott plusz méretet hozzá kell adni a C: particíóhoz. Ez a művelet a többi kötet esetében nem okoz gondot, mert a diskpart segítségével könnyen megcsinálhatjuk. De a diskpart nem használható a rendszerlemez növelésére.
Ehhez szerencsére van egy kis program, amit még a Dell készített, és azt használva a gép kikapcsolása nélkül, futtában képesek vagyunk megnövelni egy 2003 szerver esetében is a C: meghajtót. Aki még esetleg nem ismeri, a Dell honlapjáról letöltheti. Már csak a nevét nem mondtam: az ExtPart.exe-ről van szó.

De ez csak egy kis kitérő volt, nem is erről akartam írni. Hanem arról, hogy kaptam pár nap eltéréssel két feladatot, amit a szokásos eszközeimmel nem tudtam volna megcsinálni.
Az első esetben egy olyan gépről volt szó, amely fizikai szerver virtualizálásával készült. A gépben eredetileg egy darab diszk volt, és két partícióra volt felosztva. 10+40GB. Aki virtualizálta a szervert elfelejtette két külön .VMDK file-ba tenni a két partíciót. Most viszont meg kellett növelni a C: méretét, miközben a D: is tele volt már.
A második esetben pedig az a ritka eset állt elő, amikor valaki azt kérte, hogy vegyük vissza a lemezek méretét. Ez azért történhetett, mert a virtuális gép egy másik klónozásával jött létre, és az eredeti gép esetében szükséges volt a 90GB méret, a klón esetében viszont 30 is elég volt.

Ehhez kellett keresnem valamilyen eszközt. Azt már láttam, hogy van a környezetünkben egy régi GParted (Gnome Partition Editor) nevű .ISO file, így megkerestem annak legújabb kiadását, amit itt meg is találtam.

Egy teszt gép segítségével megnéztem mit tud, hogyan kell használni, stb. Mikor úgy gondoltam, hogy már élesben is tudom használni, nekikezdtem.
A két gép esetében eléggé hasonló dolgokat kellett csinálni. A virtualizált szerver esetében a következő lépéseket hajtottam végre.
  • mentés a gépről
  • egy 15 és egy 40GB-os új diszk hozzáadása
  • ezeket még a kikapcsolás előtt inicializáltam a Windowson belül
  • gép kikapcsolás
  • a GParted CD hozzárendelése a virtuális géphez, majd boot
  • az eredeti lemezről a 10GB-os partíció átmozgatása a 15GB-os új lemezre
  • az eredeti lemezről a 40GB-os partíció átmozgatása a 40GB-os új lemezre
  • a 10GB-os partíció kihúzása a teljes 15GB-os méretre
  • az így keletkezett 15GB-os partíció megjelölése, mint boot partíció
  • a .vmx file módosítása úgy, hogy az scsi:0:0 az új 15GB-os partícióra mutasson
  • miután a CD-t disconnect állapotba tettük, jöhet a bekapcsolás
  • a Windows lefuttatja a chkdsk-t, mielőtt elindul
  • nekem még az indulás után is kért egy újraindítást. Ennek okát pontosan nem tudom (valaki?)
  • a lemez kezelőben ellenőrizni kell, hogy a többi prtíció rendben látszik-e. Ha kell, akkor a megfelelő meghajtó nevet hozzá kell rendelni
  • végül a feleslegessé vált eredeti 50GB-os lemez törlése. Itt egy kicsit zavaró lehet, ha csak a virtuális gép tulajdonságaira hagyatkozunk. Nem biztos, hogy mindent jól mutat. Érdemes megnézni a datastore-on is, hogy melyik méretű .VMDK file-nak mi a neve.
  • végül egy storage vMotion, hogy az előbbi bizonytalanságot megszüntessük.

A másik gép esetében is hasonlóan jártam el, csak ott mielőtt az új diszkre pakoltam volna a partíciót, előtte át kellett méretezni, hogy elférjen a kisebb lemezen is.

Ha van ettől egyszerűbb módszer a tarsolyotokban, szívesen venném ha megosztanátok velem.


2013. április 20., szombat

vOpenData – nyílt közösségi virtualizációs adatbázis projekt

Ben Thomas és William Lam közösen elhatározták, hogy megpróbálnak létrehozni egy olyan adatbázist, amiből válaszokat kaphatunk pl. a következő kérdésekre:

- mekkora egy átlagos VM mérete?
- átlagosan hány hostot tartalmaz egy cluster?
- átlagosan hány cluster van egy infrastruktúrában
- stb.

Természetesen ilyen adatokat csak akkor tudunk kinyerni, ha minél több valós infrastruktúra adata kerül bele. Itt jövünk mi a képbe. Létrehoztak egy scriptet (pontosabban kettőt, egyet PowerCLI, egyet pedig Perl nyelven), amit ha futtatunk, és az így kapott .zip file-t feltöltjük, akkor mi is hozzájárultunk az adatgyűjtéshez.
A gyűjtött információk semmilyen beazonosítható adatot nem tartalmaznak, csak technikai értékeket. Bár gondolom ez még nem nyugtat meg mindenkit, illetve valószínűleg a munkáltató engedélye is kell a projektben való részvételhez. Ezt mindenki saját maga dönti el, hogy szerinte van-e értelme az ilyen kezdeményezésnek. Ha van, akkor érdemes hozzájárulni a sikeréhez. Rövid idő alatt már több mint 68000 virtuális gép adata került fel, így már tényleges következtetéseket is le lehet vonni.

Ha többet akartok tudni róla, akkor látogassatok ide: http://www.vopendata.org/
De ha csak ha a statisztikákat akarjátok látni, akkor ide: http://dash.vopendata.org/public
Ez utóbbi nekem IE használatával nem működik, lehet hogy csak helyi porobléma. Firefox alatt viszont minden rendben.

Kíváncsi lennék rá, hogy közületek lesz-e valaki, aki támogatja a projektet. Illetve még valami. Annak is érdemes letöltenie a scriptet, aki tanulni szeretne belőle. Én ezt tettem.

2013. április 14., vasárnap

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.

2013. április 6., szombat

Top 10 Virtualizációs és VMware blog

Minden évben Eric Siebert a saját blogján meghirdet egy blogger "versenyt", amely évről évre népszerűbb. Mindig jelennek meg újabb bloggerek, de vannak akik már évek óta a legjobbak között szerepelnek. Az első 10 helyezett blogról szeretnék megosztani veletek néhány információt.
Én a magam részéről napi rendszerességgel olvasom őket (természetesen RSS használatával), így nagyon sok információ birtokába lehet jutni.
Ha valaki nem ismeri valamelyik blogot a lentiek közül, annak érdemes pár percet rászánnia, biztosan fog pár érdekességet találni.

Akkor nézzük az idei verseny első 10 helyezettjét.

1. Yellow Bricks (Duncan Epping)

Mint a Clustering Deepdive könyvek egyik szerzője, leginkább erőforrás kezeléssel, DRS és HA működésével, vCloud használatával kapcsolatban ír. Nagyon termékeny, nem véletlenül lett az első.

2. Frank Denneman blogja

A fentebb említett könyvek másik szerzője. Ennek megfelelően hasonló témában jelennek meg cikkei, de nagyon gyakran egy adott problémát, érdekességet jár körbe. Ezek mellett időnként jövőbeli vSphere funkciókról is olvashatunk. Volt szerencsém több előadáson részt venni, ahol Frank Denneman és Duncan Epping volt az előadó, és minden ilyen alkalom nagy élmény volt.

3. Scott Lowe blogja

Virtualizáció, storage és network. Mindhárom témában nagyon sok érdekes és hasznos cikk olvasható. De én leginkább a Mastering VMware vSphere 5 könyvéről ismerem. Amikor a VCP5 vizsgámra készültem, ez a könyv volt a fő forrásom. Rendkívül részletes, olvasmányos.

4. NTPro.nl (Eric Sloof)

Alig van olyan nap, amikor nem jelenik meg új bejegyzése. Mivel főleg oktatással foglalkozik, ezért cikkei is ezen téma köré csoportosulnak. Minden infót megtalálhatunk új tanfolyamokról, vizsga lehetőségekről, oktató videókról, könyvekről, White Paper megjelenésekről, flingeről, stb.

5. Virtual Geek (Chad Sakac)

Minden ami EMC és VMware. Ennek megfelelően főleg storage jellegű írásai vannak. Mély technikai jellegű írások.

6. Virtually Ghetto (William Lam)

Mint ahogy blogjának alcímében írja, VMware scripts & resources. Olyan scriptek fűződnek a nevéhez, mint a vmwarevSphereHealthCheck.pl, vagy vmwarevSphereSecurityHardeningReportCheck.pl, vagy a sokak által ismert ghettoVCB. Persze ezek mellett sok más információt, technikai érdekességet találhatunk a blogjában. Jellemzően kb. 100 hasznos bejegyzés évenként!!

7. Mike Laverick blogja

Sok hasznos és részletes cikk a vSphere környezet használatáról, beállításokról, stb. Főleg oktatási céllal megírt bejegyzések. Nincs saját blogja, írása a VMware saját blogjai között jelennek meg.

8. Virtu-al (Alan Renouf)

Ha PowerCLI, akkor Alan Renouf (és persze Luc Dekens). Elképesztő mennyiségű scriptet írt és osztott meg az érdeklődőkkel. Ha ilyen jellegű problémának van, biztosan kapunk rá választ. Vagy a blog olvasása során, vagy  fórumban feltett kérdésünkre adott válaszán keresztül. De nekem a legnagyobb segítséget a vCheck script gyűjtemény megírásával segített. Erről már írtam itt is régebben.
Nagy élmény amikor párban Luc Dekens-sel előadást tartanak. Mindketten nagyon nagy fejek.

9. Cormac Hogan blogja

Ő az egyetlen a 10-ből, akinek nem követem az írásait. Így ez meglepetés marad mindenki számára (mindenki alatt azt a néhány embert értem, aki ezt olvassa...). Illetve még abban is kilóg a sorból, hogy az előző években nem szerepelt a blogja a listákon, tehát új bloggernek számít.

10. vSphere-land (Eric Siebert)

Mint a bevezetőben említettem, az ő blogján történt a szavazás. A teljes lista itt található.
Neki az előkelő 10.-dik helyet sikerült megszereznie:) E mellett természetesen más jellegű írások is találhatók a blogjában. (pl. egy nagyon részletes link gyűjteményt)

Ők 10-en kapták a legtöbb szavazatot. Persze ez nem jelenti azt, hogy mások ne lennének ennyire jók, de valamiért a szavazóknak ezek a blogok tetszettek leginkább.
Én a fentieken kívül még hasznosnak tartom pl. Kendrick Coleman, Andre Leibovoci, Luc Dekens, Vladan Seget blogját is, és persze fel-fel bukkan mindenfél hasznos írás mások blogján is.

Ha valakinek van ötlete, hogy mit érdemes olvasni a Neten annak, aki napi szinten tájékozott szeretne maradni, akkor a hozzászólások között bátran ossza meg másokkal is. (Hátha most majd lesz végre hozzászólás is...)