Назад | Перейти на главную страницу

Максимальное увеличение производительности и пропускной способности 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 по тому же прямому кабельному каналу.

EDIT2: после завершения синхронизации я мог запустить iperf и обнаружил, что производительность составляла около 990 Мбит / с, медлительность была вызвана фактическим использованием набора данных.

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

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

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

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

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

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

Попробуйте разделить факторы, способствующие:

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

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

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