ICACT20230145 Slide.25
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Thank you for your attention, feel free to give us any comment or question.
|
|
ICACT20230145 Slide.24
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Here is the references list for this presentation.
|
|
ICACT20230145 Slide.23
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
we have presented two scaling scenarios to address the automatic scalability of Telco applications on VM and On Kubernetes in a virtual cluster on the virtualized Cloud Computing environment. The proposed Cloud Computing architecture is constructed with a load balancer, a Management and orchestrator system, and an Auto-Scaling system. The load balancer is utilized to route and balance user requests to Cloud services deployed in a virtual cluster. The Management and orchestrator system is used to collect the use of physical resources and define attributes of each virtual machine or each pod in a virtual cluster. The Auto-Scaling system with Scaling management plugin is utilized to dynamically provision the virtual machines, and Pods based on the rule user-defined or the use of the resources in a virtual cluster. In addition, idle virtual machines or pods are destroyed, and then the resources can be released. On the other hand, the energy cost can be reduced by removing the idle virtual machines, and pods. Our architecture has demonstrated the proposed algorithms for Telco cloud are capable of handling sudden load requirements, maintaining higher resource utilization, and reducing energy costs. The Scaling management plugin of the Auto-scaling system is the essential element in enhancing resource utilization, thus reducing the infrastructure and management costs. In the future, beside for VNF and CNF, we will extends for support application run on bare-metal. Else we use other algorithms, or improve existing algorithms to accommodate auto-scaling application.
|
|
ICACT20230145 Slide.22
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
I will now proceed to the end of my presentation by discussing some potential future works
|
|
ICACT20230145 Slide.21
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
With the requirements of Telco service, the customers will use more resources with specific time based on area. Then the Telco service should scale in, and scale-out applications served for that time. We provide an auto-scaling algorithm that allows schedule scale application at a specific time that, it illustrates on Algorithm 2.
|
|
ICACT20230145 Slide.20
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
With a defined threshold, we illustrate our auto-scaling algorithm on Algorithm 1. When Telco service runs on VM, the algorithm first determines the current VMs with the resource defined in the rules above or below given threshold numbers, respectively. If all VMs have resources defined in the rules above the given upper threshold, a new VM will be provisioned, started, and then added to the load balancer, respectively. If there are VMs with resources defined in the rules below a given lower threshold and with at least one VM that has no resources defined in the rules, the idle VM will be removed from the load balancer and be terminated from the system. For Telco services running on Pod Kubernetes, with the rule defined (maybe about physical computing resources such as the uses of CPU and memory) will be indices for the evolution of the workload of a virtual cluster. When Telco applications run on Pod Kubernetes, the algorithm first determines the current Pods with the use of physical resources above or below given threshold numbers. If the uses of resources of all Pods are above the given upper threshold, a new Pod will be created, provisioned, started, and then perform the same computing tasks in the virtual cluster. If the uses of resources of some Pods are below a given lower threshold and with at least one Pod that has no computing job, the idle Pod will be terminated from the virtual cluster.
|
|
ICACT20230145 Slide.19
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Now, I will shows two algorithms we used for our cluster.
|
|
ICACT20230145 Slide.18
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Scaling Management Plugin is a support system for auto-scaling applications for the virtual cluster. With the architect in the figure, it has three components: API is a RESTful API for a third-party component to work with this plugin. Rules Management is a rule engine for MANO rules use. Provisioning modules with roles, based on rules candetect and replace the instance with status unhealthy or unreachable.
|
|
ICACT20230145 Slide.17
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The MANO System is a platform that supports the management of Cloud infrastructure, management and deployment of CNF/VNF of 4G and 5G core networks on the Cloud infrastructure. In particular, Mano manages the physical servers of Cloud infrastructure through Kubernetes and OpenStack, managing services deployed in the form of VM through OpenStack, services deployed as Cloud Native through Kubernetes. The MANO System includes Front-end, Back-end, Database components and agents collecting, monitoring and controlling the components of the Cloud likes NFVI, VIM and CNF/VNF platform.
|
|
ICACT20230145 Slide.16
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In our architecture, the load balancer is utilized to balance the Telco application load. Depending on the way we deploy applications on virtual machines or Pod Kubernetes, we choose the appropriate load balancer. When deploying an application on a virtual machine, Apache HTTP Load-Balancer is utilized as a load balancer to allow incoming HTTP requests to be routed into servers that perform the Telco application. Since the Apache HTTP LoadBalancer configuration can be updated dynamically, this allows a Cloud system to automatically and dynamically add new servers for a virtual cluster. The additional web servers enable the virtual cluster to scale and thus provide better response time for incoming HTTP requests. Else deploy an application on Pod Kubernetes, we use Kubernetes Load Balancer used as a load balancer to allow incoming HTTP requests to be routed into Pods that perform the Telco application. With the confguration of Kubernetes Load Balancer can be updated dynamically, and a Cloud system to automatically and dynamically add a new pod for a virtual cluster. The additional pod enables the virtual cluster to scale and thus provide better response time for incoming HTTP requests to the system.
|
|
ICACT20230145 Slide.15
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
A scalable architecture that effectively handles these two scenarios is illustrated in the figure. This architecture includes three main components: Load balancer, Management, and orchestrator (MANO) system and Auto-Scaling system with two auto-scaling algorithms. The load balancer can balance the requests between different virtual machines or pods that perform the same application in a virtual cluster. Management and orchestrator system used for management (VMs on Openstack or Pods on Kubernetes) collects resource usages or other attributes of all VMs, and Pods for each virtual cluster that is running on the Cloud. Auto-Scaling system with three modules in it includes Load balancer controller, Address collector, and Scaling management plugin. It can horizontally expand/shrink the number of VMs, the number of pods according to the workload of a virtual cluster over MANO where VMs, Pods belong and the new one can serve services. If the application running on the virtual cluster consumes most of the resources or is over a defined threshold, the auto-scaling system can create a new VM or new Pod that performs the same application and load balancer and then balances the requests among VMs or Pods in the same virtual cluster.
|
|
ICACT20230145 Slide.14
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In the next section, I will give you an overview of the architecture design in our Telco Cloud.
|
|
ICACT20230145 Slide.13
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
We aim to introduce an elastic auto-scaling architecture for applications deployed in virtual machines and on the pod in a Telco cloud and to provide two auto-scaling algorithms used. With the result, we was integrated with Telco Cloud for Online Charging Services Application serves more than 1 million customers and is expanding.
|
|
ICACT20230145 Slide.12
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Based on container technology, E. Casalicchio and V. Perciballi address the problem of selecting the more appropriate performance metrics to activate auto-scaling actions. In the figure, the high level architecture of the auto-scaling controller in Kubernetes. Relative metrics are collected by cAdvisor. Absolute metrics could be collected at host level (virtual machines) and/or infrastructure level (physical machines).
|
|
ICACT20230145 Slide.11
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Then Che-Lun Hung et al. use a dynamic-scaling scenario with a novel design of applications deployed in virtual machines in a virtual cluster. But the architecture just applies to applications running on a virtual machine. The use of containers as a base technology for large-scale systems opens many challenges in the area of resource management at run-time.
|
|
ICACT20230145 Slide.10
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The first related work, Trieu C. Chieu et al. proposed a useful architecture for dynamic scaling of the web application in a virtualized cloud computing environment. Their architecture includes a load-balancer, virtual cluster orchestrator system, and auto-provisioning system, and works effciently in virtual machines. However, a user can rent many virtual machines to perform his applications which are not only web applications. Meanwhile, for security, virtual machines for a specifc user can be regarded as a group, and a user cannot access the resources from other groups.
|
|
ICACT20230145 Slide.09
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Now, I will quickly go over previous contributions made by other authors and how our research
|
|
ICACT20230145 Slide.08
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Auto-scaling is often referred to in the context of resource provisioning, scalability, and elasticity. These terms are often used interchangeably, but they are slightly different concepts. Understanding the differences between these concepts can help us to identify the unique issues of auto-scaling and focus on the solutions. In [8], the key features are: The ability to scale out (i.e., the automatic addition of extra resources during increased demand) and scale in (i.e., the automatic termination of extra unused resources when demand decreases, to minimize cost). The capability of setting rules for scaling out and in. The facility to automatically detect and replace unhealthy or unreachable instances.
|
|
ICACT20230145 Slide.07
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Telco cloud represents the Data Center resources which are required to deploy and manage a mobile phone network. Telco clouds are based in private Data Center facilities which are used to manage the telecommunication requirements of 3G/4G and LTE networks. With the current roll-out of 5G equipment across the mobile service provider, vendors have adopted strategies related to network function virtualization (NFV) and software-defined data center (SDDC) management which have become indispensable part of a Telco setup. The current Telco Cloud architecture used NFV Architecture proposed by the European Telecommunications Standards Institute (ETSI), it consists of: Virtualization Network Function (VNF) Layer, NFV Infrastructure (NFVI) Layer, Operation Support Subsystem (OSS) Layer and Management, Automation and Network Orchestration (MANO) Layer.
|
|
ICACT20230145 Slide.06
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Basically, virtual network functions (VNFs) are software applications that deliver network functions such as directory services, routers, firewalls, load balancers, and more. They are deployed as virtual machines (VMs) and have often been the next step for telecommunications providers in their digital transformation from the physical network functions (PNFs) of legacy network appliances on proprietary hardware. As an evolution from VNFs, cloud-native network functions (CNFs) are designed and implemented to run inside containers. This containerization of network architecture components makes it possible to run a variety of services on the same cluster and more easily on-board already decomposed applications, while dynamically directing network traffic to the correct pods.
|
|
ICACT20230145 Slide.05
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Then, We must known about Containers and Kubernetes. A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. Kubernetes is a container-based deployment platform with many benefits such as elasticity, durability, ease of management, and cost-effectiveness. Cloud-native containerization is replacing Virtual Machine (VM) as the preferred method of application deployment. However, the network requirements involved, including high performance and low latency, prove to be a barrier to the deployment of 5G applications. Cloud-native Network Function (CNF) enables network functionalities to run in containers instead of on traditional bare metal servers.
|
|
ICACT20230145 Slide.04
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, We talk about Virtual Machine (VM), which is a compute resource that uses software instead of a physical computer to run programs and deploy apps. VNFs are virtualized network services running on open computing platforms formerly carried out by proprietary, dedicated hardware technology. Most VNFs are run in virtual machines (VMs).
|
|
ICACT20230145 Slide.03
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The first, we need to distinguish some terms for father understand. Virtualization is use software to divide the whole CPU, RAM, HDD load of a computer into many virtual machines (VMs). Cloud is known as a network of virtual machines developed according to the Private, Public, Hybrid model. Cloud Native is an approach to packaging and deploying applications on Cloud environment including: Microservice design, container packaging, CI/CD. NFV is the standard for managing and controlling VNFS network functions on Cloud environment. SDN is use software to define network communication between VNFs. In the figure, The Evolution of Cloud Native Stack when using technology from Virtualization to Cloud and from now Cloud Native.
|
|
ICACT20230145 Slide.02
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
First of all, I start with the background of the paper and the introduction of the topic
|
|
ICACT20230145 Slide.01
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
I will present this in the following sections. First I will introduce the purpose we want to achieve. Then, I will share our related work and our contributions. In the third part, I will introduce the design architecture to solve the problem. Next, I will give the two algorithms we used. And finally, summarizing and providing future tasks will be done.
|
|
ICACT20230145 Slide.00
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Hello everybody, my name is Dang Sao Cao. I am currently a cloud engineer in Viettel High Technology, Viettel Group and a M.SC student at Hanoi University of Science and Technology in Vietnam. For ICACT 2023, my team are very glad to present our research named "Elastic Auto-Scaling Architecture in Telco Cloud".
|
