Dotaz: NFS4 exporty, jak to kruci (ne)funguje?

[MP]

Dotaz s diskusi je zde: https://forum.root.cz/index.php?topic=15231.msg207605;topicseen#new

Ve zkratce, nemuzu skloubit nastaveni tak, abych umoznil urcitym subnetum pristup do urcitych adresaru nfs serveru pres sec=sys a zaroven zablokoval pristup do vsech casti stromu (specialne /srv/nfs), pokud neni provedena krb5 autorizace.

Nevi nekdo? Idealni by zrejme bylo to bezet jako dva nezavisle nfs servery, ale nemam v soucasne situaci jak.

Odpovědi

[humanoid]

jeden normalny a druhy virtualny a basta...

[MP]

No, to nemam jak, to jsem zkousel. Virtualni NFS nad fyzickym NFS neni schopen fungovat pri zatezi. Asi by to muselo byt na blokovem zarizeni, ale do iscsi s lvm se mi moc nechce...

[Aleš Kapica]

Virtualni NFS nad fyzickym NFS neni schopen fungovat pri zatezi.

To je pěkná blbost…

[MP]

Zkousel jsem to. Ten virtualni nfs sel do kolen, zatez rostla do 40+ bez ohledu na pocet cpu cores/ram, iowaity rostly taky, disk byl saturovan na urovni hypervizoru. Na urovni uloziste se to stouralo v nose skoro. Jo. ten nfs server byl raw file.

[Aleš Kapica]

No, já měl spíš na mysli že je blbost provozovat NFS server nad NFS serverem. Až dodatečně jsem si uvědomil že to mohlo být také takto: jeden velký soubor sdílený přes, namountovaný přes loop a z něj pak sdílený obsah. Každopádně ať tak či tak problém je řešitelný na úrovni jednoho NFS serveru.

Především by mne ale zajímaly tři věci – co chcete docílit a proč. A jak vypadá soubor s exporty.

[Aleš Kapica]

Z toho co jsem se dočetl v diskuzi na tom rootu vidím, že ač nemáte kerberos nakonfigurován, přesto se ho snažíte použít. Což logicky fungovat nebude.

Druhá věc - exporty. Používáte sync - to bude děsně zpomalovat. A také se mi moc nezdá atribut subtree_check.

[Aleš Kapica]

Jo a teď jsem si všiml jedné věci co by mohla způsobovat ten problém na který jste se tam ptal – všimněte si, že jste nechal pro /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í.

[MP]

Tak postupne...

1] Ten fsid na subdir jsem jiz opravil, kazdy export ma nyni svuj vlastni.

2] sync...je to uloziste pro VM disky, takze async je mimo hru. V ramci testovani nfs4 navic ten rozdil nebyl zas tak velky.

3] krb5 jsem zkousel, to ze tam je, je jen v ramci testovani, pokud prece jen IPA nasadim znova

4] pouziti. No ma to dva ucely:

4a] uloziste pro obrazy VM, kde bych rad pouzil sec=sys, aby do toho kerberos nesahal

4b] uloziste pro data. Hodil by se mi taktez sec=sys pro overene hosty, nebot kdybych na to pouzil krb5, tak bych resil problem s tim, ze hodne sluzeb jede neinteraktivne, cili zadne tickety od krb5.

5] no a finalne problem je ten, ze pri sec=sys na /srv/nfs v NFS4 oproti NFS3 je pristup do celeho nfs stromu :( Coz prave pro ty klienty 4] bych rad mel blokovany, aby se nedostali do 4a].

[MP]

Jo, ten exports vypada ted takto:

/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.

[Aleš Kapica]

No. Přijde mi poněkud zvláštní, že máš definovaný export na /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)

[MP]

Ty dva exporty jsou proto, ze pocitam s 2 proxmox clustery. Pak by bylo napr. /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.

[Aleš Kapica]

Dva clustery? Proč? To mi moc nedává smysl.

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 klientu

No 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.

[MP]

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,

Jde o to, ze to uloziste je oddelene od hypervizoru, takze samotne drbd je na nic. To mame ted, dvounodove xen+drbd. A druhe uloziste samostatne pro data proste nemam, takze ted to musim mit vse na jednom NFS. GlusterFS bych na tuhle produkci nedal, to muzu pouzit tam, kde to nebude tak kriticke, nemluve o tom, ze fuse je pomale pro sdileni dat ve VM. A ceph zatim nerealny, nebot na to uloziste jsou jen dve zeleza.

[Aleš Kapica]

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.

[MP]

Ty to snad poradne nectes co pisu...

1] uloziste je oddelene od hypervizoru, takze lvm je mi taktez k nicemu, musel bych to tahat pres iscsi. To nfs uz nad drbd postavene je.

2] proxmox libgfapi umi pouzit, ale vykon byl porad pod vykonem nfs, navic velke databaze na tom nefunguji tak dobre

3] oddelene clustery byvaji i pojistka proti tomu, kdyz se rozsype samotny cluster. To neni jen o aktualizaci...

[Aleš Kapica]

Z toho co píšeš to afaik nevyplývá. Přesněji řečeno - vyplývá mi z toho, že úložiště je jeden dvounodový cluster, který řeší jenom poskytování dat pro budoucí virtualizační cluster o neznámém počtu nodů.

Oddělené clustery žádnou pojistkou nejsou, pokud nemají zajištěno že jsou k dispozici stejná data. Ovšem pak nutně přichází otázka - neporušila se jejich konzistence při rozsypání? Pojistkou proti rozsypání clusteru je nezávislá konektivita s druhým ringem. A v případě dvounodového clusteru s drbd pokud možno drát, který jde mimo aktivní prvky.

[MP]

Ano je to tak. 2 node cluster slouzici jako storage (HA nfs nad drbd). Sance,ze bych dostal dalsi masiny a mohl prejit na ceph je momentalne blizka nule.

Virtualizacni nody - mame 6-7 serveru, startujeme se 3. Zbytek, az se to osvedci, na to zmigruje. A je rozdil upgradovat treba proxmox4 na budouci proxmox5 v ramci jednoho velkeho clusteru. Taky jsem cetl dost pripadu, kdy doslo k poskozeni clusterove databaze, nebo chybe pri pridani stroje. To je pak hodne velky rozdil resit rozsypany cluster nebo dva. Kazdopadne, to je jine tema.

No, koukam, ze asi jedina moznost oddeleni na urovni nfs serveru by asi bylo nfs3, coz je ale hodne velky krok zpatky. Tak snad casem se najde reseni, jak presunout "datastore3" mimo primarni nfs server.