Смотрим на EMC VNX/VNXe внимательно. Часть 2
Сегодня у нас не просто дюжина, а целых три дюжины ножей в спину EMC-шной “революции”, “неудобные вопросы” к EMC по поводу VNX/VNXe от блоггера Recoverymonkey (Dimitris Krekoukias), общим числом 36, опубликованные в его блоге.
Dimitris – сотрудник NetApp, но ведущий собственный, автономный и независимый блог, вне blogs.netapp.com, пишущий много интересного, так что переводы его публикаций в этом блоге будут появляться часто.
Беспрецедентная маркетинговая шумиха, поднятая вокруг старта новых продуктов EMC – систем VNX/VNXe не должна совсем запорошить нам глаза, настолько, чтобы мы не могли критически проанализировать возможные недостатки новой системы, а их, если посмотреть внимательно, хватает. ?? в особенности остановимся на многократно повторяемом EMC-персонами в отношении новых систем слово Unified.
Немного сокращенный перевод поста recoverymonkey предлагается сегодня вашему вниманию.
Questions to ask EMC regarding their new VNX systems…
Posted on January 13, 2011 by Dimitris
- Возьмем, к примеру, систему VNX емкостью 100TB. Допустим, что мы отдали все 100TB под NAS. Допустим, что все 100TB были первоначально заполнены данными, но затем, год спустя, объемы данных в NAS уменьшились, и сейчас занимают всего 70TB. Могу я взять эти освободившиеся 30TB и немедленно использовать их под FC? Ну хранилище же теперь “unified”, так? Без необходимости нарушать best practices для размещения LUN на Celerra?
- Является ли VNX (или хотя бы NS, стоящая перед ним) системой, сертифицированной на “пять девяток”? (Это так для CX, но как насчет комбинации CX/NS?)
- Где в архитектуре принципиальная разница с тем, что было до сих пор? Все выглядит так, что у вас есть 2 штуки CX SP, и перед ними NAS gateways. Выглядит очень похоже на то что было, и по прежнему в этом нет ничего unified. Давайте все же привнесем немного правды в рекламу! Только маленькие VNXe выглядят чуть иными (не с точки зрения софта, но хотя бы с точки зрения количества корпусов, на которых это работает).
- Кажется новые системы лицензируются по емкости?
- Могут ли новые системы использовать больше 2TB в FAST Cache? (больше чем текущий CLARiiON CX4-960)
- Как дела с гранулярностью при использовании RecoverPoint при репликации NAS-части? Кажется там необходимо реплицировать весь NAS как единый чанк, как одну большую consistency group, с необходимостью использовать Celerra Replicator для большей гранулярности?
- Как дела с гранулярностью при восстановлении NAS в RecoverPoint? Нельзя сделать восстановление на уровне отдельного файла или даже тома?
- Можно ли сделать обновление с сохранением данных на дисках, в случае уже имеющихся CX3 или CX4 (data-in-place upgrade) или это обновление с полной заменой (forklift upgrade)?
- Почему FASTv2 не рекомендован для Exchange 2010?
- Может ли FAST на VNX исключать из анализа ряд периодов времени, которые могут сбить его алгоритм, например период создания резервной копии данных?
- А FAST файлового уровня это по прежнему отдельная подсистема?
- Почему для VNXe в принципе нет варианта использовать FC?
- Можно ли обновиться с VNXe на VNX?
- А на VNXe есть FAST?
- Почему FAST по-прежнему использует такой огромный и неэффективный чанк размером аж 1GB?
- Почему такие функции, как блочный доступ, NAS и репликация по прежнему требуют использования отдельного друг от друга железа и софта?
- Почему по-прежнему существуют две различные системы создания снэпшотов?
- Ну хотя бы теперь блочные снэпшоты не вызывают такого огромного падения производительности? Кстати, как дела со снэпшотами на NAS?
- Хотя бы теперь мы можем хранить снэпшоты на системе подолгу, например год, если это нам необходимо?
- Почему предлагается целых 4(четыре!) разных средства репликации? (Mirrorview, Celerra Replicator, Recoverpoint, SAN copy)
- Что там о сих пор делают в таком количестве все эти разные OS? (Windows в StorageProcessor, Linux в Control Station и RecoverPoint, DART в NAS-blades, может быть больше, если вы захотите добавить Rainfinity и Atmos)
- Почему по-прежнему нет дедупликации для FC и iSCSI?
- Почему нет дедупликации для памяти/кэша?
- Наконец, почему нет суб-файловой дедупликации вообще?
- Почему Celerra по-прежнему ограничена объемом 256TB на один data mover?
- ?? Celerra по-прежнему ограничена объемом 16TB на том? ??ли нам нужна еще одна, полностью отдельная система (Isilon), чтобы получить объем тома больше 16TB?
- Celerra по-прежнему не умеет совместно использовать том между data movers? ??ли для этого опять нужен Isilon?
- Почему мы не можем передавать все протоколы по одному 10Gb-линку, если VNX это настоящий “unified”?
- Устранены ли проблемы с производительностью при использовании thin provisioning ?
- Устранены ли проблемы с “узким горлом” (bottlenecks) для пула?
- Можем ли мы в самом деле делать stripe/restripe в пуле FLARE? Когда добавляем пространство? С использованием thin provisioning?
- Для того, чтобы использовать thin provisioning, по-прежнему нужна миграция данных?
- Устранены ли проблемы с низкой эффективностью RAID5 и RAID6 при записи? ?? каким образом?
- Будут ли бенчмарки для новых систем показываться для RAID6, или это будет, по-прежнему, только RAID10? Как насчет участия в бенчмарках SPC-1?
- Почему EMC по-прежнему обходит стороной тот факт, что ее пулы теперь построены с использованием файловой системы? Может быть потому, что они продолжают утверждать, что такое, де, не настоящий SAN, даже в совсем недавних утверждениях?
- Теперь, когда EMC использует файловую систему чтобы получить в CX SPs функциональность пулов, thin provisioning, компрессии и auto-tiering (и, возможно, дедупликаци в будущем), как собирается решаться проблема фрагментации? (О как повернулась ситуация!)
Таким образом, когда EMC говорит о “Unified Storage”, они на самом деле имеют ввиду “Unified Management”. Было бы здорово, если бы они были честными, и так бы это и говорили, о “наших новых системах хранения, с новым единым управлением, пусть и не unified-архитектурой”.
Но “новые системы хранения с unified-управлением но не-unified-архитектурой” гораздо хуже выговаривается, чем “unified storage”.
Unified Management, к сожалению, не может помочь решить многих нижележаших проблем и ограничений, хотя, безусловно, позволяет показать ряд впечатляющих демонстраций.
Крутой GUI под которым находится наскоро слепленный франкенсторадж с использованием множества различных технологий, это конечно “работает” для пользователя, и винегрет под общей крышкой хорошо замаскирован снаружи, пока все… как правило в самый неподходящий для этого момент.
Конечно, средства управления это основной “интерфейс к системе” для конечного пользователя, многие люди не заботятся о том, что там, за ним, внутри, у них нет ни времени, ни склонности учиться. Я просто хочу пригласить их узнать побольше, начать думать о том, как оно там устроено внутри, потому что когда там внутри устраиваются какие-то трюки, и когда внешний GUI прикрывает разрозненных 4-5 различных продуктов, собранных под ним вместе, и когда оно перестает работать так, как задумано, то вас могут начать “футболить” между 3-4 различными и плохо связанными между собой группами поддержки, которые будут пытаться выяснить, какой из продуктов в итоге явился причиной проблемы.
Всегда думайте в плане того, что будет, если что-то пойдет “не так”, и всегда предполагайте, что вещь сломается – только в этом случае вы будете иметь готовыми надлежащие процедуры, и будете готовы к худшему.
?? всегда помните, что чем сложнее машина, тем сложнее найти поломку, тем сложнее ее починить, когда она сломалась (а она сломается, они всегда ломаются, все и всегда). Никакая внешняя красота не заменяет чистого и простого инженерного решения внутри.
Конечно, машина в стиле Rube Goldberg-а это прикольно, если прикол есть ваша конечная цель.