虚拟化网络中实现负载分担的方法和装置

摘要

本申请提供一种虚拟化网络中实现负载分担的方法，应用在所述虚拟化网络的控制器上，所述方法包括：接收虚拟化接入设备上传的访问业务服务器组的业务相关报文；所述业务服务器组包括至少一个业务服务器；在业务服务器组中选择一个业务服务器作为所述业务相关报文的目的服务器；向所述虚拟化接入设备下发负载分担流表，所述负载分担流表用于：将所述业务相关报文的目的MAC地址更改为所述业务相关报文的目的服务器的MAC地址后，从通往所述目的服务器的出端口转发。通过本申请的技术方案，将业务流量分发分散在多个虚拟化接入设备上进行，避免了性能瓶颈；并且在增加业务服务器数量时配置更为简化。

说明书

技术领域

本申请涉及网络通信技术领域，尤其涉及一种虚拟化网络中实现负载分 担的方法和装置。

背景技术

云计算是信息技术产业的一次新变革，它将各种传统的计算资源、存储 资源以及网络资源，通过互联网全部转移到云端，用户不必了解设备的位置， 也不必了解计算的过程，而只要按需使用即可。

作为支撑云计算的重要技术基石，虚拟化技术得到了充分发展。服务器 虚拟化技术可以在一台物理主机同时运行多个虚拟机，这些虚拟机相互隔离 并共用底层物理资源。考虑到容量扩展的便利性和高可用性需求，企业通常 将业务配置在多台虚拟的主机或物理主机上，每台主机作为一个业务服务器， 以一个业务服务器组的形式向其用户提供业务服务。这时，就需要一个方案 来将多个用户端的访问分发到不同的业务服务器上，在这些业务服务器间进 行负载分担。

在云计算的环境下，业务服务器组的成员可能分布在任何地方，并且可 能发生虚拟机迁移的情况，在进行负载分担时，如何减少配置的复杂程度、 避免性能瓶颈，就成为需要考虑的问题。

发明内容

有鉴于此，本申请提供一种虚拟化网络中实现负载分担的方法，应用在 所述虚拟化网络的控制器上，所述方法包括：

接收虚拟化接入设备上传的访问业务服务器组的业务相关报文；所述业 务服务器组包括至少一个业务服务器；

在业务服务器组中选择一个业务服务器作为所述业务相关报文的目的服 务器；

向所述虚拟化接入设备下发负载分担流表，所述负载分担流表用于：将 所述业务相关报文的目的MAC地址更改为所述业务相关报文的目的服务器 的MAC地址后，从通往所述目的服务器的出端口转发。

本申请还提供了一种虚拟化网络中实现负载分担的装置，应用在所述虚 拟化网络的控制器上，所述装置包括：

业务相关报文接收单元，用于接收虚拟化接入设备上传的访问业务服务 器组的业务相关报文；所述业务服务器组包括至少一个业务服务器；

目的服务器选择单元，用于在业务服务器组中选择一个业务服务器作为 所述业务相关报文的目的服务器；

负载分担流表下发单元，用于向所述虚拟化接入设备下发负载分担流表， 所述负载分担流表用于：将所述业务相关报文的目的MAC地址更改为所述 业务相关报文的目的服务器的MAC地址后，从通往所述目的服务器的出端 口转发。

由以上技术方案可见，本申请的实施例中，控制器以流表的方式控制虚 拟化接入设备将业务相关报文的目的MAC地址更改为所选择的业务服务器 的MAC地址，即可将业务流量分配到所选择的业务服务器上，从而将业务 流量分发分散在多个虚拟化接入设备上进行，避免了性能瓶颈；并且无需为 每个业务服务器配置不同的IP地址，在增加业务服务器数量时配置更为简化。

附图说明

图1是一个例子中业务服务器组所在网络的组网结构示例图；

图2是一个例子中控制器或接入网关所在设备的硬件架构示意图；

图3是一个例子中一种虚拟化网络中实现负载分担的方法的流程图；

图4是一个例子中基于分布式交换机的虚拟化网络的组网结构示例图；

图5是一个例子中一种虚拟化网络中实现负载分担的装置的逻辑结构图。

具体实施方式

SDN(SoftwareDefinedNetworking，软件定义网络)是当前盛行的一种 网络虚拟化解决方案，其核心理念是将网络的控制平面和转发平面相分离， 把网络的控制平面，如所有转发行为的决策都迁移到集中式的控制器 (Controller)上，转发设备采用控制器下发的流表进行转发。

在应用虚拟化技术的主机上，通常每个虚拟机有自己的虚拟网卡，在虚 拟网卡和物理主机的物理网卡之间，由软件实现的虚拟交换机(vSwitch)进 行报文转发。vSwitch可以作为被控制器控制的其中一种转发设备，来实现 端到端的网络虚拟化。

图1所示是一种业务服务器组所在的网络可能具有的组网结构，业务服 务器组包括运行在物理主机140上的虚拟机VM-S1、运行在物理主机150上 的虚拟机VM-S2和VM-S3、以及物理主机160，其中，VM-S1通过vSwitch 141、VM-S2和VM-S3通过vSwitch151接入物理网络；运行在物理主机120 上的虚拟机VM-C1和VM-C2通过vSwitch121接入物理网络，运行在物理 主机130上的虚拟机VM-C3通过vSwitch131接入物理网络，VM-C1、VM-C2 和VM-C3作为业务服务器组的用户端，需要访问业务服务器组以获得相应 的服务。运行在物理主机110上的控制器111对物理网络中的设备和各个 vSwitch进行管理和控制。

申请人知道的一种已有的技术方案中，在图1所示的网络中增加LB (LoadBalancing，负载均衡)设备，以LB设备的虚拟IP地址作为业务服 务器组的IP地址发布给用户端。所有的用户端会以该虚拟IP地址对业务服 务器组的业务发起请求，该请求会先发送到LB设备上。在LB设备上保存 业务服务器组中所有业务服务器(如图1中的VM-S1、VM-S2、VM-S3、物 理服务器160)的地址信息，其中包括每个业务服务器的IP地址。LB设备 在收到用户端的请求后，在业务服务器组中分配一个业务服务器，再以该业 务服务器的IP地址为目的地址将用户端的请求发送到该业务服务器上。这样， 用户端访问业务服务器组的流量都需要先经过LB设备，当访问量比较大时， LB设备就会成为性能的瓶颈；并且，每个业务服务器都需要配置不同的IP 地址，在增加业务服务器组的服务器数量时配置较为复杂。

另外，LB设备可以是网络中一个独立的设备，也可以是虚拟设备VLB (VirtualLoadBalancing，虚拟负载均衡)。如果是一个独立的设备，则需要 额外的投资来购置该设备的硬件和软件；如果是VLB设备，引入VLB设备 能够在云计算的虚拟化环境下使负载均衡功能具备更多的灵活性，但是同时 也导致访问各业务服务器的流量需要到VLB上绕行，使得数据中心内的流量 模型绕行严重，面临着更为突出的性能瓶颈问题。

在本申请的一个例子中，运行在控制器上的负载分担控制逻辑能够在不 额外增加设备的情况下实现业务负载均衡功能，同时避免现有的负载分担方 案导致的性能瓶颈问题。本例中的控制器可以是vSwitch控制器，可以是具 备SDN控制功能和vSwitch控制功能的控制器，也可以是分布式交换机控制 器；控制器所在的物理设备可以是主机，也可以是网络设备。请参考图2， 控制器所在的物理设备可以包括处理器211、内存212、非易失性存储器213 以及网络接口14，这些硬件通过内部总线215相互连接。在这个例子中，处 理器211将VLAN映射控制逻辑从非易失性存储器213中读取到内存212中 运行，其运行流程如图3所示。

本例中，业务服务器组包括一个以上的业务服务器，业务服务器可以是 运行在物理主机上的虚拟机，也可以是物理服务器。业务服务器组具有至少 一个业务IP地址，用户端可以利用业务IP地址来访问业务服务器组提供的 服务。业务服务器组可以在控制器上创建，以分布式交换机控制器为例，可 以在分布式交换机控制器上创建业务服务器组，将虚拟机接入虚拟化网络的 端口加入到该业务服务器组中，该虚拟机即成为该业务服务器组中的业务服 务器；业务服务器组也可以通过其他方式创建，并在控制器上保存该业务服 务器组的业务IP地址，和其包含的业务服务器以及业务服务器的MAC地址、 所连接的vSwitch等信息。

本例中，用户端通过虚拟化接入设备连接到物理网络，包括通过vSwitch 接入物理网络的虚拟机，也包括通过接入网关接入实现虚拟化功能的物理主 机。物理主机通过接入网关与网络中的其他主机或虚拟机进行通信，接入网 关按照控制器采用的协议与控制器进行交互，向控制器上报与物理主机相关 的地址和其他配置信息，根据控制器下发的流表对来自和去往物理主机的报 文进行处理；换言之，接入网关作为非虚拟化的物理主机与虚拟化网络之间 的中继，实现控制器对与物理主机相关的报文的控制，例如，接入网关在收 到来自物理主机的报文时，如果本地流表中未找到匹配的表项，则将该报文 上报给控制器；如果本地流表中找到匹配的表项，则根据表项对该报文进行 处理。

步骤310，接收虚拟化接入设备上传的访问业务服务器组的业务相关报 文。本例中的业务相关报文包括各种在获得业务服务器组提供的业务服务的 过程中访问业务服务器组的报文，例如以业务服务器组的业务IP地址为目的 地址的业务报文。

当vSwitch收到来自虚拟机、或者当接入网关收到来自物理主机访问业 务服务器组的业务相关报文时，如果本地未找到匹配该报文的流表表项，则 将该业务相关报文上传到控制器。

步骤320，在业务服务器组中选择一个业务服务器作为所述业务相关报 文的目的服务器。

控制器上保存有其管理域内各个VM、vSwitch、业务服务器组、接入网 关以及其他被管理设备的信息，如VM的IP地址、MAC(MediaAccessControl， 媒体接入控制)地址、所连接的vSwitch、所在的物理主机等信息，业务服 务器组的业务IP地址、其包含的业务服务器的MAC地址、所连接的vSwitch、 所在的物理主机等信息。

当控制器收到虚拟化接入设备上传的访问业务服务器组的业务相关报文 后，在保存的业务服务器组中的业务服务器中选择一个作为该业务相关报文 的目的服务器，来为发送该业务相关报文的用户端提供服务。

控制器可以采用各种负载均衡方法来在业务服务器组中选择某个业务相 关报文的目的服务器，包括已有的各种负载均衡算法。控制器还可以选择各 种参数来应用这些负载均衡算法，如业务相关报文的源IP地址(或业务相关 报文的源VM)、业务相关报文的源虚拟化接入设备的标识、业务相关报文 的源物理设备等等。例如，以业务相关报文的源IP地址为参数，采用轮转、 加权轮转等算法来确定该报文的目的服务器。

步骤330，向上传业务相关报文的虚拟化接入设备下发负载分担流表， 该负载分担流表用于：将该业务相关报文的目的MAC地址更改为该业务相 关报文的目的服务器的MAC地址后，从通往该目的服务器的出端口转发。

控制器从保存的业务服务器组的信息中得到所选择的目的服务器的 MAC地址，按照该目的服务器所连接的vSwitch和/或物理网络中的网络设 备、与上传该业务相关报文的虚拟化接入设备之间的转发路径确定该业务相 关报文在虚拟化接入设备上的出端口，据之生成负载分担流表，下发给上传 该业务相关报文的虚拟化接入设备。下发的负载分担流表指令该虚拟化接入 设备将该业务相关报文的目的MAC地址更改为目的服务器的MAC地址，并 从虚拟化接入设备上通往目的服务器的出端口转发。

