Вышел Data ONTAP 8.1 RC
Вышел долгожданный 8.1
Напомню, что по введенной с июля 2010 года модели именования релизов, выпуск под названием RC (Release Candidate) является полноценным релизом, оттестированным и готовым в продакшн.
Цитата с сайта:
Release Candidate (RC)
All Data ONTAP releases are made available first as release candidates (RCs). The RC classification indicates that NetApp has completed the internal testing of the major release. RCs are provided primarily to customers who want to start exploring the major or maintenance releases for either new features or bug fixes early on. RC releases are fully tested and are suitable for production usage. (выделение мое, romx)
NetApp might provide multiple RCs, as necessary, to address any specific issues found before the release becomes a general availability (GA) release. NetApp Global Services (NGS) provides support for RCs. After RCs move to GA, all maintenance and patch releases are based on the GA release and not on the RC.
Релизы “цифра после запятой” (Major Release) выходят каждые 18 месяцев, после их выпуска, каждые 6 месяцев выпускаются так называемые Maintenance Release.
Список изменений довольно велик и существеннен. Очень много важных изменений, поэтому далее я собрал почти все значимое, в кратком переводе. Порядок пунктов хаотичный и не слишком системный, просто FYI.
Появился FC-to-SAS Bridge. Теперь Metrocluster может строиться на полках DS4243 и DS2246, с дисками SAS, а не на старых DS14MK4 c дисками FC. В этом качестве будет продаваться ATTO FiberBridge 6500N. Его поддержка появилась в 8.1RC1.
Также поддерживается прямое включение устройств на магнитной ленте с интерфейсом SAS (а не только FC, как раньше).
Прекращена поддержка полок DS14MK2 с интерфейсными модулями ESH2. Так что если вы все еще используете такие – не обновляйтесь на 8.1.
Появился механизм так называемого cache rewarming. ??звестная проблема с инвалидацией и опустошением (и последующим новым наполнением) кэша Flash Cache при кластерном тэйковере или ином отключении контроллера (наполнение это, вследствие большого размера кэша, было продолжительно и довольно болезненно), теперь решена остроумным способом. WAFL делает снэпшот для находящегося в Flash Cache сегмента данных, а когда система возвращается в работу, Flash Cache восстанавливается из этого снэпшота. Напомню, что Flash Cache это кэш только чтения, поэтому проблем с flush-ем данных на диски в нем, при такой ситуации, там просто нет в принципе, и можно сделать rewarming вот таким простым и изящным способом. Этот режим теперь включен по умолчанию.
Появился механизм reallocation на дедуплицированных томах. Напомню, раньше, на дедуплицированных томах, средства data reallocation в WAFL практически не работали. Примерно понимая всю принципиальную сложность задачи дефрагментации при дедупликации, интересно как именно они этого добились.
Больше не будет FilerView – традиционного веб-интерфейса, встроенного в систему. Пользуйтесь System Manager 2.0.
Появились новые средства System Health Monitoring.
Улучшения в Autosupport.
Теперь, для новых систем, по умолчанию создаваемый aggregate выбран как 64-bit. Root vol также располагается по умолчанию и первоначальной установке системы на 64-bit aggregate.
Aggregate snapshot reserve установлен в 0 по умолчанию, за исключением создания aggregate для syncmirror, там он используется и там по прежнему 5%.
Почти повсюду поддерживается IPv6, в том числе в RLM и SP (в BMC, в FAS2040 – нет).
Появилась поддержка TLS (Transport Layer Security) v1.0,в дополнение к SSL.
??зменились дефолтные установки безопасности для протоколов. Теперь безопасные протоколы (SSH, HTTPS) включены по умолчанию, а небезопасные (RSH, Telnet, FTP, HTTP) – выключены.
Устрожена политика пароля для root-user. Пароль должен быть минимум 8 символов, хотя бы одну цифру, и хотя бы две буквы.
Появился специальный (отключенный по умолчанию) логин diag, для диагностики и траблшутинга в консоли. Это специальный служебный пользователь, работа которым предполагается только под руководством службы поддержки для диагностики проблем. (что-то типа нынешнего priv set diag?)
Улучшения и модификации в boot menu.
??зменения в механизме работы лицензий. Теперь бесплатные опции, такие как дедупликация, не будут требовать лицензий вовсе. Также появятся “групповые” лицензии, на пак функций целиком.
Появилась долгожданная возможность конверсии 32-bit aggregate в 64-bit, без копирования и перемещения данных, in place.
Будет поддерживаться работа Volume SnapMirror между aggregates разных типов (32 на 64 и обратно).
Увеличен размер aggregates для некоторых платформ.
Больше нет лимита на поддиректории (раньше было ограничение в 99998 вложенных поддиректорий для директории, если это вас беспокоит;)
Появилась поддержка SFTP и FTPS (FTP-over-SSL).
Snapshot Reserve для томов FlexVol, создаваемый по умолчанию, уменьшен до 5%.
Заработал SnapLock.
Теперь Data Motion for vFilers (непрерывающая работу vFiler-ов миграция их) возможна не только между контроллерами одной системы хранения, но и между разными системами хранения NetApp.
Появился интерактивный шелл SSH в vFiler ( то есть прямо в конкретный vFiler, без необходимости входить в vFiler0 и переключать контекст). Также поддерживается IPv6.
Компрессия (и управление ей) теперь работает и в vFiler (не только в vFiler0, как ранее)
База фингерпринтов дедупликации теперь хранится в двух экземплярах, одна на уровне FlexVol (как до DOT 7.3), и одна на уровне aggregate (как после 7.3). Это, как я понимаю, позволяет решить проблему с продолжением дедупликации после репликации тома на другую систему, без необходимости пересканировать и пересоздавать базу fingerprints, которая после репликации оставалась на старой системе.
Компрессия теперь работает для SnapLock и для обоих типов Metrocluster.
a pnfs?
про размеры томов и агрегатов забыл
odna ptichka:
Не, не забыл.
> Увеличен размер aggregates для некоторых платформ.
Но в Whatsnew никаких подробностей сверх этого не было.
tmk:
Думаю, что pnfs будет развиваться в рамках cluster-mode части Data ONTAP. Особой нужды в нем в двухконтроллерной конфигурации хранилища нет.
Обидно то, что отсутствует возможность апгрейда до 64bit агрегатов, содержащих root-vol. :(
Владельцы маленьких систем, у которых все на aggr0, все еще не могут познать все бонусы 64bit агрегатов.
Minus:
Если так, то это неприятная новость.
А какие особенные бонусы от 64-bit для маленьких систем? Я так вот вижу разве только компрессию. Есть что-то еще, для, допустим, владельцев 2040 и пары десятков дисков?
Ну, вообще если я правильно понял ман по aggr add -64bit-upgrade, апгрейд произойдет только в том случае если мы а) добавляем новые диски б) максимальный размер агрегата становится больше 16Тб. Во всех других случаях опция просто добавит диски.
По поводу бонусов - компрессия лично для меня на первом месте (у меня один FAS2040 для NDMP и файловых бэкапов). Во-вторых, data motion. У меня основная система тоже 2040, но с максимальным количеством дисков, при этом так получилось, что SATA агрегаты 32bit, а SAS - 64bit. Так что - никакого ручного tiering-а, а хотелось бы. Понятно, что это надо было планировать изначально, но все равно обидно.
pNFS будет в RC2 (для С-Mode)
как-то так
—-
CAN I EXPAND MY 32-BIT ROOT AGGREGATE TO 64-BIT?
If there is a strong requirement to expand your root aggregate beyond 16TB, you can add disks and trigger the 64-bit expansion on the root aggregate
odna ptichka:
Да, рутовый агрегат апнуть до 64-бит можно, только расширив его за пределы 16Тб. Т.е. для маленьких 2040, например, из 12х2Тб SATA, счастья не случится, т.е. in-place upgrade невозможен.
>> Думаю, что pnfs будет развиваться в рамках cluster-mode части Data ONTAP. Особой нужды в нем в двухконтроллерной конфигурации хранилища нет.
Как это нет нужды? А балансировка нагрузки между агрегатами двух разных голов? По мне так это чуть ли не самый важный архитектурный минус MetApp по сравнению с EMC - необходимость делить диски между двумя головами и невозможность балансировки между ними. А помимо этого, pNFS может дать возможность балансировки нагрузки от одного хоста к одному файлу через NFS по двум или более сетевым интерфейсам в транке. Так что, думается, pNFS был бы очень полезен для двухконтроллерной конфигурации
Никита:
Ну, по-моему это как-то уж совсем оверкилл и глушение рыбы атомной бомбой, использовать ради такого не менее чем pNFS.
Балансироваться между агрегейтами, если такая необходимость возникает, можно же (и нужно) и на уровне собственно прикладной задачи. Это и дешевле, и лучше работает.
К слову сказать, EMC для Clariion также не рекомендует доступ к дискам от двух контроллеров, если речь идет о производительности и существенной нагрузке. Это возможно, но не рекомендуетя в best practices, я об этом факте упоминал ранее, в постах про EMC. Так что NetApp тут не одинок, и просто сразу не занмается фигней, ведущей к ухудшению производительности доступа к дискам. :)
Впрочем, как выше уже подтвердили, pNFS буде в Cluster-mode, а, начиная с RC2, Cluster mode наконец будет поддерживать блочный доступ (FC, iSCSI) и многие другие привычные технологии, типа дедупликации, и двухузловая Cluster-mode будет стоит как двухузловая 7-Mode, что откроет многим возможность начать использовать Cm.
У EMC-шного dual ownership есть недостатки, в частности увеличивается latency, но тем не менее выигрыш в IOPS-ах получить можно. Да и даже если EMC-шный dual ownership такой плохой, почему бы не NetApp-у не обставить их и в этом моменте? Хорошего в том, что диски делятся на две части, ничего нет. Балансироваться между агрегатами на уровне прикладной задачи? Что же правильного и удобного в том, чтобы вместо того, чтобы прозрачно в автоматическом режиме распределять нагрузку между всеми дисками средствами СХД, строить нагромождения на прикладном уровне? Это все равно что распределять нагрузку по дискам не путем построения из них RAID-а, а “на уровне прикладной задачи”. Например, вместо одной базы SQL на RAID из четырех дисков, поднять кластер из 4-х SQL серверов, каждый их которых использовал бы один диск. ?? что такого дорогого и оверкильного в pNFS , особенно учитывая, что “…двухузловая Cluster-mode будет стоит как двухузловая 7-Mode, что откроет многим возможность начать использовать Cm.”? Разве что на pNFS будет идти отдельная от NFS дорогущая лицензия, но это уже вопрос не к дороговизне pNFS самой по себе, а к маркетингу. Так и ту же дедупликацию можно было бы сделать платной и считать, что это нечто только для high end систем
> Да и даже если EMC-шный dual ownership такой плохой, почему бы не NetApp-у не обставить их и в этом моменте?
Ну, они и обставили :)
> Хорошего в том, что диски делятся на две части, ничего нет.
На самом деле это всерьез беспокоит, когда этих дисков - 12, а задача для стораджа - одна :)
Во всех остальных случаях это, на практике, не принципиальная проблема.
> Что же правильного и удобного в том, чтобы вместо того, чтобы прозрачно в автоматическом режиме распределять нагрузку между всеми дисками средствами СХД, строить нагромождения на прикладном уровне?
В том, что прикладной уровень это, как правило, уже умеет, и, как правило, делает это куда более умно и с учетом рабочей задачи, чем сторадж, который, обычно, ничего не знает про задачу.
В общем, тут есть два разных варианта подхода
мой и неверный.>Minus
>Ну, вообще если я правильно понял ман по aggr add -64bit-upgrade, апгрейд произойдет только в том случае если мы а) добавляем новые диски
Есть ещё один вариант - апробированный и рабочий. Убить агрегат и создать снова 64-битный. Грубо, но работает.