Шесть виртуальных машин из образа размером 60 ГБ займут 360 ГБ, если хранить каждую целиком. Связанные клоны при 12 ГБ изменений на машину потребуют 132 ГБ: 60 ГБ на эталон и ещё 6 × 12 ГБ на отличия.
Расчётная экономия — 228 ГБ, или 63%. Это не результат теста Basis Dynamix Enterprise и не обещание для любого контура. Цифра отвечает на практический вопрос: стоит ли обновлять платформу ради однотипных ВМ под сервер 1С, СУБД и тестовые базы.
В версии 4.7 тонкие диски и связанные клоны заработали на общих хранилищах Shared SEP. Об этом компания «Базис» сообщила в анонсе выпуска Basis Dynamix Enterprise 4.7. Замеров скорости клонов и готового сценария развёртывания 1С в анонсе нет, поэтому объём можно рассчитать заранее, а работу контура придётся проверить на пилоте.
Где связанные клоны сокращают расход хранилища
Связанный клон не хранит отдельную копию всего эталонного диска. Платформа записывает в него только изменения относительно базового образа. Если шесть машин получили одну ОС, одинаковые компоненты 1С и общий набор настроек, повторяющаяся часть остаётся в эталоне.
Тонкий диск решает соседнюю задачу. При его создании платформа не занимает весь заданный объём физического хранилища. Место выделяется по мере записи данных, а диск расширяется без остановки ВМ.
Для сравнения зафиксируем допущение: полный диск в расчёте — самостоятельная копия образа для каждой машины. Реальное потребление тонкого диска зависит от того, сколько данных записано внутрь.
| Способ хранения | Что лежит в хранилище | Как считать занятое место | Где искать экономию |
|---|---|---|---|
| Самостоятельные копии | Полный образ каждой ВМ | N × B | Экономии на повторяющихся данных нет |
| Тонкие диски | Только записанные блоки каждой ВМ | Сумма фактически записанных данных | Не резервируется незаписанная часть дисков |
| Связанные клоны | Один эталон и отличия каждого клона | B + N × D | Общие файлы хранятся один раз |
| Клоны с отдельными дисками данных | Эталон ОС, отличия клонов и самостоятельные диски баз | B + N × D + данные | Экономия относится к системным дискам, а не ко всей инфраструктуре |
Для группы однотипных ВМ главный выигрыш даёт общий эталон. Диски с базами 1С, журналами СУБД, временными файлами и резервными копиями считайте отдельно.
Это различие меняет оценку проекта. Если каждая тестовая машина получает собственную базу на сотни гигабайт, экономия на системном образе останется, но её доля в общем пуле снизится.
Как рассчитать место до обновления
Для расчёта нужны три значения:
N— число однотипных ВМ;B— размер эталонного образа;D— средний объём изменений одного клона.
Самостоятельные копии займут:
Vполные = N × B
Связанные клоны займут:
Vклоны = B + N × D
Возьмём сценарий из начала статьи: шесть ВМ, эталон 60 ГБ, изменения одного клона — 12 ГБ. Самостоятельные копии потребуют 6 × 60 = 360 ГБ. Клоны займут 60 + 6 × 12 = 132 ГБ.
Экономия составит:
360 − 132 = 228 ГБ
Доля экономии:
228 ÷ 360 × 100% = 63%
Число 12 ГБ — допущение, а не характеристика Basis Dynamix Enterprise. После пилота его нужно заменить фактическим приростом клона.
| Изменения одного клона, D | Шесть самостоятельных копий | Эталон и шесть клонов | Расчётная экономия |
|---|---|---|---|
| 6 ГБ | 360 ГБ | 60 + 6 × 6 = 96 ГБ | 264 ГБ |
| 12 ГБ | 360 ГБ | 60 + 6 × 12 = 132 ГБ | 228 ГБ |
| 30 ГБ | 360 ГБ | 60 + 6 × 30 = 240 ГБ | 120 ГБ |
| 60 ГБ | 360 ГБ | 60 + 6 × 60 = 420 ГБ | Клоны занимают на 60 ГБ больше |
Клоны выгодны, пока изменения не приближаются к размеру эталона. Чем чаще ВМ расходятся по составу программ и данным, тем слабее эффект.
Точную границу даёт неравенство:
B + N × D < N × B
Перенесём известные значения:
D < (N × B − B) ÷ N
Для шести ВМ и образа 60 ГБ:
D < (6 × 60 − 60) ÷ 6
D < 50 ГБ
При среднем приросте меньше 50 ГБ связанные клоны занимают меньше места. При 50 ГБ оба варианта требуют по 360 ГБ. Выше этой границы выбранная расчётная модель уже не даёт экономии.
Граница меняется вместе с числом машин. Для двух ВМ клон должен оставаться меньше половины эталона. При десяти ВМ допустимый прирост приближается к 90% размера эталона, поскольку базовый образ распределяется между большим числом клонов.
Эта формула сравнивает только место под одинаковые системные диски. Она не учитывает резервные копии, снимки, диски баз и служебный запас хранилища.
Порог 75% требует реакции, 90% блокирует рост
Тонкие диски не отменяют физический предел пула. Они лишь откладывают выделение места до момента записи.
По анонсу компании «Базис», при заполнении пула более чем на 75% платформа предупреждает администратора. На уровне 90% и выше она блокирует создание новых дисков и увеличение существующих.
| Заполнение пула | Что делает платформа | Что проверить администратору |
|---|---|---|
| До 75% | Диски продолжают расти по мере записи | Темп роста клонов, снимков и дисков данных |
| 75–89% | Платформа выдаёт предупреждение | Какие ВМ растут, сколько места дадут ближайшие обновления, можно ли расширить пул |
| От 90% | Создание и увеличение дисков блокируется | Какие операции уже остановлены и где добавить ёмкость |
| После расширения | Тонкие диски снова получают место по мере записи | Вернулся ли запас ниже рабочего порога |
Порог 75% взят из анонса платформы. Это не рекомендуемый запас для базы 1С и не основание заполнять пул до предупреждения.
К расчёту клонов добавьте запас на ожидаемый рост. Например, пул на 1 ТБ пересекает порог предупреждения после 750 ГБ занятых данных: 1000 × 0,75 = 750 ГБ. Блокировка начнётся на уровне 900 ГБ: 1000 × 0,9 = 900 ГБ.
Здесь 1 ТБ — условный размер пула для примера. Подставьте фактическую полезную ёмкость своего хранилища, а не паспортный объём накопителей.
Следить нужно не только за текущим заполнением. Важен прирост за неделю после обновления ОС, платформы 1С и тестовой загрузки базы. Один снимок перед изменениями тоже увеличит расход пула, поэтому замер без обычных административных операций даст заниженный прогноз.
Шаблон ВМ нужно подготовить до создания клонов
Связанный клон сокращает повторное хранение данных, но не собирает сервер 1С сам. Сначала администратор готовит эталонную ВМ, устанавливает нужные компоненты и загружает образ в платформу.
База знаний РОСА о подготовке шаблона для Basis Dynamix Enterprise требует установить в образ cloud-init. В пакет входят настройки BASIS-утилит и QEMU Guest Agent. Идентификатор загруженного образа берут в разделе «Образы» интерфейса BASIS.
Если эталон строится на Linux, продолжите работу по порядку установки компонентов 1С и СУБД в Linux. Образ стоит готовить до тиражирования: исправление шести уже разошедшихся машин съест часть времени, которое должны были сберечь шаблоны.
Разделяйте базовый образ и переменные данные. В эталон подходят ОС, агент гостевой системы, платформа 1С и общий набор системных пакетов. Рабочую базу, журналы СУБД и резервные копии лучше держать на самостоятельных дисках.
Так проще оценить рост клона. Обновление ОС или платформы меняет системный диск, а загрузка новой базы не маскирует этот прирост десятками гигабайт данных.
Добавление узла не равно развёртыванию 1С
В Basis Dynamix Enterprise 4.7 новый вычислительный узел подключается одним действием через API или форму портала. По анонсу компании «Базис», платформа сама проводит регистрацию и установку узла. Маршрут консольного доступа к ВМ обновляется после добавления оборудования.
Эта автоматизация заканчивается на инфраструктурном уровне. В материалах релиза нет подтверждения, что система сама установит сервер 1С, настроит СУБД, активирует лицензии и перенесёт рабочие базы.
Поэтому обновление не стоит обосновывать одной кнопкой создания ВМ. Оно сокращает ручные операции с узлами и расход хранилища, если команда уже умеет готовить повторяемые образы.
Миграцию между разными процессорами проверяют на пилоте
Версия 4.7 получила профили выравнивания процессоров для группы вычислительных узлов. Профиль выбирают при создании ВМ.
Профиль balanced рассчитан на работу с процессорами разных поколений внутри одной зоны. Профиль compatible использует минимальный общий набор инструкций CPU и сохраняет возможность миграции между всеми узлами зоны.
Из анонса нельзя вывести скорость 1С после такого выравнивания. Нельзя и обещать беспроблемный перенос между любыми моделями процессоров. Пилот должен повторять состав будущей зоны хотя бы на двух узлах.
Перед переносом рабочих ролей проверьте четыре операции:
- Создайте ВМ из эталона на первом узле.
- Запустите сервер 1С или тестовую СУБД под типовой нагрузкой.
- Перенесите ВМ на второй узел с выбранным профилем CPU.
- Проверьте службы, журнал событий и доступ пользователей после миграции.
Сам факт успешной миграции ещё не отвечает на вопрос о потерях производительности. Для решения между физическим размещением и гипервизором пригодится отдельное сравнение сервера 1С и виртуальной машины.
Пилот покажет реальный прирост клонов
Начните с одного эталона и двух клонов. На первом разместите тестовый сервер 1С, на втором — тестовый сервер СУБД. Рабочую базу пока не переносите.
До обновлений запишите размер эталона и каждого клона. Затем обновите ОС, платформу 1С и пакеты внутри обеих ВМ. После этого загрузите копию тестовой базы на отдельный диск и снова снимите показатели.
| Этап пилота | Что записать | Какой вывод получится |
|---|---|---|
| Эталон загружен | Размер базового образа B | Постоянная часть формулы |
| Два клона созданы | Начальный размер отличий | Накладные данные после создания |
| ОС и 1С обновлены | Прирост каждого клона | Расход места при обслуживании |
| Тестовая база загружена | Рост отдельного диска данных | Потребность базы вне системного образа |
| ВМ перенесены между узлами | Результат запуска служб и доступа | Совместимость выбранного профиля CPU |
| Пул получил снимки | Общий расход после снимков | Запас для обычных операций администратора |
Пилот нужен не для получения красивого процента. Он заменяет допущение D фактическим приростом вашей ВМ.
Если два клона выросли по-разному, не берите меньший результат. Для планирования используйте больший либо средний с отдельным запасом на обновления. Размер запаса выбирайте по наблюдаемому росту, поскольку материалы релиза не задают его за администратора.
Когда обновление ради клонов оправдано
Переход на Basis Dynamix Enterprise 4.7 ради хранения имеет смысл при трёх условиях: вы используете Shared SEP, регулярно создаёте однотипные ВМ и выполняется неравенство B + N × D < N × B.
Для шести машин по 60 ГБ граница проходит на 50 ГБ изменений на клон. При расчётных 12 ГБ обновление сокращает занятое место с 360 до 132 ГБ. При 60 ГБ изменений клоны требуют уже 420 ГБ.
Возьмите размер своего эталона, число будущих машин и ожидаемый прирост клона. Подставьте значения в формулу. Затем замените ожидание результатом пилота и добавьте диски баз, снимки и резервные копии.
После этого проверьте итог против ёмкости Shared SEP. Если расчёт пересекает 75%, сначала расширьте пул или сократите объём данных. Экономия на системных образах не исправит хранилище, которому не хватает места для рабочих баз.