In English

Как самому сделать себе немного облака. Часть первая

28.05.2014, Калошин Вячеслав
Ссылка на запись:
http://blog.kaloshin.ru/2014/05/06/

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

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

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

Для начала надо определиться, что же такое облако и с чем его можно есть.

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

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

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

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

В итоге грань между «отказоустойчивым кластером» (масло маслянное, да) и «облаком» получилась … ну очень тонкой. Поэтому предлагаю оставить теологические споры диванным аналитикам и перейти к практике.

Что можно получить от облака?
  • Снижение расходов на обслуживание бизнеса. Как прямых, вроде стоимости серверов, так и косвенных, в виде ускорения каких-либо бизнес-процессов.
  • Увеличение доступности сервисов. Выйти на «5 девяток» по-прежнему дорого, но гораздо дешевле, чем это было лет пять назад.
  • Открытие новых возможностей для бизнеса. Звучит слишком рекламно, но это реально так. Новые технологии реально дают такие возможности, даже заикание о которых раньше приводило к кручению пальцем у виска.
Остальные преимущества в принципе либо укладываются в эти пункты, либо проистекают из них. Давайте я попробую раскрыть эти пункты на примере наиболее распространенных решений.

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

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

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

Вот я тут упомянул публичные и гибридные облака. Чем они отличаются? Публичное облако – это такое облако, все сервисы которого крутятся у провайдера. Гибридное – это «размазанное» по своим и провайдерским мощностям.

Теперь немного про популярные слова, которые связаны с облаками и которые связывают с преимуществами для бизнеса.
Вот скажем Bigdata. Что это? Я встречал определения типа «это то, для обработки чего не хватит даже самого мощного компьютера» и «петабайты данных». Я сторонник другого, более крамольного определения. Bigdata – это те данные, которые у нас уже есть, но мы не знаем, что с ними можно сделать. А потерять неохота. У кого-то это будет мегатонны логов пользователей, у кого-то куча данных с датчиков, а у кого-то это будет жалкая пара терабайт картинок. И вот облака дают возможность как-то хранить и по возможности обрабатывать эти данные. При этом «бигдачность» системы вовсе не характеризуется объемом обрабатываемых данных. Есть системы, где обрабатываются буквально гигабайты данных, но эти гигабайты легко грузят сотни серверов. В общем, красивое слово.

VDI, или Virtual Desktop Infrastructure. Развитие идеи терминальных серверов, только с предоставлением пользователю своей виртуальной машины. Шикарно ложится на облака, особенно в случае применения однотипных АРМ-ов и поэтому в последнее время развивается очень сильно.

DWH, или Data WareHouse. Еще одно общее слово. Для кого-то это хранилище кучи файлов, кто-то хранит всякие таблички. Говоря кратко, это то место, куда бегают всякие системы анализа и отчетов за данными. Данные там собираются из разных источников, приводятся к общим знаменателям, группируются и так далее и тому подобное. По понятным причинам, DWH очень любят всякие финансовые компании.

Ладно, хватит красивых слов, тем более, что интересующиеся могут спокойно напрячь поисковик и начитаться по любому интересующему термину. Пойдем практиковаться.

Планируем облако.
Что надо сделать в самом начале? В самом начале надо взять за шкирку вашего системного аналитика … как нет аналитика? Тогда берете за шкирку себя и начинаете описывать и считать.

Берете каждый сервис в вашей инфраструктуре и, все обдумав, отвечаете на следующие вопросы:
  • Время работы сервиса. Круглосуточно, ночью, днем в рабочие часы. Бухгалтерия ночью не работает, а веб-сайт должен быть доступен круглосуточно.
  • Доступность сервиса. Может ли он делать паузы во время работы? Скажем, на 5 минут? Телефония должна работать всегда, а вот резервное копирование может и постоять на паузе.
  • Критичность сервиса. Если он «упадет», как сильно это повлияет на бизнес? Сравните бухгалтерию во время сдачи отчета и внутренний портал. Если добудете цифры в духе «простой 5 минут – 100 500 рублей» или «день простоя – штраф в мульен», то вообще отлично. Хинт: заручитесь одобрением финансистов и бухгалтеров: они тают, когда ИТ-шники спрашивают про их тяжелую долю и пытаются ее облегчить.
  • Ресурсные требования по времени. Телефония требует ресурсы пиками и очень не любит, когда ей недодают ресурсов во время этого пика. А тот же веб-сервер толерантен к таким проблемам.
  • Просто ресурсные требования. Сколько дисков-процессоров-сети надо сервису.
  • Сложность обслуживания? Сколько ИТ-шников в среднем требуется для обслуживания этого сервиса. Стоимость ИТ-шника?
  • Есть ли возможность прогнозировать нагрузку? Для веб-сайта – нет, а для той же системы резервного копирования – запросто.
  • Зависимость сервиса. Скажем, бухгалтерия не выживет на одном офисе без бухгалтерской системы, ей будет очень плохо без сервиса печати, чуть полегче без телефонов и ей абсолютно будет начхать на веб-сайт. Но все умрет без работающей системы хранения данных.
  • Возможность вынести сервис наружу. Веб-сайт и почтовые системы – почему бы и нет? Бухгалтерию – убьют.
  • Уровень масштабирования в зависимости от роста компании. Веб-сайту пофиг, сколько у вас сотрудников, а той же VDI или почтовой системе – нет.
  • Сложность масштабирования системы в зависимости от нагрузки. Веб-сайты обычно довольно легко сделать масштабируемыми, а вот телефонию без бутылки не отмасштабируешь. Тут надо очень хорошо подумать, а какие функции этого сервиса можно отдать наружу.
При этом очень желательно максимально детализировать сервисы. Скажем, типичный веб-сервис на самом деле состоит из кеширующего сервера, веб-сервера, сервера базы данных и сервера хранения данных. Чем более высокой будет детализация, тем в дальнейшем будет проще.

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

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

Но на данном этапе я повангую и скажу сразу: больше всего линий пойдут к двум сервисам – сервису передачи данных (он же обычно обзывается «локалкой») и к сервису хранения данных (он же жесткий диск, он же файлопомойка, в некоторых случаях это будет NAS).

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

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

Теперь настала пора взять в руки краски и любым приятным способом раскрасить серверы по критичности для бизнеса. При этом рекомендую брать как минимум два цвета: один для «критичный всегда», а второй для «критичный только в рабочее время». Скажу сразу, если у вас получилось, что все сервисы «критичные всегда», то что-то вы не так сделали. Весь мой опыт говорит о том, что так не бывает. Понижайте градус критичности.

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

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

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

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

И, наконец, последний шаг. Считаем себестоимость каждого сервиса. Скажем, сколько стоит нам веб-сервер сейчас? А если его в локальный кластер? А сколько будет стоить, если его унести на арендованный у провайдера сервер? А если под него купить облако? Есть ли загружаемые с веб-сервер большие файлы, под которые дешевле будет купить сервис CDN? Есть ли разница в стоимости лицензий для «standalone» и «cloud/terminal»? Если мы уменьшим время простоя, то сколько сэкономим?
В результате у вас получится большая портянка, по которой будет сразу понятно, какой сервис выгодно тащить в облако, для какого лучше построить локальный кластер (и какими ресурсами он должен обладать), а какие реализовать по остаточному принципу или вообще оставить на отдельных машинах.

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

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

Скажу сразу, выбирать систему виртуализации еще рано, в следующей части будем. Вы для начала докажите себе и владеющим деньгами людям, что это вообще выгодно будет. Для предварительных расчетов можете смело ставить стоимость системы виртуализации в 300 баксов на один железный сервер. Этого при необходимости хватит на корпоративную и пальцатую VMware, но скорее всего можно будет обойтись гораздо меньшими деньгами. Лучше побольше заложите на инженеров. Чем они будут «продвинутей», тем больше шансов, что у вас все взлетит.

***И да, картинку спер из интернета. Автора не знаю, а то бы написал.

Центральный федеральный округ