Planejar, implantar e verificar o SQL Azure
Após selecionar uma carga de trabalho para migrar ou criar no SQL do Azure, você precisará planejar a migração, implantar adequadamente e verificar se a implantação foi bem-sucedida. Nesta unidade, você aprendeu vários métodos para cada etapa do processo.
Planejamento da pré-implantação
Antes de começar a realizar implantações no Azure, é importante entender seus requisitos e como eles são mapeados para ofertas no SQL do Azure. Usando o que você aprendeu no módulo de introdução ao SQL do Azure, faça um plano. Você precisa responder às seguintes perguntas:
- Método de implantação: portal do Azure ou interface de linha de comando?
- Opção de implantação: Máquina virtual, banco de dados, pool elástico, instância gerenciada ou pool de instâncias?
- Modelo de compra (somente Banco de Dados SQL do Azure): DTU ou vCore?
- Camada de serviço: Uso Geral, Comercialmente Crítico ou Hiperescala?
- Hardware: gen5 ou algo novo?
- Dimensionamento: Número de vCores e tamanho máximo de dados?
Talvez antes de responder às perguntas anteriores, você também precise escolher uma carga de trabalho que será migrada para o SQL do Azure ou que será nascida na nuvem. Se você está migrando, há muitas ferramentas e recursos disponíveis para ajudar você a planejar, avaliar, migrar e otimizar os bancos de dados e o aplicativo. Fornecemos recursos no final deste módulo.
Limites de recursos
O módulo de introdução ao SQL do Azure descreveu limites, taxas e funcionalidades, como IOPS ou OLTP na memória. Há outros limites de recursos afetados pela sua escolha de Instância Gerenciada de SQL do Azure, de Banco de Dados SQL do Azure ou de opções dentro destas opções:
- Memória
- Tamanho máximo do log
- Taxa do log de transações
- IOPS de dados
- Tamanho do tempdb
- Número máximo de trabalhos simultâneos
- Retenção de backup
Os limites da Instância Gerenciada de SQL do Azure e do Banco de Dados SQL do Azure dependem da sua escolha do modelo de compra, da camada de serviço e do número de vCores ou DTU apenas no Banco de Dados SQL do Azure.
A Instância Gerenciada de SQL do Azure e o Banco de Dados SQL são ofertas de PaaS (plataforma como serviço). Restringir essas opções não deve reduzir a sua capacidade de usar integralmente um serviço gerenciado do SQL Server.
Em uma instância do Banco de Dados SQL do Azure de uso geral, sua escolha de computação provisionada ou sem servidor também afeta esses limites. Antes de implantar, analise o que está incluído na implantação planejada para garantir que está começando com o que precisa.
Os recursos do SQL do Azure têm limites gerais de recursos por assinatura e por região. Se você precisar aumentar os limites, solicite um aumento de cota no portal do Azure.
Implantação
Após a conclusão do planejamento pré-implantação, é hora de colocar o plano em ação. Nessa fase, você implantará o SQL do Azure usando o portal do Azure ou a linha de comando, determinará a configuração de rede e fará uma conexão inicial.
Para o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure, há basicamente seis painéis no portal do Azure para serem preenchidos durante uma implantação.
Servidor
Quando você cria uma Instância Gerenciada de SQL do Azure, o procedimento para fornecer o nome do servidor é o mesmo que no SQL Server. Para bancos de dados e pools elásticos, é obrigatório um Banco de Dados SQL do Azure. Um servidor do Banco de Dados SQL do Microsoft Azure é um servidor lógico que atua como um ponto administrativo central para um banco de dados em pool ou individual. Ele inclui logons, regras de firewall, regras de auditoria, políticas de detecção de ameaças e grupos de failover. Você saberá mais sobre esses elementos mais tarde.
Esse servidor lógico não expõe nenhum acesso em nível de instância nem recursos como com a Instância Gerenciada de SQL do Azure. Para servidores de Banco de Dados SQL do Azure, o nome do servidor deve ser exclusivo em todo o Azure.
Computação e armazenamento
No módulo anterior deste roteiro de aprendizagem, você aprendeu sobre as opções e recomendações para computação e armazenamento, incluindo camadas de serviço, modelos de compra e gerações de hardware. Você precisará selecionar a configuração desejada durante a implantação. Você também precisa determinar o número de vCores e o Tamanho máximo de dados.
De uma forma geral, se estiver migrando, é recomendável usar um tamanho semelhante ao que você usa na implantação local. Também é possível usar ferramentas como o recomendador de SKU do Assistente de Migração de Dados para estimar o número de vCores e o tamanho máximo de dados com base em sua carga de trabalho atual.
O Tamanho máximo dos dados não é necessariamente o tamanho dos seus dados atualmente. Ele é a quantidade máxima de espaço de dados que pode ser alocada para o seu banco de dados. Isso também ajuda você a entender a alocação do espaço do log, o qual é dimensionado com Tamanho máximo de dados.
Configuração de rede
As opções de rede para o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure são diferentes. Quando você implantar um Banco de Dados SQL do Azure, o padrão atual será Sem acesso.
Você pode selecionar um ponto de extremidade público ou um ponto de extremidade privado. No exercício que segue esta unidade, utilize o ponto de extremidade público e defina a opção Permitir que os serviços e recursos do Azure acessem este servidor como Sim. Outros serviços do Azure podem acessar o banco de dados, por exemplo, o Azure Data Factory ou as Máquinas Virtuais do Azure. Também é possível selecionar Adicionar endereço IP do cliente atual para se conectar por meio do endereço IP do computador cliente usado para implantar o Banco de Dados SQL do Azure.
Com a Instância Gerenciada de SQL do Azure, você o implanta dentro de uma rede virtual do Azure e de uma sub-rede dedicada a instâncias gerenciadas, o que lhe permite ter um endereço IP privado seguro. A Instância Gerenciada de SQL do Azure fornece pode conectar uma rede local a uma instância gerenciada, conectar uma instância gerenciada a um servidor vinculado ou a outro armazenamento de dados local e conectar uma instância gerenciada a outros recursos.
Além disso, é possível habilitar um ponto de extremidade público para que você possa se conectar à instância gerenciada da Internet sem uma VPN (rede virtual privada). Esse acesso está desabilitado por padrão.
Fonte de dados
No Banco de Dados SQL do Azure, é possível selecionar o banco de dados AdventureWorksLT como exemplo durante a implantação no portal do Azure. Na Instância Gerenciada de SQL do Azure, você implanta primeiro a instância e depois os bancos de dados dentro dela. Você não pode ter o banco de dados de exemplo no ato da implantação, semelhante ao que ocorre com o SQL Server. É possível aprender mais sobre os bancos de dados de exemplo AdventureWorks no GitHub.
Você também pode implantar um banco de dados em branco ou criar um banco de dados com base na restauração de um backup replicado geograficamente.
Ordenações de banco de dados
Ordenações no SQL Server e no SQL do Azure dizem ao mecanismo de banco de dados como tratar determinados caracteres e idiomas. Uma ordenação fornece as propriedades de regras de classificação, de diferenciação de maiúsculas e minúsculas e de diferenciação de acentos para os seus dados.
Quando você criar um novo banco de dados SQL ou uma instância gerenciada do SQL, leve em conta os requisitos de localidade dos dados com os quais está trabalhando. O conjunto de ordenações afeta as características de muitas operações no banco de dados. No produto tradicional do SQL Server, a configuração regional do sistema operacional geralmente determina a ordenação padrão.
Na Instância Gerenciada de SQL do Azure, defina o agrupamento do servidor na criação da instância. Não é possível alterá-lo posteriormente. A ordenação do servidor define o padrão para todos os bancos de dados nessa instância gerenciada de SQL, mas você pode modificar as ordenações em um nível de banco de dados e de coluna.
No Banco de Dados SQL do Azure, você não pode definir a ordenação do servidor. Está definido na ordenação padrão e mais comum de SQL_Latin1_General_CP1_CI_AS, mas você pode definir a ordenação do banco de dados. Para interromper esse valor em partes:
SQLsignifica que se trata de uma ordenação do SQL Server, em vez de uma ordenação primária do Windows.Latin1_Generalespecifica o alfabeto ou o idioma a ser utilizado na classificação.CP1faz referência à página de código usada pela ordenação.CIsignifica que não diferencia maiúsculas de minúsculas.CSsignifica diferenciar maiúsculas e minúsculas.ASsignifica que ele considera a acentuação.AIsignifica indiferente a acentos.
Outras opções estão disponíveis. Os exemplos são larguras de caracteres e codificação UTF-8. Você pode encontrar mais detalhes sobre o que é e o que não é possível fazer com o SQL do Azure na documentação.
Aceitação do Microsoft Defender para Nuvem
Quando você implanta o Banco de Dados SQL do Azure no portal do Azure, ele solicita se você deseja habilitar o Microsoft Defender para Nuvem em uma avaliação gratuita. Selecione Iniciar avaliação gratuita. Após a avaliação gratuita, o Defender para Nuvem é cobrado de acordo com o preço da camada Standard do Microsoft Defender para Nuvem.
Após habilitá-lo, você obtém funcionalidades relacionadas à identificação e mitigação de potenciais vulnerabilidades do banco de dados e à detecção de ameaças. Para obter mais informações sobre essas funcionalidades, consulte o próximo módulo de segurança deste roteiro de aprendizagem.
Na Instância Gerenciada de SQL do Azure, você pode habilitar o Microsoft Defender para Nuvem na instância após a implantação.
Análise de seleções
No painel Revisar e criar, revise as seleções de implantação e os termos do Azure Marketplace.
Dica
Você também tem a opção Baixar um modelo para automação, que fornece um modelo do Azure Resource Manager (modelo do ARM) para implantações configuráveis e repetíveis. Esta unidade não abrange os modelos do ARM. Se você estiver interessado, saiba mais sobre as Especificações de Modelo.
Detalhes da implementação da implantação de chave
Embora o Azure cuide da implantação para você, existem alguns detalhes da implementação da implantação que você deve estar ciente. Todos os serviços são criados no backbone do Azure conhecido como Azure Service Fabric. Compreender o back-end de como alguns desses serviços são implantados e dimensionados no Azure Service Fabric ajuda você a entender os vários comportamentos que poderá ver.
Instância Gerenciada do Azure SQL
Nos bastidores, o Azure implanta um anel dedicado para a Instância Gerenciada de SQL do Azure (às vezes chamado de cluster virtual), para seu serviço. Essa arquitetura ajuda a fornecer segurança e suporte nativo a redes virtuais.
Devido a essa arquitetura, as operações de implantação e colocação em escala podem levar mais tempo. Por exemplo, quando você escala ou reduz verticalmente, o Azure implanta um novo cluster virtual para você e propaga seus dados nele. Você pode considerar cada instância como sendo executada em apenas uma máquina virtual.
Os pools de Instância SQL do Azure foram introduzidos para ajudar com o tempo de implantação longo. Você pode pré-implantar um pool de recursos dedicados. A implantação em um pool e o dimensionamento dentro de um pool são mais rápidos do que as implantações tradicionais. Você também obtém uma maior densidade de empacotamento, pois pode implantar várias instâncias em uma única máquina virtual.
Banco de Dados SQL do Azure
O Banco de Dados SQL do Azure está contido em um servidor de banco de dados lógico. Na maioria dos casos, uma instância dedicada do SQL Server hospeda o banco de dados SQL, mas não é necessário se preocupar com o gerenciamento da instância.
O servidor de banco de dados lógico fornece algo com o qual se conectar. Ele também permite agrupar e gerenciar determinadas permissões e configurações. Dentro de cada servidor de banco de dados lógico há um banco de dados primário lógico, que pode fornecer diagnósticos no nível da instância.
Banco de Dados SQL do Azure – Hiperescala
A camada Hiperescala do Banco de Dados SQL do Azure, que não está disponível na Instância Gerenciada de SQL do Azure, tem uma arquitetura exclusiva para o SQL do Azure. A equipe do SQL do Azure rearquitetou a Hiperescala para a nuvem. Essa arquitetura inclui um sistema de cache de várias camadas que pode ajudar tanto na velocidade quanto na escala. A colocação em escala e outras operações não estão mais relacionadas ao tamanho dos dados e podem ser concluídas em tempo constante, em questão de minutos. O uso do armazenamento remoto também permite backups de instantâneo.
Em um módulo posterior do roteiro de aprendizagem sobre os princípios básicos do SQL do Azure, você aprenderá mais sobre a arquitetura e como ela afeta o desempenho e a disponibilidade. Uma consideração a ser feita durante a fase de implantação é que, após mover um banco de dados para a camada Hiperescala, você não poderá voltar para a camada Uso Geral ou Comercialmente Crítico.
Governança de recursos
À medida que você aumenta ou diminui os recursos em uma camada de serviço, os limites de dimensões como CPU, armazenamento e memória podem ser alterados até um determinado limite. Embora haja uma abordagem multifacetada para governança no SQL do Azure, as três seguintes tecnologias são as principais usadas para controlar o uso de recursos no SQL do Azure:
- Os objetos de trabalho do Windows permitem que um grupo de processos seja gerenciado e controlado como uma unidade. Os objetos de trabalho são usados para controlar o commit de memória virtual de arquivo, os limites de conjunto de trabalho, a afinidade de CPU e os limites de taxa. Você pode usar a exibição de gerenciamento dinâmico
sys.dm_os_job_objectpara ver os limites em vigor. - O Resource Governor é um recurso do SQL Server que ajuda os usuários e, nesse caso, o Azure, a controlar recursos como CPU, E/S física e memória. A Instância Gerenciada de SQL do Azure também permite grupos e pools de carga de trabalho definidos pelo usuário do Resource Governor.
- O Gerenciador de Recursos de Servidor de Arquivos está disponível no Windows Server. Ele controla as cotas de diretório de arquivos, que são usadas para gerenciar o Tamanho máximo dos dados.
Outras implementações para controlar a taxa de arquivo de alterações são integradas no mecanismo de banco de dados do Azure, por meio da governança do arquivo de alterações. Esse processo limita as altas taxas de ingestão para cargas de trabalho como BULK INSERT, SELECT INTO e builds de índice. Elas são rastreadas e impostas como o nível de subsegundo. Atualmente, elas são escalonadas linearmente em uma camada de serviço.
Verificação
Após concluir a implantação, é hora de verificar essa implantação. Nessa fase, normalmente você verifica os resultados no portal do Microsoft Azure ou na CLI do Azure, executa algumas consultas que verificam a configuração da implantação e faz os ajustes necessários.
Para a Instância Gerenciada de SQL do Azure e o Banco de Dados SQL do Azure, a primeira coisa a fazer é verificar o status do banco de dados ou da instância com o portal do Azure ou a CLI do Azure. Em seguida, você pode analisar os detalhes da implantação e o log de atividades para garantir que não existam falhas ou problemas ativos.
Para a Instância Gerenciada de SQL do Azure, você pode verificar o logon de erros, o que é algo comum a ser feito no SQL Server local ou em uma máquina virtual do Azure. Essa funcionalidade não está disponível no Banco de Dados SQL do Azure.
Por fim, você provavelmente confirmaria que a sua rede está configurada corretamente, obteria o nome do servidor e se conectaria em uma ferramenta como o SQL Server Management Studio ou o Azure Data Studio. Você pode executar as seguintes consultas para entender melhor o que você implantou e verificar se isso foi implantado corretamente:
SELECT @@VERSION
SELECT * FROM sys.databases
SELECT * FROM sys.objects
SELECT * FROM sys.dm_os_schedulers
SELECT * FROM sys.dm_os_sys_info
SELECT * FROM sys.dm_os_process_memory --Not supported in Azure SQL Database
SELECT * FROM sys.dm_exec_requests
SELECT SERVERPROPERTY('EngineEdition')
SELECT * FROM sys.dm_user_db_resource_governance -- Available only in Azure SQL Database and SQL Managed Instance
SELECT * FROM sys.dm_instance_resource_governance -- Available only in Azure SQL Managed Instance
SELECT * FROM sys.dm_os_job_object -- Available only in Azure SQL Database and SQL Managed Instance
Não há suporte para uma consulta relacionada à memória do processo do SO no Banco de Dados SQL do Azure, embora ela possa parecer funcionar. Não há suporte para essa consulta porque, com o Banco de Dados SQL do Azure, algumas coisas relacionadas ao sistema operacional são abstraídas, permitindo que você foque no banco de dados.
As três últimas consultas estão disponíveis apenas no Banco de Dados SQL do Azure e na Instância Gerenciada de SQL do Azure. O primeiro, sys.dm_user_db_resource_governance, retorna as configurações e as definições de capacidade utilizadas pelos mecanismos de governança de recursos no banco de dados ou no pool elástico atual. Você pode obter informações semelhantes para um Instância Gerenciada de SQL do Azure na segunda, sys.dm_instance_resource_governance. A terceira, sys.dm_os_job_object, retorna uma linha que descreve a configuração do objeto de trabalho que gerencia o processo do SQL Server, bem como as estatísticas de consumo de recursos.
Os próximos dois exercícios abordam todos os detalhes envolvidos na implantação do Banco de Dados SQL do Azure ou da Instância Gerenciada de SQL do Azure. Use sua assinatura do Azure para implantar o Banco de Dados SQL do Azure. Após a implantação, você usa várias consultas de verificação e notebooks SQL pré-executados no Azure Data Studio para comparar o Banco de Dados SQL, a Instância Gerenciada de SQL e o SQL Server 2019.