我有一个长期目标，即在某个地方的托管数据中心建立一个 DR 站点，该计划的一部分包括复制我的 EqualLogic SAN 的一些卷。我做这件事有点困难，因为我不知道我的方法是否合理。
为了完整性，这篇文章可能会有点长。
一般相关信息：
- 我有一台 EqualLogic PS4000X (~4TB)。
- SAN 充当 vSphere 5 环境中 2 个 ESXi 主机的共享存储。
- 我有 4 个卷，每个卷 500GB。卷 1 和卷 2 包含我的“第 1 层”虚拟机。这些将是我计划复制的唯一卷。
- 由于我们的 PRI（语音），目前拥有 3Mb/s 的连接，实际数据带宽约为 2.8Mb/s。
我测量体积变化的方法：
戴尔的一位代表告诉我，估算卷中的增量的一种方法（也许不是最好的？）是测量在常规快照计划的一段时间内使用的快照保留空间。
我对此的第一个实验是创建一个快照间隔 15 分钟的计划，快照保留量为 500GB。我让它运行一整夜，直到第二天 COB。我不记得 500GB 中可以保存多少个快照，但最终平均每个快照约 15GB。
$average_snapshot_delta = $snapshot_reserve_used / $number_of_snapshots
然后我将快照间隔改为 60 分钟，这样经过整整 24 小时后，500GB 中总共有 13 个快照。这样我每小时就有 ~37GB（或每 15 分钟 ~9GB）。
问题：
这些数字对我来说简直是天文数字。凭借我的带宽，我每小时可以达到 1GB 多一点，利用率达到 100%。块级复制真的这么贵吗？还是我做错了什么？
答案1
您的数字归结为 10.24 MB/s，对于纯写入来说，这似乎有点偏高。但是，我不知道您的工作负载。
但是，你有一个更大的问题。初始复制将以 3MB/s 的速度复制 1TB 的数据。
1TB = 1024GB = 1,048,576 MB
2.8 MB/s replication speed
~4.33 days
在此期间，它会将您的净更改排队，以待初始同步完成。如果您需要从远程阵列提取数据，则需要 4.33 天才能完全启动并运行（除非您使用带外数据传输方法，例如 FedEx 隔夜送货或卡车）。
至于 15 分钟快照和 60 分钟快照之间的净变化差异，我相信 60 分钟快照受益于大量写入合并。或者换句话说，所有对文件系统日志的写入都在较长的快照中合并，而 15 分钟快照中合并的次数较少。
这就是同步模式真正发挥作用的地方。3MB/s 的管道对于同步复制来说严重不足。批量异步复制将获得写入合并的一些好处，因此总传输量会降低，但代价是在灾难中丢失一些数据。不幸的是，我对 Equilogic 不够熟悉，不知道它能做什么
答案2
我认为这是 equallogic 最大的缺点。复制基于快照，而其快照技术效率极低。
我们的环境中运行着大约 25 个阵列，我的目标是在 2-3 年内用 netapp 替换它们。根据我们在 netapp cif 文件器上看到的情况以及对 nfs 的测试，复制带宽和快照空间将减少 80%。再加上 netapp 的重复数据删除功能，效率会更高。
确保将您的 Windows 页面文件和 VMware 交换文件放在非复制卷上。
另外 - 如果您负担得起，请考虑添加一些 riverbed wan 优化器。它们将减少 wan 上用于复制的数据量约 60%。它为我们节省了成本，并且我们的最低 ds3 wan 连接数最高可达 oc-3。
您还没有提到延迟是多少。它是复制计算中的关键组成部分。
答案3
如果您的虚拟机没有将页面文件放在单独的数据存储中，则应尝试将它们移动到一个数据存储中，然后重新测量数据变化率（数据流失）。这肯定会有所帮助。不要复制超过需要的内容。
EQL 是否支持连续异步复制或由快照计划驱动？您可以全天候使用整个 3Mb 吗？
我也赞同在将阵列放置在远程站点之前同步阵列的建议。
答案4
我目前正在进行类似的事情，但是使用 Solaris 11 和 zfs 作为我们的 san 后端。由于带宽问题，我决定将大部分组件分离出来。我们迁移到 exchange 2010，以便我们可以使用相同的副本设置我们的 dr 站点。我发现，由于您看到的带宽问题，对这些数据进行 san 级快照是荒谬的。我们决定在 exchange 本身内设置 dag 和复制会更便宜、更高效。我们也对我们的 mysql 服务器做了同样的事情。我们现在克隆的是快照之间增量较少的系统。我能够在办公室进行初始同步并将其传输到最终目的地。