A P2P-Based Self-Healing Service for Network
Maintenance
Serviço de auto-correção baseado em P2P para
manutenção de redes
Pedro Arthur Pinheiro Rosa Duarte, Jeferson Campos Nobre,
Lisandro Zambenedetti Granville, Liane Margarida Rockenbach Tarouco
Federal University of Rio Grande do Sul
12th IFIP/IEEE International Symposium on Integrated Network Management 2011
Apresentado por Bruno Barcarollo Gauer
Roteiro








Objetivo
Introdução
Trabalhos Relacionados
Proposta
Implementação
Estudo de caso / Avaliação
Conclusões
Críticas
Objetivo
Propor um mecanismo de auto-correção que
funcione sobre um sistema de gerência de redes
baseado em P2P
Introdução



Recentemente as redes têm aumentado em tamanho,
complexidade e heterogeneidade
Introdução de tecnologias distribuídas na gerência de redes
(P2PBNM) trouxe melhorias comparado ao sistema
tradicional centralizado
P2P Based Management Overlays




Gerência colaborativa
Conectividade mais robusta entre entidades
Melhoria na distribuição das tarefas
Boa escalabilidade
Introdução


Uso de propriedades self-* do Autonomic Computing
Autonomic Computing: paradigma que define
composição e características de sistemas autônomos


Propriedades self-*: Self Awareness, Self Configuring, Self
Optimizing, Self-Healing, Self Protecting
Foco em Self-Healing (auto-correção):

Habilidade de detectar e corrigir problemas, além de manter o
sistema funcionando corretamente de maneira transparente
Introdução

Self Healing: Automatizar tarefas de gerência

Reduzir custos de manutenção de infraestrutura



50% do custo é relativo a prevenção de erros,
diagnósticos e correção
Facilitar a vida dos administradores
Objetivos da proposta:


Abstrair monitoramento e correção dos sistemas
Tratar a heterogeneidade das redes usando ”workplans” (descrições de
alto nível de como os sistemas devem ser gerenciados)

Alta disponibilidade dos serviços

Avaliar o serviço em um sistema distribuído de detecção de intrusões
Trabalhos Relacionados

Abordagens Auto-Correção (Self-Healing)




PANACEA: framework para desenvolvimento de
sistemas com auto-correção
Inserção de elementos de auto-correção ao sistema
na fase de design e codificação
Elementos posteriormente são utilizados para
correções e testes em tempo de execução
Desvantagem: é embutido na aplicação
Trabalhos Relacionados

Abordagem: Model Based Adaptation

Apenas para aplicações com configurações em tempo real
Trabalho relacionados de gerência P2P

Madeira Management System


Adaptive Management Components (AMC):
containers que rodam em um elemento e fazem a
sua gerência e se comunicam com outros AMCs
ManP2P



Management by Delegation: Gerentes podem
delegar tarefas uns aos outros
Orientado a serviços (peers se organizam de acordo
com tarefas que podem realizar)
Suporte a propriedades self-* através de módulos
autônomos de peers
Proposta

Peers executam tarefas através de serviços de gerência



Cada serviço tem um identificador único e vários componentes
responsáveis pelas tarefas
Componentes comunicam a rede seus serviços e fazem sincronia
entre si
Peers são agrupados de acordo com os serviços que
oferecem

Podem participar de mais de um grupo
Proposta

Fornecer propriedade de auto-correção (self-healing)
para sistemas P2PBNM


Monitoramento



Dividido em 2 serviços: monitoramento e correção
Verifica periodicamente estados dos componentes e identifica
falhas
Reporta ao serviço de correção
Correção

Aguarda por falhas a serem corrigidas
Proposta


Auto-correção é atrelada ao elemento a ser gerenciado em
tempo de execução em 3 passos:
Monitoring service identifier: identificador global de requisição de
serviço em um grupo de monitoramento
Serviço de Monitoramento

Requisição de serviço é uma tupla:




(target, workplan, period)
Target: elemento a ser monitorado e informações específicas
(protocolo da camada de transporte, portas, etc.)
Workplan: descrição em alto-nível de como o elemento deve ser
monitorado e os parâmetros que identificam seu estado normal e
anômalo
Period: frequência com que o serviço deve ser monitorado
Serviço de Monitoramento

Workplan distribuído entre log2 n peers

Peers são então organizados em um anel lógico
Serviço de Correção

Requisição de serviço é uma tupla:

(target, workplan)

Target: especificação do elemento gerenciado a ser corrigido



Workplan: descrição em alto nível de como o elemento deve
ter suas anomalias tratadas
Workplan é replicado entre log2 n peers
Caso peer sem workplan necessário seja requisitado este é
responsável por encontrar e repassar para um peer que o
tenha
Interação dos Serviços
Interação dos Serviços


Após executar o workplan de correção envia
notificação de sucesso ou falha

Sucesso → Continua monitoramento

Falha → Interrompe monitoramento
Caso de substituição do elemento monitorado:


Grupo de monitoramento não aborta workplan
Grupo de correção recebe notificação e retorna sucesso para
monitoramento enviando informações sobre como monitorar
novo elemento
Implementação

Construído sobre o sistema protótipo de
gerência P2P: ManP2P-ng



Possui mecanismos de auto-organização e
manutenção para topologias planas P2P (modelo
descentralizado)
Descoberta de recursos por inundação
Fornece uma API que desenvolvedores de
componentes de gerência devem utilizar para
integra-los aos peers
Implementação

API: base para mecanismo de auto-correção

Permite instanciação, inicialização e operação dos
componentes de gerência

Componentes são descritos em XML

Fornece noção de grupos (de serviços neste caso)
Workplan de monitoramento

No evento da recepção da mensagem é checado
se há alguma falha, caso positivo o serviço de
correção é informado
Workplan de Correção

Após receber mensagem de detecção de
problema executa correção, no exemplo o script
healingActivities
Estudo de Caso




Auto-correção para auxílio de um HIDS (Host-based
Instrusion Detection System)
HIDS: Monitora e analiza hosts para verificar se estão
sendo atacados ou comprometidos
Composto por sensores (agentes) que coletam dados
sobre hosts onde estão rodando e enviam para gerente
Cenários de falha:


Sensor falha → sistema deve continuar funcionando
normalmente, administrador pode ser notificado
Gerente falha → notifica administrador e para sensores
Estudo de Caso

Problemas:

Parada de parte ou todo serviço

Brechas de segurança


Necessidade de intervenção manual (inviável para
sistemas grandes)
Falhas frequentes ou comuns podem ser
corrigidas automaticamente
Avaliação




Testado em 2 experimentos em uma overlay com 32
peers e nº variável de sensores
Avaliado:

Tráfego total da gerência da auto-correção

Tempo médio de duração
Primeiro cenário: workplan de correção executado
completamente pelo peer que recebeu notificação do
grupo de monitoramento
Segundo cenário: workplan executado de modo
cooperativo por vários peers
1º Experimento – Tráfego
2º Experimento – Tempo Médio
Conclusão



Os resultados mostram a relação de troca entre
Trafego x Tempo
Plano de correção independente demanda
menos recursos
Plano de correção cooperativo melhor em
situações onde o tempo é crítico
Críticas



Necessário avaliar proposta em cenários mais
complexos e heterogêneos
Questões de segurança não foram tratadas
Faltaram mais detalhes sobre possíveis erros no
sistema de monitoramento/correção