IPv4 a Multihoming

[PCnity]

Zdravim,

Snazim sa zvysit redundanciu nasich sluzieb, tym ze pridame dalsie geograficky oddelene data centrum (Slovensko, Nemecko). K tomuto som si uz zabezpecil registraciu za LIRa a vlastny IPv4 subnet v RIPE.

(PLS, ak pisem blbosti, upozornite ma na to, nie som ani z daleka expert v tejto oblasti)

Ak som spravne pochopil pravidla, najmensia routovatelna jednotka na internete je /24 subnet, kedze kazdy dalsi ASN zvacsuje uz teraz privelku globalnu routovaciu tabulku.

Z toho mi vyplyva, ze by sa dali vytvorit 3 ASN, potom dva /24 subnety routovat fixne cez providera A do DC A (primarne), jeden /24 fixne announcovat cez providera B v datacentre B (backup) a do tretice jeden /24 (celkovo /22 subnet) announcovat cez oboch providerov do oboch DC.

Ak to teda chapem spravne, vznikne mi problem anycastu. IP Packet pre adresu z multihomovaneho subnetu mi raz dojde do DC A a inokedy (hoc aj od toho isteho "klienta") do DC B. V zavislosti od routovacich metrik, providerov po ceste, etc.

Pre DNS OK, mam 2 rozne servre, jeden v DC A, druhy v DC B co maju tu istu public IP z multihomoveho subnetu... Raz odpovie jeden, raz druhy, no issue.

Lenze ostatne sluzby nie su taketo simple, mozu bezat len single. Sice mam tu istu VMku na zdielanom storage cez DRBD dostupnu v oboch DC, ale naraz moze bezat len v jednom DC. A tu zacina moj problem.

Ako zabezpecit, aby IP paket pre server aktivny prave v DC A, nasledne aj dorazil k tej spravnej VMke?

Moj prvotny napad je bridgovat (L2) internetovu VLANu na switchoch v oboch DC. Ak som nezabudol na nic zasadne, takto by ten problem za mna vyriesil ARP protokol, ci?

Pride nove spojenie na multihomovanu IPcku, IP packet dojde do jedneho z tych dvoch DC, router ho forwardne na interface v internetovej VLAN na switchi, pripadne pred tym este spravi ARP request ak nema zaznam v tabulke... Tento forwardnuty packet uz teda ma na urovni L2 nastavenu spravnu DST MAC a kedze switch v DC A a switch v DC B by mali zbridgeovanu Internet VLAN, samotny ethernetovy ramec by siel bud priamo k cielovej VM, alebo by putoval cez Port s L2 bridgeom do druheho switchu a odtial k cielovej VM.
Cielova VM by uz odpovedala priamo cez router v jej aktivnom data centre.

Predstavujem si to moc jednoducho? Je v tej uvahe nieco uplne vadne?

Velku vacsinu by som riesil normalnejsie, pomocou dvoch A zaznamov v DNS a nasledne load balancer/mail server/etc v kazdom DC... Avsak mame sluzby ktore toto neumoznuju, su IP based a velmi velmi velmi citlive na nedostupnost.

Dakujem za input.

[Reklama]

[j]

Pises hezky, ale moc zesiroka ... pokud tvoje sluzby neumej bezet v clusteru, tak k cemu ti to bude? Tohle mela bejt tvoje zakladni uvaha. Pokud chces provozovat bezpecnostni cluster, tak proste potrebujes, aby vse bezelo na dvou a vice mistech ... zaroven. Tzn, tvoje aplikace/sluzby to musi umet. Pokud to neumi, tak to proste nemuze fungovat.

[PCnity]

Pises hezky, ale moc zesiroka ... pokud tvoje sluzby neumej bezet v clusteru, tak k cemu ti to bude? Tohle mela bejt tvoje zakladni uvaha. Pokud chces provozovat bezpecnostni cluster, tak proste potrebujes, aby vse bezelo na dvou a vice mistech ... zaroven. Tzn, tvoje aplikace/sluzby to musi umet. Pokud to neumi, tak to proste nemuze fungovat.

Takto vyjadrenie mi nepomoze, logicky ze tam, kde to som schopny to ovplyvnit mam uz teraz infrastrukuru plne redundatnu (zatial u jedneho poskytovatela).

Lenze NIE vsetko som schopny ovplyvnit. Mam VMku, appliance ktora je selfcontained. Nastavis jej public IP a tym to konci. Nema zmysel ani riesit ze ci by pred nu nemohol ist nejaky loadbalancer, haproxy, whatever, pretoze klienti ktori s nou komunikuju, budu komunikovat proste vzdy s jedno IPv4. bodka. Nevedia inac.

