Reducing Latency

You can reduce the latency between your different virtual machines (VMs) to use them at their best capacity.

The latency is the delay between an action and the time at which it is effective. The less latency you have, the fastest you can manage your resources.
You can reduce this latency by placing the VMs closer, you need to create them with the same account in the same Subregion. But as the Cloud is virtualized, for a single Subregion there are different physical sites. So even if the VMs are in the same Subregion they might be on physically separated. Using the same account enhances the changes of the VMs to be on the same Subregion.

You can ensure to reduce latency to a minimum by placing the VMs closer; in a same physical site. You can use tags to place your VMs in a same cluster or hypervisor.

You can also reduce latency by working in a single Subnet. By default, thanks to a network enhancement, VMs within a same Subnet can communicate with one another without any security group rules required. This enables to reduce overall latency between two VMs and avoid issues for specific protocols, like those used by Microsoft Windows. If you want to have further security between two VMs (for example, one in a DMZ and one in an internal network), place them in different Subnets or disable this feature.

Working in a Single Subregion or in a Single Subnet

  • In a single Subregion

You can create your VMs in the same Subregion and with the same account. For more information, see Creating VMs.

  • In a single Subnet in a Net

You can create VMs in the same Subnet. For more information about the Subnets in a Net, see Creating and Managing Subnets in Your Net.

Placing Instances Closer

On the Same Cluster

You can force your VMs to be on the same cluster using one of the following two tags:

Tag Name Behavior Value Usable at boot time with user datas

osc.fcu.attract_cluster

Distributes VMs with the same tag on the same UCS

Free

Yes

osc.fcu.attract_cluster_strict

Alias osc.fcu.attract_cluster but fails with an InsuficientCapacity error if request is not enforceable

Free

Yes

For more information about how to use those tags, see Configuring a VM with User Data and OUTSCALE Tags.

If an error occurs when using osc.fcu.attract_cluster_strict tag, use this command in the user data header at the boot of the VM following this syntax:

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

On the Same Hypervisor

You can force your VMs to be on the same hypervisor using one of the two following tags:

  • The number VMs you can put on the same hypervisor depends on the type of the VMs and the hypervisor capacity.

  • As the VMs are on the same hypervisor, in case of a crash, all of your VMs will be down.
Tag Name Behavior Value Usable at boot time with user datas

osc.fcu.attract_server

Distributes VMs with the same tag on the same physical server

Free

Yes

osc.fcu.attract_server_strict

Alias osc.fcu.attract_server but fails with an InsufficientCapacity error if the request is not enforceable

Free

Yes

For more information about how to use those tags, see Configuring a VM with User Data and OUTSCALE Tags.

If an error occurs when using osc.fcu.attract_server_strict tag, use this command in the user data header at the boot of the VM following this syntax:

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

Forcing an attract_server automatically forces an attract_cluster.

Security Group Isolation Within Subnets

By default, thanks to a network enhancement, VMs within a same Subnet can communicate with one another without any security group rules required. This enables to reduce overall latency between two VMs and avoid issues for specific protocols, like those used by Microsoft Windows. If you want to have further security between two VMs (for example, one in a DMZ and one in an internal network), place them in different Subnets or disable this feature.

Export to PDF