Virtual SAN 和维护时间段

原文：http://www.yellow-bricks.com/2013/11/25/virtual-san-maintenance-windows/

注明：本文内容基于 VMware VSAN beta 版本撰写，请访问http://www.vmware.com/products/virtual-san/获得有关正式版本的更新信息。

       写完“VSAN 所需的最低主机数为 4”这篇文章后，很多人通过电子邮件和 Twitter 等渠道向我提出大量问题，这些问题主要是关于这样做的成本如何以及是否有必要这样做的。首先我要说明的是，我写这篇文章的目的主要是为了让人们去思考如何调整 VSAN 环境规模。因此，关于 Virtual SAN 和维护时间段的主题或许颇有难度。

       我想，这里需要考虑一系列问题。即使在您要执行滚动升级的常规存储环境中，如果您有两个控制器，一个要升级，另一个要处理 IO。您也仍然会面临风险。问题是，作为虚拟化管理员，您可以比较灵活地进行管理，并希望某些功能可以像 vSphere HA 一样正常工作。您需要思考的是：我愿意承担多大的风险？我能够承担多大的风险？

     如果您要将主机置于维护模式，从 VSAN 的角度说，您需要思考的是：

• 我是否希望将数据从一台主机移动到另一台主机以保持可用性？

• 我是不是只想保持数据可访问性，而承担维护期间可能停机的风险？

     我想针对这两点谈一下。如果要将数据从一个节点移动到另一个节点以保持可用性，则“维护时间段”可能会很长。您可能需要通过网络在主机间复制数 TB 的数据，因此可能需要数小时才能完成。如果您的 ESXi 升级过程连同重新引导主机需要大约 20 分钟，您是否愿意等上几个小时来完成数据迁移呢？或者，您是否会在面临风险的情况下告知用户可能发生停机，然后在更高的风险下进行维护，但只需数分钟而不是数小时即可完成呢？20 分钟后，VSAN 将自动重新同步，所以不会丢失任何数据。

      说实话，在这一点上，我没法给您提出建议，我强烈建议您与存储团队一起进行讨论。了解他们当前的流程、他们的业务 SLA 内容（如果有）以及他们如何处理升级/定期维护事宜。

     呼朋引伴，欢迎分享！

――――――――――――――――――――――――――――――――――――――――――――

作者： Duncan Epping

Duncan Epping 现任 VMware R&D 的 SDDC 新兴解决方案团队首席架构师。他主要负责挖掘现有产品和功能的新机会，并通过对新解决方案或产品进行原型开发来为 VMware 探索新的业务商机。他主要致力于软件定义的存储和业务连续性/灾难恢复解决方案，目前正在申请一项专利。