• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Service Redundancy and Traffic Balancing Using Anycast
 

Service Redundancy and Traffic Balancing Using Anycast

on

  • 3,246 views

Presentation for Large Scale Production Engineering (#lspe) January 2012 meeting.

Presentation for Large Scale Production Engineering (#lspe) January 2012 meeting.

Statistics

Views

Total Views
3,246
Views on SlideShare
3,226
Embed Views
20

Actions

Likes
2
Downloads
36
Comments
0

2 Embeds 20

https://twitter.com 13
http://a0.twimg.com 7

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • show route table inet 172.17.13.10 show route forwarding-table family inet destination 172.17.13.10 # show ip cef 172.17.13.10 internal # show ip cef 172.17.13.10 interface # show ip cef # show cef interface gix/x/x

Service Redundancy and Traffic Balancing Using Anycast Service Redundancy and Traffic Balancing Using Anycast Presentation Transcript

  • Service Redundancy and Traffic Balancing Using Anycast Sean Jain Ellis [email_address] Twitter @bandarji
  • Traditional Load Balancer Function
    • Balances connections between servers
    • Routes requests to healthy systems
    • Handles site failure
  • What is Anycast?
    • Anycast is a method by which dynamic routing protocols are used to direct traffic to the best candidate server or servers within a group of potential destinations, all sharing the same address.
    • Benefits
    • High availability
    • Load balancing
    • Consistent configuration
    • Dispersed deployment
  • Really, what is Anycast?
    • Each service assigned an address
    • Same address applied to all servers ’ on loopback
    • Servers advertise host route to loopback address
      • Servers become routers, integrating with infrastructure
      • Use zebra or quagga software daemons
      • Ethernet interface becomes gateway for upstream routers
    • Regardless of location
      • Refer client connections to service address
      • Routers determine server to terminate connections
  • Anycast Addressing
    • All servers share logical address 172.17.13.10.
  • Routers As Load Balancers
    • Traffic directed to destination with least cost
    • When two or more destinations are equal
      • Select gateways by round robin algorithm
      • Maintain connection table, ensuring server affinity
    • When low cost destinations disappear
      • Select gateway(s) to destination of equal, higher cost
      • Listen for returning low cost routes
    • Why not? The hardware is already present
  •  
  • What You Need
    • Routing protocol daemon zebra or quagga
    • Tool to monitor service
      • monit, netcat, curl
    • Coordination from network team
      • Routing protocol parameters
      • SNMP access
      • Console (administrative) access too much to ask?
  • Server Configuration
    • First: define logical addressing scheme
    • Determine routing protocol
    • Assign an address for service
    • Configure loopback interface with service address
    • Configure routing protocol on server
  • Server Configuration in Detail
    • Example is for CentOS host using quagga from EPEL
    • /etc/sysconfig/network-scripts/ifcfg-lo:[0-x]
    • /etc/quagga/zebra.conf
    • /etc/quagga/ospfd.conf
  • Sample /etc/quagga/zebra.conf
    • hostname ServerA
    • interface lo:0
    •   ip address 172.17.13.10/32
    • interface eth0
    •   ip address 172.17.13.40/27
  • Sample /etc/quagga/ospfd.conf
    • hostname ServerA
    • interface eth0
    •   ip ospf authentication message-digest
    •   ip ospf message-digest-key 1 md5 apasswd
    •   ip ospf priority 0
    •   ip ospf hello-interval 1
    •   ip ospf dead-interval 4
    • router ospf
    •   ospf router-id 172.17.12.40
    •   area 94.40.30.0 authentication message-digest
    •   network 172.17.13.10/32 area 94.40.30.0
    •   network 172.17.12.32/27 area 94.40.30.0
  • Routing Must Be Per-Flow
    • JUNOS
    • set policy-options policy-statement ecmp then load-balance per-packet
    • set routing-options forwarding-table export ecmp
    • edit forwarding-options hash-key family inet
    •   set layer-3
    •   set layer-4
    • cisco IOS
    • int gi0/0/0
    •   ip load-sharing per-destination
    • router ospf 1
    •   maximum-paths 8
    • ip cef accounting load-balance-hash
  • Standby Host
    • Failure of the server(s) on Network One causes routing to switch to server(s) on Network Two. Network One could be a single system with server in Network Two serving as a standby host, if per-flow routing is not an option.
  • Failure Recovery
    • OSPF hello packets
      • One second interval
      • Dead timer of four seconds
    • Faster? Use bidirectional forwarding detection (BFD)
  • OSPF vs BGP
    • vi vs emacs
    • Go with whatever network folks offer
    • However!
    • BGP allows for server-side policies to control traffic
    • OSPF traffic controls are configured per router interface
  • Thank You Sean Jain Ellis [email_address] Twitter @bandarji