Буквально на прошлых выходных я установил новый (резервный) сервер резервного копирования для своей основной машины FreeNAS и запустил полное резервное копирование пула между ними. Обе машины являются корпоративным оборудованием и работают быстро, связь между ними - прямая оптическая сеть 10G (Chelsio), обе машины имеют много быстрого NVMe ZIL/ кеша и 128 ГБ быстрого ddr4, с платами Xeon v4 и Supermicro. Пул, который я копирую / копирую, состоит из 14 ГБ фактических данных, дедуплицированных с использованием 35 ГБ данных (2,5x дедупликация). Пулы представляют собой полосатые зеркала (4 комплекта трехсторонних зеркал с корпоративными дисками 6+TB 7200), а не RaidZ, поэтому у них даже нет четности для их замедления. На серверах или их соединениях больше ничего не работает, кроме соединений SSH для передач. Команда zfs send включает аргументы, необходимые для отправки данных с дедупликацией (хотя из-за надзора не сжимается).
Команда на отправителя:
zfs send -vvDRLe mypool@latest_snapshot | nc -N BACKUP_IP BACKUP_PORT
Команда на получателя:
nc -l PORT | zfs receive -vvFsd my_pool
Я ожидал, что произойдет одно из двух: либо он отправит 14 ТБ и завершит работу, либо отправит 35 ТБ, но уже отправленный 21 ТБ (дедуплицированные данные) идет очень быстро, и нужно отправить только 14 и немного ТБ. Но вместо этого он, похоже, намеревается отправить все 35 ТБ в полном объеме, причем невероятно медленно - я сделал что-то не так или неправильно понял?
Чего я не понимаю, так это того, что даже при сериализации снимков / наборов данных диски серверов резервного копирования работают почти на 100% в соответствии с gstat и делают это уже 4 полных дня. Данные поступают правильно (я могу смонтировать те снимки / наборы данных, которые были завершены). Но отправка всего пула выглядит так, как будто это займет около 7 дней, почти 100% активности диска все время.
Передача 14 ТБ или даже 35 ТБ по каналу 10 ГБ между двумя быстрыми серверами - независимо от того, какая информация о состоянии отображается на консоли - просто не должна занимать так много времени, если только она невероятно неэффективна, что кажется маловероятным.
Обе системы могут считывать и записывать данные даже с вращающихся жестких дисков со скоростью почти 500 МБ / с, а ZFS оптимизирует доступ к диску и не требует повторной дедупликации данных, поскольку они отправляются уже в дедуплицированном виде.
Почему это так долго? Почему бы не отправлять только один раз необработанные блоки в пуле?
Отвечая на некоторые моменты из комментариев:
- netcat (nc):
netcat (nc)предоставляет прозрачный незашифрованный tcp транспорт / туннель для передачи данных между двумя системами (среди прочего) - немного похоже на ssh / VPN, но не замедляет и не переупаковывает, кроме простых TCP-соединений на проводе. Что касаетсяzfs send/zfs receive, то они находятся в прямом взаимодействии, и за крошечной задержкой соединениеnetcatдолжно работать с максимальной скоростью, которую может обработать отправка / получение. - Скорость зеркального диска: зеркало записывает на самой низкой скорости любого из своих дисков, но ZFS рассматривает диски как чередующееся зеркало (данные разбиваются на 4 vdevs в обеих системах, и каждый vdev является зеркалом). Если исходный пул заполнен на 55%, а пул dest пуст и предполагается, что процессоры могут работать, zfs должен иметь возможность одновременно читать с 12 дисков и записывать на 4 диска, а записи должны быть почти последовательными, нет другая деятельность IO. Я полагаю, что самый медленный диск в любом зеркале может последовательно записывать со скоростью> = 125 МБ / с, что намного ниже скорости для современного корпоративного жесткого диска 7200, и резервная копия может заполняться последовательно, а не случайным вводом-выводом. Вот где я получаю устойчивую скорость репликации >> 500 МБ / с.
- Таблица дедупликации / адекватность ОЗУ: Таблица дедупликации составляет около 40 ГБ в ОЗУ (от байтов на запись x общее количество блоков в исходном пуле на
zdb). Я установил sysctl в обеих системах, чтобы зарезервировать 85 ГБ ОЗУ для таблицы дедупликации и других метаданных, а значит, около 35 ГБ для кэшированных данных, перед любым использованием L2ARC (если используется с send / rcv). Таким образом, дедупликация и метаданные не должны быть удалены из оперативной памяти на любой машине.
Скорость и прогресс обновления:
- После 5 дней выполнения у меня есть некоторые обновленные показатели прогресса. Он отправляет данные со средней скоростью около 58 МБ / с. Не совсем пагубно, но все же лежит в основе вопроса выше. Я ожидаю, что скорость будет примерно в 10 раз выше, поскольку наборы дисков могут одновременно считывать до 12 жестких дисков (почти 2 ГБ / с) и записывать до 4 дисков одновременно (около 500 ГБ / с). Он не должен дедуплицировать или повторно дедуплицировать данные (AFAIK), он работает на 3,5 ГГц 4 + 8-ядерном Xeon v4 с тоннами оперативной памяти в обеих системах и локальной сети, которая может обрабатывать 1 ГБ / с.