metodologÍa para corregir problemas de estabilidad, …
TRANSCRIPT
METODOLOGÍA PARA CORREGIR PROBLEMAS DE ESTABILIDAD, EN LA
COMUNICACIÓN DE LOS MEDIOS DE ALMACENAMIENTO Y SERVIDORES FÍSICOS, EN
AMBIENTES VIRTUALIZADOS PARA CENTROS DE DATOS
Jonathan Alberto Tinedo Perez, [email protected].*Autor Correspondiente. Especialización en
Teleinformática, Universidad Distrital “Francisco José de Caldas”, Bogotá – Colombia (Sur América).
Resumen
El presente artículo muestra el resultado de aplicar una metodología diseñada para corregir los problemas de estabilidad en la
comunicación de los medios de almacenamiento y servidores en un Centro de Datos, el cual se encuentra conformado por una
plataforma virtual bajo ambiente VMWARE, hardware con equipamiento de red, servidores físicos de marca CISCO y una
solución de almacenamiento SAN marca EMC, todo integrado como una solución convergente. La problemática presentada sobre
el Centro de Datos está afectando el funcionamiento de algunos medios de almacenamiento, generando eventos de degradaciones
en la comunicación con los discos de los servidores virtuales. A su vez se ha visualizado desconexión momentánea de los
servidores físicos de manera aleatoria con el gestor centralizado Vcenter. Una vez aplicado los correctivos a través del diseño de
una metodología planificada en 3 etapas se obtuvieron resultados satisfactorios en la reducción del número de desconexiones de
los hosts con el Vcenter con un porcentaje promedio del 95% de efectividad.
Abstract
This article shows the result of applying a methodology designed to correct stability problems in the communication of storage
media and servers in a Data Center, which is made up of a virtual platform under VMWARE environment, network equipment
and physical servers CISCO brand and an SAN storage solution EMC brand, all integrated as a converged solution. The problems
presented on the Data Center are affecting the operation of some storage media, generating degradation events in the
communication with the disks of the virtual servers. At the same time, momentary disconnection of the physical servers has been
visualized in a random way with the centralized Vcenter manager. Once the corrective measures were applied through the design
of a methodology planned in 3 stages, satisfactory results were obtained in reducing the number of disconnections of the hosts
with the Vcenter with an average percentage of 95% effectiveness.
Palabras Claves: actualizaciones, ambientes virtualizados, centro de datos, datastores, estabilidad, hearbeat, vcenter,
VMWARE.
1. Introducción
El objetivo de los sistemas convergentes es permitir que los departamentos de TI sean ágiles y ofrezcan rápidamente activos a los
usuarios de la empresa.
Una infraestructura convergente sólo utiliza los componentes de TI y almacenamiento que son verdaderamente necesarios,
incrementando por tanto la eficiencia en la utilización del hardware. Los costes de gestión disminuyen gracias a la centralización
de funciones. La convergencia crea una infraestructura para el centro de datos que está perfectamente adaptada a las necesidades
de la organización. La flexibilidad que conlleva este nivel de personalización se consigue mediante la virtualización, la
automatización y la coordinación. [1]
En el caso de estudio se cuenta con un Centro de Datos, el cual se encuentra conformado por: una plataforma virtual con
VMWARE, el hardware con equipamiento de red además de los servidores físicos todos marca CISCO, y una solución de
almacenamiento SAN marca EMC; todo el equipamiento se encuentra integrado como una solución convergente.
La problemática que se ha venido presentando hace algún tiempo está afectando el funcionamiento y rendimiento de algunos
Datastores (medios virtuales de almacenamiento), lo cual genera eventos de degradaciones y latencias en la comunicación con los
discos de los servidores virtuales, causando lentitud en el rendimiento de los procesos internos. A su vez se ha visualizado en
ocasiones, desconexión de los servidores físicos con el gestor centralizado Vcenter. Al estar configurada la plataforma virtual
como Clúster, todos los recursos de los hosts y los Datastores se encuentran disponibles para todos los servidores virtuales, por lo
tanto, la falla se suele presentar de manera aleatoria en cualquiera de ellos, lo que dificulta identificar cual es el motivo por el cual
se viene ocasionando la falla.
Para poder lograr mejorar la estabilidad de la plataforma virtual se deberá diseñar una metodología conformada por la aplicación
de medidas correctivas, definida en etapas para ir evaluando los resultados a nivel de la plataforma. La aplicación de los correctivos
al requerir interrupción del servicio, deberán ser planificados en Ventanas de Mantenimiento con autorización del cliente. Se
advierte que, de no aplicar los correctivos a la mayor brevedad posible, se seguirán presentado degradaciones en la comunicación
de los medios de almacenamiento y servidores físicos del Centro de Datos, pudiendo causar una interrupción general de tiempo
indefinido, generando indisponibilidad de servicio y molestias a los usuarios finales que utilizan los aplicativos contenidos en el
Centro de Datos.
En el presente artículo se muestran los resultados del diseño de una metodología para mejorar los problemas de estabilidad en la
comunicación de los medios de almacenamiento y servidores físicos que forman parte del Centro de Datos. Después de la
introducción, en la sección 2 se muestra un diagnóstico de la infraestructura del Centro de Datos actual, donde se describe su
estructura y se valida el estado actual de cada componente que lo conforma. En la sección 3 se identifican y documentan las
medidas correctivas a aplicar sobre la infraestructura del Centro de Datos para atacar la problemática planteada. Posteriormente
en la sección 4 se diseña una metodología para ejecutar todos los correctivos identificados en la sección anterior. Luego de ejecutar
el plan, en la sección 5 se verifica que los correctivos aplicados hayan realmente solventado la falla. Por último, se efectúan las
conclusiones en la sección 6.
2. Diagnóstico de la infraestructura del Centro de Datos
Como parte del diagnóstico inicial de la infraestructura que conforma el Centro de Datos es relevante Identificar todo el
equipamiento a nivel de infraestructura que conforma el Centro de Datos a fin de conocer las especificaciones tanto físicas
como lógicas del mismo.
2.1. Descripción del equipamiento a nivel físico que conforma el Centro de Datos
2.1.1. Descripción de servidores físicos empleados
Todos estos servidores son de Marca CISCO, modelo UCSB-B200-M3, cuyas especificaciones son: 2 procesadores Intel
Xeon de 2.80GHz, 270 Gb de disco local de almacenamiento, 524 Gb de memoria RAM.
2.1.2. Tipo y versión del hypervisor
El Sistema Operativo utilizado por los servidores físicos para la plataforma VMWARE es ESXi 5.5.0 update 3.
Adicionalmente se cuenta con un gestor centralizado VMWARE Vcenter Server versión 5.5.0 y cuyo programa de
monitoreo y configuración es Vsphere Client 5.5.0.
2.1.3. Tipo de Solución de Almacenamiento
Se cuenta con una solución de Storage EMC VNX-5400 de 450Tb, la cual es una solución de Storage de disponibilidad
continua de almacenamiento la cual usa Fiber Channel como medio de transporte hacia los servidores.
2.1.4. Elementos de Red
La solución de convergencia cuenta con un arreglo de varios Switch CISCO de diferente jerarquía y configurados en
clúster para proporcionar alta disponibilidad (HA) los cuales se mencionan en la tabla 1, e interactúan entre sí para
transportar internamente los datos entre los servidores virtuales y la solución de almacenamiento EMC a nivel LAN, y a
su vez para asignar el direccionamiento y para el enrutamiento del tráfico externo entrante y saliente que va hacia el
Router del proveedor ISP, que conexión externa al Centro de Datos.
Tabla 1. Listas de Switches que conforman el equipamiento de red del Centro de Datos
TIPO MARCA
Switch Catalyst 3750 Stack CISCO
Switch Catalyst 3750 Stack CISCO
Switch Nexus 5548P CISCO
Switch Nexus 5548P CISCO
Switch SAN Fiber Channel MDS 9148 CISCO
Switch SAN Fiber Channel MDS 9148 CISCO
Switch Fabric Interconnect UCS 6248UP CISCO
Switch Fabric Interconnect UCS 6248UP CISCO
2.2. Descripción del equipamiento a nivel lógico que conforma el Centro de Datos
En primera instancia se tiene que el direccionamiento de la solución de convergencia está dividido en una red para
producción que permite el enrutamiento a nivel WAN por parte del proveedor ISP. Adicionalmente se cuenta con un
direccionamiento para administración interna de la solución de convergencia.
Existen varios componentes que interactúan entre sí a nivel de software y que permiten dar funcionalidad a cada uno de
los servidores virtuales que están en funcionamiento dentro del Centro de Datos.
Uno de los componentes lógicos disponibles son las LUN (Logical Unit Number) que son volúmenes lógicos agrupados
para formar una unidad de almacenamiento de cierta capacidad definida. Estas unidades a nivel de la plataforma residen
en la solución de Almacenamiento (Storage) EMC y son gestionadas a su vez por el gestor Unisphere VNX Client.
El siguiente nivel de almacenamiento lógico lo forman los Datastores, que son contenedores lógicos que almacenan tanto
las máquinas virtuales (MV) como los archivos necesarios para el funcionamiento de esas MV y se encuentran disponibles
desde la plataforma VMWARE.
A continuación, se muestra en la figura1 un diagrama de la topología del equipamiento que conforma el Centro de Datos
y como se encuentra interconectado para facilitar la interpretación de las conexiones físicas entre los diferentes equipos.
Figura 1 Diagrama de topología de conexión del equipamiento que conforma el Centro de Datos.
Fuente:[1]
2.3. Validación de la solución de almacenamiento que forman parte del Centro de Datos.
A fin de validar el estado en que se encuentra la plataforma del Storage es necesario identificar los elementos que posee
configurados actualmente basándose en los parámetros identificados desde el gestor Unisphere.
El Storage o solución de almacenamiento consiste en una SAN marca EMC, modelo VNX5400 que posee 2 Storage
Processors A y B para alta disponibilidad. Continuando con la descripción de las partes que conforman el almacenamiento
del Storage, es importante resaltar que actualmente la solución cuenta con 2 Bus; para el Bus 0 se tienen 6 Enclosure o
arreglos de discos y para el Bus 1 se tienen 8 Enclosure. Los arreglos tienen discos de diferentes formatos y capacidades.
2.4. Verificación de la configuración del equipamiento de red del Centro de Datos.
Actualmente según [1] se cuentan con 8 switches todos de marca CISCO que conforman el arreglo del equipamiento de
conectividad de red, dividido en 4 jerarquías o familias diferentes:
Los switches Catalyst 3750, son 2 y están configurados en modo Stack (apilados en cascada), y la gestión
integra ambas consolas para facilitar su administración. Son equipos capa 3 y se encargan de manejar el
direccionamiento a nivel LAN para los equipos y máquinas virtuales y el tráfico entrante y saliente a nivel
WAN en comunicación con el firewall y el Router del ISP. Maneja velocidades de 1GB por cada puerto de red.
Los switches Nexus 5548, están interconectados en alta redundancia (HA) y tienen configurados los VPC
(Virtual Port Channel) 101 y 102 tanto en el primario como en el secundario para distribuir de manera troncal
todas las VLAN configuradas en la red a altas velocidades (10GB).
Los switches SAN MDS 9148, también son 2 interconectados en alta disponibilidad (HA) apuntando a cada
uno de los Storage Processors A y B del Storage VNX-5400, por un lado, y del otro lado conectados hacia los
switches FI UCS 6248, usando Fiber Channel como medio permitiendo alcanzar hasta 8GB de velocidad de
tráfico.
Los switches Fabric Interconnect UCS 6248UP, son 2 conectados en modo clúster por la tecnología Port
Channel con los servidores físicos del Centro de Datos, conformando la solución UCS (Unified Computing
System). Estos switches representan la puerta de comunicación del tráfico saliente y entrante hacia los
servidores físicos, por ello son el punto de interconexión común con los demás switches.
2.5. Validar el estado de cada uno de los servidores físicos que forman parte del Centro de Datos.
La plataforma virtual está conformada por un ambiente VMWARE de 10 servidores ESXi de los cuales los dos primeros
están agrupados en un clúster para administración y los 8 restantes agrupados en clúster para producción.
Luego se relacionan todos los Datastores presentes en la plataforma, los cuales son los medios de almacenamiento para
las Máquinas Virtuales y demás archivos presentes. Los Datastores se encuentran agrupados en Datastores locales que
son los discos de cada servidor físico, y los Datastores que visualizan las LUN (logical unit number) configuradas dentro
de la SAN de almacenamiento.
3. Medidas correctivas a aplicar sobre la infraestructura del Centro de Datos
En función a los artículos de la base de conocimiento de los proveedores de VMWARE y CISCO que se consiguen en la red,
algunos casos aperturados con dichos proveedores, y los logs encontrados relacionados a los últimos eventos sobre el gestor
de VMWARE, permitieron identificar posibles falencias sobre la configuración y versiones del SO de los servidores físicos
del Centro de Datos.
A continuación, se presenta en la figura 2 un diagrama donde se mencionan las medidas correctivas contempladas a aplicar
sobre la infraestructura del Centro de Datos:
Figura 2 Diagrama de las medidas correctivas a aplicar sobre la infraestructura del Centro de Datos
Fuente: [Diagrama elaborado en base a la agrupación de todas las medidas correctivas involucradas]
A fin de documentar el detalle de la metodología a aplicar para cada uno de los puntos, se elabora varios diagramas con cada
medida y el procedimiento a seguir a fin de condensar todos los pasos necesarios para llevar a cabo las mejoras en las
configuraciones consideradas.
3.1. Medida correctiva 1 Siguiendo parte de las indicaciones de la página web [2], para llevar a cabo la actualización de la versión del SO ESXi
se lleva a cabo el procedimiento citado en la figura 3:
Figura 3 Medida correctiva de aplicación de actualizaciones a servidores físicos y gestor Vcenter
Fuente: [2]
3.2. Medida correctiva 2
El documento referencial [3] hace mención a como se pueden instalar drivers a dispositivos a través del Cisco Unified
Computing System (UCS). Indica primero que existe una clara diferencia entre “Device Drivers” y “Firmware”, que
consiste en que el software del device drivers es instalado sobre el SO, mientras que el firmware está a un nivel más
bajo de código que es instalado sobre los dispositivos de hardware. A continuación, se resumen en la figura 4 los pasos
a ejecutar para llevar a cabo la actualización de drivers y dicho procedimiento debe ser ejecutado del paso 1 al 4 por
cada driver a actualizar antes del reinicio final.
Figura 4 Medida correctiva de aplicación de actualizaciones a controladores de tarjetas de red
Fuente: [3]
3.3. Método correctivo 3
Aplicar actualización del Firmware de los Switch SAN MDS 9148, que comunican la solución de Storage con los
servidores físicos del Centro de Datos con la finalidad de dar mayor capacidad de medición de performance del tráfico
que fluye a través de los switches.
Según las indicaciones del Ingeniero de soporte Ernest Appiah, del grupo de Cisco TAC – SAN (vía correo electrónico
[email protected] al correo [email protected] en fecha 07-09-2017) se recibió
seguimiento del diagnóstico del caso CISCO SR 683011450 de ambos switches SAN MDS9148 que forman parte de
la solución de red del Centro de Datos, indicando que el error de desconexión temporal que presentan los servidores
hacia el gestor Vcenter de Vmware no es a causa del funcionamiento de los switches CISCO MDS sino que el problema
apuntaba hacia los servidores físicos o el Storage. Adicionalmente comento que CISCO recomienda que se actualicen
los Sistemas Operativos de ambos switches.
Según la consulta de Recommended Releases for Cisco MDS 9000 Series Switches [12] la actualización recomendada
para el modelo MDS 9148 es el code level 6.2.19 a fin de aprovechar las nuevas capacidades de hardware y software.
Estas versiones tienen funciones y características mejoradas que permiten integrar un mejor diagnostico en la
investigación del problema de rendimiento. Actualmente en ambos switches corren la versión 5.2.8c.
Basándose en el Troubleshooting TechNotes de CISCO sobre el procedimiento de actualización de Firmware sobre un
MDS 9000 Series Multicapa Director Switch [13] se tiene en la figura 5 las siguientes indicaciones para llevar a cabo
de manera exitosa el procedimiento:
Figura 5 Medida correctiva de aplicación de actualización de firmware switch SAN
Fuente: [13]
3.4. Método correctivo 4
Validar y corregir configuración de parámetro Hearbeat
Basándose en el kb 1005757 de [4] existe un procedimiento para las fallas cuando los host ESXi presentan
desconexiones intermitentes con el Vcenter.
Causa: Según la teoría del articulo la causa de la falla se produce cuando el mensaje Hearbeat que envía el host no es
recibido por el Vcenter Server, esto hace que el Vcenter no pueda identificar el host. En la configuración por defecto el
host envía señal cada 10 segundos, y el Vcenter tiene una ventana de 60 segundos para recibir los Hearbeats. De no
completar esos lapsos de tiempo se podrían estar presentando congestión a nivel de la red entre el host y el Vcenter
Server. [2]
Procedimiento:
Este es un error ya identificado que ocurre en el vCenter Server, el cual no tiene una solución definida. Se debe
incrementar el tiempo límite en el vcenter Server para la señal del Hearbeats mientras el error de red pueda ser resuelto.
A continuación, se muestra en la figura 6 los pasos necesarios para llevar a cabo el método correctivo numero 4:
Figura 6 – Medida correctiva de configuración de parámetro Hearbeat
Fuente: [4]
3.5. Método correctivo 5
Proceso de mejora de parámetros de configuración en cada uno de los host esxi:
A nivel de los Adaptadores de Storage
Correctivos en configuraciones de zonificación a nivel de los Switches SAN para cada uno de los hosts para garantizar
alta disponibilidad de las rutas hacia los medios de almacenamiento LUN y balanceo de carga de trabajo [5].
o Validar estado de los puertos lógicos WWN y activación y desactivación
o Modificación de la zonificación dentro de los switches [6]
Modificación de la configuración de multipathing a nivel de los Datastores para configurar el modo Round Robin según
las buenas prácticas establecidas por el fabricante VMWARE.
o Validación de configuración existente con PowerPath vs multipath nativo de VMWARE NMP (Validación de
configuración de estado actual en configuración de powerpath , [6]. (descripción de power path a nivel de
configuración [7]
o Actualización de parches a través del Update Manager presente en cada host para garantizar que las versiones
de los controladores NMP sea el indicado según la página web Vmware Compatibility Guide.
A nivel de los Adaptadores de Red
Aplicar segmentación de red a nivel del uso de las tarjetas de red de cada host ESXi según criterios de mejores prácticas.
[9].
A continuación, se muestra en la figura 7 un resumen de los parámetros de configuración de red a corregir:
Figura 7 – Método correctivo 5 procesos de mejora de configuración de los hosts
Fuente: [9]
4. Diseño de la metodología para ejecutar todos los correctivos
A fin de poder aplicar los cambios de manera exitosa y sin generar afectación de los aplicativos que se encuentran en
producción es necesario aplicar una metodología planificada por etapas que sea analizado por el grupo de control de cambios
con el cliente a fin de analizar todos los riesgos que estuvieran implicados. La metodología se dividió en 3 etapas detallada
de la siguiente forma:
Etapa 1: Actualización a nivel del Sistema Operativo de los servidores físicos y del Vcenter llevándolo a la versión de 5.5
update 3 para corregir errores presentes en las anteriores versiones. Y por otro lado Se actualizaron los drivers de las
controladoras de las tarjetas de red de cada servidor físico a nivel de interfaz Ethernet y Fiber Channel para nivelar la
compatibilidad (ver Método de Corrección 1 y 2).
Etapa 2: Corrección del parámetro Heartbeat dentro del Vcenter. Se actualizo el firmware de los switches SAN MDS 9148 a
una versión más actual (ver Método de Corrección 3 y 4).
Etapa 3: El proceso de todas las mejoras de parámetros de configuración a nivel de cada uno de los hosts, asociados a los
Adaptadores de Storage y Adaptadores de Red (ver Método de Corrección 5).
La metodología ejecutada a nivel general aplicado en la Infraestructura se muestra en la figura 8.
Figura 8 Diagrama de Etapas de la Metodología sobre las acciones correctivas según los formatos RFC
Fuente: [Estructura definida por la integración de las etapas que conforman la metodología aplicada]
5. Evaluación de las medidas correctivas sobre la plataforma virtual
A fin de medir los resultados de los correctivos aplicados y evaluar si la metodología utilizada fue exitosa sobre la plataforma
del Centro de Datos, se muestran gráficos con las estadísticas de cuantas desconexiones a nivel de servidor físico (host ESXi)
se experimentaron previo a la aplicación de las correcciones, las cuales serán comparadas con las estadísticas obtenidas en el
gráfico una vez fueron aplicadas todas las mejoras citadas en la fase 3 del artículo.
5.1. Análisis de eventos presentados previo a la aplicación de la metodología diseñada
El grafico 1 que se muestra más abajo refleja la relación estadística de eventos identificados de desconexión de los hosts
con el Vcenter un mes antes de la aplicación de la metodología. Como se puede observar el host con menos afectaciones
fue el host ESXi06 con 1 caída identificada, mientras que los host ESXi02, ESXi03, ESX04 y ESXi10 reportaron hasta
4 afectaciones durante el mes. Indagando con el proveedor VMWARE a través de uno de los casos aperturados se
determinó que la causa raíz de las desconexiones de los hosts son por congestión de la red al momento de experimentar
altas tasas de tráfico generados por tareas y acciones de la plataforma virtual. Cada vez que se desconecta uno de los
hosts se registra la alarma a nivel del Vcenter (no del host local) por lo que solo se pierde gestión y capacidad de
migración, clonación y alta disponibilidad; sin embargo, no se experimenta caída de servicios, por no afectarse la
operatividad de los hosts desconectados.
Grafico 1 Eventos de desconexión de los hosts con el Vcenter presentados durante el mes previo a la aplicación de los
correctivos
Fuente: [Revisión de los logs de eventos sobre el gestor Vcenter de plataforma virtual VMWARE]
5.2. Análisis de eventos presentados durante el mes posterior a la aplicación de correctivos definidos por la
metodología diseñada
El grafico 2 que se muestra a continuación refleja los resultados de la mejora de estabilidad de conexión que posee en
estos momentos la plataforma virtual a nivel de desconexión de los hosts con el vCenter luego de aplicar la metodología
diseñada sobre el Centro de Datos.
Se decidió mantener una observación diaria durante el mes posterior de los cambios, sobre los logs de cada host, similar
a la labor ejecutada durante el mes anterior, y se estableció el análisis comparativo de los resultados obtenidos por cada
host. De manera gráfica se evidencia que exceptuando a los host ESXi02 y ESXi03 se redujo un 100% las desconexiones
de los otros servidores con el gestor vCenter, esto es un indicativo de que las latencias de comunicación de red
experimentadas por tráfico elevado de uso de los servidores virtuales se redujeron ampliamente luego de los cambios.
En el caso de los hosts con afectación identificada (ESXi02 y ESXi03), se redujo un 75% las afectaciones lo cual es un
porcentaje considerable de mejoras. Sacando un promedio entre todos los hosts se obtuvo una mejora del 95% a nivel
de las desconexiones identificadas por lo que se garantiza que la metodología diseñada fue efectiva en la resolución de
la problemática planteada.
Grafico 2 Análisis comparativo de la cantidad eventos de desconexión de los hosts con el Vcenter antes y después de la
aplicación de la metodología diseñada
Fuente: [Revisión de los logs de eventos directamente desde el gestor Vcenter de plataforma virtual VMWARE]
3
4 4 4
2
1
3 3 3
4
0
1
2
3
4
5
host esxi1 host esxi2 host esxi3 host esxi4 host esxi5 host esxi6 host esxi7 host esxi8 host esxi9 hostesxi10
Can
tid
ad d
e ev
ento
s
Servidores Host
Eventos de desconexion temporal de host ESXi con Vcenter en el mes antes de aplicar la metodologia
3
4 4 4
2
1
3 3 3
4
0
1 1
0 0 0 0 0 0 00
1
2
3
4
5
hostesxi1
hostesxi2
hostesxi3
hostesxi4
hostesxi5
hostesxi6
hostesxi7
hostesxi8
hostesxi9
hostesxi10
Can
tid
ad d
e ev
ento
s
Servidores Host
Eventos de desconexion temporal de host ESXi con Vcenter luego de los correctivos
6. Conclusiones
La estructura de las 3 etapas se llevó a cabo de manera progresiva y agrupadas en actividades comunes que se resumen a
continuación: la primera etapa consistió en aplicar diferentes actualizaciones con el fin de nivelar las versiones incompatibles de
software y firmware y de esta manera reducir el impacto sobre la funcionalidad de la plataforma en general. La segunda etapa
consistió en modificar el parámetro Heartbeat para que cada servidor tuviera un tiempo más amplio para enviar señales de
disponibilidad hacia el Vcenter y así reducir el margen de desconexiones entre los hosts y el Vcenter. En la tercera etapa se
realizaron ajustes a nivel de la configuración de red de cada uno de los hosts, con el fin de dividir el tráfico entre las diferentes
tarjetas, para aumentar el ancho de banda, generar balanceo de cargas para evitar cuellos de botella y evitar afectar las funciones
de gestión al momento de presentarse altas tasas de tráfico.
Es importante resaltar que en promedio se obtuvo una mejora del 95% en la reducción del número de desconexiones de los
servidores con el gestor Vcenter, por lo que se garantiza que la metodología diseñada fue efectiva en la resolución de la
problemática planteada.
Tanto el diagnostico, diseño y ejecución de la metodología fue llevado a cabo sin necesidad de invertir dinero en equipamiento o
mano de obra adicional sobre el Centro de Datos, por lo que representa un logro sustancial y una buena solución para ser aplicada
en escenarios de infraestructuras similares donde se presente la misma problemática.
7. Referencias
[1] J. Tinedo, «Informe sobre la descripción de la plataforma de la Solución de Convergencia a nivel de elementos físicos y lógicos que la conforman,» UT- Selcomp/MIcrohard - Consejo Superior de la Judicatura , Bogota, 2016.
[2] A. Chaika, «Install VMware ESXi on a Cisco B200 M3 blade server,» 04 08 2016. [En línea]. Available: https://4sysops.com/archives/install-vmware-esxi-on-a-cisco-b200-m3-blade-server/.
[3] CISCO, «UCS Driver Installation for Common Operating Systems,» 26 04 2016. [En línea]. Available: https://www.cisco.com/c/en/us/support/docs/servers-unified-computing/ucs-manager/116349-technote-product-00.html#anc19.
[4] VMware Knowledge Base, «ESXi host disconnects intermittently from vCenter Server (1005757),» 29 03 2013. [En línea]. Available: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005757.
[5] CISCO, «Configuring Zones and Zone Sets,» 2017. [En línea]. Available: https://www.cisco.com/en/US/docs/storage/san_switches/mds9000/sw/san-os/quick/guide/qcg_zones.html.
[6] CISCO, «Configuring Zones and Zone Sets,» 26 10 2007. [En línea]. Available: https://www.cisco.com/en/US/docs/storage/san_switches/mds9000/sw/san-os/quick/guide/qcg_zones.html.
[7] EMC Corporation, «EMC PowerPath Family version 6x,» 07 2017. [En línea]. Available: https://www.emc.com/collateral/TechnicalDocument/docu42986.pdf.
[8] V. Choinski , «EMC PowerPath en comparacion con MPIO nativo de Windows,» 10 2011. [En línea]. Available: https://www.emc.com/collateral/TechnicalDocument/docu42986.pdf.
[9] Formadores IT, «BUENAS PRÁCTICAS CON VMWARE VSPHERE,» 27 04 2014. [En línea]. Available: https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&cad=rja&uact=8&ved=0ahUKEwi7y7uqxb_XAhUEQiYKHT38ClMQFghIMAY&url=http%3A%2F%2Fwww.e-forem.es%2Fcomfia%2Fpluginfile.php%2F15162%2Fmod_folder%2Fcontent%2F0%2FTema%25201%2520-%2520Buenas%2520p.
[10] Logicalis Group, «Infraestructura convergente,» 2017. [En línea]. Available: http://www.es.logicalis.com/soluciones-y-servicios/data-center/infraestructura-convergente/.
[11] VMWARE , «ESXi host disconnects intermittently from vCenter Server (1005757),» 03 12 2015. [En línea]. Available: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005757.
[12] CISCO, «Recommended Releases for Cisco MDS 9000 Series Switches,» 26 05 2017. [En línea]. Available: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/mds9000/sw/b_MDS_NX-OS_Recommended_Releases.html.
[13] CISCO, «Upgrade the Firmware on an MDS 9000 Series Multilayer Director Switch,» 11 11 2015. [En línea]. Available: https://www.cisco.com/c/en/us/support/docs/storage-networking/mds-9000-nx-os-san-os-software/118952-technote-mds9k-00.html.
[14] zoning- CISCO, «SAN How To: Zoning Methods,» 25 01 2016. [En línea]. Available: https://www.cisco.com/c/en/us/support/docs/storage-networking/storage-networking/200230-SAN-How-To-Zoning-Methods.html.