利用 VMware 技术构建超融合平台 第 1 部分

得过且过

　　

　　

　　原文：http://www.yellow-bricks.com/2014/01/22/building-hyper-converged-platform-using-vmware-technology/
　　注明：本文内容基于 VMware VSAN beta 版本撰写，请访问http://www.vmware.com/products/virtual-san/获得有关正式版本的更新信息。
　　

　　

　　      我最近正在制作一组幻灯片，用于介绍如何使用 VMware 技术构建超融合平台。当然，这组幻灯片重点介绍 Virtual SAN，因为这是堆栈中的核心产品之一。这组幻灯片的制作素材主要来源于我与不同客户和合作伙伴的讨论，他们正努力为自己的数据中心构建一个平台，而且这一平台可以轻松地进行复用。这一平台看起来会很美观，可以进行横向和纵向扩展。不仅可以在完整数据中心内使用，还可以在小型 SMB 环境或 ROBO 部署中使用。
　　

　　       我想有必要在开始时阐述一下我对超融合的理解，虽然不久之前我已就此主题撰写了多篇文章。我要说的是这些观点仅仅是“我”个人的理解，因为我知道很多人可能会对此持不同观点。超融合平台是一种设备型解决方案，其中，一个机箱为多个虚拟机提供平台。该机箱通常会容纳多台安装了虚拟化管理程序的通用 x86 主机（尽量避免使用“商用”一词），并具有聚合到大型共享池的本地存储以及网络端口。请注意，机箱本身一般并不具有网络交换功能，但虚拟交换机除外。要将存储聚合到大型共享池中，需要借助另外一款软件。目前市场上典型的超融合平台有 Nutanix、SimpliVity 和 Pivot。
　　

　　       我们不禁要问，如果仅仅采用安装了虚拟化管理程序的 x86 机箱以及存储软件，那么，在常规环境下又有哪些优点呢？我认为具有以下优点：

• 　　产品上市速度快，安装/部署时间少于 4 个小时（大多数情形下，可能比这个速度更快）
  
• 　　易于管理和集成
  
• 　　可在容量和性能方面进行横向扩展
  
• 　　价格一般比较实惠（具体价格可能会有所差异）
  

　　

　　       听起来是一个很不错的产品，对吗？更方便、更实惠、上市速度更快。可以说，对于许多公司，这些都称得上是绝佳的解决方案，因为它们可以为您提供一个一体化的业务组件。也就是说，这种产品采用单个 SKU，大多数情况只提供一个技术支持联系点。一些合作伙伴和客户反馈说，唯一的缺点就是，这些解决方案通常会受到硬件和特定配置的限制，而这些配置与您的首选供应商并不完全一样，或许也并不是您偏好的配置。因此，在对它更新/修补时，可能会造成操作问题，或许操作团队会因此而感到很郁闷。除此之外，还存在一个“信任”问题。有些人非 HP 不用，不愿采用任何其他品牌，而另外一些人完全不理会这一点。我想，这应该属于个人经验和个人风格问题。为此，我们会走向何方呢？依我看来，这正是 Virtual SAN/VSAN 的用武之地。
　　

　　       目前，Virtual SAN/VSAN 已推出 Beta 版，可让您根据自己的要求和预算来挑选自己的硬件供应商和自己的组件并进行大小调整。（提前说明一下，目前 VSAN 的定价和打包方式尚未最终确定。）所以，如果您要以合作伙伴的身份为客户构建超融合的平台，或者以客户的身份为自己构建这种平台，要从何处着手呢？就让我们从可以使用哪些 VMware 产品和功能开始吧！

• 　　ESXi 5.5
  
• 　　vCenter Server 5.5
  
  
  
  • 　　vSphere HA
    
  • 　　vSphere DRS +      vMotion
    
  • 　　VASA + 虚拟机存储策略
    
  • 　　Distributed Switch      + 网络 IO 控制
    
  
  
• 　　Virtual SAN
  

　　
　　
　　     
　　      从软件的角度来看，以上应该是您的堆栈核心，不过您也可以加入其他产品和功能，如 vCenter Orchestrator、VC Ops、vSphere Replication 和 vSphere Data Protection等。不过，我们还是把重点放在核心以及如何构建解决方案上吧。我会假定您已熟悉这些组件，因此不会再对其进行深入介绍。但是，我还是要简单谈谈为什么我觉得这些组件是值得推荐的。vSphere HA 十分简单，在大多数环境中，保持可用性可谓至关重要。使用 vSphere DRS 和 vMotion 可以确保虚拟机能获得所需的资源，并能让我们执行许多操作，如在不中断工作负载的情况下将主机置于维护模式等。借助 Distributed Switch 和网络 IO 控制，我们可以根据分配给数据流量的份额轻松地管理涉及服务质量的虚拟交换解决方案。对于 Virtual SAN 来说，这一点非常重要，因为从网络的角度讲，我们需要确保 VSAN 能够获得所需的资源。如果要将多个本地磁盘资源聚合到一个大型池中，则 VSAN 就是不可或缺的。
　　

　　      但这与硬件有什么关系呢？我在一周前发布了一篇文章，介绍了如何将普通虚拟机磁盘大小扩展到每台主机上的 VSAN 所需的磁盘数目。要查看深入的介绍，我建议阅读这篇文章。让我们随意设想一种情形，了解一下我们的选择。

• 　　每个虚拟机平均 1.5 个 vCPU
  
• 　　每个虚拟机 5 GB 内存
  
• 　　每个虚拟机 50 GB 磁盘
  
• 　　允许的故障数目 = 1
  

　　

　　       我们要运行 100 个虚拟机。这意味着，我们总共需要：

• 　　100 x 1.5 个 vCPU = 30 个核心
  
• 　　500 GB 内存
  
• 　　11.8 TB 磁盘空间
  

　　

　　       我是如何得到上述数字的呢？从 vCPU 的角度来看，我希望每个核心最多 5 个 vCPU。即，我会将 150 除以 5，结果为最少 30 个核心。从内存的角度来看，使用 500 GB 最为简单，为了计算简便，我不会考虑 TPS。还有 11.8 TB 的磁盘容量要求。我是如何得到这一数字的呢？我在关于规模调整的博文中提供了一个公式：
　　(((虚拟机数* 平均虚拟机大小)+ (虚拟机数* 平均内存大小))* FTT+1) + 10%
　　

　　       此处，结果应为：(((100 * 50) + (100 *5)) * 2) = (5000 + 500) * 2 = 12100 GB + 10% / 1024 = 11.8 TB
　　     （我使用了这个 VSAN 数据存储计算器）
　　

　　       现在，我们了解了大概需要多少容量，那么，如何将各个部分联系在一起呢？我会在本系列博客的第 2 部分进行讨论！
　　

　　呼朋引伴，欢迎分享！
　　


————————————————————————————————————————————




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