Van egy ügyfelünk és van nála egy régóta elhúzódó probléma.
Az Exchange organizácójuk nem túl bonyolult, a lentebbi módon néz ki.

Nagyítás

Azaz két administrative/routing group, jelezve, hogy ez valamikor két cég volt, külön IT szervezettel. Mindkét RG-nek saját Internet kijárata van. Mindkét smarthoston X-re végződő operációs rendszer fut. Ami még fontos a történet szempontjából, hogy ‘A’ cég rendszergazdája valamivel paranoiásabb, mint ‘B’ cégé… azaz a smarthoston nem engedi át azokat a kifelé menő leveleket, melyeknek feladója @a.ceg.hu. ‘B’ rendszergazda ellenben mindenkit kienged.
Az elvárt működés az lenne, hogy mindenki a saját kijáratát használja. Ezzel szemben, amennyiben felvesszük ‘A’ cég SMTP konnektorába a * névteret, minden levél – tehát a ‘B’-ben feladottak is – ‘A’ kijáratán mennek ki. Ahol a smarthost el is meszeli a nem oda valókat. Emiatt most gyakorlatilag ‘A’ konnektor le van zárva, mindenki ‘B’-n keresztül levelez.
A cégnél az email meglehetősen kritikus, tehát idő sem nagyon van kísérletezni, meg hibázni sem nagyon lehet.

Kollégám egy évvel ezelőtt kapott egy éjszakát, reggelig sportolt a rendszeren, de nem jutott előbbre. Amint hozzányúlt, felvette a * névteret, megindultak vissza ‘A’ smarthostjáról az NDR-ek, lett is egyből sírás-rívás, árvák könnyeinek potyogása.
Én múlt héten kezdtem el foglalkozni az esettel, péntek délután volt lehetőségem megpiszkálni a rendszert.
Első körben – még hétközben – felvettem mindkét konnektorra egy senki más által nem használt névteret, ahol nekem van egy eldugott postafiókom. (Nem írkálom ki egyenként, de minden smtp névtérhez 1-es súly tartozik.) Ez délután volt, szépen hagytam, hagy terjedjen el az infó a Link State Táblában (LST). Másnap reggel teszteltem, mindkét szerverről küldtem egy levelet magamnak, gyönyörűen a megfelelő kijáraton ment ki mindegyik. Nem lesz itt semmi probléma – nyugodtam meg – akár munkaidőben is át lehetne állítani.
Azért csak megvártam a péntek délutánt. Beírtam a * névteret ‘A’ konnektorába, újraindítottam a Routing Engine Service-t (RES) és az SMTP szolgáltatást, megvártam, amíg az LST frissül, mindenhonnan küldtem egy tesztlevelet – és csak az ‘A’-ból feladott érkezett meg. Jeges rémület szorította össze a szívemet, gondolatban elnézést kértem a kollégámtól, hogy ennyire amatőrnek néztem – és megpróbáltam összekapni magam, hogy megbírkózzak az ismeretlennel. Első körben gyorsan visszaállítottam a kiindulási állapotot, nehogy elvesszenek a levelek. Mondhatnád, hogy mit vacakolok, az smtp konnektoron be lehet állítani, hogy milyen csoportok küldhetnek levelet rajta keresztül, egyszerűen fel kell venni, hogy ‘A’ konnektoron ‘B’ userek ne küldhessenek – és már kész is, lehet menni a pénztárhoz felmarkolni a zsét. Ugyanerre vezetne, ha mindkét konnektoron csak a saját RG-jére érvényesen definiálnám a névtereket. El is raktároztam ezeket a megoldásokat, végső esetben jók lesznek – de itt elsősorban a ‘miért’-et kell megtalálnom és tisztességes megoldást összerakni. A workaround-dal mindig az a baj, hogy nem ismerjük, mi váltja ki, nem tudjuk, milyen más rendellenéséget okozhat. Nehéz így felelősen rendszert üzemeltetni.

Szóval jöhetett a kísérletezgetés. Első körben lecsekkoltam minden elemet. (Az organizáció messze nem ilyen egyszerű, mint amit rajzoltam. Az csak a lényegi vázlat.) Aztán elkezdtem rugdosni a rendszert. (Igen, így identifikálunk: belerúgunk a rendszerbe és lessük, mekkorát sikít.) Nos, láttam olyan csodákat, hogy szemem-szám elállt. A legdurvább az volt, hogy felvettem jó magasra (10) az RG konnektoron a súlyokat, RES újraindít, tesztlevél. És igen, megjött mindkét feladótól! Boldogan csaptam a levegőbe, majd a biztonság kedvéért megnéztem mindkét levél fejlécét. Elég sokáig néztem, egyre üvegesebb szemekkel… majd szóltam Janinak, hogy jöjjön ide, mert ilyesmit még ő sem látott. A ‘B’ szerveren lévő postafiókból a levél az 1-es súlyú út helyett átment a 10-es súlyú RGC-n, majd az ottani 1-es súlyú SMTP konnektor helyett visszament B szerverre – újabb 10-es súly -, végül most már kiment a ‘B’ SMTP konnektoron; azaz mindösszesen összeszedett 21 egységnyi súlyt, az 1 egység helyett. A sportember.

Ha azt mondom, hogy tanácstalan voltam, akkor meglehetősen enyhén fejeztem ki magam. Először is elmentem darts-ot dobálni pár percig. Ránézésre nyugodtnak látszódtam, a figyelmes szemlélőnek legfeljebb az tűnhetett fel, hogy a tábla mellé dobott nyilak is beleálltak a falba. Pedig műanyag hegyűek.

Végül érdekes módját választottam a monitorozásnak. Beírtam újból a * névteret ‘A’ konnektorába, újraindítottam a szolgáltatásokat, mindeközben egy perces auto frissítésre állítottam a Winroute-ot – és fel-alá szkrolloztam a képernyőn, hátha elkapok valahol valami érdekeset. És úgy döntöttem, hogy nem leszek gyáva nyúl, teszek rá, hogy NDR-ek jönnek vissza.
Nos, igen, végül csak elkaptam valamit.
A következő sorozatot láttam:

  • Körülbelül két perc telt el, amíg ‘A’ SMTP konnektora state up állapotba jutott.
  • Körülbelül öt perc telt el, mire az LST frissült.
  • Majdnem tíz percbe telt, mire ‘B’ SMTP konnektora state up állapotba került.

Itt van minden. A magyarázat is, és a megoldás is.
Látható, hogy van egy olyan kritikus öt perc, amikor az organizáció már észleli, hogy két konnektoron is rajta van a * névtér, de a ‘B’ konnektor még nem él. Tehát ebben az öt percben az ‘A’ felé küldi a leveleket. Egyéni balszerencse, hogy mind a kollégám, mind én ebben az öt percben teszteltünk, majd a sikertelen teszt után pánikszerűen álltunk vissza az eredeti állapotra.
Nézzük meg az egyes eseteket:

  • Amikor a teszt névteret vettem fel, nem siettem. Délután beírtam, elmentem haza, reggelig volt ideje elterjedni a változásnak. Azaz nem indítottam újra a szolgáltatásokat, nem került egyik konnektor sem state down állapotba. Persze, hogy ment minden rendben.
  • Na, azzal a súlyemelővel még a hiba gyökerének ismeretében sem igen tudok mit kezdeni. Valószínűleg pont úgy küldtem meg a tesztlevelet, hogy ‘B’ kijárata még éppen nem élt, ezért átment ‘A’-ra, aztán ott valahogy észrevette, hogy időközben életre kelt a ‘B’ SMTP konnektor – és visszament afelé. Elég perverz – és nem is igazán értem, mert nem logikus.

Gyors teszt, immáron jócskán kivárva – és minden levél a saját kijáratán ment ki.
A feladat megoldva.

Aki velem együtt dőlt hátra a székében, elégedetten csettintve, hogy ez egy korrekt lezárása volt az esetnek – igen nagyot tévedett. Ez a megoldás ugyanis – dacára annak, hogy működik – életveszélyes.
Gondolkodjunk el a következő eseteken:

  • ‘B’ rendszergazda újraindítja az Exchange szerverét.
  • Vagy elég csak a Routing Engine Service-t újraindítania.
  • Ledől a ‘B’ smarthost. Oké, tudom, hogy Unix, de a kalapács ellen azok sem rendelkeznek erős védelemmel.

Mindegyik esetben hosszabb-rövidebb ideig az organizáció azt fogja látni, hogy csak ‘A’ konnektor él – és mivel nem tud róla, hogy azon az úton leselkedik Szkülla és Karübdisz – így arra küldi az összes levelet. Azaz nem az történik, hogy ‘B’ konnektor felállásáig a levelek egy kényelmes queue-ban várakoznának – nem, ehelyett egy gusztustalan NDR-rel pattannak vissza.
Szépen végiggondolva a szituációt, visszaállítottam az eredeti állapotot, leírtam, mit tapasztaltam – majd az egészet bedobtam az ‘It needs business decision’ dossziéba.
Amíg ‘A’ rendszergazda nem enged ki minden levelet, addig jobb, ha az a konnektor nem is működik.