 |
|
|
|
Не теряя управления
Не теряя управления В статье описываются методы отказоустойчивости ИТ-инфраструктуры. Особое внимание уделяется вопросам сохранения управляемости серверов под нагрузкой Как часто в своей работе мы забываем о некоторых на первый взгляд незначительных мелочах, которые, будучи упущенными, могут если не сыграть злую шутку, то заставить понервничать. Когда в эксплуатацию вводится новое оборудование, мало кто отдает себе отчет, что по прошествии времени с ним могут происходить удивительные вещи. И временная потеря управления по причинам, от нас не зависящим, может стать одним из событий, которые надолго остаются в нашей памяти. С чего все началось, или Рассказ о небольшом происшествии В свое время под моим началом оказался интересный проект по организации резервного копирования на предприятии с филиальной структурой. Аппаратное и программное обеспечение было подобрано с учетом требований заказчика, была выбрана централизованная топология резервного копирования в соответствии с уровнем организации, схема ротации носителей была настроена с учетом местной специфики. Несмотря на то что компания функционировала круглосуточно, большая часть персонала работала по 40-часовой рабочей неделе, в общем, атмосфера была довольно спокойной. В один прекрасный день, точнее, в одну прекрасную ночь, меня поднял с постели звонок «горячей линии» той самой компании, где уже более полугода все шло тихо и ровно. Проблема оказалась в том, что менеджеры одного из дальних филиалов затеяли в выходные дни круглосуточную рекламную акцию. Как обычно, по доброй старой российской традиции, руководство центрального филиала об этом знало, но особого значения этому не придало, а ИТ-департамент, в том числе и системного администратора, вообще «забыли» предупредить. И в самый ответственный момент оказалось, что система учета бонусов просто не работает. Инициативные менеджеры вспомнили об ИТ-службе и подняли среди ночи своего системного администратора. Он и определил, что SQL-сервер, на котором находилась база данных учета бонусов, вглухую занят каким-то очень прожорливым процессом. Проанализировав сетевой трафик, системный администратор в офисе заказчика справедливо пришел к выводу, что этот самый загадочный процесс как раз и является порождением задачи резервного копирования, запущенной, кстати, в выделенное и заранее согласованное «окно бэкапа». И теперь все это нужно каким-то образом остановить. Ситуация осложнялась тем, что программа резервного копирования игнорировала любые попытки установки приоритетов распределения ресурсов. То есть, несмотря на любые настройки, программа-агент при интенсивной работе все равно сгребала под себя все, что можно: память, процессорное время, и начинала гнать данные сплошным потоком по сетевому интерфейсу. Кстати, довольно приличное ПО. Пока работа шла в штатном режиме, и процесс копирования запускался в специально выделенное «окно бэкапа», такой расклад всех (и заказчика в первую очередь) вполне устраивал. А тут ситуация внештатная, как говорится, «предупреждать надо». Проблемы не было бы вовсе, если бы ИТ-службу оповестили заранее. Перенастроить задания копирования на другое время – дело нескольких минут, и все прошло бы без сучка и задоринки. Но традиционно пренебрежительное отношение к ИТ сыграло свою роль, и результат не заставил себя ждать. Выяснить причину – это хорошо, но надо как-то решать проблему. Поначалу задача казалась тривиальной: подключиться через удаленную консоль управления к серверу резервного копирования и остановить запущенное задание. Но дело в том, что подключиться к серверу управления и по совместительству медиасерверу [1] было невозможно из-за высокой нагрузки на сетевой интерфейс. Аналогичная ситуация была и с агентом резервного копирования, работавшим в тот момент на сервере SQL, – попытки остановить процесс через управляющую консоль системы резервного копирования потерпели фиаско. Все старания на предмет подключиться по протоколу RDP (речь идет о Windows-системе) и даже посредством оснастки MMC «Удаленное управление компьютером»), чтобы штатными средствами остановить процесс копирования и продолжить работу, не увенчались успехом. Учтем и тот факт, что заказчик экономил на всем. Поэтому и KVM-switch, и средства удаленного управления типа iLO отсутствовали. Казалось, оставался единственный на тот момент выход: послать кого-либо из местного персонала, например, охранника, чтобы выполнить холодную перезагрузку сервера SQL. С риском сорвать мероприятие и, если «повезет», разрушить базы данных. К счастью, была еще одна лазейка, которой не воспользовались сотрудники местного подразделения ИТ. На серверах внутри периметра была установлена и запущена служба сервера Telnet. Делалось это как некий заменитель удаленного управления, для случаев, когда понадобится «что-то сделать с серверами» в сложной ситуации. Еще одна возможность, прозорливо предоставленная для ИТ-службы, – предустановленные утилиты Sysinternals [2] от Марка Руссиновича. В итоге я просто подключился к серверу по Telnet и с помощью команды pskill убил бесполезный на тот момент процесс резервного копирования. К слову сказать, на успех мероприятия данный инцидент не оказал слишком большого влияния, хотя и заставил всех понервничать. Реже причинами подобных происшествий бывают незапланированные скачки потребления ресурсов (например, генерация «тяжелых» запросов на сервере Баз данных) или утечка памяти из-за криво работающего очередного обновления, призванного «улучшить работу системы». Но в данной статье мы коснемся в основном вопросов снижения сетевой нагрузки и поиска обходных путей для обеспечения бесперебойной работы системы в любой ситуации. Что же касается других причин, в конце статьи будет представлено несколько полезных рекомендаций. Статью целиком читайте в журнале «Системный администратор», №5 за 2014 г. на страницах 22-26. |
АЛЕКСЕЙ БЕРЕЖНОЙ, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
