![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Отказоустойчивость и теория вероятности
А вот скажите, где бы почитать про первый сабж в совокупности со вторым?
А то я не совсем соображу, как работают с вероятностями событий типа "винт накрылся", если у нас есть только характеристики типа MTBF, а распределение вероятности сдохнуть в течение жизни винта я не знаю, причем не только количественно но и качественно (хотя и очевидно, что с временем эта вероятность нарастает, а MTBF это что-то вроде середины в оном распределении).
Хочу количественно сравнить разные варианты решения проблемы отказоустойчивости в случае "простой системы на 10-20 минут в день всем пофиг, но данные после физически выполненной операции терять неприемлемо, и желательно чтобы данные восстанавливались автоматически". Плюс еще иногда выполняемая автоматическая репликация этих данных на другой сервер, но канал связи с этим сервером есть не всегда, поэтому использовать его в качестве резервного нельзя, а репликация в случае умирания и восстановления одной из баз не должна нарушаться.
Что-то мне подсказывает, что я пытаюсь решать самодельными техническими средствами проблемы, которые нужно решатьжесточайшими пиздюлями персоналу выключающему компыорганизационными методами и покупкой надежного оборудования и софта. То бишь 1000 баксов на софт+10000 на сервер+100000 на оракл.
А то я не совсем соображу, как работают с вероятностями событий типа "винт накрылся", если у нас есть только характеристики типа MTBF, а распределение вероятности сдохнуть в течение жизни винта я не знаю, причем не только количественно но и качественно (хотя и очевидно, что с временем эта вероятность нарастает, а MTBF это что-то вроде середины в оном распределении).
Хочу количественно сравнить разные варианты решения проблемы отказоустойчивости в случае "простой системы на 10-20 минут в день всем пофиг, но данные после физически выполненной операции терять неприемлемо, и желательно чтобы данные восстанавливались автоматически". Плюс еще иногда выполняемая автоматическая репликация этих данных на другой сервер, но канал связи с этим сервером есть не всегда, поэтому использовать его в качестве резервного нельзя, а репликация в случае умирания и восстановления одной из баз не должна нарушаться.
Что-то мне подсказывает, что я пытаюсь решать самодельными техническими средствами проблемы, которые нужно решать
no subject
вашу мать.
Что у вас там за мега-задачи которые нельзя регулярным ночным бэкапом за несколько сотен баксов решить?
Вычислительный центр Беларусь банка? Белаз? Белкалий? Впрочем последние два на MSSQL на моей памяти.
У нас тут немелкие заводы случается на интербэйзах видеть - и ничего.
no subject
Если шо, оно сейчас так и работает - с регулярными бэкапами и тому подобным. За последние 12 лет финансовые данные ни разу не терялись, но вот ебля с восстановлением эмпирическими методами пару раз была.
А я хочу сделать, чтобы а) восстанавливалось само б) без вуду-знаний
no subject
Вы их не сразу комитите?
Херится база, которая реплицируется раз в час?
Херится веник?
no subject
1) Комп в процессе работы выключают из сети или нажимают резет. Ставить базу на другой комп - нельзя по условиям сертификации и бессмысленно, т.к. другой будут выключать еще чаще. УПС поможет, но только в том случае, если не вырвут провод прямо из упса.
2) Может похерится веник.
Задача - не потерять закомиченные данные.
no subject
2) RAID
вуаля
no subject
no subject
PS Что у вас там за вандализм такой что провода прямо из компа дёргают? Бухгалтерам чайник некуда включить?
no subject
no subject
Пару раз наказать - и все будет в порядке. Для доказательной базы поставить видеонаблюдение с записью.
no subject
1. Купить фулл-тавер, привинтить упс внутри.
2. Таки райд. Либо две базы.
no subject
Хм... такте ощущение что сервер стоит прям рядом с бухгалтером и УПСов там нет.
Первейшие организационные методы
- помещение серверной с максимально ограниченным доступом
- отдельный выделенный сервер стоящий в серверной
- УПС
Это первейшие минимальные орг. действия.
Любые другие без этих первых - бессмысленны.
no subject
2) Система по условиям использования и сертификации стоит в одном единственном опечатанном компе, т.е. сервер ставить отдельный нельзя.
ну и прочая, и прочая. В общем, я ж пишу - адовы условия.
(no subject)
(no subject)
(no subject)
no subject
А кто вам тогда разрешит менять железо и раскидывать данные по другим железкам?
Задача поставлена некорректно.
"Серверная" - это может быть отгороженный гипсокартоном угол, но обязательно с дверью пол замком.
no subject
no subject
no subject
УПС не поможет, т.к. провод вырвут из компа.
no subject
no subject
и пусть вырывают :)
no subject
no subject
no subject
no subject
no subject
no subject
(no subject)
no subject
2 metaclass - ребе, сейчас пороюсь в загашниках, была одна интересная статья именно о винтах и рейдах