Комментарии 17
Сатья с фото - однозначно лайк :)
Обычно ждёшь, что системные инженеры - это такие бородатые мужики с усталым взглядом. У тут симпатичная девушка.
Клево
Huawei в данный момент предлагает впечатляющие решения. И по характеристикам и по стоимости и по уровню техподдержки. Если вы до сих пор использовали решения от "классических" вендоров СХД, советую посмотреть в сторону Huawei.
Работаю в сфере восстановления данных. Исходя из большого опыта восстановления данных с СХД, могу сказать что корнем большинства серьёзных проблем, возникающих с современными хранилищами, является парадоксальная вера программистов пишущих прошивки в то, что железо всегда работает безупречно.
Елизавета, скажите пожалуйста, как ваша служба поддержки обрабатывает ситуации, в которых приведение СХД в исправное состояние не помогает получить доступ к данным? Например, пользователь перепутал железки и на хранилище с важными данными пересоздал массив заново с другими параметрами? Размер блока изменил, например? И занимается ли ваша поддержка вообще такими случаями?
В прошлом году был кейс, когда у Заказчика пропал доступ к данным (само собой, доступ к файловой системе пропал не сам по себе, а после определённых не совсем корректных действий применительно к СХД со стороны самой СХД). Оперативные способы решения (при помощи CLI команд) не помогли восстановить работоспособность, поэтому было принято решение экстренно разработать хотпатч для решения проблемы. Мы подключили несколько команд из отдела R&D (коллеги работали практически 24x7), за 2 дня патч был готов, протестирован на тестовом стенде в HQ. В итоге доступ к данным восстановлен.
В общем и целом, для решения проблем делаем всё что в наших силах и в нашей компетенции. Траблшутить продукты других вендоров нам сложно (но иногда и таким успешно занимаемся). Наш мощный инструмент в решении проблем – это большая команда узкоспециализированных экспертов на линии поддержки L3 (коллеги находятся в Китае) и, как уже говорила чуть выше, для решения самых сложных проблем мы используем стенды, которые позволяют воспроизвести и "пощупать" проблему.
Например, пользователь перепутал железки и на хранилище с важными данными пересоздал массив заново с другими параметрами? Размер блока изменил, например?
Вопрос про классические СХД? Например, изменить размер блока на LUNe на массивах серии OceanStor Dorado V6 можно только:
1) Пересоздав LUN и выбрав при этом нужный Application Type (Application Type – это профиль LUNa, где указывается размер блока, включены ли дедуп/компрессия);
2) Затем возможна миграция на новый LUN на уровне СХД без прерываний в сервисе (при помощи SmartMigration), ну или уже на уровне гипервизора (vMotion для VMware, Live Migration для Hyper-V).
В прошлом году был кейс, когда у Заказчика пропал доступ к данным
Пропал доступ по причине изменения конфигурации/сбоя в работе СХД? Что именно патчили не совсем понял. Сами данные были целы?
Вообще очень серьёхный подход к поддержке, конечно. Несколько раз сталкивались с ситуациями когда в процессе попытки владельца оборудования подключить к решению проблемы R&D отдел производителя выяснялось, что команда, разрабатывавшая данную железку давно распущена и непонятно где искать людей, которые понимают как она работает.
Воспроизводит проблему на стенде команда в Китае или вы и подключаете их по удалёнке?
Вопрос про классические СХД
Имел в виду возникшую по какой-либо причине ситуацию, когда состояние метаданых (повреждены, уничтожены) и распределение пользовательских данных на накопителях не соответствует ни одной из моделей, поддерживаемых оборудованием.
Под классическими СХД подразумеваете те, что использую стандартные модели хранения данных, обозначаемые номерами уровней?
Как поступаете в случае выхода из строя количечества накопителей, превышающих заложенный в СХД уровень избыточности?
В целом интересно, знакомы ли вы с программным обеспечением, позволяющем виртуально реконструировать повреждённые массивы? Для того, чтобы извлечь данные и затем залить их на пересозданный заново массив. Или такого рода проблемы решаются созданием патчей под конкретную ситуацию?
Пропал доступ по причине изменения конфигурации/сбоя в работе СХД? Что именно патчили не совсем понял. Сами данные были целы?
Оборудование сконфигурировали давно, через некоторое время произошёл сбой из-за особенностей конфигурации в т.ч. (было несколько факторов). Хотпатч выпустили для обновления контроллеров СХД, чтобы перевести одну из файловых систем из состояние Faulty в Normal. Признаюсь, было нервно. Главное – данные целы!
Воспроизводит проблему на стенде команда в Китае или вы и подключаете их по удалёнке?
Если Заказчик разрешает – подключаемся удалённо (в случае с кейсами высокого приоритета удалёнка становится возможна практически в 100% случаев). Если это требуется для решения проблемы, коллеги из Китая тестируют воспроизведение проблемы и ищут её решение на своём локальном стенде.
Про тестирование на стендах. Один из недавних показательных кейсов о полезности своих стендов. В процессе реализации сервиса по миграции (это уже не совсем поддержка, а проф. сервис, но всё же) обнаружили, что в одной из свежих сборок ОС при добавлении нового LUN и рескана дисков появляется BSOD. Опытным путём обнаружили, что проблема есть на VM, а вот на физике всё ок. Также выяснили, что при презентации LUNов с СХД других вендоров проблема также существует. Вендор ОС обещал исправиться, Заказчику порекомендовали “свежак” в продуктив не наливать. Самостоятельно Заказчику с проблемой было бы разобраться сложнее + на это ушло бы пару дней.
Имел в виду возникшую по какой-либо причине ситуацию, когда состояние метаданых (повреждены, уничтожены) и распределение пользовательских данных на накопителях не соответствует ни одной из моделей, поддерживаемых оборудованием.
Под классическими СХД подразумеваете те, что использую стандартные модели хранения данных, обозначаемые номерами уровней?
На уровне метаданных обычно работают эксперты из нашей HQ, увы мне сложно детально прокомментировать этот вопрос. Но в кейсе, где делали хотпатч проблемы были как раз с метаданными. Под классическими имею в виду не SDS (не программное решение, настроенное поверх серверов), т.е. СХД с контроллерными и (если нужно) дисковыми полками.
Как поступаете в случае выхода из строя количечества накопителей, превышающих заложенный в СХД уровень избыточности?
На старых версиях СХД можно было попробовать включить "умерший” HDD (через наш саппорт), а вот с SSD уже сложнее. На массивах серии Dorado V6 есть функционал anti-wear leveling, который помогает уменьшить вероятность одновременного выхода из строя нескольких дисков. Для тех, кто не любит менять диски, на Dorado V6 есть RAID-TP (возможность одновременного отказа 3ёх дисков).
В целом интересно, знакомы ли вы с программным обеспечением, позволяющем виртуально реконструировать повреждённые массивы? Для того, чтобы извлечь данные и затем залить их на пересозданный заново массив. Или такого рода проблемы решаются созданием патчей под конкретную ситуацию?
Пока не знакома. Подобные задачки если и решаются, то уже более узкоспециализированными коллегами из нашей HQ. Как верно подметили ниже, у нас очень много команд разработки, невозможно знать в деталях все линейки СХД, а у каждой свои особенности.
Елизавета, спасибо большое за оказанную помощь! С прошедшими праздниками, успехов Вам!
Перепрошивка дисков/контроллеров порой действительно необходима для решения проблемы. Если наша техническая поддержка сделала заключение, что проблема решается обновлением, то задачка на обновление передаётся департаменту профессиональных сервисов и мы (я и мои коллеги) помогаем Заказчку с проведением обновления. Обновление является операцией с повышенного риска, поэтому проводится только после предварительного анализа логов, собранных через специальный инструмент – SmartKit. Анализ логов позволяет избежать многих проблем, в т.ч. провести обновление без прерывания сервисов.
Форматирование (с потерей данных), пожалуй, совсем редкий кейс. Форматирование СХД с полной потерей данных в своей практике вспомнить не могу. Был кейс, когда было необходимо форматирование одной из СХД в HyperMetro паре и дальнейшая повторная синхронизация более 100 TB данных. Такой кейс был вызван в т.ч. тем, что Заказчик и партнёр пытались самостоятельно устранить изначальную проблему. Так что дополнительно могу порекомендовать сразу писать в саппорт при наличии проблем с СХД :)
Кстати, помимо прошивки (обновления) существует установка хотпатчей. Лучше всего ставить хотпатчи проактивно, не дожидаясь воспроизведения уже известных проблем. Установка хотпатча занимает около 15 минут. Мы стараемся так или иначе напоминать об этом Заказчикам, напомню и тут лишний раз.
"Сырой" софт к Заказчикам обычно не попадает, предварительно коллеги из HQ проводят все необходимыe стадии тестрования. Затем свежие прошивки мы гоняем в рамках POC (Proof of Concept) и, только после этого, в продуктив. Стабильной прошивка становится примерно через полгода после релиза.
Позволю себе процитировать комментарий человека к моей статье
Huawei всё
Ну вот прям-таки уж весь хуавей взял и "всё" :) Смешно. Да, косяк есть, при чём по опыту работы с продуктами Huawei (не только консьюмерскими) - это нормальная ситуация. Разработка у них построена каким-то сильно специфическим образом. И вот то ли у них такой менталитет в плане разработки, то ли действительно с тестированием плохо (при чём это даже касается работы собственных девайсах с их же прошивками, а не о связи с каким то другим ПО) - не знаю, но я уже с этим просто смирлся. За то - дёшево :)
https://habr.com/ru/news/t/573108/#comment_23375624
Очевидно, что ТП работает... плохо.
Там просто ОЧЕНЬ много команд внутри, похоже. У двух похожих коммутаторов могут слегка отличаться CLI, например. Видно, что со временем они потихоньку сходятся к более или менее единому стандарту, но процесс идёт небыстро.
По СХД разброс меньше. По крайней мере, веб-интерфейс и RESTful API на OceanStor/Dorado, которые мне встречались, везде одинаковый.
Так что то, что в одном из депертаментов у китайцев что-то плохо, не говорит о том, что плохо везде. Как, впрочем, и не гарантирует от обратного.
При возникновении проблем с ТП (для Enterprise) можно обратиться к имеющемуся контакту со стороны Huawei (обычно это сервисный или аккаунт менеджер) или в крайнем случае к партнёру (если почему-то со стороны Huawei контактов нет).
Тем не менее, нужно понимать, что ТП – интерфейс между разработкой и Заказчиком. Обычно коллеги из ТП предоставляют ответ в рамках SLA. Да, иногда исправление проблем занимает длительное время, но, как мне кажется, это не тот критерий, который определяет показатель качества работы именно поддержки.
Кстати, вопросы по работе оборудования также можно обсуждать и на нашем Enterprise форуме.
Попробовали связаться с данным вендором, но нам так и не прислали КП. Что уж говорить про оборудование на тестирование.
Другие вендоры повели себя намного лояльнее. Результат - КП и результаты тестов vdbench на руках.
Сергей, очень жаль, что есть такой неприятный опыт. Увы, не знаю всей истории, уверена, что всё может быть немного сложнее. Тем не менее, мы всегда рады показать наши СХД как на площадке Заказчика, так (иногда) и с помощью удалённых стендов.
Вопросы с КП обычно решаются через наших менеджеров/партнёров. Если долго нет ответа, возможно наш саппорт (CISsupport@huawei.com) сможет помочь в данной ситуации.
Думаю для многих очевидно, что системы хранения данных это не ПК и даже не рядовой сервер по сроку жизни. Однако, как показала практика, по истечению гарантийного срока даже при приобретенной поддержке ваш СХД начинает превращаться в тыкву!
Попробую расскзать как это будет на самом деле. По опыту использования двух устройств хранения разной серии этой компании.
Например, для одного из хранилищ после EOL(окончания жизненного цикла) невозможно купить запасной жесткий диск, хотя с момента приобретения хранилища прошло всего 6 лет!
Другое хранилище по прошествии того же времени, при заполнении объема более 60-70% начинает страшно тупить (падение производительности в 20 раз!) при этом тикет в техподдержке висит более полугода. Инженеры различных уровней регулярно подключаются, делают вид что читают логи, однако продуктивное использование хранилища не представляется возможным.
Например, для одного из хранилищ после EOL (окончания жизненного цикла) невозможно купить запасной жесткий диск, хотя с момента приобретения хранилища прошло всего 6 лет!
Подобная практика присутствует у всех Enterprise вендоров IT-оборудования, в этом и смысл End-of-Life. Поддержка оборудования и выпуск запасных частей происходит еще как минимум 5 лет после End-of-Sale, после наступает период End-of-Life, таким образом жизненный цикл продукта получатся около 8-10 лет, что вполне соответствует циклу обновления IT-оборудования. Заниматься поддержкой legacy оборудования (с момента начала продаж которого прошло 10 лет и более) нецелесообразно ввиду появления все более новых решений, а вероятность отказов старого оборудования увеличивается с каждым годом. Данная модель применяется не только в Enterprise, с таким же успехом, к примеру, можно попробовать обновить смартфон выпуска 2012 года.
Решить подобную задачу можно путем поиска запасных частей по остаткам складов дистрибуторов, или у сервисных провайдеров занимающихся поддержкой EOL оборудования, но более основательным и рациональным подходом будет модернизация данных комплексов.
Другое хранилище по прошествии того же времени, при заполнении объема более 60-70% начинает страшно тупить (падение производительности в 20 раз!) при этом тикет в техподдержке висит более полугода. Инженеры различных уровней регулярно подключаются, делают вид что читают логи, однако продуктивное использование хранилища не представляется возможным.
У большинства CХД наблюдается деградация производительности, если на дисках мало свободного места. Обычно это учитывается при сайзинге СХД. Тем не менее, занятость 60-70% пространства не должна приводить к проблемам с производительностью. Также у каждой СХД есть свой сценарий использования. Например NAS СХД OS 9000 (V5) предназначена для работы с большим блоком данных (Media asset scenario/HPC Scenario/Video surveillance Scenario), виртуализация (в основном там маленький блок) может работать не так эффективно как на блочном хранилище.
Я yточнила у команды поддержки о каком кейсе может идти речь. У нас есть предположения, но предлагаю указать номер кейса (можно в личных сообщениях). Если речь идёт о том кейсе, о котором мы думаем, то мы по-прежнему будем продолжать работу в данной ситуации, несмотря на то, что сервисный контракт уже истёк. Также напоминаем, что в данном кейсе требуется дополнительный анализ поведения ОС со стороны техподдержки вендора.
Скорая помощь для СХД: как работает поддержка Huawei