ストレージ規模がどんどん大きくなる当システム。次期再編成のためのメモである。話を一般化するために特殊な箇所は変更してあり、このまま適用できるわけではない。B)から60TBに及ぶ巨大なストレージを取り扱えるようにする。Slave)を用いてデータの冗長化を行う。基本的には無停止が可能なようにするが、HAのような完全無停止を要求するわけではない。RN316が良いようだ。EDA500を追加することで10万円以内で筐体を用意することができる。ディスクとあわせると、20台60TBで約40万円が必要だ(2017年6月現在)。バックアップは実際には現在はサーバーによる内蔵とAoEの組み合わせ、とするが、将来的には同様の方法をとるのが望ましいだろう。構成NetGearで用意したディスクを、NetGearの機能でRAID5化し(つまり有効ディスク数は18となる)、これをiSCSIで提供する。Anyがイニシエータとなり、これをLUKSデバイスとして暗号化/復号化し、その上にbtrfsを構築して利用する。-d1オプションを使って無停止性を確保することができる。-dsingle構成にしたほうが良いと考えられる。-d1とした場合、ディスク30台を使用して使える容量は9台分となる。バックアップも基本的には同様に構築する。異なるグループのiSCSIを用意し、btrfsボリュームを作成する。接続iSCSIによる通信でほぼネットワークはあふれることになるため、ネットワークは分離することにする。上流側は主にはクライアントユースになる、と考えれば、上流側をUSBアダプタとすることでホストの切り替えを容易にすることが考えられる。このとき、両者が所属するネットワーク(サブネット1)はホストネットワークであり、下流側はストレージのみを接続する、という形態にすることでiSCSIの通信を混在することを避けられる。Aに接続されていたサブネット2のケーブルを接続すれば良い。NASの用意NASのディスクを各NAS上でRAID5で構成する。2台ひと組にしておけば、btrfsは-d1であってもディスクを使い切ってくれる。-dsingleにする場合は、NAS内のディスクは容量を揃える必要があるが、NASの合計容量を揃える必要はなくなる。全ディスクを連結してRAID5を作ってしまうと、ディスク容量の制約が厳しくなるので、この方法のほうが良いだろう。性能面でも、暗号化とRAIDの組み合わせはかなり重いので、速度を考えればハードウェアRAIDのほうが望ましい。RAID5を構成したディスク上にLUNを作る。NASはサブネット3に置かれるため、実際に混在することはない。ホストのセットアップiSCSIイニシエータとして利用するため、iSCSIイニシエータutilのインストールと、iscsiサービスの起動が必要になる。利用方法については、archwiki参照のこと。全てのiSCSIターゲットにログインした上、これをluksFormatする。ディスクは増えていくことになるので、キーファイルを使ったほうがスクリプトにする際に良いだろう。/dev/mapper/Crypt[12]追加で、サブボリュームの作成や、fstabの編集などを行っておく。iSCSIターゲットの探索とログイン、ディスクの復号化とマウントの一連の流れはスクリプトにしておいたほうが良いだろう。利用まずNASを起動し、次にホストを起動する。スクリプトによってマウントする。セットアップが終われば非常にシンプルである(ただし、スクリプトにしていないと打つコマンドの量は多い。それはそれでセキュアだが)スクリプトをsystemdユニットにしておくのは良い考えだが、コケる可能性の高いユニットなので、enableにはしないほうが良いだろう。Linuxでの手順である。btrfsのマウントポイントは/mnt/masterであるとする。実際には特定ユーザーのデータが配置されるのであり、~foo/.masterfsがマウントポイントである。~foo/.masterfsこれにより、ふたつのマウントポイントを意識せずに共有することができるようになる。ここではNFSのマウントポイントも別に用意する。/srv/nfs4/masterfsここまではスクリプトに含めると良いだろう。NFSパッケージのインストール。マウントを手動で行っているため、enableは非推奨。nfs-server他ホスト(サブネット1のホスト)からマウントするためには、次のようにする。nfs4とする必要がある場合、サーバー側パスにエクスポートルートを含める必要がある場合があるという。CIFSArch系ディストリビューションにおけるSambaのセットアップ手順はArchwikiが参考になるだろう。Linuxを中心に使っているユーザーにとっては、常時マウントするわけではないから、ファイルマネージャでのusershareシェアで十分かもしれない。AndroidユーザーにとってはCIFSで構築したほうがメディアファイルの再生も容易になる。DLNAメディアファイルを広く再生する方法として有効なDLNA。DLNA対応のプレイヤーがあり、それによって大画面で見られるといった場合には役立つだろう。Masterにログインすることが前提であるならばRygelで良いと思う。ない場合は、ReadyMedia(minidlnaパッケージ)を利用することが推奨されているようだ。minidlnaグループで動作する。そのため、ライブラリはこのユーザーでアクセス可能でなくてはいけない。面倒を避けるためには、/etc/minidlna.confのinotifyをnoにしておくのが良いだろう。~/.config/minidlna/minidlna.pidのようにする。DAAPiTunesを使用しているユーザーにとっては軽快に動作する音楽ストリーミング方法。forked-daapdが推奨されているが、AURにしか存在しない。forked-daapdで動作する。LinuxではAmarokあるいはRhythemboxで再生できる。Playerなどがあるようだ。2008年頃に流行したDAAPだが、既にだいぶ廃れている印象はある。ストレージとの分離ユーザーデータ(dotfileなど)にも容量の大きなものがあるため、ストレージに退避したいと考えるかもしれないが、割とそれはリスキーである。dotfileの場合、ファイルシステムをまたぐと動作しないもの、シンボリックリンクをこえられないものがあったりする。ログイン時においてはストレージから切り離された状態にある可能性もあり、またストレージがダウンする可能性もあると考えなくてはいけない。ストレージが切り離されても動作する状態を保ったほうが良い、ということである。作業中のファイルなどは、ストレージとは別にシステム側にもあったほうが良い。ストレージが切り離された時に作業不能になる度合いを軽減するためである。xdgディレクトリはシンボリックリンクが切れているとログイン時に変更されてしまう。そのため、データが大きい~/Picturesや~/Videoなどは、単純なディレクトリとして、その下にシンボリックリンクを配置したほうが良い。Dotfiles製作中のメディアファイルはDocumentsではなく~/.storage/user/art/以下に配置し、Documentsは文書ファイルのみを配置することで軽量なディレクトリにすることができる。disks)ものスペースを一台に集約し、そのファイルを他のホストでアクセスするようにすることができた。NFS/CIFS/DLNA/DAAPでアクセスできるため、ファイルの取り扱いは非常に良いはずだ。加えてRAID5によりディスク故障やディスク破壊にも対応する。これでも壊れる可能性はある。誤消去や誤った更新・上書き、NASの故障、Btrfsの修復不能なクラッシュにどう対応するのだろうか?ここでRAIDとバックアップは違う、という基本に立ち戻る必要がある。RAID1を組み合わせたとしても、バックアップは別途必要なのである。基本的にバックアップはメインストレージと同等の設備が必要になる。RAID1としているのであれば、バックアップにおける無停止性はそれほど重要ではないため、その場合はメインストレージの半分で済むということになる。シンメトリカルな2つのストレージ群とホストが編成されることになる。slave系のコントローラホストはサーバーであり、処理性能よりも省電力性や静音性が重要となるだろう。いえ、あまりにも処理性能をおざなりにすると、SSHの処理でもたついて時間がかかることになる。MicroServerを使用しているが、どちらかといえばラップトップのほうが適性があるとされている。標準でコンソールを備え、無停電電源装置を内蔵した状態になるからだ。省電力で静音性も高い。メインホストからみた速度向上のためにはメモリは多目であったほうがいいだろう。構築、ストレージへの接続、Btrfsの作成は同様である。バックアップはBtrfsのsend/receive機能を使うことができる。差分バックアップも用意で、本当に変更されたものだけを転送するため、非常に効率が良い。次のようなスクリプトを用意する。fifiまた、slave側は次のようなスクリプトを用意する。+%y%m%d%H%M`あとは次のようにすることで転送する。btrfsreceiver.sh続いてmaster側。ここではbashを使っている。/dev/tcp/slave.local/12358暗号化の必要がないとしても、危険だと考えられるため、SSHの利用が推奨される。