vSAN其实很简单-如何榨干vSAN的最后的空间- Part2（转）

https://mp.weixin.qq.com/s/zFuxJeI0TuX3AM5TSrfEmA

 

上一篇文章我们聊了如何开启vSAN UNMAP功能用来回收释放的空间，这次我们继续来聊聊剩下两个节省空间的方法。

 

• 调整vSAN中的vswap文件属性

• 调整存储策略

 

之前文档连接：

vSAN其实很简单-如何榨干vSAN的最后的空间- Part1

 

 

首先还是强调：

vSAN建议保留30%的剩余空间

vSAN建议保留30%的剩余空间

vSAN建议保留30%的剩余空间

 

这样既可以不超过80%的被动平衡的阈值，也可以确保在某个节点发生问题时，有足够的空间可以重建数据。

 

调整vSAN中的vswap文件属性

=========================

首先我们需要明确下swap文件（交换文件）的作用：

swap文件是VM在开机时候创建一个和VM内存一样的文件，用来在主机内存资源紧张时存储VM的内存里的信息。按照ESXi的设计，这个交换文件是内存优化的所有方法中的最后的选择:

 

• Transparent page sharing

• Memory ballooning

• Memory compression

• Swap to host cache

• Regular swapping  <---------

   

换句话说，这个方法是最后的保底线，当然也是性能最差的。相当于一个汽车上的备胎。如果你要问使用swap文件的性能如何？你会考虑汽车的备胎性能么？

 

    vSAN环境使用默认存储策略的情况下，VM在开机时候会创建一个FTT=1并且是thick模式的swap文件（vswap对象），例如一个虚拟机的内存是10G，则开机时就会创建一个使用空间为20G的对象，而且是thick模式的！

有没有觉得很浪费空间？如果客户环境中有100台这样的VM，每台10G内存，那么只要这些VM开机就会有2T的空间作为swap文件使用（100台*10G*2）

    因此在vSAN6.7以后，我们可以调整vSAN的配置确保VM开启时候创建的swap文件是thin模式的。方法如下：

1.在所有主机上执行下面命令：

esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled

2.重启VM

重启后，VM创建的VM就变成了thin模式

想一想有些需要超大内存的虚拟机，例如256G内存，这下子一台就可以节省512G的空间还有点小激动呢。

 

调整存储策略

===========================

    之所以最后说这个，是因为这个选项是优先级最低的。调整虚拟机的存储策略从FTT1为0，意味着任何主机/磁盘离线都可能会影响到现在运行的VM。但是在一些场合，尤其是急需要释放vSAN空间的情况下我们是可以把这个选项纳入考虑范围的。当然，前提是当前VM的双副本都是健康的状态。

    除此以外，有一些所谓的“技巧”可以分享，例如把系统盘和数据盘分开，如Windows下C盘安装系统，D盘用来存放数据。如果在极端场景下需要调整虚拟机的存储策略，那么可以把C盘调整为FTT0，D盘保留原来的存储策略。之所以可以这么灵活的调整，得益于在vSAN中存储策略可以应用到的最小单元并不是虚拟机，而且更加小的单元：虚拟机磁盘。因此我们也有了更多的选择进行调整。

 

以上是的可以节省vSAN空间的三个方法，希望可以作为参考。

 

 

关于Linux下如何验证磁盘回收的功能

===============

上一篇文章有人咨询我如何在Linux下验证磁盘回收的功能，下面是具体过程：

1. 创建了一个CentOS8的VM，开机后占用磁盘空间为18GB

2. 当前home目录使用率只有1%

文件系统类型是xfs

 

3. 我们在/home目录里创建创建一个20GB的空文件

dd if=/dev/zero of=20G.dd bs=1M count=20000

4. 创建完成后，home目录使用率为46%

5. vCenter中看到VM占用的空间从18G增加到58G（20GB*2）

6. 虚拟机界面中可以看到相同的使用量

7. 检查VMDK对象的的状态，每个副本使用量为23.9GB

8. 在CentOS里删除刚刚创建的大文件，home目录使用率降回1%

9. 如果不回收空间的话，vCenter中这个VM占用的空间依旧为57.9G

10. 在CentOS中执行下面命令

sudo fstrim /home

11. 此时VM的磁盘使用量就将会到18G

12. 每个副本的磁盘使用量降为4.2G

13. 这个VM运行在211上，因此在性能监控VM里，可以看到当时VM有UNMAP IO

 

14. 由于这两个副本分别在主机211和213上，因此我们可以在这两台主机的后端看到当时有大量的UNMAP IO产生。

 

 

至此，验证过程结束。

 

画外音

===========================

    最近在处理一个Basic级别的SR，客户传统存储异常断电导致VMFS文件损坏。经过研发部门的确认，受损的文件系统无法修复，于是客户就抓狂了并且态度十分不友好。客户的心情我们能理解，但是其实还有有些事情需要再说下：

 

1. 重要的虚拟机请备份！说了好半天业务多么重要，“自己从业十多年没遇到类似的事情”。为什么这么重要的VM没有备份？从业这么多年难道都不备份么？

2. 请购买合适级别的服务。当前的BASIC级别的服务的场景是测试、开发场景，响应时间为5*12。如果我们把应该投入到高级别的服务的精力放在低级别的故障上，那是对购买高级服务的用户的不尊重。

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/services/support/vmware-basic-support-datasheet.pdf

3. 除了BCS/MCS服务以外，VMware不提供故障分析原因，这和技术能力无关。

4.不要张口闭口就是"我觉得设计原理应该是...，你们设计的产品有问题..."，产品设计和开发不是用户和售后部门可以决定的。

 

好了 吐槽完毕

 

参考文档：

• https://blogs.vmware.com/virtualblocks/2018/07/18/swap-object-thin-provisioning-in-vsan-6-7/

• https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-C228168F-6807-4C2A-9D74-E584CAF49A2A.html