Storage Area Network – 1 (úvod)

26. 7. 2010 | Mark Stopka | Sítě | Hardware | 19449×

V tomto nepravidelném seriálu se budeme zabývat problematikou Storage Area Network, neboli sítěmi typu SAN. V prvním díle si vysvětlíme, co to SAN je, proč se používá a které základní prvky ho tvoří.

Obsah

• Co je to SAN
• Jaké nabízí SAN výhody
• Kdy používat SAN
• Kdy nepoužívat SAN
• Z čeho se skládá SAN
• V příštím díle…

Co je to SAN

Začneme zlehka. Za SAN (Storage Area Network) se považuje síť, která propojuje počítače (pracovní stanice a servery) se zařízeními na ukládaní dat (diskovými poli). Zpravidla je taková síť budována pomocí vysokorychlostních optických spojení a je vyhrazena k přístupu k uloženým a zazálohovaným datům. Ve zkratce je tedy SAN určen k ukládání a ochraně dat. Dlouhou dobu SAN využívá Fibre Channel (FC) protokol, který zapouzdřuje protokol SCSI (Small Computer Storage Interconnect). Poměrně nově se však používá protokol iSCSI (Internet Small Computer Storage Interconnect), který zapouzdřuje SCSI do IP paketů, a největším nováčkem je protokol Fibre Channel over Ethernet (FCoE), který zapouzdřuje FC rámce do rámců sítě Ethernet.

Právě použití sítě k vytváření sdíleného diskového úložiště (storage poolu) je to, co dělá SAN SANem. SAN umožňuje přesouvat data mezi různými systémy pro ukládání dat, sdílení dat mezi různými servery a poskytuje rychlé přenosové médium pro přístup k datům, stejně jako pro zálohování, obnovu a archivaci dat.

Jaké nabízí SAN výhody

SAN má oproti lokálně připojeným diskům několik výhod, zde je pár z nich:

• Odstraňuje vzdálenostní limity lokálně připojených disků (DAS – Direct Attached Storage), ty jsou pro SCSI okolo 25 metrů, SAS nabízí jen 6 metrů a SATA dokonce jen 1 metr. [zdroj 1, zdroj 2]
• Zvyšuje výkon – současné SAN sítě umožňují přístup k diskům rychlostí stovek megabytů za sekundu (1 Gb/s FC, 2 Gb/s FC, 4 Gb/s FC, 8 Gb/s FC, 10 Gb/s FCoE).
• Vyšší spolehlivost pomocí více cest k úložnému zařízení – SAN umožňuje použít více přístupových cest k úložišti z jednoho, nebo více serverů.
• Lepší možnosti zotavení po havárii – jedná se o asi nejčastější důvod zavádění SANu. Disková pole mohou zrcadlit data do jiné, nezávislé lokality, což umožňuje jednodušší zotavení po havárii.
• Obecně vyšší spolehlivost – SAN je obecně více spolehlivý než lokálně připojené disky, umožňuje mít dostatek předpřipravených tzv. hot-spare disků a je navržen pro kritické aplikace, které si nemohou dovolit být nedostupné.

Kdy používat SAN

SAN se vyplatí provozovat velkým společnostem (více než 25 serverů) nebo společnostem, které provozují aplikace citlivé na rychlost přístupu k datům (performance sensitive), jako jsou například databáze. Také se vám nějaké síťové úložiště (ať už SAN, nebo NAS) hodí v případě, že provozujete množství souborových serverů (NAS), zálohujete příliš dlouho (SAN) nebo streamujete video.

Kdy nepoužívat SAN

SAN byste neměli implementovat, pokud jste malá organizace o pár serverech a nemáte problémy s výkonem databázových aplikací, zálohováním ani správou dat. Rozhodně se nevyplatí používat SAN pro aplikace jako webový server (pro ten je výhodný NAS), servery primární infrastruktury (DNS, WINS, doménové řadiče, …), servery, které vystačí s méně než 100 GB dat (nemusí platit v případě, že je aplikace vysoce náročná na rychlost přístupu k datům).

Z čeho se skládá SAN

Každý SAN se skládá ze 4 prvků, fyzické infrastruktury (optické vlákna, switche, disková pole, adaptéry, …), protokolu (FC, iSCSI, FCoE), aplikace (Oracle, DB2, …) a ze specialistů – tedy lidí, kteří zbylé 3 části poskládají dohromady tak, aby to nakonec i fungovalo. Já osobně bych si dovolil klást důraz na poslední prvek celé skládanky.

Pokud byste SAN chtěli rozdělit na vrstvy, dalo by se říci, že úplně dole stojí Storage vrsta (disková pole, páskové mechaniky, páskové knihovny aka jukeboxy), nad ní se vznáší vrstva Fabric (switche, huby, gatewaye a routery) a úplně nejvýš je pak vrstva Hostovací (HBA, SFP, ovladače pro HBA a samotná vlákna).

Switch QLogic SANbox 5600 s připojenými vlákny, GBIC moduly a LC konektory [wikipedia]

• HBA, neboli Host Bus Adapter se stará o obsluhu I/O operací a připojuje server k fabric vrstvě.
• GBIC/SFP je zařízení, které se stará o přeměnu elektrického signálu na optický, který putuje samotným vláknem.
• Optické vlákno je skleněné vlákno určené k přenosu světelné informace, používají se v zásadě 3 různé v závislosti na vzdálenosti a požadované přenosové rychlosti.
• Switch je srdcem každé větší SAN, má na starosti, aby se data dostala tam, kam mají, aniž by to brzdilo všechny ostatní – separují kolizní domény.
• Hub je nejjednodušší zapojení, používá se například k propojení disků v polích, na samotné síti se moc nepoužívá, zejména protože neseparuje kolizní domény a všechna připojená zařízení tak tvoří smyčku.
• Router slouží k propojení dvou a víc SAN sítí.
• Gateway je zařízení, které umožňuje překládat komunikaci pomocí jednoho protokolu na komunikaci pomocí jiného protokolu, například z iSCSI na FC nebo naopak. Za příklad takového zařízení se dá považovat například NetApp V-Series.

QLogic HBA QLA 2200 [wikipedia]

V příštím díle…

V příštím díle se zblízka podíváme na stavební bloky sítí typu FC-SAN, bude se jednat o zařízení k ukládání dat, stejně jako o zařízení sloužící k jejich přenosu.

       

Komentáře

[Michal Fecko]

Sice nevyuzijem zatial nikde ale skvele sa to cita a rozsirim si obzory. Dakujem.

[gtz]

Tak jen zlehka na to

Rád si počtu v seriálu, pár SANů jsem viděl a měl jsem co společného i s velkými systémy jako je HITACHI/EVA atd.

Switch je srdcem každé větší SAN, má na starosti, aby se data dostala tam, kam mají, aniž by to brzdilo všechny ostatní – separují kolizní domény.

Switch je snad srdcem každé SAN sítě

Kdy nepoužívat SAN...

V dnešní době kdy ceny SAN/FC zařízení klesly o hodně dolů a jsou dostupné i malých firmám proč ne? Zajisté, že tyto firmy nedosáhnou na výkon modelů AMS od Hitachi, ale klasické diskové pole se dá dnes pořídit opravdu za zlomek ceny (pole 12*1000 GB + FC switch se v dnešní době vejde zhruba do 350 000,- CZ a slušný páskový loader-robot s LTO4 do zhruba 150 000,- ). Většina ostatních výrobců dokonce dodávají na trh SAN-START-kity, kde je vše potřebné pro nastartování prostředí SAN (Před nějakou dobou jsem pro jednoho mého zákazníka zajišťoval SAN START kit za cca 10 000€ v konfiguraci : Pole 4 Gbit FC/SATA 16x 500 GB SATA , QLogic SANbox 1400 + 4x FC karty). Menší a levnější FC pole používají disky SATA, nemusí se používat drahé FC disky o malé kapacitě. Spousta těchto polí umí i mix., kdy máte třeba půlku disků FC a druhou SATA. Místo FC disků se v dnešní době hodně používají SAS disky, které mají podobný výkon jako FC.

Proč tedy ne?

Chtěl jsem na podobné téma sepsat blog ( Protokoly FC a jejich použití ), ale nějak jsem se k tomu zatím nedostal.

[Mordae]

Pole pripojene ke dvema serverum s dual port kartama nepotrebuje switch. Takze *temer* kazde.

Jinak info pro ctenare; SANka je megadraha, veleuzasna vec, ale ve finale zjistite, ze diky praci vyrobcu switchu je cela konfigurace vlastne otazka par chvil a pak se o sit, krom dohledu, uz moc nestarate.

No a pak potkate divne veci. Nektera pole chteji zonu pro kazdy kontroler, jina potrebuji zonu pro kazdou cestu a tak...

[skunerq]

Místo FC disků se v dnešní době hodně používají SAS disky, které mají podobný výkon jako FC.

SAS se FC diskum nevyrovna ani nahodou. To je jako rict, ze iSCSI ma podobny vykon jako FC, sice jsou papirove hodnoty velmi podobne, ale v realnem provozu proste SAS ani iSCSI na FC nema. Osobne jsem to testoval.

[Käyttäjä 11133]

Switch je snad srdcem každé SAN sítě

Ne není, SAN vytvoříš i HUBem, nebo P2P spojením mezi polem a klientem.

A FYI HP EVA není velký systém. :) HDS, záleží jaké HDS.

[kyytaM]

Nemam nejaky vacsi prehlad v storage zariadeniach tak sa pytam ocividne znalejsich. :) Zhruba aka kategoria je riesenie v podobe HP XP24000 (high end - 64x300GB 15k RPM FC + 24x450GB 15k RPM) + IBM DS5100 (midrange - 128 x 1TB SATA 7,2K)? Respektive nejake horror stories? :)

[gtz]

Jaká kategorie? nějak jsem to přesně nepochopil.

HP XP je jeden z vyšších modelů z řady StorageWorks (plná redundance atd.) a předpokládám správně pole slouží pro virtualizaci nebo něco podobného a DS51000 slouží na uložení dat (slušné řešení).

[Mordae]

Moc se v tom nevyznam, ale DS5100 mi zni jako potomek DS4xxx, k cemuz se nekolik mych horror stories vaze.

[gtz]

HP EVA není velký systém, je pro střední SMB Business. HDS mám na mysli standardní pole AMS ( 2U a výše) modely AMS 2100-2300-2500 (novinka na trhu), popřípadě standardní řada AMS200,500,1000. Pro segment SMB jsou vhodné menší políčka řady SMB.

Myslel jsem to, že SAN by měl být srdcem každé sítě. Vídám i to, že pole je připojené přímo přes Qlogic kartu do serveru. Je to pak řešení pro ty nejmenší firmy.

[JoHnY2]

Diky za zajimavy clanek.

Mel bych dotaz zacatecnika na iSCSI. Jaka se da u 1Gbit ethernetu ocekaval rezie iSCSI? Pokusne jsem provadel par mereni na dvou strojich s Core2 Duo, e1000e sitovkama a 1TB samsungy S2 a prekvapilo me, ze se maximalni prenosovka zastavila uz na 55MB/s (presun 10GB filu), pritom disky i ethernet by mely mit minimalne 30MB rezervu. Bohuzel jsem je mel na hrani jen jeden den, takze je moje zahada porad neobjasnena.

[Radek Hladik]

U SANu už přichází do úvahy nejenom propustnost daného média, ale i latence. A samozřejmě další věci, které u DAS moc význam nehrají. Používáme "homemade" iSCSI diskové pole s cca 20-30 klientama a mám zhruba takovéhle zkušenosti:

* iSCSI dokáže přenášet až cca 110MB/s po GB ethernetu (zkoušeno na null targetu, tedy bez fyzického disku). Na dvou bondovaných síťovkách i dvojnásobek.

* ve chvíli, kdy připojim disk, jsem schopen se dostat na cca rychlost disku (zkoušel jsem to s jakýmisi raptory, lokálně dělaly 75MB/s, přes iSCSI asi 73MB/s)

* Pokud na targetu mám filesystém, je schopný srazit výkon o 10-15MB/s dolů

To je sice všechno hezké, ale v praxi je s tím spousta problémů:

* Klienti přistupují současně, pokud se správně nenastaví cache, výkon výrazně klesne. Pokud se nepoužívá filesystém (což nedoporučuju), pak je vhodné mít target na 64bit architektuře, protože ta umí blockdevice cachovat více jak 1GB

* Implementace initiatorů se různí. Například ta ve FreeBSD je totálně nepoužitelná, protože každý požadavek posílá okamžitě po sítí a celá I/O operace stojí, dokud nedorazí odpověď. Běžná práce s filesystémem používá 4KB bloky, při tom dosahuje asi 50% výkonu openiSCSI. Při defaultní velikosti pro dd 512B dosahuje tak max 10%. Projevovala se zde latence takovým způsobem, že byl na výkonu poznat i switch navíc...

* Naopak iSCSI se dá provozovat i přes 100MBit linku, mám malý servřík (Intel little valley), má malý disk mirrorovaný přes iSCSI a je to rozumně svižné - I/O dělá cca 10MB/s.

Chtěl jsem jenom ilustrovat, jak je celá problematika složitá. To co je v případě DAS řešeno jedním řadičem, diskem a krátkým kabílkem, je v případě SAN nahrazeno značně komplikovanou infrastrukturou.

A na závěř perličku: Objednal jsem si z ebay iSCSI HBA na hraní (metalický GB ethernet) a poprvé jsem viděl čistě gigabitový port. Zkoušel jsem to doma, kde jsem měl jen 100MBit switch a HBA hrdě hlásil No Link...

[Heron]

Sám mám něco podobného (Server C2D CentOS 5.5 64b, Klient C2Q W7 Ult 64b), Intel síťovky Intel PRO/1000 PT a Samsung F1 1TB disk. iSCSI target nemám na FS (to je opravdu pomalé), ale přímo na LV. Ve Windows pak naformátovaný jako NTFS. Rychlost čtení souborů je cca 95MB/s (čtení toho LV do /dev/null jde 103MB/s). Zápis je překvapivě ještě rychlejší, protože to cachují i ty Win. Takže zápis 2GB je pro tu zapisující aplikaci hned (rychlostí RAM). Pak to tam W7 postupně flushne (a opravdu s tím vůbec nespěchá).

Výhoda je, že to cachuje jak server, tak klient. Takže při běžné práci se na disk prakticky nesáhne (pro čtení), pouze tedy poprvé.

55MB/s je málo. Co jsem tak vypozoroval, tak největší problémem jsou latence. U mě třeba změna mezi repotec a 3com switchem udělala 20MB/s. Překvapivě ještě rychlejší to je přes stávající switch v RouterBoardu, který si naklikám (masterport). Na tom mi to jede právě těch 95MB/s. Kabeláž úplně levná Cat5e o délce 32m (client 2m switch 30m server).

[VSi]

Zápis je překvapivě ještě rychlejší, protože to cachují i ty Win. Takže zápis 2GB je pro tu zapisující aplikaci hned (rychlostí RAM). Pak to tam W7 postupně flushne (a opravdu s tím vůbec nespěchá).

To je docela problém, když vypadne napájení nebo stroj kvůli HW chybě spane. Jasně, že USP by v takovém případě měla být samozřejmá, a stroj přece nepadá. Ale stát se něco takového může (třeba se UPS zblázní, špatná baterie která se detekuje jako OK), a aby to zkončilo rozsypaným filesystemem, to by nebylo dobré. Nezkoušel jste, jestli se s takovou situací NTFS na iSCSI dokáže vyrovnat, když se stroj tvrdě vypne uprostřed zápisu?

I když ta cache na klientu (Windows) asi půjde vypnout, pokud budu chtít jistotu na úkor výkonu.

[Heron]

Upřímně řečeno od těchto věcí jsou zálohy.

Jasně, stejné otázky jsem si sám sobě také pokládal. Odpovědi: Ve Vista 64b / W7 64b jsem BSOD ještě nevidel. Ve WinXP 64b ano, asi dvě -- vždy za to mohl špatný HW (GK - ve vistě a 7 by se provedl jen reset karty a reload ovladačů). V CentOS kernel panic pouze na špatném HW (na vlastních strojích jsem jej neviděl nikdy). UPS tam mám. Špatná baterie tam není, od toho dělá pravidelné automatické testy.

Vypnout to natvrdo jsem nezkoušel. Co jsem nechtěně vyzkoušel je odpojení stroje sítě (vadný konektor). Ten iSCSI iniciátor (stana klienta) pochopitelně nezahodí data ve write cache, ale naopak se usilovně snaží připojit. Target (server) se se mnou odmítá úplně bavit o nějakých restartech služby, pokud tam je připojený iniciátor. Takže po opětovném napojení kabelu se to rozjelo a data byla. Co by se stalo v případě tvrdého resetu, hmm ten FS by se nerozpadl, ale ta kopírovaná data by tam pochopitelně nebyla. Což ale není problém, protože na zdrojovém disku stále jsou.

Write cache jde vypnout. Jdou vypnout všechny cache. Ale pak to bude nepoužitelně pomalé. Je to o kompromisu. Já preferuji rychlost a ochranu dat řeším denní zálohou (Acronis). A tu zálohu jsem vytahoval z mnoha jiných důvodů, ale nikdy ne z důvodů selhání HW či SW.

[Kvakor]

Když havaruje klient tvrdě během zápisu, tak jsou data většinou v pytli tak jako tak. Synchonní zápis (bez WB cache) je pro reálné použití nepoužitelný (nejde ani tak o rychlost přenosu dat, ale o latence) a cachování dat k zápisu na lokálním disku (jako to dělají některé distribuované souborové systémy) zas stojí a padá s konzistencí soborového systému na onom disku.

Takže v praxi se toto buďto neřeší a doufá se, že klient disk nezboří, nebo se musí obětovat rychlost a jít o vrstvu výš, tj. místo storage poskytovat klasický fileserver. Když jsou data opravdu důležitá, tak se stejně použije raději databáze s podporou transakcí, nebo se z tlustého klienta udělá tenký.

BTW: Sice nemám skušenosti s vzdáleně připojeným NTFS, ale nikdy jsem nezažil, že by se lokální NTFS u klienta "zbořilo" do neopravitelného stavu jen při výpadku napájení nebo připojení disku (první generace konektorů u SATA kabelů na některých deskách moc dobře nedržela). Disk, který byl totálně zmršen, byl přiveden do tohoto stavu vždy čistě sotwarově (typicky přepsání začátku disku náhodnými nesmyslnými daty), takže kdyby byl připojen ke storage, tak se vesele zruší data i tam. Na druhou stranu, na místech, kde se používá SAN, by nejspíš nikdo takové šílenosti, které by klienta do podobného stavu přivedly, nejspíš nedělal ...

[VSi]

Vyšší spolehlivost u sdílení souborů, tj. NAS je jasná.

Vycházím z toho, co mě nedávno trochu vylekalo, a to je rozsypání ext3, pokud se několikrát tvrdě vypne při běžícím vytížení zápisem v případě, že nefungují "write barriers". Tedy ne že by se mi to stalo, ale četl jsem o tom, byla to celá stránka s testy, teď to nemůžu najít. A ty barriers nefungovaly u LVM a mdraid, teď je to možná kolem 2.6.32 spravené. Toto se neprojeví při normálním použití, ale jen když v okamžiku pádu běží intenzivní zápis, a to ještě jen někdy.

