Tengo un problema aquí en un clúster de conmutación por error de Windows Server 2016 (WSFC) que aloja una instancia de clúster de conmutación por error de SQL (FCI) que emplea Storage Spaces Direct (S2D). En cada servidor, después de la creación inicial exitosa, S2D agrega automáticamente un volumen RAID que de otro modo no se usaría al grupo de almacenamiento (aunque S2D no se puede crear en volúmenes RAID e insiste absolutamente en discos no asignados). Ahora está roto, debido a, por lo que pude entender, exactamente eso. Como consecuencia, el disco virtual está fuera de línea, lo que elimina todo el clúster. No volverá a estar en línea debido a la falta de recursos de la red del clúster. Los discos en cuestión pueden retirarse pero no eliminarse. La reparación del disco virtual no se ejecuta, la prueba de compatibilidad del clúster afirma que la configuración no es válida.
Esta es una nueva configuración. Entonces podría simplemente eliminar el disco virtual, el clúster o incluso los servidores y comenzar de nuevo. Pero antes de ser productivos, debo asegurarme de que esto nunca vuelva a suceder. El sistema que se dispara en la rodilla virtual hasta detenerse con solo agregar innecesaria y erróneamente un disco no compatible no es una plataforma que podamos implementar. Así que principalmente necesito una forma de evitar que esto suceda, en lugar de repararlo ahora. Mi conjetura es que evitar que una configuración de S2D tome más discos de los que fue creado haría el truco. El costo de una interacción potencialmente más manual durante un reemplazo de disco real es insignificante para el grupo ... que tenemos aquí. Por mucho que haya examinado la documentación hasta ahora, sin embargo, no puedo encontrar ninguna manera de controlar eso. A menos que me falte algo, ni Set-StoragePool,
Cualquier ayuda o sugerencia sería muy apreciada.
Los siguientes son solo más detalles sobre lo anterior: Tenemos 2 máquinas de servidor HPE DL380 Gen9 doblemente conectadas entre sí a través de Ethernet de 10GB con capacidad RDMA y 1GB a la red del cliente. Cada característica tiene un controlador RAID HP ??? y un simple controlador HBA HP ??? (dado que S2D requiere absolutamente y funciona solo en discos conectados directamente, sin guía). La configuración de almacenamiento consta de un OS-RAID en el controlador RAID, un RAID de archivos en el controlador RAID y el conjunto de discos directamente conectados en el HBA destinados a S2D.
Configuré 2 Windows Servers 2016 datacenter edition en los OS-RAID, instalé la función WSFC, ejecuté y pasé la prueba de compatibilidad del clúster, incluida la opción S2D, creé el clúster sin almacenamiento, agregué un testigo de uso compartido de archivos (en una máquina separada), habilité S2D en el grupo de almacenamiento, que se componía automáticamente de todos los discos no asignados, y encima de ese grupo creó un disco virtual del tipo espejo y utilizó NTFS como sistema de archivos, ya que se supone que este es el FS elegido para un FCI SQL instalación.
Luego instalé la edición estándar de SQL 2016 como un FCI en ese clúster, importé una base de datos y lo probé todo. Todo estuvo bien. La base de datos estaba allí y más rápido que nunca. La conmutación por error forzada y automática fue muy fácil. Todo se veía bien.
Al día siguiente intentamos hacer uso de los archivos RAID restantes. Lo primero fue cambiar el nivel RAID ya que no nos gustó la preconfiguración. Poco después de eliminar el volumen RAID preconfigurado y crear uno nuevo (en cada servidor), detectamos que el clúster estaba inactivo. Por lo que pude deducir hasta ahora, el volumen preconfigurado de Archivos RAID se había agregado mientras tanto automáticamente al grupo y, como lo eliminamos, ahora faltaba en el grupo. Mientras lo comprobaba, encontré el nuevo RAID de archivos, que aún se estaba creando, que también se muestra como una unidad física del grupo. Por lo tanto, el grupo ahora incluye 2 volúmenes RAID en cada servidor, uno de los cuales ni siquiera existía. Get-PhysicalDisk enumera estos volúmenes (pero no sus discos) junto con los discos realmente físicos en el HBA, no estoy seguro de si eso es regular.
Pude retirar esos discos físicos (es decir, aquellos que en realidad son los volúmenes RAID), y ahora están marcados como retirados. Pero todavía están en la piscina y no puedo eliminarlos en este momento, intentar hacerlo falla. Repair-VirtualDisk debería reconstruir el disco virtual a un estado apropiado solo en los discos restantes (seguí esto: https://social.technet.microsoft.com/Forums/windows/en-US/dbbf317b-80d2-4992- b5a9-20b83526a9c2 / storage-spaces-remove-physical-disk? forum = winserver8gen ), pero este trabajo termina inmediatamente, "exitoso", por supuesto, sin ningún efecto.
Intentar volver a conectar el disco virtual en línea falla, indicando que un recurso de clúster en red no está disponible. Según tengo entendido, esto solo podría referirse al grupo de almacenamiento (disponible), ya que los discos que faltan no son recursos de clúster. El grupo no muestra errores que corregir. La ejecución de la prueba de compatibilidad de clúster reclama una configuración no adecuada para un clúster.
No puedo encontrar ninguna parte que se mueva otra pulgada, todo parece estancado para siempre. ¿Alguna idea sobre cómo evitar que un WSFC en funcionamiento se acelere de esa manera?
No encontré ningún mensaje de error que encontré particularmente esclarecedor, y no quería bombardear la página aún más al publicarlos todos. Si alguien quiere tener algún detalle específico, házmelo saber.
¡Muchas gracias por su tiempo, muchachos!
Karsten
Actualización según lo solicitado por el Sr. Raspberry
Get-PhysicalDisk -CanPool $true | Sort Model | ft FriendlyName, BusType, CanPool, OperationalStatus, HealthStatus, Usage, SizeAdemás, ¿hay alguna posibilidad de que haya cometido un error al reconfigurar File-RAID al asignar una unidad S2D a un nuevo RAID?