Introducción
Este documento aclara algunos aspectos de la política de soporte para la coresidencia de aplicaciones definida en la Política de soporte de coresidencia de aplicaciones como parte de la política de soporte para las aplicaciones virtualizadas de Cisco Unified Communications (UC)/Collaboration definidas en Cisco Collaboration Virtualization. Esta nota técnica se aplica a todas las UC de Unified Computing System (UCS) y a otras opciones de hardware de virtualización que incluyen la configuración de referencia probada de UCS, UCS basada en especificaciones y servidores de terceros basados en especificaciones.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
-
UC en la solución UCS
-
Hardware de configuración de referencia probada UCS
-
Hardware basado en especificaciones (UCS, HP o IBM)
-
Virtualización de aplicaciones de Cisco Collaboration
-
Software VMware vSphere
-
hardware de Cisco Unified Computing System
Nota: Consulte la sección "Información Relacionada" de este documento para ver los enlaces de la página web.
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Coresidencia y "Calidad de Servicio"
Un elemento clave de la convergencia y la virtualización de la red es el uso compartido de los recursos de hardware.
-
Una red IP convergente comparte el hardware de red entre varios flujos de tráfico (voz, vídeo, acceso al almacenamiento y otros datos).
-
Un servidor virtualizado (o host de virtualización) comparte el hardware de red, almacenamiento e informática entre varias máquinas virtuales de aplicaciones (VM).
En ambos casos, la calidad del servicio es necesaria para proteger las UC de las aplicaciones que no son de UC cuando los recursos de hardware son finitos, como por ejemplo:
-
Calidad de servicio (QoS) en el routing y el switching de hardware de red para garantizar que el tráfico de red de voz/vídeo obtenga el ancho de banda y la protección necesarios frente a retrasos y fluctuaciones.
-
Adhesión a las reglas de virtualización de UC (por ejemplo, tamaño de hardware físico/virtual, política de residencia, etc.) para garantizar que las VM de UC obtengan la CPU, la memoria, la capacidad de almacenamiento y el rendimiento de red/almacenamiento necesarios.
Es imposible para Cisco probar todas las combinaciones de hardware y aplicaciones para la coresidencia de VM, especialmente para las VM de aplicaciones de terceros cuyo comportamiento podría ser impredecible o no estar claramente definido. Por lo tanto, el rendimiento en tiempo real de las aplicaciones de Cisco UC sólo se confirma cuando se instala en una configuración de referencia probada de UCS y, a continuación, sólo cuando se cumplen todas las condiciones de la política de co-residencia (consulte Escalado de virtualización de colaboración y, en el caso de las aplicaciones que admiten reservas de CPU como UCM e IMP, podría haber otras consideraciones).
En otros entornos, la incertidumbre se puede reducir mediante pruebas previas a la implementación, la creación de líneas de base, siguiendo los principios generales de la virtualización y siguiendo las reglas de la virtualización de Cisco UC (en Cisco Collaboration Virtualization). Sin embargo, Cisco no puede garantizar que las máquinas virtuales nunca se vean privadas de recursos y nunca tengan problemas de rendimiento.
Consideraciones clave de soporte para máquinas virtuales que no sean de UC o de terceros
Para permitir que Cisco TAC proporcione soporte de forma eficaz cuando ejecute VM de Cisco UC co-residentes con VM de aplicaciones que no sean de UC o de terceros, los clientes deben garantizar cualquiera de las siguientes ventajas:
-
Las VM que no son de UC o de terceros no son críticas y pueden apagarse temporalmente si es necesario para facilitar la resolución de problemas.
-
Si ninguna VM no es crítica, la capacidad de repuesto debe aprovisionarse en hosts de virtualización o servidores físicos para la reubicación (temporal o permanente) de VM como solución a los problemas de rendimiento de las aplicaciones. La capacidad de repuesto ya es una práctica recomendada para el diseño de redundancia o para proporcionar almacenamiento temporal de VM cuando se requiere mantenimiento en hardware o software. Algunos ejemplos de "capacidad de repuesto" son los servidores físicos "vacíos" adicionales (para proporcionar "espera en caliente" o almacenamiento provisional) o los servidores blade/de montaje en rack existentes que no se utilizan completamente.
Para permitir que Cisco TAC proporcione soporte de forma eficaz cuando ejecute VM de Cisco UC co-residentes con VM de aplicaciones que no sean de UC o de terceros, Cisco podría requerir estas actividades del cliente para el diagnóstico o la resolución de problemas:
-
Cambios en la carga de trabajo de software o en el hardware físico, para resolver o resolver problemas de rendimiento de las aplicaciones. Algunos ejemplos de cuándo podrían requerirse estos cambios son las VM de UC que reciben las operaciones de entrada/salida de entrada/salida de almacenamiento por segundo (IOPS), la CPU, la memoria, la red y la capacidad de disco insuficientes del hardware.
-
A continuación se enumeran ejemplos de cómo se ven estos cambios en una implementación real.
-
Software: apagado temporal de VM no críticas para facilitar la resolución de problemas de rendimiento
-
Software: mueva VM críticas y/o VM no críticas para alternar el host de virtualización/servidor físico como solución temporal o permanente.
-
Reduzca temporalmente el número de máquinas virtuales que se ejecutan en un host si Cisco lo considera necesario para solucionar problemas.
-
Reduzca permanentemente el número de máquinas virtuales que se ejecutan en un host si Cisco determina que el host está sobrecargado.
-
División de una máquina virtual de aplicaciones de UC densa en varias VM menos densas y, a continuación, traslado de estas VM menos densas a hosts alternativos. Por ejemplo, dividir un OVA de usuario de CUCM 10K en varios OVA de usuario de CUCM 7.5K y, a continuación, reubicar algunos de esos OVA de usuario de CUCM 7.5K.
-
Estos enfoques permiten reducir la carga de trabajo de software en un host de virtualización/servidor físico sobrecargado, de modo que la carga de trabajo ya no se vea afectada por los recursos de hardware.
-
Hardware incorporaciones/actualizaciones para "reparar" un host sobrecargado como alternativa a la desactivación de VM o al traslado de VM.
-
Por ejemplo, la incorporación de más discos físicos para aumentar la capacidad de almacenamiento o proporcionar IOPS.
-
Por ejemplo, la adición de más memoria física o de más núcleos físicos de CPU.
-
Por ejemplo, la adición de interfaces NIC físicas para abordar la congestión LAN.
-
Estos enfoques permiten "actualizar" el hardware sobrecargado para dar cabida a la carga de trabajo de software que requiere muchos recursos.
El suministro de soporte de Cisco depende de que el cliente mantenga un contrato de soporte actual y totalmente pagado con Cisco.
Información Relacionada
Comentarios