Доброго дня
Так уж получилось, что я занимаюсь системами хранения данных последние 5 лет, 4 года из которых я посвятил системам среднего уровня компании EMC, чему и был в общем-то рад. О EMC я, возможно, посвящу отдельный пост, а данный будет посвящен системам хранения NetApp, с которыми приходится иметь дело последний год в довольно сложных конфигурациях. Взгляд со стороны покупателя, пользователя, администратора, без особых технических подробностей и красивых картинок.
Кому интересно — добро пожаловать под кат.
Как всё началось
А началось всё с того, что решили построить второй, удаленный дата-центр. Так как ресурсы старой СХД подошли к концу, а строить ДЦ в любом случае надо с нуля, решили закупить нечто, что способно выдержать нагрузку порядка 1000 виртуальных машин и порядка 20 продуктовых баз данных Oracle + куча разработки. Ну и соответственно, раз удаленный ДЦ, значит репликация и отказоустойчивость на уровне всего дата-центра. Не буду подробно останавливаться на всех аспектах выбора, но скажу, что в претендентах были Hitachi, EMC и NetApp. Выбрали NetApp, т.к. после тестов нам понравилось как работает Oracle по NFS и отсутствием FC SAN как класса, можно использовать существующую 10gb сеть. На том и остановились.
Какие ставились задачи
- Удаленные площадки в режиме active-active (в смысле часть баз там, часть там, не RAC)
- Потеря данных Oracle в случае краха одной из сторон — 0 секунд
- Время переключения базы на другую сторону — до 5 минут с помощью кластерного ПО (Veritas)
- Постоянная доступность виртуальных машин Vmware
Что в итоге получилось
А получилось 2 системы FAS6280, 2 контроллера в каждой, на двух площадках под базы данных, репликация SnapMirror + одна система FAS3270 в конфигурации MetroCluster (SyncMirror) под виртуальные машины. Версия Ontap — 8.1.2 на всех системах. Везде — FlexVol и RaidDP.
Скажу сразу — с метрокластером на FAS3270 нет никаких проблем. Совсем. Абсолютно. Он работает и выполняет в точности те задачи, которые на него возлагались, тянет около 1000 виртуальных машин, поделенных пополам между площадками. Никаких проблем и подводных камней. Если контроллер уходит в ребут, виртуалки замирают на 15 секунд по вводу-выводу и продолжают работать как ни в чем не бывало. Обратное переключение, когда контроллер возвращается, занимает примерно столько-же времени. Этой системой я доволен на все 200%. Но, скажем честно, загрузка на нем пока еще около 50% по месту и около 25-30% по вводу-выводу дисков (около 4500 дисковых iops на 75 активных дисков/сторона). Как показывает практика, именно это и позволяет ему работать без проблем.
Совместно с NetApp была составлена спецификация на FAS6280, был проведен сайзинг, обсуждали все-все подводные камни, которые могут возникнуть в случае наших задач. Нас заверили, что всё будет работать так, как мы обсудили. А обсудили мы следующую картину:
- Каждая база данных содержит 3 раздела: data+index, archivelog, redo+undo.
- 20 баз данных поделенных на 4 контроллера, репликация между парой контроллеров.
- 2 раздела, data + arch — асинхронный snapmirror, раз в минуту. Раздел redo — синхронный snapmirror.
- Разработка размазана тонким слоем по всем 4 контроллерам.
На момент запуска утилизация по месту была порядка 40% на каждый контроллер, утилизация по дисковому воду-выводу — 20%. Из чего можно сделать вывод, что системы просто бездельничали.
Сейчас утилизация по месту около 85%, по дискам около 70% в среднем, в пиках 90%. Если в цифрах — 100% утилизации, это 32500 дисковых операций на контроллер. Дисковые операции != кол-ву iops на nfs.
Проблема первая — синхронный SnapMirror
Обещано — 30 сессий синхронной репликации на контроллер. Всё. Никаких подробностей, кроме того, что указано — синхронная репликация очень чувствительна к latency сети. Никаких подробностей о нагрузке, направлении.
По факту, синхронная репликация ломается даже при 2 сессиях направленных в разные стороны (то что это может оказаться ключом мы поняли спустя почти 2 месяца).
Выглядело это так:
[fas6280a_1:wafl.nvlog.sm.sync.abort:notice]: NVLOG synchronization aborted for snapmirror source VOL_prod_ru, reason='Out of NVLOG files'
[fas6280a_1:snapmirror.sync.fail:notice]: Synchronous SnapMirror from fas6280a_1:VOL_prod_ru to fas6280a_2:VOL_prod_ru failed.
Открывали кейс, консультировались напрямую с инженерами NetApp — вердикт всегда звучал один — у вас проблемы с сетью. Провели собственные изыскания на этот счет, потратили на это почти месяц — наш вердикт, сеть в порядке, латенси под нагрузкой около 0.5мс и не скачет. Решение подсказал один из технарей из глубин NetApp — он сказал, что в разные стороны работать и не должно, ибо что-то там связано с самим механизмом Consistency Point (CP), подробности мы так и не поняли, но стоило развернуть репликации в одну сторону — стало всё хорошо.
Так как это нас не устроило, докупили 4 полки дисков и увезли все Redo/Undo на FAS3270, на метрокластер, и забыли о проблемах синхронной репликации как класса. Правда скачкообразная нагрузка с виртуалок, высокая нагруженость процессоров и высокие требования по времени отклика для Redo не позволила нам остаться на этом решении, но это отдельная история.
Проблема вторая — асинхронный SnapMirror
Тут всё проще — если мы ставим синхронизацию раз в минуту, получаем никогда не заканчивающуюся сессию, потому как данные не успевают переливаться за отведенное время, слишком долго считаются изменения. Остановились на 5 минутном расписании, сдвинутом на 1 минуту для каждого раздела. Когда нагрузка выросла до 80% утилизации дисков, имеем лаг синхронизации для самых тяжелых баз порядка 15-20 минут постоянно, в моменты пиковой нагрузки (бэкап например, диски 90-95% утилизации), лаг увеличивается до бесконечности. Из чего следует, что никакого переключения за 5 минут быть не может, ибо только докатывание изменений в лучшем случае 20 минут + обратная ресинхронизация после разворота репликации, которая на больших разделах идет очень долго, те же 20 минут в лучшем случае.
Проблема третья — QOS, или в терминологии NetApp — FlexShare
Система управляет планировщиком, работает на уровне томов (volume), позволяет задать приоритеты от 1 до 99 для каждого тома относительно других томов плюс относительно системных процессов. Описание шикарное, казалось-бы всё просто как 2х2. По факту:
- Нельзя ограничить верхнюю планку для тома, ну если вдруг какое-то приложение сломалось и начало очень сильно мучать ввод-вывод, пострадают все.
- Не важно, какой приоритет выставлен, скажем для прода 99, для разработки — 1, нагрузка разработки все равно будет влиять на прод. Но да, время отклика раздела разработки будет немного хуже, если нагрузка постоянна.
- Если нагрузка разработки не постоянная, а скачкообразная — приоритет вообще не работает. Ему нужно время на адаптацию.
- Приоритет не ускоряет выполнение SnapMirror, как бы высоко не задирали system.
- Приоритет поднимает общий латенси по системе, но не сильно. Заметно только при очень высокой нагрузке.
- При очень высокой нагрузке контроллера, невозможно выполнить большинство команд, результат приходит через 3-5 минут после запуска команды на выполнение, например даже нельзя посмотреть состояние репликации, а это блокирует работу кластерного ПО.
Именно из за последнего приоритет выключен на наших системах. Открывали кейс по этому вопросу — результата нет никакого.
Проблема четвертая — свободное место на агрегате (набор из нескольких raid-групп объединенных в одно пространство).
Кто сталкивался с NetApp прошлых лет, наверняка знают, что если заполнить агрегат более чем на 90% данными, то система становится крайне ленивой и не желает работать. Маркетологи упорно утверждают, что данная проблема была полностью устранена начиная с версии 8.1 (а может даже 8.0, я не помню точно, если честно). По факту — полнейшая ложь. Не уследили мы за местом, заполнили агрегат аж на 93% — всё, привет. Время отклика системы в целом увеличилось почти в 2 раза. И это при условии, что мы не используем дедупликации, компресии и прочие вкусности, только тонкие тома (thin provisioning). Систему отпустило только при освобождении места до 85%. Точка.
Более того, попробуйте заполнить агрегат на 85-95%, создайте десяток сессий snapmirror в разные стороны, нагрузите систему вводом-выводом процентов на 80, а потом удалите раздел, размером в 1/5 объема агрегата. Результат — больше часа неработоспособных баз данных из за того, что система ушла в себя, время отклика по всем разделам составляло от 300мс до 5с. На консоль не реагировала, была даже мысль перезагрузить контроллер, но сначала начали экстренно снимать всю нагрузку с него, убили репликацию на стороне-приёмнике, и через какое-то время система начала приходить в себя. Рекомендация NetApp — убивайте файлики по одному, не надо сразу 12тб удалять через vol destroy.
Проблема пятая — 2 агрегата
А вот шутка в том, что если у вас на 100% загружены диски на одном агрегате, то второй агрегат с загрузкой в 10% откажется работать, и латенси там будет сравнимо с агрегатом у которого 100%. А связано это напрямую с тем, как в NetApp записываются данные.
Дело в том, что в отличии от классических блочных систем хранения, которые умеют прогонять данные напрямую на диски (write-through), если размер блока более определенного значения (обычно 16кб или 32кб, но можно настроить), NetApp никогда так не делает и по сути всегда пишет write-back из за особенностей работы WAFL. Именно этим обусловлено большое кол-во памяти на контроллерах, даже младших моделей. И именно этим обусловлена супер-низкая latency на запись, которой так гордятся NetApp, если система не сильно нагружена. Кэш един для всех агрегатов, он переполняется, становится невозможно писать даже в не нагруженный агрегат.
Вывод — не стоит перегружать диски более чем на 60% если хочется стабильного низкого latency на системе. Ну и не имеет смысла делать отдельный агрегат, если у вас одинаковые диски.
Небольшие выводы
- Если есть задача построить DR-решение до 50км, берите MetroCluster и даже не думайте. Разница в цене смешная, совершенно прозрачно для хостов. Из минусов — крайне желательна отдельная темная оптика между ДЦ. Но по факту работает и при делении ресурсов, проверено. Можно вписать в существующий SAN, но я вам этого не говорил.
- Если есть задача получить низкий latency — не допускайте загрузки дисков более 50-60% (90-110 iops на SAS-диск 3.5").
- Старайтесь избегать скачкообразной нагрузки, чем нагрузка более линейна, тем легче NetApp её переваривает.
- Старайтесь избегать нагрузки разными блоками. WAFL это крайне сильно тревожит.
- Не допускайте более 85% загрузки данными агрегата.
- Готовьтесь менять железо по гарантии. Много. Часто. Но этим сейчас страдают все производители систем начального и среднего уровня.
Вот в общем-то наверное и все мои наблюдения за год общения с данными системами. Системы на самом деле очень не плохие, очень легки в изучении. Всем приятного администрирования.
Автор: madorc
