{"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":"Resilienza nel sistema di storage Qsan","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Oggi, nell'infrastruttura IT, con l'uso pervasivo della virtualizzazione, i sistemi di archiviazione dati rappresentano il nucleo che ospita tutte le macchine virtuali. Il guasto di questo nodo potrebbe fermare completamente il funzionamento del centro di calcolo. Sebbene una parte considerevole dell'hardware dei server abbia una certa forma di ridondanza \"di default\", a causa del ruolo particolare degli SCSI all'interno del data center, ci sono requisiti elevati in termini di \"robustezza\".<\/p>\n

<\/p>\n

\"Resilienza
\n<\/a><\/noindex><\/p>\n

Il metodo pi\u00f9 efficace per garantire la ridondanza nell'IT \u00e8 l'uso di pi\u00f9 esemplari di hardware e software (nel caso pi\u00f9 semplice, la duplicazione). Certamente, l'SCSI pu\u00f2 essere interamente duplicato. E per il disaster recovery, \u00e8 proprio questo approccio che viene utilizzato. Ma non tutte le aziende possono permettersi tale soluzione. Non si tratta solo del costo raddoppiato dell'hardware, ma anche di altre spese per l'organizzazione e il supporto di una simile soluzione. <\/p>\n

<\/p>\n

Tuttavia, la possibilit\u00e0 di duplicare l'hardware non annulla la necessit\u00e0 di garantire la ridondanza a livello dei componenti. In particolare, negli SCSI si applica la ridondanza per i blocchi di alimentazione, i moduli di raffreddamento, i dischi e, ovviamente, i controller. Tutto ci\u00f2 \u00e8 gi\u00e0 da tempo diventato una prassi comune. \u00c8 difficile trovare un SCSI senza l'uso di un simile design. Qsan <\/a><\/noindex>qui non \u00e8 un'eccezione. Ma in questo articolo vogliamo parlare di ci\u00f2 che non salta subito all'occhio, ed \u00e8 soprattutto mirato ad aumentare la robustezza del sistema nel suo insieme.<\/p>\n

<\/p>\n

Moduli di raffreddamento<\/h3>\n

<\/p>\n

Molto spesso in Sistemi di archiviazione <\/a><\/noindex>contesti con chassis 2U-3U vengono utilizzati moduli combinati che uniscono blocchi di alimentazione e ventole. Da un lato, questo \u00e8 conveniente, poich\u00e9 \u00e8 necessario manutenzione solo per un'unit\u00e0. Dall'altro, se il sistema di raffreddamento dovesse guastarsi, il blocco di alimentazione potrebbe essere disattivato forzatamente per evitare il surriscaldamento. E sembrerebbe che non si tratti di una situazione critica, ma non vale la pena aggiungere vulnerabilit\u00e0 agli SCSI.<\/p>\n

<\/p>\n

Il raffreddamento nel sistema di archiviazione Qsan \u00e8 organizzato in moduli separati con sostituzione \"a caldo\", indipendenti dalle unit\u00e0 di alimentazione. Infatti, le unit\u00e0 di alimentazione hanno i propri ventilatori, progettati per raffreddare le stesse. Il modulo di raffreddamento contiene due ventilatori indipendenti che si supportano a vicenda. Ci sono due di questi moduli nel sistema di archiviazione: uno a destra e uno a sinistra, per un raffreddamento efficace di tutti i componenti. Se uno dei ventilatori smette di funzionare, tutti gli altri aumentano automaticamente la loro velocit\u00e0 per compensare la carenza di flusso d'aria. \u00c8 per questo che un guasto del ventilatore non comporta il rischio di surriscaldamento dell'intero dispositivo.<\/p>\n

<\/p>\n

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

<\/p>\n

Schema classico di connessione dei moduli di espansione<\/a><\/noindex> al sistema di archiviazione implica una topologia conosciuta come cascata. In questo caso, i controller del modulo e del sistema di archiviazione sono collegati tra di loro tramite un'unica fibra SAS. In totale, ci sono 2 fibre per un sistema a doppio controller. Se deve essere collegato un secondo modulo, viene collegato nello stesso modo al primo modulo. E cos\u00ec via. Il vantaggio di questa topologia \u00e8 la semplicit\u00e0 di implementazione nell'hardware. Lo svantaggio \u00e8 una certa vulnerabilit\u00e0 in caso di interruzione improvvisa della catena SAS, a causa di un guasto incrociato di controller non connessi tra di loro o dell'alimentazione di uno dei moduli di espansione a met\u00e0 della catena. Il risultato sar\u00e0 la perdita di accesso a una parte dei dischi e il possibile collasso del gruppo RAID, se \u00e8 \"disperso\" in pi\u00f9 case.<\/p>\n

<\/p>\n

Da guasti incrociati dei controller, Qsan ha una protezione sotto forma di collegamento logico interno tra i controller tramite il backplane del sistema di archiviazione. Cio\u00e8, il controller del sistema di archiviazione vede non solo il controller JBOD direttamente collegato a esso, ma anche il controller \"vicino\" tramite un link speciale nel backplane. Di conseguenza, se si verifica tale situazione e nessuno scollega fisicamente i cavi SAS tra il sistema di archiviazione e il modulo, l'accesso a tutti i dischi sar\u00e0 mantenuto.<\/p>\n

<\/p>\n

\"Resilienza<\/p>\n

Per proteggere le catene SAS dalle interruzioni, ad esempio a causa della mancanza di alimentazione di un'unit\u00e0 di espansione, si applica solitamente una diversa topologia di connessione: il cascata inversa. In questo caso, l'SAN si collega direttamente al primo e all'ultimo armadio della catena, ottenendo accesso ai dischi da entrambi i lati.<\/p>\n

<\/p>\n

\"Resilienza<\/p>\n

Se si desidera una protezione pi\u00f9 robusta, \u00e8 possibile costruire configurazioni pi\u00f9 ampie, utilizzando ad esempio una topologia ad albero. Oppure si pu\u00f2 complicare ulteriormente combinando le topologie menzionate. Ci\u00f2 \u00e8 reso possibile dal gran numero di connettori SAS sugli apparecchi (2 per ogni controller SAN e 5 per ogni controller JBOD) con riconoscimento automatico delle modalit\u00e0 di funzionamento in entrata\/uscita. L'importante \u00e8 che l'amministratore non si confonda. E l'SAN sapr\u00e0 come configurare correttamente la configurazione.<\/p>\n

<\/p>\n

Fast rebuild<\/h3>\n

<\/p>\n

La presenza nel sistema di dischi di riserva a sostituzione 'calda' (hot spare) aumenta notevolmente l'affidabilit\u00e0 della memorizzazione delle informazioni. Tuttavia, il semplice fatto di avere questi dischi non significa una protezione assoluta. Il problema \u00e8 che il processo di ripristino (rebuild) pu\u00f2 essere piuttosto laborioso e spesso richiede molto tempo. La laboriosit\u00e0 \u00e8 dovuta all'accesso continuo ai dati principali. Cio\u00e8, mentre il sistema continua a funzionare, deve anche copiare i dati su un nuovo disco. E la durata del rebuild dipende direttamente dalla capacit\u00e0 del disco e dalle sue caratteristiche di velocit\u00e0. Poich\u00e9 il sistema non ha informazioni sullo spazio effettivamente occupato sui dischi, durante il rebuild copia semplicemente tutto: blocco per blocco. <\/p>\n

<\/p>\n

Di conseguenza, il ripristino di un disco moderno di grande capacit\u00e0 superiore a 10 TB sotto un carico significativo sull'SAN pu\u00f2 facilmente richiedere una settimana o pi\u00f9. Si deve anche tenere presente che durante il rebuild aumenta notevolmente la probabilit\u00e0 di guasti su altri dischi a causa dell'aumento del carico su di essi. Questo pu\u00f2 rappresentare un serio pericolo, ad esempio, in caso di utilizzo di RAID5.<\/p>\n

<\/p>\n

Come soluzione a questo problema, molti sviluppatori di SAN hanno cercato di accelerare il processo di ripristino. Possono essere utilizzati vari approcci, ma la sostanza \u00e8 una: copiare durante il rebuild solo i blocchi realmente occupati. Qsan non \u00e8 rimasta indifferente a questo problema. L'SAN di questo fornitore, con l'opzione attivata Fast Rebuild<\/a><\/noindex> il sistema tiene traccia dei blocchi utilizzati per la registrazione, in modo da avere la possibilit\u00e0, in caso di guasto del disco, di copiare su un nuovo supporto solo quelli.<\/p>\n

<\/p>\n

\"Resilienza<\/p>\n

L'opzione Fast Rebuild non \u00e8 attivata per impostazione predefinita durante la creazione di nuovi volumi, poich\u00e9 il suo utilizzo influisce sulle prestazioni, soprattutto durante le operazioni di scrittura casuale, perch\u00e9:<\/p>\n

<\/p>\n

    \n
  1. \u00c8 necessario monitorare la scrittura nei blocchi;<\/li>\n
  2. Durante il rebuild non viene effettuato il ricalcolo dei checksum per lo spazio non utilizzato, quindi quando si registra nuovamente in quest'area \u00e8 necessario prima \"inizializzarlo\".<\/li>\n<\/ol>\n

    <\/p>\n

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

    <\/p>\n

    In conclusione<\/h2>\n

    <\/p>\n

    Ogni produttore di storage sottintende che i propri dispositivi siano affidabili. E se non ci sono errori fatali durante lo sviluppo dei dispositivi e una straordinaria tendenza al risparmio nel processo di produzione e collaudo, si pu\u00f2 sostanzialmente essere d'accordo con il fornitore. Tuttavia, bisogna comprendere: <\/p>\n

    <\/p>\n