Смотрим на 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

  1. Возьмем, к примеру, систему VNX емкостью  100TB. Допустим, что мы отдали все 100TB под NAS. Допустим, что все 100TB были первоначально заполнены данными, но затем, год спустя, объемы данных в NAS уменьшились, и сейчас занимают всего 70TB. Могу я взять эти освободившиеся 30TB и немедленно использовать их под FC? Ну хранилище же теперь “unified”, так? Без необходимости нарушать  best practices для размещения LUN на Celerra?
  2. Является ли VNX (или хотя бы NS, стоящая перед ним) системой, сертифицированной на “пять девяток”? (Это так для CX, но как насчет комбинации CX/NS?)
  3. Где в архитектуре принципиальная разница с тем, что было до сих пор? Все выглядит так, что у вас есть 2 штуки CX SP, и перед ними NAS gateways. Выглядит очень похоже на то что было, и по прежнему в этом нет ничего unified. Давайте все же привнесем немного правды в рекламу! Только маленькие VNXe выглядят чуть иными (не с точки зрения софта, но хотя бы с точки зрения количества корпусов, на которых это работает).
  4. Кажется новые системы лицензируются по емкости?
  5. Могут ли новые системы использовать больше 2TB в FAST Cache? (больше чем текущий CLARiiON CX4-960)
  6. Как дела с гранулярностью при использовании RecoverPoint при репликации NAS-части? Кажется там необходимо реплицировать весь NAS как единый чанк, как одну большую consistency group, с необходимостью использовать Celerra Replicator для большей гранулярности?
  7. Как дела с гранулярностью при восстановлении NAS в RecoverPoint? Нельзя сделать восстановление на уровне отдельного файла или даже тома?
  8. Можно ли сделать обновление с сохранением данных на дисках, в случае уже имеющихся CX3 или CX4 (data-in-place upgrade) или это обновление с полной заменой (forklift upgrade)?
  9. Почему FASTv2 не рекомендован для Exchange 2010?
  10. Может ли FAST на VNX исключать из анализа ряд периодов времени, которые могут сбить его алгоритм, например период создания резервной копии данных?
  11. А FAST файлового уровня это по прежнему отдельная подсистема?
  12. Почему для VNXe в принципе нет варианта использовать FC?
  13. Можно ли обновиться с VNXe на VNX?
  14. А на VNXe есть FAST?
  15. Почему FAST по-прежнему использует такой огромный и неэффективный чанк размером аж 1GB?
  16. Почему такие функции, как блочный доступ, NAS и репликация по прежнему требуют использования отдельного друг от друга железа и софта?
  17. Почему по-прежнему существуют две различные системы создания снэпшотов?
  18. Ну хотя бы теперь блочные снэпшоты не вызывают такого огромного падения производительности? Кстати, как дела со снэпшотами на NAS?
  19. Хотя бы теперь мы можем хранить снэпшоты на системе подолгу, например год, если это нам необходимо?
  20. Почему предлагается целых 4(четыре!) разных средства репликации? (Mirrorview, Celerra Replicator, Recoverpoint, SAN copy)
  21. Что там о сих пор делают в таком количестве все эти разные OS? (Windows в StorageProcessor, Linux в Control Station и RecoverPoint, DART в NAS-blades, может быть больше, если вы захотите добавить Rainfinity и Atmos)
  22. Почему по-прежнему нет дедупликации для FC и iSCSI?
  23. Почему нет дедупликации для памяти/кэша?
  24. Наконец, почему нет суб-файловой дедупликации вообще?
  25. Почему Celerra по-прежнему ограничена объемом 256TB на один data mover?
  26. И Celerra по-прежнему ограничена объемом 16TB на том? Или нам нужна еще одна, полностью отдельная система (Isilon), чтобы получить объем тома больше 16TB?
  27. Celerra по-прежнему не умеет совместно использовать том между data movers? Или для этого опять нужен Isilon?
  28. Почему мы не можем передавать все протоколы по одному 10Gb-линку, если VNX это настоящий “unified”?
  29. Устранены ли проблемы с производительностью при использовании thin provisioning ?
  30. Устранены ли проблемы с “узким горлом” (bottlenecks) для пула?
  31. Можем ли мы в самом деле делать stripe/restripe в пуле FLARE? Когда добавляем пространство? С использованием thin provisioning?
  32. Для того, чтобы использовать thin provisioning, по-прежнему нужна миграция данных?
  33. Устранены ли проблемы с низкой эффективностью RAID5 и RAID6 при записи? И каким образом?
  34. Будут ли бенчмарки для новых систем показываться для RAID6, или это будет, по-прежнему, только RAID10? Как насчет участия в бенчмарках SPC-1?
  35. Почему EMC по-прежнему обходит стороной тот факт, что ее пулы теперь построены с использованием файловой системы? Может быть потому, что они продолжают утверждать, что такое, де, не настоящий SAN, даже в совсем недавних утверждениях?
  36. Теперь, когда 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-а это прикольно, если прикол есть ваша конечная цель.

Оставить комментарий

20/0.134

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.