Иванов Иван Ивановитч. Hpe Storeever Msl2024/4048/6480 Tape Library troubleshooting and Veeam backup and replication и veritas netbackup

Траблшутинг ленточной библиотеки HPE StoreEver MSL2024/4048/6480 LTO-6/ LTO-7 при работе с Veeam backup and replication и veritas netbackup - уроки и выводы.

Все вышесказанное усугублялось отвратительной организацией.

20 лет Первой чеченской войне: часть II.

Morituri: идущие на смерть

Евгений Норин для спецпроекта,

посвященного 20-летию начала Первой чеченской войны

tl/dr - драйвера и прошивки, как обычно.

HPE StoreEver MSL2024/4048/6480 Tape Library troubleshooting and Veeam backup and replication и veritas netbackup - lessons and conclusions

All of the above was exacerbated by the disgusting organization

20 years of the First Chechen War: Part II.

Morituri: going to death

Yevgeny Norin for a special project,

dedicated to the 20th anniversary of the beginning of the First Chechen War

tl/dr -drivers and firmware.

Начало пути

Пару месяцев назад пришла задача - в тестовом сегменте перестроить ленточную библиотеку, HPE StoreEver MSL 4048, ранее работавшую с Veeam, для работы с Veritas Netbackup.

Решение о переходе было принято в связи с окончанием тестовой лицензии на Veeam. Можно было продлить еще на месяц, но ряд вопросов работы с Veeam так и остался не отвеченным, в частности корректная работа с MS Exchange DAG

https://www.veeam.com/blog/how-to-backup-exchange-database-availability-groups-dags-with-veeam-backup-replication.html

и нормальная работа (а не пинками костылей из командной строки) с раздельным расписанием для папок на MS file storage cluster, что подразумевает агентов и RDM, с последующим раздельным расположением архивов по репозиториям.

На Veritas Netbackup лицензия была, купленная на деревенской распродаже у цыган.

Сегмент конечно тестовый, но все же там была и не только наша тестовая инфраструктура,

поэтому суетиться было надо осторожно. Не только наша инфраструктура - там стояла общая СХД HPE MSA 2000 (или 1040, не помню), данные на которой портить было нежелательно.

Конфигурация сети на начало всего процесса.

Один физический сервер HPE, для роли media/proxy. На сервере стоит FC HBA HPE (на чипе Qlogic), который торчит двумя проводами в две SAN switch HPE (на самом деле Brocade).

Примечание: две SAN switch потому, что учить работе с фабриками людей тоже приходится.

В другие две порта двух фабрик смотрит своими двумя портами HPE LTO6 Drive. Этот драйв, в свою очередь, стоит в библиотеке типа MSL G3 4048. Ситуация не особо изменится для любой другой библиотеки, из перечисленных выше.

На сервере MS Server 2016. Все патчи стоят.

Второй физический сервер исполняет роль хоста виртуализации, но там ничего не происходит.

Veeam стоял в своей штатной конфигурации - управляющий сервер отдельно, прокси (или медиа- в терминах Netbackup) отдельно. На прокси был развернут сервис Tape, который данные как-то писал. Скорость .. какую-то давал, в пределах "до терабайта и до 12 часов" это было не критично.

После установки на этот сервер Netbackup как media сервера - библиотека перестала писать вообще. Вот совсем. Задача стартует, и не происходит ничего.

Вернее, ну как ничего? Согласно web-консоли библиотеки - кассета переезжала в драйв, и там вставала в Idle.

Все это усугублялось следующими причинами.

1. Netbackup (а не backup exec) я первый раз увидел примерно тогда же.

2. Все оборудование стояло не в соседнем кабинете, а в условно соседнем здании. Очень условно соседнем я бы сказал - пара станций на метро, провайдерская оптика от здания до здания. Так вышло, что инженерный центр в нашей организации отдельно, а мы отдельно, и тестовый сегмент именно в инженерном центре.

3. Запасного оборудования не было вообще.

4. Хоть это и тестовый сегмент, но настроено там было всякого и терять это не хотелось. В том числе там отрабатывался всякий SAN, так что парочка LUN (тоже от HP MSA 2000 кстати. Хотя может уже и 1040) была презентована.

