Помните, как во второй половине 90-х один известный тогда профессор хрипло пел “Бегут года, и грусть, печаль в твоих глазах, а я не знаю что тебе сказать”. Так вот, года действительно бегут, а грусть-печаль в глазах из-за того, что гонка технологий уже достигла таких скоростей, что успеть за ними не может даже самый ловкий мангуст. Правда, некоторые вещи категорически отказываются меняться, и раз уж эта статья из блога компании, занимающейся бекапами, видимо, что-то не меняется в бекапах. А проблема, о которой хочется поговорить сегодня - это выбор сервера, который эти бекапы и будет делать. Все как-то привыкли думать только о размере стораджа, куда их предстоит складывать, а то, что процесс бекапа - это типичная задача обработки большого массива данных, которая жрёт RAM и CPU как не в себя, многие то ли забывают учесть, то ли по неопытности упускают этот момент. Так что сегодня учимся подбирать сервера для бекапов не только по размеру дисков. Или, как говорят зарубежные коллеги: backup server sizing best practices.

И да, в посте будет математика. Целых две формулы. Я предупредил.

Как и любое другое здравое современное приложение, Veeam Backup & Replication спроектирован таким образом, чтобы минимально загружать своему пользователю мозги и максимально эффективно справляться с поставленной задачей. На местах этот высокопарный посыл выражается в том, что независимо от масштаба вашей задачи устанавливается  Veeam в три клика, ещё в пять делается первичная настройка и всё, полетели бекапы бекапироваться. Но как все мы отлично понимаем, это всего лишь радужная теория из мира с поняшками и бабочками. Ведь даже если самому приложению совершенно без разницы, бекапить ли ваш ноутбук на подключенный usb диск или гонять сотни терабайт снапшотов по FC фабрике (а ему действительно всё равно), то происходить это всё будет на вполне конкретном физическом железе, которому предстоит обработать все эти потоки данных. То есть, в то время, пока софтовая часть остаётся неизменной, архитектура решения в целом меняется до неузнаваемости.

Если скорость бекапа своего компа можно легко увеличить на порядок простой заменой USB 2.0 диска на USB 3.1, то имея задачу забекапить развесистую ферму серверов, да ещё и раскиданную по всему миру, можно столкнуться с тем, что в одном месте окажется слабый CPU, в другом процесс утыкается в объёмы доступной RAM, в третьем все ждут, когда контроллер дисковой полки соизволит записать очередную порцию данных, а в четвёртом так и вообще еле живой линк с внешним миром. Так что чем сложнее задача, тем проще и обиднее будет ошибиться с выбором любого из компонентов системы. И если за покупку слишком мощных серверов ругать вас не будут, то промашка в меньшую сторону скорее всего чревата большим числом неприятных разговоров в самом ближайшем будущем. Здесь - ты не поместился в бекапное окно, здесь - попытка сделать снепшот приводит к развалу кластера, а вот там просто нет ресурсов и придётся просить докупить новых железок. Так что тема планирования потребления CPU и RAM для бекапов не настолько и третьесортная задача, как к ней многие относятся. 

Но прежде чем начать выписывать себе бюджеты на сотни CPU и тысячи гигабайт RAM, давайте освежим в памяти общую архитектуру Veeam Backup & Replication, чтобы точно не путаться в определениях и назначении компонентов.

1. Сам VBR (Veeam Backup & Replication) сервер. Командный центр, оркестратор, ЦУП, разум улья, словом, называйте как хотите, но основная его роль - это синхронизация всех остальных компонентов и выдача команд на запуск разных увлекательных внутренних процессов, отслеживание расписания, и так далее. Технически ничего не мешает разместить вообще все компоненты на одной машине, и они даже будут работать. Однако такой сервер и ресурсов потребует соответствующих, и производительность его будет далека от совершенства. Так что лучше размещать всё остальное согласно назначению. Об этом ниже.

2. База данных. Veeam - это классическое приложение, хранящее всю важную информацию в базе данных. Где и как вы расположите эту базу данных - его совершенно не волнует.  Лишь бы до неё была связь и сервер стабильно работал. Хотите на одной машине с основной консолью? Пожалуйста! Для этого в установщике лежит Microsoft SQL Server 2016 SP2 Express Edition, который будет автоматически развёрнут и настроен самым лучшим образом. У вас уже есть своя инсталляция и вы хотите, чтобы база крутилась там? Без проблем! Просто укажите установщику адрес сервера и с какой учёткой туда идти. В процессе эксплуатации передумали и хотите перенести базу на другой сервер? Просто измените ключик в реестре или воспользуйтесь встроенной тулой. Всё для вас.

3. Прокси сервер или просто прокся. Не знаю, почему когда-то давно было решено назвать их именно так, но точно знаю, что новичков это название иногда путает (именно путает, а не пугает). Но не будем искать виноватых, а просто зафиксируем, что прокси - это тот компонент инфраструктуры, который будет читать данные с бекапируемого объёкта и укладывать их в бекап. Это если упрощенно, потому что на самом деле данные будут сжиматься, дедуплицироваться, шифроваться, на их пути могут возникнуть другие прокси, нестабильные каналы связи и всякие хитрые хранилища. Не суть. Сейчас важно зафиксировать, что прокси - это то, что примет на себя основной удар по обработке данных. Они запускают пары data movers, один из которых что-то откуда-то читает, а второй что-то куда-то пишет. Чуете очевидную мораль? Чем ближе ваша прокся к бекапируемому объекту и чем ближе к ней хранилище бекапов, тем быстрее будет идти процесс. Но тут важно не увлекаться и помнить, что чудес не бывает. Ваши машины лежат на FC сторадже? Так будьте любезны и проксе предоставить FC подключение, иначе как ей данные получать? Ну не через managed интерфейс хоста же, ну честное слово. Хотя на самом деле с этой проблемой связана одна из самых частых ошибок при конфигурации - пользователь хочет, чтобы бекапы работали через Virtual Appliance, а работает через Network. Но не будем сейчас о грустном.

4. Репозиторий. Он же бекапный сторадж. Может быть буквально чем угодно, к чему можно присоединиться, а ещё лучше, если там можно запустить наш дата мувер. Запустились на целевой системе - значит, можем контролировать процесс и часть операций проводить локально. Не можем запуститься на целевой системе - значит, приходится верить на слово, а каждый байт информации гонять взад-назад по сети. Так что во время любого синтетического трансформа бекапа, лежащего на сетевой шаре, ваша сеть будет вас ненавидеть. Поэтому Windows/Linux сервер - это твой бро, сетевые шары нет. Работать, конечно, будет, но медленно и не пойми как. Есть ещё целая россыпь вариантов вроде S3, дедуплицирующих систем и всяких специфических файловых систем вроде XFS, но это тема отдельного разговора. Просто помним, что репозиторий - это наше хранилище и гарант безопасного сна. Ну и особенно хорошо, если там можно запускать дата муверы. 

5. Enterprise Manager. Командир над командирами, в котором можно объединить управление несколькими VBR серверами и дать рядовым пользователям пользоваться частью функций через простенький веб-интерфейс. Например, можно выдать гранулярные права своему хелпдеску на восстановление определённых объектов на определённых машинах. Удалил пользователь письмо и корзину почистил, а хелпдеск ему хлоп - и вытаскивает это письмо из бекапа. Красота.

6. И цифрой “шесть” давайте обозначим всё остальное, включая комбо-сервера, на которых крутится сразу по несколько ролей. Например, использовать один сервер в качестве и прокси, и репозитория - вполне нормальная идея, если серверу хватает ресурсов. Ну и помимо основных компонентов есть ещё целая россыпь вспомогательных: tape server, wan accelerator, cache repository и прочие gateway servers. Тут можно долго всё перечислять, тщательно объясняя, кто и зачем нужен, но мы здесь не за этим собрались. Лучше почитайте документацию, благо там всё очень понятно и подробно описано.

Главный посыл всего вышесказанного: VBR- это не одна конкретная машина, на которой вы прокликали мастер установки и получили работающее решение. Вернее, в небольших инсталляциях это, может, и так, но если у вас раскидистая инфраструктура, то VBR полностью готов ей соответствовать. Все эти компоненты и созданы, дабы дать возможность масштабироваться в зависимости от решаемой задачи. Странно будет поставить все компоненты VBR в европейском датацентре, если предстоит бекапить виртуалки по всему миру. Оставьте у себя в офисе управляющий сервер, а прокси и репозитории расположите рядом с машинами. Всё для вашего удобства.

С этим разобрались. Что дальше? Обычно всем сразу на ум приходит идея посчитать количество необходимого для хранения бекапов дискового пространства. Для этого принимается стратегическое решение: бекапить каждую машину раз в день и прикинуть, сколько же нам надо терабайт под бекапы - с помощью отличного калькулятора от Тимоти Девина.

Идея, конечно, хорошая, но вот реализация так себе. Давайте всё же сделаем это несколько грамотней и получим сразу все вводные, необходимые для наших расчётов. И да, сейчас будет очередной чеклист:

1. Первым шагом будет проработка ваших RPO и RTO метрик, про которые уже было сказано очень много раз. Главное - запомнить основной посыл: не вы должны решать, с какой периодичностью делать бекапы и как быстро они должны восстанавливаться, а владельцы сервисов и те, кто называется на западе applications team. Вам надо собраться всех вместе и решить, для какого сервиса какой простой будет допустим и какой объём потерянных данных вы сможете пережить без того, что вас всех уволят, а компания закроется. Исходя из этого вы уже сможете построить вашу схему ротации бекапов, известную в англоязычной литературе как retention scheme.

2. После этого мы уже можем переходить к подсчётам необходимого места. И здесь не надо пытаться изобрести колесо: просто возьмите и посчитайте, сколько места сейчас занимает ваш продакшн.  Да, реальный размер будет меньше за счёт дедупликации, компрессии и отбрасывания ненужных блоков, но это тот самый случай, когда никто вам не скажет как именно посчитать коэффициент сжатия (кроме эффективных маркетологов и продавцов). А запас, как мы знаем, карман не тянет.

3. Посчитали свои терабайты? Отлично, теперь считаем, сколько у нас виртуальных машин/серверов. Совсем хорошо будет, если получится посчитать количество дисков на них, так как несколько дисков параллельно обрабатывать можно, а вот один в несколько потоков не получится. Соответственно, два диска по 500Гб забекапятся быстрее, чем один на терабайт, при прочих равных.

4. Размер окна резервного копирования ака Backup window. Время, за которое должен состояться ваше бекап. Тут не всё так просто, как может показаться. Есть непосредственно бекап продакшена, который должен быть совершён вне времени основной офисной активности, чтобы не повлиять на сервисы. А есть некие побочные вещи, вроде бекап копи, синтетических трансформаций, записи бекапов на ленты и так далее. Если ваша инфраструктура резервного копирования находится на отдельном оборудовании и может спокойно заниматься своими делами, то вам повезло. Если нет, то ваша задача усложняется: надо, чтобы и сам бекап успел сделаться, и все последующие операции.

5. И завершает наш парад вводных самая спорная метрика: сколько новых данных в день будет появляться на ваших серверах. Daily change rate, как называют на западе. К сожалению, тут нет единственно верного ответа, как посчитать этот параметр. Кто-то ограничивается примерными значениями, кто-то делает снапшоты и через сутки смотрит на их размеры. Вариантов много, и точного на сто процентов нет. Но вполне можно обойтись и “средней температурой по больнице”: для машин без высокой активности считается, что в день изменяется не более 5% диска, а “в среднем по больнице” принято считать, что 10% изменяющихся данных в день - это отличный показатель для дальнейших расчётов. 

У пунктов 2 и 5 есть тонкий момент. Как вы прекрасно понимаете, требуемые мощности для того, чтобы успешно и вовремя забекапить весь прод, несколько отличаются от мощностей, необходимых для создания инкрементов. Иногда на порядок. То есть покупать супер-мощный сервер под прокси, который будет только раз в год (а вдруг вам достаточно) упаковывать все ваши петабайты за ночь, а все оставшиеся дни просто греть воздух, может статься и не очень разумным. Возможно, проще будет купить сервер в два раза меньше, но выделять под бекап не четыре часа, а восемь. Или вообще разбить процесс на несколько дней, делая полный бекап только части машин. Словом, момент тонкий и требует отдельного осмысления.

Зато теперь, когда у нас наконец-то есть все вводные данные, можно смело вооружаться калькулятором и начинать считать. При подсчётах мы будем исходить из того, что следуем рекомендациям VBR, и количество параллельно обрабатываемых тасок равно количеству имеющихся у процессора ядер. А одна таска - это один обрабатываемый диск. То есть если у нас на прокси CPU с четырьмя ядрами, то одновременно будут обрабатываться четыре диска с бекапируемых машин. И каждая таска, согласно всё тем же рекомендациям, для спокойной работы требует 2 Гб RAM.

Вспоминаем, на какой вопрос мы ищем ответ: если у меня будет вот столько данных, которые надо забекапить за вот такое количество времени, то сколько вычислительных ресурсов мне надо для этого заложить?

Итак, берём вводные: у меня 640 Тб данных, я хочу делать Per-VM бекап (потому что могу), на бекап у меня есть 8 часов ночью, а мой change rate - классические 10%.

Шаг первый: делим объём данных на имеющееся время и получаем некую скорость обработки данных, которой нам надо достичь. В моём случае получается (640 Тб* 1024*1024)/(8 часов * 60* 60) = 23075 Мб/с - такова должна быть пропускная способность нашей системы.

Шаг второй. Пусть жизнь наша нелегка, и всё, что у нас есть - это сервера, которые могут выдать только 100 Мб/с. Делим желаемое на имеющееся и получаем 23075\100= 230. Округляем в большую сторону до 231. Получилось количество необходимых ядер. Да, блюстители размерностей и единиц измерений могут прибывать в ужасе от таких переходов, но куда деваться. Для примера давайте ещё представим, что наши сервера не настолько древние и от гигабита пропускной способности в обморок не падают. Получится, что нам вполне хватит 24 ядра. Более чем посильное число для современного оборудования.

На третьем шаге умножаем количество ядер на рекомендованные 2 Гб на таск и получаем 24*2 = 48 Гб RAM. Да в ноутбуки уже больше ставят, если честно. А вот у коллеги с более старым железом получится 2312 = 462 Гб RAM. Уже более интересное число, но чего только не сделаешь, дабы успеть забекапиться вовремя.

Затем просто делим это цифры на желаемое количество проксей, округляем в большую сторону и получаем искомые параметры. Повторюсь, никто не запрещает вам использовать хоть десять прокси, хоть один. Просто выдавайте им соответствующие ресурсы, и всё будет здорово. У вас по 12 ядер в сервере? Отлично, 231/12 = 20 серверов по 24 Гб оперативки в каждом. И так далее.

И вспоминаем нюанс с инкрементами. Мы договорились принять, что у нас будет меняться по 10% данных в день. Подставляем в наши формулы: (640 Тб*0,1% * 1024*1024)/(8 часов * 60* 60)=   2 331 Мб/c  / 100 Мб/c = 24 ядра * 2 Гб RAM на таск = 48 Гб RAM. Значит, при прочих равных для инкрементальных бекапов нам будем достаточно двух серверов, по 24 гига оперативки в каждом.

Вот и вся математика. Как видите, никакой магии тут нет и всё считается довольно просто. Да, в своих подсчётах мы используем некую общую пропускную способность в вакууме, а не берём конкретные цифры по скорости сети, дисковых полок и так далее, но кто кроме вас знает вашу инфраструктуру, её слабые и сильные стороны? 

На этом предлагаю на сегодня закончить. Мы рассмотрели только самых основных потребителей ресурсов, но если вам хочется узнать подробности про каждый аспект (база данных, сам VBR, сколько ресурсов нужно для побочных процессов и так далее), то недавно мой коллега Tim Smith целый час рассказывал про это на своё вебинаре. Крайне рекомендую к просмотру всем интересующимся темой, так как там всё разобрано действительно до костей.