company_banner

Netapp — реальность против маркетинга

Доброго дня

image
Так уж получилось, что я занимаюсь системами хранения данных последние 5 лет, 4 года из которых я посвятил системам среднего уровня компании EMC, чему и был в общем-то рад. О EMC я, возможно, посвящу отдельный пост, а данный будет посвящен системам хранения NetApp, с которыми приходится иметь дело последний год в довольно сложных конфигурациях. Взгляд со стороны покупателя, пользователя, администратора, без особых технических подробностей и красивых картинок.

Кому интересно — добро пожаловать под кат.

Как всё началось

А началось всё с того, что решили построить второй, удаленный дата-центр. Так как ресурсы старой СХД подошли к концу, а строить ДЦ в любом случае надо с нуля, решили закупить нечто, что способно выдержать нагрузку порядка 1000 виртуальных машин и порядка 20 продуктовых баз данных Oracle + куча разработки. Ну и соответственно, раз удаленный ДЦ, значит репликация и отказоустойчивость на уровне всего дата-центра. Не буду подробно останавливаться на всех аспектах выбора, но скажу, что в претендентах были Hitachi, EMC и NetApp. Выбрали NetApp, т.к. после тестов нам понравилось как работает Oracle по NFS и отсутствием FC SAN как класса, можно использовать существующую 10gb сеть. На том и остановились.

Какие ставились задачи

  1. Удаленные площадки в режиме active-active (в смысле часть баз там, часть там, не RAC)
  2. Потеря данных Oracle в случае краха одной из сторон — 0 секунд
  3. Время переключения базы на другую сторону — до 5 минут с помощью кластерного ПО (Veritas)
  4. Постоянная доступность виртуальных машин 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% загрузки данными агрегата.
  • Готовьтесь менять железо по гарантии. Много. Часто. Но этим сейчас страдают все производители систем начального и среднего уровня.

Вот в общем-то наверное и все мои наблюдения за год общения с данными системами. Системы на самом деле очень не плохие, очень легки в изучении. Всем приятного администрирования.
Tinkoff
it’s Tinkoff — просто о сложном

Comments 71

    +2
    Несколько странное с точки зрения oracle решение сложить redo+undo на один раздел.
      +1
      С точки зрения NetApp так вообще, хоть в один раздел все базы клади. Просто разными томами управлять проще, реплицировать, следить за нагрузкой.
        +1
        У undo и redo принципиальная разная структура операций: по redo идут чисто последовательные запись и чтение, по undo идет random read-write.
        redo гораздо более критичен по производительности.
        И смысла иметь синхронно реплицируемое undo при отстающих остальных табличных пространствах совершенно никакого.
          0
          Это не в моей компетенции, я с oracle не слишком дружен. Очень давно уже наши DBA используют такую структуру, еще до моего прихода, и всех всё устраивает. Сейчас redo + undo лежит на флешах, соответственно на random read полностью все равно, а random write для NetApp всё равно. Но спасибо за информацию, у нас еще есть базы, которые используют механические диски для redo, надо будет посмотреть.
            +1
            В таком случе хотел еще спросить — такой вариант с отстванием части разделов с dba согласован?
            Он неработоспособен и при потере master массива невозможно будет запуститься на slave, кроме этого возможна потеря достаточно большого объема транзакций при последущем восстановлении с ленточек.
            По потере — причина в том, что если БД работает достаточно активно и redo log switch происходит раз в минуту (что неправильно, но бывает), а в БД всего 3 группы redo, то через три минуты произойдет затирание redo, сгенерированного три минуты назад, а архивная копия лога из-за задержки на slave еще не доедет.
            По невозможности подняться — из-за несинхронного режима 100% вероятность получить fractured oracle блоки (в которх разный rba в заголовке и в трейле) при пропадании master или просто при разрыве канала синхронизации. Fractured блоки oracle не умеет восстаналивать по redo (если только не был выполнен begin backup, но постоянно с этим жить нельзя — можно только включать на момент split mirror для получения косистентной копии, например), так что опять только вариант восстанавления с ленточек.
            Рекомендую перевести всю синхронизацию oracle на синхронный режим.
              +1
              Спасибо за развернутый комментарий. DBA в курсе, что у нас не синхронная репликация, по этому у нас 10-20 redo-файлов по 1гб каждый, в зависимости от базы. log switch раз в 1-2 минуты в среднем на нагруженных базах, что дает нам от 20 до 40 минут информации в redo.
              В далеких планах конвертация 6280 в metro, но с этим есть ряд сложностей, как физически, так и финансово.
                +1
                Пожалуйста :)
                Рекомендуемое oracle-ом время между log switch — 15-20 минут, так что рекомендую кроме количества также увеличить размер каждого redo хотя бы до 8Gb — это здорово снизит нагрузку по записи dwbr и немного увеличит mttr, что не так страшно.
                По fractured блокам — попробуй на тестовой БД под умеренной нагрузкой провести эксперимент, разорвать синхронизацию и на стороне slave выполнить recover+open (restelogs). По моему опыту даже в синхронном режиме без begin backup не получится поднять копию БД.
                  +1
                  Пробовали увеличить размер redo, заканчивалось это тем, что при log switch происходит сильный всплеск log file sync на базе из за копирования большого кол-ва информации в arch, что для некоторых приложений крайне не желательно, приложения зависают. Потому пока вот так.
                  Касаемо recover, я постоянно делаю копии для разработки на базе снапшотов, база не открывается в лучшем случае 1 раз из 20, может тут помогает оракловый dNFS? Пока базы жили на блочной СХД, без begin backup не поднимались вообще, да и с ним через раз.
                  Еще раз повторюсь, я не силен в oracle, потому пишу только то, что слышал «краем уха» общаясь с нашими dba и разбирая совместно с ними проблемы.
                    +1
                    О, пошел читать про dNFS, что-то новое для меня :)
                      +1
                      Для консистентности снепшотов ничего не используете? SnapManager или SnapCreator?
                        0
                        Нет, просто на СХД делаю снап+клон и отдаю разрабам.
                          +1
                          Гляньте на SnapCreator Framework. Бесплатный фреймворк, который позволяет делать консистентные снэпшоты, по идее и с клонами должен работать.
                          А SnapManager for Oracle точно позволяет делать консистентные клоны, но он стоит денег.
          +1
          Не понял про:
          Дисковые операции != кол-ву iops на nfs.

          Поясните пожалуйста, как определили что iops ы равны. Ведь, например в классическом RAID хостовые iops = iops диска * на N (где N=1,2,4,6,6.66 итд)
          спасибо!
            0
            Вчера наблюдал.
            По NFS приходит 200k iops кусками по 4kb, которые превращаются на дисках в 20k iops кусками по 38-40kb.
            В отличии от этого по iscsi блоки реального размера и попадают на диски 1 к 1.
              +1
              Видимо nettap может определять очередь для одного блока в кэше и суммирует его перед отправкой на диск…
                0
                Я это тестировал не на нетапе. Линуксовые хранилки.
            0
            Когда нагрузка выросла до 80% утилизации дисков, имеем лаг синхронизации для самых тяжелых баз порядка 15-20 минут постоянно, в моменты пиковой нагрузки (бэкап например, диски 90-95% утилизации), лаг увеличивается до бесконечности. Из чего следует, что никакого переключения за 5 минут быть не может, ибо только докатывание изменений в лучшем случае 20 минут + обратная ресинхронизация после разворота репликации, которая на больших разделах идет очень долго, те же 20 минут в лучшем случае.

            Еще вопросик:
            Какая пропускная способность канала? Он FC?
              –1
              Ну и на последок, не рассматривали HP 3Par? просто учился на него недавно, думается мне что там нет таких проблем… по цене правда не уверен что адекватней
              +4
              Саппорт нетаппа — редкостные долбо… бы. Причём речь не про начальные круги, а там, дальше. Существования проблем не признают, предлагаю при следующих авариях собирать статистику производительности для дальнейшего анализа.

                +4
                Подпишусь под каждым словом. Если у вас есть разовая проблема, есть полное описание и логи, скриншоты базовой статистики, и хочется понять, что было сделано не так и кто виноват, дабы не повторилось, или возможно какой-то фикс — просят перфстат в момент проблемы, ничем помочь не могут и отвечают неделями. Из за них теперь все работы ночами, даже просто удаление снапшотов.
                  +2
                  Просто интересно, а про support какой организации такого не скажешь?
                    0
                    Ну, например, HP. По замене гарантийного железа вообще все отлично, по глюкам — бывало приезжали специалисты и разбирались на месте. Это, естественно, про корпоративный сектор и дорогие железки.
                      0
                      Спасибо! А с каких железок начинается порог «дорогих»?
                        0
                        Не знаю. Просто у меня опыт общения с HP по блейдам, дисковым полкам и ленточным библиотекам, не самые дешевые железки.
                        Может быть на какие-нибудь дешевые пролианты, которые они продают как горячие пирожки, действуют другие условия.
                          0
                          Понятно. Как то меня обошло общение с hp support. Сервера работали как часы.
                        +1
                        У них же поддержка через партнёров и приезжают их специалисты, а не из HP.
                          0
                          В Питере был довольно крупный отдел саппорта именно HP, я знаком был с несколькими инженерами оттуда.
                            0
                            Занятно, теперь осталось понять при каких условиях они включаются в работу.
                              0
                              Скорее всего залогом успеха является хороший сервисный контракт. Если у вас контракт «Proactive 24» или «Critical Service», у которых поддержка «24х7, 4h response» то в 100% случаев ты будешь говорить с самим HP.
                              По дисковым массивам я знаю, что у них стояли локально Eva и XP, так что они могли применить твою рабочую конфигурацию у себя и имитировать разные варианты решения проблемм в песочнице.
                    0
                    что в претендентах были Hitachi, EMC и NetApp

                    А HP рассматривался? И если нет то почему?
                      0
                      Рассматривался HP P10000 3PAR. Не устроило, что они немного устарели на тот момент времени по сравнению со свежими, еще даже не начавшими продаваться новыми поколениями Symmetrix & VSP, отсутствие флеш-буфера и полное отсутствие поддержки FCOE, для нас это было важно. Мы очень хотели нативный FCOE, если уж говорить про блок, потому как нам очень не хотелось строить отдельную сеть SAN. Но в итоге то FCOE у нас все равно не работает :)
                        0
                        А почему не работает FCoE?
                      +1
                      >>Потеря данных Oracle в случае краха одной из сторон — 0 секунд
                      Но у вас же репликация отстает. Это требование в итоге стало не критичным?
                      Мне периодически приходится делать дизайн схем резервирования и пока лучше DataGuard (тот который online redo apply делает)ни чего для себя не нашел. А хочется, т.к. цена на такое решение достаточно кусачая получается :-(
                        +1
                        При отставании записи в datafiles oracle должен восстановить все недописанное по archive и redo логам.
                        Что касается цены — второй сайт в любом случае подлежит полному лицензированию, так что разница в цене с DataGuard не столь велика должна быть.
                          0
                          >>второй сайт в любом случае подлежит полному лицензированию
                          Холодные standby не лицензируются, на сколько я знаю. В случае аппаратной репликации, на другой стороне инстанс даже не запущен. А вот горячие standby, на которые применяется тот-же dataguard, лицензируются в полном объеме.
                            0
                            Эта информация устарела. Oracle все ужесточил, теперь можно не лицензировать только если на failover сервере не установлен soft и он физически не подключен к массиву :) Круто, да? ;)
                              0
                              Оппа… вот это сюрприз. А где это у них описано?
                              Если есть ссылка с удовольствием почитал бы. Буквально полгода назад «всё было в порядке».
                    • UFO just landed and posted this here
                        0
                        Скорее всего менял поставщик. Для вендора будет очень напряжно держать ТАКОЙ штат инженеров в каждой стране, а в России еще и в каждом регионе.
                        0
                        Есть фраза про постоянные замены железок по гарантии. А что летит чаще всего? И, кстати, какого объема СХД на ДЦ?
                          0
                          Дисков заменили — уже сбился со счета, заменили 4 блока питания дисковых полок и одну дисковую полку целиком. Сейчас еще будем менять память в одном из контроллеров, ошибки ECC. Общий полезный объем обеих 6280 — 228тб, 3270 — 54тб (метро-кластер, физически 108тб). Диски все SAS 600gb 3.5".
                            0
                            А как со временем замены? Быстро приходят новые диски и блоки?
                              +4
                              С этим проблем как раз нет, обычно на следующий день уже всё у нас в офисе, в не зависимости от размеров посылки. Ну и поддержка у них через глобальный support, напрямую, а не через разнообразных мелких и крупных интеграторов, как делает, например, EMC.
                              0
                              А каждая замена диска, как-то влияет на производительность всего стораджа? Запускается же какой-то процесс ребилда для каждого случая?
                              И если они так часто летят, у вас небыло момента когда дисков могло вылететь столько что вы уже не сможете починить массив?
                              ps
                              Кстати, а что там за SAS диски внутри?
                                +1
                                > А каждая замена диска, как-то влияет на производительность всего стораджа?
                                Почти не заметно.

                                > Запускается же какой-то процесс ребилда для каждого случая?
                                Запускается автоматически в фоне, идет с небольшим приоритетом, 600гб диск за пару часов становится в строй.

                                > дисков могло вылететь столько что вы
                                По этому обычно держат hot-spare диск, как только один вылетел, стразу на spare начинается ребилд, Шансы что за этот час выйдет из строя еще 2 диска (raid-dp переживает выход 2 дисков, т.е. потеря данных будет только если помрут сразу 3) довольно низкие.

                                > уже не сможете починить массив?
                                Ну, а где бывают такие админы, у которых не сделаланы баккапы? :)
                            –1
                            Проблема не в железках Netapp, а в реализации проекта.
                              0
                              Еще вопрос к автору — а вы тестируете работоспособность баз\виртуальных машин в случае сбоя на одной из площадок? Оно действительно поднимается?
                                0
                                Целиком площадка не падала, падали сервера баз данных, переезжали сами. Падала сеть между ДЦ — не поднялось из за ошибок кластерного ПО, ошибка в конфигурации, сейчас проводим работу над ошибками, строим отдельную fencing-сеть, к счастью испытывать пока не пришлось.
                                Виртуалки переживают пока любые неприятности и работают без проблем, поднимаются сами, что бы не случилось.
                                В идеале конечно хочется получить автоматического возвращения работоспособности даже при падении всей площадки (например питание), но пока это немного хромает, есть над чем работать.
                                  +1
                                  >>к счастью испытывать пока не пришлось
                                  Если не испытывать — нельзя быть уверенным, что в нужный момент всё отработает как надо. У нас некоторые клиенты специально, каждые полгода меняют местами ДЦ, чтобы в случае реальной проблемы все знали что делать и был ожидаемый результат.
                                  Но то, что виртуалки и базы успешно переезжают — это в любом случае хорошо.
                                    0
                                    Просто поменять местами и мы можем, и даже автоматом всё-всё сразу, только это не полный отказ всей площадки по питанию, или, что еще хуже, splitbrain из за экскаватора, разные немного вещи. Тут уже завязка на всю инфраструктуру, в которой еще и сеть присутствует, и вот сеть как раз сильно большое зло, когда у вас не отдельный от сети SAN. В теории мы знаем, что произойдет и как это лечить, а на практике — стараемся максимально закрыть все дыры, но всё время вылезает что-то новое.
                                +1
                                7 лет работаю с NetApp системами. Про заполнение аггрегата есть баг, да. За этим надо следить, по всему остальному надо понимать как система работает и знать нюансы. Надо правильно её «готовить» ) А так системы отличные, если руки и голова есть, то будут работать как часы, годами.
                                  0
                                  Данный пост и предназначен для небольшого понимания внутренней «кухни» NetApp, не более того. Просто поделился наблюдениями. Идеальных универсальных систем не бывает. Есть только приближенные к идеалу на данном этапе развития, но и цена там…
                                    +1
                                    Спасибо за статью, часто приходиться работать с поставщиками оборудования — на слайдах все красиво и прекрасно, но когда начинаешь устанавливать вылазят те или иные ограничения, сложности о которых поставщик «забыл» упомянуть. Это в принципе касается всех (и EMC и NetApp). Только реальный опыт подобный описанному вами дает понять где и у кого слабые места.
                                    0
                                    А есть системы за которыми не нужно следить :)?
                                    +2
                                    madorc, при всём уважении, а вы не думали о FlashPool, если у вас NVRAM не справляется?
                                    FlexShare — всё же не QoS, для того чтобы у вас был QoS вам нужно на C-Mode переходить.
                                    Далее, если вам нужно «Потеря данных Oracle в случае краха одной из сторон — 0 секунд» — это Metro Cluster «адназначна»
                                    Если у вас сильно загружены диски, то может всё же КЭШ добавить? Кстати какой у вас Cache Hit?

                                    По поводу проблем со SnapMirror в разные стороны… хм… проверю… как-нибудь.

                                    P.S. занимаюсь уже 7-й год как EMC так и NetApp'ом и могу вам сказать что NetApp никогда не скрывал про необходимость свободного пространства — скажите мне фамилию того кто вам не сказал про это :)
                                      0
                                      Фамилию не скажу, не гоже портить карму хорошим людям :)

                                      cDOT вещь интересная, но с ходу на неё не перепрыгнешь… FlashPool нет, т.к. нет flash-дисков на этих системах, но есть PAM, по 4тб на контроллер у 6280 и по 1тб на 3270, cache hit в среднем 92%.
                                      +2
                                      Есть полноценный QoS с ограничением по IOPS или MB/s — он доступен в cDOT.
                                      Никакой связи в записи с объемом кэша нет — запись ведется через NVRAM, который размером в несколько гигабайт.

                                      Про все остальное прекрасно ответил bakset.
                                        +2
                                        Все пять проблем, которые перечислил Заказчик, в большей степени связаны с некорректным использованием функционала NetApp и/или некорректным дизайном систем хранения FAS6280 под окружение Заказчика.
                                        Первая проблема скорее всего связана с ограничениями, которые накладывает Sync SnapMirror (например превышение количество параллельных потоков реплицирования или реплицирование томов, находящихся на одном агрегате с дедуплицированными томами)
                                        Вторая проблема — количеств изменений в байтах (новых блоков данных) за заданный промежуток времени превышает время, за которое эти изменения могут реплицироваться на удаленную систему
                                        Третья проблема — уже озвучили (Storage QoS появился в cDOT)
                                        Четвертая проблема — свободное место в агрегате. Есть такая фича у NetApp, но это должен знать архитектор решения и закладывать необходимый объём.
                                        Пятая проблема — опять же проблема дизайна, если в одном агрегате диски нагружены на 100%, а в другом агрегате на 10% — это неверная конфигурация, неправильное распределение количества шпинделей по агрегатам и/или распределение типов данных по агрегатам.

                                        Системы то хорошие )))
                                          0
                                          nice try, NetApp
                                            +2
                                            Кстати на счёт пятой проблемы, наверно действительно дело в дизайне. Как так получилось, что один агрегат более нагружен чем второй? Этот вопрос нужно было решить на этапе внедрения, если это не представлялось возможным по каким-то причинам «предугадать» сайзером.

                                            Положительная сторона в том, что в новой версии 8.2 C-Mode появилась возможность агрегаты переключать на ходу между контроллерами (ARL), а функционал vol move доступен бесплатно и тоже может онлайн мигрировать тома между агрегатами. Таким образом даже в направильно сбалансированной системе теперь можно перераспредилить нагрузку между агрегатами и контроллерами с гранулярностью до вольюма.

                                            А вообще любым инструментом можно сделать что-нибудь «не то», если очень «захотеть».
                                              0
                                              Кстати vol move доступен на 7-Mode. Можно сбалансировать нагрузку агрегатов.
                                            –3
                                            Не понял про:
                                            Дисковые операции != кол-ву iops на nfs.


                                            Поясните пожалуйста, как определили что iops ы равны. Ведь, например в классическом RAID хостовые iops = iops диска * на N (где N=1,2,4,6,6.66 итд)

                                            Когда нагрузка выросла до 80% утилизации дисков, имеем лаг синхронизации для самых тяжелых баз порядка 15-20 минут постоянно, в моменты пиковой нагрузки (бэкап например, диски 90-95% утилизации), лаг увеличивается до бесконечности. Из чего следует, что никакого переключения за 5 минут быть не может, ибо только докатывание изменений в лучшем случае 20 минут + обратная ресинхронизация после разворота репликации, которая на больших разделах идет очень долго, те же 20 минут в лучшем случае.


                                            Еще вопросик:
                                            Какая пропускная способность канала? Он FC?

                                            Ну и на последок, не рассматривали HP 3Par? просто учился на него недавно, думается мне что там нет таких проблем… по цене правда не уверен что адекватней

                                            Спасибо!
                                              +1
                                              Учитывая эти и другие накладные расходы, сколько в результате полезного пространства может быть использованно в каждом из агрегатов в абсолютных значениях?
                                              Я имею ввиду более конкретно, а то расплывчато получается.
                                              К примеру:
                                              =======================Пример===========================
                                              Есть СХД FAS6280 с двумя контроллерами
                                              У контроллера «А» есть 48 диска 600ГБ
                                              Создан агрегат aggr0 из (21+2) + (21+2) (т.е 2x RAID-DP) + 2х спардиска
                                              Итого полезного RAW пространства грубо говоря 2*21*600 = 25200 ГБ
                                              df -A -h для агрегата aggr0 показывает 22ТБ из них реально заюзать чтобы не падал перфоменс 19TB.
                                              =======================Пример===========================
                                              В таком духе.

                                              Спасибо.
                                                +1
                                                19ТБ реально заюзать.
                                                Реально заюзать и больше чем 22ТБ, использую thin provisioning и deduplication, совместное их использование даёт около 50% экономии пространства, при очень минимальном влиянии на производительность.
                                                  0
                                                  WTF?
                                                  Конкретику пожалуйста, выше пример.
                                                    +1
                                                    Сорри ниже ошибся с местом ответа, продублировал, а старый уже отредактировать не могу (

                                                    Конкретика простая.
                                                    Пример аггрегат 20ТБ,
                                                    Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
                                                    На vol включается дедупликация
                                                    На каждом из этих vol делается по одному Thin LUN на 2ТБ.

                                                    Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
                                                    Как то так )
                                                      0
                                                      Спасибо, интересно узнать конкретику заказчика по примеру выше.

                                                      Хтелось бы удостовериться, что не имеет место следующий случай:

                                                      Что при экономии на RAID-DP и с учётом всех оверхедов, мы получаем полезного пространства больше чем кто-бы то из вендоров-конкурентов мог бы предоставить на высоконагруженных задачах, но так как хотелось ещё больше, съели лишнее пространство (весь резерв системы рекомендуемый по бестпрактису) и получили «проблему у нетапа».
                                                +1
                                                Конкретика простая.
                                                Пример аггрегат 20ТБ,
                                                Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
                                                На vol включается дедупликация
                                                На каждом из этих vol делается по одному Thin LUN на 2ТБ.

                                                Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
                                                Как то так )

                                                  0
                                                  пардон, не туда написал коментарий, переместил.
                                                  0
                                                  Правильно ли я понимаю, что 30 сессий синхронной репликации на контроллер в одну сторону система выдерживает?

                                                  Only users with full accounts can post comments. Log in, please.