Большой компьютер = большие возможности, верно?
Например, можно климатическую модель всей Земли построить, или микробиом описать.
Но с большими возможностями также приходят и большие проблемы, и имя этим проблемам - MTBF.
Ведь есть же статистика, великая и ужасная.
Допустим, мы построим суперкомпьютер из очень хороших и надёжных узлов. У каждого из которых MTBF = 100 лет.
Если в машине 100 000 таких узлов, то ошибки будут возникать каждые 9 часов. Согласно той же статистике, среднее время работы HPC приложения меньше девяти часов, так что всё ок.
А если в машине этих узлов 1 000 000? Тогда ошибки будут возникать каждые 53 минуты. А сколько мы их исправлять будем?
Это не моя теория, а Донгарры с соавторами.
А вот табличка из практики:
Т.е. на практике среднее время наработки на отказ в 9 часов (даже чуть меньше, 8.93 ч.) мы уже прекрасно наблюдаем.
Пару дней назад я писал про облачный дата-центр DUG McCLOUD c 40 000 узлами. Как думаете, какой у него MTBF? Судя по тому, что в описании программного сейсмического кода пункт номер один - "Толерантность к отказам оборудования", а пункт номер три - "наличие контрольных точек" - они об отказоустойчивости на программном уровне думали серьезно.
Кстати, какое время сохранения контрольной точки? На больших системах сохранение чекпойнта занимает около 20-ти минут. Чем больше система - тем больше потребуется времени, если не совершенствовать технику. Тут уместно вспомнить предыдущие выкладки с отказом каждые 53 минуты и смоделировать совсем уж апокалиптический сценарий, когда время сохранения контрольной точки и восстановления после отказа будет больше MTBF. То есть система просто не будет успевать работать.
Выводы: Отказоустойчивость - это актуально. На всех уровнях, включая надёжное железо, системные библиотеки и чекпойнты (или другие методы промежуточного сохранения/репликации) в пользовательских приложениях.