У меня в меня начали дохнуть 1.5TB диски в сервере. Я, в свое время, забыл поменять настройку в их прошивке, в связи с чем они (WD Green) постоянно парковали головки. В результате один диск не проходит проверку SMART, и количество парковок - 1.5млн (при чем на трех 1.5, а на четвертом 0.5). Последний месяц пул был в состоянии degraded без одного диска, но неделю назад начались косячки. Короче говоря я решил форсировать свое продвижение к "the СХД"
Купил два диска WD Red (это которые NASware, с прошивкой, оптимизированной под nas и 24/7) 3TB. И тут же залип с ними на весь день.
VMware и RDMVMware и RDM
Для начала нужно вспомнить, что у меня дома NAS - не отдельная железка, а виртуальная машина в VMware vSphere Hypervisor. Тут кроется первая сложность: чтобы не создавать дополнительных слоев абстракции (и на ровном месте терять в производительности), нужно отказаться от стандартной схемы с форматированием дисков в VMFS Datastore и созданием файлов виртуальных дисков. Отказываться надо в пользу RDM (Raw Device Mapping), это когда чуть менее, чем все, SCSI и ATA команды от виртуалки передаются прямиком на диск вместо того, чтобы обрабатываться ядром гипервизора и его файловой системой, как в обычном случае. Следующая засада - vSpere "искаропки" поддерживает RDM только для внешних LUN-ов (то есть импортируемых с внешних СХД по SAS,FC,iSCSI). Оно-то в принципе логично, это энтерпрайз-функционал, обычно том лежит на какой-нибудь злой хранилке тысяч за 200 зелени, и к нему имеет доступ целый кластер гипервизоров, и виртуалка с этим RDM-диском может путешествовать между узлами. В энтерпрайзе локальные диски вообще нужны только чтоб стартануть сам гипервизор (и то, всякие брендовые серверы могут иметь прямо на плате флешку с этим самым гипервизором, и обходиться без дисков совсем), и ни о каких локальных RDM никто не задумывается. Но, к счастью, это ограничение можно обойти с помощью таинственной магии командной строки.
В общем все эти проблемы на самом деле не проблемы, т.к. это уже пройденный этап и я точно знал что и как надо делать. Но не тут-то было, блеать. Ибо начались пляски с бубном.
RDM из консоли отказались создаваться, операционка говорила, что-то типа "фс не предназначена для файлов такого размера". Тут надо упомянуть, что при использовании cli-magic где-нибудь на системном томе создается "виртуальный" файл размером с подопытный диск. В моем случае - 3 ТБ. Начал гуглить и нагуглил про ограничение в 2ТБ на LUN. И тут мне стало пиздец как грустно. Мозг начал изобретать ебические схемы с форматированием в VMFS, созданием двух vdisk-ов на 1.5ТБ, потом их внутри виртуалки с помощью geom загнать в jbod (чтоб не пыталось слать конкурентные запросы с двух виртуальных дисков на один физический), а сверху уже разворачивать zfs pool. С этой схемы я сразу охуел, т.к. весь этот цирк явно не пойдет на пользу производительности, и мне стало оттого еще грустнее. Но тут мосК сказал "Эй, СТОПЭ, блеать!!!! У тебя же на работе как-то, сцуко, работает аж целых шесть 3ТБ-ных RDM-а! Там же работает, значит и тут должно, никакого 2ТБ на LUN, никакого хардкора с geom, выпрямляй руки и делай, блеать". Пошел на рабочий хост, посмотрел: ну все как есть, та же команда, работает нормально, версия гипервизора на работе даже ниже, чем дома. WTF, подумал я, но следующая же догадка оказалась верной: версия VMFS. На работе я с нуля ставил гипервизор 5.0, а дома, хоть он и 5.1, но пережил несколько апгрейдов и изначально ставился с 4.1, если я правильно помню. Так вот при апгрейде не происходит автоматического обновления файловой системы (тоже логично для ынтырпрайза: там ведь кластеры, и если обновить, то все старые версии потеряют этот датастор). В общем с залипаловом, но таки-создал RDM. Но на этом мой секс не кончился, ибо:FreeBSD и дискиFreeBSD не захотела работать с этими RDM. В качестве NAS у меня использовалась именно FreeBSD, и она люто ругалась на unsupported sector size, при чем постоянно путалась в показаниях: размер сектора в каждом ядерном сообщении был разный (либо 0, либо какие-то ебанутые числа разрядов в 15). Всякий секас с изменением типов виртуального адаптера, пересозданием RDM и прочими радостями ни к чему не приводил. Сомнения в работоспособности RDM были отметены тестовой машиной с линуксом, который радостно отформатировал оба тома и преспокойно делал на них ввод/вывод. Тут мне опять стало немного грустно... я уже так подружился с FreeNAS и ее красивым гуём с RRDшечками и прочим one-click-anything. Но тут я вспомнил, что изначально я остановился на FreeNAS, так как OpenSolaris в лице NexentaStor вместо того, чтобы работать быстрее (zfs для него, все-таки, нативная фс), показывал дичайшие лаги (но тогда это было вызвано и неисправной памятью). В общем попробовал - диски видит. Решено! NAS теперь будет на ядре соляриса. Но тут меня ожидал очередной охуительный сюрприз:Nexenta и диски с 4kb секторамиNexenta и диски с 4kb секторами. Начнем с теории. Раньше, когда трава была зеленее и водка по 3.75, у всех дисков размер сектора был 512 байт, все было зашибись. Но сейчас объемы дисков растут и вместе с ними растет "накладняк" на физическое размещения такого количества секторов. Производители решили данную проблему методом увеличения физического сектора до 4кб. Но т.к. в мире есть и все еще в ходу всякие недооперационки вроде XP, которые умеют работать только с секторами в 512 байт, производители накопителей придумали эмуляцию 512-байтных секторов. Т.е. контроллеры дисков могут обрабатывать ввод-вывод по 512 байт и нумеруют логически сектора именно такого размера. Вроде все зашибись, но есть проблема: физически сектора по 4k, и головки умеют читать-писать только по 4k. Т.е. читается лишний объем данных. С записью все намного херовее. У каждого сектора есть своя чек-сумма для выявления ошибок, и нетрудно догадаться, что это чек-сумма четырех килобайт. Чтобы записать на диск логический сектор в 512кб диску нужно: считать физический 4к сектор, посчитать его контрольную сумму с новыми 512 байтами, потом записать новый 4кб с новой чек-суммой. Самое грустное, что это физически не может произойти быстрее, чем за один полный оборот пластины. То есть на эту операцию есть МЕХАНИЧЕСКОЕ ограничение, что очень плохо, к тому же шпиндель - самая медленная часть диска. Среднестатистическое время ожидания вращения шпинделя увеличивается в три раза (с половины оборота до полутора). Немного сглаживает эту проблему command queueing (пока пластина делает оборот, можно подвинуть головки и прочитать/записать что-нибудь где-нибудь в другом месте), но совершить чудо она не может: производительность 512-байтной записи сильно ниже, чем в случае 4-килобайнтых блоков (от двух раз, до десятков и даже сотен в самых неблагоприятных условиях). В общем и целом нужно либо заставить ОС общаться с контролером диска только блоками по 4кб, чтобы было все как надо.
Тут у меня начинается очередной секс. На FreeBSD, в свое время, эта проблема решалась относительно просто: через тот же GEOM на базе одного из дисков создавалось виртуальное блочное устройство с размером блока 4кб, после этого zfs при создании пула автоматически выбирала минимальный блок, равный 4кб (т.к. один из дисков якобы не может работать с блоками меньше), дальше прослойка geom убиралась и zfs пул импортировался на живых дисках с правильными метаданными (интересующая характеристика, ashift - это минимальное смещение по диску в байтах, точнее логарифм этого числа по двойке... т.е. при ashift=9 работа с диском ведется блоками, кратными 512 байт, при ashift=12 - кратными 4кб). Но в Nexenta нет GEOM-а, т.к. это не FreeBSD, а OpenSolaris+DebianGNU. Решение быстро находится в интернетах: оказывается в OpenSolaris можно люто тюнить scsi-драйвер, в том числе на базе производителя и модели LUN-а переопределять всякие значения, в том числе интересующий нас physical-block-size. Достаточно выставить этот параметр в 4096 и все взлетит. Но хуй. Я дрочился очень долго, думал что не так пишу vendor и product (там влияет количество символов и важен порядок пробелов), всячески извращался, пока не нашел при очередном глубинном бурении поисковой системы гугла, что, блеать, конкретно в Nexenta, поддержка конкретно параметра physical-block-size в файле sd.conf, конкретно нихуя не реализована. Тут я охуел вообще и стал искать чем инициализировать пул с ashift=12. Перепробовал кучу всяких FreeBSD, но они все не видели дисков, попытался воткнуть zfsonlinux, но там оказалась старая версия, которая тоже этого не умеет. Уже думал переткнуть диски в другой комп и попробовать из невиртуальной bsd. Но тут очередная ступень бурения гугла дала мне надужду на дзен. Я нашел репорт одного чувака, который собирал себе сторадж на HP-шном бэрбоне как раз с Nexenta на борту. Он тоже столкнулся с такой проблемой и решил ее пиздецки радикально: он добыл у разрабов версию бинарного файла zpool, в которую захардкодено создание пулов с ashift=12 (вместо поисков минимального блока по дискам). И, блеать, за что ему отдельное спасибо - он выложил этот файл в энторнет! Скачал-подменил и массив создался правильно. Аллилуя, дзен и прочая радость.Промежуточные итоги:
Сервер: Core i7 2600, 32GB DDR3-1800. VMware ESXi 5.1
"Старый" NAS: 4 vCPU, 16GB vRAM, virtual NIC intell pro1000. Три диска WD15EADS .FreeNAS 8.3 (FreeBSD 8.3-RELEASE-p3) raidz 4x1.5TB, degraded.
"Новый" NAS: 4 vCPU, 10GB (на момент тестов) vRAM, virtual NIC intell pro1000. NexentaStor 3.1.1 (NexentaOS_134f). Два диска WD30EFRX, stripe-пул.
Подготовил датасеты, запустил rsync копировать со старого на новый. Почти на всех разделах скорость копирования была 950-1000 мегабит, т.е. ограничение в гигабитной виртуальной сетевухе. На разделах с включенной дедупликацией скорость плавала от 900 до 200 мегабит (но тут я еще ничего не настраивал).
На новом сторадже так же делал тесты с помощью dd (потоковое чтение/запись). Получилось красиво:
мелкие блоки 95 МБ/с запись и 231 МБ/с чтение
большие блоки 188 МБ/с запись и 293 МБ/с чтение. На одном из тестов показало 279 на запись.
Чтение из кеша - 3.2 гигабайт/с.
Это с двух шпинделей. Планируется увеличивать до raidz 4+1.