Zavřít
Vstoupit Následujte nás

3S.cz

Odborná sekce

Fenomén, který zpomaluje i vaši SAN síť!

06.01.2021, 10:05

Pokud se sítěmi Fibre Channel pracujete pravidelně a jste závislí na jejich vynikajících výkonnostních atributech, možná vás překvapí, že právě SAN sítě jsou čím dál častěji zdrojem výkonnostních problémů řešených naším SAN Analytickým týmem zákaznické podpory.

FibreChannel bývá vnímán (právem) jako něco extrémně rychlého a spolehlivého, zkrátka protokol, ve kterém se příčiny výkonnostních problémů nehledají. Většina storage administrátorů automaticky za viníka považuje diskové pole a hledá chybu zde. Nicméně nemusí tomu tak být.

A co to změnilo?

Změnu přinesly flash technologie v diskových polích. Byla to vskutku fantastická změna. Za poslední desítku let Disková pole díky Flash technologii zrychlila z řádu tisíců IOPs (dosažitelných rotačními disky) do řádu statisíců až desítek milionů IOPs dosažitelných pomocí Flash akcelerací. To je zrychlení x1000 a více.

Hitachi Hi-Performance Flash Modul drive

 

Jak se vedle tohlo vyvíjel protokol FibreChannel?

Z rychlosti 4 Gbps jsme se propracovali na 32Gbps, kterou trh začíná pomalu a váhavě adoptovat. To je zrychlení x8. A to je zjevný nepoměr vývoje poslední dekády - navýšení výkonností diskových polí x1000 verzus přenosových cest x8.

Takový nepoměr má své konsekvence. Výsledkem je, že sítě SAN – Storage Area Network, které poskytují propojení mezi servery a Diskovým polem, jsou tlačeny ke svým fyzikálním limitům. V této specifické situaci dochází k vyčerpání vyrovnávacích pamětí FibreChannel portů (tato paměť je nazývána Buffer/Buffer kredit) a port, který má vyčerpané B2B kredity není schopen zpracovat žádný další datový rámec. V literatuře je tento fenomén degradace kvality služby Diskového pole nazýván “Slow Drain Device” problém. Bottleneck se tak přesouvá často ze samotného diskového pole na úroveň FibreChannel SAN sítí a způsobuje latence. 


Latence diskového pole

Předpokládám, že coby IT administrátoři monitorujete Latence neboli Response Time diskového pole. Je to základní metrika, která vypovídá o kvalitě služby, kterou Vaše aplikace dostávají. Vypadá řekněme obdobným způsobem jako následující graf z FullFlash systému Hitachi VSP G900:

Položili jste si otázku, co vlastně takovýto graf prezentuje?

Předpokládám, že ano a nejčastější odpověď byla: "říká jak dlouho diskovému poli trvá reagovat na požadavek serveru". A přesně tato odpověď je bohužel špatně, přestože ji pravděpodobně slyšíte i od řady specialistů v Data Storage oboru. Pravdou je, že vzhledem k transakční povaze FibreChannel protokolu, je latence celkový čas od okamžiku, kdy diskové pole přijme požadavek serveru, zpracuje jej, přenese sítí SAN po okamžik, kdy protistrana potvrdí úspěšný přenos celé IO operace.

V čem je tedy rozdíl?

V tom, že latence uváděné diskovým polem nejsou pouze čas, který potřebuje diskové pole, aby zprocesovalo IO požadavek. Je to latence včetně času, který potřebuje FibreChannel síť, aby tato data přenesla.

Představte si situaci, kdy server požádá o data. Diskové pole rychlostí křemíku připraví odpověď, což může trvat dokonce méně než 0,1 milisekundy. Představte si, že v síti SAN máte bottleneck, který zaviní latence v řádu stovek milisekund. Pravděpodobně všechny možné monitoringy diskového pole, VMware apod se zaplaví plejádou červených alertů: "Pozor vysoké latence!".

