Conhecemos Diamanti pela primeira vez há dois anos na KubeCon 2017 e ficamos impressionados com sua visão: fornecer uma plataforma de container bare-metal desenvolvida especificamente para microsserviços e ambientes nativos de nuvem e otimizada para Kubernetes ou, basicamente, uma plataforma hiperconvertida dispositivo de infraestrutura para Kubernetes. Vimos isso como uma jogada interessante e, no ano passado, na KubeCon 2018, começamos a conversar com eles sobre como trabalhar conosco para entender o armazenamento no Kubernetes e como o armazenamento do Kubernetes pode ser testado e quantificado de maneira metódica para que possamos começar a testar e documentar Desempenho de armazenamento do Kubernetes.
Conhecemos Diamanti pela primeira vez há dois anos na KubeCon 2017 e ficamos impressionados com sua visão: fornecer uma plataforma de container bare-metal desenvolvida especificamente para microsserviços e ambientes nativos de nuvem e otimizada para Kubernetes ou, basicamente, uma plataforma hiperconvertida dispositivo de infraestrutura para Kubernetes. Vimos isso como uma jogada interessante e, no ano passado, na KubeCon 2018, começamos a conversar com eles sobre como trabalhar conosco para entender o armazenamento no Kubernetes e como o armazenamento do Kubernetes pode ser testado e quantificado de maneira metódica para que possamos começar a testar e documentar Desempenho de armazenamento do Kubernetes.
Foi ótimo trabalhar com Diamanti e foi capaz de nos fornecer a compreensão profunda do Kubernetes e do armazenamento Kubernetes de que precisávamos para criar nossa metodologia de teste. A Diamanti foi iniciada por ex-engenheiros da VMware, VERITAS e Cisco e é financiada pela Goldman Sachs e outros VCs conhecidos, o que é impressionante, mas o que é mais impressionante é que a Diamanti tem sido uma das principais contribuintes para os padrões de armazenamento e rede (ou seja, FlexVolume/CSI e CNI) que foram aceitos no código upstream do Kubernetes.
Os negócios corporativos estão evoluindo na velocidade da luz, e as empresas estão tentando acompanhar essa evolução com novas tecnologias para acelerar todo o ciclo de produção de aplicativos. Containers foi a tecnologia projetada para acelerar o desenvolvimento e a implantação de aplicativos, mas construí-los na infraestrutura legada pode ser complicado e rapidamente se torna um obstáculo considerável para estruturar uma pilha de contêineres totalmente funcional. Os contêineres são incompatíveis com o armazenamento tradicional e a infraestrutura de rede, portanto, uma abordagem faça você mesmo (DIY) para criar um ambiente de contêiner é um desafio de TI, caro e lento. A Diamanti Enterprise Kubernetes Platform destina-se a fornecer aos arquitetos de infraestrutura, operações de TI e proprietários de aplicativos a velocidade, simplicidade, eficiência e controle de que precisam para executar aplicativos em contêineres com estado em escala.
A Diamanti Enterprise Kubernetes Platform é uma plataforma de contêiner bare-metal focada nos aspectos de rede e armazenamento para começar a funcionar rapidamente, especialmente para grandes empresas. Com Docker e Kubernetes de código aberto totalmente integrados, juntamente com hardware específico e suporte completo para toda a pilha, a Diamanti Enterprise Kubernetes Platform é uma solução de contêiner completa que pode ser implantada em minutos. A Diamanti afirma ter desempenho e utilização incomparáveis em sua Enterprise Kubernetes Platform; o molho secreto para esse desempenho é usar uma arquitetura hiperconvergente exclusiva projetada especificamente para a maneira como os contêineres do Kubernetes usam recursos de rede e armazenamento.
Especificações do Diamanti D10
| Network | 4 × 10 GbE por meio de uma única conexão QSFP+ (por nó) |
| Armazenamento | |
| Armazenamento de dados | Configuração de 4 TB (4 x SSD NVMe de 1000 GB por nó) Configuração de 8 TB (4 x SSD NVMe de 2000 GB por nó) Configuração de 32 TB (4x 8000 GB NVMe SSD por nó) |
| Sistema operacional host e armazenamento de imagens do Docker | 960 GB (2x SSD SATA de 480 GB por nó) |
| Computar | |
| CPU | 2 processadores Intel Xeon com 20/32/44 núcleos (por nó) |
| RAM | 192 GB / 384 GB / 768 GB (por nó |
| Físico | |
| Fator de Forma | 1U |
| Dimensões e peso (por nó) | 17.25" L x 28" P x 1.72" A / 52 lbs. 43.8 cm x 71.1 cm x 4.4 cm / 24 kg |
| Energia | Fontes de alimentação redundantes duplas de 110/220 V |
| Ambiental | Temperatura de operação: 50 ° F a 95 ° F (10 ° C a 35 ° C) |
Construir e projetar
O dispositivo Diamanti é o hardware físico da solução de empilhamento de contêineres da Diamanti. Este dispositivo é oferecido em um cluster mínimo de três nós, onde cada nó é um rack de 1U que fornece até 32 TB de capacidade de armazenamento de dados e 960 GB para sistema operacional host e armazenamento de imagem do Docker.
A frente de um nó mostra uma grade de alumínio projetada para fluxo de ar eficiente com o log da empresa no meio e no canto superior esquerdo, um mecanismo de travamento. No canto superior direito da frente, está o painel de controle que fornece um botão liga/desliga, juntamente com LEDs indicadores para a integridade do sistema. A remoção da grade de alumínio revelará os locais dos slots de unidade, também uma VGA e duas portas USB.
Movendo-se para a parte traseira do aparelho, vemos as portas do dispositivo. Aqui destacamos as duas fontes de alimentação independentes da esquerda e um sistema ventilado; e no meio/direita, as duas portas de gerenciamento, uma porta 10GbE para conectar nós com alto desempenho e baixa latência, uma porta QSFP+ (para 4x10G SFP+) e 4 portas USB para conectar um teclado e outros periféricos.
Gestão de Sistemas
O dispositivo é fornecido com pilha de software completa pré-integrada, incluindo sistema operacional, Docker, Kubernetes e outros serviços de convergência de contêiner. Ele fornece painéis e funções de relatório por meio de um navegador, CLI ou API REST e Diamanti OS. A Diamanti Enterprise Kubernetes Platform é certificada pela K8s; uma certificação concebida pela organização CNCF.
Para gerenciamento, olhamos para o console Diamanti. Abrindo-o, vamos direto para o painel que contém informações básicas e fáceis de ler rapidamente. Aqui podemos ver quantos nós estão em execução, quantos contêineres e quantos pods. O uso de CPU, armazenamento, memória e rede também são facilmente vistos em porcentagens à esquerda. À direita está a largura de banda em Kbps.
A próxima guia principal abaixo é Criar aplicativos. Depois que os usuários criarem os aplicativos que desejam, a subguia é Implantar com um pequeno ícone do Kubernetes. A partir daqui, os usuários precisam inserir informações como nome, imagem, ambiente, porta, montagens de volume e a quantidade de CPU e memória.
A próxima guia principal abaixo é Aplicativos. Abaixo da guia principal estão as subguias: Pods, Replications Controllers, Replica Sets, Stateful Sets, Daemon Sets, Deployments e Jobs. Os pods fornecem aos usuários um breve resumo da integridade de um pod selecionado, bem como a computação, rede e armazenamento atribuídos.
A subguia Stateful Sets permite aos usuários detalhar mais os conjuntos e exportá-los, se necessário. Aqui, são apresentadas informações básicas, como nome, namespace, número desejado, número atual, número pronto, idade e opções sobre quais ações tomar.
Os usuários também podem detalhar os registros do pod para ver a atividade e possíveis problemas.
A próxima guia principal abaixo é K8S Configurations. Aqui, os usuários podem gerenciar configurações de aplicativos relacionados ao Kubernetes, como contas de serviço, consultar segredos, configurar mapas e criar namespaces.
Na guia Administração do nó, os usuários podem visualizar, adicionar ou excluir nós, bem como monitorar a utilização dos recursos do nó. Novamente, aqui os usuários podem monitorar a integridade geral de um determinado nó e os recursos: computação, rede e armazenamento.
Como o nome da guia indica, a Administração de armazenamento permite que os usuários vejam todos os itens de armazenamento, incluindo volumes, instantâneos, unidades, volumes persistentes, reivindicações de volume persistente, classes de armazenamento e backups. Na subguia Volumes, temos a capacidade de criar um novo volume ou ver um resumo de um existente, incluindo sua integridade, taxa de transferência de armazenamento e uso.
A subguia Drives permite que os usuários vejam as alavancas das unidades físicas com informações como em qual slot a unidade está, seu S/N, capacidade bruta, capacidade utilizável, capacidade alocada, seu firmware e em que estado ela está. podem ser formatados a partir desta subguia.
A subguia Persistent Volumes permite que os usuários criem ou exportem volumes persistentes, além de fornecer informações como nome, tipo de capacidade, acesso, recuperação, status, reivindicação, disponibilidade de armazenamento, idade e uma lista de ações, incluindo editar, exportar e excluir.
As Reivindicações de Volume Persistente fazem o mesmo que acima para PVCs.
Nossa próxima guia principal é a guia Administração de rede. Aqui os usuários podem criar, excluir, editar ou exportar redes. Aqui recebemos informações como nome, grupo, se é a rede padrão, rede de host, sua sub-rede, gateway, endereço inicial, endereço final e endereço IP.
A administração do usuário é bastante direta. Aqui, os administradores podem criar usuários e grupos e configurar várias políticas para controle de acesso.
As configurações avançadas permitem que os administradores criem e ajustem os níveis de cluster e desempenho.
Embora geralmente passemos por várias funções de gerenciamento para dar aos leitores uma ideia geral do que esperar ao passar por algo, estamos fazendo algo um pouco diferente desta vez. Também executamos nossos benchmarks para que possamos ver o que a GUI faz com uma carga de trabalho mais pesada em execução. Para cada um desses benchmarks, estaremos na guia Node Administrations.
Com nossos testes básicos (aleatórios e sequenciais), pode-se ver facilmente o empate na computação, bem como as métricas de desempenho à direita.
Nosso teste de SQL causou um impacto bastante leve na computação e na rede, enquanto o armazenamento atingiu quase 1 milhão de IOPS.
Por fim, damos um exemplo do que se espera enquanto nosso teste Oracle está rodando.
Desempenho
Análise de Carga de Trabalho do VDBench
Quando se trata de matrizes de armazenamento de comparação, o teste de aplicativo é o melhor e o teste sintético vem em segundo lugar. Embora não seja uma representação perfeita das cargas de trabalho reais, os testes sintéticos ajudam a estabelecer a linha de base dos dispositivos de armazenamento com um fator de repetibilidade que facilita a comparação entre soluções concorrentes. Essas cargas de trabalho oferecem uma variedade de perfis de teste diferentes, desde testes de "quatro cantos" e 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:
- Leitura aleatória em 4K: 100% de leitura, 128 threads, 0-120% de atualização
- Gravação aleatória em 4K: 100% de gravação, 64 threads, 0-120% de atualização
- 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
Em todos os nossos testes VDBench, testamos o dispositivo Diamanti com base em diferentes implantações executando 3, 6, 9 ou 12 pods Vdbench por vez para aumentar o limite do dispositivo. Começando com desempenho de leitura aleatória de 4K, todos os pods Vdbench começaram com uma latência de 120μs; e desempenho de IO variando entre os 3 pods em 95,863 IOPS e 12 pods em 269,208 IOPS. Olhando para o desempenho máximo, todas as configurações ficaram abaixo da latência de 600μs. Com 3 pods Vdbench, vimos um pico de 947,619 IOPS com uma latência de 370μs; com 6 pods, pico de 1,745,344 IOPS com latência de 436μs; com 9 pods, pico de 2,492019 IOPS com latência de 447μs; e a última implantação, 12 pods, atingiu o pico de 2,753,170 IOPS com uma latência de 554μs.
Olhando para o desempenho de gravação em 4K, todas as implantações de teste começaram com uma latência de 300μs, mas aumentaram rapidamente entre 26ms e 28ms ao atingir o desempenho máximo. O desempenho atingiu o pico com 3 pods em 13,719 IOPS; 6 pods a 27,747 IOPS; 9 pods em 42,805 IOPS; e com 12 pods a 58,559 IOPS. Mostrando um aumento constante de desempenho em mais pods adicionados.
Mudando para cargas de trabalho sequenciais, observamos o desempenho de leitura de 64K do dispositivo e aqui a implantação de 3 pods começou em 14,560 IOPS ou 910 MB/s com uma latência de 297 μs. Todas as outras implantações começaram perto de 18,000 IOPS ou 1.1 GB/s com uma latência de 227 μs. Com relação ao desempenho máximo das implantações, a implantação de 3 pods atingiu o pico de 143,431 IOPS ou 9 GB/s com uma latência de 327 μs. Todas as outras implantações atingiram quase o mesmo desempenho de 179,000 IOPS ou 11.1 GB/s, com a implantação de 12 pods sendo a única que ultrapassou a marca de latência de 1ms.
Na gravação sequencial de 64K, todas as implantações do Vdbench começaram com uma latência próxima a 350μs. As implantações atingiram o seguinte pico: 3 pods, a 9,693 IOPS ou 606 MB/s com latência de 4.9 ms; os 6 pods, a 22,202 IOPS ou 1.39 GB/s com latência de 4.3 ms; os 9 pods, a 30,475 IOPS ou 1.9 GB/s com latência de 4.7 ms; e, finalmente, os 12 pods atingiram um pico de 32,052 IOPS ou 2.4 GB/s com uma latência de 4.9 ms.
Nosso próximo conjunto de testes são nossas cargas de trabalho SQL: SQL, SQL 90-10 e SQL 80-20. Para SQL, todas as implantações começaram com latência de 180μs. Os 3 pods começaram em 26,291 IOPS e atingiram um pico de 261,573 IOPS com uma latência de 366μs. Os 6 pods atingiram 57,061 IOPS e atingiram o pico de 570,642 IOPS com uma latência de 336μs. Os 9 pods começaram com 86,197 IOPS e atingiram o pico de 885,269 IOPS com uma latência de 332μs. E a implantação de 12 pods começou em 101,753 IOPS e atingiu um pico de 1,106,860 IOPS com uma latência de 346μs.
Para SQL 90-10, todas as implantações começaram perto da latência de 200μs. A implantação de 3 pods começou em 10,753 IOPS e atingiu um pico de 105,877 IOPS com uma latência de 904 μs. Os 6 pods atingiram 49,361 IOPS e atingiram o pico de 245,158 IOPS com uma latência de 782μs. Os 9 pods começaram com 80,157 IOPS e atingiram o pico de 401,444 IOPS com uma latência de 716μs. E a implantação de 12 pods começou em 55,748 IOPS e atingiu um pico de 554,685 IOPS com uma latência de 690 μs.
Para nosso último teste de SQL, o 80-20, vimos que as implantações do Vdbench também começaram muito perto da latência de 200μs. As implantações atingiram o pico da seguinte forma: a implantação de 3 pods em 57,944 IOPS com latência de 1.6 ms; os 6 pods atingiram o pico de 132,384 IOPS com uma latência de 1.4 ms; os 9 pods 217,273 IOPS com latência de 1.3ms; e a implantação de 12 pods atingiu um pico de 305,426 IOPS com uma latência de 1.2 ms.
A seguir estão nossas cargas de trabalho Oracle: Oracle, Oracle 90-10 e Oracle 80-20. Com o Oracle, todas as implantações começaram abaixo de 210μs. Aqui vemos o desempenho máximo das implantações. Os 3 pods atingiram um pico de 54,844 IOPS com uma latência de 2.2 ms. Os 6 pods atingiram um pico de 125,633 IOPS com uma latência de 1.9ms. Os 9 pods atingiram o pico de 206,024 IOPS com uma latência de 1.7ms. E a implantação de 12 pods atingiu um pico de 290,313 IOPS com uma latência de 1.6 ms.
No Oracle 90-10, as implantações começaram abaixo de 200μs. A implantação de 3 pods atingiu um pico de 106,182 IOPS com uma latência de 620μs. Os 6 pods atingiram um pico de 243,383 IOPS com uma latência de 541μs. Os 9 pods atingiram o pico de 393,727 IOPS com uma latência de 502μs. E, por último, a implantação de 12 pods atingiu um pico de 544,584 IOPS com uma latência de 483μs.
Para o Oracle 80-20, vimos mais uma vez todas as implantações iniciando com uma latência de 210μs. Observando o desempenho máximo das implantações, vemos os 3 pods com pico de 58,037 IOPS com latência de 1.1 ms; os 6 pods com pico de 132,911 IOPS com latência de 991μs; os 9 pods com pico de 215,817 IOPS com latência de 915μs; e, finalmente, a implantação de 12 pods atingiu um pico de 304,391 IOPS com uma latência de 865μs.
Conclusão
O Kubernetes foi aceito por empresas menores e agora está amadurecendo em uma tecnologia que a maioria, se não todas as empresas da Fortune 500, estão olhando e, algumas das mais inovadoras, estão começando a implementar. O Kubernetes existe há apenas 5 anos, mas ultrapassou a parcela dos inovadores na curva de adoção de tecnologia e está solidamente no campo dos primeiros usuários. Esse posicionamento na curva de adoção de tecnologia é importante, pois a comunidade do Kubernetes descobriu como executar o Kubernetes e agora está se concentrando em fazê-lo funcionar bem. Esperamos que testes como esses ajudem os consumidores do Kubernetes a decidir quais fornecedores usar. e ajudar os fornecedores, dando-lhes um padrão para se comparar.
A Diamanti criou uma solução Kubernetes atraente com o dispositivo de contêiner D10, oferecendo uma interface de gerenciamento informativa e simples de usar e uma plataforma de armazenamento de back-end muito rápida para hospedagem de contêineres. Como este ainda é um campo emergente, não há muitas soluções totalmente desenvolvidas no mercado, mas pelo que vimos, o D10 é capaz de atingir todas as marcas para o que tradicionalmente procuramos em um solução de armazenamento ou HCI. O desempenho geralmente é fantástico, oferecendo bem mais de 2.7 milhões de IOPs 4K de leitura aleatória de nosso cluster testando de 3 a 12 pods. Do ponto de vista da latência, começamos com pouco mais de 100 microssegundos e chegamos ao máximo em 600 microssegundos. Em termos de armazenamento, o desempenho é incrível e, a partir de uma plataforma de tecnologia emergente, é incrível. Do ponto de vista da gravação, o dispositivo oferecia 50k IOPS 4K aleatório, o que parece ser o único ponto fraco, mas algo que a empresa deveria ser capaz de resolver por meio de software ou talvez até mesmo de mídia de armazenamento. A largura de banda sequencial ofereceu velocidades de leitura superiores a 11 GB/s, novamente desempenho muito forte e utilizável, com velocidades de gravação chegando a 2.4 GB/s no pico.
No geral, para clientes que implantam o Kubernetes em seu ambiente, o dispositivo de contêiner Diamanti D10 oferece uma ótima abordagem pronta para uso da perspectiva de hospedagem e armazenamento para aqueles que desejam dar uma olhada séria no mercado de contêineres rápidos e soltos. Para ser justo, isso não é para todos, o cluster é bastante específico em seu direcionamento. Mas se você se encaixa nesse alvo, o Diamanti oferece exatamente o que esses clientes desejam, ele foi desenvolvido especificamente para esses tipos de cargas de trabalho de contêiner emergentes. Embora seja totalmente possível aproveitar o PKS para VMware ou soluções alternativas com foco mais corporativo, a Diamanti oferece um sistema de baixa complexidade e deve ter vantagem de custo em relação às pilhas corporativas tradicionais. Devido à abrangência da solução (tem uma boa GUI para variar) e ao perfil de desempenho muito bom, determinamos que o D10 é um vencedor digno do prêmio StorageReview Editor's Choice.
Inscreva-se no boletim informativo StorageReview
