Migrare servicii: email

În articolul anterior am vorbit despre migrarea serviciului DNS către un alt server – o operațiune care se efectuează destul de rar. Mult mai des există însă nevoia de a migra serverul de email pe un alt sistem sau de a adăuga un MX secundar.

Ca și în cazul DNS-ului, există multe cauze care pot să ducă la nevoia de a muta serviciile de mail, iar backup și restore nu pot fi o soluție la migrarea serverului de email, din cauza dinamismului datelor – este foarte simplu ca între backup și restore să sosească un email important pe sistemul vechi și există riscul ca acesta să fie pierdut – un risc pe care nu vrem să ni-l asumăm.

Există însă o caracteristică a protocolului SMTP care ne permite să trecem ușor peste această problemă: dacă un server nu răspunde, emailul este întârziat câteva ore de expeditor. Nu este cea mai frumoasă soluție, dar este posibil să se facă o migrare în felul următor:

Pasul 0: Se modifică IP-ul serverului de mail în DNS, astfel încât să îndice către sistemul nou.

Pasul 1: Se opresc serviciile email atât pe sistemul vechi cât și pe cel nou. Din acest moment nu se vor mai putea trimite sau primi email-uri.

Pasul 2: Se face un backup al sistemului vechi.

Pasul 3: Se restaurează datele pe sistemul nou.

Pasul 4: Se pornește sistemul nou. Din acest moment, serviciul email ar trebui să funcționeze fără probleme, dar, pe lângă timpul cât ambele sisteme au fost nefuncționale, vor mai exista erori datorită perioadei de caching a DNS-ului.

Astfel, este foarte probabil ca timp de câteva ore sau chiar zile, utilizatorii sau alte servere de mail să încerce să se conecteze la vechiul IP. În funcție de felul în care sunt configurate, unele din servere ar putea să reîncerce sau să abandoneze trimiterea, ceea ce ar duce la erori la expeditor și posibil, pierderea emailurilor respective. Iar utilizatorii vor fi, în mod cert, derajați că nu-și pot accesa mailurile imediat.

Iată cum, deși posibilă, această soluție nu este optimă. Ar putea funcționa pentru servere de mail cu trafic foarte mic și un server DNS al cărui timp de expirare este de câteva ore, dacă operațiunea este făcută într-un week-end în care se așteaptă foarte puțin trafic. Nu recomand această soluție decât pentru cine se plictisește în zilele de Crăciun sau anul nou

Este deci necesară o soluție care să permită celor două sisteme să funcționeze simultan până când toate schimbările se propagă pe noua mașină și în DNS, astfel încât clienții să sesizeze cât mai puțin schimbarea.

Iată pașii care trebuie urmați:

Pasul 0: Înainte de a începe migrarea, vom instala un sistem de operare pe noul server, să-i spunem mail2.exemplu.ro (iar vechiul server va fi mail.exemplu.ro), împreună cu alte aplicații care sunt necesare (de exemplu un firewall și configurarea unui sistem de backup).

Pasul 1: Instalarea și configurarea pe mail2.exemplu.ro a tuturor serviciilor care trebuie mutate. De cele mai multe ori asta înseamnă SMTP/SMTPS, POP3/POP3S și IMAP/IMAPS (mutarea serviciului webmail o voi lăsa pentru articolul următor, în care mă voi referi la migrarea serviciilor web). La încheierea acestui pas ar trebui ca serverul mail2.exemplu.ro să răspundă identic cu mail.exemplu.ro la orice cerere – să primească mailuri pentru aceleași domenii și să permită utilizatorilor accesul la ele.

Pasul 2: Se va modifica în DNS adresa IP a serverului de mail, astfel incât să indice către sistemul nou instalat: mail2.exemplu.ro.

Situația în acest punct este în felul următor: atât mail.exemplu.ro cât și mail2.exemplu.ro răspund corect la conexiunile SMTP, stocând datele local. Serviciile POP și IMAP, deși corect configurate, nu sunt complet funcționale pe mail2.exemplu.ro, pentru că acesta nu are fizic emailurile, ce se află încă pe mail.exemplu.ro.

De aceea, din acest moment suntem într-o cursă contra cronometru împotriva cache-ului DNS – pe măsură ce acesta expiră, din ce în ce mai mulți clienți vor accesa noul sistem, care trebuie să fie pregătit.

Pasul 3: Ținând cont de ce am scris mai sus, copierea emailurilor pe noul server astfel încât să fie la dispoziția serviciilor POP/IMAP este următorul pas logic. Există mai multe metode, de exemplu copierea directă a fișierelor sau utilizarea unui program de tip fetchmail. Unele servere SMTP oferă funcționalități interne care la configurarea ca smarthost “împing” automat mailurile locale către noul server.

Pasul 4: Din acest moment este de preferat ca vechiul server de mail să nu mai stocheze local emailurile primite, deci este necesar să configurăm serviciul SMTP pentru a fi smarthost pentru domeniile servite. Astfel, la primirea unui email, acesta nu va mai fi livrat local ci va fi trimis către serverul mail2.exemplu.ro. În anumite cazuri, acest pas se poate lega de pasul 3, așa cum am scris mai sus.

La încheierea pașilor 3 și 4 situația este în felul următor: serviciul SMTP a fost mutat complet către mail2.exemplu.ro, orice email nou intrat în sistem se va livra fizic doar pe mail2.exemplu.ro, indiferent care dintre servere a răspuns conexiunii. Serviciile POP/IMAP de pe mail2.exemplu.ro au acces la toate mailurile, actualizate, în timp ce serviciile care rulează pe mail.exemplu.ro “văd” o copie mai veche.

Clienții care lucrează pe o copie mai veche vor avea următoarele probleme la mutarea pe noul server: unele mailuri care au fost citite vor apărea ca necitite, mailuri șterse vor “reînvia”, iar modificările din folderele IMAP vor fi anulate.

Pasul 5: Acest pas are ca scop prevenirea problemelor de mai sus. Vom face în așa fel încât utilizatorii să lucreze cât mai puțin pe o copie veche a mailurilor personale. Vom reconfigura deci serviciile POP/IMAP de pe vechiul server astfel încât fie să acceseze noile mailuri, fie să trimită cererile către noul server, mail2.exemplu.ro. Soluții sunt multiple:

• dacă există acces la configurările clienților de mail ai utilizatorilor (de exemplu printr-un sistem de management al configurației), se poate modifica manual IP-ul serviciilor POP/IMAP. Funcționează bine dacă este vorba doar de configurarea unui webmail, mai puțin dacă sunt implicate sute de sisteme și dispozitive mobile.
• redirectarea cererilor către porturile POP3/POP3S/IMAP/IMAPS din firewall către adresele corecte. În funcție de locația clienților (intranet, internet) și structura rețelei, această soluție poate funcționa complet, parțial sau deloc.
• exportarea către mail.exemplu.ro a sistemului de fișiere în care sunt stocate mailurile, de pe mail2.exemplu.ro, astfel încât toate serviciile, indiferent pe care din sisteme se află, să acceseze aceleași date. Poate fi extrem de riscant și trebuie testată soluția foarte bine înainte de implementare!
• oprirea serviciilor POP/IMAP de pe vechiul server mail.exemplu.ro și instalarea în locul lor a unor proxy-uri care să se conecteze la serverul “real” – mail2.exemplu.ro. Este soluția cea mai elegantă și o recomand.

Pasul 6: La încheierea pasului anterior, mail2.exemplu.ro ar trebui să aibă toate datele actualizate și să poată răspunde corect tuturor cererilor, iar vechiul mail.exemplu.ro doar să trimită către mail2 cererile pe care (încă) le mai primește. Pasul 6 constă în monitorizarea vechiului server, care pe măsură ce modificările în DNS se propagă, va primi din ce în ce mai puține cereri. Dacă au trecut cel puțin 12 ore (de preferat 24), de când nu s-au mai primit cereri, se poate considera migrarea încheiată și sistemul mail.exemplu.ro se poate opri sau configura ca MX secundar.

În acest ultim caz, se dezactivează serviciile care nu mai sunt necesre (POP/IMAP), se șterg mailurile stocate local și se configurează serviciul SMTP pentru a fi smarhost și a trimite mailurile către MX-ul principal. În DNS, înregistrarea MX va primi o prioritate mai mică decât a MX-ului principal.

Dacă pașii de mai sus au fost executați corect, rapid și în intervale în care utilizatorii nu prea își verifică mailurile (de exemplu în week-end sau noaptea), ar trebui ca migrarea să fi decurs fără probleme și, cel mai important, fără a fi sesizată.

Tu ai migrat servicii de mail? Ce metodă ai adoptat? Lasă un comentariu mai jos!

Dacă ai nevoie de ajutor pentru a migra servicii de pe un sistem pe altul, NOVIT te poate ajuta! Contactează-ne!

Image credit: Koshyk.

Related posts:

1. Migrare servicii: website și alte servicii web Iată că am ajuns și la ultimul episod din seria...
2. Migrare servicii: DNS În ultimele trei post-uri din categoria IT m-am referit la...
3. Email sau nu e mail? Dacă săptămâna trecută am vorbit despre importanța de a avea...
4. Email Oops, nu am scris conținut pentru pagina asta, deocamdată. Revino...
5. Recomandare echipamente și servicii Oops, nu am scris conținut pentru pagina asta, deocamdată. Revino...