Моему серверу 4U 71 ТиБ ZFS, собранному из двадцати четырех 4-терабайтных дисков, уже больше десяти лет и он всё ещё отлично работает. Хотя сейчас у него уже вторая материнская плата и блок питания, система до сих пор не столкнулась ни с одной поломкой дисков (стучу по дереву).

Как же мне удалось добиться отсутствия отказов дисков в течение десяти лет?

Давайте сначала поговорим о самих дисках

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

Выключайте сервер, когда его не используете

Мой NAS по умолчанию выключен. Я включаю его дистанционно только когда мне нужно его использовать. Я использую скрипт, который включает питание сервера через «умную» IoT розетку, а после того, как BMC (Контроллер управления платой) завершит загрузку, я использую IPMI для включения самого дискового массива. Но я мог бы также использовать Wake-on-Lan в качестве альтернативы.

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

Мне было недостаточно просто выключить питание дисков, но оставить включенной материнскую плату, потому что это она потребляет 7 Вт (примерно, как два Raspberry Pi) в режиме ожидания. А с моим графиком это означало трату энергии впустую.

Для меня такой режим работы является комфортным, потому что я запускаю другие службы на устройствах с низким энергопотреблением, таких как Raspberry Pi4 или серверах, которые потребляют гораздо меньше энергии в режиме ожидания, чем мой «большой» NAS.

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

Вы можете также возразить, что мой случай не показателен и не репрезентативен и мне просто повезло и тут помогло большое число дисков. Но с преемником этого NAS с 20 дисками Samsung Spinpoint F1s объемом по 1 Тб история была такой же: у меня не было ни одной поломки диска в нем в течение всего срока его эксплуатации в течение 5 лет.

Материнская плата (вышла из строя один раз)

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

К счастью, такая материнская плата всё ещё была доступна на Ebay по хорошей цене, поэтому мне в итоге оказалось проще заменить ее на новую, чем ремонтировать старую. Мне нужна была именно такая же плата, потому что сервер использует четыре слота PCIe: 3 x HBA и 1 x 10Гбит NIC.

ZFS

Файловая система ZFS прекрасно отработала все эти годы. Я менял операционные системы на протяжении многих лет и никогда не сталкивался с проблемами при импорте пула в новую установку ОС. Если бы я собрался построить новое хранилище данных, я бы обязательно снова использовал ZFS.

Я запускаю проверку целостности zpool scrub на дисках несколько раз в год. Проверка ни разу не нашла ни одной ошибки контрольной суммы. За все время проверок с дисков считалось более петабайта данных. Так как выполнение проверки занимает примерно 20 часов и потребляет много электроэнергии во время выполнения, мне приходиться запускать ее в «дешевые» дни, когда стоимость электричества была минимальной.

И я совершенно не удивлен этим результатом. Отказ дисков чаще всего связан с риском возникновения следующих ситуаций:

1. Полный отказ, когда диск даже не определяется

2. Плохие сектора (проблемы при чтении или записи)

Существует и третий вид отказа, но он встречается крайне редко: молчаливая порча данных. Молчаливой она является потому, что или сам диск не осознает, что он оперирует поврежденными данными или SATA-соединение не обнаруживает никаких ошибок контрольной суммы при их передаче.

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

Каждый раз, когда вы слушаете энтузиастов ZFS, у вас может сложиться впечатление, что если вы не используете ZFS, то вы рискуете в один прекрасный момент потерять все свои данные. Я не согласен с этим, все зависит от контекста и обстоятельств. Хотя ZFS не так уж сложно освоить и, если вы хорошо знакомы с Linux или FreeBSD, эту файловую систему определенно стоит попробовать.

Уровень шума (очень тихо)

Мой NAS очень тихий для NAS. Но чтобы достичь этого, мне пришлось потрудиться. 

Его корпус содержит три мощных вентилятора на 12 В, которые охлаждают 24 отсека для дисков. Эти вентиляторы очень шумные, если они работают на своей стандартной скорости. Поэтому я решил, что мне хватит их работы на самой низкой скорости (холостом ходу) когда они почти не шумят. Поэтому мне пришлось добавить вентилятор для охлаждения четырех PCIe-карт (HBA и сетевой), иначе они сильно нагревались. Этот сетап обеспечивал достаточную циркуляцию воздуха большую часть времени, но его было недостаточно, так как диски со временем нагревались, особенно когда происходил процесс чтения/записи данных.

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

Я даже посетил математический подфорум и попросил у его постояльцев алгоритм, который лучше всего подошел бы для сохранения баланса охлаждения дисков и тишины. Кто-то посоветовал использовать «PID-контроллер», о котором я ничего не знал. 

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

Этот скрипт прекрасно работает на протяжении многих лет и поддерживает температуру дисков в пределах 40 градусов Цельсия или даже ниже. Как оказалось PID-контроллеры замечательное решение, и мне кажется, что их следует использовать в большинстве оборудования, которое управляет вентиляторами, температурой и так далее, вместо «тупого» включения/выключения по достижению порога или менее «тупого» задания параметров по таблице «Температура-Скорость».

Сеть

Я начинал с четырёхпортовых гигабитных сетевых контроллеров и использовал объединение сетевых интерфейсов (бондинг), чтобы добиться скорости передачи данных в сети около 450 Мбит/с между различными системами. Эта настройка требовала огромного количества UTP кабелей, поэтому я в итоге мне это надоело, и я купил несколько нормально работающих, но дешевых карт Infiniband. С ними я смог достичь скорости передачи данных между системами около 700 Мбит/с. Когда я решил отказаться от Ubuntu и вернуться к Debian, у меня возникла проблема: карты Infiniband в последней не работали, и я не смог найти, как это исправить. Поэтому я решил купить несколько б/у 10 гигабитных Ethernet карт, которые работают исправно до сих пор.

Проблемы с БП (помер)

При включении NAS все диски в нем запускаются одновременно (без последовательного запуска), что потребляет около 600 Вт в течение нескольких секунд. Мой блок питания имеет паспортную мощность 750 Вт, и линия на 12 вольт в теории должна была обеспечить достаточное питание, но иногда блок выключался при загрузке и в итоге не вынес такого режима и был заменен. 

ИБП (выбросил)

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

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

Резервное копирование (его нет)

Мои самые важные данные резервируются трижды. Многие данные, хранящиеся на этом NAS, не являются достаточно важными для резервного копирования. Я полагаюсь на замену оборудования и ZFS для защиты от потери данных из-за отказа дисков. Если этого окажется недостаточно, мне не повезет. И я живу с этим риском уже в течение 10 лет. Возможно, моя удача когда нибудь закончится, но пока я наслаждаюсь тем, что мне не нужно заботиться о бэкапе.

Планы на будущее хранилища (или их отсутствие)

Есть ли у меня планы, что делать дальше? Честно говоря, нет. Я собрал этот NAS изначально такого объема, потому что не хотел перемещать данные, если бы у меня закончилось место в хранилище. В итоге у меня все еще достаточно свободного места.

У меня есть запасная материнская плата, процессор, память и запасные HBA-карты, поэтому скорее всего я смогу восстановить систему, если что-нибудь сломается.

Поскольку размеры жестких дисков значительно увеличились, возможно я перейду от корпуса с 24 корзинами к форм-фактору меньшего размера. Можно создать тот же объем для хранения данных с помощью всего 6–8 жестких дисков с избыточностью RAIDZ2 (RAID 6). Но это будет таким же дорогостоящим проектом.

Еще один вероятный сценарий, что в ближайшие годы мой NAS все-таки сломается, и я решу не заменять его вовсе и мое «хобби по хранению данных» подойдет к концу.

Закажите VPS линейки Storage VPS line предназначенные для построения сетевых хранилищ данных со скидкой 25%!

А как вы продлеваете жизнь вашим дискам?