Servidor de Infra-estrutura

É normal vermos entre os analistas de segurança o conceito de que cada máquina deve servir com um propósito único, ou seja, um servidor Web deve servir Web, um servidor de Email deve servir somente Email, assim como de ftp, dns, stream de vídeo, entre outros serviços Internet.

É inteligente essa idéia e deve ser seguida sempre que possível pois garante a segurança dos serviços e a performance, um serviço não interferindo no outro. Contudo, em geral observamos o contrário. Em situações de médio porte para baixo, temos servidores que são responsáveis por mais de um serviço de infra-estrutura Internet. Com isso, temos um problema, exatamente o que foi dito acima. Questões de segurança envolvendo um serviço e seu gerenciamento interferindo no contexto de funcionamento geral.

Com o Apache 2.0 a idéia é criar um servidor de Infra-estrutura. O que seria isso? O servidor Apache agora é um framework para servidores, possibilitando a criação de módulos para quais serviços se desejar. Ele é totalmente adaptável a realidade do serviço. Isso traz vantagens como facilidade no gerenciamento, onde apenas uma API será necessária manipular para gerenciar todos os serviços, apenas um treinamento deve ser dado para o administrador, etc.

Tal feature foi criada com o objetivo de facilitar a implementação de outros protocolos, rápida e confiavelmente. É um passo pretensioso e bastante ousado do grupo.

Utilizando um servidor e framework para vários serviços, via a mesma interface, pode-se manipular questões como segurança facilmente. Pode-se implementar uma política de segurança para todos os serviços, aprende-se apenas sobre um software, concentra-se na auditoria / programação em cima de uma API, ou seja, não é necessário a multiplicação dos recursos e dos riscos.

Além disso, pode haver compartilhamento de recursos, como por exemplo, tendo-se vários serviços espalhados você pode precisar de multiplicar modos de acessar uma mesma base de dados para autenticação de usuários, enquanto tendo apenas um servidor de ?serviços Internet?, já na fase após a requisição pode-se fazer a autenticação do usuário numa base comum de dados.

Para implementar um novo protocolo, é como escrever um módulo normalmente para o Apache, pode-se até utilizar a tradicional API via modperl, ou seja, muitíssimo simples. Existe por padrão no novo Apache o mod_echo, que é um módulo implementando o protocolo echo, ele só echoa o que vem para ele, mas é um exemplo do funcionamento da implementação de um protocolo simples, que não o HTTP, que já está um tanto quanto desenvolvido e confuso para o entendimento do desenvolvedor iniciante.

CGId: uma nova abordagem

O módulo de CGI fornece a possibilidade ao servidor de rodar programas externos e produzir resultados específicos para cada requisição. CGIs são usadas pela maioria dos sites para produzir conteúdo dinâmico, diferenciado por usuário e contexto.

O Apache sempre teve suporte a CGI pelo módulo mod_cgi. Quando um CGI é requisitado, o processo filho chamado para atender a requisição cria um novo processo para rodar o CGI. Após a execução do programa a saída com os dados são redirecionadas para o processo inicial, que repassa os dados ao cliente original da requisição. Assim funciona na versão 1.3, que tem problemas sérios de performance e por isso existem módulos como o modperl, por exemplo, que otimizam em muita operações com CGIs em Perl. Sobre este assunto especificamente, citado no parágrafo de respostas a requisições, mod_cgi, arquitetura web, mod_perl, já tratei em artigos passados aqui na Developers.

Para resolver esses problemas, na versão 2.0 temos algumas possibilidades. Existem dois módulos, o mod_cgi, que deve ser usada em plataformas não-Unix e com MPM de prefork (compatibilidade) e o segundo módulo, o mod_cgid, que pode ser usado em qualquer MPM Unix com threads, a grande novidade.

O mod_cgid evita problemas de performance criando um daemon específico para atender requisições de CGI. Antes do start de qualquer filho do processo pai Apache, no processo de inicialização, o servidor cria um novo processo que será o servidor de CGI. Esse processo cria um socket para comunicação com os filhos do Apache pai. O servidor de CGI criará um processo para rodar os CGIs, que comunicam-se diretamente com o processo filho do Apache geral que recebeu a requisição. A saída do processo CGI filho será enviado ao processo Apache filho, que irá redirecioná-la para o cliente. Existe um ganho considerável de performance nessa conjuntura.

Obviamente, problemas surgem ao se criar um novo ?servidor?, mas que são contornados e valem o custo/benefício pelo quesito performance, de forma geral. Mecanismos semelhantes a recuperação de perda de piped logs são usadas para o mesmo problema com pipe entre os processos mod_cgid.

Conclusões

Estamos na versão 2.0.16 beta, que saiu em 9 de abril deste ano. Ainda falta bastante trabalho mas a próxima beta não tarda. As modificações como vistas são muitas e indicam para dois aspectos fundamentais já desenhados ao longo do texto: portabilidade e escalabilidade.

Essas duas palavras genéricas que se relacionam diretamente não são por acaso. É uma imposição do mundo real, que não para de crescer e multiplicar suas plataformas. Como vimos vários aspectos da arquitetura do Apache, todo esse esquema nos mostra que ele está mais enxuto, muito bem modularizado, plugável, enfim, muito flexível.

Vimos que ele pretende fazer serviços de infra-estrutura bem definidos e com excelência, com foco, ser adaptável a situações diferenciadas (conseguindo atender outros tipos de serviços), e mesmo redirecionando tarefas que eram de sua responsabilidade em versões anteriores para outros, como execução de CGI, controle de Logs, etc.

Sua arquitetura é construída modularmente, onde pode-se encaixar conforme suas próprias necessidades as peças necessárias ao funcionamento ótimo para cada um. É um quebra cabeça perfeito que se adapta bem em qualquer serviço de infra-estrutura de redes, com características intrínsecas de portabilidade e escalabilidade. Não posso esquecer: a um custo zero.

Mediante todas essas constatações, a tendência é que o Apache 2.0 mantenha-se líder em seu segmento e tendendo a se expandir em outros nichos de serviços e plataformas.

Referências:

• www.apache.org
• modules.apache.org
• www.apachetoday.com
• www.apacheweek.com