Я совсем недавно уже писал про одно из нововведений в cDOT 8.3 - поддержку MetroCluster, но считаю нужным упомянуть и другие возможности, которые пользователи получат в новой версии. Список изменений весьма обширен - более 40 из 90 страниц отведены перечислению именно новых возможностей.
Что первым бросается в глаза? Конечно система управления - теперь System Manager интегрирован в Data ONTAP! Больше не нужно устанавливать на компьютер приложение, мучаться с версиями Java - достаточно открыть браузер, набрать адрес и после этого мы получаем полноценную систему управления (на HTML5). Уверен, это это придется по душе очень многим админам!
Еще одна приятная возможность для администратора - можно сильно упростить жизнь за счет использования 'network subnet'. Вместо того, чтобы назначать каждому логическому интерфейсу (LIF) конкретный адрес, администратор назначает пул адресов для широковещательного домена (broadcast domain). А уже при создании LIF, ему присваивается адрес из пула. Такой подход может быть крайне удобен в больших и часто меняющихся инфраструктурах.
Использование IP Spaces для изоляции SVM - еще одна возможность для построения развитой инфраструктуры. IP Spaces позволяют получать доступ к кластеру из несвязанных подсетей - даже если клиенты имеют одинаковые адреса:
В данном случае, клиенты в IPSpace A физически отделены от клиентов IPSpace B, но работают с одним кластером. Эта возможность актуальна для компаний, которые предоставляют системы NetApp в аренду "по кусочкам".
Миграция LUN - администратор должен был очень внимательно подходить к процессу планирования системы с самого начала - если уж создали LUN, то перемещать его потом даже внутри системы будет не слишком просто и потребуется остановить доступ к данным. Теперь можно спокойно перемещать LUN внутри SVM без прерывания доступа к данным. Миграция происходит совершенно прозрачно для пользователя и работающих приложений. Далеко не всегда можно заранее спланировать рост нагрузки и требования, поэтому возможность онлайн миграции крайне важна для обеспечения эффективности.
В больших конфигурациях, можно получить слишком большое количество путей от хоста до LUN - это является проблемой управления, но может влиять и на производительность. Для того, чтобы поддержать число путей в рамках разумных границ, теперь используется технология Selective LUN Mapping (SLM) - хост видит только нужные пути до системы, а лишние спрятаны (но могут быть включены при необходимости. Коллеги писали об этом совсем недавно (есть примеры команд).
В больших конфигурациях, можно получить слишком большое количество путей от хоста до LUN - это является проблемой управления, но может влиять и на производительность. Для того, чтобы поддержать число путей в рамках разумных границ, теперь используется технология Selective LUN Mapping (SLM) - хост видит только нужные пути до системы, а лишние спрятаны (но могут быть включены при необходимости. Коллеги писали об этом совсем недавно (есть примеры команд).
Автоматизация процесса обновления ПО. Еще одна "крутая фишка". В самых разных ситуациях я сталкивался с тем, что система работает, на ней наблюдаются какие-то проблемы (не критичные, но малоприятные). Спрашиваешь, а почему не обновить на новый микрокод - там же есть исправление как раз вашей проблемы? "Мы бы с удовольствием, но для нас очень проблематично выделить время на обновление и столкнуться с угрозой остановки сервиса. Кроме того, это очень сложная процедура." И это длится год за годом! Теперь такая проблема больше не должна волновать - администратору достаточно всего трех команд, чтобы запустить процесс обновления:
После этого система начнет процесс обновления (все происходит онлайн - данные доступны, пользователи ничего не замечают). Контролировать процесс можно командой:cluster image package get cluster image validate cluster image update
cluster image show-update-progress
Конечно нужно быть готовым к неприятностям, но лучше всего просто заранее изучить документацию - тогда неприятностей можно и избежать.
Обновлять систему стало легко, но так ли просто обновить несколько кластеров сразу на нескольких площадках, объединенных в единую инфраструктуру? Далеко не факт. Но если мы используем репликацию (Snap Mirror), то для ее нормального функционирования нужно было поддерживать одинаковые версии и всегда обновлять сначала "получателя" данных. В случае, если репликация идет в обе стороны, приходится останавливать SnapMirror на время апгрейда. Теперь у нас есть version-flexible SnapMirror, благодаря которому можно спокойно обновлять любой из узлов без остановки репликации. Еще одна задача администрирования решена! Для поддержки распределенной отказоустойчивый инфраструктуры это очень важное нововведение.
Раз уж затронули SnapMirror, то теперь при передаче данных используется компрессия, что позволяет снижать нагрузку на сеть и каналы связи. Не могу сдержаться - FalconStor NSS умел так делать еще лет 10 тому назад! :) В любом случае, это еще один плюс в копилку.
У заказчиков, использующих SnapVault появлиась возможность восстанавливать данные на уровне отдельных файлов (технология On-Demand Data Management). Данные доступны пользователю сразу и он может с ними работать, пока происходит копирование на основную систему.
Перейдем к производительности и эффективности хранения.
Больше не записываем нули на диски! Для томов с включенной дедупликацией, в онлайне находятся блоки из одних нулей и они не записываются на диски (Inline zero write detection and elimination). В VMware, например, мы создаем eager zeroed диски, чтобы обеспечить неизменный уровень производительности, но из-за архитектуры WAFL, нам нет нужды записывать нули на диски. Кроме того, существуют и другие специфические задачи, когда за счет исключения нулевых блоков, мы получаем заметный прирост производительности.
Еще одно направление оптимизации - All-Flash Optimized personality. Для All-Flash систем мы отказываемся от всех алгоритмов по оптимизации работы с обычными дисками, так как все это бесполезно для SSD дисков. Как следствие, производительность системы возрастает, а там, где борьба идет за микросекунду, любая оптимизация может быть критичной. AFF personality доступна только для FAS80xx и не позволяет использовать обычные диски - только SSD.
Также улучшена производительность на случайных операциях чтения - наиболее заметно для SSD, но и на обычных дисках при определенных типах нагрузки должно быть видно.
Следить за производительностью стало удобнее - собирать статистику можно уже не на уровне агрегата, а на уровне отдельного тома (qos statistics volume show).
Что касается эффективности, то самая большая проблема в младших системах (с небольшим числом дисков) это объяснить заказчику, куда делось все то дисковое пространство, за которое он заплатил. Для каждого контроллера отдельные диски выделим под root (рекомендуется RAID-DP) плюс еще пара дисков в резерв (spare). И вот, в самой младшей системе от 12 дисков осталось 2 под данные.
Да, конечно, можно немного "поколдовать" и улучшить ситуацию (здесь RAID4, там один spare диск) - в результате, что-то подходящее можно собрать. Но, во-первых, это нужно делать руками (и игнорировать предупреждения системы), а, во-вторых, даже в этом случае, мы получаем не слишком-то большой объем. Поэтому систему из 12 дисков сложно использовать как active-active, так как на одном из контроллеров будет всегда слишком мало дисков. Наконец-то, в Data ONTAP 8.3 появилось решение - Advanced Disk Partitioning (ADP). После метрокластера, мне кажется, это вторая по значимости новость - можно на одних и тех же физических дисках размещать два агрегата - для root и для данных. Причем, для root мы можем собрать RAID-DP и два spare "блока", а для данных один резервный блок. Теперь конфигураций с 12ю дисками можно уже пользоваться "из коробки" - полезного пространства стало гораздо больше.
И даже для системы с 12 дисками можно использовать active-active режим работы (полезная емкость конечно ниже, но мы можем делить нагрузку между контроллерами):
ADP очень хорошо работает и для AFF конфигураций - стоимость SSD дисков довольно высока и "выбрасывать" их на создание рутового агрегата довольно расточительно. Благодаря ADP, AFF система будет показывать лучшую экономику, при сравнении с конкурентами, чем ранее.
И третьим плюсом от ADP является оптимизация нагрузки на SSD диски в FashPool - на одних и тех же дисках можно создать агрегаты для каждого из контроллеров. Широкий страйпинг позволит обеспечить лучшую производительность системы.
Advanced Disk Partitioning можно использовать на младших системах (22хх) для совмещения root и data агрегатов на одних дисках, всех AFF конфигурациях и для всех систем в FlashPool.
В версии 8.3 также существенно увеличен максимальный объем FlashPool - рост в 4 раза:
Обновлять систему стало легко, но так ли просто обновить несколько кластеров сразу на нескольких площадках, объединенных в единую инфраструктуру? Далеко не факт. Но если мы используем репликацию (Snap Mirror), то для ее нормального функционирования нужно было поддерживать одинаковые версии и всегда обновлять сначала "получателя" данных. В случае, если репликация идет в обе стороны, приходится останавливать SnapMirror на время апгрейда. Теперь у нас есть version-flexible SnapMirror, благодаря которому можно спокойно обновлять любой из узлов без остановки репликации. Еще одна задача администрирования решена! Для поддержки распределенной отказоустойчивый инфраструктуры это очень важное нововведение.
Раз уж затронули SnapMirror, то теперь при передаче данных используется компрессия, что позволяет снижать нагрузку на сеть и каналы связи. Не могу сдержаться - FalconStor NSS умел так делать еще лет 10 тому назад! :) В любом случае, это еще один плюс в копилку.
У заказчиков, использующих SnapVault появлиась возможность восстанавливать данные на уровне отдельных файлов (технология On-Demand Data Management). Данные доступны пользователю сразу и он может с ними работать, пока происходит копирование на основную систему.
Перейдем к производительности и эффективности хранения.
Больше не записываем нули на диски! Для томов с включенной дедупликацией, в онлайне находятся блоки из одних нулей и они не записываются на диски (Inline zero write detection and elimination). В VMware, например, мы создаем eager zeroed диски, чтобы обеспечить неизменный уровень производительности, но из-за архитектуры WAFL, нам нет нужды записывать нули на диски. Кроме того, существуют и другие специфические задачи, когда за счет исключения нулевых блоков, мы получаем заметный прирост производительности.
Еще одно направление оптимизации - All-Flash Optimized personality. Для All-Flash систем мы отказываемся от всех алгоритмов по оптимизации работы с обычными дисками, так как все это бесполезно для SSD дисков. Как следствие, производительность системы возрастает, а там, где борьба идет за микросекунду, любая оптимизация может быть критичной. AFF personality доступна только для FAS80xx и не позволяет использовать обычные диски - только SSD.
Также улучшена производительность на случайных операциях чтения - наиболее заметно для SSD, но и на обычных дисках при определенных типах нагрузки должно быть видно.
Следить за производительностью стало удобнее - собирать статистику можно уже не на уровне агрегата, а на уровне отдельного тома (qos statistics volume show).
Что касается эффективности, то самая большая проблема в младших системах (с небольшим числом дисков) это объяснить заказчику, куда делось все то дисковое пространство, за которое он заплатил. Для каждого контроллера отдельные диски выделим под root (рекомендуется RAID-DP) плюс еще пара дисков в резерв (spare). И вот, в самой младшей системе от 12 дисков осталось 2 под данные.
ADP очень хорошо работает и для AFF конфигураций - стоимость SSD дисков довольно высока и "выбрасывать" их на создание рутового агрегата довольно расточительно. Благодаря ADP, AFF система будет показывать лучшую экономику, при сравнении с конкурентами, чем ранее.
И третьим плюсом от ADP является оптимизация нагрузки на SSD диски в FashPool - на одних и тех же дисках можно создать агрегаты для каждого из контроллеров. Широкий страйпинг позволит обеспечить лучшую производительность системы.
Advanced Disk Partitioning можно использовать на младших системах (22хх) для совмещения root и data агрегатов на одних дисках, всех AFF конфигурациях и для всех систем в FlashPool.
В версии 8.3 также существенно увеличен максимальный объем FlashPool - рост в 4 раза:
| FAS8080 EX | 144 TiB |
| FAS8060 | 72 TiB |
| FAS8040 | 48 TiB |
| FAS8020 | 24 TiB |
| FAS25xx | 16 TiB |
Почитать на тему:
Clustered Data ONTAP 8.3 Release Notes
Clustered Data ONTAP 8.3 Network Management Guide
Clustered Data ONTAP 8.3 SAN Administration Guide
Clustered Data ONTAP 8.3 Physical Storage Management Guide
2 комментария:
Андрей, не останавливайся (:
Не всегда, к сожалению, удается достаточно времени уделять. :( Но я стараюсь! А "не останавливаться" про NetApp или вообще? :)
Отправить комментарий