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

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

2013/12/31

WRX STI tS

"元RX-7乗りの適当な日々"の2013年人気エントリランキング


2013年も残すところ、あと数時間。すっかり年の瀬です。今年も当ブログへアクセスいただき、ありがとうございました。

今年も例年通り、まとめの意を込めて、当ブログでの2013年のアクセスランキングを残しておきます。


今年の当ブログへのアクセス数(PV数)を確認してみると、これまでずっと右肩上がりだったPVも、昨年(2012年)比で約19%減という結果でした。また、例年通り過去に書いたエントリへのアクセス数がそれなりに上位を占めていますので、昨年同様、2013年に書いたエントリのランキングと、ブログ全エントリに対する2013年アクセスランキングの両方を残しておきます。

ちなみに、過去のランキングは以下のエントリを。


まずは、2013年に書いたエントリに絞ったランキングBEST10から。


1. 新しい車を買いました「WRX STI tS」


2. Amazonでオライリー洋書のKindle版の一部が0円で販売中...!!


3. Linuxサーバがディスク容量不足になった!何か消さねば!ってなった時にどう対処するか


4. 自動車の複数社による同時査定で、一般ディーラー査定よりかなり高額で売却できた話+RX-7ドナドナ記録


5. iPhone5のスリープ(電源)ボタンの効きが悪くなってきたのでApple Storeへ行ってきた


6. muninの表示がクソ重くなっていたのを劇的に改善した話


7. Linux/Mac/Windowsでハードウェア構成に関する情報を調べる


8. iPhone4Sの背面ガラスの修理代が、Apple Storeで意外と安かった話


9. LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた


10. はじめてのAmazon VPC - 1. ルーターからVPCへVPN接続する


まさか1位がこのエントリとは!このブログも書き始めて8年経ち、ようやく車関連のブログになってきた気がしますw




次に、ブログ全エントリに対する2013年内のアクセスランキングです。

毎年の傾向ではありますが、2013年に書いたエントリに限らず、それ以前の過去エントリの閲覧数が全体的に非常に多くなっています。(2013年のエントリはベスト10内で1つ。)


1. 様々なLinuxのOSバージョンを確認する


2. 動画ファイル(FLV/SWF/MP4)を音声ファイル(MP3/AAC)に変換する無料サービス「Sphere MP3」


3. わずか2時間で出来た!無料でDropboxの容量を8GB増やせるチュートリアル


4. psコマンドでスレッドを表示させたり、スレッドごとのCPU使用率を確認する


5. SIMフリーのiPhone4Sをアメリカで買ってから使い始めるまでの記録


6. iPhoneのホームボタンの効きが悪くなったので、デコピンしたら本当に直った件


7. topコマンドでマルチコアなCPUの状況を確認する


8. ハネムーンで行ったタヒチの海が素晴らしすぎた件


9. Linuxでシステムに対して意図的に高負荷をかけたい場合


10. 新しい車を買いました「WRX STI tS」


次点




・・・と、2013年の当ブログはこんな感じでした。

過去のエントリの方がたくさんPVをゲットしている感じなので、来年は長く流入が期待できそうなエントリも、もうちょっと意識的に書いていこうと思いました。あとブログのタイトルを変えたものの仮タイトルのままなので、そのうち変えたいと思っています。


さて、今年はこれが最後のエントリとなります。どうぞ、来年もよろしくお願い致します。

それでは、よいお年を!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


関連リンク



2013/12/26

by slimmer_jimmer

Lsyncdのインストールと設定+α


Lsyncdを入れてみた作業メモ。環境はCentOS 6系で、Lsyncdのバージョンは2.1.4。

Lsyncdは、Linux Kernelに組みこまれているinotifyを使って、指定したディレクトリ配下で変更が加えられた場合に、ほぼリアルタイムにrsyncで(遠隔のサーバなどに)同期をかけてくれるもの。

↓の例での同期対象は、keepalivedの一部の設定ファイルと、HAProxyの設定ファイル。


同期先の設定

rsyncは特にデーモンで動かす必要も無いのですが、諸事情でデーモンで動かすことにしました。

# yum -y install rsync xinetd

yumでインストール。

次に、"/etc/xinetd.d/rsync"を開いて、以下のように編集。

disable = no

次、"/etc/rsyncd.conf"を開いて、rsyncdの設定を以下のように入れてみた。

uid = root
gid = root
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid

[keepalived]
path = /etc/keepalived
hosts allow = peer
read only = no

[haproxy]
path = /etc/haproxy
hosts allow = peer
read only = no

"hosts allow"の部分は、対向(同期元)のIPアドレスやホスト名を記載しましょう。


設定ファイルを編集したら、下記の通り、xinetdを起動します。

# /etc/init.d/xinetd start

あと、rsyncdは873番ポートを使うので、iptables等でフィルタをかけている場合は、同期元からの873ポートアクセスについては穴開けしておきましょう。


同期元の設定

LsyncdのCentOS向けのパッケージは、RepoForgeにあります。

既に上記用のyumリポジトリの設定を済ませている方は、普通に"yum install lsyncd"を。

そうでない方は、下記のようにrpmファイルをダウンロードしてインストールしちゃいましょう。

# wget http://pkgs.repoforge.org/lsyncd/lsyncd-2.1.4-1.el6.rf.x86_64.rpm
# rpm -ivh lsyncd-2.1.4-1.el6.rf.x86_64.rpm

次、"/etc/lsyncd.conf"を以下のように編集します。

settings {
    logfile    = "/var/log/lsyncd.log",
    statusFile = "/tmp/lsyncd.stat",
    statusInterval = 1,
}

sync {
    default.rsync,
    source="/etc/keepalived",
    target="peer::keepalived",
    exclude="keepalived.conf",
}

sync {
    default.rsync,
    source="/etc/haproxy",
    target="peer::haproxy",
}

シンプルにこんな感じです。ちょっと事情があって、↑の例では、excludeを使って"keepalived.conf"ファイルだけは同期対象から外しています。


あとは、以下のようにlsyncdを起動すればOKです。

# /etc/init.d/lsyncd start

問題なく起動していれば、同期元の対象のディレクトリ配下で変更を加えてみてください。数秒後には同期先にも反映されていると思います。


ちょっとだけ↑のサンプルで作った構成の話

今回は、2台でHA構成を組んだHAProxyサーバの設定ファイル同期に使いました。

イメージとしては、keepalivedでアクティブ/スタンバイのHA構成を作り、アクティブなサーバに仮想IPアドレスが振られている感じ。

xinetd + rsyncdは、アクティブ/スタンバイの2台とも起動させたままにしておき、LsyncdやHAProxyはアクティブなサーバだけで起動しているようにしました。(keepalivedの"notify_master"や"notify_backup"で制御しています。)

keepalivedまわりやHAProxyまわりの設定は、仮想IPアドレス経由で(アクティブなサーバの方に)アクセスして書き換えれば、アクティブ/スタンバイの両サーバに設定が反映できるわけですね。

もちろん、こんな感じで使うと、両方のサーバに同じ設定を記述して問題なく動かす必要があるので、そこへの注意というか工夫は必要になりますが。


とりあえず、今は↑の作業をchef-soloのRecipeに落としている。

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


参考

2013/12/25

ChefSpec利用時にChefSpec::ChefRunnerで実行中のリソースをみる


タイトルそのまんまだけど、Chefspecを使っている時に、Resourceの状態を見たい場合の話。

chef_run = ChefSpec::ChefRunner.new

とかしている場合、

p chef_run.resources

とかで標準出力に、どどーんと出してくれる。

<template[/usr/local/apache2/conf/httpd.conf] @name: "/usr/local/apache2/conf/httpd.conf" 
@noop: nil @before: nil @params: {} @provider: Chef::Provider::Template @allowed_actions: 
[:nothing, :create, :delete, :touch, :create_if_missing] @action: "create" @updated: false 
@updated_by_last_action: false @supports: {} @ignore_failure: false @retries: 0 @retry_delay: 2 
@source_line: "/opt/chef/common/apache2/recipes/default.rb:57:in `from_file'" @elapsed_time: 0 
@resource_name: :template @path: "/usr/local/apache2/conf/httpd.conf" @backup: 5 @diff: nil 
@source: "httpd.conf.erb" @cookbook: nil @local: false @variables: {} @cookbook_name: :apache2 
@recipe_name: "default" @owner: "daemon" @group: "daemon" @mode: "0644">

こんな感じ。それだけ。

メリークリスマス!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

2013/12/24

by mtlin

Amazon EC2で高速SSDを8つも搭載した新しいI2インスタンスのベンチマークをとってみた


AWS re:Inventで発表されていた、SSDによる高性能ランダムI/O用に最適化されたという、Amazon EC2の新しいインスタンスタイプ「I2インスタンス」が先日使えるようになりました。

インスタンスタイプとしては"i2.*"からはじまるやつです。

I2インスタンスタイプは、特にリレーショナルデータベース、NoSQLデータベース、およびトランザクションシステムによって生成されるI/O集約型のワークロードをホストするように設計されています。最も大きいサイズのI2インスタンスタイプは、4KBのブロックサイズでの計測で、秒間365,000を超えるランダムリードと秒間315,000を超えるランダムライトの性能を発揮します。4つのインスタンスサイズをご利用いただけますので、必要なストレージとI/O性能が高くなのに合わせて、小さくスタートし、スケールアップしていくことができます。

このインスタンスタイプはHI1インスタンスの後継にあたる第2世代のハイI/Oインスタンスタイプで、HI1インスタンスの欠けていた部分を補います。HI1インスタンスタイプと比較して、I2ファミリーは、より高速なプロセッサー、3つの追加のインスタンスサイズ、仮想CPUあたり2倍のメモリ容量、56% 多くなったSSDベースのインスタンスストレージを提供します。

Amazon Web Services ブログ: 【AWS発表】Amazon EC2 の 新インスタンスタイプ I2 が利用可能に!

これは、かなり凄そうな雰囲気が出ているので、いつものごとく軽くベンチマークをとってみることにしました。


利用できるインスタンスタイプ

上記の公式ブログより抜粋しますが、以下のような感じです。

インスタンスタイプ仮想CPU数メモリSSDの容量料金
i2.xlarge430.5GB1 x 800 GB$0.85/h
i2.2xlarge861GB2 x 800 GB$1.71/h
i2.4xlarge16122GB4 x 800 GB$3.41/h
i2.8xlarge32244GB8 x 800 GB$6.82/h

今回は最も性能の良い、SSDを8本積んでいる"i2.8xlarge"を使ってみました。


ベンチマーク方法

今回も、"fio"を使ってベンチマークをとってみます。他、Amazon Linuxを利用したり、ファイルシステムはxfsを使う等、基本的な計測方法は、以下のエントリで紹介したやり方と同じです。


尚、計測対象は、以下の4パターンです。

  • 800GBのSSD1本のデバイスに対して計測
  • 800GBのSSD2本をソフトウェアRAID0で束ねたデバイスに対して計測
  • 800GBのSSD4本をソフトウェアRAID0で束ねたデバイスに対して計測
  • 800GBのSSD8本をソフトウェアRAID0で束ねたデバイスに対して計測

ちなみにベンチマークを取るのに使ったfioコマンドとオプションは以下の6つです。

まず、上から4つは、それぞれシーケンシャルリード/ライトとランダムリード/ライト、ブロックサイズは4kで設定しています。IOPSのチェックが主目的です。

# fio -filename=/data/test5g -direct=1 -rw=read -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/test5g -direct=1 -rw=write -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/test5g -direct=1 -rw=randread -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/test5g -direct=1 -rw=randwrite -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1

あとの2つは、ブロックサイズを大きくして、主にbandwidth(転送レート)をチェックしています。

# fio -filename=/data/test5g -direct=1 -rw=read -bs=32m -size=5G -numjobs=16 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/test5g -direct=1 -rw=write -bs=32m -size=5G -numjobs=16 -runtime=16 -group_reporting -name=file1

I2インスタンス(i2.*)の起動

公式ブログにも記載がありますが、I2インスタンスを使う際は、HVM(ハードウェア仮想化マシン)用のAMIを選択する必要があります。

(最初この点を見逃していて、「あれ、I2インスタンスが選べない...!!」って探していました・・・。)

I2インスタンスは、ハードウェア仮想化 (HVM) AMIのみをサポートします。このインスタンスから最高のI/Oパフォーマンスを得るためには、Amazon Linux AMI 2013.09.02もしくは、バージョン3.8以上のカーネルを持ったLinux AMIを使う必要があります。古いバージョンのカーネルでは、I2インスタンスを使っても十分なI/O性能を発揮することができません。

Amazon Web Services ブログ: 【AWS発表】Amazon EC2 の 新インスタンスタイプ I2 が利用可能に!

f:id:rx7:20131224003344p:image:w480

AWS Management Consoleでは、↑のようにHVM imageなAmazon Linuxを選択しましょう。


f:id:rx7:20131224003345p:image:w480

すると、こんな感じで、インスタンスタイプの選択画面でI2インスタンスが選べるようになります。

何気に、"i2.8xlarge"は10Gネットワーク利用可です。


I2インスタンス(i2.8xlarge)を起動!!

↓のように、/dev/xvdb/dev/xvdiまで、800GBのSSDデバイスがズラリと並んでいるのは壮観。

# ll /dev/xvd*
brw-rw---- 1 root disk 202,   0 Dec 23 13:22 /dev/xvda
brw-rw---- 1 root disk 202,   1 Dec 23 13:22 /dev/xvda1
brw-rw---- 1 root disk 202,  16 Dec 23 13:22 /dev/xvdb
brw-rw---- 1 root disk 202,  32 Dec 23 13:22 /dev/xvdc
brw-rw---- 1 root disk 202,  48 Dec 23 13:22 /dev/xvdd
brw-rw---- 1 root disk 202,  64 Dec 23 13:22 /dev/xvde
brw-rw---- 1 root disk 202,  80 Dec 23 13:22 /dev/xvdf
brw-rw---- 1 root disk 202,  96 Dec 23 13:22 /dev/xvdg
brw-rw---- 1 root disk 202, 112 Dec 23 13:22 /dev/xvdh
brw-rw---- 1 root disk 202, 128 Dec 23 13:22 /dev/xvdi

CPUは、公称通りの Xeon E5-2670 v2 (2.50GHz) が2発!

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 62
model name      : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping        : 4
microcode       : 0x416
cpu MHz         : 2500.088
cache size      : 25600 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm xsaveopt fsgsbase smep erms
bogomips        : 5000.17
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

・・・・・が、32core分続きます・・・・・

ベンチマーク結果

以下が、SSD1本の単体と、複数のSSDデバイスをRAID0(ストライピング)で束ねた際(2, 4, 8本)のベンチマーク結果です。

IOPS
Benchmark TypeSSD x1SSD x2SSD x4SSD x8
4k, sequential read62898122407180835197893
4k, sequential write35716421504215241265
4k, randam read61290126650192157203979
4k, randam write22085375293669937269

f:id:rx7:20131224011233p:image:w480


BandWidth(帯域幅, 単位はMB/s)
Benchmark TypeSSD x1SSD x2SSD x4SSD x8
32m, sequential read468.8922.91798.23557.2
32m, sequential write462.9917.51808.83490.9

f:id:rx7:20131224011234p:image:w480


結果ですが、SSD単体でシーケンシャル/ランダムリードともに60,000IOPS超と、なかなか優秀な結果です。

IOPSについては、シーケンシャル/ランダムリードについては、4本までは、ほぼリニアな感じで性能が伸びていますが、8本になると、今回のベンチマーク環境や計測の仕方では、IOPS値が伸びませんでした。ベンチマークのやり方を変えると、また値が変わりそうな気がします。

また、シーケンシャル/ランダムライトのIOPSについては、これも今回の環境依存な気もしますが、40,000超で伸びなくなってしまいました。

公称値は、ランダムリード365,000IOPS、ランダムライト315,000IOPSなので、冬休みの宿題的な感じで時間が取れれば、FSを変えたりベンチマーク方法を少しやり直して見たいと思っています。


尚、BandWidth(帯域幅)のスループットについては、完全にリニアな感じで伸びていきました。MAXで3.5GB/secで読み書きできるわけですから、相当高速です。


↓は、RAID0でSSDデバイスを8本束ねたときの"df"の出力結果ですが、やはり驚異的なことは、20万〜30万IOPS3.5GB/secスループットの高パフォーマンスを叩き出す約6TBもの超高速ストレージが、AWSで使えるようになったということは、公式ブログにも記載がありますが、さらに可能性が大きく広がったと思います。

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  1.3G  6.6G  16% /
tmpfs                 121G     0  121G   0% /dev/shm
/dev/md0              5.9T   34M  5.9T   1% /data

ちょっと、おじさんビックリしてしまいましたが、このSSDデバイスをEBSみたいな感じで、自由な容量で好きなインスタンスで利用できるようになれば、もっとおじさんビックリ(凄そう)です!(ネットワークを介したデバイスで、このパフォーマンスを出し続けることは、難しいかもしれませんが。)

いったん今日はここまで。それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


参考



まとめ


2013/12/20

by Matt J Newman

HAProxyのパフォーマンスチューニングをやったメモ(CPS編)


HAProxyを使う上で、どうやったらパフォーマンスが上がるのかを模索するメモ。

基本的に、万能なパフォーマンスチューニングはないので、今回はCPS(Connections per Second)のパフォーマンスを上げることに焦点を絞ります。CPS(Connections per Second)は、ロードバランサの性能指標の1つとなっている数値です。


あくまで軽くやってみた過程のメモ書きみたいなものなので、まとまりもなく、まだまだ改善の余地があるとは思いますが、何かの参考にしてください。


前提

HAProxyを動かすのに使用した環境は以下の通り。

  • Server: DELL PowerEdge R420
  • CPU: Intel Xeon E5-2430L @ 2.00GHz * 2
  • Memory: 96GB
  • Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01)
    • Intel(R) 10 Gigabit PCI Express Network Driver - version 3.18.7
  • OS: CentOS 6.4 (Linux version 2.6.32-358.23.2.el6.x86_64)
  • Software: HAProxy 1.5-dev19

初期段階のHAProxyのConfig(option)は、だいたい以下のような感じ。

global
    log         127.0.0.1 local2 notice
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     131072
    user        nobody
    group       nobody
    daemon
    nbproc      1

defaults
    mode                    tcp
    log                     global
    retries                 3
    timeout queue           1m
    timeout connect         10s
    timeout client          30s
    timeout server          30s
    #timeout http-keep-alive 2s
    timeout check           10s
    maxconn                 120000

frontend hoge
    bind        *:80
    mode        tcp
    ・・・・・

backend fuga
    mode        tcp
    balance     roundrobin
    fullconn    32768
    ・・・・・

↑の前提となるデフォルト環境でまず計測

cps: 27000

haproxyの1プロセスで詰まってる感じ。


nbprocの調整

haproxy.cfgでプロセスを増やすよう以下を設定。

nbproc      2

cps: 36000

CPSが収束しない。35000〜40000付近をうろうろする感じ。


nbprocの調整 その2

haproxy.cfgで以下を設定

nbproc      4

cps: 52000

とにかくsoftirqの数が多い。TIME_WAITの数がかなり増えてきた。"tcp_max_tw_buckets"の値近く。


TIME_WAITコネクションを減らす

試しに、kernelをリビルドして、TIME_WAITコネクションの保持を短く5秒にしてみる。

cps: 47000

効果ないのでkernelを元のやつに戻す。


sysctl.confに以下のパラメータ入れて反映

根拠レスだが、以下のような感じでぶっこんでみる。

net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 32768

net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_rfc1337 = 1

net.ipv4.ip_local_port_range = 1024 65535

cps: 52000

これも、あんまり効果がなさそうなので、とりあえず設定を元に戻す。


RSSまわりの調整(MQ無効)

とにかく単一のcoreでsoftirqが高いため、ここに着手。まずは、RSSまわりを調整してみる。

"/proc/interrupts"を見ていると、24core分でRSSキューが分散されているが、大きな偏りが見られるので、1つずつ切り分けてみる。

まずはNICドライバでMQを無効にする。ixgbeモジュールに以下を設定。

options ixgbe MQ=0,0

cps: 52500

2coreでsoftirqが100%はりつき。CPSは収束しない。49000〜53000あたりをウロウロ。


RPS/RFSを設定してみる

MQを無効にしたまま、以下のような感じで4CPU core分使う感じでRPS分散。

echo "f" > /sys/class/net/bond0.88/queues/rx-0/rps_cpus
echo 32768 > /sys/class/net/bond0.88/queues/rx-0/rps_flow_cnt
echo 65536 > /proc/sys/net/core/rps_sock_flow_entries

cps: 52500

あまり結果が変わらないので、設定を元に戻す。


RSSの数を制御してみる

まずは2つずつで。ixgbeモジュールに以下を設定。

options ixgbe MQ=1,1 RSS=2,2

MQ有効にして、RSSキューを2+2に。

cps: 35000

パフォーマンス落ちた。

"/proc/interrupts"をみていると、キューが1coreに偏っているので、次はこれを手動で分散させてみることにする。


RSSキューを手動で各CPUに分散

# numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22
node 0 size: 49106 MB
node 0 free: 47674 MB
node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23
node 1 size: 49152 MB
node 1 free: 47999 MB
node distances:
node   0   1
  0:  10  20
  1:  20  10

NUMAなのでチェック。↑のような感じなので、手動で1個のCPUにRSSキューを分散させる

# /etc/init.d/irqbalance stop
# echo "2" > /proc/irq/135/smp_affinity
# echo "8" > /proc/irq/136/smp_affinity
# echo "20" > /proc/irq/138/smp_affinity
# echo "80" > /proc/irq/139/smp_affinity

cps: 52500

ふむ。でも、52500で収束して安定するようになった。次はNUMAを意識しないとどうなるか。


RSSキューを手動で各CPUに分散 その2

次に、手動でキューを2個のCPUに分散させる。

# echo "2" > /proc/irq/135/smp_affinity
# echo "4" > /proc/irq/136/smp_affinity
# echo "8" > /proc/irq/138/smp_affinity
# echo "10" > /proc/irq/139/smp_affinity

cps: 47000

やはりダメ。設定を元に戻す。


nbprocの調整 その3

haproxyのプロセスも張り付いているのでhaproxyのプロセス数を8まであげてみる

nbproc      8

cps: 53000

若干改善するも伸びず。オーバーヘッドの方が大きいのだろうか。


NICのオフロード

このへんでNICをオフロードしてみる。

# ethtool -K p2p1 rx off tx off sg off tso off gso off lro off rxvlan off txvlan off rxhash off
# ethtool -K p2p2 rx off tx off sg off tso off gso off lro off rxvlan off txvlan off rxhash off
# ethtool -K bond0 rx off tx off sg off tso off gso off lro off rxvlan off txvlan off rxhash off
# ethtool -K bond0.88 tso off gso off lro off rxvlan off txvlan off rxhash off

