Compartilhar via

Migração do SAP HANA em Instância Grande do Azure para máquinas virtuais do Azure

  • Artigo

Este artigo descreve os possíveis cenários de implantação de uma Instância Grande do Azure e oferece uma abordagem de planejamento e migração com tempo de inatividade de transição minimizado.

Visão geral

O HLI (SAP HANA em Instâncias Grandes do Azure) foi anunciado pela primeira vez em setembro de 2016. Desde então, muitas pessoas adotaram esse hardware como serviço para as respectivas plataformas de computação na memória. Ainda assim, nos últimos anos, a extensão de tamanho de VM (máquina virtual) do Azure e o suporte da implantação escalável do HANA excederam a demanda de capacidade de banco de dados ERP da maioria dos clientes corporativos. Muitos estão expressando um interesse em migrar a carga de trabalho do SAP HANA de servidores físicos para VMs do Azure.

Este artigo não é um documento de configuração passo a passo. Ele descreve os modelos comuns de implantação e oferece recomendações de planejamento e migração. Nossa intenção é destacar as considerações necessárias sobre a preparação para minimizar o tempo de inatividade da transição.

Suposições

Este artigo pressupõe o seguinte:

  • Vamos considerar apenas uma migração homogênea do serviço de computação de banco de dados do HANA do HLI (HANA em Instâncias Grandes) para a VM do Azure sem nenhuma atualização significativa de software nem de aplicação de patch. Essas atualizações secundárias incluem o uso de uma versão mais recente do sistema operacional ou da versão do HANA explicitamente indicada, conforme apoiado nas notas SAP relevantes.
  • Você realizará todas as atividades de atualizações antes ou depois da migração. Por exemplo, SAP HANA MCOS convertendo para a implantação MDC.
  • A abordagem de migração que oferece o menor tempo de inatividade é a Replicação de Sistema do SAP HANA. Outros métodos de migração não fazem parte do escopo deste documento.
  • Essas diretrizes são aplicáveis para as SKUs Rev3 e Rev4 do HLI.
  • A arquitetura de implantação do HANA permanece inalterada principalmente durante a migração. Ou seja, um sistema com uma só instância de DR (recuperação de desastre) permanecerá igual no destino.
  • Você examinou e entendeu o SLA (Contrato de Nível de Serviço) da arquitetura de destino (futura).
  • Os termos comerciais entre HLIs e VMs são diferentes. Monitore o uso das suas VMs quanto ao gerenciamento de custos.
  • Você entende que o HLI é uma plataforma de computação dedicada, enquanto as VMs são executadas na infraestrutura compartilhada, mas isolada.
  • Você confirmou se as VMs de destino dão suporte à arquitetura pretendida. Para obter uma lista dos SKUs de VM compatíveis e certificados para a implantação do SAP HANA, confira o Diretório de hardware do SAP HANA.
  • Você validou o plano de design e migração.
  • Planeje a VM de recuperação de desastre junto com o site primário. Não é possível usar o HLI como o nó de DR para o site primário em execução nas VMs após a migração.
  • Você copiou os arquivos de backup necessários para as VMs de destino, com base nos requisitos de conformidade e capacidade de recuperação dos negócios. Com os backups acessíveis da VM, é possível a recuperação pontual durante o período de transição.
  • Para obter HA (alta disponibilidade) da HSR (Replicação de Sistema do SAP HANA), você precisa configurar o dispositivo de isolamento de acordo com os guias de HA do SAP HANA para o SLES e o RHEL. Não é pré-configurado como o caso de HLI.
  • Essa abordagem de migração não abrange as SKUs de HLI com a configuração de Optane.

Cenários de implantação

Você pode fazer a migração para VMs do Azure em todos os cenários do HLI. Os modelos comuns de implantação para o HLI são resumidos na tabela a seguir. Para se beneficiar dos serviços complementares do Azure, talvez você precise fazer alterações secundárias na arquitetura.

ID do Cenário Cenário de HLI Migrar para textuais da VM? Comentário
1 Único nó com um SID Sim -
2 Nó único com MCOS (Vários componentes em um sistema) Sim -
3 Nó único com DR usando replicação de armazenamento Não A replicação de armazenamento não está disponível na plataforma virtual do Azure; altere a solução de DR atual para a HSR ou o backup/a restauração.
4 Nó único com DR (multiuso) usando replicação de armazenamento Não A replicação de armazenamento não está disponível na plataforma virtual do Azure; altere a solução de DR atual para a HSR ou o backup/a restauração.
5 HSR com isolamento para alta disponibilidade Yes Nenhum SBD pré-configurado para VMs de destino. Selecione e implante uma solução de isolamento. Opções possíveis: Agente de Isolamento do Azure (com suporte para RHEL, SLES e SBD.
6 HA com HSR, DR com replicação de armazenamento Não Substitua a replicação de armazenamento para as necessidades de DR pela HSR ou pelo backup/pela restauração.
7 Failover Automático do Host (1 + 1) Yes Use o ANF (Azure NetApp Files) para o armazenamento compartilhado com VMs do Azure.
8 Expansão com espera Yes BW/4HANA com VMs M128s, M416s e M416ms usando o ANF somente para o armazenamento.
9 Expansão sem espera Yes BW/4HANA com VMs M128s, M416s e M416ms (com ou sem o ANF para o armazenamento).
10 Expansão com DR usando replicação de armazenamento Não Substitua a replicação de armazenamento para as necessidades de DR pela HSR ou pelo backup/pela restauração.
11 Nó único com DR usando HSR Sim -
12 HSR de nó único para DR (otimizado para custo) Sim -
13 HA e DR com HSR Sim -
14 HA e DR com HSR (otimizado para custo) Yes -
15 Expansão com DR usando HSR Yes BW/4HANA com M128s. VMs M416s e M416ms (com ou sem o ANF para o armazenamento).

Planejamento de origem (HLI)

Durante a integração de um servidor do HLI, você e o Gerenciamento de Serviços da Microsoft fizeram o planejamento das configurações específicas de computação, rede, armazenamento e sistema operacional para executar o banco de dados SAP HANA. Planejamento semelhante precisa ocorrer para a migração para a VM do Azure.

Manutenção do SAP HANA

É uma boa prática operacional organizar o conteúdo do banco de dados para que os logs de dados indesejados, desatualizados ou obsoletos não sejam migrados para o novo banco de dados. A manutenção geralmente envolve a exclusão ou o arquivamento de dados antigos, expirados ou inativos. Essa ‘higiene de dados’ deve ser testada nos sistemas de não produção para aprovar a validade do corte de dados antes do uso em produção.

Permitir a conectividade de rede para novas VMs e rede virtual

Na sua implantação do HLI, a rede foi configurada com base nas informações descritas no artigo Arquitetura de rede do SAP HANA (Instâncias Grandes). Além disso, o roteamento do tráfego de rede é feito da maneira descrita na seção Roteamento no Azure.

  • O novo destino de migração da VM está colocado na rede virtual existente com os intervalos de endereços IP já com a permissão de se conectar ao HLI? Portanto, nenhuma atualização de conectividade é necessária.
  • A nova VM do Azure está colocada em uma nova Rede Virtual do Microsoft Azure, talvez em outra região, e está emparelhada com a rede virtual existente? Portanto, você pode usar a chave de serviço do ExpressRoute e a ID do recurso do provisionamento do HLI original para permitir o acesso a esse novo intervalo de IP da rede virtual. Coordene com o Gerenciamento de serviços da Microsoft para habilitar a conectividade de rede virtual para HLI.

    Observação

    Para minimizar a latência de rede entre as camadas do aplicativo e do banco de dados, as camadas do aplicativo e do banco de dados precisam estar na mesma rede virtual.

Conjunto de disponibilidade de camada de aplicativo existente, zonas de disponibilidade e PPG (grupo de posicionamento por proximidade)

Projetamos o modelo de implantação atual para atender a determinadas metas de nível de serviço. Nessa migração, verifique se a infraestrutura de destino atenderá às suas metas definidas ou as excederá.
Muito provavelmente, seus servidores de aplicativos SAP estão colocados em um conjunto de disponibilidade. Se o nível de serviço da implantação atual for satisfatório e se a VM de destino considerar o nome do host do nome lógico do HLI, a atualização da resolução de endereço DNS (Serviço de Nomes de Domínio) que aponta para o IP da VM funcionará sem atualizar nenhum perfil do SAP.

Processo de descontinuação da replicação de armazenamento (se usado)

Se você usou a replicação de armazenamento como sua solução de DR, encerre-a depois que o aplicativo SAP for desligado. Antes de fazer isso, verifique se o último catálogo do SAP HANA, o arquivo de log e os backups de dados foram replicados nos volumes de armazenamento remoto de DR do HLI. Essa replicação é importante caso ocorra um desastre durante a transição do servidor físico para a VM do Azure.

Consideração de preservação de backups de dados

Após a transição para o SAP HANA na sua VM do Azure, os dados baseados em instantâneo e os backups de log do HLI não serão facilmente acessíveis nem restauráveis em uma VM. Recomendamos fazer backups no nível de arquivo e instantâneos no HLI, até mesmo, várias semanas antes da substituição. Faça com que esses backups sejam copiados para uma conta de armazenamento do Microsoft Azure acessível pela nova VM SAP HANA. Além disso, no período de transição antecipado, antes que o backup baseado no Azure crie histórico suficiente para atender aos requisitos de recuperação pontual, faça backups no nível de arquivo.

Fazer o backup do conteúdo do HLI é fundamental. Recomendamos ter backups completos do cenário do SAP prontamente acessíveis, caso uma reversão seja necessária.

Ajuste do monitoramento do sistema

Você pode usar muitas ferramentas diferentes para monitorar e enviar notificações de alerta para sistemas no seu cenário do SAP. Lembre-se de tomar uma medida apropriada para incorporar as alterações para o monitoramento e atualizar os destinatários da notificação de alerta, se necessário.

Envolvimento da equipe de operações da Microsoft

Abra um tíquete do portal do Azure com base na instância de HLI existente. Depois que o tíquete de suporte for criado, um engenheiro de suporte entrará em contato com você por e-mail.

Envolva a equipe de contas da Microsoft

Planeje a migração próximo ao horário de renovação de aniversário do contrato do HLI para minimizar despesas desnecessárias referentes ao recurso de computação. Para desativar o HLI, coordene o encerramento do contrato e o desligamento da unidade.

Planejamento de destino

É essencial fazer um planejamento cuidadoso na implantação de uma nova infraestrutura que assumirá o lugar de uma existente. Verifique se a nova adição atenderá às suas necessidades no esquema mais amplo do cenário. Veja alguns pontos principais a serem considerados.

Disponibilidade de recursos na região de destino

Em geral, a região de implantação atual dos servidores de aplicativos SAP fica próxima aos HLIs associados. No entanto, os HLIs são oferecidos em menos locais do que as regiões disponíveis do Azure. Ao migrar o HLI físico para uma VM do Azure, também é um bom momento para ajustar a distância da proximidade de todos os serviços relacionados para otimização do desempenho. Ao fazer isso, verifique se a região escolhida tenha todos os recursos necessários. Por exemplo, o ideal é verificar a disponibilidade de determinada família de VMs ou as zonas do Azure que oferecem configuração de alta disponibilidade.

Rede virtual

Você deseja executar o novo banco de dados HANA em uma rede virtual existente ou criar uma? O principal fator de decisão é o layout de rede atual para a estrutura SAP. Além disso, quando a infraestrutura passa da implantação de uma zona para duas zonas e usa o PPG, ela impõe alterações de arquitetura. Para obter mais informações, consulte o artigo PPG do Azure para latência de rede ideal com o aplicativo SAP.

Segurança

Se a nova VM do SAP HANA for executada em uma VNet/sub-rede nova ou existente, ela é um novo serviço crítico para seus negócios. Ela merece ter proteção. Verifique se o controle de acesso está em conformidade com a política de segurança da sua empresa.

Recomendação de dimensionamento de VM

Essa migração também é uma oportunidade de dimensionar corretamente o seu mecanismo de computação do HANA. É possível usar exibições do sistema do HANA com o HANA Studio para entender o consumo de recursos do sistema, o que permite o dimensionamento correto para impulsionar a eficiência dos gastos.

Armazenamento

O desempenho do armazenamento é um dos fatores que afetarão a experiência do usuário do aplicativo SAP. Há layouts de armazenamento mínimo publicados para determinadas SKUs de VM. Para obter mais informações, confira Configurações de armazenamento de máquina virtual do Azure no SAP HANA. Recomendamos examinar essas especificações mínimas e compará-las com as estatísticas de sistema do HLI existentes para garantir a capacidade e o desempenho de E/S adequados para a nova VM do HANA.

Você vai configurar o PPG para a nova VM do HANA e os servidores associados? Em seguida, envie um tíquete de suporte para inspecionar e garantir a colocalização do armazenamento e da VM. Como sua solução de backup pode precisar ser alterada, revisite também o custo de armazenamento para evitar surpresas de gastos operacionais.

Replicação de armazenamento para recuperação de desastre

Com o HLI, a replicação de armazenamento era a opção padrão para recuperação de desastre. Esse recurso não é a opção padrão para o SAP HANA na VM do Azure. Considere a HSR, o backup/a restauração ou outras soluções compatíveis que atendam às suas necessidades comerciais.

Conjuntos de disponibilidade, zonas de disponibilidade e grupos de posicionamento por proximidade

Você pode reduzir a distância entre a camada de aplicativo e o SAP HANA para manter o mínimo de latência de rede. Coloque a nova VM de banco de dados e os servidores de aplicativos SAP atuais em um PPG. Para obter mais informações sobre como o conjunto de disponibilidade do Azure e as zonas de disponibilidade funcionam com o PPG nas implantações do SAP, confira Grupo de posicionamento por proximidade.

Se os membros do seu sistema HANA forem implantados em mais de uma zona do Azure, você deverá estar ciente do perfil de latência das zonas escolhidas. Coloque os componentes do sistema SAP de modo a diminuir a distância entre o aplicativo SAP e o banco de dados. A ferramenta de teste de latência da zona de disponibilidade de domínio público ajuda a facilitar a medição.

Estratégia de backup

Muitos de nossos clientes já estão usando soluções de backup de terceiros para o SAP HANA no HLI. Se esse for o seu caso, somente os bancos de dados protegidos da VM e do HANA precisarão ser configurados. Os trabalhos de backup contínuo do HLI poderão ter o agendamento cancelado se o computador estiver sendo desativado após a migração.

O backup do Azure para o SAP HANA em VMs já está em disponibilidade geral. Para obter mais informações sobre o backup do SAP HANA em VMs do Azure, confira Backup, Restauração e Gerenciamento.

Estratégia de DR

Se as suas metas de nível de serviço acomodarem um tempo de recuperação mais longo, o backup poderá ser fácil. Um backup para o armazenamento de blobs e a restauração no local ou a restauração em uma nova VM é a estratégia de DR mais simples e menos cara.

Na plataforma das Instâncias Grandes, a DR do HANA normalmente é feita com a HSR. Em uma VM do Azure, a HSR também é a solução de DR mais natural e nativa do SAP HANA. Independentemente de a implantação de origem ser de instância única ou clusterizada, uma réplica da infraestrutura de origem é necessária na região de DR. Essa réplica de DR será configurada depois que a migração de HLI primário para VM for concluída. O BD HANA de DR será registrado no SAP HANA primário na instância de VM como um site de replicação secundário.

Alteração de destino de conectividade do servidor de aplicativos SAP

A migração da HSR resulta em um novo host do banco de dados HANA e em um novo nome do host de banco de dados para a camada de aplicativo. Modifique os perfis SAP para que eles reflitam o novo nome do host. Se a alternância for feita pela resolução de nomes preservando o nome do host, nenhuma alteração de perfil será necessária.

OS (sistema operacional)

As imagens do sistema operacional para o HLI e a VM, apesar de estarem no mesmo nível de versão (SLES 12 SP4, por exemplo), não são idênticas. Valide os pacotes, os hotfixes, o kernel, as correções de segurança e os patches necessários no HLI. Em seguida, instale os mesmos pacotes no destino. Use a HSR para a replicação de um sistema operacional mais antigo para uma VM com uma versão mais recente do sistema operacional. Confirme as versões compatíveis examinando a Nota SAP 2763388.

Nova solicitação de licença SAP

Uma chamada simples para solicitar uma nova licença SAP para o novo sistema HANA agora que ele foi migrado para VMs.

Diferenças do SLA (contrato de nível de serviço)

Os autores gostam de destacar a diferença do SLA de disponibilidade entre o HLI e a VM do Azure. Por exemplo, pares clusterizados de HLIs de HA oferecem 99,99% de disponibilidade. Para obter o mesmo SLA, você precisará implantar VMs em zonas de disponibilidade. O SLA para Máquinas Virtuais descreve a disponibilidade de várias configurações de VM para que os clientes possam planejar a infraestrutura de destino.

Estratégia de migração

Neste documento, falamos apenas sobre a abordagem de replicação do sistema HANA para a migração do HLI para a VM do Azure. Dependendo da solução de armazenamento de destino implantada, o processo é um pouco diferente. As etapas de alto nível são descritas abaixo.

VM com discos premium/ultra para dados

Para as VMs implantadas com discos premium ou ultra, a configuração padrão de replicação de sistema do SAP HANA é aplicável para definir a HSR. Para obter uma visão geral das etapas da configuração da replicação de sistema, confira o artigo de ajuda do SAP. O artigo também aborda a tomada de posse de um sistema secundário, o failback para o primário e a desabilitação da replicação do sistema. Para a migração, só precisaremos das etapas de configuração, tomada de posse e desabilitação da replicação.

VM com ANF para volumes de dados e de log

Em um nível superior, os instantâneos mais recentes de armazenamento do HLI dos dados completos e dos volumes de log precisam ser copiados para o armazenamento do Azure. Nele, eles ficam acessíveis e podem ser recuperados pela VM de destino do HANA. O processo de cópia pode ser feito com qualquer ferramenta de cópia nativa do Linux.

Importante

A cópia e a transferência de dados podem levar horas, dependendo do tamanho do banco de dados HANA e da largura de banda de rede. A maior parte do processo de cópia deve ser feita antes do tempo de inatividade primário do banco de dados HANA.

Conversão de MCOS para MDC

O modelo de implantação de Vários componentes em um sistema (MCOS) foi usado por alguns dos nossos clientes do HLI. A motivação era burlar a limitação do instantâneo de armazenamento dos Vários contêineres de bancos de dados (MDC) das versões anteriores do SAP HANA. No modelo MCOS, várias instâncias independentes do SAP HANA são empilhadas em uma Instância Grande do HANA. O uso da HSR para a migração funciona bem, resulta em várias VMs do HANA com um banco de dados de locatário cada uma. Esse modelo propicia um cenário mais movimentado do que o que você pode preferir. A implantação padrão do SAP HANA 2.0 é o MDC. Uma alternativa é fazer a movimentação de locatário do HANA após a migração da HSR. A movimentação de locatário do HANA combina esses bancos de dados HANA independentes em colocatários em um só contêiner do HANA.

Consideração da camada de aplicativo

O servidor de banco de dados é exibido como o centro de um sistema SAP. Todos os servidores de aplicativos devem estar localizados próximo ao banco de dados SAP HANA. Em alguns casos, quando você deseja usar um novo PPG, talvez precise mover os servidores de aplicativos existentes para o PPG em que a VM do HANA está localizada. A criação de servidores de aplicativos pode ser considerada mais fácil se você já tiver modelos de implantação prontos.

Localize os servidores de aplicativos existentes e a nova VM do HANA de maneira ideal. Em seguida, você não precisará criar servidores de aplicativos, a menos que queira ter maior capacidade.

Quando você cria uma infraestrutura para aprimorar a disponibilidade do serviço, os servidores de aplicativos existentes podem se tornar desnecessários. Eles podem ser desligados e excluídos. Se o nome do host da VM de destino for alterado e for diferente do nome do host do HLI, ajuste os perfis do servidor de aplicativos SAP para que eles apontem para o novo host. Se apenas o endereço IP do banco de dados HANA tiver sido alterado, atualize o registro DNS para conduzir as conexões de entrada para a nova VM do HANA.

Teste de aceitação

A migração do HLI para a VM não causa nenhuma alteração material no conteúdo do banco de dados em comparação com uma migração heterogênea. Ainda assim, recomendamos verificar o desempenho da nova configuração.

Plano de transição

Embora essa migração seja simples, ela envolve a desativação de um banco de dados existente. É fundamental fazer um planejamento cuidadoso para preservar o sistema de origem com o conteúdo e as imagens de backup no caso de o fallback ser necessário. Um bom planejamento oferece uma reversão mais rápida.

Após a migração

O trabalho de migração não é feito até que tenhamos separado com segurança todos os serviços dependentes do HLI e a conectividade para garantir a integridade dos dados. Além disso, recomendamos desligar serviços desnecessários. Esta seção destaca alguns dos itens mais importantes.

Encerramento do HLI

Depois de migrar com êxito o banco de dados HANA para uma VM do Azure, garanta que nenhuma transação de negócios seja executada no banco de dados do HLI. No entanto, manter o HLI em execução durante a janela de retenção de backup local garantirá uma recuperação mais rápida, se necessário. Somente quando a janela de retenção de backup local tiver decorrido, você deverá desativar a Instância Grande do HANA. Em seguida, conclua seus compromissos contratuais do HLI com a Microsoft entrando em contato com os representantes da Microsoft.

Remova qualquer proxy (por exemplo, Iptables, BIGIP) configurado para o HLI

Se um serviço de proxy como o IPTables for usado para rotear o tráfego local bidirecionalmente no HLI, você não precisará dele após a migração bem-sucedida para a VM. No entanto, esse serviço de conectividade deve ser mantido enquanto o HLI ainda estiver em espera. Desligue o serviço somente depois que o HLI for completamente desativado.

Remoção de Alcance Global para HLI

Alcance Global é usado para conectar o gateway de ExpressRoute do cliente com o gateway de ExpressRoute do HLI. Ele permite que o tráfego local dos clientes atinja o locatário de HLI diretamente sem o uso de um serviço de proxy. Essa conexão não é mais necessária na ausência da unidade do HLI após a migração. Ainda assim, como o serviço de proxy IPTables, o GlobalReach também deve ser mantido até que o HLI seja completamente desativado.

Assinatura do sistema operacional – mover/reutilizar

Conforme os servidores de VM são implantados e os HLIs são desativados, as assinaturas do sistema operacional podem ser substituídas ou reutilizadas. Não é necessário pagar o dobro pelas licenças do sistema operacional.

Próximas etapas

Planeje sua implantação do SAP.

Carga de trabalho SAP no Azure: lista de verificação de planejamento e implantação