We differ between the master and N x slave NMS PRIME instances. The primary instance is also running the NMS PRIME GUI. Any changes in GUI will trigger realtime changes in any config, like DHCP, TFTP, ... via Laravel Observers or Jobs. The slaves are running on separate machines without a GUI. They are rebuilding DHCP, BIND, and TFTP configfiles on a regular base (e.g. 1 hour) via cronjob. The slaves are independent from Master and they are only connected towards MariaDB SQL cluster via a SQL read-only connection. So any changes in Master will be directly distributed towards SQL cluster and later automatically fetched from the slaves.
This concept offers:
a Master with real-time changes towards all critical configs
redundant slaves who is independent off Master
a redundant database with load-sharing possibility
Load-Sharing for either DHCP, DNS and TFTP for all Modems
5. Critical Services
ISC-DHCP
Normal ISC-DHCP failover with Master-Slave Concept:
Cronjob at slave will rebuild all configfiles on a recurring basis (e.g. every hour). In NMS Prime this could simply be done by running
Possible Cronjob for Slaves
e.g. possible cronjob
php artisan nms:dhcp && systemctl restart dhcp
e.g. possible cronjob
php artisan nms:configfile
implementing this into Laravel scheduling framework (for slaves only!) will be a advance especially if building all config files could take longer than rebuild loop, since this could be easy avoided using ->withoutOverlapping():