Управление доступностью в облачных вычислениях

Опубликовано: 20 Февраля, 2023

Предварительное условие: облачные вычисления и облачные сервисы

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

  1. Влияние на бизнес. В случае критически важных бизнес-приложений, когда предприятия полагаются на непрерывную доступность службы, даже несколько минут сбоя службы могут серьезно повлиять на производительность организации, доход, удовлетворенность клиентов и соответствие уровня обслуживания.
  2. Воздействие на клиентов. Во время сбоя облачной службы затронутые клиенты не смогут получить доступ к облачной службе, а в некоторых случаях могут снизиться производительность или качество работы пользователей. Например: когда служба хранения нарушена, это повлияет на доступность и производительность вычислительной службы, которая зависит от службы хранения.

Например, 20 декабря 2005 г. Salesforce.com (служба управления взаимоотношениями с клиентами по запросу) сообщила, что у нее произошел сбой системы, из-за которого пользователи не могли получить доступ к системе в рабочее время. Пользователи «испытывали прерывистый доступ» из-за ошибки кластера базы данных в одном из четырех узлов глобальной сети компании, говорится в заявлении представителей компании на следующий день после сбоя.

Факторы, влияющие на доступность:

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

Ниже приведен список основных факторов:

  • Избыточный дизайн приложений «Система как услуга» и «Платформа как услуга».
  • Архитектура ЦОД облачного сервиса должна быть отказоустойчивой.
  • Лучшее сетевое подключение и география в большинстве случаев могут предотвратить бедствие.
  • Клиенты облачного сервиса должны оперативно реагировать на сбои в работе службы поддержки поставщика облачных услуг.
  • Иногда сбой затрагивает только определенный регион или область облачных сервисов, поэтому в таких случаях сложно устранить неполадки.
  • Программное и аппаратное обеспечение, используемое для предоставления облачных услуг, должно быть надежным.
  • Инфраструктура сети должна быть эффективной и должна быть в состоянии справиться с атаками DDoS (распределенный отказ в обслуживании) на облачный сервис.
  • Отсутствие надлежащей защиты от внутренних и внешних угроз, например, злоупотребление привилегиями привилегированными пользователями.

Система как услуга Ответственность заказчика:

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

Мониторинг работоспособности системы как услуги:

Клиентам доступны следующие варианты, чтобы быть в курсе состояния их службы:

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

Платформа как обязанности заказчика услуг:

Следующие соображения относятся к клиентам Платформы как услуги:

  • Уровни обслуживания платформы PaaS: Клиенты должны прочитать и понять положения и условия соглашений об уровне обслуживания поставщика облачных услуг.
  • Уровни обслуживания стороннего поставщика веб-служб: если ваше приложение «Платформа как услуга» зависит от сторонней службы, очень важно понимать соглашения об уровне обслуживания этой службы. Параметры сетевого подключения со сторонними поставщиками услуг. Пример: коэффициенты пропускной способности и задержки.
  • Платформа как мониторинг работоспособности службы. Клиентам доступны следующие варианты мониторинга работоспособности службы:
    • Панель мониторинга состояния службы, опубликованная поставщиком облачных услуг.
    • Список рассылки клиентов поставщиков облачных услуг, который уведомляет клиентов о произошедших и недавно произошедших сбоях
    • Используйте сторонние инструменты для проверки работоспособности приложения
  • Мониторинг работоспособности инфраструктуры как услуги. Клиентам инфраструктуры как услуги доступны следующие параметры для управления работоспособностью службы:
    • Панель мониторинга работоспособности службы, опубликованная поставщиками облачных услуг.
    • Список рассылки клиентов поставщиков облачных услуг, который уведомляет клиентов о произошедших и недавно произошедших сбоях.
    • Сторонние инструменты мониторинга служб, которые периодически проверяют работоспособность вашей инфраструктуры как виртуального сервера службы.