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