Поделиться
Не SLA единым: 8 способов самостоятельно повысить надежность облака
Клиент, обеспокоенный надежностью своих облачных сервисов, может ориентироваться не только на SLA документ от провайдера, но и собственными силами повысить надежность ИТ-инфраструктуры. В статье рассмотрены 8 вариантов для повышения показателя эффективности облачной инфраструктуры компании. Некоторые варианты применяются еще на стадии выбора провайдера, другие — при работе с ним.
Способ №1. Размещение у провайдера с несколькими ЦОД
Решение с несколькими ЦОД является самым эффективным в качестве повышения надежности облака. Если у такого провайдера возникают неполадки, то ИТ-сервисы продолжают работать на базе второго дата-центра. Таким образом, клиенту не нужно ждать ремонта и запуска оборудования.
Рейтинг провайдеров IaaS по размеру компенсаций
Тем не менее сохраняется время простоя, затрачиваемое на развертывание копии сервисов в облако. Для сокращения этого времени используется функция параллельной инфраструктуры с практически непрерывным резервным копированием данных. Информация о том, какими ЦОД располагают провайдеры, представлена в рейтинге IaaS 2022.
Способ №2. Наличие подтвержденного Tier ЦОД
Официально подтвержденный вендором Tier является одной из важных характеристик при выборе поставщика услуг. Если не рассматривать абстрактный показатель уровня доступности, выраженный в процентах (99,7% или 99,982%), то серьезная разница в уровнях надежности наблюдается между Tier I-II и Tier III-IV.
Начиная с третьего уровня более чем в десять раз снижается показатель годового простоя (1-2 часа в год). К тому же в ЦОД уровня III присутствует возможность обслуживания оборудования без его остановки. ЦОД Tier IV обладают еще меньшим показателем годового простоя и усложненной системой резервирования оборудования.
Более подробная статья об уровнях надежности Tier доступна по ссылке. Здесь же отметим, что наибольшее распространение получил Tier III. При этом считается, что размещение сервисов в двух ЦОД Tier III лучше, чем в одном ЦОД Tier IV.
Способ №3. Создание бэкапов
Качественным показателем услуг облачного провайдера является создание бэкапов, их доступность и скорость восстановления. Выделяют полный, инкрементальный и дифференциальных виды бэкапов. В первом случае создается полная копия всех данных. Во втором — изменения с момента последнего бэкапа, в третьем — с момента создания полной копии.
Обзор услуги резервного копирования BaaS 2022
При инкрементальном резервном копировании в случае аварии сначала должен быть восстановлен исходный полный бэкап, а потом вся история изменений. Если одни и те же данные или настройки менялись несколько раз, в случае инкрементального бэкапа будут сохранены и повторены все эти изменения. При дифференциальном бэкапе будет развернута исходная полная копия и сразу применены самые последние актуальные настройки.
Способ №4. Использование услуги аварийного восстановления DRaaS
DRaaS — облачный сервис, обеспечивающий восстановление работоспособности виртуальных серверов из резервных ЦОД в кратчайшие сроки. Наличие услуги DRaaS является наилучшим решением при выборе провайдера с несколькими ЦОД, так как DRaaS позволяет развернуть облачные сервисы за считанные минуты.
Обзор услуги резервного копирования DRaaS 2021
Это происходит за счет непрерывного копирования данных на резервный ЦОД, соединение происходит через автоматически создаваемый VPN-туннель. DRaaS также обеспечивают защиту от внешних сетевых атак.
Обычно в услугу DRaaS входит:
- Резервное копирование данных
- Репликация данных на виртуальный резервный ЦОД
Использование аварийного восстановления как услуги позволяет разгрузить компанию от функций бэкапа и репликации и отдать реализацию этих функций облачному провайдеру.
Способ №5. Подготовка плана аварийного восстановления DRP
Disaster Recovery Plan — это план восстановления всех компьютерных систем после аварии. Он представляет собой документ с подробным описанием регламента действий при устранении последствий аварии и последующим восстановлением данных. Такой план позволяет компании быстрее восстановить критическую инфраструктуру после сбоя, сохранить важные данные и обеспечить работу критически важных сервисов во время аварийного простоя оборудования.
Следует учитывать, что DRP может понадобится только компаниям с собственный ИТ-отделом, в ином случае DRP относится к компетенции провайдера. При составлении DRP следует уделить внимание следующим параметрам:
- Сотрудники, отвечающие за аварийное восстановление (DR) и уровни доступа.
- Предварительная оценка рисков. Риски можно проанализировать самостоятельно, либо отдать на аутсорс. При этом их подразделяют на внешние (например, санкции, сетевые атаки), внутренние (человеческий фактор, аппаратные сбои) и другие (например, природные и экологические процессы).
- Определение критически важных бизнес-процессов и данных. Следует рассмотреть свои бизнес-процессы и оценить их важность в отказоустойчивости. Высокий, средний и низкий уровни важности отказов можно соотнести с размером компании: высокий нужен крупным ИТ или банковским компаниям, низкий — малому бизнесу.
- Бюджет (с ценами можно ознакомиться на странице услуги DRaaS в ИТ-маркетплейсе Market.CNews).
- Потребность в подрядчиках при выполнении восстановительных работ, а также их компетентность.
- Необходимые уровни доступности. Исходя из анализа степени важности бизнес-процессов, выбирают DRP с постоянной доступностью, непрерывным режимом работы и высокой доступностью.
- Учет требований законов и стандартов.
- Быстрое восстановление или параллельная инфраструктура. Быстрое восстановление обеспечивает большинство потребностей бизнеса, где сохранность актуальных данных не является критически важной. При параллельной инфраструктуре данные полностью дублируются, скорость репликации между основным и резервными серверами не превышает 30 секунд (актуально для банковских структур и государственных сервисов).
Способ №6. Защита на уровне ПО
В плане программного обеспечения следует уделять внимание двум факторам:
- ПО на стороне провайдера, применяемое для создания облака. В первую очередь речь идет о платформе виртуализации (гипервизоре). Ранее Market.CNews выпускал обзоры основных гипервизоров: VMware, KVM, Hyper-V, XEN.
- ПО заказчика, которое будет работать из облака. Тут ИТ-специалистами прорабатывается целый комплекс вопросов: работоспособность того или иного ПО из облака, интеграция различных видов ПО, самостоятельная установка и наладка ПО или использование сервисов SaaS и др.
Способ №7. Работа с провайдером как с партнером
Крупный облачный провайдер аккумулирует у себя лучшие кадры рынка, благодаря этому складывается обширная практика решения проблем. Такой провайдер всегда готов помочь советом или действием, так как обладает практическим опытом решения многих не типовых задач.
Об этом говорят и сами провайдеры. Одно из конкурентных преимуществ, активно декларируемое некоторыми из них, — наличие компетентной службы поддержки, специалистов по миграции в облака и настройке облачной платформы.
Тенденции на рынке IaaS таковы, что провайдерам выгодно долгосрочное сотрудничество, а для этого им проще помочь клиенту с решением тех или иных задач, нежели выстраивать заградительный бюрократический барьер.
Способ №8. Если дело дошло до компенсаций по SLA
Если аварийная ситуация вышла из-под контроля, и дело дошло до компенсаций, предусмотренных SLA между компаниями, то и здесь есть несколько рекомендаций:
- Зафиксировать аварию и сообщить о ней следует как можно быстрее. У ряда провайдеров отсчет простоя начинается не от фактического времени аварии, а от момента открытия тикета.
- Объяснив ситуацию, можно получить компенсацию выше оговоренной в SLA. Этот момент никак не задокументирован, но провайдеры достаточно открыто говорят о нем на конференциях и в кулуарах. Учитывая необходимость построения партнерских отношений с клиентами, о чем было сказано в предыдущем параграфе, провайдерам может быть выгодно выделить клиенту компенсацию сверх SLA ради сохранения долгосрочных партнерских отношений.
- Следует собрать и сохранить лог-файлы собственных ИТ-систем, в которых могут быть отметки времени о последней успешной операции (т.е. начале аварии) и первых успешных операциях после аварии.
Перейти к обзору SLA IaaS 2022
Короткая ссылка
