VPS en Amsterdam: qué importa al elegir ubicación

Por qué elegir un servicio VPS en Amsterdam

Elegir un servicio VPS en Amsterdam es, ante todo, una decisión de red. Amsterdam es uno de los principales puntos de interconexión de Europa, donde se encuentran numerosas redes independientes y entregan el tráfico directamente entre sí. Un servidor en esa área metropolitana suele llegar al Reino Unido, los países nórdicos, Alemania, Francia y los países del Benelux mediante rutas cortas y con pocas redes intermedias.

Ese es el argumento. El resto de esta guía consiste en comprobar si se aplica a sus usuarios, porque no se aplica a todos. Amsterdam es una buena opción predeterminada para una base de clientes distribuida por el noroeste de Europa. Es una mala elección si la mayor parte del tráfico procede de Varsovia, Estambul, São Paulo o Toronto, porque un buen peering en los Países Bajos no acorta la distancia hasta esos lugares.

Qué es realmente un punto de intercambio de Internet

Un punto de intercambio de Internet, o IXP, es una infraestructura de conmutación compartida. Las redes independientes alquilan un puerto en ella, se conectan una vez y pueden intercambiar tráfico directamente con los demás miembros. En Ámsterdam, el más conocido es AMS-IX, el Amsterdam Internet Exchange. No es el único punto de intercambio de la ciudad, y su número no es lo importante para usted.

Para entender por qué un punto de intercambio cambia la latencia, debe conocer las dos formas en que un paquete atraviesa distintas redes. La primera es el tránsito: usted paga a una red más grande para que transporte su tráfico al resto de Internet. La segunda es el peering: dos redes acuerdan intercambiar tráfico directamente, normalmente sin que haya pagos en ninguna dirección. Cada red es un sistema autónomo, o AS: una red con su propio número y su propia política de enrutamiento.

Las rutas de tránsito se eligen tanto por las relaciones comerciales como por la geografía. Un paquete de un servidor situado en una ciudad europea a un cliente de banda ancha situado en otra puede viajar legítimamente hasta una tercera ciudad, cambiar de red allí y regresar. No hay ningún problema. La ruta es simplemente el resultado de las relaciones comerciales y de la política de enrutamiento. En un punto de intercambio, las dos redes pueden entregar el paquete localmente. Así, la ruta es más corta, intervienen menos redes y hay menos puntos en los que puede aparecer congestión.

Esta es la parte que suele omitirse. Que haya un punto de intercambio en la ciudad no significa que su VPS esté conectado a él. Lo importante es la propia red de su proveedor: qué proveedores de tránsito contrata, a qué puntos de intercambio está conectado, si establece peering con las redes de consumidores y de telefonía móvil que utilizan sus usuarios y qué capacidad tiene con cada una. Dos servidores situados en el mismo edificio pueden tener rutas de salida muy diferentes. Pida al proveedor su número de AS y búsquelo en PeeringDB, donde las redes publican las instalaciones y los puntos de intercambio en los que están presentes. También puede obtener directamente los números de AS de una ruta activa, como se muestra en la sección de medición siguiente.

Ámsterdam o Frankfurt: decídalo según sus usuarios, no según el mapa

Esta es la decisión real a la que se enfrentan muchos lectores, y ambas ciudades son importantes puntos de interconexión. Frankfurt alberga DE-CIX y suele ser la opción habitual para Europa central, oriental y sudoriental, así como para las rutas hacia Viena, Varsovia, Praga y Oriente Medio. Ámsterdam ofrece una buena ubicación para el Reino Unido, Irlanda, Escandinavia y el Benelux, y para el tráfico que utiliza los cables submarinos que llegan al noroeste de Europa. Considere estas características como tendencias, no como mediciones. El enrutamiento cambia, los proveedores modifican sus upstreams y el peering de su proveedor es más específico que cualquier generalización basada sólo en la ciudad.

Por tanto, decídalo con sus propios datos.

1. Anote dónde están realmente sus usuarios. Los registros de acceso de su servidor web, sus análisis o su lista de clientes ya contienen esta información.
2. Pondere esa lista según un criterio relevante, como los ingresos o las cuentas activas, en lugar de usar recuentos brutos de visitas que los bots pueden inflar.
3. Alquile el plan más pequeño en cada ciudad candidata durante un mes y mida el rendimiento desde conexiones de usuarios reales hacia ambas.
4. Compare los datos que recopiló, no las cifras de una página de marketing.

Antes de dedicar una semana a esto, tenga en cuenta una limitación importante. Para una base de usuarios situada en Europa occidental, la diferencia entre dos grandes ciudades europeas bien conectadas suele ser menor que la latencia que añade su propia aplicación. Una página que ejecuta diez consultas a la base de datos de forma consecutiva paga el tiempo de ida y vuelta diez veces, por lo que el patrón de consultas puede costar más que la elección de la ciudad. Mida también la aplicación. Las mismas preguntas planteadas desde el otro lado se explican en la guía para elegir un VPS en Frankfurt, y el factor decisivo suele ser algo poco llamativo, como qué ubicación ofrece el tamaño de plan y el disco que necesita.

Cómo medir usted mismo la latencia hasta Ámsterdam

Ejecute estas pruebas desde la conexión que utilizan sus usuarios, o desde un punto lo más cercano posible. La fibra de la oficina no representa una conexión móvil en Manchester.

En Debian o Ubuntu, instale primero las herramientas.

sudo apt update && sudo apt install -y mtr-tiny traceroute curl

Empiece con un recuento de viajes de ida y vuelta.

ping -c 20 ams.example.com

El resumen final aparece identificado como rtt min/avg/max/mdev. El valor avg es el tiempo habitual de ida y vuelta en milisegundos, y mdev indica cuánto varía; es el jitter. Lea el porcentaje de pérdida de paquetes en el mismo bloque. La pérdida en el destino es un problema real. La pérdida que aparece en un salto intermedio, con valores correctos en todos los saltos posteriores, normalmente no es un problema, porque los routers asignan una prioridad baja a las respuestas sobre paquetes dirigidos a ellos mismos.

Después, examine la ruta.

mtr --report --report-wide --show-ips --aslookup --report-cycles 100 ams.example.com

Cada línea representa un salto y --aslookup muestra el número de AS, por lo que puede ver qué redes atraviesa el paquete y dónde sale de su proveedor. Busque el salto en el que aumenta el tiempo de ida y vuelta y permanece alto en todos los saltos posteriores: ahí se añade el retraso. Si mtr termina porque no puede abrir un raw socket, ejecútelo con sudo. Algunas redes asignan una prioridad baja a ICMP o lo descartan, así que mida también la forma en que se conectan sus usuarios, mediante TCP y contra el puerto que ofrece el servicio.

sudo mtr --tcp --port 443 --report --report-cycles 100 ams.example.com

Después, separe la red del servidor.

curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://ams.example.com/

Cada valor indica los segundos transcurridos desde que comenzó la solicitud, así que debe leer las diferencias entre ellos. connect menos dns equivale aproximadamente a un viaje de ida y vuelta: el handshake de TCP. tls menos connect corresponde al handshake de TLS (transport layer security), que requiere más viajes de ida y vuelta, por lo que aumenta más rápido con la distancia que cualquier otro valor de la línea. ttfb menos tls corresponde principalmente al tiempo que tarda el servidor en procesar la solicitud. Esta separación explica por qué curl es mejor que ping para decidir una compra. Un total alto con una diferencia ttfb pequeña significa que el equipo está lejos. Una diferencia ttfb grande con una conexión rápida significa que el equipo está cerca y que la aplicación es lenta.

La latencia también cambia según la hora, porque la congestión varía. Tome muestras durante todo el día en lugar de confiar en una sola ejecución.

while true; do date -Is; ping -c 10 -q ams.example.com | tail -2; sleep 300; done | tee latency.log

La red es una mitad de la compra. El disco y la CPU son la otra mitad, y un servidor bien ubicado en un nodo sobresuscrito sigue funcionando con lentitud. Por eso, ejecute el plan de prueba mediante un benchmark adecuado de VPS antes de comprometerse por un año.

Residencia de datos de la UE en términos sencillos

La residencia de datos es la ubicación física donde se almacenan y procesan los datos. Los Países Bajos forman parte de la Unión Europea y del Espacio Económico Europeo, por lo que un servidor en Ámsterdam mantiene sus bytes en infraestructura de la UE. Esto resuelve una cuestión de ubicación, pero la ubicación es sólo uno de los factores de una cuestión de cumplimiento.

El RGPD (Reglamento General de Protección de Datos) no prohíbe que los datos personales salgan de la UE. Establece condiciones para la transferencia y también afecta a las demás empresas que procesan datos en su nombre. Por tanto, la pregunta útil no es «¿está el servidor en la UE?». Es «¿dónde termina cada copia de estos datos?».

Ahí es donde normalmente falla una afirmación de residencia. El VPS está en Ámsterdam y la base de datos está alojada en él. Después, las copias de seguridad se envían a un almacenamiento de objetos en otra región, los registros de la aplicación se transmiten a un servicio de búsqueda alojado, las trazas de error se envían a un proveedor de monitorización, el correo transaccional sale a través de un tercero y el texto de los usuarios se publica en una API para resumirlo. Cada una de esas operaciones trasladó datos personales a algún lugar. Un requisito de ubicación se aplica a todas ellas, no sólo a la máquina que eligió deliberadamente.

Mantenga separados los dos motivos, porque conducen a diseños diferentes. Si un contrato, un regulador o un cliente exige infraestructura de la UE, se trata de un requisito de cumplimiento. Debe estar documentado y puede obligarle a permanecer dentro de una región. Si quiere que el servidor esté cerca de sus usuarios para que las páginas carguen más rápido, se trata de un requisito de latencia y puede llevarle a añadir regiones. Usar términos de cumplimiento para justificar una decisión de rendimiento le impedirá responder después a cualquiera de las dos preguntas.

Pregunte al proveedor quién puede acceder a la máquina, dónde se encuentra el personal de soporte, a qué legislación está sujeta la empresa y si algún subencargado del tratamiento está fuera del EEE. Obtenga la respuesta en un acuerdo de tratamiento de datos, porque eso es lo que solicita un auditor; un ticket de soporte no lo sustituye. Para conocer el método completo, el marco de residencia redactado para las transferencias de datos canadienses se aplica directamente: enumere los datos, enumere cada encargado que los toca, documente la regla que debe cumplir y elija la ubicación al final. Esto describe las preguntas que debe hacer, no constituye asesoramiento jurídico.

Qué no soluciona elegir Ámsterdam

• La distancia al resto de usuarios. Las señales viajan por la fibra aproximadamente a dos tercios de la velocidad de la luz en el vacío, y la ruta del cable siempre es más larga que la línea recta. Por tanto, un usuario en Singapur paga el coste de la distancia, independientemente de la ciudad europea que elija.
• Una aplicación demasiado comunicativa. Cada solicitud que espera a la anterior vuelve a pagar el tiempo de ida y vuelta.
• El riesgo de una sola región. Un VPS en una sola ciudad pertenece a un único dominio de fallo, y una buena interconexión no evita las consecuencias de eliminar el volumen equivocado.
• Hardware sobresuscrito. Un nodo con mucha carga en una ciudad bien conectada sigue siendo un nodo con mucha carga.

Qué ocurre si mis usuarios están en más de un continente

La regla es sencilla: coloque el servidor en el punto de presencia más cercano a sus usuarios. Si sus usuarios están repartidos entre varios continentes, una ubicación intermedia ofrece una experiencia lenta a ambos grupos, porque ninguno está cerca de ella.

Hay dos respuestas prácticas. Coloque todo lo que se pueda almacenar en caché detrás de una CDN (red de distribución de contenido), de modo que el origen permanezca en Amsterdam mientras las imágenes, las hojas de estilo, los scripts y las páginas almacenadas en caché se sirven desde un nodo cercano a cada usuario. También puede ejecutar un segundo servidor en la otra región y resolver el problema de los datos de forma deliberada, mediante réplicas de lectura o una replicación cuyo retraso haya medido y documentado. Ambas opciones cuestan más que un solo servidor. Ese es el coste real de tener una audiencia dividida.

Si una parte importante de su tráfico procede de Norteamérica, un VPS en Toronto atenderá a esos usuarios mejor que cualquier ciudad europea. Para los usuarios de Sudamérica, un VPS alojado en Brasil evita un viaje de ida y vuelta transatlántico en cada solicitud. Elegir Amsterdam es correcto cuando sus usuarios están en Europa, sobre todo en el norte y el oeste. Esa es una afirmación concreta, y los comandos anteriores le permiten comprobarla con su propio tráfico.

FAQ

¿Es más rápida una VPS en Ámsterdam que una en Fráncfort?

Para sus usuarios, posiblemente. Ambas ciudades son puntos importantes de interconexión, por lo que la diferencia depende de dónde estén sus usuarios y con qué redes establezca interconexión cada proveedor, no del nombre de la ciudad. Ámsterdam suele ser adecuada para el Reino Unido, Irlanda, Escandinavia y el Benelux, mientras que Fráncfort suele ser adecuada para Europa central y oriental. Contrate el plan mensual más pequeño en cada ubicación y ejecute mtr --report --aslookup y una prueba de tiempos con curl -w desde conexiones de usuarios reales durante una semana antes de decidir.

¿Alojar mi servicio en Ámsterdam hace que cumpla el RGPD?

No. Coloca los datos en infraestructura de la UE, lo que responde a una cuestión. El cumplimiento también abarca su base jurídica, sus encargados del tratamiento, sus copias de seguridad, sus registros y cada servicio de terceros al que envíe datos personales. Un servidor en Ámsterdam que envía trazas de error a un proveedor fuera del EEE sigue transfiriendo esos datos fuera del EEE. La ubicación es la parte sencilla, y es ahí donde muchas personas dejan el análisis.

¿Qué es AMS-IX y afecta a mi VPS?

AMS-IX es el punto de intercambio de Internet de Ámsterdam, una infraestructura de conmutación compartida donde redes independientes se conectan e intercambian tráfico directamente, en lugar de pagar a un proveedor de tránsito para que lo transporte entre ellas. El tráfico llega a su VPS a través de su proveedor. Un punto de intercambio en la ciudad le ayuda cuando su proveedor está presente en él y establece interconexión con las redes que utilizan sus usuarios. Solicite el número de AS del proveedor y compruebe en PeeringDB con qué redes establece interconexión ese número.

¿Cómo pruebo la red hasta una VPS antes de pagar un año?

Contrate primero el plan mensual más pequeño. Ejecute ping -c 20 para medir el tiempo de ida y vuelta y la pérdida de paquetes. Después, ejecute mtr --report --report-wide --aslookup --report-cycles 100 para ver por qué redes pasa la ruta. A continuación, haga una prueba con curl -w contra una página real mediante HTTPS para distinguir la distancia de la velocidad del servidor. Repita las pruebas a distintas horas, porque la congestión varía durante el día, y ejecútelas desde las conexiones que utilizan sus usuarios, no sólo desde su oficina. Conserve el registro para comparar valores medidos en lugar de basarse en una impresión.