Cloud resources – A shared

story
Shared resources even after boundaries and delimitation
bring own share of complexities. I will touch few here.

In the previous posts we talked about shared compute, storage and

network. Now lets try and dig a bit deeper to understand some of the side
effects.

We all know sharing of resource happens in one of three domains (time,

frequency and space).

• Time domain where some kind of scheduler allocates resource based

on time slices. Common for compute and other peripheries.
• Frequency domain where N resources are allocated in
compartmentalized manner to m consumers and time window is
insignificant to allocation strategy. Commonly observed for sharing of
different CPU cores and HW threads as vCPU.
• Space domain when one resource are divided into several parts and
allocated in partitioned manner. This is very typical for storage and
network and easy to visualize. Happens all the time in *NIX systems
where different users have home directories set with access controls
in place.

For volatile memory and others I have seen combination being utilized.

We have also observed some new domains/dimensions of sharing, ex

energy envelop and money in a online real time competitive bidding
domain of sharing. Your instances or access to shared/rented resources
can be evicted if it has already consumed more energy than provisioned
for, or some other participants to system are offering more money for
them.

All of this sharing brings

1. Noisy neighbours: Even if we see resources allocated to one
VM/instance, these are still represented by single underlying hardware. If
4-5 VMs share same hard disk and perform simultaneous IO to disk, the
IOPS performance is bound to drop and thus noise has reduced the
performance. This is one of the reasons why disk performance in cloud
seldom reaches the promised levels and smart cloud provides are
charging for IOPS.

Noisy neighbours are also referred as chatty neighbours, the ones

generating excess network traffic. If network partitioning is not very well
controlled chatty neighbours can throttle your network throughput as all
of the VMs are sharing same physical NICs.

2. Hot neighbours: CPU throttling happens at CPU level, not just core or
hyper thread level. As it is common to have more than one VM sharing
CPU (each getting allocation of cores and called as vCPU) quite possible
that one VM can run the cores at consistently high frequencies, increasing
temperature of CPU and thus resultant throttling for all cores. I have
observed this as root cause for some of the unexplained process restart.

Hot neighbour effect is managed and controlled to some extent via energy
based billing. Billing is still just a mechanism to reduce the possibility.

There are ways in which effects of sharing can be reduced but not fully
eliminated. Does it mean we can not implement real time systems using
cloud infrastructure? Well that depends on what your requirement of real
time is. If you need to be within millisecond for signal/event/timer
handling it can be done easily. If you require sub millisecond or say
microsecond guaranteed response times, highly unlikely on standard
cloud instances available. You most probably need proprietary cloud
which comes with different sharing policies.