MetroCluster概述和架构
在MetroCluster环境中部署Microsoft SQL Server需要对MetroCluster系统的物理设计进行一些说明。
MetroCluster会在位于不同位置或故障域的两个ONTAP集群之间同步镜像数据和配置。MetroCluster通过自动管理两个目标为应用程序提供持续可用的存储:
-
通过同步镜像写入集群的数据实现零恢复点目标(RPO)。
-
通过镜像配置和自动访问第二个站点的数据、实现近乎为零的恢复时间目标(Recovery Time目标、RTO)。
MetroCluster通过在两个站点中的两个独立集群之间自动镜像数据和配置来简化操作。由于存储是在一个集群中配置的,因此它会自动镜像到第二个站点的第二个集群。NetApp SyncMirror®提供所有数据的完整副本,并且没有RPO。这意味着、一个站点的工作负载可以随时切换到另一个站点、并继续提供数据、而不会丢失数据。MetroCluster负责管理切换过程、以便能够访问第二个站点上NAS和SAN配置的数据。将MetroCluster设计为经验证的解决方案、其中包括规模估算和配置、可在协议超时期限内或更短时间(通常少于120秒)执行切换。这样、RPO几乎为零、应用程序可以继续访问数据、而不会发生故障。MetroCluster可通过后端存储网络结构定义的多种变体提供。
MetroCluster可用于3种不同的配置
-
具有IP连接的HA对
-
具有FC连接的HA对
-
具有FC连接的单个控制器
术语"连接"是指用于跨站点复制的集群连接。它不是指主机协议。无论用于集群间通信的连接类型如何、MetroCluster配置均支持所有主机端协议。 |
MetroCluster IP
HA对MetroCluster IP配置会在每个站点上使用两个或四个节点。与双节点选项相比、此配置选项会增加复杂性和成本、但它具有一个重要优势:站点内冗余。简单的控制器故障不需要通过WAN访问数据。数据访问仍通过备用本地控制器保持在本地。
大多数客户选择IP连接是因为基础架构要求更简单。过去、使用暗光纤和FC交换机配置高速跨站点连接通常比较容易、但如今、高速、低延迟IP电路更容易获得。
此外、该架构也更加简单、因为只有跨站点连接用于控制器。在FC SAN连接的MetroCluster中、控制器会直接写入另一站点上的驱动器、因此需要更多的SAN连接、交换机和网桥。相反、IP配置中的控制器会通过控制器写入相对的驱动器。
对于追加信息、请参阅ONTAP官方文档和 "MetroCluster IP 解决方案架构和设计"。
HA对FC SAN连接的MetroCluster
HA对MetroCluster FC配置会在每个站点上使用两个或四个节点。与双节点选项相比、此配置选项会增加复杂性和成本、但它具有一个重要优势:站点内冗余。简单的控制器故障不需要通过WAN访问数据。数据访问仍通过备用本地控制器保持在本地。
某些多站点基础架构不是为主动-主动操作而设计的、而是更多地用作主站点和灾难恢复站点。在这种情况下、通常最好使用HA对MetroCluster选项、原因如下:
-
尽管双节点MetroCluster集群是一个HA系统、但控制器意外故障或计划内维护要求数据服务必须在相反站点联机。如果站点之间的网络连接无法支持所需的带宽、则性能会受到影响。唯一的选择是同时将各种主机操作系统和相关服务故障转移到备用站点。HA对MetroCluster集群可消除此问题、因为丢失控制器会导致在同一站点内进行简单的故障转移。
-
某些网络拓扑不是为跨站点访问而设计的、而是使用不同的子网或隔离的FC SAN。在这些情况下、双节点MetroCluster集群将不再充当HA系统、因为备用控制器无法向对面站点上的服务器提供数据。要提供完全冗余、需要使用高可用性对MetroCluster选项。
-
如果将双站点基础架构视为一个高可用性基础架构、则适合使用双节点MetroCluster配置。但是、如果系统在站点发生故障后必须长时间运行、则首选HA对、因为它会继续在单个站点中提供HA。
双节点FC SAN连接MetroCluster
双节点MetroCluster配置仅为每个站点使用一个节点。这种设计比HA对选项更简单、因为需要配置和维护的组件更少。此外、它还降低了布线和FC交换方面的基础架构需求。最后、它还可以降低成本。
这种设计的明显影响是、单个站点上的控制器故障意味着数据可以从另一个站点访问。这种限制不一定是问题。许多企业都拥有多站点数据中心运营、并采用延伸型高速低延迟网络、这些网络本质上充当一个基础架构。在这些情况下、首选配置是双节点版本的MetroCluster。目前、多家服务提供商以PB级的规模使用双节点系统。
MetroCluster故障恢复能力功能
MetroCluster 解决方案 中没有单点故障:
-
每个控制器都有两条通往本地站点上的驱动器架的独立路径。
-
每个控制器都有两条通往远程站点上驱动器架的独立路径。
-
每个控制器都有两条独立的路径连接到另一站点上的控制器。
-
在HA对配置中、每个控制器都有两个指向其本地配对节点的路径。
总之、可以删除配置中的任何一个组件、而不会影响MetroCluster提供数据的能力。这两个选项在故障恢复能力方面的唯一区别是、发生站点故障后、HA对版本仍然是整体HA存储系统。
SyncMirror
使用MetroCluster保护SQL Server以SyncMirror为基础、该技术可提供最高性能的横向扩展同步镜像技术。
利用SyncMirror实现数据保护
最简单的一个层面是、同步复制意味着、在确认镜像存储之前、必须对镜像存储的两端进行任何更改。例如、如果数据库正在写入日志、或者VMware子系统正在修补、则写入操作绝不能丢失。作为协议级别、在将写入提交到两个站点上的非易失性介质之前、存储系统不得确认写入。只有这样、才能安全地继续操作、而不会丢失数据。
使用同步复制技术是设计和管理同步复制解决方案的第一步。最重要的注意事项是了解在各种计划内和计划外故障情形下可能发生的情况。并非所有同步复制解决方案都能提供相同的功能。如果您需要的解决方案能够实现零恢复点目标(RPO)、即零数据丢失、则必须考虑所有故障情形。特别是、如果由于站点间连接断开而无法进行复制、则会产生什么预期结果?
SyncMirror数据可用性
MetroCluster复制基于NetApp SyncMirror技术、该技术旨在高效地切换至同步模式和切换至同步模式之外。此功能可满足需要同步复制、但也需要数据服务高可用性的客户的要求。例如、如果与远程站点的连接断开、则通常最好让存储系统继续在未复制的状态下运行。
许多同步复制解决方案只能在同步模式下运行。这种类型的全或全不复制有时称为Domino模式。此类存储系统将停止提供数据、而不是允许本地和远程数据副本处于不同步状态。如果强制中断复制、重新同步可能会非常耗时、并且可能会使客户在重新建立镜像期间完全丢失数据。
SyncMirror不仅可以在无法访问远程站点时无缝切换出同步模式、还可以在恢复连接后快速重新同步到RPO = 0状态。远程站点上的陈旧数据副本也可以在重新同步期间保留在可用状态、从而确保本地和远程数据副本始终存在。
如果需要Domino模式、则NetApp提供SnapMirror同步(SM-S)。此外、还存在应用程序级选项、例如Oracle DataGuard或SQL Server Always On可用性组。可以选择操作系统级磁盘镜像。有关追加信息和选项、请咨询您的NetApp或合作伙伴客户团队。