如何启动您的多cdn战略并每次交付
追求多cdn分发策略的优势是显而易见的——其中最重要的是不要冒着单点失败的风险来交付内容. 但是保持最高质量交付的最佳方法是什么呢, 在流中构建冗余和弹性, 并解决原点负载能力? 在本文中, 我们将探索多cdn选项, 突出显示关键提供者, 并确定在您继续您的多cdn之旅时要问的正确问题和要考虑的问题.
多cdn交付地址的问题
迁移到多cdn背后的主要驱动力是单cdn方法将您限制为单点故障. 区域, 一些cdn的表现可能不如其他cdn, 特别是当你在全球范围内交付时. 有时您可能在一个CDN上出现问题, 本质上, 这是你在其他CDN可能没有的, 也可能是系统性的. 当然, not every delivery issue is CDN-driven; sometimes issues can be isolated to the last mile, 考虑这种可能性也很重要.
我们的客户转向多cdn的首要原因是他们希望保持性能和可用性，并尽可能提供最好的体验，无论在广播期间发生什么或他们试图提供什么. 他们发现使用多cdn很有帮助. 它不能解决所有问题，但它增加了健壮性，使他们的流更成功.
成本方面的考虑也是一个因素. 一些cdn比其他cdn更具成本效益, 将一些用户从一个CDN转移到另一个CDN可能不仅能让你保持你的服务水平, 但同时也要降低成本. 随着时间的推移，竞争环境已经开始趋于平衡, 但CDN的定价总是取决于数量，以及你使用和承诺的数量.
多CDN的另一个驱动因素是安全性——如果流级访问安全性受到威胁，将用户从CDN迁移出去的能力, 以及将用户转移到另一个. 可用性、容量和性能是一个重要的驱动因素. 但如果各方都能以可接受的水平交付，成本很可能成为决定性因素. 图1 给出了一个大致估计的问题，通常推动移动到多cdn, 以及它们的相对重要性.
图1
用复杂性
直播交付的复杂性是内容提供商转向多cdn的另一个原因. 直播比视频点播(VOD)要复杂得多。, 并加入广告, DRM增加了更多的复杂性.
多源流的内容同步对于冗余和故障转移至关重要, 以及在您的流中保持弹性. 你的直播是单一来源还是多个来源? 如何在这些源间同步内容? 我们已经看到很多内容在从一个来源到另一个来源时出现问题. 尽管它有很多优点, multi-CDN会加重这些问题, 这取决于您为哪些cdn提供服务的源.
源负载能力也是你需要考虑的，特别是当你迁移到多cdn时. 如果您一直将内容存储在自己的原始服务器上, 服务器上的负载将随着, 说, 五个不同的cdn访问它，而不是一个, 除非你用的是 像Fastly这样的负载平衡服务 作为其他cdn的来源. 容量规划是多cdn战略的基本要素.
在具体的层面上, 你需要弄清楚如何安排交通——什么时候调整，什么时候不调整. 调整是提前进行，还是中途进行，还是只有在出现问题时才进行?
数据与决策
为了做出明智的决定，你需要数据. 只要有可能，您就应该提取QoS和QoE数据. 你应该对哪些表现良好，哪些表现不好有一个宏观的认识, 从CDN上收集CDN性能信息, 以及其他来源.
数据可以帮助你做的一件事是区分最后一英里的决定和你应该代表用户做出的决定. 是否应该允许用户单独管理他们自己的CDN交换, 根据你收集的大数据? 或者按区域对用户进行分组并根据您对流期间可能发生的事情的最佳猜测为他们切换cdn更有意义? 这两种方法都有好处. 为我们的客户, 我们在个人使用层面上做了更多的CDN切换，而不是在宏观层面上. 进行宏观调整, 有专门设计的服务来帮助您智能地制作它们. 我们将在本文后面讨论这些问题.
访问安全
对于通过cdn交付的任何内容，我们通常都有某种形式的令牌访问控制. 即使使用DRM，我们仍然有客户坚持使用某种形式的令牌访问控制. 如果您有三个cdn，每个cdn都有一个令牌身份验证系统, 您是否必须对齐它们，以便它们在每个上使用相同的令牌?
一些服务试图推动你这样做, 这很不幸, 因为它可能会降低整体的安全性. 然而, 如果不调整身份验证系统, 它增加了你必须管理的复杂性. 当你以一种无缝的方式切换cdn时, 您必须确保您在所有适当的cdn上进行了身份验证. 否则，当您尝试切换时，您的流将失败.
多cdn解决方案的三个关键组成部分
这些都是你在追求多cdn战略时可能面临的一些关键挑战. 现在我们来看看一些可用的解决方案以及它们是如何工作的. 解决方案需要解决三个关键领域:决策、路由和数据.
决策引擎可以采用基于域名系统(DNS)/服务器的方法或客户端方法. 基于服务器的方法在服务层处理所有路由，然后向下提供给用户. 这可以通过DNS完成，这样所有请求都可以转到一个地方，然后您可以将这些请求路由到您想要的任何CDN. 或者，客户端可以基于可用数据进行这些调用并在那里执行. 决策也可以通过应用程序编程接口(API)服务提供. 无论哪种方式, 它将是一个发生在客户端请求或向上的请求上的操作.
我们可以预先安排交通, 所以最简单的多cdn路由是这样的:在流开始之前, 做出了决定. 假设, “用户, you’re going to CDN 1; User B, you’re going to CDN 1; User C, 你要去cdn2.“我们可以根据地区数据或其他因素做出决定, 但不管怎样, 我们会事先决定如何分配我们的用户, 在他们开始播放之前. 一旦它们开始播放，我们就会以一种基本的方式在CDN上维护它们. 这并不意味着我们就得就此打住. 我们可以更进一步.
我们还可以动态地路由这些流量. 我们可以硬切换用户并在中途重新加载清单, 所以如果我们在看内容, 它在特定地区或用户群中出现问题或表现不佳, 我们可以说, “我们希望你能转向其他内容. 在不同的CDN上加载.“这并不能提供良好的用户体验, 因为这意味着, “停止, re-buffer, 然后重新开始播放.“我们只在紧急情况下才这么做, 当我们知道地狱之火即将降临，全世界的小狗都在哭泣.
我们更喜欢在清单或段级别上动态地进行无缝切换. 这意味着要么从客户端路由请求，如果它要去基于dns的解决方案，要么实际上在客户端级别应用更改，以便我们告诉客户端, “不要从CDN 1加载. 下一个请求从CDN 2加载.“当这种情况发生在细分市场层面时, it’s seamless; the user never even knows that they’ve switched CDNs.
您可以在清单级别执行相同的切换. 如果你在上游做动态清单操作, 然后，您可以重写清单，在下一次请求时将其指向替代路径. 客户端将加载它，然后保留段请求并从那里开始.
无缝的、动态的片段或清单级切换，适用于直播和视频点播. 对于清单级切换，它可以在清单刷新时工作. 对于直播来说，这是每个片段，但对于VOD来说，这只是预先设置或在比特率/播放开关上.
自动化多cdn管理
开发一个完全集成的多cdn解决方案需要时间和百家乐软件. 如果您想要最小化放置多cdn解决方案所需的工作, 自动化多cdn管理也是可用的.
简化这个过程的一种方法是将一个系统与你现在拥有的东西结合起来, 例如基于现有源的DNS路由和负载平衡解决方案. 用这种系统, 你只要把它放在上游, 最多, 你只需要确定你从哪里加载所有的内容, 然后系统将决定如何在理论上处理它.
你今天就可以采用这样的解决方案. 它们的提供者吹嘘它们基本上是不干涉的:“你不需要做任何事情来打开它. 你只要付钱给我们，配置一下，就搞定了.“事情并不总是这么容易, 但它绝对可以减少你必须付出的努力, 尤其是在客户那张幻灯片上.
采用基于DNS/服务器的负载平衡方法意味着使用诸如Cedexis之类的服务, 该公司于2018年被思杰收购. 本质上, 你签个协议，把钥匙交出来, 他们设置了一个DNS，所以当你的用户说, “从我的域名中获取这些内容,“它会穿过它们. 然后，他们将进行DNS选择，并从他们认为适合您的用户的CDN返回内容. 这种方法可以使功能更加丰富和复杂.
使用DNS解决方案的想法是，您可以有一个自动裁决来确定它切换到哪个CDN. 分布可以是静态的, failover-based, 基本的循环, 加权轮询, 地区, 或业绩, 这意味着它是由QoS和QoE数据驱动的. 在某些方面，它甚至可以集成第三方API, 以及具有某种形式的客户端度量报告. 在一个完美的世界, 您将获得客户机和单个用户的数据, 加上聚合数据和基于服务器或基于网络的监控和计算.
从客户端获取性能数据, 他们通常使用某种系统来跟踪你加载的内容, 或者在许多情况下，按一定的间隔加载特定的测试数据块(通常称为节点检查)，以确定cdn的估计性能和吞吐量. 不幸的是, 一些cdn可能试图优化/优先考虑这些“测试者”资产的交付，并提供对他们有利的错误结果. 最好的解决方案总是测量实际的流段, 不是任意的测试资产.
动态清单/分段方法
像Streamroot这样的解决方案也可用于帮助实现前面描述的动态清单段方法. 此解决方案既可以在服务器上运行，也可以基于服务器/客户机. 它既可以是集中式系统，也可以是带有自动化规则的分布式系统. 它也可以是由操作或分析端api驱动的.
我们在这类解决方案上合作过的一些客户希望自己控制它. 他们想让他们的运营人员通过Conviva或他们拥有的任何分析来检查数据，看看他们自己的用户体验, 然后打个电话. 他们说, “我希望能够按下这个按钮，或者设计这个带有特定输入数据点的系统，并将用户带到我们想要的任何地方.”
当你看到这些类型的积分, 问题变成了, 这对提供者有用吗, 还是我得自己造点什么? 与基于dns的多cdn一样, 分布可以是静态的, 循环, 加权轮询, 地区, 或业绩. 但是客户端方法的思想是，分发决策发生在修改客户端将要接收的实际内容的服务内部, 而不是路由它将要接收的东西.
指标
就客户端的指标而言, 我们通常查看带宽/吞吐量, 注意通量, 检查备选方案, 无论是在侧负载还是轮询上, 进行基于标签的检查, 或故障转移. 故障转移是将多cdn集成到您的解决方案中最简单和最直接的途径之一:如果您遇到问题, 你可以试试别的CDN. 我们的目标是在不影响用户体验的情况下无缝地完成这些工作. 只有当问题不在原点时才有效. 否则，你就会把失败转移到其他可能有同样问题的事情上.
在服务端，大多数时候，您将与Conviva或Datazoom等提供商合作. 它可以提取和汇总你的数据，以评估你当时分发的内容的健康状况.
您还可以使用节点检查系统聚合. 节点系统是一种分布式系统，它检查单个文件或一组文件，为您提供一些可以聚合的数据. Citrix/Cedexis系统在很大程度上依赖于全球不同的节点系统. 当你实施这个系统时, 你将它放入播放器中，这样它就可以进行节点检查并报告特定区域用户的流执行情况等信息.
相关文章
该活动汇集了内容交付领域的所有参与者——从电力和互连到服务质量和边缘计算——这是同类会议中唯一的一次. 如果你对演讲感兴趣，请继续往下读.
2020年2月5日
对高品质的需求, 互动, 因此，在接下来的几年里，数据饥渴的在线体验只会增加, 多cdn正在重新思考基础设施并引入创新, 可持续的解决方案.
1月23日2020
Jolokia的Pete Mastin和Limelight Networks的Rob Coluantoni在2019年流媒体东部的直播峰会小组中讨论了不同内容交付架构的优缺点.
2019年8月9日
如果1或2个cdn还不够好，那么15个呢? 视频分发公司Peer5推出了多cdn，有15个内容分发网络参与.
2019年4月2日
流媒体观众希望获得即时的高质量体验. Verizon数字媒体服务改进了其服务工具的质量，以持续监控问题.
2019年4月1日
流媒体执行副总裁Dan Rayburn讨论了为什么使用多个cdn对某些内容所有者有意义，而对其他内容所有者没有意义.
8月22日