PROGRAMA DE PÓS GRADUAÇÃO PAD / LSI Projeto E-Gov IPT / CIAM Universidade de São Paulo / IPT Escola Politécnica - Engenharia de Sistemas Eletrônicos Pervasive and Distributed Computing Group PROGRAMA DE PÓS GRADUAÇÃO PAD / LSI Projeto E-Gov IPT / CIAM Cluster de Servidores Web do IPT Antonio Amorim 2005

Sumário Introdução Visão geral IPVS Arquiteturas LVS no IPT Conclusões

Introdução Projeto E-Gov / IPT Servidores de e-mail em cluster Alta escalabilidade: até 700.000 usuários (8.000.000?) Alta Disponibilidade Melhor relação custo-benefício Colaboração Informal Inicialmente: IPT / LSI / Metrô / Prodesp Atualmente: IPT / LSI Prof. Takeo e colegas Antonio Amorim : Doutorando Vidal Zapparoli : Mestrando Antonio Rigo / Cláudio Marte : planejamento e gestão

Introdução Infra-estrutura Sala de aula do IPT/Cenatec Modificações inesperadas na rede Modificações inesperadas nos computadores Agenda parcialmente previsível Servidores baratos de arquitetura PC Pentium 2, 233 MHz, 128 Mb Ram, 40 GB HD Boa configuração para servidores a 10 anos atrás Uniformidade do hardware facilita o desenvolvimento Rede ethernet a 10 Mbps Vários segmentos Abaixo da velocidade recomendada para o LVS

Software Livre Todos Servidores Servidores de entrada do cluster S.O. -> Debian Linux 3.0 (Woody) Debian Sarge em fase de testes internos Servidores de entrada do cluster Balanceamento de carga -> LVS Alta Disponibilidade -> Heartbeat Servidores Web protocolos SMTP, POP3 e IMAP4 -> Qmail e Courier IMAP WebServer e Webmail -> Apache e Squirrel Mail AntiSpam e Antivírus -> SpamAssassin e ClamAV

Software Livre Servidores Auxiliares Serviço de diretório -> Bind DNS, Open LDAP Firewall e IDS (não implementado) -> IP Tables ? SNORT ? Gerenciamento (não implementado) -> MRTG ? Armazenamento -> NFS e ReiserFS (provisório)

Sistema Operacional Debian Linux 3.0 (Woody) Confiável, estável e seguro Comunidade grande e organizada Utilizado na IPTNet e na USPNet Conhecido pelas equipes do IPT Utilizado como base de distribuições populares Kurumin, Kalango, Knoppix Familiar para muitos profissionais e usuários Atualizado A versão Sarge já se tornou estável As próximas implementações do cluster utilizarão a versão Sarge Kernel com LVS e outras modificações pode ser “empacotado” com dpkg e torna-se facilmente instalável (sem compilação)

Serviços Web Serviços de E-Mail Qmail Courier IMAP POP3, SMTP Alto desempenho, seguro, escalável Utilizado por grandes provedores IG, Yahoo ... Integrável com LDAP Courier IMAP Necessário para o uso de Webmail Integrável com Qmail Integrável com Squirrel Mail

Serviços Web WebServer Webmail Apache Estável e confiável Usado em quase 70% dos servidores da internet Comumente usado no IPT Webmail Squirrel Mail Baseado em IMAP (Courier) Usado pelo Governo do Estado, Prodesp e Metrô Integrável com QMail

Serviços de Diretório Bind DNS Open LDAP Resolução de nomes Não é essencial para a rede interna Open LDAP Banco de dados hierárquico otimizado para leitura Não substitui BDs relacionais, apenas os complementa Permite coerência na segurança de diferentes aplicativos Cadastro de usuários único (single-sign-on) Autenticação Nome, senha, permissões de acesso Direcionamento localização da caixa postal e arquivos do usuário

Serviços de Diretório Open LDAP Flexibilidade: permite várias opções de configuração Servidor Local: cadastro de usuários na própria máquina Servidor externo: cadastro de usuários em servidor remoto Centralizado: cadastro de usuários único fica em um servidor que é acessado por vários clientes Distribuído: cada cliente possui localmente seu próprio cadastro de usuários, parcial e diferente dos demais Hierárquico: cada cliente possui localmente seu próprio cadastro de usuários, que é uma cópia completa ou parcial de um cadastro único localizado em um servidor externo. As cópias devem ser sincronizadas periodicamente ou disparadas por um evento

