OpenStack的网络管理指南（1）——概述

英文版查看http://docs.openstack.org/trunk/openstack-network/admin/content/ch_preface.html

个人翻译和理解有限，有错误的地方请各位大牛指正

前言

openstack网络的建立是为定义网络连接和云中的寻址提供丰富的API，Neutron服务（先前被称为“Quantum”），使运营商能够利用不同的网络技术去搭建他们的云网络。

作为与昆腾公司（ “量子”商标的所有者）的一份法律协议的一部分，参与网络相关的开发和文档董事会董事和技术委员会成员已决定更改代码名称为“Neutron” 。

在本指南中，尽可能的删除对以前代码名称的任何引用，所有的配置文件已经分别在 “Havana”和本指南中更新。

目标读者

本指南帮助OpenStack的管理员利用不同的网络技术去搭建云网络。本文档介绍了如何安装，配置和运行OpenStack的网络。

你必须具有一个提供openstack网络服务实施的插件，这个插件可以分配内部和外部的openstack网络，要了解更多的信息，请查看插件列表http://docs.openstack.org/trunk/openstack-network/admin/content/flexibility.html

你也应该熟悉如何按照运营商的文件中所描述的运行OpenStack计算服务。

文档修改历史

此版手册将取代并淘汰所有先前的版本。下表描述了最近的变化：

Revision DateSummary of Changes

June 5, 2013

• Added Chapter 5, Under the Hood.

May 9, 2013

• Updated the book title for consistency.

April 30, 2013

• Grizzly release.

March 24, 2013

• Added auth_token parameters to the neutron.conf file description.

February 4, 2013

• Use OpenStack naming conventions through out document.

December 20, 2012

• Trunk designation of this document.

November 9, 2012

• Folsom release of this document.

September 18, 2012

• First edition of this document.

资源

OpenStack的网络和其他相关项目的更多信息，请参阅该项目OpenStack的维基（ wiki.openstack.org /Neutron） 。

关于对OpenStack的网络API编程的详细信息，请参阅OpenStack的网络API指南（ V2.0 ） 。

我们欢迎反馈，意见和bug报告在bugs.launchpad.net /Neutron。

openstack网络架构

本节描述openstack网络高级组件，在你部署openstack网络之前，了解不同的解决方案，以及这些组件之间和其他服务是如何相互交互，非常有用。

概述

OpenStack的网络是一个独立的服务，就像其他的OpenStack的服务，如OpenStack计算服务， OpenStack的镜像服务，OpenStack的身份认证服务，或OpenStack的界面。和这些服务类似，部署OpenStack的网络往往涉及到各个主机上部署多个进程。

openstack网络服务的主进程是neutron-server，这是一个python的守护进程，暴露了openstack网络API，将用户的请求传递到openstack网络插件以配置额外的处理。通常情况下，这个插件需要访问数据库做持久保存（和其他openstack服务）

如果你的部署方式是使用一台控制主机来集中管理OpenStack计算组件，那么你可以在同一主机上部署OpenStack的网络服务。不过， OpenStack的网络是完全独立的，并可以部署在自己的主机上。 OpenStack的网络也可能需要的额外的代理，这得看你的部署方式

有以下三种代理方式：

插件代理：运行在每个虚拟机管理程序来执行本地vswitch配置。是否运行代理将取决于您使用的插件，因为有些插件实际上并不需要代理。

DHCP代理（neutron-DHCP代理：为租户网络提供DHCP服务。这个代理对所有插件是一样的。
L3代理（neutron-L3代理）：提供L3/NAT转发为租户网络上的虚拟机提供外部网络访问。这个代理对所有插件也是一样的。

以上的代理通过RFC(比如rabbitmq 或者qpid)，或者标准的openstack网络API 和neutron主进程进行交互。

此外

openStack的网络依赖OpenStack的身份服务（keystone）的身份验证和授权的所有API。

openstack网络与openstack计算（nova）通过标准API进行交互，作为创建虚拟机的一部分，nova计算服务和openstack网络API的通信，是插入到每个特定网络的每个虚拟机的虚拟网卡上的
openstack的界面（horizon）集成了openstack网络的API，允许管理员和租户用户通过界面去创建和管理网络服务

在物理机上部署服务

和其他的openstack服务一样，openstack网络给云管理员决定在某个服务器上运行某个服务提供了显著的灵活性。一个极端情况是，所有服务的守护进程都运行在一个单一的物理主机上。另外，每个服务都可以运行在自己的主机上，在某些情况下可以复制冗余的主机。欲了解更多情况，请参见高可用性high availability.

我们将注意力主要集中在一个标准的架构，包括一台控制主机和一台网络主机，以及一套正在运行的虚拟机管理程序，控制主机和网络主机可以部署在一台主机上。但是假如你希望虚拟机从网络上发送大量的的流量，那么建议你使用单独的网络主机，以避免潜在的CPU争用L3代理和其他的openstack服务

网络拓扑

一个标准的OpenStack的网络有四种不同的物理数据中心网络：

管理网络：用于OpenStack的组件之间的内部沟通。在此网络上的IP地址应该只限于在数据中心内部访问

数据网络：用于云内部署虚拟机的数据通信。这个网络的IP寻址要求依赖于OpenStack的网络正在使用的插件。

外部网络：用于提供虚拟机在某些部署情况下连接外网。这个网络上的IP地址应该是在互联网上可以被任何人访问。

API网络：  对租户公开所有的OpenStack的API ，包括OpenStack的网络API 。这个网络上的IP地址应该是在互联网上可以被任何人访问。 API网络跟外部网络一样，因为它可以创建一个外部子网，当使用不了全部的ip地址的时候，可以分配ip地址的范围。

先发表了，后面慢慢翻译。。。（翻译好费力啊。。。）

人数破100了啊。。。继续翻译

OpenStack的网络部署使用案例

以下几个图是比较经典的

案例一：单平面网络（Single Flat Network，这个术语不太好翻译就直接翻译了）

在最简单的情况下，创建的一个openstack网络。这是一个“共享”的网络，这意味着对所有的租户都是可见的，租户的每台虚拟机都有单一的网卡，并从该网络的子网获得固定的ip地址，这个使用案例基本上映射到OpenStack计算所提供的FlatManager和FlatDHCPManager模型。不支持浮动IP地址。

这种类型的网络，常常被openstack管理员映射到数据中心的现有物理网络上（故被称为“服务提供商网络”），这使得供应商可以使用数据中心的物理路由器作为网关让虚拟机到达外部世界，对于openstack外部网络的每一个子网，物理路由器的网关配置必须是手动的。

案例二：多平面网络

除了租户可以通过openstack API看到多个不同的共享网络和可以选择插入不同的网络外，本案例类似于上述的单平面网络

案例三：混杂的平面和专用网络

这个用例是上述模式的延伸，除了能够看到一个或者多个共享网络之外，租户还可以拥有自己专有的网络（对唯一租户可用的网络）

虚拟机可以有多个网卡来插入任意一个共享网络或者获得任意一个专属的私有网络，这种具有多个网卡的虚拟机的创建使多层网络拓扑结构成为可能。它还支持虚拟机充当网关，从而提供像路由，NAT，负载均衡等等的服务。

案例四：供应商路由器和专用网络

该用例提供每个租户一个或多个专用网络，通过OpenStack的网络路由器连接到外面的世界。每个租户的网络，映射为相同的逻辑拓扑的VlanManager（尽管OpenStack的网络不需要VLAN）。使用OpenStack的网络API ，租户只能看到分配给该租户的每个专用网络，而API中的路由器对象是由openstack的云管理员所创建和持有

这个模型支持浮动ip，路由器通过浮动ip将外部网络的地址映射到虚拟机的私有网络的固定ip上，没有浮动ip的主机仍然可以连接外部网络，因为提供商路由器对路由器的外部ip实现了SNAT，物理路由器的IP地址作为外部网络的子网gateway_ip，所以供应商具有互联网流量的缺省路由器。

路由器提供给专用网络的L3连接，这意味着除非使用额外的过滤（例如安全组），不同的租户才可以互相连接。因为只有单一的路由器，所以租户的网络不能使用重叠的ip地址。因此它可能是管理员将创建代表租户的私有网络。

案例五：租户路由器和专用网络

此用例代表了更先进的路由器，在这种情况下每个租户得到至少一个路由器，并有可能通过openstack的网络API创建更多的路由器，租户可以建立自己的网络，这些网络上行到路由器上。这种模式允许租户定义，多层次的应用。每一层是路由器后面的一个单独的网络。因为有多个路由器，租户的子网可以无冲突的重叠，因为访问外部网络是通过SNAT或者浮动ip发生的。每个路由器上行和浮动IP是来自外部网络的子网分配。