Uma das jovens empresas no mercado de soluções de Disaster Recovery é a Hystax – uma startup russa de 2016. Como o tema de recuperação de desastres é muito popular e a concorrência no mercado é extremamente alta, a startup decidiu focar na migração entre diferentes infraestruturas em nuvem. Um produto que permite organizar uma migração simples e rápida para a nuvem seria muito útil também para os clientes da empresa "Onlanta" — usuários . Assim conheci a Hystax e comecei a testar suas capacidades. O que resultou disso, contarei neste artigo.
O principal diferencial da Hystax é sua ampla funcionalidade no suporte a diferentes plataformas de virtualização, sistemas operacionais convidados e serviços em nuvem, o que permite transferir suas cargas de trabalho de qualquer lugar para qualquer lugar.
Isso possibilita criar não apenas soluções de DR para aumentar a resiliência dos serviços, mas também migrar recursos de maneira ágil e flexível entre diversas plataformas e hyperscalers, buscando a economia de recursos e a melhor solução para um serviço específico em um determinado momento. Além das plataformas mencionadas na imagem de cabeçalho, a empresa também colabora ativamente com provedores de nuvem russos: Yandex.Cloud, КРОК "Облачные сервисы", Mail.ru e muitos outros. Também vale ressaltar que, em 2020, a empresa estabeleceu um centro de P&D localizado em Skolkovo.
A escolha de uma única solução por muitos jogadores no mercado indica uma boa política de preços e alta aplicabilidade do produto, o que decidimos verificar na prática.
Assim, nossa tarefa de teste consistirá na migração da minha plataforma de teste VMware e de máquinas físicas para a plataforma do provedor, também sob gestão da VMware. Sim, existem muitas soluções que podem realizar essa migração, mas consideramos a Hystax como uma ferramenta universal, e testar a migração em todas as combinações possíveis é uma tarefa praticamente irreal. Além disso, a nuvem Oncloud.ru é construída precisamente sobre a VMware, portanto, essa plataforma como alvo nos interessa mais. A seguir, descreverei o princípio básico de funcionamento, que em geral não depende da plataforma, e VMware de qualquer maneira pode ser substituída por uma plataforma de outro fornecedor.
Na primeira etapa, é necessário implementar o Hystax Acura, que é o painel de controle do sistema.
Ele é implantado a partir de um modelo. Por algum motivo, no nosso caso, ele não foi totalmente correto e, em vez dos recomendados 8CPU, 16Gb, foi implantado com recursos duas vezes menores. Portanto, é importante não esquecer de alterá-los, caso contrário, a infraestrutura baseada em contêineres dentro da VM, na qual tudo foi construído, simplesmente não iniciará e o portal ficará inacessível. No são descritos detalhadamente os recursos necessários, bem como as portas para todos os componentes do sistema.
E também houve dificuldades na atribuição do endereço IP através do modelo, então nós o alteramos pela console. Depois disso, é possível ir para a interface web de administração e preencher o assistente inicial de configuração.
Endpoint – IP ou FQDN do nosso vCenter.
Login e Senha – aqui está claro.
Hostname do ESXi de destino – um dos hosts do nosso cluster, para o qual a replicação será realizada.
Datastore de destino – um dos datastores do nosso cluster, para o qual a replicação será realizada.
IP Público do Painel de Controle Hystax Acura – o endereço pelo qual o painel de controle estará acessível.
É necessária uma pequena especificação sobre o host e o datastore. O fato é que a replicação do Hystax opera no nível do host e do datastore. Depois, eu explicarei como mudar o host e o datastore para o tenant, mas o problema é outro. O Hystax não suporta operação com pools de recursos, ou seja, a replicação sempre ocorrerá na raiz do cluster (no momento da redação deste material, a equipe do Hystax lançou uma versão atualizada, onde rapidamente implementaram minha solicitação de recurso sobre o suporte a pools de recursos). Também não é suportado o vCloud Director, ou seja, se, como no meu caso, o tenant não tiver direitos administrativos sobre todo o cluster, mas apenas sobre um pool de recursos específico, e nós tivermos concedido acesso ao Hystax, então ele poderá replicar e iniciar essas VMs autonomamente, mas não conseguirá vê-las na infraestrutura VMware à qual tem acesso e, consequentemente, gerenciá-las. É necessário que o administrador do cluster mova a VM para o pool de recursos necessário ou a importe para o vCloud Director.
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ção ou DR por conta própria utilizando o painel Acura. Mas, até agora, o suporte ao VMware está um pouco atrás do suporte do OpenStack, onde mecanismos semelhantes já foram implementados.
Mas voltemos à implementação. Primeiro, após a configuração inicial do painel, precisamos criar o primeiro tenant em nosso sistema.
Todos os campos aqui são claros; vou falar apenas sobre o campo Cloud. Já temos uma "nuvem padrão" que criamos durante a configuração inicial. Mas se quisermos ter a possibilidade de alocar cada tenant em seu próprio datastore e em seu pool de recursos, podemos realizar isso criando nuvens separadas para cada um de nossos clientes.
No formulário de adição de uma nova nuvem, indicamos os mesmos parâmetros que na configuração inicial (podemos até usar o mesmo host), especificamos o datastore necessário para o cliente em questão, e agora, nas configurações adicionais, podemos individualmente indicar o pool de recursos necessário {"resource_pool": "YOUR_POOL_NAME"}
Como você pode notar, no formulário de criação do tenant não há nada sobre alocação de recursos ou quaisquer quotas – isso não existe no sistema. Não é possível limitar um tenant em número de réplicas simultâneas, número de máquinas para replicação ou por quaisquer outros parâmetros. Assim, criamos o primeiro tenant. Agora, há uma coisa que não é muito lógica, mas é obrigatória – a instalação do agente Cloud. Ela não é lógica porque o agente é baixado na página de um cliente específico.
Nesse caso, ele não está vinculado ao tenant criado, e através dele todos os nossos clientes (ou vários, caso os implantemos) irão operar. Um agente suporta 10 sessões simultâneas. Uma sessão conta como uma máquina. Não importa quantos discos ela possui. Até o momento, não há um mecanismo para escalar agentes dentro da Acura via VMware. Há também um ponto negativo – não temos a capacidade de ver a "utilização" desse agente a partir do painel da Acura, para concluir se precisamos implantar mais ou se a instalação atual é suficiente. No final, o stand se apresenta da seguinte forma:
A próxima etapa para acessar o portal do nosso cliente é criar uma conta (e previamente uma função que será aplicada a esse usuário).
Agora nosso cliente pode usar o portal de forma autônoma. Tudo o que ele precisa fazer é baixar os agentes do portal e instalar do seu lado. Existem três tipos de agentes: Linux, Windows e VMware.
Os dois primeiros são instalados em máquinas físicas ou em máquinas virtuais em qualquer hipervisor, exceto o VMware. Aqui não é necessário configurar nada adicional, o agente é baixado e já sabe para onde se conectar, e em questão de um minuto a máquina aparecerá no painel da Acura. Com o agente VMware a situação é um pouco mais complexa. O problema é que o agente para VMware também é baixado do portal já preparado e com a configuração necessária. Mas o agente VMware, além de conhecer o nosso portal da Acura, também precisa saber sobre o sistema de virtualização no qual será implantado.
Na verdade, esses dados o sistema solicitará que indiquemos ao baixar o agente VMware pela primeira vez. O problema é que, na nossa era de segurança abrangente, nem todos estarão dispostos a fornecer sua senha de administrador em um portal de terceiros, o que é perfeitamente compreensível. Internamente, após a implantação, o agente não pode ser configurado de outra forma (apenas suas configurações de rede podem ser alteradas). Aqui prevejo dificuldades com clientes especialmente cautelosos.
Assim, após a instalação dos agentes, podemos voltar ao painel da Acura e ver todas as nossas máquinas.
Como já trabalho há algum tempo com o sistema, tenho máquinas em vários estados. Todas estão no grupo Default, mas existe a opção de criar grupos separados e transferir as máquinas conforme sua necessidade. Isso não afeta nada – é apenas uma representação lógica dos dados e uma organização para facilitar o trabalho. A primeira e mais importante coisa que precisamos fazer depois disso é iniciar o processo de migração. Podemos fazer isso manualmente, de forma forçada, ou configurar um cronograma, inclusive em massa para todas as máquinas de uma vez.
Lembro que a Hystax se posicionava como um produto para migração. Portanto, não é surpreendente que, para iniciar nossas máquinas replicadas, precisamos criar um plano de DR. O plano pode ser elaborado para máquinas que já estão no estado Synced. Podemos gerar para uma VM específica ou para todas as máquinas de uma vez.
O conjunto de parâmetros na geração do plano de DR varia dependendo da infraestrutura para a qual você está migrando. Para o ambiente VMware, está disponível um conjunto mínimo de parâmetros. A opção Re-IP não é suportada para as máquinas. Neste plano, estamos interessados nos seguintes pontos: na descrição da VM, o parâmetro 'subnet': 'VMNetwork', onde vinculamos a VM a uma rede específica no cluster. Rank – relevante ao migrar várias VMs, determina a ordem de inicialização. Flavor – descreve a configuração da VM, neste caso – 1CPU, 2GB RAM. Na seção de subnets, definimos que 'subnet': 'VMNetwork' está associado à rede 'VM Network' do VMware.
Ao criar o plano de DR, não há como 'distribuir' os discos por diferentes datastores. Eles permanecerão no mesmo datastore que foi definido para esta nuvem do cliente e, se você tiver discos de diferentes classes, isso pode causar algumas dificuldades ao iniciar a máquina, e após a inicialização e 'desconexão' da VM da Hystax, exigirá também uma migração separada dos discos para os datastores apropriados. Depois, só resta iniciar nosso plano de DR e aguardar que nossas máquinas sejam ativadas. O processo de conversão P2V/V2V também leva tempo. Na minha maior máquina de teste de 100 GB com três discos, isso levou no máximo 10 minutos.
Depois disso, é importante verificar a VM em execução, os serviços nela, a consistência dos dados e realizar outras verificações.
Em seguida, temos dois caminhos:
- Excluir – pará um plano DR em execução. Esta ação simplesmente desativará a VM em execução. Os dados da réplica não serão perdidos.
- Desanexar – separar a máquina replicada do Acura, ou seja, concluir efetivamente o processo de migração.
Vantagens da solução:
- facilidade de instalação e configuração tanto do lado do cliente quanto do provedor;
- facilidade na configuração da migração, criação do plano DR e execução de réplicas;
- o suporte e os desenvolvedores respondem rapidamente a problemas identificados e os resolvem por meio de atualizações da plataforma ou agentes.
Desvantagens
- Suporte insuficiente para VMware.
- Ausência de qualquer tipo de controle para inquilinos por parte da plataforma.
Também elaborei uma Solicitação de Funcionalidade que enviamos ao fornecedor:
- monitoramento do uso e implantação do console de gerenciamento do Acura para agentes de nuvem;
- existência de cotas para inquilinos;
- capacidade de limitar o número de replicações simultâneas e a velocidade para cada inquilino;
- suporte para VMware vCloud Director;
- suporte para pools de recursos (implementado durante os testes);
- capacidade de configurar o agente VMware do lado do próprio agente, sem inserir credenciais da infraestrutura do cliente no painel do Acura;
- «visualização» do processo de inicialização da VM ao iniciar o plano DR.
A única coisa que achei bastante problemática foi a documentação. Não sou fã de "caixas pretas" e prefiro ter documentação detalhada sobre como o produto funciona internamente. E se para AWS e OpenStack o produto é descrito de forma mais ou menos clara, para VMware há uma documentação extremamente escassa.
Há um Guia de Instalação que descreve apenas a implantação do painel Acura, e onde não há uma palavra sobre a necessidade do agente de nuvem. Existe um conjunto completo de especificações do produto, o que é bom. Existe documentação que descreve a configuração "do começo ao fim" usando exemplos de AWS e OpenStack (embora isso mais pareça um post de blog), e uma Base de Conhecimento muito pequena.
De maneira geral, este não é exatamente o formato de documentação ao qual estou acostumado, digamos, de fornecedores maiores, então não me senti completamente à vontade. Ao mesmo tempo, não consegui encontrar respostas para algumas nuances do funcionamento do sistema "internamente" nesta documentação – muitas dúvidas precisavam ser esclarecidas com o suporte técnico, o que atrasou bastante o processo de implantação do ambiente e a realização de testes.
Em resumo, posso dizer que, no geral, gostei do produto e da abordagem da empresa na execução da tarefa. Sim, há falhas, e há uma deficiência crítica de funcionalidade (em relação ao VMware). É evidente que, antes de tudo, a empresa se orienta para nuvens públicas, em particular a AWS, e para alguns, isso pode ser suficiente. A presença de um produto tão simples e conveniente hoje, quando muitas empresas optam pela estratégia de múltiplas nuvens, é extremamente importante. Considerando o preço muito mais baixo em comparação com os concorrentes, isso torna o produto altamente atraente.
Estamos procurando um . Pode ser que você seja a pessoa certa?
Fonte: habr.com
