Si sus sistemas están habilitados para IPv6 o si habilitar IPv6 está en su plan de trabajo, tenemos buenas noticias: a partir de ayer y durante las próximas semanas, La web “activará el interruptor” y habilitará IPv6 para nuestra API compatible con S3. Si bien nuestra implementación de IPv6 aún no está completamente terminada (estamos implementando la implementación en forma gradual en nuestro entorno), pensamos que compartiríamos algunas de las decisiones que tomamos que afectan el rendimiento y la funcionalidad.

Hoy hablaré un poco más sobre nuestras elecciones a lo largo del camino y responderé algunas preguntas que puedan surgir sobre cómo estamos apoyando el protocolo (salte alpara eso).

Hola soy anthony

Como es la primera vez que me contactan, pensé que debería presentarme. Soy ingeniero de redes sénior en La web. El grupo de ingeniería de redes es responsable de garantizar la confiabilidad, la capacidad y la seguridad del tráfico de red, y eso incluye nuestra implementación de IPv6.

¿Qué es IPv6 y por qué lo habilitamos?

El protocolo de Internet versión 6 (IPv6) está reemplazando al protocolo de Internet versión 4 (IPv4) como estándar para direcciones IP. La mayor parte de Internet utiliza IPv4, y este protocolo ha sido confiable y resistente durante más de 20 años. Sin embargo, IPv4 tiene limitaciones que podrían causar problemas a medida que Internet se expande, a saber:.

La demanda de IPv6 sigue aumentando de forma exponencial. Un factor importante es la combinación del crecimiento continuo de la población y la cantidad de dispositivos conectados que lleva una persona determinada.El estudio sugiere que la cantidad promedio de dispositivos conectados por persona a nivel mundial fue de 2,4 en 2018 y se prevé que sea de 3,6 en 2023. Específicamente para América del Norte, el estudio sugiere 8,2 dispositivos conectados en 2018 y ¡la friolera de 13,4 en 2023! Cada dispositivo conectado a Internet necesita una dirección IP, y el espacio de direcciones finito de IPv4 simplemente ya no es suficiente. La clave para la mejora de IPv6 es la expansión del espacio de direcciones IP de 32 bits a 128 bits, lo que permite direcciones IP únicas prácticamente ilimitadas.

El soporte de IPv6 significa que nuestros clientes pueden acceder a nuestros servicios de la manera más eficiente y segura posible.

¿Por qué debería importarle que implementemos IPv6?

Hemos aprendido algunas cosas a lo largo de los años, por lo que abordamos nuestra implementación de IPv6 de manera un poco diferente a nuestra implementación de IPv4. Si usted es cliente o cliente potencial, esto es lo que eso significa para usted:

1. No es necesario que hagas nada: a diferencia de algunos de los proveedores de nube tradicionales, elegimos usar la misma URL de punto final y dejamos que el cliente elija si desea o no usar IPv6. Esto permite que cualquier sistema que ya tenga habilitado IPv6 se beneficie de inmediato. De hecho, si tus sistemas tienen habilitado IPv6 y eres un cliente de B2 que usa la API compatible con S3, es posible que ya te estés conectando con nosotros a través de IPv6.
2. Nuestra implementación está mejor configurada para escalar: debido a la forma en que decidimos asignar IP virtuales (VIP) a nuestros puntos finales de API, tenemos más flexibilidad para distribuir el tráfico de ingreso y la capacidad de agregar VIP según lo necesitemos en el futuro.
3. Rendimiento de red mejorado y administración de red más sencilla: con IPv6, simplificamos las asignaciones de IP y redujimos la necesidad de que los clientes utilicen(NAT). NAT agrega una sobrecarga de procesamiento al tráfico de red, ya que traduce direcciones IP, lo que puede generar problemas de latencia, especialmente con transferencias de datos de gran volumen. Cuanto menos tráfico tenga en NAT, mejor. En nuestro caso, no hay NAT con los flujos de datos de los clientes, independientemente de si se trata de IPv4 o IPv6. También tomamos la decisión de enrutar el tráfico antes de usar conmutadores de red, lo que ayuda a reducir el “ruido” de multidifusión de IPv6 y, en general, ayuda a mantener el “cable” más limpio.

Y así es como lo logramos.

Si un VIP pudiera hablar

Primero, un poco de historia: La web ofrece dos API: La weby elPuede obtener más información sobre nuestros, pero es importante tener en cuenta un par de diferencias cuando se trata de nuestra implementación de IPv6:

• API nativa de La web B2: las cargas se envían directamente a un almacén de La web. Como parte del proceso de carga de un archivo, se proporciona al cliente una “URL de carga”, que es una URL directa a un miembro asignado del almacén de almacenamiento. La transferencia de datos es directa desde el cliente al almacén de almacenamiento. El grupo de servidores de API solo se encarga de las descargas. Los balanceadores de carga se encargan principalmente de distribuir las llamadas a la API.
• API compatible con S3: las cargas se realizan a través de balanceadores de carga y el grupo de servidores API. Luego, nuestro grupo de servidores API distribuye los datos al almacén asignado. Las descargas son atendidas por nuestro grupo de servidores API, al igual que la API nativa de La web B2.

Estas diferencias de funcionalidad juegan un papel en cómo podemos desempeñarnosNosotros asignamosa nuestros puntos finales de API, por ejemplo, s3.us-west-004.La webb2.como api004.La webb2.com. Estos VIP son propiedad de nuestros balanceadores de carga y servidores de API (por ejemplo,). Con la API nativa B2 de La web, en realidad solo necesitamos dos VIP por clúster: uno para cargas y otro para descargas. La URL de carga que B2 Native proporciona al cliente distribuye naturalmente el flujo a través de nuestro espacio de IP. Con la API compatible con S3, dado que las cargas y descargas se manejan mediante el mismo flujo, solo necesitábamos un VIP… o eso creíamos.

Asignar una única VIP a la API compatible con S3 ha sido una buena idea durante mucho tiempo. Sin embargo, a medida que crecimos y el uso de la API compatible con S3 aumentó, descubrimos que una única VIP de la API compatible con S3 dificulta la ingeniería de tráfico de los flujos de entrada. Cuando un gran porcentaje de nuestro tráfico de entrada de la API compatible con S3 proviene de proveedores que prefieren llegar a nosotros a través de una única ruta, tener todo ese tráfico destinado a una única IP significa que no tenemos la capacidad de dirigir (es decir, realizar ingeniería de tráfico) partes del tráfico.

A principios de este año, aumentamos la cantidad de VIP de API en nuestros centros de datos con la mayor cantidad de tráfico de API compatible con S3 desde una sola IP a cuatro IP en cuatro prefijos de red diferentes (también conocidos como). Esto nos permite dirigir partes del tráfico de API compatible con S3. Esto también ayuda a distribuir los flujos para que los proveedores que tienenpara que podamos aprovecharlo mejor.

Lección aprendida: Con IPv6, estandarizamos cuatro VIP de IPv6 en cuatro prefijos diferentes con planes de crecer si/cuando sea necesario.

Ruta cuando puedas, cambia solo cuando lo necesites

Las redes de centros de datos de La web están diseñadas con un enfoque típico de “tres niveles”. Tenemos una capa de borde, una capa de agregación (también conocida como columna vertebral) y una capa de acceso (también conocida como hoja).

Con IPv4, tenemos dos “clases” de IP. Tenemos una() y una red pública. A cada máquina se le asigna una dirección IPv4 en la red privada, y solo a las máquinas que necesitan interactuar directamente con el mundo exterior se les asignan direcciones IPv4 públicas. Estas dos redes residen cada una dentro de su propia red., y la red del host está configurada para etiquetar el tráfico según sea necesario.

Dado el diseño estratificado de nuestra red, diferentes capas manejan estas VLAN. La capa de agregación actúa como enrutador para la red privada y la capa de borde actúa como enrutador para la red pública. Desde allí, se conmuta el tráfico IPv4 y, por lo tanto, simplemente tenemos dos VLAN grandes (es decir, planas) para IPv4.

Esto ha funcionado bien (y sigue funcionando bien). Un par de VLAN a las que podemos cambiar en cualquier parte del centro de datos simplifica las cosas. Los hosts pueden residir en cualquier parte dentro del centro de datos y las IP pueden asignarse desde los mismos grupos. Sin embargo, con el tráfico IPv4 que se conmuta en todo el centro de datos, el dominio de transmisión plano (por lo tanto, el nivel de ruido de transmisión de fondo) aumenta con el tiempo a medida que crece el entorno. En nuestro centro de datos más grande (en términos de espacio de IP), hemos tenido que aumentar la cantidad de hosts.Tamaño. Con IPv6, queríamos mejorar esto.

La primera decisión que tomamos fue eliminar el concepto de espacio de direcciones públicas y privadas con IPv6. Cada host obtiene una dirección y todas las direcciones son públicas (si el rol lo requiere). Los firewalls y las listas de control de acceso de los conmutadores existentes ya permiten o deniegan el tráfico según corresponda (lo que también ocurre con nuestras redes IPv4).

Esto no solo simplifica las asignaciones de IP, sino que también reduce la necesidad de(NAT). Tenemos muchos hosts que no están orientados al público, pero que necesitan comunicarse con el mundo exterior por diversos motivos. A medida que podemos trasladar cada vez más comunicaciones con servicios externos a IPv6, esto reduce la carga de los recursos que hemos implementado simplemente para gestionar NAT.

La segunda decisión que tomamos fue enrutar hasta la capa de conmutador de acceso. A cada conmutador de acceso se le asigna una dirección IPv6 de una parte de este bloque y a los hosts conectados a un conmutador determinado se les asigna una dirección IPv6 de una parte de este bloque.

Esto ayuda a reducir el “ruido” de multidifusión de IPv6 y, en general, ayuda a mantener el “cable” más limpio. Esto hace que las implementaciones de host sean un poco más complicadas, ya que para asignarle a un host determinado una dirección IPv6 de la red correcta, uno debe saber a qué conmutador está conectado el host. Además, si el personal del centro de datos necesita mover los hosts para equilibrar o consolidar la energía, será necesario cambiar la dirección IPv6 si la nueva ubicación hace que el host se conecte a un conmutador diferente.

Lección aprendida: incluso con la complejidad añadida, la ruta cuando se puede, cambiar solo cuando es necesario, funciona bien para nuestro entorno.

¿Que sigue?

Aún tenemos más trabajo por delante. Actualmente estamos investigando formas de admitir la API nativa de La web B2 con IPv6, así como también la copia de seguridad de La web Computer. Estén atentos para obtener más información al respecto.

Preguntas frecuentes

¿Cuál es la diferencia entre IPv4 y IPv6?

La diferencia clave entre las versiones del protocolo es que IPv6 tiene mucho más espacio de direcciones. La notación de direcciones IPv6 consta de ocho grupos de cuatro dígitos hexadecimales separados por dos puntos, por ejemplo, 2001:db8:1f70:999:de8:7648:3a49:6e8, aunque existen métodos para abreviar esta notación. A modo de comparación, la notación IPv4 consta de cuatro grupos de dígitos decimales separados por puntos, por ejemplo, 198.51.100.1.

La capacidad ampliada de direccionamiento de IPv6 permitirá contar con los billones de nuevas direcciones de Internet necesarias para soportar la conectividad de una amplia gama de nuevos dispositivos, como teléfonos, electrodomésticos y vehículos.

¿Cómo puedo utilizar IPv6 con B2 Cloud Storage?

Actualmente, solo la API compatible con La web S3 admite IPv6. Para utilizar direcciones IPv6 con B2 Cloud Storage y la API compatible con S3, no es necesario realizar ningún cambio.

¿Seguirán funcionando las direcciones IPv4?

Sí, las direcciones IPv4 seguirán siendo compatibles tanto con la API nativa B2 como con la API compatible con S3 por el momento. No tenemos ningún plan explícito para dejar de usar IPv4 en este momento.

¿Qué pasará si sigo usando IPv4?

Nada. IPv4 seguirá siendo compatible por el momento.

¿Es IPv6 mejor/más seguro que IPv4?

No es más seguro. Los clientes que se comunican con nosotros a través de IPv4 o IPv6 tendrán conexiones igualmente seguras. Nuestras API utilizan el mismo cifrado TLS sólido independientemente de si se utiliza IPv4 o IPv6. Algunos clientes pueden notar una mejora en el rendimiento si IPv6 les permite evitar la traducción de direcciones de red (NAT).

¿Existe un costo adicional por utilizar IPv6?

No.

Estoy usando La web Computer Backup. ¿Necesito hacer algún cambio?

No. IPv6 solo es relevante para La web B2 Cloud Storage. No es necesario que realices ningún cambio en tu cuenta de La web Computer Backup.