22 марта 2015 г.

Ввод серверов в эксплуатацию

Приходит новый сервер, покупается или откуда-нибудь отдаётся.Не особо важно каким путём пришёл сервер, хотя вроде NSA любит перехватить и насыпать имплантов, сколь старый он или новый.
Если старый(3-5 лет), то смотрим на состояние кулеров, кондёров на материнской плате и в блоках питания. Кулеры я обычно смазываю, хотя наработка на отказ у них довольно приличная.Обязательно чистим от пыли все элементы.
В целом всё написанное ниже справедливо и для бывшего в эксплуатации, и нового серверов.

Пару раз слышал, что если он брендовый, то должен работать из коробки.Если что-то не работает то можно смело отправлять обратно.Это мнение вроде как относится больше к блейдам, чем к не очень сложным 1-4U серверам.

По своему опыту скажу что бренды брендами, специалисты/сборщики/etc через руки которых прошёл сервер аналогично. Нахрен никому не доверяем и проверяем сами.Default distrust почти как defaul deny.
Основную информацию можно почерпнуть в мануалах к корпусу сервера/сhassis, дисковой панели/backplane, мат.плате.Как достать сервер из коробки, как открыть корпус, важные распиновки, тонкие моменты, инструкции по устранению проблем и обновлению прошивок и т.д.В общем всё должно быть.

Память
Проверяем правильность установки модулей.Обычно информация публикуется в виде таблицы в мануале к материнской плате, описывающей установку модулей в зависимости от количества процессоров на борту.
DELL 2950 например при загрузке ругается:"Эй кто там у руля?Ты как модули вставлял?У тебя не оптимально по слотам, вот как оптимально").
Был однажды мощнейший косяк.Vmware ESXi 5.x постоянно улетал в свой фирменный PSOD,но в диагностической информации про память ничего явно не указывал.В логах полнейший хлам.Наверное раз на сороковой написал о памяти.Проверили, пара модулей не в тех слотах была.Так как сервер был уже в продакшене, то выяснялся этот факт очень долго.
Память тестируем Memtest'ом
Процессоры
Визуально посмотреть монтаж кулеров. Тут особо ничего не могу сказать, каких-то косяков с монтажом не встречал.
Диски/Дисковая система
Проверяем на чтение.При проведении тестов необходимо посмотреть температуру дисков.
Victoria 4.46 - В общем-то легендарная программа.Не помню что там с большими дисками у нас, вроде до 2 TB поддерживает адресацию.Есть версия 4.47 работает на x64 и имеет ряд изменений.
Hard Disk Sentinel - Не менее легендарная программа, как наиболее развивающаяся и поддерживаемая.Снискала моё уважение к разработчикам возможностью через драйвера производителей контроллеров отображать(не всегда) состояние дисков, s.m.a.r.t., сколько записано данных и прочую информацию, находящихся в RAID массивах уровней 1, 5, 10.Есть версии под Linux, есть версии с централизованным управлением.Естественно не бесплатно.Вроде как аж существует с 2002 года.Так же есть тесты на чтение и запись, различных конфигураций и настроек.С дисками большого объёма проблем нет.

Лично моя фишка, но не знаю возможно так тоже кто-то делает.В корзине переписываю положение дисков и записываю их серийные номера в простую таблицу.Для лучшего понятия как располагаются диски по слотам и их же подключению к raid контроллеру. ОБЭП приходил?А если придут и диски с серверов по выкрутят?А иногда выкручивать их будете не вы, а кто-то совсем другой.Самое забавное будет при восстановлении  сервера.Как потом собирать диски на контроллерах неясно.Хотя есть такие монстры как R-Studio от RTT и RAID Reconstructor от Runtime.С помощью которых можно манипулировать подключёнными дисками или их образами, восстановить логическую структуру массива и получить доступ к данным.Но если дисков будет очень много?В общем всё к тому что времени чтобы вернуть назад будет потрачено очень много.Я подразумеваю, что у вас всё-таки имеется серверная комната.С надлежащим к ней доступом(решётки, двери и т.д.)Чтобы абы кто не подошёл к серверу и не задумал посортировать диски в корзине.Сама ситуация абсурдна, но бывает же всякое.
И кстати подход малоэффективен, если вы работаете в отделе и такую практику не используют другие.Со временем диски могут замениться на другие, а информацию по серийникам и логической структуре обновить будет некому.
Есть утилиты от производителей контроллеров для управления и мониторингом состояния рейд массива, такие как Adaptec Storage Manager/Maxview, Intel RAID Web Console, LSI MegaRAID Storage Manager и другие.Очень немаловажно настроить оповещение в почту о состоянии массива, чтобы держать руку на пульсе.Практически со всеми из них работал.Утилиты от Adaptec, про остальные не в курсе, если настроено оповещение на почту о состоянии массива(конкретно info/informational) отсылают информацию о дисках и серийных номерах.Про сохранение конфигурации raid массива и выгрузки её куда-либо надо будет дополнительно посмотреть.

Немного непонятно мне как поступать с различными схд, там где дисков не просто много, а очень много.Там где диски за 6TB и выше.Их тестирование на чтение занимает весьма продолжительное время.

Сетевые адаптеры
Тут мне сложно что-то советовать.В большинстве своём всё зависит от качества драйверов той программной платформы которую вы будете использовать на сервере.
Iperf и gui к нему Jperf Под множество платформ это касательно бесплатного.
Ixia IxChariot - целая коммерческая платформа.Бесполезно рассказывать, что может продукт.Лучше почитать на сайте в брошурах. Там полно практических сценариев тестирования.Высокопрофессиональное решение.
Общая логика таких продуктов: клиент(endpoint)+сервер.Между ними гоняется трафик.По итогу выводится информация по скорости, строятся графики и т.д.
Особых проблем с серверными сетевыми адаптерами не встречал.

Прошивки, bios...
Шить всё подряд лишь бы было всё последних версий явно не стоит.Лучше сначала почитать changelog'/release notes, если они имеются.Справедливо для всех компонентов.

Столкнулся  с проблемой связки материнской платы Supermicro X9SCI-LN4F и контроллера Adaptec 5805.Рекомендации от обоих производителей советовали обновить bios'ы.Обновил и проблемы ушли.

Сетевые адаптеры.Тут ничего не могу сказать.

Интерфейсы удалённого администрирования(bmc, idrac, ipmi...).Обновляем до последних(если не последние из коробки), если таковые имеются.Ранее ни за что бы не подумал.Почему
http://ptsecurity.ru/ics/ipmi_v7_fix.pdf , чтобы потом не участвовать в ботнетах как это было у нас.Терять контроль над серверами и т.д.

Тут же надо настроить внутренние сервисы, которые вам нужны на этот удалённом интерфейсе.Snmp, ssh, telnet, web и прочие.

Нагрузки
По дисковой системе в приницпе написал, что при тестах дисков необходимо понаблюдать за их тепмературой, не выходит ли она за критические рамки.
Нагрузить процессоры такими стресс тестами как Linpack+Gui(LinX) и OCCT Perestroika Посмотреть температуры при пиковой нагрузке.Подержать сервер при полной нагрузке, тем самым "прогрев его".Посмотреть изменения скорости вращения кулеров от состояния покоя и при полной нагрузке.

Роли сервера.Системы мониторинга.Сайзинг.
Воспроизвести роли под которые предназначается сервер и посмотреть, что нет явных проблем с драйверами и любых других.Тут уже на самом деле больше по софту и тому факту под какие задачи подбирался сервер, тянет он или нет.Так как вариаций и ролей применения сервера может быть много, то что-то писать по этому поводу нецелесообразно.Это на вашей совести.Могу добавить, что иногда обстановка постоянно меняется и один сервер может пересобраться в другой, одна роль перейти в другую, нагрузка может возрасти.Какой никакой запас по мощностям должен присутствовать.
Про мониторинг и сайзинг...Тут трудновато.Zabbix меня выручал уже бесчисленное количество раз именно по ресурсам.Хоть и говорят, что он усредняет значения.Сейчас проводим большое преобразование инфраструктуры.Когда есть данные(значения, графики) того что было до и после, можно планировать апгрейды и закупки, и немаловажно аргументировать их необходимость руководству цифрами, подводить рациональную базу и думать об успешности проведённых покупок/мероприятий.
С интерфейсов удалённо администрирования(bmc, idrac, ipmi...) можно получать полезные данные о температурах, скоростях вращения кулеров, напряжениях в блоках питания.
Постоянно сталкиваешься с тем, что этой самой базы просто нет."Просто работает", "просто не работает".Вот и вся аргументация.
Да в цифрах и значениях как-то самому приятнее.Математика как никак царица наук, если по Гауссу.
Восстановление
Тут больше наверное за дисковую систему надо переживать, потому что все остальные компоненты в принципе заменятся целиком.Если вы конечно не паяете всё подряд.
По данному поводу сам пишу в первые.Общие рекомендации тут такие, что необходимо продумать свои действия при выходе одного и более дисков в массиве.Сможете ли вы заменить диски так, чтобы не потерять данные?.Сможете ли вы какое-то время протянуть на деградировавшем массиве?.В одних конфигурациях это легче, в других сложнее. Соответственно все действия производятся, только в том случае, если вы адекватно понимаете структуру массива.

Зачем всё-это?!
По итогу можно получить что-то вроде  отчёта с параметрами и настройками сервера, что по моему скромному мнению позволит траблшутить его в будущем.
В большинстве всё это для СВОЕЙ личной уверенности в том, что введённый сервер работоспособен и не упадёт через 5 4 3 2 1.Всё проверено и аргументировано.Вы не подведёте компанию, её сотрудники будут работать, а она не потеряет контракты/клиентов/деньги от простоев и начальство не будет смотреть на вас косо как на непрофессионала.
Может где-то подход перегнут, может где-то глуп ,во многом конечно рутина.Если в который раз подумать, сколько можно сэкономить нервов, времени и денег за простой сервисов всего лишь одним  своим отношением к делу, то мероприятия описанные выше проводятся не зря.

Вместо заключения.
Пусконаладочные мероприятия это целый процесс в контексте всей инфраструктуры в целом, который требует понимания и осознанных действий как в аппаратных так и программных областях.
Интересно есть ли что-то подобное описанное выше у интеграторов.Есть ли какие-нибудь инструкции и порядки.Подпадает ли описанное выше под "управление конфигурациями/состояниями"
Из литературы на русском могу посоветовать:
Скот Мюллер - Ремонт и модернизация серверов
Лимончелли Т., Хоган К., Чейлап С. - Системное и сетевое администрирование. Практическое руководство.Разделы посвящённые серверам.

P.S. по возможности буду дополнять какими-нибудь моментами из практики.

Комментариев нет:

Отправить комментарий