Последний год я разбираю чужие расчёты систем резервного копирования чаще, чем делаю свои. И почти в каждом вижу одно и то же: бюджет, посчитанный весной, к моменту внедрения вырос в разы. Заказчик считает, что его обманули. Поставщик показывает переписку и документы, где всё сходится. И оба правы, потому что врать никому не пришлось.
Останній рік я розбираю чужі розрахунки систем резервного копіювання частіше, ніж роблю свої. І майже в кожному бачу одне й те саме: бюджет, порахований навесні, до моменту впровадження виріс у рази. Замовник вважає, що його обдурили. Постачальник показує листування і документи, де все сходиться. І обидва мають рацію, бо брехати нікому не довелося.
Over the past year I have reviewed other people’s backup sizing more often than I have done my own. And in nearly every one I see the same thing: a budget calculated in spring has multiplied by the time of deployment. The customer believes they were misled. The vendor produces the correspondence and the documents, and everything in them adds up. Both are right, because nobody had to lie.
Дело в том, что в расчёте резервного копирования есть три места, где одна величина незаметно заменяется другой. Объём защищаемых данных подменяется ёмкостью хранилища копий. Ёмкость хранилища — физическим объёмом дисков. А физический объём — коэффициентом сокращения, который к вашим данным может вообще не относиться. Каждая подмена по отдельности выглядит мелочью. Вместе они дают расхождение на порядок.
Річ у тім, що в розрахунку резервного копіювання є три місця, де одна величина непомітно замінюється іншою. Обсяг захищуваних даних підмінюється ємністю сховища копій. Ємність сховища — фізичним обсягом дисків. А фізичний обсяг — коефіцієнтом скорочення, який до ваших даних може взагалі не стосуватися. Кожна підміна окремо виглядає дрібницею. Разом вони дають розходження на порядок.
The reason is that a backup calculation has three places where one quantity is quietly swapped for another. The volume of protected data is swapped for the capacity of the copy repository. The repository capacity is swapped for the physical capacity of the disks. And the physical capacity is swapped for a reduction ratio that may have nothing to do with your data at all. Each substitution on its own looks trivial. Together they produce an order-of-magnitude gap.
Дальше — разбор всех трёх. С формулировками для технического задания и вопросами, которые стоит задать до того, как бюджет согласован.
Далі — розбір усіх трьох. З формулюваннями для технічного завдання і питаннями, які варто поставити до того, як бюджет узгоджений.
What follows is a breakdown of all three — with wording you can put into a specification and questions worth asking before the budget is agreed.
01
Метрика лицензииМетрика ліцензіїThe licence metric
Периметр, а не хранилище
Периметр, а не сховище
The scope, not the repository
Лицензия считается по объёму защищаемых источников. Ёмкость хранилища копий в этом расчёте не участвует вообще.
Ліцензія рахується за обсягом захищуваних джерел. Ємність сховища копій у цьому розрахунку не бере участі взагалі.
Licensing is calculated on the volume of protected sources. The capacity of the copy repository plays no part in it at all.
Начну с величины, которая определяет цену лицензии.
Почну з величини, яка визначає ціну ліцензії.
Let me start with the quantity that sets the licence price.
Лицензия считается по объёму защищаемых источников. Не по объёму копий, которые система создаст. Не по ёмкости хранилища, куда эти копии лягут. По тому, сколько данных лежит в системах, которые вы берёте под защиту. Звучит очевидно ровно до момента, когда нужно назвать число.
Ліцензія рахується за обсягом захищуваних джерел. Не за обсягом копій, які система створить. Не за ємністю сховища, куди ці копії ляжуть. За тим, скільки даних лежить у системах, які ви берете під захист. Звучить очевидно рівно до моменту, коли треба назвати число.
Licensing is calculated on the volume of protected sources. Not on the volume of copies the system will create. Not on the capacity of the repository those copies land in. On how much data sits in the systems you are putting under protection. That sounds obvious right up to the moment you have to name a number.
Потому что даже на одной виртуальной машине таких чисел три, и все три настоящие. Сколько дисков выделено. Сколько на них занято. И сколько из занятого попадает в периметр — это зависит от того, забираете ли вы системные разделы, подкачку, временные каталоги. Разница между первым и третьим доходит до двукратной.
Бо навіть на одній віртуальній машині таких чисел три, і всі три справжні. Скільки дисків виділено. Скільки на них зайнято. І скільки із зайнятого потрапляє в периметр — це залежить від того, чи забираєте ви системні розділи, підкачку, тимчасові каталоги. Різниця між першим і третім сягає дворазової.
Because even for a single virtual machine there are three such numbers, and all three are real. How much disk is provisioned. How much of it is used. And how much of the used data falls inside the scope — which depends on whether you take system volumes, swap and temp directories. The gap between the first and the third reaches twofold.
Три законных ответа на вопрос, сколько данных у одной виртуальной машиныТри законні відповіді на питання, скільки даних в однієї віртуальної машиниThree legitimate answers to “how much data does this one VM have?”
Все три числа настоящие и берутся из одной консоли. Разница между первым и третьим доходит до двукратной.Усі три числа справжні й беруться з однієї консолі. Різниця між першим і третім сягає дворазової.All three numbers are real and come from the same console. The gap between the first and the third reaches twofold.
Бюджет обычно считают по первому числу — его проще всего вытащить из консоли: открыл, выгрузил, сложил. Дальше два исхода. Посчитали по выделенному — переплатили, выяснится через год при продлении. Посчитали по занятому, но забыли половину систем — недоплатили, и это вскроется посреди внедрения, когда менять поздно. Второй случай хуже и встречается чаще.
Бюджет зазвичай рахують за першим числом — його найпростіше витягти з консолі: відкрив, вивантажив, склав. Далі два результати. Порахували за виділеним — переплатили, з’ясується через рік при продовженні. Порахували за зайнятим, але забули половину систем — недоплатили, і це розкриється посеред впровадження, коли міняти пізно. Другий випадок гірший і трапляється частіше.
Budgets are usually calculated on the first number, because it is the easiest to pull from the console: open it, export, add up. Two outcomes follow. Count provisioned capacity and you overpay — which surfaces a year later at renewal. Count used capacity but forget half the systems and you underpay — which surfaces mid-deployment, when it is too late to change anything. The second case is worse and happens more often.
И вторая развилка, которую путают ничуть не реже. Метрика бывает разная, и в одной спецификации их обычно две.
І друга розвилка, яку плутають анітрохи не рідше. Метрика буває різна, і в одній специфікації їх зазвичай дві.
And a second fork that is confused just as often. There is more than one metric, and a single specification usually contains two of them.
Виртуальная машина лицензируется по числу машин — обычно паками по десять, и объём данных роли не играет: машина есть машина, хоть пустая, хоть под завязку. Front-end терабайты — наоборот, лицензия по объёму, и число объектов в ней не считается.
Віртуальна машина ліцензується за кількістю машин — зазвичай паками по десять, і обсяг даних ролі не грає: машина є машина, хоч порожня, хоч під зав’язку. Front-end терабайти — навпаки, ліцензія за обсягом, і кількість об’єктів у ній не рахується.
A virtual machine is licensed by machine count — usually in packs of ten — and the data volume is irrelevant: a machine is a machine, empty or full. Front-end terabytes are the opposite: licensing by volume, with the number of objects not counted at all.
Ловушка в том, что одна и та же машина может считаться и так, и так. Если внутри неё Oracle или PostgreSQL, копировать её образом бессмысленно: получите либо неконсистентную копию, либо остановку базы на время снимка. Базу забирают агентом — с журналами, с восстановлением на точку во времени. И это уже front-end терабайты, а не «ещё одна машина в паке».
Пастка в тому, що та сама машина може рахуватися і так, і так. Якщо всередині неї Oracle або PostgreSQL, копіювати її образом безглуздо: отримаєте або неконсистентну копію, або зупинку бази на час знімка. Базу забирають агентом — із журналами, з відновленням на точку в часі. І це вже front-end терабайти, а не «ще одна машина в паку».
The trap is that the same machine can be counted either way. If Oracle or PostgreSQL runs inside it, image-level backup is pointless: you will get either an inconsistent copy or a database outage for the duration of the snapshot. A database is taken by agent — with logs and point-in-time recovery. And that is front-end terabytes, not “one more machine in the pack”.
Следствие двойное. В спецификации должны стоять обе позиции, и заранее известно, какие системы в какую попадают: список машин с базами составляется отдельно. И эти машины нельзя посчитать дважды — сначала в паке, потом в терабайтах. Двойной счёт я вижу примерно в каждом третьем расчёте, и всегда в пользу продавца.
Наслідок подвійний. У специфікації мають стояти обидві позиції, і заздалегідь відомо, які системи в яку потрапляють: список машин із базами складається окремо. І ці машини не можна порахувати двічі — спершу в паку, потім у терабайтах. Подвійний рахунок я бачу приблизно в кожному третьому розрахунку, і завжди на користь продавця.
The consequence is twofold. Both line items must appear in the specification, and it must be known in advance which systems fall into which: the list of database machines is compiled separately. And those machines must not be counted twice — first in the pack, then in terabytes. I see double counting in roughly one estimate in three, and always in the seller’s favour.
Отдельно про хранилище копий — тут путаница самая дорогая. Его ёмкость в расчёте лицензии не участвует вообще: она определяется глубиной хранения, схемой копирования, требованиями к неизменяемости. Систему на несколько петабайт можно строить под периметр в сотни терабайт, и это нормально. Когда я вижу в расчёте ставку лицензии, умноженную на ёмкость массива, дальше можно не смотреть.
Окремо про сховище копій — тут плутанина найдорожча. Його ємність у розрахунку ліцензії не бере участі взагалі: вона визначається глибиною зберігання, схемою копіювання, вимогами до незмінності. Систему на кілька петабайт можна будувати під периметр у сотні терабайт, і це нормально. Коли я бачу в розрахунку ставку ліцензії, помножену на ємність масиву, далі можна не дивитися.
A separate word about the copy repository — this is the most expensive confusion of all. Its capacity plays no part whatsoever in the licence calculation: it is driven by retention depth, the copy scheme and immutability requirements. A multi-petabyte system can legitimately serve a scope of a few hundred terabytes. When I see a licence rate multiplied by array capacity in an estimate, there is no need to read further.
02
Анатомия оценкиАнатомія оцінкиAnatomy of an estimate
Как периметр растёт слоями
Як периметр росте шарами
How the scope grows in layers
Периметр набирается слоями, и каждый следующий вспоминают позже предыдущего. Первый расчёт почти всегда учитывает один слой из пяти.
Периметр набирається шарами, і кожен наступний згадують пізніше за попередній. Перший розрахунок майже завжди враховує один шар із п’яти.
The scope is assembled in layers, each remembered later than the last. The first estimate almost always covers one layer out of five.
Теперь почему первоначальная оценка почти всегда занижена. Периметр набирается слоями, и каждый следующий вспоминают позже предыдущего.
Тепер чому первісна оцінка майже завжди занижена. Периметр набирається шарами, і кожен наступний згадують пізніше за попередній.
Now, why the initial estimate is almost always too low. The scope is assembled in layers, and each next one is remembered later than the one before.
Первым в расчёт попадает то, что видно в консоли виртуализации: ферма инвентаризована лучше всего, цифра берётся в один клик.
Першим у розрахунок потрапляє те, що видно в консолі віртуалізації: ферма інвентаризована найкраще, цифра береться в один клік.
The first thing to make it into the estimate is whatever is visible in the virtualisation console: the farm is the best-inventoried part of the estate and the number is one click away.
Вторым слоем приходят базы данных. Часть живёт на тех же машинах и уже посчитана, часть стоит на физических серверах и не посчитана нигде. И почти всегда выясняется, что копировать базу гипервизором и копировать агентом — это разный объём, разное время восстановления и разные строки в спецификации.
Другим шаром приходять бази даних. Частина живе на тих самих машинах і вже порахована, частина стоїть на фізичних серверах і не порахована ніде. І майже завжди з’ясовується, що копіювати базу гіпервізором і копіювати агентом — це різний обсяг, різний час відновлення і різні рядки в специфікації.
Databases arrive as the second layer. Some live on the same machines and are already counted; some sit on physical servers and are counted nowhere. And it almost always turns out that backing up a database via the hypervisor and via an agent means a different volume, a different recovery time and different lines in the specification.
Третьим идут файловые ресурсы: общие папки, архивы сканов, каталоги обмена с внешними системами. Их не считают заранее — за них нет единого ответственного.
Третіми йдуть файлові ресурси: спільні теки, архіви сканів, каталоги обміну із зовнішніми системами. Їх не рахують заздалегідь — за них немає єдиного відповідального.
Third come file shares: shared folders, scan archives, exchange directories with external systems. Nobody counts them in advance, because nobody owns them.
Четвёртым — контуры разработки и тестирования. Первый порыв: не продуктив, исключаем. А внутри копия боевой базы с настоящими данными, и восстанавливать её после сбоя всё равно придётся.
Четвертими — контури розробки і тестування. Перший порив: не продуктив, виключаємо. А всередині копія бойової бази зі справжніми даними, і відновлювати її після збою однаково доведеться.
Fourth are the development and test environments. The first instinct is to exclude them as non-production. But inside sits a copy of the live database with real data, and you will have to restore it after a failure anyway.
Пятым слоем приходит почта, уехавшая в облако, и тут метрика меняется полностью: лицензия считается по числу ящиков, а не по объёму. Привычная арифметика «терабайты умножить на ставку» не работает вовсе. Хуже того, число ящиков растёт по другим законам: компания может годами не набирать данных, но принимать людей — и лицензия растёт вместе со штатом.
П’ятим шаром приходить пошта, що поїхала в хмару, і тут метрика змінюється повністю: ліцензія рахується за кількістю скриньок, а не за обсягом. Звична арифметика «терабайти помножити на ставку» не працює зовсім. Гірше того, кількість скриньок росте за іншими законами: компанія може роками не набирати даних, але приймати людей — і ліцензія росте разом зі штатом.
The fifth layer is mail that has moved to the cloud, and here the metric changes completely: licensing is by mailbox count, not by volume. The familiar arithmetic of “terabytes times rate” does not work at all. Worse, mailbox count grows by different laws: a company can go years without accumulating data while still hiring people — and the licence grows with headcount.
Спрашиваешь, сколько занимает почта, — называют занятость хранилища под текущие копии. Это не метрика сайзинга.
Питаєш, скільки займає пошта, — називають зайнятість сховища під поточні копії. Це не метрика сайзингу.
Ask how much the mail takes up and you are told how full the repository is with current copies. That is not a sizing metric.
Там же мои любимые грабли. Спрашиваешь, сколько занимает почта, — называют занятость хранилища под копии. Это не метрика сайзинга, а то, сколько места копии занимают при сегодняшней глубине. К числу ящиков, которое и стоит в лицензии, оно отношения не имеет.
Там само мої улюблені граблі. Питаєш, скільки займає пошта, — називають зайнятість сховища під копії. Це не метрика сайзингу, а те, скільки місця копії займають за сьогоднішньої глибини. До кількості скриньок, яка і стоїть у ліцензії, воно стосунку не має.
And here is my favourite rake to step on. Ask how much the mail occupies and you are told how much repository space the copies take. That is not a sizing metric — it is how much room the copies happen to use at today’s retention. It has nothing to do with the mailbox count that the licence is actually based on.
Слои, из которых набирается периметр защитыШари, з яких набирається периметр захистуThe layers a protection scope is assembled from
Каждый следующий слой вспоминают позже предыдущего. Первый расчёт почти всегда учитывает один из пяти.Кожен наступний шар згадують пізніше за попередній. Перший розрахунок майже завжди враховує один із п’яти.Each next layer is remembered later than the one before. The first estimate almost always covers one of the five.
В одном из проектов, где мы вели расширение системы копирования, итоговый периметр вышел примерно впятеро больше первоначальной оценки. Данные за это время в пять раз не выросли. Просто первоначальная оценка учитывала один слой из пяти.
В одному з проєктів, де ми вели розширення системи копіювання, підсумковий периметр вийшов приблизно вп’ятеро більший за первісну оцінку. Дані за цей час у п’ять разів не зросли. Просто первісна оцінка враховувала один шар із п’яти.
In one project where we handled a backup system expansion, the final scope came out roughly five times the initial estimate. The data had not grown fivefold in that time. The initial estimate simply covered one layer out of five.
Бывает и наоборот: в другом проекте периметр по результатам аудита оказался немного меньше объёма, под который бронировали лицензию. Разница небольшая, но показательная — она взялась из инвентаризации, а не из ощущений. Нормальный расчёт защищает от переплаты ровно так же, как от нехватки.
Буває і навпаки: в іншому проєкті периметр за результатами аудиту виявився трохи меншим за обсяг, під який бронювали ліцензію. Різниця невелика, але показова — вона взялася з інвентаризації, а не з відчуттів. Нормальний розрахунок захищає від переплати рівно так само, як від нестачі.
The reverse happens too: in another project the audited scope came out slightly smaller than the volume the licence had been reserved for. A small difference, but a telling one — it came from an inventory rather than from impressions. A proper calculation protects against overpaying exactly as much as against coming up short.
03
Список пропусковПерелік пропусківThe list of omissions
Что забывают всегда
Що забувають завжди
What always gets forgotten
Инвентаризация источников — самостоятельный этап проекта, а не подготовка к нему.
Інвентаризація джерел — самостійний етап проєкту, а не підготовка до нього.
Inventorying the sources is a project stage in its own right, not the warm-up before one.
Список того, что всплывает последним, устойчив до скуки. Проверьте по нему свой расчёт.
Перелік того, що спливає останнім, стійкий до нудьги. Перевірте за ним свій розрахунок.
The list of things that surface last is boringly consistent. Check your own estimate against it.
Базы вне виртуальной среды
Бази поза віртуальним середовищем
Databases outside the virtual environment
Промышленные СУБД на классических Unix-платформах и на программно-аппаратных комплексах. В консоли виртуализации их не видно — в первый расчёт они не попадают никогда. При этом именно ради них вся система копирования обычно и затевалась.
Промислові СУБД на класичних Unix-платформах і на програмно-апаратних комплексах. У консолі віртуалізації їх не видно — у перший розрахунок вони не потрапляють ніколи. При цьому саме заради них уся система копіювання зазвичай і затівалася.
Production databases on classic Unix platforms and on engineered appliances. They are invisible in the virtualisation console, so they never make it into the first estimate. And yet they are usually the whole reason the backup project started.
Копия на второй площадке
Копія на другому майданчику
The copy at the second site
Система стоит на копировании в основном центре и посчитана. Её копия на резервной площадке — потенциально отдельная позиция в лицензии. Правила различаются между производителями и даже между вариантами поставки одного, поэтому вопрос задаётся прямо, а ответ получается письменно.
Система стоїть на копіюванні в основному центрі і порахована. Її копія на резервному майданчику — потенційно окрема позиція в ліцензії. Правила різняться між виробниками і навіть між варіантами постачання одного, тому питання ставиться прямо, а відповідь отримується письмово.
A system is backed up at the primary site and duly counted. Its copy at the secondary site is potentially a separate licence line. The rules differ between vendors and even between delivery options from the same vendor, so the question is asked directly and the answer is obtained in writing.
Дополнительные модули
Додаткові модулі
Add-on modules
Изолированная среда восстановления, проверка копий на вредоносную активность, неизменяемое хранение — самостоятельные позиции со своими правилами комплектования. В базовую лицензию они не входят и задним числом на тех же условиях не докупаются.
Ізольоване середовище відновлення, перевірка копій на шкідливу активність, незмінне зберігання — самостійні позиції зі своїми правилами комплектування. У базову ліцензію вони не входять і заднім числом на тих самих умовах не докуповуються.
An isolated recovery environment, malware scanning of copies, immutable storage — each is a separate line item with its own packaging rules. They are not part of the base licence and cannot be added later on the same terms.
Вспомогательная инфраструктура
Допоміжна інфраструктура
Supporting infrastructure
Копирование облачной почты требует отдельных посредников — виртуальных машин, через которые идёт выгрузка. В смете на лицензии их нет. В проекте они есть, занимают ресурсы, и кто-то должен их посчитать.
Копіювання хмарної пошти вимагає окремих посередників — віртуальних машин, через які йде вивантаження. У кошторисі на ліцензії їх немає. У проєкті вони є, займають ресурси, і хтось має їх порахувати.
Backing up cloud mail requires dedicated proxies — virtual machines through which the extraction runs. They do not appear in the licence budget. They do appear in the project, they consume resources, and somebody has to size them.
Неизрасходованный запас лицензий
Невитрачений запас ліцензій
The unused licence balance
Самый частый источник неприятных открытий. На балансе лежат лицензии, купленные несколько лет назад и, как считается, израсходованные не полностью. Их закладывают в план как готовый ресурс. До сверки с фактическим перечнем систем это не ресурс, а предположение — и сверять его надо до расчёта, а не после подписания.
Найчастіше джерело неприємних відкриттів. На балансі лежать ліцензії, куплені кілька років тому і, як вважається, витрачені не повністю. Їх закладають у план як готовий ресурс. До звірки з фактичним переліком систем це не ресурс, а припущення — і звіряти його треба до розрахунку, а не після підписання.
The most common source of unpleasant discoveries. There are licences on the books, bought a few years ago and believed to be only partly consumed. They go into the plan as a ready resource. Until they are reconciled against the actual list of systems they are not a resource but an assumption — and the reconciliation belongs before the calculation, not after the signature.
Где источник учитывается, а где про него забываютДе джерело враховується, а де про нього забуваютьWhere a source gets counted and where it gets forgotten
Список того, что всплывает последним, устойчив до скуки. Проверьте по нему свой расчёт.Перелік того, що спливає останнім, стійкий до нудьги. Перевірте за ним свій розрахунок.The list of things that surface last is boringly consistent. Check your own estimate against it.
| Виден в консолиВидно в консоліVisible in the console | Попадает в первый расчётПотрапляє в перший розрахунокIn the first estimate | Нужна отдельная позицияПотрібна окрема позиціяNeeds its own line item | |
|---|---|---|---|
| Источники данныхДжерела данихData sources | |||
| Виртуальные машины фермыВіртуальні машини фермиVMs in the farm | |||
| Базы внутри виртуальных машинБази всередині віртуальних машинDatabases inside VMs | |||
| Базы на физических серверахБази на фізичних серверахDatabases on physical servers | |||
| Базы на программно-аппаратных комплексахБази на програмно-апаратних комплексахDatabases on engineered appliances | |||
| Файловые ресурсыФайлові ресурсиFile shares | |||
| Контуры разработки и тестированияКонтури розробки і тестуванняDev and test environments | |||
| Облачная почтаХмарна поштаCloud mail | |||
| То, что вспоминают последнимТе, що згадують останнімWhat is remembered last | |||
| Копия на второй площадкеКопія на другому майданчикуThe copy at the second site | |||
| Дополнительные модулиДодаткові модуліAdd-on modules | |||
| Вспомогательная инфраструктураДопоміжна інфраструктураSupporting infrastructure | |||
| Неизрасходованный запас лицензийНевитрачений запас ліцензійUnused licence balance | |||
Вспомогательная инфраструктура — виртуальные машины-посредники для выгрузки облачной почты — лицензией не является, но ресурсы занимает, и кто-то должен её посчитать.
Допоміжна інфраструктура — віртуальні машини-посередники для вивантаження хмарної пошти — ліцензією не є, але ресурси займає, і хтось має її порахувати.
Supporting infrastructure — the proxy VMs that pull cloud mail — is not a licence line, but it consumes resources, and somebody has to size it.
Отсюда вывод, который я повторяю на каждой встрече: инвентаризация источников — самостоятельный этап проекта, а не подготовка к нему. Вводные приходят из двух мест и расходятся: письменный перечень, собранный к закупке, и устная позиция инженеров, которые эксплуатируют это каждый день. Расхождение — норма.
Звідси висновок, який я повторюю на кожній зустрічі: інвентаризація джерел — самостійний етап проєкту, а не підготовка до нього. Вхідні дані приходять із двох місць і розходяться: письмовий перелік, зібраний до закупівлі, і усна позиція інженерів, які експлуатують це щодня. Розходження — норма.
Hence the conclusion I repeat at every meeting: inventorying the sources is a project stage in its own right, not the warm-up before one. The inputs come from two places and they disagree: the written list assembled for procurement, and the verbal position of the engineers who run the systems every day. Disagreement is the norm.
Работающий инструмент один — чек-лист сверки «что есть, чего нет»: категория источника, наличие, количество, объём, способ защиты, ответственный. Заполняется совместно, подписывается обеими сторонами, и только после этого начинается расчёт.
Робочий інструмент один — чек-лист звірки «що є, чого немає»: категорія джерела, наявність, кількість, обсяг, спосіб захисту, відповідальний. Заповнюється спільно, підписується обома сторонами, і тільки після цього починається розрахунок.
There is exactly one tool that works — a reconciliation checklist of “what exists and what does not”: source category, presence, count, volume, protection method, owner. Filled in jointly, signed by both parties, and only then does the calculation begin.
И ещё одно, из области календаря. Считайте не от даты готовности проекта, а от даты окончания действующей поддержки. Процедура закупки занимает месяцы: если лицензии истекают в декабре, а конкурс объявляется в сентябре, на сбор исходных данных остаётся август — и это уже поздно.
І ще одне, з царини календаря. Рахуйте не від дати готовності проєкту, а від дати закінчення чинної підтримки. Процедура закупівлі займає місяці: якщо ліцензії спливають у грудні, а конкурс оголошується у вересні, на збір вихідних даних лишається серпень — і це вже пізно.
And one more thing, from the calendar department. Count backwards not from the project’s readiness date but from the expiry of the current support. Procurement takes months: if licences expire in December and the tender is announced in September, that leaves August for gathering the input data — and that is already late.
04
Вторая подменаДруга підмінаThe second substitution
Приёмник — это не периметр
Приймач — це не периметр
The target is not the scope
Четыре независимые системы хранения — это не одна система суммарной ёмкости. И не величина, по которой лицензируется софт.
Чотири незалежні системи зберігання — це не одна система сумарної ємності. І не величина, за якою ліцензується софт.
Four independent storage systems are not one system of aggregate capacity. Nor are they the quantity the software is licensed by.
Здесь начинается вторая часть разговора и вторая подмена.
Тут починається друга частина розмови і друга підміна.
Here begins the second part of the conversation, and the second substitution.
Возьмём типовую целевую архитектуру: четыре независимые системы хранения по несколько петабайт, разнесённые по двум площадкам, две из них в режиме неизменяемого хранения. Состав при этом может быть почти любым в разумных пределах: две флеш-системы плюс две дисковые, две флеш плюс две ленточные библиотеки, готовые аплайнсы производителя под резервное копирование или собранный на своём железе Ceph с объектным доступом. Это вопрос денег и требований к скорости, а не догма.
Візьмемо типову цільову архітектуру: чотири незалежні системи зберігання по кілька петабайт, рознесені по двох майданчиках, дві з них у режимі незмінного зберігання. Склад при цьому може бути майже будь-яким у розумних межах: дві флеш-системи плюс дві дискові, дві флеш плюс дві стрічкові бібліотеки, готові аплайнси виробника під резервне копіювання або зібраний на своєму залізі Ceph з об’єктним доступом. Це питання грошей і вимог до швидкості, а не догма.
Take a typical target architecture: four independent storage systems of a few petabytes each, split across two sites, two of them in immutable mode. The composition can be almost anything within reason: two flash systems plus two disk-based ones, two flash plus two tape libraries, purpose-built backup appliances from a vendor, or Ceph with object access assembled on your own hardware. It is a question of money and speed requirements, not dogma.
Но первое, что нужно проговорить вслух: это четыре системы, а не одна суммарной ёмкости. Независимые системы не суммируются ни по отказоустойчивости — отказ одной не компенсируется тремя другими сам собой, — ни по лицензии программного обеспечения. А соблазн взять самое крупное число из проекта и умножить на ставку возникает буквально у всех.
Але перше, що треба проговорити вголос: це чотири системи, а не одна сумарної ємності. Незалежні системи не додаються ні за відмовостійкістю — відмова однієї не компенсується трьома іншими сама собою, — ні за ліцензією програмного забезпечення. А спокуса взяти найбільше число з проєкту і помножити на ставку виникає буквально в усіх.
But the first thing to say out loud is that these are four systems, not one of aggregate capacity. Independent systems do not add up in resilience — the failure of one is not automatically covered by the other three — nor in software licensing. And the temptation to take the largest number in the project and multiply it by the rate occurs to literally everyone.
Неизменяемое хранение регулярно путают с резервированием. Копия на второй площадке защищает от отказа оборудования и аварии на площадке. Неизменяемость — от скомпрометированной учётной записи администратора. Три копии в двух центрах не спасают, если у злоумышленника есть административный доступ к обоим.
Незмінне зберігання регулярно плутають із резервуванням. Копія на другому майданчику захищає від відмови обладнання і аварії на майданчику. Незмінність — від скомпрометованого облікового запису адміністратора. Три копії у двох центрах не рятують, якщо у зловмисника є адміністративний доступ до обох.
Immutable storage is regularly confused with redundancy. A copy at the second site protects against hardware failure and a site-level incident. Immutability protects against a compromised administrator account. Three copies across two data centres will not save you if the attacker has administrative access to both.
И ещё одно, о чём в спецификациях почти не пишут: приёмник — это обычно не одна система, а несколько ярусов с разными задачами.
І ще одне, про що в специфікаціях майже не пишуть: приймач — це зазвичай не одна система, а кілька ярусів із різними завданнями.
And one more thing that specifications almost never mention: the target is usually not one system but several tiers with different jobs.
На площадке стоит быстрая система хранения под мгновенное восстановление — глубина там маленькая, зато сервис поднимается за часы. Рядом ёмкая и медленная, где живёт основная глубина. Ленточная библиотека под архив — там же или на удалённой площадке. Четвёртым ярусом хорошо ложится объектное хранилище в арендованном облаке.
На майданчику стоїть швидка система зберігання під миттєве відновлення — глибина там маленька, зате сервіс піднімається за години. Поряд ємна і повільна, де живе основна глибина. Стрічкова бібліотека під архів — там само або на віддаленому майданчику. Четвертим ярусом добре лягає об’єктне сховище в орендованій хмарі.
On site there is a fast storage system for instant recovery — retention there is shallow, but the service comes back in hours. Next to it, something capacious and slow that holds the bulk of the retention. A tape library for the archive, on site or remote. And object storage in a rented cloud sits well as a fourth tier.
Последнее избавляет от необходимости строить на второй площадке полный комплект хранения. Вместо второго набора массивов там достаточно медиа-серверов — вычислительной части без данных. При катастрофе на первой площадке они забирают данные из облака и разворачивают сервисы у себя. Медленнее, чем с готовой репликой под боком, — зато вы не платите за второй комплект дисков, который годами ничего не делает.
Останнє позбавляє необхідності будувати на другому майданчику повний комплект зберігання. Замість другого набору масивів там достатньо медіа-серверів — обчислювальної частини без даних. При катастрофі на першому майданчику вони забирають дані з хмари і розгортають сервіси в себе. Повільніше, ніж із готовою реплікою під боком, — зате ви не платите за другий комплект дисків, який роками нічого не робить.
That last one removes the need to build a full storage set at the second site. Instead of a second array complement, media servers are enough there — compute without data. In a disaster at the primary site they pull the data from the cloud and stand the services up locally. Slower than having a ready replica next door — but you are not paying for a second set of disks that does nothing for years.
Ярусы хранения копий и роль медиа-серверовЯруси зберігання копій і роль медіа-серверівCopy storage tiers and the role of media servers
Приёмник — обычно не одна система, а несколько ярусов с разными задачами.Приймач — зазвичай не одна система, а кілька ярусів із різними завданнями.The target is usually not one system but several tiers with different jobs.
Быстрое хранилище на площадкеШвидке сховище на майданчикуFast on-site storage
- ЗадачаЗавданняJob
- мгновенное восстановлениемиттєве відновленняinstant recovery
- ГлубинаГлибинаRetention
- маленькаямалаshallow
- Сервис поднимаетсяСервіс піднімаєтьсяService back in
- за часыза годиниhours
Ёмкое и медленноеЄмне і повільнеCapacious and slow
- ЗадачаЗавданняJob
- держать основную глубинутримати основну глибинуhold the bulk of retention
- ГлубинаГлибинаRetention
- недели — месяцытижні — місяціweeks to months
- НеизменяемостьНезмінністьImmutability
- включается здесь, отдельной строкой лицензиивмикається тут, окремим рядком ліцензіїenabled here, as its own licence line
Ленточный архивСтрічковий архівTape archive
- ЗадачаЗавданняJob
- долгое хранение и физический разрывдовге зберігання і фізичний розривlong retention and a physical gap
- ГлубинаГлибинаRetention
- годырокиyears
- РазмещениеРозміщенняLocation
- там же или на удалённой площадкетам само або на віддаленому майданчикуon site or remote
Объектное в арендованном облакеОб’єктне в орендованій хмаріObject storage in rented cloud
- ЗадачаЗавданняJob
- заменить второй комплект массивовзамінити другий комплект масивівreplace the second set of arrays
- На второй площадкеНа другому майданчикуAt the second site
- только медиа-серверы — вычисление без данныхлише медіа-сервери — обчислення без данихmedia servers only — compute without data
- ЦенаЦінаPrice
- медленнее готовой реплики, зато без второго комплекта дисковповільніше за готову репліку, зате без другого комплекту дисківslower than a ready replica, but no second set of disks
Четыре независимые системы — это не одна система суммарной ёмкости. Они не суммируются ни по отказоустойчивости, ни по лицензии.
Чотири незалежні системи — це не одна система сумарної ємності. Вони не додаються ні за відмовостійкістю, ні за ліцензією.
Four independent systems are not one system of aggregate capacity. They add up neither in resilience nor in licensing.
Неизменяемость при этом — свойство отдельного яруса, а не всей конструкции. Её включают там, где она нужна, и это отдельная строка в лицензии.
Незмінність при цьому — властивість окремого ярусу, а не всієї конструкції. Її вмикають там, де вона потрібна, і це окремий рядок у ліцензії.
Immutability, meanwhile, is a property of a specific tier, not of the whole construction. It is switched on where it is needed, and it is a separate licence line.
И то, о чём вспоминают позже всего. Стратегия резервного копирования не существует отдельно от стратегии аварийного восстановления — это одна конструкция, и проектировать её половинами нельзя. Копии, которые прекрасно снимаются, но не разворачиваются в срок, защищают только отчётность.
І те, про що згадують найпізніше. Стратегія резервного копіювання не існує окремо від стратегії аварійного відновлення — це одна конструкція, і проєктувати її половинами не можна. Копії, які чудово знімаються, але не розгортаються вчасно, захищають лише звітність.
And the thing remembered last of all. A backup strategy does not exist separately from a disaster recovery strategy — it is one construction, and it cannot be designed in halves. Copies that are taken beautifully but cannot be restored on time protect nothing but the paperwork.
А есть и третья, которую формулируют совсем редко: стратегия восстановления. Не «как мы храним» и не «куда мы переезжаем», а «сколько бизнес готов простаивать и что мы успеваем поднять за это время». Именно она задаёт требования к ярусам: что должно лежать на быстром хранилище, что можно отпустить на ленту, а что уедет в облако.
А є і третя, яку формулюють зовсім рідко: стратегія відновлення. Не «як ми зберігаємо» і не «куди ми переїжджаємо», а «скільки бізнес готовий простоювати і що ми встигаємо підняти за цей час». Саме вона задає вимоги до ярусів: що має лежати на швидкому сховищі, що можна відпустити на стрічку, а що поїде в хмару.
And there is a third that is very rarely articulated: the recovery strategy. Not “how we store” and not “where we fail over to”, but “how long the business can afford to be down and what we can bring up in that time”. That is what sets the requirements for the tiers: what must sit on fast storage, what can be let go to tape, and what goes to the cloud.
Пример из практики, обезличенно. Проект, где всё построено на Ceph и PostgreSQL. Архитектор заказчика посчитал полное восстановление на второй площадке в экономном варианте — вышло двадцать три часа простоя и больше. Для бизнеса неприемлемо, и вопрос сразу перешёл из плоскости «сколько стоит хранить» в плоскость «сколько стоит не работать сутки». Хорошая новость в том, что посчитали это на этапе проектирования, а не после аварии.
Приклад із практики, знеособлено. Проєкт, де все побудовано на Ceph і PostgreSQL. Архітектор замовника порахував повне відновлення на другому майданчику в економному варіанті — вийшло двадцять три години простою і більше. Для бізнесу неприйнятно, і питання одразу перейшло з площини «скільки коштує зберігати» в площину «скільки коштує не працювати добу». Хороша новина в тому, що порахували це на етапі проєктування, а не після аварії.
A depersonalised example from practice. A project built entirely on Ceph and PostgreSQL. The customer’s architect calculated a full recovery at the second site in the economy option — it came out at twenty-three hours of downtime and more. Unacceptable for the business, and the question moved immediately from “what does storage cost” to “what does a day of not working cost”. The good news is that this was calculated at the design stage, not after an incident.
Отсюда неприятное следствие, о котором молчат обе стороны сделки. Лицензия покупает право защищать объём определённым набором функций — но не скорость копирования и не время восстановления. Оно определяется архитектурой: числом потоков, каналом, производительностью дискового пула, тем, откуда именно вы поднимаете данные. Ни одна из этих величин в лицензии не фигурирует. Можно купить полный периметр по максимальному уровню функциональности и получить время восстановления, не укладывающееся ни в один норматив.
Звідси неприємний наслідок, про який мовчать обидві сторони угоди. Ліцензія купує право захищати обсяг певним набором функцій — але не швидкість копіювання і не час відновлення. Він визначається архітектурою: кількістю потоків, каналом, продуктивністю дискового пулу, тим, звідки саме ви піднімаєте дані. Жодна з цих величин у ліцензії не фігурує. Можна купити повний периметр за максимальним рівнем функціональності й отримати час відновлення, що не вкладається в жоден норматив.
Which leads to an uncomfortable consequence that both sides of the deal stay quiet about. A licence buys the right to protect a volume with a certain set of functions — but not backup speed and not recovery time. Those are determined by architecture: the number of streams, the link, the performance of the disk pool, and where exactly you are restoring from. None of these quantities appears in the licence. You can buy the full scope at the top functionality tier and still end up with a recovery time that fits no service target at all.
И последнее. Тип приёмника влияет на метрику лицензирования. Переход с ленты на диск или объектное хранилище — это не только замена железа: вспомогательная копия на объект и режим блокировки объектов считаются по своим правилам. Расчёт, сделанный под предыдущую архитектуру, нельзя переносить в новую механически, даже если защищаемый объём не изменился ни на терабайт.
І останнє. Тип приймача впливає на метрику ліцензування. Перехід зі стрічки на диск або об’єктне сховище — це не лише заміна заліза: допоміжна копія на об’єкт і режим блокування об’єктів рахуються за своїми правилами. Розрахунок, зроблений під попередню архітектуру, не можна переносити в нову механічно, навіть якщо захищуваний обсяг не змінився ні на терабайт.
And finally. The type of target affects the licensing metric. Moving from tape to disk or object storage is not merely a hardware swap: a secondary copy to object storage and object-lock mode are counted under their own rules. A calculation made for the previous architecture cannot be carried mechanically into the new one, even if the protected volume has not changed by a single terabyte.
05
Третья подменаТретя підмінаThe third substitution
Физика шифротекста
Фізика шифротексту
The physics of ciphertext
Стойко зашифрованные данные не сжимаются. Не «сжимаются хуже» — не сжимаются вовсе.
Стійко зашифровані дані не стискаються. Не «стискаються гірше» — не стискаються зовсім.
Strongly encrypted data does not compress. Not “compresses worse” — does not compress at all.
Третья подмена — самая техническая и самая дорогая. Разбирается за абзац, а спорят о ней месяцами.
Третя підміна — найтехнічніша і найдорожча. Розбирається за абзац, а сперечаються про неї місяцями.
The third substitution is the most technical and the most expensive. It takes a paragraph to explain and months to argue about.
Стойко зашифрованные данные не сжимаются. Не «сжимаются хуже» — не сжимаются. Предел компрессии шифротекста единица с сотыми. Причина в природе шифрования: хороший алгоритм отдаёт последовательность, статистически неотличимую от случайной, а сжатие работает ровно на статистической избыточности. В шифротексте сжимать нечего.
Стійко зашифровані дані не стискаються. Не «стискаються гірше» — не стискаються. Межа компресії шифротексту одиниця з сотими. Причина в природі шифрування: хороший алгоритм віддає послідовність, статистично невідрізненну від випадкової, а стиснення працює рівно на статистичній надмірності. У шифротексті стискати нема чого.
Strongly encrypted data does not compress. Not “compresses worse” — does not compress. The compression ceiling for ciphertext is one point something. The reason lies in the nature of encryption: a good algorithm produces a sequence statistically indistinguishable from random, while compression works precisely on statistical redundancy. There is nothing in ciphertext to compress.
Это не моё наблюдение, это позиция производителей. В документации Commvault есть прямой пример: кассета номиналом 110 гигабайт, на которую при сжатии без шифрования ложилось около 190 гигабайт, при включённом шифровании принимает примерно 124. Коэффициент падает с 1,73 до 1,13 — тот же носитель, тот же привод, та же настройка сжатия.
Це не моє спостереження, це позиція виробників. У документації Commvault є прямий приклад: касета номіналом 110 гігабайт, на яку при стисненні без шифрування лягало близько 190 гігабайт, при увімкненому шифруванні приймає приблизно 124. Коефіцієнт падає з 1,73 до 1,13 — той самий носій, той самий привід, те саме налаштування стиснення.
This is not my observation, it is the vendors’ own position. The Commvault documentation contains a direct example: a cartridge with a nominal capacity of 110 gigabytes, which held about 190 gigabytes with compression and no encryption, takes roughly 124 once encryption is enabled. The ratio drops from 1.73 to 1.13 — same media, same drive, same compression setting.
Ёмкость носителя при сжатии с шифрованием и без негоЄмність носія при стисненні з шифруванням і без ньогоMedia capacity with compression, with and without encryption
Тот же носитель, тот же привод, та же настройка сжатия. Пример из документации Commvault.Той самий носій, той самий привід, те саме налаштування стиснення. Приклад із документації Commvault.Same media, same drive, same compression setting. Example from the Commvault documentation.
Там же сказано, что аппаратное сжатие на зашифрованных данных включать не рекомендуется — объём может не уменьшиться, а вырасти, а программное шифрование сводит аппаратное сжатие на нет.
Там само сказано, що апаратне стиснення на зашифрованих даних вмикати не рекомендується — обсяг може не зменшитися, а зрости, а програмне шифрування зводить апаратне стиснення нанівець.
The same source states that hardware compression is not recommended on encrypted data — the volume may grow rather than shrink — and that software encryption nullifies hardware compression.
Там же производитель делает второй вывод, ещё практичнее: аппаратное сжатие на зашифрованных данных включать не рекомендуется — объём может не уменьшиться, а вырасти. Это не парадокс: попытка сжать случайную последовательность добавляет служебные структуры алгоритма, не убирая ничего. Отдельной строкой сказано, что программное шифрование сводит аппаратное сжатие на нет.
Там само виробник робить другий висновок, ще практичніший: апаратне стиснення на зашифрованих даних вмикати не рекомендується — обсяг може не зменшитися, а зрости. Це не парадокс: спроба стиснути випадкову послідовність додає службові структури алгоритму, не прибираючи нічого. Окремим рядком сказано, що програмне шифрування зводить апаратне стиснення нанівець.
In the same place the vendor draws a second, even more practical conclusion: hardware compression is not recommended on encrypted data — the volume may grow rather than shrink. This is no paradox: trying to compress a random sequence adds the algorithm’s own overhead structures while removing nothing. A separate line states that software encryption nullifies hardware compression.
Не 1,7. Не 2. Не 5. Единице.
Не 1,7. Не 2. Не 5. Одиниці.
Not 1.7. Not 2. Not 5. One.
Отсюда правило для сайзинга, до неприличия простое. Если поток шифруется на стороне программного обеспечения резервного копирования, коэффициент сокращения при расчёте ёмкости закладывается равным единице.
Звідси правило для сайзингу, до непристойності просте. Якщо потік шифрується на боці програмного забезпечення резервного копіювання, коефіцієнт скорочення при розрахунку ємності закладається рівним одиниці.
Hence a sizing rule that is almost indecently simple. If the stream is encrypted on the backup software side, the reduction ratio used in the capacity calculation is set to one.
06
Разбор цифрыРозбір цифриUnpacking the number
Из чего собран заявленный коэффициент
З чого зібраний заявлений коефіцієнт
What the claimed ratio is made of
Коэффициент из презентации обычно измерен честно. Просто не на том потоке, который будет у вас.
Коефіцієнт із презентації зазвичай виміряний чесно. Просто не на тому потоці, який буде у вас.
The number in the slide deck is usually measured honestly. Just not on the stream you will have.
Тогда откуда в презентациях берутся 1,7, три и пять? Ответ неприятен своей обыденностью: эти цифры чаще всего не выдуманы. Они честно измерены — просто не на том, о чём вы подумали.
Тоді звідки в презентаціях беруться 1,7, три і п’ять? Відповідь неприємна своєю буденністю: ці цифри найчастіше не вигадані. Вони чесно виміряні — просто не на тому, про що ви подумали.
So where do the 1.7, the three and the five in the presentations come from? The answer is unpleasant in its ordinariness: those numbers are usually not invented. They were honestly measured — just not on what you assumed.
Заявленный коэффициент почти всегда суммарный. В него входит дедупликация — устранение повторяющихся блоков, на незашифрованных данных основной вклад. Отсечение нулевых блоков — пустые области выделенных, но не заполненных дисков. Тонкое выделение ёмкости. И сжатие незашифрованных частей потока: даже когда данные шифруются, служебная часть остаётся открытой — метаданные, заголовки заданий, каталоги, — она сжимается нормально.
Заявлений коефіцієнт майже завжди сумарний. До нього входить дедуплікація — усунення повторюваних блоків, на незашифрованих даних основний внесок. Відсікання нульових блоків — порожні області виділених, але не заповнених дисків. Тонке виділення ємності. І стиснення незашифрованих частин потоку: навіть коли дані шифруються, службова частина лишається відкритою — метадані, заголовки завдань, каталоги, — вона стискається нормально.
The claimed ratio is almost always an aggregate. It includes deduplication — eliminating repeated blocks, the main contributor on unencrypted data. Zero-block elimination — the empty regions of provisioned but unfilled disks. Thin provisioning. And compression of the unencrypted parts of the stream: even when the data is encrypted, the housekeeping part stays in the clear — metadata, job headers, catalogues — and that compresses perfectly well.
Сложите это на стенде с типовыми данными — полтора-два получите законно. Перенесите на поток, зашифрованный на стороне софта копирования, — получите единицу. Обе цифры настоящие, условия разные.
Складіть це на стенді з типовими даними — півтора-два отримаєте законно. Перенесіть на потік, зашифрований на боці софту копіювання, — отримаєте одиницю. Обидві цифри справжні, умови різні.
Add that up on a bench with typical data and one and a half to two is a perfectly legitimate result. Move it to a stream encrypted on the backup software side and you get one. Both figures are real; the conditions differ.
Из чего собран заявленный коэффициент сокращенияЗ чого зібраний заявлений коефіцієнт скороченняWhat the claimed reduction ratio is made of
Коэффициент из презентации обычно измерен честно. Просто не на том потоке, который будет у вас.Коефіцієнт із презентації зазвичай виміряний чесно. Просто не на тому потоці, який буде у вас.The number in the slide deck is usually measured honestly. Just not on the stream you will have.
| Открытый потокВідкритий потікCleartext stream | Шифрование с фиксированным ключомШифрування з фіксованим ключемEncryption, fixed key | Шифрование с ключом на сессиюШифрування з ключем на сесіюEncryption, per-session key | |
|---|---|---|---|
| Дедупликация повторяющихся блоковДедуплікація повторюваних блоківDeduplication of repeated blocks | |||
| Отсечение нулевых блоковВідсікання нульових блоківZero-block elimination | |||
| Тонкое выделение ёмкостиТонке виділення ємностіThin provisioning | |||
| Сжатие полезной части потокаСтиснення корисної частини потокуCompression of the payload | |||
| Сжатие служебной частиСтиснення службової частиниCompression of metadata and headers |
Обе цифры настоящие, условия разные. Правильная форма претензии — не «вы завышаете коэффициент», а «покажите методику измерения раздельно».
Обидві цифри справжні, умови різні. Правильна форма претензії — не «ви завищуєте коефіцієнт», а «покажіть методику вимірювання окремо».
Both figures are real; the conditions differ. The right form of challenge is not “you are inflating the ratio” but “show me the measurement methodology, broken out”.
Есть и второй механизм расхождения. Дедупликация зашифрованных данных возможна, но только при детерминированном шифровании: одинаковый блок при фиксированном ключе всегда даёт одинаковый шифротекст. Как только применяется ключ на сессию, идентичные блоки превращаются в разные последовательности, и дедупликация падает почти до единицы. Коэффициент зависит от настройки шифрования, о которой в презентации не сказано ни слова — и два заказчика с одинаковым железом получают разный результат.
Є і другий механізм розходження. Дедуплікація зашифрованих даних можлива, але лише за детермінованого шифрування: однаковий блок за фіксованого ключа завжди дає однаковий шифротекст. Щойно застосовується ключ на сесію, ідентичні блоки перетворюються на різні послідовності, і дедуплікація падає майже до одиниці. Коефіцієнт залежить від налаштування шифрування, про яке в презентації не сказано ні слова — і два замовники з однаковим залізом отримують різний результат.
There is a second mechanism of divergence too. Deduplication of encrypted data is possible, but only with deterministic encryption: with a fixed key, an identical block always yields identical ciphertext. As soon as a per-session key is used, identical blocks become different sequences and deduplication drops to almost one. The ratio depends on an encryption setting the presentation says nothing about — and two customers with identical hardware get different results.
И третий случай, с которым я столкнулся напрямую. Технологии реального сокращения хост-шифрованных данных существуют: массив получает ключ через отдельный сервер управления ключами, расшифровывает поток, дедуплицирует и перешифровывает своим. Показатели там высокие и не поддельные. Но такая функция может жить только в одной линейке, требовать стороннего компонента и быть снята с поддержки — а в той линейке, которую вам предлагают, аналога не быть вовсе. Цифра настоящая. Просто она про другой продукт.
І третій випадок, з яким я зіткнувся напряму. Технології реального скорочення хост-шифрованих даних існують: масив отримує ключ через окремий сервер керування ключами, розшифровує потік, дедуплікує і перешифровує своїм. Показники там високі й не підроблені. Але така функція може жити лише в одній лінійці, вимагати стороннього компонента і бути знята з підтримки — а в тій лінійці, яку вам пропонують, аналога не бути зовсім. Цифра справжня. Просто вона про інший продукт.
And a third case I ran into directly. Technologies that genuinely reduce host-encrypted data do exist: the array obtains the key through a separate key management server, decrypts the stream, deduplicates it and re-encrypts with its own key. The figures there are high and not faked. But such a function may live in only one product line, require a third-party component and have been withdrawn from support — while the line being offered to you has no equivalent at all. The number is real. It is simply about a different product.
Отсюда правильная форма претензии к поставщику. Не «вы завышаете коэффициент» — на это всегда найдётся законный ответ. А «покажите методику измерения раздельно: сколько даёт сжатие именно шифропотока и сколько остальные механизмы». Отвечают либо цифрами, либо молчанием, и оба ответа вам одинаково полезны.
Звідси правильна форма претензії до постачальника. Не «ви завищуєте коефіцієнт» — на це завжди знайдеться законна відповідь. А «покажіть методику вимірювання окремо: скільки дає стиснення саме шифропотоку і скільки решта механізмів». Відповідають або цифрами, або мовчанням, і обидві відповіді вам однаково корисні.
Hence the right form of challenge to a supplier. Not “you are inflating the ratio” — there will always be a legitimate answer to that. But “show me the measurement methodology broken out: how much comes from compressing the encrypted stream itself, and how much from the other mechanisms”. They respond either with numbers or with silence, and both answers are equally useful to you.
Заодно про ёмкость: в проектах копирования у неё три значения — физическая, разрешённая лицензией и полезная, что осталось после схемы избыточности. Модель, где массив приезжает укомплектованным полностью, а оплачивается меньшая доля, встречается всё чаще. Первый платёж ниже — зато вы привязаны к производителю на весь срок доращивания.
Заодно про ємність: у проєктах копіювання в неї три значення — фізична, дозволена ліцензією і корисна, що лишилася після схеми надмірності. Модель, де масив приїжджає укомплектованим повністю, а оплачується менша частка, трапляється дедалі частіше. Перший платіж нижчий — зате ви прив’язані до виробника на весь строк дорощування.
While we are at it, capacity: in backup projects it has three values — physical, licence-permitted, and usable, meaning what is left after the redundancy scheme. The model where the array arrives fully populated but only a fraction is paid for is becoming more common. The first payment is lower — but you are tied to the vendor for the whole growth period.
07
Чек-листЧек-листChecklist
Что спросить до того, как согласован бюджет
Що спитати до того, як узгоджений бюджет
What to ask before the budget is signed off
Двенадцать вопросов и две формулировки для технического задания.
Дванадцять питань і два формулювання для технічного завдання.
Twelve questions and two pieces of wording for the specification.
Двенадцать вопросов. Если на каждый есть ответ в письменном виде — расчёт можно защищать.
Дванадцять питань. Якщо на кожне є відповідь у письмовому вигляді — розрахунок можна захищати.
Twelve questions. If every one of them has a written answer, the calculation can be defended.
- По какой метрике считается лицензия: объём источников, число экземпляров, число пользователей?
- Разведены ли машины, лицензируемые как экземпляры, и машины с базами, которые считаются терабайтами?
- Есть ли перечень защищаемых систем, подписанный обеими сторонами?
- Учтены ли базы вне виртуальной среды — на физике и на программно-аппаратных комплексах?
- Как лицензируется копия на второй площадке и подтверждено ли это письменно?
- Какие модули входят в базовую поставку, а какие покупаются отдельными строками?
- Посчитана ли вспомогательная инфраструктура, которая лицензией не является?
- Сверен ли имеющийся запас лицензий с фактическим перечнем систем?
- Шифруется ли поток и какой коэффициент заложен в расчёт ёмкости?
- Из каких механизмов собран заявленный коэффициент и как он измерялся?
- Какая доля поставленной ёмкости разрешена лицензией и сколько стоит доращивание?
- Когда заканчивается действующая поддержка и хватает ли времени на процедуру закупки?
- За якою метрикою рахується ліцензія: обсяг джерел, кількість екземплярів, кількість користувачів?
- Чи розведені машини, що ліцензуються як екземпляри, і машини з базами, що рахуються терабайтами?
- Чи є перелік захищуваних систем, підписаний обома сторонами?
- Чи враховані бази поза віртуальним середовищем — на фізиці і на програмно-апаратних комплексах?
- Як ліцензується копія на другому майданчику і чи підтверджено це письмово?
- Які модулі входять у базову поставку, а які купуються окремими рядками?
- Чи порахована допоміжна інфраструктура, яка ліцензією не є?
- Чи звірений наявний запас ліцензій із фактичним переліком систем?
- Чи шифрується потік і який коефіцієнт закладений у розрахунок ємності?
- З яких механізмів зібраний заявлений коефіцієнт і як він вимірювався?
- Яка частка поставленої ємності дозволена ліцензією і скільки коштує дорощування?
- Коли закінчується чинна підтримка і чи вистачає часу на процедуру закупівлі?
- Which metric is the licence based on: source volume, instance count, user count?
- Are machines licensed as instances kept separate from database machines counted in terabytes?
- Is there a list of protected systems signed by both parties?
- Are databases outside the virtual environment accounted for — on physical servers and engineered appliances?
- How is the copy at the second site licensed, and is that confirmed in writing?
- Which modules are included in the base delivery and which are bought as separate line items?
- Has the supporting infrastructure — which is not a licence item — been sized?
- Has the existing licence balance been reconciled against the actual list of systems?
- Is the stream encrypted, and what ratio is built into the capacity calculation?
- Which mechanisms make up the claimed ratio, and how was it measured?
- What share of the delivered capacity is licence-enabled, and what does growing into the rest cost?
- When does the current support expire, and is there enough time for the procurement process?
Две формулировки для технического задания
Два формулювання для технічного завдання
Two pieces of wording for the specification
Про ёмкость: полезная ёмкость и скорость восстановления указываются физические, измеренные на данных, не поддающихся дедупликации и сжатию; заявленный коэффициент сокращения сопровождается описанием методики измерения и перечнем учитываемых механизмов.
Про ємність: корисна ємність і швидкість відновлення вказуються фізичні, виміряні на даних, що не піддаються дедуплікації та стисненню; заявлений коефіцієнт скорочення супроводжується описом методики вимірювання і переліком врахованих механізмів.
On capacity: usable capacity and restore throughput are stated as physical figures, measured on data that resists deduplication and compression; any claimed reduction ratio is accompanied by a description of the measurement methodology and a list of the mechanisms counted in it.
Про форму требования: фиксируйте логический объём, который система обязана отдать на выходе, и не диктуйте поставщику количество и тип дисков. Как он этого добьётся — его задача и его риск. И помните, что цифра коэффициента в договоре без методики измерения не значит ничего: спор упрётся в то, что стороны меряли разное.
Про форму вимоги: фіксуйте логічний обсяг, який система зобов’язана віддати на виході, і не диктуйте постачальнику кількість і тип дисків. Як він цього досягне — його задача і його ризик. І пам’ятайте, що цифра коефіцієнта в договорі без методики вимірювання не значить нічого: суперечка впреться в те, що сторони міряли різне.
On the form of the requirement: fix the logical volume the system must deliver at the output, and do not dictate the number and type of disks to the supplier. How they achieve it is their job and their risk. And remember that a ratio figure in a contract without a measurement methodology means nothing: the dispute will come down to the two sides having measured different things.
08
ИтогПідсумокWrap-up
Вместо вывода
Замість висновку
In place of a conclusion
Ни одна из трёх подмен не является обманом. Обе стороны называют настоящие цифры из настоящих документов — просто цифры относятся к разным величинам, а называются одинаково.
Жодна з трьох підмін не є обманом. Обидві сторони називають справжні цифри зі справжніх документів — просто цифри стосуються різних величин, а називаються однаково.
None of the three substitutions is deception. Both sides quote real numbers from real documents — the numbers simply refer to different quantities while going by the same name.
Средство одно, и оно скучное: на каждом числе в расчёте спрашивать, что именно оно измеряет и при каких условиях получено. Недели на подготовке — месяцы экономии на внедрении.
Засіб один, і він нудний: на кожному числі в розрахунку питати, що саме воно вимірює і за яких умов отримане. Тижні на підготовці — місяці економії на впровадженні.
There is one remedy, and it is boring: for every number in the calculation, ask what exactly it measures and under what conditions it was obtained. Weeks spent in preparation are months saved in deployment.