OpenSAF (обычно в стиле SAF , служба доступность Framework [1] ) является открытым исходным кодом службы - оркестровка системы для автоматизации компьютерного приложения развертывания, масштабирования и управления. OpenSAF соответствует стандартам Service Availability Forum (SAF) и SCOPE Alliance и расширяет их . [2]
Автор (ы) оригинала | Motorola |
---|---|
Разработчики) | Фонд OpenSAF |
Первый выпуск | 31 июня 2007 г . |
Стабильный выпуск | 5.21.03 / 1 марта 2021 г . |
Репозиторий | |
Написано в | C ++ |
Тип | Программное обеспечение для управления кластером |
Веб-сайт | opensaf |
Первоначально он был разработан 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 Foundation был официально запущен 22 января 2007 года. 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 сильно влияют критически важные системные требования, в том числе операционная система Linux , SAF , ATCA и интерфейс аппаратной платформы . 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 в Стокгольме.
Версия | Дата выпуска | Заметки |
---|---|---|
1.0 | 22 января 2008 г. | Исходная кодовая база NetPlane Core Service (NCS), предоставленная Motorola ECC для проекта OpenSAF. |
2.0 | 12 августа 2008 г. | |
3.0 | 17 июня 2009 г. | Второй выпуск (начиная с версии 2.0 и далее) занял около 1,5 лет при участии Wind River Systems. [17] |
4.0 | 1 июля 2010 г. | Релиз "Архитектура". Первый жизнеспособный кандидат на развертывание операторского класса. [18] |
4.2 | 16 марта 2012 г. | Улучшенная управляемость, улучшенное моделирование доступности. |
5.0 | 5 мая 2016 | Значительный релиз. Поддержка запасных системных контроллеров (2N + запасных), безголового кластера (устойчивость к облаку), улучшенных привязок Python, ведения журнала имен узлов. [19] |
5.20 | 1 июня 2021 г. | |
Легенда: Старая версия Старая версия, все еще поддерживается Последняя версия Последняя предварительная версия Будущий выпуск |
Концепции
OpenSAF определяет набор строительных блоков, в совокупности предоставляющих механизм для управления доступностью служб (SA) приложений на основе моделей ресурсов и возможностей. [20] SA и высокая доступность (HA) - это вероятность того, что услуга будет доступна в случайный момент времени; для критически важных систем требуется доступность не менее 99,999% (пять девяток). HA и SA, по сути, одно и то же, но SA идет дальше (т. Е. Обновление оборудования и программного обеспечения в процессе эксплуатации). [21] OpenSAF разработан для слабосвязанных систем с быстрым взаимодействием между узлами (т. Е. С использованием TIPC / TCP), [22] и расширяемым для удовлетворения различных рабочих нагрузок; компоненты общаются между собой по любому протоколу. Эта расширяемость в значительной степени обеспечивается IMM API, используемым внутренними компонентами и базовыми службами. Платформа может осуществлять контроль над вычислительными ресурсами и ресурсами хранения, определяя их как объекты, которыми нужно управлять как экземпляры (службы компонентов) и / или ограничения узлов. [2] [20] [23]
Программное обеспечение OpenSAF по своей природе распространяется по принципу « первичная / реплика» . В кластере OpenSAF есть два типа узлов, которые можно разделить на те, которые управляют отдельным узлом и плоскостью управления. Один системный контроллер работает в «активном» режиме, другой - в «резервном», а остальные системные контроллеры (если таковые имеются) являются запасными, готовыми взять на себя роль активного или резервного в случае неисправности. Узлы могут работать без головы, без плоскости управления, что повышает устойчивость к облаку. [16] [24]
Системная модель
Системная модель OpenSAF - это ключевой API-интерфейс , позволяющий OpenSAF обрабатывать и проверять запросы, а также обновлять состояние объектов в модели AMF, позволяя директорам планировать рабочие нагрузки и группы обслуживания между рабочими узлами / узлами полезной нагрузки. Поведение AMF изменяется с помощью объекта конфигурации. [24] Службы могут использовать модели резервирования без резервирования, 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 следующие:
- Менеджер информационных моделей ( IMM ) - это постоянное хранилище данных, в котором надежно хранятся данные конфигурации кластера, представляющие общее состояние кластера в любой момент времени. Предоставляет средства для определения и управления промежуточным программным обеспечением и конфигурацией приложений и информацией о состоянии в форме управляемых объектов и их соответствующих атрибутов. [23] IMM реализован как база данных в памяти, которая реплицирует свои данные на всех узлах. IMM может использовать SQLite в качестве постоянного сервера. Как и Apache ZooKeeper , IMM гарантирует согласованность данных конфигурации на уровне транзакции по сравнению с доступностью / производительностью (см. Теорему CAP ). [2] [23] [27] Служба IMM соответствует трехуровневой структуре OpenSAF «Директор службы», включающей в себя директора IMM (IMMD), директора узла IMM (IMMND) и библиотеку агентов IMM (IMMA). IMMD реализован как демон на контроллерах с использованием модели резервирования 2N, активный экземпляр контроллера является «первичной репликой», резервный экземпляр контроллера поддерживается в актуальном состоянии службой контрольных точек на основе сообщений. IMMD отслеживает членство в кластере (с помощью MDS), обеспечивает контроль доступа к хранилищу данных и административный интерфейс для всех сервисов OpenSAF. [28] [2]
- Структура управления доступностью ( AMF ) обеспечивает высокую доступность и структуру управления рабочими нагрузками с надежной поддержкой (в сочетании с другими службами AIS) для полного жизненного цикла управления сбоями (обнаружение, изоляция, восстановление, исправление и уведомление). AMF следует за трехуровневым OpenSAF «Service Director», состоящим из директора (AmfD), директора узла (AmfND) и агентов (AmfA), а также внутреннего сторожевого таймера для защиты AmfND. Активная служба AmfD отвечает за реализацию конфигурации службы, сохраняемой в IMM, в рамках системы / кластера. Директора узлов выполняют одну и ту же функцию для любого компонента в пределах своей области действия. [2] Он обеспечивает согласованность моделей состояний, выступая в качестве основной информации и моста API для всех компонентов. AMF отслеживает состояние IMM, применяя изменения конфигурации или просто восстанавливая любые отклонения до «требуемой конфигурации», используя политики эскалации управления сбоями для планирования создания требуемого развертывания. [16]
- Директора AMF ( AmfD ) - это планировщики, которые решают, на каких узлах работает незапланированная группа обслуживания (резервный экземпляр службы). Это решение основано на текущих и «желаемых» моделях доступности и возможностей, моделях избыточности услуг и ограничениях, таких как качество обслуживания, соответствие / анти-сродство и т. Д. Директора AMF сопоставляют «предложение» ресурсов с «спросом» рабочей нагрузки, и его поведением можно управлять с помощью системного объекта IMM. [2] [16]
Составная часть
Компонент является логической сущностью модели системы AMF и представляет собой нормализованное представление вычислительного ресурса, такого как процессы, драйверы или хранилище. Компоненты сгруппированы в логические сервисные единицы (SU) в соответствии с взаимозависимостями сбоев и связаны с узлом. SU - это экземплярная единица рабочей нагрузки, управляемая моделью избыточности AMF, в активном, резервном или неисправном состоянии. SU одного типа сгруппированы в группы услуг (SG), которые демонстрируют определенные характеристики моделирования избыточности. SU в SG назначается экземплярам службы (SI) и получает активное или резервное состояние доступности. SI - это масштабируемые резервные логические службы, защищенные AMF. [2] [16]
Узел
Узел является экземпляром вычислений (лезвие, гипервизор или ВМ) , где развернуты экземпляры служб (рабочая нагрузка). Набор узлов, принадлежащих к одной подсети связи (без маршрутизации), составляет логический кластер. На каждом узле кластера должна быть запущена среда выполнения для служб, а также служб OpenSAF, перечисленных ниже:
- Директор узла (AmfND): AmfND отвечает за рабочее состояние каждого узла, обеспечивая работоспособность всех активных SU на этом узле. Он заботится о запуске, остановке и поддержании CSI и / или SU, организованных в SG в соответствии с указаниями уровня управления. Служба AmfND обеспечивает на узле желаемую конфигурацию AMF, сохраненную в IMM. При обнаружении сбоя узла директор (AmfD) наблюдает за этим изменением состояния и запускает служебный блок на другом подходящем исправном узле. [2] [16]
- Компонент, не связанный с SA: OpenSAF может предоставлять HA (но не SA) для экземпляров компонентов, происходящих из облачных вычислений , контейнеров , виртуализации и доменов JVM , путем моделирования команд жизненного цикла компонента и службы (запуск / остановка / проверка работоспособности) в Модель AMF. [2]
- Содержащийся в контейнере: содержащийся в контейнере AMF может находиться внутри SU. Контейнер-содержащий - это самый низкий уровень среды выполнения, который может быть создан. Компонент, содержащий контейнер с поддержкой SA, в настоящее время нацелен на виртуальную машину Java (JVM) для JSR139. [29] [2]
Сервисный блок
Базовая единица планирования в 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 или «Без резервирования». 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 имеют трехуровневую или двухуровневую архитектуру. В трехуровневой архитектуре службы OpenSAF разделены на Service Director, Service Node-Director и Agent. Директор является частью службы OpenSAF с центральной аналитикой службы. Обычно это процесс на узле контроллера. Директора узлов координируют деятельность узла по обслуживанию, например обмен сообщениями с центральным директором и местными агентами. Агент предоставляет возможности обслуживания, доступные клиентам, посредством (совместно используемой) связываемой библиотеки, которая предоставляет четко определенные API-интерфейсы служб для процессов приложений. Агенты обычно общаются со своими сервисными директорами узлов или серверами. Сервисы OpenSAF по модульному принципу классифицируются следующим образом [22].
- Основные сервисы - AMF, CLM, IMM, LOG, NTF
- Дополнительные услуги - EVT, CKPT, LCK, MSG, PLM, SMF
Дополнительные службы могут быть включены или отключены во время сборки / упаковки OpenSAF. OpenSAF можно настроить для использования TCP или TIPC в качестве основного транспорта. Узлы могут быть динамически добавлены / удалены в / из кластера OpenSAF во время выполнения. Кластер OpenSAF хорошо масштабируется до нескольких сотен узлов. OpenSAF поддерживает следующие языковые привязки для API интерфейса AIS:
- C / C ++
- Привязки Java (для сервисов AMF и CLM)
- Привязки Python
- OpenSAF предоставляет инструменты и утилиты командной строки для управления кластером OpenSAF и приложениями.
Модульная архитектура позволяет добавлять новые услуги, а также адаптировать существующие. Все сервисы OpenSAF разработаны для поддержки обновлений без отрыва от производства. Можно добавить поддержку дополнительных интерфейсов управления поверх существующей модульной архитектуры (например: - SNMP, NETCONF, REST, HTTP, RPC).
Подробная информация об архитектуре OpenSAF доступна по адресу http://sourceforge.net/p/opensaf/documentation/ci/default/tree/OpenSAF_Overview_PR.odt
Услуги
Следующие службы AIS SA Forum реализованы в OpenSAF 5.0. [23]
- Структура управления доступностью (AMF) - описана выше.
- Служба членства в кластере (CLM) - определяет, достаточно ли работоспособен узел, чтобы быть частью кластера. Предоставляет механизм для отслеживания узлов кластера путем взаимодействия с PLM для отслеживания состояния базовой ОС / оборудования.
- Служба контрольных точек (CKPT) - для сохранения состояний приложения и инкрементных обновлений, которые можно использовать для восстановления службы во время аварийного переключения или переключения.
- Служба событий (EVT) - предоставляет модель обмена сообщениями публикация-подписка, которую можно использовать для синхронизации приложений и объектов управления в отношении событий, происходящих в кластере.
- Служба управления информационными моделями (IMM) - описана выше.
- Служба блокировки (LCK) - поддерживает модель службы распределенной блокировки с поддержкой общих блокировок и эксклюзивных блокировок.
- Служба журнала (LOG) - средство для записи (в файлы журнала) функциональных изменений, происходящих в кластере, с поддержкой ведения журнала в различных форматах записи журнала. Не для отладки или отслеживания ошибок. Поддерживает регистрацию аварийных сигналов и уведомлений, происходящих в кластере.
- Служба обмена сообщениями (MSG) - поддерживает механизм обмена сообщениями в масштабе кластера с несколькими отправителями - с одним получателем, а также с механизмами групп сообщений.
- Служба уведомлений (NTF) - предоставляет модель производителя / подписчика для уведомлений системного управления, позволяющую обрабатывать ошибки. Используется для уведомлений о тревогах и неисправностях с поддержкой записи истории для анализа неисправностей. Поддерживает форматы уведомлений по рекомендациям ITU-T X.730, X.731, X.733, X.736.
- Служба управления платформой (PLM) - предоставляет механизм для настройки логического представления базового оборудования (FRU) и ОС. Предоставляет механизм для отслеживания состояния ОС, оборудования (FRU) и выполнения административных операций в координации со службами и приложениями OpenSAF.
- Software Management Framework (SMF) - поддержка автоматического обновления приложений, промежуточного программного обеспечения и ОС во время работы в кластере.
Сторонники
Поставщики сетевого оборудования будут основными пользователями продуктов, основанных на кодовой базе OpenSAF, интегрируя их в свои продукты для поставщиков сетевых услуг, операторов связи и операторов. Многие поставщики сетевого оборудования продемонстрировали свою поддержку OpenSAF, присоединившись к Фонду и / или внося свой вклад в проект с открытым исходным кодом. В число нынешних членов фонда входят: 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. OpenSAF функционально завершен, но ему не хватает экосистемы инструментов моделирования, доступных для других решений с открытым исходным кодом, таких как Kubernetes и Docker Swarm.
Смотрите также
- САФорум
- SCOPE Альянс
- OpenHPI
- Список программного обеспечения для управления кластером
- Фонд облачных вычислений
Рекомендации
- ^ "OpenSAF / О программе" . SourceForge . Архивировано 11 мая 2015 года . Проверено 28 декабря 2020 .
- ^ Б с д е е г ч я J к л м п о р д р ы Мария Тероэ; Фрэнсис Тэм (2012). Доступность услуг: принципы и практика . Джон Вили и сыновья. ISBN 978-1-1199-4167-5.
- ^ "OpenSAF Readme" . SourceForge . Архивировано 28 декабря 2020 года . Проверено 28 декабря 2020 .
- ^ «OpenSAF» . OpenSAF . Проверено 28 декабря 2020 .
- ^ «Отказоустойчивые контейнеры с использованием NiLiCon» (PDF) . ucla . Архивировано (PDF) из оригинала 29 декабря 2020 года . Проверено 28 декабря 2020 .
- ^ а б Кэролайн Матас. «Проект OpenSAF» . eetimes . Архивировано 27 августа 2020 года . Проверено 28 декабря 2020 .
- ^ ED News Staff (2007). «Лидеры отрасли создают консорциум по проекту OpenSAF» . Архивировано 29 декабря 2020 года.
- ^ Фонд OpenSaf (2010 г.). «GoAhead Software присоединяется к OpenSAF (TM)» . Архивировано 29 декабря 2020 года.
- ^ повар (2007). «Motorola запускает операционную среду высокой доступности с открытым исходным кодом» . Архивировано 29 декабря 2020 года.
- ^ Фонд OpenSAF (2010 г.). «OpenSAF в коммерческом развертывании» . Архивировано 25 июня 2018 года.
- ^ Мадхусанка Лиянаге; Андрей Гуртов; Мика Илианттила (2015). Программно-определяемые мобильные сети (SDMN): за пределами сетевой архитектуры LTE . John Wiley & Sons, Ltd. DOI : 10.1002 / 9781118900253 . ISBN 9781118900253.
- ^ Янал Алахмад; Тарик Дарадке; Анджали Агарвал (2018). «Планировщик контейнеров с учетом доступности для служб приложений в облаке» . IEEE : 1–6. DOI : 10,1109 / PCCC.2018.8711295 . ISBN 978-1-5386-6808-5. S2CID 155108018 .
- ^ Лейла Абдоллахи Вейган; Мохамед Аймен Саид; Мария Тероэ; Ферхат Хендек (2019). «Kubernetes как менеджер доступности для микросервисных приложений» . Журнал сетевых и компьютерных приложений . arXiv : 1901.04946 . Проверено 28 декабря 2020 .
- ^ а б «OpenSAF Releases 2.0» . Светочтение . Архивировано 15 августа 2020 года . Проверено 29 декабря 2020 года .
- ^ "Открытый исходный код Carrier Grade Linux промежуточного слоя rev'd (LinuxDevices)" . LWN . Архивировано 17 сентября 2014 года . Проверено 29 декабря 2020 года .
- ^ Б с д е е г ч I «Обзор OpenSAF Release 4« Архитектурный выпуск » » (PDF) . OpenSAF . Архивировано 29 декабря 2020 года (PDF) . Проверено 29 декабря 2020 года .
- ^ Ханс Дж. Раушер. «Выпущен OpenSAF 3.0» . WindRiver . Архивировано 29 июня 2020 года . Проверено 30 декабря 2020 .
- ^ «Проект OpenSAF выпускает основное обновление промежуточного программного обеспечения высокой доступности» . PICMG . Архивировано 31 декабря 2020 года . Проверено 30 декабря 2020 .
- ^ «Объявление о выпуске 5.0.0 GA и отладочных выпусках 4.7.1, 4.6.2» . sourceforge . Архивировано 31 декабря 2020 года . Проверено 30 декабря 2020 .
- ^ а б в SA Forum (2010). «SAI-AIS-AMF-B.04.01 Раздел 3.6» (PDF) . OpenSAF . Проверено 20 декабря 2020 года .
- ^ Андерс Уайделл; Мативанан Н.П. (2012). «OpenSAF в облаке. Почему по-прежнему необходимо промежуточное ПО высокой доступности» (PDF) . События Linuxfoundation . Проверено 24 сентября 2015 года .
- ^ а б Джон Пол Малой (2004). «TIPC: обеспечение связи для кластеров Linux» (PDF) . Linux Kernel.org . Симпозиум по Linux, Том второй. Архивировано (PDF) из оригинала 30 августа 2017 года . Проверено 31 декабря 2020 года .
- ^ а б в г OpenSAF TSC (2016). «Опенсаф» . OPNFV . Архивировано 31 декабря 2020 года . Проверено 28 декабря 2020 .
- ^ а б в OpenSAF Project (2020). "OpenSAF README" . Sourceforge . Проверено 31 декабря 2020 .
- ^ Максим ТЮРЕНН (2015). «НОВЫЙ ЯЗЫК ДЛЯ ДОМЕНА ДЛЯ ГЕНЕРИРОВАНИЯ И ПРОВЕРКИ КОНФИГУРАЦИЙ СРЕДНЕГО ОБЕСПЕЧЕНИЯ ДЛЯ ДОСТУПНЫХ ПРИЛОЖЕНИЙ» (PDF) . etsmtl.ca . Проверено 28 декабря 2020 .
- ^ Педжман Салехи; Абдельвахаб Хаму-Лхадж; Мария Тероэ; Ферхат Хендек (2016). «Язык моделирования на основе UML для управления доступностью услуг» . doi . Компьютерные стандарты и интерфейсы Elsevier Science Publishers BV, Vol. 44, № С. DOI : 10.1016 / j.csi.2015.09.009 . Проверено 28 декабря 2020 .
- ^ OPNFV HA Project (2016). «Сценарный анализ высокой доступности в NFV, раздел 5.4.2» (PDF) . OPNFV . Архивировано (PDF) из оригинала 31 декабря 2020 года . Проверено 31 декабря 2020 .
- ^ OpenSAF Project (2020). "OpenSAF IMM README" . Sourceforge . Архивировано 31 декабря 2020 года . Проверено 31 декабря 2020 .
- ^ Йенс Йенсен; Экспертная группа (2010). «JSR 319: Управление доступностью для Java» . JCP . Архивировано 10 июля 2017 года . Проверено 31 декабря 2020 .
- ^ Ферхат Хендек (2013). «OpenSAF и VMware с точки зрения высокой доступности» (PDF) . ДМТФ . Архивировано (PDF) из оригинала на 2015-09-03 . Проверено 31 декабря 2020 .
Внешние ссылки
- Официальный веб-сайт
- OpenSAF на SourceForge.net
- SA Forum at the Wayback Machine (архивировано 06 октября 2008 г.)