Reducing Latency

You can reduce the latency between your different instances 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 instances closer, you need to launch them with the same account in the same Availability Zone (AZ). But as the Cloud is virtualized, for a single AZ there are different physical sites. So even if the instances are in the same AZ they might be on physically separated. Using the same account enhances the changes of the instances to be on the same AZ.

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

You can also reduce latency by working in a single subnet. By default, thanks to a network enhancement, instances within a same subnet can communicate with one another without any security group rules required. This enables to reduce overall latency between two instances and avoid issues for specific protocols, like those used by Microsoft Windows. If you want to have further security between two instances (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 Availability Zone or in a Single Subnet

  • In a single Availability Zone

You can launch your instances in the same AZ and with the same account. For more information, see Creating / Launching Instances.

  • In a single Subnet in a Virtual Private Cloud

You can launch instances in the same subnet. For more information about the subnets in a VPC, see Creating and Managing Subnets in Your VPC.

Placing instances closer

On the same cluster

You can force your instances 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 instances 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 an Instance 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 instance 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 instances to be on the same hypervisor using one of the two following tags:

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

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

osc.fcu.attract_server

Distributes instances 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 an Instance 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 instance 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, instances within a same subnet can communicate with one another without any security group rules required. This enables to reduce overall latency between two instances and avoid issues for specific protocols, like those used by Microsoft Windows. If you want to have further security between two instances (for example, one in a DMZ and one in an internal network), place them in different subnets or disable this feature.