Понятие очередей сообщений

2.5. Защита

Немаловажным в ИТ-системе компании является тщательное изучение проблем безопасности и защиты. Доступ к службам и информации в рамках такой системы должен быть под контролем, а целостность передаваемых по сетям общего пользования закрытых и чувствительных данных – должным образом обеспечена.

2.5.1. Защита доступа

Нередко важно гарантировать, что службы в ИТ-системе компании доступны только авторизованным сторонам – людям и приложениям.

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

В целом защита доступа к службам включает решение двух следующих задач.

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

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

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

2.5.2. Защита коммуникаций

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

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

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

2.6. Высокая готовность системы

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

В широком смысле простои делятся на две категории.

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

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

• Повышение надежности системы.

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

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

  Если система допускает эффективное, то есть автоматическое, восстановление после сбоя без потери целостности информации, последствия и продолжительность такого внепланового простоя будут гораздо меньше.
• Минимизация влияния на службы единичного сбоя.

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

  • доступность служб;
  • доступность сообщений.

2.6.1. Доступность служб

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

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

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

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

2.6.2. Доступность сообщений

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

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

Если подобное сообщение содержит критичные для бизнеса данные, становится важным его надежно восстановить. Восстановление "застрявших" сообщений должно поддерживать целостность хранимой в них информации.

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

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

2.6.3. Восстановление после сбоя

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

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

2.7. Мониторинг и учет операций

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

2.7.1. Мониторинг производительности

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

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

2.7.2. Учет

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

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