@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" <robert.o.bu...@gmail.com> 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 <n...@qwilt.com> 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)" <zhilh...@cisco.com>
> > wrote:
> >
> > Updated the DB schema in section 3.1.1.4
> >
> > Thanks,
> > Zhilin
> >
> >
> >
> > On 04/04/2018, 11:02 AM, "Zhilin Huang (zhilhuan)" <zhilh...@cisco.com>
> > 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 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) <
> > zhilh...@cisco.com> 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" <mtorlue...@apache.org>
> > 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 <n...@qwilt.com>
> > 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) <
> >>> zhilh...@cisco.com
> >>>> 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
> >>>>
> >>>>
> >>>
> >>
> >>
>
>
