Пользователь
0,0
рейтинг
30 ноября 2015 в 13:14

Администрирование → Надёжность и долговечность серверного оборудования из песочницы

Решил написать эту статью после знакомства с публикацией «HP, Dell и IBM: компоненты, отвечающие за надёжность сервера», поскольку имею другое мнение насчёт некоторых моментов. Эта статья не претендует на инновационные подходы, а просто описывает полученный опыт и, надеюсь, предотвратит банальные ошибки.

Итак, начнём с того, что попробуем выяснить, зачем бесперебойность и беспрерывность серверам? Собственно, серверам бесперебойность не обязательна, но она нужна сервисам, которые предоставляют эти сервера. Наилучшая беспрерывность обеспечивается только распределёнными системами, которые могут функционировать независимо друг от друга с автоматическим переключением между ними (для скорости) и разнесённые географически (катастрофоустойчивость). Но это выдвигает особые (не всегда реализуемые) требования к программному обеспечению. Недостатками таких решений являются повышеная стоимость, проблемы с репликацией данных, передача состояния для бесшовного переключения на резервную систему. Дополнительными плюсами является то, что при правильной реализации системы, возможно повышение быстродействия — клиенты делятся между двумя или более локациями, а при сбое перераспределяются.

Но есть задачи, настолько критичные и специфические, что требуют особой бесперебойности серверов, для них делают особые сервера, например менфреймы, с возможностью горячей замены всех компонентов, включая процессоры, память и даже материнские платы. Но такие решения стоят гораздо дороже обычных серверов и те кто их покупает — понимаю зачем это надо.

Вернёмся к серверам начального и среднего уровней. Существенно повышает беспрерывность работы серверов возможность горячей замены компонентов.

Горячая замена блоков питания


В моей практике, сгоревших БП (блоков питания) было немного, но наличие в сервере hot-swap БП, подключённых по схеме N+N во многих случаях существенно увеличивает бесперебойность работы сервера. Если в сервере больше двух БП, то зачастую реализована схема N+1, что не позволяет питать сервер от двух независимых источников или линий питания. Электропитание с подачей в стойку двух независимых линий повышает бесперебойность в самых различных ситуациях, например при обслуживании или аварии систем энергообеспечения в датацентре. Был случай, в сервере вышел из строя БП и создал короткое замыкание, что привело к срабатыванию защиты PDU и его отключению, соседние сервера с БП по схеме 1+1, подключённые также к другому PDU продолжили работу. Резервирование БП позволяет изменять подключение сервера к сети энергообеспечения, не прерывая его работу, например, оптимизировать укладку кабелей (конечно, правильно укладывать кабеля надо при установке сервера, но мы живём в не идеальном мире).

Вопреки заблуждению сертификация 80 Plus указывает на энергоеффективность блока питания, и не обязывает производителя к обеспечению какого либо уровня надёжности.

Также резервирование БП предотвращает большинство проблем связанных с кабелями питания. Плохой контакт некачественных кабелей, случайное их выдергивание персоналом при работах. Если у вас сервер с одним блоком питания, использование для него качественного и неизношенного кабеля, который плотно устанавливается в гнездо, и при нагрузке не издаёт посторонних звуков (потрескивание) более важно — невозможна замена без остановки сервера. В случае сервера с резервированными БП, плохой контакт кабеля может привести к выходу блока питания из строя.

Горячая замена дисков


Горячую замену дисков можно производить практически со всеми вариантами интерфейсов. Конечно, есть и некоторые ограничения.

IDE устройства редко переносят отключение/подключение второго устройства на шлейф — велик риск пропадания работающего устройства из системы. Главная проблема интерфейса IDE в правильной обработке операционной системой этого события. Так как интерфейс IDE не предусматривает горячей замены, в большинстве случаев необходимо вручную запустить сканирование устройств для определения нового оборудования. Важный момент — интерфейс подключается/отключается к обесточенному диску (подключение: сначала интерфейс, потом питание, отключение: сначала питание, потом интерфейс).

ОТКАЗ ОТ ОБЯЗАТЕЛЬСТВ: выполняя отключение/подключение устройств IDE Вы делаете это на свой страх и риск — никто не гарантирует сохранение работоспособности оборудования, и стабильность работы ОС.

Интерфейсы FC, SAS, SATA (AHCI) — поддерживают горячую замену дисков в полном объеме, проблемы могут быть в операционной системе. Если дисковый контроллер SATA находится в режиме совместимости IDE — то, возможно, понадобится вручную запустить сканирование шины. В режиме AHCI в большинстве случаев диск определится автоматически. Рекомендую использовать AHCI, если ваша ОС это позволяет, т.к. этот режим также повышает производительнось диска; TRIM поддерживается только в этом режиме работы контроллера.

При отключении дисков для продления срока их службы рекомендую предварительно отключать их программным методом и извлекать после остановки шпинделя, т.е. через примерно 30 секунд после выключения для дисков 7200RPM. Если диск невозможно отключить программно и он установлен в hot-swap корзинке, рекомендую вытащить диск на минимальное расстояние, при котором диск будет отключен, подождать остановки шпинделя и извлечь окончательно. В большинстве систем — это расстояние полностью отведённой ручки корзинки. Конечно, эти действия не несут практического смысла, если диск вышел из строя, но, возможно, он просто «завис» и вам не поменяют его по гарантии и придется использовать в некритичном оборудовании.

Так же важно понимать, что диск находится в составе RAID или как отдельное блочное устройство. При использовании отдельного диска необходимо предварительно его отмонтировать для избежания сбоев в работе ОС и программного обеспечения. Даже если диск не используется в текущий момент, после извлечения примонтированого диска зачастую наблюдаются лаги всей ОС. Конечно же, диск, на котором установлена ОС, извлечь без «зависания» не получится.

Большинство серверов позволяет подсветить индикатором диск по команде с сервера, по возможности пользуйтесь этой функцией, для минимизации ошибочных извлечений дисков. Например на серверах SuperMicro номер корзинки указан на самой корзинке, и может не совпадать с номером слота на бэкплейне. Такая-же проблема есть у многих производителей.
Так же перед отключением желательно получить информацию о диске (модель, объем, серийный номер) для сопоставления сразу после извлечения диска. Во многих случаях при ошибочном извлечении другого диска это позволит устранить ошибку сразу, а иногда даже предотвратить сбой в работе или потерю данных.

В случае использования RAID-массивов, рекомендую отключать диски программно (помечать как сбойные), перед извлечением это устранит снижение производительности дисковой системы сразу после отключения диска.

Проблем с SSD дисками при частом горячем подключении/извлечении не заметил, хотя использовал несколько именно в таком режиме.

На этом первая часть заканчивается, в следующей частях про RAID массивы, память для серверов, системы удалённого управления и про важность мониторинга.
@daltin
карма
5,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (10)

  • +1
    Для того, чтобы понять что может произойти с SSD нужно просто вспомнить что флеш, сволочь, работает только с огромными блоками, а потому в большинстве SSD есть обычная память, где хранятся (во время работы) разные хитрые структуры данных. Соответственно есть шанс, что при отключении активно работающего SSD (такого, на который прямо в момент отключения кто-то что-то пишет) данные на самом флеше окажутся в «испорченном» состоянии и SSD «превратится в тыкву». Впрочем вероятность этого события всё-таки не так велика (прошивку SSD всё-таки не идиоты пишут), вы можете подключать/отключать SSD сотни, а то и тысячи раз, и не разу такого эффекта не получить.

    Впрочем добиться того, чтобы на устройство, которое вы отключаете никто в момент отключения не писал полезно и по куче разных других причин: если кто-то туда пишет, значит гарантированно часть данных потеряет. Оно вам надо?
    • 0
      данные на самом флеше окажутся в «испорченном» состояни

      Даже конденсаторы не спасут? Ими же усыпаны SSD с расчётом на запись подтвёрждыннх операций при пропадении питания.
      • 0
        Теоретически да, это не должно приводить к катастрофе, но вы же понимаете: это обратка ошибок. Кто и как их тестирует? Ошибок в коде обработки ошибок на порядок больше, чем где бы то ни было ещё.

        А если у вас какую-то важную структуру прошивка просто «забудет» записать, то никакие конденсаторы не спасут.
      • +1
        Вот на этот счет интересное исследование, если не боитесь читать сугубо научный текст по этой теме.
        https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf
        Это доклад на позапрошлогодней конференции USENIX FAST.
        • 0
          В сухом остатке: было испытано 15 железяк из которых большая часть выжила, одно издохло совсем, «с концами», одно потеряло доступ к трети записанных данных.

          Практические данные совпадают с теоретическими: вероятность того, что всё накроется медным тазом не так велика, но она таки есть, а про «просто» порчу данных я вообще молчу: только два из 15 устройств «проскочили» без потерь.
          • 0
            Сомнительное исследование в контексте серверов, большинство SSD бытовые, только в 4 из из 15 устройств были конденсаторы, да и сами модели 11-12 годов. А вывод вообще феерический:
            Because we do not know how to build durable systems that can withstand all of these kinds of failures, we recommend system builders either not use SSDs for important information that needs to be durable or that they test their actual SSD models carefully under actual power failures beforehand.

            Может быть есть что-то подобное от разработчиков SSD?
    • 0
      Большая проблема таки не в том, что устройство теоретически может похериться, а в том, что ОС не очень любит ВНЕЗАПНОЕ пропадание смонтированного устройства, и в определённых случаях может отправить работавшие с ФС процессы в Uninterruptible Sleep или вовсе упасть в Kernel Panic.

      Поэтому ВСЕГДА отмонтируйте все ФС на устройстве перед его извлечением, а также исключайте его из конфигурации mdadm/lvm/железного рейда/что там у вас ещё используется.
    • 0
      В статье рассматривались вопросы аппаратной части серверов, естественно что отключать диски SSD и HDD (как и флешки) с условием сохранения информации на них возможно только при предварительном размонтировании. Если извлечь диск, который используется (примонтирован, и какое-либо ПО обращается к нему) во всех операционных системах, с которыми я сталкивался, наблюдаются лаги. Спасибо за замечание — добавлю в текст статьи.
  • 0
    > Например на серверах SuperMicro номер корзинки указан на самой корзинке, и может не совпадать с номером слота на бэкплейне.

    А на других марках серверов кабеля к бэкплейну подключают сверхчеловеки и они же втыкают корзины с дисками?
    • 0
      Возможно всё, поэтому я рекомендовал подсвечивать диски (по логическому устройству, в некоторых, особо запущенных случаях, возможно, что система индикации подключена не правильно, и будет подсвечиваться другой диск — тогда это повод для исследования перед отключением диска) а кроме того, желательно сверять серийный номер диска после извлечения для проверки того, что извлечён правильный диск.

      Я написал про SuperMicro для примера, такая-же проблема может быть в корпусах Chenbro, AIC и так далее… В целом, SuperMicro делает хорошие корпуса среднего ценового диапазона, зачастую — лучший выбор по цене/качеству. И из серьёзных проблем вспоминается только плавающий баг с дисками SATA3 на бекплейне BPN-SAS-846EL (на BPN-SAS2-846EL устранена).

      При использовании экспандеров, нумерация дисковых слотов на них зависит от прошивки, и полностью не зависит от кабелей. Конечно, если в системе более одного экспандера, то порядок экспандеров зависит от коммутации кабелей.
      Например на Dell 720 (8 x 3,5") номера корзинок указываются на корпусе, номера слотов определяются бекплейном (бекплейн имеет только оди вариант установки), который подключен одним кабелем, я не видел ни одной возможности, что-то перепутать так, что-бы логическая и физическая нумерация перестали соответсвовать друг-другу.
      Конечно, существуют сервера (корпуса) на которых возможно перепутать кабеля, и физическая нумерация не будет соответсвовать логической, но эта проблема относиться к вопросам контроля качества сборки, а не обслуживания работающего сервера.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.