openstack-manuals/doc/common/section_getstart_compute.xml

<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="compute-service">
      <title>Compute Service</title>
      <para>The Compute Service is a cloud computing fabric
        controller, the main part of an IaaS system. It can be used
        for hosting and managing cloud computing systems. The main
        modules are implemented in Python.</para>
      <para>The Compute Service is made up of the following functional
        areas and their underlying components:</para>
      <itemizedlist>
        <title>API</title>
        <listitem>
          <para><systemitem class="service">nova-api</systemitem>
            service. Accepts and responds to end user compute API
            calls. Supports the OpenStack Compute API, the Amazon EC2
            API, and a special Admin API for privileged users to
            perform administrative actions. Also, initiates most
            orchestration activities, such as running an instance, and
            enforces some policies.</para>
        </listitem>
        <listitem>
          <para><systemitem class="service"
              >nova-api-metadata</systemitem> service. Accepts
            metadata requests from instances. The <systemitem
              class="service">nova-api-metadata</systemitem> service
            is generally only used when you run in multi-host mode
            with <systemitem class="service">nova-network</systemitem>
            installations. For details, see <link
            xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_metadata-service.html"
            >Metadata service</link> in the <citetitle>Cloud Administrator Guide</citetitle>.</para>
        </listitem>
      </itemizedlist>
      <itemizedlist>
        <title>Compute core</title>
        <listitem>
          <para><systemitem class="service">nova-compute</systemitem>
            process. A worker daemon that creates and terminates
            virtual machine instances through hypervisor APIs. For
            example, XenAPI for XenServer/XCP, libvirt for KVM or
            QEMU, VMwareAPI for VMware, and so on. The process by
            which it does so is fairly complex but the basics are
            simple: Accept actions from the queue and perform a series
            of system commands, like launching a KVM instance, to
            carry them out while updating state in the
            database.</para>
        </listitem>
        <listitem>
          <para><systemitem class="service"
              >nova-scheduler</systemitem> process. Conceptually the
            simplest piece of code in Compute. Takes a virtual machine
            instance request from the queue and determines on which
            compute server host it should run.</para>
        </listitem>
        <listitem>
          <para><systemitem class="service"
              >nova-conductor</systemitem> module. Mediates
            interactions between <systemitem class="service"
              >nova-compute</systemitem> and the database. Aims to
            eliminate direct accesses to the cloud database made by
              <systemitem class="service">nova-compute</systemitem>.
            The <systemitem class="service"
              >nova-conductor</systemitem> module scales horizontally.
            However, do not deploy it on any nodes where <systemitem
              class="service">nova-compute</systemitem> runs. For more
            information, see <link
              xlink:href="http://russellbryantnet.wordpress.com/2012/11/19/a-new-nova-service-nova-conductor/"
              >A new Nova service: nova-conductor</link>.</para>
        </listitem>
      </itemizedlist>
      <itemizedlist>
        <title>Networking for VMs</title>
        <listitem>
          <para><systemitem class="service">nova-network</systemitem>
            worker daemon. Similar to <systemitem class="service"
              >nova-compute</systemitem>, it accepts networking tasks
            from the queue and performs tasks to manipulate the
            network, such as setting up bridging interfaces or
            changing iptables rules. This functionality is being
            migrated to OpenStack Networking, which is a separate
            OpenStack service.</para>
        </listitem>
        <listitem>
          <para><systemitem class="service"
              >nova-dhcpbridge</systemitem> script. Tracks IP address
            leases and records them in the database by using the
            dnsmasq <literal>dhcp-script</literal> facility. This
            functionality is being migrated to OpenStack Networking.
            OpenStack Networking provides a different script.</para>
        </listitem>
      </itemizedlist>
      <?hard-pagebreak?>
      <itemizedlist>
        <title>Console interface</title>
        <listitem>
          <para><systemitem class="service"
              >nova-consoleauth</systemitem> daemon. Authorizes tokens
            for users that console proxies provide. See <systemitem
              class="service">nova-novncproxy</systemitem> and
              <systemitem class="service"
              >nova-xvpnvcproxy</systemitem>. This service must be
            running for console proxies to work. Many proxies of
            either type can be run against a single <systemitem
              class="service">nova-consoleauth</systemitem> service in
            a cluster configuration. For information, see <link
 xlink:href="http://docs.openstack.org/trunk/config-reference/content/about-nova-consoleauth.html"
              >About nova-consoleauth</link>.</para>
        </listitem>
        <listitem>
          <para><systemitem class="service"
              >nova-novncproxy</systemitem> daemon. Provides a proxy
            for accessing running instances through a VNC connection.
            Supports browser-based novnc clients.</para>
        </listitem>
        <listitem>
          <para><systemitem class="service">nova-console</systemitem>
            daemon. Deprecated for use with Grizzly. Instead, the
              <systemitem class="service"
              >nova-xvpnvncproxy</systemitem> is used.</para>
        </listitem>
        <listitem>
          <para><systemitem class="service"
              >nova-xvpnvncproxy</systemitem> daemon. A proxy for
            accessing running instances through a VNC connection.
            Supports a Java client specifically designed for
            OpenStack.</para>
        </listitem>
        <listitem>
          <para><systemitem class="service">nova-cert</systemitem>
            daemon. Manages x509 certificates.</para>
        </listitem>
      </itemizedlist>
      <itemizedlist>
        <title>Image Management (EC2 scenario)</title>
        <listitem>
          <para><systemitem class="service"
              >nova-objectstore</systemitem> daemon. Provides an S3
            interface for registering images with the Image Service.
            Mainly used for installations that must support euca2ools.
            The euca2ools tools talk to <systemitem class="service"
              >nova-objectstore</systemitem> in <emphasis
              role="italic">S3 language</emphasis>, and <systemitem
              class="service">nova-objectstore</systemitem> translates
            S3 requests into Image Service requests.</para>
        </listitem>
        <listitem>
          <para>euca2ools client. A set of command-line interpreter
            commands for managing cloud resources. Though not an
            OpenStack module, you can configure <systemitem
              class="service">nova-api</systemitem> to support this
            EC2 interface. For more information, see the <link
              xlink:href="http://www.eucalyptus.com/eucalyptus-cloud/documentation/2.0"
              >Eucalyptus 2.0 Documentation</link>.</para>
        </listitem>
      </itemizedlist>
      <itemizedlist>
        <title>Command Line Interpreter/Interfaces</title>
        <listitem>
          <para>nova client. Enables users to submit commands as a
            tenant administrator or end user.</para>
        </listitem>
        <listitem>
          <para>nova-manage client. Enables cloud administrators to
            submit commands.</para>
        </listitem>
      </itemizedlist>
      <itemizedlist>
        <title>Other components</title>
        <listitem>
          <para>The queue. A central hub for passing messages between
            daemons. Usually implemented with <link
              xlink:href="http://www.rabbitmq.com/">RabbitMQ</link>,
            but could be any AMPQ message queue, such as <link
              xlink:href="http://qpid.apache.org/">Apache Qpid</link>)
            or <link xlink:href="http://www.zeromq.org/">Zero
              MQ</link>.</para>
        </listitem>
        <listitem>
          <para>SQL database. Stores most build-time and runtime
            states for a cloud infrastructure. Includes instance types
            that are available for use, instances in use, available
            networks, and projects. Theoretically, OpenStack Compute
            can support any database that SQL-Alchemy supports, but
            the only databases widely used are sqlite3 databases
            (only appropriate for test and development work), MySQL,
            and PostgreSQL.</para>
        </listitem>
      </itemizedlist>
      <para>The Compute Service interacts with other OpenStack
        services: Identity Service for authentication, Image Service
        for images, and the OpenStack Dashboard for a web
        interface.</para>
</section>