Пару месяцев назад мы запустили у себя СХД на базе Нексенты для нужд массовой виртуализации. Поставили ее под хорошую нагрузку и не все пошло как по маслу и по книжке. Кому интересны шокирующие детали и опыт эксплуатации, прошу под кат.
напомню, Nexenta — это такой коммерческий софт для систем хранения данных, на базе ZFS/OpenSolaris. Умеет много что, но нам надо что бы он кормил по iSCSI наши ноды виртуализции под KVM и Hyper-V/Windows 2008 HA Cluster — с дедупликацией, кэшем и всеми остальными пряниками.
Машину собрали годную, 36 дисков по 300Gb SAS 15K, нашли 300Gb SDD Intel 710 серии (круче некуда на тот момент) и так далее.
Сервер мы собрали, Нексенту поставили. Поставили нам ее официальные партнеры Нексенты, сертифицированные инженеры. Все завелось, заработало. Торжественно включили дедупликацию, порадовались. Наладили бакап.
Стали мы переносить туда виртуальные машины с кластера Hyper-V/Windows 2008 R2. А надо сказать их много довольно, несколько сотен и размер у них не маленький — 20Гб в среднем. Есть по 5Гб, а есть и по 200.
Кластер мы разделили, старый был в старом ЦОД, а новый кластер мы собрали уже в новом. Поэтому мигрировали не по локалке, а через ВЛАН на нескольких сотнях мегабит — миграция ВМ с 200Гб диском затягивалась на несколько часов.
Все бы ничего, но первый косяк мы словили уже через неделю — по мере миграции на Нексенте кончилась память для таблицы дедупликации. Надо сказать, что в Нексенте таблица дедупликации относится к пулу дисков, а не к конкретному тому. Если память кончается, то это не значит, что умная система заранее отключит модную фичу. Умная система войдет в ступор с деградацией производительности на порядок-два. Т.е. если раньше вы гоняли тела ВМ со скоростью 80-90МБ/с через гигабиттный порт, то теперь это будет 3-4МБ/с и 200-300 IOPS на всех.
Что получается, на каждый блок ФС в пуле Нексенте надо примерно 500 байт в памяти для таблицы дедупликации. Если у нас в системе 128Гб памяти, Нексента может хранить инфу про 256 000 000 блоков:
максимальный размер занятого пула на 4К блоках — 1Тб, на 16К блоках — 4Тб, на 32К блоках — 8Тб и на 64К блоках — 16Тб. Запишите это красным маркером на стене! Зайдете за границу и прощай премия =)
Если не так задали размер блока в самом начале — ничто не поможет, кроме миграции на новый том с правильным размером. Если вы выключите дедупликацию, ничего само не произойдет. Таблица дедупликации некуда не денется, в том числе и из памяти. Все что можно будет сделать, это создать еще один новый том без дедупликации и копировать туда старый. Да, если у вас переполнена таблица ДД на этот момент, то копироваться он будет примерно со скоростью 3-4Гб в минуту. В нашем случае том был примерно 4Тб размером, миграция (zfs send / zfs receive) заняла около 16 часов. Потом мы стерли том с дедупликацией, через пару часов машине полегчало настолько, что мы смогли все запустить в работу.
Прошу заметить, что у нас было свободное место на томах — мы могли это сделать. А вот если места для миграции внутри хранилища не хватит по причине нехватки дисков или ограничения лицензии, то добро пожаловать в мир чудес и приключений. iSCSI в таком раскладе еле работает и постоянно отваливается от винды по таймаутам, Линукс стоически переносит тормоза. Блочное устройство придется монтировать и многие часы пытаться слить оттуда контент, еще вариант добить памяти в сервер с Нексентой (махнуть мать, как правило), что бы она чуть пришла в чувство…
Еще про дедупликацию на блочном уровне. Это не работает, забудьте. Держа на массиве с блоками (sic!) 4Kb сотню клиентских ВМ .vhd собранных с 3-4 шаблонов мы ожидали, что будет как в книжке про NetApp, коэффициент 8-10. Этого не вышло, dedup ratio был около 2-3. Т.е. включение базовой компрессии приводит к схожему результату – 40%. Для достижения коэффициентов 8-10 вероятно надо использовать офлайновую дедупликацию с ползучим по размеру блоком. Это как в storage pools новой Windows 2012 или ONTAP.
Дальше больше. Выключили дедупликацию, все завелось. Тома крупные, по 7Тб каждый. Продолжаем миграцию ВМ Hyper-V со старого кластера на новый, замечаем на MRTG — скорость записи снижается. Не сразу, потихоньку. За сутки миграции со скоростью 50-60МБ/с раза в два.
Почему? Тут всплывает второй косяк, не описанный в маркетинговых материалах сразу. Стоит ZFS пулу заполниться, как он радикально деградирует по производительности. Более 30% свободного места это не бросается в глаза (но видно на графике), с 30 до 10% все работает раза в три медленнее, а если места становится менее 10% — все работает на порядок медленнее.
Мораль, следите за местом. Если места на пуле не станет, это будет катастрофа – придется аварийно расширять пул упираясь в диски/полки/лицензии или мигрировать данные на соседние СХД/локальные диски нод. Нексента чувствует себя в добром здравии, если у нее свободно более 30% места – планируйте это при расчетах серверов.
Но это не самое неприятное. Самое неприятное — это когда Hyper-V теряет quorum диск или весь Cluster Shared Volumes на 4Тб кормящий три крупных ноды и не получается никакими силами хотя бы его смонтировать на одну из нод. Как достичь такого волшебного результата: поставьте на один том CSV сотню ВМ под Виндой, запустите их и начните мигрировать еще несколько ВМ на этот том. Сначала все бодро копируется, потом процесс копирования замирает, а потом у вас отваливается CSV. Да, на всем кластере. При этом таргеты будут видны, но смонтировать с них том не сможете.
В ряде случаев его получается примонтировать обратно, а в ряде случаев после суточного общения с поддержкой MS и Нексенты удастся смонтировать на одну из нод бывшего кластера том, на котором лежат .vhd файлы – без конфигураций. Тогда у вас получится их скопировать с вышеуказанной скоростью на старые добрые жесткие диски ноды и там запускать уже по одной, заводя их в Hyper-V ручками.
Это касается только Hyper-V/Windows 2008 R2 и не касается KVM. Это не касается Starwind – он ровно работает в таком режиме. Наше мнение – iSCSI Винды 2008 и Нексента между собой не совсем совместимы, массовые параллельные записи/чтения приводят к локам, таймаутам и сбоям. Никто нам ничего внятного в поддержке обеих компаний не сказал. На форумах говорят, что некоторые патчи помогают Винде в ряде случаев, что тип LUN надо менять и т.п.
Дальше, апгрейд системы на Нексенте требует ее перезагрузки. Если нет высокодоступного кластера из СХД, готовьтесь объявлять технические работы или мигрируйте все ВМ на соседние хранилища. Имейте это ввиду, changelog между версиями Нексенты громадный.
Дальше, дисковый пул Нексенты в идеале должен состоять из одинаковых дисков, собранных в одинаковые raid-группы. Вы не сможете в дальнейшем расширять эти группы или менять в них тип raid.
В общем примерно такие впечатления от Nexenta через 2 месяца работы. Сейчас у нас Линуксовая виртуализация довольно ровно и быстро работает с Nexenta, Кластер Windows 2012 работает со Starwind и мы тестируем механизм и скорость Storage Pools SMB 3.0 для использования их для организации высокодоступного CSV. Да, там работает оффлайновая дедупликация и мы видим хорошие коэффициенты, но это тема другой статьи.
Из общих соображений производительности и IO pattern. Для задач не нужны SAS диски в пуле, нам бы хватило 12 SATA дисков по 1Тб. Мы планировали что все будет с дедупликацией, а вышло без. Знали бы заранее — денег бы сэкономили. Дисковый монитор там удобный, по нему сразу видно сколько операций на диск приходится. SSD в кэш должен быть серверного класса, на нем постоянная серьезная нагрузка и по чтению и по записи.
А как у Вас эксплуатируется Нексента под нагрузкой с томами в десятки Тб? Без нагрузки у всех все красиво.
Автор: ULP
