As a first step towards reaching highly available, partitioned and secure communication between the edge sites, we are starting with a centralized control plane architecture deployment.
The users are authenticated using keystone with the help of LDAP and AD in the backend and also support an External Identity Provider authentication.
The users will be assigned roles to implement RBAC for the various services 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 authenticate 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
There are various deployment options for infrastructure (IaaS → Openstack) and platform (PaaS → kubernetes) where evaluation for edge cloud performance vs cost, throughput, latency and packet delay, scaling, availability and partitioning, replication, and load balancing can take place. Evaluation of these params of various deployment options can be done using OpenStack Rally and Yardstick. We also test StarlingX and modify its infrastructure to avoid single point of failure.
Starting point is to have the centralized control plane(the initial "basic" edge cloud) up and running, then investigate different deployment options, including: OpenStack on Kubernetes and Kubernetes on Openstack. Then test these deployment options again for the distributed control plane architecture and evaluate performance of the edge cloud infrastructure, because centralized control plane can have issues with partitioning, load balancing, replications, and single point of failure. We try to improve the performance of distributed control plane without spending lots of effort in maintaining the cloud.
We will also investigate various database engines such as RDBMSs (availability and consistency), and dynamo db (availability and partitioning) and improving the throughput and consistency for linux containers (LXC), docker containers, kata containers.
For messaging queue protocols we experiment RabbitMQ and Qpid to perform high availability load balancer such as HAProxy and high availability resource manager such as Linux Pacemaker
More details of activities are provided at: Deployment Aspects for Edge Cloud Thesis
This aspect considers how different components of the cloud work together and what solutions there could be to increase compatibility. It is also important to find ways of avoiding vendor lock-in as this opens up many opportunities for users.
First, setting up a basic cloud architecture is required.
Then, different operation systems will be installed on different edges to 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 management.
More details of activities are provided at: Integrity aspects for edge cloud thesis
Project members and contributors:
- Christopher Price
- Fatih Degirmenci
- Sofia Wallin
- Ali Shokrollahi Yancheshmeh
- Gábor Finta
- Khaled Jendi
- Latha Paramatmuni