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çõeschave, 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