Ciao a tutti! Con questo articolo AERODISK apre un blog su Habré. Evviva, compagni!
Precedenti articoli su Habré discutevano questioni relative all'architettura e alla configurazione di base dei sistemi di storage. In questo articolo prenderemo in considerazione una domanda che non è stata trattata in precedenza, ma che viene spesso posta: la tolleranza agli errori dei sistemi di storage AERODISK ENGINE. Il nostro team farà di tutto per garantire che il sistema di archiviazione AERODISK smetta di funzionare, ad es. romperlo.
È successo che su Habré sono già appesi articoli sulla storia della nostra azienda, sui nostri prodotti, nonché un esempio di implementazione di successo, per il quale Mille grazie ai nostri partner: le società TS Solution e Softline.
Pertanto, non formerò qui le capacità di gestione del copia-incolla, ma fornirò semplicemente collegamenti agli originali di questi articoli:
Voglio anche condividere una buona notizia. Ma inizierò, ovviamente, con il problema. Noi, in quanto venditori giovani, oltre ad altri costi, ci troviamo costantemente di fronte al fatto che molti ingegneri e amministratori semplicemente non sanno come utilizzare correttamente il nostro sistema di storage.
È chiaro che la gestione della maggior parte dei sistemi di storage sembra più o meno la stessa dal punto di vista dell’amministratore, ma ogni produttore ha le proprie caratteristiche. E qui non facciamo eccezione.
Pertanto, al fine di semplificare il compito di formare specialisti IT, abbiamo deciso di dedicare quest'anno all'istruzione gratuita. Per fare questo, in molte grandi città della Russia stiamo aprendo una rete di centri di competenza AERODISK, in cui qualsiasi specialista tecnico interessato può seguire un corso assolutamente gratuito e ricevere un certificato nella gestione dei sistemi di storage AERODISK ENGINE.
In ogni Centro di Competenza installeremo uno stand dimostrativo completo del sistema di archiviazione AERODISK e un server fisico, sul quale il nostro insegnante condurrà la formazione faccia a faccia. Pubblicheremo il programma di lavoro dei Centri di competenza non appena appariranno, ma abbiamo già aperto un centro a Nizhny Novgorod e il prossimo sarà la città di Krasnodar. Puoi iscriverti alla formazione utilizzando i link sottostanti. Ecco le informazioni attualmente note su città e date:
- Nizhny Novgorod (GIÀ APERTO – puoi iscriverti qui );
Fino al 16 aprile 2019 sarà possibile visitare il centro in qualsiasi orario lavorativo e il 16 aprile 2019 sarà organizzato un ampio corso di formazione. - Krasnodar (APERTURA PROSSIMA - puoi iscriverti qui );
Dal 9 al 25 aprile 2019 sarà possibile visitare il centro in qualsiasi orario lavorativo e il 25 aprile 2019 sarà organizzato un ampio corso di formazione. - Ekaterinburg (DI PROSSIMA APERTURA, segui le informazioni sul nostro sito o su Habré);
Maggio-giugno 2019. - Novosibirsk (seguire le informazioni sul nostro sito o su Habré);
Ottobre 2019. - Krasnoyarsk (seguire le informazioni sul nostro sito o su Habré);
Novembre 2019.
E, naturalmente, se Mosca non è lontana da te, in qualsiasi momento puoi visitare il nostro ufficio a Mosca e seguire una formazione simile.
Tutto. Abbiamo finito con il marketing, passiamo alla tecnologia!
Su Habré pubblicheremo regolarmente articoli tecnici sui nostri prodotti, test di carico, confronti, caratteristiche di utilizzo e implementazioni interessanti.
Crash test del sistema di storage AERODISK ENGINE N2, test di resistenza
ATTENZIONE! Dopo aver letto l'articolo, puoi dire: beh, ovviamente, il venditore si controllerà in modo che tutto funzioni "alla grande", le condizioni della serra, ecc. Risponderò: niente del genere! A differenza dei nostri concorrenti stranieri, siamo qui, vicino a te, e puoi sempre venire da noi (a Mosca o in qualsiasi Comitato Centrale) e testare in qualsiasi modo il nostro sistema di stoccaggio. Pertanto, non ha molto senso adattare i risultati a un’immagine ideale del mondo, perché Siamo molto facili da controllare. Per coloro che sono troppo pigri per andare e non hanno tempo, possiamo organizzare test a distanza. Abbiamo un laboratorio speciale per questo. Contattaci.
ACHTUNG-2! Questo test non è un test di carico, perché qui ci interessa solo la tolleranza agli errori. Tra un paio di settimane prepareremo uno stand più potente ed effettueremo test di carico del sistema di storage, pubblicando qui i risultati (a proposito, si accettano richieste di test).
Quindi andiamo a romperlo.
banco di prova
Il nostro stand è composto dal seguente hardware:
- 1 sistema di storage Aerodisk Engine N2 (2 controller, cache da 64 GB, 8 porte FC 8 Gb/s, 4 porte Ethernet 10 Gb/s SFP+, 4 porte Ethernet 1 Gb/s); Nel sistema di storage sono installati i seguenti dischi:
- 4 dischi SSD SAS da 900 GB;
- 12 dischi SAS 10 da 1,2 TB;
- 1 server fisico con Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2 porte FC 8 Gb/s, 2 porte Ethernet 10 Gb/s SFP+);
- 2 interruttori SAN 8G;
- 2 interruttori LAN 10G;
Abbiamo collegato il server al sistema di storage tramite switch sia tramite FC che 10G Ethernet. Di seguito lo schema dello stand.
I componenti di cui abbiamo bisogno, come MPIO e iniziatore iSCSI, sono installati su Windows Server.
Le zone sono configurate sugli switch FC, le VLAN corrispondenti sono configurate sugli switch LAN e MTU 9000 è installato sulle porte di storage, sugli switch e sull'host (come fare tutto questo è descritto nella nostra documentazione, quindi non lo descriveremo questo processo qui).
Metodologia di prova
Il piano del crash test è il seguente:
- Verifica del guasto delle porte FC ed Ethernet.
- Controllo dell'interruzione dell'alimentazione.
- Controllo dei guasti del controller.
- Verifica della presenza di guasti al disco in un gruppo/pool.
Tutti i test verranno eseguiti in condizioni di carico sintetico, che genereremo tramite il programma IOMETER. Parallelamente, eseguiremo gli stessi test, ma in condizioni di copia di file di grandi dimensioni sul sistema di archiviazione.
La configurazione dell'IOmeter è la seguente:
- Lettura/Scrittura – 70/30
- Blocco – 128k (abbiamo deciso di lavare i sistemi di storage in grandi blocchi)
- Numero di fili – 128 (che è molto simile al carico produttivo)
- Completamente casuale
- Numero di lavoratori – 4 (2 per FC, 2 per iSCSI)
Il test ha i seguenti obiettivi:
- Assicurarsi che il processo di caricamento e copia sintetico non si interrompa o causi errori in vari scenari di errore.
- Assicurati che il processo di cambio di porte, controller, ecc. Sia sufficientemente automatizzato e non richieda azioni da parte dell'amministratore in caso di guasti (ovviamente durante i failover non stiamo parlando di failback).
- Assicurarsi che le informazioni nei registri siano visualizzate correttamente.
Preparazione dell'host e del sistema di storage
Abbiamo configurato l'accesso in blocco sul sistema di storage utilizzando le porte FC ed Ethernet (rispettivamente FC e iSCSI). I ragazzi di TS Solution hanno descritto in dettaglio come farlo in un precedente articolo (). E, ovviamente, nessuno ha cancellato manuali e corsi.
Abbiamo creato un gruppo ibrido utilizzando tutte le unità che avevamo. Sono stati aggiunti 2 dischi SSD alla cache, 2 dischi SSD sono stati aggiunti come livello di archiviazione aggiuntivo (livello online). Abbiamo raggruppato 12 unità SAS10k in RAID-60P (tripla parità) per verificare contemporaneamente il guasto di tre unità nel gruppo. Un disco è stato lasciato per la sostituzione automatica.
Abbiamo collegato due LUN (uno tramite FC, uno tramite iSCSI).
Il proprietario di entrambi i LUN è il controller Engine-0
Iniziamo il test
Abilitiamo IOMETER con la configurazione sopra.
Registriamo un throughput di 1.8 GB/s ed una latenza di 3 millisecondi. Non sono presenti errori (conteggio errori totali).
Allo stesso tempo, dall'unità locale “C” del nostro host, iniziamo parallelamente a copiare due file di grandi dimensioni da 100 GB sui LUN di archiviazione FC e iSCSI (unità E e G in Windows), utilizzando altre interfacce.
Sopra è riportato il processo di copia su LUN FC, sotto su iSCSI.
Test n. 1: disabilitazione delle porte I/O
Ci avviciniamo al sistema di storage da dietro))) e con un leggero movimento della mano estraiamo tutti i cavi FC ed Ethernet 10G dal controller Engine-0. È come se passasse una donna delle pulizie con uno spazzolone e decidesse di lavare il pavimento proprio dove c'erano il moccio e i cavi (cioè il controller funziona ancora, ma le porte I/O sono morte).
Diamo un'occhiata a IOMETER e alla copia dei file. Il throughput è sceso a 0,5 GB/s, ma è tornato rapidamente al livello precedente (in circa 4-5 secondi). Non ci sono errori.
La copia dei file non si ferma, c'è un calo di velocità, ma non è affatto critico (da 840 MB/s è sceso a 720 MB/s). La copiatura non si è fermata.
Esaminiamo i registri del sistema di archiviazione e vediamo un messaggio sull'indisponibilità delle porte e sul trasferimento automatico del gruppo.
Il pannello informativo ci dice anche che non tutto va molto bene con le porte FC.
Il sistema di storage è sopravvissuto a un guasto delle porte I/O con successo.
Test n. 2. Disabilitazione del controller di archiviazione
Quasi immediatamente (dopo aver ricollegato i cavi al sistema di storage) abbiamo deciso di completare il sistema di storage estraendo il controller dallo chassis.
Ancora una volta ci avviciniamo al sistema di archiviazione da dietro (ci è piaciuto))) e questa volta tiriamo fuori il controller Engine-1, che in questo momento è il proprietario dell'RDG (a cui si è trasferito il gruppo).
La situazione in IOmeter è la seguente. L'I/O si è interrotto per circa 5 secondi. Gli errori non si accumulano.
Dopo 5 secondi, l'I/O è ripreso con circa lo stesso throughput, ma con latenze di 35 millisecondi (latenze corrette dopo circa un paio di minuti). Come si può vedere dagli screenshot, il valore Total error count è 0, cioè non ci sono stati errori di scrittura o lettura.
Diamo un'occhiata alla copia dei nostri file. Come puoi vedere, non si è interrotto, c'è stato un leggero calo di prestazioni, ma nel complesso tutto è tornato allo stesso ~ 800 MB/s.
Andiamo al sistema di archiviazione e vediamo una maledizione nel pannello delle informazioni che il controller Engine-1 non è disponibile (ovviamente, l'abbiamo ucciso).
Vediamo anche una voce simile nei log.
Anche il controller di archiviazione è sopravvissuto a un guasto con successo.
Prova n°3: Scollegamento dell'alimentazione.
Per ogni evenienza, abbiamo ricominciato a copiare i file, ma non abbiamo interrotto IOMETER.
Tiriamo l'alimentatore.
Un altro avviso è stato aggiunto al sistema di archiviazione nel pannello informazioni.
Anche nel menu sensori vediamo che i sensori associati all'alimentatore estratto sono diventati rossi.
Il sistema di archiviazione continua a funzionare. Il guasto dell'alimentatore non pregiudica in alcun modo il funzionamento del sistema di storage, dal punto di vista dell'host la velocità di copia e gli indicatori IOMETER sono rimasti invariati.
Test di interruzione di corrente superato con successo.
Prima del test finale, abbiamo deciso di riportare un po' in vita il sistema di storage, rimettere a posto il controller e l'alimentatore e anche mettere in ordine i cavi, cosa di cui il sistema di storage ci ha felicemente informato con le icone verdi nel suo pannello di integrità .
Test n. 4. Guasto di tre dischi in un gruppo
Prima di questo test, abbiamo eseguito un’ulteriore fase di preparazione. Il fatto è che il sistema di storage ENGINE fornisce una cosa molto utile: diverse politiche di ricostruzione. TS Solution ha scritto di questa funzionalità in precedenza, ma ricordiamone l'essenza. L'amministratore dello storage può specificare la priorità per l'allocazione delle risorse durante la ricostruzione. O nella direzione delle prestazioni I/O, ovvero la ricostruzione richiede più tempo, ma non vi è alcuna riduzione delle prestazioni. Oppure nella direzione della velocità di ricostruzione, ma la produttività sarà ridotta. O un'opzione equilibrata. Poiché le prestazioni di archiviazione durante la ricostruzione del gruppo di dischi rappresentano sempre un grattacapo per l'amministratore, testeremo una policy con una preferenza per le prestazioni di I/O e a scapito della velocità di ricostruzione.
Ora controlliamo l'eventuale guasto del disco. Abilitiamo anche la registrazione su LUN (file e IOMETER). Poiché abbiamo un gruppo con tripla parità (RAID-60P), ciò significa che il sistema deve resistere al guasto di tre dischi e, dopo il guasto, la sostituzione automatica deve funzionare, un disco deve prendere il posto di uno di quelli guasti nella RDG e su di essa deve iniziare la ricostruzione.
Inizio. Per prima cosa, attraverso l'interfaccia di archiviazione, evidenziamo i dischi che vogliamo estrarre (in modo da non perdere ed estrarre il disco di cambio automatico).
Controlliamo l'indicazione sull'hardware. Va tutto bene, vediamo tre dischi evidenziati.
E tiriamo fuori questi tre dischi.
Diamo un'occhiata a cosa c'è sull'host. E lì... non è successo niente di speciale.
Gli indicatori di copia (sono più alti rispetto all'inizio, perché la cache si è riscaldata) e IOMETER non cambiano molto quando si rimuovono i dischi e si avvia la ricostruzione (entro il 5-10%).
Diamo un'occhiata a cosa c'è nel sistema di archiviazione.
Dallo status del gruppo vediamo che il processo di ristrutturazione è iniziato ed è prossimo al completamento.
Nello scheletro RDG puoi vedere che 2 dischi sono in stato rosso e uno è già stato sostituito. Il disco di sostituzione automatica non è più presente; ha sostituito il terzo disco guasto. La ricostruzione ha richiesto diversi minuti, la scrittura dei file in caso di guasto di 3 dischi non è stata interrotta e le prestazioni di I/O non sono cambiate molto.
Il test di guasto del disco è stato decisamente superato con successo.
conclusione
A questo punto, abbiamo deciso di fermare la violenza contro i sistemi di stoccaggio. Riassumiamo:
- Controllo errore porta FC: riuscito
- Controllo errore porta Ethernet: riuscito
- Controllo degli errori del controller: riuscito
- Test di interruzione dell'alimentazione: riuscito
- Controllo dell'errore del disco nel pool di gruppi: riuscito
Nessuno dei guasti ha interrotto la registrazione o causato errori nel carico sintetico; ovviamente c'è stato un calo di prestazioni (e sappiamo come superarlo, cosa che faremo presto), ma dato che si tratta di pochi secondi, è abbastanza accettabile. Conclusione: la tolleranza agli errori di tutti i componenti del sistema di archiviazione AERODISK ha funzionato a livello, non sono stati riscontrati punti di guasto.
Ovviamente in un articolo non possiamo testare tutti gli scenari di fallimento, ma abbiamo cercato di coprire quelli più popolari. Vi preghiamo quindi di inviare i vostri commenti, suggerimenti per future pubblicazioni e, ovviamente, adeguate critiche. Saremo lieti di discutere (o meglio ancora, venire alla formazione, duplico il programma per ogni evenienza)! Fino a nuovi test!
- Nizhny Novgorod (GIÀ APERTO – puoi iscriverti qui );
Fino al 16 aprile 2019 sarà possibile visitare il centro in qualsiasi orario lavorativo e il 16 aprile 2019 sarà organizzato un ampio corso di formazione. - Krasnodar (APERTURA PROSSIMA - puoi iscriverti qui );
Dal 9 al 25 aprile 2019 sarà possibile visitare il centro in qualsiasi orario lavorativo e il 25 aprile 2019 sarà organizzato un ampio corso di formazione. - Ekaterinburg (DI PROSSIMA APERTURA, segui le informazioni sul nostro sito o su Habré);
Maggio-giugno 2019. - Novosibirsk (seguire le informazioni sul nostro sito o su Habré);
Ottobre 2019. - Krasnoyarsk (seguire le informazioni sul nostro sito o su Habré);
Novembre 2019.
Fonte: habr.com