五步成功构建私有云

本文要点

• 公有云领域正在蓬勃发展。首先，云解决方案迎来更多的竞争和机遇。其次，数据监管和安全控制正成为新的挑战。

• 你需要清晰的数据监管策略来驱动工程实践，以免阻碍业务的发展。

• 利益相关者的参与对你的成功至关重要，需要让他们接受你的策略，并了解风险和义务。

• 你无法预测未来的需求，所以要提供足够的灵活性便于后续的扩展。

• 使用自动化，包括硬件部署的自动化。给供应商施加压力，让他们参与进来。

在 2017 年云基础设施即服务 Gartner 魔力象限中，Amazon Web Services 无疑是当之无愧的领跑者。尽管如此，AWS 仍然不足以成为事实上的云服务解决方案。最近，AWS 的部分用户因为与 Amazon 零售业务存在竞争关系，宣布要停止使用 AWS。Walmart 构建了自己的私有云，并要求它的技术供应商撤出 AWS，转而寻求与 Google 和 Microsoft 合作。主流的云供应商纷纷加入 Cloud Native Computing Foundation（CNCF），推动行业朝着基于容器的跨云微服务架构发展。VMware 停止与四个主要的公有云供应商合作（Amazon、Microsoft、IBM、Google），Microsoft 启动了 Azure Stack——轻量版的 Azure。业界出现了另一个非常重要的趋势，数据隐私和安全的区域合规性（中国、俄罗斯、欧洲）正崭露头角，比如即将于 2018 年 5 月开始实行的欧洲通用数据保护条例（GDPR）。业务部门需要重新定义他们的云策略，拥抱混合云解决方案，并加入更严格的数据监管，这意味着需要向私有云迈出一大步。

云基础设施即服务 Gartner 魔力象限图：

下列是在构建私有云解决方案时需要考虑的五个方面。

1. 愿景和战略规划

很多私有云因无法发挥应有的作用而以失败告终。与工程项目一样，错误的期望值和不现实的目标会导致糟糕的结果，但实际上本不该如此。在了解了所要解决的问题之后，必须定义出清晰的目标和需求。比如，了解开发者的痛点，看看私有云将如何解决或缓解他们的问题。改进开发者体验，确保方案能够得到快速的实施，并取得长久的成功。

构建私有云需要专注，需要坚持不懈的毅力，需要强烈的动机，需要责任心和有效的沟通，需要进行所有权总成本分析，以便了解当前的服务成本。私有基础设施的日常运维是怎样的？需要为利益相关者定义拒付模型吗？如果有必要，那么有成功的先例吗？计划运行哪些类型的工作负载？如何简化容量规划？最小的预算和最大的预算分别是多少？你的解决方案能够与现有的CI/CD 管道和开发者工作流顺畅地集成在一起吗？你为你的工程团队准备好容器化的环境了吗？又或者你需要计划在混合云环境中使用容器吗？如果需要重新设计组件，那么就需要考虑这么做的成本。你的部署流程需要作出变更，为你的工程团队提供顺畅、积极正向的体验。你要定义好上层的SLA，并以KPI 的方式监控它们。在定义好策略之后，下一步就是制定战术和计划。

要记住一句话，计划得太多，反而不利于事情的进展。不过如果没有急切的目标，也就没有了动力。所以，需要在功能目标和现实技术之间做出权衡。

案例

#1 Adobe 的云广告平台通过TubeMogul 构建了自己的混合云解决方案。那么他们的愿景是什么？通过完全自动化的自有基础设施赋予利益相关者处理核心负载的能力，解决低延迟和大规模存储问题。他们的策略又是什么？通过简单的CI/CD 工作流在裸机和虚拟实例上实现性能和配置的灵活性。战术呢？使用开源的OpenStack 进行基础设施的编排和自动化。组建一支精益的团队开发和维护私有云，为开发者提供统一的CI/CD 工作流。

#2 在考虑使用私有云方案时，我们直接向我们的公有云提供商AWS 提出了质疑。我们对所使用的技术进行总体成本分析，疑问重重。在头三年的时间里，我们时刻准备着我们的私有云计划。在相当长一段时间内，我们的私有云计划成为与公有云提供商商谈价格的筹码（BATNA【1】）。

2. 设计的灵活性

在确定了你要交付的服务类型和运营模型之后，要在设计中保持足够的灵活性。研发阶段的投入是不可或缺的，你将需要进行多次迭代，并留有余地以便应对不可预测的情况。在进行技术选型时总会引发激烈的争论，然后是确定网络和服务器的规格。有句话叫“如果你要为大牲畜构建农场，就不要把它建成宠物的小窝”。在私有云架构里，你所选择的技术需要用上好多年，你要成为它们的拥护者，为此打造一个社区，支持它们，并让脾气暴虐的架构师们知道它的好处。做好升级计划，比如如何从 v1 升级到 v2。保持技术更新是支持新需求、跟随新趋势、留住人才的关键因素。

先交付一个可以带来关键商业价值的最小价值产品（MVP），后续再进行改进。尽可能利用裸机基础设施，而不仅仅是把私有云当成一个“IT 项目”。不要试图在内部构建另一个公有云，那是不可能成功的。你的方案要具备足够的灵活性，为开发人员提供有价值的支持。你要提供新的方案、API、服务，为工程利益相关者带来顺畅的体验。确保你的私有云服务遵循现有的标准，加快开发人员采用私有云的速度，并可以在多个云环境上重用功能。你可能还需要设计 SDN 并开发出一些服务层，当然，这些要视你的实际情况而定。

保持学习曲线的平滑和敏捷是非常重要的。从简单的开始，标准化开发者的工作流，用好 VLAN，部署核心服务（身份识别管理、网络、计算能力、存储），定义好清晰的升级路径。

案例

#1 在 TubeMogul，我们通过反复试错来进行技术选型或选择供应商。这当中有些技术可能已经不存在（CloudStack、Eucalyptus 等）了，最后我们选择了 OpenStack，并结合使用了裸机。我们最初的设计倾向于使用便宜但强大的日常硬件，结合简单的网络，并设计好故障应对措施。我们只用了 OpenStack 的核心服务，以及 Jenkins 的基本 CI/CD 工作流和用于配置裸机的 PXE。开发人员也使用了相同的 CI/CD 管道来管理跨云的 canary 和生产应用程序部署。多个环境之间需要具有标准的命名约定，我们才能重用现有的工具和服务。

3. 基础设施自动化

私有云部署很关键的一点是如何处理数据中心、网络和采购问题。这里涉及到资产管理和售后，它们很容易成为痛点，并给部署造成麻烦。所以，要想清楚你擅长做什么以及不擅长做什么。根据你的投资目标和团队结构的不同，你可能会承担很多压力，所以不要让那些供应商闲着。我时常提醒我的团队，VAR 指的是“Value Added Reseller”，所以不要忘了增值部分。根据参与度模型的不同，你可能需要定义好机架排布、线缆布局、端口映射、电力拉线等等。在极端情况下，你可能要使用以机架为单位的模型（rack-at-a-time）代替以服务器为单位的模型（server-at-a-time），直接将装备好的机架搬进数据中心。你只需要将机架接近核心网络就可以了，不需要自己组装和拉线。

在进行硬件自动化时，要确保你的设计适用于你的数据中心。你希望你的设计是 Top-Of-Rack【2】式的吗？或许你对 TIA 942-A 不甚了解，那么就让供应商提供想法并进行设计评审。这有可能会影响到硬件的选择和冷却通道的位置。这里有许多细节需要考虑。确保你考虑到了数据中心的空间位置和电力供应，知道如何利用现场人员处理售后问题。这些都是成功构建一个私有云的关键因素。

案例

#1 Adobe 广告云平台数据中心的最小化部署单位为两个机架。所有机架都由供应商搭建，然后进行自动化的镜像和组件部署。我们使用了 Puppet 进行配置管理，如果有一个资源处于空闲状态，或者经过售后之后需要进行重新部署，只需要标记一下状态，然后重新触发构建即可。

4. 自己搞定

你需要对自己构建的东西进行反复的测试，需要一个真实的实验室承担测试工作。你要感受到痛点，并把它们解决掉。

在跨过一系列坑之后，你要为利益相关者提供可见的数据，让他们了解整个流程。要敢于把整个私有云的状态和风险点展示出来。你是否做好了计算资源的容量规划？利益相关者是否了解网络的局限以及这将给他们的使用带来的影响？如何提供网络的可见性以便建立良好的信任和信心？是否存在过载的计算资源和超额认购？在进行迭代和增长时，这些问题都是需要解决的。

案例

#1 TubeMogul 的第一个 OpenStack 开发环境在一开始很成功，直到一个礼拜之后 Ceph 出现了问题，导致整个环境都崩溃了。这个环境是一个共享的环境，既是私有云的测试环境，也是开发环境。所以，我们得到了教训，就是不要将开发环境和利益相关者的环境混在一起。如果有人依赖你的服务，你就要承担起交付高质量服务的责任。

#2 做好容量规划是很难的，你希望了解你的业务，但又不希望业务的增长仅依赖你。知道什么时候提前增加容量至关重要。我们以两个机架作为部署单位，如果一个地方的资源不够用了，我们就增加两个机架。这个时候，设计的灵活性就发挥了它的作用，我们因此可以快速地扩展私有云。

结论

这是一个旅程。构建私有云不是件小事，而大部分公司未必需要私有云。如果有可能，就使用公有云吧。但如果要构建私有云，你需要搞清楚目标是什么。数据监管和业务决策将把你带向不同的方向。私有云并不是一个简单的工程项目，而是一个战略决策。了解大方向，取得利益相关者的支持，做好敏捷计划，以便进行迭代。Adobe 广告云平台经历了多个阶段，这些阶段都要求坚实的软件和运营工程来自动化基础设施。现在，我们交付了一个核心的基础设施，可以降低资源占用和延迟，处理更多的流量，甚至提供三倍于 AWS 原生网络的性能。

参考

【1】Roger Fisher 和 William Ury 在 1981 年出版的畅销书“Getting to Yes: Negotiating Without Giving In”中发明了术语 BATNA，它是“Best Alternative To a Negotiated Agreement”的缩写。

【2】 Cisco 数据中心的 Top-Of-Rack 架构设计

关于作者

****Nicolas Brousse，云计算领袖人物，在 TubeMogul（NASDAQ：TUBE）被 Adobe（NASDAQ：ADBE）收购之后，他成为了运营工程总监。Nocolas 领导了一支全球化的团队，包括 SRE 工程师、云计算工程师、安全工程师和数据库架构师，他们构建、管理和监控着 Adobe 广告云平台的基础设施。Nicolas 是美国技术大会的演讲常客，并经常为其他运营工程师提供建议。在加入 TubeMogul 之前，Nicolas 已经在技术领域拥有超过 15 年的经验，为 MultiMania、Lycos 和 Kewego 等公司管理高负载的数据库。

查看英文原文： The Five Steps to Building a Successful Private Cloud