Service Redundancy and Traffic Balancing Using Anycast

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

Service Redundancy and Traffic Balancing Using Anycast

by Sean Jain Ellis on Jan 19, 2012

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 7

Statistics

Service Redundancy and Traffic Balancing Using Anycast — Presentation Transcript