Společnost Apple slaví padesáté narozeniny. Založena byla 1. dubna 1976.
FreeTube, desktopový klient pro YouTube využívající lokální API, byl vydán ve verzi 0.24.0. Toto velké opravné vydání implementuje SABR (Server-Based Adaptive Bit Rate), což řeší část nedávných problémů s načítáním videí z YouTube, a aktualizuje základní komponenty jako Electron nebo přehrávač Shaka Player.
Je tu opět apríl. O víkendu zmizel kamion s 12 tunami tyčinek KitKat. Firmy to využívají k aprílovým žertům. Groupon má super akci. Koupíte 1 tyčinku a dostanete 100 zdarma. Ryanair si přelepil letadla. Šéf Outlooku se ptá, proč mají v baráku 14 beden tyčinek KitKat (𝕏). Prusa Research představuje Prusa Pro ACU a vysvětluje proč přílišné sušení škodí vaším filamentům. Telefon Sony Xperia má miliónnásobný zoom (𝕏). PC.net představil Super Ultrabox 2600 se zajímavými parametry. Další aprílové novinky například na April Fools' Day On The Web.
Společnost OpenAI, která stojí za chatovacím robotem s umělou inteligencí (AI) ChatGPT, získala od investorů 122 miliard USD (2,6 bilionu Kč). Hodnota společnosti tak dosáhla 852 miliard dolarů (více než 18 bilionů Kč). Nejnovější kolo investování se stalo největší, jaké zatím firma uskutečnila, a peníze mají posílit ambiciózní plány rozšíření výpočetní kapacity, datových center a nábor talentů.
Nástroj k identifikaci občanů v on-line komunikaci s úřady byl dnes dopoledne zhruba dvě hodiny částečně nedostupný. Problém se objevil kolem 09:00 a podařilo se ho vyřešit kolem 11:00. Částečně nedostupná byla služba Národní identitní autority (NIA), problémy podle DIA (Digitální a informační agentura) ovlivňovaly přihlašování například i přes bankovní identitu. „Dostupnost NIA byla plně obnovena, přihlášení k digitálním službám
… více »Eben Upton oznámil další zdražení počítačů Raspberry Pi kvůli růstu cen pamětí a představil Raspberry Pi 4 s 3 GB RAM za 83,75 dolarů.
Anthropic patrně omylem zveřejnil celý zdrojový kód svého CLI nástroje Claude Code prostřednictvím přiloženého sourcemap souboru v npm balíčku. Únik odhalil doposud nijak nezveřejněné funkce jako je například režim v utajení, autonomní agent 'KAIROS', orchestrace multi‑agentů, režim snění nebo dokonce virtuální mazlíček Buddy. Zajímavostí je detekce naštvání uživatele pomocí obyčejného regexpu. Anthropic rychle odstranil sourcemap a vydal opravu, nicméně kopie kódu se již stihly na GitHubu rozšířit mezi prostým lidem.
Copilot automaticky vkládal do pull requestů 'propagační tipy', reklamní text se na GitHubu objevil ve více než jedenácti tisících pull requestech. Po vlně kritiky byla tato funkce zablokována a produktový manažer Tim Rogers připustil, že umožnit Copilotovi upravovat cizí pull requesty bez vědomí autorů byla chyba.
Je 31. března a tedy Světový den zálohování (World Backup Day). Co by se stalo, kdyby Vám právě teď odešel počítač, tablet nebo telefon, který používáte?
Digitální a informační agentura (DIA) přistupuje ke změně formátu důvěryhodného seznamu České republiky z verze TLv5 na verzi TLv6, která nastane 29. dubna 2026 v 00:00 (CET). Ke změně formátu důvěryhodných seznamů členských států (tzv. Trusted Lists) dochází na základě změn příslušné unijní legislativy. Důvěryhodné seznamy se používají v rámci informačních systémů a aplikací zejména pro účely ověřování platnosti elektronických
… více »Kdysi dávno se zrodil standard IEEE 802.1Q, umožňující konsolidovat jednotlivé fyzické ethernetové sítě do jedné fyzické sítě, která je oddělena pomocí logických VLAN. V roce 2007 se začaly práce na vyšší konsolidaci síťové infrastruktury; v současné době má většina firemních datových center minimálně dvě oddělené fyzické sítě, storage síť (většinou Fibre Channel) a produkční ethernetovou síť. Standard FCoE se zrodil proto, aby bylo možné tyto dvě fyzické sítě sloučit do jedné fyzické sítě a ušetřit tak náklady na hardware, kabeláž, lidi, kteří se o sítě starají, prostor, chlazení a spotřebu. Tento standard byl schválen v roce 2009 a v současné době bývá nasazován v datových centrech po celém světě.
Důvod pro nasazení FCoE jsou jako vždy peníze. Pokud provozujete nějaké aplikace na kterých záleží, není pochyb, že potřebujete využít nějaké spolehlivé diskové pole pro ukládání dat. Nicméně je velice nákladné udržovat ethernetovou síť pro připojení uživatelů k serveru a separátní fyzickou Fibre channel síť pro přístup k datům. Většinou potřebujete mít obě sítě plně redundantní, protože si nemůžete dovolit výpadky, a dostatečně dimenzované. Mít gigabitovou ethernet síť a 4Gb Fibre Channel síť něco stojí. S příchodem 10Gb ethernetu se otevřela možnost (z pohledu kapacity) využít tuto síť i jako platformu pro připojení k diskovým polím. Jediné, co chybělo, byl patřičný standard, který by umožňoval konsolidaci v praxi provést. V současnosti je už standard k dispozici a začínají se objevovat i zařízení, která jej podporují.
Oba velcí hráči na poli storage sítí (Cisco i Brocade) už v současné době nabízejí produkty, které podporují FCoE. V případě produktů Cisco se jedná o produktovou řadu Cisco Nexus. Stejně tak společnosti jako QLogic, Emulex a Brocade začaly nabízet CNA adaptéry pro servery, které spojují jak NIC (Network interface controller), tak HBA (Host bus adaptér) do jediného zařízení. Dá se očekávat, že se brzy s podporou pro FCoE přidají i společnosti, které se v minulosti neorientovaly na storage sítě. Pokud tak neučiní, může se stát, že jim ujede vlak…
V současné době je na trhu k dispozici i první storage platforma, která nativně podporuje FCoE (sice ne zrovna dobře, ale o tom později). Jedná se o produktové řady V-series a FAS společnosti NetApp. Nicméně i pokud vaše disková pole FCoE nepodporují, pořád můžete výhod FCoE využít. Například Brocade 8000 obsahuje i běžné FC porty a pokud do těchto portů připojíte vaše diskové pole, které podporuje Fibre Channel, tento switch provede zapouzdření FC3, FC4 a FC5 vrstvy do ethernetových rámců s ethertype 0x8906. Dále pak probíhá přenos dat pomocí protokolu FCoE.
V současné době je na trhu, pokud je mi známo, jen jeden výrobce, který nabízí storage platformu s nativní podporou FCoE. Jak jsem již uvedl, jedná se o společnost NetApp s produktovou řadou V-Series a FAS. Bohužel v současné době, pokud si kupujete 10Gb karty, si můžete vybrat mezi běžnými 10Gb/s NIC a mít k dispozici ethernet (iSCSI, NFC, CIFS, …) nebo 10Gb/s CNA a mít k dispozici pouze FCoE. Zatím není možné využít CNA adaptéry k transportu běžného ethernetového provozu. Na druhou stranu, NetApp slibuje, že tato funkcionalita bude k dispozici během léta roku 2010.
V současné době se pracuje na podpoře FCoE v linuxovém jádře, jedná se o projekt Open-FCoE.org. Tento projekt si klade za cíl vytvořit softwarový FCoE initiator a target ovladač, který vám umožní užívat si FCoE i s běžným NIC adaptérem bez potřeby vlastnit CNA kartu. V budoucnu by tedy mělo být používání FCoE stejně snadné, jako je v dnešní době používání iSCSI, a to nejen v Linuxu, ale i v jiných operačních systémech (*BSD, Windows i Mac OS X). Jen bude potřeba, aby vaše síť splňovala nějaké požadavky, jako je například podpora Jumbo Frames, o tom ale až po reklamě :)
Od verze linuxového jádra 2.6.29 je Open-FCoE součástí vanilkového jádra. Aplikaci FCGW (Fibre Channel Gateway) můžete použít jako rozhraní mezi nativní FC fabric a FCoE initiatorem (pokud si chcete možnosti FCoE vyzkoušet bez toho, abyste kupovali řadu Nexus 7k nebo Brocade 8000, které umí tuto gateway poskytnout také). Na vývoji Open-FCoE se z velké míry podílí například společnost Intel, avšak i společnost Sun Microsystems v současné době nabízí svobodnou implementaci FCoE v operačním systému OpenSolaris.
Už z názvu obou protokolů je patrný rozdíl. Zatímco FCoE pracuje na ethernetové vrstvě sítě, iSCSI staví až nad TCP stackem. To jednoduše znamená, že FCoE funguje, jen pokud jsou initiator i target ve stejném ethernetovém segmentu (L2 doméně), kdežto iSCSI nemá problém, pokud používáte na vaší síti routování. Nicméně pokud využijete například Fibre Channel over IP, můžete routovat jak běžný FC, tak i FCoE traffic. [srovnání různých blokových storage protokolů na stránkách Network Appliance] iSCSI se dá nasadit na sítích, kde může docházet ke ztrátám paketů, a není k jeho nasazení zapotřebí mít 10Gb ethernet (pro FCoE oficiálně ano, ale Open-FCoE funguje i na 1Gb/s ethernetu). Nicméně pro využití FCoE musí vaše síťová zařízení podporovat PAUSE frame a class based pause flow control (PFC), což není zapotřebí pro využití iSCSI. Idea využití class based PFC je v tom, že pokud dojde k zahlcení síťového zařízení a linka mezi switchi/zařízením nemá dostatečnou propustnost, dojde k pozastavení přenosu rámců s nižší prioritou a rámce s vyšší prioritou budou přeneseny. Ano, hádáte správně, FCoE rámce budou ve třídě s nejvyšší prioritou :-). Dále je nutné mít pro FCoE k dispozici síť, která podporuje Jumbo Frames, protože FC payload je 2 112 bytů.
V současné době se pracuje na 16Gb/s FC (plánované uvedení v roce 2011). Práce budou pravděpodobně pokračovat, nejspíše také bude publikován standard, nicméně nedá se očekávat nějaké masivní nasazování 16Gb/s FC sítí, protože brzy přijde na trh 40Gb/s a 100Gb/s ethernet a trh se nejspíše bude ubírat směrem právě k FCoE na 40Gb/s a 100Gb/s ethernetu. Ale není potřeba panikařit; jakákoli migrace stojí peníze, a proto se pravděpodobně nikde nic rozsáhle migrovat nebude. Každá organizace by si však, pokud v blízké době plánuje investovat do storage sítě, měla pořádně promyslet, jestli se bude jednat o FCoE síť, nebo jen o FC. A pokud jen o FC, mít připravený plán na její začlenění do budoucí FCoE infrastruktury.
Dále se také dá očekávat že započne válka, minimálně ve větších společnostech, které mají oddělené síťové a storage oddělení. V současné době je zvykem, že storage oddělení vlastní switche, vlákna i disková pole a patřičně se o tuto storage síť také starají, kdežto s větším nasazením FCoE budou muset obě skupiny, jak storage, tak síťaři, více spolupracovat a každý storage specialista ví, jak je to se síťaři… nic neumí, jsou pomalí a na co sáhnou, to pokazí… :-D
Podrobnější představení standardu, technologií a technických detailů bude následovat v dalším článku.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Ocenil bych jednu informaci – ptal jsem se na to i borce na jedné konferenci (po přednášce o tom jak je FCoE super a máme si ho koupit) – jaká je režie IP protokolu? Zajímá mne srovnání iSCSI a FCoE za jinak stejných okolností. Rád bych slyšel konkrétní čísla, protože od něj jsem se dozvěděl, že režie IP protokolu je strašně velká. A vůbec, je to nesrovnatelné, protože na FCoE je potřeba mít 10Gbps ethernet a na tom on iSCSI nikde neprovozoval. Takže, pokud budu mít FCoE a iSCSI na stejně rychlé síti (ať už 1 nebo 10 nebo třeba 100 Gbps), o kolik bude FCoE rychlejší?
Svého času jsem provedl experiment - náhodou se mi na stole sešlo železo, které ho umožňovalo: dvě síťovky Myri-10G, externí RAIDový box s řadičem Areca na úrovni ARC-1680 (ale propoj PCI-e pouze x4), nějaký server s čipsetem Intel 5000P (CPU Xeon tuším 5300 series), jako koncové zařízení (iSCSI initiator) nějaký "průmyslový desktopový" board tuším s i945, který podporuje v x16 slotu i jiné věci než grafiku (zde iSCSI kartu).
Desktop | Server | | RAID | 10Gb Eth <======> 10Gb Eth | PCIe x4 <=====> PCIe x4
Použil jsem "alternativní" softwarový SCSI target pro Linux SCST, který mj. obsahuje také iSCSI front-end. Jako back-end umí použít libovolné blokové zařízení buď s použitím systémového bufferingu (VM), nebo bez bufferingu v "direct módu" (bDIRECT), nebo snad i s přímým relayem SCSI příkazů. SCST žije celý v kernelu a je optimalizován na průchodnost.
Mám pocit, že Intel I/OAT v čipsetu 5000 jsem nepoužil - jednak mi to v Linuxu nechtělo chodit, jednak to možná nechodí se síťovkou jinou než Intel, jednak to vlastně v Linuxu má odlehčovat jenom "copy to user", což je dost k ničemu, když SCST žije celý v kernelu (viz níže).
Samotný RAID mi dával přímo proti serveru sekvenční LBA čtení cca 600 MBps. Když jsem ho přes iSCSI namapoval "klientovi" (initiatoru) na tom desktopovém stroji, tak desktopový stroj z toho vytáhl sekvenční LBA čtení 500 MBps (v jedné relaci). Provedl jsem jenom nějaké lehké ladění dostupnými prostředky:
Ono je nakonec možné, že pro většinu aplikací ty sekvenční MBps jsou honěním trička. Důležitým číslem jsou IOps. Pokud uvážíte nevelkou standardní hloubku TCQ front na několika zúčastněných vrstvách, tak se do toho poměrně přímo promítá doba zpracování jednotlivého požadavku, potažmo i přenosové latence. Latence na běžném Ethernetu (neřku-li TCP/IP) jsou nepochybně delší, než latence na klasických storage sběrnicích.
V tomto směru bohužel žádné benchmarky nemám.
Strašlivá režie vrstev TCP/IP má několik faset. Pokud se týče ztráty kapacity na vrub enkapsulace, jsou to tuším nějaké jednotky procent při MTU=1500 (= ztráta zanedbatelá). Jiná věc je "processing overhead", tj. spotřeba procesorového výkonu na počítání algoritmů a spotřeba průchodnosti sběrnic na "zbytečné" kopie dat. Nějaká čísla jsou tady, ovšem podle mých experimentů zjevně neaktuální pro dnešní hardware - mají snad nějakou relativní hodnotu. A ještě jiná věc je režie způsobená reakcemi "TCP/IP flow control" (regulační smyčky) - tj. rozjezd spojení, přibržďování oknem, a nedejbože retransmit při ztrátě paketu, ó hrůzo.
Protože mě storage hardware v podstatě neživí, dovolím si pár odhadů selským rozumem a laických pivních prohlášení "Hrozný overhead iSCSI" znamená víceméně tolik, že netriviální logika vrstev TCP/IP se nesnadno implementuje v čistém hardwaru, a navíc zejména za nepříznivých okolností (vytížení sítě směsí různého provozu) může projevovat náhodné vyšší latence. Proto si vymyslíme jednodušší enkapsulaci celých FC rámců, která pojede přímo nad Ethernetem, nebude mít vlastní garanci doručení, proto bude implementačně jednoduchá. Garanci doručení pak doženeme jednoduchými recepty, známými z minulosti (absolutní priorita pro náš provoz, a (802.3x)802.1bb flow-control v Ethernetu) - že jednoduché recepty mohou mít své mouchy, zejména v prostředí se složitým mixem "best effort" provozu, to ať si vyřeší někdo jiný. Když dáme povinně 10Gb Ethernet, tak s trochou štěstí bude úzké hrdlo někde jinde (reálné targety nebo initiatory). Ostatně "přibržďování toku" si v moderním SCSI provozu řeší TCQ s podobným efektem, jako má TCP receive window (až na to, že ztráta FCoE paketu znamená SCSI command timeout, což je docela závažná chyba).
Abych nebyl zase tolik zbytečně ošklivý, ono má asi smysl, v nějaké složitější síti, tj. v systému, kde spolu soupeří spousta datových toků na vrstvách síťové komunikace a storage komunikace, aby storage komunikace měla obecně přednost - aby se provoz škrtil a hltil přednostně na internetové vrstvě (kde je to jaksi snáze omluvitelné), ale aby počítače měly pokud možno vždycky dostupné disky. Je možné, že to v globále vede k lepší stabilitě systémů. Podmínkou je, aby nějaká aplikace nežrala IO bandwidth "nadoraz, co to dá" - to je právě problém s absolutní priorizací. Stejně jsem ale zvědav, jak jsou na FCoE ošetřeny problémy typu "head of line blocking". A mimochodem, té priorizace by se možná dalo dosáhnout třeba i levněji s klasickými switchi, pomocí 802.1p, ne?
Jestli někdo potřebuje storage síťku na capture HD videa, tzn. vyžaduje striktně deterministické odezvy (dokonce nejen od blokové vrstvy, ale od filesystému, chacha) tak by možná měl sáhnout spíš po FC než po FCoE.
iSCSI HBA třeba od Adaptecu mívaly tuším svého času prostě jenom síťovku Intel, která byla vybavena trochu jinou option ROMkou a ovladači pro Windows, aby se to v BIOSu tvářilo jako SCSI řadič. Čili nějaký kompletní offload iSCSI do hardwaru se v podstatě nekonal.
Když se FCoE před časem začalo objevovat, mluvilo se o tom, že ethernetové switche pro tento provoz jsou stavěny speciálně na super-nízké latence. Čili není to normální kancelářský Ethernet. Máte někdo představu, kolik tyhle hračky stojí? Je to cenově blízko ke konvenčnímu Ethernetu, nebo spíš k FibreChannelu?
>> Strašlivá režie vrstev TCP/IP má několik faset.
>>
> doteď jsem byl dojmu, že fazeta je skosená hrana.
> nebo se normálně používá i v tomhle kontextu?
>
obrazně řečeno. Několik aspektů. Fakt je, že jsem to slovo takhle použité potkal asi spíš v anglině než v češtině. Omlouvám se tedy za neblahý novotvar
F.Ryšánek
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
24.2.2010 00:58
24.2.2010 11:45
24.2.2010 12:48
