Planejamento e implementação de Máquinas Virtuais do Azure para SAP NetWeaver

Artigo
03/15/2023
124 minutos para o fim da leitura

O Microsoft Azure permite que empresas adquiram recursos de computação e armazenamento gastando o mínimo de tempo, sem ciclos de compras longos. O serviço de Máquina Virtual do Azure permite que as empresas implantem aplicativos clássicos no Azure, como aplicativos baseados no SAP NetWeaver, além de aumentar a confiabilidade e disponibilidade desses aplicativos sem que sejam necessários mais recursos disponíveis localmente. Os Serviços da Máquina Virtual do Azure também dão suporte à conectividade entre locais, o que permite que as empresas integrem ativamente as Máquinas Virtuais do Azure em seus domínios locais, suas nuvens privadas e sua estrutura do sistema da SAP. Este white paper descreve os conceitos básicos de máquina virtual do Microsoft Azure e fornece uma explicação das considerações de planejamento e implementação para instalações da SAP NetWeaver no Azure e, por esse motivo, é o documento que deve ser lido antes de iniciar implantações reais da SAP NetWeaver no Azure. O documento complementa a documentação de instalação do SAP e as anotações do SAP, que representam os principais recursos para instalações e implantações de software SAP em determinadas plataformas.

Observação

Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Confira Instalar o Azure PowerShell para começar. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.

Resumo

Computação em Nuvem é um termo amplamente usado que está adquirindo cada vez mais importância no setor de TI, de pequenas empresas até multinacionais e grandes corporações.

O Microsoft Azure é a Plataforma de Serviços de Nuvem da Microsoft que oferece um amplo espectro de novas possibilidades. Agora, os clientes podem provisionar e desprovisionar com rapidez os aplicativos como um serviço na nuvem, para que não sejam limitados por restrições técnicas ou orçamentárias. Em vez de investir tempo e dinheiro na infraestrutura de hardware, as empresas podem se concentrar no aplicativo, nos processos de negócios e em seus benefícios para clientes e usuários.

Com os Serviços de Máquina Virtual do Microsoft Azure, a Microsoft oferece uma plataforma abrangente de IaaS (Infraestrutura como Serviço). Os aplicativos baseados no SAP NetWeaver têm suporte em Máquinas Virtuais do Azure (IaaS). Este whitepaper descreve como planejar e implementar aplicativos baseados na SAP NetWeaver no Microsoft Azure como a plataforma escolhida.

O documento se concentra em dois aspectos principais:

A primeira parte descreve dois padrões de implantação com suporte para aplicativos baseados no SAP NetWeaver no Azure. Ele também descreve a manipulação geral do Azure com implantações do SAP em mente.
A segunda parte detalha a implementação dos diferentes cenários descritos na primeira parte.

Para obter recursos adicionais, confira o capítulo Recursos neste documento.

Definições prévias

No decorrer do documento, usamos os termos a seguir:

IaaS: Infraestrutura como Serviço
PaaS: Plataforma como serviço
SaaS: Software como Serviço
Componente SAP: um aplicativo SAP individual como ECC, BW, Solution Manager ou S/4HANA. Os componentes SAP podem ser baseados em tecnologias ABAP ou Java tradicionais ou em um aplicativo não baseado em NetWeaver, como o Business Objects.
Ambiente SAP: um ou mais componentes SAP agrupados logicamente para executar uma função de negócios, como Desenvolvimento, QAS, Treinamento, DR ou Produção.
Estrutura do SAP: Este termo refere-se à totalidade dos ativos SAP na estrutura de TI de um cliente. A estrutura da SAP inclui todos os ambientes de produção e de não produção.
ID do sistema SAP: A combinação de camada DBMS e camada de aplicativo de, por exemplo, um sistema de desenvolvimento SAP ERP, sistema de teste SAP BW, sistema de produção SAP CRM etc. Em implantações do Azure não há suporte para dividir essas duas camadas entre local e Azure. Isso significa que um sistema SAP é implantado localmente ou no Azure. No entanto, você pode implantar os diferentes sistemas de uma estrutura da SAP no Azure ou localmente. Por exemplo, você poderia implantar os sistemas de desenvolvimento e teste SAP CRM no Azure, mas o sistema de produção CRM SAP localmente.
Entre instalações ou híbrida: Descreve um cenário em que as VMs são implantadas em uma assinatura do Azure com conectividade site a site, multissite ou de ExpressRoute entre os datacenters locais e o Azure. Na documentação comum do Azure, esses tipos de implantações também são descritas como cenários híbridos ou entre instalações. O motivo para a conexão é estender domínios locais, Active Directory/OpenLDAP local e DNS local para o Azure. A estrutura local é estendida para os ativos do Azure da assinatura. Com esta extensão, as VMs podem ser parte do domínio local. Usuários de domínio do domínio local podem acessar os servidores e podem executar serviços nessas VMs (como serviços DBMS). A comunicação e resolução de nomes entre máquinas virtuais implantadas localmente e VMs implantadas no Azure são possíveis. Esse é o caso mais comum e quase exclusivo de implantação de ativos SAP no Azure. Para obter mais informações, confira este artigo e este.
Extensão de Monitoramento do Azure, Monitoramento Avançado e Extensão para SAP do Azure: descreve o mesmo item. Trata-se de uma extensão de VM que precisa ser implantada por você para fornecer alguns dados básicos sobre a infraestrutura do Azure ao Agente de Host do SAP. As Notas do SAP podem se referir a isso como Extensão de Monitoramento ou Monitoramento Avançado. No Azure, nós nos referimos a isso como Extensão para SAP do Azure.

Observação

Implantações entre instalações ou híbridas de sistemas SAP em que máquinas virtuais do Azure que executam sistemas SAP são membros de um domínio local têm suporte para sistemas SAP de produção. As configurações entre locais ou híbridas são compatíveis com a implantação de partes ou estruturas SAP completas no Azure. Até mesmo a execução da estrutura da SAP completa no Azure requer que essas VMs sejam parte do domínio local e ADS/OpenLDAP.

Recursos

O ponto de entrada para a carga de trabalho SAP na documentação do Azure pode ser encontrado em Introdução às VMs do SAP no Azure. Começando com esse ponto de entrada, você encontra muitos artigos que abordam os tópicos de:

SAP NetWeaver e Business One no Azure
Guias do DBMS do SAP para vários sistemas DBMS no Azure
Alta disponibilidade e recuperação de desastres para carga de trabalho do SAP no Azure
Diretrizes específicas para executar o SAP HANA no Azure
Diretriz específica para Instâncias Grandes do Azure HANA para SAP HANA DBMS

Importante

Sempre que possível, um link para os Guias de Instalação SAP ou outra documentação do SAP é usado (Referência InstGuide-01 no Portal de ajuda do SAP). Quando se tratam de pré-requisitos, o processo de instalação ou detalhes de funcionalidades específicas do SAP a documentação do SAP e guias devem ser lidos sempre com cuidado, como os documentos da Microsoft só abrangem tarefas específicas para o software SAP instalado e operado em uma máquina virtual do Azure.

As seguintes Notas do SAP estão relacionadas com o tópico do SAP no Azure:

Número da observação	Title
1928533	Aplicativos SAP no Azure: Produtos com suporte e dimensionamento
2015553	SAP no Microsoft Azure: Pré-requisitos de suporte
1999351	Solução de problemas de monitoramento aprimorado do Azure para SAP
2178632	Métricas-chave de monitoramento para SAP no Microsoft Azure
1409604	Virtualização no Windows: Monitoramento Avançado
2191498	SAP no Linux com o Azure: Monitoramento Avançado
2243692	Linux na VM (IaaS) do Microsoft Azure: Problemas de licença do SAP
1984787	SUSE Linux Enterprise Server 12: Notas de instalação
2002167	Red Hat Enterprise Linux 7.x: Instalação e atualização
2069760	Atualização e instalação do SAP do Oracle Linux 7.x
1597355	Recomendação de troca de espaço para Linux

Leia também a Wiki de SCN, que contém todas as Notas SAP para Linux.

As limitações gerais padrão e as limitações máximas das assinaturas do Azure podem ser encontradas neste artigo.

Cenários possíveis

SAP é normalmente visto como um dos aplicativos mais essenciais nas empresas. A arquitetura e as operações desses aplicativos geralmente são complexas, e é importante que você atenda aos requisitos de disponibilidade e desempenho.

Portanto, as empresas precisam pensar cuidadosamente em qual provedor de nuvem escolher para executar processos comerciais críticos de negócios. O Azure é a plataforma de nuvem pública ideal para processos de negócios e aplicativos SAP comercialmente críticos. Considerando a ampla variedade de infraestruturas do Azure, quase todos os sistemas SAP NetWeaver e S/4HANA existentes podem ser hospedados no Azure no momento. O Azure fornece VMs com muitos terabytes de memória e mais de 200 CPUs. Além disso, o Azure oferece Instâncias Grandes do HANA, que permitem implantações de escala vertical do HANA de até 24 TB e implantações de expansão do SAP HANA de até 120 TB. É possível declarar hoje que quase todos os cenários SAP locais também podem ser executados no Azure.

Para obter uma descrição geral dos cenários e de alguns cenários sem suporte, confira o documento Carga de trabalho do SAP em cenários compatíveis com a máquina virtual do Azure.

Confira esses cenários e algumas das condições que foram indicadas como sem suporte na documentação referenciada ao longo de todo o planejamento e do desenvolvimento da arquitetura que você deseja implantar no Azure.

Em geral, o padrão de implantação mais comum é um cenário entre locais, como exibido

VPN com conectividade Site a Site (entre instalações)

O motivo para muitos clientes aplicarem um padrão de implantação entre instalações é que ele é mais transparente para que todos os aplicativos se estendam localmente no Azure usando o Azure ExpressRoute e tratem o Azure como um datacenter virtual. À medida que mais ativos forem movidos para o Azure, a infraestrutura de rede e a infraestrutura implantada do Azure aumentarão, e os ativos locais serão reduzidos adequadamente. Tudo transparente para usuários e aplicativos.

Para implantar sistemas SAP no Azure IaaS ou IaaS em geral, é importante entender as diferenças significativas entre as ofertas de terceirizados tradicionais ou hosters e as ofertas de IaaS. Whereas the traditional hoster or outsourcer adapts infrastructure (network, storage and server type) to the workload a customer wants to host, it is instead the customer's or partner's responsibility to characterize the workload and choose the correct Azure components of VMs, storage, and network for IaaS deployments.

Para coletar dados para o planejamento de sua implantação no Azure, é importante:

Avaliar quais produtos SAP têm suporte para execução em VMs do Azure
Avaliar quais versões específicas do sistema operacional têm suporte com VMs específicas do Azure para esses produtos SAP
Avaliar quais versões de DBMS têm suporte para seus produtos SAP com VMs específicas do Azure
Avaliar se algumas das versões necessárias do SO/DBMS exigem que você execute a versão do SAP, a atualização do pacote de suporte e as atualizações de kernel para obter uma configuração com suporte
Avaliar se você precisa migrar para sistemas operacionais diferentes a fim de implantar no Azure.

Os detalhes sobre os componentes do SAP com suporte no Azure, unidades de infraestrutura do Azure com suporte e versões do sistema operacional relacionadas e versões do DBMS são explicados no artigo Quais softwares SAP são compatíveis com as implantações do Azure. Os resultados obtidos da avaliação de versões válidas do SAP, do sistema operacional e das versões do DBMS têm um grande impacto sobre os esforços para mover os sistemas SAP para o Azure. Os resultados dessa avaliação definirão se pode haver esforços de preparação significativos nos casos em que são necessárias atualizações de versão do SAP ou alterações de sistemas operacionais.

Regiões do Azure

Os serviços do Azure da Microsoft são coletados nas regiões do Azure. Uma região do Azure é uma coleção de datacenters que contém o hardware e a infraestrutura que executa e hospeda os diferentes serviços do Azure. Essa infraestrutura inclui um grande número de nós que funcionam como nós de computação ou nós de armazenamento ou que executam a funcionalidade de rede.

Para obter uma lista das diferentes regiões do Azure, confira o artigo Regiões geográficas do Azure. Nem todas as regiões do Azure oferecem os mesmos serviços. Dependendo do produto SAP que você deseja executar e do sistema operacional e DBMS relacionados a ele, você pode acabar em uma situação em que uma determinada região não oferece os tipos de VM necessários. Isso se aplica sobretudo à execução do SAP HANA, em que, normalmente, você precisa de VMs da série M/Mv2. Essas famílias de VMs são implantadas somente em um subconjunto das regiões. Você pode descobrir exatamente quais VMs, tipos, tipos de armazenamento do Azure ou outros serviços do Azure estão disponíveis em quais regiões com a ajuda do site Produtos disponíveis por região. À medida que você inicia o planejamento e tem certas regiões em mente como a região primária e, eventualmente, a região secundária, você precisa investigar primeiro se os serviços necessários estão disponíveis nessas regiões.

Zonas de Disponibilidades

Várias das regiões do Azure implementaram um conceito chamado Zonas de Disponibilidade. As Zonas de disponibilidade são locais separados fisicamente dentro de uma região do Azure. Cada Zona de disponibilidade é composta por um ou mais datacenters equipados com energia, resfriamento e rede independentes. Por exemplo, implantar duas VMs em duas Zonas de Disponibilidade do Azure e implementar uma estrutura de alta disponibilidade para seu sistema do SAP DBMS ou os serviços centrais do SAP oferece o melhor SLA no Azure. Para esse SLA de máquina virtual em particular no Azure, verifique a versão mais recente de SLAs de Máquina Virtual. Como as regiões do Azure se desenvolveram e se expandiram rapidamente nos últimos anos, a topologia dessas regiões, o número de datacenters físicos, a distância entre esses datacenters e a distância entre as Zonas de Disponibilidade do Azure podem ser diferentes. E, com isso, a latência de rede.

O princípio de Zonas de Disponibilidade não se aplica ao serviço específico do HANA de Instâncias Grandes do HANA. Os contratos de nível de serviço para Instâncias Grandes do HANA podem ser encontrados no artigo SLA para SAP HANA em Instâncias Grandes do Azure

Domínios de falha

Domínios de falha representam uma unidade física de falha, relacionada fortemente à infraestrutura física contida nos data centers e, embora uma folha ou rack físico possa ser considerado um domínio de falha, não há nenhum mapeamento direto um-para-um entre os dois.

Quando você implanta várias máquinas virtuais como parte de um sistema SAP nos Serviços da Máquina Virtual do Microsoft Azure, pode influenciar o controlador de malha do Azure a implantar seu aplicativo em diferentes domínios de falha, atendendo, assim, aos requisitos mais elevados de SLAs de disponibilidade. No entanto, a distribuição dos domínios de falha em uma unidade de escala do Azure (coleção de centenas de nós de computação ou nós de armazenamento e rede) ou a atribuição de VMs a um domínio de falha específico é algo sobre o que você não tem controle direto. Para comandar o controlador de malha do Azure a implantar um conjunto de VMs em diferentes domínios de falha, é necessário atribuir um conjunto de disponibilidade do Azure para as VMs no momento da implantação. Para saber mais sobre conjuntos de disponibilidade do Azure, confira o capítulo Conjuntos de disponibilidade do Azure deste documento.

Domínios de atualização

Domínios de Atualização representam uma unidade lógica que ajudam a determinar como uma máquina virtual em um sistema SAP, que consiste em instâncias SAP em execução em várias VMs, é atualizada. Quando ocorre uma atualização, o Microsoft Azure percorre o processo de atualizar esses domínios de atualização individualmente. Ao distribuir as VMs no momento da implantação em diferentes domínios de atualização, você pode proteger seu sistema SAP parcialmente contra um potencial tempo de inatividade. Para forçar o Azure para implantar as VMs de um sistema SAP espalhados em diferentes domínios de atualização, você precisa definir um atributo específico no momento da implantação de cada VM. Semelhante aos domínios de falha, uma unidade de escala do Azure é dividida em vários domínios de atualização. Para comandar o controlador de malha do Azure a implantar um conjunto de VMs em diferentes domínios de atualização, é necessário atribuir um conjunto de disponibilidade do Azure para as VMs no momento da implantação. Para saber mais sobre conjuntos de disponibilidade do Azure, confira o capítulo Conjuntos de disponibilidade do Azure abaixo.

Conjuntos de disponibilidade do Azure

As Máquinas Virtuais do Azure dentro de um conjunto de disponibilidade do Azure são distribuídas pelo controlador de malha do Azure em diferentes domínios de falha e de atualização. O objetivo da distribuição por diferentes domínios de falha e de atualização é impedir que todas as VMs de um sistema SAP sejam desligadas em caso de manutenção da infraestrutura ou de uma falha em um domínio de falha. Por padrão, as VMs não fazem parte de um conjunto de disponibilidade. A participação de uma VM em um conjunto de disponibilidade é definida no momento da implantação ou posteriormente, por meio da reconfiguração ou reimplantação de uma VM.

Para entender o conceito dos conjuntos de disponibilidade do Azure e a maneira como eles se relacionam com os Domínios de Atualização e de Falha, leia este artigo.

Conforme você define os conjuntos de disponibilidade e tenta combinar várias VMs de diferentes famílias dentro de um conjunto, talvez encontre problemas que impeçam você de incluir determinado tipo de VM em um conjunto de disponibilidade. O motivo é que o conjunto de disponibilidade está associado à unidade de escala que contém determinado tipo de host de computação. E determinado tipo de host de computação só pode executar tipos específicos de famílias de VMs. Por exemplo, se você criar um conjunto de disponibilidade, implantar a primeira VM nesse conjunto, escolher um tipo de VM da família Esv3 e, em seguida, tentar implantar como segunda VM uma da família M, a segunda alocação será rejeitada. O motivo é que as VMs da família Esv3 não estão em execução no mesmo hardware de host que as máquinas virtuais da família M. O mesmo problema pode ocorrer quando você tenta redimensionar VMs e mover uma VM para fora da família Esv3 para um tipo de VM da família M. No caso do redimensionamento para uma família de VMs que não pode ser hospedada no mesmo hardware do host, é preciso desligar todas as VMs em seu conjunto de disponibilidade e redimensioná-las para que possam ser executadas no outro tipo de computador host. Para os SLAs de VMs que são implantados no conjunto de disponibilidade, confira o artigo SLAs de Máquina Virtual.

O princípio do conjunto de disponibilidade e de atualização e domínio de falha relacionados não se aplica ao serviço específico do HANA de Instâncias Grandes do HANA. Os contratos de nível de serviço para Instâncias Grandes do HANA podem ser encontrados no artigo SLA para SAP HANA em Instâncias Grandes do Azure.

Importante

Os conceitos de Zonas de Disponibilidade do Azure e conjuntos de disponibilidade do Azure são mutuamente exclusivos. Isso significa que você pode implantar um par ou várias VMs em uma Zona de Disponibilidade específica ou em um conjunto de disponibilidade do Azure. Mas não em ambos.

Regiões emparelhadas do Azure

O Azure está oferecendo pares de regiões do Azure em que a replicação de determinados dados está habilitada entre esses pares fixos de regiões. O emparelhamento de região está documentado no artigo Replicação entre regiões no Azure: continuidade dos negócios e recuperação de desastres. Como o artigo descreve, a replicação de dados é ligada aos tipos de armazenamento do Azure que podem ser configurados por você para replicar na região emparelhada. Confira também o artigo Redundância de armazenamento em uma região secundária. Os tipos de armazenamento que permitem esse tipo de replicação não são adequados para a carga de trabalho do gerenciador de banco de dados. Assim, a usabilidade da replicação do armazenamento do Azure seria limitada ao armazenamento de blobs do Azure (como para fins de backup) ou a outros cenários de armazenamento de alta latência. Ao verificar as regiões emparelhadas e os serviços que quer usar como sua região primária ou secundária, você poderá encontrar situações em que os serviços do Azure e/ou os tipos de VM que pretende usar na região primária não estão disponíveis na região emparelhada. Ou pode encontrar uma situação em que a região emparelhada do Azure não é aceitável por motivos de conformidade de dados. Nesses casos, você precisa usar uma região não emparelhada como região de recuperação de desastres ou secundária. Assim, você precisa tomar cuidado com a replicação de parte dos dados que o Azure replicaria por conta própria. Um exemplo de como replicar seu Active Directory e o DNS para sua região de recuperação de desastres aparece no artigo Configurar a recuperação de desastres para Active Directory e DNS

Serviços de máquinas virtuais do Azure

O Azure oferece uma grande variedade de máquinas virtuais que você pode selecionar para implantar. Não há a necessidade de compras antecipadas de tecnologia e infraestrutura. A oferta de serviço de VM do Azure simplifica a manutenção e operação de aplicativos, fornecendo computação sob demanda e armazenamento para hospedar, dimensionar e gerenciar aplicativos Web e aplicativos conectados. O gerenciamento de infraestrutura é automatizado com uma plataforma projetada para alta disponibilidade e dimensionamento dinâmico, para atender às necessidades de uso com a opção de vários modelos de preços diferentes.

Posicionamento de Serviços da Máquina Virtual do Microsoft Azure

Com as máquinas virtuais do Azure, a Microsoft permite implantar imagens de servidor personalizadas no Azure como instâncias de IaaS. Ou você pode escolher entre uma ampla seleção de imagens de sistema operacional personalizáveis do Azure Marketplace.

Do ponto de vista operacional, o Serviço da Máquina Virtual do Azure oferece experiências semelhantes a máquinas virtuais implantadas localmente. Você é responsável pela administração, pelas operações e também pela aplicação de patches do sistema operacional específico, em execução em uma VM do Azure e em seus aplicativos nessa VM. A Microsoft não fornece mais serviços além da hospedagem dessa VM em sua infraestrutura do Azure (infraestrutura como serviço – IaaS). Para a carga de trabalho do SAP que você implanta como cliente, a Microsoft não tem nenhuma oferta além das ofertas de IaaS.

A plataforma Microsoft Azure é uma plataforma multilocatário. Como resultado, os recursos de armazenamento, de rede e de computação que hospedam VMs do Azure são, com algumas exceções, compartilhadas entre os locatários. Lógica de cotas e limitação inteligente é usada para evitar que um locatário afete o desempenho de outro locatário (vizinho barulhento) de forma drástica. Especialmente na certificação da plataforma do Azure para SAP HANA, a Microsoft precisa provar o isolamento de recursos para casos em que várias VMs podem ser executadas no mesmo host regularmente para o SAP. Embora a lógica do Azure tente manter as variações de largura de banda experimentadas pequenas, plataformas altamente compartilhadas tendem a apresentar variações maiores na disponibilidade de recurso/largura de banda do que muitos clientes podem encontrar em suas implantações locais. A probabilidade de que um sistema SAP no Azure possa sofrer variações maiores do que aquelas em um sistema local precisa ser levada em conta.

Máquinas Virtuais do Azure para carga de trabalho do SAP

Para a carga de trabalho do SAP, reduzimos a seleção para famílias de VM diferentes que são adequadas para carga de trabalho do SAP e carga de trabalho do SAP HANA mais especificamente. A maneira como você encontra o tipo de VM correto e sua capacidade de trabalhar por meio da carga de trabalho do SAP é descrita no documento Qual software do SAP é compatível com implantações do Azure.

Observação

Os tipos de VM que são certificados para carga de trabalho do SAP, não há excesso de provisionamento de recursos de CPU e memória.

Além da seleção de tipos de VMs puramente compatíveis, você também precisa verificar se esses tipos de VM estão disponíveis em uma região específica com base no site Produtos disponíveis por região. Porém, o mais importante é que você precisa avaliar se:

Recursos de CPU e memória de diferentes tipos de VM
Largura de banda IOPS de diferentes tipos de VM
Recursos de rede de diferentes tipos de VM
Número de discos que podem ser anexados
Capacidade de aproveitar determinados tipos de armazenamento do Azure

atendem às suas necessidades. A maioria desses dados pode ser encontrada aqui (Linux) e aqui (Windows) para um tipo de VM em particular.

Como modelo de preços, você tem várias opções de preços diferentes, listadas como:

Pré-pago
Um ano reservado
Três anos reservados
Preços de spot

O preço de cada uma das diferentes ofertas com diferentes ofertas de serviço em relação a sistemas operacionais e variadas regiões está disponível no site Preços de Máquinas Virtuais do Linux e Preços de Máquinas Virtuais do Windows. Para obter informações e a flexibilidade de instâncias reservadas de um ano e de três anos, confira estes artigos:

Para obter mais informações sobre preços de spot, leia o artigo Máquinas virtuais spot do Azure. Os preços do mesmo tipo de VM também podem variar entre regiões diferentes do Azure. Para alguns clientes, vale a pena implantar em uma região do Azure menos dispendiosa.

Além disso, o Azure oferece o conceito de host dedicado. Esse conceito proporciona mais controle sobre os ciclos de aplicação de patches feitos pelo Azure. Você pode cronometrar a aplicação de patch de acordo com sua programação. Essa oferta destina-se especificamente a clientes com uma carga de trabalho que pode não seguir o ciclo normal de cargas de trabalho. Para saber sobre os conceitos de ofertas de hosts dedicados do Azure, leia o artigo Host Dedicado do Azure. O uso dessa oferta tem suporte na carga de trabalho do SAP e é empregado por vários clientes do SAP que desejam ter mais controle sobre a aplicação de patches de infraestrutura e eventuais planos de manutenção da Microsoft. Para obter mais informações sobre como a Microsoft mantém e corrige a infraestrutura do Azure que hospeda máquinas virtuais, leia o artigo Manutenção para máquinas virtuais no Azure.

Máquinas virtuais de Geração 1 e de Geração 2.

O hipervisor da Microsoft é capaz de lidar com duas gerações diferentes de máquinas virtuais. Esses formatos são chamados Geração 1 e Geração 2. A Geração 2 foi introduzida no ano de 2012 com o hipervisor do Windows Server 2012. O Azure começou a usar máquinas virtuais de Geração 1. À medida que você implanta máquinas virtuais do Azure, o padrão ainda é usar o formato de Geração 1. Enquanto isso, você também pode implantar formatos de VM de Geração 2. O artigo Suporte para VMs de Geração 2 no Azure lista as famílias de VM do Azure que podem ser implantadas como VM de Geração 2. Este artigo também lista as diferenças funcionais importantes das máquinas virtuais de Geração 2, pois elas podem ser executadas na nuvem privada do Hyper-V e no Azure. E o mais importante: este artigo também lista as diferenças funcionais entre máquinas virtuais de Geração 1 e VMs de Geração 2, já que elas são executadas no Azure.

Observação

Há diferenças funcionais de VMs de Geração 1 e Geração 2 em execução no Azure. Leia o artigo Suporte para VMs da Geração 2 no Azure para ver uma lista dessas diferenças.

Não é possível mover uma VM existente de uma geração para outra. Para mudar a geração da máquina virtual, você precisa implantar uma nova VM da geração desejada e reinstalar o software que está sendo executado na máquina virtual da geração. Essa mudança afeta apenas a imagem VHD de base da VM, e não os discos de dados ou os compartilhamentos de NFS ou de SMB anexados. Os compartilhamentos de discos de dados, NFS ou SMB que originalmente foram atribuídos, por exemplo, em uma VM de Geração 1.

Observação

A implantação de VMs da família Mv1 como VMs de Geração 2 é possível desde o início de maio de 2020. Com isso, pode haver menos upsizings e downsizings entre as VMs da família Mv1 e Mv2.

Armazenamento: Armazenamento do Microsoft Azure e Discos de Dados

Máquinas Virtuais do Microsoft Azure utilizam diferentes tipos de armazenamento. Ao implementar aplicativos SAP nos Serviços da Máquina Virtual do Azure, é importante entender as diferenças entre esses dois tipos principais de armazenamento:

Armazenamento volátil não persistente.
Armazenamento persistente.

As VMs do Azure oferecem discos não persistentes depois que uma VM é implantada. No caso de uma reinicialização da VM, todo o conteúdo nessas unidades será apagado. Portanto, é um dado que arquivos de dados e arquivos de log/restauração de bancos de dados sob nenhuma circunstância encontra-se nessas unidades são persistentes. Pode haver exceções para alguns dos bancos de dados, onde essas unidades não persistentes poderiam ser adequadas para espaços de tabela temporários e tempdb. No entanto, evite usar essas unidades VMs da série A, pois essas unidades não persistentes são limitadas na taxa de transferência dessa família VM. Para obter mais detalhes, leia o artigo Entendendo a unidade temporária em VMs do Windows no Azure

Windows

A unidade D:\ em uma VM do Azure é uma unidade não persistente que é apoiada por alguns discos locais no nó de computação do Azure. Como ela não é persistente, isso significa que as alterações feitas no conteúdo na unidade D:\ são perdidas quando a VM é reiniciada. Por “alterações”, como arquivos armazenados, diretórios criados, aplicativos instalados etc.

Linux

As VMs do Azure do Linux montam automaticamente uma unidade em /mnt/resource, que é uma unidade não persistente apoiada por discos locais no nó de computação do Azure. Como ela não é persistente, isso significa que as alterações feitas no conteúdo em /mnt/resource são perdidas quando a VM é reinicializada. Por alterações, como arquivos armazenados, diretórios criados, aplicativos instalados etc.

Contas de armazenamento do Azure

Ao implantar serviços ou VMs no Azure, a implantação de VHDs e Imagens de VM é organizada em unidades chamadas contas de Armazenamento do Microsoft Azure. As contas de armazenamento do Azure têm limitações em IOPS, taxa de transferência ou tamanhos que podem conter. No passado, essas limitações documentadas em:

desempenhavam um papel importante no planejamento de uma implantação do SAP no Azure. Dependia de você gerenciar o número de discos persistentes em uma conta de armazenamento. Você precisava gerenciar as contas de armazenamento e, eventualmente, criar contas de armazenamento para criar mais discos persistentes.

Nos últimos anos, a introdução dos discos gerenciados do Azure aliviou você dessas tarefas. A recomendação para implantações do SAP é aproveitar os discos gerenciados do Azure em vez de gerenciar contas de armazenamento do Azure por conta própria. Os discos gerenciados do Azure distribuirão discos entre diferentes contas de armazenamento, portanto, os limites das contas de armazenamento individuais não serão excedidos.

Em uma conta de armazenamento, você tem um tipo de conceito de pasta chamado de “contêineres”, que pode ser usado para agrupar determinados discos em contêineres específicos.

Dentro do Azure, um nome de VHD/disco segue a seguinte conexão de nomenclatura, que precisa fornecer um nome exclusivo para o VHD contido no Azure:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

A cadeia de caracteres acima deve identificar exclusivamente o VHD/disco que está armazenado no Armazenamento do Microsoft Azure.

Tipos de armazenamento persistentes do Azure

O Azure oferece várias opções de armazenamento persistentes que podem ser usadas para a carga de trabalho do SAP e para componentes de pilha específicos do SAP. Para obter mais detalhes, leia o documento Armazenamento do Azure para cargas de trabalho SAP.

Rede do Microsoft Azure

O Microsoft Azure fornece uma infraestrutura de rede que permite o mapeamento de todos os cenários que desejamos criar com software SAP. Os recursos são:

Acesso externo diretamente às VMs via ssh/VNC ou Serviços de Terminal do Windows
Acesso a serviços e portas específicas usadas por aplicativos nas VMs
Comunicação interna e resolução de nomes entre um grupo de VMs implantadas como VMs do Azure
Conectividade entre instalações entre a rede local de um cliente e a rede do Azure
Conectividade entre Regiões do Azure ou data centers entre sites do Azure

Para obter mais informações, confira a documentação da Rede Virtual.

Há muitas possibilidades diferentes para configurar a resolução de nomes e IPs no Azure. Também há um serviço DNS do Azure que pode ser usado, em vez de configurar seu próprio servidor DNS. Encontre mais informações neste artigo e nesta página.

Para cenários entre instalações ou híbridos, contamos com o fato de que o OpenLDAP/AD/DNS local foi estendido por meio de VPN ou conexão privada ao Azure. Para determinados cenários, conforme documentado aqui, é necessário ter uma réplica do AD/OpenLDAP instalada no Azure.

Já que a resolução de rede e de nomes é uma parte essencial da implantação de banco de dados para um sistema do SAP, esse conceito é abordado em mais detalhes no Guia de implantação de DBMS.

Redes Virtuais do Azure

Ao criar uma Rede Virtual do Azure, você pode definir o intervalo de endereços dos endereços IP privados alocados pela funcionalidade DHCP do Azure. Em cenários entre instalações, o intervalo de endereços IP definido ainda será alocado pelo Azure, usando DHCP. No entanto, a resolução de nomes de domínio é feita localmente (supondo que as VMs são uma parte de um domínio local) e, portanto, pode resolver endereços além dos diferentes Serviços de Nuvem do Azure.

Cada máquina Virtual no Azure precisa ser conectado a uma Rede Virtual.

Mais detalhes podem ser encontrados neste artigo e nesta página.

Observação

Por padrão, quando uma VM é implantada, não é possível alterar a configuração de rede virtual. As configurações de TCP/IP devem ser deixadas para o servidor DHCP do Azure. O comportamento padrão é a atribuição de IP dinâmico.

O endereço MAC da placa de rede virtual pode mudar, por exemplo, depois de redimensionar, e o SO convidado Windows ou Linux seleciona a nova placa de rede e usa automaticamente o DHCP para atribuir os endereços IP e DNS nesse caso.

Atribuição de endereço IP estático

É possível atribuir endereços IP reservados ou fixos às VMs em uma Rede Virtual do Azure. Executar as VMs em uma Rede Virtual do Azure oferece uma ótima possibilidade de aproveitar essa funcionalidade se necessário ou quando exigido por alguns cenários. A atribuição de IPS permanece válida durante toda a existência da VM, independentemente de a VM estar em execução ou desligada. Como resultado, você precisa levar o número total de VMs (VMs em execução e paradas) em consideração ao definir o intervalo de endereços IP para a Rede Virtual. O endereço IP permanecerá atribuído até que a VM seja excluída juntamente com sua interface de rede ou até que o endereço IP seja desatribuído novamente. Para obter mais informações, leia este artigo.

Observação

Você deve atribuir endereços IP estáticos por meio do Azure para vNICs individuais. Você não deve atribuir endereços IP estáticos dentro do SO convidado para um vNIC. Alguns serviços do Azure, como o serviço de Backup do Azure, dependem do fato de que pelo menos o vNIC primário esteja definido como DHCP, e não para endereços IP estáticos. Veja também o documento Solucionar problemas de backup da máquina virtual do Azure.

Endereços IP secundários para virtualização de nome de host do SAP

Cada placa de adaptador de rede da Máquina Virtual do Azure pode ter vários endereços IP atribuídos a ela. Esse IP secundário pode ser usado para os nomes do host virtuais do SAP que são mapeados para um registro PTR/DNS A, se necessário. Os endereços IP secundários precisam ser atribuídos à configuração de IP dos vNICs do Azure de acordo com este artigo e configurados no SO, pois os IPs secundários não são atribuídos por meio do DHCP. Cada IP secundário precisa ser da mesma sub-rede à qual o vNIC está associado. O uso o IP flutuante do Azure Load Balancer não é um secundário compatível em configurações de IP secundário, como clusters Pacemaker. Nesse caso, o IP do Load Balancer habilita os nomes de host virtuais do SAP. Confira também a observação do SAP #962955 com diretrizes gerais do uso de nomes de host virtual.

Várias NICs por VM

Você pode definir várias vNICs (placas de interface de rede virtual) para uma Máquina Virtual do Azure. Com a capacidade de ter várias vNICs, você pode começar a configurar o tráfego de rede no qual, por exemplo, o tráfego do cliente é roteado por meio de uma vNIC e o tráfego de back-end é roteado por meio de uma segunda vNIC. Dependendo do tipo de VM, há diferentes limitações quanto ao número de vNICs que podem ser atribuídas a uma VM. Restrições, funcionalidades e detalhes exatos podem ser encontradas nesses artigos:

Conectividade site a site

Entre instalações refere-se a VMs do Azure e locais vinculadas por uma conexão VPN permanente e transparente. Espera-se que esse se torne o padrão de implantação SAP mais comum no Azure. Pressupõe-se que os procedimentos operacionais e processos com instâncias SAP no Azure funcionem de modo transparente. Isso significa que você deve ser capaz de imprimir a partir desses sistemas, bem como usar o TMS (sistema de gerenciamento de transporte) SAP para transportar alterações de um sistema de desenvolvimento no Azure para um sistema de teste que é implantado localmente. Encontre mais documentações relacionadas ao site a site neste artigo

