🔥 热搜 🔥
百度今日热点微信公众平台贴吧opggdnf私服百度贴吧知乎dnf公益服百度傻逼
分类
社会娱乐国际人权科技经济其它
🔥 热搜 🔥
上海习近平新疆鄂州父女瓜乌鲁木齐疫情H工口小学生赛高习明泽芊川一笑图包印尼排华
分类
社会娱乐国际人权科技经济其它
查看原文
其他

关于虚拟化、Kubernetes和存储的讨论

常华Andy Andy730 2024-03-16
Source: Tim Darnell, Part 1: How We Got Here – Virtualization Solves Enterprise Challenges, Part 2: The Helmsman Arrives! – A History of Containers and Kubernetes, APR 25, 2023

第1部分：虚拟化如何解决企业挑战

首先，我们将介绍虚拟化和企业存储多年来为我们提供的所有好处，以及您能够为组织中的使用者提供的所有高效运营。

单个服务器，单个应用系统

让我给你一些关于我自己的背景。我于1997年开始从事IT工作，在一家土木工程公司担任系统管理员，为3D建模师和视频制作人员提供支持。在此之前，我在多家晶圆制造厂担任了近三年的工艺技术员，创造了集成电路，并在洁净室里上了12个小时的夜班，穿着完整的兔子服，用硅“制作香肠”。

我的第一个“办公室”装有一台HP Vectra和一台14英寸CRT显示器。正是在这里，我会把从惠普运来的Vectra台式机“改装”我在CompUSA购买的组件：额外的RAM、Matrox Millennium II显卡、Wacom绘图板和3Com以太网ISA NIC。然后，我会用3D Studio Max和Adobe软件使用它们，以便图形艺术家和3D建模师可以为土木工程建设项目创建前/后可视化。

这就是我了解“企业”存储和服务器的地方。我很幸运能够使用具有128MB RAM和近500GB SCSI存储的ALR Q-SMP四路奔腾133MHz服务器，该服务器由多个9GB希捷梭子鱼磁盘驱动器托盘组成。我也感到“幸运”，能够学习不同的处理器架构并维护DEC AlphaServer 2100A，它的内存“板”大约是一个披萨盒的大小。

我数不清有多少次我不得不卸下这些板并用压缩空气吹出该服务器中的插槽，因为服务器在重新启动后无法识别其所有内存！这就是我了解Windows NT 3.51和客户端/服务器网络的惊人（咳咳）操作系统的地方。与我长大的Novell NetWare和令牌环网络相比，它是如此“高科技”。

快进几年，我们得到了第一个运行光纤通道仲裁环路（FCAL）并为我们提供RAID5功能的Data General CLARiiON阵列。它的速度是我们旧的Ultra2/3 SCSI托盘的两倍！这是我第一次接触到NT 4.0上的Microsoft群集服务器的地方，因为我们可以对CLARiiON上的LUN进行多服务器访问，并使我们的应用系统在单个服务器发生故障时高度可用。这是开创性的。

但是，由于安全性、应用系统性能和“DLL地狱”（库依赖项）的分离，我们仍然在单个服务器上运行单个应用系统。这导致我们的托管空间中出现了一排又一排未充分利用的服务器—直到VMware在2000年代初发布了ESX，并彻底改变了一切。

VMware的出现颠覆了世界

起初，管理层中没有人愿意冒险使用在裸机上运行的应用系统，并使用PlateSpin和Vmware Converter等软件将操作系统转换为虚拟机。毕竟，在多个操作系统之间共享x86服务器和存储资源不可能提供我们习惯的相同性能，对吧？因此，我们开始将低风险应用系统和开发环境迁移到虚拟机上，并将QA和关键生产应用系统（如SQL Server、Exchange和SharePoint）保留在裸机上。

这很好，但是管理层和虚拟化支持者之间一直在争论我们应该虚拟化什么，不应该虚拟化什么。软件供应商不支持其软件的虚拟化实例，因此您必须在裸机上重现错误，并且许可方案仍然与裸机基础设施相关联。再加上“老派”服务器、网络和存储管理员将VMware视为“玩玩具”，虚拟化大山变得更加难以攀登。

