Быстрое внедрение ERP Комплексные услуги
от 1С:Центр ERP!
Управление доставкой Для торговых и курьерских компаний!
1C:ЭДО Узнайте о всех преимуществах электронного документооборота!
Переход на «1С:ЗУП ред. 3» Фирма «1С» прекращает поддержку «1С:ЗУП 2.5»!
Аренда сервера 1С
в облаке
Работайте в 1С удаленно с экономией до 70%!

Что делать, если в разгар рабочего дня «сгорает» основной сервер с учетной программой? Или ломается интернет-маршрутизатор? Скорее всего, эти форс-мажоры приведут к долговременному простою в работе (от 1 до 2 суток) пока не удастся либо починить оборудование, либо закупить новое, либо найти что-нибудь на подмену. Однако таких простое можно легко избежать, если заранее продумать возможные риски и подготовиться к ним: подготовить планы аварийного восстановления (планы АВ).

Данные планы – являются нормой для зрелой ИТ-системы и зачастую неоправданно игнорируются на небольших предприятиях. Что же из себя представляет план АВ?

Рекомендуемые решения

ИТ-обслуживание



План АВ – это список возможных рисков в ИТ-инфраструктуре, приводящие к ее отказу и сценарии действий ИТ-персонала в случае наступления таких рисков.

А если по-простому – то это документ в котором описаны все возможные ситуации, которые могут случиться и последовательность действий ИТ-инженера в том или ином случае. Например, «сгорает» сервер 1С посреди дня. В таком случае ИТ-инженер активирует на другом сервере заранее установленную и настроенную 1С, разворачивает резервную копию базы и запускает туда пользователей. Получается, в данном случае время простоя будет четко регламентированным и будет составлять от 15 минут до пары часов, а не сутки (зависит от типа резервирования и размера копии базы). И самое главное всем участником понятно, что делать и не надо ничего экстренно придумывать и импровизировать!

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

Для каждого нашего клиента мы обязательно создаем такой план АВ, и в SLA фиксируем предельно допустимое время восстановление работоспособности сервисов. При этом план создается так, чтобы выполнять действия по нему можно было удаленно, это опять экономить время на перемещение сотрудника к клиенту. Каждые полгода обязательно проводиться учения по этим планам, чтобы убедиться в работоспособности сценариев и их актуальности.

Описанные планы аварийного восстановления вкупе с другими нашими разработками типа комплексной системы мониторинга, регламентными операциями, Канбаном и процессами ITIL позволяют нам оказывать более качественные ИТ-услуги чем большинство наших конкурентов.

Далее приведен пример плана аварийного восстановления для среднестатистического клиента:

1. Недоступен основной интернет-канал


Проблема: Недоступность интернет ресурсов

Решение: В случае недоступности основного интернет канала –GW1 заходим по ssh на второй сервер GW2 и переносим роль недоступного сервера на другой:

medray-gw - XXX.XXX.XXX.XXX внутренний ip 192.168.67.10
medray-voip - YYY.YYY.YYY.YYY внутренний ip 192.168.67.1

1) GW1 запускаем

- stop-gw;

2) на GW2 запускаем

start-gw

- меняем маршрут по-умолчанию:

ip route del default && ip route add default via 10.0.0.1

- в файле /etc/asterisk/sip.conf раскомментировать строку

externip= YYY.YYY.YYY.YYY

И закомментировать строку

;externip= XXX.XXX.XXX.XXX

- Выполнить команду

asterisk -rx 'sip reload'

После восстановления работы интернета делаем следующее (именно в данной последовательности):

1) на GW2 запускаем
- stop-gw

- в файле /etc/asterisk/sip.conf раскомментировать строку

externip= XXX.XXX.XXX.XXX

И закомментировать строку

;externip= YYY.YYY.YYY.YYY

- Выполнить команду

asterisk -rx 'sip reload'

- меняем маршрут по-умаолчанию:

ip route del default && ip route add default via 192.168.67.10

2) на GW1запускаем

start-gw

2. Недоступен основной интернет шлюз

Проблема: Недоступность интернет ресурсов

Решение: В случае недоступности основного интернет канала – GW1 заходим по ssh на второй сервер GW2 и переносим роль недоступного сервера на другой:

GW1 - XXX.XXX.XXX.XXX внутренний ip 192.168.67.10
GW2 - YYY.YYY.YYY.YYY внутренний ip 192.168.67.1

1) GW1 запускаем

- stop-gw;

2) на GW2 запускаем

start-gw

- меняем маршрут по-умолчанию:

ip route del default && ip route add default via 10.0.0.1

- в файле /etc/asterisk/sip.conf раскомментировать строку

externip= YYY.YYY.YYY.YYY

И закомментировать строку

;externip= XXX.XXX.XXX.XXX

- Выполнить команду

После восстановления работы интернета делаем следующее (именно в данной последовательности):

1) на GW2 запускаем

- stop-gw

- в файле /etc/asterisk/sip.conf раскомментировать строку

externip= XXX.XXX.XXX.XXX

И закомментировать строку

;externip= YYY.YYY.YYY.YYY

- Выполнить команду

asterisk -rx 'sip reload'

3. Недоступен сервер телефонии

Проблема: Отсутствие возможности у пользователей совершать звонки

Решение: В случае недоступности сервера телефонии – GW2 заходим по ssh на второй сервер GW1 и переносим роль недоступного сервера на другой:

medray-voip - YYY.YYY.YYY.YYY внутренний ip 192.168.67.1
medray-gw - XXX.XXX.XXX.XXX внутренний ip 192.168.67.10

1) на GW2 запускаем

stop-asterisk

2) на GW1 запускаем

start-asterisk

После восстановления интернета делаем следующее:

1) на GW1запускаем

stop-asterisk

2) на GW2 запускаем

start-asterisk

4.Недоступен контроллер домена

Проблема: Невозможна доменная авторизация, не работает DHCP.

Решение: Во время недоступности основного контроллера, ресурсы запрашивают авторизацию у резервного контроллера домена автоматически. Для решения проблемы авторизации дополнительных действий не требуется.

В случае физического выхода из строя контроллера домена то необходим резервному контроллеру домена передать права основного контроллера домена.

Запускаем командную строку CMD, запускаем по очереди команды:

ntdsutil
role
connections
connect to server medray-dcr
quit

Дальше принудительная передача ролей:

seize naming master
seize rid master
seize schema master
seize pdc
quit

После того как мы успешно забрали роли то в сетевых настройках нашего нового контроллера домена меняем первичный DNS на 127.0.0.1.

При этом DHCP серверу нужно указать, чтобы выдавал первичный DNS, адрес нового контроллера домена.


EFSOL

Системная интеграция. Консалтинг

ИТ-обслуживание

обязательные поля
* Антиробот:
Введите ответ

ИТ-обслуживание

Все поля формы выделенные значком * обязательны к заполнению
* Антиробот:
Введите ответ
Поделиться:
  • Здравствуйте. С Вашего позволения- пройдемся подряд по техническим вопросам. 1) Я так понимаю, написанные примеры применимы для оборудования на базе ОС Unix. Планы перехода на резерв на железных роутерах, а-ля Cisco будут такими же? 2) Интересно бы узнать план аварийного восстановления для бухгалтерии или склада, имею ввиду 1С 3) А почему в случае недоступности контроллера домена, обязательно не работает DHCP? 4) Вы упомянули о зрелой ИТ-системе. Вопрос - в такой системе кто выполняет переход на резервный ресурс - человек или сама система?
  • Здравствуйте, Евгений. 1) Нет, скрипты действий технического персонала по активации резервных маршрутизаторов на базе Cisco, Juniper, Mikotik и тому подобных - отличаются от указанных. Представленные на сайте скрипты являются примерами плана аварийного восстановления для маршрутизаторов. 2) Конечно же, такие планы есть. К примеру, план перехода на резервный сервер СУБД либо план по вводу дублирующего сервера 1С. Поскольку вариантов исполнения подобных планов может быть великое множество, а единый стандарт отсутствует - описывать их в статье не планировали. 3) Зачастую роли AD и DHCP совмещают для экономии серверного ресурса и лицензий, хотя Microsoft строго не рекомендует этого делать на AD. Мы имели ввиду, что при крахе операционной системы либо аппаратной платформы - будет отказ всех установленных ролей. 4) Если говорить о зрелости по классификации Microsoft с ее 4 уровнями, то на каждом уровне обеспечение непрерывности выполняется по разному. В более младших моделях - человеком, в более зрелых структурах - автоматическими инструментами с применением соответствующих технологий.

У вас конкретная задача? Свяжитесь с нами прямо сейчас!


Обратный звонок RedConnect