簡介面向IBM DS系列存儲系統(tǒng)運維與實施人員的參考文檔聚焦DS Storage Manager的日常管理與調(diào)試。內(nèi)容圍繞Storage Partition與LUN Masking展開說明如何通過存儲分區(qū)實現(xiàn)主機間LUN隔離避免多主機同時識別同一磁盤造成簽名覆蓋或數(shù)據(jù)互寫并以Linux與Windows主機共享LUN為例提示隔離的必要性同時比較單主機或集群主機分區(qū)與Host Group多主機分配兩種方案的適用取舍覆蓋在線擴容、新增主機、擴展Storage Partition數(shù)量等維護操作。后半部分結(jié)合DS4800講解圖形界面建卷、RAID級別選擇、條帶塊與文件系統(tǒng)設(shè)置、熱備盤配置、HBA卡WWN映射及串口命令行排障思路。壓縮包共1個doc文件約1019KB篇幅集中便于隨查隨用。已有452人學(xué)習(xí)適合需要理解DS4000/DS4800存儲分區(qū)、卷映射與容量擴展的讀者作為操作參考和排錯線索。1. 一條 LUN 被兩臺主機同時看見為什么兩邊都不會報錯Storage Partition 和 LUN Masking 這兩個詞在存儲管理套件的配置界面里通常挨著放很多人點進去掃一眼就退出去了——不就是給主機分個盤嗎。真正的風(fēng)險在于把同一塊 LUN 同時映射給兩臺主機兩邊都不會報錯。操作系統(tǒng)照常枚舉磁盤、照常掛載、照常讀寫日志一片安靜直到某天發(fā)現(xiàn)數(shù)據(jù)被覆蓋成了別人的內(nèi)容或者文件系統(tǒng)直接損壞。這類事故不是“越權(quán)訪問”造成的恰恰是兩次都“合法”的寫入——Windows 看到一塊新磁盤會習(xí)慣性地寫入簽名Linux 上的卷管理器會自作主張打上自己的元數(shù)據(jù)頭誰也沒覺得自己做錯。所以 Storage Partition 不是權(quán)限面板上的一個裝飾開關(guān)它是把“物理上看得見”和“邏輯上可以用”這兩件事切開的那道閘。搞懂這道閘卡在哪一層、為什么只能卡在那一層才談得上會管一臺中端陣列。2. LUN Masking 與 Zoning兩道閘門分別卡在哪一層很多人對隔離的理解停在“劃個 zone 就完事了”這在只連一臺主機的時候完全沒有問題一旦上了雙機、多機就必然出問題。原因不復(fù)雜Zoning 和 Storage Partition 作用在協(xié)議棧的兩個完全不同的高度上一個管鏈路能不能通一個管命令報不報得出來。把它們混為一談等于把防火墻當(dāng)成了文件權(quán)限。2.1 Zoning 卡在光纖交換層解決“能不能看見這臺陣列”主機接進 SAN 之后第一步是向交換機端口發(fā) FLOGI 完成 fabric 登錄拿到一個 FC ID然后才能對目標(biāo)端口發(fā) PLOGI、PRLI建立真正的 SCSI 會話。Zoning 做的事就是在這條路上設(shè)卡只有處在同一個 zone 里的端口或 WWN彼此之間的登錄幀才被交換機轉(zhuǎn)發(fā)不在同一個 zone 里則連 PLOGI 都完不成后面的 SCSI 命令自然無從談起。這個粒度的關(guān)鍵特征是——Zoning 的判定對象是“設(shè)備/端口”不是“LUN”。只要主機和陣列的某個 target 端口在同一個 zone 內(nèi)登錄成功之后主機就能對這個 target 發(fā)REPORT LUNs而交換機不會、也沒能力去檢查返回的 LUN 列表里是不是混進了別人的盤。換句話說Zoning 最多告訴你“這棟樓你能進”進了樓之后哪幾個房間能開它管不著。這也解釋了為什么只做 Zoning 的多主機環(huán)境經(jīng)常出現(xiàn)“我明明只 zone 了 A 主機和陣列怎么 A 還看到了 B 的盤”——因為你看的是 LUN而 zone 看的是端口。2.2 Storage Partition 卡在控制器層解決“能看見這臺陣列的哪些 LUN”真正的 LUN 級判定發(fā)生在陣列控制器內(nèi)部。主機登錄成功后SCSI 層第一步是發(fā)REPORT LUNs問“你身上掛了哪些邏輯單元”控制器這時才拿到主機的身份標(biāo)識在 FC 環(huán)境下就是 HBA 的 WWN去查自己維護的映射表只把登記在這個 WWN 名下的 LUN 返回來。沒登記的 LUN 不會出現(xiàn)在返回結(jié)果里主機側(cè)的 SCSI 中層根本不知道它們存在/dev/sd*也就不會多出對應(yīng)的塊設(shè)備。常見的實現(xiàn)思路大致是這樣一張表以主機 WWN 為鍵以“可見 LUN 編號 → 后端卷”為值Default Group 作為兜底策略處理未登記的主機?？刂破髟诿看蜶EPORT LUNs、INQUIRY、TEST UNIT READY時都過一遍這張表屬于典型的白名單模型——默認拒絕登記才放行。# 控制器側(cè) LUN 可見性判定的示意結(jié)構(gòu)用于說明白名單模型非廠商實現(xiàn) # mapping: {host_wwn: {lun_id: volume_id}}由 Storage Partition 配置生成 def report_luns(host_wwn, mapping, default_group_policy): # WWN 必須先做歸一化大小寫、冒號分隔、前導(dǎo)零都會影響匹配 key normalize_wwn(host_wwn) visible mapping.get(key) if visible is None: # 未登記主機走 Default Group 策略這也是沒買 License 時的唯一歸宿 return default_group_policy() # 只返回該 WWN 名下登記過的 LUN 編號其余卷在主機側(cè)完全不可見 return sorted(visible.keys()) def normalize_wwn(wwn): # 統(tǒng)一成小寫、去掉分隔符50:0a:09:80:00:1a:2b:3c - 500a0980001a2b3c return wwn.replace(:, ).replace(-, ).lower()這段偽代碼里有兩個值得注意的點。第一是歸一化看起來是瑣碎細節(jié)實際是現(xiàn)場最高頻的翻車點之一交換機上抄下來的 WWN 帶冒號、全小寫管理界面里粘貼進去的可能帶大寫或者少一位前導(dǎo)零配置上“看著有”映射就是不生效。第二是兜底分支Default Group 的存在意味著只要有一臺主機沒被劃進任何 Partition它就會落到默認策略里而這個策略通常是“看得見所有沒被別的 Partition 獨占的卷”——這就是隔離形同虛設(shè)的根源。2.3 兩個機制的組合關(guān)系缺一不可但不能互相替代把兩道閘門放在一起看職責(zé)邊界就清楚了。Zoning 決定“哪些主機能跟這臺陣列建立 SCSI 會話”Storage Partition 決定“會話建立之后能看到哪些 LUN”。前者在交換機上配后者在陣列控制器上配配置位置不同、生效層不同、故障表現(xiàn)也不同Zoning 配錯的表現(xiàn)是鏈路起不來、lsscsi里連陣列的 target 都看不到Partition 配錯的表現(xiàn)是鏈路正常、能看到陣列但 LUN 數(shù)量對不上或者多出了不該有的盤。維度Zoning光纖交換機Storage Partition陣列控制器判定對象端口 / WWN主機 WWN 對應(yīng)的 LUN 列表協(xié)議層FC 登錄FLOGI/PLOGISCSI 命令REPORT LUNs隔離粒度設(shè)備級LUN 級配錯后的現(xiàn)象看不到陣列 target看得到陣列LUN 數(shù)量異常典型誤用所有端口劃進一個大 zone全部卷映射給 Default Group注意Zoning 做得再細也不能替代 Storage Partition。一個主機在 zone 內(nèi)、所有卷都在 Default Group 里的環(huán)境隔離度等于零。3. Storage Partition 的兩種劃法Host Group 里放一臺還是放多臺知道了閘門卡在哪一層接下來的問題就是這張白名單表怎么組織。DS 系列的管理套件給了兩種劃法表面看只是“主機放一組還是分開”實際是兩種完全不同的運維模型選錯了不會立刻出事但會在擴容和加節(jié)點的時候一點一點把運維成本還回來。3.1 方案一一個 Host Group 放一臺或一對集群主機這個方案的規(guī)則很干脆一個 Host Group 里放一臺主機或者放兩臺裝了集群軟件、需要共享同一批邏輯盤的主機共享盤分配給 Host Group各自獨占的盤分配給具體 Host。判定順序是“先看 Host 自己的映射再看所屬 Group 的映射”所以同一臺主機既能拿到組內(nèi)共享的卷也能拿到自己獨占的卷。它的價值在雙機場景里體現(xiàn)得最明顯。舉個例子兩臺小型機做 HA 集群共享數(shù)據(jù)盤兩邊都要看見各自的系統(tǒng)盤只想讓自己看見。用方案一共享盤掛到 Host Group 上系統(tǒng)盤分別掛到兩個 Host 上一張映射表就表達完了既不會讓 A 看見 B 的系統(tǒng)盤也不會影響兩邊對共享盤的并發(fā)訪問。擴容時也一樣新加一塊共享盤掛到 Group 上兩臺同時可見新加一塊只給 A 的盤掛到 A 的 Host 上B 完全無感。邏輯層次跟實際的業(yè)務(wù)拓撲是同構(gòu)的后面接手的人看一眼分組名就知道怎么回事。代價是 License 消耗。每個 Storage Partition 對應(yīng)一份授權(quán)方案一是“每臺主機或每對集群主機一份”主機數(shù)量一多賬面上的授權(quán)數(shù)就上去了。3.2 方案二一個 Host Group 放多臺主機邏輯盤直接給 Host省授權(quán)的方式是把多臺主機塞進同一個 Host Group然后把邏輯盤直接分配給每個 Host不經(jīng)過 Group 這一層。因為授權(quán)是按 Partition 算的一個 Partition 里放十臺主機也只算一份。代價是表達能力。這個模型里只有“Host 獨占”這一種關(guān)系沒辦法表達“這兩臺共享、那三臺獨占”的混合需求。如果一組主機里有兩臺需要共享同一塊盤在方案二下把這塊盤同時映射給兩臺 Host從陣列角度看確實兩邊都能看見但這已經(jīng)越過了 Host Group 的語義邊界后面排查“這塊盤到底該歸誰”的時候會很痛苦。所以這個方案通常用在純獨占的小規(guī)模環(huán)境一批互不相干的業(yè)務(wù)主機各自一塊或幾塊盤沒有任何共享需求。3.3 License 與運維成本的取舍為什么建議下單時就買一個常見的后悔藥場景是裝機時沒訂 Storage Partition 授權(quán)所有主機只能落在 Default Group 里于是每臺主機都能看到陣列上所有卷。這時候業(yè)務(wù)還沒上線看起來“也沒出什么事”等到一臺 Windows 主機掃盤時把別人的 LUN 寫了簽名或者兩臺主機同時掛了一塊盤互相覆蓋問題才暴露出來而這時候再補授權(quán)、再重新規(guī)劃分組是要停業(yè)務(wù)窗口的。選型的判斷標(biāo)準(zhǔn)其實很樸素如果環(huán)境里有集群、有共享盤、或者主機數(shù)量會增長就走方案一并且在下單階段把授權(quán)數(shù)量按“主機數(shù)或集群對數(shù)”估足如果是一批完全獨立、永遠不共享的單機業(yè)務(wù)方案二可以省一筆但要接受未來加共享需求時得重新規(guī)劃。這里沒有普適答案只有“你的拓撲會不會變”這個問題的答案。3.4 集群協(xié)調(diào)軟件兩個節(jié)點都能寫同一塊盤之后即使 Storage Partition 把共享盤正確地映射給了兩臺主機也只是解決了“誰能看見”沒有解決“誰能寫”。兩臺主機同時往同一個塊設(shè)備寫如果沒有上層協(xié)調(diào)結(jié)果依然是數(shù)據(jù)互相覆蓋。所以共享卷必須搭配協(xié)調(diào)機制常見的有三類HA 集群軟件用心跳和資源組做互斥同一時刻只有一個節(jié)點掛載并寫入并行文件系統(tǒng)用分布式鎖管理并發(fā)訪問讓多節(jié)點真正同時讀寫同一個文件系統(tǒng)SAN 共享文件系統(tǒng)則用令牌機制協(xié)調(diào)多臺主機對同一批卷的訪問。裸設(shè)備場景下還有并發(fā)卷的概念允許多節(jié)點同時打開同一塊設(shè)備由數(shù)據(jù)庫自己的鎖機制接管一致性。注意映射給 Host Group 的共享卷如果上層沒有集群或并行文件系統(tǒng)等于把兩塊主機的手同時伸進同一個抽屜隔離做得再好也沒用。4. 一條 LUN 從創(chuàng)建到映射圖形界面背后的參數(shù)與順序圖形界面把創(chuàng)建流程串成了一條向?qū)c下一步就行但每一步背后的選擇都會在后期變成性能問題或者容量問題。把向?qū)Р痖_看實際是四件事先在物理盤上切出 RAID 組再在組里切出邏輯盤并定條帶參數(shù)然后留出熱備盤兜底最后通過 WWN 把邏輯盤映射給主機。順序不能亂參數(shù)要想清楚。4.1 磁盤組、RAID 與邏輯盤的創(chuàng)建順序向?qū)У牡谝徊绞荂reate Logical Drive選 RAID 級別然后決定怎么選盤全自動讓控制器自己挑或者切成手工模式逐塊勾選。后者在已有數(shù)據(jù)的陣列上幾乎是必須的——自動選盤不會管你哪些盤已經(jīng)被別的卷占著、哪些盤屬于哪個磁盤組一通自動下去可能把容量切得七零八落。選完盤要點一次Calculate Capacity不點這一步向?qū)Р粫判幸驗榭刂破餍枰人愠鲞@組盤在當(dāng)前 RAID 級別下實際可用的容量再讓你決定切多大的邏輯分區(qū)。分區(qū)大小和命名之后向?qū)柺亲詣釉O(shè)置屬性還是手工設(shè)置建議選手工自動方案是給“不知道自己要什么”的人準(zhǔn)備的而條帶大小、文件系統(tǒng)類型這些參數(shù)一旦定錯改起來往往要重建卷。最后一步是選該分區(qū)將要掛載的操作系統(tǒng)類型這個選擇會影響控制器對該卷的呈現(xiàn)方式選錯的表現(xiàn)不一定是報錯有時候只是主機側(cè)認出來的設(shè)備屬性不對。4.2 條帶塊大小8K 到 256K 對應(yīng)的是什么 IO 模型條帶深度stripe unit從 8K 到 256K 有多檔可選選型的依據(jù)只有一個這塊卷上跑的應(yīng)用IO 長什么樣。數(shù)據(jù)庫類負載是典型的小塊隨機 IO一次寫 7K、8K 很常見。如果條帶設(shè)成 256K一次 7K 的寫落在了一個 256K 的條帶單元里這個單元剩余的空間在這次 IO 中就用不上了等于用大顆粒去裝小數(shù)據(jù)空間利用率和控制器處理效率都不劃算。反過來多媒體、備份歸檔這類順序大 IO 負載一次讀 200MB 的電影文件條帶設(shè)大一些控制器跨盤輪詢的次數(shù)就少預(yù)讀和并行度都能吃滿效率明顯更高。文件系統(tǒng)類型的選擇同理向?qū)Ю镒屵x“數(shù)據(jù)庫 / 多媒體 / 文件系統(tǒng)”本質(zhì)就是在替你預(yù)設(shè)這一組條帶參數(shù)。這里有個容易誤解的點條帶大小不是“塊大小”它不影響單個文件占多少空間影響的是控制器把一個 IO 拆成幾份、落到幾塊盤上。所以判斷標(biāo)準(zhǔn)不是“我的文件平均多大”而是“我的 IO 請求平均多大、是順序還是隨機”。4.3 熱備盤容量為什么必須不小于陣列內(nèi)最大的一塊盤RAID 組做完之后要留熱備盤Hot Spare作用是陣列里某塊盤故障時控制器自動拿熱備盤頂上并開始重建把降級窗口壓到最短。這里有一條硬性限制熱備盤的容量必須大于或等于它所保護的那個陣列里容量最大的盤。原因很直白重建是把故障盤上的數(shù)據(jù)按條帶重新算一遍寫到熱備盤上如果熱備盤比故障盤小物理上就裝不下重建根本沒法開始陣列會一直停在降級狀態(tài)。更隱蔽的情況是熱備盤容量夠大但被劃給了別的磁盤組、或者被指定成了只保護某個特定陣列的專用熱備這時候別的組出故障它不會被自動征用。所以配完熱備盤之后務(wù)必要確認它的保護范圍覆蓋了所有需要兜底的磁盤組。4.4 Mapping ViewWWN 才是主機的身份證卷建好了最后一步是映射。管理套件里的Mapping View是整條鏈路的收口處也是最容易配錯的地方。規(guī)范的做法是先在Mapping View里建 Host Group比如按業(yè)務(wù)命名成Oracle_data這樣的組再在組里建 Host然后給每個 Host 添加 HBA 卡的 WWN。一臺主機有幾塊 HBA、幾個端口就要加幾次因為陣列認的是端口身份不是主機名。加完 Host 之后分配邏輯盤。這一步的界面支持兩種操作把多塊盤分給同一臺主機或者把同一塊盤分給多臺主機后者就是共享場景需要上層集群軟件配合。最后的收尾動作是在Default Group上右鍵選Define Additional Mapping補齊映射關(guān)系。這一步很容易被跳過跳過的后果是前面配的分組沒真正生效主機側(cè)掃出來還是老樣子。主機側(cè)可以用幾條命令確認映射是否真的落地了# 1. 采集 HBA 端口 WWN用于在 Mapping View 里登記主機身份 # 輸出形如 0x500a0980001a2b3c粘貼進管理界面時注意去掉 0x 前綴 cat /sys/class/fc_host/host*/port_name # 2. 觸發(fā) SCSI 總線重掃讓新映射的 LUN 出現(xiàn)在系統(tǒng)里 # 三個 - 分別代表 channel / target / lun全通配表示掃全部 for h in /sys/class/scsi_host/host*/scan; do echo - - - $h; done # 3. 確認多路徑下每塊 LUN 的可見性與聚合情況 # 同一 LUN 的多條路徑應(yīng)聚合成一個 mpath 設(shè)備而不是散成多個 sdX multipath -ll # 4. 查看 SCSI 層實際枚舉到的設(shè)備核對數(shù)量是否與映射一致 lsscsi -gmultipath -ll的輸出值得多看兩眼如果同一塊 LUN 出現(xiàn)了多個獨立的設(shè)備節(jié)點而不是聚合成一個說明多路徑配置有問題如果設(shè)備數(shù)量比映射的多說明有卷落進了 Default Group隔離沒做干凈。Windows 主機側(cè)還有一層額外風(fēng)險需要提前處理。Windows 默認策略會對新發(fā)現(xiàn)的磁盤自動上線并寫入簽名這正是跨主機數(shù)據(jù)損壞的經(jīng)典成因?？梢栽谟成渲跋劝巡呗愿某呻x線# 將新發(fā)現(xiàn)的磁盤一律置為 Offline避免主機對不屬于自己的 LUN 寫入簽名 Set-StorageSetting -NewDiskPolicy OfflineAll # 確認當(dāng)前策略已生效 Get-StorageSetting | Select-Object NewDiskPolicy這條策略配合 Storage Partition 使用才是完整的Partition 保證主機看不到別人的盤離線策略保證即使因為某種原因看到了也不會主動去寫。5. 在線擴容與常見問題排查改分區(qū)為什么不用停業(yè)務(wù)存儲管理里最容易被低估的能力是“在線改”。擴容、加主機、加 Partition這些操作在 DS 系列上都是在線進行的不影響正在跑的業(yè)務(wù)。理解了這個“在線”是怎么來的遇到問題才知道從哪兒查。5.1 三條擴容路徑與“在線”的來源第一條路徑是動態(tài)卷擴容直接把已有 LUN 調(diào)大主機側(cè)重掃之后看到塊設(shè)備變大了再擴分區(qū)和文件系統(tǒng)。第二條路徑是新增 LUN 然后修改該主機的 Storage Partition把新卷加進去——注意這里改的是映射表不是已有卷的屬性。第三條路徑是升級 Storage Partition 的數(shù)量授權(quán)讓原本擠在 Default Group 里的主機能各自獨立成組。三條路徑的在線性來自同一個設(shè)計映射表的變更是“新增條目”或“追加 LUN 編號”不觸碰已經(jīng)生效的條目。已經(jīng)在跑的 IO 走的還是原來那條路徑新加的 LUN 對老會話不可見要靠主機側(cè)重掃或者重新登錄才會出現(xiàn)。所以“在線”不等于“自動生效”陣列側(cè)改完了主機側(cè)還得主動去發(fā)現(xiàn)一次。主機數(shù)量增加時同理新定義一個 Storage Partition 不會影響已定義的任何 Partition。注意在線擴容的前提是文件系統(tǒng)和卷管理器支持在線擴容。塊設(shè)備變大了df不一定跟著變中間那層分區(qū)表和文件系統(tǒng)要單獨擴。5.2 常見問題與排查現(xiàn)象一主機重掃之后看不到新映射的 LUN。原因通常是三選一WWN 填錯了大小寫、冒號、前導(dǎo)零的差異都算錯卷映射到了別的 Host 或 Host Group 上或者主機沒有重新對 fabric 做一次登錄所以控制器那邊還是舊會話。排查順序是先在Mapping View里核對這臺主機名下的 LUN 清單再回主機側(cè)用cat /sys/class/fc_host/host*/port_name拿到真實 WWN 逐字符比對最后確認掃描命令確實寫進了scan文件而不是只 echo 到了終端?，F(xiàn)象二Windows 主機掃到了一塊不屬于它的盤并且自動寫了簽名。原因是這臺主機沒有被劃進獨立的 Storage Partition落到了 Default Group 里而 Default Group 的策略通常是可見所有未被獨占的卷。解決分兩步先按 3.1 的方案給這臺主機單獨建 Host 并補齊映射把它從 Default Group 里摘出來再在主機側(cè)把NewDiskPolicy改成OfflineAll讓自動簽名這件事從源頭上不可能發(fā)生。已經(jīng)寫壞簽名的 LUN只能從備份恢復(fù)或者重建沒有別的辦法?，F(xiàn)象三熱備盤在陣列里顯示正常故障發(fā)生時卻沒有自動頂上。原因包括熱備盤容量小于故障盤、熱備盤被指定成了只保護另一個磁盤組的專用熱備、或者這個磁盤組壓根沒被納入保護范圍。解決方式是在熱備盤的屬性里確認它的保護范圍覆蓋了需要兜底的組并核對容量重建沒起來的時候先看陣列的事件日志里有沒有“insufficient capacity”之類的提示比盲目換盤高效得多。現(xiàn)象四LUN 擴容完成、主機也重掃了文件系統(tǒng)容量沒變。原因是塊設(shè)備變大只發(fā)生在 SCSI 層上面的分區(qū)表和文件系統(tǒng)還是舊尺寸。解決是依次擴分區(qū)growpart之類、擴物理卷、擴邏輯卷、擴文件系統(tǒng)每一步都要確認前一步到位了再走下一步。跳過中間任何一步最后df都不會變。現(xiàn)象五一塊 LUN 在多路徑環(huán)境里散成了多個獨立設(shè)備。原因通常是多路徑軟件沒識別到這塊盤設(shè)備白名單沒加或者同一塊 LUN 通過多條路徑被當(dāng)成了不同設(shè)備。解決是先看multipath -ll里有沒有對應(yīng)的 mpath 條目沒有就把該設(shè)備加進多路徑配置并重新加載而不是急著在裸設(shè)備上直接建文件系統(tǒng)——那樣做等于把一條路的數(shù)據(jù)和另一條路的數(shù)據(jù)割裂開。6. 串口命令行與圖形界面什么時候必須離開鼠標(biāo)圖形界面和串口命令行不是“好用”和“難用”的關(guān)系是兩種失效模式下的互補。管理套件的圖形界面承擔(dān)的是“建?！甭氊?zé)磁盤組、邏輯盤、Host Group、映射關(guān)系這些結(jié)構(gòu)性配置在界面上有可視化呈現(xiàn)配錯的時候能一眼看出拓撲不對這對防止誤操作的價值遠大于敲命令快那么幾秒?，F(xiàn)場絕大多數(shù)日常操作包括建卷、擴容、加主機、改映射走圖形界面都更穩(wěn)。串口那條路的價值在另一個場景管理網(wǎng)口不通、控制器狀態(tài)異常、圖形界面連不上的時候。這時候以太網(wǎng)管理通道默認地址段那種帶外管理口可能整條斷掉圖形界面的自動掃描在網(wǎng)絡(luò)上找不到任何控制器但通過串口登進去用終端工具以命令行方式仍然能拿到控制器的內(nèi)部狀態(tài)、看事件日志、做故障定位。它還能做到界面上沒有的一些擴展查詢信息密度更高代價是沒有圖形提示任何一條命令敲下去都沒有“下一步”按鈕幫你兜底。兩條路的實際分工我一般這么理解圖形界面用來“把結(jié)構(gòu)搭對”串口用來“在結(jié)構(gòu)出問題的時候還能進去看”。這帶來一個容易被忽略的運維要求——串口連接方式、終端參數(shù)、登錄方式這些信息必須在設(shè)備上架階段就記錄進運維文檔而不是等出故障那天再去翻手冊。真到了管理網(wǎng)不通的深夜能不能連上串口決定的不是效率是能不能在業(yè)務(wù)恢復(fù)窗口內(nèi)定位到問題。這里還有個取舍值得說清楚圖形界面之所以“更直觀、更容易掌握”本質(zhì)是它把一堆有依賴關(guān)系的操作編排成了強制順序你不能在沒選 RAID 級別的情況下直接去切分區(qū)也不能在沒加 WWN 的情況下完成映射。這種強制順序既是保護也是限制——它擋住了誤操作也擋住了“我只想查一個狀態(tài)”的輕量操作。串口命令行反過來什么都能干什么都得自己保證順序?qū)Α蛇叾汲赃^虧之后我形成了一個習(xí)慣任何一次涉及映射關(guān)系的變更先在圖形界面里把拓撲配好并截圖存檔變更完成后立刻用主機側(cè)的掃描命令驗證一遍 LUN 數(shù)量和設(shè)備名兩步都過了才算這次變更結(jié)束。這個習(xí)慣救過我很多次——有幾次就是靠變更前后的設(shè)備清單對比發(fā)現(xiàn)某臺主機的卷落進了 Default Group在業(yè)務(wù)感知到之前就糾正了。希望幫到你。本文還有配套的精品資源點擊獲取 Storage Partition與LUN Masking：SAN隔離映射實踐
簡介面向IBM DS系列存儲系統(tǒng)運維與實施人員的參考文檔聚焦DS Storage Manager的日常管理與調(diào)試。內(nèi)容圍繞Storage Partition與LUN Masking展開說明如何通過存儲分區(qū)實現(xiàn)主機間LUN隔離避免多主機同時識別同一磁盤造成簽名覆蓋或數(shù)據(jù)互寫并以Linux與Windows主機共享LUN為例提示隔離的必要性同時比較單主機或集群主機分區(qū)與Host Group多主機分配兩種方案的適用取舍覆蓋在線擴容、新增主機、擴展Storage Partition數(shù)量等維護操作。后半部分結(jié)合DS4800講解圖形界面建卷、RAID級別選擇、條帶塊與文件系統(tǒng)設(shè)置、熱備盤配置、HBA卡WWN映射及串口命令行排障思路。壓縮包共1個doc文件約1019KB篇幅集中便于隨查隨用。已有452人學(xué)習(xí)適合需要理解DS4000/DS4800存儲分區(qū)、卷映射與容量擴展的讀者作為操作參考和排錯線索。1. 一條 LUN 被兩臺主機同時看見為什么兩邊都不會報錯Storage Partition 和 LUN Masking 這兩個詞在存儲管理套件的配置界面里通常挨著放很多人點進去掃一眼就退出去了——不就是給主機分個盤嗎。真正的風(fēng)險在于把同一塊 LUN 同時映射給兩臺主機兩邊都不會報錯。操作系統(tǒng)照常枚舉磁盤、照常掛載、照常讀寫日志一片安靜直到某天發(fā)現(xiàn)數(shù)據(jù)被覆蓋成了別人的內(nèi)容或者文件系統(tǒng)直接損壞。這類事故不是“越權(quán)訪問”造成的恰恰是兩次都“合法”的寫入——Windows 看到一塊新磁盤會習(xí)慣性地寫入簽名Linux 上的卷管理器會自作主張打上自己的元數(shù)據(jù)頭誰也沒覺得自己做錯。所以 Storage Partition 不是權(quán)限面板上的一個裝飾開關(guān)它是把“物理上看得見”和“邏輯上可以用”這兩件事切開的那道閘。搞懂這道閘卡在哪一層、為什么只能卡在那一層才談得上會管一臺中端陣列。2. LUN Masking 與 Zoning兩道閘門分別卡在哪一層很多人對隔離的理解停在“劃個 zone 就完事了”這在只連一臺主機的時候完全沒有問題一旦上了雙機、多機就必然出問題。原因不復(fù)雜Zoning 和 Storage Partition 作用在協(xié)議棧的兩個完全不同的高度上一個管鏈路能不能通一個管命令報不報得出來。把它們混為一談等于把防火墻當(dāng)成了文件權(quán)限。2.1 Zoning 卡在光纖交換層解決“能不能看見這臺陣列”主機接進 SAN 之后第一步是向交換機端口發(fā) FLOGI 完成 fabric 登錄拿到一個 FC ID然后才能對目標(biāo)端口發(fā) PLOGI、PRLI建立真正的 SCSI 會話。Zoning 做的事就是在這條路上設(shè)卡只有處在同一個 zone 里的端口或 WWN彼此之間的登錄幀才被交換機轉(zhuǎn)發(fā)不在同一個 zone 里則連 PLOGI 都完不成后面的 SCSI 命令自然無從談起。這個粒度的關(guān)鍵特征是——Zoning 的判定對象是“設(shè)備/端口”不是“LUN”。只要主機和陣列的某個 target 端口在同一個 zone 內(nèi)登錄成功之后主機就能對這個 target 發(fā)REPORT LUNs而交換機不會、也沒能力去檢查返回的 LUN 列表里是不是混進了別人的盤。換句話說Zoning 最多告訴你“這棟樓你能進”進了樓之后哪幾個房間能開它管不著。這也解釋了為什么只做 Zoning 的多主機環(huán)境經(jīng)常出現(xiàn)“我明明只 zone 了 A 主機和陣列怎么 A 還看到了 B 的盤”——因為你看的是 LUN而 zone 看的是端口。2.2 Storage Partition 卡在控制器層解決“能看見這臺陣列的哪些 LUN”真正的 LUN 級判定發(fā)生在陣列控制器內(nèi)部。主機登錄成功后SCSI 層第一步是發(fā)REPORT LUNs問“你身上掛了哪些邏輯單元”控制器這時才拿到主機的身份標(biāo)識在 FC 環(huán)境下就是 HBA 的 WWN去查自己維護的映射表只把登記在這個 WWN 名下的 LUN 返回來。沒登記的 LUN 不會出現(xiàn)在返回結(jié)果里主機側(cè)的 SCSI 中層根本不知道它們存在/dev/sd*也就不會多出對應(yīng)的塊設(shè)備。常見的實現(xiàn)思路大致是這樣一張表以主機 WWN 為鍵以“可見 LUN 編號 → 后端卷”為值Default Group 作為兜底策略處理未登記的主機?？刂破髟诿看蜶EPORT LUNs、INQUIRY、TEST UNIT READY時都過一遍這張表屬于典型的白名單模型——默認拒絕登記才放行。# 控制器側(cè) LUN 可見性判定的示意結(jié)構(gòu)用于說明白名單模型非廠商實現(xiàn) # mapping: {host_wwn: {lun_id: volume_id}}由 Storage Partition 配置生成 def report_luns(host_wwn, mapping, default_group_policy): # WWN 必須先做歸一化大小寫、冒號分隔、前導(dǎo)零都會影響匹配 key normalize_wwn(host_wwn) visible mapping.get(key) if visible is None: # 未登記主機走 Default Group 策略這也是沒買 License 時的唯一歸宿 return default_group_policy() # 只返回該 WWN 名下登記過的 LUN 編號其余卷在主機側(cè)完全不可見 return sorted(visible.keys()) def normalize_wwn(wwn): # 統(tǒng)一成小寫、去掉分隔符50:0a:09:80:00:1a:2b:3c - 500a0980001a2b3c return wwn.replace(:, ).replace(-, ).lower()這段偽代碼里有兩個值得注意的點。第一是歸一化看起來是瑣碎細節(jié)實際是現(xiàn)場最高頻的翻車點之一交換機上抄下來的 WWN 帶冒號、全小寫管理界面里粘貼進去的可能帶大寫或者少一位前導(dǎo)零配置上“看著有”映射就是不生效。第二是兜底分支Default Group 的存在意味著只要有一臺主機沒被劃進任何 Partition它就會落到默認策略里而這個策略通常是“看得見所有沒被別的 Partition 獨占的卷”——這就是隔離形同虛設(shè)的根源。2.3 兩個機制的組合關(guān)系缺一不可但不能互相替代把兩道閘門放在一起看職責(zé)邊界就清楚了。Zoning 決定“哪些主機能跟這臺陣列建立 SCSI 會話”Storage Partition 決定“會話建立之后能看到哪些 LUN”。前者在交換機上配后者在陣列控制器上配配置位置不同、生效層不同、故障表現(xiàn)也不同Zoning 配錯的表現(xiàn)是鏈路起不來、lsscsi里連陣列的 target 都看不到Partition 配錯的表現(xiàn)是鏈路正常、能看到陣列但 LUN 數(shù)量對不上或者多出了不該有的盤。維度Zoning光纖交換機Storage Partition陣列控制器判定對象端口 / WWN主機 WWN 對應(yīng)的 LUN 列表協(xié)議層FC 登錄FLOGI/PLOGISCSI 命令REPORT LUNs隔離粒度設(shè)備級LUN 級配錯后的現(xiàn)象看不到陣列 target看得到陣列LUN 數(shù)量異常典型誤用所有端口劃進一個大 zone全部卷映射給 Default Group注意Zoning 做得再細也不能替代 Storage Partition。一個主機在 zone 內(nèi)、所有卷都在 Default Group 里的環(huán)境隔離度等于零。3. Storage Partition 的兩種劃法Host Group 里放一臺還是放多臺知道了閘門卡在哪一層接下來的問題就是這張白名單表怎么組織。DS 系列的管理套件給了兩種劃法表面看只是“主機放一組還是分開”實際是兩種完全不同的運維模型選錯了不會立刻出事但會在擴容和加節(jié)點的時候一點一點把運維成本還回來。3.1 方案一一個 Host Group 放一臺或一對集群主機這個方案的規(guī)則很干脆一個 Host Group 里放一臺主機或者放兩臺裝了集群軟件、需要共享同一批邏輯盤的主機共享盤分配給 Host Group各自獨占的盤分配給具體 Host。判定順序是“先看 Host 自己的映射再看所屬 Group 的映射”所以同一臺主機既能拿到組內(nèi)共享的卷也能拿到自己獨占的卷。它的價值在雙機場景里體現(xiàn)得最明顯。舉個例子兩臺小型機做 HA 集群共享數(shù)據(jù)盤兩邊都要看見各自的系統(tǒng)盤只想讓自己看見。用方案一共享盤掛到 Host Group 上系統(tǒng)盤分別掛到兩個 Host 上一張映射表就表達完了既不會讓 A 看見 B 的系統(tǒng)盤也不會影響兩邊對共享盤的并發(fā)訪問。擴容時也一樣新加一塊共享盤掛到 Group 上兩臺同時可見新加一塊只給 A 的盤掛到 A 的 Host 上B 完全無感。邏輯層次跟實際的業(yè)務(wù)拓撲是同構(gòu)的后面接手的人看一眼分組名就知道怎么回事。代價是 License 消耗。每個 Storage Partition 對應(yīng)一份授權(quán)方案一是“每臺主機或每對集群主機一份”主機數(shù)量一多賬面上的授權(quán)數(shù)就上去了。3.2 方案二一個 Host Group 放多臺主機邏輯盤直接給 Host省授權(quán)的方式是把多臺主機塞進同一個 Host Group然后把邏輯盤直接分配給每個 Host不經(jīng)過 Group 這一層。因為授權(quán)是按 Partition 算的一個 Partition 里放十臺主機也只算一份。代價是表達能力。這個模型里只有“Host 獨占”這一種關(guān)系沒辦法表達“這兩臺共享、那三臺獨占”的混合需求。如果一組主機里有兩臺需要共享同一塊盤在方案二下把這塊盤同時映射給兩臺 Host從陣列角度看確實兩邊都能看見但這已經(jīng)越過了 Host Group 的語義邊界后面排查“這塊盤到底該歸誰”的時候會很痛苦。所以這個方案通常用在純獨占的小規(guī)模環(huán)境一批互不相干的業(yè)務(wù)主機各自一塊或幾塊盤沒有任何共享需求。3.3 License 與運維成本的取舍為什么建議下單時就買一個常見的后悔藥場景是裝機時沒訂 Storage Partition 授權(quán)所有主機只能落在 Default Group 里于是每臺主機都能看到陣列上所有卷。這時候業(yè)務(wù)還沒上線看起來“也沒出什么事”等到一臺 Windows 主機掃盤時把別人的 LUN 寫了簽名或者兩臺主機同時掛了一塊盤互相覆蓋問題才暴露出來而這時候再補授權(quán)、再重新規(guī)劃分組是要停業(yè)務(wù)窗口的。選型的判斷標(biāo)準(zhǔn)其實很樸素如果環(huán)境里有集群、有共享盤、或者主機數(shù)量會增長就走方案一并且在下單階段把授權(quán)數(shù)量按“主機數(shù)或集群對數(shù)”估足如果是一批完全獨立、永遠不共享的單機業(yè)務(wù)方案二可以省一筆但要接受未來加共享需求時得重新規(guī)劃。這里沒有普適答案只有“你的拓撲會不會變”這個問題的答案。3.4 集群協(xié)調(diào)軟件兩個節(jié)點都能寫同一塊盤之后即使 Storage Partition 把共享盤正確地映射給了兩臺主機也只是解決了“誰能看見”沒有解決“誰能寫”。兩臺主機同時往同一個塊設(shè)備寫如果沒有上層協(xié)調(diào)結(jié)果依然是數(shù)據(jù)互相覆蓋。所以共享卷必須搭配協(xié)調(diào)機制常見的有三類HA 集群軟件用心跳和資源組做互斥同一時刻只有一個節(jié)點掛載并寫入并行文件系統(tǒng)用分布式鎖管理并發(fā)訪問讓多節(jié)點真正同時讀寫同一個文件系統(tǒng)SAN 共享文件系統(tǒng)則用令牌機制協(xié)調(diào)多臺主機對同一批卷的訪問。裸設(shè)備場景下還有并發(fā)卷的概念允許多節(jié)點同時打開同一塊設(shè)備由數(shù)據(jù)庫自己的鎖機制接管一致性。注意映射給 Host Group 的共享卷如果上層沒有集群或并行文件系統(tǒng)等于把兩塊主機的手同時伸進同一個抽屜隔離做得再好也沒用。4. 一條 LUN 從創(chuàng)建到映射圖形界面背后的參數(shù)與順序圖形界面把創(chuàng)建流程串成了一條向?qū)c下一步就行但每一步背后的選擇都會在后期變成性能問題或者容量問題。把向?qū)Р痖_看實際是四件事先在物理盤上切出 RAID 組再在組里切出邏輯盤并定條帶參數(shù)然后留出熱備盤兜底最后通過 WWN 把邏輯盤映射給主機。順序不能亂參數(shù)要想清楚。4.1 磁盤組、RAID 與邏輯盤的創(chuàng)建順序向?qū)У牡谝徊绞荂reate Logical Drive選 RAID 級別然后決定怎么選盤全自動讓控制器自己挑或者切成手工模式逐塊勾選。后者在已有數(shù)據(jù)的陣列上幾乎是必須的——自動選盤不會管你哪些盤已經(jīng)被別的卷占著、哪些盤屬于哪個磁盤組一通自動下去可能把容量切得七零八落。選完盤要點一次Calculate Capacity不點這一步向?qū)Р粫判幸驗榭刂破餍枰人愠鲞@組盤在當(dāng)前 RAID 級別下實際可用的容量再讓你決定切多大的邏輯分區(qū)。分區(qū)大小和命名之后向?qū)柺亲詣釉O(shè)置屬性還是手工設(shè)置建議選手工自動方案是給“不知道自己要什么”的人準(zhǔn)備的而條帶大小、文件系統(tǒng)類型這些參數(shù)一旦定錯改起來往往要重建卷。最后一步是選該分區(qū)將要掛載的操作系統(tǒng)類型這個選擇會影響控制器對該卷的呈現(xiàn)方式選錯的表現(xiàn)不一定是報錯有時候只是主機側(cè)認出來的設(shè)備屬性不對。4.2 條帶塊大小8K 到 256K 對應(yīng)的是什么 IO 模型條帶深度stripe unit從 8K 到 256K 有多檔可選選型的依據(jù)只有一個這塊卷上跑的應(yīng)用IO 長什么樣。數(shù)據(jù)庫類負載是典型的小塊隨機 IO一次寫 7K、8K 很常見。如果條帶設(shè)成 256K一次 7K 的寫落在了一個 256K 的條帶單元里這個單元剩余的空間在這次 IO 中就用不上了等于用大顆粒去裝小數(shù)據(jù)空間利用率和控制器處理效率都不劃算。反過來多媒體、備份歸檔這類順序大 IO 負載一次讀 200MB 的電影文件條帶設(shè)大一些控制器跨盤輪詢的次數(shù)就少預(yù)讀和并行度都能吃滿效率明顯更高。文件系統(tǒng)類型的選擇同理向?qū)Ю镒屵x“數(shù)據(jù)庫 / 多媒體 / 文件系統(tǒng)”本質(zhì)就是在替你預(yù)設(shè)這一組條帶參數(shù)。這里有個容易誤解的點條帶大小不是“塊大小”它不影響單個文件占多少空間影響的是控制器把一個 IO 拆成幾份、落到幾塊盤上。所以判斷標(biāo)準(zhǔn)不是“我的文件平均多大”而是“我的 IO 請求平均多大、是順序還是隨機”。4.3 熱備盤容量為什么必須不小于陣列內(nèi)最大的一塊盤RAID 組做完之后要留熱備盤Hot Spare作用是陣列里某塊盤故障時控制器自動拿熱備盤頂上并開始重建把降級窗口壓到最短。這里有一條硬性限制熱備盤的容量必須大于或等于它所保護的那個陣列里容量最大的盤。原因很直白重建是把故障盤上的數(shù)據(jù)按條帶重新算一遍寫到熱備盤上如果熱備盤比故障盤小物理上就裝不下重建根本沒法開始陣列會一直停在降級狀態(tài)。更隱蔽的情況是熱備盤容量夠大但被劃給了別的磁盤組、或者被指定成了只保護某個特定陣列的專用熱備這時候別的組出故障它不會被自動征用。所以配完熱備盤之后務(wù)必要確認它的保護范圍覆蓋了所有需要兜底的磁盤組。4.4 Mapping ViewWWN 才是主機的身份證卷建好了最后一步是映射。管理套件里的Mapping View是整條鏈路的收口處也是最容易配錯的地方。規(guī)范的做法是先在Mapping View里建 Host Group比如按業(yè)務(wù)命名成Oracle_data這樣的組再在組里建 Host然后給每個 Host 添加 HBA 卡的 WWN。一臺主機有幾塊 HBA、幾個端口就要加幾次因為陣列認的是端口身份不是主機名。加完 Host 之后分配邏輯盤。這一步的界面支持兩種操作把多塊盤分給同一臺主機或者把同一塊盤分給多臺主機后者就是共享場景需要上層集群軟件配合。最后的收尾動作是在Default Group上右鍵選Define Additional Mapping補齊映射關(guān)系。這一步很容易被跳過跳過的后果是前面配的分組沒真正生效主機側(cè)掃出來還是老樣子。主機側(cè)可以用幾條命令確認映射是否真的落地了# 1. 采集 HBA 端口 WWN用于在 Mapping View 里登記主機身份 # 輸出形如 0x500a0980001a2b3c粘貼進管理界面時注意去掉 0x 前綴 cat /sys/class/fc_host/host*/port_name # 2. 觸發(fā) SCSI 總線重掃讓新映射的 LUN 出現(xiàn)在系統(tǒng)里 # 三個 - 分別代表 channel / target / lun全通配表示掃全部 for h in /sys/class/scsi_host/host*/scan; do echo - - - $h; done # 3. 確認多路徑下每塊 LUN 的可見性與聚合情況 # 同一 LUN 的多條路徑應(yīng)聚合成一個 mpath 設(shè)備而不是散成多個 sdX multipath -ll # 4. 查看 SCSI 層實際枚舉到的設(shè)備核對數(shù)量是否與映射一致 lsscsi -gmultipath -ll的輸出值得多看兩眼如果同一塊 LUN 出現(xiàn)了多個獨立的設(shè)備節(jié)點而不是聚合成一個說明多路徑配置有問題如果設(shè)備數(shù)量比映射的多說明有卷落進了 Default Group隔離沒做干凈。Windows 主機側(cè)還有一層額外風(fēng)險需要提前處理。Windows 默認策略會對新發(fā)現(xiàn)的磁盤自動上線并寫入簽名這正是跨主機數(shù)據(jù)損壞的經(jīng)典成因?？梢栽谟成渲跋劝巡呗愿某呻x線# 將新發(fā)現(xiàn)的磁盤一律置為 Offline避免主機對不屬于自己的 LUN 寫入簽名 Set-StorageSetting -NewDiskPolicy OfflineAll # 確認當(dāng)前策略已生效 Get-StorageSetting | Select-Object NewDiskPolicy這條策略配合 Storage Partition 使用才是完整的Partition 保證主機看不到別人的盤離線策略保證即使因為某種原因看到了也不會主動去寫。5. 在線擴容與常見問題排查改分區(qū)為什么不用停業(yè)務(wù)存儲管理里最容易被低估的能力是“在線改”。擴容、加主機、加 Partition這些操作在 DS 系列上都是在線進行的不影響正在跑的業(yè)務(wù)。理解了這個“在線”是怎么來的遇到問題才知道從哪兒查。5.1 三條擴容路徑與“在線”的來源第一條路徑是動態(tài)卷擴容直接把已有 LUN 調(diào)大主機側(cè)重掃之后看到塊設(shè)備變大了再擴分區(qū)和文件系統(tǒng)。第二條路徑是新增 LUN 然后修改該主機的 Storage Partition把新卷加進去——注意這里改的是映射表不是已有卷的屬性。第三條路徑是升級 Storage Partition 的數(shù)量授權(quán)讓原本擠在 Default Group 里的主機能各自獨立成組。三條路徑的在線性來自同一個設(shè)計映射表的變更是“新增條目”或“追加 LUN 編號”不觸碰已經(jīng)生效的條目。已經(jīng)在跑的 IO 走的還是原來那條路徑新加的 LUN 對老會話不可見要靠主機側(cè)重掃或者重新登錄才會出現(xiàn)。所以“在線”不等于“自動生效”陣列側(cè)改完了主機側(cè)還得主動去發(fā)現(xiàn)一次。主機數(shù)量增加時同理新定義一個 Storage Partition 不會影響已定義的任何 Partition。注意在線擴容的前提是文件系統(tǒng)和卷管理器支持在線擴容。塊設(shè)備變大了df不一定跟著變中間那層分區(qū)表和文件系統(tǒng)要單獨擴。5.2 常見問題與排查現(xiàn)象一主機重掃之后看不到新映射的 LUN。原因通常是三選一WWN 填錯了大小寫、冒號、前導(dǎo)零的差異都算錯卷映射到了別的 Host 或 Host Group 上或者主機沒有重新對 fabric 做一次登錄所以控制器那邊還是舊會話。排查順序是先在Mapping View里核對這臺主機名下的 LUN 清單再回主機側(cè)用cat /sys/class/fc_host/host*/port_name拿到真實 WWN 逐字符比對最后確認掃描命令確實寫進了scan文件而不是只 echo 到了終端?，F(xiàn)象二Windows 主機掃到了一塊不屬于它的盤并且自動寫了簽名。原因是這臺主機沒有被劃進獨立的 Storage Partition落到了 Default Group 里而 Default Group 的策略通常是可見所有未被獨占的卷。解決分兩步先按 3.1 的方案給這臺主機單獨建 Host 并補齊映射把它從 Default Group 里摘出來再在主機側(cè)把NewDiskPolicy改成OfflineAll讓自動簽名這件事從源頭上不可能發(fā)生。已經(jīng)寫壞簽名的 LUN只能從備份恢復(fù)或者重建沒有別的辦法?，F(xiàn)象三熱備盤在陣列里顯示正常故障發(fā)生時卻沒有自動頂上。原因包括熱備盤容量小于故障盤、熱備盤被指定成了只保護另一個磁盤組的專用熱備、或者這個磁盤組壓根沒被納入保護范圍。解決方式是在熱備盤的屬性里確認它的保護范圍覆蓋了需要兜底的組并核對容量重建沒起來的時候先看陣列的事件日志里有沒有“insufficient capacity”之類的提示比盲目換盤高效得多。現(xiàn)象四LUN 擴容完成、主機也重掃了文件系統(tǒng)容量沒變。原因是塊設(shè)備變大只發(fā)生在 SCSI 層上面的分區(qū)表和文件系統(tǒng)還是舊尺寸。解決是依次擴分區(qū)growpart之類、擴物理卷、擴邏輯卷、擴文件系統(tǒng)每一步都要確認前一步到位了再走下一步。跳過中間任何一步最后df都不會變。現(xiàn)象五一塊 LUN 在多路徑環(huán)境里散成了多個獨立設(shè)備。原因通常是多路徑軟件沒識別到這塊盤設(shè)備白名單沒加或者同一塊 LUN 通過多條路徑被當(dāng)成了不同設(shè)備。解決是先看multipath -ll里有沒有對應(yīng)的 mpath 條目沒有就把該設(shè)備加進多路徑配置并重新加載而不是急著在裸設(shè)備上直接建文件系統(tǒng)——那樣做等于把一條路的數(shù)據(jù)和另一條路的數(shù)據(jù)割裂開。6. 串口命令行與圖形界面什么時候必須離開鼠標(biāo)圖形界面和串口命令行不是“好用”和“難用”的關(guān)系是兩種失效模式下的互補。管理套件的圖形界面承擔(dān)的是“建?！甭氊?zé)磁盤組、邏輯盤、Host Group、映射關(guān)系這些結(jié)構(gòu)性配置在界面上有可視化呈現(xiàn)配錯的時候能一眼看出拓撲不對這對防止誤操作的價值遠大于敲命令快那么幾秒?，F(xiàn)場絕大多數(shù)日常操作包括建卷、擴容、加主機、改映射走圖形界面都更穩(wěn)。串口那條路的價值在另一個場景管理網(wǎng)口不通、控制器狀態(tài)異常、圖形界面連不上的時候。這時候以太網(wǎng)管理通道默認地址段那種帶外管理口可能整條斷掉圖形界面的自動掃描在網(wǎng)絡(luò)上找不到任何控制器但通過串口登進去用終端工具以命令行方式仍然能拿到控制器的內(nèi)部狀態(tài)、看事件日志、做故障定位。它還能做到界面上沒有的一些擴展查詢信息密度更高代價是沒有圖形提示任何一條命令敲下去都沒有“下一步”按鈕幫你兜底。兩條路的實際分工我一般這么理解圖形界面用來“把結(jié)構(gòu)搭對”串口用來“在結(jié)構(gòu)出問題的時候還能進去看”。這帶來一個容易被忽略的運維要求——串口連接方式、終端參數(shù)、登錄方式這些信息必須在設(shè)備上架階段就記錄進運維文檔而不是等出故障那天再去翻手冊。真到了管理網(wǎng)不通的深夜能不能連上串口決定的不是效率是能不能在業(yè)務(wù)恢復(fù)窗口內(nèi)定位到問題。這里還有個取舍值得說清楚圖形界面之所以“更直觀、更容易掌握”本質(zhì)是它把一堆有依賴關(guān)系的操作編排成了強制順序你不能在沒選 RAID 級別的情況下直接去切分區(qū)也不能在沒加 WWN 的情況下完成映射。這種強制順序既是保護也是限制——它擋住了誤操作也擋住了“我只想查一個狀態(tài)”的輕量操作。串口命令行反過來什么都能干什么都得自己保證順序?qū)Α蛇叾汲赃^虧之后我形成了一個習(xí)慣任何一次涉及映射關(guān)系的變更先在圖形界面里把拓撲配好并截圖存檔變更完成后立刻用主機側(cè)的掃描命令驗證一遍 LUN 數(shù)量和設(shè)備名兩步都過了才算這次變更結(jié)束。這個習(xí)慣救過我很多次——有幾次就是靠變更前后的設(shè)備清單對比發(fā)現(xiàn)某臺主機的卷落進了 Default Group在業(yè)務(wù)感知到之前就糾正了。希望幫到你。本文還有配套的精品資源點擊獲取