Максимизация rsync производительность и пропускная способность - непосредственно подключенные гигабитные серверы
Да это должно хорошо работать. Загрузитесь в свой Стандарт Windows Server 2008, вставьте диск Windows Server 2008 и выполните его. Введите ключ Предприятия Windows Server 2008 или выберите Windows Server 2008 Enterprise, и затем можно выполнить установку обновления.
http://technet.microsoft.com/en-us/library/cc755199 (WS.10) .aspx#BKMK_Supported
Количество файлов и накладные расходы на шифрование SSH, вероятно, являются самыми большими препятствиями. Вы не увидите такой скорости передачи данных.
Возможные варианты улучшения включают:
- Использование rsync + SSH с менее дорогостоящим алгоритмом шифрования (например,
-e "ssh -c arcfour") - Полное устранение шифрования через транспорт SSH с помощью чего-то вроде HPN-SSH .
- Блочная передача. Снимки,
dd, Отправка / получение снимка ZFS и т. Д. - Если это однократная или нечастая передача, с использованием
tar, netcat (nc), mbuffer или какая-то их комбинация. - Проверьте настройки CentOS
tuned-adm. - Удаление времени из монтирования файловой системы. Изучение других вариантов монтирования файловой системы.
- Буферы приема / передачи сетевых карт.
- Настройка команды
rsync. Будет ли здесь иметь смысл-W, опция целых файлов? Сжатие включено? - Оптимизируйте свою подсистему хранения для типа передачи (твердотельные накопители, счетчик шпинделей, кэш RAID-контроллера).
Как вы, наверное, знаете, копирование большого количества маленьких файлов (например, почтовых ящиков с использованием формата MailDir или аналогичного) определенно не лучший вариант для использования преимуществ интерфейсов с высокой пропускной способностью. SSH, вероятно, тоже не лучший транспортный протокол для этого. Я бы попытался использовать tar для создания tarball на исходном хосте, прежде чем отправлять его на вторичный хост.
tar c /var/mail | ssh root@secondary-host 'tar x -C /var/backups'
Если вам нужно инкрементное резервное копирование, вы можете попробовать параметры -g tar.
Если вам все еще нужно увеличить throuput, попробуйте использовать netcat вместо ssh.
Попытайтесь разделить факторы, способствующие:
- ЦП (например, dd of / dev / zero, пропущенный через петлю)
- дисковый ввод-вывод (например, dd of большой файл передан в cat> / dev / null [передан по каналу для предотвращения короткого замыкания])
- физический сетевой ввод-вывод (например, dd передан по каналу на другую машину)
- и т. Д.
и их независимое тестирование.
У меня был плохой опыт работы с драйверами Broadcom, поэтому мое первое предложение - проверить доступную пропускную способность сети с помощью:
dd if = / dev / zero bs = 1m count = 10k | rsh backup_host cat \> / dev / null