Комментарии 22
Спасибо за интересную статью.
Вариант сжатия потока данных при экспорте в пайп в вашем случае не приемлем?
Сжатие будет работать медленнее, чем сеть 10g
Тут же вроде 800 Мбит/с. Какой-нибудь LZ4 такое в одно ядро вытянет на современных быстрых CPU, а в несколько потоков и с 10g посоревноваться (но уже смотреть надо, конечно).
Только нужно учесть, что бэкапов происходит несколько параллельно и ресурсы для одного процесса нужно как-то лимитировать, а также мониторить все это дело. В нашем случае сеть можно проапргрейдить с 10G на более производительную и получить понятный прирост. В общем именно увеличение скорости самое эффективное для нас на данный момент.
В нашем случае, кажется, что не приемлем. Потому что с одной стороны сжатых данных передать нужно меньше, с другой стороны rbd import не ожидает на вход сжатых данных и их нужно будет распаковать. Как верно заметили ранее, накладные расходы на сжатие/распаковку замедлят процесс. К тому же копирование происходит на одном сервере (при этом пулы дисков подключены к нему по сети) и потоки данных в любом случае приходят и уходят несжатыми, поэтому здесь это смысла не имеет. В иных конфигурациях, без возможности использовать другие инструменты, может стоит посмотреть в сторону сжатия.
если данные плохо поддаются упаковке - то да.
Если же там текстовые данные, то gzip с минимальным сжатием может сильно ускорить, а точнее многопоточный pigz
Кстати вопрос
Вариант с
rbd export > file && file > rbd importмы рассматривать не будем
файвый pipe пробовали? Чисто любопытно что будет если сделать mkfifo и через него. Он конечно не файл, но и не stdin. С другой стороны он не может быть многопоточным. Даже интересно поломается/не поломается/будет ли быстрее?
rbd importне ожидает на вход сжатых данных
А как-нибудь передать "поближе" запуск rbd можно?
Ну что-то типа
rbd export | lz4 | ssh backup@ceph "lz4 -d | rbd import"
Узким местом в нашем случае была передача данных по сети, которая на тот момент составляла ≈ 800 Мб/с. Причем ограничение именно программное. Аппаратная часть была с запасом: в плане сетевого канала и других ресурсов было где разгуляться.
Итого, даже с программным лимитом, сеть способна передать 800*3600 = 2.74 Тб/час. И это узкое место.
9Тб данных, которые прежде копировались за 34 часа, теперь копируются за 11 часов
Откуда 11 часов ?
На этот раз взяли диск на 500 ГБ, сгенерировали на нем 30 файлов по 9,8 ГБ. Вместе с данными ОС все вышло на 296 ГБ данных.
Данная конфигурация дампилась около часа, значит реальная скорость составила около 100Мбайт/с или ~800МБит/с. Думаю, вас ввело в заблуждение то, что у автора «800Мб/с» с графиков - это Мегабит/с.
Исходя из полученного результата, получаетя на 9Тб, действительно, потребуется около 18 часов. А учитывая, что тесты проводились не на продуктовой (а значит, не нагруженной) среде, итоговые значения на проде могут отличаться в худшую сторону.
А почему не используете ZFS в своей системе? Она позволяет делать "моментальные снэпшоты" с минимальным потреблением ресурсов (чем-то ее работа аналогична гиту). Клиент сможет делать снэпшоты хоть каждую минуту. А для сохранности сами данных, вроде как можно пул настроить так, что репликация будет работать по сети, причем с минимальным потреблением трафика (отправляется только то что изменилось). + сквозная шифрока и компрессия работает. Если я что-то упускаю - было бы интересно почитать ваше мнение.
А что снепшотить? У них ceph, и во-первых, если я правильно понимаю, ceph все данные дисков хранит обычно в xfs, во-вторых, вытаскивать их напрямую не через rbd кажется граблеопасно и хлопотно.
Мы используем Ceph, он тоже умеет делать "моментальные снэпшоты", но снэпшот не равно бэкап. К тому же, без относительно бэкапов, сталкивались с тем, что при определенном количетсве снэпшотов (кажется было 14) начинаются задержки в операциях диска (не знаю как с этим в ZFS).
Также мы используем OpenStack и придерживаемся его подходов бэкапирования, скорее поэтому схема именно такая. После того как снэпшот оригинального диска создали, уже его копируем в другой пул в отдельный диск. А при восстановлении из бэкапа создаем новый диск по мима оригинального и копируем в него данные из пула бэкапов, а не откатываемся до снэпшота.
Сколько потоков чтения/записи генерирует этот процесс? Я не знаю всех этих облачных штучек, но при бекапе старых добрых legacy ускорение как правило достигалось увеличением количества потоков чтения (соответственно, и передачи данных и записи).
Вот же круто! Но у меня струя все равно длиннее. Это я к тому, что "зачем это здесь?".
Комбинация команд и никакого мошенничества. Как мы ускорили создание бэкапов в 3 раза