Не запускается приложение на сервере
Существует большое количество причин, по которым клиентское приложение не может подключиться к серверу.
Сперва определите на чьей стороне проблема.
Проблема на локальном компьютере
1. Если с других локальных компьютеров подключение происходит, то скорее всего проблема в конкретном ПК. Сравните настройки проблемного ПК с настройками рабочего ПК, приведите их в соответствие. Как вариант, вы можете скопировать рабочее клиентское приложение с другого компьютера и запустить его на проблемном.
1.1. Проверьте, что компьютер, с которого вы запускаете клиентское приложение обозначен в Администрирование/Карта сети или в серверном конфигурационном файле \Oktell\Server\oktell.ServerService.exe.config установлена настройка Automap
1.2. Проверьте настройки интернета, пропингуйте сервер Oktell командой ping из командной строки. Если пакеты не доходят до сервера, значит имеются проблемы в настройке сети.
1.3. Убедитесь в диспетчере задач, не запущено ли клиентское приложение. Название процесса Oktell.ClientStarter4.exe (или Oktell.ClienStarter.exe для версий младше 2.8). Возможно другой пользователь уже запустил его, в таком случае возможно вам стоит использовать Работа в терминальном режиме. Также в диспетчере задач вы можете завершить этот процесс, для входа под своей учетной записью.
1.4. Убедитесь, не блокирует ли приложение на клиентском ПК антивирус или брандмауэр Windows. Либо отключите его, либо добавьте в исключение oktell.ClientStarter4.exe и oktell.phonehost.exe
1.5. Убедитесь, что правильно прописали адрес сервера oktell в клиентском конфигурационном файле \oktell\client\oktell.ClienStarter4.exe.config
Для этого проверьте параметры
- <add key="LogicServerAddress" value="ххх.ххх.ххх.ххх" />
- <add key="NETCLIENT_SERVER_ADDRESS" value="ххх.ххх.ххх.ххх" />
где ххх.ххх.ххх.ххх - IP-адрес вашего сервера oktell.
1.6. Возможно клиентское приложение запускается не от имени администратора и не имеет прав для записи в каталог Program Files, в который оно устанавливается по умолчанию. Это может привести к тому, что приложение не сможет загрузить файлы обновления и не сможет в дальнейшем подключиться к серверу.
Запустите oktell.ClienStarter4.exe от имени администратора. Для этого в свойствах приложения, на вкладке "Совместимость" поставьте галочку "Запускать от имени администратора". Эту же операцию можно применить к oktell.phonehost.exe, что может решить возможные проблемы с гарнитурой.
1.7. Возможна ситуация, когда в конфигурационном файле \oktell\client\oktell.ClienStarter4.exe.config не активирован параметр AutoUpdate, в таком случае клиентское приложение не обновляется и возможно возникнут проблемы с запуском. Для активации установите следующий ключ:
1.9. При появлении ошибки "Программа уже запущена" попробуйте установить любое значение для ключа "TerminalAddress" клиентского конфигурационного файла \oktell\client\oktell.ClienStarter4.exe.config, например term2.
1.10. При появлении ошибки "Программа уже запущена" возможны проблемы с совместимостью Windows. Запустите программу в режиме совместимости с Windows XP (SP3). Также попробуйте запустить программу от имени администратора.
1.11. Проблема в сети. Если у вас несколько сетевых интерфейсов на компьютере, отключите лишние. Оставьте только тот интерфейс, по которому доступен сервер Oktell.
1.12. Проблема с DNS именем. Убедитесь, что у вас указаны DNS-сервера. Попробуйте использовать DNS сервер — 8.8.8.8. (Google Public DNS). Как вариант, пропишите соответствие имя—адрес в hosts.
Проблема на сервере
2. Если все компьютеры локальной сети не могут подключиться, то проблема может быть как в сети, так и в настройках сервера.
2.1. Проверьте запущена ли служба OktellServer. Если нет, обратитесь к статье Серверная служба не запускается
2.2. Проверьте настройки интернета, пропингуйте сервер Oktell командой ping из командной строки. Если пакеты не доходят до сервера, значит имеются проблемы в настройке сети.
2.3. Проверьте подключение к серверу, попробуйте запустить клиентское приложение на сервере. Если запустится, значит проблема в сети или брандмауэре ОС на сервере.
2.4. Убедитесь, что на сервере Oktell антивирус или брандмауэр не блокирует работу. Либо отключите(подвергаете систему опасности), либо добавьте в исключение процессы.
- \oktell\server\oktell.ServerService.exe
- \oktell\server\oktell.HALRemoteApp.exe.
Чтобы добавить процессы в исключения брандмауэра перейдите в Панель управления -> Брандмауэр Windows -> Разрешить запуск программы или компонента через брандмауэр Windows -> Разрешить другую программу -> Обзор
В этой статье данная статья предоставляет обходные пути для проблемы, в которой нельзя запустить приложение, которое опирается на файл Explorer.exe в сеансе RemoteApp служб терминала.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 951048
Симптомы
Рассмотрим следующий сценарий. Вы входите в Windows службы терминалов сервера RemoteApp (TS RemoteApp). Сеанс TS RemoteApp включает приложения для запуска и запись реестра Run или запись реестра RunOnce. Затем попробуйте запустить приложение в сеансе TS RemoteApp. В этом сценарии приложение не начинается.
Причина
Эта проблема возникает из-за того, что вы пытаетесь запустить приложение, которое опирается на Explorer.exe файл. По проекту сеанс TS RemoteApp реализует ограниченные функции. Например, сеанс TS RemoteApp не обрабатывает следующие элементы:
- Запись реестра Run
- Запись реестра RunOnce
- Приложения для запуска
Обходной путь
Для решения проблемы используйте один из указанных ниже способов.
Метод 1. Запуск приложений для запуска в составе параметров логона пользователя
Чтобы запустить приложения-стартапы в сеансе TS RemoteApp, можно указать приложения-стартапы в составе параметров логотипа пользователя в групповой политике. Так как группа политик контролирует эти параметры, любое приложение запуска, которое вы указываете, запускается как ожидалось при входе пользователя в систему.
Чтобы указать приложения запуска в составе параметров логотипа пользователя, выполните следующие действия:
На консоли управления групповой политикой сервера (GPMC) щелкните локализованную компьютерную политику, нажмите кнопку Конфигурация компьютера и нажмите административные шаблоны.
Щелкните System, дважды щелкните Logon, а затем дважды нажмите кнопку Запустите эти программы на логотипе пользователя.
В диалоговом окне Run these programs at user logon Properties щелкните Включить.
Введите имя приложения запуска.
Если приложение запуска не расположено в папке %SystemRoot%, необходимо указать полностью квалифицированный путь файла.
Метод 2. Запустите файл Runonce.exe вместе с переключателем /AlternateShellStartup
Некоторые приложения, которые полагаются на файл Explorer.exe, могут работать в сеансе TS RemoteApp, если Runonce.exe файл в сценарий логотипа пользователя. Для этого выполните следующие действия:
На сервере GPMC щелкните локализованную компьютерную политику, щелкните Конфигурация пользователя и нажмите кнопку Windows Параметры.
Щелкните Скрипты (Logon/Logoff), а затем дважды щелкните Logon.
Причины сбоя и поломок сервера, типичные неисправности:
Как устранить и предотвратить проблемы с сервером
Предотвратить поломки сервера значительно проще и дешевле, чем устранять, когда они уже проявились.
Вот несколько требований, выполняя которые вы сможете снизить вероятность отказа вашего сервера:
- Если у вас собственная серверная, организуйте в ней качественное охлаждение и старайтесь держать ее всегда закрытой, чтобы туда не проникала лишняя пыль. Обязательно используйте источники бесперебойного питания.
- Регулярно проводите профилактическое обслуживание серверов – чистку от пыли, замену термопасты и т.д.
- Используйте специализированное ПО для мониторинга, чтобы отслеживать состояние сервера и вовремя заметить проблемы работы сервера.
- У вас обязательно должно быть настроено резервное копирование и восстановление данных сервера, чтобы предотвратить потерю важной информации в случае, если сервер все же “упадет”. Регулярно делайте бекапы, а если есть возможность – используйте отказоустойчивый кластер, тогда при сбоях в работе сервера его работа будет распределена между остальными серверами в кластере.
Если несмотря на все предпринятые меры у вас все же возникли проблемы с сервером, что делать?
- Просмотреть логи событий сервера – возможно, по ним удастся понять причину неполадок.
- Физически осмотреть комплектующие сервера, иногда их поломки бывают заметны визуально.
- Если это возможно, запустить тест памяти.
- Запустить проверку жестких дисков на наличие ошибок.
- Проверить сервер антивирусом. Это может помочь в устранении неисправностей файлового сервера, часто такие неисправности являются результатом работы вредоносного ПО.
- Проверить загрузку процессора, состояние памяти, использование дискового пространства с помощью специализированного ПО.
Срочный ремонт серверов, что можно сделать
Например, неквалифицированная попытка восстановить данные может вместо этого окончательно их уничтожить.
Обслуживание серверов
Инженеры ГК «Интегрус» уже много лет занимаются сервисным обслуживанием и ремонтом серверов, к нам всегда можно обратиться за бесплатной консультацией, аудитом, а если понадобится – то и за срочным ремонтом серверов.
Мы выполняем весь перечень ремонтных работ, работ по восстановлению данных с сервера при аппаратном или программном сбое, восстановлению сервера из бэкапа, сервисному обслуживанию, настройке защиты сервера от взлома, профилактике и мониторингу, модернизации, созданию серверной “под ключ”.
Локальный веб-сервер OpenServer не всегда работает корректно, особенно когда речь идет о его первом запуске после установки на компьютер. Часто пользователи сталкиваются с различными проблемами, приводящими к отсутствию отклика при запуске программы.
Далее я расскажу, как быстро избавиться от распространенных трудностей при работе с данным инструментом.
Просмотр логов OpenServer
Начну с небольшого совета, который чаще всего помогает сразу же распознать причину неполадки и решить ее, приложив минимальное количество усилий. Однако уточню, что подойдет эта рекомендация только в том случае, если сам OpenServer запускается в Windows, но при этом старта локального веб-сервера не происходит.
На панели задач есть значок программы, по которому нужно кликнуть правой кнопкой мыши. После этого появится контекстное меню, в котором надо нажать на «Просмотр логов» . В новом окне ознакомьтесь с полученными сведениями и определите, из-за чего появилась рассматриваемая ошибка.
Запуск программы от имени администратора
Как бы банально это ни звучало, но часто запуск OpenServer от имени администратора решает все неполадки. Дело в том, что сам компонент тесно связан с сетью и файлами, отвечающими за соединение, поэтому и требует определенных привилегий при взаимодействии с ними. Если права доступа отсутствуют, соответственно, и запуска программы не произойдет.
Вам понадобится выйти из панели управления, найти файл программы в корневом каталоге, щелкнуть по нему правой кнопкой мыши и в контекстном меню выбрать пункт «Запуск от имени администратора» . Подождите несколько секунд и проверьте, появилась ли на экране какая-либо информация, свидетельствующая о начале работы локального веб-сервера.
Если этот метод оказался эффективным, но вы не хотите каждый раз запускать программу таким образом, выполните простую настройку. Для этого снова кликните по исполняемому файлу правой кнопкой мыши и перейдите в «Свойства» . Там найдите вкладку «Совместимость» и установите галочку возле пункта «Запускать эту программу от имени администратора» .
После применения настроек софт всегда будет стартовать с повышенными привилегиями, что позволит избавиться от проблем с запуском.
Редактирование файла hosts
Встроенный в операционную систему файл hosts выполняет важную роль, и часто пользователи задействуют его, если хотят ограничить доступ к конкретным сайтам. Иногда его блокировка средствами Windows становится причиной проблем с запуском OpenServer. Информация об этом появляется в логах при попытке перейти на веб-сервер, поэтому причину можно сразу же распознать.
Хочу дать два совета:
- При использовании стороннего антивируса и брандмауэра настройте их так, чтобы OpenServer не попадал в список заблокированных программ. Стандартные средства можно отключить на время исключительно в качестве проверки.
- Запустите командную строку от имени администратора и введите команду attrib -s -r -h -a C:\Windows\system32\drivers\etc\hosts , активировав соответствующие атрибуты для упомянутого файла hosts.
Невозможно подключиться к серверу
Если же OpenServer запускается нормально, но при этом соединения с сервером не происходит, советую ознакомиться с дальнейшими инструкциями.
Способ 1: Редактирование MySQL и phpMyAdmin
Этот способ подойдет тем пользователям, которые используют OpenServer в связке с MySQL и phpMyAdmin. Он заключается в небольшой настройке этих двух компонентов для обеспечения нормального соединения, если вдруг возникла такая ситуация, что веб-сервер не хочет запускаться.
Первоочередная задача – создание нового пользователя MySQL. Вводим:
Команда отвечает за создание нового пользователя и установку для него пароля.
Откройте конфигурационный файл phpMyAdmin, который находится в папке /etc/phpmyadmin/config.inc.php . Добавьте туда две строки:
Вместо user и pass подставьте имя созданного пользователя и его пароль для MySQL.
Способ 2: Проверка данных авторизации
Это были самые распространенные способы решения проблем с запуском OpenServer.
Любое оборудование, в том числе и серверное, иногда начинает работать непредсказуемо. Абсолютно не важно — новое ли это оборудование, или же оно уже несколько лет работает с полной нагрузкой.
Случаев сбоя и некорректной работы возникает множество и диагностика проблемы зачастую превращается в увлекательную головоломку.
Ниже мы расскажем о некоторых интересных и нетривиальных случаях.
Обнаружение неполадок
В случае обращения клиента, который арендует у нас выделенные серверы фиксированной конфигурации, мы проводим диагностику, чтобы выяснить, что проблема не носит программный характер.
Проблемы программного характера клиенты обычно решают собственными силами, тем не менее, мы в любом случае стараемся предложить помощь наших системных администраторов.
Если становится ясно, что проблема аппаратная (например, сервер не видит часть оперативной памяти), то на этот случай у нас всегда есть в резерве аналогичная серверная платформа.
В случае выявления аппаратной проблемы мы переносим диски со сбойного сервера на резервный и, после небольшой перенастройки сетевого оборудования, выполняется запуск сервера в работу. Таким образом данные не теряются, а время простоя не превышает 20 минут с момента обращения.
Примеры неполадок и способы их устранения
Сбой в работе сети на сервере
Существует вероятность, что после переноса дисков со сбойного сервера на резервный перестанет работать сеть на сервере. Это обычно происходит в случае использования операционных систем семейства Linux, например Debian или Ubuntu.
При старте операционной системы этот файл сопоставляет имена интерфейсов MAC-адресам. При замене сервера на резервный, MAC-адреса сетевых интерфейсов уже не совпадают, что и приводит к неработоспособности сети на сервере.
Для решения проблемы необходимо удалить указанный файл и перезапустить сетевой сервис, либо перезагрузить сервер.
Операционная система, не найдя этого файла, автоматически сгенерирует аналогичный и сопоставит интерфейсы уже с новыми MAC-адресами сетевых карт.
Перенастройки IP-адресов после этого не требуется, сеть сразу начнет работать.
Плавающая проблема с зависаниями
Однажды к нам на диагностику поступил сервер с проблемой случайных зависаний в процессе работы. Проверили логи BIOS и IPMI — пусто, никаких ошибок. Поставили на стресс-тестирование, нагрузив все ядра процессора на 100%, с одновременным контролем температуры — завис намертво через 30 минут работы.
При этом процессор работал штатно, значения температуры не превышали стандартных при нагрузке, все кулеры были исправны. Стало ясно, что дело не в перегреве.
Далее следовало исключить вероятные сбои модулей оперативной памяти, поэтому поставили сервер на тест памяти с помощью достаточно популярного Memtest86+. Минут через 20 сервер ожидаемо завис, выдав ошибки по одному из модулей оперативной памяти.
Заменив модуль на новый, мы поставили сервер на тест повторно, однако нас ждало фиаско — сервер вновь завис, выдав ошибки уже по другому модулю ОЗУ. Заменили и его. Еще один тест — еще раз завис, вновь выдав ошибки по оперативной памяти. Внимательный осмотр слотов ОЗУ не выявил никаких дефектов.
Оставался один возможный виновник проблемы — центральный процессор. Дело в том, что контроллер оперативной памяти расположен именно внутри процессора и именно он мог давать сбой.
Сняв процессор, обнаружили катастрофу — один пин сокета был сломан в верхней части, обломанный кончик пина буквально прикипел к контактной площадке процессора. В итоге, когда на сервере не было нагрузки, все работало адекватно, но при увеличении температуры процессора контакт нарушался, тем самым прекращая нормальную работу контроллера оперативной памяти, что и вызывало зависания.
Окончательно проблема решилась заменой материнской платы, поскольку восстановить сломавшийся пин сокета нам, увы, не под силу, и это уже задача для сервисного центра.
Мнимое зависание сервера при установке ОС
Достаточно забавные случаи возникают, когда производители оборудования начинают менять архитектуру аппаратной части, отказываясь от поддержки старых технологий в пользу новых.
К нам обратился пользователь с жалобой на зависание сервера при попытке установки операционной системы Windows Server 2008 R2. После успешного запуска инсталлятора, сервер прекращал реагировать на мышь и клавиатуру в KVM-консоли. Для локализации проблемы подключили к серверу физическую мышь и клавиатуру — все то же самое, инсталлятор запускается и перестает реагировать на устройства ввода.
На тот момент этот сервер у нас был одним из первых на базе материнской платы X11SSL-f производства Supermicro. В настройках BIOS был один интересный пункт Windows 7 install, выставленный в Disable. Поскольку Windows 7, 2008 и 2008 R2 разворачиваются на одном и том же инсталляторе, выставили этот параметр в Enable и чудесным образом мышь и клавиатура наконец-то заработали. Но это было лишь только начало эпопеи с установкой операционной системы.
На моменте выбора диска для установки ни одного диска не отображалось, более того, выдавалась ошибка необходимости установки дополнительных драйверов. Операционная система устанавливалась с USB-флешки и быстрый поиск в интернете показал, что такой эффект возникает, если программа установки не может найти драйвера для контроллера USB 3.0.
Википедия сообщила, что проблема решается отключением в BIOS поддержки USB 3.0 (XHCI-контроллера). Когда мы открыли документацию к материнской плате, нас ожидал сюрприз — разработчики решили полностью отказаться от контроллера EHCI (Enhanced Host Controller Interface) в пользу XHCI (eXtensible Host Controller Interface). Иными словами, все порты USB на этой материнской плате являются портами USB 3.0. И если отключить контроллер XHCI, то мы этим самым отключим и устройства ввода, сделав невозможным работу с сервером и соответственно установку операционной системы.
Поскольку серверные платформы не были оборудованы приводами для чтения CD/DVD дисков, единственным решением проблемы стало интегрирование драйверов непосредственно в дистрибутив операционной системы. Только интегрировав драйвера контроллера USB 3.0 и пересобрав установочный образ, мы смогли установить Windows Server 2008 R2 на этот сервер, а этот случай вошел в нашу базу знаний, чтобы инженеры не тратили лишнее время на бесплодные попытки.
Интересная особенность Dell PowerVault
Еще забавнее бывают случаи, когда клиенты привозят нам оборудование на размещение, а оно ведет себя не так, как ожидается. Именно так и произошло с дисковой полкой линейки Dell PowerVault.
Устройство представляет собой систему хранения данных c двумя дисковыми контроллерами и сетевыми интерфейсами для работы по протоколу iSCSI. Помимо этих интерфейсов присутствует MGMT-порт для удаленного управления.
Среди наших услуг для размещенного оборудования как раз есть специальная услуга «Дополнительный порт 10 Мбит/с», которую заказывают в случае необходимости подключения средств удаленного управления сервером. Эти средства носят разные названия:
- «iLO» у Hewlett-Packard;
- «iDrac» у Dell;
- IPMI у Supermicro.
Для ограничения скорости порт просто настраивается как 10BASE-T и включается в работу, имея максимальную скорость в 10 Мбит/с. После того, как все было готово — мы подключили MGMT-порт дисковой полки, но клиент почти сразу сообщил, что у него ничего не работает.
Проверив состояние порта коммутатора, мы обнаружили неприятную надпись «Physical link is down». Такая надпись говорит, что имеется проблем с физическим соединением между коммутатором и подключенным в него клиентским оборудованием.
Плохо обжатый коннектор, сломанный разъем, перебитые жилы в кабеле — вот небольшой перечень проблем, которые приводят именно к отсутствию линка. Разумеется, наши инженеры сразу взяли тестер витой пары и проверили соединение. Все жилы идеально прозванивались, оба конца кабеля были обжаты идеально. К тому же, включив в этот кабель тестовый ноутбук, мы получили как и положено соединение со скоростью 10 Мбит/с. Стало ясно, что проблема на стороне оборудования клиента.
Поскольку мы всегда стараемся помочь нашим клиентам в решении проблем, решили разобраться, что именно вызывает отсутствие линка. Внимательно изучили разъем порта MGMT — все в порядке.
Нашли на сайте производителя оригинальную инструкцию по эксплуатации, чтобы уточнить — возможно ли со стороны программного обеспечения «погасить» данный порт. Однако такой возможности не предусматривалось — порт в любом случае поднимался автоматически. Несмотря на то, что подобное оборудование должно всегда поддерживать Auto-MDI(X) — иными словами правильно определять какой кабель включен: обычный или кроссовер, мы эксперимента ради обжали кроссовер и включили в тот же порт коммутатора. Пробовали принудительно выставлять параметр дуплекса на порту коммутатора. Эффект был нулевой — линка не было и идеи уже заканчивались.
Тут кто-то из инженеров высказал абсолютно противоречащее здравому смыслу предположение, что оборудование не поддерживает 10BASE-T и будет работать только на 100BASE-TX или даже на 1000BASE-X. Обычно любой порт, даже на самом дешевом устройстве совместим с 10BASE-T и вначале предположение инженера отмели как “фантастику”, но от безысходности решили попробовать переключить порт в 100BASE-TX.
Нашему удивлению не было предела, линк мгновенно поднялся. Чем именно обусловлено отсутствие поддержки 10BASE-T на порту MGMT остается загадкой. Такой случай — очень большая редкость, но имеет место быть.
Клиент был удивлен не меньше нашего и очень благодарил за решение проблемы. Соответственно ему так и оставили порт в 100BASE-TX, ограничив скорость на порту непосредственно с помощью встроенного механизма ограничения скорости.
Отказ турбин охлаждения
Как-то раз к нам приехал клиент, попросил снять сервер и вынести его в сервисную зону. Инженеры все сделали и оставили его наедине с оборудованием. Прошел час, второй, третий — клиент все время запускал/останавливал сервер и мы поинтересовались, в чем же заключается проблема.
Оказывается, что у сервера производства Hewlett-Packard отказало две турбинки охлаждения из шести. Сервер при этом включается, выдает ошибку по охлаждению и сразу выключается. При этом на сервере располагается гипервизор с критичными сервисами. Для восстановления штатной работы сервисов требовалось выполнить срочную миграцию виртуальных машин на другую физическую ноду.
Решили клиенту помочь следующим образом. Обычно сервер понимает, что с вентилятором охлаждения все хорошо, просто считывая количество оборотов. При этом, разумеется, инженеры Hewlett-Packard сделали все, чтобы нельзя было заменить оригинальную турбинку аналогом — нестандартный коннектор, нестандартная распиновка.
Оригинал такой детали стоит около $100 и ее нельзя просто так пойти и купить — надо заказывать из-за рубежа. Благо в интернете обнаружили схему с оригинальной распиновкой и выяснили, что один из пинов как раз отвечает за считывание количества оборотов двигателя в секунду.
Дальнейшее было делом техники — взяли пару проводов для прототипирования (волей случая оказались под рукой — некоторые наши инженеры увлекаются Arduino) и просто соединили пины от соседних рабочих турбинок с коннекторами вышедших из строя. Сервер запустился и клиенту наконец-то удалось выполнить миграцию виртуальных машин и запустить сервисы в работу.
Разумеется, что все это было выполнено исключительно под ответственность клиента, тем не менее в итоге такой нестандартный ход позволил сократить простой до минимума.
А где же диски?
В некоторых случаях причина проблемы порой настолько нетривиальна, что на ее поиск уходит очень большое количество времени. Так и получилось, когда один из наших клиентов пожаловался на случайный отвал дисков и зависание сервера. Аппаратная платформа — Supermicro в корпусе 847 (форм-фактора 4U) с корзинами для подключения 36-ти дисков. В сервере было установлено три одинаковых RAID-контроллера Adaptec, к каждому подключено по 12 дисков. В момент возникновения проблемы, сервер переставал видеть случайное количество дисков и зависал. Сервер вывели из продакшн и приступили к диагностике.
Первое, что удалось выяснить — диски отваливались только на одном контроллере. При этом «выпавшие диски» исчезали из списка в родной утилите управления Adaptec и заново там появлялись только при полном отключении питания сервера и последующем подключении. Первое, что пришло на ум — программное обеспечение контроллера. На всех трех контроллерах стояли немного разные прошивки, поэтому было решено на всех контроллерах установить одну версию прошивки. Выполнили, погоняли сервер в режимах максимальной нагрузки — все работает как положено. Пометив проблему как решенную, сервер отдали клиенту обратно в продакшн.
Через две недели снова обращение с той же проблемой. Было решено заменить контроллер на аналогичный. Выполнили, прошили, подключили, поставили на тесты. Проблема осталась — через пару дней выпали все диски уже на новом контроллере и сервер благополучно завис.
Переустановили контроллер в другой слот, заменили бэкплейн и SATA-кабели от контроллера до бэкплейна. Неделя тестов и снова диски выпали — сервер вновь завис. Обращение в поддержку Adaptec результатов не принесло — они проверили все три контроллера и проблем не обнаружили. Заменили материнскую плату, пересобрав платформу чуть ли не с нуля. Все, что вызывало малейшие сомнения заменили на новое. И проблема вновь проявилась. Мистика да и только.
Проблему удалось решить случайно, когда стали проверять в отдельности каждый диск. При определенной нагрузке один из дисков начинал стучать головами и давал короткое замыкание на порт SATA, при этом какая-либо аварийная индикация отсутствовала. Контроллер при этом переставал видеть часть дисков и вновь начинал их опознавать только при переподключении по питанию. Вот так один единственный сбойный диск выводил из строя всю серверную платформу.
Заключение
Конечно, это лишь малая часть интересных ситуаций, которые были решены нашими инженерами. Некоторые проблемы «отловить» достаточно непросто, особенно когда в логах нет никаких намеков на произошедший сбой. Зато любые подобные ситуации стимулируют инженеров детально разбираться в устройстве серверного оборудования и находить самые разнообразные решения проблем.
Читайте также: