Ho bisogno di un secondo controller RAID per la tolleranza agli errori?


9

Ho un server con 3 dischi rigidi installati e una capacità totale di 6. Stiamo programmando di massimizzarlo, ma il nostro consulente ha anche suggerito di ottenere un secondo controller RAID "per ridondanza" per supportare le nuove unità. Per me, questo non ha molto senso. Anche con un secondo controller RAID che esegue metà dei dischi, siamo ancora bloccati con solo la metà dei nostri dischi / programmi / dati se uno dei controller muore (il che non è molto meglio che funzionare con nessuno). Stiamo inserendo vmware sul server e ha vagamente menzionato alcune funzionalità avanzate di tolleranza agli errori / failover, ma se i dischi sono inaccessibili a causa di un controller guasto, come dovrebbe funzionare?

Contando solo le ragioni della ridondanza, non delle prestazioni, perché dovrei avere un secondo controller RAID nel mio server?


Ho visto una storia in cui l'unico controller RAID non funzionava, rendendo l'archiviazione RAID elevata su più dischi che serviva da solo non solo inutilizzabile ma anche tutti i dati lì irrecuperabili. È stato un duro colpo per l'azienda. Alla fine, la maggior parte dei dati è stata ricostruita dai file trovati nelle workstation. Peccato totale. Rispecchia sempre i dati sul cluster di dischi indipendente con ovviamente un altro controller. Non dare mai per scontato che RAID 6 ti salverà la vita in tutti i casi se fai affidamento su una singola piccola scheda che diventa calda a 80 ° C durante il funzionamento per molti anni 7/24.
h22,

Risposte:


11

In un design ad alta disponibilità a scatola singola, quindi sì, si vorrebbe un secondo controller, idealmente anche su un secondo bus. Ma questo tipo di approccio ha lasciato il posto a un design più economico basato sul clustering in cui un guasto a una scatola non interrompe il servizio. Quindi dipende se si prevede di utilizzare un ambiente cluster o fare affidamento su una singola casella. Anche se la tua risposta è quest'ultima con doppi controller può essere visto come aggiungere ulteriore complessità e forse essere eccessivo.

modifica - in base al tuo commento sull'utilizzo di ESXi sull'altra tua domanda, dovrei dire che il suo clustering è favoloso , abbiamo molti cluster a 32 vie che funzionano alla grande.


AFAIK, non useremo il clustering. Come mi gioverebbe un secondo controller in una singola scatola? Esiste un failover del controller?
Bigbio2002,

1
Non in un mondo ESX / ESXi no - ne andrebbe bene uno solo, assicurati di avere un controller che crei un array R10 grande di tutti e 6 i dischi ma ti consenta di creare questi dischi logici da 2 TB (o meno) ok. La serie Pxxx di HP ti consente di farlo.
Chopper3,

7

Un secondo controller RAID che viene utilizzato attivamente non è per ridondanza. Solo se si tratta di un controller di standby a freddo in cui si commutano tutti i dischi quando muore il primo. Quindi si ha ridondanza (per il controller). Ma attenzione a farlo, come pubblicato qui .

Quindi il RAID è per la ridondanza dei dischi che porta a un singolo punto di errore nel controller. Avere un secondo controller (non utilizzato) può risolvere questo come si potrebbe passare tutto il disco a quello nuovo. Se funziona dipende da altri fattori ...

Non sono madrelingua, ma per me la "tolleranza agli errori" è qualcosa di diverso dalla "ridondanza". Qualcuno che parla inglese può aiutarmi qui?


La ridondanza è un modo per raggiungere la tolleranza d'errore :). Stavo cercando qualcosa sulla falsariga di un cold-standby o di un controller di failover. È una funzionalità supportata o dovrei scambiare manualmente le carte?
Bigbio2002,

Non ho mai visto un controller in cui la commutazione dei dischi viene eseguita automaticamente. Ciò è dovuto al fatto che non l'ho cercato o perché non riesco a immaginare come dovresti collegare i cavi tra un disco e due controller.
mailq

Le unità a doppia porta sono abbastanza comuni negli ambienti aziendali (pensate agli scaffali SAN) - ma i prezzi aumentano di un fattore 2 o 3, ovviamente.
adattamento

3

Su un singolo box, sono effettivamente necessari due controller RAID, collegati a due diversi complessi root PCI-E, per avere la ridondanza completa del sottosistema I / O. Ciò può essere ottenuto con due diverse configurazioni:

  • utilizzare costosi dischi SAS a doppia porta, con ogni collegamento SAS collegato a un controller diverso. In questo modo, ciascun controller è collegato a ciascun disco. Ovviamente, i due controller non possono operare contemporaneamente sui dischi; è necessaria una qualche forma di blocco / recinzione per coordinare l'accesso ai dischi. SCSI ha alcune disposizioni speciali per fornire il meccanismo di scherma necessario, ma queste devono essere coordinate da un software appropriato. In altre parole, non puoi semplicemente collegare un disco a due controller e chiamarlo un giorno; piuttosto, è necessaria un'adeguata configurazione del software per farlo funzionare senza problemi;
  • utilizzare dischi SAS / SATA single link normali ed economici, collegandone la metà a ciascun controller. Ad esempio con 6 dischi, è necessario connettere 3 dischi a un controller e 3 dischi a un altro controller. Su ciascun controller, configurare un array RAID come necessario (ad esempio: RAID 5 o RAID1). Quindi, a livello di sistema operativo, è possibile configurare un RAID software tra i due array di dischi, ottenendo la ridondanza completa dell'array. Sebbene più economica, questa soluzione ha l'ulteriore inconveniente di dimezzare efficacemente la capacità di archiviazione (a causa del livello RAID1 del software).

Un problema chiave con entrambi gli approcci è che non si dispone di ridondanza completa del sistema: un problema della scheda madre / CPU può far crollare l'intero sistema, indipendentemente da quanti controller / dischi si hanno.

Per questo motivo, questo tipo di ridondanza in una scatola viene raramente utilizzato di recente (a parte quello nelle distribuzioni SAN di fascia medio / alta); piuttosto, il clustering / il mirroring della rete sta guadagnando ampia trazione. Con il clustering (o il mirroring della rete) si ha una ridondanza completa del sistema, poiché un singolo sistema guasto non può negare l'accesso ai dati. Ovviamente il clustering ha le sue insidie, quindi non è un proiettile argento / facile, ma in alcune situazioni i suoi vantaggi non possono essere negati. Inoltre, puoi anche utilizzare il mirroring di rete asincrono per avere una ridondanza dei dati quasi in tempo reale su una posizione geograficamente diversa, in modo che un singolo evento catastrofico non causi danni ai tuoi dati.


Con alcuni tipi di dati la copia che viene aggiornata solo per metà (perché la sincronizzazione non è riuscita a metà strada) potrebbe essere inutilizzabile. Un database è l'esempio tipico, ma anche vari codici sorgente e set di dati con molti piccoli file strettamente correlati l'uno dall'altro.
h22,

Dipende dal meccanismo di replica sottostante. DRBD, ad esempio, abilita l'uso di una replica sincronizzata completa (protocollo C) o quasi completa (protocollo B). Ciò significa che quando una scrittura viene riconosciuta sull'host di origine, viene effettivamente commessa sull'host remoto anche In altre parole, le barriere di scrittura vengono rispettate su entrambi gli host). Con tale garanzia, qualsiasi solido filesystem / database dovrebbe recuperare senza problemi.
shodanshok,

Sì, alcuni database supportano la replica e anche alcune altre applicazioni. Questi sono ovviamente molto più facili da lavorare.
h22,

1

Avresti bisogno di unità SAS a doppia porta per fornire effettivo failover su più controller. Sebbene esistano, sono decisamente non raggruppati, non nella fascia di prezzo di un singolo server che ha solo memoria interna.

Si tratta di tecnologie spesso utilizzate nei sistemi SAN, in cui la morte del controller è un vero problema.

Per un singolo server senza altre funzionalità di failover, un secondo controller non guadagnerà nulla, costerà solo più soldi e fornirà al consulente maggiori profitti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.