Untuk waktu yang lama, perusahaan Maxnet Systems menggunakan versi gratis VMware - ESXi, dimulai dengan versi 5.0, sebagai hypervisor. Versi berbayar vSphere menakuti model lisensi, sementara versi gratis memiliki sejumlah kelemahan yang tidak tersedia dalam versi berbayar, tetapi Anda bisa tahan dengan mereka. Tetapi ketika dalam versi baru ESXi antarmuka web baru menolak untuk bekerja dengan yang lama, dan pemantauan array RAID berhenti menunjukkan tanda-tanda kehidupan, perusahaan memutuskan untuk mencari solusi yang lebih universal dan terbuka. Perusahaan telah memiliki pengalaman yang baik dan kesan yang baik tentang LXC - Linux Containers. Oleh karena itu, menjadi jelas bahwa hypervisor mimpi akan menjadi hibrida dan menggabungkan KVM dan LXD untuk beban yang berbeda - kelanjutan evolusi LXC. Mencari informasi tentang KVM, perusahaan dihadapkan dengan kesalahpahaman, penggaruk dan praktik berbahaya, tetapi tes dan waktu menempatkan semuanya pada tempatnya.
Tentang cara mengatasi perpindahan dari ESXi ke KVM dan tidak menggerakkan roda dengan menyapu, akan memberi tahu
Lev Nikolaev (
maniaque ) - administrator dan pengembang sistem yang sarat muatan, pelatih teknologi informasi. Mari kita bicara tentang Jaringan, repositori, wadah, KVM, LXD, LXC, penyediaan, dan mesin virtual yang nyaman.
Prolog
Kami akan segera mengidentifikasi pemikiran-pemikiran utama, dan kemudian kami akan menganalisisnya secara lebih rinci.
Jaringan Meskipun kecepatan antarmuka Anda tidak melebihi 1 Gb / s, jembatan sudah cukup untuk Anda. Segera setelah Anda ingin memeras lebih banyak - itu akan membatasi Anda.
Repositori. Buat penyimpanan jaringan bersama. Bahkan jika Anda tidak siap untuk menggunakan 10 Gbit / s di dalam jaringan, bahkan 1 Gbit / s akan memberi Anda 125 MB / s penyimpanan. Untuk sejumlah beban, ini akan cukup dengan margin, dan migrasi mesin virtual akan menjadi masalah mendasar.
Wadah atau KVM? Pro, kontra, perangkap. Jenis-jenis muatan apa yang paling baik ditempatkan dalam sebuah wadah dan mana yang paling baik disimpan dalam KVM?
LXD atau LXC . Apakah LXD LXC? Atau versi lain? Atau add-on? Tentang apa semua ini? Mari kita singkirkan mitos dan pahami perbedaan antara LXD dan LXC.
Provisi yang mudah . Mana yang lebih nyaman: ambil gambar yang sama atau instal sistem dari awal setiap kali? Bagaimana cara melakukannya dengan cepat dan akurat setiap saat?
Mesin virtual yang nyaman. Akan ada cerita menyeramkan tentang bootloader, partisi, LVM.
Lain-lain . Banyak pertanyaan kecil: bagaimana cara menyeret mesin virtual dengan cepat dari ESXi ke KVM, bagaimana cara bermigrasi dengan baik, bagaimana cara virtualisasi disk dengan benar?
Alasan untuk pindah
Dari mana kita mendapatkan ide gila untuk pindah dari ESXi ke KVM / LXD? ESXi populer di kalangan bisnis kecil dan menengah. Ini adalah hypervisor yang bagus dan murah. Namun ada nuansa.
Kami mulai dengan versi 5.0 - nyaman, semuanya berfungsi! Versi 5.5 berikutnya adalah sama.
Sejak versi 6.0 itu sudah lebih sulit. Pada ESXi, antarmuka Web tidak langsung menjadi gratis, hanya dari versi 6.5, sebelum itu diperlukan utilitas untuk Windows. Kami tahan dengan ini. Siapa yang menjalankan OS X membeli Parallels dan menginstal utilitas ini. Ini adalah rasa sakit yang terkenal.
Pemantauan secara berkala terlintas. Itu perlu untuk me-restart layanan manajemen di konsol server - kemudian CIM Heartbeat muncul lagi. Kami bertahan, karena dia tidak selalu jatuh.
Versi ESXi 6.5 - sampah, limbah, dan kekejaman. Hypervisor mengerikan. Dan inilah alasannya.
- Angular jatuh dengan pengecualian di pintu masuk ke antarmuka Web. Segera setelah Anda memasukkan nama pengguna dan kata sandi - segera pengecualian!
- Kemampuan untuk memonitor status array RAID dari jarak jauh tidak berfungsi karena nyaman bagi kami. Dulu nyaman, tetapi dalam versi 6.5, semuanya buruk.
- Dukungan lemah untuk kartu jaringan modern dari Intel . Kartu jaringan dari Intel dan ESXi menyebabkan rasa sakit. Ada utas sakit di forum dukungan ESXi tentang ini. VMware dan Intel bukan teman dan hubungan tidak akan membaik dalam waktu dekat. Yang menyedihkan adalah bahwa bahkan pelanggan solusi berbayar mengalami masalah.
- Tidak ada migrasi dalam ESXi . Kecuali migrasi dianggap sebagai jeda, salin, dan mulai prosedur. Kami menghentikan mobil, menyalinnya dengan cepat, dan menyalakannya di tempat lain. Tetapi tidak mungkin menyebutnya migrasi - masih ada yang sederhana.
Setelah melihat semua ini, kami mendapat ide gila untuk bergerak dengan ESXi 6.5.
Daftar keinginan
Sebagai permulaan, kami menulis daftar keinginan untuk masa depan ideal yang akan kami tuju.
Manajemen dari bawah SSH , dan Web dan lebih opsional. Antarmuka web bagus, tetapi dalam perjalanan bisnis dari iPhone, masuk ke antarmuka web ESXi dan melakukan sesuatu yang tidak nyaman dan sulit. Oleh karena itu, satu-satunya cara untuk mengelola semuanya adalah SSH, tidak akan ada yang lain.
Virtualisasi Windows. Terkadang pelanggan meminta hal-hal aneh, dan misi kami adalah membantu mereka.
Driver selalu segar dan kemampuan untuk mengkonfigurasi kartu jaringan . Keinginan yang memadai, tetapi tidak direalisasi di bawah ESXi murni.
Migrasi langsung, bukan pengelompokan . Kami ingin kemampuan untuk menyeret mesin dari satu hypervisor ke yang lain tanpa merasakan penundaan, waktu henti atau ketidaknyamanan.
Daftar keinginan sudah siap, maka pencarian yang sulit telah dimulai.
Pilihan tepung
Pasar berputar di sekitar KVM atau LXC dengan saus yang berbeda. Terkadang sepertinya Kubernetes berada di suatu tempat di atas, di mana semuanya baik-baik saja, matahari dan surga, dan pada tingkat di bawah ini ada Morlock - KVM, Xen atau sesuatu seperti itu ...
Misalnya, Proxmox VE adalah Debian, yang ditarik oleh kernel dari Ubuntu. Ini terlihat aneh, tetapi apakah ini membuatnya diproduksi?
Tetangga kita di lantai bawah adalah Alt Linux. Mereka datang dengan solusi yang indah: mereka menggabungkan Proxmox VE sebagai satu paket. Mereka hanya menempatkan paket dalam satu perintah. Ini mudah, tetapi kami tidak memasukkan Alt Linux ke dalam produksi, jadi itu tidak cocok untuk kami.
Ambil KVM
Pada akhirnya, kami memilih KVM. Mereka tidak mengambilnya, Xen, misalnya, karena komunitas - KVM memiliki lebih banyak. Tampaknya kami akan selalu menemukan jawaban untuk pertanyaan kami. Kami kemudian menemukan bahwa ukuran komunitas tidak memengaruhi kualitasnya.
Awalnya, kami menghitung bahwa kami akan menggunakan mesin Bare Metal, menambahkan Ubuntu yang sedang kami tangani, dan menggulung KVM / LXD dari atas. Kami mengandalkan kemampuan menjalankan kontainer. Ubuntu adalah sistem yang terkenal dan tidak ada kejutan dalam hal memecahkan masalah boot / pemulihan bagi kami. Kami tahu di mana harus menendang jika hypervisor tidak dimulai. Semuanya jelas dan nyaman bagi kita.
Kursus Kecelakaan KVM
Jika Anda berasal dari dunia ESXi, maka Anda akan menemukan banyak hal menarik. Pelajari tiga kata: QEMU, KVM, dan libvirt.
QEMU menerjemahkan keinginan OS tervirtualisasi ke dalam tantangan proses reguler. Bekerja sangat baik hampir di mana-mana, tetapi lambat. QEMU sendiri adalah produk mandiri yang memvirtualisasi banyak perangkat lain.
Lebih jauh di tempat kejadian datang sekelompok
QEMU-KVM . Ini adalah modul kernel Linux untuk QEMU. Virtualisasi semua instruksi itu mahal, jadi kami memiliki modul kernel KVM yang
hanya menerjemahkan beberapa instruksi . Hasilnya, ini secara signifikan lebih cepat, karena hanya beberapa persen dari instruksi dari set umum yang diproses. Ini semua biaya virtualisasi.
Jika Anda hanya memiliki QEMU, memulai mesin virtual tanpa ikatan terlihat seperti ini:
$ qemu < >
Dalam parameter yang Anda gambarkan jaringan, blokir perangkat. Semuanya indah, tetapi tidak nyaman. Karena itu ada libvirt.
Tujuan libvirt adalah menjadi alat tunggal untuk semua hypervisor . Itu bisa bekerja dengan apa saja: dengan KVM, dengan LXD. Tampaknya hanya mempelajari sintaksis libvirt, tetapi pada kenyataannya ia bekerja lebih buruk daripada secara teori.
Ketiga kata inilah yang diperlukan untuk meningkatkan mesin virtual pertama di KVM. Tapi sekali lagi, ada nuansa ...
Libvirt memiliki konfigurasi tempat mesin virtual dan pengaturan lainnya disimpan. Ini menyimpan konfigurasi dalam file xml - penuh gaya, modis dan langsung dari tahun 90-an. Jika diinginkan, mereka dapat diedit dengan tangan, tetapi mengapa, jika ada perintah yang mudah. Juga nyaman adalah bahwa perubahan file xml luar biasa berversi. Kami menggunakan
dllkeeper - versi direktori dll. Ini sudah mungkin untuk menggunakan dllkeeper dan sudah saatnya.
Kursus Kecelakaan LXC
Ada banyak kesalahpahaman tentang LXC dan LXD.
LXC adalah kemampuan kernel modern untuk menggunakan ruang nama - untuk berpura-pura bahwa itu bukan inti yang semula.
Anda dapat membuat ruang nama ini sebanyak yang Anda suka untuk setiap wadah. Secara formal, intinya adalah satu, tetapi berperilaku seperti banyak inti identik. LXC memungkinkan Anda untuk menjalankan kontainer, tetapi hanya menyediakan alat dasar.
Canonical, yang berada di belakang Ubuntu dan dengan agresif memindahkan wadah ke depan, telah merilis
LXD, sebuah analog dari libvirt . Ini adalah penjilidan yang membuatnya lebih mudah untuk menjalankan kontainer, tetapi di dalamnya masih LXC.
LXD adalah hypervisor kontainer yang didasarkan pada LXC.
Perusahaan berkuasa di LXD. LXD menyimpan konfigurasi dalam basis datanya - di direktori
/var/lib/lxd . Di sana, LXD mengarahkan konfigurasi ke konfigurasi di SQlite. Menyalinnya tidak masuk akal, tetapi Anda dapat menuliskan perintah yang Anda gunakan untuk membuat konfigurasi wadah.
Tidak ada pembongkaran seperti itu, tetapi sebagian besar perubahan diotomatiskan oleh tim. Ini adalah analog dari file Docker, hanya dengan kontrol manual.
Produksi
Apa yang kami hadapi ketika kami semua mulai beroperasi.
Jaringan
Berapa banyak sampah dan keributan di Internet tentang jaringan di KVM! 90% material mengatakan menggunakan jembatan.
Berhenti menggunakan jembatan!
Apa yang salah dengannya? Akhir-akhir ini, saya merasa bahwa kegilaan terjadi dengan kontainer: letakkan Docker di atas Docker sehingga Anda dapat menjalankan Docker di Docker sambil menonton Docker. Kebanyakan tidak mengerti apa yang dilakukan jembatan.
Ini menempatkan pengontrol jaringan Anda dalam
mode promiscuous dan menerima semua lalu lintas karena tidak tahu yang mana dan yang tidak. Akibatnya, semua lalu lintas jembatan melewati tumpukan jaringan Linux yang luar biasa cepat, dan ada banyak penyalinan. Pada akhirnya, semuanya lambat dan buruk. Karena itu, jangan menggunakan jembatan dalam produksi.
SR-IOV
SR-IOV adalah kemampuan untuk melakukan virtualisasi dalam kartu jaringan . Kartu jaringan itu sendiri dapat mengalokasikan sebagian dari dirinya untuk mesin virtual, yang memerlukan dukungan perangkat keras. Inilah yang akan mencegah migrasi. Bermigrasi mesin virtual di mana SR-IOV hilang sangat menyakitkan.
SR-IOV harus digunakan jika didukung oleh semua hypervisor sebagai bagian dari migrasi. Jika tidak, maka macvtap adalah untuk Anda.
macvtap
Ini untuk mereka yang kartu jaringannya tidak mendukung SR-IOV. Ini adalah versi ringan dari jembatan: alamat MAC yang berbeda digantung pada satu kartu jaringan, dan
pemfilteran unicast digunakan : kartu jaringan tidak menerima semuanya, tetapi secara ketat sesuai dengan daftar alamat MAC.
Rincian lebih berdarah dapat ditemukan di pembicaraan hebat Toshiaki Makita
, Virtual Switching Technologies dan Linux Bridge . Dia penuh dengan rasa sakit dan penderitaan.
90% materi tentang cara membangun jaringan di KVM tidak berguna.
Jika seseorang mengatakan jembatan itu luar biasa, jangan bicara dengan orang itu lagi.
Dengan macvtap,
CPU menyimpan sekitar 30% karena lebih sedikit salinan. Namun mode promiscuous memiliki nuansa tersendiri. Anda tidak dapat terhubung ke antarmuka jaringan mesin tamu dari hypervisor itu sendiri - dari host. Laporan Toshiaki merinci ini. Namun singkatnya - itu tidak akan berhasil.
Dari hypervisor sangat jarang SSH. Lebih mudah untuk memulai konsol di sana, misalnya, konsol Win. Dimungkinkan untuk "menonton" lalu lintas di antarmuka - Anda tidak dapat terhubung melalui TCP, tetapi lalu lintas pada hypervisor terlihat.
Jika kecepatan Anda di atas 1 Gigabit - pilih macvtap.
Pada kecepatan antarmuka hingga atau sekitar 1 Gigabit per detik, bridge juga dapat digunakan. Tetapi jika Anda memiliki kartu jaringan 10 Gb dan ingin membuangnya entah bagaimana, maka hanya macvtap yang tersisa. Tidak ada pilihan lain. Kecuali SR-IOV.
systemd-networkd
Ini adalah cara terbaik untuk menyimpan konfigurasi jaringan pada hypervisor itu sendiri . Dalam kasus kami, ini adalah Ubuntu, tetapi untuk sistem lain, systemd berfungsi.
Kami dulu memiliki file
/etc/network/interfaces tempat kita semua menyimpannya. Satu file tidak nyaman untuk diedit setiap kali - systemd-networkd memungkinkan Anda untuk membagi konfigurasi menjadi hamburan file-file kecil. Ini nyaman karena berfungsi dengan sistem versi apa pun: dikirim ke Git dan Anda tahu kapan dan perubahan apa yang terjadi.
Ada kekurangan yang ditemukan oleh networker kami. Ketika Anda perlu menambahkan VLAN baru di hypervisor, saya pergi dan mengkonfigurasi. Lalu saya berkata: "systemctl restart systemd-networkd". Pada saat ini, semuanya baik-baik saja dengan saya, tetapi jika sesi BGP dari mesin ini dinaikkan, mereka rusak. Networker kami tidak menyetujui ini.
Untuk hypervisor, tidak ada hal buruk yang terjadi. Systemd-networkd tidak cocok untuk boarder perbatasan, server dengan BGP tinggi, dan untuk hypervisor - sangat baik.
Systemd-networkd masih jauh dari final dan tidak akan pernah selesai. Tapi ini lebih nyaman daripada mengedit satu file besar. Alternatif untuk systemd-networkd di Ubuntu 18.04 adalah Netplan. Ini adalah cara "keren" untuk mengkonfigurasi jaringan dan menginjak menyapu.
Perangkat jaringan
Setelah menginstal KVM dan LXD pada hypervisor, hal pertama yang Anda akan lihat adalah dua jembatan. Satu membuat KVM untuk dirinya sendiri, dan yang kedua - LXD.
LXD dan KVM sedang mencoba untuk menyebarkan jaringan mereka.
Jika Anda masih membutuhkan jembatan - untuk mesin uji atau untuk bermain, bunuh jembatan, yang dinyalakan secara default dan buat jembatan Anda sendiri - yang Anda inginkan. KVM atau LXD melakukannya dengan sangat - selipkan dnsmasq, dan kengerian dimulai.
Penyimpanan
Tidak masalah implementasi mana yang Anda sukai - gunakan penyimpanan bersama.
Misalnya, iSCSI untuk mesin virtual. Anda tidak akan menyingkirkan "titik kegagalan", tetapi Anda dapat
menggabungkan penyimpanan pada satu titik . Ini membuka peluang baru yang menarik.
Untuk melakukan ini, Anda harus memiliki setidaknya 10 Gb / s antarmuka di dalam pusat data. Tetapi bahkan jika Anda hanya memiliki 1 Gbit / s - jangan khawatir. Ini sekitar 125 MB / s - cukup baik untuk hypervisor yang tidak memerlukan beban disk yang tinggi.
KVM dapat melakukan migrasi dan menyeret penyimpanan. Tetapi, misalnya, dalam mode beban kerja, mentransfer mesin virtual ke beberapa Terabyte adalah hal yang menyebalkan. Untuk migrasi dengan penyimpanan umum, hanya RAM yang cukup, yang bersifat elementer. Ini
mengurangi waktu migrasi .
Pada akhirnya, LXD atau KVM?
Awalnya, kami mengasumsikan bahwa untuk semua mesin virtual di mana kernel cocok dengan sistem host, kami akan mengambil LXD. Dan di mana kita perlu mengambil inti lain - ambil KVM.
Pada kenyataannya, rencana itu tidak berjalan. Untuk memahami alasannya, lihat lebih dekat pada LXD.
Lxd
Kelebihan utama adalah menghemat memori pada intinya. Kernelnya sama dan ketika kami meluncurkan wadah baru, kernelnya sama. Tentang ini, pro berakhir dan kontra dimulai.
Blokir perangkat dengan rootfs harus dipasang. Ini lebih sulit daripada kedengarannya.
Sebenarnya tidak ada migrasi . Itu, dan didasarkan pada criu instrumen suram indah, yang melihat rekan kami. Saya bangga dengan mereka, tetapi dalam kasus-kasus sederhana criu tidak bekerja.
zabbix-agent berperilaku aneh dalam sebuah wadah . Jika Anda menjalankannya di dalam wadah, maka Anda akan melihat serangkaian data dari sistem host, dan bukan dari wadah. Sejauh ini tidak ada yang bisa dilakukan.
Ketika melihat daftar proses pada hypervisor, tidak mungkin untuk dengan cepat memahami wadah mana dari proses tertentu tumbuh . Butuh waktu untuk mengetahui namespace apa yang ada, apa dan di mana. Jika beban di suatu tempat melonjak lebih dari biasanya, maka dengan cepat tidak mengerti. Ini adalah masalah utama - keterbatasan kemampuan respons. Investigasi mini dilakukan untuk setiap kasus.
Satu-satunya plus LXD adalah menghemat memori inti dan mengurangi overhead.
Tapi Memori Bersama Kernel di KVM sudah menghemat memori.
Sejauh ini saya tidak melihat alasan untuk memperkenalkan produksi serius dan LXD. Meskipun upaya terbaik Canonical di bidang ini, produksi LXD membawa lebih banyak masalah daripada solusi. Dalam waktu dekat situasinya tidak akan berubah.
Tapi, tidak bisa dikatakan bahwa LXD itu jahat. Dia baik, tetapi dalam kasus terbatas, yang akan saya bahas nanti.
Criu
Criu adalah utilitas suram.
Buat wadah kosong, itu akan tiba dengan klien DHCP dan katakan: "Tangguhkan!" Dapatkan kesalahan karena ada klien DHCP: "Horor, horor! Dia membuka soket dengan tanda "mentah" - sungguh mimpi buruk! " Lebih buruk dari itu.
Tayangan kontainer: tidak ada migrasi, Criu berfungsi setiap saat.
Saya “suka” rekomendasi dari tim LXD apa yang harus dilakukan dengan Criu sehingga tidak ada masalah:
-
Ambil versi yang lebih segar dari repositori!Dan bisakah saya entah bagaimana meletakkannya dari paket agar tidak lari ke repositori?
Kesimpulan
LXD luar biasa jika Anda ingin membuat infrastruktur CI / CD. Kami mengambil LVM - Manajer Volume Logis, membuat snapshot darinya, dan memulai wadah di atasnya. Semuanya bekerja dengan baik! Dalam sedetik, wadah bersih baru dibuat, yang dikonfigurasi untuk pengujian dan rolling chef - kami secara aktif menggunakannya.
LXD lemah untuk produksi serius . Kami tidak dapat menemukan apa yang harus dilakukan dengan LXD dalam produksi jika tidak bekerja dengan baik.
Pilih KVM dan hanya KVM!Migrasi
Saya akan mengatakan ini secara singkat. Bagi kami, migrasi ternyata menjadi dunia baru yang indah yang kami sukai. Semuanya sederhana di sana - ada tim untuk migrasi dan dua opsi penting:
virsh migrate <vm> qemu+ssh://<hypervisor>/system --undefinesource -persistent
Jika Anda mengetik "migrasi KVM" di Google dan membuka materi pertama, Anda akan melihat perintah untuk migrasi, tetapi tanpa dua kunci terakhir. Anda tidak akan melihat disebutkan bahwa itu penting: "Eksekusi saja perintah ini!" Jalankan perintah - dan itu benar-benar bermigrasi, tetapi hanya bagaimana caranya?
Opsi migrasi penting.
undefinesource - lepaskan mesin virtual dari hypervisor tempat kami bermigrasi. Jika Anda me-reboot setelah migrasi seperti itu, maka hypervisor yang Anda tinggalkan akan memulai kembali mesin ini. Anda akan terkejut, tetapi ini normal.
Tanpa parameter kedua - persisten - hypervisor tempat Anda pindah sama sekali tidak menganggap ini sebagai migrasi permanen. Setelah reboot, hypervisor tidak akan mengingat apa pun.
- virsh dominfo <vm> | grep persistent
Tanpa parameter ini, mesin virtual adalah lingkaran di atas air. Jika parameter pertama ditentukan tanpa parameter kedua, maka tebak apa yang akan terjadi.
Ada banyak momen seperti itu dengan KVM.
- Jaringan: mereka selalu memberi tahu Anda tentang jembatan - itu mimpi buruk! Anda membaca dan berpikir - bagaimana bisa ?!
- Migrasi: mereka juga tidak akan mengatakan sesuatu yang masuk akal, sampai Anda memukul kepala Anda di dinding ini.
Di mana untuk memulai?
Untuk memulai terlambat - saya sedang berbicara tentang sesuatu yang lain.
Provisioning: bagaimana cara menggunakannya
Jika Anda puas dengan opsi instalasi standar, mekanisme yang dipra-prakan sangat bagus.
Di bawah ESXi, kami menggunakan virt-install. Ini adalah cara biasa untuk menggunakan mesin virtual. Lebih mudah karena Anda membuat file preseed di mana Anda menggambarkan gambar Debian / Ubuntu Anda. Mulai mesin baru dengan mengumpankannya kit distribusi ISO dan file preseed. Kemudian mobil itu berputar sendiri. Anda terhubung ke sana melalui SSH, kaitkan ke koki, roll cookie - itu saja, buru-buru ke prod!
Tetapi jika Anda memiliki cukup menginstal kebajikan, saya punya kabar buruk. Ini berarti bahwa Anda belum mencapai tahap ketika Anda ingin melakukan sesuatu yang lain. Kami berhasil dan menyadari bahwa menginstal kebajikan tidak cukup. Kami sampai pada beberapa "gambar emas", yang kami kloning dan kemudian meluncurkan mesin virtual.
Dan bagaimana cara mengatur mesin virtual?
Mengapa kita sampai pada gambar ini, dan mengapa penyediaan itu penting? Karena masih ada pemahaman yang lemah di masyarakat bahwa ada perbedaan besar antara mesin virtual dan mesin biasa.
Mesin virtual tidak perlu proses boot yang rumit dan bootloader yang pintar . Jauh lebih mudah untuk melampirkan disk mesin virtual ke mesin yang memiliki seperangkat alat lengkap daripada dalam mode pemulihan mencoba keluar di suatu tempat.
Mesin virtual membutuhkan kesederhanaan suatu perangkat . Mengapa saya perlu partisi pada disk virtual? Mengapa orang mengambil disk virtual dan meletakkan partisi di sana, bukan LVM?
Mesin virtual membutuhkan ekstensibilitas maksimum . Biasanya mesin virtual tumbuh. Ini adalah proses "keren" - meningkatkan partisi di MBR. Anda menghapusnya, pada saat itu menghapus keringat dari dahi Anda dan berpikir: "Jangan menulis sekarang, hanya saja tidak menulis!" - dan buat ulang dengan parameter baru.
LVM @ lilo
Hasilnya, kami datang ke LVM @ lilo. Ini adalah bootloader yang memungkinkan Anda untuk mengonfigurasi dari satu file. Jika untuk mengedit konfigurasi GRUB Anda sedang mengedit file khusus yang mengontrol mesin template dan membuat boot.cfg, lalu dengan Lilo - satu file, dan tidak lebih.
LVM tanpa partisi menjadikan sistem sempurna dan mudah. Masalahnya adalah bahwa GRUB tidak dapat hidup tanpa MBR atau GPT dan itu membeku. Kami memberitahunya: "GRUB menetap di sini," tetapi dia tidak bisa, karena tidak ada partisi.
LVM memungkinkan Anda untuk dengan cepat memperluas dan membuat cadangan. Dialog standar:
- Guys, bagaimana Anda melakukan backup virtual?- ... kami mengambil perangkat blok dan menyalin.- Sudahkah Anda mencoba mengerahkan kembali?- Yah, tidak, semuanya bekerja untuk kita!Anda dapat menjilat perangkat blok di mesin virtual kapan saja, tetapi jika ada sistem file, maka catatan apa pun di dalamnya memerlukan tiga gerakan - prosedur ini bukan atom.
Jika Anda melakukan snapshot dari mesin virtual dari dalam, maka ia dapat berbicara dengan sistem file sehingga datang ke kondisi konsisten yang diinginkan. Tapi ini tidak cocok untuk semuanya.
Bagaimana cara membuat wadah?
Untuk memulai dan membuat wadah, ada alat biasa dari template. LXD menawarkan template Ubuntu 16.04 atau 18.04. Tetapi jika Anda seorang pejuang tingkat lanjut dan tidak menginginkan templat biasa, tetapi rootf kustom Anda, yang dapat Anda sesuaikan sendiri, muncul pertanyaan: bagaimana membuat wadah dari awal di LXD?
Wadah dari awal
Mempersiapkan rootfs . Debootstrap akan membantu dengan ini: kami menjelaskan paket mana yang dibutuhkan, mana yang tidak, dan instal.
Jelaskan kepada LXD bahwa kami ingin membuat wadah dari rootfs tertentu . Tapi pertama-tama, buat wadah kosong dengan perintah pendek:
curl --unix-socket /var/lib/lxd/unix.socket -X POST -d '{"name": "my-container", "source": {"type": "none"}}' lxd/1.0/containers
Ia bahkan bisa otomatis.
Seorang pembaca yang bijaksana akan mengatakan - di mana rootfs-wadah saya? Di mana itu ditunjukkan di tempat apa? Tapi saya tidak mengatakan itu saja!
Kami memasang rootfs dari wadah di mana ia akan tinggal. Kemudian kami mengindikasikan bahwa wadah rootfs akan tinggal di sini:
lxc config set my-container raw.lxc "lxc.rootfs=/containers/my-container/rootfs"
Sekali lagi ini otomatis.
Kehidupan kontainer
Kontainer tidak memiliki kernel sendiri , jadi memuatnya lebih mudah
: systemd, init, dan terbang!
Jika Anda tidak menggunakan alat biasa untuk bekerja dengan LVM, maka dalam kebanyakan kasus, untuk memulai wadah, Anda harus memasang rootfs wadah di hypervisor.
Saya terkadang menemukan artikel yang memberi tahu autof. Jangan lakukan itu. Systemd memiliki unit automount yang berfungsi, tetapi autof tidak. Oleh karena itu, unit automount systemd dapat dan harus digunakan, tetapi autof tidak sepadan.
Kesimpulan
Kami menyukai KVM dengan migrasi . Dengan LXD, ini belum seperti itu, meskipun untuk menguji dan membangun infrastruktur kami menggunakannya di mana tidak ada beban produksi.
Kami menyukai kinerja KVM . Lebih akrab untuk melihat di atas, melihat ada proses yang relevan dengan mesin virtual ini, dan memahami siapa dan apa yang kita lakukan. Ini lebih baik daripada menggunakan satu set utilitas aneh dengan wadah untuk mencari tahu apa jenis ketukan bawah air yang ada.
Kami senang dengan migrasi. Ini sebagian besar disebabkan oleh penyimpanan bersama. Jika kami bermigrasi dengan menyeret disk, kami tidak akan senang.
Jika Anda, seperti Leo, siap untuk berbicara tentang mengatasi kesulitan operasi, integrasi atau dukungan, maka sekarang adalah waktu untuk mengirimkan laporan ke konferensi DevOpsConf musim gugur. Dan kami dalam komite program akan membantu mempersiapkan presentasi yang menginspirasi dan berguna yang sama dengan ini.
Kami tidak menunggu batas waktu Panggilan untuk Makalah dan telah menerima beberapa laporan ke program konferensi. Berlangganan buletin dan saluran telegram dan dapatkan berita terbaru tentang persiapan untuk DevOpsConf 2019 dan jangan lewatkan artikel dan video baru.