cps: 53000

たいして変化は無く。設定を元に戻す。


RSSの数を制御してみる その2

RSSキューをさらに増殖させる。ixgbeモジュールに以下を設定。

options ixgbe MQ=1,1 RSS=4,4

さっきの結果を踏まえて、割り当たるCPUマップを手動で分散させる。

# /etc/init.d/irqbalance stop
# echo "2" > /proc/irq/135/smp_affinity
# echo "8" > /proc/irq/136/smp_affinity
# echo "20" > /proc/irq/137/smp_affinity
# echo "80" > /proc/irq/138/smp_affinity
# echo "200" > /proc/irq/140/smp_affinity
# echo "800" > /proc/irq/141/smp_affinity
# echo "2000" > /proc/irq/142/smp_affinity
# echo "8000" > /proc/irq/143/smp_affinity

cps: 50000

結果がイマイチなので、設定を元に戻す。


nbprocの調整 その4

haproxyのプロセス数を6にしてみる

nbproc      6

cps: 55000

少しパフォーマンスアップ。


tune.bufsize増やす

たぶん関係ないけど、haproxy.cfgに設定。

tune.bufsize    131072

cps: 55000

当然変わらず。設定を元に戻す。


tune.maxacceptを調整

こちらも試しに設定変えてみる。haproxy.cfgに設定。

tune.maxaccept  -1

cps: 50000

悪化。設定を元に戻す。


InterruptThrottleRateの調整

割り込み関連というところで、このパラメータもOFFってみる。

options ixgbe MQ=1,1 RSS=2,2 InterruptThrottleRate=0,0
# /etc/init.d/irqbalance stop
# echo "2" > /proc/irq/135/smp_affinity
# echo "8" > /proc/irq/136/smp_affinity
# echo "20" > /proc/irq/138/smp_affinity
# echo "80" > /proc/irq/139/smp_affinity

cps: 53000

これも悪化。設定を元に戻す。


今回の結論

軽くやってみた感じ、今回の環境を前提とした場合、CPS優先でHAProxyをチューニングする際は、、、


options ixgbe MQ=1,1 RSS=2,2

ixgbeモジュールでMQ有効、RSSを2+2で。


# /etc/init.d/irqbalance stop
# echo "2" > /proc/irq/135/smp_affinity
# echo "8" > /proc/irq/136/smp_affinity
# echo "20" > /proc/irq/138/smp_affinity
# echo "80" > /proc/irq/139/smp_affinity

RSSキュー4つを、NUMAを考慮した上で、手動で各CPUコアに分散させ。

(と書きつつ、手動で分散させる必要性はあまり感じていないし、要らないかも。)


nbproc      6

HAProxyのプロセスを6つで稼動させる。


っていうパターンが、今回利用した環境では、CPS観点でパフォーマンスが出せる結果となった。

もちろん、使用する環境によってリソースの大小や使い方/使われ方が異なるので、↑のパラメータではなく、環境によって色々と試しながら調整する必要があります。

正直、思いつきで手当たり次第やってみた感が強いので、1つずつボトルネックを見極めて、潰していけば、もうちょっと改善できると思う。この辺は冬休みの宿題かなーと思っている。


ということで、今日はこの辺まで。それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


2013/12/19

CentOS 6系で xfsaild が "D" Stateのままになる件がFIXされていた


タイトルの件、昔twitterに書いたような気がしますが、xfsaildのステータスが"D"のままになりLAが特定の数字で張り付くことがたまにあって、あんれーと思っていたのですが、気付いたらちゃんとFIXリリースされていました。

あんまりしっかり見ていなくてすみません。。。


CentOSのkernelのsrc.rpmについているkernel.specのCHANGELOGを眺めていると、、、

CentOS 6.4
* Sat Mar 23 2013 Nikola Pajkovsky <npajkovs@redhat.com> [2.6.32-358.5.1.el6]
  - [fs] xfs: use maximum schedule timeout when ail is empty (Brian Foster) [921958 883905]

CentOS 6.5
* Tue Mar 19 2013 Jarod Wilson <jarod@redhat.com> [2.6.32-367.el6]
  - [fs] xfs: use maximum schedule timeout when ail is empty (Brian Foster) [883905]

と、記載がありました。

"2.6.32-358.5.1.el6"で取り込まれているので、CentOS 6.4のupdateにある"kernel-2.6.32-358.6.1.el6"このバージョン以降、もしくはCentOS 6.5でFIXされているということですね。ありがたい!

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


参考

6.5 Technical Notes - 8.82. kernel
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.5_Technical_Notes/kernel.html

2013/12/18

by QueenieVonSugarpants

pipで管理しているパッケージを一括でアップデートする


StackOverflowのウケウリです。これ。


やり方を大きく分けると、以下の2通り。

  • pip-toolsを使う
  • ワンライナーを書いて実行

個人的には、動作保障的な意味で、全パッケージのバージョンを一括でアップデートすることはそうないのですがwそれぞれ、メモがてらやり方を書いておきます。


pip-toolsを使う (追記有り)

まず、pipを使ってサクっとインストールします。

$ sudo pip install pip-tools

2015/11/30 追記

下記の pip-review コマンドは、既に pip-tools から削除された機能となっています。

現在は、そこから派生・独立していて、以下手順でインストールできます。

$ sudo pip install pip-review

インストールできたら、以下のように"pip-review"コマンドを実行すると、PyPIリポジトリをチェックして、アップデート可能なパッケージをリスト的な感じでレポーティングしてくれます。

$ pip-review
Django==1.6.1 is available (you have 1.5.4)
Mako==0.9.0 is available (you have 0.8.1)
MarkupSafe==0.18 is available (you have 0.15)
PAM==0.1.4 is available (you have 0.4.2)
Pillow==2.2.1 is available (you have 2.0.0)
SecretStorage==1.1.0 is available (you have 1.0.0)
No update information found for Twisted-Core
No update information found for Twisted-Names
No update information found for Twisted-Web
No update information found for adium-theme-ubuntu
No update information found for apt-xapian-index
awscli==1.2.8 is available (you have 0.13.2)
bcdoc==0.12.0 is available (you have 0.5.0)
boto==2.20.1 is available (you have 2.9.6)
botocore==0.28.0 is available (you have 0.13.1)

で、以下のように"--auto"オプションをつけて実行すると、一括で全パッケージをアップデートしてくれます。

$ sudo pip-review --auto

"--interactive"オプションをつけると、言葉の通りですが、インタラクティブな感じでパッケージごとにアップグレードするかしないかを聞いてくれます。([A]ll を選択すると、全てアップグレードされます。)

$ sudo pip-review --interactive
Django==1.6.1 is available (you have 1.5.4)
Upgrade now? [Y]es, [N]o, [A]ll, [Q]uit 

・・・・・以下略・・・・・

ワンライナーを書いて実行

# pip freeze --local | grep -v '^\-e' | cut -d = -f 1  | xargs pip install -U

これを実行するだけで良い、と。


一応、予期せぬことが起こるのもアレなので、pip-toolsを入れて、pip-reviewで状況を確認してから、バージョンをあげていくのがよいかなとは思います。まぁ、お好みですかね。

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


2013/12/05

by edwin van buuringen

HAProxyを透過型のプロキシとして使う(HAProxy with tproxy)


HAProxyは基本的にL7レイヤのロードバランサー(リバースプロキシ)なので、バックエンドにいるリアルサーバには、フロントエンドから届いたリクエストが、ロードバランサのIPアドレスからアクセスが来たかのように振舞います。


で、HAProxyはtproxy(transparent proxy)をサポートしているようなので、L4で動く透過型のプロキシとしても振舞うことが出来るようです。ので、ちょっと試してみました。

使ったOSは、CentOS 6.4で、HAProxyは開発版の1.5-dev19です。


参考: Transparent proxy support (www.kernel.org/doc)

Linux kernelのnf_tproxy_coreモジュールをロードする

ここからは、実際にHAProxyの稼動するサーバに対してのセットアップを行います。


まず、tproxy関連のモジュールのロードが必要です。

今回使ったCentOS 6.4には既に組み込まれていたので、ロードするだけです。

# modprobe -l | grep tproxy
kernel/net/netfilter/nf_tproxy_core.ko

tproxy関連のモジュールを探してみるとありました。"nf_tproxy_core" これっぽい。


# modinfo nf_tproxy_core
filename:       /lib/modules/2.6.32-358.18.1.el6.x86_64/kernel/net/netfilter/nf_tproxy_core.ko
description:    Transparent proxy support core routines
author:         Krisztian Kovacs
license:        GPL
srcversion:     C0E2C4553F0913555683F1E
depends:
vermagic:       2.6.32-358.18.1.el6.x86_64 SMP mod_unload modversions

Transparent proxy support core routines」とあります。


# modprobe nf_tproxy_core

このモジュールをロードして、、、


# lsmod | grep tproxy
nf_tproxy_core          1332  0 [permanent]

組み込まれました。


HAProxy側の確認

開発版(1.5-dev19)で確認する限り、デフォルトのままビルドしても、以下の通り "haproxy -vv"を実行すると、、、

Built with transparent proxy support using: IP_TRANSPARENT IP_FREEBIND

transparent proxy support using の文字列が見えます。


一応、HAProxyをビルドする際に "USE_LINUX_TPROXY=1" のフラグを立ててビルドしたら、以下のようになりました。

Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND

一応、今回はIPv6環境下での確認もしたかったので、↑でいきます。


カーネルパラメータの設定

"/etc/sysctl.conf"に以下の設定を入れます。(利用しているインターフェース名を考慮して適宜書き換えてください。)

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0

iptables / route の設定

ドキュメントの通りではありますが、以下のようにiptablesと、ip rule、ip routeの設定を入れます。

# iptables -t mangle -N DIVERT
# iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
# iptables -t mangle -A DIVERT -j MARK --set-mark 1
# iptables -t mangle -A DIVERT -j ACCEPT

と、

# ip rule add fwmark 1 lookup 100
# ip route add local 0.0.0.0/0 dev lo table 100

"/etc/sysconfig/iptables"的には以下のような感じですね。

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:DIVERT - [0:0]
-A PREROUTING -p tcp -m socket -j DIVERT
-A DIVERT -j MARK --set-mark 1
-A DIVERT -j ACCEPT
COMMIT

HAProxy の設定

最後に、"/etc/haproxy/haproxy.cfg"に以下の設定を入れます。

source  0.0.0.0  usesrc  clientip

この一行を、listenとかbackendの部分に入れておけばOKです。


動作確認

では、実際に動かしてtcpdumpでパケットの動きを眺めてみます。試した構成は、

Client <=> HAProxy <=> Real Server

になります。ClientとなるマシンからHAProxyのマシンが持つVIP(仮想IPアドレス)にリクエストを投げて、それをHAProxyがバックエンドのReal Serverへ渡す一般的な構成です。

バックエンドのReal Serverのインターフェースのところで、tcpdumpを動かしてキャプチャした結果が以下です。


通常時(tproxy設定なし)
17:58:42.554387 IP haproxy.54544 > real-server.http: Flags [S], seq 1028255911, win 14600, options [mss 1460,sackOK,TS val 800508775 ecr 0,nop,wscale 7], length 0
17:58:42.554405 IP real-server.http > haproxy.54544: Flags [S.], seq 4019287287, ack 1028255912, win 65160, options [mss 1460,sackOK,TS val 11233434 ecr 800508775,nop,wscale 12], length 0
17:58:42.554598 IP haproxy.54544 > real-server.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 800508775 ecr 11233434], length 0
17:58:42.554647 IP haproxy.54544 > real-server.http: Flags [P.], seq 1:168, ack 1, win 115, options [nop,nop,TS val 800508775 ecr 11233434], length 167
17:58:42.554653 IP real-server.http > haproxy.54544: Flags [.], ack 168, win 16, options [nop,nop,TS val 11233434 ecr 800508775], length 0
17:58:42.554793 IP real-server.http > haproxy.54544: Flags [P.], seq 1:216, ack 168, win 16, options [nop,nop,TS val 11233435 ecr 800508775], length 215
17:58:42.554828 IP real-server.http > haproxy.54544: Flags [P.], seq 216:237, ack 168, win 16, options [nop,nop,TS val 11233435 ecr 800508775], length 21
17:58:42.554991 IP haproxy.54544 > real-server.http: Flags [.], ack 216, win 123, options [nop,nop,TS val 800508776 ecr 11233435], length 0
17:58:42.555015 IP haproxy.54544 > real-server.http: Flags [.], ack 237, win 123, options [nop,nop,TS val 800508776 ecr 11233435], length 0
17:58:42.555407 IP haproxy.54544 > real-server.http: Flags [F.], seq 168, ack 237, win 123, options [nop,nop,TS val 800508776 ecr 11233435], length 0
17:58:42.555426 IP real-server.http > haproxy.54544: Flags [F.], seq 237, ack 169, win 16, options [nop,nop,TS val 11233435 ecr 800508776], length 0
17:58:42.555725 IP haproxy.54544 > real-server.http: Flags [.], ack 238, win 123, options [nop,nop,TS val 800508776 ecr 11233435], length 0

バックエンドの実サーバ的には、HAProxyのホストからアクセスがきているように見えます。L7リバースプロキシの挙動としては普通の状態ですね。


透過設定時(tproxy設定あり)
17:59:28.514936 IP client.42447 > real-server.http: Flags [S], seq 3757471154, win 14600, options [mss 1460,sackOK,TS val 800554735 ecr 0,nop,wscale 7], length 0
17:59:28.514969 IP real-server.http > client.42447: Flags [S.], seq 2578532225, ack 3757471155, win 65160, options [mss 1460,sackOK,TS val 11279395 ecr 800554735,nop,wscale 12], length 0
17:59:28.515320 IP client.42447 > real-server.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 800554736 ecr 11279395], length 0
17:59:28.515337 IP client.42447 > real-server.http: Flags [P.], seq 1:168, ack 1, win 115, options [nop,nop,TS val 800554736 ecr 11279395], length 167
17:59:28.515343 IP real-server.http > client.42447: Flags [.], ack 168, win 16, options [nop,nop,TS val 11279395 ecr 800554736], length 0
17:59:28.515458 IP real-server.http > client.42447: Flags [P.], seq 1:216, ack 168, win 16, options [nop,nop,TS val 11279395 ecr 800554736], length 215
17:59:28.515485 IP real-server.http > client.42447: Flags [P.], seq 216:237, ack 168, win 16, options [nop,nop,TS val 11279395 ecr 800554736], length 21
17:59:28.515838 IP client.42447 > real-server.http: Flags [.], ack 216, win 123, options [nop,nop,TS val 800554736 ecr 11279395], length 0
17:59:28.515844 IP client.42447 > real-server.http: Flags [.], ack 237, win 123, options [nop,nop,TS val 800554736 ecr 11279395], length 0
17:59:28.516162 IP client.42447 > real-server.http: Flags [F.], seq 168, ack 237, win 123, options [nop,nop,TS val 800554737 ecr 11279395], length 0
17:59:28.516181 IP real-server.http > client.42447: Flags [F.], seq 237, ack 169, win 16, options [nop,nop,TS val 11279396 ecr 800554737], length 0
17:59:28.516396 IP client.42447 > real-server.http: Flags [.], ack 238, win 123, options [nop,nop,TS val 800554737 ecr 11279396], length 0

この通り、HAProxyを介していますが、バックエンドの実サーバ的にも、どのクライアントからアクセスが来たのかわかるようになりました。


注意点

Client <=> HAProxy <=> Real Server

色々やってみたのですが、今回のこの構成では、"Client 〜 HAProxy"のネットワークと"HAProxy 〜 Real Server"のネットワークが別セグメントで、Real ServerからClientの戻りパケットをHAProxyのマシンを介す(つまり、ルーティング上、Clientのいるネットワーク宛のゲートウェイをHAProxyのホストにする)ようなパターンで、きちんと動きました。

Client、HAProxy、Real Serverが同じネットワークセグメントにいると動かなかったです。(正確にはパケットは戻るのですが、Real ServerからClientにSYN ACKが戻りRSTが返されるような状態。)

Real Serverのところを小細工すれば何とかなるような気がしなくも無いですが、あまり手を入れて複雑にはしたくない気もする。


と、こんな感じで軽く検証しただけで、ドキュメントとかユーザ事例をまだちゃんと追えてないので、何ともいえないですが、何か分かれば追記したいと思います。

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


参考リンク


2013/12/04

by Dalo_Pix2

TIME_WAIT状態のTCPコネクションを早く終了させるべくKernelをリビルド


以前、一度やったはずなのですが、すっかり忘れてしまっていて、結局調べることになったので、今回はここに作業ログを残しておきます。


TIME_WAITコネクションの増殖

一般的にネットワークアクセス数が極端に多いサーバでは、TIME_WAIT状態のコネクションが残留しがちです。

TIME_WAITの滞留時間が、Linuxデフォだと60秒になっているため、下記のエントリにも書きましたが、60秒の間に数十万レベルのリクエストが来るとあっという間にコネクションテーブルが埋まっていってしまうわけです。


で、別にTIME_WAITコネクションが多くなってしまうこと自体は、完全な悪というわけでもなく、 "net.ipv4.tcp_max_tw_buckets" あたりでキャップもできるし、それなりに制御して付き合っていけばいいわけですが、ローカルのTCPポートを使い切るようなケースだと、使えるローカルポートレンジは限られているので困ったりするパターンもあります。


そういえば昔、↑のエントリのような状況に出くわして、この時は諸事情で(NATしている構成ではなかったので) "net.ipv4.tcp_tw_recycle" を設定することで、TIME_WAITとなったTCPコネクションを再利用することで事なきを得たのですが、今回は検証の都合上、Linux Kernelをビルドして、TIME_WAITのコネクションが解放される時間(デフォルト: 60秒)を短くしてみます。


OS(今回の環境例)

今回使った検証環境でのサーバのOSは、LinuxのCentOS 6.4でした。

# cat /proc/version
Linux version 2.6.32-358.23.2.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Wed Oct 16 18:37:12 UTC 2013

こんな感じ。


カーネルのソースパッケージをゲットする

せっかくCentOSを使っていることもあって、公開されているカーネルのソースパッケージを取得します。

上記サイトから、該当するバージョンのリリースノートを読むと、ソースパッケージの記載場所が書いてありますので、そこからダウンロードしましょう。


CentOS 6.4だと、以下のリリースノート箇所に書いてあります。

以下のUpdateリポジトリあたりから、自分のカーネルバージョンと一致しているソースパッケージを入手します。


今回の例だと、↑の通り "/proc/version" でKernelのバージョンが "2.6.32-358.23.2.el6.x86_64" とわかりますので、以下コマンドみたいな感じでダウンロードして展開します。

# wget http://vault.centos.org/6.4/updates/Source/SPackages/kernel-2.6.32-358.23.2.el6.src.rpm
# rpm -ivh kernel-2.6.32-358.23.2.el6.src.rpm

Kernelのソースコードをちょこっと修正

本来であれば、きちんとパッチ(patch)を作成すべきなのですが、今回は検証が目的だったこともあって(面倒くさいので)、tarballを展開して直接変更を加えることにします。。。


# cd ~/rpmbuild/SOURCES/
# cp linux-2.6.32-358.23.2.el6.tar.bz2 /tmp

ソースパッケージをインストールすると、"~/rpmbuild/SOURCES/"にtarファイルが展開されるので、それを/tmpにコピーしちゃいます。


# cd /tmp
# tar xjvf linux-2.6.32-358.23.2.el6.tar.bz2

/tmpに移動して展開。


mv linux-2.6.32-358.23.2.el6 linux-2.6.32-358.23.3.namibuild.el6

ディレクトリファイル名を適当に変えてみました。

(更新番号をインクリメントして、野良ビルドしたので適当に文字列をくっつけました。)


cd linux-2.6.32-358.23.3.namibuild.el6

カレントディレクトリを変えて、以下のような感じでファイルを修正。


# diff -c Makefile{.bak,}
*** Makefile.bak        2013-11-19 16:56:31.272668572 +0900
--- Makefile    2013-11-19 16:57:03.889668546 +0900
***************
*** 1,7 ****
  VERSION = 2
  PATCHLEVEL = 6
  SUBLEVEL = 32
! EXTRAVERSION =
  NAME = Man-Eating Seals of Antiquity
  RHEL_MAJOR = 6
  RHEL_MINOR = 4
--- 1,7 ----
  VERSION = 2
  PATCHLEVEL = 6
  SUBLEVEL = 32
! EXTRAVERSION = -358.23.3.namibuild.el6.x86_64
  NAME = Man-Eating Seals of Antiquity
  RHEL_MAJOR = 6
  RHEL_MINOR = 4
# diff -c include/net/tcp.h{.bak,}
*** include/net/tcp.h.bak       2013-11-19 16:59:19.386668435 +0900
--- include/net/tcp.h   2013-11-19 16:59:38.649668421 +0900
***************
*** 111,118 ****
                                 */


! #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
!                                 * state, about 60 seconds     */
  #define TCP_FIN_TIMEOUT       TCP_TIMEWAIT_LEN
                                   /* BSD style FIN_WAIT2 deadlock breaker.
                                  * It used to be 3min, new value is 60sec,
--- 111,118 ----
                                 */


! #define TCP_TIMEWAIT_LEN (2*HZ) /* how long to wait to destroy TIME-WAIT
!                                 * state, about 2 seconds      */
  #define TCP_FIN_TIMEOUT       TCP_TIMEWAIT_LEN
                                   /* BSD style FIN_WAIT2 deadlock breaker.
                                  * It used to be 3min, new value is 60sec,

上記2ファイルですね。"include/net/tcp.h"の"TCP_TIMEWAIT_LEN"の変数が、今回変更を加えたい該当箇所になります。

設定値は、ケースに応じて吟味すべきですが、今回は↑の如く、検証内容的に2秒にしました。(短いw)


# cd ..
# tar cjvf linux-2.6.32-358.23.3.namibuild.el6.tar.bz2 linux-2.6.32-358.23.3.namibuild.el6

修正後、固めなおして、、、


# cp linux-2.6.32-358.23.3.namibuild.el6.tar.bz2 ~/rpmbuild/SOURCES/

固めたtarファイルを "~/rpmbuild/SOURCES/" にコピーします。


# cd ~/rpmbuild/SPECS/
# diff -c kernel.spec{.bak,}
*** kernel.spec.bak     2013-11-19 17:02:26.605668280 +0900
--- kernel.spec 2013-11-19 17:03:02.633668255 +0900
***************
*** 19,25 ****

  %define rhel 1
  %if %{rhel}
! %define distro_build 358.23.2
  %define signmodules 1
  %else
  # fedora_build defines which build revision of this kernel version we're
--- 19,25 ----

  %define rhel 1
  %if %{rhel}
! %define distro_build 358.23.3.namibuild
  %define signmodules 1
  %else
  # fedora_build defines which build revision of this kernel version we're
***************
*** 171,177 ****
  %endif

  # The kernel tarball/base version
! %define kversion 2.6.32-358.23.2.el6

  %define make_target bzImage

--- 171,177 ----
  %endif

  # The kernel tarball/base version
! %define kversion 2.6.32-358.23.3.namibuild.el6

  %define make_target bzImage

***************
*** 562,568 ****
  %define strip_cmd strip
  %endif

! Source0: linux-2.6.32-358.23.2.el6.tar.bz2

  Source1: Makefile.common

--- 562,568 ----
  %define strip_cmd strip
  %endif

! Source0: linux-2.6.32-358.23.3.namibuild.el6.tar.bz2

  Source1: Makefile.common

更新番号とかを変更しているので、上記のような感じで、specファイルを修正。

ここまでで、修正作業は終わりです。次はビルドでございます。


独自カーネルをビルドする

さて、ビルドすべくrpmbuildコマンドを実行すると、、、

# rpmbuild -ba kernel.spec
エラー: ビルド依存性の失敗:
        redhat-rpm-config は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        patchutils は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        xmlto は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        asciidoc は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        binutils-devel は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        newt-devel は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        python-devel は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        perl(ExtUtils::Embed) は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        bison は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        flex は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています
        hmaccalc は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています

依存関係で諸々足りないパッケージを指摘されるので、、、


yum -y install redhat-rpm-config patchutils xmlto asciidoc binutils-devel newt-devel python-devel perl-ExtUtils-Embed bison flex hmaccalc

yumでインストール。


# rpmbuild -ba kernel.spec

で、再ビルド。

実行マシンにもよりますが、カーネルのビルドは結構時間がかかりますので、気長に待ちましょう。


gpg: keyring ...のところから進まない


ひょっとしたら、以下の箇所で処理が全然すすまなくなるかもしれません。

###
### Now generating a PGP key pair to be used for signing modules.
###
### If this takes a long time, you might wish to run rngd in the background to
### keep the supply of entropy topped up.  It needs to be run as root, and
### should use a hardware random number generator if one is available, eg:
###
###     rngd -r /dev/hwrandom
###
### If one isn't available, the pseudo-random number generator can be used:
###
###     rngd -r /dev/urandom
###
+ gpg --homedir . --batch --gen-key /root/rpmbuild/SOURCES/genkey
gpg: WARNING: unsafe permissions on homedir `.'
gpg: keyring `./secring.gpg' created
gpg: keyring `./pubring.gpg' created

そんな時はですね、別シェル(ターミナル)を立ち上げて、、、


# rngd -r /dev/urandom

上記コマンドを実行してentropyを供給。


# rngd -r /dev/urandom
-bash: rngd: コマンドが見つかりません

もし、コマンドがない、って出力されたときは、、、


# yum -y install rng-tools
# rngd -r /dev/urandom

インストールして再実行してみましょう。


ビルドが終わったらインストール、、、だが

ビルドが終わると、"~/rpmbuild/RPMS/x86_64/"にrpm一式が出来ているはずです。

# cd ../RPMS/x86_64/
# rpm -Uvh kernel-2.6.32-358.23.3.namibuild.el6.x86_64.rpm kernel-devel-2.6.32-358.23.3.namibuild.el6.x86_64.rpm kernel-headers-2.6.32-358.23.3.namibuild.el6.x86_64.rpm
エラー: 依存性の欠如:
        kernel-firmware >= 2.6.32-358.23.3.namibuild.el6 は kernel-2.6.32-358.23.3.namibuild.el6.x86_64 に必要とされています

なので、こんな感じでインストールしようとするも、"kernel-firmware"がない、と(TT)


# cd ../../SPECS/
# rpmbuild -bb --with firmware kernel.spec

というわけで、再ビルド。しばし待つ。(要するに、最初から↑のコマンドを実行すると良いです。。。)


# cd ../RPMS/x86_64/
# rpm -Uvh kernel-2.6.32-358.23.3.namibuild.el6.x86_64.rpm kernel-devel-2.6.32-358.23.3.namibuild.el6.x86_64.rpm kernel-headers-2.6.32-358.23.3.namibuild.el6.x86_64.rpm kernel-firmware-2.6.32-358.23.3.namibuild.el6.x86_64.rpm
準備中...                ########################################### [100%]
   1:kernel-firmware        ########################################### [ 25%]
   2:kernel                 ########################################### [ 50%]
   3:kernel-headers         ########################################### [ 75%]
   4:kernel-devel           ########################################### [100%]

さて、やっとこさ独自ビルドしたカーネルがインストールできました。

というところで、OSを再起動します。


# cat /proc/version
Linux version 2.6.32-358.23.3.namibuild.el6.x86_64 (root@haproxy-test01) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Tue Nov 19 17:35:29 JST 2013

再起動後、ちゃんと起動してきて、独自カーネルに変わっていればOKです。


動作確認

クライアントから適当に接続要求しまくって、どうなったかを netstat で確認してみます。


Before...
# netstat -anpto
・・・・・省略・・・・・

tcp        0      0 10.50.1.62:80               10.33.56.163:47769          TIME_WAIT   -                   timewait (8.40/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.171:4649           TIME_WAIT   -                   timewait (9.04/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.111:11322          TIME_WAIT   -                   timewait (0.00/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.189:42672          TIME_WAIT   -                   timewait (25.83/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.151:1175           TIME_WAIT   -                   timewait (38.93/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.190:12461          TIME_WAIT   -                   timewait (25.89/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.61:2089            TIME_WAIT   -                   timewait (26.19/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.45:23837           TIME_WAIT   -                   timewait (25.44/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.59:30782           TIME_WAIT   -                   timewait (40.56/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.167:61432          TIME_WAIT   -                   timewait (53.22/0/0)

・・・・・省略・・・・・

After!!!
# netstat -anpto
・・・・・省略・・・・・

tcp        0      0 10.50.1.62:80               10.33.56.85:48327           TIME_WAIT   -                   timewait (0.71/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.55:37193           TIME_WAIT   -                   timewait (0.18/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.41:28099           TIME_WAIT   -                   timewait (0.34/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.33:2009            TIME_WAIT   -                   timewait (0.04/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.76:15310           TIME_WAIT   -                   timewait (0.38/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.15:41482           TIME_WAIT   -                   timewait (0.17/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.34:39958           TIME_WAIT   -                   timewait (1.76/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.97:36784           TIME_WAIT   -                   timewait (0.89/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.74:53628           TIME_WAIT   -                   timewait (1.95/0/0)
tcp        0      0 10.50.1.62:80               10.33.56.94:5927            TIME_WAIT   -                   timewait (0.82/0/0)

・・・・・省略・・・・・

上記の通りですが、Beforeでは53秒とか滞留しているコネクションがありましたが、Afterでは設定した2秒以内におさまっています。


と、簡単ではありますが、こんな感じでTIME_WAITコネクションの数を減らすことができました。

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


2013/12/03

by Kamal Wijeratna

Zenbackを外した結果


ちょうど2ヶ月前の話ですが、ブログパーツとしてつけさせてもらっていたZenbackを外すことにしました。

と、同時に外部サービスへのリンクが多かったので、整理もかねて、少しリンクを外しました。


単純に外したらどう変わるのかなぁ、という興味本位が一番大きいのですが、Googleの検索結果で、Zenbackキーワーズのサイトがオリジナルより上位に来るケースが多かったのがちょっと...というのと、ブログの読み込み時間に影響を与えつつあったこと、らへんが主な理由です。

Zenback関連からの流入は月あたり1000UUちょっとだったので、試しに一度外してみることにしました。


そこから2ヶ月たって、、、結果としてこのブログでは、アクセス数的に見ると数字的には、それほど何も変わっていません

Zenbackのブログパーツをつけていることで、多少の流入と、 キーワーズ(zenback.itmedia.co.jp)から被リンクがもらえるので、SEO的には有利なのかなと思いますが、あってもなくてもそれほど変わらないのであれば、しばらくこのまま様子見してみようかなと思っています。


Zenbackを削除するには

  • 自サイトのブログパーツを外す。
  • Zenbackの管理サイトで、自サイトのブログ情報を削除する

この2つでOKみたいです。


ただし、Zenbackキーワーズのキャッシュはしばらく残り続けるみたいで、

Zenbackをはずした場合には、自動キャッシュ更新のタイミングでzenbackキーワーズへの掲載も削除されます。

自動キャッシュ更新には時間がかかりますので、手動での対応をご希望の場合は、お問い合わせください。

no title

とのことなので、手動での削除をお願いする場合は「no title」に記載されているお問い合わせ先から依頼するとやってもらえます。

私が問い合わせたときは、営業時間内だったからか、依頼から2時間ほどでやってもらえました。(早い!)

しかも、Googleキャッシュの削除リクエストもあわせてやっていただけます。(素晴らしい!)


と、今日はこの辺で。それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́



Thanks!! 8000000views!!

エントリの内容とは全く無関係ですが、本ブログがの累計PVが800万に到達しました!いつもありがとうございます。

700万PV到達(d:id:rx7:20130725:p1)から、約6ヶ月での到達でした。これからもよろしくお願い致します。

2013/12/02

by carianoff

HAProxyでSSL処理をできるようにする


ロードバランサとかリバースプロキシを使って色々やっていると、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"以降のバージョンであれば使えそう。

ということで、前回のエントリ「HAProxy1.5系(開発版)のRPMを作成する」の続きですが、SSL対応版のHAProxyをインストールして、確認してみようと思いまする。


SSL対応版のHAProxyをビルド

上記のエントリで、HAProxyのRPMファイルを作りましたが、この環境を使ってRPMを作り直すところからはじめてみます。

(ディレクトリ構成やファイルなんかは、↑のエントリを参考にしてください。)


といってもRPMを作った環境があれば、specファイル(rpmbuild/SPECS/haproxy.spec)の修正がメインですw

# diff -c haproxy.spec{.bak,}
*** haproxy.spec.bak    2013-11-28 18:46:38.722931990 +0900
--- haproxy.spec        2013-11-29 15:30:52.222283278 +0900
***************
*** 1,13 ****
  Summary: HA-Proxy is a TCP/HTTP reverse proxy for high availability environments
  Name: haproxy
! Version: 1.5-dev19
! Release: 1
  License: GPL
  Group: System Environment/Daemons
  URL: http://haproxy.1wt.eu/
  Source0: http://haproxy.1wt.eu/download/1.5/src/devel/%{name}-%{version}.tar.gz
  BuildRoot: %{_tmppath}/%{name}-%{version}-root
! BuildRequires: pcre-devel
  Requires: /sbin/chkconfig, /sbin/service

  %description
--- 1,13 ----
  Summary: HA-Proxy is a TCP/HTTP reverse proxy for high availability environments
  Name: haproxy
! Version: 1.5_dev19
! Release: 2
  License: GPL
  Group: System Environment/Daemons
  URL: http://haproxy.1wt.eu/
  Source0: http://haproxy.1wt.eu/download/1.5/src/devel/%{name}-%{version}.tar.gz
  BuildRoot: %{_tmppath}/%{name}-%{version}-root
! BuildRequires: pcre-devel, openssl-devel
  Requires: /sbin/chkconfig, /sbin/service

  %description
***************
*** 33,39 ****
  %define __perl_requires /bin/true

  %build
! %{__make} USE_PCRE=1 DEBUG="" ARCH=%{_target_cpu} TARGET=linux26

  %install
  [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}
--- 33,39 ----
  %define __perl_requires /bin/true

  %build
! %{__make} USE_PCRE=1 DEBUG="" ARCH=%{_target_cpu} TARGET=linux26 USE_OPENSSL=1

  %install
  [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}

こんな感じで %buildのところで"USE_OPENSSL=1"とフラグをたててビルドするようにすればOKです。

あと、当然ながらopenssl-develが必要になりますので、BuildRequires に書いておくようにしましょう。

(できることならCHANGELOGも更新しておきましょう...汗)


# cd ~/rpmbuild/SPECS/
# rpmbuild -ba haproxy.spec

"rpmbuild/SOURCES"にHAProxyのtarballが配置してあれば、あとはビルド!です。


SSL対応版のHAProxyをインストール

# rpm -Uvh ~/rpmbuild/RPMS/x86_64/haproxy-1.5_dev19-2.x86_64.rpm
準備中...                ########################################### [100%]
   1:haproxy                ########################################### [100%]

まずはインストール(もしくはアップデート)。


# haproxy -vv
HA-Proxy version 1.5-dev19 2013/06/17
Copyright 2000-2013 Willy Tarreau <w@1wt.eu>

Build options :
  TARGET  = linux26
  CPU     = generic
  CC      = gcc
  CFLAGS  = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing
  OPTIONS = USE_OPENSSL=1 USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built without zlib support (USE_ZLIB not set)
Compression algorithms supported : identity
Built with OpenSSL version : OpenSSL 1.0.0-fips 29 Mar 2010
Running on OpenSSL version : OpenSSL 1.0.0-fips 29 Mar 2010
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 7.8 2008-09-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with transparent proxy support using: IP_TRANSPARENT IP_FREEBIND

Available polling systems :
      epoll : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

きちんとSSLが組み込まれていることが確認できます。


(オレオレSSL証明書を作る)

ここで、SSL証明書が必要になります。

既に持っている方はそれを使いましょう。そうじゃない方はとりあえずテストなのでオレオレ証明書を作りましょう。

# openssl genrsa 2048 > server.key
# openssl req -new -key server.key > server.csr
# openssl x509 -days 730 -req -signkey server.key < server.csr > server.crt
# cat server.key server.crt > server.pem

こんな感じでコマンドを発行すれば、有効期間が2年のオレオレSSL証明書のできあがりです。チーン

今回使うのは、"server.pem"になるので、適当な場所(/etc/haproxy配下とか)に配置してください。


haproxy.cfgの設定

"/etc/haproxy/haproxy.cfg"を修正します。


・・・・・省略・・・・・

frontend ssl-proxy
    bind    *:443 ssl crt /etc/haproxy/server.pem
    mode    http
    default_backend  web-servers

・・・・・省略・・・・・

HAProxyの基礎的な設定部分は省略しますが、443ポートでbindするfrontendを以下のような感じで作るだけです。backendは特に修正する(意識する)必要はありません。

frontendでSSL処理をするので、backendのサーバは、80番ポート(ふつーのHTTP)で待ち受けていればOKです。


あとは、haproxyをreloadするなりして、設定を反映すればOKです。


動作確認

お好みでどうぞ。

# curl -I -k https://localhost/
HTTP/1.1 200 OK

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

うまく動きました!


その他パラメータなど

HAProxy 1.5-dev用のConfiguration Manualが下記で公開されているので、これが参考になります。

普通の話ですが、"SSL"とかのキーワードでひっかけると追いやすいです。


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


オススメ (一部は、最近読んでいる本とも言う)
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ムックシリーズ)