Доступность и безотказность: почему бэкапы обречены?

Статья основана на данных компании Veeam Software.

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

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

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

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

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

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

Нельзя полагаться исключительно на резервирование.

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

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

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

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

Задайте себе вопрос: если произойдет какая-то поломка, сможем ли мы достаточно быстро восстановиться только лишь из резервных копий? Безусловно, резервирование еще применяется. К примеру, если у вас есть виртуальная машина, которая периодически резервируется, то, в случае поломки исходной виртуальной машины, будут утеряны только те данные, которые не успели попасть в резервные копии. Сохранение всех важных данных, которые размещались на поврежденном сервере, сыграет значительную роль в обеспечении восстановления. Однако, резервирование как единственный способ обеспечения безотказности – это уже не выход.

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

Зазор доступности.

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

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

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

Определение доступности через резервирование.

Удобно оперировать зазором доступности как концепцией, однако без ряда конкретных рекомендаций это понятие вряд ли может помочь в построении безотказного датацентра. В случае резервирования, оперируют понятиями «показатель времени восстановления» (ПВВ) и «показатель точки восстановления» (ПТВ). Эти показатели значительно варьируются от системы к системе. Можно говорить о непрерывной доступности, когда ПВВ и ПТВ составляют менее 15 минут каждый. При чем это время не только на восстановление одиночного сервера или приложения, потенциально за это время может быть восстановлена вся структура, приложения и данные.

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

Достичь непрерывной доступности.

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

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

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

  • Окно восстановления: 15 минут – это всего лишь ориентировочное число. В ходе планирования восстановительных мероприятий Вы можете выработать значение окна восстановления, которое удовлетворит именно Ваши бизнес-процессы.
    Методы восстановления: могут включать дублирование данных, снимки системы, синхронизацию дисков, резервирование данных и другие методы.
  • Цели восстановления: можно сконцентрироваться на физических датацентрах, общественных или закрытых облачных хранилищах.
  • Управление восстановлением: нужно выбрать, кто будет проводить восстановительные мероприятия. Это может быть Ваша ИТ-команда или приглашенные специалисты. Управлять следует инфраструктурой, процессом резервирования и восстановления, репозиториями и прочим.

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

Восстановление: практика важнее концепции.

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

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

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

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

Достижение доступности.

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

Похожие новости