Compartilhar via


Opções de configuração do mecanismo de otimização do Azure

Este artigo descreve cenários avançados para configurar ou atualizar o AOE (mecanismo de otimização do Azure).


Usando um repositório local

Se você optar por implantar todas as dependências de seu próprio repositório local, deverá publicar os arquivos de solução em uma URL acessível publicamente. Você deve garantir que toda a estrutura do projeto AOE esteja disponível na mesma URL base. Não há suporte para URLs baseadas em token SAS da conta de armazenamento.

.\Deploy-AzureOptimizationEngine.ps1 -TemplateUri <URL to the Bicep file (for example, https://contoso.com/azuredeploy.bicep)> [-AzureEnvironment <AzureUSGovernment|AzureGermanCloud|AzureCloud>]

# Example - Deploying from a public endpoint
.\Deploy-AzureOptimizationEngine.ps1 -TemplateUri "https://contoso.com/azuredeploy.bicep"

# Example 2 - Deploying from a public endpoint, using resource tags
$tags = @{"CostCenter"="FinOps";"Environment"="Production"}
.\Deploy-AzureOptimizationEngine.ps1 -TemplateUri "https://contoso.com/azuredeploy.bicep" -ResourceTags $tags

Implantação silenciosa

Opcionalmente, você também pode usar o parâmetro de entrada SilentDeploymentSettingsPath para implantar o AOE de forma mais automatizada.

A referência do arquivo deve ser um arquivo JSON com os atributos necessários definidos (todos obrigatórios , a menos que especificado).

Um exemplo do conteúdo desse arquivo de implantação silenciosa é:

{
    "SubscriptionId": "<<SubscriptionId>>",
    "NamePrefix": "<<CustomNamePrefix>>", // prefix for all resources. Fill in 'EmptyNamePrefix' to specify the resource names
    "WorkspaceReuse": "n", // y = reuse existing workspace, n = create new workspace
    "ResourceGroupName": "<<CustomName>>-rg", // mandatory if NamePrefix is set to 'EmptyNamePrefix'
    "StorageAccountName": "<<CustomName>>sa", // mandatory if NamePrefix is set to 'EmptyNamePrefix'
    "AutomationAccountName": "<<CustomName>>-auto", // mandatory if NamePrefix is set to 'EmptyNamePrefix'
    "SqlServerName": "<<CustomName>>-sql", // mandatory if NamePrefix is set to 'EmptyNamePrefix'
    "SqlDatabaseName": "<<CustomName>>-db", // mandatory if NamePrefix is set to 'EmptyNamePrefix'
    "WorkspaceName": "<<ExistingName>>", // mandatory if WorkspaceReuse is set to 'n'
    "WorkspaceResourceGroupName": "<<ExistingName>>", // mandatory if workspaceReuse is set to 'n'
    "DeployWorkbooks": "y", // y = deploy the workbooks, n = don't deploy the workbooks
    "TargetLocation": "westeurope",
    "DeployBenefitsUsageDependencies": "y", // deploy the dependencies for the Azure commitments workbooks (EA/MCA customers only + agreement administrator role required)
    "CustomerType": "MCA", // mandatory if DeployBenefitsUsageDependencies is set to 'y', MCA/EA
    "BillingAccountId": "<guid>:<guid>_YYYY-MM-DD", // mandatory if DeployBenefitsUsageDependencies is set to 'y', MCA or EA Billing Account ID
    "BillingProfileId": "ABCD-DEF-GHI-JKL", // mandatory if CustomerType is set to 'MCA"
    "CurrencyCode": "EUR" // mandatory if DeployBenefitsUsageDependencies is set to 'y'
  } 

Ao implantar silenciosamente o AOE, o que normalmente acontece em fluxos de trabalho de implantação contínua automatizados, talvez você queira usar a autenticação do Microsoft Entra para parâmetros SQL do Azure. Por exemplo, para conceder a função de administrador do SQL a um grupo do Microsoft Entra ID com a entidade de serviço de automação de fluxo de trabalho como membro. Veja um exemplo:

.\Deploy-AzureOptimizationEngine.ps1 -SilentDeploymentSettingsPath "<path to deployment settings file>" -SqlAdminPrincipalType Group -SqlAdminPrincipalName "<Group Name>" -SqlAdminPrincipalObjectId "<Group Object GUID>"

Observação

Ao implantar o AOE com identidades que não são de usuário (entidades de serviço), você deve garantir que atribua uma identidade de sistema ao SQL Server AOE e conceda a ele a função Directory Readers no Microsoft Entra ID. Siga as etapas em Entidades de serviço do Microsoft Entra com SQL do Azure.


Ativar planilhas de comprometimentos do Azure

Para usar as Pastas de Trabalho que permitem analisar o uso dos compromissos do Azure (Benefits Usage, Reservations Usagee Savings Plans Usage) ou estimar o efeito de ter outros compromissos de consumo (Benefits Simulation e Reservations Potential), você precisa configurar o AOE e conceder privilégios à sua Identidade Gerenciada no nível do contrato de consumo (EA ou MCA (Contrato de Cliente) da Microsoft). Se você não puder fazer isso durante a instalação/atualização, ainda poderá executar essas etapas de configuração extras, desde que faça isso com um usuário que seja Colaborador no grupo de recursos AOE e tenha privilégios administrativos sobre o contrato de consumo (Administrador de Inscrição Enterprise para EA ou Proprietário do Perfil de Cobrança para MCA). Você só precisa usar o Setup-BenefitsUsageDependencies.ps1 script usando a seguinte sintaxe e responder às solicitações de entrada:

./Setup-BenefitsUsageDependencies.ps1 -AutomationAccountName <AOE automation account> -ResourceGroupName <AOE resource group> [-AzureEnvironment <AzureUSGovernment|AzureGermanCloud|AzureCloud>]

Se você enfrentar problemas com a ingestão da Folha de Preços do Azure (devido ao grande tamanho da exportação do CSV), poderá criar a seguinte variável de Automação do Azure para filtrar as regiões da Folha de Preços: AzureOptimization_PriceSheetMeterRegions defina para as regiões de cobrança de suas máquinas virtuais, separadas por vírgulas. Por exemplo, UE Oeste, UE e Norte.

A Pasta de Trabalho de Uso de Reservas tem alguns blocos "Reservas não utilizadas" que exigem que o AOE exporte dados de Consumo no escopo EA/MCA (em vez do escopo padrão da Assinatura). Você pode alternar para o consumo no escopo EA/MCA criando/atualizando a variável de Automação AzureOptimization_ConsumptionScope com BillingAccount (EA/MCA, exigindo outra função de Leitor de Conta de Cobrança concedida manualmente à identidade gerenciada do AOE) ou BillingProfile (somente MCA) como valor. Essa opção pode gerar uma única exportação de consumo de grande volume, o que pode levar a erros devido à falta de memória (isso, por sua vez, requereria a implementação de AOE com um Hybrid Worker).


Atualizando o AOE

Se você tiver uma versão anterior do AOE e quiser atualizar, é tão simples quanto executar novamente o script de implantação. Use as opções de nomenclatura de recursos escolhidas na implantação inicial. Ele reimplanta o modelo do ARM, adicionando novos recursos e atualizando os existentes.

No entanto, se você personalizou anteriormente componentes, como variáveis de automação ou agendamentos, melhorou o desempenho da execução do trabalho com Hybrid Workers ou fortaleceu a solução com o Link Privado, execute o script de implantação com o DoPartialUpgrade switch, por exemplo:

.\Deploy-AzureOptimizationEngine.ps1 -DoPartialUpgrade

Com a opção DoPartialUpgrade, a implantação apenas:

  • Adicionar novos recipientes de armazenamento
  • Atualizar/adicionar runbooks de Automação
  • Atualizar/adicionar módulos de automação
  • Adicionar novos agendamentos de automação
  • Adicionar novas variáveis de automação
  • Atualizar o modelo de banco de dados SQL
  • Atualizar pastas de trabalho do Log Analytics

Alguns clientes também podem personalizar a implantação do SQL Server, por exemplo, migrando do Banco de Dados SQL para uma Instância Gerenciada de SQL. Não há ferramentas disponíveis para ajudar na migração, mas, depois que a migração do banco de dados for concluída manualmente, o script de atualização do AOE dará suporte a futuras atualizações DoPartialUpgrade com a opção IgnoreNamingAvailabilityErrors ativada (ignora a validação de nomeação/existência do SQL Server).


Recursos FinOps relacionados:

Produtos relacionados:

Soluções relacionadas: