Еще одна приятная возможность для администратора - можно сильно упростить жизнь за счет использования 'network subnet'. Вместо того, чтобы назначать каждому логическому интерфейсу (LIF) конкретный адрес, администратор назначает пул адресов для широковещательного домена (broadcast domain). А уже при создании LIF, ему присваивается адрес из пула. Такой подход может быть крайне удобен в больших и часто меняющихся инфраструктурах.
В данном случае, клиенты в IPSpace A физически отделены от клиентов IPSpace B, но работают с одним кластером. Эта возможность актуальна для компаний, которые предоставляют системы NetApp в аренду "по кусочкам".
После этого система начнет процесс обновления (все происходит онлайн - данные доступны, пользователи ничего не замечают). Контролировать процесс можно командой:
Конечно нужно быть готовым к неприятностям, но лучше всего просто заранее изучить документацию - тогда неприятностей можно и избежать.
Обновлять систему стало легко, но так ли просто обновить несколько кластеров сразу на нескольких площадках, объединенных в единую инфраструктуру? Далеко не факт. Но если мы используем репликацию (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 раза:
| FAS8080 EX |
144 TiB |
| FAS8060 |
72 TiB |
| FAS8040 |
48 TiB |
| FAS8020 |
24 TiB |
| FAS25xx |
16 TiB |
