|
サイズ: 12202
コメント:
|
サイズ: 12324
コメント:
|
| 削除された箇所はこのように表示されます。 | 追加された箇所はこのように表示されます。 |
| 行 8: | 行 8: |
| * [[NFSv4/クライアント|ＮＦＳｖ４クライアント]]については別に行う設定を前提とする。 |
ＮＦＳｖ４サーバーの作り方
目次
検証環境
- FreeBSD/amd64 10.3-RELEASE をＮＦＳｖ４【サーバー】とする。
- CentOS をサーバーにするケースは今回は無しで。
- 使用するプロトコルはＮＦＳｖ４に絞る（重要なので２回ｒｙ）。
ＮＦＳｖ４クライアントについては別に行う設定を前提とする。
- NFSv4 on ZFS 構成とし、/etc/exports ではなく sharenfs プロパティによりＮＦＳ共有設定を制御する。
- また１つのディレクトリ（≒Ｚプール）以下に集約する（ＮＦＳｖ４の名前空間的要求による）。
- もちろんバックエンドストレージをＺＦＳにしようがＵＦＳにしようが、違いは無い。ＵＦＳの場合、sharenfs でなく、/etc/exports で設定を行うくらいの違いで。
- 今回ディレクトリ作成（mkdir）＝ファイルシステム作成（zfs create）としているが、sharenfs プロパティの設定をそのまま /etc/exports に転載したものと思えばよい。
- また、ＺＦＳでもＵＦＳでもそうだが、階層外にあるものをＮＦＳ共有したいなら、nullfs で引っ張れば良い。
- バージョンの選択についてだが、過去との互換性？今時 v2 はおろか、v3 でもないでしょ、ということで、v4 ないしは v4.1（pNFS はまだ使えない orz）一択で。
ＮＦＳセキュリティメモ
ＮＦＳについてググって見ると使用状況に応じて色々と苦労している点が見られる。 Kerberos 必須という人も居れば不要という人も居るわけで、ここでは以下のアンセキュアな環境を前提とする。
専用ＮＩＣ（ＶＬＡＮ）割り当て
ＮＦＳ共有用に専用ＮＩＣ（ＶＬＡＮ）を割り当てる。そのＮＩＣにはＮＦＳ以外のサービスは提供しない。
- ＧｂＥはいいぞ。単体～数台なら十分以上の性能を発揮する。
- これは「同時」数台が帯域を使い込むような状態を想定しているので、数台がネットワークに存在するだけで飽和することを意味しない:-)。
- 可能なら１０ＧｂＥだろうけど高いし。
- 検証環境では同一ホスト内にＮＦＳサーバーとＮＦＳクライアントを共存させてみたが、単純に / 以下を対象に tar(1) で固めただけで、１．６Ｇｂｐｓ の性能が出た。
- つまり単体で最大性能発揮しようと思ったらＧｂＥは足りないかもしれないけど、１０ＧｂＥ埋めるのは結構大変。
- ましてや「複数台が同時に」という確率と合わせると数台程度ならＧｂＥでも余裕。
- まぁアレだ。キャパシティプランニングで、動画再生のような常時帯域を使いまくるような前提は勘弁な。
パケットフィルタリング無しで
ipfw/pf/iptables/tcpwrapper といったパケットフィルタリングを行わない。
- ＮＦＳｖ４に絞ってるので制限しやすくなってるが、専用ネットワークならそれほどの必要性を感じない。
- 不特定多数の人が使うような用途で、ＮＦＳクライアントの偽装やら root 権限奪取やら、あるいはそれに準じるようなアクセスがあることを想定しているなら、Kerberos 認証とか IEEE 802.1X（認証ＶＬＡＮ）とか IEEE 802.1AE（MACsec）とか導入した方がいいと思うの（言ってることの現実性はテキトー）。
認証や暗号化・アクセス制御は無しで
認証？何それ。ＵＮＩＸアカウント一択（デフォルトの -sec=sys）で。
- ＮＦＳクライアントとＮＦＳサーバーでのファイル所有者の取り扱いは可能な限りシームレスで、つまり、root は root として扱う（違うと色々面倒なんだよ）。
- Kerberos は Kerberos で大変なんだよ。 orz
- 通信の暗号化？ちょっ（ｒｙ。
- Kerberos 有効にしないとアカンって。
- IPsec？パケットは暗号化されるけど、ＮＦＳクライアントで tcpdump(8) したらバレるよねぇ。
- あぁ。ＶＰＮ越しなら IPsec もアリか。
- SELinux の類い。
- 自分アレ、コントロール（ステップアップ）できないので、disabled の扱いで。
結論
とりあえず少しずつステップアップすることがぢゅーよー、ということで、この手順を参考に難しいことに挑戦してみてください。
セットアップ
ＺＦＳ領域確保（作業例）
sysctl vfs.zfs.min_auto_ashift=12 zpool create -O atime=off export /dev/da1
- 今回、/export 上にＮＦＳ共有するファイルシステムを専用に用意するものとする（必須ではない）。
- またマウント可否は sharenfs プロパティで制御するものとする（デフォルトは off）。
- sharenfs プロパティを設定すると、/etc/zfs/exports に展開された上、mountd(8)にHUPシグナルを送られる。
/boot/loader.conf（環境依存）
vfs.zfs.trim.enabled="0"
※検証環境に使用した VMware ESXi 6.0U2 上（5.5/5.5U1/5.5U2/6.0/6.0U1 でも確認、いずれも LSI Logic SAS アダプタによる）では TRIM/UNMAP がエラーになってログがウザいので ZFS TRIM 機能をオフにする。
物理環境下なら今時のＨＤＤであれば TRIM/UNMAP 試してエラーになることは無いと思われるので、ＣＡＭのエラーメッセージがうるさい時だけ設定する。
どういうエラーメッセージが表示されるかというと、下記のようなカーネルメッセージ（SCSI/SAS なので TRIM というよりは UNMAP が実行された）で３回リトライするので３セット出力される。
(da1:mpt1:0:0:0): UNMAP. CDB: 42 00 00 00 00 00 00 00 18 00 (da1:mpt1:0:0:0): CAM status: SCSI Status Error (da1:mpt1:0:0:0): SCSI status: Check Condition (da1:mpt1:0:0:0): SCSI sense: Vendor Specific asc:0,0 (No additional sense information) (da1:mpt1:0:0:0): Error 5, Unretryable error
このあたり、dmesg(5) コマンドの結果や /var/log/messages ファイルの中を確認のこと。
/etc/rc.conf（ＮＩＣチューニング）
ifconfig_インターフェース="inet XXX.XXX.XXX.XXX netmask XXX.XXX.XXX.XXX mtu 9000"
今時のファイル共有ならＧｂＥや１０ＧｂＥ当たり前なので、ＭＴＵ値を設定する。 ＭＴＵ値はネットワーク依存で、通信に絡んでいる一番小さな値を指定することになる。必ずしも９０００（バイト）とは限らないので、ちゃんと調べよう（＆設定しよう）。
なお手動で設定できるが、その場合、ＭＴＵ値を反映するために一度、下記のようにインターフェースをダウンさせる必要がある。
ifconfig インターフェース mtu 9000 ifconfig インターフェース down ifconfig インターフェース up
/etc/sysctl.conf
ＮＦＳの最低利用バージョンの指定
vfs.nfsd.server_min_nfsvers=4
なお最大利用バージョンの指定は rc.conf 中の「nfsv4_server_enable="YES"」設定で行われている。
ＺＦＳのチューニング
vfs.zfs.min_auto_ashift=12 vfs.zfs.vdev.async_write_max_active=31
特に async_write_max_active はドライブが対応しているＮＣＱ・ＴＣＱの数（－１）を指定する（台数があれば台数分を乗算する）。
ＮＦＳのチューニング（未検証）
vfs.nfsd.issue_delegations=0 vfs.nfsd.enable_locallocks=0
vfs.nfsd.issue_delegations
- ＮＦＳサーバーでデリゲーション機能を提供するとＮＦＳクライアントにメリットがあるらしい。
- しかし、調べた範囲だと、ＮＦＳクライアントでの使用が「明言されていない」というか確認できなかったので、とりあえずオフっておく。
vfs.nfsd.enable_locallocks
- ロックについて、ＮＦＳサーバーとＮＦＳクライアント間でのロック共有ができるようになる。
- しかし、以下の組み合わせで、できたりできなかったりする。
- ＮＦＳクライアント（CentOS 6.8）→ＮＦＳサーバー（FreeBSD 10.3-R）の順でロックすると問題無くロックできる。
- ＮＦＳサーバー（FreeBSD 10.3-R）→ＮＦＳクライアント（CentOS 6.8）の順でロックするとＮＦＳクライアント側でロックされずにエラーになる。
- この問題について調査が足りてないので、とりあえずオフっておく。
- もちろんこの設定があろうが、なかろうが、ＮＦＳｖ４の売り文句であるところの、ＮＦＳクライアント（内の複数のプロセス）でのロック取得について問題無し。
- また、この話とは別に、ＮＦＳクライアント間のロック共有が可能かは未検証。
/etc/exports
V4: /export -network ネットワークアドレス -mask ネットマスク
とりあえず、/export がＮＦＳｖ４共有できるようになる。ただし、/export 自体は sharenfs=off なので、どこからからもマウントできない（厳密にはできるけどアクセスできない）。
/etc/rc.conf
- ＮＦＳｖ４サーバーとして運用するために必要なデーモンは以下の通り。
rpcbind_enable="YES" nfsuserd_enable="YES" mountd_enable="YES" nfs_server_enable="YES" nfsv4_server_enable="YES"
- また、以下の設定によりある程度のアクセス制限を行う。
rpcbind_flags="-h 公開するＮＦＳサーバーのＩＰアドレス" nfsuserd_flags="-domain アカウント識別用ドメイン" mountd_flags="-l -h 公開するＮＦＳサーバーのＩＰアドレス" nfs_server_flags="-t -h 公開するＮＦＳサーバーのＩＰアドレス"
このうち、nfsuserd_flags で指定する「ドメイン」の指定が重要となる。 ＮＦＳｖ４では、ＮＦＳサーバーとＮＦＳクライアント間のユーザー識別子を「ユーザー@ドメイン」で識別するため、合わせておく必要がある。
これはＮＦＳ共有するようなサーバー群では、同じドメインである場合、本設定を省略しても良い。
しかし、ホスティング環境でのバックアップサーバー提供のような、ＮＦＳクライアントのサーバーのドメインが統一できないような場合、サービス提供者側として、別途決め打ちする必要がある。
アカウント作成
- 先にも述べたがＮＦＳｖ４におけるＮＦＳサーバーとＮＦＳクライアント間のアカウント識別は「ユーザー＠ドメイン」である。
- これはＮＦＳｖ３／ｖ２までと違い、ＵＩＤ、ＧＩＤという数字では識別していないことを意味する（問題については後述）。
- 「ドメイン」については先に決めたとおりとする。
- よく使いそうな「ユーザー」については事前に作成しておくこと。
- ＮＦＳサーバーとＮＦＳクライアント間でアカウントミスマッチが起きると、以下の現象が発生する。
- ＮＦＳクライアント（CentOS 6.8）： nobody ユーザー・nobody グループにマップされる。
- ＮＦＳサーバー（FreeBSD 10.3-R）：32767 ユーザー・32767 グループにマップされる。
アカウント作成例
pw groupadd postgres -g 5432 pw useradd postgres -u 5432 -g postgres -c "postgres" -s /usr/sbin/nologin install -d -o postgres -g postgres -m 0755 /home/postgres
※FreeBSD の PostgreSQL 用アカウントとして pgsql （/usr/ports/UIDs ファイル参照のこと）があるが、CentOS の PostgreSQL 用アカウント（postgres）とはマッチしないので、別途作成する。
CentOS 6.x との相互運用問題
CentOS 6.8（おそらく CentOS 5.11 も） との相互運用では以下の点に注意する必要がある。
- ＮＦＳサーバー・クライアント間でＵＩＤ／ＧＩＤを合致させないといけないバグがある（ＮＦＳｖ４の仕様上、バグ認定）。
- というのもＮＦＳクライアント（CentOS 6.8）で postgres(26):postgres(26) のプロセスがアクセス（cd など）した時の、ＮＦＳサーバーへのユーザー問い合わせ結果を tcpdump(8)した結果、「postgres」ではなく「26」という文字列をＮＦＳサーバーに問い合わせ（fattr_owner）ている現象を確認した。
- なお、chown(8) や ls(1) した時には問題無い。
- 本現象について調査したところ、下記のバグがレポートされていることを確認した。
- バグレポートでは以下の点から、CentOS 6 系（少なくとも 6.8、2016年06月09日現在）以下には反映されていないものと考える。
バグレポートで言及されているディストリビューションが FedoraCore 17 である。
CentOS 6(RHEL6) は FedoraCore 12/13 ベースである。
更に CentOS 6 の nfs-utils のバージョンは 1.2.3 であるが、FedoraCore 17 では 1.2.6 である。
FedoraCore 17 ベースの CentOS 7 では問題無いと思われる（未検証）。
領域の共有設定
共有設定
/export をどう共有するかによるが「/export/ＮＦＳｖ４クライアント名」として、クライアント単位で共有設定する場合は、下記のようにパーティションを切る。
zfs create -o sharenfs="-maproot=root ＮＦＳクライアントＩＰ" export/ＮＦＳクライアント名
sharenfs 設定を行うと、/etc/zfs/exports ファイルに掃き出されるのと、合わせて mountd(8) に再読み込み（HUP シグナル）が実施される。
一つの領域を複数のＮＦＳクライアント間で共有するなら、/etc/exports に集約するのが良いと思われ（未実験）。
なおＮＦＳクライアントからは、「/ＮＦＳクライアント名」でマウントすることになる（/export がトップディレクトリとなって見えなくなる）。
更にお好みに応じて、exec=off、setuid=off も追加しよう。これはＮＦＳサーバーとしてはこれら属性を「解釈しない」という意味であって、ＮＦＳクライアントはＮＦＳクライアントで、別途設定が必要となる。
設定確認
mountd(8) の再読み込みによりＮＦＳクライアントからマウントできるようになるわけだが、これが成功したのか失敗したのかはよくわからない。 そこで、「showmount -e」コマンドと「zfs get -t filesystem sharenfs」コマンドの実行結果を見比べて判断すること（設定した内容が反映されてないなど）。
# showmount -e Exports list on localhost: /export/ＮＦＳクライアント１ XXX.XXX.XXX.XXX /export/ＮＦＳクライアント２ YYY.YYY.YYY.YYY # zfs get -t filesystem sharenfs NAME PROPERTY VALUE SOURCE export sharenfs off default export/ＮＦＳクライアント１ sharenfs -maproot=root XXX.XXX.XXX.XXX local export/ＮＦＳクライアント２ sharenfs -maproot=root YYY.YYY.YYY.YYY local
※zfs get sharenfs やべぇ。スナップショットもリストアップして大変な量に…。 orz