SAP HANA na migração de instância grande do Azure para máquinas virtuais do Azure

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

Descrição geral

As Instâncias Grandes do Azure para SAP HANA (HLI) foram anunciadas pela primeira vez em setembro de 2016. Desde então, muitos adotaram esse hardware como um serviço para sua plataforma de computação na memória. No entanto, nos últimos anos, a extensão de tamanho da máquina virtual (VM) do Azure e o suporte à implantação em expansão do HANA excederam a demanda de capacidade de banco de dados ERP da maioria dos clientes corporativos. Muitos estão expressando interesse em migrar sua 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 consultoria de planejamento e migração. Nossa intenção é chamar a atenção para as considerações necessárias para a preparação para minimizar o tempo de inatividade da transição.

Suposições

Este artigo parte dos seguintes pressupostos:

• Consideraremos apenas uma migração homogênea do serviço de computação de banco de dados HANA da Hana Large Instance (HLI) para a VM do Azure sem atualização ou aplicação de patches de software significativa. Essas atualizações menores incluem o uso de uma versão mais recente do sistema operacional (SO) ou da versão HANA explicitamente declarada como suportada pelas notas relevantes do SAP.
• Você fará todas as atividades de atualizações/upgrades antes ou depois da migração. Por exemplo, SAP HANA MCOS convertendo para implantação MDC.
• A abordagem de migração que oferece menos tempo de inatividade é o SAP HANA System Replication. Outros métodos de migração não fazem parte do escopo deste documento.
• Esta orientação é aplicável para SKUs Rev3 e Rev4 de HLI.
• A arquitetura de implantação do HANA permanece basicamente inalterada durante a migração. Ou seja, um sistema com recuperação de desastres (DR) de instância única permanecerá o mesmo no destino.
• Você analisou e entendeu o Contrato de Nível de Serviço (SLA) da arquitetura de destino (futura).
• Os termos comerciais entre HLIs e VMs são diferentes. Monitore o uso de suas VMs para gerenciamento de custos.
• Você entende que o HLI é uma plataforma de computação dedicada enquanto as VMs são executadas em infraestrutura compartilhada, mas isolada.
• Você validou que as VMs de destino suportam a arquitetura pretendida. Para obter uma lista de SKUs de VM suportadas certificadas para implantação do SAP HANA, consulte o diretório de hardware do SAP HANA.
• Você validou o design e o plano de migração.
• Planeje a VM de recuperação de desastres junto com o site primário. Não é possível usar o HLI como o nó DR para o site primário em execução em 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 de negócios. Com backups acessíveis por VM, ele permite a recuperação point-in-time durante o período de transição.
• Para a replicação do sistema SAP HANA (HSR) de alta disponibilidade (HA), você precisa configurar o dispositivo de vedação de acordo com os guias SAP HANA HA para SLES e RHEL. Não é pré-configurado como o caso HLI.
• Essa abordagem de migração não cobre as SKUs HLI com configuração Optane.

Cenários de implementação

Você pode migrar para VMs do Azure para todos os cenários de HLI. Os modelos de implantação comuns para HLI são resumidos na tabela a seguir. Para se beneficiar de serviços complementares do Azure, talvez seja necessário fazer pequenas alterações na arquitetura.

Planeamento da fonte (HLI)

Ao integrar seu servidor HLI, você e o Microsoft Service Management passaram pelo planejamento das configurações específicas de computação, rede, armazenamento e SO para executar o banco de dados SAP HANA. Planejamento semelhante precisa ocorrer para a migração para a VM do Azure.

Serviço de limpeza SAP HANA

É uma boa prática operacional organizar o conteúdo do banco de dados para que dados indesejados, desatualizados ou logs obsoletos não sejam migrados para o novo banco de dados. A limpeza geralmente envolve a exclusão ou o arquivamento de dados antigos, expirados ou inativos. Esta "higiene dos dados" deve ser testada em sistemas que não sejam de produção para validar a sua validade de corte de dados antes da utilização na produção.

Permitir conectividade de rede para novas VMs e rede virtual

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

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

  Nota

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

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

Projetamos o modelo de implantação atual para satisfazer determinadas metas de nível de serviço. Nesse movimento, certifique-se de que a infraestrutura de destino atenderá ou excederá as metas estabelecidas.
É mais provável que seus servidores de aplicativos SAP sejam colocados em um conjunto de disponibilidade. Se o nível de serviço de implantação atual for satisfatório e se a VM de destino assumir o nome de host do nome lógico HLI, atualizar a resolução de endereço DNS (serviço de nome de domínio) apontando para o IP da VM funcionará sem atualizar nenhum perfil SAP.

• Se você não estiver usando PPG, certifique-se de colocar todos os servidores de aplicativo e banco de dados na mesma zona para minimizar a latência da rede.
• Se você estiver usando o PPG, consulte uma seção posterior deste artigo, Conjuntos de disponibilidade, zonas de disponibilidade e grupos de posicionamento de proximidade.

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 disso, certifique-se de que os últimos backups de catálogo, arquivo de log e dados do SAP HANA sejam replicados nos volumes de armazenamento DR HLI remotos. Essa replicação é importante no caso de ocorrer um desastre durante a transição do servidor físico para a VM do Azure.

Considerações sobre preservação de backups de dados

Após a transição para o SAP HANA em sua VM do Azure, os dados baseados em instantâneo e os backups de log na HLI não serão facilmente acessíveis ou restauráveis para uma VM. Recomendamos fazer backups e instantâneos no nível de arquivo no HLI mesmo semanas antes da transferência. Tenha esses backups copiados para uma conta de Armazenamento do Azure acessível pela nova SAP HANA VM. No período de transição inicial também, antes que o backup baseado no Azure crie histórico suficiente para satisfazer os requisitos de recuperação point-in-time, faça backups no nível de arquivo.

O backup do conteúdo HLI é fundamental. Também é prudente ter backups completos do cenário SAP prontamente acessíveis caso seja necessária uma reversão.

Ajustando o monitoramento do sistema

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

Envolvimento da equipa de Operações Microsoft

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

Envolva a equipa da conta Microsoft

Planeje a migração perto do tempo de renovação de aniversário do contrato HLI para minimizar despesas desnecessárias com o recurso de computação. Descomissionar o HLI, coordenar a rescisão contratual e o desligamento da unidade.

Planeamento de destinos

Um planeamento cuidadoso é essencial na implantação de uma nova infraestrutura que substitua uma já existente. Certifique-se de que a nova adição atenderá às suas necessidades no esquema maior de coisas. Aqui estão alguns pontos-chave a considerar.

Disponibilidade de recursos na região de destino

A região de implantação dos servidores de aplicativos SAP atuais normalmente está próxima das HLIs associadas. No entanto, as HLIs são oferecidas 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 de proximidade de todos os serviços relacionados para otimização de desempenho. Ao fazê-lo, certifique-se de que a região escolhida tem todos os recursos necessários. Por exemplo, você pode querer verificar a disponibilidade de uma determinada família de VMs ou as Zonas do Azure que oferecem configuração de alta disponibilidade.

Rede virtual

Deseja executar o novo banco de dados HANA em uma rede virtual existente ou criar uma nova? O principal fator decisivo é o layout de rede atual para o cenário SAP. Além disso, quando a infraestrutura passa de implantação de uma zona para duas zonas e usa PPG, ela impõe uma mudança arquitetônica. Para obter mais informações, consulte o artigo Azure PPG para latência de rede ideal com o aplicativo SAP.

Segurança

Quer o novo SAP HANA VM seja executado em uma vnet/sub-rede nova ou existente, é um novo serviço crítico para o seu negócio. Merece ser salvaguardada. Garanta o controle de acesso 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 seu mecanismo de computação HANA. Você pode usar as visualizações do sistema 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 mínimos de armazenamento publicados para determinadas SKUs de VM. Para obter mais informações, consulte Configurações de armazenamento de máquina virtual do SAP HANA Azure. Recomendamos revisar essas especificações e comparar com as estatísticas do sistema HLI existentes para garantir a capacidade e o desempenho de E/S adequados para sua nova VM HANA.

Você configurará o PPG para a nova VM HANA e seus 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, também reveja o custo de armazenamento para evitar surpresas de gastos operacionais.

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

Com o HLI, a replicação de armazenamento era a opção padrão para recuperação de desastres. Esse recurso não é a opção padrão para o SAP HANA na VM do Azure. Considere HSR, backup/restauração ou outras soluções suportadas que satisfaçam suas necessidades de negócios.

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

Você pode reduzir a distância entre a camada de aplicativos e o SAP HANA para manter a latência da rede no mínimo. 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 implantações do PPG for SAP, consulte Grupo de posicionamento de proximidade.

Se os membros do seu sistema HANA forem implantados em mais de uma Zona do Azure, você deve estar ciente do perfil de latência das zonas escolhidas. Coloque os componentes do sistema SAP para 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 SAP HANA no HLI. Se estiver, apenas os bancos de dados protegidos de VM e HANA adicionados precisarão ser configurados. Os trabalhos de backup HLI em andamento podem ser desprogramados se a máquina estiver sendo descomissionada após a migração.

O backup do Azure para SAP HANA na VM agora está disponível para o público em geral. Para obter mais informações sobre o backup do SAP HANA em VMs do Azure, consulte Backup, restauração e gerenciamento.

Estratégia de DR

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

Na plataforma de instância grande, o HANA DR normalmente é feito com HSR. Em uma VM do Azure, o HSR também é a solução SAP HANA DR mais natural e nativa. Quer a implantação de origem seja 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 após a conclusão da migração HLI para VM primária. O DR HANA DB registrará na instância primária do SAP HANA na VM como um local de replicação secundário.

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

A migração HSR resulta em um novo host de banco de dados HANA e também um novo nome de host de banco de dados para a camada de aplicativo. Modifique os perfis SAP para refletir o novo nome do host. Se a mudança for feita por resolução de nomes preservando o nome do host, nenhuma alteração de perfil será necessária.

SO (sistema operativo)

As imagens do sistema operacional para HLI e VM, apesar de estarem no mesmo nível de lançamento (SLES 12 SP4, por exemplo), não são idênticas. Valide os pacotes, hot fixes, patches, kernel e correções de segurança necessários no HLI. Em seguida, instale os mesmos pacotes no destino. Você pode usar o HSR para replicar de um sistema operacional mais antigo para uma VM com uma versão mais recente do sistema operacional. Verifique as versões suportadas examinando a nota 2763388 SAP.

Novo pedido 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 no contrato de nível de serviço (SLA)

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

Estratégia de migração

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

VM com premium/ultra-discos para dados

Para VMs implantadas com discos premium ou ultra-disk, a configuração padrão de replicação do sistema SAP HANA é aplicável para configurar HSR. Para obter uma visão geral das etapas de configuração da replicação do sistema, consulte o artigo de ajuda do SAP. O artigo também aborda a aquisição de um sistema secundário, a falha de volta ao primário e a desativação da replicação do sistema. Para a migração, precisaremos apenas das etapas de configuração, controle e desativação da replicação.

VM com ANF para volumes de dados e log

Em um alto nível, os instantâneos de armazenamento HLI mais recentes dos volumes completos de dados e log precisam ser copiados para o armazenamento do Azure. A partir daí, eles são acessíveis e recuperáveis pela VM HANA de destino. O processo de cópia pode ser feito com qualquer ferramenta de cópia nativa do Linux.

Conversão de MCOS para MDC

O modelo de implantação Multiple Components in One System (MCOS) foi usado por alguns de nossos clientes HLI. A motivação foi contornar a limitação de snapshot de armazenamento do Multiple Databases Container (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. Usar o HSR para a migração funciona bem, mas resulta em várias VMs HANA com um banco de dados de locatário cada. Este modelo cria uma paisagem mais movimentada do que você pode preferir. A implantação padrão do SAP HANA 2.0 é MDC. Uma alternativa é fazer a mudança de locatário HANA após a migração HSR. A movimentação do locatário HANA combina esses bancos de dados HANA independentes em colocatários em um único contêiner HANA.

Consideração da camada de aplicação

O servidor de banco de dados é visto como o centro de um sistema SAP. Todos os servidores de aplicativos devem estar localizados perto do banco de dados SAP HANA. Em alguns casos, quando você deseja usar um novo PPG, talvez seja necessário mover os servidores de aplicativos existentes para o PPG onde a VM HANA está localizada. A criação de novos 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 HANA de forma otimizada. Em seguida, você não precisará criar novos servidores de aplicativos, a menos que queira maior capacidade.

Quando você cria uma nova infraestrutura para melhorar a disponibilidade do serviço, seus 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 diferente do nome do host HLI, ajuste os perfis do servidor de aplicativos SAP para apontar para o novo host. Se apenas o endereço IP do banco de dados HANA tiver sido alterado, atualize o registro DNS para direcionar conexões de entrada para a nova VM HANA.

Teste de aceitação

A migração de HLI para VM não faz 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. Um planejamento cuidadoso para preservar o sistema de origem com seu conteúdo e imagens de backup é fundamental caso seja necessário um fallback. Um bom planejamento oferece uma reversão mais rápida.

Pós-migração

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

Desmantelamento do HLI

Depois de migrar com êxito o banco de dados HANA para uma VM do Azure, certifique-se de que nenhuma transação comercial seja executada no banco de dados HLI. No entanto, manter o HLI em execução durante o período de tempo de sua 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 passar, você deve encerrar a instância grande do HANA. Em seguida, conclua seus compromissos contratuais de HLI com a Microsoft entrando em contato com seus representantes da Microsoft.

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

Se um serviço de proxy como o IPTables for usado para rotear o tráfego local de e para a HLI, você não precisará dele após a migração bem-sucedida para a VM. No entanto, este serviço de conectividade deve ser mantido enquanto o HLI estiver de prontidão. Só encerre o serviço quando o HLI estiver totalmente desativado.

Remover o alcance global para HLI

O Global Reach é usado para conectar o gateway ExpressRoute dos clientes com o gateway HLI ExpressRoute. Ele permite que o tráfego local dos clientes chegue diretamente ao locatário HLI sem o uso de um serviço de proxy. Essa conexão não é mais necessária na ausência da unidade 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 totalmente desativado.

Subscrição do sistema operativo – mover/reutilizar

À medida que os servidores VM são implantados e as HLIs são descomissionadas, as assinaturas do sistema operacional podem ser substituídas ou reutilizadas. Não há necessidade de pagar o dobro pelas licenças do sistema operacional.

Próximos passos

Planeje sua implantação SAP.