Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Bellwether: Surrogate Services for Popular Content Duane Wessels & Ted Hardie NANOG 19 June 12, 2000 The Slashdot Effect is a DDOS • “CNN Events” can: – melt your network – overwhelm servers dedicated to specific content – prevent maintenance designed to fix the problem. • This creates a denial of service for other content hosted on that network. A moving target is harder to hit. • A demand-driven surrogate located at the network border: – Moves the content away from low capacity networks. – Can handle the traffic for sites which experience sudden popularity. – Can help keep internal links uncongested What is a surrogate? surrogate: An intermediary program which acts as a server or tunnel for the purpose of responding to requests on behalf of one or more origin servers. Requests are serviced internally from a cache or by tunnelling them on to origin servers. Surrogates are also known as "reverse proxies" and "(origin) server accelerators". » Draft-ietf-wrec-taxonomy-03.txt No, really, what is a surrogate? • Proxies act on behalf of users; surrogates act on behalf of content providers. • A surrogate is any network element that acts on behalf of an origin server to respond to queries: – A mirror is a pre-populated surrogate. – A content delivery network (Akamai, Adero, Mirror Image) may provide surrogate services. – A demand-driven surrogate is a system activated only when popularity overloads an origin server or its network. Bellwether • Demand-driven surrogate based on – – – Squid Zebra, FreeBSD • • – IP firewall GRE And ideas stolen from CenterTrack. A picture is worth 1K words: Step 1: Administrative Setup • Configure a GRE tunnel from the surrogate to an internal router. • Configure the surrogate as a BGP peer of the border router. • Add origin hostnames to Squid access control list. Step 2: Activation • The surrogate injects a route to the popular origin server into border router’s BGP table. • The surrogate configures firewall rules to divert new HTTP connections to Squid. • Existing TCP connections and other traffic flow through GRE tunnel to the origin. Step 3: Operation • Squid creates a cache of popular content by forwarding requests to the origin server via the GRE tunnel and storing responses. • Cache hits are served from Squid, reducing the load on origin server and network alike. Simulation Workload • An origin server with a network bottleneck publishes suddenly popular content. • Client requests increase from 5 to 100 per second over 15 minutes. • Content remains popular for 2 hours, then trails off over 4 hours. • Target hit ratio is 90%. • Surrogate is PII/333 with 512 RAM and 2 SCSI disks. What if you need more? • For this result set, the surrogate is a dual PIII/550 Xeon with 2GB RAM and 10 SCSI disks. • Peak throughput is 475 HTTP requests per second. – Mean response size is 13KB. – About 45 Mbps of data flow. Next Steps • Improve error handling. – Handle overload by passing overflow traffic back to origin server. – Withdraw route in the event of Squid failure. • Use NECP to signal surrogate to start/stop service. – NECP daemon process and API – Prototype integration in Apache • Integration with higher layer switches. Final Questions • When you see a popularity spike, what melts? • What kinds of processes and devices need to activate a surrogate? Handy URLs: • To pick up a copy of bellwether: – ftp://ftp.equinix.com/bellwether • To discuss surrogate deployments: – [email protected] – (Majordomo syntax) • Contact Ted or Duane: – [email protected] – [email protected]