A mojim cielom je zabezpecit, aby tato jedna public IPv4 bola dostupna aj kebyze cele datove centrum zhori.

Preto multihoming.

[geox]

L2 tunel sluzba pres Internet mezi ruznymi DC na provozovani serverovych sluzeb neni zrovna prilis robustni reseni.
Pro jiste spektrum sluzeb by mohl pomoci "anycast". Neni to vsak uplne trivialni ...

[PCnity]

L2 tunel sluzba pres Internet mezi ruznymi DC na provozovani serverovych sluzeb neni zrovna prilis robustni reseni.
Pro jiste spektrum sluzeb by mohl pomoci "anycast". Neni to vsak uplne trivialni ...

Ked si spomeniem na vyadkov data centier v ktorych som od 2009 spravoval nasu infrastrukturu, bud islo vsetko, alebo bolo vsetko down.
Vacsina DC sa chvali ze ma viacero tranzitnych providerov a pre mna bude tranzit v oboch DC priamo samotne DC. Cize sanca ze nejake IP pakety od klientov dorazia v poriadku, ale moj interconnect medzi data centrami by bol dole, je IMO relativne nizka.

Priepustnost ma az tak netrapi, v jednom bude 10 gbps uplink s garantovanymi 250 mbps v druhom bude gigabit a DC sa tvari ze aj pre svet. Nasa terajsia spotreba podla 95% MRTG modelu je niekde okolo 30 mbps, akurat doteraz bolo DRBD len lokalne.

Ak by som navyse mal problem s interconnectom, predpokladam ze ak na mojom routri prestanem announcovat moj multihomovany subnet, BGP tranzitu by to malo skoro instatne prebrat a teda by ani packety od klientov nemali pre ten subnet dalej chodit do toho DC a teda vsetko by malo zacat chodit do toho DC, kde by som ten subnet nadalej announcoval. (aspon takto primitivne si to predstavujem)

Neviem dojst na ziadne dobre riesenie. Ta VM appka je komunikacneho charakteru, sigle tenant, pridelena priamo jednemu klientovi a jeho vlastnym klientom. Bezia cez to rozne komunikacne protokoly, od beznych HTTP/HTTPS/SMTP/SFTP az po proprietarne protokoly ronych industrialnych zariadeni (Anycast pre SNMP by bol super, ale toho je malo). A tieto veci proste chcu komunikovat s jednou IP:Port... Odhliadajuc od toho ze tieto TCP a Sessionove veci komunikacie nemozu byt priamo anycastovane, samotna ta Appliance nepodporuje nic podobne, ma sice rezim cluster, ale len vo forme active/backup a pri vypadku si posuva service IP.

By ma zaujimalo, ako to robia DC ktore maju niekolko POPov. U jedneho providera si mozem v ramci jedneho subnetu kludne par IPciek drzat v jednej sale a par dalsich IPciek v inej sale na opacnej strane mesta... Predpokladam vsak ze je to jeden a ten isty core network... A ked mali naposledy vypadok, boli asi vsetky saly dole

[Reklama]

[wardmaster]

Ahoj,
oprav mě jestli se mýlím nebo jsem to špatně pochopil, ale píšeš že máš VM, která může v jeden okamžik běžet jen na jednom místě (řekněme v DC A) a chceš, aby i v případě výpadku celého DC A byla tato VM nadále dostupná?

Jinak ohledně toho směrování paketů internetem: BGP umí zajistit, aby se jako vstupní bod do jednoho ASN využíval jeden určitý router (tuším parametr local preference, ale nejsem si jistý), ale zajistit aby se při směrování do určitého IP rozsahu vybral určitý ASN, to nevím jestli jde.

Ohledně možnosti přeposílání do jiného DC tak ano, na hraničním routeru DC B můžeš nastavit jeho přeposlání do DC A, ale řešil bych to spíš nějakým NATem typu: když přijde daný požadavek do DC B tak jeho cílovou adresu přeložím na nějakou fixní adresu, která je routovaná jen do DC A a pošlu ho zpět do internetu, v DC A na hraničním routeru to přeložím zase zpátky.

[crown]

co pouzit nejakou vpn?

Klient se zapne a zkusi se postupne pripojit na VPN A, kdyz nejde B, ...
Obe VPN prideluji stejne vnitrni IP adresy, takze z hlediska aplikaci je to transparentni, pristupuji na stejnou (interni) IP adresu

[ewefwef]

@wardmaster
local preference sa da pouzit na presne opacny smer od teba von

@
pcnity
na ovplyvnovanie odkial pride paket z internetu k tebe mozes pouzit MED alebo AS_PATH parametre, standardne sa pouziva druhy a nazyva sa to as prepending (umelo zvysis dlzku AS_PATH a teda znevyhodnis dany prefix). toto by malo vo velkej miere stacit ale nie je to na 100%

ako si ale pisal ze nemas problem mat L2 konektivitu medzi datacentrami - moj nazor je ze toto by som urcite nerobil predoze to moze mat fatalne nasledky pre obe datacentra
zmenil by som L2 prepoj na L3 a medzi obomi datacentrami nakonfiguroval routing kde by si oznamoval specifickejsie prefixy, toto by ti zarucilo ze aj keby ti paket prisiel do zleho datacentra, specificky prefix v smerovacej tabulke by ho doviedol az k potrebnej VM a v tomto pripade by ti velmi ani nezalezalo ako oznamujes prefixy do internetu ak mas dostatocnu kapacitu na linke medzi datacentrami

[Martin]

Z toho mi vyplyva, ze by sa dali vytvorit 3 ASN, potom dva /24 subnety routovat fixne cez providera A do DC A (primarne), jeden /24 fixne announcovat cez providera B v datacentre B (backup) a do tretice jeden /24 (celkovo /22 subnet) announcovat cez oboch providerov do oboch DC.

Ak to teda chapem spravne, vznikne mi problem anycastu. IP Packet pre adresu z multihomovaneho subnetu mi raz dojde do DC A a inokedy (hoc aj od toho isteho "klienta") do DC B. V zavislosti od routovacich metrik, providerov po ceste, etc.

     Pokud máte dvě datacentra a jeden ISP vám dává Internet v obou, případně v tom třetím uvažovaném, tak jde po domluvě nastavit, že uvnitř jejich sítě můžete propagovat i hostovské IP adresy, tj.maska /32. Směrem do Internetu použije sumarizaci, takže z hlediska Internetu se to bude tvářit pořád stejně. Pokud spadne celé DC, přes BGP vašeho ISP se bude propagovat  jen to zbylé DC. Pokud budete chtít z nějakého důvodu odmigrovat službu do druhého DC, stačí v BGP začít propagovat IP té služby. Více specifická síť při routovacím procesu vyhrává, takže hostovská maska /32 přebije /24 nebo /23 posílaného do Internetu. Máme to tak někde použité.

     Ještě k popisovanému problému s multihomingem. Pokud to chápu dobře, tak máte obavu, že provoz na jednu konkrétní veřejnou IP adresu může dojít někdy do DC A, někdy do DC B. S tím principem "více specifické vyhrává" bych prefix /22 (4x třída C) rozdělil na menší, jak navrhujete, pokud u ISP projde a z každého DC propagoval jeden menší subnet a jeden celkový /22. Pokud by jakékoliv DC selhalo, tak pak převáží ta celková síť s prefixem /22 a teprve pak bude záležet na tom, odkud se bude zákazník na tu IP hlásit. Pokud bude připojený přes ISP A, tak půjde do DC s Internetem od ISP A. Pokud bude mít Internet od ISP B, tak půjde do DC s Internetem od ISP B. Mělo by jít ořetřit pomocí již zmíněného "AS path prepending". BGP se rozhoduje (kroma dalších parametrů) podle počtu autonomních systémů, které jsou po cestě. AS path prepending uměle přidá vlastní AS třeba desetkrát, takže pokud chcete jako primární DC A, tak těch 10 AS přidat na propagaci z DC B.

     Ještě by šlo použít, jak myslím taky někdo psal, přeroutování z ostatních DC, kdyby se tam z nějakého důvodu dostal nějaký paket, do toho jednoho, kde běží ta aplikace. Aplikace běží řekněme v DC A. Do ostatních DC povede nějaká MPLS VPN nebo VRF a v nich bude provoz na tu veřejnou IP posílán do DC A. Návratový provoz půjde přímo Internetem z DC A, v tomto případě nesymetrický provoz nevadí, pokud po cestě nebude třeba firewal, který by kontroloval TCP provoz a sekvenční čísla. Taky by šel využít NAT, pokud DC nejsou nijak propojena. V nesprávných DC se provede překlad zdrojové IP za IP směrované do toho místního DC, kam provoz přišel. DC A pak provoz vrátí zpět do DC, kam paket přišel nejdříve. Paket si trochu pocestuje, ale to předpokládám nevadí, asi půjde o malé objemy dat a zpoždění v desítkách ms patrně přežije.