Voz y Comunicaciones unificadas : Cisco Unified Communications System

El UC en UCS TRC, el UC en el UCS SPEC-basado y las de otras compañías SPEC-basaron resolver problemas de las implementaciones

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

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/uc-virtualized. Del interés particular está el contenido del hardware admitido en http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware.

Este documento es aplicable a todas las opciones de la virtualización incluyendo:

  • 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

prerrequisitos

Requisitos

Los Quien lea este documento deben tener 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

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

¿Qué “soportado” significa?

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:

  • “Lo hace “trabajo”?” Esto suena trivial. Sin embargo, en la virtualización hay muchos elementos que “trabaje” pero “no se permite” ni “es validado necesariamente” por VMware o Cisco. Por lo tanto, ninguna asistencia técnica proporcionada. Los “trabajos” son necesarios pero no suficientes.

  • “Si trabaja, es permitió por las reglas de la política de soporte del vendedor?” Cisco define qué se admite en www.cisco.com/go/uc-virtualized. 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. E.g balanceo de carga vía el planificador de trabajos del recurso dinámico del vSphere, que no tiene sentido para los apps de la colaboración de Cisco que no soportan el oversubscription CPU, ciertas opciones de hardware o ciertas clases de co-residencia de la aplicación.

  • “Si ha permitido, hizo al vendedor la 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 o a los conjuntos de almacenamiento virtualizados las de otras compañías) o porque están fuera del ámbito de qué Cisco probó explícitamente (por ejemplo el funcionamiento “garantía” del app UC con el hardware de la serie C TRC DAS UCS 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 está proporcionando a 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.

  • 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 http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware#Storage. 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.

  • Aplicaciones de virtualización UC en la escritorio-clase CPU (e.g. Core-i3): Esto puede o no puede “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 los apps de la colaboración de Cisco, incluso si “trabajan”.

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 encuentran.

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.

Clarificaciones del soporte para las opciones de hardware virtualizadas

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:

UC en la configuración de referencia probada UCS (TRC)

Las configuraciones del hardware UCS TRC que cumplen los requisitos en http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware “se permiten”, se diseñan específicamente para y “son validadas” con los apps UC por Cisco, y “soportadas completamente” 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 se garantiza cuando está instalado en un UCS TRC que cumple todos los requisitos en http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware (requisitos de rendimiento de almacenamiento incluyendo para el SAN), y cuando todas las condiciones en la directiva de la co-residencia en http://docwiki.cisco.com/w/index.php?title=Unified_Communications_Virtualization_Sizing_Guidelines se siguen.

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 antes de que el dispositivo MCS7800 ofrezca.

UC en el UCS SPEC-basado

el hardware SPEC-basado UCS que cumple los requisitos en http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware “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 del app 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 los apps UC de Cisco al cliente. Si no, si todas las reglas en www.cisco.com/go/uc-virtualized se siguen, el TAC de Cisco ayudará con resolver problemas el hardware SPEC-basado UCS, incluyendo los problemas de rendimiento del app UC. Tenga presente las puntas enumeradas abajo en las “consideraciones dominantes del soporte al desplegar en el hardware SPEC-basado”. La ayuda de estas puntas aclara lo que puede requerir el TAC de Cisco 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 del app 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 http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware#Processors_.2F_CPUs). Por ejemplo, el app VM UC “no vio” mucha diferencia entre Intel Xeon E5640 contra X5650 (la misma arquitectura, características del rendimiento similares, la misma velocidad de la base, apenas diversas cuentas de la base habilitando 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 del app VM UC se puede garantizar solamente para los modelos CPU validados en un TRC (cuál 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 del app de Cisco UC para la capacidad requerida en http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware#Memory_.2F_RAM. 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 el app VM UC es generalmente baja a menos que el despliegue sea media-intensivo (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 con 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 del app VM UC que puedan recibir. Parte de que el proceso del diseño se está asegurando 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 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 http://www.cisco.com/go/uc-virtualized). 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.

de otras compañías SPEC-basadas

el hardware del servidor SPEC-basado de las de otras compañías que cumple los requisitos en http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware “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 del app 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 los apps UC de Cisco al cliente. Si no, si todas las reglas en http://www.cisco.com/go/uc-virtualized se siguen, el TAC de Cisco ayudará con el troubleshooting a 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 (incluyendo 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 investigar los componentes del no Cisco.

También, tenga presente que las puntas enumeraron abajo en las consideraciones dominantes del soporte al desplegar en el hardware SPEC-basado. La ayuda de estas puntas aclara lo que puede 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 http://www.cisco.com/go/uc-virtualized). 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.

Consideraciones dominantes del soporte al desplegar en el hardware SPEC-basado

  • Para permitir al TAC de Cisco para proporcionar con eficacia el soporte cuando ejecutar 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 a http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware#VMware_Requirements y a http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements. 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 Cisco que se ejecuta UC VM en las configuraciones del hardware SPEC-basadas, Cisco puede requerir las actividades siguientes 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, 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 de 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 ejecutan 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 el reducir de 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, agregando más discos físicos para aumentar la capacidad de almacenamiento y/o para proporcionar los IOP

    • Por ejemplo, agregando más memoria física o memorias más físicas CPU

    • Por ejemplo, agregando las 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, 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 configuración de referencia probada serie C UCS (TRC) 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.

Clarificaciones del soporte para el software de la virtualización

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:

  1. Hipervisor de la virtualización de Cisco UC (soportado solamente con la edición 6000 del negocio de Cisco)

  2. 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 del negocio de Cisco)

  3. Estándar del vSphere de VMware, empresa o ediciones del Enterprise Plus compradas de Cisco

  4. 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.


Información Relacionada


Document ID: 115955