Всем привет. Меня зовут Соловьёв Артём, я несколько лет занимаюсь развитием корпоративного облака, и сегодня хочу поговорить об основных отличиях корпоративных и коммерческих облаков.

Сейчас уже сложно найти людей, связанных с ИТ, которые не слышали об облачных технологиях и таких провайдерах как Amazon Web Services, Microsoft Azure, Google Cloud и т. п. Многие крупные компании строят свои ИТ-системы по облачному принципу. Хочу сосредоточиться на различиях, которые есть между коммерческими и корпоративными облаками, и на том, что стоит учитывать, если вы хотите начать переходить к облачной модели в своей организации. Также мы посмотрим, что происходит в коммерческом облаке, а что — в корпоративном.

Сначала договоримся о терминах. Я не претендую на их всеобъемлющую правильность, но внутри статьи буду подразумевать именно это.

• IaaS (Infrastructure as a Service) — предоставляемая клиенту инфраструктура, серверная или контейнерная. Может быть как виртуальная, так и физическая. Обычно, это просто предоставляемые серверы с ОС или базовые контейнеры из некоего репозитория. Также сюда можно отнести установленное на сервере системное ПО без его конфигурирования.

• IaaS+ (Infrastructure as a Service+) — предоставляемые пользователям инфраструктурные продукты: сервер + системное ПО (web‑сервер, СУБД и т. п.). В отличие от IaaS пользователь получает не просто сервер с ОС, а установленный и настроенный на сервере продукт, например Nginx, PostgreSQL, MS SQL, WildFly и т. п.

• PaaS (Platform as a Service) — платформенный сервис, в рамках которого от пользователя скрыта инфраструктурная составляющая. Например, тот же PostgreSQL может быть представлен не только как сервер с установленным ПО по модели IaaS+, но и как готовая СУБД, когда пользователю выдаётся точка подключения без указания инфраструктуры под сервисом (Data Base as a Service — DBaaS). Аналогично могут выдаваться и web‑серверы (WSaaS), и балансировщики (LBaaS), и другие продукты.

• АС (Автоматизированная система) — согласно ГОСТ 34.003–90, «система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций».

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

Начнём.

Цель

Давайте начнём с цели, для которой создаётся облако. Коммерческое облако — это бизнес; цель бизнеса — заработать деньги. Следовательно, цель создания коммерческого облака — заработать деньги.

А что у нас с корпоративными облаками? Поскольку облако внутреннее, то деньги зарабатываются другими продуктами. Всё, что не зарабатывает деньги (или почти всё), является расходами. ИТ‑инфраструктура — расходы, такие же как аренда или покупка помещения, коммунальные услуги, заработная плата. Для повышения эффективности бизнеса необходимо уменьшать расходы, и переход к облачной модели осуществляется с этой целью. То есть цель создания корпоративного облака — сэкономить деньги.

Казалось, бы сэкономленный рубль = заработанный рубль, но в нашем контексте это различие целей даёт существенную разницу в акцентах и инструментах, используемых при создании облака.

Инфраструктура

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

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

Образ результата

В коммерческом облаке пользователю выдаётся закрытый тенант, в котором тот настраивает виртуальную сеть и заказывает продукты. Если мы говорим про IaaS, IaaS+, то пользователь может получить продукт с определённым им именем, в котором заказчику предоставлены административные полномочия как на уровне ОС, так и на уровне установленного ПО. При этом провайдер не имеет доступа внутрь инфраструктуры заказчика и разворачивает всё с помощью инструментов облачной платформы, с возможность передать некий инициализирующий скрипт для первоначальной настройки сервера. В идеале, чтобы не дать возможности администраторам облака как-то увести пользовательские данные, хранящиеся внутри инфраструктуры, все виртуальные диски должны шифроваться с использованием компонентов ключей, создаваемых заказчиками.

Для услуг PaaS создаётся аналогичная ситуация. Пользователю предоставляется сервис с административными полномочиями в нём.

Такое поведение облака вполне понятно — заказчики хотят чтобы их данные оставались только их и провайдер не имел бы к ним доступа. Также они хотят полностью управлять своей инфраструктурой, и провайдер даёт им эту возможность.

Теперь давайте посмотрим на корпоративное облако. В организации, скорее всего, уже есть правила настройки разных продуктов, политики безопасности, политики аудита, процессы ITSM и т. д., в зависимости от зрелости процессов в компании. Значит, если мы хотим экономить, нужно научиться выдавать продукт, требующий минимальной настройки после выдачи. Кроме того, мы хотим иметь возможность изменять конфигурацию продукта после его выдачи. Для реализации всего этого у инструментов облака должен быть полный доступ к инфраструктуре, по крайней мере во время настройки. Экономия может получиться, во‑первых, за счёт снижения time to market, а, во‑вторых, за счёт уменьшения нагрузки на отделы сопровождения соответствующих продуктов, ведь им нужно меньше времени уделять настройке выданного оборудования.

Заказчики

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

В корпоративном облаке для экономии средств заказывать инфраструктуру должны люди, которым она нужна: разработчики, тестировщики или администраторы АС, эксплуатирующихся или создаваемых в компании. При этом, разработчик, например, может не знать все тонкости настройки СУБД или брокера сообщений. Также он может не знать всех правил компании для настройки продуктов. Более того, эти правила могут периодически изменяться. Тем не менее, всё это не должно помешать ему заказать себе, например, БД, получить строку подключения и разрабатывать с её помощью.

Тут стоит отметить, что если пользователем коммерческого облака является организация, то возможен заказ через некий «прокси», когда конечный заказчик из разработки или сопровождения некоторой АС заказывает её, после чего инфраструктура получается, настраивается ответственным подразделением (вручную или автоматически) и затем передаётся конечному заказчику.

Применяемые инструменты облака

В основе коммерческого облака обычно лежит достаточно простой сервис, позволяющий выдавать инфраструктуру, в основном виртуальные машины, из подготовленных облаком или клиентом образов. Сервис позволяет создать для каждого заказчика изолированную среду с некоторыми точками входа и выхода трафика. Клиент самостоятельно полностью управляет своей инфраструктурой, описывает сети, которые он использует, определяет способы назначения IP-адресов и т. п. Для создания ВМ провайдер часто предоставляет широкий набор образов различных операционных систем и их версий; образы, содержащие наиболее часто используемое ПО, такое как популярные свободно распространяемые СУБД, web‑серверы и т. п. Также могут предоставляться образы с коммерческим ПО, как с лицензией, так и без неё, для использования собственных лицензий заказчика.

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

При предоставлении PaaS-услуг всё то же самое: например, СУБД для DBaaS, внутри которых клиент имеет полные полномочия и может как угодно управлять своим экземпляром сервиса.

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

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

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

Теперь вернёмся к корпоративным облакам. Как мы помним, главная цель — это экономия. Значит, нужно экономить персонал, служебную инфраструктуру, время разработки и модификации облака. Кроме того, у нас уже есть готовая инфраструктура, которую мы хотим затянуть в облако. В итоге, в корпоративных облаках зачастую используются готовые или созданные самой компанией платформы управления облаком или облачные оркестраторы. Оркестраторы содержат инструменты создания и изменения облачных продуктов, в результате заказчик может не тратить силы на проектирование и реализацию инструмента управления облаком, а сосредоточиться на подготовке облачных продуктов для предоставления клиентам. В этом случае мы почти всегда будем иметь сервис типа IaaS+, со всеми требуемыми лицензиями, потому что просто сервер с ОС очень редко для чего нужен.

В организациях не обязательно в инструменты облака могут входить средства мониторинга, потому что мониторинг может существовать ещё до появления облака, и задача создателя продукта для облака — встроить регистрацию выдаваемого продукта в имеющуюся систему. Также инструменты мониторинга самого облака могут внедряться постепенно, опять же на основании того, что ещё до появления облака в крупных компаниях имеются все необходимые инструменты мониторинга и правила реагирования на инциденты, внедрённые в соответствии с практиками ITIL и ITSM.

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

Что касается Terraform, то разработка провайдера целесообразна, когда в компании понимают, кто и где будет его использовать.

Биллинг

Я сделаю некоторое упрощение: буду называть биллингом все действия, связанные с тарификацией ресурсов облака.

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

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

Квотирование

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

Теперь посмотрим на корпоративное облако. Если для коммерческого облака чем больше будет продано ресурсов, тем лучше; и чем меньше будет их фактическое потребление, тем также лучше, потому что можно будет поднять переподписку и заработать ещё больше, то в корпоративном облаке всё иначе. Как мы помним, основная цель ­ — экономия, значит, нужно как можно больше выжать из имеющихся ресурсов, увеличив их потребление, и при этом не допустив инцидентов из‑за слишком высокой загрузки.

Именно поэтому в корпоративных облаках часто применяют механизм квотирования. Когда некоторой АС выделяется ограниченное количество ресурсов — ядер и оперативной памяти, — и АС вынуждена оптимизировать свои потребности, в том числе и алгоритмы для работы в этих условиях. В то же время, нужно понимать, что какие‑то направления бизнеса могут внезапно или сезонно потребовать существенного увеличения ресурсов. Например, «выстрелила» какая‑то идея, и мы получили на этом направлении кратный рост пользователей. Потому необходимо обладать некоторым запасом мощностей, а также гибкими механизмами перераспределения или добавления квот.

Ограничения для клиентов

То, какие ограничения применяются к клиентам корпоративных облаков при наличии задолженности за потребляемые ресурсы, определяется договором. Если мы говорим о работе с физическими лицами, то обычно это прописано в оферте, которую принимает пользователь при использовании облака. Например, можно в несколько раз снизить производительность CPU при задолженности больше недели и не давать заказывать дополнительные мощности. Далее, если задолженность продолжает расти, инструменты облака могут выключить ВМ, ограничить входящий трафик и, в конце концов, удалить всё. При работе с юридическими лицами, помимо оферты могут быть проработаны индивидуальные договоры, в соответствии с которыми и будут применяться те или иные меры. Помимо денег, провайдер для некоторых тарифов может ограничивать трафик, загрузку CPU, как мгновенную, так и среднюю, например за час, и другие параметры инфраструктуры. Причём само введение ограничений можно автоматизировать. В любом случае, провайдер, если он не выходит за рамки договора, остаётся в своём праве, а от ограничений страдает клиент и его бизнес.

Что мы имеем в корпоративном облаке? В нём и инфраструктура, и заказчики относятся к одной организации (или группе связанных организаций) таким образом, что применение каких-либо ограничений может ударить по общему бизнесу и прибыли компании. А значит, облако совершенно не заинтересовано в простое бизнеса. Более того, если из-за каких-то ограничений фирма потеряет деньги, то скорее всего, виноваты будут все: и заказчики с дефолтом, и облако. Потому, если мы планируем введение каких-то санкций на основе биллинга или нагрузки, то нужно их чётко прописать, утвердить на самом высоком уровне и при наступлении подобных ситуаций сначала пообщаться с заказчиками. В этом случае автоматизировать стоит только уведомление о наступлении какого-либо события, после которого могут быть введены ограничения.

Это ещё один аргумент подумать, точно ли нужен биллинг во внутреннем облаке и в каком виде? Наличие счёта с деньгами предполагает, что они могут кончиться. И что делать дальше?

Подходы к отказоустойчивости

В коммерческом облаке отказоустойчивость организуется на уровне инфраструктуры облака. Провайдер готовит ЦОД, соответствующий каком‑то классу отказоустойчивости, даёт возможность пользователю выбирать между несколькими ЦОДами. В продвинутых облаках описываются affinity-группы внутри одного ЦОДа, то есть ограниченная часть инфраструктуры внутри одного ЦОДа, которая не зависит от других частей. Это позволяет уменьшить «радиус поражения» при проблемах внутри ЦОДа. Эти группы по‑разному называются в разных облаках, но общий смысл один. Если пользователь заказывает продукты в разных группах, то они находятся в разных стойках, подключены к разным источникам питания и разным коммутаторам. Таким образом повышается доступность (High Availability — HA). Если же продукты выданы в одной группе, то пользователь получает максимальную скорость взаимодействия компонентов между собой. Заказ же в разных ЦОДах позволяет реализовать катастрофоустойчивость (Disaster Recovery — DR). Облако предоставляет механизмы HA/DR, а пользователь в праве ими пользоваться или не пользоваться. При этом использование нескольких ЦОДов или нескольких affinity-групп в одном ЦОДе может стоить пользователям дополнительных денег.

И снова обратим взор на внутреннее облако. У компании, в целом, есть понимание того, как должны работать механизмы HA/DR для разных продуктов и разных АС. Более критичные АС требуют разнесения по разным ЦОДам, менее критичные могут не требовать. Это значит, что для экономии и соблюдения корпоративных стандартов облако само должно регулировать возможность разнесения инфраструктуры по разным ЦОДам, а продукты облака должны включать в себя правила создания инфраструктуры в соответствии с политиками. Например, если кластеру реляционной СУБД, например PostgreSQL, в промышленном окружении положено быть разнесённым по разным ЦОДам, то у заказчика не должно быть возможности заказать по‑другому. И наоборот, если ноды кластера in‑memory СУБД, таких как Apache Ignite или HSQLDB, должны находиться как можно ближе друг к другу, то пользователь также не должен иметь возможность выбрать другой вариант конфигурации.

Вот основные различия, которые мы выделили на текущем этапе развития облаков. Понятно, что в каких‑то организациях что‑то может отличаться, могут использоваться какие‑то заимствования одной модели у другой. Кроме того, корпоративные платформы управления облаком могут подключаться к коммерческим облакам. Тогда мы получаем гибридное облако. Многие коммерческие оркестраторы уже имеют в своём составе коннекторы к таким крупным решениям, как Microsoft Azure, AWS и т. п.

Как обычно, жизнь сложнее, чем написано в учебнике или, тем более, в одной статье. Тем не менее, надеюсь, вам было интересно посмотреть на облака именно в таком разрезе.