THUNDER: A Cloud Architecture To
Reduce Costs and Organizational
Overhead For Nonprofits
Gabriel Jacob Loewen
Western Kentucky University
March 27, 2015
Outline
•
•
•
•
•
•
•
•
•
Introduction
Background and Motivation
Challenge Questions
Proposed Architecture Design
THUNDER Middleware Implementation
Preliminary Results
Future Work
Conclusion
Timeline
Introduction
• What is cloud computing?
No formal definition! [1]
– A set of service oriented architectures, which allow
users to access a number of resources in a way
that is scalable, elastic, on-demand, and costefficient.
Compute
Service
Compute Service
Compute
Compute
Other Services
Client
…
Storage
Service
Cloud Interface
Server
Client
1.Grandison, T., E. M. Maximilien, S. Thorpe, and A. Alba
Introduction
Software as a service
(SaaS) [2-4]
Platform as a service
(PaaS) [2-4]
Infrastructure as a service
(IaaS) [2-4]
Compute
Service
Server
Compute Service
Compute
Storage
Service
Compute
Cloud Interface
Other Services
Lowest service level in
cloud stack.
Provides compute,
storage, and networking
services using hardware
virtualization.
2. Edmonds, A., S. Johnston, T. Metsch, and G. Mazzaferro
3. Liu, F., J. Tong, J. Mao, R. Bohn, J. Messina, M. Badger, and D.
4. Canonical Group Ltd.
Introduction
Typical General Purpose Private Cloud Architecture (Eucalyptus
[5])
5. Eucalyptus Systems
Introduction
• Private cloud architectures are great
– Provides an organization with local resources.
– Lowered privacy concerns when compared to
public vendors (Amazon, Google, etc.)
– Organization has total control over data.
• Introduce challenges
– Most provide general purpose solutions. Difficult
to deploy and maintain. Usability is sacrificed for
flexibility.
– Many different configuration options. Requires
either trial and error or expertise.
Introduction
• Vertical architecture
– Designed for one specific purpose and/or market
• e-Healthcare (Health records, healthcare tools, etc.) [6]
• Education (Collaboration tools, e-books, e-learning, etc.) [7]
• Computing with dumb terminals (Virtual machines, storage,
etc.)
– Implementation is focused on a subset of the cloud
stack
• e-Healthcare and Education SaaS.
• Computing with dumb terminals IaaS.
– PaaS possible, depending on the organizations needs.
6. Delgado, M.
7. Stein, S., J. Ware, J. Laboy, and H. E. Schaffer.
Introduction
• Why is this necessary?
– Organizations that could benefit from private cloud
computing might be discouraged [7].
• Fear of new technology.
• Insufficient technical experience.
• Inability to hire qualified personnel.
– Current research in vertical cloud architectures
focus on how they benefit particular markets, but
not on reducing complexity and increasing
usability.
7. Stein, S., J. Ware, J. Laboy, and H. E. Schaffer.
Proposed Architecture Design
• THUNDER
– Recursive backronym.
• THUNDER Helps Underfunded Nonprofits Distribute
Electronic Resources.
– Vertical architecture aimed at satisfying the
computational requirements of struggling nonprofit
organizations.
– Infrastructure as a Service.
• Provides computational infrastructure for thin clients.
– Thick clients possible, but not as cost/power efficient.
• Provides virtual machines, storage, and maybe some
platforms.
Proposed Architecture Design
Client devices connecting to the
cloud.
Head node. Manages cloud
interface and facilitates inter-node
communication.
Service nodes. Provide compute
and storage services.
Proposed Architecture Design
Compute Nodes (Thor):
1. Mount virtual machine repository (CIFS share) locally
2. Read the XML specification for the virtual machine
image
3. Invoke the hypervisor (KVM or XEN)
4. Pass the virtual machine metadata to the virtualization
API (libvirt)
5. Provide virtualization to THUNDER
Storage Nodes (Indra):
1. Manage CIFS share
2. Provide persistent storage to THUNDER
Proposed Architecture Design
Head node (Zeus):
1. Facilitate communication between services
2. Provide interface between clients and services
(apache)
3. Manages IP addresses with DHCP
4. Acts as a metadata aggregator
Client devices:
1. Connect to the THUNDER head node
2. Use the web interface to request resources
3. Connect to the resource in the web browser
4. Use the resource
Proposed Architectural Design
• How does each server communicate with the
head node?
– Middleware!
Head Node
Compute
Node 1
Compute
Node 2
Thunder Middleware
Storage
Node
Image
Repo
THUNDER Middleware Implementation
• Non-persistent socket connections between
each node and the head node.
– Head node service bound to static port.
– Every other node uses a random available port.
• Each node associates itself with a logical
group (logical clusters)
– Allows messages to be sent to entire groups, or
individual nodes.
THUNDER Middleware Implementation
Logical representation of communication structure. Each group is
comprised of many nodes. New nodes can be added or removed to
groups, and entirely different groups can be defined dynamically.
THUNDER Middleware Implementation
• Automatic node registration
– Multicast-based node registration and reauthentication.
DHCP Failover
Head Node
(10.10.1.1)
Head Node Replica
(10.10.1.2)
Subnet 1
Subnet 2
Compute Node 1
(10.10.2.1)
Compute Node 2
(10.10.2.2)
THUNDER Middleware Implementation
• Pre-shared key used in authentication
between nodes.
– Challenge/response mechanism
1. Challenge is sent from head node to service node.
2. Service node encrypts message with pre-shared key,
and sends it back to the head node.
3. Head node decrypts message and compares with
original.
• Traffic is not encrypted.
– Decreased overhead, but may pose some security
vulnerabilities.
– Will be investigated further.
THUNDER Middleware Implementation
• JSON Objects are generated by the sender
and consumed by the receiver.
Sent Message:
Response:
{
{
“_HOST_”: “10.10.0.2”,
“Command”: “Instantiate”,
“Username”: “Test”,
“Image”: “Xubuntu-Medium”
“_HOST_”: “10.10.0.5”,
“Command”: “Instantiate”,
“Username”: “Test”,
“IP”: “10.10.1.58”
“Domain”: “XubAF983C”
}
}
User Interface
• Websockets are used to establish a direct
connection between the web browser and the
cloud
– HTML5 canvas provides dynamic content
• Deployment of new nodes is based on PXE
and preseeding
• Two interfaces. One for administration and
one for general use.
Cost Savings
• Can THUNDER help to cut power costs?
Our preliminary study of THUNDER power utilization to support
twenty workstations shows a potential power cost savings of 50%
compared to a traditional set of workstations.
Cost Savings
• What about startup costs?
10
Traditional
workstations have a
lower startup cost
when the organization
requires fewer than
ten workstations.
However, THUNDER
has a lower startup
cost when the
organization requires
ten or more.
Cost Savings
• What is the big picture?
As the organization
grows, THUNDER
continues to help to
decrease hardware
costs compared to
traditional
workstations.
Cost Savings
• At what point do the cost savings plateau?
By increasing the
number of clients, we
see that the percent
savings of THUNDER
over traditional
workstations plateaus
at around 50%.
Survey Results
• THUNDER seems to be easier to use
compared to other solutions.
Survey Results
Survey Results
Survey Results
Conclusion
• User interface is not radically different than
other architectures.
– Simple, intuitive, easy to use.
• Virtual machines may be accessed via the
web browser.
– RDP server runs on the virtual machine. RDP
client displays to HTML5 canvas.
Conclusion
• THUNDER helps to support computing
infrastructure for underfunded and non-profit
organizations.
– Cost reduction up to 50% when compared to more
traditional workstation deployments.
– Reduced difficulty in deployment when compared
to other cloud architectures.
• Survey results show that users prefer
deploying THUNDER over both Openstack
and Eucalyptus.
References
1. Grandison, T., E. M. Maximilien, S. Thorpe, and A. Alba (2010). Towards a
formal definition of a computing cloud. Services, IEEE Congress on 0, 191–192.
2. Edmonds, A., S. Johnston, T. Metsch, and G. Mazzaferro (2010, March). Open
Cloud Computing Interface - Core and Models. Technical report, OCCI.
3. Liu, F., J. Tong, J. Mao, R. Bohn, J. Messina, M. Badger, and D. Leaf (2011).
Nist cloud computing reference architecture. Technical report, U.S. Department
of Commerce.
4. Canonical Group Ltd. (2010). An introduction to cloud computing. Technical
report, Canonical.
5. Eucalyptus Systems (2013). Eucalyptus cloud. www.eucalyptus.com/.
Accessed: 4/12/2013.
6. Delgado, M. (2011). The evolution of health care it: Are current u.s. privacy
policies ready for the clouds? In Services (SERVICES), 2011 IEEE World
Congress on, pp. 371–378.
7. Stein, S., J. Ware, J. Laboy, and H. E. Schaffer (2013). Improving k-12
pedagogy via a cloud designed for education. International Journal of
Information Management 33(1), 235 – 241.
References
8. Raspberry Pi Foundation (2013). Raspberry pi. http://www.raspberrypi.org/.
Accessed: 4/12/2013.
9. Doelitzscher, F., A. Sulistio, C. Reich, H. Kuijs, and D. Wolf (2011, January).
Private cloud for collaboration and e-learning services: from iaas to saas.
Computing 91(1), 23–42.
10. Cardellini, V. and S. Iannucci (2012). Designing a flexible and modular
architecture for a private cloud: a case study. In Proceedings of the 6th
international workshop on Virtualization Technologies in Distributed Computing
Date, VTDC ’12, pp. 37–44.
11. Linux Terminal Server Project (2013). Ltsp. http://www.ltsp.org/. Accessed:
4/12/2013.
12. Vereecken, W., L. Deboosere, P. Simoens, B. Vermeulen, D. Colle, C. Develder,
M. Pickavet, B. Dhoedt, and P. Demeester (2009). Energy efficiency in thin
client solutions. In A. D. Doulamis, J. Mambretti, I. Tomkos, and T. A.
Varvarigou (Eds.), Networks for Grid Appli- cations - Third International ICST
Conference, GridNets 2009, Athens, Greece, September 8-9, 2009, Revised
Selected Papers, Volume 25, pp. 109–116. Springer.
Publications
Journal Articles
1. G. Loewen, J. Galloway, J. Robinson, and S. Vrbsky. THUNDER: Helping
Underprivileged NPO’s Distribute Electronic Resources. Journal of Cloud
Computing Advances and Applications (JoCCASA). SpringerOpen Publishers,
2013.
2. M. Galloway, G. Loewen, and S. Vrbsky. Deploying a cost efficient
geographically distributed private cloud architecture. The International Journal of
Cloud Computing. Inderscience Publishers, 2012.
3. J. Galloway, J. Robinson, G. Loewen, and S. Vrbsky. On Power Aware Load
Consolidation in Private IaaS Cloud Architectures. The International Journal of
Research and Reviews. Science Academy Publisher, United Kingdom, 2012.
Publications
Conference Proceedings
1. G. Loewen, M. Galloway, S. Vrbsky. On The Performance of Apache Hadoop in
a Tiny Private IAAS Cloud. In Proceedings of the 10th International Conference
on Information Technology : New Generations (ITNG 2013). Las Vegas, NV,
April 2013.
2. G. Loewen, M. Galloway, S. Vrbsky. A Graphical Interface for Private Cloud and
Cluster Management. In Proceedings of the ACM Southeast Conference
(ACMSE ’13). Savannah, GA. 2013.
Workshops
1. G. Loewen, M. Galloway, S. Vrbsky. Designing a Middleware API for Building
Private IaaS Cloud Architectures. The First International Workshop on
Resource Management of Cloud Computing (CCRM). In Proceedings of the
IEEE International Conference on Distributed Computing Systems (ICDCS).
Philadelphia, PA. July 2013.
Thank You