<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Bom dia senhores,<br>
    <br>
    A instala&ccedil;&atilde;o do Plone, incluindo instala&ccedil;&atilde;o do sistema operacional
    (unix based) &eacute; r&aacute;pida e simples. Em menos de 2 horas &eacute; poss&iacute;vel
    levantar um servidor e sair usando por meio do
    <a class="moz-txt-link-freetext" href="http:///localhost:8080">http:///localhost:8080</a>. No entanto isto &eacute; pr&aacute;tico e recomend&aacute;vel
    somente para quem est&aacute; aprendendo, desenvolvendo com archetypes ou
    produtos personalizados com python. Para um ambiente que ir&aacute; para
    produ&ccedil;&atilde;o alguns pontos devem ser observados, tais como: <b>seguran&ccedil;a</b>,
    <b>escalabilidade</b>, <b>performance</b> e <b>backup</b>. N&atilde;o sou
    nenhuma figura carimbada do Plone, mas acredito que a minha vis&atilde;o da
    coisa possa contribuir de alguma forma.<br>
    <br>
    <b>Seguran&ccedil;a</b><br>
    <br>
    O aspecto mais importante da seguran&ccedil;a &eacute; manter o PloneSite longe
    das vulnerabilidades conhecidas. No entanto a instala&ccedil;&atilde;o de um novo
    produto, ou a manuten&ccedil;&atilde;o da vers&atilde;o de outros produtos por problemas
    de seguran&ccedil;a nem sempre &eacute; uma tarefa bem sucedida. A nossa solu&ccedil;&atilde;o
    atual &eacute; manter um ambiente denominado SANDBOX, onde fazemos todos os
    testes de atualiza&ccedil;&otilde;es antes de aplicar em DESENVOLVIMENTO e,
    posteriormente, em PRODU&Ccedil;&Atilde;O. J&aacute; aconteceu casos de tudo funcionar no
    ambiente SANDBOX e DESENVOLVIMENTO, mas ao se passar para PRODU&Ccedil;&Atilde;O
    ocorrer algum problema. Assim, a pol&iacute;tica atual n&atilde;o &eacute; satisfat&oacute;ria
    e, por isto, vamos montar um novo ambiente baseado em m&aacute;quinas
    virtuais com o XenCitrix (atualmente em fase de testes). Neste ser&aacute;
    poss&iacute;vel "desfazer" a&ccedil;&otilde;es no SO que impactem negativamente o
    desempenho ou execu&ccedil;&atilde;o do servidor pelos SNAPSHOTS feitos antes do
    procedimento. Al&eacute;m disso, todas as autentica&ccedil;&otilde;es de p&aacute;ginas s&atilde;o por
    meio do SSL, infelizmente pass&iacute;vel de ataques na vers&atilde;o 1.0
    (<a class="moz-txt-link-freetext" href="http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/">http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/</a>)<br>
    <br>
    <b></b><b>Escalabilidade e Performance</b><br>
    <br>
    Quanto &agrave; performance utilizamos o ab e o Jmeter para obter n&uacute;meros,
    al&eacute;m da visualiza&ccedil;&atilde;o constante de gr&aacute;ficos de desempenho gerados
    pelo Cacti. No entanto apenas consideramos os n&uacute;meros aceit&aacute;veis por
    falta acesso a outros n&uacute;meros para compara&ccedil;&atilde;o. Um mito desfeito
    pelos testes &eacute; 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&atilde;o faz sentido mant&ecirc;-lo habilitado nos
    ambientes de produ&ccedil;&atilde;o.<br>
    <br>
    Mas se o site est&aacute; lento, deve-se investigar os fatores:<br>
    <ul>
      <li>Uso de processador</li>
      <li>Quantidade de mem&oacute;ria e ajuste de configura&ccedil;&otilde;es (uma
        configura&ccedil;&atilde;o mal feita pode levar o zope a usar swap, o que &eacute;
        p&eacute;ssimo)</li>
      <li>Tr&aacute;fego de rede</li>
      <li>A&ccedil;&otilde;es com alto consumo de CPU nos ambientes de produ&ccedil;&atilde;o
        (copiar objetos, colar, indexar, etc)</li>
      <li>Scripts personalizados com defici&ecirc;ncia de programa&ccedil;&atilde;o (assim
        como programador n&atilde;o sabe desenhar, o pessoal da comunica&ccedil;&atilde;o n&atilde;o
        sabe programar). Usem o callProfiler, PageTemplateProfiler e
        PythonProfiler para descobrir o que est&aacute; lento.<br>
      </li>
    </ul>
    Existe cache do conte&uacute;do? Quanto maior o n&uacute;mero de camadas entre o
    cliente e o servidor, provavelmente maior ser&aacute; a performance (!)...
    mas menor ser&aacute; o controle. Balancear os dois &eacute; uma arte. Vejo
    pessoas colocando camadas e mais camadas para acesso, mas em muitos
    casos me parecem desnecess&aacute;rias... seja porque o site n&atilde;o tem o
    n&uacute;mero de acessos esperado, seja porque quanto maior o n&uacute;mero de
    camadas, maior a probabilidade de cometer uma falha na configura&ccedil;&atilde;o
    e seguran&ccedil;a, seja porque seguem receitas de bolos para outros
    ambientes espec&iacute;ficos. J&aacute; vi casos at&eacute; 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&atilde;o &eacute; interessante...
    imagens alteradas ir&atilde;o demorar muito para serem visualizadas pelos
    usu&aacute;rios.<br>
    <br>
    Qual "cacheador escolher"? Apache (com m&oacute;dulos)? Varnish? Squid?
    Escolha aquele que voc&ecirc; domina mais, esta &eacute; sempre a melhor op&ccedil;&atilde;o.
    Esque&ccedil;a os comparativos de performance, eles s&atilde;o feitos em condi&ccedil;&otilde;es
    especiais e n&atilde;o se aplicam a qualquer ambiente. O importante &eacute; ter
    um sistema de cache que funcione adequadamente, do contr&aacute;rio o seu
    sistema estar&aacute; fadado &agrave; lentid&atilde;o. Outro ponto importante para a
    performance &eacute; ter um balanceador de carga (apache via mod_balancer,
    pound, etc)... digo mais uma vez, escolha aquele que voc&ecirc; domine...
    se n&atilde;o domina nenhum, ent&atilde;o sim siga o conselho dos especialistas.<br>
    <br>
    Eu particularmente gosto da combina&ccedil;&atilde;o: SQUID (80 / 443 com
    redirect) -&gt; Apache (com mod_balancer) -&gt; Zope (n inst&acirc;ncias)
    -&gt; Zeo (m inst&acirc;ncias). Mas por que o SQUID na frente? Porque
    quase ningu&eacute;m faz assim. Eu n&atilde;o gosto do meio comum, na minha cabe&ccedil;a
    &eacute; mais vulner&aacute;vel por natureza (por ser mais conhecido). Al&eacute;m do
    mais, se eu colocasse o Apache na frente este sempre teria que
    consultar o Squid... da maneira inversa isto n&atilde;o ocorre: se existe
    no cache, e o conte&uacute;do &eacute; v&aacute;lido, o Squid j&aacute; devolve sem incomodar o
    Apache.<br>
    <br>
    Mas e ai, quais as tecnologias poss&iacute;veis? Segue uma lista n&atilde;o
    exaustiva...<br>
    <ul>
      <li>Servidores Web</li>
      <ul>
        <li>Apache</li>
        <ul>
          <li>Ideal para iniciantes e administradores ditadores</li>
          <li>Os arquivos de configura&ccedil;&otilde;es s&atilde;o fragmentados</li>
          <li>A cria&ccedil;&atilde;o de reescritas n&atilde;o &eacute; simples<br>
          </li>
        </ul>
        <li>Nginx</li>
        <ul>
          <li>Excelente como proxy reverso</li>
          <li>Gasta menos mem&oacute;ria e CPU que o apache</li>
          <li>&Eacute; recomendado para ambientes com ultramegahiper carga de
            acessos</li>
          <li>&Eacute; mais novo que as outras tecnologias... logo, mais
            vulner&aacute;vel</li>
        </ul>
        <li>Squid</li>
        <ul>
          <li>Coringa, serve como excelente servidor e cacheador</li>
          <li>N&atilde;o suporta CGI, mas pode-se resolver f&aacute;cil esta quest&atilde;o</li>
          <li>Ele sozinho pode servir, cachear e fazer balanceamento de
            carga</li>
          <li>A configura&ccedil;&atilde;o &eacute; complexa (n&atilde;o queria que fosse simples,
            n&eacute;?... ele faz tudo)</li>
          <li>Ele come mem&oacute;ria com farinha em configura&ccedil;&otilde;es equivocadas</li>
        </ul>
        <li>Zope</li>
        <ul>
          <li>A pior op&ccedil;&atilde;o</li>
          <li>Use somente para desenvolvimento e testes<br>
          </li>
        </ul>
      </ul>
      <li>Proxies / balanceadores de carga</li>
      <ul>
        <li>HAProxy</li>
        <ul>
          <li>Recomend&aacute;vel para quem gerencia v&aacute;rios servidores zope,
            sistemas gigantes com rein&iacute;cios frequentes</li>
        </ul>
        <li>Perlbal</li>
        <ul>
          <li>Solu&ccedil;&atilde;o para quem gosta do novo e desconhecido<br>
          </li>
        </ul>
        <li>Pound</li>
        <ul>
          <li>Recomend&aacute;vel para solu&ccedil;&otilde;es simplistas</li>
        </ul>
        <li>Apache</li>
        <ul>
          <li>N&atilde;o &eacute; t&atilde;o sofisticado quanto ao HAProxy, mas &eacute; melhor que
            o Pound para balanceamento de carga</li>
        </ul>
        <li>Squid</li>
        <ul>
          <li>J&aacute; falado</li>
        </ul>
        <li>Enfold proxy</li>
        <ul>
          <li>Solu&ccedil;&atilde;o para os amantes do IIS<br>
          </li>
        </ul>
      </ul>
      <li>Cache</li>
      <ul>
        <li>Varnish</li>
        <ul>
          <li>Excelente monitor de cache</li>
        </ul>
        <li>Apache Traffic Server</li>
        <ul>
          <li>Melhor que o Varnish para sites m&eacute;dios a grandes</li>
        </ul>
        <li>Apache</li>
        <ul>
          <li>mod_cache? N&atilde;o recomendo...</li>
        </ul>
        <li>Squid</li>
        <ul>
          <li>J&aacute; falado...</li>
          <li>memcache (excelente)<br>
          </li>
        </ul>
      </ul>
      <li>Dados</li>
      <ul>
        <li>Relstorage</li>
        <li>Neopod<br>
        </li>
      </ul>
    </ul>
    <br>
    Aqui tem uma solu&ccedil;&atilde;o razo&aacute;vel:
<a class="moz-txt-link-freetext" href="http://dev.plone.org/plone.org/raw-attachment/wiki/AdminsTeam/plone_notes.pdf">http://dev.plone.org/plone.org/raw-attachment/wiki/AdminsTeam/plone_notes.pdf</a><br>
    <br>
    Apesar de n&atilde;o usamos nenhuma das solu&ccedil;&otilde;es milagrosas sugeridas em
    v&aacute;rios sites, o nosso ambiente responde extremamente bem. Os
    servidores que hospedam (3) est&atilde;o praticamente subutilizados, um dos
    motivos pelo qual iremos virtualizar o ambiente. Um outro motivo &eacute;
    que com m&aacute;quinas virtuais a escabilidade e simplificada, uma vez que
    basta "clonar" um servidor em produ&ccedil;&atilde;o, alterar alguns poucos
    par&acirc;metros, e teremos outro n&oacute; respondendo como cliente ZEO em menos
    de 30 minutos.<br>
    <br>
    <br>
    <b>Backup</b><br>
    <br>
    A c&oacute;pia de seguran&ccedil;a de um Plone Site, ao contr&aacute;rio do que muitos
    pensam, n&atilde;o deve levar em considera&ccedil;&atilde;o apenas o Data.fs. &Eacute; sim
    importante fazer backups regulares de um ambiente em produ&ccedil;&atilde;o e
    constante edi&ccedil;&atilde;o, mas t&atilde;o importante quanto &eacute; ter backup de toda a
    estrutura, efetuar packs regulares da base de dados e manter em
    seguran&ccedil;a os registros de acesso rotacionados (logs). H&aacute; quem pense
    que com o buildout fazer backup da estrutura &eacute; algo desnecess&aacute;rio,
    mas a experi&ecirc;ncia me mostrou que isto n&atilde;o &eacute; completamente verdade,
    uma vez que a maioria das pessoas procedem com ajustes
    extra-buildouts.<br>
    <br>
    Obviamente uma pol&iacute;tica de backup que funciona bem em X pode n&atilde;o ser
    a melhor para Y. Enquanto esta tem poucos usu&aacute;rios e baixa altera&ccedil;&atilde;o
    de conte&uacute;do, aquela tem muitos editores e altera&ccedil;&atilde;o de conte&uacute;do
    constante:&nbsp; nesta uma pol&iacute;tica de backup menos agressiva pode ser
    usada, enquanto naquela &eacute; extremamente recomend&aacute;vel uma pol&iacute;tica de
    backup di&aacute;ria.<br>
    <br>
    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&ccedil;a e sempre
    funcionou quando precisamos de alguma restaura&ccedil;&atilde;o). Como temos os
    PloneSites espalhados em v&aacute;rios arquivos de dados, um &uacute;nico script
    varre todo os "data.fs"s e faz backup incremental de ter&ccedil;a a
    domingo, e um backup total nas segundas ap&oacute;s o pack, tamb&eacute;m nesta
    dia. Quatro conjuntos de backups &eacute; mantido, e desta forma mantemos
    30 dias de hist&oacute;rico para restaura&ccedil;&atilde;o. &Eacute; poss&iacute;vel aumentar este
    limite, mas isto tem um custo: espa&ccedil;o de armazenamento.<br>
    <br>
    Enfim... isto &eacute; um pouco do que temos aqui.<br>
    <br>
    Abra&ccedil;os,<br>
    <br>
    Charles Henrique<br>
    <br>
    <br>
    <br>
    Em 07-10-2011 14:59, Jean Rodrigo Ferri escreveu:
    <blockquote cite="mid:4E8F3DF7.3090605@interlegis.leg.br"
      type="cite">
      <pre wrap="">Em 07-10-2011 12:20, Ianeiara Guedes de Assis escreveu:
</pre>
      <blockquote type="cite">
        <pre wrap="">Bom dia Jean, colocamos nosso portal plone em produ&ccedil;&atilde;o semana passada e estamos "tunnando" o ambiente. Vc conhece algum &oacute;rg&atilde;o que tenha um ambiente similar ao nosso para que possamos trocar umas figurinhas? Nosso ambiente &eacute; Plone 3 com:

Nginx
Varnish
Pound
Inst&acirc;ncias
Zeo

Att,
Iana
Tribunal Superior Eleitoral
</pre>
      </blockquote>
      <pre wrap="">

Ol&aacute; Iana,

Eu sei que h&aacute; mas n&atilde;o estou lembrando quem tem o ambiente igual ao de 
voc&ecirc;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&ecirc; 
precisa, ok?

Abra&ccedil;o,

</pre>
    </blockquote>
    <br>
  </body>
</html>