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.
