如何在Linux环境中为SQL Server提供高可用性

如果您的组织在Linux上运行关键业务的Microsoft SQL Server，那么您的IT团队无疑会知道持续保持高可用性，性能和安全性是多么困难。特别困难的是如何通过健壮的复制和自动故障转移来确保高可用性。使用开源软件和易于配置的HA SANless群集解决方案可以提供一种更简单的维护方法，而无需牺牲组织所需的安全性和性能。

Linux的有限高可用性选项

大多数Linux发行版为IT部门提供了两个次等的高可用性选择：要么为SQL Server Enterprise Edition支付更多费用以实施“始终在线”可用性组，要么努力使复杂的“自己动手做”的HA Linux配置正常工作-这可能是异常的很难做到。

使用企业版的问题在于，它破坏了在商品硬件上使用开源操作系统的节省成本的策略。对于数量有限的小型SQL Server应用程序，可能有理由证明其额外费用。但是对于许多数据库应用程序来说，它太昂贵了，无法为Linux提供通用的HA。

使用开源软件（例如Pacemaker和Corosync或SUSE Linux Enterprise High Availability Extension），可以跨Linux环境中运行的所有应用程序提供HA。但是要使完整的软件堆栈正常工作，需要为每个应用程序创建（和测试）自定义脚本，并且即使对所使用的任何软件或硬件进行了很小的更改，这些脚本通常也需要重新测试和更新。SQL Server Standard Edition和Linux不支持的与可用性相关的功能会使这项工作更具挑战性。

在Linux中寻找SQL Server的替代高可用性解决方案

为了使HA具有成本效益并且易于实施，您可能需要考虑两种不同的通用方法。

一种是使用基于存储的系统，该系统通过在冗余且有弹性的存储区域网络（SAN）中复制数据来保护数据。对于主机操作系统而言，这种方法是不可知的，但是它要求从单个供应商处购买整个SAN基础架构，并依靠单独的故障转移规定来提供高可用性。

另一种方法是基于主机的，涉及跨Linux服务器实例创建与存储无关的SANless集群。作为HA覆盖，这些群集能够在私有，公共和混合云中跨LAN和WAN运行。该覆盖图也与应用程序无关，使组织可以在所有应用程序中使用一个通用的HA解决方案。尽管这种方法确实消耗了主机资源，但是它们相对便宜并且在Linux环境中易于扩展。

大多数HA SANless群集选件提供了实时块级数据复制，连续应用程序监视以及可配置的故障转移/故障回复恢复策略的组合，以保护所有关键业务应用程序，包括那些使用标准版中始终启用故障转移群集实例的应用程序SQL Server。

SIOS Technology Corp.为Linux提供了更强大的HA SANless集群解决方案，这些解决方案具有高级功能，旨在使IT人员摆脱支持和优化计算基础架构的复杂性和日常挑战。具有LifeKeeper的SIOS Protection Suite解决方案提供：

• 持续监控整个Linux应用程序堆栈
• 借助其应用程序恢复工具包（ARK）进行全面的应用程序保护，可对复杂的应用程序和数据库进行快速，安全的恢复或故障转移
• 向导驱动的Linux群集设置
• 配置灵活性，例如使用传统的共享存储群集或软件在无SAN群集配置中同步本地存储

例如，无SAN群集可以处理两个并发故障。在LAN和WAN以及私有，公共和混合云中，基本操作是相同的。

在典型的两节点群集服务器中，＃1最初是将数据复制到服务器＃的主服务器。它遇到问题，自动触发故障转移到服务器＃2，该服务器现已成为主要服务器。

在这种情况下，IT部门可能会开始诊断和修复导致＃1服务器故障的任何问题。固定后，它可以接管主要服务器或服务器＃2继续以这种能力将数据复制到服务器＃1。

使用大多数HA SANless群集配置，故障转移是自动的，并且故障转移和故障回复都可以通过基于浏览器的控制台进行控制。

有关SIOS LifeKeeper和Protection Suite解决方案的更多信息，请访问用于群集服务器环境的SIOS SAN和SANless高可用性群集。

经SIOS许可转载

通过SIOS AppKeeper Monitoring消除* Apache Web服务器停机

如今，Apache Web服务器是Internet上最受欢迎的Web服务器。  公司正在使用Amazon AWS，Microsoft Azure和Google Cloud Platform等云平台部署基于Apache构建的关键任务，面向客户的应用程序。  因此，您可以打赌他们正在投入大量时间和金钱来监视那些应用程序并试图减少停机时间。但是，如果我们告诉您，当Apache Web服务器停机时，可以通过自动监视和重新启动应用程序来消除手动干预的需要怎么办？

在探讨如何做到这一点之前，让我们先回顾一下，看看公司在监视和管理其Apache Web服务器以及这些关键应用程序方面的选择。

如何监视和保护Apache Web服务器免受不必要的停机

任何使用Apache Web服务器部署应用程序的人都在考虑监视其Web服务器本身的运行状况，或者将该任务外包给第三方。

在监视运行在Amazon Web Services上的云应用程序时，一种流行的选择是使用Amazon CloudWatch。  一些公司甚至通过开发脚本或使用AWS Lambda创建某种程度的自动化来扩展CloudWatch的功能。  但是，使用自定义指标正确配置Amazon CloudWatch并设置AWS Lambda需要一定数量的技术专长，而这可能超出了许多公司。  然后，随着应用程序的发展，维护任何脚本都需要付出成本和精力。

另一个选择是从诸如New Relics，Dynatrace，DataDog或LogicMonitor等供应商那里投资全面的应用程序性能监视（“ APM”）解决方案。如果您要监视的不仅仅是AWS环境，这些方法可能非常合适。APM解决方案非常可配置，可以根据发生的情况为您提供大量数据。

但是，您减少了停机时间吗？可能不是。  您所做的一切都花在了一个系统上，该系统将在Apache Web服务器出现故障时立即提醒您，并在尝试重新运行时使您的数据超载（或“警报风暴”）。

一些公司已决定将监视和管理其应用程序的责任外包给受信任的第三方（通常是“托管服务提供商”或MSP）。作为基本月费的回报，MSP监视应用程序并提供一组核心服务，通常受服务水平协议的约束。收到警报后，他们将进行调查。在某些情况下，这些调查可能需要（昂贵）升级。如果应用程序出现故障，则MSP将控制并重新启动服务或在可能的情况下重新启动实例。  但是这些补救措施通常是额外的费用。

一定有更好的方法。

使用SIOS AppKeeper进行自动监视和重新启动如何消除Apache Webserver的停机时间

根据我们的客户经验，只有三个EC2实例的普通公司每月至少要经历一次停机。  “该站点已关闭！放下一切。找出需要做什么！”您需要做的是减少对这些不必要的消防演习的需求。

SIOS AppKeeper是一项SaaS服务，易于安装和配置并监视Amazon EC2上运行的任何服务和应用程序，例如Apache httpd服务。  当检测到异常时，AppKeeper会自动重新启动服务，如果不起作用，它将重新启动整个实例。无需再通读日志以查明失败的原因，或升级到开发人员以重新启动服务。还是昂贵的外包费用。  AppKeeper提供“设置并忘记”功能，以便您消除停机时间。

如今，数百家公司依靠AppKeeper来保持其云环境运行。我们邀请您观看下面的视频，以演示AppKeeper如何保护Apache Web服务器。  如果您喜欢自己所看到的内容，请随时注册AppKeeper的14天免费试用版。

*基于客户数据，AppKeeper解决了85％的应用程序服务故障。因此，十分之九的AppKeeper会发送一封电子邮件，通知客户检测到停机时间并且服务已重新启动或实例自动重新启动。  这比手动重新启动所有文件之前恐慌和挖掘日志文件好吗？

请参阅相关文章：为什么AWS EC2应用程序监控如此困难？