VMware ESX与Virtual Iron的高可用性架构
目前唯一能提供高可用性机制的虚拟平台，是VMware Virtual infrastructure 3的HA，以及Virtual Iron V4 XEE的LiveRecovery，两者都架构十分类似，都是将数台实体机器构成一个资源池，然后透过一个管理平台（VMware的Virtual Center或Virtual Iron的Virtualization Manager）为储存池中的实体机器建立丛集关系。
接下来每台实体主机之间都会定期执行心跳检测，如果任一主机未能在时限内响应心跳检测，其它主机就会判定该主机已经失效，将会自动启动与该主机有关的虚拟机器。限制是资源池剩余的硬件资源必须大于或等于失效的那台实体主机，这样才能确保重启成功。
如果与DRS或LiveCapacity等自动负载平衡功能搭配，则系统还能在任一实体主机故障时，自动安排在最佳位置重启虚拟机器。
两种高可用性机制的关键都在于底层必须依靠一套共享储存设备，虚拟机器的数据是存放在后端储存设备，而不在前端实体主机，因此实体主机失效不会影响到数据，只要把数据转给另一台实体主机上新启动的虚拟机器使用即可。
两者较大的差别是当Virtual Iron的Virtualization Manager失效时，将无法启动LiveCapacity，必须复原Manager Server才能恢复高可用性机制。另外在内存的设定方面。VMware允许以硬盘Swap方式仿真内存，即使实体主机的物理内存较为不足，仍能重启故障主机上的虚拟机器。而Virtual Iron就会限制一定要物理内存。
两种方式互有利弊，VMware具有较大的弹性，但风险是若采用硬盘Swap将会大幅拖累虚拟机器的效能，虽然虚拟机器上的Guest OS仍可执行，但过慢的效能很可能会造成应用程序响应过慢，以致服务终止。而Virtual Iron的机制对内存的限制较严格，但较能保障服务的持续。
尽管这些高可用性架构都会持续监控整个丛集的资援使用率，确保丛集预留有足够的备用资源。但普桦科技的产品顾问李舒玄表示，最保险的作法还是在丛集（或资源池）中保留一台没有执行虚拟机器的「空」实体主机，这样才能确保失效切换的成功。
目前唯一能提供高可用性机制的虚拟平台，是VMware Virtual infrastructure 3的HA，以及Virtual Iron V4 XEE的LiveRecovery，两者都架构十分类似，都是将数台实体机器构成一个资源池，然后透过一个管理平台（VMware的Virtual Center或Virtual Iron的Virtualization Manager）为储存池中的实体机器建立丛集关系。
接下来每台实体主机之间都会定期执行心跳检测，如果任一主机未能在时限内响应心跳检测，其它主机就会判定该主机已经失效，将会自动启动与该主机有关的虚拟机器。限制是资源池剩余的硬件资源必须大于或等于失效的那台实体主机，这样才能确保重启成功。
如果与DRS或LiveCapacity等自动负载平衡功能搭配，则系统还能在任一实体主机故障时，自动安排在最佳位置重启虚拟机器。
两种高可用性机制的关键都在于底层必须依靠一套共享储存设备，虚拟机器的数据是存放在后端储存设备，而不在前端实体主机，因此实体主机失效不会影响到数据，只要把数据转给另一台实体主机上新启动的虚拟机器使用即可。
两者较大的差别是当Virtual Iron的Virtualization Manager失效时，将无法启动LiveCapacity，必须复原Manager Server才能恢复高可用性机制。另外在内存的设定方面。VMware允许以硬盘Swap方式仿真内存，即使实体主机的物理内存较为不足，仍能重启故障主机上的虚拟机器。而Virtual Iron就会限制一定要物理内存。
两种方式互有利弊，VMware具有较大的弹性，但风险是若采用硬盘Swap将会大幅拖累虚拟机器的效能，虽然虚拟机器上的Guest OS仍可执行，但过慢的效能很可能会造成应用程序响应过慢，以致服务终止。而Virtual Iron的机制对内存的限制较严格，但较能保障服务的持续。
尽管这些高可用性架构都会持续监控整个丛集的资援使用率，确保丛集预留有足够的备用资源。但普桦科技的产品顾问李舒玄表示，最保险的作法还是在丛集（或资源池）中保留一台没有执行虚拟机器的「空」实体主机，这样才能确保失效切换的成功。
| 上一页 第 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] 页 下一页 |
