ERP с быстрым результатом
1С-Отчетность: Добро пожаловать! Подключись до 31.12.2016 и получи скидку 50% на годовую лицензию!
Дарим отчет для пользователей 1С:Бухгалтерии 8.3
Абонентское
ИТ-обслуживание
Корпоративная почта или IP-телефония в подарок!
Аренда сервера 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

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

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

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

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

Все поля формы выделенные значком * обязательны к заполнению
* Антиробот:
Введите ответ
Поделиться:

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


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