Compartir a través de

Opciones de configuración del motor de optimización de Azure

En este artículo se describen los escenarios avanzados para configurar o actualizar el motor de optimización de Azure (AOE).


Uso de un repositorio local

Si decide implementar todas las dependencias desde su propio repositorio local, debe publicar los archivos de solución en una dirección URL accesible públicamente. Debe asegurarse de que toda la estructura del proyecto de AOE esté disponible en la misma dirección URL base. No se admiten las direcciones URL basadas en tokens de SAS de la cuenta de almacenamiento.

.\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

Implementación silenciosa

Opcionalmente, también puede usar el SilentDeploymentSettingsPath parámetro de entrada para implementar AOE de forma más automatizada.

El archivo que hace referencia debe ser un archivo JSON con los atributos necesarios definidos (todos obligatorios a menos que se especifique).

Un ejemplo del contenido de este archivo de implementación silenciosa es:

{
    "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'
  }

Al implementar AOE de forma silenciosa, lo que suele ocurrir en flujos de trabajo de implementación continua automatizados, es posible que desee usar la autenticación de Microsoft Entra para los parámetros de Azure SQL. Por ejemplo, para conceder el rol de administrador de SQL a un grupo de Microsoft Entra ID que tenga como miembro a la entidad de servicio de automatización del flujo de trabajo. Este es un ejemplo:

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

Nota:

Al implementar AOE con identidades que no son de usuario (entidades de servicio), debe asegurarse de asignar una identidad del sistema al AOE de SQL Server y concederle el rol Directory Readers en Microsoft Entra ID. Siga los pasos descritos en Entidades de servicio de Microsoft Entra con Azure SQL.


Habilitar libros de compromisos de Azure

Para usar los libros de trabajo que le permiten analizar el uso de los compromisos de Azure (Benefits Usage, Reservations Usage y Savings Plans Usage) o estimar el efecto de tener otros compromisos de consumo (Benefits Simulation y Reservations Potential), debe configurar AOE y conceder privilegios a su identidad administrada en el nivel de contrato de consumo (EA o Contrato de cliente de Microsoft (MCA)). Si no pudo hacerlo durante la instalación o actualización, puede seguir ejecutando esos pasos de configuración adicionales, siempre que lo haga con un usuario que sea Colaborador en el grupo de recursos de AOE y tenga privilegios administrativos sobre el contrato de consumo (Administrador de inscripción empresarial para EA o Propietario del perfil de facturación para MCA). Solo tiene que usar el Setup-BenefitsUsageDependencies.ps1 script mediante la sintaxis siguiente y responder a las solicitudes de entrada:

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

Si tiene problemas con la ingesta de la hoja de precios de Azure (debido al gran tamaño de la exportación de CSV), puede crear la siguiente variable de Azure Automation para filtrar en las regiones de la hoja de precios: AzureOptimization_PriceSheetMeterRegions establecido en las regiones de facturación, separadas por comas, para las máquinas virtuales. Por ejemplo, Oeste de la UE, UE y Norte.

El libro de trabajo de uso de reservas tiene un par de paneles de "Reservas sin usar" que requieren AOE para exportar datos de consumo en el ámbito EA/MCA (en lugar del ámbito de suscripción predeterminado). Puede cambiar al consumo de ámbito de EA/MCA mediante la creación o actualización de la variable de automatización AzureOptimization_ConsumptionScope con BillingAccount (EA/MCA, que requiere que se conceda manualmente otro rol de Lector de cuentas de facturación a la identidad administrada de AOE) o BillingProfile (solo MCA) como valor. Esta opción puede generar una exportación única de gran consumo que podría provocar errores debido a la falta de memoria (a su vez requeriría la implementación de AOE con un trabajador híbrido).


Actualización de AOE

Si tiene una versión anterior de AOE y quiere actualizarla, es tan simple como volver a ejecutar el script de implementación. Use las opciones de nomenclatura de recursos que eligió en la implementación inicial. Vuelve a implementar la plantilla de ARM, agregando nuevos recursos y actualizando los existentes.

Sin embargo, si anteriormente personalizó componentes como variables o programaciones de Automation, mejoró el rendimiento de la ejecución de trabajos con Hybrid Workers o protegió la solución con Private Link, debe ejecutar el script de implementación con el conmutador DoPartialUpgrade, por ejemplo:

.\Deploy-AzureOptimizationEngine.ps1 -DoPartialUpgrade

Con el DoPartialUpgrade conmutador, la implementación se limitará a:

  • Adición de nuevos contenedores de almacenamiento
  • Actualizar o agregar runbooks de Automation
  • Actualizar o agregar módulos de Automatización
  • Adición de nuevas programaciones de Automation
  • Añadir nuevas variables de Automatización
  • Actualización del modelo de base de datos SQL
  • Actualizar cuadernos de Log Analytics

Algunos clientes también pueden personalizar la implementación de SQL Server, por ejemplo, migrar de SQL Database a una instancia administrada de SQL. No hay herramientas disponibles para ayudar con la migración, pero, una vez que la migración de la base de datos se realiza manualmente, el script de actualización de AOE admite futuras actualizaciones con el conmutador IgnoreNamingAvailabilityErrors activado (omite la validación de nomenclatura o existencia de SQL Server).


Contenido relacionado

Funcionalidades relacionadas de FinOps:

Productos relacionados:

Soluciones relacionadas: