Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Nechápu proč sem pleteš ZFS. Nemá nativní podporu v jádře a v clusterovém použití prakticky na prd.
CEPH - Zapomeň. 3 nody jsou pro něj existenční minimum. Já mu dával šanci už třikrát, a pokaždé to skončilo na tom, že se mi ho nepodařilo rozběhat.
DRBD - fajn. Má ovšem jeden háček. Buď musíš mít pro každý stroj extra pole, nebo na něj lézt přes NFS, jako to používáme disklessu. Protože ale chceš virtualizovat i vidle, tak diskless požít nemůžeš a virtuální disky přes NFS.. - no, použít se to dá, ale žádná výhra. Navíc mám poslední dobou pocit, že hoši od Linbitu nějak prdí na agenta pro Pacemaker.
Takže já bych osobně doporučil u takové infrastruktury jako chceš provozovat jít do replikovaného GlusterFS. Výkonově je Schrot slabší, ale oproti DRBD se GlusterFS jeví pro clusterové použití jako robustnější řešení - nemusíš řešit ze kterého nodu na virtuální disk lezeš a můžeš bez obav šaškovat s nody - průběžné je aktualizovat a dělat s nimi i jiné hrátky. Mě v tom jedou zatím tři méně důležité stroje. Pořád zatím ve fázi testu. Oproti původnímu disklessovému řešení linuxových strojů které používám u Peanuts jsem zatím nepřišel na vhodnou strategii zálohování.
DRBD - fajn. Má ovšem jeden háček. Buď musíš mít pro každý stroj extra poleProč to? Nestačilo by nad tím DRBD rozběhat LVM? Přímo nad DRBD jsem to teda nezkoušel, ale IIRC jsem to zkoušel nad iSCSI blokovým zařízením - hádám, že by to mělo fungovat podobně. Samozřejmě to omezuje na maximálně 2 nody
Nechápu proč sem pleteš ZFS. Nemá nativní podporu v jádře a v clusterovém použití prakticky na prd.
Pls. Nesir informace o necem, co neznas. ZFS bezi se vsemi jadry od 2.6.32 po nejnovejsi. A clusterove pouziti pro object store se ZFS neni zadna novinka. Je nekolikero zpusobu, jak na to, ve vsech ZFS usnadnuje zivot.
Autorovi postu: kdybys se rozhodl pro ZFS a potreboval poradit, napis mi mail, pripadne muzes sem.
Co je, nebo neni v kernelu, je vzhledem k produkcnimu nasazeni IMHO irelevantni, pokud je nekdo, kdo tomu dela podporu.
…tedy aspoň do chvíle, než vás s tím taintovaným jádrem support pošle někam. Nebo vám ten někdo bude podporovat celé jádro?
Ja bych to pro takhle maly pocet serveru nekomplikoval clusterovanim, kdybych mel resit replikaci dat, tak asynchronne send/recv snapshotu periodicky. Jelikoz to PVE ale nepodporuje, resil bych si to par skriptama sam zrejme. Ne kazdymu muze vyhovovat, nekdo rad UI v browseru, to pak se ZFS asi nic pointegrovaneho poradne neexistuje, leda poupravit drobne FreeNAS (snad umi nejake pluginy, pokud si vzpominam dobre). Ale nativni distribuovana reseni bych uvazoval az od vetsiho poctu nodu, s poradnou siti, atd. V malem bych se spokojil s nejakou formou asynchronni replikace. Nicmene to je muj nazor a jsou priklady lidi, kteri to provozuji i v malem vcelku dobre zclusterovane, ale uprimne si myslim, ze to je dost developmentu naskladat reseni, aby fungovalo a pak se dalo i vyskalovat.
Bohuzel se v hi-level resenich pripravenych pro snadne pouziti neorientuju vlastni zkusenosti, protoze si rad ty technologie poskladam podle situace sam; nicmene samotne ZFS toho umi hodne, rekl bych, ze na spoustu use-cases vubec neni nejake pokrocilejsi UI potreba, staci 2 prikazy na obslouzeni celeho storage a pripadne par skriptu na replikaci (na Githubu se pro ZFS vali nekolik variant vhodnych pro nasazeni rovnou.).
Pánové nic proti, ale jste jak praštění. Nemáte s tím reálnou zkušenost (CEPH), ale doporučujete to.Zatímco vy jste se asi praštil do hlavy doopravdy, a pak jste z mého příspěvku vyčetl něco, co tam ani náhodou není.
FCoE situaci neřeší a navíc na to nikde nemám HW.
K těm snapshotům - jde o btrfs snapshoty. DRBD (blokové zařízení) + BTRFS (souborový systém) + NFS (sdílení). Používat nad DRBD LVM považuji za úlet. Ne že by to nešlo, ale je to další, vcelku zbytečná vrstva, protože obvykle se používá DRBD vytvořené nad LVM logickým oddílem.
Jinak se pokusím schematicky uvést jaké kombinace jsem používal a proč jsem je opustil
( MD RAID | HW RAID ) + LVM + DRBD Primary/Primary + OCFS2 + Virtual disk
Navíc jsem si musel napsat vlastního agenta do Pacemakeru, který se staral o správné namountování OCFS2, protože ten co byl k dispozici byl zastaralý (pracoval tenkrát ještě se zámky v userspace, které u novější verze jádra byly odstraněny). To by rok 2011. Kritickým bodem byl ovšem rozpad DRBD pole. Po opakovaných restartech, se rozpadalo DRBD pole a vznikal split-brain, jehož řešení obnášelo dilema - který nod má ta správná data? Proto jsme tento koncept opustili postupně opustili a během r. 2012 přešli zpátky na DRBD v režimu Primary/Slave.
( MD RAID | HW RAID ) + LVM + DRBD Primary/Slave + ( Ext3 | Ext4 | Btrfs ) + NFS + (Diskless | Virtual disk)
Tato změna sebou přinesla to, že jsme mohli zahodit OCFS2 a používat rovnou běžný souborový systém. U některých clusterů se přes NFS exportují celé virtuální disky, ale nejlepší výkon a komfort poskytuje Diskless - na který už jsem odkazoval výše - který pracuje rovnou se soubory.
Bohužel neuralgickým bodem je agent Pacemakeru pro DRBD od Linbitu. Jedinou cestou, jak se zbavit závislosti na DRBD je - GlusterFS. Není sice tak výkonný (jeho výkon je závislý na mnoha faktorech), ale funguje poměrně spolehlivě a co hlavně - virtuální disky uložené na jeho svazcích lze poskytovat i na jiné stroje.
Btrfs multidevice + Thin LVM + GlusterFS + Virtual disk
Tohle řešení je ale poměrně čerstvá záležitost. Mám totiž ve zvyku věci průběžně dokumentovat, což je dost náročné na čas a ještě jsem nerealizoval všechny plánované testy nejrůznějších krizových stavů. Jednoznačná výhoda je v tom, že lze virtualizovat libovolný systém. Je to blbuvzdorné a jednou vytvořený virtuální stroj lze v případě nutnosti spustit z libovolného bricku, ale nemám odzkoušeno co se stane, když se začnou hnojit data uvnitř souboru s virtuálním diskem na některém z bricků. Největší slabiny spatřuji v následujících věcech:
Rozchodit GlusterFS lze lupnutím prstu.To bych nepovažoval za tak důležité jako to, jak dobře to pak bude chodit. Ale ok, to už jste tu psal taky, že na dvou nodech (a jestli jsem dobře pochopil, tazatel jich víc mít nebude) to stáhlo za prd, to jako argument beru. Když jsem to četl, na Ceph se mi líbil návrh - hromada strojů, na nich hromada disků, poskládám to dohromady a všichni vidí všechno. Ideální pro prostředí, které se vyvíjelo tak, že tu hromadu strojů už mám, takže kvůli síťové storage nemusím vyhodit půlku serverovny. Dokonce mám pocit, že EMC něco podobného nabízí za peníze a vůbec bych se nedivil, kdyby se inspirovali (ať už jedni nebo druzí.) Na druhou stranu jsem o Ceph od nikoho neslyšel žádné pozitivní reference, takže jsem nějaké vážnější testování nechal "na jindy"...
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75Random read
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randreadHost - local, RAID10 6x300GB SAS2, MegaRAID SAS 2108 Random read/write
read : io=3072.4MB, bw=12732KB/s, iops=3183 , runt=247092msec write: io=1023.7MB, bw=4242.3KB/s, iops=1060 , runt=247092msecRandom Read
read : io=4096.0MB, bw=19690KB/s, iops=4922 , runt=213013msecVM Debian - GlusterFS, cache writeback, VirtIO Random read/write
read : io=3071.7MB, bw=13732KB/s, iops=3432, runt=229056msec write: io=1024.4MB, bw=4579.4KB/s, iops=1144, runt=229056msecRandom Read
read : io=4096.0MB, bw=45570KB/s, iops=11392, runt= 92040msecVM Debian - DRBD, cache directsync, VirtIO Random read/write
read : io=3071.7MB, bw=11792KB/s, iops=2948, runt=266734msec write: io=1024.4MB, bw=3932.5KB/s, iops=983, runt=266734msecRandom read
read : io=4096.0MB, bw=16911KB/s, iops=4227, runt=248025msecVubec tedy nevim jestli ty vysledky jsou celkove dobre nebo spatne, DRBD i GlusterFS bezi na vychozi konfiguraci, temer bez jakychkoliv uprav. Takze je cas trochu se venovat tomu tunningu...
Random R/W: read : io=3071.7MB, bw=11986KB/s, iops=2996, runt=262420msec write: io=1024.4MB, bw=3997.9KB/s, iops=999, runt=262420msec Random R: read : io=4096.0MB, bw=18343KB/s, iops=4585, runt=228656msec(8x 300GB SAS2 10k, SmartArray P410, cache R/W 75/25, R10)
Random R/W: read : io=3071.7MB, bw=11409KB/s, iops=2852, runt=275688msec write: io=1024.4MB, bw=3804.8KB/s, iops=951, runt=275688msec Random R: read : io=4096.0MB, bw=17226KB/s, iops=4306, runt=243480msecPro porovnani:
/var/tmp: read : io=3071.7MB, bw=10460KB/s, iops=2614, runt=300719msec write: io=1024.4MB, bw=3488.3KB/s, iops=872, runt=300719msecTo, ze je 6 disku rychlejsich nez 8, je zvlastni. Glusterfs FUSE fio 2 nody:
read : io=3071.7MB, bw=7332.3KB/s, iops=1833, runt=428978msec write: io=1024.4MB, bw=2445.2KB/s, iops=611, runt=428978msecGluster FUSE top 2 nody:
root@ic3:/mnt/gluster-test/fio# gluster volume top gluster-test read-perf bs 4096 count 1024 Brick: ic3-gluster:/mnt/gluster-storage Throughput 2974.68 MBps time 0.0014 secs MBps Filename Time ==== ======== ==== 0 /fio/test 2015-06-03 10:06:29.522222 0 /test 2015-06-03 09:58:58.369362 Brick: ic4-gluster:/mnt/gluster-storage Throughput 2555.94 MBps time 0.0016 secs root@ic3:/mnt/gluster-test/fio# gluster volume top gluster-test write-perf bs 4096 count 1024 Brick: ic3-gluster:/mnt/gluster-storage Throughput 719.93 MBps time 0.0058 secs MBps Filename Time ==== ======== ==== 0 /fio/test 2015-06-03 10:06:29.494512 Brick: ic4-gluster:/mnt/gluster-storage Throughput 728.18 MBps time 0.0058 secs MBps Filename Time ==== ======== ==== 0 /fio/test 2015-06-03 10:03:11.735087 0 /test 2015-06-03 09:55:40.622298
root@nod2 :~# gluster volume top stroj read-perf bs 4096 count 1024 Brick: nod2:/srv/stroj/data Throughput 1062.39 MBps time 0.0039 secs MBps Filename Time ==== ======== ==== 0 /disk.img 2015-06-03 12:04:00.744629 Brick: nod3:/srv/stroj/data Throughput 1080.73 MBps time 0.0039 secs Brick: nod1:/srv/stroj/data Throughput 1122.07 MBps time 0.0037 secs MBps Filename Time ==== ======== ==== 0 /disk.img 2015-05-27 18:00:42.352519 root@nod2 :~# gluster volume top stroj write-perf bs 4096 count 1024 Brick: nod2:/srv/stroj/data Throughput 421.07 MBps time 0.0100 secs MBps Filename Time ==== ======== ==== 0 /disk.img 2015-06-03 13:07:13.967296 Brick: nod3:/srv/stroj/data Throughput 565.88 MBps time 0.0074 secs MBps Filename Time ==== ======== ==== 0 /disk.img 2015-06-03 13:07:15.150104 Brick: nod1:/srv/stroj/data Throughput 443.47 MBps time 0.0095 secs MBps Filename Time ==== ======== ==== 0 /disk.img 2015-06-03 13:07:17.407223 root@nod2 :~# gluster volume info stroj Volume Name: stroj Type: Replicate Volume ID: ce1671b3-7217-4817-b051-1919407824a4 Status: Started Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: nod2:/srv/stroj/data Brick2: nod1:/srv/stroj/data Brick3: nod3:/srv/stroj/data Options Reconfigured: cluster.self-heal-daemon: enable nfs.disable: on
Ono s těmi benchmarky je to takové všelikajé, tak jsem jen pro porovnání přihodil stejné měření aplikované na virtuál, který používám pro testy, než bude časem úplně odstavený - stroj. Link jsem přidal, abyste si mohli otestovat jak ten stroj reaguje. Jede na něm apache, postgres. Dřív se na něm sbíraly data a dělaly nějaké výpočty.
Bricky na nodech jsou na 4TB SSHD od Seagate (LVM oddíl o velikosti 50GB, formátovaný na btrfs). Virtuální disk má 40GB a paměti má ten stroj 1GB.
Kromě tohoto stroje jedou na nodu nod2 ještě další dva, a celkem je v provozu 9 svazků.
z ic3-gluster: ic4-gluster:/gluster-test /mnt/nfsgluster nfs defaults,_netdev 0 0 fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 read : io=3071.7MB, bw=28420KB/s, iops=7105, runt=110675msec write: io=1024.4MB, bw=9477.5KB/s, iops=2369, runt=110675msec fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread read : io=4096.0MB, bw=36024KB/s, iops=9006, runt=116430msec z ic3-gluster: ic3-gluster:/gluster-test /mnt/nfsgluster nfs defaults,_netdev 0 0 fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 read : io=3071.7MB, bw=10407KB/s, iops=2601, runt=302226msec write: io=1024.4MB, bw=3470.7KB/s, iops=867, runt=302226msec fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread read : io=4096.0MB, bw=14545KB/s, iops=3636, runt=288362msecPodle tohoto testu je vykon pres NFS v pripade pripojeni na vzdaleny node cca 2.5x vetsi...
Random R read : io=4096.0MB, bw=72636KB/s, iops=18159, runt= 57744msec Random RW read : io=3071.7MB, bw=17964KB/s, iops=4490, runt=175095msec write: io=1024.4MB, bw=5990.6KB/s, iops=1497, runt=175095msecHlavne ten Random Read je docela zasadni skok. U pripojeni pres NFS (1Gbit) byly vysledky spis polovicni. Ale to pouzivat nebudu, takze asi neresim. Takze ted jdu hledat jak na benchmarky DB
quick-read=off read-ahead=off io-cache=off stat-prefetch=off eager-lock=enable remote-dio=enable quorum-type=auto server-quorum-type=serverVM: VIRTIO, writeback
cat /sys/block/vda/queue/scheduler [noop] deadline cfq blockdev --getra /dev/vda 32768Jsou to bezne vygoogleny rady pro VM a Glusterfs, ani nevim co melo nejvetsi vliv (tusim ze se to pohlo pri nastaveni parametru Glusterfs) Ted hledam nejake vhodne zpusoby tech benchmarku DB a na zaklade toho bych pokracoval s ladenim GlusterFS.
z ic3-gluster: ic4-gluster:/gluster-test /mnt/nfsgluster nfs defaults,_netdev 0 0 [cfq] fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread read : io=4096.0MB, bw=36024KB/s, iops=9006, runt=116430msec [deadline] fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread read : io=4096.0MB, bw=76913KB/s, iops=19228, runt= 54533msec
Tiskni
Sdílej: