Cisco首次于2014年11月启动应用中心基础设施自启动以来,解决方案证明在数据中心大有成功。我不说这是自吹号角,而是指出在过去8年中CiscoACI被大小客户广布置在所有垂直或行业中。 内部工程团队以快速速度为新特征、能力与型态做了大量工作。并同时修复故障并解决安全顾虑
大型安装基地和软件发布选择的结果是,随着时间的推移,我们发现硬件和软件版本、特征和部署类型各种可能的组合。客户投资ACI实现最大潜力和最佳结果吗在许多情况下,我可以说是But there is still room for improvement. We see many customers on what I would consider older code. This not such a bad thing but it makes me wonder why. I have a few assumptions. Maybe upgrading ACI is seen as complex, or maybe it takes too long, or perhaps the confidence and knowledge in the process isn't there yet (after all we don't upgrade every day). I can sympathize. ACI fabrics are the foundation of all the important and business critical workloads that run our customers' businesses. Upgrades should be approached with planning and care and should be designed for zero to near-zero disruption. Furthermore, there is a constant balance between feature velocity and code maturity such that there is never one approach that fits all customers.
if you同我到此为止,我有一些好消息分享几条战线
新软件生命周期和Cadence
问题中最常问的是代码版本你推荐我运行吗?"
这个问题有时会让我出点汗,因为每个客户的数据中心都独有并构建解决具体需求。每个人的配置都大相径庭,可能没有一刀切的答案。像IT中的任何内容一样,它取决于
Imagine a range of customers where on one end you have a profile that cares more about features and capabilities. We have many of these types of customers, some of them quite large and sophisticated. They move fast and prefer to push the boundaries of what is possible because it tends to give them an edge in what they are trying to achieve. On the other end we have a customer profile that is mostly concerned with uptime and stability. This type is careful, and risk averse but with very good reason. Mission critical workloads want to avoid any kind of chance of interruption or inconsistency.
内部,我们想出一种新的方法 提供满足两种类型选择 ACI版本6.0见图1)
总体思想是提供清晰版本生命周期可见度,并一致定时添加或增强特征时与严格识别和修复错误时对比
Each major release (6.0, 6.1, 7.0 and beyond) will have a pre-defined lifetime of 4 years. This way everyone knows upfront where they may be in the cycle with a lot of time to plan for future upgrades when it makes sense to do so. Furthermore, within each major release, the first 12 months will be all about introducing or enhancing features. Our engineering teams publish point releases every 3-4 months on average. The result is that 6.0.1, 6.0.2 and 6.0.3 will all be feature releases. This is great for those customers who desire features most. Once we pass that year mark, we will move into a maintenance cycle where we no longer introduce features but focus solely on fixing bugs, enhancing stability and hardening security.
并发下一大发布模式与下一大发布模式相同,但一年后交错发布。如果剖面先求特征,您可选择上移下一大发布方式(从6.0x到6.1.x),但如果客户优先排序代码稳定性优先,您可继续当前发布时间跨余生客户可以在几年后升级,这些较新大发布器转入各自的维护周期(并因此获得特征和稳定性)
升级最佳做法
当时间实际升级时,最好做相应规划并开眼检查最优结果。多年来Cisco发布了很多文档和技术细节过程。我们所意识到的一件事是,这些文件并非全部在线集合并难客户获取所有信息指针。去年,我们重新组织、更新并收集所有升级相关内容,从中提供一页登陆.
更好的是,我们已经创建在线核对表细节过程的每一步都链接到更多有关该步的信息(见图2)这样便容易规划、准备并升级最少或甚至不停机时间。此清单后是升级最佳实践,我们大力鼓励使用
最后,为帮助添加更多颜色并分享经验, 我们向客户和伙伴提供网络研讨会 关于ACI升级最佳实践
查查点播客户网络研讨会.
合作伙伴可查看视频PIW-CiscoACI升级最佳实践.
实用工具帮助升级
最后一个好消息是我们已经发布一些有用的工具 来增加可见度 预查和引导
- DCapp中心门户上,我们加进一个a升级前验证器免费应用可安装并运行APIC上。它提供简单视觉方式预查布料方方面面与拟升级版代码对比。它虽然不完全化,但包括故障检验和常用推荐配置(像VPC配对中非节点)。
- 思科Github数据中心库ACI-Pre-Upgrade-Validation-Script.免费Python脚本复制到APIC并运行不熟悉 Python 进程极易并记录在上文链接中。此脚本与DCapp中心视觉应用相同。然而脚本运行多盘并更频繁更新。如果有自己的Github账号,你甚至可以打开特性请求添加检查请求并开发者会考虑这些请求。应用脚本和脚本都得到Cisco完全支持我比较喜欢脚本 给它能多做点
- Nexus平台透视图3企业更新分析特征是NexusDashboard Insights的有用功能之一,这些功能是专门设计用来处理和关照环境内多操作细节并交叉升级最综合工具推荐 NexusDashboard Insights应用环境。它比我提到的其他工具深入多一点, 因为它利用平台核心更多关联和机器学习。它执行详细检查前置并后传升级包括审查可用版本并关注相关错误,包括错误细节和发布注解链接 。升级前记录织物的健康、策略和运维状态,然后升级后再运行附加三角洲分析以查看有否变化或没有预期效果 。 如果有问题,Nexus Dashboard Insights会允许你快速挖掘并快速了解哪里、什么、何时或甚至建议如何纠正问题
深入了解NexusDashboard Insights等应用,https://www.cisco.com/go/nexusinsights
终极思想
升级您的ACIFABRIC从来就不简单了 。 您可以用智能、洞察力和清晰计划接近升级 。 没有理由不升级到最新版你最满意 。 获取特征、 稳定性、安全性并最终实现对CiscoACI投资最优回报 。 快乐升级
连接CISCO