IBM Cloud Docs
Topología de red

Topología de red

Hay muchas formas de conectarse a IBM Cloud® Object Storage y la elección del punto final puede tener un impacto en el rendimiento.

Distancia física

Cuando una aplicación realiza una solicitud a COS, necesita cruzar alguna cantidad de distancia física.  A medida que aumente esta distancia, también aumentará la latencia de la solicitud. Para disminuir la latencia impuesta por la distancia física, es óptimo coubicar los recursos de cálculo y el almacenamiento de objetos cuando sea posible. Si la aplicación se ejecuta en IBM Cloud en la región us-south , para optimizar el rendimiento sería mejor leer y escribir datos en un grupo que también se encuentra en la región us-south .

Las cargas de trabajo que requieren acceder a datos en lugares de gran alcance pueden beneficiarse de la utilización de IBM Aspera, especialmente si hay una pérdida de paquetes significativa.  Puede encontrar más información sobre cómo utilizar IBM Aspera High-Speed Transfer y COS en la guía Aspera .

Las aplicaciones con alcance global se beneficiarán de la utilización de una Content Delivery Network para almacenar en memoria caché los activos almacenados en COS en ubicaciones más cercanas a sus usuarios finales.  Los archivos originales se siguen alojando en su grupo, pero las copias se pueden almacenar en la memoria caché en varias ubicaciones del mundo donde los usuarios están originando solicitudes.

Requisitos de resiliencia

Algunas cargas de trabajo pueden requerir los niveles adicionales de resiliencia que se proporcionan con la escritura de datos en grupos de varias regiones, mientras que otras pueden basarse en el mayor rendimiento marginal que se encuentra en un grupo de un único centro de datos.  Cada aplicación necesita encontrar un equilibrio entre una mayor disponibilidad y un rendimiento más rápido.

Cuando se utiliza un punto final entre regiones, es posible dirigir el tráfico de entrada a un punto de acceso específico mientras se siguen dispersando datos entre las tres regiones. Al enviar solicitudes a un punto de acceso individual no hay migración tras error automatizada si dicha región deja de estar disponible. Las aplicaciones que dirigen el tráfico a un punto de acceso en lugar del geo punto final deben implementar internamente la lógica de migración tras error adecuada para conseguir las ventajas de disponibilidad del almacenamiento entre regiones.

Una razón para utilizar un punto de acceso es controlar dónde se produce la entrada y salida de datos mientras se siguen dispersando los datos en el área más amplia posible. Imagine una aplicación que se ejecuta en la región us-south que desea almacenar datos en un grupo entre regiones de EE.UU. pero desea asegurarse de que todas las solicitudes de lectura y escritura permanecen en el área de Dallas:

  1. La aplicación crea un cliente utilizando el punto final https://s3.private.dal.us.cloud-object-storage.appdomain.cloud .
  2. El servicio COS en Dallas sufre una parada.
  3. La aplicación detecta una anomalía persistente al intentar utilizar el punto de acceso.
  4. La aplicación reconoce la necesidad de migrar tras error a un punto de acceso diferente, como San José.
  5. La aplicación crea un nuevo cliente utilizando el punto final https://s3.private.sjc.us.cloud-object-storage.appdomain.cloud .
  6. La conectividad se reanuda y el acceso se puede redireccionar a Dallas cuando se restaura el servicio.

Por el contrario, imagine otra aplicación que utiliza el punto final entre regiones de EE.UU. normal:

  1. La aplicación crea un cliente utilizando el punto final https://s3.us.cloud-object-storage.appdomain.cloud .
  2. El servicio COS en Dallas sufre una parada.
  3. Todas las solicitudes COS se redireccionan automáticamente a San José o Washington hasta que se restaure el servicio.

Tipo de red

El tráfico dirigido a COS puede proceder de una de las tres redes: Pública, Privada o Directa. La red de destino está definida por el punto final de servicio COS utilizado para acceder a un grupo. Mientras se crea un grupo en una única ubicación (ya sea entre regiones, regional o único sitio), todavía es posible acceder a ese mismo grupo a través de cualquiera de los tres tipos de red descritos.

El tráfico público atraviesa la Internet pública hasta que llega a IBM Cloud y se direcciona a un equilibrador de carga que dirige el tráfico a la red de almacenamiento distribuido COS. El tráfico privado se origina en IBM Cloud y nunca toca el Internet público.  El tráfico directo se origina en una nube privada virtual que puede contener centros de datos locales y recursos de IBM Cloud . Esta arquitectura requiere IBM Direct Linky permite a los usuarios conectarse directamente a la red de IBM Cloud privada desde el centro de datos de un usuario (utilizando un proxy inverso) sin tocar nunca la Internet pública.

Debido a que la red privada elimina cualquier variación, congestión o vulnerabilidades encontradas en la Internet pública, se recomienda que todas las cargas de trabajo utilicen la red privada siempre que sea posible.