存储设计思考

1、联网平台中的存储中心为什么没有看到存储配置？联网平台里面的运维管理模块和智能运维管理平台的异同，后端运维管理数据是否是一样的数据源。

2、互联网接入，视频专网接入，电子政务专网，公安网 网间数据如何汇聚交换的，按照当前平安城市中视频结构化的定义要求，网间摆渡网闸仅适用于时候视频结构化分析，按需调取的原则无法适用于三类点接入情况下的互联网进入视频专网的方式，通常做法是运营商建立互联网视频汇聚中心，然后将自己作为一个二类点接入方式和委办局一样接入电子政务专网，然后数据流向视频专网。

3、在212+283=500个监控点的规模下，FC-SAN存储配置和IP-SAN配置同一品牌华为只贵7万元左右，但FC-SAN存储配置和IP-SAN配置同一品牌华为只贵7万元左右，但FC-SAN的并发用户更高，适用于接入到13个乡镇和村一级都无需端口扩容。而IP-SAN不行，为什么我们的平安城市方案配置都以IP-SAN为主，这是什么考虑。以前因为价格成本原因，现在环境变了，IP-SAN适用于DVR/NVR环境，现在对是视频结构化，视频大数据有吞吐量，实时性要求后，传统SAN适用于重点场所的有限并发下满足，但实时性方面是无法保障的是事后分析的，是ETL后的，不是大数据事前预警预测的，那么在我们的视频云+中如何部署hadoop saprk满足实时性呢？很显然IP-SAN和FC-SAN和FC-SAN和FC-SAN和FC-SAN和FC-SAN和FC-SAN和FC-SAN都不能满足，而VSAN和分布式云存储体现更明显，佳都是否能提供云存储环境下的平安城市汇聚配置方案。

4、联网平台对设备的支持方面，门禁中的科松门禁和泽博门禁，霍尼是否对应的前端设备机矩阵，解码器，编码器有一个完整的映射关联图。

5、平安城市存储配置和技术方案方面对网络存储的技术配置有考虑疑问：同样的1Gbps的光纤链路（FC）与1Gbps的千兆以太网（IP）中进行数据传输时，FC的实际利用率在70%-80%左右，最高可达90%；而在千兆以太网中，其实际利用率平均在20%左右，最高也只能达到30%左右。从以上协议本身分析看来，在以太网中并不能提供针对如存储等大数据量以及I/O应用所需要的好的性能。这也是在存储区域网设计之初没有考虑IP存储的原因，虽然TCP/IP传输协议的出现较FCP传输协议出现得早。另外基于FC协议的FC-SAN理论传输速率早已达到了4Gb/s的水平，目前业界主流也已达到了8Gb/s，而基于IP协议的IP-SAN目前来说1Gb/s的理论传输速率还是主流，未来10G/s的理论传输速率还需要10G以太网的进一步发展和强壮才能够达到。据iSCSI相关技术人员的实测数据显示：基于1Gb的IP网络搭建IP SAN，数据传输速率在80-90MB/s左右，如果是全双工模式的交换机，可以达到160MB/s左右，相比光纤通道190MB/s（全双工360MB/s）的传输速率还是有明显差距。IP-SAN存储设备的磁盘控制器不是采用FC-SAN存储设备中的硬件RAID芯片+中央处理器的结构，而是采用每个磁盘柜中分为多个磁盘组，而每个磁盘组由一个微处理芯片控制所有的磁盘RAID操作(采用软件计算，效率较低)和RAID组的管理操作。这样一来，每一次磁盘I/O操作都将经过IP-SAN存储内置的一个类似交换机的设备从前端众多的主机端口中读取或者写入数据，而这些操作都是基于IP交换协议，其协议本身就要求每一个微处理芯片工作时需要大容量的缓存来支持数据包队列的排队操作，所以一般我们看到的IP-SAN存储都具有几十个GB的缓存。利用这个大的缓存区，IP-SAN存储在测试Cache的最大读带宽时可以获得600,000IOPS甚至以上这样高的值，但是这个值并不能真正说明在实际应用中就能够获得好的性能。因为在具有海量存储的时候，不可能所有的数据均载入到系统缓存中，这个时候就需要大量的磁盘I/O操作来查找数据，而IP-SAN存储所采用的SATA磁盘在这一块切切性能非常弱，而且还涉及到一个在IP网络上流动的iSCSI数据向ATA格式数据转化的效率损失问题。也就是说IP-SAN存储存在一个缓存Cache到磁盘的数据I/O和数据处理瓶颈。