Synology кэш ssd настройка

Обновлено: 05.07.2024

Компания Toshiba, крупный производитель флэш-накопителей и жёстких дисков, прогнозирует, что в 2019 году лишь 10% корпоративных данных будут храниться на SSD, хотя создаётся ощущение, что все производители СХД забыли про жёсткие диски и сконцентрировались на твердотельных накопителях. Однако, какие бы красивые IOPS-ы ни обещали нам пиарщики, что бы ни показывали синтетические тесты, реальная скорость типичной виртуальной машины зависит от того, как сконфигурирован ваш сервер и как работает само приложение. Большинство серверных программ, начиная от баз данных и заканчивая front-end с web-интерфейсом используют кэширование в ОЗУ, а значит могут вообще не зависеть от дисковой системы при любых нагрузках.

Современный корпоративный NAS - это не просто файлохранилка, но и вычислительный узел, на котором развёрнута контейнерная (Docker) и хост-виртуализация (гипервизор), а поскольку данные в такой системе хранятся на том же хосте, где и обрабатываются, запуская какое-либо приложение на гипервизоре Synology VMM, мы можем рассчитывать на определённые бонусы со стороны ОЗУ.

Во-первых, это кэширование в ОЗУ Diskstation/Rackstation всех файловых операций чтения виртуальной машины стандартным Linux-овским кэшем.
Во-вторых, это ускорение операций записи, которое достигается за счёт отсутствия прослойки между гипервизором и операционной системой. Например, при подключении хоста ESXi 6.x к NAS-у по протоколу NFS, все операции записи обязательно синхронизируются гипервизором VMware, что приводит к снижению скорости.
В-третьих, на Synology мы можем установить кэширующий сервер Redis, причем как в виртуальную машину, так и в саму DSM через community-пакеты или docker. У нас будет энергонезависимый RAM-кэширующий сервер, чья база данных лежит на RAID-массиве, ну не прелесть ли?

С третьего пункта, пожалуй, и стоит начать.

1.Самый действенный способ - использовать Redis

Если у вас уже есть готовая инфраструктура с серверами VMware vSphere, и вы приобретаете NAS только для хранения бэкапов или в качестве основной СХД, посмотрите на память: Synology RackStation RS18017xs+ имеет в базе 16 ГБ ОЗУ, которые можно расширить до 128 ГБ. Вся операционная система DSM (DiskStation Manager) редко требует более 2 ГБ ОЗУ, поэтому неиспользуемую память можно отдать под Redis. Это NoSQL сервер, который хранит данные в памяти, периодически сбрасывая свою базу на диск. При перезагрузке Redis восстанавливает базу с диска, загружая данные в ОЗУ, и даже при отключении электроэнергии, после перезагрузки вам доступны все данные с момента последней синхронизации. Внутрь Redis можно запихнуть не только строки, но и файлы, и если ваше приложение постоянно обращается к каталогу с десятками тысяч маленьких файликов (например при машинном обучении), то вы наверняка знаете, что в этом случае тормозит любая современная файловая система, а Redis - нет.

Redis можно установить через пакет Synology DSM, подключив репозиторий Synocommunity, но там лежит старая версия 3.0.5-5, поэтому лучше использовать Docker или виртуалку, запущенную на NAS-е. Устанавливаем пакет Synology Virtual Machine Manager и внутри разворачиваем 5-ю версию Redis-а на операционной системе Debian.

Давайте протестируем скорость доступа, используя встроенный бенчмарк Redis-а. Полтора миллиона транзакций в секунду в конвейерном режиме и пятьсот тысяч с настройками по умолчанию. Сам по себе Redis - однопоточный, так что вы можете клонировать виртуалку, чтобы задействовать более 1 ядра процессора NAS-а.

Пример с Redis наглядно демонстрирует, что сегодня рассматривать СХД только в качестве файлохранилки можно в двух случаях: когда речь идёт о домашнем 2-дисковом NAS-е или наоборот, когда мы говорим о мощной инфраструктуре банков или авиакомпаний. В остальном же - пожалуйста, вот вам централизованная кэширующая система: подключайтесь к ней и экономьте ресурсы ваших хостов. Вам даже не потребуется 10-гигабитное сетевое подключение: в типичных случаях использования, 1-гигабитной сети вполне достаточно для быстрой работы подключенных клиентов.

