Facebookはレイヤ4ロードバランサをIPVS(LVS)からXDPベースのものに乗り換えつつある - yunazuno.log
4月に開催されたnetdev 2.1で面白いセッションがあったのでメモ。 Facebookが使用しているレイヤ4のロードバランサに関する発表で、従来はIPVS (LVS) を使用していたが、XDPベースで自ら開発したものに移行しつつある、という内容。 XDP Production Usage: DDoS Protection and L4LB (slide) www.youtube.com XDP (eXpress Data Path) については以前のエントリで簡単に紹介した。 yunazuno.hatenablog.com XDPを改めて簡単に紹介すると、Linuxカーネルのネットワークスタックの最下部 (NICに一番近い場所) でパケット処理を行う仕組みのことで、オーバーヘッドが非常に小さい高速パケット処理の実現を目的としている。XDPはeBPFを用いており、eBPFが提供するmap
[En] IPVS for Docker Containers
2. What is IPVS • Stands for IP Virtual Server. Built on top of Netfilter and works in kernel space. No userland copying of network packets involved. • It’s in the mainline Linux Kernel since 2.4.x. Surprisingly, it’s one of the technologies which successfully pumps your stuff through world’s networks for more than 15 years and almost nobody ever heard of it. • Used in many world-scale companies s
![[En] IPVS for Docker Containers](https://cdn-ak-scissors.b.st-hatena.com/image/square/3b4cf4d1682ca1876f5ae74b91cefedc22126772/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fipvsdockerconeu2015-fullversion-151119045345-lva1-app6892-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
facebookの13億ユーザーを支えるロードバランサーの話 - stanaka's blog
最近、SREが話題ですね。 tech.mercari.com www.wantedly.com ということでSREについて調べてたら、SREconなんてものが開催されていたので中を見てたら、「Building a Billion User Load Balancer」というタイトルでFacebookのDNS〜LBまでの話があったので、そのメモです。 Building a Billion User Load Balancer | USENIX tl;dr tinydns + IPVS で Facebook規模はいける httpsの接続確立はかなり重い(RTTの4倍 = RTT 150msとするとGETまで600ms)ので、太平洋越えとかは厳しい httpsを終端させるCDNとかは活用の可能性ありそう (国内だけを考慮するなら影響は軽微かも) メモ L4 LB shiv (IPVS + pyt
#18 mruby-ipvs を実装し卒業論文を書きました - rrreeeyyy.com
Linux の L4 ロードバランサ機能である IPVS を、 mruby から利用できるようにする mruby-ipvs という mrbgem を実装し、 その mruby-ipvs に関して卒業論文を書きました。 動機 電気通信大学 という大学の 4 年生に無事進級できた為、 卒業論文を書く必要がありました。 大学に通いながら、株式会社ハートビーツ で学生スタッフとして働いていた経験上、 Linux カーネル内に実装されている L4 ロードバランサ機能である IP Virtual Server (IPVS) の、 インタフェースに不便しており、なんとかしたいという気持ちがありました。 個人的に Ruby が好きであることに加え、Chef に代表されるような、 インフラストラクチャ自動化フレームワークが Ruby で書かれ始めていること、 更に、mod_mruby といった mruby
MySQLの参照ロードバランスで最近困った２つのこと
こんにちは、インフラの担当をしております平野です。 当社では意味の分からないカードゲームが流行っているようですが、 私は「ダム」に行くともらえる「ダムカード」集めにはまっております。 大きなダムを上から覗いたときに感じる怖さからのお尻のむずむず感がたまりません。 先日、新しいサービス・アーキテクチャのインフラ構築をする際にしくじったことがあったので 記事にしたいと思いました。 1) ipvs環境化でのコネクションプーリングでMySQLがmax_connectionsに到達問題 MySQLレプリケーション機能を利用し、参照のみを利用するクエリ向けにスレーブ機を複数台並べ、 ロードバランスさせる構成を取っていました。 ロードバランサはipvs(lvs)、アプリはコネクションプール機能の利用を前提としていました。 ある程度稼働させたところ、 ・負荷が大してかかってない ・サーバ上のMySQLのコ
LinuxのLVS(IPVS)でMySQLをロードバランスするときはtimeoutに注意 - （ひ）メモ
構成 [appサーバ] -> [lvs] -> [MySQL]群 DRでMySQLのスレーブ群にロードバランス appサーバはDBコネクションのプーリング、永続化をしている 問題の現象 DBサーバ上ではmysqldへのコネクションが存在するのに、appサーバ上ではコネクションが存在しない。(netstat調べ) →無用なコネクションが残留するせいで、MySQLのmax_connectionsに達してしまう。 原因 MySQLの世界の無通信時のコネクションのタイムアウトはデフォルトで 28800秒 (8時間)。一方、IPVSの世界の無通信時のタイムアウトはESTABLISHEDなコネクションで900秒 (15分)。 # ipvsadm -Ln --timeout Timeout (tcp tcpfin udp): 900 120 300なので、DBコネクションの永続化等でコネクションを張りっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