5. Все это было "ну надо да, но не так чтоб прям все бросили, но не сломать".

Ошибки

Прочитали? Ошибки в конфигурации увидели?

Не увидели? А они есть.

Ошибки, как показала практика, не совсем что ппц-ппц, но все же.

Сначала ошибки конфигурации.

С физической конфигурацией сервера все более-менее правильно. Надо только помнить, почему так. А так (необходим физический сервер для работы с ленточной библиотекой) потому, что Vmware с 5.1 кажется версии пишет, что проброс И драйва И робота внутрь виртуальной машины - неподдерживаемая конфигурация:

As per the vSphere 5.x Release Notes, VMware does not support Tape Drives connected directly to ESXi 5.x.

https://kb.vmware.com/s/article/2007904?language=en_US

VMware does not provide support for backup tape drives and tape library devices or their functionality on ESXi/ESX hosts.

https://kb.vmware.com/s/article/1016407?language=en_US

"ESX/ESXi does not support FC connected tape devices"

Fibre Channel SAN Configuration Guide

http://www.vmware.com/pdf/vsphere4/r41/vsp_41_san_cfg.pdf

http://blog.vmpress.org/2010/12/fc-tape-library-vmware-esxi.html

Я пробовал как-то затащить внутрь виртуалки целиком HBA (VM Direct Path IO) - что-то все равно не взлетало. Драйв виден, робот нет. Или виден, но не ездит. Плюнул, но может и можно.

Читал что у людей получалось для 4-й версии

http://blog.vmpress.org/2010/12/fc-tape-library-vmware-esxi.html

Ходят упорные слухи, что в Гитлера (Hyper-V) можно затащить при подключении по SCSI.

Но опять же - я не пробовал, готового решения не видел.

Два порта в две фабрики - конфигурация штатная. Только не надо забывать включать MPIO в Windows server, который включается отдельным пинком.

Но. Но для привода в библиотеке вторая пара портов - это не второй путь. Это Failover.

Более того, по слухам и мнениям, включать Failover в вторую фабрику - верный путь к глюкам.

В две фабрики включать можно если:

- на библиотеку установлены отдельные две лицензии - кажется High Availability Control Path Failover (3000 - три тысячи - долларов) и еще одна.

- есть желание потыкаться в WWN где-то внутри MPIO и прочая. Слухи видел, матчасть не читал.

Надо заметить, что хотя библиотека (робот) и привод виделись как два устройства каждое, Veeam это вполне устраивало и внутре себя он видел одно устройство.

В итоге сервис Veeam был удален, сервисы netbackup развернуты, и поехали.

Ошибки траблшутинга.

Некоторые уже успели прочитать разосланную первую версию истории, как дело было в реальности и почему. Тут будет про немного другое.

Сначала надо понять путь, каким идут данные.

Netbackup, в отличии от Veeam, умеет писать данные в режиме Data 2 tape. Veeam вообще данные писать тоже умеет, но в режиме file 2 tape - то есть пишет свои репозитории или выбранные с локального диска файлы.

Поэтому путь данных для Netbackup выглядит примерно так:

Взяли данные в Netbackup - скомандовали библиотеке взять кассету в привод - дождались ответа "кассета в приводе" - отдали команду на перемотку кассеты - дождались перемотки - отдали данные в HBA - HBA отдал данных в switch - switch отдал данные в буфер привода - привод записал данные и ответил "шлите еще".

Все это прекрасно, до той поры пока не надо начинать выяснять "какие данные попали в HBA и что он с ними сделал". В случае передачи данных по сети есть разные MS netmon, Microsoft Message Analyzer

https://www.microsoft.com/en-us/download/details.aspx?id=44226

есть wireshark, tcpdump - можно посмотреть что ушло по сети от сервера.

В случае же FC и драйв, и библиотека (робот) - видны как два устройства, и как посмотреть что в них реально поступило - мне не известно. Если смотреть в сторону перехвата FC, то есть статья про Fibre Channel Switch Dump

http://support.qlogic.com/SupportCenter/articles/FAQ/2385

Есть тред How to Capture Fiber Channel traffic

