Ohjelmointi

Kuinka ajaa Cassandra ja Kubernetes yhdessä

Säiliöistä on tullut yhä suositumpia kehittäjille, jotka haluavat ottaa sovelluksia käyttöön pilvessä. Näiden uusien sovellusten hallitsemiseksi Kuberneteksestä on tullut de facto standardi konttien orkestroinnille. Kubernetes antaa kehittäjille mahdollisuuden rakentaa hajautettuja sovelluksia, jotka skaalautuvat automaattisesti joustavasti kysynnän mukaan.

Kubernetes on kehitetty levittämään, skaalattamaan ja hallitsemaan tuotannon valtiottomien sovellusten kuormituksia vaivattomasti. Kun on kyse tilallisesta, pilvipohjaisesta tiedosta, on tarvittu sama helppokäyttöisyys ja skaalaus.

Hajautetuissa tietokannoissa Cassandra vetoaa kehittäjille, jotka tietävät, että heidän on laajennettava tietojaan - se tarjoaa täysin vikasietoisen tietokannan ja tiedonhallinnan lähestymistavan, joka voi toimia samalla tavalla useissa paikoissa ja pilvipalveluissa. Koska kaikki Cassandran solmut ovat samanarvoisia ja kukin solmu pystyy käsittelemään luku- ja kirjoituspyyntöjä, Cassandra-mallissa ei ole yhtä vikaantumispistettä. Tiedot replikoidaan automaattisesti vikavyöhykkeiden välillä estääkseen yhden sovellukseen vaikuttavan ilmentymän häviämisen.

Yhdistetään Cassandra Kubernetesiin

Looginen seuraava askel on käyttää Cassandraa ja Kubernetesia yhdessä. Loppujen lopuksi hajautetun tietokannan saaminen toimimaan yhdessä hajautetun sovellusympäristön kanssa helpottaa tietojen ja sovellustoimintojen suorittamista lähellä toisiaan. Paitsi että näin vältetään viive, se voi auttaa parantamaan suorituskykyä mittakaavassa.

Tämän saavuttaminen tarkoittaa kuitenkin ymmärrystä siitä, mikä järjestelmä on vastuussa. Cassandralla on jo sellainen vikasietoisuus ja solmujen sijoittelu, jonka Kubernetes pystyy tarjoamaan, joten on tärkeää tietää, mikä järjestelmä on vastuussa päätösten tekemisestä. Tämä saavutetaan käyttämällä Kubernetes-operaattoria.

Operaattorit automatisoivat monimutkaisempien sovellusten käyttöönoton ja hallinnan, jotka vaativat toimialakohtaista tietoa ja joiden on oltava vuorovaikutuksessa ulkoisten järjestelmien kanssa. Siihen saakka, kun operaattoreita kehitettiin, tilalliset sovelluskomponentit, kuten tietokantatapaukset, johtivat ylimääräisiin vastuisiin devops-tiimeille, koska heidän täytyi suorittaa manuaalista työtä saadakseen instanssejaan valmistelemaan ja suorittamaan tilannekohtaisella tavalla.

Cassandralle on kehitetty useita operaattoreita, jotka Cassandra-yhteisö on kehittänyt. Tässä esimerkissä käytämme kassioperaattoria, jonka DataStax on koonnut ja hankkinut. Se tukee avoimen lähdekoodin Kubernetesia, Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) ja Pivotal Container Service (PKS), joten voit käyttää Kubernetes-palvelua, joka sopii parhaiten ympäristöön.

Kassioperaattorin asentaminen omaan Kubernetes-klusteriin on yksinkertainen prosessi, jos sinulla on perustiedot Kubernetes-klusterin ajamisesta. Kun Kubernetes-klusterisi on todennettu käyttämällä kubectl-sovellusta, Kubernetes-klusterin komentorivityökalua ja Kubernetes-pilvi-ilmentymä (olipa kyseessä avoimen lähdekoodin Kubernetes, GKE, EKS tai PKS), on kytketty paikalliseen koneeseesi, voit alkaa käyttää operaattorin määritykset YAML-tiedostot klusterille.

Kassioperaattorimääritysten määrittäminen

Seuraava vaihe on kassioperaattoriluettelon, tallennusluokan ja datakeskuksen määritelmien soveltaminen Kubernetes-klusteriin.

