博客

1-Click的演变…

通过 卡梅伦斯托克
| 最小值

几周前,在我们的Anaheim . next Conference的主题演讲中,Dheeraj强调了在管理升级的同时,我们的投资组合的增长所面临的挑战,同时还要保持我们来之不易的保持简单运营的声誉。

“五六年前,我们对AOS和Prism进行了升级。这就是增长的悖论——增长创造了复杂性。复杂性杀死增长。”

“从总体上看,升级的时间已经从半小时增长到我们一些客户的大型集群的四五个小时。

但这是责任的负担。它真的能照顾到所有的服务器、所有的固件和所有的管理程序——所有这些都不需要停机。”


这次会议的目的是真正从你们所有人那里得到反馈,让他们问:“在最复杂的事情上表现出色意味着什么?”因为我们的画布不再是五年前的那种简单的画布了。

帆布要复杂得多,酒吧Nutanix必须带来同样的快乐从我们的现有客户和新客户,谁看不出这种复杂性在他们面前,但去做这个快10倍——就像它是五年前,是这次会议应该是什么”。

视频在46:57开始,进入一键升级的故事。

回到绘图板进行1-click

在2016年初,很明显,我们需要一种新的方式来实现我们承诺的简单的1次点击升级,同时我们的投资组合也在扩大。很明显,值得信赖的旧设计——其中升级代码和逻辑被内置于AOS中——将无法解决问题。当每个产品或组件都是单独的或孤立的“1次点击”时,我们不能坐视不管,说我们有“1次点击”,因为我们一次只能执行一个组件。与此同时,随着投资组合的扩展,不同组件之间的依赖矩阵也会随之扩展。

我们需要速度,我们需要灵活性;我们需要捆绑升级,如果升级逻辑绑定到特定版本的AOS,甚至hypervisor内核,这些东西就很难提供。一些客户不经常升级他们的数据或管理平面,但对软件和固件的紧急修复(比如Spectre/Meltdown)和/或安全补丁却不断涌现。当今世界的安全形势有所不同,行动缓慢不再合适。

一定有更好的办法。

我们借鉴了消费者设计手册,开始像对待智能手机一样对待升级。想象一下,在这样一个世界里,每当开发者发布一个新版本的谷歌Chrome或微软Outlook,你都必须升级苹果的iOS系统——这是无法容忍的。然而,这正是企业IT的发展方向。你想要最新的幽灵修复?升级您的hypervisor内核或数据平面,这样我们就可以添加应用这些修复的能力。不,谢谢。这不是我们在Nutanix的方式。

LCM - Nutanix的“新”1-click

Nutanix生命周期管理器(LCM)就是为这个“应用程序”而创建的。最初,我们在2017年初决定在NX平台上专注于LCM支持固件升级——这是我们当时提供的一个缺口。戴尔(Dell) XC和联想(Lenovo) HX随后也推出了代工产品。HPE DX系列将在该平台在2019年第三季度进行GA时添加。2019年,至少有四家不同的硬件供应商提供的运行Nutanix软件的固件将能够“一键式”升级。

回顾过去,我们低估了为多个制造商提供真正的“一键固件”按钮的难度——这本身就是一个“10倍”的问题——一个没有其他公司代表“客户选择”意识形态解决的问题。“1次点击”的体验应该尽可能的相同,无论硬件是什么。

我们本可以走一条简单的路,让LCM先做我们自己的软件升级——这是我们已经知道的——但从固件升级中吸取的教训将使我们的软件升级交付得比我们想象的好得多。

在LCM的第一个版本发布两年后,我们已经覆盖了我们客户用于固件升级的大部分部署硬件平台,并且开发正在继续覆盖所有OEM合作伙伴关系。

LCM的旅程充满坎坷;例如引导设备的硬件制造商固件质量,以及使用Spectre/Meltdown修复程序对BIOS进行多次重启,导致LCM的声誉受到质疑。一些人哀叹将此类升级应用于大型集群所花费的时间。自然地,我们承担了交付机制的责任,通过这个机制,我们应用了这些制造商的固件,并承担了责任,不管原因是什么。当你的iPhone硬件坏了,你就把它拿回苹果,不管苹果的电池或内存是由哪个制造商生产的。也很好!

如果没有这些障碍,我们就不会做出更好的LCM框架设计更改,以帮助克服这些我们无法控制的外部因素,这导致了LCM旅程下一阶段的改进设计……软件升级。

LCM现在为软件升级做好了准备

2019年,LCM的重点已转移到软件升级,需要从内置在AOS/Prism的旧的一次一次单击过渡;专门解决Dheeraj在我们自己的产品线中提到的复杂性。我们想要镜像云体验,在那里保持集群的最新是不可见的——没有阅读的发布说明;没有停机时间;没有问题。惟一的交付方法是,升级逻辑与需要升级的实体解耦,与数据和管理平面解耦,并与hypervisor内核解耦。

作为一个“应用程序”,LCM可以在任何需要的时候升级自己,而不考虑在客户集群上运行的数据平面(AOS)、管理平面(Prism)或Hypervisor版本。这种将升级逻辑与这些实体解耦的方法带来了很大的灵活性。
虽然我们已经通过棱镜中心的LCM支持了Calm和carbon等软件,但我们很快也会添加Buckets。此外,在棱镜组件方面,我们将在未来几周内开始将NCC和AHV过渡到LCM进行升级。

引入中国大陆2.2

LCM的最新版本是第一个完全将其UI与Prism解耦的版本,这意味着我们可以随时更新UI,包括消息和UX布局,并在每次升级LCM“应用程序”时刷新它,而不会中断。您仍然可以通过Prism访问LCM,但是LCM现在可以控制自己的外观和功能,而不管集群上的Prism/AOS版本如何。

因此,在LCM 2.2中,你将看到一个完全重新设计的UI,提供了不同的视图、导出功能、更好的任务消息、升级状态和工作计划。

LCM的核心原则之一是消除IT管理员阅读发布说明的需要,因此依赖性处理和我们如何显示它也在改进。

自动处理依赖关系

LCM的魔力在于我们如何处理对另一个实体有需求的任何组件升级。例如,可能来自特定硬件制造商的BIOS升级也需要升级相关的BMC控制器。LCM不仅强调了这一点,而且还决定了应用升级的正确顺序。

下面的YouTube LCM 2.2演示演示了这个功能

在所有情况下,LCM中组件升级“模块”的创建者定义了他们的升级过程需要什么需求,而LCM代表管理员对其进行协调。这包括将升级“捆绑”在一起,或者在模块创建者允许的情况下将多个重启合并为一个。

OEM制造商可以定义他们自己的LCM“配方”,并决定升级的顺序,是否允许个别升级和其他合规规则。

最终,我们的目标是以一键式的方式提供一致性和可靠性的升级。

还有更多的事情要做

在我们完成整个投资组合向LCM的过渡之前,工作还没有完成。即使这样,我们也需要LCM的增长,以涵盖多集群升级、跨集群的节点移动、维护模式和其他公用事业操作,减少进行升级的时间、更好的暗站点选项、无需重启的升级,将LCM框架现有的自动升级特性扩展到其他组件,等等……10倍的挑战还在继续!也许有一天,我们会将LCM模块开发开放给第三方,将1-click扩展到Nutanix基础设施之外。

为了在规模上实现这种改进,任何分布式系统都必须采取步骤使其内部的操作更小。更小的特性和有效负载,例如通过容器部署——这就是为什么Nutanix已经开始了MSP/Kubernetes之旅,我们将继续探索使用这些技术以更快的速度交付升级的方法。AOS本身必须变小;我们通过数据平面提供的智能存储服务本身应该只是CVM之上的一个“服务”——完全处于hypervisor内核之外——将升级和新存储特性的部署缩短到几秒钟而不是几分钟。

三层基础设施升级耗时数月、耗资数万美元的日子必须结束了。管理程序和相关产品过于臃肿,管理员因为数十个依赖步骤而不敢进行升级的日子必须结束了。那些东西不像云。Nutanix和LCM正在努力结束这一切痛苦。

一如既往,我们重视反馈和建议,请继续关注。最终,我们想让Nutanix套件的运营,无论是内部还是外部,真正实现“一次点击”。请继续让我们保持诚实,并帮助我们实现目标……感谢和我们一起建立了LCM的客户。

前瞻性声明

这篇博文包含了关于我们正在开发的新产品功能和技术的计划和期望的前瞻性陈述,这些产品功能和技术的能力,以及我们在未来发布产品功能和技术的计划。这些前瞻性的陈述不是历史事实,而是基于我们当前的期望、估计、观点和信念。这些前瞻性陈述的准确性取决于未来事件,和涉及风险,不确定性和其他因素我们无法控制的,可能会导致这些语句是不准确的,导致实际结果,业绩或成就不同物质和负面的预期或暗示的语句,其中包括:引入或加速采用竞争性解决方案,包括公共云基础设施;行业或竞争动态或客户需求的转变;以及我们在提交给证券交易委员会的10-Q表格的季度报告中详细列出的其他风险。这些前瞻性声明仅在本新闻稿发布之日起发表,除法律要求外,我们不承担更新前瞻性声明以反映实际结果或后续事件或情况的义务。

©2019 Nutanix, Inc.保留所有权利。本协议中提到的Nutanix、Nutanix标识和其他Nutanix产品和特征均为Nutanix, Inc.在美国和其他国家的注册商标或商标。此处提及的所有其他品牌名称仅供识别之用,且可能为其各自持有人的商标。

Baidu