El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

La lliçó anterior va acabar amb un diagnòstic incòmode: vm-motor-disponibilidad-dev funciona, però és una sola màquina. Si l'amfitrió físic falla, si Azure aplica manteniment a la plataforma o si el trànsit es multiplica per deu, no hi ha pla B. I a Contoso Airlines li passarà la tercera cosa amb data marcada al calendari.

Cada any, a mitjan febrer, Contoso obre la venda de la temporada d'estiu. El primer dia s'hi concentra al voltant del 60 % del trànsit del mes, amb un pic de tres hores al matí en què l'API de Disponibilitat rep unes quinze vegades les peticions d'un dia normal. Amb servidors propis a Barcelona i Palma, la resposta històrica va ser comprar maquinari per al pic i tenir-lo al 6 % d'ús els altres 364 dies. Aquest és, literalment, el problema que el núvol resol.

En aquesta lliçó aprendràs a escalar el còmput i a donar-li alta disponibilitat: quina diferència hi ha entre créixer cap amunt i créixer cap als costats, com funcionen els conjunts d'escalat de màquines virtuals, com es reparteixen les instàncies entre zones de disponibilitat, quin balancejador triar entre els quatre que ofereix Azure, i quin requisit de disseny imposa tot això a la teva aplicació: no tenir estat.

Avís de cost: un conjunt d'escalat amb dues instàncies factura dues VM, i un Load Balancer Standard té cost per hora i per regles. Tot el d'aquesta lliçó s'elimina al final amb un únic esborrat del grup de recursos de laboratori.

Contingut

Escalat vertical davant d'escalat horitzontal
El cas de Contoso: el pic d'obertura de temporada
Conjunts d'escalat de màquines virtuals (VMSS)
Escalat manual, automàtic per mètrica i programat
Zones de disponibilitat i conjunts de disponibilitat
Balanceig de càrrega a Azure: les quatre opcions
Sondes d'estat
Desplegar l'API de Disponibilitat darrere d'un Load Balancer
Aplicacions sense estat: el requisit amagat
Arquitectura resultant i neteja
Errors Comuns i Consells
Exercicis
Conclusió

Escalat vertical davant d'escalat horitzontal

Hi ha dues maneres de donar més capacitat a un sistema.

Aspecte	Escalat vertical (scale up)	Escalat horitzontal (scale out)
Què fas	Canvies la màquina per una de més gran	Hi afegeixes més màquines iguals
A Azure	`az vm resize` a una mida superior	Afegir instàncies a un conjunt d'escalat
Interrupció	Requereix reinici de la VM	Cap: les noves instàncies s'hi sumen
Límit	La mida màxima de la família	Pràcticament el de la teva quota
Alta disponibilitat	Cap: continua sent un punt únic de fallada	Intrínseca: si en cau una instància, en queden les altres
Reversibilitat	Manual i amb reinici	Automàtica i en minuts
Requisit de l'aplicació	Cap	L'aplicació no pot desar estat local

L'escalat vertical és simple i de vegades la resposta correcta: una base de dades relacional monolítica sol escalar millor cap amunt. Però per al còmput d'una aplicació web, el model del núvol és l'horitzontal, per tres raons:

Elasticitat real: pots passar de 2 a 20 instàncies en minuts i tornar a 2 quan el pic acabi. Pagues pel que fas servir, quan ho fas servir.
Disponibilitat: N instàncies repartides suporten la pèrdua d'una sense que el servei caigui.
Sense sostre abrupte: no arribes un dia a la mida màxima de la família i et quedes sense sortida.

La contrapartida és la de l'última fila de la taula, i no és menor: si la teva aplicació desa la sessió de l'usuari a la memòria del servidor o escriu fitxers al seu disc local, l'escalat horitzontal la trenca. Ho tractem a l'apartat 9.

El cas de Contoso: el pic d'obertura de temporada

Les xifres que la Marta Ríos ha mesurat al sistema actual:

Moment	Peticions per segon a l'API de Disponibilitat	CPU mitjana del servidor actual
Dia normal, matinada	15	5 %
Dia normal, hora punta	120	35 %
Obertura de temporada, primera hora	1.800	saturat (100 %, cues)
Obertura de temporada, resta del dia	400	90 %

La conclusió és doble: cal capacitat molt superior durant unes hores a l'any i capacitat mínima la resta del temps. Dimensionar per al pic amb màquines fixes vol dir pagar quinze vegades el necessari durant 360 dies. Dimensionar per al dia normal vol dir perdre vendes el dia que més es ven.

La solució que construïm en aquesta lliçó: l'API de Disponibilitat es desplega en un conjunt d'escalat amb un mínim de 2 instàncies repartides en dues zones, una regla d'escalat automàtic per CPU i una regla programada que eleva el mínim el matí de l'obertura, tot darrere d'un Load Balancer.

Conjunts d'escalat de màquines virtuals (VMSS)

Un conjunt d'escalat de màquines virtuals (Virtual Machine Scale Set, VMSS) és un recurs que gestiona un grup de VM idèntiques com una sola unitat: es creen a partir del mateix model, s'actualitzen juntes i creixen o minven segons regles.

Què et dona un VMSS que no et dona crear VM a mà:

Un sol model: canvies la imatge o la mida al model i s'aplica a totes.
Escalat automàtic per mètrica, per horari o manual.
Reparació automàtica d'instàncies: si una instància falla la sonda d'estat durant un temps, el conjunt la reemplaça.
Distribució automàtica entre zones i dominis d'error.
Actualitzacions per lots (rolling upgrades) sense caiguda del servei.

Model d'orquestració: uniforme davant de flexible

Aspecte	Orquestració Uniform	Orquestració Flexible
Instàncies	Idèntiques, gestionades com a conjunt	VM normals, individualment visibles
Accés a cada instància	Limitat, a través del conjunt	Igual que a qualsevol VM (`az vm show`)
Barreja de mides o de VM al comptat i esporàdiques	No	Sí
Zones de disponibilitat	Sí	Sí, amb repartiment explícit
Recomanació actual d'Azure	Càrregues homogènies molt grans	Predeterminada per a gairebé tot el que és nou

Flexible és avui el mode recomanat per defecte: et dona la gestió del conjunt sense perdre el control individual de cada VM, i permet barrejar instàncies de preu esporàdic (spot) amb instàncies normals per abaratir els pics. És el que farem servir.

Escalat manual, automàtic per mètrica i programat

Escalat manual

# Fixar el nombre d'instancies a ma. Util per a proves i respostes puntuals.
az vmss scale \
  --resource-group rg-contoso-reservas-pro \
  --name vmss-api-disponibilidad-pro \
  --new-capacity 4

Escalat automàtic per mètrica

L'escalat automàtic observa una mètrica i actua. Una regla completa té sempre aquestes peces:

Peça	Què defineix	Exemple
Mètrica	Què s'observa	`Percentage CPU` del conjunt
Agregació i finestra	Com es resumeix i en quant de temps	Mitjana dels últims 5 minuts
Llindar i operador	Quan es dispara	Més gran que 70 %
Acció	Què es fa	Augmentar en 2 instàncies
Refredament (cooldown)	Quant s'espera abans de tornar a actuar	5 minuts
Límits	Mínim, màxim i predeterminat	2 / 20 / 2

GRUP="rg-contoso-reservas-pro"
VMSS="vmss-api-disponibilidad-pro"

# 1. Perfil d'escalat automatic: minim 2, maxim 20, valor per defecte 2.
az monitor autoscale create \
  --resource-group "${GRUP}" \
  --resource "${VMSS}" \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name autoescala-api-disponibilidad \
  --min-count 2 --max-count 20 --count 2 \
  --output none

# 2. Regla d'augment: si la CPU mitjana supera el 70 % durant 5 minuts, +2 instancies.
az monitor autoscale rule create \
  --resource-group "${GRUP}" \
  --autoscale-name autoescala-api-disponibilidad \
  --condition "Percentage CPU > 70 avg 5m" \
  --scale out 2 \
  --cooldown 5 \
  --output none

# 3. Regla de reduccio: si baixa del 30 % durant 10 minuts, -1 instancia.
az monitor autoscale rule create \
  --resource-group "${GRUP}" \
  --autoscale-name autoescala-api-disponibilidad \
  --condition "Percentage CPU < 30 avg 10m" \
  --scale in 1 \
  --cooldown 10 \
  --output none

Fixa't en l'asimetria deliberada entre les dues regles, que és una bona pràctica i no un descuit:

Es puja ràpid i en blocs grans (+2 amb finestra de 5 minuts): quedar-se curt costa vendes.
Es baixa a poc a poc i d'una en una (−1 amb finestra de 10 minuts): reduir massa aviat provoca l'efecte serra, en què el sistema afegeix i treu instàncies sense parar, i cada arrencada triga minuts i costa diners.

Si les regles de pujada i baixada tenen el mateix llindar, tindràs oscil·lació garantida. Deixa sempre una banda morta ampla entre totes dues (aquí, entre 30 % i 70 %).

Escalat programat

Quan saps quan arriba el pic, no esperis que la CPU ho demostri: la reacció per mètrica sempre arriba tard, perquè una instància nova triga uns minuts a arrencar i estar llesta.

# L'obertura de temporada es el 12 de febrer al mati:
# elevem el minim a 10 instancies entre les 07:00 i les 14:00.
az monitor autoscale profile create \
  --resource-group "${GRUP}" \
  --autoscale-name autoescala-api-disponibilidad \
  --name apertura-temporada-verano \
  --min-count 10 --max-count 30 --count 12 \
  --timezone "W. Europe Standard Time" \
  --start 2026-02-12T07:00 \
  --end 2026-02-12T14:00 \
  --output none

Durant aquest perfil, el conjunt no baixa mai de 10 instàncies i pot arribar a 30 si la CPU ho demana. Fora de la finestra, torna al perfil normal (2–20). Aquesta combinació —programat per al que és previsible, per mètrica per al que és imprevisible— és el patró que fan servir la majoria de plataformes de venda amb estacionalitat.

Zones de disponibilitat i conjunts de disponibilitat

Tenir diverses instàncies no serveix de res si són totes al mateix bastidor i aquest bastidor es queda sense corrent. Azure ofereix dos mecanismes de repartiment, i protegeixen de coses diferents.

Conjunt de disponibilitat (dins d'un mateix centre de dades)

Reparteix les VM entre:

Dominis d'error (fault domains): grups de servidors que comparteixen alimentació elèctrica i commutador de xarxa. Si falla el bastidor, cau un domini d'error. Fins a 3 per regió.
Dominis d'actualització (update domains): grups que Azure reinicia per separat durant el manteniment de la plataforma. Fins a 20.

graph TB
    subgraph AS["Conjunt de disponibilitat (un centre de dades)"]
        subgraph FD0["Domini d'error 0"]
            V1["Instancia 1"]
        end
        subgraph FD1["Domini d'error 1"]
            V2["Instancia 2"]
        end
        subgraph FD2["Domini d'error 2"]
            V3["Instancia 3"]
        end
    end

Protegeix de: fallada de bastidor i reinicis de manteniment. No protegeix de la caiguda completa del centre de dades.

Zones de disponibilitat (centres de dades diferents)

Com vas veure a 01-02, una zona és un centre de dades físicament separat dins de la mateixa regió, amb alimentació, refrigeració i xarxa independents. Repartir instàncies entre zones protegeix de la fallada d'un centre de dades sencer.

Mecanisme	Protegeix de	SLA de disponibilitat
Instància única amb discos Premium	Res, més enllà del maquinari local	99,9 %
Conjunt de disponibilitat (2+ instàncies)	Fallada de bastidor i manteniment	99,95 %
Zones de disponibilitat (2+ instàncies en 2+ zones)	Caiguda d'un centre de dades	99,99 %

Decisió de Contoso, coherent amb la del mòdul 1: components crítics en almenys dues zones de West Europe, sense actiu-actiu multiregió (decisió conscient per cost). L'API de Disponibilitat es desplega a les zones 1 i 2.

# Conjunt d'escalat amb repartiment explicit en dues zones.
az vmss create \
  --resource-group rg-contoso-reservas-pro \
  --name vmss-api-disponibilidad-pro \
  --orchestration-mode Flexible \
  --zones 1 2 \
  --instance-count 2 \
  --vm-sku Standard_B2s \
  --image Canonical:ubuntu-24_04-lts:server:latest \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/contoso_motor.pub \
  --custom-data init-api.yaml \
  --tags entorno=produccion proyecto=contoso-reservas \
         centro-coste=CC-1042 [email protected] \
         criticidad=alta \
  --output none

Amb --zones 1 2, Azure reparteix les instàncies de manera equilibrada entre totes dues zones i manté aquest equilibri en escalar. Important: les zones es trien en crear el conjunt i no s'hi poden afegir després. Si creus que algun dia ho necessitaràs, crea'l amb zones des del principi.

Balanceig de càrrega a Azure: les quatre opcions

Tenir diverses instàncies exigeix alguna cosa al davant que reparteixi el trànsit. Azure ofereix quatre serveis i la confusió entre ells és un dels temes preferits dels exàmens de certificació (i de les arquitectures mal fetes).

Servei	Capa	Àmbit	Encamina per	Casos típics	Cost relatiu
Azure Load Balancer	4 (TCP/UDP)	Regional	IP i port	Qualsevol protocol TCP/UDP, backend de VM i VMSS	€
Application Gateway	7 (HTTP/S)	Regional	Ruta URL, capçalera, host	Web i API amb encaminament per ruta, terminació TLS, WAF	€€€
Traffic Manager	DNS	Global	Resposta DNS per perfil (rendiment, prioritat, geografia)	Commutació entre regions, qualsevol protocol	€
Azure Front Door	7	Global	Ruta, host, amb xarxa perimetral i memòria cau	Llocs web globals, terminació TLS a la vora, memòria cau, WAF global	€€€

Criteris d'elecció, en forma de preguntes:

És trànsit HTTP/S? Si no ho és (per exemple, un protocol propi del motor heretat), la teva opció és Load Balancer o Traffic Manager.
Necessites decidir per l'URL (/api/* a un grup, / a un altre), reescriure capçaleres o descarregar TLS? Aleshores necessites capa 7: Application Gateway o Front Door.
El trànsit arriba de tot el món i vols memòria cau i presència a la vora? Front Door.
Només vols commutar entre regions a nivell de DNS, amb qualsevol protocol? Traffic Manager.

Dos avisos d'abast, per no envair altres lliçons:

El que és global —Front Door, Traffic Manager, CDN— es desenvolupa a la lliçó 02-06, amb el cas del client que compra des de Sud-amèrica.
El tallafoc d'aplicacions web (WAF), que s'acobla a Application Gateway o a Front Door, es tracta a la lliçó 04-04.

Aquí ens quedem en allò regional i de capa 4: Azure Load Balancer davant del conjunt d'escalat.

Components d'un Load Balancer

Component	Què és
IP frontal (frontend)	La IP pública o privada per la qual entra el trànsit
Grup de back-end (backend pool)	El conjunt d'instàncies que reben el trànsit
Sonda d'estat (health probe)	La comprovació que decideix quines instàncies estan sanes
Regla de balanceig	Uneix frontal, port, grup i sonda

Les SKU: Standard (l'actual: admet zones, fins a 1.000 instàncies, segur per defecte) i Basic, ja retirada. Fes servir sempre Standard.

Sondes d'estat

Una sonda d'estat és el que separa un balancejador d'un repartidor cec. Cada pocs segons, el balancejador pregunta a cada instància si és viva; si no respon correctament un nombre de vegades seguides, deixa d'enviar-li trànsit.

# Sonda HTTP contra el punt de salut de l'API, cada 5 segons.
az network lb probe create \
  --resource-group rg-contoso-reservas-pro \
  --lb-name lb-api-disponibilidad-pro \
  --name sonda-api-salud \
  --protocol Http \
  --port 80 \
  --path /salud.json \
  --interval 5 \
  --output none

Bones pràctiques per al punt de salut, que valen per a tot el curs:

Que sigui significatiu: ha de comprovar el que cal per servir (hi ha connexió amb la base de dades?), no retornar 200 sempre.
Que sigui barat: s'executa cada pocs segons per instància. Res de consultes pesades.
Que no exigeixi autenticació des de la xarxa interna, o la sonda fallarà sempre.
Separa vivacitat de preparació: «el procés és viu» no és el mateix que «ja puc atendre peticions».

Una sonda mal feta causa dues avaries clàssiques i oposades: instàncies trencades rebent trànsit (sonda massa indulgent) o instàncies sanes retirades del servei en cascada (sonda massa estricta o amb temps d'espera curt).

Desplegar l'API de Disponibilitat darrere d'un Load Balancer

Muntem la peça completa. Per no tocar producció mentre aprens, fes servir el grup de desenvolupament; l'exemple indica producció perquè és l'arquitectura objectiu, però pots substituir pro per dev a totes les variables.

#!/usr/bin/env bash
set -euo pipefail

GRUP="rg-contoso-reservas-pro"
REGIO="westeurope"
VMSS="vmss-api-disponibilidad-pro"
LB="lb-api-disponibilidad-pro"
IP_PUB="ip-lb-api-disponibilidad-pro"

ETIQUETES=(entorno=produccion proyecto=contoso-reservas centro-coste=CC-1042
           [email protected] criticidad=alta)

# 1. IP publica estandard i amb redundancia de zona.
az network public-ip create \
  --resource-group "${GRUP}" --name "${IP_PUB}" \
  --sku Standard --zone 1 2 3 --allocation-method Static \
  --tags "${ETIQUETES[@]}" --output none

# 2. Load Balancer amb frontal public i grup de back-end buit.
az network lb create \
  --resource-group "${GRUP}" --name "${LB}" --sku Standard \
  --public-ip-address "${IP_PUB}" \
  --frontend-ip-name frontal-publico \
  --backend-pool-name pool-api-disponibilidad \
  --tags "${ETIQUETES[@]}" --output none

# 3. Sonda d'estat contra el punt de salut de l'API.
az network lb probe create \
  --resource-group "${GRUP}" --lb-name "${LB}" \
  --name sonda-api-salud --protocol Http --port 80 --path /salud.json \
  --interval 5 --output none

# 4. Regla de balanceig: port 80 del frontal al port 80 del grup.
az network lb rule create \
  --resource-group "${GRUP}" --lb-name "${LB}" \
  --name regla-http-api \
  --protocol Tcp --frontend-port 80 --backend-port 80 \
  --frontend-ip-name frontal-publico \
  --backend-pool-name pool-api-disponibilidad \
  --probe-name sonda-api-salud \
  --idle-timeout 10 --output none

# 5. Conjunt d'escalat en dues zones, ja connectat al grup de back-end.
az vmss create \
  --resource-group "${GRUP}" --name "${VMSS}" \
  --orchestration-mode Flexible \
  --zones 1 2 --instance-count 2 \
  --vm-sku Standard_B2s \
  --image Canonical:ubuntu-24_04-lts:server:latest \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/contoso_motor.pub \
  --custom-data init-api.yaml \
  --lb "${LB}" --backend-pool-name pool-api-disponibilidad \
  --upgrade-policy-mode Automatic \
  --tags "${ETIQUETES[@]}" --output none

echo "API publicada a: http://$(az network public-ip show -g "${GRUP}" -n "${IP_PUB}" --query ipAddress -o tsv)/salud.json"

El fitxer init-api.yaml que instal·la l'API a cada instància (el mateix mecanisme de cloud-init de la lliçó anterior, ara servint la identitat de la instància perquè puguis veure el balanceig funcionant):

#cloud-config
package_update: true
packages:
  - nginx
runcmd:
  - echo "{\"servei\":\"api-disponibilitat\",\"estat\":\"ok\",\"instancia\":\"$(hostname)\"}" > /var/www/html/salud.json
  - systemctl enable --now nginx

Comprovació del balanceig: diverses crides seguides han de retornar noms d'instància diferents.

IP=$(az network public-ip show -g rg-contoso-reservas-pro -n ip-lb-api-disponibilidad-pro --query ipAddress -o tsv)
for i in {1..10}; do curl -s "http://${IP}/salud.json"; echo; done

Si sempre respon la mateixa instància, revisa la persistència de sessió de la regla: per defecte el Load Balancer fa servir una tupla de cinc camps (IP i port d'origen i destinació, protocol), i com que el teu port d'origen canvia a cada petició, hauries de veure repartiment. Si configures persistència per IP d'origen (--load-distribution SourceIP), totes les teves peticions aniran a la mateixa instància, que és justament el que no volem pel motiu de l'apartat següent.

Aplicacions sense estat: el requisit amagat

L'escalat horitzontal imposa una condició a l'aplicació: qualsevol instància ha de poder atendre qualsevol petició. Això vol dir que la instància no pot desar res que les altres necessitin.

Els tres estats que trenquen l'escalat i on han d'anar en lloc seu:

Estat que es desa malament	Símptoma quan escales	On ha d'anar
Sessió de l'usuari en memòria	El client perd el carret de bitllets en saltar d'instància	Magatzem extern: Azure Cache for Redis, o galeta signada pel client
Fitxers pujats al disc local	La targeta d'embarcament generada "desapareix" segons quina instància respongui	Azure Storage (lliçó 02-04): les targetes van a `sttarjetascontosopro`
Dades de negoci en fitxers locals	Cada instància té una veritat diferent	Base de dades (mòdul 3): `sql-contoso-reservas-pro`

La temptació fàcil és activar la persistència de sessió al balancejador perquè cada client vagi sempre a la mateixa instància. És un pedaç amb tres efectes secundaris seriosos: el repartiment es desequilibra, la caiguda d'una instància expulsa els seus usuaris, i en reduir instàncies es perden sessions actives. Serveix com a solució temporal durant una migració, mai com a disseny.

Per això l'ordre d'aquest mòdul no és casual: primer el còmput escalable, després l'emmagatzematge on viu el que el còmput no pot desar (02-04) i al mòdul 3, la base de dades. L'API de Disponibilitat de Contoso es dissenya sense estat des del primer dia: llegeix de la base de dades, escriu les targetes a Storage i no desa res en local.

Arquitectura resultant i neteja

graph TD
    CLI["Clients<br/>(web Contoso Reserves)"] --> LB["Azure Load Balancer Standard<br/>lb-api-disponibilidad-pro<br/>IP publica estatica"]
    LB -->|"sonda /salud.json"| P["Grup de back-end<br/>pool-api-disponibilidad"]
    P --> Z1["Zona 1<br/>instancia api-01"]
    P --> Z2["Zona 2<br/>instancia api-02"]
    AE["Escalat automatic<br/>CPU 70% / programat obertura"] -.->|"ajusta 2 a 20"| VMSS["vmss-api-disponibilidad-pro<br/>(Flexible)"]
    VMSS --- Z1
    VMSS --- Z2
    Z1 --> SQL["db-reservas<br/>(modul 3)"]
    Z2 --> SQL
    Z1 --> ST["sttarjetascontosopro<br/>(llico 02-04)"]
    Z2 --> ST

Neteja (recorda que el grup de producció té el bloqueig no-borrar-produccion; en laboratori treballa sobre el grup de desenvolupament):

# Esborrat individual, en ordre invers al de creacio.
az vmss delete --resource-group rg-contoso-reservas-dev --name vmss-api-disponibilidad-dev
az network lb delete --resource-group rg-contoso-reservas-dev --name lb-api-disponibilidad-dev
az network public-ip delete --resource-group rg-contoso-reservas-dev --name ip-lb-api-disponibilidad-dev

# O, en un grup de laboratori dedicat, l'esborrat complet:
# az group delete --name rg-contoso-laboratorio --yes --no-wait

I una comprovació que ja hauries de fer per reflex: az disk list --query "[?diskState=='Unattached']" -o table.

Errors Comuns i Consells

Posar el mateix llindar per pujar i baixar. Produeix l'efecte serra: el sistema afegeix i treu instàncies sense parar. Deixa una banda morta ampla (30 %–70 %).
Baixar tan agressivament com es puja. Reduir de dues en dues amb finestra de 5 minuts deixa el servei curt just quan el pic rebota. Puja ràpid, baixa a poc a poc.
Confiar només en l'escalat per mètrica per a un pic conegut. Arrencar instàncies triga minuts; el pic de l'obertura arriba en segons. Fes servir un perfil programat.
Confondre conjunt de disponibilitat amb zona de disponibilitat. El primer protegeix de la fallada de bastidor dins d'un centre de dades; el segon, de la caiguda del centre de dades sencer.
Oblidar que les zones es fixen en crear el conjunt d'escalat. No s'hi afegeixen després. Crea'l zonal des del principi.
Fer servir Application Gateway on n'hi ha prou amb un Load Balancer (o a l'inrevés). Si no necessites decisions per URL ni terminació TLS, la capa 4 és més simple i molt més barata.
Sondes que retornen 200 passi el que passi. Un punt de salut que no comprova res garanteix que el balancejador enviï trànsit a instàncies trencades.
Escalar horitzontalment una aplicació amb estat en memòria. Apareixen errors intermitents impossibles de reproduir. Treu l'estat abans d'escalar.
Consell de quota: el màxim de vCPU per família i regió és una quota, no un límit físic (lliçó 01-05). Si la teva regla pot arribar a 20 instàncies de 4 vCPU, comprova que tens 80 vCPU de quota abans del dia de l'obertura.
Consell de cost: per als pics, considera instàncies de preu esporàdic (spot) dins del conjunt flexible. Són molt més barates a canvi de poder ser desallotjades; serveixen per a capacitat extra, mai per al mínim.

Exercicis

Exercici 1: dissenyar la política d'escalat del pic

Amb les dades mesurades per la Marta Ríos (15 peticions per segon de matinada, 120 en hora punta normal, 1.800 al pic d'obertura), i sabent que una instància Standard_B2s de l'API atén còmodament unes 100 peticions per segon:

Quantes instàncies calen com a mínim en un dia normal en hora punta, amb marge per perdre'n una?
Quantes al pic d'obertura?
Defineix els valors de mínim, màxim i perfil programat que configuraries.
Explica per què no n'hi ha prou amb la regla per CPU aquell dia.

Exercici 2: triar el balancejador

Per a cada necessitat de Contoso, indica quin servei de balanceig faries servir i per què:

Repartir el trànsit del protocol binari del motor de disponibilitat heretat (TCP 8500) entre tres VM a West Europe.
Enviar /api/* a l'API de Disponibilitat i la resta a la web de reserves, dins de la mateixa regió, amb terminació TLS.
Servir la web pública a clients de Sud-amèrica amb la menor latència possible i memòria cau d'imatges.
Commutar a North Europe si West Europe deixa de respondre, per a un servei que no és HTTP.

Exercici 3: muntar i demostrar l'alta disponibilitat

En un grup de laboratori:

Crea un conjunt d'escalat flexible amb 2 instàncies a les zones 1 i 2, amb cloud-init que publiqui el nom de la instància a /salud.json.
Posa'l darrere d'un Load Balancer Standard amb sonda HTTP a /salud.json.
Demostra amb curl que el trànsit es reparteix entre les dues instàncies.
Atura una instància i demostra que el servei continua responent i que la sonda l'ha retirada del grup.

Solucions

Solució 1:

Hora punta normal: 120 ÷ 100 = 1,2 → 2 instàncies, i amb marge per perdre'n una (patró N+1), 3. Com que el mínim també ha de cobrir la zona que pugui caure, 2 és el terra absolut i 3 el prudent.
Pic d'obertura: 1.800 ÷ 100 = 18 → 18 instàncies, més marge N+1 → 20.
Configuració proposada:

# Perfil normal.
az monitor autoscale create ... --min-count 2 --max-count 20 --count 2

# Perfil programat per a l'obertura (minim alt des d'abans que obri la venda).
az monitor autoscale profile create \
  --name apertura-temporada-verano \
  --min-count 12 --max-count 30 --count 20 \
  --timezone "W. Europe Standard Time" \
  --start 2026-02-12T07:00 --end 2026-02-12T14:00

Perquè l'escalat per mètrica és reactiu: necessita 5 minuts de CPU alta per disparar-se i uns quants minuts més perquè les instàncies arrenquin i passin la sonda. El pic de l'obertura arriba en menys d'un minut, així que durant els primers 10 minuts —els de més vendes de l'any— el servei estaria saturat. El perfil programat deixa la capacitat ja calenta abans que obri la venda.

Solució 2:

Cas	Servei	Motiu
1. TCP 8500 del motor heretat	Azure Load Balancer	Capa 4: funciona amb qualsevol protocol TCP/UDP; els de capa 7 només entenen HTTP/S
2. `/api/*` davant de la resta, amb TLS, en una regió	Application Gateway	Capa 7 regional: encaminament per ruta i terminació TLS. A més admet WAF (04-04)
3. Clients de Sud-amèrica amb memòria cau	Azure Front Door	Global, amb presència a la vora, terminació TLS a prop del client i memòria cau (detall a 02-06)
4. Commutació a North Europe sense HTTP	Traffic Manager	Treballa a nivell de DNS, és independent del protocol i admet perfil de prioritat per a commutació per error

Solució 3:

#!/usr/bin/env bash
set -euo pipefail
GRUP="rg-contoso-laboratorio"
az group create --name "${GRUP}" --location westeurope \
  --tags entorno=pruebas proyecto=contoso-reservas centro-coste=CC-1042 \
         [email protected] --output none

# 1 i 2: IP, balancejador, sonda, regla i conjunt d'escalat.
az network public-ip create -g "${GRUP}" -n ip-lb-lab --sku Standard --allocation-method Static --output none
az network lb create -g "${GRUP}" -n lb-lab --sku Standard \
  --public-ip-address ip-lb-lab --frontend-ip-name frontal-publico \
  --backend-pool-name pool-lab --output none
az network lb probe create -g "${GRUP}" --lb-name lb-lab -n sonda-lab \
  --protocol Http --port 80 --path /salud.json --interval 5 --output none
az network lb rule create -g "${GRUP}" --lb-name lb-lab -n regla-http \
  --protocol Tcp --frontend-port 80 --backend-port 80 \
  --frontend-ip-name frontal-publico --backend-pool-name pool-lab \
  --probe-name sonda-lab --output none
az vmss create -g "${GRUP}" -n vmss-lab --orchestration-mode Flexible \
  --zones 1 2 --instance-count 2 --vm-sku Standard_B1s \
  --image Canonical:ubuntu-24_04-lts:server:latest \
  --admin-username azureuser --ssh-key-values ~/.ssh/contoso_motor.pub \
  --custom-data init-api.yaml --lb lb-lab --backend-pool-name pool-lab --output none

# 3. Comprovar el repartiment.
IP=$(az network public-ip show -g "${GRUP}" -n ip-lb-lab --query ipAddress -o tsv)
for i in {1..10}; do curl -s "http://${IP}/salud.json"; echo; done

# 4. Aturar una instancia (mode Flexible: son VM normals) i repetir la prova.
INSTANCIA=$(az vm list -g "${GRUP}" --query "[0].name" -o tsv)
az vm stop -g "${GRUP}" -n "${INSTANCIA}"
for i in {1..10}; do curl -s "http://${IP}/salud.json"; echo; done
# Totes les respostes han de venir ara de l'altra instancia, sense errors.

# Neteja completa.
az group delete --name "${GRUP}" --yes --no-wait

Després d'aturar la instància, la sonda falla diverses vegades seguides i el balancejador la retira del grup: pots trigar uns 15-20 segons a veure l'efecte (interval de sonda pel nombre de fallades tolerades). Aquest retard és exactament el temps d'indisponibilitat parcial que patirien alguns clients en una fallada real, i és l'argument per no posar intervals de sonda llargs.

Conclusió

Ja saps escalar i donar alta disponibilitat al còmput a Azure. Distingeixes l'escalat vertical de l'horitzontal i entens per què el núvol aposta pel segon: elasticitat real, disponibilitat intrínseca i absència de sostre. Saps què és un conjunt d'escalat de màquines virtuals, la diferència entre orquestració uniforme i flexible, i com definir escalat manual, automàtic per mètrica —amb llindars asimètrics i banda morta per evitar l'efecte serra— i programat, que és l'única resposta raonable a un pic amb data coneguda com l'obertura de la temporada d'estiu de Contoso. Coneixes la diferència entre conjunts de disponibilitat (dominis d'error i actualització dins d'un centre de dades) i zones de disponibilitat (centres de dades independents), amb el seu efecte directe sobre l'SLA: 99,9 %, 99,95 % i 99,99 %. Has comparat els quatre serveis de balanceig amb criteris clars i has desplegat un Load Balancer Standard amb sonda d'estat sobre un conjunt d'escalat repartit en dues zones. I has interioritzat el requisit amagat de tot això: l'aplicació no pot tenir estat local.

Ara bé, mira què ha costat: un conjunt d'escalat, un balancejador, una sonda, regles d'autoescalat, i encara has de pedaçar el sistema operatiu de cada instància, actualitzar la imatge, gestionar certificats TLS a mà i muntar tu mateix el desplegament sense caigudes. Per al motor heretat no hi ha alternativa. Però per a una aplicació web moderna com Contoso Reserves o per a la nova API de Disponibilitat, Azure ofereix un servei que fa tot això per tu.

A la lliçó següent, Azure App Service, veuràs per què Contoso hi publica les seves aplicacions en lloc de mantenir VM: plans i nivells amb el que desbloqueja cadascun, piles de temps d'execució, desplegament del codi amb ZIP i Git, ajustos d'aplicació i cadenes de connexió, dominis propis amb certificats gestionats, escalat automàtic sense conjunts per administrar i, sobretot, ranures de desplegament amb intercanvi i escalfament previ per publicar versions noves sense que cap client deixi de comprar el seu bitllet.

Escalat i alta disponibilitat del còmput