Jakub Vrána napsal AI plugin sql-gemini pro nástroj pro správu databáze v jednom PHP souboru Adminer. Plugin dovoluje sestavovat SQL dotazy pomocí AI, konkrétně pomocí Google Gemini.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Byla vydána nová verze 0.4.15 (𝕏) svobodného operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows. Přehled novinek i s náhledy v oznámení o vydání.
Byl představen rpi-image-gen, tj. oficiální nástroj pro vytváření vlastních softwarových obrazů pro zařízení Raspberry Pi.
Byla vydána nová major verze 8.0, aktuálně 8.0.1, softwaru pro správu elektronických knih Calibre (Wikipedie). Přehled novinek v poznámkách k vydání. Vypíchnuta je lepší podpora Kobo KEPUB formátu nebo integrovaný lokálně běžící engine Piper pro převod textu na řeč používaný pro čtení nahlas (již od verze 7.18).
Společnost OpenAI rozšířila své API o nové audio modely. Nový model pro převod textu na řeč (text-to-speech model) lze bez přihlašování vyzkoušet na stránce OpenAI.fm.
Příspěvek Bezpečnost paměti pro webové fonty na blogu Chrome pro vývojáře rozebírá, proč se pro zpracování webových fontů v Chrome místo FreeType nově používá v Rustu napsaná Skrifa z Fontations.
V pátek 21. a v sobotu 22. března proběhnou Arduino Days 2025, tj. každoroční „narozeninová oslava“ platformy Arduino. Na programu je řada zajímavých přednášek. Sledovat je bude možné na YouTube. Zúčastnit se lze i lokálních akcí. V sobotu v Praze na Matfyzu.
Komunitná konferencia Bratislava OpenCamp, ktorá sa uskutoční už o tri týždne 5. 4. 2025 na FIIT STU pozná svoj program – návštevníkom ponúkne 3 paralelné behy prednášok a workshopov na rôzne témy týkajúce sa otvoreného softvéru či otvorených technológií.
Časopis MagPi od nakladatelství Raspberry Pi se s číslem 151 přejmenoval na Raspberry Pi Official Magazine. I pod novým názvem zůstává nadále ve formátu pdf zdarma ke čtení.
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: