存儲設計思考

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和數據處理瓶頸。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章