en-US/inter-vlan-routing.xml

<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "cloudstack.ent">
%BOOK_ENTITIES;
]>
<!-- Licensed to the Apache Software Foundation (ASF) under one
    or more contributor license agreements.  See the NOTICE file
    distributed with this work for additional information
    regarding copyright ownership.  The ASF licenses this file
    to you under the Apache License, Version 2.0 (the
    "License"); you may not use this file except in compliance
    with the License.  You may obtain a copy of the License at
    http://www.apache.org/licenses/LICENSE-2.0
    Unless required by applicable law or agreed to in writing,
    software distributed under the License is distributed on an
    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    KIND, either express or implied.  See the License for the
    specific language governing permissions and limitations
    under the License.
-->
<section id="inter-vlan-routing">
  <title>About Inter-VLAN Routing (nTier Apps)</title>
  <para>Inter-VLAN Routing (nTier Apps) is the capability to route network traffic between VLANs.
    This feature enables you to build Virtual Private Clouds (VPC), an isolated segment of your
    cloud, that can hold multi-tier applications. These tiers are deployed on different VLANs that
    can communicate with each other. You provision VLANs to the tiers your create, and VMs can be
    deployed on different tiers. The VLANs are connected to a virtual router, which facilitates
    communication between the VMs. In effect, you can segment VMs by means of VLANs into different
    networks that can host multi-tier applications, such as Web, Application, or Database. Such
    segmentation by means of VLANs logically separate application VMs for higher security and lower
    broadcasts, while remaining physically connected to the same device.</para>
  <para>This feature is supported on XenServer, KVM, and VMware hypervisors.</para>
  <para>The major advantages are:</para>
  <itemizedlist>
    <listitem>
      <para>The administrator can deploy a set of VLANs and allow users to deploy VMs on these
        VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest
        VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that
        account.</para>
      <note>
        <para>A VLAN allocated for an account cannot be shared between multiple accounts. </para>
      </note>
    </listitem>
    <listitem>
      <para>The administrator can allow users create their own VPC and deploy the application. In
        this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that
        account.</para>
    </listitem>
    <listitem>
      <para>Both administrators and users can create multiple VPCs. The guest network NIC is plugged
        to the VPC virtual router when the first VM is deployed in a tier. </para>
    </listitem>
    <listitem>
      <para>The administrator can create the following gateways to send to or receive traffic from
        the VMs:</para>
      <itemizedlist>
        <listitem>
          <para><emphasis role="bold">VPN Gateway</emphasis>: For more information, see <xref
              linkend="create-vpn-gateway-for-vpc"/>.</para>
        </listitem>
        <listitem>
          <para><emphasis role="bold">Public Gateway</emphasis>: The public gateway for a VPC is
            added to the virtual router when the virtual router is created for VPC. The public
            gateway is not exposed to the end users. You are not allowed to list it, nor allowed to
            create any static routes.</para>
        </listitem>
        <listitem>
          <para><emphasis role="bold">Private Gateway</emphasis>: For more information, see <xref
              linkend="add-gateway-vpc"/>.</para>
        </listitem>
      </itemizedlist>
    </listitem>
    <listitem>
      <para>Both administrators and users can create various possible destinations-gateway
        combinations. However, only one gateway of each type can be used in a deployment.</para>
      <para>For example:</para>
      <itemizedlist>
        <listitem>
          <para><emphasis role="bold">VLANs and Public Gateway</emphasis>: For example, an
            application is deployed in the cloud, and the Web application VMs communicate with the
            Internet.</para>
        </listitem>
        <listitem>
          <para><emphasis role="bold">VLANs, VPN Gateway, and Public Gateway</emphasis>: For
            example, an application is deployed in the cloud; the Web application VMs communicate
            with the Internet; and the database VMs communicate with the on-premise devices.</para>
        </listitem>
      </itemizedlist>
    </listitem>
    <listitem>
      <para>The administrator can define Network Access Control List (ACL) on the virtual router to
        filter the traffic among the VLANs or between the Internet and a VLAN. You can define ACL
        based on CIDR, port range, protocol, type code (if ICMP protocol is selected) and
        Ingress/Egress type.</para>
    </listitem>
  </itemizedlist>
  <para>The following figure shows the possible deployment scenarios of a Inter-VLAN setup:</para>
  <mediaobject>
    <imageobject>
      <imagedata fileref="./images/multi-tier-app.png"/>
    </imageobject>
    <textobject>
      <phrase>mutltier.png: a multi-tier setup.</phrase>
    </textobject>
  </mediaobject>
  <para>To set up a multi-tier Inter-VLAN deployment, see <xref linkend="configure-vpc"/>.</para>
</section>