Dispositivo de túnel VPN

Para criar uma conexão site a site (data center local para data center do Azure), você precisa obter e configurar um dispositivo VPN ou usar o RRAS (Serviço de Roteamento e Acesso Remoto), que foi introduzido como um componente de software com o Windows Server 2012.

Conexão site a site entre locais e o Azure

A Figura acima mostra que duas assinaturas do Azure têm subintervalos de endereços IP reservados para uso em redes virtuais no Azure. A conectividade da rede local para o Azure é estabelecida via VPN.

VPN ponto a site

VPN ponto a site requer que cada computador cliente conecte-se com seu próprio VPN ao Azure. Para os cenários SAP que estamos vendo, a conectividade ponto a site não é prática. Portanto, não é feita nenhuma referência posterior à conectividade VPN ponto a site.

Mais informações podem ser encontradas aqui

VPN de múltiplos sites

Hoje em dia, o Azure também oferece a possibilidade de criar a conectividade VPN de múltiplos sites para uma assinatura do Azure. Antes, uma única assinatura era limitada a uma ligação VPN site a site. Essa limitação desapareceu com ligações VPN de múltiplos sites para uma única assinatura. Isso torna possível aproveitar mais de uma Região do Azure para uma assinatura específica por meio de configurações entre instalações.

Para obter mais documentação, confira este artigo

Conexão VNet a VNet

Usando VPN de múltiplos sites, você precisa configurar uma Rede Virtual do Azure separada em cada uma das regiões. No entanto, com frequência, você tem o requisito de que os componentes de software em diferentes regiões devem comunicar-se uns com os outros. Idealmente, essa comunicação não deve ser roteada de uma Região do Azure para local e daí para outra Região do Azure. Como atalho, o Azure oferece a possibilidade de configurar uma conexão de uma Rede Virtual do Azure em uma região a outra Rede Virtual do Azure hospedada em outra região. Essa funcionalidade é chamada de conexão de VNet a VNet. Mais detalhes sobre essa funcionalidade podem ser encontrados aqui: configurar uma conexão de gateway de VPN VNet para VNet usando o portal do Azure.

Conexão Privada ao Azure ExpressRoute

O Microsoft Azure ExpressRoute permite a criação de conexões privadas entre data centers do Azure e a infraestrutura de local do cliente, ou então em um ambiente de colocalização. O ExpressRoute é oferecido por diversos provedores VPN MPLS (com pacotes comutados) ou outros Provedores de Serviços de Rede. As conexões de ExpressRoute não passam pela Internet pública. As conexões de ExpressRoute oferecem maior segurança, mais confiabilidade por meio de múltiplos circuitos paralelos, velocidades maiores e latências menores do que conexões típicas pela Internet.

Encontre mais detalhes sobre a Azure ExpressRoute e ofertas aqui:

O ExpressRoute permite várias assinaturas do Azure por meio de um circuito de ExpressRoute, conforme documentado aqui

Túnel forçado em caso de instalações cruzadas

Para VMs que ingressam em domínios locais por meio de site a site, ponto a site ou ExpressRoute, você precisa garantir que as configurações de proxy da Internet estejam sendo implantadas para todos os usuários nessas VMs também. Por padrão, o software em execução nas VMs ou usuários usando um navegador para acessar a Internet não passariam pelo proxy da empresa, conectariam-se diretamente à Internet por meio do Azure. Mas mesmo a configuração do proxy não é uma solução perfeita para direcionar o tráfego por meio do proxy da empresa, pois verificar o proxy é responsabilidade do software e dos serviços. Se o software em execução na VM não está fazendo isso ou se um administrador manipular as configurações, o tráfego para a Internet poderá ser novamente desviado diretamente através do Azure para a Internet.

Para evitar essa conectividade de internet direta, você pode configurar o Túnel Forçado com conectividade site a site entre locais e o Azure. A descrição detalhada do recurso Túnel Forçado foi publicada aqui: configurar o túnel forçado usando o modelo de implantação clássico

O Túnel Forçado com ExpressRoute está habilitado por clientes que anunciam uma rota padrão por meio de sessões de emparelhamento via protocolo BGP do ExpressRoute.

Resumo da rede do Azure

Este capítulo continha muitos pontos importantes sobre a Rede do Azure. Eis aqui um resumo dos pontos principais:

Redes Virtuais do Azure permitem que você coloque uma estrutura de rede em sua implantação do Azure. Redes virtuais podem ser isoladas umas das outras ou, com a ajuda de Grupos de Segurança de Rede, o tráfego entre VNets pode ser controlado.
As Redes Virtuais do Azure podem ser aproveitadas para atribuir intervalos de endereços IP às VMs ou atribuir endereços IP fixos às VMs
Para configurar uma conexão site a site ou ponto a site, você precisa primeiro criar uma Rede Virtual do Azure
Após a implantação de uma máquina virtual, não é possível alterar a Rede Virtual atribuída à VM

Cotas nos serviços da máquina virtual do Azure

Precisamos ser claros sobre o fato de que a infraestrutura de rede e de armazenamento é compartilhada entre as VMs que executam uma variedade de serviços na infraestrutura do Azure. Como nos data centers do cliente, o sobreprovisionamento de alguns recursos de infraestrutura ocorre até um certo grau. A plataforma Microsoft Azure usa cotas de disco, CPU, rede e outras para limitar o consumo de recursos e para manter o desempenho consistente e previsível. Os diferentes tipos de VM (A5, A6 etc.) têm diferentes cotas para o número de discos, CPU, RAM e rede.

Observação

Recursos de CPU e memória dos tipos de VM aos quais o SAP dá suporte são pré-alocados nos nós de host. Isso significa que, após a VM ser implantada, os recursos no host estarão disponíveis conforme definido pelo tipo de VM.

Ao planejar e dimensionar soluções SAP no Azure, as cotas para cada tamanho de máquina virtual devem ser consideradas. As cotas de VM são descritas aqui (Linux) e aqui (Windows).

As cotas descritas representam os valores máximos teóricos. O limite de IOPS por disco pode ser obtido com o E/Ss pequenas (8 KB), mas é possível que não possa ser obtido com o E/Ss grandes (1 MB). O limite de IOPS é aplicado na granularidade de discos individuais.

Como uma árvore de decisão grosseira para decidir se um sistema SAP se ajusta aos Serviços da Máquina Virtual do Azure e seus recursos ou se um sistema existente precisa ser configurado de forma diferente para implantar o sistema no Azure, a árvore de decisão abaixo pode ser usada:

Árvore de decisão para decidir a capacidade de implantar um sistema SAP no Azure

as informações mais importantes para começar são o requisito de SAPS para um determinado sistema do SAP. Os requisitos de SAPS precisam ser divididos entre a parte do DBMS e a parte do aplicativo SAP, mesmo que o sistema SAP já esteja implantado localmente em uma configuração de duas camadas. Para os sistemas existentes, os SAPS relacionados ao hardware em uso geralmente podem ser determinados ou estimados com base nos parâmetros de comparação de SAP existentes. Os resultados podem ser encontrados na página Sobre o SAP Standard Application Benchmarks. Para sistemas SAP recém-implantados, você deverá ter feito um exercício de dimensionamento que deve determinar os requisitos de SAPS do sistema.
para sistemas existentes, o volume de E/S e operações de E/S por segundo no servidor DBMS devem ser medidos. Para sistemas recém-planejados, o exercício de dimensionamento para o novo sistema também deverá dar uma ideia dos requisitos de E/S no lado do DBMS. Se não tiver certeza, eventualmente, você precisará realizar uma prova de conceito.
compare o requisito de SAPS do servidor DBMS com os SAPS que os diferentes tipos de VM do Azure podem fornecer. As informações sobre os SAPS dos diferentes tipos de VM do Azure estão documentadas na Nota do SAP 1928533. O foco deve ser primeiro na VM de DBMS, já que a camada de banco de dados é a camada em um sistema SAP NetWeaver que não é escalado horizontalmente na maioria das implantações. Por outro lado, a camada do aplicativo SAP pode ser escalada horizontalmente. Se nenhum dos tipos de VM do Azure aos quais a SAP dá suporte podem oferecer os SAPS necessários, a carga de trabalho do sistema SAP planejado não pode ser executada no Azure. Você precisará implantar o sistema localmente ou precisará alterar o volume de carga de trabalho para o sistema.
conforme documentado aqui (Linux) e aqui (Windows), o Azure impõe uma cota de IOPS por disco independentemente de você usar o Armazenamento Standard ou o Armazenamento Premium. Dependo do tipo de VM, o número de discos que pode ser montado varia. Como resultado, você pode calcular um número de IOPS máximo que pode ser alcançado com cada um dos diferentes tipos de VM. Dependendo do layout do arquivo de banco de dados, você pode distribuir discos para que se tornem um volume no SO convidado. No entanto, se o volume de IOPS atual de um sistema SAP implantado exceder os limites calculados do maior tipo de VM do Azure e se não houver nenhuma chance de compensar com mais memória, a carga de trabalho do sistema SAP poderá ser gravemente afetada. Nesses casos, você pode atingir um ponto em que você não deve implantar o sistema no Azure.
especialmente em sistemas do SAP implantados localmente em configurações de duas camadas, as chances são de que o sistema talvez precise ser configurado no Azure em uma configuração de três camadas. Nesta etapa, você precisa verificar se há um componente na camada do aplicativo SAP que não pode ser escalado horizontalmente e que não se ajusta aos recursos de CPU e memória oferecidos pelos diferentes tipos de VM do Azure. Se realmente existir tal componente, o sistema SAP e a carga de trabalho não poderão ser implantados no Azure. No entanto, se for possível escalar horizontalmente os componentes do aplicativo SAP em várias VMs do Azure, o sistema poderá ser implantado no Azure.

se os componentes de camada de aplicativo do DBMS e SAP puderem ser executados em VMs do Azure, a configuração precisará ser definida em relação a:

Número de VMs do Azure
Tipos de VM para os componentes individuais
Número de VHDs na VM de DBMS para fornecer IOPS suficientes

Gerenciar ativos do Azure

Portal do Azure

O Portal do Azure é uma das três interfaces para gerenciar implantações de VM do Azure. As tarefas básicas de gerenciamento, como implantar VMs com base em imagens, podem ser feitas por meio do Portal do Azure. Além disso, a criação de contas de armazenamento, redes virtuais e outros componentes do Azure também são tarefas que o portal do Azure pode realizar bem. No entanto, funcionalidades como carregar VHDs do local para o Azure ou copiar um VHD dentro do Azure são tarefas que exigem ferramentas de terceiros ou administração por meio do PowerShell ou CLI.

Portal do Microsoft Azure - Visão geral sobre máquina virtual

Tarefas de administração e configuração para a instância de Máquina Virtual são possíveis de dentro do Portal do Azure.

Além de reiniciar e desligar uma máquina Virtual, você também pode anexar, desanexar e criar discos de dados para a instância de Máquina Virtual, capturar a instância para preparação de imagem e configurar o tamanho da instância de Máquina Virtual.

O Portal do Azure oferece as funcionalidades básicas para implantar e configurar VMs e muitos outros serviços do Azure. No entanto, nem todas as funcionalidades disponíveis são cobertas pelo Portal do Azure. No Portal do Azure, não é possível executar tarefas como:

Carregar VHDs no Azure
Copiar VMs

Gerenciamento via cmdlets do Microsoft Azure PowerShell

O Windows PowerShell é uma estrutura poderosa e extensível que foi amplamente adotada por clientes implantando grandes quantidades de sistemas no Azure. Após a instalação dos cmdlets do PowerShell em um desktop, laptop ou estação de gerenciamento dedicada, os cmdlets do PowerShell podem ser executados remotamente.

O processo de habilitação de um laptop/desktop local para usar cmdlets do Azure PowerShell e como configurá-los para uso com as assinaturas do Azure é descrito neste artigo.

Etapas mais detalhadas de como instalar, atualizar e configurar os cmdlets do Azure PowerShell também podem ser encontradas em Instalar o módulo do Azure PowerShell. Até agora, a experiência do cliente indica que o PowerShell é com certeza a ferramenta mais eficiente para implantar VMs e criar etapas personalizadas na implantação delas. Todos os clientes que executam instâncias do SAP no Azure estão usando cmdlets do PowerShell para suplementar as tarefas de gerenciamento que realizam no portal do Azure, inclusive, eles também estão usando cmdlets do PowerShell exclusivamente para gerenciar implantações no Azure. Já que os cmdlets específicos do Azure compartilham a mesma convenção de nomenclatura que os mais de 2000 cmdlets relacionados do Windows, aproveitar esses cmdlets é uma tarefa fácil para os administradores do Windows.

Veja o exemplo aqui: https://blogs.technet.com/b/keithmayer/archive/2015/07/07/18-steps-for-end-to-end-iaas-provisioning-in-the-cloud-with-azure-resource-manager-arm-powershell-and-desired-state-configuration-dsc.aspx

A implantação da Extensão para SAP do Azure (confira o capítulo Extensão para SAP do Azure neste documento) só é possível por meio do PowerShell ou da CLI. Portanto, é obrigatório instalar e configurar o PowerShell ou CLI ao implantar ou administrar um sistema SAP NetWeaver no Azure.

Conforme o Azure fornecer mais funcionalidades, serão adicionados novos cmdlets do PowerShell que exigirão uma atualização dos cmdlets. Portanto, você deve verificar o site de Downloads do Azure pelo menos mensalmente para obter uma nova versão dos cmdlets. A nova versão é instalada substituindo a versão antiga.

Para obter uma lista geral de comandos do PowerShell relacionados ao Azure, confira: Documentação do Azure PowerShell.

Gerenciamento por meio de comandos da CLI do Microsoft Azure

Para clientes que usam Linux e querem gerenciar recursos do Azure, o PowerShell pode não ser uma opção. Como alternativa, a Microsoft oferece a CLI do Azure. A CLI do Azure fornece um conjunto de comandos entre plataformas de software livre para trabalhar com a Plataforma Azure. A CLI do Azure fornece grande parte das mesmas funcionalidades encontradas no Portal do Azure.

Para obter informações sobre instalação, configuração e como usar os comandos da CLI para realizar tarefas do Azure, consulte

Primeiros passos do planejamento de uma implantação

A primeira etapa do planejamento da implantação NÃO é verificar as VMs disponíveis para executar o SAP. A primeira etapa pode ser um pouco demorada, mas o mais importante é trabalhar com equipes de conformidade e segurança em sua empresa para definir quais são as condições de limite para a implantação de qual tipo de carga de trabalho SAP ou processo comercial em nuvem pública. Caso sua empresa tenha implantado outro software antes do Azure, o processo pode ser fácil. Se a sua empresa estiver mais no início da jornada, poderá haver discussões maiores necessárias para descobrir as condições de limite e de segurança que permitem que determinados dados SAP e processos de negócios SAP sejam hospedados na nuvem pública.

Como uma ajuda útil, você pode acessar as ofertas de conformidade da Microsoft para obter uma lista de ofertas de conformidade que a Microsoft pode fornecer.

Outras áreas de preocupações, como criptografia de dados para dados em repouso ou outra criptografia no serviço do Azure, estão documentadas em Visão geral da criptografia do Azure.

Não subestime esta fase do projeto em seu planejamento. Somente quando você tiver um acordo e regras sobre esse tópico, precisará ir para a próxima etapa, que é o planejamento da arquitetura de rede implantada no Azure.

Diferentes maneiras de implantar VMs para SAP no Azure

Neste capítulo, você aprenderá as diferentes maneiras de implantar uma VM no Azure. Procedimentos adicionais de preparação, bem como a manipulação de VHDs e VMs no Azure, são abordados neste capítulo.

Implantação de VMs para SAP

O Microsoft Azure oferece várias maneiras de implantar VMs e discos associados. Portanto, é importante entender as diferenças, pois os preparativos das VMs podem ser diferentes dependendo do método de implantação. Em geral, observaremos os seguintes cenários:

Movendo uma VM do local para o Azure com um disco não generalizado

Você planeja mover um sistema SAP específico do local para o Azure. Isso pode ser feito carregando, no Azure, o VHD que contém os binários do sistema operacional, os binários da SAP e os binários do DBMS, além dos VHDs com os arquivos de dados e arquivos de log do DBMS. Ao contrário do que ocorre no cenário nº 2 abaixo, você mantém o nome de host, a SID do SAP e as contas de usuário do SAP na VM do Azure, já que eles foram configurados no ambiente local. Portanto, não é necessário generalizar a imagem. Confira os capítulos Preparação para mover uma VM do local para o Azure com um disco não generalizado deste documento para obter as etapas de preparação local e de carregamento de VMs ou VHDs não generalizados para o Azure. Leia o capítulo Cenário 3: mover uma VM do local usando um VHD do Azure não generalizado com SAP no Guia de implantação para obter etapas detalhadas de implantação de uma imagem desse tipo no Azure.

Outra opção que não discutiremos detalhadamente neste guia é usar o Azure Site Recovery para replicar servidores de aplicativos SAP NetWeaver e serviços centrais do SAP NetWeaver para o Azure. Não recomendamos usar o Azure Site Recovery para a camada de banco de dados. Em vez disso, use mecanismos de replicação específicos de banco de dados, como a replicação de sistema do HANA. Para obter mais informações, confira o capítulo Proteger o SAP do guia Sobre recuperação de desastres para aplicativos locais.

Implantando uma VM com uma imagem específica do cliente

Devido a requisitos de patch específicos da sua versão do SO ou DBMS, as imagens fornecidas no Azure Marketplace podem não atender às suas necessidades. Portanto, você precisará criar uma VM usando sua própria imagem privada de VM do SO/DBMS, que poderá ser implantada várias vezes posteriormente. Para preparar tal imagem privada para duplicação, os itens a seguir devem ser considerados:

Windows

Para obter mais detalhes, leia Carregar um VHD do Windows generalizado e usá-lo para criar VMs no Azure As configurações do Windows(como SID e nome do host do Windows) precisam ser abstraídas/generalizadas na VM local por meio do comando sysprep.

Linux

Siga as etapas descritas nestes artigos para SUSE ou Red Hat ou Oracle Linux a fim de preparar um VHD para ser carregado no Azure.

