☰

NFSマウントグループ

tag-icon • tag-icon systemd nfs
NFSマウントグループ

一連のNFSマウントポイントがマウントされた複数のサーバーがあります。これらのマウントポイントに使用されるエクスポートのグループ化は、各サーバーの「特性」を定義します。各「パーソナリティ」には同じ取り付けポイントがたくさん含まれる傾向がありますが、いくつかのユニークなマウントポイントも含まれています。

これは通常、各役割に固有のfstabを格納することによって行われます（実際にはAnsibleを使用して各サーバーにマウントグループを追加します）。

ユーザーが必要に応じて（可能であれば再起動せずに）サーバーのNFS属性を切り替えると同時に、Ansibleを介して属性の制御を維持する方法を提供したいと思います。この問題を解決する方法は百万のものがあると確信していますが、より一般的な技術のいくつか（ある場合）を調べたいと思いました。

  • fstabベースのアプローチを試すべきですか？
  • systemdターゲットを使用してこれを行うより良い方法はありますか？
  • RHEL7/8 世界にこれ以上のツールがありますか？

どんなアイデアもありがとうございます！

答え1

質問を完全に理解したかどうかはわかりません。しかし、目標がMaryに乗るものをいくつか与え、Johnに別の乗り物セットを与えることであれば...

これは簡単です。

  1. 許可されたマウントポイントとアドレスを使用してファイルを生成し、fstab構造を模倣することもできます。実際のインストールは/etc/fstab通常のインストールに使用され、ルートによってのみ制御されます。したがって、ユーザーには次のことができます。
# /etc/fstab.user/mary
10.0.0.40:/source-repo repository nfs

# /etc/fstab.user/john
//server/Secret-Documents documents cifs
  1. /etc/profile次のコード（または各ユーザーに対して呼び出される同等のコード）を追加します。
if [ -e /etc/fstab.user/$USER ] ; then
   while read device dir tp
   do
      mkdir -p /home/$USER/mnt/$dir
      mount -t $tp $device /home/$USER/mnt/$dir 
   done < /etc/fstab.user/$USER
fi

したがって、各ユーザーは独自のインストールセットを持ち、$HOME/mnt/実際のrootユーザーは誰が何を得るかを制御します。

この方法は、物理フォルダ/etc/fstab.users自体がネットワークからマウントされている場合でも機能します。

答え2

あなたできる.targetユニットを使用してマウントを開始および停止 - たとえば、.mountユニットセットを個々の-one.targetに配置すると、ユーザーはターゲット全体を即座にまたはsystemctl enable無効にできます。 （しかし止めるターゲットを「サブ」ユニットに伝播するには、より多くの作業が必要な場合があり、各.mountユニットに「StopWhenUnneeded =」がある可能性があります。 )

ただし、autofs自動インストーラを使用することをお勧めします。その主な仕事はいNFSマウントグループを管理します。 （また、管理するマウントが「要求時に」という利点もあります。したがって、200個のホストがそれぞれ200個のファイルシステムをマウントしている場合、それを再起動しても数千のマウント要求は発生しません。ファイルサーバーはマウント要求でいっぱいです。あります。）

各マウントセットが同じディレクトリにある場合（たとえば、すべて/ dataのサブディレクトリ）、ディレクトリ全体を自動マウントマップ（/etc/auto.dataなど）として定義してから、「マスター」で参照できます。 (/etc/auto.master).この構造に合わないスタンドアロンインストールは、「直接」マップによって定義できます。たとえば、

  • このコンソールに合わせてカスタマイズできるメインマップ：

    # cat /etc/auto.master

/data   /etc/auto.data
/tools  /etc/auto.tools
/-      /etc/auto.direct

  • /data自動マウントマップ（/data/one、/data/twoなど）の下のマウントセット：

    # cat /etc/auto.data

one     -nosuid,nodev datahost.example.com:/exports/data_one
two     -nosuid,nodev datahost.example.com:/exports/data_two

  • 「直接」インストール用の自動インストールマッピング（どこでも）：

    # cat /etc/auto.direct

/opt/sometool    filehost.example.com:/exports/software/sometool
/var/backup      filehost.example.com:/exports/backups/$HOST

    （systemd .automountユニットを使用したことがある場合は、同じautofs機能を使用し、「直接」自動マウントマッピングと非常によく似ています。）

自動マウントサービスを開始すると、/ dataに "autofs"仮想ファイルシステムがマウントされます。〜らしい最初は空ですが、/data/oneなどのサブディレクトリが表示された場合訪問したすべてのプログラムは、対応するNFS共有からマウントされます。

Ansibleを使用すると、すべてのマップを展開し、使用可能なマスターマップの1つを「/etc/auto.master」にシンボリックリンクできます。ユーザーは、マスターマップにシンボリックリンク（「/etc/dist/auto.master.groupA」など）を再度リンクし、自動マウントデーモンを再ロードしてホスト属性を切り替えることができます。自動マウントデーモンは、管理するautofsマウントを自動的に追加または削除します。

（auto.masterファイルには、.soなどの特別なエントリを使用するディレクトリの「プラグイン」も含まれる可能性があるため、+dir:/etc/auto.master.d/ユーザーはハイブリッドシステムが必要な場合はより小さい部分をシンボリックリンクできます。）

答え3

デフォルトのターゲットデバイスごとにグループ化されたシステムマウントと自動マウントデバイスを数回繰り返した後、通常のfstabジェネレータがすでに提供した動作を複製するために必要な依存関係とさまざまなオプションが泥棒に陥ったことがわかりました。

各「個性」に対する多くの（ほぼ50の）マウントポイントにより、作業全体が面倒で、続行できなくなりました。だから私はfstabエントリの完全なセクション（キーワードでブロックされています）を取り、そのセクションのコメントを効果的に削除し、同時に他のfstabエントリのグループの塊をコメントアウトするPythonツールをバックアップして作成しました。サーバーを再起動すると、fstabジェネレータは強制的にデバイスを再構築します。

その後、特権管理者は新しいツールを使用してサーバー属性を切り替えてサーバーを再起動できます。

学んだ教訓は、システムfstabジェネレータのように複雑なものを再実装しようとしないことです。私はそれがどのように機能するかをよく学びましたが、私が持っているマウントポイントの数と多数の依存関係（1つのマウントは異なるマウントによって異なり、自動マウントなど...）のためにfstabでエントリを指定できるという便利さも非常に優れています。無視するのが有利です。 Ansibleで（100個のユニットファイルの代わりに）単一のマスターfstab（blockinfile）を管理できるという単純さも無視できません。

確かに、fstabジェネレータが任意の入力ファイル（fstab）から単位を生成し、システム検索パスと組み合わせることができる任意のパスに出力する方法がある場合は、他の解決策があります（私のRHEL7環境では不可能）。 ）計画。

ご意見をお寄せいただきありがとうございます。

関連情報