Mais de 10 anos atrás, a Microsoft anunciou a disponibilidade da plataforma Azure para um amplo público de usuários. Durante esse tempo, muitas empresas queriam aproveitar a infraestrutura em nuvem para resolver os problemas atuais de TI. Alguns deles nos contataram para obter conselhos sobre como implantar sistemas na nuvem. Mas o tempo passou e agora a empresa está considerando a possibilidade de colocar nas nuvens sistemas que consomem muitos recursos, como SAP HANA. Nós, por sua vez, já implementamos vários projetos semelhantes e estamos prontos para compartilhar essas observações que podem garantir uma implantação mais bem-sucedida do sistema SAP na nuvem MS Azure. Algumas observações não serão uma descoberta, mas queríamos mostrar a aplicabilidade de algumas abordagens em uma plataforma de nuvem. Queremos compartilhar com você as principais lições aprendidas.
Nº 1: otimizar consistentemente a arquitetura de TI usando a nuvem
Como parte da migração de um sistema produtivo, enfrentamos o problema de alto consumo de recursos nos processos de teste e desenvolvimento, o que acabou nos fazendo pensar sobre porque precisamos de tantos recursos para o ambiente de Teste e Desenvolvimento e como otimizar o consumo de recursos de infraestrutura por um sistema produtivo.
A abordagem recomendada para construir um sistema SAP é baseada em uma avaliação da capacidade necessária usando a calculadora SAP Quick Sizer. Até agora, as metodologias SAP são baseadas em abordagens padrão que não levam em consideração as peculiaridades das tecnologias de nuvem. Recebemos os requisitos do Cliente, inserimos os dados iniciais nos estimadores SAP e recebemos uma configuração de paisagem preliminar. No caso da infraestrutura convencional, foi possível parar por aí e passar para a compra de equipamentos, mas no nosso caso foi possível aproveitar a nuvem. Na nuvem, os recursos podem ser aumentados a qualquer momento e, portanto, abandonamos a reserva de recursos em excesso incluída no estimador e implantamos máquinas de desempenho inferior. Isso permitiu reduzir custos,e conforme a carga aumenta, podemos sempre aumentar o desempenho das máquinas virtuais SAP em minutos.
A Microsoft fornece suporte SAP apenas em VMs da série M. O uso de recursos de teste semelhantes ao ambiente de produção em termos de nível de suporte no estágio inicial de desenvolvimento parecia redundante para nós.
Ao mesmo tempo, as máquinas da série E têm características semelhantes às da série M, mas seu custo é significativamente menor. Como resultado, substituímos as máquinas de teste pela série E. A desvantagem dessa substituição é a transferência da responsabilidade pela operação do sistema em ambientes de teste do fornecedor para o integrador. Isso impõe a necessidade de o integrador ter experiência em SAP.
Nº 2: Como economizar no consumo de recursos
O MS Azure permite que você economize significativamente ao reservar recursos com um pré-pagamento simultâneo por um ou 3 anos.
Freqüentemente, no estágio inicial, o cliente não consegue estimar com precisão a data de lançamento de um sistema produtivo, uma vez que seu desenvolvimento e teste são frequentemente associados a muitas variáveis que estão do lado dos desenvolvedores do negócio ou contratados.
Por exemplo, no momento do lançamento de um dos projetos, planejamos a implantação simultânea de todos os ambientes com base nos planos atuais do Cliente. Como costuma acontecer, o desenvolvimento exigiu uma coordenação mais longa com o negócio, o que atrasou o lançamento produtivo por vários meses.
Neste exemplo, uma reserva de recursos pré-pagos resultaria na perda de uma quantidade significativa de fundos para o Cliente. Claro, é necessário reservar recursos, mas é mais eficiente fazer isso em fases posteriores do projeto, quando a maior parte do sistema produtivo se estabilizou e o desenvolvimento se tornou previsível em termos de consumo de recursos. Freqüentemente, quando você reserva recursos de computação por 3 anos, pode obter uma economia de cerca de 70% em comparação com o método de pagamento pré-pago.
Nº 3: Como escolher uma região do Azure
O Azure tem uma ampla variedade de regiões de hospedagem de recursos. Um dos principais critérios para a escolha de uma região é o afastamento de sua infraestrutura dos usuários finais, o que afeta a resposta do sistema e o funcionamento das integrações e dos usuários finais.
O segundo critério, não menos importante, é a lista de serviços em uma determinada região.
Alguns serviços estão disponíveis dependendo da região. Muitas vezes, os serviços são fornecidos como uma prévia antes do lançamento oficial. Algumas regiões são mais rápidas para introduzir novas tecnologias e permitir o teste de um ou outro serviço emergente. Nem todas as regiões oferecem a capacidade de usar toda a gama de séries de máquinas virtuais.
Em nossa prática, a comparação da velocidade de acesso geralmente mostra a vantagem da região da Europa Ocidental. Isso é especialmente perceptível para empresas cujos servidores e clientes estão localizados na parte europeia da Rússia. Em cada caso específico, e especialmente se seus data centers e clientes estiverem localizados no Extremo Oriente, faz sentido verificar os atrasos de seu data center (ou da região geográfica onde seus clientes estão localizados) para escolher a melhor região do Azure.
Serviços como o Teste de Latência do Azure permitem que você teste proativamente a latência para cada uma das regiões do Azure a partir da rede do data center. Um exemplo dos resultados da medição da latência usando o serviço mencionado ao testar em nosso escritório em Moscou:
Nº 4: Como aplicar métodos baseados em solo a instalações em nuvem
Em cada migração, nos perguntamos como usar soluções tradicionais comprovadas por infraestrutura clássica na nuvem. Em particular, ao preparar uma solução, contamos com as recomendações do fornecedor para desenvolver uma solução tecnicamente correta. Os projetos SAP HANA não são exceção e também passam pelo prisma das recomendações e melhores práticas.
Em um dos projetos, durante o primeiro estágio da solução, um servidor Jump baseado em Windows foi implantado. Para otimizar os custos do estágio inicial de desenvolvimento, um servidor NFS foi implantado no mesmo servidor para as necessidades de ambientes improdutivos, que cobriu as necessidades atuais dos desenvolvedores e permitiu uma economia significativa de recursos.
Com o passar do tempo, os ambientes e requisitos de recursos aumentaram e o servidor NFS lidou com todas as tarefas. Gradualmente, no âmbito do projeto, abordamos o esgotamento dos recursos da VM inicial. Os recursos da VM no MS Azure podem ser aumentados em minutos, mas, ao mesmo tempo, os requisitos de tolerância a falhas do servidor aumentaram, o que nos fez considerar uma reconfiguração maior.
Para a implementação, foram utilizados um servidor Linux, serviço DRBD e a funcionalidade de conjunto de disponibilidade, que encerrou o problema de replicação de dados entre os nós do cluster NFS e aumentou a disponibilidade em caso de falha de um dos dois nós do cluster.
A propósito: alguns meses após a implementação da solução de cluster, o serviço NetApp Files foi adicionado ao Azure, o que permite que você aproveite os arrays da NetApp, mas pagos pelo modelo pré-pago.
Nº 5: Como automatizar a programação da VM
Ao usar qualquer infraestrutura de nuvem, sempre faz sentido analisar quais mecanismos adicionais podem ser usados para maximizar a economia de custos.
No nosso caso, os sistemas são testados durante o horário comercial. Enquanto em uma infraestrutura convencional o tempo de inatividade do servidor se traduz principalmente em contas de energia aumentadas, na nuvem os servidores não úteis consomem finanças para alugar capacidade. Avaliamos os gráficos de carga em servidores de teste e desenvolvimento e notamos que a grande maioria dos desenvolvedores e testadores usa o sistema nos dias de semana de 8-00 a 20-00.
Nos casos em que a programação de carga para sistemas improdutivos é previsível e cíclica, tentamos usar scripts para automatizar a ativação / desativação da VM. O Azure tem várias ferramentas: desligamento automático, contas de automação e Cloud Shell. Nem todos eram adequados para nós. O desligamento automático foi excluído porque só pode desligar a VM. O Cloud Shell também não se envolveu, pois exige a preparação de scripts adicionais, elaboração de gráficos e um local seguro para armazenar tudo isso com a presença de redundância, o que reduziu a economia ao mínimo.
Em nosso caso, um mecanismo mais flexível é usado. O Automation Accounts oferece uma solução pronta e funcional na forma de runbooks, permitindo que você ligue e desligue máquinas virtuais de acordo com uma programação.
Preparamos gráficos para os respectivos recursos, carregamos os runbooks e formamos links entre os gráficos e recursos.
Como resultado, reduzimos ainda mais o custo total de propriedade. Inicialmente, essas ferramentas não estavam planejadas para implementação, mas foram implementadas já na fase de operação preliminar.
A alteração da programação é feita em alguns minutos. Primeiro, um novo cronograma é formado e, em seguida, o cronograma gerado é associado ao recurso necessário. Se necessário e houver um grande número de mudanças, é possível usar o Cloud Shell para automatizar esse processo.
Nº 6: Monitorar o consumo de recursos
Enquanto para data centers convencionais, monitoramento de integridade e consumo de recursos, infelizmente, geralmente desaparecem em segundo plano, no Azure não é desejável permitir isso. As informações sobre o histórico de consumo de recursos afetam diretamente as possibilidades de otimização de custos. E no caso de reserva antecipada de recursos, pode servir de sinalização para melhorias arquitetônicas.
# 7: Seguro de Força Maior
Muitas empresas têm medo de colocar seus sistemas de TI em recursos de nuvem devido ao medo de bloqueios, que antes eram alvos de reguladores. Como qualquer outro risco, isso também pode ser levado em consideração ao projetar um sistema. Em projetos, nós, via de regra, implementamos um descarregamento semanal de backups do sistema da nuvem para o data center do Cliente. Isso permite que você tenha certeza de que o sistema pode ser restaurado em qualquer eventualidade. Além disso, utilizamos uma estratégia de instalação multicloud, que permitirá em caso de restrição de acesso não ficar sem acesso aos recursos. Nesse cenário, provedores de nuvem alternativos são usados como sites de DR para a nuvem principal, o que permite que o sistema seja restaurado em caso de bloqueios massivos.
No. 7 + Processamento de dados pessoais
Durante nosso trabalho, formamos uma abordagem sobre como armazenar e processar dados pessoais em sistemas que incluem recursos de nuvem externos. Observe que a implementação desta abordagem deve ser realizada levando em consideração os requisitos dos reguladores. Este tópico é bastante extenso e tentaremos abordá-lo nos próximos artigos se notarmos o interesse correspondente nos comentários.
Resultado
Neste artigo, revisamos várias lições práticas sobre como hospedar SAP na nuvem MS Azure. Obviamente, o tema é extremamente amplo e pudemos abordar apenas uma parte das otimizações possíveis ao migrar para a nuvem.
Que nuances você encontrou? Ficaríamos muito gratos se você compartilhar sua experiência nos comentários.