[plonegov-br] Portal Zope/Plone. TSE.

Sexta Outubro 7 17:58:47 BRT 2011

Bom dia senhores,

A instalação do Plone, incluindo instalação do sistema operacional (unix 
based) é rápida e simples. Em menos de 2 horas é possível levantar um 
servidor e sair usando por meio do http:///localhost:8080. No entanto 
isto é prático e recomendável somente para quem está aprendendo, 
desenvolvendo com archetypes ou produtos personalizados com python. Para 
um ambiente que irá para produção alguns pontos devem ser observados, 
tais como: *segurança*, *escalabilidade*, *performance* e *backup*. Não 
sou nenhuma figura carimbada do Plone, mas acredito que a minha visão da 
coisa possa contribuir de alguma forma.

*Segurança*

O aspecto mais importante da segurança é manter o PloneSite longe das 
vulnerabilidades conhecidas. No entanto a instalação de um novo produto, 
ou a manutenção da versão de outros produtos por problemas de segurança 
nem sempre é uma tarefa bem sucedida. A nossa solução atual é manter um 
ambiente denominado SANDBOX, onde fazemos todos os testes de 
atualizações antes de aplicar em DESENVOLVIMENTO e, posteriormente, em 
PRODUÇÃO. Já aconteceu casos de tudo funcionar no ambiente SANDBOX e 
DESENVOLVIMENTO, mas ao se passar para PRODUÇÃO ocorrer algum problema. 
Assim, a política atual não é satisfatória e, por isto, vamos montar um 
novo ambiente baseado em máquinas virtuais com o XenCitrix (atualmente 
em fase de testes). Neste será possível "desfazer" ações no SO que 
impactem negativamente o desempenho ou execução do servidor pelos 
SNAPSHOTS feitos antes do procedimento. Além disso, todas as 
autenticações de páginas são por meio do SSL, infelizmente passível de 
ataques na versão 1.0 
(http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/)

***Escalabilidade e Performance*

Quanto à performance utilizamos o ab e o Jmeter para obter números, além 
da visualização constante de gráficos de desempenho gerados pelo Cacti. 
No entanto apenas consideramos os números aceitáveis por falta acesso a 
outros números para comparação. Um mito desfeito pelos testes é que o 
modo debug deixa o servidor muito mais lento... na verdade, com este 
modo habilitado, perdeu-se somente de 10 a 15% de performance. 
Obviamente não faz sentido mantê-lo habilitado nos ambientes de produção.

Mas se o site está lento, deve-se investigar os fatores:

    * Uso de processador
    * Quantidade de memória e ajuste de configurações (uma configuração
      mal feita pode levar o zope a usar swap, o que é péssimo)
    * Tráfego de rede
    * Ações com alto consumo de CPU nos ambientes de produção (copiar
      objetos, colar, indexar, etc)
    * Scripts personalizados com deficiência de programação (assim como
      programador não sabe desenhar, o pessoal da comunicação não sabe
      programar). Usem o callProfiler, PageTemplateProfiler e
      PythonProfiler para descobrir o que está lento.

Existe cache do conteúdo? Quanto maior o número de camadas entre o 
cliente e o servidor, provavelmente maior será a performance (!)... mas 
menor será o controle. Balancear os dois é uma arte. Vejo pessoas 
colocando camadas e mais camadas para acesso, mas em muitos casos me 
parecem desnecessárias... seja porque o site não tem o número de acessos 
esperado, seja porque quanto maior o número de camadas, maior a 
probabilidade de cometer uma falha na configuração e segurança, seja 
porque seguem receitas de bolos para outros ambientes específicos. Já vi 
casos até em que se instalavam o Squid e pronto, considerava-se 
resolvido o problema de cache... o Squid sem o CacheFU ou algo 
semelhante no plone não é interessante... imagens alteradas irão demorar 
muito para serem visualizadas pelos usuários.

Qual "cacheador escolher"? Apache (com módulos)? Varnish? Squid? Escolha 
aquele que você domina mais, esta é sempre a melhor opção. Esqueça os 
comparativos de performance, eles são feitos em condições especiais e 
não se aplicam a qualquer ambiente. O importante é ter um sistema de 
cache que funcione adequadamente, do contrário o seu sistema estará 
fadado à lentidão. Outro ponto importante para a performance é ter um 
balanceador de carga (apache via mod_balancer, pound, etc)... digo mais 
uma vez, escolha aquele que você domine... se não domina nenhum, então 
sim siga o conselho dos especialistas.

Eu particularmente gosto da combinação: SQUID (80 / 443 com redirect) -> 
Apache (com mod_balancer) -> Zope (n instâncias) -> Zeo (m instâncias). 
Mas por que o SQUID na frente? Porque quase ninguém faz assim. Eu não 
gosto do meio comum, na minha cabeça é mais vulnerável por natureza (por 
ser mais conhecido). Além do mais, se eu colocasse o Apache na frente 
este sempre teria que consultar o Squid... da maneira inversa isto não 
ocorre: se existe no cache, e o conteúdo é válido, o Squid já devolve 
sem incomodar o Apache.

