Die Umstellung auf softwaredefinierte Umspannwerke: Herausforderungen bei der Synergie von Hardware und Software meistern
Da der Energiesektor mit der Integration dezentraler erneuerbarer Ressourcen einen kritischen Punkt erreicht, bietet die Umstellung auf softwaredefinierte Umspannwerke nicht nur neue Möglichkeiten, sondern auch Herausforderungen sowohl für allgemeine Software als auch für moderne Computerhardware.
Als Schlüssel zu diesem Übergang muss die Synergie zwischen Hardware und Software sicherstellen, dass Umspannwerke nicht nur weiterhin effektiv die Schutzfunktion unter Einhaltung der Normen und lokalen Vorschriften erfüllen, sondern darüber hinaus mehr Flexibilität, Interoperabilität und Skalierbarkeit des Betriebs auf Augenhöhe mit moderner IT bieten.
Eines der größten Hindernisse für den Einsatz von Allzwecksoftware und -hardware in Umspannwerken ist wahrscheinlich die Sicherstellung einer ausreichenden Reaktionsfähigkeit der darauf laufenden Schutzanwendungen, damit im Falle einer Unterbrechung des Stromnetzes rechtzeitig Abhilfemaßnahmen durchgeführt werden können. Diese Reaktionsfähigkeit wird häufig als Latenzzeit bestimmt und kann je nach Anwendungstyp auf verschiedene Weise gemessen werden.
Entwicklung eines Virtualisierungs-Aufbaus mit niedriger Latenz für Schutzrelais in digitalen Umspannwerken
Dieser Artikel beschreibt unsere Bemühungen, eine reproduzierbare Hardware- und Software-Einrichtung zu entwickeln, die in der Lage ist, Latenzzeiten auf einem Niveau zu liefern, das für die Virtualisierung von Schutzrelaisfunktionen in einem digitalen Umspannwerk geeignet ist.
Zu diesem Zweck konzentrieren wir uns auf die Durchführung von Latenzmessungen auf CentOS Stream 9 Hosts, die mit Hilfe des SEAPATH Projekt auf der Grundlage der kürzlich hinzugefügten CentOS-Unterstützung bereitgestellt und konfiguriert wurden.. Obwohl SEAPATH auch ein breites Spektrum an Dienstprogrammen für die Bereitstellung von Workloads auf einem konfigurierten Cluster bietet, konzentrieren wir uns im Folgenden nur auf die manuelle Bereitstellung der Testumgebung.
Optimierung von Hardware der Umspannwerksklasse: Welotec RSAPC Mk2 in Aktion
Für unser Hardware-Setup haben wir drei Rugged Substation Automation Computer Mk2 von Welotec verwendet. Dabei handelt es sich um robuste lüfterlose 19-Zoll-2U-Rackmount-Industrie-PCs, die speziell für typische Umgebungen in Umspannwerken entwickelt wurden. Sie entsprechen den Normen IEC-61850-3 und IEEE1613 und können nicht nur in einem weiten Temperaturbereich (von -40°C bis +70°C) betrieben werden, sondern bieten auch Schutz vor elektrostatischer Entladung (EDS) und widerstehen hohen elektromagnetischen Feldern und RF-Interferenzen.
Wir haben die Spitzenmodelle der Mk2-Server auf Basis des Intel Xeon W-11865MLE Prozessors mit 8 Kernen (und bis zu 16 Threads) und 64 GB RAM (bis zu 128 GB verfügbar) verwendet, um mehrere containerisierte und virtualisierte Arbeitslasten gleichzeitig einsetzen zu können.
Jedes der Systeme ist mit 8 Onboard-Ethernet-Ports ausgestattet, von denen wir einige für Latenzmessungen verwendeten.
Für alle Hosts haben wir die 1.19 RSAPC Mk2 Version des BIOS für Rugged Substation Automation Computer Mk2 verwendet, die bereits mit deaktiviertem Hyper-Threading als Teil der Intel TCC vorkonfiguriert war. An der BIOS-Konfiguration wurden keine besonderen Änderungen vorgenommen. Alle drei Server wurden mit CentOS Stream 9 RT-Betriebssystemen mit aktivierter RT-Virtualisierung unter Verwendung eines Installationsmediums aus einer hier bereitgestellten Kickstart-Datei eingerichtet.
Nachdem die Bereitstellung und die Clusterkonfiguration abgeschlossen waren, haben wir die Standardeinstellungen von CentOS Stream 9 evaluiert und auf der Grundlage unserer bisherigen Erfahrungen so angepasst, dass die beste Leistung in Bezug auf die Latenz erreicht wurde.
Zunächst haben wir zugelassen, dass Anwendungen auf allen Kernen ausgeführt werden (da wir die virtuellen Maschinen für die Verwendung von sched_setaffinity konfiguriert haben). SEAPATH konfiguriert dies standardmäßig auf die CPUs 1-7 (und zwingt den Benutzer, cgroups zu erstellen).
systemctl set-property user.slice AllowedCPUs=0-7
systemctl set-property machine.slice AllowedCPUs=0-7
systemctl set-property system.slice AllowedCPUs=0-7
grubby --args "default_hugepagesz=1G" --update-kernel ALL
grubby --args "intel_iommu=on iommu=pt" --update-kernel ALL
#Edit /etc/tuned/realtime-virtual-host-variables.conf and set the following #variables
#with the respective values:
# 1) "isolated_cores=1-7" (CPU 0 will be housekeeping CPU).
# 2) isolate_managed_irq=Y
# 3) netdev_queue_count=4
tuned-adm profile realtime-virtual-host
echo "echo 16 > /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages" >> /etc/rc.d/rc.local
chmod +x /etc/rc.d/rc.local
reboot
Nach dem Neustart haben wir eine der Onboard-NICs dem vfio-pci-Treiber zugewiesen (der genaue Befehl hängt von der PCIe-Topologie und dem Typ der verwendeten NIC ab) und als letzten Schritt der Host-Konfiguration haben wir die L3-Cache-Reservierung mit Intel CAT eingerichtet.
#setup Cache-Way masks for COS 0-1
wrmsr 0xc90 0xf00 # 1111 0000 0000
wrmsr 0xc91 0x0ff # 0000 1111 1111
# cores 0 and 1 remain in default COS 0
# core 0: host hk CPU
# core 1: guest hk vCPU
wrmsr -p 0 0xc8f 0x000000000
wrmsr -p 1 0xc8f 0x000000000
# set core 2-7 to use COS 1
wrmsr -p 2 0xc8f 0x100000000
wrmsr -p 3 0xc8f 0x100000000
wrmsr -p 4 0xc8f 0x100000000
wrmsr -p 5 0xc8f 0x100000000
wrmsr -p 6 0xc8f 0x100000000
wrmsr -p 7 0xc8f 0x100000000
virt-install -n RHEL9-RT --os-variant=rhel9.0 --memory=10240,hugepages=yes --memorybacking hugepages=yes,size=1,unit=G,locked=yes --vcpus=3 --numatune=0 --disk path=./rhel9-rt.img,bus=virtio,cache=none,format=qcow2,io=threads,size=20 --graphics none --console pty,target_type=serial -l CentOS-Stream-9-latest-x86_64-dvd1.iso --extra-args 'console=ttyS0,115200n8 serial'
--- rhel9rt-vanilla.xml 2024-09-12 06:57:02.953731331 -0400
+++ rhel9rt-vanilla-rt.xml 2024-09-12 07:13:00.013727680 -0400
@@ -15,6 +15,17 @@
<locked/>
</memoryBacking>
<vcpu placement='static'>3</vcpu>
+ <cputune>
+ <vcpupin vcpu='0' cpuset='1'/>
+ <vcpupin vcpu='1' cpuset='2'/>
+ <vcpupin vcpu='2' cpuset='3'/>
+ <vcpupin vcpu='3' cpuset='4'/>
+ <emulatorpin cpuset='0'/>
+ <vcpusched vcpus='0' scheduler='fifo' priority='1'/>
+ <vcpusched vcpus='1' scheduler='fifo' priority='1'/>
+ <vcpusched vcpus='2' scheduler='fifo' priority='1'/>
+ <vcpusched vcpus='3' scheduler='fifo' priority='1'/>
+ </cputune>
<numatune>
<memory mode='strict' nodeset='0'/>
</numatune>
@@ -28,8 +39,14 @@
<features>
<acpi/>
<apic/>
+ <pmu state='off'/>
+ <vmport state='off'/>
</features>
- <cpu mode='host-passthrough' check='none' migratable='on'/>
+ <cpu mode='custom' match='exact' check='partial'>
+ <model fallback='allow'> Cascadelake-Server-noTSX</model>
+ <vendor> Intel</vendor>
+ <feature policy='require' name='tsc-deadline'/>
+ </cpu>
<clock offset='utc'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
@@ -52,17 +69,6 @@
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>
- <disk type='file' device='cdrom'>
- <driver name='qemu'/>
- <target dev='sda' bus='sata'/>
- <readonly/>
- <alias name='sata0-0-0'/>
- <address type='drive' controller='0' bus='0' target='0' unit='0'/>
- </disk>
- <controller type='usb' index='0' model='qemu-xhci' ports='15'>
- <alias name='usb'/>
- <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
- </controller>
<controller type='pci' index='0' model='pcie-root'>
<alias name='pcie.0'/>
</controller>
@@ -178,12 +184,6 @@
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>
- <channel type='unix'>
- <source mode='bind' path='/run/libvirt/qemu/channel/6-RHEL9-RT/org.qemu.guest_agent.0'/>
- <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
- <alias name='channel0'/>
- <address type='virtio-serial' controller='0' bus='0' port='1'/>
- </channel>
<input type='mouse' bus='ps2'>
<alias name='input0'/>
</input>
@@ -191,18 +191,14 @@
<alias name='input1'/>
</input>
<audio id='1' type='none'/>
- <watchdog model='itco' action='reset'>
- <alias name='watchdog0'/>
- </watchdog>
- <memballoon model='virtio'>
- <alias name='balloon0'/>
- <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
- </memballoon>
- <rng model='virtio'>
- <backend model='random'> /dev/urandom</backend>
- <alias name='rng0'/>
- <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
- </rng>
+ <watchdog model='itco' action='none'/>
+ <memballoon model='none'>
+ <hostdev mode='subsystem' type='pci' managed='yes'>
+ <source>
+ <address domain='0x0000' bus='0x09' slot='0x00' function='0x0'/>
+ </source>
+ <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
+ </hostdev>
</devices>
<seclabel type='dynamic' model='selinux' relabel='yes'>
<label>system_u:system_r:svirt_t:s0:c325,c379</label>
Testumgebung: Benchmarking der Latenz in virtualisierten Umspannwerken
Um die Ergebnisse der Latenzmessung möglichst repräsentativ für den Anwendungsfall digitaler Umspannwerke zu machen, haben wir die Architektur der Testumgebung an einen Vorschlag angeglichen, der derzeit von der vPAC Alliance ausgearbeitet wird. Wir haben eine für das DPDK-Framework l2reflect-Anwendung zum Benchmarking der maximalen l2-Roundtrip-Latenz des Systems verwendet, die den Vorteil hat, dass sie nicht nur die Latenz des Betriebssystems misst (wie z. B. cyclictest), sondern auch die Latenz des Netzwerkstacks und des Ethernets selbst berücksichtigt.
Um die Latenz zu messen, haben wir in einer virtualisierten Umgebung manuell echtzeitfähige VMs mit der Anwendung l2reflect auf zwei zuvor vorkonfigurierten Instanzen bereitgestellt. In Abbildung 1 ist der Einsatz im Detail dargestellt. Wir haben die CPUs 1-7 isoliert und CPU0 für die Housekeeping-Aufgaben des Host-Betriebssystems belassen.
Zusätzlich wurde eine Instanz von stress-ng auf der CPU0 eingesetzt, um weitere Best-Effort-Anwendungen zu simulieren, die auf dem Host laufen. Die CPUs 1-4 wurden dann der VM mit entsprechendem Pinning auf vCPU0-3 zugewiesen, außerdem haben wir eine der Onboard-NICs an die VM weitergegeben. In der VM widmeten wir vCPU0 (CPU1 auf dem Host) den Housekeeping-Aufgaben des Gastbetriebssystems und setzten erneut eine stress-ng-Instanz ein, um Best-Effort-Anwendungen zu simulieren, die in der VM laufen.
Anschließend wiesen wir vCPU1 und vCPU2 eine l2reflect-Instanz zu und verwendeten dafür die Richtlinie SCHED_FIFO. Auf der verbleibenden isolierten vCPU4 setzten wir eine zyklische Testinstanz ein, um eine andere latenzempfindliche Anwendung zu simulieren, die keine E/A-Funktionen nutzt, um zusätzliche Informationen über die Systemleistung zu sammeln.
Erreichen einer gleichbleibend niedrigen Latenzzeit in Umspannwerken: Ergebnisse eines 7-tägigen Dauertests
Die Tests wurden kontinuierlich über einen Zeitraum von 7 Tagen durchgeführt, um eine ausreichende Statistik der gemessenen Latenz und der Gesamtstabilität des Systems bei langen Läufen sicherzustellen. Das Ergebnis ist, dass die vom l2reflect-Test gemeldete Latenz 82µs (Durchschnitt 44µs) für den virtualisierten Testaufbau nicht überschritten hat.
Obwohl es keinen allgemein akzeptierten maximalen Latenzwert für die Auslastung von Schutzrelais in Umspannwerken gibt, wird häufig davon ausgegangen, dass die vom l2reflect-Test ermittelten Werte den Grenzwert von 250µs nicht überschreiten dürfen. Es ist erwähnenswert, dass dieser Schwellenwert nicht durch ein spezifisches theoretisches Modell gestützt wird, sondern auf der Erfahrung verschiedener Akteure im Bereich der Automatisierung von Umspannwerken beruht.
Die erzielten Werte sind ein deutlicher Beweis dafür, dass eine für eine typische Schutzrelaisanwendung ausreichende Reaktionszeit mit der KVM-RT-Virtualisierung und einem Allzweckbetriebssystem wie CentOS Stream 9 erreicht werden kann, wenn es auf industriell geeigneter Hardware wie Welotec RSAPC Mk2 eingesetzt wird.
Die Tatsache, dass unsere Tests an sieben aufeinander folgenden Tagen liefen, zeigt nicht nur, dass eine maximale Latenzzeit von weniger als 250 µs erreichbar ist, sondern auch, dass dieser Wert über einen längeren Zeitraum aufrechterhalten werden kann.
Autoren: Marcelo Tosatti (RedHat), Daniel Knüppe (Welotec), Martin Kohn (Welotec), Alexander Lougovski (RedHat)
