SIEGE - Testando Carga em Servidores WEB

Depois de muito tempo.... felizmente.... mais um novo 'post'!

Estava esta semana configurando um novo servidor Apache e algumas perguntas me vieram a mente.

1. Quantas threads eu preciso configurar para conseguir que ele entregue o máximo de desempenho?

2. Meu servidor é capaz de devolver múltiplas requisições numa talagada só, mas até onde ele agüenta?

3. A partir de quantas threads isso se torna desperdício?

De muito procurar por uma ferramenta que ajudasse a responder minhas perguntas achei o SIEGE.

O SIEGE executa um teste de carga em servidores WEB, o mesmo efetua o teste de desempenho de 2 maneiras:

1. Simula o comportamento norma de um ser-humano navegando na internet, com o intervalo de 3 segundos entre cada 2 acessos;

2. O segundo modo é conhecido como benchmark, onde os intervalos são eliminados e o SIEGE faz solicitações ao servidor ininterruptamente;
   

Pela configuração padrão do SIEGE, dispõe de uma tropa VIRTUAL de 10 'soldados', prontos para o ataque. Este parâmetro pode ser alterado com a seguinte opção:

--concurrent=quantidade_de_soldados

Vamos ao que interessa!

1. Instalando o SIEGE:

Para usuários de distribuições derivadas do DEBIAN, não terão muita dificuldade, apenas usem o apt-get:

#apt-get install siege

Caso queiram compilar o pacote na 'munheca', sigam os passos abaixo:

1. Entrem no site do desenvolvedor http://freshmeat.net/projects/siege/;

2. Façam o download do SIEGE e salvem em \usr\local\src;

#cd /usr/local/src/

#wget http://freshmeat.net/urls/b2e94e779aa5343bfc0f50d3d798bd1e

3. Descompacte o pacote e entre na pasta descompactada:

#tar -xvzf siege-latest.tar.gz

#cd siege-2.69/

4. Compile o pacote:

#./configure

#make

#make uninstall (só necessário se você tiver alguma versão antiga do SIEGE instalada nesta estação)

#Make install

#siege.config

Este último é para gerar o arquivo de configuração que fica dentro da pasta raiz do usuário que instalou o mesmo. Ex.: ~/usuário/.siegerc

Pronto para a batalha!

Atacaaaaaaaaaaar!

1. Quais o servidores testaremos? Abaixo segue as duas maneiras de fazer isso:

   1. #siege www.páginateste.com.br/index.html

   2. #siege -f arquivo_com_sites.txt

2. Aumentando o número de soldados, apenas acrescentar a opção -c seguida do número de usuários:

1. #siege www.páginateste.com.br/index.html -c10

2. #siege www.páginateste.com.br/index.html -c100

3. #siege -f arquivo_com_sites.txt -c10

4. #siege -f arquivo_com_sites.txt -c100

3. Acrescentando o -b você ativa a opção de benchmark, no qual a mesma dispensa o intervalo em que são feitas as solicitações e faz solicitações ininterruptamente:

1. #siege www.páginateste.com.br/index.html -c10 -b

2. #siege www.páginateste.com.br/index.html -c100 -b

3. #siege -f arquivo_com_sites.txt -c10 -b

4. #siege -f arquivo_com_sites.txt -c100 -b

Fim do ataque!

Para limitar o tempo dos teste, acrescente a opção -t, seguida do tempo em minutos:

5. #siege www.páginateste.com.br/index.html -c10 -b -t1

6. #siege www.páginateste.com.br/index.html -c100 -b -t2

7. #siege -f arquivo_com_sites.txt -c10 -b -t5

8. #siege -f arquivo_com_sites.txt -c100 -b -t10

Caso você queria interromper manualmente, aperte CTRL+C.

No final dos testes será apresentado um relatório como este abaixo:

Mais uma vez agradeço a todos!

Abraços!
Sabocinski

Virtualização - VMware Server 1.0.9 no Ubuntu 9.04 Jaunty Jackalope

