共计 2884 个字符，预计需要花费 8 分钟才能阅读完成。
| 导读 | Greene 表示，就像许多人一样，自己在冠状病毒疫情期间只能在家远程工作。其带领的 IT 团队在融合的 VMware 环境中进行数据库云容量管理。他表示，公共云提供商面临的容量管理问题与 Greeneideas 公司正在解决的问题类似。因此，其 IT 团队成员参加了各种在线供应商会议，并接受了在线培训，以了解在云计算世界中是否也遇到了类似的问题，以及可以学到什么技术和经验来改进分析和流程。 |
Greene 在了解云计算提供商对其客户的看法之后，并结合其丰富的工作经验，开始确定容量管理的挑战。因此，组织采用私有云可能被人们认为在特定计算机上的容量不足，也可能被认为公共云环境中的成本攀升。
Greene 为云计算环境中的容量管理提供的关键主题是：
- 需要建立所有利益相关者都能从自己的角度理解的容量模型。
- 采用应用程序团队在配置容量时可能并不真正知道他们需要什么。
- 要求比较苛刻的应用程序必须以不同的方式处理。
- 清理不是自然发生的，并将会浪费容量。
- 对于 IaaS、PaaS 和其他应用程序真正提供的内容，有许多不同的观点。
以下将深入了解这些关键主题：
第一个关键主题是需要建立一种所有利益相关者都可以理解的容量模型。无论是财务人员还是应用程序系统管理员，都需要提供 150 个服务器或 200 个容器的列表以进行使用情况检查，通常不会产生有效的结果。这是为什么? 相信很少有人能理解主机名或容器名称(或是服务实例)。经过尝试，Greene 带领的 IT 团队增强了从服务器和容器列表驱动的容量模型，并合并了配置管理数据库(CMDB)、数据库和操作系统监视工具中的数据。IT 团队到处获取信息，这些信息会将网络上的资源用于需要查看容量使用情况。因此，在与应用程序团队交流时，它有助于确定这些服务器上的数据库，所用数据库的版本(以便他们可以查看哪些数据库是为了满足风险要求而迁移出的原有数据库)，与涉及成本的人员沟通时，首先要使用生成账单的资源(磁盘、CPU、内存等)，然后将其映射到所涉及的各个应用程序团队以及所使用的版本。
在这些情况下，组织 IT 团队都可以看到他们关心的问题，并将其映射到应用程序或用户社区，这有助于他们评估是否仍然需要，并了解他们可能需要在哪里进行更改，例如从原有版本的 Windows 2000 迁移。基本上，它可以归结为一种模型，该模型能够提供一组量身定制的报告来帮助他们了解自己所拥有的东西，而不是逐项列出的账单说明所用资源。
Greene 表示，他们发现的下一个主题是，应用程序团队在首次迁移到云环境或构建新应用程序时可能不知道他们真正想要什么。他们通常具有可以打动用户的出色功能和构想，但是询问采用多少个 CPU 和多少内存等问题时，他们通常会询问供应商，并希望更好地运行他们的产品，而基础设施部门面临节省成本并提高利用率的压力，但最终会选择采用云计算服务。他们面临的挑战是，关于应用程序的接受程度以及下一步可能会想到的功能，存在很多假设甚至猜测。这通常会导致这样一种情况：必须迁移到不同的运营环境以满足他们的性能需求，这需要应用程序团队和基础设施团队花费大量时间和精力进行处理。
许多团队做出的一个假设是，可以构建适合所有应用程序的一种架构，但大多数大型公司都有广泛的投资组合，通常遵循 80/20 或 90/10 规则。通常情况下，只有少数应用程序能够推动业务发展、拥有庞大的用户群或需要更高的性能。因此，虽然大多数应用程序都能适应为用户设计的经济高效、高密度的环境，但重要的是需要更高性能的环境或可用的选择，而不是采用一种满足所有需求的解决方案。
另一个主题是清理不是自然发生的，并将会浪费容量。在公共云中，这通常是增加成本，而在私有云中，这通常表现为容量不足或意外增长。在大多数情况下，允许开发人员通过自动化的方式为他们的任务配置系统，但是当不再需要容量时，没有人进行清理。因此，当他们完成一个需要资源的特殊开发项目时，或者当他们迁移到数据库、Web 服务器或操作系统的下一个版本以满足架构或风险方面的标准时，没有人愿意放弃原有资源(也许他们想了解新资源是否真的有效)。如果不注意这一点，则随着组织在云平台中运营更长的时间，将会积累更多的无用数据。这里的关键是向负责支付账单的人员展示，或者证明他们使用私有云资源的正当性，以及他们所使用的与之相关的内容，以便他们能够做出正确的决策。
最后，许多组织开始迁移到云端，他们了解原有数据中心的利用率有多低，以及效率低下的 IT 设备带来的浪费。对这一点敏感的是，本地云计算供应商已经找到了将同一资源 (CPU、内存或 IO 带宽) 同时承诺给多个应用程序或虚拟机的方法。人们认为，共享这些资源的应用程序不太可能同时使用这些资源。
在通常情况下，对于 Web 服务器之类的事情来说，这是一个很好的选择，用户可以在一天之内快速响应 Web 发送的请求。但是，这对于数据库服务器而言可能并不好，因为数据库服务器可能需要几秒钟的时间来处理一些查询，并且数据库中的应用程序使用量往往会出现一些高峰。这里面临的挑战在于，如果每个人都对系统提出 CPU 或内存需求，那么系统就会进行交换，在交换过程中，系统会花费所有的时间将进程移入或移出内存，或者将系统堆叠到无法满足要求的程度。因此，在这个例子中，可以分析每个应用程序或产品(例如，数据库通常在启动时分配大量内存区域，而不释放它们，如果过度提交，则可能进行交换)，并为这一应用程序做出正确的决策，而不是根据供应商的实验室环境使用通用的指导原则。
最后一个主题是，人们对于 IaaS、PaaS 和 XaaS 的真正含义有很多不同的看法。应用程序团队可以阅读许多关于云计算可以做什么的文章，并且他们假设迁移到云端时，以某种方式获得了更多的功能和服务。Greene 表示，组织将会得到在系统中构建和设计的东西。从满足组织要求的备份，到故障切换自动化，再到防火墙安全性，所有这些都需要使用适当的供应商工具进行规划和实施，因为它们不是一成不变的。大多数云计算提供商为操作系统、磁盘速度、支持的应用程序甚至设置提供了很多选择和可能性。组织面临的挑战是大量的选择，并将它们转换为满足组织的需求并能与供应商的环境良好配合的配置列表。
从容量的角度来看，这些是在公共云和私有云应用的一些主题。相信每个运营环境都需要进行研究和建模，以使组织能够运行分析以查看容量问题所在。需要注意的是，容量问题实际上有两种：第一个是性能，组织会发现给定应用程序对于其当前位置而言太多了 (需要迁移到更好的运营环境)。第二个是总体容量管理(这将确保组织可以为给定的容器或虚拟机提供足够的资源)。这将成为永无止境的分析，因为一旦解决了一个问题，就有另一个问题需要解决。该模型帮助组织确定问题，然后可以使用环境中的工具(移动容器、迁移到新容器或可能移动到新架构) 来确保运营环境为未来发展做好准备。
