Virtuelle Netzwerke über die API einrichten

Zwei bereitgestellte Server erhalten ein eigenes privates Netzwerk; jede Anfrage mit {serviceId} wird daher einmal pro Server ausgeführt.

1. VLAN-ID wählen

Jedes Netzwerk benötigt eine localVlanId von 11 bis 4094, die kein anderes Netzwerk der Organisation verwendet. VLAN-Verfügbarkeit abrufen listet belegte Tags als data.usedVlanIds und nennt den nächsten freien als data.nextFreeVlanId; der Bereich steht in minVlanId und maxVlanId:

curl --request GET \
  --url https://api.serverside.com/v1/networking/virtual-networks/availability \
  --header 'Authorization: Bearer <api-key>'

2. Netzwerk erstellen

Erstellen Sie ein virtuelles Netzwerk mit dem Tag aus Schritt 1 als localVlanId:

curl --request POST \
  --url https://api.serverside.com/v1/networking/virtual-networks \
  --header 'Authorization: Bearer <api-key>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "name": "backend",
  "type": "PRIVATE",
  "localVlanId": 100
}
'

Die API wählt keinen Tag für Sie; localVlanId ist bei jeder Erstellung erforderlich. Die Antwort ist 201 mit dem Netzwerk, dessen data.id die {networkId} der späteren Schritte ist. Ein privates Netzwerk erhält von uns weder Subnetz noch Gateway. Seine Server verwenden einen von Ihnen gewählten privaten Bereich; diese Anleitung nutzt 10.20.0.0/24. Frames, die Sie darin mit eigenen 802.1Q-VLAN-IDs taggen, erreichen andere Server mit unveränderten Tags.

3. Segment jedes Servers wählen

Ein Server tritt einem Netzwerk über ein Segment bei: einen Port oder zwei gebündelte Ports. Netzwerkfähigkeiten abrufen listet physische Ports unter data.availableInterfaces mit id, name, macAddress und der zugehörigen segmentId; isConfigured ist bei bereits segmentzugehörigen Ports gesetzt. data.availableBondingGroups listet gemeinsam bündelbare Ports.

curl --request GET \
  --url https://api.serverside.com/v1/baremetal/{serviceId}/networking/capabilities \
  --header 'Authorization: Bearer <api-key>'

Zwei Konfigurationen sind möglich:

• Getaggt auf dem vorhandenen Segment. Das Segment mit dem ungetaggten Internetzugangsnetz des Servers führt auch das private Netzwerk, getaggt mit dessen localVlanId. Es wird kein zweites Kabel verwendet.
• Nativ auf einem zweiten Port. Ein freier Port wird zu einem eigenen Segment; das private Netzwerk kommt dort ungetaggt an.

Bei der nativen Konfiguration akzeptiert Segment erstellen die aufzunehmenden interfaceIds: einen freien Port oder zwei aus einem Eintrag von availableBondingGroups für einen LACP-Bond, den der Host bond0, bond1 usw. nennt. Ein Bond benötigt genau zwei Ports, je einen auf jedem Switch des Paares, mit derselben Portnummer auf beiden.

curl --request POST \
  --url https://api.serverside.com/v1/baremetal/{serviceId}/segments \
  --header 'Authorization: Bearer <api-key>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "interfaceIds": [
    "<interface-id>"
  ]
}
'

Die Antwort ist 201 mit dem neuen Segment und seiner segmentId.

4. Server verbinden

Rufen Sie Dienst verbinden einmal pro Server auf. Für die getaggte Konfiguration ist segmentId das Segment mit dem Internetzugangsnetz des Servers, das Virtuelle Dienstnetzwerke auflisten in dessen Netzwerkzeile zeigt; isNative ist false. Für die native Konfiguration ist es das neue Segment aus Schritt 3 mit isNative true.

curl --request POST \
  --url https://api.serverside.com/v1/networking/virtual-networks/{networkId}/attachments \
  --header 'Authorization: Bearer <api-key>' \
  --header 'Idempotency-Key: <idempotency-key>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "serviceId": "<service-id>",
  "segmentId": "<segment-id>",
  "isNative": false
}
'

202 bedeutet, dass die Änderung zu den Switches unterwegs ist. Der Body enthält deren status APPLYING und die Annahmezeit als since. Erneutes Senden mit demselben Idempotency-Key antwortet mit 202 und der ursprünglichen Änderung. Ohne Schlüssel antwortet dieselbe bereits umgesetzte Verbindung mit 204 und ändert nichts.

5. Auf die Änderung warten

Zwei Stellen melden den Fortschritt. Dienststatus abrufen enthält networkChange mit status APPLYING oder FAILED und Startzeit als since. Während der Umsetzung erscheint ein degraded-Objekt, wenn ein Switch die Änderung wiederholt nicht übernimmt: consecutiveFailures, die jüngste failureCategory und nextAttemptAt für den nächsten automatischen Versuch oder null, sobald die Änderung auf unsere Mitarbeiter wartet. Eine als FAILED endende Änderung wurde auf dem Switch zurückgerollt; failureCategory nennt die Ursache.

Virtuelle Dienstnetzwerke auflisten zeigt den eigenen status jeder Verbindung: ATTACHING, dann ATTACHED oder ATTACH_FAILED.

curl --request GET \
  --url https://api.serverside.com/v1/baremetal/{serviceId}/virtual-networks \
  --header 'Authorization: Bearer <api-key>'

Ein Server verarbeitet jeweils eine Netzwerkänderung. Die nächste Verbindung, Trennung oder Segmentänderung wartet daher auf deren Abschluss.

6. Betriebssystem konfigurieren

Ein getaggtes Netzwerk benötigt auf dem Server eine VLAN-Schnittstelle über der segmentführenden Schnittstelle. Bare-Metal-Dienst abrufen nennt sie: Jeder Eintrag in interfaces ist ein Segment, dessen name die bei einer Bereitstellung auf dem Host geschriebene Schnittstelle ist: der Portname oder bei einem Bond bond0, bond1 usw.; dessen bondMode lautet LACP. Nach einer Segmentänderung zeigt interfaces die Konfiguration der nächsten Bereitstellung; der Host behält seine alten Schnittstellen bis zur Neuinstallation.

Unter Linux mit iproute2, wenn der Segment-name eno1 ist und die Shellvariable VLAN den Netzwerktag enthält:

ip link add link eno1 name eno1.$VLAN type vlan id $VLAN
ip addr add 10.20.0.1/24 dev eno1.$VLAN
ip link set eno1.$VLAN up

Geben Sie dem zweiten Server 10.20.0.2/24, damit beide sich über das private Netzwerk erreichen. Diese Befehle überstehen keinen Neustart; übernehmen Sie die Einstellungen zur dauerhaften Speicherung in die Netzwerkkonfiguration der Distribution (netplan unter Ubuntu, /etc/network/interfaces unter Debian, NetworkManager auf Systemen der RHEL-Familie).

Private Netzwerke übertragen Jumbo-Frames mit einer MTU von 9000. Jeder Server im Netzwerk benötigt denselben Wert auf seiner privaten Schnittstelle:

ip link set eno1 mtu 9000
ip link set eno1.$VLAN mtu 9000

Linux setzt die MTU einer VLAN-Schnittstelle nicht über die ihres übergeordneten Ports. Deshalb wird zuerst eno1 auf 9000 gesetzt. In der getaggten Konfiguration führt dieser Port auch das ungetaggte Internetzugangsnetz; die höhere MTU gilt auch dafür. Ein privates Netzwerk auf einem eigenen Port hält beides getrennt.

Server in unterschiedlichen Rechenzentren

Ein Netzwerk gehört zur Organisation; weder Erstellungsanfrage noch Netzwerk nennen ein Rechenzentrum. Das Erweitern privater Netzwerke über Rechenzentren hinweg ist demnächst verfügbar. Bis dahin müssen alle Server eines privaten Netzwerks im selben Rechenzentrum bleiben.

Server vom Netzwerk trennen

Dienst trennen nennt die Verbindung im Pfad anhand von Server- und Segment-ID:

curl --request DELETE \
  --url https://api.serverside.com/v1/networking/virtual-networks/{networkId}/attachments/{serviceId}/{segmentId} \
  --header 'Authorization: Bearer <api-key>' \
  --header 'Idempotency-Key: <idempotency-key>'

Der Aufruf antwortet mit 202 und meldet den Fortschritt ebenso über DETACHING, bis die Zeile verschwindet oder DETACH_FAILED erreicht wird. Verwenden Sie einen neuen Schlüssel: Der Schlüssel der Verbindung dieses Segments antwortet erneut mit der Verbindung und trennt nichts. Die Serveradressen dieses Netzwerks werden in ihren Blöcken wieder frei, ihre Reverse-DNS-Einträge werden gelöscht. Verbundene Dienste auflisten zeigt weiterhin verbundene Server, eine Zeile pro Server mit allen seinen Verbindungen.

Netzwerk löschen

Virtuelles Netzwerk löschen antwortet mit 204, sobald kein Server mehr verbunden ist und es keinen IP-Block mehr enthält:

curl --request DELETE \
  --url https://api.serverside.com/v1/networking/virtual-networks/{networkId} \
  --header 'Authorization: Bearer <api-key>'

Trennen Sie zuerst alle Server und geben Sie alle IP-Blöcke des Netzwerks zurück, wie unter IP-Adressen verwalten beschrieben.

Öffentliches Netzwerk eines Servers entfernen

Ein Datenbank- oder Anwendungsserver kann sein öffentliches Netzwerk entfernen und nur über das private erreichbar bleiben. Sein öffentliches Netzwerk ist das Internetzugangsnetz, die Zeile mit managedBy SYSTEM in Virtuelle Dienstnetzwerke auflisten. Es wird über denselben Aufruf Dienst trennen mit dessen id und segmentId getrennt. Nur die API kann dies; die Cloud-Konsole entfernt ausschließlich private Verbindungen. Melden Sie sich zuerst über die private Adresse an, da SSH über die öffentliche nach der Trennung nicht mehr antwortet.

Die Serveradressen werden in den IP-Blöcken des Netzwerks wieder frei. Die Blöcke bleiben im Netzwerk und werden über das Serverabonnement abgerechnet. Ohne Adresse dort kann der Server nicht neu installiert werden: Eine Bereitstellung benötigt eine primäre IPv4-Adresse auf einem nativen Netzwerk und wird sonst mit 422 PRIMARY_IPV4_REQUIRED abgelehnt. Verbinden Sie zur Wiederherstellung das Netzwerk erneut nativ und weisen Sie dem Server eine IPv4-Adresse aus seinem Block zu; die erste IPv4-Adresse eines Servers im Netzwerk wird dort seine primäre. Nach der Trennung verschwindet das Netzwerk aus der Serverliste; Virtuelle Netzwerke auflisten zeigt es mit includeManaged=true wieder:

curl --request GET \
  --url 'https://api.serverside.com/v1/networking/virtual-networks?includeManaged=true' \
  --header 'Authorization: Bearer <api-key>'

Der Server verliert auch seine eigene Internetroute. Wir betreiben kein NAT-Gateway; Paketupdates und ausgehende Aufrufe müssen daher über einen Ihrer Server mit öffentlicher Adresse laufen, der als NAT-Router oder Proxy im privaten Netzwerk eingerichtet ist.

Fehler