Мне нужно выполнить резервное копирование сотен гигабайт на месте с нескольких виртуальных машин Xen в хранилище, доступное на выделенном сервере в той же сети с гигабитным соединением. Данные в основном представляют собой данные MySQL (я использую Percona XtraDB Cluster), которые резервируются локально на серверах с помощью Xtrabackup, поэтому я предполагаю, что эти данные должны быть хорошо сжимаемыми.
В данный момент я использую duplicity 0.6.08b с шифрованием с помощью парольной фразы (я не использую ключи), так как я также rsync резервных томов, созданных с помощью duplicity, в какое-то внешнее хранилище. Уровень сжатия в настоящее время составляет 6, а размер тома — 250. Резервное копирование занимает больше дня, поэтому я ищу рекомендуемые настройки duplicity, которые обеспечат быстрое резервное копирование в локальное сетевое хранилище, не занимая при этом слишком много места.
Есть идеи?
решение1
В комментарии вы пишете, что видите пропускную способность около 50 МБ/с при резервном копировании.
50 МБ/с — этов порядкечто вы можете ожидать от полуслучайной пропускной способности диска с одиночными вращающимися ржавыми дисками (т. е. не зеркалированным или чередующимся RAID, чтобы позволить чтениям распределяться по дискам для увеличения пропускной способности). Обратите внимание, что некоторые конфигурации RAID фактически ограничивают даже лучшую пропускную способность до пропускной способности самого медленного диска. Да, многие жесткие диски рассчитаны на ~200 МБ/с, но имейте в виду, что эти цифры являются лучшими числами последовательного доступа. 50 МБ/с также составляют около 400 Мбит/с, что с некоторыми подтасовками для IP-накладных расходов и т. д. составляет 500-600 Мбит/с на сетевом проводе, так что, хотя вы не насыщаете гигабитный канал только этим, вы довольно близко подходите к территории, где возможны коллизии.
Вы не приводите никаких цифр по использованию ЦП во время резервного копирования, за исключением того, что у вас «есть три гипервизора с кучей виртуальных машин на каждом, более или менее занятых». Но копирование данных и их сжатие не так уж сильно нагружают ЦП, и если во время резервного копирования у вас есть свободное время ЦП, то вы не ограничены ЦП.Единственный способ ответить на этот вопрос — выяснить, какой фактор ограничивает пропускную способность.и затем сосредоточьте свои усилия на этом.
Мое предположениебудет означать, что вы ограничены вводом-выводом, либо при чтении, либо при записи, и что вымощьбыть привязанным к сети. Вы говорите о выделенном сервере хранения резервных копий с гигабитным Ethernet-подключением, но ничего не говорите о природе этого подключения. Является ли сетевое подключение для резервного копирования между физическими хостами общим или выделенным? (Отдельная физическая сеть, соединяющая каждый из HV с сервером резервного копирования, была бы приемлемой, если только одна VM или HV одновременно отправляет данные резервного копирования.)
Если физическое сетевое подключение к резервному серверу используется совместно с другим сетевым трафиком, вы можете перейти на архитектуру выделенного подключения. Насколько вы получите от этого выгоду, во многом зависит от того, где сжимаются данные и сколько коллизий вы действительно видите в настоящее время, но если вы сделаете это и ничего больше, вымощьиметь возможность удвоить пропускную способность сети и, таким образом, если вы ограничены сетью, сократить время резервного копирования вдвое.
Если вы ограничены вводом-выводом при чтении и/или записи, то переход к зеркальной или чередующейся настройке, которая позволяет распределить дисковый ввод-вывод по нескольким дискам, может помочь увеличить пропускную способность; это увеличит общую пропускную способность шины диска. Конечно, это имеет свои недостатки. В зависимости от того, сколько данных вы передаете в любой момент времени, добавление большего количествабыстрыйкэширование диска на сервере резервного хранениямощьтоже помогает, но я подозреваю, что если вы ограничены вводом-выводом, то это на стороне чтения, поскольку записи, вероятно, более или менее последовательны, и в этом случае добавление кэша вам не сильно поможет.
Вы также можете рассмотреть возможность перехода на файловую систему на виртуальных машинах или HV и/или на сервере резервного хранения, которая выполняет сжатие данных на лету при записи на диск, или включить такое сжатие, если оно поддерживается. Это будет стоить процессорного времени, но увеличитэффективныйскорость передачи данных на диске, поскольку меньше данных должно быть перемещено на физические пластины и с них для того же объема хранимых данных пользовательского пространства. Будет ли это чистым выигрышем в любой ситуации, по сути, это вопрос подбрасывания монеты, и его нужно оценивать в каждом конкретном случае, но это, безусловно, одинвозможностьдля ситуации, когда вы ограничены вводом-выводом, особенно если данные изначально сильно сжимаемы. Даже если данные можно сжать только на 20% (что эквивалентно коэффициенту сжатия 1,25:1 и, безусловно, достижимо, например, для текста на естественном языке; для сравнения, ZFS с компрессией gzip-9 дает мне сжатие 1,20:1 на выборке веб-сайтов Интернета,включая изображения), те же самые скорости передачи данных по пластинам в 50 МБ/с внезапно дают вам более 60 МБ/с полезных данных, передаваемых при условии, что центральный процессор может справиться с компрессией и декомпрессией.Обратите внимание, что зашифрованные данныепредполагаемыйсжимать крайне плохо, поскольку это будет напоминать случайный шум; обычно сжатие выполняется перед шифрованием, если вы планируете шифровать данные, в этом случае сжатие на уровне файловой системы на зашифрованной стороне не принесет вам никакой пользы.