Se já tiver instalado o conteúdo do SAP na VM local (especialmente para sistemas de duas camadas), você poderá adaptar as configurações do sistema SAP após a implantação da VM do Azure por meio do procedimento de renomeação da instância ao qual o Software Provisioning Manager SAP dá suporte (Nota do SAP 1619720). Confira os capítulos Preparação para implantar uma VM com uma imagem específica do cliente para SAP e Carregar um VHD do local no Azure deste documento para obter etapas de preparação local e de carregamento de uma VM generalizada para o Azure. Leia o capítulo Cenário 2: Implantação de uma VM com uma imagem personalizada para SAP no Guia de implantação para obter etapas detalhadas de implantação de uma imagem desse tipo no Azure.

Implantando uma VM com origem no Azure Marketplace

Você gostaria de usar uma imagem de VM fornecida pela Microsoft ou por terceiros, partindo do Azure Marketplace, para implantar a VM. Depois de implantar a VM no Azure, siga as mesmas diretrizes e ferramentas para instalar o software SAP e/ou DBMS na VM, como você faria em um ambiente local. Para obter descrição de implantação mais detalhada, leia o capítulo Cenário 1: implantar uma VM no Azure Marketplace para SAP no Guia de implantação.

Preparando as VMs com SAP para o Azure

Antes de carregar as VMs no Azure, você precisará certificar-se de que as VMs e VHDs atendem a certos requisitos. Há pequenas diferenças, dependendo do método de implantação usado.

Preparação para mover uma VM do local para o Azure com um disco não generalizado

Um método de implantação comum é mover, do local para o Azure, uma VM existente que executa um sistema SAP. Essa VM e o sistema SAP presente nela só devem ser executados no Azure usando o mesmo nome de host e, provavelmente, a mesma SID da SAP. Nesse caso, o SO convidado da VM não deve ser generalizado para várias implantações. Se a rede local for estendida para o Azure, será possível usar até as mesmas contas de domínio na VM que eram usadas anteriormente no ambiente local.

Os requisitos ao preparar seu próprio Disco de VM do Azure são:

Originalmente, o VHD contendo o sistema operacional podia ter um tamanho máximo de somente 127 GB. Essa limitação foi eliminada no final de março de 2015. Agora o VHD que contém o sistema operacional pode ser até 1 TB de tamanho, assim como também é o caso de qualquer outro VHD hospedado no Armazenamento do Microsoft Azure.
Ele precisa estar no formato de VHD fixo. VHDs dinâmicos ou VHDs no formato VHDx ainda não têm suporte no Azure. VHDs dinâmicos serão convertidos em VHDs estáticos quando você carregar o VHD com a CLI ou cmdlets do PowerShell
VHDs que são montados na VM e devem ser montados novamente no Azure para a VM precisam estar em um formato de VHD fixo. Leia este artigo para saber o limite de tamanho dos discos de dados. VHDs dinâmicos serão convertidos em VHDs estáticos quando você carregar o VHD com a CLI ou cmdlets do PowerShell
Adicione outra conta local com privilégios de administrador que possa ser usada pelo suporte da Microsoft ou que possa ser atribuída como contexto no qual serviços e aplicativos sejam executados até que a VM seja implantada e mais usuários apropriados possam ser usados.
Adicione outras contas locais, já que elas podem ser necessárias para o cenário de implantação específico.

Windows

Nesse cenário, nenhuma generalização (sysprep) da VM é necessária para carregar e implantar a VM no Azure. Verifique se a unidade D:\ não é usada. Defina a montagem automática de disco para discos anexados conforme descrito no capítulo Definir a montagem automática para os discos anexados deste documento.

Linux

Nesse cenário, nenhuma generalização (waagent -deprovision) da VM é necessária para carregar e implantar a VM no Azure. Certifique-se de que /mnt/resource não é usado e que todos os discos são montados por meio de uuid. Para o disco de SO, certifique-se de que a entrada do carregador de inicialização também reflete a montagem baseada em uuid.

Preparação para implantar uma VM com uma imagem específica do cliente para SAP

Os arquivos VHD que contêm um SO generalizado também são armazenados em contêineres nas Contas de Armazenamento do Azure ou como imagens do Managed Disk. Você pode implantar uma nova VM de uma imagem desse tipo referenciando a imagem VHD ou Managed Disk como uma fonte em seus arquivos de modelo de implantação, conforme descrito no capítulo Cenário 2: implantar uma VM com uma imagem personalizada para SAP do Guia de implantação.

Os requisitos ao preparar sua própria Imagem de VM do Azure são:

Originalmente, o VHD contendo o sistema operacional podia ter um tamanho máximo de somente 127 GB. Essa limitação foi eliminada no final de março de 2015. Agora o VHD que contém o sistema operacional pode ser até 1 TB de tamanho, assim como também é o caso de qualquer outro VHD hospedado no Armazenamento do Microsoft Azure.
Ele precisa estar no formato de VHD fixo. VHDs dinâmicos ou VHDs no formato VHDx ainda não têm suporte no Azure. VHDs dinâmicos serão convertidos em VHDs estáticos quando você carregar o VHD com a CLI ou cmdlets do PowerShell
VHDs que são montados na VM e devem ser montados novamente no Azure para a VM precisam estar em um formato de VHD fixo. Leia este artigo para saber o limite de tamanho dos discos de dados. VHDs dinâmicos serão convertidos em VHDs estáticos quando você carregar o VHD com a CLI ou cmdlets do PowerShell
Adicione outras contas locais, já que elas podem ser necessárias para o cenário de implantação específico.
Se a imagem contém uma instalação do SAP NetWeaver e renomear o nome do host do nome original no ponto de implantação do Azure é algo provável, é recomendável copiar as versões mais recentes do DVD do Gerenciador de provisionamento de software SAP para o modelo. Isso permitirá que você use a funcionalidade de renomeação SAP fornecida para adaptar o nome do host alterado e/ou alterar a SID do sistema SAP na imagem de VM implantada, assim que uma nova cópia for iniciada.

Windows

Verifique se a unidade D:\ não é usada. Defina a montagem automática de disco para discos anexados conforme descrito no capítulo Definir a montagem automática para os discos anexados deste documento.

Linux

Certifique-se de que /mnt/resource não é usado e que todos os discos são montados por meio de uuid. Para o disco de SO, certifique-se de que a entrada do carregador de inicialização também reflete a montagem baseada em uuid.

A GUI da SAP (para fins administrativos e de instalação) podem ser pré-instalados em um modelo desse tipo.
Outros softwares necessários para executar as VMs com êxito em cenários entre instalações podem ser instalados, desde que esse software possa trabalhar com a renomeação da VM.

Se a VM estiver suficientemente preparada para ser genérica e eventualmente independente de contas/usuários não disponíveis no cenário de implantação do Azure de destino, a última etapa de preparação, a generalização de uma imagem desse tipo, será realizada.

Generalizando uma VM

Windows

A última etapa é entrar em uma VM com uma conta de administrador. Abra uma janela de comando do Windows como administrador. Vá para %windir%\windows\system32\sysprep e execute sysprep.exe. Uma janela pequena será exibida. É importante marcar a opção Generalizar (o padrão é desmarcado) e alterar a Opção de Desligamento do seu padrão de 'Reinicializar' para 'Desligar'. Este procedimento pressupõe que o processo sysprep seja executado localmente no SO convidado de uma VM. Se desejar executar o procedimento com uma VM já em execução no Azure, siga as etapas descritas neste artigo.

Linux

Como capturar uma máquina virtual do Linux para usar como um modelo do Resource Manager

Transferindo VMs e VHDs do local para o Azure

Já que carregar discos e imagens de VM para o Azure não é possível por meio do Portal do Azure, você precisa usar a CLI ou cmdlets do Azure PowerShell. Outra possibilidade é o uso da ferramenta 'AzCopy'. Essa ferramenta pode copiar VHDs entre o local e o Azure (em ambas as direções). Ela também pode copiar VHDs entre Regiões do Azure. Confira esta documentação para download e uso do AzCopy.

Uma terceira alternativa seria usar várias ferramentas de terceiros orientadas por GUI. No entanto, verifique se essas ferramentas dão suporte a Blobs de Páginas do Azure. Para atingir nossa finalidade, precisamos usar o Armazenamento de Blobs de Páginas do Azure (as diferenças estão descritas em O que são blobs de blocos, blobs de acréscimo e blobs de páginas). Além disso, as ferramentas fornecidas pelo Azure são eficientes ao compactar as VMs e VHDs que precisam ser carregados. Isso é importante, porque essa eficiência na compactação reduz o tempo de upload (que varia mesmo assim, dependendo do link de upload do recurso local para a Internet e da região de implantação do Azure de destino). Faz sentido supor que carregar uma VM ou um VHD de um local europeu para os EUA com base em data centers do Azure levará mais tempo do que carregar os mesmos VHDs/VMs para data centers europeus do Azure.

Carregando um VHD do local no Azure

Para carregar uma VM ou um VHD existente da rede local, a VM ou o VHD precisa atender aos requisitos listados no capítulo Preparação para mover uma VM do local para o Azure com um disco não generalizado deste documento.

Essa VM NÃO precisa ser generalizada e pode ser carregada no estado e forma que tem após o desligamento no lado local. O mesmo é verdadeiro para VHDs adicionais que não contêm nenhum sistema operacional.

Carregando um VHD e tornando-o um Disco do Azure

Nesse caso, desejamos carregar um VHD, com ou sem um SO, e montá-lo em uma VM como um disco de dados ou usá-lo como disco de SO. Este é um processo de várias etapas

PowerShell

Entre na sua assinatura com Connect-AzAccount
Defina a assinatura do contexto com Set-AzContext e o parâmetro SubscriptionId ou SubscriptionName – Confira Set-AzContext
Carregue o VHD com Add-AzVhd em uma Conta de Armazenamento do Azure – Confira Add-AzVhd
(Opcional) Crie um disco gerenciado usando o VHD com New-AzDisk – Confira New-AzDisk
Defina o disco de SO de uma nova configuração de VM como VHD ou disco gerenciado com Set-AzVMOSDisk – Confira Set-AzVMOSDisk
Crie uma VM com base na configuração de VM com New-AzVM – Confira New-AzVM
Adicione um disco de dados a uma nova VM com Add-AzVMDataDisk – Confira Add-AzVMDataDisk

CLI do Azure

Entre na sua assinatura com az login
Selecione a assinatura com o az account set --subscription <subscription name or id>
Carregar o VHD com o az storage blob upload - consulte Usar a CLI do Azure com o Armazenamento do Azure.
(Opcional) Crie um Disco Gerenciado a partir do VHD com az disk create - consulte az disk.
Criar uma nova VM especificando o VHD ou Managed Disk como disco de SO com az vm create e o parâmetro --attach-os-disk
Adicionar um disco de dados a uma nova VM com az vm disk attach e o parâmetro --new

Modelo

Carregar o VHD com o PowerShell ou a CLI do Azure
(Opcional) Criar um disco gerenciado do VHD com o PowerShell, CLI do Azure ou o portal do Azure
Implantar a VM com um modelo JSON referenciando o VHD conforme mostrado neste modelo JSON de exemplo ou usando Managed Disks conforme mostrado neste modelo JSON de exemplo.

Implantação de uma imagem de VM

Para carregar uma VM ou um VHD existente da rede local para usá-lo como uma imagem de VM do Azure, a VM ou o VHD precisa atender aos requisitos listados no capítulo Preparação para implantar uma VM com uma imagem específica do cliente para SAP deste documento.

Use sysprep no Windows ou waagent -deprovision no Linux para generalizar a VM – confira Sysprep Technical Reference (Referência técnica do Sysprep) para Windows ou Como capturar uma máquina virtual do Linux para usar como um modelo do Resource Manager para Linux
Entre na sua assinatura com Connect-AzAccount
Defina a assinatura do contexto com Set-AzContext e o parâmetro SubscriptionId ou SubscriptionName – Confira Set-AzContext
Carregue o VHD com Add-AzVhd em uma Conta de Armazenamento do Azure – Confira Add-AzVhd
(Opcional) Crie uma Imagem de disco gerenciado usando o VHD com New-AzImage – Confira New-AzImage
Definir o disco do sistema operacional de uma nova configuração VM para o
- VHD com Set-AzVMOSDisk -SourceImageUri -CreateOption fromImage – Confira Set-AzVMOSDisk
- Imagem de disco gerenciado Set-AzVMSourceImage – Confira Set-AzVMSourceImage
Crie uma VM com base na configuração de VM com New-AzVM – Confira New-AzVM

CLI do Azure

Use sysprep no Windows ou waagent -deprovision no Linux para generalizar a VM – confira Sysprep Technical Reference (Referência técnica do Sysprep) para Windows ou Como capturar uma máquina virtual do Linux para usar como um modelo do Resource Manager para Linux
Entre na sua assinatura com az login
Selecione a assinatura com o az account set --subscription <subscription name or id>
Carregar o VHD com o az storage blob upload - consulte Usar a CLI do Azure com o Armazenamento do Azure.
(Opcional) Crie uma imagem de disco gerenciado usando o VHD com az image create – Confira az image.
Criar uma nova VM especificando o VHD ou a Imagem do Managed Disk carregados como disco de SO com az vm create e o parâmetro --image

Modelo

Use sysprep no Windows ou waagent -deprovision no Linux para generalizar a VM – confira Sysprep Technical Reference (Referência técnica do Sysprep) para Windows ou Como capturar uma máquina virtual do Linux para usar como um modelo do Resource Manager para Linux
Carregar o VHD com o PowerShell ou a CLI do Azure
(Opcional) Criar uma Imagem do Disco Gerenciado do VHD com o PowerShell, CLI do Azure ou o portal do Azure
Implantar a VM com um modelo JSON referenciando o VHD da imagem conforme mostrado neste modelo JSON de exemplo ou usando Managed Disks conforme mostrado neste modelo JSON de exemplo.

Baixando VHDs ou Managed Disks no local

A infraestrutura como serviço do Azure não é uma rua de mão única, em que você pode apenas carregar VHDs e sistemas SAP. Você também pode mover sistemas SAP do Azure de volta para o universo local.

Durante o tempo de download, os VHDs ou Managed Disks não podem estar ativos. Mesmo ao baixar discos montados em VMs, a VM precisa ser desligada e desalocada. Se você quiser apenas baixar o conteúdo do banco de dados, que deverá então ser usado para configurar um novo sistema local, e se for aceitável que o sistema no Azure ainda possa estar operacional durante o tempo de download e instalação do novo sistema, você poderá evitar um longo tempo de inatividade executando um backup de banco de dados compactado em um disco e simplesmente baixando esse disco, em vez de também baixar a VM base do SO.

PowerShell

Como baixar um disco gerenciado. Primeiro, você precisa obter acesso ao blob subjacente do disco gerenciado. Em seguida, você pode copiar o blob de base para uma nova conta de armazenamento e baixar o blob da conta de armazenamento.

$access = Grant-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name> -Access Read -DurationInSecond 3600
$key = (Get-AzStorageAccountKey -ResourceGroupName <resource group> -Name <storage account name>)[0].Value
$destContext = (New-AzStorageContext -StorageAccountName <storage account name -StorageAccountKey $key)
Start-AzStorageBlobCopy -AbsoluteUri $access.AccessSAS -DestContainer <container name> -DestBlob <blob name> -DestContext $destContext
# Wait for blob copy to finish
Get-AzStorageBlobCopyState -Container <container name> -Blob <blob name> -Context $destContext
Save-AzVhd -SourceUri <blob in new storage account> -LocalFilePath <local file path> -StorageKey $key
# Wait for download to finish
Revoke-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name>

Baxiar um VHD. Depois que o sistema SAP for interrompido e a VM for desligada, você poderá usar o cmdlet do PowerShell Save-AzVhd no destino local para baixar os discos VHD para a realidade local. Para fazer isso, é necessária a URL do VHD que você pode encontrar na 'Seção de Armazenamento' do portal do Azure (é necessário navegar até a conta de armazenamento e o contêiner de armazenamento no qual o VHD foi criado) e você precisa saber também para que local o VHD deve ser copiado.

Em seguida, você pode aproveitar o comando definindo o parâmetro SourceUri como a URL do VHD a baixar e o LocalFilePath como a localização física do VHD (incluindo seu nome). O comando seria semelhante ao seguinte:
```
Save-AzVhd -ResourceGroupName <resource group name of storage account> -SourceUri http://<storage account name>.blob.core.windows.net/<container name>/sapidedata.vhd -LocalFilePath E:\Azure_downloads\sapidesdata.vhd
```
Para obter mais detalhes sobre o cmdlet Save-AzVhd, confira: Save-AzVhd.

CLI do Azure

az disk grant-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --duration-in-seconds 3600
az storage blob download --sas-token "<sas token>" --account-name <account name> --container-name <container name> --name <blob name> --file <local file>
az disk revoke-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>"

Baxiar um VHD. Depois que o sistema SAP for interrompido e a VM for desligada, você poderá usar o comando do CLI do Azure _azure storage blob download_ no destino local para baixar os discos VHD para a realidade local. Para fazer isso, você precisa do nome e do contêiner do VHD que você pode encontrar na 'Seção de Armazenamento' do Portal do Azure (é necessário navegar até a conta de armazenamento e o contêiner de armazenamento no qual o VHD foi criado) e você precisa saber também para que local o VHD deve ser copiado.

Em seguida, você pode aproveitar o comando definindo os parâmetros blob e contêiner do VHD a baixar e o destino como a localização física de destino do VHD (incluindo seu nome). O comando seria semelhante ao seguinte:
```
az storage blob download --name <name of the VHD to download> --container-name <container of the VHD to download> --account-name <storage account name of the VHD to download> --account-key <storage account key> --file <destination of the VHD to download>
```

Transferindo VMs e discos no interior do Azure

Copiando sistemas SAP no interior do Azure

Um sistema SAP ou até mesmo um servidor DBMS dedicado com suporte a uma camada de aplicativo SAP provavelmente consistirá em vários discos contendo o SO com os binários ou então os dados e arquivos de log do banco de dados SAP. Nem a funcionalidade do Azure de copiar discos nem a funcionalidade do Azure de salvar discos em um disco local têm um mecanismo de sincronização que capture instantâneos de vários discos de modo consistente. Portanto, o estado dos discos copiados ou salvos, mesmo se eles fossem montados na mesma VM, seria diferente. Isso significa que, no caso concreto de ter diferentes dados e arquivo(s) de log contidos nos diferentes discos, o banco de dados, no final, seria inconsistente.

