evaluation of replica placement and retrieval algorithms
play

Evaluation of Replica Placement and Retrieval Algorithms in Self - PowerPoint PPT Presentation

Evaluation of Replica Placement and Retrieval Algorithms in Self Organizing CDNs Jan Coppens, Tim Wauters, Filip De Turck, Bart Dhoedt and Piet Demeester IFIP/IEEE International Workshop onSelf-Managed Systems & Services (SELFMAN)


  1. Evaluation of Replica Placement and Retrieval Algorithms in Self Organizing CDNs Jan Coppens, Tim Wauters, Filip De Turck, Bart Dhoedt and Piet Demeester IFIP/IEEE International Workshop onSelf-Managed Systems & Services (SELFMAN)

  2. Overview • CDN Architecture • Replica Placement Algorithms • Reference solution by means of an ILP • General real-time placement heuristics • COCOA heuristic • Evaluation of the placement algorithms • Complexity and scalability • Performance analysis of the RPA algorithms • Using Traffic Engineering for load balancing • Conclusion and future work Dept. of Information Technology - Ghent University 2

  3. Content Distribution Networks • Replicate and distribute the content to the edges of the network • Increase availability and throughput • Decrease end-to-end delay and packet loss • Focus on the delivery of video streams Replica Server Origin Server Server Replica Server Central Server Approach Content Distribution Network Dept. of Information Technology - Ghent University 3

  4. CDN Architecture • Layered architecture for a content distribution network • Consists of multiple functional modules C o n t e n t D i s t r i b u t i o n M o d u l e C o n t e n t R e t r i e v a l M o d u l e C l i e n t R e q u e s t CDN Operation C o n t e n t C o n t e n t R e t r i e v a l P l a c e m e n t T i m e Layer 3 C o n t e n t L o c a t i o n A l g o r i t h m D a t a b a s e I n t e r v a l R e p l i c a P l a c e m e n t C o n f i g u r e I n i t i a t e A l g o r i t h m M o n i t o r e d T r i g g e r e d N e t w o r k S e r v e r I n f o r m a t i o n E v e n t CDN Network M u l t i c a s t a n d T E C o n t e n t S e r v e r s C D N N e t w o r k a n d S e r v e r M o n i t o r i n g C D N P l a c e m e n t Management Layer 2 M u l t i c a s t C e n t r a l P r o c e s s i n g U n i t H a n d l e M a p T r a f f i c C o n f i g u r e t r e e o r C o n t e n t C o n t e n t n g i n e e r e d a n d I n i t i a l i z e C l i e n t E C h a n n e l D i s t r i b u t e d C o n t e n t S e r v e r P l a c e m e n t R e m o v a l P a t h S e r v e r R e q u e s t M o n i t o r i n g C r e a t i o n N e t w o r k M o n i t o r s M o n i t o r s R e p o s i t o r y CDN Hardware I n t e r f a c e t o h a r d w a r e d e v i c e s Layer 1 Dept. of Information Technology - Ghent University 4

  5. CDN Architecture • Layered architecture for a content distribution network • Consists of multiple functional modules C o n t e n t D i s t r i b u t i o n M o d u l e C o n t e n t R e t r i e v a l M o d u l e C l i e n t R e q u e s t CDN Operation Content Content C o n t e n t C o n t e n t R e t r i e v a l P l a c e m e n t T i m e Layer 3 C o n t e n t L o c a t i o n A l g o r i t h m D a t a b a s e I n t e r v a l R e p l i c a Retrieval Distribution P l a c e m e n t C o n f i g u r e I n i t i a t e A l g o r i t h m M o n i t o r e d T r i g g e r e d N e t w o r k S e r v e r I n f o r m a t i o n E v e n t CDN Network M u l t i c a s t a n d T E C o n t e n t S e r v e r s C D N N e t w o r k a n d S e r v e r M o n i t o r i n g C D N P l a c e m e n t Management Layer 2 CDN Monitoring M u l t i c a s t C e n t r a l P r o c e s s i n g U n i t H a n d l e M a p T r a f f i c C o n f i g u r e t r e e o r C o n t e n t C o n t e n t n g i n e e r e d a n d I n i t i a l i z e C l i e n t E C h a n n e l D i s t r i b u t e d C o n t e n t S e r v e r P l a c e m e n t R e m o v a l P a t h S e r v e r R e q u e s t M o n i t o r i n g C r e a t i o n N e t w o r k M o n i t o r s M o n i t o r s R e p o s i t o r y CDN Hardware I n t e r f a c e t o h a r d w a r e d e v i c e s Layer 1 Dept. of Information Technology - Ghent University 5

  6. Replica Placement Algorithms • Reference solution by means of an ILP • Determines the optimal placement of a static request distribution • Evaluation off-line (NP-complete) • General real-time RPA heuristics • Periodically replaces content in the CDN • Evaluation on-line Dept. of Information Technology - Ghent University 6

  7. Replica Placement Heuristics • Random replica placement • Popularity algorithms (parallel for each server) • Popularity Local (pop-L) - local content popularity • Popularity Global (pop-G) - global content popularity • Greedy algorithms (sequential execution for each content position) • Greedy Single (gre-S) - cost of retrieving from origin • Greedy Global (gre-G) - cost from other servers • Greedy All (gre-A) - cost of all streams in CDN Dept. of Information Technology - Ghent University 7

  8. COCOA RPA • COCOA: Co-Operative Cost Optimization Algorithm • Requires the aid of the Content Retrieval module • CR module determines the profit of available content or cost of missing content (real-time) • The COCOA RPA uses this information to make its placement decision (through monitoring module) • Hybrid algorithm • Centralized content retrieval algorithm (also used with other RPA algorithms, but more intelligent) • Distributed replica placement Dept. of Information Technology - Ghent University 8

  9. RPA Complexity • Compare the computational complexity of the RPA heuristics • COCOA has the same complexity as popularity local, but uses more accurate information RPA Requests Topology Process Complexity Random None None Distributed O(C s S) Pop-L Local None Distributed O(C s SF) Pop-G Global None Hybrid O(C s SF) Gre-S Local Origin Distributed O(C s SF) Gre-G All Entire Centralized O(C s S 3 F) Gre-A All Entire Centralized O(C s S 4 F) COCOA CR Module None Hybrid O(C s SF) Dept. of Information Technology - Ghent University 9

  10. RPA Complexity • Compare the computational complexity of the RPA heuristics • COCOA has the same complexity as popularity local, but uses more accurate information Parallelism RPA Requests Topology Process Complexity Random None None Distributed O(C s ) O(C s S) Pop-L Local None Distributed O(C s SF) O(C s F) Pop-G Global None Hybrid O(C s SF) O(C s F) Gre-S Local Origin Distributed O(C s SF) O(C s F) Gre-G All Entire Centralized O(C s S 3 F) Gre-A All Entire Centralized O(C s S 4 F) COCOA CR Module None Hybrid O(C s SF) O(C s F) Dept. of Information Technology - Ghent University 10

  11. Performance Analysis • Overhead of the average load of the algorithms to the ILP solution • COCOA is better than pop-L and close to the gre-G placement Oslo 250% Stockholm Glasgow Random Overhead of AVG load to ILP Popularity Local Copenhagen Popularity Global 200% Dublin Greedy Single Warsaw COCOA Hamburg Amsterdam London Greedy Global Berlin Brussels 150% Frankfurt Greedy All Prague Munich Strasbourg Paris Zurich Vienna Budapest Lyon 100% Bordeaux Belgrade Milan Zagreb 50% Barcelona Madrid Rome Athens 0% 25% 50% 75% 100% 125% 150% 175% 200% Replication Factor Dept. of Information Technology - Ghent University 11

  12. Performance Analysis • Overhead of the average load of the algorithms to the ILP solution • COCOA is better than pop-L and close to the gre-G placement Oslo 250% Stockholm Glasgow Random Overhead of AVG load to ILP Popularity Local Copenhagen Popularity Global 200% Dublin Greedy Single Warsaw COCOA Hamburg Amsterdam London Greedy Global Berlin Brussels 150% Frankfurt Greedy All Prague Munich Strasbourg Paris Zurich Vienna Budapest Lyon 100% Bordeaux Belgrade Milan Zagreb 50% Barcelona Madrid Rome Athens 0% 25% 50% 75% 100% 125% 150% 175% 200% Replication Factor Dept. of Information Technology - Ghent University 12

  13. Traffic Engineering for Load Balancing • Because of asymmetric topology and request distribution, the load is distributed unevenly over the network • Can cause congestion in certain parts of the network (e.g. during a flash crowd) • Traffic Engineering can be used to spread the flows over the entire CDN • Proactive in order to off-load core edges • Reactive in order to route flows round congested bottlenecks Dept. of Information Technology - Ghent University 13

  14. Proactive Traffic Engineering (1) 160 Average load: 42 Load on core edges Standard deviation: 18.4 120 80 40 0 0 200 400 600 800 1000 Time (minutes) Dept. of Information Technology - Ghent University 14

Recommend


More recommend