Revisão das Instâncias Bare Metal do Oracle Cloud Infrastructure

O Oracle Cloud Infrastructure inclui uma ampla variedade de ofertas de serviços, incluindo computação, armazenamento, rede, banco de dados e balanceamento de carga – na verdade, toda a infraestrutura necessária para construir um data center baseado em nuvem. No contexto desta revisão, estamos interessados na categoria Oracle Cloud Infrastructure Compute, com foco muito específico em suas instâncias bare metal. Como a maioria dos provedores de nuvem, a Oracle oferece instâncias de computação virtualizadas, mas, ao contrário da maioria das outras ofertas virtuais, a Oracle pode apoiá-las com formas que contêm até ~25 TB de armazenamento NVMe para aplicativos que precisam de baixa latência. Por melhores que sejam, a Oracle elevou ainda mais a aposta no desempenho da computação em nuvem, oferecendo as primeiras instâncias bare metal de alto desempenho do setor, ideais para aplicativos de missão crítica em que a latência é fundamental. As instâncias vêm com até 52 OCPUs, 768 GB de RAM, NICs duplas de 25 GbE e até 51 TB de armazenamento NVMe conectado localmente. Para aqueles que desejam mais, até 512 TB de armazenamento em bloco NVMe conectado à rede estão disponíveis, bem como opções de GPU. Todas as diferentes ofertas de computação da Oracle são executadas em uma rede definida por software altamente otimizada, ajustada para minimizar a contenção e maximizar o desempenho.

O Oracle Cloud Infrastructure inclui uma ampla variedade de ofertas de serviços, incluindo computação, armazenamento, rede, banco de dados e balanceamento de carga – na verdade, toda a infraestrutura necessária para construir um data center baseado em nuvem. No contexto desta revisão, estamos interessados na categoria Oracle Cloud Infrastructure Compute, com foco muito específico em suas instâncias bare metal. Como a maioria dos provedores de nuvem, a Oracle oferece instâncias de computação virtualizadas, mas, ao contrário da maioria das outras ofertas virtuais, a Oracle pode apoiá-las com formas que contêm até ~25 TB de armazenamento NVMe para aplicativos que precisam de baixa latência. Por melhores que sejam, a Oracle aumentou ainda mais a aposta no desempenho da computação em nuvem, oferecendo as primeiras instâncias bare-metal de alto desempenho do setor, ideais para aplicativos de missão crítica em que a latência é fundamental. As instâncias vêm com até 52 OCPUs, 768 GB de RAM, NICs duplas de 25 GbE e até 51 TB de armazenamento NVMe conectado localmente. Para aqueles que desejam mais, até 512 TB de armazenamento em bloco NVMe conectado à rede estão disponíveis, bem como opções de GPU. Todas as diferentes ofertas de computação da Oracle são executadas em uma rede definida por software altamente otimizada ajustada para minimizar a contenção e maximizar o desempenho.

Há uma grande variedade de ofertas de nuvem neste momento e até mesmo várias grandes ofertas de nuvem com AWS, Google Cloud Platform e Microsoft Azure no topo dessa lista. Embora esses provedores de serviços em nuvem ofereçam muitos produtos e serviços excelentes, uma coisa que eles normalmente não têm é desempenho. Ao comparar a nuvem com o local, o local sempre supera a nuvem. A Oracle está procurando mudar essa visão com suas ofertas de infraestrutura em nuvem.

As ofertas de computação da Oracle vêm com promessas que se espera de armazenamento ou servidores locais, incluindo desempenho, disponibilidade, versatilidade e governança. O lado do desempenho suporta desempenho máximo e consistente para aplicativos de missão crítica e é apoiado pelo anunciou recentemente SLA de infraestrutura de nuvem de ponta a ponta, que até o momento é o único semelhante na indústria. A oferta oferece suporte à disponibilidade em várias camadas, incluindo DNS, balanceamento de carga, replicação, backup, instantâneos de armazenamento e clustering. As ofertas de computação variam de uma VM de núcleo único a bare metal de locatário único de 52 núcleos, oferecendo a versatilidade para executar tudo, desde cargas de trabalho comuns até clusters HPC. E com as instâncias bare metal da Oracle, os clientes obtêm o isolamento e o controle de um servidor local, pois não contêm outros locatários e nenhum software do provedor Oracle.

As ofertas de computação do Oracle Cloud vêm em várias “formas”, incluindo instâncias bare metal, instâncias bare metal GPU e instâncias VM. Para esta revisão, veremos instâncias bare metal que, de acordo com a Oracle, podem fornecer até 5.1 milhões de IOPS e são para casos de uso como aplicativos de banco de dados de missão crítica, cargas de trabalho de HPC e aplicativos da Web intensivos em E/S. Para comparação, também mostraremos as formas de VM do Oracle, com armazenamento NVMe local (DenseIO) e com armazenamento de bloco de rede (Standard).

Gestão de Sistemas

A GUI de gerenciamento do Oracle Cloud Infrastructure é bastante simples de entender. A página principal tem orientações e assistência, se necessário. Na parte superior estão a locação ou conta, a região que está sendo usada (us-ashburn-1, no nosso caso), juntamente com as guias Home (que é a página principal), Identity, Compute, Database, Networking, Storage, Audit e E-mail. Para nossos testes, DenseIO2 e Standard2 são mostrados.

Como esta revisão se concentra no lado da computação, olhando nessa guia, podemos ver as instâncias que usaremos para nossos testes de desempenho. Cada instância tem seu nome, forma, região, domínio de disponibilidade e quando foi criada. No lado esquerdo, os usuários podem alterar a listagem selecionando o estado, por exemplo, “em execução”.

Clicar nas reticências no lado direito permite detalhar um pouco mais a instância. Observando o BM.DenseIO2.52, pode-se ver facilmente se a instância está em execução e obter informações mais detalhadas sobre ela. As tags também podem ser associadas a ele aqui. Na parte superior da informação está a capacidade de criar uma imagem personalizada, iniciar, parar ou reiniciar a instância, encerrá-la ou aplicar tags. Rolar para baixo também permite anexar volumes de blocos.

Na guia Rede, pode-se ver a Virtual Cloud Network sendo usada ou criar uma. Para a VCN, há informações como região, tabela de rotas padrão, domínio DNS e quando ela foi criada. Novamente, as reticências à direita permitem detalhar, aplicar tags e criar uma sub-rede.

Na guia Armazenamento, os usuários podem ver os volumes de blocos em seu compartimento e criar mais. Os volumes de blocos são listados por data de criação e os usuários podem detalhar para obter mais informações, criar backups manuais, desanexar o volume de blocos da instância, excluir o volume ou aplicar tags.

E como o Audit sugere, pode-se olhar rapidamente para os eventos passados selecionando a data e o intervalo de tempo. Isso permite que as empresas atendam às necessidades de conformidade de gerenciamento, onde o usuário e a ação para cada evento ou alteração no ambiente são capturados.

Desempenho

Análise de Carga de Trabalho do VDBench

Para avaliar o desempenho dessas instâncias do Oracle Cloud, aproveitamos o vdbench instalado localmente em cada plataforma. Nossos testes foram espalhados por todo o armazenamento local ao mesmo tempo, portanto, se os armazenamentos BV (Block Volume) e NVMe estivessem presentes, testamos um grupo de cada vez. 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
Clone completo de VDI e rastreamentos de clone vinculados

Analisamos dispositivos de bloco remoto (BV) e NVMe. Como há uma diferença de desempenho tão dramática, separamos os resultados em dois gráficos (a latência seria tão distante que os gráficos seriam muito difíceis de ler). Para esta revisão, examinamos as configurações de Bare Metal (BM) e VM com execuções de E/S padrão e densas em BV e apenas execuções de E/S densas para NVMe.

Olhando para o pico de leitura de 4K para BV, todas as quatro execuções começaram com forte latência abaixo de milissegundos. O primeiro a sair foi o VM.Standard, chegando a pouco menos de 53 IOPS e atingindo o pico de 60,591 IOPS com uma latência de 15ms. O próximo a quebrar a latência abaixo de milissegundos foi o VM.DenseIO, ultrapassando 1 ms aproximadamente no mesmo ponto que o padrão, mas com pico de 72,626 IOPS com uma latência de 7.5 ms. Ambas as execuções bare metal tiveram um desempenho muito melhor com o desempenho de latência abaixo de milissegundos do DenseIO até cerca de 235 IOPS, atingindo um pico de 252,275 IOPS com uma latência de 4.1 ms. O BM.Standard atingiu cerca de 250 IOPS antes de passar de 1 ms e atingiu o pico de 258,329 IOPS com uma latência de 4.05 ms.

Olhando para o desempenho máximo de leitura de 4K para NVMe, ambas as execuções tiveram latência abaixo de milissegundos. O VM.DenseIO atingiu um pico de 569,534 IOPS com uma latência de 214μs. O BM.DenseIO atingiu o pico de 4,419,490 IOPS com uma latência de apenas 174.6 μs.

Mudando para o desempenho máximo de gravação aleatória de 4K para BV, vemos uma colocação semelhante à anterior, com picos de VMs muito antes dos BMs. O VM.Standard atingiu cerca de 63 IOPS antes de quebrar a latência abaixo de milissegundos e atingiu o pico de 77,229 IOPS com latência de 5.3 ms. O VM.DenseIO teve um desempenho um pouco melhor atingindo cerca de 69 IOPS antes de passar de 1 ms e atingiu o pico de 84,274 IOPS com uma latência de 3.9 ms. O BM.DenseIO conseguiu chegar ao norte de 263 IOPS antes de passar de 1ms em latência e atingiu o pico de 280,158 IOPS com uma latência de 2.02ms. E o BM.Standard foi a configuração de melhor desempenho, atingindo cerca de 278 IOPS antes de ultrapassar a latência abaixo de um milissegundo e atingir o pico de 280,844 IOPS com uma latência de 1.84 ms.

Com o NVMe na gravação de 4K, novamente o BM superou a VM com ambos tendo desempenho de latência abaixo de milissegundos. O VM.DenseIO atingiu um pico de 412,207 IOPS com uma latência de 141μs. O BM.DenseIO atingiu o pico de 3,232,215 IOPS com uma latência de 125μs.

Passando para o trabalho sequencial, primeiro examinamos a leitura de 64K para BV. Tanto o VM.Standard quanto o VM.DenseIO quebraram a latência de 1 ms em cerca de 15.5 K IOPS ou 968 MB/s. E ambos mantiveram mais ou menos o mesmo desempenho com a latência subindo para 8.2 ms. Mais uma vez, vimos algo semelhante com BM.Standard e BM.DenseIO, ambos quebrando 1ms a cerca de 37.5K IOPS ou 2.35GB/s. Ambas as configurações atingiram um pico ao norte de 47K IOPS ou 2.95 GB/s com latência de 8.4 ms.

A leitura sequencial de 64K do NVMe teve ambas as configurações mantidas abaixo da latência de submilissegundos. O VM.DenseIO atingiu o pico de 39,512 IOPS ou 2.5 GB/s com uma latência de 403 μs, enquanto o BM.DenseIO atingiu o pico de 323,879 IOPS ou 20.2 GB/s com uma latência de 361 μs.

Com gravações sequenciais de 64K para BV, vemos novamente um fenômeno semelhante com VM.Standard e VM.DenseIO, ambos quebrando a latência de 1ms com um desempenho de 12K IOPS ou 770MB/s. Ambos atingiram um pico de cerca de 15.1 K IOPS ou 943 MB/s com uma latência de 3.1 ms. Com o BM.Standard e o BM.DenseIO ambos quebraram a latência de 1ms em cerca de 42K IOPS ou 2.6GB/s com o BM.DenseIO chegando a 46,768 IOPS ou 2.92GB/s com latência de 2.6ms. O BM.Standard atingiu o pico de 46,787 IOPS ou 2.92 GB/s com uma latência de 3.4 ms.

