Service Redundancy and Traffic Balancing

Using AnycastSean Jain Ellis

sellis@bandarji.comTwitter @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 AddressingAll 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.confhostname 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 HostFailure 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

sellis@bandarji.comTwitter @bandarji