在 Kubernetes 中导航 SQL Server 高可用性以提高性能 - DATAVERSITY

在 Kubernetes 中实现 SQL Server 高可用性以提高性能 – DATAVERSITY

时间戳记：30年2023月3日上午25:XNUMX
源节点： 2986079

SQL Server 不是 Kubernetes 容器化计划的最佳选择，这是有令人信服的理由的。 SQL Server 环境通常被描述为强大的实体，以其巨大的规模和消耗大量预算资源的趋势而闻名。 此外，SQL Server 环境：

  1. 保护组织最宝贵的数据资产，因此需要严格的安全措施。
  2. 提出关键的正常运行时间要求，促使需要计划内和计划外停机管理。
  3. 由于涉及多种操作系统和基础设施组件，因此带来了重大的管理挑战。

容器为增强组织内 SQL Server 的敏捷性、灵活性和成本效益以及其他优势提供了巨大的潜力。 然而，向 Kubernetes 中的容器化部署过渡的主要障碍是 SQL Server 工作负载对正常运行时间的严格要求。

Kubernetes 中的默认高可用性 (HA)

独立使用时， Kubernetes 结合了某些高可用性 (HA) 功能来保护容器化 SQL Server 工作负载。 这些内置功能包括 Pod 复制、负载平衡、服务发现、持久卷和 StatefulSet。 Kubernetes 利用这些功能来降低风险，例如：

  1. Pod 故障： 当个别 Pod 由于资源冲突或其他问题而崩溃时，就会发生这种情况。
  2. 节点故障： 当集群内的节点变得不可用（例如由于硬件故障）时，就会发生这种情况。
  3. 集群故障： 这与集群通信能力的丧失有关，例如控制平面节点的故障。

然而，这里必须区分用于管理关键 SQL Server 工作负载的 HA 解决方案和不适合该任务的 HA 解决方案。

Kubernetes 凭借其丰富的容器编排功能，在 IT 行业中释放了非凡的可能性。 然而，当用作独立的 HA 解决方案时，它不足以成为 SQL Server 工作负载的实用选择。 此限制主要源于与故障转移相关的固有延迟。 默认情况下，Kubernetes 需要五分钟时间来重新安排无法访问的节点的工作负载。 到 2023 年，这种故障转移基准对于 SQL Server 来说是远远不能接受的，特别是对于大型企业来说，SQL Server 停机可能会产生每秒数千美元的费用。 在故障转移期间满足最短五分钟的停机时间窗口是根本站不住脚的。

因此，虽然 Kubernetes 非常适合各种容器用例，但它缺乏自行处理 SQL Server HA 的功能。 庆幸的是，更广泛的 技术景观 拥有先进的集成解决方案，可最大程度地减少 SQL Server Kubernetes 部署中的停机时间。

寻求理想 SQL Server 容器 HA 解决方案的 IT 专业人员的 10 大必备功能

  1. 寻找具有良好记录的解决方案，最好有十多年的记录。
  1. 多元化的全球经验 - 理想情况下，是一个为全球客户群提供保护关键 SQL Server 环境的解决方案。
  1. 寻求一种解决方案，该解决方案从最初作为本机 SQL Server 实例的工具发展而来，融入尖端功能，专门设计用于在 Kubernetes 中实现 SQL Server 部署接近零的停机时间。
  1. 优先考虑通过在数据库级别引入运行状况监控和自动故障转移机制来增强 Kubernetes 集群管理的解决方案。 这些功能应该超越 Pod 级别管理的限制。
  1. 考虑将 Microsoft 等行业领导者认可的解决方案作为在 Kubernetes 内的 SQL Server 中启用 HA 的首选方法。
  1. 评估为 Kubernetes 中的 SQL Server 可用性组提供自动故障转移支持等功能的解决方案，从而提供关键工作负载所需的弹性。
  1. 选择能够跨不同站点、区域和云环境提供部署灵活性的解决方案，特别是当您有不同的基础设施需求时。
  1. 寻找通过 SDP 隧道等专有技术优化网络性能的解决方案。
  1. 请注意可显着减少故障转移时间、将中断时间从几分钟缩短到几秒钟的解决方案，从而确保服务不间断。
  1. 考虑提供简化部署选项的解决方案，例如与 Rancher 和 Helm 图表的兼容性，使实施更加简单。

底线：选择集成这些改进的解决方案来优化高可用性，即使在最具挑战性的 SQL Server 环境中也是如此。 此选择应该有助于通过容器实现 SQL Server 现代化的更加简化的流程，为您提供前所未有的成本控制、更高的敏捷性以及跨整个 IT 基础架构的增强的可移植性。

时间戳记：

更多来自 数据多样性