terheléselosztó kioldó , amely lehetővé teszi a HTTP forgalom és tetszőleges TCP kérések elosztását egy szervercsoport között, számos tényező figyelembevételével (például ellenőrzi a szerverek elérhetőségét, felméri a terhelési szintet, rendelkezik DDoS ellenintézkedésekkel) és elsődleges adatszűrést végez ( Például elemezheti a HTTP fejléceket, szűrheti a helytelen lekérdezési paramétereket, blokkolhatja az SQL és XSS helyettesítését, csatlakoztathatja a tartalomfeldolgozó ügynököket). A HAProxy is képes a komponensek interakciójának koordinálására a mikroszolgáltatási architektúrán alapuló rendszerekben. A projekt kódja C és betűkkel van írva GPLv2 licenccel. A projektet számos nagy webhelyen használják, köztük az Airbnb, Alibaba, GitHub, Imgur, Instagram, Reddit, StackOverflow, Tumblr, Twitter és Vimeo.
Főbb kiadási jellemzők:
- Új API bevezetésre került , amely lehetővé teszi a HAProxy beállítások menet közbeni kezelését a REST Web API-n keresztül. Beleértve dinamikusan hozzáadhat és eltávolíthat háttérrendszereket és kiszolgálókat, ACL-eket hozhat létre, módosíthatja a kérések útválasztását, módosíthatja a kezelők kötéseit IP-re;
- Hozzáadtuk az nbthread direktívát, amely lehetővé teszi a HAProxyban használt szálak számának konfigurálását a többmagos CPU-k teljesítményének optimalizálása érdekében. Alapértelmezés szerint a munkaszálak száma az aktuális környezetben elérhető CPU-magoktól függően van kiválasztva, felhőkörnyezetekben pedig az alapértelmezett egy szál. A szigorú korlátok beállításához hozzáadták a MAX_THREADS és MAX_PROCS összeállítási opciókat, korlátozva a szálak és folyamatok számának felső határát;
- A bind direktíva használata a kezelők hálózati címekhez való kötésére egyszerűsödött. A beállításkor már nem szükséges folyamatparamétereket megadni - alapértelmezés szerint a kapcsolatok az aktív kapcsolatok számától függően lesznek elosztva a szálak között.
- A naplók beállítása, ha elszigetelt tárolókban fut, leegyszerűsödött – a napló mostantól elküldhető az stdout és stderr, valamint bármely meglévő fájlleíróhoz (például „log fd@1 local0”);
- A HTX (Native HTTP Representation) támogatása alapértelmezés szerint engedélyezve van, lehetővé téve az egyensúlyozást olyan fejlett funkciók használatakor, mint a végpontok közötti HTTP/2, a 7. rétegbeli újrapróbálkozások és a gRPC. A HTX nem helyettesíti a fejléceket a helyükön, hanem a módosítási műveletet lecsökkenti egy új fejléc eltávolítására és a lista végére történő hozzáadására, amely lehetővé teszi a HTTP protokoll bármely kiterjesztett változatának manipulálását, megőrizve a fejlécek eredeti szemantikáját, és lehetővé teszi, hogy nagyobb teljesítmény elérése érdekében, amikor a HTTP/2-t HTTP/1.1-re fordítja és fordítva;
- Hivatalos támogatás hozzáadva a végpontok közötti HTTP/2 módhoz (a HTTP/2 összes szakaszának feldolgozása, beleértve a háttérhívásokat is, nem csak a proxy és az ügyfél közötti interakciót);
- A gRPC-protokoll kétirányú proxyjának teljes támogatása megvalósult a gRPC-folyamok elemzésének, az egyes üzenetek kiemelésének, a gRPC-forgalomnak a naplóban való megjelenítésének és az üzenetek ACL-ek segítségével történő szűrésének lehetőségével. A gRPC lehetővé teszi a mikroszolgáltatások munkájának megszervezését különböző programozási nyelveken, amelyek kölcsönhatásba lépnek egymással egy univerzális API segítségével. A gRPC hálózati kommunikációja a HTTP/2 protokollon felül van megvalósítva, és az adatok sorosítására szolgáló protokollpufferek használatán alapul.
- Hozzáadott támogatás a „Layer 7 Retries” módhoz, amely lehetővé teszi ismételt HTTP kérések küldését olyan szoftverhiba esetén, amelyek nem kapcsolódnak a hálózati kapcsolat létrehozásának problémáihoz (például ha nincs válasz vagy üres válasz egy POST kérés). A mód letiltásához a „disable-l7-retry” jelzőt hozzáadtuk a „http-request” opcióhoz, és a „retry-on” opciót is hozzáadtuk az alapértelmezett, figyelési és háttérszakaszok finomhangolásához. A következő jelek állnak rendelkezésre az újraküldéshez: all-retryable-errors, none, conn-failure, empty-response, junk-response, response-timeout, 0rtt-rejected, valamint a visszatérési állapotkódokhoz (404 stb.) való kötődés. ;
- Új folyamatkezelő került bevezetésre, amely lehetővé teszi a külső végrehajtható fájlok HAProxy kezelőivel történő hívását.
Például a Data Plan API (/usr/sbin/dataplaneapi), valamint a különféle Offload adatfolyam-feldolgozó motorok egy ilyen külső kezelő formájában valósulnak meg; - Kötések kerültek hozzáadásra a .NET Core, Go, Lua és Python SPOE (Stream Processing Offload Engine) és SPOP (Stream Processing Offload Protocol) bővítmények fejlesztéséhez. Korábban a bővítményfejlesztést csak C nyelven támogatták;
- Külső spoa-tükör kezelő (/usr/sbin/spoa-mirror) hozzáadva a kérések külön szerverre való tükrözéséhez (például az éles forgalom egy részének másolásához egy kísérleti környezet valós terhelés alatti teszteléséhez);
- Által benyújtott a Kubernetes platformmal való integráció biztosítása;
- Beépített támogatás hozzáadva a statisztikák exportálásához a megfigyelő rendszerhez ;
- A HAProxyt futtató többi csomóponttal való információcserére használt Peers Protocol kibővült. Beleértve a Heartbeat és a titkosított adatátvitel támogatását;
- A „sample” paraméter hozzáadásra került a „log” direktívához, amely lehetővé teszi, hogy a kéréseknek csak egy részét írja be a naplóba, például 1-ből 10-et, hogy analitikai mintát képezzen;
- Automatikus profilalkotási mód hozzáadva (profiling.tasks direktíva, amely képes az automatikus, be- és kikapcsolási értékeket felvenni). Az automatikus profilalkotás engedélyezve van, ha az átlagos késleltetés meghaladja az 1000 ms-ot. A profilozási adatok megtekintéséhez a „profilozás megjelenítése” parancsot hozzáadtuk a Runtime API-hoz, vagy lehetőség van a statisztikák visszaállítására a naplóba;
- Támogatás hozzáadva a háttérkiszolgálókhoz a SOCKS4 protokoll használatával;
- Hozzáadott végpontok közötti támogatás a TCP-kapcsolatok gyors megnyitását lehetővé tévő mechanizmushoz (TFO - TCP Fast Open, RFC 7413), amely lehetővé teszi a kapcsolatbeállítási lépések számának csökkentését azáltal, hogy az elsőt egy kérésben egyesíti, a második lépést pedig a klasszikus 3 lépésből álló kapcsolategyeztetési folyamat, és lehetővé teszi az adatok küldését a kapcsolat létrehozásának kezdeti szakaszában;
- Új műveletek hozzáadva:
- "http-request change-uri" az URL reguláris kifejezéssel történő lecseréléséhez;
- „tcp-request content do-resolve” és „http-request do-resolve” a gazdagépnév feloldásához;
- A „tcp-request content set-dst” és a „tcp-request content set-dst-port” a cél IP-címet és portot helyettesíti.
- Új konverziós modulok hozzáadva:
- aes_gcm_dev adatfolyamok visszafejtéséhez AES128-GCM, AES192-GCM és AES256-GCM algoritmusok használatával;
- protobuf a mezők kinyerésére a Protocol Buffers üzenetekből;
- ungrpc a mezők kinyeréséhez a gRPC üzenetekből.
Forrás: opennet.ru