ロードバランサのアーキテクチャいろいろ - yunazuno.log
少し前に，Facebookのロードバランサが話題になっていた． blog.stanaka.org このエントリを読んで，各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた． ざっくり検索した限りだと，Microsoft, CloudFlareの事例が見つかったので，Facebookの例も併せてまとめてみた． アーキテクチャ部分に注目してまとめたので，マネジメント方法や実装方法，ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする． 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた？)ロードバランサのアーキテクチャは，下記の論文が詳しい． Parveen Patel et al., Ananta: cloud scale load balancing
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
RHEL7のNICのネーミングルール - めもめも
参考資料 ・Predictable Network Interface Names 何の話かというと RHEL7では、NICのネーミングルールが変わっています。RHEL6では、DELL製のハードウェアの場合だけネーミングルールが変わるという謎のudevルール（biosdevname）がありましたが、RHEL7では、さらにまた仕組みが変わって、systemdがNICのネーミングを行うようになりました。 まとめると次のようになります。 バージョン ハードウェア ネーミングルール RHEL5 すべて 古典的な「eth0」「eth1」など RHEL6 一般のマシン 古典的な「eth0」「eth1」など RHEL6 DELL製のハードウェア biosdevnameによる「em1」「em2」「p1p1」など RHEL7 一般のマシン Predictable Network Interface Name
GoogleのHTTPロードバランサーの破壊力があり過ぎる #gcpja - Qiita
そもそもGoogle Compute Engineのロードバランサー、GCE LBは、1インスタンス・1グローバルIP・ウォームアップなしでいきなり100万リクエスト／秒を捌けてしまう謎性能を備えていて、既存の他社クラウドのLBだけこれで置き換えたい！ という声もちらほら聞かれるほどの強力LBサービスであった。 From Compute Engine Load Balancing hits 1 million requests per second! そして今回、正式公開ではないLimited Preview版ではあるものの、GCE LBの新機能としてHTTP Load Balancingが発表された。その性能と機能の破壊力があり過ぎるので、GCPブログ記事のリンクをシェアするだけではあまりにもったいない！ と思い、要点を訳してみた。 DNSに頼らない、1グローバルIPによるUS、EU、A
ウノウラボ Unoh Labs: サーバのネットワーク速度の調査/測定方法
こんにちは。kyagi です。先日データセンタ内のサーバ群のうち、なぜか特定の１台だけネットワークの速度が極端に遅いという問題がありました。今回はサーバマシンのネットワーク速度の測定方法と原因についてお話しします。同様のトラブルが発生している方のお役に立てば幸いです。問題解決までの手順としては以下になります。 1. 現在の状態を調べる 2. ハード/ソフト含めて考えられる原因をいくつか挙げる 3. 原因について改善されるまでひとつひとつ検証していく まず現在の NIC の HW 情報とドライバを lspci で調査します。ここでは Broadcom の NetXtreme BCM5722 という NIC を使用していることがわかります。 # lspci -vvv | grep Ether 01:00.0 Ethernet controller: Broadcom Corporation
遠隔地からハングしたサーバの電源ON/OFFやBIOS操作が可能なリモートマネジメントカード「Lights-Out 100」を使ってみた
サーバが遠隔地にある場合に一番困ることのひとつが、サーバのOSがハングアップして何もコマンドを受け付けなくなり、「サーバの電源ボタンを押すしかない！」という状態に陥った場合。わざわざサーバがある場所まで行くのは時間もかかりますし、特に夜中や休日だと気が重くなってしまいます。そこで、こういう緊急事態を回避するためにも、今回HP ProLiant ML150 G5を買ったついでに、リモートマネジメントカード「HP Lights-Out 100」(定価2万4150円)をオプション品として購入してみました。 使えると思った機能は主に2つ。1つ目は「ウェブブラウザから仮想電源ボタンを利用して電源のON/OFF」、もう1つはJAVAを使って「OSに依存せずにコンソールを操作」できるという点です。この2つの機能によって、安心して遠いところにサーバを設置できるだけでなく、システムの温度・電圧・ファンの動作
「はてな流大規模データ処理」を見てきた - もぎゃろぐ
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
無料で使えるサーバ監視/サイト監視。SSL証明書/ドメインの有効期限チェック ： Site Alert(サイトアラート)
お知らせ 2017/01/03 xyz ドメインに対応しました ドメイン期限監視について、xyz ドメインに対応いたしました。 追加ご希望のドメインがございましたら お問い合わせ よりお気軽にご依頼ください。 2016/12/28 サーバ監視における ssh タイムアウトについて 2016/12/28(水) 00:00 頃～12/29(木) 00:00 頃の間、サーバ監視における ssh ポート (ポート22) への接続が全件タイムアウトとなり失敗として扱われる事象が発生しておりました。 上位回線において過剰な通信と判断され、外部 ssh ポートへの接続を制限したとのことでしたが、 調整の結果、ssh ポートへの制限を解除し、今後はこのような制限をかけないことで合意いたしました。 皆様にご不便をおかけしたことをお詫びいたします。 2016/12/27 システム機能追加のお知らせ SSLサー
パソコンを業務用途にも耐えうる高性能ブロードバンドルータにしてしまう「Vyatta」
オープンソースで作られているエンタープライズ用ソフトウェアルーター「Vyatta」は最初から個人向けと言うよりは業務用途目的で開発されており、Cisco 7200よりも価格やパフォーマンスなどで10倍のアドバンテージがあると豪語、実際に第3者機関によるテストでもそのことがある程度証明されており、コストを75％削減できるとしています。 確かにそれ相応の機能があるようで、ルーター、ファイアウォール、VPNなどが可能。また、XenやVMwareの仮想ネットワーク内でも動作。オープンソースで無料版の「Community Edition」であってもコンパイル済みのバイナリの提供やバグフィックスなどは6ヶ月ごとに必ず行われると明言しており、ほかにもRedhatのような有償による手厚いサポートもちゃんと提供しています。 というわけで、実際にこのVyattaを使ってPPPoE接続のブロードバンドルーターを
はてなは京都移転するけど、インフラは東京、という話 - stanaka's blog
はてなの京都移転話も、もうはや周回遅れ気味ですが、あまり気にせずにいきます。ちなみに、今回のエントリの結論はタイトルそのままで、データセンターは京都に移転しません、ということです。 これまで、はてなはデータセンターの移転を二度経験しています。一回目は、京都から東京で1日半ほどサービスが停止しました。その後、鉢山からさくらインターネットのiDCへ1年ほどかけて徐々に移転しました。この時は、各サービスが最大半日程度停止しました。 今回の京都移転を計画していた時もid:jkondoはいつもの調子で、自前サーバからさらに自前DCなんてどうどう？、などと言うのですが、300台程度の規模では自前DC建設の初期コストは賄えないし、また移転のために長い時間サービスを止めれられる状況でもないでしょう、ということで(幸いなことに)没になりました。やれやれ。 id:naoyaもはてなのインフラの仕事から卒業して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
