OpenShift 虚拟化是红帽推出的一款解决方案,目标用户是那些希望通过采用容器化架构来推动应用现代化,但同时认识到虚拟化在其数据中心部署策略中仍必不可少的企业。
坦率地说,尽管有些应用依然无法实现容器化,但这没有关系。为了解决这个问题,OpenShift 虚拟化提供一种更现代的范式,在一个统一平台中一致地管理对容器和虚拟机的需求。
红帽必须攻克的一个难题是:在提供功能对等的同时,如何确保新解决方案能够延续客户所熟悉的产品和配置体验,从而使得这一采用过程对客户而言几乎是轻而易举的。
一旦在信息技术生态系统中游刃有余,人们往往会试图将熟悉的原理运用到新的系统。VMware vSphere 已成为众多系统管理员常用的一个数据中心虚拟化解决方案。在这种环境中工作的人们引入了诸多设计解决方案,并将其用作部署和配置虚拟机及虚拟数据中心的最佳实践。对于此 IT 领域的从业人员来说,这些设计决策已近乎本能,因此在规划新环境时,他们很可能会自然而然地尝试采用类似的决策模式。
本博客系列将探讨企业及其虚拟化管理员如何与传统的虚拟机监控程序环境互动,以及他们如何在 OpenShift 虚拟化领域中实现相似的操作与配置,重点关注两者的差异。
首先,让我们聚焦于诸如 VMware vSphere 等其他虚拟化解决方案中常见的多网络设计。熟悉的人都知道,此类环境中的 ESXi 主机通常具备支持多种网络配置的能力,每种虚拟网络专用于虚拟数据中心内的某一用途。这种网络隔离有多种实现方式,比如,可以将主机上的不同物理 NIC 连接到上游的不同交换机或网络;或者,通过上行链路中继其他 VLAN,并验证这些 VLAN 在虚拟机监控程序中的 vSwitch 或分布式 vSwitch 上是否正确标记,以指明其预期用途。最常见的网络环境至少细分为以下网络:
- 用于 ESXi 主机和 vCenter 虚拟机以及可能部署的其他第三方管理主机的管理网络。
- 用于 ESXi 主机的主机迁移网络,可支持在主机之间进行客户机热迁移(称为 vMotion),以提供高可用性。
- 供 ESXi 主机访问存储资源的主机存储网络,这些资源为虚拟机提供了后备存储或客户机映射存储。
- 为虚拟客户机本身提供网络连接的虚拟机网络。
除了上方列出的网络外,根据特定客户环境的用例,他们常常还会遇到独特的网络配置和用途。就其本质而言,虚拟交换技术有助于轻松实施大量不同的配置。因此,可想而知,对于那些习惯于用通俗易懂的方式定义网络的人们来说,当决定采用像 OpenShift 虚拟化这样另辟蹊径的解决方案时,可能会惊讶不已。
以下几个小节将逐一介绍上述每个主要用例,并演示 OpenShift 虚拟化如何满足这些需求。
默认情况下,OpenShift 虚拟化在安装时会配置一个内部容器集网络。与 Kubernetes 环境中部署的任何其他应用一样,这个内部网络用于在其生命周期内与容器集本身通信。借助 OpenShift 控制台、virtctl CLI 实用程序或 oc 命令,您可以通过内部 API 网络来执行虚拟客户机的所有基本管理功能。基本上,OpenShift 虚拟化中的这个网络所执行的操作,管理员也可在 VMware vSphere 环境中通过内部管理网络实现。
尽管 OpenShift 环境中的所有网络功能都可以通过默认的容器集网络来处理,包括上述针对简单配置所详述的管理功能,但这种做法通常并不可取。对于某些任务,如虚拟客户机迁移和存储访问,直接从专用网络进行访问的优势巨大。虽然有多种方法可以通过迁移策略来调优某些操作(如客户机迁移等)的性能,以限制所使用的带宽量,但大多数企业用户都会认同,为客户机迁移、存储和虚拟客户机访问等其他功能配置专用网络是可取的做法,对于那些之前在 VMware vSphere 环境中操作过的人员来说也更加熟悉。
为此,OpenShift 采用了 Multus CNI 插件。借助该插件,您可以配置额外的网络接口、SR-IOV 或 Linux 网桥设备供工作节点使用,以便根据需要将它们附加到各个容器集。
在安装 Multus 之前,客户端必须对底层网络进行相应的配置。对于 Linux 网桥,这将通过使用 nmstate 操作器来执行。对于 SR-IOV 设备,您将使用 SR-IOV 操作器。配置了网络环境后,管理员可以着手配置网络附加定义,以指示 OpenShift 如何使用额外的物理接口、SR-IOV 设备或定义它们的 Linux 网桥。
接下来,我们来深入探究实时迁移的配置。鉴于实时迁移的带宽需求,许多 VMware vSphere 部署都定义了专用网络来支持 vMotion。如果基础架构中发生实时迁移事件,但没有专用于该任务的网络,则可能会对虚拟客户机等共享网络资源产生负面影响。如果节点变得不可用并且多个客户机被迫同时迁移,这也会影响环境本身的管理。OpenShift 虚拟化中提供了多个选项,可用来防止实时迁移事件对集群的主要网络或性能造成负面影响。
其一是定义包含规则的迁移策略,包括用来限制可用于迁移的带宽量的一些规则。也可以通过修改 OpenShift 虚拟化概述设置下的集群设置,为实时迁移定义一个专用网络。在此菜单中,您可以限制在任何给定时间可以进行的实时迁移数量,从而达到节省带宽的目的。您也可以修改用于这些实时迁移的网络。
为此,请在工作节点上为专用网络接口创建网络附加定义,并定义一个私有网络来允许仅在配置为支持虚拟化的工作节点之间进行连接,然后选择这个网络。这样,当选择一个客户机进行迁移或将一个主机置于维护模式以强制所有客户机让位时,将使用由实时迁移专用的网络,从而防止对主 OpenShift 网络基础架构造成额外压力。
存储资源网络将取决于用于 OpenShift 集群的存储提供商。许多存储提供商为其存储系统提供符合 CSI 规范的原生驱动程序,它们会自动应用其指定的存储连接最佳实践。
从 OpenShift 虚拟化角度来看,可以遵循一些建议的最佳实践来配置存储类,以便支持虚拟客户机。例如,为虚拟机置备的持久卷应处于 RWX 模式。这样,在虚拟客户机需要迁移到另一个节点时,其他节点可以访问这个持久卷。与迁移一样,工作节点可以配置为通过默认管理网络访问存储,也可以通过附加单独的网络,为基于 NFS 或 iSCSI 的持久卷提供连接。在许多情况下,OpenShift 中的管理网络或默认容器集网络将负责初始化对指定存储系统的 API 调用。CSI 驱动程序将验证置备的卷是否已正确映射到可用的存储网络。
最后,请考虑通过公共访问权限来访问虚拟机中运行的应用或直接访问虚拟机。对于尚未准备好进行应用容器化的用户,可以将当前在虚拟机上运行的应用视作与它们一起在容器中运行的应用来对待。为此,请在虚拟机上应用一个标签,以标识您要为其提供访问权限的应用。使用这个标签进行标识后,为虚拟机上的应用可能需要的必要端口创建 Kubernetes 服务。然后,为了公开此服务,您可以创建 OpenShift 路由并允许直接访问该应用(而不是通过默认 OpenShift 容器集网络访问整个虚拟客户机),这与容器化应用是完全一样的。
以这种方式访问虚拟客户机是应用虚拟化和应用容器化之间的一个过渡步骤。如果想要采用更传统的方法,即直接访问虚拟机的客户机操作系统,您可以创建网络附加定义,并绑定到为托管虚拟客户机启用的各个工作节点上可用的 Linux 网桥或 SR-IOV 设备。这将确认虚拟客户机获得了分配的外部 IP,并且用户可以使用 SSH 或其选择的远程访问协议来直接连接客户机。
在将额外网络附加至虚拟客户机时,需要牢记一点:Linux 网桥、可用物理接口和 VLAN 标签的定义需要保持完全一致,并且它们在集群中的每个工作节点上均可用,以确保当虚拟客户机需要迁移到集群中其他节点时能够维持高可用性。
应该为已部署的 OpenShift 虚拟化解决方案寻找网络架构的配置方法,以提供与 VMware vSphere 等其他常见虚拟机监控程序环境相媲美的性能和行为,从而确保客户能享受到引人入胜的产品使用体验。在红帽,我们坚信积极正面的体验能够提升客户满意度和产品采用率,进而加速应用现代化的进程。
若要详细了解应用现代化以及 OpenShift 虚拟化如何助力此进程,欢迎您参与我们即将举行的现场活动,例如红帽全球峰会:互联 或 OpenShift 虚拟化路演。在路演活动中,我们将精心呈现 OpenShift 虚拟化的产品概述,并安排针对性的实训教学活动。
关于作者
产品
工具
试用购买与出售
沟通
关于红帽
我们是世界领先的企业开源解决方案供应商,提供包括 Linux、云、容器和 Kubernetes。我们致力于提供经过安全强化的解决方案,从核心数据中心到网络边缘,让企业能够更轻松地跨平台和环境运营。