https://supportforums.cisco.com/t5/storage-networking/how-to-capture-fiber-channel-traffic/td-p/2767280

с ссылками на Xgig

http://community.brocade.com/t5/Fibre-Channel-SAN/Sniffing-Fibre-Channel-Packets-from-Brocade-Switch-200E/td-p/21680

https://ask.wireshark.org/questions/27036/capturing-fibre-channel-frames

и пишут про какой-то FC analyzer

есть Checking for Fibre Channel connectivity problems

http://www.brocade.com/content/html/en/troubleshooting-guide/FOS_740_TSHOOT/GUID-FD646B83-258A-4DFD-988E-D4D92A0ABF8A.html

Но вообще как-то все равно грустно.

Траблшутинг ленточных библиотек средствами netbackup

Заведение робота в Veritas Netbackup сделано .. ну мягко говоря через жопу. Там есть десяток видов подключений робота, если его добавлять вручную, из вкладки Robot.

Все эти вида добавлений не работали.

Единственный гарантированно работавший способ - это добавление робота через мастера со стартовой (самой верхней) вкладки netbackup. Вот там мастер обнаружения вполне работает. Причем, как и veeam - видит не два устройства, а одно.

Робот добавился, привод увидел, инвентаризацию кассет сделал, и отказался писать.

Точнее - если бы он совсем отказался писать, было бы еще ничего. Но он не отказывался - просто не писал.

Сам Veritas Netbackup вполне себе рабочий софт, с богатой историей, огромной кучей разного рода утилит под капотом, и совершенно невообразимыми завалами мануалов. И без powershell, хотя из командной строки в нем можно делать овердохрена.

Но стоит пойти глубже, как этого перестает хватать.

Из всего набора утилит в Netbackup оказались полезными:

Описанная в Troubleshooting Robot or Drive Issues in NetBackup

https://www.veritas.com/support/en_US/article.TECH169477

утилита robtest - с совершенно угробищным синтаксисом вида

For example, this robtest command issues a move media request from slot 86 to drive 2:

m s86 d2

Это позволило проверить, что кассеты в роботе в драйвы встают, как минимум робот исправен, и проблемы в netbackup.

При попытке включить debug - утилита вылетала.

Второй полезной утилитой оказалась bpbkar32

How to benchmark the performance of the bpbkar32 process on a Windows client

https://www.veritas.com/support/en_US/article.TECH17541

это позволило уточнить то, что я тоже и так знал - что Netbackup может получать данные с дисков на нормальной скорости, проблема не в чтении с диска.

Следующим шагом было внезапное понимание того, что Netbackup может писать прямо на кассеты. Veeam не может, Bareos (Bacula) вроде тоже.

Точнее Veeam может писать на кассеты а)файлы б) свой репозиторий, потому что он файлы. Но для бекапов - Disk 2 Disk to tape и все.

Для проверки того, что с источником тоже все нормально, была сделана отдельная задача (в терминах Netbackup - policy), которая писала "куда-то".

Следующим шагом была попытка записать "хотя бы гигабайт" и попытка покрутить настройки в Netbackup. И посмотреть логи.

Логи Veritas netbackup.

Я не знаю, откуда это унаследовано, но чтобы посмотреть логи - надо вручную сделать под них папки, в veritas\netbackup\log, по одной на каждый процесс.

Потом можно вкрутить в глубинах настройки на Master сервере параметры media\properties\log и включить их там.

В некоторых случаях (для логов Vmware и всякого hotadd) надо еще и в реестре потыкать, тогда будут логи от 0 до 7, причем самые толстые это 5, а 6 и 7 - какие то специальные.

Сами логи иногда показывают то что надо - всякие обращения, lock файлы, вообще логи полезные.

Но в моей случае - поначалу в логе не было ничего.

Точнее ну как ничего .. как-то раз с оставил задачу на пару часов, и в логе самой задачи появилась надпись "start writing" и скорость - 30 КИЛОБАЙТ в секунду. Ну, два мега в минуту. И простыня с логами. В которых было что-то типа "что дали то и пишу".

Проблема в том, что ничего полезного - в логи не попадало.

Настройки скорости в Veritas netbackup для кассетных библиотек и не только.

Есть пдф-ка типа Perfomance tuning netbackup / Symantec NetBackup Backup Planning and Performance Tuning

В ней расписан страх и ужас - конфиг параметров

1) глобальный, но диски из него можно исключить, точнее прописать в них свои параметры

2) делается путем подсовывания файлов в program files\veritas\netbackup\db\

Файлы - в частности такие -

SIZE_DATA_BUFFERS

NUMBER_DATA_BUFFERS

SIZE_DATA_BUFFERS_DISK

NUMBER_DATA_BUFFERS_DISK

Это именно текстовые файлы (без расширений вообще), которые можно делать в блокноте. Внутрь в тексте же пишутся всякие разные цифирки.

См. https://vox.veritas.com/t5/NetBackup/How-data-buffer-size-and-buffer-number-effect-the-Netbackup/td-p/445557

В некоторых случаях само наличие файла без ничего внутри выступает в роли джампера.

Например DO_NOT_APPEND (это про кассеты) или NOSHM (это про shared memory)

См. Does the touch file "NOSHM" really disable the use of shared memory during backups and/or restore?

https://www.veritas.com/support/en_US/article.000026448

Можно кстати netbackup писать в MS Win events, только я забыл как. Тоже как-то через vxlogcfg файл там же.

В итого тыкание в эти джамперы успеха не дало.

Драйвера прошивки и вот это все, часть первая.

Сначала было обновить прошивки и на библиотеке, и драйвера библиотеки в Win.

Беда и печаль имени HPE

Найти что-то на сайте HPE можно только через гугль. Это ужас, кошмар, но половина ссылок там битая, а остальные ведут неизвестно куда. Так что через гугль находим то, что нужно, и дальше гуглим уже по названию. Это помогает.

Кстати про прошивки. Внезапно (для меня) у библиотеки одни прошивки, у драйвов другие. Ничего удивительного, учитывая что HBA - это очень и очень навороченный ASIC, с своей оперативкой, биосом, процессором и микрооперационкой.

Тем не менее, все было обновлено .. и результата не дало.

Зато нашелся документ от HPE, что-то типа HPE HCL - HPE Data Availability, Protection and Retention Compatibility Matrix,

www.hpe.com/storage/buramatrix

с указанием что и как работает, и какие прошивки актуальные, и с каким софтом что работает, а что нет.

Никаких результатов это не дало.

Переходим к плану Б и В. Потом Г и так далее.

План Б был прост - эскалировать проблему, типа мы тут тупые, помогите.

Предложенное решение было хорошим

- выключите лишние порты на драйвах,

- оставьте презентованной только библиотеку, а лучше вообще зацепите ее на отдельный HBA

- обновите все прошивки

- может драйвы умерли и надо их в поликлинику сдать на опыты.

Только слабо помогло. Точнее, помогло никак, разве что решил парочку других проблем вида "ну я и дурачок" - потому что все прошивки и драйвера на стороне библиотеки были обновлены.

План В.

Было решено поискать "что-то для тестирования кассет, раз Netbackup не пишет и HBA на сервере тоже все пишет и читает".

В недрах Netbackup ничего подобного не нашлось. Есть вроде как утилита под Linux, которая что-то пишет, но это не утилита Netbackup.

Обзор "что еще пишет и может затестировать кассеты" прошел .. тоже нетрадиционно - было решено попробовать System Center Data Protection Manager (DPM), Bareos и может попробовать обратно Veeam.

Bareos не встал нормально.

Veeam надо было переустанавливать с ноля, снова запрашивать ключ и так далее.

System Center Data Protection Manager я скачал, но почему-то решил сначала почитать про него.

Но это совершенно дурные способы, вообще-то.

Потому что есть Linear Tape File System (LTFS).

Конечно, Хабр с их набросами про политику то еще днище, но иногда кто-то по неопытности начинает туда писать что-то полезное. В том числе так туда попала статья "Хранение данных на кассетах LTO-5 Ultrium с файловой системой LTFS".

https://habrahabr.ru/post/263199/

Программа LTFS Configuration (LTFS for Windows) была найдена, скачана, и даже заработала.

