openstack-manuals/doc/arch-design/hybrid/section_tech_considerations_hybrid.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE section [
<!ENTITY % openstack SYSTEM "../../common/entities/openstack.ent">
%openstack;
]>
<section 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="technical-considerations-hybrid">
    <?dbhtml stop-chunking?>
    <title>Technical considerations</title>
    <para>A hybrid cloud environment requires inspection and
        understanding of technical issues that are not only outside of
        an organization's data center, but potentially outside of an
        organization's control. In many cases, it is necessary to
        ensure that the architecture and CMP chosen are adaptable.
        All of these factors influence
        and add complexity to the design of the hybrid cloud architecture.</para>
    <para>Incompatibilities with other cloud platforms are inevitable,
        however, clouds using the same version and distribution
        of OpenStack are unlikely to experience any issues.</para>
    <para>Clouds that exclusively use the same versions of OpenStack should
        have no issues, regardless of distribution. The newer the distribution in
        question, the less likely it is that there will be
        incompatibilities between versions. An OpenStack community initiative defines
        core functions that need to remain backward compatible between supported
        versions.</para>
      <note>
        <para>For example, the DefCore initiative defines
           basic functions that every distribution must support in order
           to bear the name <productname>OpenStack</productname>.</para>
      </note>
    <para>Vendors can add proprietary customization to their distributions. If
        an application or architecture makes use of these features, it will be
        difficult to migrate to or use other types of environments.</para>
    <para>If an environment includes non-OpenStack clouds, it may experience
        compatibility problems. CMP tools must account for the differences in the
        handling of operations and implementation of services. Some situations in which these
        incompatibilities can arise include differences between the way in which a
        cloud:</para>
    <itemizedlist>
        <listitem>
            <para>Deploys instances</para>
        </listitem>
        <listitem>
            <para>Manages networks</para>
        </listitem>
        <listitem>
            <para>Treats applications</para>
        </listitem>
        <listitem>
            <para>Implements services</para>
        </listitem>
    </itemizedlist>

    <section xml:id="capacity-planning-hybrid">
      <title>Capacity planning</title>
    <para>One of the primary reasons many organizations turn to a
        hybrid cloud system is to increase capacity without having to
        make large capital investments.</para>
    <para>Capacity, and the placement of workloads,
        accounts for the design of a mostly
        internally-operated cloud.
        The long-term capacity plan for this design must incorporate
        growth over time to prevent permanent consumption of a more
        expensive external cloud. In order to avoid this scenario, we
        recommend accounting for the future applications' capacity
        requirements and plan growth appropriately.</para>
    <para>Unpredictability is a consideration for capacity planning. It is
        difficult to predict the amount of load a particular application
        might incur if the number of users fluctuate, or the application
        experiences an unexpected increase in popularity. It is possible
        to define application requirements in terms of vCPU, RAM, bandwidth
        or other resources and plan appropriately. However, other clouds
        might not use the same meter or even the same oversubscription rates.</para>
    <para>Oversubscription is a method to emulate more capacity than
        may physically be present. For example, a physical
        hypervisor node with 32&nbsp;GB RAM may host 24
        instances, each provisioned with 2&nbsp;GB RAM. As long
        as all 24 instances are not concurrently utilizing 2 full
        gigabytes, this arrangement is a non-issue. However, some
        hosts take oversubscription to extremes and, as a result,
        performance can frequently be inconsistent. If at all
        possible, determine what the oversubscription rates of each
        host are and plan capacity accordingly.</para>
    </section>

    <section xml:id="security-hybrid">
      <title>Security</title>
    <para>Security domains are an important distinction when planning for a hybrid
        cloud environment and its capabilities. A security domain
        comprises users, applications, servers or networks that share
        common trust requirements and expectations within a
        system.</para>
    <para>The security domains are:</para>
    <orderedlist>
        <listitem>
            <para>Public</para>
        </listitem>
        <listitem>
            <para>Guest</para>
        </listitem>
        <listitem>
            <para>Management</para>
        </listitem>
        <listitem>
            <para>Data</para>
        </listitem>
    </orderedlist>
    <para>You can map the security domains individually to the
        organization's installation or combine them. For example, some
        deployment topologies combine both guest and data domains onto
        one physical network, whereas other topologies physically
        separate the networks. In each case, the cloud operator
        should be aware of the appropriate security concerns.  We recommend
        mapping security domains against the specific OpenStack
        deployment topology. The domains and their trust requirements
        depend upon whether the cloud instance is public, private, or
        hybrid.</para>
    <para>The public security domain is an entirely untrusted area of
        the cloud infrastructure. It can refer to the internet as a
        whole, or simply to networks over which an organization has no
        authority. Do not trust this domain.
        For example, in a hybrid cloud deployment, any information traversing
        between and beyond the clouds is of the public domain and untrustworthy.</para>
    <para>The guest security domain handles compute
        data. Instances on the cloud generate the data, but not services that
        support the operation of the cloud, such as API calls. We recommend not
        to trust this domain if you are a public cloud provider that
        uses hybrid cloud configurations, or a private cloud provider who does
        not have controls on instance use and allows unrestricted internet access
        to instances. Private cloud providers, however, can use this network as
        an internally trusted network if controls are in place.</para>
    <para>The management security domain is where services interact.
        The networks in this domain transport confidential data such as configuration
        parameters, user names, and passwords. Trust this domain when it is
        behind an organization's firewall in deployments.</para>
    <para>The data security domain is concerned primarily with
        information pertaining to the storage services within
        OpenStack. The data that crosses this network has integrity and
        confidentiality requirements. Depending on the type of deployment there
        may also be availability requirements. The trust level of this network
        is heavily dependent on deployment decisions and does not have a default
        level of trust.</para>
    <para>When operating or utilizing public or private clouds, consider the management
        of the users. The identity service allows for LDAP to be part of the
        authentication process. Including these systems in your
        OpenStack deployments may ease user management if integrating
        into existing systems.</para>
      <warning>
        <para>Be mindful of consistency when utilizing third party
        clouds to explore authentication options.</para>
      </warning>
    <para>Due to the passing of user names, passwords, and tokens between
        client machines and API endpoints, we recommend the placement of API
        services behind hardware to perform SSL termination.</para>
    <para>The hypervisor also requires a security assessment. In a public cloud,
        organizations typically do not have control over the choice of
        hypervisor. For example, Amazon uses its own particular version of Xen.
        Properly securing your hypervisor is important. Attacks made upon the
        unsecured hypervisor are called a "hypervisor breakout".
        Hypervisor breakout describes the event of a
        compromised or malicious instance breaking out of the resource
        controls of the hypervisor and gaining access to the bare
        metal operating system and hardware resources.</para>
    <para>There is not an issue if the security of instances is not important.
        However, enterprises need to avoid vulnerability. The only way to
        do this is to avoid the situation where the instances are running
        on a public cloud. That does not mean that there is a
        need to own all of the infrastructure on which an OpenStack
        installation operates; it suggests avoiding situations in which
        sharing hardware with others occurs.</para>
    <para>There are other services worth considering that provide a
        bare metal instance instead of a cloud. In other cases, it is
        possible to replicate a second private cloud by integrating
        with a private Cloud-as-a-Service deployment. The
        organization does not buy the hardware, but also does not share
        with other tenants. It is also possible to use a provider that
        hosts a bare-metal "public" cloud instance for which the
        hardware is dedicated only to one customer, or a provider that
        offers private Cloud-as-a-Service.</para>
    <para>It is important to realize that each cloud
        implements services differently. What keeps data secure in one
        cloud may not do the same in another. Be sure to know the
        security requirements of every cloud that handles the
        organization's data or workloads.</para>
    <para>More information on OpenStack Security can be found in the
        <link
        xlink:href="http://docs.openstack.org/security-guide"><citetitle>OpenStack
        Security Guide</citetitle></link>.
        </para>
      </section>

    <section xml:id="utilization-hybrid">
      <title>Utilization</title>
    <para>When it comes to utilization, it is important that the CMP
        understands what workloads are running, where they are
        running, and their preferred utilizations. For example, in
        most cases it is desirable to run as many workloads internally
        as possible, utilizing other resources only when necessary. On
        the other hand, situations exist in which the opposite is
        true. The internal cloud may only be for development and
        stressing it is undesirable. In most cases, a cost model of
        various scenarios helps with this decision. However, internal
        priorities influence this analysis. To improve efficiency,
        make these decisions programmatically.</para>
    <para>The Telemetry module (ceilometer)
        provides information on the usage of various OpenStack
        components. There are two limitations to consider:</para>
      <itemizedlist>
        <listitem>
          <para>
          If there is to be a large amount of data (for example, if
        monitoring a large cloud, or a very active one) it is
        desirable to use a NoSQL back end for Ceilometer, such as
        MongoDB.</para>
        </listitem>
        <listitem>
          <para>
          You must monitor connections to non-OpenStack clouds
         and report this information to the CMP.</para>
        </listitem>
      </itemizedlist>
    </section>

    <section xml:id="performance-hybrid">
      <title>Performance</title>
    <para>Performance is of the upmost importance in the design of a
        cloud. When it comes to a hybrid cloud deployment, many of the
        same issues for multi-site deployments apply, such as network
        latency between sites. It is also important to think about the
        speed at which a workload can be spun up in another cloud, and
        how to reduce the time necessary to accomplish the task.
        This may mean moving data closer to applications
        or applications closer to the data they process, including a
        grouping functionality so that connections that
        require low latency take place over a single cloud rather than
        spanning clouds. This may also mean ensuring that the CMP has
        the intelligence to know which cloud can most efficiently run
        which types of workloads.</para>
    <para>As with utilization, native OpenStack tools are available to
        assist. Ceilometer can measure performance and, if necessary,
        the Orchestration (heat) module can
        react to changes in demand by spinning up more resources.</para>
      <note>
        <para>It is important to note, however, that Orchestration requires
        special configurations in the client to enable functioning
        with solution offerings from Amazon Web Services. When dealing
        with other types of clouds, it is necessary to rely on the
        features of the CMP.
        </para>
      </note>
    </section>

    <section xml:id="components">
      <title>Components</title>
    <para>The number and types of native OpenStack components that are
        available for use is dependent on whether the deployment is
        exclusively an OpenStack cloud or not.</para>
    <para>Using more than one cloud in any situation requires
        consideration of four OpenStack tools:</para>
    <itemizedlist>
        <listitem>
            <para>OpenStack Compute (nova): Regardless of deployment
                location, hypervisor choice has a direct effect on how
                difficult it is to integrate with one or more
                additional clouds. For example, integrating a Hyper-V
                based OpenStack cloud with Azure has less
                compatibility issues than if KVM is used.</para>
        </listitem>
        <listitem>
            <para>Networking (neutron): Whether OpenStack Networking
                or legacy networking (nova-network) is used, the network is one place
                where understanding integration capabilities is necessary
                in order to connect between clouds.</para>
        </listitem>
        <listitem>
            <para>Telemetry module (ceilometer): Use of Telemetry
                depends, in large part, on what the other parts of the
                cloud are using.</para>
        </listitem>
        <listitem>
            <para>Orchestration module (heat): Similarly, Orchestration can
                be a valuable tool in orchestrating tasks a CMP
                decides are necessary in an OpenStack-based
                cloud.</para>
        </listitem>
    </itemizedlist>
    </section>

    <section xml:id="special-considerations-hybrid">
      <title>Special considerations</title>
    <para>Hybrid cloud deployments also involve two more issues that
        are not common in other situations:</para>
      <itemizedlist>
        <listitem>
          <para>Image portability: Note that, as of the Kilo release,
        there is no single common image format that is usable by all
        clouds. Conversion or the recreation of images is necessary
        if porting between clouds. To make things simpler,
        launch the smallest and simplest images feasible, installing
        only what is necessary preferably using a deployment manager
        such as Chef or Puppet. Do not use golden images for speeding up
        the process. However, if you repeat the deployment of the same
        images, we recommend utilizing this technique instead of provisioning
        applications on lighter images each time.</para>
        </listitem>
        <listitem>
          <para>API differences: Avoid using a hybrid cloud deployment with more than
        just OpenStack (or with different versions of OpenStack).
        The APIs need to perform certain functions that are different.
        The CMP needs to know how to handle all necessary
        versions. To get around this issue, some implementers build
        portals to achieve a hybrid cloud environment, but a heavily
        developer-focused organization may benefit more from a hybrid
        cloud broker SDK such as jClouds.</para>
        </listitem>
      </itemizedlist>
    </section>
</section>