Резервное копирование и восстановление OpenStack: лучшие практики

OpenStack — это платформа облачных вычислений с открытым исходным кодом, которая набирает популярность в Казахстане. Но как защитить данные в OpenStack. Давайте рассмотрим лучшие практики резервного копирования и восстановления OpenStack

Введение в OpenStack

OpenStack — это платформа облачных вычислений с открытым исходным кодом, которая предоставляет как структуру, так и набор инструментов для создания и контроля частной и публичной облачной инфраструктуры.

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

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

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

Компоненты OpenStack

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

• Вычислительный компонент под названием Nova. Управляет службами виртуализации и оркестрации для работы с виртуальными машинами (ВМ), облегчая создание, управление и масштабируемость виртуальных машин.
• Компонент хранилища под названием Swift и Cinder. Первый представляет собой распределенную объектную систему хранения, предназначенную исключительно для хранения данных — документов, носителей и т. д. Второй предлагает услуги блочного хранения, позволяющие подключать и управлять томами хранения для виртуальных машин.
• Сетевой компонент под названием Neutron. Предлагает работу в сети как услугу, позволяющую создавать и управлять сетями, подсетями и маршрутизаторами с поддержкой различных сетевых топологий.
• Компонент информационной панели под названием Horizon. Графический веб-интерфейс пользователя (GUI) для OpenStack, упрощающий управление ресурсами для администраторов и пользователей.
• Компонент идентификации под названием Keystone. Эта служба идентификации и аутентификации обрабатывает аутентификацию пользователей и ролей и обеспечивает централизованный контроль доступа.
• Компонент сервиса изображений под названием Glance. Управляет и хранит образы виртуальных машин, оптимизируя развертывание экземпляров с предопределенными конфигурациями.
• Компонент оркестрации под названием Heat. Служба оркестрации, которая позволяет определять облачную инфраструктуру и управлять ею в виде кода, упрощая создание целых облачных приложений и управление ими с помощью шаблонов.
• Компонент телеметрии под названием Ceilometer. Предоставляет услуги измерения и мониторинга для отслеживания использования ресурсов в облачной среде, помогая в выставлении счетов, отслеживании использования и мониторинге производительности.
• Компонент базы данных под названием Trove. Предлагает базу данных как услугу, упрощая управление, предоставление и масштабирование баз данных в облаке.
• Компонент, связанный с контейнером, под названием Magnum. Используется для оркестрации и управления контейнерами, поддерживает популярные контейнерные технологии, такие как Docker и Kubernetes.
• Компонент рабочего процесса под названием Mistral. Предлагает несколько средств управления рабочими процессами с использованием разных языков на основе YAML.
• Компонент под названием Sahara. Создан для быстрого и простого способа предоставления кластеров Hadoop.
• Компонент обмена сообщениями под названием Zaqar. Многопользовательское облачное приложение для обмена сообщениями с полной поддержкой RESTful API, которое является одновременно безопасным и быстрым.
• Общий компонент FS под названием Manila. Предлагает API для управления общими ресурсами в независимой от поставщика среде.
• Компонент DNS под названием Designate. Предоставляет высокофункциональный REST API для управления DNS.
• Ключевой компонент управления под названием Barbican. Он безопасно хранит ключи и управляет ими, что полезно во всех средах.
• Компонент анализа событий под названием Vitrage. Предлагает сложную систему управления событиями для OpenStack. Это служба анализа событий, содержащая множество сведений о проблемах и способах их решения.
• Компонент действий по тревоге на основе правил, называемый Aodh. Включает сигналы тревоги на основе действий с высокой степенью настройки.

Некоторые из компонентов считаются «основными компонентами» из-за того, как большинство пользователей OpenStack используют их тем или иным образом или в той или иной форме. Этими компонентами являются Nova, Heat, Glance, Keystone, Swift, Horizon, Neutron, Cinder и Ceilometer.

Резервное копирование в OpenStack

Создание резервных копий данных для восстановления в случае катастроф или сбоев не просто важно; это абсолютно необходимо. Этот принцип применим ко всем аспектам управления данными, включая резервное копирование экземпляров и томов OpenStack. ИТ-команды рассматривают OpenStack как нечто универсальное – главным образом потому, что OpenStack по своей сути является платформой с открытым исходным кодом, которая пытается использовать открытые стандарты везде, где это возможно.

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

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

• Резервное копирование всех данных, а не только виртуальных машин

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

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

• Обратите внимание на ключевые параметры резервного копирования (особенно, когда речь идет об аварийном восстановлении).

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

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

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

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

• Обязательно узнайте как можно больше об основных модулях OpenStack.

