mirror of
https://github.com/vmstan/gravity-sync.git
synced 2025-07-08 18:34:04 -04:00
Updated Reference Architectures (markdown)
parent
7168b75c7b
commit
9b19267ea8
@ -23,16 +23,4 @@ One way to get around having logging in two places is by using keepalived and pr
|
|||||||
2. The VIP managed by the keepalived service will determine which Pi-hole responds. You make your configuration changes to the active VIP address.
|
2. The VIP managed by the keepalived service will determine which Pi-hole responds. You make your configuration changes to the active VIP address.
|
||||||
3. Client queries the single DNS servers, and Pi-hole does it's thing.
|
3. Client queries the single DNS servers, and Pi-hole does it's thing.
|
||||||
|
|
||||||
You make your configuration changes to the active VIP address and they will be sync'd to the other within the timeframe you establish (here, 15 minutes.)
|
You make your configuration changes to the active VIP address and they will be sync'd to the other within the timeframe you establish (here, 15 minutes.)
|
||||||
|
|
||||||
### Crazy Town
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
For those who really love Pi-hole and Gravity Sync. Combining the best of both worlds.
|
|
||||||
|
|
||||||
1. Client requests an IP address from a DHCP server on the network and receives it along with DNS and gateway information back. Two DNS servers (VIPs) are returned to the client.
|
|
||||||
2. The VIPs are managed by the keepalived service on each side and will determine which of two Pi-hole responds. You can make your configuration changes to the active VIP address on either side.
|
|
||||||
3. Client queries one of the two VIP servers, and the responding Pi-hole does it's thing.
|
|
||||||
|
|
||||||
Here we use `./gravity-sync pull` on the secondary Pi-hole at each side, and off-set the update intervals from the main sync.
|
|
Loading…
x
Reference in New Issue
Block a user