1. Это стоимость ViPR. И звучит это примерно так — мы тут спецом сделали дерьмовое управление и интеграцию, чтобы стрясти с вас ещё кучу бабла. А поверьте мне, когда у вас будет пару десятков массивов и петабайт, то стоимость ViPR вас крайне удивит…
2. Не буду заниматься рекламой, но есть прекрасный вендор СХД, который предоставляет такой софт бесплатно.
Мы только собираемся принять участие в этом празднике жизни. Для Active-Active есть всего два варианта, которые можно будет масштабировать еще, как минимум, 5 лет: EMC VPLEX и IBM SVC.
Уж лучше VPLEX, чем SVC :)
Вообще я рекомендую использовать VPLEX, только для тех приложений и сервисов, которым это реально надо, а не для всего и всех.
Какая интеграция имеется ввиду, SMI-S provider?
PowerPath/VE доступен для VPLEX Metro.
См. выше. ответил.
vipr
тоже упоси вас господь этим ужасом пользоваться. Я надеюсь в будущих версиях они с ним что-то сделают.
Имеется ввиду pvmove?
Просто делается зеркало для теукщих томов с новыми, а после того как синхронизация заканчивается — отрываем старые и все. Даунтайм был только для тех хостов, где LVM не стоял.
LUN «растянут» на все подлежащие массивы? Если да, то тут все очевидно.
В том-то и дело, что без растянутых LUN'ов. К сожалению очень сложно воспроизвести данный случай поэтому мы пока просто перейдем на 4-Egine конфигурацию для изоляции мощных потребителей на своих директорах.
Под интеграцией понимается, что PowerPath должен показывать имена Storage Group и томов, как он это делает для VNX и VMAX, но не делает для VPLEX. Хотя в то же время утилита networker inquire показывает имена девайсов на VPLEX (обнаружили случайно).
В результате взаимодействие с администраторами серверов очень сильно усложнилось. Так же нет специальных политик и оптимизации под VPLEX/
Как пользователь VPLEX (2 года мучаюсь), сочувствую людям, которым впарили этот хлам, потому что:
1. До сих пор у VPLEX нет интеграции с VNX и PowerPath
2. При большом количестве объектов управление тупит очень сильно (решение не предназначено для больших окружений, хотя парни из lufthansa как-то живут, хотел бы посмотреть как)
3. При проблемах с производительностью на одном из подлежащих массивах страдают все клиенты со всех подлежащих массивов
4. Отвратительный мониторинг (в официальных курсах написано следующее: используйте Excel для парсинга csv файлов, если хотите посмотреть исторические данные по производительности)
Мы тоже мигрировали большой объем данных (сотни ТБ), но использовали для этого LVM, а не VPLEX. Данный подход хорош тем, что в будущем, при помощи LVM, перепрыгнуть на новый СХД будет на много проще без использования костылей ввиде VPLEX и RP.
VPLEX это решение одной фичи — active-active на два ЦОДа, не более.
Давить ни на кого не собираюсь, я делюсь своим опытом и привожу опыт группы, чтобы показать, что это не просто моё IMHO, а большая работа проделанная большой группой специалистов совместно со специалистами от самих производителей, поэтому тут не пройдут отмазки, что заказчик сделал что-то не так. Периодически, раз в несколько лет, проводится «батл» среди вендоров на право входа в стандарт. На этом батле решения гоняются во всех возможных режимах, что можно только придумать. Прошлый батл, например, длился почти год…
Так вот, если коротко, то если для решения нужна репликация, то для этого решения возьмут либо VPLEX + VNX, VMAX + SRDF или VPLEX + XtremIO, либо другой вендор, но не VNX + MirrorView. За рубежом EMC прекрасно знают о своих недостатках и их там не единожды в них тыкали моськой и они это признавали. Только в России этот шлак толкают на право и налево подо всё, что только можно. Но, к сожалению, трансформировать убогую архитектуру VNX быстро просто не возможно, как и прикрутить какие-то техологичные фичи. Этому ещё мешает дичайшая разнородность решений их корявейшая интеграция друг с другом (например, VPLEX до сих пор хреново понимается PowerPath'ом и не умеет общаться с массивами расположенными под ним… уже сколько лет)
Про NFS — боже упаси вас использовать NAS от EMC. Нет, конечно, не используем этот ужас. Есть же нормальные вендоры для NAS.
Так было бы из чего готовить. Не буду тут показывать пальцем на правильных вендоров, дабы не быть обвиненным в рекламе, где всё работает уже более 10 лет без нареканий (10 лет это только мой опыт, а так и того больше). Хочу так же отметить, что это не только мой опыт, а так же опыт всей группы в которой суммарно >500 СХД разного калибра… более того у нас так же стандартами «запрещено» использовать MirroView — если нужна репликация на EMC то SRDF или VPLEX. И для виртуализации никакого Fibre Chanel (SCSI) под датасторы — только NFS… все эти стандарты написаны «кровью» убитыми данными. Я думаю это долгий разговор и не в рамках комментариев. :)
Вот только вы не учитываете Storage Efficiency (компрессия, дедупликация) у тех самых «красивых и дорогих» СХД, и если посмотреть в этом разрезе, то не такие уж они и дорогие получаются, в особенности для VMWare. То что EMC для этого не подходит — тут я с вами согласен. У нас на уровне группы от америки до азии запрещено использовать в продуктиве на EMC как компрессию так и дедупликацию. Плюс я сам убедился в этом когда у нас 2 раза тестовый VNX прилег часов на 12 из-за использования дедупликации.
«На борту бесплатная (у других вендоров эта опция часто идёт за дополнительные деньги) дедупликация» — NetApp уже лет 10 дает это for free :)
«Луны располагаются только на одной RAID-группе» — Так уже даже EMC не делает.
«В результате команда из 4 контроллеров в HP 3PAR работает значительно лучше, чем 4 малосвязанных контроллера в большинстве mid-range СХД.» — если использовать 4 контроллера, то будет 8 путей, что может вызвать проблему когерентности кэша. Нужно почитать, что на эту тему пишет сам вендор в connectivity guide (например EMC не рекомендует такой конфиг для VPLEX).
«Response time 0.1 ms» — это для SSD очень мало, даже для «True Flash» это очень мало, даже с половиной выключенных ячеек памяти на «True Flash» можно добиться около 0.25ms, а 0.1ms — это какой-то кэш.
P.S. и пора уже перестать воспринимать массив через призму IOPS'ов т.к. в большой инфраструктуре массив так же должен хорошо интегрироваться с этой инфраструктурой, т.к. IOPS'ы должны быть управляемыми.
Yep! Особенно прикольно, то что в ViPR нельзя задавать политику именования создаваемых им объектов (Зоны, LUN'ы, и т.п.). В итоге, если потом захочешь разобраться в том, что ViPR наделал за тебя, то может и не получиться. Так что базу ViPR лучше не терять.
Так было заявлено со сцены на EMC Forum 2014, поправьте меня, если что-то изменилось.
Совершенно согласен с пользователем shapa. За многие годы работы с EMC вывел уникальную формулу подхода EMC — недосказанное враньем не считается. Яркий пример — VPlex, которым до сих пор не возможно управлять без ViPR, но почему-то EMC об этом начинает рассказывать только после того как втюхали VPlex.
Теперь по поводу «уникального» и «неповторимого» XtremIO:
1. Какова интеграция с инфраструктурой? Есть ли софт для создания консистентных снапшотов (Oracle, MS SQL и т.п.)? Можно ли мониторить XtremIO не только при помощи продуктов EMC? Есть ли API, PowerShell модули для управления и т.п.(а не убогий SMI-S)?
2. CLI работает на хосте управления или на самой железке? В ней есть табличные выводы и grep(или аналог)?
1. NFS поддерживается?
2. "… После этого создается аппаратный снапшот NetApp, из которого производится чтение данных.." Вопрос: читаеся полный логический набор данных из снапшота или только та физическая разница, что есть в снапшоте? (надеюсь вы меня поняли)
madorc, при всём уважении, а вы не думали о FlashPool, если у вас NVRAM не справляется?
FlexShare — всё же не QoS, для того чтобы у вас был QoS вам нужно на C-Mode переходить.
Далее, если вам нужно «Потеря данных Oracle в случае краха одной из сторон — 0 секунд» — это Metro Cluster «адназначна»
Если у вас сильно загружены диски, то может всё же КЭШ добавить? Кстати какой у вас Cache Hit?
По поводу проблем со SnapMirror в разные стороны… хм… проверю… как-нибудь.
P.S. занимаюсь уже 7-й год как EMC так и NetApp'ом и могу вам сказать что NetApp никогда не скрывал про необходимость свободного пространства — скажите мне фамилию того кто вам не сказал про это :)
Это ограничение SCSI протокола, а не СХД. Какие бы вы страйпы на СХД не делали они вам не помогут, если LUN будет одни (или их количество будет не достаточно для обеспечения потока ввода/вывода).
От модели СХД может зависеть только глубина очереди на Front End портах СХД, но не на LUN. На LUN (SCSI Target) размер очереди регулируется со стороны хоста и масимум зависит от модели HBA (максимум 128 для Emulex HBA и 256 для Qlogic HBA).
Если честно, то ничего :)
Чтобы использовать блочный сторадж нужен хороший LVM для распараллеливания запросов на множество LUN (Target) из-за ограничений SCSI протокола, а не стораджа как такового. Если коротко, то глубина очереди (Queue Depth, outstanding IO) на один LUN лимитирована (максимум 128 для Emulex HBA и 256 для Qlogic HBA). Этот параметр говорит о том сколько параллельных SCSI запросов может выполняться на одном LUN'е. С увеличением глубины очереди возрастает Response Time и по умолчанию этот параметр равен 32, в новых VMWare — 64 (). Так вот когда у вас куча виртуалок начинает драться за один таргет эта очередь начинает переполняться и все виртуалки хапают большой Response Time после которого не все приложения могут выжить.
Я ещё не встречал людей, которые учитывали этот важнейший параметр при проектировании виртуализации и не только. Я тут не просто так теоретизирую ибо со всем этим сталкивался.
У блочного доступа по FC есть только одно преимущество — честный multipath.
В статье нет технологий, которых нет у других.
Google:
EMC может и далеко до HUAWEI, вот только про NetApp вы конечно загнули. Как бы ни я ни весь мир с вам не согласны.
1. Это стоимость ViPR. И звучит это примерно так — мы тут спецом сделали дерьмовое управление и интеграцию, чтобы стрясти с вас ещё кучу бабла. А поверьте мне, когда у вас будет пару десятков массивов и петабайт, то стоимость ViPR вас крайне удивит…
2. Не буду заниматься рекламой, но есть прекрасный вендор СХД, который предоставляет такой софт бесплатно.
Уж лучше VPLEX, чем SVC :)
Вообще я рекомендую использовать VPLEX, только для тех приложений и сервисов, которым это реально надо, а не для всего и всех.
См. выше. ответил.
тоже упоси вас господь этим ужасом пользоваться. Я надеюсь в будущих версиях они с ним что-то сделают.
Просто делается зеркало для теукщих томов с новыми, а после того как синхронизация заканчивается — отрываем старые и все. Даунтайм был только для тех хостов, где LVM не стоял.
В том-то и дело, что без растянутых LUN'ов. К сожалению очень сложно воспроизвести данный случай поэтому мы пока просто перейдем на 4-Egine конфигурацию для изоляции мощных потребителей на своих директорах.
В результате взаимодействие с администраторами серверов очень сильно усложнилось. Так же нет специальных политик и оптимизации под VPLEX/
LVM от Symantec решает эти задачи.
1. До сих пор у VPLEX нет интеграции с VNX и PowerPath
2. При большом количестве объектов управление тупит очень сильно (решение не предназначено для больших окружений, хотя парни из lufthansa как-то живут, хотел бы посмотреть как)
3. При проблемах с производительностью на одном из подлежащих массивах страдают все клиенты со всех подлежащих массивов
4. Отвратительный мониторинг (в официальных курсах написано следующее: используйте Excel для парсинга csv файлов, если хотите посмотреть исторические данные по производительности)
Мы тоже мигрировали большой объем данных (сотни ТБ), но использовали для этого LVM, а не VPLEX. Данный подход хорош тем, что в будущем, при помощи LVM, перепрыгнуть на новый СХД будет на много проще без использования костылей ввиде VPLEX и RP.
VPLEX это решение одной фичи — active-active на два ЦОДа, не более.
Так вот, если коротко, то если для решения нужна репликация, то для этого решения возьмут либо VPLEX + VNX, VMAX + SRDF или VPLEX + XtremIO, либо другой вендор, но не VNX + MirrorView. За рубежом EMC прекрасно знают о своих недостатках и их там не единожды в них тыкали моськой и они это признавали. Только в России этот шлак толкают на право и налево подо всё, что только можно. Но, к сожалению, трансформировать убогую архитектуру VNX быстро просто не возможно, как и прикрутить какие-то техологичные фичи. Этому ещё мешает дичайшая разнородность решений их корявейшая интеграция друг с другом (например, VPLEX до сих пор хреново понимается PowerPath'ом и не умеет общаться с массивами расположенными под ним… уже сколько лет)
Про NFS — боже упаси вас использовать NAS от EMC. Нет, конечно, не используем этот ужас. Есть же нормальные вендоры для NAS.
«кровью» убитыми данными. Я думаю это долгий разговор и не в рамках комментариев. :)P.S. Приходите на EMC Forum 2015 30 октября :)
«Луны располагаются только на одной RAID-группе» — Так уже даже EMC не делает.
«В результате команда из 4 контроллеров в HP 3PAR работает значительно лучше, чем 4 малосвязанных контроллера в большинстве mid-range СХД.» — если использовать 4 контроллера, то будет 8 путей, что может вызвать проблему когерентности кэша. Нужно почитать, что на эту тему пишет сам вендор в connectivity guide (например EMC не рекомендует такой конфиг для VPLEX).
«Response time 0.1 ms» — это для SSD очень мало, даже для «True Flash» это очень мало, даже с половиной выключенных ячеек памяти на «True Flash» можно добиться около 0.25ms, а 0.1ms — это какой-то кэш.
P.S. и пора уже перестать воспринимать массив через призму IOPS'ов т.к. в большой инфраструктуре массив так же должен хорошо интегрироваться с этой инфраструктурой, т.к. IOPS'ы должны быть управляемыми.
P.P.S. реклама не удалась, КРОКу не зачет.
Так было заявлено со сцены на EMC Forum 2014, поправьте меня, если что-то изменилось.
Теперь по поводу «уникального» и «неповторимого» XtremIO:
1. Какова интеграция с инфраструктурой? Есть ли софт для создания консистентных снапшотов (Oracle, MS SQL и т.п.)? Можно ли мониторить XtremIO не только при помощи продуктов EMC? Есть ли API, PowerShell модули для управления и т.п.(а не убогий SMI-S)?
2. CLI работает на хосте управления или на самой железке? В ней есть табличные выводы и grep(или аналог)?
2. "… После этого создается аппаратный снапшот NetApp, из которого производится чтение данных.." Вопрос: читаеся полный логический набор данных из снапшота или только та физическая разница, что есть в снапшоте? (надеюсь вы меня поняли)
FlexShare — всё же не QoS, для того чтобы у вас был QoS вам нужно на C-Mode переходить.
Далее, если вам нужно «Потеря данных Oracle в случае краха одной из сторон — 0 секунд» — это Metro Cluster «адназначна»
Если у вас сильно загружены диски, то может всё же КЭШ добавить? Кстати какой у вас Cache Hit?
По поводу проблем со SnapMirror в разные стороны… хм… проверю… как-нибудь.
P.S. занимаюсь уже 7-й год как EMC так и NetApp'ом и могу вам сказать что NetApp никогда не скрывал про необходимость свободного пространства — скажите мне фамилию того кто вам не сказал про это :)
Плюсы «вайдстрайпинга» конечно никто не отменял и я об этом написал, но что я хочу донести до народа — на VMWare его нет — blogs.vmware.com/vsphere/2012/02/vmfs-extents-are-they-bad-or-simply-misunderstood.html
Чтобы использовать блочный сторадж нужен хороший LVM для распараллеливания запросов на множество LUN (Target) из-за ограничений SCSI протокола, а не стораджа как такового. Если коротко, то глубина очереди (Queue Depth, outstanding IO) на один LUN лимитирована (максимум 128 для Emulex HBA и 256 для Qlogic HBA). Этот параметр говорит о том сколько параллельных SCSI запросов может выполняться на одном LUN'е. С увеличением глубины очереди возрастает Response Time и по умолчанию этот параметр равен 32, в новых VMWare — 64 (). Так вот когда у вас куча виртуалок начинает драться за один таргет эта очередь начинает переполняться и все виртуалки хапают большой Response Time после которого не все приложения могут выжить.
Я ещё не встречал людей, которые учитывали этот важнейший параметр при проектировании виртуализации и не только. Я тут не просто так теоретизирую ибо со всем этим сталкивался.
У блочного доступа по FC есть только одно преимущество — честный multipath.