131 lines
6.6 KiB
XML
131 lines
6.6 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:id="module002-ch003-neutron-use-cases">
|
|
<title>Neutron Use Cases</title>
|
|
<para>As of now you must be wondering, how to use these awesome
|
|
features that OpenStack Networking has given to us.</para>
|
|
<para><guilabel>Use Case: Single Flat Network</guilabel></para>
|
|
<para>In the simplest use case, a single OpenStack Networking
|
|
network exists. This is a "shared" network, meaning it is
|
|
visible to all tenants via the OpenStack Networking API.
|
|
Tenant VMs have a single NIC, and receive a fixed IP
|
|
address from the subnet(s) associated with that network.
|
|
This essentially maps to the FlatManager and
|
|
FlatDHCPManager models provided by OpenStack Compute.
|
|
Floating IPs are not supported.</para>
|
|
<para>It is common that an OpenStack Networking network
|
|
is a "provider network", meaning it was created by the
|
|
OpenStack administrator to map directly to an existing
|
|
physical network in the data center. This allows the
|
|
provider to use a physical router on that data center
|
|
network as the gateway for VMs to reach the outside world.
|
|
For each subnet on an external network, the gateway
|
|
configuration on the physical router must be manually
|
|
configured outside of OpenStack.</para>
|
|
<figure>
|
|
<title>Single Flat Network</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="figures/image34.png"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<para><guilabel>Use Case: Multiple Flat
|
|
Network</guilabel></para>
|
|
<para>This use case is very similar to the above Single Flat
|
|
Network use case, except that tenants see multiple shared
|
|
networks via the OpenStack Networking API and can choose
|
|
which network (or networks) to plug into.</para>
|
|
<figure>
|
|
<title>Multiple Flat Network</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="figures/image35.png"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<para><guilabel>Use Case: Mixed Flat and Private
|
|
Network</guilabel></para>
|
|
<para>This use case is an extension of the above flat network
|
|
use cases, in which tenants also optionally have access to
|
|
private per-tenant networks. In addition to seeing one or
|
|
more shared networks via the OpenStack Networking API,
|
|
tenants can create additional networks that are only
|
|
visible to users of that tenant. When creating VMs, those
|
|
VMs can have NICs on any of the shared networks and/or any
|
|
of the private networks belonging to the tenant. This
|
|
enables the creation of "multi-tier" topologies using VMs
|
|
with multiple NICs. It also supports a model where a VM
|
|
acting as a gateway can provide services such as routing,
|
|
NAT, or load balancing.</para>
|
|
<figure>
|
|
<title>Mixed Flat and Private Network</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="figures/image36.png"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<para><guilabel>Use Case: Provider Router with Private
|
|
Networks</guilabel></para>
|
|
<para>This use provides each tenant with one or more private
|
|
networks, which connect to the outside world via an
|
|
OpenStack Networking router. The case where each tenant
|
|
gets exactly one network in this form maps to the same
|
|
logical topology as the VlanManager in OpenStack Compute
|
|
(of course, OpenStack Networking doesn't require VLANs).
|
|
Using the OpenStack Networking API, the tenant would only
|
|
see a network for each private network assigned to that
|
|
tenant. The router object in the API is created and owned
|
|
by the cloud admin.</para>
|
|
<para>This model supports giving VMs public addresses using
|
|
"floating IPs", in which the router maps public addresses
|
|
from the external network to fixed IPs on private
|
|
networks. Hosts without floating IPs can still create
|
|
outbound connections to the external network, as the
|
|
provider router performs SNAT to the router's external IP.
|
|
The IP address of the physical router is used as the
|
|
gateway_ip of the external network subnet, so the provider
|
|
has a default router for Internet traffic.</para>
|
|
<para>The router provides L3 connectivity between private
|
|
networks, meaning that different tenants can reach each
|
|
other's instances unless additional filtering, such as
|
|
security groups, is used. Because there is only a single
|
|
router, tenant networks cannot use overlapping IPs. Thus,
|
|
it is likely that the admin would create the private
|
|
networks on behalf of tenants.</para>
|
|
<figure>
|
|
<title>Provider Router with Private Networks</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="figures/image37.png"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<para><guilabel>Use Case: Per-tenant Routers with Private
|
|
Networks</guilabel></para>
|
|
<para>A more advanced router scenario in which each tenant
|
|
gets at least one router, and potentially has access to
|
|
the OpenStack Networking API to create additional routers.
|
|
The tenant can create their own networks, potentially
|
|
uplinking those networks to a router. This model enables
|
|
tenant-defined multi-tier applications, with each tier
|
|
being a separate network behind the router. Since there
|
|
are multiple routers, tenant subnets can be overlapping
|
|
without conflicting, since access to external networks all
|
|
happens via SNAT or Floating IPs. Each router uplink and
|
|
floating IP is allocated from the external network
|
|
subnet.</para>
|
|
<figure>
|
|
<title>Per-tenant Routers with Private Networks</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="figures/image38.png"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
</chapter>
|