Comprendre les emplacements et les régions d' IBM Cloud
Découvrez comment les sites et les régions d' IBM Cloud s sont organisés pour les déploiements de clusters, y compris les régions multizones et les régions multizones à campus unique.
Régions à zones multiples VPC
Les ressources VPC sont provisionnées dans une région, qui est un ensemble distinct de zones au sein d'une métropole. Les zones sont mappées à des centres de données distincts afin de garantir une répartition uniforme des ressources entre les
zones d'une architecture multizone. Dans l’API et l’interface de ligne de commande (CLI), les zones utilisent le nom de zone régionale dans l’API et la ligne de commande (us-south-1), mais dans la console, les zones sont désignées
par l’emplacement du centre de données (Dallas 1). Pour connaître le code du centre de données correspondant à la zone VPC et à l’emplacement, tels que us-south-1 et DAL10, consultez la section Régions multizones.
- Mumbai (
in-mum) Limitations du VPC MZR - Systèmes d'exploitation: Vous ne pouvez créer des clusters qu'à partir de la version 4.16 à Mumbai et vous ne pouvez utiliser que des nœuds de travail RHEL 9 ou RHCOS.
- Travailleurs Baremetal: Les nœuds de travail VPC baremetal ne sont pas disponibles à Mumbai.
- Chennai (
in-che) Limites VPC MZR - Systèmes d'exploitation: vous ne pouvez créer des clusters qu'à partir de la version 4.16 et ultérieure à Chennai et vous ne pouvez utiliser que des nœuds de travail RHEL 9 ou RHCOS.
- Travailleurs Baremetal: les nœuds de travail Baremetal VPC ne sont pas disponibles à Chennai.
- Montréal (
ca-mon) VPC MZR limitations - Webhooks: Seuls les webhooks qui accèdent à un service en cluster fonctionnent. Les webhooks qui accèdent directement à un site externe, hors cluster, URL sont bloqués.
- Systèmes d'exploitation: Vous ne pouvez créer des clusters qu'à partir de la version 4.16 à Montréal et vous ne pouvez utiliser que des nœuds de travail RHEL 9 ou RHCOS.
- Portworx Enterprise et Portworx Backup: La méthode d'installation par défaut pour Portworx Enterprise et Portworx Backup n'est pas encore prise en charge pour les clusters privés dans la région de Montréal. Contactez le support Portworx si vous devez installer Portworx Enterprise ou Portworx Backup dans un cluster privé à Montréal. Pour plus d'informations, voir Portworx Support.
Cette image est une représentation artistique et ne reflète pas les frontières politiques ou géographiques réelles.
| Zone géographique | Pays | Métropole | Région | Zones |
|---|---|---|---|---|
| Asie Pacifique | Australie | Sydney | au-syd | au-syd-1, au-syd-2, au-syd-3 |
| Asie Pacifique | Inde | Chenaï | in-che | in-che-1, in-che-2, in-che-3 |
| Asie Pacifique | Inde | Mumbai | in-mum | in-mum-1, in-mum-2, in-mum-3 |
| Asie Pacifique | Japon | Osaka | jp-osa | jp-osa-1, jp-osa-2, jp-osa-3 |
| Asie Pacifique | Japon | Tokyo | jp-tok | jp-tok-1, jp-tok-2, jp-tok-3 |
| Europe | Allemagne | Francfort | eu-de | eu-de-1, eu-de-2, eu-de-3 |
| Europe | Espagnol | Madrid | eu-es | eu-es-1, eu-es-2, eu-es-3 |
| Europe | Royaume-uni | Londres | eu-gb | eu-gb-1, eu-gb-2, eu-gb-3 |
| Amérique du Nord | Canada | Montréal | ca-mon | ca-mon-1, ca-mon-2, ca-mon-3 |
| Amérique du Nord | Canada | Toronto | ca-tor | ca-tor-1, ca-tor-2, ca-tor-3 |
| Amérique du Nord | Etats-Unis | Dallas | us-south | us-south-1, us-south-2, us-south-3 |
| Amérique du Nord | Etats-Unis | Washington DC | us-east | us-east-1, us-east-2, us-east-3 |
| Amérique du Sud | Brésil | São Paulo | br-sao | br-sao-1, br-sao-2, br-sao-3 |
Régions classiques
Dans ce document, le terme zone désigne différentes choses en fonction du type d'infrastructure utilisé. Pour VPC, le terme zone fait référence aux noms de zones à l'intérieur d'une MZR, comme us-south-1.
Pour l'infrastructure classique, le terme zone fait référence à un centre de données classique, tel que dal10.
Régions classiques avec plusieurs centres de données
Si vous créez un cluster classique avec plusieurs centres de données, les répliques du maître hautement Kubernetes disponible sont automatiquement réparties entre les centres de données. Vous avez la possibilité de répartir vos nœuds de travail
entre plusieurs zones classiques (centres de données) afin de protéger vos applications en cas de défaillance d’une zone. Pour déterminer si une région classique possède plusieurs centres de données, vous pouvez exécuter ibmcloud oc locations et rechercher la valeur dans la colonne Multizone Metro.
Cette image est une représentation artistique et ne reflète pas les frontières politiques ou géographiques réelles.
| Zone géographique | Pays | Métropole | Région | Zones |
|---|---|---|---|---|
| Asie Pacifique | Australie | Sydney | au-syd | syd01, syd04, syd05 |
| Asie Pacifique | Japon | Osaka | jp-osa | osa21, osa22, osa23 |
| Asie Pacifique | Japon | Tokyo | jp-tok | tok02, tok04, tok05 |
| Europe | Allemagne | Francfort | dé-fra | fra02, fra04, fra05 |
| Europe | Royaume-uni | Londres | uk-lon | lon02, lon04, lon05, lon06 |
| Amérique du Nord | Etats-Unis | Dallas | us-dal | dal10, dal12, dal13 |
| Amérique du Nord | Etats-Unis | Washington DC | us-wdc | wdc04, wdc06, wdc07 |
Régions classiques avec un centre de données
Si vous créez un cluster classique dans une région qui ne compte qu'un seul centre de données, le maître hautement disponible comprend trois répliques sur des hôtes distincts, mais n'est pas réparti dans les zones classiques.
Les régions classiques dotées d'un seul centre de données sont gérées à partir du point d'extrémité régional situé dans la région la plus proche qui prend en charge les centres de données classiques, comme mon01 à us-east ou sao01 à us-south.
Cette image est une représentation artistique et ne reflète pas les frontières politiques ou géographiques réelles.
| Zone géographique | Pays | Métropole | Région | Zone | Géré à partir de la région |
|---|---|---|---|---|---|
| Asie Pacifique | Inde | Chenaï | in-che | che01 | Asie-Pacifique Nord (ap-north, jp-tok) |
| Asie Pacifique | Singapour | Singapour | sng-mtr | sng01 | Asie-Pacifique Nord (ap-north, jp-tok) |
| Europe | France | Paris | fr-par | par01 | Europe centrale (eu-central, eu-de) |
| Europe | Pays-Bas | Amsterdam | fr-ams | ams03 | Europe centrale (eu-central, eu-de) |
| Amérique du Nord | Canada | Montréal | ca-mon | mon01 | Est des Etats-Unis (us-east) |
| Amérique du Nord | Canada | Toronto | ca-tor | tor01 | Est des Etats-Unis (us-east) |
| Amérique du Nord | Etats-Unis | San Jose | us-sjc | sjc03, sjc04 | Sud des Etats-Unis (us-south) |
| Amérique du Sud | Brésil | São Paulo | br-sao | sao01 | Sud des Etats-Unis (us-south) |
Régions Satellite
Pour afficher la liste des régions Managed from prises en charge pour les clusters Satellite, Emplacements Satellite pris en charge.
Où sont les ressources ?
L'endroit où vos ressources sont stockées dans le cluster dépend de la disponibilité du cluster. Un cluster peut être disponible dans une seule zone ou dans plusieurs zones (multizone).
Ressources dans les groupes de zones uniques
Les ressources de votre cluster restent dans le centre de données où celui-ci est déployé, mais les opérations de gestion peuvent être acheminées via un point de terminaison régional.
Les ressources de votre cluster, notamment le maître et les noeuds worker, sont situées dans la même zone dans laquelle vous avez déployé le cluster. Lorsque vous initiez des actions d'orchestration de conteneurs locaux, par exemple des commandes
oc, les informations s'échangent entre le maître et vos noeuds worker dans la même zone.
Si vous configurez d'autres ressources de cluster, telles que le stockage, la mise en réseau, la puissance de calcul ou des applications s'exécutant dans des pods, ces ressources et leurs données restent dans le centre de données où vous avez déployé votre cluster.
Lorsque vous lancez des actions de gestion de cluster, telles que l'exécution de commandes ibmcloud oc, les informations de base concernant le cluster (nom, ID, utilisateur, etc.) sont acheminées via un point
de terminaison régional et le point de terminaison global.
Ressources dans les clusters multizones
Dans les clusters multizones, les ressources du cluster sont réparties sur plusieurs sites (zones pour VPC et centres de données pour Classic) pour une plus grande disponibilité.
Les nœuds de travail sont répartis entre plusieurs zones VPC ou centres de données classiques dans la région afin d'accroître la disponibilité de votre cluster. Les Kubernetes sont également réparties dans des zones ou des centres de données
classiques. Lorsque vous lancez des actions d'orchestration de conteneurs en local, telles que des commandes oc, les informations sont échangées entre vos nœuds maîtres et vos nœuds de travail via le point de
terminaison global.
Les autres ressources du cluster, telles que le stockage, la mise en réseau, la puissance de calcul ou les applications s’exécutant dans des pods, varient quant à leur mode de déploiement dans les zones de votre cluster. Pour plus d'informations, consultez les rubriques suivantes :
- Mise en place de stockage de fichiers et stockage de blocs dans des clusters, ou choix d'une solution de stockage persistant multizone.
- Activer l'accès public ou privé à une application à l'aide d'un service d'équilibrage de charge réseau(NLB)dans un cluster.
- Gestion de trafic réseau à l'aide d'Ingress
- Augmentation de la disponibilité de votre application
Lorsque vous lancez des actions de gestion de cluster, telles que l'exécution de la commande ibmcloud oc commandes, les informations de base concernant le cluster
(nom, ID, utilisateur, etc.) sont acheminées via le point de terminaison global.