Re: Traffic Server Secondary Streaming IPs Design
@Robert I didn’t notice the health poll is for the cache, thanks for pointing this out. If so, it should work. On 4/4/18, 10:23 PM, "Robert Butts" wrote: @nbaoping > So I suggest the change to the current TM to be like: > 1) Separate the current polling of cache servers into two different pollings, one for the keep alive, the other for the stat query. The Golang Monitor already does this. We call it the "health" and "stat" polls in the code. The stat poll is the full stats, and the health poll is just the system stats. Does that work for your keep-alive poll? The health poll is slightly more than just establishing a TCP connection, but it's very small, and it also gives us the interface data. > We need record the availability for each configured IP so that if it’s assigned, the router can check if it can redirect the client request to that assigned IP or not. > if we have multiple interfaces support, we should check the bandwidth availability for each interface Because the health poll has interface data, I'd suggest modifying Traffic Monitor to poll a single arbitrary IP for the Stat poll, as you suggest; and to poll all IPs on the Health poll. Then, because the system stats are in the health poll, the Monitor can figure out which interface that IP is on, and track the availability of that interface from that health poll data. If you aren't familiar with the Health vs Stat polls in the new Golang Monitor, see: https://traffic-control-cdn.readthedocs.io/en/latest/ development/traffic_monitor_golang.html#architecture https://github.com/apache/incubator-trafficcontrol/blob/ master/traffic_monitor/manager/manager.go https://github.com/apache/incubator-trafficcontrol/blob/ master/traffic_monitor/manager/health.go https://github.com/apache/incubator-trafficcontrol/blob/ master/traffic_monitor/manager/stat.go Does that work? On Wed, Apr 4, 2018 at 5:07 AM, Eric Friedrich (efriedri) < efrie...@cisco.com> wrote: > Hey Nir- > For our particular use case, we are looking at making an IP the delivery > unit. We would like to use a single interface with multiple IPs. DSs would > be assigned to one of the IPs on that interface. Interface (or IP) > priority does not come into play here as there is no failover between IPs > > —Eric > > > > On Apr 4, 2018, at 1:23 AM, Nir Sopher wrote: > > > > +1 > > Note that beyond the DB, the change should also be reflected into the > > cr-config. > > As I see it, a flexible model may be built of the below items: > > 1 - Edge server. > > 2- Interface > > 3. IPs > > > > The Interface (or should it be called "delivery unit") is the element we > > redirect the traffic to and which is monitored by the traffic-monitor: > > * Each server may have multiple interfaces > > * Each interface may have multiple IPs > > * Interfaces has priorities (abstraction for primary/secondary) > > * Each interface is given a seperate DNS name by the router. Single name > > for the multiple IPs. > > * Each interface is monitored and reported seperately by the traffic > > monitor, including health an stats. > > > > > > The router "redirect target decision" may look as follows > > 0. Select cache as we do today taking into account the consistent hash. A > > server is in the selection group only if one of its interfaces is found > to > > be healthy > > 1. Once we have server selected, select an interface out of all > interfaces > > of the server with max available priority. > > > > An additional improvement, may assign DS to interfaces instead of > servers. > > A server serves DS X iff one of its interfaces is assigned to the DS. > > > > Nir > > > > > > On Apr 4, 2018 6:56 AM, "Zhilin Huang (zhilhuan)" > > wrote: > > > > Updated the DB schema in section 3.1.1.4 > > > > Thanks, > > Zhilin > > > > > > > > On 04/04/2018, 11:02 AM, "Zhilin Huang (zhilhuan)" > > wrote: > > > >Good points. I am happy to make this change in the design doc. > > > >Thanks, > >Zhilin > > > > > >On 03/04/2018, 8:17 PM, "Eric Friedrich (efriedri)" < > efrie...@cisco.com> > > wrote: > > > >I would prefer a consistent way to store all interface and IP > > address information. Its good database design practice to store similar > > information in similar tables (i.e. all IP info in 1 table) rather than > > keep some IPs in the server table and some IPs in another table. > > > >I also think this refactoring will give us greater flexibility for > > more changes in the future. Outside of this particular use case, we might > > have add
Re: Traffic Server Secondary Streaming IPs Design
Hi guys, It’s really exciting that we are moving to one flexible solution to have the IP and interface tables separately. Based on this, I have some ideas for the change of the Traffic Monitor(TM). Actually, the TM have two different purposes to polling the cache servers. One is to make sure the connectivity is ok, the other is to query the stat of the interface. The connectivity is actually for the IP (with port) connectivity, while the stat is for the interface. Since we will have multiple interfaces and may have multiple IPs for each interface, I think the polling to the cache server should be like: 1) Check the connectivity of all the configured IPs of the cache server This function works like the keep alive to make sure all the configured IPs is reachable. 2) Query the stat for all the configured interfaces of the cache server This function is to query the interfaces stat, it doesn’t care which IP will be used to query the stat. So I suggest the change to the current TM to be like: 1) Separate the current polling of cache servers into two different pollings, one for the keep alive, the other for the stat query. For the keep alive polling, we can use some specific url to check if the IP with port is opened or not; For the stat query, we will reuse the astats plugin, but need a little change to the uri to support returning multiple interfaces stat in the same request. If we don’t separate it, we will have to issue each stat query for each IP, and all the IPs of one interface will return the same big response, which is unnecessary, and will bring much more unnecessary load to the ATS and TM. If we separate it, we could make the keep alive check very light weighted, and also can use one request to query all the configured interfaces stat. Besides, we could also use different polling intervals for the keep alive and stat query. 2) The health availability of the cache server will be based on the configured IPs of the cache server Currently, we only have the availability of one cache server, but it will not be enough when we add multiple interfaces and multiple IPs support. We need record the availability for each configured IP so that if it’s assigned, the router can check if it can redirect the client request to that assigned IP or not. 3) The max available bandwidth check should be changed to per interface. Currently, the max available bandwidth is only for the primary interface of the cache server, if we have multiple interfaces support, we should check the bandwidth availability for each interface. If one interface is overload, we will mark all the IPs of that interface to be unavailable. 4) We will pick up one available IP to query the stat. Currently, we use the fqdn of the cache server to query the stat, since we will have multiple IPs, we could pick up one available IP to query. Best regards, Neil On 4/4/18, 1:23 PM, "Nir Sopher" wrote: +1 Note that beyond the DB, the change should also be reflected into the cr-config. As I see it, a flexible model may be built of the below items: 1 - Edge server. 2- Interface 3. IPs The Interface (or should it be called "delivery unit") is the element we redirect the traffic to and which is monitored by the traffic-monitor: * Each server may have multiple interfaces * Each interface may have multiple IPs * Interfaces has priorities (abstraction for primary/secondary) * Each interface is given a seperate DNS name by the router. Single name for the multiple IPs. * Each interface is monitored and reported seperately by the traffic monitor, including health an stats. The router "redirect target decision" may look as follows 0. Select cache as we do today taking into account the consistent hash. A server is in the selection group only if one of its interfaces is found to be healthy 1. Once we have server selected, select an interface out of all interfaces of the server with max available priority. An additional improvement, may assign DS to interfaces instead of servers. A server serves DS X iff one of its interfaces is assigned to the DS. Nir On Apr 4, 2018 6:56 AM, "Zhilin Huang (zhilhuan)" wrote: Updated the DB schema in section 3.1.1.4 Thanks, Zhilin On 04/04/2018, 11:02 AM, "Zhilin Huang (zhilhuan)" wrote: Good points. I am happy to make this change in the design doc. Thanks, Zhilin On 03/04/2018, 8:17 PM, "Eric Friedrich (efriedri)" wrote: I would prefer a consistent way to store all interface and IP address information. Its good database design practice to store similar information in similar tables (i.e. all IP info in 1 table) rather than keep some IPs in the server table and some IPs in another table. I also t
Re: Question about the poll model of the Traffic Monitor
r more NICs). > > > > Assume all addresses are reachable from the TM. > > > > —Eric > > > > > > > On Mar 28, 2018, at 11:37 AM, Robert Butts > > wrote: > > > > > > When you say different interfaces, do you mean IPv4 versus IPv6? Or > > > something else? > > > > > > If you mean IPv4 vs IPv6, we have a PR for that from Dylan Volz > > > https://github.com/apache/incubator-trafficcontrol/pull/1627 > > > > > > I'm hoping to get to it early next week, just haven't found the time to > > > review and test it yet. > > > > > > Or did you mean something else by "interface"? Linux network > interfaces? > > > Ports? > > > > > > > > > On Wed, Mar 28, 2018 at 12:02 AM, Neil Hao (nbaoping) < > > nbaop...@cisco.com> > > > wrote: > > > > > >> Hi, > > >> > > >> Currently, we poll exact one URL request to each cache server for one > > >> interface, but now we’d like to add multiple interfaces support, > > therefore, > > >> we need multiple requests to query each interface of the cache > server, I > > >> check the code of Traffic Monitor, it seems we don’t support this kind > > of > > >> polling, right? > > >> > > >> I figure out different ways to support this: > > >> 1) The first way: change the ‘Urls’ field in the HttpPollerConfig from > > >> ‘map[string]PollConfig’ to ‘map[string][]PollConfig’, so that we can > > have > > >> multiple polling config to query the multiple interfaces info. > > >> > > >> 2) The second way: Change the ‘URL’ field in the PollConfig from > > ‘string’ > > >> to ‘[]string’. > > >> > > >> No matter which way, it seems it will bring a little big change to the > > >> current polling model. I’m not sure if I’m on the right direction, > would > > >> you guys have suggestions for this? > > >> > > >> Thanks, > > >> Neil > > >> > > > > >
TM: Question about the poll model of the Traffic Monitor
Hi, Currently, we poll exact one URL request to each cache server for one interface, but now we’d like to add multiple interfaces support, therefore, we need multiple requests to query each interface of the cache server, I check the code of Traffic Monitor, it seems we don’t support this kind of polling, right? I figure out different ways to support this: 1) The first way: change the ‘Urls’ field in the HttpPollerConfig from ‘map[string]PollConfig’ to ‘map[string][]PollConfig’, so that we can have multiple polling config to query the multiple interfaces info. 2) The second way: Change the ‘URL’ field in the PollConfig from ‘string’ to ‘[]string’. No matter which way, it seems it will bring a little big change to the current polling model. I’m not sure if I’m on the right direction, would you guys have suggestions for this? Thanks, Neil
