{"id":38966,"date":"2019-10-31T22:27:03","date_gmt":"2019-10-31T19:27:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/admin-bez-ruk-giperkonvergentsiya\/"},"modified":"2019-10-31T22:27:03","modified_gmt":"2019-10-31T19:27:03","slug":"admin-bez-ruk-giperkonvergentsiya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin sem m\u00e3os = hiperconverg\u00eancia?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nEsse \u00e9 um mito, bastante comum no setor de hardware de servidores. Na pr\u00e1tica, no entanto, solu\u00e7\u00f5es hiperconvergentes (quando tudo est\u00e1 em um s\u00f3 lugar) s\u00e3o necess\u00e1rias por muitos motivos. Historicamente, as primeiras arquiteturas foram desenvolvidas pela Amazon e Google para seus servi\u00e7os. Naquela \u00e9poca, a ideia era criar uma fazenda computacional com n\u00f3s id\u00eanticos, cada um com seus pr\u00f3prios discos. Tudo isso era unido por algum software sistema (hipervisor) e dividido em m\u00e1quinas virtuais. O objetivo principal era minimizar o esfor\u00e7o na manuten\u00e7\u00e3o de um \u00fanico n\u00f3 e minimizar os problemas de escalabilidade: simplesmente comprava-se mais mil ou duas mil de servidores semelhantes e conectava-se ao lado. Na pr\u00e1tica, isso \u00e9 uma exce\u00e7\u00e3o, e muito mais frequentemente fala-se de um n\u00famero menor de n\u00f3s e uma arquitetura um pouco diferente. <\/p>\n

Mas a vantagem continua a mesma \u2014 uma incr\u00edvel simplicidade de escalabilidade e gerenciamento. A desvantagem \u00e9 que diferentes tarefas consomem recursos de maneira diferente, e em alguns lugares haver\u00e1 muitos discos locais, em outros, pouca mem\u00f3ria operacional, e assim por diante, ou seja, dependendo do tipo de tarefas, a utiliza\u00e7\u00e3o dos recursos pode cair. <\/p>\n

Acontece que voc\u00ea paga de 10 a 15% a mais pelo conforto da configura\u00e7\u00e3o. Isso gerou o mito do t\u00edtulo. N\u00f3s procuramos muito onde a tecnologia poderia ser utilizada de forma ideal, e encontramos. O fato \u00e9 que a Cisco n\u00e3o tinha suas pr\u00f3prias solu\u00e7\u00f5es de armazenamento, mas queria todo o mercado de servidores. E eles desenvolveram o Cisco Hyperflex \u2014 uma solu\u00e7\u00e3o com armazenamento local nos n\u00f3s. <\/p>\n

E a partir disso, surgiu uma solu\u00e7\u00e3o muito boa para data centers de backup (Disaster Recovery). Por que e como \u2014 vou explicar agora. E vou mostrar os testes do cluster. <\/a><\/noindex><\/p>\n

Onde necess\u00e1rio<\/h3>\n

\nHiperconverg\u00eancia \u00e9: <\/p>\n

    \n
  1. Transfer\u00eancia de discos para n\u00f3s computacionais.<\/li>\n
  2. Integra\u00e7\u00e3o completa do subsistema de armazenamento de dados com o subsistema de virtualiza\u00e7\u00e3o.<\/li>\n
  3. Transfer\u00eancia\/integrac\u00e3o com o subsistema de rede.<\/li>\n<\/ol>\n

    \nEsse tipo de combina\u00e7\u00e3o permite implementar muitos recursos de armazenamento no n\u00edvel da virtualiza\u00e7\u00e3o, tudo a partir de uma \u00fanica interface de gerenciamento.<\/p>\n

    Na nossa empresa, projetos de design de data centers de backup s\u00e3o muito procurados, e frequentemente opta-se pela solu\u00e7\u00e3o hiperconvergente devido \u00e0 variedade de op\u00e7\u00f5es de replica\u00e7\u00e3o (inclusive at\u00e9 metroc\u00f3modos) prontamente dispon\u00edveis. <\/p>\n

    Nos casos de data centers de backup, geralmente se refere a um local remoto na cidade oposta ou at\u00e9 mesmo em outra cidade. Isso permite a recupera\u00e7\u00e3o de sistemas cr\u00edticos em caso de falha parcial ou total do data center principal. Dados s\u00e3o constantemente replicados do ambiente de produ\u00e7\u00e3o, e essa replica\u00e7\u00e3o pode ocorrer no n\u00edvel da aplica\u00e7\u00e3o ou no n\u00edvel do dispositivo de armazenamento (SDS).<\/p>\n

    Portanto, agora irei falar sobre a estrutura do sistema e os testes, e depois sobre alguns cen\u00e1rios de aplica\u00e7\u00e3o real com dados sobre economia. <\/p>\n

    Testes<\/h3>\n

    \nNossa configura\u00e7\u00e3o consiste em quatro servidores, cada um equipado com 10 discos SSD de 960 GB. H\u00e1 um disco dedicado para o cache de opera\u00e7\u00f5es de escrita e para armazenar a m\u00e1quina virtual de servi\u00e7o. A pr\u00f3pria solu\u00e7\u00e3o \u00e9 a quarta vers\u00e3o. A primeira era visivelmente inacabada (de acordo com o feedback), a segunda ainda era um pouco crua, a terceira j\u00e1 era bastante est\u00e1vel, e esta pode ser chamada de vers\u00e3o final ap\u00f3s o t\u00e9rmino dos testes beta para o p\u00fablico. Durante o per\u00edodo de teste, n\u00e3o encontrei problemas, tudo funciona como um rel\u00f3gio.<\/p>\n

    Mudan\u00e7as na v4<\/b>Um monte de bugs foi corrigido. <\/p>\n

    Inicialmente, a plataforma s\u00f3 funcionava com o hipervisor VMware ESXi e suportava um n\u00famero limitado de n\u00f3s. Al\u00e9m disso, o processo de implanta\u00e7\u00e3o nem sempre terminava com sucesso, precisando reiniciar algumas etapas, havia problemas na atualiza\u00e7\u00e3o de vers\u00f5es anteriores, e os dados na GUI nem sempre eram exibidos corretamente (embora ainda n\u00e3o esteja totalmente satisfeito com a exibi\u00e7\u00e3o dos gr\u00e1ficos de desempenho); \u00e0s vezes, surgiam problemas na interse\u00e7\u00e3o com a virtualiza\u00e7\u00e3o.<\/p>\n

    Agora todas as doen\u00e7as infantis foram corrigidas, o HyperFlex suporta tanto ESXi quanto Hyper-V, al\u00e9m disso, \u00e9 poss\u00edvel:<\/p>\n

      \n
    1. Criar um cluster estendido. <\/li>\n
    2. Criar um cluster para escrit\u00f3rios sem a necessidade de Fabric Interconnect, com de dois a quatro n\u00f3s (compramos apenas os servidores).<\/li>\n
    3. Trabalhar com SDS externos.<\/li>\n
    4. Suporte a cont\u00eaineres e Kubernetes.<\/li>\n
    5. Criar zonas de disponibilidade.<\/li>\n
    6. Integra\u00e7\u00e3o com VMware SRM, caso a funcionalidade embutida n\u00e3o seja satisfat\u00f3ria.<\/li>\n<\/ol>\n

      A arquitetura n\u00e3o difere muito das solu\u00e7\u00f5es dos principais concorrentes, n\u00e3o se reinventou a roda. Tudo isso opera na plataforma de virtualiza\u00e7\u00e3o VMware ou Hyper-V. O hardware est\u00e1 hospedado em servidores desenvolvidos pela pr\u00f3pria Cisco UCS. H\u00e1 quem odeie a plataforma devido \u00e0 relativa complexidade da configura\u00e7\u00e3o inicial, a multitude de bot\u00f5es, e um sistema de modelos e depend\u00eancias n\u00e3o triviais, mas h\u00e1 tamb\u00e9m quem tenha encontrado o zen, compreendido a ideia e n\u00e3o deseje mais trabalhar com outros servidores. <\/p>\n

      Vamos analisar especificamente a solu\u00e7\u00e3o para VMware, pois a solu\u00e7\u00e3o foi criada originalmente para ela e possui funcionalidades mais avan\u00e7adas, enquanto que a Hyper-V foi aprimorada ao longo do tempo para acompanhar a concorr\u00eancia e atender \u00e0s expectativas do mercado.<\/p>\n

      H\u00e1 um cluster de servidores equipados com discos. Existem discos para armazenamento de dados (SSD ou HDD \u2014 a sua escolha e necessidades), al\u00e9m de um disco SSD para cache. Ao gravar dados no datastore, os dados s\u00e3o armazenados na camada de cache (um disco SSD dedicado e RAM da VM de servi\u00e7o). Paralelamente, um bloco de dados \u00e9 enviado para os n\u00f3s do cluster (o n\u00famero de n\u00f3s depende do fator de replica\u00e7\u00e3o do cluster). Ap\u00f3s a confirma\u00e7\u00e3o de todos os n\u00f3s sobre a grava\u00e7\u00e3o bem-sucedida, a confirma\u00e7\u00e3o \u00e9 enviada ao hipervisor e, em seguida, \u00e0 VM. Os dados gravados s\u00e3o desduplicados, comprimidos e gravados nos discos de armazenamento em segundo plano. Nesse processo, grandes blocos s\u00e3o gravados sequencialmente nos discos de armazenamento, reduzindo a carga sobre eles.<\/p>\n

      A deduplica\u00e7\u00e3o e compress\u00e3o est\u00e3o sempre ativadas e n\u00e3o podem ser desativadas. A leitura de dados ocorre diretamente dos discos de armazenamento ou do cache da RAM. Se for utilizada uma configura\u00e7\u00e3o h\u00edbrida, a leitura tamb\u00e9m \u00e9 armazenada no disco SSD.<\/p>\n

      Os dados n\u00e3o est\u00e3o vinculados \u00e0 localiza\u00e7\u00e3o atual da m\u00e1quina virtual e s\u00e3o distribu\u00eddos uniformemente entre os n\u00f3s. Essa abordagem permite que todos os discos e interfaces de rede sejam igualmente carregados. Surge uma desvantagem \u00f3bvia: n\u00e3o conseguimos minimizar a lat\u00eancia de leitura, j\u00e1 que n\u00e3o h\u00e1 garantia de que os dados est\u00e3o localmente dispon\u00edveis. Mas considero que essa \u00e9 uma sacrif\u00edcio insignificante em compara\u00e7\u00e3o com os benef\u00edcios obtidos. Al\u00e9m disso, as lat\u00eancias na rede alcan\u00e7aram valores que praticamente n\u00e3o afetam o resultado geral.<\/p>\n

      Toda a l\u00f3gica de funcionamento do subsistema de disco \u00e9 gerida por uma m\u00e1quina virtual de servi\u00e7o especializada, o controlador Cisco HyperFlex Data Platform, que \u00e9 criada em cada n\u00f3 de armazenamento. Na nossa configura\u00e7\u00e3o, a m\u00e1quina virtual de servi\u00e7o foi alocada com oito vCPUs e 72 GB de RAM, o que n\u00e3o \u00e9 pouco. Lembro que o pr\u00f3prio host possui 28 n\u00facleos f\u00edsicos e 512 GB de RAM.<\/p>\n

      A m\u00e1quina virtual de servi\u00e7o tem acesso direto aos discos f\u00edsicos atrav\u00e9s do passthrough do controlador SAS na VM. A comunica\u00e7\u00e3o com o hipervisor ocorre atrav\u00e9s de um m\u00f3dulo especial chamado IOVisor, que intercepta opera\u00e7\u00f5es de entrada e sa\u00edda, e com um agente que permite enviar comandos para a API do hipervisor. O agente \u00e9 respons\u00e1vel pelo trabalho com snapshots e clones do HyperFlex.<\/p>\n

      No hipervisor, os recursos de disco s\u00e3o montados como compartilhamentos NFS ou SMB (dependendo do tipo de hipervisor, adivinhe qual \u00e9 onde). E, por tr\u00e1s disso, est\u00e1 um sistema de arquivos distribu\u00eddo, que permite adicionar funcionalidades de storage avan\u00e7adas: provisionamento fino de volumes, compress\u00e3o e deduplica\u00e7\u00e3o, snapshots utilizando a tecnologia Redirect-on-Write, replica\u00e7\u00e3o s\u00edncrona\/ass\u00edncrona.<\/p>\n

      A m\u00e1quina virtual de servi\u00e7o fornece acesso \u00e0 interface web de gerenciamento do subsistema HyperFlex. Existe integra\u00e7\u00e3o com o vCenter, e a maior parte das tarefas do dia a dia pode ser executada a partir dele, mas as datastores, por exemplo, s\u00e3o mais facilmente configuradas a partir de uma interface web separada, se voc\u00ea j\u00e1 mudou para a r\u00e1pida interface HTML5, ou pode usar o cliente Flash completo com integra\u00e7\u00e3o total. Na interface web de servi\u00e7o, voc\u00ea pode ver o desempenho e o status detalhado do sistema.<\/p>\n

      \"Admin
      \n
      \nExiste tamb\u00e9m outro tipo de n\u00f3 no cluster \u2014 n\u00f3s de computa\u00e7\u00e3o. Estes podem ser servidores em rack ou blade sem discos embutidos. Nestes servidores, \u00e9 poss\u00edvel iniciar VMs cujos dados s\u00e3o armazenados em servidores com discos. Em termos de acesso a dados, n\u00e3o h\u00e1 diferen\u00e7a entre os tipos de n\u00f3s, pois a arquitetura implica uma abstra\u00e7\u00e3o da localiza\u00e7\u00e3o f\u00edsica dos dados. A m\u00e1xima propor\u00e7\u00e3o de n\u00f3s de computa\u00e7\u00e3o para n\u00f3s de armazenamento \u00e9 de 2:1.<\/p>\n

      O uso de n\u00f3s de computa\u00e7\u00e3o aumenta a flexibilidade ao escalar recursos do cluster: n\u00e3o precisamos necessariamente comprar n\u00f3s com discos, se a nossa necessidade \u00e9 apenas de CPU\/RAM. Al\u00e9m disso, podemos adicionar uma blade chassis e obter economia em coloca\u00e7\u00e3o de servidores no rack.<\/p>\n

      Como resultado, temos uma plataforma hiperconvergente com as seguintes caracter\u00edsticas:<\/p>\n