磁帶庫分區(qū)

所謂磁帶庫分區(qū)就是將磁帶庫中的磁帶驅(qū)動器和插槽分配給不同的平臺,這些驅(qū)動器及插槽只能被分配的主機使用.但機械臂可以控制所有的驅(qū)動器及插槽,并被所有的主機控制.控制順序遵循先來先控制的原則.磁帶庫分區(qū)的前提條件是此磁帶機是多通道結(jié)構(gòu)。

來自社區(qū)會員分享案例 5 則，均是磁帶庫日常運維中的典型故障。

在STK L180磁帶庫上爬過的坑

故事發(fā)生在幾年前，在更換機房的一組光纖交換機的實施過程中，原光纖交換機因使用超限，決定將其更換為博科DS5100。交換機下聯(lián)設(shè)備有存儲、小型機、磁帶庫。光纖交換機使用端口zone，并反復確認了zone配置信息。切換當天，按照計劃順利實施。驗證小型機和存儲鏈路均正常。但業(yè)務(wù)驗證時發(fā)現(xiàn)，NBU備份軟件中，手動執(zhí)行備份任務(wù)，有部分失敗。

故障現(xiàn)象：

查看NBU備份軟件中日志，關(guān)于執(zhí)行備份任務(wù)的報錯，發(fā)現(xiàn)在STK L180磁帶庫上執(zhí)行的備份任務(wù)均失敗。

檢查過程：

首先，查看光纖鏈路標簽，確認實施前后一致。接著，確認DS5100光纖交換機與L180磁帶庫的端口和ZONE劃分也配置正確。然后，詳細分析了交換機log信息，發(fā)現(xiàn)連接磁帶機光纖卡的兩個端口，只有FX流，沒有RX數(shù)據(jù)流。

根據(jù)，以上故障現(xiàn)象及檢查方式，基本上先排除光纖交換機和光纖鏈路的問題。問題聚焦在STK L180磁帶庫上。因平時很少出現(xiàn)問題，面對這臺老古董，確實無從下手。

L180磁帶庫有3塊光纖卡，其中一塊為機械臂的光纖卡，另兩塊為磁帶機的光纖卡。重新手動發(fā)起備份任務(wù)，觀察老古董的工作，發(fā)現(xiàn)其機械臂可將磁帶抓入磁帶機，但兩個磁帶機均無法進行正常讀寫。備份任務(wù)無法正常執(zhí)行。初步懷疑是兩臺磁帶機的光纖卡有問題，可是磁帶機上的光纖卡上連指示燈都沒有，繼續(xù)崩潰中。。。

硬著頭皮在L180磁帶機的面板中翻看信息，狀態(tài)顯示都正常無報錯信息。繼續(xù)仔細檢查，發(fā)現(xiàn)兩個磁帶機的光纖卡速率speed僅為1 GBIT。 顯示信息：speed : 1GBIT

1GBIT？會不會是跟新更換光纖交換機的端口速率不匹配呢？可是怎么修改磁帶庫的光纖卡速率呢？在面板上把所有選項翻個遍，根本沒有更改端口速率的選項。心想，先不在這臺老古董上浪費時間吧，去光纖交換機上改下吧。

緊接著登錄到DS5100光纖交換機上，查看磁帶機連接的端口模式為自適應，會不會是無法自適應1GBIT呢？決定將光纖交換機的該端口速率強制為1GBIT，修改后，重新執(zhí)行備份任務(wù)，老古董的機械臂將磁帶抓入磁帶機中，然后就沒有聲音了。。。還是之前的故障現(xiàn)象。。。

馬上跟光纖交換機廠商工程師確認，該型號交換機端口雖然可以強制1 GBIT，但硬件只能支持2 GBIT和4 GBIT以上。

看來，只能寄希望于修改這臺老古董身上了，翻出已經(jīng)落了灰的產(chǎn)品手冊，看了2個多小時，終于發(fā)現(xiàn)了線索，L180磁帶庫在前面板上沒有配置選項可以直接更改磁帶機的光纖卡速率，只能通過修改LOOP ID值。LOOP ID 值為80，磁帶機光纖卡速率為1 GBIT。Loop ID值 為126，磁帶機光纖卡變?yōu)樽赃m應。放下產(chǎn)品手冊，趕緊跑到面板前，找到Loop ID的修改位置，將ID值改為126，磁帶機的光纖卡速率變?yōu)樽赃m應， 顯示信息：speed : auto。

重新再NBU中發(fā)起備份任務(wù)，磁帶機終于轉(zhuǎn)動了。

（社區(qū)會員qq373793057分享）

AIX 7.1環(huán)境NBU備份Oracle rac數(shù)據(jù)庫，磁帶庫驅(qū)動器故障導致備份失敗案例

故障現(xiàn)象：

AIX 7.1環(huán)境下 NBU 備份oracle rac數(shù)據(jù)庫時，磁帶庫驅(qū)動器故障導致備份失敗。

報錯提示為 driver load tape error。

故障原因：

根據(jù)報錯信息定位由于帶庫驅(qū)動器無法正常裝載磁帶導致備份失敗，通過WEB登錄帶庫管理界面查看驅(qū)動器狀態(tài)，發(fā)現(xiàn)帶庫驅(qū)動器offline狀態(tài)?？梢耘袛鄮祢?qū)動器故障，同時log顯示有驅(qū)動器error信息，確認驅(qū)動器故障后，在nbu Device Monitor界面禁用故障的驅(qū)動器，防止備份作業(yè)再次調(diào)起故障的驅(qū)動器，同時將驅(qū)動器里的磁帶手工彈出，此時聯(lián)系廠家更換驅(qū)動器，更換完成后再NBU上啟用驅(qū)動器，進行作業(yè)備份，測試驅(qū)動器工作正常。

更換驅(qū)動器后備份恢復正常。

（社區(qū)會員qb306分享）

昆騰QUANTUM i40 物理帶庫備份失敗案例

帶庫描述：QUANTUM i40 –HP LTO4 tape drive-head

故障現(xiàn)象：

win2003+NBU+昆騰i40物理帶庫，突然無法備份，系統(tǒng)能識別到帶庫驅(qū)動器，NBU軟件也正常識別到磁帶，但是無法備份。

檢查過程：

1、將帶庫下架，拆除頂板，進行帶庫抓取，拿出，清洗，驅(qū)動器、機械臂、磁帶物理狀態(tài)檢查，正常！

2、帶庫-SAN交換機-服務(wù)器，之間的鏈路狀態(tài)檢測，端口替換，光纖模塊替換檢查，正常！

3、NBU重新配置，驅(qū)動重打，還是無法備份。

最后聯(lián)系昆騰原廠，現(xiàn)場診斷，原廠說可能是驅(qū)動器磁頭磨損，帶庫管理界面無任何報錯，最后將驅(qū)動器寄回原廠更換磁頭，恢復正常?。。?！

（社區(qū)會員ACDante分享）

TSM+昆騰磁帶庫的小案例

TSM6.3.4 +昆騰i500 環(huán)境。

故障現(xiàn)象：

由于帶庫使用昆騰i500，不屬于ibm的嫡系部隊，所以只能使用tsm 自動驅(qū)動程序進行驅(qū)動，開始的時候一直使用沒有問題，直到有一天，其中的兩個個驅(qū)動器讀寫報錯，后來檢查確認是磁帶的問題，拿掉故障磁帶后就好了，這時使用tsmdlst

重新使用識別掃描不好使，重啟os和帶庫均不好使。

后來來個干脆的：

TSM服務(wù)器關(guān)閉，帶庫斷電 10分鐘，重新啟動帶庫，服務(wù)器驗證。

正常了。

再不行，我就準備殺招了（刪除drive，path的定義）

這個問題啊，有可能還是tsm和帶庫版本兼容不太好的一面吧。

（社區(qū)會員董志衛(wèi)分享）

TS3200卡帶故障解決案例

機器：TS3200

管理系統(tǒng)：TSM

報錯如下：

連接磁帶庫管理口狀態(tài)如下：

控制器狀態(tài)：

控制器1報錯，顯示超時查看磁帶倉庫分配狀態(tài)：

從圖中看出：控制器正在讀寫11倉磁帶“W00007L5，且該磁帶出現(xiàn)故障，原因應該為損壞磁帶引起控制器卡帶。

界面進行移動磁帶，重新分配磁帶，損壞磁帶無法轉(zhuǎn)入I/O倉

解決：

斷電拆開控制器：

卡帶

拔出損壞磁帶后安裝回控制器

重新上電，初始化需要時間

拔除損壞磁帶后進行備份

2016-10-10-09.48.53

ANR0944E

QUERY PROCESS：找不到活動的進程。 (會話: 21)

2016-10-10-09.52.29

ANR2034E

QUERY EVENT：使用此條件時找不到匹配的項。 (會話: 23)

2016-10-10-09.52.29

ANR2034E

QUERY EVENT：使用此條件時找不到匹配的項。 (會話: 23)

2016-10-10-10.00.12

ANR2034E

SELECT：使用此條件時找不到匹配的項。 (會話: 21)

2016-10-10-10.00.13

ANR0944E

QUERY PROCESS：找不到活動的進程。 (會話: 21)

2016-10-10-10.09.43

ANR7808W

Sun Microsystems 庫連接模塊 libacs.dll 在該系統(tǒng)上不可用。

2016-10-10-10.09.45

ANR8470W

庫 LB0.1.0.4 中驅(qū)動器 MT0.0.0.4 初試化錯誤。

2016-10-10-10.09.45

ANR8470W

庫 LB0.1.0.4 中驅(qū)動器 MT1.0.0.4 初試化錯誤。

2016-10-10-10.10.00

ANR1414W

由于以前的寫錯誤，卷 W00041L5 的訪問方式是“只讀的”。

2016-10-10-10.10.00

ANR1412W

卷 W00014L5 的訪問方式是“unavailable”。

2016-10-10-10.10.00

ANR1412W

卷 892AABL5 的訪問方式是“unavailable”。

2016-10-10-10.10.00

ANR1412W

卷 W00043L5 的訪問方式是“unavailable”。

2016-10-10-10.10.00

ANR1412W

卷 W00009L5 的訪問方式是“unavailable”。

2016-10-10-10.12.29

ANR0535W

節(jié)點 ORA_PRD（TDP Oracle AIX）的會話 1 的事務(wù)已失敗 － 沒有足夠的安裝點可用，不能滿足請求。 (會話: 1)

2016-10-10-10.12.47

ANE4994S

TDP Oracle AIX ANU0599 TDP for Oracle: (25297138): =>(ora_prd) ANU2602E The object /adsmorc//arch_PRD_924861811_35538_1_20161010 was not found on the TSM Server (會話: 2)

2016-10-10-10.20.12

ANR2034E

SELECT：使用此條件時找不到匹配的項。 (會話: 4)

2016-10-10-10.20.14

ANR0944E

QUERY PROCESS：找不到活動的進程。 (會話: 4)

2016-10-10-10.20.26

ANR2034E

SELECT：使用此條件時找不到匹配的項。 (會話: 4)

2016-10-10-10.20.27

ANR0944E

QUERY PROCESS：找不到活動的進程。 (會話: 4)

顯示失敗

原因為拔插控制器之后，TSM無法直接online起控制器需要進入命令行手工執(zhí)行命令online起

命令：q drvie 查看庫轉(zhuǎn)臺

q path 路徑狀態(tài)

q libary

online起驅(qū)動器：update path tsmserver server1 srctype=server desttype=drive library=LB0.1.0.4 device=MT0.0.0.4 online=yes

最后TSM備份成功

（社區(qū)會員Diness分享）

近日，工作流存儲、歸檔和數(shù)據(jù)保護領(lǐng)域企業(yè)美國昆騰公司推出的Scalar平臺為存儲和管理大量的非機構(gòu)化數(shù)據(jù)進行了優(yōu)化，基于該平臺的首批新產(chǎn)品包括Scalar i6和Scalar i3磁帶庫和StorNext AEL6歸檔設(shè)備。

據(jù)了解，Scalar存儲平臺提供比前一代機架式磁帶庫高一倍的同類最佳存儲密度，從而讓各種規(guī)模的企業(yè)機構(gòu)都能降低自身的數(shù)據(jù)中心占地面積，并進一步降低存儲成本。昆騰公司產(chǎn)品與解決方案營銷高級副總裁Geoff Stedman表示：“磁帶長期以來一直是備份的代名詞，但是未來它將成為高效非架構(gòu)化數(shù)據(jù)存儲的支持因素，基于云的冷存儲、視頻制作、視頻監(jiān)控和無人駕駛汽車設(shè)計等都非常適合磁帶。”

基于Scalar平臺的磁帶產(chǎn)品是針對三種不同的環(huán)境而設(shè)計的：Scalar i3適合中小型企業(yè)，在近12U的機架空間內(nèi)提供3PB的存儲。Scalar i6主要是面向要求極為苛刻的工作流程和企業(yè)環(huán)境，在一個48U機架內(nèi)擴展到12PB。StorNext AEL6則適合于海量數(shù)據(jù)歸檔，全新的StorNext AEL6把Scalar i6磁帶庫與昆騰StorNext數(shù)據(jù)管理軟件整合到一起，從而增強針對媒體工作流程的StorNext AEL專用歸檔存儲設(shè)備產(chǎn)品線。