Pika huomautus palvelinkeskuksen määritelmästä. Tämä perustuu Cassandrassa käytettyihin määritelmiin eikä viittaukseen fyysiseen datakeskukseen.

Tämän hierarkia on seuraava:

  • Solmu viittaa tietokonejärjestelmään, joka käyttää Cassandran esiintymää. Solmu voi olla fyysinen isäntä, koneesimerkki pilvessä tai jopa Docker-säilö.
  • Telineellä tarkoitetaan joukkoa Cassandra-solmuja lähellä toisiaan. Teline voi olla fyysinen teline, joka sisältää solmut, jotka on kytketty yhteiseen verkkokytkimeen. Pilviasennuksissa teline viittaa kuitenkin usein kokoelmaan koneen esiintymiä, jotka toimivat samalla käytettävyysalueella.
  • Datakeskus viittaa loogisten telineiden kokoelmaan, jotka yleensä asuvat samassa rakennuksessa ja yhdistetty luotettavalla verkolla. Pilviasennuksissa datakeskukset kartoittavat yleensä pilvi-alueen.
  • Klusteri viittaa kokoelmaan tietokeskuksia, jotka tukevat samaa sovellusta. Cassandra-klusterit voivat toimia yhdessä pilviympäristössä tai fyysisessä datakeskuksessa, tai ne voidaan jakaa useisiin paikkoihin paremman joustavuuden ja pienemmän viiveen vuoksi

Nyt olemme vahvistaneet nimeämiskäytäntömme, on aika määrittää määritelmät. Esimerkissämme käytetään GKE: tä, mutta prosessi on samanlainen muilla Kubernetes-moottoreilla. Vaiheita on kolme.

Vaihe 1

Ensinnäkin meidän on suoritettava kubectl-komento, joka viittaa YAML-määritystiedostoon. Tämä koskee kassioperaattoriluettelon määritelmiä yhdistettyyn Kubernetes-klusteriin. Manifestit ovat API-objektien kuvauksia, jotka kuvaavat kohteen, tässä tapauksessa Cassandra-operaattorisi, toivotun tilan. Täydelliset versiokohtaiset luettelot löydät tältä GitHub-sivulta.

Tässä on esimerkki kubectl-komennosta GKE-pilvelle, joka käyttää Kubernetes 1.16:

kubectl create -f //raw.githubusercontent.com/datastax/cass-operator/v1.3.0/docs/user/cass-operator-manifests-v1.16.yaml

Vaihe 2

Seuraava kubectl-komento käyttää YAML-kokoonpanoa, joka määrittelee klusterin Cassandra-solmuille käytettävät tallennusasetukset. Kubernetes käyttää StorageClass-resurssia abstraktiokerroksena pysyvää tallennustilaa tarvitsevien palkkien ja fyysisten tallennusresurssien välillä, jotka tietty Kubernetes-klusteri voi tarjota. Esimerkki käyttää SSD: tä tallennustyypinä. Lisää vaihtoehtoja on tällä GitHub-sivulla. Tässä on suora linkki YAML: ään, jota käytetään tallennuskokoonpanossa, alla:

apiVersion: storage.k8s.io/v1

laji: StorageClass

metatiedot:

nimi: palvelintallennus

toimittaja: kubernetes.io/gce-pd

parametrit:

tyyppi: pd-ssd

replikaatiotyyppi: ei mitään

volumeBindingMode: WaitForFirstConsumer

reclaimPolicy: Poista

Vaihe 3

Lopuksi käyttämällä kubectl-sovellusta uudelleen, käytämme YAML: ää, joka määrittelee Cassandra Datacenterin.

# Mitoitettu toimimaan 3 k8s: n työntekijäsolmuilla, joissa on 1 ydin / 4 Gt RAM-muistia

# Katso viereisestä esimerkistä cassdc-full.yaml kunkin parametrin dokumentit

apiVersion: cassandra.datastax.com/v1beta1

laji: CassandraDatacenter

metatiedot:

nimi: dc1

tekniset tiedot:

clusterName: klusteri1

serverType: cassandra

serverVersion: "3.11.6"

managementApiAuth:

epävarma: {}

koko: 3

storageConfig:

cassandraDataVolumeClaimSpec:

