Compartilhar via

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

  • Artigo

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 (e.g., 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 input para implantar o SilentDeploymentSettingsPath AOE de maneira 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 de ID do Microsoft Entra 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 de não usuário (entidades de serviço), você deve atribuir uma identidade do sistema ao AOE SQL Server e conceder a ele a Directory Readers função na ID do Microsoft Entra. Siga as etapas em Entidades de serviço do Microsoft Entra com o SQL do Azure.


Habilitar pastas de trabalho de compromissos 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ê tiver problemas com a ingestão da Folha 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 nas regiões da Tabela de Preços: AzureOptimization_PriceSheetMeterRegions Defina como as regiões de cobrança 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 de "Reservas Não Utilizadas" que exigem AOE para exportar dados de Consumo no escopo do EA/MCA (em vez do escopo de Assinatura padrão). Você pode alternar para o consumo de escopo do EA/MCA criando/atualizando a AzureOptimization_ConsumptionScope variável de automação com BillingAccount (EA/MCA, exigindo outra função de leitor da conta de faturamento concedida manualmente à identidade gerenciada AOE) ou BillingProfile (somente MCA) como valor. Essa opção pode gerar uma grande exportação de consumo único que pode levar a erros devido à falta de memória (por sua vez, exigiria a implantação de AOE com um Hybrid Worker).


Atualizando 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 o DoPartialUpgrade switch, a implantação só irá:

  • 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 é feita manualmente, o script de atualização AOE dá suporte a atualizações futuras DoPartialUpgrade com a opção ativada (ignora a IgnoreNamingAvailabilityErrors validação de nomenclatura/existência do SQL Server).


Conteúdo relacionado

Recursos FinOps relacionados:

Produtos relacionados:

Soluções relacionadas: