1. 项目概述与核心价值

最近在帮一个客户做私有云环境搭建，他们采购了深信服的超融合一体机，需要在上面批量部署一批Ubuntu 22.04 LTS的虚拟机，用作开发测试环境。这个需求听起来很常规，但实际操作下来，我发现从规划镜像、配置模板到最终批量克隆，每一步都有不少细节需要注意，尤其是在深信服HCI（超融合基础设施）这个特定平台上，和我们在VMware vSphere或者Proxmox上习惯的操作逻辑有些不同。如果你也正面临类似的任务，或者对在超融合平台上部署标准化Linux系统感兴趣，这篇从实战中总结出来的记录或许能帮你避开我踩过的那些坑。

简单来说，超融合架构把计算、存储、网络都打包在了一起，管理起来是方便了，但正因为高度集成，一些底层的配置选项反而被封装或转移了位置。部署Ubuntu 22.04 LTS本身不难，难的是如何利用深信服HCI平台提供的特性，高效、标准化地完成部署，并且让虚拟机在后续使用中性能稳定、易于管理。这不仅仅是点几下“新建虚拟机”那么简单，它涉及到镜像准备、虚拟机模板优化、网络与存储策略对接，以及一些平台专有的性能调优参数。接下来，我就把这套从零开始的部署流程和核心要点拆开揉碎了讲清楚。

2. 部署前的核心准备工作

在点击“创建虚拟机”按钮之前，充分的准备工作能让你事半功倍，避免部署到一半发现缺这少那，又要推倒重来。

2.1 镜像获取与验证

Ubuntu 22.04 LTS的官方镜像可以从Ubuntu官网或国内镜像站（如阿里云、清华源）下载。这里有个关键选择：是下载传统的ISO安装镜像，还是使用预制的云镜像（Cloud Image）？

• ISO安装镜像：就是大家最熟悉的那个安装盘。它的好处是通用性强，安装过程可视化，可以自定义分区、软件包选择等所有细节。但在超融合平台批量部署时，缺点也很明显：安装过程完全手动或需要配合自动化工具（如Kickstart、Preseed），耗时较长。
• Cloud Image (qcow2/raw)：这是为云环境和虚拟化量身定制的镜像。它通常已经预装了cloud-init，系统最小化，开箱即用。在深信服HCI上，我强烈推荐使用这个。因为它能无缝对接平台的“虚拟机模板”和“自定义规范”功能，实现主机名、IP地址、密码等的自动化注入，实现真正的无人值守批量部署。

我这次选择的是Ubuntu 22.04 LTS Cloud Image (qcow2格式)。下载后，务必校验其SHA256值，确保镜像完整未篡改。这是保证后续所有系统稳定性的基石。

2.2 深信服HCI平台环境检查

登录到深信服超融合平台的管理界面，你需要确认以下几个关键点，它们直接影响部署的可行性和效率：

1. 存储资源池状态：确认你有足够的存储空间，并且性能池（通常为SSD）和容量池（通常为HDD）状态健康。Ubuntu系统盘建议放在性能池以获得更好的IO体验。
2. 网络配置：确认你已经规划并创建好了虚拟机需要接入的业务网络（VXLAN或VLAN类型）。记下网络的名称和ID。更重要的是，检查DHCP服务是否就绪，或者你是否准备使用静态IP。如果使用cloud-init配合静态IP，需要提前规划好IP、网关、DNS信息。
3. 计算资源：确认集群内有足够的CPU和内存资源。虽然Ubuntu桌面版最低要求不高，但作为服务器用途，建议至少分配2核CPU、4GB内存。对于开发测试环境，我通常从2C4G起步。
4. 权限与角色：确保你使用的账号有创建虚拟机、上传镜像、操作存储和网络的相应权限。用错账号卡在权限问题上是最耽误时间的。

注意：深信服HCI的不同版本（如标准版、高级版）以及软件版本号，其界面和部分功能位置可能略有差异。本文基于较新的常见版本进行描述，核心逻辑相通。

3. 创建虚拟机模板：效率的关键

直接使用原始Cloud Image每次创建虚拟机效率很低。最佳实践是先将这个镜像制作成一个高度优化的“虚拟机模板”，以后所有新虚拟机都从这个模板克隆，秒级生成。

3.1 上传镜像与创建初始虚拟机

首先，我们需要把下载的qcow2镜像上传到平台，并以此创建第一台“母机”。

1. 上传镜像：在HCI管理平台的“存储”或“镜像”管理页面，找到上传功能。将本地的ubuntu-22.04-server-cloudimg-amd64.img（或类似名称）文件上传到平台的某个存储池中。这个过程可能需要一些时间，取决于镜像大小和网络速度。
2. 创建虚拟机：使用“从镜像创建”的方式新建一台虚拟机。
   • 名称：命名为类似template-ubuntu2204-base。
   • 镜像：选择你刚刚上传的Ubuntu Cloud Image。
   • 计算配置：CPU和内存按需分配，例如2核4G。这里配置的是模板的基准规格，克隆时可以调整。
   • 系统盘：重要！Cloud Image本身很小（约600MB），但系统盘需要预留增长空间。建议设置一个合适的容量，例如40GB或80GB，并选择“精简置备”以节省初始存储空间。存储策略选择高性能的SSD存储池。
   • 网络：添加一个网络适配器，连接到你的业务网络。此处先不绑定任何IP地址，IP配置留给cloud-init。
   • 其他：虚拟硬件版本选择平台推荐的最高兼容版本。不需要添加CD-ROM。

3.2 系统初始化与通用化处理

创建成功后，不要立即启动这台虚拟机。我们需要先对其进行一些“模板化”处理，使其变得通用、干净。

1. 配置Cloud-Init数据源：Cloud-Init默认会监听多种数据源（如NoCloud, ConfigDrive, OpenStack等）。在深信服HCI中，虚拟机初始化数据通常通过类似“自定义规范”或“初始化脚本”的功能注入，其底层机制可能模拟了NoCloud数据源。为了确保兼容性，我们可以在模板中安装并配置cloud-init，明确其数据源优先级。但这通常不是必须的，因为Cloud Image已内置。

2. 安装常用工具与优化：启动这台模板虚拟机，进行登录（初始用户通常是ubuntu，密码随机或为空，需要通过平台控制台查看）。进入系统后，执行一系列标准化操作：

   • 更新系统：sudo apt update && sudo apt upgrade -y
   • 安装常用工具：sudo apt install -y curl wget vim net-tools open-vm-tools（如果平台需要）
   • 清理临时文件：sudo apt autoremove -y && sudo apt autoclean
   • 清理历史命令和日志：sudo rm -f /var/log/*.log /var/log/*.gz; history -c; sudo shutdown now
   • 关键一步：清理Cloud-Init缓存：sudo cloud-init clean --logs --reboot。这个命令会清空当前实例的cloud-init运行缓存和日志，确保下次从模板克隆出来的新虚拟机能重新运行cloud-init，从而应用新的主机名、IP等配置。这是模板能否成功复用的核心。

3. 关机并转换为模板：在完成所有清理和优化后，在深信服HCI管理界面，将这台名为template-ubuntu2204-base的虚拟机关机。然后，在虚拟机右键菜单或操作列表中，找到“转换为模板”的选项，点击确认。至此，一个干净的、可复用的Ubuntu 22.04 LTS虚拟机模板就创建好了。

4. 配置自定义规范与批量部署

有了模板，批量部署就变成了一个简单快速的克隆过程。但如何让每台克隆出来的虚拟机拥有不同的主机名、IP地址呢？这就需要用到“自定义规范”或“用户数据”功能。

4.1 理解深信服的初始化配置

在深信服HCI中，这个功能可能被称为“初始化脚本”、“自定义数据”或直接集成在创建虚拟机的向导里。其本质是让你在创建或克隆虚拟机时，注入一段符合Cloud-Init标准的配置数据（通常是YAML格式的user-data）。

一个典型的、用于配置静态IP和主机名的user-data示例如下：

#cloud-config hostname: ubuntu-dev-01 fqdn: ubuntu-dev-01.example.com manage_etc_hosts: true users: - name: ubuntu ssh-authorized-keys: - ssh-rsa AAAAB3NzaC1yc2E...（你的公钥） sudo: ['ALL=(ALL) NOPASSWD:ALL'] shell: /bin/bash - name: admin passwd: $6$rounds=4096$salt$encrypted_password_hash（使用mkpasswd生成） sudo: ['ALL=(ALL) NOPASSWD:ALL'] groups: sudo shell: /bin/bash # 配置网络（静态IP示例） write_files: - path: /etc/netplan/99-cloud-init.yaml content: | network: version: 2 ethernets: ens192: # 网卡名，请根据实际情况修改，通常为ens160, ens192, eth0等 addresses: - 192.168.1.101/24 gateway4: 192.168.1.1 nameservers: addresses: [8.8.8.8, 114.114.114.114] permissions: '0644' # 最后执行一次网络应用 runcmd: - [netplan, apply]

实操心得：网卡名称（如ens192）是最大的变数，它取决于虚拟化平台的虚拟硬件类型。在深信服HCI上，你可能需要先通过模板启动一台虚拟机，登录后使用ip a命令查看实际的网卡名称，然后据此修改user-data。使用match规则（如match: {name: ens*})可以增加适配性，但静态配置更稳妥。

4.2 执行批量克隆部署

现在，进入最激动人心的批量部署环节。

1. 基于模板创建：在HCI管理界面，选择“从模板创建虚拟机”。
2. 设置规格：为新的虚拟机命名（如ubuntu-dev-01,ubuntu-dev-02），并可以调整CPU、内存、磁盘大小（通常只能增加，不能减少）。
3. 注入自定义数据：在创建向导的“高级设置”或“初始化配置”部分，找到粘贴user-data的地方。将你为这台虚拟机量身定制的YAML配置粘贴进去。每台虚拟机的hostname和addresses字段必须是唯一的。
4. 完成创建：提交后，平台会从模板快速克隆出一个新的虚拟磁盘，并挂载启动。虚拟机首次启动时，cloud-init会检测到注入的user-data，并自动执行主机名设置、用户创建、网络配置等操作。你只需要等待几分钟，就可以直接用配置的IP地址SSH登录了。

对于批量部署，你可以通过两种方式提高效率：

• 方式一：API调用：如果部署数量巨大（几十上百台），建议研究深信服HCI提供的API，编写脚本循环调用，动态生成并注入不同的user-data。
• 方式二：克隆后修改：先克隆出一台配置好的虚拟机，然后将其关机，再使用平台的“克隆”功能，快速复制出多台。但这种方式需要额外步骤来修改每台新虚拟机的IP和主机名（可通过启动脚本或后续管理工具完成）。

5. 部署后的优化与配置

虚拟机启动并成功接入网络后，工作只完成了一半。以下是一些必要的后续优化配置，能让系统更安全、更好用。

5.1 系统安全与访问加固

1. 禁用默认用户密码登录：Cloud Image的默认ubuntu用户通常允许密码登录。为了提高安全性，建议在user-data中预先注入SSH公钥，并在系统启动后，修改SSH配置禁用密码登录：sudo vim /etc/ssh/sshd_config，设置PasswordAuthentication no，然后重启SSH服务。
2. 配置防火墙：Ubuntu默认使用ufw。启用并配置它，只开放必要的端口（如SSH的22端口，以及你的应用端口）：sudo ufw allow 22/tcp && sudo ufw enable。
3. 配置时区与NTP：确保时间同步，这对于日志分析和分布式应用至关重要。可以使用sudo timedatectl set-timezone Asia/Shanghai和sudo systemctl enable --now systemd-timesyncd。

5.2 存储与性能调优

1. 磁盘扩容处理：如果你在克隆时增加了系统盘大小，Ubuntu系统可能不会自动识别新增的空间。你需要使用growpart和resize2fs（对于ext4）工具来扩展分区和文件系统。这部分操作也可以写入cloud-init的runcmd阶段自动完成。
2. 虚拟硬件驱动：检查是否安装了最优的虚拟硬件驱动。对于磁盘和网络IO，可以尝试在深信服HCI模板设置中，选择性能更佳的虚拟设备型号（如VirtIO SCSI控制器和VirtIO网卡）。Ubuntu Cloud Image通常已包含VirtIO驱动。

5.3 集成平台监控与管理

为了让虚拟机更好地被深信服平台管理，可以考虑：

1. 安装监控代理：如果深信服HCI平台提供了官方的性能监控代理，建议安装在虚拟机内，以便在平台界面上集中查看CPU、内存、磁盘IO等详细指标。
2. 标签与分类：在HCI平台上为这些Ubuntu虚拟机打上统一的标签（如env:dev,os:ubuntu2204），便于后续进行资源分组、权限管理和成本核算。

6. 常见问题与故障排查实录

在实际操作中，我遇到了不少问题，这里把典型问题和解决方案记录下来。

6.1 Cloud-Init 未执行或执行失败

• 现象：虚拟机启动后，主机名还是模板的旧主机名，IP地址是DHCP获取的或者没有IP，自定义用户未创建。
• 排查思路：
  1. 检查日志：登录虚拟机（通过平台VNC），查看Cloud-Init日志：sudo cat /var/log/cloud-init.log和sudo cat /var/log/cloud-init-output.log。这里会有详细的执行过程记录和错误信息。
  2. 检查数据源：运行sudo cloud-init query ds查看Cloud-Init识别到的数据源是什么。在深信服HCI中，它应该识别到类似NoCloud或ConfigDrive的数据源。
  3. 检查user-data是否注入：运行sudo cloud-init query userdata，看是否能打印出你注入的配置。如果为空，说明平台未成功注入数据。
  4. 验证user-data语法：YAML格式非常严格，缩进错误、冒号后面缺空格都会导致解析失败。可以使用在线YAML校验工具检查你的配置。
• 解决方案：确保模板制作时执行了cloud-init clean；检查深信服平台上的自定义数据配置是否正确粘贴（无多余字符）；根据日志错误修正user-data语法；确认平台版本是否支持你所用的Cloud-Init配置指令。

6.2 网络配置不生效

• 现象：user-data中配置的静态IP没有应用，虚拟机无法通过指定IP访问。
• 排查思路：
  1. 检查网卡名：这是最常见的问题。使用ip a或ls /sys/class/net查看虚拟机内实际的网卡名称，务必与user-data中netplan配置下的网卡名保持一致。
  2. 检查Netplan配置：查看生成的配置文件/etc/netplan/99-cloud-init.yaml内容是否正确。
  3. 手动应用测试：可以尝试sudo netplan --debug apply，查看详细的配置应用过程和报错。
• 解决方案：修正user-data中的网卡名称；或者在user-data中使用match规则进行模糊匹配；确保网关和DNS地址可达。

6.3 从模板克隆的虚拟机启动慢

• 现象：克隆出的虚拟机第一次启动花费了很长时间（超过5分钟）。
• 排查思路：这通常是因为磁盘的“精简置备”模式。首次启动时，系统需要写入大量数据，而精简盘需要动态分配物理存储空间，可能导致IO等待。
• 解决方案：对于性能要求较高的生产环境，可以在创建模板或克隆时，为系统盘选择“厚置备”模式。虽然会一次性占用全部存储空间，但能保证最佳的初始启动和运行时IO性能。这是一种典型的“空间换时间”的取舍。

6.4 SSH公钥注入失败

• 现象：配置了ssh-authorized-keys，但无法用对应的私钥登录。
• 排查思路：检查/home/ubuntu/.ssh/authorized_keys文件是否存在，权限是否正确（应为600），以及内容是否是你的公钥。
• 解决方案：确保user-data中ssh-authorized-keys的格式正确，每行一个密钥，且是完整的公钥字符串（以ssh-rsa AAA...或ecdsa-sha2-nistp256 AAA...开头）。也可以尝试在runcmd阶段手动追加公钥到文件作为备用方案。

通过这套从准备、模板制作、批量部署到后期优化的完整流程，我们就能在深信服超融合平台上，建立起一套高效、标准化、可管理的Ubuntu 22.04 LTS虚拟机集群。整个过程的核心在于理解Cloud-Init与平台自定义数据的配合，以及做好模板的通用化处理。一旦模板和配置规范确立下来，后续的扩容和维护工作就会变得非常轻松。