这样，访问业务服务器组的业务相关报文将根据目的IP地址(业务服务 器组的业务IP地址)和目的MAC地址被转发到控制器选择的目的服务器上。 并且，后续匹配该负载分担流表的业务相关报文将由虚拟接入设备直接进行 MAC地址替换和转发。

以图1所示的网络为例，对包括虚拟机VM-S1、VM-S2和VM-S3、以 及物理主机160的业务服务器组，控制器111上保存有表1所示的内容，其 中：PS-160为物理主机160；IP-G为业务服务器组的业务IP地址；MAC-S1、 MAC-S2、MAC-S3、MAC-160分别为VM-S1、VM-S2、VM-S3和物理主机 160的MAC地址。

业务服务器 IP地址 MAC地址 VM-S1 IP-G MAC-S1 VM-S2 IP-G MAC-S2 VM-S3 IP-G MAC-S3 PS-160 IP-G MAC-160

表1

当虚拟机VM-C3作为用户端访问业务服务器组时，其生成的业务报文 以IP-G为目的IP地址。该业务报文到达vSwitch131后，vSwitch131未找 到匹配的流表，将其上传至控制器111。

控制器111根据业务报文的源IP地址，在VM-S1、VM-S2、VM-S3、 和PS-160中确定VM-S1为其目的服务器，则向vSwitch131下发负载分担流 表。vSwitch131按照下发的负载分担流表，将业务报文中的目的MAC地址 更改为VM-S1的MAC地址MAC-S1后，从通往物理网络的端口发送出去。 目的IP地址为IP-G、目的MAC地址为MAC-S1的业务报文通过物理网络到 达VM-S1。由于该业务报文的目的MAC为VM-S1的真实MAC，因此该业 务报文可以穿越物理网络到达VM-S1。

可见，本例中，当用户端访问业务服务器组时，控制器以流表的方式控 制接入用户端的vSwitch或接入网关进行目的服务器的MAC地址替换，即 可将业务流量分配到所选择的目的服务器上，从而实现负载的分担。控制器 通过流表对将业务流量分发到哪个目的服务器上进行控制，但并不参与业务 流量的分发。业务流量的分发分散在多个接入用户端的虚拟化接入设备上进 行。在控制器下发的负载分担流表的生存期内，所有匹配该流表的业务流量 将由虚拟化接入设备直接分发到负载分担流表中的目的服务器上，而不再需 要经过集中的中继设备，避免了性能瓶颈；本例中通过MAC地址标识不同 的业务服务器，因而无需为每个业务服务器配置不同的IP地址，减少了IP 地址占用，并且在虚拟化环境下增加业务服务器数量时配置更为简化。

在一个例子中，在控制器上保存所下发的负载分担流表、以及负载分担 流表与接收该负载分担流表的虚拟化接入设备的对应关系。控制器对业务服 务器组中的业务服务器进行健康检查，可以采用现有负载均衡技术中的健康 检查方案，也可以仅由业务服务器的接入设备(如vSwitch)上报给控制器 其连接该业务服务器的端口状态变为DOWN(失效)来判断该业务服务器发 生故障。如果某个业务服务器发生故障，则找出所有以该业务服务器为目的 服务器的负载分担流表，将这些负载分担流表的目的服务器刷新为业务服务 器组中某个状态正常的业务服务器，即刷新后的负载分担流表用于：将业务 相关报文的目的MAC地址更改为该状态正常的业务服务器的MAC地址，并 从通往该状态正常的业务服务器的出端口转发；控制器指令该负载分担流表 对应的虚拟化接入设备，对该负载分担流表进行同样的刷新。由于以其他业 务服务器为目的服务器的已建立流表不受影响，当业务服务器组内的某一业 务服务器故障时，不会影响到其他业务服务器对当前业务的正常处理。当业 务服务器组中的业务服务器发生迁移后，控制器找出所有以该业务服务器为 目的服务器的负载分担流表，将该流表的出端口刷新为通往迁移后目的服务 器的出端口，并指令负载分担流表对应的虚拟化接入设备对该负载分担流表 进行同样的刷新。

在这个例子中，控制器可以对各个业务服务器的状态进行维护，在步骤 320中，控制器可以从状态正常的业务服务器中选择一个作为业务相关报文 的目的服务器。

与业务服务器组的业务IP类似，可以为业务服务器组设置一个组MAC 地址作为所有业务服务器共用的虚拟MAC地址。一个例子中，当用户端通 过业务IP地址访问业务服务器组时，如果业务IP地址与用户端的IP地址在 同一个网段，则在本地ARP(AddressResolutionProtocol，地址解析协议) 缓存查找业务IP地址对应的MAC地址；如果没有找到，则发起目的地址为 业务IP地址的ARP请求，虚拟化接入设备将用户端的ARP请求报文上传到 控制器。控制器收到目的地址为业务服务器组的业务IP地址的ARP请求报 文后，以该业务服务器组的组MAC地址作为地址解析结果，生成ARP响应 报文，发送给该用户端，作为对其ARP请求报文的响应。通过设置统一的组 MAC地址，可以简化本例中方案的部署，并增强可维护性。

这个例子中，如果用户端的IP地址与业务IP地址在同一个网段内，用 户端生成的访问业务服务器组的业务相关报文将以业务IP地址为目的IP地 址，以业务服务器组的组MAC地址为目的MAC地址。如果用户端的IP地 址与业务IP地址不在同一个网段内，用户端生成的访问业务服务器组的业务 相关报文将以业务IP地址为目的IP地址，以该用户端的网关的MAC地址 为目的MAC地址。这样，在虚拟化接入设备上，根据控制器下发的负载分 担流表，会将来自用户端的业务相关报文中的业务服务器组的组MAC地址、 或网关的MAC地址更改为控制器指定的目的服务器的MAC地址。

如果用户端的IP地址与业务IP地址不在同一个网段内，业务相关报文 需要进行三层转发才能从虚拟化接入设备经过物理网络到达目的服务器。这 种情况下，控制器下发的负载分担流表中还可能会包括与三层转发相关的处 理过程，例如修改VLAN(VirtualLocalAreaNetwork，虚拟局域网)信息等， 这些过程均可采用与现有技术相同的处理方式，不再赘述。

需要说明的是，用户端发送的以业务IP地址为目的地址的ARP请求报 文与业务服务器提供的业务服务无关，因而不是业务相关报文，控制器将进 行ARP响应而不会为其分配目的服务器。

当某个用户端虚拟机发生迁移后，接入迁移后虚拟机的vSwitch会重新 生成该虚拟机的流表。当该虚拟机作为用户端访问业务服务器组时，按照本 例中的上述流程，vSwitch即可获得新的负载分担流表，并实现迁移后虚拟 机到目的服务器的访问。

本申请的另一个例子中，业务服务器组所在的网络环境为基于分布式交 换机(DistributedvSwitch)实现的虚拟化网络，由分布式交换机控制器 (DistributedvSwitchController)对各个vSwitch和接入网关进行控制。分布 式交换机控制器利用vSwitch或接入网关上的端口来识别和管理连接在 vSwitch或接入网关上的主机(包括虚拟机和物理主机)，其管理域内所有 vSwitch和接入网关上的端口具有在该虚拟化网络中唯一的全局端口号。一 种示例性的组网结构如图4所示，连接在vSwitch420的端口422上的VM42a、 连接在vSwitch420的端口423上的VM42b和连接在vSwitch430的端口432 上的VM43a组成业务服务器组，连接在vSwitch440上的VM44a、连接在 接入网关450上的物理主机45a可以作为用户端对业务服务器组发起访问。 vSwitch420、vSwitch430、vSwitch440和接入网关450分别通过各自的端口 421、端口431、端口441和端口451接入物理网络，分布式交换机控制器410 作为该虚拟化平台的控制器也接入物理网络，以实现相互间的通信。

在分布式交换机控制器410上创建业务服务器组，将连接各个业务服务 器的全局端口号加入到该业务服务器组中。分布式交换机控制器410从其预 置的MAC地址池中选择一个虚拟MAC地址gMAC作为该业务服务器组的 组MAC地址，分配1.1.1.1作为业务服务器组的业务IP，并建立如表2所示 的表项用于生成负载分担流表：

