За последний год через нас прошло больше десятка технических заданий на системы резервного копирования — банки, телеком, госструктуры. В каждом есть требуемая ёмкость, глубина хранения и окно копирования. Норматив времени восстановления по классам сервисов видели в двух.
Дальше происходит одно и то же. Систему внедрили, зелёные статусы идут, отчёты формируются. Потом кто-то просит восстановить виртуальную машину на терабайт, и она восстанавливается девять часов. К нам приходит вопрос: почему так, ведь массив выдаёт двадцать гигабайт в секунду, а сеть двадцать пять гигабит.
Отвечаем: потому что ни массив, ни сеть в этой арифметике не участвуют. Участвует скорость одного потока и то, из чего этот поток читает. Всё остальное — потолок, до которого дело не дошло.
Ниже — пять развилок, на которых расчёт расходится с реальностью. Разбираем в том порядке, в каком они всплывают в проектах.
Природа данных
Что вообще сожмётся
Коэффициент редукции определяется не массивом, а тем, что на него пишут. Дедупликация выигрывает на повторах, а не на содержимом.
Первое место, где ломается сайзинг, — коэффициент редукции. Он приходит из спецификации массива, попадает в расчёт ёмкости и живёт там до момента, когда пул заполняется в полтора раза быстрее плана.
Причина простая: эффективность дедупликации и сжатия определяется не массивом, а тем, что на него пишут. Программа резервного копирования почти всегда сжимает и дедуплицирует поток на своей стороне — на медиасервере, до отправки. На массив приезжают данные, близкие к случайным. Сжать их ещё раз нельзя, и это не дефект массива, а свойство данных.
Обратите внимание на верхнюю строку. Дедупликация действительно даёт кратный выигрыш — но не на содержимом, а на повторах. Двадцать полных копий одного набора ужимаются великолепно, потому что девятнадцать из них состоят из уже известных блоков. Ровно поэтому коэффициент, полученный на дедуп-пуле резервных копий, нельзя переносить на первичное хранилище, а коэффициент первичного хранилища — на репозиторий копий. Это разные числа, полученные из разной природы.
Что с этим делать практически. Считать ёмкость от сырых терабайт. Редукцию учитывать только там, где источником данных является сама система резервного копирования, и только по замеру на выборке реальных данных заказчика — неделя тестового копирования показывает больше, чем любая презентация.
Расчёт ёмкости
Сколько это в терабайтах на самом деле
Логический объём — это не «сколько у нас данных». Это полная копия плюс прирост на глубину плюс каждый уровень длительного хранения.
Вторая развилка — из чего вообще складывается объём. Логический объём хранения — это не «сколько у нас данных». Это полная копия плюс суточный прирост, умноженный на глубину ежедневных точек, плюс каждый уровень длительного хранения отдельным слагаемым.
Суточный прирост при этом нельзя брать типовым. Разброс по системам, которые видим, — от одного процента до пятнадцати. Разница между тремя и восемью процентами на трёхстах терабайтах защищаемых данных — это полтора терабайта в сутки, сорок пять в месяц. На таких величинах ошибка в предположении дороже ошибки в выборе вендора.
График показывает то, что стоит держать перед глазами при чтении любого коммерческого предложения. Между честным расчётом и расчётом «поставим три к одному» — трёхкратная разница в закупаемой ёмкости. Продавцу это выгодно ровно один раз, при подписании. Дальше выгодно уже не ему.
Ошибка в предположении о суточном приросте обходится дороже, чем ошибка в выборе вендора.
Отдельной строкой считается неизменяемый ярус, и об этом ниже, в разделе про исчезнувший физический разрыв.
Арифметика восстановления
Почему восстановление идёт в один поток
Время восстановления равно объёму, делённому на скорость самого узкого последовательного участка тракта. Всё остальное — потолок.
Теперь та самая арифметика. Время восстановления равно объёму, делённому на скорость самого узкого последовательного участка тракта. Суммарная производительность массива, ширина канала и количество ядер на медиасервере в формулу не входят.
Тракт выглядит так: чтение блоков из дедуплицированного хранилища, регидратация, распаковка, передача, запись в целевое хранилище. Ограничителем почти всегда становится первое звено, потому что чтение из дедуп-пула — это не последовательное чтение, а выборка блоков по всему пулу. На дисках это десятки мегабайт в секунду.
Здесь же живёт заблуждение, которое стоит проговорить отдельно. На копировании параллелизм есть: программа распределяет потоки по машинам и по дискам, и увеличение числа читателей действительно расширяет окно. На восстановлении параллелизм ограничен структурой объекта. Один виртуальный диск не делится между потоками — один диск, один поток, сколько читателей ни ставь. А для отдельных сочетаний платформы виртуализации и агента ограничение жёстче: полное восстановление одной машины идёт в один поток даже при нескольких дисках, и настройкой это не переопределяется.
Арифметика получается неприятная. При скорости порядка тридцати мегабайт в секунду полное восстановление перестаёт быть применимой механикой уже на единицах терабайт — не потому, что оно не работает, а потому, что результат приходит позже любого разумного норматива. Десять терабайт — это трое с лишним суток. За это время вопрос «когда восстановимся» перестаёт быть техническим.
Вывод для проектирования: закладывая норматив, надо знать не сколько потоков поддерживает продукт вообще, а сколько потоков он выделит на восстановление одного конкретного объекта в вашей связке версий. Этот вопрос имеет смысл задавать вендору письменно, а ответ подшивать к проекту.
Уровни восстановления
Одной механики не бывает
Полное восстановление медленное по природе. Ускорять его бессмысленно — его надо не использовать там, где нужен быстрый возврат.
Раз полное восстановление медленное по природе, ускорять его бессмысленно. Правильный ход — его не использовать для того, что должно вернуться быстро.
Зрелая система — это три-четыре механики с разным временем и разной ценой. Восстановление из аппаратного снимка на массиве вообще не читает репозиторий и для свежих точек даёт минуты. Мгновенный запуск поднимает машину сразу, презентуя диски прямо из копии, а фактический перенос данных идёт фоном. Копия без дедупликации читается линейно и предсказуемо. Полный restore из основного пула остаётся штатным вариантом для всего, что не имеет жёсткого норматива.
Стоимость этих уровней растёт снизу вверх, и здесь проект обычно уходит в одну из двух крайностей. Либо быстрый ярус не закладывают вовсе — тогда норматив в четыре часа существует только на бумаге. Либо его закладывают под весь парк, и бюджет вырастает вдвое ради машин, которые никто не станет возвращать в авральном режиме. Правильный размер быстрого яруса определяется не долей от общего объёма, а суммой данных тех сервисов, которые действительно обязаны вернуться в течение рабочего дня. В нашей практике это обычно десять-пятнадцать процентов защищаемого объёма, и цифру эту надо не оценивать, а выписать поимённо.
У мгновенного запуска есть подвох, на который регулярно наступают. Механика формально работает с любого носителя, но запущенная с медленного пула машина стартует быстро и работает непригодно медленно. Формально сервис поднят, фактически им нельзя пользоваться, а в отчёте всё зелёное. Если закладываете мгновенный запуск в норматив — ярус под него должен быть на флеше, иначе это не решение, а его имитация.
Сервис поднят, пользоваться им нельзя, а в отчёте всё зелёное.
И главное: строку таблицы «допустимое время простоя» заполняет не инфраструктура. Инфраструктура не имеет права назначать бизнесу, сколько он может стоять. Она может только честно сказать, во сколько обойдётся каждый вариант.
Платформенная защита
Что умеет сама платформа
Под словами «у нас всё реплицируется» скрываются четыре разные механики с разной областью применения и разной ценой.
На Nutanix — а гиперконвергенция в наших проектах почти всегда означает именно его — половина механик из предыдущего раздела уже встроена, и это меняет разговор с заказчиком. Меняет, к сожалению, не всегда в лучшую сторону: под словом «у нас всё реплицируется» регулярно скрываются четыре совершенно разные вещи с разной областью применения. Разберём их по порядку, от дешёвой к дорогой.
Локальный снимок на том же кластере. Делается мгновенно, откатывает состояние за минуты, стоит почти ничего по времени. И живёт он в том же контейнере, на тех же дисках, под тем же Prism Central. Отказ кластера, потеря площадки или компрометация административной учётной записи убирают и продуктив, и точки восстановления одним движением. Это механизм отката, а не резервная копия — и в отчёте регулятору он должен называться именно так. Второй нюанс, о котором вспоминают поздно: глубокие цепочки снимков занимают дорогой флеш продуктивного кластера, тот самый, который покупался под нагрузку.
Репликация на соседний кластер той же площадки. Появляется отдельный домен отказа по железу, и это уже принципиально другой уровень. Nutanix Disaster Recovery даёт здесь три режима: асинхронный с точкой раз в час и реже, NearSync на облегчённых снимках LWS с интервалом от одной до пятнадцати минут и синхронную репликацию с нулевой потерей данных — последняя требует канала с задержкой до пяти миллисекунд. Закрывает отказ кластера. Не закрывает площадку и не закрывает шифровальщика: логическую порчу реплика аккуратно повторит с задержкой в один интервал.
Репликация на удалённый кластер. То же самое плюс площадка, и здесь ограничителем становится канал. Первичная синхронизация идёт полными копиями, дальше — только изменения, но режимы с минутными интервалами чувствительны и к полосе, и к скорости изменения данных. Начиная с NCI 7.5 в одной политике защиты можно смешивать до четырёх доменов отказа: синхронно на соседнюю площадку, асинхронно или NearSync в регион, плюс длительное хранение в объектном хранилище. Это уже не «репликация», а полноценная топология, и проектировать её надо соответственно.
Выгрузка снимков в объектное хранилище — Multicloud Snapshot Technology. Снимает глубокие цепочки с продуктивного пула, кладёт их в любое совместимое с S3 хранилище и позволяет восстановиться в любую точку, где развёрнут Nutanix. Интервал — от часа. Важное свежее изменение: Instant Restore, ставший общедоступным в Prism Central 7.5.1, запускает машину по метаданным, не дожидаясь выгрузки всех данных, — то есть механика мгновенного запуска работает теперь и из объекта, а не только с локального яруса. Из платформенных механик это ближе всего к настоящей резервной копии. Общая для всех них оговорка: без Nutanix Guest Tools снимок согласован только на уровне отказа, и нагруженной базе данных этого не хватит.
Выделенный контур резервного копирования. Отдельный кластер или отдельная площадка под копии, где работает уже программа резервного копирования со своим репозиторием, каталогом и неизменяемостью. Нужен там, где требуется независимость от компрометации самой платформы, гранулярный возврат объектов внутри приложений, единый каталог по всему парку — включая то, что вне гиперконвергенции, — и хранение годами под требования регулятора.
Практическое правило, к которому приходим: платформенные механики закрывают отказ и ошибку, программа резервного копирования закрывает злой умысел и регуляторику. Это не конкуренция, а разделение зон ответственности, и в грамотном проекте работают обе. Ошибка проектирования начинается там, где одну зону пытаются закрыть средствами другой: снимками — комплаенс, а полным восстановлением из репозитория — норматив в пятнадцать минут.
Ярусы и протоколы
Куда это всё класть
Репозиторий редко бывает однородным. Главный вопрос по протоколам — не «умеет ли массив», а кто в архитектуре их предоставляет.
Репозиторий редко бывает однородным. В нормальной архитектуре выделяется до пяти ролей: приёмный ярус под окно копирования, основной пул на оперативную глубину, быстрый ярус под жёсткий норматив, неизменяемый ярус и архив. Совмещать роли можно, но осознанно.
Закрывать эти роли можно не только классическими массивами, и в матрице ниже мы специально смешали три разных типа целевого хранилища — в реальных проектах они и стоят рядом.
Классические массивы. Lenovo ThinkSystem DG на платформе unified — файловый, блочный и объектный доступ на сквозном NVMe. Lenovo ThinkSystem DS — то же железо и та же операционная система хранения, но только блок. Lenovo ThinkSystem DE на SANtricity — ёмкость за разумные деньги, ради которой этот класс и берут под основной пул. Про разницу между первыми двумя — чуть ниже, в части про протоколы.
Гиперконвергентный кластер как целевое хранилище. Lenovo ThinkAgile HX650 в гибридной конфигурации с Nutanix Unified Storage закрывает и файловую шару, и объектный доступ прямо с платформы, без отдельного массива. Для заказчика, который уже живёт на Nutanix, это обычно самый дешёвый способ получить объектный ярус и самый быстрый по срокам: не новая платформа, а ещё один кластер знакомой.
И сразу оговорка, которую обязаны проговаривать вслух. Отдельный кластер — это отдельный домен отказа по железу, но не по платформе: тот же вендор, тот же программный стек, тот же контур администрирования, а нередко и тот же Prism Central. Сценарий «скомпрометирован администратор платформы» такой репозиторий не закрывает, и в матрице это вынесено отдельной строкой. Плюс гибридная конфигурация на дисках не годится под быстрый ярус восстановления — только под ёмкостный.
Программно-определяемое объектное хранилище. Cloudian HyperStore на серверах Lenovo ThinkSystem SR650 V4 отвечает ровно на две строки матрицы: неизменяемый ярус и архив. Object Lock, горизонтальное масштабирование добавлением узлов, стоимость терабайта, подбирающаяся к ленточной при несопоставимой скорости доступа. Из готовых аппаратных альтернатив в той же роли — Everpure, бывшая линейка Pure Storage FlashBlade//E: объектный доступ и неизменяемость идут из коробки, ценой закрытой платформы и привязки к одному вендору.
Общее правило для всех трёх вариантов и, пожалуй, самое дорогое из всего раздела: наличие объектного протокола не равно сертификации. Cloudian, Everpure, объектный ярус на самой платформе виртуализации — каждый надо проверять в матрице совместимости той версии программы резервного копирования, которую вы ставите.
У нас был проект, где целевое хранилище, честно и полностью поддерживающее S3, просто отсутствовало в списке проверенных для выбранной программы резервного копирования. Выяснилось это после того, как платформа хранения была определена, и архитектуру пришлось пересобирать. И вот тут история получает продолжение, ради которого её и рассказываем: примерно через год производитель ПО добавил это хранилище в список поддерживаемых. Сегодня тот же выбор был бы правильным.
Ещё одно решение, которое принимают молча, а платят за него потом, — совмещение ролей на одной системе. Приёмный ярус и основной пул на одной коробке выглядят экономией ровно до первого совпадения окна копирования с восстановлением: запись потока копий и рандомное чтение регидратации дерутся за одни и те же диски и за одну очередь контроллера. В обычную ночь это незаметно, а в аварию — именно тогда, когда система нужна, — обе операции замедляются одновременно. Если совмещаете, закладывайте это в расчёт производительности, а не только в расчёт ёмкости.
Там же держите в голове заполнение. Дедуплицированный пул, набитый выше восьмидесяти пяти процентов, начинает деградировать по скорости, а сборка мусора перестаёт успевать освобождать место в темпе поступления новых копий. Пятнадцать-двадцать процентов свободного — это не запас на вырост, а рабочий параметр, без которого заявленные цифры не воспроизводятся. В спецификациях эта строка не пишется, в жизни она обязательна.
Мораль не в том, что кто-то кого-то не поддерживал. Мораль в том, что список живой и двигается в обе стороны, а значит смотреть его надо на дату проекта и на конкретную версию продукта — не по памяти, не по прошлогоднему опыту и не по строчке «S3-совместимо» в спецификации. Модель тоже уточняйте: поддержка семейства не означает автоматически поддержку каждой линейки внутри него.
Отдельно про протоколы, потому что это самый частый спор в тендерах. Вопрос «должен ли массив уметь файловые и объектные протоколы» почти всегда задан неверно. Правильная постановка — кто в архитектуре предоставляет протокол.
Программы резервного копирования работают с файловым и объектным доступом сами. Репозиторий можно положить на сетевую шару, копию — в объектное хранилище с блокировкой объектов, а при мгновенном запуске медиасервер сам поднимает файловый ресурс со своего блочного тома и презентует его гипервизору. Массиву для этого файловые протоколы не нужны. Функционально блочный массив плюс медиасервер закрывают весь набор сценариев.
Отсюда проверочный вопрос к любому предложению: покажите в архитектуре точку, где используется каждый заявленный протокол. Нет точки — требование избыточно, и вы за него платите. Есть точка — требование обосновано, и это нормальное инженерное решение: прямая презентация ресурса с массива действительно снимает нагрузку с медиасерверов, а объектный ярус на том же оборудовании упрощает эксплуатацию. Просто это архитектурный выбор, а не техническая необходимость, и подавать его надо честно.
И ещё один потолок, о котором вспоминают поздно. Он находится не в носителе, а в фабрике. Ленточные приводы актуального поколения дают порядка четырёхсот мегабайт в секунду на устройство. Двадцать четыре привода — это девять с половиной гигабайт в секунду теоретически. Но если библиотека подключена линками по восемьсот мегабайт в секунду, то на линк приходится ровно два привода на полной скорости, а остальное простаивает. Из той же арифметики следует, что сплошная вычитка десяти петабайт при реальной полосе в три гигабайта в секунду — это больше месяца непрерывной работы. Миграцию архива на новую платформу надо планировать как отдельный проект с собственным окном, а не строкой «перенос данных» в календарном плане.
Неизменяемость
Air gap кончился, чем закрываем
Физический разрыв исчез вместе с лентой в оперативном контуре. Замена состоит из двух слоёв и работает только при обоих.
Раньше защита копий от целенаправленного удаления держалась на физике: картридж извлечён из библиотеки, и никакие административные права до него не дотянутся. При переходе на диск и объект этот разрыв исчезает, и его надо чем-то заменить.
Замена состоит из двух слоёв, и работает она только при обоих. Технический слой — неизменяемость на уровне хранилища, стандартом стала блокировка объектов по модели «записал один раз, читаешь много». Организационный слой — разделение прав: учётная запись, управляющая копированием, не должна иметь возможности сократить срок удержания, снять блокировку или удалить хранилище. Сюда же подтверждение критичных операций вторым администратором.
Деталь, которую стоит проверять руками. У блокировки объектов два режима. Мягкий допускает снятие привилегированной учётной записью — то есть ровно тем, кого вы и опасаетесь. Строгий не допускает удаления до истечения срока никем. От целенаправленной атаки защищает только строгий, а по умолчанию у разных хранилищ включается разное.
Дальше цена. Неизменяемость почти всегда обходится дороже, чем следует из общего коэффициента, и по двум причинам. Первая: изолированные наборы, как правило, не используют общие дедуп-ссылки с основным пулом — они самодостаточны, чтобы восстановление было возможно при полной утрате репозитория, а самодостаточность означает собственные полные копии. Вторая: пока срок удержания не истёк, место не освобождается, даже если копия уже не нужна. Ошибка в сроке в большую сторону лечится только ожиданием.
Поэтому ёмкость неизменяемого яруса считается отдельной строкой, от полного объёма и глубины удержания, без коэффициента основного пула. Консервативно — да. Но именно эта строка чаще всего оказывается заниженной.
Выбор платформы
Две философии: чем отличается софт
Формально оба продукта решают одну задачу. Различия растут из разных представлений о том, что происходит с данными на предприятии.
В короткий список у нас обычно попадают два продукта. Формально они решают одну задачу, но исходят из разных представлений о том, что вообще происходит с данными на предприятии, — и различия в возможностях и в цене растут именно отсюда.
За пределами этих двух остаётся ниша платформенно-нативных продуктов — они хороши там, где вся виртуализация живёт на одной платформе, и заслуживают отдельного разговора. Здесь их не сравниваем: смешивать в одной таблице универсальные корпоративные системы и решения под конкретную платформу — значит заведомо получить некорректное сравнение.
Функциональные таблицы редко определяют выбор: базовый сценарий закрывают оба. Решают ответы на четыре вопроса. Какая доля парка приходится на нестандартные источники — если в инфраструктуре живут унаследованные системы и корпоративные базы с особыми требованиями, ширина покрытия становится решающей. Насколько глубока интеграция с вашей платформой виртуализации — нативная безагентная работа убирает целый слой прокси-серверов. Сколько людей это будет эксплуатировать — продукт, требующий выделенного администратора, в команде из трёх человек становится риском, а не защитой от него. И как система будет расти: вширь по количеству объектов или вглубь по объёму — от этого напрямую зависит, какая модель лицензирования окажется дешевле через три года.
Пятый вопрос стоит отдельно, потому что на нём горят проекты. Сертифицирован ли выбранный целевой массив для нужной версии продукта. Совместимость по протоколу не равна сертификации: хранилище, честно поддерживающее объектный доступ, может отсутствовать в матрице проверенных для конкретного ПО. Выясняется это на внедрении, когда железо уже стоит в стойке.
Чек-лист
Что спросить до того, как считать спецификацию
Двенадцать вопросов, которые превращают круглое число в расчёт, который можно защищать.
- Для каждого класса сервисов зафиксированы допустимое время простоя и допустимая потеря данных — и подписаны владельцами систем, а не инфраструктурой?
- Объём считался по занятому месту или по выделенному? Исключены ли реплики, служебные и брошенные машины?
- Откуда взялся коэффициент редукции и к какому именно потоку данных он относится?
- Суточный прирост измерен или принят типовым?
- Какой механикой достигается норматив для каждого класса — и чем это подтверждено, кроме суммарной пропускной способности железа?
- Сколько потоков продукт выделит на восстановление одного объекта в вашей связке версий?
- Ёмкость неизменяемого яруса посчитана отдельной строкой, без общих ссылок с основным пулом?
- Для каждого требуемого протокола указана точка его использования в архитектуре?
- Целевое хранилище присутствует в матрице совместимости нужной версии продукта?
- Может ли учётная запись, управляющая копированием, сократить срок удержания или удалить репозиторий?
- Перенос существующих данных выделен в отдельный этап с расчётом по полосе тракта?
- Есть ли регламент тестового восстановления с замером фактического времени — и когда он исполнялся последний раз?
Итог
Вместо вывода
Резервное копирование — единственная инфраструктурная система, ценность которой измеряется в момент отказа всего остального. Всё остальное время она выглядит статьёй расходов, и поэтому её так легко спроектировать формально: ёмкость есть, глубина есть, статусы зелёные.
Критерий зрелости простой. Если в организации есть документ, где для каждого класса сервисов записано допустимое время простоя, и есть протокол тестового восстановления, где записано фактическое, — система спроектирована. Если такого документа нет, обсуждать коэффициенты, лицензии и модели массивов преждевременно: считать нечего.
Если у вас сейчас лежит на столе ТЗ или коммерческое предложение — прогоните его по чек-листу выше. Полчаса времени, и обычно уже после третьего вопроса понятно, о чём разговаривать с подрядчиком.
Цифры в публикации — расчётные иллюстрации порядка величин; всё, что влияет на закупку или на норматив, проверяется на конкретной конфигурации.