Názory k článku Velká řešení otevřeně: load balancing s HAProxy
-
Terminace ssl spojeni na balancerech je naprosto standardni reseni - rika se tomu SSL Akcelerator. Sit za loadbalancerem ale musite mit pod kontrolou a nesmite tam pripojit cizi zarizeni. Pokud stavite cluster pro jednoho zakaznika s vlastni vnitrni siti, tak opravdu neni zadny rozumny duvod tento scenar nepouzit. Tech par procent usetreneho vykonu se Vam muze ve spicce hodit.
-
MP (neregistrovaný)
Zase na druhou stranu, ve chvili, kdy potrebujete presmerovat backend nekam mimo, klidne i pres nechranene site, tak je lepsi nemit terminaci ssl na balanceru. Jeste resenim je mit reencrypt setup, kdy se pouzije HTTP rezim s ssl offload, ale smerem na backend se to zase zasifruje.
Ja to ted prave rozjizdim v testovacim rezimu a taktez hodne vaham nad TCP/HTTP rezimem. Jednak z duvodu prave Let's Encrypt a uloziste pro certifikaty a nutnost jejich prenos na balancery/aplikacni servery v ruznem formatu, jednak z duvodu, ze jsem ted nasazoval jednu apache proxy pro websockety a byly s tim problemy, nez se naslo konfiguracni reseni. TCP je jednoduchost, ale nevyhodou je prave nemoznost to filtrovat na urovni L7.
-
. . (neregistrovaný)
terminovat SSL spojení na balanceru je pro homogenní systémy lepší řešení, držíš tím soukromé klíče na jednom místě a dobře chráněné, než když je má k dispozici aplikační kód či mnoho dalších jednotek.
Nic ti ale nebrání, aby backend komunikace byla chráněná vlastní ssl/tls vrstvou, tohle řešení běžně používám a implementuji i klientů.
Websocket na to je velice špatně navržený a v kombinaci s node.js to může být průser. HTTP/2 umožňuje v jednodušším režimu rovnou jeho terminaci na balanceru a následnou komunikaci přes HTTP na backend. Pokud máš potřebu HTTP/2 dostat až k samotné aplikaci (jak to dělá třeba google), je vhodné z aplikace odstranit doménovou logiku a udělat z ní jen transparentní collector pro data z dalších backendů.
Je neskutečně rizikové v jednom aplikačním vlákně dešifrovat data a zároveň tam provádět doménové operace, řada programovacích jazyků/knihoven/compilerů nenuluje data při uvolnění (či alokaci) paměti a může dojít k úniku soukromých klíčů, zejména kritické to je v dynamických jazycích s GC (php, node.js, python, lua, java).
-
MP (neregistrovaný)
Tak, pokud maji mit klice k dispozici balancery v chranene zone, ale pristupne zvenku, nebo nginxy v interni zone, tak to uz vyjde z meho pohledu nastejno ve chvili, kdyz hodlam mit tls po cele trase. Interni certifikaty na to nasazovat nechci (ani na to nemam automatiku), takze je pro me jednodussi pouzit tcp variantu. V obou pripadech stejne musim delat synchronizaci certifikatu na vice stroju. Rozhodne tim nezavrhuji http variantu, mozna na ni casem prejdeme, nebyt let's encrypt, tak snad ani nevaham.
-
. . (neregistrovaný)
samozřejmě, pokud máš takovýhou infrastrukturu, moc velký rozdíl v tom není, ale na backendu můžeš mít mnohem více technologií než nginx nebo v budoucnu dojde k rozšíření a pak to je problematické.
Terminací SSL/TSL vrstvy na backendu přicházíš o možnost znovupoužívání SSL/TLS session a musí se pro každý backend vytvářet nová (její synchronizace a udržování na centralizovaném uložišti je technicky náročnější), tím zbytečně prodlužuješ načítání stránek.
Balancování pouze TCP kanálu může dojít k ne optimálnímu využití zdrojů, stejně tak nedokážeš efektivně využívat cache pro statické soubory, ty ale zase můžeš mít někde jinde v CDN.
-
Diky za pekny serial.
HA proxy je podle me stale nejlepsi volba na trhu, ackoli pokud mohu, tak presouvam loadbalancing a SSL interception na sitovou infrastrukturu, tj. routery. Hlavne pro SOA/microservice architectury v rezimu "hodne malych zprav" presunuti SSL preruseni na hardware ulehci serverum (bavim se napr. o ~1000 zprav/requestu za vterinu).
Nicmene zpet k HAProxy jakozto vyrazneho prvku v navrhu architektury, ktera je schopna distribuovat zatez a preklopit se na jine zdroje v pripade vypadku aktualnich zdroju. Pro nove datove centrum, ktere stavime v Belgii/Francii zrovna testuju pouziti Apache Mesos, resp. Mesosphere Data Center Operating System (DCOS). Zkracene, to co je operacni system pro jeden pocitac (notebook/workstation/server), to chce byt DCOS pro cele datove centrum ve smyslu jednotneho pristupu ke zdrojum. DCOS si ridi sam (castecne), kam sluzby vypusti a kam je preklopi v pripade vypadku sluzby, ja mu definuju zony/prostor -> zdroje, nad kteryma muze operovat.
Tuto problematiku resi komponenta Marathon, ktera jako underlaying subsystem pouziva HAProxy, kterou automaticky prekonfiguruje noveho/fail-over deploymentu.
https://mesosphere.github.io/marathon/docs/service-discovery-load-balancing.htmlresp. marathon-lb
https://github.com/mesosphere/marathon-lbChapu, ze pokud stavis cluster, ktery je bud maly do poctu nodu, nebo do poctu aplikaci(treba jen jedna distribuovana), ktere na nem provozujes, tak manualni cesta pripadne Ansible/Puppet, apod. je way-to-go. Na druhou stranu, pokud mas vetsi mnozstvi nejruznejsich aplikaci, a infrastruktura, na ktere pobezi musi poskytovat loadbalancing, failover a pokud mozno self-healing, pak je Mesos pro me zajimavy a cesta budoucnosti (ackoli ma taky svoje mouchy :-) )
Mesos's moto:
Program against your datacenter like it’s a single pool of resources (CPU, RAM, Storage)Link:
http://mesos.apache.org/Mozna trochu off-topic, ale kazdopadne hot-topic na mojem stole pri navrhu noveho DC a HAProxy v tom hraje dulezitou roli!
Tesim se na dalsi dily!
-
. . (neregistrovaný)
hezké!
Máš s tím už nějaké zkušenosti? Jak vám jde testování?
Je to cca dva roky, kdy na jednom projektu o cca desítkách serverů kolegové zkoušeli právě tenhle stack nahodit, bylo v tom ale poměrně dost drobných bugů, provozně to je tak nějak na hraně, zpětné přispívání do apache projektů je pro malé partnery krkolomné a trvá dlouho.
Rád uslyším o někom, kdo na tom také staví produkci a jaký je současný stav.
ČLÁNKY DO MAILU