Distanza fisica

Quando un'applicazione effettua una richiesta a COS, deve attraversare una certa quantità di distanza fisica.  Con l'aumentare di questa distanza, aumenterà anche la latenza della richiesta. Per ridurre la latenza imposta dalla distanza fisica, è ottimale co - localizzare le risorse di calcolo e l'archivio oggetti, laddove possibile. Se la tua applicazione è in esecuzione in IBM Cloud nella regione us-south , per ottimizzare le prestazioni sarebbe meglio leggere e scrivere i dati in un bucket che si trova anche nella regione us-south .

I carichi di lavoro che richiedono l'accesso ai dati in luoghi di ampia portata potrebbero trarre vantaggio dall'utilizzo di IBM Aspera, soprattutto se si verifica una perdita di pacchetti significativa.  Ulteriori informazioni sull'uso di IBM Aspera High-Speed Transfer e COS sono disponibili nella guida Aspera .

Le applicazioni con portata globale trarranno vantaggio dall'utilizzo di una Content Delivery Network per memorizzare nella cache gli asset archiviati in COS in ubicazioni più vicine agli utenti finali.  I file originali continuano ad essere ospitati nel loro bucket, ma le copie possono essere memorizzate nella cache in varie ubicazioni nel mondo in cui gli utenti stanno originando le richieste.

Requisiti di resilienza

Alcuni carichi di lavoro potrebbero richiedere ulteriori livelli di resilienza forniti con la scrittura dei dati nei bucket tra regioni, mentre altri potrebbero fare affidamento sulle prestazioni marginali aumentate rilevate in un bucket di un singolo data center.  Ogni applicazione deve trovare un equilibrio tra maggiore disponibilità e prestazioni più rapide.

Quando si utilizza un endpoint Cross Region, è possibile indirizzare il traffico in entrata a uno specifico punto di accesso pur disperdendo i dati in tutte e tre le aree. Quando si inviano richieste a un singolo punto di accesso non vi è alcun failover automatico se tale regione diventa non disponibile. Le applicazioni che indirizzano il traffico a un punto di accesso invece che all'endpoint geo devono implementare internamente la logica di failover appropriata per ottenere i vantaggi di disponibilità dell'archiviazione tra regioni.

Un motivo per utilizzare un punto di accesso è controllare dove si verificano l'ingresso e l'uscita dei dati, pur disperdendo i dati nell'area più ampia possibile. Immagina un'applicazione in esecuzione nella regione us-south che desidera memorizzare i dati in un bucket interregionale degli Stati Uniti ma desidera garantire che tutte le richieste di lettura e scrittura rimangano nell'area di Dallas:

1. L'applicazione crea un client utilizzando l'endpoint https://s3.private.dal.us.cloud-object-storage.appdomain.cloud .
2. Il servizio COS a Dallas subisce un'interruzione.
3. L'applicazione rileva un errore persistente nel tentativo di utilizzare il punto di accesso.
4. L'applicazione riconosce la necessità di eseguire il failover su un punto di accesso diverso, come San Jose.
5. L'applicazione crea un nuovo client utilizzando l'endpoint https://s3.private.sjc.us.cloud-object-storage.appdomain.cloud .
6. La connettività viene ripresa e l'accesso può essere reinstradato a Dallas quando il servizio viene ripristinato.

Per contrasto, immagina un'altra applicazione che utilizza il normale endpoint interregionale degli Stati Uniti:

1. L'applicazione crea un client utilizzando l'endpoint https://s3.us.cloud-object-storage.appdomain.cloud .
2. Il servizio COS a Dallas subisce un'interruzione.
3. Tutte le richieste COS vengono automaticamente reinstradate a San Jose o Washington fino a quando il servizio non viene ripristinato.

Tipo di rete

Il traffico diretto a COS può provenire da una delle tre reti: Pubblico, Privato o Diretto. La rete di destinazione è definita dall'endpoint del servizio COS utilizzato per accedere a un bucket. Mentre un bucket viene creato in una singola ubicazione (che sia tra regioni, regionale o sito singolo), è ancora possibile accedere allo stesso bucket tramite uno qualsiasi dei tre tipi di rete descritti.

Il traffico pubblico attraversa l'Internet pubblico finché non raggiunge IBM Cloud e viene instradato a un programma di bilanciamento del carico che indirizza il traffico nella rete di archiviazione distribuita COS. Il traffico privato ha origine all'interno di IBM Cloud e non tocca mai Internet pubblico.  Il traffico diretto ha origine in un VPC (Virtual Private Cloud) che potrebbe contenere sia i data center locali che risorse IBM Cloud . Questa architettura richiede IBM Direct Linke consente agli utenti di connettersi direttamente alla rete IBM Cloud privata da un data center dell'utente (utilizzando un proxy inverso) senza mai toccare l'Internet pubblico.

Poiché la rete privata elimina tutte le variazioni, la congestione o le vulnerabilità rilevate nell'Internet pubblico, si consiglia che tutti i carichi di lavoro utilizzino la rete privata quando possibile.