mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-27 02:30:10 +08:00
translated
This commit is contained in:
geekpi
parent
1f27925a39
commit
8ec5a349f2
@ -1,78 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
How modelling helps you avoid getting a stuck OpenStack
|
||||
============================================================
|
||||
|
||||
|
||||
### Share or save
|
||||
|
||||
|
||||
|
||||
_Lego model of an Airbus A380-800\. Airbus run OpenStack_
|
||||
|
||||
A “StuckStack” is a deployment of OpenStack that usually, for technical but sometimes business reasons, is unable to be upgraded without significant disruption, time and expense. In the last post on this topic we discussed how many of these clouds became stuck and how the decisions made at the time were consistent with much of the prevailing wisdom of the day. Now, with OpenStack being 7 years old, the recent explosion of growth in container orchestration systems and more businesses starting to make use of cloud platforms, both public and private, OpenStack are under pressure.
|
||||
|
||||
### No magic solution
|
||||
|
||||
If you are still searching for a solution to upgrade your existing StuckStack in place without issues, then I have bad news for you: there are no magic solutions and you are best focusing your energy on building a standardised platform that can be operated efficiently and upgraded easily.
|
||||
|
||||
The low cost airlines industry has shown that whilst flyers may aspire to best of breed experience and sit in first or business class sipping champagne with plenty of space to relax, most will choose to fly in the cheapest seat as ultimately the value equation doesn’t warrant them paying more. Workloads are the same. Long term, workloads will run on the platform where it is most economic to run them as the business really doesn’t benefit from running on premium priced hardware or software.
|
||||
|
||||
Amazon, Microsoft, Google and other large scale public cloud players know this which is why they have built highly efficient data centres and used models to build, operate and scale their infrastructure. Enterprises have long followed a policy of using best of breed hardware and software infrastructure that is designed, built, marketed, priced, sold and implemented as first class experiences. The reality may not have always lived up to the promise but it matters not now anyway, as the cost model cannot survive in today’s world. Some organisations have tried to tackle this by switching to free software alternatives yet without a change in their own behaviour. Thus find that they are merely moving cost from software acquisition to software operation.The good news is that the techniques used by the large operators, who place efficient operations above all else, are available to organisations of all types now.
|
||||
|
||||
### What is a software model?
|
||||
|
||||
Whilst for many years software applications have been comprised of many objects, processes and services, in recent years it has become far more common for applications to be made up of many individual services that are highly distributed across servers in a data centre and across different data centres themselves.
|
||||
|
||||
|
||||
|
||||
_A simple representation of OpenStack Services_
|
||||
|
||||
Many services means many pieces of software to configure, manage and keep track of over many physical machines. Doing this at scale in a cost efficient way requires a model of how all the components are connected and how they map to physical resources. To build the model we need to have a library of software components, a means of defining how they connect with one another and a way to deploy them onto a platform, be it physical or virtual. At Canonical we recognised this several years ago and built [Juju][2], a generic software modelling tool that enables operators to compose complex software applications with flexible topologies, architectures and deployment targets from a catalogue of 100s of common software services.
|
||||
|
||||
|
||||
|
||||
_Juju modelling OpenStack Services_
|
||||
|
||||
In Juju, software services are defined in something called a Charm. Charms are pieces of code, typically written in python or bash that give information about the service – the interfaces declared, how the service is installed, what other services it can connect to etc.
|
||||
|
||||
Charms can be simple or complex depending on the level of intelligence you wish to give them. For OpenStack, Canonical, with help from the upstream OpenStack community, has developed a full set of Charms for the primary OpenStack services. The Charms represents the instructions for the model such that it can be deployed, operated scaled and replicated with ease. The Charms also define how to upgrade themselves including, where needed, the sequence in which to perform the upgrade and how to gracefully pause and resume services when required. By connecting Juju to a bare metal provisioning system such as [Metal As A Service (MAAS)][3] the logical model of OpenStack can is deployed to physical hardware. By default, the Charms will deploy services in LXC containers which gives greater flexibility to relocate services as required based on the cloud behaviour. Config is defined in the Charms or injected at deploy time by a 3rd party tool such as Puppet or Chef.
|
||||
|
||||
There are 2 distinct benefits from this approach: 1 – by creating a model we have abstracted each of the cloud services from the underlying hardware and 2: we have the means to compose new architectures through iterations using the standardised components from a known source. This consistency is what enables us to deploy very different cloud architectures using the same tooling, safe in the knowledge that we will be able to operate and upgrade them easily.
|
||||
|
||||
With hardware inventory being managed with a fully automated provisioning tool and software applications modelled, operators can scale infrastructure much more efficiently than using legacy enterprise techniques or building a bespoke system that deviates from core. Valuable development resources can be focused on innovating in the application space, bringing new software services online faster rather than altering standard, commodity infrastructure in a way which will create compatibility problems further down the line.
|
||||
|
||||
In the next post I’ll highlight some of the best practises for deploying a fully modelled OpenStack and how you can get going quickly. If you have an existing StuckStack then whilst we aren’t going to be able to rescue it that easily, we will be able to get you on a path to fully supported, efficient infrastructure with operations cost that compares to public cloud.
|
||||
|
||||
### Upcoming webinar
|
||||
|
||||
If you are stuck on an old version of OpenStack and want to upgrade your OpenStack cloud easily and without downtime, watch our [on-demand webinar][4] with live demo of an upgrade from Newton to Ocata.
|
||||
|
||||
### Contact us
|
||||
|
||||
If you would like to learn more about migrating to a Canonical OpenStack cloud, [get in touch][5].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Cloud Product Manager focused on Ubuntu OpenStack. Previously at MySQL and Red Hat. Likes motorcycles and meeting people who do interesting stuff with Ubuntu and OpenStack
|
||||
|
||||
|
||||
------
|
||||
|
||||
|
||||
via: https://insights.ubuntu.com/2017/07/18/stuckstack-how-modelling-helps-you-avoid-getting-a-stuck-openstack/
|
||||
|
||||
作者：[Mark Baker ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://insights.ubuntu.com/author/markbaker/
|
||||
[1]:https://insights.ubuntu.com/author/markbaker/
|
||||
[2]:https://www.ubuntu.com/cloud/juju
|
||||
[3]:https://www.ubuntu.com/server/maas
|
||||
[4]:http://ubunt.eu/Bwe7kQ
|
||||
[5]:http://ubunt.eu/3OYs5s
|
||||
@ -0,0 +1,76 @@
|
||||
如何建模可以帮助你避免在 OpenStack 中遇到问题
|
||||
============================================================
|
||||
|
||||
|
||||
### 分享或保存
|
||||
|
||||
|
||||
|
||||
_乐高的空客 A380-800模型。空客运行 OpenStack_
|
||||
|
||||
“StuckStack” 是 OpenStack 的一种部署方式，通常由于技术上但有时是商业上的原因，它无法在没有明显中断、时间和费用的情况下升级。在关于这个话题的最后一篇文章中，我们讨论了这些云中有多少陷入僵局，当时的决定与当今大部分的智慧是一致的。现在 OpenStack 已经有 7 年了，最近随着容器编排系统的增长以及更多企业开始利用公共和私有的云平台，OpenStack 正面临着压力。
|
||||
|
||||
|
||||
### 没有魔法解决方案
|
||||
|
||||
如果你仍在寻找一个解决方案来没有任何问题地升级你现有的 StuckStack, 那么我有坏消息给你: 有没有魔法解决方案, 你最好集中精力建立一个标准化的平台, 它可以有效地操作和升级。
|
||||
|
||||
低成本航空业已经表明, 虽然乘客可能渴望最好的体验, 可以坐在头等舱或者商务舱喝香槟, 有足够的空间放松, 但是大多数人会选择乘坐最便宜的, 最终价值等式不保证他们付出更多的代价。工作负载是相同的。长期而言, 工作负载将运行在最经济的平台上, 因为在高价硬件或软件上运行的业务实际上并没有受益。
|
||||
|
||||
Amazon、Microsoft、Google 等大型公共云企业都知道，这就是为什么他们建立了高效的数据中心, 并使用模型来构建、操作和扩展基础设施。长期以来，企业一直奉行以设计、制造、市场、定价、销售，实施为一体的最优秀的硬件和软件基础设施。现实可能并不总是符合承诺，但由于成本模式在当今世界无法生存，所以现在还不重要。一些组织试图通过改用免费软件替代, 而不改变自己的行为来解决这一问题。因此, 他们发现, 他们只是将成本从软件获取变到软件操作。好消息是，那些高效运营的大型运营商使用的技术，现在可用于所有类型的组织。
|
||||
|
||||
### 什么是软件模型？
|
||||
|
||||
虽然许多年来, 软件程序由许多对象、进程和服务组成, 但近年来, 程序是普遍由许多单独的服务组成, 它们高度分布式地分布在数据中心的不同服务器以及跨越数据中心的服务器上。
|
||||
|
||||
|
||||
|
||||
_OpenStack 服务的简单演示_
|
||||
|
||||
许多服务意味着许多软件需要配置、管理并跟踪许多物理机器。以成本效益的方式规模化地进行这一工作需要一个模型，即所有组件如何连接以及它们如何映射到物理资源。为了构建模型，我们需要有一个软件组件库，这是一种定义它们如何彼此连接以及将其部署到平台上的方法，无论是物理还是虚拟。在 Canonical 公司，我们几年前就认识到这一点，并建立了一个通用的软件建模工具 [Juju][2]，使得运营商能够从 100 个通用软件服务目录中组合灵活的拓扑结构、架构和部署目标。
|
||||
|
||||
|
||||
|
||||
_Juju 建模 OpenStack 服务_
|
||||
|
||||
在 Juju 中，软件服务被定义为一种叫做 Charm 的东西。 Charms 是代码片段，它通常用 python 或 bash 编写，其中提供有关服务的信息 - 声明的接口、服务的安装方式、可连接的其他服务等。
|
||||
|
||||
Charms 可以简单或者复杂，具体取决于你想要赋予的功能。对于 OpenStack，Canonical 在上游 OpenStack 社区的帮助下，为主要 OpenStack 服务开发了一套完整的 Charms。Charms 代表了模型的说明，使其可以轻松地部署、操作扩展和复制。Charms 还定义了如何升级自身，包括在需要时执行升级的顺序以及如何在需要时优雅地暂停和恢复服务。通过将 Juju 连接到诸如[裸机即服务（MAAS）][3]这样的裸机配置系统，其中 OpenStack 的逻辑模型可以部署到物理硬件上。默认情况下，Charms 将在 LXC 容器中部署服务，从而根据云行为的需要, 提供更大的灵活性来重新定位服务。配置在 Charms 中定义，或者在部署时由第三方工具（如 Puppet 或 Chef）注入。
|
||||
|
||||
这种方法有两个不同的好处：1 - 通过创建一个模型，我们从底层硬件抽象出每个云服务。2 - 使用已知来源的标准化组件，通过迭代组合新的架构。这种一致性使我们能够使用相同的工具部署非常不同的云架构，运行和升级这些工具是安全的。
|
||||
|
||||
通过全面自动化的配置工具和软件程序来管理硬件库存，运营商可以比使用传统企业技术或构建偏离核心的定制系统更有效地扩展基础架构。有价值的开发资源可以集中在创新应用领域，使新的软件服务更快上线，而不是改变标准的商品基础设施, 这将会导致进一步的兼容性问题。
|
||||
|
||||
在下一篇文章中，我将介绍部署完全建模的 OpenStack 的一些最佳实践，以及如何快速地进行操作。如果你有一个现有的 StuckStack, 那么虽然我们不能很容易地拯救它, 但是与公有云相比，我们将能够让你走上一条完全支持的、高效的基础架构以及运营成本的道路。
|
||||
|
||||
### 即将举行的网络研讨会
|
||||
|
||||
如果你在旧版本的 OpenStack 中遇到问题，并且想要轻松升级 OpenStack 云并且无需停机，请观看我们的[在线点播研讨会][4]，从 Newton 升级到 Ocata 的现场演示。
|
||||
|
||||
### 联系我们
|
||||
|
||||
如果你想了解有关迁移到 Canonical OpenStack 云的更多信息，请[联系][5]。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
专注于 Ubuntu OpenStack 的云产品经理。以前在 MySQL 和 Red Hat 工作。喜欢摩托车，遇见使用 Ubuntu 和 Openstack 做有趣事的人。
|
||||
|
||||
------
|
||||
|
||||
|
||||
via: https://insights.ubuntu.com/2017/07/18/stuckstack-how-modelling-helps-you-avoid-getting-a-stuck-openstack/
|
||||
|
||||
作者：[Mark Baker ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://insights.ubuntu.com/author/markbaker/
|
||||
[1]:https://insights.ubuntu.com/author/markbaker/
|
||||
[2]:https://www.ubuntu.com/cloud/juju
|
||||
[3]:https://www.ubuntu.com/server/maas
|
||||
[4]:http://ubunt.eu/Bwe7kQ
|
||||
[5]:http://ubunt.eu/3OYs5s
|
||||
Loading…
Reference in New Issue
Block a user