Boa noite a todos!

Atualmente uma grande saída para espaço, tempo e facilidade na área de informática, chama-se VIRTUALIZAÇÃO. Iremos falar dos tipos de virtualização em outro post.
Esta facilidade tem nos ajudado cada vez mais tanto nas nossas estações pessoais quanto em datacenters. Hoje já encontramos várias soluções de virtualização, sendo elas:

• Xen Opensource;

• Xen Source (Adquiro pela Citrix);

• VMware;

• Paralles;

• Virtual Box;

Todas as soluções acima apresentam um versão free. Essas versões são limitadas a número de máquinas hospedadas. Iremos hoje tratar tecnicamente da versão free da VMware, a mesma é chamada de VMware Server.

Vamos colocar a mão na massa!

Iremos instalar o Vmware Server em uma estação com o linux Ubuntu 9.04 Jaunty Jackalope.

1. Instalando os pacotes de compilação do ubuntu:

sudo apt-get install build-essential linux-headers-$(uname -r) xinetd

2. Download do Vmware Server do site do fabricante:

Acesse o site abaixo e selecione a versão 1.0.9, pois será está que trataremos neste post.

http://www.vmware.com/download/server/

Salve o arquivo em:

#cd /usr/local/src/

1. Download do pacote de correção da instalação do Vmware Server:

#cd /usr/local/src

#wget -c http://www.insecure.ws/warehouse/vmware-update-2.6.27-5.5.7-2.tar.gz

1. Descompactando e instalando:

Esta etapa preste bem atenção, pois um erro apresentará e é aí que teremos que executar o pacote de correção.

#cd /usr/local/src/

#tar -xvzf Vmware-server-1.0.9-156507.tar.gz

#tar -xvzf vmware-update-2.6.27-5.5.7-2.tar.gz

#cd vmware-server-distrib/

#./vmware-install.pl

Após execução do comando acima, apresentaram os erros abaixo:

/tmp/vmware-config0/vmmon-only/linux/driver.c: In function ‘LinuxDriver_Ioctl’:

/tmp/vmware-config0/vmmon-only/linux/driver.c:1670: error: too many arguments to function ‘smp_call_function’

make[2]: ** [/tmp/vmware-config0/vmmon-only/linux/driver.o] Erro 1

make[1]: ** [_module_/tmp/vmware-config0/vmmon-only] Erro 2

make[1]: Saindo do diretório `/usr/src/linux-headers-2.6.28-12-generic'

make: ** [vmmon.ko] Erro 2

make: Saindo do diretório `/tmp/vmware-config0/vmmon-only'

Unable to build the vmmon module.

É neste momento que usaremos o pacote de correção do Vmware:

#cd vmware-update-2.6.27-5.5.7-2

#./runme.pl

Quando você ver a mensagem abaixo, é porque a instalação está pronta!

Mais uma vez agradeço a atenção de todos e espero ter ajudado!

Ahh.. Não esqueça de assistir o vídeo!

Nginx - Fazendo Global Service Load Balance (GSLB)

Mais uma vez estamos aqui... dividindo um pouco de conhecimento!

Para começar precisamos responder 2 perguntas que já devem estar rodeando a cabeça do leitor... Ná verdade são 4 em duas.

1 - O que é Ngnix? Pra que sever?
2 - O que é GSLB? Onde aplico?

Vamos a primeira!

1 - O que é Nginx? Pra que server?

O Nginx (pronuncia-se enginex), é um servidor WEB e Proxy Reverso de alta performance, podendo fazer proxy de servidores de e-mail IMAP, POP, SMTP. O Nginx também pode fazer proxy de outros protocolos, mas, seu foco são protocolos HTTP e HTTPS.
Ele é um projeto Open Source que está sendo desenvolvido por um russo chamado Igor Sysoev, no qual já está trabalhando no mesmo a uns 4 anos.
E falando em proxy... já podemos imaginar algumas centenas de coisas que podemos fazer.. uma delas e balanceamento de servidores (Load Balancing). Ele é um ótimo e robusto balanceador de carga, com configuração fácil e rápida. em poucos minutos estarás com seus servidores balanceados.

Próxima pergunta...

2 - O que é GSLB? Onde aplico?

O GSLB - Global Service Load Balance, como já diz o nome, é um balanceamento global de servidores, ou seja, poderei balancear uma determinada aplicação ou serviço entre vários datacenters localizados em um continente, país, estado ou cidade. Vamos ver se a figura abaixo nos ajuda um pouco:

Vamos lá..

Um cliente na internet requisita uma determinada aplicação. O servidor que responderá está aplicação te encaminhará para um datacenter, podendo aplicar as seguintes métricas:

• Localização Geográfica: De acordo com a posição geográfica do cliente, o mesmo, será encaminhado para o datacenter mais próximo;
• Disponibilidade: Se o datacenter mais próximo do cliente não estiver disponível, o mesmo será direcionado para um que possa atende-lo naquele momento;
• Carga alta: Caso a aplicação esteja congestionada no datacenter principal, a requisição do cliente será direcionada para um datacenter que esteja mais livre;
• Balanceamento Manual: Este balanceamento é feito de acordo com o 'peso' (weight) configurado para cada datacenter;

O GSLB é uma ótima solução para 'disaster recovery', caso um algo aconteça com um dos datacenters do ambiente, automáticamente a requisições serão direcionadas para o que estiver disponível.

Com as duas perguntas respondidas... acredito que o leitor já está imaginando o que faremos..
Sim! Utilizaremos nosso amigo Nginx para fazer o balanceamento de carga (Load Balance) de um ambiente que possui vários datacenters espalhados pelo mundo. Eis o cenário abaixo:

Dados do cenário:

Datacenter - US

Aplicação URL: http://us.app.com IP Externo: 201.x.y.1
Servidores:

Server1 10.1.1.1:80
Server2 10.1.1.2:80
Server3 10.1.1.3:80

Porta do serviço: 80

Datacenter - EU

Aplicação URL: http://eu.app.com IP Externo: 189.x.y.1
Servidores:

Server1 192.168.1.1:8001
Server2 192.168.1.2:8001
Server3 192.168.1.3:8001

Porta do serviço: 8001

Datacenter - APAC

Aplicação URL: http://apac.app.com IP Externo: 200.x.y.1
Servidores:

Server1 172.1.1.1:8080
Server2 172.1.1.2:8080
Server3 172.1.1.3:8080

Porta do serviço: 8080

Mãos-a-obra

1 - Download do Nginx:

# cd /usr/local/src/
# wget pacote_do_Nginx
# tar -xvzf pacote_do_Nginx.tar.gz
# cd pasta_Nginx/
# ./configure # make # make install

Ao instalar será criada uma pasta em /etc/nginx/, onde na mesma encontram os arquivos de configuração do Nginx. Você irá notar uma breve semelhança com a estrutura de pastas e arquivos do Apache2.

2- Configuração do Nginx no Datacenter US:

# cd /etc/nginx/sites-enable/
# mv default ../
# tail default > default
# vi default

#==========================================================

http {
upstream us.app.com {
server 10.1.1.1:80 weight=3; # Caso você queira dividir a carga entre servidores manualmente,
                          # acrescente o weight e altere o peso, nos outros servidores
server 10.1.1.2:80;
server 10.1.1.3:80;
          }
server {
listen 80;
server_name www.app.com app.com; # URL chamada pelo cliente
location / {
proxy_pass http://us.app.com; # Note: Este é o upstream configurado
       }
  }

geo $gslb {
default us;
include conf/gslb.conf;
   }

if  ($gslb=eu) {
   rewrite ^(.*) http://eu.app.com$1 redirect;
   }

if  ($gslb=apac) {
   rewrite ^(.*) http://apac.app.com$1 redirect;
   }
}

#=======================================================

3 - Criaremos o arquivo gslc.conf em /etc/nginx/conf/:
Obs.: Este procedimento terá que ser feito nos três datacenters

# mkdir /etc/nginx/conf
# touch /etc/nginx/conf/gslb.conf
# cd /etc/nginx/conf
# vi gslb.conf

O conteúdo deste arquivo é formado pelar redes que atendem cada região, exemplo:

98.0.0.0/24 us;
189.0.0.0/24 us;
50.0.0.0/24 eu;
201.0.0.0/24 eu;
20.0.0.0/24 apac;
200.0.0.0/24 apac;
...
...
...

OBS.: Estas redes descritas acima são apenas para demonstração e entendimento da funcionalidade da solução;

4- Configuração do Nginx no Datacenter EU:

# cd /etc/nginx/sites-enable/
# mv default ../
# tail default > default
# vi default

#==========================================================

http {
upstream eu.app.com {
server 192.168.1.1:8001 weight=3; # Caso você queira dividir a carga entre servidores manualmente,
                               # acrescente o weight e altere o peso, nos outros servidores
server 192.168.1.2:8001;
server 192.168.1.3:8001;
          }
server {
listen 80;
server_name www.app.com app.com; # URL chamada pelo cliente
location / {
proxy_pass http://eu.app.com; # Note: Este é o upstream configurado
       }
  }

geo $gslb {
default eu;
include conf/gslb.conf;
   }

if  ($gslb=us) {
   rewrite ^(.*) http://us.app.com$1 redirect;
   }

if  ($gslb=apac) {
   rewrite ^(.*) http://apac.app.com$1 redirect;
   }
}

#=======================================================

5- Configuração do Nginx no Datacenter APAC:

# cd /etc/nginx/sites-enable/
# mv default ../
# tail default > default
# vi default

#==========================================================

http {
upstream apac.app.com {
server 172.1.1.1:8080 weight=3; # Caso você queira dividir a carga entre servidores manualmente,
                             # acrescente o weight e altere o peso, nos outros servidores
server 172.1.1.2:8080
server 172.1.1.3:8080
          }
server {
listen 80;
server_name www.app.com app.com; # URL chamada pelo cliente
location / {
proxy_pass http://apac.app.com; # Note: Este é o upstream configurado
       }
  }

geo $gslb {
default apac;
include conf/gslb.conf;
   }

if  ($gslb=eu) {
   rewrite ^(.*) http://eu.app.com$1 redirect;
   }

if  ($gslb=us) {
   rewrite ^(.*) http://us.app.com$1 redirect;
   }
}

#=======================================================

Após estes 5 passos, você terá um ambiente 100% balanceado e preparado para um 'disater recovery'.

Lembrando que esta é uma solução Open Source, a mesma pode ser atendida por appliance pelas seguintes empresas:

