[jira] [Updated] (TC-90) TR should check for closest cache group because using Maxmind Geolocation

["Ryan Durfey (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TC-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Durfey updated TC-90:
--------------------------
    Labels: cache_group routing  (was: )

> TR should check for closest cache group because using Maxmind Geolocation
> -------------------------------------------------------------------------
>
>                 Key: TC-90
>                 URL: https://issues.apache.org/jira/browse/TC-90
>             Project: Traffic Control
>          Issue Type: Bug
>          Components: Traffic Router
>    Affects Versions: 1.8.0
>            Reporter: Eric Friedrich
>            Priority: Minor
>              Labels: cache_group, routing
>
> Problem Statement: 
> If all caches in the primary cache group are unavailable, our goal is to provide a backup routing policy for RFC1918 clients. 
> When client IP is an public Internet IP, the current backup policy is to assign the client to the geographically closest cache (Distance = MaxMind Geo Lat/Long - configured CG lat/long). 
> With Jeff's proposed fix below, instead of going to the geolocation provider, TR would find the cache group closest to the CZF "hit" cache group. 
> From Jeff Elsoo:
> There's a small logic gap in the existing algorithm around cache
> location selection and I think if we fix that (two line change), we
> should be better off all around. I think the only time we'd ever want
> to go to the geolocation provider is in the event of a miss on the
> CZF, so as long as we have a hit there, we should find the cache group
> closest to that hit location that has available caches. This would
> automatically provide the "backup" cache group concept, and has the
> added benefit of doing this selection dynamically based on the state
> of the CDN.
> See this to get an idea of what I mean: http://apaste.info/u3PQo
> Obviously we'd need to test this to ensure we don't break other functionality.
> dev@ Discussion Thread: https://lists.apache.org/thread.html/b033b3943c22a606370ad3981fa05fb0e7039161b88bbc035bc49b25@%3Cdev.trafficcontrol.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)