За последние 3 года только федерация EMC помогла развернуть программно–определяемые ЦОД–ы в более чем 1000 организаций по всему миру, полностью сохранив имеющуюся инфраструктуру, оптимизировав её использование для обеспечения бизнес–процессов. И согласно сделанным наблюдениям, в большинстве случаев к подобному решению компании приходят быстро и даже неожиданно для самих себя. Поэтому, даже если сейчас программно–определяемый ЦОД (далее для краткости — ПОЦОД) кажется вам чем–то очень уж диковинным, не спешите зарекаться от его внедрения. Риски проведения серьезных изменений в организации IT интуитивно понятны. В этой статье рассмотрены преимущества перехода к ПОЦОД и 4 распространенных причины их построения в организациях.

Что собой представляют программно–определяемые ЦОД–ы, в общих чертах знает каждый. И, хотя в нюансах могут быть расхождения, каждый уважаемый IT–производитель ориентирует стратегию своего портфеля решений в русле помощи своим заказчикам в преобразовании «обычных» ЦОД–ов в программно–определяемые. При этом, прежде всего, речь идет об экономической выгоде заказчиков от такого перехода. Однако, в процессе обоснования перед бизнесом необходимости этой трансформации с завидной регулярностью возникают трудности. Это не удивительно, если учесть сложность и запутанность взаимосвязи одного мира с другим. Вспоминается бородатый анекдот про то, как сын спросил папу–программиста почему солнце восходит на востоке и заходит на западе. Ответ «если это работает — ничего не трогай», хорошо характеризует действительность. Грустно и смешно то, что корпоративные IT, некогда бывшие авангардом инноваций, теперь больше ассоциируются с шаманской кастой, исполняющей ритуалы с бубнами.



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

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

Не секрет, что серьёзные изменения в инфраструктуре или бизнес–процессах часто становятся причиной какого–то критического сбоя, или даже серии сбоев. А это может иметь неприятные долгоиграющие последствия при наличии высокой нагрузки на инфраструктуру.

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

В России c этим еще сложнее, с нашим «особым путем» и «российской спецификой», которую не понимают «на западе». Дело в том, что мы, видя себя изнутри и глядя на западные IT–модели по их рекламным буклетам и пресс–релизам, делаем вывод, что мы с ними не просто очень разные, но они вообще инопланетяне. И всё, что хорошо для них, для нас, для землян — дальний космос. Такого же мнения придерживался и я, пока не понял, что хотя разрыв между «нашим» и «их» IT есть, но он далеко не космически велик. А значит, возможно, нам есть, что взять для себя из их передовых разработок, подвергнув, при необходимости, критическому осмыслению. Далее я предлагаю рассмотреть и проанализировать четыре аргумента в пользу перехода к ПОЦОД–у.

Но сначала я хочу напомнить о том, какими особенностями обладают современные реализации ПОЦОД–ов:

• Автоматизированное развёртывание виртуальных машин, сетевых ресурсов, ресурсов хранения. Повышается скорость развертывания и предоставления новых сервисов. Появляется возможность использовать глобальные политики для управления рабочими процессами, включая, например, настройку резервного копирования, политик безопасности, сетевых параметров. Избавление от множества другой рутины.
• Автоматизированное управление уровнями хранения данных. Обеспечивается высокая скорость работы с данными, при сохранении расходов на хранение на приемлемом уровне. Возможность использования политик SLO для управления хранением.
• Автоматизированный мониторинг. Предоставление информации о состоянии сервисов в реальном времени. Облегчается процесс управления ПОЦОД. Благодаря оперативности реагирования и возможности проактивного мониторинга, увеличивается надежность, доступность и производительность. Благодаря повышению эффективности работы сервиса снижаются эксплуатационные затраты.
• Прозрачность использования ресурсов. Возможность точно оценить затраты на поддержку сервисов, корректность подсчета потребления ресурсов различными подразделениями организации. Снижение риска необоснованного чрезмерного потребления.
• Автоматизированная защита от сбоев, включая автоматическое восстановление. Предотвращение сбоя сервиса, либо ускорение его возвращения в строй. Снижение риска ошибки оператора во время восстановления.
• Встроенные сервисы резервного копирования и восстановления. Возможность использования личных политик защиты данных, в том числе в соответствии с корпоративными или внешними политиками. Дедупликация в ходе резервного копирования. Минимизация затрат благодаря ускорению резервного копирования и восстановления.

Таким образом, ПОЦОД — это интересное техническое решение, существенно облегчающее жизнь и упрощающее выполнение различных задач, потенциально позволяющее выйти на новый уровень предоставления IT–услуг бизнесу. Однако, как «у нас», так и «у них», настоящие хардкорные специалисты не устают повторять, что они могут сделать «всё то же самое своими руками, за зарплату». В этом есть своя правда. Более того, при если придти к управленцам с попыткой обоснования подобного решения, то в лучшем случае мы столкнемся с искренним непониманием. Мол, «раньше вы требовали деньги, чтобы делать свою работу, а теперь вы просите деньги, чтобы работу не делать».



Получается, что ситуация для перехода к ПОЦОД должна созреть, как минимум, до того состояния, когда бизнес «не может жить по старому». А в идеале, когда еще и IT по старому уже не хочет. И такая тенденция постепенно развивается.

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

Причина №1. Проблемы с производительностью в сочетании неэффективным использованием инфраструктуры

Из всех причин, эта, пожалуй, наиболее распространенная, в том числе и в России. Потому что редко можно встретить IT–руководителя, который на самом деле точно знает, какие приложения и сколько ресурсов потребляют, причем в подробностях. Распространена ситуация, когда ресурсы выделяются под критичные приложения исходя из их пиковых потребностей, плюс некоторый запас. В результате инфраструктура бывает перегружена железом, которое, с одной стороны, большую часть времени простаивает, а с другой — испытывает регулярные всплески нагрузки, которая утыкается в узкие места, что создает ощущение недостатка физических ресурсов. А их всего лишь нужно правильно спланировать и использовать. Желание побороть подобную ситуацию приводит к рассмотрению программно–определяемых решений, потому что нехватка информации не позволяет формировать стратегию развития инфраструктуры, планировать бюджет и т.д.

Причина №2. Сложно определить и поддерживать соответствие сервисного уровня приложения и предоставляемых ему физических ресурсов

Рано или поздно бизнесу приходится меняться вслед за требованиями рынка. Это выражается в новых проектах, развитии приложений и в использовании в бизнес–процессах новых данных. Как следствие — меняются рабочие нагрузки, растут объемы данных. Бывает? Да!

Чтобы организационные процессы и инфраструктура позволяли подстраиваться под динамически меняющуюся нагрузку, нужно своевременно оценивать, каким образом обеспечить максимальную эффективность использования ресурсов. В типичной архитектуре ПОЦОД для этого используются специальные программные средства, автоматизирующие или, по крайней мере, облегчающие данный процесс.

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

Однажды был случай, когда у одного из больших заказчиков нашли ряд приложений, работающих с хранилищем класса Tier 1, которые после оценки профиля нагрузки перенесли в хранилище более низкого уровня без какой–либо потери производительности. Это принесло заказчику экономию в размере $5,2 млн. Не думаю, что такое удалось бы легко сделать, будь IT–инфраструктура этого заказчика жестко завязана на аппаратные уровни. А вот с использованием ПОЦОД — запросто. В российской практике у нас тоже был такой похожий случай. Только нам в результате оказалось не до смеха, потому что заказчик радостно сократил объем закупок нашего железа. Правда, он был нам очень благодарен.

Причина №3. Сотрудники IT перегружены работой, набор персонала приостановлен, а требования растут

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

Одним из важнейших преимуществ ПОЦОД в решении этой проблемы является использование глобальных политик и постепенный переход к автоматизированному выделению ресурсов в соответствии с ними. Уже само по себе классифицирование приложений является очень полезным мероприятием, позволяющим определить белые пятна инфраструктуры. А когда удастся на основе полученной классификации выделять ресурсы и измерять успешность достижения сервисных уровней — улучшится мнение бизнеса об IT.

С другой стороны, появляется возможность использовать освободившихся людей для решения более полезных и важных задач, предоставив им инструмент управления гораздо б?льшими объемами ресурсов. Например, согласно данным Gartner, в среднем один сотрудник оперирует данными объемом примерно 250 ТБ. По результатам сотрудничества с рядом крупнейших сервис–провайдеров, реализующих концепцию ПОЦОД, этот показатель возрастает до 600 Тбайт, а в ряде случаев — до 900. В дальнейшем, благодаря еще более глубокой автоматизации, будет пройден рубеж в 1 Пбайт.

Причина №4. «Теневые IT»

Сегодня ширится использование предприятиями публичных облаков. Да–да, в России тоже. Например, для обеспечения гибкости разработки. Зачастую это даже негласно приветствуется, поскольку многие разработчики не верят, что им по силам эффективно и выгодно использовать собственные IT–сервисы. Для них внутренние IT–системы компании — это дорого, долго и, иногда, некачественно. Поэтому они пользуются публичными IT–ресурсами по своему усмотрению, и, что самое неприятное, — без ведома и контроля своих же IT–служб. Это может привести, как минимум, к несоблюдению сервисных уровней, а как максимум, — к потере интеллектуальной собственности, утечке персональных данных, и т.п. Тем не менее, корпоративным IT это безобразие проще возглавить, нежели пытаться предотвратить. А для этого необходимо подготовить свою инфраструктуру для безопасной интеграции с публичными облаками, либо научиться предоставлять IT–сервисы внутренним пользователям с тем качеством и удобством, что они получают и у публичных провайдеров.

Например, для минимизации риска неконтролируемого роста цен на услуги внешних сервисов или недостаточной стабильности их работы, оценить потенциал развертывания собственного облачного хранилища. Согласно нашему опыту, использование программно–определяемых хранилищ не только не уступает по гибкости внешним сервисам, но в ряде случаев обходится до 25% дешевле. К тому же инфраструктура сервиса находится полностью под вашим контролем.

В заключение

Переход к новой форме организации IT обусловлен, в основном, следующими факторами:

1. Необходимость непрерывно решать проблемы с производительностью, сочетающаяся с желанием более эффективно использовать IT–инфраструктуру.
2. Требование поддерживать соответствие сервисных уровней приложений и предоставляемых им физических ресурсов.
3. Стремление более эффективно использовать имеющиеся в IT человеческие ресурсы в ситуации постоянного давления «сверху».
4. Растущие риски «теневых IT».

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

Разумеется, далеко не всегда подобная трансформация может произойти исключительно по инициативе IT–подразделения. Без понимания и поддержки на уровне бизнеса подобные мероприятия провести едва ли возможно. Но это уже другая история.

Использованные источники:
1) https://www.linkedin.com/pulse/four–catalysts–software–defined–data–centre–rollouts–dayne–turbitt?published=t
2) https://www.linkedin.com/pulse/software–san–driving–commodity–storage–enterprise–antonio–romeo?published=t
3) http://www.emc.com/collateral/analyst–reports/idc–sds–3rd–platform.pdf
4) http://www.emcfederation.com/

Следите за нашим блогом на Хабре и заходите ко мне в гости!
Денис Серов