abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 0
včera 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 8
včera 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
včera 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 7
16.10. 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
16.10. 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
16.10. 22:04 | Pozvánky

Rádi bychom vás pozvali na přednášku o frameworku Avocado. Jedná se o testovací framework další generace, inspirovaný Autotestem a moderními vývojovými nástroji, jako je třeba git. Přednáška se bude konat 23. října od 17 hodin na FEL ČVUT (Karlovo náměstí, budova E, auditorium K9 – KN:E 301). Více informací na Facebooku.

… více »
mjedlick | Komentářů: 0
16.10. 21:44 | Bezpečnostní upozornění

Nový útok na WPA2 se nazývá KRACK a postihuje prakticky všechna Wi-Fi zařízení / operační systémy. Využívá manipulace s úvodním handshake. Chyba by měla být softwarově opravitelná, je nutné nainstalovat záplaty operačních systémů a aktualizovat firmware zařízení (až budou). Mezitím je doporučeno používat HTTPS a VPN jako další stupeň ochrany.

Václav HFechs Švirga | Komentářů: 3
15.10. 00:11 | Zajímavý projekt

Server Hackaday představuje projekt RainMan 2.0, aneb jak naučit Raspberry Pi 3 s kamerovým modulem pomocí Pythonu a knihovny pro rozpoznávání obrazu OpenCV hrát karetní hru Blackjack. Ukázka rozpoznávání karet na YouTube. Zdrojové kódy jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 0
14.10. 15:11 | IT novinky

Online obchod s počítačovými hrami a elektronickými knihami Humble Bundle byl koupen společností IGN. Dle oficiálních prohlášení by měl Humble Bundle dále fungovat stejně jako dosud.

Ladislav Hagara | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (0%)
 (0%)
 (0%)
 (0%)
 (100%)
 (0%)
Celkem 1 hlasů
 Komentářů: 0
    Rozcestník
    Štítky: není přiřazen žádný štítek

    Vložit další komentář
    xkucf03 avatar 24.2.2010 00:58 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Režie IP
    Díky za článek :-)

    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ší?
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    24.2.2010 01:41 Stanislav Petr | skóre: 27 | Praha
    Rozbalit Rozbalit vše Re: Režie IP
    Obecne u iSCSI zacina byt znatelna zatez na iniciatoru uz kolem 600Mbps pri pouziti bezne sitove karty, takze 10Gbps adapter tak trochu nepripada v uvahu. iSCSI se da celkem rozumne pouzivat na rychlosti 1Gbps pri pouziti specialni karty (http://qlogic.com/Products/SANandDataNetworking/iSCSIAdapters/Pages/iSCSIAdaptersHome.aspx). Ale takovehle iSCSI adaptery se prave vyrabeji do rychlosti max. 1Gbps, takze zadne konkretni sorvnani cisel existovat nemuze...
    No jo... Co bych cekal od systemu, kterej se vypina tlacitkem start... http://glux.org
    24.2.2010 06:35 kyytaM | skóre: 35 | blog: kyytaM | Bratislava
    Rozbalit Rozbalit vše Re: Režie IP
    Iba uvaha - pri pouziti kvalitnej NIC s TCP/UDP offloadom (mala by sa odburat velka cast rezie spojena so sietovym prenosom) by mala byt zataz obmedzena prevazne na reziu samotnej iSCSI vrstvy (teoreticky). Je to aj v realite tak?
    24.2.2010 09:31 Stanislav Petr | skóre: 27 | Praha
    Rozbalit Rozbalit vše Re: Režie IP
    tcpoffload je u iSCSI pokud chcete dosahovat rozumnych rychlosti skoro podminkou... Ale stejne bezna karta s tcpoffload ani zdaleka nevyrovna specialni iSCSI karte (prakticky testovano na - prakticky testovano na Intel PRO 1000/F a 1000/MF.
    No jo... Co bych cekal od systemu, kterej se vypina tlacitkem start... http://glux.org
    24.2.2010 09:34 zigi | skóre: 12
    Rozbalit Rozbalit vše Re: Režie IP
    Mohu se zeptat, v cem tak zasadnim se lisi vyuziti lepsi sitove karty, Linuxu a nejake implementace iSCSI targetu od pouziti toho specializovaneho HBA? Jestli jsem to aspon trochu pochopil, tak veskere nastaveni sdilenych prostredku se resi pres tuto kartu (tedy obsahuje implementaci iSCSI - firmware, ovladac a nejaky program pro nastaveni z user space)?
    24.2.2010 10:58 JZ | skóre: 18 | blog: tucnakovo_putovani
    Rozbalit Rozbalit vše Re: Režie IP
    Obecně použití speciálního HW uleví zátěži systému, protože ten pak nemusí funkci tohoto adaptéru emulovat (např. u FCoE tedy nemusí řešit zapouzdření FC do Ethernetových rámců systém, ale řeší ho HW).
    There can be no success without sacrifice!
    24.2.2010 18:47 zigi | skóre: 12
    Rozbalit Rozbalit vše Re: Režie IP
    To je mi jasny, ale protoze s FC/iSCSI nemam zatim zadnou primou zkusenost, tak me zajima, jak se pri pouziti takovychto zarizeni konfiguruje sdileni disku, popr. diskoveho oddilu (jak pres FC tak i za pomoci HBA).
    Pro linux je nekolik implementaci iSCSI (TCP/IP - Ethernet), pomoci kterych se da nasdilet disk/oddil a specifikovat, kdo se k nemu muze pripojit.

    Otazka: Da se v linuxu pouzit FC pro propojeni nekolika pocitacu (jako klasicka ethernet sit) a co se pro FC na linuxu pouziva? Diky
    Marek Stopka avatar 25.7.2010 23:49 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Režie IP
    Pokud myslíš, jako udělat si diskové pole na Linuxu, tak ano, ale potřebuješ k tomu FC HBA, které podporuje v linuxovém kernelu target mode.
    24.2.2010 09:43 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Režie IP

    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:

    • jako nejrychlejší pro tento typ zátěže se ukázal SCST režim "bDIRECT" (bufferovaný režim dával asi 300 MBps - což při random zátěži nemusí být k zahození)
    • pochopitelně jsem použil Jumbo framy o běžné maximální velikosti 9 kB
    • tušímže jsem trochu poladil "maximum window" parametry TCP stacku na obou koncích na maximální hodnotu

    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? :-)

    [:wq]
    gtz avatar 24.2.2010 11:45 gtz | skóre: 27 | blog: merlins | Brno - Venkov / Rosicko
    Rozbalit Rozbalit vše Re: Režie IP
    Ano má to něco do sebe, ale i tak, já bych raději volil klasickou FC. Latence jsou tam nízké až skoro žádné. Novější modely FC již podporují 8Gbit, oproti 4Gbit je to opravdu fofr.

    Prováděl pár testů na FC diskovém poli ( SATA-II ) a normálním obyčejným Intel Serverem na kterém běžel CentOS (+FC KARTA). Pokusím se benchmarky najít, sice to byl jen +4Gbit, ale i tak se to s technologií iSCSI nedalo ani srovnat (iSCSI bylo v řádech pomalejší).
    - nejhorší jsou trpaslíci ... Ti Vám vlezou úplně všude
    herne the hunter avatar 24.2.2010 12:48 herne the hunter | skóre: 10 | tor lara
    Rozbalit Rozbalit vše Re: Režie IP
    panečku, to muselo dát pěknou práci tenhle komentář jen napsat… RESTEKP! škoda, že tomuhle tématu rozumím asi stejně jako lister středostavovským způsobům 19. století ;) nicméně mne zaujala věta

    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?
    i am herne the hunter and you are a leaf driven by the wind.
    24.2.2010 13:21 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Režie IP

    >> 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

    [:wq]
    26.2.2010 02:25 motyq | skóre: 4
    Rozbalit Rozbalit vše Re: Režie IP
    spravne se pise RESKEPT :D
    http://wocis.net - můj píseček
    25.2.2010 00:03 tomfi | skóre: 19
    Rozbalit Rozbalit vše Re: Režie IP
    >>> Čili není to normální kancelářský Ethernet. Máte někdo představu, kolik tyhle hračky stojí?

    Vlajkovou lodí je u cisca řada NEXUS 7000... vše redundantní, zatím podpora 256 nebo 512 10GbE portů... časem by měl umět snad i 40 a 100GbE porty. klidně ho zkuste poptat, ale můj tajný typ je že v korunách se pod 7 cifernou hodnotu nedostanete.

    Na druhou stranu pokud má switch 10GbE a adekvátní propustnost switching fabric, tak by si to mělo poradit i když to bude mít na cedulce edimax :D (nízké latence jsou dobrou prerekvizitou vůbec k zacházení s 10GbE... ono když to má zvládnout minimálně 200kpps na port (10GbE), tak máš na jeden rámec velmi málo času... ty latence z principu být velké nemůžou.) Snad jediné na co si dát pozor je QoS a nějakou tu ochranu před dos, aby ten FCoE měl dobré podmínky pro doručení i v těchto rychlostech.
    Vždyť jsou to jen jedničky a nuly ...
    Marek Stopka avatar 25.2.2010 08:02 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Režie IP
    4x Cisco nexus 2k, 4x Cisco nexus 5k, 4x Cisco nexus 7k - €500 000, kolik stál jednotlivej kousek nemám tušení.
    25.2.2010 12:16 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Režie IP
    Koukám, že hranice sci-fi se zase o dost posunula. Zůstává mi rozum stát, jak dokážou znovu a znovu ochcat základní fyziku...
    [:wq]
    25.2.2010 14:25 polish
    Rozbalit Rozbalit vše Re: Režie IP
    On to v podstate bude klasicky switch, akorat se bude chovat jako nevychovany : v podstate nebude cekat az ramec prijde cely, aby ho zkontroloval a po overeni, ze je v poradku ho poslal dal, ale hned z hlavicky se ho bude snazit rvat na cilovy port (prave kvuli snizeni latence)
    25.2.2010 14:30 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Režie IP
    Cili cut-through, nikoli "store and forward". Proc ne... spis mi nejde na rozum, jak jsou schopni tohle delat mezi nejakymi 256 porty 10Gb Eth najednou navzajem, a jeste pri tom pocitat nejake priority a vkladat "pause" ramce :-)
    [:wq]
    25.2.2010 15:00 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Režie IP
    Já bych řekl, že těch 10 Gb/s · 256 portů náhodného provozu je nesmysl. Třeba trvalý proud z jednoho na druhý port zvládne maximální rychlostí, paralelní izolované přenosy taky. Ale jakmile dojde na křížení provozu a soupeření o vnitřní sběrnici (pochybuji, že tam mají n(n-1) cest, spíš něco na způsob hyperkrychle nebo možná jen okruhu), tak zpoždění začne narůstat.
    24.2.2010 09:38 zigi | skóre: 12
    Rozbalit Rozbalit vše Re: FCoE – Fibre Channel over Ethernet
    Pokud mate zkusenosti s iSCSI, mohl byste mi doporucit nejakou implementaci, viz. http://www.abclinuxu.cz/poradna/linux/show/294773
    24.2.2010 10:55 Ivan
    Rozbalit Rozbalit vše Tohle uz tu mozna bylo
    Pokud mne pamet neklame, tak existuji i standarty "SCSI over ethernet" and dokonce jsem nekde videl i "ATA over ethernet".
    24.2.2010 12:03 Yenya
    Rozbalit Rozbalit vše Re: Tohle uz tu mozna bylo
    Jo, me by zajimalo jak si FCoE stoji proti ATA-over-Ethernet. To mi prislo jako jednoduchy protokol, nevyzadujici zadnou prioritizaci ani jumbo framy.

    -Yenya
    Marek Stopka avatar 24.2.2010 12:21 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: Tohle uz tu mozna bylo
    FCoE to ke své funkci (tu prioritizaci) taky nepotřebuje, ale pokud to chceš mít spolehlivé FCoE (či libovolnou jinou storage technologii po ethernetu) musíš nějak ochcat Best effort delivery featury.
    xkucf03 avatar 24.2.2010 12:36 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše ATAoE vs. iSCSI
    U ATAoE jsem viděl i srovnání, kde vycházel pomalejší než iSCSI (přestože ho „nezdržuje“ TCP/IP). Ale možná to bylo jen mizernou implementací…
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    25.2.2010 14:47 pavuk
    Rozbalit Rozbalit vše Re: FCoE – Fibre Channel over Ethernet
    svieze zamyslenie nad FCoE a Infiniband http://etherealmind.com/fcoe-doesnt-replace-infiniband-copy-cheaper/

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.