Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
В 2010 году я начал работать в компании «Онланта» в должности пресейла. Отечественный рынок облачных услуг на тот момент только развивался, но уже был заряжен большим потенциалом. Недолго думая, в 2011 году мы приняли решение зайти на рынок в качестве облачного провайдера. 2021 – юбилейный для облака OnCloud.ru, и, оглядываясь назад, мы понимаем, что за десять лет мы проделали огромный путь в развитии нашего облака. О том, какие уроки мы усвоили, прокачивая облачный сегмент бизнеса компании, я расскажу в этой статье, теперь уже, на правах архитектора OnCloud.ru, имеющего десятилетний стаж работы с нашим облаком.
Освоение рынка мы начинали с проектирования архитектуры и разработки сервисной модели будущего OnCloud.ru. Достаточно долго решали, на чем будем строить и за сколько продавать. Как ни странно, с технической составляющей вопросов возникало меньше, чем с выведением модели расчета себестоимости проекта. Ориентиров было мало, разве что за рубежом. Поэтому создавали велосипед с нуля. Забегая вперед, могу сказать, что получился у нас не велосипед, а целый космический корабль.
Источник
Подавляющая масса существовавших на тот момент провайдеров по какой-то причине строила свои решения на блейд-серверах. Мы сделали несколько подходов к расчетам, оценили себестоимость такого решения и избрали иной путь. К 2011 году у нас появился кластер на больших четырехпроцессорных серверах (HPE DL580), который в общей сложности прослужил нам восемь лет с учетом апгрейдов. В среднем за это время мы заменяли каждый сервер порядка двух раз. Но благодаря четырехпроцессорным серверам мы не только сэкономили в части себестоимости, но и получили технический профит, имея возможность предоставлять заказчикам большие виртуальные машины.
На блейд-серверах конкуренты могли предложить ограниченное число ядер виртуальных процессоров и объема оперативной памяти – как правило, 16 vCPU объемом до 128 Гб RAM (два стандартных XEON по 8 ядер). Мы же могли предоставить сразу 40 vCPU с удвоенным объемом RAM, и долгое время позиционировали это как конкурентное преимущество. Списали свой кластер лишь в 2019 году – когда подошел к концу его срок полезного использования. К тому же, VMware, наш постоянный партнер по виртуализации, на тот момент прекратил его поддерживать.
К 2011 году мы реализовали приличное число проектов и предоставляли оборудование в аренду. СХД, в числе которых было несколько систем от IBM: DS 4700 и 3500 на SATA и SAS-дисках, остались в резерве с наших прошлых проектов. То есть, не вкладывая ни рубля, «Онланта» могла поддерживать два класса хранения – SATA и SAS. Но вскоре мы с коллегами пришли к выводу, что оборудование слабовато и апгрейды все же потребуются.
Роль SATA-дисков мы ограничили бэкапами. А модернизация СХД заключалась в покупке Hitachi HUS VM с SAS и SSD-дисками. В 2012 году она давала довольно приличную производительность по сравнению с другими продуктами на рынке, самостоятельно распределяя данные с помощью технологии тиринга по двум классам хранилищ (SAS и SSD). На тот момент это было хорошей инвестицией. В дальнейшем, наращивая классы хранения, мы смогли с помощью масштабирования сервиса сократить стоимость ресурсов для заказчиков примерно вдвое при росте инфляции и курса доллара. Сделали хорошо и себе, и заказчикам.
Сеть была еще одним тонким местом в архитектуре облака, которое мы пытались устранить. Сетевое оборудование у нас также осталось с прошлых проектов. Это были простые гигабитные коммутаторы Cisco, с которых мы не раздумывая перешли на Juniper 10 Гбит, как только к нам пошли заказчики. К слову, эти коммутаторы до сих пор используются у нас в сетях Colocation.
С апгрейдом сети проблемы не закончились, и мы столкнулись с DDoS-атаками. У нас был общий для всех заказчиков интернет-канал, который разделялся пропорционально их потребностям. То есть если атака шла на одного заказчика, то страдали все. При возникновении проблемы мы оперативно поменяли провайдера на того, кто использовал Cisco Arbor для защиты от DDoS-атак. Такой своеобразный ход конем одномоментно и навсегда избавил нас от этой проблемы.
Здесь сомнений практически не было. Мы остановили свой выбор на гипервизоре от VMware, который обладал всего одним небольшим минусом – высокой ценой. Но плюсы с лихвой перекрывают этот изъян.
Сейчас, когда все провайдеры предлагают доступность своего облака, которая закрепляется в SLA на уровне гипервизора, мы свое облако позиционируем в спектре интегральной доступности: на уровне гипервизора, сети и систем хранения данных. За 2020 год была абсолютная доступность по всем трем параметрам на уровне 100%. Никакой секретной формулы расчета SLA нет, но мы отвечаем перед заказчиками финансово не по одному, а сразу по трем параметрам (гипервизор, сеть и СХД) – как только один из них проседает, это отражается на общем уровне доступности. Чтобы просадки не происходило, все элементы облака у нас задублированы, и даже если проводятся технические работы, оно остается доступным. Например, не так давно мы практически полностью заменили все сетевое оборудование в кластере виртуализации, и сделали это без остановок работы сервиса и простоев. Заказчики даже не заметили полного апгрейда сетевого оборудования.
Первый серьезный проект случился у нас сразу после старта облака, и мы набили «базовые шишки первопроходца», благодаря чему на голову повысили уровень нашего сервиса буквально за два года.
К нам пришел крупный заказчик, и для него мы делали комплексный облачный проект, а не просто выделяли набор ресурсов в аренду, как это было ранее. У заказчика стояла задача перенести вовне среду разработки, чтобы в ней могли работать внешние разработчики без доступа ко внутренней сети заказчика. Мы предоставили виртуальные серверы, весь необходимый стек лицензий Microsoft, лицензию на базу данных Oracle и сервис WebEx для коммуникации удаленных разработчиков. Это был готовый комплект сервисов для удаленной работы распределенной команды. С помощью этого проекта мы научились предоставлять не разрозненные сервисы, а комплексные услуги с фиксированными показателями доступности.
С правильной математической моделью стоимости проекта мы «бодались» около года. Стремились максимально точно всё рассчитать, учесть окупаемость всех затрат (закупка оборудования, техподдержка, лицензии, размещение в ЦОД, трудозатраты и др.). Со стороны заказчикам казалось, что выходит дорого. Нам не всегда сразу удавалось выйти на доходность в проекте. Приходили новые заказчики, аналогичные нам игроки рынка тоже только нащупывали цены, и нам бывало непросто донести заказчикам, сколько реально стоит облако.
Одной стороной медали было сравнение с «конкурентами». Здесь важно понимать, что нашими конкурентами были не только те, кто предлагал облака. В начале 2010-х годов на рынке было очень много компаний, которые занимались в основном хостингом сайтов, а в довесок собирали непонятные «самодельные» облака и предлагали виртуальные серверы. По качеству технической реализации такие облака сильно проигрывали решениям от настоящих провайдеров, коими в то время могли называться немногие. Именно из-за таких игроков приходилось работать с возражениями «там дешевле». Облачный сегмент рынка тогда еще только формировался, и мы занимались просветительской работой, объясняя, почему дешевое – не всегда хорошее, и почему результат от «недооблачных» провайдеров в конечном итоге их разочарует. С конкурентами нашего уровня мы сравнивали себя комплексно – и по цене, и по SLA, и по техническим решениям.
Вторая сторона медали – сравнение on premise-инфраструктуры с облачной. Заказчики по какой-то причине считали стоимость облака без учета множества сопутствующих затрат. В их видении инфраструктуру может поддерживать один инженер в штате, работая в режиме 24/7. Мы объясняли, что один инженер не может заменить несколько линий поддержки, Service Desk, группу мониторинга доступности, группу экспертов по каждому направлению и дежурную смену. А без всех этих элементов поддержки качество будет неудовлетворительным. Кроме CAPEX на инфраструктуру есть еще и переменные издержки на электроэнергию и работу охлаждающего оборудования, которое порой потребляет не меньше самих серверов.
Так мы защищали каждую цифру проекта и детально прописывали каждую статью расходов в отдельном документе, который разрабатывался чуть ли ни специально для ИТ-директоров, чтобы те могли предметно защищать бюджет на переезд в облако. В конечном итоге, когда все разбиралось по составляющим, приходило озарение, что от облака есть не только технические или организационные, но и ощутимые финансовые плюсы. Для собственной инфраструктуры оборудование, как правило, закупается впрок. С облаком же прогнозировать потребность в ресурсах не надо, легко можно добавлять их при необходимости и так же легко отказываться от ненужных. Сегодня у всех моих коллег эти слова уже «отлетают от зубов».
Когда намерение переехать в облако уже достаточно серьезное, возникает второй вопрос: «В какое облако переезжать?» Нередко, выбирая с заказчиком подходящее решение между частным и публичным облаком, мы опирались на аргументы из данной таблицы. Каждая модель по-своему прекрасна.
Если после приведенных аргументов все равно остаются архитектурные сомнения, мы предлагаем гибрид публичного облака либо с инфраструктурой заказчика, либо с нашим частным облаком. Гибридная модель суммирует плюсы публичной и приватной модели. Но уже сегодня на рынке есть качественно новая прорывная модель, о которой я поведаю чуть позднее.
До 2014 года наше облако развивалось в рамках одного дата-центра – SAFEDATA. Затем поступил запрос от рынка на географически распределенное облако, и мы приняли решение развернуть второе плечо в дата-центре IXcellerate. Это позволило организовать для заказчиков резервный ЦОД на базе нашего облака. Мы обеспечили качественную сохранность резервных копий, организовав резервное копирование «крест-накрест». Обеспечили сетевую связность между площадками, арендовав темную оптику, пущенную двумя разными трассами.
Чтобы выбрать подходящее решение для резервного копирования, мы развернули целый исследовательский проект с чек-листами и проверками вендоров по ним. Первоначально мы использовали IBM Tivoli Storage Management, который нам достался практически бесплатно вместе с ленточной библиотекой. Решение было лишено портала управления, все приходилось делать через заявки, а скорость бэкапирования нас расстраивала. На рынке на тот момент были более интересные решения – от Veeam, Commvault, Veritas, Avamar. У двух последних не было провайдерской системы лицензирования с оплатой по факту потребления. Нам бы дорого обошелся перевод всех виртуальных машин на новый софт в виде разовой инвестиции. А между двух оставшихся мы выбрали Veeam, потому что, во-первых, у него есть и искомая система лицензирования, а во-вторых, он обеспечивал максимальную скорость бэкапирования и восстановления из резервных копий. Более того, продукт хорошо зарекомендовал себя на российском рынке, вендор сразу позиционировал его как облачный и предложил понятный RoadMap. Раньше мы брали плату только за объем бэкапов. Теперь появилась дополнительная строка в счетах – оплата лицензий.
Только за счет перехода на Veeam мы отказались от ленты, все бэкапы хранили на СХД, в три раза увеличили скорость восстановления из резервных копий и частично передали управление бэкапами в руки заказчиков через портал самоуправления от вендора.
Третьим серьезным этапом развития нашего облака было создание портала управления облачными ресурсами, где можно вести биллинг, документооборот, заказывать сопутствующие и дополнительные сервисы и общаться с менеджерами облачного проекта. Мы используем платформу как внутри компании, так и с некоторыми заказчиками. Руководители проектов на ней готовят счета, ведут учет потребления ресурсов заказчиков. Сейчас работаем над нашей собственной разработкой – Корпоративной Системой МультиОблачных Сервисов (КОСМОС), – которая дает возможность управлять не только различными гипервизорами, но и облачными платформами, в числе которых, как вы можете догадаться, будет не только OnCloud.ru. Совсем скоро начнем подключать к ней партнеров по новому направлению, о котором я расскажу чуть позже.
Сейчас облако OnCloud.ru географически распределено на два связанных между собой кластера виртуализации – в ЦОД IXcellerate и DataSpace TIER III. SAFEDATA мы теперь используем в качестве площадки для пилотов и размещения оборудования заказчиков, требовательных к цене, но не требовательных к сертификатам ЦОД. Кластер в IXcellerate построен на процессорах E5V4 c частотой 2,4 GHz, и в ближайшие полгода мы заменим их на процессоры GOLD второго поколения с частотой 3 GHz. Площадка сертифицирована по 152-ФЗ. DataSpace — один из лучших ЦОДов Москвы. У нас там большие четырехпроцессорные серверы с 3 GHz на XEON GOLD. Наш кластер построен на процессорах GOLD первого поколения с частотой 3 GHz.
В обоих ЦОД мы поддерживаем два класса хранения SAS (1 IOPS/GB) и SSD (5 IOPS/GB), для SAS используется СХД INFINIDAT, SSD размещено на NetApp FAS-серии. На первый квартал 2021 года запланирован переход с NetApp FAS-серии на Huawei DORADO V6 на NVME-дисках и последующее внедрение NVMe over Fabric. Бэкапим крест-накрест на базе вендорского решения Veeam Backup & Replication. Резервные копии храним в СХД Lenovo серии DE с SATA-дисками.
В 2020 году в рамках регулярного плана мы переаттестовали облако по 152-ФЗ до второго уровня защищенности включительно. Сертификаты действительны до лета 2023 года. В облаке есть отдельный аттестованный типовой сегмент виртуальных машин. Ежегодно OnCloud.ru успешно проходит «экзамен» на устойчивость к хакерским атакам – Pentest. На страже облака стоят IPS/IDS – системы обнаружения и предотвращения вторжений. IPS мониторит и анализирует инциденты информационной безопасности, IDS же блокирует нелегитимные сетевые соединения и доступы. В OnCloud.ru есть Next-Generation Firewall (NGFW) — полностью интегрированные межсетевые экраны с ориентацией на защиту от любых угроз. Благодаря этому решению ресурсы в облаке находятся под защитой от угроз независимо от факта проведения атак на него.
Летом 2020 года мы подтвердили партнерство с Lenovo и Huawei, развили направление мультивендорной поддержки оборудования, начали сотрудничать с отечественными и зарубежными гиперскейлерами. Это позволило нам создать новое направление – Multicloud, о котором я и хотел рассказать.
Мультиоблако (multicloud) – решение, позволяющее получать ресурсы от разных поставщиков или на разных платформах при построении единой интегрированной инфраструктуры.
У нас имеются партнерские соглашения с гиперскейлерами, и мы используем не только ресурсы нашего облака OnCloud.ru, но и ресурсы облачных платформ теперь уже наших партнеров, а не конкурентов, – Mail.ru, Yandex, Alibaba, AWS. Мы дорабатываем наш портал управления, чтобы ресурсы партнеров можно было объединить в рамках единой консоли. Сервисы с партнерских платформ доступны по принципу «единого окна», а сами партнеры получили дополнительный канал реализации своих сервисов в лице нашей компании.
В мультиоблачной архитектуре конструктор из решений от разных сервис-провайдеров расширяет возможности облака. Развязываются руки не только в техническом плане, но и в финансовом. Появляется возможность кастомно закрывать нетипичные задачи.
Как показывает практика, у нас получается дополнять решения от разных сервис-провайдеров экспертизой и компетенциями – мы уже не один год помогаем компаниям правильно мигрировать, разворачивать сервисы на любых типах платформ. Реализация ресурсов наших партнеров «по цеху» в рамках мультиоблачных кейсов происходит через нас. На данный момент есть уже несколько выполненных кейсов и много проектов в работе. Десятилетний опыт с проектами любого масштаба позволяет нам называть себя экспертами в межплатформенной интеграции.
А еще с помощью решений Mail Cloud Solutions (MCS), нашего партнера, мы можем строить приватные облака полностью в рамках программы импортозамещения, так как платформа входит в реестр российского ПО. Также мы поддерживаем множество разработок, которые созданы исключительно на российском рынке.
Совсем недавно у нас появился тестовый кластер GPU. Кластер развернут на видеокартах NVIDIA Tesla T4, основанных на графических ускорителях последнего поколения. Из него мы можем предоставлять виртуальные серверы с этими видеокартами и со всеми необходимыми лицензиями вендора, чтобы, например, развернуть с ними VDI или виртуальные серверы. Если у компании есть потребность в индивидуальном решении с GPU, мы не отказываем. Теперь наше облако обладает достаточной производительностью, чтобы служить в качестве среды для производства и дистрибуции тяжелого и технически требовательного контента.
Оглядываясь назад, самым сложным этапом я бы назвал, наверное, старт облака, когда мы изобретали велосипед с нуля. Мы уже умели рассчитывать финансовую модель облачных услуг, но на выяснение всех нюансов и подводных камней облачных сервисов потребовалось несколько лет. Параллельно мы всегда стремились к индивидуальному кастомному сервису. Небольшими шажками мы осилили путь к лидирующим позициям в облачном сегменте рынка. Сейчас мы с легкостью выводим на рынок новые услуги как в самом облаке OnCloud.ru, так и на смежных платформах, развиваем новые направления и привлекаем все больше партнеров и заказчиков.
И вот уже 10 лет мы с командой изучаем потребности заказчиков, их инфраструктуру, а затем делаем большие и красивые облачные проекты. Да, оценить проект можно уже только с заказчиком и то через год-другой. Быть облачным архитектором — это все равно что быть универсальным айтишником: необходимо обладать системным мышлением и охватывать сразу несколько сфер. Но самое большое удовольствие в профессии — это видеть, как архитектурные проекты, над которыми ты работал, начиная с одной лишь идеи, воплощаются в жизнь большими командами.
Освоение рынка мы начинали с проектирования архитектуры и разработки сервисной модели будущего OnCloud.ru. Достаточно долго решали, на чем будем строить и за сколько продавать. Как ни странно, с технической составляющей вопросов возникало меньше, чем с выведением модели расчета себестоимости проекта. Ориентиров было мало, разве что за рубежом. Поэтому создавали велосипед с нуля. Забегая вперед, могу сказать, что получился у нас не велосипед, а целый космический корабль.
«Начинка» OnCloud.ru
Выбор серверного оборудования
Подавляющая масса существовавших на тот момент провайдеров по какой-то причине строила свои решения на блейд-серверах. Мы сделали несколько подходов к расчетам, оценили себестоимость такого решения и избрали иной путь. К 2011 году у нас появился кластер на больших четырехпроцессорных серверах (HPE DL580), который в общей сложности прослужил нам восемь лет с учетом апгрейдов. В среднем за это время мы заменяли каждый сервер порядка двух раз. Но благодаря четырехпроцессорным серверам мы не только сэкономили в части себестоимости, но и получили технический профит, имея возможность предоставлять заказчикам большие виртуальные машины.
На блейд-серверах конкуренты могли предложить ограниченное число ядер виртуальных процессоров и объема оперативной памяти – как правило, 16 vCPU объемом до 128 Гб RAM (два стандартных XEON по 8 ядер). Мы же могли предоставить сразу 40 vCPU с удвоенным объемом RAM, и долгое время позиционировали это как конкурентное преимущество. Списали свой кластер лишь в 2019 году – когда подошел к концу его срок полезного использования. К тому же, VMware, наш постоянный партнер по виртуализации, на тот момент прекратил его поддерживать.
Системы хранения данных
К 2011 году мы реализовали приличное число проектов и предоставляли оборудование в аренду. СХД, в числе которых было несколько систем от IBM: DS 4700 и 3500 на SATA и SAS-дисках, остались в резерве с наших прошлых проектов. То есть, не вкладывая ни рубля, «Онланта» могла поддерживать два класса хранения – SATA и SAS. Но вскоре мы с коллегами пришли к выводу, что оборудование слабовато и апгрейды все же потребуются.
Роль SATA-дисков мы ограничили бэкапами. А модернизация СХД заключалась в покупке Hitachi HUS VM с SAS и SSD-дисками. В 2012 году она давала довольно приличную производительность по сравнению с другими продуктами на рынке, самостоятельно распределяя данные с помощью технологии тиринга по двум классам хранилищ (SAS и SSD). На тот момент это было хорошей инвестицией. В дальнейшем, наращивая классы хранения, мы смогли с помощью масштабирования сервиса сократить стоимость ресурсов для заказчиков примерно вдвое при росте инфляции и курса доллара. Сделали хорошо и себе, и заказчикам.
Сеть
Сеть была еще одним тонким местом в архитектуре облака, которое мы пытались устранить. Сетевое оборудование у нас также осталось с прошлых проектов. Это были простые гигабитные коммутаторы Cisco, с которых мы не раздумывая перешли на Juniper 10 Гбит, как только к нам пошли заказчики. К слову, эти коммутаторы до сих пор используются у нас в сетях Colocation.
С апгрейдом сети проблемы не закончились, и мы столкнулись с DDoS-атаками. У нас был общий для всех заказчиков интернет-канал, который разделялся пропорционально их потребностям. То есть если атака шла на одного заказчика, то страдали все. При возникновении проблемы мы оперативно поменяли провайдера на того, кто использовал Cisco Arbor для защиты от DDoS-атак. Такой своеобразный ход конем одномоментно и навсегда избавил нас от этой проблемы.
Гипервизор
Здесь сомнений практически не было. Мы остановили свой выбор на гипервизоре от VMware, который обладал всего одним небольшим минусом – высокой ценой. Но плюсы с лихвой перекрывают этот изъян.
- Для нас это был абсолютно знакомый продукт, потому что мы неоднократно использовали его в проектах по аутсорсингу – соответственно на обучение инженеров дополнительные затраты не требовались.
- На VMware достаточно просто продавать облако благодаря программе лицензирования для сервис-провайдеров с гибким чеком по модели pay-as-you-go – сколько ресурсов мы заказчикам продали, за столько вендору и заплатим.
- Затраты на эксплуатацию абсолютно прозрачны. Если бы мы строили облако на альтернативном, бесплатном на тот момент ПО, то стоимость техподдержки для нас была бы непредсказуемой. А третьей линии поддержки скорее всего бы не предвиделось. Скорее всего пришлось бы остаться со всеми возможными проблемами один на один.
Интегральный SLA
Сейчас, когда все провайдеры предлагают доступность своего облака, которая закрепляется в SLA на уровне гипервизора, мы свое облако позиционируем в спектре интегральной доступности: на уровне гипервизора, сети и систем хранения данных. За 2020 год была абсолютная доступность по всем трем параметрам на уровне 100%. Никакой секретной формулы расчета SLA нет, но мы отвечаем перед заказчиками финансово не по одному, а сразу по трем параметрам (гипервизор, сеть и СХД) – как только один из них проседает, это отражается на общем уровне доступности. Чтобы просадки не происходило, все элементы облака у нас задублированы, и даже если проводятся технические работы, оно остается доступным. Например, не так давно мы практически полностью заменили все сетевое оборудование в кластере виртуализации, и сделали это без остановок работы сервиса и простоев. Заказчики даже не заметили полного апгрейда сетевого оборудования.
2012 год – первый большой проект
Первый серьезный проект случился у нас сразу после старта облака, и мы набили «базовые шишки первопроходца», благодаря чему на голову повысили уровень нашего сервиса буквально за два года.
К нам пришел крупный заказчик, и для него мы делали комплексный облачный проект, а не просто выделяли набор ресурсов в аренду, как это было ранее. У заказчика стояла задача перенести вовне среду разработки, чтобы в ней могли работать внешние разработчики без доступа ко внутренней сети заказчика. Мы предоставили виртуальные серверы, весь необходимый стек лицензий Microsoft, лицензию на базу данных Oracle и сервис WebEx для коммуникации удаленных разработчиков. Это был готовый комплект сервисов для удаленной работы распределенной команды. С помощью этого проекта мы научились предоставлять не разрозненные сервисы, а комплексные услуги с фиксированными показателями доступности.
Первые «грабли» — стоимость реализации или «все познается в сравнении»
С правильной математической моделью стоимости проекта мы «бодались» около года. Стремились максимально точно всё рассчитать, учесть окупаемость всех затрат (закупка оборудования, техподдержка, лицензии, размещение в ЦОД, трудозатраты и др.). Со стороны заказчикам казалось, что выходит дорого. Нам не всегда сразу удавалось выйти на доходность в проекте. Приходили новые заказчики, аналогичные нам игроки рынка тоже только нащупывали цены, и нам бывало непросто донести заказчикам, сколько реально стоит облако.
Одной стороной медали было сравнение с «конкурентами». Здесь важно понимать, что нашими конкурентами были не только те, кто предлагал облака. В начале 2010-х годов на рынке было очень много компаний, которые занимались в основном хостингом сайтов, а в довесок собирали непонятные «самодельные» облака и предлагали виртуальные серверы. По качеству технической реализации такие облака сильно проигрывали решениям от настоящих провайдеров, коими в то время могли называться немногие. Именно из-за таких игроков приходилось работать с возражениями «там дешевле». Облачный сегмент рынка тогда еще только формировался, и мы занимались просветительской работой, объясняя, почему дешевое – не всегда хорошее, и почему результат от «недооблачных» провайдеров в конечном итоге их разочарует. С конкурентами нашего уровня мы сравнивали себя комплексно – и по цене, и по SLA, и по техническим решениям.
Вторая сторона медали – сравнение on premise-инфраструктуры с облачной. Заказчики по какой-то причине считали стоимость облака без учета множества сопутствующих затрат. В их видении инфраструктуру может поддерживать один инженер в штате, работая в режиме 24/7. Мы объясняли, что один инженер не может заменить несколько линий поддержки, Service Desk, группу мониторинга доступности, группу экспертов по каждому направлению и дежурную смену. А без всех этих элементов поддержки качество будет неудовлетворительным. Кроме CAPEX на инфраструктуру есть еще и переменные издержки на электроэнергию и работу охлаждающего оборудования, которое порой потребляет не меньше самих серверов.
Так мы защищали каждую цифру проекта и детально прописывали каждую статью расходов в отдельном документе, который разрабатывался чуть ли ни специально для ИТ-директоров, чтобы те могли предметно защищать бюджет на переезд в облако. В конечном итоге, когда все разбиралось по составляющим, приходило озарение, что от облака есть не только технические или организационные, но и ощутимые финансовые плюсы. Для собственной инфраструктуры оборудование, как правило, закупается впрок. С облаком же прогнозировать потребность в ресурсах не надо, легко можно добавлять их при необходимости и так же легко отказываться от ненужных. Сегодня у всех моих коллег эти слова уже «отлетают от зубов».
Когда намерение переехать в облако уже достаточно серьезное, возникает второй вопрос: «В какое облако переезжать?» Нередко, выбирая с заказчиком подходящее решение между частным и публичным облаком, мы опирались на аргументы из данной таблицы. Каждая модель по-своему прекрасна.
| Публичное облако(public cloud) | Частное облако (private cloud) | |
| Плюсы |
|
|
| Минусы |
|
|
Если после приведенных аргументов все равно остаются архитектурные сомнения, мы предлагаем гибрид публичного облака либо с инфраструктурой заказчика, либо с нашим частным облаком. Гибридная модель суммирует плюсы публичной и приватной модели. Но уже сегодня на рынке есть качественно новая прорывная модель, о которой я поведаю чуть позднее.
2014 – второе плечо
До 2014 года наше облако развивалось в рамках одного дата-центра – SAFEDATA. Затем поступил запрос от рынка на географически распределенное облако, и мы приняли решение развернуть второе плечо в дата-центре IXcellerate. Это позволило организовать для заказчиков резервный ЦОД на базе нашего облака. Мы обеспечили качественную сохранность резервных копий, организовав резервное копирование «крест-накрест». Обеспечили сетевую связность между площадками, арендовав темную оптику, пущенную двумя разными трассами.
2016 – муки выбора резервного копирования
Чтобы выбрать подходящее решение для резервного копирования, мы развернули целый исследовательский проект с чек-листами и проверками вендоров по ним. Первоначально мы использовали IBM Tivoli Storage Management, который нам достался практически бесплатно вместе с ленточной библиотекой. Решение было лишено портала управления, все приходилось делать через заявки, а скорость бэкапирования нас расстраивала. На рынке на тот момент были более интересные решения – от Veeam, Commvault, Veritas, Avamar. У двух последних не было провайдерской системы лицензирования с оплатой по факту потребления. Нам бы дорого обошелся перевод всех виртуальных машин на новый софт в виде разовой инвестиции. А между двух оставшихся мы выбрали Veeam, потому что, во-первых, у него есть и искомая система лицензирования, а во-вторых, он обеспечивал максимальную скорость бэкапирования и восстановления из резервных копий. Более того, продукт хорошо зарекомендовал себя на российском рынке, вендор сразу позиционировал его как облачный и предложил понятный RoadMap. Раньше мы брали плату только за объем бэкапов. Теперь появилась дополнительная строка в счетах – оплата лицензий.
Только за счет перехода на Veeam мы отказались от ленты, все бэкапы хранили на СХД, в три раза увеличили скорость восстановления из резервных копий и частично передали управление бэкапами в руки заказчиков через портал самоуправления от вендора.
2018 год – портал управления облачными ресурсами
Третьим серьезным этапом развития нашего облака было создание портала управления облачными ресурсами, где можно вести биллинг, документооборот, заказывать сопутствующие и дополнительные сервисы и общаться с менеджерами облачного проекта. Мы используем платформу как внутри компании, так и с некоторыми заказчиками. Руководители проектов на ней готовят счета, ведут учет потребления ресурсов заказчиков. Сейчас работаем над нашей собственной разработкой – Корпоративной Системой МультиОблачных Сервисов (КОСМОС), – которая дает возможность управлять не только различными гипервизорами, но и облачными платформами, в числе которых, как вы можете догадаться, будет не только OnCloud.ru. Совсем скоро начнем подключать к ней партнеров по новому направлению, о котором я расскажу чуть позже.
2020 год – OnCloud.ru сейчас
Сейчас облако OnCloud.ru географически распределено на два связанных между собой кластера виртуализации – в ЦОД IXcellerate и DataSpace TIER III. SAFEDATA мы теперь используем в качестве площадки для пилотов и размещения оборудования заказчиков, требовательных к цене, но не требовательных к сертификатам ЦОД. Кластер в IXcellerate построен на процессорах E5V4 c частотой 2,4 GHz, и в ближайшие полгода мы заменим их на процессоры GOLD второго поколения с частотой 3 GHz. Площадка сертифицирована по 152-ФЗ. DataSpace — один из лучших ЦОДов Москвы. У нас там большие четырехпроцессорные серверы с 3 GHz на XEON GOLD. Наш кластер построен на процессорах GOLD первого поколения с частотой 3 GHz.
В обоих ЦОД мы поддерживаем два класса хранения SAS (1 IOPS/GB) и SSD (5 IOPS/GB), для SAS используется СХД INFINIDAT, SSD размещено на NetApp FAS-серии. На первый квартал 2021 года запланирован переход с NetApp FAS-серии на Huawei DORADO V6 на NVME-дисках и последующее внедрение NVMe over Fabric. Бэкапим крест-накрест на базе вендорского решения Veeam Backup & Replication. Резервные копии храним в СХД Lenovo серии DE с SATA-дисками.
Информационная безопасность
В 2020 году в рамках регулярного плана мы переаттестовали облако по 152-ФЗ до второго уровня защищенности включительно. Сертификаты действительны до лета 2023 года. В облаке есть отдельный аттестованный типовой сегмент виртуальных машин. Ежегодно OnCloud.ru успешно проходит «экзамен» на устойчивость к хакерским атакам – Pentest. На страже облака стоят IPS/IDS – системы обнаружения и предотвращения вторжений. IPS мониторит и анализирует инциденты информационной безопасности, IDS же блокирует нелегитимные сетевые соединения и доступы. В OnCloud.ru есть Next-Generation Firewall (NGFW) — полностью интегрированные межсетевые экраны с ориентацией на защиту от любых угроз. Благодаря этому решению ресурсы в облаке находятся под защитой от угроз независимо от факта проведения атак на него.
Летом 2020 года мы подтвердили партнерство с Lenovo и Huawei, развили направление мультивендорной поддержки оборудования, начали сотрудничать с отечественными и зарубежными гиперскейлерами. Это позволило нам создать новое направление – Multicloud, о котором я и хотел рассказать.
Multicloud в партнерстве с гиперскейлерами
Мультиоблако (multicloud) – решение, позволяющее получать ресурсы от разных поставщиков или на разных платформах при построении единой интегрированной инфраструктуры.
У нас имеются партнерские соглашения с гиперскейлерами, и мы используем не только ресурсы нашего облака OnCloud.ru, но и ресурсы облачных платформ теперь уже наших партнеров, а не конкурентов, – Mail.ru, Yandex, Alibaba, AWS. Мы дорабатываем наш портал управления, чтобы ресурсы партнеров можно было объединить в рамках единой консоли. Сервисы с партнерских платформ доступны по принципу «единого окна», а сами партнеры получили дополнительный канал реализации своих сервисов в лице нашей компании.
В мультиоблачной архитектуре конструктор из решений от разных сервис-провайдеров расширяет возможности облака. Развязываются руки не только в техническом плане, но и в финансовом. Появляется возможность кастомно закрывать нетипичные задачи.
Как показывает практика, у нас получается дополнять решения от разных сервис-провайдеров экспертизой и компетенциями – мы уже не один год помогаем компаниям правильно мигрировать, разворачивать сервисы на любых типах платформ. Реализация ресурсов наших партнеров «по цеху» в рамках мультиоблачных кейсов происходит через нас. На данный момент есть уже несколько выполненных кейсов и много проектов в работе. Десятилетний опыт с проектами любого масштаба позволяет нам называть себя экспертами в межплатформенной интеграции.
А еще с помощью решений Mail Cloud Solutions (MCS), нашего партнера, мы можем строить приватные облака полностью в рамках программы импортозамещения, так как платформа входит в реестр российского ПО. Также мы поддерживаем множество разработок, которые созданы исключительно на российском рынке.
Про GPU
Совсем недавно у нас появился тестовый кластер GPU. Кластер развернут на видеокартах NVIDIA Tesla T4, основанных на графических ускорителях последнего поколения. Из него мы можем предоставлять виртуальные серверы с этими видеокартами и со всеми необходимыми лицензиями вендора, чтобы, например, развернуть с ними VDI или виртуальные серверы. Если у компании есть потребность в индивидуальном решении с GPU, мы не отказываем. Теперь наше облако обладает достаточной производительностью, чтобы служить в качестве среды для производства и дистрибуции тяжелого и технически требовательного контента.
В заключение
Оглядываясь назад, самым сложным этапом я бы назвал, наверное, старт облака, когда мы изобретали велосипед с нуля. Мы уже умели рассчитывать финансовую модель облачных услуг, но на выяснение всех нюансов и подводных камней облачных сервисов потребовалось несколько лет. Параллельно мы всегда стремились к индивидуальному кастомному сервису. Небольшими шажками мы осилили путь к лидирующим позициям в облачном сегменте рынка. Сейчас мы с легкостью выводим на рынок новые услуги как в самом облаке OnCloud.ru, так и на смежных платформах, развиваем новые направления и привлекаем все больше партнеров и заказчиков.
И вот уже 10 лет мы с командой изучаем потребности заказчиков, их инфраструктуру, а затем делаем большие и красивые облачные проекты. Да, оценить проект можно уже только с заказчиком и то через год-другой. Быть облачным архитектором — это все равно что быть универсальным айтишником: необходимо обладать системным мышлением и охватывать сразу несколько сфер. Но самое большое удовольствие в профессии — это видеть, как архитектурные проекты, над которыми ты работал, начиная с одной лишь идеи, воплощаются в жизнь большими командами.
У нас есть для вас вакансии!
- Ведущий инженер систем мониторинга
- Системный архитектор (VMware)
