Revision edd28bbf docs/admin-guide.rst
b/docs/admin-guide.rst | ||
---|---|---|
517 | 517 |
allocator. The VM is "pinned" to this backend, and can not change through its |
518 | 518 |
lifetime. The backend allocator decides in which backend to spawn the VM based |
519 | 519 |
on the available resources of each backend, trying to balance the load between |
520 |
them. |
|
520 |
them. Also, Networks are created to all Ganeti backends, in order to ensure |
|
521 |
that VMs residing on different backends can be connected to the same networks. |
|
521 | 522 |
|
522 |
Handling of Networks, as far as backends are concerned, is based on whether the |
|
523 |
network is public or not. Public networks are created through the `snf-manage |
|
524 |
network-create` command, and are only created on one backend. Private networks |
|
525 |
are created on all backends, in order to ensure that VMs residing on different |
|
526 |
backends can be connected to the same private network. |
|
523 |
A backend can be marked as `drained` in order to be excluded from automatic |
|
524 |
servers allocation and not receive new servers. Also, a backend can be marked |
|
525 |
as `offline` to denote that the backend is not healthy (e.g. broken master) |
|
526 |
and avoid the penalty of connection timeouts. |
|
527 |
|
|
528 |
Finally, Cyclades is able to manage Ganeti backends with different enabled |
|
529 |
hypervisors (`kvm`, `xen`), and different enabled disk templates. |
|
527 | 530 |
|
528 | 531 |
Listing existing backends |
529 | 532 |
````````````````````````` |
... | ... | |
552 | 555 |
backend attributes can be also changed dynamically using the `snf-manage |
553 | 556 |
backend-modify` command. |
554 | 557 |
|
555 |
``snf-manage backend-add`` will also create all existing private networks to
|
|
558 |
``snf-manage backend-add`` will also create all existing public networks to
|
|
556 | 559 |
the new backend. You can verify that the backend is added, by running |
557 | 560 |
`snf-manage backend-list`. |
558 | 561 |
|
559 | 562 |
Note that no VMs will be spawned to this backend, since by default it is in a |
560 |
``drained`` state after addition and also it has no public network assigned to
|
|
561 |
it.
|
|
563 |
``drained`` state after addition in order to manually verify the state of the
|
|
564 |
backend.
|
|
562 | 565 |
|
563 |
So, first you need to create its public network, make sure everything works as |
|
564 |
expected and finally make it active by un-setting the ``drained`` flag. You can |
|
565 |
do this by running: |
|
566 |
So, after making sure everything works as expected, make the new backend active |
|
567 |
by un-setting the ``drained`` flag. You can do this by running: |
|
566 | 568 |
|
567 | 569 |
.. code-block:: console |
568 | 570 |
|
569 | 571 |
$ snf-manage backend-modify --drained=False <backend_id> |
570 | 572 |
|
571 |
Removing an existing Ganeti backend |
|
572 |
``````````````````````````````````` |
|
573 |
In order to remove an existing backend from Synnefo, we run: |
|
574 |
|
|
575 |
.. code-block:: console |
|
576 |
|
|
577 |
# snf-manage backend-remove <backend_id> |
|
578 |
|
|
579 |
This command will fail if there are active VMs on the backend. Also, the |
|
580 |
backend is not cleaned before removal, so all the Synnefo private networks |
|
581 |
will be left on the Ganeti nodes. You need to remove them manually. |
|
582 |
|
|
583 | 573 |
Allocation of VMs in Ganeti backends |
584 | 574 |
```````````````````````````````````` |
585 | 575 |
As already mentioned, the Cyclades backend allocator is responsible for |
... | ... | |
597 | 587 |
$ snf-manage backend-modify --drained=True <backend_id> |
598 | 588 |
|
599 | 589 |
The backend resources are periodically updated, at a period defined by |
600 |
the ``BACKEND_REFRESH_MIN`` setting, or by running `snf-manage backend-update-status`
|
|
601 |
command. It is advised to have a cron job running this command at a smaller
|
|
602 |
interval than ``BACKEND_REFRESH_MIN`` in order to remove the load of refreshing
|
|
603 |
the backends stats from the VM creation phase. |
|
590 |
the ``BACKEND_REFRESH_MIN`` setting, or by running `snf-manage |
|
591 |
backend-update-status` command. It is advised to have a cron job running this
|
|
592 |
command at a smaller interval than ``BACKEND_REFRESH_MIN`` in order to remove
|
|
593 |
the load of refreshing the backends stats from the VM creation phase.
|
|
604 | 594 |
|
605 | 595 |
Finally, the admin can decide to have a user's VMs being allocated to a |
606 | 596 |
specific backend, with the ``BACKEND_PER_USER`` setting. This is a mapping |
... | ... | |
634 | 624 |
nodes of the same Ganeti backend, by modifying the same options at the |
635 | 625 |
nodegroup level (see `gnt-group` manpage for mor details). |
636 | 626 |
|
627 |
Removing an existing Ganeti backend |
|
628 |
``````````````````````````````````` |
|
629 |
In order to remove an existing backend from Synnefo, you must first make |
|
630 |
sure that there are not active servers in the backend, and then run: |
|
631 |
|
|
632 |
.. code-block:: console |
|
633 |
|
|
634 |
# snf-manage backend-remove <backend_id> |
|
635 |
|
|
636 |
|
|
637 | 637 |
|
638 | 638 |
Managing Virtual Machines |
639 | 639 |
~~~~~~~~~~~~~~~~~~~~~~~~~ |
Also available in: Unified diff