VMware vSphere 5.1 群集深入解析(二十七)- 群集架构的扩展

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介:

第四部分 群集架构的扩展

第一章 群集架构的扩展

在这部分我们将继续讨论特定的基础架构、怎样利用HA,DRS和存储DRS以及怎样部署增加可用性。无论是你的工作量还是资源提供给你的工作量,我们将通过一些设计建议和决策方法来进行指导。当然,为了在实施的细节上做出合适的决定,完全了解你的环境是必要的。无论如何,我们希望这个部分能提供一个恰当的方式理解如何将某些功能放到一起,如何在你的环境接收到需求的时候,建立理想的架构。

 

场景

我们选择是场景是扩展群集,也会提到Vmware vSphere Metro Storage Cluster解决方案。我们选择指导的场景来允许我们解释多个设计和架构考虑。尽管场景已经测试过,在我们的实验环境中也有效,每个环境是独一无二的,我们的建议基于我们的经验和你的情况可能不同。

一个VMware vSphere Metro Storage Cluster (vMSC)配置是Vmware vSphere 5认证的解决方案,基于群集结合存储阵列同步复制。这个解决方案通常部署在数据中心距离上有限制的环境,往往大都市或者校园环境。

扩展群集模式主要的优势是使数据中心充分活跃和工作负载平衡,因为站点之间虚拟机的迁移和存储vMotion的能力,许多客户发现了其吸引力,开启 on-demand和non-intrusive来跨站点移动工作负载,群集的扩展能力提供主动负载平衡自由,这应该是主要的设计和实施目标。

扩展群集解决方案提供的好处:

  • 工作负载移动性

  • 跨站点自动负载平衡

  • 增强避免停机时间

  • 避免灾难

 

技术需求和约束

因为虚拟机在线迁移的技术约束,有一些指定的需求必须在扩展群集实施时需要考虑,这些需求在Vmware 硬件兼容向导中存储部分的清单中,包括如下:

  • 存储连接使用光纤通道,ISCSI,SVD(存储虚拟化设备)和支持FCOE

  • 存储连接使用NAS(NFS协议)在写入的时候不支持vMSC配置(2012年8月)

  • 在站点和ESXi管理网络之间支持的最大网络延迟为10ms往返时间(Round Trip Time (RTT))

  • 注意vMotion仅仅在企业加强版的license下才支持的10ms延迟(Metro vMotion)

  • 为了同步存储重复链接支持最大的延迟是5ms(Round Trip Time (RTT)),通常你的存储厂商会提供它们允许的最大的RTT

  • ESXi的vMotion网络至少需要622Mbps的冗余网络链路

存储的需求比存储同步复制解决方案要复杂一些,一个vSphere Metro Storage Cluster请求会由单个存储子系统扩展到站点,在这个设计中,提供的数据存储必须可以访问(能读能写),并同时来自于两个站点。更进一步,当问题出现,ESXi主机必须能继续从任一站点访问数据存储,不影响正在进行的存储操作。

这排除了传统的同步复制解决方案,当他们在活动的(主)LUN之间创建主/备关系,数据被访问,备LUN正在收到复制操作,在这些解决方案中,为了访问备LUN,重复必须停止(或者撤销),LUN可见主机,现在升级了的备LUN有了完全不同的LUN ID,本质上是一个新的可用副本,这种类型的解决方案适用于适用于传统的灾难恢复。预计虚拟机需要在第二站点上启动,vMSC需要同时配置第二站点,vMSC需要同时配置不影响访问,所以站点之间还是允许运行着的虚拟机进行迁移;正常的vMotion不会迁移虚拟机的磁盘文件。

vMSC的存储子系统必须在两个站点上同时读写,所有磁盘写入站点同步来确保数据一致性。写无论本地从哪个位置读取,存储架构在群集站点间调用需要大量的带宽和非常低的延迟,增加距离和延迟将引起磁盘写入延迟,使得性能大打折扣,将不允许在群集站点的不同地点之间成功执行vMotion。

 

