Что такое общественное облако
Общественное облако
Общественное облако (community cloud) — вид инфраструктуры, которая распределяется между несколькими организациями из определенного сообщества с общими интересами (безопасностью, соблюдением, юрисдикции и т.д.), может находиться в кооперативной (совместной) собственности, управлении и эксплуатации одной или более из организаций сообщества или третьей стороны (или какой-либо их комбинации), и оно может физически существовать как внутри так и вне юрисдикции владельца. Это контролируется и используется группой организаций, имеющих общие интересы. Расходы распределены по меньшему числу пользователей, чем публичное облако (но больше, чем частное облако), так что только некоторые части экономии облачных технологий реализованы.
Общая информация
Общественное облако находится между публичным и частным облаком. Оно немного похоже на частное облако, но инфраструктура и вычислительные ресурсы являются исключительными для двух или более организаций, которые имеют общую конфиденциальность, безопасность и нормативные соображения, а не для одной организации.
С общественным облаком можно хранить свои файлы удаленно и надежно, и затем более позднее получать доступ к на различных компьютерах. Общественное облако предлагает широкий спектр услуг многократным клиентам, все еще используя общую инфраструктуру. Общественные облака часто предлагают тот же самый уровень безопасности и инфраструктуры как частные облака, соразмерные к уровню предложенной услуги.
Общественное облако только начинает распространение в мире IT. Несколько организаций начали работать с сообществом облачных платформ. Общественное облако является многопользовательской платформой, которая позволяет нескольким компаниям работать на одной и той же платформе, учитывая, что они имеют сходные нужды и проблемы.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Общественное облако
Общественное облако (community cloud) — вид инфраструктуры, которая распределяется между несколькими организациями из определенного сообщества с общими интересами (безопасностью, соблюдением, юрисдикции и т.д.), может находиться в кооперативной (совместной) собственности, управлении и эксплуатации одной или более из организаций сообщества или третьей стороны (или какой-либо их комбинации), и оно может физически существовать как внутри так и вне юрисдикции владельца. Это контролируется и используется группой организаций, имеющих общие интересы. Расходы распределены по меньшему числу пользователей, чем публичное облако (но больше, чем частное облако), так что только некоторые части экономии облачных технологий реализованы.
Содержание
Общая информация
Общественное облако находится между публичным и частным облаком. Оно немного похоже на частное облако, но инфраструктура и вычислительные ресурсы являются исключительными для двух или более организаций, которые имеют общую конфиденциальность, безопасность и нормативные соображения, а не для одной организации.
С общественным облаком можно хранить свои файлы удаленно и надежно, и затем более позднее получать доступ к на различных компьютерах. Общественное облако предлагает широкий спектр услуг многократным клиентам, все еще используя общую инфраструктуру. Общественные облака часто предлагают тот же самый уровень безопасности и инфраструктуры как частные облака, соразмерные к уровню предложенной услуги.
Общественное облако только начинает распространение в мире IT. Несколько организаций начали работать с сообществом облачных платформ. Общественное облако является многопользовательской платформой, которая позволяет нескольким компаниям работать на одной и той же платформе, учитывая, что они имеют сходные нужды и проблемы.
Публичные облака в российских реалиях. Часть 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.
Яндекс же пошел по своему пути. Для реализации недостающего функционала собственными силами ему требуется время. В долгосрочной перспективе разработка собственной платформы позволит максимально быстро откликаться на потребности индустрии.