Lvmcache (7) — linux manuals

Настройка TRIM в дистрибутивах systemd

В данном разделе показано, как настроить периодический запуск TRIM в дистрибутивах, которые используют систему инициализации systemd.

Ubuntu 16.04

Дистрибутив Ubuntu 16.04 предоставляет сценарий, который еженедельно запускается с помощью cron.

Примечание: Стратегия настройки TRIM в Ubuntu 16.04 не зависит от systemd и отличается от остальных дистрибутивов этого типа.

Чтобы просмотреть сценарий, введите:

Как видите, сценарий требует версии fstrim с флагом –all. Многие версии fstrim, поставляющиеся в ранних версиях Ubuntu, не поддерживают этого флага.

Другие дистрибутивы systemd

В остальных дистрибутивах на основе systemd поддержка TRIM включается в файле fstrim.timer, который запускает операции TRIM на всех доступных смонтированных устройствах один раз в неделю. Он тоже использует опцию fstrim —all.

На момент написания этого руководства к таким дистрибутивам относятся:

• Debian 8
• CentOS 7
• Fedora 24
• Fedora 23
• CoreOS

В CentOS 7, Fedora 23, Fedora 24 и CoreOS юниты fstrim.service и fstrim.timer доступны по умолчанию. Чтобы настроить еженедельный запуск TRIM на всех смонтированных накопителях, включите юнит .timer:

sudo systemctl enable fstrim.timer

В Debian 8 юниты fstrim.service и fstrim.timer доступны внутри файловой системы, но по умолчанию не загружены в systemd. Сначала просто скопируйте эти файлы:

sudo cp /usr/share/doc/util-linux/examples/fstrim.service /etc/systemd/system sudo cp /usr/share/doc/util-linux/examples/fstrim.timer /etc/systemd/system

Затем вы можете активировать этот юнит так же, как и в других дистрибутивах.

sudo systemctl enable fstrim.timer

Теперь команда TRIM будет выполняться на всех доступных устройствах раз в неделю.

Как SSD-накопители хранят данные?

Чтобы лучше понимать, какие именно проблемы устраняет TRIM, нужно ознакомиться с особенностями хранения данных на SSD.

Ограничение циклов перезаписи

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

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

Восстановление устаревших страниц

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

Как работает TRIM?

Процессы сборщика мусора SSD отвечают за удаление блоков и выравнивание износа устройства. Однако файловые системы, как правило, удаляют данные, просто отмечая занятое ими пространство как доступное для записи пространство. На самом деле они не удаляет данные из базового хранилища, а просто позволяют перезаписать ранее занятую область памяти.

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

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

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

Когда SSD-кэш будет полезен

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

На практике появление случайных запросов среди равномерной последовательной нагрузки совсем не редкость. Это может происходить при одновременной работе на сервере нескольких различных приложений. Например, одно имеет установленный приоритет и работает с последовательными запросами, а другие время от времени обращаются к данным (в том числе, повторно) в случайном порядке. Другим примером возникновения случайных запросов может быть так называемый I/O Blender Effect, который перемешивает последовательные запросы.

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

Рисунок 1. Равномерный временной интервал с предсказуемой частотой обращений

При большом количестве таких обращений пространство SSD-накопителей будет быстро заполняться, и производительность системы будет стремиться к скорости работы на HDD-накопителях.

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

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

Посмотреть свободное место на диске

Рассмотрим теперь вопрос, как удобнее всего смотреть свободное место на диске. Тут особо вариантов нет — используется известная и популярная утилита df.

# df -h

Команда показывает информацию и заполнении всех примонтированных дисков, в том числе и сетевых, если они присутствуют в системе. Нужно понимать, что эта информация не всегда достоверная. Вот пример такой ситуации — Диск занят на 100% и не понятно чем, df и du показывают разные значения.

Сразу же покажу удобную комбинацию команд, чтобы посмотреть, кто в данной директории занимает больше всего места. Директории выстроятся в список, начиная с самой объемной и далее. В моем примере будут выведены 10 самых больших папок в каталоге.

# du . --max-depth=1 -ah | sort -rh | head -10

В первой строке будет объем самой директории /usr, а далее вложенные в нее. Привожу пример небольшого скрипта, который я люблю использовать, чтобы оценить размер директорий, к примеру, в архиве бэкапов и сохранить информацию в текстовый файл. Актуально, если у вас не настроен мониторинг бэкапов в zabbix.

echo "==================================" >> dir_size.txt
echo "Dirs size `date +"%Y-%m-%d_%H-%M"`" >> dir_size.txt
echo "==================================" >> dir_size.txt
du -s *| sort -nr | cut -f 2- | while read a;do du -hs $a >> dir_size.txt ;done

На выходе останется файл dir_size.txt следующего содержания.

==================================
Dirs size 2019-09-04_18-16
==================================
3.2T	resad
2.0T	winshare
1.7T	mail
1.2T	doc
957G	share
43G	web
17G	hyperv
6.5G	zabbix
5.2G	onlyoffice
525M	databases

В целом, по свободному месту на дисках все. Утилит df и du достаточно, чтобы закрыть этот вопрос.

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.

Examining the cache

A cache logical volume is built on the combination of the origin logical volume and cache-pool logical volume.

# lvs vg_erica0/home
  LV   VG        Attr       LSize   Pool             Origin       Data%  Meta%  Move Log Cpy%Sync Convert
  home vg_erica0 Cwi-aoC--- 380.00g   0.25   14.54           0.11

We can use ‘lvs -a’ option to see all of the parts used to create the cache . Below home is the new the cached logical volume, home_cachepool is the cachepool lv, and home_corig is the origin lv. home_cachepool_cdata and home_cachepool_cmeta are the data cache lv and a metadata cache lv combined to create the cachepool. lvol0_pmspare is the spare metadata logical volume

# lvs -a 
  LV                     VG        Attr       LSize   Pool             Origin       Data%  Meta%  Move Log Cpy%Sync Convert                                                                    
  home                   vg_erica0 Cwi-aoC--- 380.00g   0.31   14.54           1.14            
         vg_erica0 Cwi---C--- <89.92g                               0.31   14.54           1.14            
   vg_erica0 Cwi-ao---- <89.92g                                                                      
   vg_erica0 ewi-ao----  40.00m                                                                      
             vg_erica0 owi-aoC--- 380.00g                                                                      
          vg_erica0 ewi-------  40.00m  

Add the «-o +devices» option to show which devices the extents for each logical volume are based on.

# lvs -a -o +devices

Настройка RAID уровня 10 в CentOS 8

RAID 10 сочетает в себе зеркалирование дисков (запись на два диска одновременно) и чередование дисков для защиты данных. При наличии как минимум 4 дисков RAID 10 распределяет данные по зеркальным парам. В этой конфигурации данные могут быть извлечены, пока работает один диск в каждой зеркальной паре.

Как и предыдущие уровни RAID, начните с очистки всех ваших сырых дисков.

Создайте по одному разделу на каждом из дисков и установите флаг RAID.

Затем создайте устройство RAID 10 и проверьте его состояние:

После настройки устройства RAID создайте файловую систему, которая вам нужна. Ниже показан пример настройки xfs.

После этого создайте точку монтирования, в которую будет монтироваться устройство:

Настроить монтирование в /etc/fstab:

Убедитесь, что он может быть установлен правильно:

Остановить и удалить массив RAID

Если вы хотите удалить устройство RAID из своей системы, просто отключите точку монтирования, остановите ее и удалите с помощью приведенных ниже команд. Не забудьте заменить /mnt/raid0 своей точкой монтирования, а /dev/md0 вашим устройством RAID.

Тест 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-ами.

Как создать программный Raid 0

h2<dp>2,0,0,0,0—>

Сразу хочу предупредить, что создать программный райд в Виндовс 7 или программный RAID в windows 10 — редкостное извращение, заниматься которым я не рекомендую.

p, blockquote<dp>7,1,0,0,0—>

Если вам нужно реальное ускорение, действовать надо немного по другому: скопировать все важные данные на внешний накопитель, отформатировать ваши винчестеры и делать установку с нуля — сначала настроить BIOS, потом сам массив и лишь затем устанавливать Винду.Но на всякий случай вот вам описание процедуры создания RAID 0 на Виндовс. У «Семерки» и «Десятки» алгоритм почти не отличается — только некоторые пункты могут называться по-другому. Такая опция компанией Microsoft названа «чередующиеся тома».

p, blockquote<dp>8,0,0,0,0—>

