元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2012/04/29

安っ!単3・単4アルカリ乾電池60本が980円送料無料!


ちょっと安過ぎでビックリするw 単3アルカリ乾電池、1本あたり16円ちょいとかw

今まで見た中でも最安・激安のレベルです。

60本って大杉かもしれませんが、リモコンが一杯あるとか、マウスを激しく使う(充電式の出番かw)とか、みんなで寄りあって買うとかすると良いかもしれませんね。


ALL-WAYS 単3アルカリ乾電池(60本入) B-T3X10P-AW

ALL-WAYS 単3アルカリ乾電池(60本入) B-T3X10P-AW

ALL-WAYS 単4アルカリ乾電池(60本入) B-T4X10P-AW

ALL-WAYS 単4アルカリ乾電池(60本入) B-T4X10P-AW

2012/04/23

WEB+DB PRESS Vol.68

"WEB+DB PRESS Vol.68"の特集「Web技術まるごと整理」に寄稿しました


タイトルそのままですが、今回の"WEB+DB PRESS Vol.68"に寄稿させていただきました。

正確には、特集1の「新人時代に押さえておきたい Web技術まるごと整理」の第5章「クラウドまるごと整理」です。



ターゲットが新卒のエンジニア向けということで、わずかなページではありますが、要点を絞ってクラウドのイロハについて説明してみました。

とまぁ、私の原稿はともかく、今回の"WEB+DB PRESS Vol.68"は、かなり内容が充実しています。


↑リンク先から目次を見ていただければわかると思いますが、特集1ではdankogai先生のお話から始まり、Web技術のおさらいをした後に、その次の特集では、弊社の主席エンジニアの名村先生による、「Node.js実践入門」というガッツリ36ページの濃厚な実践書です。さらにクックパッド執筆陣によるリーンスタートアップの話や、その後の新連載の面子がとにかく凄すぎる・・・。

とりあえず、書籍で見かけたら少し手にとってのぞいてみてください・・・。ゴールデンウィークのお供にも良いと思いますよ!

=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


WEB+DB PRESS Vol.68

WEB+DB PRESS Vol.68


2012/04/22

お花見(横浜みなとみらい)


今年は、横浜みなとみらいにて少しだけ花見イベント(4/8)を満喫。

iPhone4Sだと、このくらいの写真が限界です。


お花見 (横浜みなとみらい)

お花見 (横浜みなとみらい)

お花見 (横浜みなとみらい)

お花見 (横浜みなとみらい)


当日のすべての写真

2012/04/21

MySQL

「MySQL Casual Talks vol.3」に参加してきたよ、のメモ


4/19に、"カジュアル"ではなく"ガチュアル"と定評のある「MySQL Casual Talks」の第3回目に参加してきました。

尚、このイベントの過去の参加記録は以下。


今回は、すごくたくさん人がいたので、誰かがブログでまとめてくれるっしょー、とか思っていたのですが、ひょっとしたら誰もまとめていないんじゃないか疑惑、かもしれなかったので、重い腰をあげてエントリを書いてみることにしました。


駄菓子菓子!


