プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

QNAP NAS out of memory が起こりました

いまごろ公開してますが、去年(2018年)の12月頃の出来事でした。

2台の QNAP (TS-251+, TS-231P, QTS バージョンはいまとなっては不明ですが、両方ともたぶん 4.3.5.0760 あたりだと思います) で NAS to NAS のバックアップテストをしていたら、 メールに NAS out of memory のエラーメールが飛んできました。

内容を確認すると、

  Simple yet powerful NAS   <http://www.qnap.com/>Go to QNAP  

[Warning][nas01] Hardware Status

NAS Name: nas01
Severity: Warning
Date/Time: 2018/12/02 06:46:02

App Name: Hardware Status
Category: Kernel
Message: [Hardware Status] NAS out of memory. Started kill process: 21074 "wizReq.cgi". Disable some applications to free up memory, or expand the system memory.

<http://www.qnap.com>(c)2018 QNAP Systems, Inc.

というものです。 wizReq.cgi ってのをキーワードにして検索してみると、

WizReq.cgi - high memory usage - QNAP NAS Community Forum

というディスカッションがありました。

どうも、 NAS to NAS でのバックアップに起因するエラーのようです。 このディスカッション先にあるように、 Backup Station から Hybrid backup Sync に切り替えてみて、再度試したところ問題なく動作するようになりました。

取り急ぎ、類似の症状で困ってる人もいるかもしれないのでメモっときます。

SoftEther VPN Server 設定の再確認

リモートアクセスVPN を QNAP 上で動かす』 で書いたように、外部から家のLAN環境に入るため、 SoftEther VPN Server を QNAP 上の VM で動かしています。

去年、ルータ買い替え(顛末はこちらの記事などご覧ください)&新しい仕事場に引っ越し、などいろいろとあり、その後、VPN 接続をきちんと試してなかったので、改めて試してみた話をメモっておきます。

設定確認

結論から言うと、リモートアクセスVPN を QNAP 上で動かす の記事と同じ設定のままで問題なく接続できました。
ちなみに、上記記事の時点から、QNAPのファームウェアをアップデートしていることもあり、ネットワーク周りの概要の画面はこんな感じになります。

f:id:junichim:20191205150326p:plain

ちなみに、今の状態は

  • ルータ NVR510 v15.01.14
  • QNAP, QTS 4.4.1.1117

です。

別の設定方法

実は、上記設定を試す際に、いろいろと試していたら、 VM に 仮想NICを2つ追加するところまでは同じようにして、 QNAP 上の仮想スイッチを追加せずとも VPN が構成できました。

f:id:junichim:20191205150841p:plain

こちらは、どちらかというと以前の ESXi での構成に近い感じですね(物理NICが一つで、仮想NICが2つ)。

まあ、考えてみれば当たり前なんですが、一応できるよ、ということで載せておきます。

余談

余談です。

実は、ルータ買い替え直後、新しいルーターで一度試したのですが、この時は、 VPN Server に接続できませんでした (こちらの記事にあるように、QNAP の再設定時に発覚しました)。

本来は NAT-T で何もしなくてもポートが開くことを期待していたのですが、なぜか(この時の)NVR510 の場合はうまくいかなかったようです。

でも、今回試した際は問題なく接続できました(当時の詳細な記録が残っていないため戻って検証できないのが残念です)。

VPN Server に接続できなかった後、引っ越しして、その後いろいろと変更したところとしては、

  • ルータのファームウェアアップデート v15.01.13 -> v15.01.14
  • QNAP のファームウェアアップデート 4.3.5.0760 かそれ以前 -> 4.3.6.0805 (4.4.1.1117 の前にこれでも接続に成功してます)

などがあります。
とはいえ、リリースノートなどを見ても関係しそうなところはないんですよねー。こうなるとまあ正直ちょっとわかんないですね。

少なくとも、現在の環境では問題なく動作しております。

参考

どこまで関係あるかわかりませんが、Yamaha ルータではNAT-Tが効かない、というような話もあるようです。

YAMAHA ルータと Splatoon 2 - mura日記 (halfrack)

でも、Yamahaルータのドキュメントでは、 NAT-T で使う UDP の場合は、 Symmetric NAT 相当にはならないようなので、どうなんでしょうかね? (TCP の場合はポートセービングIPマスカレードで動作して、この動作が Symmetric NAT と同じということのようです)

ちなみに、上記の記事で紹介されている STUNner を使ってみたら、いまの NVR510 は Port Restricted Cone NAT と判定されました。

f:id:junichim:20191205225651p:plain

Symmetric NAT だとか Port Restricted NAT ってなんだろう?と思い、ついでに調べてみると、こんな感じの説明がありました。

『なんとか cone NAT 』系のものは、『送信元の IPアドレスとポート番号が同じであれば、変換後のIPアドレスとポート番号も同じものを使う』というのがポイントのようです。 個別の違いは、外部からの通信があった場合に通すときの条件の違いのようです。
一方、 Symmetric NAT は送信元のIPアドレスとポート番号に加えて、送信先のIPアドレスとポート番号も含めて、変換後のIPアドレスとポート番号を決定する、というもののようです。

