Fórum Root.cz
Hlavní témata => Server => Téma založeno: FAT32 01. 03. 2021, 22:43:41
-
Zdravím jak virtualizovat efektivně a s co nejmenší chybovostí fyzicky server na, kterém je mdadm raid 1?
Virtuální server by měl být tradiční QEMU virtuál v proxmoxu.
Níže je detailní info:
mount | grep '^/dev'
/dev/md2 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
/dev/md0 on /boot type ext4 (rw,relatime,data=ordered)
mdadm --query --detail /dev/md{0,2}
/dev/md0:
Version : 1.2
Creation Time : Thu Aug 23 20:10:05 2018
Raid Level : raid1
Array Size : 975296 (952.44 MiB 998.70 MB)
Used Dev Size : 975296 (952.44 MiB 998.70 MB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Sun Feb 7 00:57:06 2021
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : dir2:0
UUID : 1da015d3:c3443291:f4b63363:aec59730
Events : 159
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
/dev/md2:
Version : 1.2
Creation Time : Thu Aug 23 20:10:25 2018
Raid Level : raid1
Array Size : 217697280 (207.61 GiB 222.92 GB)
Used Dev Size : 217697280 (207.61 GiB 222.92 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Feb 24 01:02:48 2021
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : dir2:2
UUID : 148bd7a9:a17e9e6e:d002c2d0:d7806567
Events : 6779
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
/etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/md2 during installation
UUID=7963eac4-4af8-4f02-8091-30887c83a10d / ext4 errors=remount-ro 0 1
# /boot was on /dev/md0 during installation
UUID=b50673a9-beeb-46c5-accf-45778ebe6512 /boot ext4 defaults 0 2
# swap was on /dev/md1 during installation
UUID=35e6df63-d091-4db4-88a5-5636a1fea96b none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
nfs defaults 0 0
dir2.host.tld:/mnt/bacula /mnt/bacula nfs defaults 0 0
-
Já tedy nechápu otázku...
-
Zrušit RAID a virtualizovat bez RAIDu (přičemž tuto funkcionalitu - odolnost proti výpadku jednoho disku - převezme systém poskytující virtualizaci).
Protože se ale ptáš, tak nejspíš z nějakého důvodu RAID zrušit nelze (za normální okolností by stačilo změnit to ve fstabu a přegenerovat initramdisk, případně konfiguraci grubu). K tomu budeš muset poskytnout více informací, abychom věděli, jaká řešení připadají v úvahu. Možnosti zahrnují například:
- rozpojit ty dva disky a provozovat ve virtuálu raid trvale degradovaný (s tím že opět bude odolnost proti selhání zajištěna zvenku)
- provozovat raid tak jak je, a virtuálu poskytnout dvě disková zařízení. K tomu je potřeba vědět, jak hostitel má vyřešené disky, tj. jestli toto lze udělat efektivně (na většině mnou provozovaných strojů by to nešlo, protože dělám RAID přes celý disk, takže by se musel nějak složitě zmenšovat), případně zda neefektivita nevadí (např. se jedná o počítač který jednou za půl hodiny zpracuje malý kousek dat)
-
md0 vytvoreno v 2018, co je za probem nainstalovat novy PVE virtual s odpovidajici verzi OS a pak rsyncnout disky, upravit grub/initramfs/network?
-
md0 vytvoreno v 2018, co je za probem nainstalovat novy PVE virtual s odpovidajici verzi OS a pak rsyncnout disky, upravit grub/initramfs/network?
Jako natvrdo hodit rsync na / a přehoupnout to na cílový server?
Každopádně problém to asi není, já server ještě nevirtualizoval, kort server s RAID 1, takže sbírám informace od zkušenější :)
-
Napadlo mě totéž, co _Jendu. Degradovaný raid ve virtualizovaném prostředí a/nebo víc virtudálních disků.
Ale vlastně si nejsem jistý, jak chápe otázku sám tazatel. V jakém smyslu je míněna efektivita? Že virtualizace nesebere zbytečně prostor na discích? Nebo že nepoběží raid na hostitelském systému a nad ním ještě další raid ve virtualizovaném prostředí? Nebo to znamená, že lze snadno a efektivně přenést z (třeba testovacího) virtuálního prostředí serveru nastavení/data/aplikace/služby do původního? Nebo by ku příkladu bylo cílem povýšit ve virtuálním prostředí verzi systému a vyzkoušet běh potřebných služeb tam? Podle zadání se budou lišit i odpovědi.
-
Řeším stejný problém. Převod P2V (Physical-to-Virtual).
Zatím nedál jsem se dostal s nástrojem Clonezilla
petr@maxbox:~$ sudo fdisk -l | grep Disk
Disk /dev/md0: 93.1 GiB, 99931389952 bytes, 195178496 sectors
Disk /dev/md2: 7.5 GiB, 7995392000 bytes, 15616000 sectors
Disk /dev/md1: 1.7 TiB, 1892264443904 bytes, 3695828992 sectors
Cílové prostředí virtual server na ProxMox.
https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE
-
ja bych to řešil tak jak to tady někdo nademnou navrhoval.
čistý virtuál s jedním virtuálním diskem
boot nějakého liveCD (rescueCD), na disk tam nadelat partitiony, a rsyncnout všechno z fyzického serveru.
pak chroot, zmenit tam ve fstab device, pregenerovat ramdisk, nainstalovat grub a hotovo
-
A co vlastne na tom serveru bezi? Proc se resi jen migrace zelezo -> VM. Proc to neresit na aplikacni urovni? Jestli by treba nebylo lepsi (levnejsi) to provozovat na Proxmox v LXC? Ci treba i v dnes popularnich kontejnerech (docker/docker-compose)? Chapu, ze je to pracnejsi nez jen copy-paste, ale z pohledu budouci spravy to pak bude jednodussi.
-
Jestli by treba nebylo lepsi (levnejsi) to provozovat na Proxmox v LXC? Ci treba i v dnes popularnich kontejnerech (docker/docker-compose)? Chapu, ze je to pracnejsi nez jen copy-paste, ale z pohledu budouci spravy to pak bude jednodussi.
LXC je naopak ještě jednodušší než migrace do plné virtualizace, protože neřešíš filesystém, initramdisk a zavlekač, stačí jen zkopírovat rootfs a ono to samo spustí init. Ale narazí pokud to má nějaký víc lowlevel přístup (nestandardní iptables moduly, možná TAP VPN, nedejbože custom jaderný modul).
Rozdělení na mnoho kontejnerů ve stylu dockeru mi osobně na správu jednodušší nepřijde, YMMV.
-
Rozdělení na mnoho kontejnerů ve stylu dockeru mi osobně na správu jednodušší nepřijde, YMMV.
Je otazka, co tam provozujes. Muze byt jednodussi a nemusi... Moderni aplikace, ktere pocitaji s behem v kontejneru jsou urcite jednodussi (referencujes jiz nekym vytvoreny kontejner, podstrcis konfiguraci a muzem jet). Starsi, ktere musis rucne kontejnerizovat a vse okolo, urcite tak jednoduche nebudou. Proto jsem se ptal, co tam bezi...
Abych byl kontrejnejsi. Tak nektere aplikace, ktere doma provozuji jsem mel puvodne jako programy spoustene pres systemd a pristupoval na ne pres nginx. Sprava trosku slozitejsi a pridavani novych manualni prace. Po nastaveni docker-compose a traefik mi staci jen dopsat par radek do .yaml, spravne nastavit a vse funguje tak nejak samo. Upgrade trivialni, kdy se stahnout nove verze kontejneru a spusti. Pravda, produkcni prostredi nemusi byt tak jednoduche, ale i tak mi to prijde (po pocatecnim nastaveni) jako mnohem jednodussi na udrzbu. Ale jak pises YMMV. :)
-
Podrobný popis a video mého úspěšného převodu P2V RAID1 (virtuálka běží na ProxMox).
https://petr.maxbox.cz/index.php/2021/03/14/raid1-ubuntu-16-04-p2v-physical-to-virtual-conversion-using-clonezilla-ubuntu-16-04/ (https://petr.maxbox.cz/index.php/2021/03/14/raid1-ubuntu-16-04-p2v-physical-to-virtual-conversion-using-clonezilla-ubuntu-16-04/)
Snad to pomůže