Отказоустойчивость и теория вероятности
Sep. 3rd, 2010 06:36 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassА вот скажите, где бы почитать про первый сабж в совокупности со вторым?
А то я не совсем соображу, как работают с вероятностями событий типа "винт накрылся", если у нас есть только характеристики типа MTBF, а распределение вероятности сдохнуть в течение жизни винта я не знаю, причем не только количественно но и качественно (хотя и очевидно, что с временем эта вероятность нарастает, а MTBF это что-то вроде середины в оном распределении).
Хочу количественно сравнить разные варианты решения проблемы отказоустойчивости в случае "простой системы на 10-20 минут в день всем пофиг, но данные после физически выполненной операции терять неприемлемо, и желательно чтобы данные восстанавливались автоматически". Плюс еще иногда выполняемая автоматическая репликация этих данных на другой сервер, но канал связи с этим сервером есть не всегда, поэтому использовать его в качестве резервного нельзя, а репликация в случае умирания и восстановления одной из баз не должна нарушаться.
Что-то мне подсказывает, что я пытаюсь решать самодельными техническими средствами проблемы, которые нужно решатьжесточайшими пиздюлями персоналу выключающему компыорганизационными методами и покупкой надежного оборудования и софта. То бишь 1000 баксов на софт+10000 на сервер+100000 на оракл.
А то я не совсем соображу, как работают с вероятностями событий типа "винт накрылся", если у нас есть только характеристики типа MTBF, а распределение вероятности сдохнуть в течение жизни винта я не знаю, причем не только количественно но и качественно (хотя и очевидно, что с временем эта вероятность нарастает, а MTBF это что-то вроде середины в оном распределении).
Хочу количественно сравнить разные варианты решения проблемы отказоустойчивости в случае "простой системы на 10-20 минут в день всем пофиг, но данные после физически выполненной операции терять неприемлемо, и желательно чтобы данные восстанавливались автоматически". Плюс еще иногда выполняемая автоматическая репликация этих данных на другой сервер, но канал связи с этим сервером есть не всегда, поэтому использовать его в качестве резервного нельзя, а репликация в случае умирания и восстановления одной из баз не должна нарушаться.
Что-то мне подсказывает, что я пытаюсь решать самодельными техническими средствами проблемы, которые нужно решать
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-09-04 07:31 am (UTC)2) Система по условиям использования и сертификации стоит в одном единственном опечатанном компе, т.е. сервер ставить отдельный нельзя.
ну и прочая, и прочая. В общем, я ж пишу - адовы условия.
no subject
Date: 2010-09-04 09:01 am (UTC)Пусть будет не один комп а одна комната или один ящик. Закрытый и опломбированный.
no subject
Date: 2010-09-04 08:33 pm (UTC)no subject
Date: 2010-09-04 08:40 pm (UTC)А наезжать за по сути встроеный комп поидеи не должны, иначе народ с продвинутыми серверами (IPMI/iKVM) отгреб бы дополнительный гемморой за встроеный сервисный комп.