Horizo​​n 6.0和Virtual SAN:……(VMware)的完美结合

Horizo​​n6 + 虚拟SAN在今天的特别网络广播活动中,VMware正式宣布发布VMware Horizo​​n 6.0。该版本旨在满足当今移动办公人员的需求,并针对软件定义的数据中心架构和出色的操作模型进行了优化。

该公告包含了整个Horizo​​n Suite产品的许多新的重要功能,但是我个人最喜欢的公告之一是对Virtual SAN存储策略的支持。

通过利用Virtual SAN必须提供的所有关键优势,此新版本提供了与Virtual SAN集成的无与伦比的水平:

  • 彻底简单的管理和配置
  • 存储策略库管理框架,
  • 性能,容量和弹性基础
  • 线性可扩展功能(向上或向外扩展)。

通过利用vSphere的新策略驱动的控制平面和基于存储策略的管理框架,Horizo​​n 6.0可以通过根据针对虚拟桌面的存储容量,性能和可用性要求定义的VM存储策略来保证虚拟桌面的性能和服务水平。

Horizo​​n 6.0将针对虚拟桌面的一组VM存储策略自动部署到vCenter Server。这些策略是针对每个磁盘(Virtual SAN对象)自动且单独地应用的,并在虚拟桌面的整个生命周期内得到维护。以下列出了策略及其各自的性能,容量和可用性特征:

  • VM_HOME –每个对象的磁盘带区数为1,允许的故障数为1。这对应于Virtual SAN的默认策略。
  • OS_Disk –每个对象的磁盘带区数1,允许的故障数1。同样,这是默认策略。
  • REPLICA_DISK –每个对象的磁盘带区数为1,允许的故障数为1,闪存读取缓存保留量为10%。此策略将某些SSD或闪存容量专用于副本磁盘,以便为该磁盘将经历的预期读取级别提供更大的缓存。
  • 永久磁碟 –每个对象的磁盘条带数为1,允许的故障数为1,对象空间预留为100%。 此策略可确保保证所有类型的磁盘的所有空间 需要。

以下视频说明了新的Horizo​​n 6.0与Virtual SAN策略的集成:

Horizo​​n 6.0和Virtual SAN的结合使客户能够部署持久性和非持久性虚拟桌面,而无需传统的SAN。

通过将基于服务器的存储的较低成本与共享数据存储的可用性优势相结合,并从基于SSD的性能加速中获得额外收益,Virtual SAN可通过整体实施VDI解决方案节省大量成本。

– Enjoy

有关将来的更新,请确保在Twitter上关注我: @PunchingClouds

的VMware Virtual SAN:见证组件部署逻辑

虚拟SAN我的问题’人们经常问到有关Virtual SAN中见证组件的行为和逻辑。显然,这有点混浊。因此,我想借此机会回答这个问题,并为那些在正式白皮书之前寻求有关该主题的更多细节的人们解答。因此,请注意这一点。

行为与逻辑我’这里要说明的m对最终用户是100%透明的,并且与见证组件的布局无关。此行为由系统管理和控制。这旨在提供您可能会看到的见证组件的数量及其原因的理解。

Virtual SAN对象由在配置了Virtual SAN的vSphere群集中的主机之间分布的组件组成。这些组件存储在Virtual SAN分布式数据存储中的磁盘组的不同组合中。通过基于闪存的设备及其数据为组件透明分配缓存和缓冲能力“at rest”在磁盘上。

见证组件是每个存储对象的一部分。 Virtual SAN Witness组件包含对象元数据,它们的目的是在必须在Virtual SAN群集中做出可用性决定时避免出现裂脑行为并满足法定要求的情况,成为决胜局。

Virtual SAN Witness组件以三种不同的方式定义和部署:

  • 主要证人
  • 次要证人
  • 抢劫者见证

主要证人: 群集中至少需要(2 * FTT)+ 1个节点才能容忍节点/磁盘故障的FTT数量。如果在放置所有数据组件之后,我们在配置中没有所需数量的节点,则主要见证方位于互斥节点上,直到配置中有(2 * FTT)+1个节点。

次要证人: 创建辅助见证人以确保每个节点对仲裁具有相等的投票权。这很重要,因为每个节点故障都应平等地影响仲裁。添加辅助见证人,以便每个节点获得相等数量的组件,这包括仅包含主要见证人的节点。因此,在此步骤中,均衡每个节点上的数据组件+见证的总数。

抢劫者证人: 如果在添加主见证服务器和辅助见证服务器后,最终在配置中获得的组件总数为偶数(数据+见证服务器),那么我们将添加一个决胜局见证服务器以使总组件计数为奇数。

让我将上述定义和逻辑结合到两个现实世界场景中,并解释为什么证人组件按其放置方式放置:

  • 方案1:带有511 GB VMDK的VM容忍失败1

注意: Virtual SAN对象名称空间限制为每个对象255GB。大于255GB的对象在主机之间平均分配。这说明了在以下两个示例中使用带有多个串联RAID 0集的RAID 1集配置说明的行为。

例子1

在此特定方案中仅部署了一个见证人,为什么?

在这种特定情况下,所有RAID 0条带都放置在不同的节点上。仔细看看主机名。

现在为什么以这种方式发生这种情况,这与上述证人类型有何关系?

在这种情况下执行见证计算时,见证组件逻辑将发挥作用,如下所示:

  • 主要证人: 数据分量分布在4个节点上(大于2 * FTT + 1)。因此,我们不需要主要证人。
  • 次要证人: 由于参与配置的每个节点仅具有一个组成部分,因此我们不需要任何辅助见证即可平均投票。
  • 抢劫者证人: 由于配置中的组件总数为4,因此我们只需要一名决胜局见证人。
  • 方案2:具有515 GB VMDK的VM容忍失败1

方案2

在这种情况下,部署了3个见证人,为什么?

在这种特定情况下,某些RAID 0条带放置在同一节点上。仔细看看主机名。组件的配置在以下配置中分层:

  • 节点vsan-host-1.pml.local上的2个组件
  • 节点vsan-host-4.pml.local上的2个组件
  • 节点vsan-host-3.pml.local上的1个组件
  • 节点vsan-host-2.pml.local上的1个组件
在这种情况下执行见证计算时,见证组件逻辑将发挥作用,如下所示:
  • 主要证人: 数据分量分布在4个节点上(大于2 * FTT + 1)。因此,我们不需要主要证人。
  • 次要证人: 由于两个节点各有2票,而2个节点各只有1票,因此我们需要在以下节点上添加一票(见证):
    • vsan-host-3.pml.local
    • vsan-host-2.pml.local
  • 抢劫者证人: 在将以上两个见证人相加后,配置中的总组件数为8(6个数据+ 2个见证人),我们需要一个决胜局见证人,这是第三个见证人。
在大多数情况下,人们希望见证者数量取决于对策略的容忍度(0到3)。见证人的数量完全取决于组件和数据的放置方式,并不是真正由给定的策略确定。
再次,正如我在本文开头所说的那样,此行为对最终用户而言是100%透明的,并且无需担心,因为该行为是由系统管理和控制的。
– Enjoy
有关将来的更新,请确保在Twitter上关注我: @PunchingClouds

的VMware Virtual SAN互操作性:vSphere Replication和vCenter Site Recovery Manager

虚拟SAN + VR + SRM对于Virtual SAN互操作性系列的第三篇文章,我想展示Virtual SAN vSphere Replication和vCenter Site Recovery Manager之间的互操作性。此演示介绍了客户可以将vSphere Replication和vCenter Site Recovery Manager与Virtual SAN结合使用的多种可能方式之一。

在下面的演示中,我对传统SAN基础架构上托管的虚拟机执行了完全自动化的计划迁移,将其无缝迁移到Virtual SAN环境。此示例特别说明了利用具有与Virtual SAN集成功能的现有vSphere工具和技术可以轻松实现这种类型的操作。

考虑将虚拟机迁移到Virtual SAN群集时,此操作非常有用和高效。关于Virtual SAN仅是针对Greenfield环境的解决方案的讨论一直存在,这绝对是不准确的。如下面的视频所示,这是一种可用于将现有虚拟机自动迁移到Virtual SAN的方法,而不会造成数据丢失的风险,并且还可以进行完全编排。

vSphere Replication提供虚拟机复制功能,vCenter Site Recovery Manager提供该过程的编排功能。只能使用vSphere Replication执行该操作,但随后必须手动执行该过程的某些部分。

尽管此演示集中于单个站点内的计划迁移操作,但是相同的示例和功能适用于以下情形:

  • 计划跨站点迁移
  • 灾难恢复

从工具和解决方案的角度来看,“计划迁移”操作与“灾难恢复”操作之间的区别是单击即可,这是在vCenter Site Recovery Manager中确定的。

以下列出了vSphere Replication和vCenter Site Recovery Manager交付给Virtual SAN的一些关键优势:

  • 异步复制– 15分钟的RPO
  • 基于VM的保护
  • 提供自动化的灾难恢复操作& orchestration
  • 自动故障转移–执行用户定义的计划
  • 自动故障回复–反向器原始恢复计划
  • 计划的迁移–确保零数据丢失
  • 时间点恢复–多个恢复点
  • 无中断测试–在隔离的网络上自动化测试

 

– Enjoy

特别感谢Graham Daly 的VMware’的多媒体程序管理器,可以为录音添加动听的声音, @VMken和 @jhuntervmware from the TM 存储 &可用性团队用于验证我的演示记录。

有关将来的更新,请确保在Twitter上关注我: @PunchingClouds

的VMware Virtual SAN互操作性:vCloud 自动化 Center

虚拟SAN-vCAC对于Virtual SAN互操作性系列的第二篇文章,我展示了Virtual SAN与vCloud 自动化 Center之间的互操作性。该演示展示了可使用vCloud 自动化 Center通过服务目录将虚拟机供应到Virtual SAN基础架构的多种方法之一。

在这种情况下,我创建了三个vCloud 自动化 Center蓝图并将其发布到服务目录。私有云中的所有用户均可访问所有蓝图。每个蓝图都是基于虚拟机模板创建的,这些模板配置了在vSphere级别分配的VM存储策略。

VM存储策略是一种vSphere构造,用于存储存储功能,以便将其应用于虚拟机或不同的VMDK。在这种情况下,功能基于Virtual SAN产品的容量,可用性和性能。

在演示中,重点是部署具有最高可用性的虚拟机。虚拟机或VMDK的可用性配置由“允许的故障数”存储功能定义。

服务目录包含3种不同的虚拟机产品,每种产品具有不同的“允许的故障数””定义如下:

  • 默认可用性FTT = 1
  • 中等可用性FTT = 2
  • 高可用性FTT = 3

部署的结果是,您看到虚拟机对象分布​​在群集中的四个主机上,以满足可用性要求。重要的是要指出,用于演示的所有配置都存在于vCloud 自动化 Center中。没有自定义用作此实现的一部分。这只是vCloud 自动化 Center与Virtual SAN结合使用的众多方式之一。

尽管默认情况下vCloud 自动化 Center提供了部分集成功能,但自定义工作流程和高级配置可以完成更多工作。

vCloud 自动化 Center提供Virtual SAN的主要优势:

  • 集中的供应,治理,基础架构管理功能
  • 简单的自助服务消费功能
  • 权利合规性监视和执行
  • 利用现有的业务流程和工具
  • 委派资源控制

 

– Enjoy

有关将来的更新,请确保在Twitter上关注我: @PunchingClouds

X