Eric, Great, IP as delivery unit. Note that I believe the port is part of this unit, and not a common settings to all IPs in the interface.
+1 for Rob's suggestion (stats are collected on the interface level, and health/heartbeat on the ip level) Rob/Jeff I believe we need to verify this entire concept fits well with monitor and router localization. Nir On Wed, Apr 4, 2018, 17:23 Robert Butts <[email protected]> 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) < > [email protected]> 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 <[email protected]> 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)" <[email protected]> > > > wrote: > > > > > > Updated the DB schema in section 3.1.1.4 > > > > > > Thanks, > > > Zhilin > > > > > > > > > > > > On 04/04/2018, 11:02 AM, "Zhilin Huang (zhilhuan)" < > [email protected]> > > > 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)" < > > [email protected]> > > > 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 additional features like sharing edges between public/private > > networks > > > or having multiple (equal priority) streaming interfaces on a cache. > > > > > > These future features would be easier if the interface data and > IP > > > data is all organized into separate tables. > > > > > > I’d also like to see the delivery service to IP mapping be a > many > > > to many mapping in the DB. For this particular feature we will only > > assign > > > a single IP (and we can restrict that in the API if we want), but I am > > near > > > certain that in the future we would like the ability to assign a DS to > > > multiple IPs on the same cache. > > > > > > > > > —Eric > > > > > > > > > > > >> On Apr 3, 2018, at 2:42 AM, Zhilin Huang (zhilhuan) < > > > [email protected]> wrote: > > >> > > >> Hi Mark, > > >> > > >> Thanks for your comments. Please check my reply in another thread: > > >> > > >> If we all agreed to use unified tables for all IPs and/or > > > interfaces: primary, management, secondary, then there need to be two > > > tables: IP and interface. > > >> And in the server table, we need to replace the original > > > "interface_xxx", "ip_xxx", "ip6_xxx" fields with a "primary_ip_id" > field. > > > And do similar things to management IP. > > >> > > >> Thanks, > > >> Zhilin > > >> > > >> > > >> On 03/04/2018, 7:08 AM, "Mark Torluemke" <[email protected]> > > > wrote: > > >> > > >> I would support an 'interfaces' table (adding some sort of a > > > 'type' column) > > >> that would include moving the management and lights out > > > management > > >> interfaces to that table as well. > > >> > > >> Cheers, > > >> Mark > > >> > > >> On Mon, Apr 2, 2018 at 2:39 PM, Nir Sopher <[email protected]> > > > wrote: > > >> > > >>> Hi Zhilin, > > >>> > > >>> I took a quick look into the spec. Hope to have the opportunity > > > to dive > > >>> deeper into it soon so we can further discuss it. > > >>> > > >>> For now I have a 2 questions. > > >>> In the spec, you refer to "secondary interfaces", and you have a > > > list of > > >>> secondary interfaces added. > > >>> IIUC the secondary interfaces are used as long as they are > > > available, and > > >>> when down, you move to the primary interface. > > >>> > > >>> Why not, instead of holding a secondary interfaces table, move > > > all > > >>> interfaces to a separate table? Primary and secondary. > > >>> For each interface you can hold: > > >>> > > >>> - Server id > > >>> - name (e.g. eth0) > > >>> - IPv6 > > >>> - IPv4 > > >>> - Priority (Integer as flexible as you wish: e.g. "1" for > > > "secondary", > > >>> "2" for "primary" in your example,) > > >>> > > >>> > > >>> Additionally, it is not clear to me what happens if one of the > > > interfaces > > >>> fails? > > >>> Does every interface has a unique DNS name? If an interface > > > fails, are > > >>> redirects > > >>> sent only to the available (secondary) interfaces? > > >>> > > >>> Thanks, > > >>> Nir > > >>> > > >>> > > >>> On Mon, Apr 2, 2018 at 10:21 AM, Zhilin Huang (zhilhuan) < > > >>> [email protected] > > >>>> wrote: > > >>> > > >>>> Hi Guys, > > >>>> > > >>>> This was originally posted in another discussion. Resend this > > > in a > > >>>> standalone topic to catch more awareness. The link for the > > > design doc: > > >>>> > > > https://docs.google.com/document/d/1vgq-pGNoLLYf7Y3cu5hWu67TUKpN5hucrp > > >>>> -ZS9nSsd4/edit?usp=sharing > > >>>> > > >>>> > > >>>> Short summary for the feature design: > > >>>> --- > > >>>> There is feature request from market to add secondary IPs > > > support on edge > > >>>> cache servers, and the functionality to assign a delivery > > > service to a > > >>>> secondary IP of an edge cache. > > >>>> > > >>>> This feature requires Traffic Ops implementation to support > > > secondary IP > > >>>> configuration for edge cache, and delivery service assignment to > > >>> secondary > > >>>> IP. > > >>>> > > >>>> Traffic Monitor should also monitor connectivity of secondary > > > IPs > > >>>> configured. And Traffic Router needs support to resolve > > > streamer FQDN to > > >>>> secondary IP assigned in a delivery service. > > >>>> > > >>>> Traffic Server should record the IP serving client request. And > > > should > > >>>> reject request to an unassigned IP for a delivery service. > > >>>> > > >>>> This design has taken compatibility into consideration: if no > > > secondary > > >>> IP > > >>>> configured, or some parts of the system has not been upgraded > > > to the > > >>>> version supports this feature, the traffic will be served by > > > primary IPs > > >>> as > > >>>> before. > > >>>> --- > > >>>> > > >>>> Much appreciated and welcome to any comments. If no major > > > objections, we > > >>>> planned to start coding this week. > > >>>> > > >>>> Thanks, > > >>>> Zhilin > > >>>> > > >>>> > > >>> > > >> > > >> > > > > >
