Walkthrough of OpenVZ Live Migration

    We have 2 HN: node1.srv.my and node2.srv.my. On node1.srv.my, we are spinning a container (service.srv.my), which has outgrown the old node and wants further growth.

    It is advisable for us to reduce the maximum downtime of the container. How can this be done?
    Answer: depending on the tasks of VE, it may not be idle at all.
    Openvz_logo

    For example, I have a web service (LNAMP) on service.srv.my with a highly visited site and a group of filler editors. They have access to the site “on record”. In general, this is the only category of service users who will notice a move. Okay. Let's get started.

    We will use the vzmigrate utility.
    1. Temporarily enable root user access on the node2.srv.my server in the sshd config:
    PermitRootLogin yes- it is executed on node2.srv.my

    2. We create keys on node1.srv.my:
    ssh-keygen -t rsa -b 4096 - it is executed on node1.srv.my

    We select an empty password so that we will not be asked for a password when entering via the key.
    3. Put the key in node2.srv.my:
    ssh-copy-id -i ~ / .ssh / id_rsa.pub root@node2.srv.my - runs on node1.srv.my

    They will ask you to enter the root password node2.srv.my for validation.
    4. Update the DNS for the service.srv.my zone if the IP address changes. (In this case, it is better to reduce the TTL - minutes to 15.)

    5. Now we can safely start the migration:
    vzmigrate -v --remove-area no --online --rsync = "- v" host_target_ip veid_service.srv.my - runs on node1 .srv.my

    Depending on the size and speed of the network, it may take a long time between nodes. It may be worth using screen if disconnects are likely.
    --online will allow you to move without ceasing to provide service.srv.my services
    --rsync = "- v" - rsync parameters, here you can configure whether to show files that will be transferred, whether to show the progress of files.
    --remove-area no allows you to save files regardless of the success of the transfer. To my surprise, this still did not prevent VE from stopping. Probably didn’t read something. If you need to be able to quickly cancel the migration, select –remove-area no and rename the veid.conf.migrated config to veid.conf. If you need to delete files, set yes.
    host_target_ip- IP address node2.srv.my
    veid_service.srv.my - VEID of the service, for example, 301 for me.

    Sometimes problems arise due to different iptables settings (http://phpsuxx.blogspot.com/2010/08/openvz-error-most-probably-some.html)

    6. vzlist on node2.srv.my shows that container 301 now it works here, on node1.srv.me vzlist will show that the container is already gone (but we saved the files just in case)

    7. We may need to change the IP service.srv.my. In this case, change the IP in the config and restart VE (vzctl restart 301). Or, by changing the IP address by using --ipdel and --ipdel.

    The move is over
    People write that when moving, the network is not lost: for example, a backup of data from VE could merge onto the backup server when moving, smoothly switching from one node to another. But did not check.
    migration

    For a long time did not write on a habr Now I will correct this situation.

    Also popular now: