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 »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
Mám nějaké zkušenosti s implementací databázových systémů po NFS (převážně SAP nad Oracle databází, nicméně i jiné), a proto bych se s vámi o ně chtěl podělit.
V „domácím“ prostředí, kde se pro databáze používá DAS (Direct Attached Storage), dokáže spolehlivé centralizované úložiště přinést mnoho výhod, centralizaci úložných kapacit, zjednodušené kapacitní plánování, zjednodušenou údržbu a vyšší výkon. Na druhou stranu samozřejmě centralizované úložiště přináší nový single point of failure (bod selhání); pokud přijdete o síťové připojení k úložišti, nebo dokonce o celé úložiště, máte problém. Proto je při návrhu úložného systému potřeba dbát na patřičný redundantní návrh, například se inspirovat návrhem Zdeňka Burdy, případně se obrátit na nějakého spolehlivého distributora úložných řešení.
Peníze, flexibilita a ještě jednou peníze, to je cena za použití FC/SAN centralizovaného storage řešení. SAN (Storage Attached Network) infrastruktura nabídne skvělý výkon, nicméně náklady na její vybudování jsou vysoké (jen takové jedno FC HBA stojí 10 000, ale potřebujete dvě, protože si nemůžete dovolit ztratit přístup ke svému úložišti jen kvůli závadě na HBA, a kvalitní FC fabric switche jsou dražší než kvalitní ethernetové switche). Stejně tak vysoké jsou i náklady na údržbu takovéto sítě. Jak již jsem uvedl v úvodu článku, pro správu FC fabric potřebujete většinou další lidi, protože běžní síťoví administrátoři nemají o FC sítích potuchy.
Prostě vysoká spolehlivost něco stojí a ne každý si to může/chce v dnešní době dovolit. Navíc za stejnou cenu, za kterou dokážete vybudovat FC/SAN síť, dokážete také vybudovat vysoce spolehlivou ethernetovou síť se srovnatelným výkonem, kterou navíc můžete použít i na něco více než jen storage traffic. Používat jako centralizované úložiště něco na bázi FC/SAN je mimo finanční možnosti většiny malých společností, přestože by jim centralizace úložných kapacit pro jejich data velice prospěla.
Důvod, proč byl zvolen protokol NFS, je poměrně prostý: NFS je protokol jednoduchý na implementaci a podporují jej všichni vendoři podnikového NAS (Network Attached Storage) hardwaru. Jedná se také o léty ověřený protokol, který na druhou stranu umí v ledasčem zklamat a překvapit. Stejně jako každý nástroj i tento by se měl používat s rozvahou. V prostředí malých společností je NFS (případně iSCSI) asi jediná možnost, kterou se společnost může vydat v případě, že by chtěla své úložné kapacity centralizovat.
V podnikovém prostředí se však cestou NFS vydávají také a mnohdy jej preferují oproti Fibre Channel SAN (Storage Attached Network), i když už mají SAN infrastrukturu vybudovanou. Nemají zatím dostatečnou důvěru v FCoE a investiční náklady do 8Gb/s FC fabric by byly obrovské, proto si je chtějí odpustit alespoň pro ty méně kritické systémy. Ať už jsou důvody jakékoli, děje se to, a proto by byla škoda o tom nic nevědět.
Protokol NFS vyvinula společnost Sun Microsystems v roce 1984, aby umožnila uživatelům přístup k datům na síťovém úložišti stejným způsobem, jakým k nim přistupují v případě lokálních disků. První verze NFSv1 nikdy nespatřila světlo světa mimo Sun Microsystems, sloužila pouze k interním experimentálním účelům. Druhá verze NFS – NFSv2 se objevila v březnu 1984 v podobě RFC 1094 a na transportní vrstvě podporovala jen UDP (User Datagram Protocol) – fungovala tedy zcela bezstavově. Stejně tak maximální velikost souboru byla 2^31 bytů (používal se signed 32 bit offset), tedy 2 GB a maximální velikost READ/WRITE operace byla 8 kB.
NFSv3 přišla na svět v červnu roku 1995 v podobě RFC 1813 a novinkou byla podpora větší velikosti souborů (offset je nyní unsigned 64 bit int) a velikost největšího souboru tak (pokud se spokojíme s 2^64) nyní záleží na serveru a na tom, jaký používá souborový systém. NFSv3 také přichází s podporou asynchronních zápisů na straně serverů, což zvyšuje výkon při zápisu. Nejdůležitější změna však byla pravděpodobně podpora pro protokol TCP na transportní vrstvě. Tímto začalo být možné NFSv3 více používat i například v prostředí sítí WAN (Wide Area Network). Nicméně, dovolil bych si podotknout, že někteří distributoři nabídli podporu pro TCP i pro NFSv2, nikoliv však SUN, ten přidal podporu pro TCP u NFSv2 až s přidáním podpory pro TCP s NFSv3.
Protokol NFSv3 je v současné době pravděpodobnější nejpoužívanější implementace NFS. A to i v případě databázových aplikací, přestože se stále jedná o bezstavový protokol (i nad stavovou transportní vrstvou TCP).
V listopadu 2000 byl představen protokol NFS ve své čtvrté verzi, a to v podobě RFC 3010, který byl následně revidován v dubnu 2003 prostřednictvím RFC 3530. Jeho vývoj byl značně ovlivněn existencí jiných síťových protokolů, jako je CIFS (Common Internet File System) od Microsoftu (který na Linuxu implementuje projekt SAMBA). NSFv4 je první verze, kterou vydala Internet Engineering Task Force, poté co ji SUN předal kontrolu nad protokolem. V této verzi NFS může být protokol již plně stavový. Nicméně ještě nedávno většina implementací NFSv4 nebyla zrovna… no, spolehlivá. Nicméně časy se mění a NFSv4 vidím jako budoucnost pro databázové i jiné aplikace, které vyžadují dobrý poměr cena/(výkon+spolehlivost).
Minimálně společnost Oracle si uvědomuje význam NFS v databázových prostředích, a proto je ve verzi Oracle 11g k dispozici vlastní implementace Oracle DirectNFS (dNFS), ostatně tento přístup je pro Oracle běžný. Když byla důležitá správa paměti, Oracle šel na to cestou „tak mi dejte stránky paměti a já se o ně budu starat sám“. Nyní, když je důležitý výkon NFS, Oracle chce čistý TCP/IP socket, on už se o vygenerování optimálního NFS requestu postará sám. Ostatní databáze tuto myšlenku až tak nepodporují, nicméně většina z nich umí více či méně dobře po NFS fungovat.
Důvodů pro vývoj Direct NFS bylo několik, předně se instalace databáze Oracle s NFS začaly rozšiřovat, na což musel Oracle nějak zareagovat. Jeden z problémů při použití kernelového NFS je, že spousta administrátorů neví, jak vlastně NFS pro dobrý výkon v databázových aplikacích nastavit, což vede k nežádoucímu dopadu na výkon i spolehlivost. Dále pak neuspokojivá implementace NFS ve Windows a odstranění dvojitého cachování dat. Při použití kernelového NFS dochází ke cachování informací jak v prostoru kernelu, tak v uživatelském prostoru v samotné databázi. Pokud je NFS a databáze více provázaná, k dvojitému cachování již nedochází, což vám umožňuje dát databázi k dispozici více paměti.
Konfigurace dNFS se ukládá v souboru $ORACLE_HOME/dbs/oranfstab nebo si ji dNFS umí načíst přímo ze souboru /etc/mtab. Syntaxe konfiguračního souboru oranfstab je následující:
server: jméno serveru path: první ip adresa/fqdn path: druhá ip adresa/fqdn export: /vol/oradata mount: /mnt/oradata
Položka server určuje jméno serveru, položky path určují, na kterých IP adresách je možné daný server najít. dNFS umí i bez využití bondingu/port allocation/etherchannelu využít více redundantních linek k přístupu ke storage systému a zvýšit tak síťovou propustnost. Takovýchto cest ke storage systému můžete mít až 4 – slouží jak pro zvýšení výkonu, tak ke zvýšení odolnosti proti výpadkům (za předpokladu dobrého síťového návrhu). Položka export určuje zdrojovou cestu, položka mount ji doplňuje o cíl, kam má být zdroj v hierarchii souborového systému připojen.
Ve výchozí konfiguraci není Oracle Direct NFS zapnuto, jeho zapnutí provedete jednoduše pomocí příkazů:
cd $ORACLE_HOME/lib mv libodm11.so libodm11.so_stub ln -s libnfsodm11.so libodm11.so
Více podrobných informací, včetně výkonnostních benchmarků, naleznete v Oracle Whitepaper – Oracle Database 11g Direct NFS Client (PDF).
V dokončení článku popíšu postřehy z implementace databáze Oracle přes NFS.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
16.4.2010 07:24
okbob | skóre: 30
| blog: systemakuv_blog
| Benešov
rekl bych ze kdysi jsem to videl i na cswu.cz, ale uz jsem to nenasel
to je cena za použití FC/SAN centralizovaného storage řešení. SAN (Storage Attached Network) infrastruktura nabídne skvělý výkonMělo být spíš Storage area network, ne?
Proč centralizové uložiště?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
16.4.2010 10:54
16.4.2010 16:53
19.4.2010 11:54
27.4.2010 13:59