Dotaz: iSCSI & souborový systém

[Want]

Jaké máte zkušenosti?

---

---

Odpovědi

[xxl]

Doma na tom provozuji btrfs. A dobrý. Ale pravděpodobně tě zajímá nějaké větší nasazení.

[Want]

No, jak se to vezme. Nemám s ním (iSCSI) žádné zkušenosti a narazil jsem na problém, který by byl snadno řešitelný, kdybych měl k dispozici paralelní připojení nezávislé na hlavním switchi. Tak jak jsem to míval kdysi - jeden hloupý 1GB switch.

Centralizace sítě má své výhody, ale i značné nevýhody. Viz schéma dole. A případný síťový problém, který vyřadí na určitý čas přístup k iSCSI způsobí, že se souborový systém přemountuje do stavu read-only, kdežto u NFS se jen pozastaví.

Mám v hlavě několik možných řešení. Jednou z variant by mohlo být nasazení XFS, které by dočasnou nedostupnost sítě mohlo ustát, protože hodně využívá RAM a té mám poměrně dost. Jenom si nejsem jist jestli by se to po obnově síťové komunikace srovnalo, nebo ne.

Nejlepší řešení by byl sheepdog který byl na tohle ideální, jenže ten se už bohužel nevyvíjí.

[Kit]

XFS bych bez UPS neprovozoval. Trpká zkušenost.

[Max]

Z jaké doby? Není to ta chyba z roku asi 2006/2008, kterou dávno opravili a od té doby existuje tato nedůvěra?
Zdar Max

[X]

S mensim polem zadny problem, s vetsim radeji FC/FCoE. Zalezi o jakem HW a setupu se bavime. Podle otazky hadam o zadnem..

[Want]

Hádáš špatně. Setup je jasný. V disklessu jede docker, jenže ten neumí persistentní změny zapisovat přes NFS. iSCSI je řešení. Háček je v tom, že veškerá komunikace jde přes hlavní switch. A pokud ho někdo uvaří tím, že zasmyčkuje porty, vyhodnotí ten výpadek I/O FS jako chybu a přepne do read-only módu. Důsledky doufám vysvětlovat nemusím.

[X]

I ta tvoje 'sheepdog' mrtvola podporuje iSCSI. Preber si to v hlave a laskave nemichej low level protokol s nejakym block level problemem. Ptal jsi se na iSCSI. Pokud mas nejaky problem na vyzsi urovni nedavej hloupe otazky jako "ma nekdo zkusenosti z iSCSI". Jo nekdo ma. Debilni otazka = debilni odpoved.

[Want]

Ptal jsem se na iSCSI a FS. Objasnil jsem i proč. Z toho co píšeš o sheepdogu je zjevné, že o tom víš kulové, ale hraješ si chytráka.

[X]

Ne neptal:

Jaké máte zkušenosti?

Mam zkusenosti s nasazenim na stredne velke pole. Pomohlo? Asi ne. Zaloz novy dotaz a napis co konkretne resis za problem. Pak se muzeme bavit.

[Want]

To máš z toho, že nečteš titulek dotazu.

Problém, který řeším je dán podstatou iSCSI. Možná je i řešitelný nějakými parametry - to je to s čím nemám zkušenosti. U NFS, když nedostane klient data, pozastaví činnost, dokud server neodpoví. Čekal bych podobné chování. Jenomže iSCSI není FS. A souborový systém reaguje na problém tím, že se remountne do RO protože nemůže zapisovat, ale po obnově konektivity už se do původního stavu nevrátí. A je otázkou co vůbec s těmi daty dělá.

Před 13 lety, jsem u jednoho stroje přišel o data, protože měl do raidu přidaný špatný disk. Přidal ho tam kolega, který se překlepnul. Ale přišel jsem na to až o měsíc později, když po restartu stroj nenaběhnul. Od té doby jedu všechno diskless.

Kdyby ten docker akceptoval kontejnery sdílené přes NFS, tak jako singularity, bylo by to v pohodě. Jenže on si potřebuje splácat vlastní stack a to nad NFS nešlo. Proto jsem nadhodil otázku: "iSCSI & FS: Jaké máte zkušenosti?"

Já použil Btrfs, ale třeba jsou pro tenhle use case jiné FS vhodnější.

[X]

Jenomže iSCSI není FS.

Tim bych mozna zacal. iSCSI je protokol pro storage area network, SAN. Mam pole a misto toho abych ho bouchnul do serveru ho spristupnim po siti tak, aby vypadalo jako primo pripojene. Je te dedikovana infrastruktura bezici mimo "starndartni sit". Je to urcite to co potrebujes? Problem lidsky faktor, jako nekdo zapojil spatne kabel, nekdo pridal spatny disk ti iSCSI pomuze tak, ze pri multiplath to jeden vytzeny kabel nezabije a na SAN swich se vetsinou stejne nesaha. Pole ktera se iSCSI pripojuji, jsou liny level nez "kolega podelal raid" a vymenuji za jizdy bez problemu(nevim jak je to s polema co maj supliky zezhora..).

[Want]

Takové problémy bohužel vždy způsobuje lidský faktor. Tyhle problémy se začaly vyskytovat od chvíle, kdy se přešlo na Fortinet. Velká propustnost = velké problémy, které se hůř řeší - když ti vaří železo. Ale na druhou stranu, jsou na dálku řešitelné. A dočasně nedostupné iSCSI by nemělo vést k trvalé nedostupnosti služby.

[X]

Neco jako docasne nedostupne iSCSI, by vzhledem k 'multipath' a vysoke redundanci konektivity s polem vubec nemelo nastat. Takove pole ma vetsinou hned nekolik dualnich karet. Je to take jina trida zarizeni a neni to zrovna levne. Nicmene hadam by se to dalo postavit i "na kolene" na normalnim linux stroji, ovsem bude to dost studia a prace.

[RealJ]

Alesi, resis dusledek a ne pricinu. Pokud mas funkcni sit tak je uplne fuk co mas za fs. Ze ti nekdo umi zacyklit tvuj switch je problem admina toho switche. Spravne udelana sit se neposere u vytrhnuti nejakeho kabelu ze zdi nebo ze nekdo zastrci kabel ze switche zpatky do switche. Pokud se chces bavit konkretne, tak i dnes provozuji na iscsi apfs, provozoval jsem nad tim ext4 a bez problemu.

[Want]

Dík za odpověď. Jak už jsem tu několikrát zmínil, topologie není v mé kompetenci a řekl bych, že to jak vypadá je výsledkem mnoha kompromisů, protože narážíme na limity všude možně.

Jinak nechci nemožné, ale uznáš sám, že nelze situaci řešit tím, že začneš dělat maintainera opuštěného software, kvůli projektu co má běžet dva roky. Na druhou stranu ale nemůžeš dopustit, aby kvůli lidské chybě ten projekt přišel o nasbíraná data, na kterých staví.

Primární chyba je v tom, že ta aplikace, co to sbírá, se distribuuje zabalená v docker stacku.

[Heron]

V souboru /etc/iscsi/iscsid.conf je sekce:

### timeouts

## control how much time iscsi takes to propagate an error to the
## upper layer. if using multipath, having 0 here is desirable
## so multipath can handle path errors as quickly as possible
## (and decide to queue or not if missing all paths)

Tohle jsi zkoušel poladit?

S dostatečně dlouhým timeoutem by se to mělo chovat, jak chceš tzn. zápisy/čtení jen vytuhnou a měly by se rozeběhnout, až se komunikace obnoví.

Zdvojené síťové cesty mezi klientem a serverem taky dávají smysl, pokud to má fungovat spolehlivě.

A u toho Dockeru ti jde o to, aby vše běželo nad NFS nebo na NFS má být jen persistentní oddíl, který se připojí do kontejneru? Minimálně to druhé by jít mělo.

[Aleš Kapica]

Tohle jsi zkoušel poladit?

Nedošlo na to, ale něco takového bude nejspíš potřeba, takže díky.

Zdvojené síťové cesty mezi klientem a serverem taky dávají smysl, pokud to má fungovat spolehlivě.

To vím taky. Ale brekot Pavla Píši napoví, že strategii má v rukou někdo jiný. Ale možná, že jim zanedlouho dojde, že se vyplatí paralelizovat síť i služby, tak aby se nehonilo všechno jedním vláknem. Ovšem pro realizaci je nutné mít vše podchyceno a zrovna to není v rámci ČVUT, kde byli uživatelé zvyklí na vlastní pašalíky, jednoduché.

A u toho Dockeru ti jde o to, aby vše běželo nad NFS nebo na NFS má být jen persistentní oddíl, který se připojí do kontejneru? Minimálně to druhé by jít mělo.

Samozřejmě že to jde. Proto jsem taky nadhodil ten dotaz, abych mohl vybrat optimální konfiguraci. A teď už mohu být i konkrétní. Jde o stroj turtle. V době, kdy jsem položil tenhle dotaz, jsem teprve zjišťoval co a jak.

Je to stejný diskless jako v laborkách. Teda. Úplně stejný ne. Protože s rozsekanou distribuční vrstvou laborky pojedou až skončím s tímhle. U nás totiž platí, že se v průběhu semestru do produkčního systému nehrabe. Ale třeba někoho bude zajímat, čím se to liší od běžného disklesu. Vysvětlení k výpisu uvádím níže.

~# cat /run/sandwich
1 192.168.x.y:/srv/100/kernel/6.5.0
2 192.168.x.y:/srv/1090/xpra/docker
3 192.168.x.y:/srv/100/kernel/cli
4 192.168.x.y:/srv/1090/xpra/iscsi
5 192.168.x.y:/srv/206/config
6 192.168.x.y:/srv/1007/intel-gpu
7 192.168.x.y:/srv/1004/ldap
8 192.168.x.y:/srv/1002/turtle
~# cat /proc/partitions 
major minor  #blocks  name

  11        0          2 sr0
   8        0   31457280 sda
   8       16   31457280 sdb
~# docker ps
CONTAINER ID   IMAGE                                             COMMAND                  CREATED        STATUS                  PORTS                          NAMES
2749854db898   nats:2.1.9-alpine3.12                             "docker-entrypoint.s…"   17 hours ago   Up 17 hours (healthy)   4222/tcp, 6222/tcp, 8222/tcp   mindlamp_message_queue.1.tqur143q6pd4rka66o96cfhn4
f4e164881361   ghcr.io/bidmcdigitalpsychiatry/lamp-server:2023   "docker-entrypoint.s…"   17 hours ago   Up 17 hours (healthy)   3000/tcp                       mindlamp_server.1.jx98w0ayhnk6bt7lz6eep9so5
cbd746b59ecb   traefik:2.9                                       "/entrypoint.sh --lo…"   17 hours ago   Up 17 hours             80/tcp                         router_traefik.1.u7f7kn25p8y5xatki69s1fqa6
187c68af3a04   redis:6.0.8-alpine                                "docker-entrypoint.s…"   17 hours ago   Up 17 hours (healthy)   6379/tcp                       mindlamp_cache.1.5d87y4f7gz11uugeiaoyvcf95
98be0c649a6c   mongo:6.0.4                                       "docker-entrypoint.s…"   17 hours ago   Up 17 hours             27017/tcp                      mindlamp_database.1.eev3qg1tdxlheeoehzsiwr5vn
~# cat /proc/mounts     
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=4031876k,nr_inodes=1007969,mode=755,inode64 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,noexec,relatime,size=812536k,mode=755,inode64 0 0
none /overlay tmpfs rw,relatime,size=6282560k,inode64 0 0
overlay / overlay rw,relatime,lowerdir=/tmp/opt8:/tmp/opt7:/tmp/opt6:/tmp/opt5:/tmp/opt4:/tmp/opt3:/tmp/opt2:/tmp/opt1,upperdir=/tmp/unirw/over,workdir=/tmp/unirw/work 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,inode64 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k,inode64 0 0
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
efivarfs /sys/firmware/efi/efivars efivarfs rw,nosuid,nodev,noexec,relatime 0 0
bpf /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=649 0 0
tracefs /sys/kernel/tracing tracefs rw,nosuid,nodev,noexec,relatime 0 0
mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,nosuid,nodev,noexec,relatime 0 0
ramfs /run/credentials/systemd-firstboot.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
configfs /sys/kernel/config configfs rw,nosuid,nodev,noexec,relatime 0 0
ramfs /run/credentials/systemd-sysctl.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
ramfs /run/credentials/systemd-sysusers.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
ramfs /run/credentials/systemd-tmpfiles-setup-dev.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noexec,noatime,inode64 0 0
ramfs /run/credentials/systemd-tmpfiles-setup.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
sunrpc /run/rpc_pipefs rpc_pipefs rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
/dev/sda /var/lib/containerd btrfs rw,relatime,space_cache=v2,subvolid=258,subvol=/containerd 0 0
/dev/sda /var/lib/docker btrfs rw,relatime,space_cache=v2,subvolid=257,subvol=/docker 0 0
nsfs /run/docker/netns/ingress_sbox nsfs rw 0 0
nsfs /run/docker/netns/1-g9y94g2r4s nsfs rw 0 0
nsfs /run/docker/netns/lb_qrgrb5414 nsfs rw 0 0
nsfs /run/docker/netns/1-qrgrb5414r nsfs rw 0 0
nsfs /run/docker/netns/lb_od6i79t70 nsfs rw 0 0
nsfs /run/docker/netns/1-od6i79t70v nsfs rw 0 0
overlay /var/lib/docker/overlay2/6463897e24fd2a100ec285058fa24fd471e8af54d137e92acb827d49feaef8cd/merged overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/ZFPJCLQE2MW7AFISHXJ4H6MDXA:/var/lib/docker/overlay2/l/Q5DP2XS5JJFSBWPWDRSTP2RBHZ:/var/lib/docker/overlay2/l/BLQ5UQB2HLOWKDSYLUO5TKBUOV:/var/lib/docker/overlay2/l/3WM7VTKIGLYKVOH2EQYJXUY3H3:/var/lib/docker/overlay2/l/OHRCZQ4CDZ7O2QZR4HOGYBSQX5:/var/lib/docker/overlay2/l/BMKHPXXROUBSBN43HIFK6EIOLH:/var/lib/docker/overlay2/l/IZ2TFPE5ZDCJLUNP5WUS4WTT5F,upperdir=/var/lib/docker/overlay2/6463897e24fd2a100ec285058fa24fd471e8af54d137e92acb827d49feaef8cd/diff,workdir=/var/lib/docker/overlay2/6463897e24fd2a100ec285058fa24fd471e8af54d137e92acb827d49feaef8cd/work 0 0
overlay /var/lib/docker/overlay2/d128d1b8e02f0b07c248c5a86fdb3f6520f1355519949463dc776a8e42cb35c6/merged overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/WK3JSTRUL4B3T5TYJ6JIIJAE3N:/var/lib/docker/overlay2/l/6S54HZYSYO5O3VGVYAW6VXKDX3:/var/lib/docker/overlay2/l/T3MIXUPHBT4AD4VIELJL5MFFPN:/var/lib/docker/overlay2/l/LSH4X3QU4J7ESNPFUCIBYRAYCE:/var/lib/docker/overlay2/l/IKCDSMTE4NX432ZR4AJMU3S2V5:/var/lib/docker/overlay2/l/ZH3VF35Y7AAZUIGEDUD5QKOA3C:/var/lib/docker/overlay2/l/UPUNZ2V76WALHR4CMYT3WBYB5F:/var/lib/docker/overlay2/l/CU7ZNRUJNKHHDHQB2P6BQLD5WA:/var/lib/docker/overlay2/l/X6KSHBJ2ZM4H7K35EDQJLHFU27:/var/lib/docker/overlay2/l/4H4I2TI2OK5BHB6W37MMG4NCAT,upperdir=/var/lib/docker/overlay2/d128d1b8e02f0b07c248c5a86fdb3f6520f1355519949463dc776a8e42cb35c6/diff,workdir=/var/lib/docker/overlay2/d128d1b8e02f0b07c248c5a86fdb3f6520f1355519949463dc776a8e42cb35c6/work 0 0
overlay /var/lib/docker/overlay2/90166d6aaca5092c43c964f4cf0a77d91e041a4445cf089b1ef3fab683fc06d4/merged overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/BJU5Y6LVN4Y2HFYNX6HSBIHB4K:/var/lib/docker/overlay2/l/SPDRM5I5IYGLRK6XTKWM3HALTN:/var/lib/docker/overlay2/l/5PX7VHBH3WOKBHHLZ3TLMN7V6E:/var/lib/docker/overlay2/l/W27RF6GROD4TX23FQSHD2HMS4U:/var/lib/docker/overlay2/l/GWDDSRJTYDGQAOYCBJ4TQCXUKK,upperdir=/var/lib/docker/overlay2/90166d6aaca5092c43c964f4cf0a77d91e041a4445cf089b1ef3fab683fc06d4/diff,workdir=/var/lib/docker/overlay2/90166d6aaca5092c43c964f4cf0a77d91e041a4445cf089b1ef3fab683fc06d4/work 0 0
overlay /var/lib/docker/overlay2/499172ecc38729037253ad96d0e945bf0ba813af172860309efa074b26291306/merged overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/BJEM7NLS6QXO4DIWNWCNZRAFUJ:/var/lib/docker/overlay2/l/644GWHRNLFVGBBWYDRIGXOUL5U:/var/lib/docker/overlay2/l/ZLKFNA4GNHFN4NMU7V56IMCRTY:/var/lib/docker/overlay2/l/TVPZ2D3UH755QA4ZNJ3F4UVLYL:/var/lib/docker/overlay2/l/CP2SNIFF22MT2JWQOCQP24U4R6:/var/lib/docker/overlay2/l/4463R3LQ6JG6N4BJ3F74EM4LJI:/var/lib/docker/overlay2/l/XMIWWTVINGZXG27IRXREZVOL5X:/var/lib/docker/overlay2/l/3EPVECWHTSKJNNAWNT655P5G6Q:/var/lib/docker/overlay2/l/AANB7DPAMDASHYVUDRSOYMMFSQ:/var/lib/docker/overlay2/l/6PJSK7SEL2DZD3WDJ3X4AYU5RL,upperdir=/var/lib/docker/overlay2/499172ecc38729037253ad96d0e945bf0ba813af172860309efa074b26291306/diff,workdir=/var/lib/docker/overlay2/499172ecc38729037253ad96d0e945bf0ba813af172860309efa074b26291306/work 0 0
overlay /var/lib/docker/overlay2/0cbc12de0af9282ad38d6638788f6921bd54b351a34379825af665c79bd58a60/merged overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/J5SDZFFOLMGBZZCYPAJ4X6DLXL:/var/lib/docker/overlay2/l/3E45UB5PFRBZDFQMPQ4CBKY4EN:/var/lib/docker/overlay2/l/CMH2JHIJQLKAEC5IREZBKR4ZZI:/var/lib/docker/overlay2/l/BF747SNURY3E2H2VBW3KT2BT6O:/var/lib/docker/overlay2/l/JX77LFZ4JFJAWDUUBPLMCNR7EO,upperdir=/var/lib/docker/overlay2/0cbc12de0af9282ad38d6638788f6921bd54b351a34379825af665c79bd58a60/diff,workdir=/var/lib/docker/overlay2/0cbc12de0af9282ad38d6638788f6921bd54b351a34379825af665c79bd58a60/work 0 0
nsfs /run/docker/netns/455a2eb726d0 nsfs rw 0 0
nsfs /run/docker/netns/abd62373498a nsfs rw 0 0
nsfs /run/docker/netns/b3b48ab8811d nsfs rw 0 0
nsfs /run/docker/netns/1f7e55670976 nsfs rw 0 0
nsfs /run/docker/netns/227a2de4bda9 nsfs rw 0 0
tmpfs /run/user/0 tmpfs rw,nosuid,nodev,relatime,size=812532k,nr_inodes=203133,mode=700,inode64 0 0
~# find /overlay/over/
/overlay/over/
/overlay/over/home.nfs
/overlay/over/home.nfs/root
/overlay/over/root
/overlay/over/root/.config
/overlay/over/root/.config/htop
/overlay/over/root/.config/htop/htoprc
/overlay/over/root/.lesshst
/overlay/over/root/.Xauthority
/overlay/over/root/.bash_history
/overlay/over/usr
/overlay/over/usr/share
/overlay/over/usr/share/applications
/overlay/over/usr/share/applications/mimeinfo.cache
/overlay/over/var
/overlay/over/var/backups
/overlay/over/var/backups/alternatives.tar.0
/overlay/over/var/backups/dpkg.statoverride.0
/overlay/over/var/backups/dpkg.diversions.0
/overlay/over/var/backups/dpkg.status.0
/overlay/over/var/backups/dpkg.arch.0
/overlay/over/var/cache
/overlay/over/var/cache/nscd
/overlay/over/var/cache/nscd/netgroup
/overlay/over/var/cache/nscd/services
/overlay/over/var/cache/nscd/hosts
/overlay/over/var/cache/nscd/group
/overlay/over/var/cache/nscd/passwd
/overlay/over/var/tmp
/overlay/over/var/tmp/systemd-private-b1870e52cbdc4a5f9176afad9dc8f38b-ModemManager.service-l1hANC
/overlay/over/var/tmp/systemd-private-b1870e52cbdc4a5f9176afad9dc8f38b-ModemManager.service-l1hANC/tmp
/overlay/over/var/tmp/systemd-private-b1870e52cbdc4a5f9176afad9dc8f38b-systemd-logind.service-2rSHpn
/overlay/over/var/tmp/systemd-private-b1870e52cbdc4a5f9176afad9dc8f38b-systemd-logind.service-2rSHpn/tmp
/overlay/over/var/log
/overlay/over/var/log/lastlog
/overlay/over/var/log/btmp
/overlay/over/var/log/wtmp
/overlay/over/var/log/journal
/overlay/over/var/log/journal/1d65e2c972bc46d29af3fb9b3b2c1bae
/overlay/over/var/log/journal/1d65e2c972bc46d29af3fb9b3b2c1bae/system.journal
/overlay/over/var/lib
/overlay/over/var/lib/dpkg
/overlay/over/var/lib/dpkg/lock
/overlay/over/var/lib/dpkg/lock-frontend
/overlay/over/var/lib/apt
/overlay/over/var/lib/apt/daily_lock
/overlay/over/var/lib/logrotate
/overlay/over/var/lib/logrotate/status
/overlay/over/var/lib/NetworkManager
/overlay/over/var/lib/NetworkManager/timestamps
/overlay/over/var/lib/containerd
/overlay/over/var/lib/containerd/io.containerd.runtime.v2.task
/overlay/over/var/lib/containerd/io.containerd.runtime.v1.linux
/overlay/over/var/lib/containerd/io.containerd.metadata.v1.bolt
/overlay/over/var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db
/overlay/over/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs
/overlay/over/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots
/overlay/over/var/lib/containerd/io.containerd.snapshotter.v1.native
/overlay/over/var/lib/containerd/io.containerd.snapshotter.v1.native/snapshots
/overlay/over/var/lib/containerd/io.containerd.snapshotter.v1.btrfs
/overlay/over/var/lib/containerd/io.containerd.snapshotter.v1.blockfile
/overlay/over/var/lib/containerd/tmpmounts
/overlay/over/var/lib/systemd
/overlay/over/var/lib/systemd/timers
/overlay/over/var/lib/systemd/timers/stamp-logrotate.timer
/overlay/over/var/lib/systemd/timers/stamp-fstrim.timer
/overlay/over/var/lib/systemd/timers/stamp-e2scrub_all.timer
/overlay/over/var/lib/systemd/timers/stamp-apt-daily-upgrade.timer
/overlay/over/var/lib/systemd/timers/stamp-apt-daily.timer
/overlay/over/var/lib/systemd/random-seed
/overlay/over/tmp
/overlay/over/etc
/overlay/over/etc/shadow
/overlay/over/etc/passwd
/overlay/over/etc/gshadow
/overlay/over/etc/group
/overlay/over/etc/shadow-
/overlay/over/etc/passwd-
/overlay/over/etc/gshadow-
/overlay/over/etc/group-
/overlay/over/etc/.pwd.lock
/overlay/over/etc/systemd
/overlay/over/etc/systemd/system
/overlay/over/etc/systemd/system/sysinit.target.wants
/overlay/over/etc/systemd/system/sysinit.target.wants/iscsid.service
/overlay/over/etc/machine-id
/overlay/over/etc/resolv.conf
/overlay/over/etc/hosts
/overlay/over/overlay

Je to virtuál, který se od běžného laborkového stroje liší tím, že má dvě vrstvy navíc. Vrstva 1090/xpra/docker obsahuje docker a 1090/xpra/iscsi klienta pro open-iscsi. Obecná konfigurace je ve vrstvě 206/config, konfigurace specifická pro stroje v rámci subnetu 192.168.x.y je ve vrstvě 1004/ldap a to co z toho dělá stroj "turtle" je ve vrstvě 1002/turtle.

Myslím, že nemusím zdůrazňovat, že všechny vrstvy vyexportované v read-only modu, složené do sendviče, jsou překryty overlayem. Jenže docker používá také overlay, a trvá na tom, aby měl adresář /var/lib/docker nad FS, se kterým umí pracovat – vnořené overlayované kontejnery, s jakými pracuje můj deset let starý buildovací skript už by zřejmě bylo moc těžké, v už tak dost složitém a nepřehledném prostředí vzájemně provázaných kontejnerů ukočírovat.

Můj virtualizační skript kvm umožňuje několik variant, jak dovnitř dostat blokové zařízení. Ale chtěl jsem, aby ten stroj byl skutečně univerzálně použitelný. Proto jsem použil iSCSI. Nemusím tedy dělat žádný deploy pro to abych rozjel jiný stroj. Stačí jenom vybrat při bootu co chci – a stáhne se konfigurace u které finální konfigurační vrstva rozhodne o tom, jaké blokové zařízení se připojí a podle to se spustí i připravený set kontejnerů. Rozdíl mezi konfigurací stroje A a stroje B, představuje jeden záznam v DHCP a několik kilobajtů v konfigurační vrstvě.

Pokud vím, docker a jiné kontejnerové aplikace neumožňují, z principu, udělat revert, protože by se jim rozsypaly ty stacky. Mně na to stačí při rebootu předat v parametru subvol (viz vytučněné místo výpisu namountovaných zařízení) místo 'containerd' a 'docker' jména snapshotů a je to na lupnutí prstu.

[Max]

Proč by neměl umět zapisovat persistentní změny přes nfs?
Jinak co je těmi smyčkami myšleno? Běžná síť by se s nimi měla umět rychle vypořádat a k výpadkům by nemělo docházet. Tj. RSTP/MSTP, Loop Protection, BPDU Guard apod.
Zdar Max

[Want]

Maxi, ty víš, že je síť mimo mou kompetenci. Vzpomínáš na naši poslední debatu v Šumavské? O firewallu? Momentálně panuje všeobecná posedlost kyberbezpečností, ale zdrojem skutečného nebezpečí je hloupost. Zopakovala se situace, která se podle mého přesvědčení neměla opakovat. A v měřítku mnohem horším než prvně.

Když se to stalo prvně, bylo to ještě v éře, kdy jsem používal vde switch. Takže bylo ihned jasné na kterém subnetu to vaří. Konektivita tehdy byla pouze 1Gbit, takže se to nikde jinde nestihlo projevit.

No. A teď se to projevilo takhle. Naštěstí nejde (zatím) o produkční nasazení. Ovšem remount do read-only stavu není zrovna to co chceš, protože ti zůstávájí data viset v RAM.

[efa]

By me zajimalo, jakypak chovani bys jako cekal, kdyz necemu odpojis disk, coz je presne situace kdyz ti zdechne iscsi. A aby se to nedelo, tak ze VZDY pouzivaji NEJMENE 2 switche a stejne tak pole ma NEJMENE dva controlery, a kazdy jeden stroj je pripojen ke vsem switchum stejne jako to pole, takze pravdepodobnost vypadku se limituje na naprosty minimum.

Pokud si to bastlis na jednom switchi za 5korun, tak to celkem logicky nemuze fungovat.

[Want]

Ty jsi mi nějak chytrý. Jen to čtení ti moc nejde.

[efa]

Zato ty ses zjevne uplnej blb.

"Háček je v tom, že veškerá komunikace jde přes hlavní switch"

Koupis si trikolku a cekas od toho ze to bude mit 1000 koni a zaroven to bude litat i plavat.

[PetebLazar]

Pokud se nepletu tak úplnost multi-path zajišťovalo využití Dual-Port HDD (FC/SAS), případně SSD.

[Want]

Ten sheepdog byl přesně na tyhle situace stavěný. Měl zajistit běh infrastruktury i v případě že byla přerušena konektivita např. při zemětřesení (vyvíjel to japonec).