storageClassName: palvelintila

accessModes:

- ReadWriteOnce

resurssit:

pyynnöt:

varastointi: 5Gi

config:

cassandra-yaml:

todentaja: org.apache.cassandra.auth.PasswordAuthenticator

valtuuttaja: org.apache.cassandra.auth.CassandraAuthorizer

roolinhallinta: org.apache.cassandra.auth.CassandraRoleManager

jvm-vaihtoehdot:

initial_heap_size: "800 miljoonaa"

max_heap_size: "800 M"

Tämä esimerkki YAML on avoimen lähdekoodin Apache Cassandra 3.11.6 -kuvalle, jossa on kolme solmua yhdessä telineessä Kubernetes-klusterissa. Tässä on suora linkki. Tällä GitHub-sivulla on täydellinen joukko tietokantakohtaisia ​​datakeskuksen määrityksiä.

Tässä vaiheessa voit tarkastella luomiasi resursseja. Nämä näkyvät pilvikonsolissasi. Esimerkiksi Google Cloud Consolessa voit napsauttaa Klusterit-välilehteä nähdäksesi, mikä on käynnissä, ja tarkastella työmääriä. Nämä ovat käyttöönotettavia laskentayksiköitä, jotka voidaan luoda ja hallita Kubernetes-klusterissa.

Jos haluat muodostaa yhteyden itse käyttöönotettuun Cassandra-tietokantaan, voit käyttää cqlsh-komentoa, komentorivin kuorta ja kysellä Cassandraa Cernetin avulla Kubernetes-klusteristasi. Todentamisen jälkeen voit lähettää DDL-komentoja taulukoiden jne. Luomiseksi tai muuttamiseksi ja tietojen manipuloimiseksi DML-ohjeilla, kuten lisätä ja päivittää CQL: ssä.

Mitä seuraavaksi Cassandra ja Kubernetes?

Vaikka Apache Cassandralle on saatavana useita operaattoreita, on tarvittu yhteistä operaattoria. Cassandra-yhteisöön osallistuvat yritykset, kuten Sky, Orange, DataStax ja Instaclustr, tekevät yhteistyötä luodakseen yhteisen operaattorin Apache Cassandralle Kubernetesiin. Tämä yhteistyö kulkee nykyisten avoimen lähdekoodin operaattoreiden rinnalla, ja tavoitteena on tarjota yrityksille ja käyttäjille yhtenäinen skaalauspino laskentaan ja tietoihin.

Ajan myötä siirtyminen pilvipohjaisiin sovelluksiin on tuettava myös pilvipalvelukohtaisilla tiedoilla. Tämä edellyttää enemmän automatisointia, jota ohjaavat Kubernetesin kaltaiset työkalut. Käyttämällä Kubernetesia ja Cassandraa yhdessä, voit tehdä lähestymistavastasi datapilvi-natiivin.

Lisätietoja Cassandrasta ja Kubernetesista on osoitteessa //www.datastax.com/dev/kubernetes. Lisätietoja Cassandran suorittamisesta pilvipalvelussa on DataStax Astrassa.

Patrick McFadin on kehittäjäsuhteiden varapuheenjohtaja DataStaxissa, jossa hän johtaa tiimiä, joka on sitoutunut tekemään Apache Cassandran käyttäjistä menestyviä. Hän on myös työskennellyt Apache Cassandran pääevankelistina ja DataStaxin konsulttina, missä hän auttoi rakentamaan suurimpia ja mielenkiintoisimpia tuotantotapoja. Ennen DataStaxia hän oli Hobsonsin pääarkkitehti ja Oracle DBA / -kehittäjä yli 15 vuoden ajan.

New Tech Forum tarjoaa mahdollisuuden tutkia ja keskustella kehittyvistä yritysteknologioista ennennäkemättömällä syvyydellä ja laajuudella. Valinta on subjektiivinen, perustuu valitsemiemme tekniikoihin, joiden uskomme olevan tärkeitä ja kiinnostavia lukijoille. ei hyväksy markkinointivakuuksia julkaisua varten ja pidättää oikeuden muokata kaikkea lähetettyä sisältöä. Lähetä kaikki tiedustelut osoitteeseen [email protected].

$config[zx-auto] not found$config[zx-overlay] not found