HAProxy provides end-to-end proxying of HTTP/2 traffic. Use HAProxy to route, secure, and observe gRPC traffic over HTTP/2. Read on to learn more. HAProxy 1.9 introduced the Native HTTP Representation (HTX). Not only does this allow you to use HTTP/2 end-to-end, it also paves the way for HAProxy to support newer versions of HTTP-based technologies and protocols at a faster pace. Today, with the re
とあるネットワーク(Web)サーバがありまして。 graceful restart できない graceful stop はできる 処理中のものは全て処理し終わってから終了する 再起動は数秒で完了する という性質のものを、稼働中に再起動するとダウンタイムがでてしまうのをなんとか誤魔化したかったのです。 最初は nginx から proxy しているところで、繋がらなかったら何秒かおいて何回までリトライ、みたいな設定ができないか探したんですが見つからず、HAProxy を調べたら以下のような設定でできたのでメモ。 frontend absorber mode tcp default_backend upstream bind *:9999 backend upstream mode tcp server localhost localhost:8888 weight 1 retries 10
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
HTTP protocol is connection-less and only the client can request information from a server. In any case, a server can contact a client. HTTP is purely half-duplex. Furthermore, a server can answer only one time to a client request. Some websites or web applications require the server to update client from time to time. There were a few ways to do so: the client request the server at a regular inte
# HAproxy: mapping process to CPU core for maximum performance This article was updated in 2018 to reflect new options. See at the bottom. HAproxy 1.5 being long in development, introduced many new features. Two of them are in particular interesting for me: encryption offloading and binding processes to CPU cores. Since version 1.5 it is possible to offload all encryption to your HAproxy servers a
マイクロサービスのアーキテクチャでシステムを開発すると、サービス間の通信を効率的に管理する方法が必要になる。この問題を解決するためにHAProxyを使う一例を提示する。 「マイクロサービス」は、この10年でもっとも興味深いアーキテクチャーのスタイルを表す言葉として、使い散らされている最新のアーキテクチャーバズワードでしょう。 マイクロサービスとは？ Martin Fowlerの定義によれば以下のようになります。 要するにマイクロサービスというアーキテクチャーのスタイルは、それぞれが独自のプロセスで動きHTTPリソースAPIなどの軽量なメカニズムでコミュニケーションを取り合う小さなサービスの形をとったひとつのアプリケーションを開発していくというアプローチです。これらのサービスは、ビジネス上の機能を中心に作られ、完全に自動化されたデプロイの仕組みによって、別々にデプロイできます。これらのサービ
RDS ReadReplicaを立てて、参照クエリを逃がすことを考える。 可用性や拡張性を考えてReadReplicaは複数台構成とした場合、RDSの仕様を考慮して設計しておく必要がある。ポイントは以下。 Read Replicaは個々にEndpoint (DNS名) を持つ。 複数Read Replicaに対してバランシングする仕組みは提供していない。 ELBは RDS (Read Replica含め) には使えない。ELBにぶら下げられるのはEC2のみ。 Read Replica各ノードの死活監視、障害時の切り離し／切り戻しを考慮する必要がある。 ということで、Read Replicaのバランシングを行うなら、自分で仕組みを用意する必要がある。 実現方法はいくつか選択肢があるが、今回はL7のバランサーとして定評のあるHAProxyを使ってみる。 Architecture with HA
特定のサーバーに対して多く接続を振り分けたい場合、serverキーワードの「weight」オプションで振り分けを行う際の重み付けを指定できる。次の例では「centos01」の重みを1、「centos02」の重みを2に設定している。 frontend web_proxy default_backend web_servers bind *:80 backend web_servers server web01 centos01:80 weight 1 server web02 centos02:80 weight 2 roundrobinアルゴリズムの場合、指定した重みに比例してそのサーバーに振り分けられる接続数が増加する。この例の場合、centos02というサーバーにはcentos01の2倍の数の接続が割り振られるようになる。 サーバーの監視 HAProxyのデフォルト設定では、バックエン
斎藤です。こんにちは。 今日は、MySQLにてレプリケーション構成において、マスタサーバのフェイルオーバーを司るmysql-master-ha(以下、MHA)を用いる際、マスタサーバ接続先の切り替えにHAProxyを使ってみようというお話です。 ※MHAは0.53.0(公式パッケージ)、MySQLは5.5.25a(Oracle公式パッケージ)、HAProxyは1.4.22(CentOS6標準パッケージ)、OSはCentOS 6.3 x86_64を用いました。 ※MHAによる冗長化およびHAProxyによるMySQLの負荷分散の設定を経験された事がある前提で記述します。 本記事では、次の流れで話題を展開します。 フェイルオーバー時の接続先切り替え方法 構成(参考) なぜHAProxyなのか 切り替え方 2台構成の問題点 その他 コツ 設定(参考) 主にMHA+HAProxyによるフェイルオー
hashicorp/serf Serf Serf使ってますか！サーフ！ 諸事情というか大人の事情で急遽自前でロードバランサを用意しないといけなくて、それをissueに書いてたら、 あんちぽさんがSerf+HAProxy使ったらいいのでは、 とIRCで助言をくれて、同日のmizzyさんのブログでもSerfに言及していたので、 ちょっとSerfの概要を知るためと、Serf+HAProxyが実際ロードバランサとしてどんな感じに使えるのか検証してみた。 I told @glidenote about a combination of Serf and HAProxy this morning, and he has already implemented the arch. and done investigation… — kentaro (@kentaro) October 29, 2013
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HAProxy on AWS: Best Practices Part 1