Dotaz: Migrace multihostingu na novou IP, jak na IP relay?

[krishna23]

Zdravím,

Mám LAMP webserver s mailserverem v jednom. Brzo mě čeká stěhování do jiného datacentra, bohužel se mi ale nepodaří změnit všechny DNS záznamy najednou (protože většina z nich ani není v mé správě), tak bych se chtěl zeptat, jak v takovémhle případě vyřešit IP relay ze staré IP na novou?

Napadlo mě, udělat mezi starým a novým serverem VPN a na staré IP nastavit NAT s maškarádou přes iptables.

Dal by se podobný relay nastavit například i s použitím Mikrotiku? Vyjde mě levněji nechat v původním datacentru 1U mikrotik, než 2U server s 2x750W zdrojem.

Je případně nějaké další pohodlnější řešení?

Děkuji za rady

Odpovědi

[NN]

Co resis za zbytecnosti. V nove lokalite zalozis server a pak to jen preklopis. Pokud nemas DNS ve sprave, je problem se domluvit, ze se to cele v konkretni den presmeruje?

[krishna23]

No na původním serveru je asi 600 domén, zhruba u dvou třetin z nich nemám přístup k administraci DNS a potřeboval bych překlopit komplet traffic na novou lokaci, aby mi pak nechyběly data na novém serveru.

[Filip Jirsák]

V původní lokalitě stačí jen NAT (DNAT + SNAT), VPN není potřeba. Mikrotik na to svými schopnostmi stačí, záleží ale na tom, o jak velký jde traffic a zda to zvládne uNATovat.

To máte všechny ty domény směrované přímo na IP adresu? Na tomhle příkladu je vidět, proč je lepší mít www jako CNAME na jméno serveru. V DNS byste změnil jenom tu jednu adresu serveru, a v původním umístění by stačilo ponechat jednoduchý webserver, který by varianty bez www přesměrovával na www (což by byl mnohem menší traffic, než přeposílání celého webu).

[Lachmex]

Castecne souhlasim s tim, co je popsano vyse - zejmena s ohledem na TTL u domen atd ... - a jeste bych mozna dodal (coz Vas mozna napadlo pod pojmem VPN) a to udelat EoIP tunnel mezi dvema DC (v podstate obdoba toho, co jste popsal ve Vasem dotazu)

Je urcite dulezite se zamyslet nad tim, jaky typ/radu mikrotiku pouzijete, ale v zasade, reseni by to pro Vas mohlo byt (a asi i nejmene bolestive/komplikovane).

Osobne jsem tuto 'necistou' cestu pred casem nedobrovolne nasledoval - 27 serveru, stare DC / nove DC a problem s postupnym preklopenim na nova IP (komplikace byla v 'nedostatku casu' pro update FW ze strany IT klientu). Toto reseni sice je z meho pohledu bastl, nicmene, ukazalo se jako funkcni a svuj ucel splnilo. Pokud je EoIP spravne nakonfigurovano a sestaveno, vse by melo bezet aniz by to zakaznik 'poznal'. Ale opakuji, neni to 'koser' a sam se za to stydim :D ....

tedy, z meho pohledu - pokud nemate jine volby a chcete jit cestou tohoto reseni, tak bych spise nezli VPN (a NATu) sel cestou EoIP ....

(jen doufam, ze za tento nazor budu nalezite kritizovan :D :D :D )

[Michal Kubeček]

To EoIP vypadá na nějaký Mikrotik-only protokol, dnes už bych asi spíš doporučil vxlan.

[pavlix]

Rozhodně to není zbytečnost, jak píše NN, naopak umět rozběhat plynule služby na jiném hardware a až následně řešit DNS je super věc. Ale bohatě na to stačí kombinace MARK, DNAT a SNAT. Přidají se do firewallu tři pravidla. Jedno paket označí, druhé přepíše cílovou adresu na nový stroj, třetí přepíše zdrojovou adresu na starý stroj. Se zbytkem si poradí connection tracking.

[Vantomas]

U řešení s NAT je důležité podotknout, že z pohledu webového serveru na novém IP se ztratí zdrojová adresa odkud návštěvník přišel a všichni vystupují pod IP toho NATovátka uprostřed. V případě, že by se tam neudělal SNAT, tak nastane situace, že webový server bude odpovědi na požadavky posílat rovnou na IP adresy klientů a zde dojde ke zmatení, protože zdrojový počítač nezná žádná taková spojení.

Osobně bych to přesně řešil přes EOIP tunel, kdy by webový server v novém DC měl dvě IP adresy a to jednu novou a poté ještě jednu tu starou, která by tam byla dopravena právě tím L2 tunelem. Systém na serveru se pak sám postará o to, že podle toho na jakou IP přišel požadavek volí odchozí IP adresu do paketů a k žádnému zmatení by nedocházelo. Řešit na Mikrotiku nějakou "vyšší" VPN než ten eoip tunel nemá smysl, nezvládá to výkonově a taky ty implementace těch protokolů tam moc neoslňují co se rychlosti týče.