In de IT-infrastructuur, met het wijdverspreide gebruik van virtualisatie, zijn opslagsystemen de kern die alle virtuele machines opslaat. Een storing van deze eenheid kan de werking van het datacentrum volledig stopzetten. Hoewel een aanzienlijk deel van de serverapparatuur op de een of andere manier standaard redundantie biedt, gelden er vanwege de bijzondere rol van opslagsystemen in datacentra verhoogde eisen aan hun 'levensvatbaarheid'.
De meest effectieve manier om redundantie in IT te waarborgen, is door meerdere exemplaren van hardware en software te gebruiken (in de eenvoudigste vorm: duplicatie). Natuurlijk kan een opslagsysteem volledig worden gedupliceerd. Voor disaster recovery wordt juist deze aanpak toegepast. Maar niet alle bedrijven kunnen zich zo'n oplossing veroorloven. Het gaat niet alleen om de dubbele kosten van de apparatuur, maar ook om andere uitgaven die verband houden met het organiseren van zo'n oplossing en het onderhoud ervan.
Echter, de mogelijkheid om apparatuur te dupliceren maakt het nog steeds noodzakelijk om redundantie op componentniveau te waarborgen. In het bijzonder wordt er in opslagsystemen gebruikgemaakt van redundantie voor voedingen, koelmodules, schijven en natuurlijk controllers. Dit is al lang een noodzaak geworden. Het is moeilijk om een opslagsysteem te vinden zonder dit soort ontwerp. Dat geldt ook hier. Maar in dit artikel willen we het hebben over wat niet meteen in het oog springt, en dat voornamelijk gericht is op het verbeteren van de algehele redundantie van het systeem.
Koelmodules
Heel vaak wordt in de 2U-3U behuizingen gebruikgemaakt van gecombineerde modules die voedingen en ventilatoren samenvoegen. Aan de ene kant is dit handig, omdat je slechts Ć©Ć©n eenheid hoeft te onderhouden. Aan de andere kant, als het koelsysteem faalt, kan de voeding gedwongen worden uitgeschakeld om oververhitting te voorkomen. Dit lijkt misschien niet de meest kritieke situatie, maar het is duidelijk niet wijs om extra kwetsbaarheden aan het opslagsysteem toe te voegen.
De koeling in de Qsan storage array is georganiseerd in de vorm van afzonderlijke modules met 'hot swap', onafhankelijk van de voedingseenheden. In feite bevatten de voedingseenheden hun eigen ventilatoren, die zijn ontworpen om de voedingseenheden zelf te koelen. De koelingsmodule bevat twee onafhankelijke ventilatoren die elkaar ondersteunen. Er zijn twee van dergelijke modules in de opslagarray, aan de rechter- en linkerkant, voor een effectieve koeling van alle componenten. Als een van de ventilatoren uitvalt, verhogen alle andere automatisch hun snelheid om het tekort aan luchtstroom te compenseren. Daarom leidt een defecte ventilator niet tot het gevaar van oververhitting van het gehele apparaat.
Topologie van het aansluiten van uitbreidingsmodules
De klassieke aansluitingsschema voor de opslagarray is gebaseerd op een topologie die cascade wordt genoemd. In dit geval worden de bijbehorende controllers van de module en de opslagarray met een enkele SAS-kabel met elkaar verbonden. Dit resulteert in 2 kabels voor een systeem met twee controllers. Als een tweede moet worden aangesloten, wordt deze op dezelfde manier op de eerste module aangesloten. Enzovoort. Het voordeel van deze topologie is de eenvoud van implementatie in de apparatuur. Het nadeel is echter een zekere kwetsbaarheid voor plotselinge onderbrekingen van de SAS-keten door het uitvallen van controllers die niet met elkaar verbonden zijn, of door het uitschakelen van een van de uitbreidingsmodules in het midden van de keten. Dit resulteert in verlies van toegang tot een deel van de schijven en mogelijk het onbruikbaar worden van de RAID-groep als deze 'verspreid' is over verschillende kasten.
Qsan heeft bescherming tegen het uitvallen van controllers in de vorm van interne logische verbinding tussen controllers via de backplane van de opslagarray. Dat wil zeggen, de opslagarray-controller ziet niet alleen de JBOD-controller die direct is aangesloten, maar ook de controller van de 'buur' via een speciale link in de backplane. Als deze situatie zich voordoet en niemand fysiek de SAS-kabels tussen de opslagarray en de module verwijdert, blijft de toegang tot alle schijven behouden.
Om te beschermen tegen onderbreking van de SAS-keten, bijvoorbeeld door het uitschakelen van een uitbreidingsmodule, wordt doorgaans een andere aansluitingsschema toegepast - de omgekeerde cascade. In dit geval wordt de opslagarray direct verbonden met zowel de eerste als de laatste module in de keten, waardoor toegang tot de schijven van twee kanten wordt verkregen.
Als je een sterkere bescherming wilt, dan kun je grotere configuraties bouwen, bijvoorbeeld door een boomtopologie te gebruiken. Of je kunt het verder compliceren door de eerder genoemde topologieƫn te combineren. Dit is mogelijk dankzij het grote aantal SAS-aansluitingen op de apparaten (2 voor elke controller van de opslagcontroller en 5 voor elke controller van de JBOD) met automatische detectie van de in-/uitgangsmodi. Het belangrijkste is dat de beheerder zelf niet in de war raakt. En de opslagcontroller zal de configuratie correct instellen.
Snelle rebuild
De aanwezigheid van reserve-schijven met 'hot spare'-functionaliteit in het systeem verhoogt de betrouwbaarheid van gegevensopslag aanzienlijk. Echter, het enkele feit dat dergelijke schijven zijn toegewezen betekent nog niet absolute bescherming. Het probleem is dat het herstelproces (rebuild) behoorlijk arbeidsintensief en vaak langdurig is. De arbeidsintensiviteit ontstaat door de voortdurende toegang tot de primaire gegevens. Dat wil zeggen, het systeem moet naast de huidige werkzaamheden ook gegevens naar de nieuwe schijf kopiƫren. En de duur van de rebuild hangt rechtstreeks af van de capaciteit van de opslag en zijn snelheidseigenschappen. Aangezien het systeem niets weet over de werkelijke bezette ruimte op de schijven, kopieert het tijdens de rebuild gewoon alles: blok voor blok.
Als gevolg hiervan kan het herstel van een moderne schijf met een grote capaciteit van 10+ TB onder zware belasting van de opslagcontroller gemakkelijk een week of langer duren. Ook moet worden opgemerkt dat tijdens de rebuild de kans op falen van andere schijven aanzienlijk toeneemt door de verhoogde belasting. Dit kan al een ernstig gevaar vormen, bijvoorbeeld bij het gebruik van RAID5.
Als oplossing voor dit probleem hebben veel ontwikkelaars van opslagcontrollers zich gericht op het versnellen van het herstelproces. Verschillende benaderingen kunnen worden toegepast, maar de essentie blijft dezelfde: het kopiƫren tijdens de rebuild van alleen de daadwerkelijk gebruikte blokken. Ook Qsan heeft zich met dit probleem beziggehouden. Bij de opslagcontrollers van deze aanbieder, bij geactiveerde optie het systeem houdt bij welke blokken worden gebruikt voor schrijven, waardoor het in geval van schijffalen alleen die op een nieuwe opslag kan kopiƫren.
De optie Snelle Rebuild is standaard niet ingeschakeld bij het aanmaken van nieuwe volumes, aangezien het gebruik ervan invloed heeft op de prestaties, vooral bij random write-operaties, omdat:
- Het is noodzakelijk om de registratie in blokken bij te houden;
- Bij een rebuild vindt er geen herberekening van de checksums voor ongebruikte ruimte plaats, waardoor het noodzakelijk is om deze eerst te 'initialiseren' voordat er nieuwe gegevens in dit gebied worden geschreven.
Daarom wordt het gebruik van Fast Rebuild voor volumes, zoals die met zwaarbelaste databases of in videobewakingssystemen, waar het volume uiteindelijk toch 100% gevuld zal zijn, niet aanbevolen. Voor bestands- of mailservers zal deze optie echter zeer nuttig zijn.
Ter afsluiting
Elke fabrikant van opslagsystemen gaat ervan uit dat zijn apparaten betrouwbaar zijn. En als er geen fatale fouten zijn bij de ontwikkeling van de apparaten en er geen ongekende zuinigheid is tijdens hun productie en testen, dan kan men in het algemeen met de leverancier instemmen. Het is echter belangrijk te begrijpen:
- de basisfailover van opslagsystemen is in de eerste plaats een manier om toegang tot gegevens te blijven behouden in geval van uitval van een of meer componenten;
- extra opties voor failover (zoals die hierboven beschreven) zijn bedoeld om enkele soorten storingen uit te sluiten en uw kansen op toegang tot gegevens te vergroten;
- 100% betrouwbaarheid bestaat helaas niet. Maar om er zo dicht mogelijk bij te komen, doen de meeste verstandige leveranciers van opslagsystemen (en inclusief hen) hun uiterste best om hun producten zowel op hardware- als softwaregebied continu te verbeteren.
Daarnaast moet men niet vergeten dat geen enkele absolute betrouwbaarheid van opslagsystemen het bestaan van back-ups, duidelijke en geoefende herstelplannen in geval van een storing en snelle technische ondersteuning van de leverancier vervangt.
Bron: habr.com
