创建纳斯达克基于云的虚拟工作流程

许多人将内容交付网络(cdn)视为SaaS云——因此, 它们被视为首批商用云. 例如，您不需要在计算机上购买时间来运行自己的媒体服务器. 而不是, 您购买的只是软件服务(例如)实时消息传递协议(RTMP) Flash流.

当时, 只有三家运营商拥有可用于全球服务的重要IaaS基础设施, 我们在与另一家知名供应商的合作中遇到了困难. 尽管该公司大力宣传其云业务, 现实情况是，它提供的更多是一个虚拟托管环境. 它的控制API是有限的——当然与Amazon EC2相比——尽管每小时计算时间的定价很有竞争力, we had many occasions where the servers we ordered through its system were taking not seconds or minutes to provision 和 become available; they were sometimes taking hours 和 even days! 公平地说, 我想其他供应商现在已经解决了这个问题——我们当时确实为其员工提供了广泛的调试——但缺乏信心已经在我们的客户心中灌输了, 我们只剩下一个选择:建立亚马逊-亚马逊的弹性. 本质上, 这意味着我们总是在两个完全独立的区域和可用性区域启动工作流，并准备在几秒钟内立即在第三个区域部署第三个工作流.

总结并直接回答问题, 我们使用Amazon EC2的关键原因是当时我们没有真正的选择. 我们仍对供应商多元化持开放态度, 和, 公平地说, 我们将在未来12个月内审查其他供应商. 然而, 对于IaaS来说，现实就是这样, Amazon EC2是一个非凡的平台——在公共IaaS方面遥遥领先——并且已经被证明是非常可靠和经济的, 以及真正的全球化.

你面临什么样的规模问题?

纳斯达克OMX企业解决方案平台的使用模式极不稳定. 在财政年度结束时, we may see thous和s of companies reporting at pretty much the same time; this requires, 以及几个管理和报告服务器, 至少要提供两倍数量的编码器. 即使对于像Amazon EC2这样规模的公司来说，这种水平的波动也是异常的, 因此，我们必须通过谈判获得具体许可，才能在短时间内对其基础设施提出如此大的要求.

关键的一点是，在初始目标区域没有容量的情况下，能够将编码器从一个可用区域移动到另一个可用区域. 我们的技术完全将纳斯达克OMX企业解决方案的工作流程从所有潜在的复杂性中抽象出来.

SLA怎么样??

Amazon EC2至少提供了99种.95% (aws.亚马逊.com/ec2-sla)可用性. 这意味着目标值为4.每年38小时，整个服务可能无法使用. 我们的应用程序始终至少在两个区域中运行. 一般来说, 这意味着我们的应用程序最终得到了一个整体的服务水平协议(SLA).05% x 0.05%)) = 99.9975%. 维护这种可用性的关键是不同区域和应用程序的自治. 公共云数据中心的服务器出现问题的几率与您拥有并托管在您自己位置的机器出现问题的几率几乎没有什么不同. 在IaaS公共云的情况下, 然而, 您可以立即访问数以千计的其他百家乐软件，以便就地使用, 你可以——也应该——一直使用多个系统来实现冗余.

我以前写过一些人在出名后声称亚马逊EC2不可靠 Reddit 和 网飞公司 中断. Amazon EC2 is usually operating well within its SLA; the issue was that Reddit 和 网飞公司 did not code their applications well to respect 中断 or failures. 与此形成鲜明对比的是, 我们交付给纳斯达克OMX企业解决方案的平台在亚马逊EC2的多个区域自动运行数百台服务器, 我们只是通过检查我们的日志才知道前面提到的中断对我们的交付有任何影响. 我们的应用程序只是在机器之间失败(在单帧视频或音频中)。, 下游起源, 以及上游的cdn, 客户也不会知道.

信号采集?

简单地说，进入Amazon EC2的信号采集必须在IP上进行. 我们使用视频会议和广播MPEG传输流视频源直接从事件向基础设施提供信号. 同样，我们使用IP语音(VoIP)进行纯音频信号采集. 亚马逊的网络服务数据中心都连接得非常好, 因此，贡献问题通常归结为原点(活动现场)的远程连接。. 我们有, 有时, 经验丰富的亚马逊基础设施内部的网络分裂, 强调能够自动为编码器选择可选区域的重要性.

操作系统选择和堆栈怎么样?

最初的实现是使用Windows构建的, 因为它使用了几个仅限windows的第三方工具, 例如Windows和Flash媒体编码器. 它曾经是直播的, 我们发现，我们面临的几乎所有运营挑战都来自这些第三方工具. 随着时间的推移，id3a开发了自己的端到端技术套件(id3a).媒体)能够取代所有这些第三方工具(除了编解码器)，并以平台无关的方式这样做. 这使我们能够通过从Windows迁移到Linux，极大地提高平台稳定性，并显著降低IaaS成本, 按小时计算哪一种便宜得多.

如何控制系统?

位于马尼拉的纳斯达克OMX企业解决方案运营中心的代理, 菲律宾, 和莱比锡, 德国, 监督整个系统, 尽管世界各地都有灾难恢复能力, 因为管理层完全是基于web的. 事件时间表由纳斯达克OMX企业解决方案管理系统交付到一个弹性和分布式(基于云的)数据库中. 这些管理系统位于多个可用性区域, 它们还会收到指令，告诉它们何时为各种事件启动编码器. 通知在web GUI上呈现给主管.

同样的web GUI允许操作员完全控制事件, 包括即时剪切和编辑(使用类似dvr的技术来标记编辑决策列表)，最终在现场活动结束的瞬间产生点播文件. GUI还提醒操作员注意任何信号信任失败，并使单个操作员能够同时监督多个事件, 大大提高了呼叫中心团队的工作效率. 的id3as.媒体管理和控制子系统全部用Erlang编写, 一种专门为大规模生产而设计的语言, 非常可用/可靠的分布式系统.

它是如何报告的?

就像id3as.媒体软件取代了工作流程中的所有第三方技术, 它提供了一个机会，将报告合并到一个干净的, 清晰的, 以及使用图形输出的动态报告模型. 这意味着id3a可以以图形化的方式深入到工作流中的任何问题, 几乎有无限的细节可用. 这确保了独立的, real-time monitoring is possible out of the box; it’s also tightly integrated into NASDAQ OMX Corporate Solutions’ own management 和 reporting systems.

总结一下——我以前也说过——it对云计算的狂热, 起初, 似乎都是关于技术的, 但事实并非如此:它实际上是一个广义的术语，指的是由各种技术支撑的动态经济模型.

是的, 通常(从技术上讲)，您可以在云中执行在私有专用设备上执行的操作, 但关键的优势应该是成本和灵活性. 它应该, 例如本文中的示例, 以对客户的真正价值主张为驱动，而不是被时髦的流行语所蒙蔽.

本文发表于2013年8月/ 9月号 流媒体杂志 作为“纳斯达克基于云的虚拟工作流”."