Benefícios do EBS vs. armazenamento da instância (e vice-versa) [fechado]

Não estou claro quanto aos benefícios que recebo do EBS versus o repositório de instâncias para minhas instâncias no Amazon EC2. Se alguma coisa, parece que o EBS é muito mais útil (parar, iniciar, persistir + melhor velocidade) com relativamente pouca diferença de custo ...? Além disso, existe alguma métrica para saber se mais pessoas estão usando o EBS agora que ele está disponível, considerando que ainda é relativamente novo?

A linha inferior é que você quase sempre deve usar instâncias apoiadas pelo EBS.

Aqui está o porquê

• As instâncias suportadas pelo EBS podem ser definidas para que não possam (acidentalmente) ser encerradas por meio da API.
• As instâncias suportadas pelo EBS podem ser interrompidas quando você não as estiver usando e retomadas quando precisar delas novamente (como pausar um PC Virtual), pelo menos com meus padrões de uso economizando muito mais dinheiro do que gasto em algumas dezenas de GB de armazenamento EBS.
• As instâncias suportadas pelo EBS não perdem o armazenamento da instância quando elas falham (não é um requisito para todos os usuários, mas torna a recuperação muito mais rápida)
• Você pode redimensionar dinamicamente o armazenamento da instância do EBS.
• Você pode transferir o armazenamento da instância do EBS para uma instância totalmente nova (útil se o hardware da Amazon em que você estava executando fica esfarrapado ou morre, o que acontece de tempos em tempos)
• É mais rápido iniciar uma instância suportada pelo EBS porque a imagem não precisa ser buscada no S3.
• Se o hardware que sua instância suportada pelo EBS estiver agendado para manutenção , a parada e o início da instância serão migrados automaticamente para o novo hardware. Também pude mover uma instância suportada pelo EBS em falha de hardware, interrompendo a instância e iniciando-a novamente (sua milhagem pode variar em falha de hardware).

Eu sou um usuário pesado da Amazon e mudei todas as minhas instâncias para o armazenamento suportado pelo EBS assim que a tecnologia saiu da versão beta. Fiquei muito feliz com o resultado.

O EBS ainda pode falhar - não é uma bala de prata

Lembre-se de que qualquer parte da infraestrutura baseada em nuvem pode falhar a qualquer momento. Planeje sua infraestrutura de acordo. Embora as instâncias suportadas pelo EBS forneçam um certo nível de durabilidade em comparação com as instâncias efêmeras de armazenamento, elas podem e falham. Tenha uma AMI a partir da qual você pode iniciar novas instâncias, conforme necessário, em qualquer zona de disponibilidade, fazer backup de seus dados importantes (por exemplo, bancos de dados) e, se seu orçamento permitir, execute várias instâncias de servidores para balanceamento de carga e redundância (idealmente em várias zonas de disponibilidade) )

Quando não

Em alguns momentos, pode ser mais barato obter E / S mais rápida nas instâncias do Repositório de Instâncias. Houve um tempo em que certamente era verdade. Agora, existem muitas opções para armazenamento do EBS, atendendo a muitas necessidades. As opções e seus preços evoluem constantemente à medida que a tecnologia muda. Se você tiver uma quantidade significativa de instâncias realmente descartáveis ​​(elas não afetam muito os seus negócios se simplesmente desaparecerem), faça as contas sobre custo x desempenho. Instâncias suportadas pelo EBS também podem morrer a qualquer momento, mas minha experiência prática é que o EBS é mais durável.

99% da nossa configuração da AWS é reciclável. Então, para mim, realmente não importa se eu encerro uma instância - nada está perdido. Por exemplo, meu aplicativo é implantado automaticamente em uma instância do SVN, nossos logs são gravados em um servidor syslog central.

O único benefício do armazenamento de instância que vejo são a economia de custos. Caso contrário, as instâncias suportadas pelo EBS vencem. Eric mencionou todas as vantagens.

[2012-07-16] Gostaria de formular esta resposta muito diferente hoje.

Não tive nenhuma boa experiência com instâncias apoiadas pelo EBS no ano passado. As últimas paradas da AWS também destruíram o EBS.

Suponho que um serviço como o RDS também use algum tipo de EBS e que pareça funcionar na maior parte do tempo. Nos casos em que gerenciamos a nós mesmos, nos livramos do EBS sempre que possível.

Livrando-nos a um ponto em que movemos um cluster de banco de dados de volta ao ferro (= hardware real). A única parte restante de nossa infraestrutura é um servidor de banco de dados, onde distribuímos vários volumes EBS em um RAID de software e fazemos backup duas vezes por dia. Tudo o que seria perdido entre os backups, podemos conviver.

O EBS é uma tecnologia um tanto quanto flakey, pois é essencialmente um volume de rede: um volume conectado ao servidor remotamente. Não estou negando o trabalho feito com ele - é um produto incrível, pois o armazenamento persistente essencialmente ilimitado fica a apenas uma chamada de API. Mas dificilmente é adequado para cenários em que o desempenho de E / S é essencial.

Além de como o armazenamento em rede se comporta, toda a rede é compartilhada nas instâncias do EC2. Quanto menor uma instância (por exemplo, t1.micro, m1.small), pior fica porque suas interfaces de rede no sistema host real são compartilhadas entre várias VMs (= sua instância do EC2) que são executadas em cima dela.

Quanto maior a instância, melhor é claro. Melhor aqui significa dentro da razão .

Quando a persistência é necessária, sempre aconselho as pessoas a usar algo como S3 para centralizar entre instâncias. S3 é um serviço muito estável. Em seguida, automatize a configuração da instância para um ponto em que você possa inicializar um novo servidor e ele se prepare sozinho. Então não há necessidade de armazenamento em rede que dura mais que a instância.

Então, apesar de tudo, não vejo nenhum benefício para as instâncias apoiadas pelo EBS do que nunca. Prefiro adicionar um minuto ao bootstrap e depois executar com um potencial SPOF.

Nós gostamos de instância-loja. Isso nos obriga a tornar nossas instâncias completamente recicláveis ​​e podemos automatizar facilmente o processo de construção de um servidor do zero em uma determinada AMI. Isso também significa que podemos trocar facilmente as AMIs. Além disso, o EBS ainda apresenta problemas de desempenho de tempos em tempos.

Eric praticamente acertou em cheio. Nós ( Bitnami ) somos um fornecedor popular de AMIs gratuitas para aplicativos e estruturas de desenvolvimento populares (PHP, Joomla, Drupal, você entendeu). Posso dizer que as AMIs suportadas pelo EBS são significativamente mais populares que as suportadas pelo S3. Em geral, acho que as instâncias apoiadas em s3 são usadas para trabalhos distribuídos e com tempo limitado (por exemplo, processamento em larga escala de dados) onde, se uma máquina falha, outra simplesmente é ativada. O AMIS suportado pelo EBS costuma ser usado para tarefas 'tradicionais' do servidor, como servidores da Web ou de banco de dados que mantêm o estado localmente e, portanto, exigem que os dados estejam disponíveis no caso de falha.

Um aspecto que não vi mencionado é o fato de que você pode tirar instantâneos de uma instância suportada pelo EBS durante a execução, permitindo efetivamente backups muito econômicos da sua infraestrutura (os instantâneos são baseados em blocos e incrementais)

Eu tive exatamente a mesma experiência que Eric na minha última posição. Agora, no meu novo trabalho, estou passando pelo mesmo processo que realizei no meu último trabalho ... reconstruindo todas as AMIs para instâncias suportadas pelo EBS - e possivelmente como máquinas de 32 bits (mais baratas - mas não podem usar a mesma AMI em 32 e 64 máquinas).

As instâncias suportadas pelo EBS são iniciadas com rapidez suficiente para que você possa começar a usar a API Amazon AutoScaling, que permite usar as métricas do CloudWatch para acionar o lançamento de instâncias adicionais e registrá-las no ELB (Elastic Load Balancer) e também para desativá-las quando não é mais necessário.

Esse tipo de dimensionamento automático dinâmico é o objetivo da AWS - onde as economias reais na infraestrutura de TI podem entrar em jogo. É praticamente impossível fazer o dimensionamento automático com as instâncias antigas do s3 "InstanceStore".

Estou começando a usar o EC2, então não sou um especialista, mas a documentação da Amazon diz:

recomendamos que você use o armazenamento da instância local para dados temporários e, para dados que exijam um nível mais alto de durabilidade , recomendamos o uso de volumes do Amazon EBS ou o backup dos dados no Amazon S3.

Ênfase minha.

Eu faço mais análises de dados do que hospedagem na web, portanto persistência não importa tanto para mim quanto para um site. Dada a distinção feita pela própria Amazon, eu não assumiria que o EBS é adequado para todos.

Vou tentar lembrar de pesar novamente depois de usar os dois.

O EBS é como o disco virtual de uma VM:

• Durável, as instâncias suportadas pelo EBS podem ser iniciadas e interrompidas livremente (economizando dinheiro)
• Pode ser capturado instantaneamente a qualquer momento, para obter backups pontuais
• As AMIs podem ser criadas a partir de instantâneos do EBS, para que o volume do EBS se torne um modelo para novos sistemas

O armazenamento da instância é:

• Local, geralmente mais rápido
• Sem rede, em casos normais, a E / S EBS tem o custo da largura de banda da rede (exceto as instâncias otimizadas para EBS, que possuem largura de banda EBS separada)
• Possui E / S limitada por segundo IOPS. Até a E / S provisionada atinge o máximo de alguns milhares de IOPS
• Frágil. Assim que a instância é interrompida, você perde tudo no armazenamento da instância.

Aqui é onde usar cada um:

• Use o EBS para a partição do SO de backup e armazenamento permanente (dados do banco de dados, logs críticos, configuração do aplicativo)
• Use o armazenamento da instância para dados em processo, logs não críticos e estado transitório do aplicativo. Exemplo: armazenamento de classificação externa, arquivos temporários etc.
• O armazenamento de instância também pode ser usado para dados críticos ao desempenho, quando houver replicação entre instâncias (DBs NoSQL, sistemas de fila / mensagem distribuídos e DBs com replicação)
• Use S3 para dados compartilhados entre sistemas: conjunto de dados de entrada e resultados processados, ou para dados estáticos usados ​​por cada sistema quando lançados.
• Use AMIs para servidores pré-cozidos e inicializáveis

A maioria das pessoas escolhe usar a instância suportada pelo EBS, pois é estável. É mais seguro, porque tudo o que você tem executando e instalado dentro dele sobreviverá a uma parada / parada ou a qualquer falha da instância.

O armazenamento da instância é sem estado, você os perde com todos os dados internos, no caso de qualquer situação de falha da instância. No entanto, é gratuito e mais rápido porque o volume da instância está vinculado ao servidor físico em que a VM está sendo executada.

Para alguém novo em tudo isso e se acidentalmente pousou aqui

A partir de agora, todas as AMIs na seção de início rápido são apoiadas pelo EBS

Também há uma boa explicação no doc oficial para saber a diferença entre o EBS e o repositório de instâncias

e essa imagem resume bastante

Se você executar várias instâncias e atribuir um serviço agendado da Instância da AWS como uma das suas prioridades em Evitar cobranças inesperadas , recomendo não usar o repositório de instâncias .

Conforme explicado na documentação dos volumes EBS e na resposta de j2d3 e Siddharth Sharma, o armazenamento de instância pode ser executado pelo tempo que você desejar, mas não pode ser parado . Significa que o serviço não pode ser agendado por uma Partida / Parada automática ou Recuperação de instância .

Além disso, para esse tipo de esquema também não há benefício em usar o EBS Backed no Elastic Beanstalk, pois ele foi projetado para garantir que todos os recursos necessários continuem em execução . Ele sempre fará um relançamento automático de todos os serviços que você parar. Analisando todo o restante , do total de cobranças no uso da VPC , EBS e ELB que foram adicionadas ao EC2-Classic , o EC2-VPC com ELB é a melhor escolha, ao contrário do EC2-Classic , uma instância interrompida mantém o Elastic associado Endereços IPe o volume EBS é armazenado automaticamente.

Como conclusão , tomando a parte principal da sua pergunta:

parece que o EBS é muito mais útil (parar, iniciar, persistir + melhor velocidade) com relativamente pouca diferença de custo ...?

A resposta é sim, mas se sua instância for baseada no EBS, ela poderá ser interrompida. Ele permanecerá na sua conta, você não será cobrado por isso . Você cobrará apenas o volume, mas o EBS será cobrado a cada hora . Você também pode considerar que, dentre todos os tipos disponíveis, você tem flexibilidade para redimensionar o volume EBS .

Além dos benefícios já listados por Eric , também deve estar ciente de que, em termos de custo, o S3 pode ou não ser mais barato que o EBS . Concordo que há uma diferença relativamente pequena no custo se você continuar executando os dois tipos de instância na mesma plataforma e arquitetura do aplicativo o tempo todo.

No entanto, se há um cenário para executar o aplicativo em um serviço de custo mais baixo, puxar toda tarefa não processada e papel-los ao VPC / EBS através de um gasoduto ou lambda dentro de um digamos regime de tempo curto <1 hora por dia, o que impossível de se fazer quando você use uma loja de instâncias , então será uma história diferente.