SIOS SANless clusters High-availability Machine Learning monitoring
企业越来越多地使用多个云服务提供商来保持灵活性和可扩展性；然而，最近发生的 CrowdStrike 中断等事件凸显出，即使是顶级系统也会遇到问题，尤其是更新和安全补丁。本次网络研讨会讨论了实施多云高可用性 (HA) 解决方案的最佳实践，以确保您的关键任务应用程序在意外中断期间正常运行。它还介绍了防止因系统配置错误或有问题的补丁而导致停机的策略，确保您能够有效地管理云基础设施。
观看点播网络研讨会，了解如何在您的环境中实现 HA 并最大限度地减少可预防的停机时间。
经许可转载西欧斯
根据 Flexera 2021 年云状况报告，云计算在过去十年中变得无处不在，99% 的组织至少使用一个公共或私有云。 虽然 AWS、Microsoft Azure 和 GCP 是当今三大公共云提供商，但许多组织（无论是有意还是无意）采用了多云战略，使他们能够挑选最有吸引力和最适合的云服务以满足他们独特的业务需求。 根据 Flexera 报告，如今 92% 的企业拥有多云战略，平均使用 2.6 个公共云和 2.7 个私有云，包括软件即服务 (SaaS)、平台即服务 (PaaS)、基础设施即服务 (IaaS) 产品。
多云只是一个由两个或多个公共和/或私有云（包括 SaaS、PaaS 和 IaaS）组成的环境。 多云环境中的不同服务可能会互操作（在这种情况下可能是混合云），也可能不一定会互操作（本质上作为单独的云孤岛运行）。 请记住，尽管所有混合云都是多云，但并非所有多云都是混合云。
多云环境由任意两个或多个公共或私有云产品组合组成，包括 SaaS、PaaS 和 IaaS。 因此，组织的多云战略可能包括在 Amazon Elastic Cloud Compute (EC2) 上运行的企业工作负载，以及使用 Microsoft 365 处理电子邮件和后台应用程序。 或者，组织可以将私有云中托管的自定义数据库连接到公共云 SaaS 产品 Salesforce。
混合云环境由本地、私有云和公共云环境组成。 根据 Flexera 报告，80% 的企业拥有混合云战略（见图 4）。 多云环境通常是影子 IT 的结果，在影子 IT 中，不同的部门采购云服务来满足各自的需求，而无需咨询集中的 IT 部门。 例如，您的营销团队可能早在 IT 部门在 AWS 中部署其第一个工作负载之前就开始使用 Salesforce，而您的人力资源和财务部门正忙于将 Workday 和 Concur 添加到您的组织现在所依赖的 SaaS 应用程序组合中。 或者，也许您拥有在全球范围内从事不同项目的应用程序开发团队。 一个开发团队可能更喜欢 Azure DevOps，而另一个团队可能更喜欢 AWS 中的开源工具。 因此，您的多云策略可能纯粹是偶然演变的——这不一定是坏事。
您的不同部门有权选择同类最佳的解决方案来满足他们的需求，而您的应用程序开发团队可以在他们首选的开发环境中最大限度地提高工作效率并缩短上市时间。
多云环境也会因设计而演变，例如，由于监管要求、并购，或实施高可用性和灾难恢复策略。
监管语言可能含糊不清。 例如，金融行为监管局 (FCA) 关于外包 IT 的规定规定，公司必须能够“知道他们将如何过渡到替代服务提供商并保持业务连续性”。该声明意味着受监管的公司至少需要规划二级云环境。 鉴于许多受到严格监管的公司规避风险的性质，这些类型的问题导致许多公司采用多云战略。
在合并或收购后整合 IT 系统并整合数据中心和云环境是一项重大挑战。 有许多因素会使这一挑战复杂化，包括与云提供商或托管提供商的现有合同。 与整合物理数据中心类似，整合云工作负载可能是一项无法带来显着商业价值的重大工作，因此它经常因优先级更高的项目而被推迟。
最后，通常采用多云策略来支持高可用性和灾难恢复需求。 在评估 AWS 和 Azure 的主要公共云中断时，大多数中断通常一次仅限于一个云区域（并且最常见的是与软件相关）。
越来越多的组织（根据 Flexera 报告，占 34%）采取了额外的步骤，跨多个公共云提供商部署他们的关键任务工作负载。 这对于静态工作负载来说要容易得多，例如可以独立运行的网站和应用程序。 对于数据库和目录服务（例如 Active Directory）等分布式系统，多云灾难恢复可能更具挑战性。
与单一云部署相比，多云环境更复杂，因此管理起来更具挑战性。 多云环境中的一些独特挑战包括： • 端到端可见性：确保完整的可见性在任何 IT 环境中都是一项挑战——在高度动态的多云环境中，它的复杂性和挑战性呈指数级增长。 但是，端到端可见性对于解决性能问题和瓶颈、保护您的数字足迹以及识别关键任务系统和应用程序中的单点故障至关重要。
• 安全和身份管理：勒索软件和其他网络安全威胁是当今每位 IT 领导者最关心的问题。 通过将某些安全责任（例如数据中心和物理安全）转移到公共云提供商并提供对加密和网络分段等服务的按需访问，迁移到公共云平台通常可以改善组织的安全状况，但它可以也更容易犯下代价高昂的错误。 例如，网络错误配置可能很常见——数以千计的数据泄露是由配置不当的 AWS S3 存储桶造成的。 身份管理是另一个挑战。 例如，以前在本地环境中使用过 Active Directory 的组织可能非常熟悉 Azure Active Directory，但将身份管理从 Azure 扩展到 AWS、GCP 和 SaaS 产品（例如 Salesforce、ServiceNow、Workday 等） ) 可以引入新的挑战。
• 应用程序和数据可移植性：在混合（多云）环境中跨不同公共云平台动态移动应用程序和数据的能力是许多多云战略的关键。 尽管公共云提供商不一定会构建他们的服务来限制应用程序和数据的可移植性，但他们不一定会合作来促进此功能，并且可能会涉及成本。 不同的云提供商也为其各种服务产品使用不同的技术。
• 多云孤岛：如果组织不针对应用程序和数据可移植性来规划和设计其多云部署，他们最终可能会遇到孤立的应用程序和存储，本质上会在跨多个云平台的传统本地数据中心环境中重现一个常见问题。 至少，组织需要多云安全和管理工具，使他们能够有效地管理跨不同云平台的风险和使用/成本。
根据 Flexera 2021 年云状况报告，81% 的组织将安全性列为其云部署的首要挑战，其次是管理云支出 (79%)。 然而，只有 42% 的组织使用多云成本管理工具，只有 38% 的组织使用多云安全工具。
尽管多云部署面临许多挑战，但它们可以提供额外的可用性，尤其是在发生重大云中断和灾难恢复的情况下。 如果您的组织正在推行多云战略，您应该与值得信赖的、与云无关的合作伙伴合作，以帮助您使用整体方法设计和实施多云部署。
为了高可用性和灾难恢复，您还需要一个跨越您的多云环境的与云无关的技术解决方案，无论您使用何种云平台。 您总是希望避免这样一种情况，即您的高可用性解决方案会比独立解决方案在您的环境中导致更多的停机时间。 早期版本的 SQL Server 群集提出了这个难题 — 要增加磁盘空间，您必须招致停机，而这在独立解决方案中是不会发生的。 虽然故障转移静态网站之类的东西可能微不足道，但移动多层应用程序堆栈在网络和数据同步方面却极其复杂。 您还需要避免故障转移到安全性较低的云环境，该环境可能由于不了解跨云提供商的不同安全解决方案之间的细微差别而配置错误。
最后，在每个公共云中，都有一些服务会迅速增加成本。 这些服务根据基于使用的定价收费，并且可能意味着仅仅几天后成本就会急剧增加。 减轻这种风险的一种方法是确保您利用每个云平台中的成本监控服务和警报。
虽然多云部署并不适用于所有组织，但许多组织会走这条路。 了解网络和安全是您最大的技术障碍之一，管理治理和成本是关键的功能挑战。 测试对于确保您的多云集群解决方案正常运行至关重要。 使用支持简单切换和切回的高可用性集群解决方案并了解您的每个应用程序将如何工作非常重要故障转移，最重要的是定期测试故障转移以了解任何网络或数据障碍。
经许可转载自信息系统
如果这个话题听起来令人困惑，我们明白了。 在我们专家的建议下，我们希望能缓和您的担忧——同时也在之前或之后为您的组织提出一些重要的考虑因素去多云. 对于采用云计算的公司来说，灾难恢复规划是一个常见的困惑点，尤其是当它涉及多个云提供商时。
这足以确保数据保护和灾难恢复(DR) 当所有数据都位于本地时。 但如今，许多公司拥有本地数据以及多个云提供商，这种混合策略可能具有良好的商业意义，但可能会给负责数据保护的人员带来挑战。 在我们深入研究细节之前，让我们定义关键术语。
多云是利用两个或多个云提供商为组织的 IT 服务和基础架构提供服务。 多云方法通常由主要公共云提供商的组合组成，即亚马逊网络服务 (AWS)、谷歌云平台 (GCP) 和微软 Azure。
组织根据成本、技术要求、地理可用性和其他因素从每个云提供商处选择最佳服务。 这可能意味着公司使用 Google Cloud 进行开发/测试，同时使用 AWS 进行灾难恢复，并使用 Microsoft Azure 处理业务分析数据。
多云不同于混合云，混合云是指混合本地基础设施、私有云服务和公共云的计算环境。
应对这些挑战要求公司制定涵盖众多问题的数据保护和恢复策略。 试着问自己以下战略问题：
在多云场景中成功保护和恢复数据的最大关键是确保您可以查看所有数据，无论数据如何存储。 公司提供的工具使您能够定义在灾难场景中应该恢复哪些数据和应用程序以及如何恢复——例如，无论是从备份映像还是通过将数据移动到云中新创建的虚拟机。
该工具应该可以帮助您编排恢复场景，重要的是，可以对其进行测试。 如果该工具与您的数据备份工具很好地集成在一起，它还可以让您将备份用作恢复数据的来源，即使数据存储在不同的位置——比如多个云。 我们最近的 SIOS 网络研讨会讨论了同一点；手表在这里如果你有兴趣。SIOS 数据管理员让您可以在灵活、可扩展的云环境中运行关键业务应用程序，例如亚马逊网络服务 (AWS) ,天蓝色， 和谷歌云平台在不牺牲性能、高可用性或灾难保护的情况下。 SIOS DataKeeper 可在AWS 市场以及唯一的 Azure 认证的 WSFC 高可用性软件Azure 市场。
灾难发生，突然停工成为现实。但是，所有客户都可以做的事情是在几乎任何云中断中存活下来。东西发生了。失败 – 无论大小 – 都是不可避免的。不可避免的是延长的停机时间。考虑美国中南部地区的微软Azure云遭遇灾难性失败的那一天。一场严重的雷暴导致了一连串的问题，最终导致整个数据中心崩溃。在一些人称之为“天空中的Azure云天”中，大多数客户都处于离线状态，不仅仅是几秒钟或几分钟，而是一整天。有些人离线超过两天。虽然微软已经解决了导致停电的许多问题，但IT专业人员将长期记住这一事件。这是坏消息。好消息是：Azure客户可以做的事情几乎可以在任何中断中存活。它可能来自单个服务器，无法使整个数据中心脱机。实际上，实现强大的高可用性和/或灾难恢复规定的Azure客户，无论是实时数据复制还是快速自动故障转移，都可以避免数据丢失，并且每当发生灾难时都很少或没有停机时间。另请参阅：Nutanix认为企业云赢得了云计算竞赛
本文介绍了在混合和纯Azure云配置中提供灾难恢复（DR）和高可用性（HA）保护的四个选项。其中两个选项特定于Microsoft SQL Server数据库，这是Azure云中的一个流行应用程序;另外两个选项是与应用程序无关的。这四个选项也可用于各种组合，在表格中进行了比较，包括：
在描述这四个选项之前，有必要对用于评估DR和HA规定的有效性的两个指标有一个基本的了解：恢复时间目标和恢复点目标。熟悉RTO和RPO的人可以跳过本节。RTO是中断的最大可容忍持续时间。在线事务处理应用程序通常具有最低的RTO，而关键任务应用程序通常具有仅几秒的RTO。RPO是可以容忍数据丢失的最长期限。如果不能容忍数据丢失，则RPO为零。RTO通常会确定所需的HA和/或DR保护的类型。低恢复时间通常需要强大的HA规定来防止日常系统和软件故障，而较长的RTO可以满足基本DR规定，旨在防范更广泛但更不频繁的灾难。与HA和DR规定一起使用的数据复制可能需要在RTO和RPO之间进行潜在的权衡。在低延迟LAN环境中，复制可以是同步的，可以同时更新主数据集和辅助数据集。这使得完全恢复能够自动且实时地发生，从而可以满足最苛刻的恢复时间和恢复点目标（分别为几秒和零），无需权衡。相反，在整个WAN中，强制主要服务器等待辅助服务器确认每个事务的更新完成将对性能产生负面影响。因此，WAN中的数据复制通常是异步的。这可以在容纳RTO和RPO之间进行权衡，这通常会导致恢复时间的增加。原因如下：为了满足零RPO，需要手动过程以确保在故障转移发生之前所有数据（例如来自事务日志）已在辅助设备上完全复制这种额外的工作会延长恢复时间，这就是为什么这样的配置通常用于DR而不是HA。
ASR是Azure的DR-as-a-service（DRaaS）产品。ASR将物理机和虚拟机复制到其他Azure站点，可能在其他区域，或从本地实例复制到Azure云。该服务可以从系统和站点中断中快速恢复，并通过消除滚动软件升级期间的停机时间来促进计划内维护。与所有DRaaS产品一样，ASR有一些限制，最严重的是无法自动检测和故障转移导致应用程序级停机的许多故障。当然，这就是为什么该服务被定性为DR而不是HA的原因。使用ASR，恢复时间通常为3-4分钟，当然，这取决于管理员能够以多快的速度手动检测和响应问题。如上所述，跨WAN的异步数据复制的需求可以进一步增加RPO为零的应用程序的恢复时间。
SQL Server提供了两个自己的HA / DR选项：故障转移群集实例（此处讨论）和Always On Availability Groups（下面讨论）。FCI提供两个优点：该功能可以在较便宜的SQL Server标准版中使用，并且它不依赖于像传统HA集群那样的共享存储。后一个优势很重要，因为云中的共享存储根本不可用 – 来自Microsoft或任何其他云服务提供商。Azure云存储的一个流行选择是Storage Spaces Direct（S2D），它支持广泛的应用程序，它对SQL Server的支持保护整个实例而不仅仅是数据库。S2D的一个主要缺点是服务器必须位于单个数据中心内，这使得该选项适用于某些HA需求，但不适用于DR。对于多站点HA和DR保护，需要通过日志传送或第三方故障转移群集解决方案提供必需的数据复制。
虽然Always On Availability Groups是SQL Server为HA和DR提供的最强大的产品，但它需要许可更昂贵的Enterprise Edition。此选项可以提供5-10秒的恢复时间和几秒或更短的恢复点。它还提供可读的辅助数据库，用于查询数据库（具有适当的许可），并且不对数据库的大小或辅助实例的数量进行限制。提供HA和DR保护的Always On Availability Groups配置包括三个节点的安排，在单个可用性集或区域中有两个节点，第三个在单独的Azure区域中。一个值得注意的限制是只复制数据库，而不是整个SQL实例，必须通过其他方式进行保护。除了对某些数据库应用程序成本过高之外，这种方法还有另一个缺点。特定于应用程序需要IT部门为所有其他应用程序实施其他HA和DR规定。使用多个HA / DR解决方案可能会大大增加复杂性和成本（用于许可，培训，实施和持续运营），这也是组织越来越倾向于使用与应用程序无关的第三方解决方案的另一个原因。
凭借其与应用程序无关且与平台无关的设计，故障转移群集软件能够为私有，公共和混合云环境中的几乎所有应用程序提供完整的HA和DR解决方案。这包括Windows和Linux。与应用程序无关，无需为不同的应用程序提供不同的HA / DR规定。与平台无关，可以利用Azure云中的各种功能和服务，包括故障域，可用性集和区域，区域对和Azure站点恢复。作为完整的解决方案，该软件至少包括实时数据复制，能够检测应用程序级故障的连续监视，以及用于故障转移和故障恢复的可配置策略。大多数解决方案还提供各种增值功能，使故障转移群集能够在几乎没有数据丢失的情况下提供低于20秒的恢复时间，从而满足几乎所有HA / DR需求。
无论是单独运行还是一致运行，所有这四个选项都可以发挥作用，使DR和HA保护的连续性对于各种企业应用程序更有效和更实惠。这包括那些能够容忍一些数据丢失和延长的停机时间的系统，以及那些需要实时恢复以实现5到9个正常运行时间且数据丢失很少或没有数据丢失的系统。为了在现实世界中实现下一次云中断，请确保您选择的任何DR和/或HA规定配置为至少两个节点分布在两个站点上。还要确保了解条款满足每个应用程序的恢复时间和恢复点目标的程度。以及可能存在的任何限制，包括检测所有可能的故障所需的手动过程，以及确保应用程序连续性和数据完整性的方式触发故障转移。
Jonathan Meltzer是SIOS Technology的产品管理总监。他在软件和SaaS产品的产品管理和营销方面拥有20多年的经验，可帮助客户管理，转换和优化其人力资本和IT资源。从RTinsights转载