2020年06月14日(日) - 19:35 | カテゴリ:
Linux
自鯖刷新によって様々なインフラを見直したのだが、実は権威DNSの構成変更は行わなかった。
刷新直前にグローバルロードバランサを組み込む構成変更を行ったのと、
権威DNSが止まるとサービス停止に陥るので、見直しをした上で安全重視で従来構成を踏襲した。
権威DNSは、グローバルIPを応答するインターネット向け権威DNS(インターネットドメイン)と、
プライベートIPを応答するイントラ向け権威DNS(ローカルネットドメイン)で分離する構成にしている。
インターネットドメインの方は、前回の権威DNS構成変更から基本設計を変更せず、
フロントエンドにdnsdist・バックエンドにBINDとgdnsdで処理する様にしている。
ローカルドメインは親ドメインを管理するBINDを最上位に構えつつ、
下位の権威DNSにサブドメインを委任する構成を取っている。
インターネットドメインは『dnsdist + BIND + gdnsd』の複合構成、
ローカルネットドメインは『BIND』単一構成と『dnsdist + PowerDNS』複合構成にした。
世間では、BIND脱却の為にNSDやPowerDNSを利用する機会も増えてきており、
いざという時に追従出来ないのは問題なので、少し囓った事のあるPowerDNSを使っている。

「自宅サーバでここまで必要か」と言われると不要だと思うが、
本職絡みでもDNSサーバ知識が必須なので、技術検証を柔軟に出来る様に上記構成を取っている。
………
今回のサーバ刷新時に構成変更を行っていないので紹介出来る内容が少なかった (´・ω・`)
唯一の変更点は、レジストラに管理を委任していた他の検証ドメインも集約化を行い、
正引き・逆引き合わせて最終的に9ドメインを管理する体制にした事。
また、ドメイン集約化を行った事でドメイン管理が複雑化したので、
従来利用していたDNSゾーン適用ansibleを見直し、マルチドメインでも簡単に管理出来る様にした。
自鯖の刷新前後を比較して大きな変更点が無い為、権威DNSについて書く事も少なくなくなった。
とは言っても自鯖刷新で大きく構成変更した、仮想サーバ基盤と録画サーバはまだ紹介出来ていないので、
近いうちに書こうと思う。
2020年06月10日(水) - 22:50 | カテゴリ:
Network
今までは、PPPoE+IPv4固定+NVR500の回線環境を使っていたが、最近は速度遅延が顕著になっていた。
特に4月末辺りから遅延が酷くなり、一番酷い時では1Mbps程度まで悪化していた。
また、10年前の機種となるNVR500ではスペック不足の場面も増えており、
TCPセッションを複数張るWebアプリを使い続けると、セッションテーブルを食い潰しそうになっていた。
NVR500が発売された2010年と現在を比較すると、Webアプリ台頭によって通信特性も大きく変化しており、
NATセッション数4,096・RAM搭載量64MBでは心許ないのが主な原因であり、
NVR500のサポートしているダイナミックルーティングプロトコルが少ないのも課題の一つだった。
今までは自宅サーバで公開Webサーバを動かしていた事もあり、品質重視のIPv4固定回線を使っていたが、
先日完了した自宅サーバ刷新によって、公開Webサーバも別拠点の仮想サーバに引っ越した上、
バックボーンにはメイン回線とは別のISPを使ったVPN型に変更したので、
通信品質重視の従来回線を使う必要性が下がっていた。
………
以前もIPoE引越しを検討した事があったのだが、検討当時はIPv4専有オプションが無かったので諦めていた。
しかし、世間から要望が多かったのかVNEでもIPv4アドレス専有オプションを提供開始した上、
JPNEのIPv4専有オプションを使ったサービスとして、
IPQ・OpenCircuit・interlinkがアドレス専有オプションをリリースしていた。
通信遅延・IPv4専有オプション・回線維持の必要性低下を総合的に考えると、
IPoE+IPv4専有オプションに移った方がメリットがある為、IPQ提供のIPoE+IPv4専有接続に変更しつつ、
ルータの処理速度を上げる為にも、メイン回線収容ルータをNVR500からRTX830に刷新してみた。

大まかなNW構成は下記の通り。メイン回線の収容ルータをYAMAHA RTX830に刷新しつつ、
コアルータ・端末用ゲートウェイは従来通りCisco 891Fを継続利用する構成にした。
ルータ間にCisco Catalyst 2960SなどL2SWが各種挟まっているが、
全リンクを1G以上でリンクアップさせており、速度低下が起きない様にしてある。

この状態で、CentOSインストーラを複数ダウンロードして負荷をかけると、
ルータのCPU負荷は下記の様になった。
YAMAHA RTX830 |
Cisco 891F [コア] |
Cisco 891F [GW] |
 |
 |
 |
実測200Mbps程度とは言っても、平均CPU負荷が7~10%に納まっているのは驚いた。
RTX830と891Fを比較すると一目瞭然で、同容量を流しているのにCPU負荷が全然違う結果になった。
………
NW回線速度測地絵サイトを使ってみた結果は下記の通り。
JPNEがKDDI系ネットワークな事もありKDDI回線の方が有利なのだが、軒並み250Mbpsは出せた。
- [6/7 21:20~21:25] KDDI スピードチェック
- [6/7 21:25~21:35] Radish Network Speed Testing 東京
- [6/7 21:35~21:40] USEN インターネット回線スピードテスト
- [6/7 21:40~21:45] Google インターネット速度テスト
………
IPoEを1週間弱使っているが、今まで問題になっていた速度遅延が起きる事は無かった。
今回はIPv4専有オプションも付けており、インターネットからの接続も出来るので従来の様な自鯖公開も出来る上、
IPQの特典として逆引き登録も出来るので、むしろ今までよりも機能充実を測れた。
NTTがIPoE先行で10Gサービスを提供した事も考えると、今後はIPoE接続が主流になっていくのかも知れない。
速度速い・IPv6ネイティブ接続・輻輳POIバイパスと、良い事ずくめに思えるが、
IPoEを使うにはYAMAHAルータを弄れる位のネットワーク知識は必要なので、普及するのは当面先になると思う。
さらに、IPoE利用時のIPv4トンネル接続は、普通の場合アドレス共有型となるので、
ネトゲをやる様な人は通信要件を満たせないかも知れない。
この辺りは、NW機器メーカーと広報活動に頑張ってもらいたい所。
………
今回のメインプロバイダ変更にはそれなりの手間がかかった。
IPv6バイパストンネル(IP-IPトンネル)によって、通信速度遅延が改善した事もあり当面はこのまま維持する予定。
10年前のルータを使い続けると処理・機能不足が否めないので、筆者にとっては良いメイン回線刷新イベントとなった。
« 続きを隠す
2020年06月06日(土) - 19:41 | カテゴリ:
PC
弄り倒してないので、今回は購入報告のみ掲載ーーー
テレワーク増加によってWebカメラの品薄問題が出てきたりしているが、
筆者はノートPCに搭載しているWebカメラを使っているので騒動は回避できている。
そんな中、情報源として読んでいるINTERNET Watchを見ていたら、
ネットワークカメラとしつつも、ファーム書き換えでUSB接続Webカメラとしても使える、
ATOM Camについて特集が組まれていた。
普段ならスルーするのだが、クラウドファンディングから誕生した物で価格以上に多機能なのと、
実売2,500~3,000円とかなり安い事もあり、物は試しで買ってみた。

録画機能を試す為にSDカードも購入。安かったので16GBを購入。

内容物は、カメラ本体・取扱説明書・電源ケーブル・電源アダプタの4つ。
パッケージ自体も簡素化しており、プチプチの様な緩衝材は無く、代わりに段ボールで固定してあった。
ATOM CamはAndroid/iOSのアプリから設定を行うので、端末が別途必要になる。
アプリのUIはシンプル設計になっておりマニュアルを読まなくても何とかなる。
筆者の場合、実測5分程度でカメラと端末でペアリングが完了した。
HD画質で撮影している時のNWトラフィックは、100~200KB程度でWebカメラとしては軽め。
5GHz無線では動かないがIPv4/IPv6関係なく正常動作し、カメラをIPv4にした上でNAT64/DNS64でも接続出来た。
通信を見た限り、HTTPSでセッションを張れればピアリングできる模様。
解析途中なのでまだ詳細を書けないが、ファームウェアを改造して流し込めばSSHログインも出来そう。
ひとまず、kernel 3.10を使っている事と、U-Boot形式なのはわかった。
欠点といえば、アプリケーションで左右パンが出来ないのと、Webカメラ本体にAPIが無い事。
前者は物理機構が必要になるので低価格に抑える為に切り捨てるのは仕方ないと思うが、
APIは是非とも実装してもらいたい所。
そうすれば、自宅サーバと連携してAPIを叩く事が可能となり、ATOM Camのメリットがさらに上がると思う。
是非とも今後のファームウェア改良に期待したい。
« 続きを隠す