Date: Fri, 29 Mar 2024 10:56:42 +0000 (UTC) Message-ID: <174676512.829.1711709802361@c4e992b7d277> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_828_743263690.1711709802360" ------=_Part_828_743263690.1711709802360 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Welcome to the Edge Cloud Project page. This page covers a brief descrip= tion of the aim of project and the planned activities.
This project's aim is to develop a cutting edge distributed cloud techno= logy and use cases for highly distributed and edge deployments and contribu= te towards open source projects like OpenStack and Kubernetes.
Develop a robust security for the edge cloud infrastructure by implement= ing a distributed control plane, which not only will provide enhanced secur= ity, but will also help to overcome in the event of a failure of one authen= tication system.
We will perform evaluation of workloads, behavior and portability in dis= tributed control plane of edge environments. Evaluations include= s load balancing, availability, partitioning and behavioral analysis of wor= kloads running in container mesh environments, compared to traditionally ne= tworked machines. Further studying the impact on applications when running = in central versus edge environments including resource and bandwidth constr= ained environments.
In practice, as part of the project, we will create our own cloud infras= tructure. The plan is to install OpenStack on the machines, install Kuberne= tes on top of it and federate the nodes.
As a first step towards reaching highly available, partitioned and secur= e communication between the edge sites, we are starting with a centralized = control plane architecture deployment.
Security
The users are authenticated using keystone with the help of LDAP and AD = in the backend and also support an External Identity Provider authenticatio= n.
The users will be assigned roles to implement RBAC for the various servi= ces available in Openstack.
To overcome the threat of single point of failure, we plan to implement = a distributed control plane and federate the large/medium edge sites. = Independent control plane is placed within each edge site. In the event of = any problem or failure in the central data center, the edge site can authen= ticate the users. Due to the use of IDP, with the help of federation, user = can authenticate in any edge site he may visit.
Keystone to Keystone federation to enable federation between edge clouds= using openstack.
To enable trust, Keystone in the role of CA will sign the images before = storing in the database.
Performance test when different flavours of OS is installed in each edge= cloud.
More details of activities are provided at: Security Aspect for Edge Cloud
Deployment
There are various deployment options for infrastructure (IaaS =E2=86=92&= nbsp;Openstack) and platform (PaaS =E2=86=92 kubernetes) where evaluat= ion for edge cloud performance vs cost, throughput, latency and packet= delay, scaling, availability and partitioning, replication, and load balan= cing can take place. Evaluation of these params of various deployment optio= ns can be done using OpenStack Rally and Yardstick. We also test = StarlingX and modify its infrastructure to avoid single point of failure.&n= bsp;
Starting point is to have the centralized control plane(the initial "bas= ic" edge cloud) up and running, then investigate different deployment optio= ns, including: OpenStack on Kub= ernetes and Kubernetes o= n Openstack. Then test these deployment options again for the distri= buted control plane architecture and evaluate performance of the edge cloud= infrastructure, because centralized control plane can have issues with par= titioning, load balancing, replications, and single point of failure. We tr= y to improve the performance of distributed control plane without spen= ding lots of effort in maintaining the cloud.
We will also investigate various database engines such as RDBMSs (availa= bility and consistency), and dynamo db (availability and partitioning)= and improving the throughput and consistency for linux containers (LXC), d= ocker containers, kata containers.
For messaging queue protocols we experiment RabbitMQ and Qpid to perform= high availability load balancer such as HAProxy and high availability reso= urce manager such as Linux Pacemaker
More details of activities are provided at: Deployment Aspects for Edge Cloud= Thesis
Integrity
This aspect considers how different components of the cloud work togethe= r and what solutions there could be to increase compatibility. It is also i= mportant to find ways of avoiding vendor lock-in as this opens up many oppo= rtunities for users.
First, setting up a basic cloud architecture is required.
Then, different operation systems will be installed on different edges t= o test the compatibility, the drawbacks and the opportunities this provides= us.
Installing Kubernetes Federation v2 is the next step. For this, we need = multiple clusters. Federation helps us in migration and multi cluster manag= ement.
More details of activities are provided at: Integrity aspects for edge cloud thesis
Project members and contributors: