GitLab存储性能提升3倍！RustFS替代MinIO实战经验分享

最近我们团队完成了一个重要的基础设施升级：将GitLab的对象存储后端从MinIO迁移到RustFS。迁移后，CI/CD流水线速度提升了3倍，存储成本降低了60%。今天就把这次实战经验完整分享给大家。

项目背景：千人大厂的GitLab存储痛点

我们公司有1000多名开发人员，每天产生大量的CI/CD数据：

• 每日构建次数：5000+次

• 存储数据量：50TB+（制品、镜像、缓存等）

• 并发访问：高峰时段200+同时操作

原有MinIO架构的问题：

• CI/CD流水线缓慢：大型构建任务需要30+分钟

• 存储成本高昂：使用云厂商对象存储，年费用80万+

• 稳定性问题：每月出现2-3次存储服务中断

• 扩展困难：存储性能无法随业务增长线性扩展

技术选型：为什么选择RustFS？

性能对比测试

我们进行了详细的性能对比测试：

测试场景	MinIO性能	RustFS性能	提升幅度
制品上传(100MB)	45秒	15秒	300%
镜像拉取(1GB)	3分钟	50秒	360%
并发构建(20任务)	经常超时	稳定完成	无限
存储成本(TB/月)	￥120	￥40	降低66%

关键发现：RustFS在小文件并发处理上优势明显，特别适合GitLab的存储模式。

实战部署：从MinIO平稳迁移到RustFS

架构设计

GitLab实例 (Kubernetes集群)
    ↓
RustFS对象存储 (4节点集群)
    ↓  
存储分层策略 (热数据SSD + 冷数据HDD)

详细部署步骤

1. 创建专用存储桶

# 创建GitLab各功能对应的存储桶
for bucket in artifacts lfs packages registry uploads backups; do
    aws --endpoint-url http://rustfs:9000 s3 mb s3://gitlab-$bucket
    aws --endpoint-url http://rustfs:9000 s3api put-bucket-policy \
        --bucket gitlab-$bucket \
        --policy file://policies/gitlab-$bucket-policy.json
done

存储桶权限策略示例 gitlab-artifacts-policy.json：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::gitlab-artifacts/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": [
                        "10.0.1.0/24",
                        "192.168.1.0/24"
                    ]
                }
            }
        }
    ]
}

2. GitLab配置优化

创建完整的 gitlab.rb配置文件：

# 启用对象存储
gitlab_rails['object_store_enabled'] = true
gitlab_rails['object_store_proxy_download'] = true

# 公共连接配置
gitlab_rails['object_store_connection'] = {
  'provider' => 'AWS',
  'region' => 'us-east-1',
  'endpoint' => 'http://rustfs.internal:9000',
  'aws_access_key_id' => ENV['RUSTFS_ACCESS_KEY'],
  'aws_secret_access_key' => ENV['RUSTFS_SECRET_KEY'],
  'path_style' => true,
  'connect_timeout' => 10,
  'read_timeout' => 30,
  'retry_limit' => 3
}

# 1. 制品存储配置
gitlab_rails['artifacts_enabled'] = true
gitlab_rails['artifacts_object_store_enabled'] = true
gitlab_rails['artifacts_object_store_direct_upload'] = true
gitlab_rails['artifacts_object_store_proxy_download'] = true
gitlab_rails['artifacts_object_store_remote_directory'] = "gitlab-artifacts"

# 2. LFS大文件存储
gitlab_rails['lfs_object_store_enabled'] = true
gitlab_rails['lfs_object_store_direct_upload'] = true
gitlab_rails['lfs_object_store_remote_directory'] = "gitlab-lfs"

# 3. 容器镜像仓库
gitlab_rails['registry_enabled'] = true
gitlab_rails['registry_object_store_enabled'] = true
gitlab_rails['registry_object_store_remote_directory'] = "gitlab-registry"

# 4. 软件包仓库
gitlab_rails['packages_enabled'] = true
gitlab_rails['packages_object_store_enabled'] = true
gitlab_rails['packages_object_store_remote_directory'] = "gitlab-packages"

# 5. 页面上传文件
gitlab_rails['uploads_object_store_enabled'] = true
gitlab_rails['uploads_object_store_remote_directory'] = "gitlab-uploads"

# 6. 备份存储
gitlab_rails['backup_upload_connection'] = gitlab_rails['object_store_connection']
gitlab_rails['backup_upload_remote_directory'] = "gitlab-backups"

3. 性能优化配置

在RustFS端进行针对性优化：

# rustfs-gitlab-config.yaml
gitlab_optimizations:
  enabled: true
  
  # 小文件优化（制品、上传文件等）
  small_files:
    enabled: true
    merge_threshold: "64KB"  # 小于64KB的文件合并存储
    batch_operations: true   # 启用批量操作
    
  # 大文件优化（LFS、镜像等）
  large_files:
    enabled: true
    multipart_threshold: "100MB"  # 100MB以上启用分片上传
    concurrent_parts: 10          # 并发分片数
    
  # 缓存策略
  caching:
    memory_cache_size: "8GB"      # 内存缓存
    disk_cache_path: "/cache/ssd" # SSD缓存
    ttl: "24h"                    # 缓存有效期
    
  # 并发优化
  performance:
    max_connections: 5000
    io_threads: 32
    worker_threads: 16

迁移过程：平稳过渡的关键步骤

1. 数据迁移方案

我们采用双写策略，确保数据安全：

#!/bin/bash
# 数据迁移脚本：MinIO -> RustFS

SOURCE_ENDPOINT="http://minio:9000"
TARGET_ENDPOINT="http://rustfs:9000"

# 迁移函数
migrate_bucket() {
    local bucket=$1
    echo "开始迁移存储桶: $bucket"
    
    # 列出所有对象
    aws --endpoint-url $SOURCE_ENDPOINT s3 ls "s3://$bucket" --recursive | \
    while read -r line; do
        # 解析对象信息
        object=$(echo $line | awk '{print $4}')
        
        if [ -n "$object" ]; then
            echo "迁移: $object"
            
            # 复制对象
            aws --endpoint-url $SOURCE_ENDPOINT s3 cp \
                "s3://$bucket/$object" - | \
            aws --endpoint-url $ARGET_ENDPOINT s3 cp - \
                "s3://gitlab-$bucket/$object"
        fi
    done
    
    echo "完成迁移: $bucket"
}

# 并行迁移各存储桶
export -f migrate_bucket
echo "artifacts lfs packages registry uploads" | tr ' ' '\n' | \
    xargs -P 3 -I {} bash -c 'migrate_bucket "$@"' _ {}

2. 流量切换策略

采用渐进式流量切换，降低风险：

# 流量切换配置（分阶段启用）
if ENV['MIGRATION_PHASE'] == 'testing'
  # 测试阶段：只读流量到RustFS，写流量到MinIO
  gitlab_rails['object_store_read_only'] = true
elsif ENV['MIGRATION_PHASE'] == 'dual_write'
  # 双写阶段：同时写入两个存储
  gitlab_rails['object_store_backup_enabled'] = true
  gitlab_rails['object_store_backup_connection'] = {
    'provider' => 'AWS',
    'endpoint' => 'http://minio:9000',
    # ... MinIO配置
  }
else
  # 完成阶段：完全切换到RustFS
  gitlab_rails['object_store_enabled'] = true
end

性能优化实战

1. CI/CD流水线优化

优化前瓶颈：

• 大型构建任务：依赖下载频繁超时

• 并发构建：多个任务同时访问存储时性能急剧下降

• 缓存失效：每日清理导致重复下载依赖

优化方案：

# GitLab Runner配置优化
concurrent: 20
check_interval: 3

[runners.docker]
  shm_size = 2048  # 增加共享内存

# 缓存配置优化
[[runners.docker.volumes]]
  "/cache:/cache:rw"

[runners.cache]
  Type = "s3"
  Shared = true
  Path = "gitlab-runner-cache"
  [runners.cache.s3]
    ServerAddress = "rustfs.internal:9000"
    AccessKey = "${RUSTFS_ACCESS_KEY}"
    SecretKey = "${RUSTFS_SECRET_KEY}"
    BucketName = "gitlab-runner-cache"
    Insecure = false

2. 容器镜像仓库优化

Docker镜像拉取/push性能优化：

# Docker客户端配置优化
{
  "registry-mirrors": ["http://rustfs.internal:9000"],
  "max-concurrent-downloads": 10,
  "max-concurrent-uploads": 10,
  "max-download-attempts": 5
}

# 镜像分层存储优化
# 利用RustFS的重复数据删除功能，相同镜像层只存储一次

监控与告警体系

1. 关键监控指标

创建专门的GitLab+RustFS监控看板：

# Prometheus监控规则
groups:
- name: gitlab_rustfs
  rules:
  - alert: HighArtifactUploadLatency
    expr: histogram_quantile(0.95, rate(gitlab_rails_artifact_upload_duration_seconds_bucket[5m])) > 5
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "制品上传延迟过高"
      
  - alert: RustFSHighUsage
    expr: rustfs_storage_usage_bytes / rustfs_storage_capacity_bytes > 0.8
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "RustFS存储使用率超过80%"

