Beholdere har blitt stadig mer populære for utviklere som ønsker å distribuere applikasjoner i skyen. For å administrere disse nye applikasjonene har Kubernetes blitt en de facto standard for containerorkestrering. Kubernetes gjør det mulig for utviklere å bygge distribuerte applikasjoner som automatisk skaleres elastisk, avhengig av etterspørsel.
Kubernetes ble utviklet for enkelt å distribuere, skalere og administrere statsløse arbeidsbelastninger for applikasjoner i produksjonen. Når det gjelder stateful, cloud-native data, har det vært behov for samme lette distribusjon og skalering.
I distribuerte databaser appellerer Cassandra for utviklere som vet at de må skalere dataene sine - det gir en fullstendig feiltolerant tilnærming til databaser og datahåndtering som kan kjøre på samme måte på flere steder og skytjenester. Siden alle noder i Cassandra er like, og hver node er i stand til å håndtere lese- og skriveforespørsler, er det ikke noe feilpunkt i Cassandra-modellen. Data replikeres automatisk mellom feilsoner for å forhindre tap av en enkelt forekomst som påvirker applikasjonen.
Koble Cassandra til Kubernetes
Det logiske neste trinnet er å bruke Cassandra og Kubernetes sammen. Når alt kommer til alt, å få en distribuert database til å kjøre sammen med et distribuert applikasjonsmiljø, blir det lettere å ha data- og applikasjonsoperasjoner nær hverandre. Ikke bare unngår dette ventetid, det kan bidra til å forbedre ytelsen i skala.
For å oppnå dette betyr det imidlertid å forstå hvilket system som er ansvarlig. Cassandra har allerede den typen feiltoleranse og nodeplassering som Kubernetes kan levere, så det er viktig å vite hvilket system som har ansvaret for å ta beslutningene. Dette oppnås ved bruk av en Kubernetes-operatør.
Operatører automatiserer prosessen med å distribuere og administrere mer komplekse applikasjoner som krever domenespesifikk informasjon og trenger å samhandle med eksterne systemer. Inntil operatører ble utviklet, førte stateful applikasjonskomponenter som database forekomster til ekstra ansvar for devops team, da de måtte påta seg manuelt arbeid for å få sine forberedelser forberedt og kjøre på en statelig måte.
Det er flere operatører for Cassandra som er utviklet av Cassandra-samfunnet. For dette eksemplet bruker vi cass-operator, som ble satt sammen og åpen fra DataStax. Den støtter åpen kildekode Kubernetes, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) og Pivotal Container Service (PKS), slik at du kan bruke Kubernetes-tjenesten som passer best for ditt miljø.
Å installere en kassoperatør på din egen Kubernetes-klynge er en enkel prosess hvis du har grunnleggende kunnskap om å kjøre en Kubernetes-klynge. Når Kubernetes-klyngen din er autentisert, ved hjelp av kubectl, kommandolinjeverktøyet Kubernetes-klyngen og Kubernetes-skyforekomsten (enten Kubernetes, GKE, EKS eller PKS med åpen kildekode er koblet til din lokale maskin, kan du begynne å bruke operatørkonfigurasjon YAML-filer til klyngen.
Sette opp definisjoner for kassoperatører
Neste trinn er å bruke definisjonene for kassoperatørmanifestet, lagringsklassen og datasenteret til Kubernetes-klyngen.
Et raskt notat om datasenterdefinisjonen. Dette er basert på definisjonene som brukes i Cassandra i stedet for en referanse til et fysisk datasenter.
Hierarkiet for dette er som følger:
- En node refererer til et datasystem som kjører en forekomst av Cassandra. En node kan være en fysisk vert, en maskininstans i skyen eller til og med en Docker-container.
- Et stativ refererer til et sett med Cassandra-noder i nærheten av hverandre. Et rack kan være et fysisk rack som inneholder noder koblet til en felles nettverkssvitsj. I skyutplasseringer refererer imidlertid et rack ofte til en samling maskinforekomster som kjører i samme tilgjengelighetssone.
- Et datasenter refererer til en samling av logiske stativer, vanligvis bosatt i samme bygning og forbundet med et pålitelig nettverk. I skyutplasseringer tilordnes datasentre generelt til en skyregion.
- En klynge refererer til en samling datasentre som støtter den samme applikasjonen. Cassandra-klynger kan kjøre i et enkelt skymiljø eller fysisk datasenter, eller distribueres på flere steder for større elastisitet og redusert ventetid
Nå har vi bekreftet navnekonvensjonene våre, det er på tide å sette opp definisjoner. Eksemplet vårt bruker GKE, men prosessen er lik for andre Kubernetes-motorer. Det er tre trinn.
Trinn 1
Først må vi kjøre en kubectl-kommando som refererer til en YAML-konfigurasjonsfil. Dette gjelder kassoperatørmanifestets definisjoner for den tilkoblede Kubernetes-klyngen. Manifester er API-objektbeskrivelser, som beskriver objektets ønskede tilstand, i dette tilfellet din Cassandra-operatør. For et komplett sett med versjonsspesifikke manifest, se denne GitHub-siden.
Her er et eksempel på en kubectl-kommando for GKE-sky som kjører Kubernetes 1.16:
kubectl create -f //raw.githubusercontent.com/datastax/cass-operator/v1.3.0/docs/user/cass-operator-manifests-v1.16.yaml
Steg 2
Den neste kubectl-kommandoen bruker en YAML-konfigurasjon som definerer lagringsinnstillingene som skal brukes for Cassandra-noder i en klynge. Kubernetes bruker StorageClass-ressursen som et abstraksjonslag mellom pods som trenger vedvarende lagring og de fysiske lagringsressursene som en spesifikk Kubernetes-klynge kan gi. Eksemplet bruker SSD som lagringstype. For flere alternativer, se denne GitHub-siden. Her er den direkte lenken til YAML som brukes i lagringskonfigurasjonen nedenfor:
apiVersion: storage.k8s.io/v1type: StorageClass
metadata:
navn: serverlagring
forsørger: kubernetes.io/gce-pd
parametere:
type: pd-ssd
replikeringstype: ingen
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Slett
Trinn 3
Til slutt, ved å bruke kubectl igjen, bruker vi YAML som definerer Cassandra Datacenter.
# Størrelse for å jobbe på 3 k8s arbeidstakernoder med 1 kjerne / 4 GB RAM# Se naboeksempel-cassdc-full.yaml for dokumenter for hver parameter
apiVersion: cassandra.datastax.com/v1beta1
snill: CassandraDatacenter
metadata:
navn: dc1
spesifikasjon:
clusterName: cluster1
serverType: cassandra
serverVersjon: "3.11.6"
managementApiAuth:
usikker: {}
størrelse: 3
storageConfig:
cassandraDataVolumeClaimSpec:
storageClassName: server-storage
accessModes:
- ReadWriteOnce
ressurser:
forespørsler:
lagring: 5Gi
konfigurere:
cassandra-yaml:
autentisering: org.apache.cassandra.auth.PasswordAuthenticator
autorisator: org.apache.cassandra.auth.CassandraAuthorizer
role_manager: org.apache.cassandra.auth.CassandraRoleManager
jvm-alternativer:
initial_heap_size: "800M"
max_heap_size: "800M"
Dette eksemplet YAML er for et åpen kildekode Apache Cassandra 3.11.6-bilde, med tre noder på ett stativ, i Kubernetes-klyngen. Her er den direkte lenken. Det er et komplett sett med dataspesifikke datasenterkonfigurasjoner på denne GitHub-siden.
På dette tidspunktet vil du kunne se på ressursene du har opprettet. Disse vil være synlige i skykonsollen din. I Google Cloud Console kan du for eksempel klikke på Clusters-fanen for å se hva som kjører og se på arbeidsbelastningen. Dette er distribuerbare databehandlingsenheter som kan opprettes og administreres i Kubernetes-klyngen.
For å koble til en distribuert Cassandra-database, kan du bruke cqlsh, kommandolinjeskallet og spørre Cassandra ved hjelp av CQL fra Kubernetes-klyngen. Når du er godkjent, vil du kunne sende inn DDL-kommandoer for å opprette eller endre tabeller osv., Og manipulere data med DML-instruksjoner, for eksempel innsetting og oppdatering i CQL.
Hva er det neste for Cassandra og Kubernetes?
Mens det er flere operatører tilgjengelig for Apache Cassandra, har det vært behov for en felles operatør. Bedrifter som er involvert i Cassandra-samfunnet, som Sky, Orange, DataStax og Instaclustr, samarbeider om å etablere en felles operatør for Apache Cassandra på Kubernetes. Dette samarbeidet går sammen med de eksisterende open source-operatørene, og målet er å gi bedrifter og brukere en jevn skaleringsstabel for beregning og data.
Over tid må flyttingen til skyinnfødte applikasjoner også støttes med skyinnfødte data. Dette vil stole på mer automatisering, drevet av verktøy som Kubernetes. Ved å bruke Kubernetes og Cassandra sammen, kan du gjøre din tilnærming til data sky-native.
Hvis du vil lære mer om Cassandra og Kubernetes, kan du gå til //www.datastax.com/dev/kubernetes. For mer informasjon om å kjøre Cassandra i skyen, sjekk ut DataStax Astra.
Patrick McFadin er direktør for utviklerrelasjoner i DataStax, hvor han leder et team viet til å gjøre brukere av Apache Cassandra vellykkede. Han har også jobbet som sjefsevangelist for Apache Cassandra og konsulent for DataStax, hvor han bidro til å bygge noen av de største og spennende distribusjonene i produksjonen. Før DataStax var han sjefarkitekt hos Hobsons og Oracle DBA / utvikler i over 15 år.
—
New Tech Forum er et sted for å utforske og diskutere ny teknologi i enestående dybde og bredde. Valget er subjektivt, basert på vårt valg av teknologiene vi mener er viktige og av størst interesse for leserne. godtar ikke markedsføringssikkerhet for publisering og forbeholder seg retten til å redigere alt bidratt innhold. Send alle henvendelser til [email protected].
