Падение SQL-серверов, виртуальных машин, отключение систем хранения данных – довольно частое явление, поэтому восстановлением работоспособности СУБД SQL Server, ProxMox, СХД после аварий нам приходится заниматься едва ли не каждый месяц. И задача это вполне стандартная, но только в том случае, если есть возможность выехать на место или подключиться к сети и ПК через интернет.
Однако бывают ситуации, когда ни то ни другое невозможно. Когда заказчик просто не имеет права предоставить удаленный доступ, не говоря о личном присутствии сторонних технических специалистов на объекте. В этом кейсе мы расскажем, как выходим из положения в подобных случаях на примере закрытого завода.
В советское время такие предприятия назывались «ящики», потому что производили они секретную (как правило, оборонную) продукцию, имели повышенный уровень безопасности, а вместо привычного адреса у них был номер почтового ящика (п/я №).
Секретный объект с особыми требованиями по безопасности
Закрытые госпредприятия существуют и сегодня. Условия работы на них особые – сотрудникам категорически запрещено даже мобильные телефоны приносить на рабочее место. Связь – только по выделенным каналам передачи данных, выход в сеть защищенный, в общедоступный интернет не попасть. Одним словом, режим строжайшей секретности.
Теперь вы понимаете, с какими сложностями мы столкнулись, когда к нам обратился IT-отдел одного из таких закрытых заводов (по понятным причинам мы не можем раскрыть информацию о его местонахождении и производимой продукции). Но давайте по порядку.
IT-отдел завода и нерешаемая проблема с СХД: SQL-серверы не стартуют, ProxMox не работает, инфраструктура стоит
Представьте себе – производственное госпредприятие, 1000+ сотрудников, серьезные проекты – серьезные обороты, несколько миллиардов в месяц. Продвинутое оборудование, современные технологии, весь процесс производства завязан на IT, соответственно, информационная инфраструктура масштабная и очень сложная. И вдруг – «лег» SQL-сервер, базы данных оказались недоступны. Производство встало, каждый час простоя – миллионные убытки, госзаказ под угрозой срыва.
IT-отдел предприятия в это время как раз проходит реорганизацию, на весь завод осталось всего два айтишника в штате. То ли компетенций, то ли ресурсов у сотрудников IT-отдела не хватило, но не справились.
Естественно, хватаются за голову, начинают искать помощь со стороны. Обзванивают профильные компании по всей России – везде отказ. Предприятие закрытое, повышенный уровень секретности, интернет по защищенным каналам, регламенты безопасности не позволяют предоставить удаленный доступ. Как решать проблему без удаленного подключения – непонятно.
Можно было на месте разобраться, что происходит с SQL-сервером и виртуальной средой ProxMox, однако объект не просто находится на расстоянии – на него физически вообще не попасть. Ну а лишних телодвижений никто делать не хочет.
В общем, положение у местных сисадминов отчаянное, и с каждым отказом ситуация становится все критичнее. Обзвонив несколько десятков российских IT-компаний, наконец выходят на нас. Мы любим нестандартные задачи и соглашаемся помочь.
Как решить IT-задачу на режимном объекте без удаленного доступа: ищем обходные пути
Проблематика: не стартуют серверы SQL (“умер” сетевой интерфейс), к базам не подключиться (сбой связи с Active Directory), не поднимаются службы, отсутствует управление. ИТ-инфраструктура встала, работа предприятия парализована. Ситуация усугубляется тем, что из-за регламентов безопасности удаленный доступ невозможен.
Задача: восстановить операционную деятельность предприятия, реанимировав SQL-сервер и базы данных. Для этого мы должны выполнить переустановку сетевой карты, перенастроить интерфейсы ProxMox, настроить IPMI (он не был настроен) для управления сервером.
Итак, что мы имеем. Закрытый объект без выхода в глобальную сеть, соответственно, без возможности удаленного подключения к машинам и нормального человеческого взаимодействия. Надо искать обходные пути.
Остаются два варианта: связь по телефону и видеосозвон. Первый наглядности не обеспечит, поэтому единственный способ коммуникации, с помощью которого можно хоть как-то представить, что происходит с серверами, – это видеосозвон.
Другого выхода нет – серверы надо «поднимать», ProxMox запускать, работу завода восстанавливать. Или объект будет просто стоять. И сложно представить, к каким последствиям приведет простой – материальные потери будут гигантскими, а руководству придется расплачиваться как минимум карьерой.
Как мы восстанавливали диски для виртуальных машин: восстановление и настройка ProxMox
Связываемся с сотрудниками IT-отдела завода через видеозвонок по Whatsapp. Они показывают на экране, что происходит с серверами. С грехом пополам пытаемся разобраться, провести диагностику, решить, что можно предпринять, чтобы сохранить данные.
Исходная информация
- Виртуальные машины ProxMox запускались, но выдавали ошибку no bootable device (нет загрузочного устройства), то есть девайс не видел загрузочных дисков. Не хотели стартовать диски, на которых хранились эти виртуальные машины.
- Разделы на двух машинах загадочным образом обнулились – судя по всему, заводские айтишники пытались самостоятельно восстановить работоспособность системы, но что-то пошло не так.
- И в лучших традициях 99% наших заказчиков: бекапы удалены, никакой документации нет. Ее вообще почему-то никто в принципе не делает и не ведет – не доходит даже до описания того, что настроено, не говоря о хранении.
На последнем пункте необходимо остановиться подробнее. Наличие бекапов и документирование процедур позволяют оперативно восстановить систему после сбоя. Производить установку и настройку из резервной копии всегда быстрее и проще, чем запускаться с нуля. Тем более что процедура резервирования с помощью встроенного инструментария не отнимает много времени.
К примеру, в ProxMox предусмотрены хорошие штатные инструменты резервного копирования, которыми можно пользоваться для создания бекапов. А образы виртуальных машин можно хранить на локальном или, что еще лучше, – в облачном хранилище, где они всегда будут доступны. Но почему-то многие системные администраторы то ли из-за лени, то ли из-за разгильдяйства игнорируют стандартный алгоритм и рекомендации по обслуживанию IT-инфраструктуры.
Первый этап – диагностика и поиск решения
Когда мы провели технический аудит, продиагностировали исходное состояние серверов, то обнаружили следующее:
- кластер из серверов “развалился”;
- RAID рассыпался;
- по сети подключиться невозможно;
- управление виртуалкой не получить;
- бекапы ProxMox отсутствуют.
После диагностики стало понятно, что остается один выход. Нужно подключать диски к новой виртуальной машине и пытаться вытащить информацию оттуда. А убедившись, что данные на дисках сохранились, вытаскивать базы через другую машину. В существующей виртуализации ProxMox у них вообще никакие виртуальные машины не стартовали.
Что было в наших силах, мы сделали:
- подключили к другой виртуалке;
- отсканировали данные на диске;
- вытащили базы.
В результате у нас получилось поднять сетевой интерфейс, запустить серверы и подцепить к ним данные. Также удалось найти сервер архивации PDM – на нем хранятся все схемы. После подключения баз потребовалось специальное ПО для переиндексации баз, так как они подключались в аварийном режиме и их структура была нарушена.
Второй этап – восстановление баз
Договорились с заказчиком, чтобы нерабочие PDM-базы выгрузили нам. На своей инфраструктуре мы подготовили и развернули среду для тестирования. Сразу обратили внимание, что лог по какой-то причине был в десять раз больше самих БД. Это свидетельствовало о том, что план обслуживания был некорректно настроен – по всей видимости, обслуживанием баз никто не занимался – они просто росли и росли вместе с логами. Что уже свидетельствует о неправильном подходе.
Начались попытки восстановить PDM-базы (без этого этапа мы не могли приступить к следующему). Сами базы как сущность мы вытащить смогли, но их целостность была нарушена – часть после обработки запустилась, а часть нет. К сожалению, большинство данных восстановить не удалось. К восстановлению БД решено было подключить разработчиков программного обеспечения, которые лучше знают структуру и нюансы. Так что восстанавливать структуру баз данных помогали сотрудникам IT-отдела завода уже профильные специалисты по PDM.
Подводим итоги
Главную проблему мы решили, несмотря на отсутствие удаленного доступа из-за жесткой политики безопасности и неудобств, связанных с коммуникацией через видеосозвон. После нашего вмешательства SQL-сервер стартовал, ProxMox заработал, часть баз была реанимирована. Это позволило восстановить операционную деятельность предприятия.
В итоге полностью парализованный завод, на котором трудится 1000+ человек и где остановка производства влечет ущерб, исчисляемый миллионами рублей, заработал. Продолжал стоять только отдел проектировщиков, и то не весь – у них оставалась недоступной часть информации в базах – остановилась разработка и работа с технической документацией. То есть все производственные и технологические процессы возобновились, завод продолжал выпускать продукцию, выполнять план, но у него приостановилась проектная деятельность. Здесь мы уже помочь не могли, и восстановлением информации в БД проектного отдела занимались разработчики специализированного PDM-софта.
На технический аудит ушло два рабочих дня. Мероприятия по восстановлению функционирования SQL-сервера, виртуализации ProxMox, баз данных и в конечном счете всего предприятия заняли еще два рабочих дня.
Наша команда, задействованная в работе над этим кейсом, состояла из трех человек:
- специалист по базам данных;
- специалист по виртуализации;
- руководитель технической поддержки.
Предложения по повышению отказоустойчивости IT-инфраструктуры
Помимо выполнения поставленных задач, мы сделали заказчику два предложения:
1. Внедрить систему мониторинга.
2. Создать и настроить систему резервного копирования. Поскольку из-за политики безопасности хранить бекапы на облаке госпредприятию нельзя, мы предложили настроить резервное копирование на основании более подходящих комплексных решений – Veeam Backup & Replication или Acronis True Image.
Наши расчеты и предложения по организации мониторинга и резервного копирования как с точки зрения выбора программного обеспечения, так и с точки зрения методологии внедрения, были сделаны с учетом особенностей деятельности предприятия. Мы принимали в расчет то, что заказчик относится к госструктуре и работает по определенным регламентам, ограничивающим возможности IT, и рекомендовали решения, которые позволяют повысить эффективность и отказоустойчивость ИТ-инфраструктуры, не заходя за рамки существующей политики безопасности.
Оригинал статьи на нашем сайте.