THUNDER: A Cloud Architecture To Reduce Costs and Organizational

Overhead For Nonprofits

Gabriel Jacob Loewen

Western Kentucky UniversityMarch 27, 2015

Outline

• Introduction• Background and Motivation• Challenge Questions• Proposed Architecture Design• THUNDER Middleware Implementation• Preliminary Results• Future Work• Conclusion• Timeline

ServerCloud Interface

…

Introduction

• What is cloud computing?– 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 cost-efficient.

Client

Client

Compute

Compute Service

Compute Service

ComputeStorage Service

Other Services

No formal definition! [1]

1.Grandison, T., E. M. Maximilien, S. Thorpe, and A. Alba

ServerCloud InterfaceCompute

Compute Service

Compute Service

ComputeStorage Service

Other Services

Introduction

Infrastructure as a service(IaaS) [2-4]

Lowest service level in cloud stack.

Provides compute, storage, and networking services using hardware virtualization.

Platform as a service(PaaS) [2-4]

Software as a service(SaaS) [2-4]

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) locally2. Read the XML specification for the virtual machine

image3. 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 share2. Provide persistent storage to THUNDER

Proposed Architecture Design

Head node (Zeus):1. Facilitate communication between services2. Provide interface between clients and services

(apache)3. Manages IP addresses with DHCP4. Acts as a metadata aggregator

Client devices:1. Connect to the THUNDER head node2. Use the web interface to request resources3. Connect to the resource in the web browser4. Use the resource

Image Repo

Storage Node

Compute Node 2

Compute Node 1

Proposed Architectural Design

• How does each server communicate with the head node?– Middleware!

Head Node

Thunder Middleware

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 re-

authentication.

Subnet 2

Subnet 1

Head Node (10.10.1.1)

Compute Node 1 (10.10.2.1)

Compute Node 2 (10.10.2.2)

Head Node Replica (10.10.1.2)

DHCP Failover

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:

{ “_HOST_”: “10.10.0.2”, “Command”: “Instantiate”, “Username”: “Test”, “Image”: “Xubuntu-Medium”}

Response:

{ “_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

3. 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