Serviços de Diretório Open LDAP No projeto E-Gov pode ser adotada a configuração hierárquica ou centralizada, dependendo dos resultados dos testes de desempenho O uso do LDAP permitiu a integração de diversos aplicativos: Qmail: SMTP e POP3 Courier IMAP Squirrrel Mail O LDAP também facilita a integração futura com novos aplicativos e até com o sistema operacional (single-sign-on) Linux pode usar o LDAP p/ autenticação em rede Aplicativos de gerenciamento, groupware, ERP, podem apontar p/ o LDAP evitando a replicação do cadastro de usuários em seus próprios bancos de dados

Serviços de Diretório Open LDAP Atributos usados na integração Qmail+Courier+Squirrel:

Segurança Antivírus ClamAV O módulo Qmail-Scanner integra o Clamav a fila do Qmail Detecção de até 38000 viroses, worms e trojans Pode bloquear anexos por tipo de arquivo. Suporte para RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, MS Cabinet files, MS CHM, MS SZDD Integrável com vários servidores de e-mail Verifica assinaturas de vírus em um banco de dados que deve ser mantido atualizado E-Mails com vírus são gravados em um diretório de quarentena

Segurança AntiSpam SpamAssassin Várias regras para determinar se um e-mail é spam ou não "Fuzzy logic": cada regra tem uma pontuação associada , baseada em sua precisão e nível de acerto. A pontuação pode ser negativa ou positiva As regras são combinadas para calcular uma pontuação total para cada mensagem Se o limite definido pelo usuário é ultrapassado, o e-mail é considerado como spam Nenhuma regra individualmente pode decidir se um e-mail é spam

Segurança SpamAssassin +Qmail+Squirrel O módulo Qmail-Scanner integra o SpamAssassin a fila do Qmail O campo “Subject” da mensagem é marcado com a string “S P A M”, antes do usuário receber a mensagem Uma pasta p/ spam pode ser criada na caixa postal do usuário Uma regra configurada no Squirrel pode filtrar as mensagens marcadas e encaminha-las para a pasta de spam antes de apresentá-las ao usuário O usuário periodicamente deve verificar a pasta, para identificar falsos positivos e limpá-la O usuário pode eventualmente ajustar o limite de pontuação total

Balanceamento de carga LVS: Linux Virtual Server [4] Múltiplos protocolos: HTTP, POP, SMTP, IMAP, FTP, DNS ... IP Virtual: um cluster se servidores aparece como um servidor único, com um único IP Alta disponibilidade: servidores que falham são detectados e retirados do cluster dinâmicamente (módulo IPFAIL) Arquitetura em três camadas Balanceador de carga Conjunto de servidores Storage compartilhado

Balanceamento de carga

Balanceamento de carga LVS: Linux Virtual Server Balanceador de carga: LVS-Director: Servidor que faz a frente de entrada do cluster, recebe as requisições do usuário e as distribui Conjunto de Servidores: real-servers: Servidores que recebem as requisições encaminhadas pelo LVS-director, precessa e devolve a resposta (Qmail, Apache...) Storage Compartilhado: Garante a consistência de dados entre os real-servers. É necessário somente para algumas aplicações Rede de alta velocidade para conectar os componentes 100 Mbps ou 1 Gbps Evita gargalos

Balanceamento de carga IPVS: Internet Protocol Virtual Server Módulo IPVS é o coração do sistema, fazendo o agendamento e controle das requisições Necessário somente no lvs-director Kernel do Linux até a versão 2.4.25 precisa ser modificado p/ suportar IPVS A partir da versão 2.4.26 o IPVS só precisa ser habilitado Intercepta o kernal em dois pontos para pergar os pacotes IP e reescreve-los para suportar balanceamento de carga O IPVS também trata os pacotes ICMP, para facilitar o teste do cluster

Balanceamento de carga IPVS

Balanceamento de carga IPVS: Internet Protocol Virtual Server Duas tabelas tipo Hash Tables são mantidas pelo IPVS Regras: para novas conexões Conexões: para as conexões estabelecidas Cada entrada na tabela de conexão ocupa 128 bytes. 256 MB de memória RAM permitem dois milhões de conexões concorrentes Múltiplos protocolos IPVSADM: permite inserir entradas na tabela das regras cada protocolo tem várias entradas na tabela de regras: IP virtual e porta do protocolo Mapeamento do IP Virtual e porta para cada real-server

