Partilhar 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 mecanismo de otimização do Azure (AOE).


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 tokens 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, 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, convém usar a autenticação do Microsoft Entra para parâmetros SQL do Azure. Por exemplo, para conceder a função de administrador SQL a um grupo do Microsoft Entra ID que tenha o principal de serviço de automação de fluxo de trabalho como membro. Eis um exemplo:

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

Nota

Ao implantar o AOE com identidades que não sejam de usuário (principais de serviço), deve garantir que atribui uma identidade do sistema ao AOE SQL Server e, em seguida, conceder-lhe a Directory Readers função no Microsoft Entra ID. Siga as etapas em Principais de serviço do Microsoft Entra com o Azure SQL.


Ativar cadernos de compromissos do Azure

Para usar as Pastas de Trabalho que permitem analisar o uso de seus 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 Microsoft Customer Agreement (MCA)). Se você não puder fazer isso durante a instalação/atualização, ainda poderá executar essas etapas de configuração extras, desde que o faça 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 Empresarial para EA ou Proprietário de 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ê tiver problemas com a ingestão da planilha de preços do Azure (devido ao grande tamanho da exportação do CVS), poderá criar a seguinte variável de Automação do Azure, para filtrar as regiões da Planilha de Preços: AzureOptimization_PriceSheetMeterRegions definido como as regiões de faturamento separadas por vírgulas de suas máquinas virtuais. 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 a AOE exporte dados de Consumo no escopo EA/MCA (em vez do escopo Assinatura padrão). Você pode alternar para o consumo de escopo EA/MCA criando/atualizando a variável de Automação com AzureOptimization_ConsumptionScope (EA/MCA, exigindo um papel adicional de Leitor de Conta de Cobrança atribuído manualmente à identidade gerida do AOE) ou BillingAccount (somente MCA) como valor. Esta opção pode gerar uma exportação de elevado consumo isolado, o que pode levar a erros por falta de memória (o que exigirá a implantação do AOE com um trabalhador híbrido).


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 ARM, adicionando novos recursos e atualizando os existentes.

No entanto, se você personalizou anteriormente componentes, como variáveis ou agendas de automação, melhorou o desempenho de execução de tarefas com Hybrid Workers ou fortaleceu a solução com Private Link, então você deve executar o script de implantação com o DoPartialUpgrade switch, por exemplo:

.\Deploy-AzureOptimizationEngine.ps1 -DoPartialUpgrade

Com o DoPartialUpgrade comutador, a implantação vai apenas:

  • Adicionar novos recipientes de armazenamento
  • Atualizar/adicionar runbooks de automação
  • Atualizar/adicionar módulos de automação
  • Adicionar novas agendas 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 do SQL. Não há ferramentas para ajudar na migração, mas, uma vez feita manualmente a migração do banco de dados, o script de atualização do AOE suporta futuras atualizações DoPartialUpgrade com a opção IgnoreNamingAvailabilityErrors ativada (ignora a validação de nomenclatura/existência do SQL Server).


Conteúdos relacionados

Recursos de FinOps relacionados:

Produtos relacionados:

Soluções relacionadas:


  • Last updated on