Пустой ночной офис отзывался холодом. Шум серверов и ветер в холодных коридорах притупляли накрывающее чувство одиночества. Уставший от ослепляющего света монитора, он решил найти минутное освобождение в какао с маковыми сушками. Едва сделав шаг в сторону кофе-поинта, он почувствовал, как запускается ДГУ…
«Странно?!» подумал он, «Ведь, я сам отключил автоматический запуск ДГУ на АВР. Эх, надо было дизель в грунт сливать, так было бы надежнее. Хорошо, хоть оптику порубить догадался. Значит, все идет по плану.».
Вычислительные системы восстановили свою работу, но данные никуда передать так и не смогли, о чем громко сообщал Zabbix.
Еще полкружки какао, «Скоро все закончится».
К монотонному завыванию системы мониторинга, начали присоединятся звонки телефонов, с каждым глотком какао их становилось все больше и больше. Наверное, в центре поддержки жизнедеятельности бункера начались сбои.
«Забавно, что к шлюзовым перегородкам можно было получить доступ с моего рабочего места. Почему местная служба безопасности не предусмотрела возможность саботажа?».
Какао почти закончилось, сушки он так есть и не стал, «Ненавижу мак.». Его бывшая любила мак. «Интересно, что бы она сейчас хотела больше, булочку с маком или воздуха еще хотя бы на полчаса? А остальная сотня человек в бункере?».
Сидеть в шуме сирен становилось невыносимо. Дыра в легком, оставленная сломанным ребром, тоже позитива не добавляла, начинался пневмоторакс. «Гребаный дурак, надо было ему пытаться мне помешать.».
Оставалась пара глотков. Хотел поставить кружку на стол, но выронил ее на пол. «Пора уходить.». Он чувствовал, что начинает задыхаться. Хоть он и не собирался дожить до завтра, «Чертова мутация!», но все равно заложенный природой страх перед асфиксией начал пробуждать панику.
Выбраться из здания ему все же удалось, хотя ему и пришлось последние метры ползти на четвереньках. «Какая ирония, в бункере, наверное, примерно тоже самое.».
Дальше ползти было бесполезно, все равно никуда не деться с этого проклятого острова. Возможно, последнего острова на Земле.
Синхронная репликация работает одинаково, что с включенным RAM-кэшом СХД, что с выключенным, поскольку не имеет к нему никакого отношения.
Не о том был вопрос. Попробуем снова. Когда есть кэш в оперативке контроллера СХД (пока одна хранилка без реплики), хосту прилетает подтверждение об удачной записи, как только данные попали в кэш, на диск они попадут несколько позже (но хосту уже на это пофиг). Когда есть реплика (но нет кэша), хосту прилетит подтверждение об удачной записи, когда данные запишутся на диски на обоих хранилках. А когда хост получит подтверждение о записи, если есть и реплика и кэши? Вижу такой вариант: хост -> кэш мастера -> кэш реплики -> подтверждение записи -> отложенная запись на диски мастера/реплики. Но тогда вы должны были реализовать репликацию кэшей хранилок. Вряд ли это так, и вы забыли об этом похвастаться? Тогда как?
Репликация работает с блочным устройством и «ничего не знает» о том, насколько актуальны данные в файловой системе ОС хоста.
Снова не про то. По вашим скриншотам видно, что реплика понимает, на сколько процентов она совпадает с оригиналом/мастером. Так вот, если процесс синхронизации еще не закончен (не важно по какой причина произошел рассинхрон) и умирает мастер, админа предупредят, что реплику до мастера поднимать не следует, это грозит потерей данных?
Как работает синхронная репликация при включенных кэшах на хранилках (кэши в оперативке контроллеров, а не на SSD каком-нибудь)? Хост получит подтверждение, как только на обоих хранилищах кэши среплицируются? Или как?
Как отреагирует хост, с которого льются данные на СХД, на падение реплики? Подвисанием записи, так как с реплики не приходят подтверждения? Какой таймаут ожидания ответа реплики?
Пускай случилась какая-то беда — рассинхрон, да еще и основная хранилка померла. Предупредит ли реплика, что на ней неактуальные данные, если ее попытаться сделать Мастером?
Да, я в курсе, не зря же я вам выше про 3,2 ГБ/с на два интерфейса писал (1,6 ГБ/с * 2). Просто значения очень близки к потолку пропускной способности, мало ли. А контроллеры СХД работают в пол силы. Так может стоило ввести в тестирование второй хост, чтобы еще IOPS-ов выжать? Может быть вы все уже проверили и померили, и больше от СХД не получить, ну тогда вопросов нет.
Скажите, пожалуйста, как вы на одном хосте с двумя FC 16 Гбит/с в тестах 2 и 3 получили пропускную способность более 5 ГБ/с? Ведь два FC 16G дают максимум 3,2 ГБ/с.
Сначала хотел описать идеальную схему, по которой нужно производить расчеты, но опять пришел к тому, что абсолютно теряется любое понимание какие формулы для этого подойдут, ибо схема зависимостей элементов сервера очень сложна. Я даже не готов описать в формулах (ну я и не математик, правда), например, разницу между надежностью RAID6 и RAID10 на шести дисках и одним диском в горячем резерве.
На чем я настаиваю, так это на том, что отказы не равномерны по времени. Не забываем про:
1) Брак. Зачастую по одной закупке приходят компоненты (жесткие диски, планки памяти и прочие расходники) из одной партии. И вся партия может полечь в первые же месяцы использования.
2) Износ. Все, что имеет подвижные элементы со временен начинает хуже работать. Если вы, конечно, в рамках ТО регулярно не заменяете смазку на осях вентиляторов, и еще чего-нибудь. Но ТО это простой оборудования, а значит понижение доступности, это тоже нужно учитывать в формулах.
3) Батареи. У RAID-контроллеров, у ИБП. Используете кэш на запись, но прозевали, когда сдохла батарея RAID-контроллера, получите потерю данных при непредвиденном отключении сервера. Хотя формально, контроллер не выходил из строя, данные потеряны, пока они восстанавливаются, сервер не доступен. 3-4 года для батарей ИБП, и он (ИБП) превращается просто в большой горячий сетевой фильтр.
4) Всякого рода смазки. Выгорание заводской термопасты, например, такое бывает на долго живущих серверах.
5) Накопление ошибок. В дисках, например. Идеально одинаковые диски с одинаковым MTTF проживут разное время в одиноком сервере или в сервере, набитом дисками, в стойке где таких серверов еще десяток. Вибрация сделает свое.
Ну вы поняли.
Вендоры могли бы изначально в своих «конфигураторах оборудования» предоставлять точные данные по каждому элементу и общие итоговые данные по сборке\комплекту
Не могли бы и не будут, об этом писал не один крупный производитель серверного оборудования (достаточно поискать по их форумам). Любой показатель MTTF – это чисто статистика, замещенная на ожидании. Это сферический, а не «точный» показатель, в реальности вмешиваются куча факторов, о которых я выше написал, и еще всякие не упомянутые. Поэтому одни (вендоры) боятся такие цифры обнародовать, другие (Uptime Institute) исключают показатели надежности из рассмотрения реальных систем, третьи (Google) пишет статьи/исследования о том, как все на самом деле с надежностью на примере жестких дисков.
И как здорово, что Заказчик даже не запаривается всем этим и ему достаточно хоть каких-то расчетов, которые он, вероятно, даже перепроверять не будет.
Интересная попытка расчета, но не убедительная.
Есть ряд вопросов (отчасти риторических) на примере первой таблицы для серверов 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, соответственно.
А что случится, если в расчет ввести электрические подстанции, ИБП, кондиционирование и провайдера?
Поймите правильно, я не пытаюсь вас подловить или завалить вопросами, просто сам пытался (не раз) произвести такие расчеты и ни разу не довел их до конца.
Здесь вы правы, но я не стал делать на этом акцент. Лишь на примере (не очень удачном, но) показал, что может случится так, что воспользоваться потенциально хорошим решением не получится, уткнувшись в проблем на этапе сборки. И да, вы не хотите в дальнейшем обзавестись сертификатом?
Вариант с компиляцией еще можно пережить, если есть доступ к репозиторию, либо много свободного времени и желания, чтобы побороть зависимости самостоятельно. Но вот хочу я, например, попробовать настроить резервное копирование на Astra Linux Special Edition, откуда компилятор выпилен и установить его нельзя. Было бы здорово иметь возможность разжиться бинарниками для таких, кхм, специфических дистрибутивов.
«Странно?!» подумал он, «Ведь, я сам отключил автоматический запуск ДГУ на АВР. Эх, надо было дизель в грунт сливать, так было бы надежнее. Хорошо, хоть оптику порубить догадался. Значит, все идет по плану.».
Вычислительные системы восстановили свою работу, но данные никуда передать так и не смогли, о чем громко сообщал Zabbix.
Еще полкружки какао, «Скоро все закончится».
К монотонному завыванию системы мониторинга, начали присоединятся звонки телефонов, с каждым глотком какао их становилось все больше и больше. Наверное, в центре поддержки жизнедеятельности бункера начались сбои.
«Забавно, что к шлюзовым перегородкам можно было получить доступ с моего рабочего места. Почему местная служба безопасности не предусмотрела возможность саботажа?».
Какао почти закончилось, сушки он так есть и не стал, «Ненавижу мак.». Его бывшая любила мак. «Интересно, что бы она сейчас хотела больше, булочку с маком или воздуха еще хотя бы на полчаса? А остальная сотня человек в бункере?».
Сидеть в шуме сирен становилось невыносимо. Дыра в легком, оставленная сломанным ребром, тоже позитива не добавляла, начинался пневмоторакс. «Гребаный дурак, надо было ему пытаться мне помешать.».
Оставалась пара глотков. Хотел поставить кружку на стол, но выронил ее на пол. «Пора уходить.». Он чувствовал, что начинает задыхаться. Хоть он и не собирался дожить до завтра, «Чертова мутация!», но все равно заложенный природой страх перед асфиксией начал пробуждать панику.
Выбраться из здания ему все же удалось, хотя ему и пришлось последние метры ползти на четвереньках. «Какая ирония, в бункере, наверное, примерно тоже самое.».
Дальше ползти было бесполезно, все равно никуда не деться с этого проклятого острова. Возможно, последнего острова на Земле.
«Ну хоть какао было вкусное!».
Не о том был вопрос. Попробуем снова. Когда есть кэш в оперативке контроллера СХД (пока одна хранилка без реплики), хосту прилетает подтверждение об удачной записи, как только данные попали в кэш, на диск они попадут несколько позже (но хосту уже на это пофиг). Когда есть реплика (но нет кэша), хосту прилетит подтверждение об удачной записи, когда данные запишутся на диски на обоих хранилках. А когда хост получит подтверждение о записи, если есть и реплика и кэши? Вижу такой вариант: хост -> кэш мастера -> кэш реплики -> подтверждение записи -> отложенная запись на диски мастера/реплики. Но тогда вы должны были реализовать репликацию кэшей хранилок. Вряд ли это так, и вы забыли об этом похвастаться? Тогда как?
Снова не про то. По вашим скриншотам видно, что реплика понимает, на сколько процентов она совпадает с оригиналом/мастером. Так вот, если процесс синхронизации еще не закончен (не важно по какой причина произошел рассинхрон) и умирает мастер, админа предупредят, что реплику до мастера поднимать не следует, это грозит потерей данных?
На чем я настаиваю, так это на том, что отказы не равномерны по времени. Не забываем про:
1) Брак. Зачастую по одной закупке приходят компоненты (жесткие диски, планки памяти и прочие расходники) из одной партии. И вся партия может полечь в первые же месяцы использования.
2) Износ. Все, что имеет подвижные элементы со временен начинает хуже работать. Если вы, конечно, в рамках ТО регулярно не заменяете смазку на осях вентиляторов, и еще чего-нибудь. Но ТО это простой оборудования, а значит понижение доступности, это тоже нужно учитывать в формулах.
3) Батареи. У RAID-контроллеров, у ИБП. Используете кэш на запись, но прозевали, когда сдохла батарея RAID-контроллера, получите потерю данных при непредвиденном отключении сервера. Хотя формально, контроллер не выходил из строя, данные потеряны, пока они восстанавливаются, сервер не доступен. 3-4 года для батарей ИБП, и он (ИБП) превращается просто в большой горячий сетевой фильтр.
4) Всякого рода смазки. Выгорание заводской термопасты, например, такое бывает на долго живущих серверах.
5) Накопление ошибок. В дисках, например. Идеально одинаковые диски с одинаковым MTTF проживут разное время в одиноком сервере или в сервере, набитом дисками, в стойке где таких серверов еще десяток. Вибрация сделает свое.
Ну вы поняли.
Не могли бы и не будут, об этом писал не один крупный производитель серверного оборудования (достаточно поискать по их форумам). Любой показатель MTTF – это чисто статистика, замещенная на ожидании. Это сферический, а не «точный» показатель, в реальности вмешиваются куча факторов, о которых я выше написал, и еще всякие не упомянутые. Поэтому одни (вендоры) боятся такие цифры обнародовать, другие (Uptime Institute) исключают показатели надежности из рассмотрения реальных систем, третьи (Google) пишет статьи/исследования о том, как все на самом деле с надежностью на примере жестких дисков.
И как здорово, что Заказчик даже не запаривается всем этим и ему достаточно хоть каких-то расчетов, которые он, вероятно, даже перепроверять не будет.
Есть ряд вопросов (отчасти риторических) на примере первой таблицы для серверов DL980 (я так понял у вас их два):
Поймите правильно, я не пытаюсь вас подловить или завалить вопросами, просто сам пытался (не раз) произвести такие расчеты и ни разу не довел их до конца.