Пару месяцев назад мы запустили систему хранения данных на базе Nexenta для нужд массовой виртуализации.
Мы подвергли его хорошей нагрузке, и не все пошло по инструкции.
Кому интересны шокирующие подробности и опыт эксплуатации, обращайтесь в кат. Напомню, Nexenta — коммерческое программное обеспечение для систем хранения данных на базе ZFS/OpenSolaris. Он умеет много чего, но нам он нужен для питания наших узлов виртуализации через iSCSI под KVM и Hyper-V/Windows 2008 HA Cluster — с дедупликацией, кешем и всеми прочими пряниками.
Собрали годную машину, 36 дисков SAS 15K по 300Gb, нашли SDD Intel 710 series на 300Gb (круче на тот момент не было) и так далее.
Мы собрали сервер и установили Nexenta. Нам его поставили официальные партнеры Nexenta, сертифицированные инженеры.
Все завелось и заработало.
Мы торжественно включили дедупликацию и радовались.
Настраиваем резервную копию.
Мы начали переносить туда виртуальные машины из кластера Hyper-V/Windows 2008 R2. Но надо сказать, что их довольно много, несколько сотен и размер у них не маленький - в среднем 20Гб.
Есть 5 ГБ, а есть 200. Мы разделили кластер, старый остался в старом дата-центре, а новый кластер мы собрали в новом.
Поэтому мигрировали не локально, а через VLAN в несколько сотен мегабит — миграция ВМ с диском 200ГБ заняла несколько часов.
Все бы ничего, но первую школу мы поймали уже через неделю - как мигрировали В Nexent недостаточно памяти для таблицы дедупликации.
Надо сказать, что в Nexent таблица дедупликации относится к дисковому пулу, а не к конкретному тому.
Если закончилась память, это не значит, что умная система заранее отключит модную функцию.
Умная система войдет в ступор с ухудшением производительности на порядок-два.
Те.
если раньше вы гоняли тела ВМ со скоростью 80-90МБ/с через гигабитный порт, то теперь это будет 3-4МБ/с и 200-300 IOPS у всех.
Происходит следующее: для каждого блока FS в пуле Nexente требуется примерно 500 байт памяти для таблицы дедупликации.
Если у нас в системе 128 ГБ памяти, Nexenta может хранить информацию о 256 000 000 блоков: максимальный занимаемый размер пула на блоках 4 КБ составляет 1 ТБ, на блоках 16 КБ — 4 ТБ, на блоках 32 КБ — 8 ТБ и на блоках 64 КБ — 16 ТБ.
Запишите это красным маркером на стене! Уезжай за границу и прощай бонус =) Если размер блока в самом начале был задан неправильно - ничего не поможет Кроме миграции на новый том правильного размера.
Если отключить дедупликацию, само по себе ничего не произойдет. Таблице дедупликации некуда деться, в том числе и из памяти.
Все, что можно сделать, это создать еще один новый том без дедупликации и скопировать туда старый.
Да, если ваша таблица DD в этот момент заполнена, то она будет копироваться примерно со скоростью 3-4ГБ в минуту.
В нашем случае размер тома был примерно 4ТБ, миграция (zfs send/zfsполучение) заняла около 16 часов.
Потом мы стёрли том дедупликацией, и через пару часов машина почувствовала себя настолько лучше, что мы смогли вернуть всё обратно в работу.
Обратите внимание, что у нас было свободное место на томах — мы могли это сделать.
Но если внутри хранилища недостаточно места для миграции из-за нехватки дисков или лицензионных ограничений, то добро пожаловать в мир чудес и приключений.
iSCSI в такой ситуации еле работает и постоянно отваливается от винды по таймаутам, линукс стоически терпит тормоза.
Вам придется смонтировать блочное устройство и потратить много часов на то, чтобы скачать контент оттуда, еще вариант добавить памяти на сервер с Нексентой (как правило, отмахнуться от матери), чтобы она пришла в себя немного.
Больше о дедупликация на уровне блоков .
Это не работает, забудьте об этом.
Держа сотню клиентских ВМ .
vhd, собранных из 3-4 шаблонов на массиве с блоками (sic!) по 4Кб, мы ожидали, что будет как в книге про NetApp, коэффициент 8-10. Этого не получилось, коэффициент дедупликации был примерно 2-3. Те.
включение базового сжатия приводит к аналогичному результату – 40%.
Чтобы добиться коэффициентов 8-10, вероятно, нужно использовать оффлайн-дедупликацию с ползучим размером блока.
Это как в пулах хранения новой Windows 2012 или ONTAP. Более того.
Дедупликацию отключил, все завелось.
Тома большие, по 7ТБ каждый.
Продолжаем мигрировать ВМ Hyper-V из старого кластера в новый, замечаем на MRTG, что скорость записи падает. Не сразу, понемногу.
В течение дня миграция со скоростью 50-60МБ/с увеличивается вдвое.
Почему? Здесь возникает вторая проблема, которая не сразу была описана в маркетинговых материалах.
Как только пул ZFS заполняется, производительность радикально падает. .
Больше 30% свободного места не заметно (но видно на графике), от 30 до 10% все работает в три раза медленнее, а если места становится меньше 10%, то все работает на порядок медленнее.
Мораль, следить за местом .
Если места в пуле не будет, это будет катастрофа — придется экстренно расширять пул за счет дисков/полок/лицензий или мигрировать данные на соседние СХД/локальные диски нод. Нексента чувствует себя хорошо, если у нее свободно более 30% места — учитывайте это при расчете серверов.
Но это не самое неприятное.
Самое неприятное, когда Hyper-V теряет кворум-диск или весь общий том кластера емкостью 4 ТБ, питающий три больших узла, и его невозможно даже смонтировать на одном из узлов.
Как добиться такого волшебного результата: разместить на одном CSV-томе сотню ВМ под Windows, запустить их и начать мигрировать на этот том еще несколько ВМ.
Сначала все копируется бодро, потом процесс копирования зависает, а потом у вас отваливается CSV. Да, на всем кластере.
В этом случае цели будут видны, но смонтировать том из них не получится.
В некоторых случаях его можно смонтировать обратно, а в некоторых случаях после ежедневного общения со службой поддержки MS и Nexenta можно будет смонтировать том, на котором расположены .
vhd-файлы, на одном из узлов бывшего кластера — без конфигураций.
Тогда вы сможете с указанной выше скоростью скопировать их на старые добрые жесткие диски узла и запускать их там по одному, вручную выводя в Hyper-V. Это применимо только к Hyper-V/Windows 2008 R2 и не применимо к KVM. К Старвинду это не относится — в этом режиме он работает плавно.
По нашему мнению, iSCSI Windows 2008 и Nexenta не полностью совместимы друг с другом; массовые параллельные записи/чтения приводят к блокировкам, тайм-аутам и сбоям.
Никто не сказал нам ничего ясного о поддержке обеих компаний.
На форумах пишут, что некоторые патчи помогают Windows в ряде случаев, что нужно изменить тип LUN и т.д. Дальше, Обновление системы на Nexenta требует перезагрузки.
Если в СХД нет высокодоступного кластера, готовьтесь анонсировать технические работы или мигрировать все ВМ в соседние хранилища.
Имейте это в виду: журнал изменений между версиями Nexenta огромен.
Далее, дисковый пул Nexenta в идеале должен состоять из одинаковых дисков, собранных в одинаковые рейд-группы.
Вы не сможете в дальнейшем расширять эти группы или менять в них тип рейда.
В общем вот примерно такие впечатления от Нексенты после 2 месяцев эксплуатации.
Теперь у нас достаточно плавно и быстро работает виртуализация Linux с Nexenta, Windows 2012 Cluster работает со Starwind, и мы тестируем механизм и скорость Storage Pools SMB 3.0, чтобы использовать их для организации высокодоступного CSV. Да, там работает оффлайн-дедупликация и мы видим хорошие коэффициенты, но это тема другой статьи.
По общим причинам производительности и шаблона ввода-вывода.
Для задач VPS нам не нужны SAS-диски в пуле; 12 SATA-дисков по 1 ТБ нам бы хватило.
Планировали, что всё будет с дедупликацией, но получилось без.
Если бы мы знали заранее, мы бы сэкономили деньги.
Дисковый монитор там удобный; сразу видно, сколько операций выполняется на диске.
SSD в кеше должен быть серверного класса; он несет постоянную большую нагрузку как при чтении, так и при письме.
Как вы эксплуатируете Nexenta под нагрузкой с объемами в десятки ТБ? Без нагрузки у всех все хорошо.
Теги: #Hyper-V #опыт использования #дедупликация #Nexenta #Server 2008
-
Отобрано 100 Кандидатов В Колонизаторы Марса
19 Oct, 24 -
Поиск Ошибок В Выпуске Llvm 13.0.0
19 Oct, 24 -
Утечки Персональных Данных В Webmoney
19 Oct, 24 -
Чемпионат Ipsc По Программированию 2009 Г.
19 Oct, 24
