《VMware Virtual SAN权威指南》一3.9.4 vSphere HA隔离响应

3.9.4 vSphere HA隔离响应

当一个启用了vSphere HA的VSAN群集上发生主机隔离事件时,vSphere HA会执行已配置过的隔离响应措施。就vSphere HA,你可以选择以下三种不同类型的隔离响应:
Leave power on(保持打开电源)
Power off,then fail over(关闭电源,然后故障切换)
Shut down,then fail over(关机,然后故障切换)
当主机隔离事件发生时,推荐的做法是让vSphere HA自动关闭运行在该主机上的虚拟机电源(Power Off)。也就是说,隔离响应应该选择“Power off,then failover”(关闭电源,然后故障切换),而不是默认选项Leave power on(保持打开电源)。
注意,“Power off,then failover”(关闭电源,然后故障切换)类似于对物理主机直接拔掉电源线的操作,虚拟机进程会被直接打断——这不是一次干净的关机。然而,在出现隔离事件的情况下,这种操作使得虚拟机不可能继续写入隔离主机上的磁盘中,因此关闭电源的做法是我们推荐的选择。此外,如果ESXi主机被分区了,虚拟机也不可能访问到存储对象的仲裁组件。

时间: 2024-11-10 07:07:55

《VMware Virtual SAN权威指南》一3.9.4 vSphere HA隔离响应的相关文章

《VMware Virtual SAN权威指南(原书第2版)》一导读

前 言 说到虚拟化及其依赖的底层基础架构,经常会提起一个组件--存储.原因相当简单:在很多环境中,存储是痛点.尽管存储市场已经因为闪存技术的引入发生了变化,很多传统的存储问题得到了缓解,但是很多机构还没能采纳这些新的架构,因而仍然会遇到挑战. 存储问题的范围包括运营上的复杂性到性能问题甚至是可用性的限制.这些问题中的大部分都起因于同样的根本问题:老旧的系统架构.这是因为大多数存储平台架构是在虚拟化技术出现之前开发出来的,而虚拟化已经改变了使用这些共享存储平台的方法. 某种程度上,可以说是虚拟化迫

《VMware Virtual SAN权威指南》一导读

前 言 说到虚拟化及其依赖的底层基础架构,经常会提起一个组件--存储.原因相当简单:在很多环境中,存储是痛点.尽管存储市场已经因为闪存技术的引入发生了变化,很多传统的存储问题得到了缓解,但是很多机构还没能采纳这些新的架构,因而仍然会遇到挑战.存储问题的范围包括运营上的复杂性到性能问题甚至是可用性的限制.这些问题中的大部分都起因于同样的根本问题:老旧的系统架构.这是因为大多数存储平台架构是在虚拟化技术出现之前开发出来的,而虚拟化已经改变了使用这些共享存储平台的方法.某种程度上,可以说是虚拟化迫使存

《VMware Virtual SAN权威指南》一3.9.1 vSphere HA通信网络

3.9.1 vSphere HA通信网络 在非VSAN部署中,vSphere HA代理的通信是通过管理网络进行的:在VSAN环境中,vSphere HA代理的通信是通过VSAN网络进行的.背后的原因是我们希望当网络故障发生时,vSphere HA主机和VSAN主机是位于同一分区(partition)中的,这就避免了故障时因vSphere HA和VSAN判断的分区不同而造成拥有的存储组件和对象集不同所造成的可能的冲突. 在VSAN环境下的vSphere HA在默认情况下仍然将管理网络的默认网关用作

《VMware Virtual SAN权威指南》一3.9.2 vSphere HA心跳数据存储

3.9.2 vSphere HA心跳数据存储 VSAN上的vSphere HA的另一个显著不同是VSAN数据存储不能用作数据存储心跳(datastore heartbeat).当在传统的SAN或者NAS数据存储上的vSphere HA群集发生了分区故障事件时,心跳对于决定虚拟机的归属扮演着非常重要的角色.这个功能对于部署在传统共享存储环境(NAS/SAN)下的vSphere HA是非常有帮助的,因为它允许分区在同一层面上进行协调.vSphere HA不将VSAN数据存储用于心跳也不允许用户把它指

《VMware Virtual SAN权威指南》一3.6 网络I/O控制配置示例

3.6 网络I/O控制配置示例 如前所述,网络I/O控制(NIOC)可以用来保证VSAN群集的通信和I/O传输所需的带宽.只有在vSphere分布式交换机(VDS)中才能配置NIOC,而在VMware标准交换机(VSS)中是不支持的.VDS的确只在某些高版本的vSphere中才提供,不过VSAN已经包含了VDS,而不管你使用的是哪个版本的vSphere. 如果你正在使用的分布式交换机版本早于vSphere版本,为了使用VSAN,我们建议你把它升级到最新版本,虽然vSphere的文档中没有特别指出

《VMware Virtual SAN权威指南(原书第2版)》一2.3 网络要求

2.3 网络要求 这一节将从网络角度探讨VSAN的需求和前提条件.VSAN是一种分布式的存储解决方案,因此它对主机之间的通信网络非常倚重,其关键是稳定性和可靠性. 2.3.1 网络接口卡 每台ESXi主机必须至少具有一块千兆以太网络接口卡专用于VSAN混合配置,而全闪存配置必须使用万兆网卡.然而,作为最佳实践,VMware和本书作者都推荐使用万兆网卡.出于冗余的考虑,可以在每一台主机上都配置网卡绑定.我们认为这是最佳实践,但这并不是构建一个完整功能的VSAN群集所必需的. 2.3.2 受支持的虚

《VMware Virtual SAN权威指南》一1.1 软件定义的数据中心

1.1 软件定义的数据中心 在2012年VMware的年度大会VMworld上,VMware分享了对于软件定义的数据中心(software-def?ined datacenter,SDDC)的愿景.SDDC是VMware的公有云和私有云的架构,在其中将数据中心所有的重要组成部分--计算.存储.网络以及相关的服务全部都进行虚拟化.将数据中心的各个组件虚拟化使得IT团队更加灵活,降低了运营的复杂性,减少了成本,并同时增加了可用性和敏捷性,最终将大大缩短把新服务投向市场的时间. 要达到这些目的,仅仅是

《VMware Virtual SAN权威指南》一1.4 Virtual SAN简介

1.4 Virtual SAN简介 对于软件定义的存储,VMware计划把重点放在一系列本地存储.共享存储以及存储/数据服务的VMware创新项目上.一言以蔽之,VMware想让vSphere成为存储服务的平台. 存储曾经是一种在项目初期配置.部署完毕并且在其整个生命周期都不会变更的存在.如果需要变更某个正被虚拟机使用的LUN或卷的某些特性或属性,大多数情况下,原始LUN或卷必须被删除并重建.这是一种干扰生产的.有风险的并需要耗费大量时间的操作,因为它需要在LUN或卷之间迁移数据.这甚至可能需要

《VMware Virtual SAN权威指南》一1.3 超融合/服务器SAN解决方案

1.3 超融合/服务器SAN解决方案 过去几年,围绕着什么是超融合什么又是Server SAN存在着很多争论.在我们看来,这两者最大的区别就是运行的平台集成化的程度和交付模式.说起交付模式,则有2种不同的方案: 基于设备的 纯软件的 基于设备的解决方案就是把软件和硬件捆绑在一起销售交付的一种解决方案,它预装了一种hypervisor,通常配置起来不费吹灰之力.它往往还通过利用其所提供的存储API或嵌入在hypervisor内的扩展数据服务等各种方法与其运行的平台硬件深度集成. 在所有这些例子中,

《VMware Virtual SAN权威指南(原书第2版)》一3.3 VSAN网络配置之VMware标准交换机

3.3 VSAN网络配置之VMware标准交换机 通过VMware标准交换机创建一个用于VSAN网络流量的端口组是相对简单的.在安装ESXi主机的时候,一个VMware标准交换机已经自动创建,并用来承载ESXi网络管理流量和虚拟机流量.可以使用这个现存的标准交换机以及与之关联的与外部网络通信的上行链路来创建一个用于VSAN流量的新的VMkernel端口.或者可以选择为VSAN网络流量的VMkernel端口创建一个新的标准交换机(见图3-2),并为它选择一些新的上行链路. 在这个例子中,我们已经决