哈布尔的读者们大家好！ 本文的主题将是灾难恢复工具在AERODISK Engine存储系统中的实施。 最初，我们想在一篇文章中介绍这两种工具：复制和 MetroCluster，但不幸的是，文章太长，因此我们将文章分为两部分。 让我们从简单到复杂。 在本文中，我们将设置并测试同步复制 - 我们将删除一个数据中心，并断开数据中心之间的通信通道，看看会发生什么。
我们的客户经常问我们有关复制的各种问题，因此在继续设置和测试副本的实施之前，我们将告诉您一些关于存储中的复制是什么的信息。
有些理论
存储系统中的复制是同时确保多个存储系统上的数据同一性的连续过程。 从技术上讲，复制是通过两种方式完成的。
同步复制 – 这是将数据从主存储系统复制到备份系统，然后两个存储系统强制确认数据已被记录和确认。 经过双方（两个存储系统）确认后，数据才被视为已记录并可以使用。 这可确保参与副本的所有存储系统上的数据身份得到保证。
这种方法的优点：
- 所有存储系统上的数据始终相同
缺点：
- 解决方案成本高（快速通信通道、昂贵的光纤、长波收发器等）
- 距离限制（几十公里以内）
- 没有针对逻辑数据损坏的保护措施（如果数据在主存储系统上损坏（故意或意外），它会在备份系统上自动立即损坏，因为数据总是相同的（这就是悖论）
异步复制 – 这也是将数据从主存储系统复制到备份系统，但有一定的延迟，并且不需要另一侧确认写入。 数据记录到主存储系统后您可以立即使用，并且在备份存储系统上数据将在一段时间后可用。 当然，这种情况下数据的身份根本无法得到保证。 备份存储系统上的数据总是有点“过去”。
异步复制的优点：
- 低成本解决方案（任何通信通道，光学可选）
- 无距离限制
- 在备份存储系统上，如果主存储系统上的数据损坏（至少在一段时间内），数据不会恶化；如果数据损坏，您可以随时停止副本以防止备份存储系统上的数据损坏
缺点：
- 不同数据中心的数据总是不相同的
因此，复制模式的选择取决于业务目标。 如果备份数据中心包含与主数据中心完全相同的数据（即 RPO = 0 的业务要求）对您来说至关重要，那么您将不得不支付现金并忍受同步的限制复制品。 而如果数据状态的延迟是可以接受的或者根本就没有钱，那么你肯定需要使用异步方法。
我们还单独强调这样一种模式（更准确地说，是一种拓扑），即城域集群。 在城域集群模式下，使用同步复制，但与常规副本不同的是，城域集群允许两个存储系统在活动模式下运行。 那些。 活动数据中心和备用数据中心之间没有分离。 应用程序同时与两个存储系统一起工作，这两个存储系统物理上位于不同的数据中心。 这种拓扑中发生事故时的停机时间非常短（RTO，通常是几分钟）。 在本文中，我们不会考虑 Metrocluster 的实现，因为这是一个非常庞大且广泛的主题，因此我们将在下一篇文章中专门讨论它，作为本文的延续。
另外，很多时候，当我们谈论使用存储系统进行复制时，很多人都会有一个合理的问题：>“许多应用程序都有自己的复制工具，为什么要在存储系统上使用复制？ 是好还是坏？
这里没有明确的答案，所以这里是赞成和反对的论点：
存储复制的参数：
- 解决方案的简单性。 使用一种工具，您可以复制整个数据集，无论负载类型和应用程序如何。 如果您使用应用程序的副本，则必须单独配置每个应用程序。 如果它们的数量超过 2 个，那么这将是极其耗费人力和成本的（应用程序复制通常需要为每个应用程序提供单独的且非免费的许可证。更多信息请参见下文）。
- 您可以复制任何内容 - 任何应用程序、任何数据 - 并且它将始终保持一致。 许多（大多数）应用程序不具备复制功能，来自存储系统的副本是提供灾难保护的唯一方法。
- 无需为应用程序复制功能支付过多费用。 一般来说，它并不便宜，就像存储系统副本的许可证一样。 但存储复制的License需要支付一次费用，并且应用副本的License需要为每个应用单独购买。 如果有很多这样的应用程序，那么它的成本就相当可观，并且存储复制的许可证成本就变成九牛一毛了。
反对存储复制的争论：
- 从应用程序本身的角度来看，通过应用程序进行副本具有更多功能，应用程序更好地了解其数据（显然），因此有更多使用它们的选项。
- 如果使用第三方工具完成复制，某些应用程序的制造商不保证其数据的一致性。 *
* - 有争议的论文。 例如，一家知名的DBMS制造商很长一段时间以来都官方宣称，他们的DBMS只能使用他们的手段正常复制，其余的复制（包括存储系统）都是“不真实的”。 但生活表明事实并非如此。 最有可能（但不确定）这根本不是向客户出售更多许可证的最诚实的尝试。
因此，在大多数情况下，从存储系统进行复制更好，因为这是一个更简单且更便宜的选项，但在需要特定应用程序功能的复杂情况下，并且有必要使用应用程序级复制。
理论讲完了，现在开始实践
我们将在实验室中配置副本。 在实验室条件下，我们模拟了两个数据中心（实际上，两个相邻的机架似乎位于不同的建筑物中）。 该展台由两个Engine N2存储系统组成，两个系统通过光缆相互连接。 运行 Windows Server 2016 的物理服务器使用 10Gb 以太网连接到两个存储系统。 展台很简单，但这并没有改变本质。
示意性地看起来像这样：
从逻辑上讲，复制的组织方式如下：
现在让我们看看我们现在拥有的复制功能。
支持两种模式：异步和同步。 同步模式受到距离和通信信道的限制是合乎逻辑的。 特别是，同步模式需要使用光纤作为物理和 10 Gigabit 以太网（或更高）。
支持同步复制距离40公里，数据中心间光通道时延值最大2毫秒。 一般来说，它会在很大的延迟下工作，但在记录过程中会出现严重的减速（这也是合乎逻辑的），因此如果您计划在数据中心之间进行同步复制，您应该检查光学质量和延迟。
对于异步复制的要求并不是那么严格。 更准确地说，他们根本不存在。 任何可用的以太网连接都可以。
目前，AERODISK ENGINE 存储系统支持通过以太网协议（通过铜缆或光纤）进行块设备 (LUN) 复制。 对于需要通过光纤通道上的 SAN 结构进行复制的项目，我们目前正在添加适当的解决方案，但尚未准备就绪，因此在我们的案例中，仅使用以太网。
复制可以在任何 ENGINE 系列存储系统（N1、N2、N4）之间进行，从初级系统到旧系统，反之亦然。
两种复制模式的功能完全相同。 以下是有关可用内容的更多详细信息：
- 复制“一对一”或“一对一”，即具有主备两个数据中心的经典版本
- 复制是“一对多”或“一对多”，即一个LUN可以同时复制到多个存储系统
- 分别激活、停用和“反向”复制，以启用、禁用或更改复制方向
- 复制可用于 RDG（Raid 分布式组）和 DDP（动态磁盘池）池。 但是，RDG 池的 LUN 只能复制到另一个 RDG。 与DDP相同。
还有很多小功能，但没有特别列出它们；我们将在设置时提及它们。
设置复制
设置过程非常简单，由三个阶段组成。
- 网络设置
- 存储设置
- 设置规则（连接）和映射
设置复制的一个重要点是，前两个阶段应在远程存储系统上重复，第三阶段仅在主存储系统上重复。
设置网络资源
第一步是配置传输复制流量的网络端口。 为此，您需要启用端口并在前端适配器部分设置其 IP 地址。
之后，我们需要创建一个池（在我们的例子中为 RDG）和一个用于复制的虚拟 IP (VIP)。 VIP 是一个浮动 IP 地址，与存储控制器的两个“物理”地址（我们刚刚配置的端口）绑定。 这将是主复制界面。 如果您需要处理标记流量，您也可以不使用 VIP，而是使用 VLAN 进行操作。
为副本创建 VIP 的过程与为 I/O（NFS、SMB、iSCSI）创建 VIP 没有太大区别。 在这种情况下，我们创建一个常规 VIP（没有 VLAN），但一定要表明它是用于复制的（没有这个指针，我们将无法在下一步中将 VIP 添加到规则中）。
VIP 必须与其浮动的 IP 端口位于同一子网中。
我们在远程存储系统上重复这些设置，当然使用不同的 IP。
来自不同存储系统的VIP可以位于不同的子网中，最主要的是它们之间有路由。 在我们的示例中，准确显示了此示例（192.168.3.XX 和 192.168.2.XX）
这样就完成了网络部分的准备工作。
设置存储
为副本设置存储与平常的不同之处仅在于我们通过特殊菜单“复制映射”进行映射。 否则一切都与正常设置相同。 现在，按顺序。
在之前创建的池R02中，需要创建LUN。 我们来创建它并将其命名为 LUN1。
我们还需要在相同大小的远程存储系统上创建相同的LUN。 我们创造。 为了避免混淆，我们将远程 LUN 称为 LUN1R
如果我们需要使用一个已经存在的 LUN，那么在设置副本时，我们需要从主机上卸载这个生产性 LUN，然后在远程存储系统上创建一个相同大小的空 LUN。
存储设置已完成，让我们继续创建复制规则。
设置复制规则或复制链接
在存储系统（目前将作为主存储系统）上创建 LUN 后，我们将存储系统 1 上的复制规则 LUN1 配置为存储系统 1 上的 LUN2R。
在“远程复制”菜单中进行设置
让我们创建一个规则。 为此，您需要指定副本的收件人。 在那里我们还设置连接的名称和复制类型（同步或异步）。
在“远程系统”字段中，我们添加存储系统2。 要添加，您需要使用管理 IP 存储系统 (MGR) 以及我们将在其中执行复制的远程 LUN 的名称（在我们的示例中为 LUN1R）。 仅在添加连接阶段才需要控制 IP；复制流量不会通过它们传输；之前配置的 VIP 将用于此目的。
在此阶段，我们可以为“一对多”拓扑添加多个远程系统：单击“添加节点”按钮，如下图所示。
在我们的例子中，只有一个远程系统，因此我们仅限于此。
规则已经准备好了。 请注意，它会自动添加到所有复制参与者上（在我们的例子中有两个）。 您可以为任意数量的 LUN 和任意方向创建任意数量的此类规则。 例如，为了平衡负载，我们可以将存储系统1的部分LUN复制到存储系统2，而将另一部分LUN从存储系统2复制到存储系统1。
存储系统1. 创建后，同步立即开始。
存储系统2. 我们看到相同的规则，但同步已经结束。
存储系统1上的LUN1处于Primary角色，即处于活动状态。 存储系统1上的LUN2R处于Secondary角色，即在存储系统1发生故障时处于备用状态。
现在我们可以将 LUN 连接到主机。
我们将通过 iSCSI 连接，尽管也可以通过 FC 完成。 在副本中通过 iSCSI LUN 设置映射实际上与通常的场景没有什么不同，因此我们在此不详细考虑这一点。 如果有的话，这个过程在文章““。
唯一的区别是我们在“复制映射”菜单中创建映射
我们设置映射并将 LUN 提供给主机。 主机看到了 LUN。
我们将其格式化为本地文件系统。
就这样，设置完成了。 接下来将进行测试。
测试
我们将测试三个主要场景。
- 定期角色切换次要 > 主要。 需要定期进行角色切换，例如，我们需要在主数据中心执行一些预防性操作，在此期间，为了使数据可用，我们将负载转移到备份数据中心。
- 紧急角色切换辅助>主（数据中心故障）。 这是复制存在的主要场景，它可以帮助在数据中心完全故障时幸存下来，而无需使公司长时间停顿。
- 数据中心之间的通信通道中断。 在由于某种原因数据中心之间的通信通道不可用的情况下检查两个存储系统的正确行为（例如，挖掘机在错误的位置挖掘并损坏了暗光学器件）。
首先，我们将开始将数据写入 LUN（使用随机数据写入文件）。 我们立即看到存储系统之间的通信通道正在被利用。 如果您打开负责复制的端口的负载监控，这很容易理解。
现在两个存储系统都有“有用”的数据，我们可以开始测试了。
以防万一，让我们看一下其中一个文件的哈希和并将其写下来。
定期角色切换
切换角色的操作（更改复制方向）可以在任何存储系统上完成，但您仍然需要同时访问这两个系统，因为您需要在主存储系统上禁用映射，并在辅助存储系统（将成为主存储系统）上启用它。 ）。
也许现在出现了一个合理的问题：为什么不将其自动化？ 答案是：很简单，复制是一种简单的灾难恢复手段，完全基于手动操作。 为了自动化这些操作，有一个 Metrocluster 模式；它是完全自动化的，但其配置要复杂得多。 我们将在下一篇文章中介绍如何设置 Metrocluster。
在主存储系统上，我们禁用映射以确保记录停止。
然后在“远程复制”菜单中的其中一个存储系统（无论是主存储系统还是备份存储系统）上，选择我们的连接 REPL1 并单击“更改角色”。
几秒钟后，LUN1R（备份存储系统）成为主存储系统。
我们将 LUN1R 映射到存储系统 2。
此后，我们的 E: 驱动器会自动连接到主机，只是这次它是从 LUN1R“到达”的。
为了以防万一，我们比较哈希值。
同样。 考试通过了。
故障转移。 数据中心故障
此时，定期切换后的主存储系统分别为存储系统2和LUN1R。 为了模拟事故，我们将关闭两个存储控制器2上的电源。
无法再访问它。
让我们看看存储系统 1（目前是备份系统）上发生了什么。
我们看到主 LUN (LUN1R) 不可用。 日志、信息面板以及复制规则本身中均出现错误消息。 因此，来自主机的数据当前不可用。
将 LUN1 的角色更改为主 LUNXNUMX。
我正在映射到主机。
确保驱动器 E 出现在主机上。
我们检查哈希值。
一切安好。 该存储系统成功地在活跃的数据中心倒塌后幸存下来。 我们连接复制“反转”以及从备份数据中心连接 LUN 所花费的时间大约为 3 分钟。 很明显，在实际生产中，一切都要复杂得多，除了存储系统的操作之外，您还需要在网络、主机和应用程序中执行更多操作。 而在生活中这段时间会更长。
在这里我想写的是，一切，测试已经成功完成，但我们不要着急。 主存储系统正在“躺着”，我们知道当它“倒下”时，它处于Primary角色。 如果突然亮起会发生什么情况？ 会有两个Primary角色，这等于数据损坏吗？ 我们现在检查一下。
让我们突然打开底层存储系统。
它会加载几分钟，然后在短暂同步后返回服务，但扮演辅助角色。
一切都好。 裂脑并没有发生。 我们考虑过这一点，并且总是在跌倒后，存储系统会上升到辅助角色，无论它“在生命期间”扮演什么角色。 现在我们可以肯定地说数据中心故障测试是成功的。
数据中心之间的通信通道故障
此测试的主要任务是确保存储系统在两个存储系统之间暂时失去通信通道然后再次出现时不会出现异常行为。
所以。 我们断开存储系统之间的电线（假设它们是由挖掘机挖掘的）。
在 Primary 上，我们看到与 secondary 没有任何联系。
在次要节点上，我们看到与主要节点没有任何联系。
一切正常，我们继续向主存储系统写入数据，即保证它们与备份的不同，即它们已经“分离”了。
几分钟后我们就“修复”了沟通渠道。 一旦存储系统相互看到，就会自动激活数据同步。 这里不需要管理员做任何事情。
一段时间后，同步完成。
连接恢复，通讯通道丢失没有造成任何紧急情况，开机后自动同步。
发现
我们分析了理论——需要什么、为什么、优点和缺点在哪里。 然后我们在两个存储系统之间设置同步复制。
接下来，对正常切换、数据中心故障和通信通道故障进行了基础测试。 在所有情况下，存储系统都运行良好。 对于手动场景，不会出现数据丢失，并且管理操作也保持在最低限度。
下次我们将使情况复杂化，并展示所有这些逻辑如何在主动-主动模式下的自动化城域集群中工作，也就是说，当两个存储系统都是主存储系统时，并且存储系统故障时的行为是完全自动化的。
请写下评论，我们很高兴收到合理的批评和实用的建议。
直到下一次
来源： habr.com