План смягчения сбоев PDU?

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

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

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

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

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

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

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

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

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

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

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