Beheerbewerkingen in Azure Managed Instance voor Apache Cassandra

  • Artikel

Azure Managed Instance voor Apache Cassandra is een volledig beheerde service voor pure opensource Apache Cassandra-clusters. Met de service kunnen configuraties ook worden overschreven, afhankelijk van de specifieke behoeften van elke workload, waardoor de maximale flexibiliteit en controle waar nodig mogelijk zijn. In dit artikel worden de beheerbewerkingen en -functies van de service gedefinieerd. Ook wordt de scheiding van verantwoordelijkheden tussen het ondersteuning voor Azure team en klanten uitgelegd bij het onderhouden van hybride clusters.

Compressie

  • Er zijn verschillende soorten compressie. We voeren momenteel een kleine compressie uit via reparatie (zie Onderhoud). Hiermee wordt een Merkle boomcompressie uitgevoerd, wat een speciaal soort compressie is.
  • Afhankelijk van de compressiestrategie die in de tabel is ingesteld met behulp van CQL (bijvoorbeeld WITH compaction = { 'class' : 'LeveledCompactionStrategy' }), wordt Cassandra automatisch gecomprimeerd wanneer de tabel een specifieke grootte bereikt. U wordt aangeraden zorgvuldig een compressiestrategie voor uw workload te selecteren en geen handmatige compressies buiten de strategie uit te voeren.

Patchen

  • Patches op besturingssysteemniveau worden automatisch uitgevoerd met een frequentie van ongeveer 2 weken.

  • Patches op softwareniveau van Apache Cassandra worden uitgevoerd wanneer beveiligingsproblemen worden geïdentificeerd. Het patchfrequentie kan variëren.

  • Tijdens het patchen worden machines één rek tegelijk opnieuw opgestart. U mag geen afname aan de toepassingszijde ervaren zolang quorum ALL-instelling niet wordt gebruikt en de replicatiefactor 3 of hoger is.

  • De versie in Apache Cassandra heeft de indeling X.Y.Z. U kunt de implementatie van primaire (X) en secundaire (Y) versies handmatig beheren via servicehulpprogramma's. Terwijl de Cassandra-patches (Z) die mogelijk vereist zijn voor die combinatie van primaire/secundaire versies automatisch worden uitgevoerd.

Notitie

De service ondersteunt momenteel Cassandra-versies 3.11 en 4.0. Beide versies zijn GA. Zie onze Azure CLI-quickstart (stap 5) voor het opgeven van de Cassandra-versie tijdens de clusterimplementatie.

Onderhoud

  • Het Nodetool-herstel wordt automatisch uitgevoerd door de service met behulp van reaper. Dit hulpprogramma wordt elke week uitgevoerd. U kunt dit uitschakelen als u uw eigen service gebruikt voor een hybride implementatie.

  • Statuscontrole van knooppunten bestaat uit:

    • Controleer actief het lidmaatschap van elk knooppunt in de Cassandra-ring.
    • Automatisch detecteren en automatischmitteren van infrastructuurproblemen zoals virtuele machine, netwerk, opslag, Linux en ondersteuning van softwarefouten.
    • Pro-actief cpu-, schijf-, quorumverlies en andere resourceproblemen bewaken.
    • Er worden waar mogelijk mislukte knooppunten automatisch weergegeven en worden knooppunten handmatig weergegeven als reactie op automatisch gegenereerde waarschuwingen.

Ondersteuning

Azure Managed Instance voor Apache Cassandra biedt een SLA voor de beschikbaarheid van datacenters in een beheerd cluster. Als u problemen ondervindt met het gebruik van de service, dient u een ondersteuningsaanvraag in de Azure-portal in.

Onze ondersteuningsvoordelen zijn onder andere:

  • Single point of contact for Cassandra infrastructure issues: no need to raise support cases with IaaS teams (disk, compute, networking) apart.
  • Pro-actief advies via e-mail over prestatiefleshalzen, grootten en andere problemen met resourcebeperkingen.
  • Ondersteuningsdekking van 24x7, inclusief automatisch gegenereerde incidenten voor ernstige storingsproblemen.
  • Door de community goedgekeurde patchondersteuning (zie Patching).
  • Interne ondersteuning voor Java JDK/JVM-engineeringteam.
  • Linux-besturingssysteemondersteuning met beveiliging van software supply chain.

Belangrijk

We onderzoeken en diagnosticeren eventuele problemen die worden gerapporteerd via ondersteuningscases en lossen waar mogelijk op. U bent echter uiteindelijk verantwoordelijk voor elk gebruik op apache Cassandra-configuratieniveau dat CPU-, schijf- of netwerkproblemen veroorzaakt.

Voorbeelden van dergelijke problemen zijn:

  • Inefficiënte querybewerkingen.
  • Doorvoer die de capaciteit overschrijdt.
  • Gegevens opnemen die de opslagcapaciteit overschrijden.
  • Onjuiste configuratie-instellingen voor keyspace.
  • Slechte strategie voor gegevensmodel of partitiesleutel.

In het geval dat we een ondersteuningsaanvraag onderzoeken en ontdekken dat de hoofdoorzaak van het probleem zich op het configuratieniveau van Apache Cassandra bevindt (en geen onderliggende aspecten op platformniveau die we onderhouden), bieden we nog steeds aanbevelingen en richtlijnen voor herstel of risicobeperking (indien mogelijk), voordat de case wordt gesloten.

U wordt aangeraden metrische gegevens in te schakelen en/of vertrouwd te raken met de integratie van Azure Monitor om veelvoorkomende problemen op toepassings-/configuratieniveau in Apache Cassandra te voorkomen, zoals hierboven.

Waarschuwing

Met Azure Managed Instance voor Apache Cassandra kunt u ook uitvoeren en sstable opdrachten uitvoeren nodetool voor routine DBA-beheer. Zie het artikel hier. Sommige van deze opdrachten kunnen het cassandra-cluster stabiliseren en moeten alleen zorgvuldig worden uitgevoerd en nadat ze zijn getest in niet-productieomgevingen. Waar mogelijk moet eerst een --dry-run optie worden geïmplementeerd. Microsoft kan geen SLA of ondersteuning bieden voor problemen met het uitvoeren van opdrachten die de standaarddatabaseconfiguratie en/of tabellen wijzigen.

Back-ups en herstellen

Back-ups van momentopnamen zijn standaard ingeschakeld en worden elke 24 uur gemaakt. Back-ups worden opgeslagen in een intern Azure Blob Storage-account en worden maximaal 2 dagen (48 uur) bewaard. Er zijn geen kosten verbonden aan de eerste twee back-ups. Er worden extra back-ups in rekening gebracht, zie prijzen. Als u het back-upinterval of de bewaarperiode wilt wijzigen, kunt u het beleid bewerken in de portal:

Screenshot of backup schedule configuration page.

Als u wilt herstellen vanuit een bestaande back-up, dient u een ondersteuningsaanvraag in de Azure-portal in. Wanneer u de ondersteuningsaanvraag indient, moet u het volgende doen:

  1. Geef de back-up-id op vanuit de portal voor de back-up die u wilt herstellen. Dit is te vinden in de portal:

    Screenshot of backup schedule configuration page highlighting backup ID.

  2. Als herstel van het hele cluster niet vereist is, geeft u de keyspace en tabel (indien van toepassing) op die moeten worden hersteld.

  3. Geef aan of u de back-up wilt herstellen in het bestaande cluster of in een nieuw cluster.

  4. Als u wilt herstellen naar een nieuw cluster, moet u eerst het nieuwe cluster maken. Zorg ervoor dat het doelcluster overeenkomt met het broncluster in termen van het aantal datacenters en dat het bijbehorende datacenter hetzelfde aantal knooppunten heeft. U kunt ook bepalen of u de referenties (gebruikersnaam/wachtwoord) in het nieuwe doelcluster wilt behouden, of herstel wilt toestaan om gebruikersnaam/wachtwoord te overschrijven met wat oorspronkelijk is gemaakt.

  5. U kunt ook beslissen of u keyspace in het nieuwe doelcluster wilt behouden system_auth of toestaan dat de herstelbewerking deze overschrijft met gegevens uit de back-up. De system_auth keyspace in Cassandra bevat autorisatie- en interne verificatiegegevens, waaronder rollen, rolmachtigingen en wachtwoorden. Houd er rekening mee dat het standaardherstelproces de system_auth keyspace overschrijft.

Notitie

De tijd die nodig is om te reageren op een aanvraag om een back-up te herstellen, is afhankelijk van de ernst van de ondersteuningscase die u genereert (en de bijbehorende SLA voor reactietijd) en de hoeveelheid gegevens die moet worden hersteld. We bieden echter geen SLA voor tijd om het herstel te voltooien, omdat dit zeer afhankelijk is van het volume van de gegevens die worden hersteld.

Waarschuwing

Back-ups zijn bedoeld voor onbedoelde verwijderingsscenario's en zijn niet geografisch redundant. Ze worden daarom niet aanbevolen voor gebruik als noodherstelstrategie (DR) in geval van een totale regionale storing. Om te beschermen tegen storingen in de hele regio, raden we een implementatie met meerdere regio's aan. Bekijk onze quickstart voor implementaties in meerdere regio's.

Beveiliging

Azure Managed Instance voor Apache Cassandra biedt veel ingebouwde, expliciete beveiligingscontroles en -functies:

  • Beperkte installatiekopieën van virtuele Linux-machines met een beheerde toeleveringsketen.
  • Common Vulnerability & Exposure (CVE) bewaking op besturingssysteemniveau.
  • Certificaatrotatie voor zowel Apache Cassandra- als Prometheus-software die wordt gehost op de beheerde virtuele machines.
  • Actief scannen op beveiligingsproblemen.
  • Actieve virusscans.
  • Veilige coderingsprocedures.

Zie ons artikel hier voor meer informatie over beveiligingsfuncties.

Hybride ondersteuning

Wanneer een hybride cluster is geconfigureerd, profiteren geautomatiseerde herverwerkerbewerkingen die in de service worden uitgevoerd, het hele cluster. Dit omvat datacenters die niet door de service worden ingericht. Buiten dit is het uw verantwoordelijkheid om uw on-premises of extern gehoste datacenter te onderhouden.

Volgende stappen

Ga aan de slag met een van onze quickstarts: