Комментарии к записи: Вышел Data ONTAP 8.1 RC

Автор: bbk

bbk — Mon, 21 Jan 2013 10:22:59 +0000

>Minus
>Ну, вообще если я правильно понял ман по aggr add -64bit-upgrade, апгрейд произойдет только в том случае если мы а) добавляем новые диски

Есть ещё один вариант - апробированный и рабочий. Убить агрегат и создать снова 64-битный. Грубо, но работает.

Автор: romx

romx — Tue, 11 Oct 2011 02:29:15 +0000

> Да и даже если EMC-шный dual ownership такой плохой, почему бы не NetApp-у не обставить их и в этом моменте?

Ну, они и обставили :)

> Хорошего в том, что диски делятся на две части, ничего нет.

На самом деле это всерьез беспокоит, когда этих дисков - 12, а задача для стораджа - одна :)
Во всех остальных случаях это, на практике, не принципиальная проблема.

> Что же правильного и удобного в том, чтобы вместо того, чтобы прозрачно в автоматическом режиме распределять нагрузку между всеми дисками средствами СХД, строить нагромождения на прикладном уровне?

В том, что прикладной уровень это, как правило, уже умеет, и, как правило, делает это куда более умно и с учетом рабочей задачи, чем сторадж, который, обычно, ничего не знает про задачу.

В общем, тут есть два разных варианта подхода ~~мой и неверный~~.

Автор: Никита

Никита — Mon, 10 Oct 2011 19:43:10 +0000

У 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 систем

Автор: romx

romx — Mon, 10 Oct 2011 02:06:31 +0000

Никита:

Ну, по-моему это как-то уж совсем оверкилл и глушение рыбы атомной бомбой, использовать ради такого не менее чем pNFS.
Балансироваться между агрегейтами, если такая необходимость возникает, можно же (и нужно) и на уровне собственно прикладной задачи. Это и дешевле, и лучше работает.

К слову сказать, EMC для Clariion также не рекомендует доступ к дискам от двух контроллеров, если речь идет о производительности и существенной нагрузке. Это возможно, но не рекомендуетя в best practices, я об этом факте упоминал ранее, в постах про EMC. Так что NetApp тут не одинок, и просто сразу не занмается фигней, ведущей к ухудшению производительности доступа к дискам. :)

Впрочем, как выше уже подтвердили, pNFS буде в Cluster-mode, а, начиная с RC2, Cluster mode наконец будет поддерживать блочный доступ (FC, iSCSI) и многие другие привычные технологии, типа дедупликации, и двухузловая Cluster-mode будет стоит как двухузловая 7-Mode, что откроет многим возможность начать использовать Cm.

Автор: Никита

Никита — Sun, 09 Oct 2011 18:07:39 +0000

>> Думаю, что pnfs будет развиваться в рамках cluster-mode части Data ONTAP. Особой нужды в нем в двухконтроллерной конфигурации хранилища нет.

Как это нет нужды? А балансировка нагрузки между агрегатами двух разных голов? По мне так это чуть ли не самый важный архитектурный минус MetApp по сравнению с EMC - необходимость делить диски между двумя головами и невозможность балансировки между ними. А помимо этого, pNFS может дать возможность балансировки нагрузки от одного хоста к одному файлу через NFS по двум или более сетевым интерфейсам в транке. Так что, думается, pNFS был бы очень полезен для двухконтроллерной конфигурации

Автор: Minus

Minus — Mon, 03 Oct 2011 08:05:33 +0000

odna ptichka:

Да, рутовый агрегат апнуть до 64-бит можно, только расширив его за пределы 16Тб. Т.е. для маленьких 2040, например, из 12х2Тб SATA, счастья не случится, т.е. in-place upgrade невозможен.

Автор: odna ptichka

odna ptichka — Wed, 28 Sep 2011 09:57:11 +0000

как-то так
—-
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

odna ptichka — Wed, 28 Sep 2011 09:29:38 +0000

pNFS будет в RC2 (для С-Mode)

Автор: Minus

Minus — Tue, 27 Sep 2011 05:34:13 +0000

Ну, вообще если я правильно понял ман по aggr add -64bit-upgrade, апгрейд произойдет только в том случае если мы а) добавляем новые диски б) максимальный размер агрегата становится больше 16Тб. Во всех других случаях опция просто добавит диски.
По поводу бонусов - компрессия лично для меня на первом месте (у меня один FAS2040 для NDMP и файловых бэкапов). Во-вторых, data motion. У меня основная система тоже 2040, но с максимальным количеством дисков, при этом так получилось, что SATA агрегаты 32bit, а SAS - 64bit. Так что - никакого ручного tiering-а, а хотелось бы. Понятно, что это надо было планировать изначально, но все равно обидно.

Автор: romx

romx — Tue, 27 Sep 2011 05:22:57 +0000

Minus:

Если так, то это неприятная новость.
А какие особенные бонусы от 64-bit для маленьких систем? Я так вот вижу разве только компрессию. Есть что-то еще, для, допустим, владельцев 2040 и пары десятков дисков?