网路资讯／虚拟备份101招

作／詹姆士

在科技的世界里，唯一不变的事情就是改变。伺服器与资料中心已经因为虚拟化、云端应用与行动应用而改变；甚至连网路也因为私有云，以及软体定义网路(SDN)而面临剧烈变化。毫无意外地，备援与复原系统也必须顺应这个趋势。

资料不再只储存在实体伺服器的外壳里；现在资料无所不在，包括手机、平板电脑、旅行用笔电、甚至存在云端平台。因此产生出更大的、更多元的应用组合，也意味着将出现更多变的可用性需求、备援频率以及复原点和复原时间目标。

虽然改变不曾停歇，但有些传统的备援方式仍然存在。试想有多少公司还在使用磁带？在《2013 InformationWeek备援科技调查》中，有33%受访者表示，他们仍然大量使用直接式磁带备援系统。

另外有33%受访者表示他们仍少量使用这种技术；而且还有55%表示他们还在使用磁碟到磁碟到磁带(Diskto-disk-to-tape)备援，只是程度多寡不一。很显然地，备援平台必须跟上时代了。

迈向虚拟化

一般而言，只管理一个备援与复原系统会比同时管理多个系统来的好。如果现在要在市场上找个新的备援产品，这个产品势必要能广泛支援各种hypervisor、作业系统以及邮件和资料库伺服器等服务，以确保公司能够建立一个集中、完整的复原设备，让所有系统一目了然。

当然有些系统比较擅长支援某些特定的资源，所以IT人员应该详细列出公司所使用的各种作业系统、hypervisor以及应用，好跟业者的相容性清单一一比对。

也由于有太多平台要支援，产品业者很难在每一项功能上都有出色表现。例如有些系统非常适合与Hyper-V共同使用，在VMware上表现也还不错，但可能无法与Xen或Oracle发挥效果。

有些则刚好相反，有些系统会利用某家公司的虚拟化应用程式介面(API)，透过虚拟主机来完成访客资料备份，但他们却无法用另一家业者的API来做同样的事。

要备份虚拟机器之前，得先在每个虚拟机器中部署代理程式，或许你已经发现，这种方法有好处也有坏处。在好的方面，一线的备援产品业者都会提供代理程式，而且这些代理程式基本上均可提供备援实体伺服器所需的完整功能。

根据《InformationWeek》的调查显示，使用虚拟机器代理程式是一般备援虚拟伺服器时最常见的方法，有48%受访者使用这种方式。

但是从缺点来看，如果要在每个虚拟机器中安装、管理代理程式，这势必要耗费许多心力。

Howard Marks在备援科技报告中写道：「透过代理程式备援会产生大量的网路流量，因为资料会透过虚拟机器的磁碟传送，经过代理程式后才离开虚拟机器的LAN连结。

因为单一主机上的所有虚拟伺服器会一起共享这个主机的频宽，因此要为新的虚拟机器备援可能会塞住网路连线，吃掉其它虚拟机器的资源。」

而另一个选择，就是利用hypervisor的API所建立的备援软体。有13%的受访者是直接透过VMware的API进行备援，同时，也有22%受访者使用hypervisor或储存系统上的影像备份。

要留意的是，直接从hypervisor进行备援并不是传统备援产品的强项。以hypervisor为基础的备援产品中，最佳的产品在hypervisor革命的早期就已经进入市场，所以它们的发展稳定，把其它大公司远抛在后。最常见的例子就是Veeam搭配VMware，以及vRanger和SEP Sesam的搭配，而SEP Sesam则是与Citrix Xen紧密结合。

也就是说，这些产品在hypervisor层次可以发挥良好功能，但若要支援Guest层次的特殊应用，仍会遇到许多限制。

因此，许多公司使用两种以上的备援产品，希望结合像是Veeam这种较先进的虚拟化备援产品，以及传统以代理程式为基础的备援伺服器，用来处理一般应用、不间断地保护资料。如果再加上第三层快照，或是以影像为基础的备援，这可是会变得非常复杂。

幸好一个好的管理平台（例如Systems Center Operations Manager）可以结合这些报告，并建立完整的图像；但是除非有绝对必要，有谁会想要花时间创造一个客制化的平台？而且，如果还要找出其中的错误，那要怎么办？当然企业可以回头采用能通报错误的备援平台，不过前提是，IT人员必须非常精通于透过API自动化。