DigiLoog

続きを読む »

Aironet 3800はCiscoからもEOS情報が出ているが現役で使える機種なのであまり市場に出ない。
それでも昨今のテレワークブーム影響なのか、オフィス縮小影響で纏まった数が出る事があり、
業務NW機器界隈を覗き続けて安くて状態が良いものを無事にゲット出来た。

マルチギガビットなのでポート名もmGigラベルだが他はいつも通りのConsoleとAUXだった。
外部電源を使う場合は48Vの専用ACアダプタを使えるが、
AironetならPOE+で汎用的に接続した方が良いと思う。

裏面は放熱用にヒートシンク状の切り込みが入っている。
写真だとわかりにくいが金属素材で出来ていたので、それなりの放熱性を確保出来ていそう。
下位モデルのAironet 2800は切り込みが無くてのっぺりしているので、
4×4 MIMOによる発熱増加を効率的に冷やす為の配慮だと思う。

実際に動作検証で使い始めたがAironet 2700/3700シリーズと違う部分が多く四苦八苦中。
コマンドは大差ないがGUIがまるっきり変わってしまったのが痛い。
金銭余裕は無いが時間余裕がちょっと出来てきたので弄りながら慣れていきたい。

« 続きを隠す

続きを読む »

2機種のバックプレーンが同じだからこそ出来る芸当なのだが、
対応したモジュールを使えばSとXでスタックを組めたりする。
だからこそ筐体も似た感じになっており、重ねても奥行があんまり変わらない。

裏面はスタックモジュールと電源冗長化のRPSポートになっており他のCatalystスイッチと同じ。
今回は48メタルポート+4SFPポートの機種なのでフロントはフル装備になっている。
シリアルポートとマネジメントポートは左端に寄せられて、右側はSFPポートのみになった為、
配線した時にSFPポートを塞ぎにくくなり、アップリンクをSFPに接続した時にごちゃごちゃしにくい。

………

お待ちかねの分解写真。
Catalyst 2960Sは変則型の基盤だったが、Catalyst 2960Xは比較的整った四角形だった。

他のCatalystや他社スイッチと同じく電源とメイン基板が分離していた。
スタックモジュールを差し込む部分も簡素化されており、シャーシの溝に沿ってそのまま差し込める。
モジュールガイドが無いと剛性が心配だが、頻繁に抜き差しする物でも無いので割り切っているのかも。

電源は安定のLITEON製。台湾のスイッチ電源メーカーで最近は色んな物で見かける。
トランスは見れなかったが電解コンデンサは日本ケミコンKXGを使っていた。

2960XはUSBシリアルポートが二つ搭載されているので、フレキシブルケーブルが基盤から伸びている。
左端に見えているLEDポート用のパーツは、
シャーシのモードボタンを押した時にSTATやSTACKを切り替え表示する為の物なのでデータ用とは別。
スイッチのデータポート制御チップにはMarvell 88E1680-LKJ2を利用していた。
スペックシートを見たら1Gbpsを出せるみたいなので、ポート自体はスペック通りに実装されている。
至って普通ではあるが、安定性重視のNW機器だからこそのチップ選択に感じた。

排熱ファンは最近のCiscoで多い4ピンコネクタタイプ。
NIDEC 800-39488-01シリーズなので、型番で探せばAliExpressとかで購入出来る筈。

電源を入れてみると起動直後はかなりの音が出るが、3分程度置くと落ち着いてファン回転数も下がる。
この時、筐体の電源ボード付近から凄い勢いで外気を吸い込んでいたので、
埃がシャーシ内に入るのを防止する為にマグネット型のファンフィルターを改造して外側に付けてみた。
3日程度動かしただけで埃っぽくなっていたので、埃流入防止で仕事してくれている。

………

検証用仮想サーバやiSCSIのデータトラフィックも実際に流しているが、問題無くパケット転送してる。
排熱ファンも正常稼働しIOSもちゃんと動いているので、不具合・バグの両方とも無かった模様。

トラフィックを転送出来て当たり前なので機能面は他のCatalystと違いがあんまり無いが、
新しいスイッチはテンション上がるので、暫くの間はログインして状況をチェックする事になりそう。
退役した2960Sも掃除すれば現役で使えるスペックは持っているので、
今後は2960Xと2960Sを使ったL2SW検証や、検証用に確保した3560CXも使ってラボテストをやろうと思う。

« 続きを隠す

続きを読む »

QTS 5.0はQuLog Centerからイベントログとアクセスログの取得を設定出来る様になった。
以前のバージョンだと設定が各々独立しておりシステムログとプラグインを併用していた筈。
筆者は元からイベントログを外部のログサーバへsyslog転送していた為、
コレに加える形でアクセスログ取得を追加した。

ログサーバにマルチバイト文字を送信するとバグりやすい気がするのと、
QNAPのサポートへエラー報告する際に都合が良いので、ログの言語はEnglishにしている。
とは言っても、アクセスログで取得するファイルパスがマルチバイトなら、
English設定でもちゃんとマルチバイトなどのディレクトリ名が取れていた。

適当なファイルをファイル共有領域へ保存した後、10秒程度してから削除したログが上の通り。
横に長いので見えにくい人は右クリックから別窓確認を推奨。

ファイルを書き込む作業がAddとWriteの2行で記録されつつ、削除動作はDeleteになっていた。
画像には載っていないが、10万個の画像を1個のフォルダに置いて丸ごと読み込んでみた所、
今度はReadログが10万行分一気にログサーバへ飛んできた。

………

今回取得したログはQNAP本体でそのまま蓄積する事も出来るのと、
QTSにもログサーバのオプションが存在するので自身でそのまま蓄積するのも良さそう。
だが、一般家庭ではNASのアクセスログなんて取らないだろうし、
その上で取るなら本職の人だと思うので外部ログサーバへ転送するのが本筋だと思う。
結果としてNAS本体で蓄積するよりログサーバへ飛ばす事で真価を発揮する設定だと感じる。

アクセス数とファイルサーバ規模にもよると思うが、
エンタープライズ環境でフルロードをかけた際に耐えられるのかは未知数。
あくまで筆者の経験上だが、そこまで大規模になるならこの機能では耐えられない気がする。
そもそも、アクセスログ取得の前にNAS自体の処理限界を迎えて頭打ちになると思うが、
この辺りは何処かの企業がレポートを出してくれれば嬉しい。

« 続きを隠す