[plonegov-br] Portal Zope/Plone. TSE.
Charles Henrique
charleshenrique em pgr.mpf.gov.br
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
Mais detalhes sobre a lista de discussão PloneGov-BR