¿Mejores prácticas para agregar un segundo conmutador FC a la estructura en un entorno de producción?

¿Mejores prácticas para agregar un segundo conmutador FC a la estructura en un entorno de producción?

Tengo un único interruptor Brocade Silkworm 200e en producción en este momento. El servidor corp exchange y 3 hosts ESX 3.5 están conectados al arreglo clariion cx3 a través de él. Los puertos 0,1 son SPA0 y 1, y los puertos 4,5 son SPB0 y 1.

Mi plan es agregar un conmutador Brocade Silkworm 300 al lado del 200 (ya está montado y encendido), ir al centro de datos y sacar SPA1 y SPB0 del 200 e insertarlos en los puertos del conmutador 300.

Estoy un poco paranoico con la idea de sacar rutas FC que están en producción. Tengo una suposición lógica de que las cosas simplemente fallarán en SPA0 y SPB1 y no se perderán A1 y B0. Sin embargo, me gustaría tener un conocimiento 100% firme de lo que puedo hacer para minimizar aún más los riesgos si es posible.

Si un LUN actualmente es propiedad de SPA, ¿utiliza automáticamente tanto SPA0 como SPA1 en round robin o el conmutador prefiere una ruta particular exclusivamente a menos que falle? Ejemplo: ¿el servidor Exchange utiliza SPA0 o SPA1, o utiliza 0 y 1 activo/activo?

Supongo que si se usan ambas rutas hacia un SP activo/activo, interrumpir una de ellas es menos riesgoso porque estoy seguro de que ya está usando la otra ruta sin problemas. Tengo miedo de forzar la conmutación por error a una ruta alternativa que no ha usado antes y luego descubrir que el cable estaba defectuoso o algo así.

¿Debería ser totalmente perjudicial para la empresa y apagar todas las máquinas virtuales y el servidor Exchange solo para asegurarme de que no se dañen los datos en caso de una conmutación por error incorrecta? ¿O es esto excesivo? De cualquier manera, haré la operación inmediatamente después de un ciclo de respaldo completo.

¿Cómo monitorearía la conmutación por error a medida que ocurre? ¿El brocade 200e lo registrará en detalle? Quiero la máxima seguridad de que todo sigue funcionando cuando desconecto esos enchufes. Puedo volver a escanear el almacenamiento en los hosts esx y observar el monitor powerpath de Exchange. ¿Puedo hacer algo mejor?

Prefiero ser mucho más cauteloso de lo que amerita la situación que hacer suposiciones excesivamente confiadas acerca de hacer algo como esto por primera vez, cuando todos nuestros huevos están en esta canasta.

Respuesta1

Espero que su plan sea crear un segundo tejido independiente; en general, se considera una buena idea.

No dice si sus servidores tienen varios HBA o no. Eso espero, ya que le permitirá reconfigurar adecuadamente las telas redundantes, pero si no, no afectará significativamente su plan inmediato.

Powerpath manejará la conmutación por error para el servidor Exchange y debe elegir una ruta a través de A1 cuando A0 esté desconectado, y no B0 o B1 a menos que ambos puertos SPA hayan fallado. Si alguna ruta no está operativa, se lo indicará o, al menos, no verá las rutas que espera. Dependiendo de la versión de Powerpath (es decir, la versión SE o la versión con licencia completa) que tenga, es posible que tenga activas políticas de múltiples rutas de equilibrio de carga, pero en cualquier caso la conmutación por error de ruta debe ser confiable para la configuración que describe. Si desconecta una ruta activa, Powerpath redirigirá las E/S fallidas a través de la ruta alternativa siempre que estén en buen estado. Puede verificar el estado de la ruta dentro de la GUI de Powerpath o desde la línea de comando powermt checkpara verificar si hay rutas fallidas\nuevas o powermt restorepara verificar y eliminar\agregar rutas muertas\nuevas. Si la política de ruta ya está configurada para el equilibrio de carga y hay rutas en buen estado visibles a través de SPA0 y SPA1 (por ejemplo), entonces tiene un nivel bastante alto de confianza de que todo está bien.

En los servidores ESX, debería poder verificar las rutas disponibles para cada LUN desde la pestaña Cliente VI->Configuración->Almacenamiento. En las propiedades puede ver las rutas disponibles, cuáles están activas y cuáles están en espera y en el cuadro de diálogo Administrar rutas puede cambiar la política (Fixed\MRU\Round Robin). No debería necesitar cambiar nada, pero nuevamente querrá asegurarse de que la ruta de conmutación por error que desea utilizar esté disponible. Nuevamente, la pila de rutas múltiples de ESX se encargará de la conmutación por error; si las E/S están en tránsito en una ruta activa, las reenviará a otra ruta si detecta que falló. ESX 3.5 solo admite rutas múltiples por turnos de forma experimental, por lo que no querrás complicarte en este caso. Puede establecer una política de ruta fija temporalmente y forzar que los LUN utilicen la ruta que desea si desea ser proactivo, pero la configuración estándar para el CX3 es dejarlo en MRU y eso debería estar bien.

En ambos casos, puede haber algún retraso antes de que se produzca la conmutación por error y las E/S pueden detenerse brevemente, pero nada debería fallar siempre que las rutas redundantes estén realmente en buen estado.

información relacionada