Author Archive

{ 2012.4.28 }

インフラ勉強会＠福岡でWakameについて話してきました

    category：linux｜author：｜tag：, ｜comment：non

    はてなブックマーク - インフラ勉強会＠福岡でWakameについて話してきました
    このエントリーをはてなブックマークに追加

    Fusic 平田です。
    インフラ勉強会＠福岡に参加してきました。
    で、行くなら喋ろうってことでWakameのお話。

    ※ Ustの録画をしそこねておりました。大変申し訳ありません。。。
    補足情報は、以下のような感じです。
    ・OpenFlow対応が追加されている
    # 参考: www.slideshare.net/yasuhiro_yamazaki/openflow-in-iaas-wakame
    ・対応ハイパーバイザにESXiとOpenVZが追加された
    ・Gentooへのインストールスクリプトが追加された

    Wakameいいよーいいよーってのをもっとわかりやすく説明するために、いろいろ実験中です。
    これについてはまた別途エントリ書くようにします。

    他の方の発表は以下の通り。

    Spring_MTさん: MySQL Casual Talks Vol.3の話、など
    # 参考: spring-mt.tumblr.com/post/21638089137/mysql-casual-talks-vol-3-lt
    参加しましたって話と、それに絡んでMySQLやRailsの話。
    いろいろ勉強会やりたい！と画策してらっしゃるようで、楽しみにしております。

    take_3さん: 東京こわいいろいろ勉強会に参加した話などなど
    特に場が騒然としたのが、x86/x64最適化勉強会の話。
    最近のCPUだと、慣例どおりのコード書いてたら分岐予測でコスト浪費するんだよってなにそれこわいすごいってな雰囲気でした。
    あとは、「などなど」とまとめましたが多方面にわたるいろいろなお話。

    あとはバックアップの話とか冗長化の話とか、あれこれいろいろ話してそのまま懇親会に移動。
    技術の話やらそうでもない話やらで大いに盛り上がりました。Excelは言語だよね、とか。
    次回もぜひ参加させていただきたいですね。

    { Page Top }

    { 2012.4.14 }

    iptablesを利用してVPN接続を共有(?)してみる話

      category：Network｜author：｜tag：｜comment：non

      はてなブックマーク - iptablesを利用してVPN接続を共有(?)してみる話
      このエントリーをはてなブックマークに追加

      Fusic 平田です。

      前提

      VPN越しでサーバに接続することがままあるのですが。
      接続先VPNルータの設定の問題で、Windows7での接続がどうにも失敗するという事態に。
      VPNルータの設定を変えたいものの、設置先が遠方なのですぐには対応できず。

      で、Linux(確認したのはUbuntu)だったら接続できるようなので、このLinuxのVPN接続を間借り共有すればいいんじゃないかなという話に。
      図で書くと↓のような想定ビフォーアフター。



      というわけで、iptablesを使ってさくっとやってみます。

      ネットワーク情報

      Linux(VPN接続済)
      eth0: 192.168.11.100
      ppp0: 192.168.100.200
      ※LinuxでのVPN接続方法については、今回は割愛。
      サーバ
      eth0: 192.168.100.100
      クライアント(Windows7)
      eth0: 192.168.11.101

      いろいろ設定

      まずはLinuxの設定をいくつか。

      $ cat /etc/sysctl.conf | grep net\.ipv4\.ip_forward
net.ipv4.ip_forward=1

      net.ipv4.ip_forward=1にすることで、IPv4転送が有効になります。
      書き換えた後は

      $ sudo sysctl -p
net.ipv4.ip_forward = 1

      として設定を反映。

      あとはiptablesでIPマスカレードを設定。

      $ sudo iptables -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE

      これでLinux側は準備完了。

      Windows7側にはルーティングを追加。

      C:\Windows\System32>route add 192.168.100.0 mask 255.255.255.0 192.168.11.100
OK!

      ※ルーティングを永続的にしたい場合は、-pを加えると再起動後も有効になります。

      で、Windows7側からpingで確認してみると

      C:\Windows\System32>ping 192.168.100.100
 
192.168.100.100 に ping を送信しています 32 バイトのデータ:
192.168.100.100 からの応答: バイト数 =32 時間 =34ms TTL=62
192.168.100.100 からの応答: バイト数 =32 時間 =34ms TTL=62
192.168.100.100 からの応答: バイト数 =32 時間 =36ms TTL=62
192.168.100.100 からの応答: バイト数 =32 時間 =38ms TTL=62
 
192.168.100.100 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 34ms、最大 = 38ms、平均 = 35ms

      無事見えるようになりました。:-)

      内容としては単なるIPマスカレードの話なのですが、こんな使い方もあるよってことで。

      { Page Top }

      { 2012.1.12 }

      RAID5がiowait出まくりで遅いので、stripe_cache_sizeを増やした話

        category：linux｜author：｜tag：, ｜comment：1

        はてなブックマーク - RAID5がiowait出まくりで遅いので、stripe_cache_sizeを増やした話
        このエントリーをはてなブックマークに追加

        あけましておめでとうございます。
        Fusic 平田です。
        新年気分とは何の関係もない、RAIDのお話です。

        年末にXenサーバのディスクがお亡くなりになったので、ディスク換装してCentOS6.2でKVMサーバを再構築。
        で、ディスク4本なのでどうしようかなーと思いつつRAID5を組んではみたのですが、iowaitが収まらない。
        特に書き込みのほうが苦戦しているようで、仮想サーバがちょっと頑張るたびにロードアベレージが10越えたり。
        これじゃ使い物にならんなあ最悪RAID10で組み直したほうがいいかなあ。。。とか悩んでいる時に以下の記事を発見。
        peterkieser.com/2009/11/29/raid-mdraid-stripe_cache_size-vs-write-transfer/
        ※ 記事中のスクリプトまでは試していません。
        書き込みで苦しんでいるならstripe_cache_size増やすと捗るよ！ってことでやってみました。

        サーバスペック：
        Xeon X3230 (4コア) メモリ8GB HDD1TB*4(RAID5, software raid)

        対象のRAIDアレイ（今回はmd3）に対して

        # echo 8192 > /sys/block/md3/md/stripe_cache_size

        と実行して値を書き換えます。
        resyncがかかってしばらくしたら完了したので、あとはtopでだらだら流して様子見。
        仮想サーバ側で何度か負荷の高い処理をしてみてもロードアベレージがさほど上がらなくなったので、とりあえずはよし。

        あとはOS再起動しても動くように、ruleを追加。

        # cat <<EOS > /etc/udev/rules.d/80-md-stripe-cache.rules
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="8192"
EOS

        今のところ、これで快適に動作しています。
        問題が起きないか、最大限の関心を持って注視を続けることが当面の隠れ業務です。

        ・・・ていうか、そもそもRAID5使わないとかsoftware raid使わないとか別の方策あった気もします。

        追記：
        8192でも微妙につっかえる場面が見受けられたので、結局32768（最大）まで増やしています。
        ページサイズ(=4KB)×stripe_cache_size×ディスク数分のメモリ使うので、あんまし増やしすぎるのも嫌だなーと思ったんですが。
        メモリで困る前にCPU数で困りそうな気がしたのと、メモリは最悪増設できるしなーってことで、とりあえずはこのままで。

        { Page Top }
        «- 以前の記事
        以後の記事 -»