Che cos'è il test di archiviazione? Tipi, Concepts & Esempio

By: Tommaso Hamilton Tommaso Hamilton
Hours aggiornato

⚡ Riepilogo intelligente

I test di archiviazione verificano che un'applicazione scriva i propri dati nelle directory corrette e disponga di spazio su disco sufficiente per evitare terminazioni impreviste, misurando al contempo la velocità di risposta dell'archiviazione sottostante in condizioni di carico realistiche.

  • 💾 Chiamato anche: Test delle prestazioni di archiviazione, perché la velocità è importante tanto quanto il corretto posizionamento.
  • ⚠️ Perché è importante: Un sistema di archiviazione lento comporta tempi di risposta lenti, query di lunga durata e una minore disponibilità delle applicazioni.
  • 🧩 Tre tipi: Test delle applicazioni, simulazione delle applicazioni e benchmarking, ognuno con le proprie attività.
  • 📏 Metriche principali: IOPS, latenza, throughput e profondità della coda: questi parametri vanno sempre letti insieme, non singolarmente.
  • 🧪 Come funziona: Definisci gli obiettivi, dimensiona il set di dati, scegli un mix realistico di operazioni di lettura/scrittura, quindi aumenta gradualmente il carico.
  • ️ Tooling: I generatori di I/O sintetici producono valori ripetibili che i comandi di copia file non possono mai raggiungere.
  • 🚫 Errori comuni: Monitoraggio del server sbagliato, saltaping svuotamento della cache e ignoramento dell'utilizzo del processore.
Scopri di più

Tutorial sui test di archiviazione: tipologie, concetti ed errori comuni

Che cos'è il test di archiviazione?

Test di archiviazione è un tipo di test del software utilizzato per verificare se l'applicazione software in fase di test memorizza i dati rilevanti nelle directory appropriate e se dispone di spazio sufficiente per evitare terminazioni impreviste dovute a spazio su disco insufficiente. È anche chiamato test delle prestazioni di archiviazione.

La tecnica si colloca sul lato non funzionale della disciplina: come altre forme di test non funzionaliNon dice nulla sul fatto che una funzionalità produca la risposta corretta, ma tutto sulla capacità del sistema di continuare a produrre risposte man mano che il volume dei dati e la pressione di I/O aumentano.

Perché testare lo storage?

La memoria di archiviazione è il livello più lento con cui la maggior parte delle applicazioni interagisce, quindi una debolezza in quest'area si ripercuote ovunque. Quattro ragioni giustificano un ciclo di test dedicato.

  • Un sistema di archiviazione lento si traduce in tempi di risposta lenti, query di lunga durata e minore disponibilità delle applicazioni.
  • La lentezza dello storage rappresenta un onere aggiuntivo per la manutenzione dell'infrastruttura server.
  • Consente di individuare i limiti pratici di archiviazione del sistema prima dell'implementazione.
  • Aiuta a capire come reagisce il sistema quando un dispositivo hardware viene sostituito o aggiornato.

Il diagramma seguente colloca il test di archiviazione in tale contesto: l'applicazione, il file system e il dispositivo fisico si trovano tutti sullo stesso percorso e un ritardo in qualsiasi punto di esso si ripercuote sull'utente.

Panoramica dei test di archiviazione che mostra un'applicazione che scrive dati attraverso il file system sul dispositivo di archiviazione

Tipi di test di archiviazione

Vengono utilizzati tre approcci, che si differenziano principalmente per quanto il carico di lavoro simulato rispecchi l'applicazione reale.

  • Test dell'applicazione: Test dell'applicazione con query di esempio in un ambiente simile a quello di produzione.
  • Simulazione dell'applicazione: Eseguire i test utilizzando un software standard che si comporta in modo simile all'applicazione di destinazione.
  • analisi comparativa: Eseguire i test utilizzando un software di benchmarking standard che genera un carico di lavoro sintetico e ripetibile.

Il primo metodo fornisce il risultato più realistico ma anche il meno portabile; il terzo fornisce valori numerici confrontabili tra dispositivi e produttori diversi, ma dice poco sul comportamento effettivo dell'applicazione.

Test comuni Concepts Coinvolto durante i test di stoccaggio

Ciascuna di queste tre tipologie corrisponde a un insieme distinto di attività, come riassunto di seguito.

Tipi di test di archiviazione Esempio di attività comuni di test di archiviazione
Test dell'applicazione Confronta i tempi di risposta OLTP
Confronta i tempi di esecuzione dei lotti
Confronta le tariffe di streaming sostenute
Simulazione dell'applicazione Testare gli IOPS di storage di picco per i database
Testare la velocità di trasmissione massima dello storage per gli ambienti di streaming dati.
Verifica la latenza di archiviazione per la messaggistica o altre applicazioni a singolo thread.
Benchmarking Test per la corruzione dei dati

Indicatori chiave nei test di archiviazione

I risultati relativi allo storage vengono riportati tramite un piccolo insieme di numeri. Interpretare uno qualsiasi di questi numeri singolarmente è il modo più rapido per giungere a una conclusione errata, poiché i valori si influenzano reciprocamente.

Metrico Cosa misura Dove conta di più
IOPS Operazioni di lettura e scrittura completate al secondo, indipendentemente dalle dimensioni Database transazionali e piccole scritture casuali
Latenza Tempo intercorso tra l'inizio e il completamento di una singola operazione di I/O Messaggistica e percorsi applicativi a singolo thread
Throughput Volume di dati trasferiti al secondo, solitamente espresso in MB/s Esecuzioni batch, backup e carichi di lavoro in streaming
profondità della coda Numero di richieste in sospeso emesse contemporaneamente Qualsiasi esecuzione che deve riflettere la concorrenza reale

La profondità della coda merita particolare attenzione. L'invio di una richiesta alla volta produce una latenza per singola richiesta accurata, ma un valore di IOPS e throughput artificialmente basso, motivo per cui un dispositivo può sembrare lento in un test e veloce in produzione, o viceversa.

ARTICOLI CORRELATI

Come eseguire il test di archiviazione

L'affidabilità di un test di archiviazione dipende dalle condizioni in cui è stato eseguito. La sequenza descritta di seguito garantisce la ripetibilità dei risultati.

  • Fase 1) Definire l'obiettivo. Bisogna stabilire se l'obiettivo del test è verificare la compatibilità del database, individuare il limite massimo di throughput o confrontare due dispositivi. Ogni obiettivo implica un carico di lavoro diverso e la loro combinazione produce risultati numerici inutilizzabili.
  • Passaggio 2) Dimensionare il set di dati in modo realistico. Un set di lavoro sufficientemente piccolo da entrare nella cache misura la cache, non lo spazio di archiviazione. Corrisponde al volume dei dati di produzione, o almeno supera di gran lunga le dimensioni della cache.
  • Passaggio 3) Scegliere il mix di lettura/scrittura e il modello. L'accesso casuale e quello sequenziale si comportano in modo molto diverso sullo stesso dispositivo, così come le configurazioni di lettura/scrittura 70/30 e le raffiche di sola scrittura. È preferibile utilizzare le impostazioni predefinite ricavate dal monitoraggio in ambiente di produzione.
  • Passaggio 4) Impostare la profondità della coda e il numero di thread. Questi parametri controllano il numero di richieste simultanee che raggiungono il dispositivo, quindi è necessario registrarli insieme a ogni risultato: un dato riportato senza di essi non è riproducibile.
  • Passaggio 5) Svuota la cache e riscalda. Elimina le cache del server e del dispositivo tra un'esecuzione e l'altra, quindi scarta il primo intervallo in modo da confrontare i valori a regime anziché quelli al primo utilizzo.
  • Passo 6) Correre abbastanza a lungo. Le sessioni di scrittura brevi nascondono il picco di scrittura che si verifica quando un SSD esaurisce il suo buffer di scrittura. Le sessioni di scrittura prolungate lo mettono in evidenza.
  • Passaggio 7) Monitorare l'intero stack. Acquisisci i dati relativi all'utilizzo del processore, della memoria e della rete, oltre ai contatori di archiviazione, in modo che un collo di bottiglia altrove non venga erroneamente interpretato come un limite di archiviazione.
  • Passaggio 8) Ripetere e confrontare. Esegui la stessa configurazione più di una volta e conserva i log; le variazioni di prestazioni tra le diverse build sono visibili solo rispetto a una baseline memorizzata.

Poiché la stessa disciplina si applica a qualsiasi misurazione basata sul carico, queste corse sono generalmente pianificate insieme a test delle prestazioni e programmato prima che la release candidate venga congelata.

Strumenti di test per l'archiviazione

Gli strumenti si dividono in due gruppi e la maggior parte dei team ha bisogno di entrambi.

  • Generatori di I/O sintetici. Utilità come filoIometer e sysbench generano un carico di lavoro descritto con precisione: dimensione del blocco, mix di lettura/scrittura, profondità della coda e durata sono tutti elementi dichiarati, in modo che un'esecuzione possa essere ripetuta esattamente su un altro dispositivo.
  • Strumenti di caricamento a livello di applicazione. Autisti come JMeter Eseguire test sull'applicazione stessa, in modo che lo storage veda lo stesso schema di accesso creato dagli utenti reali, inclusi i piani di query e il comportamento degli indici che uno strumento sintetico non può riprodurre.

OperaI contatori del sistema di archiviazione completano il quadro. Qualunque sia lo strumento che genera il carico, i dati di archiviazione devono essere letti insieme ai contatori del processore, della memoria e della rete: diverse tecniche di test dell'archiviazione, tra cui test di riferimento and test di volume, dipendono da quella visione completa per interpretare correttamente un risultato.

Errori durante l'esecuzione dei test di archiviazione

Risultati di archiviazione non validi trace tornare a un piccolo numero di errori evitabili.

  • Il monitoraggio delle prestazioni del server non è corretto, pertanto i numeri descrivono una macchina che non è oggetto di test.
  • Confrontare dispositivi di archiviazione senza prima svuotare la cache del server significa misurare la memoria anziché il disco.
  • Dimenticare di monitorare l'utilizzo del processore durante i test, il che nasconde un collo di bottiglia legato al processore dietro un sintomo apparentemente legato alla memoria di archiviazione.
  • Test delle prestazioni di archiviazione con comandi di copia file, che sono a thread singolo, assistiti dalla cache e non ripetibili.

DOMANDE FREQUENTI

Test volumetrico Il test di archiviazione aumenta la quantità di dati che un'applicazione può contenere e monitora il degrado delle prestazioni. Il test di archiviazione si concentra sul livello del dispositivo sottostante, misurando la velocità con cui i dati possono essere scritti e letti.

Ogni posizione in cui l'applicazione scrive: directory di dati, cartelle di log e temporanee, destinazioni di caricamento e percorsi di archivio. Ognuna di esse necessita di un controllo per verificare che il file venga salvato nella posizione corretta e che lo spazio libero venga segnalato correttamente.

Le metriche rimangono invariate, ma vengono aggiunti i limiti IOPS previsti, i crediti burst e i vicini rumorosi. Eseguire il test per un tempo sufficiente a esaurire i crediti burst, altrimenti il ​​valore misurato rifletterà una disponibilità temporanea anziché lo stato stazionario.

I modelli di machine learning definiscono le curve di base di IOPS e latenza normali, quindi segnalano le esecuzioni che si discostano da una soglia prima che venga superata una determinata soglia. Gli stessi modelli prevedono la crescita della capacità, in modo che l'esaurimento dei dischi venga previsto anziché rilevato in produzione.

Copilota GitHub Crea rapidamente bozze di file di lavoro, wrapper per la pulizia della cache e script per l'analisi dei risultati. Il tester fornisce comunque la dimensione del blocco, la profondità della coda e la durata, poiché questi dati provengono dal monitoraggio della produzione anziché da un modello.

Questo è un caso di test valido, non un incidente. L'applicazione dovrebbe avvisare, degradare con grazia e registrare la condizione invece di terminare. Il ripristino dallo stato di disco pieno appartiene a test di recupero.

Solitamente, lo stato della cache, la profondità della coda o la lunghezza della sequenza differivano tra di essi. Anche il condizionamento del dispositivo è importante: un SSD appena formattato scrive più velocemente di uno che è stato riempito e riscritto più volte.

Solitamente, il test viene eseguito da addetti alle prove di performance, con gli amministratori di infrastrutture o database che forniscono la configurazione del dispositivo e i modelli di accesso di produzione. Il risultato è valido solo se entrambe le parti concordano sul fatto che il carico di lavoro fosse realistico.

Riassumi questo post con: