Мы хотим установить несколько серверов в удаленном центре обработки данных, чтобы они действовали в качестве хранилища резервных копий для нашего основного центра обработки данных.
Предполагая, что оба сайта будут иметь соединение GigE, какой метод лучше всего использовать для быстрой передачи файлов? Мне нравится rsync, однако, поскольку у нас много данных для передачи (1,5 ТБ за ночь), я думаю, что протокол SSH, используемый в rsync, может сильно замедлить работу :(
Мы могли бы установить несколько быстрых конечных точек VPN для обеспечения шифрования ссылок, однако вопрос все еще остается открытым: какой инструмент является лучшим для фактической передачи?
Производительность резервного копирования определяется многими факторами. Пропускная способность является одним из них.
Часто определяется скоростью записи в хранилище.
Хороший вариант - запустить rsync в режиме демона на сервере резервного копирования, при этом вы избежите использования ssh. Однако, если у вас нет действительно медленные процессоры, накладные расходы ssh не будут значительными.
Чтобы запустить rsync в качестве демона, запустите демон rsync на сервере
rsync --daemon
По умолчанию он прослушивает TCP-порт 873, вы можете изменить его в rsyncd.conf.
Затем используйте rsync как
rsync [OPTIONS] source-path \
rsync://backup_username@backup-server:873:destination-path
Недостаточно информации, чтобы дать оценку вашей ожидаемой производительности. Однако ежедневное добавление 1,5 ТБ не невозможно.
Во время резервного копирования вы объединяете операции записи с несколькими операциями файловой системы. Запросы и обновления файловой системы. Как правило, рекомендуется запускать несколько процессов rsync, чтобы скрыть задержку при создании файла.
Я думаю, что дельта 1,5 ТБ в день - это немного выше обычного размера для таких решений, как rsync. SSH имеет архитектурный предел на уровне 2–3 МБ / с IIRC, и, как было написано ранее, протокол rsync по умолчанию намного быстрее, но не зашифрован.
Вам действительно стоит взглянуть на решения, специально разработанные для синхронизации этих объемов данных. Раньше я работал с Quantum DXi устройства, которые являются устройствами хранения, но также предлагают дедупликацию и зашифрованную репликацию. Возможно, вы захотите взглянуть на них.
/ edit: Чтобы немного расширить мое приведенное выше утверждение, важно принять во внимание следующие моменты при измерении скорости SSH:
Большим преимуществом дедупликации здесь будет то, что данные дедуплицируются на уровне блоков. Это означает, что если вы создадите один tar (не сжатый!) Для каждого клиента и разместите одно из устройств DXi на вашем основном сайте, это устройство автоматически устранит повторяющиеся блоки в потоке файлов (например, 100 клиентов имеют один и тот же фильм в своем tar - он будет сохранен только один раз и будет использоваться еще 99 раз), и блоки также будут сжаты.
Если вы затем добавляете второй за пределами площадки, только уникальные блоки данных передаются второму устройству. Благодаря этому вы фактически можете выполнять ежедневное полное резервное копирование на своем основном сайте, и только размер вновь записанных уникальных блоков должен быть передан через WAN на удаленный сайт.
Кроме того, убедитесь, что ни одна из сторон не использует действительно старые версии rsync. По-прежнему используются версии 2.x, из-за которых вся цепочка возвращается к более старой и в некоторых случаях гораздо менее эффективной версии протокола (если вам сказали «отправить дополнительный список файлов», все в порядке. Если это "список отправляемых файлов", то есть используется протокол 2.x.)
Вы можете изучить программное обеспечение для ускорения файлов. Я думаю, что на этом рынке много игроков, но я видел, как раньше использовал aspera. Вот страница сравнения aspera sync и rsync (сравнительные таблицы внизу страницы).
http://asperasoft.com/en/products/synchronization_23/aspera_sync_23
кто-то упомянул здесь, используя демон rsync - это гораздо более «легкое» решение, чем туннелирование трафика по ssh. но даже при инкапсуляции ssh передача 1,5 ТБ за ночь и насыщение гигабитного канала вполне выполнимо.
предполагая, что у вас есть несколько больших файлов [возможно, неправильное предположение] - вы сможете передать полезную нагрузку в течение ~ 5 часов. я сделал быстрый тест:
server:/mnt/big/tmp# rsync -av --progress root@otherServer:/big/file ./
receiving incremental file list
file
1849044309 100% 74.47MB/s 0:00:23 (xfer#1, to-check=0/1)
sent 30 bytes received 1849270109 bytes 75480413.84 bytes/sec
total size is 1849044309 speedup is 1.00
указание ssh использовать более легкий метод сжатия:
server:/mnt/big/tmp# rsync -e "ssh -c arcfour" -av --progress root@otherServer:/big/file ./
receiving incremental file list
file
1849044309 100% 106.70MB/s 0:00:16 (xfer#1, to-check=0/1)
sent 30 bytes received 1849270109 bytes 112076978.12 bytes/sec
total size is 1849044309 speedup is 1.00
поэтому при условии, что хранилище не является узким местом - 106 МБ / с ~ = 350 ГБ / ч ~ = 1,5 ТБ за 5 часов.
оба теста проводились на простаивающей машине с процессором xeon E5430 @ 2,66 ГГц.
для повышения эффективности [используйте несколько ядер, если у вас более медленный процессор] или просто используйте лучшую доступную пропускную способность и ввод-вывод - вы можете запустить несколько параллельных сеансов rsync для нескольких файлов.
Я не знаю, владеете ли вы / арендуете оптоволокно или просто используете услугу mpls, предоставляемую оператором, независимо от того, что ssh дает вам дополнительное преимущество надежного шифрования без установки промежуточного vpn.