Gerência da Informação

Na era da INFORMAÇÃO EXTREMA

Cerutti – gerência aula 4

Diante do cenário assoberbado de

informações na área corporativa, oriundas do Big Data, Data Science, Cloud, Mobile, mídias

sociais, qual o foco correto para os gerentes

de Informação?

Por que Gerência de Rede não é suficiente

• Hoje, quase todas as redes de qualquer tamanho tem algum tipo de sistema para monitorar seu desempenho.

• Estes sistemas de gerenciamento de rede tem sido em torno de muitos anos essenciais para os esforços da equipe de suporte de rede para oferecer serviços confiáveis.

• Uma grande variedade de opções disponíveis, que vão desde freeware para sistemas que podem custar milhões de dólares.

• Alguns sistemas são fornecidos por fornecedores de equipamentos, enquanto outros são independentes de fornecedor.

Por que Gerência de Rede não é suficiente

• Em geral, todos esses sistemas de monitorização do estado e o desempenho dos dispositivos de comutaçao e de enlaces na rede.

• Exemplos dos tipos de medições controladas incluem: Utilização de interface comutação

• CPU do dispositivo e utilização de memória• Mix dos Protocolos sobre enlaces dos comutadores• Configurações do equipamento• Disponibilidade do dispositivo• Status dos processos em servidores

Por que Gerência de Rede não é suficiente

• Mas os usuários não se queixam de que "a interface tem muita utilização" ou que "a memória do roteador é insuficiente".

• Eles dizem: "a rede é lenta", porque o tempo de resposta é que eles se preocupam.

• O problema é que esse tipo de gerenciamento de rede não pode medir tudo, o tempo todo.

• Todas essas medidas realmente não fornecem uma compreensão de que os usuários finais estão vendo

Abordagens para Monitoramento da “End User Experience"

• As pessoas que fornecem soluções de gerenciamento de rede estão cientes dessas questões.

• Gerentes de rede sempre tentam adicionar o desempenho do aplicativo para suas soluções.

Resposta ao pooling

Resposta combinada do desempenho da rede+aplicação

Uma abordagem típica é mostrada na figura 1. Neste exemplo, você quer saber o tempo de resposta do usuário está vendo a partir do servidor, o que é indicado pela seta vermelha.

RTT• Neste exemplo, você quer saber o tempo de resposta do

usuário está vendo a partir do servidor, o que é indicado pela seta vermelha.

• O poller central do sistema de gestão de rede tenta determinar este tempo de resposta, fazendo duas medições, conforme mostrado pelas setas verdes.

• A primeira é uma medida da resposta da rede entre o poller eo usuário e é tipicamente um PING.

• O segundo é uma medida da resposta do aplicativo entre o poller eo servidor de aplicativos e pode ser uma consulta de servidor "real" como abrir uma porta.

• Se o poller está localizado perto do servidor ou o usuário, a soma dessas medidas se aproxima o tempo de resposta ao usuário estaria vendo.

Problemas com redes modernas

Problema 1- Infelizmente, a abordagem baseada em um poller centro funciona em três problemas significativos quando aplicado a redes do mundo real moderno. Em primeiro lugar, muitos usuários não estão localizados no mesmo local que o poller central. Medições de desempenho de aplicativos seria válida para usuários no mesmo local que o poller, mas você não tem idéia do que usuários remotos estão vendo.

• Em segundo lugar, os testes de tempo de resposta do poller central para os locais remotos será impreciso. Isso porque as redes modernas têm uma conjunto de dispositivos que tratam diferentes tipos de tráfego de forma diferente, como firewalls e formadores de trânsito. Assim, o teste de ping podia ver uma resposta muito diferente do que o tráfego de rede real - ou não passar em tudo. Configurações de QoS na rede podem limitar a largura de banda disponível para alguns tipos de tráfego e outros não. Tráfego codificado como "alta prioridade", como VoIP, será tratado de forma diferente de aplicativos de negócios, que serão tratados de forma diferente do que o tráfego menos importante. Como resultado, os pings usadas para o teste o tempo de resposta irá enfrentar um desempenho muito diferente do tráfego da aplicação real.

As diferenças: Cloud e rotas randomicas

• Em terceiro lugar, a maior parte do tráfego em uma rede MPLS moderno não viaja através de um único ponto da rede em todos os fluxos e protocolos.

• Algumas empresas têm vários centros de dados distribuídos.

• Muitos clientes estão terceirizando aplicações-chave para provedores de serviços de aplicação (SaaS), tais como Salesforce.com.

• Uma tentativa de consulta centralizada nesta situação é completamente cega para o que esses usuários finais estão vivenciando.

Medindo a experiência do usuário• Agentes são implantados em toda a rede em locais diferentes,

em várias VLANs e servidores (incluindo vários servidores virtuais, se houver) - em qualquer lugar de ponta a ponta o desempenho precisa ser medido.

• Agentes de tráfego podem ser direcionados para medir em todas as maneiras que uma rede moderna foi concebida:

• Dos locais remotos para o Centro de Dados (ou vários centros de dados) para medir o desempenho do aplicativo

• De um agente para outro para medir o desempenho do site-to-site em redes MPLS ou para aplicações como VoIP

• Do agente para dispositivos fora da rede para medir o desempenho do aplicativo de prestadores de serviços de aplicação

Percepção do Usuário• medidas que realmente o que importam para os usuários

finais - o tempo de resposta para aplicações-chave, tais como: Os serviços de rede, tais como DNS, DHCP, ou RADIUS

• Serviços de e-mail • O tempo de resposta de servidores web, incluindo o seu

próprio site • Qualquer aplicativo de banco de dados back-end que pode ser acessado através do servidor web • Qualquer aplicativo que pode ser testada através da abertura de uma porta• Aplicacoes TCP ou UDP solicitadas pelo usuário