Мы постарались кратко описать путь, который прошла команда Timeweb за 10 лет: от rsync, LVM и DRBD к ZFS. Эта статья будет полезна тем, кто занимается масштабируемой серверной инфраструктурой, планирует делать резервные копии и заботится о бесперебойной работе систем.
Давайте поговорим о:
- rsync (удаленная синхронизация)
- DRBD (распределенное реплицируемое блочное устройство)
- инкрементное резервное копирование под DRBD с использованием LVM
- DRBD + ThinLVM
- ZFS (файловая система зеттабайт)
rsync и резервные копии BC e.
rsync (удаленная синхронизация) — вообще говоря, не о резервных копиях.Это программа, позволяющая синхронизировать файлы и каталоги в двух местах при минимизации трафика.
Синхронизация может выполняться как для локальных папок, так и для удаленных серверов.
Довольно часто для резервного копирования используется rsync. Мы использовали эту утилиту, когда сайты были проще и клиентов было значительно меньше.
Rsync проделал хорошую работу, но самая большая проблема здесь — скорость.
Программа работает очень медленно и создает большую нагрузку на систему.
А по мере увеличения данных он начинает работать еще дольше.
Rsync можно использовать в качестве технологии резервного копирования, но для очень небольшого объема данных.
LVM (диспетчер логических томов) — менеджер логических томов
Конечно, нам хотелось делать резервные копии быстрее и с наименьшей нагрузкой, поэтому мы решили попробовать LVM. LVM позволяет делать снимки даже с помощью ext 4. Таким образом, мы можем делать резервные копии с помощью снимка LVM. Мы использовали эту технологию недолго.Хотя резервное копирование выполнялось быстрее, чем в rsync, оно всегда было полным.
Но мы хотели скопировать только изменения, поэтому перешли на DRBD.
ДРБД
DRBD позволяет синхронизировать данные с одного сервера на другой.Причем синхронизируются только изменения, а не все данные.
Это существенно ускоряет процесс! Что касается хранилища, мы могли бы использовать LVM и делать снимки.
Эта система существовала очень давно и сейчас существует на некоторых серверах, которые нам пока не удалось перевести на новую систему.
Однако у этого метода все еще есть недостаток.
При синхронизации DRBD создает большую нагрузку на дисковую подсистему .
Это означает, что сервер будет работать медленнее.
В результате резервное копирование мешало работе основных сервисов, то есть пользовательских сайтов.
Мы даже пытались делать резервные копии ночью, но иногда они просто не успевали завершиться за ночь.
Приходилось маневрировать и чередовать резервные копии.
Например, сегодня работает одна часть серверов, потом другая.
Резервные копии были распределены в шахматном порядке.
DRBD к тому же сильно зависит от скорости сети и влияет на производительность сервера, с которого и на который производится резервное копирование.
Нужно искать новое решение!
Тонкий LVM
На этом этапе бизнес поставил задачу делать 30-дневные резервные копии, и мы решили перейти на ThinLVM. Это не решило главной проблемы! Мы даже не ожидали, что для поддержки тонких снимков потребуется такая высокая производительность файловой системы.Этот опыт оказался совершенно неудачным, и мы отказались от него в пользу обычных толстых LVM-снимков.
ThinLVM, по сути, был просто не предназначен для наших нужд. Изначально предназначался для небольших ноутбуков и камер, но не для хостинга.
Продолжаем поиск.
Было решено попробовать ZFS.
ZFS
ZFS — хорошая файловая система, имеющая множество встроенных вкусностей.То, что в ext 4 достигается установкой на LVM и подключением устройства DRBD, в ZFS это по умолчанию.
Сама файловая система очень надежна.
Отдельно стоит отметить функцию копирования при записи; эта технология позволяет обращаться с данными очень бережно.
ZFS позволяет делать снимки, которые можно скопировать в хранилище, а также автоматизировать резервное копирование.
Не нужно ничего придумывать! Переход на ZFS был очень осторожным.
Сначала мы создали стенд, на котором просто тестировали несколько месяцев.
В частности, пытались воспроизвести проблемы с оборудованием, питанием, сетью и заполненностью диска.
Благодаря тщательному тестированию нам удалось найти узкие места.
Больное место ZFS — переполнение диска.
Нам удалось решить эту проблему, зарезервировав пустое место.
При заполнении диска будут приняты меры по разгрузке сервера и очистке места.
После тестирования мы постепенно начали вводить новые сервера и переводить старые на ZFS. Больше никаких проблем с резервными копиями! Вы можете создавать резервные копии на 30 или 60 дней или даже каждый час.
В любом случае чрезмерных нагрузок сервер не будет испытывать.
Мы собрали все данные в таблицах ниже, чтобы сравнить резервные копии с использованием разных технологий.
Что произошло дальше?
Есть планы обновить ZFS до версии 2. ОпенЗФС 2.0.0. в 2021 году.Мы готовим переход, используя все возможности, которые были анонсированы с релизом в начале декабря.
Так оно и есть!
Это путь, который мы выбрали для себя! Вы решаете подобные проблемы? Будем рады, если вы поделитесь своим опытом в комментариях! Надеемся, статья оказалась полезной и, если вдруг вы тоже столкнетесь с задачей создания резервных копий с помощью встроенных в Linux утилит, наш рассказ поможет вам найти подходящее решение.Теги: #linux #Системное администрирование #zfs #lvm #backup #DRBD #timeweb
-
Мобильный Офис: Sparespace Против Custorus
19 Oct, 24 -
Анализ Посещаемости Сайтов Рунета
19 Oct, 24 -
Пишутся Сценарии Для Сериалов.
19 Oct, 24
