morfizm (morfizm) wrote,
morfizm
morfizm

Category:

Про бэкапы и домашний сервак - работает ли, доволен ли

В целом я доволен полученным опытом - это было интересно, прикольно, узнал много нового. Это был опыт из разряда "создай работающую модель реактивного самолёта из лего". Да, в результате кропотливой работы таки получается реактивный самолёт, и он даже летает, если очень аккуратно его запускать, и чинить когда ломается. Но при этом куда более cost-effective купить box solution с воздушным змеем или вертолётиком на радиоуправлении. В общем, те, кому не нужен реактивный самолёт, или кто не любит кропотливо собирать поделки из лего и потом их чинить, когда ломаются, не советую. В качестве забавного хобби-проекта - наоборот, рекомендую.

Что получилось в результате:

1. Сервер Lenovo Thinkserver TS140 70A4001LUX (такой или такой). Удачная и недорогая модель: он очень тихий. С кучей хардов в режиме "always on" он тише моего десктопа, даже когда он непрерывно делает random seek'и по хардам. В корпус легко влезают 5 хардов на 3.5" и 3x SSD. Я использую SAS card - IBM M1015 / 9220-8i SAS RAID Card - Flashed to LSI-9211-8i IT MODE.

2. 5 хардов на 3.5", модель WD Red (раньше были других моделей, но они постепенно умирали и я их заменял на WD Red, которые лучше), сейчас объёмы 2+3+3+5+5, с файловой системой ZFS в режиме RAID-Z2, т.е. два диска на избыточность, и три на данные. Используется только минимальный одинакового размера кусок с каждого диска, т.е. 2+2+2+2+2, т.е. 6 T на данные + 4 T избыточности. ZFS начинает сильно тормозить если заполнение выше 80%, поэтому реально полезного места под данные чуть меньше 5 T.

3. 3 SSD-диска, 2 на 120 GB (mirror configuration for ZIL, это transaction log, для ускорения записи), 1 на 160 GB (L2ARC, это read-кэш, для ускорения чтения). Специально выбирал Intel SSD 320 Series - SSDSA2BW12 (firmw 0362) - они надёжнее на случай отрубания питания, т.к. имеют конденсатор, дающий несколько миллисекунд работы, чтобы сбросить кэш на диск и не запороть данные. Более новые модели консьюмерских Intel дисков этого не имеют :) Забавно. Правда, я ещё использую UPS: CyberPower EC650LCD Ecologic 650VA/390-Watts.

4. Один канал гигабитного ethernet. При чтении не из кэша, эффективные IOPS примерно 400, и для больших файлов скорость передачи около 110 MB/sec. Это близко к максимально полной утилизации гигабитного канала. Почитайте форумы, там разный overhead из-за которого максимум несколько ниже 119 MB/sec, и всего 7.5% overhead'а это очень удачный результат. Кстати, "гигабитный канал" это 10^9 бит, а скорость копирования обычно в мегабайтах, которые 1 MiB = 2^20. Кстати, полученная скорость с учётом полного шифрования данных на дисках.

5. USB 3.0 docking station, к которой подключён бэкапный диск. Второй бэкапный диск off-site. Раз в два месяца rotation. Бэкапы, разумеется, тоже зашифрованные. Сейчас в rotation диски на 6 T и на 5 T. Эти диски тоже WD Red, в целях удобства upgrade. Например, когда 5 T мне будет мало, я куплю второй бэкапный диск на 6, а старый на 5 уйдёт внутрь вместо самого маленького, который там на 2. Тогда минимум станет 3, а не 2, т.е. 9 T на данные и 6 T на избыточность, 80% от 9 T - чуть меньше 8 T. Но теперь узкое место будут бэкапы, т.е. максимум 6 T. По сути, заплатил за 6-терабайтный диск, и увеличил объём полезного места на 1 T. Следующий апгрейд - подождать, пока появятся WD Red-ы на 8 T и заменить оба бэкапных диска (потратив деньги на 2 диска по 8 T, и приобретя ещё 2 T полезного места).

Я делал моделирование постепенных апгрейдов, с учётом всех избыточностей, а так же с учётом того, что покупать нужно самые большие диски, для которых цена за терабайт не оптимальна, там получается в среднем порядка 12:1 (платишь как за 12, приобретаешь 1). Радует только то, что пользователи, которые думают, что для получения +1 T свободного места достаточно заплатить за 1 T, это те пользователи, которые потом уныло разводят руками в случае сбоев и "потери всего". Я последний раз "терял всё" очень много лет назад, когда умерла моя единственная (на тот момент) 5-дюймовая дискета, мне было лет 11. После этого я научился записывать на 3 дискеты. Со временем я научился на каждую писать в нескольких копиях. Потом я научился записывать большие пустые файлы между копиями, чтобы при повреждении соседних дорожек, одна из копий всё ещё читалась. Я научился пользоваться ключом -rr в rar - добавление recovery record (на самом деле, сначала я научился ключу -hk в arj :)). Короче, сегодняшний setup это логическое продолжение давно начатого.


В 2015, по сравнению с 1995, появились новые проблемы сохранности данных:

1. Большие объёмы. На "одну дискету" (один жёсткий диск) всё уже не влезает. Несколько это сразу сложность. Я очень надеюсь, что в обозримом будущем появятся доступные SSD-диски большого размера (вроде 8 TB), и тогда можно будет опять упрощать и сводить к "одной дискете", возможно, повторенной несколько раз, не жертвуя скоростью доступа.

2. Объёмы настолько большие, что сбой чтения сектора на жёстком диске - не просто редкая неудача, а, скажем так, весьма вероятное и весьма ожидаемое событие при чтении всего диска подряд от начала до конца всего лишь один раз. Мне вначале казалось, что конфигурация Raid-Z2 (два избыточных диска из набора) делается для того, чтобы избежать проблем, когда второй диск "полетит" вскоре вслед за первым. Это действительно валидная проблема, особенно когда диски одной модели и из одной серии (есть корреляция сбоев, лучше покупать разные/отдельно, а не сразу несколько), но только для автоматической защиты от этой проблемы делают Raid-Z3. Raid-Z2 обычно делают для защиты от случайных сбоев чтения во время процесса "resilvering"-а. Raid-конфигурации предполагает последовательное чтение всех дисков для воссоздания избыточного диска. В этом процессе есть довольно значительный шанс ошибок чтения. Настолько значительный, что Raid-Z никто не советует использовать, даже дома. Минимум Raid-Z2. На самом деле, Raid-Z использовать можно, если не лень потом вручную восстанавливать побитые файлы из долгосрочного бэкапа, но это дополнительная ручная работа, плюс больше зависимостей на сохранность бэкапа (куда безопаснее минимизировать такие зависимости). Raid-Z3 пока используют только для производственных систем, не для дома.

3. Объёмы настолько большие, что "альфа-частица, попавшая в оперативную память, и вызвавшая bit flip" (случайную замену бита 0 на 1 или наоборот) - уже довольно вероятное событие. Я регулярно проверяю контрольные суммы на своих старых архивах, и наблюдал своими глазами файл, побитый в одном отдельном бите одного отдельного байта. Многие из современных форматов файлов, особенно не исполняемых, а "данные" (видео, фото, музыка) могут поглотить ошибку в одном бите - будет незаметный неправильный пиксель или вроде того. Но если этот бит попадёт в управляющие структуры, или в сжатый поток, то файл может вообще не открываться из-за такой ошибки. Если bit flip произойдёт при сбросе кэша метаданных файловой системы, то можно испортить не один файл, а много. В общем, bit flip-ы - реальная проблема даже для домашнего файлового сервера. Решение с FreeNAS + ZFS защищает от этого, потому что на всех операциях end-to-end checksumming, главное при этом использовать ECC-RAM (оперативную память, в которой не 8 бит на байт, а 9, один идёт на чётность). От одновременно двух bit-flip'ов оно не защитит (это всё ещё почти невероятное событие), но защитит от одного. ECC-RAM уже требует серверного билда, чтобы материнская плата и процессор её поддерживали. Многие NAS-девайсы, вроде Synology, дают ECC только для дорогих энтерпрайз-сборок. По этой причине они были мной забракованы при рассмотрении.

4. Эволюция форматов файлов. Файлы, сделанные очень давно, могут в какой-то момент просто перестать открываться. Или нужно будет ставить виртуальную машину, чтобы запускать OS 10-летней давности, в ней запускать вложенную виртуальную машину, чтобы запускать OS и приложение 20-летней давности, но вторая вложенная сама по себе не запустится, потому что она настолько устарела, что её можно запускать только из первой :) Ну и искать приложения 20-летней давности, к которым уже давно нет лицензионных версий, ключей, саппорта и прочего. По этому фронту я сделал довольно мало, но ещё лет через 10 эта проблема может стать актуальнее. Письма из разных систем я уже давно объединил в Outlook PST-файле, и там их храню. Но вот чаты нет. У меня куча логов от IRC/ICQ. С ними проще, это текстовые файлы. Но вот, скажем, логи Miranda это один ".dat"-файл, для которого когда-нибудь придётся писать парсер, если я захочу развлечения ради поднять эти логи. Файлы я, на всякий случай, храню, а парсер писать лениво :) Но надвигающаяся проблема чувствуется. Будет очень неприятно, если когда-нибудь перестанут открываться MHT/MHTML файлы - это файлы, содержащие всю страницу, включая CSS, JS и картинки в виде MIME-stream'а, как аттачменты в письмах. В этом формате я сохраняю понравившиеся мне веб-страницы, а также даже записи своего блога, потому что материал в интернете сегодня есть, а завтра нет, а если что-то понравилось, хочется иметь возможность, к этому вернуться. Надеюсь, есть люди, которые меня понимают :)

FreeNAS + ZFS решает первые три проблемы, плюс даёт performance и encryption.
К сожалению, он создаёт ряд новых проблем:

- FreeNAS вообще-то производственная система, требующая человека на обслуживании. Да, для домашних энтузиастов она годится, но только для энтузиастов, не для "нормальных людей". Нормальные люди должны были бы нанять обслуживающего человека, и это непропорционально дорого для домашних целей. Например, чтобы банально сделать rotation бэкапных дисков, я трачу минут 10 и исполняю сложную последовательность шагов, в которую входит SSH на сервер и запуск custom-script'а, чтобы изменить метки всех snapshot'ов так, чтобы FreeNAS репликация их заново копировала на новый диск.

- У FreeNAS сильно недоработана поддержка encryption. Один неровный шаг и что-то не работает, нужно заново создавать массив и восстанавливать данные из бэкапа. Таких шагов я сделал больше десятка. Уже научился "обходить все мины", но это дорого стоило. Опять же, в производственных системах encryption на уровне файловой системы, видимо, слишком редко нужен, а что непроизводственный сценарий, то плохо поддерживается.

- ZFS отличная файловая система, пока она работает. А когда возникает сбой, восстановление это мегагемор. Я умею идентифицировать и восстанавливать лишь некоторые изолированные проблемы, вроде битых файлов после corruption'а, но это настолько геморно, что я давно уже перестал это делать, считаю датасет убитым, и восстанавливаю его целиком из свежего бэкапа. За год я раз пять восстанавливал рабочий датасет, и раз в месяц пересоздаю бэкапный датасет (из-за сбоев, о которых ниже).

- USB 3.0 поддерживается плохо, а eSATA слишком чувствительный к reset'у, возникающему от малейших движений вокруг сервера. В свою очередь, ZFS уже слишком чувствительный к таким reset'ам, и, как правило, портит dataset. Самое дешёвое - считать его мёртвым и восстанавливать из бэкапа, или же, если это и есть бэкап, удалять его и заново создавать, а пока это происходит (скажем, сутки) - жить лишь с одним полным бэкапом 1-2 месячной давности. Что есть стрёмно, когда такое происходит регулярно. Я предпочитаю иметь рабочий датасет + два бэкапа, а ситуацию, когда из 3 живы только 2, это либо внештатная ситуация (что-то сломалось), либо крайне редкая и тщательно контролируемая, и при этом я заранее освежу все бэкапы, чтобы они не были застарелыми.

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

Для тех, кто захочет повторить мой путь и выбрать новое решение для домашнего файлового сервера, рекомендую против варианта с FreeNAS. Несколько общих советов:
- Старайтесь избегать любых Raid конфигураций кроме mirror из двух дисков. Для дополнительной избыточности лучше использовать софтварные решения по синхронизации. Хорошие Raid-контроллеры могут делать mirror (Raid-1) с удвоением IOPS на чтение, что будет good enough для домашних целей. Write-кэши и read-кэши можно реализовать через SSD + специальные директории и скрипты, которые будут копировать/переносить. Мне кажется, это было бы дешевле по обслуживанию, чем использование all-in-one "автоматических" решений, не важно, hardware-ных или software-ных. Ну или вообще отказаться от кэшей и терпеть тормозню.
- Старайтесь избегать нестандартных файловых систем. Выбор файловой системы должен быть такой, чтобы можно было вставить диск в другой компьютер, и на нём запустить инструменты для восстановления.
- Я не уверен, что вообще существует хорошее решение "для дома", дающее полный гигабит скорости и низкий latency, при этом дающий encryption, redundancy и защиту от bit flip'ов. FreeNAS + ZFS как бы всё это даёт, но очень большой кровью. От чего-то из требований надо отказаться, и, скорее всего, это будет performance.
- Для защиты от bit flip'ов нужно искать какое-то софтварное решение для checksumming'а, которое в нужный момент скажет, что файл требуется восстановить из бэкапа.
Tags: 1, devices, software
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 13 comments