Month: November 2009

Lehet egy node-dal több?

2009-11-25 / / 1 Comment

Scott Schnoll Exchange 2010 High Availability (HA) előadása után gondolkodtam el néhány dolgon. Van ugyanis egy olyan HA matek, amellyel eddig egy Exchange mérnök még nemigen találkozott.

Történelmileg volt ugye az SCC, azaz a Single Copy Cluster. Ez viszonylag egyszerűen nézett ki, volt egy közös diszk – rajta a quorummal – aztán voltak a node-ok, ha jól emlékszem, maximum négy. (Nem néztem utána, annyira nem is lényeges most a pontos szám. A gyakorlatban én eddig maximum 3 node-ra épülő clusterrel találkoztam.) Hogyan nézett itt ki a HA?

  • Ha kidőlt a közös diszk, vagy akár csak a közös diszken lévő quorum, akkor összedőlt a cluster is. (Hányszor hallottam már olyanról, hogy valaki megörült, hogy milyen sok hely van a Q: meghajtón és elkezdett fájlokat másolni rá. Aztán amikor megtelt és lehalt a cluster, akkor meg volt csodálkozás.)
  • Ha node dőlt ki, akkor amíg volt másik node, addig nem volt baj. A cluster működéséhez elég a diszk (quorum+adat) és egy node.

A Windows Server 2003 SP1 után kijött egy patch, mellyel a termék már ismerte a File Share Witness technikát. Ez volt az első lépés a demokrácia irányába. A Windows 2008 Server ezt már helyből tudja, sőt ki is bővítette – de erről majd később.

Az Exchange természetesen igyekezett kihasználni az új játékszert. Az FSW megteremtette a lehetőséget a logshipping elven működő clusterezési technikák előtt. Pontosabban, a logshipping lokális és standby módban megy mindenféle clusterezés nélkül, csak a CCR-hez kell az FSW. De ahhoz nagyon.
Igaz, ez azért elég korlátozott rendszer. Például maximálisan két node lehet. Azaz ha van egy FSW és a két node, akkor kapunk egy három komponensből álló rendszert, ahol kettőnek mindig működnie kell, hogy a rendszer egésze is működjön.
Vegyük észre, hogy mekkora különbség ez az SCC-hez képest. Ott ugyanis a qourumnak mindenképpen működnie kellett. Itt már csak egy szavazásra egyszerűsödött le a helyzet: a játékosok felénél többnek (min. 50.000000001%) élnie kell ahhoz, hogy a cluster működjön.

Exchange 2010-et már csak Windows Server 2008-ra telepíthetünk. Csakhogy itt már nem csak egy szimpla FSW van a spájzban, hanem jóval több alapanyagból főzhetünk.

  1. Node Majority
    Csak a node-ok játszanak, más nem. Ha a felénél több él, akkor működik a cluster.
  2. Node and Disk Majority
    Bejön a képbe egy ún. witness disk. Ez az a merevlemez, amelyiken a quorum található. Innentől kezdve a játékosok száma megnő eggyel.
  3. Node and File Share Majority
    Ez a korábbi FSW. A quorum nem diszken lakik, hanem kikerül egy megosztásba és ez a megosztás (witness share) is belép a játékosok közé.
  4. No Majority
    Gyakorlatilag a korábbi SCC modell. A quorum diszk az adu ász, mely mindent visz.

És mindemellett a node-ok száma maximum 16 lehet.

Lássuk, mi jön ki ezekből az alapanyagokból.

Az Exchange 2010-ben a quorum diszket, mint olyat, kidobták. Így a négy lehetőségből rögtön kiesik kettő, marad az 1 és a 3.
Nagy kérdés, hogy ezek közül mikor és melyiket alkalmazzuk? A válasz az, hogy felejtsük el. Egész egyszerűen ezt nem mi fogjuk eldönteni.

Miért?
Elmagyarázom.

Legyünk egy izgága Exchange rendszergazdák. Éppen most döntötte el a cég, hogy a magas rendelkezésreállású Exchange 2007 CCR rendszert lecseréli egy szintén magas – sőt, ha lehet, akkor még magasabb – rendelkezésreállású Exchange 2010 rendszerre. Rutinból elkezdünk rajzolni: akkor lesz egy FSW a Hub Transport szerveren és – mivel itt már lehet – legyen akkor 3 node. Mert minél több node, annál nagyobb a biztonság. Megtervezzük. Megcsináljuk. Üzemel.
Aztán egyik nap kidől az egyik node. A szempillánk sem rebben. Éppen a darabokra szerelt gépben turkálunk, amikor valaki véletlenül kirúgja a másik node 220-as csatlakozóját a falból. Csak kacagunk rajta. Egészen addig, míg egy óra múlva munkakönyvvel a zsebünkben repülünk kifelé az ablakon.

Mi is történt?

Van négy játékos: 3 node és 1 FSW. Kidől egy node. Megvan a többség? 3:1, azaz igen. Kidől még egy. Most megvan? 2:2. Mennyinek kell lennie a többségnek? Min. 50.000000001%-nak. Ez bizony nincs meg.
Azaz vetettünk a céggel még egy plusz vasat súlyos milliókért és egy fikarcnyival sem lett megbízhatóbb a rendszerünk – hiszen ha belegondolunk, a 2 node + 1 FSW rendszer is pont egy node kiesést bírt el. Mindezt wálság idején. Nyilván kirúgtak.

Következő munkahelyünkön egyszer csak azt a feladatot kapjuk, hogy bíráljuk el egy külső konzulens ajánlatát. Átfutjuk és egyből kiszúrjuk, hogy az illető úgy képzelte el a magas rendelkezésre állású Exchange 2010 rendszert, hogy abban 3 node van.
– Hah! – rontunk be Vezérigazgató Bálinthoz – Ez a konzulens egy idióta sarlatán! Abszolút felesleges pazarlás 3 node-ból álló clustert tenni az Exchange 2010 alá!

Ezzel rögtön két hibát követtünk el. Egyrészt nem tudtuk, hogy a konzulens a vezérigazgató unokaöccse. Másrészt szembesítés után a konzulens higgadtan, okosan elmagyarázza, hogy ő úgy képzelte, miszerint az Exchange cluster Node Majority quorum modellt használna, azaz a négy játékos közül az FSW-t hagyná el. A plusz node-nak pedig nem a node szintű redundancianövelés a célja, hanem az adatbázis szintű redundanciáé. Ráadásul ha 3 node-ot használ, akkor nem kell méregdrága (DAS) diszktömb a node-ok mellé, hanem egyszerű, RAID vezérlő nélküli vincseszterek is megteszik, melyeket itt lent a Közértben lehet venni kilóra. Ezzel nem csak ezt érik el, hogy a 3 node olcsóbb lesz, mint a kettő(1), hanem sokkal olcsóbbak lesznek a későbbi bővítési lehetőségek is, feltéve, hogy a Közértben nem fogy el a lemez.

Ezek után Bálint bólint – és már megint repülünk.

Nos, pont azért, hogy ne rúgjanak ki olyan sok Exchange rendszergazdát, a fejlesztők úgy döntöttek, hogy kiveszik a döntést a humanoidok kezéből. Amikor összerakunk egy DAG-ot, akkor páratlan számú node esetén automatikusan Node Majority tipusú cluster jön létre, páros számú node esetén pedig Node and File Share Majority tipusú. Természetesen a váltás dinamikus, ahogy bővítem vagy szűkítem a DAG-ot, úgy változik automatikusan a modell is.

(1) Természetesen ez csak nagy adatbázisok esetében igaz. De mikor nem nagy egy Exchange adatbázis? Különösen akkor, ha az Exchange 2010-ben levették róluk a féket és azt mondták a postafiókoknak, hogy szaporodjatok, sokasodjatok és töltsétek be a Földet?

Hiányzó képek

2009-11-24 / / 0 Comments

A biztonság jó dolog.

Csak épp néha piszokul bosszantó.

Vegyük elő kedvenc Outlookunkat és tapasztalni fogjuk, hogy a beérkezett levelek egy jó részében nincsenek képek, csak egy kék figyelmeztető sáv, hogy ha akarjuk, akkor letölthetjük a képeket, de ez biztonságilag kockázatos.

Miért van ez így? Miért van az, hogy bizonyos levelekben vannak képek és bizonyos levelekben nincsenek?

A HTML formátumú levelekbe a képeket két módszer szerint tudjuk berakni.

Az egyik az úgy nevezett Online HTML. Ebben az esetben a levélben van egy img tag, aminek az src attributuma egy web szerveren tárolt képre mutat. Ennek a megoldásnak az az előnye, hogy az elküldött levél maga viszonylag kicsi lesz, mert a képek nincsenek benne. További előny, hogy a küldő tud a háttérben statisztikát vezetni arról, hogy az adott levelet megnyitották-e (ha letöltötte a címzett a képet, akkor megnyitotta a levelet). Előny lehet még a feladó számára, hogy a képet utólag is tudja módosítani*. Ennek a megoldásnak vannak hátrányai is. Az Outlook az ilyen levelekre rakja fel a fent említett kék csíkot és nem tölti le a képeket. Ha valamiért a címzett, vagy a küldő web szervere offline, akkor nem tudunk hozzáférni a képekhez.

A másik az Offline HTML, amelyben az img tag src attributuma egy cid bejegyzést tartalmaz ami a levélben magában lévő rejtett csatolmányra mutat. Ez tartalmazza a képet magát. Előnye, hogy mindig elérhető a címzett számára, az Outlook nem szűri ki, ugyanakkor hátránya, hogy nagyméretűek lesznek a levelek tőle.

Vajon az Outlook miért szűri ki az első levél típusban szereplő képeket?

Mert ez a gépre nézve potenciális támadást is hordozhat. Az elmúlt években több olyan sérülékenység is napvilágra került, amit a Windows képfeldolgozó motorjában találtak és speciálisan formázott képfájlal kihasználhatóak voltak. Tehát, ha nem töltöm le a képet, akkor nem tud kárt okozni.

De engem zavar, hogy állandóan kézzel kell letöltenem a levelet. Ki lehet kapcsolni?

Igen, de nem érdemes, az ok az előbb taglalt biztonság.

Jó, de akkor mi a megoldás? Hogyan lehetne elérni, hogy azoknál a leveleknél, amiknél én szeretném automatikusan letöltődjenek a képek (pl. rendszeres, olvasott hírlevelek).

Erre van megoldás. Ha megnézzük az Outlook biztonsági beállításai között találunk egy ilyet:

 Trusted Zone

Bekarikáztam a lényeget. Tehát, ha a kép forrását berakjuk az Internet Explorer Trusted Zone-ba akkor a képet automatikusan le tudjuk tölteni.

Ok. Akkor rakjuk be. Na, ezzel lesz némi gond. Nincs olyan gomb, menü, valami az Outlookban, ami ezt megtenné nekünk. Ha van egy levelünk, aminek a linkjeit használni szeretnék, akkor szükségünk lenne a levél HTML forrására, hogy ki tudjuk másolni a megfelelő linket. Sajnos ezzel sem rendelkezünk, ugyanis ezt az  Outlook eldugja előlünk.

Mit tehetünk? Programozunk.

Írtam egy pici Outlook makrót, ami beköltözik a levél context menüjébe és ha ott rábökünk a Trust Picture Source menüpontra, akkor a levélben (vagy levelekben) lévő img src attributumokból kibogarássza a web oldalak címeit és berakja őket a Trusted Zone-ba.

A dolog működik, csak egyetlen szépséghibája van. A működés eredménye, csak az Outlook újraindítása után látható. A kód Outlook 2007-en működik (a korábbiakon nem).

Akkor rakjuk fel!

Nyissunk az Outlookban egy VBA ablakot (Alt+F11) A ThisOutlookSession-on jobb egérgomb, View Code.

Ide másoljuk be ezt:

Option Explicit
Private TrustPictureContextMenus As TrustPicturesMenu
Private WithEvents objOL As Outlook.Application
Private Sub Application_Quit()
    Set TrustPictureContextMenus = Nothing
End Sub
Private Sub Application_Startup()
    Set TrustPictureContextMenus = New TrustPicturesMenu
End Sub

Ezek után a Class Modules ágon jobb egérgomb, Insert/Class Module. Majd a keletkezett modult nevezzük át TrustPicturesMenu-re.

A kód ablakba pedig rakjuk be ezt:

Option Explicit
Private WithEvents objOL As Outlook.Application
Private WithEvents objTrustPictureButton As Office.CommandBarButton
Private Sub Class_Initialize()
    Set objOL = Outlook.Application
End Sub
Private Sub objTrustPictureButton_Click(ByVal Ctrl As Office.CommandBarButton, CancelDefault As Boolean)
    Dim RE As Object, REMatches As Object
    Set RE = CreateObject("vbscript.regexp")
    With RE
        .MultiLine = False
        .Global = True
        .IgnoreCase = True
        .Pattern = "<img\b[^>]*src=""(https?)://([^/]*)[^""]*""[^>]*>"
    End With
    ReDim Sites(1, 0) As String
    Dim objItem
    Dim SiteFound As String
    Dim ProtocolFound As String
    Dim SiteInArr As Boolean
    Dim SiteMatch
    Dim Site
    Dim i
    For Each objItem In objOL.ActiveExplorer.Selection
        Set REMatches = RE.Execute(objItem.HTMLBody)
        For Each SiteMatch In REMatches
            SiteFound = LCase(SiteMatch.SubMatches(1))
            ProtocolFound = LCase(SiteMatch.SubMatches(0))
            SiteInArr = False
            For i = 0 To UBound(Sites, 2)
                If Sites(0, i) = SiteFound And Sites(1, i) = ProtocolFound Then
                    SiteInArr = True
                    Exit For
                End If
            Next
            If Not SiteInArr Then
                If Sites(0, UBound(Sites, 2)) <> "" Then
                    ReDim Preserve Sites(1, UBound(Sites, 2) + 1)
                End If
                Sites(0, UBound(Sites, 2)) = SiteFound
                Sites(1, UBound(Sites, 2)) = ProtocolFound
            End If
        Next
    Next
    Dim DomainPartArr
    Dim HostPart As String
    Dim DomainPart As String
    Dim j, k
    For i = 0 To UBound(Sites, 2)
        DomainPartArr = Split(Sites(0, i), ".")
        DomainPart = ""
        HostPart = ""
        For j = 0 To UBound(DomainPartArr) - 2
            HostPart = HostPart + DomainPartArr(j)
            If j < UBound(DomainPartArr) - 2 Then
                HostPart = HostPart + "."
            End If
        Next
        For k = j To UBound(DomainPartArr)
            DomainPart = DomainPart + DomainPartArr(k)
            If k < UBound(DomainPartArr) Then
                DomainPart = DomainPart + "."
            End If
        Next
        RegKeySave "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\" _
                    & DomainPart & "\" & HostPart & "\" & Sites(1, i), 2, "REG_DWORD"
    Next
End Sub
Sub RegKeySave(i_RegKey As String, i_Value, Optional i_Type As String = "REG_SZ")
    Dim myWS As Object
    Set myWS = CreateObject("WScript.Shell")
    myWS.RegWrite i_RegKey, i_Value, i_Type
End Sub
Private Sub objOL_ItemContextMenuDisplay(ByVal CommandBar As Office.CommandBar, ByVal Selection As Selection)
    Dim objItem As Object
    Dim blnFoundItem  As Boolean
    Dim objCBB As Office.CommandBarButton
    For Each objItem In Selection
        If objItem.Class = olMail Or objItem.Class = olPost Then
            blnFoundItem = True
            Exit For
        End If
    Next
    If blnFoundItem = True Then
        Set objCBB = CommandBar.Controls.Item(1)
        objCBB.BeginGroup = True
        Set objCBB = CommandBar.Controls.Add(msoControlButton, , , , True)
        objCBB.Style = msoButtonWrapCaption
        objCBB.Caption = "Trust Picture Source"
        objCBB.BeginGroup = True
        Set objTrustPictureButton = objCBB
    End If
End Sub

 Mentsük el az egészet.

Ezek után, már csak a kód biztonsági beállításokat kell megtennünk, hogy a dolog működjön (digitális aláírás, miegymás 🙂 )

Használata:

Odanavigálunk kiszemelt levelünkhöz, nyomunk rajta egy jobb egérgomot és…

Context Menu

 * Erről van egy történetem. Van egy ismerősöm, aki az egyik magyar banknál dolgozott biztonsági szakértőként. Egy spammer banda az ő bankjuk nevében küldött megtévesztő leveleket (phishing). A rosszfiúk elkövették azt a hibát, hogy Online HTML levelet küldtek, amiben a logo a bank honlapjára mutatott. Az ismerősöm fogta magát és kicserélte a logót a honlapon egy figyelmezetésre, melyben jelezte, hogy a levél hamis és a tartalmát senki se vegye figyelembe.

Az IPv6 és az Exchange 2010 románca

2009-11-23 / / 5 Comments

Egy újabb bájos jelenség. Dave Goldmann címlistamágus blogjában olvastam egy aranyos sztorit.

Az Exchange 2010 ugye már csak Windows Server 2008 oprendszerre megy fel. Ez a windows viszont már helyből beépített IPv6 tudással települ fel. Ez az emberek egy részét nem szokta zavarani – de a szerverüzemeltetők között akad rendesen paranoiás alak is, akik úgy vélik, hogy amire nincs szükség, az ne is legyen fent. És kiveszik a pipát az IPv6 checkbox elől.

Nos, ők járnak úgy, mint David. Az Exchange 2010 szerverük harakirit követ el.

Tapétamániákusok, figyelem!

2009-11-19 / / 2 Comments

A TechEd-en egy előadáson tette ki az elóadó – Charlie Chung – ezt az ábrát egy ppt slide-ra. Én úriemberként csak diszkréten csikorgattam a fogamat: normális vagy, barátom? Egy ilyen bonyolult ábrát kivetíteni? Hát emellett akár fel is olvashatnád visszafelé az Alice Csodaországban-t (úgy sem lenne több értelme), akkor sem figyelne senki arra, miről is beszélsz. Egy ilyen bonyolult, ellenben roppant fontos ábra láttán mindenki igyekszik pillanatok alatt minél többet felszívni belőle. Dehogyis jut ilyenkor agysejt az előadó szövegének dekódolására.

Tiszta szerencse, hogy a Microsoft elérhetővé tette mindkettő diagramot a neten. Tehát mindenki, akit érint, mindenki, aki éppen nem tud milyen háttérteret a Windows képernyőjére, innen le tudja tölteni az Exchange 2010 Transport Server szerkezeti diagramjait.

Megyen a log vándorútra

2009-11-06 / / 2 Comments

Nagyjából éppen a bokáig érő lószarban sárban cuppogtam Moritzburg környékén, amikor egyik ügyfelünk nem kicsit bonyolult Exchange mailbox szervere úgy döntött, hogy torkonszúrja magát. No nem nagyon, de két mailbox adatbázis és a public folder adatbázis leállt. Kolléga rávetődött az incidensre. Hamar rájött, hogy a leállást az okozta, hogy betelt egy log partíció. Egy olyan partíció, ahová ez a 3 adatbázis dolgozott.

Kitérő:

Igen, ilyet teljesítményproblémák miatt nem szoktak csinálni. Csakhogy egész egyszerűen az ügyfélnél annyi adatbázis van, hogy nincs annyi betű az angol ABC-ben, hogy minden log könyvtárhoz külön partíciót rendeljünk. Így a 3 legritkábban használt, legkisebb adatbázis log fájljait egy partícióra tettük.

Nos, a két pici mailbox adatbázisból az egyik bevadult. Nem, nem a korábbi bevadulás, ennek üzleti okai voltak. A vadulás miatt elszabadultak a logfájlok, betelt a partíció, méghozzá olyan gyorsan, hogy a riasztás után már cselekedni sem maradt időnk – aztán leállt mindhárom adatbázis.

Kitérő:

Maga az Exchange mailbox rendszer a következőképpen nézett ki: CCR rendszer egy aktív és egy passzív node-dal, melyhez kapcsolódott egy SCR rendszer egy passzív node-dal.

Tehát ez volt a játszótér és adott volt a feladat. Az ügyfél nyilván ki volt kattanva, hiszen mi az, hogy egy ilyen bonyolult cluster elérhetetlenné válik – és természetesen azt várta el, hogy minél hamarabb megint elérhetőek legyenek az adatbázisok. Kolléga fogta, és a CCR mindkét node-ján elmásolta ugyanazt a nagy kupac régi – ergo már biztosan rájátszott – logot mind a public folder, mind a bevadult adatbázis logkönyvtárából, felmountolta az adatbázisokat és minden be is indult szépen. Az adatbázisok működtek, sőt, a konzol alapján a log replikáció is egészséges volt. Problem solved.

Egészen addig mindenki nyugodt volt, amíg el nem érkezett a mentés ideje. De elérkezett. Le is ment – majdnem minden adatbázisra. Egy, csak egy szaladt hibára, az a bizonyos vad adatbázis. Mely ugye nem véletlenül vadult be, a hirtelen megnövekedett üzleti igények okozták a hízást – azaz meglehetősen fontos adatok kerültek az adatbázisba.

Kolléga még megnézte az eseutil /mh paranccsal, hogy konkrétan milyen log fájlok hiányoznak a passzív node-on – de a válasz az volt, hogy semmi. Rá lett küldve egy reseed (update-storagegroupcopy), de csak annyit csinált, hogy a passzív node-on kiürült a logkönyvtár.

Ekkor érkeztem vissza szabadságról és rögtön meg is kaptam a feladatot.

Helyzetfelmérés:

  • Az adatbázis megy, ránézésre a log replikáció egészséges, az ügyfél nyugodt.
  • Ezzel szemben az aktív node-on rengeteg log van, a passzív node-on egy sem. Az adatbázisok azonos méretűek, azaz a reseeding sikerült.
  • Az SCR node-on az a bizonyos partíció fullon volt, a replikáció az említett adatbázisokon állt. Szemmel láthatóan az SCR-rel senki sem foglalkozott.
  • Viszont mivel nem sikerült a mentés, az aktív node-on pár óra múlva megint elfogy a hely, szóval nagyon gyorsan ki kell találni valamit.

Ergo egyfelől meg kellett akadályoznom az újabb leállást, másfelől össze kellett kötözgetnem a szálakat, mert itt valami nagyon félrement.

A feladat első része volt az egyszerűbb. Kerestem egy üres partíciót (későbbi fejlesztésekre volt is félrerakva egy, de a későbbi szó pont azt jelenti ugye, hogy nem mostani), majd átirányítottam ide a logolást.
Ránézésre olyan egyszerűnek és logikusnak tűnik – de nem az. Nem véletlen, hogy a kollégám sem így próbálkozott. Neki ugyanis sietnie kellett.
Első lépésben ugyanis suspendbe kell rakni a log replikációt. Ez még nem is fáj.
Második lépésben dismountolni kell az adatbázist, ráadásul bizonytalan ideig. Ez már fájt az ügyfélnek, nem is mentek bele szó nélkül. Amikor közöltem velük, hogy ez van, törődjenek bele, nincs más lehetőség, rögtön jöttek, hogy bezzeg a kollégám meg tudta oldani máshogyan. Na, ez a szakma kellemetlen része. Elmagyarázni az ügyfélnek a szakmai finomságokat, úgy, hogy közben a mundér becsületét is megvédjük. Végül azért sikerült tisztáznom, hogy a múltkori az egy gyors, ideiglenes megoldás volt, én viszont már a végleges megoldáson dolgozom.
Ha ezzel megvagyunk, akkor jön a move-storagegrouppath parancs, valahogy így:

move-StorageGroupPath -Identity ‘adatbázis‘ -LogFolderPath ‘ujlogkonyvtar‘ -SystemFolderPath ‘ujsystemkonyvtar‘ -configurationonly

Vagy hogy érthetőbb legyen, konkrét példával:

move-StorageGroupPath -Identity ‘server\vad-adatbazis’ -LogFolderPath ‘Z:\exchsrvr\log’ -SystemFolderPath ‘Z:\exchsrvr\log’ -configurationonly

Határozottan felhívom a figyelmet a configurationonly paraméterre! CCR környezetben a logkönyvtárt ugyanis nem lehet csak úgy átrakni. A parancs hatására a következők történnek:

  • Az AD konfigurációs névterében az érintett storage group tulajdonságainál átíródnak a log, illetve system könyvtárak útvonalai.
  • Emellett az új könyvtár (z:\exchsrvr\log) meg lesz osztva, méghozzá egy GUID névvel. Ha visszanézzük, akkor ez a GUID a storage group azonosítója. A megfelelő jogosultságokat szintén beállítja a parancs.

Végül ha ezen túlvagyunk, akkor manuálisan átmásoljuk a lecsatolt adatbázis log és system fájljait a régi helyről az újra, majd felmountoljuk az adatbázist. Ha nem rontottunk semmit el, akkor el is indul.
Látjuk, az időbeli bizonytalanságot a logfájlok másolása jelenti. Viszont amíg a másolás folyik, addig szét is tud replikálódni a címtárban a változás.

Ezzel a sürgős résszel meg is volnánk, jöhet a kötözgetés.

A biztonság kedvéért ráküldtem én is egy reseedet. Hátha apucitól jobban elfogadja. De semmi. Vágjunk mélyebbre. Újraindítottam a passzív node-on a replikációs szolgáltatást.
És végre történt valami. A replikáció státusza elmozdult az egészséges állapotból. Initializing. A végtelenségig. Vártam rá egy kicsit, aztán eluntam. Ennél még a kamu egészséges visszajelzés is jobb volt. Újabb reseed.

Jobb híján nézelődtem, gondolkodtam. A log könyvtár átmozgatása rendberakta az SCR-t, tökéletesen működik. Azért ez is valami: van egy aktív CCR node-om és egy passzív SCR node-om.
Aztán egy kellemetlen gondolat. Eddig azt mondtam, hogy a logfájlok másolása sértett meg valami ismeretlen dolgot az Exchange rejtett mélységeinek szövetében. De akkor a public folder adatbázisok logshipping folyamatának sem kellene működnie. Aztán mégis működik.
Hjaj. De bonyolult az élet.

Get-storagegroupcopystatus. Mindenki healthy. Egészségükre. Aztán hoppá. A CopyQueueLength értéke a vad adatbázisnál 14234. Mit ír erről a manuál? Azt, hogy ha az értéke nagyobb 3-nál, akkor baj van. Hmm. Ide azért most nem kell fejszámolóművész, itt baj van.

Test-replicationhealth. Minden passed – kivéve a vad adatbázis copy queue értéke. Az viszont nagyon nem.

További nézegetés. Hoppá. Nincs a passzív node-on edb.chk. Ezt azért volt nehéz észrevenni, mert abszolút nincs semmi más sem a könyvtárban. Ez azért magyarázza, miért nem ment le a mentés. (Akinek újdonság lenne: az Exchange az edb.chk fájlba írja, melyik lognál indult a mentés, azaz a mentés után meddig kell törölni a logokat.) Lehetséges, hogy nem csak a backup használja ezt, hanem a log replikáció is? Nagyon lehet, hiszen egy normális reseed úgy indul, hogy törli az edb.chk-t és az adatbázist.
Akkor lehet, hogy nem is jó a látszólag jó reseed?

Mint az ínyenc, aki a legfinomabb falatokat a végére hagyja, én is elővettem végül az event logot. Volt is benne érdekesség.

Nagyítás

Ez legalább világos beszéd, végre. Habár az eseutil /mh szerint nem hiányzik neki logfájl, de az eventlog szerint mégis hiányzik a 84679-es számú. (Azért ezen ne lepődjünk meg. Az eseutil csak az adatbázis épségével foglalkozik – és az adatbázisok tökéletesen jók. Itt a logshipping szakadt össze, de ahhoz az eseutil meg nem ért.) Természetesen ilyen nevű logfájl nincsen. De ennyi szívás után az ember már csak legyint és átszámol hexába: 14AC7. Ilyen nevű log már lehet. De hol? Hát például a kolléga által félrementett logok között, melyeket szerencsére nem töröltünk.
Mi lenne, ha bemásolnám az aktív node logkönyvtárába?
Bemásoltam. Egy perc focilabda rugdosás (az új irodámban nincs darts tábla) – és ott van a log a passzív node-on is. Vérszem. Az az, amit kaptam. Bemásoltam a sorban következő 10 logot az aktív node-ra. Egy percen belül megjelentek a passzív node-on is. Ujjé. Elkezdtem név alapján bogarászni az éles log könyvtárat és a mentett logok könyvtárát. Úgy tűnik, hogy az egyik a zsák, a másik meg a foltja. Ha a félremásolt logokat átmásolnám az éles logkönyvtárba, akkor zárt lenne a sor.

Persze ehhez több hely kell.

Újabb telefon az ügyfélnek. Leállnánk pár percre, ugye nem baj? Ügyfél füle egy kicsit rángatózik.

Átmásoltam a logokat egy nagyobb partícióra. (Igen, ez már adatbázispartíció volt. De csak a mentésig lesznek itt a logok, addig meg kibírják.)

Utána pedig megtörtént a nagy családegyesítés. Elvonultam gyakorolni a külső csavarást a nyomtató asztalának lábai közé. 20 perc műlva néztem vissza – és a logok szorgalmasan másolódtak át a passzív node-ra. Remek.

Legyen teljes a győzelem: újabb get-storagegroupcopystatus. A CopyQueueLength értéke szépen le is csökkent… de miaf… elkezdett növekedni a ReplayQueueLength értéke. Ugyan – hessegettem el a kellemetlen gondolatot – ez most kapott hirtelen 14000 logot, persze, hogy nem tudja ilyen tempóban rájátszani. Hagyjuk békén, holnap reggel majd meglátjuk, mi lesz a vége.

Eljött a holnap reggel. A győzelem érzésével gépeltem be a jó öreg get-storagegroupcopystaus parancsot – és a ReplayQueueLength értéke 500 körül volt. Az első gondolatom rögtön az volt: miért? A nullát el tudtam volna fogadni. A 14000 körüli értéket szintén. De miért pont 500?
A magyarázat gyorsan jött. Konzol, gyors vizuális pásztázás: a vad adatbázisnál a logshipping státusza failed. Aha. 500-nál besokkalt, aztán azóta coki.

Hát. Tulajdonképpen előrébb vagyunk. De a beteg még mindig kómában fekszik.

Most már nem álltam neki ködöt rágni, mentem egyből az eventlogba.

Nagyítás

Nagyítás

Keressünk rá a hibakódra. Azt írja, hogy a 1216 azt jelenti, hiányzik néhány tranzakciós log. Kérdezzem le az eseutil /mh paranccsal, mely logok hiányoznak. Lekérdeztem. Semmilyen log sem hiányzik.

Bakker. Mégis köd. Azért ez már kezd bizarrá válni: egyfelől azt mondja, hiányzik neki x darab log, ahhoz, hogy rájátssza végre az összes logot arra az adatbázisra, amelyikre már jó egy hete rá van játszva az összes log – másfelől pedig konkrét kérdésre azt mondja, hogy nem is hiányzik neki egy log sem.
Csak éppen nem indul el a rájátszás.

Ekkor már teli csőrrel gyakoroltam a védhetetlen bombákat a szerverszoba ajtajára.

Végül visszadaráltam az elejére. Emberek, végülis… már van edb.chk fájlunk a passzív node-on. Ez jó hír.
Töröljük gyorsan le. Azaz küldjünk rá egy reseed-et. Mert mi van, ha az a baj, hogy az adatbázis – amelyikre már rá van játszva minden log – nincs szinkronban a logkönyvtárban lévő edb.chk-val, mely még csak nemrég jött létre, a replikáció befejeztével. A reseed ugyanis törli mindkettőt, majd újra létrehozza, immár szinkronban.

És tényleg.

A ReplayQueueLength értéke egyből lenullázódott, a logshipping meggyógyult. A pezsgőbontással vártam még tíz percet, mert ez a nyomorult replikáció képes megint elromlani – de nem.

Tanulság:

  • Amíg elő nem varázsolom valahonnan a hiányzó logokat, addig felesleges a reseed. Nincs értelme. Nincs edb.chk.
  • Ha megvannak a logfájlok, akkor vissza kell másolni az aktívra, a logshipping beindul, legyártódik az edb.chk. Ekkor viszont kötelező a reseed, mert ez hozza összhangba a két node-ot.

Végül egy kényelmetlen gondolat:

És akkor mi van, ha közben töröltem a logokat?
Nos, végső esetben az SCR-en ott kellett lenniük.
De mi van, ha onnan is töröltük? Gáz.
Szóval óvatosan azzal a közvetlen logpiszkálással.

ps.
Elkiabáltam. Utólag derült ki, hogy az SCR node-on sem megy a rájátszás, ott is újra kellett seedelni az adatbázist és a logokat.

Suta konzol visszalő

2009-11-01 / / 0 Comments

Ez az utolsó sajtcetli – és ez most tényleg az.

Ha már annyira leírtam a menedzsment konzolt, hadd említsek meg róla egy pozitív dolgot is. Tudtátok, hogy a 2010-es EMC-be már több Exchange organizációt is fel tudunk venni? (Feltéve persze, hogy megvan hozzá a jogosultságunk és fizikailag is elérjük a szervereket.)
Ez persze eddig még nem egy nagy kunszt.

Bravúrszám akkor lesz belőle, amikor kiderül, hogy az így bekonnektált organizációk között grafikusan tudunk postafiókokat mozgatni.

Nem részletezem. Tessék végigondolni.