Partilhar 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 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 (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 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 de ID do Microsoft Entra que tenha a entidade de serviço de automação do 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 (entidades de serviço), você deve garantir atribuir uma identidade do sistema ao AOE SQL Server e conceder-lhe a Directory Readers função no Microsoft Entra ID. Siga as etapas em Entidades de serviço do Microsoft Entra com o Azure SQL.


Habilitar pastas de trabalho 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 AzureOptimization_ConsumptionScope variável Automação 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 grande exportação de consumo único que pode levar a erros devido à falta de memória (por sua vez, exigiria 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 switch, a implantação irá:

  • 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 disponíveis para ajudar na migração, mas uma vez que a migração do banco de dados é feita manualmente, o script de atualização do AOE oferece suporte a atualizações futuras DoPartialUpgrade com a opção ativada (ignora a IgnoreNamingAvailabilityErrors validação de nomenclatura/existência do SQL Server).


Conteúdos relacionados

Recursos de FinOps relacionados:

Produtos relacionados:

Soluções relacionadas: