Csabi IT blogja

Gyakorlat (t)eszi a mestert

Csaba Somogyi — Fri, 06 Mar 2009 19:02:23 GMT

A napokban nekiveselkedtem a demózáshoz használt rendszerünk (alapos) újjáépítésének és az eközben szerzett tapasztalatokat szeretném megosztani ebben a kis cikkben. Persze az is kiderül a végére, hogy miért is eszi a gyakorlat a “mestert” (és főleg annak...(read more)

Éles bevetésen a Core configurator

Csaba Somogyi — Fri, 10 Oct 2008 09:26:55 GMT

A bevetés azért nem annyira éles, de egy demóra készülve eljött az ideje, hogy kipróbáljam, mennyit segít a kis alkalmazás a Server Core konfigurálásában. A kísérlet alanya egy leendő tartományvezérlő, ami még némi fájlkiszolgálói feladatot is kapni fog,...(read more)

Könnyű szívvel…

Csaba Somogyi — Thu, 02 Oct 2008 09:33:23 GMT

…avagy: Server Core könnyedén. A címben van egy kis nyelvészkedés, de a lényeg a kis alkalmazás, amiről szó van. Olyan, mint egy fájdalomcsillapító, mert bizony vannak műveletek, amiket nem egyszerű elvégezni a Server Core-on. De most talán változik a...(read more)

Technológiák és emberek

Csaba Somogyi — Mon, 18 Aug 2008 16:14:00 GMT

Technorati Tags: IT , emberek Nemrégiben egy zártkörű szakmai konferencián vettem részt Seattle-ben és meglepő tanulságokkal szolgált, amikor végiggondoltam az ottani eseményeket. Először is technológiai szempontból sokkal szürkébb volt az esemény, mint...(read more)

Szerverkonszolidáció -apró ötletek az első lépésekhez

Csaba Somogyi — Tue, 01 Jul 2008 19:10:56 GMT

A TechNet Magazin júniusi számában megjelent cikkem teljes változata. Valamivel több képpel. Különös aktualitása a dolognak, hogy két nappal a Hyper-V RTM megjelenése előtt került nyomdába. Technorati Tags: virtualizáció , Hyper-V A virtualizációs...(read more)

Az árva tartományok esete a globális katalógusokkal

Csaba Somogyi — Thu, 13 Mar 2008 16:58:35 GMT

Sejtelmesen hangzik talán a cím, de ez nem egy krimi. Inkább egy aprócska esettanulmány.

Az utóbbi évben két alkalommal futottam össze hasonló esettel, gondoltam hát, megosztom a történetet. Persze a rutinos, sokat látott kollégák csak meghúzzák majd a vállukat: hm, igen vannak ilyen helyzetek, de simán megoldjuk. Lehet, hogy ők igen, de a kevésbé rutinosak talán megtakaríthatnak néhány órányi bosszúságot, ha összefutnak egy ilyen szituációval és tudják mi a megoldása.

A történet főszereplői az árva tartományok és a globális katalógusok. Ők így ebben az összeállításban kölcsönösen kizárják egymást, a történet lényege ugyanis éppen az, hogy amíg léteznek árva tartományok, addig nem lesznek új globális katalógusaink.

De mit is nevezünk árva tartománynak? Azokat, amelyeknek már nincs a hálózaton elérhető tartományvezérlőjük, tehát jó eséllyel már megszűntek. A megszűnés módja viszont nem a dcpromo volt (és az utolsó tartományvezérlő bejelölése), hanem egyszerűen eltűntek a bitködben.

Na ebben az esetben jönnek a gondok, ha újabb globális katalógust akarunk életre kelteni. A directory service ugyanis tudja a leckét és keresi-keresi a hiányzó tartományt és próbálkozik szorgalmasan az objektumok szinkronizálásával. De mivel ezzel sosem jut előbbre, hiszen nincs tartományvezérlő ami az adatokat tartalmazza, ezért nem tud mást tenni, mint belesírja ezt a bánatát az eseménynaplóba. Legnagyobb bánatunkra kékkel sír - tehát az esemény csupán információ (x. tartományvezérlő előléptetése globális katalógussá késik, mert y.z tartomány nem elérhető). És.... nem lép elő a tartományvezérlőnk globális katalógussá.

Itt kezdődött a kollégáim kálváriája. Kezdetben csak csodálkoztak, hogy miért áll le a felhasználók beléptetése (meg még jópár dolog), amikor az egyik tartományvezérlőt karbantartják. Aztán amikor megadta magát a gép RAID kontrollere és leállt szerver, akkor égetővé vált a probléma. A másik esetben még izgalmasabb lett a helyzet, mert az egyetlen működő globális katalógus egy kivonásra jelölt tartományvezérlő volt és meg is kezdték a kivonását. Global catalog pipa kivesz, OK gomb megnyom és innentől kezdve leáll a tartomány. Maguk a tartományvezérlők sem léptetik be még a rendszergazdákat sem. Az egyetlen esély az autoritive restore-on túl, ha van még olyan gép, amelyiken van belépett tartományi rendszergazda felhasználó és ő tudja, hogy hová kell ilyenkor kapni.

Ide kell: http://support.microsoft.com/kb/230306/en-us.

Az elárvult tartományokat az ntdsutil nevű létfontosságú szerszámmal tehetjük jól megérdemelt helyükre: a kukába. A procedúra közben teljesen normális, ha kicsit remeg a kezünk, hiszen ilyenkor egy éles szikével kotorászunk az Active Directory belsejében. Nem árt tehát, ha a kezünket és a szemünket fokozott syntax checking és audit módba kapcsoljuk. Viszont ha ügyesen végigcsináltuk a folyamatot, akkor néhány percen belül elhárulnak az akadályok az új globális katalógus létrehozása elől és megérkezik a régvárt üzenet: Server x. is now a global catalog.

Tanulságok? Van több is.

Tartományokat nem hozunk létre össze-vissza. Ha pedig létrehoztuk őket, akkor szabályosan szüntessük meg őket. Vannak persze extrém esetek, mint a kollégák esetében is, ahol az elárvult tartományokat a világ másik végén hozták létre, majd hagyták magukra.
Tartsuk a rendszergazdák és főleg az Enterprise Admin-ok számát a minimumon, és ezek az emberek értsék a dolgukat és kommunikáljanak egymással! (Ez sokat segíthet akkor is, ha a világ eltérő sarkaiban dolgoznak.)
Az új globális katalógus létrehozása nem egyenlő a pipa bekattintásával. A folyamat vége a sikert jelző eseménynapló bejegyzés, amíg nincs ilyenünk, addig gyanakodjunk.
Tartomány egy globális katalógussal nem igazán tartomány. Éljenek a virtuális tartományvezérlők és globális katalógusok!

Ha már iSCSi ...

Csaba Somogyi — Thu, 21 Feb 2008 16:42:26 GMT

Technorati Tags: Windows Server 2008,iSCSi

Néhány nappal ezelőtt Petrényi Józsi barátom szépen felpakolta az érdeklődőket egy ökrös szekérre és végigrázatta őket az iSCSi göröngyös országútján. Most viszont ne tessék még felugrálni, sőt kérjük a biztonsági öveket is szorosabbra húzni, mert egy kis kerülőút erejéig befordulunk egyenest a szántásba!

Igazán nagyszerű ötlet a Server Core telepítési opció. Nem kell a grafikus felülettel bajlódni, meg toldozni-foldozni. Kevéssel beéri, elég ha erőforrás morzsákat potyogtatunk elébe.

Igen ám, de mi van akkor, ha valami trükkösebb konfigurációba szeretnénk bevonni? Mondjuk az elvetemült példa kedvéért egy iSCSi-ra épülő fürtbe? Hm. Simítsuk ki a ráncokat a homlokunkon, pörgessük fel az ujjainkat a billentyűzeten és lássunk neki!

Meglepő módon egy egyszerű konfiguráció létrehozása nem is annyira bonyolult. De ha valaki mélyebben beleszalad az iSCSicli parancs opcióinak és paramétereinek szövevényébe, akkor hamar a dzsungelben érezheti magát. Mi most legyünk jó turisták és csak tisztes távolból lessünk be a sűrűbe!

(A példában feltételezzük, hogy az iSCSi Storage kiszolgálónk harcra kész, tehát létrehoztuk a megfelelő diszkeket és előkészítettük a használatra.)

Az első feladatunk az iSCSi Initiator felélesztése. A szolgáltatás alapértelmezésben telepítve van, csak engedélyezzük és indítsuk el:

sc config msiSCSI start= auto

net start msiSCSI

Ha ezzel megvagyunk, akkor egyúttal a szükséges tűzfalszabályok is életbeléptek, tehát az iniciátorunk "átlát" a tűzfalunkon. Apropó tűzfal. Hogy később majd visszatérhessünk egérvezérelt üzemmódba, ne felejtsük el engedélyezni a szerverünk távoli felügyeletét!

netsh advfirewall firewall set rule group="Remote Administration" new enable=yes

netsh advfirewall firewall set rule group="Remote Volume Management" new enable=yes

Most már felvehetjük a kapcsolatot az iSCSi Storage kiszolgálóval:

iSCSIcli QAddTargetPortal <ide jön a Storage IP címe>

Ezzel bekopogtattunk a kliensünkkel a kiszolgálóra, a következő lépések előtt rendeljük hozzá az iniciátorunkat a storage kiszolgálón a megfelelő diszkekhez (fürt esetén adjuk meg az összes érintett gépet, mint a fürt tagját)!

(Érdemes felfigyelni a Q betűre az AddTargetPortal parancs elején. Ez egyfajta shortcut parancsot jelöl: a legalapvetőbb műveleteket ilyen Q kezdetű parancsokkal tudjuk elvégezni, anélkül hogy belevesznénk a paraméterezésbe.)

Visszatérve a Server Core-t futtató géphez ismételjük meg az előbbi parancsot! (Azért kell, hogy kikényszerítsük a konfiguráció frissülését.)

iSCSIcli QAddTargetPortal <ide jön a Storage IP címe>

Kérdezzük le az elérhető kiszolgálók listáját!

iSCSIcli ListTargets

Ha mindent helyesen csináltunk idáig, akkor a visszaadott listában szerepel a kiszemelt kiszolgáló IQN neve (is). Ha csak a kiszolgáló IP címét látjuk, akkor kapcsoljunk át hibakereső üzemmódba, mert valamelyik korábbi lépés nem volt sikeres.

Ha megvan az IQN, akkor jelentkezzünk be a kiszolgálóra:

iSCSIcli QloginTarget <kiszolgáló IQN> <CHAP felhasználói név> <CHAP jelszó>

Akkor voltunk sikeresek, ha a kiszolgáló egy session ID-val válaszol. Viszont a kapcsolatunk még nem tartós, a következő újraindításkor elvész. Tegyük tartóssá!

iSCSIcli PersistentLoginTarget <kiszolgáló IQN> T * * * * * * * * * * * * * * * 0

Nem csalás, nem ámítás: a T után 15-ször szerepel a szóköz+* kombináció, majd szóköz+nulla zárja a sort. Aki utánajár, hogy miért pont így, az kap egy nyalókát, mindenesetre a dolog működik - kipróbáltam.

Ellenőrzésképpen nézzük meg a tartós kapcsolataink listáját!

iSCSIcli ListPersistentTargets

Ha itt megtaláljuk a kiszolgálónkat, akkor már nyert ügyünk van, de azért nézzük meg, hogy látszanak-e a kiosztott diszkek:

iSCSIcli ReportTargetMappings

Ne lepődjünk meg, ha valami rettenetes listát kapunk vissza, az sokkal jobb, mintha nem jönne vissza semmi.

Most már nyugodtan elkezdhetünk egerészni, menjünk át egy grafikus felülettel rendelkező gépre, kapcsolódjunk a Server Core-hoz a Computer Management MMC-ből, tegyünk online-ba a diszkeket, formázzuk meg és használjuk! Most már akár egy fürtbe is bevonhatjuk a gépünket, a konfigurációs varázsló szemrebbenés nélkül el fogja fogadni.

Kiértünk a szántásból, ki lehet oldani a biztonsági öveket, az utaskísérő hamarosan felszolgálja a pezsgőt, mert az iSCSI grafikus konfigurálása ehhez képest már pezsgős vacsora.

Merre kanyarodik az út?

Csaba Somogyi — Sun, 10 Feb 2008 12:29:58 GMT

Technorati Tags: Windows Server 2008,Virtualizáció

Bátorfi Zsolt kollégám Seattle felé röptében remek cikket írt arról, mi minden várható 2008-ban a Microsoft server platformjait illetően. Úgy látszik a repülés monotonitása és azok a remek zenék, amiket Zsolt hallgatni szokott ismét hatottak, mert remek összefoglalás született, ami ugyanakkor tele van kérdésekkel és várakozással. Kicsit hasonlít ez ahhoz, ahogy a kisgyerekek várják a karácsonyt (főleg, ha már nem az elsőt): tudják, hogy eljön, tudják, hogy jó lesz és biztosan kapnak valamilyen ajándékot, még ha nem is tudják pontosan mit. Legfeljebb reménykednek, hogy azt kapják, amire leginkább vágynak.

Szerintem a hazai üzemeltetői közösség jelentős része ugyanígy várta a Windows Server 2008-at. És a következő néhány bekezdésben nem is igazán az új operációs rendszert szeretném méltatni, azt megtesszük kollégáimmal sokszor, sok helyen. Inkább azokat a gondolataimat osztanám meg, amik arról szólnak, hogyan változik/változhat meg a munkánk, a napi életünk az új rendszer hatására.

Szép dolog ez a virtualizációs történet: érdekes a technológia, az alkalmazás sokféle lehetősége. Szeretek ezzel foglalkozni és másokat is erre bíztatni, és itt most nem jön "de", ahogy az általában jönni szokott. Inkább jön egy "és".

ÉS mostanában el-elgondolkozom azon, hogyan hat majd az egyre terjeszkedő virtualizáció az emberre? Arra az emberre, aki kitalálja, felépíti és üzemelteti. Arra, aki csak használja vagy éppen nem is tud róla, hogy használja. És arra aki, egyre nehezebben tudja eldönteni, hogy mi az az életében ami valóságos, és mi az ami virtuális (tehát csak látszat).

A kérdéskör első felére viszonylag könnyebb válaszokat adni, a magam véleményét most meg is írom. A második kör messzebbre vezet, arról egyszer majd talán a nem szakmai blogomban írok hosszabban.

A Windows Server 2008 egyik legfontosabb technológiai kihatása reményeink szerint a virtualizáció erőteljesebb terjedése lesz (a termék ára is ezért van 30 dollár körül). A technológiai részletek itt és most nem számítanak.

A virtualizáció előbb vagy utóbb meg kell hogy változtassa az üzemeltetői szemléletet. A "hány szerveretek van?" kérdést fel kell hogy váltsa a "mennyi erőforrásotok van?" kérdés. És a válasz természetszerűen összetettebb lesz, hiszen egy egyszerű szám helyett processzor ciklusokat, esetleg gigahertzeket, teraflop-okat mondunk majd, és terabájtos tárkapacitásokat mind diszken, mind memóriában.

Amikor pedig figyelembe vesszük, hogy a Windows Server 2008 immár szolgáltatás modellekben "gondolkodik" és ennek megfelelően épül fel egy-egy kiszolgáló saját szolgáltatás portfóliója, akkor még esetleg zavarba is jövünk. Pedig megint csak "erre kanyarodik az út". Ez a szemléletmód egyre több helyen, egyre több termékben fog megjelenni. (Ahogy már látszik is sok helyen: Exchange és ISA Best Practice Analyzer, SC Configuration Manager - elvárt konfiguráció, SC Operations Manager - egészség modell). Nem szerverekre tervezünk ezentúl, hanem erőforrás blokkokra vagy virtuális kiszolgálókra, a szolgáltatások pedig az általunk megadott szabályok szerint "élik az életüket". Ez a DSI víziója, amivel ha eddig nem is, de most már ideje mindenkinek barátkozni.

Amikor pedig a két történet összeér, akkor az üzemeltetői gondolkodásnak is változnia kell. Az erőforrások véglegesen elszakadnak a fizikai hardvertől. A hideg vas nem lesz más, mint a rendelkezésre álló erőforrások (számítási és tárolási kapacitás, hálózati kapcsolatok stb.) egy fizikai szeletkéje, ami éppen otthont ad bizonyos szolgáltatásoknak: pillanatnyilag és gyakran változóan. A kapacitással pedig valakinek tudatosan gazdálkodni kell, még pedig takarékosan és mértéktartóan. Mindenre kell hogy jusson elegendő, ami kitűzött (üzleti vagy egyéb) célokhoz nélkülözhetetlen, de a szükséges tartalékokon felül egyetlen bájtot, egyetlen processzor ciklust sem használhatunk feleslegesen. Erre szorít majd bennünket az üzleti világ, ami az élesedő piaci verseny miatt minden fillért és centet számon fog tartani és erre kényszerít bennünket a környezet védelme, amiről nyilvánvalóan nem lehet a jövőben "csak" beszélni, mert a végén egy pálma alatt sülünk meg a saját zsírunkban az Andrássy úton.

A jövő üzemeltetői tehát erőforrás készletekben és szolgáltatásokban kell hogy gondolkodjanak a jövőben. Fel fog értékelődni a modell- és szabályalkotási képesség, ami nélkülözhetetlen lesz a szolgáltatások elvárt viselkedésének meghatározásához és a rendellenes viselkedések okainak feltárásához. Ráadásul az egyes modelleket össze kell tudni hangolni, helyesen be kell tudni állítani köztük az elsőbbségi viszonyokat és az arányokat. Nem lesz elegendő tehát a szakmai tapasztalat és a diagnosztikai készség: módszeres mérnöki tudásra lesz szükség, széles látókörre és rugalmas gondolkodásmódra. A jövő új szoftverei jelentős tudást fognak magukkal hozni. Leírják önmagukat, a számukra legoptimálisabb működési környezetet, a nem rendeltetésszerű működés jelenségeit és elhárításuk módját. Ezek az információk a szolgáltatás- és egészségmodellekben rendelkezésre fognak állni. A sok-sok egyedi modellt azonban össze kell majd fogni egy-egy vállalati szintű szupermodellbe (nem Claudia Schiffer-re gondolok :-)), ami minden helyen egyedileg alakul ki, hiszen egyedi az alkalmazott technológiák köre és összetétele (jobb esetben általános modellekből a leghasonlóbbat igazíthatjuk majd a magunk arculatára). A szupermodell lesz az informatikai szolgáltatások alfája és omegája. Olyan összetett informatikai ökoszisztéma megjelenítési formája, amit legalább néhány embernek át kell látnia, hogy érthető legyen a rendszerek viselkedése és követhetőek a benne zajló folyamatok. És akkor még nem beszéltünk arról, hogy a rendszer folyamatosan változni fog...

