Apache Cassandra uitvoeren op Azure-VM's
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 kunt vinden op GitHub. 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 (patch- en knooppunttoestand) 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, lid kunnen worden van 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 service.
Azure VM-grootten en -schijftypen
Cassandra-workloads in Azure maken vaak gebruik van Standard_DS14_v2 of Standard_DS13_v2 virtuele machines. Cassandra-workloads profiteren van meer geheugen in de VM. Overweeg daarom voor geheugen geoptimaliseerde VM-grootten, zoals Standard_DS14_v2 of voor lokale opslag geoptimaliseerde grootten zoals Standard_L16s_v2.
Voor duurzaamheid worden gegevens- en commit-logboeken meestal opgeslagen op een stripe-set van twee tot vier premium beheerde schijven van 1 TB (P30).
Cassandra-knooppunten mogen niet te veel gegevens bevatten. We raden u aan om 12 TB aan gegevens per VM en voldoende vrije ruimte voor – compergatie te hebben. 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 enkele schijven van 1 TB in plaats van één schijf van 2 TB of 4 TB. Op een virtuele DS14_v2 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.
Naarmate Azure Ultra Disks in meerdere regio's beschikbaar wordt, kunt u ze evalueren voor Cassandra-workloads die kleinere schijfcapaciteit nodig hebben. Ze kunnen een hogere IOPS/doorvoer en lagere latentie bieden voor VM-grootten zoals Standard_D32s_v3 en Standard_D16s_v3.
Voor Cassandra-workloads die geen duurzame opslag nodig hebben, dat wil zeggen, waar gegevens eenvoudig kunnen worden gereconstrueerd vanuit een ander opslagmedium, kunt u overwegen Standard_L32s_v2 of Standard_L16s_v2 — — gebruiken. Deze VM-grootten hebben grote en snelle lokale tijdelijke NVMe-schijven.
Zie Prestaties van lokale/kortstondige Azure-schijven vergelijken met gekoppelde/permanente schijven (GitHub) voor meer GitHub.
Versneld netwerken
Cassandra-knooppunten maken intensief gebruik van het netwerk voor het verzenden en ontvangen van gegevens van de client-VM 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 stellen 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 Create a Linux virtual machine with Accelerated Networking (Een virtuele Linux-machine maken met versneld netwerken) voor meer informatie.
Azure VM data disk caching (Azure VM-gegevensschijf opslaan in de azure-VM)
Leesworkloads van Cassandra presteren het beste wanneer de latentie van de schijf met willekeurige toegang laag is. We raden u aan azure managed disks te gebruiken met ReadOnly caching ingeschakeld. ReadOnly caching biedt een lagere gemiddelde latentie, omdat de gegevens uit de cache op de host worden gelezen in plaats van naar de back-endopslag te gaan.
Leeszware, willekeurige leesworkloads zoals Cassandra profiteren van de lagere leeslatentie, ook al heeft de cachemodus lagere doorvoerlimieten dan de niet-gecachede modus. (Virtuele machines DS14_v2 bijvoorbeeld een maximale doorvoer in de cache van 512 MB/s versus een niet-gecachede doorvoer van 768 MB/s.)
ReadOnly caching is met name handig voor Cassandra-tijdreeksen en andere werkbelastingen waarbij de werkgegevensset in de hostcache past en gegevens niet voortdurend worden overschreven. Zo biedt DS14_v2 een cachegrootte van 512 GB, waarmee maximaal 50% van de gegevens uit een Cassandra-knooppunt met een gegevensdichtheid van 1-2 TB kunnen worden opgeslagen.
Er is geen aanzienlijke prestatiestraf van cache-missers wanneer LezenOnly caching is ingeschakeld. Daarom wordt de cachemodus aanbevolen voor alle werkbelastingen, behalve voor de meeste schrijfwerkbelastingen.
Zie Cachingconfiguraties voor Azure VM-gegevensschijven vergelijken (GitHub) voor meer GitHub.
Linux read-ahead
In de meeste Linux-distributies in Azure Marketplace is de standaardinstelling voor het voorlezen van blokapparaat 4096 kB. De lees-IO's van Cassandra zijn meestal willekeurig en relatief klein. Als u een grote hoeveelheid vooruitlezen hebt, wordt de doorvoer verspild door delen van bestanden te lezen die niet nodig zijn.
Als u onnodige lookahead wilt minimaliseren, stelt u de instelling Voorlezen van Linux-blokapparaat in op 8 kB. (Zie Aanbevolen productie-instellingen in de DataStax-documentatie.)
Configureer 8 KB read-ahead voor alle blokapparaten in de stripe-set en op het matrixapparaat zelf (bijvoorbeeld /dev/md0 ).
Zie Comparing impact of disk read-ahead settings (instellingen voor vooruitlezen) voor meer GitHub.
Schijfmatricem chunkgrootte
Bij het uitvoeren van Cassandra in Azure is het gebruikelijk om een mloftm stripe-set (raid 0) van meerdere gegevensschijven te maken om de totale schijfdoorvoer en IOPS dichter bij de VM-limieten te verhogen. Optimale schijfstreegrootte is een toepassingsspecifieke instelling. Voor het uitvoeren van 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 64.000, 128.000 en 256.000 voor Leesworkloads van Cassandra. Er lijkt een klein, enigszins merkbaar voordeel te zijn van de chunkgrootte van 128.000. Daarom raden we het volgende aan:
Als u al een segmentgrootte van 64 K of 256 K gebruikt, is het niet logisch om de schijf array opnieuw te bouwen om een grootte van 128 K te gebruiken.
Voor een nieuwe configuratie is het zinvol om vanaf het begin 128 K te gebruiken.
Zie Voor meer informatie Het meten van de impact van m²m-segmentgrootten op Cassandra-prestaties (GitHub).
Bestandssysteem voor logboeken commit
Schrijfgegevens van Cassandra presteren het beste wanneer doorvoerlogboeken zich op schijven met een hoge doorvoer en lage latentie hebben. In de standaardconfiguratie worden in Cassandra 3.x elke ~10 seconden gegevens uit het geheugen naar het commit-logboekbestand leeggetrokken en wordt de schijf niet voor elke schrijfing raken. In deze configuratie zijn de schrijfprestaties bijna identiek, ongeacht of het commit-logboek zich op premium gekoppelde schijven of lokale/kortstondige schijven.
Commit-logboeken moeten duurzaam zijn, zodat een opnieuw gestart knooppunt gegevens die nog niet in gegevensbestanden zijn opgeslagen, kan reconstrueren vanuit de verwijderde commit-logboeken. Sla voor een betere duurzaamheid commit-logboeken op premium beheerde schijven op en niet op lokale opslag, die verloren kunnen gaan als de VM naar een andere host wordt gemigreerd.
Op basis van onze tests heeft Cassandra op CentOS 7.x mogelijk lagere schrijfprestaties wanneer commit-logboeken zich op het xfs-bestandssysteem of het ext4-bestandssysteem hebben. Door compressie van het commit-logboek in te zetten, worden xfs-prestaties in overeenstemming met ext4. Gecomprimeerde xfs presteert in onze tests net zo goed als gecomprimeerde en niet-gecomprimeerde ext4.
Zie Waarnemingen over ext4- en xfs-bestandssystemen en gecomprimeerde commit-logboeken (GitHub) voor meer GitHub.
Prestaties van basislijn-VM's meten
Nadat u de VM's voor de Cassandra-ring hebt geïmplementeerd, moet u enkele synthetische tests uitvoeren om de basisnetwerk- en schijfprestaties vast te stellen. Gebruik deze tests om te bevestigen dat de prestaties in overeenstemming zijn met de verwachtingen, op basis van de VM-grootte.
Later, wanneer u de werkelijke workload gaat uitvoeren, is het gemakkelijker om potentiële knelpunten te onderzoeken als u de prestatiebasislijn kent. Als u bijvoorbeeld de basislijnprestaties voor netwerk-egress op de VM kent, kan dit helpen om het netwerk uit te sluiten als een knelpunt.
Zie Validating baseline Azure VM Performance (prestaties van azure-VM's valideren) voor meer informatie over het uitvoeren van prestatietest GitHub s.
Documentgrootte
De lees- en schrijfprestaties van Cassandra zijn afhankelijk van de documentgrootte. U kunt een hogere latentie en lagere bewerkingen/seconde verwachten bij het lezen of schrijven met grotere documenten.
Zie Relatieve prestaties van verschillende Cassandra-documentgrootten vergelijken (GitHub) voor meer GitHub.
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 Relatieve prestaties van verschillende replicatiefactoren (GitHub) voor meer GitHub.
Linux-pagina's in deaching
Bij het lezen van gegevensbestanden maakt de Java-code van Cassandra gebruik van reguliere bestands-I/O en profiteert deze van het opslaan in de linux-pagina. Nadat delen van het bestand één keer zijn gelezen, wordt de leesinhoud opgeslagen in de cache van de besturingssysteempagina. Daaropvolgende leestoegang tot dezelfde gegevens is veel sneller.
Daarom lijken de tweede en volgende leesresultaten bij het uitvoeren van leesprestatietests op dezelfde gegevens veel sneller dan de oorspronkelijke leesgegevens, die nodig zijn voor toegang tot gegevens op de externe gegevensschijf of vanuit de hostcache wanneer ReadOnly is ingeschakeld. Als u vergelijkbare prestatiemetingen wilt krijgen bij volgende uitvoeringen, moet u de Linux-paginacache wissen en de Cassandra-service opnieuw starten om het interne geheugen te wissen. Wanneer ReadOnly caching is ingeschakeld, kunnen de gegevens zich in de hostcache en zijn volgende leesgegevens sneller, zelfs na het wissen van de cache van de besturingssysteempagina en het opnieuw starten van de Cassandra-service.
Zie Observations on Cassandra usage of Linux page caching (Waarnemingen over Cassandra-gebruik van Linux-pagina caching (GitHub) voor meer GitHub.
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 beschikbaarheidszones binnen één regio.
Gebruik voor een implementatie met meerdere regio's Azure Global VNet-peering om de virtuele netwerken in de verschillende regio's met elkaar te verbinden. Wanneer VM's worden geïmplementeerd in dezelfde regio, maar in afzonderlijke beschikbaarheidszones, kunnen de VM's zich in hetzelfde virtuele netwerk bevinden.
Het is belangrijk om de basislijn retourlatentie tussen regio's te meten. Netwerklatentie tussen regio's kan 10-100 keer hoger zijn dan de latentie binnen een regio. U kunt een vertraging verwachten tussen gegevens die worden weergegeven in de tweede regio wanneer u LOCAL_QUORUM schrijfconsistentie gebruikt, of aanzienlijk lagere prestaties van schrijf schrijfprestaties bij het gebruik van EACH_QUORUM.
Bij het uitvoeren van Apache Cassandra op schaal, en dan met name in een omgeving met meerdere dc's, wordt het herstellen van knooppunt lastig. Hulpprogramma's zoals Reaper kunnen helpen bij het coördineren van reparaties op schaal (bijvoorbeeld voor alle knooppunten in een datacenter, één datacenter tegelijk, om de belasting van het hele cluster te beperken). Knooppuntherstel voor grote clusters is echter nog geen volledig opgelost probleem en is van toepassing op alle omgevingen, on-premises of in de cloud.
Wanneer knooppunten worden toegevoegd aan een secundaire regio, worden de prestaties niet lineair geschaald, omdat bepaalde bandbreedte en CPU-/schijfresources worden besteed aan het ontvangen en verzenden van replicatieverkeer tussen regio's.
Zie De impact van replicatie tussen meerdere dc's (multi-dc) meten (GitHub) voor meer GitHub.
Configuratie van hinted-hand-off
In een Cassandra-ring met meerdere regio's kunnen schrijfworkloads met een consistentieniveau van LOCAL_QUORUM gegevens in de secundaire regio verloren gaan. Standaard wordt de handoff door Cassandra beperkt tot een relatief lage maximale doorvoer en een hintlevensduur van drie uur. Voor werkbelastingen met zware schrijfwerkbelastingen is het raadzaam om de hinted handoff-vertraging en hintvenstertijd te verhogen om ervoor te zorgen dat hints niet worden weggeslagen voordat ze worden gerepliceerd.
Zie Waarnemingen over hinted handoff in replicatie tussen regio's (GitHub) voor meer GitHub.
Volgende stappen
Zie Cassandra on Azure VMs Performance Experimentsvoor meer informatie over deze prestatieresultaten.
Zie voor meer informatie over algemene Cassandra-instellingen, niet specifiek voor Azure:
De volgende referentiearchitectuur implementeert Cassandra als onderdeel van een n-tier-configuratie: