NFS · Gitlab 中文文檔

# NFS > 原文：[https://docs.gitlab.com/ee/administration/high_availability/nfs.html](https://docs.gitlab.com/ee/administration/high_availability/nfs.html) * [Known kernel version incompatibilities](#known-kernel-version-incompatibilities) * [NFS Server features](#nfs-server-features) * [Required features](#required-features) * [Recommended options](#recommended-options) * [Disable NFS server delegation](#disable-nfs-server-delegation) * [Important notes](#important-notes) * [Improving NFS performance with GitLab](#improving-nfs-performance-with-gitlab) * [Improving NFS performance with Unicorn](#improving-nfs-performance-with-unicorn) * [Improving NFS performance with Puma](#improving-nfs-performance-with-puma) * [Known issues](#known-issues) * [Avoid using AWS’s Elastic File System (EFS)](#avoid-using-awss-elastic-file-system-efs) * [Avoid using CephFS and GlusterFS](#avoid-using-cephfs-and-glusterfs) * [Avoid using PostgreSQL with NFS](#avoid-using-postgresql-with-nfs) * [NFS Client mount options](#nfs-client-mount-options) * [soft mount option](#soft-mount-option) * [A single NFS mount](#a-single-nfs-mount) * [Bind mounts](#bind-mounts) * [Multiple NFS mounts](#multiple-nfs-mounts) # NFS[](#nfs "Permalink") 您可以通過運行`nfsstat -m`和`cat /etc/fstab`來查看每個已安裝的 NFS 文件系統的信息和選項集. **注意：**從 GitLab 13.0 開始，不建議將 NFS 用于 Git 存儲庫. 在 GitLab 14.0 中，計劃刪除對 Nit for Git 存儲庫的支持. 盡快升級到[Gitaly Cluster](../gitaly/praefect.html) .**注意：**文件系統的性能對整體 GitLab 的性能有很大的影響，特別是對于讀取或寫入 Git 存儲庫的操作. 有關測試文件系統性能的步驟，請參見[文件系統性能基準](../operations/filesystem_benchmarking.html)測試. ## Known kernel version incompatibilities[](#known-kernel-version-incompatibilities "Permalink") RedHat Enterprise Linux（RHEL）和 CentOS v7.7 和 v7.8 附帶了內核版本`3.10.0-1127` ，該版本[包含一個錯誤](https://bugzilla.redhat.com/show_bug.cgi?id=1783554) ， [該錯誤](https://bugzilla.redhat.com/show_bug.cgi?id=1783554)會導致[上傳無法通過 NFS 復制](https://gitlab.com/gitlab-org/gitlab/-/issues/218999) . 以下 GitLab 版本包含一個可與該內核版本一起正常使用的修復程序： 1. [12.10.12](https://about.gitlab.com/releases/2020/06/25/gitlab-12-10-12-released/) 2. [13.0.7](https://about.gitlab.com/releases/2020/06/25/gitlab-13-0-7-released/) 3. [13.1.1](https://about.gitlab.com/releases/2020/06/24/gitlab-13-1-1-released/) 4. 13.2 以上如果使用的是該內核版本，請確保升級 GitLab 以避免錯誤. ## NFS Server features[](#nfs-server-features "Permalink") ### Required features[](#required-features "Permalink") **文件鎖定** ：GitLab **需要**咨詢性文件鎖定，只有 NFS 版本 4 才支持該功能.只要使用 Linux Kernel 2.6.5 +，NFSv3 還支持鎖定. 我們建議使用版本 4，并且不要專門測試 NFSv3. ### Recommended options[](#recommended-options "Permalink") 定義 NFS 導出時，建議您還添加以下選項： * `no_root_squash` -NFS 通常將`root`用戶更改為`nobody` . 當許多不同的用戶將訪問 NFS 共享時，這是一個很好的安全措施. 但是，在這種情況下，只有 GitLab 會使用 NFS 共享，因此很安全. GitLab 建議使用`no_root_squash`設置，因為我們需要自動管理文件權限. 如果沒有該設置，則當 Omnibus 軟件包嘗試更改權限時，您可能會收到錯誤消息. 請注意，GitLab 和其他捆綁組件**不是**以`root`用戶身份運行，而是以非特權用戶身份運行. 對于`no_root_squash`的建議是允許 Omnibus 軟件包根據需要設置文件的所有權和權限. 在`no_root_squash`選項不可用的某些情況下， `root`標志可以實現相同的結果. * `sync`強制同步行為. 默認值是異步的，在某些情況下，如果在同步數據之前發生故障，則可能導致數據丟失. 由于使用 LDAP 運行 Omnibus 的復雜性和不使用 LDAP 維護 ID 映射的復雜性，在大多數情況下，應啟用數字 UID 和 GID（在某些情況下默認情況下處于禁用狀態），以簡化系統之間的權限管理： * [NetApp instructions](https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-24367A9F-E17B-4725-ADC1-02D86F56F78E.html) * 對于非 NetApp 設備，請執行與[啟用 NFSv4 idmapper](https://wiki.archlinux.org/index.php/NFS#Enabling_NFSv4_idmapping)相反的`idmapping`來禁用[NFSv4 idmapping](https://wiki.archlinux.org/index.php/NFS#Enabling_NFSv4_idmapping) ### Disable NFS server delegation[](#disable-nfs-server-delegation "Permalink") 我們建議所有 NFS 用戶禁用 NFS 服務器委派功能. 這是為了避免[Linux 內核錯誤](https://bugzilla.redhat.com/show_bug.cgi?id=1552203) ，該[錯誤](https://bugzilla.redhat.com/show_bug.cgi?id=1552203)會由于[來自大量`TEST_STATEID` NFS 消息的過多網絡流量](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52017)而導致 NFS 客戶端急劇減速. 要禁用 NFS 服務器委派，請執行以下操作： 1. 在 NFS 服務器上，運行： ``` echo 0 > /proc/sys/fs/leases-enable sysctl -w fs.leases-enable=0 ``` 2. 重新啟動 NFS 服務器進程. 例如，在 CentOS 上運行`service nfs restart` . #### Important notes[](#important-notes "Permalink") [此提交](https://github.com/torvalds/linux/commit/95da1b3a5aded124dd1bda1e3cdb876184813140)可能會在[較新的內核中](https://github.com/torvalds/linux/commit/95da1b3a5aded124dd1bda1e3cdb876184813140)修復內核錯誤. Red Hat Enterprise 7 于 2019 年 8 月 6 日[發布了內核更新](https://access.redhat.com/errata/RHSA-2019:2029) ， [該更新](https://access.redhat.com/errata/RHSA-2019:2029)也可能已解決了該問題. 如果您知道使用的是已修復的 Linux 內核版本，則可能不需要禁用 NFS 服務器委派. 也就是說，GitLab 仍然鼓勵實例管理員保持 NFS 服務器委派禁用. ### Improving NFS performance with GitLab[](#improving-nfs-performance-with-gitlab "Permalink") #### Improving NFS performance with Unicorn[](#improving-nfs-performance-with-unicorn "Permalink") **注意：**從 GitLab 12.1 開始，如果可以并且應該為每個存儲使用 Rugged，它將自動檢測到它. 如果先前使用功能標記啟用了 Rugged，則需要使用以下方法取消設置功能標記： ``` sudo gitlab-rake gitlab:features:unset_rugged ``` 如果將 Rugged 功能標志顯式設置為 true 或 false，則 GitLab 將使用顯式設置的值. #### Improving NFS performance with Puma[](#improving-nfs-performance-with-puma "Permalink") **注意：**從 GitLab 12.7 開始，如果 Puma 線程數大于 1，則將禁用 Rugged 自動檢測. 如果要將 Rugged 與 Puma 一起使用，建議[將 Puma 線程數設置為 1](https://docs.gitlab.com/omnibus/settings/puma.html) . 如果您想使用 Rugged 且 Puma 線程數大于 1，則可以使用[功能標志](../../development/gitaly.html#legacy-rugged-code)啟用 Rugged 如果將 Rugged 功能標志顯式設置為 true 或 false，則 GitLab 將使用顯式設置的值. ### Known issues[](#known-issues "Permalink") #### Avoid using AWS’s Elastic File System (EFS)[](#avoid-using-awss-elastic-file-system-efs "Permalink") GitLab 強烈建議您不要使用 AWS Elastic File System（EFS）. 我們的支持團隊將無法協助解決與文件系統訪問相關的性能問題. 客戶和用戶報告說，AWS EFS 在 GitLab 的用例中表現不佳. 以串行化方式寫入許多小文件的工作負載（例如`git` ）不適合 EFS. 頂部帶有 NFS 服務器的 EBS 的性能會好得多. 如果確實選擇使用 EFS，請避免在其中存儲 GitLab 日志文件（例如`/var/log/gitlab` ），因為這也會影響性能. 我們建議將日志文件存儲在本地卷上. 有關其他人使用 EFS 的經驗的更多詳細信息，請參閱此[Commit Brooklyn 2019 視頻](https://youtu.be/K6OS8WodRBQ?t=313) . #### Avoid using CephFS and GlusterFS[](#avoid-using-cephfs-and-glusterfs "Permalink") GitLab 強烈建議不要使用 CephFS 和 GlusterFS. 這些分布式文件系統不適用于 GitLab 的輸入/輸出訪問模式，因為 Git 使用許多小文件，并且傳播的訪問時間和文件鎖定時間會使 Git 活動非常緩慢. #### Avoid using PostgreSQL with NFS[](#avoid-using-postgresql-with-nfs "Permalink") GitLab 強烈建議不要跨 NFS 運行 PostgreSQL 數據庫. GitLab 支持團隊將無法協助解決與該配置有關的性能問題. 此外，該配置在[PostgreSQL 文檔中](https://s0www0postgresql0org.icopy.site/docs/current/creating-cluster.html)特別警告： > PostgreSQL does nothing special for NFS file systems, meaning it assumes NFS behaves exactly like locally-connected drives. If the client or server NFS implementation does not provide standard file system semantics, this can cause reliability problems. Specifically, delayed (asynchronous) writes to the NFS server can cause data corruption problems. 有關受支持的數據庫體系結構，請參閱有關[為 GitLab HA 配置數據庫的](../postgresql/replication_and_failover.html)文檔. ## NFS Client mount options[](#nfs-client-mount-options "Permalink") 這是添加到`/etc/fstab`的示例片段： ``` 10.1.0.1:/var/opt/gitlab/.ssh /var/opt/gitlab/.ssh nfs4 defaults,vers=4.1,hard,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2 10.1.0.1:/var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/uploads nfs4 defaults,vers=4.1,hard,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2 10.1.0.1:/var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-rails/shared nfs4 defaults,vers=4.1,hard,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2 10.1.0.1:/var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/gitlab-ci/builds nfs4 defaults,vers=4.1,hard,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2 10.1.0.1:/var/opt/gitlab/git-data /var/opt/gitlab/git-data nfs4 defaults,vers=4.1,hard,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2 ``` 請注意，您應該考慮使用幾個選項： | Setting | Description | | --- | --- | | `vers=4.1` | 應該使用 NFS v4.1 代替 v4.0，因為 v4.0 中存在一個 Linux [NFS 客戶端錯誤，](https://gitlab.com/gitlab-org/gitaly/-/issues/1339)由于過時的數據可能導致嚴重的問題. | | `nofail` | 不要停止啟動過程，等待此掛載可用 | | `lookupcache=positive` | Tells the NFS client to honor `positive` cache results but invalidates any `negative` cache results. Negative cache results cause problems with Git. Specifically, a `git push` can fail to register uniformly across all NFS clients. The negative cache causes the clients to ‘remember’ that the files did not exist previously. | | `hard` | 而不是`soft` . [進一步的細節](#soft-mount-option) . | ### soft mount option[](#soft-mount-option "Permalink") 我們建議您在安裝選項中使用`hard` ，除非您出于特殊原因使用`soft` . 在 GitLab.com，我們使用`soft` ，因為有些時候我們不得不 NFS 服務器重新啟動和`soft`改進的可用性，但每個人的基礎不同. 例如，如果您的 NFS 由帶有冗余控制器的本地存儲陣列提供，則無需擔心 NFS 服務器的可用性. NFS 手冊頁指出： > 在某些情況下，"軟"超時可能會導致無提示數據損壞閱讀[Linux 手冊頁](https://linux.die.net/man/5/nfs)以了解它們之間的區別，如果您確實使用`soft` ，請確保已采取步驟減輕風險. 如果您遇到的問題可能是由于未發生對 NFS 服務器的磁盤寫入而導致的，例如丟失了提交，請使用`hard`選項，因為（在手冊頁中）： > 僅當客戶端響應能力比數據完整性更重要時才使用 soft 選項其他供應商也提出了類似的建議，包括[SAP](http://wiki.scn.sap.com/wiki/x/PARnFQ)和 NetApp 的[知識庫](https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/What_are_the_differences_between_hard_mount_and_soft_mount) ，他們強調說，如果 NFS 客戶端驅動程序緩存數據，則`soft`意味著無法確定 GitLab 的寫操作是否確實在磁盤上. 使用`hard`選項設置的安裝點可能無法正常運行，并且如果 NFS 服務器關閉，則`hard`會導致與安裝點進行交互時掛起進程. 使用`SIGKILL` （ `kill -9` ）處理掛起的進程. `intr`選項[在 2.6 內核中停止工作](https://access.redhat.com/solutions/157873) . ## A single NFS mount[](#a-single-nfs-mount "Permalink") 建議將所有 GitLab 數據目錄嵌套在一個裝載中，這樣可以自動還原備份而無需手動移動現有數據. ``` mountpoint └── gitlab-data ├── builds ├── git-data ├── shared └── uploads ``` 為此，我們需要使用嵌套在安裝點中的每個目錄的路徑來配置 Omnibus，如下所示：然后掛載`/gitlab-nfs`使用以下 Omnibus 配置將每個數據位置移動到子目錄： ``` git_data_dirs({"default" => { "path" => "/gitlab-nfs/gitlab-data/git-data"} }) gitlab_rails['uploads_directory'] = '/gitlab-nfs/gitlab-data/uploads' gitlab_rails['shared_path'] = '/gitlab-nfs/gitlab-data/shared' gitlab_ci['builds_directory'] = '/gitlab-nfs/gitlab-data/builds' ``` 運行`sudo gitlab-ctl reconfigure`以開始使用中心位置. 請注意，如果您已有數據，則需要手動將其復制/同步到這些新位置，然后重新啟動 GitLab. ## Bind mounts[](#bind-mounts "Permalink") 除了更改 Omnibus 中的配置外，綁定掛載還可用于將數據存儲在 NFS 掛載上. 綁定掛載提供一種僅指定一個 NFS 掛載，然后將默認的 GitLab 數據位置綁定到 NFS 掛載的方法. 首先定義您的單個 NFS 掛載點，就像通常在`/etc/fstab` . 假設您的 NFS 掛載點是`/gitlab-nfs` . 然后，在`/etc/fstab`添加以下綁定安裝： ``` /gitlab-nfs/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0 /gitlab-nfs/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0 /gitlab-nfs/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0 /gitlab-nfs/gitlab-data/shared /var/opt/gitlab/gitlab-rails/shared none bind 0 0 /gitlab-nfs/gitlab-data/builds /var/opt/gitlab/gitlab-ci/builds none bind 0 0 ``` 使用綁定安裝將需要手動確保數據目錄為空，然后再嘗試還原. 閱讀有關[還原先決條件的](../../raketasks/backup_restore.html)更多信息. ## Multiple NFS mounts[](#multiple-nfs-mounts "Permalink") 使用默認的 Omnibus 配置時，您將需要在所有 GitLab 群集節點之間共享 4 個數據位置. 沒有其他位置可以共享. 以下是需要共享的四個位置： | Location | Description | 默認配置 | | --- | --- | --- | | `/var/opt/gitlab/git-data` | Git 存儲庫數據. 這將占您數據的很大一部分 | `git_data_dirs({"default" => { "path" => "/var/opt/gitlab/git-data"} })` | | `/var/opt/gitlab/gitlab-rails/uploads` | 用戶上傳的附件 | `gitlab_rails['uploads_directory'] = '/var/opt/gitlab/gitlab-rails/uploads'` | | `/var/opt/gitlab/gitlab-rails/shared` | Build artifacts, GitLab Pages, LFS objects, temp files, etc. If you’re using LFS this may also account for a large portion of your data | `gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared'` | | `/var/opt/gitlab/gitlab-ci/builds` | GitLab CI / CD 構建跟蹤 | `gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'` | 其他 GitLab 目錄不應在節點之間共享. 它們包含特定于節點的文件和不需要共享的 GitLab 代碼. 要將日志發送到中央位置，請考慮使用遠程 syslog. Omnibus GitLab 軟件包提供了[UDP 日志傳送的](https://docs.gitlab.com/omnibus/settings/logs.html)配置. 具有多個 NFS 掛載將需要手動確保數據目錄為空，然后再嘗試還原. 閱讀有關[還原先決條件的](../../raketasks/backup_restore.html)更多信息. * * * 閱讀更多有關高可用性配置的信息： 1. [Configure the database](../postgresql/replication_and_failover.html) 2. [Configure Redis](redis.html) 3. [Configure the GitLab application servers](gitlab.html) 4. [Configure the load balancers](load_balancer.html)