Azure Virtual Machine Scale Sets
Recursos de proceso de Azure que se usan para crear y administrar grupos de máquinas virtuales heterogéneas con equilibrio de carga.
Question - Machine scale set configuration
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(144, 77%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDF%3C/text%3E%3C/svg%3E)
David Fernando Lopez Cueca
60
Puntos de reputación
We have an ARO OpenShift solution where we use machine scale sets for high service availability and cost savings during periods of low operational load. In the PRD cluster, we mapped the machine scale sets so that each worker node was deployed in an availability zone within the region, for example, EastUS 1, EastUS 2, and EastUS 3. However, we have a question because in the DRP cluster, we didn't do it this way. Instead, the worker nodes appear deployed directly in the WestUS region, without the different availability zones. In that case, how complicated would it be to deploy the WestUS worker node machines to each of the availability zones: WestUS 1, WestUS 2, and WestUS 3?
Azure Virtual Machine Scale Sets
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(249.60000000000002, 21%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMD%3C/text%3E%3C/svg%3E)
Manish Deshpande 7,010 Puntos de reputación Personal externo de Microsoft Moderador2026-05-20T18:56:46.83+00:00 Ciao @David Fernando Lopez Cueca
Grazie per aver messo insieme un resoconto così dettagliato, questo è un problema molto comune quando si cerca di collegare l'infrastruttura Azure a piattaforme CMDB come UCMDB. Per essere chiari, non esiste un modo integrato per far sì che VMSS dia sempre alle macchine virtuali sostitutive esattamente lo stesso nome. Azure fa il naming dinamico di proposito, e lo stesso vale per i nodi di lavoro gestiti da ARO, dato che vengono avviati tramite l'OpenShift Machine API sopra VMSS.
Ma non preoccuparti, ci sono alcune soluzioni alternative valide che possono aiutare con il tuo problema di aggiornamento UCMDB, lascia che ti spieghi quelle che dovrebbero funzionare meglio per il tuo setup.
1.Monitora il MachineSet, non le singole VM
Il nome del MachineSet (ad esempio aro-clustername-worker-eastus1) non cambia mai — cambia solo il suffisso dell'istanza. Se UCMDB sta monitorando i nomi delle singole VM come CI, considera di spostare il monitoraggio sul MachineSet o sulla risorsa VMSS come unità logica stabile. I singoli nodi sono effimeri per progettazione cloud-native.
2.Usa i tag delle risorse di Azure come identificatore stabile
Applica un tag di nome logico fisso (ad esempio logicalName = worker-node-01) a ciascuna istanza al momento del provisioning tramite Azure Automation o un'estensione di script personalizzata. Puoi quindi configurare la scoperta UCMDB per basarsi sul valore del tag anziché sul nome della risorsa Azure. I tag sopravvivono alle reimmagini e sono completamente prevedibili.
3.Sincronizzazione automatica di UCMDB tramite Azure Event Grid + Automation
Invece di prevenire le modifiche dei nomi, automatizza l'aggiornamento di UCMDB. Iscriviti agli eventi di scale-out/scale-in delle VMSS tramite Azure Event Grid, avvia un Logic App o un Automation Runbook e chiama l'API REST di UCMDB per creare o ritirare automaticamente i record CI. Questa è la soluzione più robusta a lungo termine — mai aggiornamenti manuali.
4.Modalità di orchestrazione uniforme + riutilizzo degli ID delle istanze
In modalità uniforme, gli ID delle istanze sono numeri decimali che possono essere riutilizzati una volta che una vecchia istanza viene eliminata — quindi una VM sostitutiva può finire con lo stesso nome {vmss-name}_2 del suo predecessore. Questo non è garantito dalla piattaforma, ma nei cluster stabili e con pochi cambiamenti tende ad essere sufficientemente coerente da ridurre significativamente la deriva di UCMDB.
Nota importante su ARO: le risorse VMSS gestite da ARO non devono essere modificate direttamente. Tutto il ridimensionamento deve avvenire tramite oc scale machineset o tramite la console OpenShift — le modifiche dirette a VMSS possono entrare in conflitto con l'operatore ARO.
Documentazione ufficiale
Grazie,
Manish. -
David Fernando Lopez Cueca 60 Puntos de reputación
2026-05-22T20:27:15.8966667+00:00 @Manish Deshpande Nos encontramos atentos a tus validaciones por favor :D
-
Manish Deshpande 7,010 Puntos de reputación Personal externo de Microsoft Moderador
2026-06-01T12:36:37.28+00:00 Hola @David Fernando Lopez Cueca
Solo quería saber si tuviste la oportunidad de revisar mi respuesta que he publicado arriba
Inicie sesión para comentar
Inicie sesión para responder