Não há dúvida de que a Amazon é líder quando se trata de uma variedade de serviços em nuvem oferecidos por meio de seu serviço da web EC2 (Elastic Compute Cloud). Com um processo de provisionamento relativamente simples e a capacidade de escalar facilmente as instâncias e as necessidades de armazenamento para cima ou para baixo, o EC2 visa oferecer todas as promessas da nuvem a preços econômicos. Para alguns, porém, a nuvem não se trata apenas de flexibilidade e facilidade de implantação; é sobre desempenho. Os benefícios de negócios de poder aumentar ou diminuir ambientes poderosos para aplicativos críticos, como análises, muitas vezes superam amplamente as despesas de fazê-lo por meio de OPEX, em vez do investimento de longo prazo do CAPEX. Para esse fim, em maio, o Amazon GA lançou a família de instâncias bare metal i3 que fornece acesso direto aos recursos de CPU e memória do servidor subjacente.
Não há dúvida de que a Amazon é líder quando se trata de uma variedade de serviços em nuvem oferecidos por meio de seu serviço da web EC2 (Elastic Compute Cloud). Com um processo de provisionamento relativamente simples e a capacidade de escalar facilmente as instâncias e as necessidades de armazenamento para cima ou para baixo, o EC2 visa oferecer todas as promessas da nuvem a preços econômicos. Para alguns, porém, a nuvem não se trata apenas de flexibilidade e facilidade de implantação; é sobre desempenho. Os benefícios de negócios de poder aumentar ou diminuir ambientes poderosos para aplicativos críticos, como análise, muitas vezes superam amplamente as despesas de fazê-lo por meio de OPEX, em vez do investimento de longo prazo do CAPEX. Para esse fim, em maio, o Amazon GA lançou a família de instâncias bare metal i3 que fornece acesso direto aos recursos de CPU e memória do servidor subjacente.
As instâncias i3.metal são construídas no sistema Nitro, que é uma coleção de componentes de proteção de servidores e descarregamento de hardware desenvolvidos pela AWS que “fornecem com segurança recursos de rede e armazenamento de alto desempenho para instâncias do EC2”. As instâncias i3.metal também aproveitam todos os outros serviços que a Nuvem AWS oferece, como o Elastic Block Store (EBS), que aproveitamos como parte desta análise. As instâncias também apresentam até 15.2 TB de armazenamento de instâncias com SSD NVMe, bem como processadores Intel Xeon de 2.3 GHz que oferecem 36 núcleos hiperencadeados (72 processadores lógicos) e 512 GiB de memória. No lado da malha, as instâncias i3.metal oferecem até 25 Gbps de largura de banda de rede agregada, gerando alta taxa de transferência de rede e menor latência por meio da rede aprimorada baseada no Elastic Network Adapter (ENA).
No EC2, há vários tipos de instância. As instâncias i3 se enquadram na categoria “Storage Optimized”, com as instâncias i3.metal assumindo o manto como as de melhor desempenho desse grupo. A tabela abaixo destaca a família e a configuração dos tipos de instância.
| Modelo | vCPU | Memória (GiB) | Desempenho de rede | Armazenamento (TB) |
| i3.grande | 2 | 15.25 | Até 10 Gigabits | 1 x 0.475 NVMe SSD |
| i3.xgrande | 4 | 30.5 | Até 10 Gigabits | 1 x 0.95 NVMe SSD |
| i3.2xgrande | 8 | 61 | Até 10 Gigabits | 1 x 1.9 NVMe SSD |
| i3.4xgrande | 16 | 122 | Até 10 Gigabits | 2 x 1.9 NVMe SSD |
| i3.8xgrande | 32 | 244 | 10 Gigabit | 4 x 1.9 NVMe SSD |
| i3.16xgrande | 64 | 488 | 25 Gigabit | 8 x 1.9 NVMe SSD |
| i3.metal | 72 | 512 | 25 Gigabit | 8 x 1.9 NVMe SSD |
As instâncias i3.metal estão disponíveis nas regiões AWS Leste dos EUA (N. Virgínia), Leste dos EUA (Ohio), Oeste dos EUA (Oregon), Europa (Frankfurt) e Europa (Irlanda) e podem ser adquiridas como instâncias sob demanda, Instâncias reservadas (3 anos, 1 ano e conversíveis) ou como instâncias spot. Para os fins desta revisão, testamos na região da Virgínia do Norte. Testamos com armazenamento NVMe e volumes de blocos EBS.
Desempenho
Análise de Carga de Trabalho do VDBench
Para avaliar o desempenho da instância EC2 i3.metal, aproveitamos o VDBench instalado localmente para testar o armazenamento EBS (30x1TB) e NVMe (8×1.7TB). Com ambos os tipos de armazenamento, alocamos 12% de cada dispositivo e os agrupamos de forma agregada para observar o desempenho máximo do sistema com uma quantidade moderada de localidade de dados.
Essas cargas de trabalho oferecem uma variedade de perfis de teste diferentes, desde testes de "quatro cantos", testes de tamanho de transferência de banco de dados comuns, bem como capturas de rastreamento de diferentes ambientes VDI. Todos esses testes utilizam o gerador de carga de trabalho vdBench comum, com um mecanismo de script para automatizar e capturar resultados em um grande cluster de teste de computação. Isso nos permite repetir as mesmas cargas de trabalho em uma ampla variedade de dispositivos de armazenamento, incluindo arrays flash e dispositivos de armazenamento individuais.
perfis:
- 4K Random Read: 100% Read, 128 threads, 0-120% iorate
- 4K Random Write: 100% Write, 64 threads, 0-120% iorate
- Leitura sequencial de 64K: 100% de leitura, 16 threads, 0-120% iorado
- Gravação sequencial de 64K: 100% gravação, 8 threads, 0-120% iorado
- Banco de Dados Sintético: SQL e Oracle
- Rastreamentos de clones vinculados a VDI
Analisamos o EBS e o NVMe nesta análise. Como há uma diferença dramática de desempenho, separamos os resultados em dois gráficos (a latência seria tão distante que os gráficos seriam muito difíceis de ler).
Nosso primeiro teste analisa a leitura aleatória de 4K. Aqui, a instância do EBS teve desempenho de latência abaixo de milissegundos até o final. Com cerca de 64K IOPS, a latência aumentou para 59.46ms com desempenho de 64,047 IOPS.
Olhando para a leitura aleatória de pico NVMe 4K, vemos que a instância tem um desempenho muito melhor. A instância atingiu o pico de 2,802,904 IOPS com uma latência de 348μs.
A gravação aleatória de 4K com EBS viu quase a mesma coisa que as leituras de 4K com EBS. A instância quebrou 1ms um pouco antes, cerca de 60K IOPS, e atingiu o pico de 64,003 IOPS com uma latência de 29.97ms.
Para a versão NVMe da instância, houve um pequeno aumento na latência, mas ainda abaixo de 1ms. A instância atingiu o pico de 920,975 IOPS com uma latência de 545μs.
Mudando para testes sequenciais, para o desempenho máximo de leitura do EBS 64K, a instância teve latência abaixo de milissegundos até cerca de 70K IOPS ou cerca de 450MB/s e atingiu o pico de 17,360 IOPS ou 1.08GB/s com uma latência de 27.65ms.
A leitura sequencial de 64K com o NVMe nos deu desempenho máximo de 244,037 IOPS ou 15.25 GB/s com uma latência de 514 μs.
Com gravação de 64K com EBS, a instância começou acima de 1 ms e atingiu o pico de 17,359 IOPS ou 1.08 GB/s com uma latência de 13.8 ms.
A gravação sequencial de 64K é a primeira vez que vemos a instância NVMe passar de 1ms. A instância atingiu o pico de 58,572 IOPS ou 3.66 GB/s com uma latência de 1.08 ms.
Mudando para nossas cargas de trabalho SQL, a instância do EBS teve desempenho de latência abaixo de milissegundos até cerca de 55 IOPS e atingiu o pico de 64,036 IOPS com uma latência de 14.93 ms.
Para a versão NVMe da instância, vimos o desempenho máximo de 834,231 IOPS com uma latência de 302 μs para o teste SQL.
Para o SQL 90-10 com EBS, a instância quebrou novamente a latência de 1ms em torno de 55K IOPS e atingiu o pico de 64,036 IOPS com 14.99ms de latência.
A versão NVMe da instância no SQL 90-10 teve um desempenho máximo de 605,150 IOPS e uma latência de 415μs.
O SQL 80-20 com EBS novamente deu quase os mesmos números com a latência abaixo de milissegundos terminando em torno de 55K IOPS e um pico de 64,036 IOPS com latência de 14.93 ms.
O SQL 80-20 com NVMe teve números de ocorrência de instância de 511,840 IOPS e uma latência de 493μs.
Os testes Oracle para EBS mostraram o mesmo desempenho de pico ímpar de quase os mesmos números. Para Oracle, a instância atingiu 64,036 IOPS com latência de 13.6ms. A instância teve desempenho de latência abaixo de milissegundos até cerca de 55 IOPS.
Com NVMe, a instância atingiu 457,372 IOPS com latência de 613μs no teste Oracle.
O Oracle 90-10 teve o pico da instância EBS em 64,035 IOPS com uma latência de 10.3ms. A instância quebrou 1ms em cerca de 55K IOPS.
A versão NVMe da instância no Oracle 90-10 foi capaz de atingir 520,448 IOPS com uma latência de 333μs.
O Oracle 80-20 teve o EBS interrompido em 1ms em torno de 55K IOPS e atingiu o pico de 64,036 IOPS com uma latência de 10.3ms.
A instância com NVMe teve desempenho máximo de 435,265 IOPS com latência de 400μs.
Em seguida, examinamos nossos testes VDI Linked Clone (LC). Começando com o Boot, a versão EBS da instância tinha latência abaixo de milissegundos até cerca de 35K IOPS e atingiu um pico de 42,893 IOPS com uma latência de 11.2 ms.
A versão NVMe da instância conseguiu atingir o pico de 349,799 IOPS e uma latência de 363 μs em nosso teste VDI LC Boot.
Para o login inicial do VDI LC, a instância do EBS ultrapassou a linha de 1ms por algum tempo antes de cair em torno de 31K IOPS. A instância atingiu o pico de 34,486 IOPS e 6.95ms de latência.
Com o VDI LC Initial Login, a instância NVMe atingiu o pico de 93,405 IOPS com uma latência de 677 μs.
Com o VDI LC Monday Login, mais uma vez a instância do EBS flertou com 1ms por algum tempo antes de mergulhar em torno de 25K IOPS e chegar ao pico de 34,643 IOPS com uma latência de 13.85ms.
E, finalmente, nosso VDI LC Monday Login with NVMe teve o pico de instância em 119,615 IOPS com uma latência de 1.1 ms.
Conclusão
Os serviços de nuvem da Amazon são normalmente considerados os mais versáteis do mercado. Embora a computação e o armazenamento certamente sejam variados, a Amazon também tem opções de desempenho. A Amazon oferece uma infinidade de opções de desempenho em seu serviço da web EC2, incluindo sua instância bare metal i3. Essas instâncias aproveitam o sistema AWS Nitro de hardware e software de uso específico. As instâncias i3.metal oferecem melhor desempenho por meio do acesso direto às CPUs e à memória, ao mesmo tempo em que oferecem aos usuários a capacidade de aproveitar outros recursos, como armazenamento anexado AWS EBS e armazenamento NVMe local.
Para desempenho, testamos armazenamento em bloco (EBS) e NVMe. A intenção é dar aos leitores uma ideia do que esperar em termos de opções, e menos de um sendo melhor que o outro (normalmente o armazenamento NVMe tem melhor desempenho e latência muito menor, e é por isso que existem dois conjuntos de gráficos). Olhando para o EBS, vimos um padrão em que a instância foi acima de 1 ms e, pouco depois, aumentou a latência e terminou. Ao longo de nossos testes, o EBS atingiu o pico em torno de 64K IOPS, que é o máximo permitido para o EBS. Isso incluiu os testes 4K e todos os três testes SQL e Oracle. A instância ficou um pouco mais lenta para nossos testes de VDI. A Amazon indica que é possível ajustar as configurações para atingir mais do que os 64K IOPS prescritos, mas os processos para chegar lá não são os que a maioria dos clientes experimentaria, então não seguimos esse caminho.
Para nossos testes NVMe, vimos resultados mais alinhados com nossos benchmarks normais. Os destaques aqui incluíram um desempenho aleatório de leitura de 4K de 2.8 milhões de IOPS, gravação de 4K de 920K IOPS, leitura de 64K de 15.25GB/s e desempenhos SQL acima de 500K IOPS em todos os três testes (com o teste SQL sendo em torno de 834K IOPS). Os testes da Oracle também tiveram uma boa exibição com o NVMe, com resultados entre 435K IOPS e 520K IOPS. Nosso VDI Linked Clone mostrou um forte desempenho de inicialização com aproximadamente 350K IOPS. A única decepção aqui é que os clientes não podem optar por mais NVMe local nas instâncias i3.metal.
No geral, a instância i3.metal nos deu exatamente o que a Amazon prometeu. Isso é reconfortante para os clientes que desejam saber que receberão o nível de serviço prometido. Obviamente, isso não é isento de custos, pois, como em qualquer implantação de nuvem, a preocupação será com a facilidade de uso e os resultados na nuvem em comparação com outros provedores de nuvem em comparação com o local. Dito isso, os clientes que têm cargas de trabalho que podem se contentar com um nível de IOPS mais baixo podem economizar bastante dinheiro. No entanto, tudo se resume a quais são os requisitos finais para a instância específica. Para esse fim, as instâncias do i3.metal são ótimas para aplicativos convencionais que não vão ou não são capazes de exceder os limites de desempenho que o i3.metal oferece e não precisam do IOPS que um array totalmente flash no local forneceria para instância. Além disso, se você já faz parte da família Amazon, a mudança para bare metal é familiar e provavelmente há um benefício de custo ao consumir vários programas da AWS em massa.
Inscreva-se no boletim informativo StorageReview
