人生で少なくとも一度は、完全な KVM 仮想化を備えたサーバーに OpenVZ コンテナを転送する必要がある人は、次のような問題に遭遇したことがあります。
- 情報のほとんどは単純に古く、EOL サイクルをとうに過ぎた OS に関連するものでした。
- オペレーティング システムごとに異なる情報が常に提供され、移行中に発生する可能性のあるエラーは考慮されません。
- 場合によっては、移行後に機能しない構成に対処する必要がある場合があります。
1 つのサーバーを転送する場合は、いつでもその場で何かを修正できますが、クラスター全体を転送する場合はどうでしょうか。
この記事では、最小限のダウンタイムで OpenVZ コンテナを KVM に正しく移行し、すべての問題を迅速に解決する方法を説明します。
小さな教育プログラム: OpenVZ と KVM とは何ですか?
専門用語については深く立ち入りませんが、一般的に次のように言います。
OpenVZ — オペレーティング システム レベルでの仮想化では、ホスト マシン上で CPU 命令や仮想化テクノロジが必要ないため、電子レンジに導入することもできます。
KVM - 本格的な仮想化。CPU のすべてのパワーを使用し、あらゆるものをあらゆる方法で縦横に仮想化できます。
ホスティング プロバイダーの間で OpenVZ は過剰に売られるだろうという一般的な考えに反して、KVM はそうではありません。後者にとって幸いなことに、KVM は現在、兄弟と同様に過剰に売られています。
何を引き継ぐのでしょうか?
移行のテスト対象として、OpenVZ で利用可能なオペレーティング システム全体 (CentOS (6 および 7 バージョン)、Ubuntu (14、16、および 18 LTS)、Debian 7) を使用する必要がありました。
ほとんどの OpenVZ コンテナはすでに何らかの LAMP を実行しており、一部には非常に特殊なソフトウェアが含まれていると想定されていました。 ほとんどの場合、これらは ISPmanager、VestaCP コントロール パネルを使用した構成でした (そして、ほとんどの場合、何年も更新されていませんでした)。 彼らの転送リクエストも考慮する必要があります。
移行は、転送されたコンテナの IP アドレスを保持しながら実行されます。コンテナが持っていた IP は VM 上に保存されており、問題なく動作すると仮定します。
転送する前に、すべてが手元にあることを確認してください。
- OpenVZ サーバー、ホスト マシンへの完全な root アクセス、コンテナーの停止/マウント/開始/削除の機能
- KVM サーバー、ホスト マシンへの完全な root アクセス、およびそれが意味するすべて。 すべてがすでに構成されており、すぐに使用できることが前提となっています。
転送を開始しましょう
転送を開始する前に、混乱を避けるために役立つ用語を定義しましょう。
KVM_NODE - KVMホストマシン
VZ_NODE - OpenVZホストマシン
CTID - OpenVZコンテナ
VM - KVM仮想サーバー
移行の準備と仮想マシンの作成。
ステップ1
コンテナをどこかに移動する必要があるので、 VM と同様の構成で KVM_NODE.
重要! 現在 CTID で実行されているオペレーティング システム上に VM を作成する必要があります。 たとえば、Ubuntu 14 が CTID にインストールされている場合、Ubuntu 14 は VM にインストールされている必要があります。マイナー バージョンは重要ではなく、それらの不一致はそれほど重大ではありませんが、メジャー バージョンは同じである必要があります。
VM を作成した後、CTID と VM 上のパッケージを更新します (OS の更新と混同しないでください。更新はしません。パッケージと、パッケージが到着した場合はメイン内の OS バージョンのみを更新します)バージョン)。
CentOS の場合、このプロセスは無害に見えます。
# yum clean all
# yum update -y
Ubuntu と Debian にとっても同様に無害です。
# apt-get update
# apt-get upgrade
ステップ2
にインストールします CTID, VZ_NODE и VM ユーティリティ rsync:
CentOSの:
# yum install rsync -y
Debian、Ubuntu:
# apt-get install rsync -y
他には何もインストールしていません。
ステップ3
停車します CTID на VZ_NODE チーム
vzctl stop CTID
イメージのマウント CTID:
vzctl mount CTID
/vz/root/ フォルダーに移動しますCTID そして実行する
mount --bind /dev dev && mount --bind /sys sys && mount --bind /proc proc && chroot .
ルートの下に、ファイル /root/exclude.txt を作成します。これには、新しいサーバーに到達しない例外のリストが含まれます。
/boot
/proc
/sys
/tmp
/dev
/var/lock
/etc/fstab
/etc/mtab
/etc/resolv.conf
/etc/conf.d/net
/etc/network/interfaces
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/hwconf
/etc/sysconfig/ip6tables-config
/etc/sysconfig/kernel
/etc/hostname
/etc/HOSTNAME
/etc/hosts
/etc/modprobe*
/etc/modules
/net
/lib/modules
/etc/rc.conf
/usr/share/nova-agent*
/usr/sbin/nova-agent*
/etc/init.d/nova-agent*
/etc/ips
/etc/ipaddrpool
/etc/ips.dnsmaster
/etc/resolv.conf
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-ens3
に接続します KVM_NODE そして私たちの VMこれにより、ネットワーク経由で動作し、アクセスできるようになります。
これで転送の準備がすべて整いました。 行く!
ステップ4
まだ魔法にかかって、私たちはパフォーマンスします
rsync --exclude-from="/root/exclude.txt" --numeric-ids -avpogtStlHz --progress -e "ssh -T -o Compression=no -x" / root@KVM_NODE:/
rsync コマンドが転送を実行します。キーがクリアであることを望みます。転送はシンボリックリンク、アクセス権、所有者およびグループを保持して実行され、高速化のために暗号化は無効になっています (より高速な暗号を使用することもできますが、これはこのタスクにとってはそれほど重要ではありません)、圧縮も無効になります。
rsync が完了したら、chroot を終了し (ctrl+d を押して)、次のコマンドを実行します。
umount dev && umount proc && umount sys && cd .. && vzctl umount CTID
ステップ5
OpenVZ から転送した後に VM を起動するのに役立ついくつかの手順を実行してみましょう。
サーバー上で Systemd たとえば、VNC サーバー画面を通じて通常のコンソールにログインするのに役立つコマンドを実行してみましょう。
mv /etc/systemd/system/getty.target.wants/[email protected] /etc/systemd/system/getty.target.wants/[email protected]
サーバー上 CentOS 6 и CentOS 7 必ず新しいカーネルをインストールしてください。
yum install kernel-$(uname -r)
そこからサーバーをロードすることはできますが、転送後に動作が停止したり、削除されたりする可能性があります。
サーバー上 CentOS 7 PolkitD に小さな修正を適用する必要があります。そうしないと、サーバーが永久にクラッシュします。
getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd group already existse[0m" || { groupadd -r polkitd && echo -e "e[1;33mAdded missing polkitd groupe[0m" || echo -e "e[1;31mAdding polkitd group FAILEDe[0m"; }
getent passwd polkitd >/dev/null
&& echo -e "e[1;32mpolkitd user already existse[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "User for polkitd" polkitd && echo -e "e[1;33mAdded missing polkitd usere[0m" || echo -e "e[1;31mAdding polkitd user FAILEDe[0m"; }
rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verification passede[0m" || { echo -e "e[1;33mResetting polkit* rpm user/group ownership & permse[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }
すべてのサーバーで、Apache 用の mod_fcgid がインストールされている場合、権限のある小さな修正が実行されます。そうでない場合、mod_fcgid を使用しているサイトはエラー 500 でクラッシュします。
chmod +s `which suexec` && apachectl restart
そして最後のものは、Ubuntu と Debian ディストリビューションに役立ちます。 この OS はエラーで永続ブートにクラッシュする可能性があります
ループが速すぎます。 実行を少し抑制する
不快ではありますが、OS のバージョンによっては簡単に修正できます。
На Debian 9, XNUMX, XNUMX 修正は次のようになります。
私たちは実行します
dbus-uuidgen
エラーが発生した場合
/usr/local/lib/libdbus-1.so.3: バージョン `LIBDBUS_PRIVATE_1.10.8' が見つかりません
LIBDBUS の存在を確認する
ls -la /lib/x86_64-linux-gnu | grep dbus
libdbus-1.so.3 -> libdbus-1.so.3.14.15
libdbus-1.so.3.14.15 <-- нужен этот
libdbus-1.so.3.14.16
すべてが順調であれば、そうします
cd /lib/x86_64-linux-gnu
rm -rf libdbus-1.so.3
ln -s libdbus-1.so.3.14.15 libdbus-1.so.3
それでも解決しない場合は、XNUMX 番目のオプションを試してください。
問題の XNUMX 番目の解決策は、 実行を少し抑制する ほぼすべての Ubuntu および Debian ディストリビューションに適しています。
実施します
bash -x /var/lib/dpkg/info/dbus.postinst configure
そして Ubuntuの14, Debian 7, XNUMX, XNUMX さらに、次のことを実行します。
adduser --system --home /nonexistent --no-create-home --disabled-password --group messagebus
rm -rf /etc/init.d/modules_dep.sh
私たちが何をしてしまったのでしょうか? Debian/Ubuntu を実行するために欠落していた messagebus を復元し、OpenVZ に由来し、多くのカーネル モジュールのロードを妨げていた modules_dep を削除しました。
ステップ6
VM を再起動し、VNC で読み込みの進行状況を確認します。理想的には、すべてが問題なく読み込まれるようになります。 移行後に特定の問題が発生する可能性がありますが、それらはこの記事の範囲を超えており、発生した場合は修正されます。
この情報がお役に立てば幸いです! 🙂
出所: habr.com