Mungkin setiap orang yang setidaknya pernah dibuat bingung oleh pencarian penyimpanan berdefinisi perangkat lunak berkinerja tinggi, cepat atau lambat, mendengar tentang DRBD , atau bahkan mungkin menanganinya.
Benar, di puncak popularitas Ceph dan GlusterFS , yang pada prinsipnya bekerja dengan sangat baik, dan yang paling penting langsung di luar kotak, semua orang hanya lupa sedikit tentang itu. Selain itu, versi sebelumnya tidak mendukung replikasi ke lebih dari dua node, dan karena ini, masalah dengan split-brain sering dijumpai, yang jelas tidak menambah popularitasnya.
Solusinya benar-benar bukan hal baru, tetapi cukup kompetitif. Dengan biaya yang relatif rendah untuk CPU dan RAM, DRBD menyediakan sinkronisasi yang sangat cepat dan aman di tingkat perangkat blok . Selama ini, pengembang LINBIT - DRBD tidak diam dan terus-menerus memperbaikinya. Dimulai dengan versi DRBD9 , tidak lagi menjadi cermin jaringan dan menjadi sesuatu yang lebih.
Pertama, gagasan untuk membuat perangkat blok terdistribusi tunggal untuk beberapa server telah surut ke latar belakang, dan sekarang LINBIT sedang mencoba untuk menyediakan alat untuk mengatur dan mengelola banyak perangkat drbd dalam sebuah cluster yang dibuat di atas partisi LVM dan ZFS .
Misalnya, DRBD9 mendukung hingga 32 replika, RDMA, node tanpa disk, dan alat orkestrasi baru memungkinkan Anda untuk menggunakan snapshot, migrasi online, dan banyak lagi.
Terlepas dari kenyataan bahwa DRBD9 memiliki alat integrasi dengan Proxmox , Kubernetes , OpenStack dan OpenNebula , saat ini mereka berada dalam beberapa mode transisi, ketika alat baru belum didukung di mana-mana, dan yang lama akan segera diumumkan sebagai usang . Ini adalah DRBDmanage dan Linstor .
Saya akan memanfaatkan momen ini untuk tidak terlalu banyak membahas masing-masing, tetapi untuk memeriksa lebih detail konfigurasi dan prinsip kerja dengan DRBD9 itu sendiri. Anda masih harus mencari tahu, jika hanya karena konfigurasi toleran dari pengontrol Linstor menyiratkan menginstalnya pada salah satu perangkat ini.
Pada artikel ini, saya ingin memberi tahu Anda tentang DRBD9 dan kemungkinan penggunaannya di Proxmox tanpa plug-in pihak ketiga.
DRBDmanage and Linstor
Pertama, perlu disebutkan sekali lagi tentang DRBDmanage , yang terintegrasi dengan sangat baik dalam Proxmox . LINBIT menyediakan plugin DRBDmanage yang sudah jadi untuk Proxmox yang memungkinkan Anda untuk menggunakan semua fungsinya secara langsung dari antarmuka Proxmox .
Ini terlihat sangat menakjubkan, tetapi sayangnya memiliki beberapa kelemahan.
- Pertama, nama volume yang ditandai, grup LVM, atau kumpulan ZFS harus bernama
drbdpool . - Ketidakmampuan untuk menggunakan lebih dari satu kumpulan per node
- Karena spesifik dari solusi, volume pengontrol hanya dapat pada LVM biasa dan tidak sebaliknya
- Gangguan dbus periodik, yang digunakan secara erat oleh DRBDmanage untuk berinteraksi dengan node.
Akibatnya, LINBIT memutuskan untuk mengganti semua logika DRBDmanage yang kompleks dengan aplikasi sederhana yang berkomunikasi dengan node menggunakan koneksi tcp biasa dan bekerja tanpa sihir di sana. Jadi ada Linstor .
Linstor benar-benar bekerja dengan sangat baik. Sayangnya, pengembang memilih java sebagai bahasa utama untuk menulis Linstor-server, tetapi jangan biarkan ini membuat Anda takut, karena Linstor sendiri hanya peduli dengan mendistribusikan konfigurasi DRBD dan mengiris partisi LVM / ZFS pada node.
Kedua solusi ini gratis dan didistribusikan di bawah lisensi GPL3 gratis .
Anda dapat membaca tentang masing-masing dari mereka dan tentang menyiapkan plug-in untuk Proxmox tersebut di wiki Proxmox resmi
Failover NFS Server
Sayangnya, pada saat penulisan, Linstor hanya memiliki integrasi dengan Kubernetes . Tetapi pada akhir tahun, driver diharapkan untuk sisa sistem Proxmox , OpenNebula , OpenStack .
Namun sejauh ini tidak ada solusi yang siap pakai, tetapi kami entah bagaimana tidak menyukai yang lama. Mari kita coba gunakan DRBD9 cara kuno untuk mengatur akses NFS ke partisi bersama.
Namun demikian, solusi ini juga akan terbukti bukan tanpa keuntungan, karena server NFS akan memungkinkan Anda untuk mengatur akses kompetitif ke sistem file repositori dari beberapa server tanpa perlu sistem file cluster kompleks dengan DLM, seperti OCFS dan GFS2.
Dalam hal ini, Anda akan dapat mengganti peran simpul Primer / Sekunder hanya dengan memigrasikan wadah dengan server NFS di antarmuka Proxmox.
Anda juga dapat menyimpan file apa pun di dalam sistem file ini, serta disk dan cadangan virtual.
Jika Anda menggunakan Kubernetes, Anda dapat mengatur akses ReadWriteMany untuk PersistentVolumes Anda.
Wadah Proxmox dan LXC
Sekarang pertanyaannya adalah: mengapa Proxmox?
Pada prinsipnya, untuk membangun skema seperti itu, kita bisa menggunakan Kubernetes serta skema biasa dengan manajer klaster. Tetapi Proxmox menyediakan antarmuka yang siap pakai, sangat multi-fungsi dan pada saat yang sama sederhana dan intuitif untuk hampir semua yang Anda butuhkan. Itu di luar kotak yang mampu mengelompokkan dan mendukung mekanisme pagar berdasarkan softdog. Dan saat menggunakan wadah LXC, ini memungkinkan Anda untuk mencapai batas waktu minimal saat beralih.
Solusi yang dihasilkan tidak akan memiliki satu titik kegagalan .
Faktanya, kita akan menggunakan Proxmox terutama sebagai klaster-manajer , di mana kita dapat mempertimbangkan wadah LXC terpisah sebagai layanan yang berjalan di kluster HA klasik, hanya dengan perbedaan bahwa wadah tersebut juga dilengkapi dengan sistem akarnya . Artinya, Anda tidak perlu menginstal beberapa instance layanan pada setiap server secara terpisah, Anda dapat melakukan ini hanya sekali di dalam wadah.
Jika Anda pernah bekerja dengan perangkat lunak cluster-manager dan menyediakan HA untuk aplikasi, Anda akan mengerti apa yang saya maksud.
Skema umum
Solusi kami akan menyerupai skema replikasi standar dari suatu basis data.
- Kami memiliki tiga node
- Setiap node memiliki perangkat drbd terdistribusi.
- Perangkat ini memiliki sistem file biasa ( ext4 )
- Hanya satu server yang bisa menjadi master
- Server NFS di wadah LXC diluncurkan pada wizard.
- Semua node mengakses perangkat secara ketat melalui NFS.
- Jika perlu, wizard dapat pindah ke node lain, bersama dengan server NFS
DRBD9 memiliki satu fitur yang sangat keren yang sangat menyederhanakan segalanya:
Perangkat drbd secara otomatis menjadi Utama pada saat dipasang pada beberapa node. Jika perangkat ditandai sebagai Utama , setiap upaya untuk memasangnya pada simpul lain akan menghasilkan kesalahan akses. Ini memastikan pemblokiran dan jaminan perlindungan terhadap akses simultan ke perangkat.
Mengapa semua ini sangat disederhanakan? Karena ketika wadah mulai, Proxmox secara otomatis me- mount perangkat ini dan itu menjadi Primer pada node ini, dan ketika kontainer berhenti, itu unmount itu sebaliknya dan perangkat menjadi Sekunder lagi.
Dengan demikian, kita tidak perlu lagi khawatir beralih perangkat Primer / Sekunder , Proxmox akan melakukannya secara otomatis , Hore!
Pengaturan DRBD
Ya, kami sudah menemukan ide. Sekarang mari beralih ke implementasi.
Secara default , versi kedelapan dari drbd disertakan dengan kernel Linux , sayangnya itu tidak cocok untuk kita dan kita perlu menginstal versi kesembilan dari modul.
Hubungkan repositori LINBIT dan instal semua yang Anda butuhkan:
wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add - echo "deb http://packages.linbit.com/proxmox/ proxmox-5 drbd-9.0" \ > /etc/apt/sources.list.d/linbit.list apt-get update && apt-get -y install pve-headers drbd-dkms drbd-utils drbdtop
pve-headers - pve-headers kernel diperlukan untuk membangun moduldrbd-dkms - modul kernel dalam format DKMSdrbd-utils - utilitas manajemen DRBD dasardrbdtop adalah alat interaktif seperti top untuk DRBD saja
Setelah menginstal modul, kami akan memeriksa apakah semuanya sudah sesuai dengan itu:
Jika Anda melihat versi kedelapan di output perintah, maka ada yang tidak beres dan modul kernel in-tree dimuat. Periksa dkms status mencari tahu apa alasannya.
Setiap node yang kita miliki akan memiliki perangkat drbd yang sama berjalan di atas partisi reguler. Pertama kita perlu menyiapkan bagian ini untuk drbd pada setiap node.
Partisi seperti itu dapat berupa perangkat blok apa saja, dapat berupa lvm, zvol, partisi disk, atau keseluruhan disk. Pada artikel ini saya akan menggunakan disk nvme terpisah dengan partisi di bawah drbd: /dev/nvme1n1p1
Perlu dicatat bahwa nama perangkat cenderung berubah kadang-kadang, jadi lebih baik untuk segera menganggapnya sebagai kebiasaan untuk menggunakan symlink konstan ke perangkat.
Anda dapat menemukan symlink untuk /dev/nvme1n1p1 dengan cara ini:
Kami menggambarkan sumber daya kami pada ketiga simpul:
Dianjurkan untuk menggunakan jaringan terpisah untuk sinkronisasi drbd.
Sekarang buat metadata untuk drbd dan jalankan:
Ulangi langkah-langkah ini pada ketiga node dan periksa status:
Sekarang disk tidak konsisten kami ada di ketiga node, ini karena drbd tidak tahu disk mana yang harus diambil seperti aslinya. Kita harus menandai salah satunya sebagai Primer agar statusnya disinkronkan ke node lain:
drbdadm primary --force nfs1 drbdadm secondary nfs1
Segera setelah ini, sinkronisasi akan dimulai:
Kita tidak harus menunggu sampai selesai dan kita bisa melakukan langkah lebih lanjut secara paralel. Mereka dapat dieksekusi pada sembarang simpul , terlepas dari keadaan saat ini dari disk lokal di DRBD. Semua permintaan akan secara otomatis dialihkan ke perangkat dengan status UpToDate .
Jangan lupa untuk mengaktifkan autorun layanan drbd pada node:
systemctl enable drbd.service
Mengkonfigurasi wadah LXC
Kami akan menghilangkan bagian konfigurasi dari cluster Proxmox yang terdiri dari tiga simpul, bagian ini dijelaskan dengan baik di wiki resmi
Seperti yang saya katakan sebelumnya, server NFS kami akan bekerja dalam wadah LXC . Kami akan menyimpan wadah di perangkat /dev/drbd100 yang baru saja kami buat.
Pertama kita perlu membuat sistem file di atasnya:
mkfs -t ext4 -O mmp -E mmp_update_interval=5 /dev/drbd100
Proxmox secara default mencakup perlindungan multimount di tingkat sistem file, pada prinsipnya, kita dapat melakukannya tanpa itu, karena DRBD memiliki perlindungan sendiri secara default, itu hanya melarang Primary kedua untuk perangkat, tetapi hati-hati tidak melukai kita.
Sekarang unduh templat Ubuntu:
# wget http://download.proxmox.com/images/system/ubuntu-16.04-standard_16.04-1_amd64.tar.gz -P /var/lib/vz/template/cache/
Dan buat wadah kami dari itu:
pct create 101 local:vztmpl/ubuntu-16.04-standard_16.04-1_amd64.tar.gz \ --hostname=nfs1 \ --net0=name=eth0,bridge=vmbr0,gw=192.168.1.1,ip=192.168.1.11/24 \ --rootfs=volume=/dev/drbd100,shared=1
Dalam perintah ini, kami menunjukkan bahwa sistem root dari wadah kami akan ada di perangkat /dev/drbd100 dan menambahkan parameter shared=1 untuk memungkinkan migrasi kontainer di antara node.
Jika terjadi kesalahan, Anda selalu dapat memperbaikinya melalui antarmuka Proxmox atau di /etc/pve/lxc/101.conf wadah
Proxmox akan membongkar templat dan menyiapkan sistem root wadah untuk kami. Setelah itu kita bisa meluncurkan wadah kita:
pct start 101
Konfigurasikan server NFS.
Secara default, Proxmox tidak mengizinkan server NFS berjalan di dalam wadah, tetapi ada beberapa cara untuk mengaktifkannya.
Salah satunya adalah dengan menambahkan lxc.apparmor.profile: unconfined pada /etc/pve/lxc/100.conf .
Atau kita dapat mengaktifkan NFS untuk semua kontainer secara berkelanjutan, untuk ini kita perlu memperbarui template standar untuk LXC pada semua node, tambahkan baris berikut ke /etc/apparmor.d/lxc/lxc-default-cgns :
mount fstype=nfs, mount fstype=nfs4, mount fstype=nfsd, mount fstype=rpc_pipefs,
Setelah perubahan, mulai ulang wadah:
pct shutdown 101 pct start 101
Sekarang mari kita masuk:
pct exec 101 bash
Instal pembaruan dan server NFS :
apt-get update apt-get -y upgrade apt-get -y install nfs-kernel-server
Buat ekspor :
echo '/data *(rw,no_root_squash,no_subtree_check)' >> /etc/exports mkdir /data exportfs -a
Pengaturan HA
Pada saat penulisan, proxmox HA-manager memiliki bug yang tidak memungkinkan wadah HA berhasil menyelesaikan pekerjaannya, sebagai akibatnya proses ruang-kernel dari server nfs yang tidak sepenuhnya terbunuh mencegah perangkat drbd meninggalkan meninggalkan Secondary . Jika Anda sudah mengalami situasi seperti itu, Anda tidak boleh panik dan hanya menjalankan killall -9 nfsd pada node di mana wadah diluncurkan dan kemudian perangkat drbd harus "melepaskan" dan itu akan pergi ke Sekunder .
Untuk memperbaiki bug ini, jalankan perintah berikut di semua node:
sed -i 's/forceStop => 1,/forceStop => 0,/' /usr/share/perl5/PVE/HA/Resources/PVECT.pm systemctl restart pve-ha-lrm.service
Sekarang kita dapat beralih ke konfigurasi HA-manager . Mari kita membuat grup HA terpisah untuk perangkat kita:
ha-manager groupadd nfs1 --nodes pve1,pve2,pve3 --nofailback=1 --restricted=1
Sumber daya kami hanya akan berfungsi pada node yang ditentukan untuk grup ini. Tambahkan wadah kami ke grup ini:
ha-manager add ct:101 --group=nfs1 --max_relocate=3 --max_restart=3
Itu saja. Sederhana bukan?
Bola nfs yang dihasilkan dapat langsung dihubungkan ke Proxmox untuk menyimpan dan menjalankan mesin dan wadah virtual lainnya.
Rekomendasi dan penyetelan
DRBD
Seperti yang saya sebutkan di atas, selalu disarankan untuk menggunakan jaringan terpisah untuk replikasi. Sangat disarankan untuk menggunakan adapter jaringan 10-gigabit , jika tidak, Anda akan mengalami kecepatan port.
Jika replikasi tampaknya cukup lambat, cobalah beberapa opsi untuk DRBD . Ini adalah konfigurasi, yang menurut saya optimal untuk jaringan 10G saya:
# cat /etc/drbd.d/global_common.conf global { usage-count yes; udev-always-use-vnr; } common { handlers { } startup { } options { } disk { c-fill-target 10M; c-max-rate 720M; c-plan-ahead 10; c-min-rate 20M; } net { max-buffers 36k; sndbuf-size 1024k; rcvbuf-size 2048k; } }
Anda dapat memperoleh informasi lebih lanjut tentang setiap parameter dari dokumentasi DRBD resmi.
Server NFS
Untuk mempercepat operasi server NFS, mungkin membantu untuk meningkatkan jumlah total menjalankan server NFS. Secara default - 8 , secara pribadi, ini membantu saya meningkatkan angka ini menjadi 64 .
Untuk mencapai ini, perbarui RPCNFSDCOUNT=64 parameter di /etc/default/nfs-kernel-server .
Dan restart daemon:
systemctl restart nfs-utils systemctl restart nfs-server
NFSv3 vs NFSv4
Tahu perbedaan antara NFSv3 dan NFSv4 ?
- NFSv3 adalah protokol tanpa kewarganegaraan, sebagai aturan, ia lebih baik mentolerir kegagalan dan pulih lebih cepat.
- NFSv4 adalah protokol stateful , ia bekerja lebih cepat dan dapat diikat ke port tcp tertentu, tetapi karena keberadaan negara itu lebih sensitif terhadap kegagalan. Ini juga memiliki kemampuan untuk menggunakan otentikasi menggunakan Kerberos dan banyak fitur menarik lainnya.
Namun, ketika Anda menjalankan showmount -e nfs_server , protokol NFSv3 digunakan. Proxmox juga menggunakan NFSv3. NFSv3 juga biasa digunakan untuk mengatur mesin boot jaringan.
Secara umum, jika Anda tidak memiliki alasan khusus untuk menggunakan NFSv4, coba gunakan NFSv3 karena tidak terlalu menyakitkan untuk kegagalan apa pun karena kurangnya status seperti itu.
Anda bisa memasang bola menggunakan NFSv3 dengan menentukan parameter -o vers=3 untuk perintah mount :
mount -o vers=3 nfs_server:/share /mnt
Jika mau, Anda dapat menonaktifkan NFSv4 untuk server sama sekali, untuk melakukan ini, tambahkan opsi --no-nfs-version 4 ke variabel --no-nfs-version 4 dan restart server, misalnya:
RPCNFSDCOUNT="64 --no-nfs-version 4"
iSCSI dan LVM
Demikian pula, daemon tgt reguler dapat dikonfigurasikan di dalam container, iSCSI akan menghasilkan kinerja yang jauh lebih tinggi untuk operasi I / O, dan container akan bekerja lebih lancar karena server tgt bekerja sepenuhnya di ruang pengguna.
Biasanya, LUN yang diekspor dipotong menjadi beberapa bagian menggunakan LVM . Namun, ada beberapa nuansa yang perlu dipertimbangkan, misalnya: bagaimana kunci LVM disediakan untuk berbagi grup yang diekspor pada banyak host.
Mungkin ini dan nuansa lain yang akan saya jelaskan di artikel selanjutnya .