Active存储知识：光纤通道和存储的结合
博科、Gadzoox、Ancor、Vixel和一些新兴企业在20世纪90年代开发的产品确实主要面向存储应用场景，但光纤通道最初是作为可以很好地传输其它协议的‘传输’协议而设计的——尽管从7层OSI模型中的第4层（L4）意义上讲不是这样。
实际上，光纤通道协议栈的最高层，即FC-4，定义了不同上层协议（ULP）之间的映射关系。这里定义了多个ULP，包括目前已过时的协议（如HIPPI或IPI）、网络协议（如ATM或IP）以及一些目前仍在使用的协议，如SCSI或SBCCS（FICON）。博科的一些最早期客户是在IP over Fibre Channel（IPoFC）上运行视频流应用的媒体公司。IPoFC在当时以明显的优势令以太网相形见绌——以太网当时正艰难地将速度提高到1 Gbps，而且使用的TCP/IP软件堆栈效率低下，而光纤通道采用极为高效的基于硬件的堆栈，速度正从1 Gbps提高到2 Gbps。博科交换机支持面向IPoFC的某些具体特性；而且除了SCSI驱动程序之外，所有光纤通道HBA厂商都还开发了面向所有主流操作系统的IP驱动程序。然而我们都知道，最终是存储应用场景将光纤通道以及博科等公司提升到了今天的位置，而其它应用场景则逐步淡出。现在，HBA厂商不再提供IP驱动程序，而博科Fabric OS也不支持曾经的一系列IPoFC专用特性——即使IPoFC目前仍可使用（主要用于博科交换机的带内管理）。因此，即使光纤通道最初不是专为存储而设计，但其设计很可能考虑了这一点；因为在数十年的时间里，多家厂商投入数百万美元的研发投资来研究如何利用该技术支持存储应用场景，在开放系统和大型机环境中都是如此。
这样就催生了一代又一代的ASIC、操作系统及一次又一次地不光以提升速度为目的的管理软件版本。旨在更高效而可靠地将成千上万的并行关键任务高性能低延迟存储流量从源传输到目的地，同时实时监控每个数据流中的每一个帧的数十种特性，使管理员可以在虚拟化环境中测量的I/O性能——直至各存储LUN【在使用NVMe时则为名称空间ID（NSID）】。他们不仅可以测量吞吐量，还可以测量延迟、IOPS、首次响应时间、待处理I/O及对存储管理员无比重要的多种其它存储专用指标。
光纤通道采用缓冲器到缓冲器流控制机制。通过该机制，每台发送设备就可以在完成链路初始化之后清楚地了解接收设备有多少个缓冲器来保存帧然后再进行处理。接收设备可以根据其缓冲器的最大数量，为发送设备提供尽可能多的缓冲‘信用’。然后，发送设备可以通过以下方法跟踪接收设备所拥有的缓冲器数量：每次发送一个帧时将信用计数器（信用）数量下调1，而在每次从接收设备收到名为Receiver Ready（R_RDY）的信号后将信用值上调1。这种简单而主动的机制可避免来自发送设备的帧数量过多，不能全部保存在接收设备的缓冲器中然后被强制丢弃，进而确保接收设备从来不会出现帧溢出。NVMe-oF规范认为这种机制是在网络中传输NVMe流量的‘理想’选择，因为PCIe在服务器中用于处理内部NVMe存储流量的也是这种机制。几十年的经验证明，缓冲器到缓冲器流控制是在网络中处理存储流量的非常理想而且可靠的流控制机制。
在光纤通道ASIC中，博科开发了一种新特性，并从称为虚拟通道（VC）的第一代ASIC中开始提供。虚拟通道可以将两台博科交换机之间的每条ISL分配到多个‘通道’中；每个通道都有自己的专用缓冲池来分别提供独立的流控制功能，此外还将少量虚拟通道专用于运行分布式Fabric架构服务的特殊流量（叫作F类流量），进而确保这些流量始终可使用专用最高优先级通道，即时在出现极端拥塞时也不例外；而且Fabric架构本身从来不会变得不稳定，因为交换机之间互相不能通信。
虚拟通道可支持存储流量隔离、分类、保护和优先级分配，因此影响一个或一些存储流量的拥塞事件不会影响到全部流量。如果某存储设备的响应速度降低，成为慢速设备（在网络中造成拥塞的原因），其中的流量会经历更长时间的延迟。如果不采取任何应对措施，这会在网络中形成‘背压’（所有流控制网络中固有的一种现象，不允许在出现拥塞时丢弃帧），而且有可能会影响多个不相关的‘受害者’流量，进而严重影响到应用性能甚至导致严重的业务后果。博科光纤通道Fabric架构可以自动检测这些延迟增加情况并将慢速流量‘隔离’到低优先级虚拟通道中，确保它们的性能下降不会影响到其它存储流量。
虚拟通道技术从我们运行速度为1 Gbps的第一代‘Stitch’ASIC就开始提供；在将支持运行速度为64 Gbps和256 Gbps的第七代光纤通道的下一代‘Condor 5’ ASIC中将继续提供。过去几年，我们增加了可用于最终用户流量的虚拟通道数量，并开发了可以更有效地利用该技术的多种软件特性，如慢速设备隔离（SDDQ）或服务质量（QoS）。
将存储与服务器分离开来，不再通过内部总线将它连接到CPU的那一天起，整个行业就开始认识到保证应用或操作系统的存储资源从不会变得不可用有多重要。您非常清楚在计算机运行时拆下硬盘驱动器（或目前使用的固态驱动器）会怎么样，然后，您就可以想象在SAN相连阵列之外运行的数千VM出现这种情况会出现什么后果，或者在运行时数据库变得不可用又会给关键任务应用带来什么影响。这不仅会导致应用或服务器或VM的整个操作系统崩溃，而且很容易出现数据破坏，进而导致长时间停机，带来严重的商业后果，包括公司破产。
因此，我们开始努力开发各种技术和最佳实践，以确保联网存储环境中永远不会出现任何单点故障（SPoF）。除了在存储阵列中使用冗余磁盘驱动器，将数据镜像或分配到多个驱动器中以防止单个驱动器故障外（这种技术叫作RAID，在存储阵列中使用冗余控制器，辅以服务器上的冗余适配器和操作系统中的多路径驱动器），企业还开始部署所谓的‘双Fabric架构’。 双Fabric架构就是使用两个完全隔离开来、中间无任何线缆连接的两个独立存储Fabric架构，以确保一个Fabric架构中的任何故障在任何情况下都不会影响到另一个Fabric架构。这只能通过将两个Fabric架构从物理上完全隔离开来实现，也是为什么说从物理上将这些Fabric架构相互隔离开来无比重要的原因所在。否则，不管您的配置冗余程度有多高，都仍算是一个Fabric架构，因此仍有可能出现单点故障。怀疑者会说，这完全是贪婪的光纤通道厂商的一种伎俩，只是想让客户相信他们需要购买两套设备；我确实听到过这种说法。当然，这种说法很荒谬，而且很容易就能反驳：只需证明使用数量完全相同的设备可以构建两种不同类型的冗余网络，正如下图所示。
这是否意味着以太网/IP网络缺乏高可用性？不是。那么这是否意味着以太网/IP网络不能采用隔离开来的双Fabric架构冗余，因此不能像完全隔离的双光纤通道存储网络一样做到高度可用？从某种角度讲是这样。记住，以太网/IP网络需要支持多种应用场景，主要是支持不同应用、客户端和服务器之间、数据中心内设备和外部设备之间、公司园区网络和互联网之间的TCP/IP通信。以太网交换机之间的冗余链路基于LAG（记住这里可能没有环路），而LAG从一开始只能用于单一源交换机和单一目标交换机之间。过去几年中，业内开发了MLAG（这实际上不是一种技术或标准，而是多种厂商专用实施方法的混合）等技术来克服这一限制；但这些技术使两台交换机作为一台运行，因此需要通过一般来说非常复杂而且繁杂的配置步骤来进行相应的配置，而且需要在它们之间建立专用链路来实现心跳信息传输和同步。同样，终端设备和网络间的IP层冗余需要将设备上的两台适配器‘捆绑起来’（这实际上叫作‘NIC捆绑’）并像一台设备一样运行，并向网络提供只有一个IP地址的一个IP接口。从技术上讲，如果您有存储专用网络，就可以在以太网/IP网络中运行相互隔离开来的冗余网络，但几乎不会有这种情况。记住，推荐使用以太网/IP网络来支持存储的一个理由就是您不需要专用基础架构。
同样，市场上没有面向基于以太网的存储网络的存储专用性能监控、分析和故障排除工具，不是因为以太网本身不如光纤通道，不可能有这种工具，而是因为没有足够的客户需求，因此厂商通常自然不会投入足够的研发时间和资金来开发这种工具。这是否意味着从未有过这种工具？当然不是。但是，鉴于没有哪一家以太网交换机厂商将全部精力集中于存储，那么开发这种工具的可能性又有多大？同样，以太网和以太网厂商必须支持广泛得难以置信的应用和应用场景，而存储只是其中之一，而且从端口出货量和销售收入方面来看甚至算不上最重要的应用，因此有人投入大量时间和资金来进行开发的可能性非常小。相反，客户将不得不使用通用性能监控、分析和故障排除工具。这些通用工具不是专为存储而设计的，因此不能提供存储管理员真正所需的测量数据，而且一般基于网络数据采样方法，而采样速度又不足以帮助了解存储流量的运行行为，更重要的是不能在出现问题时足够快速地做出相应。
对于基于以太网的存储网络如何应对数千存储流量的共存，以及它们如何基于所使用的流控制机制（不管是单纯的PFC、PCF和ECN的组合，或包含或不包含ECN的TCP）来应对拥塞和背压，我们可以展开类似的讨论。换句话说，它们可以多可靠地将存储流量从源传输到目的地。以太网领域的厂商无疑在不时地努力实现这方面的改进，如开发DCB来支持FCoE，还有目前的DCTCP（数据中心TCP）计划——该计划包括对ECN和TCP进行新的增强以便在数据中心环境内提高可靠性。以太网甚至可以在需要时采用缓冲器到缓冲器流控制方法——如果流言可信，在整个行业开发DCB和FCoE时曾有厂商（猜猜是哪个公司）提出这一建议，但该建议最终被拒绝。但现实情况是，在利用以太网支持存储应用场景方面，厂商投入的研发时间和资金非常少，因为这些应用场景在以太网市场上仍是沧海一粟。
在性能方面，我们最近通过一份第三方验证报告证明，基于以太网/IP网络的存储技术（尤其是iSCSI）根本不能全面发挥当代全闪存存储阵列的性能优势，甚至不能充分利用网络的额定链路带宽。若想在复杂的高性能全闪存阵列上花费大量资金，我敢肯定您希望能够充分利用这一数额巨大的投资。
那么问题就来了，多高的可用性才算足够？1%的应用停机时间将给我带来多大损失？显而易见，并非所有应用都能一刀切。它们并非都要求99.999%的可用性；在很多情况下，以太网/IP网络及它所提供的冗余足以满足需求。多高的性能才算够高？显然，并非您所运行的所有应用都需要最高的性能或微秒级的响应时间。对很多应用来说，以太网/IP网络及它所提供的性能也已足够。对于可靠的交付和拥塞容忍，道理同样如此。总之 … 多好才算够好？
这个问题不好回答，而且在绝大多数情况下，答案是‘看情况’。每家客户都需要决定什么程度对其应用来说是‘足够好’，根本没有一刀切的正确答案。他们将提供的某些服务将需要最高的可用性，还有一些将需要尽可能高的性能，而很多其它服务将更多地关注经济高效性而不一定是性能。重要的是要让客户了解每种技术可提供什么，以便他们做出正确的决策，为每种应用或服务选择最适当的选项，避免模棱两可。不一定要采用一种解决方案来满足所有需求；完全可以让多种存储基础架构解决方案在客户数据中心内共存，分别提供最擅长的功能。
希望在读了这个文章后，您可以更好地了解光纤通道带来的独特特性，能够与其它存储网络协议或其它存储基础架构技术进行对比，进而帮助公司做出正确决策。如果我能够帮助哪怕一家客户做出正确决策。在本系列文章的最后，本人依然认为的光纤通道的美好未来；因为在全世界最苛刻的数据中心环境中，它将继续被看作是最苛刻的应用的黄金存储标准。
北京博恒视创科技有限公司是一家专业多媒体存储系统集成商。我公司联合美国Active Storage公司共同开发了Active媒体私有云共享系统、满足4k视频剪辑和大型真人秀节目制作的Active Storage光纤存储在线实时剪辑系统、满足每天100T的源数据同城或异地的数据分发与共享的远程数据复制与内容分发系统。8K电影全流程跨平台共享实时剪辑系统，现场实时调色及DIT管理系统，影视素材归档备份管理系统、海量数据自动化迁移保存系统、全媒体制播网系统等多种完全“订制化”的解决方案。2018年本公司开发出一套完整的数据安全保存系统，以“在线编辑，近线备份，离线保存”的三维立体式的解决方案，让客户数据在“生命周期”内安全的保存，没有后顾之忧，我们始终将客户的需求放在第一位，持之以恒，坚持创新，引领产品走向高容量、高带宽、高集成和人工智能化。
大型真人秀后期非编网部分成功案例：
深圳卫视《加油吧，新郎》、爱奇艺《流行之王》、北京卫视《歌手是谁》、湖南卫视《完美假期》、江西卫视《带着爸妈去旅行》、央视三套《幸福账单》、央视三套《急速少年》、湖南卫视《旋风孝子》、湖南卫视《妈妈的牵挂》、安徽卫视《国剧盛典》、安徽卫视《合唱先锋》、腾讯《拜托了冰箱》、黑龙江卫视《嘿，大兄弟》、山东卫视《家游•好儿女》、江西卫视《七天爱上你》、芒果TV《透鲜滴星期天》、CCTV《警察特训营》、爱奇艺《大学生来了》、爱奇艺《娜就这么说》、爱奇艺《我去上学啦》、浙江卫视《喜剧总动员》、芒果TV《黄金单身汉》、芒果TV《香蕉打卡》、芒果TV《不一样的偶像》、江西卫视《玫瑰之旅》、浙江卫视《开心俱乐部》、优酷《火星实验室》、内蒙古卫视《嗨，马上出发》、芒果TV《爸爸去哪儿》、芒果TV《我是大侦探》、央视《朗读者》、湖南卫视《我家那小子》、湖南卫视《幻乐之城》、湖南卫视《亲爱的客栈》、腾讯视频《创造101》、爱奇艺《偶像练习生》《青春有你》，湖南卫视《中餐厅》《亲爱的客栈3》等等真人秀节目后期机房
欲了解详情，欢迎咨询
魏 明
-------------------------------
电话: 18611689687（同微信号）
Add: 北京市朝阳区三间房东路一号懋隆文化产业创意园34栋