Magellan Final Report - Office of Science - U.S. Department of Energy

Magellan Final Report
MB/s
Virident tachIOn (400GB)
Fusion IO ioDrive Duo (Single Slot, 160GB)
OCZ Colossus (250 GB)
1200
1000
800
600
400
200
TMS RamSan 20 (450GB)
Intel X-25M (160GB)
Percentage of Peak Write Bandwidth
90%
80%
70%
60%
50%
40%
30%
20%
10%
30% Capacity 50% Capacity 70% Capacity 90% Capacity
0
0 10 20 30 40 50
Minutes
0%
Virident tachIOn
(400GB)
TMS RamSan 20
(450GB)
Fusion IO ioDrive
Duo (Single Slot,
160GB)
Intel X-25M
(160GB)
OCZ Colossus (250
GB)
(a) Transient Random-Write Bandwidth Degradation (90% Capacity)
(b) Steady-State Random-Write Bandwidth Degradation
Figure 9.22: Graphs illustrating the degradation in the IO bandwidth to various flash devices under a
sustained random write workload. The graph on the left shows the transient behavior while the graph on
the right compares the steady-state performance of the devices while varying the utilized capacity.
9.5 Applications
We worked closely with our users to help them port their applications to cloud environments, to compare
application performance with existing environments (where applicable), and to compare and contrast performance
with other applications. In this section, we outline select benchmarking results from our applications.
9.5.1 SPRUCE
As mentioned in Chapter 3, the Magellan staff collaborated with the SPRUCE team to understand the
implications of using cloud resources for urgent computing. In this context, some benchmarking was performed
to measure the allocation delay (i.e., the amount of time between a request for some number of
instances and the time when all requested instances are available) as the size of the request increases. These
benchmarking experiments were conducted on three separate cloud software stacks on the ALCF Magellan
hardware: Eucalyptus 1.6.2, Eucalyptus 2.0 and OpenStack. The results of these benchmarks revealed some
unexpected performance behaviors. First, Eucalyptus version 1.6.2 offered very poor performance. The
allocation delay linearly increased as the size of the request increased. This was unexpected given that in
the benchmark experiments, the image being created was pre-cached across all the nodes of the cloud, so
one would expect that the allocation delays would have been much more stable, given that the vast majority
of the work is being done by the nodes and not the centralized cloud components. Also, as the number
of requested instances increased, the stability of the cloud decreased. Instances were more likely to fail to
reach a running state and the cloud also required a resting period in between trials in order to recover. For
example, for the 128-instance trials, the cloud needed to rest for 150 minutes in between trials, or else all of
the instances would fail to start. In Eucalyptus version 2.0, the performance and stability issues appeared
to be resolved. The allocation delays were much flatter (as one would expect), and the resting periods were
no longer required. OpenStack, in comparison, offered shorter allocation delays, the result of an allocation
process which utilized copy-on-write and sparse files for the disk images. As the images were pre-cached
on the nodes, this resulted in significantly shorter allocation delays, particularly for smaller request sizes.
However, the plot of the allocation delay was again not as flat as might be expected (see Figure 9.23).
75