技術系なぶろぐ
続・自家製アプコン
ずいぶん前に、Waifu2X を使った自家製アプコンの話を書いたんですが、そのアップデートです。
あの記事書いたのが2016年なんで、もう6年も前。そりゃぁ世の中で技術革新は進んでますよね。
Cupscaleというツールと、Real-ESRGANというツールです
なお、Real-ESRGANは、このページで説明されているツールを使うと楽に使えます。
さて、では早速結果を見てみましょう。
画像は、左上がオリジナル、左下が Waifu2X でアップスキャンしたもの、右が Real-ESRGAN でアップスキャンしたものです。
懐かしい新世紀エヴァンゲリオンのオープニングです。
え?懐かしくない?ついこの前、映画館でみた??ふっ、君はそれをLDで見たことあるかい?え?LDってなんですか?
いやまぁ、そう言われるわな・・・・
これは、1995年にテレビ放送された最初のエヴァンゲリオン、そのLDをキャプチャしたものです。LDが何かは・・・ググってくれ。CDに対するアナログレコード、DVDに対するLDみたいな位置づけですね。CDとかDVDがそろそろ通じなくなりつつある時代ではありますが。
というわけで、Real-ESRGAN を使えばいいんじゃないかな。を結論に終わってもいいんですが、それだけだとアレなので、もう少し比較してみましょう。
Cupscaleの比較
Cupscaleには3個のモデルが搭載されています。そのモデルの結果を比較します。
左上が BSRGAN、右上が RealESRGAN-4xplus、下が RealSR_DF4K
RealSR は論外として、BSRGAN と RealESRGAN はいい勝負をしてるように見えますが、相対的に RealESRGAN のほうが綺麗に見えます。
CupscaleとReal-ESRGANの比較
二つツールがあるので、そっちも比較しましょう。Cupscale の realesrgan-4xplus と Real-ESRGAN です。これって同じモデルってことで・・・いいんですよね?
左が Cupscale の realesrgan-4xplus、右が Real-ESRGAN です。
Real-ESRGAN のほうが綺麗に見えます。同じモデルだけど、学習のさせ方とか実装がなにか違うんでしょうか。
GPU処理とCPU処理の比較
Cupscale は CPU モードを持ってるので、GPU を使わない、CPU 処理も比較してみましょう。
左がGPU処理、右がCPU処理です。これはさすがに同じに見えます。
ツールは Cupscale の BSRGAN です。というか、CPU モードで走るのはこのモデルのみです。
なんでこんな比較をしてるかというと、私としてはCPU処理を使いたいのです。だって仮想環境だとGPUができないから。いや、できないわけではないんですが、仮想環境でGPU使おうと思ったら、くっそ高い専用GPUカードとくっそ高い専用ドライバー使うか、PCIパススルー使うから vMotion を諦めないといけなくなるので、やりたくないんですよね。なので、CPU モードで使いたいんですが、BSRGAN しか使えないので、これで妥協するか、GPU 使える物理マシンで Real-ESRGAN をやるかですね。
結論
画質で Real-ESRGAN の勝利です。
動画にした結果も置いておきましょう。2016年にやった、AIR の DVD に入ってる ED から一部を取り出したものです。元動画は2016年の記事を参照してください。
あと、このリンク、ブラウザでは再生できないかもしれません。その場合はダウンロードして再生してください。少なくともVLCでは再生できるはずです。
最後にもひとつ、アプコン処理にかかる時間の問題が。
Cupscale、Real-ESRGAN どちらもめっちゃ時間がかかります。Waifu2X も相当時間かかりましたが、それよりはるかにかかります。
サンプル用に置いた AIR の動画、動画としては23秒程度の長さなんですが、これを1本処理するのに、Waifu2X で3、4時間くらいかかるのに対して、Cupscale、Real-ESRGAN は 1 日以上かかります。25分のアニメを1本処理するのに、単純計算で2か月以上かかることに。Waifu2X で2週間弱かかってたものが、けた違いに時間がかかることになります。
Fortigate で OSPF over IPsec
こんなネットワークを運用したい!
まぁ、天体撮影をするときのステラショットを動かすパソコンで使う話なんですけどね。
望遠鏡につながるパソコン、つまりステラショットを動かすマシンです。ステラショットさえ動けば良いという考え方もあるんですが、そうはいきません。
ステラショットをリモートで使いたいので、RDPします。RDPするためのIPアドレス管理どうする?んなもん、AD任せでしょ!
撮影後のデータは?とーぜんファイルサーバに置かないといけません。
つまり、普段のサーバサービスを受けられる環境にしないといけないのです。
- 自宅ベランダで使うときは、家庭内LANにつなげばいい
- 遠征時はモバイルルータ経由で家庭内LANにつなぎたい
これで出てくるのがサテライトネットワークです。
サテライトネットワーク用のサテライトRouterは、家庭内LANにつないだらLocal Routerとして、モバイルルータにつなげばVPN Routerとして動作するわけです。
なお、この設定、すんごーく長くて面倒です。OSPF over IPsecをやりたいという方は覚悟して挑んでください。
Local Routerの設定
Local Routerとしての設定です。なお、サテライトRouterには、FortiWiFiを使ってます。無線が使えた方が便利ですからね。
なお、OSPFしゃべたり、DHCPでアドレスもらったりしますが、そんなのは家庭内LANで動いてて当たり前でしょうから、ここでは省略
インターフェースの設定
config system interface
edit "wan1"
set mode dhcp
set allowaccess ping fgfm auto-ipsec
set defaultgw enable
next
edit "internal"
set ip 10.B.6.1 255.255.255.0
next
edit "wifi"set ip 10.B.7.1 255.255.255.0
next
edit "lo0"
set ip 10.A.A.102 255.255.255.255
set type loopback
next
end
ポイントは
- WAN1インターフェースをDHCPクライアントにすること
- Loopbackインターフェースに有意なアドレスを振ること
Firewallポリシー
config firewall policy
edit 1
set srcintf "internal"
set dstintf "wan1"
set srcaddr "LAN"
set dstaddr "all"
set action accept
set service "ALL"
next
edit 3
set srcintf "wifi"
set dstintf "wan1"
set srcaddr "LAN"
set dstaddr "all"
set action accept
set service "ALL"
next
end
ここは特にポイントはないかと。サテライトルータの配下から通信を許可してるだけです。
OSPFの設定
config router ospf
config area
edit 0.0.0.0
next
end
config network
edit 1
set prefix 10.C.C.0 255.255.255.0
next
end
config redistribute "connected"
set status enable
end
set router-id 10.A.A.102
end
これもごくふつーのOSPFの設定です。
Loopback インターフェースに有意なアドレスを振ったのは、OSPFのRouter IDとして使用するためですね。
はい、ここまでは準備
VPNルータとしての設定
さて、本題です。「サテライトRouter」と「VPN Router」間でIPsec VPNを結びます。
なお、IPsec VPNです。L2TP over IPsec はやりません。意味ないですからね。なんか世の中、IPsecはL2TPと組み合わせて使うもんだと思ってる人いるみたいですけど、そんなわけない。IPsecはIPsecだけで使うもんです。
インターフェースの設定
config system interface
edit "wan2"
set mode dhcp
set defaultgw enable
next
end
これはWAN2にモバイルルータをつなぐだけの話。これはサクッと流しましょう。
IPsecの設定
IPsecに関する設定です。これはPeer感で整合をとらないといけないので、サテライトRouterと、VPN Router両方の設定が必要です。
サテライトRouterの設定
config vpn ipsec phase1-interface
edit "Satlite"
set interface "wan2"
set dhgrp 14
set mode aggressive
set proposal aes256-sha256
set localid "Satlite"
set remote-gw *.*.*.*
set psksecret ***********
next
end
config vpn ipsec phase2-interface
edit "Satlite"
set auto-negotiate enable
set phase1name "Satlite"
set dst-subnet 10.0.0.0 255.0.0.0
set src-subnet 10.0.0.0 255.0.0.0
next
edit "Multicast-inbound"
set auto-negotiate enable
set phase1name "Satlite"
set dst-subnet 10.0.0.0 255.0.0.0
set src-subnet 224.0.0.0 255.0.0.0
next
edit "Multicast-outbound"
set auto-negotiate enable
set phase1name "Satlite"
set dst-subnet 224.0.0.0 255.0.0.0
set src-subnet 10.0.0.0 255.0.0.0
next
end
config system interface
edit "Satlite"
set vdom "root"
set ip 10.B.5.2 255.255.255.255
set type tunnel
set remote-ip 10.B.5.1
set interface "wan2"
next
end
※ SPFパラメータ等を省略してます。必要なパラメータは随時足してください。多分GUIで設定すれば入ります
さて、この設定にはいくつかポイントがあります。
- Aggressiveモードをつかう
- NAT Traversalを有効にする(上記Configには表れてませんが)
- DPDを有効にする(上記Configには表れてませんが)
- Phase-II に3個のルールを設定する
- メイントラフィックを担うルールは 0.0.0.0/0 で設定しない
- コマンドラインで操作するときは、トンネルインターフェースはIPsecの設定を行ったあとでしか設定できない
サテライト側をモバイルルータでつなぐんですから、当然アドレスは不定。なんで当然のようにAggressiveモード、NAT-Tを使わないといけないんですが・・・・
なぜか世の中には、ダイナミックアドレスなのに、Mainモードを使わせる製品があるんですよね。RFC読んで出直してこい。
VPN Routerの設定
config vpn ipsec phase1-interface
edit "VPN"
set type dynamic
set keylife 1800
set mode aggressive
set proposal aes256-sha256
set dpd on-idle
set dhgrp 14
set peerid "Satlite"
set psksecret ***********
set dpd-retryinterval 60
next
end
config vpn ipsec phase2-interface
edit "VPN"
set phase1name "VPN"
set src-subnet 10.0.0.0 255.0.0.0
set dst-subnet 10.0.0.0 255.0.0.0
next
edit "outbound"
set phase1name "VPN"
set src-subnet 10.0.0.0 255.0.0.0
set dst-subnet 224.0.0.0 255.0.0.0
next
edit "inbound"
set phase1name "VPN"
set src-subnet 224.0.0.0 255.0.0.0
set dst-subnet 10.0.0.0 255.0.0.0
next
end
config system interface
edit "VPN"
set vdom "root"
set ip 10.B.5.1 255.255.255.255
set type tunnel
set remote-ip 10.B.5.2 255.255.255.255
next
end
VPNセンタールータとしての設定ですね。
サテライト側に対応する設定です。
ちょっと解説
VPN関連はポイントがあるので、ちょこっと解説。
OSPF over IPsecをやりたいわけですから、当然ながらOSPFパケットをIPsecトンネル内を通します。OSPFはマルチキャストで通信するので、OSPFのマルチキャストアドレス 224.0.0.5 宛のパケットが飛び交います。
ここで注意しないといけないのが、IPsecの設定にあるアドレスセレクター。アドレスセレクタに 10.0.0.0/8 <--> 10.0.0.0/8 を設定すればわかりやすいのですが、アドレスの値としてみれば、マルチキャストアドレスは対象外になります。
ここでFortigateの仕様が関係してきます。Fortigateはアドレスセレクタから外れたパケットは遮断してしまうようです。何を当たり前のことを?と思う方もいらっしゃるでしょうが、これ、ルータの仕様によって動作が違います。アドレスセレクタから外れたパケットを投げ込んだ場合、遮断する製品、透過させる製品、通したいパケットに応じてPhase-IIネゴシエーションを開始する製品。しかも、こういう詳しい仕様はドキュメント化されてないことがほとんどです。Fortigateは遮断してしまうようです。
なので、メインのトラフィックを通すルール、マルチキャストのInbound / Outboundを各々通すルール、合わせて3個のルールが必要になります。
「じゃあ、0.0.0.0/0でルール作って、ルーティングで制御すりゃいいだろ」その通りと言いたいのですが、残念ながらそれもできません。これもFortigateの仕様ですが、FortigateのIPsecはSAが確立すると、セレクタに応じた静的経路を自動登録します。つまり、Default Routeを書き換えられてしまい、ISAKMPパケット、ESPパケットの通信経路が変わってしまいます。
Firewallポリシーの設定
config firewall policy
edit 6
set srcintf "wifi"
set dstintf "Satlite"
set srcaddr "LAN"
set dstaddr "LAN"
set action accept
set service "ALL"
next
edit 8
set srcintf "internal"
set dstintf "Satlite"
set srcaddr "LAN"
set dstaddr "LAN"
set action accept
set service "ALL"
next
edit 9
set srcintf "Satlite"
set dstintf "internal"
set srcaddr "LAN"
set dstaddr "LAN"
set action accept
set service "ALL"
next
end
サテライトRouter側のFirewallポリシー設定です。トンネル用のインターフェースを作ったんだから、新たなルールが必要です。Fortigate使ってるんだから、当たり前だろ?と思うんですが、これも注意ポイントの一つ。
このポリシーは必ず必要です。いや、そりゃそーだろって話なんですが、そうじゃなくて
IPsecの設定したら、まずはIPsecが繋がるかを試験して、それからポリシー設定しようか、って思いますよね。そうするとハマります。
これもFortigateの仕様っぽいんですが、FortigateはIPsecを設定しても、IPsecを通した通信が許可されるようFirewallが設定されてないと、ISAKMPのネゴシエーションが失敗します。その時にデバッグ画面で記録されるエラーがこれ。
ike Negotiate ISAKMP SA Error: ike 0:***************/0000000000000000:537: no SA proposal chosen
ちょっとまて、なんで no SA proposal chosen なんだよ!
そのエラーは、SAプロポーザルが食い違ってるときに出すもんだろ?!暗号アルゴリズムも、HASアルゴリズムも、DHグループも、SA寿命もいくら見直しても間違ってない。なのに、no proposal chosenと言われる。訳が分からないよ!!と叫びたい。
OSPFの設定
最後にOSPFの設定。といっても、この記事がOSPF over IPsecをやる。って話なんで、これが本丸なんですが。
サテライトRouter
config router ospf
config network
edit 2
set prefix 10.B.5.0 255.255.255.0
next
end
config ospf-interface
edit "OSPF-Satlite"
set interface "Satlite"
set mtu 1400
next
end
end
OSPFの設定を、ネットワークとインターフェース両方に対して入れないとダメみたいです。インターフェースはトンネルインターフェースがあるので、それを設定すればいいんですが、ネットワークも必要です。なので、トンネルインターフェースをNumberdで作って、そのアドレスに対してOSPFを設定する必要があります。
あと、ポイントが MTU の設定をすること。
OSPFはネゴシエーションの中でMTUを交換して、値があってないとネゴシエーションが進みません。OSFPのステータスが Exchange から進まない場合は、MTUがあってない可能性があります。
本来であれば、トンネルインターフェースのMUTを設定したいところですが、FortigateのトンネルインターフェースはMTU設定ができないようです。なので、OSPFのインターフェースでMTUを設定します。
以上!
長かった・・・・
VMware Player上の仮想マシンからホストにリモートデスクトップ接続する
リモート天体撮影するということ
リモートデスクトップの話ですが、起源は天体写真のための環境のお話です。
うちの天体撮影はこんな環境でやってます。
右上の望遠鏡と、そこにつながる小型パソコン・ルータをベランダに設置します。望遠鏡というか赤道儀の制御や、カメラのコントロール、撮影データの取り込みするため、シリアルケーブルやUSBを繋ぐ小型パソコンを望遠鏡の近くに置く必要があります。あ、別に小型でなくてもいいですけどね?
で、その小型パソコン上でステラショット2を動かすわけですから当然、小型パソコンのGUIを操作する必要があります。どうするか?コンソール端末からリモートデスクトップ接続します。
RDP接続なわけですから、とーぜんLAN経由ですね。なんでこんなことするのか?望遠鏡はベランダに置かないといけません。ベランダは夏暑くて、冬寒いです。でもコンソール端末はネットワークさえつながれば、どこへ置いても問題ありません。コタツの上でも、エアコンが効いた室内でも。
天体観測の最大の難点は屋外で暑い!寒い!!虫がでる!!!と屋外だからこその居住性。それを屋内からできるようになるのです。
リモートデスクトップとステラショット2の問題
さて、ここで問題がひとつ。ステラショット2のバグというか制限事項です。
これが普通にステラショット2を起動した状態。何も問題はありません。正常な状態です。でこの状態にしたまま、リモートデスクトップを切断(ログオフではなく、RDPの「切断」)をして、再度RDPを接続します。
すると、
この通り、星図が表示されなくなります。赤道儀制御とか撮影は問題なく動くんですが、星図だけが消えてしまうという。
アストロアーツ社に確認したところ、不具合として認識はしてるんだけど、DirectXの不具合だそうで、そう簡単には直らない制限事項だそうです。
まぁ、MSが原因なら、当分は直らんわな・・・・
んじゃどーするか?RDPを切らなければいい!そりゃそーだわな
だけど、なんとかしたい。だってコンソール機を移動したり、ステラショットに自動撮影させて、その間はコンソール接続を切ったりしたいわけですよ。
じゃあ、どうする?
こうします。リモートデスクトップ接続を2段階にして、ステラショット2からすると、セッションが切れてないように見せかけるわけです。
仮想デスクトップはどうやるか?VMware Workstation Playerです。せっかくパソコンがあるんですから、そこにVMware Player入れて、Windowsを起動してやれば、踏み台用の仮想デスクトップができる。完璧!と考えたわけです。
が・・・・・・
VMware Player上の仮想デスクトップからホストにRDP接続する
ここで問題がでます。
こんな風に、ステラショット2と、VMware Player上でWindowsを起動します。マシンリソースの都合でWin7を使ってます。サポート切れ?そうですね?はい。
そして、仮想デスクトップにRDPで接続して、さらに仮想デスクトップからホストにRDP接続します。
すると、
こんなことになっちゃいます。分かりにくいでしょうけど、Koronaというのがホストマシン、Hikari が仮想デスクトップです。ちなみに、天文関連のマシンのホスト名はほかにOrihime、Sayaが居ます。天文関連マシンですからね、「見上げてごらん、夜空の星を。」から名前をもらってます。
どうなるかというと、仮想デスクトップからホストへのRDPが安定しません。仮想デスクトップも動作が異常に遅くなり、まともに操作できなくなります。
なぜなのか?どうやらRDPに原因があるようです。RDPのセッションが繋がった瞬間から動きがおかしくなります。また、VNCを使って同じことをしても問題が出ません。ホストマシン上で別ユーザでVMware Playerを起動した場合も問題は出ません。
さーてどうしたもんか。そうだ、Windows のサービスとして仮想マシンを起動したら?
というわけで、サービスとして登録して起動します。ポイントはsexeを使ってサービス登録すること、登録したサービスを Local Administrator 権限で起動すること。なんでかよく分かりませんが、Local System アカウントではうまく動きませんでした。
あと、Shutdown時の注意。仮想デスクトップにログインしてShutdownをしてから、ホストをSutdownすること。ホストShutdown時に仮想マシンもShutdownしてくれるといいんですが、どうやらPower Downをしちゃうようで、仮想マシンが壊れることがあります。
VMware Player の起動が異常に遅くなったのでライブラリを掃除してみた
VMware Player です。無償版のお話です。
注意:独自研究の結果です。マネする場合は自己責任で!
いつのころからか、VMware Playerを起動すると異常に時間がかかるようになりました。
こんな感じで、「応答なし」の状態が数分続きます。
ただでさえ、この後にOSの起動があって、それなりに時間かかるんだから、こんなところで止まって欲しくない。なんでここで時間かかるんぢゃ??と思ってたんですが・・・
原因はこれ
スクロールバーの長さに注目。仮想マシンおおすぎ!!
しかも、vmx に接続できない仮想マシンもちらほら。
どーやら、VMware Player起動時にライブラリに登録されてる全仮想マシンのvmxファイルを読んで、ライブラリを再構築しようとしてるみたい。そんな中で開けないvmxがあったり、そもそも開くべきvmxが多かったら、そりゃぁ時間かかりますわな。
なわけで、ライブラリを整理しましょう。GUI画面で一個づつ「ライブラリから削除」をやっていってもいいんですが・・・・仮想マシンを1個削除すると、そのたびにライブラリ画面の再構築をしようするらしく、仮想マシンを1台登録解除するたびに数分かかる。やってられっか!
というわけで、仮想マシンライブラリの一括削除を考えます。
答えは、このファイル
C:\Users\<USERNAME>\AppData\Roaming\VMware\preferenceini
このファイルを編集します。
こんな大変なことになってるファイルをばっさりと、
こんな感じにばっさりと。
すると、
あっさり起動します。
一時ファイルの作成中にエラーが発生しました とか言い出して、仮想マシンが起動しない
仮想マシンをvMotionしようとしたら、一般的なエラーとか意味不明なエラーを出して移行できなくなった。
なんじゃ??と思って、VMをShutdownして、もう一回起動。そしたら、こんなエラーががががが
とーりあえず、仮想マシンをインベントリから削除して、再登録してみる。結果変わらず。
構成ファイルと同じところにできてる、vmware.log を確認してみる。なにやら、こんなエラーメッセージが
vmx| I120: FileIO_AtomicTempFile: Failed to create temporary file, The file already exists (3). errno: 17
vmx| I120: Msg_Reset:
vmx| I120: [msg.configdb.failcreatetemp] An error occurred while creating temporary file for /vmfs/volumes/5f883c54-1bd774f2-f870-f8db88fbe1d4/***/***.vmx: The file already exists
一時ファイルの作成に失敗とか言ってる。
VMware ってGUIに表示されるエラーと、本当のエラーが食い違ってることがたまにあって、GUIのエラーメッセージはあまり信用しないほうがいいんですが、どうやら今回は一致している模様。
さーて、一時ファイルと言ってもなぁ・・・・・
とりあえず、構成ディレクトリを見てみよう。
ん・・・??なんだこれ??
※ ホスト名が見えるところは、念のためマスクしてます
**.vmx~ ファイルってなんぞや?それがないって言ってるけど、ls にもともと出てないんだから、そりゃファイルはないわな?なんでわざわざ No Such file or directory と言う??
ただ、どうやら .vmx~ っていうファイルは、VMware のロックファイルで使うっぽい。となると、「ファイルがすでにあるから、一時ファイルが作れねぇ!」っていうメッセージと整合する。。。。ような気がする。
とーりあえず、これが原因かな?ってことで、対処してみる。
とはいえ、存在しないと言ってるファイルなんてどーやって消すんだよ?
消せないなら、そんな亡霊ファイルが見えなくなりゃそれでいいだろ。ってことで、こんな手順
- 仮想マシンをVMwareのインベントリから削除(決してディスクから削除ではない)
- ESXにSSHでログイン
- 仮想マシン構成ファイルのディレクトリ名を変更
- 仮想マシン構成ファイルディレクトリを新規作成
- 旧ディレクトリから、vmxとかvmdkとかその他仮想マシンを構成するファイルを新ディレクトリに移動
- 新ディレクトリに置いたvmxファイルを使って仮想マシン登録
- 仮想マシン起動!
無事起動しました。
今回問題になった仮想マシンが、iSCSI のファイルシステムにおいてたので、ESX 上の Shell で操作してます。NFSボリュームだったら、ほかのマシンからマウントして操作するとか、もうちょっとやりやすかったかも。