NFS

NFS

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

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

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

  1. 12.10.12
  3. 13.1.1
  4. 13.2 以上

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

NFS Server features

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

Recommended options

定义 NFS 导出时，建议您还添加以下选项：

  • sync强制同步行为. 默认值是异步的，在某些情况下，如果在同步数据之前发生故障，则可能导致数据丢失.

由于使用 LDAP 运行 Omnibus 的复杂性和不使用 LDAP 维护 ID 映射的复杂性，在大多数情况下，应启用数字 UID 和 GID（在某些情况下默认情况下处于禁用状态），以简化系统之间的权限管理：

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

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

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

  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

Improving NFS performance with Puma

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

如果要将 Rugged 与 Puma 一起使用，建议 .

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

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

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 支持团队将无法协助解决与该配置有关的性能问题.

此外，该配置在特别警告：

有关受支持的数据库体系结构，请参阅有关为 GitLab HA 配置数据库的文档.

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

请注意，您应该考虑使用几个选项：

soft mount option

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

NFS 手册页指出：

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

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

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

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

A single NFS mount

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

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

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

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

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

除了更改 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 软件包提供了配置.

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

  1. Configure the database
  3. Configure the GitLab application servers