V této modelové situaci byla vina bottleneck v SAN. Pokud Váš "odborník" na straně dodavatele neumí vyhodnotit skutečnou příčinu problému, automaticky označí jako viníka diskové pole, přece latence ukázal jeho monitoring, že ano. Pravděpodobně se od „odborníka“ dozvíte, že potřebujete ještě více drahé Flash kapacity. Ještě rychlejší diskové pole. A nejlépe kompletně FullFlash kapacitu aby to "pořádně performovalo".

Rady uposlechnete, vysypete z prasátka řádově miliony Kč a nakoupíte Flash upgrade či rovnou nové diskové pole. Zapojíte jej do SAN, přemigrujete data ... a zjistíte, že výsledek je ještě tristnější. Je možné, že výkonnější diskové pole může vést k horším výsledkům? Ano, je to možné a je to důsledek "Slow Drain Device" stavů v síti SAN, které v znikají v důsledku nedodržování Best Practicies pro design SAN sítí. A co více - není to jen teoretická situace. Je to reálný scénář, který se odehrává velmi často.

Pokud jste podobný scénář zažili, máte dvě možnosti. První je uposlechnout rady "odborníka", který vám řekne, že potřebujete ještě více ještě dražších Flash disků. Druhou možností je číst dále a zamyslet se nad chováním SAN infrastruktury jako celku se všemi jeho konsekvencemi.

 

Podstata SAN sítí - FibreChannel jako bezztrátový protokol

Jak je toho dosaženo? Tím, že Fibre Channel používá k řízení přenosu kredity mezi vyrovnávacími paměti. Hodnota kreditu se sníží při odeslání rámce z portu a hodnota kreditu se doplní, když port obdrží odpověď.

Základní pravidla jsou následující:

  • Rámce se přenášejí, pouze pokud je známo, že protistrana má k dispozici paměťový slot pro příjem rámce = takzvaný Buffer Credit
  • Každý odeslaný rámec musí být zpětně potvrzen příkazem R_Rdy. Tím je jistota úspěšného přenosu a zařízení může uvolnit paměťový slot (B2B kredit)
  • Každá strana informuje druhou stranu o počtu kreditů v bufferu má
    - F porty - V přihlášení Fabric (FLOGI)
    - E porty - v parametrech Exchange Link Parameters (ELP)

 

S trochou nadsázky...

FC = "Hej, odesílateli - mám připravený koš této velikosti. Teď, když už to víš, jdi a hod mi přesně tolik jablek (nebo méně) najednou, dokud neřeknu jinak. Tímto způsobem bude přesun všech jablek pekelně efektivní, protože oba budeme vědět nezávisle, kdy je můj košík plný. “

Ethernet = "Teď, když mám vaši pozornost, budu házet jablka, dokud vás neuslyším křičet, že vám nějaké spadlo. Když k tomu dojde, na chvíli se zastavíme a můžete mi říct jen číslo z posledního jablka, které máte, odtamtud budeme házet dál. Není to nejefektivnější, ale svá jablka časem dostanete.“


Pokud propojené FibreChannel porty mají k dispozici volnou vyrovnávací paměť, tedy volné B2B kredity, probíhá komunikace bez problému. Pokud však nastane situace, že nějaký sled událostí zcela vyčerpá volné B2B kredity, nastává patová situace. Port nemůže komunikovat a vznikají latence. Patová situace může být až tak hluboká, že z ní není úniku, tj. neprocházejí ani potvrzovací signály a nemůže se tak uvolňovat vyrovnávací paměť.

Naštěstí existuje v sítích SAN inherentně zabudovaný mechanismus úniku z této patové situace. Switch vyšle příkaz BUS_Reset, čím vyčistí probíhající komunikaci, vyprázdní paměti B2B kreditů a celý přenos IO operace se pokusí zopakovat. Je to účinná, ale poněkud drastická léčba. Daní za tuto léčbu je vzrůst latencí na úroveň stovek milisekund. A dlužno podotknout, že je to z hlediska IT administrátora zdánlivě nepochopitelný vzrůst latencí - Disky diskového pole jsou utilizovány na pár procent, Procesory diskového pole také, vše je vlastně v nejlepším pořádku ... a přesto grafy ukazují extrémní latence.

 


Slow Drain Device

Předpokládejme, že máme potrubí schopné přepravovat do rezervoáru (vyrovnávací paměti) 16 Gps (galonů za sekundu), ale výstup z rezervoáru umožňuje pouze 8 Gps. Dokud je množství přitékající vody menší nebo rovné 8 Gps, bude voda z rezervoáru vytékat přibližně stejnou rychlostí, jakou do ní proudí. Lze také očekávat, že pokud byste trvale překračovali průměr 8 Gps, tak hladina vody v rezervoáru začne stoupat.

Stejný druh problému se může stát v síti FC SAN z mnoha důvodů, včetně:

  • Slow Drain Device problém = „Pomalý odtok“, který vede k vyčerpání vyrovnávacích pamětí (B2B kreditů)
  • Ztráty kreditů = fyzické chyby v jejichž důsledku se kredity a rámce se neposílají spolehlivě, což opět vede vyčerpání vyrovnávacích pamětí (B2B kreditů)
  • Oversubscription/Overutilization = • Neshoda rychlostí (např. 16G až 4G) • Nesoulad Fan-In/Fan-Out (např. 4 porty mapované do 1 portu) • Zařízení jednoduše požaduje více dat, než kolik může spotřebovat při dané rychlosti připojení


Je důležité si uvědomit, že ve všech výše uvedených scénářích se používá řízení toku Buffer-to-Buffer, aby se zajistilo, že je v FC targetu k dispozici dostatečná vyrovnávací paměť pro uložení všech rámců zaslaných FC initiátorem. Výsledkem je, že FC initiator nekomunikuje, kdykoli není schopen vyslat rámec kvůli nedostatku vyrovnávací paměti na druhém konci spoje. Například, jak je ukázáno níže, přetížení se rozšířilo z Targetu zpět na Iniciátor kvůli neshodě v datových rychlostí:

 


Další příčiny vyčerpání B2B kreditů v sítích SAN

Řada storage administrátorů se domnívá, že "Slow Drain Problem" nastatává pouze v případě propojení rychlejšího zařízení (16Gbps) s pomalejším zařízením (například 8Gbps). To je pravda, ale úplně stejné situace mohou nastávat i v prostředích, kde všechny porty běží na stejné rychlosti. Podívejme se, co se stane s trochu komplikovanější topologií, kdy jeden 16Gbps Initiator port komunikuje se dvěma 16Gbsp Target porty.

Server chce číst data z diskového pole. Pošle například skrze Port1 své FibreChannel karty požadavky diskovému poli. Pokud je diskové pole rychlé (což v dnešní době hybridních nebo FullFlash polí zpravidla je), tak diskové pole začne všemi aktivními porty servírovat odpověď. A přesně v tomto okamžiku se projeví slabina následující SAN architektury:


Problém spočívá v tom, že jeden port serveru je mapován na dva aktivní porty diskového pole - z každého kontroleru jeden. Je to zdánlivě dobrý nápad z důvodu vysoké dostupnosti, protože každý port serveru vidí oba kontrolery diskového pole.

Nicméně je to velmi špatný nápad z hlediska výkonnosti. Vraťme se do okamžiku, kdy server zaslal diskovému poli skrze Port1 požadavek na čtení většího objemu dat. Výkonné diskové pole mu začne posílat odpověď všemi aktivními porty -tedy Portem1 kontroleru A a zároveň Portem1 kontroleru B. 

Co se v tento okamžik děje?

Všimněte si, že FC rámce jsou z diskového pole posílány serveru rychleji, než je port serveru dokáže zpracovat - zkrátka dvě 16Gbps cesty slévají do jedné 16Gbps cesty. To způsobí, že paměť B2B kreditů na Switchi 1 se naplní rámci určenými pro Port1 serveru a tento port se dostane do patové situace - není schopen přijímat další data. Jenže z diskového pole se tlačí do switche další FC rámce a původně problém jednoho portu se začne rozlévat na další porty. Vzápětí se v dané zóně se do patové situace dostávají oba Porty1 na obou kontrolerech diskového pole.

Porty diskového jsou obvykle sdílené celou řadou dalších serverů a problém se začíná rozlévat v celé SAN zóně. Ve finále graduje v nemožnost komunikace řady dalších serverů, které s daným problémem původně neměly vůbec nic společného.

V extrémních případech, jako je tento, je celá SAN zóna v patu a nemůže přenášet další rámce. FC porty v dané zóně mají zcela vyčerpané B2B kredity. Patová situace může přetrvávat až 2 sekundy, kdy switch zahájí protokol resetování FC sběrnice. Dopad na zbytek prostředí jsou latence v řádu stovek až tisíců milisekund. Některé aplikace takové situace mohou tolerovat, ale u aplikací citlivých na latence (např. Oracle RAC cluster) vznikají velké problémy.

 

Jak zjistit, že se v sítích SAN odehrává něco nezdravého?

Jedním slovem... obtížně. Je to fenomén, který se odehrává mimo samotné diskové pole. Monitoring diskového pole jej nevidí přímo, vidí pouze určité signatury jeho projevů. V rámci  společného projektu výzkumu 3S.cz a VUT Brno v programu „TRIO“ jsme vyvinuli Expertní systém pro automatickou analýzu a řízení big data úložišť, který pomocí umělé inteligence je schopen signatury problémů v SAN identifikovat.

 

Jedna z indicií umožňující udělat si představu, zda je Vaše SAN v pořádku, jsou následující countery, které můžete najít u Brocade FC switchů:

  • BB credit zero - Rx Number of times the receive buffer-to-buffer credit count transitioned to zero during the sampling period
  • BB credit zero - Tx Number of times the transmit buffer-to-buffer credit count transitioned to zero during the sampling period
  • BB credit zero - Total Number of times this port had to stop transmitting because the attached port was out of credits to provide
  • BB credit zero duration - Tx Time in milliseconds during which the Tx BB credit was zero during the sampling interval


BB credit zero indikuje počet případů, kdy port nebyl schopen přenášet rámce, protože B2B kredit byl nulový. Účelem této statistiky je detekovat přetížení nebo zařízení ovlivněné latencí. Tento parametr se vzorkuje v intervalech 2,5 mikrosekundy a počítadlo se zvýší, pokud je podmínka pravdivá. Každý vzorek představuje 2,5 mikrosekundy času s nulovým kreditem Tx nebo Rx BB. Přírůstek tohoto čítače znamená, že rámce nelze odeslat do připojeného zařízení po dobu 2,5 mikrosekundy, což naznačuje snížený výkon.

BB Credit Zero není nutně chybový stav, je to pouze informace o tom, že daný port vyčerpal svoji vyrovnávací paměť. Určitá drobná množství těchto situací je ve světě FC normální okolnost. Vysoké stavy tohoto counteru však už lze považovat za alarmující a důvod k celkové revizi SAN topologie. I když se výše uvedené scénáře mohou zdát trochu extrémní, běžně se v zákaznických prostředích odehrávají.

 

Když tyto události nastanou, mohou být velmi bolestivé, protože mají široký dopad a jejich řešení je obtížné.

Specializace společnosti 3S.cz, s.r.o. zahrnuje širokou oblast DATA STORAGE ŘEŠENÍ – počínaje primárním úložištěm, virtualizací, zálohovánímarchivací dat po management software. Jsme klíčovým partnerem Hitachi Vantara na trhu s prostředky pro ukládání elektronických dat v ČR. Hlavním produktem je dnes individuální design řešení, se kterým vám rádi pomůžeme, včetně monitoringu tohtoto typu fenoménu - neváhejte nás kontaktovat.