Balanceamento de carga IPVS: algoritmos de escalonamento round robin (rr) – alternância simples entre real-servers weighted round robin (wrr) – permite direcionar mais conexões para máquinas mais velozes, pela atribuição de pesos. least connected (lc) - novas conexões são direcionadas para o real-server com a menor quantidade de conexões weighted least connection (wlc) – lc com atribuição de pesos LBLC ,DH: apropriados para real-servers com caches Web (Proxy), pernitem manter a coerência entre os caches dos servidores, evitando acesso desnecessário a servidores externos SH: source hash: apropriado para uso com firewalls que rastreiam conexões

Arquiteturas LVS IP Virtual Deve ser configurado como alias na porta local (lo) do linux director e dos real-servers Para evitar conflitos, os real-servers não devem responder à requisições ARP para a porta local O LVS oferece três Arquiteturas para balanceamento de carga, cada uma apropriada a um tipo de solução: LVS-NAT: Virtual server via NAT LVS-DR: Virtual server via Direct Routing LVS-TUN: Virtual server via Tunelamento

LVS-NAT: Virtual server via NAT Arquiteturas LVS LVS-NAT: Virtual server via NAT Altera MAC-Address do quadro ethernet Recomendado para cluster pequeno e simples LVS-Director e real-servers devem ser conectados por um Hub ou Switch LVS-Director faz a tradução de IP's Resposta das requisições tem que voltar pelo LVS-Director O LVS-Director se torna um gargalo quando o cluster cresce, porque o tráfego fica concentrado sobre ele

Arquiteturas LVS LVS-NAT

LVS-DR: Virtual server via Direct Routing Arquiteturas LVS LVS-DR: Virtual server via Direct Routing Altera MAC-Address do quadro ethernet Recomendado para cluster grande que necessita alto desempenho LVS-Director e real-servers devem ser conectados a um único seguimento físico de rede interna Os real-servers devem ter duas placas: uma conectada à rede interna e outra ao gateway com a Internet Resposta das requisições retorna pela placa do real-server conectada ao gateway Maior eficiência: alterar quadro ethernet é mais rápido que traduzir IP's. Existem múltiplas saídas, aumentando a vasão do sistema.

Arquiteturas LVS LVS-DR

LVS-TUN: Virtual server via Tunelamento Arquiteturas LVS LVS-TUN: Virtual server via Tunelamento Encapsula pacote IP com endereço virtual em pacote IP com endereço dos real-servers Real-servers devem suportar tunelamento de IP, co dispositivo de túnel configurado com IP virtual A resposta retorna ao usuário diretamente, sem passar pelo LVS- Director É mais eficiente que o LVS-NAT, mas menos que o LVS-DR, pois o encapsulamento dos pacotes consome tempo de processamento Ideal quando existem real-servers espalahdos geograficamente, em diferentes sites

Arquiteturas LVS LVS-TUN

Implementação do LVS no IPT Arquitetura LVS-DR Maior desempenho Escalonamento RR: Round-Robin Implementação do Heartbeat Existem 2 LVS-Director. O Heartbeat se encarrega de ativar o que está em “stand-by” se o outro falhar

LVS no IPT LVS-DR no IPT

Conclusões Situação Atual Próximos Passos Cluster com funcionalidade básicas já testadas Caracterização da carga de trabalho - estatísticas / simulação (Artigo WSCAD) Avaliação da escalabilidade do modelo estatístico em função da quantidade de usuários e servidores Próximos Passos Caracterização do cluster - modelagem do sistema Refinamento e complementação do modelo, avaliação de erros Implementação dos geradores de e-mails: Java e Java-Mail Realização dos testes de carga, coletando os dados com SNMP

Próximos Passos Conclusões Estudar as alternativas tecnológicas para a implementação dos softwares de simulação de carga Sistemas multi-agentes, Peer-to-Peer, Grades Computacionais... Estudar alternativas e complementos ao modelo estatístico Teoria das filas Análise espectral Caos Determinístico e fractais Wavelets Estudar as alternativas para simulação do sistema e o ambiente da Internet

Dúvidas? Antonio Amorim acoamorim@pad.lsi.usp.br amorim@ipt.br