2014年06月15日(日) - 11:02 | カテゴリ:
PC
6/12に発表されたWiMAX2+用新ルータであるNEC製NAD11に釣られ、
早速予約(契約)してきた自分(｀・ω・´)
以前から、自宅固定回線のバックアップ+宅外回線としてWiMAX2+を契約したかったのだが、
有線LANポートクレードルを装備したルータが無かったので尻込みしていた。
今回発表された物は、WiMAXルータで培った技術のあるNEC製という点と、
有線LANポートを装備したクレードル(オプション)を選べるという事なので即座に飛びついた。
…後でCiscoルータも追加してマルチホーミング環境を整備せねば
で、ここで一つ疑問が。
『実際に予約したけれど、NAD11の仕様ってどうなんよ?』
WiMAX2+対応しているとか有線LANポート持っているとか、
マニアックな事だとIEEE802.11ac対応とかはわかるのだが、他の子とは全くわからない現状(´・ω・`)
という事で、NECのサイトからNAD11の取扱説明書を持ってきて、中身を読んで見た。
NEC NAD11 取扱説明書
ルータの大きさとかバッテリーの持ち時間は他のサイト様が解説しているので省略。
※自分は、WiMAX2+の知識が皆無なので、変な事書いてもご了承
|
気になる点
|
適当な解説
|
|
au Micro IC Card(所謂SIM)必須
|
WiMAX2+だとSIMは必須になった?
それだと、グローバルIP付与はどうなる…?
|
|
バッテリー交換の可否
|
NEC純正は無いけど、
amazonにそれっぽいのはある
|
|
端末初期IPが192.168.179.1
|
他のだと192.168.1.1とかが多いので、
取説読まない人は混乱しそうな気が
|
|
IEEE 802.11 b/g/a/n/ac対応
|
モバイル端末なのに5GHz帯に対応している
もちろん、5GHzの野外使用は厳禁なので屋内専用
|
|
IEEE 802.11 転送速度
|
ac:433Mbps / n:300Mbps
他は理論値が最大転送速度になる
|
|
有線LANポート
|
クレードルに1000BASE-Tポートを搭載
ちなみに、10BASEは記載無し(使わないだろうが)
|
|
VPNパススルー対応
|
個人的にはありがたい機能
が、先の通りグローバルIP付与が謎なので使えない様な気が
|
|
Wi-Fi WAN側連動
|
WAN側の回線(WiMAX/auWi-Fi)が圏外になったら、
LAN側の無線LANを自動的にOFFにする
|
|
パケットフィルタリング可能
|
Ciscoの拡張ACL的な物を50個(行)設定可能
IPv4はもちろん、IPv6フィルタリングも可能
|
とりあえず気になった点はこんな所。
個人的にはギガLANポートとVPNパススルーが嬉しい。
これで、グローバルIPを割り当てて貰う事が出来れば文句無しだが
WiMAX2+でも可能なのかはプロバイダー毎に違うだろうし情報収集をせねば(｀・ω・´)
後は、実機が届いたら総武線とかに乗って色々測定したいな。
« 続きを隠す
2014年06月13日(金) - 23:11 | カテゴリ:
Network
今年のInteropは6/11(水)～6/13(金)の開催でした
今回は本職重視で行ったのでネタは少なめ。
と言っても、自宅で元気に稼働しているYAMAHAルータとかCiscoは見に行ったが(｀・ω・´)
毎年恒例であるInteropなのだが、昨年までは予定が付かなかったりで行く事が出来ていなかった。
そして、今年は本職の関係から行く機会を得られたので、
ここぞとばかりにNWラックに詰まったL3SWとか、普段は見られない上位ISP用GWとかを見てきた。
今年のInterop(と言っても初参加だが)は"トラフィックに耐える次世代設計NW"と、
"標的型&ゼロデイ攻撃にどう対処するか"という話題に特化している印象を受けた。
NW設計思想の方は、昨今で増えてきたスマホとかPCからのクラウド利用を想定してだと思われる。
"クラウド=NWの先"なので、それを支える為にはNWインフラは無くてはならない存在という位置づけに。
その為には、NW自体のダウンは元より応答性を犠牲にせず、
設計とアプライアンスでセキュリティ担保する設計思想など色々と興味深かった。
その事も相まってか、セキュリティアプライアンスも力が入っており、
中でも"シグネチャを使わないNGFW"の出典が多かった。
従来のFWだと、srcIP&dstIPやシグネチャ制御で遮断を行っていた為、運用が煩雑になる点と、
単体ではセキュリティリスクをフルカバーするのは難しいという弱点があった。
…その分、ノウハウ詰まっているので運用が楽なのですが
ソコに目を付けたのが、マルウェアの挙動から制御を行うアプライアンス製品の数々だった。
興味深かったのは、従来みたいな毎時のシグネチャ更新とかがいらなくなる物や、
アプリケーションレベルでの制御だとしても、ユーザ毎に通過と遮断の制御を切り替える物があったりした。
昨今だと、OpenSSLとかBINDとかの脆弱性がバンバン見つかっているので、
今後は『今までに無い方法でセキュリティ担保する』というのも重要になってくるのかもしれない。
………
で、個人的には一番の目玉であった、
YAMAHAのギガアクセスVPNルータ『RTX1210』ももちろん見てきた。
自宅のクライアントLANゲートウェイを支えているのはYAMAHAのNVR500なのだが、
運用しだしてから結構に数経っているのと、自鯖環境とクライアント環境でルータを分離させている現状から、
ここいらでRTX1210あたりを導入して中央管理化したい狙いもあったり。
コイツだと、3セグメントLANとかも普通に組めるのでセキュリティを維持しつつ柔軟なNWが組めそう。
まだ開発中との事もあり今後の作り込みによるのだろうが、
GUI面も刷新との事なので今冬は要チェックのNW機器の一つになりそう。
…そして、冬のボーナスはこれになりそう(´・ω・｀)
後は、会場をブラブラしていたらいつの間にか集まったノベルティの数々…
これで、暫くはボールペンに困らなくてすむわね(｀・ω・´)
« 続きを隠す
2014年06月08日(日) - 18:21 | カテゴリ:
Linux
2022年版として再計測してみました。
………
先日、自鯖のログ圧縮を行おうとキーボードを叩いていたのだが、
その時に『普通ならgzipだろうけどxzとか他はどうなんだろう…?』
と思ったので、実際にファイルを圧縮しつつ実行速度と圧縮率を測定してみた。
Linux(CentOS)のデフォルトlogrotateでcompressオプションを指定した場合はgzip圧縮になる。
オプションとかコマンドを再指定する事で、他の圧縮方法に切り替える事も可能だけど、
普通はそんな面倒な事やらないし、
『ログの圧縮と言ったらgzipだべ』という人が大半だと思われる。
そんな中での今回の検証だが、果たしてどの圧縮方法が鯖に優しいのだろうか(｀・ω・´)
………
● 計測方法
- 検証は仮想環境上に”CentOS x86_64″を構築し実施。
- テキスト(ログ)504MBとバイナリ(CentOSのLiveCD)649MBに対して
各圧縮コマンド毎に3回ずつ圧縮処理を行い、
その中の最速処理時間の値を圧縮方法に対応する処理時間とする
- 圧縮率指定の出来るコマンドでは、[速度重視 / 指定無し / 最高圧縮率]の3種類の測定を行う
ただし、アーカイブ化オプション(=圧縮しない)の場合は省略する
- 処理時間の測定にはtimeコマンドを使用し、
ユーザタイムでの処理時間をファイルの圧縮にかかった時間とする
- 圧縮率の計算は“[圧縮後の容量] / [圧縮前の容量]”とする
- 各コマンドのバージョンは以下の物を使用
| コマンド |
バージョン |
| gzip |
1.3.12 |
| bzip2 |
1.0.5 |
| xz |
4.999.9beta |
| zip |
3.0 |
| 7zip(7za) |
9.20.1 |
| lzh(lha) |
1.14i |
という事で、実際にコマンドを叩きまくって計測をしてみた。
◆ テキスト(ログ)ファイル [元ファイルサイズ:528394240(504M)Byte]
● 処理速度(単位:秒)
| |
最速処理速度 |
速度指定無し |
最高圧縮率 |
| gzip |
5.06 |
11.15 |
16.98 |
| bzip2 |
96.78 |
171.10 |
170.94 |
| xz |
19.02 |
303.38 |
422.88 |
| zip |
5.01 |
11.27 |
17.35 |
| 7zip |
20.37 |
207.11 |
454.99 |
| lzh |
NoData |
17.95 |
NoData |
● 圧縮率(圧縮後容量:Byte | 圧縮率:%)
| |
最速処理速度 |
速度指定無し |
最高圧縮率 |
| 圧縮後容量 |
圧縮率 |
圧縮後容量 |
圧縮率 |
圧縮後容量 |
圧縮率 |
| gzip |
69740928(66.51M) |
13.199 |
56342711(53.73M) |
10.663 |
53053857(50.60M) |
10.041 |
| bzip2 |
47765217(45.55M) |
9.040 |
39473917(37.65M) |
7.471 |
39473917(37.65M) |
7.471 |
| xz |
52814696(50.37M) |
9.995 |
39297448(37.48M) |
7.437 |
34627800(33.02M) |
6.553 |
| zip |
69741068(66.51M) |
13.199 |
56342850(53.73M) |
10.663 |
53053996(50.60M) |
10.040 |
| 7zip |
49351228(47.06M) |
9.340 |
45921512(43.79M) |
8.691 |
34625193(33.02M) |
6.553 |
| lzh |
NoData |
– |
56100468(53.50M) |
11.185 |
NoData |
– |
………
◆ バイナリ(LiveCD)ファイル [元ファイルサイズ:680525824(649M)Byte]
● 処理速度(単位:秒)
| |
最速処理速度 |
速度指定無し |
最高圧縮率 |
| gzip |
27.26 |
29.38 |
29.57 |
| bzip2 |
160.31 |
203.46 |
199.18 |
| xz |
118.53 |
289.40 |
378.48 |
| zip |
24.43 |
26.00 |
25.84 |
| 7zip |
137.07 |
313.51 |
571.32 |
| lzh |
NoData |
56.43 |
NoData |
● 圧縮率(圧縮後容量:Byte | 圧縮率:%)
| |
最速処理速度 |
速度指定無し |
最高圧縮率 |
| 圧縮後容量 |
圧縮率 |
圧縮後容量 |
圧縮率 |
圧縮後容量 |
圧縮率 |
| gzip |
663346521(632.62M) |
97.476 |
662932387(632.22M) |
97.415 |
662931421(632.22M) |
97.416 |
| bzip2 |
671338147(640.24M) |
98.650 |
668833540(637.85M) |
98.282 |
668833540(637.85M) |
98.282 |
| xz |
662375208(631.69M) |
97.333 |
657594464(627.13M) |
96.630 |
657235092(626.79M) |
96.577 |
| zip |
663346660(632.62M) |
97.476 |
662932526(623.22M) |
97.415 |
662931560(632.22M) |
97.415 |
| 7zip |
666778042(635.89M) |
97.980 |
661232857(630.60M) |
97.165 |
661003682(630.38M) |
97.131 |
| lzh |
NoData |
– |
663947004(633.19M) |
97.564 |
NoData |
– |
計測の生データはこちら
テキストファイルでは圧縮速度最重視だとgzip、圧縮率最重視だとxzという結果になった。
しかし、圧縮後容量を見るとgzipとxzだと結構差のある結果に。
ログとかだと年単位で取得とかになるので、たかが数メガでも1年分(x365)するととんでもない事に。
そういう実用面を考えると、bzip2で最高ブロック数指定がバランスを取れているのかもしれない。
意外だったのが、テキストで最高圧縮率指定だと7zipが一番縮んだ事。
実行前は『xzが一番縮むだろうな～』と予想していただけに驚きだった。
その分、処理時間も一番長かったので実用面では工夫しないといけないだろうが(´・ω・｀)
バイナリファイルの圧縮率ではxzの一人勝ちだった。
しかし、処理速度観点で見るとgzipとzipの一騎打ちに。
昔から使われているgzipとzipだけあって、様々なシーンでの高速処理が目に見えた結果だった。
圧縮処理については賛否両論あるし、それぞれのシーンによって使い分けるのが一番良いのだろうが、
実用シーンではbzip2がオールマイティに使えると感じた結果になりましたとさ(｀・ω・´)
…と言いつつ、自鯖のlogrotateは未だにgzipなわけですが
« 続きを隠す
