ter ocorrências dedicadas evita completamente problemas de vizinhança barulhenta?

Question

Devido ao compartilhamento de hardware, as instâncias da AWS podem ser propensas a problemas de "vizinho barulhento", em que uma ou mais instâncias do vizinho afetam recursos da sua instância.

Este artigo sugere:

The most effective way to avoid noisy neighbors, however, is to pay extra for dedicated EC2 instances.

Suponho que o artigo acima se refere a instâncias dedicadas do EC2 isolamento de hardware.

Perguntas :

1. As instâncias AWS dedicadas impedem completamente os problemas de vizinho com ruído?
2. Se não for completamente impedir , quanto o problema do vizinho de ruído?

Answer 1

Pelo que entendi, está sugerindo que, se você tiver várias instâncias, é provável que todas estejam presentes no mesmo hardware subjacente e use todo esse hardware, evitando que outras instâncias (potencialmente ruidosas) rodando nesse hardware - ou pelo menos tornando muito menos provável que tal vontade.

Se esse entendimento estiver correto, suas perguntas podem ser respondidas da seguinte maneira:

1. Somente se você iniciar instâncias suficientes para que elas usem completamente um único servidor subjacente e nenhuma outra instância possa ser executada nele.

2. Quanto mais "slots" no hardware subjacente que você usa, menos provável é que a instância de outra pessoa possa (a) executá-lo e (b) se torne ruidosa.

Existem vários problemas com essa linha de raciocínio. Em primeiro lugar, não sabemos que todas as suas instâncias se agruparão automaticamente no mesmo hardware (isso pode ser verdade; simplesmente não sei se é). Em segundo lugar, mesmo que o façam, não sabemos quantas instâncias você precisa executar para fechar "seu" hardware subjacente nas instâncias de outras pessoas. Em terceiro lugar, mesmo se o fizéssemos, a Amazon não é estúpida, e não existe almoço grátis; Se você executar instâncias suficientes para monopolizar completamente um servidor de back-end, esperaria pagar o mesmo que simplesmente alugar um servidor de back-end.

Parece-me que o resultado é reconhecer que (a) servidores virtualizados são baratos principalmente porque se pode exagerá-los na base de que nem todo mundo usa todos os recursos de seus servidores o tempo todo, e (b) se você realmente Quer recursos dedicados a você, você deve alugar um servidor dedicado.

    

Answer 2

Does having dedicated AWS instances completely prevent noisy neighbor issues?

Suas próprias instâncias podem ser vizinhas barulhentas umas às outras. Além disso, enquanto você paga à Amazon para garantir que nenhuma instância de outra pessoa seja executada em seu host subjacente, não acredito que ela reserve um rack inteiro - para que você possa encontrar um problema em que outros hosts no mesmo rack estão usando mais largura de banda do que o rack disponível.

If it doesn't completely prevent, how much does it reduce the noise neighbor issue?

Eu não acredito que ninguém além da Amazon seja capaz de responder a essa pergunta.

    

Answer 3

Você acredita que está passando por isso ou está apenas tentando planejá-lo?

Há muitas declarações imprecisas que você pode encontrar nas postagens do blog sobre o EC2.

O alegado problema do "vizinho barulhento" é um tópico frequente e se afoga em imprecisões.

Certamente, instâncias dedicadas resolveriam esse problema - se fosse um problema - dando-lhe um novo problema, como foi notado - você seria seu próprio vizinho barulhento. Não faria sentido para a AWS não agrupar todas as suas instâncias dedicadas em mais servidores físicos do que o absolutamente necessário.

Mas, nenhum deles é o caso, porque é um problema imaginário causado por uma falta generalizada de compreensão sobre o que são ciclos de CPU "roubados" e o que eles significam no EC2.

A infraestrutura do EC2 possui várias configurações físicas diferentes. Mesmo dentro da mesma classe de instância, dependendo do tipo em que você está implantado e da sua própria carga, você verá mais ou menos ciclos roubados, por uma razão totalmente alheia a "vizinhos barulhentos".

A classe de instância "m1.small" freqüentemente mostra que 50% de sua CPU foi "roubada", porque eles provisionaram você em uma CPU física duas vezes mais rápido do que o que eles estão cobrando por você. A classe de instância "t1.micro" reduz a utilização de 10% bastante previsivelmente após cerca de 15 segundos de 100% de utilização da CPU, e não abre as coisas de volta por dois ou três minutos - e é muito previsível e repetitivo, não aleatório - e, sim, esse afogamento é feito por ciclos de "roubo".

Eric Hammond esclarece isso muito bem:

Depending on the EC2 instance type and the underlying hardware, you may not be paying for access to all of the underlying CPU cycles. Amazon is not going to give you access to 100% of a modern, fast CPU if you have asked for an m1.small which is promised to be equivalent to an old, slow CPU.

On EC2, steal doesn't depend on the activity of other virtual machine neighbors. It is simply a matter of EC2 making sure you are not getting more CPU cycles than you are paying for.

^{— High CPU% stolen on EC2 instance at extremely regular intervals (serverfault.com)}

Certamente, subscrevi máquinas virtuais a recursos de CPU em hosts físicos que executam várias VMs em meu próprio datacenter, e provavelmente há alguns provedores de hospedagem virtuais que fazem isso. Por isso, não estou dizendo que não seja possível em nenhum lugar não acontece em nenhum ambiente virtual ... Eu só estou dizendo que se você acha que está tendo esse problema no EC2 ... procure um problema diferente.

O objetivo principal da locação dedicada no EC2 parece ser "para que você possa dizer que não está executando em hardware compartilhado" para fins de regulamentação ou conformidade.