Hi Nir,
As there is only 1 ATS instance inside an edge server, the port should be a
common setting. Currently ATS service will be bind to 0.0.0.0:<port
configured>, we do not see any benefit to change this.
Thanks,
Zhilin
On 05/04/2018, 12:34 AM, "Nir Sopher" <n...@qwilt.com> wrote:
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 <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
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> >
> >
>
