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 |
---|---|---|---|
|
Distributes instances with the same tag on the same UCS |
Free |
Yes |
|
Alias |
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:
|
Tag Name | Behavior | Value | Usable at boot time with user datas |
---|---|---|---|
|
Distributes instances with the same tag on the same physical server |
Free |
Yes |
|
Alias |
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 |
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.