Снепшоты в SolidFire
Michael Cade вчера опубликовал у себя в блоге статью-мануал по установке плагина для Veeam и NetApp HCI (SolidFire) который был не так давно выпущен и мне, на основе своего опыта, захотелось дополнить этот материал небольшой ложкой дёгтя.
Около месяца назад, в нашем телеграм-чате, один из пользователей обратился с проблемой, что задание бекапа при использовании аппаратных снепшотов с SolidFire фейлится с ошибкой:
Failed to create snapshot for LUN testlun Error: Clone creation on async handle [270] took too long to complete
Мне стало интересно, как устроена система снепшотов в SolidFire и я решил разобраться с этой проблемой.
Всё это связано с архитектурой самого SolidFire. Дело в том, что непосредственно снепшот — это снимок состояния на моменет его создания. Вы не можете читать из него данные. Для того, чтобы он стал полнофункциональным его необходимо преобразовать в клон. Создание же клона процесс довольно долгий. По сути, мы делаем полную копию данных, но т.к. в системе есть механизм инлайн дедупликации, у нас нет повторяющихся блоков данных, а есть ссылки на оригинальны блоки. И вот именно процесс создания этих ссылок и отнимает столько времени. По сути — мы имеем две независимые копии данных, которые были дедуплицированы. При этом у нас клон никак не зависит от родительского тома и существует самостоятельно, в отличие от ONTAP систем, где этот процесс реализован иначе и занимает секунды. Если сравнивать этот процесс с архитектурой ONTAP, то это будет похоже на процесс split clone, который так же копирует блоки данных и так же занимает большое количество времени.
Соответственно мы получаем ситуацию, что на большом томе с большим количеством записанных данных на системах SolidFire и NetApp HCI клон, для работы с данными создаётся довольно продолжительное количество времени. Фактически, это будет несколько быстрее, чем вы с хоста зальёте такую же копию данных, т.к. благодаря инлайн дедупликации мы не будем писать на SSD сами блоки данных, а только ссылки на оригинальные блоки.
Но если уж говорить об архитектуре, то обращаясь к моему обзору «SolidFire — СХД для тех, who **cking hate storage”, большие тома и большие ВМ не являются use case для данной системы с точки зрения производительности. SolidFire показывает себя во всей красе, когда у вас большое количество томов небольшого размера. Тогда и клоны будут создаваться на много быстрее.
Что же касается коллеги с изначальной проблемой — в итоге они решили изменить схему выделения томов на SolidFire и переносят виртуальные машины на тома объёмом до 2Тб. В этом случае время создания клона занимает менее 2 минут.
В целом же стоит отметить, что у любой СХД есть свои нюансы, о которых хорошо бы знать заранее, но как показывает практика, большинство из них можно выявить только в процессе эксплуатации. По этому я и считают, что делиться подобными кейсами очень полезно.
пс если у вас есть подобные интересные кейсы, которыми вы бы хотели поделиться с общественностью, присылайте их мне на почту и я обязательно их опубликую.
