专利名称：用于实现和管理虚拟交换机的方法和装置的制作方法
技术领域：
本发明涉及网络，并且更具体地涉及虚拟网中的虚拟交换机的设计和使用。
背景技术：
包括移动性、虚拟化、动态工作负载、多租户以及安全性需要在内的增加的计算复 杂性要求有更好用于网络的范式。虚拟化是新的网络需求的一种重要催化剂。多台虚拟机(VM)利用虚拟化就能够共享同一台物理服务器，这些虚拟机可以迁移，并且工作负载可以被构建为根据所需能力动态地“裁剪”。为了应对这种新的动态水平，已经提出了分布式虚拟交换机的概念。分布式虚拟交换机幕后的思想是提供一种从底层硬件解耦并且能够跨越多种交换机或管理程序的交换机逻辑观点。常规分布式虚拟交换机的一个示例是由加利福尼亚州圣何塞市的思科公司提供的Nexus IOOOV0另一个示例是由帕罗奥多市的VMWare提供的DVS。尽管上述两者都是设计用于纯虚拟的环境，但是没有体系结构方面的理由表明相同的思想为何不能够被扩展至物理环境。大型网络(包括数据中心和企业)的多种挑战中有三项是可裁剪性、移动性和多租户，并且采取的措施经常会顾此失彼。例如，我们能够轻易地为L2域内的虚拟机提供网络移动性，但是L2域无法扩展到大规模。并且保留租户隔离会极大程度地使移动性复杂化。常规的分布式虚拟交换机在解决很多领域中的此类问题方面有所不足。首先，它们无法提供多租户，它们不能桥接IP子网，并且不能扩展以支持成千上万的终端主机。而且，这种概念还无法以通用和灵活的方式有效地超越虚拟环境而包括物理主机。因此，在分布式虚拟网络平台这一领域中存在要解决这些以及其他问题的需求。
发明内容
通常，本发明涉及一种虚拟平台，其中一台或多台分布式虚拟交换机可以被建立用于在虚拟网络中使用。根据某些应用，根据本发明的分布式虚拟交换机提供了使虚拟机和物理机得以更加简单、安全和有效地彼此通信的能力，即使它们并不位于同一台物理主机上和/或同一子网或VLAN内亦可。根据其他的应用，本发明中的分布式虚拟交换机能够支持与传统的IP网络集成并且支持包括NAT功能、有状态防火墙以及通知IP网络工作负载迁移的复杂IP技术。根据进一步的应用，本发明中的虚拟平台建立起一台或多台分布式虚拟交换机，可以被分配给租户、应用程序或需要隔离和/或独立配置状态的其他实体。根据更进一步的应用，本发明中的虚拟平台管理和/或利用VLAN或隧道(例如GRE)以建立用于网络同时与网络中现有的交换机和路由器一起工作的分布式虚拟交换机。本发明在企业网、数据中心和其他设施中均可发挥作用。根据这些以及其他的应用，一种根据本发明的实施例在包含多台主机和多种物理转发部件的站点中管理网络资源的方法包括利用多台主机和多种物理转发部件中的第一组来标识第一组虚拟机，利用多台主机和多种物理转发部件中的第二组来标识第二组虚拟机，第一组和第二组中的某些主机和物理转发部件是相同的，并提供第一和第二分布式虚拟交换机专门分别处理第一组和第二组虚拟机之间的通信同时仍保持第一组和第二组虚拟机之间的隔离。为了进一步促进这些以及其他的应用，一种根据本发明的实施例在包含一种或多种物理转发部件的网络内管理通信的方法包括提供由逻辑转发部件构成的网络虚拟层，在逻辑转发部件的端口到某些物理转发部件的端口之间提供映射，并促使物理转发部件利用所提供的映射来转发包(packet)。
在结合附图审阅了以下对本发明具体实施例的说明之后，本发明这些以及其他的应用和特征对于本领域普通技术人员来说将变得显而易见，在附图中图I是根据本发明实施例示出了提供虚拟平台的框图；图2示出了利用本发明的原理在网络中实现的包转发方案；图3根据本发明示出了在具有若干虚拟机和物理主机的数据中心内提供分布式虚拟交换机的示例；以及图4是根据本发明实施例的示例性分布式虚拟交换机的功能框图。
具体实施例方式现参照附图来详细介绍本发明，提供附图作为本发明的示范性示例以使本领域技术人员能够实践本发明。显然地，以下的附图和示例并不意味着将本发明的保护范围限制为单个实施例，而且通过交换部分或全部所述或图示部件可以得到其他的实施例。此外，尽管本发明中有一些部件可以利用已知部件部分或完全实现，但是在这些已知部件中将只介绍用于理解本发明所必须的部分，并且这些已知部件中其他部分的详细说明将予以省略以免造成本发明不清楚。除非本文中另有说明，否则对于本领域技术人员来说显而易见的是描述为用软件实现的实施例不应局限于此，而是可以包括用硬件实现或者用软件和硬件的组合实现的实施例，并且反之亦然。除非本文中另有明确说明，否则在本说明书中，示出了单个部件的实施例不应被认为是限制性的，相反，本发明应被理解为涵盖了包括多个相同部件的其他实施例，并且反之亦然。另外，申请人无意为说明书或权利要求中的任何术语赋予特殊或专用的含义，除非是有这样的明确阐述。而且，本发明涵盖了本文中作为说明而提及的已知部件的现有和未来的已知等价形式。根据主要方面，本发明涉及一种用于供网络使用的虚拟平台，为与其相关联的物理机和虚拟机提供了更加简单、安全和有效地彼此通信的能力，即使它们并不位于相同的物理主机上和/或相同的VLAN或子网内亦可。根据其他方面，本发明还允许多个不同租户共享相同的物理网络设施以在彼此隔离的情况下通信并设定配置状态。图I中示出了本发明的各方面的示例性应用。如图I中所示，一个站点例如数据中心或企业网可以包括物理网络104。物理网络104包括多台虚拟机和/或非虚拟的物理服务器以及物理和虚拟交换机。虚拟机以例如由VMWare提供的虚拟平台(例如被包括在vSphere、vCenter等中)架设并且物理服务器可以是例如由HP、Dell和其他厂商提供的任意的通用计算单元。大型主机服务或企业网能够维持若干站点处的多个数据中心或网络，这些站点可能在地理上是分散的(例如旧金山、纽约等)。图I进一步示出了本发明如何引入了网络虚拟层106，通过网络管理程序102在网络虚拟层106上维持一台或多台分布式虚拟交换机108。这些分布式虚拟交换机108可以跨子网扩展，可以包括物理主机或物理网络端口，并且能够共享相同的物理硬件。根据本发明的各方面，这些分布式虚拟交换机能够为多租户环境提供隔离的环境，能够支持跨子网的虚拟机迁移，能够裁剪为几十或成百上千台物理服务器，并且能够支持与物理环境的无缝集成。作为特定示例，本发明可以由通常针对多位客户支持虚拟和物理主机服务器二者的服务提供商(例如以圣安东尼奥为基地的Rackspace)使用。在这样的示例中，单个客户可以拥有以同一服务提供商架设的虚拟机和物理服务器二者。而且，服务提供商可以在地理上不同的多个位置拥有多个数据中心。本发明可以在服务提供商的工作中使用以使每一 位客户/租户都能够被分配到一台或多台分布式虚拟交换机(DVS) 108。这些DVS可以被独立配置并被赋予由服务提供商的操作人员使用管理程序102指定的最低资源保证。单台DVS可以包含物理和虚拟主机二者并且可以桥接多个子网或VLAN。例如，单台DVS 108可以连接至服务提供商处的虚拟机、作为管理主机服务的一部分的物理机，并且甚至可以跨越因特网扩展以连接至客户端。根据其他方面，本发明在物理转发部件和控制层之间引入了新的抽象。该抽象将转发部件描述为用于控制层的一个或多个逻辑转发部件。逻辑转发部件拥有与它们的物理对应物类似的性质和功能，也就是查询表、端口、计数器以及相关能力(例如端口速度和/或双向带宽)。尽管为了便于说明本发明的各方面而单独示出，但是网络管理程序102和网络虚拟层106优选地通过建立和维持逻辑转发部件并将它们映射至底层硬件的共同软件集合实现(将在下文中进行更加详细的介绍)。名义上，这就意味着将转发状态、计数器和转发部件的事件暴露于其对应的逻辑上下文中。控制层并不直接驱动物理转发部件，而是与逻辑转发部件接口。更具体地，网络虚拟层106对控制层给出受网络104的物理拓扑改变影响最小的转发抽象。从控制层的视角看，向物理拓扑中加入交换机提供了更多的转发带宽，但是不需要对控制逻辑或者逻辑转发表中的现有状态进行任何改变。层106允许逻辑转发部件端口绑定至物理端口或者提供其他的端口抽象例如虚拟机接口、VLAN或隧道。网络管理程序102 (如下所述)的工作是保持层106内的逻辑转发部件上的端口和底层网络104之间的映射，并且相应地更新物理网络内的物理和/或虚拟交换机中的流表。层106内的每一个逻辑转发部件都提供了与传统的交换机数据路径兼容的接口。这是合乎需要的，原因有两个。首先，本发明优选地要与现有硬件兼容并且要有效，所有的转发都应该保留在硬件的快速路径上。因此，逻辑转发层应该优选地映射至现有的转发流水线。第二，现有的网络控制堆栈优选地要与本发明兼容。因此，层106内的逻辑部件的接口包括查询表逻辑转发部件给出一个或多个转发表。通常这包括L2、L3和ACL表。一种示例性实施方式是围绕OpenFlow设计(参见www. openflow. org),据此围绕TCAM的流水线建立更加概括性的表结构，针对每一条规则规定转发动作。该结构提供了允许支持转发规则、ACL、SPAN和其他 要素的相当大的灵活性。 端口 逻辑转发部件包含端口以表示到底层网络的绑定。端口可以由于它们被管理性地加入或它们绑定的部件故障或离开而动态地出现和消失。在本发明的实施例中，端口保留了与其物理模型相同的绝大部分品质，包括rx/tx计数器、MTU、速度、错误计数器和载波信号。物理网络104包括物理转发部件。在本发明的实施例中，转发部件可以是传统的具有标准转发芯片的硬件交换机以及虚拟交换机例如管理程序所包含的虚拟交换机。在本发明的实施例中，现有交换机的部分或全部为协议提供支持，以允许调节它们的流表来实现本发明中的分布式虚拟交换机。这样的协议可以包括OpenFlow，但是也可以使用其他的私有和开源协议例如0SPF。在本发明其他的实施例中，并且根据将在以下更加详细介绍的某些有利的方面，现有物理交换机的部分或全部(并且或许还有部分虚拟交换机)不需要支持这样的协议和/或调节它们的流表。在这样的实施例中，可以利用隧道效应来路由通过这些现有交换机的通信量。在高峰时，物理网络104内由网络管理程序102使用以实现分布式虚拟交换机108的转发部件具有四项主要职责i)将输入包映射至正确的逻辑环境，ii)进行逻辑转发决策，iii)将逻辑转发决策反向映射至物理的下一跳(next hop)地址，以及iv)进行物理转发决策，目的是将包发送至物理的下一跳。更具体地，如图2中所示，所有的包都完全由层106内的一个逻辑转发部件处理。但是，多个逻辑转发部件可以在物理网络104内的同一台物理交换机上被多路复用。所以在输入时，包因此必须被映射至正确的逻辑环境(S202)。可能会有当前的交换机不包含用于指定包的逻辑转发状态的情况，在此情况下交换机就简单地执行物理转发决策(也就是跳到步骤S208)。而且，如果所有的物理交换机都用于仅实现单个逻辑转发部件，那么映射即可变为不操作，原因在于可以在物理网络中使用逻辑寻址。通过本发明可以有多个不同的域用于将包映射至逻辑环境。例如，域可以是识别标记例如MPLS报头或输入端口。但是，为了提供对终端系统的透明性，用于识别逻辑环境的标记优选地不被暴露给连接至逻辑交换机的系统。通常，这就意味着接收包的第一台物理交换机对包进行标记以标明环境，并且最后一台交换机去除该标记。如何选择第一标记在很大程度上取决于配置环境，正如本领域技术人员所理解的那样。在步骤S204，一旦包被映射至其逻辑环境，物理交换机就执行仅在逻辑环境中才有意义的转发决策。这可以是例如用于逻辑交换机的L2查表或逻辑L3路由器所需的查找序列。但是，如果执行逻辑决策的物理交换机没有足够的能力来维持所有的逻辑状态，那么执行的逻辑决策可能就仅仅是整体逻辑决策中需要被执行的一个步骤；以及且因此包在离开逻辑转发层之前可能还需要进一步的逻辑处理。在步骤S206，逻辑决策被映射至物理层。逻辑转发决策的结果(假定没有丢包)是层106内逻辑转发部件上的一个或多个输出端口。一旦确定了这些，网络就必须将包发送至网络104内这些输出端口所绑定的物理对象。这可以是例如另一台物理交换机上的物理端口或者是不同的物理服务器上的虚拟机中的虚拟端口。因此，网络管理程序102必须为物理转发部件设置表项以将逻辑输出端口映射至物理的下一跳。在实施例中，逻辑和物理网络(通过潜在的重叠)共享不同的地址空间。因此，一旦找到用于下一跳的物理地址，就必须封装(逻辑)包以传送至下一跳的物理地址。要注意的是可能会有查表是分布式跨越多个物理部件的情况，在此情况下“下一跳”将会是继续查表的下一个物理部件而不是逻辑输出端口。在步骤S208，物理转发最终得以进行。物理转发决策基于由先前的映射步骤确定的物理地址负责用于转发包离开正确的物理输出端口。这就需要在(在先前步骤中建立的)新物理报头上进行三次(或更多次)的查找。 值得注意的是，如果网络中的物理交换机并不具有多个逻辑环境而是只有一个逻辑环境，那么先前的两个步骤S204和S206即可变为不操作。为了实施以上的四个步骤，物理交换机需要使状态用于i)查表以映射至逻辑环境，ii)逻辑转发决策，iii)从逻辑输出端口映射至物理的下一跳地址，以及iv)物理转发决策。如果优选是要最大化物理网络的控制，那么管理程序102可负责用于管理前三个，而物理转发状态可以通过标准的IGP (例如OSPF或ISIS)实施方式管理或者通过管理程序102管理。在本发明的实施例中，物理网络104的特征对应于现代化的线卡特征。例如，最低程度上，网络104中的物理和/或虚拟交换机应该提供包转发流水线以支持多个逻辑和每一个包中的物理查表。除了基本的转发动作(例如输出端口选择)以外，如果物理交换设施是由多个逻辑转发层共享的，那么硬件就应该支持(嵌套的)封装/解封装以将逻辑地址与物理地址隔离。而且，网络104中物理和/或虚拟交换机的部分或全部必须支持通过网络管理程序102 (例如使用某种协议譬如OpenFlow)来适配流表。用于修改流表的其他示例性方法包括使用SDK，例如由网络芯片组提供商Marvell或Broadcom提供的SDK或者使用交换机厂商的API例如由Juniper提供的OpenJunos API。应该注意的是在某些实施例中并且根据本发明的各方面，可以使用现有的交换机和路由器而无需通过使用隧道来调节流表。逻辑转发部件的能力可以超过单个物理转发部件的能力。因此，物理交换机/转发部件应该优选地提供通信量分流动作(例如ECMP或散列法)和链路聚合，以在多条物理路径/链路上分配通信量。最后，为了有效地监测链路和隧道，物理交换机应该提供基于硬件的链路和隧道监测协议的实施方式(例如BFD)。本领域技术人员应该可以设想出如何基于这些示例以及根据本文中的总体说明来实现物理交换机和物理网络104内的其他部件。在实施例中，网络管理程序102的实施方式从物理转发部件解耦，以使管理程序的实施方式对网络状态拥有全局性的视角。因此，无论何时在其任意一侧的状态发生了改变，通过相应地调节用于网络104内受到影响的所有交换机的映射和/或流表，都不必涉及网络管理程序102。换句话说，在物理网络上有网络拓扑结构事件时或者在控制实施方式改变了逻辑转发层的状态时，需要涉及网络管理程序102。另外，管理程序将以其固有的时间间隔执行资源管理任务以保持物理网络资源的利用最优。
现在根据本发明的实施例介绍用于将逻辑接口 106内的抽象映射至物理网络104的管理程序102的示例性机构。例如，假设有单独的机构用于建立、定义和管理逻辑接口内应该有的内容-也就是例如接口应该面向多少个逻辑转发部件以及它们的互连是怎样的
坐寸o如果假定使用的物理交换机全都提供了上述的所有要素，那么管理程序102在将逻辑接口抽象映射至物理硬件时就会遇到两个挑战潜在地限制个体物理转发部件的交换容量以及端口的有限数量和容量。 潜在地限制个体物理转发部件中的TCAM表的容量。 在数据中心的环境中，网络管理程序的任务由于网络拓扑结构很可能是粗树(fat-tree)而得以简化；因此，通过离线负载平衡(例如ECMP)或在线方式(例如TeXCP)实现的多路径将在网络拓扑结构的任意位置之间提供统一的容量。因此，即使是对极高容量的逻辑交换机，网络管理程序102也能够实现所需的容量，而无需使物理转发部件具有匹配的容量。设置问题如果与物理转发部件相关的TCAM表容量(对于特定的控制层实施方式来说)不成问题，那么网络管理程序的任务就由于它能在每一个物理转发部件中具有全部逻辑转发状态而得以简化。但是，如果可用的物理TCAM资源比较缺乏，那么管理程序102在物理网络内设置逻辑转发决策时就必须更加智能。在物理网络部件(TCAM规模方面)并不相等并且其中一部分具有足够的容量用于逻辑转发表的配置中，网络管理程序102可以先用这部分部件用于逻辑转发决策，并随后仅使用其余的部分用于在它们之间转发包。本领域技术人员应该意识到高容量物理转发部件准确的拓扑位置可能会遗留成为特定于配置的问题，但是要么将其保留在边缘作为第一跳的部件，要么就将其保留在(它们被共享的)核心区域，这都是合理的出发点。如果配置中不具有能够保留完整逻辑转发表(多个)的物理转发部件，那么管理程序102可以通过划分有问题的逻辑查表步骤以覆盖多个物理部件或者使用分离的物理转发部件以实现分离的逻辑查表步骤(如果逻辑转发是步骤链的话)来分解问题。在任何一种情况下，物理转发部件都应该以向下一个物理转发部件传送必要上下文的方式将处理过的包发送至下一个物理转发部件，从而在先前的物理转发停止的位置继续进行处理。如果特定于配置的限制处于上述两种极端情况之间的某种程度，那么网络管理程序102可以明确地在最优的转发表资源利用和最优的网络带宽使用之间进行权衡。最后，要注意的是对于所有的物理转发部件，如果具有逻辑转发表(多个)所需容量的个体部件的转发容量成为限制因素，那么管理程序102可以围绕该限制对多个这样的部件进行负载平衡。在图3示出的一个特定的示例性实施方式中，本发明提出了一种跨越多台虚拟和物理交换机分布并且以新颖的方式综合了速度、安全性和灵活性的分布式虚拟网络平台。如图3中所示，本发明提供了一种分布式虚拟交换机(DVS) 108，允许虚拟机类似于在同一L2网络内那样的高效方式跨越主机和/或虚拟LAN和/或子网通信。而且，本发明允许将多台分布式虚拟交换机108设置在同一物理主机上或相同的数据中心内，以允许多个租户共享相同的物理硬件，同时仍然保持隔离以避免彼此寻址和消耗彼此的资源。如图3中所示，一组织(例如数据中心租户)具有多台物理主机和使用包括主机300-A到300-X的数据中心的服务的虚拟机。如图所示,这些至少包括主机300-A上的虚拟机302-1和302-3、主机300-C上的虚拟机302-4和主机300-D上的虚拟机302-6。尽管数据中心可以尝试在共用VLAN中包括这些虚拟机用于管理和其他目的，但是在虚拟机数量超过数据中心所支持的VLAN规模时，这样做就变得不再可行。而且，VLAN需要在虚拟机移动时配置网络，而且VLAN不能在没有附加机构的情况下跨越子网。如图3中进一步示出的那样，虚拟交换机304-可能也是分布在多台不同的主机300上-以及物理交换机306由本发明中的虚拟层106和/或管理程序102所使用，以共同地用作单台分布式虚拟交换机308，从而共同地允许这些分散的虚拟机彼此通信，并且进一步还可以与经过授权的主机305 (例如租户组织的授权用户，这些用户可以在独立的外部客户端上和/或通过公共或私有网络连接至数据中心的资源)通信，即使它们位于不同 的主机和/VLAN上(即，子网)。如上所述并且如以下将要更加详细介绍的那样，管理程序102可以被用于管理虚拟网络，例如通过配置QOS设置、ACL、防火墙、负载平衡等进行管理。在实施例中，管理程序102可以由使用网络操作系统的控制器实施(例如申请号为12/286,098的共同待决申请中所介绍的)，通过引用将其内容并入本文并根据本发明的原理予以适用。但是，也可以使用其他的OpenFlow标准或其他的专用或开放式的控制器。管理程序102和/或分布式虚拟交换机108也可以采用申请号为11/970，976的美国专利申请中介绍的某些技术，通过引用将其内容并入本文。虚拟交换机304可以包括可商业获得的虚拟交换机例如由思科和Vmware提供的产品或其他专用的虚拟交换机。优选地，绝大部分或全部的虚拟交换机304都包括OpenFlow或其他的标准或专用协议支持以用于与网络管理程序102通信。物理交换机306可以包括任意可商业获得的交换机(例如NEC(IP8800)或HP(ProCurve 5406ZL))或包括OpenFlow或其他标准或专用协议支持的专用交换机，例如以上提及的用于与网络管理程序102通信的那些专用交换机。但是，在本发明的上述实施例中并且如下文中进一步介绍的那样，可以使用某些或者全部的网络内的现有物理交换机和路由器306，而无需通过利用隧道来影响流表。如图3中所示，虚拟交换机304与虚拟机302通信，同时物理交换机306与物理主机305通信。示例性的主机300包括例如运行Vmware ESX管理程序的服务器(例如Dell、HP等)。但是，本发明并不局限于该示例性实施例，并且本领域技术人员应该理解如何利用其他的操作系统和/或管理程序等来实现本发明的这种实施例以及等价实施例。这包括例如Citrix XenServer、Linux KVM。而且,应该注意的是,并非包括在组织内由管理程序102管理的所有物理主机都需要运行一个虚拟软件(例如部分或全部的主机305)。现在根据本发明的实施例结合图4介绍分布式虚拟交换机108的一种示例性实施方式。如上所述，例如图4中所示的分布式虚拟交换机108利用了多种传统的虚拟交换机304和物理交换机306来提供与底层结构解耦的逻辑抽象。在图4中能够看出并且应该注意到，分布式虚拟交换机108优选地包括其自身的L2和L3逻辑流表，它们可以与底层交换机304和306中的流表相同也可以不同。这是用于实现如上所述的虚拟层106的控制层内的逻辑转发部件。如图4中所示，由分布式虚拟交换机108使用的每一个虚拟和物理交换机都包括用于与网络管理程序102通信的安全信道。这可以是例如实现OpenFlow标准的通信模块(参见WWW. openflow. org)并且适用于利用OpenFlow协议与控制器通信。但是，其他的专用和开放式协议也是可行的。每一台虚拟和物理交换机304和306还包括其自身的逻辑和物理流表以及用于将输入包映射至逻辑上下文的映射表(也就是说，使得单台物理交换机可以支持多台逻辑交换机)。这可以利用常规交换机中可由管理程序102操作的标准流表和转发引擎来实现。换句话说，管理程序102调节现有流表内的项目以使304和306内的现有转发引擎实现上述的逻辑和其他映射。应该意识到交换机304和306可以具有另外的流表项目，这些流表项目不受本发明影响并且可以利用常规方式来建立和维护(例如网络管理、规则、路由请求等)。如图4中进一步示出的那样，为了支持跨越不同子网的通信，并且也是为了适用于现有的不受调节流表影响的物理和/或虚拟交换机和路由器，本发明中用于实现分布式虚拟交换机108的某些物理和虚拟交换机306和304优选地包括隧道管理器。在一个示例性实施例中，隧道管理器将VLAN或通用路由封装(GRE)隧道用于一组用作虚拟专用L2广 播域的虚拟专用网络(PVN)。控制器110维护将虚拟机102映射至一个或多个相关PVN的数据库。对于每一个PVN，控制器110和/或交换机104都建立并维护一组连接主机的PVN隧道，广播包和其他的包沿着这组隧道被承载。用这种方式，同一 PVN内的虚拟机102即使处于不同的L2域和/或不同的主机内也能够彼此通信。而且，与PVN内的主机相关联的所有虚拟机都可以看到通过虚拟机在PVN内的其他主机上发送的所有广播包，并且这些包对于该PVN以外的任何主机都是不可见的。正如本领域技术人员所理解的，根据本发明，建立隧道和/或如何利用隧道管理器204通过PVN来互连主机均可有多种不同的方式。尽管已经参照其优选实施例部分地介绍了本发明，但是对于本领域普通技术人员来说可以进行形式和细节上的多种修改和变形而并不背离本发明的实质和保护范围应该是显而易见的。应该认为所附权利要求涵盖了这样的修改和变形。
权利要求
1.一种在包含多台主机和多个物理转发部件的站点中管理网络资源的方法，包括 利用多台主机和多个物理转发部件中的第一组来标识第一组虚拟机； 利用多台主机和多个物理转发部件中的第二组来标识第二组虚拟机，第一组和第二组中的某些主机和物理转发部件是相同的； 提供第一和第二分布式虚拟交换机，专门分别处理第一组和第二组虚拟机之间的通信，同时保持第一组和第二组虚拟机之间的隔离。
2.如权利要求I所述的方法，其中所述物理转发部件包括一台或多台虚拟交换机。
3.如权利要求I所述的方法，其中所述物理转发部件包括一台或多台物理交换机。
4.如权利要求I所述的方法，其中所述第一和第二分布式虚拟交换机进一步分别处理外部主机与第一组和第二组虚拟机之间的通信。
5.如权利要求I所述的方法，其中所述第一组和第二组虚拟机分别与第一和第二数据中心租户相关联。
6.如权利要求I所述的方法，进一步包括 在其中一个物理转发部件内提供逻辑流表和物理流表； 确定逻辑流表和物理流表之间的映射；以及 利用逻辑流表和物理流表以及确定的映射促使物理转发部件转发包。
7.如权利要求6所述的方法，其中所述的一个物理转发部件由第一组和第二组虚拟机二者使用。
8.如权利要求I所述的方法，其中所述多台主机中的某些主机位于地理上分离的场所。
9.如权利要求I所述的方法，其中所述第一组虚拟机中的某些虚拟机处于不同的子网内。
10.如权利要求I所述的方法，进一步包括 提供通过某些物理转发部件的隧道。
11.如权利要求10所述的方法，其中所述隧道包括GRE隧道。
12.—种在包含一个或多个物理转发部件的网络内管理通信的方法，包括 提供包括逻辑转发部件的网络虚拟层； 在逻辑转发部件的端口到某些物理转发部件的端口之间提供映射；以及 利用所提供的映射促使物理转发部件转发包。
13.如权利要求12所述的方法，其中所述促使步骤包括 查找用于所述包的逻辑上下文； 根据逻辑上下文标识用于所述包的逻辑输出端口； 根据所提供的映射将逻辑输出端口映射至物理输出端口 ；以及 查找所述物理输出端口。
14.如权利要求12所述的方法，其中所述物理转发部件包括物理交换机。
15.如权利要求12所述的方法，其中所述物理转发部件包括虚拟交换机。
16.一种包含多台主机和多个物理转发部件的网络站点，包括 第一组虚拟机，使用多台主机和多个物理转发部件中的第一组； 第二组虚拟机，使用多台主机和多个物理转发部件中的第二组，所述第一组和第二组中的某些主机和物理转发部件是相同的； 第一和第二分布式虚拟交换机，专门分别处理第一组和第二组虚拟机之间的通信，同时保持第一组和第二组虚拟机之间的隔离。
17.如权利要求16所述的网络站点，其中所述物理转发部件包括一台或多台虚拟交换机。
18.如权利要求16所述的网络站点，其中所述物理转发部件包括一台或多台物理交换机。
19.如权利要求16所述的网络站点，其中所述第一和第二分布式虚拟交换机进一步分别处理外部主机与第一组和第二组虚拟机之间的通信。
20.如权利要求16所述的网络站点，其中所述第一组和第二组虚拟机分别与第一和第二数据中心租户相关联。
21.如权利要求16所述的网络站点，进一步包括 其中一个物理转发部件内的逻辑流表和物理流表；以及 逻辑流表和物理流表之间的映射，其中物理转发部件利用逻辑流表和物理流表以及所确定的映射来转发包。
22.如权利要求21所述的网络站点，其中所述的一个物理转发部件由第一组和第二组虚拟机二者使用。
23.如权利要求16所述的网络站点，其中所述多台主机中的某些主机位于地理上分离的场所。
24.如权利要求16所述的网络站点，其中所述第一组虚拟机中的某些虚拟机处于不同的子网内。
25.如权利要求16所述的网络站点，进一步包括 通过某些物理转发部件的隧道。
26.如权利要求25所述的网络站点，其中所述隧道包括GRE隧道。
全文摘要
通常，本发明涉及一种虚拟平台，其中一台或多台分布式虚拟交换机可以被建立用于在虚拟网络中使用。根据某些应用，根据本发明的分布式虚拟交换机提供了使虚拟机和物理机得以更加简单、安全和有效地彼此通信的能力，即使它们并不位于同一台物理主机上和/或同一子网或VLAN内亦可。根据其他的应用，本发明中的分布式虚拟交换机能够支持与传统的IP网络集成并且支持包括NAT功能、有状态防火墙以及通知IP网络工作负载迁移的复杂IP技术。根据其他方面，本发明中的虚拟平台建立起一台或多台分布式虚拟交换机，可以被分配给租户、应用程序或需要隔离和/或独立配置状态的其他实体。根据更其他方面，本发明中的虚拟平台管理和/或利用VLAN或隧道(例如GRE)以建立用于网络同时与网络中现有的交换机和路由器一起工作的分布式虚拟交换机。本发明在企业网、数据中心和其他设施中均可发挥作用。
文档编号G06F9/455GK102726007SQ201080014332
公开日2012年10月10日 申请日期2010年4月1日 优先权日2009年4月1日
发明者B·L·帕夫, D·J·温德兰得特, J·E·格洛斯四世, J·皮提特, K·E·阿密顿, M·卡萨多, P·J·巴尔兰德三世, P·因格拉姆, T·考珀内恩 申请人:Nicira网络公司