Final Dissertation Defense Gabriel Jacob Loewen Committee Members Dr Susan Vrbsky Committee Chair Dr Monica Anderson Dr John Lusth Dr Ashraf Saad Dr Jingyuan Zhang Outline ID: 637002
Download Presentation The PPT/PDF document "THUNDER: A Private Cloud Architecture De..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
THUNDER: A Private Cloud Architecture Designed for High Usability
Final Dissertation DefenseGabriel Jacob Loewen
Committee Members:
Dr. Susan
Vrbsky
, Committee Chair
Dr. Monica Anderson
Dr. John
Lusth
Dr. Ashraf
Saad
Dr.
Jingyuan
ZhangSlide2
Outline
IntroductionBackground and MotivationChallenge QuestionsArchitecture DesignCost
Savings Model
Empirical Study on Deployment
Load Balancing and
Consolidation
User
Interface
Future Work
ConclusionSlide3
Server
Cloud 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
Compute
Storage Service
Other Services
No formal definition!
[1]
Grandison
, T., E. M.
Maximilien
, S. Thorpe, and A. AlbaSlide4
Server
Cloud Interface
Compute
Compute Service
Compute Service
Compute
Storage 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]
Edmonds, A., S. Johnston, T.
Metsch
, and G.
Mazzaferro
Liu, F., J. Tong, J. Mao, R. Bohn, J. Messina, M.
Badger
Canonical Group Ltd.Slide5
IntroductionPrivate cloud computing is great
Provides an organization with local resources.Organization has total control over data.Lowered privacy concerns when compared to public vendors (Amazon, Google, etc.)
Introduce challenges
Most
p
rovide general purpose solutions. Difficult to deploy and maintain. Usability is sacrificed for flexibility.Many different configuration options. Requires either trial and error or expertise.Slide6
Introduction
Vertical cloud computingDesigned for one specific purpose and/or markete-Healthcare (Health records, healthcare tools, etc.) [6]Education (Collaboration tools, e-books, e-learning, etc.)
[7]
Services are virtualized on top of some underlying infrastructure
Base operating system, hypervisor(s), guest(s)
If money is not a concern, commercial systems availableVMware v-Sphere, etc.Delgado, M.Stein, S., J. Ware, J. Laboy, and H. E. Schaffer.Slide7
IntroductionResearch goals
Understand the challenges faced by small organizationsDevelop a new cloud architecture that addresses the challengesEvaluate the architecture from an empirical perspectiveDo people like it? Is it useful?
Evaluate the architecture from a technical perspectiveSlide8
Background and Motivation
Virtual Computing Lab at NCSU [7]Provided 9th and 10th grade students with mathematics software.
Private Cloud for Collaboration
[9]
SaaS
, IaaS, and PaaS services to support e-Learning.Designing a Modular Cloud Architecture [10]Best practices in cloud architecture design.Comparison between cloud design and LTSP[11] cluster.Energy Efficiency in Thin Client Solutions [12]Developed a model for relating energy and performance in clouds with thin clients.Stein, S., J. Ware, J. Laboy, and H. E. Schaffer.Doelitzscher, F., A. Sulistio, C. Reich, H. Kuijs, and D. Wolf Cardellini, V. and S. Linux Terminal Server ProjectVereecken, W., et al.Slide9
Background and Motivation
MotivationOrganizations that could benefit from private cloud computing might be discouraged [7].Fear of new technology.Insufficient technical experience.
Inability to hire experienced staff.
Insufficient funding.
Current research in vertical cloud architectures focus on how they can be used in particular markets, but not on reducing complexity and increasing usability of the underlying architecture.
Stein, S., J. Ware, J. Laboy, and H. E. Schaffer.Slide10
Challenge Questions
Is it possible for nodes to be discovered automatically on the local network?How can communication between nodes be established without user intervention?
Is there a good solution to distributing the required software to each node automatically?
Is there an alternative to RSA key sharing with regard to authentication and security?
Are there any other constraints to deployment that have not been uncovered?Slide11
Architecture Design
THUNDERRecursive backronym.THUNDER H
elps
U
nderfunded
Nonprofits Distribute Electronic Resources.Vertical architecture aimed at addressing the challenges faced by small and struggling organizationsInfrastructure as a Service.Provides computational, storage, and networking infrastructureSlide12
Architecture
Design
Client devices connecting to the cloud.
Head node. Manages cloud interface and facilitates inter-node communication
.
Zeus nodes.Service nodes. Provide compute and storage services.Thor and Indra nodes.Slide13
Architecture DesignNon-persistent TCP 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.Allows messages to be sent to entire groups, or individual nodes.Slide14
Architecture Design
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”}User Test wants to instantiateXubuntu-MediumResponse:{ “_HOST_”: “10.10.0.5”, “Command”: “Instantiate”, “Username”: “Test”, “IP”: “10.10.1.58” “Domain”: “XubAF983C”}Instantiation is successful. TheVM is located at 10.10.1.58Slide15
Architecture Design
JSON objects are received by the main thread and placed into a shared queue. A worker thread is dispatched for each request. The worker is responsible for responding to the sender.Slide16
Architecture Design
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.Slide17
Architecture Design
Automatic node registrationMulticast message sent across local network prompts new nodes to register with the head node
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 FailoverSlide18
Architecture DesignPre-shared key used in authentication between nodes.
Key is automatically distributed on deploymentUses challenge/response mechanismChallenge is sent from head node to service node.
Service node encrypts message with pre-shared key, and sends it back to the head node.
Head node decrypts message and compares with original.
Avoids the need for RSA key sharingSlide19
Cost Savings Model
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.Slide20
Cost Savings Model
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.Slide21
Cost Savings Model
What is the big picture?
As the organization grows, THUNDER continues to help to decrease hardware costs compared to traditional workstations.Slide22
Cost Savings Model
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%.Slide23
Additional ChallengesChallenge questions were augmented with the following
How does THUNDER differ from general purpose architectures?Can we produce some qualitative or quantitative metrics to demonstrate that THUNDER is better for users of non-technical backgrounds?Empirical study to address theseSlide24
Empirical Study on Deployment
Deployment is the process by which a private cloud is configured locally for the users.General purpose cloud solutions have a lengthy and non-intuitive deployment process.The empirical study involved volunteers deploying THUNDER as well as Eucalyptus and OpenStack.Slide25
Empirical Study on DeploymentGroup 1 consisted of 24 undergraduate and graduate students.
Group 2 consisted of 14 undergraduate and graduate students.Group 3 consisted of 5 industry professionals, including 3 educators, a medical doctor, and a lawyer.Slide26
Empirical Study on Deployment
All groups were asked to complete an optional survey composed of both qualitative and quantitative questions.Quantitative questionsHow much time was spent
?
1
Least time 5 Most time
How difficult was the deployment? 1 Least difficult 5 Most difficultHow clear were the instructions? 1 Least clear 5 Most clearQualitative questionsWhich instructions, if any, were unclear?What could be done, if anything, to simplify the deployment process?Slide27
Empirical Study Results (Group 1)
Group 1 was asked to compare the deployment process of THUNDER with that of Eucalyptus.8% successfully deployed Eucalyptus. 100% successfully deployed THUNDER.
Time spent
Perceived difficultySlide28
Empirical Study Results (Group 1)Participants in group 1 had a more favorable experience deploying THUNDER over Eucalyptus.
THUNDER was perceived to be less difficult, took less time, and had clearer instructions.
Clarity of instructionsSlide29
Empirical Study Results (Group 1)Responses to qualitative questions show that participants struggled with inaccuracies in the Eucalyptus instructions as well as in naming of components.
Which instructions, if any, were unclear?Slide30
Empirical Study Results (Group 1)Participants would have preferred automation, a graphical user interface, better instructions, as well as faster deployment for Eucalyptus.
What
could be done, if anything, to simplify the deployment process?Slide31
Empirical Study Results (Group 2)
Group 2 was asked to compare the deployment process of THUNDER with that of OpenStack.14% successfully deployed OpenStack. 100% successfully deployed THUNDER.
Time spent
Perceived difficultySlide32
Empirical Study Results (Group 2)Participants in group
2 had a more favorable experience deploying THUNDER over OpenStack.THUNDER was perceived to be less difficult, took less time, and had clearer instructions.
Clarity of instructionsSlide33
Empirical Study Results (Group 2)
Responses to qualitative questions show that participants struggled with editing configuration, networking, authentication, and component naming in OpenStack.
Which instructions, if any, were unclear?Slide34
Empirical Study Results (Group 2)
Participants would have preferred automation and better instructions for OpenStack.
What
could be done, if anything, to simplify the deployment process?Slide35
Group 3 was asked to deploy OpenStack and THUNDER.Professional users experienced the most challenges.
None successfully deployed OpenStack.Empirical Study Results (Group 3)
Time spent
Perceived difficultySlide36
Participants in group 3 had a more favorable experience deploying THUNDER over OpenStack.
All professional participants wanted more automation in OpenStack.Empirical Study Results (Group 3)
Clarity of instructionsSlide37
Load Balancing and Consolidation
Cloud computing originally focused heavily on homogeneous systemsA few large, powerful, expensive systems.Recently the focus has shifted towards heterogeneousMany less powerful, cheaper systems.Load balancing in Eucalyptus and
OpenStack
defaults to round-robin
No utilization metrics, blind VM placementSlide38
Load Balancing and Consolidation
Homogeneous cloud
Heterogeneous cloud
Not Rejected
Round-robin does not consider any constraints regarding the underlying hardware, potentially causing non-optimal placement in a heterogeneous cloud.
More OptimalSlide39
Load Balancing and Consolidation
We developed RAIN VM placement algorithmRating Assisted Instantiation N
egotiator
Rank each node using real utilization metrics
Always place VM’s on best ranked node
We found that RAIN helps to decrease overall stress on the hardware, and increases the success rate of instantiationBetter placement equates to more VM’s able to be instantiated while decreasing average loadSlide40
Load Balancing and Consolidation
Node rank is composed of a weighted sum of metrics scaled by user defined priority constantsThe node with the lowest sum is the node with the best fitnessPriority constants, Ki are real numbers that range between 0.0 and 1.0 such that the sum of the constants is always 1.0Slide41
Load Balancing and Consolidation
Node Rank consists of a weighted sum of metrics scaled by resource priority constants, K
i
After ranking nodes without sufficient free resources are thrown out.Slide42
Load Balancing and Consolidation
We compared RAIN to round-robin while aggregating system metricsCPU load, RAM utilization, number of VM’sWe varied the VCore/Core constraint from 3 to 6Controls the number of virtual cores allowed per physical core
With a high enough
VCore
/Core constraint, RAIN outperforms round-robinSlide43
Load Balancing and Consolidation
We assessed 9 sets of resource priority constants:Strict/Non-strict RAM emphasis Strict/Non-strict short-term l
oad emphasis
Strict/Non-strict long-term load emphasis
Strict/Non-strict average # active
vm emphasisConsolidation (No emphasis)Compared results to round-robin with random selection as a controlSlide44
% VM Fill
CPU Load Average
% Free RAM
% Failed Instantiations
RAIN Results
15 instantiations on 2 nodes (3VCore/Core)Slide45
% VM Fill
CPU Load Average
% Free RAM
% Failed Instantiations
RAIN Results
30 instantiations on 4 nodes (5VCore/Core)Slide46
CPU Load Average
% VM Fill
% Free RAM
% Failed Instantiations
RAIN Results
40 instantiations on 4 nodes (6VCore/Core)Slide47
Load Balancing and Consolidation
Turnaround times with RAIN consistently higher than with round-robinIt takes more time to choose a good nodeContributes to lower CPU load averageSlide48
Load Balancing and Consolidation
We found that consolidation of virtual machines produced the best results most consistentlyReaffirms previous study that suggests load consolidation as optimal solution for cost savingsRound-robin outperforms RAIN when the VCore/Core constraint is low
RAIN consistently produces lower CPU loadSlide49
User InterfaceNo general purpose cloud solution provides completely web browser based control and monitoring of resources
Command line interface most commonNo general purpose cloud solution gives remote access to virtual machines from within the web browserThird party VNC or RDP clients requiredSlide50
User InterfaceCompletely web browser based
HTML5 and WebSockets for dynamic contentMiddleware maintains WebSocket handler
HTML requests handled separately from node-to-node connections
Virtual machines can be interacted with from within the web browserSlide51
User InterfaceLaunching and interacting with virtual machines is accomplished easily in the web interface.
Scalability of resources (RAM, CPU cores, etc)Remote desktop over WebSocket interfaceSlide52
User Interface
Elasticity of components is controlled from within the browser by the administrator
Adding and removing cloud servers
Monitoring of cloud server health
RAM utilization, CPU load, etc.Slide53
Future Work
Faster deploymentCurrently we re-deploy the base operating systemIt would be faster to only re-deploy the software packagesConflict resolution?Test on a larger cluster
Study performed on 4 node cluster
How does it scale on 100 nodes? 1000
?
We want to know if there could be any technical faults at scaleRequires lots of hardware and money thoughSlide54
ConclusionEmpirical study shows that THUNDER is better suited to be used and deployed by inexperienced users when compared to Eucalyptus and OpenStack
Study also shows that THUNDER could benefit organizations with little to no experience in cloud computingCheaper than public cloud, and easier to use and deploy than general purpose cloudsSlide55
Conclusion
Performance results show that the RAIN load balancing solution performs better than round-robin, especially in heterogeneous configurationsWe believe that THUNDER helps to solve the challenges discovered in the literature as well as those discovered during empirical
study
Easy to use, easy to deploy
All
proposed challenges solvedSlide56
Publications
Journal ArticlesG. Loewen, J. Galloway, and S.
Vrbsky
. RAIN: A Metrics Based Heuristic for Optimal Virtual Machine Node Selection.
In draft
.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.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.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.Slide57
Publications
Conference ProceedingsM. Galloway, G. Loewen, S. Vrbsky
.
Performance Metrics of Virtual Machine Live Migration. In Proceedings of
the 8th
IEEE International Conference on Cloud Computing (CLOUD 2015). New York, NY. June 27 - July 2, 2015.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.G. Loewen, M. Galloway, S. Vrbsky. A Graphical Interface for Private Cloud and Cluster Management. In Proceedings of the ACM Southeast Conference (ACMSE 2013). Savannah, GA. 2013.Slide58
Publications
WorkshopsG. 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
.
Posters
G. Loewen, M. Galloway, and S.
Vrbsky. Empirical Study on the Deployment of Local Cloud Architectures. In Proceedings of the ACM Southeast Conference (ACMSE ’14), Kennesaw, GA, March 28-29 2014. ACM.Invited TalksG. Loewen. THUNDER: A Cloud Architecture To Reduce Costs and Organizational Overhead For Nonprofits. Western Kentucky University. March 27, 2015.Slide59
Thank You