🛌🏿 🙎 ❓ Crownによる仮想マシンへの自動サーバークローニング 🎧 📉 🐙

問題の声明

問題の説明

この作業では、Debian GNU / Linuxに基づいた多数の物理サーバーを使用します。開発者は、多くの場合、これらのサーバーのクローンを解体する必要があり、そのたびに手でクローンを作成するのは非効率的です。注：説明した方法では特定の分布は重要ではありません。この方法はどの分布にも簡単に適応できます。

美しさの絵

挑戦する

クラウンによって戦闘サーバーを仮想マシンにクローンする自動システムを作成します。

どうした

virt_server> p2v.py foo full WORKING WITH SERVER: 'foo' READING CONFIG FOR 'foo' CHECKING LOCAL CONFIG CHECKING LOCAL CONFIG FOR 'foo' COMPLETED SUCCESSFULLY CHECKING REMOTE CONFIG CHECKING NODUMP FLAG: "lsattr -d /home/backupman/dumps | egrep '[\\w-]+d[\\w-]+[ ]/data/dumps'" CHECKING REMOTE DUMP: 'sudo /sbin/dump a0f /dev/null /dev/null' CHECKING IF WE ARE ABLE TO SSH TO: "ssh -T backupman@foo 'if [ -d /data/dumps ] ; then exit 0 ; else exit 1 ; fi'" CHECKING REMOTE CONFIG FOR 'foo' COMPLETED SUCCESSFULLY DUMPING FILESYSTEMS GETTING THE DUMPS STOPPING VM: foo2 MAKING FS TYPE: ext3 ON PARTITION: /dev/mapper/foo RESTORING DUMPS FOR: foo INSTALLING BOOTLOADER FOR: foo RESTORING CONFIG FOR: foo STARTING VM: /etc/xen/foo.xm

どうでしたか

バトルサーバーの複製

戦闘サーバーを停止せずに複製する最も簡単で同時に最速の方法は、次のことを考慮します。

dump

ユーティリティを使用して、サーバー自体にダンプを作成します。考慮事項は次のとおりです。
- 仮想マシンのライブFSをダンプするときに起こりうる問題はひどくありません。これはバックアップではありません。経験から、実際には、私はまだ壊れたファイルの問題に遭遇していません
- サーバーダンプは迅速に行われますが、これは重要です
仮想マシンを備えたサーバーにダンプをコピーします。私はscp

を使用しています私たちの速度では、ボトルネックは依然としてネットワークであるため、送信中にファイルを暗号化するコストはそれほど大きくありません
restore

ユーティリティを使用して、事前に割り当てられたLVMパーティションにダンプを展開します
ブートローダーのインストール
仮想マシンに関連する設定のコピー（ /etc/network/interfaces, /etc/hostname, /etc/mailname, /etc/aliases

など）
新しく準備した仮想マシンを起動します。

使用される仮想化システムは完全に無関係であり、唯一の要件は、仮想マシンに仮想ディスクとしてLVMパーティションを提供できることです。私は個人的にXENを使用しています。

明確にするために、例を挙げます。仮想マシンサーバーvirt_server

、複製する物理サーバーserver1

。

server1

クローンのXEN構成は、 virt_server

にありserver1
server1

のLVMパーティションは次のとおりですserver1

/dev/mapper/server1
server1:/dumps/server1/

行いserver1:/dumps/server1/

、それをvirt_server:/dumps/server1

コピーしvirt_server:/dumps/server1
変更されたserver1

構成はvirt_server:/dumps/server1/cfg/

に保持されvirt_server:/dumps/server1/cfg/

すべてが機能するためには、 backupman

にbackupman

ユーザーを追加し、パスワードなしでsudo dump

を許可server1

必要があります。 virt_server

backupman@server1

キー認証を構成する必要がありbackupman@server1

。 virt_server

、ルートからすべてを行います。

この設定では、コンソールからのクローン作成手順は次のようになります。

 root@virt_server> xm destroy server1 root@virt_server> ssh backupman@server1 backupman@server1$ sudo dump -a0f /dumps/server1.root / backupman@server1$ for i in var usr home ; do sudo dump a0f /dumps/server1.$i /$i ; done backupman@server1$ exit root@virt_server> scp backupman@server1:/dumps/server1.* /dumps/server1/ root@virt_server> mkfs.ext4 /dev/mapper/server1 root@virt_server> mount /dev/mapper/server1 /mnt/server1 root@virt_server> cd /mnt/server1 root@virt_server> restore -rf /dumps/server1.root root@virt_server> for i in var usr home ; do cd /mnt/$i && restore /dumps/server1.$i ; done root@virt_server> dd if=/usr/share/syslinux/mbr.bin of=/dev/mapper/server1 root@virt_server> extlinux --install /dev/mapper/server1 root@virt_server> scp -R /dumps/server1/cfg/* /mnt/server root@virt_server> xm start server1.xm

プロセス自動化

サーバーのクローン作成アルゴリズムが明確になったので、スクリプトの作成を開始できます。スクリプトの操作は次のように実行されます。

スクリプト構成は、各サーバーを複製する方法を説明します
スクリプト引数は、サーバー名と必要なアクションを示します
Skrpitはサーバー名にちなんで名付けられた設定セクションを読み取り、自動的にサーバーのクローンを作成して仮想マシンを起動します
スクリプトは夜に王冠で実行されます
????
メリット！

仮想マシンサーバーとクローンサーバーを構成する

仮想マシンサーバーで、次の操作を行います。

仮想マシンのディスクパーティションを作成する
仮想マシン構成ファイルを作成する
スクリプト構成ファイルを作成する

クローンサーバーで、次の手順を実行します。

dump

ユーティリティのインストール
backupman

ユーザーを作成する
以下を/ etc / sudoersに追加して、このユーザーがダンプを開始できるようにしますbackupman ALL=NOPASSWD: /sbin/dump
ダンプ用のディレクトリを作成する
ダンプをダンプしないように、このディレクトリにchattr +d

します
キーによって仮想マシンの北からクローンサーバーへのsshアクセスを許可する

スクリプト構成

標準の.ini形式の構成は、スクリプトと共にディレクトリに配置されます。次のようになります。

 [server1] vm_config = /etc/xen/server1.xm vm_name = server1 ssh = backupman@server1.site scp = backupman@server1.site dumps_list = /,/var,/usr,/home remote_dumps_dir = /home/bakupman/dumps local_dumps_dir = /dumps/server1 mount_dir = /mnt/server1 partition = /dev/mapper/server1 fs = ext3

ssh

およびscp

パラメーターについては、少し説明する必要があります。これらのパラメーターは、それぞれssh

およびscp

呼び出しの形式を決定します。両方とも必要です。 ssh

ポートは-p

スイッチで指定され、 scp

場合、スイッチは-P

で指定されます。

スクリプト自体

スクリプトを完全に持ってくる意味がわかりません。なぜなら、 githubに投稿したので、スクリプト全体の操作についてのみ説明します。

このスクリプトは、入力として2つのパラメーター、つまり、構成ファイル内のセクションの名前であるサーバー名と必要なアクションを取ります。

実行するアクションを指定できる主な機能は次のとおりです。構成の確認、完全なクローン作成、サーバーダンプの作成、または既存のダンプの展開ができます。

 def main(): """Main function, calls all other ones""" if len(sys.argv) < 3: sys.exit('Usage: %s <servername> <action> (check|full|dump|get|restore)' % sys.argv[0]) server = sys.argv[1] action = sys.argv[2] print "\nWORKING WITH SERVER: %r\n" % server if action == "check": try: conf=read_config(server) check_config_local(conf) check_config_remote(conf except Exception, e: sys.exit("\nERROR: %r\n" % e) elif action == "full": try: conf=read_config(server) check_config_local(conf) check_config_remote(conf) stop_vm(conf) dump_physical(conf) get_dumps(conf) restore_vm(conf) install_bootloader(conf) restore_config(conf) start_vm(conf) except Exception, e: cleanup(conf) sys.exit("\nERROR: %r\n" % e) <...>

すべてのスクリプト作業は、何らかのアクションを完了できない場合に例外がスローされ、スクリプトがエラーメッセージで終了するように構成されています。

構成ファイルで指定された構成がチェックされ、何か問題がある場合、スクリプトは終了します。すべてが正常な場合、スクリプトはコンソールから入力できるすべてのコマンドを実行し、完了のステータスを確認します。

スクリプトの最も「難しい」部分はチェックです。この断片に注目したい：

 def check_config_local(conf): """Checks config by trying to ssh, checking existence of local and remote folders, destination partition, mount point, and remote dump utility""" print "\nCHECKING LOCAL CONFIG\n" # check for ensuring we won't delete accidentaly specified host os parittion if conf['partition'] == "/dev/sda" or conf['partition'] == "/dev/sda1" or \ conf['partition'] == "/dev/sda2" or conf['partition'] == "/dev/sda3" or \ conf['partition'] == "/dev/sda4" or conf['partition'] == "/dev/sda5": raise Exception, "DON'T KILL THE SERVER! %S IS A SYSTEM PARTITION!!" % conf['partition']

仮想マシンサーバー上のオペレーティングシステムはこれらのセクションにインストールされ、LVMは仮想マシン自体用に作成されます。なぜなら目的のパーティションに仮想マシンをデプロイすると、新しいファイルシステムが作成されます。次に、仮想マシンサーバーの偶発的な破壊を防ぐために、ここにシステムパーティションを入力します。

github

それだけです、スクリプトは次の場所にあります： github.com/sistemshik/p2v

Crownによる仮想マシンへの自動サーバークローニング