高可用性应用程序的云成本

在与云服务提供商签订合同后不久，账单到达会导致贴纸冲击。有意外和看似过度的指控。那些负责任的人似乎无法解释这是怎么发生的。这种情况很紧急，因为除非立即进行节省成本的变更，否则数额可能会破坏IT预算。那么我们如何管理高可用性应用的云成本呢？这种云服务贴纸冲击通常是由任务关键型数据库应用程序引起的。特别是由于各种原因，这些往往成本最高。这些应用程序需要全天候运行。它们需要冗余，这涉及复制数据和配置备用服务器实例。数据复制需要数据移动，包括跨广域网（WAN）。提供高可用性会导致许可Windows获得Windows Server故障转移群集（与使用免费的开源Linux相比）的成本更高，或者许可SQL Server企业版以获得Always On Availability Groups。在提供管理高可用性应用程序的云成本的建议之前，请务必注意，此处的目标不是最大限度地降低这些成本。而是优化每个应用程序的价格/性能。换句话说，在为需要更高正常运行时间和吞吐量性能的应用程序配置资源时，为此付出更多是适当的。同样重要的是要注意，混合云基础架构 – 应用程序在私有云和公共云中全部或部分运行 – 可能是实现最佳性价比的最佳方式。

了解云服务提供商业务和定价模型

贴纸震撼体验表明需要彻底了解云服务的定价方式以及管理高可用性应用程序的云成本。只有这样才能以最具成本效益的方式利用现有服务。所有云服务提供商（CSP）都会公布其定价。 除非服务协议中另有规定，否则定价会不断变化。所有基于硬件的资源，包括物理和虚拟计算，存储和网络服务，都不可避免地会产生一些直接或间接的成本。这些都基于这些系统消耗的空间，功率和冷却。对于软件，开源通常是免费的。 但是所有商业操作系统和/或应用软件都将产生许可费。并预先警告某些软件许可和定价模型可能非常复杂。所以一定要仔细研究它们。除了这些硬件和软件的基本费用外，各种增值服务还有潜在的单点费用。这包括安全性，负载平衡和数据保护规定。对于存储或分布式微服务的I / O，或者在“突发”期间很少发生的峰值利用，也可能存在“隐藏”成本。因为每个CSP都有自己独特的业务和定价模型，所以此处的讨论必须推广。而且，通常，最昂贵的资源涉及计算，软件许可和数据移动。它们共同占总成本的80％或更多。数据移动还可能产生单独的WAN费用，这些费用未包含在CSP的账单中。CSP基础架构内的存储和网络通常是成本最低的资源。固态驱动器（SSD）通常比每TB的旋转介质成本更高。但SSD也提供了卓越的性能，因此它们的性价比可能相当甚至更好。虽然将数据移回企业可能很昂贵，但将数据从企业迁移到公共云通常可以免费完成（尽管有单独的WAN费用）。

制定优化价格/性能的策略

覆盖高可用性应用程序的云成本需要细致的检查。以下是一些管理公共云资源利用率的建议，可以降低成本，同时为所有应用程序维护适当的服务级别。这包括需要关键任务，高正常运行时间和吞吐量的那些。通常，权利规模是管理资源利用率以获得最佳性价比的基本原则。当Willie Sutton据称被问到为什么要抢劫银行时，他回答说：“因为这就是钱的所在”。在云中，资金存在于计算资源中，因此这应该是正确调整大小的最高优先级。对于新应用程序，从计算资源的最小虚拟机配置开始。仅在需要时添加CPU内核，内存和/或I / O以实现令人满意的性能。现有应用程序的所有虚拟机最终都应该是正确的。从那些成本最高的那些开始。逐步减少分配，同时不断监控绩效，直至实现收益递减。值得注意的是，与正确尺寸相关的主要风险是尺寸不足的可能性。然而，它可能导致不可接受的差的性能。不幸的是，评估应用程序实际性能的最佳方法是使用生产工作负载，使现实世界成为适合规模的正确位置。幸运的是，云可以轻松地按需快速调整配置大小，从而降低了这种风险。在需要的地方积极进取。但是，准备好对每个变化做出快速反应。与计算形成鲜明对比的存储在云中通常相对便宜。但要小心使用廉价存储，因为I / O可能会因某些服务而产生单独且昂贵的费用。如果是这样，请利用可能更具成本效益的性能增强技术（如分层存储，缓存和/或内存数据库）来优化所有资源的利用率。私有云和公共云中的软件许可证可能是一笔巨大的费用。出于这个原因，许多组织正在从Windows迁移到Linux，从SQL Server迁移到成本较低的商业和/或开源数据库。但对于那些需要“高级”操作系统和/或应用程序软件的应用程序，请检查不同的CSP，看看是否有任何定价模型可以为所需的配置节省一些成本。最后，所有CSP都提供折扣，这些组合有时可以节省高达50％。示例包括预付服务，做出服务承诺和/或将应用程序重新定位到另一个地区。

创建和实施成本控制

云服务的自我配置可能会受到用户的欢迎。但是，如果没有适当的控制，这种便利性会过度利用资源，包括那些成本最高的资源。通过充分利用所有CSP提供的监控和管理工具，开始努力获得更好的控制。当然，这可能会遇到学习曲线。因为CSP的工具可能与私有云中使用的工具非常不同，并且可能更复杂。其中一个更有用的成本控制工具涉及标记资源。标签由键/值对和与各个资源相关联的元数据组成。有些可能非常精细。例如，每个虚拟机以及它使用的CPU，内存，I / O和其他可计费资源都可能具有标记。其他有用的标签可能会显示哪些应用程序位于生产与开发环境中，或者分配给每个成本中心或部门。总的来说，这些标签可以构成对账单中反映的资源的总利用率。广泛使用公共云服务的组织也可以很好地创建脚本。将所有可用监控，管理和标记工具中的信息加载到电子表格或类似应用程序中，以进行详细分析和其他用途，例如退款，合规性和趋势/预算。理想情况下，来自所有CSP和私有云的信息将被标准化，以包含在整体视图中，以优化在整个混合云中运行的所有应用程序的性价比。

处理最坏情况用例：高可用性应用程序

除了引言中为什么高可用性应用程序成本最高的原因之外，所有三个主要的CSP（谷歌，微软和亚马逊）都至少有一些与高可用性相关的限制。例如，故障转移通常仅由区域中断而不是由许多其他常见故障触发;主实例只能创建单个故障转移副本;以及使用事件日志来复制数据，这会产生“复制延迟”，导致故障转移期间出现临时中断。当然，这些限制都不是不可克服的 – 预算足够大。面临的挑战是找到一种通用且经济高效的解决方案，以实现跨公共云，私有云和混合云的高可用性。这种解决方案中功能最多且价格最便宜的是存储区域网络（SAN）无故障转移群集。这些高可用性解决方案完全由专门用于创建的软件实现。正如名称所暗示的那样，无共享的服务器和存储集群通过局域网和/或WAN进行自动故障转移，以确保应用程序级别的高可用性。这些解决方案中的大多数提供了实时块级数据复制，连续应用程序监视和可配置的故障转移/故障恢复恢复策略的组合。一些更强大的无SAN故障转移群集还提供高级功能。例如，广域网优化可以最大限度地提高性能并最大限度地降低带宽利用率，对价格较低的SQL Server标准版提供强大支持 我们不要忘记手动切换主服务器和辅助服务器分配以进行计划维护，以及在不中断应用程序的情况下执行例行备份的能力。

保持正确的视角

在您的混合云中尝试其中一些建议时，尽量保持每月的CSP法案正确。使用公共云，所有成本都显示在一张发票上。相比之下，运营私有云的总成本很少以完整，统一的方式呈现。如果是这样，总成本也可能导致贴纸震动。因此，一项有用的练习可能是了解运营私有云的全部成本 – 不考虑任何理由 – 就好像它是一个独立的业务，例如云服务提供商的业务。然后，来自CSP的关于任务关键型应用程序的那些账单可能看起来并不那么令人震惊。来自www.dbta.com的文章

在重大云中断中管理实时恢复

灾难发生，突然停工成为现实。但是，所有客户都可以做的事情是在几乎任何云中断中存活下来。东西发生了。失败 – 无论大小 – 都是不可避免的。不可避免的是延长的停机时间。考虑美国中南部地区的微软Azure云遭遇灾难性失败的那一天。一场严重的雷暴导致了一连串的问题，最终导致整个数据中心崩溃。在一些人称之为“天空中的Azure云天”中，大多数客户都处于离线状态，不仅仅是几秒钟或几分钟，而是一整天。有些人离线超过两天。虽然微软已经解决了导致停电的许多问题，但IT专业人员将长期记住这一事件。这是坏消息。好消息是：Azure客户可以做的事情几乎可以在任何中断中存活。它可能来自单个服务器，无法使整个数据中心脱机。实际上，实现强大的高可用性和/或灾难恢复规定的Azure客户，无论是实时数据复制还是快速自动故障转移，都可以避免数据丢失，并且每当发生灾难时都很少或没有停机时间。另请参阅：Nutanix认为企业云赢得了云计算竞赛

管理云中断

本文介绍了在混合和纯Azure云配置中提供灾难恢复（DR）和高可用性（HA）保护的四个选项。其中两个选项特定于Microsoft SQL Server数据库，这是Azure云中的一个流行应用程序;另外两个选项是与应用程序无关的。这四个选项也可用于各种组合，在表格中进行了比较，包括：

• Azure站点恢复（ASR）服务
• 具有存储空间直接的SQL Server故障转移群集实例
• SQL Server始终在可用性组
• 第三方故障转移群集软件

RTO和RPO 101

在描述这四个选项之前，有必要对用于评估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。

Azure站点恢复（ASR）服务

ASR是Azure的DR-as-a-service（DRaaS）产品。ASR将物理机和虚拟机复制到其他Azure站点，可能在其他区域，或从本地实例复制到Azure云。该服务可以从系统和站点中断中快速恢复，并通过消除滚动软件升级期间的停机时间来促进计划内维护。与所有DRaaS产品一样，ASR有一些限制，最严重的是无法自动检测和故障转移导致应用程序级停机的许多故障。当然，这就是为什么该服务被定性为DR而不是HA的原因。使用ASR，恢复时间通常为3-4分钟，当然，这取决于管理员能够以多快的速度手动检测和响应问题。如上所述，跨WAN的异步数据复制的需求可以进一步增加RPO为零的应用程序的恢复时间。

具有存储空间直接的SQL Server故障转移群集实例

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保护，需要通过日志传送或第三方故障转移群集解决方案提供必需的数据复制。

SQL Server始终在可用性组

虽然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

Jonathan Meltzer是SIOS Technology的产品管理总监。他在软件和SaaS产品的产品管理和营销方面拥有20多年的经验，可帮助客户管理，转换和优化其人力资本和IT资源。从RTinsights转载