Portál AbcLinuxu, 18. července 2025 09:39
Virtualni NFS nad fyzickym NFS neni schopen fungovat pri zatezi.To je pěkná blbost…
/srv/nfs/export3/datastore3 stejné fsid jako pro /srv/nfs/export3/proxmox_vmstore3 to je dost zákeřná chyba, protože NFS server pak bude akceptovat jako první export pro který má toto fsid uvedené jako první.
/srv/nfs *(rw,fsid=0,sync,subtree_check,root_squash,crossmnt,sec=krb5:sys) /srv/nfs/export2/ X/24(rw,fsid=1,sync,subtree_check,no_root_squash,crossmnt,sec=krb5:sys) /srv/nfs/export3/ X/24(rw,fsid=2,sync,subtree_check,no_root_squash,crossmnt,sec=krb5:sys) /srv/nfs/export2/proxmox_vmstore2 X/24(rw,fsid=11,sync,subtree_check,no_root_squash,crossmnt,sec=krb5:sys) /srv/nfs/export3/proxmox_vmstore3 X/24(rw,fsid=21,sync,subtree_check,no_root_squash,crossmnt,sec=krb5:sys) /srv/nfs/export3/datastore3 Y/24(rw,fsid=3,sync,subtree_check,root_squash,crossmnt,sec=krb5:sys)export2/ a export3/ jsou dve samostatna datova pole.
/srv/nfs/export2/ a pak na /srv/nfs/export2/proxmox_vmstore2. Proč?
Navíc, když potřebuješ sdílet virtuální disky, proč máš definované dva exporty, když ti stačí jeden? A proč máš nastavený přístup pro celý subnet, když bys měl mít přístup povolený pouze pro ty virtualizační nody? U proxmoxu bych se na nějaký kerberos z vysoka vykašlal. Je to zbytečné. Navíc, QEMU umí jet rovnou z NFS:
qemu-system-x86_64 -daemonize … -device virtio-scsi-pci -drive file=nfs://mujnfsserver/koren_nfs/vitual-disc.img,if=none,index=0,id=nfs.0,cache=none,media=disk,format=raw -device scsi-hd,drive=nfs.0 …A export vypadá takto:
/koren_nfs \
nod1(rw,fsid=0,async,no_subtree_check,no_root_squash,crossmnt) \
nod2(rw,fsid=0,async,no_subtree_check,no_root_squash,crossmnt) \
nod3(rw,fsid=0,async,no_subtree_check,no_root_squash,crossmnt)
/srv/nfs/export2/proxmox_A_vmstore2 a /srv/nfs/export2/proxmox_B_vmstore2, aby ty clustery nemohly vzajemne sahnout na disky toho druheho (kvuli id vm/disku).
Navic, kdyz jsem mel jen:
/srv/nfs/export3/proxmox_vmstore3 X/24(rw,fsid=21,sync,subtree_check,no_root_squash,crossmnt,sec=krb5:sys)
tak ten proxmox do toho nespadl, ale spadl do nastaveni /srv/nfs ..., cili nemohl zapisovat jako root. Proto jsou tam ted ty dva exporty na zkousku, ale zrejme to nema fakt smysl, takze zustane jen ten /export{2,3}.
Nastaveny subnet mam pro to, abych limitoval pocet modifikaci exports...kdyz klekne proxmoxum pristup k nfs, tak klekne cela infra na tom postavena.
QEMU sice umi rovnou NFS (to jsem nevedel), ale Proxmox potrebuje mit nadefinovany uloziste, z ktereho bere disky, neumi nastavit NFS primo do VM.
Porad ale tu je zakladni problem, jak pro klienty pristupujici k datastore3 zabranit pristup k proxmox_vmstore{2,3}, pokud by nekdo remountul nfs na klientu.
QEMU sice umi rovnou NFS (to jsem nevedel), ale Proxmox potrebuje mit nadefinovany uloziste, z ktereho bere disky, neumi nastavit NFS primo do VM.No jo. Proto také nepoužívám Proxmox, ale rovnou corosync + pacemaker + vlastní agent kvm, který pracuje rovnou s qemu. Tam můžu nastavit co chci.
Porad ale tu je zakladni problem, jak pro klienty pristupujici k datastore3 zabranit pristup k proxmox_vmstore{2,3}, pokud by nekdo remountul nfs na klientuNo právě tím, že mají přístup povolen pouze virtualizační nody. Tam uživatelé nemají vůbec co dělat. A vůbec - kolik má být těch nodů? Má ti být symetrický, nebo asymetrický cluster? Jestli by nestálo za zvážení použít místo NFS DRBD (u dvounodového clusteru), nebo GlusterFS či Ceph.
Dva clustery, no, puvodne byl v planu jeden, ale je to spise taktika "nemit vse v jednom kosiku". Jednak je tu moznost upgradovat jeden cluster nezavisle na druhem, dale snizeni rizika, ze se zacnou stroje restartovat z duvodu vsemoznych problemu a hlavne, kdyz dojde k poskozeni clusterove db, tak je jednodussi prenest VM na druhy cluster nez mit celou infra shozenou. Startujeme s jednim, pak se proste uvidi, zda bude druhy nebo to bude jeden velky,Ale takhle se to nedělá. Od toho je to cluster, aby bylo možné postupně nody upgradovat aniž by tím došlo k nějaké újmě. Zrovna teď jsem to dělal. Tedy přesněji řečeno stále dělám, protože toho zároveň využívám abych mohl aktualizovat dokumentaci pro Pacemaker. Pokud chceš minimalizovat riziko, že ti bude do něčeho Pacemaker hrabat, je třeba při aktualizaci využívat režimu unmanaged a pak je zase postupně přepínat do stavu manage. Můj cluster je aktuálně čtyřnodový, p§vodně jich bylo pět, ale tři z těch strojů už mají natočeno víc jak osm let, takže míří postupně k odpisu. Ty dva jsem nechal zatím žít právě kvůli pokusům. U dvounodového clusteru toho moc nevymyslíš. Využívám ho v podstatě už pouze k virtualizaci – všechno je virtuální, včetně NFS serveru ze kterého jedou ostatní virtuály. Má to dost podstatné východy, na které třeba časem přijdeš. Ale nebudu tě zase tak napínat. Tou nejdůležitější je reboot. Virtuál ti – na rozdíl fyzického stroje – startuje ihned, takže prodleva u případného restartu je minimální. NFS klienti to většinou ustojí. I když to je pouze výjimečná situace – můj agent pracuje s živou migrací a nepotřebuje k tomu ani nějaký pitomý libvirt. U GlusterFS se nepoužívá FUSE. Qemu leze na ty virtuální disky blokově přes libgfapi. Ovšem jestli mohu radit, tak DRBD se nevzdávej. Ale vykašli se na NFS. Použij LVM a sestavuj si DRBD oddíly extra pro každý virtuál – je to nejspolehlivější! NFS má smysl leda že bys měl datové nody oddělené od virtualizačních. Oh pravda. Já zapoměl, že podporu libgfapi má pouze novější qemu a tak je nejlepší použít vlastní sestavení, ve kterém máš zakompilované všechno co potřebuješ. Ostatně z podobných důvodů si sestavuji i vlastní binární balík ve kterém mám corosync i pacemaker s crmsh pěkně pohromadě. Což ale není nic pro nezkušeného.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.