Fast and energy-efficient eNVM based memory organisation at L3-L1 layers for ...
Defense
1. A Scalable Heterogeneous
Software Architecture for the
Telecommunication Cloud
Pascal Potvin
École de Technologie Supérieure, Université du Québec
Montréal, April 26, 2016
Master Thesis in Software Engineering
9. 2016-04-26 9
2009
Google is not virtualized, and virtualization is
not sufficient to qualify as a cloud.
(Erich Clementi, head of IBM cloud computing efforts)
10. 2016-04-26 10
2009
Virtualization is Not the Cloud.
(Rackspace white paper)
Google is not virtualized, and virtualization is
not sufficient to qualify as a cloud.
(Erich Clementi, head of IBM cloud computing efforts)
16. Telecommunication Cloud
• More Stringent Requirements than IT Cloud
– Quality of Service (QoS)
– Interoperability
– Reliability
– Usage of Stateful protocols e.g. SIP
2016-04-26 16
Cloud computing is a model for enabling ubiquitous, convenient, on-
demand network access to a shared pool of configurable computing
resources (e.g., networks, servers, storage, applications, and services)
that can be rapidly provisioned and released with minimal
management effort or service provider interaction.
(Mell and Grance, 2011)
18. Problem Statement & Research Questions
• Telecommunication Cloud
– Can we apply IT cloud principles to the telecommunication cloud?
• Heterogeneous Deployments
– How can it be done?
• Cloud Programming Paradigm
– Which cloud architectural patterns are applicable to the telco cloud?
2016-04-26 18
19. Objectives
• Cloud-native software architecture for telco
– Select architectural patterns
– Define, implement and evaluate architecture
• Elasticity
– While providing QoS
– Distributing application state while minimizing impact on latency
• Heterogeneous deployments
2016-04-26 19
21. Cloud and Telco Scalability
2016-04-26 21
Elasticity QoS Statefulness Interoperability Heterogeneity Patterns
Lu et al., 2013 Virtualization
only
Yang et al.,
2011
On group level HSS Only
Bellavista,
Corradi et
Foschini, 2013
On group level Presence Server
Only
Carella et al.,
2014
On group level
22. Cloud and QoS
2016-04-26 22
Elasticity QoS Statefulness Interoperability Heterogeneity Patterns
Turner, 2013 E-commerce
On average
/
Verma et al.,
2015
/
23. Heterogeneous Cloud
2016-04-26 23
Elasticity QoS Statefulness Interoperability Heterogeneity Patterns
Xu, Wang et Li,
2011
Job based Various Size
Crago et al.,
2011
CPU / GPU
Lee, Chun et
Katz, 2011
Job based Fairness CPU / GPU
24. Cloud Patterns
2016-04-26 24
• Horizontal Scaling (in/out) and Auto-Scaling
• Microservices and the Actor Model
• Sharding
• MapReduce
• Collocate
26. Pattern: Horizontal Scaling
• Adding more of the same compute resource to increase
capacity (Scale out)
– Easy with stateless http… needs some consideration for session based
protocols
2016-04-26 26
30. Pattern: Actor Model
• Serving one instance at a time (High Granularity)
• Actors can:
– Instantiate other actors
– Store internal state
– Asynchronously communicate with other actors
2016-04-26 30
31. Pattern: Sharding
• Scaling by creating domains serving different customers or
end users.
• Consistent Hashing algo. & Rendezvous algo. Considered
– Rendezvous selected for least state synchronization required
2016-04-26 31
HSS
URI: A[…] to F[…]
Core IMS
HSS
URI: G[…] to L[…]
Core IMS
HSS
URI: M[…] to R[…]
Core IMS
HSS
URI: S[…] to Z[…]
Core IMS
Shard aware Load Balancer
32. Pattern: Mapreduce
• Variants are possible
– Usage of Classical Mapreduce for Logging.
2016-04-26 32
Input Files Map Shuffle & Sort Reduce Output
39. Architecture
2016-04-26 39
Pouch Type 1
Pouch Type 1
Pouch Type 1
Unit 1
Unit 1
XaaS
Unit 1
Unit 1
Unit 1
Unit 2
Pouch Type 1
Pouch Type 1
Pouch Type 3
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 5
Unit 1
Unit 1
Unit 6
Pouch Type 1
Pouch Type 1
Pouch Type 2
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 3
Unit 1
Unit 1
Unit 4
Meta Management
and Orchestrator
Node Selector
Service
Deployment Database
Service
Load Distribution
Service
Element Manager
Information Distribution
Service
Platform Framework
(incl. CMW, SDS, IDS client, …)
Persistence Service
Log Gathering Service
40. Architecture
2016-04-26 40
Element Manager Persistence Service Log Gathering Service
Node Selector
Service
Deployment Database
Service
Information Distribution
Service
Meta Management
and Orchestrator
Load Distribution
Service
Platform Framework
(incl. CMW, SDS, IDS client, …)
Units
Instantiation
Traffic
Distribution
Support Services
41. Microservices and Collocate
2016-04-26 41
Pouch Type 1
Pouch Type 1
Pouch Type 1
Unit 1
Unit 1
Meta Management
and Orchestrator
Node Selector
Service
Deployment Database
Service
Load Distribution
Service
Element Manager
Information Distribution
Service
XaaS
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 1
Unit 1
Unit 1
Unit 2
Pouch Type 1
Pouch Type 1
Pouch Type 3
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 5
Unit 1
Unit 1
Unit 6
Pouch Type 1
Pouch Type 1
Pouch Type 2
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 3
Unit 1
Unit 1
Unit 4
Persistence Service
Log Gathering Service
42. Horizontal Scaling and Auto-Scaling
2016-04-26 42
Pouch Type 1
Pouch Type 1
Pouch Type 1
Unit 1
Unit 1
Meta Management
and Orchestrator
Node Selector
Service
Deployment Database
Service
Load Distribution
Service
Element Manager
Information Distribution
Service
XaaS
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 1
Unit 1
Unit 1
Unit 2
Pouch Type 1
Pouch Type 1
Pouch Type 3
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 5
Unit 1
Unit 1
Unit 6
Pouch Type 1
Pouch Type 1
Pouch Type 2
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 3
Unit 1
Unit 1
Unit 4
Persistence Service
Log Gathering Service
Scaling based on:
• CPU
• Memory
• Bandwidth
• # of Units
Hysteresis with
upper and lower
bounds.
43. Distribution of State
2016-04-26 43
Pouch Type 1
Pouch Type 1
Pouch Type 1
Unit 1
Unit 1
Meta Management
and Orchestrator
Node Selector
Service
Deployment Database
Service
Load Distribution
Service
Element Manager
Information Distribution
Service
XaaS
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 1
Unit 1
Unit 1
Unit 2
Pouch Type 1
Pouch Type 1
Pouch Type 3
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 5
Unit 1
Unit 1
Unit 6
Pouch Type 1
Pouch Type 1
Pouch Type 2
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 3
Unit 1
Unit 1
Unit 4
Persistence Service
Log Gathering Service
44. Mapreduce (for logging purpose)
2016-04-26 44
Pouch Type 1
Pouch Type 1
Pouch Type 1
Unit 1
Unit 1
Meta Management
and Orchestrator
Node Selector
Service
Deployment Database
Service
Load Distribution
Service
Element Manager
Information Distribution
Service
XaaS
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 1
Unit 1
Unit 1
Unit 2
Pouch Type 1
Pouch Type 1
Pouch Type 3
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 5
Unit 1
Unit 1
Unit 6
Pouch Type 1
Pouch Type 1
Pouch Type 2
Unit 1
Unit 1
Platform Framework
(incl. CMW, SDS, IDS client, …)
Unit 3
Unit 1
Unit 1
Unit 4
Persistence Service
Log Gathering Service
46. Simplistic IMS Demonstrator
2016-04-26 46
Terminating Side
A
T
M
A
Alice
Bob
Originating Side
SIP Msg. UnitInter-Unit Link
SIPh C
DiahH
Node Selector
Service
Diah
T
H
CSIPh
Service Req. Links
HSS
48. Hybrid Cloud
Apcera (blue) and Open Stack (green)
2016-04-26 48
M
M
XaaS
Platform Framework
(incl. CMW, SDS, IDS client, …)
AC
T
H
Diah
P. F. (…)
LDS
SDS
P. F. (…)
SIPh
P. F. (…)
M
O
Platform Framework
(incl. CMW, SDS, IDS client, …)
DB
Meta Management
and Orchestrator
Node Selector
Service
Deployment Database
Service
Load Distribution
Service
Element Manager
Information Distribution
Service
Persistence Service
Log Gathering Service
49. Raspberry Pi
2016-04-26 49
XaaS
Raspberry Pi board
Raspberry Pi board
1st Raspberry Pi board
Platform Framework
(incl. CMW, SDS, IDS client, …)
Meta Management
and Orchestrator
C H
DB
Deployment Database
Service
Platform Framework
(incl. CMW, SDS,
IDS client, …)
SIPh
Element Manager
Information Distribution
Service
T
A M
Raspberry Pi boardsNAS
O
SDS
Node Selector
Service
Load Distribution
Service
Persistence Service
Log Gathering Service
57. Conclusion
• Cloud-native software architecture for telco
– Select architectural patterns
– Define, implement and evaluate architecture
• Elasticity
– While providing QoS
– Distributing application state while minimizing impact on latency
• Heterogeneous deployments
2016-04-26 57
58. Contributions
• Actor model for the telecommunication
– Provide scalability and elasticity
• Pouch concept
– Abstraction of platform for the application (heterogeneous
deployments)
• Proposed Heterogeneous Scalable Software Architecture
providing QoS
• Proposed Mechanism to distribute state information
• Built a POC showing how IMS can be re-architectured
• Published 3 conference papers
2016-04-26 58
59. Future Research Direction
• Multi-agent architecture for telecommunication?
• Finer grained QoS regulation?
• Machine Learning insuring QoS and higher cloud utilization?
2016-04-26 59
Our main objective is to develop a cloud-native software architecture for telecommunication
systems and implement this architecture in order to evaluate its merits. In order to do so we
will determine if we can re-architecture IMS in order to provide its functionality in an ondemand,
per subscriber and per service basis through the usage of the actor model (which can
be seen as a specialization of the Microservices pattern). To our knowledge no approach
proposes the same thing at this point in time.
Our specific objectives to accomplish this objective consist of the following:
O1. Propose a mechanism to efficiently allocate computing resources through multiple cloud
platforms in order to prevent overloading of computing resources and the resulting adverse
impact on QoS. This mechanism will implement an elastic and automatic scalability scheme.
To the best of our knowledge, no research has addressed this question in the
telecommunication sector.
O2. Propose a mechanism to allow for application state information to be distributed on
compute instances, providing resiliency while minimizing impact on latency.
O3. Propose an architecture providing portability between multiple cloud environments for
telecommunication applications, enabling a solution-oriented, heterogeneous cloud
deployment. The deployment could be on pools of bare-metal servers, IaaS, Platform as a
Service (PaaS) or a mix of these. The architecture should enable communication between
services or application components even if distributed on different platforms.
O4. Implement the architecture and measure its characteristics and to validate its
performance and compare it to a traditional telecommunication node-based deployment.
O2. Propose a mechanism to allow for application state information to be distributed on compute instances, providing resiliency while minimizing impact on latency.
O1. Propose a mechanism to efficiently allocate computing resources through multiple cloud platforms in order to prevent overloading of computing resources and the resulting adverse impact on QoS. This mechanism will implement an elastic and automatic scalability scheme. To the best of our knowledge, no research has addressed this question in the telecommunication sector.
O3. Propose an architecture providing portability between multiple cloud environments for telecommunication applications, enabling a solution-oriented, heterogeneous cloud deployment. The deployment could be on pools of bare-metal servers, IaaS, Platform as a Service (PaaS) or a mix of these. The architecture should enable communication between services or application components even if distributed on different platforms.
