Hvorfor A/B-opdeling?

I indlejrede systemer kan mislykkede opdateringer ødelægge enheder. Et A/B-layout løser dette ved at opretholde to rodfilsystemer:

  • Slot A - aktiv rootfs
  • Slot B - standby rootfs til næste opdatering

Når en opdatering lykkes, skifter bootloaderen til det nye slot. Hvis opstarten mislykkes, rulles der tilbage til den sidst kendte gode version.

Denne tilgang forudsætter, at slot A og slot B har samme størrelse på partitionen, hvilket kan være vanskeligt i indlejrede systemer, hvor ressourcerne er begrænsede.

swupdate med redningssystem

En anden tilgang er at oprette partitioner til et lille redningssystem og en større partition til det normalt kørende system.

Eksempel på partitionslayout

Et typisk Raspberry Pi Compute Module 5 (CM5) layout kan se sådan ud:
PartitionTypeFormål
p1FAT32/boot_A (kerne, cmdline, bootloader)
p2ext4rootfs A
p3FAT32/boot_B (kerne, cmdline, bootloader til redningssystem)
p4ext4rootfs_B
p5ext4data/konfiguration
Bootloaderen kan bruge et flag (f.eks. GPIO17=1 i rpi-eeprom) til at afgøre, om den skal boote fra rescue-partitionen.

Praktisk eksempel

Denne opsætning er demonstreret i to rpi-image-geneksempelprojekter:

Den første opretter redningssystemet, og den anden kombinerer redningssystemet med et andet kørende system ved at justere partitionsetiketterne i cmdline.txt og fstab.

Styring af opdatering

Du kan montere den inaktive systempartition manuelt for at opdatere konfigurationer, programmer eller systemkomponenter.
For produktionssystemer styres opdateringer typisk via SWUpdatesom automatiserer denne proces på en sikker måde.

Integration med SWUpdate

SWUpdate understøtter naturligt opdateringsstrategier med to rodfrugter (A/B).
Partitioner og opdateringslogik defineres direkte i filen sw-description filen.

Denne tilgang sikrer atomare systemopdateringer med indbygget rollback-sikkerhed - en vigtig funktion for hovedløse eller fjerntliggende enheder, hvor manuel gendannelse ikke er mulig.

Artikler i denne serie

Kilder