Docker Swarm HA cluster

Virtualizáció

Sziasztok!

Docker Swarm dokumentacio alapjan letrehoztam egy load balancing teszt kornyezetet. Odaig eljutottam hogy minden node-on fut egy Nginx. Egy manager node IP alapjan ki van szolgalva az Nginx default oldala. Ott akadtam el, hogy ha egy domain DNS rekordjaba felveszem az egyik manager IP cimet es pont az fekszik meg, akkor hiaba fut a tobbi manager es worker. Olvastam mas forumokon, hogy egy domainhez fel lehet venni tobb "A" rekordot. Egyik velemeny szerint a kliens random kap egy IP-t, masik szerint ha az elso IP nem szolgal ki, akkor a soron kovetkezot probalja meg.

Ti mit gondoltok, illetve mit ajanlanatok erre a problemara?

  • 1589 megtekintés

( andrej_ v | 2017. 09. 03., v – 09:02 )

A címben HA clustert írsz, a topikban már loadbalancing teszt környezetet. Ha loadbalancing és HA kell, akkor minimum 2db loadbalance node-ra van szükséged, de igazi load és balance akkor lesz, hogy ha nodejaid terhelésének függvényében osztod a bejövő kapcsolatokat.

DNS ügyben a több A rekord round-robin működik és adott esetben működhet loadbalanceként is, de ehhez olyan jellegű szolgáltatás kell amire illik. Ha az egyik IP kiesik, akkor valóban tovább fognak menni a kliensek, de bőséges timeout után.

( Rt711 v | 2017. 09. 03., v – 11:18 )

Úgy gondolom jobban haladnál egy irányított tréninggel, és hamarabb megértenéd mire kell figyelni swarm cluster építésnél, milyen módban futnak a konténerek, hogyan kell skálázni, stb.
Erre ajánlom a Docker hivatalos doksiját, interaktív: http://training.play-with-docker.com/swarm-stack-intro/

Egy application loadbalancer megoldja hogy a lekérések a még működő apphoz jussanak. Ennek elérése érdekében fel kell venned az összes node IP-jét a loadbalancerben.

-

Koszi a valaszokat! Az megvan hogy ha kiesik egy node akkor egy masik szolgalja ki a kerest.

Vegyunk egy peldat. Van ket manager node, mindket managerhez van ket-ket worker node. A domain DNS beallitasainal beallitom A rekordba az egyik manager IP cimet. Igy mukodik a load balancing, ki is eshet barmelyik worker es az egyik manager is. De mi van ha az a manager esik ki, amelyikre ra van iranyitva a domain?

A round-robin megoldas nem szimpatikus a fent emlitett timeout miatt. Olvastam IP floatingrol is, ami egyelore nekem meg magas es nem is tudom hogy egy VPS kornyezetben van-e ra lehetoseg. Viszont mindenkeppen erdekes temanak tunik.

Osszegezve, epithetek akar milyen bonyolult cluster kornyezetet, ha a vegen a domaint egy konkret gep IP cimere kell iranyitani. Onnantol kezdve azon a gepen all, vagy bukik az egesz. Es errol semmi infot nem talaltam docker doksiban es mas docker tutorialokban sem.

Pedig annyira nem bonyolult ez. Az biztos, hogy ha az adott IP statikusan csak 1 helyen érhető el, akkor az valóban SPOF, ezért is kell lehetőség szerint az IP-t valamilyen formában mozgatni ha arra szükség van (egy sima HA solution ezt megoldja neked) - ez lesz a floating IP amivel véleményem szerint meg kéne barátkozni.
Viszont abban is igazad van, hogy ez inkább csak akkor működik, ha a cluster node-ok azonos hálózati szegmensen belül tudnak lenni (különben az egyik nem tudná a másiktól átvenni az IP címet) ergo azoknak esélyesen 1 szolgáltató egy environmentjén belül kell landolniuk (ergo hybrid cloud itt nem játszik).
Van ugyan olyan lehetőség, hogy saját DNS szervert üzemeltetve automatizáltan át lehet iratni egy DNS A rekordhoz tartozó IP-t egy teljesen más IPre (és így akkor be lehet rántani más hálózati range-ben lévő gépet is gond nélkül), de a DNS caching miatt ez még így is macerás tud lenni sok esetben ha a szolgáltatást kívülről akarják esetleg az ügyfelek elérni (viszont ugyan ez a móka már tökéletesen működik a saját environmenteden belül ha nincs másik DNS szerver, vagy ha mindent a /etc/hosts file-ban írsz át gyorsan centralizáltan)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Sokat tisztult a kep, koszonom!

