Hi Eric, How does the backup list relate to the RFC1918-is-not-in-geo problem?
To get to a cachegroup you need to get a match in the coverage zone, I would think? Rgds, JvD > On Dec 22, 2016, at 12:28, Eric Friedrich (efriedri) <[email protected]> > wrote: > > The current behavior of cache group selection works as follows > 1) Look for a subnet match in CZF > 2) Use MaxMind/Neustar for GeoLocation based on client IP. Choose closest > cache group. > 3) Use Delivery Service Geo-Miss Lat/Long. Choose closest cache group. > > > For deployments where IP addressing is primarily private (say RFC-1918 > addresses), client IP Geo Location (#2) is not useful. > > > We are considering adding another field to the Coverage Zone File that > configures an ordered list of backup cache groups to try if the primary cache > group does not have any available caches. > > Example: > > "coverageZones": { > "cache-group-01": { > “backupList”: [“cache-group-02”, “cache-group-03”], > "network6": [ > "1234:5678::\/64”, > "1234:5679::\/64"], > "network": [ > "192.168.8.0\/24", > "192.168.9.0\/24”] > } > > This configuration could also be part of the per-cache group configuration, > but that would give less control over which clients preferred which cache > groups. For example, you may have cache groups in LA, Chicago and NY. If the > Chicago Cache group fails, you may want some of the Chicago clients to go to > LA and some to go to NY. If the backup CG configuration is per-cg, we would > not be able to control where clients are allocated. > > Looking for opinions and comments on the above proposal, this is still in > idea stage. > > Thanks All! > Eric > >
