Condividi tramite

Eseguire Apache Cassandra in macchine virtuali di Azure

  • Articolo

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux che ha raggiunto lo stato EOL (End of Life, fine del ciclo di vita). Valutare le proprie esigenze e pianificare di conseguenza. Per ulteriori informazioni, consultare la Guida alla fine del ciclo di vita di CentOS.

Questo articolo descrive le considerazioni sulle prestazioni per l'esecuzione di Apache Cassandra in Azure Macchine virtuali.

Queste raccomandazioni sono basate sui risultati dei test delle prestazioni, disponibili in GitHub. È consigliabile usare queste raccomandazioni come base e quindi testare il proprio carico di lavoro.

Istanza gestita di Azure per Apache Cassandra

Se si sta cercando un servizio più automatizzato per l'esecuzione di Apache Cassandra in Azure Macchine virtuali, è consigliabile usare Azure Istanza gestita per Apache Cassandra. Questo servizio automatizza la distribuzione, la gestione (applicazione di patch e integrità dei nodi) e il dimensionamento dei nodi all'interno di un cluster Apache Cassandra. Offre anche la funzionalità per i cluster ibridi, affinché i data center Apache Cassandra distribuiti in Azure possano essere aggiunti a un anello Cassandra locale o ospitato da terze parti esistente. Il servizio viene distribuito usando Azure set di scalabilità di macchine virtuali. Durante lo sviluppo di questo servizio sono state adottate le raccomandazioni seguenti.

Dimensioni e tipi di dischi delle macchine virtuali di Azure

I carichi di lavoro Cassandra in Azure usano in genere macchine virtuali Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 o Standard_E16s_v5 . I carichi di lavoro Cassandra traggono vantaggio dalla presenza di più memoria nella macchina virtuale, quindi prendere in considerazione dimensioni delle macchine virtuali ottimizzate per la memoria, ad esempio Standard_DS14_v2 o Standard_E16s_v5 o dimensioni ottimizzate per l'archiviazione locale, ad esempio Standard_L16s_v3.

Per la durabilità, i log di dati e commit vengono in genere archiviati in un set con striping costituito da due a quattro dischi gestiti Premium da 1 TB (P30).

I nodi Cassandra non devono essere troppo densi di dati. È consigliabile avere al massimo da 1 a 2 TB di dati per macchina virtuale e spazio disponibile sufficiente per la compattazione. Per ottenere i valori massimi combinati di velocità effettiva e operazioni di I/O al secondo usando dischi gestiti Premium, è consigliabile creare un set di striping con alcuni dischi da 1 TB, anziché usare un singolo disco da 2 TB o 4 TB. Ad esempio, in una macchina virtuale DS14_v2 quattro dischi da 1 TB offrono un massimo di operazioni di I/O al secondo pari a 4 × 5000 = 20 K, rispetto a 7,5 K per un singolo disco da 4 TB.

Valutare i dischi Ultra di Azure per i carichi di lavoro Cassandra che necessitano di capacità del disco più piccola. Possono offrire un numero di operazioni di I/O al secondo/o superiore e una latenza inferiore nelle dimensioni delle macchine virtuali, ad esempio Standard_E16s_v5 e Standard_D16s_v5.

Per i carichi di lavoro Cassandra che non necessitano di risorse di archiviazione durevoli, ovvero in cui i dati possono essere facilmente ricostruiti da un altro supporto di archiviazione, è consigliabile usare Standard_L16s_v3 o Standard_L16s_v2 macchine virtuali. Queste dimensioni delle macchine virtuali hanno dischi NVM Express (NVMe) temporanei di grandi dimensioni e veloci.

Per altre informazioni, vedere Confronto tra le prestazioni dei dischi locali/temporanei di Azure e i dischi collegati/persistenti (GitHub).

Rete accelerata

I nodi Cassandra usano la rete in modo intensivo per inviare e ricevere dati dalla macchina virtuale client e per comunicare tra i nodi per la replica. Per prestazioni ottimali, le macchine virtuali Cassandra necessitano di una rete a velocità effettiva elevata e a bassa latenza.

È consigliabile abilitare Rete accelerata nella scheda di interfaccia di rete del nodo Cassandra e nelle macchine virtuali che eseguono applicazioni client che accedono a Cassandra.

La rete accelerata richiede una distribuzione Linux moderna con i driver più recenti, ad esempio Cent OS 7.5+ o Ubuntu 16.x/18.x. Per altre informazioni, vedere Creare una macchina virtuale Linux con rete accelerata.

Memorizzazione nella cache dei dischi di dati delle macchine virtuali di Azure

I carichi di lavoro di lettura di Cassandra offrono prestazioni ottimali quando la latenza del disco ad accesso casuale è bassa. È consigliabile usare dischi gestiti di Azure con la memorizzazione nella cache di sola lettura abilitata. La memorizzazione nella cache di sola lettura offre una latenza media inferiore, perché i dati vengono letti dalla cache nell'host anziché essere indirizzati all'archiviazione back-end.

I carichi di lavoro con operazioni di lettura elevata e casuale come Cassandra garantiscono prestazioni ottimali con una latenza di lettura inferiore anche se la modalità cache ha limiti di velocità effettiva inferiori rispetto alla modalità non cache. (Ad esempio, DS14_v2 le macchine virtuali hanno una velocità effettiva massima memorizzata nella cache di 512 MBps rispetto a 768 MBps non memorizzata nella cache.

La memorizzazione nella cache ReadOnly è particolarmente utile per le serie temporali Cassandra e altri carichi di lavoro in cui il set di dati funzionante si inserisce nella cache host e i dati non vengono sovrascritti costantemente. Ad esempio, la serie DS14_v2 fornisce dimensioni della cache di 512 GB, che consentono di archiviare fino al 50% dei dati da un nodo Cassandra con densità dei dati di 1-2 TB.

Non c'è alcuna riduzione significativa delle prestazioni dai mancati riscontri nella cache quando la memorizzazione nella cache ReadOnly è abilitata, quindi la modalità memorizzata nella cache è consigliata per tutti i carichi di lavoro con maggiore quantità di scrittura.

Per altre informazioni, vedere Confronto delle configurazioni di memorizzazione nella cache del disco dati delle macchine virtuali di Azure (GitHub).

Read-ahead Linux

Nella maggior parte delle distribuzioni Linux in Azure Marketplace, l'impostazione read-ahead predefinita del dispositivo di blocco è 4096 kB. Le operazioni di I/OS di lettura di Cassandra sono in genere casuali e relativamente piccole. Di conseguenza, la presenza di un processo read-ahead di grandi dimensioni spreca velocità effettiva a causa della lettura di parti di file non necessarie.

Per ridurre al minimo le attività di lookahead non necessarie, configurare l'impostazione read-ahead del dispositivo di blocco Linux su 8 kB. Vedere Impostazioni di produzione consigliate nella documentazione di DataStax.

Configurare il read-ahead di 8 kB per tutti i dispositivi di blocco nel set di striping e nel dispositivo array stesso (ad esempio, /dev/md0).

Per altre informazioni, vedere Confronto dell'impatto delle impostazioni read-ahead del disco (GitHub).

Dimensioni del blocco mdadm dell'array di dischi

Quando si esegue Cassandra in Azure, si crea in genere un set di striping mdadm (ovvero RAID 0) di più dischi dati per aumentare la velocità effettiva complessiva del disco e le operazioni di I/O al secondo fino ai valori più vicini ai limiti delle macchine virtuali. Le dimensioni ottimali dello stripe del disco sono un'impostazione specifica dell'applicazione. Ad esempio, per i carichi di lavoro OLTP di SQL Server, la raccomandazione è di 64 kB. Per i carichi di lavoro di data warehousing, la raccomandazione è di 256 kB.

I test non hanno rilevato alcuna differenza significativa tra dimensioni dei blocchi di 64 K, 128 K e 256 K per i carichi di lavoro di lettura Cassandra. Risulta un piccolo vantaggio, appena evidente, per le dimensioni del blocco da 128 K. È quindi consigliabile eseguire queste operazioni:

  • Se si usa già una dimensione di blocco di 64 K o 256 K, non è opportuno ricompilare la matrice di dischi per usare dimensioni da 128 K.

  • Per una nuova configurazione, è opportuno usare 128 K fin dall'inizio.

Per altre informazioni, vedere Misurazione dell'impatto delle dimensioni dei blocchi mdadm sulle prestazioni di Cassandra (GitHub).

File system del log di commit

Le scritture di Cassandra offrono prestazioni ottimali quando i log di commit si verificano su dischi con velocità effettiva elevata e bassa latenza. Nella configurazione predefinita Cassandra 3.x scarica i dati dalla memoria nel file di log di commit ogni ~10 secondi e non accede al disco per ogni scrittura. In questa configurazione, le prestazioni di scrittura sono quasi identiche se il log di commit si trova su dischi collegati Premium rispetto a dischi locali/temporanei.

I log di commit devono essere durevoli, affinché un nodo riavviato possa ricostruire tutti i dati non ancora presenti nei file di dati dai log di commit scaricati. Per una migliore durabilità, archiviare i log di commit in dischi gestiti Premium e non nell'archiviazione locale, perché potrebbero andare persi se viene eseguita la migrazione della macchina virtuale a un altro host.

In base ai test, Cassandra in CentOS 7.x potrebbe offrire prestazioni di scrittura inferiori quando i log di commit si trovano nel file system xfs rispetto al file system ext4. L'attivazione della compressione dei log di commit allinea le prestazioni del file system xfs a quelle del file system ext4. Nei test eseguiti i log di commit xfs compressi garantiscono le stesse prestazioni dei log di commit ext4 compressi e non compressi.

Per altre informazioni, vedere Osservazioni sui file system ext4 e xfs e sui log di commit compressi (GitHub).

Misurazione delle prestazioni di base della macchina virtuale

Dopo aver distribuito le macchine virtuali per l'anello Cassandra, eseguire alcuni test sintetici per stabilire le prestazioni di base per la rete e i dischi. Usare questi test per verificare che le prestazioni siano in linea con le aspettative, in base alle dimensioni della macchina virtuale.

In un secondo momento, quando si esegue il carico di lavoro effettivo, conoscere le prestazioni di base semplifica l'analisi dei potenziali colli di bottiglia. Ad esempio, conoscere le prestazioni di base per il traffico in uscita dalla rete nella macchina virtuale può aiutare a escludere la rete dai possibili colli di bottiglia.

Per altre informazioni sull'esecuzione di test delle prestazioni, vedere Convalida delle prestazioni di base delle macchine virtuali di Azure (GitHub).

Dimensioni del documento

Le prestazioni di lettura e scrittura di Cassandra dipendono dalle dimensioni del documento. È possibile prevedere una latenza più elevata e un numero inferiore di operazioni al secondo durante la lettura o la scrittura con documenti di grandi dimensioni.

Per altre informazioni, vedere Confronto delle prestazioni relative di diverse dimensioni dei documenti Cassandra (GitHub).

Fattore di replica

La maggior parte dei carichi di lavoro Cassandra usa un fattore di replica (RF) pari a 3 quando si usano dischi Premium collegati e anche fino a 5 quando si usano dischi locali temporanei. Il numero di nodi nell'anello cassandra deve essere un multiplo del fattore di replica. Ad esempio, un fattore di replica di 3 implica un anello di 3, 6, 9 o 12 nodi, mentre un fattore di replica di 5 prevede 5, 10, 15 o 20 nodi. Quando si usa un fattore di replica maggiore di 1 e un livello di coerenza di LOCAL_QUORUM, è normale che le prestazioni di lettura e scrittura siano inferiori rispetto allo stesso carico di lavoro in esecuzione con un fattore di replica pari a 1.

Per altre informazioni, vedere Confronto delle prestazioni relative di vari fattori di replica (GitHub).

Memorizzazione nella cache delle pagine Linux

Quando il codice Java di Cassandra legge i file di dati, usa i normali I/O dei file e trae vantaggio dalla memorizzazione nella cache delle pagine linux. Dopo aver letto una volta parti del file, il contenuto letto viene archiviato nella cache della pagina del sistema operativo. L'accesso in lettura successivo agli stessi dati è molto più veloce.

Per questo motivo, quando si eseguono test delle prestazioni di lettura sugli stessi dati, la seconda lettura e quelle successive saranno molto più veloci rispetto alla lettura originale, che ha dovuto accedere ai dati sul disco dati remoto o dalla cache dell'host quando è abilitata la memorizzazione nella cache di sola lettura. Per ottenere misurazioni delle prestazioni simili nelle esecuzioni successive, cancellare la cache delle pagine Linux e riavviare il servizio Cassandra per cancellare la memoria interna. Quando è abilitata la memorizzazione nella cache di sola lettura, i dati potrebbero trovarsi nella cache dell'host e le operazioni di lettura successive saranno più veloci anche dopo la cancellazione della cache delle pagine del sistema operativo e il riavvio del servizio Cassandra.

Per altre informazioni, vedere Osservazioni sull'utilizzo di Cassandra della memorizzazione nella cache delle pagine Linux (GitHub).

Replica in più data center

Cassandra supporta in modo nativo il concetto di più data center, semplificando la configurazione di un anello Cassandra in più aree di Azure o tra zone di disponibilità all'interno di un'area.

Per una distribuzione su più aree, usare il peering di rete virtuale globale di Azure per connettere le reti virtuali nelle diverse aree. Quando le macchine virtuali vengono distribuite nella stessa area ma in zone di disponibilità separate, le macchine virtuali possono risiedere nella stessa rete virtuale.

È importante misurare la latenza di roundtrip di base tra le aree. La latenza di rete tra aree può essere da 10 a 100 volte superiore alla latenza all'interno di un'area. Prevedere un ritardo per la visualizzazione dei dati nella seconda area quando si usa la coerenza di scrittura LOCAL_QUORUM o prestazioni delle scritture notevolmente ridotte quando si usa il livello EACH_QUORUM.

Quando si esegue Apache Cassandra su larga scala e in particolare in un ambiente multi-controller di dominio, la riparazione dei nodi diventa complessa. Strumenti come Reaper consentono di coordinare le riparazioni su larga scala, ad esempio in tutti i nodi di un data center, un data center alla volta, per limitare il carico sull'intero cluster. Tuttavia, il ripristino dei nodi per cluster di grandi dimensioni non è ancora un problema completamente risolto e si applica in tutti gli ambienti, sia in locale che nel cloud.

Quando i nodi vengono aggiunti a un'area secondaria, le prestazioni non vengono ridimensionate in modo lineare, perché alcune risorse di larghezza di banda e CPU/disco vengono spese per ricevere e inviare traffico di replica tra aree.

Per altre informazioni, vedere Misurazione dell'impatto della replica tra aree e in più data center (GitHub).

Configurazione hinted handoff

In un anello Cassandra in più aree, i carichi di lavoro di scrittura con livello di coerenza LOCAL_QUORUM potrebbero perdere dati nell'area secondaria. Per impostazione predefinita, l'hinted handoff di Cassandra è limitato a una velocità effettiva massima relativamente bassa e una durata dell'hint di tre ore. Per i carichi di lavoro con scritture pesanti, è consigliabile aumentare il tempo di limitazione dell'handoff e l'intervallo di hint per assicurarsi che gli hint non vengano eliminati prima della replica.

Per altre informazioni, vedere Osservazioni sull'hinted handoff nella replica tra aree (GitHub).

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Altro collaboratore:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Per altre informazioni su questi risultati delle prestazioni, vedere Cassandra negli esperimenti sulle prestazioni delle macchine virtuali di Azure.

Per informazioni sulle impostazioni generali di Cassandra, non specifiche di Azure, vedere: