Регистрация
Александр Жилин

куда плывут облака или стратегия развития инфраструктуры

28 октября 2014, 19:52 3743 8

Длительная работа в роли CIO с последующим переходом в вендора дает интересные результаты.

Ты по прежнему пытаешься найти ответы на вопросы развития ИТ, но уже имея под рукой весьма существенный ресурс вендора. В моем случае это ресурс Microsoft.

Вспоминая, как последние несколько лет мы активно упражнялись в рассказах про эффективность облаков и про облачный подход я задался вопросом, а как же собственно это облако получается на самом деле и что скрывает в своей дымке. А самое интересное-куда эти облака плывут и по дороге ли нам с нами?

В итоге, посидев пару вечеров над вордом, собрал воедино ряд фактов и тенденций, которые и предлагаю вашему вниманию.

Возможно некоторые мои мысли покажутся вам знакомыми, а некоторые спорными. На самом деле это призыв к дискуссии :)

Итак, спляшем "от печки"

Бизнес-пользователи используют информационные технологии в виде сервиса, обеспечивающего функцию эффективного управления информацией. Для пользователей важными факторами являются объем и качество предоставляемых ИТ сервисов, их удобство, надежность и безопасность. Тот факт, что за предоставляемым ИТ сервисом располагается целая цепочка технологических решений: компьютеров, сетей передачи данных, серверов и систем хранения информации, ERP и CRM систем не имеет для большинства пользователей никакого значения. Функции создания и сопровождения ИТ сервисов обеспечивает ИТ подразделение компании, в его задачи входит не только создание и обеспечение бесперебойной работы сервисов, но и применение максимально эффективных технологий для оптимизации стоимости владения всеми ИТ сервисами предприятия.

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

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

Описанные тренды приводят нас к двум главным выводам: ИТ сервисы стремительно централизуются, а пользовательские устройства становятся все более универсальными и быстро заменяемыми.  В итоге ИТ поэтапно приходит к централизованной модели.

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

Стратегия централизации подразумевает создание центров обработки данных (ЦОД) с консолидацией в них аппаратных мощностей с предоставлением пользователям сервиса по месту через сети передачи данных. Роль пользовательского устройства – обеспечить удобный доступ к информации.

Тут я полагаю для вас ничего нового нет. пойдем дальше.

Таким образом возникают две основные задачи:

  • Эффективное управление инфраструктурой, а точнее ИТ сервисами
  • Эффективная доставка и управление контентом на устройства, включая управление самим устройством.

Рассмотрим эти два вопроса в отдельности более подробно

Управление инфраструктурой и сервисами.

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

Условно можно выделить следующие уровни зрелости:

Традиционная инфраструктура.

Данный этап построения инфраструктуры не предполагает использование технологий виртуализации и автоматизированного управления. Ключевые особенности:

  • Приложения запускаются на физических серверах, для хранения данных используются либо дисковое пространство самих серверов, либо системы хранения данных (СХД), либо несколько систем хранения данных, объединенных с группами серверов высокоскоростными каналами связи;
  • Управление мощностью и доступностью выполняется в ручном режиме,   трудозатратно и малоэффективно;

  • Построение отказоустойчивых и катастрофоустойчивых сред является дорогостоящим и сложным процессом;

  • Низкий уровень использования (утилизации) аппаратных ресурсов, низкий уровень отдачи от вложенных средств;

  • Низкая степень управляемости;
  • Низкая гибкость и масштабируемость инфраструктуры, длительное время ввода в эксплуатацию новых систем, высокие трудозатраты при модернизации\замене оборудования;

  • Итого: высокие капитальные и эксплуатационные затраты, низкая финансовая эффективность;

     


Виртуализированная инфраструктура с дискретным управлением.

Данный вариант предполагает консолидацию ИТ сервисов на базе виртуальной среды и запуск системы дискретного управления инфраструктурой. Переход на полностью виртуализированную инфраструктуру, а также запуск системы управления происходит обычно постепенно, поэтапно: от низко критичных сред разработки и базовых инфраструктурных сервисов в сторону критичных инфраструктурных сервисов и ключевых бизнес-приложений.   Современные технологии виртуализации позволяют без ущерба для производительности проводить полную консолидацию ИТ сервисов (разумеется могут быть исключения, например - устаревшие системы аппаратной защиты). На базе виртуальной среды обеспечивается единообразие инфраструктуры, единый подход к управлению и масштабированию. Ключевые особенности:


  • Приложения размещаются на виртуальных серверах, которые могут быть гибко масштабированы под задачу, реплицированы с целью обеспечения отказоустойчивости и тд;

  • Управление мощностью и доступностью осуществляется в рамках платформы виртуализации, но на уровне дискретных серверов, как физических, так и виртуальных, как правило в полу-ручном режиме, но уже с большей степенью эффективности;

  • Построение отказоустойчивых и катастрофоустойчивых сред является более простым и низкозатратным процессом;

  • Осуществляется мониторинг виртуальных и физических серверов, что способствует сокращению количества сбоев;

  • Обеспечена высокая гибкость и масштабируемость инфраструктуры, сокращенное время и трудозатраты на ввод в эксплуатацию и модернизацию\ремонт аппаратной части;

  • Нет инструментов для расчета стоимости ИТ сервисов, расчет при необходимости обеспечивается в ручном режиме;

  • Администратор по-прежнему оперирует дискретными серверами;

  • Построение ИТ сервисов из компонентов инфраструктуры происходит в ручном режиме, как и управление сервисов - происходит на уровне его дискретных компонентов;

  • Достигается высокая утилизация аппаратного обеспечения;

  • Итого: существенное сокращение капитальных и эксплуатационных затрат, повышение качества функционирования ИТ сервисов;

     


Управление ИТ услугами или «частное облако». Вот тут и начинается то самое облако

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

Под каждую услугу формируется набор компонентов, которые требуются для ее предоставления. Для типовых услуг могут быть созданы типовые шаблоны, на основе которых выделение и группировка компонентов может производиться в автоматическом режиме с учетом требований к отказоустойчивости и производительности.

Данный механизм обеспечивается при помощи комплексной современной системы управления инфраструктурой, обеспечивающий в том числе мониторинг и проактивное управление, patch management и тп. 

Три важных момента:


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

  • Имеющаяся в системе управления отчетность позволяет делать стоимость ИТ существенно более прозрачной, фактически демонстрируя затраты на каждый ИТ сервис с точки зрения инфраструктуры. Это стало возможно благодаря степени абстракции сервисов от физической инфраструктуры. Теперь бизнес получает инструмент прозрачного «магазина» для своих потребностей. Хочешь катастрофоустойчивый сервис 24х7 с уровнем доступности mission critical? 100 руб. Дорого? Вот вариант бизнес-критикал-80 руб. Есть вопросы-вот отчет по утилизации.

  • При переходе к управлению стоимостью сервисов изменяется подход к оценке стоимости\себестоимости ресурсов -  от абстрактной стоимости физического сервера к «стоимости ресурсов в единицу времени». Это изменение создает возможность управления сервисами на уровне затрат (стоимости) пула ресурсов. Если в каком-то случае выгодно использовать собственные мощности – используем собственные. Если для какого-то случая выгодно купить сторонние ресурсы – их можно купить на то время, на которое оно необходимо (целесообразно по затратам). Если нужно обеспечить резервирование мощностей на случай пиковых нагрузок – также можно решить при помощи подключения внешних ресурсов, не инвестируя в собственный резервный ЦОД. Таким образом инфраструктура становится гибкой, масштабируемой и измеряется одним параметром: стоимостью (за процессор, мегабайт, пространство адресов).

     

    Ключевые особенности этапа:


  • Сохраняются преимущества виртуализированной модели инфраструктуры;

  • Осуществляется полноценное управление мощностями, доступностью и стоимостью в разрезе ИТ услуги\сервиса;

  • ИТ подразделение может перейти в формат сервис-провайдера и получает возможность четко биллировать оказываемые услуги не только в формате стоимости выезда инженера для установки Windows, но и в формате четкой обоснованной стоимости ИТ сервисов;

  • Становится доступным гибкое управление мощностями и доступностью с возможностью подключения любых внешних мощностей в случае необходимости и их последующим отключением;

  • Пользователи получают запрошенный каталог сервисов, прозрачную стоимость услуги, возможность гибкого выбора условий работы приложений

  • В итоге стоимость ИТ для бизнеса становится четкой и прозрачной, что приводит к более четким требованиям со стороны бизнес-подразделений, считающих свои бюджеты;

     


Переход к сервисной модели организации инфраструктуры создает условия для подключения для доступа к этим сервисам с различных типов и форматов устройств.


Существует ряд технологий, обеспечивающих не только предоставление этих сервисов на базе WEB, но и организацию привычной пользователю среды.


 


Предоставление сервисов пользователям


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


Можно выделить несколько аспектов предоставления этих сервисов для пользователей:


  • Нет необходимости использовать мощное пользовательское устройство, все ресурсоемкие задачи решаются в центре;

  • Должны быть обеспечены принципы информационной безопасности и аутентификации;

  • Должны быть обеспечены механизмы управления устройством и его содержимым, в том числе возможность удаленной поддержки пользователя;

  • Стоимость эксплуатации рабочих мест должна быть максимально оптимизирована;

  • Должна быть обеспечена высокая надежность предоставления сервисов;

     


Все устройства можно условно разделить на стационарные и мобильные. Для мобильных устройств ввиду иного способа потребления контента (режим управления через тач скрин) как правило требуется создание специализированных мобильных приложений с удобным тач интерфейсом.


При этом для мобильных рабочих мест особенно актуальны вопросы безопасности, удаленного управления, траблшутинга, а также обновления программного обеспечения.


Разумеется, для управления пользовательскими устройствами необходима система управления пользовательской инфраструктурой, если нет «лишних» денег делать эту вручную.

Стационарные механизмы вы знаете уже давно:

-терминальные сервисы

-виртуализорованные рабочие столы

-виртуализированные приложения



По итогам всего вышесказанного получается, что облака уже в нашей долине :)





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

Подписаться на комментарии
Петр Маишев
Петр Маишев

29 октября 2014 19:38

Вот только когда есть сервисы, которые по потребляемой мощности сравнимы с одной машиной (от которой мы стараемся абстрагироваться) как то картинка не складывается. А обычно, это самые критичные сервисы и есть.

 

#

Александр Жилин
Александр Жилин

5 ноября 2014 09:04

А почему нет?

Размер виртуальной машины может быть любой, в том числе значительно меньше мощности физического сервера.

другое дело, что тут разумеется есть эффект масштаба. Если у нас всего 5 физических серверов и 1 хранилище руками управлять бывает проще, но философия перехода к управлению мощностями от этого ведь не меняется :)




#

Петр Маишев
Петр Маишев

6 ноября 2014 14:15

Я тоже про эффект масштаба говорю. Если у нас 100 сервисов, потребляемая мощность которых в попугаях распределена так:
1) 80 сервисов - 1 попугай каждый
2) 16 сервисов - 10 попугаев каждый
3) 4 сервиса - 100 попугаев каждый

Как строить облако для первых двух типов сервисов понятно, но, критичные для бизнеса сервисы - это строчка 3. И они это те самые 5 физических серверов (N+1) + СХД.

#

Александр Жилин
Александр Жилин

3 декабря 2014 10:42

так в чем сложность?

строим единую инфраструктуру на базе серверов и СХД.

если у нас разные типы ресурсов и их нужно группировать (например медленные и дешевые для тестовой зоны и дорогие и производительные для продуктива) можно сформировать два пула (облака), но обычно таких группы 2-3, не более. То есть мы уходим от подхода - один сервер под одну задачу или при наличии денег-  группа серверов+СХД под группу отдельных задач, а рядом вторая такая группа и тд. 

Есть единая среда, а точнее единый подход.

На ее базе мы собираем из кубиков (ресурсов) разные конструкции. Нужна высокопроизводительная и отказоустойчивая архитектура-нужно собрать конструкцию из дублирующих виртуальных ресурсов с масштабированием, просто будет использовано больше кубиков, чем в обычном случае.

Или, если есть желание сделать отдельное облако для тестовой зоны (из дешевых и медленных ресурсов), а отдельную для мегасервисов - делаем два облака, из которых нарезаем кубики по необходимости.

в старой парадигме мы создавали отдельные кластеры под каждую группу задач, при этом утилизация оборудования зачастую была менее 50%.

то есть берем описанные 5 серверов+СХД.

создаем облако.

под критичные сервисы создаем балансируемый по нагрузке и отказоустойчивости кластер. Запускаем критичные сервисы и радуемся.

для прочих некритичных из того же облака, по тем же принципам, создаем сервера\диски для других сервисов.



#

Александр Жилин
Александр Жилин

3 декабря 2014 10:42

#

Александр Декевич
Александр Декевич

3 декабря 2014 15:25

Сорри, Александр, но как-то "деградация" понятий  в публикации произошла.

И в итоге тема "Куда плывут облака ..." трансформировалась в обыкновенный, маленький, типовой кластер виртуалок... :-( (этак, -10 лет, как минимум)
"Соль" в чем? Если трактовать кластер виртуалок, как "облако", то тогда можно добавить для вкуса и полного маркетинга "360" и "Organic" :-).

Т.е. я не вижу в чем, в данном случае, отличие просто "виртуализации среды" от "облака".

#

Александр Жилин
Александр Жилин

11 мартa 2015 12:12

Александр!

пожалуй так на словах не убедить.

давай посмотрим на практике?


у нас на Белорусской есть технологический центр, построенный на базе частного облака.

давай прямо в брюхо этой технологии заглянем?


с меня кофе.

на встречу могу позвать до 15 человек, если кому-то интересно :)

#

Александр Жилин
Александр Жилин

11 мартa 2015 12:13

Петр!

аналогичное предложение: приезжайте на Белорусскую, покажу на практике как работает


сможете руками потрогать, берите с собой админов



#

Пожалуйста, авторизуйтесь, чтобы оставить свой комментарий

Нажимая на кнопку "Подписаться", Вы соглашаетесь с условиями Политики в отношении обработки персональных данных и даете согласие на обработку персональных данных