Недавно компания Veeam анонсировала новую функцию в грядущем обновлении своего главного продукта, вся суть которой заключается в том, чтобы не давать приложению работать слишком быстро. Звучит как минимум странно, поэтому предлагаю попробовать разобраться, зачем же надо искусственно снижать скорость создания бекапа, когда голос разума активно настаивает на обратном.
И, так как “плясать начинают от печки”, мы рассмотрим ситуацию с самого начала — с принципов, лежащих в основе виртуальных бекапов, немного копнем внутрь и раскроем одну очевидную проблему, которую не учитывает около 90% администраторов виртуальных сред. Также отмечу, что для упрощения повествования описания всех функций будут даваться на основе функционала гипервизора от VMware, как наиболее прозрачного и документированного.
Главная идея заключена в снижении нагрузки на СХД, где находится продакшн система, так как бесконтрольная активность зачастую приводит к слишком сильному увеличению задержек выполнения операций I/O, а это вызывает неприятные последствия:
• Производительность приложений внутри гостевых ОС падает до критически низких отметок и даже ниже
• Развал кластерных структур, таких как DAG, SQL always on и т.д.
• Гостевая ОС может попросту потерять системный диск
И множество других, самых невероятных на первый взгляд вещей, связанных с деградацией производительности на уровне хранилища.
Как мы дошли до такого
Ни для кого не секрет, что в основе бекапа виртуальных сред лежат снапшоты. Эта альфа и омега позволяет достигать двух крайне важных целей: консистентности файловой структуры на дисках виртуальной машины и защиты файлов самих дисков на период бекапа.
После успешной остановки дисковых операций и создания снапшота можно приступать непосредственно к сохранению дисков ВМ. Делать это можно по-разному:
• Можно забрать файл, обратившись напрямую к хосту через LAN стек. Этот способ всегда работает, но он всегда очень медленный (если только вся бекапная инфраструктура не построена на 10G линках).
• Более выгодным вариантом является возможность временно прицепить диск к другой машине и скачать его оттуда. В этом случае данные будут получаться напрямую с хранилища, через I/O стек. Скорость копирования в данном случае, при прочих равных, будет лучше как минимум на порядок.
• И самый быстрый, но и самый дорогой вариант — это забрать файл непосредственно с SAN, получив от гипервизора все необходимые метаданные. В этом случае скорость копирования может быть выше и на два порядка, и на три. Всё зависит только от коннекции между SAN и местом хранения бекапа.
Но какой бы вариант вы не использовали, после завершения копирования дисков наступает пора произвести обратную операцию — все изменения, которые произошли с виртуальной машиной за время бекапа и накопились в снапшоте, должны быть консолидированы с оригинальным диском, после чего снапшот может быть безопасно удалён, а ВМ продолжит работать как ни в чём не бывало.
И тут всплывают два очень важных нюанса, на которые мало кто обращает внимание, пока не столкнётся с их проявлениями.
Консолидация снапшота — очень тяжёлая процедура с точки зрения нагрузки на СХД хоста и напрямую зависит от скорости(производительности) хранилища. Это раз. И два — данная операция обладает наивысшим приоритетом на уровне гипервизора, т.к. нет ничего важнее, чем целостность информации, и с этим трудно спорить.
Складывая первое со вторым, можно легко сделать вывод, что если во время консолидации снапшота на кластерную ВМ приходит heartbeat запрос, то гипервизор может запросто отложить его передачу (поместив во временный буфер), если посчитает, что ответ на этот запрос займёт недопустимое количество времени и может привести к рассогласованию операции консолидации.
В этот момент мы будем иметь три мнения:
• С точки зрения гостевой ОС, у неё всё хорошо. Она работает, а то, что гипервизор её немного подмораживает, на её уровне даже не всегда заметно. Но стоит отметить, что бывают исключения, и, как описано в начале статьи, ОС может потерять связь со своими дисками. В том числе и системным со всеми вытекающими.
• С точки зрения гипервизора всё просто отлично. Он старательно удаляет снепшот, а входящие к ВМ запросы, по своему усмотрению, помещает в свой буфер или в так называемый Helper snapshot, чтобы потом отдать эти данные ВМ. Целостность данных обеспечена, все пляшут.
• А вот на кластере в этот момент паника. Участник кластера (а то и несколько участников) уже пропустил несколько опросов, и пора бы начинать пересчёт кворума, а то и вовсе сообщать о том, что кластер скорее мёртв, чем жив. В любом случае ситуация очень неприятная.
Если кто-то захочет протестировать свой кластер, хочу предупредить, что не стоит создавать снапшот, считать до десяти и сразу удалять его. Снапшот должен пожить, нарастить мышцу… вырасти в объёме и только тогда его нужно консолидировать. Иначе тест не имеет смысла. Оценить время, необходимое для правильного эксперимента, можно простым способом: через Datastore Browser скачать vmdk файлы ВМ. Время, которое понадобится на подобную операцию, будет на 99% верным показателем.
Мама, ну не виноватая я
Некоторые клиенты после того, как у них опять развалился DAG после трехсуточного бекапа mailbox сервера расположенного на СХД времён позднего палеолита, очень любят обвинять нас во всех смертных грехах, ссылаясь на очевидную связь — кластер развалился во время бекапа, значит, виноват бекапный софт. Но, к сожалению, все факты, описанные в этой статье, подтверждены самой VMware. В статье размещённой в их KB, черным по белому написано — во время консолидации снапшота нагруженная ВМ может перестать отвечать на запросы извне. Типичные следствия этого — BSOD с сообщением о потере системного диска; если ВМ была частью какого-либо кластера, то она из него исключается, кластер распадается, или в самом лучше случае вы просто увидите очень сильную деградацию производительности (хотя с этим можно относительно успешно бороться увеличением RAM). А в best practices не рекомендуется хранить снапшот более двух суток.
Со своей стороны мы также собрали подборку информации по данной теме в своей КВ статье.
Как мы решили с этим бороться
Очевидно, что узким местом в этом процессе является внутренняя скорость работы СХД. Ещё утром казалось, что у нас просто отличнейший накопитель, а уже к вечеру мы вынуждены выключать продакшн для снижения нагрузки на сторейдж, в надежде, что на этот раз получится удалить забытый месяц назад снапшотик, который успел разрастись до сотен гигабайт (и производительность ВМ упала до критической отметки).
В начале был опробован вариант лобовой атаки — введён параметр, прямо ограничивающий количество операций с СХД. Но у этого метода было слишком много минусов, свойственных статическим системам. А иногда доходило до выстрела в ногу — юные пионеры, любящие хранить бекапы на той же СХД, где расположены ВМ, могут выявить все возможные способы сделать бекап ещё медленней, а хост довести до паники.
Поэтому в новой версии было решено полностью отказаться от такой модели и перейти к динамической обработке текущих показателей задержек I/O. На уровне глобальных настроек приложения это выглядит так:
Причем надо отметить, что помимо глобальных настроек, можно выставлять свои параметры для каждого конкретного data storage или volume, в случае работы с Hyper-V. Но это уже вопрос лицензирования.
Так рассмотрим-же предлагаемую связку параметров.
“Stop assigning new tasks to datastore at:” Если во время бекапа мы видим, что величина задержки (IOPS latency) превысила допустимый порог, VBR сервер не будет создавать новых потоков передачи файлов, пока производительность СХД не вернётся к допустимому уровню. Или проще говоря, мы не будем пытаться выжать все соки из хранилища, если оно достаточно сильно загружено.
“Throttle I/O of existing tasks at:” – применяется в случае, если задание резервного копирования уже работает, и при этом возникает задержка при обращении к диску, вызванная внешней нагрузкой. Например, если во время бекапа, на одной из машин запустится SQL сервер, создав дополнительную нагрузку на ту же СХД, то VBR сервер искуственно снизит собственную интенсивность обращений к дискам, дабы не помешать продакшн системе. Когда производительность вернётся на прежний уровень, VBR сервер так же автоматически увеличит скорость передачи данных. Этот пункт как-бы дополняет предыдущий. Если в качестве первой меры мы просто перестаём создавать дополнительную нагрузку, работая на неком установившемся уровне, то второй мерой служит снижение интенсивности уже идущих операций в угоду производственными системам.
Пример того, как отрабатывают данные параметры, отлично виден на этом скриншоте:
В самом начале графика хранилище находится в состоянии “покоя”, т.е. происходят обычные рабочие процедуры. В 18:55 было включено бекапное задание, вызвавшее ожидаемый рост задержек на операции чтения/записи с ярко выраженными пиками, доходящими до 80 мсек. Около 19:42 был активирован механизм контроля (отметка Enable), и, как мы видим, средняя величина задержек операций чтения (зелёный график) удерживется на отметке в 20 мсек и вырастает только при отключении механизма контроля (отметка Disable).
Замечу, что дефолтные значения порогов в 20 и 30 мсек взяты не с потолка, а в результате оценки данных мониторинга от множества наших заказчиков, которые любезно согласились их предоставить. Таким образом, эти значения отлично подойдут для большинства виртуальных сред.
Заключение
Пожалуй на этом я и закончу описание этой функции. Я постарался сделать его максимально доступным, но если есть ещё вопросы, буду рад продолжить в комментариях или через личку.
Так же не стесняйтесь задавать вопросы по другим нашим продуктам или их отдельным функциям. Постараюсь ответить всем, а если кратко не получится, то сделаю отдельную статью.
Автор: Loxmatiymamont
