Synology expansie disconnectie: onze aanpak - Technical Fact
Aan de hand van onze technical fact reeks geven we je een inkijk in hoe onze technical engineers te werk gaan. Ze staan voor je stil bij problemen die ze tegenkomen in het werkveld, geven een inkijk in onze services en spelen in op hot topics uit de IT-wereld. Dit in de hoop jou en je IT-team te kunnen ondersteunen of verder helpen.
De klant waar we in dit technical fact over spreken doet beroep op onze housing service. Dit betekent dat zijn IT-infrastructuur is ondergebracht in ons datacenter. Zowel de hardware als de software van onze klant draait in dit geval in onze racks. Dit in zowel het datacenter van Antwerpen als Zaventem. Daarnaast staan we niet enkel in voor de housing van hun IT, maar nemen we eveneens het volledige beheer van de IT-omgeving van A tot Z op ons.
Beginsituatie
Onze monitoring service detecteerde volgend probleem bij een van onze klanten: een crash van twee HDD disks die behoorden tot éénzelfde volume op een Synology NAS. De onderliggende storage pool was geconfigureerd in een RAID-5. Voor diegenen die niet bekend zijn met RAID-5: deze technologie wordt gebruikt om data weg te schrijven (disk striping in combinatie met parity) en is dus van groot belang als extra zekerheid voor hun back-up & archiving proces. Meer nog, een RAID-5 kan maar 1 HDD failure tegelijk tolereren, dus twee disks die tegelijk falen geeft een risico op data loss. Toen we deze melding detecteerden schoten we dan ook meteen in actie.
Oplossing Core ICT
Wanneer in een bepaalde case de hardware vastloopt en deze een fout aangeeft, nemen we als eerste stap contact op met de vendor. In dit geval contacteerden we de support van Synology.
De supportmedewerker adviseerde ons om beide drives te reseaten, zodat we de connectie ervan konden testen. Eén van de drives slaagde er hierdoor in om terug online te komen, terwijl de andere faalde om connectie te maken met zijn controller. Op dit moment waren we gelukkig al uit de data loss zone, gezien 1 gefaalde disk geen probleem geeft voor een RAID-5. We zetten onze troubleshooting verder. In tussentijd keek de vendor de logs na en ontdekte hier de oorzaak van de crash: een onderbreking van de connectie tussen het expansie chassis en het primaire chassis.
We vroegen een RMA (Return Merchandise Authorization) aan om de huidige expansie te kunnen vervangen. De vendor stuurde op korte termijn enkele onderdelen op. In eerste instantie verstuurden ze enkel de expansie kabel, maar aangezien dit ontoereikend was moesten we de volledige expansie unit vervangen en bezorgden ze ons deze eveneens.
Opnieuw tijd voor een test. Jammer genoeg was er niets veranderd en bleef één van de twee disks offline, terwijl de andere geen issues meer meldde. Hierdoor werd het duidelijk dat de disk het probleem was geworden na de onderbreking tussen het chassis en de expansie en dat deze aan vervanging toe was. Van de vendor kregen we een nieuwe disk toegestuurd waarna we de corrupte disk konden vervangen.
Waarom niet als eerste de disks vervangen en testen vraag jij je af? In samenspraak met de support gingen we eerst met het chassis en de expansie aan de slag. Als we dit niet zouden doen en het probleem zou zich wel op dit niveau manifesteren, zouden de overige disks mogelijks ook geïnfecteerd kunnen raken. Als gevolg zouden er nog meer disks offline kunnen gaan en zouden we het probleem dus enkel groter maken. Het chassis werd dus puur uit veiligheidsoverweging vervangen.
Next steps
Nadat de verschillende onderdelen vervangen waren creëerden we een nieuw volume. Het oude was namelijk corrupt door de kapotte disks. Gelukkig stonden hier nog maar weinig actieve gegevens op. Het was nog niet zo lang in productie en zou enkel gebruikt worden om de data te archiveren. Indien er meer gegevens op dit volume zouden staan, hadden we deze eerst moeten migreren naar een tijdelijke plaats om vervolgens het volume opnieuw aan te kunnen maken.
Vanaf het begin van de case, pauzeerden we de archiveringsback-ups. Het was belangrijk dat we deze stap uitvoerden alvorens we nieuwe volumes zouden aanmaken. De reden hiervoor was dat de volumes die op dat moment in stonden voor de archivering van de data, hun capaciteit hadden bereikt. Normaal zou op dit moment het nieuwe volume automatisch in gebruik worden genomen. Dit was echter niet mogelijk, aangezien deze niet operationeel was door de crash. We besloten daarom de archiveringsback-ups vanaf het begin te pauzeren. Als we deze stap niet zouden uitvoeren, zouden we foutmeldingen van de back-ups ontvangen die aangaven dat er te weinig storage vrij was. Door de archiveringsback-ups tijdig te pauzeren konden we dus verschillende warnings voorkomen.
Nadat we het nieuwe volume aanmaakten op de Synology voegden we dit als target toe aan de back-up software. Zo konden we de archiverings-back-ups terug laten lopen. Deze verliepen vlekkeloos waardoor het volume terug werd volgeschreven en de taken terug konden hervatten zoals voorheen.
Conclusie
Dankzij onze monitoringsservice pikten we het incident snel op en konden we het op korte termijn oplossen. Aanvullend willen we vanuit onze eigen ervaring nog een aantal zaken meegeven in verband met je back-up en archiving. Zo is het zinvol om zowel je RAID-opstelling als back-up schijven te gebruiken voor belangrijke opslagopstellingen. We merken in de praktijk namelijk dat er te weinig wordt nagedacht over de opstelling van deze oplossingen. Retentie, RAID-opstelling, het aantal back-up schijven dat je best gebruikt, potentiële groei van je bedrijf zijn zaken die vaak niet aan bod komen. We zien dat er vaak pas aandacht aan wordt geschonken nadat het in de praktijk is misgelopen.
Wil je dit voorkomen en een degelijke back-up strategie uitwerken? Of heb je nog vragen over deze case? Aarzel niet en neem contact op via onderstaand formulier.