FreeNASをVMware上で実験してみた

普段、自宅ファイルサーバとして利用しているFreeNASですが、正常系は問題なく動作しているものの、トラブルが起きた場合の処置についてはこれまで調べてきませんでした。
そこで、今回ちょっと調べてみたいと思います。

まず、VMware上にFreeNAS9.1の32bit版をインストールしました。ホストシステムが32bit+PAEカーネルのLinuxMint13なので、FreeNASも32bit版を選択しました。
起動用のHDDは10GB、データ用のHDDはSCSIで10GB×2(それぞれのディスクに1A,1Bという名前を付けました)としました。

インストール自体は特に問題ありません。ホスト名などは適当にvmFreeNASとしました。

インストール後、パスワードを設定し、10GBのディスク2本で暗号化ありのZFSボリュームをミラーで作成しました。

これをCIFSで共有するわけですが、いつものことながら、今ひとつよくわかりません。設定してからLinux側から見えるようになるまで時間がかかるためでしょうか。
まあ、今回の目的は暗号化関連なのでよしとします。

適当なファイルをvmFreeNAS側に置いた状態で、今度は暗号化ZFSボリュームにパスフレーズをつけてみます。これまでは暗号化していてもパスフレーズもなしで運用してきました。

実験1:ディスクのみ持ち出した場合にどうなるのか?

仮想FreeNASサーバを2台動かして、1台目のディスク2台(ミラーなので)をコピーして、そのうちのディスク1台をFreeNASサーバ2台目に付けてみます。

普通にボリュームを作成しようとすると、中身のあるディスクとしては認識されず、初期化しようとします。つまり、ディスクを持ち出しても読み出せそうにありません。

001

しかし、「ボリュームの自動インポート」を行うと、暗号化ボリュームをインポートするか聞いてきます。

002

ここでYesを選んでOKを押すと、

003

暗号化キーを確認してきます。ここで、元のFreeNASサーバからエクスポートした暗号化キーのファイルを指定してやると・・・ボリュームも指定しろ、とエラーがでました。(下記)

004

とにかく、両方指定してやると、

005

元のボリューム名を確認してきます。そこでOKを押すと、

006

無事にインポートされました。シェルで中のファイルを見ると、確かに存在していそうです。ミラーしたディスクの片方しかマウントしていないので、DEGRADEになっていますが、とにかくファイルの救出はできそうな感じです。

なお、ミラーを構成する2つのディスクを接続してからボリュームの自動インポートを行い、ディスクを指定する際に2つとも指定してやるとミラーであることを認識してミラーディスクとしてインポートされました。
一度でも片方だけでインポートすると、一旦ボリュームをデタッチしてもミラーとしてはインポートされなくなるようです。(当然といえば当然な気がしますが・・)

実験1をまとめると、暗号化キーとミラーディスクの片方があればデータは復旧可能。

実験2:パスフレーズをつけたディスクは起動時にどうなるのか?

もう一つ気になっていたことがあります。暗号化キーにパスフレーズをつけた場合に、起動時に入力が必要なのかどうかです。これまでは起動時に入力するのは面倒なので、パスフレーズをつけずに運用していました。
一方で、考えようによってはパスフレーズを入力しなければ決して中身の見えないサーバとして運用することもできるかもしれないわけです。

というわけで、実験してみました。

先に2台のディスクのコピーを持ち込んだらHEALTHYに復帰した2台目の方で、パスフレーズをつけて再起動してみました。

007

起動後、ボリュームはロックされた状態になりました。

008

ロックされたボリュームを選択して、下の方のUnlockをクリックします。

009

パスフレーズを入力して「OK」をクリックします。

010

無事にアクセスできるようになりました。(正確にはCIFSでアクセスできるかは確認していません。例によって、見えたり見えなかったりが不安定なので。シェルでディレクトリやファイルの存在を確認しただけです。)

実験2のまとめ:パスフレーズを設定すると、起動後にパスフレーズを入力するまではアクセスできない。

FreeNASのディスクをフォーマットしなおす

出張中にrsyncによるバックアップが終わっていたので、元のミラーディスクを消去します。
(ちなみにバックアップはLinux上でも別にrsyncで取ってありますので、二重化はされたままです)

ストレージを表示し、先にバックアップをとったボリュームのところの赤×がついたアイコンをクリックしてボリュームを削除します。この時、Windows共有(CIFS)の設定をクリアするか聞いてきますが、クリアしないで残しておきます。(CIFSの共有自体はrsyncでバックアップを取る前に停止してあります)

改めてボリュームマネージャで同じボリューム名で2本のHDDをミラーリングにてZFSボリュームを作成します。この時の設定として暗号化を追加します。

ボリューム作成が終わったらバックアップからの復元のためにrsyncで逆方向のコピーを行ってデータを復元しますが、また長い長い時間がかかります。放置しておくしかありませんので、今日はここまでです。

あとはCIFSのサービスを再開させればいいのだと思いますが、どうでしょうかね。

<追伸>
CIFSサービスを再開させるだけで無事にファイルサーバとして復帰してくれました。

FreeNASにディスクを追加する

Microserverで快調に動いているFreeNASにディスクを追加してみました。

目的は万が一空き巣にでも入られてHDDを持ち去られた場合に備えて、FreeNAS8.3.1で追加された暗号化を適用したいということです。全領域を暗号化するには一旦中身をバックアップしないといけないので、まずは外付けディスク以外に内蔵ディスクでもバックアップをとることにしました。

4本ある3.5インチベイのうち、すでに2TB×2でRAID1によるミラーリングで2本、初めからついてきた250GBの作業領域で1本使っていますので、残りの1本に新たに買ってきた2TBのHDDを取り付けて電源ONしました。

暗号化ボリュームの取扱いになれるのを兼ねて、バックアップ領域も暗号化を適用してみます。

1.ボリュームの作成

ボリュームマネージャでバックアップ領域としてボリュームを作成します。

Screenshot-3

ボリューム名に「BACKUP」、メンバディスクは今回追加した ada3(2.0TB) を選択、ファイルシステムはZFSを選択、ZFS選択後に出てくる「Enable full disk encryption」を選択して「ボリュームを追加」を押します。

Screenshot-4

この時点でシェルから今回のディスクにアクセスが可能になります。

/mnt # rsync -av /mnt/DATA/ /mnt/BACKUP/

として、データを丸ごとコピーします。

2.パスフレーズの設定等

※暗号化鍵やパスフレーズ、リカバリキーは厳重に保管する必要があります。

1)パスフレーズの設定

ストレージのレポートから追加したボリュームの右の方の鍵のマーク(鍵だけのマークで下記の画面コピーでは右から5番目のもの)をクリックして、パスフレーズを設定します。

Screenshot-6

2)リカバリ鍵の設定

Screenshot-7

上記アイコンのうち、「+」と「-」のついた右の二つをつかってリカバリ鍵の追加と削除ができます。追加したリカバリ鍵はパスフレーズを忘れてしまった際にパスフレーズの代わりに使うことができます。

3)暗号化鍵のダウンロード

Screenshot-7

上記アイコンのうち、左から2番目の「↓」がついたボタンを使うと、暗号化鍵のコピーをダウンロードできます。

4)暗号化鍵の変更

Screenshot-7

上記アイコンのうち、真ん中のものを使うと、暗号化鍵を再生成することができます。再生成には現状のパスフレーズが必要です。暗号化鍵が漏洩したと思われる場合に暗号化鍵を変更するために使用します。

3.あまりに遅い??

・・・ここまで終わったところで、rsyncの状況を確認したところ、30分で40GB程度の進捗。計算すると、20MB/s程度しか出ていません。これだと1.4TB=1400GBコピーし終わるのは18時間後になってしまいます。AESによる暗号化処理をハードウェアでサポートするAESーNIがCPUで持っていないと非常に遅くなる、とは書いてありましたが、20MB/sではあまりに遅すぎます。
一旦 rsync を中止しして、あらためて暗号化無しでボリュームを作成して転送してみると、20分で46GB程度の進捗ですので、暗号化を行うと半分強くらいまでスループットが落ちてしまうようです。

これだとrsyncが遅いだけかもしれませんので、簡単に速度の比較をしてみることにしました。

まず、FreeNAS上にWindows共有を2つ用意しました。片方は暗号化無しの250GBのHDD上のボリューム、もう片方は暗号化ありの2TBのHDD上のボリュームです。

ここにトータル600MB、3000個のファイル(大きなPDFからデジカメの写真など適当なファイルです)を書き込んでみました。先に暗号化無しの方に書き込むと141秒かかりましたので、4.25MB/sということになります。次に暗号化有りの方に書き込むと120秒で終わってしまいましたので、5.0MB/sということにないました。

次に各種Linuxディストリビューションファイルを3.85GB書き込んでみます。今度は先に暗号化有りの方から書き込んでみたところ108秒かかりましたので35.6MB/sということになります。次に暗号化無しの方に書き込んで見たところ73秒で終わりましたので52.7MB/sということになります。

この結果からすると、大きなファイル中心の書き込みは影響を受けてしまいそうですが、細かいファイル中心の場合にはディスクの性能の方が効いてきそうな感じです。

今日のところはここまでにして、とりあえず rsync でバックアップが取り終わるのを放置して待つことにします。

FreeNASを8.3.0から8.3.1-RELEASE-p2にアップデート

なんとなく、FreeNASを以前アップグレードした8.3.0から最新の8.3.1-RELEASE-p2にアップグレードしてみました。
・・・といっても、前回のような面倒な手順は必要ありません。

  1. まず、お約束のバックアップは当然取ります。
  2. www.freenas.orgにアクセスして、ダウンロードページで「GUI Upgrade 64-bit」をクリックします。
  3. 29c6・・・で始まるSHA256のHashが表示され、その下にダウンロードボタンが表示されるので、ダウンロードをポチッとクリックして、しばらく待ちます。ポチッとした直後にはFreeNASとは無関係な「Download」とかかれた広告バナーが待ち構えていますので、何も押さずに待ちます。(何とかならないんですかね?この地雷バナー・・・。多分マルウェア満載なんじゃないかと思うのですが・・・)
    ※8.0.xからのアップグレードのためのリンクは少し下にあります。今回は8.3.0からのアップグレードです。
  4. しばらく待つと「FREENAS-8.3.1-RELEASE-p2-x64.GUI_Upgrade.txz」という拡張子がtxzのファイルをどこに保存するか聞いてくるので、適当なローカルの場所を指定して保存します。
  5. FreeNASにWebGUIでログインして、「システム」→「設定」→「高度な設定」と進んでいくと、下の方に「ファームウェア更新」のボタンがあるので、ポチッと押します。
  6. ファームウェアファイルを一時保存する場所を聞かれるので、適当に場所を選択して、「更新を適用」をポチッと押します。
  7. 「New image to be installed」でファイルを選択するよう指示されますので、4で保管したtxzの拡張子のファイルを指定し、その下の「イメージのSHA256ハッシュ」には3の29c6・・・d84bのHASHの値をコピペして、「更新を適用」をクリックします。
  8. しばらく(数分くらい?)待つと、「System – Rebooting」に表示が変わります。
    コンソールにはブートの画面が表示されるようです。裏では2回リブートがかかるようです。
    かなり時間がかかるので、コンソールの画面でアップグレードの過程を確認する方がいいと思います。(コンソールでみていても、途中で長く止まることがあるので、気長に待つ必要があります。)
  9. 10分くらい放置後、ブラウザをリロードすると、再度WebGUIでのログインを促されますので、ログインすると、System Informationが表示され、バージョンアップしていることが確認できます。

FreeNASのデータバックアップ

普段、自宅のデータはFreeNAS上に置いてあります。FreeNASのデータ領域は2TBのHDD(しかも敢えて異なるメーカーのものを選定)を2本によるミラーリングにしてあるので、まず心配はいらないと思います。それでも念のためと誤操作による消失対策として外付けのHDDにも月に1回くらいバックアップをとっています。
これまでは古い2TBのHDDを外付けHDDケースに入れて、Windows7マシンでNTFSフォーマットし、盗難等の対策としてTruecryptによる暗号化ボリュームを設定していました。しかし、このHDDが何やら挙動が怪しくなってきたので、新規にWesternDigitalの外付け2TBを購入してバックアップ用にすることにしました。

早速、Windows7マシンに接続して、TrueCryptで暗号化ボリュームを作成・・・・していたのですが、なんせ2TBなので、20時間くらいかかりそう・・・・ということで電源を入れたまま放置していました。ところが、あと数時間というところで、Windowsが不意にリブートしたようです。で、調べてみると、WindowsUpdateによる自動再起動とのこと。

もう一回暗号化ボリュームを最初から作る気力はないので、他の方法を探ることに。
今回は、『Windowsのバカヤロー』から始まったことなので、Linuxで解決すべく考えてみることにしました。

“FreeNASのデータバックアップ” の続きを読む

FreeNASアップデート2回目

何も文句を言うことなく黙々と働きつづけるFreeNAS。前回バージョンアップした後のバージョンは8.0.4で、これで黙々と働いてくれていました。・・・が、久しぶりにFreeNASのWebサイトを訪問してみたら、 8.3.0がリリースされていましたので、アップデートしてみます。

・・・が、前回同様、バージョンアップに先立って、いつものようにBunBackupを使って、Windows7マシンにつけてある外付けHDDに中身をバックアップします。やはり誤操作ですべてを失うリスクがありますので、バックアップは重要です。。

で、アップグレード手順は、やはりここに書いてあります。8.0.1-BETA3より前のバージョンからアップグレードする場合にはGUIを使わずにisoファイルを使ってアップグレードを、8.2.0-BETA3以降のバージョンからのアップグレードでは.txzファイルを、8.2.0-BETA3より前のバージョンからのアップグレードでは.xzファイルを使用するようです。今回は8.0.4からのアップグレードなので、.xzファイルを使ってアップグレードすることになります。

“FreeNASアップデート2回目” の続きを読む

rsyncでディレクトリの同期

GWの終わりには竜巻で大きな被害が出るなど、最近は天気が荒れがちでよく雷がなったりしています。また、東日本大震災の影響の電力不足が続いていて、この夏はいつ停電になってもおかしくない気がします。停電すると常時稼働している機器が影響を受けます(当たり前ですが)。

停電対策といえばまずはUPSですが、導入するお金も置く場所もありません。そうなると、電源OFFするしかないのですが、嫁さんが先に帰ってきてPCで遊ぶ際に写真が見れないとかという話になってしまいます。それも困るので、MicroServer+FreeNASの導入で遊休状態になっている玄箱PRO上のSamba上に最低限のファイルをコピーして稼働させることを考えました。
が、コピーを手作業でやっていると面倒なので、rsyncで自動化できないか調べてみました。

実施にあたってはこちらのサイトDebianの公式サイトの記述を参考にさせていただきました。

1.考え方

玄箱PRO側でrsyncdをdaemonモードで起動して待機させます。sshモードの方が試してみる分には簡単なようですがパスワード入力が要る(自動化するには鍵ペアで認証になる?)のと速度が遅いので、daemonモードで実施します。daemonモードは暗号化がかかりませんが、自宅内ネットワークなのでよしとします。
そこに、FreeNAS側からrsyncで書込みをさせます。

2.玄箱側の設定

rsyncのインストールは初めからしてあったのか、したのか忘れました(^^;。
ただ、設定ファイルである /etc/rsyncd.conf は存在していなかったので作成します。

コピー(同期)はFreeNAS側の common というディレクトリを /home/common に同期させます。また、玄箱は非力なので、コネクションをたくさん張られてもかえって遅くなるだけなので接続数を制限します。
設定ファイルを作成したら、

で daemonモードで起動します。

3.FreeNAS側の設定

FreeNAS側は「システム」→「Rsync Tasks」→「Add Rsync Task」でタスクを作成します。

  • 「パス」にはローカル側のディレクトリを指定します。Browseでは共有単位でしか選択できないようなのですが、今回はFreeNAS側の common の下をすべて同期するわけではないので、対象ディレクトリをフルパスで指定します。
  • 「リモートホスト」には玄箱PROのIPアドレスを指定します。
  • 「Rsync mode」には「Rsync module」を指定します。
  • 「Remote Module Name」には /etc/rsyncd.conf のモジュールオプションの[]の中身、すなわち「common」を指定します。
  • 「Remote Path」には「パス」で指定した部分のうち、common以下の部分だけ指定します。
  • 「Direction」はFreeNASから玄箱PROなので、「Push」を選択します。
  • 「Minute」以下はどの周期で同期を試みるか設定します。
  • 「ユーザ」は「root」を選択します。
  • あとはデフォルトのままにしたような・・

これで「OK」を押すと設定した時間で同期動作が始まりました。

4.自動起動の設定

rsyncをinetdから起動させるための設定をします。
まず/etc/servicesファイルに 次のような rsync サービスがあることを確認します。

デーモンを inetd から起動させるために、次の行を /etc/inetd.conf に書き足します。

修正後に inetd に HUP シグナルを送り、 修正された設定ファイルを読み込ませます。

5.他に参考になりそうなもの

rsync + cron + sshのみで実現する方法(rsyncd を使わない方法)

FreeNASアップデート

嫁さんが「(FreeNASに保存してある)写真にアクセスできない」というので、そんな馬鹿な・・・・と思いながら、管理コンソールにアクセスしてみたら、確かに応答がありません。直接コンソールをみても反応なしです。仕方がないので、強制電源OFF/ONしたら復帰しました。

で、調べてみると、いまインストールしてあるFreeNASは8.0.2なのですが、最新は8.0.4のようですので、アップデートしてみることにしました。

・・・が、その前に、別のHDDに中身をバックアップします。

いつものようにBunBackupを使って、Windows7マシンにつけてある外付けHDDに中身をバックアップします。やはり誤操作ですべてを失うリスクがありますからね。

8.0以降からのアップグレードの手順はこちらにあるようです。基本的な手順は、

  1. 設定ファイルの保存
  2. CDからフルインストール
  3. 設定ファイルの復元

のようですが、WebGUIからもアップデートできるようです。ただ、この場合は設定ファイル保存後に、一旦サービスを停止して、アップデート、再起動・・・という手順を踏むようです。(結構めんどくさい感じ)

で、CD-ROMからアップデートしようかと思ったのですが、結局WebGUIからアップデートをかけてみることにしました。

思ったほど手順は難しくありません。

  1. アップデート用のファイルのダウンロード
    こちらからアップデートに必要なファイルをダウンロードします。 WebGUIでのアップデートに必要なファイルは拡張子がxzになっているものです。あわせて、sha256のチェックサムファイルもダウンロードしておきます。
  2. ファイルの正当性チェック
    「$ sha256sum FreeNAS-8.0.4-RELEASE-x64.GUI_Upgrade.xz」
    として、チェックサムが一致するか確認します。(GUIの中でもチェックされるようです)
  3.  設定ファイルのバックアップ
    一応、設定ファイルをバックアップします。万が一WebGUIでアップデートするのに失敗した際に必要になるのでしょう。(自分は必要ありませんでした)
    Webの管理コンソール画面で、「システム」→「設定」→「一般的な設定」の中に、「設定のダウンロード」というボタンがあるので、これを押すと設定ファイルを保存できます。
  4.  サービスの停止
    「サービス」→「サービスの制御」でONになっているサービスをすべてOFFに変更します。
  5.  コンソール表示の設定
    「システム」→「設定」→「高度な設定」 で「フッタへのコンソールメッセージの表示(UIのリロードが必要)」にチェックを入れて、「Save」を押します。その後、ブラウザでリロードボタンを押すと、下の方にコンソールメッセージが表示されるようになります。
  6. ファームウェアのアップデート(一時保存場所の設定)
    同じ画面(「システム」→「設定」→「高度な設定」)で、「ファームウェアアップデート」を押すと、アップデートファイルを一時保存する場所を聞いてくるので、適当に設定します。(自分はデフォルトのままにしました)
  7. アップデートするファイルの指定
    アップデートするファイルがどこにあるか聞いてくるので、1でダウンロードしたファイルを指定します。併せて、sha256のチェックサムの結果もコピー&ペーストで入力します。
  8. あとはひたすら待つ
    途中、勝手に2回リブートがかかります。再起動の途中でブートメニューが一瞬表示されますが、触る必要はないようです。(自分は触りませんでした)
    コンソール画面を見ていると、2回リブート後に通常の「Console setup」の画面になり、アップデートが終了します。
  9. 停止したサービスを再開
    4で停止したサービスを再開します。

で、意外に簡単に終わりました。

 

LinuxからFreeNASに接続する

Windowsからは昨日の設定でほぼ何も考えずに接続できるようになりました。

Linuxから接続する場合のことを書いておきます。

今回はLinuxMint11から接続してみます。

Nautilusのメニューから、「移動」→「ネットワーク」を選択します。

すると、「Windowsネットワーク」のアイコンが出てくるので、ダブルクリックします。

すると、ワークグループごとにアイコンが出てくるので、設定したワークグループの方を選択します。
(下記でモザイクがかかっている方です)

コンピュータ名がでてくるので、FreeNASに対応するアイコンをダブルクリックします。

共有名がでてくるので、該当するものをクリックします。

パスワード入力画面になりますので、ユーザー名、ワークグループ名とパスワードを入力します。

無事に接続できました。

書き込みができない場合は、FreeNAS側でログインしたユーザーのパーミッションがあるかどうか確認する必要があります。

<追伸>

デフォルトでワークグループが「WORKGROUP」になるのはクライアント側(LinuxMint側)の設定のようで、/etc/samba/smb.conf の中の 「workgroup=WORKGROUP」を書き換えてやればいいようです。書き換えてやると、「移動」→「ネットワーク」にでてくるネットワーク一覧の中にコンピュータ名も出てくるようになりました。

FreeNASの設定

昨日に引き続き、FreeNASの設定をやってみます。

1.一般的設定

「システム」の「設定」で一般的な項目を設定します。

  • 言語を「Japanese」に変更
  • タイムゾーンを「Asia/Tokyo」に変更

2.グループ、ユーザの追加

「アカウント」の項目でグループとユーザを追加します。管理ユーザーグループと普通のユーザーグループ、管理ユーザー(自分)と普通のユーザー(嫁さん)をそれぞれ追加しました。元々の目的は、嫁さんが適当にファイルを弄ってしまうので、誤って消してしまうのを防ぎたい、ということにあります。ですので、それぞれアクセス権を設定するためにグループもわけておきます。

3.ストレージ関係

「ストレージ」の「ボリュームの作成」でボリュームを作ります。

今回は、250GBのディスクはリモートの作業領域にするということで、単独でZFSファイルシステムにしてみます。ボリューム名は「WORK」としました。2TBのディスク2台はまとめてZFSファイルシステムにしますが、mirrorの設定をして、ボリューム名は「DATA」にしました。これでミラーリングがされている、と思います。さらにこの後、CIFSで共有をしたときに、Windowsからのユーザーアクセスができるように、所有権とアクセス権を変更しておきます。

所有権は自分、アクセス権はDATAは基本的に自分しか書き込まないので、その他のライトパーミッションは落としておきます。

4.CIFSの設定変更

Windowsでの共有に向けて「サービス」の「CIFS」で設定を変更しておきます。

  • NetBIOS名
  • ワークグループ
  • DOS文字セット・・・「CP932」に変更
  • Large RWのサポートにチェック

くらいでしょうか。もちろん、Windows側と合わせておかなければならないはず。

5.サブディレクトリの構築

シェルでDATAの下にサブディレクトリを作ってパーミッションを設定します。WebUIから作る方法は見つかりませんでした。

6.共有の作成

「サービス」→「CIFS」→「共有の作成」でWindowsの共有を作成します。

名前、パスを入力したら、「Inherit Owner」「パーミッションの継承」「ゴミ箱の有効化」などをチェックして、OKを押します。

7.サービスの起動

「サービス」→「サービスの制御」でCIFSをONに変更すると、しばらくしてWindowsから見えるようになるはず・・・。