У билайна есть разношерстный парк Unix-серверов: это AIX, Solaris, где-то есть даже HPUX на итаниуме. Они достаточно надежны, но так как они начали эксплуатироваться давно, вероятность их выхода из строя по мере расходования запаса надежности увеличивается. Часто на таких серверах работают критичные программные продукты, а данные с них хранятся на системах хранения данных (СХД), которые тоже не молодеют. 

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

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

Что происходит, когда критической системе начинает плохеть

Все начинается с мониторинга. Если критическая система недоступна или достигнуты пороговые значения по использованию какого-то ресурса (диска, сети, процессора), автоматически заводится тикет высокого приоритета. В нем перечислены специалисты, которые нужны на срочной АВР-конференции, чтобы устранить неполадки.

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

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

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

Пример аварии: упал сервер по причине выгорания процессорной платы

То, что из строя вышла процессорная плата, было видно по сообщениям на ILOM-интерфейсе. На восстановление таких конфигураций есть SLA  — он известен, как и алгоритм действий. Быстро восстановить сервер не получится: нужно переключаться на резервную ноду, после чего заниматься восстановлением упавшего сервера. Переключения между нодами в кластерах делаются плановым порядком минимум 2 раза в год. Это дает уверенность, что у нас есть рабочая запасная нода.

Для переезда надо пригласить ответственных за приложение — администраторов баз данных. Администраторы ОС после отмашки на переключения переносят кластерные ресурсы (IP, шары, диски с СХД) на новую активную ноду. Дальше администраторы БД творят волшебство так, чтобы данные не потерялись. Автоматического переключения активной ноды нет — аварии каждый раз разные и нужен человеческий присмотр для таких переездов. 

После подготовки к запуску приложения наступает очередь колдовать «аппликативщиков» — это терминология такая — и проверять то, что все стало работать как надо.

Пояснение: приложение и база данных есть не всегда, и не всегда они связаны между собой. Но, для обобщенного случая, предполагаем, что есть и база, и приложение. И до переезда и восстановления работоспособности базы желательно произвести некие действия на стороне приложения, которые остановят трафик к базе.

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

После восстановления сервиса на запасной ноде, начинается «разбор полетов» — думаем, какую пользу можно извлечь аварии. Это возможность провести профилактические работы по обновлению микрокода, некоторого системного софта или железа: например, гигабитных сетевых плат на 10 гигабитные или добавке памяти. Так как все заинтересованные лица собрались в одном месте, обсуждение проходит быстро и результативно. После этого всех отпускают по своим делам до прогнозируемого времени завершения оперативных работ по замене сгоревших компонент — просто так держать вместе большое количество занятого народа никто не собирается.

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

Если принимается решение вернуться обратно на починенный сервер, то приложение и база гасятся на активной ноде, ресурсы переключаются на восстановленную ноду, после чего делаются базовые проверки и начинается подъем баз и приложений. 

После переезда АВР-конференция готовится к завершению — создаются задачи для ответов на вопросы, которые надо сделать к дебрифу:

• Уточнение влияния от падения.

• Выяснение, были ли у возникшей проблемы индикаторы, которые не отслеживались на мониторинге.

• Обсуждение поиска специалиста для выполнения каких-то действий.

• Актуализация наличия запасных плат соответствующего типа.

После раздачи всем сестрам по серьгам задач для дебрифа определяется время его проведения и список его участников. Созданные задачи вносятся в протокол, АВР объявляется закрытой.

Пример длительной предаварии, которая влияет на несколько систем

Одиночный сервер – это простейший случай. Гораздо объемнее проблемы с СХД, с которого подается много места на много критичных серверов. Поэтому такие проблемы стараются предупредить и произвести сервисные работы до того, как случится авария. 

Недавно возникла потребность в подобном сервисе одного из СХД. Мониторинг предупредил, что СХД становиться не по себе и лучше как можно скорее провести сервис. Но есть нюанс: данные после него могут потеряться. Во время тщательного планирования в срочном порядке перевели все во время  сервисных окон на запасные сервера, которые работают с другой СХД. К концу этих двух недель мы подошли к тому самому опасному сервисному обслуживанию СХД, который, как и было запланировано, длился все выходные. Потому что, как и предполагалось, он привел-таки к полной очистке данных на СХД.

Но из-за тщательного планирования для такой предаварии и длительных подготовительных работ снаружи это выглядело так: в пятницу после окончания рабочего дня мы выключили сервера, которые работают с этой СХД, а в воскресенье вечером они были включены и полностью готовы к возвращению сервисов. 

Для тех дисков, которые являются зеркалом дисков с данными восстановление происходило средствами массива. Но там были и системные загрузочные диски для виртуалок с солярисом. Пришлось в загрузочный zpool для такого добавлять диск с третьего СХД и восстанавливать его через zpool.

Некоторые большие диски с данными также не имели копии на втором массиве. Приходилось копировать данные на диски аналогичного размера, поданные с третьей СХД с перенастройкой базы данных на работу с новым дисковым пространством. Еще пришлось подавать дополнительное дисковое пространство для архивных журналов у таких баз данных, с целью подстраховаться, если работы затянутся.

Работа происходила в режиме многодневной предаварии с определенными исполнителями на каждый день на каждую стадию — координаторы просто периодически обновляли статус работ.

Полезная выжимка: выводы с пояснениями

• Не каждое падение сервера требует сбора конференции с вовлечением различных групп для восстановления

Но есть группа сервисов, для которых прописан такой порядок — их функционирование нужно восстанавливать оперативно. Для этого есть планы и процедуры, которые помогают сохранить комфортную атмосферу в стрессовой ситуации. 

• Координатор помогает расставлять приоритеты, если проблема возникла одновременно у нескольких сервисов

Если серверов много, привлекают дополнительных специалистов, работу которых распараллеливают и приоритезируют. Если владелец какого-то продукта не согласен с матрицей приоритетов, он должен договорится об изменении порядка выполнения работ через координатора. 

• Исполнители от разных команд обычно переходят в отдельные комнаты для исполнения своих задач

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

• Иметь актуальные планы на случай аварий и отлаженные работающие процедуры — это хорошо

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

Пример: при плановом перевозе виртуалки с одного гипервизора на другой нужно её отключать — там старые версии OS, а на них живая миграция не поддерживается. Если включить системный диск, он оставит файлик на ZFS, который мешает примонтировать системный раздел после переезда. Поэтому надо грузиться по сети и удалять мешающий файлик. Поэтому, когда однажды упал гипервизор, и после замены карты примерно половина виртуалок выдавала именно такую ошибку, её устранение занимало всего по 10 минут на каждую из виртуалок. При этом все делалось в параллель. Команда загрузки с сети и правки отработана и описана — на случай, если кому-то придется делать это в первый раз.

• Если видишь прогноз аварии, то лучше его воспринимать серьёзно

Решения, которые работают на унаследованных риск-платформах, постепенно переносятся на типовое (общедоступное) оборудование. Там, где есть возможность, меняется архитектура.

Есть некоторые сервера (крупные базы данных), которые на время смены архитектуры должны продолжать работать с текущим подходом. Для них нужно разработать свои планы действий в аварийных ситуациях и проводить соответствующие тренировки.

P.S.: Прав был Суворов.