負荷分散装置のSSLアクセラレーター機能について

負荷分散装置のSSLアクセラレーター機能を鍵長1024it時代から使っている方向けのリマインダーです。

いわゆる暗号アルゴリズムの2010年問題により、

1024bitの鍵長では近い将来破られるという予測のもと各社からの1024bitのものの提供が終了しています。

ほとんどの方は2048bitへの移行を終わられているかと思います。

dmmでも2048bitへの移行がほとんど完了しました。

ただ、この変更により注意点があります。

鍵長が1024bitから2048bitになるということは、その機器に5倍以上のパフォーマンスが必要になり。これにより機器自体のパフォーマンスが低下してしまう現象が発生します。

例えばSSLの最大同時接続数が10000TPSだったものは2048bitになることで2000TPSまで処理が低下するということです。

10000TPSまでまだ余裕があるなと放置していると問題が発生してしまい、

後手後手の対応になってしまうこともあるかと思います。

また、トラブルシューティングにも多くの時間を要することになってしまうかもしれません。

機器によってはリプレースが必要なものもあるかもしれませんので、

前もって現環境の状況を確認してみてはいかがでしょうか。

ちなみに

F5社のBIGIP
A10Networks社のAX

のどちらも5分の1のパフォーマンスになるとの事でした。

マルチキュー ネットワークインターフェース(修正)

 

最近のNICは複数の送信用受信用のキューが用意されており、

そのキューはそれぞれハードウェアのIRQに関連付けられているので複数のCPUに処理を分散させることができます。

ただ、

複数のキューはあっても受信用のキューだけしか用意されていないNICではIRQでの分散が出来ていないように見えます。

有名どころのNICでは

BroadComの[bnx2][tg3]系のドライバのnicは受信用だけ複数のキューが用意されています。

一方でIntelの[igb][ixgbe]系のドライバのnicは送受信用に複数のキューが用意されています。

/proc/interruptsを見ると確認できます。

私の環境での例です。

em1-0
em1-1
em1-2
em1-3
em1-4

となっていまして、このbroadcomのnicは受信用のキューしかないように見えます。

p6p1-TxRx-0
p6p1-TxRx-1
p6p1-TxRx-2
p6p1-TxRx-3
p6p1-TxRx-4
p6p1-TxRx-5
p6p1-TxRx-6
p6p1-TxRx-7
p6p1-TxRx-8
p6p1-TxRx-9
p6p1-TxRx-10
p6p1-TxRx-11

一方でintelのnicのほうはこのようになっていて送受信用のキューがあり、それが12個見えています。

TxRxとなっているものが送受信対応と考えればいいのかなと思います。

これが原因かはわからないないのですがCPUの使い方に違いがありましたので紹介します。

/proc/interruptsで確認できます。

interrupts

p6p1のnicは均等に複数のcpuに処理が分散されていますがem1のnicはcpu0に偏っています。

次に実際に負荷をかけてCPUの状態を確認します。

まずはintelのnic経由で負荷をかけます。

top – 18:15:53 up 6:09, 2 users, load average: 1.99, 1.97, 1.91
Tasks: 318 total, 1 running, 317 sleeping, 0 stopped, 0 zombie
Cpu0 : 20.8%us, 29.5%sy, 0.0%ni, 42.4%id, 0.0%wa, 0.0%hi, 7.2%si, 0.0%st
Cpu1 : 16.2%us, 23.7%sy, 0.0%ni, 53.8%id, 0.0%wa, 0.0%hi, 6.4%si, 0.0%st
Cpu2 : 11.5%us, 18.3%sy, 0.0%ni, 65.6%id, 0.0%wa, 0.0%hi, 4.7%si, 0.0%st
Cpu3 : 17.6%us, 24.8%sy, 0.0%ni, 49.6%id, 0.0%wa, 0.4%hi, 7.6%si, 0.0%st
Cpu4 : 11.2%us, 14.1%sy, 0.0%ni, 70.4%id, 0.0%wa, 0.4%hi, 4.0%si, 0.0%st
Cpu5 : 3.7%us, 5.8%sy, 0.0%ni, 89.1%id, 0.0%wa, 0.0%hi, 1.4%si, 0.0%st
Cpu6 : 8.7%us, 12.6%sy, 0.0%ni, 75.2%id, 0.0%wa, 0.0%hi, 3.5%si, 0.0%st
Cpu7 : 3.7%us, 5.4%sy, 0.0%ni, 89.8%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st
Cpu8 : 0.7%us, 0.3%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu9 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu10 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu11 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32829724k total, 2468428k used, 30361296k free, 131044k buffers
Swap: 524280k total, 0k used, 524280k free, 1373528k cached

黄色文字部分のシステムのCPU利用率をみていただくとわかるのですが均等に分散しているように見えます。

次はbroadcomです。

top – 18:17:43 up 6:11, 2 users, load average: 1.99, 1.97, 1.91
Tasks: 318 total, 1 running, 317 sleeping, 0 stopped, 0 zombie
Cpu0 : 21.6%us, 34.0%sy, 0.0%ni, 1.0%id, 0.0%wa, 0.0%hi, 43.3%si, 0.0%st
Cpu1 : 2.0%us, 4.0%sy, 0.0%ni, 94.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 1.0%us, 2.0%sy, 0.0%ni, 97.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 2.0%us, 3.0%sy, 0.0%ni, 95.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 34.0%us, 46.8%sy, 0.0%ni, 19.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu8 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu9 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu10 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu11 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

一目瞭然ですね。赤と黄色を見るとCPU0へ負荷が偏っているのがわかると思います。

これはmemcachedに対してmemslapでおもいっきり負荷をかけた結果なのですが、
サーバのパフォーマンスを引き出せぬまま限界を迎えてしまった例です。

複数のmemcachedを立ち上げてサーバ内でスケールアウトは可能なのですが、
できれば、サーバ内でスケールアップのほうが運用しやすいのではないでしょうか。

そもそも、最近のNICは複数のキューがあるのでそのキューで分散できると思いこんでいたんですが、

よくよくみてみると使えてないんだなと。

とりあえずはmemcachedなどのシングルプロセスで動作するアプリケーションでサーバ内でスケールアップさせるためにはintelのnicを利用する形で対応するのが手間がかからず良いように思います。

OS:CentOS 6.4
カーネル:2.6.32-358.el6.x86_64

オンボードNIC:Broadcom BCM5720 Gigabit Ethernet PCIe
driver: tg3
version: 3.129d broadcom社から2013-08-30時点で最新をインストールしています。
firmware-version: FFV7.4.8 bc 5720-v1.30

PCINIC:Intel 10-Gigabit X540-AT2
driver: ixgbe
version: 3.9.15-k
firmware-version: 0x800002ee
今回調査していたサーバは上記構成です。

irqbalanceを起動時にonにしておけばintelのnicであれば綺麗に分散してます。

起動時にirqbalanceをonにしてしまえば、後でirqbalanceを止めてもきれいに分散したままになります。

ただ、起動時にirqbalanceをoffで起動するとintelのnicでも分散しないので注意です。

broadcomはirqbalanceを使っても分散しませんので、

とりあえずはintelのnicを使うことで対応するのが簡単で良いかもしれません。

あと、補足として

RPSを設定することで複数のCPUに分散出来ない場合であっても

複数のキューを有効活用することによってCPU負荷を改善させることができるようです。

echo "f" > /sys/class/net/eth0/queues/rx-0/rps_cpus

標準ではdisabledだそうです。

RFSを設定することでも改善はできるようなのですが私の環境では変化がなかったので採用していません。

この設定により1%のidleが15%のidleへと変化しました。

これにより改善はするのですが劇的な改善というほどのものではないかなという印象です。

完璧に裏が取れているというわけではありませんので、

間違いを指摘していただける方、補足いただける方はコメントいただけると助かります。

もしかしたらBroadcomのNICでもシングルプロセスでもきれいに分散できるかもしれませんので、

情報をお持ちの方宜しくお願い致します。

こちらの記事も参照ください

ps中毒

 

psといってもプレイステーションではありません。

コマンドのほうです。

シェルでログインしている最中

なぜかpsコマンドを意味なく連打し、historyを埋め尽くしちゃいます。

手が勝手に動くんです。どうしようもないんです。

職業病ですかね?

ギネスに登録されるくらpsコマンドを打っているかもしれない。

ところで、

みなさんはどんなコマンドを多用していますか?

コメントかツイートお願いします!^^

 

 

DMMのインフラの歴史②

 

さて、無事にサーバは東京への引っ越しが終わり、

右も左もわからない私たち(といっても師匠と私の二人だけ)のインフラ運用が始まります。

データセンターも「なにそれ?おいしいの?」くらいの知識で

ラックにマウントできるサーバも始めて見ました。

お手本が全くない中で

試行錯誤を繰り返しながら、まさに手探り状態で運用していた記憶があります。

そういった中でサーバのラッキング、ケーブリングを行うわけですが、

ご想像の通りめちゃくちゃ汚かったです。

現DMMの社長がその配線を見て、たまらず配線し直したというのは語り草です。

さて、話は変わりインフラ環境についてです。

記念すべき東京での最初のデータセンターは

三鷹にある某セキュリティ会社が運営するデータセンター。

SVEC箱サーバが5台で1ラックからのスタートで

回線はうろ覚えなんですが確か10Mbpsでの契約だったと思います。

さすが長嶋さんの宣伝する会社だけあってセキュリティは万全

荷物までも空港のようにX線検査が必要でした。
※荷物の検査機器があるのは後にも先にもここだけです。

OS/ミドルウェア/アプリについては

OSは雑誌付録のredhat。みんなもそうでしたよね?

ミドルウェアはapacheと

当時、dmmではreal netwaorks社のrealvideo形式のコンテンツを配信していたので、

RealServerを運用していました。

通常のコンテンツページは静的なhtmlで掲示板などはperlで作成、

決済系のアプリケーションは他社の開発したパッケージ(perl版)を利用

といった構成です。

運用についてですが、

基本的には遠隔での操作

必要に応じて東京へ出張して作業を行っていました。

ipmiもなかったですしノートパソコンも持ってなかったので、

現地での作業は出たとこ勝負。

石川に残っているホストスオールオウの師匠と電話で連絡を取りながらの作業です。

Diskがnot foundだった時は冷や汗ものでした。

こうやって前途多難な自前でのインフラ運用が始まっていきます。

お仲間いませんかね?SPF設定

 

「SPF」

差出人ドメインのなりすましを防ぐための認証技術としてSPFは一番普及しているのではないかと思います。

大手のプロバイダがこのSPFレコードを使い迷惑メールへの分類を開始していることもあり、

ほとんどの方が設定しているのではないかと思います。

SPFレコードは

SPF(type99)レコードか、SPFフォーマットのTXTレコードで公開します。

ちょっとややこしいのでdmmの例を出します。

dmm.com. 900 IN TXT “v=spf1 ip4:203.209.144.0/20 ip4:113.157.232.128/25 ip4:118.159.239.0/26 ip4:202.6.244.0/22 -all”
dmm.com. 900 IN SPF “v=spf1 ip4:203.209.144.0/20 ip4:113.157.232.128/25 ip4:118.159.239.0/26 ip4:202.6.244.0/22 -all”

上段がSPFフォーマットでTXTレコードで公開

下段がSPF(type99)レコードで公開

ほとんどのプロバイダがTXTレコードをみてなりすましの確認をしているので、

dmmでもSPFフォーマットのTXTレコードで公開しています。

が、

dmmではさらにSPF(type99)レコードでも公開するようにしています。

dnsの情報は他社のものも確認できるので各社と足並みをそろえるようにしてはいるのですが、

どうも、大手(google,twitter,facebookなどなど)ではTXTレコードしか使ってないようです。

当然、みんな設定しているものと思っていたので、

なんか、はしごを外された気分。(>_<) 私の理解ではキャッシュ問題を吸収するような余裕をもったスケジュールでSPFレコードを取り扱えばそれほどデメリットは感じられません。 今後SPF(type99)だけで確認するプロバイダも出てくると仮定しておくのが自然だと思うので、 最初から設定しておけばいいのになと思っている次第です。 何かほかにもデメリットがあるんですかね? みなさんの見解をお待ちしております。 とりあえず、dmmでは1年以上どちらも設定しているのですが特に問題ないのですが。