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 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
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
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
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
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...
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
