Amikor a logika már szaltózik bukfenc helyett

Hihetetlenül ráérek, így leírok egy másik esetet is a korábban említett átállásból.
Exchange5.5 rendszert upgradeltünk 2003-ra egyik ügyfelünknél. Az SMTP konnektor (illetve a korábbi Internet Mail Service – IMS) nem közvetlenül kapcsolódik az internetre, hanem egy Symantec SMTP gateway ( a továbbiakban SSGW) vállalja magára az ezzel járó fáradalmakat. Azaz a részfeladat: van egy – egyébként korrekten működő – 5.5 IMS, melyet ki akarunk lökni a smarthost elől és egy 2003 SMTP konnektort (továbbiakban SC-t) tennénk a helyére.
Szépen felhúztuk az új szervert, első körben ráállítottuk a bejövő forgalmat, feltettük az Archive sinket, leszkripteltük a mailarchív biztonságos helyre mentését – remekül működik. (Illetve elsőre nem, de ez majd egy másik cikk lesz.) Jöhet a kifelé menő levelezés átállítása: névtér átír, forgalom átmegy – és bedugul. Miaf…?
Gyors ellenőrzés: mailbox server: queue üres; SC: queue tele; SSGW: queue üres. Tesztlevelek 10-200 perc között érkeznek meg és az SC queue folyamatosan dagad.
Ki a bűnös? Valszeg az SSGW, az szokott ilyesmiket csinálni. Konstans javítási mód: újraindítjuk. Semmi. Visszaállítjuk az e-mail routolást, az IMS 5 perc alatt kiszórja a leveleket. Most ki a bűnös? Talán az új SC?
Ilyenkor az első ötlet természetesen a névfeloldás átnézése: DNS, WINS, TCP/IP beállítások, route tábla, napfolttevékenység. Minden rendben.
Jó, akkor tartsuk be a Microsoft ajánlásokat.
Pontosabban a nem-ajánlásokat. Leinstalláljuk az Archive sinket (csak diagnosztikai célokra javasolják) és megszüntetjük a kifelé menő levelek feladó szerinti szűrését (egyáltalán nem ajánlják). Semmi változás.
Nézzük telnettel. Az SC-ről rámegyek az SSGW-re, a mail from beadása után elmegy vadászni és kb 1 perc után szól vissza, hogy sender ok. Tehát mégis az SSGW a hibás! Ellenpróba: ugyanezt megcsinálom az IMS-ről – és itt is befigyel az 1 perc várakozás! Várjunk csak… akkor az SSGW lenne a hibás, de az IMS ezt nagy ívben letojja, míg az SC megsértődik? Dehát ez az újabb termék!
Na jó, elő a netmont. Majd az eldönti. Először megszaglásszuk a jó forgalmat. Tesztlevél elmegy, az Ethereal szépen összerakja a levélhez tartozó forgalmat. Ugyanez a lassú forgalomnál teljes káoszhoz vezet: valami akkora dzsuvát rak össze az Ethereal _1_ levélnek, hogy az őrület. Arról nem is beszélve, hogy _nyoma sincs_ a tesztlevélhez tartozó csipcsipcsókának (SYN/ACK/ACK; copyright by FótiMarci) az egész fájlban! De hát… ez fizikai képtelenség!?
Itt döntöttünk úgy, hogy szoptunk mi már eleget, szopjon most már más is -> Microsoft Premier Support.
Az első másfél hónap meglehetősen nyugodtan telt. A magyar részleg bekért párszáz mega anyagot, majd továbbpasszolta az egészet a német csoportnak. Ők újra bekértek párszáz mega adatot és elmentek gondolkodni. Sajnos olyasvalakihez került az úgy, aki nem igazán állt a helyzet magaslatán. Folyamatosan jött a hülyébbnél hülyébb ötletekkel – dobjuk ki a Symantec gateway-t, használjuk a virtuális smtp szervert az smtp konnektor helyett, meg ilyenek. Látszott, hogy fogalma sincs, mi történik a háttérben, de próbálkozott. Én meg nem győztem végezni a szemmel láthatóan vezérfonal nélküli kísérleteket. Végül levélváltásaink kezdtek túlmenni azon a határon, amit egészséges iróniának nevezünk – így egy másik mérnök vette át az ügyet.
Természetesen bekért párszáz mega anyagot. Aztán jött egy levél, amitől melléültem a széknek.
Azt írta, hogy az 5.5 IMS – erőforráspazarló módon – minden levélküldéshez külön sessiont nyitott. A 2003-ban ezt már átdolgozták, és alaphelyzetben minden session 20 levelet küld. (Ezért nem találtam a tesztlevélhez tartozó csipcsipcsókát – mert 20 levélhez tartozott 1. És ezért mutatta az Ethereal 1 levélnek a huszat.) Csakhogy. Ugye ott van az az 1 perc, amíg az SSGW ellenőrzi a mail from adatot. És addig a 20 levél nem áll össze az SSGW-n, amíg a huszadiknak is le nem ellenőrizte a feladóját. Na, ekkor küldi csak ki a köteget. Közben meg szépen torlódik az SC-n a queue.
Persze valami gubanc még ezenkívül is lehetett, mert valahogy össze kellett jönnie a mért 200 perces csúszásnak is – de a jelenség okozója a kötegelés volt, melyet az a jelentéktelennek tűnő 1 perces kivárás borított ki. Az 5.5 IMS ezzel nem foglalkozott: minden levél várt 1 percet, aztán ment tovább. Nagy ügy.
A workaround se volt akármi. Annyit beszélünk Exchange-dzsel kapcsolatban az AD-ról, meg adatbáziskezelésről, hogy az ember hajlamos elfelejteni, hogy az SMTP valahol az IIS része – tehát a működését befolyásoló paraméterek a Metabase-ben vannak(1). Nyilván nem mindegyik van kivezetve a grafikus felületre; többek között az sem, amelyik megmondja, hogy hány levelet küldjön egy sessionben.
Ha esetleg valakinek szüksége lenne rá, ezt a változót kell megkeresni: MaxBatchedMessages – és ki kell javítani az ott lévő értéket 1-re. (Vigyázat, két helyen is szerepel; és csak akkor történik változás, ha mindkét helyen átírjuk. És persze befigyel még az IIS Admin szolgáltatás obligát újraindítása.)

Ps: Természetesen ez csak a workaround. Az igazi megoldás az lesz, ha megtaláljuk, miért szuttyog annyit a feladóellenőrzés a ‘smart’ hoston.

(1) Persze ez sem teljesen igaz. Erre az első újraindításkor jöttünk rá, amikor az AD-ból visszaszinkronizálódótt a Metabase-be az a bizonyos 20-as szám. A levelezés meg ismételten fejreállt.

This entry was posted in IT.

2 thoughts on “Amikor a logika már szaltózik bukfenc helyett

Leave a Reply

Your email address will not be published. Required fields are marked *