{"id":96767,"date":"2020-10-14T14:43:02","date_gmt":"2020-10-14T12:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam"},"modified":"2020-10-14T14:43:02","modified_gmt":"2020-10-14T12:43:02","slug":"hystax-cloud-migration-skachem-po-oblakam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/hystax-cloud-migration-skachem-po-oblakam","title":{"rendered":"Hystax Cloud Migration: navegando nas nuvens","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Uma das novas empresas no mercado de solu\u00e7\u00f5es de Recupera\u00e7\u00e3o de Desastres \u00e9 a Hystax \u2013 uma startup russa fundada em 2016. Como o tema da recupera\u00e7\u00e3o de desastres \u00e9 muito popular e h\u00e1 uma competi\u00e7\u00e3o extrema no mercado, a startup decidiu se concentrar na migra\u00e7\u00e3o entre diferentes infraestruturas de nuvem. Um produto que possibilite uma migra\u00e7\u00e3o simples e r\u00e1pida para a nuvem seria muito \u00fatil tamb\u00e9m para os clientes da empresa \"Onlanta\" \u2014 usu\u00e1rios. Oncloud.ru<\/a><\/noindex>. Assim conheci a Hystax e comecei a testar suas capacidades. O que resultou disso, contarei neste artigo.<\/p>\n

\"Hystax<\/a><\/noindex>
\nO principal diferencial da Hystax \u00e9 sua ampla funcionalidade no suporte a diferentes plataformas de virtualiza\u00e7\u00e3o, sistemas operacionais convidados e servi\u00e7os em nuvem, o que permite transferir suas cargas de trabalho de qualquer lugar para qualquer lugar.<\/p>\n

Isso possibilita criar n\u00e3o apenas solu\u00e7\u00f5es de DR para aumentar a resili\u00eancia dos servi\u00e7os, mas tamb\u00e9m migrar recursos de maneira \u00e1gil e flex\u00edvel entre diversas plataformas e hyperscalers, buscando a economia de recursos e a melhor solu\u00e7\u00e3o para um servi\u00e7o espec\u00edfico em um determinado momento. Al\u00e9m das plataformas mencionadas na imagem de cabe\u00e7alho, a empresa tamb\u00e9m colabora ativamente com provedores de nuvem russos: Yandex.Cloud, \u041a\u0420\u041e\u041a \"\u041e\u0431\u043b\u0430\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b\", Mail.ru e muitos outros. Tamb\u00e9m vale ressaltar que, em 2020, a empresa estabeleceu um centro de P&D localizado em Skolkovo.\u00a0<\/p>\n

A escolha de uma \u00fanica solu\u00e7\u00e3o por muitos jogadores no mercado indica uma boa pol\u00edtica de pre\u00e7os e alta aplicabilidade do produto, o que decidimos verificar na pr\u00e1tica.<\/p>\n

Assim, nossa tarefa de teste consistir\u00e1 na migra\u00e7\u00e3o da minha plataforma de teste VMware e de m\u00e1quinas f\u00edsicas para a plataforma do provedor, tamb\u00e9m sob gest\u00e3o da VMware. Sim, existem muitas solu\u00e7\u00f5es que podem realizar essa migra\u00e7\u00e3o, mas consideramos a Hystax como uma ferramenta universal, e testar a migra\u00e7\u00e3o em todas as combina\u00e7\u00f5es poss\u00edveis \u00e9 uma tarefa praticamente irreal. Al\u00e9m disso, a nuvem Oncloud.ru \u00e9 constru\u00edda precisamente sobre a VMware, portanto, essa plataforma como alvo nos interessa mais. A seguir, descreverei o princ\u00edpio b\u00e1sico de funcionamento, que em geral n\u00e3o depende da plataforma, e VMware de qualquer maneira pode ser substitu\u00edda por uma plataforma de outro fornecedor.\u00a0<\/p>\n

Na primeira etapa, \u00e9 necess\u00e1rio implementar o Hystax Acura, que \u00e9 o painel de controle do sistema.<\/p>\n

\"Hystax<\/a><\/noindex>
\nEle \u00e9 implantado a partir de um modelo. Por algum motivo, no nosso caso, ele n\u00e3o foi totalmente correto e, em vez dos recomendados 8CPU, 16Gb, foi implantado com recursos duas vezes menores. Portanto, \u00e9 importante n\u00e3o esquecer de alter\u00e1-los, caso contr\u00e1rio, a infraestrutura baseada em cont\u00eaineres dentro da VM, na qual tudo foi constru\u00eddo, simplesmente n\u00e3o iniciar\u00e1 e o portal ficar\u00e1 inacess\u00edvel. No Requisitos de implementa\u00e7\u00e3o<\/a><\/noindex> s\u00e3o descritos detalhadamente os recursos necess\u00e1rios, bem como as portas para todos os componentes do sistema.\u00a0<\/p>\n

E tamb\u00e9m houve dificuldades na atribui\u00e7\u00e3o do endere\u00e7o IP atrav\u00e9s do modelo, ent\u00e3o n\u00f3s o alteramos pela console. Depois disso, \u00e9 poss\u00edvel ir para a interface web de administra\u00e7\u00e3o e preencher o assistente inicial de configura\u00e7\u00e3o.\u00a0<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nEndpoint \u2013 IP ou FQDN do nosso vCenter.\u00a0
\nLogin e Senha \u2013 aqui est\u00e1 claro.\u00a0
\nHostname do ESXi de destino \u2013 um dos hosts do nosso cluster, para o qual a replica\u00e7\u00e3o ser\u00e1 realizada.\u00a0
\nDatastore de destino \u2013 um dos datastores do nosso cluster, para o qual a replica\u00e7\u00e3o ser\u00e1 realizada.
\nIP P\u00fablico do Painel de Controle Hystax Acura \u2013 o endere\u00e7o pelo qual o painel de controle estar\u00e1 acess\u00edvel.<\/p>\n

\u00c9 necess\u00e1ria uma pequena especifica\u00e7\u00e3o sobre o host e o datastore. O fato \u00e9 que a replica\u00e7\u00e3o do Hystax opera no n\u00edvel do host e do datastore. Depois, eu explicarei como mudar o host e o datastore para o tenant, mas o problema \u00e9 outro. O Hystax n\u00e3o suporta opera\u00e7\u00e3o com pools de recursos, ou seja, a replica\u00e7\u00e3o sempre ocorrer\u00e1 na raiz do cluster (no momento da reda\u00e7\u00e3o deste material, a equipe do Hystax lan\u00e7ou uma vers\u00e3o atualizada, onde rapidamente implementaram minha solicita\u00e7\u00e3o de recurso sobre o suporte a pools de recursos). Tamb\u00e9m n\u00e3o \u00e9 suportado o vCloud Director, ou seja, se, como no meu caso, o tenant n\u00e3o tiver direitos administrativos sobre todo o cluster, mas apenas sobre um pool de recursos espec\u00edfico, e n\u00f3s tivermos concedido acesso ao Hystax, ent\u00e3o ele poder\u00e1 replicar e iniciar essas VMs autonomamente, mas n\u00e3o conseguir\u00e1 v\u00ea-las na infraestrutura VMware \u00e0 qual tem acesso e, consequentemente, gerenci\u00e1-las. \u00c9 necess\u00e1rio que o administrador do cluster mova a VM para o pool de recursos necess\u00e1rio ou a importe para o vCloud Director.<\/p>\n

Por que eu enfatizo tanto esses pontos? Porque, pelo que entendi do conceito do produto, o cliente deve ter a capacidade de realizar qualquer migra\u00e7\u00e3o ou DR por conta pr\u00f3pria utilizando o painel Acura. Mas, at\u00e9 agora, o suporte ao VMware est\u00e1 um pouco atr\u00e1s do suporte do OpenStack, onde mecanismos semelhantes j\u00e1 foram implementados.\u00a0<\/p>\n

Mas voltemos \u00e0 implementa\u00e7\u00e3o. Primeiro, ap\u00f3s a configura\u00e7\u00e3o inicial do painel, precisamos criar o primeiro tenant em nosso sistema.<\/p>\n

\"Hystax<\/a><\/noindex>
\nTodos os campos aqui s\u00e3o claros; vou falar apenas sobre o campo Cloud. J\u00e1 temos uma \"nuvem padr\u00e3o\" que criamos durante a configura\u00e7\u00e3o inicial. Mas se quisermos ter a possibilidade de alocar cada tenant em seu pr\u00f3prio datastore e em seu pool de recursos, podemos realizar isso criando nuvens separadas para cada um de nossos clientes.<\/p>\n

\"Hystax<\/a><\/noindex>
\nNo formul\u00e1rio de adi\u00e7\u00e3o de uma nova nuvem, indicamos os mesmos par\u00e2metros que na configura\u00e7\u00e3o inicial (podemos at\u00e9 usar o mesmo host), especificamos o datastore necess\u00e1rio para o cliente em quest\u00e3o, e agora, nas configura\u00e7\u00f5es adicionais, podemos individualmente indicar o pool de recursos necess\u00e1rio {\"resource_pool\": \"YOUR_POOL_NAME\"}\u00a0<\/p>\n

Como voc\u00ea pode notar, no formul\u00e1rio de cria\u00e7\u00e3o do tenant n\u00e3o h\u00e1 nada sobre aloca\u00e7\u00e3o de recursos ou quaisquer quotas \u2013 isso n\u00e3o existe no sistema. N\u00e3o \u00e9 poss\u00edvel limitar um tenant em n\u00famero de r\u00e9plicas simult\u00e2neas, n\u00famero de m\u00e1quinas para replica\u00e7\u00e3o ou por quaisquer outros par\u00e2metros. Assim, criamos o primeiro tenant. Agora, h\u00e1 uma coisa que n\u00e3o \u00e9 muito l\u00f3gica, mas \u00e9 obrigat\u00f3ria \u2013 a instala\u00e7\u00e3o do agente Cloud. Ela n\u00e3o \u00e9 l\u00f3gica porque o agente \u00e9 baixado na p\u00e1gina de um cliente espec\u00edfico.<\/p>\n

\"Hystax<\/a><\/noindex>
\nNesse caso, ele n\u00e3o est\u00e1 vinculado ao tenant criado, e atrav\u00e9s dele todos os nossos clientes (ou v\u00e1rios, caso os implantemos) ir\u00e3o operar. Um agente suporta 10 sess\u00f5es simult\u00e2neas. Uma sess\u00e3o conta como uma m\u00e1quina. N\u00e3o importa quantos discos ela possui. At\u00e9 o momento, n\u00e3o h\u00e1 um mecanismo para escalar agentes dentro da Acura via VMware. H\u00e1 tamb\u00e9m um ponto negativo \u2013 n\u00e3o temos a capacidade de ver a \"utiliza\u00e7\u00e3o\" desse agente a partir do painel da Acura, para concluir se precisamos implantar mais ou se a instala\u00e7\u00e3o atual \u00e9 suficiente. No final, o stand se apresenta da seguinte forma:<\/p>\n

\"Hystax<\/a><\/noindex>
\nA pr\u00f3xima etapa para acessar o portal do nosso cliente \u00e9 criar uma conta (e previamente uma fun\u00e7\u00e3o que ser\u00e1 aplicada a esse usu\u00e1rio).<\/p>\n

\"Hystax<\/a><\/noindex>
\n\"Hystax<\/a><\/noindex>
\nAgora nosso cliente pode usar o portal de forma aut\u00f4noma. Tudo o que ele precisa fazer \u00e9 baixar os agentes do portal e instalar do seu lado. Existem tr\u00eas tipos de agentes: Linux, Windows e VMware.<\/p>\n

\"Hystax<\/a><\/noindex>
\nOs dois primeiros s\u00e3o instalados em m\u00e1quinas f\u00edsicas ou em m\u00e1quinas virtuais em qualquer hipervisor, exceto o VMware. Aqui n\u00e3o \u00e9 necess\u00e1rio configurar nada adicional, o agente \u00e9 baixado e j\u00e1 sabe para onde se conectar, e em quest\u00e3o de um minuto a m\u00e1quina aparecer\u00e1 no painel da Acura. Com o agente VMware a situa\u00e7\u00e3o \u00e9 um pouco mais complexa. O problema \u00e9 que o agente para VMware tamb\u00e9m \u00e9 baixado do portal j\u00e1 preparado e com a configura\u00e7\u00e3o necess\u00e1ria. Mas o agente VMware, al\u00e9m de conhecer o nosso portal da Acura, tamb\u00e9m precisa saber sobre o sistema de virtualiza\u00e7\u00e3o no qual ser\u00e1 implantado.<\/p>\n

\"Hystax<\/a><\/noindex>
\nNa verdade, esses dados o sistema solicitar\u00e1 que indiquemos ao baixar o agente VMware pela primeira vez. O problema \u00e9 que, na nossa era de seguran\u00e7a abrangente, nem todos estar\u00e3o dispostos a fornecer sua senha de administrador em um portal de terceiros, o que \u00e9 perfeitamente compreens\u00edvel. Internamente, ap\u00f3s a implanta\u00e7\u00e3o, o agente n\u00e3o pode ser configurado de outra forma (apenas suas configura\u00e7\u00f5es de rede podem ser alteradas). Aqui prevejo dificuldades com clientes especialmente cautelosos.\u00a0<\/p>\n

Assim, ap\u00f3s a instala\u00e7\u00e3o dos agentes, podemos voltar ao painel da Acura e ver todas as nossas m\u00e1quinas.<\/p>\n

\"Hystax<\/a><\/noindex>
\nComo j\u00e1 trabalho h\u00e1 algum tempo com o sistema, tenho m\u00e1quinas em v\u00e1rios estados. Todas est\u00e3o no grupo Default, mas existe a op\u00e7\u00e3o de criar grupos separados e transferir as m\u00e1quinas conforme sua necessidade. Isso n\u00e3o afeta nada \u2013 \u00e9 apenas uma representa\u00e7\u00e3o l\u00f3gica dos dados e uma organiza\u00e7\u00e3o para facilitar o trabalho. A primeira e mais importante coisa que precisamos fazer depois disso \u00e9 iniciar o processo de migra\u00e7\u00e3o. Podemos fazer isso manualmente, de forma for\u00e7ada, ou configurar um cronograma, inclusive em massa para todas as m\u00e1quinas de uma vez.<\/p>\n

\"Hystax<\/a><\/noindex>
\nLembro que a Hystax se posicionava como um produto para migra\u00e7\u00e3o. Portanto, n\u00e3o \u00e9 surpreendente que, para iniciar nossas m\u00e1quinas replicadas, precisamos criar um plano de DR. O plano pode ser elaborado para m\u00e1quinas que j\u00e1 est\u00e3o no estado Synced. Podemos gerar para uma VM espec\u00edfica ou para todas as m\u00e1quinas de uma vez.<\/p>\n

\"Hystax<\/a><\/noindex>
\nO conjunto de par\u00e2metros na gera\u00e7\u00e3o do plano de DR varia dependendo da infraestrutura para a qual voc\u00ea est\u00e1 migrando. Para o ambiente VMware, est\u00e1 dispon\u00edvel um conjunto m\u00ednimo de par\u00e2metros. A op\u00e7\u00e3o Re-IP n\u00e3o \u00e9 suportada para as m\u00e1quinas. Neste plano, estamos interessados nos seguintes pontos: na descri\u00e7\u00e3o da VM, o par\u00e2metro 'subnet': 'VMNetwork', onde vinculamos a VM a uma rede espec\u00edfica no cluster. Rank \u2013 relevante ao migrar v\u00e1rias VMs, determina a ordem de inicializa\u00e7\u00e3o. Flavor \u2013 descreve a configura\u00e7\u00e3o da VM, neste caso \u2013 1CPU, 2GB RAM. Na se\u00e7\u00e3o de subnets, definimos que 'subnet': 'VMNetwork' est\u00e1 associado \u00e0 rede 'VM Network' do VMware.\u00a0<\/p>\n

Ao criar o plano de DR, n\u00e3o h\u00e1 como 'distribuir' os discos por diferentes datastores. Eles permanecer\u00e3o no mesmo datastore que foi definido para esta nuvem do cliente e, se voc\u00ea tiver discos de diferentes classes, isso pode causar algumas dificuldades ao iniciar a m\u00e1quina, e ap\u00f3s a inicializa\u00e7\u00e3o e 'desconex\u00e3o' da VM da Hystax, exigir\u00e1 tamb\u00e9m uma migra\u00e7\u00e3o separada dos discos para os datastores apropriados. Depois, s\u00f3 resta iniciar nosso plano de DR e aguardar que nossas m\u00e1quinas sejam ativadas. O processo de convers\u00e3o P2V\/V2V tamb\u00e9m leva tempo. Na minha maior m\u00e1quina de teste de 100 GB com tr\u00eas discos, isso levou no m\u00e1ximo 10 minutos.<\/p>\n

\"Hystax<\/a><\/noindex>
\nDepois disso, \u00e9 importante verificar a VM em execu\u00e7\u00e3o, os servi\u00e7os nela, a consist\u00eancia dos dados e realizar outras verifica\u00e7\u00f5es.\u00a0<\/p>\n

Em seguida, temos dois caminhos:\u00a0<\/p>\n

    \n
  1. Excluir \u2013 par\u00e1 um plano DR em execu\u00e7\u00e3o. Esta a\u00e7\u00e3o simplesmente desativar\u00e1 a VM em execu\u00e7\u00e3o. Os dados da r\u00e9plica n\u00e3o ser\u00e3o perdidos.\u00a0<\/li>\n
  2. Desanexar \u2013 separar a m\u00e1quina replicada do Acura, ou seja, concluir efetivamente o processo de migra\u00e7\u00e3o.\u00a0<\/li>\n<\/ol>\n

    \nVantagens da solu\u00e7\u00e3o:<\/strong>\u00a0<\/p>\n