Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
+------------+ +------------+ |SWITCH A +---------------------------+SWITCH B | +------------+ +------------+ | | | | | | | +------------------------+ | | | +-----------+ | | | | | | | | +------------------------+ +------------------------+ | eth0 eth1 eth2 | | eth2 eth1 eth0 | | 10gbit 40gbit 40gbit | | 40gbit 40gbit 10gbit | | | | | | | | | | | | | +-----+ | | +------+ | | | | | | | | | | | | bond0 | | bond0 | | | | | | | | | | | +--------+ | | +-----+ | | | | | | | | br0 | | br0 | | br0.10 VLAN10 | | VLAN10 br0.10 | | br0.20 VLAN20 | | VLAN20 br0.20 | | br0.30 VLAN30 | | VLAN30 br0.30 | | | | | | SERVER A | | SERVER B | +------------------------+ +------------------------+Myšlenka je poměrně jednoduchá. Jedná se o dva servery, které jsou napřímo propojeny 40Gb síťovkami. Cílem mého snažení je, aby servery mezi sebou komunikovaly napřímo a vše ostatní přes switche ven. Myslel jsem si, že vše naházím do bridgů, jak je vidět na "obrázku" a pomocí RSTP na switchích se pak vždy jedna z 10Gb cest zablokuje. STP na bridgi v linuxu jsem vypnul. Je ta myšlenka správná? Případně řešili byste to jinak? Nedaří se mi to totiž dostat do provozuschopného stavu (cyklí se to). Je nutné na switchích konfigurovat MSTP nebo vystačím se samotným RSTP? Všechny porty na switchi jsou VLAN trunky. S MSTP nemám žádné zkušenosti, zkoušel jsem to s ním nastavit, ale výsledek byl podobný.
Můj první záměr a zároveň pokus bylo použití levných switchů (T1700G-28TQ), které umí stack. A do obou jsem poslal 4x1Gbit LACPem. S tím, že tu 40G linku jsem provozoval uplně odděleně. Problém těch switchů byl, že se to chovalo podivně - stačilo odpojit jakýkoliv kabel a ten switch v tu chvíli ztratil obvykle 5-8 ICMP paketů na všech portech! Pokud jsem jeden ze switchů vypnul, tak to bylo mnohem horší. Řešil jsem to s výrobcem a bylo mi řečeno, že je to vlastnost. Na nějaké další pokusy se stackem jsem v tu chvíli ztratil chuť.U switchů je na tohle potřeba dávat bacha. Řešil jsem něco podobného - switch to umí, paráda, podíváme se, co o tom lidi píšou na netu: "při výpadku jednoho switche stack 20s nebo minutu neswitchuje, když switch zapojíte zpátky, tak to neswitchuje 20s, podle výrobce je to vlastnost, je potřeba 4x dražší switch".
Rozhoupal jsem se to celé přestavět a koupil 10G switche (Ubiquiti EdgeSwitch 16 Xg), které neumí stack a jednoportové 10G síťovky do serverů.To chápu, pokud někdo ví o 10G switchích, které umí stack a nestojí 200+ kKč jeden, tak bych o tom rád věděl.
A celé to zapojil tak, že právě tu redundanci zajistím skrz 40G síťovky. S tím, že to celé pohlídá RSTP, který jsem popravdě nikdy na podobné věci nepoužíval.No, teoreticky by to tak, jak to máte zapojené a nastavené, mělo fungovat tak, jak chcete. Když je STP na těch linuxech vypnuté, měly by switche shodit buď tu linku mezi sebou, nebo jednu mezi switchem a serverem. Pokud to nefunguje, tak bych zkusil tcpdump na tom Linuxu a zkusit vysledovat, jestli tam něco nazahazuje BPDU rámce, kterými se ta smyčka detekuje. Jinak bych ale souhlasil s Maxem, tohle řešení je dost divné. Nehledě na to, že ten bridge je čistě softwarová záležitost, takže je otázka, jestli přes něj těch 10Gbit vůbec projde. Řešil jsem něco podobného (corosync cluster mezi více servery, switche neumí stackovat) a udělal jsem to jednoduše tak, že mám switche (4) zapojené do kruhu a MSTP na tom. Každý server je zapojený do dvou switchů přes bond rozhraní v režimu active-passive. Zkoušel jsem tomu různě vytahovat kabely a podle všeho jsem si nikam nenapsal, co se dělo, ale mám za to, že z toho byly výpadky do 3 sekund, což by ten cluster měl přežít. Je tu samozřejmě jedna možnost, jak to může vypadnout: když jeden z těch switchů vytuhne, ale nevypne se, tj. připojené servery na svých síťovkách nebudou mít link down. V takovém případě ten bond nemá důvod přepnout aktivní linku na druhý switch a server nebude v síti. Dá se to řešit tak, že ten bond do sítě posílá nějaké pakety (ARP nebo echo request IIRC) a prohlásí tu linku za nefunkční, když se nic nevrací - což ovšem samozřejmě znamená, že musí běžet to, co na ty pakety má odpovídat. Nebo se to dá řešit tak, že když po vás někdo chce HA řešení, tak se holt musí plácnout přes kapsu a koupit pořádné switche. (Akorát teda pokud chcete 10Gbit a stack, tak si připravte tak půl milionu.) Jinak k RSTP vs. MSTP - dokud bude fyzická topologie té sítě pro všechny VLANy stejná, stačí vám RSTP. Pokud ne, musíte počítat s tím, že RSTP řeší čistě fyzickou síť bez ohledu na VLANy a tudíž že přeruší i smyčky, které vzhledem k nastavení VLAN ve skutečnosti smyčku netvoří. V takových případech musíte použít MSTP
Takove Delly S4048 z druhe roky jsou za uplnou hubicku (my je berem za nejakych 1400 EUR bez DPH a dopravy z UK).Tak moment, 48x10Gbit + 6x40Gbit, podporuje stacking, to celé za 40kKč (plus SFP moduly, hádám)? Ehm, v čem je háček?
Akorat tedy se nic nebroadcastuje, ve vpsFree setupu mame na kazdem portu toho switche proste navazanou jednu BGP session na spojovacce.Jo, to jsem myslel. Asi, přece jenom v BGP a BGP terminologii se úplně nevyznám.
Tiskni Sdílej: