NFS

原文：https://docs.gitlab.com/ee/administration/high_availability/nfs.html

NFS

您可以通过运行nfsstat -m和cat /etc/fstab来查看每个已安装的 NFS 文件系统的信息和选项集.

注意：从 GitLab 13.0 开始，不建议将 NFS 用于 Git 存储库. 在 GitLab 14.0 中，计划删除对 Nit for Git 存储库的支持. 尽快升级到Gitaly Cluster .注意：文件系统的性能对整体 GitLab 的性能有很大的影响，特别是对于读取或写入 Git 存储库的操作. 有关测试文件系统性能的步骤，请参见文件系统性能基准测试.

Known kernel version incompatibilities

RedHat Enterprise Linux（RHEL）和 CentOS v7.7 和 v7.8 附带了内核版本3.10.0-1127 ，该版本包含一个错误 ， 该错误会导致上传无法通过 NFS 复制 . 以下 GitLab 版本包含一个可与该内核版本一起正常使用的修复程序：

  1. 12.10.12
  2. 13.0.7
  3. 13.1.1
  4. 13.2 以上

如果使用的是该内核版本，请确保升级 GitLab 以避免错误.

NFS Server features

Required features

文件锁定 ：GitLab 需要咨询性文件锁定，只有 NFS 版本 4 才支持该功能.只要使用 Linux Kernel 2.6.5 +，NFSv3 还支持锁定. 我们建议使用版本 4，并且不要专门测试 NFSv3.

Recommended options

定义 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（在某些情况下默认情况下处于禁用状态），以简化系统之间的权限管理：

Disable NFS server delegation

我们建议所有 NFS 用户禁用 NFS 服务器委派功能. 这是为了避免Linux 内核错误 ，该错误会由于来自大量TEST_STATEID NFS 消息的过多网络流量而导致 NFS 客户端急剧减速.

要禁用 NFS 服务器委派，请执行以下操作：

  1. 在 NFS 服务器上，运行：

    1. echo 0 > /proc/sys/fs/leases-enable
    2. sysctl -w fs.leases-enable=0

  2. 重新启动 NFS 服务器进程. 例如，在 CentOS 上运行service nfs restart .

Important notes

此提交可能会在较新的内核中修复内核错误.

Red Hat Enterprise 7 于 2019 年 8 月 6 日发布了内核更新 ， 该更新也可能已解决了该问题.

如果您知道使用的是已修复的 Linux 内核版本，则可能不需要禁用 NFS 服务器委派. 也就是说，GitLab 仍然鼓励实例管理员保持 NFS 服务器委派禁用.

Improving NFS performance with GitLab

Improving NFS performance with Unicorn

注意：从 GitLab 12.1 开始，如果可以并且应该为每个存储使用 Rugged，它将自动检测到它.

如果先前使用功能标记启用了 Rugged，则需要使用以下方法取消设置功能标记：

  1. sudo gitlab-rake gitlab:features:unset_rugged

如果将 Rugged 功能标志显式设置为 true 或 false，则 GitLab 将使用显式设置的值.

Improving NFS performance with Puma

注意：从 GitLab 12.7 开始，如果 Puma 线程数大于 1，则将禁用 Rugged 自动检测.

如果要将 Rugged 与 Puma 一起使用，建议将 Puma 线程数设置为 1 .

如果您想使用 Rugged 且 Puma 线程数大于 1，则可以使用功能标志启用 Rugged

如果将 Rugged 功能标志显式设置为 true 或 false，则 GitLab 将使用显式设置的值.

Known issues

Avoid using AWS’s Elastic File System (EFS)

GitLab 强烈建议您不要使用 AWS Elastic File System（EFS）. 我们的支持团队将无法协助解决与文件系统访问相关的性能问题.

客户和用户报告说，AWS EFS 在 GitLab 的用例中表现不佳. 以串行化方式写入许多小文件的工作负载（例如git ）不适合 EFS. 顶部带有 NFS 服务器的 EBS 的性能会好得多.

如果确实选择使用 EFS，请避免在其中存储 GitLab 日志文件（例如/var/log/gitlab ），因为这也会影响性能. 我们建议将日志文件存储在本地卷上.

有关其他人使用 EFS 的经验的更多详细信息，请参阅此Commit Brooklyn 2019 视频 .

Avoid using CephFS and GlusterFS

GitLab 强烈建议不要使用 CephFS 和 GlusterFS. 这些分布式文件系统不适用于 GitLab 的输入/输出访问模式，因为 Git 使用许多小文件，并且传播的访问时间和文件锁定时间会使 Git 活动非常缓慢.

Avoid using PostgreSQL with NFS

GitLab 强烈建议不要跨 NFS 运行 PostgreSQL 数据库. GitLab 支持团队将无法协助解决与该配置有关的性能问题.

此外，该配置在PostgreSQL 文档中特别警告：

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 配置数据库的文档.

NFS Client mount options

这是添加到/etc/fstab的示例片段：

  1.  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
  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
  3.    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
  4.    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
  5.    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 客户端错误，由于过时的数据可能导致严重的问题.
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

我们建议您在安装选项中使用hard ，除非您出于特殊原因使用soft .

在 GitLab.com，我们使用soft ，因为有些时候我们不得不 NFS 服务器重新启动和soft改进的可用性，但每个人的基础不同. 例如，如果您的 NFS 由带有冗余控制器的本地存储阵列提供，则无需担心 NFS 服务器的可用性.

NFS 手册页指出：

在某些情况下，”软”超时可能会导致无提示数据损坏

阅读Linux 手册页以了解它们之间的区别，如果您确实使用soft ，请确保已采取步骤减轻风险.

如果您遇到的问题可能是由于未发生对 NFS 服务器的磁盘写入而导致的，例如丢失了提交，请使用hard选项，因为（在手册页中）：

仅当客户端响应能力比数据完整性更重要时才使用 soft 选项

其他供应商也提出了类似的建议，包括SAP和 NetApp 的知识库 ，他们强调说，如果 NFS 客户端驱动程序缓存数据，则soft意味着无法确定 GitLab 的写操作是否确实在磁盘上.

使用hard选项设置的安装点可能无法正常运行，并且如果 NFS 服务器关闭，则hard会导致与安装点进行交互时挂起进程. 使用SIGKILL （ kill -9 ）处理挂起的进程. intr选项在 2.6 内核中停止工作 .

A single NFS mount

建议将所有 GitLab 数据目录嵌套在一个装载中，这样可以自动还原备份而无需手动移动现有数据.

  1. mountpoint
  2. └── gitlab-data
  3.     ├── builds
  4.     ├── git-data
  5.     ├── shared
  6.     └── uploads

为此，我们需要使用嵌套在安装点中的每个目录的路径来配置 Omnibus，如下所示：

然后挂载/gitlab-nfs使用以下 Omnibus 配置将每个数据位置移动到子目录：

  1. git_data_dirs({"default" => { "path" => "/gitlab-nfs/gitlab-data/git-data"} })
  2. gitlab_rails['uploads_directory'] = '/gitlab-nfs/gitlab-data/uploads'
  3. gitlab_rails['shared_path'] = '/gitlab-nfs/gitlab-data/shared'
  4. gitlab_ci['builds_directory'] = '/gitlab-nfs/gitlab-data/builds'

运行sudo gitlab-ctl reconfigure以开始使用中心位置. 请注意，如果您已有数据，则需要手动将其复制/同步到这些新位置，然后重新启动 GitLab.

Bind mounts

除了更改 Omnibus 中的配置外，绑定挂载还可用于将数据存储在 NFS 挂载上.

绑定挂载提供一种仅指定一个 NFS 挂载，然后将默认的 GitLab 数据位置绑定到 NFS 挂载的方法. 首先定义您的单个 NFS 挂载点，就像通常在/etc/fstab . 假设您的 NFS 挂载点是/gitlab-nfs . 然后，在/etc/fstab添加以下绑定安装：

  1. /gitlab-nfs/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0
  2. /gitlab-nfs/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0
  3. /gitlab-nfs/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0
  4. /gitlab-nfs/gitlab-data/shared /var/opt/gitlab/gitlab-rails/shared none bind 0 0
  5. /gitlab-nfs/gitlab-data/builds /var/opt/gitlab/gitlab-ci/builds none bind 0 0

使用绑定安装将需要手动确保数据目录为空，然后再尝试还原. 阅读有关还原先决条件的更多信息.

Multiple NFS mounts

使用默认的 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 日志传送的配置.

具有多个 NFS 挂载将需要手动确保数据目录为空，然后再尝试还原. 阅读有关还原先决条件的更多信息.

阅读更多有关高可用性配置的信息：

  1. Configure the database
  2. Configure Redis
  3. Configure the GitLab application servers
  4. Configure the load balancers