Justin Rik
Encompass: een workload analyse methodologie
Toen Hyper-Converged werd geïntroduceerd in 2016, vroegen de meeste van ons zich af waar we deze revolutionaire nieuwe oplossing voor moesten gaan gebruiken. Het was duidelijk dat Hyper-Converged ongelofelijk veel waarde zou brengen voor iedere organisatie, groot of klein, maar welke workloads zijn nu geschikt voor Hyper-Converged? Het devies toentertijd was simpel: ‘80% van alle workloads die we aantreffen is geschikt voor Hyper-Converged, de resterende 20% moet naar een standaard infrastructuur’. Veel gehoord was ook: ‘grote databases zijn minder geschikt voor Hyper-Converged’. Gelukkig hebben we nu een manier gevonden om op basis van data de juiste beslissing te maken.
Voordat ik begin over wat Encompass doet, is het zaak om duidelijk te maken hoe Hyper-Converged verschilt van een traditionele infrastructuur. Een traditionele infrastructuur – ook bekend als 3-tier – bestaat uit compute (servers), networking (FC of IP) en natuurlijk storage. Vroeger werd de mainframe voorzien van storage door middel van SLED’s (Single Large Expensive Discs). Dit waren ongelooflijk betrouwbare discs, en niet zonder reden: er was geen redundantie. De SLED’s werden direct gekoppeld aan de mainframe server, zonder enige bescherming of hot spares. Er gingen rond de jaren 90 stemmen op om gebruik te gaan maken van een centrale vorm van opslag in de vorm van een storage array. Storage arrays maakten gebruik van relatief goedkope discs die beschermd werden door middel van RAID, waardoor de data beschermt blijft. Het ontwerp is niet drastisch veranderd, maar de onderliggende componenten wel.
Hyper-Converged gaat eigenlijk weer terug naar de “oude” mainframe tijd, door gebruik te maken van servers met rechtstreeks gekoppelde discs. Echter, Hyper-Converged maakt gebruik van ‘Software Defined Storage’ (SDS). SDS groepeert de discs van meerdere server nodes en presenteert deze als een logische entiteit. Dankzij SDS kunnen we een groep standaard x86 servers zich laten gedragen als een storage array, met de functionaliteit die u van een array mag verwachten: data protectie en dataservices (snapshots, replicatie, data-reductie, encryptie, etc.). De discs van de servers worden aangeboden aan de SDS laag, die hier op zijn beurt een pool of datastore van maakt. U kiest hoe u uw data wilt beschermen – of niet – door middel van mirroring of door middel van parity gebaseerde bescherming zoals Erasure Coding. De SDS laag is gebaseerd op policies, dat betekent dat de SDS laag er voor zorgt dat uw data altijd beschermd is en blijft. Dit maakt deze manier van het managen van storage vele malen efficiënter, bovendien is het een veel schaalbaardere oplossing.
Nu u het verschil tussen Hyper-Converged en een traditionele omgeving kent, kunnen we ons richten op de werking van Encompass. Encompass maakt gebruik van de volgende data bronnen: Liveoptics, RV data of TAM data. Encompass kijkt naar een VMware landschap van een organisatie en gaat de VM’s (virtuele machines die de workload draaien) classificeren in twee verschillende categorieën: ‘Standard’ en ‘Outlier’. We maken hierbij gebruik van een auto-industrie analogie die ‘Robots and Welders’ heet. De Robots worden gebruikt om de massa-geproduceerde auto te maken die we allemaal kennen. De Robots zijn eenvoudig op te schalen en zijn zeer geschikt voor automatisering. De Welders worden gebruikt voor de unieke auto’s, denk aan de Ferrari’s en Lamborghini’s. De laatstgenoemde zijn om meerdere redenen niet geschikt voor massaproductie. We zien hetzelfde in het applicatielandschap. De Robots (Standard) consumeren – over het algemeen – niet buitensporig veel resources, komen niet in heel veel verschillende configuraties voor, en zijn veelal erg geschikt voor automatisering (net als Hyper-Converged). De Welders (Outlier) zijn workloads die buitenproportioneel veel resources consumeren, veelal – maar niet exclusief – qua storagebehoefte. Encompass zoekt die workloads met buitensporige hoeveelheden vCPU, vMemory of storage. Onderzoek toont aan dat, ondanks dat de Outliers vaak maar 10% van de totale workloads vertegenwoordigt, ze verantwoordelijk kunnen zijn voor 75% van de totale storagebehoefte!
Waarom is dit zo relevant? Kan ik er niet voor kiezen om alsnog deze resource consumerende workloads op Hyper-Converged te plaatsen? Absoluut, maar dit is niet altijd het meest efficiënt. Hyper-Converged biedt u een oplossing waarbij u uw compute en storage tegelijkertijd beheert, en idealiter is er een balans tussen beide. Wanneer u bijvoorbeeld workloads heeft met veel storagebehoefte, dan wordt u gedwongen om extra nodes aan te schaffen om te voorzien in deze behoefte. Dat betekent extra kosten vanwege de nodes, maar ook vanwege de benodigde licenties.
Een tweede reden – en mijns inziens nog belangrijker – heeft te maken met dataservices. Er zijn veel vormen van replicatie beschikbaar voor Hyper-Converged: Vsphere replication, Recoverpoint 4 VM’s, etc. Deze oplossingen draaien samen met de VM’s op hetzelfde platform. Dat betekent dat ze mogelijk gaan concurreren om resources. In het geval van de Outlier workloads (die veelal veel performance nodig hebben) is het wijs om dit over te laten aan een storage array die daarvoor ontwikkeld is.
Naast het in kaart brengen welke workloads wat consumeren, laat Encompass ook zien hoeveel verschillende soorten Operating Systems er in gebruik zijn. Dit toont aan of een organisatie aan eventuele kwetsbaarheden is blootgesteld, en hoe we dit samen kunnen verminderen of verhelpen. Encompass laat zien hoeveel verschillende configuraties er aangetroffen zijn (qua resource allocatie). Dit is een leuk startpunt om na te denken over het toepassen van verschillende T-shirt sizes waar de business uit kan kiezen, om op die manier de efficiëntie te verhogen. Ook wordt zichtbaar hoeveel clusters er zijn, en of er bepaalde clusters zijn die gemixte Operating Systems huisvesten. Dit zorgt in de meeste gevallen namelijk voor extra licentiekosten.
Waarschijnlijk vraagt u zich af waarom ik het een methodologie noem, terwijl het meer op een tool lijkt. Een tool is alleen maar nuttig in de juiste handen. Er komt nog meer bij kijken dan alleen maar vaststellen wat een workload consumeert. Overige zaken die moeten worden nagekeken zijn:
- Wat zijn de performance eisen voor een applicatie?
- Wat zijn de RPO/RTO eisen (hoeveel dataverlies is acceptabel en hoe lang kan de business platliggen?);
- Zijn er workloads die u in een public cloud zou willen draaien?
Het huidige IT-landschap is nagenoeg onmogelijk te navigeren zonder het juiste kompas. Wij hebben dat kompas en willen hem graag met u delen! Neem contact op met uw accountmanager of met mij. Wij kunnen niet wachten om u hiermee verder te helpen.
Justin Rik
Account Systems Engineer