Broadcom und Arista haben gemeinsam eine vereinheitlichte Netzwerk-Fabric für Rechenzentren vorgestellt. Sie soll virtuelle und physische Server durchgängig im Netzwerk erreichbar und verwaltbar machen.

Physische und virtuelle Workloads in Rechenzentrumsnetzen zu verwalten, bleibt aufwendig. Klassischerweise existieren zwei Fabrics nebeneinander: VMware NSX mit dem Overlay-Protokoll GENEVE für die virtuellen Workloads und in aktuellen physischen Architekturen eine EVPN/VXLAN-Fabric für Control- und Dataplane. Über beide Architekturen hinweg müssen jedoch konsistente Sicherheitsrichtlinien eingerichtet sowie die Konnektivität und Performance sichergestellt werden. Insbesondere in größeren Umgebungen ist das ein erheblicher Betriebsaufwand.

Die Unified Network Fabric soll diese Trennung aufheben. Dazu integrieren Broadcom und Arista VCF mit dem Universal Cloud Network (UCN) und führen physische und virtuelle Workloads in einer gemeinsamen EVPN-/VXLAN-Fabric zusammen. Die Control Plane tauscht Erreichbarkeits-/Routing-Informationen über EVPN aus, der Nutzdatenverkehr läuft in der Data Plane über VXLAN.

Anbindung über Transit Gateway und Route Controller

VCF bindet seine virtuellen Workloads über ein sogenanntes Transit Gateway an die Arista Fabric an – das mit VCF 9.0 eingeführte Anbindungselement der Virtual Private Clouds (VPCs). Die benötigten Erreichbarkeits-/Routing-Informationen erhält das Transit Gateway vom VCF Route Controller (RC), der ein Multiprotocol BGP (MP-BGP) Peering mit den Arista EVPN Gateways unterhält. Über dieses Peering tauschen beide Seiten die Routing-Informationen aus.

In EVPN-Fabrics erfolgt die Mandantentrennung über virtuelle Routing-Instanzen und sogenannte L3VNIs. In der Unified Fabric ordnet der Administrator jedem L3VNI das passende Transit Gateway zu. Die Abbildung zeigt diese Kopplung am Beispiel des L3VNI 10000. Die 1:1-Zuordnung zwischen Routing-Instanz und Transit Gateway soll die Mandantentrennung, Skalierbarkeit und eine einfache Verwaltung gewährleisten.

Routenaustausch und Datenpfad

Damit die Arista Fabric die virtuellen Workloads erreicht, verteilt der VCF Route Controller entsprechende Host-Routen (/32 für IPv4 oder /128 für IPv6) als EVPN-Typ-5-Routeninformationen mit der Host-IP-Adresse und der Tunnel Endpoint (TEP) IP-Adresse für den VXLAN-Tunnel an die Arista EVPN Gateways. Optional kann das EVPN Gateway diese Host-Routen aggregieren, um die Routing-Tabellen der Fabric in größeren Umgebungen zu entlasten. In der Rückrichtung melden die Arista EVPN Gateways Subnetz-Präfixe oder eine Standard-Route je Routing-Instanz an den Route-Controller.

Auf Basis dieser Informationen verpackt der jeweilige ESXi-TEP die Nutzdaten in einen VXLAN-Tunnel und schickt sie an das Arista-EVPN-Gateway. Dieses leitet die Pakete durch den passenden L3VNI an den Ziel-VTEP (Leaf-Switch) im EVPN-Fabric weiter. Ein durchgehender VXLAN-Tunnel zwischen ESXi-Host und Leaf-Switch entsteht also nicht – das EVPN Gateway fungiert als Re-Encapsulation-Punkt zwischen virtueller und physischer Welt.

Einheitliche Sicht für den Betrieb

Über die EVPN-Routinginformationen soll der Administrator zudem in einer einzigen Routing-Umgebung erkennen, an welchem TEP sich ein Workload befindet – ohne Umweg über proprietäre Schnittstellen.

Ergänzend führen Arista CloudVision und VCF Operations die Telemetrie-, Topologie- und Konfigurationsdaten beider Welten in einer gemeinsamen Oberfläche zusammen. Fehleranalyse und Change-Management lassen sich so übergreifend abwickeln. Für den operativen Alltag dürfte dieser Aspekt mindestens so wichtig sein wie die Control-Plane-Mechanik selbst.

Verfügbarkeit und Einsatzszenarien

Die Unified Network Fabric ist zunächst als Tech Preview in VCF 9.1 verfügbar; die allgemeine Verfügbarkeit sowie das Lizenzmodell stehen laut Broadcom noch aus. Interessant dürfte der Ansatz für Brownfield-Migrationen und gemischte Mandantenumgebungen sein, in denen heute zwei getrennte Fabrics parallel laufen. Voraussetzung bleibt eine zertifizierte Switch-Fabric – Multi-Vendor-Szenarien sind über die offene EVPN-Typ-5-Schnittstelle grundsätzlich möglich, in der Erstauflage liegt der Fokus aber auf der Arista-Integration.

(fo)

GitHub stellt sein Abrechnungsmodell für Copilot abermals um. Ab dem 1. Juni setzen sich alle Bezahltarife, die für einzelne Entwicklerinnen und Entwickler konzipiert sind, aus zwei Bestandteilen zusammen: einer festen Menge an Token (den Base Credits) und einem Flex‑Kontingent. Letzteres will GitHub dynamisch an wirtschaftliche Faktoren wie die Modellkosten anpassen.

GitHub hatte bereits Ende April angekündigt, kostenlose Modelle aus den Copilot-Tarifen zu streichen. Jetzt folgt weitere Feinabstimmung, die als Reaktion auf das Feedback der Community zu verstehen ist, wie GitHub zu den Änderungen schreibt. Die Community fragte sich nämlich, ob das in den kostenpflichtigen Tarifen enthaltene Token-Kontingent ausreicht, wenn Anfang Juni die Umstellung auf verbrauchsbasierte Nutzung erfolgt.

Base Credits + Flex-Kontingent = AI Credits

Was es mit dem Flex‑Kontingent auf sich hat, beantwortet GitHub folgendermaßen: „Es passt sich an, wenn sich die wirtschaftlichen Rahmenbedingungen für KI verändern, einschließlich Modellpreisen, neuen Modellen und Effizienzverbesserungen.“ Die Base Credits, die sich 1:1 aus dem Abonnementpreis ergeben, bleiben dagegen immer gleich, so der Anbieter.

Das Flex‑Kontingent greift ab dem 1. Juni für die Tarife Pro und Pro+. Haben Entwicklerinnen und Entwickler die Base Credits ausgeschöpft, können sie aus dem Flex-Kontingent weitere Token beziehen. Beim Pro-Tarif summieren sich 1.000 Base Credits und ein derzeitiges Flex-Kontingent von 500 Credits zu einer monatlichen Gesamtmenge von 1.500 AI Credits. Für den Tarif Pro+ ergeben sich dementsprechend 7.000 AI Credits (3.900 Base + 3.100 Flex).

Das gleiche Abrechnungsschema wendet auch der neue Max-Tarif an, der ebenfalls ab Juni startet. Er richtet sich an diejenigen, die Copilot intensiv nutzen, schlägt mit 100 US-Dollar pro Monat zu Buche und umfasst 10.000 Base Credits sowie ein gleichwertiges Flex-Kontingent von weiteren 10.000 AI Credits.

Fallback auf einfachere Modelle entfällt

Wurde der Credit-Rahmen ausgeschöpft, blockiert Copilot bis zum Start des nächsten Abrechnungszeitraums alle Anfragen, die Credits benötigen. Bislang konnte man automatisch auf ein günstigeres Modell zurückfallen, doch diese Möglichkeit entfällt mit dem neuen Tarifmodell. Immerhin lässt GitHub den Free-Tarif weiterhin unangetastet, mit derzeit 50 Premium-Anfragen und 2.000 Code-Vorschlägen pro Monat.

Nutzerinnen und Nutzer der bisherigen monatlichen Tarife müssen nichts weiter tun, die Umstellung erfolgt automatisch. Jährliche Verträge werden nicht auf das neue Modell umgestellt. Sie laufen bis zum Vertragsende noch nach dem bisherigen anfragenbasierten Preissystem, allerdings mit höheren Multiplikatoren für teurere Modelle.

(mro)

Die stark wachsende Zahl von Raketenstarts für den Aufbau von Starlink & Co. „gleicht einem unregulierten Geoengineering-Experiment, das viele unbeabsichtigte und schwerwiegende Folgen für die Umwelt haben könnte“. Das meint Eloise Marais, die Leiterin einer internationalen Forschungsgruppe, die untersucht hat, wie groß die Luftverschmutzung durch die Raketen ist. Herausgekommen ist dabei, dass allein der Aufbau der sogenannten Megakonstellationen schon für mehr als ein Drittel der Klimabelastung durch die Raumfahrt verantwortlich ist; 2029 sollen es mindestens 42 Prozent sein. Das liegt primär an dem bei Starts ausgestoßenen Ruß, der dabei so hoch in die Atmosphäre gelangt, dass er über 500-mal stärker das Klima belastet als Ruß aus Fahrzeugen und Kraftwerken.

Folgen völlig unklar

Wie das University College London zusammenfasst, hat die Gruppe ermittelt, dass die Raketenstarts für den Aufbau von Starlink & Co. schon jetzt mehr als die Hälfte des gesamten genutzten Raketentreibstoffs verbrauchen. Dieser Anteil soll weiter wachsen. Beobachten konnten auch Außenstehende, dass sich die Zahl der jährlichen Raketenstarts zwischen 2020 und 2025 verdreifacht hat, getrieben fast ausschließlich durch SpaceX und seine Falcon 9. Die Folgen für die Erdatmosphäre werden nur langsam klarer. Schon 2029 könnten die aber so weitreichend sein wie vorgeschlagenes Geoengineering, also technische Maßnahmen im Kampf gegen den Klimawandel. Das geschieht aber weitgehend unreguliert und ohne Abwägung der Konsequenzen.

Der Raketentreibstoff auf Kerosinbasis, den SpaceX verwendet, sorge für die Abgabe von Rußpartikeln in oberen Atmosphärenschichten, erklärt das Forschungsteam. Dort verbleibt er für Jahre, weil er anders als Ruß aus Quellen an der Oberfläche nicht durch Niederschläge entfernt wird. Während der Ruß deshalb dort 540-mal effektiver das Klima beeinflusse als bodennaher Ruß, dürfte die Raumfahrt schon 2029 rund 870 Tonnen Ruß ausstoßen – so viel wie alle Passagierfahrzeuge in Großbritannien. In der Folge dürfte dieser Ruß einen abkühlenden Effekt auf das weltweite Klima haben, aber man müsse trotzdem sehr vorsichtig sein. Welche Folgen sich genau ergeben, sei vollkommen unklar und nur jetzt habe man noch die Möglichkeit, gegebenenfalls gegenzusteuern.

Als Geoengineering bezeichnet man großräumige technische Eingriffe in Kreisläufe der Erde – besonders im Kampf gegen den Klimawandel. Während es immer wieder Warnungen vor solchen Vorhaben und den damit verbundenen immensen Risiken gibt, wird teilweise erwartet, dass Geoengineering angesichts der katastrophalen Folgen der Klimaerwärmung in den kommenden Jahrzehnten mindestens von einzelnen Nationen umgesetzt wird. Ein US-Start-up hat zudem eigenmächtig mit der Freisetzung von reflektierenden Partikeln begonnen. Die jetzt im Fachmagazin Earth’s Future veröffentlichte Studie besagt jetzt, dass es sich bei der rasch anwachsenden Zahl von Satellitenstarts um eine weitere bereits praktizierte Form von Geoengineering handelt, wobei der Effekt vollkommen unbeabsichtigt wäre.

(mho)