Si è verificato un problema qui in un WSFC (Windows Server Failover Cluster) del 2016 che ospita un'istanza del cluster di failover SQL (FCI) che utilizza Storage Spaces Direct (S2D). Su ogni server, dopo una corretta creazione iniziale, S2D ha aggiunto automaticamente un volume RAID altrimenti inutilizzato al pool di archiviazione (sebbene S2D non possa essere creato su volumi RAID e insiste assolutamente su dischi non cancellati). Ora è rotto, a causa - per quanto ho potuto capire - esattamente quello. Di conseguenza, il disco virtuale è offline, portando l'intero cluster con sé. Non tornerà online, a causa di una risorsa di rete cluster mancante. I dischi in questione possono essere ritirati ma non rimossi. La riparazione del disco virtuale non viene eseguita, il test di compatibilità del cluster richiede una configurazione non valida.
Questa è una nuova configurazione. Quindi potrei semplicemente eliminare il disco virtuale, il cluster o persino i server e ricominciare. Ma prima che diventiamo produttivi, devo assicurarmi che questo non accada mai più. Il sistema che si spara nel ginocchio virtuale a un arresto anomalo semplicemente aggiungendo inutilmente e erroneamente un disco non supportato non è una piattaforma che possiamo implementare. Quindi, in primo luogo, ho bisogno di un modo per impedire che ciò accada, piuttosto che ripararlo ora. La mia ipotesi è che impedire un setup S2D di afferrare più dischi di quanti ne siano stati creati farebbe il trucco. Il costo di un'interazione potenzialmente più manuale durante una sostituzione del disco reale è trascurabile per il clusterf ... che abbiamo qui. Per quanto abbia sfogliato la documentazione finora, tuttavia, non riesco a trovare alcun modo per controllarlo. A meno che non mi manchi qualcosa, né Set-StoragePool,
Qualsiasi aiuto o suggerimento sarebbe molto apprezzato.
Di seguito sono riportati ulteriori dettagli su quanto segue: Abbiamo 2 macchine server HPE DL380 Gen9 doppiamente collegate tra loro tramite Ethernet da 10 GB con capacità RDMA e tramite 1 GB alla rete client. Ogni caratteristica è un controller RAID HP ??? e un semplice controller HBA HP ??? (dal momento che S2D richiede e funziona esclusivamente su dischi non collegati direttamente e non). La configurazione di archiviazione comprende un sistema operativo RAID sul controller RAID, un file RAID sul controller RAID e il set di dischi direttamente collegati sull'HBA destinati a S2D.
Ho impostato 2 datacenter 2016 Server Windows Edition su OS-RAID, ho installato la funzione WSFC, ho eseguito e superato il test di compatibilità del cluster inclusa l'opzione S2D, creato il cluster senza memoria, aggiunto un testimone di condivisione file (su un computer separato), abilitato S2D sul pool di archiviazione, che comprendeva automaticamente tutti i dischi non cancellati, e sopra quel pool creava un disco virtuale di tipo mirror e utilizzava NTFS come file system, poiché si suppone che questo sia il FS prescelto per un FCI SQL installazione.
Ho quindi installato l'edizione standard di SQL 2016 come FCI su quel cluster, importato un database e testato tutto. Andava tutto bene. Il database era lì e più veloce che mai. Il failover forzato e automatico è stato un gioco da ragazzi. Sembrava tutto a posto.
Il giorno successivo abbiamo provato a utilizzare il restante File-RAID. La prima cosa è stata cambiare il livello RAID in quanto non ci piaceva la pre-configurazione. Poco dopo aver eliminato il volume RAID preconfigurato e averne creato uno nuovo (su ciascun server), abbiamo rilevato che il cluster era inattivo. Da quello che ho potuto capire fino ad ora, il volume Files-RAID preconfigurato era stato nel frattempo automaticamente aggiunto al pool e, appena lo abbiamo eliminato, mancava ora al pool. Mentre ho controllato, ho trovato il nuovo Files-RAID, mentre era ancora in fase di creazione, già mostrato come unità fisica del pool. Quindi il pool ora includeva 2 volumi RAID su ciascun server, uno dei quali non esisteva nemmeno. Questi volumi (ma non i loro dischi) sono elencati da Get-PhysicalDisk insieme ai dischi effettivamente fisici sull'HBA, non sono sicuro che sia normale.
Sono stato in grado di ritirare quei dischi fisici (cioè quelli che sono in realtà i volumi RAID) e ora sono contrassegnati come ritirati. Ma sono ancora nel pool e non riesco a rimuoverli ora, cercando di farlo non riesce. Un Repair-VirtualDisk dovrebbe ricostruire il disco virtuale in uno stato adeguato solo sui dischi rimanenti (sono andato da questo: https://social.technet.microsoft.com/Forums/windows/en-US/dbbf317b-80d2-4992- b5a9-20b83526a9c2 / storage-space-remove-physical-disk? forum = winserver8gen ), ma questo lavoro termina immediatamente, "con successo" ovviamente, senza alcun effetto.
Il tentativo di ripristinare online il disco virtuale non riesce, affermando che una risorsa di cluster in rete non è disponibile. A quanto ho capito, questo potrebbe riferirsi solo al pool di archiviazione (disponibile), poiché i dischi mancanti non sono risorse cluster. Il pool non mostra errori da correggere. L'esecuzione del test di compatibilità del cluster richiede una configurazione non adatta per un cluster.
Non riesco a trovare nessuna parte rimasta che si muoverebbe di un altro pollice, il tutto sembra bloccato per sempre. Qualche idea su come impedire a un WSFC in esecuzione di trovarsi in quel modo?
Non ho riscontrato alcun messaggio di errore che ho trovato particolarmente illuminante e non volevo bombardare ulteriormente la pagina pubblicandoli tutti. Se qualcuno vuole avere dettagli specifici, fammelo sapere.
Grazie mille per il tuo tempo, ragazzi!
Karsten
Aggiornamento come richiesto da Mr. Raspberry
Get-PhysicalDisk -CanPool $true | Sort Model | ft FriendlyName, BusType, CanPool, OperationalStatus, HealthStatus, Usage, SizeInoltre, c'è qualche possibilità che tu abbia commesso un errore durante la riconfigurazione di File-RAID assegnando un'unità S2D a un nuovo RAID?