Dve konektivity a load balancing (diskuse)

[Filip Jirsák]

Určitě musíte rozdělovat spojení, jemnější dělení pro vás pravděpodobně nemá smysl. Podle prvního paketu spojení se určí odchozí IP adresa, na kterou pak protějšek odpovídá – tím je určeno, kterým spojením se k vám budou vracet odpovědi (a po navázání spojení už nelze IP adresu zdroje měnit). Můžete sice odchozí pakety již navázaného spojení poslat přes druhého ISP, ale vracet se vám budou stále přes toho prvního – a zpravidla je silnější download, takže upload balancovat nemusíte. A na začátku spojení asi nedokážete určit, jak velký v něm bude provoz, takže asi nezbývá jiná varianta, než nějak určit, kterým spojem má jít následující spojení, a spoléhat se na to, že se celkové vytížení obou spojů bude pohybovat někde okolo požadovaných hodnot.

[maertien]

Bohuzel potrebuju per-packet rozdelovani. Na ta spojeni je to sice hezke, ale neni spojeni jako spojeni a muze dochazet k ruznym nechtenym stavum...

[Filip Jirsák]

V tom případě musíte svést konektivitu od poskytovatelů i na druhém konci do jednoho bodu (nějaké peeringové centrum nebo něco, kam mají oba vaši ISP dotažené „dráty“, a kam si dáte vlastní router), veškerá vaše spojení budou (pokud se dívám „z internetu“) jakoby zakončena v tomto bodě (budou mít jeho IP adresu) a teprve tam uděláte DNAT a paket pošlete vybraným spojením. Od ISP budete kupovat jen okruhy k tomuto bodu. Na celou akci bych počítal rozpočet v desítkách až stovkách tisíc.

A nebo si rozmyslete, zda opravdu potřebujete rozdělování po paketech i na downloadu. Protože neexistuje jiné řešení, než to, které jsem popsal v předchozím odstavci. Když váš klient naváže TCP/IP spojení přes ISP1, navazuje jej z IP adresy A. Počítač někde na druhém konci světa mu odpoví a pošle paket na adresu A a do sítě ISP1 – nemůže nijak vědět, že kdyby paket poslal na nějakou jinou adresu B skrze síť ISP2, paket nakonec dorazí k původnímu klientovi. A změnit IP adresu během spojení také nemůžete, protože TCP/IP spojení je určeno dvojicí IP adres a dvojicí portů. U jiných druhů komunikace (třeba UDP) je to podobné – UDP paket většinou přijde jako odpověď na nějaký požadavek, a přijde na stejnou IP adresu, ze které šel požadavek. A i kdyby UDP paket přišel „sám od sebe“, našel si jeho odesílatel vaši IP adresu třeba v DNS – pak můžete něco ovlivnit nastavením DNS, ale nedokážete udělat tak jemné rozlišení, abyste udělal load balancing po paketech. Jediná možnost jak udělat load balancing po paketech pro download je dostat se k paketům někde mezi „internetem“ a sítěmi vašich ISP.

[maertien]

Dekuji za reakci. Se strojem venku se pocita.

[Filip Jirsák]

Pak záleží na tom, jak moc to chcete mít spolehlivé. Levnější varianta mít počítač u nějakého běžného ISP nebo třeba v housingovém centru a dělat NAT tam, pak ale kapacita vaší konektivity bude záviset na tom, kolik vám dovolí tento ISP. A nebo dražší varianta (v řádech, které jsem napsal výš) pronajmout si rack někde třeba v Sitelu, od vašich stávajících ISP mít jenom okruh a v místě s NATujícím počítačem si nasmlouvat konektivitu klidně od třetího ISP nebo od několika ISP.

[petr_p]

V tom případě potřebujete vlastní autonomní systém a dynamické směrovaní.

[cezz]

No ja som videl riesenie pomocou servera niekde v hostingu. (s dobrou konektivitou) Data sa vlastne posielali dvoma nezavislymi spojmi s tym, ze server robil nasledne SNAT smerom do internetu (aspon tak som to zbezne pochopil) Ale co viem, nebol to ziaden zazrak..

Mne este napada jedno podobne riesenie - spojit tie dva tunely bondingom, ale neviem do akej miery je to vhodne riesenie.

http://blackhole.sk/topicm-vychytavky-loadbalancing - to je to prve riesenie, ale pripada mi zbytocne komplikovane.

[maertien]

Diky za hint, to vypada celkem nadejne. Reseni pres stroj venku mne take napadlo.

[maertien]

Dekuji vsem prispevatelum za jejich reakce.

[Dušan Hokův]

proc se posledni dobou dotazy objevuji v blogu a ne v poradne?

[cezz]

Teraz som aj celkom rad, v poradni by som to prehliadol..

[onion]

Protoze z poradny se casto ledacos vyhazovalo s tim, ze to tam nepatri a netyka se to dostatecne Linuxu. A nez spekulovat nad tim, jestli zrovna muj dotaz nebude na obtiz v poradne a riskovat jeho smazani, je snazsi dotaz umistit do blogu.