Назад | Перейти на главную страницу

План по устранению отказов PDU?

Клиент только что испытал полный отказ APC AP7911A коммутируемый / измеряемый блок распределения питания стойки (PDU). Очевидно, это привело к отключению всего подключенного оборудования. Оборудование в порядке, как и вышестоящие ИБП.

В ситуациях, когда невозможно сбалансировать устройства между несколькими источниками питания / блоками распределения питания / блоками ИБП (например, коммутаторы с одним источником питания, отсутствие линий питания высокого напряжения и т. Д.), Как можно уменьшить подобные сбои? Это была установка в одну стойку в далеко не идеальном компьютерном зале, но типичном для большинства малых и средних предприятий. Следует ли планировать сбой отдельного PDU, или это просто что-то, с чем нужно справляться, когда это происходит?

Несколько блоков питания на серверах - это нормально, но не волшебная палочка. Часто, когда что-то связано с властью, они убирают другие вещи вокруг себя, например. объединительная плата, к которой подключаются оба ваших резервных блока питания. Гораздо больше шансов продолжить работу, если у вас есть два сервера на отдельных ИБП.

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

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

Я был в точно такой же ситуации, когда я сделал все возможное, чтобы обеспечить резервирование в кластере серверов, но ситуация была подведена из-за отказа одного источника питания, который, в свою очередь, вызвал появление устройства, которое только один БП выйти из строя. Иногда решающее значение имеет отдельный блок питания, например резервный постоянный ток, коммутатор или массив вентиляторов стоечного шкафа.

Лучший ответ, который я придумал, - использовать PDU с ** автоматическим переключателем передачи ** (ATS). Это позволяет подключить PDU к двум источникам питания, и он будет переключаться между ними без простоев в случае выхода из строя одного из них. Это идеально подходит для ваших устройств с одним блоком питания, очевидно, потому что они остаются включенными. Коммутатор ATS обычно имеет около 8 выходов, так что он эффективно заменяет PDU.

Для типичных сценариев SME, когда у вас нет двух цепей питания в центре обработки данных, но у вас может быть стойка, подключенная либо к одному ИБП и к сети, либо к сети через два ИБП, это обеспечивает хорошую защиту, иначе вы всегда будете ставка на то, какой источник PDU выйдет из строя первым. Я также считаю, что эти коммутаторы ATS более устойчивы, чем стандартные PDU, так что это еще больше снижает риск бедствий.

Я нахожусь в немного необычной ситуации, так как у нас есть несколько собственных центров обработки данных, и мы можем решать, как все работает, и мы используем блейд-серверы, но в целом у нас половина наших блоков питания идет на один PDU, а другая половина - на другой. PDU именно по этой причине. Теперь обычно оба PDU находятся на одном очень большом PDU / UPS, каждый из которых обслуживает несколько половинных рядов по 40 стоек. Итак, мы разбиваем наши кластеры по рядам, т.е. элемент кластера 1 в одной из первых 20 стоек первого ряда, номер 2 во вторых 20 стойках первого ряда, номер 3 в первых 20 стойках второго ряда и т. Д. таким образом мы застрахованы в случае потери блока питания, блока распределения питания, большого блока распределения питания / ИБП или всего ряда (из-за затопления, пожара и т. д.). Но, поскольку я говорю, что это немного необычно, но, надеюсь, дает некоторое представление о том, как мы это делаем, я всегда предлагал разные PDU, но убедитесь, что если вы используете несколько центральных / больших PDU и ИБП, вы не получаете слишком много фаз. из соображений безопасности (ищите в SF предыдущие межфазные аргументы :))

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

Я бы записал комплект, который настроен таким образом, если это возможно, и спланировал бы сбой, и ожидал бы его в какой-то момент.

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

Когда дело доходит до покупки нового комплекта, я бы купил эти серверы с двумя блоками питания и подключил каждый к отдельному ИБП (через PDU, если необходимо). Даже дешевые серверы Dell для малого и среднего бизнеса можно купить с двумя блоками питания.

Если вы не можете установить второй PDU в стойку, у вас нет другого выбора, кроме как настроить сервер таким образом, чтобы внезапные потери мощности нанесли лишь минимальный ущерб.

  1. Прежде всего, я бы обязательно использовал RAID-контроллеры с батарейным питанием, чтобы данные на диске были согласованными или, по крайней мере, могли быть приведены в согласованное состояние при восстановлении питания.
  2. Во-вторых, используйте журналируемые файловые системы. Это помогает поддерживать целостность файловой системы.
  3. В-третьих, попробуйте настроить все запущенные службы таким образом, чтобы было что-то вроде транзакций: все структуры данных можно было вернуть в согласованное состояние и при необходимости принять минимальную потерю данных (откат). Это сильно варьируется от сервиса к сервису (Базы данных, Частота модификаций, Журналы ...) и может потребовать, а может и не потребовать довольно много ручной работы с вашей стороны. Если это вообще возможно ...
  4. В-четвертых, соответствующим образом скорректируйте свою стратегию резервного копирования и постарайтесь создавать больше и меньше резервных копий (вместо нескольких больших).

Но, честно говоря, первые три не дадут вам 100% защиты. Будьте готовы к восстановлению из резервной копии в любое время.