Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento aclara algunos aspectos del soporte del software de la virtualización de las aplicaciones de las Comunicaciones unificadas de Cisco (UC), del vSphere de VMware y del hardware del servidor (Cisco o las de otras compañías) cuando está desplegado después de la política de soporte en www.cisco.com/go/virtualized-collaboration. Del interés particular es el contenido del hardware admitido.
Este documento es aplicable a todas las opciones de la virtualización, que incluyen:
UC en la configuración de referencia probada del sistema de Comunicaciones unificadas (UCS) (TRC)
UC en el UCS SPEC-basado
de otras compañías SPEC-basadas
Cisco recomienda que usted tiene conocimiento de estos temas (véase la información relacionada en el extremo de este documento para los links de la página web):
UC en la solución UCS (Comunicaciones unificadas de Cisco en el Cisco Unified Computing System)
Configuraciones del hardware probadas UCS de la configuración de referencia (TRC)
configuraciones del hardware SPEC-basadas (servidor del proveedor UCS o de las de otras compañías)
Virtualización de las aplicaciones de la colaboración de Cisco
Software del vSphere de VMware
Hardware de Cisco Unified Computing System
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
Las aplicaciones de la colaboración de Cisco que soportan la virtualización (véase de un vistazo en www.cisco.com/go/virtualized-collaboration).
Política de soporte para la virtualización de las aplicaciones de Cisco UC/Collaboration (véase la documentación complementaria en www.cisco.com/go/virtualized-collaboration).
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Hay generalmente siempre cuatro dimensiones del “soporte” a considerar. Son mencionadas abajo bajo la forma de preguntas, con las respuestas específicas a la virtualización de las aplicaciones de Cisco UC/Collaboration:
¿““Trabaja”? ” Mientras que esto suena trivial, en la virtualización hay muchos elementos que aparecen “trabajar”, pero no pudo ser estable o realizarse adecuadamente para las aplicaciones en tiempo real. Mientras que los “trabajos” son necesarios, no es suficiente en sus el propio “ser permitido” o soportado por Cisco, y puede ser que “no haya sido validado” por VMware o Cisco.
“Si trabaja, es permitió por las reglas de la política de soporte del vendedor?” Cisco define qué se soporta contra lo que se permite en www.cisco.com/go/virtualized-collaboration. Para la colaboración de Cisco, un elemento que “no se permite incluso si “trabaja”” es generalmente debido a una de estas razones:
Crea un problema de aplicación que se pueda reparar solamente con las mejoras del software o la re-arquitectura; por ejemplo, ciertas clases de fotos que cuelgan o causan un crash al administrador de las Comunicaciones unificadas de Cisco.
Puede afectar negativamente la estabilidad de la aplicación o la capacidad/el funcionamiento fiables, y la validación requerida de Cisco todavía no ha ocurrido; por ejemplo, vMotion con el administrador antes de marzo 2011 de las Comunicaciones unificadas de Cisco.
Un escenario válido del uso no existe para las aplicaciones de la colaboración de Cisco. Por ejemplo, planificador de trabajos del recurso dinámico del vSphere para las aplicaciones que no soportan las reservas CPU.
“Si se permite, hizo al vendedor lo valida?” Por ejemplo, prueba y garantía formales, que es determinado importante para las implementaciones UC/Collaboration de la voz en tiempo real y vídeo, los centros del Contacto del cliente, y otras comunicaciones esenciales para la misión. “No validan” algunos los elementos “permitidos”, tampoco porque son demarcación exterior de la responsabilidad de Cisco (por ejemplo cliente-proporcionó a los servidores virtualizados las de otras compañías o los conjuntos de almacenamiento) o porque están fuera del ámbito de qué Cisco probado explícitamente (por ejemplo el rendimiento de la aplicación UC la “garantía” con la serie C UCS probó la configuración de referencia (TRC) dirija el hardware asociado del almacenamiento (DAS) contra la “dirección-solamente” con el hardware SPEC-basado). La parte del valor de las soluciones de la infraestructura tales como Vblock o FlexPod es que sean proporcionen la “validación” en el nivel del sistema para un despliegue de muchos productos, multi-vendor.
“Hace al vendedor proporcionan la asistencia técnica para “cómo-a” o “el rotura-arreglo”?” Por ejemplo, ayuda con la configuración, o el troubleshooting de establecer la causa raíz y de reparar para un problema. El Centro de Asistencia Técnica de Cisco (TAC) soporta los Productos comprados de Cisco con un contrato de mantenimiento válido, entregado.
Aquí están algunos ejemplos del mundo real del “soporte” que ilustran estos conceptos:
Inicio de VMware del SAN: En 2010, esta característica “trabajada” como característica experimental de VMware en el vSphere 4.0, pero “no fue soportada oficialmente” por VMware hasta el vSphere 4.1, que afectó cuando Cisco podría considerar soportarlo para sus clientes.
Fibre Channel SAN con las aplicaciones virtualizadas UC: La política de soporte de Cisco “permite que” los apps UC conecten con los conjuntos de almacenamiento de las de otras compañías vía las redes SAN de Cisco o de las de otras compañías, con tal que cumplan los requisitos en www.cisco.com/go/virtualized-collaboration. Sin embargo, Cisco no valida el Switches de las de otras compañías SAN o los conjuntos de almacenamiento de las de otras compañías, y el TAC de Cisco no proporciona la ayuda en el Switches o los vectses de las de otras compañías.
Virtualización de las aplicaciones UC en la escritorio-clase CPU (por ejemplo, Core-i3): Esto pudo o no pudo “trabajar” en el sentido que la aplicación puede instalar y iniciar con éxito para arriba, pero es inverosímil que “trabaja” en el sentido de proporcionar a la estabilidad, a la capacidad o al funcionamiento de la producción-clase. Estos CPU no son permitidos, son validados, o soportados por las aplicaciones de la colaboración de Cisco, incluso si aparecen “trabajar”.
Es imposible que Cisco pruebe cada aspecto y combinación de hardware, de VMware y de aplicación para la garantía, determinado para el hardware y software de las de otras compañías. Por lo tanto, Cisco define las diversas directivas del soporte del hardware que representan los equilibrios entre la “garantía” y la “flexibilidad”, sobre la base de cuánto de la solución quisiera el cliente que Cisco “poseyera”, mientras que asegura los requerimientos mínimos para la operación de la aplicación de producción se cumplen.
Nota: Pedirán los clientes que no siguen la política de soporte publicada de Cisco reproducir un problema en una configuración admitida antes de que el TAC de Cisco pueda proporcionar con eficacia el soporte.
Para todas las opciones, es un requisito que el host (hardware físico + vSphere de VMware) es soportado por todas las aplicaciones del coresidente en ese host. Refiera a estos links para el soporte de aplicaciones:
De un vistazo en www.cisco.com/go/virtualized-collaboration
Se permiten”, se diseñan específicamente para y “son validadas” con las aplicaciones UC por Cisco, y “soportadas completamente” las configuraciones del hardware UCS TRC que cumplen los requisitos en el hardware de la virtualización de la Colaboración “por el TAC de Cisco dentro de la demarcación del soporte de Cisco. Por ejemplo, Cisco posee todo el hardware en una serie C TRC UCS con el almacenamiento DAS. Sin embargo, para una B-serie TRC UCS, Cisco no valida ni apoya el Switches o los conjuntos de almacenamiento del almacenamiento de las de otras compañías, y el TAC de Cisco no ayuda con estos componentes de las de otras compañías.
El funcionamiento del app VM de Cisco UC está confiado cuando está instalado en un UCS TRC que cumple todos los requisitos en el hardware de la virtualización de la Colaboración (requisitos de rendimiento de almacenamiento incluyendo para el SAN), y cuando todas las condiciones en la directiva de la co-residencia en el apresto de la virtualización de la Colaboración se siguen. Para el UCM y el IMP usando las reservas CPU, hay consideraciones adicionales descritas aquí.
El UC en UCS TRC también especifica una Lista de materiales del hardware, a la cual es útil a ésos el deseo de Cisco posee el diseño de hardware como con más viejas ofertas del dispositivo MCS7800.
el hardware SPEC-basado UCS que cumple los requisitos del hardware de la virtualización de la Colaboración y todos los requisitos específicos a la aplicación “se permite” y “es soportado completamente” por el TAC de Cisco dentro de la demarcación del soporte de Cisco apenas como UCS TRC.
La diferencia es que las configuraciones del hardware SPEC-basadas UCS no están validadas explícitamente con las aplicaciones de la Colaboración. Por lo tanto, no se hace ninguna predicción o garantía del funcionamiento de la aplicación VM UC cuando está instalada en el UCS SPEC-basó el hardware. Solamente se proporciona la dirección, y propiedad de asegurar que el diseño de hardware de las preventas proporciona el funcionamiento requerido por las rotaciones de las aplicaciones UC de Cisco al cliente. Si no, si todas las reglas en www.cisco.com/go/virtualized-collaboration se siguen, el TAC de Cisco ayudará con resolver problemas el hardware SPEC-basado UCS, que incluyen los problemas de rendimiento de la aplicación UC. Tenga presente las puntas enumeradas en las “consideraciones dominantes del soporte al desplegar en el hardware SPEC-basado”. La ayuda de estas puntas aclara qué TAC de Cisco puede requerir para proporcionar el soporte eficaz y hasta dónde TAC tomará un problema.
El UCS TRC se puede pensar en como “puntos de referencia del diseño” para el UCS SPEC-basado. El “riesgo” que un UCS SPEC-basó el diseño de hardware no proporcionará el suficiente funcionamiento a un conjunto de la aplicación VM UC es proporcional a la cantidad de “desviación” de UCS TRC. Más concretamente:
Modelo del servidor UCS no en cualquier TRC: Normalmente no un problema a menos que el firmware o los drivers usados en ese modelo sea substancialmente diferentes de los modelos validados como parte de un TRC.
Modelo CPU no en cualquier TRC: Un diverso modelo CPU no validado como parte de un TRC no es normalmente un problema mientras sea una arquitectura permitida CPU con la velocidad requerida de la base, y las reglas de apresto virtual-a-físicas UC para la cuenta requerida de la base se siguen (refiera a los procesadores soportados). Por ejemplo, la aplicación VM UC no experimentó mucha diferencia en el funcionamiento entre Intel Xeon E5640 contra X5650 (la misma arquitectura, las características del rendimiento similares, la misma velocidad de la base, apenas diversas cuentas de la base que habilitan diversas cuentas VM). Sin embargo, debido a las interacciones de los modelos CPU con el firmware del modelo del servidor y otros componentes del sistema, el funcionamiento de la aplicación VM UC se puede confiar solamente para los modelos CPU validados en un TRC (que era solamente el E5640).
Memoria: Una diversa configuración de la memoria que lo que uso TRC es raramente un problema mientras siga las guías de consulta de la población de la memoria de Cisco para el rendimiento óptimo en el modelo del servidor, más las reglas de apresto virtual-a-físicas de la aplicación de Cisco UC para la capacidad requerida en el hardware de la virtualización de la Colaboración. Observe que la memoria UCS TRC está clasificada intencionalmente para cualquier mezcla posible del app VM UC que pueda “caber” en el host, que da lugar al RAM total que puede ser más alto que lo que su despliegue determinado necesita.
Adaptadores: La utilización LAN para la aplicación VM UC es generalmente baja para señalar, pero puede ser alta para las implementaciones que son media-intensivas (por ejemplo, las porciones de secuencias de audio del voicemail o de secuencia de video de la Conferencia contra la señalización de tráfico) o usar el almacenamiento NAS/SAN (en este caso los adaptadores son parte de la solución del almacenamiento abajo). Las series C TRC UCS se configuran con bastantes accesos de Ethernet para manejar las necesidades típicas de los tipos de mezclas de la aplicación VM UC que puedan recibir. La parte del proceso del diseño es asegurarse que estos puertos son suficientes para su despliegue específico.
Almacenamiento: Aquí es donde la mayor parte de miente la complejidad y el “riesgo”, debido a la naturaleza IO-intensiva de la mayoría de las aplicaciones de Cisco UC. Hay varias calculadoras disponibles para la capacidad teórica DAS IO, pero es muy difícil predecir exactamente la capacidad real DAS sin la prueba formal. El NAS y los conjuntos de almacenamiento asociados SAN proporcionan herramientas más robustas de la garantía de diseño, pero Cisco no valida los conjuntos de almacenamiento de las de otras compañías o el Switches del almacenamiento (el UC en Vblock se puede utilizar para ofrecer esta garantía). Las series C TRC UCS tienen configuraciones DAS probadas contra la tolerancia del tiempo de espera de y los IOP generados por los tipos de mezclas del app VM UC que el TRC pueda recibir.
la incertidumbre SPEC-basada se puede reducir más a fondo por la prueba del PRE-despliegue, baselining, siguiendo los principios generales de virtualización, y después de las reglas de virtualización de Cisco UC (en la virtualización de la colaboración de Cisco). Sin embargo, Cisco no puede garantizar que los VM nunca serán hambrientos para los recursos y nunca tendrán problemas de rendimiento fuera de un UCS TRC. El “espacio libre” sigue siendo una mejor práctica del diseño, bajo la forma de dejar una cierta capacidad inusitada en un host, o disposición de los host adicionales.
El UC en el UCS SPEC-basado no especifica una Lista de materiales del hardware (BOM), puesto que por definición SPEC-basado es para las implementaciones donde el cliente requiere diverso specs/BOM que lo que fue validada en un TRC. Los clientes deben utilizar el TRC BOM como dirección, y leverage a su partner y Cisco combina para la ayuda en la generación del servidor BOM.
el hardware del servidor SPEC-basado de las de otras compañías que cumple los requisitos en el hardware de la virtualización de la Colaboración “es permitido” por Cisco, pero Cisco no realiza ninguna prueba o validación en el hardware de las de otras compañías.
No se hace ninguna predicción o garantía del funcionamiento de la aplicación VM UC cuando está instalada en las de otras compañías SPEC-basó el hardware. Solamente se proporciona la dirección, y propiedad de asegurar que el diseño de hardware de las preventas proporciona el funcionamiento requerido por las rotaciones de las aplicaciones UC de Cisco al cliente. Si no, si todas las reglas en la virtualización de la colaboración de Cisco se siguen, el TAC de Cisco ayudará con el troubleshooting para eliminar los problemas de la aplicación como la causa raíz. El cliente posee la conducción de la resolución de los problemas de los equipo y programas de computación del no Cisco, o las causas raíz de los equipo y programas de computación del no Cisco de la aplicación publican (que incluye cliente-proporcionó al software de VMware según lo descrito en las clarificaciones del soporte para el software de la virtualización más adelante en este documento). El cliente pudo necesitar contratar a los vendedores de las de otras compañías para investigar los componentes del no Cisco.
También, tenga presente que las puntas enumeraron en las consideraciones dominantes del soporte al desplegar en el hardware SPEC-basado. La ayuda de estas puntas aclara lo que pudo requerir el TAC de Cisco para proporcionar el soporte eficaz y hasta dónde TAC tomará un problema.
Observe que Cisco no soporta la virtualización en los servidores OEM HP/IBM de la herencia (servidores de la convergencia de medios de las 7800 Series, o el “MCS7800”).
El UCS TRC se puede utilizar como “puntos de referencia del diseño” para las de otras compañías SPEC-basadas según lo con el UCS SPEC-basado descrito anterior en este documento. Las consideraciones similares para el CPU, la memoria, los adaptadores y el almacenamiento existen. Observe que no hay TRC basados en los modelos del servidor de las de otras compañías.
la incertidumbre SPEC-basada se puede reducir más a fondo por la prueba del PRE-despliegue, baselining, siguiendo los principios generales de virtualización, y después de las reglas de virtualización de Cisco UC (en la virtualización de la colaboración de Cisco). Sin embargo, Cisco no puede garantizar que los VM nunca serán hambrientos para los recursos y nunca tendrán problemas de rendimiento fuera de un UCS TRC.
Cisco no especifica una Lista de materiales del hardware (BOM) para los servidores SPEC-basados las de otras compañías, puesto que por definición éstos están cliente-proporcionaron, las de otras compañías, los servidores NON-OEM. Los clientes pueden utilizar el UCS TRC BOM para la dirección, y leverage a sus equipos TIC del servidor del proveedor y del servidor interno de las de otras compañías para la ayuda en la generación del hardware BOM de las de otras compañías.
Para permitir al TAC de Cisco para proporcionar con eficacia el soporte cuando usted ejecuta Cisco UC VM en las configuraciones del hardware SPEC-basadas, Cisco requiere el vCenter de VMware para el UCS SPEC-basado y a las de otras compañías SPEC-basadas. Para los detalles adicionales refiera al hardware de la virtualización de la Colaboración y a los requisitos de software de la virtualización. Los clientes deben proporcionar los datos del vCenter de VMware cuando sea necesario por el TAC de Cisco que demuestra el cumplimiento de los requisitos de la virtualización UC tales como funcionamiento del almacenamiento.
Para permitir al TAC de Cisco para proporcionar con eficacia el soporte cuando usted ejecuta Cisco UC VM en las configuraciones del hardware SPEC-basadas, Cisco puede requerir estas actividades del cliente para el diagnóstico del problema o la resolución: Cambios a la carga de trabajo del software o al hardware físico, para resolver problemas o a los problemas de rendimiento de la aplicación de la resolución. Los ejemplos de cuando estos cambios pudieron ser requeridos son UC VM que recibe los IOP de la CPU insuficiente, de la memoria, de la red, de la capacidad del disco o del almacenamiento del hardware.
Los ejemplos de lo que parecen estos cambios adentro un despliegue real se enumeran aquí:
Software: potencia abajo temporal de los VM no críticos para facilitar el troubleshooting del funcionamiento
Software: mueva los VM críticos y/o los VM no críticos para alternar el host/al servidor físico de la virtualización como temporal o solución permanente.
Reduzca temporalmente el número de máquinas virtuales que se ejecutan en un host si Cisco juzga necesario para los propósitos de Troubleshooting.
Reduzca permanentemente el número de máquinas virtuales que se ejecuten en un host si se sobrecarga Cisco determina el host.
Partir un app denso VM UC en los VM menos-densos múltiples, entonces moviendo esos VM menos-densos para alternar el host; por ejemplo, HUEVOS de un usuario CUCM que parten 10K en el usuario múltiple OVAs CUCM 7.5K, entonces volviendo a poner a algo esos del usuario OVAs CUCM 7.5K.
Estos acercamientos permiten una reducción en la carga de trabajo del software en un host/un servidor físico sobrecargados de la virtualización, para morir de hambre la carga de trabajo no más para los Recursos de hardware.
Hardware adiciones/actualizaciones “para reparar” un host sobrecargado como alternativa a accionar-abajo los VM o a cambiar la colocación o densidad VM.
Por ejemplo, adición de más discos físicos para aumentar la capacidad de almacenamiento y/o para proporcionar los IOP
Por ejemplo, adición de más memoria física o memorias más físicas CPU
Por ejemplo, adición de interfaces físicas NIC para dirigir la congestión LAN
Estos acercamientos permiten el “actualizar” del hardware sobrecargado para acomodar la carga de trabajo recurso-hambrienta del software.
El soporte del “Cómo” se puede proporcionar por Cisco solamente para los servidores UCS. Para los servidores de las de otras compañías, las clientes necesitas de contratar a los recursos de soporte de las de otras compañías.
Si estos requisitos son inaceptables, se recomienda para desplegar en una serie C TRC UCS con el almacenamiento DAS.
La disposición de Cisco del soporte es contingente en el cliente que mantiene un contrato de servicio técnico actual y totalmente desembolsado con Cisco.
Los clientes tienen estas opciones de la compra de componentes para el software de la virtualización que las aplicaciones de la colaboración de Cisco se pueden desplegar encendido:
Hipervisor de la virtualización de Cisco UC o hipervisor más (soportado solamente con la edición 6000 del negocio de Cisco)
Fundación de la virtualización de Cisco UC (soportada solamente con las aplicaciones UC desplegó como UC en la solución UCS o como parte de la edición 6000/7000 del negocio de Cisco)
Estándar del vSphere de VMware, empresa o ediciones del Enterprise Plus compradas de Cisco
El estándar del vSphere de VMware, la empresa o las ediciones del Enterprise Plus compradas dirigen de VMware
Para las opciones 1, 2 y 3, el TAC de Cisco está disponible ayudar. Para la opción 4, el TAC de Cisco no ayuda con el software de la virtualización, y el cliente debe contratar a su vendedor de las de otras compañías.
La disposición de Cisco del soporte es contingente en el cliente que mantiene un contrato de servicio técnico actual y totalmente desembolsado con Cisco.