U NTFS je tohle možná OK, chyba souvisela se zápisem žurnálu ve špatném pořadí a nepřítomností kontrolních součtů, které by to odhalily.

Ad výkon a write cache: je mi jasné, že synchronní zápis až na disk srazí výkon k nepoužitelnosti. To mám i vyzkoušeno. U SATA disků bez HW řadiče se využívá interní cache, kterou FS podle potřeby vyprazdňuje (nebo využívá write barriers), a předchází tak porušení struktury při výpadku napájení. Že se přijde o "rozdělaná data" v cache je jasné. U HW raidů se doporučuje vypnout cache na discích, a používat jen tu na RAIDu, která je zálohovaná baterií.

Tj. jsem předpokládal, že třeba u Fibre Channel je write cache součástí diskového pole, a na klientu, resp. HBA už se write cache na SCSI vrstvě nedělá (mimo toho, co dělá samotný filesystem). Je to tak? Jak jinak by bylo možné používat jeden iSCSI/FC svazek z více strojů pro nějaký paralelní FS? Pomocí jeho speciální synchronizace informací o cache?

[BrainLess]

Problemem jsou vetsinou "shitove" sitovky ktere nejsou schopne utilizovat dane pasmo.

[JoHnY2]

S tim souhlasim, mezi PCI Reatekem a PCI-E PRO/1000 od Intelu je naprosto brutalni rozdil. Celkem si taky nemuzu stezovat na Marwelly i kdyz jsem je nikdy nemel v serveru.

[P.]

co to znamena utilizovat pasmo?

podle meho laickeho nazoru: 100MBit/s je 100MBit/s

[trekker.dk]

100Mbit znamená, že ta karta o sobě tvrdí, že to umí.

Využít pásmo znamená, že ta karta opravdu dokáže touhle rychlostí vysílat/přijímat data. V tomhle ohledu jsou slavné síťovky Realtek, které při velkém provozu (zbytečně) generují spoustu přerušení, takže procesor nestíhá a těch 100Mbitů je jenom teoretických.

[Ondrej 'SanTiago' Zajicek]

Me zkusenosti se sitovkama Realtek (rtl8139) jsou ty, ze bez potizi dosahnou rychlosti pres 90 Mbps bez vyznamneho vytizeni procesoru.

[Radek Hladik]

Přesne tak, na 8139 nedám dopustit. Síťovka za pár korun, podpora všude bez problémů a výkon v rozumných mezích...

[Ivan]

Proc vsichni uvadeji MB/sev jako benchmark? Copak se SANka pouziva na ukladani filmu?

[drunkez]

pac v shitnej SANke je to prvy bottleneck....I/O utilizacia na kontroleroch switchoch a lunoch tak ako aj latencia je uz dalsie kolo....

[Käyttäjä 11133]

Protože množství IOPS bude hodně hodně záležet na poli které použiješ, jeho konfiguraci LUN,...

[Peteb]

Nevyhodou techto reseni (SAN reseni se stovkami HDD) je vysoka vysledna cena/TB kapacity. Coz v ramci omezenych rozpoctu (aspon u nas) vede k osazovani HDD co nejvetsich kapacit. Tyto jsou slouceny do RAIDu a nasledne rozkrajeny na dilci jednotky, poskytovane jednotlive/sloucene serverum(aplikacim). Vysledkem je pak sdileni "vretene/seeku" vice servery/aplikacemi. Tvari v tvar takovym nasazenim si pak nelze nevzpomenout na uvod Mistrovstvi v Oracle 7, ktere uvadi ".. na pokusy si priprav sedm samostatnych disku (system,data,idx,temp,rbs,redo,archiv,..)".

[Mordae]

Oracle nepripominat. Da se rozjet i na jedinem SATA disku, ale je to utrpeni. Nejhorsi je, ze ten ksindl ten disk pomalu utavi jen na blbym enterprise manageru.

Delal jsem ~2 roky s Oraclem. Co jsem si zacal hrat s Postgresem, nechapu, jakto, ze je Oracle stale jeste na trhu (a ano, delal jsem zejmena na DB v tom jejich pseudo-clusteru).

[gtz]

Benchmarky storage strojů naleznete zde

[Pavel Francírek]

Z hlediska interconnectu se tu trochu zapomnělo na InfiniBand.

[frr]

Tvrdil mi jeden německý distributor HPC hraček, že IB vychází levněji než FC - při kratších latencích. Řekl bych, že je na druhou stranu poněkud omezený dosahem. Ale pro kompaktnější sestavy, proč ne... Asi i další fičury se mohou lišit - a nemám na mysli zrovna tlustou metalickou kabeláž. Pokud mohu soudit, na našem trhu se IB zatím moc neprodalo. FC má kdekdo, IB sem tam nějaká univerzita/výzkumák/vývojové centrum - hlavně v žiletkových vanách, kde je IB v backplanu, a s krátkým propojem na storage.

Cca před rokem se dost mluvilo o PCI-e IOV na úrovni bladeových krabic a HPC storage. Jako že PCI-e povede až do externího RAIDu, a v backplanu namísto IB bude PCI-e switch. A pod vanou na žiletky bude foch na PCI karty, které bude možno mapovat přes PCI-e switch žiletkám a dokonce virtuálním strojům. Už jste to někdo potkali na živo?

Ne že bych něco z toho viděl jinak než na papíře...

[kyytaM]

Neda sa IB pouzivat na zivu mirgaciu pri virtualizacii? :)

[Käyttäjä 11133]

Na to se dá používat i ethernet. :D:D

[kyytaM]

Tak doplnujuca otazka, kedy budu "kupitelne" 40Gbit a 100Gbit Ethernet komponenty (ked standard bol schvaleny nejaky mesiac dozadu)? ;)

[frr]

No když si vezmu, kolik stojí 10Gb Ethernet, který v PCčku je tak na hraně toho, co má smysl z hlediska průchodností interních sběrnic, doručování interruptů a schopnosti dnešních CPU a OS zpracovávat reálný síťový provoz, tak bych řekl, že 40Gb nebo 100Gb v PCčku hned tak neuvidíme. Taky si vemte, kolik žerou a topí skromnější varinaty 10Gb Eth (optika a CX4 metalika), nemluvě o žravé metalice 10Gbase-T => jak by musel vypadat 40Gb nebo 100Gb interfejs (asi jako špičková grafárna).

Objeví se to podle mého nejprve jako trunková rozhraní na internetových páteřích, kde už je reálně potřeba takovéhle kapacity přehazovat vidlema, a v backplanech a switchovacích maticích ta průchodnost už je.

Ano, toho smajlíka jsem postřehl ;)

[kyytaM]

Stacilo mi, ked som pred cca pol rokom pozeral, kolko stoja 10 Gbit L2 switche. :)

Len ma zaujal IB z toho pohladu, ze ak mam vo virtualizacnom clustery virtualky s radovo 10kami GB RAM, tak migracia (kopirovanie ich pamate) z jedneho hosta na druhy uz vie zabrat celkom dost casu, :)

[Pavel Francírek]

Rozhodně. Hlavně kvůli zmíněné latenci, která je o řád lepší než u Ethernetu.

[peppa]

ještě jedna situace kdy SAN určitě ano - když virtualizujete servery

[ET]

pokud si dobre pamatuju, co se tyce rychlosti - taky je treba davat bacha z kolika disku se danej raid stavi - napr. neni vzdy efektivni postavit raid 10 napr z 8 disku ale udelat 2 raidgrupy z 2x4 raid 10 (nejlip treba pres 2 patra kvuli redundanci) a ty pak spojit do jednoho celku - pokud vim zalezi to od vyrobce

[Käyttäjä 11133]

Jasně, nicméně já se tímto moc zabývat v seriálu nebudu, jde mi spíše o popsání protokolů, technologií,... konkrétní implementace jsou příliš závislé na výrobci a vždy je nejlepší se poradit přímo s výrobcem, nebo nějakým konzultantem.

[Radek Hladik]

Článek se mi zatím poměrně líbí, ale rád bych zdůraznil, že popisuje "enterprise" technologie za netriviální peníze (to není výtka). SAN je ale možno provozovat i v menším a pořád může přinášet spoustu výhod. Existují otevřené implementace iSCSI (target IET a initiator OpeniSCSI), jako médium poslouží i gigabitový ethernet. Balíčky jsou dostupné ve spoustě distribucí a na netu je spousta popisů a návodů.

[Käyttäjä 11133]

K iSCSI a dalším levným technologiím se dostaneme snad později. V současné fázi se budu zabývat Fibre Channelem, iFCP, FCIP, CDP,... později se možná dostanu i k iSCSI.

[Aktuator]

Takže budeš popisovat věci co 95% čtenářů nikdy nevyužije, ale iSCSI může použít kdekdo hned. Ale co, koho chleba jíš toho píseň zpívej. Navíc je to napsané dobře.

[Heron]

To je kritika zcela mimo mísu. Pokud by se mělo psát podle toho, kolik lidí si to přečte, tak abc skončí jako Blesk

[Radek Hladik]

S tím naprosto nesouhlasím a svůj příspěvek jsem tak ani zdaleka nemyslel...

Jsou články, které vyujiže skoro každý (třeba zprávy o stavu kernelu nebo recenzi na toaletní papír) a pak jsou články z katergorie zajímavé věci. Možná/nejspíš člověk takové věci nevyužije, ale jednoznačně si rozšíří vzdělání, což by každý soudný člověk měl průběžně dělat...

Svůj příspěvek jsem myslel jako upozornění pro právě takové čtenáře a kdo měl zájem/čas/chuť/náladu, tak teď už má na jednom storji připojený disk z jiného stroje a bude se lépe orientovat v pokračováních seriálu...

[stn]

No vida, tak kdyz je na netu spousta popisu a navodu na ty lowend/homemade SAN technologie, proc pridavat dalsi? Myslim, ze hodne lidi vcetne me si rado precte i drahych enterprise-class technologii, aspon si rozsiri obzory. Ostatne neni az takovy problem se k takovym technologiim dostat, staci se nechat zamestnat v nejake dostatecne velke firme .

[frr]

Jako iSCSI target jsem před časem otestoval linuxový SCST (out of tree). Existuje také in-tree STGT (údajně ne tak dobrý jako SCST). Na webu SCST je nějaké srovnání SCST, STGT, IET a LIO.

[Radek Hladik]

Už jsem také zaregistroval a druhý iSCSI server (target) mám v plánu postavit právě na tomto... Minimálně pro testování, ale předpokládám, že i pro následný ostrý provoz...

[Radek Hladik]

Ještě bych dodal, že existuje iSCSI target z NetBSD. Funkčně je sice poměrně dost hrozný a výkon nic moc, ale je to čistě userspace aplikace, přeložitelná i na Linuxu (i staticky). Mám jí na svém modifikovaném RIPLinuxu a je to docela pohodlné k opravě různých rozpadlých systémů (hlavně Windows, Linux se dobře opravuje přímo z toho RIPLinuxu). Nabootju z CD, nastavím iSCSI a připojím do normálního Win počítače, kde mám všemožné nástroje atd...

[Ming]

Jenom doplnim, ze 10Gbps FCoE neni rychlost fibru, ale toho nosneho ethernetu. FC uvnitr jede na 8Gbps. Za to existuje "cisty" FC, ktery jede na 10Gbps (ma jej napr. Cisco viz tady).