Xylos brands

High-available file servers ontwerpen in Azure: een afweging tussen mogelijkheden en beperkingen

Traditionele file servers vereisen heel wat onderhoud en als je de bestaande infrastructuur wilt upgraden of updaten, sta je doorgaans voor een moeilijke, dure en inefficiënte opdracht. Daarom ontwerpen wij technische designs die je op dit vlak volledig ontzorgen. Maar hoe ontwerp je nu zo'n file server in Azure? Laten we het proces illustreren met een van onze klantencases.

Ons klantscenario

Onlangs vroeg een klant ons of we een oplossing konden leveren om on-premises file servers die over heel België verspreid stonden, naar de cloud te migreren.

De oplossing moest aan het volgende lijstje eisen voldoen:

  • High availability
  • Gecentraliseerd
  • Schaalbaar
  • Onderhoudsvriendelijk
  • Gemakkelijk te herstellen

Daarnaast moesten we rekening houden met de volgende vereisten:

  • Hoeveelheid data: 8 TB (11 miljoen bestanden), verspreid over tien locaties in heel België
  • NTFS-machtigingen moesten worden overgedragen
  • De bestanden moeten minstens tien jaar lang bewaard worden

Na een grondige analyse en een succesvolle proof of concept stelden we het volgende technische ontwerp op:

In de volgende secties gaan we dieper in op sommige keuzes die we hebben gemaakt.

Onze Azure-oplossing

Azure Files

Op het eerste gezicht leek Azure Files de meest gepaste oplossing, maar er was één cruciaal struikelblok: om ACL's te gebruiken, moesten we Azure Active Directory Domain Services instellen. Omdat dit geen optie was, moesten we een andere manier bedenken om onze doelen te halen.

Windows Server met de kracht van Azure

Een Windows-serverconfiguratie dan?

We beginnen bij het begin: eerst maakten we twee file servers in Azure. Hiervoor gebruik je het best een ARM-template: met zo’n template kun je de file servers automatisch herindelen en het document bevat specifieke informatie over het design, zodat iedereen die informatie kan bekijken wanneer nodig.

We hadden een VM voor algemene doeleinden nodig. Nadat we de opties hadden overwogen, besloten we dat 'Standard_D4s_v3' de beste keuze was voor onze oplossing. Als de oplossing krachtiger of net minder krachtig moest zijn, konden we de grootte eenvoudig aanpassen.

We plaatsten de servers ook in twee verschillende Availability Zones om de gewenste redundantie te behalen. Zelfs als een volledig datacenter om de een of andere reden zou uitvallen, konden we zo terugvallen op een virtual machine in een ander datacenter.

Tot slot gebruikten we twee schijven van 4 TB om alle data op te slaan.

Waarom twee schijven van 4 TB?

Zo konden we een belangrijke beperking van Azure omzeilen: “Large disk support – Now you can backup VMs with disk sizes up to 4 TB (4095 GB), both managed and unmanaged.”

Eén implementatie later ...

Een van de problemen bij de klant was dat de schijfruimte op hun file servers bijna vol was. Om dit te verhelpen, wilden we ervoor zorgen dat de dataset van onze klant in de nabije toekomst oneindig kon groeien.

Dit deden we met behulp van Windows Storage Spaces. De schijven van deze file servers zijn geconfigureerd als een gestripete, thin provisioned virtuele schijf (met Simple Storage Layout). Dit betekent dat er op elk gewenst moment extra schijven aan de VM kunnen worden gekoppeld en dat de virtuele schijven kunnen worden uitgebreid wanneer nodig, zonder downtime. Zo kon elke Storage Space dynamisch groeien. Daarnaast was er nog een ander voordeel: we moesten geen teveel aan opslagruimte voorzien (lees: te veel geld verspillen), maar alleen de opslagruimte voorzien die we in de nabije toekomst nodig hebben.

 

Dankzij Windows Storage Spaces konden we het vakje 'schaalbaar' op de lijst van onze klant aanvinken.

Over naar high availability

Om de file servers gesynchroniseerd te houden, gebruikten we Azure File Sync.

Hoe weten we op welke server de werknemers werken? Wat gebeurt er als twee werknemers op verschillende servers aan hetzelfde bestand werken?

Dit probleem losten we op met DFS (Distributed File System). Voor elke Site hebben we bepaalde naamruimtes gemaakt, maar hiervoor kun je elke gewenste datatopologie gebruiken. 

Het geheim? Prioriteit instellen voor een naamruimte. Als je bijvoorbeeld de naamruimte van file server 1 prioriteit geeft, wordt al het verkeer naar deze server geleid, tenzij de verbinding onbeschikbaar is. Zo creëer je een actief-passieve opstelling. Als file server 1 dan om de een of andere reden niet beschikbaar is (patches, Azure-datacenter onbeschikbaar, ...), leidt de DFS-naamruimte al het verkeer om naar file server 2 tot de verbinding hersteld is.

De Azure-configuratie

We hadden dus twee file servers met DFS. Het verschil met een on-premises file server-opstelling is dat we de bestanden op beide servers met Azure File Sync gesynchroniseerd konden houden.

Voor het gebruik van Azure File Sync heb je een opslagaccount nodig. Omdat in dit geval de bestanden in het opslagaccount op beide servers moesten worden gedupliceerd en slechts passief werden gebruikt om de servers te synchroniseren, volstond de standaardperformantie met lokaal redundante opslag.

We maakten een fileshare aan voor elke site. Dit was weer een keuze die we zorgvuldig moesten afwegen. Met een andere beperking van Azure in het achterhoofd (de maximale grootte van een fileshare in Azure is 5 TiB) berekenden we dat als elke site ongeveer 10 TiB/10 Sites = 1 TiB omvat, elke site nog 4 TiB kon uitbreiden voordat we actie moesten ondernemen. Nog een voordeel is dat we het eenvoudig konden houden door geen extra abstractie per laag te maken (door bijvoorbeeld voor elke schijf een fileshare te maken).

Daarna moesten we de Azure File Sync Agents op beide servers installeren. Met Powershell CmdLets als installatie-interface is dat kinderspel, dus ga ik hier niet te diep op in. Lees meer over Powershell CmdLets als installatie-interface

Het resultaat

Synchronisatiegroepen

De eindpunten

Volgende stap: alle data migreren. Het is essentieel dat je deze stappen juist uitvoert. Om de implementering met 10 TB zo vlot mogelijk uit te voeren, moet je alle data naar één server overzetten, zodat AFS nadien alle bestanden naar de tweede server kan synchroniseren. Als je dezelfde data tegelijk naar beide servers probeert over te zetten, loopt het gegarandeerd mis.

Wij gebruikten de bewezen robuuste kopieeroplossing Robocopy om alle data te migreren. Robocopy heeft enkele krachtige switches die de oplossing perfect maken voor ons project.

  • /mir switch: Mirrort de mapstructuur. Erg handig voor delta's en incrementele migraties.
  • /mt:[n] switch: Maakt multi-threaded kopieën met N threads. N moet een geheel getal tussen 1 en 128 zijn. Dit maakte het proces heel wat sneller.
  • /copy:<copyflags> met flags D=Data, A=Attributes, T=Time stamps, S=NTFS Access Control List (ACL), O=Owner information en U=Auditing information. Al deze waarden moesten ook worden gekopieerd.

Hiernaast bestaan er nog interessante switches, maar deze drie hadden we nodig voor onze doeleinden. 

Azure levert ook mooie visuele diagrammen en is voortdurend bezig met het verbeteren van die diagrammen. Zo weet je in een oogopslag wat er precies gebeurt.

To Cloud Tier or not to Cloud Tier?

Cloud tiering is een optionele, maar krachtige functie in Azure File Sync waarbij vaak gebruikte bestanden lokaal op de server worden gecachet terwijl alle andere bestanden op basis van de beleidsinstellingen naar Azure Files worden 'getieret'. Hierbij vervangt de Azure File Sync-systeemfilter (StorageSync.sys) het bestand lokaal door een pointer of reparse point. Een reparse point is een URL naar het bestand in Azure Files.

Hoewel we deze functie perfect konden gebruiken, botsten we hier op een andere beperking van Azure, waardoor we de functie voorlopig links moesten laten liggen. Hierover lees je meer in het volgende deel: back-up en bewaring.

Wat met back-ups en bewaring?

Wegens wettelijke en nalevingsredenen moest de klant alle bestanden minstens tien jaar lang bewaren. Dit konden we op verschillende manieren verwezenlijken. Hieronder vermelden we er een paar.

MABS back-upserver

DPM/MABS biedt volledige granulariteit voor back-up en bewaring, maar in de praktijk zou MABS de hoeveelheid data in dit project niet aankunnen. Als je hiermee een virtual machine met een dataset groter dan zo'n 3 miljoen bestanden zou willen back-uppen, zou de back-up steeds mislukken. Bovendien vereist DPM/MABS extra onderhoud, wat we zoveel mogelijk wilden vermijden.

Azure Files Backup (preview)

We konden alle bestanden back-uppen door de Azure-fileshares (onze Azure File Sync cloud-eindpunten) te back-uppen. Zo zouden we gemakkelijk een of meerdere bestanden van een bepaalde dag kunnen herstellen. In de preview kun je echter slechts een keer per dag een geplande back-up aanmaken. Bovendien kun je de back-ups slechts maximaal 180 dagen bewaren, terwijl onze klant de data minstens tien jaar lang moet bewaren. Toch hebben we deze oplossing gebruikt omdat dit een erg eenvoudige methode is om data op korte termijn te herstellen.

Azure Virtual Machine Backup

Zoals we eerder vermeldden, ondersteunt Azure Virtual Machine Backup alleen VM's met schijven met een maximale grootte van 4 TB. Hiervoor hebben we aan het begin van het project al gezorgd, dus kunnen we nu probleemloos verder.

Azure VM Backup biedt alle functies die we nodig hebben. We kunnen de back-ups minstens tien jaar lang bewaren, elke dag een back-up maken en onze VM's en data eenvoudig herstellen zonder extra onderhoud. Er is slechts één aandachtspunt: als we eerder Cloud Tiering hadden gebruikt, zouden veel bestanden niet geback-upt zijn. Deze zouden immers alleen in Azure Files opgeslagen zijn en op de VM zelf zouden alleen pointers staan. Zoals gezegd moesten we daarom de Cloud Tiering-functie achterwege laten.

Toch zorgde Azure Virtual Machine Backup ervoor dat we een goede back-upoplossing konden ontwerpen die aan al onze behoeften voldoet.

Conclusie

We hebben een volledige file server-omgeving geïmplementeerd met AFS en DFS om een high-available omgeving te creëren. De infrastructuur is robuust, performant, gemakkelijk te onderhouden en herstellen, gemonitord en flexibel. Met de handige functies van Azure maken we van elk project een succes.

Wil je meer weten over onze Azure-oplossingen? Bekijk dan zeker onze website.

Deel dit blogbericht
Categorieën: Azure
Tags: Azure

Also interesting for you

Laat een antwoord achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd.

Breng jouw kennis en skills naar een hoger niveau

Schrijf nu in voor onze nieuwsbrief en krijg maandelijks:

  • Uitnodigingen voor Xylos' events & webinars
  • De laatste blogposts en cases
  • Nieuwste IT-trends