1 / 40

从宏观到微观的 CDN 之道

从宏观到微观的 CDN 之道. 焦胜强. 目录. 引子 宏观篇 微观篇. 引子 什么是 CDN 拥挤的传统结构 CDN 的目的. 什么是 CDN. 名称释义 Content Delivery Network CDN 的几个构成部分 内容调度 :GSLB,SLB 内容管理 :cache 源站 :storage 最简单的 CDN 一台负责全局负载均衡的 DNS 几台 Cache 分布于不同节点. 拥挤的传统结构. 传统的内容服务网络结构. CDN 的主要解决的问题. 带宽 距离. 宏观篇. 传统架构展示 51 图片频道的特点

aimon
Download Presentation

从宏观到微观的 CDN 之道

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 从宏观到微观的CDN之道 焦胜强

  2. 目录 • 引子 • 宏观篇 • 微观篇

  3. 引子 • 什么是CDN • 拥挤的传统结构 • CDN的目的

  4. 什么是CDN • 名称释义 • Content Delivery Network • CDN的几个构成部分 • 内容调度:GSLB,SLB • 内容管理:cache • 源站:storage • 最简单的CDN • 一台负责全局负载均衡的DNS • 几台Cache分布于不同节点

  5. 拥挤的传统结构 • 传统的内容服务网络结构

  6. CDN的主要解决的问题 • 带宽 • 距离

  7. 宏观篇 • 传统架构展示 • 51图片频道的特点 • 我们需要什么样的方案

  8. 传统的架构 • 解析层(DNS) • Bind • 3DNS • 其他 • 调度层(Balancer) • Netsclaer • F5 • Array • LVS • 服务层(应用服务) • WEB • Cache • FTP

  9. 互联网的访问之路

  10. 传统的CDN架构示意图 • 图1

  11. 传统的CDN架构示意图 • 图2

  12. 将CDN节点架构放大

  13. 有什么问题吗? • 每个cache都保存了同样的数据 • 宝贵的存储被浪费了

  14. 51图片频道的特点 • 源数据巨大,几百T • 访问热点不明显 • 每个用户的数据都有可能被别的用户访问 • 复杂的用户关系网络所表现的:每个人都是主角 • 访问量巨大 • 传统的CDN架构已经表现吃力

  15. 我们需要什么样的方案 • 扩展性 • 可用性 • 冗余 • 高效 • 大量 • 易用性 • 全部的开源软件 • 标准的协议使用 • 全面的资料介绍

  16. 相对于传统架构,我们必须做出改变 • 解析层 • 组合调度1层 • 组合调度2层 • 服务层

  17. 我们增强后的架构 LVS Standby Nginx (balancer) Nginx (balancer) Nginx (balancer) Squid (cache) Squid (cache) Squid (cache) Squid (cache) Squid (cache) Origin server (51DFS)

  18. 为什么可以这样? • 同样的算法总是得到同样的结果 • 多台具有相同算法的机器共同工作 • 唯一的object将被保存在唯一的cache

  19. 微观篇 • 各个细节的实现部分解析层(GSLB) • 调度层(SLB) • 服务层(Cache)

  20. 依靠DNS来实现GSLB • 就近访问:让用户访问距离自己最近的IDC • 负载均衡:多个IDC同时提供服务 • 故障转移:单个IDC出现问题时,用户不受影响

  21. 网宿的GSLB系统(CDNR)

  22. 改进的组合实现的调度层(SLB) • 负载均衡 • 故障转移 • 高效可用

  23. LVS有多强 • DR模式的优势 • LVS只负责调度请求,服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量 • 硬件平台的极限 • 网卡接口PCI 2.1总线的速率(DELL 1950): • 总线位宽是64位,总线频率66MHz,每时钟传输1组数据,它的带宽为508.6MB/s,即4068.8Mbps • 千兆以太网,一个线速端口的包转发率(fps)为1.488M • ((4CRC+46负荷)+2byte类型+6源MAC+6目的MAC) + 12帧间隙 + 8 MAC前导位 = 64 • 接近于操作系统的转发性能

  24. LVS DR的体系结构

  25. HTTP与TCP状态图

  26. 网卡吞吐量 for Linux 1

  27. 网卡吞吐量 for Linux 2

  28. 为什么使用Nginx Proxy • 高并发连接(epoll) • 所支持的FD上限是最大可以打开文件的数目 • 具体数目可以cat /proc/sys/fs/file-max,跟系统内存挂钩 • max_clients = worker_processes * worker_connections/4 • WAN环境中存在大量的慢速连接时性能无明显下降 • 士兵站岗的故事 • 高性能 • We are currently using Nginx 0.6.29 with the upstream hash module which gives us the static hashing we need to proxy to varnish. We are regularly serving about 8-9k requests/second and about 1.2Gbit/sec through a few Nginx instances and have plenty of room to grow! -- Wordpress.com • 我们的实际使用效果 req 1000+/s,bw 500M+ • 低内存占用

  29. 为什么使用Nginx Proxy • 灵活的配置 • 故障切换的实现 • proxy_connect_timeout 2; • Buffer控制 • proxy_buffers 64 4k; • 策略实现 • 多域名合并 • proxy_set_header Host "images22.51.com";

  30. Nginx Proxy所实现的URL HASH • 模块 • ngx_http_upstream_hash_module • 代码片段

  31. Nginx Proxy所实现的故障转移 • 部分代码

  32. 服务层--- cache的服务细节 • Cache数据的获取 • Push(preload) • Pull • Squid的cache类型 • Mem • disk • Squid 结构 • Hash Table • 磁盘cache的2级hash目录

  33. Squid 请求处理流程

  34. 影响squid效率的几个因素 • 源数据过大 • 磁盘IO • 集群下的单台失效

  35. 页面的可缓存条件 • Etag • Max-age • Expires • Last-Modified • Refresh_pattern

  36. 未来的几个工作 • GSLB智能化 • 一致性HASH • 平滑扩展的首要技术 • 主动健康检查

  37. 一致性哈希的简单测试

  38. 大盈若冲，其用不穷 • Cache的精神 • 学习的态度

  39. 谢谢

  40. 部分资料 • http://www.phparticle.net/bbshtmldata/8493/ • http://www.leftworld.net/wenzhang/show/7331.html • http://blog.csdn.net/rstevens/archive/2007/10/30/1858067.aspx • http://www.nginx.net/

More Related