はてなブックマーク - 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マスカレードの話なのですが、こんな使い方もあるよってことで。

      はてなブックマーク - rails3.2でdeviseのインストール手順を間違えたら面倒だった話
      このエントリーをはてなブックマークに追加

      この前Rails3.1がリリースされたと思ったら、もうRails3.2です。
      バージョンが上がると、重宝して使っていたgemやプラグインが対応に追いつくのかが不安なんですが、その内のひとつ「devise」に関してのちょっとしたエントリーです。

      deviseとは

      github.com/plataformatec/devise

      deviseはシステムのログイン管理を担ってくれるRubyのパッケージです。
      ログイン認証が必要なシステムに対して、ユーザー登録・パスワードの暗号化・パスワードリセットなどの処理を担ってくれるので便利です。

      そのdeviseを使用したプロジェクトを作ります。
      Railsは3.2です。

      rails new sample

      で、プロジェクト作成。データベースも作成しておきます。

      Gemfileに、deviseに関する行を追加。

      gem 'devise'

      その後、本来は

      rails generate devise:install

      とすべきところを、

      rails generate devise user

      と、いきなりモデルの作成をしました。
      すると、

      /home/user/.rvm/gems/ruby-1.9.2-p180@rails32/gems/execjs-1.3.0/lib/execjs/runtimes.rb:50:in `autodetect': Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)

      本編とは関係ないエラーが出てしまいました。
      JavaScriptのランタイムが無いと。
      Gemfileから

      # gem 'therubyracer'

      のコメントアウトを外します。

      で、再度

      rails generate devise user

      を実行。
      すると、必要なファイルが作成されます。
      そして、アプリを起動すると。。

      /home/user/.rvm/gems/ruby-1.9.2-p180@rails32/gems/devise-2.0.1/lib/devise/rails/routes.rb:406:in `raise_no_devise_method_error!':User does not respond to 'devise' method. This usually means you haven't loaded your ORM file or it's being loaded too late. To fix it, be sure to require 'devise/orm/YOUR_ORM' inside 'config/initializers/devise.rb' or before your application definition in 'config/application.rb' (RuntimeError)

      何か怒られました。
      ここで、「ああ、『rails generate devise:install』をしてなかった。。」と、インストールコマンドを実行。

      rails generate devise:install

      すると、

      /home/yama/.rvm/gems/ruby-1.9.2-p180@rails32/gems/devise-2.0.1/lib/devise/rails/routes.rb:406:in `raise_no_devise_method_error!': User does not respond to 'devise' method. This usually means you haven't loaded your ORM file or it's being loaded too late. To fix it, be sure to require 'devise/orm/YOUR_ORM' inside 'config/initializers/devise.rb' or before your application definition in 'config/application.rb' (RuntimeError)

      同じエラーです。どつぼにはまりかけです。

      エラーをよく読むと、
      config/initializers/devise.rb か、
      config/application.rb に、
      require 'devise/orm/YOUR_ORM' を書いてね、と言われているようです。
      どのO/Rマッパーを使うのかがわからないと起動できないみたいですね。
      なので、
      config/application.rb に

      require 'devise/orm/active_record'

      を記述後、インストールコマンドを実行。
      無事、必要なファイルが生成され、deviseを使えるようになりました。

      何事も順序どおりに、端折っちゃだめよというお話でした。

        はてなブックマーク - 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数で困りそうな気がしたのと、メモリは最悪増設できるしなーってことで、とりあえずはこのままで。