一、为什么我们得学会调整集群的“胖瘦”

想象一下，你家里的储物柜一开始只放几件衣服，后来越买越多，柜子塞不下了，你就得再买一个柜子；反过来，如果好多衣服送人了，柜子空着占地方，你可能会想把它腾出来。vSphere集群的扩容和缩容，本质上就是这么回事。企业里的虚拟化环境，业务在变，服务器负载在变，集群里的物理主机数量也得跟着调整。扩容就是往集群里加ESXi主机，让更多虚拟机有地方跑；缩容就是移除一些主机，减少电费和维护压力。很多人觉得这事儿就是点几下鼠标，但真正在企业生产环境里，牵一发动全身，搞不好虚拟机就掉线了，业务直接中断。所以咱们得有一套规范的流程，还得知道风险在哪里。

二、动手之前，先摸清家底

2.1 搞明白当前集群的资源状况

别一上来就加机器，先看看现在的集群到底缺什么。用vSphere Client打开集群的总览页面，关注CPU、内存、存储的使用率。如果CPU长时间超过80%，而内存才用了一半，那加主机主要是为了扩CPU；反过来也一样。另外还要注意每台主机的剩余可用资源，因为虚拟机迁移时需要目标主机有足够余量。

2.2 选好趁手的工具：PowerCLI

虽然网页界面也能操作，但批量操作、脚本化执行会快得多，而且容易记录。我的建议是用PowerCLI，它是VMware官方提供的PowerShell模块，管集群特别好使。下面所有示例都基于PowerCLI这个技术栈。

# 先安装PowerCLI模块（如果还没有装）
Install-Module -Name VMware.PowerCLI -Force

# 连接vCenter，请把地址、用户名、密码换成你自己的
Connect-VIServer -Server vcenter.example.com -User administrator@vsphere.local -Password 'P@ssw0rd!'

# 查看集群里的主机和资源使用情况
Get-Cluster -Name "生产集群" | Get-VMHost | Format-Table Name, State, @{N='CPU(GHz)';E={$_.CpuTotalMhz/1000}}, @{N='内存(GB)';E={[math]::Round($_.MemoryTotalGB,2)}} -AutoSize

这段代码先连上vCenter，然后找出“生产集群”里的所有主机，显示每台主机的名字、状态、CPU总频率和内存总量。执行之后你就能清楚知道自己有几台机器，每台多大能力。

三、扩容实操：给仓库加个新货架

假设我们现在决定加一台ESXi主机到集群里。规范化流程分三步：第一步先把主机装好系统，第二步加入集群，第三步验证资源是否被正确管理。

3.1 把新主机“拉”进集群

新主机的ESXi系统装好后，用PowerCLI把它加进集群是最方便的。注意，加之前要确认新主机的IP地址能跟vCenter互通，账号密码正确。

# 新主机的IP和管理账号
$esxiHost = "192.168.10.50"
$esxiUser = "root"
$esxiPass = "Esxi@2024"

# 添加到目标集群
Add-VMHost -Name $esxiHost -User $esxiUser -Password $esxiPass -Location (Get-Cluster -Name "生产集群")

# 加进来之后，马上看看主机是否处于维护模式
Get-VMHost -Name $esxiHost | Select-Object Name, ConnectionState, State

运行后，新主机通常会处于“已连接”但还没被正常接管的状态。这里要特别提醒：如果集群启用了EVC（增强的vMotion兼容性），新主机的CPU型号不能太旧，否则加不进去。EVC就像规定“这个仓库里所有货架都必须能放同一规格的箱子”，老架子可能放不下新箱子。

3.2 给新主机配置网络和存储

新主机加入集群后，还得保证它跟其他主机跑在同一个二层网络里，能看到相同的共享存储。否则虚拟机迁上去就没网络、没磁盘了。用PowerCLI可以批量检查并配置。

# 假设新主机要用的vSwitch端口组是"VM网络"，物理网卡是vmnic0和vmnic1
New-VirtualSwitch -VMHost $esxiHost -Name "vSwitch0" -Nic "vmnic0","vmnic1"

# 创建一个端口组，关联到虚拟交换机
New-VirtualPortGroup -VMHost $esxiHost -Name "VM网络" -VirtualSwitch "vSwitch0"

# 查看新主机是否能看见所有共享数据存储
Get-VMHost -Name $esxiHost | Get-Datastore | Format-Table Name, FreeSpaceGB, CapacityGB

如果共享存储没显示出来，多半是FC SAN或者iSCSI没配置好。走iSCSI的可以再用PowerCLI添加动态发现地址：

# 配置iSCSI软件适配器
Get-VMHostStorage -VMHost $esxiHost -RescanAllHba | Out-Null
New-IScsiHbaTarget -VMHost $esxiHost -Type Virtual -ErrorAction SilentlyContinue
Get-VMHostStorage -VMHost $esxiHost -RescanAllHba | Out-Null

注意，这里只是示例，真实环境配置网络和存储要根据你的架构来，但原则很简单：新主机必须和已有主机拥有相同的网络和存储“视野”。

四、缩容实操：让老货架体面退场

缩容比扩容更敏感，因为你得把满载的货物搬到别的架子上，还得保证搬的过程中货物不掉地。在虚拟化里，这就是虚拟机迁移（vMotion）。缩容的规范流程是：先迁移虚拟机，再检查残留，最后把主机置于维护模式并移除。

4.1 把虚拟机全部迁走

当我们要将一台主机变成维护模式时，vCenter会自动把上面的虚拟机迁到其他主机，但前提是集群里有足够资源，而且虚拟机是共享存储，网络也通。用PowerCLI可以手动控制这个过程。

# 假设要缩容的主机叫esxi-node-03
$vmhost = Get-VMHost -Name "esxi-node-03"

# 让vCenter自动把主机上的虚拟机迁移到其他可用主机
Set-VMHost -VMHost $vmhost -State Maintenance -Evacuate

# 查看主机状态，确认已是维护模式
Get-VMHost -Name "esxi-node-03" | Select-Object Name, State

执行Set-VMHost -State Maintenance -Evacuate后，vCenter会依次迁移每一台虚拟机。如果某些虚拟机因为设置了苛刻的“非关联性规则”导致无法自动迁移，迁移过程会卡住，这时需要人工介入。

4.2 处理迁移不掉的“钉子户”

有时候某台虚拟机绑定了特定主机（比如用到了直通硬件），或者DRS规则不允许它跑到别的机器上。这时得先取消绑定，再手动迁移。

# 找到这台主机上所有虚拟机
$vms = Get-VMHost -Name "esxi-node-03" | Get-VM

foreach ($vm in $vms) {
    # 尝试迁移到另一台主机，如果失败就打印提示
    try {
        Move-VM -VM $vm -Destination (Get-VMHost -Name "esxi-node-01") -ErrorAction Stop
    }
    catch {
        Write-Host "虚拟机 $($vm.Name) 迁移失败: $($_.Exception.Message)"
    }
}

迁移完成后，还要确认主机上没有虚拟机、没有挂载的ISO镜像、没有活动的快照等。再用Get-VMHost -State Maintenance检查状态。

4.3 把主机从集群里拿掉

确认主机处于维护模式后，最后一步是移除。这一步很快，但做了之后，这台主机就和集群没关系了。

# 从vCenter中移除主机（注意：不会删除ESXi系统本身）
Remove-VMHost -VMHost (Get-VMHost -Name "esxi-host-04") -Confirm:$false

这里有个“隐藏”风险：如果主机是被集群里的vCenter管着的，移除之后DRS就不会再调度这台机器了，但主机上的虚拟化服务还在。如果还想让这台主机独立运行，可以关掉它的ESXi管理网络重新配置，或者直接重装系统。

五、风险控制不能只靠运气

在生产和测试环境里，我都见过因为缩容引发的事故：有人直接强制移除主机，结果上面还跑着虚拟化数据库；也有人扩容时没检查EVC，导致新旧主机混合后，老虚拟机无法开启高版本CPU模式。这些教训告诉我们，风险控制要贯穿整个过程。

第一，执行前必须做“预检”。用PowerCLI检查集群里的剩余CPU和内存，估算迁移后每个虚拟机是否都能得到足够资源。下面这个脚本能帮你看迁移后的资源压力。

# 获取集群资源情况，去掉要维护的主机，看剩余可用
$cluster = Get-Cluster -Name "生产集群"
$totalCpu = ($cluster | Get-VMHost | Where-Object {$_.State -ne "Maintenance"} | Measure-Object -Property CpuTotalMhz -Sum).Sum
$usedCpu = ($cluster | Get-VMHost | Where-Object {$_.State -ne "Maintenance"} | Measure-Object -Property CpuUsageMhz -Sum).Sum
$totalMem = ($cluster | Get-VMHost | Where-Object {$_.State -ne "Maintenance"} | Measure-Object -Property MemoryTotalGB -Sum).Sum
$usedMem = ($cluster | Get-VMHost | Where-Object {$_.State -ne "Maintenance"} | Measure-Object -Property MemoryUsageGB -Sum).Sum

Write-Host "剩余可用CPU: $([math]::Round(($totalCpu-$usedCpu)/1000,2)) GHz"
Write-Host "剩余可用内存: $([math]::Round($totalMem-$usedMem,2)) GB"

这个脚本能告诉你，在把某台主机下线后，集群还剩多少资源。如果剩余资源不足，就别继续，先加机器或者删掉不用的虚拟机。

第二，操作时要“分批”。缩容时不要一下把三台主机同时置于维护模式，而是逐台做，每完成一台都观察一下虚拟机运行状态，看看有没有蓝屏、性能告警。扩容时也别同时加很多台，加一台等集群DRS重新平衡后再加下一台。

第三，回滚方案必须有。扩容前保留好原集群的配置备份，缩容前记录好被移除主机的网络IP和存储挂载信息。一旦出问题，至少能按原来的样子恢复。用PowerCLI导出配置是个好习惯。

# 导出集群配置信息到本地文件
Get-Cluster -Name "生产集群" | Export-Clixml -Path "D:\backup\cluster-config.xml"

一旦集群配置被误改，可以用Import-Clixml导回来重新应用。

六、应用场景和优缺点分析

扩容最典型的场景是什么？当企业上了新业务，或者到了业务高峰期（比如电商大促、年底结算），CPU和内存容易爆。这时候加主机见效最快，比一台台加虚拟机配置省事得多。缩容则是当业务收缩、长期空转的服务器越来越多时，把多余主机撤下来，省电、省机房散热、省软件授权费。

但扩容和缩容并不是万灵药。扩容的优点是灵活，风险相对低，只要资源足够，新主机几分钟就能加入集群并提供服务。缺点是如果集群本身设计得不好，比如共享存储带宽不够，加再多主机也是白搭，性能瓶颈可能转移到存储或网络。另外，某些老版本vSphere对集群最大主机数有限制，超了之后就得重新设计架构。

缩容的优点是节省成本，让闲置资源“复活”到其他平台。缺点也很明显：操作风险高，一旦迁移虚拟机时网络抖动或存储故障，可能导致业务中断。而且缩容不是一锤子买卖，如果过两个月业务又涨回来，你还得再扩容，来回折腾可能比一直留着机器更麻烦。

所以，什么时候该扩容？当集群整体负载长时间超过70%，而且预测后续会继续增长，这时加主机是合理的。什么时候该缩容？当集群负载连续一两个月低于20%，并且没有周期性波峰，就可以考虑缩掉一两台。要避免“看一天数据就做决定”的冲动，建议用vRealize Operations或者简单点，自己写脚本收集一周的CPU和内存走势。

七、总结

vSphere集群扩容缩容，说到底是让基础设施跟着业务走，不要“明明吃不饱还拼命摆盘子”，也别“客人坐满了还在锁门”。把流程标准化：先评估现状，再用PowerCLI批量操作，操作前做资源预检，操作中逐台执行，操作后验证状态。同时，把风险控制的重心放在“迁移”这个环节，因为无论是加主机还是减主机，本质都是让虚拟机在集群内部流动。只要网络、存储、CPU兼容性都考虑周全，流动就是安全的。

希望这篇文章能帮你少踩一些坑。企业环境没有“随便点点”这回事，尤其是集群这种承载着所有虚拟机的底盘，动它之前，多花十分钟做检查和备份，远比出了事故再花十小时修复划算。最后，把文中的命令收集起来，改改IP和名字，就能直接用在你的环境里了。