Продолжим наше “журналистское расследование” и пройдем детальнее по моделям и семействам. Начнем с младшей серии – VNXe, которая, вследствие именитости вендора и привлекательности цены вызвала большой интерес на отечественном массовом рынке.
На что же следует обратить внимание, останавливая свой выбор на EMC VNXe, из того, о чем, часто, самим EMC упоминается вскользь. Или, как пишет один блоггер, “всегда читайте то, что написано на странице самым мелким шрифтом”. Вооружимся лупой и приступим к чтению :)
Как я уже писал в первой части, очевидной целью VNX/VNXe на рынке являются системы NetApp, слишком очевидно, что многое в них сделано с прицелом “ответ на”. А поэтому давайте определим, с какими системами NetApp соответствующие модели EMC VNXe конкурируют, и оценим их плюсы и минусы.
VNXe – это системы “младшего” семейства. Их естественным конкурентом являются модели 2000-й серии NetApp FAS, а также, отчасти, модель 3210 из “новых”. Напомню, что серия 2000 у NetApp состоит на сегодня из трех моделей, это FAS2020 и 2050, производящиеся с 2007 года, и подходящих к концу своей активной карьеры, и более новой FAS2040. Также частично в это семейство попадает FAS3210.
Совершенно естественно, что для VNXe возможности FAS2000 надо “крыть”, что, впрочем, по идее, не должно быть сложным, перебивать системы 4-летней давности.
В серии VNXe имеются две модели – VNXe 3100 и VNXe 3300.
VNXe 3100 превосходит по формальным параметрам FAS2020 (было бы удивительно, если бы новая система проигрывала бы по ним системе 4-летней давности;), например по максимальному количеству дисков (96 у 3100 против 60 у 2020) и больше кэш памяти (8GB против 2GB). Однако VNXe 3300 проигрывает по максимальному количеству дисков системе FAS2040 (120 против 136 дисков), но превосходит по объемам кэша (24 против 8 GB). Также в системах класса FAS2000 нет опции 10GB Ethernet, она появляется только на 3210.
Однако давайте посмотрим внимательнее на сторону общих ‘факапов’ ;)
Как я уже мельком упоминал в первой части, EMC решила в VNXe полностью отказаться от FC. FibreChannel в VNXe не предлагается даже как опция. В чем-то я даже соглашусь с таким решением, как вы знаете я последовательный сторонник Ethernet storage, но если в случае FAS2020 у нас есть выбор, продолжать использовать FC или нет, то в VNXe это решили за нас. Все, FC – вчерашний день. Его в этих системах не будет. Точка.
Как опция есть 10G Ethernet (для 3300 только). впрочем, как я понимаю, это не Unified Target, завести в него все интерфейсы и протоколы, и сделать в нем FCoE не выйдет. Также вопрос, насколько 10G Ethernet полноценно потянет внутренняя шина. В новых 3200/6200 у NetApp шина сделана PCIe 2.0, вдвое более широкая, чем обычный PCIe, не в последнюю очередь именно ради комфортного и достаточного обеспечения работы 10G Ethernet портов.
Довольно теоретическое ограничение для систем “малого класса” на количество LUN/Vol. У 3100 допустимо максимум 128 LUN и 256 Vol (512 у 3300), что сильно меньше, чем 1024 у FAS2020, хотя я не думаю, что такая маленькая система, как 3100 сможет упереться в 128 LUN-ов в реальной жизни. Но держать в памяти стоит.
Самая серьезная проблема, с которой столкнутся будущие покупатели VNXe, это, на мой взгляд, невозможность апгрейда с data-in-place (то есть с сохранением данных “на их местах”, на дисках) на более “взрослые” системы VNX, а также, если вы уже клиент EMC, то невозможности data-in-place с ваших текущих систем, например AX4 или NX4.
Если вы переросли VNXe, и захотели перейти на VNX, то не обманывайтесь похожестью аббревиатур, различие тут не в одной маленькой буковке ‘e’.
EMC VNX и VNXe это принципиально разные по внутреннему устройству системы. Просто перенестись между ними не выйдет, как и не выйдет перейти, например, с сегодняшней вашей Clariion AX4 или CX4-120, или Celerra NX4, на VNXe.
Переход возможен только с полным переносом данных со старой на новую. Старую систему забэкапили, остановили, вынули, новую собрали и поставили, проинсталлировали и разбили, и данные на нее восстановили. Старую можно попробовать продать на eBay ;)
У FAS2000 тоже не все в порядке с апгрейдабельностью на midrange, увы, это общая плата за дешевизну, но у них вы хотя бы штатно можете взять все ваши имеющиеся полки с дисками расширения и переключить их, прямо кабелями, на контроллер новой системы, будь то хоть даже FAS6280, и все данные увидятся, поднимутся и заработают немедленно после физического переключения. И в любом случае вы сможете использовать диски и полки от старых систем на новых. Новая серия FAS3200/6200, как и более ранние, поддерживает как FC, так и SAS.
По софту. Я уже говорил в первой части о определенных проблемах софтверного плана, остановлюсь на этом более подробно.
Я уже упоминал, что дедупликация на VNX/VNXe только пофайловая, то есть работает на NAS-уровне только, и дедуплицирует только полностью идентичные файлы, в отличие от субфайловой/блочной дедупликации NetApp, которая может дедуплицировать и содержимое различных файлов, если внутри у них есть сходные фрагменты. Пример – разные файлы vmdk с разными виртуальными машинами в них, но с идентичной OS, и, следовательно, сильно совпадающих по содержимому. В целом файлы vmdk не одинаковы, но в значительной мере идентичны внутри.
Как показывает исследование (например см. публикацию с конференции FAST’11: A Study of Practical Deduplication), субфайловая дедупликация сравнительно маленькими блоками (в случае NetApp размер фиксированного блока равен 4KB) более эффективна, чем файловая.
Следует также помнить, что “файловая” дедупликация EMC не работает на самых “вкусных” с точки зрения дедупликации задачах, например на NFS-хранилище для VMware, где NetApp стабильно показывает 70-90% снижения занимаемого данными объема.
Возможно, во второй половине года, будет объявлено о выпуске блочной дедупликации у VNX. Обещаю тогда, когда она стант официально доступна, внимательно рассмотеть ее, прочитать все написанное мелким шрифтом (есть ощущение, что радость придет далеко не всем), и рассказать вам о ней.
Репликация для VNXe имеется только асинхронная. Конечно, асинхронная репликация более востребована, особенно на небольших системах, но тут опять же “все выбрали за нас”. “Вам не нужна синхронная репликация” (и рукой так, по джедайски;). Кроме того, репликация также не имеет никаких средств оптимизации (например компрессии) трафика, передаваемого по WAN. Это возможно сделать какими-то сторонними, внешними средствами, например с помощью устройств Riverbed, но у NetApp эта “компрессия” встроена.
Нет собственных средств для offsite-backup, например чего-то аналогичного SnapVault, а хранение снэпшотов на дисках системы по прежнему больно ударяет по производительности, каковой проблемы лишен NetApp.
SnapSure несовместим с дедупликацией (single-instancing) и компрессией. Либо снэпшоты, либо дедупликация и компрессия. Если вы планируете использовать дедупликацию и компрессию, вы сильно сокращаете набор доступных вам для этих данных возможностей, таких как клоны и снэпшоты.
Компрессия – постпроцесная, то есть как дедупликация в NetApp. Сперва записали много, а потом что-то вернули когда отработают процессы. У NetApp компрессия онлайн. То есть вы “на ходу” записываете на диски меньше.
Дедупликация и компрессия работают только на файловом уровне, а размер файлового тома не может превышать 16TB. Компрессия и дедупликация не работает для LUN-ов, VMDK, файлов PST, данных Oracle over dNFS, и прочего подобного.
Когда EMC говорит о полной сертификации под VMware, то тут есть определенная доля лукавства. В настоящий момент, по моим данным, VNXe 3100 сертифицирован только как NAS, а VNXe 3300 – только как iSCSI (если на момент публикации это уже изменилось – поправьте меня). Я уже писал ранее, в части 1, как все непросто с так называемым Unified Storage (делает жест “кавычки” пальцами рук;) в понимании EMC. И следовательно как все непросто с функциональной совместимостью между NAS и iSCSI SAN в такой конструкции.
Сильно муссируется факт принадлежности VMware компании EMC, из этого как-бы естественно должен вытекать вывод, что системы EMC для VMware “более родные”, однако тут не все так просто. Несмотря на то, что 70% акций VMware действительно принадлежит EMC, VMware (VMW) это independently listed company, то есть ее акции котируются на бирже независимо от акций EMC (а вот, например, Isilon (ISLN), или Data Domain (DDUP) других недавних покупок EMC – уже нет), и она во многом самостоятельно определяет свою политику на рынке. Парадоксально, но, если мне не изменяет память, отношения технологического партнерства у VMware с NetApp чуть ли не более продолжительные, чем с собственно EMC! Они были установлены еще до “покупки” VMware!
У VNXe (сейчас) нет возможности использовать SSD, а следовательно – нет FASTcache. У NetApp для FAS2000 тоже нет FlashCache, зато он есть в FAS3210, который вполне можно, умеючи, “умять” по цене в “старшие low-enterprise”, если Flash вам понадобится. Тем не менее помните, что когда EMC говорит про FASTcache, это не относится к VNXe.
Нет FAST VP – автоматизированного storage tiering, с переносом данных с SAS на NL-SAS.
Нет официальных, подтвержденных данных о производительности новой архитектуры. Ну то есть заталкивать девушек в Mini это прикольно и честно-благородно, но все же как там насчет баб производительности, а? Извините, что я вам весь пафос момента сбиваю, нам бы вот на IOPS-ы бы посмотреть, а? ;)
Впрочем, про производительность и о “EMC’s approach” к этому вопросу это мы еще поговорим в среду и далее.
Да, несомненно системы VNXe имеют поразительно низкую для своего класса цену. Но, строго говоря, “цена ниже рыночной” должна вас сперва насторожить (а только потом – обрадовать). Если VNXe так хорош, то почему его отдают так дешево? Нет ли тут some gotchas, как выражаются наши англоязычные друзья? Ведь не секрет, что в энтерпрайзе “потребительская ценность” есть сумма из:
Цена железа + бренд + потребительские свойства = потребительская ценность
Если бренд высок у обоих вендоров, если цена физического железа примерно равна, то низкую цену для потребителя на выходе мы можем получить только за счет какой-то недостачи в потребительских свойствах, по сравнению с аналогичным продуктом конкурента, какую мы и постараемся замаскировать “привлекательной ценой”. Либо же объявленная цена есть фактический “порог рентабельности”, а значит нет надежд на значительную скидку в процессе привычного торга в “треугольнике” вендор-партнер-клиент.
Да, цена у NetApp обычно высока, но почему именно она высока, я уже писал в посте ранее. За большую цену и возможностей вам достается больше. Для многих это достаточный аргумент, для кого-то – нет. Но я бы хотел, чтобы вы помнили очень хорошую фразу в отношении цены покупки в IT: “Деньги вы экономите один раз и “дядины”, а геморрой покупаете надолго и свой”.
Пусть не застилает вам глаза низкая цена.