VMware注意到，只有第2层和第3层应用系统真正实现了虚拟化，并为其合作伙伴开发了虚拟化关键业务应用系统（VBCA）计划。这使他们能够向客户证明VMware和ESX/ESXi已为企业中的黄金时段和第1层关键应用系统做好了准备。从那时起，VMware的创新和产品开发有了自己的生命，并催生了您作为虚拟化或企业存储管理员从此一直为消费者提供的许多企业功能。

虚拟化如何改变了管理员、开发人员和用户的体验

应用系统可用性
Vmware HA是企业中应用系统可用性的真正游戏规则改变者。在另一台运行ESXi的服务器上快速重新启动虚拟机的功能为我们提供了比以往更好的RPO。创建启动顺序计划并在服务器发生故障时让多层应用系统正确启动的能力将应用系统可用性提高到裸机环境中前所未有的水平。

资源利用率
Vmware DRS功能使我们能够正确利用服务器资源—在许多情况下，每个物理服务器的CPU/内存利用率从个位数提高到70%-80%。DRS使我们能够在大型多服务器群集之间适当平衡虚拟机资源利用率，并从企业中购买的每台服务器中获得最大价值。这降低了与机架空间占用、功耗、网络和SAN容量以及服务器维护相关的成本。

成本管理和员工技能
同样，降低基础设施成本是一个巨大的好处，因为资源利用率和通过提高应用系统可用性来防止停机成本。在人员配备方面，VMware为历来被降级为基础设施（计算、网络、存储）单一堆栈的管理员提供了拓宽技能组合并转变为全面发展的基础设施工程师的机会。

在我看来，这确实是平台工程诞生的地方，为我们今天拥有的虚拟化技能和工具箱赋予了生命。虽然大型企业和环境需要专门的基础设施人员，但创建VM管理员角色使许多组织有机会减少员工支出，进一步降低成本，并为VM管理员提供在职业发展过程中深化和拓宽技能的能力。

数据和应用系统可移植性
使用VMware从裸机层抽象出来，为我们提供了一些非凡的功能，可以在本地群集和地理位置不同的数据中心或办公地点之间移动应用系统及其数据。vMotion和Storage vMotion改变了我们组织内两个连接的VMware集群之间的迁移游戏规则。

此外，我们不必构建新的服务器实例并从磁带或便携式硬盘恢复数据，我们现在可以将虚拟机及其所有必要数据导出到OVF，并在新的断开连接的位置启动并运行它—只需将OVF导入新的ESXi集群即可。这对于在开发、QA和暂存环境之间复制环境以快速建立多层应用系统环境也是一个巨大的好处，从而减少了基础设施启动时间并最大化了开发工作流。

容量管理
除了在物理服务器上共享CPU和内存资源的明显优势外，共享存储和数据存储的概念还使我们能够最大限度地利用底层企业存储基础设施的投资。与其增加SAN环境中的容量怪物并分配多个可能只有10%利用率的LUN，我们可以调整存储分配的大小并根据需要增加它们。

能够在不影响VMFS数据存储上运行的虚拟机的情况下动态扩展和增长VMFS数据存储，这使我们能够确保主动而不是被动地处理数据增长，从而为应用系统可用性和成本管理提供进一步的好处。

存储基础设施
我的职业生涯从系统管理员晋升为顾问，在那里我提供了使用EMC存储和思科UCS计算的VCE Vblock解决方案和融合解决方案。然后，我跳到了供应商领域，在日立工作了近10年。这就是我亲眼看到如此多创新的地方。

随着VMware为路径选择和故障切换等提供VASA和VAAI集成，通过基于存储策略的管理（SPBM）提供阵列供应商的存储功能，以及vVol和vSAN的开发，以便客户可以使用商用硬件，历史存储管理员角色的游戏规则发生了变化。我们不必仅仅依靠存储管理员来提供存在于我们阵列中的企业功能，我们终于有了一种方法来向VMware管理员角色展示这些功能。它确实减少了VMware和存储管理员之间的摩擦。

开发人员敏捷性
在裸机时代，我们为开发人员部署一台服务器需要多少小时/天/周？从机架空间、电源、网络和存储的资源规划到服务工单和变更咨询委员会的批准，再到购置成本和接收设备的时间，开发人员等待基础设施的时间可能比需要的要长得多。

借助VMware的抽象层，创建虚拟机模板并提供虚拟机的自助部署，以便他们在开发过程中更加敏捷，这再次改变了游戏规则。然而，这带来了虚拟机蔓延的额外挑战。它有时会导致资源过度分配，因此您必须小心开发人员和最终用户的启用情况！这是我们今天所知道的DevOps实践的萌芽期吗？

灾难恢复
在VMware宣布推出站点恢复管理器（SRM）之前，我们在虚拟化环境中向消费者提供低RPO和RTO的能力有限且复杂。这使企业阵列供应商能够为其特定阵列创建存储复制适配器（SRA），将阵列微码中的复制功能绑定到SRM内部的工作流中。我们最终不仅可以异步复制虚拟机正在使用的VMDK，还可以异步复制vCenter和ESXi服务器中的所有虚拟机对象。VMware还使我们能够为多虚拟机应用系统执行故障切换蓝图，以确保我们的应用系统在灾难发生之前正确运行到远程站点。

在SRM之后不久，VMware推出了一个名为Vmware Metro Storage Cluster（VMSC）的同步解决方案。这使得具有同步复制能力的企业阵列供应商能够为客户创建零RPO灾难恢复解决方案，从而进一步扩展虚拟化环境的业务连续性功能。我仍然记得仔细阅读Duncan Epping的Yellow Bricks和Eric Shank的The IT Hollow博客以了解这些技术，并在Hitachi设计VMSC解决方案，使我们的客户能够使用这项突破性技术来满足以前无法想象的SLA！

安全性、加密和RBAC
显然，VMware环境中需要的一项主要企业功能是安全性。从与思科和帕洛阿尔托等供应商提供的行业领先的安全解决方案集成（还记得Nexus 1000V吗？）和虚拟机和VMDK级加密，到vCenter中全面的RBAC角色，VMware再次为我们提供了保护VMware基础设施所需的一切。由于我们在单个服务器上的应用系统体系结构中组合了如此多的不同层，因此安全层的抽象至关重要，从特定垂直行业的监管角度来看尤其重要。

数据保护
任何了解虚拟化早期的人都记得我们在数据保护方面遇到的挑战。我们过去常常将第三方备份客户端加载到我们需要保护的每个操作系统上，这些操作系统将与中央备份服务器连接，该服务器会将我们的数据流式传输到磁带。然后是备份供应商集成VMware的日子，他们提供了查询VMware基础设施和实际备份整个VM的能力，然后允许恢复到任何其他VMware群集。

这带来了一系列挑战，直到基于磁盘的备份、快照和具有重复数据删除功能的更改块跟踪（CBT）问世。我们不再需要担心磁带库、银行保险库或Iron Mountain的异地磁带存储，以及备份服务器的网络瓶颈。如果您和我一样，您还记得能够获得NFR许可证作为Veeam等软件的VCP，您可以在家庭实验室中使用它来保护您的数据。同时，您还学习了如何正确保护虚拟化基础设施上的组织数据和虚拟机！

性能
CPU和内存的资源预留与厚置备存储和非抽象存储（如vVols）相结合，使我们能够为虚拟机提供近乎裸机的性能。随着处理器核心密度随着网络和存储吞吐量的增加而增加，我们终于能够保证应用系统和托管它们的虚拟机的性能要求。现在，企业存储解决方案带来了突破性的性能功能，可以保证为客户提供尽可能高的性能级别。

进一步整合：万物的aaS化
亚马逊早在2006年就开始整合公有云基础设施，当时许多组织正试图利用他们使用VMware和自己的硬件构建的私有云基础设施。许多组织对将基础设施密钥移交给公有云相关的成本和感知风险持谨慎态度，并希望利用他们对自己的基础设施的投资。

在自己的组织内为消费者提供自助服务功能以进一步整合基础设施服务是该镇的话题，VMware通过发布Vmware Cloud Director（VCD）等产品以及OpenStack等其他解决方案再次提供了创新。由此，基础设施即服务（IaaS）诞生了。

一旦组织开始使用IaaS，许多行业都遵循平台即服务（PaaS）和软件即服务（SaaS）引领潮流。此后不久，一切都作为服务提供：灾难恢复、数据保护、台式机、存储和网络。甚至监控也作为一项服务提供！这极大地改变了支出和资源分配，因为组织更专注于使用服务，而不是虚拟化为我们提供的重基础设施和专业知识的方法。

由此开始了下一代应用系统开发和消费的转折点，转向更加以开发人员和应用系统为中心的方法。基础设施不再是王道，而是自下而上地推动应用系统开发。开发商成为王者，基础设施必须跟随！


第2部：容器和Kubernetes的历史

建立在巨人的肩膀上

基于容器的技术并不是什么新鲜事，就像虚拟化和虚拟机管理程序并不是什么新鲜事（至少在非x86架构上—参见LPAR）。事实上，我们可以追溯到1979年的容器根和UNIX V7中引入的chroot进程。虚拟机使我们能够分离出在单个裸机服务器上运行的多个操作系统，而chroot使我们能够在单个操作系统中创建和分离软件系统的虚拟化副本。

查看这种差异的另一种方法是，虚拟机模拟整个“计算机”实体，包括硬件和运行操作系统所需的一切。但是，容器在现有操作系统中运行，并利用该操作系统中的资源-代表具有独立CPU、内存和文件系统的虚拟用户空间来运行受保护的进程。就密度而言，我们通常可以在裸机上运行比虚拟机多三到四倍的容器，因为没有基本底层操作系统二进制文件和库的多个副本。


现代化容器开始出现

流程容器是由Google在2006年左右开发的，是我们今天所知的容器的真正起源。然后它们被重命名为cgroups，并在2008年合并到Linux内核中。这些cgroups缺乏管理其生命周期的管理结构，Cloud Foundry的Docker和Warden等产品被开发用于处理容器的生命周期管理（将Vmware vCenter视为并行）。

在2013年Docker出现之前，没有一个容器管理项目或产品真正起飞。

寻找最佳交响乐指挥家与CNCF的崛起

Docker到来后，容器使用的爆炸式增长为市场带来了大量的容器编排产品，如Docker Swarm，Apache Mesos，HashiCorp Nomad，Pivotal Cloud Foundry，以及Google一个名为Kubernetes的新的有趣的开源项目。

对于许多客户来说，这种情况令人困惑，这在任何早期技术采用阶段都是典型的，客户试图确定“押注哪匹马”。一些编排器支持（并且仍然支持）付费产品的免费和“企业”版本，但由于100%开源的容器编排方法，x86容器社区的兴趣在很大程度上被Kubernetes激起。

Kubernetes于2014年在Google成立，其设计深受内部集群管理器Borg和曾在Borg工作的开发人员的影响。Kubernetes从Google的内部使用经验中引入了经过验证的方法，以管理、编排和自动化动态、基于容器的生态系统中存在的CRUD（创建/读取/更新/删除）流失。Google与Linux基金会合作创建了云原生计算基金会（CNCF），Kubernetes1.0于2015年发布！

到2017年底，大多数容器平台都引入了Kubernetes支持，Kubernetes终于获得了它的桂冠——到2018年，大多数客户已经迁移到Kubernetes。

现在，在了解如何管理现代化应用系统堆栈和基础设施时，您可能听说过“畜牲与宠物”一词。这句话背后的故事是，与其像我们过去对待虚拟机（宠物）那样以永恒的关怀和脆弱性对待基础设施，你不应该关心基础设施是否在你身上死亡，一切都应该是可替换的（畜牲）——这是云原生基础设施和DevOps的纯粹观点。但是，这对需要持久存储的有状态应用系统有何影响？

短暂（非持久）存储是Kubernetes从一开始就假设大多数Pod会消耗存储的方式。一些纯粹主义者仍然认为，短暂存储应该是容器化应用系统中使用的唯一存储，并且持久存储需求应该从Kubernetes和容器之外提供服务。但是，仍然有许多应用系统需要持久存储，并且希望在Kubernetes内部运行这些服务以及其临时容器的客户！

在Kubernetes时间线的早期，存储厂商直接为Kubernetes代码库做出贡献，为其特定的企业存储硬件提供持久的存储功能（从VMware的角度考虑VAAI/VASA/SPBM）。然而，供应商对Kubernetes的直接贡献很大，而且不能很好地扩展，所以容器存储接口（CSI）规范诞生了！这使得供应商能够在树外编写驱动程序，而无需直接为Kubernetes代码库做出贡献，并保持Kubernetes发布的速度-开源并与任何单个企业供应商分开。

为什么外部CSI只是一个辅助

随着CSI驱动程序的消失，存储厂商可以选择是做他们一直做的事情并创建与外部存储控制器硬件的集成，还是创新和创建云原生存储解决方案。大多数企业硬件阵列并不是为处理CRUD生命周期每天创建的数千个配置操作、快照/克隆操作或API请求而构建的。将控制平面迁移到Kubernetes以获得真正的云原生存储体验是跟上CRUD流失的唯一答案。

由于大多数传统CSI驱动程序依赖于外部硬件控制器功能进行快照、克隆和复制等操作，因此使用或需要这些类型功能的应用部署的一致性必须在每个站点上具有相同的硬件。这种方法正是存储厂商想要的—因为它允许他们销售“更多设备”并在客户环境中站稳脚跟，从而锁定供应商并强制升级新的机型。客户面临的挑战是，他们现在必须确保在正确或特定的存储硬件上运行，而不是专注于在其应用系统中提供创新的解决方案。这完全违背了我们在第1部分中讨论的以开发人员和应用系统为中心的模型！

传统架构和Kubernetes架构之间的常见挑战

这是关于容器、编排器以及Kubernetes中的有状态应用系统如何跨不同平台和基础设施的持久存储挑战的相当多的历史。如果你像几年前在我的职业生涯中一样，可能会感到不知所措，可能会有一些你不理解的东西，或者你可能会对如何将我们在虚拟化环境中习惯的所有企业优势带到Kubernetes基础设施中感到困惑。

起初，我盲目地进入了Kubernetes。我的意思是，我是一个三重VCAP，精通Linux，几乎看到了虚拟化世界的一切，并帮助公司使用这些技术取得了成功，所以这应该是轻而易举的，对吧？在我之前的工作中，当我被要求开始围绕在Kubernetes上运行的有状态应用系统为客户开发参考架构和设计时，我不断遇到障碍。我了解到，如果我要提供我在VMware领域已经习惯的相同的企业功能和体系结构，这并不像看起来那么简单。

这些障碍主要是由于外部CSI驱动程序的限制因素造成的，这些驱动程序必须与我需要包含在这些体系结构中的特定硬件阵列一起使用。我无法为在Kubernetes中运行的有状态应用系统开发合适的云原生架构，该架构可以跨本地、公有云和不同的硬件进行扩展。我很快明白，我需要的是一个一致的存储层，可以在任何地方使用，以及我想要提供的任何后备存储，无论是企业阵列、EBS或Azure磁盘，还是来自超融合服务器的简单本地驱动器。

让我们看一下我们在博客系列的第1部分中讨论的相同领域，这些领域涉及虚拟化如何改变体验，以及其中一些挑战如何挑战Kubernetes环境中有状态应用系统的并行体验。

应用系统可用性
Kubernetes运行一个调度程序，该调度程序可以通过部署和守护程序集在Kubernetes集群中的可用节点上动态部署容器。但是，容器的存储可用性问题仍然存在，因为持久存储是一个依赖于CSI功能的独立实体。

您认为vSAN在VMware环境中的这种情形下会有什么帮助？当vSAN群集中的节点出现故障时，虚拟机存储会发生什么情况？

资源利用率
适用于Kubernetes的云原生存储解决方案使用群集节点上的资源，控制平面资源将作为群集上的工作负载运行。无论预置或使用的卷数量如何，任何云原生存储解决方案都必须占用较小的空间。

如果随着您部署越来越多的虚拟机，ESXi虚拟机管理程序资源使用的CPU和内存呈指数级增长，您的应用系统工作负载容量会是什么样子？

成本管理和员工技能
使用Kubernetes进行存储管理，尤其是在组织转向多云环境时，成本可能很高—不仅从底层卷的角度来看（如果精简配置和容量管理等功能不可用），而且从人员配备的角度来看也是如此。

如果您没有用于VMware存储的VMFS抽象层，该怎么办？跨不同的存储后端提供一致的企业服务是否具有挑战性，不仅从操作角度，而且从维护、故障排除和人员配置角度？

数据和应用系统可移植性
Kubernetes中的应用系统是通过YAML清单部署的。对于有状态应用系统，在集群之间移动或复制应用系统以进行蓝绿测试需要两个步骤：首先，复制或备份/还原底层持久存储，然后使用存储重新部署容器（应用系统）。

如果像vMotion这样的东西可用于跨Kubernetes集群迁移容器及其持久存储，会怎么样？

