Недавно я зарегистрировался в Rackspace для размещения некоторых серверов баз данных. У меня настроено два сервера MySQL и есть метод для создания резервных копий (с использованием инструментов Percona Xtrabackup и innobackupex). Я пытался использовать дублирование, чтобы скопировать эти резервные копии в хранилище S3 и CloudFiles, и это занимает Forreverr! Я ожидал, что резервное копирование S3 будет не очень быстрым, но резервное копирование CloudFiles заняло 15 часов для резервного копирования 9 ГБ. Это ужасно медленно и неприемлемо для меня.
Я просмотрел исходный код дублирования, и по умолчанию он не использовать Rackspace Servicenet для переноса в облачные файлы. Затем я просмотрел исходный код облачных файлов для библиотеки, которую duplicity использует для бэкэнда CF, и увидел, что существует вариант среды для использования Servicenet (RACKSPACE_SERVICENET). Пока это установлено на что-то библиотека облачных файлов должна подключаться к облачным файлам через службу Rackspace Servicenet, которая ДОЛЖЕН сделать для быстрых переводов. Это не.
Я не уверен, связано ли ограничение скорости с некоторыми ограничениями CloudFiles или библиотека python облачных файлов на самом деле не подключается через службу RackSpace.
Есть ли у кого-нибудь из вас какие-либо другие предложения о том, как я должен / мог бы получить эти резервные копии с сервера на стороннюю или удаленную службу резервного копирования?
Может быть, не полный ответ, скорее предложение. Не могли бы вы настроить инстанс Amazon EC2, который постоянно зеркалирует (или отслеживает на несколько минут) основные серверы БД. Затем вы можете запускать резервные копии с этого экземпляра EC2 непосредственно на S3 и получать более высокую скорость передачи, а также уменьшать нагрузку на ваши основные машины БД.
Хотя 15 часов для 9 ГБ - это, если мои мыслительные вычисления верны (что, вероятно, не так), менее 2 МБ / с, что действительно похоже на проблему. Возможно, стоит обратиться в службу поддержки Rackspace и спросить, почему такая низкая скорость передачи.
Мы используем Rackspace Server Backup (также известный как резервное копирование сервера JungleDisk), который, как и Duplicity, выполняет локальную дедупликацию и сжатие, а затем загружает «фрагменты» через HTTP в облачного провайдера. Мы увидели некоторые проблемы с производительностью, и основная причина заключалась в том, что наши точки подготовки для облачных файлов и облачных серверов были разными. Наши облачные серверы создавались в центре обработки данных DFW, но все сегменты облачных файлов для JungleDisk находятся в центре обработки данных ORD.
В настоящее время Rackspace не дает людям выбора, какой центр обработки данных они собираются использовать, потому что объект DFW близок к мощности. Итак, все для «новых» учетных записей предоставляется в ORD. Поэтому вам нужно открыть заявку в службу поддержки, чтобы изменить точку подготовки.
Кроме того, вы не можете использовать ServiceNet между центрами обработки данных Rackspace (пока).
Тем не менее, мы видим, что во время резервного копирования 40+ Мбит / с даже проходят через центры обработки данных Rackspace с помощью Rackspace Cloud Backup, поэтому я подозреваю, что у вас есть какая-то проблема с конфигурацией с дублированием, или вы связаны диском или процессором во время резервного копирования. Вы пробовали запустить резервную копию той же цели из внешних облачных файлов? Как работает простой HTTP PUT для большого файла (т.е. исключает дублирование для теста)?