Differences

This shows you the differences between two versions of the page.

--- connectivity-suite:architecture [2019/07/25 08:48]
voegeli [System architecture]
+++ — (current)
@@ Line 1: / Line 1: @@
-====== Introduction ======
-The Connectivity Suite is a The lean remote management system to build your private network infrastructure and maintain NetModule devices. Therefore the Connectivity Suite has three key capabilities:
-  *  Build complete network infrastructures remotely by setting up automatically a encrypted VPN infrastructure for secure communication
-  *  Monitor networks and devices in real time
-  *  Manage networks and devices centralized by scheduled OTA updates and configurations
-The Connectivity Suite has been designed to have a scalable architecture. It allowes to be installed in the cloud or on premises depending on customer needs. The system architecture is based on Linux running microservices in Docker containers.
-{{ :cs:software_architecture_basic.png? }}
-  *User interface: browser-based web interface accessible by https (SSL + OAuth).
-  *Middleware: The middleware is based on Apache Kafka and establishs the communication between the User Interface and the microservices in the Core for a scalable, robust and distributed system.
-  *Core: in the core several microservices (Identity, Devices, Configuration, Deployment, Health) are running which are servicing REST API requests.
-The solution can be used in standalone mode by using the interactive  user interface provided by NetModule or by integrating the Connectivity Suite into customer applications by using the powerful REST API. The user interface and the middleware are open platform where user specific changes can be adapted.
-===== Services =====
-The Connectivity Suite runs several standalone services (microservices) in the Core, servicing REST API requests. Each service handles its own configuration and presistence and is running as an individual Docker container. The services are using the service of the Kafka cluster or the PostgreSQL database for presistance. The Connectivity provides following services:
-**Identity**\\
-The Identity microservice provides endpoints to manage users as well as tenants. As the Connectivity Suite provides user rolles with different access rights, the Identity microservice manages that the access rights of the different user types. However It does not handle authentication. the user right itself is assigned by the platform administrator.
-**Devices**\\
-The Devices microservice provides provides endpoints to manage devices. The microservice stores the static configuration (type, manufacturer, model, serial number, etc.) of a device. The microservice also manages named groups of devices. Device groups are not yet implemented in the current version.
-The microservice keeps also track of currently valid IP addresses through which each device can be reached.
-**Configuration**\\
-The Configuration microservice provides endpoints to manage the available firmware as well as the runtime configuration of devices registered in the system. Firmware images can be uploaded as well as referenced in this service. The runtime configuration of devices is also managed which allows to set the runtime properties (IP address, networks, …) and upload a device-specific configuration. Those properties will be merged with an uploaded configuration file when a complete deployable (firmware and configuration) is being retrieved.
-Configurations cannot be deleted, only replaced with a sequentially numbered, updated configuration. Thus, a complete history of all previous device configurations remains available.
-**Deployment**\\
-The Deployment microservice provides endpoints to manage the deployment of firmware and configuration to devices. To deploy a configuration/firmware to a device, the first step that needs to be executed is the creation of a deployable. A deployable is the combination of a specific configuration (multiple configurations can be kept beside each other) and an update method (push/pull) together with a device ID. After that, the deployable needs to be scheduled with a job. A job has a schedule (when and for up to how long to execute) and a list of deployables that should be deployed to devices. Once a job schedule is activated, the microservice will make sure it’s executed according to instructions. The state of the job can also be queried through the service.
-**Health**\\
-The Health microservice provides health data from devices to monitore the connectivity status and the uptime of each device and network.
-=====Home=====
-The Home represents the Connetivity Suite which may be running on a single machine, or as a distributed system with several instances of each microservice. The Home is running on a Home server which includes an OpenVPN server as one of the Docker components. It is used to securely connect to devices in the customer networks, and for network devices to connect to the Home server (notify about new devices, update IP when switching VPN servers).
-===== Provisioning =====
-Provisioning is called the process to connect a device for the first time to the Connectivity Suite. The Provisioning is required since a device is initially not able to connect to the Connectivity Suite. The Provisioning takes place in the Provisioning network which is hosted by the Provisioning server. Once a device is in the Provisioning network it can be assigned to any Tenant and can connect to the Connectivity Suite also after disconnection.
-During the provisioning the device is provisioned with the network address of the Connectivity Suite installation, VPN configuration, key material and many more information. The configuration of the device will be updated accordingly to Connect automatically to Provisioning network of the Connectivity Suite.
-===== Tenant =====
-Tenant is a group of devices. From the user perspective a tenant could be used to separate devices depending on the country, region, business unit or something else. Administration rights can be assigned for each tenant separately to restrict user access per Tenant. Devices that belong to one tenant can not communicate with all other tenants in the network.
-Devices within a Tenant are connected and can communicate, wherease devices cannot communicate cross Tenant. The Tenant represents a network of devices and end devices.
-===== System architecture =====
-=== Home network ===
-The Home network is a VPN subnet consisting of all Tenants.The Home network is used to address all devices (and possible end devices) which ar assigned to Tenants. Its size can be roughly estimated like this: Maximum number of Devices X average number of End Devices behind a single Device.
-<WRAP center round info 60%>
-Note: The Home server does not belong to the Home network but all devices in the home network are connected to the Home server.
-</WRAP>
-{{ :cs:home2.png? }}
-=== Provisioning network ===
-A provisioning network is a VPN subnet consisting of Devices newly detected by the Connectivity Suite but not assigned to a Tenant yet. Only the Platform Administrator has access to this subnet and can move Devices to a Tenant. A Connectivity Suite instance has exactly one Provisioning Network.
-<WRAP center round info 60%>
-The Provisioning server is in the same subnet as the Home server
-</WRAP>
-{{ :cs:provisioning2.png? }}
-==== Tenant network ====
-A Tenant is a VPN subnet consisting of Devices and Generic Devices. Tenants can be used to group Devices. A Tenant is used for logical grouping. A Tenant network is hosted by virtual VPN servers which are hosted by the Home server. The certificates used for establishing VPN connections are created in an automated fashion.
-A simple network architecture how a Tenant is managed by the Connectivity Suite is shown below:
-{{ :cs:tenants2.png? }}
-[[cs:start|← Back to Connectivity Suite Main Page]]

User Tools

Site Tools

Differences

Page Tools