我有一个长期的目标，就是在某个地方build立灾难恢复站点，其中一部分包括复制一些EqualLogic SAN。 我有一个困难的时候这样做，因为我不知道我的方法是否健全。
为了完整起见，这篇文章可能有点冗长。
戴尔代表告诉我，估计卷中增量的一种方法（可能不是最好的方法）是测量在定期快照时间表的一段时间内使用的快照储备空间。
我的第一个实验是创build快照之间15分钟的时间表，快照储备为500GB。 我让这个过夜，直到第二天的COB。 我不记得可以保存在500GB的快照数量，但是我最终平均每个快照大约15GB。
$average_snapshot_delta = $snapshot_reserve_used / $number_of_snapshots 然后，我将快照时间间隔改为60分钟，在完整的24小时后，共有13个500GB的快照。 这使我每小时约37GB（或每15分钟约9GB）。
这些数字对我来说是天文数字。 有了我的带宽，我可以在100％利用率的情况下做到超过1GB /小时。 是块级复制这昂贵还是我做一些完全错误的东西？
你的数字归结为10.24 MB / s，这似乎有点纯粹写的高端。 但是，我不知道你的工作量。
但是，你有一个更大的问题。 最初的复制将在3MB / s的吸pipe上复制1TB的数据。
1TB = 1024GB = 1,048,576 MB 2.8 MB/s replication speed ~4.33 days
在这段时间内，当初始同步完成时，它将排队等待你的networking更新。 如果您需要从远程arrays中获取数据，则需要等待4.33天，直到您完全启动并运行（除非您有一个带外数据传输方法，例如FedEx隔夜邮递或卡车）。
至于你的15分钟快照和60分钟快照之间的净变化的差异，我相信60分钟快照正在得到很多写入组合的好处。 换句话说，所有这些写入文件系统日志的文件都会在较长的快照中合并，而不是像15分钟那样快。
这是同步模式真正进入自己的地方。 一个3MB / s的pipe道在同步复制方面被严重地忽略了。 批量asynchronous复制将获得写入组合的一些好处，从而降低总体传输量，但要以在灾难中丢失一些数据为代价。 不幸的是，我对Equilogic知之甚less
这是我认为最大的反对意见。 复制基于快照，其快照技术难以置信地无效。
我们在我们的环境中运行了大约25个arrays，我的2-3年目标是用netapp代替它们。 根据我们在netapp cif文件系统上看到的和nfs的testing，复制带宽和快照空间将减less80％。 增加了netapp的重复数据删除function，效率更高。
确保把你的Windows页面文件和你的vmware交换文件放在一个非复制的卷上。
另外 – 如果你能负担得起，看看增加一些河床湾优化。 他们会将您的复制数据量减less60％左右。 它拯救了我们，我们有最less的三个连接到oc-3。
你也没有提到你的延迟是什么。 这是复制计算中的关键组件。
如果您的虚拟机在单独的数据存储上没有他们的页面文件，您应该尝试将它们移动到一个，然后重新测量您的数据更改速率（数据stream失）。 这一定会有所帮助。 不要复制超过你的需要。
EQL是否支持连续的asynchronous复制或由快照计划驱动？ 你能用整个3Mb 24/7吗？
我也第二次build议您在将远程站点放在远程站点之前同步数组。
为了关注最相关的信息，我build议定义一个恢复点和恢复时间的目标。 这些被无意识地称为“RPO”和“RTO”。 磁盘复制应该通过保持崩溃一致的副本数据在另一个站点上永远不会超过几分钟来减less它们。一旦你有了这些数字，你就可以定义一些事情，比如你需要多长时间一次崩溃一致的副本。
3Mb / s可能不会削减芥子酱，除非您使用广域网加速（例如其他答复者提到的Riverbed）。 WAN加速通过在链接的两侧保存磁盘上的caching来实现，它们存储您发送的所有最新数据，并且如果发送重复数据块，则会发送引用而不是数据。
也就是说，假设您的存储使用相同的引擎来拍摄快照，因为它用于复制快照，那么最准确的度量变化确实是快照储备。 尽pipe如此，您仍然需要在测量期间保持一个快照和保留的隔离。 假设EqualLogic在写入快照上使用拷贝，比较来自全天拍摄的多个快照的保留数据可能实际上使得您的数据看起来好像比实际情况更多。
至于数据本身，我同意build议不复制交换文件的答复。 交换文件可能需要大量的磁盘，并且总是在变化，这将触发大量的复制stream量。 我不知道VMWare是否支持没有它们的环境的复制，尽pipe…我假设在没有交换文件的情况下复制的虚拟机数据存储中的虚拟机将会崩溃一致，但是我不能确认我自己。
我目前正在处理类似的事情，但是Solaris 11和zfs作为我们的后端。 由于带宽，我决定分离出大部分组件。 我们迁移到2010年交换，以便我们可以build立一个相同的副本我们的博士网站。 我发现做san级别的快照对于这个数据是荒谬的，因为带宽问题就像你看到的一样。 我们决定在交易所内部设立一个dag和复制它会更便宜和更有效率。 我们也对我们的mysql服务器做了同样的事情。 我们现在克隆的是快照之间less量变化的系统。 我能够在办公室进行初步同步，并将其运送至最终目的地。
在Equallogic SAN上，块大小为16 Mo，用于快照和复制。 这就是为什么你有这些天文数字。 没办法改变这一点。 我们满足RTO / RPO SLA的解决scheme是在两个站点之间安装Riverbed WAN优化设备。