OpenStack состоит из отдельных программных компонентов, которые совместно обеспечивают предоставление облачных услуг. Сообщество OpenStack признает девять основных компонентов: Horizon, Glance, Nova, Heat, Keystone, Swift, Neutron, Ceilometer и Swift. Особого внимания в отношении резервного копирования заслуживает Cinder, компонент блочного хранилища, отвечающий за предоставление томов для экземпляров OpenStack.

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

• Не пропускайте официальную документацию OpenStack.

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

• Попробуйте узнать больше о степени интеграции вашего решения для резервного копирования с OpenStack.

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

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

Существующие встроенные методы резервного копирования для OpenStack

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

Возможности резервного копирования и восстановления OpenStack можно разделить на две большие группы в зависимости от того, как их можно запустить – это можно сделать с помощью графического интерфейса (OpenStack Horizon) или с помощью базового интерфейса командной строки (OpenStack Cinder).

Резервное копирование OpenStack Horizon

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

• Первый шаг — запустить OpenStack Horizon.
• Теперь вам нужно найти список активных в данный момент томов (Project > Volumes > Volumes).
• После выбора тома в раскрывающемся меню в правой части экрана должно быть несколько опций, в том числе опция «Create Backup».
• Это действие должно открыть новый экран с различными полями для заполнения, такими как поле названия резервной копии «Backup Name».
• После заполнения всех полей остается только запустить процесс резервного копирования и дождаться его завершения.
• Саму резервную копию можно найти на странице «Backup» (Project > Volumes > Backups) с отдельным столбцом «Status», показывающим текущий статус каждого задания резервного копирования.

Как видите, рассматриваемый процесс достаточно прост и не так уж и сложен. То же самое можно сказать и о создании резервных копий OpenStack на основе инстансов:

• Первый шаг очень похож на предыдущий пример — запуск OpenStack Horizon.
• Следующий шаг — найти список текущих доступных экземпляров (Project > Compute > Instances).
• Кнопка «Create Snapshot» должна быть доступна сразу же после выбора конкретного экземпляра.
• Список существующих на данный момент снимков можно найти, выбрав Project > Compute > Images. Он показывает общий список снимков, их текущий статус, параметры восстановления и многое другое.

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

Резервное копирование OpenStack Cinder

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

Первый тип резервной копии, который мы здесь используем, — это снимок на основе тома:

1. Первый шаг — запросить список текущих томов и их параметров с помощью следующей команды
   
   $ openstack volume list
2. Следующим шагом будет запуск самой процедуры резервного копирования с помощью другой команды (используя имя резервной копии, полученное на предыдущем шаге).
   
   $ openstack volume backup create volume-5 \ –force
3. Последний шаг — проверить вновь созданную резервную копию с помощью другой команды (и UUID резервной копии, который был показан в конце предыдущего шага).
   
   $ openstack volume backup show volume-backup-UUID

Также возможно создать резервную копию базового тома, используя ту же последовательность, что показана выше, за исключением флага –force. Этот флаг позволяет продолжить резервное копирование даже для томов со статусом in-use (например, томов, подключенных к экземпляру).

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

Второй тип резервной копии — это снимок экземпляра на основе образа с несколько иной комбинацией операций:

1. Первым шагом будет запрос списка активных в данный момент серверов и их UUID с помощью следующей команды:
   $ openstack server list
2. Следующий шаг — задача создания резервной копии со своей уникальной командной строкой.
   $ openstack server backup create instance-1
3. Подтверждение статуса вновь созданного снимка также является необходимостью, для чего и предназначена следующая команда.
   $ openstack volume backup show backup-UUID –fit-width

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

Другие особенности и нюансы OpenStack Cinder

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

В этом сценарии backup-2 — это точный идентификатор самой резервной копии, а volume-4 — это имя экземпляра, в который восстанавливается резервная копия.

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

Последней темой здесь будет отмена задачи. Теперь можно отменить как операции резервного копирования, так и восстановления, хотя обе эти функции были добавлены не так давно. Возможность отмены текущей операции резервного копирования была добавлена ​​в октябре 2015 года в выпускной версии Liberty, а возможность отмены текущих операций восстановления присутствует с августа 2018 года в выпускной версии Rocky.

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

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

В этом сценарии рекомендуется использовать статус error операции, чтобы впоследствии не возникало путаницы относительно того, был ли сам процесс успешным или нет. Основная причина этого заключается в том, как OpenStack обрабатывает восстановленные тома: невозможно получить доступ к отмененному целевому тому, чтобы узнать, были ли вообще восстановлены какие-либо данные.

Сторонние решения резервного копирования для OpenStack

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