Ну и не забывайте, что Synology DSM может использовать защиту данных Redis-а снэпшотами на уровне файловой системы Btrfs. Конечно, использование Redis потребует от вас небольшую переработку приложения, что не всегда возможно, поэтому давайте посмотрим работу встроенного кэширования Synology DSM.

2. Кэширование в ОЗУ самого NAS-а

Даже если виртуалка под Windows или Linux занимает на диске сотни гигабайт, активно используются единицы или десятки гигабайт дискового пространства: логи и файлы баз данных, часто запрашиваемые файлы, в общем всё то, что не кэшируется в памяти самой гостевой операционной системы или приложения. Часто запрашиваемые блоки данных хранятся в ОЗУ самой Synology DSM, что мы многократно видели в синтетических тестах прямого файлового доступа. Механизм кэширования в ОЗУ лучше всего наблюдать на дисковых операциях случайного чтения.

На этой диаграмме - идеальный вариант доступа к тестовой области объёмом 16 ГБ. Почти вся она может поместиться в ОЗУ NAS-а, что и происходит в процессе теста. Обратите внимание: "раскачивается" NAS достаточно долго - около 10 минут, после чего выходит на максимальную производительность.

Когда кэш заполняется, скорость чтения вырастает в 3 раза, но всё равно остаётся небольшой по меркам того, что можно выжать из ОЗУ. Имеет ли смысл добавлять SSD для операций, использующих небольшую активную область раздела, способную уместиться в памяти СХД?

3. SSD кэш в реализации Synology

SSD-кэш может работать в двух режимах: только чтение и чтение/запись. В первом случае вам достаточно и 1 твердотельного накопителя, а во втором случае - потребуется как минимум пара для объединения в «зеркало». Кэширующие SSD можно объединить и в более сложные массивы, в том числе RAID 5, главное чтобы для кэширования записи поддерживалась отказоустойчивость.

В текущей версии DiskStation Manager содержимое SSD кэша чтения не сохраняется после перезагрузки NAS-а. То есть, после ребута вас ждёт некий период прогрева, хотя DSM начинает пихать данные на SSD буквально с первых минут после запуска. Для кэша чтения/записи такой проблемы нет.

Повторим наш тест, для чего сначала будем использовать 1 SSD в режиме кэша чтения, а затем 2 SSD в режиме кэша чтения/записи, объединив их в зеркальный RAID 1.

Мы видим, что SSD, мягко говоря, работают-то побыстрее, и зеркальный массив дополнительно увеличивает производительность за счёт чтения с двух накопителей одновременно. Но помимо того, что кэш SSD работает быстрее, он ещё и заполняется быстрее, что хорошо видно на логарифмической диаграмме.

Получается, что NAS не нужно упрашивать сохранить данные в кэше: SSD выходят на максимальную скорость уже через 3-4 минуты, а ОЗУ - через 10-15 минут. Кроме того, SSD-кэш активнее освобождает данные и перестраивается между нагрузками, хотя на диаграммах этого не показать. Но, как говорится, только чтением жив не будешь, и очень интересно, как поведут себя кэши в паттернах VDI и SQL задач. Мы будем использовать 2 размера области теста: 16 ГБ, сопоставимую с объёмом ОЗУ и 96 ГБ, в три раза больше, чем есть памяти в NAS-е.

Там где добавляется запись, уже нужно грамотнее подходить к выбору самих SSD, учитывая, что скорее всего они будут постоянно заполнены данными, и их скорость будет отличаться от максимальной. Увеличим тестовую область в 6 раз:

Кстати, Synology DSM постоянно отслеживает здоровье SSD-шек и предупредит, когда накопитель лучше заменить. Для HDD производства Seagate есть расширенная диагностика через систему IronWolf Health Management (читайте подробнее в нашем обзоре), но это сравнительно новая технология, и насколько она полезна, покажет время. Изменим паттерн на SQL, и посмотрим на поведение массива.

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

Тест Sysbench OLTP

