Temperature intorno ai 100 gradi mi paiono decisamente eccessive, se non
è un errore di SMART.
Nei miei segue abbastanza la temperatura ambiente, con ovviamente
qualche grado extra.
On Tue, Feb 21, 2023 at 09:57:26PM +0100, listemessaggi@coplast.eu wrote:
[...]Strano il reset, forse un problema di cavi? Sempre e solo lo scsi target2:0:1: ? Se si è un disco in particolare che sta bloccando tutto...
No sono tutti e 4 i dischi del raid5 che a random segnalano quel problema.
Che tipo di dischi sono? Non saranno dei "green", vero?
Diego
Il 22-02-2023 08:43 Diego Zuccato ha scritto:
Che tipo di dischi sono? Non saranno dei "green", vero?
Diego
Ignorando realmente la cosa, che cosa comporterebbe il fatto di essere green >> o meno?
/paride
I "green" immagino di WD sono dischi infaustamente famosi per
distruggersi in breve tempo se usati continuativamente. Se li si installa
su un server questi tendono a guastarsi molto velocemente. Non vanno
usati su server o su dispositivi che rimangono accesi molto o 24h/7d...
Il 22-02-2023 08:43 Diego Zuccato ha scritto:
Che tipo di dischi sono? Non saranno dei "green", vero?
Diego
Ignorando realmente la cosa, che cosa comporterebbe il fatto di essere green o meno?
/paride
Il 22 febbraio 2023 10:21:41 UTC, Marco Ciampa <ciampix@posteo.net> ha scritto:
On Wed, Feb 22, 2023 at 10:04:49AM +0000, Paride Desimone wrote:
Il 22-02-2023 08:43 Diego Zuccato ha scritto:
Che tipo di dischi sono? Non saranno dei "green", vero?
Diego
Ignorando realmente la cosa, che cosa comporterebbe il fatto di essere green
o meno?
/paride
I "green" immagino di WD sono dischi infaustamente famosi per
distruggersi in breve tempo se usati continuativamente. Se li si installa >>su un server questi tendono a guastarsi molto velocemente. Non vanno
usati su server o su dispositivi che rimangono accesi molto o 24h/7d...
Apposto :-). Vedo di prendermi in Gold allora.
In data mercoledì 22 febbraio 2023 09:41:06 CET, listemessaggi@coplast.eu ha scritto:
No sono tutti e 4 i dischi del raid5 che a random segnalano quel problema.L'alimentatore come sta?
Come posso verificare? Tester?
Sono 4 dischi Western Digital da 8 Tb cadauno della serie WD Red Plus (NASware 3.0)
Non è robaccia..., non sono SSD ma non sono neanche male. Costicchiano...
Il 22 febbraio 2023 11:44:22 CET, Paride Desimone <nospam@inventati.org> ha scritto:
Il 22 febbraio 2023 10:21:41 UTC, Marco Ciampa <ciampix@posteo.net> ha scritto:
On Wed, Feb 22, 2023 at 10:04:49AM +0000, Paride Desimone wrote:
Il 22-02-2023 08:43 Diego Zuccato ha scritto:
Che tipo di dischi sono? Non saranno dei "green", vero?
Diego
Ignorando realmente la cosa, che cosa comporterebbe il fatto di essere green
o meno?
/paride
I "green" immagino di WD sono dischi infaustamente famosi per >>distruggersi in breve tempo se usati continuativamente. Se li si installa >>su un server questi tendono a guastarsi molto velocemente. Non vanno >>usati su server o su dispositivi che rimangono accesi molto o 24h/7d...
Apposto :-). Vedo di prendermi in Gold allora.
Esagerato. I Red vanno benissimo, sono pensati apposta per quegli usi
Restando valido tutto quanto discusso nello scambio di mail precedente, ma non è che il problema sia ad un altro livello? Che sia l'approccio sbagliato? Forse sto chiedendo troppo a questo server?
Questa macchina esporta via Tgt dei volumi gestiti da LVM che a suo volta si appoggia ad un raid5 software.
Si tratta di una ventina di volumi, ognuno ha 3 snapshot (backup 1 giorno prima, 2 giorni prima, ecc.), quindi l'IO su disco è effettivamente elevato. I volumi esportati via iscsi (tgt) passano per due reti in fibra 10Gb verso
i server hypervisor che fanno girare le macchine virtuali.
Di tutte le macchine virtuali si pianta solo una dove c'è un database. Effetivamente i database usano molti i dischi.
Questa macchina che funge da NAS/SAN ha una macchina fisica secondaria configurata in modo simile, ogni giorno i volumi vengono replicati sulla secondaria. Ho già provato ad eliminare questo passaggio per alleggerire il lavoro, ma non cambia, ci sono comunque eventi di qualche disco che si
ferma, e a cascata fino a iscsi e si ferma per un istante. Poi riparte
subito e da solo, ma l'Hypervisor che usa i dischi via iscsi non accetta "pause" e la macchina virtuale del database si blocca.
Vedete qualcosa di sbagliato?
Qualche idea?
On Wed, Feb 22, 2023 at 01:29:07PM +0100, listemessaggi@coplast.eu wrote:
Restando valido tutto quanto discusso nello scambio di mail precedente, ma >> non è che il problema sia ad un altro livello? Che sia l'approccioIl problema secondo me non è il RAID software ma il fatto di usare tanto
sbagliato? Forse sto chiedendo troppo a questo server?
Questa macchina esporta via Tgt dei volumi gestiti da LVM che a suo volta si >> appoggia ad un raid5 software.
Si tratta di una ventina di volumi, ognuno ha 3 snapshot (backup 1 giorno
prima, 2 giorni prima, ecc.), quindi l'IO su disco è effettivamente elevato.
I volumi esportati via iscsi (tgt) passano per due reti in fibra 10Gb verso >> i server hypervisor che fanno girare le macchine virtuali.
Di tutte le macchine virtuali si pianta solo una dove c'è un database.
Effetivamente i database usano molti i dischi.
Questa macchina che funge da NAS/SAN ha una macchina fisica secondaria
configurata in modo simile, ogni giorno i volumi vengono replicati sulla
secondaria. Ho già provato ad eliminare questo passaggio per alleggerire il >> lavoro, ma non cambia, ci sono comunque eventi di qualche disco che si
ferma, e a cascata fino a iscsi e si ferma per un istante. Poi riparte
subito e da solo, ma l'Hypervisor che usa i dischi via iscsi non accetta
"pause" e la macchina virtuale del database si blocca.
Vedete qualcosa di sbagliato?
IO su 4 dischi senza casche, neanche SAS ma soprattutto non SSD...
Qualche idea?Puoi provare ad aggiungere un disco SSD come cache LVM e vedere se
risolvi...
https://blog.jenningsga.com/lvm-caching-with-ssds/ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/enabling-caching-to-improve-logical-volume-performance_configuring-and-managing-logical-volumes
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/lvm_cache_volume_creation
altrimenti fai tutto SSD...
Grazie per i consigli, opterei per passare a tutto SSD, sarebbe anche trasparente, senza fermi, un disco alla volta.
Devo valutare i costi, 4 dischi SSD da 8 Tb cadauno costano parecchio. Consigli su cosa acquistare?
Grazie
Il 2023-02-22 18:45, Marco Ciampa ha scritto:
On Wed, Feb 22, 2023 at 01:29:07PM +0100, listemessaggi@coplast.eu
wrote:
Restando valido tutto quanto discusso nello scambio di mailIl problema secondo me non è il RAID software ma il fatto di usare tanto
precedente, ma
non è che il problema sia ad un altro livello? Che sia l'approccio
sbagliato? Forse sto chiedendo troppo a questo server?
Questa macchina esporta via Tgt dei volumi gestiti da LVM che a suo
volta si
appoggia ad un raid5 software.
Si tratta di una ventina di volumi, ognuno ha 3 snapshot (backup 1
giorno
prima, 2 giorni prima, ecc.), quindi l'IO su disco è effettivamente
elevato.
I volumi esportati via iscsi (tgt) passano per due reti in fibra
10Gb verso
i server hypervisor che fanno girare le macchine virtuali.
Di tutte le macchine virtuali si pianta solo una dove c'è un database.
Effetivamente i database usano molti i dischi.
Questa macchina che funge da NAS/SAN ha una macchina fisica secondaria
configurata in modo simile, ogni giorno i volumi vengono replicati
sulla
secondaria. Ho già provato ad eliminare questo passaggio per
alleggerire il
lavoro, ma non cambia, ci sono comunque eventi di qualche disco che si
ferma, e a cascata fino a iscsi e si ferma per un istante. Poi riparte
subito e da solo, ma l'Hypervisor che usa i dischi via iscsi non
accetta
"pause" e la macchina virtuale del database si blocca.
Vedete qualcosa di sbagliato?
IO su 4 dischi senza casche, neanche SAS ma soprattutto non SSD...
Qualche idea?Puoi provare ad aggiungere un disco SSD come cache LVM e vedere se
risolvi...
https://blog.jenningsga.com/lvm-caching-with-ssds/
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/enabling-caching-to-improve-logical-volume-performance_configuring-and-managing-logical-volumes
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/lvm_cache_volume_creation
altrimenti fai tutto SSD...
Se il problema è l'accesso al disco lento per me fai prima a mettere una cache SSD ai volumi LVM; ...io avrei portato anche il raid su LV ma questo è un altro discorso ;)
Piviul
Il 23/02/23 13:16, listemessaggi@coplast.eu ha scritto:
Grazie per i consigli, opterei per passare a tutto SSD, sarebbe anche trasparente, senza fermi, un disco alla volta.
Devo valutare i costi, 4 dischi SSD da 8 Tb cadauno costano parecchio. Consigli su cosa acquistare?
Grazie
Il 2023-02-22 18:45, Marco Ciampa ha scritto:
On Wed, Feb 22, 2023 at 01:29:07PM +0100, listemessaggi@coplast.eu
wrote:
Restando valido tutto quanto discusso nello scambio di mail
precedente, ma
non è che il problema sia ad un altro livello? Che sia l'approccio sbagliato? Forse sto chiedendo troppo a questo server?
Questa macchina esporta via Tgt dei volumi gestiti da LVM che a
suo volta si
appoggia ad un raid5 software.
Si tratta di una ventina di volumi, ognuno ha 3 snapshot (backup
1 giorno
prima, 2 giorni prima, ecc.), quindi l'IO su disco è
effettivamente elevato.
I volumi esportati via iscsi (tgt) passano per due reti in fibra
10Gb verso
i server hypervisor che fanno girare le macchine virtuali.
Di tutte le macchine virtuali si pianta solo una dove c'è un database. Effetivamente i database usano molti i dischi.
Questa macchina che funge da NAS/SAN ha una macchina fisica secondaria configurata in modo simile, ogni giorno i volumi vengono
replicati sulla
secondaria. Ho già provato ad eliminare questo passaggio per alleggerire il
lavoro, ma non cambia, ci sono comunque eventi di qualche disco che si ferma, e a cascata fino a iscsi e si ferma per un istante. Poi riparte subito e da solo, ma l'Hypervisor che usa i dischi via iscsi non accetta
"pause" e la macchina virtuale del database si blocca.
Vedete qualcosa di sbagliato?Il problema secondo me non è il RAID software ma il fatto di usare tanto IO su 4 dischi senza casche, neanche SAS ma soprattutto non SSD...
Qualche idea?Puoi provare ad aggiungere un disco SSD come cache LVM e vedere se risolvi...
https://blog.jenningsga.com/lvm-caching-with-ssds/ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/enabling-caching-to-improve-logical-volume-performance_configuring-and-managing-logical-volumes
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/lvm_cache_volume_creation
altrimenti fai tutto SSD...
Infatti anche io avevo suggerito questo come primo passo...
On Thu, Feb 23, 2023 at 01:46:46PM +0100, Piviul wrote:
Se il problema è l'accesso al disco lento per me fai prima a mettere una
cache SSD ai volumi LVM; ...io avrei portato anche il raid su LV ma questo è
un altro discorso ;)
Piviul
Il 23/02/23 13:16, listemessaggi@coplast.eu ha scritto:
Grazie per i consigli, opterei per passare a tutto SSD, sarebbe anche
trasparente, senza fermi, un disco alla volta.
Devo valutare i costi, 4 dischi SSD da 8 Tb cadauno costano parecchio.
Consigli su cosa acquistare?
Grazie
Il 2023-02-22 18:45, Marco Ciampa ha scritto:
On Wed, Feb 22, 2023 at 01:29:07PM +0100, listemessaggi@coplast.eu
wrote:
Restando valido tutto quanto discusso nello scambio di mailIl problema secondo me non è il RAID software ma il fatto di usare tanto >>>> IO su 4 dischi senza casche, neanche SAS ma soprattutto non SSD...
precedente, ma
non è che il problema sia ad un altro livello? Che sia l'approccio
sbagliato? Forse sto chiedendo troppo a questo server?
Questa macchina esporta via Tgt dei volumi gestiti da LVM che a
suo volta si
appoggia ad un raid5 software.
Si tratta di una ventina di volumi, ognuno ha 3 snapshot (backup
1 giorno
prima, 2 giorni prima, ecc.), quindi l'IO su disco è
effettivamente elevato.
I volumi esportati via iscsi (tgt) passano per due reti in fibra
10Gb verso
i server hypervisor che fanno girare le macchine virtuali.
Di tutte le macchine virtuali si pianta solo una dove c'è un database. >>>>> Effetivamente i database usano molti i dischi.
Questa macchina che funge da NAS/SAN ha una macchina fisica secondaria >>>>> configurata in modo simile, ogni giorno i volumi vengono
replicati sulla
secondaria. Ho già provato ad eliminare questo passaggio per
alleggerire il
lavoro, ma non cambia, ci sono comunque eventi di qualche disco che si >>>>> ferma, e a cascata fino a iscsi e si ferma per un istante. Poi riparte >>>>> subito e da solo, ma l'Hypervisor che usa i dischi via iscsi non
accetta
"pause" e la macchina virtuale del database si blocca.
Vedete qualcosa di sbagliato?
Qualche idea?Puoi provare ad aggiungere un disco SSD come cache LVM e vedere se
risolvi...
https://blog.jenningsga.com/lvm-caching-with-ssds/
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/enabling-caching-to-improve-logical-volume-performance_configuring-and-managing-logical-volumes
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/lvm_cache_volume_creation
altrimenti fai tutto SSD...
Ecco questo è un problema, nel senso che acquistare per avere vita a termine non mi ispira molto.
Il fatto è che non è chiaro quale sia il problema, se è l'accessostudia pure, fai le tue prove ma che io sappia no. Ricordo che ci sono
lento o cos'altro.
Però prima di acquistare 4 dischi potrei acquistarne solo 1 e provare.
Ma devo tenere in considerazione il fatto che parliamo di un server di produzione, che non deve fermarsi mai, e se non ho capito male la conversione/aggiunta al tipo di volume con cache richiede un fermo.
Devo documentarmi.
On Thu, 23 Feb 2023, listemessaggi@coplast.eu wrote:
Ecco questo è un problema, nel senso che acquistare per avere vita a
termine non mi ispira molto.
peché tu sei eterno ? guarda che sostituire un disco in un raid è meno critico e costoso che sostituire un sistemista.
--
Leonardo Boselli
Firenze, Toscana, Europa
http://i.trail.it
Il 23/02/23 21:56, listemessaggi@coplast.eu ha scritto:
[...]studia pure, fai le tue prove ma che io sappia no. Ricordo che ci sono
delle limitazioni alla dimensione del volume di cache e che se il
volume lento da cachare è un volume di root c'è da installare thin-provisioning-tools altrimenti al boot non riesce a montare la
partizione di root. Mi ero preso qualche appunto ma sono su un pc a
cui non posso accedere ora... Non prendere però un disco SSD per la
cache qualunque, prendine uno di classe enterprise, viene sollecitato parecchio.
Fai sapere!
Piviul
Il 2023-02-24 09:33, franchi@modula.net ha scritto:
Forse mi è passato, ma non ho capito che controller hai sul server.
Luciano
In realtà questo non è un vero server, a livello hardware è una workstation da progettazione 3D della Dell "riciclata" a server, con 5
dischi collegati via SATA, nel primo Debian, negli altri 4 il raid
software.
Buongiorno a tutti,
riapro e chiudo questo tema perchè non ho più dato feedback. Ci ho messo davvero tanto a risolvere, dopo i vostri consigli mi era stato chiesto di dare feedback in merito alle prove da effettuare, eccomi per questo.
Alcune macchine virtuali, in particolare una macchina con database Oracle piuttosto "stressato", andavano in freeze perchè il disco esportato via iscsi si "fermava" per sofferenze varie.
A distanza di quasi 1 anno, dopo aver rinnovato il raid con 4 disci SSD da 8Tb molto costosi, dopo aver lavorato su LVM, su DRBD, sulla rete in fibra, ... , ... alla fine ho capito e sperimentato che il problema erano gli snapshot. Avere 3 snapshot per ogni disco visrtuale significa scrivere i
dati 4 volte, 1 volta sul disco e altre 3 volte sui file COW che realizzano
i 3 snapshot. Se i dischi sono tanti gli snapshot sono tantissimi... I/O su disco molto gravoso.
Ripensata la strategia di backup, senza snapshot o meglio con un uso molto limitato e solo in orari dove le macchine con database non fanno backup interni, tutto funziona.
Matteo
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 11:02:19 |
| Calls: | 6,666 |
| Files: | 12,213 |
| Messages: | 5,336,375 |