PROGRAMA DE PÓS GRADUAÇÃO PAD / LSI Projeto E-Gov IPT / CIAM

1. Antonio Amorim 2005 Cluster de Servidores Web do IPT Universidade de São Paulo / IPT Escola Politécnica - Engenharia de Sistemas Eletrônicos Pervasive and Distributed Computing Group PROGRAMA DE PÓS GRADUAÇÃOPAD / LSIProjeto E-GovIPT / CIAM

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

3. 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

4. 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

5. Software Livre • Todos Servidores • 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

6. 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)

7. 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)

8. Serviços Web • Serviços de E-Mail • Qmail • 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

9. Serviços Web • WebServer • 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

10. Serviços de Diretório • Bind DNS • 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

11. 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

12. 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

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

14. 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

15. 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

16. 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

17. Balanceamento de carga • 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

18. Balanceamento de carga

19. 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

20. 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

21. IPVS • Balanceamento de carga

22. 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

23. 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

24. 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

25. 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

26. LVS-NAT Arquiteturas LVS

27. 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.

28. LVS-DR Arquiteturas LVS

29. 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

30. LVS-TUN Arquiteturas LVS

31. LVS no IPT • 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

32. LVS-DR no IPT LVS no IPT

33. Conclusões • Situação Atual • 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

34. Conclusões • Próximos Passos • 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

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