Comments 20
А бывают СХД, имеется ввиду нормальные двухголовые с 2 БП, которые не выдержат эти тесты?
del
UFO just landed and posted this here
Спасибо. Пожелание учтём, добавим пункт для следующей статьи о краш-тестах.
Кстати да, отказ контроллера — реальный кейс. Причем иногда оказывается что к моменту отказа, контроллеры такого типа или с такой прошивкой уже невозможно найти в продаже, что рождает интересные проблемы — данные есть, а добыть их нельзя
А вы эксплуатируете схд в продакшене без сервисной поддержки? и без резервных копий?)))))
Я нет — вообще не использую СХД, а для своих задач использую софтовый рэйд или хранилку на основе HDFS, однако нагуглить погорельцев не сложно, вот первое что попалось:
Умер RAID-контроллер. Нужно восстановить информацию, сгорел древний аппаратный raid контроллер., «Raid контроллер сгорел. Как восстановить данные с raid 1+0 и т п, даже на хабре можно найти обсуждения подобных проблем: Что делать, если вышел из строя RAID-контроллер?. Это я к тому что проблема не редка. Из того что вспомнилось, были истории у каких то хостинг провайдеров, которые после аналогичной проблемы почти неделю ребилдили рейд и восстанавливали данные клиентов из пыльных бэкапов (естественно все восстановить не удалось) — это реальная жизнь.
Умер RAID-контроллер. Нужно восстановить информацию, сгорел древний аппаратный raid контроллер., «Raid контроллер сгорел. Как восстановить данные с raid 1+0 и т п, даже на хабре можно найти обсуждения подобных проблем: Что делать, если вышел из строя RAID-контроллер?. Это я к тому что проблема не редка. Из того что вспомнилось, были истории у каких то хостинг провайдеров, которые после аналогичной проблемы почти неделю ребилдили рейд и восстанавливали данные клиентов из пыльных бэкапов (естественно все восстановить не удалось) — это реальная жизнь.
А можете сымитировать вот такой случай — Отказ питания (сразу двух блоков) в момент ребилда массива на хот-спэйр-диск после отвала одного (или более) основных?
Т.е. условная вводная — «у нас не датацентр, а обычная серверная» некой компании, которая не может себе позволить две разных ветки электропитания, а в ИБП, вот незадача, внезапно умерли аккумуляторы (или они перестали держать нагрузку, так бывает, да :) И переоценивший собственное время автономной работы ИБП вырубился в момент, когда Windows только собиралась выключаться по команде управляющей программы :) )
Желательно, чтобы на ЛУНе лежал диск от виртуальной машины, и туда в момент падения что-то писалось. Совсем идеально, если ЛУН представлял собой кластерный том, на котором были вхдшки от нескольких виртуалок, но достаточно будет и одной-двух без кластера.
После этого интересны моменты —
1) вспомнит ли СХД после включения, что у неё был ребилд;
2) Останется ли LUN и файлы в нём;
3) при успехе п.2 проверить — что выжило, что нет, внутри vhd-шки из файлов, которые были там ранее. (например, сравнить контрольные суммы файлов. Ещё можно, чтобы одна из vhd была системным томом, допустим, Windows, загрузится ли? )
Т.е. условная вводная — «у нас не датацентр, а обычная серверная» некой компании, которая не может себе позволить две разных ветки электропитания, а в ИБП, вот незадача, внезапно умерли аккумуляторы (или они перестали держать нагрузку, так бывает, да :) И переоценивший собственное время автономной работы ИБП вырубился в момент, когда Windows только собиралась выключаться по команде управляющей программы :) )
Желательно, чтобы на ЛУНе лежал диск от виртуальной машины, и туда в момент падения что-то писалось. Совсем идеально, если ЛУН представлял собой кластерный том, на котором были вхдшки от нескольких виртуалок, но достаточно будет и одной-двух без кластера.
После этого интересны моменты —
1) вспомнит ли СХД после включения, что у неё был ребилд;
2) Останется ли LUN и файлы в нём;
3) при успехе п.2 проверить — что выжило, что нет, внутри vhd-шки из файлов, которые были там ранее. (например, сравнить контрольные суммы файлов. Ещё можно, чтобы одна из vhd была системным томом, допустим, Windows, загрузится ли? )
В вашем сценарии должно быть два ибп, даже если и нету двух вводов… и в этом случаи одновременный отказ обоих бп статистически маловероятен. После отказа одного бп, схд должна сбросить кеш записи на диски… если у вас один ИБП это ваш косяк.
Можем:-). Учитывая многочисленные пожелания, после статьи про нагрузочный тест сделаем еще Краш-тест 2.0, где учтем все пожелания. Спасибо!
А что вы хотите в этом случаи тестировать? абсолютно оторванный от реальности тест… Допустим в реальности пропало питание на обоих бп — в этом случаи данные не успели записаться и находятся в кеш памяти — сколько времени продержится батарея? если батарея умерла раньше чем восстановили полноценное питание вы проиграли. Скорее всего так и будет…
для тех, кто читает по диагонали:
смысл моего сценария не в том, что питание пропало, это ёжику понятно, что недописанная инфа пропадёт, а в том, что непосредственно перед пропаданием питалова вышел диск из массива, а в сам момент шёл ребилд массива! Под нагрузкой. В том числе RW.
И интересно, что произойдёт:
1 — ребилд продолжится с момента, на котором всё упало;
2 — ребилд начнётся заново;
3 — ребилд зафэйлится и массив развалится (например, похерились metadata);
4 — ребилд зафэйлится, но массив сохранится в статусе degraded и можно будет исправить ситуацию руками, например, перевоткнуть hot spare;
5 — ребилд пройдёт, но часть информации пропадёт (потому что писалось как раз в момент падения.) Теоретически невозможен — софт по идее, стремится к атомарности операций, но вот практика показывает, что возможно всё.
Вот и интересно, как именно софт СХД отработает такое.
И да кстати — а какой будет в этом случае статус hot spare диска, на который шёл ребилд — останется в массиве, сбросится обратно или зависнет в некоем промежуточном положении?
а насчёт
Лучше быть богатым и здоровым, чем бедным и больным :)
В конце концов, ИБП это лишь пример «правдоподобной» причины, почему такое может быть. Криворукий инженер, упавший со стремянки и вырвавший оба кабеля, менее правдоподобен, но не менее вероятен :)
смысл моего сценария не в том, что питание пропало, это ёжику понятно, что недописанная инфа пропадёт, а в том, что непосредственно перед пропаданием питалова вышел диск из массива, а в сам момент шёл ребилд массива! Под нагрузкой. В том числе RW.
И интересно, что произойдёт:
1 — ребилд продолжится с момента, на котором всё упало;
2 — ребилд начнётся заново;
3 — ребилд зафэйлится и массив развалится (например, похерились metadata);
4 — ребилд зафэйлится, но массив сохранится в статусе degraded и можно будет исправить ситуацию руками, например, перевоткнуть hot spare;
5 — ребилд пройдёт, но часть информации пропадёт (потому что писалось как раз в момент падения.) Теоретически невозможен — софт по идее, стремится к атомарности операций, но вот практика показывает, что возможно всё.
Вот и интересно, как именно софт СХД отработает такое.
И да кстати — а какой будет в этом случае статус hot spare диска, на который шёл ребилд — останется в массиве, сбросится обратно или зависнет в некоем промежуточном положении?
а насчёт
если у вас один ИБП это ваш косяк.
Лучше быть богатым и здоровым, чем бедным и больным :)
В конце концов, ИБП это лишь пример «правдоподобной» причины, почему такое может быть. Криворукий инженер, упавший со стремянки и вырвавший оба кабеля, менее правдоподобен, но не менее вероятен :)
Батарея нужна не для того, чтобы пережить отсутствие электричества, а для быстрого но корректного выключения СХД. Батарея держит около 10 минут. В течение этого времени система автоматически сбрасывает все содержимое кэша на локальные диски своего контроллера (там где ОС установлена), а потом мягко выключается. Сброс кэша (даже самого большого длится) 3-4 минуты, этот сценарий мы постоянно отрабатываем в лаборатории. Конечно, если поставить в СХД несколько терабайт кэша, то никакая батарея не поможет, но мы в наших СХД так, очевидно, не делаем.
Вы проверяете ванильные сценарии.
Поскольку у вас в архитектуре фигрирует sas, то для sas существует простой метод положить шину: каждое устройство открывает канал для передачи данных. Если устройство-дятел не закрывает каналы, то через N операций SASxN шина окажется заблокирована и потребуется bus reset. Если устройство-дятел настойчиво, то bus reset будет достаточно частым, чтобы словить таймауты (т.е. ошибки IO).
Ещё можно попробовать устроить дребезг контактов (т.е. втык/вытык) — не всякая система переживает такое.
Ну и на закуску — slow-lorry на массив работает офигенно. Диск, который не выдаёт никаких ошибок, но принимает запись со скоростью в 2-3 Мб/с. Удачи работать на таком массиве, так сказать.
Поскольку у вас в архитектуре фигрирует sas, то для sas существует простой метод положить шину: каждое устройство открывает канал для передачи данных. Если устройство-дятел не закрывает каналы, то через N операций SASxN шина окажется заблокирована и потребуется bus reset. Если устройство-дятел настойчиво, то bus reset будет достаточно частым, чтобы словить таймауты (т.е. ошибки IO).
Ещё можно попробовать устроить дребезг контактов (т.е. втык/вытык) — не всякая система переживает такое.
Ну и на закуску — slow-lorry на массив работает офигенно. Диск, который не выдаёт никаких ошибок, но принимает запись со скоростью в 2-3 Мб/с. Удачи работать на таком массиве, так сказать.
Ну и на закуску — slow-lorry на массив работает офигенно. Диск, который не выдаёт никаких ошибок, но принимает запись со скоростью в 2-3 Мб/с. Удачи работать на таком массиве, так сказать.
Некоторые современные СХД такие диски уже научились детектить и выплёвывать из массива со статусом «slow». Умеет ли конкретно эта — неизвестно. Вроде не заявлялось.
Но да, прикольный случай. Непонятно только, как его симулировать, это нужно где-то найти заведомо тормозной диск…
Sign up to leave a comment.
Краш-тесты СХД AERODISK ENGINE N2, проверка на прочность