UC●MのLocusnetworksのスイッチがGARPを無視する場合の対処法

UC●Mが使用しているLocusnetworksの謎スイッチがkeepalivedのGARPを無視してフェイルオーバーできない場合の対処として、仮想MACを利用する以外にも比較的簡単な方法があります。

ちなみにL2おろしのサービスなので、MACアドレスが直で見れるので見てみたところLocusnetworksという謎のスイッチでした。

以前の検証でフェイルオーバーできないIPもIPエイリアスではなく、実IPをふりなおせば問題なく使えることは確認できていました。
もしやと思い、ソースIPを指定してLocusnetworksの謎スイッチのアドレスにpingを送ったところ、その瞬間にLocusnetworksの謎スイッチのARPテーブルが更新されて疎通できるようになりました。

ping -I [VIP] [UC●M GW IP]

GARPは無視するけど、なんらかの形で存在を教えてあげると切り替わってくれるみたいです。

フェイルオーバー後にkeepalivedがUC●MのGWにVIPをソースIPとしてpingを打てばとりあえずフェイルオーバーできない問題は解消しそうです。

仕組みはいろいろできると思いますが、keepalivedのnotify_masterを使います。

vrrp_instance IV_1 {
    state BACKUP
    interface eth0
    virtual_router_id 1
    priority 50
    advert_int 1
    notify_master /usr/local/bin/to_master.sh
    authentication {
        auth_type PASS
        auth_pass papapass
    }
    virtual_ipaddress {
        192.168.144.254
    }
}

/usr/local/bin/to_master.sh の中身はこんな感じです。

#!/bin/bash
ping -I [VIP] -c 10 [UC●M GW]

keepalivedがマスターに昇格したら自動でVIPをソースにしてpingをうちます。これでLocusnetworksの謎スイッチのARPテーブルが更新されて疎通できるようになります。
(-c10 は不信感の表れです)

この件でUC●M側の対応としてはファームアップだったみたいですが、ファームアップ後もしっかり再現したのでこのような実装を思いつきました。
「他のお客様はアプライアンスを使っていてみなさん仮想MACなので問題ない」とのありがたい言葉もUC●Mからいただいております。

この程度の金額のサービスで仮想MACが使えるアプライアンスを維持できるお客様しかいないもんでしょうかね。

CPUfreqを利用して微妙に節電

一ヶ月のガスの使用量は1㎥か2㎥。水道料金は基本料だけで抑えて暮らしていますが、電気代だけはどうしようもありません。
そんな極貧暮らしが多少楽になるネタを仕事中に見つけました。

CPUfreqを利用してspeed stepをよりユーザの意図した通りに刻んで節電する方法です。

必要なパッケージをインストールしてから、デーモンを一つ動かすだけです。

sudo aptitude install cpufreqd cpufrequtils
sudo /etc/init.d/cpufreqd start

これでcpufreq-infoコマンドで統計を見ることができるようになります。

$ sudo cpufreq-info                                                                                                                                                                                         
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.39 GHz
  available frequency steps: 2.39 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 2.39 GHz and 2.39 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.39 GHz (asserted by call to hardware).
  cpufreq stats: 2.39 GHz:24.38%, 1.60 GHz:75.62%  (6118618)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 2.39 GHz
  available frequency steps: 2.39 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 2.39 GHz and 2.39 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.39 GHz (asserted by call to hardware).
  cpufreq stats: 2.39 GHz:25.84%, 1.60 GHz:74.16%  (7899714)

このように動作クロックの割合など見れて便利です。
自宅のサーバは普段仕事をしていないので、少しでもケチるためにondemandからpowersaveに変更します。

変更は面倒なのでそのままパラメータを投げてしまいました。

# echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# echo powersave > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

powersaveはondemandよりクロックの回復が遅いみたいです。とはいっても自宅サーバのCore2 Duo E6600は2段階しかspeed stepしてくれないので効果は薄そうですが。
i7 870との比較です。

# E6600
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies                                                                                                                                        
2394000 1596000

# i7 870
$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2934000 2933000 2800000 2667000 2533000 2400000 2267000 2133000 2000000 1867000 1733000 1600000 1467000 1333000 120000

家のサーバの電源が落とせないため、実際の効果は職場の検証機を使って暇なときにやってみようと思います。

netfilterのconntrack_maxとip_local_port_rangeの関係

いろいろ追い続けてきたnetfilterですが、Linux NAT Boxとしての物理的な限界値であるOSの使用できるポートの上限数にたどり着きました。

メモリをガン積みしていくらconntrack_maxの上限を増やしたところで、ip masquaradeに使うポートがなければ頭打ちです。

これについてはnetstat-natコマンドが見やすいです。
あれやこれやワンライナーでつなげて見ると、ASSUREDの状態のconntrackでも一つのポートをシェアしてる様子が伺えます。
これは手元のクライントマシンでnetfilterをロードして抽出した結果です。

tcp   192.168.2.111:62258               xx.xxx.xx.xxx:www             TIME_WAIT
tcp   192.168.2.111:62258               xx.xxx.xx.xxx:www             TIME_WAIT
tcp   192.168.2.111:62258               xx.xxx.xx.xxx:www             TIME_WAIT

つまりconntrack_countがローカルポートの使用数というわけではないことがわかります。

こんな感じでリアルで使っているポートをユニークで洗い出すと使用しているポートの数が分かります。

 sudo netstat-nat | awk '{print $2}' | cut -d ":" -f2 | sort -n | uniq | wc -l
25

いくらip_local_port_rangeを増やしたところでnetfilterのメモリ使用容量から逆算すると、せいぜい16Gもつんでいれば十分なようですね。
FWやsuricata等で鬼のようなトラッキングをしたいという時は別でしょうけど、GWだけでつかっている場合には16Gで十分おつりがきます。

FWアプライアンスがメモリをいっぱい積んでる理由も納得できますね。