2016年10月15日(土) - 22:19 | カテゴリ:
Network
今年は4月辺りから、ns-lab BB(自鯖・自宅ラック)の設備更新を進めており、
先々月あたりに、コアルータ・スイッチの更新を実施していった。
そんな中、物が入手出来ず更新出来なかったFirewall・ONU直結スイッチが残っていたのだが、
CiscoにするかAlliedにするか迷った結果、コアはCiscoで固めているので、
敢えて違う機種を入れようと思い「AlliedTelesis CentreCOM AT-SH210」を購入してみた。
今回は新品なので、ちゃんとAlliedTelesisロゴ入り段ボールに入った状態で届いた。
お値段高いし、保守切れてしまうのは悲しいので、封印シールを剥がすのは割愛。
最初はAT-X210にしようと思っていたのだが、
値段が高いのと必要無い機能が多く管理しきれないのがネックだった。
まぁ、自宅でCiscoCatalyst使っている人が言うセリフじゃないが ﾍ(ﾟ∀ﾟﾍ)
そんな事を思いつつ調査をしていた所、AT-SH210の存在を知った。
AT-SH210はAT-X210と同じハードウェア・筐体を使った上で、
上位機能を省いてコストダウンした物。
今回は省略されている機能が必要無い物であったのと、スイッチング容量が多い等、
自分の要件を満たしていたので機種はSH210に決定した。
ちゃんと梱包されているL2SWを買ったのは何時ぶりだろう…
ちなみに、シリアルケーブルは付属されていない。
前面は普通の24ポートギガスイッチの装丁。側面は排気口が空いている。
写真の通りファン穴の様な排気口だが、ファンは装着されていない。
スペック表でも「ファンレス設計」と書いてあるので、
この程度の穴が空いていれば十分に冷却出来る構造になっているのだろう。
まだ設定を作り込んでいないので本番運用出来ないのだが、
近日中に既存スイッチからの入れ替えを実施予定。
その時に、ns-lab BB全体の構成図とかポリシーを作り直して公開する事にするか。
« 続きを隠す
2016年10月08日(土) - 20:32 | カテゴリ:
Linux
ns-lab BBは自鯖とConoHaの2拠点体制で運用していたのだが、
自鯖でゲストインスタンスを増やしすぎたからか、
CPU負荷・ディスクI/O負荷が高くなってきており、鯖が応答不能になるのが問題だった。
という事で、今年の初頭からBB設備の入れ替えを行いつつ対策を行っていたのだが、
作業も終盤になり一部のデータを外出しする所まで完了した。
その中、処理速度が必要な物はConoHaに移したのだが、
ディスク容量が必要な物(100～130GB)をどうするかという事で、
ns-lab BB初となる「さくらのVPS」でHDDプランを借りてみる事にした。
今回のVPSを借りるに当たって、ns-lab BBのVPS棲み分けはこんな感じ。
本来は全部ConoHaでやるのが楽なのだが、ConoHaでHDD(SSD)容量を求めると、
他の所が過剰になり値段が高いので対象外とした。
|
VPS
|
ConoHa
|
さくらのVPS
|
|
用途
|
高速処理用途、DBガリガリ書き込む
|
DR環境、アーカイブ
|
|
CPU
|
3コアをそれなりに使用
|
1コアを使う程度。稀に2コアで処理
|
|
DISK
|
高ディスクI/O必須
|
遅くてもOK
|
一長一短なのだが、目的の一つにDRが含まれているので、今回のさくらは石狩拠点で構築。
東京から石狩にping打つと20～25ms程度の時間がかかるが、
今回は応答性は必要無いので許容する事に。
という事で鯖を借りたので、とりあえず「cat /proc/cpuinfo」してみた。
Linuxベンチはそのうち纏まった時間を取って実行予定。
上：ConoHa(CPU3コア/MEM2GB/SSD50GB)「Xeon E5-2660 v3」
下：さくらのVPS(CPU3コア/MEM2GB/HDD200GB)「Xeon E5645」
やはり最新設備を使っているConoHaのCPUは速かった…
さくらのVPSもSSDプランだと速いのかもしれないが、
今回はHDDプランなので結構前のCPUを使い続けているイメージ。
使えるCPUコードも結構違うので、本気でCPUを使いまくる場合はConoHaの方が良いのかもしれない。
まだ使い出してから日が経っていないのでなんとも言えない所だが、
1～3ヶ月程使ってそれぞれの得意な処理とかVPSの特性が判った暁には、
もう一度比較検証をやってみようと思う。
« 続きを隠す
2016年09月17日(土) - 19:53 | カテゴリ:
Linux
自鯖の監視システムは正・副で二重化しているのだが、
正で使っているzabbixのバージョンが2.4のまま放置していたのが気がかりだった。
だが、先日読んだIT記事で「zabbix3.2.0が正式リリースされた」と書いてあり、
流石にメジャーバージョンが2つも上がればバグとかも減っているだろうと思ったので、
時間を見つけてzabbix2.4から一つ飛び越えてzabbix3.2にバージョンアップしてみた。
なんとなく、Windowsのタイルを彷彿させるUIだった。
自鯖のzabbixはソースコードからmakeしているので、
3.2についても秘伝のスクリプトを使って「./configure && make && make install」した。
configureの時に難しいオプションは追加していないので、
2.4時代のオプションをそのまま流用する事が出来た。
巷だと設定ファイルも書き直ししている例が多いのだが、
2.4のコンフィグをそのまま上書きして終了。こっちもエラーは特に出なかった。
………
エラーでは無いが少し焦ったのだが、zabbixのデータベースバージョンアップ作業。
zabbixのメジャーバージョンを上げた際はデータベースのバージョンアップが自動で走るのだが、
これが結構長く、体感で10分程度時間がかかった。ちなみに、DBサイズはzabbixだけで1.5GB程。
自動バージョンアップは、zabbix serverのログを見れば進捗がわかるので、
zabbix serverの起動直後は、適当に「tail -f log」していれば良いと思う。
DBバージョンアップが完了したら、いつも通りにsetup.phpを動かしてコンフィグを作成すれば完了。
焦りはしたが、大きなエラーやDB破損が起こる事無くバージョンアップ作業は完了した。
………
3.2を少し使った印象としては、WebUIの応答が速くなったような気がする。
もしかしたら、zabbixのフロントエンドを大幅に改修した結果なのだろう。
サーバ・エージェントの動作は特に違いがわからなかった。逆に言うと安定している (｀・ω・´)
結論だが、3.0を飛ばしてバージョンアップをしても問題は無かった。
もちろん、zabbixの設定次第だと思うが「互換性が～」を理由にバージョンを上げていない自鯖屋の人は、
バックアップを取った上でバージョンを上げる分には、チャレンジする価値があると思う。
« 続きを隠す