Para gravações sequenciais de 64K para NVMe, tanto o VM.DenseIO quanto o BM.DenseIO tiveram desempenho de latência inferior a milissegundos novamente, mas ambos também sofreram um aumento na latência (juntamente com uma redução final no desempenho do BM.DenseIO). O VM.DenseIO atingiu um pico de 25K IOPS ou 1.56 GB/s com uma latência de 311 μs após um pico de até 754 μs. O BM.DenseIO teve desempenho de pico muito melhor (160,895 IOPS ou 10.1 GB/s a uma latência de 170 μs), mas caiu um pouco no final com um aumento na latência também, terminando em 132,192 IOPS ou 8.8 GB/s com uma latência de 310μs.

Em nossa carga de trabalho SQL para BV, o VM.Standard foi o primeiro a ultrapassar 1 ms com aproximadamente 50 IOPS, atingindo um pico de 73,259 IOPS com uma latência de 3.4 ms. O VM.DenseIO ultrapassou a latência de 1ms em cerca de 58K IOPS e atingiu o pico de 78,624 IOPS com uma latência de 3.1ms. Com os BMs, ambos ficaram abaixo de 1ms de latência até cerca de 275K (com o BM.DenseIO rodando um pouco mais). O BM.Standard atingiu o pico de 305,368 IOPS com 1.7 ms de latência, enquanto o BM.DenseIO atingiu o pico de 307,979 IOPS com 1.35 ms de latência.

SQL para NVMe novamente teve latência abaixo de milissegundos com o VM.DenseIO chegando a 188,786 IOPS com 167μs. O BM.DenseIO atingiu um pico de 1,684,869 IOPS com uma latência de 142μs.

No benchmark SQL 90-10 para BV, ambas as VMs quebraram o desempenho de latência abaixo de milissegundos em cerca de 58K IOPS. O VM.Standard atingiu o pico de 71,691 IOPS com uma latência de 3.5ms. O VM.DenseIO atingiu um pico de 79,033 IOPS com uma latência de 3.05 ms. O BM.Standard quebrou a latência de 1ms com um desempenho de aproximadamente 270K IOPS e atingiu o pico de 303,904 IOPS com uma latência de 1.7ms. O BM.DenseIO teve latência abaixo de milissegundos até cerca de 290K IOPS e atingiu o pico de 307,472 IOPS com uma latência de 1.34ms.

Para NVMe SQL 90-10, o VM.DenseIO atingiu o pico de 172,693 IOPS com uma latência de 182μs. O BM.DenseIO atingiu o pico de 1,328,437 IOPS com 165μs.

No benchmark SQL 80-20 para BV, o VM.Standard atingiu cerca de 54K IOPS antes de ultrapassar 1ms e atingiu o pico de 72,204 IOPS com uma latência de 3.4ms. O VM.DenseIO teve latência abaixo de milissegundos até cerca de 59K IOPS e atingiu o pico de 78,787 IOPS com uma latência de 2.99ms. O BM.Standard atingiu cerca de 280 IOPS com latência abaixo de 1 ms e atingiu o pico de 300,014 IOPS com uma latência de 1.6 ms. O BM.DenseIO quebrou a latência de 1ms em cerca de 285K IOPS e atingiu o pico de 299,730 IOPS com latência de 1.3ms antes de cair no desempenho.

No benchmark SQL 80-20 para NVMe, o VM.DenseIO atingiu o pico de 144,010 IOPS com uma latência de 218μs. O BM.DenseIO atingiu um pico de 1,114,056 IOPS com uma latência de 182μs antes de ter uma ligeira queda no desempenho.

