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
