...
The following diagram depicts the system architecture of eduroam Managed SP.
Production Deployment
It was decided to migrate the web frontend to the existing eduroam Managed IdP host, alleviating the need for a separate VM.
It was decided to add at least one RADIUS backend server outside of the GEANT IT environment. SURF volunteered to check hosting possibilities (on-prem SURF or Amazon).
Infrastructure Requirements
...
| VM requirements | Web Frontend VM | RADIUS SP Proxy VM |
|---|---|---|
| Description of usage | Presents the UI to eduroam NROs and eduroam SP operators, for management of their Wi-Fi deployments. The VM also triggers configuration changes on the RADIUS servers via the R Config API. | Exposes a dedicated pair of (IP, UDP port) to each connected eduroam SP. VM accepts incoming RADIUS traffic from eduroam SPs and forwards requests via RADIUS/TLS to the production eduroam infrastructure (preferably with a NAPTR lookup target, alternatively via an NRO/ETLR backup link). Each VM can handle up to m=500 eduroam SPs. |
| Number of VMs with same specification | 1 | n (Pilot: n=2; Prod: n= scale2scale-up with number of eduroam SPs connected) For production, the VMs need to be in different locations for redundancy. |
| Hardware requirements (CPU, RAM, disk space) | 1 CPU, 1 GB RAM, 10 GB disk space | 1 CPU, 512 MB RAM, 50 GB disk space |
| Network connection requirements | standard | standard |
| IP addressing requirements (IPv4, IPv6, public route) | IPv4 and IPv6 publicly reachable, static addresses | 2 x IPv4 and 2 x IPv6 publicly reachable, static addresses (one mgmt IP, one production IP)). Production IP must be stable when transitioning between Pilot and Production to avoid forcing eduroam SP reconfiguration. |
Naming requirements1 | msp-pilot.eduroam.org (DNS maintained by eduroam OT) | msp-radius-1...n.eduroam.org (DNS maintained by eduroam OT) |
Infrastructure Hosting Requirements
Hosting requirements | Applying to Web Frontend VM | Applying to RADIUS SP Proxy VM |
|---|---|---|
Availability | 99.9% | 99.99% |
Backup (what, frequency, retention period) | What: database contents, product configuration, product logs Frequency: once per day Period: 1 month | What: database contents, product configuration, product logs Frequency: once per day Period: 1 month |
Monitoring and alerting1 | IPv4 and IPv6 reachability HTTPS on IPv4 and IPv6 MariaDB server running? memory and disk usage | IPv4 and IPv6 reachability RADIUS responsivity on RADIUS/UDP master port (monitoring script to be made available) MariaDB server running? memory and disk usage |
Measuring and Reporting2 | number of eduroam SPs enrolled, monthly (figure can be read from UI, cumulative) | number of eduroam authentications proxied, monthly (automated SQL query can be crafted upon request) |
Log retention3 | for each month, 1 of the database backups should be retained "forever" product logs should be retained for 6 months | for each month, 1 of the database backups should be retained "forever" product logs should be retained for 6 months |
Security policy for access and usage4 | The log and database should be accessible only to OT personnel. There is next to no PII in the log files or database - limited to ePTID of administrators | The log and database should be accessible only to OT personnel. There is next to no PII in the log files or database - limited to normal RADIUS proxy logs, with identical GDPR treatment requirements as ETLR logs). |
1As the minimum, network accessibility (outside of LAN) and hardware resource usage must be monitored. Indicate if some of these resources can be deemed critical so that adequate thresholds for alerting are implemented. Additional, indicate which specific applications uptime and operational health must be monitored and alerting implemented.
2Define what should be measured, how and with what period in order to deliver appropriate reporting relating to KPIs, usage, etc.
3Define which logs should be kept in order to have debugging data and data in case of misuse of the service, and how long logs should be retained.
4Define the policy for limiting access to the piece of the infrastructure and where it should be implemented (system level, network level etc.)
System and Application Maintenance Requirements
System and application requirements | Applying to Web Frontend VM | Applying to RADIUS SP Proxy VM |
|---|---|---|
Operating system | RHEL / CentOS / Rocky 8 | RHEL / CentOS / Rocky 8 |
Applications1 | Apache + PHP + MariaDB | base install (package installations Ansible managed) |
| Maintenance hours2 | Pilot: European standard (outside typical office hours CET) Production: product is used world-wide - there is never a good time | any time so long as only one VM is out of service at any given time |
Configuration management3 | currently none (Git desired) | configuration auto-generated (Ansible + R Config API) |
1 List the applications installed on a system, and add corresponding licenses where applicable.
2 Define the appropriate time window for regular maintenance or give some recommendations.
3 Applies to automatised configuration management. Describe the system used.
Human Resources Requirements
Indicate requirements both in skills and manpower needed, for personnel needed for the DevOps team (that maintains service specific applications) and for L2 support.
Human resources requirements | Applying to Group_1_distinguisher | Applying to Group_2_distinguisher |
|---|---|---|
Description | ||
Manpower (in % of FTE) | ||
| Recommended number of persons (considering backup) | ||
| Skills |