SOHO環境のNASをどうするか思案した結果、3ベイモデルのNASに行き着いたので、参考までにとりまとめておく。
SOHO向けNASの考察
SOHOにRAID5/6は不要
RAID5/6を構成できることを売り文句とする簡易NASが売られているが、安易にRAID5/6で構成してはいけません。RAID5/6の欠点も正しく知っている必要があります。
RAID5/6のHDDで物理障害が発生した場合には復旧は困難を極めます。例えばNAS本体が故障した場合、あるいは複数台のHDDが障害を起こした場合、これを普及するには同一型番のNAS本体なり、あるいはNASをマウントする専用のソフトウェアが必要になります。専用機材を持たない状態では手が出せないため、業者に委託せざる得なくなる可能性が高く、速やかな復旧は望めませんし、HDD4台程度のNASでも数十万の復旧費用がかかることになります。
RAID5/6のメリットはHDD1台では実現できない大容量を実現できる点、複数台のHDDに分散することで高速な読み書きを行える点にあります。ですが8TBのHDDでも、2TBのHDDでも容量単価は殆ど変わりません。大容量のメリットを得られるのは8TBを超えるパーティションが必要な時だけです。容量が8TB以下ならRAID1で十分です。高速化が必要ならRAID5/6よりもRAID10のほうが優れていますし、SSDをキャッシュとして使用するのも効果的です。
つまるところRAID5/6が必要なのは、RAID0/1/10では賄えないような、16TBを超える大きなパーティションが必要な場合に限られると言うことです。
SOHOならRAID1が理想
復旧作業を考えるならばRAID1が理想的です。よほど特殊なファイルシステムを採用していない限り、既存のPCでマウントするだけで直前に保存されたファイルも含めて復元することが出来ます。
高速性が必要ならSSDキャッシュを
高速性が必要ならSSDのキャッシュを設けた方が実効性が高いです。 RAID5/6/10でHDDの台数を増やすよりも 高い実効性を期待できる上に、先に述べたように復旧作業を考えるなら RAID5/6/10 は避けたいところです。
バックアップ機能も必要
RAIDにしているからと言ってバックアップが不要になるわけではありません。誤った操作によりファイルを上書きした場合など、バックアップがなければ対処できません。したがってバックアップ用のドライブも必要です。
出来れば世代別バックアップを行えるように、共有用パーティションの2倍程度の容量が必要です。
SOHO向けNASの まとめ
以上の条件を踏まえると、共有ストレージとしてRAID1を構築するためにHDDを2ドライブ、バックアップ先とするためにHDDを1ドライブ、合わせて3ドライブ以上のNASが必要ということになります。これに加えて、高速性も求めるならSSDをキャッシュとして利用できるもの必要です。
この条件を満たすNASを探していた時にたどり着いたのがQNAPの QNAP TS-332X/351/328のシリーズ。 他社だと2ドライブより上位のモデルは4ドライブになってしまい、少々オーバースペックとなってしまいます。ですが、QNAPのこのシリーズは 3.5インチのHDDを3台まで搭載できるというよく考えられた製品です。 TS-332X/351 ならSSDキャッシュを設けられるので速度面でも十分です。
ちなみにQNAPは中々尖った製品が多くて面白いです。比較的に安価なNASにも10GbE SFP+ポートを設けていたり、GPGPUやLGPAによる演算をサポートしていたり、仮想OSのホストになれたり、もはやNASの皮をかぶったサーバーですね。QSW-804-4Cなんかも10Gb HUBとしては最安値なんじゃないかな。
Oracleのバックアップにexpdpを使用している。expdpを実行したところ「ORA-31634: ジョブはすでに存在します」と「ORA-31664: デフォルト設定時に一意のジョブ名を構成できません」と見慣れないエラーが表示される。
以下のSQLでDATAPUMP_JOBSにあるジョブ名を確認する。
> select * from DBA_DATAPUMP_JOBS ORDER BY JOB_NAME
>
> OWNER_NAME JOB_NAME OPERATION JOB_MODE STATE DEGREE ATTACHED_SESSIONS DATAPUMP_SESSIONS
> SYSTEM SYS_EXPORT_SCHEMA_01 EXPORT SCHEMA NOT RUNNING 0 0 0
> SYSTEM SYS_EXPORT_SCHEMA_02 EXPORT SCHEMA NOT RUNNING 0 0 0
>...
なんと・・・SYS_EXPORT_SCHEMA_01~99まで、全部で99個のジョブが溜まっている。実はexp先の容量不足から一部スキーマのバックアップに失敗していた時期があって、どうやらその時に失敗したexpdpのジョブが消えること無く溜まっていたらしい。
こういう時にはexpdpにattachオプションを指定して起動し、コマンプロンプトからkill_jobを実行すれば良い。でも残念ながら下記のようなエラーになってしまい、既存ジョブにアタッチする事が出来ない。
C:\>expdp SYSTEM/****@ORA attach=SYS_EXPORT_SCHEMA_01
Export: Release 11.2.0.1.0 - Production on 金 6月 21 09:43:34 2019
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
接続先: Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
ORA-39002: 操作が無効です
ORA-39000: ダンプ・ファイル指定が無効です
ORA-31640: ダンプ・ファイル"C:\dmp\XXX.dmp"を読取りのためにオープンできません
ORA-27041: ファイルをオープンできません。
OSD-04002: ファイルをオープンできません
O/S-Error: (OS 2) 指定されたファイルが見つかりません。
既存ジョブにアタッチできないので、仕方なく以下のSQLでジョブを廃棄することにする。
> DROP TABLE SYS_EXPORT_SCHEMA_01;
> ...
> DROP TABLE SYS_EXPORT_SCHEMA_99;
これで溜まっていたジョブが削除されたので、expdpは正常に戻った。
日付をまたいで「『VBAを覚えようと思うんだけど』と聞かれた話 」の続きなど。
VBAを進められない理由・・・それは2025年以降、Microsoft Officeが月額制ライセンスのみとなることで、どのパソコンにもExcelが入っている時代が終わりそうだからだ。現在のMicrosoft Officeのライセンスは大きく分けて2種類、月額制ライセンスと買切りライセンスにわけられる。このうち買切りライセンスはOffice 2019を最後のバージョンとして2025年10月にサポートが終了する。
Microsoft Officeの買切りライセンスにはユーザーライセンスとデバイスライセンスの2種類に分かれる。ユーザーライセンスは使うユーザが同じなら複数台にインストールできるが、1台のPCを複数人で共有するなら人数分のライセンスが必要だ。デバイスライセンスはインストールするPCの台数分購入する必要があるが、1台のPCを複数人で共有してもOKだ。
対して月額制ライセンスはユーザーライセンスしか用意されていない。 PCの台数より従業員の人数の方が多いという職場は少なくない。小売業とか、製造業とか。1台のPCを10人程度で共有していた場合、デバイスライセンスだったら5万円で済んだのが、月額制ライセンスだと5年で50万円くらいに膨れ上がる。この金額増を避けるためMicrosoft Officeを全部のPCにはインストールしなくなると考えている。
一般家庭向けだと法人ライセンスより高くて年間1万2千円。4人家族なら年間4万8千円。現在はプレインストールモデルのOffice Personalを1万7千円の価格差で買えるから大抵の人はインストールしている。ライセンス料が5年で24万円と言われたら、利用頻度の低いだろう一般家庭は躊躇するのではなからろうか。海外だともうちょっと安いファミリー向けライセンスもあるらしいのだが、そうだとしても結構厳しい。
僕は 上記の理由から2025年になるとMicrosoft Officeの利用が減り、比較的安いコストで使える互換製品に移る動きが再び起こると思っている。互換OfficeソフトはMicrosoft Officeのファイルをほぼ問題なく扱うことが出来る。だがVBAだけは互換ソフトで動作しない。今むやみにVBAでプログラムを作りすぎると、5年後に追い詰められる予感がするのだ。
事務系の同僚女子に「VBAを覚えようと思うんだけど」と言われて唸ったことがある。
ITリテラシーの高い従業員が増えることや、業務が効率化されること自体は喜ばしいのだが、ことVBAだけは手放しで勧められないのだ。
VBAはVisual Basicという言語が元になっている。このVisual Basicは1998年発売の6.0を最後に、2008年4月にサポートを終了している。Office製品の一部として提供されているためセキュリティアップデートこそ提供されているが、機能面では更新されていない。20年前で進化が止まっている。
そのためVBAでは、新しいバージョンのDB利用や、WEBサービスとの連携に無理が出ているのだ。MicrosoftのSQLServerで扱うデータ型の一部は取り扱えないし、WEB APIを呼び出そうとすると恐ろしく冗長なコードを書かざる得ない。
さらにVBAはインターネットが普及してセキュリティが重要視される以前の設計なので、セキュリティ面がどうしても弱い。標準では電子署名なしのマクロを実行できないように設定されているのは、セキュリティ的に弱く攻撃の対象にされやすいためだ。
セキュリティ面ではVBAを電子署名必須として運用するか、それが出来ないなら社内から無くしたいのが実情だ。でも実態は彼方此方で活用しているので、止めるに止められないので、セキュリティ担当者は困っていたりする。
ではどうしたら良いかというと、実は代案がない。ExcelやWordのファイルを扱うことができて、ライセンス料がかからず、平易に学習できて、完璧に日本語化されていて、どのWindowsパソコンでもそのまま動かせる言語・・・というのが見当たらない。
というわけで、VBAに関する愚痴でした。ちなみに私自身は、VBAを使って、新規にはマクロを作らないことにしています。 新たに作るときにはC#+Closed XMLで書きます。もしくはPower Query+Excelの数式だけで作ります。
Microsoftにも早く今後のLoadmapを考えてほしい。
ようやく重い腰を上げて、サーバーのバージョンを更新しました。
これに伴ってクラウドベンダーをScaleway からVultr に切り替えました。 VultrもScalewayと同じく、月額250円前後~で格安VPSを提供しています。
Vultrの最大のメリットは日本にDCを持っている事。 Scalewayのほうが若干ですがサーバー性能・・・特にSSDの性能は高いのですが、待てど暮らせどEU以外にDCが作られる様子がないのですよね。Cloudflareと併用することでネットワークの距離に起因する応答速度の問題はクリアできていましたが、SSHなど保守作業においてレスポンスが遅いのは如何ともしがたく、 Vultrに写ることにしました。
今回はサーバーを再構築するにあたり、漸くDocker Composeベースで環境を構築することにしました。Docker Compose良いですね。現状で動かしているのはWordpressとGitbucketだけなんですが、公式イメージがDockerHubに上がっているような環境については、殆ど何もすることがなく環境を構築できるのは便利ですね。
加えてMongoDBや.NET Core環境も動作させたいのですが、流石にメモリ1GBのプランでは厳しいかな。
不要になったホームページを閉鎖する手順を記した良記事。 「ドメイントラブルを防ぐ、Webサイトを正しく閉鎖する方法 」
一時期にはキャンペーンサイトなど安易に期間限定でドメインを取得してしまうWEBサイトが多数あったが、最近は問題点が知れ渡ったのか大分減ってきた。取得してしまったドメインを方々に迷惑を掛けることなく、キチンと止めるのはとても面倒なのである。
まとめるとこんな感じ。 1.閉鎖したドメインで一定期間は閉鎖の案内を表示するか、あるいは新URLへの転送を行う。 2.HTTPリファラーをモニタリングして、可能な限りリンク元URLに対して変更依頼を行う。 3.閉鎖するドメインへのアクセスがほぼ無くなったのを確認した後にWEBサーバーを廃止。 4.WEBサーバ廃止後はDNSからレコードを削除。 5.WEBサイトを閉鎖した後もドメインは更新し続け手放さないのが理想。
最近はちょっとしたプログラムを作るときに.NET Coreコンソールアプリケーションを選択するようにしている。今のところ実際にLinuxで動かすような機会はないが、クロスプラットフォームに出来るからだ。ただ通常はDLLとしてビルドされるため、PCに詳しくない人には起動手順を説明しにくい。
第三者向けにインストーラを作成して使用手順を書こうとした時に、ふと.NET Core 2.2からはDLLではなくて、実行ファイル(EXEファイル)としてビルド出来ることを思い出した。第三者向けに配布するなら実行ファイルとしてビルドしておいた方が便利そうだ。
コマンドラインから実行ファイルを生成するのは以下のように”-r win-x64 –self-contained true”指定するだけである。
dotnet publish -c release -r win-x64 --self-contained true
win-x64はRID(Runtime Identifier)でビルドするターゲットとなるプラットフォームを示します。linux-x64とかwin-arm64などと指定すれば異なるOSやCPUアーキテクチャをターゲットとしたバイナリを簡単に作れて便利です。
URL:https://docs.microsoft.com/ja-jp/dotnet/core/deploying/deploy-with-cli https://docs.microsoft.com/ja-jp/dotnet/core/rid-catalog
子供に悪戯されることもあって、久しぶりにコンタクトレンズに戻しました。所が一つ問題が・・・「あれ?スマホの文字が読めない・・・」まだ若いつもりでしたが完全に老眼です。メガネは普段外してて、必要時に掛けてたので気がつきませんでした。
そこで以前から興味を持っていた遠近両用コンタクトレンズを使ってみることにしました。人間の瞳孔は明るいところで小さく絞られ、暗いところで大きく開きます。実は明るさ以外にも、近くをみるときには小さく絞られ、遠くを見るときには大きく開きます。これを利用してコンタクトレンズの中心部分を老眼用に低い度数に、外側部分を高い度数にしたのが、遠近両用コンタクトレンズです。
もともと視野の中心部分は、レンズを真っ直ぐに抜けていく光が焦点を結ぶ部分だから、レンズの中央部分に度が入って居なくてもキチンと焦点を結べるわけです。ただし視野の外苑部分は中央の度が入って居ない部分と、外側の度が入って居る部分の光が焦点を結べないのでぼけた感じになります。
また極端に明るい場所だと瞳孔が開かないため、レンズの外側の度が入った部分で見ることが出来ず、遠くが見えません。 逆に暗い場所だと瞳孔が開いてしまうために、レンズの外側の度がはいった部分を使ってしまい、近くが見えません。
遠近両用コンタクトレンズの欠点は、 視野の外縁部がぼけてしまうことと、明るすぎると遠くが見えず、暗すぎると近くが見えないことです。球技などのスポーツを行う場合や、工事現場や工場など絶えず周囲に気をつけなければならない人、屋外の明るい場所や暗い場所で作業するひとには向きません。
私は事務仕事なので、夜間の運転さえ避ければ問題無さそうです。
実際に使ってみた感想なのですが、外縁部のぼけなど全く問題を感じないレベルでした。もともと細かな文字を見るときや運転以外は裸眼で過ごす時が多かったかもしれませんが、市や中心以外のボケも意識しないと気がつかないレベルです。
問題になるのではないかと思っていた夜間の運転ですが、元々度数がそれほど高くない(-2.5程度)からか、裸眼よりもよく見えてます。運転にも支障が無いレベルでした。
老眼の程度がさらに進行するとまた違うのだろうけど、当面は愛用することになりそう。