Conclusão: para copiar ou salvar discos que fazem parte de uma configuração do sistema SAP, você precisa interromper o sistema SAP e também desligar a VM implantada. Somente então você pode copiar ou baixar o conjunto de discos para criar uma cópia do sistema SAP no Azure ou localmente.

Os discos de dados podem ser armazenados como arquivos VHD em uma Conta de Armazenamento do Azure e podem ser diretamente anexados a uma máquina virtual ou ser usados como uma imagem. Nesse caso, o VHD é copiado para outro local antes de ser anexado à máquina virtual. O nome completo do arquivo VHD no Azure deve ser exclusivo dentro do Azure. Conforme mencionado anteriormente, o nome em questão é um tipo de nome de três partes com a seguinte aparência:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

Discos de dados também podem ser Managed Disks. Nesse caso, o Managed Disk é usado para criar um novo Managed Disk antes de ser anexado à máquina virtual. O nome do Managed Disk deve ser exclusivo dentro de um grupo de recursos.

PowerShell

Você pode usar os cmdlets do Azure PowerShell para copiar um VHD, conforme mostrado neste artigo. Para criar um Managed Disk, use New-AzDiskConfig e New-AzDisk conforme mostrado no exemplo a seguir.

$config = New-AzDiskConfig -CreateOption Copy -SourceUri "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" -Location <location>
New-AzDisk -ResourceGroupName <resource group name> -DiskName <disk name> -Disk $config

CLI do Azure

Você pode usar a CLI do Azure para copiar um VHD. Para criar um novo Managed Disk, use az disk create conforme mostrado no exemplo a seguir.

az disk create --source "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --name <disk name> --resource-group <resource group name> --location <location>

Ferramentas do Armazenamento do Azure

Gerenciador de Armazenamento do Azure

Edições profissionais de Gerenciadores do Armazenamento do Azure que podem ser encontradas aqui:

A cópia de um VHD no interior de uma conta de armazenamento é um processo que leva apenas alguns segundos (semelhante ao hardware de SAN criando instantâneos com cópia lenta e cópia em gravação). Depois de ter uma cópia do arquivo VHD, você pode anexá-lo a uma máquina virtual ou usá-lo como uma imagem para anexar cópias do VHD a máquinas virtuais.

PowerShell

# attach a vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -VhdUri <path to vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -ManagedDiskId <managed disk id> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a copy of the vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name <disk name> -VhdUri <new path of vhd> -SourceImageUri <path to image vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption fromImage
$vm | Update-AzVM

# attach a copy of the managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$diskConfig = New-AzDiskConfig -Location $vm.Location -CreateOption Copy -SourceUri <source managed disk id>
$disk = New-AzDisk -DiskName <disk name> -Disk $diskConfig -ResourceGroupName <resource group name>
$vm = Add-AzVMDataDisk -VM $vm -Caching <caching option> -Lun <lun, for example 0> -CreateOption attach -ManagedDiskId $disk.Id
$vm | Update-AzVM

CLI do Azure


# attach a vhd to a vm
az vm unmanaged-disk attach --resource-group <resource group name> --vm-name <vm name> --vhd-uri <path to vhd>

# attach a managed disk to a vm
az vm disk attach --resource-group <resource group name> --vm-name <vm name> --disk <managed disk id>

# attach a copy of the vhd to a vm
# this scenario is currently not possible with Azure CLI. A workaround is to manually copy the vhd to the destination.

# attach a copy of a managed disk to a vm
az disk create --name <new disk name> --resource-group <resource group name> --location <location of target virtual machine> --source <source managed disk id>
az vm disk attach --disk <new disk name or managed disk id> --resource-group <resource group name> --vm-name <vm name> --caching <caching option> --lun <lun, for example 0>

Copiando discos entre contas de armazenamento do Azure

Esta tarefa não pode ser realizada no Portal do Azure. Você pode usar cmdlets do Azure PowerShell, a CLI do Azure ou um navegador de armazenamento de terceiros. Os comandos CLI ou cmdlets do PowerShell podem criar e gerenciar blobs, os quais incluem a capacidade de copiar blobs em regiões entre contas de armazenamento de forma assíncrona na assinatura do Azure.

PowerShell

Você também pode copiar VHDs entre assinaturas. Para obter mais informações, leia este artigo.

O fluxo básico da lógica do cmdlet do PowerShell tem esta aparência:

Crie um contexto de conta de armazenamento para a conta de armazenamento de origem com New-AzStorageContext – Confira New-AzStorageContext
Crie um contexto de conta de armazenamento para a conta de armazenamento de destino com New-AzStorageContext – Confira New-AzStorageContext
Iniciar a cópia com

Start-AzStorageBlobCopy -SrcBlob <source blob name> -SrcContainer <source container name> -SrcContext <variable containing context of source storage account> -DestBlob <target blob name> -DestContainer <target container name> -DestContext <variable containing context of target storage account>

Verificar o status da cópia em um loop com

Get-AzStorageBlobCopyState -Blob <target blob name> -Container <target container name> -Context <variable containing context of target storage account>

Anexe o novo VHD a uma máquina virtual, conforme descrito acima.

Para obter exemplos, confira este artigo.

CLI do Azure

Iniciar a cópia com

az storage blob copy start --source-blob <source blob name> --source-container <source container name> --source-account-name <source storage account name> --source-account-key <source storage account key> --destination-container <target container name> --destination-blob <target blob name> --account-name <target storage account name> --account-key <target storage account name>

Verificar o status da cópia ainda está em um loop com

az storage blob show --name <target blob name> --container <target container name> --account-name <target storage account name> --account-key <target storage account name>

Anexe o novo VHD a uma máquina virtual, conforme descrito acima.

Administração de discos

Estrutura de VM/disco para implantações SAP

Idealmente, a administração da estrutura de uma VM e os discos associados deve ser simples. Em instalações locais, os clientes desenvolveram muitas formas de estruturar uma instalação de servidor.

Um disco base que contém o sistema operacional e todos os binários do DBMS e/ou SAP. Desde março de 2015, este disco pode ser de até 1 TB de tamanho, enquanto restrições anteriores o limitavam a 127 GB.
Um ou vários discos contendo o arquivo de log do DBMS do banco de dados SAP e o arquivo de log da área de armazenamento temporário do DBMS (se o DBMS der suporte a isso). Se os requisitos de IOPS do log de banco de dados forem altos, você precisará distribuir vários discos para alcançar o volume de IOPS necessário.
Um número de discos contendo um ou dois arquivos de banco de dados do banco de dados SAP e também os arquivos de dados temporários do DBMS (se o DBMS der suporte a isso).

Configuração de referência da VM IaaS do Azure para SAP

Windows

Com muitos clientes, vimos configurações em que, por exemplo, binários de DBMS e SAP não foram instalados na unidade c:\ na qual o sistema operacional estava instalado. Havia vários motivos para isso, mas quando analisamos a raiz, geralmente era que as unidades eram pequenas e as atualizações de SO precisavam de espaço adicional há 10-15 anos atrás. Nenhuma das condições se aplica com muita frequência nos dias de hoje. Hoje, a unidade c:\ pode ser mapeada em VMs ou discos de grande volume. Para manter as implantações simples em sua estrutura, é recomendável seguir o seguinte padrão de implantação para sistemas SAP NetWeaver no Azure

O arquivo de paginação do sistema operacional Windows deve estar na unidade D: (disco não persistente)

Linux

Coloque o arquivo de troca do Linux em /mnt /mnt/resource no Linux, conforme descrito neste artigo. O arquivo de troca pode ser configurado no arquivo de configuração do Agente do Linux /etc/waagent.conf. Adicione ou remova as seguintes configurações:

ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=30720

Para ativar as alterações, é necessário reiniciar o Agente do Linux com

sudo service waagent restart

Leia a Nota do SAP 1597355 para obter mais detalhes sobre o tamanho do arquivo recomendado

O número de discos usados para os arquivos de dados do DBMS e o tipo de armazenamento do Azure esses discos são hospedados em deve ser determinado pelos requisitos de IOPS e pela latência necessária. Cotas exatas são descritas neste artigo (Linux) e neste artigo (Windows).

Experiência de implantações do SAP nos últimos dois anos nos ensinou algumas lições que podem ser resumidas como:

O tráfego IOPS para diferentes arquivos de dados nem sempre é o mesmo, já que sistemas de cliente existentes podem ter arquivos de dados dimensionados diferentemente que representam seus bancos de dados SAP. Como resultado, usar uma configuração RAID em vários VHDs para colocar os arquivos de dados formados desses discos pelos LUNs mostrou-se uma melhor opção. Havia situações, especialmente com o Armazenamento Standard do Azure, nas quais uma taxa de IOPS atingiu a cota de um único disco com o log de transações do DBMS. Nesses cenários, é recomendado usar o Armazenamento Premium ou, alternativamente, agregar vários discos de Armazenamento Standard com uma faixa de software.

Windows

Práticas recomendadas para o SQL Server em Máquinas Virtuais do Azure

Linux

Configurar RAID de software no Linux

Configurar o LVM em uma VM Linux no Azure

O Armazenamento Premium está apresentando desempenho significativamente melhor, especialmente para gravações de log de transações críticas. Para cenários SAP que se espera que forneçam produção como desempenho, é altamente recomendável usar séries de VMs que podem aproveitar o Armazenamento Premium do Azure.

Tenha em mente que o disco que contém o SO, e conforme recomendamos, os binários da SAP e o banco de dados (VM base), não está mais limitado a 127 GB. Agora ele pode ter até 1 TB de tamanho. Isso deve ser espaço suficiente para manter todos os arquivos necessários, incluindo, por exemplo, logs de trabalho em lotes SAP.

Para obter mais sugestões e detalhes, especificamente para VMs de DBMS, confira o Guia de implantação de DBMS

Administração de discos

Na maioria dos cenários, você precisa criar discos adicionais para implantar o banco de dados SAP na VM. Falamos sobre as considerações de número de discos no capítulo Estrutura de VM/disco para implantações SAP deste documento. O Portal do Azure permite anexar e desanexar discos depois que uma VM base é implantada. Os discos podem ser anexados/desanexados quando a VM está instalada e em execução, bem como quando ela é interrompida. Ao anexar um disco, o portal do Azure oferece a possibilidade de anexar um disco vazio ou um disco existente que nesse momento não está anexado a outra VM.

Observação: Discos só podem ser anexados a uma única VM em um determinado momento.

Anexar/desanexar discos do Armazenamento Standard do Azure

Durante a implantação de uma nova máquina virtual, você pode decidir se deseja usar Managed Disks ou colocar os discos em Contas de Armazenamento do Azure. Se você quiser usar o Armazenamento Premium, é recomendável usar Managed Disks.

Você precisa decidir se deseja criar um disco novo e vazio ou se você deseja selecionar um disco existente que foi carregado anteriormente e deve ser anexado à VM agora.

IMPORTANTE: você NÃO deseja usar o Cache de Host com o Armazenamento Standard do Azure. Você deve deixar a preferência de Cache de Host no padrão de NENHUM. Com o Armazenamento Premium do Azure, você deverá habilitar o Cache de Leitura se a característica de E/S for lida principalmente como tráfego típico de E/S em relação os arquivos de dados do banco de dados. No caso do arquivo de log de transações do banco de dados, é recomendado usar a opção sem cache.

Windows

Como anexar um disco de dados no Portal do Azure

Se discos forem anexados, você precisará entrar na VM para abrir o Gerenciador de Disco do Windows. Se a montagem automática não estiver habilitada conforme recomendado no capítulo Definir a montagem automática para os discos anexados, o volume recém-vinculado precisará ser colocado online e inicializado.

Linux

Se discos forem anexados, você precisará entrar na VM e inicializá-los, conforme descrito neste artigo

Se o novo disco for um disco vazio, também será necessário formatar o disco. Para formatação, especialmente para arquivos de dados e de log do DBMS, aplicam-se as mesmas recomendações existentes para implantações bare-metal do DBMS.

Uma conta de Armazenamento do Azure não oferece recursos ilimitados em termos de volume de E/S, IOPS e volume de dados. Geralmente as VMs de DBMS são mais afetadas por isso. Talvez seja melhor usar uma conta de armazenamento separada para cada VM se você tiver algumas VMs com volumes altos de E/S para implantar, para permanecer dentro do limite de volume da Conta de Armazenamento do Azure. Caso contrário, você precisa ver como pode equilibrar essas VMs entre diferentes Contas de Armazenamento sem atingir o limite de cada Conta de Armazenamento individual. Mais detalhes são discutidos no Guia de implantação de DBMS. Você também deve ter essas limitações em mente para VMs de servidor de aplicativos SAP puro ou outras VMs que eventualmente possam exigir VHDs adicionais. Essas restrições não se aplicam se você usar o Managed Disk. Se você planeja usar o Armazenamento Premium, é recomendável usar Managed Disks.

Outro tópico relevante para as Contas de Armazenamento é se os VHDs em uma Conta de Armazenamento estão sendo replicados geograficamente. A replicação geográfica é habilitada ou desabilitada no nível da Conta de Armazenamento e não no nível da VM. Se a replicação geográfica estiver habilitada, os VHDs na Conta de Armazenamento serão replicados para outro data center do Azure na mesma região. Antes de decidir sobre isso, você deve considerar a seguinte restrição:

A replicação geográfica do Azure funciona localmente em cada VHD em uma VM e não replica as E/Ss em ordem cronológica entre vários VHDs em uma VM. Portanto, o VHD que representa a VM base, bem como VHDs adicionais vinculados à VM, são replicados de modo independente uns dos outros. Isso significa que não há nenhuma sincronização entre as alterações nos diferentes VHDs. O fato de que as E/Ss são replicadas de modo independente da ordem em que são gravadas significa que a replicação geográfica não tem valor para servidores de banco de dados com bancos de dados distribuídos entre vários VHDs. Além do DBMS, também pode haver outros aplicativos em que os processos gravam ou manipulam dados em diferentes VHDs e nos quais é importante manter a ordem das alterações. Se isso for um requisito, a replicação geográfica no Azure não deverá ser habilitada. Dependendo de você precisar/querer ou não a replicação geográfica para um conjunto de VMs, mas não para outro conjunto, você já pode categorizar VMs e os VHDs relacionados a elas em diferentes Contas de Armazenamento com replicação geográfica habilitada ou desabilitada.

Definindo a montagem automática para os discos vinculados

Windows

Para VMs que são criadas por meio de imagens ou discos próprios, é necessário verificar e possivelmente definir o parâmetro de montagem automática. Definir esse parâmetro permitirá que a VM, após uma reinicialização ou reimplantação no Azure, monte novamente as unidades anexadas/montadas, de modo automático. O parâmetro é definido para as imagens fornecidas pela Microsoft no Azure Marketplace.

Para definir a montagem automática, verifique a documentação do executável de linha de comando diskpart.exe aqui:

Opções de linha de comando do DiskPart

Montagem automática

A janela de linha de comando do Windows deve ser aberta como administrador.

Se discos forem anexados, você precisará entrar na VM para abrir o Gerenciador de Disco do Windows. Se a montagem automática não estiver habilitada conforme a recomendação no capítulo Como definir a montagem automática de discos anexados, o volume recém-anexado>precisará ser colocado online e inicializado.

Linux

Você deve inicializar um disco vazio anexado recentemente, conforme descrito neste artigo. Você também precisa adicionar novos discos a /etc/fstab.

Implantação final

Para obter as etapas exatas e de implantação final, especialmente a implantação da extensão para SAP do Azure, confira o Guia de implantação.

Acessando sistemas SAP em execução nas VMs do Azure

Para cenários em que você deseja se conectar a esses sistemas SAP pela Internet pública usando a GUI do SAP, os procedimentos a seguir precisam ser aplicados.

Posteriormente neste documento, discutiremos o cenário principal, conectar-se a sistemas SAP em implantações entre instalações que têm uma conexão site a site (túnel VPN) ou uma conexão do Azure ExpressRoute entre os sistemas locais e sistemas do Azure.

Acesso remoto aos serviços SAP

Com o Azure Resource Manager, não há mais pontos de extremidade padrão como havia no antigo modelo clássico. Todas as portas de uma VM do Azure Resource Manager estão abertas, desde que:

Nenhum grupo de segurança de rede seja definido para a sub-rede ou a interface de rede. O tráfego de rede para VMs do Azure possa ser protegido por meio dos chamados "Grupos de Segurança de Rede". Para obter mais informações, consulte O que é um NSG (Grupo de Segurança de Rede)?
Nenhum Azure Load Balancer seja definido para a interface de rede

Veja a diferença de arquitetura entre o modelo clássico e o ARM, conforme descrito neste artigo.

Configuração de conectividade do Sistema SAP e da GUI da SAP pela Internet

Confira este artigo, que descreve os detalhes deste tópico: Conexão do SAP GUI fechada durante a conexão com o sistema SAP no Azure

Alterando as configurações de Firewall na VM

Pode ser necessário configurar o firewall em suas máquinas virtuais para permitir o tráfego de entrada para o sistema SAP.

Windows

Por padrão, o Firewall do Windows em uma VM implantada no Azure é ativado. Agora você precisa permitir que a porta SAP seja aberta, caso contrário a GUI da SAP não poderá se conectar. Para fazer isso:

Abra Painel de Controle\Sistema e Segurança \Firewall do Windows em Configurações Avançadas.

Agora, clique com o botão direito do mouse em Regras de Entrada e escolha Nova Regra.

No Assistente que aparece a seguir, escolha criar uma nova regra de Porta.

Na próxima etapa do assistente, deixe a configuração como TCP e digite o número da porta que deseja abrir. Como a ID da nossa instância SAP é 00, usamos 3200. Se a instância tiver um número de instância diferente, a porta que você definiu anteriormente com base no número da instância deverá ser aberta.

Na próxima parte do assistente, você deve deixar o item Permitir Conexão marcado.

Na próxima etapa do assistente, você deve definir se a regra se aplica à rede de Domínio, Privada e Público. Ajuste essa configuração se necessário, conforme suas necessidades. Entretanto, ao conectar-se com a GUI da SAP do exterior pela rede pública, é necessário ter a regra aplicada à rede pública.

Na última etapa do assistente, nomeie a regra e pressione Concluir para salvar.

A regra entrará em vigor imediatamente.

Linux

As imagens do Linux no Azure Marketplace não habilitam o firewall iptables por padrão, e a conexão com o sistema SAP deve funcionar. Se você habilitou o iptables ou outro firewall, confira a documentação do iptables ou do firewall usado para permitir o tráfego TCP de entrada para a porta 32xx (em que xx é o número do sistema SAP).

Recomendações de segurança

A GUI da SAP não se conecta imediatamente a nenhuma das instâncias da SAP (porta 32xx) em execução, mas se conecta primeiro através da porta aberta para o processo do servidor de mensagens SAP (porta 36xx). No passado, a mesma porta foi usada pelo servidor de mensagens para a comunicação interna com as instâncias do aplicativo. Para impedir que servidores de aplicativo locais se comuniquem inadvertidamente com um servidor de mensagens no Azure, as portas de comunicação interna podem ser alteradas. É altamente recomendável alterar a comunicação interna entre o servidor de mensagens SAP e suas instâncias de aplicativo para um número da porta diferente em sistemas que foram clonados por meio de sistemas locais, como um clone de desenvolvimento para testes de projeto, etc. Isso pode ser feito com o parâmetro de perfil padrão:

rdisp/msserv_internal

conforme documentado em Configurações de segurança para o Servidor de Mensagens SAP

VM única com cenário de demonstração/treinamento do SAP NetWeaver

Executando sistemas de demonstração SAP em VMs únicas com os mesmos nomes de VM, isoladas em serviços de nuvem do Azure

Neste cenário, estamos implementando um cenário de sistema de treinamento/demonstração típico em que o cenário de treinamento/demonstração completo está contido em uma única VM. Vamos supor que a implantação é feita por meio de modelos de imagem de VM. Também pressupomos que várias dessas VMs de demonstração/treinamento precisam ser implantadas com as VMs tendo o mesmo nome. O sistema de treinamento como um todo não tem conectividade com seus ativos locais e é o oposto de uma implantação híbrida.

Pressupõe-se que você criou uma imagem de VM, conforme descrito em algumas seções do capítulo Preparar VMs com SAP para o Azure deste documento.

A sequência de eventos para implementar o cenário tem esta aparência:

PowerShell

Criar um novo grupo de recursos para cada estrutura de treinamento/demonstração

$rgName = "SAPERPDemo1"
New-AzResourceGroup -Name $rgName -Location "North Europe"

Criar uma nova conta de armazenamento se você não quiser usar Managed Disks

$suffix = Get-Random -Minimum 100000 -Maximum 999999
$account = New-AzStorageAccount -ResourceGroupName $rgName -Name "saperpdemo$suffix" -SkuName Standard_LRS -Kind "Storage" -Location "North Europe"

Crie uma nova rede virtual para cada estrutura de treinamento/demonstração para habilitar o uso do mesmo nome do host e endereços IP. A rede virtual é protegida por um Grupo de Segurança de Rede que permite apenas o tráfego para a porta 3389 para habilitar o acesso de Área de Trabalho Remota e porta 22 para SSH.

# Create a new Virtual Network
$rdpRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGRDP -Protocol * -SourcePortRange * -DestinationPortRange 3389 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 100
$sshRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGSSH -Protocol * -SourcePortRange * -DestinationPortRange 22 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 101
$nsg = New-AzNetworkSecurityGroup -Name SAPERPDemoNSG -ResourceGroupName $rgName -Location  "North Europe" -SecurityRules $rdpRule,$sshRule

$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name Subnet1 -AddressPrefix  10.0.1.0/24 -NetworkSecurityGroup $nsg
$vnet = New-AzVirtualNetwork -Name SAPERPDemoVNet -ResourceGroupName $rgName -Location "North Europe"  -AddressPrefix 10.0.1.0/24 -Subnet $subnetConfig

Criar um novo endereço IP público que pode ser usado para acessar a máquina virtual da Internet

# Create a public IP address with a DNS name
$pip = New-AzPublicIpAddress -Name SAPERPDemoPIP -ResourceGroupName $rgName -Location "North Europe" -DomainNameLabel $rgName.ToLower() -AllocationMethod Dynamic

Criar uma nova interface de rede para a máquina virtual

# Create a new Network Interface
$nic = New-AzNetworkInterface -Name SAPERPDemoNIC -ResourceGroupName $rgName -Location "North Europe" -Subnet $vnet.Subnets[0] -PublicIpAddress $pip

Crie uma máquina virtual. Para este cenário, todas as VMs terão o mesmo nome. A SID das instâncias do SAP NetWeaver nessas VMs também será a mesma. No Grupo de Recursos do Azure, o nome da VM deve ser exclusivo, mas em diferentes Grupos de Recursos do Azure, você pode executar VMs com o mesmo nome. A conta padrão de “Administrador” do Windows ou “raiz” para Linux não são válidas. Portanto, um novo nome de usuário do administrador deve ser definido, junto com uma senha. O tamanho da VM também deve ser definido.

#####
# Create a new virtual machine with an official image from the Azure Marketplace
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

# select image
$vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "MicrosoftWindowsServer" -Offer "WindowsServer" -Skus "2012-R2-Datacenter" -Version "latest"
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "SUSE" -Offer "SLES-SAP" -Skus "12-SP1" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "RedHat" -Offer "RHEL" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "Oracle" -Offer "Oracle-Linux" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$diskName="osfromimage"
$osDiskUri=$account.PrimaryEndpoints.Blob.ToString() + "vhds/" + $diskName  + ".vhd"

$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Windows
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Linux
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

#####
# Create a new virtual machine with a Managed Disk Image
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMSourceImage -VM $vmconfig -Id <Id of Managed Disk Image>
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig

Opcionalmente, adicione discos adicionais e restaure o conteúdo necessário. Todos os nomes de blob (URLs para os blobs) devem ser exclusivos no Azure.

# Optional: Attach additional VHD data disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
$dataDiskUri = $account.PrimaryEndpoints.Blob.ToString() + "vhds/datadisk.vhd"
Add-AzVMDataDisk -VM $vm -Name datadisk -VhdUri $dataDiskUri -DiskSizeInGB 1023 -CreateOption empty | Update-AzVM

# Optional: Attach additional Managed Disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
Add-AzVMDataDisk -VM $vm -Name datadisk -DiskSizeInGB 1023 -CreateOption empty -Lun 0 | Update-AzVM

CLI

O código de exemplo a seguir pode ser usado no Linux. Para Windows, use o PowerShell conforme descrito acima ou adapte o exemplo para usar %rgName% em vez de $rgName e defina a variável de ambiente usando o comando setdo Windows.

Criar um novo grupo de recursos para cada estrutura de treinamento/demonstração

rgName=SAPERPDemo1
rgNameLower=saperpdemo1
az group create --name $rgName --location "North Europe"

Criar uma nova conta de armazenamento

az storage account create --resource-group $rgName --location "North Europe" --kind Storage --sku Standard_LRS --name $rgNameLower

Crie uma nova rede virtual para cada estrutura de treinamento/demonstração para habilitar o uso do mesmo nome do host e endereços IP. A rede virtual é protegida por um Grupo de Segurança de Rede que permite apenas o tráfego para a porta 3389 para habilitar o acesso de Área de Trabalho Remota e porta 22 para SSH.

az network nsg create --resource-group $rgName --location "North Europe" --name SAPERPDemoNSG
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGRDP --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 3389 --access Allow --priority 100 --direction Inbound
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGSSH --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 22 --access Allow --priority 101 --direction Inbound

az network vnet create --resource-group $rgName --name SAPERPDemoVNet --location "North Europe" --address-prefixes 10.0.1.0/24
az network vnet subnet create --resource-group $rgName --vnet-name SAPERPDemoVNet --name Subnet1 --address-prefix 10.0.1.0/24 --network-security-group SAPERPDemoNSG

Criar um novo endereço IP público que pode ser usado para acessar a máquina virtual da Internet

az network public-ip create --resource-group $rgName --name SAPERPDemoPIP --location "North Europe" --dns-name $rgNameLower --allocation-method Dynamic

Criar uma nova interface de rede para a máquina virtual

az network nic create --resource-group $rgName --location "North Europe" --name SAPERPDemoNIC --public-ip-address SAPERPDemoPIP --subnet Subnet1 --vnet-name SAPERPDemoVNet

Crie uma máquina virtual. Para este cenário, todas as VMs terão o mesmo nome. A SID das instâncias do SAP NetWeaver nessas VMs também será a mesma. No Grupo de Recursos do Azure, o nome da VM deve ser exclusivo, mas em diferentes Grupos de Recursos do Azure, você pode executar VMs com o mesmo nome. A conta padrão de “Administrador” do Windows ou “raiz” para Linux não são válidas. Portanto, um novo nome de usuário do administrador deve ser definido, junto com uma senha. O tamanho da VM também deve ser definido.

#####
# Create virtual machines using storage accounts
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard-D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard-D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard-D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password

#####
# Create virtual machines using Managed Disks
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard-DS11-v2 --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard-DS11-v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard-DS11-v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard-DS11-v2 --os-disk-name os --authentication-type password

#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Windows --admin-username <username> --admin-password <password> --size Standard-D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Linux --admin-username <username> --admin-password <password> --size Standard-D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd> --authentication-type password

#####
# Create a new virtual machine with a Managed Disk Image
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard-DS11-v2 --os-disk-name os --image <managed disk image id>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard-DS11-v2 --os-disk-name os --image <managed disk image id> --authentication-type password

Opcionalmente, adicione discos adicionais e restaure o conteúdo necessário. Todos os nomes de blob (URLs para os blobs) devem ser exclusivos no Azure.

# Optional: Attach additional VHD data disks
az vm unmanaged-disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --vhd-uri https://$rgNameLower.blob.core.windows.net/vhds/data.vhd  --new

# Optional: Attach additional Managed Disks
az vm disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --disk datadisk --new

Modelo

Você pode usar os modelos de exemplo no repositório Azure-quickstart-templates no GitHub.

Implementar um conjunto de VMs que se comuniquem dentro do Azure

Esse cenário não híbrido é um cenário típico para fins de treinamento e demonstração, no qual o software que representa o cenário de demonstração/treinamento é distribuído entre várias VMs. Os diferentes componentes instalados em diferentes VMs precisam se comunicar uns com os outros. Novamente, nesse cenário, nenhuma comunicação de rede local ou cenário entre instalações é necessária.

Esse cenário é uma extensão da instalação descrita no capítulo Cenário de treinamento/demonstração de VM única com SAP NetWeaver deste documento. Nesse caso, mais máquinas virtuais serão adicionadas a um grupo de recursos existente. No exemplo a seguir, a estrutura de treinamento consiste em uma VM SAP ASCS/SCS, uma VM executando um DBMS e uma VM de instância de servidor de aplicativos SAP.

Antes de criar esse cenário, você precisa pensar sobre configurações básicas, conforme já praticado no cenário anterior.

Nomeação de grupos de recursos e máquinas virtuais

Todos os nomes de grupos de recursos devem ser exclusivos. Desenvolva seu próprio esquema de nomenclatura de recursos, como <rg-name>-sufixo.

O nome da máquina virtual deve ser exclusivo dentro do grupo de recursos.

Instalação de rede para comunicação entre as diferentes VMs

Conjunto de VMs em uma Rede Virtual do Azure

Para evitar conflitos de nome com clones das mesmas estruturas de treinamento/demonstração, você precisa criar uma Rede Virtual do Azure para cada estrutura. A resolução de nomes DNS será fornecida pelo Azure, ou você pode configurar seu próprio servidor DNS fora do Azure (não será mais discutido aqui). Neste cenário, não configuramos nosso próprio DNS. A comunicação por meio de nomes do host será habilitada para todas as máquinas virtuais dentro de uma Rede Virtual do Azure.

Os motivos para separar estruturas de treinamento ou demonstração por redes virtuais, e não apenas pelos grupos de recursos, podem ser:

A estrutura da SAP, como foi configurada, precisa de sua própria AD/OpenLDAP, e um servidor de domínio precisa fazer parte de cada uma das estruturas.
A estrutura da SAP, como foi configurada, tem componentes que precisam trabalhar com endereços IP fixos.

Mais detalhes sobre Redes Virtuais do Azure e como defini-las podem ser encontrados neste artigo.

Implantar VMs SAP com conectividade de rede corporativa (entre instalações)

Você executa uma estrutura da SAP e deseja dividir a implantação entre bare-metal para servidores high-end DBMS, ambientes virtualizados locais para camadas de aplicativo, além de IaaS do Azure e sistemas SAP menores, de duas camadas, configurados. A hipótese fundamental é que os sistemas SAP em uma estrutura da SAP precisem se comunicar entre si e com muitos outros componentes de software implantados na empresa, independentemente da forma de implantação. Não deve haver tampouco nenhuma diferença introduzida pela forma de implantação para o usuário final conectando-se à GUI da SAP ou outras interfaces. Essas condições só podem ser atendidas quando temos o Active Directory/OpenLDAP e serviços DNS locais estendidos aos sistemas do Azure por meio de conectividade de site a site/multissite ou conexões privadas, como a Azure ExpressRoute.

Cenário de uma estrutura SAP

O cenário híbrido ou entre instalações pode ser descrito como nos gráficos abaixo:

Conexão site a site entre ativos locais e no Azure

O requisito mínimo é o uso de protocolos de comunicação segura, como SSL/TLS, para acesso via navegador ou conexões VPN para acesso ao sistema para os serviços do Azure. A suposição é que as empresas administram a conexão VPN entre sua rede corporativa e o Azure de modo diferente. Algumas empresas podem, cegamente, abrir todas as portas. Outras empresas podem querer ser precisas em relação às portas que precisam abrir, etc.

As portas de comunicação SAP típicas estão listadas na tabela a seguir. Basicamente, é suficiente abrir a porta do gateway da SAP.

Serviço	Número da Porta	Exemplo `<nn`> = 01	Intervalo Padrão (Mín-Máx)	Comentário
Dispatcher	sapdp`<nn>` confira *	3201	3200 – 3299	Dispatcher SAP, usado pela GUI da SAP para Windows e Java
Servidor de mensagens	sapms`<sid`> confira **	3600	número livre de sapms`<anySID`>	sid = ID do sistema SAP
Gateway	sapgw`<nn`> confira *	3301	livre	Gateway SAP, usado para comunicação CPIC e RFC
Roteador SAP	sapdp99	3299	livre	Apenas os nomes de serviço CI (instância central) podem ser reatribuídos em /etc/services, para um valor arbitrário, após a instalação.

*) nn = Número da Instância SAP

**) sid = ID do sistema SAP

Para obter mais informações, consulte [Portas TCP/IP usadas por Aplicativos SAP] (https://help.sap.com/docs/Security/575a9f0e56f34c6e8138439eefc32b16/616a3c0b1cc748238de9c0341b15c63c.html). Com este documento, você pode abrir portas dedicadas no dispositivo VPN necessárias para cenários e produtos específicos da SAP.

Outras medidas de segurança ao implantar VMs em um cenário como esse poderiam ser criar um Grupo de Segurança de Rede para definir as regras de acesso.

Imprimindo em uma impressora de rede local da instância SAP no Azure

Imprimindo via TCP/IP no cenário entre instalações

Configurar suas impressoras de rede com base em TCP/IP locais em uma VM do Azure é, no geral, igual ao que ocorre em sua rede corporativa, pressupondo que você tenha um túnel VPN site a site ou conexão de ExpressRoute estabelecida.

Windows

Para fazer isso:

Algumas impressoras de rede vêm com um assistente de configuração que torna mais fácil configurar sua impressora em uma VM do Azure. Se nenhum software assistente foi distribuído com a impressora, o modo "manual" de configurá-la é criar uma nova porta de impressora TCP/IP.

Abra o Painel de Controle -> Dispositivos e Impressoras -> Adicionar uma impressora

Escolha Adicionar uma impressora usando um endereço TCP/IP ou nome do host

Digite o endereço IP da impressora

A porta de impressora padrão é 9100

Se necessário, instale manualmente o driver de impressora apropriado.

Linux

assim como para o Windows, apenas siga o procedimento padrão para instalar uma impressora de rede

basta seguir os guias públicos do Linux para SUSE ou Red Hat e Oracle Linux sobre como adicionar uma impressora.

Impressão em rede

Impressora baseada em host por SMB (impressora compartilhada) em cenário entre instalações

Impressoras baseadas em host não são compatíveis com rede por design. Mas uma impressora baseada em host pode ser compartilhada entre computadores em uma rede, desde que a impressora esteja conectada a um computador ligado. Conecte sua rede corporativa via site a site ou ExpressRoute e compartilhe a impressora local. O protocolo SMB usa NetBIOS em vez de DNS como serviço de nomes. O nome do host NetBIOS pode ser diferente do nome do host DNS. O caso padrão é com o nome do host NetBIOS e o nome do host DNS sendo idênticos. O domínio DNS não faz sentido no namespace do NetBIOS. Da mesma forma, o nome do host DNS totalmente qualificado consistindo no nome do host DNS e no domínio DNS não deve ser usado no namespace do NetBIOS.

O compartilhamento de impressora é identificado por um nome exclusivo na rede:

Nome do host SMB (sempre necessário).
Nome do host do compartilhamento (sempre necessário).
Nome do domínio se o compartilhamento de impressora não estiver no mesmo domínio que o sistema SAP.
Além disso, um nome de usuário e uma senha podem ser necessárias para acessar o compartilhamento de impressora.

Como fazer:

Windows

Compartilhe a impressora local. Na VM do Azure, abra o Windows Explorer e digite o nome do compartilhamento da impressora. Um assistente de instalação de impressora vai guiá-lo pelo processo de instalação.

Linux

Aqui estão alguns exemplos de documentação sobre configuração de impressoras de rede no Linux ou que incluam um capítulo sobre impressão no Linux. Isso funciona da mesma forma em uma VM Linux do Azure, desde que a VM seja parte de um VPN:

SLES – Imprimir por meio do Compartilhamento do SMB (Samba) ou Compartilhamento do Windows

RHEL ou Oracle Linux – Iniciando a Ferramenta de Configuração das Definições de Impressão

Impressora USB (encaminhamento de impressora)

No Azure, a capacidade dos Serviços de Área de Trabalho Remota de fornecer aos usuários acesso a seus dispositivos de impressora local em uma sessão remota não está disponível.

Windows

Para obter mais informações, consulte Detalhes técnicos de compartilhamento de impressora

Integração de sistemas SAP do Azure ao Sistema de Correção e Transporte (TMS) para cenáros entre instalações

O Sistema de Alteração e Transporte SAP (TMS) deve ser configurado para exportar e importar solicitações de transporte entre sistemas na estrutura. Suponhamos que as instâncias de desenvolvimento de um sistema SAP (DES) estejam localizadas no Azure enquanto a garantia de qualidade e os sistemas de produção (PRD) sejam locais. Além disso, pressupomos que exista um diretório de transporte central.

Configurando o domínio de transporte

Configure seu domínio de transporte no sistema designado por você como o controlador de domínio de transporte, conforme descrito em Configurando o controlador de domínio de transporte. Um TMSADM de usuário do sistema será criado e o destino RFC necessário será gerado. Você pode verificar essas conexões RFC usando a transação SM59. A resolução do nome do host deve estar habilitada em seu domínio de transporte.

Como fazer:

Em nosso cenário, decidimos que o sistema QAS local será o controlador de domínio CTS. Chame a transação STMS. A caixa de diálogo TMS é exibida. Uma caixa de diálogo Configurar Domínio de Transporte é exibida. (Essa caixa de diálogo só aparece se você ainda não tiver configurado um domínio de transporte.)
Verifique se o TMSADM do usuário criado automaticamente está autorizado (SM59 -> Conexão ABAP -> TMSADM@E61.DOMAIN_E61 -> Detalhes -> Utilitários(M) -> Teste de Autorização). A tela inicial da transação STMS deve mostrar que esse sistema SAP está funcionando agora como o controlador do domínio de transporte, conforme mostrado aqui:

Tela inicial da transação STMS no controlador de domínio

Incluindo sistemas SAP no domínio de transporte

A sequência de inclusão de um sistema SAP em um domínio de transporte será semelhante ao seguinte:

No sistema de desenvolvimento no Azure, vá para o sistema de transporte (Cliente 000) e chame a transação STMS. Escolha Outra Configuração na caixa de diálogo e continue com Incluir o Sistema no Domínio. Especifique o controlador de domínio como o host de destino (Incluindo sistemas SAP no domínio de transporte). O sistema está agora aguardando para ser incluído no domínio de transporte.
Por motivos de segurança, você precisa, em seguida, voltar para o controlador de domínio para confirmar a solicitação. Escolha Visão Geral do Sistema e Aprovação do sistema em espera. Em seguida, confirme o prompt e a configuração será distribuída.

Esse sistema SAP agora contém as informações necessárias sobre todos os outros sistemas SAP no domínio de transporte. Ao mesmo tempo, os dados de endereço do novo sistema SAP são enviados a todos os outros sistemas SAP e o sistema SAP é inserido no perfil de transporte do programa de controle de transporte. Verifique se os RFCs e o acesso ao diretório de transporte do domínio funcionam.

Continue com a configuração do seu sistema de transporte normalmente, conforme descrito na documentação Sistema de Alteração e Transporte.

Como fazer:

Certificar-se de que o STMS local está configurado corretamente.
Certificar-se de que o nome do host do controlador de domínio de transporte pode ser resolvido pela máquina virtual no Azure e vice-versa.
Chame a transação STMS -> Outra configuração -> Incluir o sistema no domínio.
Confirmar a conexão no sistema TMS local.
Configurar camadas, grupos e rotas de transporte como de costume.

Em cenários entre instalações conectados site a site, a latência entre locais e o Azure ainda pode ser significativa. Se seguirmos a sequência de transportar objetos através de sistemas de desenvolvimento e teste para produção ou pensarmos sobre como aplicar os transportes ou pacotes de suporte aos diferentes sistemas, perceberemos que, dependendo do local do diretório de transporte central, alguns dos sistemas encontrarão alta latência ao ler ou gravar dados no diretório de transporte central. A situação é semelhante a configurações de estrutura da SAP em que os diferentes sistemas estão distribuídos por diferentes data centers com distância significativa entre os data centers.

Para contornar essa latência e fazer com que os sistemas trabalhem rapidamente na leitura ou gravação de ou para o diretório de transporte, você pode configurar dois domínios de transporte STMS (um com os sistemas locais e o outro com os sistemas no Azure) e então vincular os domínios de transporte. Confira esta documentação, que explica os princípios por trás desse conceito no SAP TMS.

Como fazer:

Configurar um domínio de transporte em cada lugar (local e Azure) usando o STMS de transação
Vincular os domínios com um link de domínio e confirmar o vínculo entre os dois domínios.
Distribuir a configuração para o sistema vinculado.

Tráfego RFC entre instâncias SAP localizadas no Azure e localmente (entre instalações)

O tráfego RFC entre os sistemas locais e que estão no Azure precisa funcionar. Para configurar uma conexão, chame a transação SM59 em um sistema de origem em que você precisa definir uma conexão RFC com o sistema de destino. A configuração é semelhante à configuração padrão de uma conexão RFC.

Supomos que no cenário entre instalações, as VMs executando sistemas SAP que precisarem se comunicar uns com os outros estão no mesmo domínio. Portanto, a configuração de uma conexão RFC entre os sistemas SAP não difere das etapas de configuração e entradas em cenários locais.

Acessar compartilhamentos de arquivos locais de instâncias SAP localizadas no Azure ou vice-versa

As instâncias SAP localizadas no Azure precisam acessar compartilhamentos de arquivos que estão nas instalações corporativas. Além disso, as instâncias SAP locais precisam acessar compartilhamentos de arquivos que estão localizados no Azure. Para habilitar os compartilhamentos de arquivos, você deve configurar as permissões e opções de compartilhamento no sistema local. Certifique-se de abrir as portas na conexão VPN ou ExpressRoute entre o Azure e seu datacenter.

Suporte

Extensão para SAP do Azure

Para alimentar alguma parte das informações de infraestrutura do Azure de sistemas SAP críticos para as instâncias do agente de host do SAP, instaladas em VMs, uma extensão do Azure (VM) para SAP precisa ser instalada nas VMs implantadas. Já que as demandas do SAP eram específicas para aplicativos SAP, a Microsoft decidiu não implementar genericamente a funcionalidade necessária no Azure, mas sim deixar para os clientes a tarefa de implantar as configurações e a extensão de VM necessárias em suas máquinas virtuais em execução no Azure. No entanto, o gerenciamento de ciclo de vida e a implantação da Extensão de VM do Azure para SAP serão automatizados principalmente pelo Azure.

Design da solução

A solução desenvolvida para habilitar a obtenção das informações necessárias pelo Agente do Host do SAP baseia-se na arquitetura do Agente de VM do Azure e da estrutura de extensão. A ideia do Agente de VM e do framework de extensão é permitir a instalação de aplicativos de software disponíveis na Galeria de extensão de VM do Azure em uma VM. A ideia do princípio por trás desse conceito é permitir (em casos como a extensão do Azure para SAP), a implantação de uma funcionalidade especial em uma VM e a configuração desse software, no momento da implantação.

O 'Agente de VM do Azure' que permite a manipulação de extensões de VM do Azure específicas dentro da VM é injetado em VMs do Windows por padrão na criação de VMs no Portal do Azure. No caso do SUSE ou Red Hat ou Oracle Linux, o agente de VM já é parte da imagem do Azure Marketplace. Caso alguém carregasse uma VM Linux do local para o Azure, o agente de VM deveria ser instalado manualmente.

Os blocos de construção básicos da solução para fornecer informações de infraestrutura do Azure ao agente de host do SAP no Azure têm a seguinte aparência:

Componentes de extensão do Microsoft Azure

Conforme mostrado no diagrama de bloco acima, uma parte da solução é hospedada na Imagem de VM do Azure e na Galeria de extensões do Azure, que é um repositório global replicado gerenciado pelo Azure Operations. É responsabilidade da equipe de MS/SAP conjunta trabalhar para que a implementação da SAP no Azure funcione com o Azure Operations para publicar novas versões da Extensão para SAP do Azure.

Quando você implanta uma nova VM do Windows, o Agente de VM do Azure é adicionado automaticamente à VM. A função desse agente é coordenar o carregamento e a configuração das extensões do Azure das VMs. Para VMs Linux, o Agente de VM do Azure já é parte da imagem do SO do Azure Marketplace.

No entanto, há uma etapa que ainda precisa ser executada pelo cliente. Esta é a habilitação e configuração de coleta de desempenho. O processo relacionado à configuração é automatizado por um script do PowerShell ou comando da CLI. O script do PowerShell pode ser baixado no Microsoft Azure Script Center, conforme descrito no Guia de implantação.

A arquitetura geral da extensão do Azure para SAP é semelhante a:

Extensão do Azure para SAP

Para obter instruções exatas e etapas detalhadas de como usar esses cmdlets do PowerShell ou o comando da CLI durante as implantações, siga as instruções fornecidas no Guia de implantação.

Integração de instância SAP localizada no Azure ao SAProuter

Instâncias SAP em execução no Azure precisam ser acessíveis também do SAProuter.

Conexão de rede de roteador SAP

Um SAProuter habilitará a comunicação TCP/IP entre os sistemas participantes se não houver conexão direta por IP. Isso tem a vantagem de que nenhuma conexão de ponta a ponta entre os parceiros de comunicação é necessária no nível da rede. O SAProuter está escutando na porta 3299, por padrão. Para se conectar a instâncias SAP por meio de um SAProuter, você precisa fornecer o nome do host e a cadeia de caracteres do SAProuter ao realizar qualquer tentativa de conexão.

Servidor de Aplicativos para Java do SAP NetWeaver

Até aqui, o foco do documento tem sido o SAP NetWeaver em geral ou a pilha ABAP do SAP NetWeaver. Nesta pequena seção, são listadas as considerações específicas para a pilha Java da SAP. Um dos mais importantes aplicativos baseados exclusivamente em Java do SAP NetWeaver é o SAP Enterprise Portal. Outros aplicativos com base em SAP NetWeaver, como o SAP PI e o SAP Solution Manager usam tanto o ABAP do SAP NetWeaver quanto pilhas Java. Portanto, é certamente necessário considerar também aspectos específicos relacionados à pilha Java do SAP NetWeaver.

SAP Enterprise Portal

A configuração de um Portal SAP em uma Máquina Virtual do Azure não será diferente de uma instalação local se você estiver implantando em cenários entre instalações. Como o DNS é feito por local, as configurações de porta das instâncias individuais podem ser feitas do mesmo modo que são configuradas localmente. As recomendações e as restrições descritas neste documento até este ponto se aplicam a um aplicativo como o SAP Enterprise Portal ou a pilha Java do SAP NetWeaver em geral.

Portal SAP exposto

Um cenário de implantação especial por alguns clientes é a exposição direta do SAP Enterprise Portal à Internet enquanto o host de máquina virtual está conectado à rede da empresa por meio de túnel VPN site a site ou ExpressRoute. Para esse cenário, você precisa certificar-se de que portas específicas estejam abertas e não estejam bloqueadas por um grupo de segurança de rede ou firewall.

O URI inicial do portal é http(s):<Portalserver>:5XX00/irj, em que a porta é formada conforme a documentação da SAP em Portas do Servidor de Aplicativos para Java.

Configuração de ponto de extremidade

Se você quiser personalizar a URL e/ou as portas do seu SAP Enterprise Portal, consulte esta documentação:

HA (alta disponibilidade) e DR (recuperação de desastre) para SAP NetWeaver em execução em máquinas virtuais do Azure

Definição de terminologias

O Termo alta disponibilidade (HA) geralmente está relacionado a um conjunto de tecnologias que minimiza as interrupções da TI, proporcionando a continuidade dos negócios dos serviços de TI por meio de componentes redundantes e tolerantes a falhas ou protegidos contra failover no mesmo data center. Em nosso caso, dentro de uma Região do Azure.

A DR (recuperação de desastre) também está voltada para minimizar as interrupções dos serviços de TI e a recuperação de dados, mas em diferentes data centers, que estão normalmente localizados a centenas de quilômetros de distância. Em nosso caso, geralmente entre diferentes Regiões do Azure na mesma região geopolítica ou como estabelecidos por você, como cliente.

Visão Geral de Alta Disponibilidade

É possível separar a discussão sobre a alta disponibilidade da SAP no Azure em duas partes:

Alta disponibilidade da infraestrutura do Azure, por exemplo, alta disponibilidade de computação (VMs), rede, armazenamento etc., e seus benefícios para aumentar a disponibilidade do aplicativo SAP.
Alta disponibilidade de aplicativos SAP, por exemplo, alta disponibilidade de componentes de software SAP:
- Servidores de aplicativos SAP
- Instância ASCS/SCS SAP
- servidor do BD

e como ele pode ser combinado com alta disponibilidade de infraestrutura do Azure.

Alta disponibilidade da SAP no Azure tem algumas diferenças em comparação com alta disponibilidade da SAP em um ambiente físico ou virtual local. O seguinte documento da SAP descreve as configurações padrão de Alta Disponibilidade do SAP nos ambientes virtualizados no Windows. Há não configuração de alta disponibilidade do SAP integrada com sapinst para Linux. Para obter mais informações sobre alta disponibilidade do SAP local para Linux, confira Informações do parceiro de alta disponibilidade para Linux.

Alta disponibilidade de infraestrutura do Azure

Atualmente, não há um SLA de 99,9% de VM individual. Para ter uma ideia da disponibilidade de uma VM individual, você pode criar o produto dos diferentes SLAs do Azure disponíveis.

A base para o cálculo é 30 dias por mês, ou 43.200 minutos. Portanto, 0,05% de tempo de inatividade corresponde a 21,6 minutos. Conforme ocorre normalmente, a disponibilidade dos serviços diferentes se multiplicará da seguinte maneira:

(Serviço de disponibilidade nº 1/100) * (Serviço de disponibilidade nº 2/100) * (Serviço de disponibilidade nº 3/100)

Assim como:

(99,95/100) * (99,9/100) * (99,9/100) = 0,9975 ou uma disponibilidade geral de 99,75%.

Alta disponibilidade de VM (máquina virtual)

Há dois tipos de eventos de plataforma do Azure que podem afetar a disponibilidade das máquinas virtuais: manutenção planejada e manutenção não planejada.

Eventos de manutenção planejada são atualizações periódicas feitas pela Microsoft na plataforma subjacente do Azure para melhorara a confiabilidade, o desempenho e a segurança geral da infraestrutura da plataforma na qual suas máquinas virtuais são executadas.
Eventos de manutenção não planejada ocorrem quando o hardware ou a infraestrutura física subjacente à sua máquina virtual apresenta algum tipo de falha. Isso inclui falhas na rede local, falhas no disco local ou outras falhas no nível de rack. Quando tal falha é detectada, a plataforma do Azure migrará automaticamente sua máquina virtual do servidor físico não íntegro hospedando sua máquina virtual para um servidor físico íntegro. Esses eventos são raros, mas podem também reinicializar a sua máquina virtual.

Para mais detalhes, confira Disponibilidade de máquinas virtuais do Windows no Azure e Disponibilidade de máquinas virtuais do Linux no Azure.

Redundância de Armazenamento do Azure

Os dados da sua Conta de Armazenamento do Microsoft Azure sempre são replicados para garantir durabilidade e alta disponibilidade, cumprindo o SLA do Armazenamento do Azure mesmo diante de falhas transitórias de hardware.

Já que o armazenamento do Azure está mantendo três imagens dos dados por padrão, RAID5 ou RAID1 em vários discos do Azure não são necessárias.

Para saber mais, veja Preços de Armazenamento do Microsoft Azure.

Utilizando a Reinicialização de VM da infraestrutura do Azure para atingir maior disponibilidade de aplicativos SAP

Se você decidir não usar as funcionalidades como Clustering de Failover do Windows Server (WSFC) ou Pacemaker Linux (atualmente compatível apenas com SLES 12 ou posterior), a Reinicialização de VM do Azure será usada para proteger o sistema SAP contra tempo de inatividade planejado e não planejado da infraestrutura de servidor físico do Azure e da plataforma subjacente do Azure em geral.

Observação

É importante mencionar que a Reinicialização de VM do Azure protege principalmente as VMs, NÃO os aplicativos. A Reinicialização de VM não oferece alta disponibilidade para aplicativos SAP, mas oferece um certo nível de disponibilidade da infraestrutura e, portanto, indiretamente, maior disponibilidade de sistemas SAP. Não há, tampouco, nenhum SLA para o tempo necessário para reiniciar uma VM após uma interrupção de host planejada ou não planejada. Portanto, esse método de alta disponibilidade não é adequado para componentes críticos de um sistema SAP como (A)SCS ou DBMS.

Outro elemento de infraestrutura importante para alta disponibilidade é o armazenamento. Por exemplo, o SLA do Armazenamento do Azure tem disponibilidade de 99,9%. Se alguém implantar todas as VMs com seus discos em uma única Conta de Armazenamento do Azure, a indisponibilidade potencial do Armazenamento do Azure causará indisponibilidade de todas as VMs localizadas na Conta de Armazenamento do Azure e também de todos os componentes SAP em execução dentro dessas VMs.

Em vez de colocar todas as VMs em uma única Conta de Armazenamento do Azure, você também pode contas de armazenamento dedicado para cada VM e, dessa forma, aumentar a disponibilidade geral da VM e do aplicativo SAP usando várias Contas de Armazenamento do Azure independentes.

Os discos gerenciados do Azure são colocados automaticamente no domínio de falha da máquina virtual aos quais eles estão conectados. Se você colocar duas máquinas virtuais em um conjunto de disponibilidade e usar Managed Disks, a plataforma cuidará da distribuição dos Managed Disks em diferentes Domínios de Falha. Se você planeja usar o Armazenamento Premium, também é altamente recomendável usar Managed Disks.

Uma arquitetura de exemplo de um sistema SAP NetWeaver que usa alta disponibilidade de infraestrutura e contas de armazenamento do Azure poderia ter esta aparência:

Diagrama que mostra um sistema SAP NetWeaver que usa as contas de armazenamento e HA de infraestrutura do Azure.

Uma arquitetura de exemplo de um sistema SAP NetWeaver que usa alta disponibilidade de infraestrutura e Managed Disks do Azure poderia ter esta aparência:

Utilizando a alta disponibilidade da infraestrutura do Azure para atingir maior disponibilidade de aplicativos SAP

Para componentes críticos da SAP, conseguimos o seguinte até agora:

Alta disponibilidade de servidores de aplicativos (SA) SAP

As instâncias do servidor de aplicativos SAP são componentes redundantes. Cada instância de SA SAP está implantada em uma VM própria, que está em execução em um domínio de falha e de atualização diferente do Azure (confira os capítulos Domínios de falha e Domínios de atualização). Isso é garantido pelo uso de conjuntos de disponibilidade do Azure (confira o capítulo Conjuntos de Disponibilidade do Azure). Potencial indisponibilidade planejada ou não planejada de um domínio de falha ou atualização do Azure causará indisponibilidade de um número restrito de VMs com suas instâncias SAP.

Cada instância de SA SAP será colocada em sua própria conta de Armazenamento do Azure – a indisponibilidade potencial de uma Conta de Armazenamento do Azure causará indisponibilidade de apenas uma VM com a instância de SA SAP. No entanto, lembre-se de que há um limite de Contas de Armazenamento do Azure dentro de uma assinatura do Azure. Para assegurar o início automático da instância do (A)SCS após a reinicialização da VM, não se esqueça de definir o parâmetro de Inicialização automática no perfil de início de instância do (A)SCS descrito no capítulo Usar a Inicialização automática para instâncias SAP. Leia também o capítulo Alta disponibilidade para servidores de aplicativos SAP para obter mais detalhes.

Mesmo que você use Managed Disks, esses discos também são armazenados em uma Conta de Armazenamento do Azure e podem não estar disponíveis no caso de uma interrupção de armazenamento.
Maior disponibilidade de instância do (A)SCS SAP

Aqui, utilizamos a Reinicialização de VM do Azure para proteger a VM com instância do (A)SCS SAP instalada. No caso de tempo de inatividade planejado ou não planejado de servidores do Azure, as VMs serão reiniciadas em outro servidor disponível. Como mencionado anteriormente, a Reinicialização de VM do Azure protege principalmente as VMs e NÃO os aplicativos, neste caso, a instância do (A)SCS. Por meio da Reinicialização de VM, alcançaremos indiretamente maior disponibilidade da instância do SAP (A)SCS. Para assegurar o início automático da instância do (A)SCS após a reinicialização da VM, não se esqueça de definir o parâmetro de Inicialização automática no perfil de início de instância do (A)SCS descrito no capítulo Usar a inicialização automática para instâncias SAP. Isso significa que a instância do (A)SCS como um SPOF (ponto único de falha) em execução em uma única VM será o fator determinante para a disponibilidade de toda a estrutura da SAP.
Maior disponibilidade de servidor DBMS

Aqui, de modo semelhante ao caso de uso de instância do SAP (A)SCS, utilizamos a Reinicialização de VM do Azure para proteger a VM com software do DBMS instalado e podemos obter maior disponibilidade de software DBMS por meio da Reinicialização de VM. DBMS em execução em uma única VM também é um SPOF, e é o fator determinante para a disponibilidade de toda a estrutura da SAP.

Alta disponibilidade de aplicativo SAP no Azure IaaS

Para obter alta disponibilidade total no sistema SAP, é necessário proteger todos os componentes críticos do sistema SAP, por exemplo, de servidores de aplicativos SAP redundantes e componentes exclusivos (por exemplo, ponto único de falha), como a instância do (A)SCS SAP e DBMS.

Alta disponibilidade para servidores de aplicativos SAP

Para as instâncias de caixa de diálogo/servidores de aplicativos SAP, não é necessário pensar em uma solução de alta disponibilidade específica. A alta disponibilidade é obtida pela redundância e, portanto, pela existência de um número suficiente deles em máquinas virtuais diferentes. Eles devem ser todos colocados no mesmo conjunto de disponibilidade do Azure, para evitar que as VMs possam ser atualizadas ao mesmo tempo durante o tempo de inatividade da manutenção planejada. A funcionalidade básica baseada nos domínios de falha e de atualização diferentes em uma Unidade de Escala do Azure já foi introduzida no capítulo Domínios de atualização. Conjuntos de disponibilidade do Azure foram apresentados no capítulo Conjuntos de disponibilidade do Azure deste documento.

Não há um número infinito de domínios de falha e atualização que possam ser usados por um conjunto de disponibilidade do Azure em uma unidade de escala do Azure. Isso significa que, colocando um número de VMs em um conjunto de disponibilidade, mais cedo ou mais tarde, mais de uma VM termina no mesmo domínio de atualização ou falha.

Implantando algumas instâncias do servidor de aplicativos SAP em suas VMs dedicadas e supondo que temos cinco domínios de atualização, o quadro a seguir surge no final. O número máximo real de domínios de falha e atualização dentro de um conjunto de disponibilidade pode mudar no futuro:

Alta disponibilidade dos servidores de aplicativos SAP no Azure

Alta disponibilidade para serviços centrais do SAP no Azure

Para a arquitetura de alta disponibilidade do SAP Central Services no Azure, confira o artigo Arquitetura e cenários de alta disponibilidade para SAP NetWeaver como informações de entrada. O artigo aponta para descrições mais detalhadas para os sistemas operacionais específicos.

Alta disponibilidade para a instância do banco de dados SAP

A configuração típica de alta disponibilidade de DMBS SAP é baseada nas duas VMs DBMS nas quais a funcionalidade de alta disponibilidade de DBMS é usada para replicar dados da instância de DBMS ativa para a segunda VM em uma instância de DBMS passiva.

As funcionalidades de Recuperação de Desastre e Alta Disponibilidade para DBMS em geral, assim como um DBMS específico, são descritos no Guia de implantação de DBMS.

Alta disponibilidade de ponta a ponta para o sistema SAP completo

Aqui estão dois exemplos de uma arquitetura de alta disponibilidade SAP NetWeaver completa no Azure - um para Windows e outro para Linux.

Somente discos não gerenciados: Os conceitos, conforme explicado abaixo, talvez precisem ser um pouco comprometidos quando você implantar muitos sistemas SAP e o número de VMs implantadas estiver excedendo o limite máximo de contas de armazenamento por assinatura. Nesses casos, os VHDs de VMs devem ser combinados em uma conta de armazenamento. Normalmente você faria isso pela combinação de VHDs de VMs das camadas de aplicativo SAP de sistemas SAP diferentes. Também combinamos diferentes VHDs de diferentes VMs DBMS de sistemas SAP diferentes em uma conta de armazenamento do Azure. Mantendo assim os limites de IOPS das Contas Armazenamento do Azure em mente Metas de escalabilidade e desempenho para contas de armazenamento padrão

HA no Windows

Diagrama que mostra a arquitetura de alta disponibilidade de aplicativos SAP NetWeaver com o SQL Server no Azure IaaS.

As seguintes construções do Azure são usadas para o sistema SAP NetWeaver, para minimizar o impacto por problemas de infraestrutura e a aplicação de patches ao host:

O sistema completo é implantado no Azure (necessário – a camada do gerenciador de banco de dados, a instância de (A)SCS e a camada de aplicativo completo precisam ser executadas no mesmo local).
O sistema completo é executado dentro de uma assinatura do Azure (obrigatório).
O sistema completo é executado dentro de uma rede virtual do Azure (obrigatório).
A separação das VMs de um sistema SAP em três conjuntos de disponibilidade é possível mesmo com todas as máquinas virtuais pertencendo à mesma rede virtual.
Cada camada (por exemplo, DBMS, ASCS, servidores de aplicativos) deve usar um conjunto de disponibilidade dedicado.
Todas as VMs que executam instâncias DBMS de um sistema SAP estão em um conjunto de disponibilidade. Presumimos que haja mais de uma VM executando instâncias do DBMS por sistema, já que recursos nativos de alta disponibilidade do DBMS são usados, como o SQL Server Always On ou o Oracle Data Guard.
Todas as VMs que executam instâncias de DBMS usam sua própria conta de armazenamento. Arquivos de log e arquivos de dados de DBMS são replicados de uma conta de armazenamento para outra usando funções de alta disponibilidade de DBMS que sincronizam os dados. Indisponibilidade de uma conta de armazenamento causará indisponibilidade de um nó de cluster do Windows SQL, mas não do serviço do SQL Server inteiro.
Todas as VMs que executam uma instância do (A)SCS de um sistema SAP estão em um conjunto de disponibilidade. Um Cluster de Failover do Windows Server (WSFC)é configurado no interior dessas VMs para proteger a instância do (A)SCS.
Todas as VMs que executam instâncias do (A)SCS usam sua própria conta de armazenamento. Os arquivos de instância do (A)SCS e a pasta global do SAP são replicados de uma conta de armazenamento para outra usando a replicação do SIOS DataKeeper. Indisponibilidade de uma conta de armazenamento causará indisponibilidade de um nó de cluster do Windows (A)SCS, mas não do serviço do (A)SCS inteiro.
TODAS as VMs que representam a camada do servidor de aplicativos SAP estão em um terceiro conjunto de disponibilidade.
TODAS as VMs executando servidores de aplicativos SAP usam sua própria conta de armazenamento. A indisponibilidade de uma conta de armazenamento causará indisponibilidade de um servidor de aplicativos SAP, em que outros servidores de aplicativos SAP continuam em execução.

A figura a seguir ilustra o mesmo cenário usando Managed Disks.

Arquitetura de alta disponibilidade de aplicativos SAP NetWeaver com o SQL Server no Azure IaaS

HA no Linux

A arquitetura para alta disponibilidade da SAP em Linux no Azure é basicamente a mesma que aquela para Windows, conforme descrito acima. Veja a Nota SAP 1928533 para obter uma lista de soluções de alta disponibilidade compatíveis.

Usando a inicialização automática para instâncias SAP

A SAP ofereceu a funcionalidade para iniciar as instâncias SAP imediatamente após a inicialização do SO na VM. As etapas exatas documentadas no artigo da Base de Dados de Conhecimento SAP 1909114. No entanto, a SAP não recomenda mais o uso da configuração, porque não há nenhum controle na ordem de reinicializações de instâncias, supondo que mais de uma VM tenha sido afetada ou várias instâncias tenham sido executadas por VM. Supondo um cenário típico do Azure de uma instância do servidor de aplicativos SAP em uma VM e o caso de uma única VM eventualmente sendo reiniciada, a Inicialização Automática não é crítica e pode ser habilitada adicionando este parâmetro:

Autostart = 1

No perfil de início da instância de SAP ABAP e/ou instância de Java.

Observação

O parâmetro Inicialização automática também pode ter algumas desvantagens. Mais detalhadamente, o parâmetro aciona o início de uma instância de Java ou SAP ABAP quando o serviço do Windows/Linux relacionado da instância é iniciado. Esse é certamente o caso quando o sistema operacional é inicializado. No entanto, reinicializações de serviços SAP também são uma coisa comum para a funcionalidade de gerenciamento de ciclo de vida do Software SAP, como SUM ou outras atualizações. Essas funcionalidades não estão esperando em hipótese nenhuma que uma instância seja reiniciada automaticamente. Portanto, o parâmetro Inicialização automática deve ser desabilitado antes de executar essas tarefas. O parâmetro de Inicialização automática também não deve ser usado para instâncias do SAP que estão clusterizadas, como ASCS/SCS/CI.

Consulte informações adicionais sobre a inicialização automática para instâncias SAP aqui:

Sistemas SAP maiores de 3 camadas

Aspectos de alta disponibilidade de configurações SAP de 3 camadas já foram discutidos nas seções anteriores. Mas e quanto a sistemas em que os requisitos do servidor DBMS são grandes demais para que ele fosse localizado no Azure, mas nos quais a camada do aplicativo SAP poderia ser implantada no Azure?

Localização de configurações SAP de 3 camadas

Não há suporte para dividir a camada de aplicativo em si ou o aplicativo e a camada DBMS entre o local e o Azure. Um sistema SAP é completamente implantado localmente OU no Azure. Também não há suporte para executar alguns dos servidores de aplicativos localmente e outros no Azure. Esse é o ponto de partida da discussão. Também não damos suporte à implantação dos componentes do DBMS de um sistema SAP e da camada de servidor de aplicativos SAP em duas Regiões do Azure diferentes. Por exemplo, o DBMS no Oeste dos EUA e camada de aplicativo SAP nos EUA Central. O motivo para não dar suporte a essas configurações é a sensibilidade de latência da arquitetura do SAP NetWeaver.

No entanto, ao longo do ano passado, parceiros de data center desenvolveram colocalizações para Regiões do Azure. Essas colocalizações geralmente são próximas dos data centers físicos em uma Região do Azure. A curta distância e a conexão de ativos no local por meio de ExpressRoute no Azure podem resultar em uma latência menor que 2 ms. Nesses casos, é possível localizar a camada de DBMS (incluindo o armazenamento SAN/NAS) em uma dessas colocalizações e a camada de aplicativo SAP no Azure. HANA em Instâncias Grandes.

Backup offline de sistemas SAP

Dependendo da configuração SAP escolhida (2 ou 3 camadas), pode haver necessidade de backup. O conteúdo da própria VM, além de ter um backup do banco de dados. Os backups relacionados ao DBMS devem ser feitos com métodos de banco de dados. Uma descrição detalhada dos diferentes bancos de dados pode ser encontrada no Guia de DBMS. Por outro lado, os dados da SAP podem fazer backup de maneira offline (incluindo o conteúdo do banco de dados) conforme descrito nesta seção, ou online, conforme descrito na próxima seção.

O backup offline basicamente exigiria um desligamento da VM por meio do Portal do Azure e uma cópia do disco da VM base, além de todos os discos anexados à VM. Isso preservaria uma imagem da VM e seus discos associados em um ponto no tempo. É recomendável copiar os backups para outra Conta de Armazenamento do Azure. Portanto, o procedimento descrito no capítulo Copiar discos entre Contas de Armazenamento do Azure deste documento seria aplicável.

Uma restauração de estado consiste em excluir a VM base, bem como os discos originais da VM base e os discos montados, copiando os discos salvos de volta à Conta de Armazenamento original ou grupo de recursos para managed disks e, em seguida, reimplantando o sistema. Para obter mais informações, confira Como criar scripts desse processo no PowerShell.

Não se esqueça de instalar uma nova licença SAP, já que restaurar um backup de VM, conforme descrito acima, cria uma nova chave de hardware.

Backup online de um sistema SAP

O backup do DBMS é executado com métodos específicos de DBMS, conforme descrito no Guia de DBMS.

O backup de outras VMs no sistema SAP pode ser feito usando a funcionalidade de Backup de máquinas virtuais do Azure. O Backup de Máquina Virtual do Azure é um método padrão para fazer backup de uma VM completa no Azure. O Backup do Azure armazena os backups no Azure e permite uma restauração de uma VM novamente.

Observação

Desde dezembro de 2015 o uso do Backup da VM NÃO mantém a ID exclusiva da VM que é usada para licenciamento SAP. Isso significa que uma restauração de um backup de VM exige a instalação de uma nova chave de licença da SAP, já que a VM restaurada é considerada como uma nova VM e não uma substituta da VM antiga que foi salva.

Windows logo. Windows

Teoricamente, as VMs que executam bancos de dados podem ser copiadas em backup de maneira consistente também se os sistemas DBMS derem suporte ao VSS (Serviço de Cópias de Sombra de Volume) do Windows da mesma forma que o SQL Server, por exemplo. No entanto, lembre-se de que com base nos backups de VM do Azure, as restaurações pontuais não são possíveis. Portanto, a recomendação é executar backups de bancos de dados com a funcionalidade do DBMS em vez de depender do backup de VM do Azure.

Para conhecer o Backup de Máquina Virtual do Azure, comece aqui: Fazer backup de uma VM do Azure usando as configurações da VM.

Outras possibilidades são usar uma combinação do Microsoft Data Protection Manager instalado em uma VM do Azure e o Backup do Azure para backup/restauração de bancos de dados. Encontre mais informações aqui: Preparar-se para fazer o backup de cargas de trabalho no Azure com o System Center DPM.

Linux logo. Linux

Não há nenhum equivalente ao VSS do Windows em Linux. Portanto, apenas backups consistentes com arquivo são possíveis, enquanto os consistentes com aplicativo não são. O backup do DBMS SAP deve ser feito usando a funcionalidade DBMS. O sistema de arquivos que inclui os dados relacionados ao SAP pode ser salvo, por exemplo, usando tar, conforme descrito em Eackup e restauração do sistema SAP no UNIX.

Azure como local de recuperação de desastre para estruturas da SAP de produção

Desde meados de 2014, extensões para vários componentes do Hyper-V, System Center e Azure permitem o uso do Azure como local de DR para VMs executadas localmente com base no Hyper-V.

Um blog que detalha como implantar essa solução está documentado aqui: Como proteger soluções SAP com o Azure Site Recovery.

Resumo da alta disponibilidade para sistemas SAP

Os pontos principais de alta disponibilidade para sistemas SAP no Azure são:

Neste momento, o único ponto de falha da SAP não pode ser protegido exatamente da mesma maneira como pode ser feito em implantações locais. O motivo é que os clusters desse disco compartilhado ainda não podem ser criados no Azure sem o uso de software de terceiros.
Para a camada de gerenciador de banco de dados, você precisa usar a funcionalidade que não depende da tecnologia de cluster de disco compartilhado. Os detalhes estão documentados no Guia de DBMS.
Para minimizar o impacto de problemas nos domínios de falha na manutenção de host ou de infraestrutura do Azure, você deve usar conjuntos de disponibilidade do Azure:
- É recomendável ter um conjunto de disponibilidade para a camada do aplicativo SAP.
- É recomendável ter um conjunto de disponibilidade separado para a camada de DBMS SAP.
- NÃO é recomendável aplicar o mesmo conjunto de disponibilidade para VMs de sistemas SAP diferentes.
- É recomendável usar Managed Disks Premium.
Para fins de Backup da camada do SAP DBMS, confira o Guia do DBMS.
Fazer backup de instâncias de caixas de diálogo SAP não faz muito sentido, já que é normalmente mais rápido reimplantar instâncias de caixa de diálogo simples.
Fazer backup da VM que contém o diretório global do sistema SAP e, com ela, todos os perfis das diferentes instâncias faz sentido e deve ser executado com o Backup do Windows ou, por exemplo, tar no Linux. Como há diferenças entre o Windows Server 2008 (R2) e o Windows Server 2012 (R2) que facilitam o backup usando versões mais recentes do Windows Server, é recomendável executar o Windows Server 2012 (R2) como sistema operacional convidado Windows.

Próximas etapas

Leia os artigos: