Archívum

Posts Tagged ‘scoped send connector’

Send connector gondolatok

március 28, 2019 2 hozzászólás

Bár mostanában kicsit el vagyok havazva néhány nagyobb migrációval, egy-két apró segítségkérés megoldását próbálom beszorítani az időmbe.

Egyik helyen kértek, hogy nézzem át a levelezés beállításait, ugyanis egy redundánsra elképzelt környezetben pont a redundancia hiányzott – konkrétan sem a levélküldés, sem a levélfogadás nem működött, külső partnerek irányába. A DAG működött, tehát a kliensek tudtak csatlakozni a postafiókhoz, belső levélküldés rendben volt, de szerették volna, ha valóban magas rendelkezésre állást alakítunk ki.

A fogadás témakörét néhány alapbeállítás hiánya (másodlagos MX, tűzfal-beállítás) kimerítette, a küldésnél viszont akár ennek, de leginkább ennek a cikknek az olvasása hiányzott. Létezett ugyan két Send connector, mindegyiknél a “Source” szervereknél ki volt töltve az elképzelt konfiguráció alapján – ettől függetlenül, amikor az elsődleges kiszolgálót leállítottuk, a küldés továbbra is az “ő” küldési csatlakozóján akart kimenni. Természetesen a kiszolgáló leállított állapotában az sem tud küldeni, így a levelek csak gyűltek – az ügyfél és a kollégák pedig értetlenkedtek.

A megoldást többféle módon próbálták megtalálni, ezekből szemezek.

Egyrészt, minden csatlakozón kipróbálták a “Scoped send connector” bekapcsolását. Nos, ez valóban az egyik helyes megoldás, bizonyos feltételekkel: amennyiben a tartományban ki vannak alakítva telephelyek, megfelelő ip-címtartománnyal, s a levelező-kiszolgálók különböző telephelyek tagjai. Ebben az esetben ugyanis csak a saját telephely (és a “Scope” által nem védett) küldési csatlakozóit látja a kiszolgáló, nem fogja használni a “másik” csatlakozóját. Jelen esetben nem volt telephelyes kialakítás, így ennek a pipának a ki/be kapcsolt állapota semmit nem jelentett.

A másik próbálkozás a súlyozásra (költség) irányult. Nos, itt hivatkozok vissza az előbbi cikkre – ugyanis tekintettel arra, hogy a fő telephelyhez elképzelt csatlakozó költsége kisebb volt, mint a második telephelyé, mindig ő lett a kiválasztott. Az, hogy a kiszolgáló épp nem működött, nem zavarta az Exchange-t… Amint egyenlő költséget állítottunk be, a kiválasztási folyamat továbblépett, lehetővé téve a második kiszolgáló csatlakozójának használatát.

Egy másik megoldás, amit mondjuk nem próbáltak, az MX-rekordok alapján történő küldés (ez ugye akkor járható, ha nem DNS-alapú címkeresés történik, hanem smart host-nak küldik). Ekkor felvesszük minkét smart-hostot 1-1 A rekordba, majd azonos névvel, de különböző súlyozással felvesszük a két MX rekordot (egyik mutat egyik A rekordra, másik a másikra).

A megoldások sora tovább folytatódhat, de gondolatébresztőnek ennyi elég…