Последний год мы разбираем чужие расчёты систем резервного копирования чаще, чем делаем свои. И почти в каждом видим одно и то же: бюджет, посчитанный весной, к моменту внедрения вырос в разы. Заказчик считает, что его обманули. Поставщик показывает переписку и документы, где всё сходится. И оба правы, потому что врать никому не пришлось.
Дело в том, что в расчёте резервного копирования есть три места, где одна величина незаметно заменяется другой. Объём защищаемых данных подменяется ёмкостью хранилища копий. Ёмкость хранилища — физическим объёмом дисков. А физический объём — коэффициентом сокращения, который к вашим данным может вообще не относиться. Каждая подмена по отдельности выглядит мелочью. Вместе они дают расхождение на порядок.
Дальше — разбор всех трёх. С формулировками для технического задания и вопросами, которые стоит задать до того, как бюджет согласован.
Метрика лицензии
Периметр, а не хранилище
Лицензия считается по объёму защищаемых источников. Ёмкость хранилища копий в этом расчёте не участвует вообще.
Начнём с величины, которая определяет цену лицензии.
Лицензия считается по объёму защищаемых источников. Не по объёму копий, которые система создаст. Не по ёмкости хранилища, куда эти копии лягут. По тому, сколько данных лежит в системах, которые вы берёте под защиту. Звучит очевидно ровно до момента, когда нужно назвать число.
Потому что даже на одной виртуальной машине таких чисел три, и все три настоящие. Сколько дисков выделено. Сколько на них занято. И сколько из занятого попадает в периметр — это зависит от того, забираете ли вы системные разделы, подкачку, временные каталоги. Разница между первым и третьим доходит до двукратной.
Бюджет обычно считают по первому числу — его проще всего вытащить из консоли: открыл, выгрузил, сложил. Дальше два исхода. Посчитали по выделенному — переплатили, выяснится через год при продлении. Посчитали по занятому, но забыли половину систем — недоплатили, и это вскроется посреди внедрения, когда менять поздно. Второй случай хуже и встречается чаще.
И вторая развилка, которую путают ничуть не реже. Метрика бывает разная, и в одной спецификации их обычно две.
Виртуальная машина лицензируется по числу машин — обычно паками по десять, и объём данных роли не играет: машина есть машина, хоть пустая, хоть под завязку. Front-end терабайты — наоборот, лицензия по объёму, и число объектов в ней не считается.
Ловушка в том, что одна и та же машина может считаться и так, и так. Если внутри неё Oracle или PostgreSQL, копировать её образом бессмысленно: получите либо неконсистентную копию, либо остановку базы на время снимка. Базу забирают агентом — с журналами, с восстановлением на точку во времени. И это уже front-end терабайты, а не «ещё одна машина в паке».
Следствие двойное. В спецификации должны стоять обе позиции, и заранее известно, какие системы в какую попадают: список машин с базами составляется отдельно. И эти машины нельзя посчитать дважды — сначала в паке, потом в терабайтах. Двойной счёт мы видим примерно в каждом третьем расчёте, и всегда в пользу продавца.
Отдельно про хранилище копий — тут путаница самая дорогая. Его ёмкость в расчёте лицензии не участвует вообще: она определяется глубиной хранения, схемой копирования, требованиями к неизменяемости. Систему на несколько петабайт можно строить под периметр в сотни терабайт, и это нормально. Когда мы видим в расчёте ставку лицензии, умноженную на ёмкость массива, дальше можно не смотреть.
Анатомия оценки
Как периметр растёт слоями
Периметр набирается слоями, и каждый следующий вспоминают позже предыдущего. Первый расчёт почти всегда учитывает один слой из пяти.
Теперь почему первоначальная оценка почти всегда занижена. Периметр набирается слоями, и каждый следующий вспоминают позже предыдущего.
Первым в расчёт попадает то, что видно в консоли виртуализации: ферма инвентаризована лучше всего, цифра берётся в один клик.
Вторым слоем приходят базы данных. Часть живёт на тех же машинах и уже посчитана, часть стоит на физических серверах и не посчитана нигде. И почти всегда выясняется, что копировать базу гипервизором и копировать агентом — это разный объём, разное время восстановления и разные строки в спецификации.
Третьим идут файловые ресурсы: общие папки, архивы сканов, каталоги обмена с внешними системами. Их не считают заранее — за них нет единого ответственного.
Четвёртым — контуры разработки и тестирования. Первый порыв: не продуктив, исключаем. А внутри копия боевой базы с настоящими данными, и восстанавливать её после сбоя всё равно придётся.
Пятым слоем приходит почта, уехавшая в облако, и тут метрика меняется полностью: лицензия считается по числу ящиков, а не по объёму. Привычная арифметика «терабайты умножить на ставку» не работает вовсе. Хуже того, число ящиков растёт по другим законам: компания может годами не набирать данных, но принимать людей — и лицензия растёт вместе со штатом.
Спрашиваешь, сколько занимает почта, — называют занятость хранилища под текущие копии. Это не метрика сайзинга.
Там же наши любимые грабли. Спрашиваешь, сколько занимает почта, — называют занятость хранилища под копии. Это не метрика сайзинга, а то, сколько места копии занимают при сегодняшней глубине. К числу ящиков, которое и стоит в лицензии, оно отношения не имеет.
В одном из проектов, где мы вели расширение системы копирования, итоговый периметр вышел примерно впятеро больше первоначальной оценки. Данные за это время в пять раз не выросли. Просто первоначальная оценка учитывала один слой из пяти.
Бывает и наоборот: в другом проекте периметр по результатам аудита оказался немного меньше объёма, под который бронировали лицензию. Разница небольшая, но показательная — она взялась из инвентаризации, а не из ощущений. Нормальный расчёт защищает от переплаты ровно так же, как от нехватки.
Список пропусков
Что забывают всегда
Перечень того, что всплывает последним, устойчив до скуки. Инвентаризация источников — самостоятельный этап, а не подготовка к нему.
Список того, что всплывает последним, устойчив до скуки. Проверьте по нему свой расчёт.
Базы вне виртуальной среды. Промышленные СУБД на классических Unix-платформах и на программно-аппаратных комплексах. В консоли виртуализации их не видно — в первый расчёт они не попадают никогда. При этом именно ради них вся система копирования обычно и затевалась.
Копия на второй площадке. Система стоит на копировании в основном центре и посчитана. Её копия на резервной площадке — потенциально отдельная позиция в лицензии. Правила различаются между производителями и даже между вариантами поставки одного, поэтому вопрос задаётся прямо, а ответ получается письменно.
Дополнительные модули. Изолированная среда восстановления, проверка копий на вредоносную активность, неизменяемое хранение — самостоятельные позиции со своими правилами комплектования. В базовую лицензию они не входят и задним числом на тех же условиях не докупаются.
Вспомогательная инфраструктура. Копирование облачной почты требует отдельных посредников — виртуальных машин, через которые идёт выгрузка. В смете на лицензии их нет. В проекте они есть, занимают ресурсы, и кто-то должен их посчитать.
Неизрасходованный запас лицензий. Самый частый источник неприятных открытий. На балансе лежат лицензии, купленные несколько лет назад и, как считается, израсходованные не полностью. Их закладывают в план как готовый ресурс. До сверки с фактическим перечнем систем это не ресурс, а предположение — и сверять его надо до расчёта, а не после подписания.
Отсюда вывод, который мы повторяем на каждой встрече: инвентаризация источников — самостоятельный этап проекта, а не подготовка к нему. Вводные приходят из двух мест и расходятся: письменный перечень, собранный к закупке, и устная позиция инженеров, которые эксплуатируют это каждый день. Расхождение — норма.
Работающий инструмент один — чек-лист сверки «что есть, чего нет»: категория источника, наличие, количество, объём, способ защиты, ответственный. Заполняется совместно, подписывается обеими сторонами, и только после этого начинается расчёт.
И ещё одно, из области календаря. Считайте не от даты готовности проекта, а от даты окончания действующей поддержки. Процедура закупки занимает месяцы: если лицензии истекают в декабре, а конкурс объявляется в сентябре, на сбор исходных данных остаётся август — и это уже поздно.
Вторая подмена
Приёмник — это не периметр
Четыре независимые системы хранения — это не одна система суммарной ёмкости. И не величина, по которой лицензируется софт.
Здесь начинается вторая часть разговора и вторая подмена.
Возьмём типовую целевую архитектуру: четыре независимые системы хранения по несколько петабайт, разнесённые по двум площадкам, две из них в режиме неизменяемого хранения. Состав при этом может быть почти любым в разумных пределах: две флеш-системы плюс две дисковые, две флеш плюс две ленточные библиотеки, готовые аплайнсы производителя под резервное копирование или собранный на своём железе Ceph с объектным доступом. Это вопрос денег и требований к скорости, а не догма.
Но первое, что нужно проговорить вслух: это четыре системы, а не одна суммарной ёмкости. Независимые системы не суммируются ни по отказоустойчивости — отказ одной не компенсируется тремя другими сам собой, — ни по лицензии программного обеспечения. А соблазн взять самое крупное число из проекта и умножить на ставку возникает буквально у всех.
Неизменяемое хранение регулярно путают с резервированием. Копия на второй площадке защищает от отказа оборудования и аварии на площадке. Неизменяемость — от скомпрометированной учётной записи администратора. Три копии в двух центрах не спасают, если у злоумышленника есть административный доступ к обоим.
И ещё одно, о чём в спецификациях почти не пишут: приёмник — это обычно не одна система, а несколько ярусов с разными задачами.
На площадке стоит быстрая система хранения под мгновенное восстановление — глубина там маленькая, зато сервис поднимается за часы. Рядом ёмкая и медленная, где живёт основная глубина. Ленточная библиотека под архив — там же или на удалённой площадке. Четвёртым ярусом хорошо ложится объектное хранилище в арендованном облаке.
Последнее избавляет от необходимости строить на второй площадке полный комплект хранения. Вместо второго набора массивов там достаточно медиа-серверов — вычислительной части без данных. При катастрофе на первой площадке они забирают данные из облака и разворачивают сервисы у себя. Медленнее, чем с готовой репликой под боком, — зато вы не платите за второй комплект дисков, который годами ничего не делает.
Неизменяемость при этом — свойство отдельного яруса, а не всей конструкции. Её включают там, где она нужна, и это отдельная строка в лицензии.
И то, о чём вспоминают позже всего. Стратегия резервного копирования не существует отдельно от стратегии аварийного восстановления — это одна конструкция, и проектировать её половинами нельзя. Копии, которые прекрасно снимаются, но не разворачиваются в срок, защищают только отчётность.
А есть и третья, которую формулируют совсем редко: стратегия восстановления. Не «как мы храним» и не «куда мы переезжаем», а «сколько бизнес готов простаивать и что мы успеваем поднять за это время». Именно она задаёт требования к ярусам: что должно лежать на быстром хранилище, что можно отпустить на ленту, а что уедет в облако.
Пример из практики, обезличенно. Проект, где всё построено на Ceph и PostgreSQL. Архитектор заказчика посчитал полное восстановление на второй площадке в экономном варианте — вышло двадцать три часа простоя и больше. Для бизнеса неприемлемо, и вопрос сразу перешёл из плоскости «сколько стоит хранить» в плоскость «сколько стоит не работать сутки». Хорошая новость в том, что посчитали это на этапе проектирования, а не после аварии.
Отсюда неприятное следствие, о котором молчат обе стороны сделки. Лицензия покупает право защищать объём определённым набором функций — но не скорость копирования и не время восстановления. Оно определяется архитектурой: числом потоков, каналом, производительностью дискового пула, тем, откуда именно вы поднимаете данные. Ни одна из этих величин в лицензии не фигурирует. Можно купить полный периметр по максимальному уровню функциональности и получить время восстановления, не укладывающееся ни в один норматив.
И последнее. Тип приёмника влияет на метрику лицензирования. Переход с ленты на диск или объектное хранилище — это не только замена железа: вспомогательная копия на объект и режим блокировки объектов считаются по своим правилам. Расчёт, сделанный под предыдущую архитектуру, нельзя переносить в новую механически, даже если защищаемый объём не изменился ни на терабайт.
Третья подмена
Физика шифротекста
Стойко зашифрованные данные не сжимаются. Не «сжимаются хуже» — не сжимаются вовсе.
Третья подмена — самая техническая и самая дорогая. Разбирается за абзац, а спорят о ней месяцами.
Стойко зашифрованные данные не сжимаются. Не «сжимаются хуже» — не сжимаются. Предел компрессии шифротекста единица с сотыми. Причина в природе шифрования: хороший алгоритм отдаёт последовательность, статистически неотличимую от случайной, а сжатие работает ровно на статистической избыточности. В шифротексте сжимать нечего.
Это не наше наблюдение, это позиция производителей. В документации Commvault есть прямой пример: кассета номиналом 110 гигабайт, на которую при сжатии без шифрования ложилось около 190 гигабайт, при включённом шифровании принимает примерно 124. Коэффициент падает с 1,73 до 1,13 — тот же носитель, тот же привод, та же настройка сжатия.
Там же производитель делает второй вывод, ещё практичнее: аппаратное сжатие на зашифрованных данных включать не рекомендуется — объём может не уменьшиться, а вырасти. Это не парадокс: попытка сжать случайную последовательность добавляет служебные структуры алгоритма, не убирая ничего. Отдельной строкой сказано, что программное шифрование сводит аппаратное сжатие на нет.
Не 1,7. Не 2. Не 5. Единице.
Отсюда правило для сайзинга, до неприличия простое. Если поток шифруется на стороне программного обеспечения резервного копирования, коэффициент сокращения при расчёте ёмкости закладывается равным единице. Не 1,7. Не 2. Не 5. Единице.
Разбор цифры
Из чего собран заявленный коэффициент
Коэффициент из презентации обычно измерен честно. Просто не на том потоке, который будет у вас.
Тогда откуда в презентациях берутся 1,7, три и пять? Ответ неприятен своей обыденностью: эти цифры чаще всего не выдуманы. Они честно измерены — просто не на том, о чём вы подумали.
Заявленный коэффициент почти всегда суммарный. В него входит дедупликация — устранение повторяющихся блоков, на незашифрованных данных основной вклад. Отсечение нулевых блоков — пустые области выделенных, но не заполненных дисков. Тонкое выделение ёмкости. И сжатие незашифрованных частей потока: даже когда данные шифруются, служебная часть остаётся открытой — метаданные, заголовки заданий, каталоги, — она сжимается нормально.
Сложите это на стенде с типовыми данными — полтора-два получите законно. Перенесите на поток, зашифрованный на стороне софта копирования, — получите единицу. Обе цифры настоящие, условия разные.
Есть и второй механизм расхождения. Дедупликация зашифрованных данных возможна, но только при детерминированном шифровании: одинаковый блок при фиксированном ключе всегда даёт одинаковый шифротекст. Как только применяется ключ на сессию, идентичные блоки превращаются в разные последовательности, и дедупликация падает почти до единицы. Коэффициент зависит от настройки шифрования, о которой в презентации не сказано ни слова — и два заказчика с одинаковым железом получают разный результат.
И третий случай, с которым мы столкнулись напрямую. Технологии реального сокращения хост-шифрованных данных существуют: массив получает ключ через отдельный сервер управления ключами, расшифровывает поток, дедуплицирует и перешифровывает своим. Показатели там высокие и не поддельные. Но такая функция может жить только в одной линейке, требовать стороннего компонента и быть снята с поддержки — а в той линейке, которую вам предлагают, аналога не быть вовсе. Цифра настоящая. Просто она про другой продукт.
Отсюда правильная форма претензии к поставщику. Не «вы завышаете коэффициент» — на это всегда найдётся законный ответ. А «покажите методику измерения раздельно: сколько даёт сжатие именно шифропотока и сколько остальные механизмы». Отвечают либо цифрами, либо молчанием, и оба ответа вам одинаково полезны.
Заодно про ёмкость: в проектах копирования у неё три значения — физическая, разрешённая лицензией и полезная, что осталось после схемы избыточности. Модель, где массив приезжает укомплектованным полностью, а оплачивается меньшая доля, встречается всё чаще. Первый платёж ниже — зато вы привязаны к производителю на весь срок доращивания.
Чек-лист
Что спросить до того, как согласован бюджет
Двенадцать вопросов и три формулировки для технического задания.
Двенадцать вопросов. Если на каждый есть ответ в письменном виде — расчёт можно защищать.
Отдельно — две формулировки для технического задания.
Про ёмкость: полезная ёмкость и скорость восстановления указываются физические, измеренные на данных, не поддающихся дедупликации и сжатию; заявленный коэффициент сокращения сопровождается описанием методики измерения и перечнем учитываемых механизмов.
Про форму требования: фиксируйте логический объём, который система обязана отдать на выходе, и не диктуйте поставщику количество и тип дисков. Как он этого добьётся — его задача и его риск. И помните, что цифра коэффициента в договоре без методики измерения не значит ничего: спор упрётся в то, что стороны меряли разное.
Итог
Вместо вывода
Ни одна из трёх подмен не является обманом. Обе стороны называют настоящие цифры из настоящих документов — просто цифры относятся к разным величинам, а называются одинаково.
Средство одно, и оно скучное: на каждом числе в расчёте спрашивать, что именно оно измеряет и при каких условиях получено. Недели на подготовке — месяцы экономии на внедрении.
Если считаете сейчас систему копирования или продлеваете лицензии — присылайте свой расчёт, разберём по пунктам чек-листа. Обычно расхождение находится в первых трёх.