先交付一个可以带来关键商业价值的最小价值产品(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 做好容量规划是很难的,你希望了解你的业务,但又不希望业务的增长仅依赖你。知道什么时候提前增加容量至关重要。我们以两个机架作为部署单位,如果一个地方的资源不够用了,我们就增加两个机架。这个时候,设计的灵活性就发挥了它的作用,我们因此可以快速地扩展私有云。