A Windows Server 2008 üzenete tehát szerintem nem pusztán technológiai üzenet, hanem egyben valahol mélyen emberi kérdés is: készen állunk-e a önmagunk folyamatos megváltoztatására? Carpe diem vagy γνῶθι σεαυτόν (gnothi seauton)?

Tervezni csak pontosan szépen...

Csaba Somogyi — Tue, 05 Feb 2008 12:34:31 GMT

Technorati Tags: System Center,Capacity Planner 2007

A jól ismert József Attila verssor jutott eszembe a System Center Capacity Planner 2007 bejelentését olvasva, ezért választottam a cikk mottójául (kis módosítással).

Az utóbbi másfél-két év során sokat írtunk, beszéltünk a Dynamic Systems Initiative-ról (DSI), ami a Microsoft víziója a dinamikus, önfelügyelő és nagyrészt virtualizációra épülő informatikai rendszerekről. Elmondtuk, leírtuk azt is, hogy a megvalósítás útja az egyes rendszerek modelljeinek megalkotása lesz (az XML alapú Service Modeling Language segítségével), ami tartalmazza a rendszer függőségeit, teljesítmény elvárásait, egészség kritériumait.

A System Center termékcsalád egyes tagjaiban (Operations Manager, Configuration Manager), az Exchange Server 2007-ben, az ISA Server 2006-ban (Best Practices Analyzer) és magában a Windows Server 2008-ban (Server Manager) máris láthatjuk a modelleket működés közben.

A Capacity Planner 2007-tel pedig kapunk egy olyan modellező eszközt, amivel a valós üzemeltetési tapasztalatokból felépített kapacitás modellek segítségével aprólékosan megtervezhetjük rendszereinket, különös tekintettel az erőforrások méretezésére.

Az SCCP segíthet abban, hogy költséges és időrabló tesztelés nélkül készíthessünk jól skálázható modellt a tervezett rendszerről, gyorsan készíthessünk alternatív javaslatokat és megismerhessük az egyes komponensek módosításának hatását a rendszer egészére. Nem is beszélve arról, hogy konkrét adatokkal tudjuk alátámasztani az eszközigényeket, illetve adatokkal jelezhetjük mivel jár, ha egyes komponenseket kisebb teljesítményűvel helyettesítünk.

A System Center Capacity Planner 2007 alapkiépítésben az Exchange 2007 kapacitás modelljét tartalmazza, hamarosan (2. negyedév) elérhető lesz az Operations Manager végleges kapacitás modellje és a Sharepoint 2007 modellje is, majd folyamatosan érkeznek a további modellek is. A termék ingyenes, letölthető az alábbi linkről:

http://www.microsoft.com/downloads/details.aspx?FamilyId=E754F35D-59DB-4BC4-8386-E83E66A16FAD&displaylang=en

A házi datacenter -2.

Csaba Somogyi — Wed, 30 Jan 2008 15:07:05 GMT

Technorati Tags: Windows Server 2008,Windows Home Server,Hyper-V

Kicsit lemaradtam a házi datacenter történettel, mentségemre szóljon, hogy meglehetősen sűrű volt az elmúlt néhány hét, és a következők sem tűnnek lazábbnak.

Valahol ott hagytam abba, hogy egy időre leragadtam a router-be dugott USB diszkes NAS-nál. Aztán jött egy lehetőség, és egy már reménytelennek ítélt kifizetetlen munkáért cserébe válogathattam némi hardvert magamnak. Sikerült is öszelapátolnom egy elég csinos kupacot, ami most valahogy így néz ki:

Az egész rendszer lelke egy Intel DQ965GF alaplap, ami elég jó választás volt, ha a szükséges kompromisszumokat is meggondolom. Egyrészt nem akartam nagy házat a gép köré, ki is néztem az A-Cube 1606 nevű dobozt (tágas, mégis kicsi, könnyen vihető). Másrész a ház mérete miatt csak mikroATX-es alaplap jöhetett szóba. Plusz figyelni kellett arra, hogy legyen meg az a két fontos tulajdonság, ami a Hyper-V futattásához kell: a Hardware assisted virtualization és a Data Execution Prevention. Cserébe feladtam a több fizikai processzor lehetőségét, de legagalább a Quad-okat támogatja a lap.

Került még a dobozba egy Intel 6420-as processzor (ennyi fért a keretbe, de majd kinövi magát előbb-utóbb egy Q6700-ra), aztán 8 GB RAM, és 3 SATA2 diszk (+ még kettő külső: egy USB-s és egy FireWire - ezeken laknak az ISO file-ok és részben a Home Server-em). Hogy az 5.25"-ös hely se maradjon kihasználatlanul, oda került egy ASUS DVD-író.

A diszkek története kicsit hosszadalmasabb. Lepenye Tamás kollégámmal beszélgettük egyszer arról, hogy talán a diszkek sebessége most a legszűkebb keresztmetszet a virtuális rendszerekben, főleg olyan kis demóra szánt esetekben, mint amiket mi használunk. Végül abban maradtunk, hogy a legjobb megoldás az, ha külön diszken van az operációs rendszer, a virtuális diszkek és mondjuk a pagefile (arra az esetre, ha kifutnánk a fizikai memóriából és a gépünknek hirtelen szüksége lenne többletre). Ez nagyjából meg is valósul nálam, igaz a pagefile mellé én még csempésztem némi statikus tartalmat (a DVD-be égetésre váró cuccokat).

A motyó szépen összeállt, és most valahogy így néz ki (ez persze nem a saját gépem, mert az egy sötét gardrób mélyén teszi a dolgát, ahol szinte lehetetlen lefotózni).

Szoftverileg természetesen Windows Server 2008 RC1 (build 17119) fut rajta Hyper-V szerepkörrel és változó számú virtuális masinériával. Most éppen 137 óra az uptime-ja (a múlt héten kellett egy demóhoz és fájó szívvel le kellett lőnöm, akkor 396 óra volt benne...).

A reklám után, amikor visszatérek, akkor elmesélem hogyan lett Home Server-em.

A parancssor ereje legyen velünk

Csaba Somogyi — Wed, 30 Jan 2008 13:25:55 GMT

Technorati Tags: Windows Server 2008,Hyper-V,Server Core

Azzal biztosan nem mondok újat, hogy a Hyper-V szerepkör a Server Core-ra is telepíthető. Sőt! Éppen ez a preferált konfiguráció, mert ez foglalja a legkevesebbet az egyébként nagyon értékes erőforrásokból, mint a fizikai memória és a diszk. Amikor pedig végképp kibújik belőlünk a maximalista IT-s, akkor a Server Core-okat failover cluster-be rendezzük, és ezeken tenyésztjük tovább a virtuális gépeket.

De hogy a csodában kell ezt az egészet beizzítani?

Valahogy így:

1. Telepítsd fel a Windows Server 2008-at a Core opcióval.

2. Állíts be egy erős rendszergazda jelszót ezzel a paranccsal, aztán reboot:

net user administrator <valami nagyon erős jelszó>

shutdown /r /t 0

3. Nevezd át gépet (ami azért is jó, mert 3 perc múlva úgysem emlékeznél az alapértelmezett nevére)

netdom renamecomputer %computername% /newname:<egy konvenció szerinti gépnév>

shutdown /r /t 0

4. Tedd a gépet domain-ba, mert úgy sokkal egyszerűbb lesz felügyelni (ha ezt nem akarod, akkor legalább tartósan csatold fel a felügyeletre szánt gépről a c$ megosztást a megfelelő jelszóval)

netdom join %computername% /domain:<a domain neve> /userd:<egy megfelelő jogú account> /passwordd:*

amikor kérdezi, írd be jelszót

shutdown /r /t 0

5. Jelentkezz be helyi rendszergazdai joggal és add hozzá a megfelelő tartományi csoportot vagy felhasználót a helyi Administrators csoporthoz

net localgroup administrators /add <domain account vagy csoport neve>

logoff

6. Jelentkezz be tartományi fiókkal és telepítsd a Hyper-V szerepkört

start /w ocsetup Microsoft-Hyper-V

a rendszer hamarosan újraindítást kér, tegyél a kedvére.

7. Egy másik gépen tedd fel a Hyper-V Management tulajdonságot (a Remote Management csoportban lesz) és csatlakozz a Core géphez.

8. Állítsd be a Hyper-V beállításokat (alapértelmezett folderek stb.) és a hálózatot és már indulhatnak is a virtuális gépek.

Ha valamilyen misztikus okból nem sikerülne a csatlakozás a Hyper-V MMC-vel, akkor

netsh advfirewall firewall set rule group="Remote Administration" new enable=yes

Hamarosan következik: Server Core, mint failover cluster tag

Ahol a jövő már elkezdődött...

Csaba Somogyi — Fri, 14 Dec 2007 12:07:14 GMT

Technorati Tags: Windows Server 2008, Hyper-V, virtualizáció, SQL 2008, IT Pro Momentum

Alig két hónapja indítottuk útnak a Microsoftnál az IT Pro Momentum programot, amelynek a legfontosabb célja az új technológiák széles körű megismertetése az informatikus közösséggel és máris megérkeztek az első visszajelzések a legbátrabb kollégáktól.

Az elsők között jelentkezett a programba Varga Árpád és a Cason Zrt. fejlesztői csapata. Munkájukhoz kapcsolódóan két projektet indítottak párhuzamosan: virtualizáció és SQL Server 2008 témában.

Árpád a következőképpen foglalta össze a projektek lényegét és a tapasztalatokat:

"Az egyik projekt fő célja a fejlesztési környezetünk megváltoztatása. Keressük a módot, amely a leghatékonyabb lehetne számunkra. A fő probléma jelenleg az, hogy rendszerfejlesztőkként mindig valamilyen specializált hardver/szoftver térbe kell alkalmazásainkat illeszteni, ezért gyakran okoz fejtörést a szinte végleges formájában lévő alkalmazás „élesítése”. Erre láttuk alternatívaként a virtualizációt. Igyekszünk a célkörnyezetnek a lehető legjobban megfelelő fejlesztői platformokat létrehozni, hogy a felmerülő problémákat a lehető legnagyobb mértékben már itt, „az asztalon” kiszűrhessük. A 2008-as virtualizáció számos jól ismert előnye sokat segít ebben."

"A másik projekt összefügg egy romániai fejlesztéssel, amelynek célja személyi nyomkövetés. Itt egyes embereknél elhelyezett GPS/GPRS alapú nyomkövetők információit kell feldolgozni, és térképen megjeleníteni. Mivel a közkézen forgó térképmotorok romániai lefedettsége az adott térségben nem éri el az utcaszintet, így kénytelenek vagyunk ezt a hézagot egyelőre saját fejlesztéssel kitölteni. Ebben nyújt segítséget az SQL 2008-ban megtalálható SPATIAL támogatás, ami eddigi tapasztalataink szerint igen jól használható geocoding motorok mögött."

"Mint minden korai bevezetést és alkalmazást megcélzó projektben, itt is nap, mint nap szembesülünk technológiai problémákkal, illetve azzal, hogy bizonyos funkciók még nagyon korai (a bétát is megelőző) fázisban vannak. Ilyen esetekben jön jól a TechNet-ben összegyűjtött nagy tudásbázis és az, hogy gondjainkat közvetlenül továbbíthatjuk a fejlesztők felé a béta támogatási csatornákon keresztül. Összességében viszont kedvezőek a tapasztalatok, mind teljesítmény, mind megbízhatóság és biztonság tekintetében."

Néhány mondat a Cason Zrt-ről

A Cason Mérnöki Zrt. 1992 óta van jelen a magyar és nemzetközi piacokon termékeivel és szolgáltatásaival. Portfóliójuk legfontosabb elemei az ipari kommunikációs berendezések, az integrált ipari rendszerek, valamint a személy- és flottakövetésre kifejlesztett GPS/GPRS alapú megoldásuk.

Legfontosabb ügyfeleik az energiaiparból, logisztikai-, szállítmányozó cégekből és a gyógyszergyárak közül kerülnek ki, de legújabb termékük kapcsán biztonsági és távközlési kapcsolatrendszerük is bővül.

A cég fejlesztési központja Magyarországon, Érden található, de jelen vannak Franciaországban, Spanyolországban, Romániában, Japánban, Taiwanon, Szingapúrban és Thaiföldön is. A vállalatnál 114-en dolgoznak. Amellett hogy többször innovációs díjjal is kitüntették, 2006-ban a Cason Zrt. felkerült Európa 500 leggyorsabban fejlődő vállalatának listájára is.

Út a házi datacenter-ig - 1.

Csaba Somogyi — Thu, 13 Dec 2007 15:44:52 GMT

Technorati Tags: Windows Server 2008, virtualizáció, Windows Home Server, hardware, Hyper-V

Ez a történet valamikor réges-régen kezdődött, mint általában a mesék. És az is lehet, hogy többen átélték ugyanezt a történetet és most deja vue érzésük van. Szóval néhány éve már fel-felébred bennem egy olyan érzés, hogy valami hiányzik a házi informatikai környezetből. Valami, ami folyamatos szolgáltatást nyújt, amit nem kell külön bekapcsolni, csak rákattanni és lehet zenét hallgatni (sőt akár csapkodni ide-oda és percenként másikat hallgatni), filmet nézni, meg ahol biztonságban vannak a digitális fotók, sőt akár a világ végéről is elérhetők. Tehát igazából egy szerver hiányzott.

Felmerült több lehetőség és ötlet a vágy beteljesítésére, de aztán valamilyen apróságon mindegyik megbukott. Csak három a legtovább életben maradt ötletből.

NAS. Valami kis dobozka, benne diszkekkel, rádugva a hálózatra és hurrá. Sokáig élt az ötlet, több alkalmasnak látszó vasat is megnéztem (sajnos nincs olyan kapcsolatrendszerem, hogy ki is próbálhassam őket). Végül azon bukott meg a dolog, hogy a NAS eszköz önmagában általában buta és pl. az Internet felé nehézkesen publikálható (bár azóta találtam olyat, amiben beépített FTP van), és akkor még nem megbízható és biztonságos. Ráadásul elég drága, főleg ha az ember nem akarja egyetlen diszk megbízhatóságára építeni kincsei megőrzését.
Okos router. Köztes megoldásként merült fel, és mivel más jó tulajdonságai miatt amúgy is ilyen tudású routert vettem egy ideig üzemelt is ez a megoldás. Az az ASUS WL500g Premium, amit végül kiválasztottam -a szokásos router funkciókon kívül- remek FTP és média szerver is. Bármilyen USB diszket rá lehet dugdosni és az ott tárolt mindenfélét házon belül és kívül lehet szétszórni. Ráadásul olyan funkciókra is alkalmas (pl. t.rr.nt file rádob, ő azt szépen letölt, diszkre letesz, 24 óráig seed és közben nincs gép bekapcsolva), amiknek a részletezésébe most inkább nem mennék bele :-). Min bukott meg? Megint csak az egy szál diszken (nem tud két diszket kezelni) és a diszk fájlrendszerén. Ha valakinek mond valamit az EXT2 :-). Szóval komoly gondjai voltak a hosszú és ékezetes fájlnevekkel, ami valószínűleg a router beágyazott 20-22 MB-os oprendszere miatt lehetett (és csak súlyos hekkeléssel lehetett volna okosítani, amihez viszont nem vagyok kellően képzett és fanatikus).
Aztán jöttek az első hírek a Windows Home Server-ről. Windows-os tudás adott, az ára nem lehet valami rettenet, gyerünk, próbáljuk ki. Jelentkeztem a béta programba, letöltöttem a telepítőt és ott tartottam, hogy jó, de mire tegyem. Van ugyan egy ezer éves PC a sarokban (P2-Celeron, 550 MHz :-)), de abban csak 256 MB RAM van és nem is bővíthető - a Home Server-nek pedig ez kevés. Uccu, Virtual PC, nézzük mit tud a dolog. Hihihi, ez nagy-nagy százalékban Small Business Server! De azért érdekes. Azután jött a hír, hogy csak OEM csatornán keresztül lehet majd kapni - vagyis géppel, előtelepítve. Brühühü. Nem szeretem, amikor eldöntik, hogy milyen gép lesz jó nekem, persze jó drágán. Ötlet keserű szájízzel bekukázva.

Itt aztán el is aludt a dolog néhány hónapra, maradt az ASUS router a külső diszkkel és az EXT2 szívásaival. Aztán jött egy lehetőség és Szilasligeten (mennyivel kellemesebb leírni így, mint hogy Kerepes!) épülni kezdett a saját házi datacenter-em. Más és több lesz, mint az eredeti elgondolás, de azt is tudni fogja, amit eredetileg szerettem volna. És most jön a reklám :-). Ne menjenek sehová, mert hamarosan visszatérünk és folytatjuk azzal, hogy mi van a fekete dobozban.

Izoláció és integráció - Hyper-V mélyrepülés

Csaba Somogyi — Mon, 10 Dec 2007 12:39:33 GMT

Technorati Tags: windows Server 2008, hyper-V, virtualizáció

A napokban írtam egy kisebb cikket a Hyper-V körül használatos fogalmakról és két nap múlva -újraolvasva a cikket- egy csomó további kérdés merült fel, ami megért egy kis utánjárást. A kis házi nyomozómunka eredményét tartalmazza ez az írás.

Nézzük először a kérdéseket, amik felmerültek. (Na, nem tudományosan és didaktikusan felépített sorrendben, hanem ahogy felmerültek...)

Mekkora is ez az igen vékonyka hypervisor, és pontosan hogyan is kapcsolódik a többi komponenshez?
Szépen hangzik ez a partíció meghatározás, de valahogy nem elég leíró. Mit is jelent a partíció?
Milyen komponensek játszanak még a virtualizációban?
Mitől lesz a Hyper-V sokkal nagyobb durranás, mint volt (/lesz valaha) a Virtual Server 2005?

Kezdjük a legfontosabbal: a hypervisor nem csodafegyver. Valóban kulcsfontosságú komponense a Hyper-V megoldásnak, de korántsem kizárólagos fontosságú. Legalább további két-három hasonlóan fontos elemből áll össze a teljes rendszer, aminek a működését tényleg nem tudom jobb kifejezéssel jellemezni, mint az izoláció és integráció páros. Kik is a további szereplők?

Az első fontos elem kétségkívül a hypervisor, amelyik az elkülönített erőforrásokat biztosítja a virtuális gépek számára. Amikor magunk elé képzeljük ezt az alkotóelemet, ne valami szokásos, gigantikus méretű Microsoft-os varázslatra gondoljunk. A hypervisor attól remek, hogy kicsi. ~~A pontos méretét homály fedi, annyit sikerült megtudni róla, hogy~~ ~~kevesebb, mint 50 kilobájt!! (Csak összehasonlításként: a notebook-om touchpad drivere 500 kB körül van.)~~ A hypervisor nagyjából az átlagos eszközvezérlő méretű: AMD platformon 519KB, Intelen 536 KB. (Köszönet Lepenye Tamás kollégámnak a pontos adatokért.)

Tehát egy zsilettpenge vékonyságú szoftverről van szó, ami képletesen darabokra szabdalja a hardverünket, annak megfelelően, hogy mekkora partíciókat határoztunk meg. És akkor máris itt vagyunk ismét a partíciónál (és annak létrehozásánál, de erről kicsit később). A partíció egy virtuálisan definiált hardver. Adott méretű memória, adott mennyiségű processzor időszelet és virtuális eszközök összessége. Ugye nem nagyon lepődünk meg azon, hogy maga a definíció egy XML állomány? Ezt olvassa/írja szükség szerint a Virtual Machine Management (VMM) szolgáltatás (aminek a front end-je az az MMC, amiből az egész rendszert felügyeljük). A hypervisor a tényleges fizikai hardvert egyfajta erőforrás készletként látja (resource pool), látja mennyi erőforrás szükséges a gazdakörnyezet futtatásához és a maradékot pedig felkínálja a virtuális gépek számára. A VMM egy-egy virtuális gép indításakor beolvassa a hardver definíciót és létrehozza a partíciót a hypervisor-on keresztül, ami az így lefoglalt erőforrásokat kiveszi a szabad erőforrások közül és a virtuális gépnek adja át. A virtuális gép a neki átadott hardver szeletet közvetlenül látja, semmilyen közvetítő szoftvert nem kell igénybe vennie, hogy azokat elérje. (A virtuális operációs rendszer kernele ténylegesen ring 0-án fut, nem pedig valami emulált és szoftveresen átkódolandó szinten).

Persze ehhez, az kell, hogy a hardverünk támogassa a virtualizációt egy speciális -1. szinttel, a hypervisor móddal (az Intel a Vanderpool processzoroktól kezdve, az AMD a Pacifica processzoroktól kezdve adja ezt a funkciót.) (Erről némi olvasnivaló: Rings, Lord of the Ring0)

Feléled tehát lassan a virtuális hardverünk, de még nem üzemképes: nincs meg a koordináció a hardver elemek között, és a virtuális gépnek nincs kapcsolata a gazdagéppel, tehát még felügyelni sem lehet. Itt jön a képbe az ún. Worker process, ami minden virtuális géphez létrejön a gazda operációs rendszeren. Ez a processz kapcsolja össze a virtuális hardver elemeit, mintha egy virtuális alaplapba rakosgatnánk az alkatrészeket. Ezen felül kapcsolatot épít fel a gazda gép és a virtuális gép között, biztosítva hogy a gazdagépről irányítani tudjuk a virtuális gép működését. Megint csak nem érhet bennünket nagy meglepetésként, hogy az irányítás WMI parancsokon keresztül történik. A megjelenítés maga pedig- csodák-csodája- RDP.

A Worker process tartja a kapcsolatot minden szereplővel: figyeli a hardver konfiguráció (tehát a partíció definíció) változását, így ha menetközben átkonfiguráljuk azt, akkor azokat igyekszik érvényre juttatni a hypervisor-on keresztül (így adhatunk például röptében memóriát, további processzort, diszket, hálózati kártyát a virtuális géphez). A "felvilágosult" (enlightened), -tehát hypervisor-t ismerő- virtuális gépek esetén a VMBus-on keresztül hozzáférést biztosít a szintetikus hardver elemekhez - például egy virtuális switch-hez, amivel VLAN-okkal elkülöníthetjük akár az azonos gépen futó virtuális gépeinket is, miközben a hálózat bizonyos szegmensei felé kommunikálhatnak. A gazda gép és a kliensek közötti kommunikációs alagút a VSP-VSC páros (Virtualization Service Provider - Virtualization Service Client), mintegy klasszikus kliens-szerver megoldás esetén.

Szintén a Worker process nyújtja a virtuális eszközöket a virtuális gép számára (az emulált eszközöket is) és koordinálja a fizikai hardver eszközökhöz való hozzáférést a hypervisor-on keresztül (hiszen lehet, hogy több virtuális gép szeretne kommunikálni egy-egy fizikai hardverrel és ekkor ütemezésre van szükség).

Összefoglalva tehát, a Virtual Machine Management tartja a kapcsolatot az összes Worker process-el, lekérdezve a virtuális gépek állapotát, terhelését, egyeztetve konfigurációjukat az ismert partíció definícióval. A Worker process egy virtuális alaplapba fogja össze a hypervisor által átadott memóriát és processzoridőt (akár több processzorét is), valamint a virtuális eszközöket (devices). Az integrációs komponenseken keresztül tartja a kapcsolatot a szintetikus eszközökkel (VMBus) és a többi virtuális géppel (VSP-VSC), valamint feldolgozza a gazdagépről érkező felügyeleti utasításokat (WMI) és leképezi az RDP kapcsolatokat (ezért láthatjuk már a boot-olási folyamatot is RDP-n keresztül, eltérően a fizikai gépektől). A hypervisor számon tartja a hardver erőforrásokat, a partíció definíciók szerint súlyozza az erőforrásokat, miközben gondoskodik elkülönítésükről, illetve ellenőrzi a hozzáférési jogosultságokat.

És mitől lesz más és jobb? Elsősorban a hypervisor tudásától és a hardveresen támogatott virtualizációtól. A Virtual PC és Server az x86 architektúra korlátai miatt sok kényszerű kompromisszumot tartalmaz. A virtuális operációs rendszerek egy köztes futási szinten (Ring1) kénytelenek futni, amit aztán a VMM emulál a hardver felé (ez a paravirtualizáció). Az ár viszont meglehetősen magas, a virtuális gépek teljesítménye lényegesen rosszabb, mint azt az adott hardver indokolná. A processzorokba épített Ring-1 szintű hypervisor-ok, kiegészítve a szoftveres (és a Microsoft esetében mikrokernel-es) hypervisor-ral képesek túllépni ezeken a korlátokon és a hardver valós képességeihez jobban közelítő teljesítményt biztosítani virtuális környezetben is. (Erről kicsit bővebben: Hardware assisted virtualization)

Kis fogalom magyarázat a Hyper-V-hez

Csaba Somogyi — Tue, 04 Dec 2007 13:02:09 GMT

Technorati Tags: Windows Server 2008, virtualizáció, Hyper-V

A virtualizáció kapcsán sokan, sokféle szakkifejezést használnak, röpködnek a szakszavak, a bonyolult, nem is mindig pontos magyarázatok, amitől egyszerű földi halandó számára az egész történet valami misztikus varázslattá válhat.

Pedig szó sincs varázslatról. Mert ez csak színtiszta technológia.

Kis tájékozódási segítségként nézzük a legfontosabb szakkifejezések egyszerű magyarázatát:

Hypervisor: A hypervisor egy vékonyka szoftverréteg, ami közvetlenül a hardware és a rajta futó operációs rendszerek között üldögél. A feladata, hogy elkülönített futtatási környezeteket biztosítson az összes operációs rendszer számára. (Ezek a partíciók.) Minden partíció csak a saját hardware erőforrásaival rendelkezik (memória, eszközök és a CPU adott időszeletei). A hypervisor ellenőrzi és koordinálja a partíciók hozzáférését a tényleges hardware-hez.

Partíció (Partition): ez a hypervisor által biztosított elkülönítés alapegysége; egy fizikai címtartományból és egy vagy több virtuális processzorból épül fel. Ráadásul a partícióhoz meghatározott hardware erőforrások rendelhetők és az erőforrások eléréséhez szükséges jogosultságok is.

Szülő partíció (Parent partition): az a partíció, amelyben dolgozva a gyerekpartíciókat létrehozzuk és felügyeljük.

Gyerek partíció (Child partition): a szülőből létrehozott bármely további partíció.

Vendég operációs rendszer (Guest): a partícióban futó operációs rendszer szoftver. A vendég rendszer lehet teljes kiépítettségű (pl. bármely Windows rendszer), vagy akár egy speciális célú kernel. A hypervisor közömbös a vendég rendszer iránt, csak az erőforrásokat adja számára.

Eszköz emuláció (Device emulation): olyan eszköz virtualizációs megoldás, ahol a virtualizált hardware nem különböztethető meg a tényleges fizikai hardware-től (1:1-es megfelelés).

Szintetikus eszközök (Synthetic devices): olyan virtuális eszközök, amelyeknek nincs közvetlen fizikai megfelelőjük. Az ilyen eszközök a VMBus segítségével kommunikálhatnak akár más partícióban lévő fizikai eszközökkel is.