Exercício: proteger, monitorar e ajustar um banco de dados migrado

  • 20 minutos

Você trabalha como desenvolvedor de banco de dados para a organização AdventureWorks. A AdventureWorks vende bicicletas e peças para bicicletas diretamente para clientes finais e distribuidores há mais de uma década. Seus sistemas armazenam informações em um banco de dados que você migrou anteriormente para o Banco de Dados do Azure para PostgreSQL.

Depois de ter realizado a migração, você deve ter a garantia de que o sistema está com um bom desempenho. Você decide usar as ferramentas do Azure disponíveis para monitorar o servidor. Para aliviar a possibilidade de tempos de resposta lentos causados pela contenção e latência, você decide implementar a replicação de leitura. Você precisa monitorar o sistema resultante e comparar os resultados com a arquitetura de servidor flexível.

Neste tutorial, você executará as seguintes tarefas:

  1. Configurar as métricas do Azure no serviço Banco de Dados do Azure para PostgreSQL.
  2. Executar um aplicativo de exemplo que simule vários usuários consultando o banco de dados.
  3. Exibir as métricas.

Configurar o ambiente

Executar estes comandos da CLI do Azure no Cloud Shell para criar um banco de dados do Azure para PostgreSQL, com uma cópia do banco de dados adventureworks. Os últimos comandos vão imprimir o nome do servidor.

SERVERNAME="adventureworks$((10000 + RANDOM % 99999))"
PUBLICIP=$(wget http://ipecho.net/plain -O - -q)
git clone https://github.com/MicrosoftLearning/DP-070-Migrate-Open-Source-Workloads-to-Azure.git workshop

az postgres server create \
    --resource-group <rgn>[sandbox resource group name]</rgn> \
    --name $SERVERNAME \
    --location westus \
    --admin-user awadmin \
    --admin-password Pa55w.rdDemo \
    --version 10 \
    --storage-size 5120

az postgres db create \
    --name azureadventureworks \
    --server-name $SERVERNAME \
    --resource-group <rgn>[sandbox resource group name]</rgn>

az postgres server firewall-rule create \
    --resource-group <rgn>[sandbox resource group name]</rgn> \
    --server $SERVERNAME \
    --name AllowMyIP \
    --start-ip-address $PUBLICIP --end-ip-address $PUBLICIP

PGPASSWORD=Pa55w.rdDemo psql -h $SERVERNAME.postgres.database.azure.com -U awadmin@$SERVERNAME -d postgres -f workshop/migration_samples/setup/postgresql/adventureworks/create_user.sql

PGPASSWORD=Pa55w.rd psql -h $SERVERNAME.postgres.database.azure.com -U azureuser@$SERVERNAME -d azureadventureworks -f workshop/migration_samples/setup/postgresql/adventureworks/adventureworks.sql 2> /dev/null

echo "Your PostgreSQL server name is:\n"
echo $SERVERNAME.postgres.database.azure.com

Configure as métricas do Azure no serviço Banco de Dados do Azure para PostgreSQL

  1. Abra uma nova guia e navegue até o portal do Azure.

  2. No portal do Azure, selecione Todos os recursos.

  3. Selecione o nome do servidor do Banco de Dados do Azure para PostgreSQL começando com adventureworks.

  4. Em Monitoramento, selecione Métricas.

  5. Na página do gráfico, adicione a seguinte métrica:

    Propriedade Valor
    Escopo adventureworks[nnn]
    Namespace da métrica Métricas padrão do servidor PostgreSQL
    Métrica Conexões ativas
    Agregação Avg

    Essa métrica exibe o número médio de conexões feitas ao servidor a cada minuto.

  6. Selecione Adicionar métrica e adicione a seguinte métrica:

    Propriedade Valor
    Escopo adventureworks[nnn]
    Namespace da métrica Métricas padrão do servidor PostgreSQL
    Métrica Porcentagem de CPU
    Agregação Avg

  7. Selecione Adicionar métrica e adicione a seguinte métrica:

    Propriedade Valor
    Escopo adventureworks[nnn]
    Namespace da métrica Métricas padrão do servidor PostgreSQL
    Métrica Porcentagem de memória
    Agregação Avg

  8. Selecione Adicionar métrica e adicione a seguinte métrica:

    Propriedade Valor
    Escopo adventureworks[nnn]
    Namespace da métrica Métricas padrão do servidor PostgreSQL
    Métrica Porcentagem de E/S
    Agregação Avg

    Essas três métricas finais mostram como os recursos estão sendo consumidos pelo aplicativo de teste.

  9. Defina o período do gráfico como Últimos 30 minutos.

  10. Selecione Fixar no painel e Fixar.

Execute um aplicativo de exemplo que simule vários usuários consultando o banco de dados

  1. No portal do Azure, na página do Banco de Dados do Azure para o servidor PostgreSQL, em Configurações, selecione Cadeias de Conexão. Copie a cadeia de conexão do ADO.NET para a área de transferência.

  2. Prossiga para a pasta ~/workshop/migration_samples/code/postgresql/AdventureWorksSoakTest.

    cd ~/workshop/migration_samples/code/postgresql/AdventureWorksSoakTest

  3. Abra o arquivo App.config no editor de códigos:

    code App.config

  4. Substitua o valor do Banco de dados por azureadventureworks e substitua ConectionString0 pela cadeia de conexão da área de transferência. Altere a ID de usuário para azureuser@adventureworks[nnn] e defina a Senha como Pa55w.rd. O arquivo concluído será semelhante ao mostrado abaixo:

    <?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <appSettings>
        <add key="ConnectionString0" value="Server=adventureworks101.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="ConnectionString1" value="INSERT CONNECTION STRING HERE" />
        <add key="ConnectionString2" value="INSERT CONNECTION STRING HERE" />
        <add key="NumClients" value="100" />
        <add key="NumReplicas" value="1"/>
    </appSettings>
</configuration>

    Observação

    Ignore as configurações de ConnectionString1 e ConnectionString2 por enquanto. Você atualizará esses itens mais tarde no laboratório.

  5. Salve as alterações e feche o editor.

  6. No prompt de Cloud Shell, execute o seguinte comando para compilar e executar o aplicativo:

    dotnet run

    Quando o aplicativo é iniciado, ele gera um número de threads, cada um dos threads simulando um usuário. Os threads executam um loop, executando uma série de consultas. Você verá mensagens como as mostradas abaixo começando a aparecer:

    Client 48 : SELECT * FROM purchasing.vendor
Response time: 630 ms

Client 48 : SELECT * FROM sales.specialoffer
Response time: 702 ms

Client 43 : SELECT * FROM purchasing.vendor
Response time: 190 ms

Client 57 : SELECT * FROM sales.salesorderdetail
Client 68 : SELECT * FROM production.vproductanddescription
Response time: 51960 ms

Client 55 : SELECT * FROM production.vproductanddescription
Response time: 160212 ms

Client 59 : SELECT * FROM person.person
Response time: 186026 ms

Response time: 2191 ms

Client 37 : SELECT * FROM person.person
Response time: 168710 ms

    Deixe o aplicativo cliente em execução enquanto você executa a próxima tarefa.

Exibir as métricas

  1. Retorne ao portal do Azure.

  2. No painel esquerdo, selecione Painel.

    Você deve ver o gráfico exibindo as métricas no serviço Banco de Dados do Azure para PostgreSQL.

  3. Selecione o gráfico para abri-lo no painel Métricas.

  4. Permita que o aplicativo seja executado por vários minutos (o mais longo é o melhor). À medida que o tempo passa, as métricas no gráfico devem se parecer com o padrão ilustrado na imagem a seguir:

    Image showing the metrics gathered while the sample app is running

    Este gráfico destaca os seguintes pontos:

    • A CPU está sendo executada com capacidade total; a utilização atinge 100% muito rapidamente.
    • O número de conexões aumenta lentamente. O aplicativo de exemplo foi projetado para iniciar 101 clientes em uma rápida sucessão, mas o servidor só pode lidar com a abertura de algumas conexões de cada vez. O número de conexões adicionadas em cada "etapa" no gráfico está ficando menor e o tempo entre "etapas" está aumentando. Após aproximadamente 45 minutos, o sistema só pôde estabelecer 70 conexões de cliente.
    • A utilização de memória aumenta consistentemente ao longo do tempo.
    • A utilização de E/S está próxima a zero. Todos os dados exigidos pelos aplicativos cliente atualmente são armazenados em cache na memória.

    Se você deixar o aplicativo em execução por tempo suficiente, verá conexões começando a falhar, com as mensagens de erro mostradas na imagem a seguir.

    Image showing the connection errors that can occur when the server has insufficient resources available

  5. No Cloud Shell, pressione ENTER para interromper o aplicativo.

Configurar o servidor para coletar dados de desempenho de consulta

  1. No portal do Azure, na página do servidor do Banco de Dados do Azure para PostgreSQL, em Configurações, selecione Parâmetros do servidor.

  2. Na página Parâmetros do servidor, defina os seguintes parâmetros com os valores especificados na tabela a seguir.

    Parâmetro Valor
    pg_qs.max_query_text_length 6000
    pg_qs.query_capture_mode ALL
    pg_qs.replace_parameter_placeholders ON
    pg_qs.retention_period_in_days 7
    pg_qs.track_utility ON
    pg_stat_statements.track ALL
    pgms_wait_sampling.history_period 100
    pgms_wait_sampling.query_capture_mode ALL

  3. Clique em Salvar.

Examinar as consultas executadas pelo aplicativo usando Repositório de Consultas

  1. Retorne ao Cloud Shell e reinicie o aplicativo de exemplo:

    dotnet run

    Permita que o aplicativo seja executado por 5 minutos ou mais antes de continuar.

  2. Deixe o aplicativo em execução e vá para o portal do Azure

  3. Na página do servidor do Banco de Dados do Azure para PostgreSQL, em Desempenho inteligente, selecione Análise de desempenho de consultas.

  4. Na página Análise de desempenho de consultas, na guia Consultas de execução prolongada, defina o Número de consultas como 10, defina Selecionado em como méd e defina o Período como Últimas 6 horas.

  5. Acima do gráfico, selecione Ampliar (o ícone de lupa com o sinal "+") algumas vezes para se basear nos dados mais recentes.

    Dependendo de quanto tempo você permitiu que o aplicativo seja executado, verá um gráfico semelhante ao mostrado abaixo. O Repositório de Consultas agrega as estatísticas para consultas a cada 15 minutos, de modo que cada barra mostra o tempo relativo consumido por cada consulta em cada período de 15 minutos:

    Image showing the statistics for long running queries captured by using Query Store

  6. Passe o mouse sobre cada barra para exibir as estatísticas das consultas nesse período. As três consultas que o sistema está gastando na maior parte do tempo são:

    SELECT * FROM sales.salesorderdetail
SELECT * FROM sales.salesorderheader
SELECT * FROM person.person

    Essas informações são úteis para um administrador monitorando um sistema. Ter uma percepção das consultas que estão sendo executadas por usuários e aplicativos permite que você entenda as cargas de trabalho que estão sendo executadas e, possivelmente, faça recomendações para os desenvolvedores de aplicativos sobre como eles podem melhorar seu código. Por exemplo, é realmente necessário que um aplicativo recupere todas as 121.000+ linhas da tabela sales.salesorderdetail?

Examine as esperas que ocorrem usando Repositório de Consultas

  1. Selecione a guia Estatísticas de espera.

  2. Defina o Período como Últimas 6 horas, defina Agrupar por como Evento e defina o Número máximo de grupos como 5.

    Assim como acontece com a guia Consultas de execução prolongada, os dados são agregados a cada 15 minutos. A tabela abaixo do gráfico mostra que o sistema tem sido o assunto de dois tipos de evento de espera:

    • Cliente: ClientWrite. Esse evento de espera ocorre quando o servidor está gravando dados (resultados) de volta no cliente. Ele não indica esperas incorridas durante a gravação no banco de dados.
    • Cliente: ClientRead. Esse evento de espera ocorre quando o servidor está aguardando para ler dados (solicitações de consulta ou outros comandos) de um cliente. Ele não está associado ao tempo gasto na leitura do banco de dados.

    Image showing the wait statistics captured by using Query Store

    Observação

    Ler e gravar no banco de dados são indicados por eventos de E/S em vez de eventos de cliente. O aplicativo de exemplo não provoca nenhuma espera de E/S, pois todos os dados exigidos são armazenados em cache na memória após a primeira leitura. Se as métricas mostrarem que a memória estava em execução baixa, você provavelmente verá que eventos de espera de E/S começam a ocorrer.

  3. Retorne ao Cloud Shell e pressione Enter para interromper o aplicativo de exemplo.

Adicionar réplicas ao serviço Banco de Dados do Azure para PostgreSQL

  1. No portal do Azure, na página do servidor do Banco de Dados do Azure para PostgreSQL, em Configurações, selecione Replicação.

  2. Na página Replicação, selecione + Adicionar réplica.

  3. Na página do Servidor PostgreSQL, na caixa Nome do servidor, digite adventureworks [nnn]-replica1 e, em seguida, selecione OK.

  4. Quando a primeira réplica tiver sido criada (levará vários minutos), repita a etapa anterior e adicione outra réplica chamada adventureworks[nnn]-replica2.

  5. Aguarde até que o status de ambas as réplicas seja alterado de Implantando para Disponível antes de continuar.

    Image showing the Replication page for Azure Database for PostgreSQL. Two replicas have been added.

Configurar as réplicas para habilitar o acesso para o cliente

  1. Selecione o nome da réplica adventureworks[nnn]-replica1. Você será levado à página do Banco de Dados do Azure para PostgreSQL nesta réplica.
  2. Em Configurações, selecione Segurança de conexão.
  3. Na página Segurança da conexão, defina Permitir acesso aos serviços do Azure como ATIVADO e selecione Salvar. Essa configuração habilita aplicativos que você executa usando o Cloud Shell para acessar o servidor.
  4. Quando a configuração tiver sido salva, repita as etapas anteriores e permita que os serviços do Azure acessem a réplica adventureworks[nnn]-replica2.

Reiniciar cada servidor

Observação

A configuração da replicação não exige que você reinicie um servidor. A finalidade dessa tarefa é limpar a memória e as conexões estranhas de cada servidor, para que as métricas coletadas ao executar o aplicativo novamente sejam limpas.

  1. Vá para a página do servidor adventureworks[nnn].
  2. Na página Visão Geral, selecione Reiniciar.
  3. Na caixa de diálogo Reiniciar servidor, selecione Sim.
  4. Aguarde o reinício do servidor antes de continuar.
  5. Seguindo o mesmo procedimento, reinicie os servidores adventureworks[nnn]-replica1 e adventureworks[nnn]-replica2.

Reconfigure o aplicativo de exemplo para usar as réplicas

  1. No Cloud Shell, edite o arquivo de App.config.

    code App.config

  2. Adicione as cadeias de conexão para as configurações de ConnectionString1 e ConnectionString2. Esses valores devem ser iguais aos de ConnectionString0, mas com o texto adventureworks[nnn] substituído por adventureworks[nnn]-replica1 e adventureworks[nnn]-replica2 nos elementos Server e ID de usuário.

  3. Defina a configuração NumReplicas como 3.

    O arquivo App.config final deve ser parecido com este:

    <configuration>
    <appSettings>
        <add key="ConnectionString0" value="Server=adventureworks101.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="ConnectionString1" value="Server=adventureworks101-replica1.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101-replica1;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="ConnectionString2" value="Server=adventureworks101-replica2.postgres.database.azure.com;Database=azureadventureworks;Port=5432;User Id=azureuser@adventureworks101-replica2;Password=Pa55w.rd;Ssl Mode=Require;" />
        <add key="NumClients" value="100" />
        <add key="NumReplicas" value="3"/>
    </appSettings>
</configuration>

  4. Salve o arquivo e feche o editor.

  5. Inicie o aplicativo em execução novamente:

    dotnet run

    O aplicativo funcionará como antes. No entanto, desta vez, as solicitações são distribuídas entre os três servidores.

  6. Permita que o aplicativo seja executado por alguns minutos antes de continuar.

Monitore o aplicativo e observe as diferenças nas métricas de desempenho

  1. Deixe o aplicativo em execução e vá para o portal do Azure.

  2. No painel esquerdo, selecione Painel.

  3. Selecione o gráfico para abri-lo no painel Métricas.

    Lembre-se de que este gráfico exibe as métricas do servidor adventureworks*[nnn]*, mas não das réplicas. A carga de cada réplica deve ser muito parecida.

    O gráfico de exemplo ilustra as métricas coletadas para o aplicativo durante um período de 30 minutos, desde a inicialização. O gráfico mostra que a utilização da CPU ainda era alta, mas a utilização da memória era menor. Além disso, após aproximadamente 25 minutos, o sistema estabeleceu conexões para mais de 30 conexões. Isso pode não parecer uma comparação favorável à configuração anterior, que era compatível com 70 conexões após 45 minutos. No entanto, a carga de trabalho agora foi distribuída entre três servidores, que estavam sendo executados no mesmo nível, e todas as 101 conexões foram estabelecidas. Além disso, o sistema conseguiu realizar a execução sem relatar nenhuma falha de conexão.

    Image showing the metrics for the Azure Database for PostgreSQL server while running the application, after replication was configured

    Você pode resolver o problema de utilização da CPU ao escalar verticalmente para um tipo de preço mais alto com mais núcleos de CPU. O sistema de exemplo usado neste laboratório é executado usando o tipo de preço Básico com 2 núcleos. Mudar para o tipo de preço de Uso geral fornecerá até 64 núcleos.

  4. Retorne ao Cloud Shell e pressione Enter para interromper o aplicativo de exemplo.

Agora você viu como monitorar a atividade do servidor usando as ferramentas disponíveis no portal do Azure. Você também aprendeu como configurar a replicação e viu como a criação de réplicas somente leitura pode distribuir a carga de trabalho em cenários de dados com uso intensivo de leitura.