Migração do SAP HANA na Instância Grande do Azure para o Azure Máquinas Virtuais

Este artigo descreve possíveis cenários de implementação de Instâncias Grandes do Azure e oferece uma abordagem de planeamento e migração com um período de indisponibilidade 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 este hardware como um serviço para a sua plataforma de computação dentro da memória. No entanto, nos últimos anos, a extensão de tamanho da máquina virtual (VM) do Azure e o suporte da implementação de escalamento horizontal do HANA excederam a procura da capacidade da base de dados ERP da maioria dos clientes empresariais. Muitos estão a manifestar 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. Descreve os modelos de implementação comuns e oferece conselhos de planeamento e migração. A nossa intenção é chamar as considerações necessárias para a preparação para minimizar o período de indisponibilidade da transição.

Pressupostos

Este artigo faz os seguintes pressupostos:

• Vamos considerar apenas uma migração homogénea do serviço de computação de bases de dados HANA da Instância Grande (HLI) para a VM do Azure sem atualização de software ou aplicação de patches significativa. Estas atualizações secundárias incluem a utilização de uma versão mais recente do sistema operativo (SO) ou a versão HANA explicitamente indicada como suportada pelas notas SAP relevantes.
• Irá realizar todas as atividades de atualizações antes ou depois da migração. Por exemplo, conversão do SAP HANA MCOS para implementação MDC.
• A abordagem de migração que oferece menos tempo de inatividade é a Replicação do Sistema SAP HANA. Outros métodos de migração não fazem parte do âmbito deste documento.
• Esta orientação é aplicável aos SKUs Rev3 e Rev4 do HLI.
• A arquitetura de implementação do HANA permanece praticamente inalterada durante a migração. Ou seja, um sistema com uma única instância de recuperação após desastre (DR) permanecerá igual no destino.
• Analisou e compreendeu o Contrato de Nível de Serviço (SLA) da arquitetura de destino (para ser).
• Os termos comerciais entre HLIs e VMs são diferentes. Monitorize a utilização das VMs para a gestão de custos.
• Compreende que o HLI é uma plataforma de computação dedicada enquanto as VMs são executadas numa infraestrutura partilhada mas isolada.
• Validou que as VMs de destino suportam a arquitetura pretendida. Para obter uma lista dos SKUs de VM suportados certificados para implementação do SAP HANA, veja o diretório de hardware do SAP HANA.
• Validou o plano de conceção e migração.
• Planeie a VM de recuperação após desastre juntamente com o site primário. Não pode utilizar o HLI como nó de DR para o site primário em execução nas VMs após a migração.
• Copiou os ficheiros de cópia de segurança necessários para as VMs de destino, com base nos requisitos de conformidade e de recuperação empresarial. Com as cópias de segurança acessíveis da VM, permite a recuperação para um ponto anterior no tempo durante o período de transição.
• Para a elevada disponibilidade (HA) da replicação do sistema SAP HANA (HSR), tem de configurar o dispositivo de esgrima de acordo com os guias HA do SAP HANA para SLES e RHEL. Não está pré-configurado como o caso HLI.
• Esta abordagem de migração não abrange os SKUs HLI com a configuração optane.

Cenários de implementação

Pode migrar para as VMs do Azure para todos os cenários HLI. Os modelos de implementação comuns do HLI são resumidos na tabela seguinte. Para beneficiar de serviços complementares do Azure, poderá ter de fazer pequenas alterações arquitetónicas.

Planeamento de origem (HLI)

Ao integrar o servidor HLI, o utilizador e a Gestão de Serviços da Microsoft passaram pelo planeamento das definições específicas de computação, rede, armazenamento e SO para executar a base de dados SAP HANA. É necessário um planeamento semelhante para a migração para a VM do Azure.

Limpeza do SAP HANA

É uma boa prática operacional limpar o conteúdo da base de dados para que os dados indesejados, desatualizados ou os registos obsoletos não sejam migrados para a nova base de dados. Geralmente, a limpeza envolve eliminar ou arquivar dados antigos, expirados ou inativos. Esta "higiene de dados" deve ser testada em sistemas de não produção para validar a sua validade de corte de dados antes da utilização da produção.

Permitir conectividade de rede para novas VMs e rede virtual

Na implementaçã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 encaminhamento de tráfego de rede é feito da forma descrita na secção Encaminhamento no Azure.

• O novo destino de migração da VM é colocado na rede virtual existente com intervalos de endereços IP já autorizados a ligar ao HLI? Em seguida, não é necessária mais nenhuma atualização de conectividade.
• A nova VM do Azure é colocada numa nova Rede Virtual do Microsoft Azure, talvez noutra região, e está em modo de peering com a rede virtual existente? Em seguida, pode utilizar a chave de serviço do ExpressRoute e o ID de Recurso do aprovisionamento original do HLI para permitir o acesso a este novo intervalo de IP de rede virtual. Coordene com a Gestão de Serviços da Microsoft para permitir a conectividade da rede virtual ao HLI.

  Nota

  Para minimizar a latência de rede entre as camadas da aplicação e da base de dados, as camadas da aplicação e da base de dados têm de estar na mesma rede virtual.

Conjunto de disponibilidade de camada de aplicação existente, zonas de disponibilidade e grupo de colocação por proximidade (PPG)

Concebemos o modelo de implementação atual para satisfazer determinados objetivos de nível de serviço. Neste movimento, certifique-se de que a infraestrutura de destino irá cumprir ou exceder os seus objetivos definidos.
Provavelmente, os servidores de aplicações SAP são colocados num conjunto de disponibilidade. Se o nível de serviço de implementação atual for satisfatório e se a VM de destino assumir o nome de anfitrião do nome lógico HLI, atualizar a resolução de endereços do serviço de nome de domínio (DNS) que aponta para o IP da VM funcionará sem atualizar quaisquer perfis SAP.

• Se não estiver a utilizar PPG, certifique-se de que coloca todos os servidores de Aplicação e BD na mesma zona para minimizar a latência de rede.
• Se estiver a utilizar PPG, veja uma secção posterior deste artigo, Conjuntos de disponibilidade, zonas de disponibilidade e grupos de colocação por proximidade.

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

Se utilizou a replicação de armazenamento como solução de DR, termine-a depois de a aplicação SAP ser encerrada. Antes de o fazer, certifique-se de que o último catálogo, ficheiro de registo e cópias de segurança de dados do SAP HANA são replicados para os volumes de armazenamento HLI de DR remotos. Esta replicação é importante no caso de ocorrer um desastre durante a transição do servidor físico para a VM do Azure.

Consideração de preservação de cópias de segurança de dados

Após a transição para o SAP HANA na VM do Azure, os dados baseados em instantâneos e as cópias de segurança de registo no HLI não serão facilmente acessíveis ou restauráveis para uma VM. Recomendamos que faça cópias de segurança e instantâneos ao nível do ficheiro no HLI, mesmo semanas antes da transferência. Faça com que estas cópias de segurança sejam copiadas para uma conta de Armazenamento do Azure acessível pela nova VM sap HANA. Também no período de transição inicial, antes de a cópia de segurança baseada no Azure criar histórico suficiente para satisfazer os requisitos de recuperação para Um Ponto anterior no Tempo, faça cópias de segurança ao nível dos ficheiros.

A cópia de segurança do conteúdo HLI é fundamental. Também é prudente ter cópias de segurança completas da paisagem SAP prontamente acessíveis no caso de ser necessária uma reversão.

Ajustar a monitorização do sistema

Pode utilizar muitas ferramentas diferentes para monitorizar e enviar notificações de alerta para sistemas no seu cenário SAP. Lembre-se de tomar as medidas adequadas para incorporar alterações para monitorizar e atualizar os destinatários da notificação de alerta, se necessário.

Envolvimento da equipa de Operações da Microsoft

Abra um pedido de suporte a partir do portal do Azure com base na instância do HLI existente. Após a criação do pedido de suporte, um engenheiro de suporte contactá-lo-á por e-mail.

Contactar a equipa da conta Microsoft

Planeie a migração perto da hora de renovação de aniversário do contrato HLI para minimizar as despesas desnecessárias para o recurso de computação. Para desativar o HLI, coordene a cessação do contrato e o encerramento da unidade.

Planeamento de destino

Um planeamento cuidadoso é essencial na implementação de uma nova infraestrutura para substituir uma existente. Certifique-se de que a nova adição irá satisfazer as suas necessidades num esquema maior de coisas. Seguem-se alguns pontos-chave a considerar.

Disponibilidade de recursos na região de destino

Normalmente, a região de implementação dos servidores de aplicações SAP atual está próxima dos HLIs associados. No entanto, os HLIs são oferecidos em menos localizações do que as regiões do Azure disponíveis. Ao migrar o HLI físico para uma VM do Azure, também é uma boa altura para ajustar a distância de proximidade de todos os serviços relacionados para otimização do desempenho. Ao fazê-lo, certifique-se de que a região escolhida tem todos os recursos necessários. Por exemplo, poderá querer verificar a disponibilidade de uma determinada família de VMs ou das Zonas do Azure que oferecem uma configuração de elevada disponibilidade.

Rede virtual

Pretende executar a nova base de dados HANA numa rede virtual existente ou criar uma nova? O principal fator decisivo é o esquema de rede atual para o cenário SAP. Além disso, quando a infraestrutura passa da implementação de uma zona para duas zonas e utiliza PPG, impõe alterações arquitetónicas. Para obter mais informações, veja o artigo PPG do Azure para obter uma latência de rede ideal com a aplicação SAP.

Segurança

Quer a nova VM sap HANA seja executada numa vnet/sub-rede nova ou existente, é um novo serviço crítico para a sua empresa. Merece salvaguarda. Certifique-se de que o controlo de acesso está em conformidade com a política de segurança da sua empresa.

Recomendação de dimensionamento da VM

Esta migração também é uma oportunidade para dimensionar corretamente o motor de computação HANA. Pode utilizar vistas de sistema HANA com o HANA Studio para compreender o consumo de recursos do sistema, o que permite o dimensionamento certo para impulsionar a eficiência de gastos.

Armazenamento

O desempenho do armazenamento é um dos fatores que afetará a sua experiência de utilizador da aplicação SAP. Existem esquemas de armazenamento mínimos publicados para determinados SKUs de VM. Para obter mais informações, veja Configurações de armazenamento de máquinas virtuais do Azure do SAP HANA. Recomendamos que analise estas especificações e compare com as estatísticas do sistema HLI existentes para garantir a capacidade e o desempenho adequados de E/S para a sua nova VM HANA.

Irá configurar o PPG para a nova VM HANA e os respetivos servidores associados? Em seguida, submeta um pedido de suporte para inspecionar e garantir a colocalização do armazenamento e da VM. Uma vez que a solução de cópia de segurança pode ter de ser alterada, reveja também o custo de armazenamento para evitar surpresas de gastos operacionais.

Replicação de armazenamento para recuperação após desastre

Com o HLI, a replicação de armazenamento era a opção predefinida para a recuperação após desastre. Esta funcionalidade não é a opção predefinida do SAP HANA na VM do Azure. Considere o HSR, a cópia de segurança/restauro ou outras soluções suportadas que satisfaçam as suas necessidades empresariais.

Conjuntos de disponibilidade, zonas de disponibilidade e grupos de colocação por proximidade

Pode reduzir a distância entre a camada da aplicação e o SAP HANA para manter a latência de rede no mínimo. Coloque a nova VM de base de dados e os atuais servidores de aplicações SAP num PPG. Para obter mais informações sobre como as zonas de disponibilidade e o conjunto de disponibilidade do Azure funcionam com o PPG para implementações SAP, veja Grupo de Colocação por Proximidade.

Se os membros do seu sistema HANA estiverem implementados em mais do que uma Zona do Azure, deve estar ciente do perfil de latência das zonas escolhidas. Coloque os componentes do sistema SAP para diminuir a distância entre a aplicação SAP e a base de dados. A ferramenta de teste de latência da zona de disponibilidade do domínio público ajuda a facilitar a medição.

Estratégia de cópia de segurança

Muitos dos nossos clientes já estão a utilizar soluções de cópia de segurança de terceiros para o SAP HANA no HLI. Se estiver, só é necessário configurar bases de dados HANA e VM protegidas. As tarefas de cópia de segurança HLI em curso podem não ser agendadas se a máquina estiver a ser desativada após a migração.

A cópia de segurança do Azure para SAP HANA na VM está agora disponível globalmente. Para obter mais informações sobre a cópia de segurança do SAP HANA em VMs do Azure, veja Cópia de Segurança, Restauro e Gerir.

Estratégia de DR

Se os objetivos de nível de serviço acomodarem um tempo de recuperação mais longo, a cópia de segurança pode ser fácil. Uma cópia de segurança para o armazenamento de blobs e restauro no local ou restauro para uma nova VM é a estratégia de DR mais simples e menos dispendiosa.

Na plataforma de instâncias grandes, o DR do HANA é normalmente feito com HSR. Numa VM do Azure, o HSR é também a solução de DR sap HANA mais natural e nativa. Quer a implementação de origem seja de instância única ou em cluster, é necessária uma réplica da infraestrutura de origem na região de DR. Esta réplica de DR será configurada após a conclusão da migração principal do HLI para a VM. A BD DR HANA será registada no SAP HANA primário na instância da VM como um site de replicação secundária.

Alteração do destino de conectividade do servidor de aplicações SAP

A migração HSR resulta num novo anfitrião de base de dados HANA e também num novo nome de anfitrião de base de dados para a camada da aplicação. Modifique os perfis SAP para refletir o novo nome de anfitrião. Se a mudança for efetuada pela resolução de nomes que preserva o nome do anfitrião, não é necessária nenhuma alteração de perfil.

SO (sistema operativo)

As imagens do SO 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 necessários, correções frequentes, patches, kernel e correções de segurança no HLI. Em seguida, instale os mesmos pacotes no destino. Pode utilizar o HSR para replicar de um SO mais antigo para uma VM com uma versão mais recente do SO. Verifique as versões suportadas ao rever a nota SAP 2763388.

Novo pedido de licença sap

Uma chamada simples para pedir uma nova licença SAP para o novo sistema HANA, agora que foi migrada para VMs.

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

Os autores gostam de chamar a atenção para a diferença de disponibilidade do SLA entre o HLI e a VM do Azure. Por exemplo, os pares HA de HLIs em cluster oferecem 99,99% de disponibilidade. Para alcançar o mesmo SLA, terá de implementar 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 planear a infraestrutura de destino.

Estratégia de migração

Neste documento, abordamos apenas a abordagem de Replicação do Sistema HANA para a migração do HLI para a VM do Azure. Depende da solução de armazenamento de destino implementada, o processo difere ligeiramente. Os passos de alto nível são descritos abaixo.

VM com discos premium/ultra para dados

Para VMs implementadas com discos premium ou ultra, a configuração de replicação do sistema SAP HANA padrão é aplicável para configurar o HSR. Para obter uma descrição geral dos passos na configuração da replicação do sistema, veja o artigo de ajuda do SAP. O artigo também abrange a tomada de um sistema secundário, a reativação pós-falha para a primária e a desativação da replicação do sistema. Para a migração, só precisamos da configuração, da tomada de conta e da desativação dos passos de replicação.

VM com ANF para volumes de dados e registo

A um nível elevado, os instantâneos de armazenamento HLI mais recentes dos dados completos e dos volumes de registo têm de ser copiados para o armazenamento do Azure. A partir daí, são acessíveis e recuperáveis pela VM HANA de destino. O processo de cópia pode ser feito com quaisquer ferramentas de cópia nativas do Linux.

Conversão mcOS para MDC

O modelo de implementação Multiple Components in One System (MCOS) foi utilizado por alguns dos nossos clientes HLI. A motivação foi contornar a limitação do instantâneo de armazenamento do Contentor de Múltiplas Bases de Dados (MDC) de versões anteriores do SAP HANA. No modelo MCOS, várias instâncias independentes do SAP HANA estão empilhadas numa Instância Grande do HANA. A utilização do HSR para a migração funciona bem, mas resulta em várias VMs HANA com uma base de dados de inquilino cada. Este modelo torna um cenário mais movimentado do que o que poderia preferir. A implementação predefinida do SAP HANA 2.0 é MDC. Uma alternativa é fazer com que o inquilino do HANA se mova após a migração do HSR. A movimentação de inquilinos HANA combina estas bases de dados HANA independentes em co-inquilinos num único contentor HANA.

Consideração da camada da aplicação

O servidor de bases de dados é visto como o centro de um sistema SAP. Todos os servidores de aplicações devem estar localizados perto da base de dados SAP HANA. Em alguns casos, quando pretender utilizar um novo PPG, poderá ter de mover os servidores de aplicações existentes para o PPG onde a VM HANA está localizada. A criação de novos servidores de aplicações poderá ser considerada mais fácil se já tiver modelos de implementação prontos.

Localize os servidores de aplicações existentes e a nova VM HANA da melhor forma. Em seguida, não terá de criar novos servidores de aplicações, a menos que pretenda uma maior capacidade.

Quando cria uma nova infraestrutura para melhorar a disponibilidade do serviço, os servidores de aplicações existentes podem tornar-se desnecessários. Podem ser encerrados e eliminados. Se o nome do anfitrião da VM de destino tiver sido alterado e for diferente do nome do anfitrião do HLI, ajuste os perfis do servidor de aplicações SAP para apontarem para o novo anfitrião. Se apenas o endereço IP da base de dados HANA tiver sido alterado, atualize o registo DNS para liderar as ligações de entrada para a nova VM HANA.

Teste de aceitação

A migração do HLI para a VM não altera materialmente o conteúdo da base de dados em comparação com uma migração heterogénea. Ainda assim, recomendamos que verifique o desempenho da nova configuração.

Plano de transferência

Embora esta migração seja simples, envolve a desativação de uma base de dados existente. O planeamento cuidadoso para preservar o sistema de origem com os respetivos conteúdos e imagens de cópia de segurança é fundamental para o caso de ser necessária uma contingência. Um bom planeamento oferece uma inversão mais rápida.

Pós-migração

A tarefa de migração só é efetuada depois de desassociarmos com segurança quaisquer serviços dependentes do HLI e conectividade para garantir a integridade dos dados. Além disso, recomendamos que encerre serviços desnecessários. Esta secção chama a atenção para alguns dos itens mais importantes.

Desativar o HLI

Depois de migrar com êxito a base de dados HANA para uma VM do Azure, confirme que não são executadas transações empresariais na base de dados HLI. No entanto, manter o HLI em execução durante o período de tempo da janela de retenção da cópia de segurança local irá garantir uma recuperação mais rápida, se necessário. Apenas quando a janela de retenção da cópia de segurança local estiver passada, caso desativar a Instância Grande do HANA. Em seguida, conclua os compromissos contratuais do HLI com a Microsoft ao contactar os representantes da Microsoft.

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

Se um serviço proxy como os IPTables for utilizado para encaminhar o tráfego no local de e para o HLI, não precisa dele após a migração com êxito para a VM. No entanto, este serviço de conectividade deve ser mantido enquanto o HLI estiver parado. Encerre o serviço apenas quando o HLI estiver totalmente desativado.

Remover o Alcance Global do HLI

O Alcance Global é utilizado para ligar o gateway do ExpressRoute dos clientes ao gateway do HLI ExpressRoute. Permite que o tráfego no local dos clientes chegue diretamente ao inquilino do HLI sem a utilização de um serviço proxy. Esta ligação já não é necessária na ausência da unidade HLI após a migração. Ainda assim, tal como o serviço 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 de VM são implementados e os HLIs são desativados, as subscrições do SO podem ser substituídas ou reutilizadas. Não é necessário pagar o dobro das licenças de SO.

Passos seguintes

Planeie a implementação do SAP.