Part3 保护虚拟环境的建置策略
现实中不存在十全十美的IT解决方案，只有较适合或较不适合某类环境的区别。从我们前面谈到的种种虚拟环境备份、备援与负载平衡手段就可看出，要达到相同目的，不会只有一种办法。但不同方式所需付出的代价，以及达到的效果都各有不同，以备援来说，越高层级的保护，效果虽然越好，但相对的付出的投资也越高，不见得适合所有用户。
不过从前面的讨论，我们仍可归纳出几个基本原则：
原则1 备份是不可或缺的基本措施
无论是否建有高可用性备援架构，都仍然需要备份。考虑到高可用性架构属于一种同步复制的机制，也就是说主系统的错误也会被同步到备援系统上，要解决这个问题，还是得利用备份取得不同时间点的复本。另外为因应法规要求的长期保存需求，同样也必须依靠备份来满足。
至于要采取哪一种备份手段，则须依具体情况而定：
● 在虚拟机器上安装代理程序：导入虚拟化之前，如果已为每一台服务器都购买了备份代理程序授权，则可把这些授权移到虚拟机器上使用，如此即可无需更动原有备份架构与政策。但前提是执行虚拟软件的实体主机不能背负太多的虚拟机器，以免备份带来的负荷影响到系统效能。如果要在实体主机上执行超过10个以上的虚拟机器，这种方式便不适用。
● 实体主机端备份：如果只有执行冷备份的需求，又能容许备份期间的效能降低，可以考虑实体主机端的备份，否则就得透过撰写Script来确保热备份的一致性。
● 储存端备份：如果用户的储存设备能提供快照功能，那在备份时可优先考虑选择储存端备份，以将备份负担从前端主机卸下。不过还要注意到需透过Script保持复本一致性，以及储存设备效能问题。
原则2 依任务关键性与预算选择备援类型
不是所有虚拟环境用户都需要建立可自动执行失效切换的高可用性备援系统，需视用户对虚拟机器失效后能容忍的回复时间长短而定，如果虚拟机器中执行的是极为关键的服务，只能容许几十秒或更短的服务中断，才需要导入高可用性架构，否则一般的备份就能满足要求。
而虚拟环境的高可用性架构，由低到高又可分为几个等级：
基本的实体主机备援
也就是在多台实体主机上建立高可用性丛集，但底层的储存设备、网络与外部的虚拟化管理平台仍为单点。
实体主机＋储存设备的高可用性
目前企业级虚拟平台的架构中，数据都是存放一个共享储存设备中，而虚拟平台提供的高可用性功能，也都必须依赖这个共享储存设备才能实现，因此共享储存设备也就成为一个单点故障来源。一旦储存设备损毁，则一切数据都会遗失，更谈不上高可用性。因此对较讲求可用性的用户，为储存设备建立高可用性架构，也是不可或缺的措施。
目前许多企业级储存设备都能提供A-A或A-S的高可用性架构，当然用户也可不利用储存设备本身的高可用性机制，而透过储存虚拟化产品如IBM SVM、DataCore的SANsymphony、SANmelody，以及Falconstor的IPStore等提供的多路径动态传输功能，来达到储存设备高可用性的目的。
实体主机＋储存设备+传输通道的高可用性
当前端实体主机与后端储存设备都建立高可用性后，还要考虑到连接实体主机与实体主机的局域网络，以及实体主机连接储存设备或储存设备彼此互连的局域网络或储存局域网络（SAN），也都可能是导致系统失效的因素。
虽然网络设备出问题的机率比实体主机或储存设备要低，但若要确保实体主机或储存设备高可用性机制的传输路径动态切换能够成功，也需连带建立起高可用性的传输通道，包括前端服务器的局域网络，或后端储存设备的储存局域网络（SAN）也都必须冗余设置，也就是两套传输线路与两套交换机。
全冗余化（Full-Redundance）架构
许多虚拟平台的监控管理，以及在线迁移、自动负载平衡等功能都需依赖Virtual Center或Virtualization Manager之类的管理平台才能实现，虽然这些管理平台的失效，不会直接影响到虚拟机器的运作，也不会影响高可用性功能，但用户仍将因此失去许多管理功能（如在线迁移、自动负载平衡等）。一般的备份固然能满足保护这些管理平台的需求，但最理想的作法便是为这些管理平台建立丛集，使整个虚拟环境的每一个环节都有冗余系统备援，达到全冗余化。
全冗余化+异地端备援
全冗余化的虚拟环境虽能达到极高的可靠性，但问题是所有备援系统都是位于同一地点（顶多是不同楼层），并无法因应天灾、大规模停电等意外的冲击。要解决这个问题，就必须建立异地端的备援。
异地备援建置有多种方式，可采取主机端、网络端或储存端，不过考虑到虚拟环境中实体主机与网络的负担通常相当高，并不太适合采用会增加主机与网络负荷的主机端或网络端异地备援方案，因此储存端是较理想的方式。
目前许多较高阶的储存设备都能提供远程复制机制，如EMC的SRDF（Symmetrix Remote Data Facility）、NetApp的SnapMirror、HDS的TureCopy等，均可不经过前端主机，而直接把数据复制到远程另一台储存设备上。
当然也可利用DataCore SANsymphony与Falconstor IPStor等储存虚拟化产品来达到远程复制的目的，这类储存虚拟化平台也内建有远程复制功能，可将其界接的储存设备数据，从本地端复制到远程，同样不会占用前端主机的运算资源，而且不像储存设备内建的远程复制会限制异地端设备的厂牌型号，可在不同厂牌、类型的储存设备间进行镜像复制，系统建置弹性更大。
原则3 视政策决定导入在线迁移与负载平衡与否
无需停机的在线虚拟机器迁移，或是自动负载平衡通常只有较少数用户需要。多数企业都订有停机岁修时间，也能容许主机在升级时短暂停机，除非是执行的业务极为关键，连一点点服务中断都不允许，才用得上不停机的在线迁移功能。
而自动负载平衡的情况也类似，即使用户发现原先为虚拟机器调配的硬件资源并不适当，而需重新调整，多数用户也能接受以手动方式迁移虚拟机器，将虚拟机器从负担较重的实体主机转移到负担较轻的主机上，只有大量执行关键应用的虚拟化用户，才需要全自动的负载平衡机制。
现实中不存在十全十美的IT解决方案，只有较适合或较不适合某类环境的区别。从我们前面谈到的种种虚拟环境备份、备援与负载平衡手段就可看出，要达到相同目的，不会只有一种办法。但不同方式所需付出的代价，以及达到的效果都各有不同，以备援来说，越高层级的保护，效果虽然越好，但相对的付出的投资也越高，不见得适合所有用户。
不过从前面的讨论，我们仍可归纳出几个基本原则：
原则1 备份是不可或缺的基本措施
无论是否建有高可用性备援架构，都仍然需要备份。考虑到高可用性架构属于一种同步复制的机制，也就是说主系统的错误也会被同步到备援系统上，要解决这个问题，还是得利用备份取得不同时间点的复本。另外为因应法规要求的长期保存需求，同样也必须依靠备份来满足。
至于要采取哪一种备份手段，则须依具体情况而定：
● 在虚拟机器上安装代理程序：导入虚拟化之前，如果已为每一台服务器都购买了备份代理程序授权，则可把这些授权移到虚拟机器上使用，如此即可无需更动原有备份架构与政策。但前提是执行虚拟软件的实体主机不能背负太多的虚拟机器，以免备份带来的负荷影响到系统效能。如果要在实体主机上执行超过10个以上的虚拟机器，这种方式便不适用。
● 实体主机端备份：如果只有执行冷备份的需求，又能容许备份期间的效能降低，可以考虑实体主机端的备份，否则就得透过撰写Script来确保热备份的一致性。
● 储存端备份：如果用户的储存设备能提供快照功能，那在备份时可优先考虑选择储存端备份，以将备份负担从前端主机卸下。不过还要注意到需透过Script保持复本一致性，以及储存设备效能问题。
原则2 依任务关键性与预算选择备援类型
不是所有虚拟环境用户都需要建立可自动执行失效切换的高可用性备援系统，需视用户对虚拟机器失效后能容忍的回复时间长短而定，如果虚拟机器中执行的是极为关键的服务，只能容许几十秒或更短的服务中断，才需要导入高可用性架构，否则一般的备份就能满足要求。
而虚拟环境的高可用性架构，由低到高又可分为几个等级：
基本的实体主机备援
也就是在多台实体主机上建立高可用性丛集，但底层的储存设备、网络与外部的虚拟化管理平台仍为单点。
实体主机＋储存设备的高可用性
目前企业级虚拟平台的架构中，数据都是存放一个共享储存设备中，而虚拟平台提供的高可用性功能，也都必须依赖这个共享储存设备才能实现，因此共享储存设备也就成为一个单点故障来源。一旦储存设备损毁，则一切数据都会遗失，更谈不上高可用性。因此对较讲求可用性的用户，为储存设备建立高可用性架构，也是不可或缺的措施。
目前许多企业级储存设备都能提供A-A或A-S的高可用性架构，当然用户也可不利用储存设备本身的高可用性机制，而透过储存虚拟化产品如IBM SVM、DataCore的SANsymphony、SANmelody，以及Falconstor的IPStore等提供的多路径动态传输功能，来达到储存设备高可用性的目的。
实体主机＋储存设备+传输通道的高可用性
当前端实体主机与后端储存设备都建立高可用性后，还要考虑到连接实体主机与实体主机的局域网络，以及实体主机连接储存设备或储存设备彼此互连的局域网络或储存局域网络（SAN），也都可能是导致系统失效的因素。
虽然网络设备出问题的机率比实体主机或储存设备要低，但若要确保实体主机或储存设备高可用性机制的传输路径动态切换能够成功，也需连带建立起高可用性的传输通道，包括前端服务器的局域网络，或后端储存设备的储存局域网络（SAN）也都必须冗余设置，也就是两套传输线路与两套交换机。
全冗余化（Full-Redundance）架构
许多虚拟平台的监控管理，以及在线迁移、自动负载平衡等功能都需依赖Virtual Center或Virtualization Manager之类的管理平台才能实现，虽然这些管理平台的失效，不会直接影响到虚拟机器的运作，也不会影响高可用性功能，但用户仍将因此失去许多管理功能（如在线迁移、自动负载平衡等）。一般的备份固然能满足保护这些管理平台的需求，但最理想的作法便是为这些管理平台建立丛集，使整个虚拟环境的每一个环节都有冗余系统备援，达到全冗余化。
全冗余化+异地端备援
全冗余化的虚拟环境虽能达到极高的可靠性，但问题是所有备援系统都是位于同一地点（顶多是不同楼层），并无法因应天灾、大规模停电等意外的冲击。要解决这个问题，就必须建立异地端的备援。
异地备援建置有多种方式，可采取主机端、网络端或储存端，不过考虑到虚拟环境中实体主机与网络的负担通常相当高，并不太适合采用会增加主机与网络负荷的主机端或网络端异地备援方案，因此储存端是较理想的方式。
目前许多较高阶的储存设备都能提供远程复制机制，如EMC的SRDF（Symmetrix Remote Data Facility）、NetApp的SnapMirror、HDS的TureCopy等，均可不经过前端主机，而直接把数据复制到远程另一台储存设备上。
当然也可利用DataCore SANsymphony与Falconstor IPStor等储存虚拟化产品来达到远程复制的目的，这类储存虚拟化平台也内建有远程复制功能，可将其界接的储存设备数据，从本地端复制到远程，同样不会占用前端主机的运算资源，而且不像储存设备内建的远程复制会限制异地端设备的厂牌型号，可在不同厂牌、类型的储存设备间进行镜像复制，系统建置弹性更大。
原则3 视政策决定导入在线迁移与负载平衡与否
无需停机的在线虚拟机器迁移，或是自动负载平衡通常只有较少数用户需要。多数企业都订有停机岁修时间，也能容许主机在升级时短暂停机，除非是执行的业务极为关键，连一点点服务中断都不允许，才用得上不停机的在线迁移功能。
而自动负载平衡的情况也类似，即使用户发现原先为虚拟机器调配的硬件资源并不适当，而需重新调整，多数用户也能接受以手动方式迁移虚拟机器，将虚拟机器从负担较重的实体主机转移到负担较轻的主机上，只有大量执行关键应用的虚拟化用户，才需要全自动的负载平衡机制。
【责任编辑 冉金龙】
| 上一页 第 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] 页 |
