Вы говорите о том, что выбор системы может не соответствовать тому, что выбрал бы сам пользователь.
Идея в том, что ViPR Controller создан для избавления пользователя от необходимости выбора.
В нем есть две основные логические сущности:
* виртуальный массив — объединяет пулы реальных физических массивов, их порты и сети
* виртуальный пул — шаблон, согласно которому происходит выбор откуда и как будут выдаваться ресурсы
Ситуация. У заказчика есть 5 массивов: пара EMC VNX, один EMC VMAX, один IBM XIV, один HDS HUS-VM. На второй площадке похожий зоопарк.
Есть виртуальный пул «блочный том». Если пользователь запросит ёмкость из этого виртуального пула, будет создан том на каком-то из этих пяти массивов, как-то будет сделан зонинг, и хост увидит его.
Вся сила ViPR в кастомизируемости этих виртуальных пулов (=шаблонов). За счет нее мы уходим от «полной непредсказуемости» выбора. Иногда эта мера вынужденная. Например, при создании пула «блочный том с репликацией на вторую площадку» необходимо будет выбрать конкретную технологию репликации. Соответственно, последующий выбор будет ограничен массивами, ее поддерживающими. А в отдельных случаях — конкретной парой массивов, между которыми репликация уже настроена.
Другой вариант использования кастомизации. По каким-то причинам пользователь считает, что лучше знает какие ресурсы выбирать (например, для явной изоляции нагрузок). Можно создать виртуальный пул (=шаблон) «специальная емкость для специальных задач», где будет явно указано в каком пуле какого массива нарезать емкость, через какие порты массива ее отдавать, НЕ нарезать зоны в SAN, потому что это будет сделано потом особым образом вручную и тп. То есть совершенно однозначное указание по выделению ресурсов, при этом:
1. Без какого-либо изучения управлялок массивов (нам не важно, что это было VNX, VMAX, XIV или HUS-VM)
2. Без какого-либо копания в исходном коде
Надеюсь, изучение исходников в Вашей парадигме не является самоцелью?
Если да, тогда будет проще написать подобный продукт своими силами.
Миру известны как успешные, так и неуспешные примеры таких попыток. Есть даже примеры, когда подобные начинания выходили за рамки компании и становились самостоятельными коммерческими продуктами. Правда почему-то распространяются они с закрытым исходным кодом ;)
Вы намеренно рассматриваете только две крайности mainframe vs google? Вы правильно написали все новые бизнесы.
А что делать старым, уже успешным? Когда хочется, ломая старое ИТ, не сломать, а улучшить бизнес? Вы можете привести хотя бы один пример, когда какая-либо крупная компания успешно совершила такой переход за один шаг?
Мне кажется, если рассматривать реального заказчика(даже очень мотивированного на изменения), это процесс итерационный. Да, нас всех рано или поздно ждет прекрасное далеко типа «facebook/google/apple». Но на первых шагах на инфраструктурном уровне приходится работать с тем, что есть.
Скажите, Вы считаете разумным, что в модели devops, толковые ребята, которые хорошо умеют «dev», тратят свое время на изучение логики работы СХД EMC, NetApp, HDS и пр., вместо того, чтобы заниматься совершенствованием логики бизнес-приложения? В прекрасном facebook/google/apple будущем для них взаимоотношения с хранилищем будут выражаться простыми понятиями типа 10ГБ емкости типа «быстрый» в расположении «площадка 1», и этого будет достаточно. Штука под названием ViPR Controller позволяет им общаться с инфраструктурой на этом языке уже сейчас.
Сегодня вышла новая версия EMC Storage Integrator (3.6). Кроме прочего, добавлена поддержка работы с XtremIO через GUI или PowerShell.
Утилита по-прежнему доступна для бесплатной загрузки с нашего сайта.
Мы гарантированно получим коллизию, если мы уже записали 2^160 блоков (кол-во всех возможных вариантов дайджестов в SHA-1) по 4КБ и хотим записать еще один.
2^160 это 1.4615016e+48 блоков данных по 4КБ, то есть на массиве у нас хранится 5.8460065e+48 КБ данных. Таким образом, поместив на массив 5.2e+33 экзабайт данных мы гарантированно получим коллизию из-за того, что у нас кончились дайджесты.
Теперь перейдем к реальности. Например, система XtremIO из восьми XBrick 10ТБ будет иметь полезный объем 8.33*8 ~ 67 ТБ. Даже с учетом дедупликации 1:10 это будет всего лишь 670 терабайт. Ежедневная полная перезапись всего этого объема данных в течение 5 лет дает суммарно порядка 1.1 экзабайта данных.
Цифры несколько несопоставимые.
Да, вероятность коллизии имеется. Однако на этих объемах данных эта вероятность настолько мала, что при аккуратной оценке всех рисков, риск потери данных из-за коллизии будет стоять далеко не на первом месте.
Если нужен только мониторинг, старый добрый SNMP поможет — он, естественно, поддерживается. MIB можно бесплатно скачать с нашего сайта технической поддержки.
Для интеграции продуктов EMC в среды Microsoft, в том числе и для предоставления интерфейса PowerShell, у нас есть бесплатный плагин — EMC Storage Integrator. В текущей версии (3.5) ESI не поддерживает XtremIO. Следите за анонсами.
Есть набор модулей, созданный энтузиастами. Он в своей основе как раз использует вызовы REST API.
По поводу VPLEX. Скажите, Вы используете этот продукт в своей компании? У Вас есть какие-то конкретные вопросы, с которыми мы можем Вам помочь? Честно говоря, ни от кого из пользователей VPLEX, с кем я общался, не доводилось слышать подобных отзывов.
Может лучше вместо регистрации сделать авторизацию по OpenID/Facebook/Вконтакте?!
Думаю, у каждого уже есть несколько десятков логинов-паролей для разных сайтов и +1 к этому списку не очень хочется получать :)
Хотя, честно говоря, мне кажется главная фишка Вашего сервиса в простоте. Не надо от неё избавляться.
Тогда присоединяюсь к всенародному требованию посмотреть на фотки устройства в действии.
Товарищ гугл по запросу «Xybernaut Xyberview» дает ссылки либо на миниатюрные непонятные картинки либо угадайте на чьи посты ;)
Достаточно близко к этому подошли отношения Coca-Cola и Pepsi. По крайней мере в анкете, которую заполняют желающие работать в СС есть несколько пунктов из серии «работали ли когда-либо вы или ваши родственники в pepsi».
Счет #3730
Спасибо!
Идея в том, что ViPR Controller создан для избавления пользователя от необходимости выбора.
В нем есть две основные логические сущности:
* виртуальный массив — объединяет пулы реальных физических массивов, их порты и сети
* виртуальный пул — шаблон, согласно которому происходит выбор откуда и как будут выдаваться ресурсы
Ситуация. У заказчика есть 5 массивов: пара EMC VNX, один EMC VMAX, один IBM XIV, один HDS HUS-VM. На второй площадке похожий зоопарк.
Есть виртуальный пул «блочный том». Если пользователь запросит ёмкость из этого виртуального пула, будет создан том на каком-то из этих пяти массивов, как-то будет сделан зонинг, и хост увидит его.
Вся сила ViPR в кастомизируемости этих виртуальных пулов (=шаблонов). За счет нее мы уходим от «полной непредсказуемости» выбора. Иногда эта мера вынужденная. Например, при создании пула «блочный том с репликацией на вторую площадку» необходимо будет выбрать конкретную технологию репликации. Соответственно, последующий выбор будет ограничен массивами, ее поддерживающими. А в отдельных случаях — конкретной парой массивов, между которыми репликация уже настроена.
Другой вариант использования кастомизации. По каким-то причинам пользователь считает, что лучше знает какие ресурсы выбирать (например, для явной изоляции нагрузок). Можно создать виртуальный пул (=шаблон) «специальная емкость для специальных задач», где будет явно указано в каком пуле какого массива нарезать емкость, через какие порты массива ее отдавать, НЕ нарезать зоны в SAN, потому что это будет сделано потом особым образом вручную и тп. То есть совершенно однозначное указание по выделению ресурсов, при этом:
1. Без какого-либо изучения управлялок массивов (нам не важно, что это было VNX, VMAX, XIV или HUS-VM)
2. Без какого-либо копания в исходном коде
Надеюсь, изучение исходников в Вашей парадигме не является самоцелью?
Если да, тогда будет проще написать подобный продукт своими силами.
Миру известны как успешные, так и неуспешные примеры таких попыток. Есть даже примеры, когда подобные начинания выходили за рамки компании и становились самостоятельными коммерческими продуктами. Правда почему-то распространяются они с закрытым исходным кодом ;)
А что делать старым, уже успешным? Когда хочется, ломая старое ИТ, не сломать, а улучшить бизнес? Вы можете привести хотя бы один пример, когда какая-либо крупная компания успешно совершила такой переход за один шаг?
Мне кажется, если рассматривать реального заказчика (даже очень мотивированного на изменения), это процесс итерационный. Да, нас всех рано или поздно ждет прекрасное далеко типа «facebook/google/apple». Но на первых шагах на инфраструктурном уровне приходится работать с тем, что есть.
Скажите, Вы считаете разумным, что в модели devops, толковые ребята, которые хорошо умеют «dev», тратят свое время на изучение логики работы СХД EMC, NetApp, HDS и пр., вместо того, чтобы заниматься совершенствованием логики бизнес-приложения? В прекрасном facebook/google/apple будущем для них взаимоотношения с хранилищем будут выражаться простыми понятиями типа 10ГБ емкости типа «быстрый» в расположении «площадка 1», и этого будет достаточно. Штука под названием ViPR Controller позволяет им общаться с инфраструктурой на этом языке уже сейчас.
Утилита по-прежнему доступна для бесплатной загрузки с нашего сайта.
Этот простой командлет просто поражает :)
Мы гарантированно получим коллизию, если мы уже записали 2^160 блоков (кол-во всех возможных вариантов дайджестов в SHA-1) по 4КБ и хотим записать еще один.
2^160 это 1.4615016e+48 блоков данных по 4КБ, то есть на массиве у нас хранится 5.8460065e+48 КБ данных. Таким образом, поместив на массив 5.2e+33 экзабайт данных мы гарантированно получим коллизию из-за того, что у нас кончились дайджесты.
Теперь перейдем к реальности. Например, система XtremIO из восьми XBrick 10ТБ будет иметь полезный объем 8.33*8 ~ 67 ТБ. Даже с учетом дедупликации 1:10 это будет всего лишь 670 терабайт. Ежедневная полная перезапись всего этого объема данных в течение 5 лет дает суммарно порядка 1.1 экзабайта данных.
Цифры несколько несопоставимые.
Да, вероятность коллизии имеется. Однако на этих объемах данных эта вероятность настолько мала, что при аккуратной оценке всех рисков, риск потери данных из-за коллизии будет стоять далеко не на первом месте.
Для интеграции продуктов EMC в среды Microsoft, в том числе и для предоставления интерфейса PowerShell, у нас есть бесплатный плагин — EMC Storage Integrator. В текущей версии (3.5) ESI не поддерживает XtremIO. Следите за анонсами.
Есть набор модулей, созданный энтузиастами. Он в своей основе как раз использует вызовы REST API.
По поводу VPLEX. Скажите, Вы используете этот продукт в своей компании? У Вас есть какие-то конкретные вопросы, с которыми мы можем Вам помочь? Честно говоря, ни от кого из пользователей VPLEX, с кем я общался, не доводилось слышать подобных отзывов.
В России EPP не работает.
Думаю, у каждого уже есть несколько десятков логинов-паролей для разных сайтов и +1 к этому списку не очень хочется получать :)
Хотя, честно говоря, мне кажется главная фишка Вашего сервиса в простоте. Не надо от неё избавляться.
в корне неверное понимание принципов работы системы
Товарищ гугл по запросу «Xybernaut Xyberview» дает ссылки либо на миниатюрные непонятные картинки либо угадайте на чьи посты ;)