Condividi tramite

Eseguire Apache Cassandra in macchine virtuali di Azure

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux che ha raggiunto lo stato EOL (End of Life, fine del ciclo di vita). Considera l'uso e pianifica 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 set di scalabilità di macchine virtuali di Azure. 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 dei dati e di commit vengono in genere archiviati in un insieme di striping da due a quattro unità SSD 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 la larghezza di banda combinata più elevata possibile e le operazioni di I/O al secondo usando unità SSD Premium, è consigliabile creare un set di striping da pochi dischi da 1 TB, invece di usare un'unità singola da 2 TB o da 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 fornire IOPS/throughput più elevati e latenza inferiore su dimensioni delle macchine virtuali come 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 taglie di macchine virtuali hanno grandi e veloci dischi locali temporanei NVM Express (NVMe).

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 Azure Managed Disks con la memorizzazione nella cache ReadOnly 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, le macchine virtuali DS14_v2 hanno una velocità effettiva massima memorizzata nella cache di 512 MBps rispetto a 768 MBps non memorizzati 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 dovuta ai mancati accessi alla cache quando la memorizzazione nella cache ReadOnly è abilitata, quindi la modalità cache è consigliata per tutti tranne che per i carichi di lavoro con molte scritture.

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

Linux lettura anticipata

Nella maggior parte delle distribuzioni Linux disponibili per Azure in Microsoft Marketplace, l'impostazione predefinita del dispositivo di blocco read-ahead è 4096 KB. Le operazioni di I/O di lettura di Cassandra sono in genere casuali e relativamente piccole. Di conseguenza, un ampio read-ahead spreca risorse leggendo parti di file che non sono necessarie.

Per ridurre al minimo le operazioni 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 su Azure, è comune creare un mdadm stripe set (ovvero, RAID 0) di più dischi dati per aumentare il throughput complessivo del disco e le operazioni di I/O al secondo vicini ai limiti della VM. La dimensione ottimale dello stripe del disco è una configurazione 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 percettibile, per le dimensioni del blocco da 128 K. Di conseguenza, è consigliabile adottare gli approcci seguenti:

  • 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 maggiore durabilità, archiviare i log di commit nelle unità SSD Premium e non nella risorsa di archiviazione locale, che può andare perduta se viene eseguita la migrazione della macchina virtuale a un altro host.

In base ai test, Cassandra in CentOS 7.x potrebbe avere prestazioni di scrittura inferiori quando i log di commit si trovano nel file system xfs rispetto a 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 il livello di prestazioni di riferimento semplifica l'esame 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 su Cassandra utilizza un fattore di replicazione (RF) di 3 nel caso di dischi Premium dedicati e perfino 5 nel caso di dischi locali temporanei/effimeri. 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 RF 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 RF 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 di prestazioni di lettura sugli stessi dati, la seconda e le letture successive sembra essere molto più veloce della lettura originale, che è necessario per accedere ai dati sul disco dati remoto o dalla cache host quando ReadOnly è abilitato. 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 la memorizzazione nella cache ReadOnly è abilitata, i dati potrebbero trovarsi nella cache host e le letture successive sono più veloci anche dopo la cancellazione della cache della pagina 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. Si prevede un ritardo tra i dati visualizzati nella seconda area quando si usa la coerenza di scrittura LOCAL_QUORUM, o si prevedono prestazioni delle scritture significativamente ridotte quando si usa EACH_QUORUM.

Quando si esegue Apache Cassandra su larga scala e in particolare in un ambiente multi-datacenter, la riparazione dei nodi si fa più 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 rimane una sfida non risolta 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 handoff suggerito

In un anello Cassandra multiregione, i carichi di scrittura con un livello di coerenza di LOCAL_QUORUM potrebbero perdere dati nell'area secondaria. Per impostazione predefinita, l'hinted handoff di Cassandra è limitato a un throughput massimo relativamente basso e a una durata dell'hint di tre ore. Per i carichi di lavoro con scritture pesanti, è consigliabile aumentare la velocità di consegna con suggerimenti e il tempo della finestra dei suggerimenti per assicurarsi che i suggerimenti non vengano eliminati prima della replica.

Per ulteriori informazioni, consultare Osservazioni sull'hinted handoff nella replicazione tra regioni (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 altre informazioni sulle impostazioni generali di Cassandra, non specifiche di Azure, vedere:

  • Last updated on