這篇文章主要為大家展示了“HDFS如何進行升級管理”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“HDFS如何進行升級管理”這篇文章吧。
成都做網(wǎng)站、網(wǎng)站制作,成都做網(wǎng)站公司-創(chuàng)新互聯(lián)已向近1000家企業(yè)提供了,網(wǎng)站設(shè)計,網(wǎng)站制作,網(wǎng)絡(luò)營銷等服務(wù)!設(shè)計與技術(shù)結(jié)合,多年網(wǎng)站推廣經(jīng)驗,合理的價格為您打造企業(yè)品質(zhì)網(wǎng)站。
Hadoop的官方文檔中，對于HDFS的升級建議分三個步驟，1，先停掉HDFS服務(wù)，再啟動，HDFS合并FsEditLog到FsImage之中，再停掉HDFS服務(wù)，2，備份namenode的meta文件，在新版本HDFS安裝目錄的配置文件中，配置namenode的meta文件目錄指向舊有的meta文件目錄，以-upgrade選項啟動HDFS，讓HDFS服務(wù)執(zhí)行升級過程，3，升級進度達到100%后，執(zhí)行hadoop dfsadmin -finlizeUpgrade告訴HDFS服務(wù)，升級結(jié)束。如果升級失敗，以-rollback選項啟動HDFS，執(zhí)行回滾。
從升級到本身使命來說，升級到目的就是為了保護現(xiàn)有數(shù)據(jù)，如果在升級過程中，出現(xiàn)因為升級而導(dǎo)致數(shù)據(jù)丟失，或者整個HDFS文件系統(tǒng)的損壞，那升級就失敗了?？赐闔adoop官方文檔的升級過程和命令后，我很好奇，如此簡單的描述，能保證升級過程一定是“達到”目的的嗎？或者至少保證不會損壞HDFS文件系統(tǒng)本身！
懷疑是懷疑，等了解它，再對它下結(jié)論！然而HDFS升級的資料非常少，這里從源碼分析，力求做到最接近作者升級設(shè)計的意圖。
在HDFS文件系統(tǒng)中，NameNode的一個基本職責(zé)是分配塊到datanode上；告訴客戶端一個塊的內(nèi)容可以從哪臺機器上能讀取到。塊信息對于HDFS文件系統(tǒng)來說，是非常重要的，為了不丟失塊信息，并能讓客戶端，datanode能快速懂檢索塊信息，HDFS的開發(fā)者們在設(shè)計NameNode的存儲結(jié)構(gòu)時，借鑒了數(shù)據(jù)庫的WAH一些做法，但同時又采用了一種非常不常見到做法。
為了保證塊信息不丟失，HDFS在分配一個塊時，先寫塊信息的日志到磁盤的文件系統(tǒng)，這個存儲在HDFS中叫fsEditLog，日志寫成功后，再向處于JVM heap中的一種可以存儲重復(fù)HASH值條目的Map中，添加這個塊信息，如果是刪除塊操作，則是從這個Map中刪除相應(yīng)的條目。這個Map中保存了HDFS中所有塊信息，而不是常見的緩存部分數(shù)據(jù)。在HDFS的namenode存儲中，磁盤上存儲的塊信息和Map中存儲的塊信息的實際數(shù)量是一樣的。為了保證這個Map所存儲的數(shù)據(jù)不超過JVM Heap的限制，Namenode在啟動的時候，默認JVM的-Xx啟動參數(shù)值的2%作為計算這個Map最多可以容納條目的數(shù)量，Map中的條目達到這個最大值時，則不可以添加新的塊。在磁盤端，塊信息主要存儲在fsImage中，塊操作日志存儲在fsEditLog中，自fsImage文件中最后的事務(wù)點后，對于塊的操作是首先順序?qū)ψ芳拥絝sEditLog中，而不是直接寫入fsImage。HDFS服務(wù)在啟動時會啟動一個checkpointer組件，定期的把當(dāng)前的fsImage和fsEditLog合并到新的fsImage中。
NameNode的meta內(nèi)部物理結(jié)構(gòu)如下圖所示：
`-- current |-- edits_0000000000000000001-0000000000000000007 |-- edits_inprogress_0000000000000000008 |-- fsimage_0000000000000000000 |-- fsimage_0000000000000000000.md5 |-- seen_txid `-- VERSION
從存儲上看HDFS的存儲結(jié)構(gòu)，只有在HDFS啟動時，從fsImage中載人塊信息到內(nèi)存端的Map，或者在需要時，把內(nèi)存端的Map寫入磁盤端去。對于塊的增、刪、改這樣的操作，內(nèi)存端和磁盤端獨立，日志能保證最終的塊信息在兩端是一致的。這樣設(shè)計的好處是，簡單，容易實現(xiàn)，缺點是內(nèi)存端大小會受到限制，不容易擴展。
相對NameNode對于塊的存儲結(jié)構(gòu)，DataNode上對于塊的存儲結(jié)構(gòu)簡單很多，DataNode只存儲<塊，大小>對。一個塊被寫入到DataNode上后，會寫一個和這個塊名相同的meta文件，存儲塊大小和塊生成的時間。DataNode中，對塊的生命周期進行了細致的劃分，當(dāng)向文件追加的新塊時，塊的是位于RBW目錄（1.x則是在BlockBeingWritten目錄），當(dāng)這個塊達到系統(tǒng)指定的塊大小或者文件寫關(guān)閉，這個塊會變成finallized狀態(tài)，DataNode把此塊移動到current/finallized目錄中。
在HDFS 2.x中，對于數(shù)據(jù)塊的存儲是按照BlockPoolSlice來管理的，從邏輯上說，一個BlockPoolSlice代表DataNode配置項dfs.datanode.data.dir中的一個目錄。DataNode上新建塊，移動和刪除塊是通過BlockPoolSlice完成邏輯上的操作。BlockPoolSlice內(nèi)部的物理結(jié)構(gòu)如下圖所示：
|-- current | |-- BP-1134876178-10.1.101.51-1427874067591 | | |-- current | | | |-- dfsUsed | | | |-- finalized | | | |-- rbw | | | `-- VERSION | | |-- dncp_block_verification.log.curr | | |-- dncp_block_verification.log.prev | | `-- tmp | `-- VERSION |-- detach |-- in_use.lock |-- storage `-- tmp
對于NameNode meta文件的升級，NameNode在啟動時，如果分析帶有upgrade命令選項，會升級meta文件夾中的current目錄，現(xiàn)在假設(shè)HDFS剛重啟過一次，并沒有新的塊添加到HDFS中，此時，fsEditLog都是空的，對于此目錄的操作按照下面的操作步驟進行。
如果meta文件夾中有previous目錄，刪除它
把current重名為previous.tmp
新建current目錄
把previous.tmp文件下的VERSION文件升級為當(dāng)前安裝的版本，寫入current目錄
載人previous.tmp文件下fsImage到中的文件和塊到內(nèi)存，載入這個過程是向下兼容的，經(jīng)載入后的文件和塊已經(jīng)被轉(zhuǎn)化成當(dāng)前安裝版本的格式。
舊版本fsImage中的genStamp、clusterId、numFiles信息保留不變，但舊版本的fsImage文件名和fsEditLog文件可能會改變
在fsImage載入成功后，把處于內(nèi)存端的文件和塊按照最新的格式寫入磁盤的current目錄，并且在這個時候，告訴系統(tǒng)，NameNode的meta文件升級操作完成！
從這個過程中，可以看出，NameNode在升級的過程中，并沒有在舊版本的fsImage和fsEditLog上直接進行操作，而是新建一個文件夾，這樣的方式是非常安全的。首先解開了開篇的一半疑問。
DataNode升級的過程和NameNode的fsImage升級的方式比較類似，但在具體操作上有很大的不同，DataNode上存儲的主要是數(shù)據(jù)塊，如果采用復(fù)制數(shù)據(jù)塊到新的目錄，那復(fù)制PB，EB級別的數(shù)據(jù)，這個過程將變得不可想象。大師們?yōu)镈ataNode的升級尋找到了一個合適的方案。
對于一個BlockPoolSlice的物理文件夾，升級執(zhí)行下面的步驟
如果BlockPoolSlice的物理文件夾中有previous，刪除它
重命名current目錄為previous.tmp
在DataNode文件中創(chuàng)建current/{bpid}/current目錄, 這里的bpid是blockpool ID，是HDFS 2.x版本中引入的新術(shù)語，用于管理block pool slice
遍歷previous.tmp文件中所有的塊，為這些塊建立硬連接，保存到current/{bpid}/current目錄，這個過程中，塊文件的名稱可能會因版本跨度而發(fā)送變化。回想一下NameNode中塊信息的升級，由于塊信息中塊的文件名主要包戶一個生成的時間戳和文件的序列號，因此，在變更塊文件名的時候，只要NameNode和DataNode按照相同的規(guī)則進行變換，在升級后，仍能保持和HDFS升級前在用戶層面上是的一致的。
重命名previous.tmp目錄為previous，并在這個時候告訴HDFS，此block pool slice升級完成
硬連接是某些文件系統(tǒng)的一個高級特性，某些文件系統(tǒng)中設(shè)計有兩種Node，一種是INode，存儲文件的索引信息，一種是DataBlock，存儲文件真正的數(shù)據(jù)，文件的名字是存儲在INode中的，INode還使用一個指針指向此文件的第一個DataBlock，建立硬連接實質(zhì)上是為文件的數(shù)據(jù)塊新建一個INode，這個INode也是指向此文件的第一個數(shù)據(jù)塊。而這個INode中包含的文件名可以和此文件的原名字不同。當(dāng)然，原文件名其實也是存儲該文件DataBlock的硬連接。在這樣的文件系統(tǒng)上，刪除一個文件，只是刪除這個文件的INode，如果一個文件的DataBlock沒有INode指向它，這些DataBlock就可以被文件系統(tǒng)回收。只要還有一個INode指向這些DataBlock，它們就不會被回收。在這樣的文件系統(tǒng)中，INode可以被設(shè)計得很小，比如Ext4，一個INode占512字節(jié)，一個DataBlock至少是4K，在格式化磁盤時，系統(tǒng)分配INode的個數(shù)約為DataBlock個數(shù)的1/8。
所以，采用硬連接的方式升級DataNode所需要操作的磁盤空間就小很多了。從邏輯上說，也不會對文件系統(tǒng)造成損壞。
如果升級過程失敗，需要通過rollback命令選項，讓HDFS回滾到升級之前到狀態(tài)。由于此時兩個版本的HDFS文件系統(tǒng)信息都是是存在的，回滾的過程其實是一個文件夾重命名的過程，具體的步驟如下面：
把current目錄重名為remove.tmp
把previous目錄重命名為current
刪除remove.tmp目錄
到此時，HDFS升級的細節(jié)討論的差不多，對HDFS能成功升級也抱有信心，當(dāng)然能安全回滾也不是問題，當(dāng)HDFS程序正確的執(zhí)行完升級各步驟后，還需要手工的執(zhí)行
hadoop dfsadmin -upgradeFinallized
讓HDFS刪除升級之前到文件，這個命令執(zhí)行完后，也就不能回滾到以前的HDFS版本了。
以上是“HDFS如何進行升級管理”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
重慶分公司
重慶分公司
