Storage Area Network – 3 (stavební bloky 2)

9. 8. 2010 | Mark Stopka | Hardware | Sítě | 12578×

V třetím díle seriálu o Storage Area Networks navážeme tam, kde jsme minule přestali. Popsali jsme zařízení na ukládání dat a jedno zařízení sloužící k jeho přenosu – FC SAN Switch. Dnes budeme pokračovat a představíme si zařízení router, stejně jako jednotlivé vrsty FC protokolu a pracovní režimy jednotlivých portů v FC switchích.

Obsah

• FC router
  • iFCP a FCIP – v čem se liší?
  • Switchovaný fabric více z blízka
• Příště…

FC router

Datové FC routery se v sítích SAN používají na překlad jednoho protokolu na jiný. Může se jednat o překlad z protokolu SCSI na FC nebo například iSCSI na FC. Jedná se o relativně levnou (v porovnáním s výměnou pole) metodu, jak poskytnout koncovým klientům například iSCSI konektivitu, pokud současné diskové pole iSCSI nezvládá. Případně vám umožní připojit do SAN starší páskovou mechaniku, která zvládá jen SCSI protokol. Často bývají routery také označovány slovem „gateway“ nebo „bridge“.

Velice významnou roli hraje FC router při tvorbě odolných řešení, například umožní tunelovat FC protokol prostřednictvím jiného typu sítě, třeba sítě typu IP. V takovém případě se bude jednat o router podporující protokol iFCP (Internet Fibre Channel Protocol) a FCP (Fibre Channel Protocol). V takovém řešení budete mít v každém datovém centru vlastní FC SAN a obě tyto SAN budou propojeny právě prostřednictvím tohoto routeru a protokolu iFCP nebo FCIP.

Protokol iFCP, jak již název napovídá, zapouzdřuje FC rámce a přenáší je na druhou stranu, a to prostřednictvím TCP spojení. Umožňuje propojení SAN sítí na libovolnou vzdálenost prostřednictvím běžné IP WAN sítě. Další protokol umožňující propojení SAN sítí prostřednictvím sítí IP je protokol FCIP (Fibre Channel over IP).

SAN router Brocade 7500E

iFCP a FCIP – v čem se liší?

Teď se možná ptáte, k čemu existují dva různé protokoly se stejným účelem, totiž propojit dvě sítě SAN prostřednictvím sítě IP. Zásadní rozdíl mezi těmito protokoly je v tom, jakým způsobem propojují. V případě protokolu FCIP se jedná o tunel, který propojuje dvě vzdálené sítě do jednoho společného celku – jedné fabric, a to se všemi pozitivy i negativy. V jednom FC ostrovu (FC island) je tak vidět veškerý traffic a zařízení, která spadají do druhého FC ostrovu. Z pohledu FC switchů jsou tyto propojeny běžným portem typu inter-switch link (ISL). Zařízení, které takto propojuje sítě, se také nazývá Fibre Channel extender. Každý Fibre Channel extender pracující s FCIP má tzv. buffer (občas v literatuře nazývané taky buffer credits), nicméně zabývat se buffer credits by bylo až příliš zdlouhavé, proto si to necháme snad na samostatný článek – vyšší dívčí. Důležité je, že čím více buffer credits, tím lépe. V závislosti na jejich množství bude vaše SAN rychlejší a bude fungovat na větší vzdálenost (s vyšší latencí).

Na druhou stranu protokol iFCP umožňuje zařízením v dvou různých SAN (jedná se již o dvě různé SAN, nikoli o jednu rozsáhlou SAN propojenou tunelem) komunikovat. Všechno, co se děje v jedné SAN, se nepřenáší do druhé, pouze provoz určený pro zařízení v druhé SAN bude přenesen po iFCP propojení. Tedy na rozdíl od FCIP, iFCP nepřenáší například chyby. Pokud se něco stane v SAN propojené pomocí FCIP, ochromí to oba FC ostrovy. Pokud se něco podobného stane ve dvou SAN, které jsou propojeny pomocí iFCP, chyba zůstane izolována v SAN, kde k chybě došlo. U iFCP dochází k namapování Fibre Channel adres na IP adresy a poslání TCP/IP paketu na druhou stranu. Pro více informací o iSCSI, iFCP a FCIP doporučuji nastudovat knihu IP SANs: a guide to iSCSI, iFCP, and FCIP protocols for storage area networks nebo si počkat na některý z dalších dílů.

Stejně tak při iFCP nebude docházet k volení (election) řídícího switche (Principal Switch – PS) při výpadku IP konektivity mezi těmito dvěma SAN a podobně. iFCP síť se tedy z celkového pohledu bude chovat na stejné konektivitě více stabilně.

Switchovaný fabric více z blízka

V minulém díle jsme si řekli, že existuje nějaký FC-SW protokol, stejně jako ISL – inter-switch link, který propojuje jednotlivé switche, ale jsou i další druhy portů u fabric switchů? Když se tak ptám, tak asi ano… a to následující (z důvodu jednoduchosti vynecháme všechny proprietární rozšíření od společností Cisco, Brocase, QLogic a dalších).

Název portu	Určení portu
N_port	Node port – port používaný k připojení koncových uzlů, jako jsou disková pole nebo klienty na straně koncových zařízení
F_port	Fabric port – port používaný k připojení koncových uzlů jako jsou disková pole nebo klienty na straně switche
E_port	ISL – Inter-Connect Link – port používaný k propojení dvou různých switchů v rámci jedné fabric
EX_port	port používaný k propojení routerů a switchů, na straně routeru se tváří jako EX_port, na straně switche jako E_port

Ve chvíli, kdy je switch připojen do sítě, je mu přiděleno tzv. Domain_ID. V každé FC-SW síti se volí řídící switch (Principal Switch – PS), samotný proces je podobný k tomu, jak se volí root bridge switch v protokolu Spanning Tree, poté následuje distribuce Domain_ID. Předtím, než mohou jednotlivé switche komunikovat mezi sebou, se každý z nich zkonfiguruje, aby zjistil, co má kde připojeno na kterých N_portech. Switch přiřadí FCID ke každému připojenému uzlu, které je odvozeno od Domain_ID, Area_ID a WWN připojeného zařízení.

Proces probíhá zhruba následovně:

1. Zahození interního Domain_ID seznamu.
2. Na každém E_portu dojde k přenesení BF rámce (výjimka: BF rámce se nezasílají na E_porty, na kterých byly obdrženy – zabraňuje se tak smyčkám)
3. Počká se na FST (Fabric Stability Timeout), aby se zajistilo, že byly BF rámce přeneseny přes celou fabric.
4. Vyšle se EFP (Exchange Fabric Parameters) rámec a SW_ACC (Switch Accept) každému zdroji BF rámce.
5. V EFP rámci se vyhodnotí parametry PS_Priority, PS_Name a seznam Domain_ID.
6. Sečte se PS_Priority a PS_Name a vybere se vítěz, nižší číslo vyhrává.

Po zvolení PS switche tento začne distribuci seznamu Domain_ID.

Příště…

Příště si představíme používané topologie v FC sítích, jako jsou dvojitý switch (Dual switch), Kruh switchů (Loop of switches), křížová síť (Meshed fabric), hvězda (Star) a jádro-okraj (Core-edge). Také si povíme o zónách a vysvětlíme si rozdíl mezi soft a hard zónami.

       

Komentáře

[BFU]

Ja to vubec nechapu

[peppa]

to nevadí, na doma ani do firmy malé a střední velikosti toto není zapotřebí

[BrainLess]

Tak tak ... relativne levny SAN router za 25 000$

[zz9]

Pouziva google ve sve infrastrukture take tyto prvky? (diskova pole, FC switche...), ja dokazi zajistit, na tolika pocitacich, ze ty data ten konkretni stroj zrovna ma? Nekde jsem cetl, ze servery google jsou "jen" hromada plecen PIII apod, co je na tom pravdy?

[hujer]

no jelikoz ma google asi statisice serveru, tak to asi nemusi bejt nic vykoneho. ale google ma vetsinou vlastni reseni, google file system (GFS) atd .. ohledne googlu myslim ze jde najit cesky clanek co popisuje co jak maji udelane .. napr. ohledne serveru, myslim ze maj nakou unifikovanou platformu s napajenim 18V atd .. cosi styl http://www.zive.cz/clanky/google-odhalil-tajemstvi-svych-uspornych-serveru/sc-3-a-146455/default.aspx

[hujer]

http://linuxzblizka.blog.zive.cz/2010/03/utajovane-technologie-googlu/ :)

[VSi]

Tak to ví asi jen sám Google Ale z veřejně dostupných informací (např. přednášky lidí z Googlu) je to asi tak: v měřítku systémů Googlu, je i ta nejvíc Enterprise technologie příliš nespolehlivá, resp. nedokáže zaručit potřebnou spolehlivost za reálnou cenu.

Takže alespoň pro infrastrukturu, která posyktuje veřejné služby (hledání, mapy, apps), Google údajně používá "obyčejné" komponenty v obrovkém počtu. Problémem je také spotřeba elektřiny, takže se používá to s nejlepším poměrem výkon/spotřeba. Ve své době to byly P3, dnes už asi ne. Spolehlivost je zajištěna a úrovni aplikací. Data jsou v několika kopiích a nemusí být zrovna na tom stroji, který je zpracovává, jsou síťově sdílená. Systém uložení dat např. zajišťuje, že bude uložen určitý počet kopií v každém z datacenter Googlu, aby se data nepřenášela na dlouhé vzdálenosti.

Ale je třeba říct, že přístup Googlu často nelze v prostředí, kde se používá FC / SAN, dost dobře uplatnit. Zjednodušeně se takový přístup začíná vyplácet až od určité velikosti, což je ještě závislé na druhu služeb.

http://www.youtube.com/watch?v=zRwPSFpLX8I

[deda.jabko]

s googlem je trosku potiz, ze informace vypousti po kouskach... ale pokud by vas zajimalo, co pouziva treba konkurence jmenovite yahoo! doporucuji dat vyhledavat "hadoop yahoo"... zdrojaky k hadoop a dalsimu softwaru jsou volne k dispozici, takze pokud mas vic pocitacu muzes si takovy cluster postavit i doma.

[Zdenek]

Nepouziva FC, ale starej dobrej ethernet. Lepsi je resit redundanci a failover na aplikacni urovni a koupit si levny a bezny HW nez cpat penize do hromady zeleza, ktera je uz zitra stara.

[Peto_MiG]

Pred casom som dokonca videl aj fotku takeho stroja a celeho datoveho centra.

V skratke ide o to, ze Google naozaj vsadil na pocet, nizku jednotkovu cenu, geograficku rozptylenost a svoju vlastnu softverovu technologiu zabezpecujucu redundanciu dat.

Jeho datove centrum je v podstate prepravny (lodny?) kontajner, ktory ma po oboch dlhsich stenach same rackove police s chodbou uprostred. Police su plne samostatnych rackovych serverov. V jednom kontajneri ich je cca 1500(?).

Kazdy server obsahuje zakladnu dosku vcelku beznych desktopovych parametrov (naposledy to bol tusim custom model od Gigabyte) s 2 procesormi, 2 diskami SATA v RAID1, priamo do zdroja je zapojena 12V bateria (taka ta bezna UPS-kova, asi 7Ah). Cele je to vmontovane do custom rackovej skrinky (obycajna plechova v style "nejde o dizajn ale o funkcnost). Finta je v tom, ze Google zistil, ze riesit zalohu napajania nejakou velkou centralnou UPS by bolo velmi drahe, kladlo by dalsie naroky na chladenie apod. Google riesenie (kazdy stroj - vlastna baterka) je genialne jednoduche a funkcne. V konecnom dosledku, Google jednoducho postavi kontajner, prenajme si konektivitu a elektricku energiu a fici to.

Kazdy stroj ma svojho dvojnika niekde inde vo svete, kde je indexovana rovnaka cast hesiel a navzajom sa to softverovo synchronizuje. Ked sa pokazi len disk, vymeni sa. Ked sa pokazi cely stroj, tak po zapojeni noveho sa nan automaticky nasypu data z dvojnika.

Nejako takto som to pochopil.

[zz9]

Jakze je to udelane s tou baterkou?

12V - AKU - ZDROJ - DESKA? (jak se dobiji ta aku?)

220V - ZDROJ - AKU-DESKA? (deska ma na sobe nejaky dalsi "zdroj" pro jine napetove vetve?)

Nebo uplne jinak?

---

"Kazdy stroj ma svojho dvojnika niekde inde vo svete"

Jenom jednoho na svete nebo kazdy stroj ma dvojnika v dane lokalite?

A jak se vlastne rozklada takova obrovska zatez? Geograficky DNS servery hodi pozadavky do spravneho datacentra co je "nejblize", porad nejak nerozumim, kdyz muj dotaz treba gmailu doputuje na konkretni server v konkretnim datacentru, jaky mechnismus zajisti, ze tam ten stroj bude mit na discich zrovno moje potreba data. Nebo snad se konkretni uzivatele vzdy dostavaji na tentyz "par"(n-tici) stroju?

[VSi]

Co jsem viděl z fotek, tak tam 12V baterka je připojená dovnitř zdroje, který řeší její nabíjení a přepnutí, když vypadne 230V. Prostě si představ elektroniku UPS integrovanou v ATX zdroji - díky tomu tomu, že ten zdroj nemusí dělat tolik různých napětí jako u ATX to může být jednodušší. Jiná napětí než jdou ze zdroje je asi levnější dělat pomocnými obvody na základní desce.

K funkci na aplikační úrovni je třeba si uvědomit (obecně, nejen v případě Googlu), že požadavek na zobrazení 1 stránky vůbec nemusí provádět 1 stroj. I u jednoduché aplikace můžeš mít na 1 stroji třeba PHP skripty a na 2. stroji databázi, oba spolu komunikují přes síť. U Googlu (nebo při jiné obdobné zátěži) to může vypadat nějak takhle: pomocí DNS se tvůj požadavek nasměruje na 1 z X strojů, tzv. loadbalancer. Ten má přehed o dalších strojích, které můžou požadavek zpracovat, ví jestli běží, jak jsou zatížené atd. Ten loadbalancer přepošle tvůj požadavek např. na nejméně zatížený stroj, nebo náhodně na kterýkoliv běžící. Je možná třeba ještě jedna úroveň přeposílání např. podle aplikace (hledání, gmail, apps). Dejme tomu že chceš zobrazit zprávy v inboxu gmailu: stroj zpracovávající tvůj požadavek ty zprávy na disku samozřejmě nemá, ale ví, jak se k nim přes síť dostat. Tomu se říká distribuovaná databáze nebo souborový systém. Všecha data jsou rozprostřená na různých strojích a jejich discích, a vedle toho se udržuje informace, na kterém stroji (bude jich víc, kvůli tomu kdyby jeden vypadl) jsou zrovna tvoje e-maily uložené.

Naopak když třeba přijde e-mail, tak stroj, který ho zpracovává, ho vůbec nemusí ukládat na svůj disk, ale podle konfigurace ho uloží třeba na 3 jiné stroje z X tisíc (desítek tisíc?), které google má. Kam se zrovna tvůj e-mail uloží se vybírá třeba podle toho, kde je dost místa a asi se myslí i na to, aby e-maily z jedné schránky byly uloženy u sebe.

Neříkám, že přesně takhle to funguje, ale princip jak se zvládá takhle velká zátěž a velké množství dat je snad zřejmý.

[zz9]

To je hodne zajimave. Da se toto nejak nasimulovat v mensim poctu stroju? Existuji opensource projekty, ktere by tuto problematiky nejak kompletne resily? Neco jsem cetl o hadoop, ale nejsem z toho moudry. Nebo alespon nejaky kvalitnejsi materialy ke studovani?

[BrainLess]

Google ( jeho pracovnici ) mysleli a tyhle drahe cetky nepouzivaji. Misto toho pouzivaji "homemade" PC servery ( normalni pc uzpusobene potrebam googlu = bez zvukovky, porty jenom co potrebuji, zadnej brutalni vykon ). A pro vysokou dostupnost upravili software nikoliv HW. Pouzivaji vlastni DB ( BigTable ).

[Ivan]

jj. FC je pekna hracka, ale bohuzel prilis draha. Kdo by si myslel, ze na konsolidaci usetri, je blazen. U nekterych vyrobcu poli dokonce plati, ze cim vetsi pole tim vetsi cena za GB. Ciste teoreticky mate moznost u velkych poli pouzit ruzny SW vychatavky, ale praxi na to skoro nikdo nema odvahu.

[Käyttäjä 11133]

U nekterych vyrobcu poli dokonce plati, ze cim vetsi pole tim vetsi cena za GB.

Jo, jenže taky to pole pak umí uplně jiné věci, že... :) Třeba FICON, a když máš mainframe, tak na euro nehledíš, jinak by si už dávno měl otevřené systémy.