Резервное копирование через распределенные файловые системы

Резервное копирование через распределенные файловые системы

Надеюсь, я смогу сформулировать свой вопрос как можно точнее.

Я ищу способ делать резервные копии для моих vm-серверов как можно скорее и чаще, поскольку данные, которые они обрабатывают/создают, представляют ценность. У меня есть KVM-хост и как минимум 2 гостя: веб-сервер (Apache/PHP) и сервер баз данных (MySQL/Solr). Мне не важен хост, мне важны гости. Я не хочу, чтобы вы углублялись в KVM или виртуализацию для этой темы. Эта тема должна быть применима ко всем средам на основе vm, а также ко всем другим средам. Сценарий vm подходит хорошо, потому что он более сложный и представляет собой одну из самых сложных ситуаций в моем воображении. По крайней мере, мне это нужно на этой основе.

В настоящее время у меня есть резервные копии in-vm и снимки на основе LVM, которые я генерирую 1-2 раза в день. В случае аппаратного сбоя (который у меня недавно был) я в лучшем случае потеряю целую кучу данных.

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

Другим интересным способом, по-видимому, является использование распределенной файловой системы. Идея заключается в том, чтобы иметь файловую систему, которая действует немного как двоичный журнал MySQL. Или более обобщенно: она захватывает все действия записи в файловой системе и асинхронно реплицирует их на другую машину. В зависимости от сети и объема записанных данных, это может закончиться задержкой в ​​секунды или минуты, и, само собой разумеется, она пропускает все действия, которые удерживаются в кэше. Итак, у меня есть виртуальная машина, которая находится в распределенной файловой системе, установленной на хосте виртуальной машины. Каждое действие записи затем асинхронно применяется на (скажем) резервном сервере. Когда дело доходит до аппаратного сбоя, я могу переключиться на резервный сервер (теоретически) как на новый главный сервер или просто скопировать файлы обратно на восстановленный главный сервер в случае, если время простоя более приемлемо, чем потеря данных. Эффект должен быть таким, что виртуальная машина будет вести себя так, как будто она была выключена немедленно за несколько секунд или минут до этого. Но не часов. Я не ищу репликацию master-master на уровне файловой системы, так как она не поддерживается большинством приложений, особенно серверами баз данных, такими как MySQL!

Итак, мой вопрос: есть ли кто-нибудь, кто уже имел опыт работы с такими конфигурациями или имеет знания, которые являются как положительными, так и отрицательными для этой попытки резервного копирования данных? У меня нет глубокого опыта работы с этими файловыми системами. Особенно в плане надежности и производительности.

решение1

Распределенная файловая система — это не резервное копирование, это избыточность. Она также «резервирует» ваши случайные удаления.

Тем не менее,ДРБД.

решение2

Лучшим возможным ответом на вашу ситуацию является кластерное хранилище, в котором данные избыточно хранятся на уровне блоков. Существует несколько различных способов реализовать это, но лучшее, что я могу себе представить (по крайней мере, в соответствии с вашими требованиями к времени безотказной работы), — это кластер с открытым стеком. Openstack распределит как хранилище, так и вычисления, так что в случае отказа оборудования и выполнение, и хранение будут избыточными и непрерывными. Другими словами, лучший способ сохранить целостность данных и время безотказной работы — убедиться, что приложение изначально не зависнет. Как указал yoonix, это не защитит вас от пользовательских/логических ошибок, но Open Stack также включает инструменты для создания образа диска/резервного копирования — загрузка образа и загрузка занимают минуты, если не секунды. Amazon Web Services и Rackspace являются примерами развертываний OpenStack. http://www.openstack.org/

Хорошим местом для начала работы с OpenStack является devstack (по сути, скрипт развертывания с различными режимами развертывания для тестирования). http://devstack.org/

Слабость этой реализации — нехватка оборудования, эта система не очень хороша в небольшом офисе с двумя физическими серверами или чем-то подобным (хотя отлично работает с блейд-системами).

решение3

Рассматривали ли вы возможность перехода на платформу VMware и использования их решений для этого?

'Fault Tolerance' (используя vLockstep) поддерживает вторую 'резервную' копию любой виртуальной машины в актуальном состоянии со всеми изменениями, внесенными в основную версию виртуальной машины. Если что-то случается с основной версией, система немедленно переключается на вторичную виртуальную машину. (незначительное время простоя или отсутствие влияния)

«Высокая доступность» поддерживает резервную ВМ в состоянии готовности, но резервная ВМ остается выключенной. В случае отказа основной ВМ система автоматически включает резервную ВМ. (несколько минут простоя)

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

Связанный контент