|
|
|
|
Железный канал: «Информационная безопасность в офисе.» |
|
|
|
Fantom
 222 EGP
 
Рейтинг канала: 6(257)
Репутация: 31
Сообщения: 1367
Откуда: Иркутск
Зарегистрирован: 04.07.2003
  |
|
"Автоматизировать этот процесс стремно, но при правильном подходе можно сократить время ручного переключения до единиц минут"
кхм... вложу свои скромные пять злотых, а если делается постоянное фоновое копирование с подменой всего сервера в случае ЧС - это не оно, случаем?
Просто очень давно-давно когда-то, видел этаких "сиамских близнецов" с пуповиной нуль-модема 
_________________
Деньги есть - ума не надо... |
|
|
|
Voha
 930 EGP
        
Рейтинг канала: 9(1038)
Репутация: 167
Сообщения: 4920
Откуда: Moscow, Russia
Зарегистрирован: 15.02.2001
|
|
| Fantom : |
"Автоматизировать этот процесс стремно, но при правильном подходе можно сократить время ручного переключения до единиц минут"
кхм... вложу свои скромные пять злотых, а если делается постоянное фоновое копирование с подменой всего сервера в случае ЧС - это не оно, случаем?
Просто очень давно-давно когда-то, видел этаких "сиамских близнецов" с пуповиной нуль-модема
|
Все решения похожи принципом - нужно иметь стенд-бай с актуальной копией рабочей базы и быстро на него переключиться. Все проблемы начинаются на этапе претворения этого очевидного принципа в жизнь 
Как гарантировать "актуальность" копии?
Как определить, что "главный" сдох?
Как определить это максимально быстро?
А что делать, если главный "моргает" - вот он есть, а вот его нет, а вот опять есть?
А как гарантировать защиту от глюков, если мы уже переключились на стенд-бай, а "главный" внезапно ожил?
ну и т.д.
_________________
Time will show... |
|
|
|
Снуч
941 EGP
Рейтинг канала: 5(100)
Репутация: 232
Сообщения: 2696
Откуда: Ракслатенон
Зарегистрирован: 09.08.2005
|
|
| Voha : |
Как гарантировать "актуальность" копии?
Как определить, что "главный" сдох?
Как определить это максимально быстро?
А что делать, если главный "моргает" - вот он есть, а вот его нет, а вот опять есть?
А как гарантировать защиту от глюков, если мы уже переключились на стенд-бай, а "главный" внезапно ожил?
|
а нельзя избавится от главного вообще? то есть сделать два главных - два близнеца, работающих синхронно, которым все равно, кто из них главный, если нет необходимости восстановить данные после остановки, и пусть работают по принципу: кто стабильно пашет/кто вообще пашет в данный момент - тот и главный? тогда при выключении одного из серверов, второй продолжает работу, когда же отключившийся оживает, то сначала подкачивает/включается в работу, что автоматически делает его неглавным. Если сбой на обоих - тогда, да, тогда тяжко, но ведь вероятность такого события крайне мала, а чтобы её ещё уменьшить, то просто увеличиваешь количество таких серверов-близнецов, третий из которых вообще может никогда не будет главным (тьху-тьху-тьху).
Последний раз редактировалось: Снуч (13:33 29-04-2010), всего редактировалось 4 раз(а) |
|
|
|
Voha
930 EGP
Рейтинг канала: 9(1038)
Репутация: 167
Сообщения: 4920
Откуда: Moscow, Russia
Зарегистрирован: 15.02.2001
|
|
| Снуч : |
|
а нельзя избавится от главного вообще?
|
| Voha : |
|
С записью хуже - конструкции типа "мастер-мастер" вызывают множество гемора проблемами неуникальных индексов.
|
_________________
Time will show... |
|
|
|
Minx
978 EGP
    
Рейтинг канала: 2(19)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| бухой джедай : |
|
засчита оборудования на Котором стоит БД от разнообразных неприятностей(капризы систкемы Электроснабюжения,ЭМИ,природная статика)
|
Копать в сторону ЭМС - электромагнитной совместимости. Это отдельное направление, занимающееся как раз этим самым. Т.е. защита от ЭМПомех, пропадания и сбоев питания (провалы, всплески напряжения и пр.), паразитные каналы проникновения. экранирование и т.д.
| Voha : |
|
Автоматизировать этот процесс стремно, но при правильном подходе можно сократить время ручного переключения до единиц минут.
|
При правильном подходе в серьезных системах переход производится так, что никаких функциональных изменений в системе не происходит. Т.е. она должна без каких-либо задержек/изменений и пр. выполнять боевую задачу.
Другое дело что это применяется только там, где это критично. На транспорте, в космосе и пр.. Там время переключения может составлять доли секунды либо вообще отсутствовать - горячий резерв управляет, выключая из строя главный комплект.
Если же взять например банковские системы БД - так там другая задача. Можно упасть, можно сгореть, все что угодно. Но данные должны выжить и их можно было бы восстановить в боевой системе за какое-то приемлемое время (например сутки).
Т.е. архитектура и особенности обеспечения безопасности и надежности функционирования зависят от постановки задачи.
| Voha : |
|
Как гарантировать "актуальность" копии?
|
В современных системах никто не гарантирует актуальность копии. В абсолютном большинстве случаев речь идет о вероятности сохранения копии. Т.е. если вероятность сбоя в одной копии за час 1/10, копии разнесены друг от друга так, что сбои и отказы независимы, то вероятность того, что за час накроется во всех трех копиях - 1/1000. И если гарантировать восстановление одной из них за час - то обеспечивается 1/1000 в каждый час бесконечного времени. Соответственно, в серьезных системах эту вероятность сводят к пренебрежимо малым величинам (скажем не более 1 сбоя за 20 лет).
| Voha : |
|
Как определить, что "главный" сдох?
|
Если два комплекта, то гарантированно вообще никак. Потому что если два комплекта работают по-разному, то невозможно определить кто из них прав.
Два комплекта чаще всего используют для холодного резерва.
Соответственно имеются мажорирующие системы 2 из 3 (3 из 5, 2+2), определяющие кто прав и выводящие неправого из работы.
| Voha : |
|
Как определить это максимально быстро?
|
Однозначно определить можно только по каким-то конечным функциональным зависимостям, которые должны быть синхронизированы. Имеются системы с синхронизацией по такту процессора, с периодической синхронизацией и с синхронизацией по неким внутренним программным циклам (приличным по компьютерным меркам временам - десятки и сотни мс).
| Voha : |
А что делать, если главный "моргает" - вот он есть, а вот его нет, а вот опять есть?
А как гарантировать защиту от глюков, если мы уже переключились на стенд-бай, а "главный" внезапно ожил?
|
Ничего. Если кто-то умер, то он умер или навсегда, или до тех пор, пока не придет обслуживающий персонал и не найдет проблему, исправит, протестирует вышедший из строя модуль. И только тогда - запуск.
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
бухой джедай
 182 EGP
Рейтинг канала: 4(87)
Репутация: 70
Сообщения: 7906 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
 |
|
люди
| Voha : |
Если от утраты по форс-мажору или криворукости - множественное резервирование в разных физических локациях. Количество локаций, методы резервирования, частота полных и инкрементальных бакапов определяются ценностью информации, и заданным максимальным временем простоя при потере основной машины.
Существуют решения, которые обеспечивают 100% 24х7 доступность базы по крайней мере на чтение. С записью хуже - конструкции типа "мастер-мастер" вызывают множество гемора проблемами неуникальных индексов. В общем случае простой "на запись" определяется временем переключения мастера на резерв. Автоматизировать этот процесс стремно, но при правильном подходе можно сократить время ручного переключения до единиц
минут.
|
шото из єтого я там по ссілочке уже чтото нашел просто надеялся что знаете где єто можно почитать ...
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист... |
|
|
|
Voha
930 EGP
Рейтинг канала: 9(1038)
Репутация: 167
Сообщения: 4920
Откуда: Moscow, Russia
Зарегистрирован: 15.02.2001
|
|
| Minx : |
| Voha : |
|
Автоматизировать этот процесс стремно, но при правильном подходе можно сократить время ручного переключения до единиц минут.
|
При правильном подходе в серьезных системах переход производится так, что никаких функциональных изменений в системе не происходит. Т.е. она должна без каких-либо задержек/изменений и пр. выполнять боевую задачу.
Другое дело что это применяется только там, где это критично. На транспорте, в космосе и пр.. Там время переключения может составлять доли секунды либо вообще отсутствовать - горячий резерв управляет, выключая из строя главный комплект.
|
Ты говоришь о другой задаче. Которая не имеет никакого отношения к сохранению консистентности данных при ЗАПИСИ в случае перемещения точки записи. Это, кстати, главная проблема при резервировании изменяющихся БД. О существовании которой, ты, похоже, не очень представляешь - поэтому и рассуждая далее про банковские БД, расставил приоритеты надежности очень странно...
| бухой джедай : |
|
просто надеялся что знаете где єто можно почитать ...
|
Нет, где читать не подскажу. Могу в личку подсказать с конкретными вопросами и применяемыми для конкретных задач софтовыми/хардовыми решениями для обеспечения сервисов 24х7 в ip-сетях.
_________________
Time will show... |
|
|
|
бухой джедай
182 EGP
Рейтинг канала: 4(87)
Репутация: 70
Сообщения: 7906 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
|
|
| Voha : |
|
Нет, где читать не подскажу. Могу в личку подсказать с конкретными вопросами и применяемыми для конкретных задач софтовыми/хардовыми решениями для обеспечения сервисов 24х7 в ip-сетях.
|
Слишком обьемные у меня запросы чтоб когото в личку терзать ... надо раздел диплома лепить (типа раздел по ГО) с подтемй "Сохранение и зашита БД в условиях черезвічайніх ситуаций "...
посему и ишу источники
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист... |
|
|
|
Fantom
222 EGP
Рейтинг канала: 6(257)
Репутация: 31
Сообщения: 1367
Откуда: Иркутск
Зарегистрирован: 04.07.2003
|
|
Кури внутрение регламенты ИТ департаментов
1. ЖД
2. Связистов
3. Банков
ЗЫ: в нашей стране есть ещё п.4. - "приход налоговой" 
_________________
Деньги есть - ума не надо... |
|
|
|
бухой джедай
182 EGP
Рейтинг канала: 4(87)
Репутация: 70
Сообщения: 7906 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
|
|
| Fantom : |
|
Кури внутрение регламенты ИТ департаментов
|
еслиб кто сказал где эти регламенты можно стырить ...
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист... |
|
|
|
|
|
|
|
|
Железный канал: «Информационная безопасность в офисе.» |
|
|
