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

У мене є два сервери Dell R515, на яких працює CentOS 6.5, причому один з широкоформатних NIC в кожному безпосередньо приєднаний до іншого. Я використовую пряме посилання, щоб щовечора підсилювати резервні копії з основного сервера в парі на вторинний за допомогою rsync over ssh. Контролюючи трафік, я бачу пропускну здатність ~ 2 Мбіт / с, що набагато менше, ніж я очікував від гігабітного порту. Я встановив MTU на 9000 з обох сторін, але це, здається, нічого не змінило.

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

Я використовую ext4 з обох сторін, якщо це має значення

Спасибі

EDIT: Я використав наступні 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 знімок відправити / отримати , і т.д.
• Якщо це разова або нечаста передача, використовуючи tarnetcat ( nc), mbuffer або якусь комбінацію.
• Перевірте свої tuned-admнастройки CentOS .
• Видалення аніме з кріплення вашої файлової системи. Вивчення інших параметрів кріплення файлової системи.
• Буфери для передачі / прийому NIC.
• Налаштування rsyncкоманди. Буде чи -W, в цілому-файли опція має сенс тут? Чи ввімкнено стиснення?
• Оптимізуйте підсистему зберігання даних щодо типу передачі (SSD, кількість шпинделів, кеш-пам'ять контролера RAID.)

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

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

Якщо вам потрібно додаткове резервне копіювання, ви можете спробувати -gваріанти tar. Якщо вам все ж потрібно максимально використовувати титру, спробуйте використовувати Netcat замість ssh.

Спробуйте роздрібнити фактори, що сприяють:

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

і перевірити їх самостійно.

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