This page describes the flow matrix of the NMS/Shacache/Wendelin
General description
The NMS (a.k.a. SlapOS master), shacache and wendelin services are ERP5 based services. It means that to provide those services, we actually deploy a full ERP5 that will then be customized to do a specific service.
A ERP5 is provided by the following SlapOS services :
- default (main SlapOS instance)
- kumofs (x2: volatile and permanent)
- mariadb
- zodb-zeo
- zope (xN: one service per zope family)
- balancer
- wcfs
- jupyter
Those services are usually running inside a theia (SlapOS IDE) which can be simple or resilient.
If the Theia is resilient, the architecture is like this:
- theia0 : hosting all the production services
- theia-pull-backup : hosting the historized daily backup
- theia1: hosting all the failover services (the services are stopped in the theia1 by default)
Usually, theia0, theia-pull-backup and theia1 are running on separate physical machines. Sometimes, theia-pull-backup and theia1 can run on the same machine. Of course there is no point in putting all in the same machine. If you have only one machine, use a simple theia.
Incoming traffic
We will show in the table below the incoming connection on all 3 theia for ERP5 services:
| Theia |
SlapOS Service |
From |
Destination IP |
Destination Port |
Traffic Type |
Purpose |
| theia0 |
DEFAULT |
frontend |
DEFAULT-IPv6 |
8196 |
https |
web server of the monitoring |
| KUMOFS-PERSISTENT |
frontend |
PERSISTENT-IPv6 |
2004 |
https |
web server of the monitoring |
| KUMOFS-VOLATILE |
frontend |
VOLATILE-IPv6 |
2014 |
https |
web server of the monitoring |
| MARIADB |
frontend |
MARIADB-IPv6 |
45679 |
https |
web server of the monitoring |
| ZODB |
frontend |
ZODB-IPv6 |
2101 |
https |
web server of the monitoring |
| ZOPE-1 |
frontend |
ZOPE-1-IPv6 |
random |
https |
web server of the monitoring |
| ZOPE-2 |
frontend |
ZOPE-2-IPv6 |
random |
https |
web server of the monitoring |
| [...] |
|
|
|
|
|
| ZOPE-N |
frontend |
ZOPE-N-IPv6 |
random |
https |
web server of the monitoring |
| BALANCER |
frontend |
BALANCER-IPv6 |
random |
https |
web server of the monitoring |
| frontend |
BALANCER-IPv6 |
2151 |
https |
ZOPE-1 access |
| frontend |
BALANCER-IPv6 |
2153 |
https |
ZOPE-2 access |
| |
|
[...] |
|
|
| frontend |
BALANCER-IPv6 |
2151+2*N |
https |
ZOPE-N access |
| WCFS (nothing non local) |
|
|
|
|
|
| JUPYTER |
frontend |
JUPYTER-IPv6 |
8196 |
https |
web server of the monitoring |
| frontend |
JUPYTER-IPv6 |
8888 |
https |
access to Jupyter lab |
| THEIA |
frontend |
THEIA-IPv6 |
3000 |
https |
vscode GUI |
| frontend |
THEIA0-IPv6 |
8386 |
https |
web server of the monitoring |
| theia-pull-backup |
THEIA0-IPv6 |
22200 |
ssh |
SSH access for backup |
| theia-pull-backup |
THEIA |
frontend |
THEIA-PULL-BACKUP-IPv6 |
8070 |
https |
web server of the monitoring |
| theia1 |
THEIA |
frontend |
THEIA1-IPv6 |
8386 |
https |
web server of the monitoring |
| theia-pull-backup |
THEIA1-IPv6 |
22210 |
ssh |
SSH access for backup |
Note1: theia-pull-backup is responsible for launching the copy of the data from theia0 and to theia1 thanks to rdiff-backup over SSH.
Note2: in default mode, all services of theia1 are stopped. If you trigger take over, the NMS services that were running on theia0 will run on theia1 (hence all incoming traffic for NMS services must be allowed on theia1).
Outgoing traffic
The list below describes outgoing traffic for all machines involved in NMS/Shacache/Wendelin
- SlapOS client:
- https traffic to frontend (to reach the NMS)
- https traffic to frontend (to reach the shacache for sotfware release upgrades)
- OS upgrades : https traffic to package repositories
- NTP
- DNS