Comments 4
Интересная попытка расчета, но не убедительная.
Есть ряд вопросов (отчасти риторических) на примере первой таблицы для серверов DL980 (я так понял у вас их два):
Поймите правильно, я не пытаюсь вас подловить или завалить вопросами, просто сам пытался (не раз) произвести такие расчеты и ни разу не довел их до конца.
Есть ряд вопросов (отчасти риторических) на примере первой таблицы для серверов DL980 (я так понял у вас их два):
- Вероятно, один сервер резервирует второй, иначе как объяснить, что вы замесили два серверных шасси (строка № 1 в таблице) в формулу дублирования Md. Отсюда первый вопрос, если догадка про резервирование серверов верна, почему вы не посчитали вероятность выхода из строя (Р) сначала для одного сервера (учитывая все его компоненты), а потом не подставили эту Р в формулу Md? Ибо сейчас кажется, что у вас каша из компонентов для двух серверов.
- У вас два набора по четыре процессора (строка № 2 в таблице). Это значит по четыре проца на шасси, или все же 8 процов на шасси? В любом случае, откуда появилось дублирование у процессоров? Ведь выход из строя хотя бы одного процессора приводит к циклическому перезапуску сервера, что приводит к простою сервера. В пределах одного сервера нет резервирования по процессорам, а вероятность выхода из строя всего сервера тем выше, чем больше в нем процессоров.
- Примерно тоже самое и с памятью (№ 3). Дублирования память в пределах сервера может быть только если используется зеркалирование памяти, но DL980 таким фокусам не обучен. Хоть потеря планки памяти и приведет только к перезагрузке сервера, а не полной его потере (как в случае с процессором). Тем не менее, надежность сервера тем ниже, чем больше планок памяти. К тому же в какой-то момент (после потери одной, двух или больше планок) перестанет запускаться целевая задача (база данных или виртуалки), так как ей перестанет хватать ресурсов (оперативки).
- Жесткие диски (№ 5). Всего шесть дисков на сервер? При этом 2 дублируются? У вас массив уровня RAID 5? Иначе не понятно, как такие цифры получились. Сюда же вопрос про RAID-контроллер, он у вас есть? Если есть, и он навернулся, потеряли сервер.
- Сетевые карты (№ 7). У вас интерфейсы в группе (bonding, teaming, прочее), раз вы посчитали дублирование?
- Еще вы забыли блоки вентиляторов. Если вы правильно собрали сервер, их суммарной эффективности хватает, чтобы сервер не перегрелся после выхода из строя первого же вентилятора. Но опять же, 2-3 вентилятора засбоят, и ваш сервер перестанет запускаться.
- Заявление о том, что «отказы компонентов обычно распределены во времени равномерно», особенно из расчета эффективного времени работы системы 10 лет, мягко говоря ошибочно.
- Если вы под IT-системой подразумеваете аппаратно-программный комплекс в целом, а не только аппаратную платформу под какие-либо задачи, то не стоит забывать про вероятность ошибок в ОС и прочем софте, что тоже приведет к простою системы. Именно поэтому Uptime Institute еще в 2009 году убрала из требований к уровням Teir показатели availability и annual downtime, соответственно.
- А что случится, если в расчет ввести электрические подстанции, ИБП, кондиционирование и провайдера?
Поймите правильно, я не пытаюсь вас подловить или завалить вопросами, просто сам пытался (не раз) произвести такие расчеты и ни разу не довел их до конца.
Спасибо за столь обширные вопросы.
Данный расчет делался для соответствия пункта ТЗ и согласования с Заказчиком проектной документации.
В расчете, как Вы справедливо заметили, не затрагиваются многие нюансы технической (физической и логической) архитектуры системы.
Но по требованию Заказчика в данном случае хватало списка оборудования системы из спецификации.
Вероятно, один сервер резервирует второй, иначе как объяснить, что вы замесили два серверных шасси (строка № 1 в таблице) в формулу дублирования Md. Отсюда первый вопрос, если догадка про резервирование серверов верна, почему вы не посчитали вероятность выхода из строя (Р) сначала для одного сервера (учитывая все его компоненты), а потом не подставили эту Р в формулу Md? Ибо сейчас кажется, что у вас каша из компонентов для двух серверов.
На самом деле этих серверов четыре — 2 на основной площадке и 2 на резервной, данный расчет для одной площадки.
С процессорами\памятью\дисками\сетевыми картами тут, конечно, не все так просто. Лучше использовать вариант, что часть элементов находится в ЗИП и их можно будет оперативно при остановке сервера для замены. Системы диагностики могут предупреждать, что такая ситуация может наступить скоро или по факту.
Еще вы забыли блоки вентиляторов. Если вы правильно собрали сервер, их суммарной эффективности хватает, чтобы сервер не перегрелся после выхода из строя первого же вентилятора. Но опять же, 2-3 вентилятора засбоят, и ваш сервер перестанет запускаться.
Вентиляторы как и прочее встроенное оборудование должны обслуживаться и проходить тестирование. Так же в ЗИП нужно иметь несколько их.
Заявление о том, что «отказы компонентов обычно распределены во времени равномерно», особенно из расчета эффективного времени работы системы 10 лет, мягко говоря ошибочно.
7 лет работы 4 серверов 365*24*7 — 4 HDD и 2 планки памяти, ежегодное обслуживание. Тут смотря какой вендор, обслуживание и окружающая среда.
Если вы под IT-системой подразумеваете аппаратно-программный комплекс в целом, а не только аппаратную платформу под какие-либо задачи, то не стоит забывать про вероятность ошибок в ОС и прочем софте, что тоже приведет к простою системы. Именно поэтому Uptime Institute еще в 2009 году убрала из требований к уровням Teir показатели availability и annual downtime, соответственно.
В данном случае ОС и софт уже немного в другой лиге у нас по ГОСТ.
А что случится, если в расчет ввести электрические подстанции, ИБП, кондиционирование и провайдера?
Получить данные от представителя услуг (электрокомпании\провайдера) в нужном для нас формате не получится. Тут только можем добавить какое устройство стоит у провайдера в нашу сторону, например. И то это обычно можно сделать только физическим путем наглядно.
И данные по этому устройству добавить в таблицу. По ИБП и АКБ проще — данные есть у вендоров.
Поймите правильно, я не пытаюсь вас подловить или завалить вопросами, просто сам пытался (не раз) произвести такие расчеты и ни разу не довел их до конца.
Расчеты и данные тут очень «абстрактны» — так как их можно корректировать в нужную сторону.
По факту нужно делать матрицу из коэффициентов готовности по оборудованию с дублирующими элементами, внешнему оборудованию и питанию, дополнительным элементам. Чем больше компонентов будет в расчете, тем более точен он может быть по факту. Но тем меньше по времени работы будет итог.
Вендоры могли бы изначально в своих «конфигураторах оборудования» предоставлять точные данные по каждому элементу и общие итоговые данные по сборке\комплекту.
Но так как обычно в системах «сборная солянка» из оборудования и элементов — это не делается кем то снаружи, может только понимающий все элементы систем сотрудник выполнить расчет.
Данный расчет делался для соответствия пункта ТЗ и согласования с Заказчиком проектной документации.
В расчете, как Вы справедливо заметили, не затрагиваются многие нюансы технической (физической и логической) архитектуры системы.
Но по требованию Заказчика в данном случае хватало списка оборудования системы из спецификации.
Вероятно, один сервер резервирует второй, иначе как объяснить, что вы замесили два серверных шасси (строка № 1 в таблице) в формулу дублирования Md. Отсюда первый вопрос, если догадка про резервирование серверов верна, почему вы не посчитали вероятность выхода из строя (Р) сначала для одного сервера (учитывая все его компоненты), а потом не подставили эту Р в формулу Md? Ибо сейчас кажется, что у вас каша из компонентов для двух серверов.
На самом деле этих серверов четыре — 2 на основной площадке и 2 на резервной, данный расчет для одной площадки.
С процессорами\памятью\дисками\сетевыми картами тут, конечно, не все так просто. Лучше использовать вариант, что часть элементов находится в ЗИП и их можно будет оперативно при остановке сервера для замены. Системы диагностики могут предупреждать, что такая ситуация может наступить скоро или по факту.
Еще вы забыли блоки вентиляторов. Если вы правильно собрали сервер, их суммарной эффективности хватает, чтобы сервер не перегрелся после выхода из строя первого же вентилятора. Но опять же, 2-3 вентилятора засбоят, и ваш сервер перестанет запускаться.
Вентиляторы как и прочее встроенное оборудование должны обслуживаться и проходить тестирование. Так же в ЗИП нужно иметь несколько их.
Заявление о том, что «отказы компонентов обычно распределены во времени равномерно», особенно из расчета эффективного времени работы системы 10 лет, мягко говоря ошибочно.
7 лет работы 4 серверов 365*24*7 — 4 HDD и 2 планки памяти, ежегодное обслуживание. Тут смотря какой вендор, обслуживание и окружающая среда.
Если вы под IT-системой подразумеваете аппаратно-программный комплекс в целом, а не только аппаратную платформу под какие-либо задачи, то не стоит забывать про вероятность ошибок в ОС и прочем софте, что тоже приведет к простою системы. Именно поэтому Uptime Institute еще в 2009 году убрала из требований к уровням Teir показатели availability и annual downtime, соответственно.
В данном случае ОС и софт уже немного в другой лиге у нас по ГОСТ.
А что случится, если в расчет ввести электрические подстанции, ИБП, кондиционирование и провайдера?
Получить данные от представителя услуг (электрокомпании\провайдера) в нужном для нас формате не получится. Тут только можем добавить какое устройство стоит у провайдера в нашу сторону, например. И то это обычно можно сделать только физическим путем наглядно.
И данные по этому устройству добавить в таблицу. По ИБП и АКБ проще — данные есть у вендоров.
Поймите правильно, я не пытаюсь вас подловить или завалить вопросами, просто сам пытался (не раз) произвести такие расчеты и ни разу не довел их до конца.
Расчеты и данные тут очень «абстрактны» — так как их можно корректировать в нужную сторону.
По факту нужно делать матрицу из коэффициентов готовности по оборудованию с дублирующими элементами, внешнему оборудованию и питанию, дополнительным элементам. Чем больше компонентов будет в расчете, тем более точен он может быть по факту. Но тем меньше по времени работы будет итог.
Вендоры могли бы изначально в своих «конфигураторах оборудования» предоставлять точные данные по каждому элементу и общие итоговые данные по сборке\комплекту.
Но так как обычно в системах «сборная солянка» из оборудования и элементов — это не делается кем то снаружи, может только понимающий все элементы систем сотрудник выполнить расчет.
Сначала хотел описать идеальную схему, по которой нужно производить расчеты, но опять пришел к тому, что абсолютно теряется любое понимание какие формулы для этого подойдут, ибо схема зависимостей элементов сервера очень сложна. Я даже не готов описать в формулах (ну я и не математик, правда), например, разницу между надежностью RAID6 и RAID10 на шести дисках и одним диском в горячем резерве.
На чем я настаиваю, так это на том, что отказы не равномерны по времени. Не забываем про:
1) Брак. Зачастую по одной закупке приходят компоненты (жесткие диски, планки памяти и прочие расходники) из одной партии. И вся партия может полечь в первые же месяцы использования.
2) Износ. Все, что имеет подвижные элементы со временен начинает хуже работать. Если вы, конечно, в рамках ТО регулярно не заменяете смазку на осях вентиляторов, и еще чего-нибудь. Но ТО это простой оборудования, а значит понижение доступности, это тоже нужно учитывать в формулах.
3) Батареи. У RAID-контроллеров, у ИБП. Используете кэш на запись, но прозевали, когда сдохла батарея RAID-контроллера, получите потерю данных при непредвиденном отключении сервера. Хотя формально, контроллер не выходил из строя, данные потеряны, пока они восстанавливаются, сервер не доступен. 3-4 года для батарей ИБП, и он (ИБП) превращается просто в большой горячий сетевой фильтр.
4) Всякого рода смазки. Выгорание заводской термопасты, например, такое бывает на долго живущих серверах.
5) Накопление ошибок. В дисках, например. Идеально одинаковые диски с одинаковым MTTF проживут разное время в одиноком сервере или в сервере, набитом дисками, в стойке где таких серверов еще десяток. Вибрация сделает свое.
Ну вы поняли.
Не могли бы и не будут, об этом писал не один крупный производитель серверного оборудования (достаточно поискать по их форумам). Любой показатель MTTF – это чисто статистика, замещенная на ожидании. Это сферический, а не «точный» показатель, в реальности вмешиваются куча факторов, о которых я выше написал, и еще всякие не упомянутые. Поэтому одни (вендоры) боятся такие цифры обнародовать, другие (Uptime Institute) исключают показатели надежности из рассмотрения реальных систем, третьи (Google) пишет статьи/исследования о том, как все на самом деле с надежностью на примере жестких дисков.
И как здорово, что Заказчик даже не запаривается всем этим и ему достаточно хоть каких-то расчетов, которые он, вероятно, даже перепроверять не будет.
На чем я настаиваю, так это на том, что отказы не равномерны по времени. Не забываем про:
1) Брак. Зачастую по одной закупке приходят компоненты (жесткие диски, планки памяти и прочие расходники) из одной партии. И вся партия может полечь в первые же месяцы использования.
2) Износ. Все, что имеет подвижные элементы со временен начинает хуже работать. Если вы, конечно, в рамках ТО регулярно не заменяете смазку на осях вентиляторов, и еще чего-нибудь. Но ТО это простой оборудования, а значит понижение доступности, это тоже нужно учитывать в формулах.
3) Батареи. У RAID-контроллеров, у ИБП. Используете кэш на запись, но прозевали, когда сдохла батарея RAID-контроллера, получите потерю данных при непредвиденном отключении сервера. Хотя формально, контроллер не выходил из строя, данные потеряны, пока они восстанавливаются, сервер не доступен. 3-4 года для батарей ИБП, и он (ИБП) превращается просто в большой горячий сетевой фильтр.
4) Всякого рода смазки. Выгорание заводской термопасты, например, такое бывает на долго живущих серверах.
5) Накопление ошибок. В дисках, например. Идеально одинаковые диски с одинаковым MTTF проживут разное время в одиноком сервере или в сервере, набитом дисками, в стойке где таких серверов еще десяток. Вибрация сделает свое.
Ну вы поняли.
Вендоры могли бы изначально в своих «конфигураторах оборудования» предоставлять точные данные по каждому элементу и общие итоговые данные по сборке\комплекту
Не могли бы и не будут, об этом писал не один крупный производитель серверного оборудования (достаточно поискать по их форумам). Любой показатель MTTF – это чисто статистика, замещенная на ожидании. Это сферический, а не «точный» показатель, в реальности вмешиваются куча факторов, о которых я выше написал, и еще всякие не упомянутые. Поэтому одни (вендоры) боятся такие цифры обнародовать, другие (Uptime Institute) исключают показатели надежности из рассмотрения реальных систем, третьи (Google) пишет статьи/исследования о том, как все на самом деле с надежностью на примере жестких дисков.
И как здорово, что Заказчик даже не запаривается всем этим и ему достаточно хоть каких-то расчетов, которые он, вероятно, даже перепроверять не будет.
На чем я настаиваю, так это на том, что отказы не равномерны по времени. Не забываем про:
Вы неправильно настаиваете. Расчеты надежности на MTBF берут за основу модель отказов "ванны" и выделяют из нее область постоянной вероятности отказов. Есть еще "детская смертность" слева и износ справа, — для этих областей расчет надежности никто не делает.
Таким образом полученные с помощью расчетов цифры имеют смысл только в при таких условиях (по вашим же пунктам):
1) Прошел период детской смертности — т.е. исключены возможные браки в производстве. В случае критически важных систем это достигается "burn-in" тестами. В обычном случае — через определенное время эксплуатации.
2) 3) 4) Все изнашивающиеся элементы — вентиляторы, батареи, смазки, жесткие диски периодически проходят ТО и заменяются согласно регламенту производителя до того, как они входят в фазу "износа"
И только в случае если все эти условия выполнены, можно считать, что вероятность отказов равномерна во времени и можно производить расчет MTBF.
Не могли бы и не будут, об этом писал не один крупный производитель серверного оборудования (достаточно поискать по их форумам). Любой показатель MTTF – это чисто статистика, замещенная на ожидании. Это сферический, а не «точный» показатель, в реальности вмешиваются куча факторов, о которых я выше написал, и еще всякие не упомянутые. Поэтому одни (вендоры) боятся такие цифры обнародовать, другие (Uptime Institute) исключают показатели надежности из рассмотрения реальных систем, третьи (Google) пишет статьи/исследования о том, как все на самом деле с надежностью на примере жестких дисков.
На самом деле цифра MTBF достаточно легко измеряемая, если у вендора есть достаточно большой парк изделий одного типа в эксплуатации и он может четко определить сколько часов эксплуатировалось каждое изделие, занимается самостоятельным ремонтом своих изделий и может отделить дефекты, произошедшие по вине пользователя от внутренних дефектов.
Так как основная статистика ведется на основе изделий, поступающих в ремонт, она будет постоянно обновляться, что обычно и влечет за собой необходимость делать запрос производителю для получения актуальной информации. Ну и некоторые статистику не ведут вообще. Поэтому и цифр никаких не дадут.
Sign up to leave a comment.
Пример расчета «коэффициента готовности» для IT-системы