PDF面向软件定义 SLA
公有云中的企业计算
Jason Lango，Bracket Computing
公有云引入了可能重塑企业计算的新技术和架构。特别是，公有云是企业应用程序、平台软件和新的服务设计中心。大规模、按需资源的 API 驱动编排是一个重要的新设计属性，它将公有云与传统的企业数据中心基础设施区分开来。企业应用程序必须适应新的公有云设计中心，但与此同时，新的软件和系统设计模式可以为公有云服务增加企业属性和服务级别。
本文对比了现代企业计算与新的公有云设计中心，并介绍了公有云的软件定义 SLA（服务级别协议）的概念。公有云与企业数据中心和专用系统相比如何？公有云中企业计算的独特挑战和机遇是什么？如何利用大规模公有云的按需资源来实现软件定义 SLA？其中一些机遇也可能对其他公有云用户（如消费者 Web 应用程序）有利。
如今，企业计算的主导架构模型是私有数据中心中的专用系统，这些系统经过工程设计，可为企业应用程序提供有保证的服务级别。大型多租户公有云提出的架构模型截然不同：应用程序和服务构建为分布式系统，位于虚拟化商品资源之上。许多大型消费者 Web 公司已成功使用此模型交付了弹性和高效的应用程序。
将企业应用程序迁移到公有云并非易事，但许多公司仍然对在其业务中广泛使用云基础设施感兴趣，无论是通过公有云还是私有云部署。新的灵活性和自动化水平有望简化 IT 运营。为了成为大多数应用程序的主要计算平台，公有云需要成为一个高性能的企业级平台，能够支持业务应用程序，例如财务分析、ERP（企业资源规划）系统和供应链管理。下一节将着眼于实施企业云服务所必需的实际系统考虑因素。
企业 SLA 与公有云设计中心
企业可以广义地解释为需要高级属性（如高可用性、安全性、可靠性和/或性能）的业务环境。无论应用程序是旧版还是新版，此定义都成立。例如，可以使用新的横向扩展架构来实现企业分析数据库，但仍然具有企业要求。出于监管或业务原因，数据安全性可能至关重要。数据完整性至关重要，因为错误的商业决策或财务结果可能会给公司带来实际收入损失，甚至可能导致市场价值损失。企业服务级别同时具有很高的商业价值，并且在技术上难以实现。
SLA 规定了企业服务级别要求，通常以提供商和消费者之间的法律合同形式出现，并对违规行为处以处罚。具体且可衡量的 SLO（服务级别目标）是用于测试是否满足 SLA 的单个指标。这种区分在本文的上下文中很重要，本文稍后将确定由软件定义 SLA 管理的可编程强制执行的 SLO。
在本文中，公有云指的是一个平台，该平台部署应用程序和服务，并在由第三方 CSP（云服务提供商）运行的足够大的资源池中提供按需资源，以满足任何可预见的需求。许多流行的 IaaS（基础设施即服务）和 PaaS（平台即服务）提供商都符合此定义，包括 Amazon Web Services、Microsoft Azure 和 Google Compute Engine。云计算通常包括按需自助服务、广泛的网络访问、资源池化（又名多租户）、快速弹性以及计量服务。12
不幸的是，企业期望的服务级别与当今公有云提供的服务级别之间存在公认的差距。当前的公有云 SLA 很薄弱——通常仅提供 99.95% 的数据中心可用性，并且不保证性能——而且处罚也很小。4 哪些服务级别重要？为什么它们具有挑战性？如何实现它们？让我们从长远角度看待公有云和企业基础设施的发展。虽然公有云仍在快速发展和增长，但有可能观察到一些趋势。
可靠性和可用性
企业 SLA 的可用性组成部分在技术上可能具有挑战性。例如，业务关键型应用程序可能无法容忍每年超过五分钟的停机时间，这符合 99.999%（“5 个 9”）正常运行时间的可用性 SLO。相比之下，公有云中的资源具有介于企业和商品硬件组件之间的单位经济性，包括相对较高的预期故障率。例如，亚马逊的虚拟块设备广告宣传的年故障率为 0.1% - 0.5%，这意味着每年最多有 1/200 的设备会发生故障。
业务关键型应用程序通常对应用程序级数据不一致性的容忍度较低，并且对数据损坏的容忍度为零。许多企业应用程序可以使用“最终一致性”架构重新实现，以优化性能和可用性，但代价是补偿临时不一致性。3 然而，当业务风险或惩罚足够高时，一些企业应用程序宁愿承受一些停机时间和/或数据丢失，也不愿交付不正确的结果。如果可用性 SLO 足够严格，则会对软件施加压力，要求其实现快速恢复以维持所需的正常运行时间。
领先的 CSP 一直在推动开发人员采用新的容错软件和系统设计模式，这些模式对底层基础设施的可靠性和可用性几乎不做假设。公有云设计中心鼓励将“为故障而设计”10 作为正常操作的一部分，以实现高可用性。这产生了对容错软件的需求，以补偿已知的不可靠基础设施，这在比喻上类似于 RAID（独立磁盘冗余阵列）如何补偿不可靠的物理介质。可靠性和可用性已成为软件问题。从积极的方面来看，这是一个构建更强大的软件的机会。
性能
企业应用程序的性能需求各不相同。面向最终用户的应用程序可能会按照特定的响应时间 SLO 进行管理，类似于以秒的分数衡量的消费者 Web 应用程序。重要的业务应用程序（如 ERP 和财务分析）可能会按照响应时间和吞吐量导向的 SLO 进行管理，以支持特定的业务目标，例如隔夜交易策略优化。
在公有云中，许多性能挑战是多租户的副产品。物理资源的行为类似于排队系统：多租户云基础设施的超额订阅会导致可用性能的大幅波动。16 无论存储是旋转式还是固态，或者网络是千兆位还是百千兆位，“嘈杂的邻居”都可能存在。计算超额订阅也可能对 I/O 延迟产生负面影响。18 性能和成本之间存在运营权衡。多租户公有云允许物理基础设施的高利用率以优化 CSP 的成本，这可能会以更低的价格传递给用户。不幸的是，共享物理资源的性能无法以尽可能低的固定成本得到保证。超额订阅的物理资源的性能可能会随机波动，但“便宜”，而静态分区的物理资源的性能可以得到保证，但成本较高。亚马逊预置 IOPS（每秒 I/O 操作数）就是这种权衡的一个例子，其中有保证的性能大约是成本的两倍。2
灵活使用虚拟资源是公有云中的一项要求，尤其是在要保证性能的情况下。必须主动管理分布式系统以实现性能目标。按需资源的优势在于它们可以动态重新配置，但这也是一个主要的软件挑战。
安全
安全要求因应用程序类别而异，但概括来说是风险管理：应用程序或数据集的业务或监管价值越高，安全要求就越严格。除了避免与可用性一致的拒绝服务以及避免“数据泄露”之外，还希望通过部署多层安全控制来增加“平均入侵时间”，因为认识到没有哪个单独的系统可以做到完美安全。
从企业安全的角度来看，公有云是一个有趣的环境。一方面，多租户公有云被认为是一个新的且令人担忧的环境。另一方面，跨正在运行的工作负载强制实施逻辑安全控制和自动化策略管理的能力提供了一个机会。逻辑控制比物理控制更灵活、可审计和可强制执行。网络访问控制规则是逻辑控制的经典示例，现在可以直接应用于虚拟机，而不是通过物理交换机端口间接应用。逻辑分段可以动态配置，并且可以缩小以适应正在运行的工作负载中的确切资源，并在工作负载移动时移动。
公有云需要新的安全工具和技术，需要重新思考经典的安全技术。需要以编程方式表达安全 SLO。用户、应用程序和数据集中心策略强制执行是进一步探索的值得关注的领域，以应对实施更高级别安全 SLA 的挑战（例如，“财务组以外的用户不得访问财务数据”以及“静态数据必须每两小时重新加密一次”）。
从专用系统到分布式系统
企业数据中心通常针对预定的一组用例进行优化。专用系统（如图 1 所示）经过工程设计，可通过预集成的组件以固定的性价比实现特定的服务级别。这些系统有多种外形尺寸：硬件设备、预集成的机架系统，以及最近的虚拟设备和云设备（提供开箱即用的私有云，并预配置了 SLA）。供应商垂直整合硬件和软件组件以提供服务级别属性（例如，保证的速率 I/O、物理资源重新配置、故障隔离等）。通过结合供应商的部署建议和性能和可靠性工程的最佳实践，可以满足更高级别的 SLA。
专用系统目前为需要高带宽节点间通信的工作负载提供非常高的性能水平。I/O 密集型数据分析就是一个例子：实现低响应时间 SLA 意味着每秒数十到数百千兆字节的持续节点间流量将超过大型公有云环境中常见的传统 10 千兆位以太网。
企业买家可能会为特定用例证明额外的费用是合理的——例如，技术计算用户为提前访问 GPGPU（通用图形处理器计算单元）以进行并行计算付费，而数据仓库用户为 InfiniBand 或专有的 Banyan 网络付费以获得更高的带宽数据移动。实际上，GPGPU 等专用技术已在公有云中以有限的数量和地理位置交付，并且随着时间的推移扩大了可用性。不断走在技术前沿需要付出溢价。
静态和集成，迎接动态和分布式
CSP 不断改进其产品。专用系统与公有云之间的硬件差距正在缩小。公有云提供商创建了为大规模部署和运营效率量身定制的硬件设计，Open Compute Project 就是一个流行的例子。9 CSP 的经济激励很明确：更多用例意味着更多收入。亚马逊云服务公司一段时间以来一直在提高实例 (VM) 性能，最近的动机是业务分析（亚马逊 Redshift）。由于虚拟机资源适当调整大小的实际好处，这种趋势可能会继续下去——例如，简单的可扩展性问题（阿姆达尔定律）、节点之间数据移动成本的降低或性价比/功率效率。此外，一些 CSP 可能会收购提供有保证服务级别的专用系统，例如云设备。
公有云是动态和分布式的，这与静态和集成的专用系统形成对比。CSP 的虚拟化资源针对自动化、成本和规模进行了优化， 但 CSP 也拥有平台和硬件抽象层。抽象是在提供更高级别 SLA 方面的一个挑战——很难保证服务级别，因为不知道哪些虚拟资源位于同一性能和故障域内。
企业基础设施有机会转型。新的企业应用程序正在针对云友好的软件平台（如 Cloud Foundry 和 Hadoop）编写。隐含地，在实施高可用性分布式系统的挑战性努力中，应用程序将变得对组件故障具有鲁棒性，并且对高可用性基础设施的需求将随着时间的推移而减少。此外，CSP 和平台服务可以帮助加速这种转变。例如，Microsoft Azure 使故障域对分布式应用程序可见：工作负载可以从同一数据中心内的独立故障域分配节点。SLA 可以在公有云上的软件中交付，从而为企业应用程序提供企业属性和服务级别。
面向软件定义 SLA
相对于企业消费者的需求，公有云中的按需资源实际上是无限的。为了理解这一点，了解规模会有所帮助。尽管很少公开披露，但据保守估计，单个公有 CSP 的服务器数量已达数十万台，并且还在快速增长。14 这已经比拥有数万台服务器的相当大的企业数据中心至少大一个数量级。在这种规模下，整个企业数据中心都可能容纳在 CSP 的空闲按需容量内。与大型网站上的数百万最终用户相比，对于企业业务、自定义内部部门、批处理或分析应用程序而言，50,000 名最终用户已是一个很大的数字。
这种新的设计中心从根本上改变了当今企业应用程序和基础设施中的架构假设：资源范围不再像专用系统那样固定，也不再由中央 IT 进行容量管理。即使是额外的 CPU 和 RAM 现在也可以由企业应用程序和平台服务在运行时以逻辑方式配置，无论是直接还是间接地，通过启动新的虚拟机。资源范围仅受预算限制，但软件必须针对公有云进行设计才能利用这一点。
虽然 CSP 提供了有限的 SLA，但通常需要应用程序和平台软件组件来提供围绕应用程序特性（如性能、弹性、可用性和成本）的保证。由于与多租户相关的挑战，公有云应用程序目前对其底层的基础设施几乎不做假设。它们被构建为通过设计来容忍任意故障并实施自己的 SLA。有机会创建新的架构设计模式，以帮助系统地解决其中的一些问题，并允许使用可重用的组件。
SD-SLA（软件定义 SLA）预计将在针对公有云设计中心优化的平台软件组件和云服务中增加。下一节将提供示例、实施注意事项以及局限性和未来机遇。
定义 SD-SLA
SD-SLA 提供了一种新的设计模式，该模式将 SLA 和 SLO 正式化为公有云软件组件的可配置参数。然后，这些组件管理底层资源以满足特定的可衡量 SLO 要求。借助按需资源，可以实施软件系统层来满足一些 SLO，而这些 SLO 以前需要规划、静态分区和资源过度配置。然后，云服务 API 可能会开始将 SD-SLA 作为运行时配置合并。
SD-SLA 中的可编程 SLO 可能会指定基本服务级别（如响应时间、I/O 吞吐量和可用性）的指标。它们还可能指定抽象但可衡量的属性，例如地理位置或工作负载放置约束。一些示例：亚马逊的面向服务的架构具有一个数据服务，该服务按照实时 SLA 进行管理，该服务动态调整大小和负载平衡，以“在其 99.9% 的请求中提供 300 毫秒内的响应”。8 亚马逊预置 IOPS 允许为每个存储卷配置给定的每秒 I/O 操作数。
最近的 文章“你就是绕不过去：你正在构建一个分布式系统”6 中介绍了许多有趣的软件定义 SLA 的目标，该文章还描述了构建真实世界分布式系统的挑战。
SD-SLA 应该是供应商和技术无关的，以逻辑单元指定，并且可以客观衡量——例如，配置所需的每秒 I/O 操作数，而不是实现它所需的设备数量；或节点之间的带宽量，而不是物理拓扑。
实施注意事项和示例
SD-SLA 必须在公有云设计中心的分布式系统中实施：为了运行时可配置的 SLO 可以横向扩展；为了高可用性和容错能力；以及使用按需计算和 I/O 资源。
首先，考虑这个简单的示例：在分布式键值存储的上下文中，重新配置 I/O 吞吐量 SLO 以保证一定数量的 IOPS（见图 2）。假设键值存储使用 N 路复制和类似仲裁的一致性，如 Dynamo 中所示，并且底层存储卷支持可配置的性能容量，如亚马逊预置 IOPS 中所示。给定 I/O 吞吐量 T 的初始配置，SD-SLA 感知资源管理器将分配足够的卷以提供所需的聚合 I/O 容量。保守且欠优地，假设它为每个卷分配 T × N IOPS，因为每个 get() 操作都会生成 N 个并发 I/O 请求。在本例中，SD-SLA 感知资源管理器可以将 SLO 重新配置和性能不佳的卷场景都视为标准的副本故障/替换，从而提供自动重新配置，而无需使用额外的数据复制代码路径进一步使系统复杂化。如果 I/O 吞吐量 SLO 重新配置为 T'，则将以 T' × N IOPS 分配新卷，并故障转移旧卷，直到系统收敛到 T' 聚合 I/O 吞吐量容量。在此期间，可以使用加权 I/O 分配策略来最大化 I/O 吞吐量。在现实世界中，将需要进一步的性能和成本优化，并且可以考虑更复杂的算法，例如纠删码而不是简单的复制。
鉴于分布式系统开发的挑战，不太可能有一种适用于所有情况的 SD-SLA 实施方案。各种可编程 SLO 可以在应用程序服务、平台软件组件或 CSP 本身中实施。特定的应用程序上下文决定了哪些组件适合给定的用例。由于公有云和企业应用程序都在不断变化，因此行业可能会继续迭代 CSP、应用程序与两者之间的软件组件和服务提供的属性。
SD-SLA 的运行时重新配置具有挑战性。QoS（服务质量）技术（如 I/O 调度和准入控制）是必要的，但还不够。应用程序或服务特定的实施对于动态配置 RAM、CPU 和存储资源以满足不断变化的 SLO 或在环境条件变化的情况下满足 SLO 是必要的。然而，SD-SLA 的价值可能证明了大量的工程工作和成本是合理的。一个例子是点对点对象存储的实施，以允许更灵活地使用底层资源，包括运行时替换计算节点和灵活的数据放置。一些 SD-SLA 实施可能会使用控制理论中的闭环调整。11 运行时重新配置可能与故障弹性齐头并进，因为组件替换、初始配置和运行时调整都可能以类似的应用特定方式进行管理。
必须考虑计算和数据的放置，以实现性能和数据可用性 SD-SLA。计算和数据的共置可以缓解与多租户网络相关的一些性能问题。示例包括在 Hadoop、Dryad 和 CIEL 中实施的计算和数据的灵活移动；在 Microsoft Azure 和亚马逊云服务（分别是关联组和放置组）中实施的与放置相关的 SLO；以及在 Google Spanner 中实施的数据可用性 SLO，指定地理位置和最小副本数。7
标记通常可用于识别受 SD-SLA 约束的资源，并专门用于实施安全 SLO。除了 CSP 本身支持的资源标记之外，基于主机的虚拟网络和 OpenFlow 还提供了进一步的机会来标记活动网络流中的用户和组，类似于 Cisco TrustSec 和 IEEE 802.1AE（MAC 安全标准，也称为 MACsec）。可以通过将用户和组标记与访问控制相关联来实施安全 SLO。同样，存储服务元数据中的数据集级别标记有助于实施数据集级别 SLO（例如，数据可用性、复制、访问控制和加密密钥管理策略）。
按需成本优化
即使使用围绕专用系统的复杂工具和技术，过度配置也是保证系统整个生命周期内服务级别的实际标准方法。专用系统的全部成本必须预先支付，包括过度配置的开销，以满足 SLA 并适应随着时间的推移不断增加的使用量。相比之下，公有云中的按需资源可以根据需要分配和释放，因此可以根据实际使用量计费。对于可变工作负载，这是公有云在运营效率方面优于专用系统的机会。
调整满足 SD-SLA 所需的成本和资源分配可以优化运营效率。鉴于可能需要可变资源来实现不同的 SLO，给定的 SD-SLA 可能与成本函数相关联。以下是 SD-SLA 经济学的两个基本定理：(1) 任何 SLO 的变化都必须始终与成本作为随机变量进行权衡；(2) 即使所有其他 SLO 都是固定的，面对不断变化的底层条件（例如，不可预测的多租户资源），成本也是一个随机变量。
可编程成本建模13 和优化15 是公有云研究中的新主题，并且工作正在进行中。
局限性和未来机遇
不出所料，软件定义 SLA 既有理论上的局限性，也有实际上的局限性。由于成本始终是需要管理的系统级参数，因此某些组合可能不起作用。例如，一个无效的组合是，如果应用程序要求 100 万 IOPS，最坏情况响应时间为 1 毫秒，而成本低于交付此实时 SLA 所需的物理系统的成本。即使给定无限的成本，某些 SLO 也可能在物理上无法实现（例如，带宽大于底层 CSP 的物理容量或资源分配速度快于底层 CSP 能够提供的速度）。此外，设计不佳的云服务可能不适合软件定义 SLA——例如，如果基本操作是串行化的，那么它们就无法以编程方式横向扩展和向上扩展以满足 SD-SLA。
借助 SD-SLA，还有更多机会转向许多重要后台进程的连续模型，这些进程以前由于固定资源的限制而需要进行调度。考虑到企业存储或数据库系统，而不是信任底层的物理存储控制器，可能有一个软件进程扫描物理介质，以确保潜在的位错误得到及时纠正。由于此过程可能会对具有固定计算和 I/O 资源的系统的正常运行造成破坏，因此典型的方法是在营业时间之外运行它，可能每两到四周的周末运行一次。未来的具有 SD-SLA 的云服务可能会被设计为允许重要的后台进程持续运行，而不会影响交付给应用程序的前端服务级别，因为前端服务和连续后台进程可能都具有独立的可编程 SLO，这些 SLO 可以使用按需资源进行横向扩展。
动态资源管理是 CSP 之间竞争可能释放新机遇的领域（例如，“分配具有特定数量非易失性 RAM 的 VM”或“为此正在运行的 VM 添加两个更多 CPU”）。现代虚拟机监控程序已经支持这一点。物理属性可以分解为单独可消耗的单元。例如，计算资源可以独立于 I/O 分配，I/O 吞吐量可以独立于容量分配，CPU 和 RAM 可以彼此独立分配。这削弱了专用系统的垂直集成优势。亚马逊已通过提供各种各样的 VM 类型来解决此问题1，尽管找到 CPU 和 RAM 的正确组合可能仍会涉及过度配置其中一个或另一个。
企业宏基准必须根据新的公有云设计中心进行定制。在存储领域，已经为严格的基础设施基准（如 SPC-117）付出了很多努力；然而，公有云引入了根本性的经济转变——性价比指标需要考虑工作负载运行时。由于公有云的按需性质，价格是随时间推移分配的资源的函数，以工作负载开始运行后的小时或天来衡量，而不是企业硬件的标准三年生命周期。借助 SD-SLA，分配的资源随时间、前端负载以及满足应用程序 SLA 所需的任何其他因素而变化。另一方面，在大型 RAM 缓存中实施的 I/O 基准测试将产生惊人的数字，但性价比仍然必须捕获，才能使此基准测试具有相关性。行业需要进一步努力，为公有云和 SD-SLA 发展企业宏基准。
自然而然地要问，SD-SLA 是否始终如一地得到满足。还有更多机会通过自动化测试基础设施和分析来实现可编程 SD-SLA 验证。5 这为第三方验证 SLA 和适当评估处罚提供了机会。
进一步的行业和学术努力可以完全阐明软件定义 SLA 的局限性。值得看看我们能在这方面走多远，也许有一天会足够接近近似值：“您想要什么样的应用程序响应时间？这是您将要付出的代价。”
超越公有云
公有云为重新构想企业计算提供了机会。对于公有云服务而言，承担企业计算用例的大部分将是一段有益的旅程。与过去的转型一样，企业应用程序从一种模型到另一种模型的转型可以逐步进行，从非关键应用程序开始，并随着生态系统的成熟而向上构建。车轮已经开始转动。
令人瞩目的是，一项七年的技术可以被乐观地评价，并与过去 20-30 年企业基础设施的整体进步相提并论。公有云创新的步伐是持续不断的。大量的精力和资本持续涌入公有云基础设施。如今，公有云是一个价值数十亿美元且快速增长的市场。今天的所有或任何问题都可能转瞬即逝。由于计算经济学的变化——从大型机到客户端-服务器时代，企业平台在历史上已经看到了结构的 радикальное 转变。我们正处在又一次行业转型之中。
未来的企业应用程序和基础设施可能会构建为分布式系统，其中包含专注于公有云的可重用平台软件组件。这可以帮助信息技术专业人员和应用程序开发人员部署快速且可靠的应用程序，而无需每次都重新发明轮子。与可靠性、可用性、安全性和服务性相关的一些企业功能可以在此模型中持续运行。SD-SLA 的运行时配置提供了一个机会，可以根据人们想要的确切性能指标进行管理，而不是物理特性，例如原始硬件或预先打包的 SLA。企业应用程序可以利用大型 CSP 的规模、效率以及快速发展的硬件和运营优势。这些都是重要的机会，在专用系统中不可用，但由公有云的大规模按需资源实现。
所有工程师和 IT 专业人员都应该明智地了解公有云，并利用这些趋势和机会，无论是在他们目前的工作还是下一份工作中。公有云正在定义新软件的形态——从应用程序到基础设施。这是我们的未来。
参考文献
1. Amazon Web Services. 2013. Amazon EC2 实例; http://aws.amazon.com/ec2/instance-types/.
2. Amazon Web Services. 2013. Amazon Elastic Block Store (EBS); http://aws.amazon.com/ebs/.
3. Bailis, P., Ghodsi, A. 2013. 当今的最终一致性：局限性、扩展和超越。 11(3); https://queue.org.cn/detail.cfm?id=2462076.
4. Baset, S. A. 2012. 云 SLA：现状与未来。 SIGOPS Operating Systems Review 46(2): 57-66.
5. Bouchenak, S., Chockler, G., Chockler, H., Gheorghe, G., Santos, N., Shraer, A. 2013. 验证云服务：现状与未来。 SIGOPS Operating Systems Review 47(2): 6-19.
6. Cavage, M. 2013. 就是无法回避：你正在构建一个分布式系统。 11(4); https://queue.org.cn/detail.cfm?id=2482856.
7. Corbett, J. C., et al. 2012. Spanner：谷歌的全球分布式数据库。第 10 届 Usenix 操作系统设计与实现会议论文集： 251-264.
8. DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., Vogels, W. 2007. Dynamo：亚马逊的高度可用键值存储。第 21 届 SIGOPS 操作系统原理研讨会论文集： 205-220.
9. Facebook. 2011. 开放计算项目; http://www.opencompute.org/.
10. Hamilton, J. 2007. 关于设计和部署互联网规模的服务。第 21 届大型安装系统管理会议论文集。
11. Hellerstein, J. L. 2009. 工程自治系统。第 6 届自治计算国际会议论文集： 75-76.
12. Mell, P., Grance, T. 2011. NIST 云计算定义。美国国家标准与技术研究院特别出版物 800-145; http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.
13. Mian, R., Martin, P., Zulkernine, F., Vazquez-Poletti, J. L. 2012. 估算公有云中数据密集型工作负载的资源成本。第 10 届网格、云和电子科学中间件国际研讨会论文集。
14. Netcraft. 2013. 亚马逊网络服务持续增长（五月）; http://news.netcraft.com/archives/2013/05/20/amazon-web-services-growth-unrelenting.html.
15. Ou, Z., Zhuang, H., Nurminen, J. K., Ylä-Jääski, A., Hui, P. 2012. 利用 Amazon EC2 同一实例类型中的硬件异构性。第 4 届 Usenix 云计算热点研讨会 (HotCloud) 论文集： 1-5.
16. Schad, J., Dittrich, J., Quiané-Ruiz, J.-A. 2010. 云中的运行时测量：观察、分析和减少差异。超大型数据库基金会论文集 3(1-2): 460-471.
17. Storage Performance Council. 2013. SPC 规范; http://www.storageperformance.org/specs.
18. Xu, Y., Musgrave, Z., Noble, B., Bailey, M. 2013. Bobtail：避免云中的长尾效应。第 10 届 Usenix 网络系统设计与实现会议论文集： 329-342.
喜欢它，讨厌它？请告诉我们
Jason Lango 是 Bracket Computing 的联合创始人兼首席技术官，这是一家企业云计算公司，他在 Sutter Hill Ventures 担任驻场企业家期间创立了该公司。他的职业生涯专注于企业计算、存储、安全和操作系统。Jason 曾担任 Cisco（通过 IronPort Systems 的收购）的首席工程师，在那里他担任 Web 安全产品线的首席架构师。在此之前，他在 NetApp 工作了 7 年多，担任高级工程师，负责文件系统性能和代理缓存技术。他的职业生涯始于 SGI，从事其原始 UNIX 内核 (IRIX) 中的大规模进程和线程调度工作。Jason 在 http://lastbusinessmachine.com 上撰写博客。
© 2013 1542-7730/13/1100 $10.00
最初发表于 Queue 第 11 卷，第 11 期—
在 数字图书馆 中评论本文
更多相关文章
Marc Brooker, Ankush Desai - AWS 的系统正确性实践
构建可靠和安全的软件需要一系列方法来推理系统的正确性。除了行业标准的测试方法（例如单元测试和集成测试）之外，AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分——也许最重要的是，形式化规范作为测试预言，为 AWS 的许多测试实践提供正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域，这些领域的投资已经看到了出色的回报，这加速了投资步伐。
Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经到了分布式计算无处不在的地步。内存应用程序数据大小正在超过单台机器的容量，因此需要将其划分为集群；在线服务具有高可用性要求，这只能通过将系统部署为多个冗余组件的集合来满足；高持久性要求只能通过数据复制来满足，有时需要跨越广阔的地理距离。
David R. Morrison - 模拟：分布式系统中未被充分利用的工具
模拟在人工智能系统的出现中发挥着巨大的作用：我们需要一种高效、快速且经济高效的方式来训练人工智能代理在我们基础设施中运行，而模拟绝对提供了这种能力。
Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 公司到云端：谷歌的虚拟桌面
超过四分之一的 Google 员工使用内部、数据中心托管的虚拟桌面。这种本地产品位于公司网络中，允许用户从世界任何地方远程开发代码、访问内部资源和使用 GUI 工具。在其最显着的特性中，虚拟桌面实例可以根据手头的任务调整大小，具有持久的用户存储，并且可以在公司数据中心之间移动以跟随出差的 Google 员工。直到最近，我们的虚拟桌面都是使用名为 Ganeti 的自研开源虚拟集群管理系统托管在 Google 公司网络上可商购的硬件上的。今天，这项重要且对 Google 至关重要的工作负载在 GCP（Google Compute Platform）上运行。
© 保留所有权利。