В этой статье я приведу наиболее значимые, с моей точки зрения, новые функции систем хранения NetApp в самой последней версии Clustered Data ONTAP. По традиции приведу пример на автомобилях: Представьте у вас есть Тесла автомобиль, вы обновили прошивку и получили автопилот с автопаркингом бесплатно, хотя его там раньше не было. Правда приятно? Так вот самыми главными аргументами обновить вашу систему до Cluster-Mode является сохранение инвестиций и возможность получить самый современный функционал на старом железе:
- Онлайн детекция (дедупликация) нулей на ходу, что может быть очень полезно в случае БД и провиженинга виртуальных машин.
- Онлайн дедупликация для FlashPool (и AFF) систем, что позволит продлить срок службы SSD дисков. Функция доступна начиная с 8.3.2.
- Если обновиться до VMWare vSphere 6, у вас будет поддержка vVOL как с NAS так и SAN
- QoS — установка максимального порога операций ввода-вывода или Мб/с на файлы, луны, вальюмы и SVM.
- Поддержка NFS4.1, которая также присутствует у VMware vSphere 6
- Поддержка pNFS которая позволяет распаралеливать NFS и переключаться между путями от клиента к файловой шаре без её перемонтирования, поддерживается с RHEL 6.4 и выше.
- Поддержка SMB (CIFS) 3.0 который работает с клиентами начиная с Win 8 и Win 2012
- Поддержка закрытия файлов и сессий для SMB 3.0 из Data ONTAP
- Поддержка SMB 3.0 Encription.
- SMB Continuous Availability (SMB CA), предоставляет возможность переключения между путями и контроллерами хранилища без разрыва соединения, что очень важно для работы SQL/Hyper-V
- ODX при работе с Microsoft SAN/NAS позволяет сгрузить рутинные задачи, типа забить блок данных определенным патерном, и позволяет не гонять лишних данных между хостом и хранилищем.
- Онлайн миграция вольюмов по агрегатам, в том числе и на других нодах кластера
- Онлайн миграция лунов по вольюмах, в том числе и по другим нодам кластера
- Онлайн переключение агрегатов между нодами HA пары
- Возможность объединять гетерогенные системы в один кластер. Таким образом апгрейд осуществляется без останова доступа к данным, благодаря такой возможности NetApp называет свой кластер Бессмертным. На момент обновления кластера, его ноды могут состоять из разных версий cDOT. Не могу упустить возможность и не упомянуть, что у большинства конкурентов если кластеризация вообще есть, то она во-первых весьма ограничена по числу нод, а во-торых все ноды кластера обязаны быть идентичными (гомогенный кластер).
- ADP StoragePool — технология для более рационального распредиления SSD под кеш (гибридные агрегаты). К примеру у вас есть только 4 SSD, а вы хотите чтобы 2, 3 или четыре агрегата получали преимущество от кеширования на SSD.
- ADP Root-Data Partitioning позволит отказаться от выделенных root агрегатов для систем FAS22XX/25XX и AFF8XXX
- Space Reclamation для SAN — возвращает удалённые блоки хранилищу. Напомню что без SCSI3 UNMAP деже если на вашем луне блоки данных удалялись, на тонком луне на самом хранилище эти блоки всё-равно были помечены как используемые и таки занимали дисковое пространство, а любой тонкий лун раньше мог только расти, так как ранее просто не было механизма обратной связи хранилища и хоста. Для поддержки Space Reclamation хосты должны быть ESXi 5.1 или выше, Win 2012 или выше, RHEL 6.2 или выше.
- Adaptive compression — улучшает скорость чтения компрессированных данных.
- Улучшения работы FlexClone для файлов и лунов. Появилась возможность задания политик удаления клонов файлов или лунов (будет полезно к примеру с vVOL).
- Возможность аутентифицировать администраторов СХД при помощи Active Directory (лицензия CIFS не требуется).
- Поддержка Kerberos 5: 128-bit AES и 256-bit AES шифрование, поддержка IPv6.
- Поддержка SVM DR (на основе SnapMirror). Т.е. возможность отреплицировать всю SVM на резервный сайт. Важным моментом является возможность на этапе настройки отношений репликации заранее задать новые сетевые адреса (режим Identity discard), так как на резервной площадке, часто используются отличные от основной площадки диапазоны сетевых адресов. Функция Identity discard будет очень удобна не большим компаниям, которые не могут себе позволить оборудование и каналы связи, для того чтобы растянуть L2 домен с основной площадки на запасную. Для того чтобы клиенты переключились на новые сетевые адреса достаточно поменять записи DNS (что может быть легко авмоматизировано при момощи простого скрипта). Также поддерживается Identity preserve режим, когда все настройки LIF, volume, LUN сохраняются на удалённой площадке.
- Возможность восстановления файла или луна из резервной копии SnapVault не восстанавливая весь вольюм.
- Возможность интегрировать СХД с антивирусными системами для проверки файловых шар. Поддерживаются Computer Associates, McAfee, Sophos, Symantec, Trend Micro и Kaspersky.
- Оптимизирована работа FlashPool/FlashCache. Позволяет кешировать компрессированные данные и большие блоки (ранее оба этих типа данных не попадали в кеш).
Сетевое подключение 7-Mode (вверху) и Cluster-Mode (внизу) для FAS2240-2.
Обновление FAS22XX
Во-первых обязательно необходимо наличие 10Gbit Mezzanine адаптера. Если у вас FC Mezzanine, его будет необходимо заенить на 10Gbit и перейти на iSCSI.
Во вторых будьте готовы пожертвовать один 10Gbit порт с каждого такого контроллера под нужды Cluster-Interconnect. Это обязательный минимум. Можно отдать один или два порта 10Gbit порта с контроллера, если под кластерный интерконнект выделен один порт 10Gbit, не пожадничайте отдать ещё один порт 1Gbit под те же нужды, хотя это уже не является обязательным требованием. Другими словами обновление может повлечь изменение дизайна вашего сетевого подключения.
Если у вас уже использовалась Active-Passive конфигурация, то вы сможете сэкономить 3-4 диска высвобожденные из под Root агрегат благодаря ADP Root-Data partitioning.
Почему есть смысл обновлять FAS22ХХ до cDOT
Вместо четырех портов 10Gbit с двух контроллеров в 7-Mode мы получим два 10Gbit порта в Cluster-Mode: по подному порту с контроллера, для подключения хостов.
Во-первых, отказоустойчивость такого решения не страдает потому-что LIF интерфейсы в случае отказа линка или контроллера переезжают вместе с IP и MAC адресами на второй контроллер в онлайне. Если это iSCSI, то со стороны хоста просто происходит переключение пути к хранилищу, на уровне драйвера мультипасинга (SAN LIF'ы не ездят, вместо этого работает мультипасинг).
Во-вторых, некоторые пользователи пробовали запускать синтетическую нагрузку и им не удалось нагрузить два из четырех линков более чем на 40% при 48x SAS 10k дисках, остальные два всё-равно простаивали. А в штатном режиме работы утилизация линков у того же пользователя не достигала 10%. Другой заказчик живёт на cDOT 8.3.1 и системой FAS2240 20x900 +4 SSD в конфигурации Active-Passive (т.е. по-сути используется только один 10Gbit линк, второй пассивно ожидает когда он понадобится в аварийном случае) и не наблюдает каких-либо отрицательных изменений в скорости доступа к хранилищу после перехода на Cluster-Mode, имея при этом всю свою, не малую, виртуальную инфраструктуру живущую на этом хранилище.
system1> ifstat e1a
-- interface e1a (8 days, 20 hours, 10 minutes, 27 seconds) --
RECEIVE
Frames/second: 12921 | Bytes/second: 46621k | Errors/minute: 0
Discards/minute: 0 | Total frames: 11134k | Total bytes: 38471m
Total errors: 0 | Total discards: 0 | Multi/broadcast: 0
No buffers: 0 | Non-primary u/c: 0 | Bad UDP cksum 0
Good UDP cksum 2044 | Redo UDP cksum 0 | Bad TCP cksum 0
Good TCP cksum 0 | Redo TCP cksum 0 | Tag drop: 0
Vlan tag drop: 0 | Vlan untag drop: 0 | Mac octets 9472k
UCast pkts: 72750k | MCast pkts: 187k | BCast pkts: 15181
CRC errors: 0 | Bus overrun: 0 | Alignment errors: 0
Long frames: 0 | Jabber: 0 | Pause frames: 0
Runt frames: 0 | Symbol errors: 0 | Jumbo frames: 42959k
TRANSMIT
Frames/second: 12457 | Bytes/second: 2936k | Errors/minute: 0
Discards/minute: 0 | Total frames: 10710k | Total bytes: 2528m
Total errors: 0 | Total discards: 0 | Multi/broadcast: 971
Queue overflows: 0 | No buffers: 0 | Frame Queues: 0
Buffer coalesces: 0 | MTUs too big: 0 | HW UDP cksums: 0
HW TCP cksums: 0 | Mac octets: 110k | UCast pkts: 974
MCast pkts 4 | BCast pkts: 967 | Bus underruns: 0
Pause fraMes: 0 | Jumbo frames: 0
LINK_INFO
Current state: up | Up to downs: 1 | Speed: 10000m
Duplex: full | Flowcontrol: full
При обновлении вашей СХД с 7-Mode до Cluster-Mode с переносом данных на временную СХД и потом онлайн миграцией данных назад, можно воспользоваться подручными свичами.
Обновление систем 32XX и 6XXX
Обновление старших систем, как правило не приводит к каким-либо изменениям в подключении хранилища к сети так как в них либо есть 10Gbit порты для Cluster Interconnect на борту, либо их туда можно доставить в свободный PCI слот.
В системах 32ХХ на борту нет 10Gbit портов, но их можно доставить в свободный PCI разьём.
В системах 6XXX на борту уже есть 10Gbit и можно либо задействовать их либо нужно будет докупить 10Gbgit NIC есле свободных портов нет.
Выводы
Возможность обновить ваши старые СХД NetApp это способ сохранения инвестиций, даже с учётом того, что на FAS22XX системах теряется один 10Gbit порт с контроллера, «игра стоит свеч», благодаря широкому дополнительному функционалу. Для более старших систем конвертация, как правило, вообще не влечёт изменения подключения к сети. У многих других уважаемых вендоров, процесс обновления это, обычно, полная замена железа, в том числе и дисковых полок. NetApp в этом плане намного более гибче благодаря возможности обновлять старое железо самыми новыми прошивками и возможности подключения всех полок от своих старых СХД, а разграничения совместимости дисковых полок между классами Low/Mid/High-End попросту нет. Бессмертный кластер позволяет объединять разные модели и безостановочно его вертикально и горизонтально масштабировать, а также апдейтить и апгрейдить.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания, дополнения и вопросы по статье напротив, прошу в комментарии.
Комментарии (29)
pcmaniac
24.11.2015 22:30+2А есть инфа по реальному использованию интерконнекта? Если например вместо одного 10Г порта использовать 4х1Г, всё равно простаивают :)
bbk
24.11.2015 22:59+1Если всё сконфигурино правильно, то кластерный интерконнект практически не используется.
По ним бегает синхронизация нескольких системных баз данных между всеми нодами кластера, размером в пару мегабайт.
Технически 1Gbit может выполнять эту роль, но если вы мигрируете данные между нодами, 1Gbit точно будет узким горлышком, в связи с этим нетапп официально НЕ ПОДДЕРЖИВАЕТ работу кластерного интерконнекта на 1Gbit портах.
Стоит отдельно оговорить случай с 2240. Если у вас только один кластерный линк 10Gbit и этот линк по какой-то причине будет разорван, одна нода из HA пары перезагрузится. В этом нет ничего ужасного, так как отработает take over (HA). Take-over относительно дорогая операция и её можно избежать при помощи трюка с запасным 1Gbit портом с кластерной ролью, который нужно добавить в Cluster'ный бродкаст домен. Таким образом, 1Gbit не используется для кластерной сети, до тех пор, пока не произойдет разрыв 10Gbit линка. Как только основной 10Gbit умрёт, кластерный LIF (по стандартной политике) переедет на первый доступный порт в кластеном бродкаст домене, т.е. на 1Gb порт, избежав не нужной операции Take-Over. По-этому я написалне пожадничайте отдать ещё один порт 1Gbit под те же нужды, хотя это уже не является обязательным требованием.
pcmaniac
24.11.2015 23:54+1Так если одна нода перезагрузится, то на её стороне потухнут оба линка, и 10Г и 1Г. В чём тогда смысл? Take over всё равно произойдёт. Или я чего-то не понимаю?
bbk
25.11.2015 09:23Не путайте одно с другим :)
если одна нода будет в дауне, это не значит что вторая пойдет в даун, только лишь потому что у нее кластерные порты потухнут.
Описанная мною ранее ситуация имеет место только в случае обрыва кластерного соединения между нодами НА пары, при том всего нод в кластере две и обе не видят друг друга.pcmaniac
25.11.2015 13:50+1А, понял, речь идёт о защите от Split Brain? Тогда да, лучше перестраховаться :)
bbk
25.11.2015 14:02Да это защита, но не от сплитбрейна.
Вот предположим вы мигрировали вольюм, а LIF еще не перенесли.
Или на хосте не настроен правильно мультипасинг и хост обращается к контроллеру нетапа который не владеет луном.
В обоих этих случаях доступ к данным будет прозрачно проксироваться и ходить к контроллеру через кластерный интерконнект.
А тут у нас берет и пропадает кластерный коннект.
Что сделать чтобы хост гарантированно продолжил получать доступ к данным и сообщить ему про правильные пути? Никак, нужно просто убрать эти пути:
Потушить одну ноду и переместить все пути к данным на оставшуюся ноду.pcmaniac
25.11.2015 14:43+1А если онлайн миграция не используется, мультипасинг настроен правильно и ломать его никто не планирует. Можно для кластерного интерконнекта ограничиться 4х1Г линками? Просто если они в данном случае будут всегда простаивать, то какой смысл под это выделять 10Г, если по 4 1Г порта на каждой голове свободны и никогда не будут использоваться в продакшене т.к. слишком велики там задержки и разница в скорости с 10Г очень заметна даже на маленькой нагрузке.
bbk
25.11.2015 15:201 Гбит можно настроить под кластерный интерконнект это мною проверено — работает.
Но официально НЕ ПОДДЕРЖИВАЕТСЯ. Это значит, что если система у вас еще на поддержке и у вас будут какие-то проблемы связанные с кластерным интерконнектом и вы обратились в поддержку, то как только обнаружится что для кластерного интерконнект используется 1 Гб, есть большая вероятность, что поддержка скажет вернуть кластерный интерконнект на 10 Гб.
madorc
25.11.2015 14:15+1Полный вайп системы при апгрейде 7-mode -> cDOT всё еще требуется? :)
bbk
25.11.2015 15:45Теперь есть возможность полку с дисками отключить от старой системы 7M и подключить к новой СМ. Это называется Copy-Free-Transition (CFT).
При переключении полки минимальный простой не избежен.
Данные будут сохранены и будут полностью доступны на чтение и запись. Для этого необходимо иметь новую систему с установленной СМ плюс нужно иметь минимальное количество дисков для Root Aggregate, это обязательный минимум.
In-place (т.е. Обновление прошивки на существующем контроллере) апгрейд с 7М на СМ не поддерживается. Это связано именно с необходимостью в Root Aggregate.
Что можно сделать:
Можно взять на тест у партнера/Дисти/Вендора систему FAS с дисками с уже установленной СМ.
Переключить вашу полку на нее. Здесь будет простой.
Далее смигрировать данные на временную полку уже в онлайне.
Обновить вашу систему до СМ и добавить ее в кластер.
Забрать вашу старую (и уже пустую) полку со временной FAS системы и подключить ее к вашей старой FAS системе (и уже обновленной до СМ).
Далее в онлайне мигрируйте данные со временной FAS назад на вашу старую систему со старой полкой.
Удаляем временную систему со временной полкой из кластера.
Итого:
Одно переключение полок с прерыванием
Две Онлайн миграции.
И на вашей старой системе с обновленной прошивкой оказываются ваши старые данные.
Полка с данными может не обнульться (форматироваться).
Я проводил подобную процедуру.
madorc
25.11.2015 16:08+1In-place (т.е. Обновление прошивки на существующем контроллере) апгрейд с 7М на СМ не поддерживается. Это связано именно с необходимостью в Root Aggregate.
У меня на всех системах выделенный root-агрегат и уже давно…
Система объемом 4 стойки, боюсь фокус с «переключить» не выйдет и пока я не освобожу все 4 стойки — апгрейд не светит… Подождем, вдруг что-нибудь придумают с апгрейдом 8.2 — > 8.3 без вайпа, учитывая, что у меня метро-кластер и я могу переключить совсем всё на одну площадку, дилемма только с возвращением назад.bbk
30.11.2015 09:50В текущей схеме CFT не поддерживается миграция MetroCluster с 7-Mode на cDOT.
Другими словами для MetroCluster, wipeconfig по-прежнему необходимо выполнять.
bbk
25.11.2015 16:29Не в курсе по поводу CFT для МС, может быть что для такого случая это не работает.
По поводу выделенных Root Aggregate на 7М. В контексте CFT они не спасут, дело в том что при CFT миграции предусматривается использование утилиты 7МТТ для переноса старой конфигурациистарой 7М в СМ. В связи с чем выделенные Root Aggregate в 7М, пока что будут нужны.
Возможно в будущем это будет реализовано (при наличии выделенных root aggregate для 7М) путем создания второго вольюма с СМ root volume на на тех жевольюма Root агрегатах. Это вполне возможно, учитывая что в обоих режимах используется одинаковый тип HA политики для Root Aggregate (CFO). Но это только предположение, я не знаю роадмапродмап CFT.
tmk826
25.11.2015 18:14+1Самое обидное, что с pNFS не возможно иметь разделы, которые распределены по нескольким узлам в кластере.
bbk
26.11.2015 00:28Оказывается Infinite Vol поддерживают NFSv4.1 и pNFS.
tmk826
26.11.2015 10:54+1Странно почему наши NetApp партнёры ничего об этом продукте не говорят… Спасибо!
bbk
25.11.2015 18:35Да, infiniVol пока что не работает с pNFS.
Чего не хватает, на мой взгляд, это того, что NFSv4 в vSphere6 пока что не поддерживает балансировку по линкам (мультипасинг), множественные пути исспользуются только в режиме один активный, все остальные запасные.
Хотя в контексте vVol это этом нет большой необходимости.tmk826
26.11.2015 11:04в NFSv4,1/pNFS мультипасинг не предназначен для балансировки, к тому-же сервер должен поддерживать session connection trunking.
bbk
26.11.2015 11:42Почему вы считаете что мультипасинг NFSv4 не поедназначен и не сможет балансировать трафик?
tmk826
26.11.2015 13:12rfc5661#13.5 конечно говорит о «Data-server-level multipathing is used for bandwidth scaling via trunking and for higher availability», однако у клиента нет никакой информации о том разные ли это интерфейсы и о их качественных характеристиках (скорость, задержки). Это всего лишь лист IP адресов по которым можно достучатся до сервера
bbk
26.11.2015 17:43The NFSv4.1 file layout supports multipathing to multiple data server addresses. Data-server-level multipathing is used for bandwidth scaling via trunking (Section 2.10.5) and for higher availability of use in the case of a data-server failure.
tools.ietf.org/html/rfc5661#section-13.5tmk826
26.11.2015 18:42Правильно. Наши дата-сервера возвращают два IP адреса — v4 и v6 того-же самого интерфейса. Лоад балансиг не имеет смысла и клиент об этом не знает.
bbk
27.11.2015 18:05Пока что cDOT не поддерживает trunking в NFSv4.1, также как и vSphere6.
Но поддержка trunking планируется в будущих версиях cDOT.
navion
Жаль не сделали внутреннего интерконнекта хотя бы в младших моделях — без коммутатора можно подключить только 3 хоста вместо 4.
bbk
Весь прикол кластера в возможности масштабироваться, по этому внутренних портов небыло и не будет.
В следующем же поколении сделали не внутренний шиной, а внешними портами, просто на 2552 теперь не 2 а 4 порта на контроллер из которых два под кластер.
Так или иначе на практике я не видел чтобы 2240, cDOT и active-passive/active-active конфигурацией упирался в производительность порта.
iscsi
А что скажите про возможное узкое место в виде ATTO 6500N на AFF системе (в конфигурации MetroCluster)?
bbk
Кстати может стоило добавить и MC в перечень.
В MetroCluster есть рекомендация на длину стека (петлю), т.е. в зависимости от типа полок, дисков, конфигурации (MC или обычная система), версии Data ONTAP и контроллеров есть рекомендации на количество таких полок одном стеке.
На каждый стек приходится по два SAS-FC бриджа: в начале и конце стека.
Поддерживаются SAS-FC бриджи ATTO 6500 и новые ATTO 7500.
Первый бридж имеет 2 порта 8FC, второй 2 порта 16FC соответственно.
Рекомендации по длине стека для MC подбираются исходя из пропускной способности бриджей, чтобы они не были узким местом дисковой подсистемы.
К примеру для 8.3.0 MC поддерживается ATTO 6500 со следующей длинной стека: