6 февраля 2015 в 16:06

Автоматизация инфраструктуры хранения данных при помощи ViPR Controller: модель IT as a Service в действии

image

Мы живём в мире, где развитие программно-определяемых решений (software defined), переход ИТ от управления техническими параметрами к уровню решения бизнес-задач и удаление лишних звеньев в организационных процессах – реальные тренды, активно меняющие ландшафт индустрии.

Представьте себе довольно обыденную ситуацию: существует компания (например, банк), в которой возникает необходимость срочной разработки некого приложения. Разработчик пишет заявки администраторам, те вручную заходят на массив и выделяют необходимое пространство. Знакомая схема? К сожалению, в случае с большими корпорациями она перестаёт работать: задач становится больше, оперативность их выполнения — критичней, а объёмы информации и вовсе увеличиваются на порядки. В этих условиях ждать, условно говоря, 2 недели, пока админы выделят необходимые мощности, неприемлемо. И, если разложить данные вручную по 10 массивам представляется возможным, то, когда массивов 100, вопрос автоматизации процесса встаёт ребром.

Именно эти проблемы решает ViPR Controller —простой и умный софт, который устанавливается в дополнение к СХД и автоматизирует управление ими. Как это происходит и зачем бизнесу такой подход – рассказываем в нашем посте.

Идея
Решение ViPR Controller в потоке данных выполняет роль своего рода железнодорожной стрелки (control plane), в то время как «рельсы» (data plane) остаются прежними – это массивы, коммутаторы и и серверы, уже имеющиеся в компании. Т.е. в самом потоке данных он не участвует, но управляет им. ViPR Controller подключается ко всем уровням системы (массивы, сеть, сервер), специалист задает ему логическую структуру виртуальных массивов (пример: массив №1 в Москве, массив №2 в Санкт-Петербурге), и затем указывает, из каких физических компонентов будет состоять каждый из них.
Следующий шаг – определить набор сервисов (сервис-ориентированная архитектура в действии). После того, как мы построили управляющую инфраструктуру и задали виртуальную структуру массивов, мы создаем каталог сервисов в зависимости от типов задач, которые ставятся в нашей компании.

В итоге этим каталогом могут пользоваться все сотрудники, которым нужно решить ту или иную задачу. Чтобы, например, разработать приложение, необходимо только запросить в каталоге определённый уровень сервиса (золотой/серебряный, защищённый/незащищенный и т.д.) с помощью self service-портала. Необходимые объемы памяти предоставляются оперативно, так что ждать реакции администраторов теперь не нужно.

Таким образом, от решения технических вопросов мы поднимаемся на уровень решения бизнес-задач силами ИТ, а кроме того – значительно сокращаем количество звеньев в организационной цепи и экономим драгоценное время.

Технология
У каждого производителя СХД существует определенный набор средств управления. Основная техническая «фишка» ViPR Controller в том, что он оснащен всеми библиотеками необходимыми для доступа к массивам различных производителей (EMC, Hitachi, IBM, HP и т.д.), более того из коробки присутствует замечательный инструмент – библиотека работы с Openstack Cinder, де-факто ставший одним из ключевых средств управления СХД в нынешнем мире и позволяющий работать с массивами многих производителей при помощи драйверов, разрабатываемых этими же производителями. Всё, что нужно сделать, – задать общую логическую структуру. ViPR Controller через родной для каждого массива софт (либо используя Cinder как прослойку) сделает всю «чёрную» работу – выделит тома на нужных массивах и «нарежет» их оптимальным для решения конкретной задачи способом.

Внутри построенных с помощью ViPR Controller виртуальных массивов могут быть различные пулы и типы памяти (быстрый flash, медленные диски – в зависимости от специфики задач). В получившейся иерархии мы можем впоследствии использовать инструменты анализа производительности. Более того про такое понятие как Storage Silos теперь можно забыть, так как система принудительно старается утилизировать все имеющиеся ресурсы равномерно в зависимости от уровня сервиса/виртуального массива/виртуального пула и т.д.

