server

服务器环境配置初始化方案

2025/01/30更新

Posted by Seasons on January 30, 2025

实验室服务器环境配置：完整问题与解决方案记录

本文件总结了我们在医院环境下搭建一套生物信息学与人工智能研究服务器所经历的 问题背景、需求分析、网络与安全约束、硬件角色分配、软件环境部署、以及 DMZ（或网闸）策略 等，并给出了总体的配置与运维思路。该方案旨在让课题组在最少维护精力的基础上，获得一个稳定可靠、兼顾安全合规的科研环境。

1. 问题背景

  1. 医院网络环境
    • 外网访问必须通过 “VPN + 堡垒机”，且禁用自定义端口转发或 SFTP。很多常见的科研工具（RStudio, CVAT）默认使用自定义端口，这在堡垒机下难以直连。
    • 当服务器全部转入医院内网后，若仍需对外提供服务（或院外访问），只能经由 DMZ 或堡垒机进行有限端口通信；文件传输也依赖医院指定的 Web 上传工具或审计机制。
    • 安全和合规要求严格：要最少开放端口，同时有日志审计和账号+动态验证码登录策略，减少潜在风险。
  2. 硬件概况
    • 2 台 CPU 服务器 (各 2T 内存, Ubuntu 22.04)，面向生物信息分析 (R/Python) 与少量数据库需求；
    • 1 台 GPU 服务器 (1T 内存, 4×NVIDIA 4090, Ubuntu 22.04)，专注深度学习训练和 GPU 加速的图像标注(CVAT)；
    • 1 台存储服务器（ZFS） (60 盘×18TB)，提供大容量统一存储；
    • 如需对外开放 RStudio/CVAT Web 界面，则考虑自建或医院自带的 DMZ 服务器。若医院 DMZ 不灵活，我们可用 2000~3000 元预算买二手机器部署 DMZ+反向代理。
  3. 主要需求
    1. 生物信息分析：RStudio Server (安装 R 及 Bioconductor 包)、Python 生信包(pysam, bedtools 等)；
    2. 医学图像 AI：多卡 GPU 训练(Pytorch / TensorFlow)；CVAT（标注及自动标注）；
    3. 用户规模 ~10 人，大家临床和科研都忙，不想耗费大量精力反复搭建或维护；
    4. 希望一次性做好配置，既符合医院网络规范，也能长期稳定使用。
  4. 关键困惑点
    • 是否共享 /home？若把 /home 放 NFS 机械盘下，性能和环境冲突会否成为问题？
    • 要不要上 HPC 调度（Slurm）？将来若服务器扩容后，会不会难整合？
    • DMZ 是用医院现成的还是自己做？后续端口维护和安全审计怎么平衡？
    • 如何让 RStudio / CVAT / JupyterLab / VSCode Web 等端口在外网或 VPN 环境下“可访问”又不违规？

2. 整体解决思路

  1. 不共享 /home
    • 建议每台 CPU/GPU 保持本地 /home (SSD/RAID)，免去远程机械盘带来的 IO 延迟，也防止 GPU/CPU 不同驱动环境互相干扰；
    • 大数据放 ZFS 服务器，通过 NFS 挂载到 /data，在存储端做快照备份。这样兼顾集中管理与本地操作性能。
  2. 无需现在部署 HPC 集群调度
    • 目前 10 人规模，只需 RStudio/Python 手动跑脚本即可。引入 Slurm/PBS 反而增加维护负担；
    • 后续扩容时可再上线 HPC 调度器，只需保持软件环境和账号一致即可平滑过渡；可用 cgroups / systemd slice 限制资源，避免互相抢占。
  3. 关于 DMZ 服务器
    • 若要对外或院外访问 RStudio(端口 8787)、CVAT(8080)、VSCode Web 等，需要反向代理或端口映射；
    • 医院已有 DMZ 并可配置 443→内网 8787/8080 的话，就让IT统一管理；
    • 如医院 DMZ 不够灵活，我们可自建 DMZ（购二手机器 2~3k）放 DMZ VLAN，IT只需帮我们开 443(HTTPS)对外，以及 DMZ↔内网 8787/8080/8888/DB端口等白名单。这样就能以 HTTPS(443) 向外提供RStudio/CVAT/Jupyter服务。
  4. 软件环境
    • 统一 Ubuntu 22.04 LTS；
    • Miniconda 管理 Python/R 环境：CPU服务器装生信包 + RStudio Server，GPU服务器装 PyTorch/CVAT Docker；
    • 不强制容器化/HPC调度，减轻日常运维。CVAT GPU 用 Docker Compose + nvidia-container-toolkit 即可。
  5. 最小化系统升级
    • OS 只做安全补丁，不做大版本升级；
    • GPU驱动、CUDA、PyTorch、RStudio等升级需谨慎测试后再上线；
    • Conda或R包版本保持稳定，如有新需求由用户自行建虚拟环境或私有库。

3. 硬件与角色分配

  1. CPU 服务器 (2 台)
    • 各 2T 内存，跑生信分析、数据库、RStudio Server 等；
    • 本地安装 Ubuntu + Miniconda + R；挂载 ZFS /data；
    • 若并发量大，可在两台 CPU 机都装 RStudio Server 分摊用户负载。
  2. GPU 服务器 (1 台)
    • 1T 内存, 4×RTX 4090；主要用于深度学习、图像标注；
    • 安装 CUDA、PyTorch(GPU)，以及 Docker Compose 部署 CVAT GPU；
    • 可选在上面也跑RStudio Server（若需要GPU+R深度学习），但多数生信R分析放CPU即可。
  3. 存储服务器 (ZFS)
    • 60 盘×18TB；组 RAIDZ2或RAIDZ3；
    • 通过 NFS 导出 /data；可设置每日 ZFS 快照，若需本地或外部备份也可更灵活；
    • 不建议把 /home 放NFS，避免性能/环境问题。
  4. DMZ 服务器 (可选)
    • 若医院已有 DMZ 并可开放443→(内网端口)，直接使用；
    • 如不够灵活，自建一台 DMZ机(二手机器 2~3k)放 DMZ VLAN，跑 Nginx/Traefik 反向代理 (443→8787,8080…)；
    • IT 帮忙在防火墙/VPN层设置 DMZ ↔ 内网 所需端口白名单及审计。

4. 详细安装配置步骤

（详情见另一个“安装配置文档”）
这里只做整体概述：

  1. 操作系统 & 基础
    • 各服务器安装 Ubuntu 22.04 + 常用工具；UFW 只开放 SSH 22，后续按需求开 8787/8080 等；
    • 用户本地建立统一账号，cgroups / systemd slice可限资源。
  2. ZFS 服务器
    • 安装 zfsutils-linux；创建 zpool(raidz2/3)；zfs create tank/data 并 NFS 导出；
    • 定期做 ZFS 快照 (cron)。
  3. CPU 服务器
    • Miniconda + RStudio Server；在 conda 环境中安装生信 Python 包；
    • 若需数据库(MySQL/PostgreSQL)也可部署在 CPU 机上。
  4. GPU 服务器
    • 安装 NVIDIA 驱动/CUDA；
    • Miniconda + PyTorch(GPU)；Docker + nvidia-container-toolkit，用 docker-compose 启动 CVAT GPU(监听8080)。
  5. DMZ 或反向代理
    • 若医院 DMZ → 提交“443→内网”端口映射申请；
    • 自建 DMZ → 配置 Nginx/Traefik, 443 对外, 反向代理到 CPU/GPU(8787,8080,8888…)。
    • IT 帮忙在防火墙开 DMZ↔内网所需白名单端口 + 外部 VPN→DMZ 443。

5. 后续维护与注意事项

  1. 资源限制
    • cgroups / systemd slice 防单用户独占；
    • RStudio 自带 rsession-memory-limit 也可使用。
  2. 扩容 & HPC
    • 若将来服务器增多且负载上升，可再部署 Slurm/PBS 等；现阶段 10 人不太需要。
    • 只要账号/conda环境一致，后期整合并不复杂。
  3. ZFS 快照 & 数据备份
    • 建议每天自动 zfs snapshot tank/data，重要数据可做离线/异地备份；
    • 数据库(如 PostgreSQL)可配合定期 dump/备份。
  4. 最小化升级
    • 保持 GPU 驱动、CUDA、PyTorch、RStudio 等版本稳定；只打安全补丁；
    • 遇到版本冲突或功能需求可在 conda 环境内做分支升级。
  5. 网络与安全
    • 外网 or VPN 用户 → 堡垒机二次验证 → DMZ 443 → 内网(8787/8080…)；
    • 如无端口映射或反向代理，就只能 SSH 终端方式使用；
    • VSCode Remote SSH 也需堡垒机/DMZ 提供隧道或 code-server Web 端(443)支持。

6. 方案总结

  1. 核心理念
    • 不共享 /home、只共享 /data (ZFS)；
    • 不急着用 HPC 调度，维持轻量运维；
    • CPU 服务器跑生信 + RStudio、GPU 服务器跑 AI + CVAT；
    • 如果要对外提供 RStudio/CVAT Web 界面，需借助医院或自建 DMZ 443 反向代理。
  2. 可扩展性
    • 后续想加更多服务器、数据库或容器，只需在内网环境中扩展 conda/R 环境或 Docker Compose，不必重做大规模架构；
    • HPC 调度器可在以后随时引入。
  3. 运维重点
    • ZFS 快照/备份，避免数据丢失或误删；
    • CUDA/GPU 驱动升级谨慎；
    • Conda、R 包维持稳定版本，平衡功能需求与依赖冲突；
    • DMZ 服务器若自建，需要自己维护安全加固、SSL 证书与日志审计。

结语：
本方案结合了医院网络环境的严谨要求与课题组对 RStudio/CVAT/GPU 训练等科研应用的灵活需求，通过“本地 /home + ZFS /data + Miniconda + 反向代理”的架构，在安全与效率间取得折衷。若某些细节（DMZ 方式、端口开放策略）与医院实际政策有差异，可根据此思路进行微调。祝部署顺利！

CATALOG
    FEATURED TAGS
    科研 paper-reading command computer-vision polyp dataset-polyp domain adaptation life skill server GAN Python detr series detr-series segmentation