Мы любим прогресс и сложные случаи в современных ИТ. Но иногда к нам обращаются с такими историями, что инженерам приходится вспоминать былые времена. Помните SUN? Компания SUN Microsystems запомнилась в лучшие свои годы качественным инженерным «железом» enterprise-уровня. К чему лукавить: ностальгируем и чуточку скучаем. Отчего нас бросило в такую меланхолию? Недавно работали с одним случаем. Решили написать небольшую заметку — не все же ностальгировать в одиночестве.
Итак, недавно к нам пришел один из наших заказчиков. У него был недоступен один из критичных серверов.
Исходные данные: старенькая система Sun Fire V440 2003 года выпуска, еще фиолетовая сановская, но одновременно надежная и добротная, поддерживаемые ОС Solaris 8/9/10, до четырех процессоров UltraSPARC® IIIi (1.062, 1.28, or 1.593 GHz), память до 32 GB, до четырех SCSI-дисков, шесть слотов PCI:
Sun Fire V440, No Keyboard
Copyright 2006 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.22.19, 16384 MB memory installed, Serial #61770219.
Ethernet address 0:3:ba:ae:89:eb, Host ID: 83ae89eb.
Небольшое отступление автора. Мы понимаем, что говорим об очень старом железе, так что вот аналогия для лучшего понимания. Мощность нашего сервера сравнима с iPhone 6S, только работает он более 20 лет в режиме 24х7х365.
Доступ ко всем дискам отсутствует. Выезжаем, до этого собрав актуальные для системы средства диагностики и восстановления.
Приехали на площадку заказчика, сделали первичную диагностику и выявили: система аппаратно исправна, но ОВР (OpenBoot PROM) не видит диски.
Сразу набросали возможные причины сбоя:
- SCSI-шина не видит диски;
- сбойные диск/диски забивают шину ошибками;
- бакплейн или кабель скончались;
- аппаратный рейд LSI, встроенный в материнскую плату, умер.
Осмотр, проверка подключений SCSI, тесты SCSI.
Похоже, один или несколько дисков вызывает сбой по SCSI-шине. Есть вероятность, что диски дергали в попытках восстановить доступность.
Помним, на данной системе есть два варианта доступа к дискам: через аппаратный рейд встроенного контроллера (LSI) или с помощью контроллера, который пропускает диски напрямую.
Сбросили буферы, проверили наличие томов рейда, — не созданы, диски отданы напрямую. Проверяем их на доступность поочередно. Находим пару конфигураций дисков, при которых хотя бы часть из дисков видны. Используем древний инструмент Solaris Utility Environment (помните такой?), но актуальный для этой системы, смотрим на состояние файловых систем, загрузочных зеркал и зеркал данных (первые два диска для ОС, вторые — приклад):
Solaris Utility Environment version 3.32
Booting this environment will not modify any disks on this system.
Правим параметры SVM (Solaris Volume Manager, старый софт-рейд в Solaris), монтирование ФС (файловых систем), и поднимаем ОС на половинке зеркала.
ОС доступна в Single user mode, работаем, дочищаем хвосты в SVM, проверяем доступность данных — все ок.
Собираем стабильную конфигурацию из дисков: один — под ОС, другой — под данные. Загружаемся. Заказчик решил перенести данные приклада из SVM в ZFS (новая ФС, софт-рейд в Solaris 10/11). Создаем новый пул и мигрируем данные. Докидываем в пул диск — зеркало данных готово: SC Alert: DISK @ HDD3 has been inserted.
Выдохнули. Фактически заменили три диска из четырех, восстановление с резервной копии (лент) не потребовалось, что сильно ускорило запуск системы в работу.
format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c1t0d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci@1f,700000/scsi@2/sd@0,0
1. c1t1d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci@1f,700000/scsi@2/sd@1,0
2. c1t2d0 <HITACHI-HUS10733ASUN72G-PA05-68.37GB>
/pci@1f,700000/scsi@2/sd@2,0
3. c1t3d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci@1f,700000/scsi@2/sd@3,0Остается сделать зеркало на рута и разделы ОС в SVM, настроить загрузку с нового диска и проверить систему.
Светает, фиолетовый Sun горит зеленым, доступ восстановлен. А вы если работаете с легаси — пишите в комментариях, с каким легаси сталкиваетесь вы или какие случаи запомнились.
Автор: JetHabr
