Спецификация интерфейса приложения

( Спецификация интерфейса приложения AIS ) — это набор открытых спецификаций, которые определяют интерфейсы программирования приложений (API) для прикладного компьютерного программного обеспечения высокой доступности. Он разработан и опубликован Форумом доступности услуг (SA Forum) и размещен в свободном доступе. Помимо снижения сложности приложений высокой доступности и сокращения времени разработки, спецификации призваны облегчить переносимость приложений между различными реализациями промежуточного программного обеспечения и допустить сторонних разработчиков к области, которая в прошлом была строго закрытой.

История

AIS является частью интерфейсов доступности услуг (SAI) SA Forum. Первоначальные спецификации, выпущенные 14 апреля 2003 г., включали в себя структуру управления доступностью (AMF), службу членства в кластере (CLM) и четыре других служебных службы (контрольная точка, событие, сообщение и блокировка).

Дополнительные услуги были добавлены в последующих выпусках.

В выпуске 3 (18 января 2006 г.) добавлен первый набор служб управления: управление журналами, уведомлениями и информационными моделями (IMM).
В выпуске 4 (27 февраля 2007 г.) служебные службы были расширены за счет таймера и именования.
В выпуске 5 (16 октября 2007 г.) к службам управления была добавлена функция безопасности и добавлена платформа управления программным обеспечением.
В выпуске 6 (21 октября 2008 г.) добавлена служба управления платформой, чтобы закрыть разрыв между AIS и HPI ( интерфейс аппаратной платформы ).

AIS состоит из 12 сервисов и двух платформ. Услуги разделены на три функциональные группы — услуги платформы AIS, базовые услуги управления AIS и общие служебные услуги AIS — в дополнение к платформам AIS.

Первоначально API были определены только на языке программирования C , но с июля 2008 года сопоставление Java различных API-интерфейсов служб выпускается постепенно.

Зависимости службы

Различные сервисы и структуры спецификаций интерфейса спроектированы так, чтобы быть модульными и в определенной степени независимыми друг от друга. Это позволяет системе, обеспечивающей только AIS и отсутствие HPI, и наоборот.

Единственная необходимая архитектурная зависимость — это зависимость от службы членства в кластере (CLM). Все службы AIS, за исключением службы управления платформой (PLM) и службы таймера (TMR), зависят от CLM.

Ожидается, что все службы AIS должны использовать службы управления AIS для предоставления доступа к своим административным интерфейсам, конфигурации и информации управления средой выполнения (рис. 2).

Услуги платформы

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

Основными логическими объектами, реализуемыми PLM, являются:

Аппаратный элемент (HE) . Аппаратный элемент — это логический объект, который представляет собой любой тип аппаратного объекта, который может быть, например, шасси, блейд-модулем ЦП или устройством ввода-вывода. Обычно все сменные блоки (FRU) моделируются как аппаратные элементы.
Среда выполнения (EE) . Среда выполнения — это логический объект, представляющий среду, способную запускать некоторые программы. Например, блейд-процессор или машина SMP запускают один экземпляр операционной системы, смоделированный как среда выполнения. Поддерживаются различные архитектуры виртуализации (рис. 4).

PLM поддерживает состояние этих объектов в информационной модели и предоставляет средства для управления ими и отслеживания любых изменений состояния. Для выполнения этих задач для HE служба PLM обычно использует HPI. В случае EE PLM отвечает за получение всей необходимой информации о работоспособности операционной системы и любого доступного уровня виртуализации.

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

Служба членства в кластере реализует два логических объекта:

Кластер — представляет сам кластер и является родительским объектом для объектов узла кластера.
Узел кластера — представляет настроенный узел кластера.

CLM предоставляет API для получения текущей информации о членстве в кластере и отслеживания изменений членства (например, выход из узла, присоединение к узлу). Все службы AIS на уровне кластера должны использовать API отслеживания CLM для определения членства.

Управленческие услуги

Различные объекты, реализованные службами AIS (например, среды выполнения, контрольные точки, компоненты и т. д.), представлены как управляемые объекты SA Forum в информационной модели (IM), которую можно рассматривать как базу данных управления конфигурацией . Управляемые объекты являются экземплярами классов объектов, определенных соответствующей спецификацией службы AIS, которая определяет атрибуты класса и административные операции. Административные операции, указанные для классов объектов, представляют собой операции, которые могут выполняться над объектами, представленными объектами, например блокировка сервисного модуля или экспорт содержимого IM в формате XML. Объекты в IM хранятся в древовидной иерархии, где объект может иметь не более одного родительского объекта и любое количество дочерних объектов.

Логические сущности, представленные объектами в IM, обычно не реализуются самой службой IMM; вместо этого пользовательские приложения и службы AIS, такие как служба контрольных точек или платформа управления доступностью, обеспечивают их реализацию. Поэтому их называют реализаторами объектов (OI). В целях управления все службы AIS представляют свои реализованные объекты как управляемые объекты через службу IMM.

В IM есть две категории объектов и атрибутов: среда выполнения и конфигурация.

среды выполнения Объекты и атрибуты отражают текущее состояние сущностей, которые они представляют, — они носят описательный характер.

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

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

Соответственно, служба IMM предоставляет « южный » интерфейс – IMM-OI API – разработчикам объектов и « северный » интерфейс – IMM-OM API – приложениям управления (рис. 5), например агентам SNMP, и выступает посредником между эти две партии. Он также отвечает за хранение постоянных объектов и атрибутов.

Бревно

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

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

Определены четыре типа потоков журнала: сигнализация (записи журнала на основе ITU X.733 и ITU X.736), уведомление (записи журнала на основе ITU X.730 и ITU X.731), система и приложение . Тип приложения используется приложениями для определения потоков журналов для конкретных приложений. Для каждого типа потока сигналов тревоги, уведомлений и системного журнала в кластере SA Forum существует ровно один предопределенный поток журнала. Пользовательским приложениям разрешено использовать любые предопределенные потоки или создавать новые потоки журналов для конкретных приложений.

Уведомление

Служба уведомлений в значительной степени основана на модели ITU-T Fault Management (как она содержится в документах серии X.700), а также на многих других вспомогательных рекомендациях.

Служба уведомлений основана на концепции уведомления , которая объясняет инцидент или изменение статуса. Термин «уведомление» используется вместо термина «событие», чтобы четко отличить его от «события», определенного службой событий AIS.

Служба NTF основана на парадигме публикации-подписки . Он определяет шесть типов уведомлений: тревога, охранная тревога, создание/удаление объекта, изменение состояния, изменение значения атрибута и прочее. Уведомления генерируются/публикуются производителями с использованием API производителя уведомлений. Потребителями уведомлений могут быть либо подписчики , которые подписываются на уведомления и получают их по мере их поступления; или читатели , которые получают уведомления из сохраненных журналов с помощью API-интерфейса потребителя уведомлений. Потребители уведомлений обоих типов могут определять фильтры, которые определяют характеристики уведомлений, которые они заинтересованы в получении или чтении.

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

Безопасность

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

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

Рамки

Структура управления доступностью

Структура управления доступностью обеспечивает доступность услуг в системах, совместимых с SA Forum. Он координирует рабочую нагрузку различных подконтрольных ему организаций в зависимости от их готовности предоставлять услуги. Для этого приложение необходимо описать согласно информационной модели, заданной для AMF. Эта модель описывает, какие ресурсы принадлежат приложению в кластере и какие сервисы предоставляет приложение.

Базовым логическим объектом этой информационной модели является компонент , который представляет собой набор ресурсов для платформы управления доступностью, которые инкапсулируют некоторые конкретные функции приложения. Рабочая нагрузка, создаваемая путем предоставления некоторой службы, которая может быть назначена компоненту с помощью AMF, представлена как экземпляр службы компонента (CSI) . Когда компонент активно предоставляет услугу, ему присваивается активное состояние от имени CSI, представляющего услугу.

