openstack-manuals/doc/training-guide/module002-ch003-neutron-use-cases.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><anchor xml:id="h.lrsgdytf1mh5"/>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 such 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
            others instances unless additional filtering (e.g.,
            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>