统一和非统一

vMSC解决方案在不同区域目录中分类,这些分类基于不同基础的主机访问存储。理解不同类型的扩展存储解决方法非常重要,它会影响到你的设计,有个主要的目录在VMware 硬件兼容性列表中有描述:

  • 统一主机访问配置–两个站点的ESXi主机要连接全部站点存储群集上的存储节点来访问,提交ESXi主机的路径是扩展访问距离

  • 不统一的主机访问配置–每个站点的ESXi主机只连接同一站点的存储节点,提交ESXi主机的路径的存储节点限制在本地站点。

让我们从架构和实施角度描述更深一些来确保它们足够清晰。

统一,数据中心-A和数据中心-B的主机既能访问数据中心A存储系统又能访问数据中心B存储系统。实际上,存储区域网络在站点和所有主机之间被扩展从而能访问所有的LUN,在这些配置中,读写访问LUN发生在两个阵列之一上,同步镜像被维护隐藏,在第二阵列处于只读状态。例如,如果LUN包含的数据存储在数据中心-A的阵列上可读写,所有的ESXi主机将通过数据中心A的阵列进入数据存储,为了数据中心A的ESXi主机,会有一个本地访问,数据中心B ESXi主机上的运行着虚拟机的位于数据存储上,为了防止停机或者LUN的操作控制转换到数据中心-B上,所有的ESXi主机将继续查看在场的相同的LUN,除了已经访问了数据中心-B的ESXi主机。

图160:统一存储架构

image

正如你所看到的,理想的情况是一个虚拟机同一个数据中心通过阵列控制(读写)访问的数据存储,这最大限度的减少了数据中心之间的流量,避免了读取整个互连性能的影响。

虚拟机的站点关联的概念是由数据存储的读写副本支配,“站点关联”一些时候也称之为“site bias”或者“LUN locality”,意味着当数据中心A上的虚拟机有站点关联,它读写数据中心A位于数据存储上的副本,这已经在DRS章节中解释得较详细。

 

不统一:数据中心A上的主机只能访问数据中心本地的阵列,阵列(相反的数据中心的同级阵列)负责提供全部的数据存储大家访问,在大多数场景中虚拟机用到了这个概念,它允许每个数据中心上的ESXi主机读写同一个数据存储/LUN。

很好理解,即使两个虚拟机在同一个数据存储,但位于不同的数据中心,它们会写到本地,在此配置的一个关键点是,定义每个LUN/数据存储的站点关联(Site Affinity),还有时候需要涉及到“Site bias”或者“LUN locality”。换句话说,如果在站点和站点上的存储系统之间的链路上发生一些事情,站点为了个给数据存储将只有读写方式的能够访问,这当然是为了在失败的场景下阻止数据损坏。

图161:不统一的存储架构

image

作为统一的解决方案是当今最常用的部署,我们的测试情况下将使用统一存储,应当指出,许多的设计考虑也适用于非统一配置,若不是这种场景的情况,我们会进行收集。

 

场景架构

在这部分我们将为场景描述架构配置,我们还将讨论一些基本的配置和多样的vSphere功能,为了更深的解释各自的功能,涉及到此书HA和DRS部分,我们将基于VMware最佳实践和提供的操作手册来提出针对建议,在我们失败的场景中将解释怎样在实践中阻止和限制停机时间。

 

架构

一个由单个vSphere 5.1群集和4个ESXi主机组成的架构场景,vSphere vCenter服务器管理这些主机,它决定使用vSphere 5.1来测试提高改进vSphere 5.0 U1中介绍的“永久设备丢失”(PDL)场景。介绍的这些加强的功能主要用于扩展群集环境。我们将在此章节讨论vSphere HA部分更详细的内容。值得注意的是在vSphere 5.1中PDL行为方面没有任何改变。

为了我们测试目的,我们模拟有两个站点的用户环境,第一个站点叫Frimley,第二个站点叫Bluefin。Frimley数据中心和Bluefin数据中心之间是扩展2层网络,学校群集之间的距离是最小的距离,vCenter Server和虚拟机运行在同一个群集上。

每个站点有两个ESXi主机,Bluefin数据中心的vCenter Server配置了vSphere DRS管理主机,在扩展群集环境中只有一个vCenter Server实例是使用的,不同于传统的VMware Site Recovery Manager配置需要两个vCenter Server。在第15章讨论了配置VM-Host关联规则,在我们的场景中使用ISCSI为主要协议。

在vSphere 5.1群集通过统一设备接入模式的光纤配置连接上NetApp MetroCluster。此配置在NetApp的技术白皮书“TR-3548”中有深入描述。这意味着群集里每个主机连接了两个存储节点。每个节点连接到两个光纤交换机,第二区域的节点还连接到两个类似的交换机,对于任何给定的LUN,两个存储节点中的任何一个呈现的LUN是通过ISCSI读写。

与此相反的存储节点保持着复制,只读副本有效的隐藏起来,直到ESXi主机需要。

当使用NetApp MetroCluster,一个ISCSI连接绑定一个指定的虚拟IP地址,ESXi主机上的这个虚拟IP地址用来连接存储控制器。在失败的场景中,IP-Address转换到相反的存储控制器,允许无缝访问目标存储的IP地址,而不需要重新配置。

总计创建了8个LUN:4个通过虚拟ISCSI IP地址访问Frimley数据中心,另外4个通过虚拟ISCSI IP地址访问Bluefin数据中心。

图162:基础结构

image

表27:基础架构

image





本文转自 tim2009 51CTO博客,原文链接:http://blog.51cto.com/virtualbox/1223280,如需转载请自行联系原作者
目录
相关文章
|
2月前
|
监控 API 开发者
深入理解微服务架构:构建可扩展的应用程序
【10月更文挑战第6天】深入理解微服务架构:构建可扩展的应用程序
48 0
|
3月前
|
存储 缓存 API
探索后端技术:构建高效、可扩展的系统架构
在当今数字化时代,后端技术是构建任何成功应用程序的关键。它不仅涉及数据存储和处理,还包括确保系统的高效性、可靠性和可扩展性。本文将深入探讨后端开发的核心概念,包括数据库设计、服务器端编程、API 开发以及云服务等。我们将从基础开始,逐步深入到更高级的主题,如微服务架构和容器化技术。通过实际案例分析,本文旨在为读者提供一个全面的后端开发指南,帮助大家构建出既高效又具有高度可扩展性的系统架构。
|
2月前
|
监控 持续交付 API
深入理解微服务架构:构建高效、可扩展的系统
【10月更文挑战第14天】深入理解微服务架构:构建高效、可扩展的系统
93 0
|
2月前
|
消息中间件 监控 API
理解微服务架构:构建灵活和可扩展的应用
【10月更文挑战第7天】理解微服务架构:构建灵活和可扩展的应用
|
2月前
|
消息中间件 监控 API
深入理解微服务架构:构建可扩展与灵活的应用
【10月更文挑战第7天】深入理解微服务架构:构建可扩展与灵活的应用
45 0
|
1月前
|
监控 前端开发 JavaScript
探索微前端架构:构建可扩展的现代Web应用
【10月更文挑战第29天】本文探讨了微前端架构的核心概念、优势及实施策略,通过将大型前端应用拆分为多个独立的微应用,提高开发效率、增强可维护性,并支持灵活的技术选型。实际案例包括Spotify和Zalando的成功应用。
|
15天前
|
监控 持续交付 API
深入理解微服务架构:构建高效、可扩展的系统
深入理解微服务架构:构建高效、可扩展的系统
30 0
|
1月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
82 1
|
20天前
|
监控 测试技术 持续交付
深入理解微服务架构:构建高效、可扩展的系统
深入理解微服务架构:构建高效、可扩展的系统
35 0
|
2月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
62 3

推荐镜像

更多