Já faz um tempo, mas achei que nosso caso de uso seria útil ...
Primeiro + ponto na AWS .
Temos um servidor dedicado em um host conhecido. É uma especificação enorme e está tentando administrar as lojas Magento há muito tempo. Ajustamos e brincamos com a configuração de uma maneira que não derrubará os sites. Nosso host não havia instalado o APC (antes de eu começar), então eles o instalaram, mesmo que nós pagássemos para construir um servidor Magento, derrubamos nossos sites por 3 horas com uma versão PHP quebrada. Conseguimos fazê-lo novamente com um APC desativado.
na AWS Temos uma réplica exata de todas as nossas AMIs (NGINX, NGINX + verniz, servidor de controle) aguardando na AWS com as quais podemos iniciar e brincar a qualquer momento. Podemos clonar o volume EBS em que nossos dados do Vhosts estão localizados no mapa de alguns IPs para os endereços IP internos da VPC, trancá-los no servidor e estar em funcionamento em nenhum momento. Faça nosso TESTE, verifique se está tudo bem, faça alterações no sistema LIVE e desligue a réplica até que seja necessária novamente. Neste ponto, as alterações que fizemos na configuração, clonamos em uma nova versão AMI.
Segundo + ponto para a AWS . Atingimos um limite de endereço IP em nosso host atual. Na AWS, temos vários endereços IP internos da VPC e alocamos em nossa conta 20 IP externos elásticos que podemos mapear para endereços IP internos. Os recursos de rede no AWS VPC são absolutamente incríveis. É irreal como eles empacotaram isso para administradores de rede de baixo nível. Demorou 3 dias para obter alguns novos endereços IP em nosso host e adicionados ao firewall.
É aqui que eu dou à AWS outra +
Os backups em nosso servidor dedicado atual são apenas um clone de uma pasta mantida em um cofre de backup. Basicamente, uma unidade montada. Uma unidade montada disponível apenas para esse servidor. Portanto, no caso de uma interrupção massiva, teríamos que obter uma nova configuração do servidor, montar o armazenamento de backup, instalar e configurar nosso novo servidor exatamente da mesma maneira (grande tarefa) e recriar os dados. Nosso anfitrião possui 4 horas de retorno para obter um novo hardware, mas isso não significa nada para mim. Está recebendo a configuração e os sites novamente.
Nosso negócio oferece soluções para negócios por todo o ciclo de vida da web. Consultoria, design, SEO, suporte e manutenção. Se tivéssemos uma interrupção em nosso dedicado, sairíamos do negócio, porque levaria dias antes de nos levantarmos novamente. Não podemos ter esse cenário nem no nosso mapa what if. Isso simplesmente não pode acontecer.
Atualmente, na AWS, temos nosso conteúdo da Web nas instâncias da AWS montadas nos volumes EBS a 750IOPS e uma segunda instância (o que chamamos de servidor de controle) que sincroniza os dados em outra zona de disponibilidade dentro do cronograma e atualiza uma instância para a configuração mais recente, caso precisa iniciar uma instância dessa AMI. Ele sincroniza todas as configurações do NGINX, arquivos de instalação do PHP-FPM para isso.
Então agora temos dois conjuntos de dados; uma AMI que é um clone do servidor web NGINX de produção e uma cópia do conteúdo do diretório Vhosts com arquivos de configuração e Vhosts, caso seja necessário iniciar um novo servidor.
É aqui que a AWS recebe outro +
Nosso servidor dedicado se esforça nos horários de pico. Sim, rodamos o Magento, por isso é um pouco diferente de alguns aplicativos. Temos uma configuração de disco raid Quad Core de 32 GB e, às vezes, ocorre até interrupções quando um cliente envia uma campanha de e-mail ou duas ao mesmo tempo. Nós mal podemos fazer nada. Possui MySQL localmente, sua memória otimizada para MYSQL, mas os discos são ruins.
Na AWS, executamos 3 instâncias de alta CPU. 2 servidores da Web NGINX / PHP-FPM, além de uma instância de cache NGINX SSL + Varnish. Em seguida, temos um servidor Magento Admin menor que hospeda todas as imagens e mídias que são mapeadas via CNAMES através do Cloudfront. Todas essas instâncias são reservadas para manter os custos baixos.
Em seguida, temos nossos bancos de dados no RDS em uma instância grande de 2000IOPS que os dois servidores da Web conectam a ele, que tira instantâneos a cada noite. Com um pouco de tempo de inatividade (temos páginas de manutenção para nossas lojas), podemos redimensionar o IOPS e o tamanho da instância. A melhor coisa sobre o RDS é que podemos tirar um instantâneo mais recente e criar um novo banco de dados para teste e desenvolvimento. Então desligue. É simplesmente fantástico.
Usamos o Elastic Cache + e agora testamos o Redis para gerenciar o cache dos servidores Web front-end. Mais uma vez, podemos redimensionar para cima e para baixo.
Podemos adicionar novas instâncias sob demanda de alta CPU dos servidores (clonando nosso front-end NGINX) com alguns trabalhos manuais para ajudar no Natal e, se precisarmos, quando um cliente nos disser que enviará uma forte campanha de e-mail de 100.000 vendas de produtos com 75% de desconto.
Agora estamos testando nosso dimensionamento automático na Amazon e como acionamos os servidores, adicionamos endereços IP, atualizamos as configurações do NGINX, etc. e começamos a trabalhar sem problemas, mas também retiramos o servidor e o desligamos durante os períodos de silêncio (próximo).
AWS + + A
movimentação de dados em nosso dedicado é uma interrupção do serviço. Copiar, Rsync MV etc atingirá os discos IO, o que por sua vez atrasa os sites.
Usar volumes e snapshots na AWS é tão fácil. Realmente não preciso dizer nada aqui.
AWS +++++++
Gerenciamento e controle geral do servidor. Na verdade, não há realmente visibilidade no nosso servidor dedicado. É apenas SSH e algum servidor realmente ruim informa que o nosso host envia mensalmente.
Na AWS, podemos ver estatísticas que, embora não sejam totalmente precisas aos meus olhos sobre o desempenho dos aplicativos, oferecem uma boa idéia de como a Instância real está funcionando. Temos alarmes configurados para detectar problemas.
Conclusão
* AWS vs Dedicado - Pure Power. * Para todos os AWS Trolls que não estou dizendo ou tentando dizer, a AWS executará um dedicado com dois Quads, cargas de memória SSD etc. Até a AWS não tentará dizer isso. Há coisas que você pode fazer para melhorar o desempenho, otimização do EBS, provisionamento de IOPS e redimensionar instâncias, mas eu sei que um puro esqueleto dedicado será superior ao desempenho.
AWS vs Dedicated - Arquitetura para uma solução adequada
Os servidores dedicados estavam sentados em um rack solitário em algum lugar que não será suficiente para mim. Esta não é uma situação do mundo real ou adequada como uma solução aos meus olhos ao fornecer às empresas uma solução para administrar suas lojas ou sites.
Temos toda a nossa rede de servidores na AWS VPC, podemos expandir, contratar, ver onde todos os nossos recursos estão em um só lugar. Como solução, eu nunca gostaria de voltar para um servidor dedicado.
Se eu estivesse executando um site que pudesse lidar com uma interrupção massiva e pudéssemos esperar para reconstruir um novo servidor com o host ou estivesse disposto a usar dois hosts ou AWS como backup e mover um site se um dedicado fosse desativado, esse é o única maneira de fazer isso. Isso por si só é um problema demorado.
Custos
A razão pela qual os servidores dedicados agora são tão baratos é porque a AWS está oferecendo maneiras baratas de gerenciar seu próprio mini data center, que é o que muitos data centers usaram para adicionar premium. Agora, há uma mudança nos preços e os data centers precisam usar técnicas de escória contra a AWS para vender seus serviços ou gritar sobre a potência do Raw Server e a falta de alguns tipos de instância da AWS.
As pessoas que comparam um servidor dedicado a uma instância da AWS devem realmente levar em consideração todos os serviços extras que a AWS oferece em torno dessa instância do servidor e mapear isso a um preço dedicado. Deixe-me expandir. Ao sair e notificar o contrato ao nosso host atual, eles disseram à AWS isso, custos EBS com desempenho ruim, etc. etc. Por isso, enviamos um mapa da solução do que queríamos.
- LAN privada com políticas de segurança / roteamento e firewalls
- 20 endereços IP externos, com a capacidade de remapear nos servidores em tempo real ou através do painel de controle
- 4 servidores com 8 núcleos, cada um com 16 threads
- 32 GB de RAM
- Servidor de banco de dados com a capacidade de fornecer até 10000 IOPS, mas geralmente sobre 2000IOP
- Backups de apontar e clicar
- Sem contrato ou apenas 12 meses
Além de não poderem fazer tudo isso, disseram que, se pudessem fornecer a pilha de software para isso, nossos custos de instalação teriam sido em torno de 10.000 libras esterlinas mais taxas mensais.
Servidores dedicados superarão as nuvens, mas isso é coisa do passado agora. Você pode ver isso no marketing contra a computação em nuvem. A computação em nuvem é a solução completa que une as pequenas empresas ao seu próprio data center. Aos meus olhos e depois de definir muitas soluções da AWS, a AWS é a solução comercial no momento
Sei que, quando compro uma Instância da AWS, não é apenas a Instância, mas todo o kit anexado a ela. Sei que quando compro um servidor dedicado, é realmente apenas um servidor despejado em um rack com um cabo conectado.
Sei que £ por £, um servidor dedicado será melhor que a AWS, mas para meus clientes e necessidades reais de negócios, a AWS supera em massa as soluções dedicadas