cél:
- van két IP, amire a terhelést el kéne osztani (súlyozva egyik IP-re és h. ha nem elérhető az egyik IP adott időn belül, csak akkor menjen a forgalom a másikra)
- ezeken az IP-ken van egy TCP port nyitva internetre, ami a lényeg elérhetőség szempontjából
kérdés:
- ti milyen (port) "load balancer as a service" szolgáltatást ajánlotok?
- 416 megtekintés
Hozzászólások
Ebben mi lenne az "as a service"? Cloudban akarod ezt megvalósítani?
Gondolom HTTP / HTTPS típusú forgalomról lenne szó. A leírás alapján szerintem bármelyik HTTP LB alkalmas a feladatra (Haproxy, Pound, Nginx stb.).
- A hozzászóláshoz be kell jelentkezni
Na igen, HTTP(S) esetén vannak kész megoldások, de nem volt egyértelmű, mire is gondolt a költő.
- A hozzászóláshoz be kell jelentkezni
Elvileg egy Mikrotik is tudná valami scripttel a failover-t, ami csekkolja az IP címeket és szükség esetén átírja a NAT szabályt.
De talán még a PCC-vel megoldható lenne ténylegesen a terhelés elosztás is, bár eddig még csak kimenő forgalom több WAN vonalra szétosztásnál láttam.
https://wiki.mikrotik.com/wiki/Manual:PCC
Na meg nem kell hozzá router, hogy tényleg szolgáltatás legyen:
https://help.mikrotik.com/docs/display/ROS/Cloud+Hosted+Router%2C+CHR#C…
- A hozzászóláshoz be kell jelentkezni
Az a legpraktikusabb, ha annak a szolgáltatónak a loadbalancerét használod, ahol a hostjaid vannak. Nálam pl. ezek mennek:
https://rackforest.com/szolgaltatasok/vps: Redundáns Loadbalancer (LVS)
- A hozzászóláshoz be kell jelentkezni
szimplán DNS SRV rekord esetleg?
- A hozzászóláshoz be kell jelentkezni
Az nem igazán erre való, inkább A recorddal (vagy AAAA :) ) de azt is úgy kell akkor csinálnod, hogy health checkelni a backendeket, és csak azokat az IP címeket visszaadni egy kérésre, amik tényleg működnek(és ráadásul random sorrendben, hogy ha egy kliens csak egy A recordot kezel, akkor is el legyen osztva a terhelés). Tipikusan ilyenkor a TTL-t alacsony értékre kell megadni. Pl ezt meg lehet csinálni Consullal, bár igazából azt leginkább egy zárt zónán belül szokás így használni, de persze úgy is lehet, hogy kifelé is látszódjon.
- A hozzászóláshoz be kell jelentkezni
Jó lehet az az SRV is LBre, ha a kliens tudja. (ez a usecase szinte biztosan nem ilyen, csak ha már felemlegetted a consult meg a belült).
- A hozzászóláshoz be kell jelentkezni
itt a kliens alatt magát az applikációs réteget érted?
fixme, de anno amikor ezzel foglalkoztam, akkor mind a loadbalance, mind a failover ment (anélkül, h rugdosni kellett volna a DNS zónát) - amennyiben protokoll szinten támogatott volt. (pl SIP)
- A hozzászóláshoz be kell jelentkezni
Alapvetően minden azon múlik, hogy hol hostolsz. Ha cloud-ról beszélünk, akkor használd a cloud provider által nyújtott lehetőséget. Ha nem, akkor meg nehéz as a service load balancerről beszélni :D Amúgy van sok lehetőséged, de sok mindenen múlik, pl: tcp, vagy applikációs rétegben akarsz loadbalance-olni? Szóba jöhet DNS alapú megoldás és olyan is, amikor átmegy a forgalom a loadbalanceren, ami elosztja a terhelést. De ugye akkor még azt is meg kell oldanod, hogy a load balancer HA legyen, vagyis azok között is kell valamilyen terheléselosztás, ami viszont leggyakrabban tényleg DNS alapon megy, de mehet ip alapon is, csak akkor már az IP address management-hez is hozzá kell férned. Szóval nagyon sok a lehetőség, és leginkább a körülményeken múlik, hogy mikor melyik a legcélszerűbb.
- A hozzászóláshoz be kell jelentkezni
Külső kell vagy belső? Ha külső, akkor Amazon Route53 + weighted + health check.
Ha belső, akkor valamelyik TCP proxy + okosítás.
- A hozzászóláshoz be kell jelentkezni
Van egy koreai ügyfelünk, aki egy gyártósori "központi" szervert szeretne HA-képessé tenni, és ehhez küldtek nekik egy másik ugyan olyan vasat koreából (sima Dell szerver, semmi extra, semmi spéci HW nincs benne).
Mi csináltunk a helyi hálózatukat, így megkérdezték, ezt meg tudjuk-e oldani. Gondolták, hogy ha hálózatot csinálunk, akkor egy ilyen "két gépet kössünk a hálózatra" feladat nem nagy dolog... Nyilván meg ne álljon a termelés, ha elromlik az a gép.
- Milyen OS?
- Nem tudjuk
- Milyen szoftver?
- Nem tudjuk.
- Van-e és milyen adatbázis?
- Nem tudjuk.
- Stateless vagy stateful a kliensek kapcsolata a szerverrel?
- Nem tudjuk.
- Kapcsolat szakadás esetén a kliens újra kapcsolódik vagy kézzel kell beavatkozni, hogy helyre jöjjön?
- Nem tudjuk.
- Milyen módon lehetne replikálni a rendszert a rajta futó szoftver gyártója szertint?
- Nem tudjuk.
- Tudnak-e a kliensek több IP-re csatlakozni, vagy virtuális IP-vel kell megoldani az elérést és a failover-t?
- Mi az a virtuális IP? Mi az a failover? Egyébként nem tudjuk.
stb. beszélgetés zajlott. Majd mikor mondtuk, hogy sajnos információ nélkül nem tudunk segíteni, akkor kikerekedett szemmel kérdezték, hogy de miért nem? Csak két gépet kell a hálózatra kötni, hogy mindegyiket a X.Y.0.10 IP címen elérhessék, és a másik válaszoljon, ha az egyik megáll, nem hiszik, hogy olyan nagy dolog lenne ez...
Nekem ez a feltett kérdés is ilyesmi eddig. Kérdez valaki, beírnak sokan, de a kérdező semmire sem reagál, nem ad további információt.
Az, hogy TCP port van nyitva, akármi is lehet. Egyáltalán nem biztos, hogy LB-rel megoldható a feladat. Talán nem is terhelés elosztás kell, hanem ha jól értem aktív-passzív failover. Lehet csak a kliens app-ba integrálva megy majd a failover, mert teljesen egyedi a kommunikáció. Maga a felvetés, hogy szolgáltatásként szeretné igénybe venni, de nincs megadva, hogy milyen szolgáltatásra van szüksége, már fura.
- A hozzászóláshoz be kell jelentkezni
Ilyenre pl megoldás lehet a Xen-nek (de talán egyéb virtualizációs megoldásnak) az az implementációja, ahol a két host-on folyamatosan szinkronban tartja a RAM-ot (kvázi be nem fejezett live migration-t képzelj el). Ha az elsődleges vas kidöglik, a backup befejezettnek tekinti a migrációs, és kb 1 pinged sem veszett el.
Xen Kemari - erre keress rá.
- A hozzászóláshoz be kell jelentkezni
Csupán két géppel a failover mókás helyzeteket eredményezhet, és az egészben talán a forgalom átirányítása a legegyszerűbb kérdés.
- A hozzászóláshoz be kell jelentkezni
Talán a VMWare Fault Tolerance nevűje tudja ezt, de az olcsó nem lesz, és valszin minimum 3db gép kéne, és még a storage oldal sehol... Az UPS meg minden más háttéről nem is beszélve.
A fenti tipikusan olyan, amikor a random "ájtis" kérdésre a farzsebből előkapott megoldást várják, mert már láttál belülről számítógépet.
Jelen topikban azt sem tudjuk, hogy egyáltalán udp vagy tcp alapú lenne, és milyen felsőbb protokol. :) Aztán könnyen lehet, hogy valójában a Cloudflare megoldása elég, mert webről van szó.
- A hozzászóláshoz be kell jelentkezni
Nekem kisebb vagy non-cloud dolgokra Traefik valt be evek ota. Intezi maganak a certet, tud taplalkozni kb mindenbol is.
Ha dinamikusan szeretned mogotte a node-okat regisztralni akkor eleg egyszeru osszekotni mondjuk Hashicorp Consullal.
- A hozzászóláshoz be kell jelentkezni
NGINX open source is tökéletes erre a célra
https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-bal…
- A hozzászóláshoz be kell jelentkezni
A szokásos nulladik kérdés: a failover/terhelés elosztás mögötti alkalmazás tudja, hogy ilyen huncut dolgok történhetnek vele? Adatok, adatbázis mint elsődleges nyűgök.
Ha nincs ilyen csak mindíg visszamegy egy helloworld, akkor a DNS roundrobin mellékhatását ki lehet használni, miszerint ha egy kapott IP-re épp nem tudnak csatlakozni, akkor lép tovább. Ez esetben persze nagyon bután fog működni, lesz timeout, és nem is biztos, hogy minden kliens szereti.
- A hozzászóláshoz be kell jelentkezni