1. CrossBow（项目名称）：
有必要对技术（网络虚拟化和资源控制）和项目名称（CrossBow）之间的关系进行一番解释。公元前 341 年，中国人发明了十字弓（Crossbow），但直到中世纪，特别是当钢铁被用于制造武器时，它才得到了广泛的应用。威力更强大的十字弓可以在 200 码之外穿透铠甲，这给安坐在马背上的骑士带来了真正的梦魇。但是最大的区别之处就在于使用简单。在经过一周的训练后人们可以熟练地使用十字弓,而具备长弓的同等单弩发射技能需要几年的练习。
类似地，如果您了解一下在终端主机上的现有服务质量（QOS）机制，您会发现该机制很难使用，而且需要技能高超的管理员才能得心应手地使用。即使那样，现有 QOS 机制会带来巨大性能损失，采用任何虚拟化技术这种性能损失也还是相当普遍存在。在 Solaris 平台中，我们已经发明出一种作为真实和虚拟网络接口卡（NIC）属性来施加带宽资源控制的新方式，因此该方式被构建在 Solaris 网络堆栈内作为其中的一部分，且不会带来巨大的性能损失。因为虚拟化方面和/ 或资源控制方面仅作为 NIC/VNIC（当 NIC 或 Virtual NIC 被创建时进行指定）的属性和一个普通用户，且无需在 QOS 或虚拟化中进行修改。由于我们试图在虚拟化领域和资源控制内获得像在中世纪的战场上使用武器所获得的类似结果，因此使用 "CrossBow" 作为项目名称最为合适。
2. CrossBow（背景）：
围绕服务（HTTP、HTTPS、 FTP、NFS 等等）、协议（TCP、UDP、SCTP 等等）或者像 Containers、 Xen 和 ldoms 这样的虚拟机，Crossbow 通过创建虚拟化堆栈来提供用于网络虚拟化和资源控制的构造块。
项目允许系统管理员将物理 NIC 划分为多个虚拟 NIC。这些虚拟 NIC 和真实 NIC 相当类似，而且就像真实 NIC 一样进行管理。在共享的 NIC 上，Virtual NIC 可以分得自己的优先权和带宽，却不会引起任何性能下降。虚拟 NIC 可以拥有自己的 NIC 硬件资源（Rx/Tx 环、 DMA 通道）、MAC 地址、内核线程和队列，它们专属于 VNIC，且在所有通信过程中不被共享。在采用 Solaris Container 服务器的情况下，Container 服务器可以分得一个虚拟堆栈实例（Stack Instance），以及一个或多个虚拟 NIC。因此，一个 VNIC 的此种通信可以完全与其他通信隔离，并能分得各种能使用带宽量方面的限制或保证。
3. 概述：
Crossbow 项目在多个市场中扩展 Solaris 范围。
3a.操作系统/ 网络/ 服务器整合:
应用程序、网络和服务器整合在 OS 和网络虚拟化中发挥着重要的作用。该市场通常受拥有和管理物理机器和物理网络的成本驱动。水平扩展环境的理想阵地是 2-4 套接字机，它在 x86/x64 系统中作为 4-8 CPU 计算机，以及在 SUN 基于 Niagara 的新服务器中的 32-64 CPU 计算机。从拥有总成本角度来看，这些刀片只有一个物理 NIC（1Gb 或 10Gb），但是它们却试图在必须共享 NIC 资源和可用带宽的多种虚拟机（Xen、 Containers、 ldoms）上运行。
30多年来，问题变得愈加糟糕，我们已经设计了运行尽可能快的应用程序，并且任何拥塞控制都成为通信层的工作（如果真有这种情况）。那么，如果虚拟机采用基于 UDP 的通信，那么其他在相同系统上的虚拟机使用 TCP 通信将遭受巨大影响。即使在相同的通信（例如 TCP）内，像 ftp/http 等类似的批量吞吐量将对交互通信和等待时间敏感的应用程序产生非常大的负面影响。
Crossbow 项目的目标是使不同的虚拟机以公平的方式共享通用的 NIC，并允许系统管理员在必要的情况下（例如 ISP 在通用管道上出让有限的 B/W）设置优先策略而不带来性能影响。
3b.传统的 QOS 和应用程序整合:
基于 QOS 机制的现有主机设置非常复杂，且通常会带来可观的性能损失、增加了等待时间。主要问题就是为入站包提供的基于中断的传送机制和由隔离层实施的 QOS（通常在 NIC 驱动程序和 IP 之间）。主机堆栈的网络和通信层不识别 QOS 层。包已经通过中断的形式被传送到主机内存，且 QOS 层需要将包划分给不同的队列，然后应用这些策略。由于超过带宽使用等级导致包不能被处理，在此情况下，包停留在队列中并仍在消耗系统内存。
Crossbow 项目集成了堆栈虚拟和 QOS，将之作为堆栈架构本身的一部分，以便在零性能损失和简单管理界面下提供 QOS 型功能的大型子集。它还使用堆栈集成区分服务( diffserv），虚拟 NIC 可以在其中设置并读取基于区分服务的标签。Crossbow 架构在区分基于层 2、 3 和 4 头（也就是 VLAN 标记、逻辑 mac 地址、本地 IP 地址、协议和端口）的通信很有限；尽管该架构涵盖了 90% 没有性能损失的应用案例，但所提供的功能只作为现有 QOS 机制的子集。这就是为什么项目 Crossbow 要参考“带宽相关策略”而不是 QOS 来作为宽带资源控制的原因。
3c.水平扩展市场
低价大容量服务器提供要求在各个服务器之间几乎不或不共享数据的服务，这就是由这些服务器所组成的市场划分( 通常为 2-4 套接字机）。这些小型服务器在机柜中可以是独立机器或是在机箱中的刀片（blade）。网格是使用高容量服务器获得传统的大型 SMP 机器或主桢输出的另一种方式。
在采用共享公用 10Gb NIC 到机箱的刀片情况下，Crossbow 以公平的方式再一次提供带宽共享。此外， Crossbow 为网络管理、虚拟化和带宽资源控制提供的 API 可以被第 3 方 管理软件使用，用来通过服务器场或机箱中的所有刀片传播策略。在基于同质环境的 Solaris 中很轻松将应用程序或虚拟机标记为（基于端口或 IP 地址）重要，且在整个机器中传播相同的策略。可以适当添加区分服务标签，这样策略就被中央系统中的所有机器和网络元件共有。
4. 现有架构中的技术问题：
正如前面所述，基于 QOS 系统的主机在网络堆栈之间作为一个层工作，这样提供所请求的 QOS 服务的效率相当低。但是那还不是全部问题。
现有中断驱动包传送模式阻止任何一种策略实施和公平共享。当一个 NIC 中断被提升时，它处在最高优先级，且无论进程要处理哪个中断，CPU 都必须进行上下文切换。绝大多数情况下，重要包的进程被中断以便处理非重要包的到来。
在内核中的匿名包进程是虚拟化堆栈和实施任何带宽资源控制( 包括公平性）的另一个主要问题。当堆栈确定没有任何一个进程对包感兴趣且必须要放开它时，处理传入包工作的80% 已经完成。换句话说，放开不希望的包的代价是很高的
在主机中的所有进程流经公共队列，并由公共线程进行处理，这使得基于通信类型的策略实施非常困难。在特定 CPU 上，每个包的 recv 或 xmit 将对任何其他包的处理产生影响。
在大多数虚拟化环境中，由于存在进程间的桥接，在虚拟机中的伪 NIC 没有办法了解真实硬件的硬件容量（即使像硬件的检查量这样的简单项也不可得），从而导致负面性能影响。此外尚没有以公平方式共享 NIC 的机制。从 dom0 到 domU 的典型包传输也会造成严重的性能问题。
5. CrossBow 架构：
Crossbow 架构提出将网络虚拟化和资源控制集成为堆栈架构的一部分。我们已经设计出了应用于未来10 年的 Solaris 10 网络堆栈，其中到 CPU 关联的连接得到了维护，并且上层堆栈严密控制 NIC 资源。
Crossbow 在 Solaris 10 网络堆栈之上，通过将基于服务、协议或虚拟机的包类别推送到尽可能低的层中构建。如果 NIC 硬件本身有能力将便携式内存划分为可以优先拥有自己的 DMA 通道和 MSI-X 中断的各个分段/ 队列( 称作 Rx 和 Tx 环），那么堆栈安排 NIC 分类器在配置策略的基础上将包分为不同的 Rx 环。每个 Rx/Tx 环属于一个 CPU 和称作序列化队列的单独内核队列，该队列控制包达到基于经配置带宽的系统比率。
与 DMA 通道、MSI-X 中断、序列化队列、CPU 和处理线程相关的 Rx/Tx 环对于服务、协议或虚拟机完全是唯一的，并可以分得一个惟一 MAC 地址和 Virtual NIC。Virtual NIC 将成为可以像公共 NIC 那样被管理的管理实体.NIC 分类器将传入的包（来自拥有 Rx 环( 和 VNIC）的 Squeue）驱动到正确的 RX 环，拥有 Rx 环( 和 VNIC）的 Squeue 在这里通过基于资源公平共享或经配置带宽的轮询模式将包拉回。只有当 Squeue 没有要处理的包且 Rx 环为空时才使用中断模式。每个单个 Rx 环在中断和轮询模式之间动态切换。超过经配置带宽的限度的传入包将留在相应 Rx 环的 NIC 中，且只有当它们准备好接受处理时才在系统中被拉回。
管理实体（VNIC）的创建是可选的，且通常与 Solaris 容器、 Xen 或 ldoms 此类的虚拟机相关。对于基于应用程序或协议的资源控制，要创建单独的数据路径以便提供隔离和资源控制，但是不用配置 VNIC。
正如前面所述，VNIC 只是一个管理实体。如果对特定 Rx 环的分类已经由 NIC 完成，当 Rx 环为中断模式时，通过功能调用将包直接传送到 IP 层；或当 Rx 环为轮询模式时，在 IP 层贮存的 squeue 将包链直接从 Rx 环中拉回。实际上，整个数据链接层被绕过从而导致性能的改进和较低的等待时间。如果 VNIC 处于混杂模式，数据链接绕行被放弃，且 Rx 环通过 VNIC 层（它为混杂数据流创建包的副本）传送包。类似地，在轮询模式中，squeue 轮询进入点被改变为在 VNIC（轮询次数）处的点，VNIC 从 Rx 环拉回包、制作包副本，然后将链给 Squeue 轮询线程。
整个分层架构被构建在功能指针之上，称作 “upcall_func” 和 “downcall_func”，相应于上下文为 “upcall_arg” 和 “downcall_arg”。每个层提供该层 recv 功能的指针，称作 “upcall_func”；相应于上下文为 “upcall_arg”，指向下一层。类似地，每个层提供到传输功能的指针，称作 “downcall_func”；相应于上下文为 “downcall_arg”，指向上一层。这就是包路径的构造过程。任何层可以通过提供上一层的 “upcall_func” 和 “upcall_arg” 给下一层( 如果需要，对于传输端做法相同）来缩短自己的回路。当每一层指向它获得的参考时，对于某一层的所有上下文 cookie 都将在基于系统的参考上运行，并确保数据结构一直不空闲，直到所有参考被放。
在这种情况下 NIC 硬件没有分类功能（也就是不可能分类，因为大多数 inte、 broadcom 和 SUN 1Gb NIC 以及近乎所有的 10Gb NIC 传输近几年来都提供了这样的功能）或者已经完成分类功能，CrossBow 架构在 mac 层中提供分类功能并采用与 NIC 硬件分类器和 RX 环类似功能的软环。NIC 硬件层与下面的 MAC 层耦合，而软环命名为 “Pseudo Hardware layer”。由管理员发出的用于创建新 VNIC 或数据流的请求将一直成功从伪硬件层返回。伪硬件层管理硬件和软件分类功能、Rx 环和明显来自上一层的软环。
6. Crossbow 层、数据结构和包流：
使用下列两个流很容易解释这个问题。第 1 个流是提供给 IP_addr = a.b.c.d && TCP 的，它通过 Upper dls 等流过公共路径。我们基于这样的假设，查错工具（或在 DLS 中的其它工具）对这项流感兴趣且我们不能绕过数据链接进程。在这种情况下，squeue 轮询功能是 dls_poll_ring，参数为 dls_impl_t。
第 2 个流是提供给 IP_addr = m.n.o.p && port = 80 && TCP 的，它是惟一的并且没有进程对它执行查错。在这种情况下，dls 层允许自己通过为 soft_ring/Rx_ring 设置 upcall_func and upcall_arg 直接调用 IP 而被绕过。在这种情况下，squeue 直接轮询 H/W Rx 环。
7. 管理模式：
Crossbow 引入了一个称作 “netrcm” 的新命令和又一个参数 “dladm”。所引入的参数在 Solaris 10 中作为新型高性能设备的驱动程序框架（GLDv3）的一部分。
“dladm（1M）” - 主要用于创建、修改和销毁基于 mac 或 IP 地址的 VNIC。所创建的 VNIC 就像其他 NIC 那样是可见的并由 ifconfig 管理，如有必要，它能获得由 DHCP 分配的 IP 地址。
下列示例可以很好地说明这一点:
示例 1：配置 VNIC
要在单个物理设备 bge0 上使用 vinc-ids 1 和 2 来创建两个 VNIC，
请输入下列命令：
# dladm create-vnic -d bge0 1
# dladm create-vnic -d bge0 2
The new links will be called vnic1 and vnic2.
示例 2：配置 VNIC 并分配带宽和优先权
要在单个物理设备 bge0 上使用 vinc-ids 1 和 2 来创建两个 VNIC 接口，
以及使用被分配 MAC 地址的厂使 vnic1 成为具有更高优先级的 VNIC，
并保证 vnic1 使用的带宽量高达 90%，同时使用随机 MAC 地址和 100Mbps的硬限制，使 vnic2
而具有较低优先级
# dladm create-vnic -d bge0 -m factory -b 90% -G -p high 1
# dladm create-vnic -d bge0 -m random -b 100M -L -p low 2
示例 3：通过选择厂 MAC 地址配置 VNIC
要使用 vinc-id 1 创建 VNIC 接口，首先
列举厂可用的 MAC 地址，然后使用
其中之一：
# dladm show-dev -d bge0 -m
bge0
link: up speed: 1000 Mbps duplex: full
MAC addresses:
slot-ident Address In Use
1 0:e0:81:27:d4:47 Yes
2 8:0:20:fe:4e:a5 No
# dladm create-vnic -d bge0 -m factory -n 2 1
# dladm show-dev -d bge0
bge0
link: up speed: 1000 Mbps duplex: full
MAC addresses:
slot-ident Address In Use
1 0:e0:81:27:d4:47 Yes
2 8:0:20:fe:4e:a5 Yes
示例 4：配置 VNIC 共享 MAC 地址
要使用 vnic-id 1 和 2 创建两个 VNIC，首先列举
分配了 MAC 地址的可用厂，然后提取
将由新创建的 VNIC 共享的那个厂
# dladm show-dev -d bge0 -m
bge0
link: up speed: 1000 Mbps duplex: full
MAC addresses:
slot-ident Address In Use
1 0:e0:81:27:d4:47 Yes
2 8:0:20:fe:4e:a5 No
# dladm create-vnic -d bge0 -m shared -n 2 1
# dladm create-vnic -d bge0 -m shared -n 2 2
示例 5：使用用户指定的 MAC 地址创建 VNIC
要使用 vnic-id 1 创建 VNIC，提供用户指定的
mac 地址
# dladm create-vnic -d bge0 -m 8:0:20:fe:4e:b8
“netrcm（1M）” - 这个命令主要用于向应用程序通信或协议提供隔离和专用资源。此外我们还可以为流配置带宽和保证。下列示例可以更好地说明使用方法：
示例 1：为任务重要端口 443 通信（也就是 HTTP 服务）创建策略
在 https 服务器上围绕入站 https 创建一个策略
以便 https 获得专用的 NIC 硬件和内核 TCP/IP
资源。所指定的 policy-id 是 https-1，被用于今后删除策略的修改
# netrcm add-policy -d bge0 -H transport = TCP local port = 443 https-1
示例 2：修改现有策略以添加带宽资源控制
要修改 https-1 策略以便添加带宽控制
并为之提供一个较高优先级
# netrcm modify-policy -d bge0 -b 90% -G -p high https-1
示例 3：限制 UDP 协议的带宽使用
要为 UDP 协议创建一个策略 以便它不能消耗
多于可用带宽量的10%。policy-id 被称作 limit-udp-1。
# netrcm add-policy -d bge0 -b 90% -L -p low limit-udp-1
8. Crossbow 可观察性 —— 状态、历史记录和 API：
除了与网络虚拟化和带宽资源控制相关的功能之外，Crossbow 还提供了了解带宽使用情况的大量新型工具和机制。管理员可以在不引起性能损失的情况下，看到不同 VNIC 或经配置的流（通过 “netrcm”）的实际带宽使用情况。
处理特定流的 Rx 环和 squeue 不时跟踪由用户区守护程序拉回的正常层。守护程序还在特定日志文件中计入信息，这使用户在任何时间下看到历史记录。用户可以请求在过去一段时间的使用情况，以便了解系统表现。
Crossbow 将通过允许系统被放置在容量计划模式下来提供更多有助于容量计划的工具。在该模式中监控和显示用于上层通信的带宽使用情况。
所有可观察性和管理界面可以被 API 访问，这使得其他应用程序可以使用和管理系统。
9. 参考资料：
OpenSolaris 上的 Crossbow 项目页面提供了许多有用的信息：http://www.opensolaris.org/os/project/crossbow
Crossbow 邮件列表是执行项目所有日常业务的联系途径。任何人都可以加入邮件列表 crossbow dash 并在 opensolaris dot org 上进行讨论。
|
Print-friendly Version
