Microsoft Ignite ’19: ‘Hold my beer’ terwijl ik NFS workloads naar Azure migreer

Microsoft Ignite 2019 verslag dag 3 Erwin
Microsoft Ignite 2019 verslag dag 3 Erwin
Home / Blog & Nieuws / Cloud / Microsoft Ignite ’19: ‘Hold my beer’ terwijl ik NFS workloads naar Azure migreer

Trueligans Erwin (VP Solutions) en Rudy (Solutions Architect) zijn in het zonnige Florida aanwezig bij Microsoft Ignite: hét jaarlijkse techcongres van Microsoft waar nieuwe technologieën op het vlak van Azure, containers, development en meer voor het eerst gepresenteerd worden.

Bekijk onze Managed Azure dienst

NFS workloads migreren naar Azure Blob Storage

Meer en meer applicaties worden verplaatst naar Azure. Ook applicaties die gebruikmaken van NAS-functionaliteiten zoals NFS (Network File System).

Om meerdere redenen is het geregeld noodzakelijk deze toch wel oude, maar wel bewezen, technieken te blijven gebruiken in Azure.

Vanuit applicaties gebruikmaken van bestanden kan tegenwoordig veel schaalbaarder en sneller met oplossingen als Object Storage. In de praktijk blijkt het vaak lastig om applicaties aan te passen om hier gebruik van te maken.

Idealiter vindt er dus een refactoring van de applicaties plaats zodat de diensten van Azure ingezet kunnen worden en het niet een lift & shift gaat worden.

Toch is zo nu en dan een lift & shift noodzakelijk omdat een applicatielandschap heel veel bewegende delen heeft. Een migratie is vaak op zichzelf al een complexe operatie. Daarbij is het gelijktijdig vervangen of veranderen van een aantal onderdelen een risico.

Azure heeft daar diverse oplossingen voor, waarbij de keuze voor de beste oplossing gemaakt kan worden op basis van de type workload.

Een overzicht van de NFS-storagemogelijkheden binnen Azure

1. NFS op Block Blops

Deze dienst is nog niet live, maar is in ontwikkeling en is binnenkort beschikbaar.

NFS op Block Blops is het goedkoopst van alle oplossingen, maar ook het minst snel. Vooral geschikt voor lezen, maar dan niet enorm snel. Schrijven op deze oplossing is erg traag, maar eigenlijk ook onwenselijk en niet altijd mogelijk. Deze oplossing werkt vooralsnog enkel met NFS v3.

2. NFS op Azure Files

Met een redelijke doorvoer en latency is NFS op Azure Files in veel gevallen prima oplossing. Het is nog niet beschikbaar, begin volgend jaar wel. Men is bezig om ook CIFS te gaan ondersteunen. Wanneer CIFS beschikbaar wordt is nog niet bekend. Deze oplossing ondersteund enkel NFS v4.1.

3. NFS op Azure NetApp Files

NetApp Hardware in de Azure datacenters. In de datacenters van True hebben we heel wat NetApp filers staan in diverse setups. Zie ook mijn vorige blogpost.

We weten heel goed dat deze filers echt enorm snel zijn en ook Microsoft geeft aan dat deze dienst de snelste oplossing is voor NFS.

De toegangstijden zijn het beste en de doorvoer per thread is enorm hoog. Er zijn hierbij verschillende snelheidsopties beschikbaar. Van snel tot enorm snel. Deze oplossing bied zowel NFS v3 als v4.1.

4. NFS via HPC Cache

Het komt er op neer dat HPC Cache eigenlijk vooral voor hele zware lees-workloads geschikt is. Deze dienst is geschikt voor vele honderden tot duizenden VM’s die ontzettend veel data moeten lezen, voornamelijk grote bestanden. Deze cache kan gelijktijdig gebruikmaken van bestaande on-premisses NFS-oplossingen en ook Azure-Blob.

De cache kan je heel dichtbij de VM’s plaatsen die ermee moeten werken, waardoor de latency heel laag is en de performance heel goed. Maar nogmaals, enkel voor lezen.

Het is zelfs mogelijk om op een on-premisses omgeving aan de andere kant van de wereld NFS beschikbaar te hebben wat enorm snel gemaakt kan worden door een HPC Cache dichtbij bij de VM’s.

Een hele specifieke situatie wanneer deze oplossing gebruikt zal gaan worden. Enkel NFS v3 is ondersteund.

Kortom: heel veel opties om NFS-workloads naar Azure te migreren.

NFS workloads migreren naar Azure via HPC cache
Schematische weergave om NFS-workloads te migreren naar Azure via HPC cache.

Houd m’n bier eens vast

Microsoft Ignite '19 hold my beer

Alleen al om de titel van de sessie moest je erbij zijn: “Hold my beer while I optimize your Azure”.

Binnen 30 seconden werd al veel duidelijk over de spreker: energiek, enthousiast, humoristisch, uit Duitsland en hij lust geen bier.

Waar veel organisaties tegenaan lopen is het niet efficiënt gebruiken van clouddiensten. Achter de streep kost het altijd geld en er kan dus bespaard worden. Ik zet de belangrijkste punten uit zijn sessie op een rij.

1. Right sizing

Bij de initiële inrichting is bepaald hoe groot een VM moet zijn en daarna blijven we er vanaf. In de tijd van fysieke servers was dat heel normaal. De server blijft namelijk een paar jaar staan waardoor we er ons niet druk over hoeven te maken.

Juist het geregeld bekijken van de belasting is heel belangrijk bij VM’s. Als een VM door applicatieoptimalisaties veel sneller is geworden en dus minder resources verbruikt kan het zijn dat er flink bespaard kan worden door de VM te downsizen.

Deze controle-slagen moeten geregeld gedaan worden om te kunnen besparen.

2. Automatiseren

Een aantal servers hoeven niet 24×7 aan te staan. Schakel ze automatisch uit na een bepaald tijdstip. VM’s voor developers kunnen wellicht zelfs helemaal verwijderd worden om ze de dag er na weer vers aan te maken.

3. Azure Advisor

We ruimen nooit goed op. We spelen er mee, we verwijderen iets, maar nooit alles. Omdat het in de cloud zo makkelijk is even ergens mee te testen blijft er veel achter, is vaak de praktijk.

Van VM’s, storage-accounts tot SQL instances. We laten het allemaal achter.

De Azure Advisor helpt om ongebruikte resources boven water te krijgen. Met tags is het mogelijk inzichtelijk te krijgen wat het doel is. Op basis van tags is het opruimen een stuk makkelijker. Op vrijwel alle diensten van Azure zijn tags toe te voegen.

Taggen met Azure Advisor

 

1-op-1’s

Ook vandaag had ik (volledig ongepland overigens), een 1-op-1 met program een product manager van Microsoft.

Juist het teruggeven van informatie aan deze mensen is belangrijk voor de ontwikkeling van de producten en diensten van Microsoft. Vaak geven ze dan wat meer achtergrond van waar ze mee bezig zijn en waarom ze bepaalde zaken juist wel of niet gaan ontwikkelen.

Een samenvatting van wat ik besproken heb en wat ik daarvan alvast mag delen:

True en Azure Stack HCI

Bij True zijn we bezig met nieuwe ontwikkelingen zoals Azure Stack HCI, Azure, True Managed Kubernetes op Linux Hosts en vooral de hybride oplossingen hiermee.

Samen met de aankondigingen en diverse sessies die we bijgewoond hebben is te zien dat Microsoft echt hele mooie dingen beschikbaar maakt en nog gaat maken. Uitdagingen waar we langer mee zaten worden hiermee opgelost. Denk aan Azure Arc (zie ook Rudy’s blogpost), nieuwe netwerkadapters om Hyper-V (Azure Stack HCI) te koppelen aan Azure en ontwikkelingen rondom Kubernetes.

Kubernetes en Azure Stack HCI

Microsoft gaat Azure Stack HCI certificeren voor Kubernetes workloads. Microsoft gaat de integraties met Kubernetes in Azure en Azure Stack HCI verder doorontwikkelen. Goede integratie met onder andere Kubernetes, Rancher en Openshift voor Azure Stack HCI is men druk mee bezig.

De hybride oplossing voor Kubernetes in combinatie met bijvoorbeeld Rancher en de netwerkadapters om Azure Stack HCI met Azure te koppelen heb ik aangehaald. Nu zijn dit nog losse onderdelen welke samen enorm krachtig kunnen zijn.

Het lift & shift mogelijk maken van VM’s naar Kubernetes is een belangrijk onderdeel van de visie hieromheen.

Azure Stack HCI onderhoud

Azure Stack HCI is in de basis heel erg stabiel. Een grote uitdaging bij clusters met grote datasets is het patchmanagement. Niet de patching zelf, dat gaat erg eenvoudig, maar de tijd dat het tezamen kost met de noodzakelijke reboots.

Als tijdens het updaten en herstarten een klein blokje data wijzigt zal 256MB aan data opnieuw gesynchroniseerd moeten worden. Gedurende het onderhoud kunnen honderden tot duizenden van deze kleine blokjes gewijzigd kunnen worden met een hersynchronisatie van Gigabytes tot Terabytes tot gevolg. Dit kan uren tot dagen duren afhankelijk van de grootte van de dataset.

Gelukkig werd aangegeven dat men zich bewust is dat dit problematisch kan zijn en dat ze zitten te broeden op een oplossing.

Windows Server V-next, de volgende versie van Windows Server, heeft een aantal interessante nieuwe features, maar vooral verbeteringen. Het wachten op deze verbeteringen is voor bepaalde onderdelen ondoenlijk en lijkt het daarom noodzakelijk dat dit al in Windows Server 2019 uitgebracht moet gaan worden.

Tot zover de tweede dag. Op naar dag 3!

Ben je benieuwd naar de rest van de avonturen van Erwin en Rudy? Volg dan onze Microsoft Ignite berichten en houd onze social media kanalen in de gaten. Mocht je een keer willen sparren met Erwin over Azure en de nieuwe ontwikkelingen, neem dan contact op met True Webspace.

True Ligan
Managed hosting sinds 2000