Public cloud что это

Простыми словами: Разбираемся с «облачными» услугами

Раньше, чтобы развернуть какое-либо приложение, приходилось покупать и настраивать собственные физические серверы. Такой подход обладал большим количеством недостатков, например, если для нормальной работы приложения ему достаточно «полтора сервера», платить все равно приходилось за два – расходы на содержание и обслуживание инфраструктуры оказывались неоправданно высокими.

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

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

«Однако инженеры и исследователи быстро поняли, что такой подход плохо масштабируется, – говорит Прадип Падала (Pradeep Padala), учредитель ContainerX. – Поэтому начались поиски альтернативных способов проведения вычислений: начали разрабатываться распределенные системы, объединяющие в себе мощности огромного количества компьютеров».

Появились такие академические проекты, как Condor – это распределённая сеть компьютеров, развернутая в Висконсинском университете в Мадисоне. На сегодняшний день там установлено 350 настольных UNIX-станций, которые предоставляют доступ для работы пользователям со всего мира. Были и другие проекты, например distributed.net и SETI@home – на тот момент эта идея была инновационной, да и заниматься поиском внеземных цивилизаций тоже достаточно интересно.

Затем появился БАК от ЦЕРН, который породил бессчётное количество исследовательских проектов, на которые уходили миллиарды долларов. Как часть всего этого движения в моду вошли грид-вычисления. Определение грид-вычислений очень близко к тому, что мы называем «вычисления как услуга». В качестве примера можно привести Globus Toolkit.

Одновременно со всем этим, в технической индустрии, VMware и Xen занимались популяризацией виртуализации, которая позволяла запускать сразу несколько машин на одной физической машине. Это преобразило IT-индустрию, а простота использования привлекла внимание стартапов, которым было сложно покупать и содержать свое собственное оборудование.

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

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

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

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

Свои вычислительные ресурсы поставщик объединяет в пул, чтобы их можно было динамически перераспределять в соответствии с нуждами пользователей – это так называемый принцип множественной аренды (Multi-tenancy). Возникает ощущение независимости от местоположения, когда заказчик не знает, где именно находятся ресурсы, но может определять их расположение на абстрактном уровне (страна или регион).

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

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

Что касается стоимости услуг, то процесс их формирования может быть достаточно сложным, а ценник изменяться от поставщика к поставщику. Джейсон Лемкин (Jason M. Lemkin), партнер SaaStr Ventures, считает, что если ваш продукт лучше, то не стоит стесняться завышать цену.

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

Помимо характеристик выделяют еще три модели обслуживания: программное обеспечение как услуга (SaaS), платформа как услуга (PaaS) и инфраструктура как услуга (IaaS). Отличаются они степенью предоставляемого контроля.

В случае IaaS клиент получает возможность использовать облачную инфраструктуру по своему усмотрению и самостоятельно управлять ресурсами обработки и хранения, а также сетями. «Пользователь может создать виртуальную инфраструктуру и изменить её в любой момент», – говорит консультант Эван Лейт (Ewan Leith). Аутсорсинг стал популярным еще в те времена, когда компании хотели использовать компьютеры, но не хотели нести издержки по их содержанию и обслуживанию. По этой причине мы сегодня имеем технологию виртуализации.

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

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

Второй слой – это платформа как услуга или PaaS. При переходе от модели IaaS к модели PaaS (Platform as a Service) дополнительно на сторону облачного провайдера передается управление операционными системами и базами данных. В этом случае клиентам не приходится думать о дисковом пространстве, которое необходимо выделить, и распределении нагрузки между серверами. Примерами PaaS являются Google App Engine, Heroku и Force.com.

Программное обеспечение как услуга (SaaS) – последний уровень облачных вычислений, обычно дополняющий PaaS. Это программное обеспечение для конечного пользователя, например, обеспечивающее работу с электронной почтой или текстом. Очень часто оно предоставляется по подписке. Примерами SaaS могут служить Google Apps, Salesforce.com и Business Productivity Online Suite от Microsoft.

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

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

Частное облако (private cloud) – это инфраструктура, которая располагается в пределах одной организации. Данная модель развертывания создана с целью удовлетворить потребности внутреннего рабочего персонала, обеспечивая высокий уровень безопасности данных. Частное облако создается, например, для обеспечения какой-либо дочерней компании сервисом корпоративной почты.

Публичное облако (public cloud) – это инфраструктура, предназначенная для свободного использования широкой публикой. Этот тип облака может находиться в собственности, например, коммерческих, научных и правительственных организаций.

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

Общественное облако (community cloud) имеет схожие черты с частным и публичным облаком. Это вид инфраструктуры, предназначенный для использования конкретным сообществом потребителей из организаций, имеющих общие задачи. Общественное облако может управляться организациями третьей стороны и существовать как внутри, так и вне юрисдикции владельца. В этом случае ответственность по содержанию облака перекладывается с плеч организаций-членов на все сообщество целиком.

Гибридным же облаком (hybrid cloud) называют композицию из двух или более типов облаков, которые связываются между собой стандартизированными технологиями передачи данных. Очень часто компании запускают бизнес-критические приложения в приватном облаке, в то время как остальные приложения работают в публичном облаке.

Источник

Что такое частные, публичные и гибридные облака: в чем разница и куда перенести сервисы компании

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

Типы облаков: частные, публичные и гибридные

Сначала разберемся, что понимают под частным, или приватным, публичным, или общедоступным, и гибридным облаком.

Мощность готовых виртуальных серверов можно менять: если снизилась нагрузка на один, его ресурсы можно тут же передать другому. Подробнее об этом — в статье о виртуализации в облаке.

Итак, что же называют частным, публичным и гибридным облаком?

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

Публичное облако — это когда виртуальная IT-инфраструктура облака принадлежит провайдеру и предоставляется компании-клиенту в аренду. С точки зрения экономики публичное облако это сервис, а именно — виртуальная инфраструктура как сервис. Провайдер выделяет пул виртуальных ресурсов в том объеме, в котором они нужны компании-клиенту, которая запускает на них свои приложения.

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

Гибридные облака — когда часть инфраструктуры размещена в публичном облаке провайдера, а часть в частном облаке вашей компании. В более широком смысле: когда собственная часть инфраструктуры компании — это даже не частное облако, а обычная, необлачная (традиционная, «железная») инфраструктура, не задействующая виртуализацию. Если она работает в паре с публичным облаком, то такую IT-инфраструктуру тоже можно назвать гибридным облаком. Например, в гибридной инфраструктуре традиционные локальные системы хранения данных могут передавать данные в публичное облако для обработки.

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

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

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

Давайте сравним частные и публичные облака по нескольким параметрам.

Эластичность или масштабируемость

Это возможность быстро выделять из пула виртуальных ресурсов нужные компании мощности. Здесь частное облако уступает публичному.

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

Бесперебойность работы сервисов и доступа к приложениям

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

В частном облаке компании нужно организовать резервное копирование инфраструктуры самостоятельно. Это важно, чтобы не потерять данные, если оборудование, на котором развернуто облако, выйдет из строя. Для обеспечения полной надежности частное облако разворачивают на базе 2-3 распределенных дата-центров, что требует значительных расходов.

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

Инновации

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

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

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

Например, это уже готовые базы данных, системы обработки big data на базе Hadoop, Spark и подобных технологий, системы машинного обучения, Kubernetes как современная платформа для построения микросервисов и многое другое. И все это можно развернуть буквально за пару кликов.

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

Правда, есть исключения: если строить частное облако с помощью провайдера, можно получить доступ к его PaaS-сервисам и другим инновациям, которые эксперты провайдера помогут внедрить в облачную инфраструктуру вашей компании.

Основные отличия частных и публичных облаков

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

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

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

С частными облаками есть два варианта:

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

Ресурсы почти всегда покупают у провайдера по модели pay-as-you-go — ваша компания платит только за те мощности, которые использует. Например, у вас распродажа, выросло число покупателей и нагрузка на сервисы — вы получаете в облаке больше ресурсов, платите больше. Число покупателей уменьшилось, нагрузка упала — арендуете меньше мощностей и платите меньше, не переплачивая за простаивающие ресурсы.

В VK к аренде облачного сервера бесплатно добавлены публичные IP-адреса, безлимитный трафик, балансировщик нагрузки и мониторинг параметров виртуальных машин.

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

Какое облако лучше использовать: частное, публичное или гибридное

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

Частные облака чаще всего вынуждены использовать те компании, которые подпадают под специальные требования безопасности, иногда вытекающие из прямых требований законодательства и регуляторов. Многие такие требования тянутся из прошлого — в начале 2010-х годов технологии публичных облаков были несовершенны и не так безопасны, как сегодня, когда их используют многие организации, работающие с приватными данными, и даже банки.

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

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

Примеры использования гибридных облаков:

Персональные данные перед отправкой из частной инфраструктуры в публичное облако можно анонимизировать, если этого требует регулятор. Например, отправлять в облако ID-номер вместо Ф.И.О. и других идентифицирующих данных. ID сопоставляется только во внутренней базе, поэтому при передаче данные остаются анонимными. Также можно отправлять в облако информацию, обезличенную за счет обобщения, вроде «15% выборки 20-25 лет, 30% держат дома кота».

Источник

Публичные облака в российских реалиях. Часть 1. IaaS

Облачные технологии, инфраструктура как сервис и платформенные сервисы из нишевых решений давно перешли в стандарт де-факто для размещения приложений не только стартапов, но и крупных финансовых компаний, госкомпаний, автомобильных гигантов и популярных игровых сервисов. Компании Netflix и Spotify, Dropbox и Instagram начинали свой путь на облачных ресурсах, не инвестируя в собственную инфраструктуру. Совокупная выручка мировых поставщиков облачных услуг в 2019 году превысила бюджет Российской Федерации. В этой статье мы рассмотрим рынок облачных услуг в России. Мы сравним его с мировыми трендами и определим — опережаем мы или отстаём от мировых лидеров в развитии облачных услуг и насколько.

Как все начиналось

Публичные облака в РФ появились как эволюционное развитие собственной инфраструктуры виртуализации. Следуя за трендами в корпоративном сегменте, они были основаны на привычных крупным заказчикам технических решениях, таких как Microsoft Hyper-V и VMware vSphere, c установкой портала самообслуживания (Windows Azure Pack или vCloud Director for SP). Клиенты получали понятный им функционал: знакомые инструменты управления, мониторинга и резервного копирования – всё, с чем клиенты работали каждый день.

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

Инфраструктура, обеспечивающая ресурсы платформы виртуализации, должна быть в списке совместимой и поддерживаемой. Для этого чаще всего используются серверы именитых производителей (Dell EMC, HPE, Lenovo, Huawei и др.) и выделенные СХД, подключаемые как блочные устройства по протоколу FС. Приобретение и поддержка такой инфраструктуры – это основная статья затрат в эксплуатации облачной платформы. Функционал и развитие облачной платформы целиком определяется выбранным вендором.

Параллельно стали появляться публичные облака, как эластичная инфраструктура, от нетипичных игроков на рынке из таких индустрий, как retail (Amazon), e-commerce (Alibaba) и интернет (Google).

Используя наработки на базе собственных on-premise технологий, в популярного поставщика облачных услуг превратилась компания Microsoft с их платформой Azure.

Большинство игроков частично использовали решения open-source. Например, Amazon использовал гипервизор Xen, а сейчас переключился на KVM. Кто-то использовал платформу с открытым исходным кодом OpenStack, дорабатывая ее под свои нужды.

Запуск решения на базе готовой платформы с открытым исходным кодом позволяет сократить время выхода на рынок, особенно если нет достаточно зрелых технологий, на базе которых можно построить собственную инфраструктуру. Вокруг популярной платформы обычно довольно зрелая экосистема с необходимым набором утилит для организации DevOps конвейера, мониторинга, автоматизации и оркестрации. Такой платформой можно считать Mail.ru Cloud Solutions (MCS) на базе Openstack.

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

Немного о сравнении

Мы сравним эти два подхода к построению облачной инфраструктуры от компаний Mail.ru Group и Яндекс. Остановимся только на ключевых отличиях и посвятим сравнению цикл статей. В первой статье мы начнем с IaaS, во второй статье планируем остановиться на сетевых сервисах и PaaS, в третьей – на SaaS, мониторинге и сервисной поддержке.

Мы ограничили состав участников сравнения указанными платформами, потому что они соответствуют нашему представлению о современном поставщике облачных услуг, которое заключается в следующих критериях:

На каждом этапе сравнения будем брать ориентир на облачную платформу Microsoft Azure. Это поможет нам понять, насколько компании Яндекс и Mail.ru Group приблизились в технологическом аспекте к одному из мировых лидеров в области предоставления облачных услуг.

Вместо Microsoft Azure могла быть любая другая платформа из крупных игроков. Мы предпочли ее по двум причинам:

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

Рис. 2. Архитектура ЦОД ближайшего к России региона Azure

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

Важным преимуществом платформ MCS и Яндекс.Облако по сравнению с Microsoft Azure является наличие дата-центов на территории Российской Федерации. Если ваш сервис должен соответствовать требованиям Федерального закона «О персональных данных» (ФЗ-152), то развертывание его в облаке от зарубежного поставщика потребует внедрения дополнительных технических решений, так как первичная обработка персональных данных (ПДн) должна происходить на территории Российской Федерации и в дальнейшем данные должны передаваться по защищенным каналам связи. Невыполнение требований о защите ПДн может привести к блокировке доступа к сервису Роскомнадзором.

Рис. 3. Архитектура ЦОД платформы MCS

Облачная платформа от Mail.ru Group размещена на территории города Москвы в двух арендованных дата-центрах: DataLine на Коровинском шоссе и DataPro на Авиамоторной улице. Последний имеет сертификацию Uptime Institute. Между дата-центрами организован канал 40 Гбит/с с длиной трассы около 25 км. Это позволяет нам рассматривать оба дата-центра, как площадки для построения высокодоступных (High-Availability) кластеров с узлами в каждом из дата-центров с синхронной репликацией данных между ними, но без так называемой кворум площадки.

Сетевая архитектура облака имеет растянутые L2 сети между площадками. Это дает нам возможность использовать технические средства отказоустойчивости: Keepalived, Veritas Cluster Server, Microsoft Windows Server Failover Cluster и прочие. Такие средства увеличивают наши шансы на миграцию большинства legacy решений в IaaS данного поставщика. При этом мы сохраняем отказоустойчивость архитектуры, которую мы использовали на собственном оборудовании on-premise.

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

При отсуствии официальной сертификации платформы под SAP HANA, компания Mail.ru Group может установить по запросу клиента сертифицированные SAP HANA Appliance и подключить их к клиентскому VPC внутри облака MCS. Это позволит не потерять поддержку на продуктивные среды SAP продуктов и воспользоваться всеми преимуществами облачной инфраструктуры для остальных сред.

Аналогичным примером может быть установка оборудования для организации защищенных каналов связи с помощью национальных стандартов криптографии (например, алгоритмов шифрования ГОСТ Р 34.12-2015).

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

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

Рис. 4. Архитектура ЦОД платформы Яндекс.Облако

Облако от компании Яндекс в свою очередь размещено в трех собственных дата-центрах, расположенных в Московской, Владимирской и Рязанской областях. Каждый ЦОД проектировался и строился самостоятельно. Яндекс эксплуатируют их с соблюдением международных и собственных стандартов. Надо отметить, что опыт в построении дата-центов у Яндекса действительно имеется.

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

Три полноценные площадки позволяют разворачивать любые отказоустойчивые архитектуры. Однако большая удаленность, порядка 200 км друг от друга, не позволяет развернуть кластера высокой доступности (High-Availability) с узлами в каждом из дата-центров с возможностью синхронной репликации данных между ними. Также отсутствие L2 между дата-центрами ограничивает нас в возможности развернуть здесь legacy решения.

Архитектура IaaS платформы

Модель обслуживания Infrastructure-as-a-Service (IaaS), как описано в стандарте NIST, это возможность предоставить клиенту вычислительные, сетевые ресурсы и ресурсы хранения данных, на базе которых клиент сам размещает и управляет операционными системами и приложениями. Современная IaaS платформа включает в себя гипервизор, предоставляющий вычислительные ресурсы, программно-определяемую систему хранения данных software-defined storage (SDS) для размещения данных и программно-определяемую сеть software-defined networking (SDN) как средство организации сетевого доступа к ресурсам IaaS.

Референтная платформа нашего сравнения, Azure от компании Microsoft, начинает свою историю еще в далеком 2003-м году с приобретения компании Connetix и их продукта Virtual PC с целью догнать конкурента VMware и их продукт GSX Server, вышедший двумя годами ранее. Спустя время продукт Virtual PC интегрировали в состав платформы Windows Server. Он появился в версии 2008, но только к версии 2012 были реализованы SDS на базе Scale-Out File Server и Storage Spaces и SDN на базе Hyper-V Network Virtualization. Это позволило построить целиком программно-определяемую платформу IaaS без привязки к аппаратным возможностям СХД или оборудования ЛВС.

Платформа Azure поддерживается большинством современных DevOps утилит как для построения конвейера непрерывного развертывания, так и для автоматизации рутинных задач. У Azure функциональный веб-интерфейс и подробно документированный API. Все крупные игроки по разработке платформ автоматизации и управления облачными платформами поддерживают Azure. Утилита командной строки Azure CLI доступна как расширение PowerShell и как отдельная утилита для платформ Windows, Linux и MacOS X.

Компания Mail.ru Group для своего облака взяла наработки платформы OpenStack. К 2020 году компания перешла на полностью собственный дистрибутив, который не связан с open-source версией платформы. В качестве гипервизора используется функция ядра ОС Linux Kernel-based Virtual Machine (KVM), основным разработчиком которого является компания Red Hat, ныне часть IBM. Объем доработок KVM, которые выполнили разработчики MCS, компания не раскрывает. В части SDS для блочных устройств и сервиса NFS используется решение CEPH – его тоже дорабатывала команда MCS. Для объектного хранилища S3 были переиспользованы технологии облачного диска Mail.ru Group. В качестве сетевого решения применяется решение на базе OpenvSwitch, однако механизмы управления Control plane были серьезно переработаны. Это дало жизнь проекту Sprut.

Для управления платформой MCS был реализован отдельный портал, в котором реализованы самые популярные сервисы, а также доступен нативный интерфейс OpenStack Horizon. Для тонкой настройки сервисов предоставляется доступ к OpenStack CLI или OpenStack API. Есть также возможность использовать решение Infrastructure as Code (IaC) которое будет обращаться напрямую к API платформы. Работу с OpenStack поддерживает большинство систем управления конфигурацией, что упрощает встраивание облака MCS в DevOps конвейер и внешние системы управления облачными ресурсами.

Как было у Яндекса? Первую версию своей платформы компания разрабатывала для себя. Яндекс, так же, как и Mail.ru Group ориентировался на архитектуру и компоненты OpenStack. Однако, потом компания отказалась от нее. Было принято решение начать с «чистого листа. Яндекс переиспользовал базовые инфраструктурные компоненты, которые у них уже были. К ним компания дополнительно разработала недостающие модули и платформу управления.

В качестве гипервизора компания Яндекс также использует KVM. В его разработку инвестированы большие ресурсы. Решения SDS и SDN были разработаны компанией самостоятельно. SDS основан на собственной СУБД Yandex Database (YDB) для хранения мета-данных о размещении виртуальных машин и Network Block Storage (NBS) как сервиса предоставления блочных устройств виртуальным машинам, также YDB используется и в S3-совместимом решении в составе платформы. Яндекс, в отличии от MCS и Azure, не предлагает сервис NFS в составе услуг, рекомендуя развернуть его на базе виртуальной машины. В качестве SDN используется переработанная платформа OpenContrail. Её разрабатывали Juniper Networks, которая с недавнего времени входит в Linux Foundation, как платформа TungstenFabric.

Использование собственной платформы управления ограничивает возможности по встраиванию ресурсов Яндекс.Облака в конвейер DevOps или внешние системы управления облачными ресурсами. В настоящий момент заявлена поддержка IaC Terraform с помощью разработанного компанией провайдера. Ещё существует неофициальная поддержка работы с Ansible. Однако, среди популярных систем для управления Гибридными Облаками (Cloud Management Platforms) – таких как Red Hat CloudForms, Morpheus, Scalr, поддержка отсутствует. Компания также разработала и поддерживает свою собственную утилиту YC CLI для работы с платформой из командной строки с собственным набором команд.

Хранение данных

У MCS есть репликация блочных устройств между зонами доступности, что позволяет запустить виртуальную машину с теми же данными на любой из площадок, а также получить высокопроизводительный локальный диск NVMe или общее СХД по протоколу ISCSI. Azure предлагает репликацию объектных хранилищ как внутри зоны доступности, так и между зонами в пределах географического региона, а также сервис Azure Site Recovery для репликации блочных устройств. Обе платформы предоставляют сервис NFS.

В платформе Яндекс.Облако нет синхронной репликации блочных устройств между зонами доступности. Реплицируются только резервные копии и S3-хранилище. Репликация данных для Яндекс.Облака может быть реализована средствами приложения или СУБД. Отсутствие репликации блочных устройств связано с тем, что ЦОДы располагаются достаточно далеко и синхронная репликация будет вносить значительные задержки в дисковый ввод-вывод. Сервис NFS платформой Яндекс.Облако не предоставляется.

Образы виртуальных машин

В отличие от Azure, в MCS отсутствует возможность развернуть ВМ с использованием enterprise-level дистрибутива ОС Linux (RHEL, SLES, OEL). Платформа Яндекс.Облако позволяет развернуть ВМ с ОС RHEL версии 7.8, но подписку клиент должен оформлять самостоятельно через стороннюю организацию.

Оба провайдера поддерживают загрузку собственных образов ОС. Яндекс поддерживает форматы qcow (qemu), vhd (Microsoft Hyper-V/Azure) и vmdk (VMware ESXi), но отсутствует возможность импорта ova/ovf формата. MCS поддерживает загрузку формата RAW, для которого требуется конвертация с помощью стандартной утилиты из пакета Qemu. Ещё он поддерживает конвертацию на лету при загрузке через веб-интерфейс портала. Azure позволяет загружать собственные образы в формате VHD (формат Hyper-V).

Уровни SLA отличаются между платформами. MCS и Azure предоставляют SLA в рамках доступности на каждый из облачных сервисов, а также на отдельные параметры внутри сервиса – например, на IOPS для блочных устройств. Яндекс же оперирует только доступностью сервиса, не включая характеристики отдельных компонент. Все провайдеры компенсируют часть счета на услуги в зависимости от времени простоя сервиса. Яндекс отдельно упоминает о возможности полной компенсации платежей в случае потери данных клиента.

Все платформы предоставляют сервис управления учетными записями и правами Identity and Access Management (IAM).

Яндекс для этого требует наличия учетной записи в сервисе Яндекс.Паспорт или интеграцию с внешним провайдером учетных записей посредством протокола SAML, например, AD FS, и позволяет управлять квотами и правами в контексте облачных услуг.

Компания Mail.ru Group расширила функционал, заложенный в IAM для Openstack в части работы с собственным сервисом S3, и близка по возможностям к сервису платформы Яндекс.Облако.

Обе платформы не предполагают сценариев интеграции IAM для собственных приложений клиента.

Наиболее богатый функционал IAM у Azure. Кроме управления облачной инфраструктурой есть возможность получить Active Directory, как услугу. Есть возможность использовать IAM для интеграции с приложениями в облаке для управления учетными записями клиентов компании. Все платформы поддерживают управление собственными SSH ключами для Linux систем.

Управляемые сервисы VPN и DNS

Для полноценного использования платформы IaaS нам требуются такие сервисы, как Managed VPN и Managed DNS. Azure позволяет управлять внешними и внутренними DNS зонами, обычными или техническими DNS записями, а также автоматически регистрировать новые DNS записи при создании ВМ. В MCS функционал ограничен созданием внутренней DNS зоны и автоматической регистрацией ВМ в ней, с возможностью создания произвольного имени или же привязки DNS-записи к сетевому порту (IP адресу), но без возможности управления техническими записями. В платформе Яндекс.Облако отсутствует возможность управлять записям DNS.

Если говорить об организации защищенного подключения и пиринга, то наиболее полный функционал у Azure. В нём есть поддержка режимов client-to-site, site-to-site и прямого пиринга по протоколу BGP. Пропускная способность VPN-линка к Azure ограничивается оконечным оборудованием клиента. MCS поддерживает только режим site-to-site для протокола IPSec. Яндекс – только технологию прямого соединения (название сервиса — Yandex.Cloud Interconnect) по протоколу BGP. Для организации защищенного канала VPN к платформе Яндекс.Облако потребуется развернуть Cisco CSR, Mikrotik CHR или другое VPN решение из маркетплейса.

On-Premise решение для частного облака

Все поставщики облачных услуг предоставляют возможность развертывания своей платформы на оборудовании заказчика (on-premise). Частное облако может быть интегрировано с публичной платформой от данного поставщика для организации гибридного решения с единым порталом управления, репликацией машин и Disaster Recovery площадкой в публичном облаке. Есть отличие предоставления сервиса и вот в чём оно состоит. Microsoft и Яндекс поставляют собственные решения в виде готового к установке в ЦОД оборудования. Компания Mail.ru Group может поставить свое решение на оборудование клиента, совместимого с их платформой.

Итоги сравнения

Подведём итоги сравнения платформ MCS и Яндекс.Облако в части IaaS. Производители данных решений не до конца реализовали весь функционал, необходимый для полноценного перехода инфраструктуры клиента на их сервисы. Отсутствие или недостаточная реализация функционала таких сервисов, как VPN и DNS, требует от клиента наличия своей собственной команды для их поддержки. Это создаёт технический долг, который компании обещают закрыть.

Основные отличия между платформами кратко:

Сравнивая функционал у обоих игроков, оценим его как почти равный. Разве что MCS выглядит более зрелым игроком. На это две причины: разница в возрасте, около полутора лет с момента запуска, и использование наработок из эко системы Openstack. С другой стороны в мире не так много крупных облачных сервисов, построенных на базе Openstack. Если развитие данной платформы будет приостановлено, то компания Mail.ru Group будет вынуждена продолжать разработку в одиночку, будучи скованной архитектурными паттернами родительской платформы Openstack.

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

Источник