Фундаментальный принцип отказоустойчивого проектирования заключается в предоставлении услуг набором резервных объектов , поэтому компоненты должны иметь возможность действовать в качестве резервных от имени CSI. Резервные компоненты поддерживают себя в состоянии, позволяющем им взять на себя предоставление услуг в случае сбоя компонента с активным назначением. Роль AMF заключается в назначении активных или резервных рабочих нагрузок компонентам приложения в зависимости от состояния компонента и конфигурации системы.

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

Конфигурация Availability Management Framework включает политики восстановления и исправления. Это позволяет расставлять приоритеты ресурсов и обеспечивает различные модели резервирования. Они варьируются от простой модели 2N (также известной как 1+1 или активный резерв) до более сложных моделей, таких как модель N-путевого резервирования, которая позволяет выполнять более одного резервного назначения от имени одного и того же экземпляра службы компонента или N-way-active, который позволяет выполнять несколько активных назначений.

Чтобы упростить администрирование, AMF дополнительно группирует компоненты в сервисные единицы и группы сервисов, а экземпляры сервисов компонентов — в экземпляры сервисов. Все это составляет приложение. Через IMM над этими логическими объектами доступен набор административных операций.

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

Структура управления программным обеспечением

Систему, совместимую с SA Forum, можно охарактеризовать ее конфигурацией развертывания, которая состоит из программного обеспечения, развернутого в системе, а также всех настроенных программных объектов. Конфигурация развертывания составляет важную часть информационной модели, управляемой службой IMM.

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

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

Во время этой миграции SMF

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

Для выполнения всех этих задач реализация SMF взаимодействует как минимум (1) с AMF для поддержания доступности, (2) с IMM для внесения изменений в информационную модель и (3) с NTF для получения уведомлений, которые могут указывать на ошибку. ситуации, вызванные продолжающейся кампанией.

Software Management Framework также предоставляет API для клиентских процессов, позволяющий регистрировать их заинтересованность в получении обратных вызовов, когда в кластере инициируется соответствующая кампания по обновлению и по мере ее прохождения через важные этапы. Это позволяет координировать действия, специфичные для приложения, с обновлением. Это может варьироваться от простой блокировки начала кампании обновления, когда приложение выполняет какую-либо критически важную задачу, до координации действий по обновлению на уровне приложения, таких как обновление схемы базы данных или развертывание новых протоколов.

Для поставщиков программного обеспечения, поставляющих приложения для развертывания в кластере SA Forum, Software Management Framework также определяет схему XML для файла типов сущностей , которая описывает типы сущностей программного обеспечения, реализованные приложением. Эта информация используется для разработки соответствующих конфигураций развертывания.

Коммунальные услуги

Контрольно-пропускной пункт

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

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

События

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

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

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

Замки

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

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

Сообщения

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

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

Очереди сообщений можно группировать вместе, образуя группы очередей сообщений. Группы очередей сообщений позволяют осуществлять связь между несколькими точками. Они идентифицируются логическими именами, поэтому процесс-отправитель не знает о количестве очередей сообщений и о расположении очередей сообщений в кластере, с которым он взаимодействует. Группы очередей сообщений можно использовать для распределения сообщений между очередями сообщений, относящимися к группе очередей сообщений. MSG определяет три политики одноадресного распределения — равное распределение нагрузки, локальное равное распределение нагрузки и локальную лучшую очередь — и политику широковещательной ( многоадресной ) рассылки.

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

Мы

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

Служба именования не накладывает ни определенного макета, ни соглашений ни на имена ( предполагается кодировка UTF-8 ), ни на объекты, к которым они привязаны. Это позволяет пользователям службы выбирать и использовать свою собственную схему именования без какой-либо конкретной аппаратной или логической конфигурации программного обеспечения. Ожидается, что клиенты службы именования понимают структуру, расположение и семантику привязок объектов, которые они собираются хранить внутри и получать из службы.

Таймеры

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

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

Модель программирования

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

Интерфейс приложения SA Forum возникает между процессом и библиотекой, реализующей этот интерфейс. Интерфейс предназначен для использования как многопоточными, так и однопоточными процессами приложений. Термин «процесс» можно рассматривать как эквивалент процесса, определенного стандартом POSIX; однако AIS не требует процесса POSIX , а скорее любого эквивалентного объекта, который система предоставляет для управления выполняющимся программным обеспечением.

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

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

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

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

AIS использует как синхронную, так и асинхронную модели программирования. Синхронные API обычно используются для интерфейсов управления библиотеками и ассоциациями. Многие службы AIS предоставляют возможность отслеживать изменения в реализуемых ими объектах. Трек API обычно состоит из трех функций: инициирование и остановка отслеживания объекта, вызываемого клиентом; и обратный вызов, вызываемый службой, для уведомления клиента о (ожидающих) изменениях отслеживаемого объекта.

Обратная совместимость

Для достижения обратной совместимости при развитии спецификации AIS необходимо соблюдать ряд правил:

Определение функции или типа никогда не меняется для конкретной версии SA Forum.
Изменения в определении функции или типа (добавление нового аргумента в функцию, добавление нового поля в структуру данных) приводят к необходимости определения новой функции или имени типа. Новое имя функции или типа создается на основе исходного имени предыдущей версии с суффиксом, указывающим версию, в которой изменилась функция/тип (например, saAmfComponentRegister_3()).
В качестве исключения из предыдущего правила, новые значения перечисления, значения флага или поля объединения могут быть добавлены к существующему типу перечисления, флага или объединения без изменения имени типа, при условии, что размер перечисления, флага или объединения тип не меняется.
Разработчики AIS должны гарантировать, что они соблюдают номера версий, предоставленные приложением при инициализации библиотеки, и не предоставляют новые значения перечисления приложениям, использующим более старые версии.
Разработчики AIS также должны гарантировать, что они соблюдают номера версий, предоставленные приложением при инициализации библиотеки, в отношении новых или измененных кодов ошибок и не предоставляют приложениям коды ошибок, которые применяются только к функциям в самой последней версии спецификации. написано в более старой версии спецификации.

В качестве примера рассмотрим majorVersion Vx данного сервиса, который включает функцию f(), и предположим, что f() пришлось изменить в более новой MajorVersion Vy (Vy > Vx), что привело к введению f_y( ) вариант, который теперь заменяет f() в Vy.

Учитывая реализацию AIS, которая поддерживает обе версии Vx и Vy, процесс может инициализировать библиотеку, указав либо Vx, либо Vy:

если процесс инициализирует дескриптор библиотеки с помощью Vx, этот дескриптор не обеспечивает доступ к функциям, которые были представлены в более новых версиях, чем Vx. В частности, этот дескриптор не позволит процессу успешно вызвать f_y().
если процесс инициализирует дескриптор библиотеки с помощью Vy, этот дескриптор не обеспечивает доступ к функции, представленной в версиях старше Vy, а затем замененной более новым вариантом той же функции. В частности, этот дескриптор не позволит процессу успешно вызвать функцию f().

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

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

Версии спецификаций имеют следующую структуру: <код выпуска>.<основная версия>.<дополнительная версия>.

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

Реестр реализации

Реестр реализации SA Forum — это процесс, который позволяет регистрировать реализации спецификаций SA Forum и делать их общедоступными. Членство не требуется для регистрации реализаций. Реализации, которые были успешно зарегистрированы, могут называться «Зарегистрированы на форуме доступности услуг».

См. также

Ссылки

Внешние ссылки