MODELO TECNOLGICO DO EXPRESSO EM NUVEM Verso da Comunidade Expresso Primeira Fase Verso 1.

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

Sumrio
1 Introduo..............................................................................................................................4 2 Objetivo..................................................................................................................................4 3 Escopo do Expresso em Nuvem...........................................................................................5 3.1 Servio Ldap e Catlogos..............................................................................................5 3.2 Tamanho das instituies integrantes............................................................................5 3.3 Banco de Dados.............................................................................................................6 3.4 Login nico.....................................................................................................................6 3.5 Expresso Offline e arquivamento local..........................................................................6 3.6 Certificao Digital.........................................................................................................6 3.7 Gerenciamento...............................................................................................................6 3.8 Personalizaes.............................................................................................................7 3.9 Software como Servio..................................................................................................7 3.10 Forma de acesso..........................................................................................................7 3.11 Mobilidade....................................................................................................................8 3.12 Integrao com a Datavrev.........................................................................................8 3.13 Monitoramento............................................................................................................9 3.14 Mensageiro Instantneo...............................................................................................9 4 Descrio da arquitetura do Expresso..................................................................................9 4.1 Topologia a ser utilizada na fase inicial do Expresso em Nuvem...............................10 4.1.1 Servio web: nica instncia de cdigo................................................................10 4.1.1.1 Detalhes tcnicos da soluo........................................................................11 4.1.2 Banco de dados: disponibilidade e balanceamento de carga..............................12 4.1.2.1 Detalhes tcnicos da soluo........................................................................13 4.1.3 Servio IMAP: escalabilidade e balanceamento de carga...................................15 4.1.3.1 Detalhes tcnicos da soluo........................................................................16 4.1.4 Servio LDAP: disponibilidade, escalabilidade e balanceamento de carga.........17 4.1.5 Servio SMTP: disponibilidade, escalabilidade e balanceamento de carga........18 4.2 Funambol: disponibilidade, escalabilidade e balanceamento de carga......................19 4.3 Monitoramento.............................................................................................................19 4.4 Servio de listas...........................................................................................................20 5 Laboratrio do Expresso em Nuvem...................................................................................21 5.1 Plano de testes para o laboratrio...............................................................................22 5.1.1 Testes de funcionalidades....................................................................................22 5.1.2 Testes de recuperao de falhas.........................................................................23 5.1.3 Testes de desempenho........................................................................................23 5.1.4 Testes de falhas sobre carga................................................................................24

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

CONTROLE DE VERSES
Verso 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 Contedo Criao do Documento Aprimoramento do escopo tcnico Ambiente de Teste Dados sobre a Reunio com a Dataprev Alterao da proposta inicial de arquitetura Incluso das configuraes de DMZ Incluso das alteraes no Pgpool Incluso das modificaes para Cyrus Integrao da documentao existente Incluso de dados do laboratrio e adequao comunidade Expresso Data 24/06/10 08/07/10 26/07/10 06/08/10 10/08/10 12/08/10 16/08/10 03/09/10 13/09/10 14/01/11 Autores Equipe tcnica reunida em Porto Alegre Equipe SITCE Equipe SITCE Equipe SITCE Equipe SITCE Equipe SITCE Equipe SITCE Equipe SITCE Equipe SITCE Equipe SITCE

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

1 Introduo
O Expresso em Nuvem tem o objetivo de ser uma sute de comunicao a ser utilizada por diferentes instncias de governo do Brasil. Prefeituras, governos estaduais, ministrios e instituies federais podero empregar o mesmo ambiente para suprirem suas necessidades de comunicao. A ideia que norteia o modelo do Expresso em Nuvem integrar essas instituies dando ampla possibilidade de comunicao entre todos os clientes desse modelo de Expresso. Funcionalidades como webmail, agenda, catlogo, mobilidade, certificao digital e mensageiria instantnea estaro disponibilizadas para possibilitar que o Expresso em Nuvem seja uma ferramenta facilitadora da comunicao dentro de cada instituio e entre cada instituio. O Serpro e a Dataprev firmaram, em meados de 2010, um acordo de cooperao tcnica e comercial para a elaborao e a implantao do modelo em nuvem para o Expresso. Esse acordo j possibilitou que algumas decises tcnicas fossem aqui utilizadas para possibilitar a futura integrao das infraestruturas do Expresso de ambas as empresas. O projeto do Expresso em Nuvem ser dividido inicialmente em duas etapas. Tecnicamente, na fase inicial o Expresso ser implantado sobre uma infraestrutura o mais escalvel possvel, contando com balanceamento de carga e alta disponibilidade. A fase posterior contemplar maiores alteraes de cdigo que visem a melhora de performance, uma maior integrao entre o Serpro e a Dataprev e outras atividades tcnicas que se mostrem necessrias. A etapa dois iniciar aps o primeiro cliente adentrar no ambiente.

2 Objetivo
Este documento, direcionado comunidade Expresso, apresenta o andamento tcnico da construo do modelo tecnolgico para o Expresso que seja mais aderente aos conceitos da computaco em nuvem. Embora algumas pequenas alteraes no cdigo dessa ferramenta j tenham sido realizadas, as solues tecnolgicas aqui apresentadas envolvem principalmente modificaes na infraestrutura e na lgica de funcionamento dos servios que compem o Expresso. At o primeiro cliente ser implantado no Expresso em Nuvem, o Serpro estar testando em laboratrio as funcionalidades, a escalabilidade e a performance do modelo implantado. Dependendo dos resultados desse laboratrio algumas alteraes podem ainda ser realizadas.

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

3 Escopo do Expresso em Nuvem

O modelo tecnolgico do Expresso em Nuvem est embasado nas caractersticas dos recursos a serem disponibilizados pela ferramenta. Abaixo, separados pelos tipos de servios disponibilizados, seguem os detalhes que compem o escopo do Expresso em Nuvem. O escopo dos servios a serem disponibilizados ainda no est fechado. Assim sendo, este documento est em contnua mudana. At ento, todos os servios esto sendo disponibilizados em mquinas virtuais. Mesmo que haja certa perda de performance por causa da virtualizao, a facilidade da gerncia de mquinas virtuais comparadas aos servidores reais faz essa opo, alm de mais aderente ao modelo de cumputao em nuvem, muito mais adequada a um ambiente que precisa ter considervel escalabilidade. 3.1 Servio Ldap e Catlogos

Todos os clientes tero suas entradas ldap localizadas abaixo de dc=expresso,dc=gov,dc=br. Assim sendo, uma determinada prefeitura, por exemplo, poder ter suas entradas ldap inseridas abaixo de ou=prefeitura,dc=expresso,dc=gov,dc=br. Ser possvel tambm, dependendo do modelo de gerncia do Expresso adotado por tal prefeitura, criar setores, regionais ou algum outro tipo de segmentao no ramo ldap da instituio. Todos os servios do ambiente Expresso que realizam consultas e autenticaes no ldap utilizaro a base de consulta dc=expresso,dc=gov,dc=br. Dessa forma, todos os clientes do modelo de nuvens conseguiro pesquisar informaes de todos os outros integrantes do ambiente. De incio, as instituies do Expresso em Nuvem no podero agregar catlogos de endereos prprios. Se um integrante j possuir um catlogo ldap (Fedora-ds, Active Directory, Openldap, etc) esse, de incio, no poder ser integrado aos catlogos do Expresso porque isso faria tal catlogo necessitar ser apresentado a todas as outras instituies participantes. possvel que o Expresso, no futuro, possa ter o recurso de apresentao de catlogos por instituio (por unidade organizacional - ou). 3.2 Tamanho das instituies integrantes

O modelo em nuvem possibilitar que instituies de diferentes tamanhos possam integrar o ambiente, pois o custo operacional de implantar um novo cliente no parque de servidores ser baixo. Assim sendo, ser possvel que ministrios do Governo Federal estejam hospedados nos mesmos recursos de hardware que prefeituras de pequenas cidades.

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

3.3

Banco de Dados

Uma das novidades do modelo tecnolgico do Expresso em Nuvem est na forma com que o banco de dados ser empregado. Todo o Expresso em Nuvem utilizar o mesmo banco de dados, permitindo que usurios das diferentes instituies possam comunicar-se atravs de agendamentos, email, mensageiro instantneo, catlogo, etc. 3.4 Login nico

Todos os clientes do Expresso em Nuvem logar-se-o utilizando o CPF. Como as caixas corporativas tambm precisaro ter login nico, ser necessria a incluso do nome da organizao ao identificador dessas caixas. Se o cliente Prefeitura de Caruaru, por exemplo, necessitar criar uma caixa corporativa para os gerentes esta poderia chama-se gerentes-caruaru. Inicialmente, o Expresso em Nuvem no utilizar domnios virtuais. importante que essa caracterstica no seja confundida com os vrios domnios de email que o Expresso poder utilizar. Nada impede, por exemplo, que a caixa gerentes-caruaru tenha o endereo de email gerentes@caruaru.pe.gov.br. 3.5 Expresso Offline e arquivamento local

As funcionalidades de Expresso Offline e Arquivamento local com o Google Gears sero disponibilizadas para todos os clientes. Essas funcionalidades so de fundamental importncia para usurios que possuem pequena cota de mensagens. Apesar da Google j ter parado de desenvolver o Gears, essa soluo demonstrou-se eficaz na implementao do arquivamento local. Outras solues j esto sendo estudadas e desenvolvidas no Serpro para suprirem as tarefas executadas pelo Gears. 3.6 Certificao Digital

As funcionalidades de login por certificado, assinatura digital e criptografia tambm estaro disponveis aos integrantes. Embora essas funcionalidades ainda estejam acopladas forma de login e ao formato no padronizado das informaes constantes nos certificados das diferentes autoridades certificadoras, esses recursos j esto bastante estveis e possuem relevada importncia s instituies que primam pela segurana de suas informaes. 3.7 Gerenciamento

Como o Expresso j possibilita que sejam criados gerentes com permisses especficas sobre certos ramos ldap, ser possvel determinar que um usurio administrador tenha permisses de criao e remoo de contas cadastradas abaixo de apenas um container da base ldap. Esse ramo poderia agregar toda a instituio ou apenas determinados setores dela, facilitando o seu

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

gerenciamento. Foi testado em laboratrio o novo recurso de gerenciamento de cotas por dn ldap. Com essa facilidade, o administrador do Serpro ter condies de atribuir limites de cotas que seriam utilizadas em cada instituio. 3.8 Personalizaes

Sero permitidas personalizaes de temas. Embora as personalizaes no Expresso de cada cliente dificultem a gerncia desse servio quando em nuvem, um maior nvel de personalizao acarreta melhor aceitao da ferramenta. Determinados clientes podero operar com temas especficos que contenham as identificaes visuais da instituio. Mesmo que esse tipo de personalizao no seja necessria a todos os clientes (pode ser oferecida como um adendo de contrato), ser criado um pacote contendo o cdigo do Expresso e outro contendo apenas o conjunto de temas para o template Serpro. Dessa forma, a incluso de um novo tema no acarretar a criao de uma nova reviso do Expresso, facilitando a tarefa de manter uma mesma verso/reviso para todos os clientes. 3.9 Software como Servio

O Expresso em Nuvem ser disponibilizado no modelo de software como servio (SaaS). Se o Serpro optasse por um modelo de infraestrutura como servio (IaaS), isso incorreria em um aumento expressivo da complexidade do gerenciamento de vrios clientes. Mesmo que fossem utilizadas ferramentas automatizadas para gerenciar o funcionamento das mquinas virtuais, tarefas como a atualizao do Expresso, atualizao de pacotes de software integrantes da arquitetura e a verificao de erros relatados pelos usurios (no encontrados nas homologaes e testes) seriam enormemente dificultados. 3.10 Forma de acesso

Todos os clientes utilizaro o mesmo endereo para acessar o Expresso (http://expresso.gov.br), sendo diferenciados apenas por um /cliente ao final da URL. O usurio acessar a ferramenta atravs de uma URL de forma semelhante ao padro http://expresso.gov.br/<cliente>. Caso o /cliente seja esquecido, o usurio acessar o Expresso em Nuvem utilizando um tema padro. Essa forma de acesso trouxe vantagens e desvantagens que merecem ser esclarecidas: 1. Vantagens: 1. Utilizao de apenas um certificado HTTPS para todas as instituies, sem a necessidade de modific-lo a cada novo integrante. 2. Maior facilidade de gerenciamento em comparao soluo com mltiplas instncias.

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

3. Maior aderncia com os conceitos da computao em nuvem em relao opo de mltiplas instncias. 4. A personalizao ser apresentada inclusive da tela inicial (tela de login) mesmo que no haja um cookie previamente configurado. 5. Permitir que seja empregada uma nica instncia do cdigo do Expresso para todos os clientes. 6. No futuro podero ser utilizados os conceitos de domnios virtuais dos servidores IMAP. 2. Desvantagens: 1. Necessidade de alterao da aplicao. Essas alteraes j foram realizadas. 2. URL mais complexa e fora dos padres usuais. 3. Como o tema a ser utilizado ser definido por qual /cliente o usurio utilizar, um cliente poder logar no Expresso com o tema de outra instituio. 3.11 Mobilidade

O acesso a dispositivos mveis pelo Expresso em Nuvem se dar por quatro formas distintas: 1. Acesso interface web do Expresso Mini: o Expresso j possui uma interface web leve que facilita o acesso ao sistema via dispositivos mveis. Essa interface pode ser acessada com a incluso de um /mobile ao final da URL. Esse tipo de acesso no possui o recurso de temas. 2. Acesso atravs do Funambol: o Funambol possui um cliente de mail, catlogo e agenda que pode ser instalado em muitos dispositivos mveis. A url https://funambol.serpro.gov.br apresentar maiores detalhes sobre downloads de certificados e downloads de clientes; 3. Acesso direto via proxy IMAPs e SMTPs: essa forma de acesso permitir que outros dispositivos mveis, inclusive aqueles que ainda no possuem suporte ao Funambol, possam utilizar o sistema de email do Expresso em Nuvem. 4. ActiveSync: permite a sincronizao com dispositivos mveis atravs do protocolo Microsoft ActiveSync. Embora esse recurso no tenha sido elencado inicialmente como uma das funcionalidades do Expresso em Nuvem, ele provavelmente integrar o conjunto de facilidades do ambiente. 3.12 Integrao com a Datavrev

Em reunio realizada na Dataprev nos dias 3 a 5 de agosto de 2010 na cidade do Rio de Janeiro foi acordado que, por motivos estratgicos, o Serpro e a

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

Dataprev cooperariam na implantao do Expresso em Nuvem. Em conformidade com a ferramenta IMAP, que j foi implantada em produo na Dataprev, o modelo tecnolgico do Expresso em Nuvem tambm ir utilizar Cyrus Aggregator como forma de facilitar uma futura integrao das infraestruturas das duas empresas. Haver a possibilidade de, de acordo com parmetros de localizao geogrfica ou acordos operacionais, algumas caixas do Expresso em Nuvem estarem hospedadas nos ambientes da Dataprev enquanto outras, no datacenter no Serpro. 3.13 Monitoramento

A exemplo do que j acontece com os ambientes do Expresso hoje em produo, o modelo em nuvem ser monitorado diretamente pelo Zabbix e, de forma mais ampla, pelo Farol. Com essas ferramentas de monitoramento, ser possvel ter imediata cincia dos problemas que venham a ocorrer no Expresso em Nuvem, sabendo se a gravidade de tais incidentes podem comprometer a qualidade dos servios, a disponibilidade ou, em ltima anlise, o nvel de servio acordado com o cliente. 3.14 Mensageiro Instantneo

O modelo do Expresso em Nuvem possuir o recurso do mensageiro instantneo (IM) Jabber. Os integrantes do ambiente em nuvem podero comunicar-se via IM, independentemente de qual instituio pertenam.

4 Descrio da arquitetura do Expresso

A tabela abaixo apresenta os servios necessrios operao do Expresso. Dependendo da carga a qual o servio ser submetido e das possibilidades tcnicas criadas pela lgica de funcionamento de tal servio, cada um desses utilizar diferentes formas de aderir aos preceitos da computao em nuvem.
Servios do Ambiente Expresso WEB PROXY WEB SMTP IMAP BANCO DE DADOS (SGBD) LDAP Disponibiliza a interface do Expresso Acrescentado infraestrutura por questes de segurana, realiza o repasse das requisies web e das requisies do Funambol. Utilizado para o envio e recebimento de emails Empregado no armazenamento e leitura de mensagens Utilizado para o armazenamento de agendamentos, contatos e outras informaes necessrias ao Expresso. Empregado na autenticao de usurios e nas consultas por catlogos corporativos

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

JABBER FUNAMBOL MONITORAMENTO

Utilizado no servio de mensagens instantneas Realiza a integrao do Expresso com dispositivos mveis Realiza o monitoramento de todo o ambiente Expresso

A seguir sero demonstradas as principais caractersticas de cada um dos componentes da arquitetura inicial (Fase 1) do Expresso em Nuvem. 4.1 Topologia a ser utilizada na fase inicial do Expresso em Nuvem

A arquitetura a ser empregada na fase inicial do Expresso em Nuvem est apresentada na Figura 1. 4.1.1 Servio web: nica instncia de cdigo

Para alcanar o objetivo de ser utilizada apenas uma instncia do Expresso foi necessrio realizar alteraes no cdigo da aplicao e na configurao dos proxies. Essas modificaes j foram realizadas e j esto em operao. O modelo proposto para o servio web possui as seguintes caractersticas gerais: Ser criado um tema padro para o caso do cliente no informar qual o tema ser utilizado. A informao do tema, que armazenada em cookie, ser perdida caso o navegador do usurio feche repentinamente. Nesse caso, o usurio dever escolher novamente acessar o ambiente atravs de sua URL especfica.

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

Figura 1: Arquitetura inicial do Expresso em Nuvem

4.1.1.1

Detalhes tcnicos da soluo

Abaixo h um resumo das tarefas executadas pelos proxies:

No conceito de nuvem apenas um virtual host do Apache ser utilizado, ou seja, todos os clientes tero um mesmo domnio; Todos os clientes sero direcionados para um nico cdigo do Expresso. Cada FrontEnd web ter apenas um virtual host e um cdigo do Expresso. Cada cliente ter um tema, que ser definido pelo proxy, atravs do uso de um cookie que baseado no domnio. O proxy Apache far cache, balanceamento de carga e SSL. A utilizao de um proxy, alm de melhorar a performance do ambiente, contribui no incremento da segurana do ambiente.

O virtual host do Apache incluir um cookie denominado THEME, que contm a informao sobre o diretrio no qual os FrontEnds do Expresso devero

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

buscar o tema para aquele usurio especfico. O contedo desse cookie o nome do tema para um determinado cliente. Sendo assim, cada cliente que optar por um tema exclusivo dever digitar a URL da sua instituio para acessar o Expresso. Os proxies, por sua vez, fazem um rewrite inserindo o cookie com o nome do tema para a URL base do Expresso toda vez que a URI do tema for digitada no browser. Como exemplo, a configurao abaixo seria includa no virtualhost do proxy para que o cliente pudesse utilizar o tema da prefeitura x.
RewriteCond %{REQUEST_URI} ^/prefeiturax RewriteRule ^/(.*)$ https://%{SERVER_NAME} CO=THEME $1:.expresso.gov.br,L,R]

O cookie THEME possui validade at que o browser seja fechado ou que esse cookie seja excluido. Isso acarreta que, se o usurio no entrar com a URI /nomedocliente ou ento o browser fechar e abrir novamente, esse usurio ter novamente o tema padro do Expresso em Nuvem. 4.1.2 Banco de dados: disponibilidade e balanceamento de carga

A ferramenta escolhida para realizar a replicao sncrona do PostgreSQL foi o Pgpool (Figura 2). Esse servio se tornar o ponto central de entrada para todas as inseres e consultas ao banco. Sua alta-disponibilidade ser garantida pelo uso do Heart-Beat. Com exceo dos tunings, a nica alterao nos bancos de dados que contero as informaes replicadas ser aquela que permitir escritas vindas apenas do Pgpool. Abaixo so apresentadas algumas peculiaridades da soluo implementada.

H a possibilidade de haver muitos backends. Como a escrita sncrona, isso incorre em um aumento no tempo de escrita e uma diminuio do tempo mdio de leitura ao banco de dados. No entanto, levando em considerao que o Expresso realiza operaes de leitura em mais de 90% dos acessos ao banco de dados, mesmo com a limitao apresentada, esse modelo de replicao e balanceamento de carga pode ser implantado na infraestrutura inicial do Expresso. O Pgpool um ponto central de falhas. Entretanto, alm de, como j foi exposto, poder possuir alta-disponibilidade atravs do Heart-beat, esse software no consome grandes recursos de processamento. A performance dessa ferramenta j est sendo massivamente testada em laboratrio. Essa soluo, alm de ser razoavelmente simples de ser implementada, no requer que sejam realizadas alteraes no banco da aplicao. Algumas tabelas do Expresso no possuem chaves primrias o que dificultaria a utilizao de outras solues de replicao. A soluo proposta no inviabiliza que outras tcnicas de replicao sejam aplicadas nos servidores de backend. Se o Expresso vier a possuir o

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

recurso da diferenciao no apontamento do banco de dados de escrita e de leitura, seria possvel criar um site backup do Expresso em Nuvem em outros locais da Internet. Isso ser melhor estudado na segunda fase do subprojeto.

Figura 2: Arquitetura de altadisponibilidade e balanceamento de carga para o PostgreSQL

4.1.2.1

Detalhes tcnicos da soluo

Uma falha na rede poderia ocasionar inconsistncias nos Postgres. Nesse caso o Pgpool retira de operao um dos bancos de dados para evitar que a inconsistncia seja repassada a operao do banco. Para recolocar em produo um banco de dados marcado como indisponvel por algum problema de replicao, necessrio parar todos os bancos e reinici-los, gerando uma indisponibilidade temporria no Expresso. Se uma dessas falhas vier a ocorrer, os bancos de dados podero ser reinicializados durante a madrugada. As verses 2010, v2.3.x, do Pgpool2 resolvem alguns problemas crticos da replicao sncrona de PostgreSQL: as seqncias seriais e as funes que envolvem operaes com datas. As verses 2.3.x adotam a abordagem de eleger um master e enviar as funes de tempo originais a esse, recolhendo os resultados e reescrevendo as queries para embut-las nos outros backends. Para garantir consistncia de sequncias entre servidores, foi ativada a opo de travar tabelas durante o perodo de uma transao que envolva uma funo desse tipo. O Pgpool2 v2.3.x permite uma soluo de replicao no intrusiva aos backends. No necessrio realizar alteraes nas configuraes desses para o correto funcionamento da soluo. Isso gera a vantagem de, em caso de desastres, poder ser utilizado diretamente o banco de um dos backends. O Pgpool2 v2.3.x intercepta as queries e as reescreve, se necessrio, antes

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

de envi-las aos servidores backend. Durante os testes foi identificada a necessidade de alterar cdigo do Pgpool2 para que ele processasse corretamente campos de tempo e timestamps com valores default com cast para big int. Isso foi necessrio por causa de algumas peculiaridades da modelagem do banco de dados do Expresso. O Serpro (SITCE) apresentou esse problema ao projeto do Pgpool, na thread http://lists.pgfoundry.org/pipermail/pgpool-general/2010August/002888.html que resultou em alterao de cdigo no repositrio de desenvolvimento. Assim, atualmente, est sendo utilizado uma verso do Pgpool ainda no lanada oficialmente, a 2.3.4, que tem poucas, mas crticas para o Expresso em Nuvem, modificaes sobre a verso 2.3.3. Questes sobre a Escolha pela replicao sncrona com Pgpool2: A replicao sncrona master-master de bancos de dados um problema de soluo nada trivial mas que, com o uso do Pgpool2, tornou-se vivel, trazendo vantagens aderentes ao contexto do Expresso em Nuvem. A replicao transparente para a aplicao cliente (Expresso). Ocorre chaveamento (failover) automatizado em caso de falha, com temporizao configurvel. H um tempo de indisponibilidade prximo de zero. Nenhuma perda de dados ocorre em caso de falhas individuais dos backends. No existe janela de tempo em que ocorreriam perdas de dados, como haveria no caso da replicao assncrona. H uma maior garantia de consistncia de leitura de dados entre quaisquer dos backends, mesmo sob carga mxima. Uma leitura sempre receber dados atualizados e consistentes em qualquer momento. O plano de contingncias facilitado em relao a outras possibilidades de replicao e balanceamento de carga. H a possibilidade da construo de uma arquitetura modular que possibilitaria ter replicao sncrona e assncrona num mesmo cluster de servidores e, se necessrio, em diferentes nveis hierrquicos. A deficincia principal da replicao sncrona na verso 2.3.x do Pgpool2 so as escritas serializadas. Cada novo servidor backend adiciona seu tempo de resposta ao tempo final para ter concluda uma operao de escrita ao cluster de servidores. Dependendo do perfil da aplicao, pode ou no ser uma soluo adequada. Para que ocorra um impacto mnimo ao usurio, tambm necessrio que os backends estejam conectados por redes de alta velocidade e baixa latncia.

No laboratrio do Expresso em Nuvem que est sendo neste momento realizado, o modelo do banco de dados, devido forma como o Expresso utiliza esse servio, j est sendo reavaliado, pois o Expresso atualmente possui alguns

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

problemas de performance no acesso ao banco de dados. Na tabela de preferncias por exemplo, o Expresso, para cada usurio logado, exclui um determinado registro da conta default, recriando-o dentro de uma mesma transao. Esse tipo de comportamento do cdigo j est sendo analisado para que alteraes possam ser propostas. O PostgreSQL que est sendo atualmente utilizado o 8.3. No entanto, alguns testes com a verso 9.0, que traz a replicao nativa, esto sendo realizados. 4.1.3 Servio IMAP: escalabilidade e balanceamento de carga

O projeto inicial do servidor de e-mail Cyrus no possua escalabilidade. No entanto, existe um complemento, denominado Cyrus Aggregator (antigo Cyrus Murder), desenvolvido pela prpria Carnegie Mellon University (CMU), mantenedora do projeto Cyrus, para agregar escalabilidade ao projeto inicial. A arquitetura do Aggregator constituda, basicamente, por um draft de protocolo denominado Mupdate. O servidor Mupdate responsvel por interligar vrios servidores Cyrus, denominados backends. A aplicao acessa os backends, de forma transparente, atravs de um ou mais servidores chamados frontends. Todos esses servidores se comunicam atravs do protocolo Mupdate e IMAP para realizar operaes na caixa de e-mail do usurio final. A arquitetura do servidor IMAP est apresentada na Figura 3.

Figura 3: Arquitetura fsica do Cyrus Aggregator

A Dataprev j utiliza em produo uma infraestrutura semelhante apresentada na Figura 3. A meta dessa empresa criar contas IMAP para mais de 60 mil usurios. Com o acordo de cooperao entre o Serpro e a Dataprev, a escolha desse software para prover o servio IMAP teve como grande vantagem a possibilidade de, no futuro, integrar as infraestruturas de correio entre ambas

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

as empresas. O Cyrus ainda o nico servidor IMAP conhecido que tem o recurso de caixas postais compartilhadas num mesmo espao de endereos que englobe vrios servidores operando em conjunto de forma transparente aos programas clientes. O programa Dovecot, tambm amplamente estudado pelo Serpro, possui vrias outras vantagens tcnicas de segurana, modularidade, flexibilidade de armazenamento, escalabilidade horizontal e simplicidade. No entanto, o ainda ausente recurso de caixas postais compartilhadas, na forma citada, tambm foi um fator decisivo na escolha pelo Cyrus. Recentemente o Serpro adquiriu um storage da IBM que ser dedicado ao Expresso. Esse equipamento, atravs de recursos de snapshot, possui rpida recuperao de arquivos pequenos, sendo ideal para a operao do Cyrus, onde cada email um arquivo no sistema. Assim sendo, a disponibilidade da soluo implementada ser garantida pelos recursos de storage e backup utilizados. Com a arquitetura apresentada na Figura 3, a infraestrutura de correio eletrnico poder crescer horizontalmente num limite muito alto, potencialmente at alguns milhes de contas, se colocada sobre infraestrutura de hardware, rede, storage, e sistemas de arquivos adequados. Isso pois o ponto de afunilamento, o servidor de coordenao Mupdate master, sofre uma carga computacional bastante baixa, pois utilizado apenas nas criaes, edies e remoes de caixas ou subpastas IMAP. 4.1.3.1 Detalhes tcnicos da soluo

Abaixo so apresentadas algumas peculiaridades do Cyrus Aggregator na operao conjunta com o Expresso em Nuvem:

Foi utilizada a configurao Cyrus Aggregator que emprega servidores backends, local onde as caixas postais so armazenadas, um servidor coordenador do Aggregator (Mupdate master), que define e informa onde estaro as caixas postais e suas pastas e servidores "proxy/frontend", que servem de ponto de comunicao com o Expresso. Para que a escalabilidade do Cyrus funcione corretamente, todos os servidores Mupdate, frontends e backends devem estar na verso 2.3 (ou superior) do Cyrus. Em sua maior parte, o Expresso funciona perfeitamente sobre a arquitetura do Aggregator. Um problema j identificado foi que o Php no possua uma funo capaz de definir em qual servidor backend a caixa de um determinado usurio seria criado. A alternativa encontrada foi criar todas as caixas em um backend padro e deixar a cargo do Cyrus a distribuio entre os backends. No entanto, mesmo essa alternativa apresentava restries. Em testes realizados sobre o Aggregator, quando era solicitada a criao de uma nova caixa no frontend, esse realizava a

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

operao localmente, deixando de realiz-la nos backends como era o esperado. Para corrigir o problema acima exposto, o Serpro desenvolveu um conjunto de correes do cdigo do Cyrus disponibilizado pelo Projeto Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595370). Com essas correes j submetidas ao Debian, o Expresso em Nuvem poder utilizar o Aggregator de forma segura. Tambm foram enviados patches para anlise da comunidade Cyrus da Carnegie Mellon University
(http://asg.andrew.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&msg=51077).

Como o Serpro utiliza o Debian GNU/Linux para o Expresso, foi empregada uma verso dos repositrios internos do Projeto Debian para base de nosso laboratrio local. Tal verso (branch hmh) Debian baseada no cdigo Cyrus 2.3.16 que j tem aproximadamente 3 anos de lanamento e alcanou boa estabilidade. Provavelmente antes do teto no Cyrus mupdate master, sero alcanados os limites de trfego de rede, sendo ento necessrio outros estudos de performance de rede com bonding para agregao de banda. Com o conjunto de correes desenvolvidas para o servidor Cyrus em configurao Murder/Aggregator, tem-se agora a seguinte situao:

A operao do Aggregator transparente ao usurio, mesmo que esse utilize outros clientes de IMAP (Thunderbird ou clientes para dispositivos mveis); O compartilhamento de caixas postais num mesmo espao de endereos entre diversos servidores backend est funcional. O controle total sobre os critrios de alocao final de caixas postais por diferentes servidores backend est operacional; A boa escalabilidade horizontal entregada pelo Aggregator est perfeitamente acoplada ao Expresso.

4.1.4

Servio LDAP: disponibilidade, escalabilidade e balanceamento de carga

O modelo tecnolgico do ldap criado e gerenciado pela equipe do CEDN (Serpro So Paulo) j possui alta disponibilidade, prevendo a operao de servidores masters e slaves da base ldap (Fedora-ds). Como o Expresso j possui configuraes que permitem diferenciar entre bases LDAP de escrita e bases LDAP de leitura, a alta disponibilidade, escalabilidade e balanceamento de carga desse servio j esto bem consolidados e em produo em todos os ambientes da verso 2 do Expresso. A Figura 4 apresenta a arquitetura fsica desse servio.

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

Figura 4: Arquitetura fsica inicial do Ldap

Os servidores ldap de escrita so muito pouco utilizados em comparao aos servidores de leitura. Os servidores LDAP master so utilizados apenas nas seguintes operaes:

Quando o usurio tem sua senha expirada; Quando o usurio troca a senha por vontade prpria; Quando o usurio atualiza seu telefone; Nas operaes envolvidas com a administrao de contas;

Como j foi apresentado na seo que tratava do escopo do Expresso em Nuvem, todas as entradas LDAP dos usurios e instituies participantes ficaro abaixo do dn dc=expresso,dc=gov,dc=br. As unidades organizacionais sero criadas abaixo desse dn e, de acordo com o modelo de gerncia do Expresso em nuvem contratado pelo cliente, poder-se- criar setores ou outras formas de diviso (por regional, por exemplo) que facilitem e viabilizem a administrao por gerentes que possuiriam permisses apenas em determinados segmentos ldap da instituio. 4.1.5 Servio SMTP: disponibilidade, escalabilidade e balanceamento de carga

De forma semelhante s configuraes do LDAP, a alta disponibilidade do SMTP ser dada por um switch balanceador. Todos os emails que forem enviados ao Expresso em Nuvem ou deste sarem passaro pela arquitetura do balanceamento do Postfix. A Figura 5 demonstra a arquitetura utilizada para o SMTP do Expresso em Nuvem. Como esse servio ser desempenhado por servidores virtualizados que estaro ligados a storages de alto desempenho e disponibilidade, no ser necessrio acoplar equipamentos de storage para armazenarem as filas de mensagens. No servio SMTP assim como em todos os outros que possuem escalabilidade ou balanceamento de carga, se houver necessidade de entregar maior processamento ao servio, outros servidores com semelhantes

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

configuraes podero ser utilizados, bastando que o switch balanceador passe a entregar mensagens tambm ao novo servidor.

Figura 5: Arquitetura fsica inicial do SMTP

4.2

Funambol: disponibilidade, escalabilidade e balanceamento de carga

O servio Funambol ser utilizado por todos os clientes do Expresso em nuvem. A sua escalabilidade, balanceamento de carga e disponibilidade, a exemplo dos proxies web, ser garantida pelos switches balanceadores configurados com o stick (Figura 6). O stick responsvel por prover o mapeamento IP_origem servidor_balanceado.

Ilustrao 6: Arquitetura fsica inicial do Funambol

Monitoramento Embora o monitoramento realizado pelo Zabbix esteja representado na Figura 1 como um servio disponibilizado por servidores no modo ativo-passivo, o Serpro utiliza um banco de dados Mysql para armazenar todos os dados coletados dos servidores em operao. Assim sendo, possvel disponibilizar esse banco de dados em um servidor dedicado e utilizar outros servidores para realizarem a apresentao web, o processamento de alarmes, etc. No entanto, com o conhecimento emprico obtido atravs da experincia com a operao do Zabbix, possvel iniciar a operao do Expresso em Nuvem

4.3

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

sem precisar, necessariamente, criar o balanceamento de carga para esse servio. Evidentemente, com o crescimento do Expresso em Nuvem, o monitoramento tambm precisar ser melhorado em termos do processamento a ele dedicado e da arquitetura fsica por ele empregada. 4.4 Servio de listas Ainda no foram feitos testes de funcionalidade relativos ao servio de listas. A comunidade Expresso utiliza listas por alias do Postfix enquanto o Serpro adaptou o Expresso para utilizar o servio de listas sobre o Mailman. Abaixo segue uma pequena comparao entre as duas solues.

Listas por aliases do Postfix Vantagens: No requer que novos servidores sejam instalados; A alta disponibilidade, balanceamento de carga e escalabilidade j estariam resolvidos com o Postfix; J largamente utilizado na comunidade do Expresso; Desvantagens: Possui menos recursos que as listas do Mailman. No entanto, ser necessrio avaliar quais dos recursos do Mailman so realmente utilizados nos ambientes que j o possuem. Listas no Mailman Vantagens: Possuem maiores recursos de controle de envio, filtros, etc. A disponibilidade pode ser garantida com servidores ativos e passivos sobre mquinas virtuais. Desvantagens: O balanceamento de carga e a escalabilidade no so triviais. Para criar o balanceamento de carga seria necessrio exigir que todos os servidores de listas contivessem os mesmos dados no banco de dados do Mailman que, at a verso estudada, seria local e prprio. Os frontends do Expresso enviam dados ao Mailman todas as vezes que uma determinada lista editada, criada ou removida. Essa forma de funcionamento parte do princpio que o servidor de lista nico. Por isso, a criao de algum balanceamento de carga exigir que alteraes no cdigo do Expresso sejam criadas. Embora tenha sido gerado um mdulo no Expresso especfico para gerenciar os recursos de listas, muitas das opes avanadas (as que no esto presentes nas listas do Postfix, por exemplo) necessitam ser ajustadas diretamente na interface web do Mailman. Como essa interface precisaria ser acessada por parte dos gerentes do Expresso em Nuvem e

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

como os clientes das nuvens no estaro, necessariamente, na rede intranet do Serpro, seria preciso criar proxies web para que a interface do Mailman pudesse ser acessada da Internet. Nesse caso, tambm esse servio deveria passar por testes de segurana. O servio de listas ainda precisar ser melhor analisado para que as questes acima sejam resolvidas. Para a etapa inicial, embasando-se na utilizao do Mailman nos ambientes onde esse est instalado, seria possvel iniciar o Expresso em Nuvem sem existir balanceamento de carga para este servio. No entanto, decises tcnicas esto sendo agora tomadas para que, no futuro, uma possvel migrao do servio de listas ou a mudana no modelo criado para suportar as listas no dificulte o gerenciamento desse servio.

5 Laboratrio do Expresso em Nuvem

O laboratrio do Expresso em nuvem est ocorrendo nesse momento no Serpro. Testes de carga e testes de funcionalidades esto sendo executados. Algumas alteraes na infraestrutura e na lgica de comunicao entre os servios e servidores esto sendo realizadas como forma de deixar a arquitetura do Expresso em Nuvem o mais escalvel possvel. O laboratrio do Expresso em Nuvem est tendo tambm a incumbncia de gerar grficos e relatrios tcnicos sobre a performance de todo o ambiente, avaliando atravs de scripts do Jmeter, a carga que o ambiente inicial ir suportar. A arquitetura do laboratrio do Expresso em Nuvem est apresentada na Figura 7. Basicamente, so 6 servidores com Xen Citrix (XC) e 2 servidores Debian Lenny 64 bits. As especificaes de cada um desses servidores esto abaixo relacionadas:

XC1, XC2, XC3, XC4, XC5, XC6: Dell PowerEdge R900 4 processadores quad core Intel Xeon X7350 2.93GHz (total de 16 ncleos) 128KiB L1 cache e 8MB L2 cache 32 GB de memria Ram de 667 MHz 4 placas Gigabit Ethernet Duas placas HBA 4Gb Fiber Channel DL1 e DL2: Dell PowerEdge R900 4 processadores com 6 cores Intel Xeon E7450 2.4GHz (total de 24 ncleos) 192KiB L1 cache, 9MB L2 cache, 12MB L3 cache. 32 GB de memria Ram de 667 MHz

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

4 placas Gigabit Ethernet Duas placas HBA 4Gb Fiber Channel

Figura 7: Arquitetura fsica do laboratrio do Expresso em Nuvem

5.1

Plano de testes para o laboratrio

O laboratrio do Expresso em Nuvem est dividido entre testes de funcionalidades, testes de recuperao de falhas, testes de desempenho e testes de falhas sobre carga. 5.1.1 Testes de funcionalidades

A equipe do Serpro que j realiza os testes de homologao de novas verses do Expresso ir participar ativamente dessa etapa dos testes do Expresso em Nuvem. Todas as funcionalidades do Expresso sero testadas na tentativa de verificar-se qualquer fuga ao normal comportamento desse software. Abaixo esto apresentados alguns itens sobre funcionalidades que necessitaro ser testados. Evidentemente, nessa lista no estaro todos eles, apenas alguns aos quais dever ser dado especial ateno: Gerenciamento de cotas por OU; Gerenciamento de contas por OU; Testes com o arquivamento local; Verificaes com o Expresso offline; Problemas decorrentes da incluso de cache de elementos estticos nos proxies web; 6. Verificao dos detalhes de funcionamento dos balanceadores web; 7. Atribuio de diferentes pesos ao balanceamento web; 8. Testes de conectividade com os VIPs dos balanceadores; 9. Testes utilizando os navegadores Firefox e Internet Explorer homologados; 10. Testes com o mensageiro instantneo; 1. 2. 3. 4. 5.

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

11. Testes de envio de arquivo atravs do mensageiro instantneo; 12. Testes com o Funambol; 13. Testes do funcionamento das listas; 14. Verificaes de todos as variveis geradas e monitoradas pelo Zabbix. 5.1.2 Testes de recuperao de falhas

Nesta etapa esto sendo simuladas algumas falhas que podero ocorrer quando o Expresso em Nuvem estiver em produo. Abaixo segue uma lista das necessidades de teste. Essa lista no se esgota neste documento. Outros testes sero includos conforme a necessidade.

Retirada de operao do master do Mupdate; Retirada de operao de um dos proxies web; Retirada de operao dos frontends do Expresso; Retirada de operao de um dos backends do Cyrus; Restaurao total do backup de um dos backends do Cyrus; Retirada de operao de um dos servidores de banco de dados; Restaurao da operao do servidor de banco de dados retirado de produo; Retirada de operao de um dos servidores SMTP; Retirada de operao do servidor Pgpool; Simulao da queda do switch que interliga todos os servidores; Simulao da restaurao dos servios que operam no modo ativo-passivo; Testes de desempenho

5.1.3

O objetivo bsico dessa etapa a avaliao do nmero de usurios que j poder integrar a fase inicial do projeto do Expresso em Nuvem. Sobre essa avaliao, embasado no comportamento dos servios e servidores, sero tecidas consideraes sobre as necessidades de hardware para determinados incrementos no nmero de usurios desse modelo tecnolgico. Os testes de carga para o laboratrio esto sendo realizados com o uso da ferramenta Jmeter. Essa ferramenta, que j foi empregada nos testes de carga da verso 1 do Expresso, simula um navegador padro, permitindo testar o ambiente como um todo atravs da criao de scripts automatizados que simulam um usurio acessando o sistema realizando tarefas cotidianas ao Expresso. A partir desses scripts, possvel disparar dezenas de milhares de acessos simultneos para que a verificao do comportamento do ambiente em nuvem sobre intensa carga. A ferramenta tambm permite parametrizar o tempo e a quantidade de acessos. A monitorao do Zabbix durante a execuo dos testes est sendo de extrema importncia. Atravs dos dados obtidos por ela e pelos dados de respostas do Zabbix, possvel analisar o comportamento do ambiente diante

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

das situaes impostas e avaliar quantos usurios simultneos o ambiente projetado suporta. Mesmo quando um limite de usurios atingido, se o servio responsvel pelo gargalo possuir escalabilidade, outros servidores virtuais (ou at reais) esto sendo acrescentados para que os testes possam verificar os outros afunilamentos e identificar as mincias do modelo implementado. 5.1.4 Testes de falhas sobre carga

Essa fase complementa etapa dos testes de desempenho e dos testes de falhas. Muitas vezes testes de falhas so executados sobre o sistema com normal, mnima ou at nenhuma utilizao. No entanto, algumas das falhas que ocorrem em perodos de pico de acesso so mais difceis de serem solucionadas. Esses problemas precisam ser mapeados para que na sua ocorrncia as equipes tcnicas envolvidas com a operao do sistema tenham conhecimento prvio dos passos a serem seguidos.

MODELO TECNOLGICO DO EXPRESSO EM NUVEM FASE 1

FICHA TCNICA
Servio Federal de Processamento de Dados SERPRO
Diretor Presidente Marcos Vincius Ferreira Mazoni Diretoria de Servios Nivaldo Venncio da Cunha Superintendncia de Suporte e Consultoria em Infraestrutura de TIC - SUPSI Wilton Itaiguara Gonalves Mota Departamento de Internalizao Tecnolgica em TIC - SITEC Jos Edson Marinho de Souza Diviso de Especializao em Correio Eletrnico - SITCE merson Salvadori Virti Elaborao - SITCE Andr Felipe Machado Eduardo de Oliveira Nunes merson Salvadori Virti Gustavo Sandini Linden