Максимальная производительность и пропускная способность rsync - гигабитные серверы с прямым подключением

У меня есть два сервера Dell R515 под управлением CentOS 6.5, с одним из сетевых адаптеров Broadcom в каждом, напрямую подключенным к другому. Я использую прямую ссылку для передачи резервных копий с основного сервера в паре на вторичный сервер каждую ночь, используя rsync через ssh. Наблюдая за трафиком, я вижу пропускную способность ~ 2 Мбит / с, что намного меньше, чем я ожидаю от гигабитного порта. Я установил MTU на 9000 с обеих сторон, но это ничего не изменило.

Есть ли рекомендуемый набор настроек и оптимизаций, которые позволили бы мне достичь максимальной доступной пропускной способности? Более того, поскольку я использую rsync поверх ssh (или, возможно, просто NFS) для копирования миллионов файлов (~ 6 ТБ небольших файлов - огромный почтовый магазин Zimbra), оптимизация, которую я ищу, может быть более специфичной для моего конкретного случая использования. ,

Я использую ext4 с обеих сторон, если это имеет значение

Благодарность

РЕДАКТИРОВАТЬ: я использовал следующие rsyncпараметры с довольно похожими результатами:

rsync -rtvu --delete source_folder/ destination_folder/

rsync -avHK --delete --backup --backup-dir=$BACKUPDIR source_folder/ destination_folder/

В настоящее время я наблюдаю тот же уровень плохой производительности при использовании cpэкспорта NFS по той же прямой кабельной линии связи.

РЕДАКТИРОВАТЬ 2: после завершения синхронизации я смог запустить iperfи обнаружил, что производительность была около 990 Мбит / с, медлительность была вызвана фактическим использованием набора данных.

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

Варианты для улучшения включают в себя:

• Использование rsync + SSH с менее затратным алгоритмом шифрования (например -e "ssh -c arcfour")
• Полностью исключить шифрование по протоколу SSH с помощью чего-то вроде HPN-SSH .
• Блочные переводы. Снимки dd, отправка / получение снимков ZFS и т. Д.
• Если это однократная или нечастая передача, используйте tarnetcat ( nc), mbuffer или некоторую комбинацию.
• Проверьте tuned-admнастройки CentOS .
• Удаление atime из ваших файловых систем монтируется. Изучение других параметров монтирования файловой системы.
• NIC отправлять / получать буферы.
• Настройка вашей rsyncкоманды. Будет ли -Wздесь полезен вариант с целыми файлами? Сжатие включено?
• Оптимизируйте свою подсистему хранения для типа передачи (SSD, число шпинделей, кэш контроллера RAID).

Как вы, наверное, знаете, копирование большого количества маленьких файлов (например, почтовых ящиков в формате MailDir или аналогичных) определенно не лучший вариант, чтобы использовать преимущества интерфейсов с высокой пропускной способностью. SSH, вероятно, не лучший транспортный протокол для этого. Я бы попробовал использовать tar для создания архива на исходном хосте, прежде чем отправить его на ваш вторичный хост.

tar c /var/mail | ssh root@secondary-host 'tar x -C /var/backups'

Если вам нужно инкрементное резервное копирование, вы можете попробовать -gопции tar. Если вам все еще нужно увеличить throuput, попробуйте использовать netcat вместо ssh.

Попытайтесь дразнить обособленные факторы:

• CPU (например, дд / dev / zero по конвейеру)
• дисковый ввод / вывод (например, dd большого файла, переданного в cat> / dev / null [piped для предотвращения короткого замыкания])
• физический сетевой ввод / вывод (например, dd передается на другую машину)
• и т.п.

и тестировать их самостоятельно.

У меня были некоторые неудачные опыты с драйверами Broadcom, поэтому мое первое предложение состоит в том, чтобы проверить полезную пропускную способность сети с: dd if=/dev/zero bs=1m count=10k | rsh backup_host cat \> /dev/null