[polish]

Asi bych nespolehal na timeouty filesystemu. Oddelit SAN sit od bezneho internet provozu a nasadit multipath - vice nezavislych tras.

[Want]

Jasně, vyřešilo by to přímé propojení těch dvou strojů, ale bohužel, to už není v mé kompetenci. A nejsem si ani jist, zdali je to možné. Samozřejmě existuje i varianta protlačit přes NFS celé virtuální blokové zařízení. Používám to, ale jen při spouštění, kdy se nic nezapisuje.

[Peter Golis]

Ako to čítam, tak nerozumiem jednej veci. Naozaj tam máte úmyselne vytvorený Single Point of Failure, a ten odstavuje kritickú časť infraštruktúry bežiacu v kontajneroch?

Alebo to nie je kritická časť infraštruktúry ktorej nevadia výpadky, a nie je čo riešiť?

[Want]

Uvádím výše - je to mimo mou kompetenci. Spousta věcí se mění a je to jak s očkováním proti slintavce a kulhavce. Nikdy neuhlídáš všechno. A teď se to prostě sešlo, takže se ukázala slabina, která by většinu lidí nenapadla ani ve snu. Nemůžu vědět, kdy se něco podobného stane zas, ale mohu zvolit technické řešení, které bude robustní - tak jako je robustní ta disklessová infrastruktura. S tou ten incident neudělal nic. A nebýt toho, že se remountlo to Btrfs, netušil bych, že se něco dělo.

[Peter Golis]

To by naozaj nikoho nenapadlo že jediný switch je SPOF. A zaujímalo by ma čo nastane ak ten switch čírou náhodou odíde do kremíkového neba.

A ak ten výpadok neurobil nič s tou bezdiskovou infraštruktúrou, tak to obkukaj a nasaď to rovnakým štýlom.

Inak docker naozaj nevie pracovať s trvalým úložiskom cez NFS? Pýtam sa pre kamaráta.

[Want]

