ti-enxame.com

Benefícios do EBS vs. armazenamento de instância (e vice-versa)

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

371
HelloWorldy

A linha inferior é que você quase sempre deve usar instâncias de suporte do EBS.

Aqui está o porquê

  • Instâncias suportadas pelo EBS podem ser configuradas para que não possam ser encerradas (acidentalmente) pela API.
  • Instâncias apoiadas pelo EBS podem ser interrompidas quando você não as estiver usando e retomadas quando você precisar delas novamente (como pausar um Virtual PC), pelo menos com meus padrões de uso economizando muito mais dinheiro do que gasto com algumas dúzias de GB de armazenamento EBS.
  • As instâncias com suporte do EBS não perdem o armazenamento de instâncias quando ocorrem falhas (não são um requisito para todos os usuários, mas tornam a recuperação muito mais rápida)
  • Você pode redimensionar dinamicamente o armazenamento de instâncias do EBS.
  • Você pode transferir o armazenamento de instâncias do EBS para uma nova instância (útil se o hardware na Amazon em que você estava executando fica escamoso ou morre, o que acontece de vez em quando)
  • É mais rápido iniciar uma instância com suporte do EBS porque a imagem não precisa ser buscada no S3.
  • Se o hardware da sua instância com backup do EBS for programado para manutenção , a interrupção e o início da instância migrarão automaticamente para o novo hardware. Também consegui mover uma instância com suporte do EBS em hardware com falha parando a instância e iniciando-a novamente (sua milhagem pode variar em hardware com falha).

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

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

Tenha em mente que qualquer infra-estrutura baseada em nuvem pode falhar a qualquer momento. Planeje sua infraestrutura de acordo. Embora as instâncias com suporte do EBS ofereçam certo nível de durabilidade em comparação com instâncias de armazenamento efêmeras, elas podem falhar. Ter uma AMI na qual você possa 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, executar várias instâncias de servidores para balanceamento de carga e redundância (idealmente em várias zonas de disponibilidade ).

Quando não para

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

287
Eric J.

99% da nossa configuração da AWS é reciclável. Então, para mim, não importa se termino uma instância - nada está perdido nunca. 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âncias que vejo é economia de custos. Caso contrário, as instâncias com suporte do EBS ganham. Eric mencionou todas as vantagens.


[2012-07-16] Eu diria esta resposta muito diferente hoje.

Eu não tive nenhuma boa experiência com instâncias apoiadas pelo EBS no ano passado. Os últimos downtimes na AWS praticamente destruíram o EBS também.

Eu estou supondo que um serviço como RDS usa algum tipo de EBS bem e que parece funcionar na maior parte. Nas instâncias que administramos, nos livramos do EBS, quando possível.

Livrar-se de uma extensão onde nós mudamos um cluster de banco de dados de volta para ferro (= hardware real). A única peça remanescente em nossa infraestrutura é um servidor de banco de dados no qual distribuímos vários volumes do EBS em um software RAID e backup duas vezes por dia. O que quer que seja perdido entre backups, podemos viver com.

O EBS é uma tecnologia um tanto flakey, já que é essencialmente um volume de rede: um volume conectado ao seu servidor a partir do controle remoto. Eu não estou negando o trabalho feito com ele - é um produto incrível, já que o armazenamento persistente essencialmente ilimitado é apenas uma chamada da API. Mas dificilmente é adequado para cenários em que o desempenho de I/O é fundamental.

E, além de como o armazenamento em rede se comporta, toda a rede é compartilhada em instâncias do EC2. Quanto menor a 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 sobre ela.

A instância maior que você obtém, o melhor fica 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. O S3 é um serviço muito estável. Em seguida, automatize a configuração da sua instância até um ponto em que você possa inicializar um novo servidor e pronto. Então não há necessidade de ter armazenamento de rede que viva mais que a instância.

Portanto, apesar de tudo, não vejo benefícios para as instâncias apoiadas pelo EBS. Eu prefiro acrescentar um minuto ao bootstrap, então corro com um potencial SPOF.

67
Till

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

40
sehugg

Eric praticamente acertou em cheio. Nós ( Bitnami ) somos um fornecedor popular de AMIs livres para aplicações populares e estruturas de desenvolvimento (PHP, Joomla, Drupal, você tem a idéia). Posso dizer-lhe que as AMIs apoiadas pelo EBS são significativamente mais populares que as suportadas pelo S3. Em geral, creio que as instâncias de backup s3 são usadas para tarefas distribuídas e limitadas no tempo (por exemplo, processamento em larga escala de dados) em que, se uma máquina falhar, outra é simplesmente transferida. O AMIS apoiado pelo EBS tende a ser usado para tarefas de servidor 'tradicionais', 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 é possível obter instantâneos de uma instância apoiada pelo EBS durante a execução, permitindo efetivamente que você tenha backups muito econômicos da sua infraestrutura (os instantâneos são baseados em blocos e incrementais)

16
Daniel Lopez

O EC2 "Hardware"

Quando uma instância do EC2 é iniciada, uma máquina virtual é reservada para a instância ser executada. Essa máquina virtual tem especificações específicas dependendo do tipo de instância: CPU de 32 ou 64 bits, número de núcleos virtuais, tamanho do disco rígido, etc. Detalhes sobre as especificações da instância estão disponíveis em http: // aws .Amazon.com/ec2/# instance .

Quando sua instância do EC2 está em um estado "em execução", isso significa que ela está sendo executada na máquina virtual e é por isso que você é cobrado.

O disco rígido da máquina virtual é considerado "efêmero". O termo "efêmero" vem da palavra grega "ephemeros", que significa "durar apenas um dia". Qualquer coisa em um disco rígido deve ser considerado temporário. A menos que os dados sejam copiados do disco rígido, se a máquina virtual for interrompida, os dados serão perdidos. Isso inclui dados, software e até mesmo um sistema operacional que reside nesses discos rígidos.

O Amazon Web Services fornece instâncias do EC2 com dois tipos de dispositivos raiz: "EBS-backed" e "instance store".

Instâncias de "Instance Store"

Uma instância de "armazenamento de instância" é uma instância do EC2 cujo dispositivo raiz reside no disco rígido da máquina virtual. Quando a instância é criada, a AMI base é copiada para o disco rígido da máquina virtual e iniciada. A instância pode ser executada por quanto tempo quiser, mas não pode ser interrompida. Como o dispositivo raiz da instância é o disco rígido real, ele está "preso" no hardware e a única coisa que você pode fazer é encerrar a instância. Se você fizer isso, a instância será excluída, nunca será recuperada. Você também corre o risco de que, se o hardware da máquina virtual falhar, você também perderá qualquer coisa no disco rígido.

Se você ativar uma instância de "armazenamento de instâncias", prepare-se para deixá-la funcionando até que você esteja completamente acabado. Observe que você será cobrado a partir do momento em que a instância é iniciada, até o momento em que ela é encerrada.

Instâncias "EBS-Backed"

Uma instância "respaldada pelo EBS" é uma instância do EC2 que usa um volume do EBS como dispositivo raiz. Os volumes do EBS são unidades "virtuais" redundantes, que não estão vinculadas a nenhum hardware específico, mas estão restritas a uma zona de disponibilidade do EC2 específica. Isso significa que um volume do EBS pode passar de uma peça de hardware para outra na mesma zona de disponibilidade. Você pode pensar nos volumes do EBS como uma espécie de armazenamento anexado à rede.

Se o hardware da máquina virtual falhar, o volume do EBS pode simplesmente ser movido para outra máquina virtual e relançado. Em teoria, você não perderá dados.

Outro benefício é que os volumes do EBS podem ser facilmente copiados e copiados. Assim, você pode capturar facilmente os instantâneos de backup de seus volumes, criar novos volumes e lançar novas instâncias do EC2 com base nesses volumes duplicados.

Provavelmente, a maior vantagem das instâncias "apoiadas pelo EBS" sobre as instâncias de "armazenamento de instâncias" é que elas podem ser interrompidas. Quando você faz isso, a máquina virtual é desligada e o volume do EBS é armazenado para recuperação posterior. O hardware está disponível para outra pessoa usar. Além disso, durante esse período, você não recebe a cobrança da instância do EC2. Mas você é cobrado pelo armazenamento do EBS. Quando você deseja que a instância seja executada novamente, basta iniciá-la novamente. Uma nova máquina virtual é reservada, seu volume do EBS é anexado e sua instância é inicializada.

Mas e os discos rígidos da máquina virtual?

Sim, é possível usar esses discos rígidos, mesmo quando sua instância do EC2 é "apoiada pelo EBS". Por padrão, eles não estão disponíveis. Se você usar os programas de linha de comando para ativar sua instância, poderá usar a opção "-b" no comando ec2-run-instances para anexar as unidades "instance store" à sua instância do EC2.

Ter essas unidades disponíveis pode ser benéfico se você quiser armazenar dados temporários. O acesso de leitura e gravação deve ser mais rápido do que ler e gravar em um volume do EBS, porque você não está enviando dados pela rede. Além disso, você não será cobrado pela transferência de dados ou pelo armazenamento de dados. Mas isso só funciona se os dados puderem ser perdidos a qualquer momento.

Fonte: http://help.skeddly.com/Amazon-web-services/ebs-backed-versus-instance-store

16
Siddharth Sharma

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 suas AMIs para instâncias apoiadas pelo EBS - e possivelmente como máquinas de 32 bits (mais baratas - mas não posso usar a mesma AMI em 32 e 64 máquinas).

As instâncias apoiadas pelo EBS são lançadas com rapidez suficiente para que você possa começar a usar o Amazon AutoScaling API 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 desligá-los quando não forem mais necessários.

Esse tipo de escalonamento automático dinâmico é o que a AWS significa - onde a economia real na infraestrutura de TI pode entrar em ação. É praticamente impossível fazer escalonamento automático com as antigas instâncias de "InstanceStore" do s3.

15
j2d3

Eu estou apenas começando a usar o EC2, então não é um especialista, mas a própria documentação da Amazon diz:

recomendamos que você use o armazenamento de instâncias locais para dados temporários e, para dados que exigem um nível mais alto de durabilidade , recomendamos o uso de volumes do Amazon EBS ou o backup os dados para o Amazon S3.

Ênfase minha.

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

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

12
isomorphismes

O EBS é como o disco virtual de uma VM:

  • Duráveis, instâncias respaldadas pelo EBS podem ser iniciadas e paradas livremente (economizando dinheiro)
  • Pode ser instantâneo a qualquer momento, para obter backups pontuais.
  • AMIs podem ser criadas a partir de snapshots do EBS, portanto o volume do EBS se torna um modelo para novos sistemas

O armazenamento de instâncias é:

  • Local, geralmente mais rápido
  • Não conectada em rede, em casos normais, a E/S do EBS tem o custo da largura de banda da rede (exceto para instâncias otimizadas para EBS, que têm largura de banda EBS separada)
  • Tem E/S limitada por segundo IOPS. Mesmo provisionado I/O maximiza a 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 sistema operacional de backup e armazenamento permanente (dados do banco de dados, logs críticos, configuração do aplicativo)
  • Use o armazenamento de instâncias para dados em processo, logs não-críticos e estado de aplicativo transitório. Exemplo: armazenamento de classificação externa, tempfiles, etc.
  • O armazenamento de instâncias também pode ser usado para dados críticos de desempenho, quando há replicação entre instâncias (bancos de dados NoSQL, sistemas de fila/mensagem distribuídos e bancos de dados com replicação)
  • Use o 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é-prontos e lançáveis
7
BobMcGee

A maioria das pessoas opta por usar a instância de backup do EBS, pois é stateful. É mais seguro porque tudo o que você tem em execução e instalado dentro dele sobreviverá ao parar/parar ou a qualquer falha de instância.

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

3
mezi

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

A partir de agora todos os AMI na seção de início rápido são apoiados pelo EBS

enter image description here

Também há uma boa explicação em documento oficial para a diferença entre EBS e Instância armazenar

& esta imagem resume muito bem enter image description here

1
Aishwat Singh

Se você executar várias instâncias e atribuir um serviço planejado da instância do AWS como uma das prioridades em Evitando cobranças inesperadas , eu recomendaria não usar a instância -loja.

Como explicado na documentação de EBS Volumes e a resposta de j2d3 e Siddharth Sharma o repositório de instâncias pode ser executado por quanto tempo quiser, mas não pode ser parado . Significa que o serviço não pode ser agendado por um Automatic Start/Stop ou Instance Recovery .

Além disso, para este tipo de esquema, também não há benefício em usar EBS Backed em Elastic Beanstalk como foi projetado para garantir que todos os recursos necessários sejam continue executando . Ele sempre fará um relançamento automático de todos os serviços que você parar. enter image description here Revendo todo o resto , do total de encargos usando o VPC , EBS e ELB que adicionado a EC2-Classic , o EC2-VPC com ELB é principalmente a melhor escolha onde ao contrário de EC2-Classic, uma instância parada retém seu associado Elastic IP addresses e o volume do EBS é armazenado automaticamente.

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

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

A resposta é yes mas se sua instância for baseada em EBS, ela pode ser interrompida. Ele permanecerá na sua conta, , você não será cobrado por ele . Você será cobrado apenas o volume, mas EBS é cobrado por hora . Você também pode considerar que entre todos tipos disponíveis você tem flexibilidade para Redimensionar o Volume do EBS .

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

No entanto, se houver um cenário para executar o aplicativo em um serviço de custo mais baixo, puxe todas as tarefas não manipuladas e role them para o VPC/EBS via a pipeline ou lambda dentro de um curto espaço de tempo diga <1 hora por dia, que impossível fazer quando você usa uma loja de instâncias , então será uma história diferente.

0
Chetabahana