Synnefo » snf-ganeti » ganeti-local

<!doctype refentry PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [

  <!-- Please adjust the date whenever revising the manpage. -->

  <!ENTITY dhdate      "<date>February 11, 2009</date>">

  <!-- SECTION should be 1-8, maybe w/ subsection other parameters are

       allowed: see man(7), man(1). -->

  <!ENTITY dhsection   "<manvolnum>8</manvolnum>">

  <!ENTITY dhucpackage "<refentrytitle>ganeti-masterd</refentrytitle>">

  <!ENTITY dhpackage   "ganeti-masterd">

  <!ENTITY debian      "<productname>Debian</productname>">

  <!ENTITY gnu         "<acronym>GNU</acronym>">

  <!ENTITY gpl         "&gnu; <acronym>GPL</acronym>">

  <!ENTITY footer SYSTEM "footer.sgml">

]>

<refentry>

  <refentryinfo>

    <copyright>

      <year>2008</year>

      <year>2009</year>

      <holder>Google Inc.</holder>

    </copyright>

    &dhdate;

  </refentryinfo>

  <refmeta>

    &dhucpackage;

    &dhsection;

    <refmiscinfo>ganeti 2.0</refmiscinfo>

  </refmeta>

  <refnamediv>

    <refname>&dhpackage;</refname>

    <refpurpose>ganeti master daemon</refpurpose>

  </refnamediv>

  <refsynopsisdiv>

    <cmdsynopsis>

      <command>&dhpackage; </command>

      <arg>-f</arg>

      <arg>-d</arg>

      <arg>--no-voting</arg>

    </cmdsynopsis>

  </refsynopsisdiv>

  <refsect1>

    <title>DESCRIPTION</title>

    <para>

      The <command>&dhpackage;</command> is the daemon which is

      responsible for the overall cluster coordination. Without it, no

      change can be performed on the cluster.

    </para>

    <para>

      For testing purposes, you can give the <option>-f</option>

      option and the program won't detach from the running terminal.

    </para>

    <para>

      Debug-level message can be activated by giving the

      <option>-d</option> option.

    </para>

    <refsect2>

      <title>ROLE</title>

      <para>

        The role of the master daemon is to coordinate all the actions

        that change the state of the cluster. Things like accepting

        new jobs, coordinating the changes on nodes (via RPC calls to

        the respective node daemons), maintaining the configuration

        and so on are done via this daemon.

      </para>

      <para>

        The only action that can be done without the master daemon is

        the failover of the master role to another node in the

        cluster, via the <command>gnt-cluster masterfailover</command>

        command.

      </para>

      <para>

        If the master daemon is stopped, the instances are not

        affected, but they won't be restarted automatically in case of

        failure.

      </para>

    </refsect2>

    <refsect2>

      <title>STARTUP</title>

      <para>

        At startup, the master daemon will confirm with the node

        daemons that the node it is running is indeed the master node

        of the cluster. It will abort if it doesn't get half plus one

        positive answers (offline nodes are queried too, just in case

        our configuration is stale).

      </para>

      <para>

        For small clusters with a number of nodes down, and especially

        for two-node clusters where the other has gone done, this

        creates a problem. In this case the

        <option>--no-voting</option> option can be used to skip this

        process. The option requires interactive confirmation, as

        having two masters on the same cluster is a very dangerous

        situation and will most likely lead to data loss.

      </para>

    </refsect2>

    <refsect2>

      <title>JOB QUEUE</title>

      <para>

        The master daemon maintains a job queue (located under

        <filename

        class="directory">@LOCALSTATEDIR@/lib/ganeti/queue</filename>) in

        which all current jobs are stored, one job per file serialized

        in JSON format; in this directory a subdirectory called

        <filename class="directory">archive</filename> holds archived

        job files.

      </para>

      <para>

        The moving of jobs from the current to the queue directory is

        done via a request to the master; this can be accomplished

        from the command line with the <command>gnt-job

        archive</command> or <command>gnt-job autoarchive</command>

        commands. In case of problems with the master, a job file can

        simply be moved away or deleted (but this might leave the

        cluster inconsistent).

      </para>

    </refsect2>

    <refsect2>

      <title>COMMUNICATION PROTOCOL</title>

      <para>

        The master accepts commands over a Unix socket, using JSON

        serialized messages separated by a specific byte sequence. For

        more details, see the design documentation supplied with

        Ganeti.

      </para>

    </refsect2>

  </refsect1>

  &footer;

</refentry>

<!-- Keep this comment at the end of the file

Local variables:

mode: sgml

sgml-omittag:t

sgml-shorttag:t

sgml-minimize-attributes:nil

sgml-always-quote-attributes:t

sgml-indent-step:2

sgml-indent-data:t

sgml-parent-document:nil

sgml-default-dtd-file:nil

sgml-exposed-tags:nil

sgml-local-catalogs:nil

sgml-local-ecat-files:nil

End:

-->