全局端口号 业务IP地址 组MAC地址 业务服务器的MAC地址 状态 422 1.1.1.1 gMAC M-42a 正常 423 1.1.1.1 gMAC M-42b 正常

432 1.1.1.1 gMAC M-43a 正常

表2

其中，业务服务器的MAC地址可以由分布式交换机控制器410根据其 保存的连接到全局端口的主机信息自动生成；业务服务器以其接入该虚拟化 网络的全局端口号作为标识。分布式交换机控制器410对业务服务器组内的 各个业务服务器进行周期性的健康检查，通过健康检查的业务服务器的状态 为正常，健康检查失败的业务服务器的状态为故障。

当虚拟机VM44a或物理主机45a第一次访问业务服务器组时，本地ARP 缓存中尚无与1.1.1.1对应的MAC地址，发送ARP请求报文。接收到ARP 请求报文的vSwitch440或接入网关450将该ARP请求报文上传到分布式交 换机控制器410。

假设VM44a、物理主机45a与业务IP地址在同一个网段内，分布式交 换机控制器410收到的ARP请求报文以1.1.1.1为目的IP地址。分布式交换 机控制器410识别出该ARP请求报文的目的IP地址为业务服务器组的业务 IP地址，为该ARP请求返回该业务服务器组的组MAC地址作为响应。这样， 所有用户端的ARP缓存中，与业务IP地址对应的MAC地址为该业务服务 器组的组MAC地址gMAC。通过设置统一的组MAC地址，可以简化本例中 方案的部署，并增强可维护性。

VM44a收到ARP响应后，以业务服务器组的业务IP地址和组MAC地 址作为目的地址生成业务报文，对业务服务器组发起访问。第一个业务报文 在到达vSwitch440后，因没有匹配的流表，vSwitch440会将其上传到分布 式交换机控制器410。

分布式交换机控制器410发现上传业务报文的目的IP地址是业务服务器 组的业务IP地址，按照设定的负载均衡算法从表2中状态正常的业务服务器 中选择一个作为VM44a的业务报文的目的服务器。设分布式交换机控制器 410选择了连接在端口423上的VM42b作为目的服务器，则通过查找保存 的被管理对象的连接拓扑，可以获知vSwitch440将业务报文转发到目的服 务器VM42b的出端口为端口441。

分布式交换机控制器410生成负载分担流表下发给vSwitch440，指令 vSwitch440先将目的IP地址为1.1.1.1的业务报文的目的MAC地址更改为 VM42b的MAC地址M-42b，然后从端口441转发出去。分布式交换机控制 器410保存所生成的负载分担流表和VM42b的对应关系。

收到负载分担流表的vSwitch440对目的IP地址为1.1.1.1的业务报文进 行对应的处理后，目的地址为1.1.1.1和M-42b的业务报文将经过物理网络的 转发后到达VM42b。后续当VM44a再次发送访问1.1.1.1的业务报文时， vSwitch440将按照已有的负载分担流表进行目的MAC地址的更改和转发。

当某个业务服务器发生故障时，如VM42b所在的物理主机掉线，VM42b 将无法通过分布式交换机控制器410的健康检查。分布式交换机控制器410 将表2中VM42b的状态改为故障，这样新的业务流量将不会再分配到VM 42b上。分布式交换机控制器410在保存的已经下发的负载分担流表中查找 目的服务器为VM42b的流表，将这些负载分担流表的目的服务器刷新为状 态正常的业务服务器中的一个，并且指令该负载分担流表对应的vSwitch或 接入网关进行同样的刷新。

以上述下发给vSwitch440的负载分担流表为例，VM42b的状态变为故 障后，分布式交换机控制器410选择状态正常的VM43a作为新的目的服务 器，则将该负载分担流表刷新为：将目的IP地址为1.1.1.1的业务报文的目 的MAC地址更改为VM43a的MAC地址M-43a，然后从端口441转发出去， 并指令vSwitch440也同样刷新该负载分担流表。这个例子中，业务报文在 vSwitch440上还是通过端口441转发到物理网络，因此在刷新流表时不需更 改出端口。

分布式交换机控制器410上以其他状态正常的业务服务器为目的服务器 的流表不受VM42b故障的影响，这些业务服务器上正在进行的业务服务也 不会受到影响。

在这个例子中，只需要将业务服务器的全局端口加入到分布式交换机控 制器上的业务服务器组中，在发生虚拟机迁移时只要更改迁移的业务服务器 的全局端口，即可完成与业务服务器组有关的配置，简化了网络管理员的工 作。

与上述流程实现对应，本申请还提供了虚拟化网络中实现负载分担的装 置，应用在该虚拟化网络的控制器上，该装置可以通过软件实现，也可以通 过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上 的装置，可以通过图2中的处理器211将负载分担控制逻辑读取到内存212 中运行而形成。

图5所示为本申请一个例子中的一种虚拟化网络中实现负载分担的装置， 应用在该拟化网络的控制器上，所述装置包括业务相关报文接收单元、目的 服务器选择单元和负载分担流表下发单元，其中：业务相关报文接收单元用 于接收虚拟化接入设备上传的访问业务服务器组的业务相关报文；所述业务 服务器组包括至少一个业务服务器；目的服务器选择单元用于在业务服务器 组中选择一个业务服务器作为所述业务相关报文的目的服务器；负载分担流 表下发单元用于向所述虚拟化接入设备下发负载分担流表，所述负载分担流 表用于：将所述业务相关报文的目的MAC地址更改为所述业务相关报文的 目的服务器的MAC地址后，从通往所述目的服务器的出端口转发。

一个例子中，所述装置还包括负载分担流表保存单元、健康检查单元和 第一流表刷新单元，其中：负载分担流表保存单元用于保存所下发的负载分 担流表以及所述负载分担流表对应的虚拟化接入设备；健康检查单元用于对 业务服务器组中的业务服务器进行健康检查；第一流表刷新单元用于当某个 业务服务器发生故障时，将以发生故障的业务服务器为目的服务器的负载分 担流表刷新为以业务服务器组中某个状态正常的业务服务器为目的服务器； 并指令对应的虚拟化接入设备进行同样的刷新。

所述装置还可以包括ARP接收单元和ARP响应单元，其中：ARP接收 单元用于接收虚拟化接入设备上传的ARP请求报文；所述ARP请求报文的 目的地址为所述业务服务器组的业务IP地址；ARP响应单元用于以所述业 务服务器组的组MAC地址作为地址解析结果，响应所述ARP请求报文。

所述访问业务服务器组的业务相关报文可以包括：以业务服务组的业务 IP地址和组MAC地址为目的地址的业务报文，以及以业务服务组的业务IP 地址和业务报文源主机的网关的MAC地址为目的地址的业务报文；所述将 业务相关报文的目的MAC地址更改为其目的服务器的MAC地址，包括：将 业务相关报文中的业务服务组的组MAC地址或网关的MAC地址更改为所选 择的所述业务相关报文目的服务器的MAC地址。

所述虚拟化接入设备可以包括：连接虚拟机VM的虚拟交换机vSwitch， 和连接物理主机的接入网关，所述接入网关根据控制器下发的流表对物理主 机访问业务服务器组的业务相关报文进行处理，并将未查询到匹配流表的业 务相关报文上传到控制器。

所述装置还可以包括负载分担流表保存单元和第二流表刷新单元，其中： 负载分担流表保存单元用于保存所下发的负载分担流表和对应的虚拟化接入 设备；第二流表刷新单元用于当某个业务服务器发生迁移后，将以发生故障 的业务服务器为目的服务器的负载分担流表的出端口刷新为通往迁移后目的 服务器的出端口；并指令对应的虚拟化接入设备进行同样的刷新。

一个例子中，所述控制器包括分布式交换机控制器；所述业务服务器以 其接入所述虚拟化网络的全局端口号作为标识。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本 申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在 本申请保护的范围之内。