debootstrap
node1#
-Running a burnin
-----------------
+Running a burn-in
+-----------------
Now that the cluster is created, it is time to check that the hardware
works correctly, that the hypervisor can actually create instances,
…
node1#
-You can see in the above what operations the burnin does. Ideally, the
-burnin log would proceed successfully through all the steps and end
+You can see in the above what operations the burn-in does. Ideally, the
+burn-in log would proceed successfully through all the steps and end
cleanly, without throwing errors.
Instance operations
- initrd_path: default ()
Hardware:
- VCPUs: 1
- - memory: 128MiB
+ - maxmem: 256MiB
+ - minmem: 512MiB
- NICs:
- nic/0: MAC: aa:00:00:78:da:63, IP: None, mode: bridged, link: xen-br0
Disks:
Mon Oct 26 05:27:39 2009 - INFO: Readding a node, the offline/drained flags were reset
Mon Oct 26 05:27:39 2009 - INFO: Node will be a master candidate
-And is now working again::
+And it is now working again::
node1# gnt-node list
Node DTotal DFree MTotal MNode MFree Pinst Sinst
node2 1.3T 1.3T 32.0G 1.0G 30.4G 1 3
node3 1.3T 1.3T 32.0G 1.0G 30.4G 0 0
-.. note:: If you have the ganeti-htools package installed, you can
- shuffle the instances around to have a better use of the nodes.
+.. note:: If Ganeti has been built with the htools
+ component enabled, you can shuffle the instances around to have a
+ better use of the nodes.
Disk failures
+++++++++++++
As you can see, *instance4* has a copy running on node3, because we
forced the failover when node3 failed. This case is dangerous as the
-instance will have the same IP and MAC address, wreaking havok on the
+instance will have the same IP and MAC address, wreaking havoc on the
network environment and anyone who tries to use it.
Ganeti doesn't directly handle this case. It is recommended to logon to
node1# gnt-instance modify -B memory=4G instance1
Modified instance instance1
- - be/memory -> 4096
+ - be/maxmem -> 4096
+ - be/minmem -> 4096
Please don't forget that these parameters take effect only at the next start of the instance.
node1# gnt-instance modify …
Mon Oct 26 18:59:37 2009 * Verifying orphan volumes
Mon Oct 26 18:59:37 2009 * Verifying remaining instances
Mon Oct 26 18:59:37 2009 * Verifying N+1 Memory redundancy
- Mon Oct 26 18:59:37 2009 - ERROR: node node2: not enough memory on to accommodate failovers should peer node node1 fail
+ Mon Oct 26 18:59:37 2009 - ERROR: node node2: not enough memory to accommodate instance failovers should node node1 fail
Mon Oct 26 18:59:37 2009 * Other Notes
Mon Oct 26 18:59:37 2009 * Hooks Results
node1#
- try to manually move instances around (but this can become complicated
for any non-trivial cluster)
-- try to reduce memory of some instances to accommodate the available
- node memory
-- if you have the ganeti-htools package installed, you can run the
- ``hbal`` tool which will try to compute an automated cluster solution
- that complies with the N+1 rule
+- try to reduce the minimum memory of some instances on the source node
+ of the N+1 failure (in the example above ``node1``): this will allow
+ it to start and be failed over/migrated with less than its maximum
+ memory
+- try to reduce the runtime/maximum memory of some instances on the
+ destination node of the N+1 failure (in the example above ``node2``)
+ to create additional available node memory (check the :doc:`admin`
+ guide for what Ganeti will and won't automatically do in regards to
+ instance runtime memory modification)
+- if Ganeti has been built with the htools package enabled, you can run
+ the ``hbal`` tool which will try to compute an automated cluster
+ solution that complies with the N+1 rule
Network issues
++++++++++++++
from the above that instance2 has /dev/drbd0, instance3 /dev/drbd1, and
instance4 /dev/drbd2.
+LUXI version mismatch
++++++++++++++++++++++
+
+LUXI is the protocol used for communication between clients and the
+master daemon. Starting in Ganeti 2.3, the peers exchange their version
+in each message. When they don't match, an error is raised::
+
+ $ gnt-node modify -O yes node3
+ Unhandled Ganeti error: LUXI version mismatch, server 2020000, request 2030000
+
+Usually this means that server and client are from different Ganeti
+versions or import their libraries from different, consistent paths
+(e.g. an older version installed in another place). You can print the
+import path for Ganeti's modules using the following command (note that
+depending on your setup you might have to use an explicit version in the
+Python command, e.g. ``python2.6``)::
+
+ python -c 'import ganeti; print ganeti.__file__'
+
.. vim: set textwidth=72 :
.. Local Variables:
.. mode: rst
projects / ganeti-local / blobdiff