• Citrix (http://www.citrix.com.br)
• F5 (http://www.f5.com)
• Cisco (http://www.cisco.com)

Mais uma vez.. obrigado pela atenção e espero ter ajudado!
Agora eu vou dormir!
Abraços.

OSB.:(Se tiverem tempo assistam os vídeos abaixo, não falam do Nginx, mas de um ambiente 100% disponível)

Proxy Reverso? O que danado é isso?

E voltando para mais um capítulo da nossa jornada...

Estes últimos dias tenho deparado-me bastante com a necessidade de conhecer e aprender soluções que trabalham com PROXY REVERSO.

E o que danado é um PROXY REVERSO?

De acordo com minhas pesquisas... Proxy é um termo em inglês que significa “fazer algo em favor de alguém” [LEXICO PUBLISHING GROUP, 1998].

Também achei a seguinte definição no Wikipédia: Proxy é um servidor que atende a requisições repassando os dados a outros servidores. Um usuário (cliente) conecta-se a um servidor proxy, requisitando algum serviço, como um arquivo, conexão, website, ou outro recurso disponível em outro servidor.

Ele quis dizer o seguinte:




Então podemos chegar a conclusão que o nosso amigo PROXY REVERSO, nada mais é do que a situação acima, mas, de forma contrária, ou seja:

Trocando em miúdos... ao invés da requisição a uma aplicação ser originada de um usuário da rede interna para a internet, o processo é o contrário, concluindo que:

PROXY REVERSO é o cara que vai receber as requisições para aplicações de clientes da internet e entrega-las a rede local ou uma DMZ.

Mas me diga uma coisa... quais os ganhos que poderei ter com esse tal de PROXY REVERSO?

1. Balanceamento de Carga, se um dos servidores da aplicação WEB 'cair' o nosso amigo PROXY REVERSO, não entrega as requisições ele, tornando assim a aplicação e as requisições 100% UP;
2. Proteger aplicações WEB contra ataques com HTML Injection, PHP Injection entre outros padrões de ataques conhecidos;
3. Com o PROXY REVERSO, posso configurar filtros em cima das requisições HTTP, fazendo que, o mesmo, apenas entregue aos requisitantes o conteúdo permitido;
4. Para questões de segurança do servidor de aplicação, posso esconder informações que vem no HEADER. Tais como sistema operacional, versão do webserver e build do mesmo. Dificultando assim exploração de possíveis vulnerabilidades do servidor;
5. Unifica e centraliza o acesso a todos os servidores WEB do ambiente em um único ponto, auxiliando assim no gerenciamento da rede e criação de regras de NAT no firewall;
6. Centralização dos log's de acesso (requisições e respostas), já que as mesmos estarão sendo feitas ao servidor de PROXY REVERSO;
7. Os servidores WEB não ficam diretamente ligados a rede pública Internet e assim A aumentando a “Segurança”. Atualização de patchs e correções apenas no servidor de PROXY REVERSO, já que o mesmo estará respondendo pelos servidores WEB;
8. SSL Offload: Permite a utilização de SSL (Secure Sockets Layer) mesmo para os servidores web internos que hospedam aplicações que não suportam criptografia. Essa funcionalidade é um grande reforço na segurança do ambiente, pois, mesmo que as aplicações não suportem criptografia, os dados originados na Internet com destino ao proxy reverso podem ser criptografados, deixando sem criptografia, apenas a comunicação entre o proxy reverso e os servidores WEB internos (tráfego com maior controle de proteção, pois, está sendo transmitido dentro da rede local);
9. Com o PROXY REVERSO é possível configurar para que as requisições utilizadas para a propagação de vírus e vermes (worms) possam ser bloqueadas imediatamente impedindo que esse tipo de tráfego chegue até os servidores web internos;

Só mais uma coisa.. quais são os programas que podem me ajudar a implantar o PROXY REVERSO?

Podemos responder isso em 2 grupos.

Soluções 'instaláveis':

• Cisco Cache Engine (http://www.cisco.com);
• iPlanet Web Proxy Server (http://www.sun.com);
• ISA Server (http://www.microsoft.com);
• LocalDirector (http://www.cisco.com);
• ProxySG (http://www.bluecoat.com);
  
• Squid Web Proxy Cache (http://www.squid-cache.org);
• Nginx (http://wiki.nginx.org/).
• Apache (http://www.apache.org/);
  

Soluções em Appliance:

• Citrix NetCaler (http://www.citrix.com.br)
• Cisco CSM - Content Switch Module (http://www.cisco.com)
• F5 -Big IP (http://www.f5.com)

E para não reinventar a roda, temos alguns links de configurações em plataforma Linux:

http://www.koruja.org/
http://unde-rlinux.org/
http://www.youtube.com/ (Não deixe de assistir, ajuda a entender o propósito, o mesmo está abaixo.)

Gostaria de agradecer aos autores destas fontes acima e a um cara chamado Leandro de Souza Lopes, pois com base na monografia dele, pude esclarecer muitas dúvidas.

Mais uma vez... Obrigado!