Distance physique

Lorsqu'une application fait une demande à COS, elle doit parcourir une certaine distance physique.  Au fur et à mesure que cette distance augmente, la latence de la requête augmente également. Afin de réduire la latence imposée par la distance physique, il est optimal de colocaliser les ressources de calcul et le stockage d'objets dans la mesure du possible. Si votre application s'exécute dans IBM Cloud dans la région us-south , afin d'optimiser les performances, il est préférable de lire et d'écrire des données dans un compartiment également situé dans la région us-south .

Les charges de travail qui nécessitent l'accès à des données dans des endroits de grande portée peuvent bénéficier de l'utilisation d' IBM Aspera, en particulier en cas de perte de paquets importante.  Pour plus d'informations sur l'utilisation d' IBM Aspera High-Speed Transfer et de COS, consultez le guide Aspera .

Les applications à portée mondiale bénéficieront de l'utilisation d'un Content Delivery Network pour mettre en cache les actifs stockés dans COS dans des emplacements plus proches de leurs utilisateurs finaux.  Les fichiers d'origine continuent d'être hébergés dans leur compartiment, mais les copies peuvent être mises en cache à divers endroits dans le monde où les utilisateurs sont à l'origine des demandes.

Exigences en matière de résilience

Certaines charges de travail peuvent nécessiter les niveaux de résilience supplémentaires qui sont associés à l'écriture de données dans des compartiments inter-régionaux, tandis que d'autres peuvent s'appuyer sur les performances marginales accrues trouvées dans un compartiment de centre de données unique.  Chaque application doit trouver un équilibre entre une disponibilité plus élevée et des performances plus rapides.

Lors de l'utilisation d'un noeud final interrégional, il est possible de diriger le trafic entrant vers un point d'accès spécifique tout en dispersant les données dans les trois régions. Lors de l'envoi de demandes à un point d'accès individuel , il n'y a pas de reprise en ligne automatisée si cette région devient indisponible. Les applications qui dirigent le trafic vers un point d'accès à la place du geo noeud final doivent implémenter en interne la logique de basculement appropriée pour obtenir les avantages de disponibilité du stockage interrégional.

L'une des raisons de l'utilisation d'un point d'accès est de contrôler l'endroit où se produisent l'entrée et la sortie des données tout en dispersant les données dans la zone la plus large possible. Imaginez une application en cours d'exécution dans la région us-south qui souhaite stocker des données dans un compartiment interrégional aux Etats-Unis mais qui souhaite s'assurer que toutes les demandes de lecture et d'écriture restent dans la région de Dallas:

1. L'application crée un client à l'aide du noeud final https://s3.private.dal.us.cloud-object-storage.appdomain.cloud .
2. Le service COS de Dallas subit une indisponibilité.
3. L'application détecte un échec persistant lors de la tentative d'utilisation du point d'accès.
4. L'application reconnaît la nécessité de basculer vers un autre point d'accès, tel que San José.
5. L'application crée un nouveau client à l'aide du noeud final https://s3.private.sjc.us.cloud-object-storage.appdomain.cloud .
6. La connectivité est reprise et l'accès peut être réacheminé vers Dallas lorsque le service est restauré.

Pour le contraste, imaginez une autre application utilisant le noeud final interrégional américain normal:

1. L'application crée un client à l'aide du noeud final https://s3.us.cloud-object-storage.appdomain.cloud .
2. Le service COS de Dallas subit une indisponibilité.
3. Toutes les demandes COS sont automatiquement redirigées vers San José ou Washington jusqu'à ce que le service soit restauré.

Type de réseau

Le trafic dirigé vers COS peut provenir de l'un des trois réseaux suivants: public, privé ou direct. Le réseau ciblé est défini par le noeud final de service COS utilisé pour accéder à un compartiment. Alors qu'un compartiment est créé dans un emplacement unique (que ce soit dans une région, une région ou un site unique), il est toujours possible d'accéder à ce même compartiment via l'un des trois types de réseau décrits.

Le trafic public traverse l'Internet public jusqu'à ce qu'il atteigne IBM Cloud et qu'il soit acheminé vers un équilibreur de charge qui dirige le trafic vers le réseau de stockage distribué COS. Le trafic privé provient d' IBM Cloud et ne touche jamais l'Internet public.  Le trafic direct provient d'un cloud privé virtuel qui peut contenir à la fois des centres de données locaux et des ressources IBM Cloud . Cette architecture requiert IBM Direct Linket permet aux utilisateurs de se connecter directement au réseau IBM Cloud privé à partir du centre de données d'un utilisateur (à l'aide d'un proxy inverse) sans jamais toucher à l'Internet public.

Etant donné que le réseau privé élimine tous les écarts, encombrements ou vulnérabilités détectés dans l'Internet public, il est recommandé que toutes les charges de travail utilisent le réseau privé dans la mesure du possible.