vSAN 6.0设计与规模设定――vSAN设计概览

  写在前面:《vSAN 6.0设计与规模设定》系列文章是本人学习vSAN的一个学习记录，该系列文章参照VMware白皮书《VSAN_Design_and_Sizing_Guide》，仅供大家学习交流，欢迎各位提出质疑互相讨论！

  设计设计，说的就是能够对从一个整体的角度去思考，却又能抓住其中的细节，做到粗中有细，细中现粗，因此我认为在任何的设计面前，开始时的一个大方向不能有错误。一样的，在进入vSAN的一些细节上的设计时，首先有几个大方面需要先行考虑。

一、严格遵守VMware兼容性列表（VCG）

  虽然VMware官方称任何x86服务器都能够用于vSAN，但实际中并非如此，只有保证你的硬件符合官方的兼容性要求，才能让vSAN在实际业务中提供最高的稳定性和性能。VCG中包含了推荐的或者已经过测试的硬件、驱动版本、firmware。因而在实际项目中建议使用VCG列表中的硬件型号（服务器、存储控制器、闪存设备、磁盘等等），当然如果条件允许，可以直接使用Ready Node作为vSAN节点。除了硬件型号意外，硬件环境对应的firmware和驱动版本也需要注意使用适合版本，保证最终的vSAN群集能够提供最佳性能。

（ps:VCG地址 http://www.vmware.com/resources/compatibility/search.php）

二、使用受支持的vSphere版本

  虽然vSAN支持vSphere 5.5（U1和U2）、vSphere 6.0多个版本，但是推荐使用vSphere最新版本以避免出现一些已知问题（ps:毕竟vSAN是一个刚出不久的技术，VMware本身也在不断改进修改，因而使用最新版本减少vSAN出现问题的可能性）。注意：VMware不支持将vSAN从Beta版本升级到GA版本，如果您当前使用Beta版本，故您只能采用全新部署的方法使用正式版本的vSAN。

三、平衡的主机配置

  作为最佳的部署实践，使用相似的甚至相同的ESXi主机配置（包括存储设备）进行vSAN群集的部署。这可以进一步确保虚拟机组件在整个群集和磁盘中能有一个平衡的分布。当一台没有提供vSAN存储容量的主机运行在vSAN群集当中的时候，有可能会在出现群集出现问题的时候发生其他额外的错误。

四、vSAN群集的生命周期

  vSAN存储的优势之一在于灵活的扩展性。它使得用户能够通过简单的增加vSAN节点的磁盘进行纵向扩展，也可以通过增加群集中的vSAN节点数量进行横向扩展。这样简单的增加主机或者磁盘，便能使得用户能够在不同的时间根据不同的业务需求组件更改vSAN群集的规模。

  在为vSAN群集进行硬件选型的时候，牢记一点：无论是在混合存储架构还是全闪存架构中，增加vSAN群集的存储容量要比在Cache层增加闪存设备容量来得容易。

  当要为vSAN群集扩展容量的时候，只需要简单的插入磁盘或者闪存盘即可。然而当你需要升级Cache层的闪存设备是，就得替换原有的闪存设备，操作更为复杂。如果说容量和闪存设备同时增加，这倒是不难的。但如果只是为了增加Cache层的大小，那就不得不进行更多复杂的工作，迁移更多的数据。因此为了避免这种情况出现，在设计之初就将未来所需的额外增加纳入考虑范围。简言之，Design for growth。

五、考虑容量、维护、可用性

  vSAN群集的最低要求是三台ESXi主机，然后这个最低要求有非常大的限制。在vSAN群集中，当出现设备或者节点故障时，vSAN会尝试在群集中重建故障设备或者几点上的虚拟机组件。在一个3节点的vSAN群集中，如果一个节点故障，群集将无法进行重建过程。同样的，如果一台主机需要进入维护模式，也无法使用迁出所有该主机上所有数据的选项使主机进入维护模式。这些都只有当群集中有4台或以上的ESXi主机数量，并且有足够的剩余空间时才能够实现。

  另一个需要考虑的问题就是vSAN群集的Capacity层。在vSAN中虚机的存放是通过存储策略驱动的，其中的一项策略参数就是FTT(NumberOfFailuresToTolerate)，该参数定义了虚机存放的副本数量。因此进行vSAN群集设计时需要考虑该值的设定对容量大小的影响。这个参数的具体将在后续文章中介绍。

  至此，五个需要考虑的大方面已经说明完毕，接下来就是进入更为详细的考量阶段了。