Pull to refresh

Comments 6

В тот момент, когда ваш ответ на DR — это кластеризация приложения, то всё, прощай бизнес. Он работает до ближайшего залётного дятла.


DR должна обеспечивать восстановление после отказа, а не снижение вероятности отказа. Кластер повышает надёжность, но не даёт ничего для DR (кроме замедления самой процедуры).


Пример disaster:


DELETE * from main_table;
WHERE client_id="test";

Сколько кластеров надо, чтобы от такого disaster спасти? 200 active-active нод хватит? 400? 600? 65535?

Кластеризация в этом контексте — это инструмент для улучшения RTO, с которого можно начать, а не полноценное DR-решение. В статье я сразу указываю, что для защиты от человеческого фактора надо делать бэкап — от него никто не застрахован.

Использование кластеризации увеличивает время восстановления (поднять одинокую СУБД из бэкапа быстрее и проще, чем разлить бэкап по СУБД из мастера и трёх реплик). Кластеризация исключает или смягчает часть отказов, но в контексте DR — это источник замедления.


Простое доказательство:


Сценарий 1: У вас 1С на компьютере у бухгалтера с локальным логином, с него раз в час делается бэкап на ленточный накопитель. Размер диска бухгалтера 250Гб.
Сценарий 2: У вас 1С на терминальном сервере (active и backup, системные диски — 500Гб), она работает с MSSQL в кластере (3 сервера по 1Тб), под управлением AD (два сервера по 500Гб). Пользователи подключаются с тонких клиентов, загрузка по PXE. Бэкап всего раз в час.


В обоих случаях случается большой D, после чего всё оборудование выходит из строя. Новое оборудование ставится за константное время (допустим).


Вопрос: в каком сценарии DR время восстановления до рабочего состояния будет меньше?

Примеры хорошие, все сильно зависит от рисков, которые мы хотим предупредить. Для локальной “одинэски” и популярного интернет-магазина в облаке мы по-разному оценим угрозы и порекомендуем разные варианты защиты.

Возможно, словосочетание DR в этой статье немного сбивает с толку. Я хотел показать, что даже небольшая компания без DR-плана может воспользоваться знаниями о послеаварийной защите и подумать о собственных рисках. Кому-то важно подняться за секунды, кому-то — взять не самое дорогое и быстрое решение, но сохранить все данные. Среди моих клиентов встречаются оба варианта.

Когда обслуживающая компания предлагает решения по восстановлению, какая ответственность предполагается в договоре, если данные восстановить не удастся? Это же должно быть как-то указано? Есть какие-нибудь примеры?

Если говорить про наши услуги как сервис-провайдера, мы несем финансовую ответственность перед клиентом. Конкретные условия прописываем отдельно в каждом договоре.
Sign up to leave a comment.