Re: Problema storage
On Thu, Nov 23, 2023 at 04:16:49PM +0100, listemessa...@coplast.eu wrote: > 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 Grazie della condivisione. Non pensavo che gli snapshot (a parte l'occupazione disco) potessero essere così impattanti... -- Amike, Marco Ciampa
Re: Problema storage
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
Re: Problema storage
Il 26-02-2023 21:56 listemessa...@coplast.eu ha scritto: Il 2023-02-24 09:33, fran...@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, ti spiacerebbe eliminare la conferma di lettura quando scrivi in quasta ml? /paride -- https://keyserver.gnupg.org/pks/lookup?op=get=0xf14cd648d16d33c82a7d2ac778c59a24690431d3 Chi e' pronto a rinunciare alle proprie liberta' fondamentali per comprarsi briciole di temporanea sicurezza non merita ne' la liberta' ne' la sicurezza.(Benjamin Franklin - dalla Risposta al Governatore, Assemblea della Pennsylvania, 11 novembre 1755)
Re: Problema storage
Err, ovviamente TBW va convertito in settori. Il 27/02/2023 09:26, Diego Zuccato ha scritto: Difficile tradurlo in anni di vita... Ma se guardi i contatori dei dischi attuali puoi farti un'idea del carico a cui sono sottoposti: guardi il totale di settori scritti e dividi per il tempo di attività. Poi dividi il dato TBW per il numero che hai ottenuto e ottieni un tempo che puoi convertire in anni/mesi/giorni . Se arrivi a più di 3 anni, vai trnaquillo. Chiaramente un SSD usato per pagine web statiche avrà una vita "un tantino" più lunga del suo gemello usato per mining Chia... :) Diego Il 26/02/2023 23:00, listemessa...@coplast.eu ha scritto: Il 2023-02-23 22:04, Leonardo Boselli ha scritto: On Thu, 23 Feb 2023, listemessa...@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 No non sono eterno, concordo con te. Però mi piacerebbe tradurre quel numero in anni di vita. matteo -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Problema storage
Difficile tradurlo in anni di vita... Ma se guardi i contatori dei dischi attuali puoi farti un'idea del carico a cui sono sottoposti: guardi il totale di settori scritti e dividi per il tempo di attività. Poi dividi il dato TBW per il numero che hai ottenuto e ottieni un tempo che puoi convertire in anni/mesi/giorni . Se arrivi a più di 3 anni, vai trnaquillo. Chiaramente un SSD usato per pagine web statiche avrà una vita "un tantino" più lunga del suo gemello usato per mining Chia... :) Diego Il 26/02/2023 23:00, listemessa...@coplast.eu ha scritto: Il 2023-02-23 22:04, Leonardo Boselli ha scritto: On Thu, 23 Feb 2023, listemessa...@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 No non sono eterno, concordo con te. Però mi piacerebbe tradurre quel numero in anni di vita. matteo -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Problema storage
Il 2023-02-23 22:04, Leonardo Boselli ha scritto: On Thu, 23 Feb 2023, listemessa...@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 No non sono eterno, concordo con te. Però mi piacerebbe tradurre quel numero in anni di vita. matteo
Re: Problema storage
Il 2023-02-24 06:52, Piviul ha scritto: Il 23/02/23 21:56, listemessa...@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 Cerco un disco adatto, acquisto, provo e rispondo.
Re: Problema storage
Il 2023-02-24 09:33, fran...@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.
Re: Problema storage
Il 23/02/23 21:56, listemessa...@coplast.eu ha scritto: Il fatto è che non è chiaro quale sia il problema, se è l'accesso 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. 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
Re: Problema storage
On Thu, 23 Feb 2023, listemessa...@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
Re: Problema storage
Ecco questo è un problema, nel senso che acquistare per avere vita a termine non mi ispira molto. Il 2023-02-23 14:11, Diego Zuccato ha scritto: Attenzione. Al momento mi pare che da 8T ci sia solo il Samsung 870 QVO, che è un QLC. Dal sito https://www.samsung.com/it/memory-storage/sata-ssd/ssd-870-qvo-sata-3-2-5-8tb-mz-77q8t0bw/ : "fino a un massimo di 2.880 TBW". Quindi dipende da quanto ci (ri)scrivi. Diego Il 23/02/2023 13:16, listemessa...@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, listemessa...@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...
Re: Problema storage
Il fatto è che non è chiaro quale sia il problema, se è l'accesso 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. Il 2023-02-23 14:37, Marco Ciampa ha scritto: 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, listemessa...@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, listemessa...@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...
Re: Problema storage
Attenzione. Al momento mi pare che da 8T ci sia solo il Samsung 870 QVO, che è un QLC. Dal sito https://www.samsung.com/it/memory-storage/sata-ssd/ssd-870-qvo-sata-3-2-5-8tb-mz-77q8t0bw/ : "fino a un massimo di 2.880 TBW". Quindi dipende da quanto ci (ri)scrivi. Diego Il 23/02/2023 13:16, listemessa...@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, listemessa...@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... -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Problema storage
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, listemessa...@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, listemessa...@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... > > > > > -- Amike, Marco Ciampa
Re: Problema storage
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, listemessa...@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, listemessa...@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...
Re: Problema storage
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, listemessa...@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...
Re: Problema storage
On Wed, Feb 22, 2023 at 01:29:07PM +0100, listemessa...@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... -- Amike, Marco Ciampa
Re: Problema storage
Dopo che mi è morto un Raid5 di 3 dischi con dei WD green dopo 2 anni e pochi giorni, non ne ho mai più presi. Devo verificare i RED che ho messo in CEPH, che effettivamente mi paiono un tantino lenti... Meno male che ho già avviato l'acquisto degli SSD per sostituirli. Grazie per il link. Diego Il 22/02/2023 13:43, Marco Ciampa ha scritto: On Wed, Feb 22, 2023 at 12:21:16PM +0100, Paolo Redaelli wrote: Il 22 febbraio 2023 11:44:22 CET, Paride Desimone ha scritto: Il 22 febbraio 2023 10:21:41 UTC, Marco Ciampa ha scritto: On Wed, Feb 22, 2023 at 10:04:49AM +, 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 Ma occhio a prendere i RED con tecnologia CMR anziché i MEFITICI SMR... altrimenti vai sul sicuro e prendi Seagate Ironwolf Vedere: https://www.tomshardware.com/news/wd-moves-to-settle-smr-hdd-false-advertising-class-action-lawsuit -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Problema storage
On Wed, Feb 22, 2023 at 01:13:33PM +0100, listemessa...@coplast.eu wrote: > 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... POSSONO essere robaccia anche se costano, controlla il tipo di tecnologia... https://arstechnica.com/gadgets/2020/06/western-digital-adds-red-plus-branding-for-non-smr-hard-drives/ -- Amike, Marco Ciampa
Re: Problema storage
On Wed, Feb 22, 2023 at 12:21:16PM +0100, Paolo Redaelli wrote: > > > Il 22 febbraio 2023 11:44:22 CET, Paride Desimone ha > scritto: > >Il 22 febbraio 2023 10:21:41 UTC, Marco Ciampa ha > >scritto: > >>On Wed, Feb 22, 2023 at 10:04:49AM +, 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 Ma occhio a prendere i RED con tecnologia CMR anziché i MEFITICI SMR... altrimenti vai sul sicuro e prendi Seagate Ironwolf Vedere: https://www.tomshardware.com/news/wd-moves-to-settle-smr-hdd-false-advertising-class-action-lawsuit -- Amike, Marco Ciampa
Re: Problema storage
In data mercoledì 22 febbraio 2023 13:15:06 CET, listemessa...@coplast.eu ha scritto: > Come posso verificare? Tester? Se il tuo hardware supporta l'IPMI puoi usare ipmitool. -- Cosmo
Re: Problema storage
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? Grazie
Re: Problema storage
Sinceramente non saprei. Come posso verificare? Tester? Il 2023-02-22 09:48, Cosmo ha scritto: In data mercoledì 22 febbraio 2023 09:41:06 CET, listemessa...@coplast.eu ha scritto: No sono tutti e 4 i dischi del raid5 che a random segnalano quel problema. L'alimentatore come sta?
Re: Problema storage
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 2023-02-22 09:43, Diego Zuccato ha scritto: Che tipo di dischi sono? Non saranno dei "green", vero? Diego Il 22/02/2023 09:41, listemessa...@coplast.eu ha scritto: No sono tutti e 4 i dischi del raid5 che a random segnalano quel problema. 2 dischi li ho già sostituiti perchè stando allo SMART contenevano errori Il 2023-02-22 09:27, Marco Ciampa ha scritto: On Tue, Feb 21, 2023 at 09:57:26PM +0100, listemessa...@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...
Re: Problema storage
Il 22 febbraio 2023 11:44:22 CET, Paride Desimone ha scritto: >Il 22 febbraio 2023 10:21:41 UTC, Marco Ciampa ha scritto: >>On Wed, Feb 22, 2023 at 10:04:49AM +, 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 -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
Re: Problema storage
Il 22 febbraio 2023 10:21:41 UTC, Marco Ciampa ha scritto: >On Wed, Feb 22, 2023 at 10:04:49AM +, 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. /Paride -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
Re: Problema storage
On Wed, Feb 22, 2023 at 10:04:49AM +, 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... -- Amike, Marco Ciampa
Re: Problema storage
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 -- https://keyserver.gnupg.org/pks/lookup?op=get=0xf14cd648d16d33c82a7d2ac778c59a24690431d3 Chi e' pronto a rinunciare alle proprie liberta' fondamentali per comprarsi briciole di temporanea sicurezza non merita ne' la liberta' ne' la sicurezza.(Benjamin Franklin - dalla Risposta al Governatore, Assemblea della Pennsylvania, 11 novembre 1755)
Re: Problema storage
In data mercoledì 22 febbraio 2023 09:41:06 CET, listemessa...@coplast.eu ha scritto: > No sono tutti e 4 i dischi del raid5 che a random segnalano quel problema. L'alimentatore come sta? -- Cosmo
Re: Problema storage
Che tipo di dischi sono? Non saranno dei "green", vero? Diego Il 22/02/2023 09:41, listemessa...@coplast.eu ha scritto: No sono tutti e 4 i dischi del raid5 che a random segnalano quel problema. 2 dischi li ho già sostituiti perchè stando allo SMART contenevano errori Il 2023-02-22 09:27, Marco Ciampa ha scritto: On Tue, Feb 21, 2023 at 09:57:26PM +0100, listemessa...@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... -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Problema storage
Confermo quei circa 110 corrispondono a 55°C, che comunque sono tanti. Il 2023-02-22 09:20, Cosmo ha scritto: In data mercoledì 22 febbraio 2023 08:56:07 CET, Diego Zuccato ha scritto: Nei miei segue abbastanza la temperatura ambiente, con ovviamente qualche grado extra. Quelli sono i valori grezzi, il valore degli attributi è un'altra cosa feb 22 08:32:54 debian smartd[786]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 112 to 111 root@debian:~# sensors ---snip--- drivetemp-scsi-1-0 Adapter: SCSI adapter temp1:+32.0°C (low = +0.0°C, high = +60.0°C) (crit low = -41.0°C, crit = +85.0°C) (lowest = +18.0°C, highest = +32.0°C) ---snip drivetemp-scsi-0-0 Adapter: SCSI adapter temp1:+33.0°C (low = +0.0°C, high = +70.0°C) (crit low = +0.0°C, crit = +70.0°C) (lowest = +30.0°C, highest = +40.0°C) saluti
Re: Problema storage
No sono tutti e 4 i dischi del raid5 che a random segnalano quel problema. 2 dischi li ho già sostituiti perchè stando allo SMART contenevano errori Il 2023-02-22 09:27, Marco Ciampa ha scritto: On Tue, Feb 21, 2023 at 09:57:26PM +0100, listemessa...@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...
Re: Problema storage
In data mercoledì 22 febbraio 2023 08:56:07 CET, Diego Zuccato ha scritto: > Nei miei segue abbastanza la temperatura ambiente, con ovviamente > qualche grado extra. Quelli sono i valori grezzi, il valore degli attributi è un'altra cosa feb 22 08:32:54 debian smartd[786]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 112 to 111 root@debian:~# sensors ---snip--- drivetemp-scsi-1-0 Adapter: SCSI adapter temp1:+32.0°C (low = +0.0°C, high = +60.0°C) (crit low = -41.0°C, crit = +85.0°C) (lowest = +18.0°C, highest = +32.0°C) ---snip drivetemp-scsi-0-0 Adapter: SCSI adapter temp1:+33.0°C (low = +0.0°C, high = +70.0°C) (crit low = +0.0°C, crit = +70.0°C) (lowest = +30.0°C, highest = +40.0°C) saluti -- Cosmo
Re: Problema storage
Nei miei segue abbastanza la temperatura ambiente, con ovviamente qualche grado extra. Tipo: # smartctl -A /dev/sda smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-13-amd64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE [...] 190 Airflow_Temperature_Cel 0x0022 075 059 045Old_age Always - 25 (Min/Max 23/27) [...] 194 Temperature_Celsius 0x0022 025 041 000Old_age Always - 25 (0 17 0 0 0) [...] La sala è normalmente mantenuta a 18-22 gradi. Altri dischi, più in alto nel rack, riportano anche 43 gradi, ma stanno lavorando molto di più e sono più impacchettati: # smartctl -A /dev/sda smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-20-amd64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === Current Drive Temperature: 41 C Drive Trip Temperature:85 C Accumulated power on time, hours:minutes 25281:43 Manufactured in week 45 of year 2019 Specified cycle count over device lifetime: 5 Accumulated start-stop cycles: 21 Specified load-unload count over device lifetime: 60 Accumulated load-unload cycles: 1009 Elements in grown defect list: 0 # smartctl -A /dev/sdaa smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-20-amd64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === Current Drive Temperature: 43 C Drive Trip Temperature:85 C Accumulated power on time, hours:minutes 14298:59 Manufactured in week 15 of year 2021 Specified cycle count over device lifetime: 5 Accumulated start-stop cycles: 5 Specified load-unload count over device lifetime: 60 Accumulated load-unload cycles: 554 Elements in grown defect list: 0 Diego Il 22/02/2023 08:11, Cosmo ha scritto: In data mercoledì 22 febbraio 2023 06:26:59 CET, Diego Zuccato ha scritto: Temperature intorno ai 100 gradi mi paiono decisamente eccessive, se non è un errore di SMART. Quello è semplicemente il valore dell'attributo SMART non l'indicazione della temperatura espressa in gradi celsius -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: Problema storage
In data mercoledì 22 febbraio 2023 06:26:59 CET, Diego Zuccato ha scritto: > Temperature intorno ai 100 gradi mi paiono decisamente eccessive, se non > è un errore di SMART. Quello è semplicemente il valore dell'attributo SMART non l'indicazione della temperatura espressa in gradi celsius -- Cosmo
Re: Problema storage
Err... Butto lì: dischi che si stanno cuocendo? Temperature intorno ai 100 gradi mi paiono decisamente eccessive, se non è un errore di SMART. Diego Il 21/02/2023 21:57, listemessa...@coplast.eu ha scritto: Buonasera a tutti, chiedo aiuto per interpretare quanto segue. Feb 20 23:19:44 emiliano kernel: [4782542.532294] sd 2:0:1:0: attempting task abort! scmd(ce39ece2) Feb 20 23:19:44 emiliano kernel: [4782542.532300] sd 2:0:1:0: [sdc] tag#2246 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 Feb 20 23:19:44 emiliano kernel: [4782542.532305] scsi target2:0:1: handle(0x000a), sas_address(0x443322110100), phy(1) Feb 20 23:19:44 emiliano kernel: [4782542.532307] scsi target2:0:1: enclosure logical id(0x59890960a0016600), slot(1) Feb 20 23:19:44 emiliano kernel: [4782542.595275] sd 2:0:1:0: task abort: SUCCESS scmd(ce39ece2) [...] Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 35 to 34 Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 108 to 110 Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 114 to 116 Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 96 to 98 Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sde [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 103 to 105 Qualche info in più: si tratta di un server con Debian sul primo disco, mentre i restanti 4 dischi sono gestiti in raid5 con mdadm, sopra questo c'è lvm che gestisce i volumi, i volumi vengono esportati via iscsi (tgtadm). Ogni tanto il servizio iscsi ha dei "fermi", i server virtuali che risiedono su altri server fisici (rete 10 Gb in fibra) ne soffrono, in particolare un database oracle la prende sempre male, macchina virtuale che va in freeze almeno una volta al giorno... Non riesco a capire in corrispondenza di quali eventi si presenti il problema. Troppo IO su disco? Dischi meccanici, no SSD? Troppi snapshot? (3 per ogni volume, circa una ventina di LV) Grazie se mi date qualche suggerimento, qualche idea per indagare. Matteo -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Problema storage
Buonasera a tutti, chiedo aiuto per interpretare quanto segue. Feb 20 23:19:44 emiliano kernel: [4782542.532294] sd 2:0:1:0: attempting task abort! scmd(ce39ece2) Feb 20 23:19:44 emiliano kernel: [4782542.532300] sd 2:0:1:0: [sdc] tag#2246 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00 Feb 20 23:19:44 emiliano kernel: [4782542.532305] scsi target2:0:1: handle(0x000a), sas_address(0x443322110100), phy(1) Feb 20 23:19:44 emiliano kernel: [4782542.532307] scsi target2:0:1: enclosure logical id(0x59890960a0016600), slot(1) Feb 20 23:19:44 emiliano kernel: [4782542.595275] sd 2:0:1:0: task abort: SUCCESS scmd(ce39ece2) [...] Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 35 to 34 Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 108 to 110 Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 114 to 116 Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 96 to 98 Feb 20 23:51:51 emiliano smartd[18032]: Device: /dev/sde [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 103 to 105 Qualche info in più: si tratta di un server con Debian sul primo disco, mentre i restanti 4 dischi sono gestiti in raid5 con mdadm, sopra questo c'è lvm che gestisce i volumi, i volumi vengono esportati via iscsi (tgtadm). Ogni tanto il servizio iscsi ha dei "fermi", i server virtuali che risiedono su altri server fisici (rete 10 Gb in fibra) ne soffrono, in particolare un database oracle la prende sempre male, macchina virtuale che va in freeze almeno una volta al giorno... Non riesco a capire in corrispondenza di quali eventi si presenti il problema. Troppo IO su disco? Dischi meccanici, no SSD? Troppi snapshot? (3 per ogni volume, circa una ventina di LV) Grazie se mi date qualche suggerimento, qualche idea per indagare. Matteo