Mas e ai, quais as tecnologias possíveis? Segue uma lista não exaustiva...

    * Servidores Web
          o Apache
                + Ideal para iniciantes e administradores ditadores
                + Os arquivos de configurações são fragmentados
                + A criação de reescritas não é simples
          o Nginx
                + Excelente como proxy reverso
                + Gasta menos memória e CPU que o apache
                + É recomendado para ambientes com ultramegahiper carga
                  de acessos
                + É mais novo que as outras tecnologias... logo, mais
                  vulnerável
          o Squid
                + Coringa, serve como excelente servidor e cacheador
                + Não suporta CGI, mas pode-se resolver fácil esta questão
                + Ele sozinho pode servir, cachear e fazer balanceamento
                  de carga
                + A configuração é complexa (não queria que fosse
                  simples, né?... ele faz tudo)
                + Ele come memória com farinha em configurações equivocadas
          o Zope
                + A pior opção
                + Use somente para desenvolvimento e testes
    * Proxies / balanceadores de carga
          o HAProxy
                + Recomendável para quem gerencia vários servidores
                  zope, sistemas gigantes com reinícios frequentes
          o Perlbal
                + Solução para quem gosta do novo e desconhecido
          o Pound
                + Recomendável para soluções simplistas
          o Apache
                + Não é tão sofisticado quanto ao HAProxy, mas é melhor
                  que o Pound para balanceamento de carga
          o Squid
                + Já falado
          o Enfold proxy
                + Solução para os amantes do IIS
    * Cache
          o Varnish
                + Excelente monitor de cache
          o Apache Traffic Server
                + Melhor que o Varnish para sites médios a grandes
          o Apache
                + mod_cache? Não recomendo...
          o Squid
                + Já falado...
                + memcache (excelente)
    * Dados
          o Relstorage
          o Neopod

Aqui tem uma solução razoável: 
http://dev.plone.org/plone.org/raw-attachment/wiki/AdminsTeam/plone_notes.pdf

Apesar de não usamos nenhuma das soluções milagrosas sugeridas em vários 
sites, o nosso ambiente responde extremamente bem. Os servidores que 
hospedam (3) estão praticamente subutilizados, um dos motivos pelo qual 
iremos virtualizar o ambiente. Um outro motivo é que com máquinas 
virtuais a escabilidade e simplificada, uma vez que basta "clonar" um 
servidor em produção, alterar alguns poucos parâmetros, e teremos outro 
nó respondendo como cliente ZEO em menos de 30 minutos.

*Backup*

A cópia de segurança de um Plone Site, ao contrário do que muitos 
pensam, não deve levar em consideração apenas o Data.fs. É sim 
importante fazer backups regulares de um ambiente em produção e 
constante edição, mas tão importante quanto é ter backup de toda a 
estrutura, efetuar packs regulares da base de dados e manter em 
segurança os registros de acesso rotacionados (logs). Há quem pense que 
com o buildout fazer backup da estrutura é algo desnecessário, mas a 
experiência me mostrou que isto não é completamente verdade, uma vez que 
a maioria das pessoas procedem com ajustes extra-buildouts.

Obviamente uma política de backup que funciona bem em X pode não ser a 
melhor para Y. Enquanto esta tem poucos usuários e baixa alteração de 
conteúdo, aquela tem muitos editores e alteração de conteúdo constante:  
nesta uma política de backup menos agressiva pode ser usada, enquanto 
naquela é extremamente recomendável uma política de backup diária.

Existe N formas de se efetuar o backup, inclusive por receitas do 
buildout. Eu, particularmente, prefiro personalizar scripts agendados e 
utilizar o repozo (inspira mais confiança e sempre funcionou quando 
precisamos de alguma restauração). Como temos os PloneSites espalhados 
em vários arquivos de dados, um único script varre todo os "data.fs"s e 
faz backup incremental de terça a domingo, e um backup total nas 
segundas após o pack, também nesta dia. Quatro conjuntos de backups é 
mantido, e desta forma mantemos 30 dias de histórico para restauração. É 
possível aumentar este limite, mas isto tem um custo: espaço de 
armazenamento.

Enfim... isto é um pouco do que temos aqui.

Abraços,

Charles Henrique

Em 07-10-2011 14:59, Jean Rodrigo Ferri escreveu:
> Em 07-10-2011 12:20, Ianeiara Guedes de Assis escreveu:
>> Bom dia Jean, colocamos nosso portal plone em produção semana passada e estamos "tunnando" o ambiente. Vc conhece algum órgão que tenha um ambiente similar ao nosso para que possamos trocar umas figurinhas? Nosso ambiente é Plone 3 com:
>>
>> Nginx
>> Varnish
>> Pound
>> Instâncias
>> Zeo
>>
>> Att,
>> Iana
>> Tribunal Superior Eleitoral
>
> Olá Iana,
>
> Eu sei que há mas não estou lembrando quem tem o ambiente igual ao de
> vocês. Vamos repassar esta mensagem para a lista PloneGov-BR para que o
> pessoal do governo nos ajude a entrar em contato com as pessoas que você
> precisa, ok?
>
> Abraço,
>

-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.interlegis.gov.br/pipermail/plonegov-br/attachments/20111007/4eacd731/attachment.htm 