写在前面:《vSAN 6.0设计与规模设定》系列文章是本人学习vSAN的一个学习记录,该系列文章参照VMware白皮书《VSAN_Design_and_Sizing_Guide》,仅供你们学习交流,欢迎各位提出质疑互相讨论!php
设计设计,说的就是可以对从一个总体的角度去思考,却又能抓住其中的细节,作到粗中有细,细中现粗,所以我认为在任何的设计面前,开始时的一个大方向不能有错误。同样的,在进入vSAN的一些细节上的设计时,首先有几个大方面须要先行考虑。
服务器
1、严格遵照VMware兼容性列表(VCG)架构
虽然VMware官方称任何x86服务器都可以用于vSAN,但实际中并不是如此,只有保证你的硬件符合官方的兼容性要求,才能让vSAN在实际业务中提供最高的稳定性和性能。VCG中包含了推荐的或者已通过测试的硬件、驱动版本、firmware。于是在实际项目中建议使用VCG列表中的硬件型号(服务器、存储控制器、闪存设备、磁盘等等),固然若是条件容许,能够直接使用Ready Node做为vSAN节点。除了硬件型号意外,硬件环境对应的firmware和驱动版本也须要注意使用适合版本,保证最终的vSAN群集可以提供最佳性能。
ide
(ps:VCG地址 http://www.vmware.com/resources/compatibility/search.php)性能
2、使用受支持的vSphere版本
学习
虽然vSAN支持vSphere 5.5(U1和U2)、vSphere 6.0多个版本,可是推荐使用vSphere最新版本以免出现一些已知问题(ps:毕竟vSAN是一个刚出不久的技术,VMware自己也在不断改进修改,于是使用最新版本减小vSAN出现问题的可能性)。注意:VMware不支持将vSAN从Beta版本升级到GA版本,若是您当前使用Beta版本,故您只能采用全新部署的方法使用正式版本的vSAN。测试
3、平衡的主机配置
ui
做为最佳的部署实践,使用类似的甚至相同的ESXi主机配置(包括存储设备)进行vSAN群集的部署。这能够进一步确保虚拟机组件在整个群集和磁盘中能有一个平衡的分布。当一台没有提供vSAN存储容量的主机运行在vSAN群集当中的时候,有可能会在出现群集出现问题的时候发生其余额外的错误。spa
4、vSAN群集的生命周期设计
vSAN存储的优点之一在于灵活的扩展性。它使得用户可以经过简单的增长vSAN节点的磁盘进行纵向扩展,也能够经过增长群集中的vSAN节点数量进行横向扩展。这样简单的增长主机或者磁盘,便能使得用户可以在不一样的时间根据不一样的业务需求组件更改vSAN群集的规模。
在为vSAN群集进行硬件选型的时候,牢记一点:不管是在混合存储架构仍是全闪存架构中,增长vSAN群集的存储容量要比在Cache层增长闪存设备容量来得容易。
当要为vSAN群集扩展容量的时候,只须要简单的插入磁盘或者闪存盘便可。然而当你须要升级Cache层的闪存设备是,就得替换原有的闪存设备,操做更为复杂。若是说容量和闪存设备同时增长,这却是不难的。但若是只是为了增长Cache层的大小,那就不得不进行更多复杂的工做,迁移更多的数据。所以为了不这种状况出现,在设计之初就将将来所需的额外增长归入考虑范围。简言之,Design for growth。
5、考虑容量、维护、可用性
vSAN群集的最低要求是三台ESXi主机,而后这个最低要求有很是大的限制。在vSAN群集中,当出现设备或者节点故障时,vSAN会尝试在群集中重建故障设备或者几点上的虚拟机组件。在一个3节点的vSAN群集中,若是一个节点故障,群集将没法进行重建过程。一样的,若是一台主机须要进入维护模式,也没法使用迁出全部该主机上全部数据的选项使主机进入维护模式。这些都只有当群集中有4台或以上的ESXi主机数量,而且有足够的剩余空间时才可以实现。
另外一个须要考虑的问题就是vSAN群集的Capacity层。在vSAN中虚机的存放是经过存储策略驱动的,其中的一项策略参数就是FTT(NumberOfFailuresToTolerate),该参数定义了虚机存放的副本数量。所以进行vSAN群集设计时须要考虑该值的设定对容量大小的影响。这个参数的具体将在后续文章中介绍。
至此,五个须要考虑的大方面已经说明完毕,接下来就是进入更为详细的考量阶段了。