螃蟹不可以生吃
曾有某個大型鐵路部門，在系統(tǒng)改擴建時擬對核心業(yè)務實現(xiàn)容災，而恰逢某知名廠商隆重推出首款支持遠程數(shù)據(jù)鏡像的中端存儲產(chǎn)品。于是兩者一拍即合，國內(nèi)首個基于中端存儲設備的實時容災就此誕生。
在確定方案框架后，用戶還曾經(jīng)謹慎的測試了該存儲設備在模擬應用中的性能表現(xiàn)，并依此最終確定了產(chǎn)品配置指標。但是工程進入實施階段之后，意料之外的問題還是出現(xiàn)了。
首先是數(shù)據(jù)鏡像過程消耗了太多的設備處理能力，而控制器又無法進一步擴展，造成用戶應用得到的性能只有測試時的三分之一。然后是鏡像機制不完整，該設備不支持異步鏡像，因此對遠程鏈路的質(zhì)量和效率要求非常之高，以至于維護通訊鏈路的成本大幅度增加，基本抵消了用中端產(chǎn)品替換高端產(chǎn)品所節(jié)約的投資。最終的結(jié)果可想而知??用戶雖然在總體投入上稍微有所節(jié)省，但得到的系統(tǒng)性能卻大打折扣。
更令用戶頓足捶胸的是，僅數(shù)月之后，市場上就涌現(xiàn)出一批設計更合理、技術更完善、價格也更低廉的容災產(chǎn)品。這個剛剛上馬還處在試運行階段的產(chǎn)品立時成了“過時設備”，被無奈的列入到整改清單中。
合理而巧妙的利用新技術誠然是獲得最優(yōu)性價比的重要手段，但上面這個真實的事例告訴我們，嘗試新技術的同時也必然會伴隨風險。作為直接承擔風險責任的最終用戶，即便有勇氣做第一個吃螃蟹的人，也應該盡量設法搞清楚“螃蟹”的成熟度，尤其是針對存儲系統(tǒng)。
孔雀開屏的后面
作為全系統(tǒng)的核心基礎，存儲系統(tǒng)對整體架構(gòu)的影響可謂“牽一發(fā)而動全身”，因此對存儲系統(tǒng)的建設一定要全面考量不可偏頗。
當年虛擬存儲方興未艾的時候，某專業(yè)虛擬存儲廠商曾經(jīng)興致勃勃的召開技術演示會，向若干金融電信業(yè)的IT負責人推薦。大屏幕上“帶內(nèi)虛擬”、“帶外虛擬”、“自動資源分配”、“透明擴展”、“透明遷移”等諸多概念絢麗起舞，臺下卻有幾位老先生眉頭緊蹙。
會議行將結(jié)束的時候，一些頗有經(jīng)驗的用戶終于發(fā)問了。
“我理解，這虛擬存儲其實就是把我們現(xiàn)有的存儲設備都統(tǒng)一由你的設備來管理，然后主機再統(tǒng)一使用由你的設備提供的資源。對嗎？”
“正是。這樣您可以……”
“這樣你的設備豈不是個很大的單一故障點？我為什么要把所有數(shù)據(jù)都集中到這個相對脆弱的設備上？”
“我們的設備提供有熱備容錯功能，而且‘把所有雞蛋放在一個籃子里’也更方便管理和使用。”
“為了保障系統(tǒng)穩(wěn)定和安全，我們在前端主機和后端存儲設備上的投資非常大，現(xiàn)有你的虛擬存儲僅是價值十幾萬的設備，卻嵌入在整個系統(tǒng)的中心，這有點不合適吧？我承認虛擬存儲的各種好處，但是相對我系統(tǒng)中現(xiàn)有的‘雞蛋’，你提供的這個‘籃子’似乎脆弱了點?！?/P>
虛擬存儲技術本身的是非對錯自有公論，但這些用戶能夠不被新技術華麗的外表迷惑，敏銳的看到潛在問題，這種實事求是的態(tài)度確實值得學習。
梨子的滋味需要嘗
大型系統(tǒng)中，各種軟硬件配合關系繁多，安裝調(diào)試工作也很復雜。雖然很多設備和軟件廠商都會盡量提供一些“兼容性列表”和其他指導性文檔，但仍然可能有很小的技術細節(jié)跳出來妨礙整體系統(tǒng)正常運行。所以復雜系統(tǒng)的方案確立最好能夠以實際測試為基礎，而不是依照廠商承諾紙上談兵。對那些沒有同行業(yè)應用案例的項目，更是應該“先嘗后買”。
不久前，某石油公司的一套集群系統(tǒng)，就因為過于樂觀的相信廠商承諾，而陷入實施安裝的泥潭。
這個系統(tǒng)原本采用傳統(tǒng)的DAS存儲方式，用于處理部分勘探數(shù)據(jù)。由于近來油價高起全球業(yè)務量驟增，該系統(tǒng)的工作負載也隨之增加，解決后端存儲瓶頸成為首要問題。
經(jīng)過歷時一年的調(diào)研，用戶收集了來自幾乎每一個關聯(lián)廠商的產(chǎn)品介紹和方案建議。打印出來的卷宗堆積如山，其中的內(nèi)容囊括了硬件存儲設備、SAN/NAS架構(gòu)、虛擬存儲、集群文件系統(tǒng)、數(shù)據(jù)備份……等各個方面。
反復推敲之后，用戶最終選定以“SAN+集群文件系統(tǒng)+4層交換”作為整體方案架構(gòu)，以各領域信譽較高的廠商為產(chǎn)品供應商，并選用其中端產(chǎn)品。粗看起來，似乎這樣的方案并無風險，但如果了解到具體的規(guī)模之后，恐怕就不會那么輕松了。
按這樣的規(guī)劃，將有至少3套滿配置容量的中端存儲設備和64臺主機，同時接入一個至少128端口的SAN；64臺主機訪問存儲設備的鏈路沒有冗余；集群文件系統(tǒng)將在64臺主機間共享所有存儲空間；多臺4層交換將聯(lián)合工作，在64臺主機間均衡負載。這其中很多方面都可稱“規(guī)模龐大”，遠遠超出了一般技術人員的經(jīng)驗范圍。具體到用戶選定的產(chǎn)品，更是有很多搭配創(chuàng)了國內(nèi)首例。如此復雜的工程，其實施難度可想而知。
事實上，該系統(tǒng)的安裝調(diào)試工作經(jīng)歷了半年時間，最終用戶不得不修改最初的方案設計結(jié)構(gòu)，將這個大的SAN一分為三，才勉強讓系統(tǒng)上線運行，最初規(guī)劃的負載均衡和資源共享當然也就無從談起了。
試想用戶當初若能拿出一部分調(diào)研時間來搭建測試系統(tǒng)，也許結(jié)果會令人滿意許多。
量變到質(zhì)變
系統(tǒng)越大就越復雜，當復雜達到一定程度時，就需要有新的技術手段和機制出現(xiàn)，否則系統(tǒng)將無法工作，這是IT從業(yè)者完全理解的淺顯道理。只不過這量變到質(zhì)變的界限到底在哪里，卻時常是考驗認知和經(jīng)驗的難題。
時下全國都在準備實施“平安工程”，即公安和城管部門在城市各公共場所安放攝像頭并實時監(jiān)控，以提高打擊犯罪和維護社會治安的效率。
從技術上看，平安工程所涉及的技術手段似乎與傳統(tǒng)安全監(jiān)控系統(tǒng)并無二至，都是由攝像頭、DVR、數(shù)據(jù)網(wǎng)絡、中心服務器等部分組成，只不過前端攝像頭和DVR多些、網(wǎng)絡分布廣些、后端數(shù)據(jù)量大些。事實上，很多集成商最初提供給用戶的方案建議，就是基于傳統(tǒng)安防系統(tǒng)的版本，只在設備的配置數(shù)量上略做修改而已。殊不知這樣的方案與平安工程的實際需求差之十萬八千里之遙，根本不可能得以貫徹實施。
傳統(tǒng)樓宇或工廠的監(jiān)控系統(tǒng)，完全采用集中式管理機制。如果哪棟現(xiàn)代化大廈的每一層都有一個監(jiān)控室，那一定是個天大的笑話。但是平安工程所要求的網(wǎng)絡結(jié)構(gòu)恰恰就是分散式的，如果習慣性的用集中模式提出解決方案，不僅在技術手段上會遭遇眾多難題，而且從功能效果上也與平安工程的主旨背道而馳。
換句話說，就算集成商虧了血本搭建超級網(wǎng)絡，有本事讓全市數(shù)十萬攝像頭采集的視頻全都匯聚到中心監(jiān)控室，公安部門利用這個系統(tǒng)進行工作的場景也一定非常滑稽??中心控制室內(nèi)上萬名干警精神抖擻的盯著各自的監(jiān)視屏幕，一旦發(fā)現(xiàn)情況，馬上聯(lián)系距離事發(fā)地點最近的派出所。由于派出所反倒無法接收視頻信息，發(fā)現(xiàn)情況的干警不得不在電話里詳細描述當事人的體貌特征。搞不好“萬人監(jiān)控室”會很吵雜，手機彩信還能排上用場。
上述幾個存儲技術理念與實際情況的沖突，都是為了提醒用戶留意：技術理念大多看上去很美，但是否與您的需求吻合，就要靠實踐去檢驗了。
