サーバ機リプレイス(PC-Q21A)

年の瀬も近づいてまいりましたが、サーバを更新することにした。久しぶりの自作なので、メモしておきます。
自宅サーバで、 Mini-itx希望で、メモリは多く載せたい、ゲームはしないということを店員さんに伝えて、選択におつきあいしてもらった。
若い方でしたが、マニアックで詳しいそうだったので、ほぼおすすめに従った感じです。

Mini-ITX用ケース

Lian Li のPC-Q21

現在使用ケースの半分くらいの大きさでしょうか。 グラボを載せるわけでもないので全く問題ないでしょう。
こんな小さくてかわいらしいケースがあるのですね。 Diskも思ってた以上に搭載できるようです。

raijintekのmetisは、カラーが豊富で、電源がATXだったので迷いましたが、今回はさらに小さいQ21の採用となりました、
Q21の電源はSFXになります。音が気になるかと心配でしたが、全く問題なし。

Mini-ITX マザーボード

ASUSのB150 Pro Gaming Aura
マザーボードはどこがよいのかと全くわからないので、安くてオススメにしました。Gameとか全くしませんが。
ネットワークポートが2個付属のものがよかったのですが、あまりありませんね。H170のギガバイト製品がありましたが、ちょいとお高めでした。NICのカードは古いのを使い回すことに。

組み立て中に気づいたのですが、B150なのにボードの背面にM.2付いてるのですね。こちらのDiskを買えばよかったと。店員さん、言ってよ!(なんてね。)


え! キーボード用にPS-2? こちらも驚いた。

SFX電源

SiverStone SST-ST45SF-G

仕様

300Wのブロンズでも充分だとおもったけれど、店員さんおすすめで450Wのゴールド。今回は、これが想像以上に高かった。。。。
うるさくても嫌だったし、電源がすぐに故障なんてのも寂しいので、言いなりに。
ケーブル類も取り外せるので割とすっきりできます。PCIe用のケーブルとか使いませんので。
電源のスイッチがないことに驚き。サーバで常時稼働なので特に問題ありません。

今回マザーボードがLEDで派手に光るので、off時も綺麗です。

CPU

Intel core-i5 6500 3.2GHz

せっかくなのでi7にしたかったのですが、予算と照らし合わせ、まあこのクラスで充分ですね。はい。
あれ? ファン付いてました。ファンはケースと干渉するかと思い、別途購入してしまった。標準のファンでもギリギリいけた感じでした。



ファン

NOCTUA NH-L9i

いつも標準のfanで乗り切っているので、今回初購入。NOCTUAというメーカ。
厚さの薄めのファンを選択。このファンならボードは全く気にしなくても大丈夫ということで。
箱をあけると立派ですね。見た目はどうでもよいですが、なんだか、高品質そうです。
マザーボードの裏側から4つのネジで固定。 とても静かに回転してくれます。


メモリ

http://www.crucial.com/

メモリの安さに驚いた。DDR4ってもうこんなに安いんですね。という訳で、16GB x 2で32GBにしました。VMをたくさん動作させることが多いので、これは嬉しいです。
こちらは、ヒートシンクはついてないです。

SSD


MX300 525GB

半年前の256GBの値段と変わらない。。すごい。セールでもっと安くなるかと思うとこちらも驚きです。1万ちょっと購入できるとは。

家にあまっている2.5inch HDDを増設しても、Q21はまだ余裕。3.5 inchあと1個詰めます。 別途2.5inchなら詰め込めそうです。
マザーボードのSATAの口が4つまでですが。

 

vyatta 6.6R1にバージョンアップ

vyattaのバージョンアップを久しぶりに実施した。
6.5R1がリリースされた際にすぐに実施したのだが、なんか不安定だったので、6.4に戻していました。

こんな情報がありました。
この情報をたよりにいろいろと調べてみると、やはり6.5の時から問題が発生していたようです。
以前、不安定だったのはこれが原因のようです。(リリースされてすぐに6.5適用したから情報がなかったんだな。。)
こんなところ、よほどじゃないと疑わないよね。。。

せっかくなので、本当かどうか調べてみました。まずは、6.4でpppoe側をダンプ。

6.4-mss

mtuは1454に設定している。mssは1412と自動調整されていますね。

6.6R1にバージョンアップ後、同様にダンプすると。。。
6.6-mss

mtuは1454で設定しているのに、mssは1460になっていて調整されていない。。。。
これが原因なんですね。

サイトにあるように、policyでinterfaceにINするSYNパケットを1414にセットします。
mtuが1454だら、ヘッダ40として1414って訳ですね。R6.4の時は1412に調査されているようだが、
まっ、40バイトでいいでしょう。
こんな感じでpolicy追加。LAN側はbridge設定しているのでbridge インターフェイスに適用しました。ethXでは、変化なかった。

set policy route PPPOE-IN rule 10 destination address 0.0.0.0/0
set policy route PPPOE-IN rule 10 protocol tcp
set policy route PPPOE-IN rule 10 tcp flags 'SYN,!ACK,!FIN,!RST'
set policy route PPPOE-IN rule 10 set tcp-mss 1414
set interface bridge br2 policy route PPPOE-IN

さて、同様にダンプすると。。。ちゃんとmssが1414に設定されています。
6.6-mss-change

とりあえず、これでOKとしよう。しかしなんでこんなリグレっぽいことが放置されているのだ??

 

Wireshark::VXLAN

先日、openvswitchを使ってVXLANをやってみたが、VNIがどうなっているかとか、tcpdumpの結果
だけではわからなかった。
現時点、最新のwireshark 1.10.1ではVXLANをデコードできるようだったので、早速やってみた。

wiresharkでパケットを読み込んで、オーバレイされたパケットを選択する。
Analyze->Decode Asを選択する。
Transportタブに表示されているリストからVXLANを選択してApplyを実行する。

VXLAN-uni-decode

こんな感じでデコードされます。暗号化とかしないと地理的に異なるところでは使えないね。。
何も設定していないので、やはりVNIは0であった。。

先日のVXLANの方法は、純粋なVXLANではないようである。完全にユニキャストのみ。。
これでは、トンネル先を毎回指定しないといけないのでスケールしないかな。。。

調べていると、linuxのkernel 3.7以降でVXLANをサポートしているようであった。
ここに、vxlanの起動の仕方があったので、参考にできるだろう。

次回は、kernelをバージョンアップして、マルチキャストでVXLANする環境を作ってみよう。
おそらく、vxlanを作って、ovsに接続してやればいいだけな気がする。多分。。