Newsgroup: it.comp.os.linux.sys
Titolo: Sostituzione PERC

Qualcuno di voi ha mai sostituito una controller PERC (su un server in produzione si intende) con un modello più performante, sempre PERC? 
 
E' una operazione supportata? Stando ad Internet sembra di si.
 
Ho contattato il forum di supporto DELL per ulteriori chiarimenti, ma non mi fido molto, l'ultima volta (come da mio thread su icols) mi han detto che se la controller indica tutto "Ok" significa che è tutto ok. Bene, ho perso tutti i dati a causa di 2 dischi guasti non identificati (avevo 1 disco rotto, l'ho sostituito, ignorando ci fosse un secondo disco rotto nel RAID1). La controller nemmeno se ne è accorta.
 
Vorrei cambiare una 310 in 710, *senza* perdere dati. E' fattibile ?

 Vorrei cambiare una 310 in 710, *senza* perdere dati. E' fattibile ?
 
Non so risponderti nello specifico. Ho cambiato nel tempo qualche 
decina di Perc, e sono sempre riuscito a reimportare la configurazione 
RAID dai dischi. Però ho usato quasi sempre lo stesso modello di 
controller. All'epoca mi ricordo di aver importato con successo il RAID 
da diversi modelli della famiglia 4.
 
La cosa importante è partire con il nuovo controller *senza dischi* e 
cancellare ogni eventuale configurazione residua. A freddo poi 
inserisco i dischi e di solito o il controller non batte ciglio e 
riconosce in automatico le LUN, oppure mal che vada devo dirgli di 
importare la foreign config (caso raro a dir il vero).
 
Ad ogni modo le prime volte ho sempre testato in apposito ambiente.
 
Più che altro mi chiedo, avendo letto le tue peripezie con il RAID10, 
se utilizzi dischi certificati Dell (dalla versione firmware non mi 
sembrava).
 
 
-- 
Gabriele
 

 sembrava).
 
Nel caso specifico, no. Ma sono dischi "origin storage" forniti con tanto di tray compatibile e non mi hanno mai dato problemi (ne avrò cambiati a decine e decine nel corso degli anni, tutti correttamente rilevati come guasti)
 
Per me è la controller, in questo caso, ad essere impazzita.
 
Per quanto riguarda la sostituzione: seguo un altra strada: migro tutte le VM del server in questione (tranne 2, le più grosse) su un altro, scaricandolo al massimo. Una volta scarico i problemi di performance si dovrebbero risolvere (o quanto meno limitare la massimo) da soli. Così facendo avrò tutto il tempo per spostare (brutalmente con rsync) i due server rimasti (100GB + 150GB) tra due o più macchine splittando utenti qua e la. Che 6 dischi SAS 15K in RAID-5 non riescano a reggere 2 VM con 500-600 siti l'uno, mi pare ridicolo, per quanto economica possa essere la controller. Ho VM ben più trafficati e meno corazzati dal punto di vista HW e con RAID-6 (meno performante di un RAID-5, in scrittura)
 
Svuotato il server, cambio controller, piallo tutti i dischi e riparto.
 
Domandina OT: qualche strumento per testare in maniera approfondita i dischi? Quelli nel server guasto potrebbero essere funzionanti, ma non so quali. Li vorrei testare tutti, doverli sostituire a prescindere costerebbe un patrimonio, circa 400 euro l'uno e sono 6. Magari rotti son solo 2.

Per i test dei dischi hai diverse strade:
- offline - cd bootabile Dell Diagnostic
- offline - tool specifico del produttore del disco
- online - patrol read
- online - un semplice dd in lettura per rilevare semplicemnte la 
presenza di punctured stripes (avrai nel caso degli IO error)
 
In ogni caso sarebbe utile vedere cosa riporta OpenManage (in 
particolare sense data e la flag failure predicted).
 
Rispetto alle performance RAID 5/6 (a parità di dischi) devi anche 
considerare quanta cache ha il controller, se ha una batteria tampone, 
e se è attivo/attivabile il write back.
 
-- 
Gabriele
 

 e se è attivo/attivabile il write back.
 
Il writeback non è attivo e non ho batteria tampone (è una H310) ma le performance sono comunque talmente basse da risultare anomale.
Ho server con batteria fuori uso (in attesa di sostituzione) quindi con writeback disattivato che comunque sono più performanti.

 Nulla. Tutto OK per lui.
 
Strano ma se lo dici ci credo.
 
 
-- 
Gabriele
 

 importare la foreign config (caso raro a dir il vero).
 
Stavo pensando: ho un server con RAID-1 da rimpiazzare.
Avendo un server a disposizione, con controller RAID vera (H730), avrei ipotizzato questi due tentativi (prima della classica soluzione: "spostamento manuale di tutti i dati sul nuovo server"):
 
a) spengo il server attuale. metto 1 dei due dischi nel server nuovo, faccio il boot. Se parte, inserisco anche il secondo disco e lui fa il rebuild. A questo punto la migrazione dell'intero server, compreso la controller, è terminata
 
b) aggiungo un terzo disco al server attuale. Faccio fare il rebuild su un RAID-1 a tre dischi. Estraggo il terzo disco. Spengo. Inserisco il terzo disco nel server nuovo e guardo se parte. Se parte, inserisco l'altro disco.
 
La soluzione "b" è più lunga, ma se tutto dovesse andare in vacca, mi permette di avere comunque un disco funzionante sul server vecchio (che funziona). Basta riaccenderlo e via andare....
 
Idee migliori ? Vorrei evitare di spostare entrambi i dischi e ritrovarmi con il nuovo server che non li riconosce e per qualsivoglia motivo mi distrugge il raid con tutti i dati dentro ed allo stesso tempo evitare il più possibile il rebuild da dischi vecchiotti (vuoi mai che mi si spacca il disco con i dati mentre rebuilda sul disco nuovo.....)
 
Soluzione "c", la più costosa: faccio un RAID-1 a 4 dischi sul server attuale.
Spengo. Sposto una coppia di dischi nel nuovo server. Se parte e funziona, sono a cavallo, il nuovo server è già in sync e non deve fare alcun rebuild, poi converto a RAID-6.

Potresti fare anche una variante delle b):
 
- spengo il vecchio server
- sfilo undo dei due dischi
- inserisco un nuovo disco, accendo e faccio partire la rebuild
- sul nuovo server vedo se riesco ad importare il RAID1 degradato con 
un disco solo
 
 
Come extrema ratio (non te lo auguro, ma ci sono passato), seganti 
tutti i dati salienti del RAID (posizione, tipologia, stripe size, ecc 
...). Con le vecchie PERC sono stato in grado di ripartire impostando 
da zero la configurazione del RAID su dischi già in uso, avendo 
l'accortezza di non fare l'inizializzazione.
 
Se ben ricordo megacli ti permette in ogni caso di salvare ed esportare 
la configurazione esistente (e di reimportarla alla bisogna).
 
 
-- 
Gabriele
 

 la configurazione esistente (e di reimportarla alla bisogna).
 
Hai una guida senza che giro tutta Internet ?

 Hai una guida senza che giro tutta Internet ?
 
Guarda ogni volta mi guardo l'help da cli e cerco di ricordarmi le 
sintassi corrette, peraltro non troppo complicate, comunque qui:
 
http://serverfault.com/questions/665106/megacli-lost-virtual-disk-raid-configuration
 
 
 
trovi una un esempio, dove si parla anche di ricostruire il RAID senza 
inizializzare, come ti accennavo l'altro giorno.
 
Uno cheat sheet più ampio lo trovi ad esempio qui:
 
https://wiki.hetzner.de/index.php/LSI_RAID_Controller/en
 
 
 
-- 
Gabriele
 

 effettiva del server.
 
Supponiamo che la migrazione del volume non sia supportata.
Come cambieresti la controller di 1 server con qualcosa di più moderno?
 
Non c'è altra soluzione che backup, sostituzione e restore ?

 Non c'è altra soluzione che backup, sostituzione e restore ?
 
Penso di no ... forse trattandosi di un RAID1 potresti configurare il 
nuovo server in JBOD con un disco solo. Onestamente non ho mai capito 
su quale porzione del disco le PERC salvino la conf del RAID. Sarei 
curioso se qualcuno conoscesse la risposta.
 
 
 
-- 
Gabriele
 

 direi H700 o superiore in base alla generazione del server Dell.
 
Ultimamente anche io.
 
Ma ammetto che lo stress psicologico è aumentato e non sono più lucido, ho paura di sbagliare (ho già perso un intero server a causa del cambio disco errato). Il mio timore più grosso è:
 
come diavolo rimetto in piedi un nodo XenServer se è dotato di controller di merda (leggasi H200) ? Non posso spostare i dischi su una macchina più recente, in quanto le nuove controller non supportano la H200.
 
Non posso mettere una nuova controller nel server attuale, in quanto non è supportata dal server (così dice DELL, meglio non andare ad aumentare i problemi)
 
L'unica soluzione è quella di tenere la stessa generazione di server come ricambio ma con una controller più performante. Se dovesse andare tutto in vacca, sposto i dischi su un server di pari generazione, magari dotato di H700
 
Ma è un palliativo, prima o poi (anzi, mi sa già da ora) la H700 uscirà dal supporto, DELL non avrà più componenti di ricambio etc etc.
 
Come ci si tutela in questi casi, dove il vendor cambia generazione di server praticamente ogni 18-24 mesi ? Quasi-quasi nemmeno il mio cellulare cambio così di frequente.
 
 
P.S: con supermicro questo problema non c'è: 3 anni fa ho acquistato 3 server con determinate caratteristiche hardware. Sono tutt'ora in vendita e supportati, sia come barebone, sia come componenti sfusi. Sempre 3 anni fa ho acquistato ben 8 server DELL. Sono tutt'ora usciti di generazione e DELL non ha nemmeno più i dischi da inviare come parti sfuse, solo come ricambi in caso di guasto.

 Come ci si tutela in questi casi, dove il vendor cambia generazione di server praticamente ogni 18-24 mesi ? Quasi-quasi nemmeno il mio cellulare cambio così di frequente.
 
Cosa ti vieta di slegarti del tutto dall'hardware utilizzando una 
soluzione del genere?
 
https://xen-orchestra.com/blog/xenserver-vm-continuous-replication/
 
 
Questo è solo un esempio, l'hint è sul concetto non sullo strumento.
 
-- 
Bye
Gianfranco Bartolini
(gianfranco punto bartolini at tiscali punto it)

 Questo è solo un esempio, l'hint è sul concetto non sullo strumento.
 
L'idea è ottima, anzi, è più o meno simile a ciò che stavo pensando io.
Nello specifico, non uso Xen Orchestra, hai idea di come funzioni quella cosa li ? Fa uso di qualche software particolare che posso installare manualmente ?
 
Io pensavo a lvmsync o analogo, come blocksync.py. sarei propenso a quest'ultimo, il primo richiede Ruby, che nel Dom0 di Xen non c'è.
 
Il secondo non ha dipendenze. In pratica farei uno snapshot di una VM funzionante, esporto come XVA lo snapshot (forse prima devo creare una VM a partire da tale snapshot, poco importa), copio l'XVA sul nuovo host e importo l'XVA creando la nuova VM che manterrò spenta.
 
Questo porterà via alcune ore di tempo, ma sarà fatto tutto a caldo, senza disservizi alla VM.
 
Una volta spostato il "grosso", con lvmsync o blocksync.py sincronizzo le variazioni tra i due block device. Spengo la VM originale per preservare la consistenza dei dati, sincronizzo sul nuovo server, accendo il nuovo.
 
Trasferendo solo le variazioni, dovrei riuscire a far tutto in poco tempo.
 
Idee migliori ?

 Nello specifico, non uso Xen Orchestra, hai idea di come funzioni quella cosa li ? Fa uso di qualche software particolare che posso installare manualmente ?
 
Non ho esperienza diretta non usando soluzioni Xen-based ma ne ho sempre 
sentito parlare bene.
 
Per tutte le valutazioni c'è sia la trial sia i sorgenti 
(
https://xen-orchestra.com/docs/from_the_sources.html
) sia i forum, ma 
se devi operare su ambienti di produzione critici personalmente non 
andrei ad inventarmi soluzioni creative fatte in casa, molto meglio 
affidarsi a chi fa questo di mestiere, ci ha già sbattuto la testa e 
realizzato una soluzione funzionante con tanto di supporto a 
disposizione, sempre nell'ottica di togliersi il più possibile di dosso 
le grane invece di andarsele a cercare.
 
Se poi è solo una questione di costi:
http://www.xenserver-backup.com/
 
 
Direi che per 69 dollari australiani una prova si può anche fare


 Direi che per 69 dollari australiani una prova si può anche fare
 
Non è una questione di costì, bensi di versioni.
La procedura di XO richiede XS 6.5, io devo migrare server dalla 5.5.
 
Considerato che ho delle VM anche di 200GB di dati, esportarle via rete gigabit (che faccio spesso, con VM più piccole) richiederebbe comunque un fermo di minimo 2000 secondi (supponendo un trasferimento ottimale a 100MB/s su lan giga).
 
Se fosse possibile fare un incrementale, sarebbe perfetto.
Potrei anche fare a due step come fatto in passato, ma si complica parecchio:
 - snapshot della VM in esecuzione
 - esporto lo snapshot
 - creo una nuova VM dallo snapshot partendo dal nuovo nodo
 - avvio senza le NIC configurate
 - cambio gli IP
 - spengo i servizi sulla vecchia VM
 - rsync di tutto (trasferirà solo le differenze tra la creazione dello snapshot e l'avvio di rsync, quindi circa 1 ora di attività)
 - rsync di tutto per la seconda volta (trasferirà solo le differenze dal primo rsync, si presume pochi minuti)
 - ripristino gli IP sulla nuova VM
 
Comincia ad essere un discreto sbattimento, sopratutto non sono certo di cosa possa succedere rsyncando tutto il server brutalmente. In teoria non succede niente, dato che le due VM sono cloni perfetti. Dovrei cambiare solo i MAC-Address delle schede di rete, dato che la nuova VM ne avrà di diversi.
 
Potrei provare su una VM di servizio e vedere quanto tempo ci mette a fare l'rsync di tutto. Sicuramente meno che trasferire i 200GB di botto.
 
 
Anyway, ho un altro problema, sempre inerente gli storage.
Avendo anche server supermicro, con RAID LSI2208 integrati, mi si presenta lo stesso problema delle PERC: in caso di catastrofe (MB non funzionante, controller integrata impazzita, bla bla bla), come ripristino l'operatività del server in tempo zero o prossimo allo zero?
Pensavo di tenere una LSI2208 (sempre supermicro) di scorta in versione PCI, metterla su un server con MB compatibile con tale slot PCI e spostare i dischi. Avendo lo stesso chip, IN TEORIA l'operazione può solo andare a buon fine.
 
I tecnici di supermicro mi han suggerito di non procedere in questo modo ed evitare di importare il raid di una controller integrata in una controller PCI, anche se dello stesso modello (il perchè non me l'hanno detto, sono in attesa di risposta). Han suggerito di procedere con la migrazione verso una MB identica in termini di BIOS e firmware e sempre con la stessa controller RAID integrata (identica come firmware). Mi potrebbe star bene, ma tra qualche anno quando la controller o la MB non saranno più disponibili? Resto comunque bloccato come con le PERC.
 
In poche parole, vorrei sapere come tutelarmi dalla dismissione dell'hardware da parte del vendor, non ho un giro tale di hardware da permettermi il ricambio generazionale ogni 2-3 anni. Ho server tutt'ora operativi di circa 5-6-7 anni e devo comunque poter ripristinare il servizio in caso di disastro. Il problema sono solo le controller RAID, CPU, Dischi etc etc si cambiano

 In poche parole, vorrei sapere come tutelarmi dalla dismissione dell'hardware da parte del vendor, non ho un giro tale di hardware da permettermi il ricambio generazionale ogni 2-3 anni. Ho server tutt'ora operativi di circa 5-6-7 anni e devo comunque poter ripristinare il servizio in caso di disastro. Il problema sono solo le controller RAID, CPU, Dischi etc etc si cambiano
 
A mio avviso sempre con lo stesso sistema, replica costante a caldo 
delle vm su secondo sito/hardware sempre online, di qualsiasi specifica 
e marca sia. Salti a piè pari il vendor lock-in.
 
Le ipotesi che hai citato tu potrebbero in via di massima essere anche 
percorribili ma a parte lo sbattimento e la necessità di presidio sul 
posto (non sempre scontato), ti tutelano solo in caso di problemi sul 
controller o sui dischi, non sul resto dell'hardware.


 controller o sui dischi, non sul resto dell'hardware.
 
Il resto dell'hardware non è un problema. Virtualizzando, le VM non vendono l'hardware fisico, quindi faranno sempre il boot.
Il problema sarebbe il boot di XenServer su hardware differente, ma dubito fortemente che faccia problemi in caso di cambio di CPU (pur sempre Intel, non cambio architettura) o in caso di cambio di tipologia di ram
 
Se si spacca il server, sposto i dischi su qualcosa di simile e riparto.
Il problema è che le controller non leggono il RAID creato con il precedente server. Questo è *IL* problema. Il resto in qualche modo lo si risolve (cambio la singola CPU, cambio il modulo di RAM, etc etc). Se salta l'intera M/B, cambio l'intero server.
 
Il problema è solo il RAID creato con una controller hardware che magari non è più in produzione ed il modello successivo non importa la configurazione del modello precedente.

 Il problema è solo il RAID creato con una controller hardware che magari non è più in produzione ed il modello successivo non importa la configurazione del modello precedente.
 
Per intenderci, mi è stato comunicato (da supermicro, non da terzi) che questa scheda:
http://www.supermicro.com/products/accessories/addon/AOC-S3108L-H8iR.cfm
 
potrebbe non leggere correttamente un RAID creato con una controller integrata, anche se dello stesso identico chipset.
 
In pratica la LSI3108 PCI potrebbe non leggere la LSI3108 integrata.
 
A me sa tanto di stronzata planetaria, o del supporto supermicro, o di progettazione delle schede. Che il cambio del solo form-factor non permetta la lettura della configurazione è una cosa difficile a cui credere. Una LSI3108 è sempre una LSI3108, indipendentemente dalla forma.

 Il problema è solo il RAID creato con una controller hardware che magari non è più in produzione ed il modello successivo non importa la configurazione del modello precedente.
 
Appunto, quindi *non* risolvi il problema. Con la replica su secondo 
server invece sì.


 A me sa tanto di stronzata planetaria, o del supporto supermicro, o di progettazione delle schede. Che il cambio del solo form-factor non permetta la lettura della configurazione è una cosa difficile a cui credere. Una LSI3108 è sempre una LSI3108, indipendentemente dalla forma.
 
O anche di differenze di bios che vanno a scrivere metadati differenti 
sui dischi, difficile saperlo


 sui dischi, difficile saperlo
 
I metadati non li scrive mica il bios sul disco ma la controller raid.
Se la controller è la stessa e cambia solo il formfactor, i metadati sono scritti in egual modo. Altrimenti sarebbero due controller diverse.

 guasterebbe
 
Non sempre è possibile.
Considerato oltretutto che bisogna fare un reboot ad ogni aggiornamento.
 
Nel mio caso la soluzione migliore è spostare tutte le VM, piallare il nodo attuale e ripartire da zero. Ma non so come spostarle arrecando il minor disservizio possibile, con l'attuale infrastruttura.

 Se la controller è la stessa e cambia solo il formfactor, i metadati sono scritti in egual modo. Altrimenti sarebbero due controller diverse.
 
Il controller fa quel che gli dice il bios di fare
A parità di chipset puoi avere bios differenti e quindi comportamenti 
differenti


 Nel mio caso la soluzione migliore è spostare tutte le VM, piallare il nodo attuale e ripartire da zero. Ma non so come spostarle arrecando il minor disservizio possibile, con l'attuale infrastruttura.
 
Server "muletto" d'appoggio e sw di replica vm in trial? Non è che ci 
siano così tante altre strade


 differenti
 
Quindi in condizioni normali, tutti coloro che dovessero cambiare la controller raid causa guasto, sarebbero in braghe di tela perchè la nuova controller, stesso modello della vecchia ma ubicata su un server più recente, potrebbe non essere compatibile con la vecchia? Mah.
 
Io dubito fortemente che il BIOS decida dove posizionare i metadati, è compito della controller decidere cosa e come scrivere. Anche perchè la configurazione del RAID la si fa tramite firmware della controller, non tramite BIOS, il BIOS da questo punto di vista non ne sa nulla.
 
Io parlo della *STESSA* controller, cambia solo il form-factor.
 
Nel caso in questione, la LSI3108 PCI-E è presente anche in versione integrata, 
sempre su PCI-E, stando al disegno a blocchi della scheda madre. Stesso socket, stesso chipset.
 
Però, se il problema è il passaggio da integrata a standalone, risolvo presto: uso solo schede standalone e se si spaccano, sostituisco la scheda con una spare identica. Questo *non può* non funzionare, altrimenti saremmo tutti f0ttuti in caso di guasto ad una controller sapendo di non poterla sostituire con una gemella.
 
P.S: Io per BIOS intendo il BIOS del computer, non il *firmware* della controller, questo lo do per scontato.

 Quindi in condizioni normali, tutti coloro che dovessero cambiare la controller raid causa guasto, sarebbero in braghe di tela perchè la nuova controller, stesso modello della vecchia ma ubicata su un server più recente, potrebbe non essere compatibile con la vecchia? Mah.
 
No ci siamo fraintesi, io mi riferivo al bios del controller, non della 
scheda madre, anche se nel caso dei controller integrati a volte le due 
cose si sovrappongono.
 
Può essere che nel caso specifico del tuo server supermicro il bios del 
controller integrato sia differente da quello su scheda separata a 
parità di chipset, da qui le riserve del supporto tecnico (che 
certamente sembrano più pippe per pararsi in caso di problemi che 
impedimenti reali).


 impedimenti reali).
 
In realtà il firmware è il medesimo e lo si flasha con lo stesso identico file.
C'è poi il piano B (quello al quale sto puntando), ovvero la controller (sempre identica) in versione PCI-E mezzanine, che si installa sempre in uno slot PCI-E ma non accessibile dall'esterno. Questa per intenderci:
 
http://www.supermicro.com/products/accessories/addon/AOM-S3108M-H8.cfm
 
 
Adesso son curioso di sapere con quale ragionamento Supermicro mi potrà dire che la controller di cui sopra non è compatibile con quest'altra:
http://www.supermicro.com/products/accessories/addon/AOC-S3108L-H8iR.cfm
 
 
stesso firmware, stesse modalità di flash, stesso chipset, stesso socket.
Cambia solo la forma, la prima ha il socket PCI-E "sulla pancia" essendo una sorta di mezzanine, la seconda ha il socket PCI-E tradizionale e richiede uno slot tradizionale nel case.
 
Attendo risposta poi si vedrà.
C'è sempre il piano C: controller PCI-E tradizionale e passa la paura (credo). se si rompe, cambio controller, ma perdo sempre uno slot. In server 1U è problematico.

 C'è sempre il piano C: controller PCI-E tradizionale e passa la paura (credo). se si rompe, cambio controller, ma perdo sempre uno slot. In server 1U è problematico.
 
Peccato che da quanto so Citrix non supporti il sw raid altrimenti avevi 
già risolto indipendentemente dal controller (a meno che non sia 
cambiato qualcosa ultimamente)


 cambiato qualcosa ultimamente)
 
e' appunto questo il problema, altrimenti sarei andato di raid sw.
 
Comunque, tanto per generare ulteriore confusione, il mio fornitore dice che posso migrare tra due controller di pari chipset ma formfactor differente.
 
supermicro dice che non si può fare.
 
LSI/Avago, nella knowledge base, dicono che è possibile migrare da qualunque megaraid 'vecchio' a qualunque più recente. (in pratica, migrazione anche tra PERC H200 a PERC H730)
 
DELL dice che non si può fare, dalla H200 si può andare solo alla H700
 
Oh, io non so più a chi dar retta.
 
Nessuno qui nel gruppo ha 2 controller Megaraid/DELL/Supermicro con cui fare un rapido test ?