自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

數(shù)據(jù)中心網(wǎng)絡(luò)聚合:新策略和文化沖突

網(wǎng)絡(luò)
在線技術(shù)研究社區(qū)Wikibon的首席研究貢獻者Stuart Miniman指出,如果網(wǎng)絡(luò)專業(yè)人員在他們的生產(chǎn)網(wǎng)絡(luò)中傳輸存儲流量,那么他們也要熟悉存儲專業(yè)人員的管理問題。

隨著存儲和數(shù)據(jù)的聚合,網(wǎng)絡(luò)人員必須以新的方式來考慮網(wǎng)絡(luò)連接。“您必須認識到您將會傳輸更多的流量,并且它對延遲更加敏感,而且對可用性也非常敏感,”Foskett說。“您必須保證網(wǎng)絡(luò)不會中斷。如果您失去了數(shù)據(jù)中心,那么人們將很難接受。如果你失去了存儲網(wǎng)絡(luò),那么服務器也將崩潰。”

而且,在線技術(shù)研究社區(qū)Wikibon的首席研究貢獻者Stuart Miniman指出,如果網(wǎng)絡(luò)專業(yè)人員在他們的生產(chǎn)網(wǎng)絡(luò)中傳輸存儲流量,那么他們也要熟悉存儲專業(yè)人員的管理問題。

“存儲人員真正關(guān)心的是數(shù)據(jù)可用性,以及保證不會出現(xiàn)數(shù)據(jù)丟失,與之相反,網(wǎng)絡(luò)管理員真正關(guān)心的是保證連接、帶寬和回彈性的存在,”Miniman說。

當存儲人員和網(wǎng)絡(luò)人員一起工作時,這些不同的心態(tài)會造成文化沖突?,F(xiàn)在他們必須找到共同點。

“我們聽到過有一些人從未聚合過,因為他們的網(wǎng)絡(luò)人員和SAN人員相互之間根本不交流,” 阿拉巴馬大學伯明翰分校的IT基礎(chǔ)架構(gòu)服務執(zhí)行主管Bob Cloud說道。“我們比較特別,因為我?guī)ьI(lǐng)的團隊中既有網(wǎng)絡(luò)人員,也有SAN人員。”

Cloud安排他的存儲和網(wǎng)絡(luò)團隊一起在數(shù)據(jù)中心實現(xiàn)基于FCoE的網(wǎng)絡(luò)聚合。作為使用Brocade的Ethernet和Fibre Channel產(chǎn)品的客戶,從去年九月份開始,Cloud就選擇嘗試使用用Brocade技術(shù)實現(xiàn)的FCoE。

他在一臺服務器機架上引入了兩臺冗余Brocade 8000頂級機架交換機。機架中的服務器是通過FCoE與交換機連接的。然后這兩臺8000交換機通過Fibre Channel連接將存儲流量發(fā)送到一臺Brocade DCX存儲控制交換機,并通過Ethernet上行鏈路將生產(chǎn)數(shù)據(jù)流量發(fā)送到上游Brocade FastIron SuperX交換機。一開始,存儲和網(wǎng)絡(luò)團隊不清楚誰應該負責管理Brocade 8000 FCoE交換機。

“我認為在交換機的擁有者和使用者是誰的問題上很自然會存在一些爭議,”Cloud說。“但是我們很快就解決了這個問題,因為在我們的數(shù)據(jù)中心內(nèi),網(wǎng)絡(luò)小組和SAN小組都是向我報告的。我要求他們解決這個問題,因為現(xiàn)在是試驗階段。試驗的目的就是要解決這些組織問題。”

為何要進行數(shù)據(jù)中心聚合?

圍繞數(shù)據(jù)中心聚合的宣傳,以及選擇FCoE還是iSCSI之間的斗爭會使人忽略核心的問題:最終所有的存儲都將通過生產(chǎn)環(huán)境的Ethernet網(wǎng)絡(luò)傳輸,而工程師必須為這個轉(zhuǎn)變做好準備。

聽供應商的介紹會讓人心煩意亂,因為他們講的每件事都是從自己的角度出發(fā)看問題。Cisco Systems和Brocade是FCoE的主要推動者。而同時,Dell告訴它的客戶在Ethernet上使用iSCSI是聚合發(fā)展方向。諸如Intel這樣的芯片供應商和諸如QLogic和Emulex這樣的網(wǎng)絡(luò)適配器供應商則都積極準備,以支持企業(yè)選擇的任意一種技術(shù)。

企業(yè)必須忽視供應商的宣傳,相反要考慮他們現(xiàn)有的基礎(chǔ)架構(gòu)投入,以便決定選擇哪種技術(shù)。他們也必須理解網(wǎng)絡(luò)聚合可能是小規(guī)模地增長,不可能在短期內(nèi)超過機架級的增長。

“一般當客戶來找我們時,他們已經(jīng)選擇了一種聚合類型,而我們必須讓他們了解到實際上還有很多不同的選擇,并且它們不是互相排斥的,”大型系統(tǒng)集成商的數(shù)據(jù)中心實踐技術(shù)解決方案架構(gòu)師Joe Onisick說道。

為什么需要數(shù)據(jù)中心網(wǎng)絡(luò)聚合?

隨著10Gigabit Ethernet (GbE)、服務器虛擬化和其它技術(shù)的廣泛應用,企業(yè)必須認真處理網(wǎng)絡(luò)聚合,以便控制資金和運營花費,并降低復雜性。

“如果您在一個機架上部署了很多服務器,特別是VMware機架,那么您可能需要為每臺服務器配備10條Gigabit Ethernet銅線連接和2條Fibre Channel連接,”位于田納西州的連鎖醫(yī)院Wellmont Health System的技術(shù)總監(jiān)Darren Ramsey說道。“假如您的機架上有10臺服務器,那就需要120條電纜。這要耗費大量的人力,是非常不靈活的布線,并且會產(chǎn)生大量的熱量。同時,交換機端口也不便宜。”

在他的數(shù)據(jù)中心中,Ramsey最近通過使用Cisco的Nexus線在8個虛擬化Dell服務器機架中引進了網(wǎng)絡(luò)聚合。他將每臺服務器上的10個NICS和2個主線適配器(HBA)合并為2個QLogic聚合網(wǎng)絡(luò)適配器(CAN),從而為冗余的頂級機架Nexus 2232 Fabric Extenders提供2條10 GbE FCoE連接。全部共8對Nexus 2232 Fabric Extenders將上行流連接到2臺冗余的Nexus 5020交換機上。存儲和數(shù)據(jù)流量通過FCoE聚合到Nexus 5020上。這樣,存儲流量就可以返回到本地Fibre Channel,然后連接到存儲區(qū)網(wǎng)絡(luò)(SAN)中的一對Cisco MDS 9506 Director交換機上。生產(chǎn)數(shù)據(jù)流量會繼續(xù)連接上行到Catalyst 6509交換機。

“FCoE優(yōu)化并減少了我們所需的Fibre Channel端口數(shù),因為所有的主機現(xiàn)在都直接在Nexus上運行,”Ramsey說道。“我們不再需要從服務器直接連接到MDS上。同時它還減少了每個機架的復雜性。當我們在每臺服務器上使用2條10 Gigabit連接時,我們就能夠在該設(shè)備上運行更多的虛擬機。”

網(wǎng)絡(luò)聚合:是iSCSI還是FCoE?

FCoE占據(jù)了所有數(shù)據(jù)中心網(wǎng)絡(luò)聚合宣傳的重心,但是很多行業(yè)資深人員表示,iSCSI是另外一種可行的選擇。作為一種基于IP的存儲網(wǎng)絡(luò)協(xié)議,iSCSI可以很自然地運行在Ethernet網(wǎng)絡(luò)上。大多數(shù)使用iSCSI的企業(yè)目前都通過他們自己的獨立網(wǎng)絡(luò)來運行存儲協(xié)議的,因為聚合并不適合Gigabit Ethernet。但是隨著10 GbE交換機價格的下降,基于iSCSI的聚合也正變得越來越符合現(xiàn)實要求。

“可以肯定的是,轉(zhuǎn)到iSCSI比到FCoE更簡單一些,”存儲博主及IT咨詢師Stephen Foskett說。“有了iSCSI,您就不需要使用數(shù)據(jù)中心橋接、新NIC、新布線或者新交換機。”

最終企業(yè)的現(xiàn)有基礎(chǔ)架構(gòu)和存儲需求將決定網(wǎng)絡(luò)聚合方法的選擇。

“如果客戶還不準備部署Fibre Channel,那么我很少會鼓勵他們采用FCoE,”Onisick說。“如果他們需要非常高的性能和非常低的塊數(shù)據(jù)吞吐量,那么FCoE是個好方法。如果他們能夠容忍稍微高一點的延遲,那么iSCSI會很好。而且,如果他們沒有塊數(shù)據(jù)方面的需求,那么NAS(網(wǎng)絡(luò)附加存儲)和NFS(網(wǎng)絡(luò)文件系統(tǒng))是好的選擇。”

對于Ramsey,iSCSI不是一種可行的方法,因為Wellmont有高性能方面的需求。

“我們用過iSCSI,但它仍然是通過TCP運行的,而且您需要處理緩沖、流控制、開窗口或丟包和排列問題,所以我們不會使用iSCSI。FCoE的優(yōu)點是:它不運行在3層協(xié)議上。它是原生2層協(xié)議幀中的Fibre Channel數(shù)據(jù)包封裝,而我們所做的就是在服務器與Nexus 2232和Nexus 5020之間傳輸這個數(shù)據(jù)包。”

 

責任編輯:佟健 來源: TechTarget中國
相關(guān)推薦

2015-11-13 10:55:53

DevOps網(wǎng)絡(luò)運維

2010-04-22 15:50:39

2010-04-22 14:42:10

2016-07-25 13:01:56

大型數(shù)據(jù)中心SDNSDS

2024-05-09 12:57:04

數(shù)據(jù)中心

2023-07-26 15:46:26

數(shù)據(jù)中心數(shù)據(jù)存儲

2018-11-29 11:21:09

數(shù)據(jù)中心數(shù)據(jù)中心互連DCI

2019-05-09 10:32:31

數(shù)據(jù)中心層級IT基礎(chǔ)設(shè)施

2023-06-28 11:39:02

數(shù)據(jù)中心服務器

2009-12-31 16:22:57

數(shù)據(jù)中心之“變” 網(wǎng)絡(luò)

2011-04-12 10:54:30

網(wǎng)絡(luò)布局機房布線

2009-02-25 09:32:19

2009-04-14 12:59:30

Nehalemintel數(shù)據(jù)中心

2017-01-04 12:58:50

數(shù)據(jù)中心網(wǎng)絡(luò)效率

2020-01-09 10:50:46

數(shù)據(jù)中心IT技術(shù)

2010-08-05 09:36:06

2017-12-28 14:12:39

數(shù)據(jù)中心升級策略

2012-05-02 10:06:34

虛擬桌面基礎(chǔ)架構(gòu)VDI數(shù)據(jù)中心

2019-03-29 14:45:29

數(shù)據(jù)中心容器網(wǎng)絡(luò)技術(shù)

2014-12-02 09:29:51

Facebook數(shù)據(jù)中心運維
點贊
收藏

51CTO技術(shù)棧公眾號