Кстати, к ViPR Controller можно подключать не только СХД – он также способен управлять серверами и использовать их для дополнительной ёмкости. Но это уже тема для отдельного поста.

Уникальность
Попытки создать систему, подобную ViPR Controller, уже предпринимались ИТ-вендорами, но по различным причинам эти проекты пока что не имели особого успеха. Корпорация EMC начала активно продвигать идею программно-определяемых СХД около года назад, и ViPR Controller – это на данный момент объективно уникальное решение на рынке, т.к. ни один его аналог не работает с разнородными СХД различных производителей.

Зачем это нужно
Во-первых, использование системы ViPR Controller колоссально ускоряет выполнение необходимых задач. То задание, на решение которого «дедовским» способом может уйти несколько дней или даже недель, с настроенным ViPR Controller решается за минуты. Как говорится, «почувствуйте разницу». Особенно актуально это для современных бизнес-задач, зачастую требующих мгновенного реагирования.

Во-вторых, ViPR Controller — отличное средство для защиты прозрачности ИТ-процессов в организации. В России на данный момент эта проблема стоит не так остро, а вот на Западе прозрачность ИТ становится одной из самых актуальных тем индустрии. Приведём пример: ИТ-ресурсы корпорации распределяются «по старинке» — силами ИТ-департамента. Перед разработчиками поставлена срочная бизнес-задача, они запрашивают у ИТ-службы необходимые ресурсы и получают ответ «в течение двух недель предоставим». Недолго думая, разработчики покупают необходимые мощности на Amazon собственными силами и за свои деньги – благо, это сравнительно недорого, а решить задачу мобильно в таких случаях гораздо важнее. В итоге люди, владеющие интеллектуальной собственностью корпорации, разворачивают её на сторонних ресурсах, подверженных частым атакам злоумышленников. C ViPR Controller необходимость «идти на Amazon» отпадает: гораздо легче и удобнее действовать через портал self-service, не рискуя безопасностью ценной корпоративной информации.

В-третьих, такой подход, естественно, экономит издержки компании за счет высвобождаемого времени ИТ-персонала. Чем больше мощностей, тем сложнее и дороже ими управлять, а ViPR Controller использует ресурсы с максимальной эффективностью.

В-четвёртых, в структуре ИТ-процессов появляется единый «зонтик», который накрывает собой разнородное «железо». Например, если в компании используются СХД разных производителей, каждый из них применяет собственную технологию для интеграции с другими элементами системы. Если понадобится развернуть, например, мониторинг, то его необходимо будет вручную адаптировать под технологии каждого из производителей СХД. ViPR Controller совместим с технологиями всех производителей СХД и выстраивает их в эффективную систему, позволяя через единую точку интеграции управлять мониторингом, соединять массивы с продуктами VMware, развернуть частное облако и т.д.

Вывод
Разумеется, в некоторых случаях то, что делает ViPR Controller, можно сделать более качественно силами ИТ-персонала, но также, начиная с какого-то объёма информации и количества задач, это просто перестаёт работать. Идеальные, но медленные и затратные способы решения задач сменяются хорошими, быстрыми и стабильными. Поэтому реальность такова, что за системами, построенными по прототипу ViPR Controller, будущее индустрии.

Кроме того, современные циклы разработки не терпят медлительности, присущей громоздкой иерархии многих ИТ-отделов. А люди все больше верят в быстрые и качественные решения бизнес-задач, доступные в рамках возможностей «третьей платформы».

Именно поэтому ИТ-революция не в наращивании терабайт, а в наиболее эффективном их использовании во благо бизнеса.

PS
И, наконец, «на сладкое»: решение ViPR Controller доступно для свободного скачивания в режиме некоммерческого использования (http://russia.emc.com/cloud/vipr/try.htm/), так что вы можете опробовать все его преимущества бесплатно и без временных ограничений, и убедиться, насколько это применимо к тем бизнес-задачам и проблемам, которые возникают или могут возникнуть в вашей работе.
Автор: @netgt
Dell EMC
рейтинг 103,29
Dell EMC. Пришло время трансформации

Комментарии (19)

  • 0
    Закрытый исходный текст? Это означает, что когда оно делает не то, что от него ожидают, админ даже парочки print'ов вставить не сможет, чтобы посмотреть, куда оно там не туда смотрит и не о том думает.

    Это плохо. Серверный софт должен быть хотя бы читаем персоналом, а ещё лучше, редактируемым.

    Если единственной опцией при неожиданном поведении (которое может быть не багой, а, например, опечаткой в конфиге) является эскалация кейса в саппорт, то это очень, очень медленно и очень, очень плохо. Не говоря уже про то, что inhouse компетенции при этом никакой не образуется.
    • 0
      Не говоря уже про то, что inhouse компетенции при этом никакой не образуется.

      А откуда ей взяться с открытым софтом, если учесть что 99% админстраторов СХД и виртуализации не имеют достаточной квалификации для правки кода?
      • 0
        Мы говорим не про правку кода систем виртуализации или СХД (я вполне представляю себе что там — потому что я, например, знаю несколько мест в Xen'е, которые я не могу разобрать даже со словарём, хотя, казалось бы, чистый Си).

        Мы говорим про систему принятия решений, которая должна быть охватываема и понятна. Условный пример — 1С. Довольно большое число сисадминов, кто имеет несчастие администрировать её, вполне могут залазить в код конфигурации при необходимости даже править. Вот примерно такой уровень и ожидается.

        Потому что бизнес-логика, она такая. Одному всё ок, а у другого абстракции с реальностью несрастаются в неожиданных местах.

        Чем выше по уровню стека программа, тем более она должна быть доступна для изучения обслуживающим персоналом.
        • 0
          Речь о готовых продуктах, модификация которых часто ведёт к снятию с поддержки — на одного знающего клиента найдётся 99 идиотов, которые не понимают что делают.
          И даже в 1С хорошей практикой считается использование немодифицированных конфигураций.
          • 0
            Отличное обоснование. 99% клиентов идиоты, так что сырцы будут закрыты.
            • 0
              Скорее, отсутствие исходников для коммерческого софта не является катастрофой.
              • 0
                А прекращение работы обсуждаемого продукта вообще является катастрофой? Если нет, то что бы с ним не происходило, катастрофы не будет.
    • +1
      Это очень хорошее замечание и очень хороший повод для холивара. Попытаюсь остановить его во избежании. Суть в том что Controller — это не конструктор для оркестрации а средство для решения определенного рода задач которые не решаются большим количеством разных способов, потому что технологии с которыми оно работает являются жестко стандартизированными, другими словами нарезать лун на массиве EMC VNX или IBM DS можно грубо говоря только определенной командой, что исключает ошибку, также как и создать зону на SAN коммутаторе можно только одним способом. Другими словами EMC гарантирует решение определенного рода задач определенным документированным набором способов и не более того.
      • 0
        А выбрать на каком массиве нарезать lun'ы можно по единственному алгоритму? Если я правильно понял, что этот софт делает — он автоматизирует provision в соответствии с политикой. Вот решения в области этой политики, они — единственные и непогрешимые?
        • 0
          Идея такая — вы собираете все массивы в некую виртуальную сущность (по сути на практике только группа которая существует внутри ViPR, то есть траффик он через себя никак не гоняет, только управляет), в которую объединены массивы целиком либо кусками (определенные порты и пулы дисков), и вот внутри этой группы система старается распределить утилизацию емкости максимально равномерно между физическими сущностями
          • 0
            Таким образом, есть некий алгоритм «равномерного распределения». Который может учитывать количество lun'ов, их размер, ещё какие-то особенности, возможно, резервирования и т.д. И всё это может чуть-чуть вести себя не так, как ожидает клиент. И клиент не может понять, почему было принято то или иное решение.

            Как «продукт» оно вполне работает на старинных монстров энтрепрайза, но попадает в одну категорию с мейнфреймами. Более эффективные IT-отделы стараются обладать достаточной компетенцией для того, чтобы получать ответ «что не так» или «что нужно поправить» без привлечения всей цепочки из уровней поддержки (а первым в этой цепочке становится персонал заказчика, который без понимания «нутра» не может адекватно сформулировать проблему).
            • +1
              >Таким образом, есть некий алгоритм «равномерного распределения». Который может учитывать количество lun'ов, их размер, ещё какие-то особенности, возможно, резервирования и т.д. И всё это может чуть-чуть вести себя не так, как ожидает клиент. И клиент не может понять, почему было принято то или иное решение.

              клиент всегда может понять почему было принято то или иное решение, потому что компания EMC всегда с радостью может это объяснять клиенту

              >Более эффективные IT-отделы стараются обладать достаточной компетенцией для того, чтобы получать ответ «что не так» или «что нужно поправить» без привлечения всей цепочки из уровней поддержки (а первым в этой цепочке становится персонал заказчика, который без понимания «нутра» не может адекватно сформулировать проблему)

              ИТ отделы делятся на 2 типа — тех кто реализует все самостоятельно из простых элементов и тех кто покупает сложные элементы у компаний на них специализирующихся, оба варианта вообщем-то жизнеспособны и вопрос их эффективности не так однозначен
              • –1
                Компания EMC никогда не делает ошибок, её видение решения проблемы никогда не отличается от видения решения проблемы заказчиком, а технические требования заказчика никогда не противоречивы. Я понял, идеальный мир.

                Насчёт «двух типов» я совершенно согласен. Но «оба варианта жизнеспособны» только в условиях сервисно-придаточного отношения к ИТ. Когда это «отдел ИТ», в остальном не имеющий отношения к жизни клиентов.

                Уже лет 5-7 идёт суровая революция devops'а, который, помимо срачика dev vs ops, подразумевает глубокую вовлечённость всех сотрудников в происходящие процессы, готовность изучать и адаптировать технологии по месту (да, пошёл в код да поправил), плюс полагающиеся к этому технологии повышения надёжности.

                Да, это разные миры — один «сертифицированный спецалист, который может написать саппорту, который с радостью всё объяснит» (или нет — это уж как повезёт). Второй — когда компания владеет компетенцией в эксплуатируемых продуктах, отдавая на аутсос только common carrier услуги, тривиально понятные и оптимизируемые только по цена/качество, причём что такое «качество» может объяснить любой стажёр в измеряемых объективных показателях.

                Первый мир — это мир махрового энтерпрайза, который too big to change, и который до сих пор использует мейнфреймы.

                Все новые бизнесы, класса facebook, google, apple — все они держат компетенцию у себя, а не покупают критические для бизнеса решения на стороне.
                • 0
                  Вы намеренно рассматриваете только две крайности mainframe vs google? Вы правильно написали все новые бизнесы.
                  А что делать старым, уже успешным? Когда хочется, ломая старое ИТ, не сломать, а улучшить бизнес? Вы можете привести хотя бы один пример, когда какая-либо крупная компания успешно совершила такой переход за один шаг?

                  Мне кажется, если рассматривать реального заказчика (даже очень мотивированного на изменения), это процесс итерационный. Да, нас всех рано или поздно ждет прекрасное далеко типа «facebook/google/apple». Но на первых шагах на инфраструктурном уровне приходится работать с тем, что есть.

                  Скажите, Вы считаете разумным, что в модели devops, толковые ребята, которые хорошо умеют «dev», тратят свое время на изучение логики работы СХД EMC, NetApp, HDS и пр., вместо того, чтобы заниматься совершенствованием логики бизнес-приложения? В прекрасном facebook/google/apple будущем для них взаимоотношения с хранилищем будут выражаться простыми понятиями типа 10ГБ емкости типа «быстрый» в расположении «площадка 1», и этого будет достаточно. Штука под названием ViPR Controller позволяет им общаться с инфраструктурой на этом языке уже сейчас.
                  • 0
                    Вы совершенно правы. Старые бизнесы, которые неповоротливы и громоздки, но всё ещё полны успеха, начинают ощущать, как их подъедают с неожиданных сторон. И они хотят реформироваться, пуская ИТ всё глубже «в себя», а на самом деле, расформировывая ИТ отделы и становясь «ИТ компанией».

                    И, разумеется, это процесс итеративный. И начало итераций идёт с постепенного переноса компетенций in house. А для этого исходники, формализация всех процессов разработки (CI, тесты, формализмы code review), и ещё раз перенос компетенции.
        • +1
          Вы говорите о том, что выбор системы может не соответствовать тому, что выбрал бы сам пользователь.

          Идея в том, что ViPR Controller создан для избавления пользователя от необходимости выбора.

          В нем есть две основные логические сущности:
          * виртуальный массив — объединяет пулы реальных физических массивов, их порты и сети
          * виртуальный пул — шаблон, согласно которому происходит выбор откуда и как будут выдаваться ресурсы

          Ситуация. У заказчика есть 5 массивов: пара EMC VNX, один EMC VMAX, один IBM XIV, один HDS HUS-VM. На второй площадке похожий зоопарк.
          Есть виртуальный пул «блочный том». Если пользователь запросит ёмкость из этого виртуального пула, будет создан том на каком-то из этих пяти массивов, как-то будет сделан зонинг, и хост увидит его.

          Вся сила ViPR в кастомизируемости этих виртуальных пулов (=шаблонов). За счет нее мы уходим от «полной непредсказуемости» выбора. Иногда эта мера вынужденная. Например, при создании пула «блочный том с репликацией на вторую площадку» необходимо будет выбрать конкретную технологию репликации. Соответственно, последующий выбор будет ограничен массивами, ее поддерживающими. А в отдельных случаях — конкретной парой массивов, между которыми репликация уже настроена.

          Другой вариант использования кастомизации. По каким-то причинам пользователь считает, что лучше знает какие ресурсы выбирать (например, для явной изоляции нагрузок). Можно создать виртуальный пул (=шаблон) «специальная емкость для специальных задач», где будет явно указано в каком пуле какого массива нарезать емкость, через какие порты массива ее отдавать, НЕ нарезать зоны в SAN, потому что это будет сделано потом особым образом вручную и тп. То есть совершенно однозначное указание по выделению ресурсов, при этом:
          1. Без какого-либо изучения управлялок массивов (нам не важно, что это было VNX, VMAX, XIV или HUS-VM)
          2. Без какого-либо копания в исходном коде

          Надеюсь, изучение исходников в Вашей парадигме не является самоцелью?
          Если да, тогда будет проще написать подобный продукт своими силами.
          Миру известны как успешные, так и неуспешные примеры таких попыток. Есть даже примеры, когда подобные начинания выходили за рамки компании и становились самостоятельными коммерческими продуктами. Правда почему-то распространяются они с закрытым исходным кодом ;)
    • 0
      EMC вас услышала!
      Open source проект, основанный на ViPR Controller называется CoprHD (читается copperhead). Исходники будут доступны в июне.
  • +1
    Yep! Особенно прикольно, то что в ViPR нельзя задавать политику именования создаваемых им объектов (Зоны, LUN'ы, и т.п.). В итоге, если потом захочешь разобраться в том, что ViPR наделал за тебя, то может и не получиться. Так что базу ViPR лучше не терять.

    Так было заявлено со сцены на EMC Forum 2014, поправьте меня, если что-то изменилось.
    • 0
      В феврале будет 2.2 где это починили :)

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное