You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Zhilin Huang (zhilhuan)" <zh...@cisco.com> on 2018/04/02 07:21:28 UTC
Traffic Server Secondary Streaming IPs Design
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
Re: Traffic Server Secondary Streaming IPs Design
Posted by "Zhilin Huang (zhilhuan)" <zh...@cisco.com>.
Hi Nir,
Thanks a lot for your comments!
As Eric stated, we are using a secondary (streaming) IP to serve specific delivery service. In other words, a primary or secondary IP is assigned to a specific delivery service. So there is no traffic move.
For your comments:
> 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,)
There are two reasons we use separate tables for secondary IPs and interfaces:
1) The secondary IPs and/or interfaces are optional, but primary IP and interface is mandatory for each server.
2) We want to make little change on existing data structure to avoid compatibility issue.
If in the community, we agreed to use unified tables for all IPs and/or interfaces: primary, management, secondary, then there need to be two tables: IP and interface.
Reason: There could be several secondary IPs configured on an interface (no matter primary or secondary). Secondary interface is optional for configuring secondary IPs.
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.
> Additionally, it is not clear to me what happens if one of the interfaces
> fails?
As stated above, it is simply unavailable, and service will fail.
> Does every interface has a unique DNS name? If an interface fails, are
> redirects
> sent only to the available (secondary) interfaces?
No. A secondary IP is just set as an A record for streamer FQDN of a specific DS by Traffic Router.
Thanks,
Zhilin
On 03/04/2018, 9:07 AM, "Eric Friedrich (efriedri)" <ef...@cisco.com> wrote:
For our particular use case, it is important that if a secondary IP is down, the traffic does not move to the primary IP.
This use case relates to use of the source IP address to differentiate traffic for billing purposes. We don’t want traffic to move to the primary IP as this would miscategorize the traffic.
—Eric
> On Apr 2, 2018, at 4:39 PM, Nir Sopher <ni...@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) <zhilhuan@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
>>
>>
Re: Traffic Server Secondary Streaming IPs Design
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
For our particular use case, it is important that if a secondary IP is down, the traffic does not move to the primary IP.
This use case relates to use of the source IP address to differentiate traffic for billing purposes. We don’t want traffic to move to the primary IP as this would miscategorize the traffic.
—Eric
> On Apr 2, 2018, at 4:39 PM, Nir Sopher <ni...@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) <zhilhuan@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
>>
>>
Re: Traffic Server Secondary Streaming IPs Design
Posted by Nir Sopher <ni...@qwilt.com>.
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) <zhilhuan@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
>
>