VMware和OpenStack经常被描述为相互竞争的两种私有云技术。虽然这两种技术其实可以互补,但一些组织却选择从VMware迁移到OpenStack的私有云上。
让我们来看看这些组织如何能同时使用这两种技术--无论是长期的,或是走向完全基于OpenStack的云的铺垫。
首先,要记住很重要的一点,OpenStack不是一个虚拟机管理程序。它可以通过抽象层支持大多数的虚拟机管理程序,这也为我们开启了可以使用它的自动编排能力的绝佳机会。
一个具体的例子可以清楚的解释这一点。Intel的IT部门在2010年实现了一个基于VMware的大型私有云以及一个单独的OpenStack云来支持KVM和Ceph。Intel的模式得到了进一步发展,可以使用OpenStack来编排这两个环境,除了Intel定制的自动化集合。
在2014年,Intel的IT托管机构处理了8000个人工服务请求,其中花费了190000个小时在等待完成。到2016年底,Intel预计,基于它们新的云模型,90%的人工服务请求可以立即自动处理,这大大的节约了时间。
大部分OpenStack的发行版本都支持ESXi以及VMware工具的使用。这会演变成使用vSphere 和VMotion的复杂的,多云多站点的操作来支持关键任务的应用程序。
Intel的做法是让VMware和OpenStack并存,但在某些情况下,企业希望用更低成本的虚拟机管理程序,如KVM,又能够结合OpenStack编排的好处。
从VMware转移到OpenStack私有云之前要了解的事情
鉴于许多企业在VMware上的前期投资,从VMware迁移到OpenStack的现象还是比较少见的。但事实上,这个迁移正在发生--而且是成功的发生--这引起了VMware客户群的注意。
有些公司采取了与Intel相似的做法。他们先从自己的工作负载中切割出一块可以在比如KVM上运行的很好的环节,将那部分放到OpenStack中。随着经验的积累,更多的业务操作会转移到OpenStack上。然后,公司便需要做出关键的战略决策:保留他们的VMware环境来执行关键任务的工作负载,还是全部迁移到OpenStack。
那些最广为人知的OpenStack迁移案例研究,比如eBay,Comcast和沃尔玛,往往是非常大的企业。这是因为迁移的过程是复杂的,且需要新的资源。此外,OpenStack的功能仍在不断发展,尤其是高可用性,存储和监控的功能。这解释了为什么OpenStack-VMware的混合模型会存在,这些组织使用VMware中好用的功能来填补OpenStack的空白之处。
常见的VMware到OpenStack的迁移模型包括:
两种云环境以及vSphere共存--例如之前提到的Intel的案例;
跨VMware和OpenStack资源池的可移植性,针对应用生命周期的某些部分采用不同的云;
以及完成最终到OpenStack的迁移
随着大多数的大公司都部署这种混搭的模型,使用OpenStack的管理功能来连接资源池似乎是不错的第一步。这正是Intel在走向可移植性和用户控制资源的过程中所做的。
从逻辑上讲,下一步是创建一个可移植的应用程序架构,可以允许应用跨池迁移。将此模型应用于新的应用程序,并且有选择地,应用到现有的应用程序上,基于它们是否应该被迁移或被替换。
无论你的最终目的是什么,是从VMware完全迁移出去,还是只留下VMware工具,而关键任务应用使用OpenStack的部分迁移,又或者可能只是使用OpenStack来控制VMware的资源池,这是一个应该要花上几年的过程,请做好不断尝试的心理准备。
好文章,需要你的鼓励
很多人担心被AI取代,陷入无意义感。按照杨元庆的思路,其实无论是模型的打造者,还是模型的使用者,都不该把AI放在人的对立面。
MIT研究团队提出递归语言模型(RLM),通过将长文本存储在外部编程环境中,让AI能够编写代码来探索和分解文本,并递归调用自身处理子任务。该方法成功处理了比传统模型大两个数量级的文本长度,在多项长文本任务上显著优于现有方法,同时保持了相当的成本效率,为AI处理超长文本提供了全新解决方案。
谷歌宣布对Gmail进行重大升级,全面集成Gemini AI功能,将其转变为"个人主动式收件箱助手"。新功能包括AI收件箱视图,可按优先级自动分组邮件;"帮我快速了解"功能提供邮件活动摘要;扩展"帮我写邮件"工具至所有用户;支持复杂问题查询如"我的航班何时降落"。部分功能免费提供,高级功能需付费订阅。谷歌强调用户数据安全,邮件内容不会用于训练公共AI模型。
华为研究团队推出SWE-Lego框架,通过混合数据集、改进监督学习和测试时扩展三大创新,让8B参数AI模型在代码自动修复任务上击败32B对手。该系统在SWE-bench Verified测试中达到42.2%成功率,加上扩展技术后提升至49.6%,证明了精巧方法设计胜过简单规模扩展的技术理念。