Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Когда то давно, когда я читал про снапшоты, обсуждались различные стратегии их создания и поддержания.
1. классическая — изменения записываются в раздел снапшота, и при его удалении перемещаются на оригинальный раздел
2. альтернативная — изменения записываются в оригинальный раздел, но перед этим старые данные считываются и копируются в раздел снапшота
3. логическая, например на уровне файловой системы — любые изменения записываются в новое место раздела, сохраняя информацию о месте размещения данных для каждого снапшота (т.е. работа не с данными а с номерами кластеров, т.е. объем обрабатываемых данных в тысячи и миллионы раз меньше… от размера кластера)
достоинства и недостатки обоих вариантов:
1. для классического
— запись в раздел, во время поддержания снапшота, такая же по скорости операция, что и запись без него, вне зависимости от количества поддерживаемых снапшотов
— медленное удаление снапшота из-за переноса данных (собственно это и описано в статье)
2. для альтернативного
— запись данных в оригинальный раздел ощутимо медленнее, в худшем случае в 2 раза для одного поддерживаемого снапшота, и в N+1 раз медленнее, для поддержки N снапшотов (вырожденный случай, когда в каждом снапшоте одни и те же данные изменяются)
— практически мгновенное удаление снапшота (время не зависит от объема накопившихся данных в снапшоте)
3. для логического
— скорость записи не зависит от существования снапшотов
— так же мгновенное удаление снапшота
— слабая изоляция данных друг от друга, так как физически файлы/разделы будут размазаны по всему физическому устройству (или нескольким), а не не каждый раздел на своем устройстве, как это удобно делать с классическим подходом создания снапшотов
Третий подход — это некоторые файловые системы (например тот же nilfs), т.е. любые с поддержкой снапшотов
Собственно у меня риторический вопрос, почему. комплексные системы виртуализации (в сочетании с управлением томами виртуальных машин) старательно отворачиваются от второго и третьего подходов?
1. классическая — изменения записываются в раздел снапшота, и при его удалении перемещаются на оригинальный раздел
2. альтернативная — изменения записываются в оригинальный раздел, но перед этим старые данные считываются и копируются в раздел снапшота
3. логическая, например на уровне файловой системы — любые изменения записываются в новое место раздела, сохраняя информацию о месте размещения данных для каждого снапшота (т.е. работа не с данными а с номерами кластеров, т.е. объем обрабатываемых данных в тысячи и миллионы раз меньше… от размера кластера)
достоинства и недостатки обоих вариантов:
1. для классического
— запись в раздел, во время поддержания снапшота, такая же по скорости операция, что и запись без него, вне зависимости от количества поддерживаемых снапшотов
— медленное удаление снапшота из-за переноса данных (собственно это и описано в статье)
2. для альтернативного
— запись данных в оригинальный раздел ощутимо медленнее, в худшем случае в 2 раза для одного поддерживаемого снапшота, и в N+1 раз медленнее, для поддержки N снапшотов (вырожденный случай, когда в каждом снапшоте одни и те же данные изменяются)
— практически мгновенное удаление снапшота (время не зависит от объема накопившихся данных в снапшоте)
3. для логического
— скорость записи не зависит от существования снапшотов
— так же мгновенное удаление снапшота
— слабая изоляция данных друг от друга, так как физически файлы/разделы будут размазаны по всему физическому устройству (или нескольким), а не не каждый раздел на своем устройстве, как это удобно делать с классическим подходом создания снапшотов
Третий подход — это некоторые файловые системы (например тот же nilfs), т.е. любые с поддержкой снапшотов
Собственно у меня риторический вопрос, почему. комплексные системы виртуализации (в сочетании с управлением томами виртуальных машин) старательно отворачиваются от второго и третьего подходов?
Второй подход — не так уж хорош, чтобы на него смотреть :) Вот третий — да, хорош всем, но он существенно сложнее в реализации. Особенно если диски хранятся в отдельных файлах.
Первый вариант использует VMware. Описанный вами плюс верен только для «молодых» снапшотов в единственном экземпляре. Два-три снимка недельного возраста могут здорово снизить производительность.
Второй подход называется copy-on-write и в чистом виде используется Hyper-V.
Третий механизм реализован на большинстве SAN и как вы правильно отметили, он реализовывается на уровне файловой системы, поэтому хост о такой возможности может и не знать. Эта задача бекапного софта на 100%: получить от хоста набор метаданных, прийти на SAN, отдать команду на снепшот набора секторов и щабрать их копии. Основная выгода заключена в практически моментальном создании снапшота и «отпускании» ВМ т.к. все дальнейшие операции можно проводить без её участия. Этот механизм реализуется каждым вендором по своему, но проблемы изоляции уже давно нет. На современных системах можно устраивать финты вроде выделения отдельных дисков для хранения снимков или создать снимки в самом конце хранилища. Вариантов действительно много, на любой вкус и цвет.
Так что неправда ваша, всё используется.
Второй подход называется copy-on-write и в чистом виде используется Hyper-V.
Третий механизм реализован на большинстве SAN и как вы правильно отметили, он реализовывается на уровне файловой системы, поэтому хост о такой возможности может и не знать. Эта задача бекапного софта на 100%: получить от хоста набор метаданных, прийти на SAN, отдать команду на снепшот набора секторов и щабрать их копии. Основная выгода заключена в практически моментальном создании снапшота и «отпускании» ВМ т.к. все дальнейшие операции можно проводить без её участия. Этот механизм реализуется каждым вендором по своему, но проблемы изоляции уже давно нет. На современных системах можно устраивать финты вроде выделения отдельных дисков для хранения снимков или создать снимки в самом конце хранилища. Вариантов действительно много, на любой вкус и цвет.
Так что неправда ваша, всё используется.
Тоже недоумеваю, ну если есть проблема что VM-snapshot нельзя долго держать активным — можно ж заснепшотить VM-ки, быстренько сделать снепшот раздела FS, где лежат образы дисков и готово — снепшоты VM можно по одному удалять (время их жизни минимально), а после этого образы дисков не спеша копировать себе из снепшота FS.
Осталось дождаться когда железные вендоры перейдут на единые стандарты и API. Вот заживём…
Зачем железные? Вы производитель продукта по организации виртуализации, в т.ч. и по бекапам этих виртуалок, значит как минимум вы контролируете тот раздел FS, где лежат образы дисков виртуалок. В т.ч. можете сделать снепшот этого раздела и забрать образы дисков с него с нужной скоростью (загрузкой). Доступ к этому разделу FS ведь абстрагирован от железа, нет?
Да бог с вами, зачем нам контролировать фс? Строго говоря, процесс происходит на уровне ниже фс.
Мы как производитель продукта для бекапов получаем от хоста набор метаданных о файлах машин (кому, как не ему, знать где, что находится), идём к контроллеру и говорим ему сделать снимок (и нас совершенно не интересует как он его сделает), потом терпеливо ждём ответа об удачном завершении процесса и координаты файлов для копирования.
Зачем усложнять и влезать в материи, где мы будем явно лишней прослойкой?
Мы как производитель продукта для бекапов получаем от хоста набор метаданных о файлах машин (кому, как не ему, знать где, что находится), идём к контроллеру и говорим ему сделать снимок (и нас совершенно не интересует как он его сделает), потом терпеливо ждём ответа об удачном завершении процесса и координаты файлов для копирования.
Зачем усложнять и влезать в материи, где мы будем явно лишней прослойкой?
Ясно, я просто не разбирался в вашем продукте (а строго говоря, просто высказал свое имхо, как можно было бы решить указанную проблему), поэтому был не в курсе, где ваша зона отвественности, а где не ваша )
Насчет зачем усложнять, тут ответ прост — чтобы достичь большей эффективности. Ещё вопрос, что сложнее — пытаться найти баланс между скоростью копирования и длительностью жизни снепшота, или добавить новую прослойку и перевести бекапы на другой уровень (снепшота FS, а не снепшота VM).
Насчет зачем усложнять, тут ответ прост — чтобы достичь большей эффективности. Ещё вопрос, что сложнее — пытаться найти баланс между скоростью копирования и длительностью жизни снепшота, или добавить новую прослойку и перевести бекапы на другой уровень (снепшота FS, а не снепшота VM).
Но замедление бэкапа приводит и к тому, что объем изменений в снэпшоте будет намного больше, чем при быстром бэкапе. Из-за этого увеличится время, требуемое на слияние снэпшота после бэкапа и, следовательно, увеличивается вероятность того, что кластер развалится тогда. Или нет?
Тут надо искать золотую середину и кроме как опытным путём её не найти. Метрики сильно зависят от интенсивности операция на самой машине, от объема данных для бекапа и т.д. Поэтому, к сожалению, формулы для нахождения ответа нет.
Если у вас хороший и быстрый накопитель, то проблемы консолидации даже большого снимка, скорее всего, не возникнет.
А возможно, замедление бекапа приведёт к увеличению снепшота на 20мб, а сам бекап будет делаться дольше на 15 минут. Такие изменения погоды не сделают, а кластер останется жить как и раньше.
Но как показывает практика, если нет проблем со временем (например бекапы еле-еле успевают пройти к началу рабочего дня), то лучше пусть они дольше создаются, но потом гарантированно не будет проблем на стадии финализации.
Или можно вообще плюнуть на всё и увеличить время опроса элементов кластера ;)
Если у вас хороший и быстрый накопитель, то проблемы консолидации даже большого снимка, скорее всего, не возникнет.
А возможно, замедление бекапа приведёт к увеличению снепшота на 20мб, а сам бекап будет делаться дольше на 15 минут. Такие изменения погоды не сделают, а кластер останется жить как и раньше.
Но как показывает практика, если нет проблем со временем (например бекапы еле-еле успевают пройти к началу рабочего дня), то лучше пусть они дольше создаются, но потом гарантированно не будет проблем на стадии финализации.
Или можно вообще плюнуть на всё и увеличить время опроса элементов кластера ;)
P.S. Пожалуй сделаю оговорку — если мы бекапим одну единственную машину на хосте, то конечно да, нет никакого смысла тормозить бекап по описанным вами причинам. Но в 99% случаев на хосте находится больше чем одна машина, и пока на первой удаляется снапшот, можно во всю бекапить следующую, создавая дополнительную нагрузку на хранилище, тем самым здорово снижая шансы на успешную консолидацию дисков первой.
Не стоит забывать про выскокнагруженные системы, когда операции записи на диск по скорости могут превысить
операцию консолидации снапшота и в итоге привести к переполнению датастора с аварийной остановкой виртуальной машины. Что гораздо страшнее развалившегося кластера.
операцию консолидации снапшота и в итоге привести к переполнению датастора с аварийной остановкой виртуальной машины. Что гораздо страшнее развалившегося кластера.
В этом случае данные будут получаться напрямую с хранилища, через I/O стек. Скорость копирования в данном случае, при прочих равных, будет лучше как минимум на порядок.
Нет там такой разницы, да и в сеть всё равно упрётесь при передаче данных на сервер резервного копирования. А в вашем же Best Practice Guide для Nutanix первый способ указан как рекомендуемый.
… а если не в сеть, то в скорость дисков хранилища бекапов, или в мощность передающей прокси или в ещё десяток возможных узких мест. Можно долго спорить, а можно прогнать несколько грамотных тестов и убедиться самостоятельно.
Nutanix это очень специфический случай, поэтому-то для него написан отдельный best practices. Всё логично.
Nutanix это очень специфический случай, поэтому-то для него написан отдельный best practices. Всё логично.
Я сравнивал скорость и существенной разницы не заметил, зато странности в поведении гостей при использовании Hot Add встречались. Правда это на TSM без сжатия/дедупликации на датамуверах.
P. S. А почему вы не пишете в корпоративный блог? Со статьями про поддержку понятно, но тут занятный технический материал на который никто не обидится.
P. S. А почему вы не пишете в корпоративный блог? Со статьями про поддержку понятно, но тут занятный технический материал на который никто не обидится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ямщик, не гони лошадей или почему быстрый бекап не всегда хорошо?