DigiLoog

続きを読む »

全体構成図は下記の通り。
部屋が複数あるので自宅の対角線上にAPを2台配置しつつ、
1台のAPで2.4GHz・5.2GHzを同時出力する構成にしてみた。
※下記ではAP1台で1種類の周波数に見えるが、実際は両周波数を出力中

SSIDはIPv4専用・IPv6専用を用意する事で、用途に応じた使い分けを出来るようにした。
無線LANセグメントのデフォゲは1台のルータで処理をしているが、
NW負荷はそれ程高く無いので問題無いと判断した。

別部屋に置いていたイーサネットコンバータは、今までWLI-TX4-AG300Nを使っていたが、
流石に老朽化して不調になる事も多々あったのでNTP設定で話題になったTP-Link製にしてみた。
軽く触ったが、W53/W56に対応していない事や、管理画面のログイン処理が雑だったり、
無線APなのに謎のTCP/22が空いた状態になっている以外はは問題無かった。
…無線セグは元からルータでACLかけているので、
やばそうな通信はAnyDenyした上で使おうと思う ﾍ(ﾟ∀ﾟﾍ)

………

上記構成で唯一嵌まったところとしては、
Aironet実機型番とIOSバージョンの組み合わせによっては、BVIのIP指定方法が変化する点。
通常のAironetはBVI1に管理IPアドレスを1つ付与する運用をすると思うが、
ns-lab BBの既存APではBVIを敢えて2つ以上作成していた。
ただ、今回購入したAironet2600ではBVIを1つしか作成出来ない事に気付かず、
管理I/FとしてLInkUPはしているが、ARPは引けない事象が発生した (´・ω・｀)

原因はBVI2以降に対応していない為、元からIP疎通は出来ないのに、
BVI1以外を作成した段階でMACアドレスが強制的にBVI1以外に適用されてしまい、
ARPを引けなくなるからだった。
という事で、今回からAP1台で1管理IPの構成に変更も行った。

………

という事で小さな事に嵌まりはしたものの、今の所は快適にIPv4/IPv6で通信が出来ている。
ただ、無線AP製品は長期間使ってみないと善し悪しがわからないので、
暫くは今回構築した構成で行こうと思う。

« 続きを隠す

続きを読む »

細かい所はCISCO公式の詳細があるので割愛。
自宅で使っている現行機はCiscoASA 5510なので、スペック上は3倍以上早くなる。
ただ今回は速度はどうでも良くて、筐体の発熱削減と消費電力削減の二つが主目的。
ちなみに、搭載しているCPUは下記の通り。情報はCISCOのコミュニティに乗ってた。

CPUの世代が違うので単純な比較は出来ないのだが、
IntelのARKを見ると5510の方が消費電力が多い。
ただ、動作テストをした限りでは5512-Xの方が発熱量は少なかった。

………

前面・背面はこんな感じになっている。
前面にはSSDを搭載するスロットがあるが、これはFIrePOWER用の物。
今回購入した筐体はFirePOWER無しなのでブランクパネルになっている。
背面は特に変更点はなく標準状態状態だった。

筐体の天板はネジ一本で止まっているだけなので簡単に開ける事が出来る。
マザーボードは毎度のFOXCONN製で、SATAコネクタがあったり、BIOS用のコイン電池があったりと、
普通のPC用マザーボードと遜色無かった。
真ん中当りの黒い部分はファンで吸い込んだ風をCPUにあてる為のガードになっていて外す事が出来る。

真ん中にはCPUヒートシンクがある。
ここに効率的に風を当てる為に、ASA 5512-Xは吸気方向でファンが搭載されている。

メモリはDDR3のECC付きっぽい物を使っていた。
チップセット的には、もしかしたらECC無しでも起動しそうだが、
標準で4GBも乗っているので変更する事は無さそう。
マザボには、EPS12Vコネクタもちゃんと乗っていた。
流石に、アプライアンスで電力不足の不安定は洒落にならないからだと思う。

………

ファンは普通の40mm角・28mm厚ファンを利用。
止め方が特殊で一見するとネジ止めに見えるのだが、実際はゴムブッシュをネジ止めして、
ファン自体はシャーシにはめ込んでいるだけである。

ASA 5510の時と同じく、Nidec UltraFloを使っていた。
ただ、例の如く音が大きく静音化する前は離陸するような音が鳴っていた。
という事で、毎度のTSUKUMOで換装用のファンを調達。
本当は静音版(4000rpm)が欲しかったのだが、在庫切れだったので標準版(5500rpm)をチョイス。

換装した後がコチラ。結構キレイに纏まったと思う。が、良かったのはココまでだった…
ファンは筐体仕様でちゃんと固定する形はなってないので、5500rpmで回ってもビビリ音が凄かった。
解決方法としては、ゴムブッシュ型からネジ止めに変更するか、
ビビリが止まる様に耐震ゴムで押さえ込むかになると思う。
ネジ止めにすると、筐体全バラシした上でシャーシ改造が必要になるので最後の手段。
という事で、安く実現出来そうな耐震ゴムでなんとか出来ないか試行錯誤予定。

後は、ファンの回転数を下げる方法もあるが、ファン1個で1500円程する事もあり結構痛い出費になる。
あと、単純にファン回転数を下げて静音化すると、夏場を乗り越えられるか怖いので、
こちらも最後の手段として利用にする予定。

« 続きを隠す

続きを読む »

GLSBはDNSキャッシュとレコード応答を利用して接続先サーバを切り替える。
切り替えルーチンは様々な物があるが、
ラウンドロビン・ジオグラフィー・グローバルアベイラビリティの採用例が多い様に思う。

今回構築したGSLBでは、広域負荷分散する程の自鯖台数もないので基本はラウンドロビンで設定しておき、
セッション維持が必要な用途(FQDN)は、ソーリーサーバ形式で拠点切り替えを行う様にしてみた。
という事で、ns-lab BBで実際に使っているGSLBの構成がこちら。

自鯖と言いつつサーバはCloudGarage上に構築したので、VPS仕様によりNATが必須となってしまった。
また、UDPリバプロを使いたかった為、gdnsdの前段にnginxを配置してみた。
この構成だとgdnsdで取得するIPアドレスが、ローカルIP(nginx)になってしまうが、
gdnsdで接続元IPが必要になるのはジオグラフィーロードラバンス(GdnsdPluginGeoip)する時なので、
今回は使わない機能と割り切った。

前段にUDPリバプロを配置した事でメリットもあった。
gdnsdはDNSクエリログを記録する機能が無いのだが、
UDPリバプロを配置した事で、接続元IPなどをnginxで取得する事が可能になった。
iptablesを透過モードで全クエリ取得する事も可能だが、
他の遮断ログと混在すると解析するのが大変なので、今回はリバプロ取得の方が合致した。

構成図を見るとわかる通り、nginx配下でもたすき掛けに分散させておき、
1台のプログラム・サーバがダウンしても、稼働し続けるようにしてある。
サーバスペックは低いのでDDoSレベルには耐えられないが…

………

本稼働しだしてから日が浅いのと、
gdnsdのヘルスチェックも一部しか使っていないので未知数な所もあるが、
負荷テスト・障害テストなどを色々やってみた所では特に問題は無かった。
業務レベルでGSLBを扱う時はRoute53を採用した方が楽だが、
GSLBの概念を把握していないと障害時にハマるので、
自鯖で検証しつつ検証利用しながら使い倒すのが良いかもしれない。

………

後日談 ＞ 【DigiLoog】：gdnsdとdnsdistでGSLB構築

« 続きを隠す