了解7大典型负载数据变化规律，让快照灾备更加高效

随着用户对RPO和RTO的极致追求和存储快照技术的发展（ROW快照普及，硬件能力提升），使得采用存储快照做灾备成为一种潮流。Gartner指出，"2016年前，20%的企业(现有比例为7%)将仅采用快照和复制技术，摈弃传统的备份和恢复方法"。

但你知道如何规划快照吗？比如快照的间隔和数据变化量（需要复制的数据）不同的应用负载是否一样？快照越快快照的大小越大吗？

我以前考虑过这个问题，一直想了解各种应用的数据变化率。因为现在远程复制技术基本都是基于快照技术，经常被客户问，我这个ORACLE数据库采用阵列复制做灾备，大约需要多少带宽？我们只能说，It depends。因为这依赖你应用变化的数据量。

但是就算你知道数据的变化量，你就能够规划出带宽需求吗？因为快照是有间隔的，应用写的数据会被压缩，删除或者覆盖，不是1:1的情况。因此，很难给出相对准确的估算。

就算你用了洪荒之力，没有真实数据支撑，规划总是一件困难的事。

福利来了。大家知道，Nimble Storage的InfoSight是一款云维护平台，它有很多的客户真实运行数据（参见大数据分析揭示真实世界的应用负载，存储厂商和用户必看），可以做很多相关的分析。

今天，我们就来利用Nimble的数据科学家的最新分析成果，来看看不同负载的快照和数据变化率的一些对应关系，并且看如何应用到我们日常的快照灾备的方案规划中。

Nimble的数据科学家从超过8100个客户的环境中提取了7个典型应用负载相关的数据，得出了很多有意思的结论。

1、写负载如何影响快照大小

Nimble的数据科学家发现，虽然随着写入的数据量的增长，快照的大小也是增长的，但是快照相比写入数据量的相对百分比随着写入更多的数据而下降。比如，你写入10GiB的数据，典型的快照大小是1.4GiB，也就是14%的写入数据量。但如果你写入1000GiB的数据，快照大小平均是96GiB，也就是9.6%的数据写入量。这个其实不难理解，因为有些数据被删除和修改了。

Nimble的数据科学家还发现，快照大小和写入数据量的比例不同的应用负载差距还很大。写入同样的数据，Oralce，Virtual Desktop和Sharepoint有最大的快照大小而SQL Server和Exchange却有最小的快照大小。Oralce，Virtual Desktop和Sharepoint的快照大小和写入数据量基本是线性增长，但SQL Server和Exchange却随着写入数据量而比率快速下降。

这意味着针对Exchange和SQL Server快照，如果做一个大的快照要比做一堆小的快照来跟高效。比如你针对100GiB的写入量做一个快照，比针对10GiB写入量的做10个快照要节省很多空间。相反，Oracle, Sharepoint卷这种变化收效就不大。

因此，西瓜哥觉得，采用快照灾备的优化思路可以针对Exchange和SQL Serve这样的应用，尽量等数据量变化比较大再做快照。不过这样RPO太大，因此要综合考虑。但对于ORACLE来说，快照的大小和写入的数据量的比例基本不变，因此，可以做大量的小快照，取得比较好的RPO而不用担心浪费空间。

2、快照频度如何影响快照大小

Nimble的数据科学家还发现，快照的频度对快照大小的影响，不同负载差别非常大。

根据Nimble收集的用户数据，Virtual Desktop, Virtual Server和Exchange卷大概1小时产生01.-0.2GiB的增量数据，然而其他负载的卷1小时累计产生的数据增量不到0.05GB。如果延伸到1周来看，Virtual Desktop卷比其他负载产生4倍多的数据量。这是由于其近乎线性的变化率。ORACLE卷也是类似的情况，其1周的数据变化量仅次于Virtual Desktop卷。

针对这些特点，西瓜哥考虑的优化思路就是针对SQL SERVER，如果快照的频度尽量小一些，还是有比较大的空间节省，当然在满足RPO的前提下。但是对于ORACLE，这个节省就不明显，因此，不妨快照频度就高一些，这样获得比较低的RPO。

3、解开write/size的相互依赖

Nimble的数据科学家还研究了快照间隔和快照大小/写入数据的联系。总的来说，每写一次数据的快照大小随着快照间隔的增大而增大。在1个小时做一次快照的情况下，Exchange和SQL Server的快照大小是写入数据的1/4，然而其他应用接近1/5。

然而最有意思的是，File Server负载的快照大小/数据写入的比率几乎是一个常量0.22，和快照间隔无关。因此，你快照的频度做快一些，对于File Server负载来说，也不会带来更多的空间消耗。因此，如果这样的负载，不烦快照频度就调高一些，便于获得更好的RPO。

有了这些真实的数据支撑，可能对于我们举一反三还是有很多启发。但是，还是需要考虑到局限性。

1、这是基于Nimble存储的快照机制统计出来的，不同的存储实现快照的机理不同，因此这个结论可能在你的环境中不一定适用；

2、快照的频度其实和你设计的RPO目标密切相关，节省了空间，但满足不了RPO要求也是不行的；

3、快照的大小不仅仅影响存储的空间，更重要的是影响复制的带宽。现在的灾备系统，带宽的资源一般是最大的瓶颈。

不过，还是感谢Nimble的数据科学家，让我们了解不同负载卷快照的一些特征，相信还是有很多的共性，启发大家更加高效利用快照来实现灾备的目标。

标签：负载,快照,写入,Nimble,数据量,数据,灾备
来源： https://blog.51cto.com/u_15127583/2735086