Como funciona a escalabilidade?

O auto-scale permite que sua aplicação consiga se adaptar para atender mudanças no volume de acessos, adicionando e removendo recursos de acordo com a quantidade de usuários.

Criando uma Aplicação Escalável

Você precisa informar no momento da criação se a aplicação será ou não escalável. Caso precise mudar o perfil da aplicação depois de criada, será necessário criar uma nova e um caminho rápido para isso é clonar a aplicação, onde é possível tornar a nova aplicação escalável ou não, além de trocar o tamanho dos gears. 

Bom, como estamos nesse negócio para criar aplicações, mãos a obra. Supondo que você já tenha o RHC instalado (veja como instalar) vá na linha de comando e rode:

$ rhc app create [APP] [APP-TYPE...] --scaling

Sendo que:

[APP]            O nome da aplicação
[APP-TYPE...] Tipo da aplicação, que pode ser php-5.5, ruby-1.9, python-2.9, etc
--scaling|-s Indica que a aplicação será escalável

Lista completa de tipos de aplicações aqui ou rode o comando:

$ rhc cartridges

Aplicações Escaláveis e Não-escaláveis

Se você criar uma aplicação como não escalável, ela irá ocupar um único gear e todo o tráfego será direcionado para ele. Novos cartuchos como banco de dados ou cache serão instalados neste único gear. Podemos fazer aqui uma analogia com um servidor onde todos os serviços são instalados, compartilhando os recursos de CPU, memória e disco desde único servidor.

Ao criar uma aplicação escalável, o primeiro gear recebe o código da aplicação e uma instância do HAProxy, responsável pelo balanceamento da carga. Se você adicionar novos cartuchos para sua aplicação, como banco de dados ou cache, estes serão instalados em gears dedicados, ou seja, outros gears. 

 

Como a Escalabilidade Funciona?

Um Load Balancer HAProxy é posicionado entre sua aplicação e a internet. Todo o tráfego web para seus gears é roteado pelo HAProxy. Quando o tráfego web aumenta, o HAProxy notifica o OpenShift sobre a necessidade de novos gears.

O algoritmo de escalabilidade prevê uma média de 20 reqs/seg em cada gear. Se esta limite for alcançado - distribuido entre todos os gears da aplicação - então o HAPrxy incia o processo de scale-out: criar um novo gear para atender o crescimento da demanda. Se esta média cair para 50% da capacidade total (10 reqs/seg em cada gear) então o processo inverso, scale-down, é inciado e o gear mais novo é removido.

Ao atingir 3 gears, o primeiro deles deixa de atender requisições web e passa a fazer apenas o roteamento. Isso permite ao HAProxy utilizar sozinho os recursos do gear, mantendo a performance do sistema em níveis superiores.

Código Escalado

Durante o scale-out/down, o repositório git é copiado para cada novo gear, garantindo que todos executam o mesmo código. Se você fizer uma alteração de código em seu repositório local e em seguida publicá-lo, todos os gears de aplicação recebem esta alteração.

Dados Locais vs Compartilhados

Os dados entre os gears não são compartilhados. Cada gear possui seu storage privado. Isto significa que escrever um arquivo no gear X não o torna acessível ao gear Y.

Para dados persistentes, utilize a área apontada na variável de ambiente OPENSHIFT_DATA_DIR. Este diretório é mantido entre as publicações de código, mas é destruida assim que um gear é removido.

Caso sua aplicação precise compartilhar dados entre gears distintos, ou preservar estes dados independente da escalabilidade (criar/remover gears), sugerimos utilizar dois métodos.

1 - Salve seus dados em um banco de dados;

2 - Utilize um storage externo, como Amazon S3.

Tem mais dúvidas? Envie uma solicitação

0 Comentários

Por favor, entre para comentar.
Powered by Zendesk