{"id":36005,"date":"2019-10-31T22:09:06","date_gmt":"2019-10-31T19:09:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/otkazoustojchivost-v-shd-qsan\/"},"modified":"2019-10-31T22:09:06","modified_gmt":"2019-10-31T19:09:06","slug":"otkazoustojchivost-v-shd-qsan","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/otkazoustojchivost-v-shd-qsan","title":{"rendered":"Affidabilit\u00e0 nello storage Qsan","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Oggi, nell'infrastruttura IT, con l'uso diffuso della virtualizzazione, i sistemi di storage dati rappresentano il nucleo che ospita tutte le macchine virtuali. Un guasto di questo nodo pu\u00f2 fermare completamente il funzionamento del centro di calcolo. Anche se una buona parte dell'hardware server \u00e8 dotata di tolleranza ai guasti in una forma o nell'altra 'per impostazione predefinita', proprio a causa del ruolo particolare che rivestono gli SCSI all'interno di un data center, ci sono requisiti pi\u00f9 elevati in termini di 'resilienza'.<\/p>\n

<\/p>\n

\"Affidabilit\u00e0
\n<\/a><\/noindex><\/p>\n

Il metodo pi\u00f9 efficace per garantire la tolleranza ai guasti in IT \u00e8 utilizzare pi\u00f9 esemplari di hardware e software (nel modo pi\u00f9 semplice, una duplicazione). Certamente, gli SCSI possono essere completamente duplicati. Ed \u00e8 proprio questo approccio che viene utilizzato per il disaster recovery. Tuttavia, molte aziende non possono permettersi una soluzione di questo tipo. Non si tratta solo del costo raddoppiato dell'hardware, ma anche delle altre spese legate all'organizzazione di una tale soluzione e al suo successivo supporto. <\/p>\n

<\/p>\n

Tuttavia, la possibilit\u00e0 di duplicare l'hardware non cancella la necessit\u00e0 di garantire la ridondanza a livello di componenti. In particolare, negli storage array ci sono sistemi di ridondanza per alimentatori, moduli di raffreddamento, dischi e, naturalmente, controller. Tutto ci\u00f2 \u00e8 una realt\u00e0 consolidata. \u00c8 difficile trovare un sistema di storage senza un design del genere. Qsan <\/a><\/noindex>qui non fa eccezione. Ma in questo articolo vogliamo parlare di ci\u00f2 che non \u00e8 immediatamente visibile e che \u00e8 soprattutto finalizzato a migliorare la resilienza del sistema nel suo complesso.<\/p>\n

<\/p>\n

Moduli di raffreddamento<\/h3>\n

<\/p>\n

Molto spesso in Storage ibrido <\/a><\/noindex>i chassis da 2U-3U si utilizzano moduli combinati, che uniscono alimentatori e ventilatori. Da un lato, questo \u00e8 comodo, poich\u00e9 bisogna manutenere solo un'unit\u00e0. Dall'altro, se il sistema di raffreddamento si guasta, l'alimentatore potrebbe essere disattivato per prevenire il surriscaldamento. E sembra non crearsi una situazione critica, ma non vale affatto la pena di aggiungere vulnerabilit\u00e0 allo storage array.<\/p>\n

<\/p>\n

Il raffreddamento nel sistema di archiviazione Qsan \u00e8 organizzato in moduli separati con sostituzione a caldo, indipendenti dall'alimentatore. Infatti, negli alimentatori ci sono delle ventole progettate per raffreddare gli stessi alimentatori. Il modulo di raffreddamento contiene due ventilatori indipendenti, che si garantiscono reciprocamente. Ci sono due di questi moduli nel sistema di archiviazione, uno a destra e uno a sinistra, per un'efficace circolazione dell'aria su tutti i componenti. Se uno dei ventilatori si guasta, tutti gli altri aumentano automaticamente la loro velocit\u00e0 per compensare la carenza di flusso d'aria. Per questo motivo, un guasto del ventilatore non comporta il rischio di surriscaldamento dell'intero dispositivo.<\/p>\n

<\/p>\n

Topologia di connessione dei rack di espansione<\/h3>\n

<\/p>\n

Schema di connessione classico rack di espansione<\/a><\/noindex> La connessione a un sistema di archiviazione condivisa (SAS) implica una topologia nota come cascata. In questo caso, i controller delle scaffalature e il sistema di archiviazione condivisa sono collegati tramite un unico cavo SAS. In totale, si ottengono 2 cavi per un sistema a doppio controller. Se \u00e8 necessario collegare un secondo, viene connesso allo stesso modo alla prima scaffalatura. E cos\u00ec via. Il vantaggio di questa topologia \u00e8 la sua facilit\u00e0 di implementazione nell'hardware. Lo svantaggio \u00e8 una certa vulnerabilit\u00e0 a un'interruzione improvvisa della catena SAS, a causa di un guasto incrociato tra controller non collegati tra loro e scaffalature, o a causa dell'interruzione dell'alimentazione di una delle scaffalature di espansione nella parte centrale della catena. Ci\u00f2 comporta la perdita di accesso a una parte degli archivi e il possibile collasso del gruppo RAID, se questo \u00e8 \"distribuito\" su pi\u00f9 chassis.<\/p>\n

<\/p>\n

La protezione contro il guasto incrociato dei controller in Qsan \u00e8 fornita da un collegamento logico interno tra i controller tramite il backplane del sistema di archiviazione. Ci\u00f2 significa che il controller del sistema di archiviazione pu\u00f2 vedere non solo il controller JBOD direttamente connesso a lui, ma anche il controller \"vicino\" tramite un link speciale nel backplane. Di conseguenza, se si verifica una tale situazione e nessuno scollega fisicamente i cavi SAS tra il sistema di archiviazione e l'armadio, l'accesso a tutti i dispositivi di memoria sar\u00e0 mantenuto.<\/p>\n

<\/p>\n

\"Affidabilit\u00e0<\/p>\n

Per proteggersi da un'interruzione della catena SAS, ad esempio a causa dell'interruzione di corrente dell'armadio di espansione, solitamente si utilizza una topologia di connessione diversa \u2013 un retrocascade. In questo caso, il sistema di archiviazione \u00e8 collegato sia al primo che all'ultimo armadio nella catena, ottenendo accesso ai dispositivi di memoria come se provenissero da entrambi i lati.<\/p>\n

<\/p>\n

\"Affidabilit\u00e0<\/p>\n

Se desideri una protezione pi\u00f9 forte, puoi costruire configurazioni pi\u00f9 complesse, utilizzando, ad esempio, una topologia ad albero. Oppure puoi complicare ulteriormente combinando le topologie menzionate. Questo \u00e8 possibile grazie al grande numero di connettori SAS sui dispositivi (2 per ogni controller di storage e 5 per ogni controller JBOD) con riconoscimento automatico delle modalit\u00e0 di funzionamento in ingresso\/uscita. L'importante \u00e8 che l'amministratore non si confonda. E il sistema di storage sar\u00e0 in grado di configurare tutto correttamente.<\/p>\n

<\/p>\n

Ricostruzione veloce<\/h3>\n

<\/p>\n

La disponibilit\u00e0 di dischi di riserva con sostituzione a caldo (hot spare) aumenta notevolmente l'affidabilit\u00e0 della memorizzazione delle informazioni. Tuttavia, il semplice fatto di riservare tali dischi non garantisce una protezione assoluta. Infatti, il processo di ripristino (rebuild) \u00e8 abbastanza laborioso e spesso richiede tempo. La laboriosit\u00e0 deriva dall'accesso continuo ai dati principali, il che significa che il sistema, oltre a lavorare normalmente, deve anche copiare i dati sul nuovo disco. La durata del rebuild dipende direttamente dalla capacit\u00e0 del dispositivo di memorizzazione e dalle sue caratteristiche di velocit\u00e0. Poich\u00e9 il sistema non ha conoscenza dello spazio realmente occupato sui dischi, durante il rebuild copia semplicemente tutto: blocco dopo blocco. <\/p>\n

<\/p>\n

Di conseguenza, il ripristino di un disco moderno con una grande capacit\u00e0 di oltre 10 TB, durante un carico significativo sul sistema di archiviazione, pu\u00f2 facilmente richiedere una settimana o pi\u00f9. Inoltre, \u00e8 importante tenere a mente che durante il rebuild aumenta significativamente la probabilit\u00e0 di guasto di altri dispositivi a causa dell'aumento del carico su di essi, il che pu\u00f2 rappresentare un grave rischio, ad esempio, in un sistema RAID5.<\/p>\n

<\/p>\n

Per affrontare questo problema, molti sviluppatori di archiviazione sono impegnati ad accelerare il processo di recupero. A questo scopo possono essere adottati diversi approcci, ma il concetto \u00e8 lo stesso: copie solo dei blocchi effettivamente utilizzati durante il rebuild. Anche Qsan si \u00e8 interessata a questa problematica. Per i sistemi di archiviazione di questo fornitore, con l'opzione attivata. Fast Rebuild<\/a><\/noindex> Il sistema tiene traccia dei blocchi utilizzati per la scrittura, consentendo cos\u00ec, in caso di guasto del disco, di copiare su un nuovo supporto solo quelli.<\/p>\n

<\/p>\n

\"Affidabilit\u00e0<\/p>\n

L'opzione Fast Rebuild non \u00e8 attivata di default quando si creano nuovi volumi, poich\u00e9 il suo utilizzo influisce sulle prestazioni, specialmente durante le operazioni di scrittura casuale, perch\u00e9:<\/p>\n

<\/p>\n

    \n
  1. \u00c8 necessario tenere traccia della scrittura nei blocchi;<\/li>\n
  2. Durante il rebuild non viene effettuato il ricalcolo dei checksum per lo spazio non utilizzato, pertanto, durante una nuova scrittura in quest'area, \u00e8 necessario prima 'inizializzarla'.<\/li>\n<\/ol>\n

    <\/p>\n

    Pertanto, non \u00e8 consigliabile utilizzare Fast Rebuild per volumi, ad esempio, con database ad alta intensit\u00e0 di carico o in sistemi di videosorveglianza, dove il volume sar\u00e0 comunque riempito al 100%. Tuttavia, per server di file o di posta, questa opzione sar\u00e0 molto utile.<\/p>\n

    <\/p>\n

    In conclusion<\/h2>\n

    <\/p>\n

    Ogni produttore di sistemi di archiviazione dati (\u0421\u0425\u0414) presuppone che i propri dispositivi siano affidabili. E se non ci sono gravi errori nella progettazione dei dispositivi e una sorprendente tendenza al risparmio nei processi di produzione e testing, in generale si pu\u00f2 concordare con il fornitore. Tuttavia, \u00e8 importante comprendere: <\/p>\n

    <\/p>\n