Colocación correcta de dispositivos en un tejido Fibre Channel

Estamos recibiendo un par de nuevos conmutadores de 8 Gb para nuestro tejido de canal de fibra. Esto es algo bueno ya que nos estamos quedando sin puertos en nuestro centro de datos principal, y nos permitirá tener al menos un ISL de 8 Gb ejecutándose entre nuestros dos centros de datos.

Nuestros dos centros de datos están separados unos 3.2 km a medida que se ejecuta la fibra. Hemos estado recibiendo un servicio sólido de 4 Gb durante un par de años, y tengo grandes esperanzas de que también pueda soportar 8 Gb.

Actualmente estoy descubriendo cómo reconfigurar nuestro tejido para aceptar estos nuevos interruptores. Debido a las decisiones de costes de un par de años estamos no ejecutando un tejido de doble circuito totalmente independiente. El costo de la redundancia total se consideró más costoso que el improbable tiempo de inactividad de una falla del interruptor. Esa decisión se tomó antes de mi tiempo, y desde entonces las cosas no han mejorado mucho.

Me gustaría aprovechar esta oportunidad para hacer que nuestro tejido sea más resistente ante una falla del interruptor (o la actualización de FabricOS).

Aquí hay un diagrama de lo que estoy pensando para un diseño. Los elementos azules son nuevos, los elementos rojos son enlaces existentes que se (re) moverán.

_{(fuente: sysadmin1138.net )}

La línea de flecha roja es el enlace actual del conmutador ISL, ambos ISL provienen del mismo conmutador. El EVA6100 está conectado actualmente a los dos interruptores 16/4 que tienen un ISL. Los nuevos conmutadores nos permitirán tener dos conmutadores en la CC remota, algunos de los ISL de largo alcance se están moviendo al nuevo conmutador.

La ventaja de esto es que cada interruptor no está a más de 2 saltos de otro interruptor, y los dos EVA4400, que estarán en una relación EVA-replicación, están a 1 salto el uno del otro. El EVA6100 en la tabla es un dispositivo más antiguo que eventualmente será reemplazado, probablemente con otro EVA4400.

La mitad inferior del gráfico es donde se encuentran la mayoría de nuestros servidores, y tengo algunas dudas sobre la ubicación exacta. Lo que debe ir allí:

• 10 hosts VMWare ESX4.1
  • Accede a recursos en el EVA6100
• 4 servidores Windows Server 2008 en un clúster de conmutación por error (clúster de servidor de archivos)
  • Accede a recursos tanto en el EVA6100 como en el EVA4400 remoto
• 2 servidores Windows Server 2008 en un segundo clúster de conmutación por error (contenido de Blackboard)
  • Accede a recursos en el EVA6100
• 2 servidores de bases de datos MS-SQL
  • Accede a recursos en el EVA6100, con exportaciones nocturnas de DB que van al EVA4400
• 1 biblioteca de cintas LTO4 con 2 unidades de cintas LTO4. Cada unidad tiene su propio puerto de fibra.
  • Los servidores de respaldo (que no están en esta lista) se ponen en contacto con ellos.

Por el momento, el clúster de ESX puede tolerar la caída de hasta 3, quizás 4 hosts, antes de que tengamos que comenzar a apagar las máquinas virtuales por espacio. Afortunadamente, todo tiene MPIO activado.

Los enlaces actuales de 4Gb ISL no se han acercado a la saturación que he notado. Eso puede cambiar con la replicación de los dos EVA4400, pero al menos uno de los ISL será de 8 Gb. Mirando el rendimiento que obtengo del EVA4400-A, estoy muy seguro de que, incluso con el tráfico de replicación, tendremos dificultades para cruzar la línea de 4 Gb.

El clúster de servicio de archivos de 4 nodos puede tener dos nodos en SAN1SW4 y dos en SAN1SW1, ya que eso colocará ambas matrices de almacenamiento a un salto de distancia.

Los 10 nodos ESX son un tanto irritantes. Tres en SAN1SW4, tres en SAN1SW2 y cuatro en SAN1SW1 es una opción, y estaría muy interesado en escuchar otras opiniones sobre el diseño. La mayoría de estos tienen tarjetas FC de doble puerto, por lo que puedo ejecutar dos nodos. No todos , pero lo suficiente como para permitir que un solo interruptor falle sin matarlo todo.

Los dos cuadros MS-SQL deben ir en SAN1SW3 y SAN1SW2, ya que deben estar cerca de su almacenamiento primario y el rendimiento de db-export es menos importante.

Las unidades LTO4 están actualmente en SW2 y a 2 saltos de su transmisor principal, por lo que ya sé cómo funciona. Esos pueden permanecer en SW2 y SW3.

Prefiero no hacer que la mitad inferior del gráfico sea una topología totalmente conectada, ya que eso reduciría nuestro recuento de puertos utilizables de 66 a 62, y SAN1SW1 sería un 25% de ISL. Pero si eso es muy recomendable, puedo ir por esa ruta.

Actualización: algunos números de rendimiento que probablemente serán útiles. Los tenía, solo separé que son útiles para este tipo de problema.

EVA4400-A en la tabla anterior hace lo siguiente:

• Durante la jornada laboral:
  • Las operaciones de E / S promedian menos de 1000 con picos de 4500 durante las instantáneas de ShadowCopy del clúster de servidores de archivos (duran aproximadamente 15-30 segundos).
  • MB / s generalmente permanece en el rango de 10-30MB, con picos de hasta 70MB y 200MB durante ShadowCopies.
• Durante la noche (copias de seguridad) es cuando realmente pedalea rápido:
  • El promedio de operaciones de E / S es de alrededor de 1500, con picos de hasta 5500 durante las copias de seguridad de la base de datos.
  • MB / s varía mucho, pero ejecuta aproximadamente 100 MB durante varias horas y bombea unos impresionantes 300 MB / s durante aproximadamente 15 minutos durante el proceso de exportación de SQL.

EVA6100 está mucho más ocupado, ya que es el hogar del clúster ESX, MSSQL y todo un entorno de Exchange 2007.

• Durante el día, las operaciones de E / S promedian alrededor de 2000 con picos frecuentes de hasta alrededor de 5000 (más procesos de base de datos) y MB / s promediando entre 20-50MB / s. El pico de MB / s ocurre durante las instantáneas de ShadowCopy en el clúster de servicio de archivos (~ 240MB / s) y dura menos de un minuto.
• Durante la noche, Exchange Online Defrag, que funciona de 1 a.m. a 5 a.m., bombea operaciones de E / S a la línea a 7800 (cerca de la velocidad de flanco para acceso aleatorio con este número de husillos) y 70 MB / s.

Agradecería cualquier sugerencia que pueda tener.

Perdón por el retraso.

Eché un vistazo a lo que tienes y lo que quieres lograr, tuve algunos pensamientos, aquí hay una buena foto primero ...

• Parece que no tiene sentido usar un enlace de 8 Gbps entre sitios en este momento; la razón es que está limitado por los puertos de 4 Gbps en el 4400 remoto, ya tiene 4 Gbps estables más el ancho de banda disponible es mucho mayor que el requisito de uso real - Hoy parece un desperdicio colocar uno de los interruptores 24x8 allí. Usaría dos de los conmutadores de 16x4 Gb en el sitio remoto.
• Me sentiría tentado a usar los nuevos conmutadores 24x8 como sus conmutadores principales 'principales': la mayor parte de su tráfico es de servidor a 6100 y la nueva caja será mucho más rápida. De esta manera, debería ver algunas pequeñas ganancias de rendimiento, ya que el nuevo conmutador tiene búferes más grandes y menor latencia, además de que puede elegir qué servidores mover a 8 Gb cuando lo desee, lo mismo para cuando cambie el 6100 (el Los 4600 tienen puertos nativos de 8 Gb, pero eso aún no es oficial;)).
• Luego nos metemos en una parte del diseño donde tenemos dos opciones; para mantener o descartar los dos 'conmutadores intermedios' de 16x4 Gb, basados ​​exclusivamente en el recuento de puertos. Básicamente, si usó los conmutadores 24x8 como cajas principales, solo tiene 3 puertos de reserva (ya que usará 18 para los 18 servidores, más 2 para el 6100 y un enlace ISL, lo que equivale a 21 utilizados). Usted podriaconecta el 4400 local a los conmutadores 24x8, dejándote exactamente 1 puerto libre para tus unidades de cinta, pero eso te deja con cero puertos libres. Lo que me vería tentado a hacer es usar los dos 'interruptores intermedios' de 16x4 Gb, ya sea como conmutadores locales secundarios para manejar las unidades de cinta y 4400 locales o posiblemente para manejar los enlaces ISL entre sitios si lo desea, aunque tendrá puertos gratis en los conmutadores de 24x8 Gb para hacer eso directamente desde allí si lo desea, no he mostrado ambos, ya que son muy similares.

Así que eso es lo que pienso: hay ajustes por todas partes, pero mis ideas generales están ahí, siéntanse libres de volver con cualquier aclaración.