Fragen zur Netzwerk Konfiguration eines PVE Clusters mit Ceph, OVS und PBS

[Bitstream]

Hallo zusammen,

ich bin gerade dabei einen Proxmox VE + Backup Server Prototypen aufzubauen. Ziel ist die Ablösung eines lokalen 8 Knoten VMware Clusters inkl. vSAN und Veeam Backup. Für den Testbetrieb habe ich mindestens 4 bis 5 Server für PVE mit 10 NICs je Server zur Verfügung und einen Super Micro Server mit 24 HDDs für das Backup. Alles "altes" Zeug aber für den Test wird es wohl reichen, sollten die Tests erfolgreich sein wird neue Hardware für den Cluster angeschafft.

Ich habe hier soweit auch alles bereits einmal durchgespielt und am laufen, einzig bei der Netzwerkkonfiguration tue ich mich etwas schwer. Ich möchte natürlich alles "richtig" machen und versuche deshalb herrauszufinden wie denn die Netzwerke unter Proxmox am besten eingerichtet werden.

Vorab, ich möchte das ganze mit OVS realisieren aber das sollte bei den grundlegenden Fragen eigentlich erst einmal keine Rolle spielen.

Für die ersten Tests hatte ich erst einmal alles über ein Netz laufen lassen, es ging am Anfang hauptsächlich um die Möglichkeit vorhandene Features mit Proxmox nachbauen zu können. Diese Funktionalitäten sind soweit die bisherigen Tests zeigen, gegeben.

Jetzt aber zu meinen Fragen, ich habe die Dokus soweit alle gelesen (hoffe ich doch) und mir auch z.B. einen Vortrag von Alwin angesehen. In der Doku, in der folgenden Antwort von Alwin und auch im Vortrag wird immer wieder auf das weitere separieren der Netze hingewiesen.

None. Your servers need more NIC ports. Ceph public & cluster, VM traffic, corosync (best two interfaces) and maybe some extra for migration, backups or management.

Leider wird es nach VM Netzwerk, Cluster und Public Netzwerk (Ceph) mit der Doku etwas eng. Ich habe in einer älteren Doku noch etwas zum Migration Network (CLI Konfiguration) gefunden und anschließend gesehen das dieses Feature inzwischen auch in die Web UI eingebaut ist

Gibt es evtl. hier oder woanders einen best practise guide den ich bisher übersehen habe? Ich würde nämlich in der Tat gerne die Netze soweit wie möglich separieren um keine Flaschenhälse zu generieren.

Könnt ihr mir aufzeigen was ich alles benötige um so wenig wie möglich Störungen bzw. Einflüsse durch die verschiedenen Traffic Arten zu haben?

Welche Art von Traffic benötig welche Bandbreite bzw. wieviel Gigabits sollten mindestens zur verfügung gestellt werden?

Was kann man zusammen legen, evtl. über VLANs trennen und was sollte über separate NICs/Kabel/Switches fließen? Was macht Sinn was evtl. nicht?

Soweit ich das bisher gesehen habe sollten diese Dinge separiert werden:

Ceph public & cluster network - Das Cluster Network sollte wohl über den 54GBit Switch laufen? Was ist mit dem Public Network?
(VLANs) VM Guest Network traffic
Corosync (best two interfaces) - Hier habe ich zwei NICs pro Server und zwei separate Gigabit Switches für Ring0|1 vorgesehen
(Live) Migration network
Backup network für PBS
(OOB) Management network
(OSD) Replication traffic - Kann man den separieren? Sollte m.M. im Prinzip dem Ceph Cluster Network entsprechen.
(Cluster) Heartbeat traffic - Kann man den separieren? Sollte m.M. im Prinzip dem Ceph Cluster Network entsprechen.

Ich hab keine Ahnung ob ich alle Punkte oben aufgeführt bzw. bedacht habe, aber deshalb wende ich (Noob) mich ja ans Forum Ich hoffe doch hier gibt es ein paar findige User die mir bei dem ein oder andren Thema auf die Sprünge helfen können.

Soweit habe ich das bisher für mich aufgedröselt:

Interface IP Address       Network Type            Comment
ens18     192.168.18.11    management network      ssh, web ui
ens19     192.168.19.11    ceph public network     The Monitor, Manager, and metadata Services as well as Ceph Clients communicate on this network.
ens20     192.168.20.11    ceph cluster network    OSDs route heartbeat, object replication and recovery traffic over the cluster network
ens21     192.168.21.11    corosync ring0 network  Corosync handles the cluster communication in Proxmox VE
ens22     192.168.22.11    corosync ring1 network  Corosync handles the cluster communication in Proxmox VE
ens23     192.168.23.11    live migration network
ens24     192.168.24.11    backup network      
ens25     10.1.x.x         vm vlan networks
ens26     noch nicht belegt
ens27     noch nicht belegt

Bis dahin und habt eine gute Zeit
Volker

 

[aaron]

Vorab, ich möchte das ganze mit OVS realisieren aber das sollte bei den grundlegenden Fragen eigentlich erst einmal keine Rolle spielen.

Hast du spezielle Gründe dafür? In den meisten Fällen wird es mittlerweile nämlich nicht mehr gebraucht da die normale Linux Bridge die meisten Funktionen in den letzten Jahren bekommen hat, die man so braucht.


Zu den Netzen selbst. Die Grundidee ist, soweit wie möglich es auf verschiedene physikalische Netze aufzuteilen damit nicht Dienste einander negativ beeinflussen.

Um das ganze noch ausfallsicher zu machen, sollten die Netze über zwei (gestackte) Switche gehen, damit man auch mal ein Switch kaputtgehen kann bzw. man Firmware Updates installieren kann, was meist einen Neustart braucht.

Sprich bis auf Corosync, welches selbst wechseln kann, muss man für die anderen Diense einen Bond konfigurieren damit das ausfallsicherer wird. Damit ist man dann aber auch sehr schnell am Ende der verfügbaren Netzwerkkarten.

Das wichtige zuerst, Corosync sollte eben mindestens eins, besser zwei Netze für sich alleine haben, vor allem wenn HA verwendet werden soll ist es wirklich wichtig eine stabile Verbindung zu haben. Du kannst bis zu 8 Netze (links/rings) für Corosync konfigurieren und somit auch andere Netze as absolute Notfallreserve nehmen.

Was, glaube ich auch noch klar gesagt werden muss, mit einem Hyperkonvergenten PVE Ceph cluster, hast du zwei geclusterte Systeme parallel. Einerseits PVE das Corosync für die Clusterkommunikation verwendet, und Ceph das von PVE deployed und gemanaged wird.

Ceph läuft idealerweise auch auf seinem eigenen physikalischen Netz um nicht zB vom Backuptraffic oder einer (Live) Migration beeinflusst zu werden. Wieviel Bandbreite du so brauchst, hängt davon ab, wie viele Nodes du hast, wie viele OSDs und was für welche (HDD, SSD, NVME,...), denn je nachdem kann auch ein 10Gbit schon sehr schnell zum Flaschenhals werden.
Schau dir am besten mal die Ceph Benchmark paper an. Das von 2020 schaut was man aus schnellen u.2 NVMEs in Kombination mit einem 100Gbit Netz herausholen kann während das von 2018 sich anschaut wie sich verschiedene Netzwerkgeschwindigkeiten mit unterschiedlicher OSD Anzahl auswirken.

Ceph kennt zwei Netze. Das obligatorische Public Netz über das die Monitore, Manager, Clients und OSDs miteinander kommunizieren. Wenn man dieses Netz nun ein wenig entlasten will, kann man das optionale Cluster Netzwerk konfigurieren. Dann läuft der Heartbeat und Replication Traffic zwischen den OSDs darüber. Beide müssen schnell sein.

Was du jetzt noch an Netzen aufsplittest kommt ganz auf deine Möglichkeiten an. Ob man zB Backup und Migration Netz aufteilt; denn je nachdem wie oft Backups laufen und wie oft migriert wird, könnte man mitunter argumentieren, dass man die im gleichen Netz laufen lässt. Genauso was den VM und MGMT Traffic angeht. Wenn hier davon ausgegangen werden kann, dass die Bandbreite mehr als ausreicht, könnte man diese auch nur mit VLANs trennen.

Ich hoffe das hilft dir weiter und klärt ein paar Dinge auf. Ansonsten einfach Fragen

 

[Bitstream]

@aaron vielen Dank für deine ausführliche Antwort!

Hast du spezielle Gründe dafür? In den meisten Fällen wird es mittlerweile nämlich nicht mehr gebraucht da die normale Linux Bridge die meisten Funktionen in den letzten Jahren bekommen hat, die man so braucht.

Irgendjemand hat wohl in den Specs gelesen das der OVS in etwa wie der Distributed Switch (VDS) von VMware ist/funktioniert. Bei genauerer Betrachtung sehe ich das nicht so optimistisch. Allerdings erhoffe ich mir ein besseres Handling von VLANs (wir haben viele, auch Host/Cluster only) und Bridges. Weiter hätte der Netzwerk Kollege wohl gerne Netflow. Jedenfalls steht das ganze noch auf der Liste der zu testenden Funktionen und es wird sich bei der Umsetzung zeigen, ob es Sinnvoll ist oder nicht.

Sprich bis auf Corosync, welches selbst wechseln kann, muss man für die anderen Diense einen Bond konfigurieren damit das ausfallsicherer wird. Damit ist man dann aber auch sehr schnell am Ende der verfügbaren Netzwerkkarten.

Danke, dies ist eine sehr wichtige Info. Wie oben geschrieben habe ich in der Testumgebung 10 NICs pro Server zur Verfügung. Ich schaue aktuell welchen Traffic die einzelnen Dienste verursachen können, um die Planung weiter zu verfeinern. Corosync ist für mich eigentlich klar, da wird es zwei Ringe/Switches geben die komplett losgelöst von allem anderen agieren. Nur das Management der Switche wird einen Link ins Managementnetz bekommen.

Ceph kennt zwei Netze. Das obligatorische Public Netz über das die Monitore, Manager, Clients und OSDs miteinander kommunizieren. Wenn man dieses Netz nun ein wenig entlasten will, kann man das optionale Cluster Netzwerk konfigurieren. Dann läuft der Heartbeat und Replication Traffic zwischen den OSDs darüber. Beide müssen schnell sein.

Was ist hier mit schnell gemeint? Ich bin bisher davon ausgegangen das ich für das Public Netz durchaus auch eine Gigabit Leitung nutzen kann und eine kleine Latenz benötige. Das Cluster Netzwerk benötigt eine hohe Bandbreite, soweit mein bisheriges Verständnis. Oder war es umgekehrt Deine Aussage lässt mich jedenfalls an meinen bisherigen Erkenntnissen zweifeln, also noch mal die Nase in die Doku stecken

Backup und Migration Netz werden definitiv getrennt, da haben wir in den letzten Jahren mit VMware unser Lehrgeld gezahlt Zum einen haben wir VMs die auch im laufe des Arbeitstags gesichert werden müssen und zum anderen haben wir teilweise/zweitweise einige Migrationen. Hintergrund sind (sehr große) VMs der Entwicklung die häufig gestartet/gestoppt werden und recht Ressourcen hungrig sind. Je nachdem wo die gerade liegen, wurden die bei VMware vom Distributed Resource Scheduler (DRS) auf weniger ausgelastete Hosts verschoben. Ich gehe derzeit bei PVE vom gleichen verhalten aus.

Das Management Netz werden wir ebenfalls von den VM Netzen trennen. In der Vergangenheit hatten wir das mal mit den VM Netzen (VLANs) über die gleichen Kabel laufen lassen mit der folge das wir auch schon mal nicht vernünftig ans Management Interface gekommen sind. Soweit ich das Verhindern kann, werde ich das über separate Kabel auch tun. Beim Management Netz reicht dann auch eine Gigabit Leitung, sie muss nur exklusiv für diesen Zweck sein, dann sollte es meiner Meinung keine Probleme geben.

Ich habe die Liste von oben um einen Reiter für die Bandbreite und Redundanz (Interface Typ) erweitert. Den passenden LACP Mode für die verschiedenen Traffic Typen müsste ich mir dann auch noch suchen. Die Geschwindigkeiten sind erst einmal nur symbolisch, um sie unterscheiden zu können. Derzeit habe ich bis 56 Gigabit zur Verfügung. Da wir aber später für die Umgebung alles neu anschaffen bin ich da recht flexibel.

Interface IP Address       Gbit iface   Network Type            Comment
ens18     192.168.18.11      1+ bond    management network      ssh, web ui
ens19     192.168.19.11      ?  ?       ceph public network     The Monitor, Manager, and metadata Services as well as Ceph Clients communicate on this network.
ens20     192.168.20.11      ?  ?       ceph cluster network    OSDs route heartbeat, object replication and recovery traffic over the cluster network
ens21     192.168.21.11      1+ single  corosync ring0 network  Corosync handles the cluster communication in Proxmox VE
ens22     192.168.22.11      1+ single  corosync ring1 network  Corosync handles the cluster communication in Proxmox VE
ens23     192.168.23.11     50+ bond    live migration network
ens24     192.168.24.11     10+ single  backup network    
ens25     10.1.x.x          10+ bond    vm vlan networks
ens26     noch nicht belegt
ens27     noch nicht belegt

Für das Backup ist der PBS vorgesehen und nach den bisherigen Tests scheint mir die benötigte Bandbreite recht gering zu sein da nur Deltas übertragen werden. Ändert sich das nach dem ersten Backup noch einmal? Ich habe das Backup bisher knapp drei Wochen am laufen und konnte, abgesehen von neuen VMs keinen erhöhten Traffic mehr feststellen.

Nur zur Info für den Fall, dass sich jemand über die "nur" mit 10+ gekennzeichnete Bandbreite bei den VM Netzen wundert. Der größte Teil der benötigten Bandbreite wird zwischen den VMs gebraucht. Hier stehen u.a. Buildserver und Repositories die munter zum Teil fette binaries durch die Gegend schieben.

Edit: Blöd, Denkfehler! Ich meinte den Traffic von außen auf die Umgebung, die VMs müssen natürlich untereinander eine größere Bandbreite haben. Die Endet aber am Rack Switch. Der Wert muss aber trotzdem erhöht werden.

Edit 2: Noch mal Blöd, Stichwort: Distributed Resource Scheduler (DRS). Gut, dass wir drüber gesprochen bzw. geschrieben haben, mir fällt jetzt erst auf das es so etwas unter Proxmox gar nicht gibt. Damit wäre das Projekt auf einen Schlag komplett erledigt. Gibt es da wirklich kein äquivalent?

 

[aaron]

Was ist hier mit schnell gemeint? Ich bin bisher davon ausgegangen das ich für das Public Netz durchaus auch eine Gigabit Leitung nutzen kann und eine kleine Latenz benötige. Das Cluster Netzwerk benötigt eine hohe Bandbreite, soweit mein bisheriges Verständnis. Oder war es umgekehrt Deine Aussage lässt mich jedenfalls an meinen bisherigen Erkenntnissen zweifeln, also noch mal die Nase in die Doku stecken

Nein. Das Ceph Public Netz ist das notwendige, das Ceph Cluster optional. Sprich, wenn es kein Ceph Cluster gibt, läuft auch der OSD Heartbeat und Replication Traffic darüber. Wenn es ein Ceph Cluster Netz gibt, läuft aber immer noch der Client Traffic über das Ceph Public Netz. Sprich die VMs sprechen mit der jeweils primären OSD über das Public Netz -> sollte schnell sein.

Das Netz, das mit 1Gbit auskommt und nur niedrige Latenz braucht, ist für Corosync. Vielleicht hat sich hier beim vielen einlesen was vermischt

Für das Backup ist der PBS vorgesehen und nach den bisherigen Tests scheint mir die benötigte Bandbreite recht gering zu sein da nur Deltas übertragen werden. Ändert sich das nach dem ersten Backup noch einmal? Ich habe das Backup bisher knapp drei Wochen am laufen und konnte, abgesehen von neuen VMs keinen erhöhten Traffic mehr feststellen.

Genau. Solange die VM auch durchgehend läuft, werden auch nur die Bereiche der Festplatte angeschaut, die seit dem letzten Backup eine Schreiboperation abbekommen haben. Wenn eine neue VM zum ersten Mal gesichert wird, wird zwar die ganze Festplatte zum PBS übertragen (AFAIK), aber mitunter nur ein Teil davon neu abgespeichert, z.B. wenn es sich um einen Klon einer anderen VM handelt, oder das gleiche OS installiert ist, was die Wahrscheinlichkeit erhöht, dass sich die Festplatten der VMs stellenweise sehr ähneln -> Deduplizierung auf PBS Seite.

Edit 2: Noch mal Blöd, Stichwort: Distributed Resource Scheduler (DRS). Gut, dass wir drüber gesprochen bzw. geschrieben haben, mir fällt jetzt erst auf das es so etwas unter Proxmox gar nicht gibt. Damit wäre das Projekt auf einen Schlag komplett erledigt. Gibt es da wirklich kein äquivalent?

Nein, etwas Fertiges gibt es hier tatsächlich nicht. Es gäbe aber die Möglichkeiten, so etwas selbst zu bauen. Entweder bekommt ihr die Metriken von PVE selbst, z.B. weil es die Metriken selbst an einen Server, wie Graphite oder InfluxDB schickt (https://pve.proxmox.com/pve-docs/pve-admin-guide.html#external_metric_server) oder ihr habt eh eure eigene Monitoringlösung.

Anhand der für euch im speziellen wichtigen Metriken könnt ihr dann über die API jegliche Aktion starten, die man auch selber über die CLI bzw. GUI machen kann.
In der PVE Wiki gibt es einen Artikel wie man sich gegen die API Authentifiziert und wie man sie verwendet mit Beispielen anhand von curl: https://pve.proxmox.com/wiki/Proxmox_VE_API
Der API Viewer (auch auf jeder installierten PVE Instanz vorhanden, Documentation oben links in der GUI) zeigt einem welche API Endpunkte es gibt und welche Parameter sich diese erwarten. Für Migrationen z.B. https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/{node}/qemu/{vmid}/migrate


Eine Frage habe ich jetzt noch. Für das Migration Netz hast du 50Gbit oder mehr vermerkt. Schreiben eure VMs dermaßen viel und schnell in den RAM, dass so ein schnelles Netz nötig ist, um da irgendwie hinterherzukommen?

 

[Bitstream]

Das Netz, das mit 1Gbit auskommt und nur niedrige Latenz braucht, ist für Corosync. Vielleicht hat sich hier beim vielen einlesen was vermischt

Ähm, ja. Also wenn wir das Trennen benötigen beide Netze eine schnelle Verbindung. Mein Lösungsansatz wäre eine redundante Verbindung über z.B. 56 Gigabit, Public und Cluster Network jeweils über einen Link/Port geleitet und im Fehlerfall ein Fall back auf eine Leitung. So geht es jedenfalls bei VMware, mal schauen, ob sich das in der Art auch mit Proxmox realisieren lässt.

Es gäbe aber die Möglichkeiten, so etwas selbst zu bauen. Entweder bekommt ihr die Metriken von PVE selbst, z.B. weil es die Metriken selbst an einen Server, wie Graphite oder InfluxDB schickt (https://pve.proxmox.com/pve-docs/pve-admin-guide.html#external_metric_server) oder ihr habt eh eure eigene Monitoringlösung.

Okay, influxDB 2.0 ist eh angebunden und läuft auch schon im Testaufbau. Die Implementierung für RDS muss ich mir anschauen, klingt aber erst einmal nicht so schwierig. Deine Info ist super! Ich hatte schon befürchtet das Projekt einstampfen zu müssen, bevor es richtig losgegangen ist.

Für das Migration Netz hast du 50Gbit oder mehr vermerkt. Schreiben eure VMs dermaßen viel und schnell in den RAM, dass so ein schnelles Netz nötig ist, um da irgendwie hinterherzukommen?

Das ist historisch und aus der VMware Implementierung übernommen. Unter bestimmten Umständen nutzt VMware das vMotion Netzwerk für Storage vMotion und dann kommen schon einige Daten zusammen. Das sollte unter Proxmox anders laufen, also direkt über die OSD Replikation, richtig?

Edit: Was passiert, wenn ich einen Ceph Cluster und einen iSCSI Storage habe und dann den Storage einer VM von z.B. iSCSI Storage auf den Ceph Storage verschiebe? Welchen weg gehen die Daten dann?

 

[aaron]

Mein Lösungsansatz wäre eine redundante Verbindung über z.B. 56 Gigabit, Public und Cluster Network jeweils über einen Link/Port geleitet und im Fehlerfall ein Fall back auf eine Leitung.

Ich würde es gar nicht so kompliziert machen. Wenn ihr sowieso nicht in absehbarer Zeit weitere NICs nachsteckt, dann könntest du dir fürs erste das Ceph Cluster Netz auch sparen. Wenn du es aber schonmal konfiguriert haben willst um es später auch einfacher auf andere NICs zu schieben, würde ich es folgendermaßen machen:

   ┌───────┐       ┌────────┐
   │ NIC 1 │       │ NIC 2  │
   └────┬──┘       └─────┬──┘
        │                │
        │                │
        │ ┌───────────┐  │
        └─┤Bond (LACP)├──┘
          └──┬─────┬──┘
             │     │
      ┌──────┘     └─────┐
      │                  │
┌─────┴─────┐     ┌──────┴─────┐
│Ceph Public│     │Ceph Cluster│
│  (VLAN)   │     │    (VLAN)  │
└───────────┘     └────────────┘

Durch LACP wird, wenn möglich, die volle Bandbreite genutzt. In der /etc/network/interfaces kann das ganze dann z.B. so aussehen:

auto ens19
iface ens19 inet manual

auto ens20
iface ens20 inet manual

auto bond0
iface bond0 inet manual
    bond-slaves ens19 ens20
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer2
    mtu 9000
#ceph bond

auto ceph_cluster
iface ceph_cluster inet static
    address 10.10.10.1/24
    vlan-id 10
    vlan-raw-device bond0
#Ceph Cluster

auto ceph_public
iface ceph_public inet static
    address 10.10.20.1/24
    vlan-id 20
    vlan-raw-device bond0
#ceph public

Das ist historisch und aus der VMware Implementierung übernommen. Unter bestimmten Umständen nutzt VMware das vMotion Netzwerk für Storage vMotion und dann kommen schon einige Daten zusammen. Das sollte unter Proxmox anders laufen, also direkt über die OSD Replikation, richtig?

Ohne jetzt selbst viel Erfahrung mit den teuren sachen von VMware zu haben, wenn eine VM migriert wird und die Disken der VM im Ceph liegen, wird nur der Zustand der VM (RAM, CPU) über das Migrationsnetz übertragen. Das Storage auf dem die Disken liegt ist ja von jeder Node über Ceph und dessen Netz erreichbar.

Je nachdem wie schnell das Migrationnetz ist, kann es schon mal vorkommen, dass sich der RAM zu schnell ändert. Hatte vor einiger Zeit z.B. einen Kunden im Support bei dem die Migration nie fertig wurde und dann (nach einem sehr langen Timeout) abgebrochen wurde. Das war IIRC ein 1Gbit Netz und die VM hatte währenddessen den WIndows Virusscanner aktiv der den großen Fileshare gescannt hat.

 

[Bitstream]

Vielen Dank für deine hilfreichen Antworten! Ich werde die Infos jetzt mal sacken lassen und die Dinge noch mal für mich sortieren.

Edit: Was passiert, wenn ich einen Ceph Cluster und einen iSCSI Storage habe und dann den Storage einer VM von z.B. iSCSI Storage auf den Ceph Storage verschiebe? Welchen weg gehen die Daten dann?

Kannst du dazu evtl. noch etwas sagen? Geht der Traffic vom iSCSI Netzwerk direkt ins Ceph Netzwerk oder nehmen die Daten noch einen Umweg?

Durch LACP wird, wenn möglich, die volle Bandbreite genutzt. In der /etc/network/interfaceskann das ganze dann z.B. so aussehen:

LACP war mein Plan, ich hatte allerdings im Kopf die beiden Netze physikalisch zu trennen damit die sich nicht in die Quere kommen. Umgekehrt hätte ich mit deiner Lösung die doppelte Bandbreite und im Falle eines Ausfalls immer noch die einfache Bandbreite. Die Anbindung für den Storage wird bei uns auf jeden Fall redundant, ob mit 100 Gigabit oder 56 Gigabit ist noch offen, aber sie wird redundant.

 

[aaron]

Kannst du dazu evtl. noch etwas sagen? Geht der Traffic vom iSCSI Netzwerk direkt ins Ceph Netzwerk oder nehmen die Daten noch einen Umweg?

Der Traffic geht über die Node, sprich iSCSI -> Node -> Ceph. Wenn die VM läuft, passiert das im Hintergrund, ohne dass diese davon etwas mitbekommt.