Když si ho postavíš sám, tak jo. Jenže to, co mám za úkol rozjet už postaveno je. Je to několik kontejnerů co vzájemně spolupracují, žel ten klíčový má nějaký konfigurační problém. Takže není čas zkoumat, jak to je ubastleno uvnitř, protože to ještě nejede, jak by mělo.

[efa]

To mas marny, on po tobe chce reseni jak na lavku ze shnilyho prkna pres potok dostat nalozenej kamion.

Ten jeho switch je tak neco za petikorunu vytazenyho z popelnice, protoze nic normlaniho smycku ani nezapne. Klidne si to vyzkousej.

iSCSI mam jak na vyhrazeny tak na sdileny infrastrukture, a zadnej problem s tim neni. Ma to trosicku horsi latence nez FC, ale to je vse. Na druhou stranu ... je to sranda (proti FC) o poznani levnejsi a vyrazne univerzalnejsi. Protoze narozdil od FC si to proste muzu attachnout k libovolnymu cemukoli na siti.

Resit chovani pri vypadku s jednim switchem, je presne stejny, jako resit fail raidu s jednim diskem.

[Peter Golis]

On dostal úlohu: Tak sa to pokazilo, urob s tým niečo aby to neblblo. A delegoval to na internetové fórum. Má zaujímavú náplň práce.

[X]

Ptal se na zkusenosti. Zase bych ho tak negriloval. Presnou situaci vi jenom Want.

[Peter Golis]

Skúsenosti má kde kto, obvykle veľmi dobré keďže iSCSI sa používa na redundantných pripojeniach.

Potom to ale upresnil s nezmyselnými obmedzeniami typu že tam je SPOF, alebo kontajnery boli šité horúcou ihlou a nemajú podporu NFS.

Neviem čo mu bráni vytvoriť korektne nové kontajnery, a prehodiť do nich údaje. Asi je ten návod naňho zložitý, a on očakáva info kam má kliknúť popri rannej káve.

Holt, antonym Want je tu pojem.

[Want]

Ty vole Golis. Nebudu ti vykládat o věcech do kterých tobě ani mně nic není. To podstatné ses dozvěděl. Nejsem velmistr vesmíru jak si někteří naivně myslí, protože kdyby jo, bylo by všechno jinak. Ptal jsem se na zkušenosti s iSCSI a FS. To je opravdu takový problém napsat používám nad tím tenhle FS protože tohle a tohle?

Chápu, že se někdo o své zkušenosti dělit nechce. Co nechápu, je ta potřeba mít blbé kecy a vyjadřovat se k problému, který jen v plné nahotě ukázal slabiny řešení, které ale není z mojí hlavy. Mým cílem je ošéfovat i takovou situaci. Ne říkat někomu jinému jak má co dělat.

[Peter Golis]

Používal som, ale kvôli latencii bol prechod na FC.

Tyvole Want, nabudúce nechaj navrhovať topológiu niekoho iného. A tie narýchlo zbastlené kontajnery radšej zmigruj ako som povedal na novo a korektne vytvorené.

Zas si sa nezaprel ako majster sveta.

[Want]

Topologie sítě není v mé kompetenci jestli jsi to dosud nepochopil. O situaci víš kulové, takže si svoje moudra strč za klobouk. Já se k tvým schopnostem - pokud sis toho ještě nevšiml - také nevyjadřuji.

[Peter Golis]

To som pochopil, a preto som spomínal že máš nanovo a korektne vytvoriť tie kontajnery, a zmigrovať im dáta.

Ak si nepochopil ten prehľadný návod čo som ti nalinkoval až pod nos, tak to radšej zabaľ.

[Heron]

Používám to pro Windows 11, kam chci dostat velký 18TB disk z diskového pole, které je přesně na druhé straně bytu a neslyším jej. Ve Windows 11 je iSCSCI initiátor a na straně FreeBSD je iSCSI target. 2.5Gpbs síťovky a jede to cca 200MB/s na mechanických HDD. Takže super!

V QCM jsme takto měli připojené mnohem větší diskové pole do všech výpočetních uzlů na vmware. Funguje spolehlivě, když se správě udělá sít, tak výpadek jedné cesty znamená přepnutí na jiný 40Gbps port do 1s. VMka s PostgreSQL nikdy nepřišla o jediný řádek ani při výměně 40Gbps switche za trvalého běhu produkčních serverů!

[Heron]

Ale na síťování a multipath nejsem expert, síť jsme si nechávali nastavit od externí firmy.

[Aleš Kapica]

Díky za info!