MDN (Wikipedie), dnes MDN Web Docs, původně Mozilla Developer Network, slaví 20 let. V říjnu 2004 byl ukončen provoz serveru Netscape DevEdge, který byl hlavním zdrojem dokumentace k webovým prohlížečům Netscape a k webovým technologiím obecně. Mozille se po jednáních s AOL povedlo dokumenty z Netscape DevEdge zachránit a 23. července 2005 byl spuštěn MDC (Mozilla Developer Center). Ten byl v roce 2010 přejmenován na MDN.
Wayback byl vydán ve verzi 0.1. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána nová verze 6.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově se lze k síti Tor připojit pomocí mostu WebTunnel. Tor Browser byl povýšen na verzi 14.5.5. Thunderbird na verzi 128.12.0. Další změny v příslušném seznamu.
Meta představila prototyp náramku, který snímá elektrickou aktivity svalů (povrchová elektromyografie, EMG) a umožňuje jemnými gesty ruky a prstů ovládat počítač nebo různá zařízení. Získané datové sady emg2qwerty a emg2pose jsou open source.
Byla vydána (𝕏) nová verze 25.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 25.7 je Visionary Viper. Přehled novinek v příspěvku na fóru.
Před 40 lety, 23. července 1985, společnost Commodore představila první počítač Amiga. Jednalo se o počítač "Amiga od Commodore", jenž byl později pojmenován Amiga 1000. Mělo se jednat o přímou konkurenci počítače Apple Macintosh uvedeného na trh v lednu 1984.
T‑Mobile USA ve spolupráci se Starlinkem spustil službu T-Satellite. Uživatelé služby mohou v odlehlých oblastech bez mobilního signálu aktuálně využívat satelitní síť s více než 650 satelity pro posílání a příjem zpráv, sdílení polohy, posílání zpráv na 911 a příjem upozornění, posílání obrázků a krátkých hlasových zpráv pomocí aplikace Zprávy Google. V plánu jsou také satelitní data.
Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia AI asistenta Lumo.
Našel by se tu někdo, kdo má zkušenosti s provozem něčeho podobného? V mém případě se jedná o storage Dell MD3000i, což by měl být stejný HW jako IBM DS4000.
Jak jsem zmínil přistupuji k němu přes iSCSI porty, které má celkem 4. Mám k němu připojené dva servery na přímo (tzn. do každého serveru dva porty). Víceméně tato konfigurace funguje, pokud pominu chyby, které jsou podle Dellu "normální" - v konzoli se při připojení na portál anebo listování disků objevují I/O chyby 20MB LUNu, který je pro nějaké zvláštní účely.
Můj problém tkví v tom, že když vypnu jednu ze síťovek:
1) v době kdy se na úložiště nepřistupuje, multipath zareaguje během 20 s
2) v době, kdy na úložiště zapisuji, multipath zareaguje po více než minutě
Pokud sleduji stav sessions příkazem iscsiadm -m session -P 2,tak v prvním případě je vidět, že ztrátu zaznamená za méně než 10 s. V druhém ale čekám téměř minutu. Testy jsem prováděl při zápisu v jednom threadu, nevím tedy, zda se čas prodlužuje s více souběžnými operacemi...
V iscsid.conf mám nastaveny všechny timeouty velmi nízko. Tak trochu z toho podezírám modul rdac (který zde slouží ke kontrole cest) protože v sobě má nastavený nějaký timeout na 60000 ms.
Měl by někdo nějaký nápad nebo malinkou myšlenku? Mám totiž obavy, že kdyby všechny virtuální stroje musely při problému čekat minutu až dvě než se vzpamatuje disk, tak by dříve popadaly...
Jediné co mne napadlo je, zkompilovat si modul dm-rdac s upraveným timeoutem ve zdrojácích, ale nevím, jestli je to dobrý nápad, protože netuším, jak to uvnitř funguje. Co bych měl asi zmínit, že jedu na Lennym (Debian).
Přikládám konfiguráky /etc/multipath.conf a /etc/iscsi/iscsid.conf
Řešení dotazu:
Tak problém částečně odhalen - při zápisu mnoha malých souborů reaguje multipath na odpojení síťovky rychle. Problém tedy bude pravděpodobně v nějakém bufferu...
Po dlouhé době jsem rozhodl podělit se o řešení. Vždycky jsem dostal storage do stavu, že nějakou dobu fungoval, ale třeba po třech týdnech došlo k nepříjemnému zpanikaření kernelu na obou strojích, které k úložišti přistupují. Po velmi dlouhém bádání a doslova pokusech jsem se rozhodl znovu obrátit na podporu Dellu, která mne ale odpálkovala, že nepoužívám podporovaný systém. Nakonec jsem zkusil nasadit CentOS a rázem se situace zlepšila. I/O chyby se objevují sice stejně, ale je jich podstatně méně. Pády systémů naprosto vymizely.
Jaké z toho plyne ponaučení? Dell pro open source Linux nebrat!
S Xenem jsem nikdy nepracoval. Dell se žene zejména za ziskem, o nějaké větší podpoře nemůže být řeč. Jednou jsem v noci volal na jejich hotline a přepojilo mne to na nějaký mezinárodní helpdesk odkud mi nebyli schopni poradit. Na druhou stranu jejich HW servis funguje velmi dobře.
K rychlosti můžu říct jen toto - mám to připojené přes všechny čtyři síťovky ke dvěma serverům. I při minimálním vytížení z toho jen s obtížemi dostanu více jak 80MB/s z jednoho stroje. Údajně je to tak úmyslně. Pokud nastavíte multipath do nějakého load balanced režimu (který mimochodem toto úložiště nepodporuje), dají se z toho dostat chvílemi slušné rychlosti, ale s tím také spousta chyb.
Dost jsem se s tím natrápil a dnes už bych sáhnul po jiném výrobci nebo ještě lépe po nějaké skládačce (třeba Supermicro), kde budu mít vždycky možnost nastavit si systém přesně podle mých potřeb. Nemám rád neprůhledná řešení. Jen pro zajímavost v tomto úložišti tepe Windows (pravděpodobně Windows Embeded)... Navíc už dvakrát se mi stalo, že jeden z management portů přestal fungovat, dokud jsem úložiště natvrdo nevypnul a znova zapnul.
Pokud se chcete pobavit více, napište mi na email nebo jabber, který naleznete v mém profilu.
Zapojeni mame pres switch do POOLu xenserveru, ktery ridi 3X pripojeni do toho iscsi pres 2GBps (sitovky na xenu jsou v bondu ...)
Pokud máte navázány řekněme dvě iSCSI relace, každou přes jinou síťovku, tak jste možná omezen kapacitou jednotlivé síťovky. Pokud chcete ze dvou síťovek vytáhnout dvojnásobek, musel byste nějak zařídit balancing mezi relacemi. Zároveň záleží na tom, jakým provozem testujete průchodnost. Při sekvenčním čtení jediným vláknem se sice Linux snaží o nějaký read-ahead, ale v podstatě se neuplatní TCQ, takže nelze "nafrontovat požadavky do obou iSCSI relací paralelně" - prostě protože se těch požadavků nesejde dostatek. Při čtení více vlákny se paralelní frontování do více iSCSI relací použít dá - ale pokud si nedáte pečlivě záležet, tak zas budou paralelní relace číst každá z jiného místa disku, tzn. disky budou muset seekovat, což může průchodnost dramaticky srazit. Kolik disků je v tom RAIDu a jakých? Kromě toho, pokud si správně pamatuju z mého jediného historického pokusu o load balancing přes dm-mpath, balancing mezi SCSI cestami funguje v režimu "round robin", kdy se vždycky do jedné cesty pošle dávka N požadavků, pak se přepne na alternativní cestu, a zase N požadavků. Hodnotu N lze konfigurovat, ale doporučená hodnota je v každém případě výrazně vyšší než 1, aby se round-robin algoritmus nemusel volat pro každý požadavek extra (kvůli zátěži CPU). Potažmo se dvěma čtoucími vlákny se load balancing taky moc neuplatní Domnívám se, že by to šlo otestovat sekvenčním *zápisem*. Při něm se uplatní write-back, takže VM/IO vrstvy vygenerují z jednoho zapisujícího vlákna sérii požadavků na IO. Pokud budou rozumně nastavené hloubky front (detaily z hlavy nedám) tak by mělo docházet k rozkládání mezi obě linky / SCSI cesty. Pokud testujete zápisem a máte v serveru hodně RAMky, musíte zapisovat mnohem větší soubor, než je velikost RAM, a po spuštění testu chvíli počkat, než se ustálí tok dat (než se buffery v RAMce zaplní po strop) - alternativně lze použít "direct IO", pokud ho lze při zvoleném způsobu generování zátěže nastavit (a nejsem si jist, jestli náhodou zároveň nevykostíte TCQ na úrovni operačního systému). Dále pokud nechcete testovat schopnost disků seekovat, doporučuji zapisovat nikoli skrz filesystém, ale přímo DDčkem apod. sekvenčně na blokové zařízení.
A propos, průchodnost iSCSI: jaké používáte MTU?
Jinak už jsem taky zaslechl, že některé "lepší" storage záměrně omezují průchodnost "per host" (nebo snad per flow, nebo per co vlastně) na nějakých 100 MBps - na rozhraní FC 4Gb. Pokud Vám tohle nevyhovuje, tak zlatá Areca. Já vím - je to jako srovnávat limuzínu s Trabantem...
To je dlouhe Ale pekne
1. To ohledne MSI zni zajimave, ale v tomhle se neorientuji, takze muzu maximalne vyzkouset nejakou tu propustnost a to je vse ...
2.jj ty reakce se daji zmenit, jak temy timeauty , tak primo nastavenim multipatch (pristupove body a zpusob samotenho propojeni) ja mam napriklad round-robin:
root@xenserver ~]# multipath -ll -v2 36a4badb0004ee06f0000039a4c10a9fedm-6 DELL,MD3000i [size=1000G][features=0][hwhandler=1 rdac] \_ round-robin 0 [prio=200][active] \_ 34:0:0:0 sdg 8:96 [active][ready] \_ 33:0:0:0 sdd 8:48 [active][ready]dale jsem vygoogloval, ze ty chyby od toho kernelu jsou vycemene v poradku, ze je to dano treba u toho dell trosku jinym nastanevim toho hwhandleru a rdac, citrix na to ma primo specialni utilitu, co nastavi jadro (initrd) a pak samotne moduly, specialne pro ten dell - zatim jsem neresil ... 3. Pruchodnost je asi OK. ja to mam zapojene "trosku blbe" mam na xenech bond (round-robin) co na SW iSCSCI (slackware + bond) na SAS pole dava cca 100-120 MB/s, vzdy ale obe sitovky pripojeny pres jeden switch (3com) na DELU jsou SATA a docetl jsem se, ze PRIMO ten DELL, pokud ma SAS chova se uplne jinak
Vetsinou testuju, ze kopiruju 20 GB SQL backup ... no a ten samotny dell dava prave "jen" tech 80MB/s sakra ten nemuzu najit tu diskusi .... tak aspon tohle
4. RAID10 + SATA disky (bohuzel). MTU. Default takze 1500, pole umi samozrejme jumbo frames, xenserver taky ... Ale nezjistil jsem, zda switch ano ...
end_request: I/O error, dev sdc, sector 0 end_request: I/O error, dev sdf, sector 0 end_request: I/O error, dev sdc, sector 0 end_request: I/O error, dev sdf, sector 0Ovsem tyto hlasky chodi jen, kdyz: vytvaris novy virtualni disk, hybas s vitrualnim ulozistem jako celkem, kopirujes image a tak .. Pri chodu vitrualniho stroje to nedela ... Pro me je vysledek, ze to neresim, necham to zit takto .. Uvidim, co prinese xenserver 5.6 (ten nasadim az casem ..)
Když hrábnu do archivu, tak jsem tehdy ten multipath nastavoval takhle:
echo "0 2929686528 multipath 0 0 1 1 round-robin 0 2 1 8:0 20 8:16 20" | dmsetup create dma
Tušímže čísla "20" znamenaly délku dávky.
V podstatě je to úleva, že si s těmito hračkami nemusím hrát
Oni i Arecy se SAS portama dávají menší průchodnost na SATA disky než na SAS disky - se SATA diskama jsou v sekvenční průchodnosti asi o čtvrtinu slabší (řekněme 800 MBps vs 600 MBps). Ale občas čtu o konkrétních modelech RAIDových kastlí, které obsahují SASový expandér, že to s konkrétními modely SATA disků buď nefunguje vůbec, nebo třeba že to pro SAS provoz neumí využít multilane SAS link mezi HBA a expandérem, takže to jede jediným 300MBps lanem...
Ohledně MSI: http://www.fccps.cz/download/adv/frr/MSI/PCIe-MSI.html = otravně dlouhé teoretické čtení, rozumné řešení problému s tuhnoucím HBA z toho stejnak neplyne.
Uz davno, pamatujes
Vyzkoušejte a uvidíte.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
5.5.2009 21:48