Voz e comunicações unificadas : Cisco Collaboration Systems Release

Comunicações unificadas (UC), NON-UC, e Co-residência da terceira das máquinas virtuais (VM) que pesquisa defeitos TechNote

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (21 Abril 2016) | Feedback


Índice


Introdução

Este documento esclarece alguns aspectos da política de suporte para a co-residência do aplicativo definida no http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines#Application_Co-residency_Support_Policy como parte da política de suporte para os aplicativos virtualizados das comunicações unificadas de Cisco (UC) /Collaboration definidos em http://www.cisco.com/go/uc-virtualized. Esta Nota Técnica é aplicável a todo o UC no UCS e a outras opções de hardware da virtualização que incluem UCS a configuração de referência testada UCS, SPEC-baseado e HP/IBM SPEC-baseado.

Pré-requisitos

Requisitos

Os leitores deste documento devem estar cientes destes tópicos:

  • UC na solução UCS (comunicações unificadas de Cisco no Cisco Unified Computing System)

  • Hardware testado UCS da configuração de referência

  • hardware SPEC-baseado (UCS, HP ou IBM)

  • Virtualização de aplicativos da colaboração do Cisco

  • Software do vSphere de VMware

  • Hardware de Cisco Unified Computing System

Nota: Veja a seção da “informação relacionada” deste documento para os links do página da web.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Co-residência e “Qualidade de Serviço”

Um principal da chave da convergência de rede e da virtualização é a partilha dos recursos do hardware.

  • Uma rede IP convirgida compartilha do hardware de rede entre córregos do tráfego múltiplo (Voz, vídeo, acesso do armazenamento, outros dados).

  • Um cálculo, um armazenamento e um hardware de rede virtualizados das partes do server (ou o host da virtualização) entre as máquinas virtuais dos aplicativos múltiplos (VM).

Em ambos os casos, Qualidade de Serviço é exigido para proteger o UC dos aplicativos NON-UC quando os recursos do hardware são finitos, como esta'n:

  • QoS no hardware de rede do roteamento e switching para assegurar o tráfego da Voz/rede de vídeo obtém a largura de banda e a proteção necessários do retardo e tremulação.

  • A aderência à virtualização UC ordena (por exemplo cola do hardware do /virtual, política da co-residência, etc. físicos) para assegurar UC VM obtém o CPU, a memória, a capacidade de armazenamento e o armazenamento/desempenho da rede necessários.

É impossível para Cisco testar cada combinação de hardware e pedido para a co-residência VM, particularmente para o app VM da 3ª parte cujo o comportamento pode ser imprevisível ou definido não claramente. Consequentemente, Cisco garante somente o desempenho do app VM de Cisco UC quando instalado em um UCS testou a configuração de referência (veja http://docwiki.cisco.com/wiki/Tested_Reference_Configurations_%28TRC%29) e então somente quando todas as condições na política da co-residência são seguidas (veja http://docwiki.cisco.com/w/index.php?title=Unified_Communications_Virtualization_Sizing_Guidelines).

Para outros ambientes, a incerteza pode ser reduzida por testes do PRE-desenvolvimento, linha de base, seguindo princípios gerais de virtualização, e depois das regras de virtualização de Cisco UC (em http://www.cisco.com/go/uc-virtualized). Contudo, Cisco não pode garantir que os VM estarão morridos de fome nunca para recursos e nunca para ter problemas de desempenho.

Considerações chaves do apoio para máquinas virtuais NON-UC e de 3ª parte

Para permitir o tac Cisco de fornecer eficazmente o apoio quando Cisco sendo executado UC VM co-residente com app VM non-UC/3rd-party, clientes dever assegurar qualquer um do seguinte:

  • O partido VM Non-UC/3rd é NON-crítico e pode ser posto-para baixo temporariamente se for necessário para facilitar pesquisar defeitos.

  • Se nenhum VM é NON-crítico, a seguir a capacidade de reposição deve ser fornecida em anfitriões ou em servidores físicos da virtualização para o internamento (provisório ou permanente) dos VM como soluções aos problemas de desempenho do aplicativo. A capacidade de reposição é já um melhor prática recomendado do projeto para a Redundância ou para fornecer a plataforma provisória dos VM quando a manutenção é exigida no hardware ou no software. Os exemplos “da capacidade de reposição” são extra “esvaziam” servidores físicos (para fornecer o “standby recente” ou a plataforma provisória), ou os server existentes da lâmina/montagem de rack utilizados não inteiramente.

Para permitir o tac Cisco de fornecer eficazmente o apoio quando Cisco sendo executado UC VM co-residente com app VM non-UC/3rd-party, Cisco puder exigir as seguintes atividades do cliente para diagnósticos do problema ou definição:

  • Mudanças à carga de trabalho do software ou ao hardware físico, para pesquisar defeitos ou aos problemas de desempenho do aplicativo da resolução. Os exemplos de quando estas mudanças puderam ser exigidas são recepção UC VM PROCESSADORES DE ENTRADA/SAÍDA CPU insuficientes, da memória, da rede, da capacidade de disco ou do armazenamento do hardware.

  • Os exemplos do que estas mudanças olham como dentro uma distribuição real estão listados abaixo.

    • Software: potência baixa provisória de VM NON-críticos facilitar o Troubleshooting do desempenho

    • Software: mova VM críticos e/ou VM NON-críticos para alternar o host/servidor físico da virtualização como provisório ou a solução permanente.

      • Reduza temporariamente o número de máquinas virtuais que são executado em um host se Cisco julga necessário para propósitos de Troubleshooting.

      • Reduza permanentemente o número de máquinas virtuais que são executado em um host se Cisco determina o host é sobrecarregado.

      • Rachando um app denso VM UC nos VM menos-densos múltiplos, movendo então aqueles VM menos-densos para alternar o host. Por exemplo ÓVULOS de rachadura de um usuário CUCM 10K no usuário múltiplo OVAs CUCM 7.5K, relocating então algum aqueles do usuário OVAs CUCM 7.5K.

    • Estas aproximações reservam reduzir a carga de trabalho do software em um host/servidor físico sobrecarregados da virtualização, de modo que a carga de trabalho seja morrida de fome já não para recursos do hardware.

  • Hardware: adições/elevações “para fixar” um host sobrecarregado como uma alternativa a pôr-para baixo VM ou a mover VM.

    • E.g. adicionando mais discos físicos para aumentar a capacidade de armazenamento e/ou fornecer PROCESSADORES DE ENTRADA/SAÍDA

    • E.g. adicionando mais memória física ou núcleos mais físicos CPU

    • E.g. adicionando relações físicas NIC para endereçar a congestão LAN.

    • Estas aproximações reservam “promover” o hardware sobrecarregado para acomodar a carga de trabalho recurso-esfomeado do software.

A disposição de Cisco do apoio é contingente em cima do cliente que mantém um contrato de suporte atual e inteiramente pago com Cisco.


Informações Relacionadas


Document ID: 113520