Например, для одного из хранилищ после 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точнила у команды поддержки о каком кейсе может идти речь. У нас есть предположения, но предлагаю указать номер кейса (можно в личных сообщениях). Если речь идёт о том кейсе, о котором мы думаем, то мы по-прежнему будем продолжать работу в данной ситуации, несмотря на то, что сервисный контракт уже истёк. Также напоминаем, что в данном кейсе требуется дополнительный анализ поведения ОС со стороны техподдержки вендора.
Сергей, очень жаль, что есть такой неприятный опыт. Увы, не знаю всей истории, уверена, что всё может быть немного сложнее. Тем не менее, мы всегда рады показать наши СХД как на площадке Заказчика, так (иногда) и с помощью удалённых стендов. Вопросы с КП обычно решаются через наших менеджеров/партнёров. Если долго нет ответа, возможно наш саппорт (CISsupport@huawei.com) сможет помочь в данной ситуации.
При возникновении проблем с ТП (для Enterprise) можно обратиться к имеющемуся контакту со стороны Huawei (обычно это сервисный или аккаунт менеджер) или в крайнем случае к партнёру (если почему-то со стороны Huawei контактов нет).
Тем не менее, нужно понимать, что ТП – интерфейс между разработкой и Заказчиком. Обычно коллеги из ТП предоставляют ответ в рамках SLA. Да, иногда исправление проблем занимает длительное время, но, как мне кажется, это не тот критерий, который определяет показатель качества работы именно поддержки.
Кстати, вопросы по работе оборудования также можно обсуждать и на нашем Enterprise форуме.
Пропал доступ по причине изменения конфигурации/сбоя в работе СХД? Что именно патчили не совсем понял. Сами данные были целы?
Оборудование сконфигурировали давно, через некоторое время произошёл сбой из-за особенностей конфигурации в т.ч. (было несколько факторов). Хотпатч выпустили для обновления контроллеров СХД, чтобы перевести одну из файловых систем из состояние Faulty в Normal. Признаюсь, было нервно. Главное – данные целы!
Воспроизводит проблему на стенде команда в Китае или вы и подключаете их по удалёнке?
Если Заказчик разрешает – подключаемся удалённо (в случае с кейсами высокого приоритета удалёнка становится возможна практически в 100% случаев). Если это требуется для решения проблемы, коллеги из Китая тестируют воспроизведение проблемы и ищут её решение на своём локальном стенде.
Про тестирование на стендах. Один из недавних показательных кейсов о полезности своих стендов. В процессе реализации сервиса по миграции (это уже не совсем поддержка, а проф. сервис, но всё же) обнаружили, что в одной из свежих сборок ОС при добавлении нового LUN и рескана дисков появляется BSOD. Опытным путём обнаружили, что проблема есть на VM, а вот на физике всё ок. Также выяснили, что при презентации LUNов с СХД других вендоров проблема также существует. Вендор ОС обещал исправиться, Заказчику порекомендовали “свежак” в продуктив не наливать. Самостоятельно Заказчику с проблемой было бы разобраться сложнее + на это ушло бы пару дней.
Имел в виду возникшую по какой-либо причине ситуацию, когда состояние метаданых (повреждены, уничтожены) и распределение пользовательских данных на накопителях не соответствует ни одной из моделей, поддерживаемых оборудованием.
Под классическими СХД подразумеваете те, что использую стандартные модели хранения данных, обозначаемые номерами уровней?
На уровне метаданных обычно работают эксперты из нашей HQ, увы мне сложно детально прокомментировать этот вопрос. Но в кейсе, где делали хотпатч проблемы были как раз с метаданными. Под классическими имею в виду не SDS (не программное решение, настроенное поверх серверов), т.е. СХД с контроллерными и (если нужно) дисковыми полками.
Как поступаете в случае выхода из строя количечества накопителей, превышающих заложенный в СХД уровень избыточности?
На старых версиях СХД можно было попробовать включить "умерший” HDD (через наш саппорт), а вот с SSD уже сложнее. На массивах серии Dorado V6 есть функционал anti-wear leveling, который помогает уменьшить вероятность одновременного выхода из строя нескольких дисков. Для тех, кто не любит менять диски, на Dorado V6 есть RAID-TP (возможность одновременного отказа 3ёх дисков).
В целом интересно, знакомы ли вы с программным обеспечением, позволяющем виртуально реконструировать повреждённые массивы? Для того, чтобы извлечь данные и затем залить их на пересозданный заново массив. Или такого рода проблемы решаются созданием патчей под конкретную ситуацию?
Пока не знакома. Подобные задачки если и решаются, то уже более узкоспециализированными коллегами из нашей HQ. Как верно подметили ниже, у нас очень много команд разработки, невозможно знать в деталях все линейки СХД, а у каждой свои особенности.
В прошлом году был кейс, когда у Заказчика пропал доступ к данным (само собой, доступ к файловой системе пропал не сам по себе, а после определённых не совсем корректных действий применительно к СХД со стороны самой СХД). Оперативные способы решения (при помощи 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).
Перепрошивка дисков/контроллеров порой действительно необходима для решения проблемы. Если наша техническая поддержка сделала заключение, что проблема решается обновлением, то задачка на обновление передаётся департаменту профессиональных сервисов и мы (я и мои коллеги) помогаем Заказчку с проведением обновления. Обновление является операцией с повышенного риска, поэтому проводится только после предварительного анализа логов, собранных через специальный инструмент – SmartKit. Анализ логов позволяет избежать многих проблем, в т.ч. провести обновление без прерывания сервисов.
Форматирование (с потерей данных), пожалуй, совсем редкий кейс. Форматирование СХД с полной потерей данных в своей практике вспомнить не могу. Был кейс, когда было необходимо форматирование одной из СХД в HyperMetro паре и дальнейшая повторная синхронизация более 100 TB данных. Такой кейс был вызван в т.ч. тем, что Заказчик и партнёр пытались самостоятельно устранить изначальную проблему. Так что дополнительно могу порекомендовать сразу писать в саппорт при наличии проблем с СХД :)
Кстати, помимо прошивки (обновления) существует установка хотпатчей. Лучше всего ставить хотпатчи проактивно, не дожидаясь воспроизведения уже известных проблем. Установка хотпатча занимает около 15 минут. Мы стараемся так или иначе напоминать об этом Заказчикам, напомню и тут лишний раз.
"Сырой" софт к Заказчикам обычно не попадает, предварительно коллеги из HQ проводят все необходимыe стадии тестрования. Затем свежие прошивки мы гоняем в рамках POC (Proof of Concept) и, только после этого, в продуктив. Стабильной прошивка становится примерно через полгода после релиза.
Подобная практика присутствует у всех Enterprise вендоров IT-оборудования, в этом и смысл End-of-Life. Поддержка оборудования и выпуск запасных частей происходит еще как минимум 5 лет после End-of-Sale, после наступает период End-of-Life, таким образом жизненный цикл продукта получатся около 8-10 лет, что вполне соответствует циклу обновления IT-оборудования. Заниматься поддержкой legacy оборудования (с момента начала продаж которого прошло 10 лет и более) нецелесообразно ввиду появления все более новых решений, а вероятность отказов старого оборудования увеличивается с каждым годом. Данная модель применяется не только в Enterprise, с таким же успехом, к примеру, можно попробовать обновить смартфон выпуска 2012 года.
Решить подобную задачу можно путем поиска запасных частей по остаткам складов дистрибуторов, или у сервисных провайдеров занимающихся поддержкой EOL оборудования, но более основательным и рациональным подходом будет модернизация данных комплексов.
У большинства CХД наблюдается деградация производительности, если на дисках мало свободного места. Обычно это учитывается при сайзинге СХД. Тем не менее, занятость 60-70% пространства не должна приводить к проблемам с производительностью. Также у каждой СХД есть свой сценарий использования. Например NAS СХД OS 9000 (V5) предназначена для работы с большим блоком данных (Media asset scenario/HPC Scenario/Video surveillance Scenario), виртуализация (в основном там маленький блок) может работать не так эффективно как на блочном хранилище.
Я yточнила у команды поддержки о каком кейсе может идти речь. У нас есть предположения, но предлагаю указать номер кейса (можно в личных сообщениях). Если речь идёт о том кейсе, о котором мы думаем, то мы по-прежнему будем продолжать работу в данной ситуации, несмотря на то, что сервисный контракт уже истёк. Также напоминаем, что в данном кейсе требуется дополнительный анализ поведения ОС со стороны техподдержки вендора.
Сергей, очень жаль, что есть такой неприятный опыт. Увы, не знаю всей истории, уверена, что всё может быть немного сложнее. Тем не менее, мы всегда рады показать наши СХД как на площадке Заказчика, так (иногда) и с помощью удалённых стендов.
Вопросы с КП обычно решаются через наших менеджеров/партнёров. Если долго нет ответа, возможно наш саппорт (CISsupport@huawei.com) сможет помочь в данной ситуации.
При возникновении проблем с ТП (для Enterprise) можно обратиться к имеющемуся контакту со стороны Huawei (обычно это сервисный или аккаунт менеджер) или в крайнем случае к партнёру (если почему-то со стороны Huawei контактов нет).
Тем не менее, нужно понимать, что ТП – интерфейс между разработкой и Заказчиком. Обычно коллеги из ТП предоставляют ответ в рамках SLA. Да, иногда исправление проблем занимает длительное время, но, как мне кажется, это не тот критерий, который определяет показатель качества работы именно поддержки.
Кстати, вопросы по работе оборудования также можно обсуждать и на нашем Enterprise форуме.
Максим, рада вновь пообщаться :) С прошедшими!
Если что, я всегда на связи.
Оборудование сконфигурировали давно, через некоторое время произошёл сбой из-за особенностей конфигурации в т.ч. (было несколько факторов). Хотпатч выпустили для обновления контроллеров СХД, чтобы перевести одну из файловых систем из состояние Faulty в Normal. Признаюсь, было нервно. Главное – данные целы!
Если Заказчик разрешает – подключаемся удалённо (в случае с кейсами высокого приоритета удалёнка становится возможна практически в 100% случаев). Если это требуется для решения проблемы, коллеги из Китая тестируют воспроизведение проблемы и ищут её решение на своём локальном стенде.
Про тестирование на стендах. Один из недавних показательных кейсов о полезности своих стендов. В процессе реализации сервиса по миграции (это уже не совсем поддержка, а проф. сервис, но всё же) обнаружили, что в одной из свежих сборок ОС при добавлении нового LUN и рескана дисков появляется BSOD. Опытным путём обнаружили, что проблема есть на VM, а вот на физике всё ок. Также выяснили, что при презентации LUNов с СХД других вендоров проблема также существует. Вендор ОС обещал исправиться, Заказчику порекомендовали “свежак” в продуктив не наливать. Самостоятельно Заказчику с проблемой было бы разобраться сложнее + на это ушло бы пару дней.
На уровне метаданных обычно работают эксперты из нашей HQ, увы мне сложно детально прокомментировать этот вопрос. Но в кейсе, где делали хотпатч проблемы были как раз с метаданными. Под классическими имею в виду не SDS (не программное решение, настроенное поверх серверов), т.е. СХД с контроллерными и (если нужно) дисковыми полками.
На старых версиях СХД можно было попробовать включить "умерший” HDD (через наш саппорт), а вот с SSD уже сложнее. На массивах серии Dorado V6 есть функционал anti-wear leveling, который помогает уменьшить вероятность одновременного выхода из строя нескольких дисков. Для тех, кто не любит менять диски, на Dorado V6 есть RAID-TP (возможность одновременного отказа 3ёх дисков).
Пока не знакома. Подобные задачки если и решаются, то уже более узкоспециализированными коллегами из нашей HQ. Как верно подметили ниже, у нас очень много команд разработки, невозможно знать в деталях все линейки СХД, а у каждой свои особенности.
В прошлом году был кейс, когда у Заказчика пропал доступ к данным (само собой, доступ к файловой системе пропал не сам по себе, а после определённых не совсем корректных действий применительно к СХД со стороны самой СХД). Оперативные способы решения (при помощи 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).
Перепрошивка дисков/контроллеров порой действительно необходима для решения проблемы. Если наша техническая поддержка сделала заключение, что проблема решается обновлением, то задачка на обновление передаётся департаменту профессиональных сервисов и мы (я и мои коллеги) помогаем Заказчку с проведением обновления. Обновление является операцией с повышенного риска, поэтому проводится только после предварительного анализа логов, собранных через специальный инструмент – SmartKit. Анализ логов позволяет избежать многих проблем, в т.ч. провести обновление без прерывания сервисов.
Форматирование (с потерей данных), пожалуй, совсем редкий кейс. Форматирование СХД с полной потерей данных в своей практике вспомнить не могу. Был кейс, когда было необходимо форматирование одной из СХД в HyperMetro паре и дальнейшая повторная синхронизация более 100 TB данных. Такой кейс был вызван в т.ч. тем, что Заказчик и партнёр пытались самостоятельно устранить изначальную проблему. Так что дополнительно могу порекомендовать сразу писать в саппорт при наличии проблем с СХД :)
Кстати, помимо прошивки (обновления) существует установка хотпатчей. Лучше всего ставить хотпатчи проактивно, не дожидаясь воспроизведения уже известных проблем. Установка хотпатча занимает около 15 минут. Мы стараемся так или иначе напоминать об этом Заказчикам, напомню и тут лишний раз.
"Сырой" софт к Заказчикам обычно не попадает, предварительно коллеги из HQ проводят все необходимыe стадии тестрования. Затем свежие прошивки мы гоняем в рамках POC (Proof of Concept) и, только после этого, в продуктив. Стабильной прошивка становится примерно через полгода после релиза.