Estão surgindo mais e mais soluções que estão se afastando da abordagem tradicional de armazenamento unificado. Esses são armazenamentos especializados, adaptados às tarefas de uma determinada área de negócios. Anteriormente, falei sobre o sistema Infinidat InfiniBox F2230. Hoje no centro da minha análise do SolidFire.
"Quem diabos odeia armazenamento" @ Dave Heats, fundador da NetAppNo final de 2015, a NetApp anunciou a compra da startup SolidFire, fundada em 2010. O interesse nesses sistemas é devido à sua abordagem diferente para gerenciar data warehouses e desempenho previsível.
As soluções SolidFire complementam a linha de produtos NetApp, que inclui as séries All Flash FAS (AFF), EF e E. Também permitiu, um ano e meio depois, lançar no mercado um novo produto - o NetApp HCI (Hyper Converged Infrastructure), que usa o SolidFire como um subsistema de armazenamento.
“Estamos desenvolvendo um novo sistema de armazenamento projetado para data centers de computação em nuvem muito grandes. Basicamente, a ideia é que muitas empresas transfiram a computação de seus escritórios ou de seus próprios datacenters para esses grandes datacenters em nuvem, onde eles têm dezenas de milhares de clientes com todas as informações em um só lugar. Portanto, estamos criando um novo sistema de armazenamento projetado para atender a esses grandes data centers. ”
Dave Wright, CEO da SolidFire, 2012
Recentemente, há cada vez mais soluções que estão se afastando da abordagem tradicional de armazenamentos unificados que podem resolver qualquer problema, para armazenamentos especializados projetados para resolver problemas de uma determinada área de negócios.
Há pouco tempo,
eu já falei sobre o sistema Infinidat InfiniBox F2230 , perfeito para as tarefas dos provedores de serviços. O participante de hoje em nossa análise do SolidFire também pode ser atribuído a essa classe de dispositivos. O fundador do SolidFire, Dave Wright, e sua equipe são da RackSpace, onde estavam desenvolvendo um sistema de armazenamento eficiente que proporcionaria desempenho linear em um ambiente com muitos usuários, embora fosse simples, facilmente escalável e com recursos de automação flexíveis. Na tentativa de resolver esse problema, o SolidFire nasceu.
Até o momento, a linha SolidFire consiste em quatro modelos com diferentes taxas de IOPS / TB.
10 SSDs (MLC) são usados para armazenamento de dados e Radian RMS-200 como NVRAM. É verdade que já existem planos de mudar para os módulos
NVDIMM .
De interesse aqui é como o SolidFire recupera e armazena dados. Todos sabemos sobre o recurso limitado de unidades SSD; portanto, é lógico que, para sua melhor preservação, a compactação e a desduplicação ocorram rapidamente, antes de gravar no SSD. Quando o SolidFire recebe dados do host, os divide em blocos 4K, após o que esse bloco é compactado e armazenado na NVRAM. Em seguida, ocorre a replicação síncrona desse bloco na NVRAM para o nó "vizinho" do cluster. Depois disso, o SolidFire recebe o hash desse bloco compactado e procura esse valor de hash em seu índice de dados armazenados em todo o cluster. Se já existir um bloco com esse hash, o SolidFire atualiza apenas seus metadados com um link para esse bloco; se o bloco contiver dados exclusivos, ele será gravado no SSD e os metadados também serão gravados. Esse mecanismo para armazenar dados e metadados é muito semelhante ao mecanismo de operação do armazenamento de objetos.
Nosso cluster de teste de quatro nósJá surgiram rumores de que esta linha será atualizada em breve. Vale a pena notar uma coisa muito importante - o cluster SolidFire é capaz de trabalhar com nós com diferentes "densidades de IOPs / TB" e combinar nós de gerações diferentes em um cluster. Em primeiro lugar, torna o uso deste sistema mais previsível em termos de suporte de hardware e também facilita a transição de nós antigos para novos, quando você simplesmente adiciona novos e exclui antigos do cluster em tempo real (aguardando apenas a reconstrução do cluster) sem tempo de inatividade, porque Há suporte para Escalonar e Escalar.
O SolidFire pode ser entregue como três soluções:
- SolidFire como um produto autônomo baseado em servidores Dell / EMC,
- como parte do FlexPod SF em servidores Cisco,
- como parte do NetApp HCI em sua plataforma.
Como você pode ver na tabela de características, os nós suportam apenas a conexão iSCSI e, para a conexão FC, há um tipo separado de nó - Fabric Interconnect, que por sua vez contém quatro portas para dados FC e quatro portas iSCSI para conexão com nós, além de 64 GB de memória nativa do sistema / cache de leitura.
A tabela de características também mostra o desempenho de cada um dos nós. Esse é um daqueles casos em que você conhece o desempenho do seu sistema de armazenamento no estágio da compra. Esse desempenho é garantido (com um perfil de carga de 4Kb, 80/20) para cada nó.
Assim, ao comprar um cluster de nós X ou expandir uma solução existente, você entende quanto volume e que tipo de desempenho terá no final. Obviamente, você pode obter mais desempenho de cada nó sob certas condições, mas não é para isso que esta solução foi projetada. Se você deseja obter milhões de IOPS em 2U em um único volume, é melhor voltar a atenção para outros produtos, como o AFF. O melhor desempenho no SolidFire pode ser obtido com um grande número de volumes e sessões.
Página inicial da interfaceO gerenciamento de armazenamento é bastante simples. De fato, temos dois pools de recursos: volume e IOPS. Ao identificar um dos tipos de recursos e conhecer seu número final, entendemos claramente os outros recursos do nosso sistema. Isso novamente torna a expansão do sistema uma tarefa extremamente fácil. Precisa de mais desempenho? Considere o SF4805 ou o SF19210 com uma proporção IOPS / TB "menos densa". Precisa de volume? Nós olhamos para SF9605 e SF38410, que fornecem menos IOPS em Gb.
Do ponto de vista do administrador de armazenamento, o sistema parece bem chato. Coisas como desduplicação e compactação funcionam por padrão.
Replicação e instantâneos também estão disponíveis, e a replicação pode ser organizada para toda a gama de produtos NetApp (exceto para a série E). É essa simplicidade, na minha opinião, que é revelada por trás da citação de Dave Heats do título do artigo. Como esse sistema envolve a integração com vários sistemas de alocação dinâmica de recursos, sem a participação de um administrador e sem custos adicionais de mão-de-obra, em breve você geralmente esquecerá como é a interface do SolidFire. Mas falaremos mais sobre integração.
Na
Onlanta ,
realizamos testes de estresse para garantir os 200k IOPS prometidos. Não que não acreditemos no fornecedor, mas estamos acostumados a tentar tudo por conta própria. Não nos propusemos a meta de sair do sistema mais do que o declarado. Também fomos capazes de verificar por nossa própria experiência que o sistema fornece um bom resultado precisamente com um grande número de fluxos. Para isso, organizamos 10 volumes de 1 TB no SolidFire, nos quais colocamos uma máquina virtual de teste. Já na fase de preparação do ambiente de teste, ficamos agradavelmente surpreendidos com o trabalho de desduplicação. Apesar do fato de o esquema de seu trabalho ser bastante padrão, a qualidade do trabalho no cluster acabou sendo extremamente eficaz. Os discos antes dos testes foram preenchidos com dados aleatórios.
Para acelerar, geramos um bloco de 10 mb e eles o preencheram. Além disso, em cada máquina virtual, esse bloco foi gerado separadamente, ou seja, em todos os carros o padrão é diferente. Dos 10 TB preenchidos com dados - o espaço ocupado real na matriz era de 4 TB. A eficiência da desduplicação é de 1: 2,5; no FAS com essa abordagem, a eficiência de desduplicação em linha tendeu a 0. Conseguimos 190k IOPS com uma resposta de ~ 1 ms em nossa bancada de testes.
Gostaria de observar que os recursos arquiteturais da solução não permitem obter um alto nível de desempenho em um pequeno número de threads. Uma pequena lua ou apenas uma máquina virtual de teste não será capaz de mostrar resultados altos. Conseguimos obter essa quantidade de IOPS usando toda a capacidade do sistema e com um aumento gradual no número de máquinas virtuais que criam uma carga usando fio. Aumentamos seu número até que os atrasos não ultrapassassem 1,5 ms, após o que paramos e retiramos os indicadores de desempenho.
A plenitude do subsistema de disco também afeta o desempenho. Como eu disse anteriormente, antes de executar os testes, enchemos os discos com dados aleatórios. Se você executar o teste sem primeiro preencher os discos, o desempenho será muito maior com o mesmo nível de atraso.
Também realizamos nosso teste de tolerância a falhas favorito desativando um dos nós. Para obter o melhor efeito, um nó Mestre foi selecionado para desativar. Devido ao fato de cada servidor cliente estabelecer sua própria sessão com o nó do cluster, e não por meio de um único ponto, ao desconectar um dos nós, nem todas as máquinas virtuais são degradadas, mas apenas aquelas que funcionavam com esse nó. Assim, do lado do armazenamento, vemos apenas uma queda parcial no desempenho.
É claro que, por parte dos hosts de virtualização, em alguns armazenamentos de dados, a queda de desempenho foi de 0. Mas, em 30 segundos, o desempenho foi restaurado sem perda de desempenho (deve-se ter em mente que a carga no momento da queda era de 120k iops, que três poderiam produzir potencialmente dos quatro nós, respectivamente, não deveríamos ter visto uma perda no desempenho).
No lado do SolidFire, a reconstrução da matriz começou. O cronômetro está parado um pouco, e o processo levou cerca de 55 minutos, o que se encaixa na hora prometida pelo fornecedor. Ao mesmo tempo, ninguém removeu a carga do sistema de armazenamento e ela permaneceu no mesmo nível de 120k IOPS.A tolerância a falhas é fornecida não apenas no nível do disco, mas também no nível do nó. O cluster suporta a falha simultânea de um nó, após o qual o processo de reconstrução do cluster é iniciado. Considerando o uso do SSD e que todos os nós estão envolvidos na reconstrução, a recuperação do cluster leva cerca de uma hora (a reconstrução no caso de uma falha no disco leva cerca de 10 minutos). Deve-se ter em mente que, quando um nó falha, você perde tanto no desempenho quanto na quantidade de espaço utilizável. Assim, você sempre precisa ter espaço livre na quantidade de um nó. O tamanho mínimo do cluster é de quatro nós. Essa configuração permitirá evitar problemas se um dos nós falhar antes de aguardar a substituição.
Como na maioria dos sistemas de armazenamento, o monitoramento de desempenho é exibido aqui apenas em tempo real. Para ter acesso aos dados históricos, é necessário implantar o chamado Nó de Gerenciamento, comprometido em pegar os dados da API do SolidFire e enviá-los ao Active IQ. Se você já trabalhou com sistemas NetApp, talvez já tenha se deparado com este portal. Você tem a oportunidade de trabalhar com dados sobre produtividade, eficiência, incluindo previsões de crescimento. No que você pode acessar esses dados, mesmo do seu dispositivo móvel, estando em qualquer lugar do mundo.
Como mencionei o trabalho de desduplicação em linha, também falarei sobre a eficiência do armazenamento em geral. Assim como na série AFF, a NetApp fornece uma taxa de eficiência de armazenamento garantida com base no tipo de dados armazenados.
Como você pode ver, os tipos de dados e os coeficientes garantidos são ligeiramente diferentes. Por exemplo, o SolidFire tem exatamente o nosso caso - infraestrutura virtual com um coeficiente de 4: 1. E isso não leva em consideração o uso de instantâneos.
A arquitetura da solução é baseada na Qualidade de Serviço (QoS), que realmente garante desempenho garantido para cada volume.
A QoS é uma das funções críticas para provedores de serviços e outras empresas que precisam fornecer um nível garantido de desempenho de armazenamento. Alguém dirá que QoS não é algo novo e é implementado por muitos outros fornecedores. Outra questão é como isso funciona. Se no armazenamento tradicional é mais provável priorizar e limitar a velocidade, o SolidFire, por sua vez, usa uma abordagem integrada para obter desempenho garantido.
- O uso de um SSD completo permite obter baixa latência para E / S.
- A expansão em escala prevê facilmente métricas de desempenho.
- Falta de RAID clássico - desempenho previsível com
- falhas de hardware
- Uma distribuição de carga equilibrada elimina gargalos no sistema.
- A QoS ajuda a evitar "vizinhos barulhentos".
Além da capacidade de definir o desempenho máximo e mínimo, é possível fornecer esse desempenho além do limite máximo (Burst). Cada volume possui um certo sistema condicional de empréstimos. Quando sua produtividade está abaixo da marca máxima, ele recebe esses empréstimos, graças aos quais, por um certo período de tempo, ele pode superar a marca máxima de produtividade. Essa abordagem permite colocar um grande número de aplicativos que exigem alto desempenho no armazenamento e, ao mesmo tempo, protegê-los dos efeitos negativos entre si. O mais interessante é que a QoS é suportada não apenas no nível de volume da matriz, mas também no nível de VMware VVs, que permite alocação granular de recursos para cada máquina virtual. O suporte total ao VAAI e à API do VASA fornece uma forte integração de matriz com o virtualizador.
Falando em integração, a solução da VMware está longe de terminar.
Talvez o SolidFire possa ser chamado de sistema de armazenamento mais automatizado que pode se integrar a qualquer sistema moderno, sistemas de virtualização / contêiner, suporta sistemas de gerenciamento de configuração, o SDK está disponível para vários idiomas.
Como sempre, observei a primeira coisa que o SDK para Python é com a qual automatizo meus próprios fluxos de trabalho. Portanto, precisamos criar 15 volumes de 1 TB e obter o iqn na saída, que passaremos aos administradores da VMware para adicionar datastores. Já temos grupos de acesso pré-criados nos quais nossos hosts VMware e políticas de QoS pré-criadas são registradas.
Ou aqui está um vídeo de demonstração do Python SDK mais detalhado do próprio SolidFire:
Essa abordagem de automação torna o SolidFire conveniente não apenas para provedores de nuvem e tarefas similares, mas de acordo com o conceito de integração e entrega contínuas (CI / CD) permite otimizar o processo de desenvolvimento.
Como mencionei - o WebUI funciona através da API e você pode ver todas as solicitações e respostas através do log da API.Se você estiver interessado em aprender mais sobre o SolidFire, sobre sua comparação com os concorrentes, sobre como trabalhar com o sistema etc., desejo recomendar o
canal do YouTube deles, que possui um número bastante grande de vídeos úteis. Por exemplo, o ciclo "Comparando arquiteturas modernas totalmente em flash".
Entre os recursos interessantes do sistema, está o mecanismo interno para fazer backup de instantâneos em um armazenamento externo compatível com S3. Isso permite usar instantâneos como backups e armazená-los em repositórios externos, tanto no site quanto em recursos externos, por exemplo, na Amazon. Obviamente, essa abordagem dificilmente pode ser chamada de flexível, do ponto de vista da recuperação de dados, mas, em alguns casos, essa solução pode ser útil e bastante aplicável. Há outro ponto interessante - você pode enviar dados para o armazenamento S3 de duas maneiras:
- Nativo - nesse caso, os dados já desduplicados serão derramados, mas, ao mesmo tempo, esse volume pode ser restaurado apenas no mesmo sistema em que é derramado.
- Descomprimido - um conjunto completo de blocos já foi derramado aqui, o que permite restaurar esta lua em qualquer outro cluster do SolidFire.
Em geral, estávamos mais do que satisfeitos com nossa comunicação com o SolidFire. Obtivemos o desempenho prometido, o trabalho de desduplicação em linha está além dos elogios, os recursos de integração e automação também deixaram uma impressão extremamente positiva. A influência da falha dos nós, ou melhor, seu efeito mínimo no desempenho do sistema como um todo, a distribuição de carga e a ausência de um único ponto de falha, o que poderia afetar bastante o desempenho, tornam esse sistema extremamente atraente. Apesar do fato de que o cluster só pode funcionar no iSCSI, a presença do nó de transporte FC torna esse sistema mais universal.
Gostaria de expressar uma gratidão especial nos testes a Yevgeny Krasikov, da NetApp, e Arthur Alikulov, da Merlion. Aliás, Arthur, tem um maravilhoso
canal Telegram para todos que desejam acompanhar as notícias da direção do armazenamento e da NetApp em particular. Você pode encontrar uma grande quantidade de materiais úteis e, quem quer que precise ler, mas também queira conversar, também há discussões sobre
armazenamento de bate -
papo .
Se você ainda tiver dúvidas ou aparecer novas de repente, convido você a visitar o NetApp Directions 2018, que será realizado em 17 de julho de 2018 no Hyatt Regency Petrovsky Park, onde Arthur e eu falaremos sobre o SolidFire em uma das sessões.
Inscrição para o evento e todos os detalhes.
E em nossa empresa há uma vaga.