Em nossa carga de trabalho Oracle com BV, o VM.Standard teve desempenho de latência abaixo de milissegundos até atingir cerca de 52 mil IOPS e atingir o pico de 70,096 IOPS com uma latência de 3.4 ms. O VM.DenseIO quebrou a latência de 1ms em aproximadamente 58K IOPS e atingiu o pico de 75,000 IOPS com uma latência de 3.1ms. O BM.Standard quebrou a latência de 1ms em torno de 255K com desempenho máximo de 280,599 IOPS com latência de 1.41ms. O BM.DenseIO teve latência abaixo de milissegundos até cerca de 260 IOPS e atingiu o pico de 267,632 IOPS com uma latência de 1.3 ms.

Nossa carga de trabalho Oracle com NVMe apresentou desempenho máximo para VM.DenseIO de 132,553 IOPS com latência de 257μs. Com o BM.DenseIO, o desempenho máximo foi de 1,043,104 IOPS e uma latência de 199μs.

No Oracle 90-10 para BV, o VM.Standard teve latência abaixo de milissegundos até pouco mais de 54K IOPS e atingiu o pico de 72,533 IOPS com uma latência de 2.2ms. O VM.DenseIO quebrou a latência de 1ms em aproximadamente 61K IOPS e atingiu o pico de 76,908 IOPS com uma latência de 1.86ms. Ambos os BMs chegaram a 297K IOPS antes de quebrar a latência de 1 ms. O BM.Standard atingiu o pico de 305,771 IOPS com uma latência de 1.17ms. O BM.DenseIO teve desempenho máximo de 297,509 IOPS com latência de 1.03 ms.

No Oracle 90-10 para NVMe, o VM.DenseIO teve um desempenho máximo de 133,330 IOPS e uma latência de 163μs. O BM.DenseIO teve desempenho máximo de 1,088,454 IOPS e latência de 142μs.

No Oracle 80-20 com BV, o VM.Standard atingiu cerca de 55K em menos de 1ms e atingiu o pico de 74,032 IOPS com uma latência de 2.14ms. O VM.DenseIO teve latência abaixo de milissegundos até cerca de 51K e atingiu o pico de 75,666 IOPS com uma latência de 2ms. Ambos os BMs chegaram até cerca de 295K IOPS antes de quebrar 1ms. O BM.Standard atingiu o pico de 306,955 IOPS com uma latência de 1.14ms. O BM.DenseIO atingiu um pico de cerca de 295K IOPS com uma latência de 893μs.

No Oracle 80-20 com NVMe, o VM.DenseIO atingiu o pico de 108,483 IOPS com uma latência de 195μs. O BM.DenseIO atingiu o pico de 956,326 IOPS com uma latência de 158μs.

Em seguida, examinamos o VDI Full Clone. Para a inicialização com BV, o VM.Standard quebrou 1 ms, pouco abaixo de 40 IOPS e atingiu o pico de 56,057 IOPS com uma latência de 4.2 ms. O VM.DenseIO conseguiu com latência abaixo de milissegundos até aproximadamente 43K IOPS e atingiu o pico de 61,570 IOPS com uma latência de 3.6 ms. Ambos os BMs tiveram latência abaixo de milissegundos até pouco acima do limite de 200 IOPS. Ambos atingiram um pico de cerca de 220 IOPS com uma latência de 2.1 antes de cair no desempenho.

Para inicialização Full Clone com NVMe, o VM.DenseIO atingiu um pico de cerca de 136K IOPS com uma latência de 235μs. O BM.DenseIO atingiu o pico de 1,032,322 IOPS com uma latência de 213μs.

Com o VDI Full Clone Initial Log In com BV, ambas as VMs atingiram cerca de 41K IOPS com latência abaixo de um milissegundo, com o VM.Standard atingindo um pico de 55,522 IOPS com uma latência de 3.7ms e o VMDenseIO atingindo um pico de 59,560 IOPS com latência de 3.6ms . Ambos os BMs quebraram a latência abaixo de milissegundos em torno de 203K IOPS (com o padrão indo antes do denso). O BM.Standard atingiu um pico de cerca de 225K IOPS com latência de 2.04ms e o BM.DenseIO atingiu um pico de 224,385 IOPS com uma latência de 1.8ms.

Para o login inicial de clone completo de VDI com NVMe, o VM.Standard atingiu o pico de 59,883 IOPS com uma latência de 506 μs. E o BM.DenseIO atingiu o pico de 467,761 IOPS com uma latência de 262μs.

VDI Full Clone Monday Login with BV tinha o VM.Standard com latência abaixo de milissegundos até quase 36K IOPS com um pico de 50,685 IOPS e uma latência de 2.3 ms. VM.DenseIO funcionou abaixo de 1ms até pouco mais de 38K IOPS e atingiu o pico de 53,304 IOPS com latência de 2.2ms. O BM.Standard quebrou a latência de 1ms em cerca de 205K IOPS e atingiu o pico de 224,764 IOPS com uma latência de 1.5ms. O BM.DenseIO ultrapassou 1ms em torno de 210K com um pico de pouco mais de 220K IOPS e uma latência de 1.2ms.

VDI Full Clone Monday Login with NVMe mostrou um desempenho máximo de VM.DenseIO de 44,384 IOPS com uma latência de 356μs. O BM.DenseIO atingiu um pico de 356,691 IOPS com uma latência de 252μs.

Nossa seleção final de testes analisa o VDI Linked Clone. Começando novamente com o teste de inicialização com BV, o VM.Standard teve latência abaixo de milissegundos até cerca de 29K IOPS, com pico de cerca de 38K IOPS com latência de 2.4ms. O VM.DenseIO chegou até cerca de 32K IOPS antes de quebrar 1ms e atingiu o pico em cerca de 38K IOPS também com latência de 2.16ms. Ambos os BMs chegaram a aproximadamente 100 IOPS antes de ultrapassar a latência de 1ms. Ambos tiveram um desempenho máximo de cerca de 114K IOPS com latência de 3ms.

Com o VDI Linked Clone Boot para NVMe, vimos o pico VM.DenseIO em 65,384 IOPS com uma latência de 238 μs. O BM.DenseIO atingiu um pico de 555,004 IOPS com uma latência de 217μs.

Com o Login inicial com BV, ambas as VMs quebraram a latência de 1ms em aproximadamente 28K IOPS, com o VM.Standard atingindo o pico de 36,682 IOPS com uma latência de 1.6ms e o VM.DenseIO atingindo o pico de 38,525 IOPS com uma latência de 1.6ms. Ambos os BMs quebraram a latência de 1ms em torno de 132K IOPS com o BM.Standard atingindo um pico de 140,848 IOPS com uma latência de 1.3ms e o BM.DenseIO atingindo um pico de 139,883 IOPS e 1.2ms de latência.

O login inicial com NVMe teve um desempenho máximo de 24,228 IOPS e 326μs para VM.DenseIO e 242,778 IOPS com 234μs para BM.DenseIO.

Por fim, com o VDI Linked Clone Monday Login with BV, o VM.Standard teve desempenho de latência abaixo de milissegundos até cerca de 27K IOPS com um pico de 39,874 IOPS e uma latência de 2.86 ms. VM.DenseIO quebrou 1 ms em cerca de 25 IOPS e atingiu o pico de 42,469 IOPS e 3 ms de latência. Ambos os BMs tiveram latência abaixo de milissegundos até cerca de 135K IOPS, com pico de 146K IOPS, o densaIO tendo uma latência de 1.6ms e o padrão tendo uma latência de 1.76ms.

Com o VDI Linked Clone Monday Login com NVMe, o VM.DenseIO atingiu um pico de 34,016 IOPS e uma latência de 464μs. O BM.DenseIO atingiu um pico de 260,527 IOPS e uma latência de 317μs.

Conclusão

A infraestrutura de nuvem da Oracle aborda um dos principais problemas da nuvem – desempenho ou falta dele – com suas instâncias bare metal. A Oracle oferece instâncias de computação bare metal e virtual, bem como versões NVMe com até 25 TB de armazenamento NVMe para desempenho diferente de tudo visto na nuvem. É preciso mais do que armazenamento NVMe para atingir o desempenho cotado da Oracle de até 5.1 milhões de IOPS; as instâncias também têm até 52 OCPUs, 768 GB de RAM, NICs duplas de 25 GbE e até 51 TB de armazenamento NVMe conectado localmente. Esse nível de desempenho é usado principalmente para casos de uso, como aplicativos de banco de dados de missão crítica, cargas de trabalho HPC e aplicativos da Web com uso intensivo de E/S.

No lado do desempenho, executamos nossos testes VDBech para formas bare metal (BM) e VM usando o armazenamento NVMe local (DenseIO) e o armazenamento em bloco de rede (Standard). O desempenho, simplesmente, nos surpreendeu. Para cada teste, executamos dois conjuntos de gráficos, pois a discrepância de latência entre DenseIO e Standard era tão grande que seria difícil ler os gráficos se todos estivessem em um conjunto. Em termos de desempenho de armazenamento nessas instâncias em comparação com o armazenamento tradicional, elas rivalizam com muitas das melhores opções de armazenamento compartilhado do mercado, sem falar nas alternativas de nuvem. Os BVs anexados que são hospedados em iSCSI e com backup oferecem uma forte combinação de taxa de transferência e largura de banda atendida em baixa latência. Para colocar isso em contexto, vimos muitos testes com 32 BVs conectados nas 52 instâncias de OCPU excederem o desempenho de arrays de armazenamento totalmente flash que testamos em nosso laboratório. Na verdade, alguns podem ter sido um pouco mais rápidos, o que é bastante impressionante, considerando que estamos comparando uma instância de nuvem com um AFA de US$ 250, comutação de FC e vários hosts de computação.

O que torna as instâncias bare metal do Oracle Cloud realmente incríveis é o armazenamento NVMe conectado localmente. O DenseIO2.8 tinha 1 dispositivo, enquanto o DenseIO2.52 tinha 8, dando a essas instâncias o desempenho medido em milhões de IOPS. A instância com 1 SSD NVMe viu a velocidade de leitura aleatória de 4K chegar a 569k IOPS, enquanto a instância com 8 teve o desempenho disparado para 4.4M IOPS. Largura de banda também não era brincadeira; a instância menor teve um pico de leitura de 2.5 GB/s, enquanto a maior atingiu acima de 20 GB/s. Certifique-se de ter um plano de backup em vigor, pois as formas NVMe são armazenamento conectado localmente, afinal, que precisam ser protegidos.

A Oracle construiu servidores e armazenamento de alta especificação na nuvem; a única coisa que pode rivalizar com suas instâncias bare metal é construir um servidor de alta especificação hospedado localmente, juntamente com todos os outros componentes e serviços para suportá-lo. Assim como todas as soluções em nuvem, a Oracle oferece fluidez para ativar e desativar suas instâncias e flexibilidade para ajustar os requisitos de armazenamento conforme necessário. Com essas instâncias, o problema óbvio que surgirá é o custo. A conveniência de obter uma instância online no Oracle Cloud versus o esforço e as despesas necessárias para configurar um hardware comparável em seu próprio data center talvez seja o principal fator decisivo. Embora o armazenamento anexado ao NVMe seja caro, não há como contestar os benefícios de desempenho que vimos. Se você tem uma empresa que é afetada pelo tempo de processamento de grandes conjuntos de dados, não há solução mais fácil ou rápida para concluir cargas de trabalho como análises do que as formas baseadas em NVMe que usamos. E não é que as formas de bloco anexadas padrão fossem ruins, as formas NVMe eram tão irreais que ofuscavam o resto. O ponto principal é que as empresas com visão de futuro que podem obter valor mensurável da nuvem de alto desempenho devem definitivamente avaliar o que a Oracle está fazendo. Existem muitas opções ao ir para a nuvem, mas nada é tão rápido quanto o que vimos com as instâncias bare metal do Oracle Cloud, tornando essas soluções uma clara e merecida vencedora do nosso primeiro Editor's Choice Award concedido a serviços em nuvem fornecedor.