This document outlines a project to deploy a production-ready OpenStack compute and block storage environment using Ubuntu, OpenStack, and SolidFire technologies. Key goals were to provide a reference architecture emphasizing predictable performance, quality of service, and ease of use. The deployment utilized Nova, Cinder, Swift and Ubuntu Charms. Results included an estimated 600-1200 virtual machines and 210-415 IOPS per application instance on a SolidFire cluster. Lessons learned included the ongoing challenges of OpenStack deployment and the need to adjust defaults and be prepared for configuration changes between releases.

1. Deploying a best of breed OpenStack
Compute & Block Storage Cloud
…with ass-kicking VMs to show for it
Adam Carter David Medberry John Griffith
Director of Product Management Cloud Engineer PTL Cinder
adam@solidfire.com david.medberry@canonical.com john.griffith@solidfire.com

2. Agenda • What did we set out to accomplish
• How did we get there?
– Compute (Nova) environment
– Block Storage (Cinder) environment
– Deployment via Ubuntu Charms
• What do we have to show for it?
• What we learned along the way
• Where to from here
• Q&A

3. What did we • A blueprint
• A reference architecture
set out to – For any OpenStack deployer looking to stand
accomplish? up a production-ready compute (Nova) and
block storage (Cinder) environment
• For use cases such as
– IaaS
– DBaaS
• Emphasizing the attributes of
– Predictable performance
– Quality-of-Service
– Ease of Use

4. OpenStack Compute Environment
• Folsom on Ubuntu 12.04 via the Ubuntu Cloud
archive
– http://ubuntu-cloud.archive.canonical.com/
• Multi-node nova-compute and distinct nova cloud
controller
• Messaging node with Horizon, Keystone, mysql,
and Rabbitmq
• Swift

5. Deployment
• Juju/Charms
• Applying a generic load to a 'local' volume is not an
ideal Juju use case, but it can be done
• Customizing an image may solve the same problem
more efficiently if network bandwidth is an issue by
pre-loading all packages and applications
• And co-locating an Ubuntu mirror in your cloud is
always a win (aka our colo bandwidth was not
designed for so many instances)

6. OpenStack Block Storage Environment
• Cinder Block Storage Service
• Folsom version and drivers straight from Ubuntu
packages
• Volume provisioning and iSCSI CHAP via
SolidFire OpenStack driver
• Control QoS attributes outside of OpenStack into
the SolidFire API (today)

7. 2x Dell PowerConnect 5548 2x Force10 S4810
(10Gbps Stack) (80Gbps Stack, 2x40)
ER
MAST
PSU
SYS
FAN
S4810P
Stat
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 LNK 47 ACT
PWR
1
RS-232
us
52 60
Reset
M RPS Fan
Q SF P+
Stack No.
LNK ACT LNK ACT LNK ACT
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 1 2 1 2 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 56 LNK ACT
Stacking HDMI SFP+ Ethernet
SFP+
ER
MAST
PSU
SYS
FAN
Stat
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 LNK 47 ACT
PWR
S4810P 1
us
RS-232
Reset
M RPS Fan
52 60
Stack No. Q SF P+
LNK ACT LNK ACT LNK ACT
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 1 Stacking HDMI 2 1 SFP+ 2 LNK ACT
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 56 Ethernet
SFP+
What do we SolidFire Five Node
have to show
1
2
1
2
SF3010 Cluster
1
2
1
2
1
2
for it?
5x Dell C1100 Chassis
2x E5645, 96GB RAM
OpenStack Management
Services:
Swift, Keystone, Glance,
Cinder, Nova Scheduler
and API
2x Intel QSSC-S4R
(Management Traffic)
Ubuntu 12.04 LTS
OpenStack Compute
(Storage I/O)
(Nova)
1GbE
10GbE
Connections are per-chassis (Redundant
connections for each chassis & network)
KVM Hypervisor
OpenStack Cinder Block Storage Service
Estimated 600 – 1200 Virtual Machines, 210 – 415 IOPs per Application Instance

8. Where to from • Blueprint for Grizzly Cinder (this week)
here • Finish the reference architecture and
publish it
• Cinder development in Grizzly

9. What we learned along the way…
• Setting up an OpenStack cluster still challenging…even for
people with significant experience with Essex – things
have moved, options have changed
• Critical to know the key scaling factors and your use model
• Examine all the nova and cinder defaults and adjust for
your use case
• Be prepared if you update from Essex to Folsom (or
Folsom to Grizzly) to encounter config changes you may
not know about
• Be ready to fix bugs as you go with a new release (we
found Folsom, SolidFire, and Juju bugs as we went)

10. DEMO
TIME…

11. Any Questions?
SolidFire Canonical
Booth E7 Ubuntu Booth
@Solidfire @Canonical