.
Recurso patrocinado Se você ainda estiver hospedando o Microsoft SQL Server internamente, talvez seja hora de dar ao administrador de banco de dados algum tempo livre para se concentrar em coisas que agregam mais valor aos negócios do que o gerenciamento de rotina. Certamente parece que mais empresas estão migrando para bancos de dados gerenciados na nuvem, de acordo com Gartner. Em 2017, as receitas de banco de dados local superaram a receita de banco de dados gerenciado. Em 2021, eles eram iguais em tamanho.
A Amazon Web Services (AWS) oferece suporte ao SQL Server por meio do Amazon Relational Database Service (Amazon RDS) desde 2012. Então, por que uma organização de usuário final pode considerar a mudança para um serviço de nuvem gerenciado para SQL Server e o que está envolvido na migração? ?
O apelo dos serviços gerenciados
Oluropo Rufus Ayodele, arquiteto de dados líder da AWS Premier Consulting Partner Onica, acredita que uma abordagem gerenciada para bancos de dados elimina grande parte do trabalho pesado dos usuários. Os administradores de banco de dados não precisam gastar tanto tempo supervisionando coisas como backups, provisionamento e patches que são tratados automaticamente, por exemplo.
Os serviços gerenciados também oferecem segurança integrada criptografando dados em repouso e em trânsito. Um SQL Server local pode lidar com conexões criptografadas, mas requer alguma configuração, enquanto um serviço gerenciado fornece isso como uma opção pronta para uso.
Os bancos de dados gerenciados oferecem funcionalidade de backup integrada, configurável por meio do console, que remove outra tarefa da lista de tarefas do DBA. Os clientes podem reduzir a probabilidade de precisar restaurar esses backups graças à redundância integrada na forma de várias zonas de disponibilidade (Multi-AZ) e réplicas. Os usuários do RDS podem configurá-los simplesmente porque fazem parte da infraestrutura da AWS, facilitando a manutenção dos bancos de dados em funcionamento.
“Com bancos de dados locais, você precisa agendar o tempo de inatividade”, explica Ayodele. “No entanto, com o RDS, você tem um tempo de inatividade mínimo, já que a instância de espera falha rapidamente e se torna o novo servidor primário, após a conclusão da manutenção.”
Os clientes também podem monitorar seus Amazon RDS para SQL Server instâncias usando ferramentas integradas, como CloudWatch, Performance Insight e Enhanced Monitoring, em vez de instalar e configurar ferramentas de monitoramento de terceiros.
Por fim, os serviços gerenciados oferecem provisionamento mais fácil, diz Ayodele. Os clientes podem automatizar seu provisionamento para dimensionar facilmente o uso do banco de dados e acomodar as flutuações da carga de trabalho.
A mudança para o RDS também oferece economia de licenças. Para novos projetos que exigirão núcleos SQL Server adicionais, os clientes podem se beneficiar do modelo RDS de pagamento conforme o uso, incluindo licenciamento da Microsoft, o que representa uma economia de custos inicial.
O céu é o limite
O serviço oferece capacidade flexível e opções de dimensionamento para atender a diferentes cargas de trabalho. Os clientes podem desfrutar de até 128 vCPUs e 4.096 gigabytes (GiB) de RAM por instância com RDS for SQL Server. A memória por instância pode ser dimensionada para os recursos do sistema operacional e a potência da CPU pode ser aumentada. O RDS for SQL Server pode lidar com bancos de dados com até 16 tebibytes (TiB) de armazenamento. Os clientes também podem dissociar o armazenamento do dimensionamento da CPU, permitindo que eles dimensionem cada um para suas cargas de trabalho específicas sem pagar por recursos extras de que não precisam.
Ao contrário dos sistemas locais, dimensionar o banco de dados geralmente nem sempre envolve necessariamente tempo de inatividade. O AWS Auto Scaling permite que o cliente escale verticalmente (mas não reduza) sem deixar o sistema offline. Mas se eles quiserem provisionar um tamanho de instância maior – de M5.xlarge a M5.2xlarge, por exemplo – ainda haverá uma pequena interrupção.
Portanto, embora os DBAs não precisem provisionar memória e CPUs extras para lidar com picos de demanda de armazenamento, eles devem planejar um pequeno período de inatividade ao provisionar para obter mais CPU e memória. Os clientes podem agendar esses eventos em sua janela de manutenção para minimizar o impacto.
O RDS for SQL Server oferece suporte ao paralelismo da mesma forma que em um ambiente local. Ele usa todos os núcleos sem redundância para otimizar o uso dos recursos da CPU. Embora as consultas no modo de lote sejam limitadas a dois graus de paralelismo no RDS para SQL Server Standard Edition, o Enterprise Edition pode usar todos os núcleos, permitindo aumentar consideravelmente o desempenho em consultas maiores.
A mudança das implantações do SQL Server para o RDS permitiu que a Onica trouxesse aos clientes vantagens de custo significativas. Uma empresa do setor de publicidade e publicação já estava executando o SQL Server em uma instância AWS EC2, por exemplo, mas queria modernizar mudando para um serviço gerenciado. “Eles mudaram para a RDS porque estavam crescendo”, explica Ayodele, mas queriam ser o mais econômicos possível.
A Onica trabalhou com o cliente para criar uma opção RDS de pagamento conforme o uso. Isso permitiu que o cliente otimizasse o uso da nuvem executando seletivamente uma réplica na região da Ásia-Pacífico, que respondeu a algumas consultas durante o horário da APAC. Um script habilitava essa réplica apenas durante essas horas, desligando-a durante o horário europeu, quando a maioria de suas consultas vinha do oeste.
Muitos clientes, como a empresa de publicidade e publicação, experimentarão ganhos de eficiência e flexibilidade aprimorados para aumentar e diminuir várias cargas de trabalho, com tempo de inatividade mínimo ou nulo, traduzindo-se em maior lucratividade a longo prazo, diz Onica
A mecânica da migração
Uma migração homogênea entre uma versão local do SQL Server e o equivalente RDS pode ser relativamente fácil, diz Ayodele. A única mudança necessária é uma alteração do esquema do sistema. O RDS tem procedimentos armazenados internos para fins de gerenciamento que não estão no mecanismo do SQL Server local. Assim, os clientes podem simplesmente migrar o próprio banco de dados para evitar corromper o esquema do sistema RDS.
O próximo passo será usar ferramentas nativas ou Serviço de migração de banco de dados da AWS (AWS DMS) para transportar os dados da origem para o destino. Com o AWS DMS, o banco de dados de origem permanece operacional durante esse processo para minimizar o tempo de inatividade. O DMS pode usar a tecnologia Change Data Capture (CDC) para acompanhar as alterações contínuas no banco de dados de origem durante a migração. Depois que a migração for concluída, as etapas finais serão executar a versão do RDS como uma réplica e, em seguida, alternar para a instância de banco de dados primária do RDS quando estiver pronta.
Existem algumas práticas recomendadas que os clientes devem seguir ao migrar, diz Ayodele. “A velocidade da conexão de rede é importante”, diz ele. “Você deve capturar isso no início do projeto.” Nada impede um projeto de migração de dados como um tubo fino que cria um gargalo de dados.
Outra etapa crítica é realizar testes de desempenho adequados para garantir que o sistema de destino funcione conforme o planejado. A Onica normalmente coleta dados do sistema SQL Server do cliente no local ou baseado em EC2 coletados nos seis meses anteriores para entender o uso e a velocidade da memória. Em seguida, eles escrevem código para obter essas informações, coletando amostras que refletem diferentes cenários de produção ao longo do tempo, como entrada/saída (E/S) constante e pontiaguda.
A Onica usa esses dados de amostra para informar a configuração do sistema RDS. Depois de criar o ambiente de nuvem, eles executarão alguns benchmarks simples para avaliar seu desempenho. Esses procedimentos de projeto e teste ajudam o cliente a otimizar a configuração antes de migrar todos os dados. “Isso nos ajuda a evitar erros como superdimensionar as CPUs”, explica Ayodele.
O começo é apenas o começo
Quando os clientes devem começar a migrar o SQL Server para o RDS? Para alguns, o melhor momento foi ontem, e o próximo melhor momento é hoje. Eventos como fim de suporte (EOS) ou expiração de licença futura podem desencadear essas decisões.
Por exemplo, o SQL Server 2012 e 2012/R2 chegaram ao fim do suporte em julho de 2022, o que deixará alguns clientes da Microsoft sem atualizações de segurança, atualizações não relacionadas à segurança, correções de bugs ou suporte técnico. Eles podem obter atualizações de segurança estendidas (ESUs) até 2025, mas isso ainda os deixa sem atualizações não relacionadas à segurança. Se o uso do SQL Server for crítico para seus negócios, pode fazer mais sentido modernizar agora com uma implantação na nuvem.
O SQL Server 2019 chegará ao fim de seu suporte principal em janeiro de 2025, portanto, qualquer organização com uma licença de serviço SQL local que expire antes disso pode querer considerar dar o salto agora em vez de renovar mais tarde.
A licença do SQL Server está incluída no custo do RDS for SQL Server sob seu modelo de licença incluída (Standard, Enterprise, Express, Web), o que evita que os clientes tenham que se preocupar com os termos de licenciamento. Sem compromissos ou taxas iniciais, os clientes podem pagar sob demanda ou escolher a instância reservada por um ou três anos com desconto para economia adicional.
Não deixe para muito tarde, alerta Ayodele. Ter tempo suficiente para migrar dá aos clientes a oportunidade de reavaliar sua infraestrutura de dados e buscar oportunidades de otimização, ressalta.
Há também oportunidades para dividir a arquitetura de banco de dados relacional e colocar parte dela em opções NoSQL, acrescenta. “A maioria dos bancos de dados NoSQL não tem servidor e temos arquitetos que podem integrá-los para você.”
Pensar no futuro sobre a migração para o RDS for SQL Server também oferece aos clientes o tempo necessário para garantir a adesão da liderança.
Um processo típico de descoberta da Onica começa trabalhando com a equipe técnica de um cliente e conduzindo uma avaliação de prontidão de migração para entender sua infraestrutura atual. Em seguida, eles realizam uma análise técnica de custo de propriedade para entender parâmetros como quantos servidores o cliente provavelmente usará e o volume de dados que processará.
“Os gerentes técnicos seniores se envolvem no final deste trabalho e examinam o relatório”, diz Ayodele. “Isso leva a mais perguntas sobre o que está impulsionando o projeto.”
Uma base para uma maior modernização
Depois que os clientes fizerem o salto para o RDS for SQL Server, eles poderão aproveitar os outros serviços que a AWS tem a oferecer, modernizando ainda mais sua arquitetura, diz Ayodele. “Uma opção comum são os serviços de aprendizado de máquina de inteligência artificial (IA)”, diz ele. Isso inclui recursos como reconhecimento de imagem e vídeo. Ele dá um exemplo de uma empresa que deseja garantir que seus anúncios sejam reproduzidos apenas ao lado de vídeos apropriados. “O reconhecimento de vídeo pode ajudá-lo a fazer isso”, diz ele.
Outros aplicativos para aprendizado de máquina incluem análises preditivas, que os clientes do SQL Server para RDS podem usar por meio da integração avançada do R e do Python. No lado da infraestrutura, a capacidade de rodar em GPUs e oferecer paralelismo completo permite que o serviço seja dimensionado de acordo com as necessidades dos clientes, conclui Ayodele.
A migração do SQL Server local para serviços gerenciados do Amazon RDS não precisa ser difícil e pode apresentar alguns benefícios operacionais e de custo significativos. No entanto, algumas empresas ainda podem achar isso esmagador ou podem exigir ajuda de profissionais experientes.
Um parceiro de serviços de consultoria nativo da nuvem como a Onica pode ajudá-lo a dar o salto, diz Ayodele, garantindo que você faça as malas adequadamente para a viagem e faça pleno uso da nuvem quando chegar.
Patrocinado pela AWS.
.
