Réduire la latence

Vous pouvez réduire la latence entre différentes instances pour les utiliser à leur capacité optimale.

La latence est le délai entre l’action et le moment où celle-ci est effective. Moins vous avez de latence, plus vous pouvez gérer rapidement vos ressources.

Vous pouvez réduire la latence en plaçant les instances plus près les unes des autres, vous devez lancer celles-ci avec le même compte et dans la même Availability Zone (AZ). Comme le Cloud est virtuel, pour une seule AZ, il y a différents sites physiques. Même si les instances sont dans la même AZ, elles peuvent être séparées physiquement. Utiliser le même compte augmente les changes que les instances soient sur la même AZ.

Vous pouvez vous assurer de réduire la latence au minimum en plaçant les instances plus près les unes des autres ; sur le même site physique. Vous pouvez utiliser des tags pour placer vos instances sur le même cluster ou hyperviseur.

Vous pouvez également réduire la latence en ne travaillant qu’avec un seul subnet. Par défaut, grâce à une amelioration du réseau, les instances dans un même subnet peuvent communiquer entre elles sans aucune règle de security group nécessaire. Ceci vous permet de réduire la latence entre deux instances et éviter des conflits avec des protocoles spécifiques, tels que ceux utilisés par Microsoft Windows. Si vous voulez une sécurité accrue entre vos instances, (par exemple, une sur un DLZ et l’autre sur un réseau interne), placez les dans des subnets différents ou désactivez cette fonctionnalité.

Travailler dans une seule Availability Zone ou dans un seul subnet

  • Dans une seule Availability Zone

Vous pouvez lancer des instances dans la même AZ et avec le même compte. Pour en savoir plus, voir Créer / Lancer des instances.

  • Dans un seul subnet d’un Virtual Private Cloud (VPC)

Vous pouvez lancer des instances dans le même subnet. Pour en savoir plus sur les subnets dans un VPC, voir Créer et gérer des subnets dans un VPC.

Rapprocher les instances

Sur le même cluster

Vous pouvez forcer vos instances à être sur le même cluster en utilisant l’un de ces deux tags :

Nom du tag Comportement Valeur Utilisable au boot avec les user data

osc.fcu.attract_cluster

Distribue les instances avec le même tag sur le même UCS.

Libre

Oui

osc.fcu.attract_cluster_strict

Alias osc.fcu.attract_cluster mais échoue avec une erreur "InsuficientCapacity" si la requête ne peut être forcée.

Libre

Oui

Pour en savoir plus à propos de comment utiliser ces tags, voir Configurer une instance avec les user data et les tags OUTSCALE.

Si une erreur apparaît lors de l’utilisation du tag osc.fcu.attract_cluster_strict, utilisez cette commande, lors du boot, dans le header des user data suivant cette syntaxe :

-----BEGIN OUTSCALE SECTION-----
tags.osc.fcu.attract_cluster_strict=myclusterofvms_1
-----END OUTSCALE SECTION-----

Sur le même hyperviseur

Vous pouvez forcer vos instances à être sur le même hyperviseur en utilisant l’un de ces deux tags :

  • Le nombre d’instances que vous pouvez placer sur le même hyperviseur dépend du type d’instances et de la capacité de l’hyperviseur.

  • Comme les instances sont placées sur le même hyperviseur, en cas de crash, toutes les instances seront impactées.
Nom du tag Comportement Valeur Utilisable au boot avec les user data

osc.fcu.attract_server

Distribue les instances avec le même tag sur la même slide.

Libre

Oui

osc.fcu.attract_server_strict

Alias osc.fcu.attract_server mais échoue avec une erreur "InsuficientCapacity" si la requête ne peut être forcée.

Libre

Oui

Pour en savoir plus à propos de comment utiliser ces tags, voir Configurer une instance avec les user data et les tags OUTSCALE.

Si une erreur apparaît lors de l’utilisation du tag osc.fcu.attract_server_strict, utilisez cette commande, lors du boot, dans le header des user data suivant cette syntaxe :

-----BEGIN OUTSCALE SECTION-----
tags.osc.fcu.attract_server_strict=myclusterofvms_1
-----END OUTSCALE SECTION-----

Forcer un attract_server force automatiquement un attract_cluster.

Isolation du security group à l’intérieur d’un subnet

Par défaut, grâce à une amélioration du réseau, les instances au sein d’un même subnet peuvent communiquer entre elles sans règles de security group requises. Ceci permet de réduire la latence entre deux instances et d’éviter des problèmes avec des protocoles spécifiques, comme ceux utilisés par Microsoft Windows. Si vous souhaitez mettre en place un plus grande sécurité entre deux instances (par exemple une en DMZ et une autre dans un réseau interne), placez-les dans des subnets différents ou désactiver cette fonctionnalité.