Operações de manutenção do provedor de recursos do MySQL no Azure Stack Hub

Importante

A partir do build 2108 do Azure Stack Hub, os provedores de recursos SQL e MySQL são oferecidos a assinaturas que receberam acesso. Se você quiser começar a usar esse recurso ou se precisar atualizar de uma versão anterior, abra um caso de suporte e nossos engenheiros de suporte orientarão você pelo processo de implantação ou atualização.

O provedor de recursos MySQL é executado em uma VM (máquina virtual) bloqueada. Para habilitar as operações de manutenção, você precisa atualizar a segurança da VM. Para fazer isso usando o princípio de privilégios mínimos (POLP), você pode usar o ponto de extremidade JEA (Administração Just Enough) do PowerShell DBAdapterMaintenance. O pacote de instalação do provedor de recursos inclui um script para essa operação.

Aplicando patch e atualizando

O provedor de recursos MySQL não é atendido como parte do Azure Stack Hub porque é um componente de complemento. A Microsoft fornece atualizações para o provedor de recursos MySQL conforme necessário.

Para o MySQL RP V1, quando um provedor de recursos do MySQL Server atualizado é lançado, um script é fornecido para aplicar a atualização. Esse script cria uma nova VM do provedor de recursos, migrando o estado da VM do provedor antiga para a nova VM.

Para o MySQL RP V2, os provedores de recursos são atualizados usando o mesmo recurso de atualização usado para aplicar atualizações do Azure Stack Hub.

Para obter mais informações, consulte Atualizar o provedor de recursos MySQL.

Atualizar a VM do provedor

MySQL RP V1 é executado em uma VM de usuário , você precisa aplicar os patches e atualizações necessários quando eles forem lançados. Você pode instalar um pacote Windows Update durante a instalação ou atualizar para o provedor de recursos.

O MySQL RP V2 é executado em um Windows Server gerenciado que está oculto. Você não precisa corrigir ou atualizar a VM do provedor de recursos. Ele será atualizado automaticamente quando você atualizar o RP.

Atualizar as definições de Windows Defender da VM

Essas instruções se aplicam somente ao SQL RP V1 em execução nos Sistemas Integrados do Azure Stack Hub.

Para atualizar as definições do Defender, siga estas etapas:

  1. Baixe a atualização de definições de Windows Defender de definição de Windows Defender.

    Na página de definições, role para baixo até "Baixar e instalar manualmente as definições". Baixe o arquivo de 64 bits "Windows Defender Antivírus para Windows 10 e Windows 8.1".

    Como alternativa, use esse link direto para baixar/executar o arquivo fpam-fe.exe.

  2. Abra uma sessão do PowerShell para o ponto de extremidade de manutenção da VM do adaptador de provedor de recursos mySQL.

  3. Copie o arquivo de atualização de definições para a VM do adaptador do provedor de recursos usando a sessão do ponto de extremidade de manutenção.

  4. Na sessão do PowerShell de manutenção, execute o comando Update-DBAdapterWindowsDefenderDefinitions .

  5. Depois de instalar as definições, recomendamos que você exclua o arquivo de atualização de definições usando o comando Remove-ItemOnUserDrive ).

Exemplo de script do PowerShell para atualizar definições.

Você pode editar e executar o script a seguir para atualizar as definições do Defender. Substitua valores no script por valores do seu ambiente.

# Set credentials for the local admin on the resource provider VM.
$vmLocalAdminPass = ConvertTo-SecureString '<local admin user password>' -AsPlainText -Force
$vmLocalAdminUser = "<local admin user name>"
$vmLocalAdminCreds = New-Object System.Management.Automation.PSCredential `
    ($vmLocalAdminUser, $vmLocalAdminPass)

# Provide the public IP address for the adapter VM.
$databaseRPMachine  = "<RP VM IP address>"
$localPathToDefenderUpdate = "C:\DefenderUpdates\mpam-fe.exe"

# Download Windows Defender update definitions file from https://www.microsoft.com/en-us/wdsi/definitions.  
Invoke-WebRequest -Uri 'https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64' `
    -Outfile $localPathToDefenderUpdate  

# Create a session to the maintenance endpoint.
$session = New-PSSession -ComputerName $databaseRPMachine `
    -Credential $vmLocalAdminCreds -ConfigurationName DBAdapterMaintenance `
    -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)

# Copy the defender update file to the adapter VM.
Copy-Item -ToSession $session -Path $localPathToDefenderUpdate `
     -Destination "User:\"

# Install the update definitions.
Invoke-Command -Session $session -ScriptBlock `
    {Update-AzSDBAdapterWindowsDefenderDefinition -DefinitionsUpdatePackageFile "User:\mpam-fe.exe"}

# Cleanup the definitions package file and session.
Invoke-Command -Session $session -ScriptBlock `
    {Remove-AzSItemOnUserDrive -ItemPath "User:\mpam-fe.exe"}
$session | Remove-PSSession

Configurar Diagnóstico do Azure extensão para o provedor de recursos MySQL

Essas instruções se aplicam somente ao SQL RP V1 em execução nos Sistemas Integrados do Azure Stack Hub.

A extensão Diagnóstico do Azure é instalada na VM do adaptador do provedor de recursos MySQL por padrão. As etapas a seguir mostram como personalizar a extensão para coletar os logs de eventos operacionais do provedor de recursos do MySQL e os logs do IIS para fins de solução de problemas e auditoria.

  1. Entre no portal do administrador do Azure Stack Hub.

  2. Selecione Máquinas virtuais no painel à esquerda, pesquise a VM do adaptador do provedor de recursos MySQL e selecione a VM.

  3. Nas configurações de diagnóstico da VM, vá para a guia Logs e escolha Personalizado para personalizar os logs de eventos que estão sendo coletados.

    Ir para diagnóstico configurações

  4. Adicione Microsoft-AzureStack-DatabaseAdapter/Operational!* para coletar logs de eventos operacionais do provedor de recursos MySQL.

    Adicionar logs de eventos

  5. Para habilitar a coleção de logs do IIS, marcar logs do IIS e logs de solicitação com falha.

    Adicionar logs do IIS

  6. Por fim, selecione Salvar para salvar todas as configurações de diagnóstico.

Depois que os logs de eventos e a coleção de logs do IIS forem configurados para o provedor de recursos MySQL, os logs poderão ser encontrados em uma conta de armazenamento do sistema chamada mysqladapterdiagaccount.

Para saber mais sobre a extensão Diagnóstico do Azure, consulte O que é Diagnóstico do Azure extensão.

Rotação de segredos

Essas instruções se aplicam somente aos Sistemas Integrados do Azure Stack Hub.

Ao usar os provedores de recursos SQL e MySQL com sistemas integrados do Azure Stack Hub, o operador do Azure Stack Hub é responsável por girar os seguintes segredos de infraestrutura do provedor de recursos para garantir que eles não expirem:

  • Certificado SSL externo fornecido durante a implantação.
  • A senha da conta de administrador local da VM do provedor de recursos fornecida durante a implantação.
  • Senha do usuário de diagnóstico do provedor de recursos (dbadapterdiag).
  • (versão >= 1.1.47.0) Key Vault certificado gerado durante a implantação.

Exemplos do PowerShell para girar segredos

Altere todos os segredos ao mesmo tempo:

.\SecretRotationMySQLProvider.ps1 `
    -Privilegedendpoint $Privilegedendpoint `
    -CloudAdminCredential $cloudCreds `
    -AzCredential $adminCreds `
    -DiagnosticsUserPassword $passwd `
    -DependencyFilesLocalPath $certPath `
    -DefaultSSLCertificatePassword $certPasswd `  
    -VMLocalCredential $localCreds `
    -KeyVaultPfxPassword $keyvaultCertPasswd

Altere a senha do usuário de diagnóstico:

.\SecretRotationMySQLProvider.ps1 `
    -Privilegedendpoint $Privilegedendpoint `
    -CloudAdminCredential $cloudCreds `
    -AzCredential $adminCreds `
    -DiagnosticsUserPassword  $passwd

Altere a senha da conta de administrador local da VM:

.\SecretRotationMySQLProvider.ps1 `
    -Privilegedendpoint $Privilegedendpoint `
    -CloudAdminCredential $cloudCreds `
    -AzCredential $adminCreds `
    -VMLocalCredential $localCreds

Girar o certificado SSL

.\SecretRotationMySQLProvider.ps1 `
    -Privilegedendpoint $Privilegedendpoint `
    -CloudAdminCredential $cloudCreds `
    -AzCredential $adminCreds `
    -DependencyFilesLocalPath $certPath `
    -DefaultSSLCertificatePassword $certPasswd

Girar o certificado Key Vault

.\SecretRotationSQLProvider.ps1 `
    -Privilegedendpoint $Privilegedendpoint `
    -CloudAdminCredential $cloudCreds `
    -AzCredential $adminCreds `
    -KeyVaultPfxPassword $keyvaultCertPasswd

parâmetros de SecretRotationMySQLProvider.ps1

Parâmetro Descrição Comentário
AzureEnvironment O ambiente do Azure da conta de administrador de serviço usada para implantar o Azure Stack Hub. Necessário apenas para implantações de Microsoft Entra. Os nomes de ambiente com suporte são AzureCloud, AzureUSGovernment ou se estiver usando uma ID de Microsoft Entra da China, AzureChinaCloud. Opcional
AzCredential Credencial de conta de administrador de serviço do Azure Stack Hub. O script falhará se a conta usada com o AzCredential exigir MFA (autenticação multifator). Obrigatório
CloudAdminCredential Credencial de conta de domínio de administrador de nuvem do Azure Stack Hub. Obrigatório
PrivilegedEndpoint Ponto de extremidade privilegiado para acessar Get-AzureStackStampInformation. Obrigatório
DiagnosticsUserPassword Senha da conta de usuário de diagnóstico. Opcional
VMLocalCredential A conta de administrador local na VM MySQLAdapter. Opcional
DefaultSSLCertificatePassword Senha padrão do Certificado SSL (*.pfx). Opcional
DependencyFilesLocalPath Caminho local dos arquivos de dependência. Opcional
KeyVaultPfxPassword A senha usada para gerar o certificado Key Vault para o adaptador de banco de dados. Opcional

Essas instruções se aplicam somente ao MySQL RP V2 em execução nos Sistemas Integrados do Azure Stack Hub.

Observação

Atualmente, a rotação de segredos para provedores de recursos de adição de valor (RPs) só tem suporte por meio do PowerShell.

Assim como a infraestrutura do Azure Stack Hub, os provedores de recursos de valor agregado usam segredos internos e externos. Como operador, você é responsável por:

  • Fornecer segredos externos atualizados, como um novo certificado TLS usado para proteger os pontos de extremidade do provedor de recursos.

  • Gerenciando a rotação de segredo do provedor de recursos regularmente.

Quando os segredos estão se aproximando da expiração, os alertas a seguir são gerados no portal do administrador. Concluir a rotação de segredo resolverá estes alertas:

  • Validade pendente do certificado interno

  • Validade pendente do certificado externo

Pré-requisitos

Em preparação para o processo de alternância:

  1. Se ainda não o fez, instale o módulo do Azure PowerShell para Azure Stack Hub antes de continuar. A versão 2.0.2 prévia ou posterior é necessária para a alternância de segredos do Azure Stack Hub. Para obter mais informações, confira Migrar do AzureRM para o Azure PowerShell no Azure Stack Hub.

  2. Instale a Azs.Deployment. Administração módulos 1.0.0: Galeria do PowerShell | Azs.Deployment. Administração 1.0.0

Install-Module -Name Azs.Deployment.Admin
  1. Se o certificado externo estiver se aproximando da expiração, examine os requisitos de certificado PKI (infraestrutura de chave pública) do Azure Stack Hub para obter informações importantes de pré-requisito antes de adquirir/renovar seu certificado X509, incluindo detalhes sobre o formato PFX necessário. Revise também os requisitos especificados na seção de certificados PaaS opcionais, para seu provedor de recursos de valor agregado específico.

Preparar um novo certificado TLS para rotação de certificado externo

Observação

Se apenas o certificado interno estiver se aproximando da expiração, você poderá ignorar esta seção.

Em seguida, crie ou renove seu certificado TLS para proteger os pontos de extremidade do provedor de recursos de valor agregado:

  1. Conclua as etapas em Gerar solicitações de assinatura de certificado (CSRs) para renovação de certificado para seu provedor de recursos. Aqui, você usa a ferramenta Verificador de Prontidão do Azure Stack Hub para criar o CSR. Certifique-se de executar o cmdlet correto para o seu provedor de recursos, na etapa "Gerar solicitações de certificado para outros serviços do Azure Stack Hub". Por exemplo New-AzsDbAdapterCertificateSigningRequest , é usado para RPs SQL e MySQL. Quando terminar, você enviará o gerado. Arquivo REQ para a AC (Autoridade de Certificação) para o novo certificado.

  2. Depois de receber o arquivo de certificado da CA, conclua as etapas em Preparar certificados para implantação ou alternância. Use a ferramenta Verificador de Prontidão novamente para processar o arquivo retornado da CA.

  3. Por fim, conclua as etapas em Validar certificados PKI do Azure Stack Hub. Use a ferramenta Verificador de Prontidão mais uma vez para executar testes de validação em seu novo certificado.

Girar o certificado interno

Abra um console do PowerShell com privilégios elevados e conclua as seguintes etapas para girar os segredos externos do provedor de recursos:

  1. Entre em seu ambiente do Azure Stack Hub usando suas credenciais de operador. Confira Conectar-se ao Azure Stack Hub com o script de entrada do PowerShell para PowerShell. Use os cmdlets do Azure PowerShell Az (em vez de AzureRM) e substitua todos os valores de espaço reservado, como URLs de ponto de extremidade e nome do locatário do diretório.

  2. Determine a ID do produto do provedor de recursos. Execute o cmdlet Get-AzsProductDeployment para recuperar uma lista das implantações mais recentes do provedor de recursos. A coleção "value" retornada contém um elemento para cada provedor de recursos implantado. Encontre o provedor de recursos de interesse e anote os valores dessas propriedades:

    • "name" – contém a ID do produto do provedor de recursos no segundo segmento do valor.

    Por exemplo, a implantação de RP do MySQL pode ter uma ID do produto de "microsoft.mysqlrp".

  3. Execute o Invoke-AzsProductRotateSecretsAction cmdlet para girar o certificado interno:

    Invoke-AzsProductRotateSecretsAction -ProductId $productId
    

Girar o certificado externo

Primeiro, você precisa anotar os valores para os parâmetros a seguir.

Espaço reservado Descrição Valor de exemplo
<product-id> A ID do produto da implantação mais recente do provedor de recursos. microsoft.mysqlrp
<installed-version> A versão da implantação mais recente do provedor de recursos. 2.0.0.2
<package-id> A ID do pacote é criada concatenando a ID do produto e a versão instalada. microsoft.mysqlrp.2.0.0.2
<cert-secret-name> O nome sob o qual o segredo do certificado é armazenado. SSLCert
<cert-pfx-file-path> O caminho para o arquivo PFX do certificado. C:\dir\dbadapter-cert-file.pfx
<pfx-password> A senha atribuída ao seu certificado . Arquivo PFX. strong@CertSecret6

Abra um console do PowerShell com privilégios elevados e conclua as seguintes etapas:

  1. Entre em seu ambiente do Azure Stack Hub usando suas credenciais de operador. Confira Conectar-se ao Azure Stack Hub com o script de entrada do PowerShell para PowerShell. Use os cmdlets do Azure PowerShell Az (em vez de AzureRM) e substitua todos os valores de espaço reservado, como URLs de ponto de extremidade e nome do locatário do diretório.

  2. Obtenha o valor do parâmetro product-id. Execute o cmdlet Get-AzsProductDeployment para recuperar uma lista das implantações mais recentes do provedor de recursos. A coleção "value" retornada contém um elemento para cada provedor de recursos implantado. Encontre o provedor de recursos de interesse e anote os valores dessas propriedades:

    • "name" – contém a ID do produto do provedor de recursos no segundo segmento do valor.
    • "properties"."deployment"."version" – contém o número da versão atualmente implantada.

    Por exemplo, a implantação de RP do MySQL pode ter uma ID do produto e a "microsoft.mysqlrp"versão "2.0.0.2".

  3. Crie a ID do pacote do provedor de recursos concatenando a ID do produto e a versão do provedor de recursos. Por exemplo, usando os valores derivados na etapa anterior, a ID do pacote DE RP do SQL é microsoft.mysqlrp.2.0.0.2.

  4. Usando a ID do pacote derivada na etapa anterior, execute Get-AzsProductSecret -PackageId para recuperar a lista de tipos de segredo que estão sendo usados pelo provedor de recursos. Na coleção value retornada, encontre o elemento que contém um valor de "Certificate" para a propriedade "properties"."secretKind". Esse elemento contém propriedades para o segredo do certificado do provedor de recursos. Anote o nome atribuído a este segredo de certificado, que é identificado pelo último segmento da propriedade "name", logo acima de "properties".

    Por exemplo, a coleção de segredos retornada para o RP do SQL contém um "Certificate" segredo chamado SSLCert.

  5. Use o cmdlet Set-AzsProductSecret para importar seu novo certificado para Key Vault, que será usado pelo processo de alternância. Substitua os valores de espaço reservado da variável adequadamente antes de executar o script.

    $productId = '<product-id>'
    $packageId = $productId + '.' + '<installed-version>'
    $certSecretName = '<cert-secret-name>' 
    $pfxFilePath = '<cert-pfx-file-path>'
    $pfxPassword = ConvertTo-SecureString '<pfx-password>' -AsPlainText -Force   
    Set-AzsProductSecret -PackageId $packageId -SecretName $certSecretName -PfxFileName $pfxFilePath -PfxPassword $pfxPassword -Force
    
  6. Por fim, use o Invoke-AzsProductRotateSecretsAction cmdlet para girar os segredos:

    Invoke-AzsProductRotateSecretsAction -ProductId $productId
    

Monitorar o progresso da rotação de segredo

Você pode monitorar o progresso da alternância de segredos no console do PowerShell ou no portal do administrador, selecionando o provedor de recursos no serviço do Marketplace:

Tela de rotação de segredo em andamento.

Observação

O tempo de rotação do segredo pode custar mais de 10 minutos. Depois de concluído, o Status do provedor de recursos será alterado para "Instalado".

Coletar logs de diagnóstico

O Azure Stack Hub tem várias maneiras de coletar, salvar e enviar logs de diagnóstico para Suporte da Microsoft. A partir da versão 1.1.93, o Provedor de Recursos do MySQL dá suporte à maneira padrão de coletar logs do ambiente do Azure Stack Hub. Para obter mais informações, consulte Coleção de logs de diagnóstico.

A partir da versão 1.1.93, o Provedor de Recursos do MySQL dá suporte à maneira padrão de coletar logs do ambiente do Azure Stack Hub. Se você estiver usando uma versão mais antiga, é recomendável atualizar o Provedor de Recursos do MySQL para a versão mais recente.

Para coletar logs da VM bloqueada, use o ponto de extremidade JEA (Administração Just Enough) do PowerShell DBAdapterDiagnostics. Esse ponto de extremidade fornece os seguintes comandos:

  • Get-AzsDBAdapterLog. Esse comando cria um pacote zip do provedor de recursos diagnóstico logs e salva o arquivo na unidade de usuário da sessão. Você pode executar esse comando sem parâmetros e as últimas quatro horas de logs são coletadas.

  • Remove-AzsDBAdapterLog. Esse comando remove os pacotes de log existentes na VM do provedor de recursos.

Requisitos e processo de ponto de extremidade

Quando um provedor de recursos é instalado ou atualizado, a conta de usuário dbadapterdiag é criada. Você usará essa conta para coletar logs de diagnóstico.

Observação

A senha da conta dbadapterdiag é a mesma usada para o administrador local na VM criada durante uma implantação ou atualização do provedor.

Para usar os comandos DBAdapterDiagnostics , crie uma sessão remota do PowerShell para a VM do provedor de recursos e execute o comando Get-AzsDBAdapterLog .

Você define o intervalo de tempo para a coleção de logs usando os parâmetros FromDate e ToDate . Se você não especificar um ou ambos os parâmetros, os seguintes padrões serão usados:

  • FromDate é quatro horas antes da hora atual.
  • ToDate é a hora atual.

Exemplo de script do PowerShell para coletar logs:

O script a seguir mostra como coletar logs de diagnóstico da VM do provedor de recursos.

# Create a new diagnostics endpoint session.
$databaseRPMachineIP = '<RP VM IP address>'
$diagnosticsUserName = 'dbadapterdiag'
$diagnosticsUserPassword = '<Enter Diagnostic password>'
$diagCreds = New-Object System.Management.Automation.PSCredential `
        ($diagnosticsUserName, (ConvertTo-SecureString -String $diagnosticsUserPassword -AsPlainText -Force))
$session = New-PSSession -ComputerName $databaseRPMachineIP -Credential $diagCreds `
        -ConfigurationName DBAdapterDiagnostics -SessionOption (New-PSSessionOption -Culture en-US -UICulture en-US)

# Sample that captures logs from the previous hour.
$fromDate = (Get-Date).AddHours(-1)
$dateNow = Get-Date
$sb = {param($d1,$d2) Get-AzSDBAdapterLog -FromDate $d1 -ToDate $d2}
$logs = Invoke-Command -Session $session -ScriptBlock $sb -ArgumentList $fromDate,$dateNow

# Copy the logs to the user drive.
$sourcePath = "User:\{0}" -f $logs
$destinationPackage = Join-Path -Path (Convert-Path '.') -ChildPath $logs
Copy-Item -FromSession $session -Path $sourcePath -Destination $destinationPackage

# Cleanup the logs.
$cleanup = Invoke-Command -Session $session -ScriptBlock {Remove-AzsDBAdapterLog}
# Close the session.
$session | Remove-PSSession

Limitações conhecidas do provedor de recursos do MySQL Server versão 1

Limitação:
Quando o script de implantação, atualização ou rotação de segredo falhou, alguns logs não podem ser coletados pelo mecanismo de coleta de log padrão.

Solução alternativa:
Além de usar o mecanismo de coleta de logs padrão, vá para a pasta Logs na pasta extraída onde o script é localizado, para encontrar mais logs.

Próximas etapas

Adicionar servidores de hospedagem do MySQL Server