Что нужно сделать:

p, blockquote<dp>9,0,0,0,0—>

• Нажмите кнопку «Пуск», перейдите в панель управления и выберите «Администрирование», затем «Управление компьютером».
• Перейдите в раздел «Запоминающие устройства» – «Управление дисками».
• Кликните правой кнопкой мыши по области с описанием свойств диска в левой части интерфейса и выберите «Преобразовать в динамический диск».
• Повторите это с другим томом, который хотите добавить к массиву.
• Кликните на появившемся дисковом пространстве в нижней части окна и выберите «Создать том». После запуска мастера нажмите кнопку «Далее».
• Выберите в списке девайсы, которые вы хотите преобразовать в чередующиеся тома.
• Назначьте букву для нового массива.
• Выберите опцию «Форматировать» и подходящую файловую систему (рекомендую NTFS). Размер кластера оставьте по умолчанию.
• После всех манипуляций нажмите кнопку «Готово».

Некоторые замечания:

p, blockquote<dp>10,0,0,1,0—>

• Дисковое пространство, выделяемое под чередующиеся тома, должно быть одинаковым на каждом винчестере. Минимальный выделяемый объем 50 Мб.
• Аппаратные RAID 0 несовместимы с программными.
• Чередующиеся тома не могут содержать ОС или загрузочный раздел.
• Их нельзя расширить или зеркалировать.
• Если один из физических накопителей выйдет из строя, утрачен будет весь чередующийся том.

Повторяю: способ можно использовать только как временный «костыль». Для долговременного использования рекомендую аппаратный RAID 0.

p, blockquote<dp>11,0,0,0,0—>

p, blockquote<dp>12,0,0,0,0—> p, blockquote<dp>13,0,0,0,0—> p, blockquote<dp>14,0,0,0,1—>

after—></dp></dp></dp></dp></dp></dp></dp></dp></dp></dp></dp></dp></dp></dp></dp></dp>

Windows в числе своего арсенала предусматривает несколько возможностей по созданию программного RAID. Это в первую очередь старая системная функция по работе с динамическими дисками, в рамках которой можно, в частности, создавать специальные разделы из нескольких устройств информации с реализацией конфигураций RAID, 1 и 5. А Win8.1 и Win10 на своём борту содержат более современную технологию – дисковые пространства.

Что это за технология и как её использовать?

Настройка дисковых накопителей

В первую очередь, следует настроить хранилище, которое пригодится для сохранения данных ВМ и резервных копий. Далее приведём пример дисковой разметки, который в реальности подходит лишь для тестовых целей. Если речь идёт о реальных условиях, следует применять программный либо аппаратный RAID-массив, что позволит исключить утерю данных при выходе дисков из строя.

Итак, предположим, что физический сервер имеет 2 диска — /dev/sda, где установлен гипервизор, и пустой диск /dev/sdb, планируемый к использованию для хранения данных ВМ. Дабы система увидела новое хранилище, следует воспользоваться наиболее простым и эффективным способом — подключить его, как обычную директорию. Однако перед этим надо выполнить ряд подготовительных действий. Давайте рассмотрим, каким образом подключить новый диск /dev/sdb любого размера, отформатировав его в файловую систему ext4.

1.Первым делом размечаем диск, создавая новый раздел:

fdisk /dev/sdb

2.Потом нажимаем o или g (разметить диск в MBR или GPT).
3.Далее жмём клавишу n (создаём новый раздел).
4.Потом клавишу w (чтобы сохранить изменения).
5.Тепeрь файловую систему ext4:

mkfs.ext4 /dev/sdb1

6.Пришло время создать директорию, где будем монтировать раздел:

mkdir ```/mnt/storage

7.Откроем конфигурационный файл для редактирования:

nano /etc/fstab

8.Добавим туда новую строку:

/dev/sdb1   /mnt/storage    ext4    defaults    0   0

9.После внесения изменений сохраним их сочетанием Ctrl + X.
10.И проверим, что всё работает, отправив сервер в перезагрузку:

shutdown -r now

11.Потом проверим смонтированные разделы:

df –H

По идее, вывод команды покажет, что /dev/sdb1 смонтирован в директорию /mnt/storage. Таким образом, наш накопитель к работе готов.

Stage 1. Preparation

Ok, let’s make a list of what we need to start migration:

1. Working Linux system to migrate. In my case it was CentOS 7.4, but I’m sure everything would work on any Linux system with on disk partitions.
2. CentOS bootable live-cd or USB flash drive. I love the Gnome version, but there’s a KDE option if preffered. I won’t stop on how to burn a live-cd or make a bootable flash drive, there’re loads of articles about it out there. CentOS live-cd distribution contains everything we need out-of-the-box since all that we need is package which is preinstalled.
3. Data on the previous drive must fit the size of the new one. In my case only 10GB were busy on the 1TB disk, so, it was not a problem for me at all.
4. You also will need a cup of coffee to relax.

dm-cache command shortcut

A single command can be used to cache main LV with automatic
creation of a cache-pool:

# lvcreate --cache --size CacheDataSize VG/LV 

or the longer variant

# lvcreate --type cache --size CacheDataSize \

        --name NameCachePool VG/LV 

In this command, the specified LV already exists, and is the main
LV to be cached. The command creates a new cache pool with size and given
name or the name is automatically selected from a sequence lvolX_cpool,
using the optionally specified fast PV(s) (typically an ssd). Then it
attaches the new cache pool to the existing main LV to begin caching.

(Note: ensure that the specified main LV is a standard LV. If a
cache pool LV is mistakenly specified, then the command does something
different.)

(Note: the type option is interpreted differently by this command
than by normal lvcreate commands in which —type specifies the type of the
newly created LV. In this case, an LV with type cache-pool is being created,
and the existing main LV is being converted to type cache.)

dm-writecache settings¶

To specify dm-writecache tunable settings on the command line,
use:

—cachesettings ‘option=N’ or

—cachesettings ‘option1=N option2=N …’

For example, —cachesettings ‘high_watermark=90
writeback_jobs=4’.

To include settings when caching is started, run:

# lvconvert --type writecache --cachevol fast \
	--cachesettings 'option=N' vg/main

To change settings for an existing writecache, run:

# lvchange --cachesettings 'option=N' vg/main

To clear all settings that have been applied, run:

# lvchange --cachesettings '' vg/main

To view the settings that are applied to a writecache LV, run:

# lvs -o cachesettings vg/main

Tunable settings are:

Факторы влияющие на производительность

Рассмотрим что такое Stripe size, Virtual Drive initialization, Consistency Check, Patrol Read.

Virtual Drive initialization — это зануление, блоков раздела, перед тестирование скорости советую дождаться полной инициализации. По времени занимает по разному все зависит от размеров массива.

Stripe size — Размер блока данных одной ячейки раздела, по сути карта как данные распределены по жестким дискам. Размер страйпа может иметь большое влияние на Конфигурирование RAID для оптимальной производительности и других факторов эффективности. Как правило при последовательных данных увеличить скорость RAID контроллера можно с помощью размеров stripe 512 kb или 1 mb. При случайном виде доступа лучше 16 кб, все зависит от того какое По у вас будет крутиться на данном разделе. Но в большинстве случаев лучше оставить стандартный размер, предлагаемый производителем.

Consistency Check — Проверка целостности является важной функцией, которая помогает обнаружить несоответствия в данных, хранящихся на жестких дисках в RAID массивах и выявляет возможные повреждения данных. Проверка целостности генерирует значительное количество запросов к диску, которые могут уменьшить производительность RAID

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

Patrol Read — помогает обнаруживать и исправлять плохие блоки на жестких дисках и предотвращать возможную потерю данных. Patrol Read генерирует значительное количество запросов к диску, которые могут уменьшить производительность RAID контроллера. Вы должны включить или отключить Patrol Read в зависимости от цели вашей работы измерения.

Настройка RAID уровня 1 в CentOS 8

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

Прежде чем мы начнем, давайте очистим все диски перед тем, как мы начнем конфигурации RAID, чтобы убедиться, что мы начинаем с чистых дисков.

Создайте по одному разделу на каждом из дисков и установите флаг RAID.

Создать устройство RAID 1:

Проверьте статус нового массива:

Когда устройство RAID будет готово, мы не сможем использовать его, если на нем нет файловой системы. Чтобы исправить это, создайте файловую систему, которая вам нужна. Ниже показан пример настройки xfs.

После этого создайте точку монтирования, в которую будет монтироваться устройство:

Снова настройте монтирование в /etc/fstab:

Убедитесь, что он может быть установлен правильно:

dm-cache chunk size¶

The size of data blocks managed by dm-cache can be specified with
the —chunksize option when caching is started. The default unit is KiB. The
value must be a multiple of 32KiB between 32KiB and 1GiB. Cache chunks
bigger then 512KiB shall be only used when necessary.

Using a chunk size that is too large can result in wasteful use of
the cache, in which small reads and writes cause large sections of an LV to
be stored in the cache. It can also require increasing migration threshold
which defaults to 2048 sectors (1 MiB). Lvm2 ensures migration threshold is
at least 8 chunks in size. This may in some cases result in very high
bandwidth load of transfering data between the cache LV and its cache origin
LV. However, choosing a chunk size that is too small can result in more
overhead trying to manage the numerous chunks that become mapped into the
cache. Overhead can include both excessive CPU time searching for chunks,
and excessive memory tracking chunks.

Command to display the chunk size:

lvs -o+chunksize VG/LV

lvm.conf(5) allocation/cache_pool_chunk_size

controls the default chunk size.

The default value is shown by:

lvmconfig —type default
allocation/cache_pool_chunk_size

dm-writecache block size¶

The dm-writecache block size can be 4096 bytes (the default), or
512 bytes. The default 4096 has better performance and should be used except
when 512 is necessary for compatibility. The dm-writecache block size is
specified with —cachesettings block_size=4096|512 when caching is
started.

When a file system like xfs already exists on the main LV prior to
caching, and the file system is using a block size of 512, then the
writecache block size should be set to 512. (The file system will likely
fail to mount if writecache block size of 4096 is used in this case.)

Check the xfs sector size while the fs is mounted:

# xfs_info /dev/vg/main

Look for sectsz=512 or sectsz=4096

The writecache block size should be chosen to match the xfs sectsz
value.

It is also possible to specify a sector size of 4096 to mkfs.xfs
when creating the file system. In this case the writecache block size of
4096 can be used.

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

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

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

Обратите внимание: «раскачивается» NAS достаточно долго — около 10 минут, после чего выходит на максимальную производительность

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

Как выбрать SSD для сетевого хранилища

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

Рассмотрю на примере 250-гигабайтного Kingston A2000 NVMe PCIe SSD. TBW модели — 150. Означает, в течение пятилетнего гарантийного периода на диск может быть записано 150 терабайт информации.

Synology рекомендует заменить кэш еще до того, как предельное число будет достигнуто.

Для сравнения, TBW 1-терабайтной модели линейки равен 600, 500-гигабайтной — 350. Высокая скорость последовательного чтения/записи (до 2000/1100 МБ/с) и низкое энергопотребление (0,0032 Вт в режиме простоя), определило мой выбор A2000 NVMe в качестве кэша NAS. Дополнительно отмечу, предельное энергопотребление в процессе записи — 4,5 ватта.

Главные характеристики по информации Kingston:

• Габариты — 80 мм x 22 мм x 3,5 мм.
• Масса — 6,6 г (250 ГБ, 1 TБ), 6,8 г (500 ГБ).
• Уровень вибрации в процессе работы — от 7 до 800 Гц.
• MTBF — 2 000 000.
• Продолжительность ограниченной гарантии и бесплатной техноподдержки вендором ― 5 лет.

• 250 ГБ – 150 000/180 000 IOPS.
• 500 ГБ – 180 000/200 000 IOPS.
• 1 ТБ – 250 000/220 000 IOPS.

Объем блока — 4 килобайта.

Температурный диапазон:

• эксплуатации: 0 — +70;
• хранения: -40 — +85.

Для дома и малого офиса спецификации более чем хороши, тем более с учетом довольно скромных цен.

Весомым аргументом стали для меня три десятилетия опыта компании, продукты которой доступны более чем в 175 странах. Означает, что при возникновении вопросов пользователя проконсультируют и он сам легко найдет в интернете информацию по теме. Ведь распространенные ситуации «компьютер не видит флешку», «телефон не читает карту памяти» зачастую нерешаемы, если применяются малоизвестные накопители. Попросту некому подсказать, как исправить.

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

Кэш файлового хранилища относится к той же категории, что и флешка — является накопителем информации. Только применение более ответственное. А значит — не место для экспериментов.

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