Комментарии 19
Закрытый исходный текст? Это означает, что когда оно делает не то, что от него ожидают, админ даже парочки print'ов вставить не сможет, чтобы посмотреть, куда оно там не туда смотрит и не о том думает.
Это плохо. Серверный софт должен быть хотя бы читаем персоналом, а ещё лучше, редактируемым.
Если единственной опцией при неожиданном поведении (которое может быть не багой, а, например, опечаткой в конфиге) является эскалация кейса в саппорт, то это очень, очень медленно и очень, очень плохо. Не говоря уже про то, что inhouse компетенции при этом никакой не образуется.
Это плохо. Серверный софт должен быть хотя бы читаем персоналом, а ещё лучше, редактируемым.
Если единственной опцией при неожиданном поведении (которое может быть не багой, а, например, опечаткой в конфиге) является эскалация кейса в саппорт, то это очень, очень медленно и очень, очень плохо. Не говоря уже про то, что inhouse компетенции при этом никакой не образуется.
Не говоря уже про то, что inhouse компетенции при этом никакой не образуется.
А откуда ей взяться с открытым софтом, если учесть что 99% админстраторов СХД и виртуализации не имеют достаточной квалификации для правки кода?
Мы говорим не про правку кода систем виртуализации или СХД (я вполне представляю себе что там — потому что я, например, знаю несколько мест в Xen'е, которые я не могу разобрать даже со словарём, хотя, казалось бы, чистый Си).
Мы говорим про систему принятия решений, которая должна быть охватываема и понятна. Условный пример — 1С. Довольно большое число сисадминов, кто имеет несчастие администрировать её, вполне могут залазить в код конфигурации при необходимости даже править. Вот примерно такой уровень и ожидается.
Потому что бизнес-логика, она такая. Одному всё ок, а у другого абстракции с реальностью несрастаются в неожиданных местах.
Чем выше по уровню стека программа, тем более она должна быть доступна для изучения обслуживающим персоналом.
Мы говорим про систему принятия решений, которая должна быть охватываема и понятна. Условный пример — 1С. Довольно большое число сисадминов, кто имеет несчастие администрировать её, вполне могут залазить в код конфигурации при необходимости даже править. Вот примерно такой уровень и ожидается.
Потому что бизнес-логика, она такая. Одному всё ок, а у другого абстракции с реальностью несрастаются в неожиданных местах.
Чем выше по уровню стека программа, тем более она должна быть доступна для изучения обслуживающим персоналом.
Это очень хорошее замечание и очень хороший повод для холивара. Попытаюсь остановить его во избежании. Суть в том что Controller — это не конструктор для оркестрации а средство для решения определенного рода задач которые не решаются большим количеством разных способов, потому что технологии с которыми оно работает являются жестко стандартизированными, другими словами нарезать лун на массиве EMC VNX или IBM DS можно грубо говоря только определенной командой, что исключает ошибку, также как и создать зону на SAN коммутаторе можно только одним способом. Другими словами EMC гарантирует решение определенного рода задач определенным документированным набором способов и не более того.
А выбрать на каком массиве нарезать lun'ы можно по единственному алгоритму? Если я правильно понял, что этот софт делает — он автоматизирует provision в соответствии с политикой. Вот решения в области этой политики, они — единственные и непогрешимые?
Идея такая — вы собираете все массивы в некую виртуальную сущность (по сути на практике только группа которая существует внутри ViPR, то есть траффик он через себя никак не гоняет, только управляет), в которую объединены массивы целиком либо кусками (определенные порты и пулы дисков), и вот внутри этой группы система старается распределить утилизацию емкости максимально равномерно между физическими сущностями
Таким образом, есть некий алгоритм «равномерного распределения». Который может учитывать количество lun'ов, их размер, ещё какие-то особенности, возможно, резервирования и т.д. И всё это может чуть-чуть вести себя не так, как ожидает клиент. И клиент не может понять, почему было принято то или иное решение.
Как «продукт» оно вполне работает на старинных монстров энтрепрайза, но попадает в одну категорию с мейнфреймами. Более эффективные IT-отделы стараются обладать достаточной компетенцией для того, чтобы получать ответ «что не так» или «что нужно поправить» без привлечения всей цепочки из уровней поддержки (а первым в этой цепочке становится персонал заказчика, который без понимания «нутра» не может адекватно сформулировать проблему).
Как «продукт» оно вполне работает на старинных монстров энтрепрайза, но попадает в одну категорию с мейнфреймами. Более эффективные IT-отделы стараются обладать достаточной компетенцией для того, чтобы получать ответ «что не так» или «что нужно поправить» без привлечения всей цепочки из уровней поддержки (а первым в этой цепочке становится персонал заказчика, который без понимания «нутра» не может адекватно сформулировать проблему).
>Таким образом, есть некий алгоритм «равномерного распределения». Который может учитывать количество lun'ов, их размер, ещё какие-то особенности, возможно, резервирования и т.д. И всё это может чуть-чуть вести себя не так, как ожидает клиент. И клиент не может понять, почему было принято то или иное решение.
клиент всегда может понять почему было принято то или иное решение, потому что компания EMC всегда с радостью может это объяснять клиенту
>Более эффективные IT-отделы стараются обладать достаточной компетенцией для того, чтобы получать ответ «что не так» или «что нужно поправить» без привлечения всей цепочки из уровней поддержки (а первым в этой цепочке становится персонал заказчика, который без понимания «нутра» не может адекватно сформулировать проблему)
ИТ отделы делятся на 2 типа — тех кто реализует все самостоятельно из простых элементов и тех кто покупает сложные элементы у компаний на них специализирующихся, оба варианта вообщем-то жизнеспособны и вопрос их эффективности не так однозначен
клиент всегда может понять почему было принято то или иное решение, потому что компания EMC всегда с радостью может это объяснять клиенту
>Более эффективные IT-отделы стараются обладать достаточной компетенцией для того, чтобы получать ответ «что не так» или «что нужно поправить» без привлечения всей цепочки из уровней поддержки (а первым в этой цепочке становится персонал заказчика, который без понимания «нутра» не может адекватно сформулировать проблему)
ИТ отделы делятся на 2 типа — тех кто реализует все самостоятельно из простых элементов и тех кто покупает сложные элементы у компаний на них специализирующихся, оба варианта вообщем-то жизнеспособны и вопрос их эффективности не так однозначен
Компания EMC никогда не делает ошибок, её видение решения проблемы никогда не отличается от видения решения проблемы заказчиком, а технические требования заказчика никогда не противоречивы. Я понял, идеальный мир.
Насчёт «двух типов» я совершенно согласен. Но «оба варианта жизнеспособны» только в условиях сервисно-придаточного отношения к ИТ. Когда это «отдел ИТ», в остальном не имеющий отношения к жизни клиентов.
Уже лет 5-7 идёт суровая революция devops'а, который, помимо срачика dev vs ops, подразумевает глубокую вовлечённость всех сотрудников в происходящие процессы, готовность изучать и адаптировать технологии по месту (да, пошёл в код да поправил), плюс полагающиеся к этому технологии повышения надёжности.
Да, это разные миры — один «сертифицированный спецалист, который может написать саппорту, который с радостью всё объяснит» (или нет — это уж как повезёт). Второй — когда компания владеет компетенцией в эксплуатируемых продуктах, отдавая на аутсос только common carrier услуги, тривиально понятные и оптимизируемые только по цена/качество, причём что такое «качество» может объяснить любой стажёр в измеряемых объективных показателях.
Первый мир — это мир махрового энтерпрайза, который too big to change, и который до сих пор использует мейнфреймы.
Все новые бизнесы, класса facebook, google, apple — все они держат компетенцию у себя, а не покупают критические для бизнеса решения на стороне.
Насчёт «двух типов» я совершенно согласен. Но «оба варианта жизнеспособны» только в условиях сервисно-придаточного отношения к ИТ. Когда это «отдел ИТ», в остальном не имеющий отношения к жизни клиентов.
Уже лет 5-7 идёт суровая революция devops'а, который, помимо срачика dev vs ops, подразумевает глубокую вовлечённость всех сотрудников в происходящие процессы, готовность изучать и адаптировать технологии по месту (да, пошёл в код да поправил), плюс полагающиеся к этому технологии повышения надёжности.
Да, это разные миры — один «сертифицированный спецалист, который может написать саппорту, который с радостью всё объяснит» (или нет — это уж как повезёт). Второй — когда компания владеет компетенцией в эксплуатируемых продуктах, отдавая на аутсос только common carrier услуги, тривиально понятные и оптимизируемые только по цена/качество, причём что такое «качество» может объяснить любой стажёр в измеряемых объективных показателях.
Первый мир — это мир махрового энтерпрайза, который too big to change, и который до сих пор использует мейнфреймы.
Все новые бизнесы, класса facebook, google, apple — все они держат компетенцию у себя, а не покупают критические для бизнеса решения на стороне.
Вы намеренно рассматриваете только две крайности mainframe vs google? Вы правильно написали все новые бизнесы.
А что делать старым, уже успешным? Когда хочется, ломая старое ИТ, не сломать, а улучшить бизнес? Вы можете привести хотя бы один пример, когда какая-либо крупная компания успешно совершила такой переход за один шаг?
Мне кажется, если рассматривать реального заказчика (даже очень мотивированного на изменения), это процесс итерационный. Да, нас всех рано или поздно ждет прекрасное далеко типа «facebook/google/apple». Но на первых шагах на инфраструктурном уровне приходится работать с тем, что есть.
Скажите, Вы считаете разумным, что в модели devops, толковые ребята, которые хорошо умеют «dev», тратят свое время на изучение логики работы СХД EMC, NetApp, HDS и пр., вместо того, чтобы заниматься совершенствованием логики бизнес-приложения? В прекрасном facebook/google/apple будущем для них взаимоотношения с хранилищем будут выражаться простыми понятиями типа 10ГБ емкости типа «быстрый» в расположении «площадка 1», и этого будет достаточно. Штука под названием ViPR Controller позволяет им общаться с инфраструктурой на этом языке уже сейчас.
А что делать старым, уже успешным? Когда хочется, ломая старое ИТ, не сломать, а улучшить бизнес? Вы можете привести хотя бы один пример, когда какая-либо крупная компания успешно совершила такой переход за один шаг?
Мне кажется, если рассматривать реального заказчика (даже очень мотивированного на изменения), это процесс итерационный. Да, нас всех рано или поздно ждет прекрасное далеко типа «facebook/google/apple». Но на первых шагах на инфраструктурном уровне приходится работать с тем, что есть.
Скажите, Вы считаете разумным, что в модели devops, толковые ребята, которые хорошо умеют «dev», тратят свое время на изучение логики работы СХД EMC, NetApp, HDS и пр., вместо того, чтобы заниматься совершенствованием логики бизнес-приложения? В прекрасном facebook/google/apple будущем для них взаимоотношения с хранилищем будут выражаться простыми понятиями типа 10ГБ емкости типа «быстрый» в расположении «площадка 1», и этого будет достаточно. Штука под названием ViPR Controller позволяет им общаться с инфраструктурой на этом языке уже сейчас.
Вы совершенно правы. Старые бизнесы, которые неповоротливы и громоздки, но всё ещё полны успеха, начинают ощущать, как их подъедают с неожиданных сторон. И они хотят реформироваться, пуская ИТ всё глубже «в себя», а на самом деле, расформировывая ИТ отделы и становясь «ИТ компанией».
И, разумеется, это процесс итеративный. И начало итераций идёт с постепенного переноса компетенций in house. А для этого исходники, формализация всех процессов разработки (CI, тесты, формализмы code review), и ещё раз перенос компетенции.
И, разумеется, это процесс итеративный. И начало итераций идёт с постепенного переноса компетенций in house. А для этого исходники, формализация всех процессов разработки (CI, тесты, формализмы code review), и ещё раз перенос компетенции.
Вы говорите о том, что выбор системы может не соответствовать тому, что выбрал бы сам пользователь.
Идея в том, что ViPR Controller создан для избавления пользователя от необходимости выбора.
В нем есть две основные логические сущности:
* виртуальный массив — объединяет пулы реальных физических массивов, их порты и сети
* виртуальный пул — шаблон, согласно которому происходит выбор откуда и как будут выдаваться ресурсы
Ситуация. У заказчика есть 5 массивов: пара EMC VNX, один EMC VMAX, один IBM XIV, один HDS HUS-VM. На второй площадке похожий зоопарк.
Есть виртуальный пул «блочный том». Если пользователь запросит ёмкость из этого виртуального пула, будет создан том на каком-то из этих пяти массивов, как-то будет сделан зонинг, и хост увидит его.
Вся сила ViPR в кастомизируемости этих виртуальных пулов (=шаблонов). За счет нее мы уходим от «полной непредсказуемости» выбора. Иногда эта мера вынужденная. Например, при создании пула «блочный том с репликацией на вторую площадку» необходимо будет выбрать конкретную технологию репликации. Соответственно, последующий выбор будет ограничен массивами, ее поддерживающими. А в отдельных случаях — конкретной парой массивов, между которыми репликация уже настроена.
Другой вариант использования кастомизации. По каким-то причинам пользователь считает, что лучше знает какие ресурсы выбирать (например, для явной изоляции нагрузок). Можно создать виртуальный пул (=шаблон) «специальная емкость для специальных задач», где будет явно указано в каком пуле какого массива нарезать емкость, через какие порты массива ее отдавать, НЕ нарезать зоны в SAN, потому что это будет сделано потом особым образом вручную и тп. То есть совершенно однозначное указание по выделению ресурсов, при этом:
1. Без какого-либо изучения управлялок массивов (нам не важно, что это было VNX, VMAX, XIV или HUS-VM)
2. Без какого-либо копания в исходном коде
Надеюсь, изучение исходников в Вашей парадигме не является самоцелью?
Если да, тогда будет проще написать подобный продукт своими силами.
Миру известны как успешные, так и неуспешные примеры таких попыток. Есть даже примеры, когда подобные начинания выходили за рамки компании и становились самостоятельными коммерческими продуктами. Правда почему-то распространяются они с закрытым исходным кодом ;)
Идея в том, что ViPR Controller создан для избавления пользователя от необходимости выбора.
В нем есть две основные логические сущности:
* виртуальный массив — объединяет пулы реальных физических массивов, их порты и сети
* виртуальный пул — шаблон, согласно которому происходит выбор откуда и как будут выдаваться ресурсы
Ситуация. У заказчика есть 5 массивов: пара EMC VNX, один EMC VMAX, один IBM XIV, один HDS HUS-VM. На второй площадке похожий зоопарк.
Есть виртуальный пул «блочный том». Если пользователь запросит ёмкость из этого виртуального пула, будет создан том на каком-то из этих пяти массивов, как-то будет сделан зонинг, и хост увидит его.
Вся сила ViPR в кастомизируемости этих виртуальных пулов (=шаблонов). За счет нее мы уходим от «полной непредсказуемости» выбора. Иногда эта мера вынужденная. Например, при создании пула «блочный том с репликацией на вторую площадку» необходимо будет выбрать конкретную технологию репликации. Соответственно, последующий выбор будет ограничен массивами, ее поддерживающими. А в отдельных случаях — конкретной парой массивов, между которыми репликация уже настроена.
Другой вариант использования кастомизации. По каким-то причинам пользователь считает, что лучше знает какие ресурсы выбирать (например, для явной изоляции нагрузок). Можно создать виртуальный пул (=шаблон) «специальная емкость для специальных задач», где будет явно указано в каком пуле какого массива нарезать емкость, через какие порты массива ее отдавать, НЕ нарезать зоны в SAN, потому что это будет сделано потом особым образом вручную и тп. То есть совершенно однозначное указание по выделению ресурсов, при этом:
1. Без какого-либо изучения управлялок массивов (нам не важно, что это было VNX, VMAX, XIV или HUS-VM)
2. Без какого-либо копания в исходном коде
Надеюсь, изучение исходников в Вашей парадигме не является самоцелью?
Если да, тогда будет проще написать подобный продукт своими силами.
Миру известны как успешные, так и неуспешные примеры таких попыток. Есть даже примеры, когда подобные начинания выходили за рамки компании и становились самостоятельными коммерческими продуктами. Правда почему-то распространяются они с закрытым исходным кодом ;)
EMC вас услышала!
Open source проект, основанный на ViPR Controller называется CoprHD (читается copperhead). Исходники будут доступны в июне.
Open source проект, основанный на ViPR Controller называется CoprHD (читается copperhead). Исходники будут доступны в июне.
Yep! Особенно прикольно, то что в ViPR нельзя задавать политику именования создаваемых им объектов (Зоны, LUN'ы, и т.п.). В итоге, если потом захочешь разобраться в том, что ViPR наделал за тебя, то может и не получиться. Так что базу ViPR лучше не терять.
Так было заявлено со сцены на EMC Forum 2014, поправьте меня, если что-то изменилось.
Так было заявлено со сцены на EMC Forum 2014, поправьте меня, если что-то изменилось.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация инфраструктуры хранения данных при помощи ViPR Controller: модель IT as a Service в действии