5 時過ぎに目が覚めて眠れなくなったので気になっていたことを考えてみた。 はじめに RDS のリードレプリカを HAProxy で振り分ける方法については... blog.cloudpack.jp 上記の記事を参考にしつつ... blog.cloudpack.jp 上記のようなことをやってみたりした。 RDS のリードレプリカ（RR）接続を HAProxy で振り分ける 一応、構成図 基本的には... HAProxy で RDS への分散アクセスを行う場合には、以下のように設定すれば RDS への接続をチェックして接続出来なければ HAProxy がよしなに切り離してくれる。 （略） listen mysql bind 0.0.0.0:3306 mode tcp option mysql-check user user_name balance leastconn server read0
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
2016 - 03 - 15 Amazon ECSでHAProxyのDockerコンテナを各Taskに配置するのがなかなか良い件 Docker HAProxy AWS ECS どうも、コンテナ芸人です。久しぶり？に Amazon ECSを使ったネタをお届けします。 今のプロジェクトではDBに MySQL を利用していますが、コスト低減のためにMaster(Multi-AZ)だけRDSでSlaveはEC2で構築しています。で、SlaveにはELB経由で参照していましたが、最近この仕組みをHAProxyコンテナに置き換えてみたらなかなか良かったぞという話です。 旧構成 これがつい先日までの構成。 ECS Task *1 は Nginx+Node(React)+ API (Go)+td-agent で1セット Nginxは API コンテナや、 SSR でHTMLを返却するNodeコンテナへPr
追記(2016-07-13 16:40) Changelog に書いてあるとおり(BUG/MEDIUM: dns: unbreak DNS resolver after header fix)、 動的名前解決ができないバグが修正されました。 HAProxy 1.6.6 で動的名前解決できないバグが修正されていました(Changelog にも書いていますが一応検証しました)— tkuchiki (@tkuchiki) 2016年7月13日 詳細は省きますが、本記事と同様の検証を行い、動的名前解決ができることを確認しました。 追記(2016-06-24 12:34) HAProxy 1.6.5 は、DNS の動的名前解決が動作しないようです。 ご注意ください。 HAProxy 1.6.5 で動的名前解決できない問題については 1.6.4 で困っていなければそれを使って、1.6.5 がよければ
0 ? '-30px' : '30px'), opacity: menu === 'platform' ? '1' : '0', transition: transition ? 'left 500ms ease-out, opacity ' + (menu === 'platform' ? '100ms' : '100ms') + ' ease-out' : 'none' }" x-ref="platform" role="menu" :aria-label="'HAProxy One menu'" :inert="menu !== 'platform'" @keydown.tab.shift="if (menu === 'platform' && $event.target === $el.querySelector('a')) { $event.preventDefault(); c
MySQL で slave を複数台立てて参照分散するには、HAProxy を利用してロードバランスと切り離しを行うと手軽に使えて便利です。 option mysql-check という設定で、HAProxy 自身が mysqld に接続してヘルスチェックが可能です。 listen mysql-slave bind 127.0.0.1:3307 mode tcp option mysql-check user haproxy balance roundrobin server slave1 192.168.1.11 check server slave2 192.168.1.12 check server slave3 192.168.1.13 checkなのですが、この設定だと以下のように少々不便なことがあります。 mysqldに接続できるかどうかのみを死活の判断にしているので、レプリケ
HAProxyは基本的にL7レイヤのロードバランサー(リバースプロキシ)なので、バックエンドにいるリアルサーバには、フロントエンドから届いたリクエストが、ロードバランサのIPアドレスからアクセスが来たかのように振舞います。 で、HAProxyはtproxy(transparent proxy)をサポートしているようなので、L4で動く透過型のプロキシとしても振舞うことが出来るようです。ので、ちょっと試してみました。 使ったOSは、CentOS 6.4で、HAProxyは開発版の1.5-dev19です。 参考: Transparent proxy support (www.kernel.org/doc) https://www.kernel.org/doc/Documentation/networking/tproxy.txt Linux kernelのnf_tproxy_coreモジュールを
ロードバランサとかリバースプロキシを使って色々やっていると、HTTPS/SSL対応かー、どうしようかなーみたいなことを考える日がそのうちやってきたりするかもしれません。 さて、最近触り始めたHAProxyなんですが、公式サイトの記載を見ていると、開発版のバージョンだとSSL処理をサポートしているみたいなんですよねー。 Update [2012/09/11] : native SSL support was implemented in 1.5-dev12. The points above about CPU usage are still valid though. HAProxy - The Reliable, High Performance TCP/HTTP Load Balancer ふむふむ、"1.5-dev12"以降のバージョンであれば使えそう。 ということで、前回のエントリ
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
斎藤です。こんにちは。 今日は、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によるフェイルオーバーの仕組み
haproxy には起動後に設定ファイルを読み込み直したりする機能がないので、バランス先を追加するなどの変更が無停止ではできない、と思い込んでいたのだけど実は違った、というお話。 実際、同一プロセスで読み込み直すことはできないのだけども、以下のような手法で graceful に再起動することができる。man はちゃんと読みましょう。 # haproxy -f /path/to/haproxy.conf -sf [既に動いているhaproxyのpid]として -sf オプションに pid を渡して起動すると…… haproxy[2] : 起動 haproxy[2] : 既に動いている haproxy[1] に SIGTTOU を送信 haproxy[1] : SIGTTOU を受けると Listen をやめる 新規接続は受け付けない 既に確立している接続はそのまま維持 haproxy[2]
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
