Delen via

Apache Cassandra uitvoeren op Azure-VM's

  • Artikel

Let op

Dit artikel verwijst naar CentOS, een Linux-distributie die einde van de levensduur (EOL) is. Houd rekening met uw gebruik en plan dienovereenkomstig. Zie de Richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

In dit artikel worden prestatieoverwegingen beschreven voor het uitvoeren van Apache Cassandra op virtuele Azure-machines.

Deze aanbevelingen zijn gebaseerd op de resultaten van prestatietests, die u op GitHub kunt vinden. Gebruik deze aanbevelingen als basislijn en test vervolgens op basis van uw eigen workload.

Azure Managed Instance voor Apache Cassandra

Als u op zoek bent naar een meer geautomatiseerde service voor het uitvoeren van Apache Cassandra op virtuele Azure-machines, kunt u overwegen Om Azure Managed Instance voor Apache Cassandra te gebruiken. Deze service automatiseert de implementatie, het beheer (patching en knooppuntstatus) en het schalen van knooppunten binnen een Apache Cassandra-cluster. Het biedt ook de mogelijkheid voor hybride clusters, zodat Apache Cassandra-datacenters die zijn geïmplementeerd in Azure, kunnen deelnemen aan een bestaande on-premises of door derden gehoste Cassandra-ring. De service wordt geïmplementeerd met behulp van Virtuele-machineschaalsets van Azure. De volgende aanbevelingen zijn aangenomen tijdens de ontwikkeling van deze dienst.

Azure VM-grootten en schijftypen

Cassandra-workloads in Azure gebruiken vaak Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 of Standard_E16s_v5 virtuele machines. Cassandra-workloads profiteren van meer geheugen in de virtuele machine, dus overweeg om geoptimaliseerde grootten van virtuele machines te overwegen, zoals Standard_DS14_v2 of Standard_E16s_v5, of geoptimaliseerde grootten voor lokale opslag, zoals Standard_L16s_v3.

Voor duurzaamheid worden gegevens- en doorvoerlogboeken meestal opgeslagen op een stripeset van twee tot vier premium beheerde schijven (P30).

Cassandra-knooppunten mogen niet te dicht zijn bij gegevens. We raden u aan maximaal 1 tot 2 TB aan gegevens per VIRTUELE machine te hebben en voldoende vrije ruimte voor compressie. Als u de hoogst mogelijke gecombineerde doorvoer en IOPS wilt bereiken met behulp van premium beheerde schijven, raden we u aan om een stripe-set te maken van een paar schijven van 1 TB in plaats van één schijf van 2 TB of 4 TB te gebruiken. Op een DS14_v2 VM hebben vier schijven van 1 TB bijvoorbeeld een maximale IOPS van 4 × 5000 = 20 K, versus 7,5 K voor één schijf van 4 TB.

Evalueer Azure Ultra Disks voor Cassandra-workloads die kleinere schijfcapaciteit nodig hebben. Ze kunnen hogere IOPS/doorvoer en lagere latentie bieden voor VM-grootten, zoals Standard_E16s_v5 en Standard_D16s_v5.

Voor Cassandra-workloads die geen duurzame opslag nodig hebben, dat wil gezegd, waarbij gegevens eenvoudig kunnen worden gereconstrueerd vanuit een ander opslagmedium, kunt u overwegen om Standard_L16s_v3 of Standard_L16s_v2 VM's te gebruiken. Deze VM-grootten hebben grote en snelle lokale, tijdelijke NVM Express-schijven (NVMe).

Zie Prestaties van lokale/tijdelijke Azure-schijven vergelijken met gekoppelde/permanente schijven (GitHub) voor meer informatie.

Versneld netwerken

Cassandra-knooppunten maken intensief gebruik van het netwerk om gegevens van de client-VM te verzenden en te ontvangen en om te communiceren tussen knooppunten voor replicatie. Voor optimale prestaties profiteren Cassandra-VM's van een netwerk met hoge doorvoer en lage latentie.

We raden u aan versneld netwerken in te schakelen op de NIC van het Cassandra-knooppunt en op VM's met clienttoepassingen die toegang hebben tot Cassandra.

Versneld netwerken vereist een moderne Linux-distributie met de nieuwste stuurprogramma's, zoals Cent OS 7.5+ of Ubuntu 16.x/18.x. Zie Een virtuele Linux-machine maken met versneld netwerken voor meer informatie.

Azure VM-gegevensschijf opslaan in cache

Leesworkloads van Cassandra presteren het beste wanneer de latentie van willekeurige toegangsschijven laag is. U wordt aangeraden beheerde Azure-schijven te gebruiken waarvoor ReadOnly-caching is ingeschakeld. ReadOnly caching biedt een lagere gemiddelde latentie, omdat de gegevens worden gelezen uit de cache op de host in plaats van naar de back-endopslag te gaan.

Leesintensieve, willekeurige werkbelastingen zoals Cassandra profiteren van de lagere leeslatentie, ook al heeft de modus met cache lagere doorvoerlimieten dan de modus zonder cache. (Bijvoorbeeld: DS14_v2 virtuele machines een maximale doorvoer in de cache hebben van 512 MBps versus niet in de cache van 768 MBps.)

ReadOnly caching is met name handig voor Cassandra-tijdreeksen en andere werkbelastingen waarbij de werkgegevensset past in de hostcache en gegevens niet voortdurend worden overschreven. DS14_v2 biedt bijvoorbeeld een cachegrootte van 512 GB, waarmee maximaal 50% van de gegevens uit een Cassandra-knooppunt met een gegevensdichtheid van 1-2 TB kan worden opgeslagen.

Er is geen aanzienlijke prestatiestraf voor cachemissers wanneer ReadOnly-caching is ingeschakeld, dus de modus met cache wordt aanbevolen voor alle werkbelastingen met veel schrijfbewerkingen, behalve voor de meeste schrijfintensieve werkbelastingen.

Zie Cacheconfiguraties voor Azure-VM-gegevensschijven vergelijken (GitHub) voor meer informatie.

Linux-leesbewerking

In de meeste Linux-distributies in Azure Marketplace is de standaardinstelling voor lezen van blokapparaten 4096 KB. De lees-I/OS van Cassandra zijn meestal willekeurig en relatief klein. Daarom verspilt een grote leesdoorvoer door delen van bestanden te lezen die niet nodig zijn.

Als u onnodige lookahead wilt minimaliseren, stelt u de instelling lezen van het Linux-blokapparaat in op 8 kB. (Zie Aanbevolen productie-instellingen in de DataStax-documentatie.)

Configureer 8 kB voor lezen voor alle blokapparaten in de stripe-set en op het matrixapparaat zelf (bijvoorbeeld /dev/md0).

Zie Voor meer informatie de impact van de instellingen voor lezen van schijven vergelijken (GitHub).

Grootte van schijfmatrix mdadm-segment

Wanneer u Cassandra uitvoert in Azure, is het gebruikelijk om een mdadm stripe set (dat wil gezegd RAID 0) van meerdere gegevensschijven te maken om de totale schijfdoorvoer en IOPS dichter bij de VM-limieten te verhogen. Optimale schijfstreepgrootte is een toepassingsspecifieke instelling. Voor SQL Server OLTP-workloads is de aanbeveling bijvoorbeeld 64 kB. Voor datawarehousingworkloads is de aanbeveling 256 kB.

Onze tests hebben geen significant verschil gevonden tussen segmentgrootten van 64k, 128k en 256k voor leesworkloads van Cassandra. Er lijkt een klein, enigszins merkbaar voordeel te hebben van de segmentgrootte van 128.000. Daarom raden we het volgende aan:

  • Als u al een segmentgrootte van 64 K of 256 K gebruikt, is het niet zinvol om de schijfmatrix opnieuw te bouwen met een grootte van 128 K.

  • Voor een nieuwe configuratie is het zinvol om vanaf het begin 128 K te gebruiken.

Zie De impact van mdadm-segmentgrootten meten op Cassandra-prestaties (GitHub) voor meer informatie.

Logboekbestandssysteem doorvoeren

Cassandra-schrijfbewerkingen presteren het beste wanneer doorvoerlogboeken zich op schijven bevinden met hoge doorvoer en lage latentie. In de standaardconfiguratie worden in Cassandra 3.x elke ~10 seconden gegevens uit het geheugen naar het doorvoerlogboekbestand verwijderd en wordt de schijf niet voor elke schrijfbewerking aangeraakt. In deze configuratie zijn schrijfprestaties bijna identiek of het doorvoerlogboek zich op premium gekoppelde schijven versus lokale/kortstondige schijven bevindt.

Doorvoerlogboeken moeten duurzaam zijn, zodat een opnieuw opgestart knooppunt alle gegevens die nog niet in gegevensbestanden staan, kan reconstrueren vanuit de leeggemaakte doorvoerlogboeken. Voor een betere duurzaamheid slaat u doorvoerlogboeken op premium beheerde schijven op en niet op lokale opslag, wat verloren kan gaan als de virtuele machine naar een andere host wordt gemigreerd.

Op basis van onze tests kan Cassandra op CentOS 7.x lagere schrijfprestaties hebben wanneer doorvoerlogboeken zich in het xfs- versus ext4-bestandssysteem bevinden. Als u doorvoerlogboekcompressie inschakelt, worden xfs-prestaties in overeenstemming met ext4. Gecomprimeerde xfs presteren evenals gecomprimeerde en niet-gecomprimeerde ext4 in onze tests.

Zie Observaties over ext4- en xfs-bestandssystemen en gecomprimeerde doorvoerlogboeken (GitHub) voor meer informatie.

De prestaties van vm's volgens basislijn meten

Nadat u de VM's voor de Cassandra-ring hebt geïmplementeerd, voert u enkele synthetische tests uit om de basislijnnetwerk- en schijfprestaties vast te stellen. Gebruik deze tests om te controleren of de prestaties voldoen aan de verwachtingen, op basis van de VM-grootte.

Later, wanneer u de werkelijke workload uitvoert, is het gemakkelijker om potentiële knelpunten te onderzoeken door de basislijn voor prestaties te kennen. Als u bijvoorbeeld weet wat de basislijnprestaties zijn voor uitgaand netwerkverkeer op de VIRTUELE machine, kan dit helpen om het netwerk uit te sluiten als een knelpunt.

Zie De basislijn voor Azure VM-prestaties valideren (GitHub) voor meer informatie over het uitvoeren van prestatietests.

Documentgrootte

De lees- en schrijfprestaties van Cassandra zijn afhankelijk van de documentgrootte. U kunt verwachten dat u een hogere latentie en lagere bewerkingen per seconde ziet bij het lezen of schrijven met grotere documenten.

Zie Vergelijking van relatieve prestaties van verschillende Cassandra-documentgrootten (GitHub) voor meer informatie.

Replicatiefactor

De meeste Cassandra-workloads gebruiken een replicatiefactor (RF) van 3 bij het gebruik van gekoppelde Premium-schijven en zelfs 5 bij het gebruik van tijdelijke/tijdelijke lokale schijven. Het aantal knooppunten in de Cassandra-ring moet een veelvoud van de replicatiefactor zijn. RF 3 impliceert bijvoorbeeld een ring van 3, 6, 9 of 12 knooppunten, terwijl RF 5 5, 10, 15 of 20 knooppunten zou hebben. Wanneer u RF gebruikt die groter is dan 1 en een consistentieniveau van LOCAL_QUORUM, is het normaal dat de lees- en schrijfprestaties lager zijn dan dezelfde workload die wordt uitgevoerd met RF 1.

Zie Vergelijking van relatieve prestaties van verschillende replicatiefactoren (GitHub) voor meer informatie.

Linux-pagina's opslaan in cache

Wanneer de Java-code van Cassandra gegevensbestanden leest, wordt gebruikgemaakt van reguliere I/O-bestanden en profiteert deze van de cache van Linux-pagina's. Nadat delen van het bestand één keer zijn gelezen, wordt de leesinhoud opgeslagen in de cache van de pagina met het besturingssysteem. De volgende leestoegang tot dezelfde gegevens is veel sneller.

Daarom lijken de tweede en volgende leesbewerkingen veel sneller te zijn dan de oorspronkelijke leesbewerking, die nodig is om toegang te krijgen tot gegevens op de externe gegevensschijf of vanuit de hostcache wanneer ReadOnly is ingeschakeld. Als u vergelijkbare prestatiemetingen wilt krijgen bij volgende uitvoeringen, wist u de cache van de Linux-pagina en start u de Cassandra-service opnieuw om het interne geheugen te wissen. Wanneer ReadOnly-caching is ingeschakeld, bevinden de gegevens zich mogelijk in de hostcache en zijn latere leesbewerkingen sneller, zelfs nadat de cache van de besturingssysteempagina is gewist en de Cassandra-service opnieuw is opgestart.

Zie Observaties over Cassandra-gebruik van Caching van Linux-pagina's (GitHub) voor meer informatie.

Replicatie van meerdere datacenters

Cassandra biedt systeemeigen ondersteuning voor het concept van meerdere datacenters, waardoor u eenvoudig één Cassandra-ring kunt configureren in meerdere Azure-regio's of in meerdere beschikbaarheidszones binnen één regio.

Voor een implementatie met meerdere regio's gebruikt u Azure Global VNet-peering om de virtuele netwerken in de verschillende regio's te verbinden. Wanneer VM's in dezelfde regio worden geïmplementeerd, maar in afzonderlijke beschikbaarheidszones, kunnen de VM's zich in hetzelfde virtuele netwerk bevinden.

Het is belangrijk om de latentie van de basislijn roundtrip tussen regio's te meten. Netwerklatentie tussen regio's kan 10-100 keer hoger zijn dan latentie binnen een regio. Verwacht een vertraging tussen gegevens die in de tweede regio worden weergegeven bij gebruik van LOCAL_QUORUM schrijfconsistentie of aanzienlijk lagere prestaties van schrijfbewerkingen bij het gebruik van EACH_QUORUM.

Wanneer u Apache Cassandra op schaal uitvoert en met name in een omgeving met meerdere domeincontrollers, wordt herstel van knooppunten lastig. Hulpprogramma's zoals Reaper kunnen helpen bij het coördineren van reparaties op schaal (bijvoorbeeld op alle knooppunten in een datacenter, één datacenter tegelijk, om de belasting van het hele cluster te beperken). Herstel van knooppunten voor grote clusters is echter nog geen volledig opgelost probleem en is van toepassing in alle omgevingen, zowel on-premises als in de cloud.

Wanneer knooppunten worden toegevoegd aan een secundaire regio, worden de prestaties niet lineair geschaald, omdat sommige bandbreedte- en CPU-/schijfresources worden besteed aan het ontvangen en verzenden van replicatieverkeer tussen regio's.

Zie De impact van replicatie tussen regio's met meerdere domeincontrollers (GitHub) voor meer informatie.

Configuratie van hinted-handoff

In een Cassandra-ring met meerdere regio's kunnen schrijfworkloads met consistentieniveau van LOCAL_QUORUM gegevens in de secundaire regio verliezen. Standaard wordt de hand-off van Cassandra beperkt tot een relatief lage maximale doorvoer en de levensduur van drie uur. Voor workloads met zware schrijfbewerkingen is het raadzaam om de vertraging van de hints en hintvensters te verhogen om ervoor te zorgen dat hints niet worden verwijderd voordat ze worden gerepliceerd.

Zie Observaties over hinted handoff in replicatie tussen regio's (GitHub) voor meer informatie.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Andere inzender:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Zie Cassandra op Prestatieexperimenten van Azure-VM's voor meer informatie over deze prestatieresultaten.

Zie voor meer informatie over algemene Cassandra-instellingen, niet specifiek voor Azure: