root / README.admin @ 3a4e3bac
History | View | Annotate | Download (2.8 kB)
1 |
README.admin - Administration notes |
---|---|
2 |
|
3 |
This file contains notes related to administration of a working Synnefo |
4 |
deployment. This document should be read *after* README.deploy, which contains |
5 |
step-by-step Synnefo deployment instructions. |
6 |
|
7 |
|
8 |
Reconciliation mechanism |
9 |
======================== |
10 |
|
11 |
On certain occasions, such as a Ganeti or RabbitMQ failure, the VM state in the |
12 |
system's database may differ from that in the Ganeti installation. The |
13 |
reconciliation process is designed to bring the system's database in sync with |
14 |
what Ganeti knows about each VM. |
15 |
|
16 |
The administrator can trigger reconciliation manually, by issuing a Ganeti |
17 |
OP_INSTANCE_QUERY_DATA command, using gnt-instance info. |
18 |
|
19 |
Alternatively, the reconciliation process can be triggered for all VMs using the |
20 |
command |
21 |
|
22 |
./manage.py reconcile --all |
23 |
|
24 |
It is advised, though not strictly necessary, to run the reconciliation process |
25 |
periodically, through cron. To avoid overloading the Ganeti master, the periodic |
26 |
reconciliation process takes a staggered approach to updating the VMs, which is |
27 |
configured through the following parameters: |
28 |
|
29 |
* The settings.py RECONCILIATION_MIN parameter, which specifies the maximum time |
30 |
a VM can remain ``non-reconciled''. (default: 30 mins) |
31 |
|
32 |
* The --interval option to the reconcile command, which declares the interval |
33 |
time between reconciliation attempts (default: 1 min) |
34 |
|
35 |
On each invocation of the reconcile command, the system will trigger a |
36 |
reconciliation for ((num_all_vms/RECONCILIATION_MIN) * interval) machines. |
37 |
Obviously the lower the interval value and the higher the setting of |
38 |
RECONCILIATION_MIN, the less load is going to be put on Ganeti. |
39 |
|
40 |
Logging |
41 |
======= |
42 |
|
43 |
Logging in Synnefo is using Python's logging module. The module is configured |
44 |
using a configuration file, whose format is described here: |
45 |
|
46 |
http://docs.python.org/library/logging.config.html |
47 |
|
48 |
By default, the log initialization code will look for the logging.conf file |
49 |
in the following locations in order: |
50 |
|
51 |
1. /etc/synnefo/logging.conf |
52 |
2. os.getcwd()/logging.conf |
53 |
3. synnefo.logic.__path__[0]/logging.conf (<-- this is the default) |
54 |
|
55 |
The default configuration is using Linux conventions: it logs to /dev/log for |
56 |
all loggers. The default configuration can be changed by copying the default |
57 |
file to any of the above mentioned locations and changing it appropriately. |
58 |
|
59 |
* Logging and demonization: If the logging is configured to print to the console |
60 |
(using the consoleHandler handler) then daemon processes (notably, the |
61 |
dispatcher) will not work as it should. This only happens after the daemon |
62 |
has lost its controlling terminal (e.g. because the terminal was closed); |
63 |
in this case the dispatcher does not know where to log to and depending on |
64 |
the system it either crashes or stalls. This can be avoided if the logging |
65 |
module is not configured to output to the console. |