2. 性能监控脚本

#!/usr/bin/env python3
import requests
import json
from datetime import datetime

class GitLabRustFSMonitor:
    def __init__(self, gitlab_url, rustfs_endpoint):
        self.gitlab_url = gitlab_url
        self.rustfs_endpoint = rustfs_endpoint
    
    def check_ci_performance(self):
        """检查CI/CD性能"""
        # 获取最近100个流水线的平均持续时间
        pipelines = requests.get(f"{self.gitlab_url}/api/v4/pipelines?per_page=100").json()
        
        total_duration = 0
        for pipeline in pipelines:
            if pipeline['status'] == 'success':
                total_duration += pipeline['duration']
        
        avg_duration = total_duration / len(pipelines)
        return avg_duration
    
    def check_storage_health(self):
        """检查存储健康状态"""
        health_url = f"{self.rustfs_endpoint}/health"
        try:
            response = requests.get(health_url, timeout=5)
            return response.status_code == 200
        except:
            return False
    
    def generate_daily_report(self):
        """生成每日性能报告"""
        report = {
            'date': datetime.now().isoformat(),
            'ci_performance': self.check_ci_performance(),
            'storage_health': self.check_storage_health(),
            'recommendations': []
        }
        
        if report['ci_performance'] > 1800:  # 超过30分钟
            report['recommendations'].append('考虑优化大型构建任务的缓存策略')
            
        return report

成本效益分析

迁移前后成本对比

迁移前成本（MinIO+云存储）：

• 云存储费用：50,000元/月

• MinIO许可费用：10,000元/月

• 运维人力成本：30,000元/月

• 月总计：90,000元

迁移后成本（RustFS）：

• 硬件服务器：一次性投资40万元（分摊3年）

• RustFS商业支持：15,000元/月

• 运维人力成本：10,000元/月

• 月总计：约26,000元

年节省：(90,000 - 26,000) × 12 = 768,000元

性能收益量化

指标	迁移前	迁移后	提升价值
CI/CD平均时长	45分钟	15分钟	开发效率提升，年价值约100万元
构建失败率	8%	1%	减少重复构建，年节约2000小时
存储可用性	99.5%	99.95%	减少生产事故，年价值约50万元

遇到的问题和解决方案

问题1：大文件上传超时

现象：超过2GB的LFS文件上传经常失败

解决方案：调整分片上传配置

# 增加分片大小和超时时间
gitlab_rails['object_store_connection'].merge!({
  'multipart_threshold' => 200.megabytes,
  'upload_connection_timeout' => 600,
  'upload_socket_timeout' => 600
})

问题2：缓存一致性

现象：多个Runner节点缓存不同步

解决方案：实现分布式缓存一致性

# 使用一致性哈希分布缓存
gitlab_runner_consistent_hashing: true
gitlab_runner_cache_shared: true
gitlab_runner_cache_path: "runners/${CI_RUNNER_ID}/cache"

项目成果总结

技术成果

1. 性能突破：CI/CD流水线速度提升3倍

2. 成本优化：年存储成本降低76.8万元

3. 稳定性提升：存储服务可用性达到99.95%

业务价值

1. 开发效率：工程师等待时间减少，更多时间投入编码

2. 可靠性：生产环境发布更加稳定可靠

3. 可扩展性：为未来业务增长预留充足空间

经验总结

成功关键因素

1. 充分的测试验证：在 staging 环境充分测试后再上生产

2. 渐进式迁移：采用双写策略确保数据安全

3. 完善的监控：建立全面的性能监控体系

给同行的建议

1. 提前规划存储架构：根据团队规模选择合适的集群规模

2. 重视性能调优：不同规模的GitLab实例需要不同的优化策略

3. 建立回滚预案：任何时候都要有快速回退的方案

GitLab存储迁移是个系统工程，但通过合理的技术选型和实施方案，确实能够带来显著的性能和成本收益。希望我们的实战经验对大家有所帮助！

---

以下是深入学习 RustFS 的推荐资源：RustFS

官方文档： RustFS 官方文档- 提供架构、安装指南和 API 参考。

GitHub 仓库： GitHub 仓库 - 获取源代码、提交问题或贡献代码。

社区支持： GitHub Discussions- 与开发者交流经验和解决方案。

欢迎同行交流讨论，共同提升DevOps基础设施水平！