我们目前使用 VMWare ESX 5.5，并且主要运行 Win VM（一些 linux）。最大的 VM 是生产 SQL Server（SQL Server 2014，标准版）。
我们正在评估 DR 选项，看起来在 hyper-v 上的生活要简单得多，它具有本机 VM 复制。是的，我们知道 SAN 复制和所有其他美妙的音乐。但在管理程序级别执行此操作看起来完全简单。
因此，我们正在考虑从 VMWare 迁移到 hyper-v。
问题是：hyper-v 复制是 SQL Server 本身的可靠选择吗？
我们的想法是让 hyper-v 完成所有工作，并让生产 SQL Server 将其 tlog 推送到云存储。因此，如果我们需要在将虚拟机副本上线之前“赶上”它，我们可以应用日志。
SQL Server 数据库为 0.5-1.0 TB
迁移到SSD时，您是否保留RAID10？
我们有一个在大阵列中带有内部 SAS 磁盘的服务器：
16x600GB RAID 10
这为我们提供了约 4.6TB 的存储空间。它很快（这是 SQL Server）。
我们的 SQL 数据库是：
-- 600GB MDF -- 200+GB/天的日志文件 -- 大量事务性 -- 繁重的读写工作负载
我们正在寻求迁移到 SSD（出于通常的原因：速度、速度和性能）。我们希望使用写入密集型 400GB SSD。（他们似乎是最好的成本容量比）
我们认为在 SSD 上，对 RAID10 的需求较少（RAID10 的一个重要原因是提高吞吐量，但 SSD 本身就可以解决这个问题）。
带有旋转磁盘的 RAID5 是 SQL 的性能灾难（只有当磁盘非常昂贵时才有意义）。
在戴尔世界中，我们将使用“Write Intensive MLC”SSD。
但是对于SSD，有什么好的办法呢？
在所有情况下，我们都会在机箱中安装一两个热备用 SSD。
什么是合适的方法？
-- 我们知道 RAID10 是凯迪拉克 -- 我们更愿意减少设备数量（鉴于 SSD 解决了 RAID10 用来解决的性能问题） ---- 减少设备数量有助于美元方面，并且在扩展侧（使用更少的驱动器托架...）
但是，在 SSD 上使用 RAID5 会以某种方式惩罚我们吗？
-- 我们知道磁盘上的 RAID5 性能在一个驱动器死机时会变得很糟糕。-- 而且 RAID5 的写入性能很差：该命中来自 (a) 控制器（计算奇偶校验），还是 …
我们将调试和事务日志转储到MongoDB.
我们真的很喜欢，MongoDB因为：
但是有一个大问题MongoDB：索引必须适合物理 RAM。实际上，这将我们限制为 80-150 GB 的原始数据（我们目前在具有 16 GB RAM 的系统上运行）。
因此，对于我们拥有 500 GB 或 1 TB 的数据，我们需要 50 GB 或 80 GB 的 RAM。
是的，我知道这是可能的。我们可以添加服务器并使用MongoDB sharding. 我们可以购买一个特殊的服务器盒，它可以容纳 100 或 200 GB 的 RAM，但这是摇尾巴的狗！我们可以在硬件上花费 boucoup $$$ 来运行FOSS，当 SQL Server Express 可以在更少的硬件上处理更多的数据时Mongo（SQL Server 不满足我们的架构需求，或者我们会使用它！）我们不会花费巨额$ 在硬件上，因为它是必要的，只是因为Mongo架构，而不是因为固有的处理/存储需求。（还有分片？撇开成本不谈，谁需要三个、五个或更多服务器的持续复杂性来管理相对较小的负载？）
底线：MongoDB是FOSS，但我们必须在硬件上花费 $$$$$$$ 才能运行它？我们宁可购买商业软件！
我确定我们不是第一个遇到这个问题的人，所以我们问社区：
我们下一步要去哪里？
（我们已经运行了 Mongo v2）
我需要 IPTables，就像其他人一样，但我使用它的程度不足以真正保持我的知识完整和新鲜。
CentOS 中的设置实用程序太基础了。它似乎不允许我打开自定义端口，只是标准端口。
我需要一种基于文本的方式来打开防火墙中的自定义端口。我该怎么办？
我需要加密一个 200gb 的文件。
使用 7z，在相当快的 win2012 服务器上，将需要 12 小时（使用fastest选项）。
有没有更快的方法？