コンテナの最大ダウンタイムを削減したいと考えています。 これをどのように行うことができますか？
回答：VEのタスクによっては、まったくアイドル状態にならない場合があります。
例えば、私はservice.srv.myにWebサービス（LNAMP）を持ち、アクセス数の多いサイトとフィラーエディターのグループを持っています。 彼らは「記録にある」サイトにアクセスできます。 一般に、これは移動に気付くサービスユーザーの唯一のカテゴリです。 わかった 始めましょう。
vzmigrateユーティリティを使用します。
1. sshd構成のnode2.srv.myサーバーで、rootユーザーのアクセスを一時的に有効にします。
PermitRootLogin yes-node2.srv.myで実行されます
2. node1.srv.myにキーを作成します。
ssh-keygen -t rsa -b 4096-node1.srv.myで実行
空のパスワードを選択します。これにより、キーで入力するときに、まだパスワードとパスワードを求められません。
3. node2.srv.myにキーを配置します。
ssh-copy-id -i〜/ .ssh / id_rsa.pub root@node2.srv.my-node1.srv.myで実行
検証のために、ルートnode2.srv.myパスワードの入力を求められます。
4. IPアドレスが変更された場合、service.srv.myゾーンのDNSを更新します。 （この場合、TTLを15分に減らすことをお勧めします。）
5.次に、大胆に移行を開始します。
vzmigrate -v --remove-area no --online --rsync = "-v" host_target_ip veid_service.srv.my-node1.srv.myで実行
ネットワークのサイズと速度によっては、ノード間で時間がかかる場合があります。 切断される可能性がある場合は、画面を使用する価値があります。
--onlineを使用すると、service.srv.myサービスの提供を停止せずに移動できます
--rsync = "-v"-rsyncパラメーター。ここでは、転送されるファイルを表示するかどうか、ファイルの進行状況を表示するかどうかを構成できます。
--remove-area noを指定すると、転送の成功に関係なくファイルを保存できます。 驚いたことに、これでもVEの停止を防ぐことはできませんでした。 おそらく何も読んでいませんでした。移行をすばやくキャンセルできるようにする必要がある場合は、-remove-area noを選択し、config veid.conf.migratedの名前をveid.confに変更します。 ファイルを削除する必要がある場合は、yesを設定します。
host_target_ip-node2.srv.myの IPアドレス
veid_service.srv.my-サービスのVEID。たとえば、301。
iptablesの設定が異なるために問題が発生することがあります（http://phpsuxx.blogspot.com/2010/08/openvz-error-most-probably-some.html）
6. node2.srv.myのvzlistは、コンテナ301がここで動作していることを示し、node1.srv.meのvzlistは、コンテナがもう存在しないことを示します（ただし、念のためファイルを保存しました）
7. IP service.srv.myを変更する必要がある場合があります。 この場合、構成でIPを変更し、VEを再起動します（vzctl restart 301）。 または、-ipdelおよび--ipdelを使用してIPアドレスを変更します。
動きは終わりました
人々は、移動してもネットワークが失われないことを書きます。たとえば、VEからのデータのバックアップは、移動時にバックアップサーバーにマージされ、ノード間をスムーズに切り替えられます。 しかし、チェックしませんでした。
長い間、habrに書き込みませんでした 次に、この状況を修正します。