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 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 0
dnes 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 0
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ářů: 9
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ářů: 8
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
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (12%)
 (0%)
 (0%)
 (0%)
 (76%)
 (12%)
Celkem 25 hlasů
 Komentářů: 0
    Rozcestník

    Storage Area Network – 3 (stavební bloky 2)

    9. 8. 2010 | Marek Stopka | Hardware | Sítě | 4811×

    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

    link

    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
    SAN router Brocade 7500E

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

    link

    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

    link

    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 portuUrčení portu
    N_portNode port – port používaný k připojení koncových uzlů, jako jsou disková pole nebo klienty na straně koncových zařízení
    F_portFabric port – port používaný k připojení koncových uzlů jako jsou disková pole nebo klienty na straně switche
    E_portISL – Inter-Connect Link – port používaný k propojení dvou různých switchů v rámci jedné fabric
    EX_portport 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_IDWWN 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_PriorityPS_Name a vybere se vítěz, nižší číslo vyhrává.

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

    Příště…

    link

    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.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

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

    Komentáře

    Vložit další komentář

    9.8.2010 08:42 BFU
    Rozbalit Rozbalit vše Re: Storage Area Network – 3 (stavební bloky 2)
    Ja to vubec nechapu :-(
    9.8.2010 12:25 peppa
    Rozbalit Rozbalit vše Re: Storage Area Network – 3 (stavební bloky 2)
    to nevadí, na doma ani do firmy malé a střední velikosti toto není zapotřebí
    11.8.2010 08:30 BrainLess
    Rozbalit Rozbalit vše Re: Storage Area Network – 3 (stavební bloky 2)
    Tak tak ... relativne levny SAN router za 25 000$ :-)
    9.8.2010 16:28 zz9
    Rozbalit Rozbalit vše A google?

    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?

    9.8.2010 16:44 hujer
    Rozbalit Rozbalit vše Re: A google?
    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
    9.8.2010 16:50 VSi | skóre: 28
    Rozbalit Rozbalit vše Re: A google?
    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

    9.8.2010 18:15 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: A google?
    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.
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    10.8.2010 10:04 Zdenek
    Rozbalit Rozbalit vše Re: A google?
    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.
    10.8.2010 14:21 Peto_MiG
    Rozbalit Rozbalit vše Re: A google?
    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.
    11.8.2010 08:04 zz9
    Rozbalit Rozbalit vše Re: A google?

    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?

    11.8.2010 14:33 VSi | skóre: 28
    Rozbalit Rozbalit vše Re: A google?
    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ý.
    11.8.2010 15:26 zz9
    Rozbalit Rozbalit vše Re: A google?
    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?
    11.8.2010 08:32 BrainLess
    Rozbalit Rozbalit vše Re: A google?
    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 ).
    12.8.2010 10:08 Ivan
    Rozbalit Rozbalit vše Re: A google?
    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.

    Marek Stopka avatar 12.8.2010 11:10 Marek Stopka | skóre: 57 | blog: Paranoidní blog | London, United Kingdom
    Rozbalit Rozbalit vše Re: A google?
    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.

    Založit nové vláknoNahoru

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