Configurar redes virtuales mediante la API

Dos servidores desplegados se incorporan a su propia red privada, así que cada petición que acepte un {serviceId} se ejecuta una vez por servidor.

1. Elegir un ID de VLAN

Cada red necesita un localVlanId de 11 a 4094 que no use otra red de la organización. Obtener disponibilidad de VLAN enumera las etiquetas ocupadas como data.usedVlanIds e indica la siguiente libre como data.nextFreeVlanId, con el intervalo en minVlanId y maxVlanId:

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

2. Crear la red

Crea una red virtual con la etiqueta del paso 1 como 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
}
'

La API no elige una etiqueta por ti, así que localVlanId se incluye en cada creación. La respuesta es 201 con la red, cuyo data.id es el {networkId} de los siguientes pasos. Una red privada no recibe subred ni puerta de enlace de nosotros. Sus servidores usan un intervalo privado que eliges tú; esta guía usa 10.20.0.0/24. Las tramas que etiquetes dentro con tus propios ID de VLAN 802.1Q llegan a los demás servidores con sus etiquetas intactas.

3. Elegir el segmento de cada servidor

Un servidor se une a una red en un segmento: uno de sus puertos o dos agregados. Obtener capacidades de red enumera los puertos físicos en data.availableInterfaces, cada uno con su id, name, macAddress y el segmentId al que pertenece, con isConfigured activado en un puerto que ya está en un segmento. data.availableBondingGroups enumera los puertos que pueden agregarse.

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

Funcionan dos configuraciones:

• Etiquetada, en el segmento existente. El segmento que transporta la red de acceso a Internet sin etiquetar también transporta la red privada, etiquetada con su localVlanId. No se usa un segundo cable.
• Nativa, en un segundo puerto. Un puerto libre se convierte en su propio segmento y la red privada llega ahí sin etiquetar.

Para la configuración nativa, Crear segmento acepta los interfaceIds que incluir: un puerto libre o dos de una entrada de availableBondingGroups para formar un enlace agregado LACP, que el host llama bond0, bond1, etc. Un enlace agregado usa exactamente dos puertos, uno en cada conmutador de la pareja, con el mismo número en ambos.

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>"
  ]
}
'

La respuesta es 201 con el nuevo segmento y su segmentId.

4. Conectar los servidores

Conecta el servicio una vez por servidor. Para la configuración etiquetada, segmentId es el que transporta la red de acceso a Internet del servidor, que Listar redes virtuales del servicio muestra en la fila de esa red, e isNative es false. Para la nativa, es el nuevo segmento del paso 3, con 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
}
'

Un 202 significa que el cambio está en camino a los conmutadores y su cuerpo contiene el status del cambio, APPLYING, y la hora de aceptación como since. Reenviar la petición con la misma Idempotency-Key responde 202 con el cambio original. Sin clave, la misma conexión enviada una vez establecida responde 204 y no cambia nada.

5. Esperar al cambio

Dos lugares informan del progreso. Obtener estado del servicio contiene networkChange, con status APPLYING o FAILED y la hora de inicio como since. Mientras se aplica, aparece un objeto degraded si un conmutador sigue sin aceptar el cambio: consecutiveFailures, la última failureCategory y nextAttemptAt para el siguiente intento automático, o null cuando el cambio espera a nuestro equipo. Un cambio terminado como FAILED se ha revertido en el conmutador y su failureCategory indica la causa.

Listar redes virtuales del servicio muestra el status propio de cada conexión: ATTACHING y después ATTACHED o ATTACH_FAILED.

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

Un servidor acepta un cambio de red a la vez, así que su siguiente conexión, desconexión o cambio de segmento espera a que termine este.

6. Configurar el sistema operativo

Una red etiquetada necesita una interfaz VLAN en el servidor, sobre la interfaz que transporta el segmento. Obtener servicio bare metal la identifica: cada entrada de interfaces es un segmento y su name es la interfaz que un despliegue escribe en el host, el nombre del puerto o bond0, bond1, etc. para un enlace agregado, cuyo bondMode muestra LACP. Tras cambiar los segmentos, interfaces muestra la configuración que escribirá el siguiente despliegue y el host conserva sus interfaces anteriores hasta reinstalarlo.

En Linux con iproute2, donde el name del segmento es eno1 y la variable de shell VLAN contiene la etiqueta de la red:

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

Asigna 10.20.0.2/24 al segundo servidor y ambos se comunican por la red privada. Estos comandos no persisten tras reiniciar; pon los mismos ajustes en la configuración de red de la distribución (netplan en Ubuntu, /etc/network/interfaces en Debian, NetworkManager en sistemas de la familia RHEL) para conservarlos.

Las redes privadas transportan tramas jumbo con MTU de 9000 y todos los servidores de la red necesitan el mismo valor en su interfaz privada:

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

Linux no establece la MTU de una interfaz VLAN por encima de la del puerto donde reside, por eso el puerto principal eno1 pasa primero a 9000. En la configuración etiquetada ese puerto también transporta la red de acceso a Internet sin etiquetar y la MTU mayor también se le aplica; una red privada en un puerto propio mantiene ambas separadas.

Servidores en distintos centros de datos

Una red pertenece a la organización y ni la petición de creación ni la red indican un centro de datos. Pronto estará disponible extender una red privada entre centros de datos. Hasta entonces, mantén todos los servidores de una red privada en el mismo centro de datos.

Desconectar un servidor de la red

Desconectar servicio identifica la conexión en la ruta mediante el ID del servidor y el del segmento:

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>'

Responde 202 e informa del progreso del mismo modo, pasando por DETACHING hasta que desaparece la fila o llega a DETACH_FAILED. Usa una clave nueva: la que conectó la red en ese segmento vuelve a responder con la conexión y no desconecta nada. Las direcciones que tenía el servidor en esa red vuelven libres a sus bloques y se eliminan sus registros de DNS inverso. Listar servicios conectados muestra los servidores aún conectados, una fila por servidor con cada conexión.

Eliminar la red

Eliminar red virtual responde 204 cuando no hay servidores conectados ni bloques de IP en la red:

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

Desconecta primero todos los servidores y devuelve los bloques de IP de la red como explica Gestionar direcciones IP.

Eliminar la red pública de un servidor

Un servidor de base de datos o aplicaciones puede prescindir de su red pública y seguir accesible solo por la privada. Su red pública es la de acceso a Internet, la fila con managedBy SYSTEM en Listar redes virtuales del servicio, y se desconecta mediante la misma llamada Desconectar servicio con el id y segmentId de esa red. Solo la API puede hacerlo, ya que la consola elimina únicamente conexiones privadas. Inicia sesión primero por la dirección privada, porque SSH a la pública deja de responder al desconectarla.

Las direcciones del servidor vuelven libres a los bloques de IP de la red y los bloques permanecen en ella, facturados en la suscripción del servidor. Sin una dirección allí no se puede reinstalar: un despliegue necesita una IPv4 principal en una red nativa y de lo contrario se rechaza con 422 PRIMARY_IPV4_REQUIRED. Para restaurarla, conecta de nuevo la red como nativa y asigna al servidor una IPv4 de su bloque, ya que la primera IPv4 que recibe en una red se convierte en la principal allí. Tras desconectarla, la red desaparece de la lista del servidor; Listar redes virtuales vuelve a mostrarla con includeManaged=true:

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

El servidor también pierde su propia ruta a Internet y no operamos ninguna puerta de enlace NAT, así que las actualizaciones de paquetes y llamadas salientes deben pasar por uno de tus servidores que conserve una dirección pública, configurado como router NAT o proxy en la red privada.

Errores