А что вообще положено делать вам и вашим клиентам для того чтобы не убить данные в таком случае? Даунтайм понятно - это минус чуть-чуть упущенной прибыли, одноразово, форс-мажоры бывают, компенсировали, забыли.
Но "убились нахрен все данные клиентов" - это же печаль какая-то совсем. Ладно, предположим клиенты (наученные) делают бэкап себе, а с вашей стороны хоть какая-то техническая возможность избежать хотя бы повреждения FS есть?
С точки зрения виртуалок это всё было как "отключили по питанию".
А "потеря данных"... Я лично наблюдал клиента, который пытался убедить fsck сделать проверку для PV-тома на LVM. Такому ума хватит метаданные ext3 поверх метаданных LVM накатать.
Т.е. журнализация в файловых системах таки работает нормально, в смысле что они переживают отключение питания как положено, не умирая?
Просто я удолбался выяснять аналогичный вопрос про базы данных. По любой логике сбой питания - такая же проблема, как и все остальные, и соответственно транзакции после commit должны быть на диске и после включения их изменения будет видно. Но на практике возникают разнообразные вопросы вида "а рейд-контроллер ли у вас с батарейкой", "без UPS базы регулярно дохнут", т.е. практически базы данных не всегда переживают издевательство с выключением машин.
Ключевое: write cache. Отсюда требование батарейки. Если нет батарейки и есть write cache - то при фейле всего и вся теряется не только current state, но и некий произвольный кусок предыдущих. Не факт, что консистентый с точки зрения БД.
У нас потому SSD (RAID10 over SSD) для кеширования на запись и используется, чтобы в случае эпикфейла всего лишь продолжнить работу.
ад какойта ваще. как в анекдоте про бекапы: если люди, у которых нет резервного оборудования и сингле поенте оф фейлуре, а есть люди, которые думают, что у них есть резерф и все задублировано.
трасса была зарезервирована. По поводу резерва коммутатора - там было виртуальное шасси (т.е. кластер), которое из нескольких железок. Легло синхронно.
вот я и не понял, что помешает этому кластеру лечь синхронно еще раз.
окей, если трансиверы (или как они там) опять сдохнут, то вы их быстро замените, пользуясь наработанным опытом, но если опять произойдет что-то нештатное - все равно будуте тыкаться вслепую, ребутать и читать логи по два часа, что не гуд.
"Респект и уважуха", как принято говорить, за подробный рассказ что именно произошло. Познавательно.
P.S. Но вот зарекаться от отказов даже в новой супер-пупер СХД я не стал. Всякое бывает. Например отключение на секунду питания по всему ДЦ при переходе с одного ИБП на другой. Внезапно.
Давайте начнём с более простого: инженер перепутает шкаф и рубанёт стойку по обоим вводам.
Да, может быть. Я же говорю про конкретные мерзкие баги, которые я умудрился найти практически в каждой железке (драйвере) и даже в linux-raid (аж три дедлока).
Comments 23
Но "убились нахрен все данные клиентов" - это же печаль какая-то совсем. Ладно, предположим клиенты (наученные) делают бэкап себе, а с вашей стороны хоть какая-то техническая возможность избежать хотя бы повреждения FS есть?
Reply
А "потеря данных"... Я лично наблюдал клиента, который пытался убедить fsck сделать проверку для PV-тома на LVM. Такому ума хватит метаданные ext3 поверх метаданных LVM накатать.
Reply
Просто я удолбался выяснять аналогичный вопрос про базы данных. По любой логике сбой питания - такая же проблема, как и все остальные, и соответственно транзакции после commit должны быть на диске и после включения их изменения будет видно.
Но на практике возникают разнообразные вопросы вида "а рейд-контроллер ли у вас с батарейкой", "без UPS базы регулярно дохнут", т.е. практически базы данных не всегда переживают издевательство с выключением машин.
Reply
У нас потому SSD (RAID10 over SSD) для кеширования на запись и используется, чтобы в случае эпикфейла всего лишь продолжнить работу.
Reply
Reply
Reply
Reply
(The comment has been removed)
Reply
Reply
окей, если трансиверы (или как они там) опять сдохнут, то вы их быстро замените, пользуясь наработанным опытом, но если опять произойдет что-то нештатное - все равно будуте тыкаться вслепую, ребутать и читать логи по два часа, что не гуд.
Reply
Reply
P.S. Но вот зарекаться от отказов даже в новой супер-пупер СХД я не стал. Всякое бывает. Например отключение на секунду питания по всему ДЦ при переходе с одного ИБП на другой. Внезапно.
Reply
Да, может быть. Я же говорю про конкретные мерзкие баги, которые я умудрился найти практически в каждой железке (драйвере) и даже в linux-raid (аж три дедлока).
Reply
Reply
Reply
Leave a comment