Точнее говоря НЕ заработала, потому что .. просто что-то не пошло. Кажется, не запустилась.

Программа кстати хорошая.

Что-то подобное есть и на HPE - ПО HPE StoreOpen Standalone и HPE StoreOpen Automation.

Только без регистрации не скачать.

https://www.hpe.com/ru/ru/product-catalog/storage/storage-software/pip.hpe-storeopen-and-linear-tape-file-system-ltfs-software.4249221.html

План Д.

После этого решено было посмотреть - а что же это там происходит внутре HBA.

Причем на сервере - залезть в HBA на библиотеке не было решительно никакой возможности.

Первым делом был нагуглен Qlogic San serfer. Частично в этом помог бложек кампании Veeam, который они по инерции ведут на хабре

Статья

Разбор кейса про изменение настроек размера блока данных для записи на ленту с Veeam Backup & Replication

https://habrahabr.ru/company/veeam/blog/340236/

со ссылкой на Changing Block Size in a QLogic HBA in Windows 2008

2008, КАРЛ! В 2017 году.

Хотя некоторые и с 2003 никак не слезут, что уж.

Следующим объектом раскопок стал сайт Qlogic.

Хороший сайт в целом, если ткнуть на Download - то можно выбрать тех, для кого они OEM гонят.

В нашем случае - HPE, http://driverdownloads.qlogic.com/QLogicDriverDownloads_UI/HP.aspx?companyid=4

Но что особо хорошо так это то, что там сравнительно легко можно вылезти на очень полезный софт -

qlogic converged console.

Софт то я скачал .. только он не заработал. Нет у вас, говорит, ни агентов в системе, ни методов супротив Кости Сапрыкина.

Зато он притащил с собой ~~мумитролля~~ Tomcat7

Пришлось качать Windows SuperInstaller (x64) и все ради чего - ради FC-FCoE, iSCSI, and Ethernet Networking Management Agents

После чего все нашлось, и вылезло много всяких картинок ..

Как оказалось - почти бесполезных, но версию BIOS и Firmware он мне показал.

Кстати у HPE есть своя версия qlogic converged console - QConvergeConsole Management Utility GUI for HP Branded QLogic based Fibre Channel, Converged Network and Intelligent Ethernet Adapters.

Помогло это снова почти никак. Но помогло потом.

И тут внезапно - HPE Library and Tape

Еще в самом начале всей этой возни я поставил HPE Library and Tape Tools - is a free, downloadable, robust diagnostic tool for all of HP's tape storage and magneto-optical storage products.

LTT 4.24 is a new architecture with web based GUI and monitoring capability of TapeAssure.

https://www.hpe.com/ru/ru/product-catalog/storage/storage-software/pip.hpe-library-and-tape-tools.406729.html

Ссылка на загрузку не работает, так что гугль и еще раз гугль -

HPE Library and Tape Tools 4.24 Release Notes

Part Number: 876940-001

Published: March 2017

HPE Library and Tape Tools

By downloading, you agree to the terms and conditions of the Hewlett Packard Enterprise Software License Agreement.

Толи у меня все же была подписка, толи я кого спросил - не помню. В итого утилиту я скачал, поставил, запустил .. и она вылетела с ошибкой "ой я нишмагла".

Тогда, еще в начале всей возни, заниматься с ней мне было лень, хотелось быстрых решений, да и других дел хватало.

Теперь пришлось потыкаться, потому что вариантов не было, кроме как собрать еще один сервер, а под него надо контроллер, и так далее. И еще провода перетыкать.

Потыкавшись в утилиту еще пару раз, оказалось что запускаться то она запускается, и даже видит и робот и драйв, но драйв ~~зогхвачен~~ залочен.

Оказалось, что драйв захвачен кем-то из уже установленного в процессе раннего тыкания в разное - толи Netbackup device manager, толи Veeam tape manager, толи LTFS Configuration.

Все службы переведены в Disabled, потом перезагружен и сервер, и отдельно драйв, и отдельно библиотека.

На втором заходе на эту процедуру LTT сказала, что она конечно что-то видит, но не может сообразить в каком виде все это ей подсовывают, поэтому укажите руками.

После указания руками - она все же запустилась.

LTT

Писали ее индусы под чем-то очень охуенным, потому что юзабилити у программы явно на высоте, одна отчетность в стиле "а мы умеем в выпадающие списки" уже доставляет. Отдельно доставляет то, что надо в ряде случаев тыкаться в опции, а еще в ряде случаев (write / read test) - сначала сунуть кассету в драйв через интерфейс библиотеки.

Однако тесты показали странное - роботом библиотека шевелит, что-то писать пытается, на брокаде какие-то данные идут .. но вот минутный поток в 2 (два) мегабайта в минуту - это как-то ну совсем не характерно для оптики. Зато вполне соответствует ранее замеченным 30 кбайт//секунду.

Проверка всей цепочки.

В очередной раз пришлось обратить внимание на всю цепочку - от драйвера win - HBA в самом сервере - порт на Brocade - опять порт на Brocade - драйв.

Прошивки на библиотеке были обновлены ранее, на брокаде в целом тоже (хотя обновление брокады - мой страшный сон, что через FTP и гуй, что в консоли).

Раньше HBA работал с этой библиотекой, но мало ли что.

Решено было посмотреть поближе, хотя, опять же - с презентованными то LUN он работал.

LUN были отцеплены, ибо нефиг.

Прошивка (firmware) на HBA оказалась предпоследней, с лета, приехала вместе с Service Pack for ProLiant (SPP) скорее всего. Драйвер оказался постарей - кажется, марта 2017. Или типа того.

Ладно, что же оставалось. Все равно писать тикет, так что попросят обновиться - и прошивку и драйвер я обновил.

Случилось чудо.

После обновления прошивки и драйвера HBA на сервере - драйв и библиотека взяли, и прошли и штатные тесты (пошевелить роботом, почитать что внутре драйва - ошибок нет), и внезапно прошел тест записи.

Оказалось, что тест скорости записи, выведенный отдельной кнопкой, даже работает и (о чудо) меряет скорость. Правда, минимальный размер тестового файла - 1 гбайт, но он же записался, причем быстро.

После этого драйв (после переустановки конечно) заработал и в Netbackup, и тоже выдал нормальную скорость записи - под сотню мегабайт в секунду, после подстройки буферов - и все полторы.

Вопросы.

Вопрос "почему я дурак и сразу не обновил прошивку и драйвер еще два месяца назад" сравнительно прост.

- Затупил, не ожидал что "вроде как работающий HBA и только писавший из Veeam - не будет писать из netbackup.

- свежая прошивка и драйвер от HPE вышли месяц назад, в конце сентября.

- надо было убрать презентацию LUN, остановить все задачи, поставить брокаду на монитор и заниматься строго этим, а не котиков рассматривать.

Плюсы.

Сгонял и лично поговорил с всякими интересными людьми. Понял что логи нетбекапа - в целом не очень. Нашел три полезные программы, помянутые выше и всяко потыкал в них.

Минусы.

Можно было и побыстрей это сделать конечно. В разы быстрей.

Симптоматика для выяснения проблемы.

Наиболее показательны оказались две вещи

- данные пишутся, но со скорость порядка 1-2 мегабайт/минуту

- кассета в привод встает не 1 минуту (нормальная ситуация), а 4 минуты.

Возможно связанные случаи.

DPM to tape backup writing speed is very slow

https://social.technet.microsoft.com/Forums/en-US/f5b7b628-366e-4e2c-80f6-6370ca04557c/dpm-to-tape-backup-writing-speed-is-very-slow?forum=dpmtapebackuprecovery

How to by-pass DPM tape backup performance issues

https://blogs.msdn.microsoft.com/george_bethanis/2014/05/26/how-to-by-pass-dpm-tape-backup-performance-issues/

Иванов Иван Ивановитч : другие произведения.

Hpe Storeever Msl2024/4048/6480 Tape Library troubleshooting and Veeam backup and replication и veritas netbackup - lessons and conclusions

© Copyright Иванов Иван Ивановитч Размещен: 29/10/2017, изменен: 29/10/2017. 29k. Статистика. Статья: Скачать FB2		Ваша оценка: