✖


Jump to content

OpenSAF

Add links
OpenSAF
Оригинальный автор(ы) Моторола
Разработчик(и) Фонд ОпенсАФ
Первоначальный выпуск 31 июня 2007 г .; 17 лет назад ( 31 июня 2007 г. )
Стабильная версия
21.05.03 / 1 марта 2021 г .; 3 года назад ( 01.03.2021 )
Репозиторий
Написано в С++
Тип Программное обеспечение для управления кластером
Веб-сайт опенсаф .sourceforge .что Отредактируйте это в Викиданных

OpenSAF (обычно называемый SAF , платформа доступности служб) [1] ) — это с открытым исходным кодом служба — система оркестрации для автоматизации компьютерными приложениями развертывания, масштабирования и управления . OpenSAF соответствует стандартам Service Availability Forum (SAF) и SCOPE Alliance и расширяет их . [2]

Первоначально он был разработан Motorola ECC и поддерживается проектом OpenSAF. [3] OpenSAF — это наиболее полная реализация спецификаций SAF AIS , предоставляющая платформу для автоматизации развертывания, масштабирования и работы служб приложений в кластерах хостов. [4] Он работает с различными инструментами виртуализации и запускает службы в кластере, часто интегрируясь со средами выполнения JVM , Vagrant и/или Docker . OpenSAF изначально взаимодействовал со стандартными интерфейсами прикладного программирования (API) C, но в него были добавлены привязки 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 сильно влияют критически важные системные требования, включая Linux Carrier Grade, 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 году две общественные конференции: одну организовал Университет Массачусетского технологического института в Бостоне, Массачусетс, а вторую — Эрикссон в Стокгольме.

История выпусков
Версия Дата выпуска Примечания
Старая версия, больше не поддерживается: 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 v4

OpenSAF определяет набор строительных блоков, в совокупности обеспечивающих механизм управления доступностью служб (SA) приложений на основе моделей возможностей ресурсов. [20] SA и High Availability (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] Службы могут использовать модели резервирования «без резервирования», 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, включающему директора (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 может обеспечить высокую доступность (но не SA) для экземпляров компонентов, происходящих из доменов облачных вычислений , контейнеризации , виртуализации и JVM , путем моделирования команд жизненного цикла компонентов и служб (запуск/остановка/проверка работоспособности) в Модель АМФ. [2]
  • Содержащийся в контейнере: Содержащийся в контейнере AMF может находиться внутри SU. Содержащийся в контейнере — это самый низкий уровень среды выполнения, экземпляр которого может быть создан. Компонент, содержащийся в контейнере с поддержкой SA, в настоящее время нацелен на виртуальную машину Java (JVM) согласно JSR139. [29] [2]

Сервисный отдел

[ редактировать ]
Концепции OpenSAF

Базовой единицей планирования в OpenSAF является сервисный модуль (SU). SU — это группа компонентов. SU состоит из одного или нескольких компонентов, которые гарантированно располагаются на одном узле. По умолчанию SU не назначают IP-адреса, но могут содержать некоторые компоненты, которые это делают. SU можно административно управлять с помощью адреса объекта. AmfND отслеживает состояние SU и, если оно не находится в желаемом состоянии, по возможности повторно развертывается на том же узле. AmfD может запустить SU на другом узле, если этого требует модель резервирования. [2] SU может определить том, например, каталог локального диска или сетевой диск, и предоставить его компонентам в SU.[39] SU можно административно управлять через интерфейс командной строки AMF или управление можно делегировать 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 разделены на директора службы, директора узла службы и агента. Директор является частью службы OpenSAF с централизованной службой аналитики. Обычно это процесс на узле контроллера. Директора узлов координируют действия служб на уровне узла, такие как обмен сообщениями, с его центральным директором и его локальными агентами. Агент предоставляет клиентам возможности обслуживания посредством (общей) подключаемой библиотеки, которая предоставляет четко определенные API-интерфейсы служб процессам приложений. Агенты обычно общаются со своими директорами узлов или серверами своих служб. Службы OpenSAF модульно классифицируются следующим образом: [22]

  • Основные услуги – AMF, CLM, IMM, LOG, NTF.
  • Дополнительные услуги – EVT, CKPT, LCK, MSG, PLM, SMF.

Дополнительные службы можно включить или отключить во время сборки/упаковки OpenSAF. OpenSAF можно настроить на использование TCP или TIPC в качестве основного транспорта. Узлы можно динамически добавлять/удалять в/из кластера OpenSAF во время выполнения. Кластер OpenSAF хорошо масштабируется до нескольких сотен узлов. OpenSAF поддерживает следующие языковые привязки для API-интерфейсов интерфейса AIS:

  • С/С++
  • Привязки Java (для сервисов AMF и CLM)
  • Привязки Python
  • OpenSAF предоставляет инструменты и утилиты командной строки для управления кластером и приложениями OpenSAF.

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

Услуги

[ редактировать ]

Следующие службы 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.
  • Платформа управления программным обеспечением (SMF) — поддержка автоматического обновления приложений, промежуточного программного обеспечения и ОС во время эксплуатации в кластере.

Сторонники

[ редактировать ]

Поставщики сетевого оборудования будут основными пользователями продуктов на базе кода 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 .

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ «OpenSAF/О программе» . СоурсФордж . Архивировано из оригинала 11 мая 2015 г. Проверено 28 декабря 2020 г.
  2. ^ Jump up to: а б с д и ж г час я дж к л м н тот п д р с Мария Торое; Фрэнсис Тэм (2012). Доступность услуг: принципы и практика . Джон Уайли и сыновья. ISBN  978-1-1199-4167-5 .
  3. ^ «Ознакомительные сведения об OpenSAF» . СоурсФордж . Архивировано из оригинала 28 декабря 2020 г. Проверено 28 декабря 2020 г.
  4. ^ «ОпенСАФ» . ОпенСАФ . 19 марта 2014 года . Проверено 28 декабря 2020 г.
  5. ^ «Отказоустойчивые контейнеры с использованием NiLiCon» (PDF) . укла . Архивировано (PDF) из оригинала 29 декабря 2020 г. Проверено 28 декабря 2020 г.
  6. ^ Jump up to: а б Кэролайн Мэтас. «Проект OpenSAF» . время . Архивировано из оригинала 27 августа 2020 г. Проверено 28 декабря 2020 г.
  7. ^ Сотрудники ED News (2007). «Лидеры отрасли создадут консорциум по проекту OpenSAF» . Архивировано из оригинала 29 декабря 2020 г.
  8. ^ Фонд ОпенСаф (2010). «GoAhead Software присоединяется к OpenSAF™» (пресс-релиз). Архивировано из оригинала 29 декабря 2020 г.
  9. ^ повар (2007). «Motorola запускает операционную среду высокой доступности с открытым исходным кодом» . Архивировано из оригинала 21 декабря 2014 г.
  10. ^ Фонд OpenSAF (2010). «OpenSAF в коммерческом развертывании» (пресс-релиз). Архивировано из оригинала 25 июня 2018 г.
  11. ^ Мадхусанка Лиянаге; Андрей Гуртов; Мика Илианттила (2015). Программно-определяемые мобильные сети (SDMN): за пределами сетевой архитектуры LTE . John Wiley & Sons, Ltd., тел .: 10.1002/9781118900253 . ISBN  9781118900253 .
  12. ^ Янал Алахмад; Тарик Дарадке; Анджали Агарвал (2018). «Планировщик контейнеров с учетом доступности для служб приложений в облаке» . IEEE : 1–6. дои : 10.1109/PCCC.2018.8711295 . ISBN  978-1-5386-6808-5 . S2CID   155108018 .
  13. ^ Лейла Абдоллахи Вайган; Мохамед Аймен Саид; Мария Торое; Ферхат Хендек (2019). «Kubernetes как менеджер доступности для микросервисных приложений». Журнал сетевых и компьютерных приложений . arXiv : 1901.04946 .
  14. ^ Jump up to: а б «Выпуск OpenSAF 2.0» . Легкое чтение . Архивировано из оригинала 15 августа 2020 года . Проверено 29 декабря 2020 г. .
  15. ^ «Обновленная версия промежуточного программного обеспечения Carrier Grade Linux с открытым исходным кодом (LinuxDevices)» . ЛВН . Архивировано из оригинала 17 сентября 2015 г. Проверено 29 декабря 2020 г. .
  16. ^ Jump up to: а б с д и ж г час я «Обзор OpenSAF Release 4 «The Architecture Release» » (PDF) . ОпенСАФ . Архивировано (PDF) из оригинала 31 декабря 2020 года . Проверено 29 декабря 2020 г. .
  17. ^ Ханс Й. Раушер (22 июня 2009 г.). «Выпущен OpenSAF 3.0» . ВиндРивер . Архивировано из оригинала 29 июня 2009 г. Проверено 30 декабря 2020 г.
  18. ^ «Проект OpenSAF выпускает крупное обновление промежуточного программного обеспечения высокой доступности» . ПИКМГ . Архивировано из оригинала 31 декабря 2020 г. Проверено 30 декабря 2020 г.
  19. ^ «Объявление о выпуске 5.0.0 GA и поддерживающих выпусках 4.7.1, 4.6.2» . исходник . Архивировано из оригинала 31 декабря 2020 г. Проверено 30 декабря 2020 г.
  20. ^ Jump up to: а б с Форум СА (2010). «SAI-AIS-AMF-B.04.01 Раздел 3.6» (PDF) . ОпенСАФ . Проверено 20 декабря 2020 г.
  21. ^ Андерс Виделл; Мативанан НП (2012). «OpenSAF в облаке. Почему промежуточное ПО высокой доступности все еще необходимо» (PDF) . Мероприятия по основанию Linux . Проверено 24 сентября 2015 г.
  22. ^ Jump up to: а б Джон Пол Малой (2004). «TIPC: обеспечение связи для кластеров Linux» (PDF) . Linux Kernel.org . Симпозиум по Linux, том второй. Архивировано (PDF) из оригинала 30 августа 2017 г. Проверено 31 декабря 2020 г.
  23. ^ Jump up to: а б с д OpenSAF TSC (2016). «Опенсаф» . ОПНФВ . Архивировано из оригинала 31 декабря 2020 г. Проверено 28 декабря 2020 г.
  24. ^ Jump up to: а б с Проект OpenSAF (2020). «README OpenSAF» . Сорсфордж . Проверено 31 декабря 2020 г.
  25. ^ Максим ТЮРЕНН (2015). «НОВЫЙ ДОМЕННО-СПЕЦИАЛЬНЫЙ ЯЗЫК ДЛЯ СОЗДАНИЯ И ПРОВЕРКИ КОНФИГУРАЦИИ ПРОМЕЖУТОЧНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ ВЫСОКОДОСТУПНЫХ ПРИЛОЖЕНИЙ» (PDF) . etsmtl.ca . Проверено 28 декабря 2020 г.
  26. ^ Пейман Салехи; Абдельвахаб Хаму-Лхадж; Мария Торое; Ферхат Хендек (2016). «Язык моделирования предметной области на основе UML для управления доступностью услуг» . дои . Компьютерные стандарты и интерфейсы, Том. 44, № C. Elsevier Science Publishers BV doi : 10.1016/j.csi.2015.09.009 . Проверено 28 декабря 2020 г.
  27. ^ Проект OPNFV HA (2016). «Анализ сценариев обеспечения высокой доступности в NFV, раздел 5.4.2» (PDF) . ОПНФВ . Архивировано (PDF) из оригинала 31 декабря 2020 г. Проверено 31 декабря 2020 г.
  28. ^ Проект OpenSAF (2020). «README OpenSAF IMM» . Сорсфордж . Архивировано из оригинала 31 декабря 2020 г. Проверено 31 декабря 2020 г.
  29. ^ Йенс Йенсен; Экспертная группа (2010). «JSR 319: Управление доступностью для Java» . JCP . Архивировано из оригинала 10 июля 2017 г. Проверено 31 декабря 2020 г.
  30. ^ Ферхат Хендек (2013). «OpenSAF и VMware с точки зрения высокой доступности» (PDF) . ДМТФ . Архивировано (PDF) из оригинала 23 сентября 2015 г. Проверено 31 декабря 2020 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=OpenSAF&oldid=1191482414"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 2e7b5eb6ce4cb9e6edf3b613d6def2fe__1703355120
URL1:https://arc.ask3.ru/arc/aa/2e/fe/2e7b5eb6ce4cb9e6edf3b613d6def2fe.html
Заголовок, (Title) документа по адресу, URL1:
OpenSAF - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)