このため、cone NAT の場合は、下記記事に説明されているような手順で、 NAT 越えを実現することができるということです。

[24日目] NAT Traversalって知ってますか | Cerevo TechBlog

なるほど、勉強になりますね。

で、 NVR510 はこちらの記事中で触れらているように、UDPに対しては、ポートセービングIPマスカレードが使われず、 なんとか cone NAT 系の振る舞いをしているということのようです。

そうなるとますます、最初にNAT-Tが動いていないように見えたのが謎ですね。

ちなみに、最初は下記のサイトの説明からは、 port Restricted NAT と Symmetric NAT って一度送信した相手からしかNATを通さないので同じじゃない?って思ってしまいました。

NAT変換後のIPアドレスとポート番号の決め方についての話が抜けていたので、 port Restricted NAT と Symmetric NAT が同じように思えたようです。

あと、SoftEther で使ってる NAT-T については下記などが参考になりそうです。

VPN の NAT トラバーサル (UDP ホールパンチング) 機能 - 登 大遊 (Daiyuu Nobori) の個人日記

NATまわりはややこしいなー。

伊勢ギーク・フェア2019 に出展しました

先日、三重県伊勢市で開催された伊勢ギーク・フェアに出展してきました。 私自身は数年ぶりの参加でした。

公式のFacebookページはこちら

https://www.facebook.com/igfaire/

会場の様子

当日、準備しながら撮った会場の様子はこんな感じでした。

f:id:junichim:20191126140657j:plain

f:id:junichim:20191126140716j:plain

実際に現場にいると写真で見るより、ずっと人が多い感じでした。 小さい子供も多くて、ゲームしたりロボット動かしたりと楽しそうです。私の子供も短い時間ですが、ご多分に漏れず、ロボットを動かしてご満悦のようでした。

出展内容

当日出展したのは、

blog.mori-soft.com

blog.mori-soft.com

で作った、LINEボットからラズパイカメラで撮影する、というものです。

ブースの様子はこんな感じです。

f:id:junichim:20191126143549j:plain

(写真中のQRコードでボットと友達になっても、現在はなにもできないです。悪しからず。)

ラズパイ zero は小さくて気に入ってるんですが、ブースに置くと・・・迫力ないですね。 ちなみに、後ろ向きのディスプレイは設定作業やトラブル対応のために持っていったものです。こっちのほうが目立ってますね。

あと、個人的に一番モノづくりしたのは、机の上においてある段ボールの看板だったりしました。

振り返り

がっつりモノづくりしている方が多数いるのでが、来場者もそういうものを求めてるんだろうと予想し、 こちらにはあんまり人来ないだろうなと思っていたのですが、思ったより興味を持ってみてくれていた方が いらっしゃいました。
ありがとうございます。

さて、今回は、LINEボットからラズパイカメラで撮影するというのを出しましたが、実際に会場で 使ってみるといくつか気づいた点がありました。

写真を1回リクエストしたにも関わらず、3~4枚まとめて写真が送られてくる

イベント会場で試すと、このような現象が発生していました。

もっとも、これは私の仕込んだバグでした。

ラメラサーバー側の処理(node.js)をsetIntervalを使った繰り返し処理として書いたのですが、 呼び出した関数が非同期で戻ってくるのに気づいておりませんでした。

また、呼び出した関数の処理(写真撮影と画像アップロードとLINEへの投稿)が完了したら、 撮影指示を削除するという流れとしていました。

このため、最初に呼び出した撮影指示が終わらないうちに、またsetintervalから関数が呼ばれてしまい、 この時点では撮影指示ファイルがまだ残っているので、もう一度写真撮影の処理が呼ばれて・・・ というのを何度か繰り返した結果、複数枚の画像が返送される、という現象になっていました。

仕事場のWiFi環境だと気づかなかったのですが、イベント会場では、テザリング経由で ネットワークにつないでいたので、処理に時間がかかり、 問題が発覚したという次第です。

古い撮影指示が実行される

これはイベント時の問題ではないのですが、気になったのでメモを残しておきます。

上記の問題をイベント会場で手直ししていたので、イベント翌日、リポジトリに 反映させようとして、ラズパイに電源をつなぎました。

そうすると、ラズパイ側のカメラサーバーが自動起動して、S3 上の撮影指示を読みにいってしまいました(これ自体は動作としては正しいです)。

どうもイベント後や夜中に撮影指示を送った方もいたようで、カメラサーバー起動により、 朝一番に私の事務所の壁や天井の写真が送られたようです。 いきなり変なタイミングで変な写真が送られてしまいすいませんでした。

まあ、こんな事故が起こらないように、撮影指示のタイムスタンプを見て、 一定以上の時間が経過している場合は無視するようなロジックをいれる必要があることに気づきました。

動かさないとわからないことですね。 おいおい組み込んでいこうと思います。

まとめ

やっぱり、イベントは見るのもいいけど参加するほうがおもしろいですね。
来年も頑張って何か出したいな。