###Introdução
Ao decidir qual arquitetura de servidor utilizar para seu ambiente, existem muitos fatores a considerar, tais como desempenho, escalabilidade, disponibilidade, confiabilidade, custo, e facilidade de gerenciamento.
Aqui está uma lista de configurações de servidor comumente utilizadas, com uma breve descrição de cada uma, incluindo prós e contras. Tenha em mente que todos os conceitos abordados aqui podem ser usados em várias combinações entre si, e que cada ambiente tem requisitos diferentes, assim não há uma configuração única, correta.
##1. Tudo em um único servidor
O ambiente inteiro reside em um único servidor. Para uma aplicação web típica, que incluiria um servidor web, servidor de aplicação, e um servidor de banco de dados. Uma variação comum desta configuração é a pilha LAMP, que significa Linux, Apache, MySQL, e PHP, em um único servidor.
Caso de Uso: Bom para a configuração rápida de uma aplicação, uma vez que é a configuração mais simples possível, mas oferece pouco em termos de escalabilidade e isolamento de componente.
###Prós:
###Contras:
Aplicação e banco de dados disputam os mesmos recursos de servidor (CPU, Memória, I/O, etc.) que, além de possível baixo desempenho, pode tornar difícil de determinar a origem (aplicação ou banco de dados) do baixo desempenho.
Não é facilmente escalável horizontalmente
###Tutoriais Relacionados:
##2. Servidor de banco de dados separado
O sistema gerenciador de banco de dados (SGBD) pode ser separado do resto do ambiente para eliminar a disputa de recurso entre a aplicação e a base de dados, e para aumentar a segurança removendo a base de dados da DMZ, ou internet pública.
Caso de Uso: Bom para configurar rapidamente uma aplicação, enquanto evita a aplicação e o banco de dados de disputarem os mesmos recursos de sistema.
###Prós:
As camadas de aplicação e de banco de dados não competem pelos mesmos recursos de servidor (CPU, Memória, I/O, etc.)
Você pode escalar verticalmente cada camada separadamente, adicionando mais recursos para qualquer servidor que necessita maior capacidade
Dependendo da sua configuração, pode-se aumentar a segurança removendo seu banco de dados da DMZ
###Contras:
Configuração um pouco mais complexa do que com um único servidor
Problemas de desempenho podem surgir se a conexão de rede entre os dois servidores está com alta-latência (ou seja, os servidores estão distantes geograficamente um do outro), ou a largura de banda é muito baixa para a quantidade de dados a ser transferida.
###Tutoriais Relacionados:
##3. Balanceador de Carga (Proxy Reverso)
Balanceadores de carga podem ser adicionados a um ambiente de servidor para melhorar o desempenho e a confiabilidade distribuindo a carga por múltiplos servidores. Se um dos servidores que tem balanceamento de carga falhar, os outros servidores irão tratar o tráfego de entrada até que o servidor defeituoso volte a funcionar novamente. Ele pode ser usado também para servir múltiplas aplicações através do mesmo domínio e porta, utilizando um proxy reverso de camada 7 (camada de aplicação).
Exemplos de softwares capazes de balancear carga via proxy reverso: HAProxy, Nginx, e Varnish.
Caso de Uso: Útil em um ambiente que requer escalabilidade pela adição de mais servidores, também conhecido como escalabilidade horizontal.
###Prós:
###Contras:
###Tutoriais Relacionados
##4. Acelerador HTTP (Proxy Reverso com Cache)
Um acelerador HTTP, ou Proxy HTTP Reverso com Cache, pode ser usado para reduzir o tempo que ele leva para servir conteúdo para um usuário através de uma variedade de técnicas. A principal técnica empregada com um acelerador HTTP é fazer cache de respostas do servidor web ou do servidor de aplicação em memória, assim requisições futuras para o mesmo conteúdo podem ser servidas rapidamente, com menos interações desnecessárias com os servidores web e de aplicação.
Exemplos de softwares capazes para aceleração HTTP: Varnish, Squid, Nginx.
Caso de Uso: Útil em ambientes com aplicações web dinâmicas de conteúdo pesado, ou com muitos arquivos comumente acessados.
###Prós:
###Contras:
###Tutoriais Relacionados:
#5. Replicação de Banco de Dados Mestre-Escravo
Uma forma de melhorar o desempenho de um sistema de banco de dados que executa muitas leituras em comparação com as gravações, como um CMS, é a replicação de banco de dados mestre-escravo. A replicação mestre-escravo requer um nodo mestre e um ou mais nodos escravos. Nesta configuração, todas as atualizações são enviadas ao nodo mestre e as leituras podem ser distribuídas entre todos os outros nodos.
Caso de Uso: Bom para aumentar o desempenho de leitura para a camada de banco de dados de uma aplicação.
Aqui está um exemplo de uma configuração mestre-escravo, com um único nodo escravo:
###Pros:
###Contras:
###Tutoriais Relacionados:
#Exemplo: Combinando Conceitos
É possível fazer balanceamento de carga dos servidores de cache, adicionalmente aos servidores de aplicação, e usar replicação de banco de dados em um só ambiente. O propósito de combinar estas técnicas é colher os benefícios de cada uma sem introduzir muitos problemas e complexidade. Aqui está um exemplo de como um ambiente de servidor deve se parecer:
Suponhamos que o balanceador de carga está configurado para reconhecer requisições estáticas (como imagens, css, javascript, etc.) e enviar estas requisições diretamente aos servidores de cache, e enviar outras requisições para os servidores de aplicação.
Aqui está uma descrição do que aconteceria quando um usuário envia um pedido de conteúdo dinâmico:
Se o usuário requisitar conteúdo estático:
Este ambiente tem ainda dois pontos únicos de falha (balanceador de carga e servidor de banco de dados mestre), mas ele fornece todos os outros benefícios de confiabilidade e desempenho que descrevemos em cada seção acima.
##Conclusão
Agora que você está familiarizado com algumas configurações básicas de servidor, você deve ter uma boa ideia de que tipo de configuração você gostaria de usar para a sua própria aplicação. Se você estiver trabalhando para melhorar seu próprio ambiente, lembre-se que um processo iterativo é melhor para evitar a introdução de muitas complexidades muito rapidamente.
Deixe-nos saber de quaisquer configurações você recomenda ou gostaria de aprender mais sobre, nos comentários abaixo!
Por Mitchell Anicas
Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in our Questions & Answers section, find tutorials and tools that will help you grow as a developer and scale your project or business, and subscribe to topics of interest.
Sign up
Boa noite. Otimo material e muito bem explicado… Aonde acho mais materias com a explicação mais a fundo sobre os assuntos.
Att., Fernando
Parabéns, excelente explicação.
Olá Mitchell,
Estou enfrentando muitos problemas de Proxy do Brasil para o DataServer dos Estados Unidos, por acaso a solução 3 ou 4 poderiam ser aplicadas com um servidor externo a Digital Ocean.
Estou usando Floating IP e seguido a minhas aplicações ficam fora do ar, mas quando vejo qual o problema é algum Proxy da Embratel para de localizar o Floating IP, mas consegue localizar o Public IP da Droplet.
traceroute to 159.203.. (159.203..), 64 hops max, 52 byte packets 1 192.168.0.1 (192.168.0.1) 215.404 ms 1.367 ms 1.314 ms 2 bd077701.virtua.com.br (189.7.119.1) 38.128 ms 36.018 ms 31.568 ms 3 bd077064.virtua.com.br (189.7.112.100) 10.869 ms 11.838 ms 12.980 ms 4 embratel-g0-0-0-3-uacc01.pae.embratel.net.br (200.213.139.37) 107.653 ms embratel-g0-0-0-8-uacc02.rjo.embratel.net.br (200.167.245.1) 33.927 ms embratel-g1-0-3-iacc05.pae.embratel.net.br (200.247.68.137) 35.125 ms 5 ebt-h0-9-0-0-tcore01.pae.embratel.net.br (200.244.213.27) 36.636 ms ebt-t0-3-1-2-udist02.pae.embratel.net.br (200.230.3.164) 34.795 ms 34.940 ms 6 ebt-bp1422-intl02.nyk.embratel.net.br (200.230.220.114) 144.453 ms ebt-t0-7-0-9-tcore01.pae.embratel.net.br (200.244.212.216) 37.562 ms ebt-t0-7-0-10-tcore01.pae.embratel.net.br (200.244.212.204) 40.647 ms 7 ebt-b1511-tcore01.ctamc.embratel.net.br (200.230.251.218) 158.782 ms * * 8 ebt-b1452-intl02.nyk.embratel.net.br (200.230.220.126) 139.229 ms 139.076 ms 137.392 ms 9 * * * 10 * * *
Alguma sugestão?
Gostaria de saber um pouco melhor como implementar a situação 3 para que faça uso também de um servidor que funcionaria como storage. Por exemplo, teria dois servidores cada um rodando a aplicação e teria que montar uma unidade para acessar e gravar dados.
Obrigado Fernando Pimenta pela tradução e Mitchell Anicas pelo post. Excelente Tutorial muito bem explicado com tudo que é preciso saber para ter um ambiente extremamente profissional, tanto para estudo como produção.