OpenSAF (обычно именуемый SAF , Service Availability Framework [1] ) — это система оркестровки служб с открытым исходным кодом для автоматизации развертывания, масштабирования и управления компьютерными приложениями . OpenSAF соответствует стандартам Service Availability Forum (SAF) и SCOPE Alliance и расширяет их. [2]
Первоначально он был разработан Motorola ECC и поддерживается проектом OpenSAF. [3] OpenSAF является наиболее полной реализацией спецификаций SAF AIS , предоставляя платформу для автоматизации развертывания, масштабирования и эксплуатации служб приложений в кластерах хостов. [4] Он работает с рядом инструментов виртуализации и запускает службы в кластере, часто интегрируясь с JVM , Vagrant и/или средами выполнения Docker . OpenSAF изначально взаимодействовал со стандартными интерфейсами прикладного программирования C (API), но добавил привязки Java и Python. [2]
OpenSAF фокусируется на доступности сервисов за пределами требований высокой доступности (HA). Хотя опубликовано мало официальных исследований по улучшению методов высокой доступности и отказоустойчивости для контейнеров и облака, [5] исследовательские группы активно изучают эти проблемы с OpenSAF.
OpenSAF был основан отраслевым консорциумом, включающим Ericsson, HP и Nokia Siemens Networks, и впервые анонсирован Motorola ECC, приобретенной Emerson Network Power 28 февраля 2007 года. [6] Фонд OpenSAF был официально запущен 22 января 2008 года. В состав организации вошли Emerson Network Power, SUN Microsystems, ENEA, Wind River, Huawei, IP Infusion, Tail-f, Aricent, GoAhead Software и Rancore Technologies. [2] [7] GoAhead Software присоединилась к OpenSAF в 2010 году, прежде чем была приобретена Oracle. [8] Разработка и проектирование OpenSAF во многом зависят от критически важных системных требований, включая Carrier Grade Linux, SAF , ATCA и Hardware Platform Interface . OpenSAF стал важной вехой в ускорении внедрения Linux в телекоммуникациях и встраиваемых системах. [9]
Целью Фонда было ускорить принятие OpenSAF в коммерческих продуктах. Сообщество OpenSAF проводило конференции в период с 2008 по 2010 год; первая конференция была организована Nokia Siemens Networks в Мюнхене (Германия), вторая — Huawei в Шэньчжэне (Китай), а третья — HP в Пало-Альто (США). В феврале 2010 года было объявлено о первом коммерческом развертывании OpenSAF в сетях операторов. [10] Академические и отраслевые группы независимо опубликовали книги, описывающие решения на основе OpenSAF. [2] [11] Растущий объем исследований в области доступности услуг ускоряет разработку функций OpenSAF, поддерживающих критически важные развертывания облаков и микросервисов, а также оркестровку сервисов. [12] [13]
OpenSAF 1.0 был выпущен 22 января 2008 года. Он включал в себя кодовую базу NetPlane Core Service (NCS), предоставленную Motorola ECC. [14] Вместе с выпуском OpenSAF 1.0 был заложен фундамент OpenSAF. [6] OpenSAF 2.0, выпущенный 12 августа 2008 года, был первым выпуском, разработанным сообществом OpenSAF. Этот выпуск включал службу журналов и поддержку 64-битной архитектуры. [14] OpenSAF 3.0, выпущенный 17 июня 2009 года, включал управление платформой, улучшения удобства использования и поддержку Java API. [15]
OpenSAF 4.0 стал знаменательным релизом в июле 2010 года. [2] Названный «архитектурным релизом», он внес значительные изменения, включая устранение функциональных пробелов, урегулирование внутренней архитектуры, обеспечение возможности обновления в процессе эксплуатации, уточнение API и улучшение модульности. [16] Получив значительный интерес со стороны промышленности и ученых, OpenSAF провел две общественные конференции в 2011 году, одну из которых организовал Массачусетский технологический институт в Бостоне, штат Массачусетс, а вторую — Ericsson в Стокгольме.
OpenSAF определяет набор строительных блоков, которые в совокупности обеспечивают механизм управления доступностью сервиса (SA) приложений на основе моделей ресурсов и возможностей. [20] SA и высокая доступность (HA) — это вероятность доступности сервиса в случайный момент времени; критически важные системы требуют доступности не менее 99,999% (пять девяток). HA и SA по сути одно и то же, но SA идет дальше (т. е. обновления оборудования и программного обеспечения в процессе эксплуатации). [21] OpenSAF разработан для слабосвязанных систем с быстрыми взаимосвязями между узлами (т. е. с использованием TIPC/TCP), [22] и расширяемыми для удовлетворения различных рабочих нагрузок; компоненты взаимодействуют между собой с помощью любого протокола. Эта расширяемость в значительной степени обеспечивается API IMM, используемым внутренними компонентами и основными службами. Платформа может осуществлять контроль над вычислительными ресурсами и ресурсами хранения, определяя их как объекты, которые будут управляться как экземпляры (службы компонентов) и/или ограничения узлов. [2] [20] [23]
Программное обеспечение OpenSAF распределено по своей природе, следуя архитектуре «первичный/реплика» . В кластере `OpenSAF' есть два типа узлов, которые можно разделить на те, которые управляют отдельным узлом и плоскостью управления. Один системный контроллер работает в «активном» режиме, другой в «резервном» режиме, а оставшиеся системные контроллеры (если таковые имеются) являются запасными, готовыми взять на себя роль активного или резервного в случае сбоя. Узлы могут работать без монитора, без плоскости управления, что добавляет устойчивости облаку. [16] [24]
Системная модель OpenSAF является ключевым API- интерфейсом , позволяющим OpenSAF обрабатывать и проверять запросы, а также обновлять состояние объектов в модели AMF, позволяя директорам планировать рабочие нагрузки и группы обслуживания по рабочим/полезным узлам. Поведение AMF изменяется с помощью объекта конфигурации. [24] Службы могут использовать модели избыточности «No Redundancy», 2N, N+M, N-way и N-way Active. [20] OpenSAF не хватает очевидных цепочек инструментов моделирования для упрощения проектирования и создания моделей конфигурации AMF. Текущие исследования для устранения этого пробела [25] [26] должны предоставлять инструменты экосистемы для лучшей поддержки моделирования и автоматизации вариантов использования операторского класса и Cloud Native Computing Foundation .
Контроллер системы OpenSAF (SC) является основным управляющим блоком кластера, управляющим его рабочей нагрузкой и направляющим связь по всей системе. Плоскость управления OpenSAF состоит из различных компонентов, каждый из которых имеет свой собственный процесс, которые могут работать как на одном узле SC, так и на нескольких узлах SC, поддерживая кластеры высокой доступности и доступность сервисов . [2] [24] Различные компоненты плоскости управления OpenSAF следующие:
Компонент — это логическая сущность модели системы AMF, представляющая собой нормализованное представление вычислительного ресурса, такого как процессы, драйверы или хранилище. Компоненты группируются в логические сервисные единицы (SU) в соответствии с взаимозависимостями отказов и связываются с узлом. SU — это инстанцируемая единица рабочей нагрузки, контролируемая моделью избыточности AMF, в активном, резервном или неисправном состоянии. SU одного типа группируются в сервисные группы (SG), которые демонстрируют особые характеристики моделирования избыточности. SU в SG назначается сервисным экземплярам (SI) и получает состояние доступности «активный» или «резервный». SI — это масштабируемые избыточные логические службы, защищенные AMF. [2] [16]
Узел — это вычислительный экземпляр (лезвие, гипервизор или виртуальная машина), где развертываются экземпляры служб (рабочая нагрузка). Набор узлов, принадлежащих к одной и той же подсети связи (без маршрутизации), составляет логический кластер. Каждый узел в кластере должен запускать среду выполнения для служб, а также перечисленные ниже службы OpenSAF:
Базовой единицей планирования в OpenSAF является единица обслуживания (SU). SU представляет собой группу компонентов. SU состоит из одного или нескольких компонентов, которые гарантированно размещены на одном узле. SU не назначаются IP-адреса по умолчанию, но могут содержать некоторые компоненты, которые их назначают. SU можно административно управлять с помощью адреса объекта. AmfND отслеживает состояние SU и, если они не находятся в желаемом состоянии, повторно развертывает их на том же узле, если это возможно. AmfD может запустить SU на другом узле, если этого требует модель избыточности. [2] SU может определять том, например, каталог локального диска или сетевой диск, и предоставлять его компонентам в SU. [39] SU можно административно управлять через AMF CLI, или управление можно делегировать AMF. Такие тома также являются основой для постоянного хранилища. [2] [16]
Целью сервисной группы является поддержание стабильного набора реплик SU, работающих в любой момент времени. Она может использоваться для гарантии доступности определенного количества идентичных SU на основе выбранной настроенной модели избыточности: N-Way, N-way-Active, 2N, N+M или «No-redundancy». SG — это механизм группировки, который позволяет OpenSAF поддерживать количество экземпляров, объявленных для данного SG. Определение SG идентифицирует все связанные SU и их состояние (активный, резервный, неисправный). [2] [16]
Экземпляр службы OpenSAF (SI) — это набор SU, которые работают вместе, например, один уровень многоуровневого приложения. Набор SU, который защищает службу, определяется SG. Многоэкземплярная SG (N-way-active, N-way, N+M) требует стабильного IP-адреса, DNS-имени и балансировщика нагрузки для распределения трафика этого IP-адреса среди активных SU в этой SG (даже если сбои приводят к перемещению SU с машины на машину). По умолчанию служба предоставляется внутри кластера (например, SU[TypeA] группируется в одну SG, а запросы из SU[typeB] распределяются между ними по нагрузке), но служба также может предоставляться за пределами кластера (например, для клиентов, чтобы достичь интерфейсных SU). [2] [16]
Файловые системы, доступные для OpenSAF SU, по умолчанию являются потенциально эфемерными хранилищами. Если узел уничтожается/создается заново, данные на этом узле теряются. Одним из решений является общее хранилище сетевой файловой системы (NFS), доступное всем узлам полезной нагрузки. [30] Возможны и другие технические решения — важно то, что тома (общий файловый ресурс, точка монтирования) могут быть смоделированы в AMF. Высокодоступные тома обеспечивают постоянное хранилище, которое существует в течение всего срока службы самого SU. Это хранилище также может использоваться как общее дисковое пространство для SU в SG. Тома, смонтированные в определенных точках монтирования на узле, принадлежат определенному SG, поэтому этот экземпляр не может использоваться совместно с другим SG, использующим ту же точку монтирования файловой системы.
Архитектура OpenSAF распределена и работает в кластере логических узлов. Все службы OpenSAF имеют либо 3-уровневую, либо 2-уровневую архитектуру. В 3-уровневой архитектуре службы OpenSAF разделены на директора служб, директора узлов служб и агента. Директор является частью службы OpenSAF с центральным интеллектом служб. Обычно это процесс на узле контроллера. Директора узлов координируют действия служб в области узла, такие как обмен сообщениями с его центральным директором и его локальными агентами. Агент предоставляет возможности служб, доступные клиентам, посредством (общей) подключаемой библиотеки, которая предоставляет четко определенные API служб для процессов приложений. Агенты обычно взаимодействуют со своими директорами узлов служб или серверами. Службы OpenSAF модульно классифицируются следующим образом [22]
Дополнительные службы могут быть включены или отключены во время сборки/упаковки OpenSAF. OpenSAF можно настроить на использование TCP или TIPC в качестве базового транспорта. Узлы можно динамически добавлять/удалять в/из кластера OpenSAF во время выполнения. Кластер OpenSAF хорошо масштабируется до нескольких сотен узлов. OpenSAF поддерживает следующие языковые привязки для API интерфейса AIS:
Модульная архитектура позволяет добавлять новые сервисы, а также адаптировать существующие. Все сервисы OpenSAF разработаны для поддержки обновлений в процессе эксплуатации.
Следующие службы AIS форума SA реализованы в OpenSAF 5.0. [23]
Поставщики сетевого оборудования будут основными пользователями продуктов, основанных на кодовой базе OpenSAF, интегрируя их в свои продукты для поставщиков сетевых услуг, операторов и поставщиков услуг. Многие поставщики сетевого оборудования продемонстрировали свою поддержку OpenSAF, присоединившись к Фонду и/или внеся вклад в проект Open Source. Текущие члены Фонда включают: Ericsson , HP и Oracle . Несколько поставщиков вычислительных и коммуникационных технологий также заявили о своей поддержке инициативы OpenSAF, включая OpenClovis SAFplus, Emerson Network Power Embedded Computing, Continuous Computing, Wind River, IP Infusion, Tail-f, Aricent, Rancore Technologies, GoAhead Software и MontaVista Software.
OpenSAF обычно используется как способ достижения доступности сервисов операторского класса (пять девяток). OpenSAF функционально завершен, но ему не хватает экосистемы инструментов моделирования, доступных другим решениям с открытым исходным кодом, таким как Kubernetes и Docker Swarm .