Comments 23
bs=1M | gzip --fast
тоже так делал, а потом побенчил и пришел к bs=64K и lzop — размер чуть больше, но по CPU и времени сильно «дешевле»
Не совсем понимаю почему нужно посылать сигналы приложению, если всё таки можно по тем же самым метрикам изменять лимиты в cgroups.
Почти тоже самое можно сделать одной строкой cpuwatch 10 ionice -c2 -n7 dd if=…
При большой нагрузке на IO, автоматически будет расти avg, что в свою очередь будет останавливать dd.
При большой нагрузке на IO, автоматически будет расти avg, что в свою очередь будет останавливать dd.
UFO just landed and posted this here
>>резервного копирования тома, которая выполняется с помощью создания снимка раздела и запуска dd + gzip
Откройте для себя ZFS и не мучайтесь этой ерундой.
Откройте для себя ZFS и не мучайтесь этой ерундой.
А каким образом ZFS поможет в решении проблемы резервного копирования и роста IO?
Таким, что на zfs чертовски удобно делать снапшоты, чертовски удобно работать с томами (добавить-удалить диск в пул и прочее) и все резервное копирование заключается в грамотном управлении политикой создания и удаления снапшотов. Не нужно писать какие-то адские скрипты создания архивов, и прочее, вы просто копируете данные с разных серверов или раб. ПК (например я копирую с помощью rsync данные с файлового сервера win2012 И с кучи linux серверов) на сервер с zfs, ночью создаю новые снапшоты с определенным сроком хранения, удаляю старые (5 строчек в cron) и все. При любой аварии я моментально могу достать данные (хоть 1 файл) без распаковки архивов, без ожидания.
Таким, что на zfs чертовски удобно делать снапшоты, чертовски удобно работать с томами (добавить-удалить диск в пул и прочее) и все резервное копирование заключается в грамотном управлении политикой создания и удаления снапшотов. Не нужно писать какие-то адские скрипты создания архивов, и прочее, вы просто копируете данные с разных серверов или раб. ПК (например я копирую с помощью rsync данные с файлового сервера win2012 И с кучи linux серверов) на сервер с zfs, ночью создаю новые снапшоты с определенным сроком хранения, удаляю старые (5 строчек в cron) и все. При любой аварии я моментально могу достать данные (хоть 1 файл) без распаковки архивов, без ожидания.
Мне кажется, что я, все же, про другое пишу. Если Вы захотите решить проблему именно резервного копирования, что никак со снэпшотами не связано, то проблема так или иначе себя проявит и zfs тут не при чем.
Проблема сохранения отзывчивости приложений при больших дисковых операциях решается путем выделения под backup отдельного сервера, который ничем кроме хранения бэкапа не занимается.
У меня в компании так и сделано, стоит старенький HP Proliant ML150 с 6 SATA дисками по 3 Tb c ZFS.
И никаких проблем нет. Цена б/у сервера — 7-10 т.р., диски берутся тоже самые обычные (WD Red), просто делается RAIDZ со spare диском. Итого за 55 т.р. имеем нормальный сервер для хранения бэкапов для небольшой компании и никакого гемороя с перегрузками IO.
У меня в компании так и сделано, стоит старенький HP Proliant ML150 с 6 SATA дисками по 3 Tb c ZFS.
И никаких проблем нет. Цена б/у сервера — 7-10 т.р., диски берутся тоже самые обычные (WD Red), просто делается RAIDZ со spare диском. Итого за 55 т.р. имеем нормальный сервер для хранения бэкапов для небольшой компании и никакого гемороя с перегрузками IO.
Мы предпочитаем корзину и raid10. Но путь абсолютно верный, да
Честно говоря, я не очень понимаю при чем здесь ZFS, но пытаюсь понять.
1. Я понимаю что ZFS превосходит LVM2 в аспектах сжатия данных, в производительности снэпшотов, в дедупликации данных (по крайней мере на Solaris, возможно, FreeBSD).
2. Неважно что у меня на том сервере откуда я копирую данных — LVM2 и ZFS, операция копирования генерирует дополнительные IO, кроме того, в зависимости от условий она еще может «вымывать» буферный кэш, что ведет к еще большему росту IO, в результате чего приложения могут столкнуться с ситуацией, что им IO не хватает.
3. Статья о том, как приостановить бэкап, если наблюдается ситуация, что приложения начали голодать по IO.
4. Статья не о том, как эффективно организовать сервер хранения бэкапов.
Теперь вопрос: в чем именно Ваша точка зрения в контексте метода [остановки приложения резервного копирования], который я предлагаю, и как ZFS (в контексте статьи речь видимо идет о zfsonlinux) помогает в осуществлении резервного копирования (принципиально), а не в контексте лучше/хуже, что позволяет приложениям не голодать по IO?
ps: я копирую 11 ТБ томов виртуальных машин
1. Я понимаю что ZFS превосходит LVM2 в аспектах сжатия данных, в производительности снэпшотов, в дедупликации данных (по крайней мере на Solaris, возможно, FreeBSD).
2. Неважно что у меня на том сервере откуда я копирую данных — LVM2 и ZFS, операция копирования генерирует дополнительные IO, кроме того, в зависимости от условий она еще может «вымывать» буферный кэш, что ведет к еще большему росту IO, в результате чего приложения могут столкнуться с ситуацией, что им IO не хватает.
3. Статья о том, как приостановить бэкап, если наблюдается ситуация, что приложения начали голодать по IO.
4. Статья не о том, как эффективно организовать сервер хранения бэкапов.
Теперь вопрос: в чем именно Ваша точка зрения в контексте метода [остановки приложения резервного копирования], который я предлагаю, и как ZFS (в контексте статьи речь видимо идет о zfsonlinux) помогает в осуществлении резервного копирования (принципиально), а не в контексте лучше/хуже, что позволяет приложениям не голодать по IO?
ps: я копирую 11 ТБ томов виртуальных машин
Теперь вопрос: в чем именно Ваша точка зрения
А Вы прочитайте мой коммент внимательней, там вполне все понятно.
Вы написали:
резервного копирования тома, которая выполняется с помощью создания снимка раздела и запуска dd + gzip
Я написал:
Откройте для себя ZFS и не мучайтесь этой ерундой.
Все. Мой комментарий касался только 1 вашей фразы про то, что Вы делаете рез.копирование через запуска dd + gzip
Как вы притормаживаете ресурсоемкую дисковую операцию при росте IO я вообще не оспариваю.
А чем плох dd и gzip? Как это связано с zfs?
А чем плох dd и gzip?
Вы еще спросите чем плох пароль 123456 и как это связано с безопасностью.
А тем и плох dd и gzip, что насилуя ими диск, Вы поднимаете IO до небес, а потом жалуетесь, что плохая отзывчивость web-приложений.
Давайте смотреть на вещи трезво, it depends. По нескольким причинам.
1. Gzip не насилует диск;
2. Gzip имеет на dd успокаивающее действие, поскольку замедляет dd;
3. dd осуществляет последовательное чтение, нам помогает readahead, при использовании direct мы не вымываем буферный кэш;
4. В зависимости от заполненности FS и от объема изменений, dd может быть лучше и хуже чем другой метод. Скопировать FS с миллионами мелких картинок, к примеру, будет быстрее с помощью dd чем rsync;
5. Статья не про dd, а про способ остановки;
6. Я не до конца понимаю при чем здесь ZFS и зачем вы начали про нее разговор?
1. Gzip не насилует диск;
2. Gzip имеет на dd успокаивающее действие, поскольку замедляет dd;
3. dd осуществляет последовательное чтение, нам помогает readahead, при использовании direct мы не вымываем буферный кэш;
4. В зависимости от заполненности FS и от объема изменений, dd может быть лучше и хуже чем другой метод. Скопировать FS с миллионами мелких картинок, к примеру, будет быстрее с помощью dd чем rsync;
5. Статья не про dd, а про способ остановки;
6. Я не до конца понимаю при чем здесь ZFS и зачем вы начали про нее разговор?
Я открыл для себя другое правило: в продакшн — ничего модного. У моей компании нет на это денег.
Когда мода заглохнет и %продукт% станет мейнстримом и будет включен в основных дистрибутивах по умолчанию — пора.
Почему бы не копировать с помощью rsync? Это решило бы проблему тайм-аута и добавило больше секьюрности в весь процесс.
Only those users with full accounts are able to leave comments. Log in, please.
Резервное копирование томов LVM2 с защитой от перегрузок IO с использованием сигналов SIGSTOP, SIGCONT