Dutch, Objects, Technology

Nutanix Objects Deel 2

In mijn vorige blog heb ik beschreven wat Object storage is en waarvoor je dit kunt gebruiken.

In een hele korte samenvatting: Object storage wordt het meest gebruikt in drie gebieden, Dev/ops omgevingen door gebruik te maken van REST API, in Big Data omgevingen voor opslaan van objecten met doorzoekbare metadata. En voor archivering waarbij versie control en Write Once Read Many technolgieen belangrijk zijn. Een voorbeeld van archivering is “Splunk Smart Store”. Nutanix Objects is hiervoor gecertificeerd, en kan dus de “cold” en “frozen” data van Splunk opslaan. Hiermee kan een enorme kosten besparing worden gerealiseerd voor de storage binnen Splunk. Meer weten hierover geef mij een mail www.linkedin.com/in/ricardovanvelzen.

Andere delen van deze blog vind je hier:

In dit deel ga ik in op de Nutanix Object Storage technologie zelf, hoe Nutanix Objects is opgebouwd.

De opbouw:

De belangrijkste onderdelen van Nutanix Objects zijn als volgt in te delen:

De “density” blijft natuurlijk niet bij die ene petabyte, je kunt veel meer nodes in een cluster plaatsten. Met versie 2.0 van Nutanix Objects kun je meerdere clusters in een “namespace” plaatsen. Binnen de architectuur van Objects is geen maximum gedefinieerd, je kunt de oplossing oneindig doorschalen.

De architectuur:

Zoals het bovenstaande figuur laat zien, is Nutanix Objects volledig onderdeel van het Nutanix cluster. Het management van de Object Store doe je dus door gebruik te maken van hetzelfde management platform als waarmee je de rest van het Nutanix cluster ook managed, PRISM. Geen nieuwe leer curve dus. Het tweede wat opvalt is dat de Objects services als containers draaien in een Kubernetes cluster binnen het Nutanix Cloud platform. Dit Kubernetes cluster hoef je niet zelf te beheren. Mocht je een eigen Kubernetes cluster nodig hebben, dan is dit beschikbaar onder de naam “Karbon”. Dit is een volledige Kubernetes implemenatie, maar dan zonder de complexiteit die een normale Kubernetes omgeving met zich meebrengt, de Nutanix cloud platform ontzorgt je ook hierin volledig. Maar even terug naar Objects. Nutanix heeft ervoor gekozen om Objects als een container service op te bouwen vanwege het feit dat dit veel flexibiliteit geeft in bijvoorbeeld schaalbaarheid, maar daarover straks meer. Voor de uiteindelijke storage afhandeling maakt Nutanix Objects natuurlijk gebruik van de distributed storage service techniek die al in het Nutanix cluster aanwezig is, met voordelen van dien. Zo maakt Objects optimaal gebruik van Erasure coding, compressie en de-duplicatie technieken die al standaard aanwezig zijn binnen een Nutanix oplossing.

Kijken we wat dieper naar de architectuur dan kunnen we dit schematisch weergeven zoals in onderstaand schema.

De S3 Adapter, Object Controller, Metadata Service en Load Balancers zijn de onderdelen van Nutanix Objects en draaien elk in hun eigen container. Stargate is de Nutanix OS service die al het I/O verkeer regelt voor het Nutanix cluster. De http of https PUT en GET opdrachten worden via de load balancers naar de verschillende S3 adapters geleid. Door het “Identity Access Management” (IAM) wordt gekeken wie bij welke “store” en “bucket” mag. De Object controller raadpleegt de metadata en haalt via “stargate” de juiste data op, of zet het juist weg.

Er worden minimaal twee Kubernetes workers geinstalleerd waar alle services in draaien. Mocht er meer noodzakelijk zijn worden er meer workers, elk op een nutanix node, opgestart. Daarmee worden er ook meer S3 adapters, Object Controllers en Metadata Services in gebruik genomen. Maar ook binnen de workers zelf kan er opgeschaald worden. De S3 adapter bijvoorbeeld kan onafhankelijk van de andere services opschalen wanneer dit noodzakelijk is, zo ook met de andere services zoals de Object Controllers. Dit geeft uitermate flexibiliteit en schaalbaarheid tot meerdere petabytes en miljarden objecten per Object cluster, zonder dat je als gebruiker hiervoor iets hoeft te doen. Het systeem regelt dit allemaal zelf.

Mocht er meer storage capaciteit nodig zijn dan kan er een tweede Nutanix cluster aan de Object store worden gekoppeld. Dit tweede cluster hoeft in tegenstelling tot het “hoofd” cluster geen AHV hypervisor te hebben maar kan een Nutanix cluster zijn op basis van bijvoorbeeld ESXi. Je kan dan per cluster opgeven hoeveel maximaal storage van deze extra cluster je beschikbaar wilt hebben binnen je Object Store. De extra storage capaciteit valt onder dezelfde storage “name-space”. Nutanix Objects kan dus over meerdere clusters heen werken.

Hiermee heb ik de architectuur van Nutanix Objects beschreven. Zoals je kan lezen voldoet Objects aan de verschillende Object strorage eisen zoals ik die in deel 1 al beschreven had.

  • Schaalbaar tot meerdere petabytes, over verschillende Nutanix clusters heen
  • Onderliggende structuur maakt gebruik van micro service platform (container architectuur). Dit maakt het flexibel, schaalbaar, redudant en performant
  • Ondersteuning van WORM, Versioning, IAM, encryptie voor veilig een certificeerd opslaan van data

In mijn volgende deel ga ik uitleggen hoe je Nutanix Objects installeert