Ettol tartottam, hogy mas szoftvereket fogtok ajanlani a swarm ele. Ha jol ertem, akkor kijelenthetjuk hogy a swarm (es tarsai, pl kubernetes) csak terheles elosztasra es !worker! kiesesre jo, ha domain is jelen van. Ezt nem is neveznem HA-nak, mert mi az hogy csak a workerek eshetnek ki? Nem leszolni akarom, csak megerteni. En ugy ertelmeztem hogy olyan managerek is kieshetnek, amikre nincs a domain kozvetlenul iranyitva, lasd: https://docs.docker.com/engine/swarm/images/swarm-diagram.png

Viszont ha masik szoftvert (vagy szolgaltatast) kell hasznalnom a HA funkciohoz, akkor felmerul a kerdes, hogy minek a swarm? Felteszek 5 gepre egy-egy normal kontenert, aztan majd egy masik szoftver vagy szolgaltatas elintezi hogy melyik gepre iranyitsa a klienst.

Én úgy gondolom, hogy a rövid válasz, hogy így van. A kubernetesről nem tudok nyilatkozni ilyen szempontból. Vagy valami felhős load balancer, vagy valami saját floating ips HA megoldás a swarm ELÉ, az ami neked kell, de ez egy vékony dolog, nem minősíti a swarm clustert, ha ez nem a része, no para.

Szerintem félreérted az egész swarm / container mögötti lényeget.
A swarm nem azért van, hogy HA-t biztosítson neked. Mind a Docker, mind a Kubernetes megoldás arra van kitalálva, hogy dinamikusan tudj hozzáadni / elvenni workert a "clusterből" és így tudd azt skálázni. Értsd: Ha hírtelen megnövekszik a kihasználtság, akkor simán be tudsz rúgni 1-2 új workert és hadrendbe állítani azokat, hogy így legyen valami ami ki tudja neked szolgálni a plusz worload igényt. Vica-versa: Ha esetleg a kihasználtság alacsonyan van, akkor simán meg tudod csinálni, hogy 1-1 workert leállítasz / decomolsz.
Ha ezt ráadásul összepárosítod egy rakat automatizmussal, akkor egy tökéletesen ön-skálázódó rendszert tudsz összerakni, mint amit -azt hiszem- a Netflix is használ: Minden load ballancerük HA-s, azok mögött egy csomó container alapú worker (most hogy a containert pontosan mi szolgála ki (Docker / Kubernetes vagy más hasonló technika) az lényegtelen) külön-külön environmentben (minden environment konkrét szerepet tölt be), és minden environmenthez megvannak a saját automatizmusok, amik képesek 1 teljesen új container-t neked nulláról olyan szinten felhúzni, hogy az nyomban be is lép a clusterbe, és percekkel annak megkreálása után már képes a megemelkedett workloadot kiszolgálni. Ergo Netflix-nek csak annyi a dolga, hogy monitorozza minden ilyen environment kihasználtságát, és ha valami határérték fölé megy, akkor automatikusan be tud rúgni neked akármennyi plusz workert. És ami széppé teszi ezt az az, hogy nem kell 1 konrkét szerveren belül maradj! Nem egy cloud szolgáltatónak van olyan API-ja amivel komplett új VM-et tudsz perceken belül kreálni (ergo plusz diszket, memóriát és CPU-t tudsz minden mögé tenni) és bevonni ebbe a körforgásba.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

+1

A swarm módban megadjuk a replikák számát, így ha egy vas vagy vm valamilyen okból elhagyja a clustert akkor az a konténer átkerül arra a node-ra mely legkevésbé terhelt. Az állapot automatikusan rendeződik amint a node ismért bekerül a clusterbe.

Public cloud megoldásnál feltételezve hogy az mondjuk AWS, az ECS cluster elé beraksz egy ELB-t, az EC2 gépek pedig autoscaling policyben definiált riasztások alapján skálázzák az elérhető gépek számát. Az ELB-re pedig A record aliast raksz mert az úgy költséghatékony.
Amikor a cluster megközelíti a definiált maximális optimális terhelési szintet, a gépek száma növekszik, és minden új gépre a rendszer dob egy containert amit automatikusan regisztrál a loadbalancerben, így a felhasználók nem érintettek. Ez addig megy míg a terhelés le nem csökken vagy a plafont el nem éred.

-

Valami ilyesmit szeretnek en is kiprobalni. Csak a domainen akadtam meg. De most mar latom hogy nem mukodo megoldas, hogy kozvetlenul iranyitom a swarm-ra. Kell a swarm ele meg egy reteg es oda kell iranyitani az A rekordot.

Ha mar AWS-t szoba hoztad... Mi a velemenyed a PAAS vs IAAS-rol? Szerinted megeri tobbet fizetni hogy ilyen harom betus Amazon szolgaltatasokat pattintasz ossze, azzal szemben hogy te epitkezel egyszeru VPS-ekbol? Tudom hogy a skalazhatosag miatt annyit fizetsz amennyi eroforrasra szukseged van, de egy VPS eseten azert nagyobb eroforrasokat kapsz ugyanazert a penzert. Hogy latod?

Miért veszed egy kalap alá a kettőt? PaaS esetében csak azt tudod használni amit az adott szolgáltató kínál az adott platform alatt (szolgáltatások, API-ok, etc). IaaS esetében meg azt amit felépítesz a VM-jeidre. Logikusan, ha olyan igényed van amit PaaS kielégít (az adott platform megad mindent ami kell), akkor azzal jársz jobban, ellenkező esetben IaaS-al kell magadnak összerakni amit szeretnél a saját igényeidnek megfelelően.

Edit: Egy dolog még amit figyelembe vehetsz: PaaS esetén meg kell bízz az adott szolgátlatóban, és az általa nyújtott szolgáltatásokban (nem csak security szempontból, de reliability, meg stability oldalról is - itt azért erősen érdemes elgondolkodni azon, hogy az adott szolgáltató mit is vállal (SLA)). IaaS esetében több kontrollod van némileg, de cserébe minden PaaS nyújtotta előnyt neked kell kézzel összerakni (már ha szükséged van rá).
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Azt hiszem ez már tényleg egy új topic kellene legyen, és igazán nincs szándékomban szétoffolni ezt.

Ahogy Huncraft is mondta mindenkinek másra van szüksége.

Jómagam nagyon megkedveltem az AWS-t mikor projektet implementáltam, most viszont részt veszek a tervezésben is és néha elbizonytalanodok. Biztonsági oldalról azért mégiscsak ott van hogy ezek az S3 objektumok elérhetetlenné vállhatnak, vagy épp valaki illetéktelen hozzáfér, és megmondom őszintén nagy meló jó IAM policyt kidolgozni. Persze minden egyes változtatást tesztelni kell.
Az AWS ad egy löketet az egész projektnek mivel ha jó a hozzáállás akkor az egész infrastruktúka kód, így bármikor módosítható, tesztelhető és mindez relative gyorsan. Gyorsabban mintha baremetal környezetben dolgoznál. Példa: Még folyamatban az előző deployment törlése, de már tolom fel a következőt, ami persze ugyanúgy letesztelve mivel az egész kód.

Természetesen ennek ára van, és aki arra vetemedik hogy AWS-t használ az először tegye rendbe a dolgokat fejben. Tudni kell mit miért akarsz és ez mennyibe kerül. Sokszor a support sem tud rendes választ adni költségmodellezésben, és ez nagy mínusz. Rengeteg feature requestet küldünk nekik (és gondolom bárki aki komolyan használja), mivel elég fapadosak a rendszerek és lehetne sokkal jobb is. A jó hír az hogy ezek nagy részét implementálják is, csak épp nem tudják megmondani mikorra lesz meg.

Nem árt ha a projektet olyanok tervezik akik értik az AWS-t, vagy legalább elfogadják a visszajelzéseket, így extrákat lehet betervezni, mint mondjuk cross region replication ha S3-ról beszélünk.

Nagy adatmennyiség esetén előfordulhat hogy örökre bent ragadsz, bár szerintem erre kis esély van és nagyban függ a tárolt adattól.

Manapság az adatok értéke idővel rohamosan csökken, ezért váltásnál figyelembe veheted. Pl: nagy mennyiségű metaadatot nem mozgatsz át, hanem a már feldolgozott adatokat, eredményeket, így megintcsak spóroltál (legalábbis én így tenném, de ha végtelen a cég pénze akkor lehet nagyot álmodni).

Nem megoldhatatlan az AWS mellőzésével hasonló rendszert kiépíteni, csak kell hozzá megfelelő számú jólfizetett szakember aki tudja ezeket a rendszereket megfelelően reszelgetni. Számításba kell venni a komponensenkénti supportot is, hiszen éles rendszereket nem lehet megfelelő support nélkül üzemeltetni. Minden komponensnek kell legyen üzemeltető csapata és ezek jólképzett, motivált szakemberek kell legyenek.

Jómagam AWS-t használnék, és azt tudom javasolni hogy a megoldás legyen úgy áttervezve hogy az cloud-ready legyen. Fölösleges pénzkidobásnak tartom AWS-t használni úgy hogy EC2-re telepített custom megoldásokkal támogatott containereket hosztolsz.

Nagyon könnyű olyan megoldást építeni ami irdatlan sokba kerül.
Maradj cloud native amennyire csak lehet és használd a kínált megoldásokat a lehető legköltséghatékonyabban.

-