Linux叢集應用的新挑戰(轉)
Linux叢集應用的新挑戰(轉)[@more@]【導讀】Linux叢集計算已經改變了高效能運算領域的組成結構:低價的Linux叢集系統正在取代那些昂貴的、傳統意義上的超級計算機,開始被應用於解決那些更富挑戰性的高效能運算問題。
Linux叢集計算已經改變了高效能運算領域的組成結構:低價的Linux叢集系統正在取代那些昂貴的、傳統意義上的超級計算機,開始被應用於解決那些更富挑戰性的高效能運算問題。
為了充分發揮Linux叢集系統的潛在效能,我們需要一種新的儲存機制,基於物件的叢集儲存技術應運而生。基於物件的叢集儲存技術是一種新儲存系統的基礎,無論是在儲存容量還是在存取效能方面,它都有著良好的可擴充套件性。這些使得該技術可以滿足功能強大的Linux叢集系統對儲存方面的需求。
近年來,在科學研究和工程計算等領域,高效能叢集計算技術的卓越成就大家有目共睹。高效能叢集技術已逐漸佔據了高效能運算的主導地位,這一點從2003年11月公佈的世界高效能運算機排行榜中體現無疑。在該排行榜前500臺的超級計算機裡,有208臺採用了叢集系統,叢集系統已是當前高效能運算機最流行的體系結構。
現在,這種流行趨勢正由科學工程計算領域向商用領域蔓延。地質學家們正致力於研究更強大的地震分析技術,以獲取地球結構更精細的圖片,從而用來指導油田的鑽探和開發;製藥公司正在海量的基因庫中努力尋求對人類疾病更深入的理解和認識,從而可以開發出更有效的藥物或治療方法;而我們熟知的一些入口網站,如Yahoo和Google,則需要對因特網上浩如煙海的資料進行檢索和分類,從而提供給世界各地的人們使用。所有這些領域,都成為Linux叢集計算系統大顯身手的地方。同時,不得不看到,Linux叢集計算的廣泛應用也帶來了新的挑戰。
對共享儲存效能的需求不斷增長
除了對高效能運算方面的需求外,上述各商業應用還有著一個共同的特點:它們都需要高效能的I/O支援。確保叢集系統得到高效使用的必備條件是,它可以對TB(1TB=1000GB,1GB=1000MB)量級的共享資料進行快速訪問。沒有這一點,叢集系統的效能將會大幅降低。為了簡化應用系統的開發和維護,這些共享資料必須對計算叢集上的所有程式都可用。隨著叢集系統的規模越來越大、節點越來越多,為實現各個節點對共享資料的高效訪問,對儲存系統的要求也越來越高,傳統的、基於網路的儲存系統已經不能提供滿足這種共享訪問所必需的效能。
例如,在動畫生成應用中(這方面最早和最有名的例子是電影《泰坦尼克號》的特效生成,它使用了一個包含160個節點的Linux叢集系統),需要將場景生成任務分發到上百個計算節點上,其中每個節點負責生成最終場景中一個單獨的部分。共享的場景和人物資訊,以及每一幀的渲染指令必須能夠為每一個參與計算的節點所訪問,而每個節點計算一幀會產生大約50MB的輸出。最後各個單獨的幀依次組合,得到完整的一幅畫面。這樣的流程是許多叢集計算應用過程中常見的資料訪問情形。
傳統的共享儲存方法的缺點
叢集計算的開發者們自然地採用了能夠被叢集系統中所有節點訪問的共享儲存系統。讓我們先來簡單審視一下現有的這種共享儲存系統。
首先是檔案伺服器。它將磁碟陣列(RAID)直接連線到網路系統中的伺服器上,這種形式的網路儲存結構稱為DAS(Direct Attached Storage)。這種結構中,各類儲存裝置透過IDE或SCSI等I/O匯流排與檔案伺服器相連。叢集節點的資料訪問必須透過檔案伺服器,然後經過I/O 匯流排訪問相應的儲存裝置。當連結節點數增多時,I/O匯流排將會成為一個潛在的瓶頸,因此這種儲存方式只適用於小規模的叢集系統,大一些的叢集需要更具擴充套件性的儲存系統。
儲存區域網(SAN,Storage-Area Networks)和最佳化後的直接網路儲存,或者網路附加儲存(NAS,Network-Attached Storage)結構被用於中等規模的叢集系統。SAN是一種類似於普通區域網的高速儲存網路,通常由RAID陣列連線光纖通道組成。SAN和叢集節點的資料通訊通常是由SCSI命令,而不是網路協議實現(如圖1所示)。
在NAS儲存結構中,儲存系統不再透過I/O匯流排附屬於某個特定的伺服器或客戶機,而是透過網路介面與網路直接相連,叢集節點透過網路協議(如TCP/IP)對共享資料進行訪問(如圖2所示)。
然而,當叢集變得龐大時,這些結構都存在著嚴重的缺陷。面對眾多叢集計算應用系統的高併發性和單節點高吞吐需求,無論是SAN還是NAS結構都顯得力不從心。由於這兩方面的侷限,在實際應用中,人們不得不採用資料“搬家”的策略。首先將資料從共享儲存系統搬到計算節點上進行處理,處理結束後,再將計算結果從計算節點搬回共享儲存系統。在大規模的叢集系統上,很多應用程式為了這樣的搬家需要花費幾個小時甚至更多時間。
一個新興的標準:基於物件的儲存
對眾多的叢集計算使用者來說,一種基於物件的儲存技術正作為構建大規模儲存系統的基礎而悄然興起。它利用現有的處理技術、網路技術和儲存元件,可以透過一種簡單便利的方式來獲得前所未有的可擴充套件性和高吞吐量。
這種體系結構的核心是物件,物件是容納了應用資料和一個可擴充套件的儲存屬性的基本容器。傳統的檔案被分解為一系列儲存物件,並分發到一個或多個 “智慧磁碟”上,這種磁碟被稱為基於物件的儲存裝置(OSD,Object-based Storage Devices)。每一個OSD具備本地處理功能、用於資料和屬性快取的本地記憶體和本地的網路連線。OSD構成了分散式儲存結構的核心,它將許多傳統的儲存分配行為從檔案系統層轉移,從而解決了當前儲存系統的一個瓶頸問題。
物件屬性包括了安全資訊和使用狀況統計資訊,這些資訊被用於基於安全認證的訪問、服務質量控制,以及為實現OSD間負載均衡所需的資料動態分配。物件儲存技術採用了和叢集計算系統類似的可擴充套件結構,當儲存容量增加時,它提供的均衡模型能夠保證網路頻寬和處理能力也同步增長,從而確保系統的可擴充套件性。
儲存網路工業協會(SNIA)和T10標準技術委員會中的聯合技術小組正在制定一個關於OSD的標準。標準包括了一個針對iSCSI協議的命令集,它在原有的SCSI命令集中增添了物件擴充套件功能。同時,物件規範和命令集的制定促使了一種新的智慧儲存裝置的出現,這種智慧儲存裝置可以整合到基於 IP的、高效能、大規模並行儲存環境中去。目前多個業內領先的儲存裝置公司都參與了這項工作,其中包括EMC、惠普、IBM、Intel、希捷及 Veritas軟體公司等。
共享儲存的實現
物件儲存結構提供了新一代網路儲存系統的基礎。在新興的應用中,它和一種可擴充套件的、為應用程式提供檔案系統介面的後設資料管理層結合在一起。這一層負責管理諸如目錄隸屬關係和檔案所有許可權這樣的資訊。它同樣負責將跨OSD的儲存物件(每個儲存物件是檔案的一部分)聯接成一個檔案,以確保資料的可靠和可用。叢集節點向這一層提出請求,例如開啟或關閉檔案,透過認證後,接受它能夠訪問OSD所必需的資訊,此後叢集節點可以直接對檔案進行讀寫操作,而和後設資料管理層無關。
物件儲存結構作為可擴充套件叢集檔案系統的一部分被實現後,就能夠為數以百計的客戶端提供高容量的總頻寬。簡而言之,物件儲存技術可以為高效能Linux叢集系統提供高價效比的共享儲存。
Linux叢集計算已經改變了高效能運算領域的組成結構:低價的Linux叢集系統正在取代那些昂貴的、傳統意義上的超級計算機,開始被應用於解決那些更富挑戰性的高效能運算問題。
為了充分發揮Linux叢集系統的潛在效能,我們需要一種新的儲存機制,基於物件的叢集儲存技術應運而生。基於物件的叢集儲存技術是一種新儲存系統的基礎,無論是在儲存容量還是在存取效能方面,它都有著良好的可擴充套件性。這些使得該技術可以滿足功能強大的Linux叢集系統對儲存方面的需求。
近年來,在科學研究和工程計算等領域,高效能叢集計算技術的卓越成就大家有目共睹。高效能叢集技術已逐漸佔據了高效能運算的主導地位,這一點從2003年11月公佈的世界高效能運算機排行榜中體現無疑。在該排行榜前500臺的超級計算機裡,有208臺採用了叢集系統,叢集系統已是當前高效能運算機最流行的體系結構。
現在,這種流行趨勢正由科學工程計算領域向商用領域蔓延。地質學家們正致力於研究更強大的地震分析技術,以獲取地球結構更精細的圖片,從而用來指導油田的鑽探和開發;製藥公司正在海量的基因庫中努力尋求對人類疾病更深入的理解和認識,從而可以開發出更有效的藥物或治療方法;而我們熟知的一些入口網站,如Yahoo和Google,則需要對因特網上浩如煙海的資料進行檢索和分類,從而提供給世界各地的人們使用。所有這些領域,都成為Linux叢集計算系統大顯身手的地方。同時,不得不看到,Linux叢集計算的廣泛應用也帶來了新的挑戰。
對共享儲存效能的需求不斷增長
除了對高效能運算方面的需求外,上述各商業應用還有著一個共同的特點:它們都需要高效能的I/O支援。確保叢集系統得到高效使用的必備條件是,它可以對TB(1TB=1000GB,1GB=1000MB)量級的共享資料進行快速訪問。沒有這一點,叢集系統的效能將會大幅降低。為了簡化應用系統的開發和維護,這些共享資料必須對計算叢集上的所有程式都可用。隨著叢集系統的規模越來越大、節點越來越多,為實現各個節點對共享資料的高效訪問,對儲存系統的要求也越來越高,傳統的、基於網路的儲存系統已經不能提供滿足這種共享訪問所必需的效能。
例如,在動畫生成應用中(這方面最早和最有名的例子是電影《泰坦尼克號》的特效生成,它使用了一個包含160個節點的Linux叢集系統),需要將場景生成任務分發到上百個計算節點上,其中每個節點負責生成最終場景中一個單獨的部分。共享的場景和人物資訊,以及每一幀的渲染指令必須能夠為每一個參與計算的節點所訪問,而每個節點計算一幀會產生大約50MB的輸出。最後各個單獨的幀依次組合,得到完整的一幅畫面。這樣的流程是許多叢集計算應用過程中常見的資料訪問情形。
傳統的共享儲存方法的缺點
叢集計算的開發者們自然地採用了能夠被叢集系統中所有節點訪問的共享儲存系統。讓我們先來簡單審視一下現有的這種共享儲存系統。
首先是檔案伺服器。它將磁碟陣列(RAID)直接連線到網路系統中的伺服器上,這種形式的網路儲存結構稱為DAS(Direct Attached Storage)。這種結構中,各類儲存裝置透過IDE或SCSI等I/O匯流排與檔案伺服器相連。叢集節點的資料訪問必須透過檔案伺服器,然後經過I/O 匯流排訪問相應的儲存裝置。當連結節點數增多時,I/O匯流排將會成為一個潛在的瓶頸,因此這種儲存方式只適用於小規模的叢集系統,大一些的叢集需要更具擴充套件性的儲存系統。
儲存區域網(SAN,Storage-Area Networks)和最佳化後的直接網路儲存,或者網路附加儲存(NAS,Network-Attached Storage)結構被用於中等規模的叢集系統。SAN是一種類似於普通區域網的高速儲存網路,通常由RAID陣列連線光纖通道組成。SAN和叢集節點的資料通訊通常是由SCSI命令,而不是網路協議實現(如圖1所示)。
在NAS儲存結構中,儲存系統不再透過I/O匯流排附屬於某個特定的伺服器或客戶機,而是透過網路介面與網路直接相連,叢集節點透過網路協議(如TCP/IP)對共享資料進行訪問(如圖2所示)。
然而,當叢集變得龐大時,這些結構都存在著嚴重的缺陷。面對眾多叢集計算應用系統的高併發性和單節點高吞吐需求,無論是SAN還是NAS結構都顯得力不從心。由於這兩方面的侷限,在實際應用中,人們不得不採用資料“搬家”的策略。首先將資料從共享儲存系統搬到計算節點上進行處理,處理結束後,再將計算結果從計算節點搬回共享儲存系統。在大規模的叢集系統上,很多應用程式為了這樣的搬家需要花費幾個小時甚至更多時間。
一個新興的標準:基於物件的儲存
對眾多的叢集計算使用者來說,一種基於物件的儲存技術正作為構建大規模儲存系統的基礎而悄然興起。它利用現有的處理技術、網路技術和儲存元件,可以透過一種簡單便利的方式來獲得前所未有的可擴充套件性和高吞吐量。
這種體系結構的核心是物件,物件是容納了應用資料和一個可擴充套件的儲存屬性的基本容器。傳統的檔案被分解為一系列儲存物件,並分發到一個或多個 “智慧磁碟”上,這種磁碟被稱為基於物件的儲存裝置(OSD,Object-based Storage Devices)。每一個OSD具備本地處理功能、用於資料和屬性快取的本地記憶體和本地的網路連線。OSD構成了分散式儲存結構的核心,它將許多傳統的儲存分配行為從檔案系統層轉移,從而解決了當前儲存系統的一個瓶頸問題。
物件屬性包括了安全資訊和使用狀況統計資訊,這些資訊被用於基於安全認證的訪問、服務質量控制,以及為實現OSD間負載均衡所需的資料動態分配。物件儲存技術採用了和叢集計算系統類似的可擴充套件結構,當儲存容量增加時,它提供的均衡模型能夠保證網路頻寬和處理能力也同步增長,從而確保系統的可擴充套件性。
儲存網路工業協會(SNIA)和T10標準技術委員會中的聯合技術小組正在制定一個關於OSD的標準。標準包括了一個針對iSCSI協議的命令集,它在原有的SCSI命令集中增添了物件擴充套件功能。同時,物件規範和命令集的制定促使了一種新的智慧儲存裝置的出現,這種智慧儲存裝置可以整合到基於 IP的、高效能、大規模並行儲存環境中去。目前多個業內領先的儲存裝置公司都參與了這項工作,其中包括EMC、惠普、IBM、Intel、希捷及 Veritas軟體公司等。
共享儲存的實現
物件儲存結構提供了新一代網路儲存系統的基礎。在新興的應用中,它和一種可擴充套件的、為應用程式提供檔案系統介面的後設資料管理層結合在一起。這一層負責管理諸如目錄隸屬關係和檔案所有許可權這樣的資訊。它同樣負責將跨OSD的儲存物件(每個儲存物件是檔案的一部分)聯接成一個檔案,以確保資料的可靠和可用。叢集節點向這一層提出請求,例如開啟或關閉檔案,透過認證後,接受它能夠訪問OSD所必需的資訊,此後叢集節點可以直接對檔案進行讀寫操作,而和後設資料管理層無關。
物件儲存結構作為可擴充套件叢集檔案系統的一部分被實現後,就能夠為數以百計的客戶端提供高容量的總頻寬。簡而言之,物件儲存技術可以為高效能Linux叢集系統提供高價效比的共享儲存。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10617542/viewspace-960291/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Linux叢集大全(轉)Linux
- ELK 在 Spark 叢集的應用Spark
- 叢集的應用例項(zt)
- Linux 叢集技術(轉)Linux
- 管理應用程式面臨的挑戰
- Linux發行商支援統一標準 集體挑戰Windows(轉)LinuxWindows
- 機器學習的技術原理、應用與挑戰機器學習
- 管理的挑戰——軟技能在專案管理中的應用案例(轉)專案管理
- 叢集式數字監控應用模型研究(一) (轉)模型
- Redis專案實戰---應用及理論(二)---Redis叢集原理Redis
- Quartz叢集原理及配置應用quartz
- 應用級叢集系統的設計
- Linux作業系統的嵌入式領域面臨新挑戰(轉)Linux作業系統
- 新產品:無需應用伺服器的開源叢集框架Corus伺服器框架
- 基於linux的叢集系統(二)(轉)Linux
- 大型單頁面應用的進階挑戰
- 分散式 PostgreSQL 叢集(Citus)官方示例 - 多租戶應用程式實戰分散式SQL
- Zookeeper應用場景之【叢集管理】
- 採用Scrum的挑戰Scrum
- linux下搭建ZooKeeper叢集(偽叢集)Linux
- Linux叢集的安裝與平行計算(轉)Linux
- 擴散模型在機器學習中的應用及其挑戰模型機器學習
- Linux 叢集系統大比拼(轉)Linux
- 用Docker搭建RabbitMq的普通叢集和映象叢集DockerMQ
- “遷移策略+新容器執行時”應對有狀態應用的冷熱遷移挑戰
- Novell演示款最新的Linux版 欲挑戰微軟(轉)Linux微軟
- 工程專案管理的新挑戰—可持續發展(轉)專案管理
- 專案經理負責制遇到新挑戰(轉)
- 新的產品,新的挑戰(圖靈訪談)圖靈
- 叢集映象:實現高效的分散式應用交付分散式
- Etcd叢集的介紹和選主應用
- 白話多叢集:工具和應用助手
- Linux 叢集化Linux
- MySQL在Web應用領域面臨NoSQL的挑戰MySqlWeb
- 高可用的MongoDB叢集-實戰篇MongoDB
- 產業叢集(轉載)產業
- MySQL叢集配置(轉)MySql
- 有屏智慧音響的新戰爭、新挑戰、新變數變數