容量管理
同样，Kubernetes使用其调度程序从CPU和内存角度提供了出色的容量管理。但是，存储的容量管理由所使用的存储提供程序决定。同样，当没有提供一致的存储层时，这带来了各种挑战。精简配置和适当调整存储大小在动态、高流失率的环境中（如Kubernetes集群）至关重要。

如果您能够在VMware中的VMDK上设置策略，以便根据VMFS或vSAN数据存储的功能自动增长VMDK并扩展底层文件系统，情况会怎么样？这是否有帮助，并防止虚拟机在磁盘意外填满时惊艳？

存储基础设施
由于Kubernetes依赖于CSI实现来提供特定的存储功能，因此确保跨不同基础设施的功能对等至关重要。快照、卷迁移和复制等原语是很好的附加功能，必须与我们在VMware基础设施中拥有的企业功能相匹配。但是，随着应用系统部署在不同的平台和基础设施中，诸如能够支持Kubernetes中最流行的卷模式（如ReadWriteOnce（RWO）和ReadWriteMany（RWX））之类的关键功能变得非常重要。

如果vSphere快照不存在，而您必须依靠底层存储硬件来执行VMDK的快照，该怎么办？它们是否便携、一致且兼容？

开发人员敏捷性
开发人员通常在Kubernetes环境中自行构建和部署他们的应用系统。当需要持久存储时，开发人员可以创建引用StorageClass的PersistentVolumeClaims（PVC），该StorageClass定义了他们需要的特定存储功能。它与vSphere中基于存储策略的管理（SPBM）的工作方式非常相似—策略定义存储功能（StorageClass），并且可以在请求置备vVol（PVC）时引用。这允许开发人员根据应用系统的存储要求自助进行持久卷预配。

在使用SPBM之前，您是否能够轻松地为开发人员提供自行调配特定存储功能的能力？如果他们需要调配具有类似功能的卷，但由不同站点的不同存储硬件提供支持，该怎么办？

灾难恢复
Kubernetes没有为有状态应用系统内置原生灾难恢复功能。众所周知，在一组集群的两端有一个一致的存储层进行复制对于VMware中低接触和适当的灾难恢复计划的成功至关重要，在Kubernetes中也不例外。一些供应商可能声称拥有通过简单备份和还原为Kubernetes提供灾难恢复解决方案。但残酷的事实是，除非您能够绑定到存储层并执行适当的异步和同步复制，否则我们多年来所知道的灾难恢复是不可能的。

您是否将简单的备份和恢复作为灾难恢复的唯一方法，并在VMware环境中的业务连续性计划中满足业务关键型RPO和RTO？

安全性、加密和RBAC
加密内置于Kubernetes中，用于加密etcd（Kubernetes的配置数据库）中的数据。存在全面的基于角色的访问控制，用于控制对Kubernetes中对象的访问。但同样，存储在Kubernetes中被视为一个单独的公民，用于持久存储的存储解决方案必须独立于Kubernetes支持这些原语和功能。

如果私有云VMware云中的每个租户都可以对另一个租户的VMDK进行未加密的访问权限，您会感到舒服吗？

数据保护
就像传统的裸机备份解决方案必须过渡到支持VMware基础设施一样，Kubernetes的备份解决方案需要支持Kubernetes集群中使用的所有原语，以实现适当的数据保护。具有命名空间感知能力、具有应用系统一致性备份的能力、遵守3-2-1备份规则、提供勒索软件保护以及还原到单独的Kubernetes集群的能力是支持Kubernetes数据保护的关键功能。

对于您的VMware环境，您必须在每个虚拟机上加载第三方代理，使用适用于裸机的备份解决方案，您是否愿意这样做？

性能
云原生存储解决方案的存储性能至关重要，不应依赖于其他协议以高性能方式运行。应尽可能使用存储和文件系统对容器的本机表示，以确保高水平的IOPS和吞吐量，而不考虑基础应用系统的I/O配置文件。此外，控制IOPS和吞吐量的能力（想想VMware中的存储I/O控制）对于防止Kubernetes集群上出现嘈杂的邻居情况至关重要。

对于在VMware环境中需要高性能的应用系统，您是否会将高性能CPU和内存与低性能存储相结合？如果无法控制干扰邻居情况，并且一个虚拟机消耗了共享VMFS数据存储的后备存储的所有IOPS或吞吐量，则可能会面临哪些挑战？
继续滑动看下一个
Andy730
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题？点此查看未经处理的缓存