当日は皆さんスピード感あふれる発表が多かったのと、僕はTwitterに書いていたりしたので、手元のメモがあまりないんですよね...(*´σー`)エヘヘ

ということで、公開されている資料を集めて貼り付けた方がメモよりわかりやすいんじゃないかと思って、探してみました。同時にブログでフォローエントリを書かれているケースも多く見られましたので、そちらのリンクも(見つけられたものは)一緒に貼っておきます。

# スライドやリンクがないものについてはタレコミ情報をお待ちしておりますw


イベントの雑感としては、ガチュアルからカジュアルなお話まで、相変わらず素敵で楽しめる話が多いなーと思いましたん。(カジュアルに棒読み)

=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


どうやらみなさんは本当のカジュアルなMySQLを知らないらしい。4/19(木) 19:30に来てください。本物のカジュアルをお目にかけてみせますよ by 諸富さん([twitter:@164c])

※資料公開してくださいw


こんな僕でも一億枚さばけた - 30days albumインフラ成長の歴史 by 黒田さん([twitter:@lamanotrama])


データセンター移行に伴い、MySQLをカジュアルにアップグレードしたお話 by [twitter:@n0ts]さん

View more presentations from Naoya Nakazawa


MySQL Casual な生活 by hatakさん ([twitter:@hisashi])


(ここからはLT)


FORCING SWAP IN by [twitter:@kozy]さん

View more presentations from koziy


なんとかkitについて by [twitter:@marqs]さん

スライド
http://speakerdeck.com/u/marqs/p/ligthtning-talks-at-mysql-casual-vol3

レプリケーションエラーから自動で復旧 by [twitter:@glidenote]さん

スライド
http://speakerdeck.com/u/glidenote/p/2012-04-19-mysql-casual-vol3

MySQL Cluster 7.2のネタ by [twitter:@RKajiyama]さん

※ スライドが映し出されないというハプニングがww

※ 資料があれば公開お願いしますw


道具を磨くことのススメ by [twitter:@masudaK]さん #増田チャラい

View more presentations from Kenichi Masuda


AKB mysql-buildの話 by [twitter:@kamipo]さん

※資料公開してくださいw


PHP と MySQL でカジュアルに MapReduce する by [twitter:@yuya_takeyama]さん

View more presentations from Yuya Takeyama


RailsとMysql by [twitter:@Spring_MT]さん

スライド
http://springmt.github.com/20120419_mysql_casual_lt/

カジュアルなクエリ品質管理 by [twitter:@mikeda]さん

View more PowerPoint from Tomohiro Ikeda


(ここからは超LT)


(続)マスタN対スレーブ1レプリケーションの作り方 by [twitter:@do_aki]さん

View more PowerPoint from do_aki


Fluentd and MySQL by [twitter:@tagomoris]さん

View more presentations from tagomoris


2012/04/13

by ZakVTA

DNSラウンドロビンを使った時にアクセス・負荷が偏る話


昨日に続き、アクセスが偏る系のエントリです。

なにかと議論のネタになるDNSラウンドロビンですが、今日はDNSラウンドロビンを使った時に、各IPアドレスにくるリクエスト数に偏りが出るという話。


DNSラウンドロビンで設定されているFQDNに、コマンドラインで"host"とか"nslookup"のコマンドを何度か実行すると、返ってくるIPアドレスリストの順序が入れ替わっていくことが確認できると思います。

基本的に、クライアントはそのIPアドレスリストの上(最初)からアクセスを行うため、これによって(一応)負荷分散が実現できるはずですが、特定環境のクライアントでは、ラウンドロビンとはならずに必ず特定のIPアドレスにアクセスするケースがあるのです。(既知の事実ですが。)


この事は、Wikipediaの該当ページにも記載されています。

主にIPv6における宛先アドレス選択アルゴリズムとして定義された「RFC3484」では、DNSが同一サーバ名に対し複数のIPアドレスを持つ場合に「自分のアドレスに近いアドレスを優先的に選択する」ことを定めており、Windows Vistaなどマイクロソフト製OSの一部や、最近のLinuxなどではこのルールに従いDNSラウンドロビンがデフォルトで無効にされている。

DNSラウンドロビン - Wikipedia

これが、どういうことかというと、RFC3484の以下部分に書いてあるとおりですが、

Rule 9: Use longest matching prefix.

When DA and DB belong to the same address family (both are IPv6 or both are IPv4): If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then prefer DB.

http://www.ietf.org/rfc/rfc3484.txt

DNSの問い合わせ結果の各々のIPアドレスと自分のIPアドレスを比較し、一致する部分の長さが最も大きくなるものが使われるというもの。


このページの例がわかりやすいのですが、

11000000 10101000 00000000 00000001 = 192.168.0.1 = Client IP to match.
11000000 10101000 00000000 01100100 = 192.168.0.100 = (24 + 1 = 25 bits matching the client IP)
11000000 10101000 00000000 00001010 = 192.168.0.10 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001011 = 192.168.0.11 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001101 = 192.168.0.15 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00010100 = 192.168.0.20 = (24 + 3 = 27 bits matching the client IP)

↑の例だと、自分のIPアドレス(192.168.0.1)と、最長で一致しているのが、"192.168.0.10"、"192.168.0.11"、"192.168.0.15"の3つとなり、この中で一番上(最初)のIPアドレスが使われることになるっぽい。(つまり、192.168.0.10)

つまり、この環境だと問い合わせ結果のリストに含まれる"192.168.0.100"や"192.168.0.20"のIPアドレスは使われないことになる。


一部のクライアント(特にIPv6が有効になっているケースとか?)では、IPv4アドレスでの結果であっても、上記のようにRFC準拠したDNS問い合わせの実装となっているケースがあるようで、それによってDNSラウンドロビンで設定しているドメインであっても、リクエスト・トラフィックに偏りが出てしまう。

有名なのは、Windows VistaやWindows 2008 Server(R1以前?)のDNSクライアントらしい。Windows 7やWindows Server 2008 R2では問題ないみたい。

ただし、アプリケーション(Firefox等のブラウザとか)によっては、上記のような環境においても、アプリケーション側でラウンドロビンにのっとった実装を行ってくれているようだ。


ここで言いたかったのは、上記のような可能性がある以上、DNSラウンドロビンを採用している環境で、各IPアドレスでのアクセス・負荷に偏りが出ることは必然であり、RFC準拠である以上、DNSラウンドロビンは場合によっては使い物にならなくなる可能性があるということ。

今更な話かもしれませんが。


それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


参考


DNS & BIND 第5版

DNS & BIND 第5版

2012/04/12

traffic

Linuxのbonding(802.3ad)で発生したトラフィックの偏りをなおした話


はじめに

とある環境の話。internalのLinuxサーバでbonding(ボンディング)を組んでいました。modeは4802.3ad(LACP)準拠のリンクアグリケーションなモードです。


ちなみに、bondingとは・・・

ちなみに、"bonding"とは、ネットワークインターフェースを冗長化(または負荷分散)する方法で、複数のNICを束ねて1本に見せることができます。チーミング(teaming)と呼ばれたりもしますね。

で、Linuxではbondingにもいくつかモードがあって、複数のポリシーの中から選択することができます。

  • balance-rr 又は 0 - 耐障害性とロードバランシングのためラウンドロビンポリシーを設定します。利用可能な第 1 のインターフェースからそれぞれのボンディングされたスレーブインターフェースで送受信が順次行われます。
  • active-backup 又は 1 - 耐障害性のためアクティブなバックアップポリシーを設定します。利用可能な第 1 のボンディングされたスレーブインターフェースにより送受信が行われます。別のボンディングされたスレーブインターフェースは、アクティブなボンディングされたスレーブインターフェースが失敗した場合にのみ使用されます。
  • balance-xor 又は 2 - 耐障害性とロードバランシングのため XOR (排他的論理和) ポリシーを設定します。この方法を使用すると、インターフェースによって受信要求の MAC アドレスとスレーブ NIC の 1 つの MAC アドレスが一致します。このリンクが確立すると、利用可能な第 1 のインターフェースから送信が順次行われます。
  • broadcast 又は 3 - 耐障害性のためブロードキャストポリシーを設定します。全ての送信は、全てのスレーブインターフェースで行われます。
  • 802.3ad 又は 4 - IEEE 802.3ad 動的リンクアグリゲーションのポリシーを設定します。同一の速度とデュプレックス設定を共有するアグリゲーショングループを作成します。アクティブなアグリゲーターの全てのスレーブで送受信を行います。802.3ad に対応するスイッチが必要です。
  • balance-tlb 又は 5 - 耐障害性とロードバランシングのため送信ロードバランシング (TLB) ポリシーを設定します。発信トラフィックは、各スレーブインターフェースの現在の負荷に従って分散されます。受信トラフィックは、現在のスレーブにより受信されます。受信しているスレーブが失敗すると、別のスレーブが失敗したスレーブの MAC アドレスを引き継ぎます。
  • balance-alb 又は 6 - 耐障害性とロードバランシングのためアクティブロードバランシング (ALB) ポリシーを設定します。IPV4 トラフィック用の送受信ロードバランシングが含まれます。ARP ネゴシエーションにより、受信ロードバランシングが可能です。
no title

はい、ここまでがおさらい。


閑話休題、とあるサーバで・・・

モード4のbondingの(送信時)負荷分散アルゴリズムXOR スタイルとなるので、これまでも多少偏っているサーバはそれなりに見てきました。


駄菓子菓子!


今回は違ったのです。偏り方のレベルが・・・!!


まずはグラフを見てください

以下は、そのサーバのeth0eth1トラフィックのグラフです。


eth0のグラフ(before)

f:id:rx7:20120412211201p:image

eth1のグラフ(before)

f:id:rx7:20120412211202p:image


トラフィックの偏りがパないw

ここまで、くっきり偏ったのは初めて見たので、さすがに驚きました。もう笑っちゃうレベルw

片方が920Mbps、もう片方が40Mbpsとか・・・w

ということで、真面目に送信のハッシュポリシーを調べてみると、、、

  • 0 又は layer2 - デフォルト設定です。このパラメーターは、ハードウェア MAC アドレスの XOR を使用してハッシュを生成します。使用する公式は以下のとおりです:
(<source_MAC_address> XOR <destination_MAC>) MODULO <slave_count>
no title

デフォルトはLayer 2となっているわけですね。

というわけで、主な送信元のMACアドレスを調べてみます。

$ tomahawk -t 10 -u username -c -f server.list '/sbin/ifconfig | grep "bond0 "'

username@172.xx.xx.165 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:50

username@172.xx.xx.166 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:8C

username@172.xx.xx.167 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:96

username@172.xx.xx.169 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:26

username@172.xx.xx.170 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:YY:AE

username@172.xx.xx.171 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:68

username@172.xx.xx.172 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:YY:E0

username@172.xx.xx.173 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:18

username@172.xx.xx.174 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:A0

username@172.xx.xx.175 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:ZZ:E0

username@172.xx.xx.177 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:ZZ:60

username@172.xx.xx.178 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:YY:XX:34

username@172.xx.xx.179 % /sbin/ifconfig | grep "bond0 "
bond0     Link encap:Ethernet  HWaddr XX:XX:XX:YY:XX:30

・・・・・以下、省略・・・・・

送信先(とあるサーバ)のMACアドレスとの排他的論理和(XOR)が、ほっとんど""という結果にww

というわけで、トラフィックがNICによって偏ってしまうのは当然の結果であったわけです。


802.3ad(LACP)モードでの送信ハッシュポリシー

調べていくと送信ハッシュポリシーは"layer2"、"layer3+4"、"layer2+3"の3種類から選択できることがわかります。

ということで、今回は"layer2+3"に送信ハッシュポリシーを変更してみました。

  • 2 又は layer2+3 - layer2 及び layer3 プロトコル情報の組み合わせを使用して、ハッシュを生成します。ハードウェア MAC アドレス及び IP アドレスの XOR を使用して、ハッシュを生成します。公式は以下のとおりです:
(((<source_IP> XOR <dest_IP>) AND 0xffff) XOR
  ( <source_MAC> XOR <destination_MAC> ))
    MODULO <slave_count>
no title

設定は、"/etc/modprobe.conf"に以下のような感じで記載して、(念のため)リブートしました。

# cat /etc/modprobe.conf

・・・前半省略・・・

alias bond0 bonding
options bond0 mode=4 lacp_rate=1 miimon=200 xmit_hash_policy=layer2+3

すると、こうなりました!

以下が、上記設定後の各ネットワークインターフェースでのトラフィックのグラフです。

ちょっと見辛いですが、eth0とeth1のトラフィックが奇麗に分散できていることがわかります。


eth0のグラフ(after)

f:id:rx7:20120412211203p:image

eth1のグラフ(after)

f:id:rx7:20120412211204p:image


おわりに

bondingの設定パラメータは、たくさんの種類があるので、しっかり読んでおいた方がよいですね。反省。

ちなみに、(ここまでも紹介してきましたが)以下のRedHatさんのドキュメントが結構詳しいです。

24.7.2. チャンネルボンディングの使用
http://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sec-Using_Channel_Bonding.html

それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


あわせて読みたい



オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)