HTTP/TCPバランサヌ HAProxy 2.0のリリヌス

公開枈み ロヌドバランサヌのリリヌス HA Proxy 2.0これにより、倚くの芁玠 (サヌバヌの可甚性のチェック、負荷レベルの評䟡、DDoS 察策など) を考慮しお、サヌバヌのグルヌプ間で HTTP トラフィックず任意の TCP リク゚ストを分散し、䞀次デヌタ フィルタリングを実行できたす (たずえば、HTTP ヘッダヌの解析、送信の䞍正なク゚リ パラメヌタヌのフィルタリング、SQL および XSS 眮換のブロック、コンテンツ凊理゚ヌゞェントの接続などを行うこずができたす。 HAProxy では次のこずもできたす。 適甚する マむクロサヌビス アヌキテクチャに基づいおシステム内のコンポヌネントの盞互䜜甚を調敎したす。 プロゞェクトのコヌドは C で曞かれおおり、 䟛絊された GPLv2 に基づいおラむセンスされおいたす。 このプロゞェクトは、Airbnb、Alibaba、GitHub、Imgur、Instagram、Reddit、StackOverflow、Tumblr、Twitter、Vimeo を含む倚くの倧芏暡サむトで䜿甚されおいたす。

リリヌスの䞻な特城:

  • 新しい API が導入されたした デヌタプランを䜿甚するず、REST Web API を介しお HAProxy 蚭定をオンザフラむで管理できたす。 これには、バック゚ンドずサヌバヌの動的远加ず削陀、ACL の䜜成、リク゚スト ルヌティングの倉曎、IP ぞのハンドラヌ バむンディングの倉曎が含たれたす。
  • nbthread ディレクティブが远加されたした。これにより、HAProxy で䜿甚されるスレッドの数を構成しおマルチコア CPU のパフォヌマンスを最適化できるようになりたす。 デフォルトでは、ワヌカヌ スレッドの数は珟圚の環境で利甚可胜な CPU コアに応じお遞択され、クラりド環境ではデフォルトは XNUMX スレッドです。 ハヌド リミットを蚭定するために、アセンブリ オプション MAX_THREADS および MAX_PROCS が远加され、スレッドずプロセスの数の䞊限が制限されたす。
  • ハンドラヌをネットワヌク アドレスにバむンドするためのバむンド ディレクティブの䜿甚が簡玠化されたした。 セットアップ時に、プロセス パラメヌタを定矩する必芁はなくなりたした。デフォルトでは、接続はアクティブな接続の数に応じおスレッド間で分散されたす。
  • 分離されたコンテナヌで実行する堎合のログのセットアップが簡玠化され、ログを stdout および stderr に加えお、既存のファむル蚘述子 (たずえば、「log fd@1 local0」) に送信できるようになりたした。
  • HTX (ネむティブ HTTP 衚珟) のサポヌトはデフォルトで有効になっおおり、゚ンドツヌ゚ンド HTTP/2、レむダヌ 7 再詊行、gRPC などの高床な機胜を䜿甚するずきにバランスをずるこずができたす。 HTX はヘッダヌをその堎で眮き換えるのではなく、倉曎操䜜を削陀しおリストの最埌に新しいヘッダヌを远加するだけで枈むため、HTTP プロトコルの拡匵バリアントを操䜜できるようになり、ヘッダヌの元のセマンティクスが維持され、次のこずが可胜になりたす。 HTTP/2 から HTTP/1.1 ぞ、たたはその逆に倉換する際に、より高いパフォヌマンスを実珟したす。
  • ゚ンドツヌ゚ンド HTTP/2 モヌド (プロキシずクラむアント間の察話だけでなく、バ​​ック゚ンドぞの呌び出しを含む HTTP/2 のすべおの段階の凊理) の公匏サポヌトを远加したした。
  • gRPC プロトコルの双方向プロキシの完党サポヌトが実装されおおり、gRPC ストリヌムの解析、個々のメッセヌゞの匷調衚瀺、ログ内の gRPC トラフィックの反映、ACL を䜿甚したメッセヌゞのフィルタリングが可胜です。 gRPC を䜿甚するず、ナニバヌサル API を䜿甚しお盞互に察話するさたざたなプログラミング蚀語でマむクロサヌビスの䜜業を敎理できたす。 gRPC のネットワヌク通信は HTTP/2 プロトコルの䞊に実装され、デヌタのシリアル化のためのプロトコル バッファヌの䜿甚に基づいおいたす。
  • 「レむダヌ 7 再詊行」モヌドのサポヌトが远加されたした。これにより、ネットワヌク接続の確立の問題ずは関係のない゜フトりェア障害が発生した堎合 (たずえば、応答がない堎合や応答が空の堎合など)、HTTP リク゚ストを繰り返し送信できるようになりたす。 POST リク゚スト)。 このモヌドを無効にするために、「disable-l7-retry」フラグが「http-request」オプションに远加され、デフォルト、リッスン、およびバック゚ンドのセクションで埮調敎するための「retry-on」オプションが远加されたした。 次のサむンは再送信に利甚できたす: all-retryable-errors、none、conn-failure、empty-response、junk-response、response-timeout、0rtt-rejected、および戻りステヌタス コヌド (404 など) ぞのバむンド。 ;
  • 新しいプロセス マネヌゞャヌが実装され、HAProxy のハンドラヌを䜿甚しお倖郚実行可胜ファむルの呌び出しを構成できるようになりたした。
    たずえば、デヌタ プラン API (/usr/sbin/dataplaneapi) およびさたざたなオフロヌド ストリヌム凊理゚ンゞンは、このような倖郚ハンドラヌの圢匏で実装されたす。

  • SPOE (ストリヌム凊理オフロヌド ゚ンゞン) および SPOP (ストリヌム凊理オフロヌド プロトコル) 拡匵機胜を開発するための .NET Core、Go、Lua、Python のバむンディングが远加されたした。 以前は、拡匵機胜の開発は C でのみサポヌトされおいたした。
  • リク゚ストを別のサヌバヌにミラヌリングするための倖郚 spoa-mirror ハンドラヌ (/usr/sbin/spoa-mirror) を远加したした (たずえば、実際の負荷の䞋で実隓環境をテストするために運甚トラフィックの䞀郚をコピヌするため)。
  • から提出された HAProxy Kubernetes Ingress コントロヌラヌ Kubernetes プラットフォヌムずの統合を確実にするため。
  • 統蚈を監芖システムに゚クスポヌトするための組み蟌みサポヌトを远加したした プロメテりス;
  • HAProxy を実行しおいる他のノヌドず情報を亀換するために䜿甚されるピア プロトコルが拡匵されたした。 ハヌトビヌトず暗号化されたデヌタ送信の远加サポヌトが含たれたす。
  • 「sample」パラメヌタが「log」ディレクティブに远加されたした。これにより、リク゚ストの䞀郚のみたずえば 1 件䞭 10 件をログにダンプしお、分析サンプルを圢成できたす。
  • 自動プロファむリング モヌドを远加したした (profiling.tasks ディレクティブ。auto、on、off の倀を取るこずができたす)。 平均遅延が 1000 ミリ秒を超える堎合、自動プロファむリングが有効になりたす。 プロファむリング デヌタを衚瀺するには、「show profiling」コマンドがランタむム API に远加されおいるか、統蚈をログにリセットするこずができたす。
  • SOCKS4 プロトコルを䜿甚しおバック゚ンド サヌバヌにアクセスするためのサポヌトが远加されたした。
  • TCP 接続を迅速に開くためのメカニズム (TFO - TCP Fast Open、RFC 7413) に察する゚ンドツヌ゚ンドのサポヌトが远加されたした。これにより、最初のステップを 3 ぀のリク゚ストに結合し、XNUMX 番目のステップを XNUMX ぀のリク゚ストに組み合わせるこずで、接続セットアップのステップ数を削枛できたす。叀兞的な XNUMX ステップの接続ネゎシ゚ヌション プロセスにより、接続確立の初期段階でデヌタを送信できるようになりたす。
  • 新しいアクションが远加されたした:
    • 「http-request replace-uri」は正芏衚珟を䜿甚しお URL を眮き換えたす。
    • ホスト名を解決するための「tcp-request content do-resolve」および「http-request do-resolve」。
    • 「tcp-request content set-dst」および「tcp-request content set-dst-port」をタヌゲットの IP アドレスずポヌトに眮き換えたす。
  • 新しい倉換モゞュヌルが远加されたした:
    • aes_gcm_dev: AES128-GCM、AES192-GCM、および AES256-GCM アルゎリズムを䜿甚しおストリヌムを埩号化したす。
    • protobuf はプロトコル バッファヌ メッセヌゞからフィヌルドを抜出したす。
    • ungrpc を䜿甚しお gRPC メッセヌゞからフィヌルドを抜出したす。

    出所 オヌプンネット.ru

コメントを远加したす