2022年02月05日(土) - 22:35 | カテゴリ:
Network
外部公開していない”ns-lab BB”サーバがインターネットへ通信する時、
NW経路の都合で仮想ルータを使ってNAPTする様にしている。
その仮想ルータにIIJ SEIL/x86を使っているのだが最新OSのAyameを弄る必要が出た。
というのも、IIJ SEIL/x86 Fujiが600円でばら撒かれていた時に購入したライセンスが尽きてしまい、
弾補充とAyame移行検証も兼ねてProxmox上の仮想インスタンスへ入れる事となった。
仮想インスタンスに割り当てたスペックは次の通り。
他にも仮想サーバが動いている環境だが、オーバーコミットしていないので遅延は少ない筈。
| CPU |
1コア (Intel Xeon D-1518 2.20GHz) |
| MEM |
1GB |
| HDD |
10GB (ZFS) |
| NIC |
virtio (100Mbps Limit) ×2 |


今回は10GBファイルをダウンロードするwgetを同時に3本実行して負荷をかけてみた。
上画像のターミナルはProxmox上のtopコマンドだが、SEILの仮想ゲストCPU負荷100%近かった。
下画像はSEILの負荷状況をSNMPで取得した物だが、こっちもCPU負荷が80%近くに上がっており、
両サイドから見たとしても負荷がかなり高い事がわかる。
今回は最低限のスペックしか割り当てていないので負荷が高い物と思われるが、
誤自宅が簡単に購入できるライセンスはCPU1コアの物なので、そもそも増強する事が難しい。
25万円出せばエンタープライズライセンスを購入出来るが石油王じゃないとこの金額を即出すのは辛い。
スタンダードライセンスでもCPUを2コアを積める様になれば速度を出せそうだが、
そんな環境はエンタープライズを買うか物理ルータを買えというお達しなんだと思う。
Fujiを利用している人がAyameを弄りだして面食らうのがコンフィグの作り方だと思う。
そもそもコマンド体系が全く違うのでドキュメント片手に格闘する必要が出てくるが、
SEIL弄っている人なら1時間弄れば慣れると思う。
実際に筆者も弄ってみたが2時間程度で大体の挙動とコマンド体系を覚える事が出来た。
結構よく出来ているのだが、Firewall設定の様に1行で多数のオプションを書くとバグる事があるので、
業務利用やコアな事をやるにはバグを飼いならすスキルと成熟が必要とも感じた。
慣れが必要な誤自宅向けルータではあるが、
Ciscoに程度慣れて違うメーカーに手を出したくなった人は是非とも弄ってもらいたい。
2022年01月30日(日) - 22:29 | カテゴリ:
Linux
自宅サーバで運用しているProxmoxにスタティックルートを設定しようとしたら、
Web GUIから追加する方法が分からなかったのでメモ。
結論を先に書くと、Web GUIから追加する事は出来ずCLIで設定を直接弄る必要があった。

筆者のProxmox環境では、各NICでサーバインスタンスのトラフィックを出しつつ、
ホストサーバにも接続出来る様にする必要があった為、
物理NIC→ブリッジ→管理I/Fの様に仮想NICを構成している。
この状態でセグメント毎に戻り通信を分散出来るようにスタティックルートを書きたかったのだが、
画像の通りWeb GUIではゲートウェイ(デフォルトルート)しか設定出来なかった。
同じ事を考えている人は多いと思うので調べてみたら次のフォーラムがヒットした。
要約すると、”/etc/network/interfaces”にスタティックルートを直記するのが唯一の手段らしい。
筆者はmgmt1の”OVS IntPort”にプライベートIP宛のルーティングを切りたかったので次の様にした。
$ cat /etc/network/interfaces
auto mgmt1
iface mgmt1 inet static
address 192.0.2.2/24
post-up route add -net 10.0.0.0/8 gw 192.0.2.1
post-up route add -net 172.16.0.0/12 gw 192.0.2.1
post-up route add -net 192.168.0.0/16 gw 192.0.2.1
ovs_type OVSIntPort
ovs_bridge vmbr1
|
細かく設定するならpost-downとルーティング削除も追加すべきだが、
そこまで厳密な制御は今回いらなかったので設定しなかった。
………
2022年末頃のProxmox VE 7.2までは”route add”で動いていたのだが、
Proxmox VE 7.3でバグってしまったので下記に変更した。
何回か再起動もしてみたが問題なく適用出来ている。
$ cat /etc/network/interfaces
auto mgmt1
iface mgmt1 inet static
address 192.0.2.2/24
post-up ip route add 10.0.0.0/8 via 192.0.2.1 dev ${IFACE}
post-up ip route add 172.16.0.0/12 via 192.0.2.1 dev ${IFACE}
post-up ip route add 192.168.0.0/16 via 192.0.2.1 dev ${IFACE}
pre-down ip route del 10.0.0.0/8 via 192.0.2.1 dev ${IFACE}
pre-down ip route del 172.16.0.0/12 via 192.0.2.1 dev ${IFACE}
pre-down ip route del 192.168.0.0/16 via 192.0.2.1 dev ${IFACE}
ovs_type OVSIntPort
ovs_bridge vmbr1
|
この設定でWeb GUIからmgmt1にデフォルトルートを切りなおしたり、
仮想NICのVLAN変更なども実施したが今の所問題なく動いている。
小技なのとDebian/Ubuntuに慣れた人ならお手の物だが、
RHEL使いやNetworkManagerを使っている人は意外と嵌るので備忘録としておく。
2022年01月19日(水) - 22:24 | カテゴリ:
PC
2020年に発売された初代ATOM Camが話題になってから早1年半。
上下左右のカメラ操作にも対応したカメラが同じメーカーから発売されたので1台買ってみた。

という事で、ATOM Cam Swingをゲット。
発売時は値引きセールもやっていたのだが、その時に買うのを忘れたので普通に定価購入。
Webカメラは様々なメーカーから出ているが、
ATOM Camの良いところは値段が安い割に多機能で様々な使い方が出来る点。
今回購入したのはSwingなのでカメラを上下左右に動かす事が出来るのだが、
同等の物を海外製品で探すと怪しいWebカメラしか対応している物が無かったりする。
ATOM CamシリーズもWYZE CAMのOEMではあるが、
出所がはっきりしているので有象無象の怪しい中国製よりは安心できるのもメリットの一つ。


開封直後の状態はこんな感じになっている。
外箱も驚くほど小さくWebカメラ本体がみっちりと詰まっていた。

電源はUSBポートから取る形式で専用ケーブルを利用する事となる。
カメラ本体は電源が詰まった部分とカメラを格納した部分の2つをダブルヒンジで接続している。


初代・二代目のATOM Camを縦に連結したような形で縦設置する事となる。
電源はmicro USB形式だが、防水と電圧確保の為に同梱ケーブルを使うように注意書きがあった。
筆者も同梱USBケーブルを接続しているが、流石にカッチリ嵌る様に作られていた。

ATOM Camなので録画用SDカードを入れる事が出来るが、
この部分もゴムパッキンで覆われており防水対策がちゃんとしていた。
左のRESETボタンは初期セットアップしたりカメラを初期化する時に使う物だが、
コレが結構深い所まで押す必要があり爪を立てないと反応しなかったりする。
また、セットアップ時の音声ガイド音量が大きく夜中だと近所迷惑になりそうだった。
この辺りはATOM Cam初代でも同様だったので直して欲しかったが、直っていなかった (´・ω・`)
動画撮影時のネットワーク帯域は100~200KB程度で他のWebカメラと大差無かった。
モバイルルータでは流石に不安だが、普通の固定回線を使っているなら問題なく使える帯域だった。
野外利用するなら無線接続は必須になると思うが、
ネットワーク帯域や解像度のバランスが上手く、どの利用シーンでも処理できるようになっている。
心残りなのはAPI操作に対応していない所。
この値段でAPIに対応するのは無理だと思うが、
ラズパイと組み合わせてAPIを叩けると一気に利用用途が広がるので実装して欲しいと感じた。
実稼働させて一週間も使っていないので実利用を元にしたレビューは出来ないが、
Webカメラとしてのポテンシャルは高い様に感じる。
暫くの間は起動させっぱなしにさせつつ実際の利用シーンを模索しようと思う。
« 続きを隠す