Возьмём базу данных MariaDB в виртуалке с небольшим объёмом памяти, ну например 8 ГБ. Создадим таблицу в 50 миллионов записей с таким расчетом, чтобы её объём в 11.2 ГБ был больше ОЗУ, доступной для гостевой системы, но меньше ОЗУ NAS-а (16 ГБ) и заставим машину активно использовать диск в режиме транзакционной нагрузки, используя случайные запросы чтения. Проведём этот тест трижды: сначала виртуалка работает на хосте под VMware ESXi 6.7, подключенном по iSCSI, потом то же самое, но с NFS, а затем перенесём виртуалку в Synology Virtual Machine Manager, используя для миграции пакет Synology Active Backup for Business.

Тесты показывают, что сетевой трафик составляет 500-600 Мбит/с, но дисковая активность проявляется только в операциях записи, а значит Synology DSM одинаково хорошо кэширует и операции блочного доступа и операции файлового доступа, что не удивительно, поскольку iSCSI LUN-ы хранятся в виде файлов. Напомню, что наша тестовая RackStation RS18017xs+ имеет базовые 16 ГБ ОЗУ.

В данном случае SSD кэширование не даёт особых преимуществ из-за того, что часть виртуального диска, на котором лежит файл базы данных, легко умещается в ОЗУ NAS-а. Давайте создадим ситуацию, в которой объём базы данных сильно превышает свободную память Rackstation RS18017xs+. Увеличивать количество строк в тестовой таблице до миллиардов не получается: сильно начинает тормозить сама база данных, делая результаты не репрезентативными. Гораздо проще отнять лишнюю память у Synology DSM, для чего запустим в гипервизоре Synology VMM виртуальную машину с 12 ГБ ОЗУ, в результате под кэш останется всего около 2.5 ГБ.

И вот здесь SSD кэш сглаживает негативный эффект от нехватки памяти, хотя всё равно показатели чтения хуже, чем в предыдущем тесте. Нам нужно убедиться, что на скорость влияет именно отсутствие лишней памяти, а не гипервизор Synology VMM, для чего мы должны запустить тот же самый тест на самом NAS-е.

Переместив базу данных в гипервизор Synology VMM, нам пришлось добавить в RS18017xs+ ещё 16 ГБ памяти для того, чтобы сохранить возможность кэширования в ОЗУ NAS-а. Тесты показывают ту же производительность, что не удивительно, поскольку для всех файловых операций в СХД используется общий пул. То есть для практического использования базы данных можно вполне обойтись средствами Synology VMM, сократив количество серверов в вашей компании.

Углубляясь в настройки буферизации на уровне приложения и экспериментируя с параметром InnoDB Buffer Pool Size, я заметил, что при значениях от 1 ГБ до 6 ГБ, производительность существенно не меняется, так что выгоднее отдавать этот объём памяти NAS-у. Так поступают хостинг-провайдеры, предлагая в аренду виртуальные машины с небольшим объёмом памяти: база данных активно работает с дисковой подсистемой, в роли которой выступает СХД с SSD и большим объёмом памяти.

Причём, стоит отметить, что далеко не каждый SAN-массив имеет функцию кэширования в ОЗУ: буферизация LUN на уровне блоков - это редкая особенность, но у Synology сейчас даже iSCSI LUN-ы хранятся в виде файлов, поэтому помимо снапшотов по расписанию, DSM легко ориентируется в том, что нужно держать в памяти, а что - нет. Вот вам ещё один плюс NAS-ов перед SAN-ами.

Какие SSD выбирать?

Постарайтесь для SSD-кэширования выбирать накопители на основе MLC или SLC, но никак не 3D NAND TLC. По возможности, выбирайте SSD бизнес-класса, а в обзорах обращайте внимание на распределение IOPS по времени, как в нашем обзоре NVME SSD. Имейте в виду, что ваш SSD обязательно должен быть в списке совместимости Synology, и тогда за дисковый массив можно не переживать.

Выводы

Какие выводы можно сделать из нашего тестирования? Прежде всего, обратите внимание на то, насколько агрессивно Synology DSM записывает данные на SSD. Буквально считанные минуты под нагрузкой - и они копируются на SSD накопители, ускоряя и NFS подключения, и iSCSI LUN-ы. По синтетическим тестам, SSD работают даже быстрее ОЗУ, но на деле выходит совсем иначе: чем большое объём горячих данных в вашей инфраструктуре, тем больше памяти нужно установить в NAS, не важно, используются ли в нём жесткие диски, SSD или гибридные массивы.

Ну и наш пример с Redis-ом показывает, что если вы вступили на путь добра и решили вместо старой SAN-СХД установить современный умный NAS с виртуализацией, то используйте его возможности по-максимуму: совсем не обязательно стараться забить все отсеки хранилища твердотельными дисками - можно просто добавить поддержку NoSQL баз данных в ваш софт и на самой простой модели Synology серии Rackstation получить чудо-скорость, которую ещё очень много лет не дадут никакие SSD.

Большинство серверных программ, начиная от баз данных и заканчивая front-end с web-интерфейсом используют кэширование в ОЗУ, а значит могут вообще не зависеть от дисковой системы при любых нагрузках.

Во-первых, это кэширование в ОЗУ Diskstation/Rackstation всех файловых операций чтения виртуальной машины стандартным Linux-овским кэшем.

Во-вторых, это ускорение операций записи, которое достигается за счёт отсутствия прослойки между гипервизором и операционной системой. Например, при подключении хоста ESXi 6.x к NAS-у по протоколу NFS, все операции записи обязательно синхронизируются гипервизором VMware, что приводит к снижению скорости.

В-третьих, на Synology мы можем установить кэширующий сервер Redis, причем как в виртуальную машину, так и в саму DSM через community-пакеты или docker. С третьего пункта и начнём.

1.Самый действенный способ - использовать Redis

Это NoSQL сервер, который хранит данные в памяти, периодически сбрасывая свою базу на диск. При перезагрузке Redis восстанавливает базу с диска, загружая данные в ОЗУ, и даже при отключении электроэнергии, после перезагрузки вам доступны все данные с момента последней синхронизации. Внутрь Redis можно запихнуть не только строки, но и файлы, и если ваше приложение постоянно обращается к каталогу с десятками тысяч маленьких файликов (например при машинном обучении), то вы наверняка знаете, что в этом случае тормозит любая современная файловая система, а Redis - нет.

2. Кэширование в ОЗУ самого NAS-а

Эффективность кэширования в ОЗУ На этой диаграмме - идеальный вариант доступа к тестовой области объёмом 16 ГБ.

3. SSD кэш в реализации Synology

SSD кэш в реализации Synology SSD-кэш может работать в двух режимах: только чтение и чтение/запись. В первом случае вам достаточно и 1 твердотельного накопителя, а во втором случае - потребуется как минимум пара для объединения в «зеркало». Кэширующие SSD можно объединить и в более сложные массивы, в том числе RAID 5, главное чтобы для кэширования записи поддерживалась отказоустойчивость.

Кстати, Synology DSM постоянно отслеживает здоровье SSD-шек и предупредит, когда накопитель лучше заменить. Для HDD производства Seagate есть расширенная диагностика через систему IronWolf Health Management (читайте подробнее в нашем обзоре ), но это сравнительно новая технология, и насколько она полезна, покажет время. Изменим паттерн на SQL, и посмотрим на поведение массива.

3. Тест Sysbench OLTP

Проведём этот тест трижды: сначала виртуалка работает на хосте под VMware ESXi 6.7, подключенном по iSCSI, потом то же самое, но с NFS, а затем перенесём виртуалку в Synology Virtual Machine Manager, используя для миграции пакет Synology Active Backup for Business .

Какие SSD выбирать?

Постарайтесь для SSD-кэширования выбирать накопители на основе MLC или SLC, но никак не 3D NAND TLC. По возможности, выбирайте SSD бизнес-класса, а в обзорах обращайте внимание на распределение IOPS по времени, как в нашем обзоре NVME SSD. Имейте ввиду, что ваш SSD обязательно должен быть в списке совместимости Synology, и тогда за дисковый массив можно не переживать.

Выводы

В домашних сетевых накопителях возможность создать кеш на быстром SSD была всегда, но требовала установки твердотельного накопителя в один из доступных слотов для дисков. Из‑за этого особой популярностью она не пользовалась. Ситуация начала меняться три года назад с выходом Synology DS918+. В этой модели два выделенных разъема для компактных и быстрых SSD, выполненных в форм‑факторе M.2. В актуальной линейке Synology для домашних пользователей и энтузиастов (DS720+, DS420+ и DS920+) также есть слоты для кеша NVME. С учетом достаточно низкой стоимости современных NVME SSD трудно не уступить соблазну заполнить два пустующих слота.

Потенциальные проблемы

В большинстве статей раздел о потенциальных проблемах может располагаться ближе к концу текста, если вообще присутствует, но здесь явно не тот случай. Технология кеширования с использованием NVME — палка о двух концах, способная приводить к внезапным перезагрузкам устройства, неожиданной потере записываемых данных, деградации всего тома с последующим длительным (и неочевидным) восстановлением и исключительно быстрому, не оправданному записываемыми объемами данных исчерпанию ресурса перезаписи ячеек кеширующих SSD. При этом большинства проблем можно избежать, правильно выбрав накопители и правильно настроив кеш. К сожалению, большинство описанных ниже моментов не нашли отражения в документации Synology, из‑за чего пользователи снова и снова наступают на одни и те же грабли.

Спонтанные перезагрузки с потерей данных

При интенсивном использовании кеша в режиме r/w (для этого тебе придется создать зеркальный массив из двух NVME-накопителей) некоторые пользователи отмечали неожиданные перезагрузки устройства, приводившие к потере только что записанных данных (возникновение так называемой write hole). К примеру, пользователь DS918+ настроил пару не самых дешевых дисков Samsung 970 Evo в качестве кеша, но от потери данных его это не спасло. Аналогичную проблему обсуждают в соседней ветке. С чем это связано?

Дело здесь в том, что в некоторых моделях NVME-накопителей, основанных на технологиях TLC и QLC, после исчерпания объема SLC-кеша могут возникать задержки обработки команд записи. Вот готовый рецепт. Возьми пару самых дешевых NVME SSD самого маленького объема. Включи кеш на чтение‑запись и не забудь активировать режим сквозного кеширования последовательных операций. Отведи на кеш весь доступный объем накопителей — и начинай запись.

Все современные SSD кешируют операции записи. Записываемые данные сперва попадают в область псевдо-SLC, запись в которую происходит очень быстро. Накопитель будет уплотнять данные, перезаписывая их в TLC/QLC-ячейки в режиме простоя.

Поток данных не прекращается. Через короткое время SLC-буфер переполняется, и контроллеру SSD приходится одновременно принимать новые данные и уплотнять уже записанные. Свободные блоки быстро заканчиваются, и к операции уплотнения добавляется операция очистки ранее записанных блоков — а она в таких накопителях очень медленная. Через короткое время контроллер захлебывается, и очередная попытка записи приводит к тайм‑ауту.

Напомню, диски NVME подключаются не через контроллер SATA, который способен самостоятельно обработать ошибку, а напрямую к шине PCIe. Пользователи модели DS918+ отмечали, что возникновение тайм‑аута при записи приводило к спонтанной перезагрузке устройства с последующей деградацией как кеша, так и всего тома (кеш r/w становится его неотъемлемой частью).

Подобные ошибки отмечали пользователи разных моделей Kingston и ADATA с контроллерами SMI. Отдельные пользователи жалуются на периодические ошибки тайм‑аута с накопителями WD Black; в то же время диски Samsung 970 Evo в возникновении этой ошибки не замечены (впрочем, как и любые другие диски, эти модели также подвержены преждевременному износу).

Справедливости ради — я не слышал о возникновении подобных ошибок в устройствах поколения 2020 года.

Преждевременное исчерпание ресурса SSD

Пользователь DS918+ и пары Samsung 960 Evo 256GB отмечает преждевременное исчерпание ресурса SSD. На SSD записано всего 30 Тбайт данных, что даже отдаленно не приближается к заявленному производителем ресурсу. Брак? Возможно, но маловероятно: случай не единичный.

В этом и подобных случаях проблема в факторе коэффициента усиления записи (write amplification), а точнее — несовпадение оптимального для SSD сценария работы с фактическим.

Продолжение доступно только участникам

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

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

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

Некоторое время назад мы с Вадимом Сержантовым из Synology беседовали о выборе NAS. До разговора я был своим аппаратом полностью доволен, и никаких апгрейдов не планировал.

Но сначала Вадим рассказал о Synology Hybrid RAID – фирменной технологии хранения данных, позволяющей отдавать пользователю максимум пространства на дисках в массиве без ущерба для сохранности данных.

А потом мы подняли тему кэширования при помощи SSD, и я вспомнил, что можно распространить этот процесс не только на чтение, но и на запись.

В процессе монтажа ролика идея улучшить NAS постепенно крепла, и в итоге все вылилось в небольшой апгрейд на 104 тысячи рублей.

Три Железных Волка

Под потолком кладовки у меня уже два года работает NAS Synology DiskStation DS918+. Это четырехдисковая модель на четырехъядерном процессоре Celeron J3455. Уже вышла обновленная модель DiskStation DS920+, но различия не настолько критичны, чтобы я решил поменять устройство целиком. Сама Synology говорит о 15%-м приросте производительности, что, конечно, неплохо. Но для тотального апгрейда я подожду модель на новых 10-нанометровых Celeron, анонсированных в начале 2021 года. Вот там, думаю, ускорение будет посерьезнее.

Внутри NAS жило три накопителя. Все Seagate IronWolf, только два по 12 Тбайт и один на 16 Тбайт. Первая пара использовалась в режиме RAID 0, то есть просто объединяла пространство без потерь места, но и без защиты. Третий, большой IronWolf был самостоятельным томом, и NAS делал на него бэкапы ценных данных с пары 12-терабайтников.

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

Плюс один диск у меня все равно оставался практически не используемым. То есть место вроде как есть, но занимать его особо нечем, да и для бэкапов надо оставить. Можно «приклеить» его к первому тому и сделать массив типа RAID 5 (с безопасностью для одного диска), но тогда четыре терабайта повиснут в воздухе и не будут использоваться вообще ни для чего.

12-терабайтники трудятся с конца 2017 года. По SMART нулевые, будто только с завода, да и гарантия еще до декабря 2022 года. Думаю, еще сто лет проработают. Но покупать к ним в компанию молодой экземпляр того же объема вроде как странно…

В общем, решил подойти к вопросу радикально: изъять 12-терабайтные диски, а к почти юному 16-терабайтнику (выпущен 26 марта 2019 года) купить пару новых дисков его объема. Сделать из них RAID 5 и забыть о тревогах.

У этого блестящего плана был только один недостаток. А именно цена его реализации. Несмотря на то, что объем 16 терабайт уже не максимальный (есть модели на 18 Тбайт), стоит такое пространство недешево. IronWolf Pro, как у меня, обойдется по 50 тысяч рублей за экземпляр.

Выдохнув, я стал искать варианты подешевле. И быстро нашел. У Seagate есть семейство Exos X, которое, судя по характеристикам, почти идентично IronWolf, да и гарантия такая же пятилетняя. Но вот цена существенно ниже: 16 Тбайт обойдутся в 35 тысяч вместо 50. А время на отказ вообще вдвое больше: 2.5 миллионов часов вместо 1.2 миллиона у IronWolf Pro.

Да, Exos X – это формально не специальная модель для NAS, а «диск корпоративного класса». Но если некая модель официально поддерживает режим 24х7, не имеет официальных ограничений по объему рабочих данных и использует технологию записи CMR, то, скорее всего, для NAS она подойдет. По крайней мере, Synology линейку Exos X для моего 918+ одобряет.

Для тех, кто не очень погружен в тему, уточню насчет странных букв CMR. Это Сonventional Magnetic Recording, то есть традиционная магнитная запись. Некоторое время назад появилась еще технология SMR (Shingled Magnetic Recording), так называемая черепичная запись. Она позволяет упихивать на пластину больше данных и, таким образом, сокращать количество «блинов» в накопителе. Но есть проблема, как на дешевых SSD: как только объем записываемых данных забьет кэш накопителя, скорость резко падает. Оно не очень страшно в настольном компьютере, а вот в NAS, да в RAID-массиве приводит к крайне неприятным последствиям. Тем не менее, и WD, и Toshiba почему-то используют SMR в некоторых NAS-накопителях, не предупреждая об этом в спецификациях. Мне такое веселье уж точно не нужно. И именно поэтому выбирал только среди Seagate.

Выбирал, выбирал, и в итоге все же взял IronWolf Pro. Да, жаба негодовала. Но все же, когда речь идет о массиве RAID 5, есть смысл собирать в нем совершенно одинаковые по характеристикам накопители. Если бы покупал три диска сразу, тогда бы, почти уверен, взял Exos X, ну потому что они хорошие и существенно дешевле. В моем же случае воспоминания о дивной экономии быстро сотрутся, а сомнения могли бы остаться. Лучше обойтись без них.

Переезд

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

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

Виртуальная машина с Windows 10 тоже переехала на новый том без приключений. Просто создал резервную копию приложением Active Backup for Business (оно бесплатно устанавливается на NAS Synology из встроенного магазина), а потом развернул образ после загрузки с нового тома.

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

Последним этапом стало добавление в массив из двух новых 16-терабайтных IronWolf Pro еще одного, самого первого. Процесс добавления занял примерно 5 суток, причем это вообще не зависит от объема данных – только от емкости самого накопителя.

И вот когда все закончилось, у меня включился режим защиты данных для отказоустойчивости одного диска. Из суммарных 48 терабайт (звучит-то как!) в моем распоряжении находится 32. И если квакнется один из накопителей (ну, мало ли), с данными ничего не случится. Надо будет просто вставить еще один такой же, и еще через пять суток массив снова восстановит отказоустойчивость.

Так что можно теперь не заморачиваться с перекрестным копированием папок. И не очень задумываться о том, сколько еще места есть в запасе. Много есть. Хватит.

Твердая вишенка на торте

Для кэширования данных у меня уже давно стоит SSD Kingston SKC1000240G. Объемом, как можно заметить по названию, 240 гигабайт. Модель довольно старая, с производства давно снятая, но крайне выносливая: после двух лет круглосуточной эксплуатации в NAS никаких признаков старения не наблюдается.

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

Точно такой же SSD сейчас можно найти разве что на Авито, да и то неясно – в каком состоянии. Покупать наследника бессмысленно: он отличается весьма радикально, да вдобавок его скоростные возможности чрезмерно избыточны для NAS. Как я понимаю, реальная скорость SSD в моем случае ограничена пропускной способностью SATA III, то есть 6 Гбит/с. Вкладываться в серьезный накопитель в данном случае не очень оправданно.

В итоге купил Silicon Power на 256 Гбайт (модель SP256GBP34A80M28). Тоже не самая простенькая модель, но все недорогая и, что немаловажно, выдерживающая поток записи на максимальной скорости до 10 Гбайт подряд. Но и после превышения рубежа скорость падает не до нуля, а до 500-600 Мбайт/с, что все равно вполне достаточно.

Для включения кэширования записи SSD объединяются в массив типа RAID 1, и объем его будет ограничиваться меньшим из накопителей. То есть в моем случае это 240 Гбайт. Процесс включения кэширования элементарен, справится даже умная бабушка.

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

Итого

Я проапгрейдил в своем NAS все, что можно. Ну, почти все.

Оперативная память была добавлена еще раньше, сейчас ее 12 Гбайт. Больше ставить никакого смысла нет.

Один свободный слот оставлю на аварийный случай, когда надо будет срочно сбросить какие-то данные. Но, надеюсь, это вообще не пригодится.

Есть способы сделать из SSD не кэш, а полноценный том. Пока это шаманство (хоть и не сложное), но после выхода обновления операционной системы до 7.0 станет стандартной функцией. В принципе, можно будет прикупить пару терабайтных SSD и сделать RAID 1. Задач под это пока не вижу, но как красиво, RAID на SSD!

Умный сетевой диск (NAS) остается штукой не очень бюджетной. А если все сделать по уму, то и вообще дорогой. Моя коробочка, даже с учетом морального старения платформы, стоит за 200 тысяч. Но все же свое домашнее облако с приличной производительностью и (почти) безграничным пространством – это круто. Разок попробуешь – уже не слезешь.

Читайте также: