使用vembu bdr套件的任务关键VM为真实15分钟的RTO
大多数IT站点的关键任务系统分为两大类:数据库驱动的财务系统和过程控制制造系统。对于不需要专门的流程控制硬件的关键任务系统，vSphere虚拟环境中的高性能虚拟机在处理影响业务连续性的场景时为IT提供了明显的优势。
在这样的环境中，Vembu Backup&Disaster Recovery（BDR）的新v4.0版为其提供了一个灾难恢复管理（DRM）系统，该系统能够满足比以前版本更严格的RTO和RPO目标。对于高度活跃的数据库驱动系统，Vembu BDR v4.0利用VMware工具和VMware更改块跟踪（CBT）以15分钟的间隔执行增量备份，对查询处理的影响最小。因此，它可以将活动关键任务虚拟机上的数据丢失限制在15分钟的处理时间内。
尽管如此，使用紧密分散的数据恢复点来保护数据只是业务连续性SLA中规定的需求的一半。在恢复一个功能完整的VM的竞赛中，只损失15分钟过去的处理只是起点。如果恢复一个具有大量数据的VM需要60分钟，那么从LoB的角度来看，组织将损失75分钟的处理时间。这就是为什么任务关键系统的恢复时间是如此关键的问题。
今天，许多数据保护包试图通过直接从备份文件启动替代生产虚拟机来解决满足严格的RTO目标的问题。这些技术提供了在不首先执行恢复操作的情况下快速呈现能够执行与原始虚拟机相同功能的恢复虚拟机的能力。然而，恢复的VM无法维持相同水平的应用程序性能，这在LoB执行人员看来是一个严重缺陷。
在不执行显式恢复操作的情况下，恢复虚拟机的完整功能和性能的唯一方法是通过虚拟机复制。然而，维护一个副本虚拟机需要频繁且可能代价高昂的更新过程，其中包括显式备份和隐式恢复操作。
为了使IT部门能够广泛使用复制，Vembu BDR v4.0为恢复和复制操作添加了关键的优化，这大大减少了ESXi主机和生产虚拟机上的开销，而不仅仅是虚拟机快照处理。具体而言，在VM上运行的Vembu BDR服务器能够利用热添加SCSI传输模式将逻辑磁盘和逻辑磁盘快照文件直接写入vSphere数据存储，而无需ESXi主机来创建VM快照。
更重要的是，vembu bdr v4.0有一个副本管理模块，它使IT管理员能够完全管理初始故障转移，并稍后使用合并完成故障转移或故障恢复。此外，V4.0还通过消除在vembu bdr服务器上运行单独的客户端模块，从而简化了所有管理功能，该vembu bdr服务器将成为BDR报告层次结构中的自己的客户端。要使VM最佳支持Vembu BDR服务器的扩展功能，我们将使用4 CPU，8GB的RAM和Para虚拟化以太网NIC配置VM。
我们的LOB应用模拟基于TPC-E基准的OLTP股票交易应用。我们的目标是衡量频繁增量备份和复制操作引入的I / O负载变化如何改变了OLTP应用程序的I / O平衡。为此，我们监控了在测试期间执行的所有TPC-E SQL查询的聚合交易数据，我们指定为累积事务处理速率（CTPS）。标准TPC-E性能测试专注于以商业为导向的贸易结果查询的交易率，该贸易结果查询处理股票交易完成。
为了运行我们的测试应用程序，我们设置了两个vm，分别称为“oblSQL-1”和“SQLBench-1”。在oblSQL-1上，我们运行了一个由16 GB初始表数据生成的TPC-E基准数据库实例。为了支持TPC-E基准数据库，我们安装了SQL Server 2014，并在一个名为“ION_XENstor”的基于iSCSI san的数据存储上提供了8个cpu、32GB RAM和3个精简配置的逻辑磁盘。我们生成了针对SQLBench-1上的TPC-E数据库的客户和代理业务事务。最后，我们在VM上安装了Vembu BDR v4.0，我们称之为“oblVembu-40”，并将oblSQL-1复制到VM中，称为“oblSQL-1_Replica”。
我们在测试场景中在8Gbps光纤通道（FC）SAN或10GbE iSCSI SAN上配置了所有vSphere数据存储。通过对所有虚拟机数据存储使用共享存储，我们能够在每个虚拟机备份和恢复过程中利用无局域网技术。无局域网技术使运行BDR备份的VM能够确定是否可以使用SAN或热添加SCSI传输模式直接访问包含目标VM逻辑磁盘的数据存储。
虽然许多VM备份包在VM备份期间仅利用直接数据存储访问来读取数据，但Vembu BDR利用热添加SCSI模式在备份、恢复和复制操作中直接将数据读取和写入vSphere数据存储。在端到端VM复制中，Vembu BDR能够从源VM快照读取VMware更改块跟踪（CBT）数据，并将该数据作为逻辑磁盘快照写入副本VM的数据存储中。因此，Vembu BDR服务器能够执行频繁的复制更新，对活动VM的开销影响非常小。
- 系统卷(C:)，提供100gb的精简存储;
- SQL Server部署卷（D :)，具有50 GB的瘦身存储，
- 和TPC-E数据库卷（E :)，具有100 GB的薄配置存储
激活时，oblSQL-1在ION_XENstor数据存储上的存储空间在100到140 GB之间，其中包括一个用于VM页面交换的30 GB vSphere缓存文件。存储占用空间的变化主要与TPC-E数据库中表数据的增长有关，在较小程度上与系统数据库tempdb的增长有关，这是在SQLbench-1上启动的测试查询的结果。
我们开始评估BDR复制性能，通过设置完整备份的端到端性能基线，并完全恢复OBLSQL-1，没有SQL查询活动。在此过程中，我们从其初始数据存储，ION_Xenstor备份OBLSQL-1，然后将VM恢复为我们计划复制OBLSQL-1，XIO_ENSTOR的数据存储。
在对oblSQL-1进行全量备份时，BDR备份服务器oblVembu-40触发oblSQL-1的主机为ION_XENstor中的三个虚拟机逻辑磁盘分别创建快照。接下来，Vembu BDR备份服务器以每秒220 MB以上的速度依次从三个逻辑磁盘快照中挂载和读取块数据。与此同时，BDR备份服务器重新格式化、重复数据删除、压缩并将生成的备份数据(约占虚拟机原始数据存储占用空间的20%)以每秒超过95mb的速度写入BDR面向文档的数据库VembuHIVE®。通过大幅减少写入VembuHIVE的数据量，最初的全备份只花了11分钟。
完成完整备份后，我们将从vembuhive恢复OBLSQL-1到数据存储xio_xenstor。我们通过将xio_xenstor显式设计为目标数据存储来恢复OBLSQL-1;但是，我们将备份指向我们的vCenter服务器，而不是特定的ESXi服务器。
通过允许运行BDR Backup的虚拟机oblVembu-40通过我们的vCenter服务器恢复备份，该进程能够利用oblSQL-1的配置数据。在恢复过程开始时，vCenter被指示向oblSQL-1提供一个具有相同设备基础设施(cpu、内存、存储和网络)的新虚拟机。特别的是，新虚拟机具有与oblSQL-1相同的SCSI控制器和磁盘容量，但缺少数据。
当目标虚拟机创建完成后，oblVembu-40通过vCenter在ESXi服务器上触发一个快照，vCenter用来承载恢复的虚拟机。接下来，oblVembu-40挂载快照和VembuHIVE，以将oblSQL-1备份数据公开为一组三个vmdk格式的虚拟磁盘映像。然后BDR Backup能够从VembuHIVE流化备份数据，以大约5倍的倍数对该数据进行补水，然后将补水数据写入XIO_XENstor上的三个虚拟磁盘文件。
通过利用vCenter和vembuhive的功能，vembu bdr降低了恢复oblsql-1的过程，将VM虚拟磁盘映像流式传输到通过vCenter配置的新数据存储。通过将逻辑磁盘数据直接传输到新VM的数据存储，整个恢复过程能够在36分钟内完成。
在基线测试的最后阶段，我们运行了oblSQL-1的初始复制。对于任何虚拟机，初始复制任务本质上是作为完全备份和恢复执行，以创建源虚拟机的完整副本。因此，就像从传统备份恢复虚拟机一样，我们将vCenter服务器标识为新虚拟机副本的“主机”，并指定XIO_XENstor作为目标数据存储。
复制开始时，vCenter服务器创建并发放了一个名为“oblSQL-1_Replica”的新服务器。同样，新VM具有与oblSQL-1相同的设备基础结构。接下来，在复制过程中开销最严重的时刻，oblVembu-40触发vCenter服务器请求oblSQL-1的ESXi主机和oblSQL-1_Replica的ESXi主机为每个虚拟机创建快照。
在成功地为oblSQL-1和oblSQL-1_Replica创建快照之后，oblVembu-40再次利用LAN-free机制重新配置其磁盘基础设施。使用热添加SCSI模式，将oblSQL-1_Replica的数据存储快照以及oblSQL-1的三个逻辑磁盘的快照都挂载到oblVembu-40上。然后，我们的BDR备份服务器能够依次从oblSQL-1的三个卷中读取逻辑块数据，并将这些数据作为三个磁盘映像文件写入oblSQL-1_Replica的数据存储中。因此，在端到端复制过程中的所有I/O都由oblVembu-40直接处理，整个过程需要29分钟才能完成。
一旦创建了复制虚拟机，我们就能够使用连续的增量备份计划来更新副本。每次进行增量备份时，BDR backup服务器都会执行以下操作:
- 重新组织原虚拟机每个逻辑盘快照传输的CBT数据，
- 将该数据格式化为副本上对应磁盘的磁盘快照，
- 并将快照文件流到复制数据存储
在此过程中，BDR备份服务器始终将快照写入副本VM，快照比备份期间传输的原始CBT数据小50%到60%。
虽然TPC-E数据库上的SQL事务上的SQL事务的卷在TPC-E数据库上的两倍超过两倍，但是ION_NENSTOR上的物理I / O的模式，包含OBL-1的数据存储差别差异。TempdB上的所有I / O活动由逻辑读数组成，在ION_Xenstor上没有任何物理I / O.相比之下，TPC-E数据库上的SQL事务完全是写入操作。因此，我们的业务交易负载转换为TPC-E数据库上大约600个物理写入IOPS的源闪通流，然后又是ION_Xenstor。物理和逻辑SQL事务中的这些模式以及基础ESXi数据存储的结果IOPS负载对于为OBL-1提供全面的DRM计划具有重要意义。
在处理SQL Server上的TPC-E业务事务时，逻辑读的重要性使得OLTP应用程序对外部I/O操作不那么敏感，比如对底层数据存储上的快照数据的读写。尽管如此，数据的高写操作率(600 iops)使得oblSQL-1对逻辑磁盘快照的创建和展开特别敏感，特别是对于包含TPC-E数据库的逻辑磁盘。
更重要的是，我们的业务事务（添加和更新TPC-E数据库记录）每小时生成约25GB的CBT数据。为了遵守RPO，将数据丢失限制在oblSQL-1总数据的10%，RTO限制在15分钟，有必要每30分钟安排一次增量复制。
虽然复制虚拟机可以满足SLA对业务连续性的RPO和RTO要求，但它不能满足传统备份计划的任何记录保持要求。一个副本最多可以保留7个快照，当有新的快照添加时，快照会自动删除。因此，我们还需要设置一个持续的增量备份计划，这可能会与VMware的CBT机制产生严重的冲突。
在同一VM上运行两个不同的增量备份作业，没有控件损坏所有增量备份。每个作业将在每个备份后独立重置VMware CBT数据，从而留下了具有不完整数据的随后的增量备份。因此，只要将增量备份滚动到完整备份时，将会有未重配错误。
为了避免增量备份数据的损坏，Vembu BDR将CBT重置的所有控制权交给BDR客户端。因此，可以使用同一个BDR backup客户端在同一个虚拟机上调度复制和备份任务。特别是，客户端识别数据保护配置并同步CBT rest，以保持两个任务的备份数据一致。因此，我们为oblSQL-1安排了增量复制和备份过程，从备份或副本恢复虚拟机时从未引发数据损坏问题。
在我们的测试场景中，我们每30分钟运行一次增量复制和一次增量备份。对于这两个进程，我们启用了AppAware VSS快照，以确保所有SQL Server数据库的一致性。此外，由于在快照进程期间，oblSQL-1的数据存储产生了600个写IOPS，所以最大的开销发生在每个进程开始时，即数据库静默并创建快照时。
虽然在整个过程的初始化中，SQL Server事务处理级别的IOPS对OBL-1的IOPS速度仍然负担，但它们对缓存数据的强度依赖，请在两个进程中所有SQL Server数据库的静态之后快速反弹。因此，我们的OLTP业务事务处理应用程序在最小地受到TPC-E交易率下降约5％至约805 CTP的影响。
而且，在oblSQL-1上处理的IOPS不受影响，因为直接从每个进程开始时创建的逻辑磁盘快照生成的数据流为oblVembu-40流。读取增量备份数据或展开VMFS和VSS快照对事务处理没有影响。
为了完成复制测试，我们在Vembu BDR备份服务器中使用故障切换和回切选项执行了VM故障切换。我们首先关闭了oblSQL-1，它正在运行我们的OLTP应用程序。接下来，我们打开了故障切换和回切选项，在我们的oblSQL-1虚拟机副本上启动恢复操作。
从管理副本实用程序的顶部菜单中，系统管理员可以调用四个功能中的一个：
- 初始化生产处理到备用副本的故障切换，
- 在运行的副本上完成故障转移过程，
- 或完成从活动副本到原始生产系统的故障回退
- 从复制的虚拟机中恢复单个文件和文件夹
在初始故障切换中，副本将通电并从系统管理员选择的VM快照启动。对于我们的oblSQL-1副本，使用增量备份中创建的一个快照通电和引导的总时间刚刚超过4.5分钟。
完成初始故障转移后，IT管理员可以选择立即将副本作为生产系统运行。这种策略为最终恢复提供了最大的灵活性;然而，它也有明显的性能成本。VMware对每个逻辑盘的CoW (copy on write)快照会影响虚拟机的I/O性能。具体来说，CoW快照使写入新数据所需的I/O操作次数翻倍，因为必须先将已有数据写入快照，才能将新数据替换。
这种从快照运行的策略的基本原理是基于物理系统的使用。其基本思想是，副本是一个临时系统，仅在IT能够恢复原始物理系统之前使用它。此时，伪装成生产系统的副本将failback -到原始物理系统，包括它作为生产系统时发生的所有数据更改。虽然这种策略在不对称物理服务器的世界中是有意义的，但在虚拟环境中，这种策略等同于洗纸杯。
虚拟机的价值在于它没有价值。作为虚拟基础设施，虚拟机是consuma
祝福的对象。因此，一旦我们启动了VM并确认副本正在使用最新的数据进行操作，我们就使用Failover和Failback选项立即确定故障转移状态。在结束故障转移状态时，Vembu BDR Backup服务器从副本虚拟机中删除了所有快照，并消除了继续将该虚拟机作为复制目标的能力。尽管如此，在删除所有CoW快照时，故障转移终结确保所有进一步的I/O处理将不受任何阻碍地继续进行。
在启动oblSQL-1_Replica之后，我们立即在SQLbench-1上重新启动事务处理生成器。在10分钟内，SQL Server已经为新的VM上的TPC-E数据库处理重建了它的缓冲区和过程缓存。因此，在关闭原VM的15分钟内，我们以850个cTPS的原始生产速率处理业务事务。
Vembu BDR备份服务器的一个关键价值主张是，它能够直接从数据存储快照中读取和写入所有备份和恢复数据。因此，Vembu BDR减轻了生产虚拟机和ESXi主机的所有I/O开销，这对于在高度活跃的虚拟环境中维护积极的DRM策略至关重要。此外，Vembu BDR在我们的测试环境中的性能使我们能够通过对备份和复制的增量备份的组合来增强对运行在VM上的任务关键型OLTP应用程序的支持。因此，我们能够遵守30分钟的RPO，在5分钟内将VM恢复到生产环境，并在15分钟内返回到业务事务的全生产级别处理(850个ctp)。
