Página 1
Marcos de Benedicto – 16/nov/2012
Distribuição de Sistema de Cache
EXT CACHE_1 EXT CACHE_2 EXT CACHE_3 EXT CACHE_4
DMZ CACHE_1 DMZ CACHE_2 DMZ CACHE_3 DMZ CACHE_4
DB CACHE_1 DB CACHE_2
BALANCE DOMAIN
DMZ Web-Cache
External Web-Cache
Green Zone
App-Cache
WEB SERVER
APP SERVER
DATABASE
FW/NLB
FW/NLB
Página 2
Marcos de Benedicto – 16/nov/2012
Distribuição de Sistema de Cache
DOMAIN
NS1.DOMAIN NS2.DOMAIN
BALANCER_1 BALANCER_2
EXT CACHE_1 EXT CACHE_2 EXT CACHE_3 EXT CACHE_4
FW/NLB
Cache Layer-1
1. Registro de domínio. Registro.br
2. Configuração de dominio.com.br em dois DNS, uma
sugestão seria utilizar o Route53 da Amazon. Neste caso
configurar o domínio em duas regiões diferentes.
3. Configurar balanceamento para o “External Web Cache ”,
existem muitas soluções para esta camada, uma delas seria o
Akamai. São aconselhados pelo menos 4 regiões de cache
para esta camada os quais podem ser configurados no ELB da
Amazon, lembrando que o ELB deve ser montado em pelo
menos duas regiões diferentes dentro da Amazon.
4. Configuração do “External Web-Cache” ou “Web Cache
Accelerator”, a sugestão aqui é configurar no Akamai, este
serviço é muito utilizado pelos portais e garante uma boa
integridade e performance. Este serviço deve apontar para
uma camada de Firewall/NLB instalada na DMZ. Esta Camada
é constituída de um equipamento de Firewall para garantia de
segurança e um NLB para distribuição de nós de WebServer.
Página 3
Marcos de Benedicto – 16/nov/2012
Distribuição de Sistema de Cache
EXT CACHE_1 EXT CACHE_2 EXT CACHE_3 EXT CACHE_4
FW/NLB
DMZ CACHE_1 DMZ CACHE_2 DMZ CACHE_3 DMZ CACHE_4
FW/NLB
DATA
Cache Layer-2
1. Balanceamento do NLB garante que os nós do cache sejam
utilizados de forma igual, a sugestão para este balanceamento
é LeastConns + source address onde são analisadas as
conexões de cada nó e distribuídas de forma igual, source
address para que se mantenham as sessões em apenas um
nó.
2. Cache de DMZ, nesta camada a sugestão é utilizar o Varnish
o qual recebe os requests do NLB pesquisa na memória
interna e caso não exista o objeto ele solicita ao webserver,
esta pesquisa é feita da seguinte forma: Consulta ao objeto
do varnish, caso existe o varnish pergunta ao webserver que
responde com 304(não modificado) ou com 200(para
atualização do cache server)
3. Firewall entre DMZ e GreenZone, este firewall garante que
a comunicação entre cache server e webserver, alem de
balancear a camada de webserver. Esta camada garante que
não serão feitas request de outros ambientes e que estes
webservers não estarão disponíveis para consulta fora do
modelo de cache.
Página 4
Marcos de Benedicto – 16/nov/2012
Distribuição de Sistema de Cache
WEB
SERVER_1
WEB
SERVER_2
APP
SERVER_1
APP
SERVER_2
DB CACHE_1 DB CACHE_2
DB NODE_1 DB NODE_2
FW/NLBCache Layer-3
1. GreenZone é a área onde são inseridos e modificados os
dados, esta área deve ser protegida de qualquer intervenção
externa e deve ter a intervenções internas controladas por
alguma ferramente de analise de logs e segurança.
2. São montadas redundancias nesta camada afim de garantir
redundancia e não performance, neste modelo os
responsaveis pela performance são os cache servers, portanto
estão nesta camada dois webservers, dois apps servers e dois
nós de banco de dados. Este modelo é suficiente para a
estrutura e mais simples para o controle de segurança e
aplicação de patchs.
3. Os webservers se comunicam com o apps server via
mod_wl_2.0 o qual já tem um balanceamento de carga e
redundância necessários para o ambiente.
4. Os apps servers devem fazer a consulta da camada de
NoSQL(DB CACHE) implementada com Layer-3 de cache, este
funciona como uma tabela de consulta dos principais objetos
do banco diminuindo a carga dos nós do banco.
5. A persistência de dados deve ser feita com uma conexão
direta entre apps servers e banco de dados, é um caminho
diferente da consulta, neste caso não é necessário que exista
a camada de NoSQL(DB CACHE).