How to Jump-Start Your Multi-CDN Strategy and Deliver Every Time
追求多cdn分发策略的优势是显而易见的——其中最重要的是不要冒着单点失败的风险来交付内容. 但是保持最高质量交付的最佳方法是什么呢, building redundancy and resiliency into your streams, 并解决原点负载能力? 在本文中, 我们将探索多cdn选项, 突出显示关键提供者, 并确定在您继续您的多cdn之旅时要问的正确问题和要考虑的问题.
Problems That Multi-CDN Delivery Addresses
迁移到多cdn背后的主要驱动力是单cdn方法将您限制为单点故障. 区域, some CDNs might not perform as well as others, especially when you’re delivering worldwide. Sometimes you can have issues at one CDN, 本质上, that you might not be having at another CDN, 也可能是系统性的. 当然, not every delivery issue is CDN-driven; sometimes issues can be isolated to the last mile, and it’s important to consider that possibility too.
我们的客户转向多cdn的首要原因是他们希望保持性能和可用性，并尽可能提供最好的体验，无论在广播期间发生什么或他们试图提供什么. And they find that going multi-CDN helps. 它不能解决所有问题，但它增加了健壮性，使他们的流更成功.
成本方面的考虑也是一个因素. Some CDNs are more cost-effective than others, 将一些用户从一个CDN转移到另一个CDN可能不仅能让你保持你的服务水平, 但同时也要降低成本. The playing field has begun to level out over time, 但CDN的定价总是取决于数量，以及你使用和承诺的数量.
多CDN的另一个驱动因素是安全性——如果流级访问安全性受到威胁，将用户从CDN迁移出去的能力, as well as move users to another one. Availability is a big driver, as are capacity and performance. 但如果各方都能以可接受的水平交付，成本很可能成为决定性因素. 图1 给出了一个大致估计的问题，通常推动移动到多cdn, as well as their relative importance.
图1
用复杂性
直播交付的复杂性是内容提供商转向多cdn的另一个原因. Live is significantly more complex than video on demand (VOD), 并加入广告, DRM增加了更多的复杂性.
多源流的内容同步对于冗余和故障转移至关重要, as well as maintaining resiliency within your streams. Does your live stream have a single origin or multiple origins? How will you synchronize content across those origins? 我们已经看到很多内容在从一个来源到另一个来源时出现问题. 尽管它有很多优点, multi-CDN can compound those problems, depending on which origins you have serving to which CDNs.
源负载能力也是你需要考虑的，特别是当你迁移到多cdn时. If you’ve been storing your content on your own origin server, the load on that server is going to increase with, 说, five different CDNs accessing it instead of just one, 除非你用的是 像Fastly这样的负载平衡服务 作为其他cdn的来源. Capacity planning is an essential element of a multi-CDN strategy.
在具体的层面上, 你需要弄清楚如何安排交通——什么时候调整，什么时候不调整. 调整是提前进行，还是中途进行，还是只有在出现问题时才进行?
数据与决策
To make these decisions wisely, you’ll need data. Whenever possible, you should be pulling QoS and QoE data. 你应该对哪些表现良好，哪些表现不好有一个宏观的认识, collecting 信息 about the CDN performance from the CDN, 以及其他来源.
数据可以帮助你做的一件事是区分最后一英里的决定和你应该代表用户做出的决定. 是否应该允许用户单独管理他们自己的CDN交换, based on the big-picture data you’ve collected? 或者按区域对用户进行分组并根据您对流期间可能发生的事情的最佳猜测为他们切换cdn更有意义? There are benefits in both approaches. 为我们的客户, 我们在个人使用层面上做了更多的CDN切换，而不是在宏观层面上. 进行宏观调整, 有专门设计的服务来帮助您智能地制作它们. We’ll look at those later in this article.
访问安全
对于通过cdn交付的任何内容，我们通常都有某种形式的令牌访问控制. 即使使用DRM，我们仍然有客户坚持使用某种形式的令牌访问控制. If you have three CDNs and each has a token authentication system, do you have to align them so that they use the same tokens on each?
Some services try to push you to do that, 这很不幸, because it can potentially reduce security overall. 然而, if you don’t align the authentication systems, it increases the complexity that you have to manage. When you’re switching CDNs in a way that’s seamless to the user, 您必须确保您在所有适当的cdn上进行了身份验证. Otherwise, when you try to switch, your stream will fail.
The Three Key Components of a Multi-CDN Solution
这些都是你在追求多cdn战略时可能面临的一些关键挑战. 现在我们来看看一些可用的解决方案以及它们是如何工作的. 解决方案需要解决三个关键领域:决策、路由和数据.
决策引擎可以采用基于域名系统(DNS)/服务器的方法或客户端方法. 基于服务器的方法在服务层处理所有路由，然后向下提供给用户. 这可以通过DNS完成，这样所有请求都可以转到一个地方，然后您可以将这些请求路由到您想要的任何CDN. 或者，客户端可以基于可用数据进行这些调用并在那里执行. 决策也可以通过应用程序编程接口(API)服务提供. 无论哪种方式, 它将是一个发生在客户端请求或向上的请求上的操作.
我们可以预先安排交通, 所以最简单的多cdn路由是这样的:在流开始之前, 做出了决定. 假设, “用户, you’re going to CDN 1; User B, you’re going to CDN 1; User C, 你要去cdn2.” We can base that decision on region data or on other factors, 但不管怎样, we make a call on how we want to distribute our users up front, 在他们开始播放之前. 一旦它们开始播放，我们就会以一种基本的方式在CDN上维护它们. That doesn’t mean we have to stop there. 我们可以更进一步.
We can also route that traffic dynamically. We can hard-switch users and reload the manifest midstream, 所以如果我们在看内容, 它在特定地区或用户群中出现问题或表现不佳, 我们可以说, “We want you to switch over to alternative content. 在不同的CDN上加载.” This does not provide a good user experience, 因为这意味着, “停止, re-buffer, 然后重新开始播放.“我们只在紧急情况下才这么做, 当我们知道地狱之火即将降临，全世界的小狗都在哭泣.
我们更喜欢在清单或段级别上动态地进行无缝切换. 这意味着要么从客户端路由请求，如果它要去基于dns的解决方案，要么实际上在客户端级别应用更改，以便我们告诉客户端, “不要从CDN 1加载. Load from CDN 2 on this next request.” When that happens at the segment level, it’s seamless; the user never even knows that they’ve switched CDNs.
You can perform the same switch at the manifest level. If you’re doing dynamic manifest manipulations upstream, 然后，您可以重写清单，在下一次请求时将其指向替代路径. 客户端将加载它，然后保留段请求并从那里开始.
无缝的、动态的片段或清单级切换，适用于直播和视频点播. 对于清单级切换，它可以在清单刷新时工作. 对于直播来说，这是每个片段，但对于VOD来说，这只是预先设置或在比特率/播放开关上.
自动化多cdn管理
开发一个完全集成的多cdn解决方案需要时间和百家乐软件. 如果您想要最小化放置多cdn解决方案所需的工作, automated multi-CDN management is available as well.
简化这个过程的一种方法是将一个系统与你现在拥有的东西结合起来, 例如基于现有源的DNS路由和负载平衡解决方案. 用这种系统, 你只要把它放在上游, 最多, 你只需要确定你从哪里加载所有的内容, then the system will determine how to handle that in theory.
你今天就可以采用这样的解决方案. 它们的提供者吹嘘它们基本上是不干涉的:“你不需要做任何事情来打开它. You can just pay us and configure it, and you’re set.“事情并不总是这么容易, but it can definitely reduce the effort you have to put in, 尤其是在客户那张幻灯片上.
采用基于DNS/服务器的负载平衡方法意味着使用诸如Cedexis之类的服务, which was purchased by Citrix in 2018. 本质上, you sign an agreement and turn over the keys, and they set up a DNS so that when your users 说, “从我的域名中获取这些内容,“它会穿过它们. 然后，他们将进行DNS选择，并从他们认为适合您的用户的CDN返回内容. This approach can get more feature-rich and complicated from there.
使用DNS解决方案的想法是，您可以有一个自动裁决来确定它切换到哪个CDN. 分布可以是静态的, failover-based, 基本的循环, 加权轮询, 地区, 或业绩, which means it’s driven by QoS and QoE data. It can even have third-party API integration at some points, as well as having some form of client-side metric reporting. 在一个完美的世界, you’re getting data on both the client and the individual user, 加上聚合数据和基于服务器或基于网络的监控和计算.
To get the performance data from the clients, 他们通常使用某种系统来跟踪你加载的内容, 或者在许多情况下，按一定的间隔加载特定的测试数据块(通常称为节点检查)，以确定cdn的估计性能和吞吐量. 不幸的是, 一些cdn可能试图优化/优先考虑这些“测试者”资产的交付，并提供对他们有利的错误结果. 最好的解决方案总是测量实际的流段, 不是任意的测试资产.
The Dynamic Manifest/Segment Approach
像Streamroot这样的解决方案也可用于帮助实现前面描述的动态清单段方法. 此解决方案既可以在服务器上运行，也可以基于服务器/客户机. 它既可以是集中式系统，也可以是带有自动化规则的分布式系统. It can also be API-driven from an operational or analytics side.
我们在这类解决方案上合作过的一些客户希望自己控制它. 他们想让他们的运营人员通过Conviva或他们拥有的任何分析来检查数据，看看他们自己的用户体验, 然后打个电话. 他们说, “我希望能够按下这个按钮，或者设计这个带有特定输入数据点的系统，并将用户带到我们想要的任何地方.”
When you look at these types of integration, 问题变成了, is that going to work with the provider, 还是我得自己造点什么? 与基于dns的多cdn一样, 分布可以是静态的, 循环, 加权轮询, 地区, 或业绩. 但是客户端方法的思想是，分发决策发生在修改客户端将要接收的实际内容的服务内部, versus just routing what it’s going to receive.
指标
In terms of metrics on the client side, we typically look at bandwidth/throughput, 注意通量, 检查备选方案, 无论是在侧负载还是轮询上, 进行基于标签的检查, 或故障转移. 故障转移是将多cdn集成到您的解决方案中最简单和最直接的途径之一:如果您遇到问题, 你可以试试别的CDN. 我们的目标是在不影响用户体验的情况下无缝地完成这些工作. That works only if the problem is not on your origin. 否则，你就会把失败转移到其他可能有同样问题的事情上.
在服务端，大多数时候，您将与Conviva或Datazoom等提供商合作. 它可以提取和汇总你的数据，以评估你当时分发的内容的健康状况.
You can also use node-check system aggregation. 节点系统是一种分布式系统，它检查单个文件或一组文件，为您提供一些可以聚合的数据. Citrix/Cedexis系统在很大程度上依赖于全球不同的节点系统. 当你实施这个系统时, 你将它放入播放器中，这样它就可以进行节点检查并报告特定区域用户的流执行情况等信息.
相关文章
该活动汇集了内容交付领域的所有参与者——从电力和互连到服务质量和边缘计算——这是同类会议中唯一的一次. If you're interested in speaking, read on.
2020年2月5日
对高品质的需求, 互动, 因此，在接下来的几年里，数据饥渴的在线体验只会增加, multi-CDNs are rethinking infrastructure and bringing in innovative, 可持续的解决方案.
1月23日2020
Jolokia的Pete Mastin和Limelight Networks的Rob Coluantoni在2019年流媒体东部的直播峰会小组中讨论了不同内容交付架构的优缺点.
2019年8月9日
When 1 or 2 CDNs isn't good enough, how about 15? 视频分发公司Peer5推出了多cdn，有15个内容分发网络参与.
2019年4月2日
Streaming viewers expect an instant-on, high-quality experience. Verizon数字媒体服务改进了其服务工具的质量，以持续监控问题.
2019年4月1日
流媒体执行副总裁Dan Rayburn讨论了为什么使用多个cdn对某些内容所有者有意义，而对其他内容所有者没有意义.
8月22日
提及的公司及供应商