Author: JoeP

Powerhell

2012-05-25 / / 1 Comment

Nevezhetjük szerencsének, de eddig még sikerült megúsznom a postafiókok nagy tömegben történő exportálását pst fájlokba. Eddig. Háát…

A környezet ránézésre nem túl veszélyes. 230 postafiók, 160 GB adatmennyiség. A szerver jól méretezett. A kliens, amelyikről a másolást végezni kell – a lehetőségekhez képest – szintén.
Ezen azért rugózzunk egy kicsit, mert később fontos lesz. Exchange 2007, az export-mailbox követelménye 32 bites(!) Outlook 2007, szigorúan 32 bites(!) Windows 7-en. Erre kell még egy 32 bites Exchange 2007 admin csomag.
Még a tesztfázisban összeraktam egy virtuális kliensgépet, hogy ismerkedjek a folyamat dinamikájával. Másra nem is volt jó, mert diszk, az nem volt mögötte, de sikerült bejátszani a parancsot, eljátszottam a nyelvi beállításokkal, szóval felkészültem.
A migrációra a helyi emberünkkel közösen összeraktunk egy kliensgépet. Az éles indulás előtt ezen is teszteltem egy kicsit, minden működött, mint egy svájci óra.
Eldördült a startpisztoly, levélforgalom leállít, a kliensen parancs kiad, elégedetten hátradől. Kábé 10 percig. Ekkor kezdett el sikítozni a Windows, hogy eldobta az agyát. Konkrétan elfogyott a memóriája. Ezzel párhuzamosan a másolás is beállt, mint a gerely. Kilőttem a taszkot. Fejvakarás. Nem túl sokáig, mert a helyzet hamarosan világossá vált. A Windows ugye 32 bites, ebben a maximum RAM 4 GB lehet. Volt még a pagefile, a kettő együtt 10 GB. Az export-mailbox egyszerre 4 szálat indít és balszerencsémre rögtön az első csoportban benne volt a titkárság postafiókja, nem is mondom, mekkora mérettel. Lúzer hiba volt. Felnyomtam a virtuális memóriát 40 GB-re, restart, aztán elkezdtem újra.
Nem indult el. A powershell fél perc szutykolódás után váratlan hibát dobott, a legsemmitmondóbb 1000-es hibaüzenettel. Újraindítás már volt, tehát ebben sem reménykedhettem. Mi romolhatott el? Persze, játszottam még a parancs maxthreads paraméterével, de el se jutott odáig a folyamat, a powershell sorra dobta a váratlan hibákat. Pedig addigra már megszokhatta volna.
A leginkább logikus gondolat az volt, hogy amikor erőszakosan kilőttem a powershell processzt, akkor megsérülhetett valami alkotóeleme és azóta a PS nem tér magához. Telepítsük újra! Ahogy azt Móricka elképzeli. Mivel Windows 7 esetében már beépítve jön a PS 2.0, így nem lehet külön letölteni. Feature-ként sem lehet eltávolítani, majd visszarakni. Ekkor szóltam a kollégának, hogy B terv, kezdjen el telepíteni egy másik munkaállomást. Itt már lejjebb adjuk az igényeket, eszébe se jusson windowsupdate-tel foglalkozni. Én pedig előre menekültem. Rakjunk fel WMF3 CTP2 csomagot, abban van Powershell 3. Aztán majd meglátjuk, mit csinál. Semmit. Fel sem települt. Azt mondta, hogy neki szigorúan angol nyelv kell, ez meg nem az. De meg lehet engesztelni egy angol language pack-kel. Töltsük le! Hát, nem. Nyelvi csomag eleve a Windows Update-ről szedhető le, ultimate és enterprise Windows 7 esetén. Csakhogy mi itt professional verzióval szopunk. Elvileg leszedhető az MSDN-ről a teljes csomag, de mire a 2 GB lejön, addigra a kolléga újrahúzza a gépet. És még ekkor sem garantálja senki, hogy nyelvet tudok váltani, hiszen a professional eleve nem lehet többnyelvű.
Csapásváltás. Menjünk vissza a legutóbbi rendszermentéshez, töltsük vissza, aztán telepítsünk mindent újra attól a ponttól. Röpke félóra alatt meg is csináltam, restart, újabb próba, újabb váratlan PS elszállás.
Hát, ezzel nem jutottam sokat előre.
Közben kolléga felhúzta az új gépet, gyorsan kipreparáltam, maxthreads a biztonság kedvéért kettőre állítva, aztán hajrá. Nem hiszed el: ezen is váratlan Powershell hiba történt. Meg lehetett volna mintázni rólam a bambaság szobrát.

Vicc.

– Doktor úr, nagy baj van!
– Mi a panasza?
– Ha megnyomom a lábam, fáj! Ha megnyomom a derekam, fáj! Ha megnyomom a tarkóm, fáj! Milyen betegség az ilyen?
– Valószínűleg eltörött az ujja.

Azaz ha több kliensen is ugyanazzal a hibával száll el egy folyamat, akkor lehet, hogy a szerver a hibás. Mágikus restart. A biztonság kedvéért a kliensen is. Másolás elindít, összes végtaggal imádkozik. És igen, ez volt a probléma, a Powershell váratlanul jól működik.

Vegyük észre az eset szépségét. A 32 bites kliensen elindított, 32 bites Exchange modullal feljavított Powershell (aka EMS) menetközben meghívogatja a 32 bites Outlook MAPI motorját, ezen keresztül próbálja meg leszívni a szerverről a levelezési tartalmakat és kirakni pst fájlokba. Aztán elfogy a RAM, ki kell lőni a taszkot, és mi hal meg tőle? A szerver. Finom.

Mindegy, elméletileg örülhetnénk is… csakhogy itt a háromnapos ünnepre terveztünk egy háromnapos átállást. Ebből elveszett a péntek délután, az export legjobb esetben is csak szombat délre fejeződik be és igencsak csipkedhetjük magunkat, hogy ezt a fél napot behozzuk valahogy.

Én mindenesetre halk sóhajjal betoltam az Alvin albumot az mp3 lejátszóba.

Ott szorít, ahol szűkebb

2012-05-23 / / 0 Comments

Egy nagyon jó nyomozás leírása Paul-tól. Érdemes végigolvasni, megnézni, hogyan gondolkodott, milyen eszközöket használt és hogyan göngyölítette fel az esetet. Majd hasonlítsuk össze, hogyan oldottam meg anno én egy ránézésre teljesen különböző, de valójában ugyanarra a konfigurációs hibára visszavezethető problémát, pusztán a józan eszem és a Salvador Dali-féle paranoiac-critical módszer segítségével.

A message tracking log használata – másképpen

2012-04-18 / / 3 Comments

Minden Exchange admin nagy barátja a message tracking log, rendszerint ennek segítségével tudjuk átrugdosni a dögöt az utca másik oldalára, azaz így bizonyítjuk, hogy a levél rendben kiment az Exchange organizációból, a továbbiakban pedig legyenek kedvesek a fogadó oldali rendszergazdát zaklatni.

Paul Cunningham mutatott be egy másik lehetőséget, melyhez szintén a jó öreg MTL-t használjuk: addig gyötörjük, amíg nem összesíti nekünk a napi levélforgalmainkat. Hasznos információ? Igen. Hozzá lehet férni valami egyszerű módon? Tudomásom szerint nem.
A megoldást nem teszteltem, nem tudok beszámolni gyakorlati tapasztalatokról – de mindenképpen használható ötletnek tűnik.

A lelkes TMG

2012-04-10 / / 3 Comments

Apróság, nem is akkora nagy szívás, de a kognitív energiák elszivárgása képes némi fogcsikorgatást előidézni.

Van a DMZ-ben egy levelezőszervered – mondjuk egy Exchange Edge – és az SMTP portját egy TMG szerveren keresztül szeretnéd kipublikálni. Ez nem lehet komoly feladat, a varázsló 2004 óta szinte semmit sem változott. Illetve…

From Segédlet

Ez bizony egy zavarbaejtő kérdés. Azt mondja, van másik, van jobb… miért használod ezt a régi szutykot?

Ne dőljünk be neki.

Ha ugyanis az általa felajánlott E-mail Policy varázslóval publikálunk, akkor a szerverünk SMTP portja nem lesz elérhető kintről. Még ha véres verítékkel szétkonfiguráljuk a TMG-t, akkor sem. Egy apróságot ugyanis elfelejt a kuruzsló közölni: E-mail Policy-t csak és kizárólag akkor tudunk használni a TMG-n, ha telepítünk rá egy Exchange Edge szervert is.

Az már egy teljesen más téma, hogy a fenti felállásban igencsak elgondolkodtató, hogy az Edge szervert ne a DMZ-be tegyük, hanem a TMG-re. Az integráltság ugyan növekszik – és ezzel vétünk a KISS-elv ellen – de megspórolunk egy Windows Server 2008 R2 licenszt. Amennyiben viszont más gyártó smarthostját használjuk, akkor nyomjunk pánikszerűen egy No-t és haladjunk tovább.

Internet Database Availability Group

2012-04-01 / / 0 Comments

Amikor elkezdtem olvasni Scott cikkét, egyből elcsöppent a nyálam. Épp mostanában van egy olyan munkám, hogy bár az ügyfélnek nincs túl sok pénze, de szeretne egy olyan HA megoldást két telephelyen, melyek még akkor is működnek, ha a Föld megsemmisül. Üzletpolitikailag meg nem mondhatjuk azt, hogy nem.
Szóval olvastam, olvastam, és bár a működését elsőre még nem láttam át teljes mélységében, de nagyon tetszett a dolog. Végülis nem akárki írta a cikket, aki Scott Schnollnál többet tud az Exchange HA területről, az már festi magát. És pont most jöttek ki vele, pont amikor égető szükségünk lenne rá. Remek.

A lelkesedésem egészen addig tartott, amíg észre nem vettem az írás végén a tag-eket.

ps.
Persze, folyamatosan nyüzsgött agyam hátterében a kisördög: mi is van azzal a kritikus round-trip latency-vel, az adatbázisok rpcclientaccessserver paramétereivel, na meg a CAS proxyzásokkal? De olyan jó lett volna hinni benne, hogy ezt mind-mind megoldották.

Imádom a lehetetlen küldetéseket

2012-03-03 / / 0 Comments

Napok óta a Windows 8 bétával foglalkozik a szakmai blogoszférának a Windowsra érzékeny része. Olyannyira benne van a levegőben, hogy már én is elgondolkoztam, hogy feldobok egy szervert és egy klienst a tesztrendszeremre. Ha időm lesz. Ha.

Viszont vannak olyan emberek – és az összes kalapomat megemelem előttük, pedig van pár – akik nem elégszenek meg azzal, hogy felraknak egy Windows 8 szervert, hanem úgy istenigazából nekiszaladnak és megnézik, hol vannak a határai. És mennyire kemény betonból vannak.

Paul Cunningham úgy döntött, hogy Exchange 2010-et telepít a béta Windows 8 szerverre. És nem riasztotta el, hogy ez abszolút nem támogatott. És akkor sem dőlt a kardjába, amikor a telepítő is közölte vele ezt a hírt. Hiszen a registry-t lehet editálni is, és miért ne hazudhatnánk be a Windows 2008-at (6.1) a Windows 8 (6.2) helyett? Ja, hogy a telepítés után nem indul el az Exchange? Kérem, ha már elkezdtünk hekkelni, miért állnánk meg pont itt?

A teljes cikk: Installing Exchange Server 2010 on Windows Server 8 Beta.

Pecs kedd

2012-02-17 / / 0 Comments

Csütörtökről péntekre virradó éjjel van, én pedig a megérdemelt pihenésemet töltöm a padláson. A ‘megérdemelt’ jelen esetben nem üres szóvirág – tényleg megdolgoztam érte.

Szerdán ügyfélnél voltam. A tervezett munka aznapra két hyper-v host beüzemelése volt, négy-négy virtuális hálózattal, mindegyiken két virtuális gép, ezekből egy-egy tartományvezérlő egy új AD-ban. Semmi izgalmas, mondhatni rutinmunka.
Lett volna. Ha kedden nem küldött volna ki az MS 9-12 hotfixet. Mely hotfixek nem telepítés közben találják el a rendszeremet. De igazából még ez sem lett volna baj, windows update jelez, telepítés megtörténik, gépek újraindulnak és mindenki megy a dolgára. Csakhogy… homokszem került a fogaskerekek közé. Az egyik host gépen lement a telepítés, csak utána valahogyan elfelejtett szólni, hogy újra kellene indítani a gépet a telepítés befejezéséhez. Én meg nem vettem észre, mert menetközben – igen, a szokásos időhiány – már telepítettem a virtuális gépeket is, és a sok gép, sok windowsupdate közben nem jelzett be a vészcsengőm, miszerint elmaradt egy újraindítás. És az is hiba volt, hogy először nem faragtam be az összes virtuális hálózatot, csak azt, amelyiken keresztül a virtuális gépek elérték a belső hálózatot, meg a netet. Úgy voltam vele, hogy telepítés közben mindig van egy csomó holtidő, majd aközben jól elkonfigurálgatok.
És ekkor lépett be Alice csodaországba. A virtuális hálózatok megadásánál változatosabbnál változatosabb hibaüzeneteket kaptam. Hogy nem tudja létrehozni, mert még az előzőn dolgozik. Abszolút nem zavarta, hogy nem volt előző. De persze a hibaüzenet után mégis létrehozta. Ránézésre jól, de használni mégsem lehetett. Ráadásul volt, amelyiket létrehozta, volt, amelyiket nem. Én meg bőszen undóztam, töröltem… végül valami óriási káosz alakult ki a virtuális hálózatokkal. Már most szólok, ha azt mondja, hogy egy hálókártyára nem tud virtuális switchet rárakni, mert már van rajta, ne kezdjél káromkodni, hogy de nincs is – szinte biztos, hogy a nagy kavarásban bekattintva maradt a kártyán az MS virtuális switch szolgáltatás.
Nem akarom a végtelenségig szaporítani a szót, végül belavíroztam magam egy olyan helyzetbe, hogy a hyper-v szerint egy, azaz 1 virtuális hálózat sem volt, a network panelen belül meg látszott nyolc hálókártya: négy virtuális switch és négy virtuális kártya. Miközben a társgépen – mely az utolsó csavarig megegyezett ezzel – minden simán ment, ha nem is elsőre, de harmadikra. Fejvakargatás. Ilyenkor tiszta haszon, hogy kopaszodom, mert van hol vakarni. A nyolc kártyából egy sem hagyta magát törölni, a konzol, ahonnan törölhettem volna, meg egyiket sem látta. Jobb híján maradt a visszaút a kályhához: hyper-v eltávolítása, majd újra felrakása. Árnyalta a helyzetet a már létrehozott két virtuális gép. VHD félrementve, hyper-v le, gép újraindul – és csak itt, ekkor ugrott ki, hogy be volt ragadva 11 patch. Köztük egy csomó szutyok dotnetes.
Az újraindítás után már ment minden simán. A virtuális gépek könyvtárait inkább töröltem, aztán hyper-v vissza. Mielőtt bármit is csináltam volna, befaragtam a virtuális switcheket. Elsőre. (Ez maradt meg tanulságnak: addig nincs virtuális gép, amíg pöpecül nincs kész a virtuális hálózat.) A hálózat után jöttek a gépek, a vhd-t felismerték, evoé. Pusztán csak fél nap helyett egy egészet csesztem el a feladatra, ami nem lett volna baj, ha időmilliomos vagyok – csak most éppen nem.

Csütörtök reggel. Egy bonyolult tesztrendszert kell összehoznom, jövő hét közepén már vagy húsz demó fog futni rajta. Nyolc gép, DC-k, Exchange szerverek, internetszimuláció, mindenféle kliensek – nem egyszerű környezet. Csütörtök reggel kezdenék… és megint egyre hülyébb jelenségekbe futottam bele. Nem húzom az időt: néhány gépen elfelejtettem kikapcsolni a windows update-et, ezek magukra rántották a patch-eket. Nagyjából a tesztrendszer 70%-ánál jártam, eldönthettem, mi legyen: vagy rárakom mindegyik gépre a hotfixeket, bevállalva azt, hogy innentől a tesztrendszer nem lesz kompatibilis magával, vagy visszamegyek a legutóbbi snapshot-hoz (jó messze az időben) és újra végigcsinálom az azóta elkövetett lépéseket. A hotfixek mellett döntöttem. Nem nyert. Két gépre az istennek sem ment fel, csak jöttek azok a legendásan értelmezhetetlen windows update hibaüzenetek. Oké, hagytam a fenébe. Csak éppen eltelt a délelőtt. Ebéd után végigcsináltam az újabb feladatokat, majd visszaálltam – a patch-ek utáni snapshotra. Azaz visszaálltam volna, mert a környezet ezer darabra szakadt. A kliensek látták az Exchange szervereket, a szervereken lévő konzolok meg nem. A névfeloldás úgy ahogy volt, meghalt. Szenvedtem még vele pár órát, majd B terv – vissza ahhoz a pár nappal ezelőtti snapshothoz, amikor még minden jó volt. Itt gyorsan letiltottam minden gépen a windows update-et és eljátszottam az utóbbi napok laborgyakorlatait. Így jutottam el péntek hajnalban oda, ahol csütörtök reggel kellett volna lennem. Amivel nem lett volna semmi baj, ha nem lennék borzalmasan beszorulva a határidők közé és nem kísérte volna ezt a tevékenységemet eddig is felfoghatatlan mértékű balszerencse.

A legjobban jellemzi a helyzetet, amikor csütörtökön napközben éppen az égre néztem és arra gondoltam, vajon mi jöhet még – erre a szélvihar miatt elment az internetkapcsolatom. Elsőre meglepődtem, de aztán elismerően bólogattam: igen, ez egy pontos találat volt. Sok mindenre számítottam, ezek mind be is következtek – de a szélvihar… az igen. Abban van fantázia.

Riport szkript

2012-01-03 / / 3 Comments

Pár bejegyzéssel ezelőtt írtam néhány EMS parancsot, hogyan lehet lekérdezni egy-két fontos adatot egy Exchange adatbázisról. Nos, ahhoz képest itt van egy nagyágyú. Steve Goodman még a nyáron összefarigcsált egy igen komoly riportáló szkriptet, mely nem csak hasznos adatokat szed össze egy Exchange organizációról, de a kimenete is egy látványosan formázott html, melyet egyből le lehet tenni bármelyik CIO/ügyfél asztalára. Sőt, a szerző határozottan bátorítja az érdeklődőket, hogy nyugodtan bővítgessék a szkriptet olyan lekérdezésekkel, melyekre a meglévők mellett még szükségük van.

Kosztüm

2011-11-21 / / 3 Comments

Adott a feladat, publikáljunk egy Exchange 2010 OWA szolgáltatást TMG-n keresztül. Ez ma már egyáltalán nem pilótavizsgás munka, nosza.

Úgy döntöttünk, saját SAN tanúsítványt használunk, így első lépésben azt gyártjuk le. Certification snap-in, advanced, create a request. Itt kapjuk a következő ablakot.

From Segédlet

Először is pár szívélyes szóval megemlékeznék az UI tervezőjének felmenőági rokonairól. Hogy a szöszbe lehet olyan felületet tervezni, ahol nem látszik, mi kattintható választás és mi egyszerűen csak szöveg? Aki először jár erre, kénytelen az egérrel végigszkennelni az ablakot, figyelve, hol változik meg a kurzor.
Jó, nézzük a lehetőségeket. Aszongya, hogy… az Igazi Rendszergazda mindig a custom opciót választja, így akkor mehetünk is tovább.

From Segédlet

Mondjuk, nem fogunk dúskálni a lehetőségekben, az Igaz Rendszergazda egy kicsit meg is szeppen, mert egy kukkot sem ért a beállításokból, de aztán vállat von, biztosan jó lesz az alapértelmezés, és nyomja tovább bátran a varázslót. Elkészül a tanúsítvány, lecseréli az Exchange alatt, minden rendben, a napocska mosolyog, a madarak trilláznak. A belső hálóról működik az OWA, működik a MAPI, sehol nem jön fel tanúsítványhibára figyelmeztető ablak.

Kiexportáljuk a tanúsítványt, figyelve, hogy benne legyen a privát kulcs, felmásoljuk a TMG szerverre. Elkezdjük összerakni a web listenert. Elérkezünk oda, hogy kiválasszuk hozzá a tanúsítványt… de nincs. Azt mondja, hogy az a tanúsítvány, melybe az összes bizalmunkat helyeztük, az bizony inkorrekt. Hogy a manóba? Hiszen az Excange elfogadta, a kliensek elfogadták, az Active Directory elfogadta, a TMG tartományi tag, tehát a root CA tanúsítványa rajta van, a dátumok jók… akkor miért inkorrekt? Ezért.

Ott, amikor a custom sablont választottuk a tanúsítvány igénylésénél, ott csak V3-as (CNG) tanúsítványt igényelhettünk. Igenám, de ebből a tipusú tanúsítványból a TMG nem tudja kiolvasni a privát kulcsot, azaz úgy érzékeli, hogy nincs benne, azaz a tanúsítvány inkorrekt. Kuka.

Visszamegyünk ahhoz a bizonyos ablakhoz és most azt választjuk, hogy Active Directory Enrollment Policy.

From Segédlet

Itt már a jól ismert legördülő menü fogad, kiválasztjuk a V2-es Web Server sablont, és máris minden kiegyenesedik.

Tömörítsek?

2011-11-15 / / 1 Comment

Amióta létezik olyan termék, hogy Exchange, állandóan visszatérő kérdés az adminok körében: kell-e tömöríteni az adatbázis, és ha igen, akkor mikor?

Rövid kitérő, ha valaki esetleg nemrég bújt volna még csak ki a tojáshéjból. Az Exchange-ben – eltekintve a régebbi verziók stm fájljaitól – egy adatbázis egy darab edb fájl. Ezen a fájlon belül vannak adattáblák, ahol az összetartozó adatok között pointerek teremtik meg a kapcsolatot. Amikor törlök egy levelet, akkor az egyik adattáblából törlődik a levél tartalma, és emellett törlődnek a rámutató pointerek is. Értelemszerűen hiába csökkennek az egyes adattáblák méretei, az edb fájl mérete nem csökken. A fájlon belül üres hely (whitespace) szabadul fel, de a sok, apró üres hellyel az Exchange nem tud mit kezdeni. Ekkor jön be a képbe az Online Maintenance folyamaton belül az Online Defragmentation, azaz online tömörítés: ez az edb fájlon belül az üres helyeket kimozgatja a fájl végére, így újra hasznosíthatók lesznek. Az online tömörítés, mint a neve is mutatja, online, azaz működés közben is végezhető. Csak éppen erőforrásigényes, emellett Exchange 2010 előtt szégyenlős is, ha túl nagy aktivitást észlel az adatbázison, akkor megáll. Márpedig az online tömörítés hiányában vészesen dagadni kezd az adatbázis. Sőt, ha valaki végiggondolja a folyamatot, akkor láthatja, hogy az online tömörítés mellett is dagadhat az adatbázis. Például kapunk egy tüskeszerű nagy terhelést. Egy nap alatt felhízik az adatbázis (betör egy spam), a felhasználók ugyan törlik a leveleket, de az online tömörítés csak az üres helyekkel tud játszani, az edb fájl méretével már nem. Ahhoz, hogy az utóbbi is csökkenjen, már más módszerekhez kell nyúlni.

Így jutottunk el az offline tömörítéshez. Ekkor lecsatoljuk az adatbázist és az edb fájlt átadjuk egy erre a célra kifejlesztett adatbázismatyizó programnak (eseutil). Ez nyit egy új, ideiglenes adatbázist, elkezdi átmásolni az értelmes tartalmat (nem, a levelekben már nem kutat értelmet), majd ha végzett, akkor az eredeti adatbázist törli, az ideiglenest pedig átnevezi. Visszacsatoljuk és jó esetben mindenki boldog.

Most jön egy újabb kitérő. Olvasdd el Paul Cunningham írását. Nagyon szépen körbejárja a témát, a végeredménnyel pedig csak egyetérteni lehet: az offline defrag nem az az elem, melyet a rendszeres, szabályozott karbantartási folyamatok során végzel. Mivel az offline defrag offline, és emellett kockázatos is, csak akkor van értelme, ha az adatbázis mérete már problémákat okoz. Pontosan miket is? Egyrészt kezd elfogyni a tárterület a diszken. Ekkor el lehet gondolkozni az offline tömörítésen, de ha nem szeretjük a kockázatot, akkor lehet bővíteni is a tárterületet. Másrészt – saját tapasztalataim szerint – az Online Maintenance időigénye az edb fájl fizikai méretével arányos. A nagy edb fájl hosszú Online Maintenance időt jelent és így már lehet, hogy a folyamat nem fér bele a kijelölt időablakba. Nyilván az időablakot ki lehet húzni, de ekkor összecsúsznak az adatbázisműveletek, neadjisten belecsúsznak a produktív időbe, ez persze újabb terhelés – és egész egyszerűen mire végetér egy online tömörítés, már megint töredezett az adatbázis. Értelemszerűen itt is eljárhatunk úgy, hogy bővítünk – több RAM/proci – de ennyire ne legyünk már nyulak. Ezzel ugyanis csak elodázzuk a probléma megoldását.

Ekkor úgy halványan felmerül az offline tömörítés utáni igény az IT csapatban. De biztos, hogy erre van szükségünk? Mi van, ha az adatbázis tényleg ekkora lett? (Jelzem, ha az adatbázis mérete meg lett tervezve, az összes postafiók mérete korlátos, akkor ez a kérdés érdektelen.) Ilyenkor lenne jó tudni, mennyi is a whitespace. Biztosan vannak szofisztikáltabb módszerek is, én egy közepesen bonyolult powershell parancsot szoktam használni:

get-mailboxdatabase | get-mailboxstatistics | measure-object -property itemcount,totalitemsize -sum

Ez a szerveren lévő összes adatbázisra kiírja, hogy mennyi item-et (levelet, kontaktot, naptárbejegyzést) tartalmaznak, illetve ezeknek mekkora az összesített méretük. Ugyanez létezik konkrét adatbázisra is:

get-mailboxstatistics -database name | measure-object -property itemcount,totalitemsize -sum
get-publicfolderstatistics | measure-object -property itemcount,totalitemsize -sum

Az adatbázisok fizikai méretét megtaláljuk a Windows Explorerben, ebből pedig tudni fogjuk, hogy az adatbázisban mennyi az adat jellegű tartalom adattartalma. Igen, nem véletlenül fogalmaztam ennyire körülményesen. A cikk elején is írtam, hogy az edb fájlban vannak olyan adattáblák is, melyek az adatok strukturálását, gyors elérését segítik. Ez az adatbázis overhead. Tervezéskor én 20%-kal szoktam dolgozni – mégem hidat méretezünk, ekkora pontosság bőven elég – azaz ha ennél jóval nagyobb a különbség, akkor tényleg itt van az ideje az offline tömörítésnek.

Vagy mégsem?

Jó hír azoknak, akik Exchange 2010-et üzemeltetnek, hogy ők már használhatják az offline tömörítést online is. Nem, nem golyóztam be, legalábbis még nem nagyon. Olvassuk vissza, mit csinál az eseutil: nem tudnánk ezt mi is elvégezni, az adatbázis lecsatolása nélkül? Létrehozunk egy új adatbázist, felcsatoljuk, a postafiókokat átmozgatjuk (csak az adattartalom megy át, a whitespace nem), a régi adatbázist lecsatoljuk, letöröljük. Kész. A kliensek nem a Mailbox szerverhez kapcsolódnak, hanem a CAS szerverhez, az meg mindig tudja, melyik adatbázisban van a felhasználó. Ezzel ki is húztuk az offline defrag mindkét méregfogát:
– Nem offline. Régebben könnyű volt az élet, ötkor megszólalt a gyárban a sziréna, a portás hatkor lehúzta a redőnyt, a rendszergazda ekkor kezdett ébredezni, majd éjjel lecsatolta az adatbázisokat és reszelgette. Manapság már nincs holtidő. A legtöbb alkalmazottnak van minimum egy emailképes kütyüje, és valami fura perverzióból éjjel is meg akarják nézni a leveleiket. Offline folyamat? Hogy gondolod.
– Bármennyire okos is az eseutil, egyszerűen nem tudjuk olyan alaposan paraméterezni, mit csináljon az értelmetlen adatokkal, mint ahogy egy postafiókmásolás esetében. Már nem kell rettegni attól, hogy az eseutil után kapunk egy annyira tömör adatbázist, hogy gyakorlatilag üres.

Pecs

2011-11-10 / / 0 Comments

Kora reggel jött egy kérdés. Valami nem működik egy Exchange 2010 szerveren. Oké, mindjárt megnézem a tesztrendszeren.
Hát, a mindjárt kicsit elhúzódott, ugyanis szégyen ide vagy oda, de marha régen jártam már erre, tizensok patch várta toporzékolva, hogy feltelepüljön. – Jól van, aranyoskáim, azonnal – nyugtattam meg a virtuális gépeket és rányomtam az install gombra.
Közben elmentem reggelizni. Visszajöttem, restart.

Nosza, nézzük azt a problémát. Elindítottam az outlook-ot a kliensen – erre közölte, hogy nincs Exchange szerver. Hoppá. Megpingettem, látta. Névre is, IP-re is. Mind a kettőt. Biztos az outlook2003 hülyéskedik – gondoltam – és beléptem egy másik tesztgépbe, ahol outlook2010 dolgozott. Ugyanaz. Ő sem látta az Exchange szervereket.
Mi a fenét csinálhattak a patch-ek?

Korán reggel volt, az agyam még nem bootolt be rendesen, pusztán ezzel tudom magyarázni, hogy már első körben ész nélkül nekiálltam guglizni. Lett is egy csomó találat, egyik vadabb dolgot mondott, mint a másik. Mindegyik szálnak utánajártam, de minden rendben volt, ezek nem okozhatták a hibát.
Kimentem a konyhába, főztem egy kávét. Innentől mondhatom azt, hogy nekiálltam módszeresen felgöngyölíteni a problémát. Exchange szerver, eventlog. Minden rendben, viszont másfél órával ezelőtt tömérdek piros felkiáltójel. Hmm, hmm. Nagyon sok. Ezt most mind olvassam át? Eh, ez másfél órával ezelőtt volt, nekem meg most van bajom. Majd visszanézek, ha nincs jobb ötletem.
Nézzük az Exchange szolgáltatásokat. Na, itt köptem vissza kis híján a kávét. Az automatikusan induló Exchange szolgáltatások durván fele csak úgy lógott a levegőben, köztük persze az Exchange RPC is. Mind a két szerveren! Ez azért már tényleg izgalmas. Indítsuk újra. Sorra végignyomkodtam a start gombot és a szervízek elindultak. Ráküldtem még vagy 5 refresh-t, de a szolgáltatások makacsul működtek. Ez egyre rejtélyesebb. Valahogy nyugodtabb lettem volna, ha a szolgáltatások egyszer csak maguktól megálltak volna.

Na, mindegy. Nézzük az outlook mit lát. Mindent. Mind a kettő. Mind a két Exchange szerveren. Fejvakarás.
Gyorsan megnéztem, amit a kora reggeli kérdéssel kapcsolatban akartam, aztán amíg válaszoltam, be is ugrott a megoldás. A kora reggel. A patch.
Idősporolás miatt egyszerre nyomtam rá mindegyik szerveren a Windows Update gombra, aztán reggeli után egyszerre a Reboot gombra. Az öt szerver (két DC, két Exchange, egy TMG) egyszerre állt le és egyszerre indult újra. Csakhogy. Amikor az Exchange szerverek szolgáltatásai keresték volna az AD-t, az még sehol sem volt. Emiatt vésték tele piros felkiáltójellel az eseménynaplót. Később persze meglett az AD, de a szolgáltatások nem indultak el maguktól.

Tanulság? A reggeli kávé előtt soha ne pecseljünk.

Aláírva

2011-11-07 / / 1 Comment

Haladni kell a korral, mese nincs. Nem lehetünk annyira kiberszerencsétlenek, hogy nincs saját tanúsítványunk. Hiszen jó dolog a nick, meg az avatar, de mennyivel vagányabb már, ha tanúsítvánnyal tudjuk igazolni, hogy mi vagyunk mi.

Oké, értem én, a tanúsítványos játék soha nem volt igazán egyszerű. Illetve, ha megpróbáltuk egyszerűvé tenni, mindjárt drága lett. Csináljunk saját CA szervert? Hát, az elég macera, ráadásul ki fog csak úgy megbízni a szerverünkben? Kérjük meg az embereket, hogy léccilécci tegyék a szerverünk tanúsítványát a Trusted CA Servers tárolójukba? Aha. Akkor már inkább vegyünk egyet valamelyik nagy CA szervezettől. Persze, ez pénzbe kerül.
A jó hír az, hogy nem mindig. Ha például magánszemély vagy, akkor a Comodo-tól(1) ingyen kapsz levelezésre használható tanúsítványt.

(1) Vagy akinek jobban tetszik, InstantSSL. Mindenesetre, ahogy maguk állítják, ők a második legnagyobbak a piacon, azaz ahhoz mindenképpen elég nagyok, hogy az általuk kiadott tanúsítványt valószínűleg mindenhol elfogadják a világon.

Meggyőztelek? Remek. Akkor nyomjál is rá bátran a megrendelő gombra.
Illetve, ne, várj egy kicsit. Milyen böngészőt használsz?

Elmesélem, hogyan jártam. Miután megrendeltem a tanúsítványt, közölték, hogy nagyon örülnek és küldenek a subject-ként megadott emailcímre egy levelet, melyben leírják a további teendőket. Ez nem volt bonyolult, rá kellett kattintani egy linkre. (Vagy elmenni egy weboldalra és beírni a levélben megadott emailcím/jelszó párost.) Oké, katt. Nagy büdös error.

“The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID).”

Mi van? A Comodo-t már megint meghekkelték? Márpedig bármelyik módszerrel próbálkoztam, mindig ezt az üzenetet kaptam. Benéztem a böngésző (Chrome) beállításai közé, hátha valahol túl szigorúra van állítva a tanúsítványok kezelése, de nem találtam semmit.
Jó, nézzük a többi böngészőt. Kimásoltam a linket. Firefox. Egy abszolút értelmezhetetlen hibaüzenetet kaptam. Opera. Lefagyott. IE9. Na, ez végre meglepően őszinte volt, azt írta, hogy szerinte nem a megfelelő böngészőt használom.

Ilyenkor marad a gugli. Nos, mondanom sem kell, az üzenetnek semmi köze a valósághoz. Szokás szerint.
John Robbins írta le a frankót, igaz, ő egy fizetős Comodo (kódaláíró) tanúsítvánnyal szívott.

A quick round with Comodo support and I find out Chrome and IE 9 are definitely not supported. They sent me a link with their instructions for downloading the certificate. The first line had me shaking my head:
1) Open http://www.instantssl.com/code-signing/ in Internet Explorer (IE) 6 or 7 with ActiveX enabled. (Windows XP preferred)

Hát, izé. Most akkor szedjem le az IE9-et, tegyem fel az IE8-at, kapjam le a tanúsítványt, majd upgradeljek vissza IE9-re? Elég rondán hangzik. Próbáltam kreatívan értelmezni az IE9 korábbi üzenetét. Mi van, ha a tanúsítványigénylő folyamat során a Comodo belerakott egy sütit a böngészőbe, mely később kellett a tanúsítvány letöltéséhez? Hiszen ez is belefér az üzenetbe.
Újabb próbálkozás. Chrome-ból visszavonattam a kért tanúsítványt, simán megtette. Majd átléptem az IE9 alá, bízva abban, hogy a John írásától eltelt egy évben csak észrevették a Comodo-nál, hogy van IE9 is. Újabb igénylés, most IE alól léptem be a gmail fiókomba – és tadam. Megkaptam a tanúsítványt, be is tette a Personal fiókba. (Nyilván kimentettem, és eltettem biztos helyre is.)

Tulajdonképpen ennyi. A többi már egyéni szociális probléma: a gmail-t ugyanis eddig senki nem értesítette, hogy egy levelet alá is lehet írni, sőt, akár titkosíthatnám is. Az hagyján, hogy a webes felületen erre semmi lehetőségem sincs, de ha aláírt levelet kapok, azzal sem tud mit kezdeni a kliens.

From Segédlet

A képen is látható, hogy a feladó publikus kulcsát tartalmazó tanúsítványt és az email lenyomatát is magában foglaló bináris cuccot a gmail egyszerűen csak egy p7s csatolásnak mutatja, anélkül, hogy értelmezné. Körbedolgozni persze lehet, a gépemen van Outlook is, abba felvettem a gmail fiókomat, aztán legfeljebb az aláírt leveleket innen küldöm. Csak éppen borzasztóan nem elegáns a dolog, mivel ekkor az elküldött levél nem ugyanabba a Sent Item folderbe kerül, márpedig én az esetek 99,99%-ában a webes felületről levelezek.

Ha esetleg kedved van még a témával kapcsolatos anyázást olvasni, tudom ajánlani Jason Perlow írását a zdnet-en. A cím önmagában is telitalálat és remekül illeszkedik hozzá az illusztráció is.

Lync RFC-k

2011-10-14 / / 2 Comments

Szoktam volt mondogatni, hogy hasznosak persze a mélyebb, vagy esetleg kevésbé mélyebb szakcikkek is, de ha az ember tényleg érteni szeretné, mi folyik a mélyben, akkor bele kell vetnie magát az RFC-k világába. Nem mondom, hogy felhőtlen viháncolás lesz az élmény, de megéri.

Valószínűleg így gondolta Ken Lasko is, mert a blogján közreadott egy gyűjteményt: melyek azok az RFC-k, melyek érintik a Lync működését.

NIS

2011-09-16 / / 0 Comments

Az alábbi videón két medve beszélget a biztonságról: Yuri Diogenes és Tom Shindler. Az első 20 percben eldörmögnek arról, mi mindennel is foglalkoznak mostanában, az utolsó tíz percben viszont Yuri tart egy érdekes bemutatót arról, hogyan is tudja megvédeni a még nem naprakészre patch-elt hálózatunkat egy jól konfigurált NIS (Network Inspection Service) a TMG-n. (Feltéve persze, hogy a támadás szignatúrája már ismert és a NIS meg is kapta a frissítést.)
 

 

Ideje van a keresésnek és ideje a vesztésnek

2011-08-29 / / 0 Comments

Nem is voltak annyira elszálltak ezek a prédikátorok, amikor a látszólag zöld szövegeket nyomták. Legalábbis a csapat, aki a Windows 2008 szerver telepítő rutinját írta, tanulhatott volna Salamontól.

A tesztrendszeremhez kellett volna egy 32 bites Windows Server 2008. Msdn-es telepítőkulcsom még volt, telepítő médiám… a fene tudja. Úgy emlékeztem, hogy van, csak nem tudtam, hogy hol. Semmi baj, tudomásom szerint a Microsoft oldaláról letöltött eval verzió ugyanaz, a kulccsal simán lehet aktiválni.
Letöltöttem, kiajánlottam a virtuális gépnek, indít, nyelvválasztás… majd telepítő kód. Nosza, begépeltem.

Windows installation has encountered an error and needs to be restarted.

Ez volt a válasz. Ejnye már. Beindítottam a riadóláncot, kértem még néhány kódot. Mindegyikre ugyanezt a választ kaptam, függetlenül attól, hogy milyen tipusú kód volt.
Oké, ennyit az eval verzióról. Kuncsorogtam egy msdn verziójú telepítőt az msdn kódom mellé, azzal már gond nélkül felszaladt, úgy, hogy nem kért semmilyen kódot.

Botor dolog lenne persze azt mondani, hogy az eval szar, az msdn meg jó. A kettő között olyan 200 KB különbség van, azaz a két telepítő gyakorlatilag ugyanaz. Egy különbség van csak, de az elég groteszk ahhoz, hogy megérjen egy írást.

  • Az msdn verzió annyival rövidebb, hogy nem kér semmilyen kódot. Feltelepíted, majd kapsz 3 napot, hogy aktiváld.
  • Az eval verzió logikája, hogy nem kell hozzá kód, de 180 nap után a kardjába dől. Természetesen ezen időszak alatt, ha van rendes kulcsod, aktiválhatod és teljes értékű szervered lesz.

Eddig nincs is gond. Csakhogy valami mekkmester úgy gondolta, hogy utólag rárak még valami okosságot. Azt mondta, hogy milyen remek lenne, ha az eval verzióba már telepítés előtt be lehetne ütni a valós kódot, így két legyet ütünk egy csapásra. Berakták. Azzal a szubrutinnal együtt, amelyik online akarja leellenőrizni a kódot, hogy valós-e. Mindezt a telepítésnek abban a fázisában, amikor nemhogy mini operációs rendszer nincs a gépen, de még network sem. Trükkös, mi? Az ellenőrzés nyilván elhasal, bármilyen kódot is írsz be. Egyedül akkor megy tovább, ha üresen hagyod a mezőt. Gondolj bele, mennyi értelme van feltenni egy kérdést, de csak akkor továbbengedni a delikvenst, ha nem válaszol semmit.
És mindezt pluszban programozták bele a telepítőbe.
Finom.

Megjegyzés

Mindemellett el tudom képzelni, hogy pont fordítva történtek a dolgok és mind az eval, mind az msdn verzió a bolti változatból keletkezett, a kódbekérő rész részleges, illetve teljes kiműtésével. Sőt, még azt sem tartom kizártnak, hogy létezik valahol egy manual, ahol leírják, hogy az eval verziónál tilos bármit is beírni az ablakba. (A letöltési oldalon mindenesetre csak annyit említenek, hogy nem kötelező.) Még az is lehet, hogy nem akar online ellenőrizni, hanem egyszerűen csak kivették belőle a validáló rutint. Sok minden lehet. Ha így van, akkor ez az egész már nem tűnik annyira nagy hülyeségnek… de gányolásnak igen.

Újbeszél

2011-08-23 / / 2 Comments

A UNIX sokkal komplikáltabb – az átlagos UNIX buherátornak sose jut eszébe, hogy is hívják ezen a héten a PRINT parancsot

Az Igazi Programozó

Valamikor jókat röhögtünk a fenti íráson… és meg sem fordult a fejünkben, hogy egyszer a Windows operációs rendszerben is – egyáltalán, az se fordult meg a fejünkben, hogy a Windowsból operációs rendszer lesz – hasonló káosz alakul ki a nevek és szintaktikák körül.

Összelapátoltam ebbe az írásba, pusztán csak úgy magamnak, néhány fontosabb változást. Olyan egyszerű – legalábbis régebben egyszerű – fogásokról lesz szó, melyek ma már némileg megbonyolódtak.

Winhttp

Ha proxy mögül neteztünk, és olyan programot kellett indítanunk, amelyik képtelen volt kiolvasni az Internet Explorerből a proxy beállításokat (pl. Windows Update), akkor volt szükség a winhttp proxy beállítására. Ezt nagyon egyszerűen lehetett megoldani, a proxycfg paranccsal:

proxycfg -p proxyservername:portnumber -> beállította a proxyszerver értékét a winhttp-ben,
proxycfg -d -> lenullázta a proxyszerver értékét a winhttp-ben.

A Windows 2008 szerverben kinyírták a proxycfg-t, a tudását pedig átadták a netsh-nak. Itt így néz ki a parancs:

From Segédlet

Server Manager

A Windows Server 2008-ban kapott végre értelmet a Server Manager konzol. Most nem részletezem, mi mindent lehet vele kavarni, hiszen nem a dedóban vagyunk. Gondolom, azzal sem mondok újat, hogy volt neki parancssoros verziója is, mellyel pontosan ugyanannyi csodát lehetett varázsolni, mint a grafikus konzollal. Ezt a programot hívták úgy, hogy servermanagercmd.
A Windows Server 2008 R2-ben viszont megszűnt ez a parancs. Pontosabban, beleolvadt a Powershell-be. Elindítjuk, betöltjük a ServerManager modult

import-module ServerManager

és tulajdonképpen megint megtehetünk mindent, amit korábban is, csak teljesen más szintakszissal. Life long learning.

Időszinkron

Ez az ősidőkben (NT4) még elég cifrán működött, de aztán finoman becsiszolódott. Tartományi környezetben a PDC emulátor FSMO szereppel ellátott tartományvezérlőt kell hozzászinkronizálni egy külső forráshoz, tőle pedig – a szolgálati út betartásával – megkapja a többi tartományvezérlő, még akkor is, ha az erdő több tartományból áll. A tartományi kliensek pedig értelemszerűen a tartományvezérlőhöz szinkronizálnak.
A PDC emulátor beállítása pofonegyszerű volt:

net time /querysntp -> Lekérdezte az ntp szerver nevét
net time /setsntp:time.kfki.hu -> Beállította az ntp szerver nevét

A Windows Server 2008 R2 ezt is nyugdíjba küldte. Bejött helyette a w32tm parancs, a szintakszis pedig finoman szólva is durván bonyolult lett:

w32tm /config /manualpeerlist:time.kfki.hu,0×8 /syncfromflags:MANUAL /reliable:yes
w32tm /config /update
net stop w32time
net start w32time
w32tm /resync

A szkript – mert ez már az – önmagában is megérne egy elemzést. Mivel még mindig nem dedó, ezt rátok bízom: a parancs létezik a korábbi Windows változatokban, mind kliens-, mind szerveroldalon, a w32tm /? parancsra elég részletes help jön fel. Egy dolgot nem ír a help: mi a búbánat az a 0x8 függelék az ntp szerver neve mögött? Erre egy KB cikk ad választ: ezzel a kapcsolóval állítjuk be, hogy az ntp kérést kliens módban küldje a gépünk.

Jó az öreg a háznál

2011-08-19 / / 1 Comment

Takarítottam a sufniban és a kezembe akadt egy 10 mbites HUB. Először elmosolyodtam, aztán elérzékenyültem: Istenem, amikor ilyenekből építettük a hálózatot… a gyerekek alsósok voltak, nekem pedig még volt hajam…
Majd jött a következő gondolat: megőrizzem? Menjen a lomtalanításra szánt cuccok közé?

Nos, kidobásról szó sem lehet. Jó lesz ez még valamire.

1. Belehallgatni a hálózati forgalomba

Képzeld el, hogy van egy router az internet felé, a belső hálón pedig egy NAS. Egyik sincs rootolva (mert egyáltalán nem vagyok olyan vadember, mint amilyennek néha látszom), az utóbbin valami linux klón alapú oprendszer van. A NAS-on beállítható, hogy küldjön emailben riasztást, ha bármi rendkivüli esemény történt. Beállítottam. Van mellette egy ‘teszt’ gomb. Megnyomtam. Szűkszavú üzenet: a levélküldés sikertelen.
?
Ha látnám a hálózati forgalmat, sokkal okosabb lennék. De egyik eszközön sincs sniffer, a switchelt hálózatban meg cseszhetem a promiszkusz módot. Nos, ekkor jön a jó öreg HUB. Beledugom a NAS-t, beledugom a laptopot, beledugom a routert, és már indulhat is a Wireshark.

2. Kici ócó NLB

Nem lesz rövid. Ahhoz, hogy érthető legyen a levezetés, kénytelen leszek alaposan kivesézni ezt az egész NLB katyvaszt, közben persze el is fogok kalandozni jobbra-balra. De nem lesz minden haszon nélkül az írás, legalábbis remélem.
Kezdjük ott, hogy milyen NLB technikák is léteznek?
Multicast és Unicast.
Mindkét módszernél azt kell valahogy megoldanunk, hogy habár egy csomagot csak egy unicast IP címre küldünk el, az mégis több géphez érkezhessen meg. Sőt, az a varázsló, aki ezt elvégzi, gondoskodjon arról is, hogy a célgépek közötti terhelés elosztása konfigurálható legyen. Még sőtebb, tudjuk szabályozni azt is, hogy a szétszórás csak bizonyos portok között történjen meg.
A varázslót hívják NLB-nek, illetve a Windows implementációját WNLB-nek.

From Segédlet

2.1 Multicast

Ebben az esetben az NLB node-ok hálózati kártyái kapnak egy plusz unicast IP címet (VIP) és egy plusz multicast MAC címet (VMACM), a meglévő unicast IP címük (IP1/IP2) és MAC címük (MAC1/MAC2) mellé.

From Segédlet

A node-ok személyes adatforgalmát a módosítás nem érinti. Használják az IP1/2 és MAC1/2 címeket, élnek, mint Marci Hevesen. A switchben is a MAC1/2 címek jelennek meg, hiszen ez szerepel a csomagok Ethernet keretében. A VIP címet felvettük a DNS-be, kihirdettük a cégnél. Jön is a kliens és rá akar csatlakozni az NLB szolgáltatására. (Az egyszerűség kedvéért legyen ez egy weblap, de bármi más is lehet, ami egy tcp porton keresztül érhető el.) A felhasználó beírja a böngészőbe a címet, a DNS visszaadja neki a VIP-et, a gép elküld egy ARP kérést a VIP címre. Ez broadcast, tehát mindenki felkapja. Az NLB magára ismer és küld egy ARP választ, benne a VMACM címmel. A kliens örül, megvan a cél MAC address, beteszi az Ethernet keretbe, megy a csomag. A switch érzékeli, hogy a csomag címzettje egy multicast MAC cím, alaphelyzetben ezeket gondolkodás nélkül kitolja mindegyik portra, tehát a csomag megérkezik az NLB-hez is, aki a saját szeszélye alapján továbbtolja valamelyik node-ra.
Okos? Okos. Működik? Háát…
Akadnak bajok.
Például egy másik kliens a router mögül próbálkozik. Ilyenkor a túloldali ARP kérést a router ragadja magához, hogy majd ő küld egy újabb ARP kérést a másik alhálózaton. Elküldi, visszakap egy olyan kombinációt, miszerint a cél node-nak unicast IP címe és multicast MAC címe van. – Ne te, már ne! – hőköl vissza és eldobja a csomagot. Kommunikáció meglőve. Ezt még kilőhetjük úgy, hogy a router ARP táblájába felvesszük statikus bejegyzésként a VIP-VMACM párost, ilyenkor nincs ARP kérdezz/felelek, a router helyből tudja a MAC címet, tehát mehet a csomag. (Hozzáteszem, hogy vannak olyan háklis routerek, melyek nem csak az ARP válaszban nem bírják elviselni a unicast IP – multicast MAC kombinációt, hanem úgy egyáltalán sem. Ekkor elfelejthetjük a Multicast NLB-t, vagy érdemei elismerése mellett nyugdíjazzuk a routert.)
Oké, router rendben. De mi van, ha az NLB akar küldeni egy csomagot a nyúlon routeren túlra? Kezdi azzal, hogy küld egy ARP kérést a router IP címére. Windows 2003-ig bezárólag az NLB csalt, mert az ARP kérést a MAC1/2 címről küldte, de a Windows 2008 már a VMACM címet teszi a kérésbe. Mit csinál ezzel a router? Úgy van, kidobja oda, ahová a szabálytalan csomagokat szokta. A kommunikáció megint meghalt. Kénytelenek leszünk az NLB node-ok ARP tábláját is módosítani, fel kell venni a router IP-MAC párosát statikus bejegyzésként. Ekkor nem kell megvárnunk, hogy a router válaszoljon a szabálytalan kérésünkre, menni fog a feloldás séróból is.
És még nincs vége a galibáknak.
Mit is írtam? A switchre küldött multicast MAC címet tartalmazó csomagot a switch alapból kiküldi minden portjára. Jó ez nekünk? Nem annyira. Gyakorlatilag elárasztjuk a switchre kötött egyéb hostokat tök felesleges csomagokkal. (Úgy is hívják a jelenséget, hogy flood.) Természetesen ez ellen is lehet védekezni, de itt már elgondolkodik a rendszergazda arról, hogy mennyire is igaz a Microsoft azon állítása, hogy az NLB olcsó és egyszerű technika.
Az egyik megoldás úgy néz ki, hogy okos switchünk van, ahol be tudjuk állítani, hogy a multicast csomagok mely portokon jelenhetnek csak meg. A többi port coki. Ez működik, de olyan nem elegáns. Ha figyelmetlenül valamiért átdugom másik portba az NLB lábát, akkor újra floodolok, ráadásul lehet, hogy csak akkor veszem észre, amikor vezig ordítva beront a gépterembe a hálózat lassúsága miatt. (Oké, jobb helyeken a vezig kártyája nem nyitja a gépterem ajtaját, de nem biztos, hogy adott esetben ez a hosszútávú megoldás.)
Sokkal elegánsabb, ha még okosabb switchet használunk, mely már tudja az IGMP snooping technikát. Ekkor persze az NLB-t is konfigurálni kell. Azt mondjuk neki, hogy az ARP válasz csomag mellé tegyen már egy IGMP Host Membership Report csomagot is. Erre a csomagokra általában csak a routerek vevők, de nekünk okos switchünk van, aki bele tud lesni (snoop) az IGMP csomagba, és innentől tudni fogja, hogy mely portok mögött van olyan host, amelyik multicast vevő. A többire nem küldi tovább a multicast MAC címmel rendelkező csomagokat.
Végül természetesen megoldás lehet az is, hogy az NLB két lábát külön VLAN-ba tesszük. Ekkor ugyan a csomagok továbbra is elárasztják a broadcast domaint (a switchnek azokat a portjait, melyek a VLAN-hoz tartoznak), de mivel csak a két NLB láb érintett, így a floodolást az érintett portokra korlátoztuk. Viszont gondoskodnunk kell a VLAN elérhetőségéről.

Nos, ennyi. Látható, hogy a megoldáshoz módosítani kell mind a router, mind a node-ok ARP tábláját és minimum menedzselhető switchekre van szükségünk, akár portot akarunk konfigurálni, akár VLAN-t akarunk kialakítani, az IGMP snoopingról már nem is beszélve. Ez bizony se nem kici, se nem ócó. (A moddolt firmware-es olcsó routereket most hanyagoljuk.)

2.2 Unicast

Ennél az NLB technikánál más a trükk. Az NLB lecseréli a node-ok címeit, egy közös VIP és VMAC címre. Mindkettő unicast, tehát semmi szükség a multicast-os trükközésekre. Mivel mind a két node címei megyegyeznek, a nekik küldött csomagok megérkeznek az NLB-hez, aki már tud velük játszani.

From Segédlet

Nyilván ez sem ennyire egyszerű. Például milyen MAC címet jegyez be a switch a node-ok portjaihoz? A VMAC-et? Azzal gond lesz, mert az elsőt be fogja jegyezni, a másodikat már nem, mivel ugyanaz a MAC nem jelenhet meg más porton is. Ezzel jól ki is heréltük az NLB-t, mert mindig csak egy portra menne a forgalom.
A trükk az, hogy NLB elmaszkolja a VMAC címet. Összedob mindkét node számára egy kamu MAC címet és ezt teszi az Ethernet keretbe. (Az ábrán MACK1 és MACK2.) A switch ezeket a címeket fogja bejegyezni a portokhoz.
Nézzük akkor a folyamatot. VIP-et bejegyeztük, kihirdettük, felhasználónk beírja a böngészőbe, a gépe elküld egy ARP kérést a VIP címre. Az NLB felkapja, belerakja az ARP keretbe a valódi VMAC értéket. (Az Ethernet keretben a kamu MAC cím van, de ez jelenleg senkit nem érdekel.) A kérdező megkapja, boldog. Összedobja a csomagot. Hogyan? Hát belerakja a frissen kapott VMAC értéket az Ethernet keretbe. Elküldi. Mit fog ezzel a csomaggal csinálni a switch? Hát, zavarba jön. Ilyen MAC cím nincs hozzárendelve egyik porthoz sem. Ilyenkor a standard eljárás az, hogy a switch kiküldi a csomagot minden portra és reménykedik abban, hogy valahonnan visszajön egy válasz és akkor majd bejegyzi jól. Hát, ezt most várhatja.
Lássuk a cifrázást.
A router jelen esetben nem háklis. Mind a VIP, mind a VMAC normális unicast címek. Suhannak a csomagok, mint olajos hal a vécélefolyóban.
Ellenben. Tud-e kommunikálni a két node egymással? Nézzük. Node1 küld egy ARP kérést a VIP címre. Az ARP keretben visszakapja a VMAC értéket. Ezt belerakja a küldendő csomag Ethernet keretébe… majd döbbenten észleli, hogy ez az ő MAC címe. Nem küldi sehova.
Legalábbis nem mindig. És nem mindet.
Ott van például az NLB heartbeat. Erről annyit kell tudni, hogy broadcast, az Ethertype értéke 0x886F és csak node szinten működik, azaz azt nem tudja megállapítani, hogy a port szabályokban megadott portokon tényleg fut-e valami szolgáltatás. Na, ez a kommunikáció például megy. Miért is? Hiszen mondtam: broadcast. Csak a célzott kommunikáció nem megy.
És az se mindig döglődik. Windows 2003 Sp1 óta pl van egy érdekes lehetőség. A registry-ben engedélyezhető (UnicastInterHostCommSupport) hálózati kártya szinten, hogy unicast node-ok is tudjanak egymással beszélgetni.
Ettől függetlenül ez a modell nem terjedt el. Gondoljunk bele, mit csinálnánk, ha rendszergazdaként be szeretnénk lépni konkrétan az egyik node-ra? Az NLB meg mindig a másikra dob. Idegbaj. Emiatt is szoktak berakni az NLB kártya mellé egy másik hálózati kártyát.

From Segédlet

Nem mondanám, hogy egyszerűsödik, mi? Számok, szaggatott nyilak, minden, ami szem-szájnak ingere.
Az alapprobléma az, hogy melyik kártyán legyen beállítva a default gateway. Mindkettőn nem javasolt, mint ahogy a Windows erre figyelmeztet is. Na jó, akkor melyik legyen a nagy hatótávolságú, routeren is átlátó kártya és melyik az, amelyik csak a subneten beszélget? Hülye kérdés. Nem így fogjuk rendezni a helyzetet. Egyszerűen beállítjuk a normál kártyát első számú kártyának (erre kerül a default gateway), az NLB kártyát meg második számúnak. Így bármelyik kártyán is jön be csomag, kifelé a normál kártyán fog menni.
Ha hagyják.
A Vista/Windows Server 2008 vonulat óta a hálózati kártyák összelinkelése alaphelyzetben tiltott. Azaz ha az NLB kártyán jön be egy csomag, akkor az nem tud kimenni a másik kártyán. Ehhez netsh segítségével rá kell linkelni az NLB kártya forgalmát a normál kártyára. Ekkor már ki tud menni.
Windows Server 2008 esetén ugyanezt másképpen is el tudjuk érni. Modellváltás. A Windows Server 2008 alaphelyzetben az ún. Strong Host modellt használja. A korábbi szervertermékek a Weak Host modellt alkalmazták, mely azt jelenti, hogy az operációs rendszernek semmi kifogása sincs az ellen, hogy multihomed (több hálókártyás) rendszerben az egyik kártyán keresztül el lehessen érni a másik kártyán futó szolgáltatásokat. A mi esetünkben ez azzal jár, hogy a Windowst át kell váltani a Weak Host modellre. Naná, ezt is netsh-val, méghozzá kártyaszinten, azon belül is külön küldő, illetve külön fogadó irányban.
Zsong már a fejed? Pedig még nincs vége.
Nézzük át, mi is történik ilyenkor. VIP publikálva, felhasználó gépétől jön az ARP kérés a VIP címre. Ez broadcast, kimegy mindenhová, az NLB felkapja. A válaszba belerakja a VIP és a VMAC értékeket. A visszamenő csomag viszont már a konkrét gép valós hálózati kártyáján megy ki, annak a MAC címe kerül bele az Ethernet keretbe… de ez megint senkit nem érdekel. A túloldalon kicsomagolják az ARP keretet, a következő csomag Ethernet keretébe már az onnan jövő MAC (VMAC) kerül, ez kikerül minden switch portra (mert ismeretlen), az NLB felkapja, a válaszcsomag megint a normál kártyáról megy ki… és így tovább.

Akkor most gondoljuk végig, mi a helyzet flood téren?
Hát, ugye, van. Éppen az előbb jártuk körbe.
Védekezési lehetőség? Nos, az IGMP itt nem játszik, hiszen nincs multicast. Emiatt a switch portját sem tudjuk multicastra konfigurálni. Bizony, egyedül a VLAN felosztás segít, azaz megint drága, menedzselhető switch kell.

És ez az a pont, ahol az eddig csendben üldögélő HUB végre szerepet kap.

From Segédlet

Mi az a csoda, amit a HUB tud? Hát az, hogy nagyjából akkor élte a fénykorát, amikor az NLB-t kitalálták. Erősebbet mondok: az NLB-t a HUB-hoz találták ki, ez az eszköz az NLB ideális játszótere. Miért? Mert a HUB abszolút nem foglalkozik a MAC címekkel. Nem azon a szinten dolgozik. Nagy ívben tojik arra, hogy mit bűvészkedünk a keretekben az L2 címzésekkel. Ez majd a később elszaporodó és egyre okosabb switchek problémája lesz.
Nézzük meg, mit is csináltunk. Az NLB hálókártyákat nem közvetlenül dugtuk be a switchbe, hanem beraktunk eléjük egy HUB-ot. Ennek már csak egy uplinkje kerül bele a switchbe. Mennyi? Egy.
Járjuk körbe ismét a folyamatot. A switch portjára két MAC is rákerül, a kamu MACK1 és a MACK2. A kliens elindít egy ARP kérést, ez broadcast, kikerül a HUB-ra, az NLB felkapja. Valamelyik normál hálókártyáról válaszol, az ARP keretben a VMAC. Kliens következő csomagjában az Ethernet keretben a VMAC, beérkezik a switchbe… ahol megint nem lesz ilyen MAC egyik portnál sem, tehát megint floodolunk.
Izé. Nem maradt itt ki valami?
Dehogyisnem.
A switchben most már csak egy helyen jelenne meg a VMAC, tehát nincs szükség maszkolásra. Egyszerűen kikapcsoljuk: MaskSourceMac érték nullára állítása a registryben. Ekkor kapjuk a fenti ábrán látható szituációt. A HUB letojja, hogy két lábán is ugyanaz a MAC – a VMAC – jelenik meg. Hiszen nála meg se jelenik, nem érzékeli. (Ezért piros.) Az uplinken – függetlenül attól, hogy melyik node-tól jött – csak a VMAC jelenik meg, tehát ez kerül rá a portra. A kliens ARP kérésére az NLB válaszol. Maszkolás nincs, tehát mind az Ethernet, mind az ARP keretbe a VMAC kerül. (De az Ethernet keret még mindig nem érdekli a klienst. A switchet annál inkább.) A kliens a VMAC címre küldi az újabb csomagot, a switchen van ilyen MAC a portoknál, tehát flood kilőve, a csomag csak a HUB-ra jut ki.

Nézzük meg, mit csináltunk. Van egy borzasztó gagyi, nem menedzselhető switchünk és egy, a sufniból előkukázott HUB. Mindösszesen egy plusz kábelbe, illetve egy registry állításba került és tökéletesen működő NLB megoldásunk van.
Tényleg jó néha az öreg a háznál.

Ps1.
Felvetődhet, hogy jó-jó, de mi a helyzet a sebességgel? A switch már jó eséllyel gigás. Hogyan lesz ezzel összhangban a 10 mbites HUB? Melyik piacon lehet venni gigás HUB-ot? A helyzet nem ennyire rossz. Nézzük csak meg, hogyan forognak a csomagok. A szerverre – konkrétan az NLB kártyára – küldött csomagok tényleg keresztülmennek a HUB-on, de a szerverről a kliens felé menő forgalom már közvetlenül a switchre megy. Legtöbbször a kliens csak vezérlő utasítást küld a szerver felé, az pedig adathalmazokat tol vissza – azaz a HUB pont ott szűk keresztmetszet, ahol egyébként sem nagyok az igények.

Ps2.
A cikknek ezzel még nincs vége. Az első célt elértük, látjuk, hogy a HUB-ot tényleg tudjuk még mire használni. De a téma még nincs körbejárva: mi a helyzet például a virtuális környezettel?

Saját könyvtár

2011-08-19 / / 0 Comments

Az Exchange blogban hívták fel a figyelmet, hogy az Office blogban megjelent egy hasznos kis cikk. És tényleg. Arról szól, hogyan lehet a Technet Library anyagaiból saját offline könyveket összeállítani, pár kattintással. A könyvek formátuma xhtml, illetve pdf, az utóbbi már mehet is a Kindle-re.
Az összes probléma annyi, hogy meglehetősen alacsony a limit: egy könyvbe 100 lapnál több nem kerülhet, márpedig a Technet Library – a sok ugrólap miatt – meglehetősen töredezett. Konkrét példa: az Exchange 2010 HA és Site Resiliency + Performance topikok önmagukban alkotnak egy kötetet, 70 lap, 220 oldal.

Új blog

2011-08-12 / / 5 Comments

Finoman szólva sem vagyunk elkényeztetve magyar nyelvű, IT infra témájú blogokkal. Azon kevesek, amelyek még működnek, vagy átmentek csiripbe, vagy szökőévente frissülnek. (Értem ezt jelen blogra is.) (Bár Asteriksz kolléga éppen a napokban táltosodott meg.)
Erre a pangó piacra lépett be egy új blog. A szerző volt kollégám, ismerve őt, az írások szakmai szinvonalára látatlanban azt mondom, hogy nem lesz panasz. Ajánlott kategória.

Mennyi is az annyi?

2011-08-02 / / 0 Comments

Feltehetően mindenki hallott már az Exchange adminok életét megkeserítő a remek stub alapú archiválási technikáról. Arról van szó, hogy egy külső gyártó terméke (pl Symantec Enterprise Vault) MAPI felületen végigszkenneli az Exchange kijelölt adatbázisait, majd a beállított feltételeknek eleget tevő levelekből (méret, időpont) a tartalmat kiveszi, átrakja a saját adatbázisába, az eredeti helyen pedig csak egy pointert hagy ott, mely az átmásolt tartalomra mutat.
Az elv még nem is lenne rossz – bár látjuk, hogy összességében helyet nem nyertünk, viszont az Exchange adatbáziskezelő műveletei felgyorsultak. Persze ennek ára is van, a csonkolt levelek elérése lassabb, egy disaster utáni recovery kész horror (pedig eleve sem egy leányálom), plusz adminisztráció, na meg több zsák pénz.

Most ne menjünk bele, hogy ennek van-e egyáltalán létjogosultsága Exchange 2010 alatt (itt ugye az adatbázisok maximális mérete a tera tartományban mozog). Tételezzük fel, hogy már van ilyen rendszerünk, megörököltük a korábbi Exchange verziónkkal. Jelen cikkben csak egy apróságra hívnám fel a figyelmet: hogyan lehet egy pitiáner tervezési hibával hülyét csinálni magunkból.

De előbb számoljunk. Exchange 2003 alatt a default blokkméret az adatbázisban 4 Kbyte, Exchange 2007 alatt 8 Kbyte. Azaz bármekkora is volt a levél, egy 4/8 Kbyte méretű stub marad a levél helyén. A felszabaduló helyet pedig az Online Maintenance visszadolgozza a szabad területek közé.
Az Exchange 2010 alatt a blokkméret 32 Kbyte lett. Gondoljuk el: akármekkora volt a levél, 32 Kbyte hely mindig foglalt marad a számára. Rólam tudni kell, hogy hajlamos vagyok több képernyő hosszúságú emaileket írni, de még ezek sem érik el a 32K méretet. Gyakorlatilag ezt a határt csak csatolással szokták átlépni – igaz, azzal nagyon.
Akkor mi is az a pitiáner hiba? Az, amikor úgy állítják be a külső rendszert, hogy alaphelyzetben a csatolásokat archiválja, de egy bizonyos idő eltelte (mondjuk egy év) után minden levelet. Ez az utóbbi húzás az, amelynek az égegyadta világon semmi értelme sincsen. A levél után ott marad a 32K hely, igaz, ezen belül a sok szöveg helyett csak egy link lesz benne – de a felszabaduló hellyel az Online Maintenance nem tud mit kezdeni. Foglalt marad. Cserébe megnyerjük, hogy plusz helyet foglalunk el az archiváló rendszerben, a felhasználó lassabban éri el a régi levelét, egyszerre kell gondoskodnunk mind a két rendszer rendelkezésreállásáról és kinlódhatunk mind a backup/restore, mind a DR folyamatainkkal.

Azaz, ha használunk ilyen külső rendszereket, akkor felejtsük el az idő alapon történő archiválást az összes levélre, koncentráljunk csak a csatolásokra. (A magam részéről pedig azt tenném hozzá, hogy gondolkozzunk el a Personal Archive és menedzselt mailbox kombináción, sokkal olcsóbban – és egyszerűbben – is el tudjuk érni ugyanazt, mint a külső cuccokkal.)