Revision 36e23a40 doc/admin.sgml
| b/doc/admin.sgml | ||
|---|---|---|
| 4 | 4 |
<articleinfo> |
| 5 | 5 |
<title>Ganeti administrator's guide</title> |
| 6 | 6 |
</articleinfo> |
| 7 |
<para>Documents Ganeti version 1.3</para>
|
|
| 7 |
<para>Documents Ganeti version 2.0</para>
|
|
| 8 | 8 |
<sect1> |
| 9 | 9 |
<title>Introduction</title> |
| 10 | 10 |
|
| 11 |
<para>Ganeti is a virtualization cluster management software. You are |
|
| 12 |
expected to be a system administrator familiar with your Linux distribution |
|
| 13 |
and the Xen virtualization environment before using it. |
|
| 11 |
<para> |
|
| 12 |
Ganeti is a virtualization cluster management software. You are |
|
| 13 |
expected to be a system administrator familiar with your Linux |
|
| 14 |
distribution and the Xen or KVM virtualization environments |
|
| 15 |
before using it. |
|
| 14 | 16 |
</para> |
| 15 | 17 |
|
| 16 |
<para>The various components of Ganeti all have man pages and interactive |
|
| 17 |
help. This manual though will help you getting familiar with the system by |
|
| 18 |
explaining the most common operations, grouped by related use. |
|
| 18 |
<para> |
|
| 19 |
The various components of Ganeti all have man pages and |
|
| 20 |
interactive help. This manual though will help you getting |
|
| 21 |
familiar with the system by explaining the most common |
|
| 22 |
operations, grouped by related use. |
|
| 19 | 23 |
</para> |
| 20 | 24 |
|
| 21 |
<para>After a terminology glossary and a section on the prerequisites |
|
| 22 |
needed to use this manual, the rest of this document is divided in three |
|
| 23 |
main sections, which group different features of Ganeti: |
|
| 25 |
<para> |
|
| 26 |
After a terminology glossary and a section on the prerequisites |
|
| 27 |
needed to use this manual, the rest of this document is divided |
|
| 28 |
in three main sections, which group different features of |
|
| 29 |
Ganeti: |
|
| 24 | 30 |
<itemizedlist> |
| 25 | 31 |
<listitem> |
| 26 | 32 |
<simpara>Instance Management</simpara> |
| ... | ... | |
| 122 | 128 |
Adding a new virtual instance to your Ganeti cluster is really easy. |
| 123 | 129 |
The command is: |
| 124 | 130 |
|
| 125 |
<synopsis>gnt-instance add -n <replaceable>TARGET_NODE</replaceable> -o <replaceable>OS_TYPE</replaceable> -t <replaceable>DISK_TEMPLATE</replaceable> <replaceable>INSTANCE_NAME</replaceable></synopsis> |
|
| 131 |
<synopsis>gnt-instance add -n <replaceable>TARGET_NODE<optional>:SECONDARY_NODE</optional></replaceable> -o <replaceable>OS_TYPE</replaceable> -t <replaceable>DISK_TEMPLATE</replaceable> <replaceable>INSTANCE_NAME</replaceable></synopsis>
|
|
| 126 | 132 |
|
| 127 | 133 |
The instance name must be resolvable (e.g. exist in DNS) and |
| 128 |
of course map to an address in the same subnet as the cluster
|
|
| 134 |
usually to an address in the same subnet as the cluster
|
|
| 129 | 135 |
itself. Options you can give to this command include: |
| 130 | 136 |
|
| 131 | 137 |
<itemizedlist> |
| 132 | 138 |
<listitem> |
| 133 |
<simpara>The disk size (<option>-s</option>)</simpara> |
|
| 139 |
<simpara>The disk size (<option>-s</option>) for a |
|
| 140 |
single-disk instance, or multiple <option>--disk |
|
| 141 |
<replaceable>N</replaceable>:size=<replaceable>SIZE</replaceable></option> |
|
| 142 |
options for multi-instance disks</simpara> |
|
| 134 | 143 |
</listitem> |
| 135 | 144 |
<listitem> |
| 136 |
<simpara>The swap size (<option>--swap-size</option>)</simpara>
|
|
| 145 |
<simpara>The memory size (<option>-B memory</option>)</simpara>
|
|
| 137 | 146 |
</listitem> |
| 138 | 147 |
<listitem> |
| 139 |
<simpara>The memory size (<option>-m</option>)</simpara>
|
|
| 148 |
<simpara>The number of virtual CPUs (<option>-B vcpus</option>)</simpara>
|
|
| 140 | 149 |
</listitem> |
| 141 | 150 |
<listitem> |
| 142 |
<simpara>The number of virtual CPUs (<option>-p</option>)</simpara> |
|
| 143 |
</listitem> |
|
| 144 |
<listitem> |
|
| 145 |
<simpara>The instance ip address (<option>-i</option>) (use the value |
|
| 146 |
<literal>auto</literal> to make Ganeti record the address from |
|
| 147 |
dns)</simpara> |
|
| 148 |
</listitem> |
|
| 149 |
<listitem> |
|
| 150 |
<simpara>The bridge to connect the instance to (<option>-b</option>), |
|
| 151 |
if you don't want to use the default one</simpara> |
|
| 151 |
<para> |
|
| 152 |
Arguments for the NICs of the instance; by default, a |
|
| 153 |
single-NIC instance is created. The IP and/or bridge of |
|
| 154 |
the NIC can be changed via <option>--nic |
|
| 155 |
0:ip=<replaceable>IP</replaceable>,bridge=<replaceable>BRIDGE</replaceable></option> |
|
| 156 |
</para> |
|
| 152 | 157 |
</listitem> |
| 153 | 158 |
</itemizedlist> |
| 154 | 159 |
</para> |
| ... | ... | |
| 165 | 170 |
</varlistentry> |
| 166 | 171 |
|
| 167 | 172 |
<varlistentry> |
| 173 |
<term>file</term> |
|
| 174 |
<listitem> |
|
| 175 |
<para>The instance will use plain files as backend for its |
|
| 176 |
disks. No redundancy is provided, and this is somewhat |
|
| 177 |
more difficult to configure for high performance.</para> |
|
| 178 |
</listitem> |
|
| 179 |
</varlistentry> |
|
| 180 |
|
|
| 181 |
<varlistentry> |
|
| 168 | 182 |
<term>plain</term> |
| 169 | 183 |
<listitem> |
| 170 | 184 |
<para>The instance will use LVM devices as backend for its disks. |
| ... | ... | |
| 200 | 214 |
</para> |
| 201 | 215 |
|
| 202 | 216 |
<para> |
| 203 |
Removing an instance is even easier than creating one. This operation
|
|
| 204 |
is non-reversible and destroys all the contents of your instance. Use
|
|
| 205 |
with care: |
|
| 217 |
Removing an instance is even easier than creating one. This |
|
| 218 |
operation is irrereversible and destroys all the contents of
|
|
| 219 |
your instance. Use with care:
|
|
| 206 | 220 |
|
| 207 | 221 |
<synopsis>gnt-instance remove <replaceable>INSTANCE_NAME</replaceable></synopsis> |
| 208 | 222 |
</para> |
| ... | ... | |
| 296 | 310 |
</sect2> |
| 297 | 311 |
|
| 298 | 312 |
<sect2> |
| 313 |
<title>Live migrating an instance</title> |
|
| 314 |
|
|
| 315 |
<para> |
|
| 316 |
If an instance is built in highly available mode, it currently |
|
| 317 |
runs and both its nodes are running fine, you can at migrate |
|
| 318 |
it over to its secondary node, without dowtime. On the master |
|
| 319 |
node you need to run: |
|
| 320 |
|
|
| 321 |
<synopsis>gnt-instance migrate <replaceable>INSTANCE_NAME</replaceable></synopsis> |
|
| 322 |
|
|
| 323 |
</para> |
|
| 324 |
</sect2> |
|
| 325 |
|
|
| 326 |
|
|
| 327 |
<sect2> |
|
| 299 | 328 |
<title>Replacing an instance disks</title> |
| 300 | 329 |
|
| 301 | 330 |
<para> |
| ... | ... | |
| 304 | 333 |
you failed over all its instances, but it's still secondary |
| 305 | 334 |
for some? The solution here is to replace the instance disks, |
| 306 | 335 |
changing the secondary node: |
| 307 |
<synopsis>gnt-instance replace-disks <option>-s</option> <option>--new-secondary <replaceable>NODE</replaceable></option> <replaceable>INSTANCE_NAME</replaceable></synopsis>
|
|
| 336 |
<synopsis>gnt-instance replace-disks <option>-n <replaceable>NODE</replaceable></option> <replaceable>INSTANCE_NAME</replaceable></synopsis>
|
|
| 308 | 337 |
|
| 309 | 338 |
This process is a bit long, but involves no instance |
| 310 | 339 |
downtime, and at the end of it the instance has changed its |
| 311 | 340 |
secondary node, to which it can if necessary be failed over. |
| 312 | 341 |
</para> |
| 313 | 342 |
</sect2> |
| 343 |
|
|
| 314 | 344 |
<sect2> |
| 315 | 345 |
<title>Failing over the master node</title> |
| 316 | 346 |
|
| ... | ... | |
| 408 | 438 |
gnt-cluster command |
| 409 | 439 |
gnt-cluster copyfile |
| 410 | 440 |
gnt-cluster verify |
| 441 |
gnt-cluster verify-disks |
|
| 411 | 442 |
gnt-cluster getmaster |
| 412 | 443 |
gnt-cluster version |
| 413 | 444 |
</screen> |
Also available in: Unified diff