vStack заявляет, что HCP 3.2 переключает сетевые сервисы на резервный узел менее чем за 10 секунд. Активные TCP-соединения при этом сохраняются. Бухгалтер может не успеть повторно открыть клиент 1С, пока трафик уже уйдёт на другой сервер.
Но сохранённое TCP-соединение ещё не означает сохранённую транзакцию СУБД. Пресс-релиз vStack от 1 октября 2026 года не показывает, что произойдёт с сеансом 1С, фоновой операцией и внешней интеграцией.
Вердикт такой: HCP 3.2 стоит допустить к пилоту, если вы проектируете двухузловой кластер или общее NVMe-хранилище. Переносить рабочую 1С по одному анонсу рано. Сначала платформа должна пережить отказ узла во время записи в базу.
Что HCP 3.2 меняет в контуре 1С
В HCP 3.2 появилась внутрикластерная NVMe Fabric. Хранилище доступно с разных узлов, а виртуальную машину можно запустить или восстановить на подходящем сервере.
При выборе сервера платформа учитывает свободные вычислительные ресурсы и расположение данных. Если один сервер выходит из строя, его виртуальные машины можно распределить между оставшимися узлами. Эти возможности описаны в анонсе vStack и материалах CNews о релизе.
Для 1С здесь важна не сама NVMe Fabric. Важен путь от виртуальной машины с сервером приложений или СУБД до её данных после отказа узла.
| Функция HCP 3.2 | Возможная польза для контура 1С | Чего релиз не подтверждает |
|---|---|---|
| Доступ к хранилищу с разных узлов | ВМ можно запустить там, где доступны вычислительные ресурсы | Что задержка СУБД останется в допустимых пределах |
| Запуск или восстановление ВМ на подходящем сервере | Платформа не привязывает ВМ к одному физическому узлу | Что клиент 1С продолжит работу без повторного входа |
| Распределение ВМ после отказа сервера | Нагрузка отказавшего узла переходит на оставшиеся серверы | Что у них хватит процессоров, памяти и пропускной способности |
| NVMe-oF/TCP | Хранилище подключается через сеть по протоколу NVMe | Время проведения документов и массовых операций 1С |
| iSCSI с дополнительной защитой доступа | Можно подключить Unified Storage по привычному протоколу | Настройки защиты, совместимость инициаторов и влияние на задержку |
| Общее хранилище для HCP и внешних систем | Один ресурс могут использовать ВМ платформы и сторонняя система | Как конкурирующая нагрузка повлияет на СУБД |
| Сохранение TCP-сессий при переключении сети | Сетевое соединение может пережить переход на резервный узел | Состояние транзакции, блокировок и фоновых заданий 1С |
Вывод из таблицы: релиз описывает инфраструктурные механизмы, но не доказывает готовность рабочей базы к переносу.
NVMe в названии функции не отвечает на вопрос о скорости 1С. Между накопителем и проведением документа стоят сеть, протокол хранения, гипервизор, файловая система и СУБД. Поэтому сначала проверьте, какие свойства СХД имеют значение именно для проекта 1С.
В исследованных материалах нет замеров задержки СУБД, времени проведения документов или восстановления сеанса. Нет и конфигурации стенда, на которой vStack проверяла переключение менее чем за 10 секунд. Использовать эту цифру как обещание простоя для 1С нельзя.
Два узла снижают порог пилота, но не доказывают отказоустойчивость
HCP 3.2 поддерживает отказоустойчивые конфигурации из двух серверов. Для небольшой компании это меняет экономику пилота: не нужно сразу собирать кластер из трёх вычислительных узлов.
Два узла создают другой риск — split-brain. Так называют ситуацию, когда потерявшие связь серверы считают себя активными и одновременно меняют общие данные.
В анонсе vStack названы два механизма защиты: persistent reservations и witness. Первый ограничивает доступ узла к данным. Второй участвует в определении кворума, то есть права продолжать работу.
Этого описания мало для проекта. В материалах о релизе нет схемы размещения witness, требований к его каналу связи и поведения при его недоступности. Не описан и результат такого отказа для выбранной СУБД.
| Сценарий | Что заявлено для HCP 3.2 | Что проверить на пилоте |
|---|---|---|
| Отказ активного узла | Сетевые сервисы переходят на резервный узел менее чем за 10 секунд с сохранением TCP-соединений | Состояние сеанса 1С, результат транзакции и запуск ВМ |
| Потеря связи между двумя узлами | Узел должен подтвердить право работать с данными; используются persistent reservations и witness | Какой узел продолжает работу и исключена ли одновременная запись |
| Возврат отключённого узла | vStack сообщает об улучшенном поведении кластеров при возвращении сервера или площадки | Как синхронизируются данные и когда узел снова принимает нагрузку |
| Деградация накопителя | Платформа выявляет признаки деградации, выбирает резервный диск и следит за восстановлением | Не мешает ли перестроение хранилища работе СУБД |
| Отказ узла с несколькими ВМ | ВМ можно распределить между оставшимися серверами | Хватает ли оставшимся узлам ресурсов для сервера 1С и СУБД |
| Потеря связи с witness | Поведение в материалах о релизе не описано | Сохраняется ли кворум и блокируется ли запись на изолированном узле |
Вывод из таблицы: отказоустойчивость HCP нужно проверять не по состоянию ВМ, а по результату операции в базе.
У двухузловой схемы есть ещё одна граница. После отказа половина вычислительных ресурсов исчезает. Релиз не даёт исходных данных для расчёта запаса, поэтому назначать число пользователей или объём памяти по нему нельзя.
На пилоте используйте ту же раскладку ролей, что планируете в рабочем контуре. Если СУБД и сервер 1С будут жить на разных ВМ, не объединяйте их ради удобства испытания. Иначе проверка покажет поведение другой системы.
Проверяйте запись в базе, а не доступность пустой ВМ
Пилот должен воспроизвести рабочую операцию. Запуск пустой ВМ после отключения сервера подтверждает только работу гипервизора и хранилища.
Возьмите операцию, которая меняет данные и запускает связанные действия. Подойдёт проведение документа на тестовой копии базы с фоновым заданием и обменом с внешней системой.
Перед испытанием зафиксируйте состояние документа, время запуска задания и записи на стороне интеграции. Затем отключите активный узел во время записи в СУБД.
После переключения проверьте четыре результата:
- клиент 1С сохранил подключение либо вернул понятную ошибку;
- транзакция завершилась один раз или откатилась целиком;
- фоновое задание не пропало и не выполнилось повторно;
- внешняя система получила одну согласованную запись.
Цель проверки — не добиться отсутствия любой ошибки. При аварии клиент может потерять сеанс. Важнее, чтобы база не получила частично записанную операцию, а интеграция — дубль.
Повторите испытание после возврата узла. Этот этап нельзя заменять проверкой зелёного статуса в панели HCP. Нужно убедиться, что вернувшийся сервер синхронизировал данные и принимает ВМ без повторного конфликта.
Если в проект входят NVMe-oF/TCP и iSCSI, прогоните сценарий для каждого протокола. Разные пути доступа означают разные сетевые настройки, средства защиты и точки отказа.
Отдельный прогон нужен при совместном использовании Unified Storage. vStack заявляет, что одни ресурсы хранения могут обслуживать ВМ HCP и внешние системы. На пилоте создайте внешнюю нагрузку и повторите рабочую операцию 1С.
Порядок подготовки можно сверить с материалом о том, как отделять инфраструктурное обновление от рабочего контура 1С. Для сравнения полезен и пилот Inscale с проверкой прикладного сценария: там доступность платформы тоже не равна готовности самой 1С.
SMART снимает часть ручных проверок дисков
HCP 3.2 автоматически обнаруживает NVMe, SSD и HDD. По материалу IT-Text о релизе, платформа собирает SMART/health, выявляет признаки деградации, выбирает резервный диск и отслеживает восстановление данных.
Для администратора это сокращает число ручных проверок. Состояние накопителей и ход восстановления можно смотреть средствами платформы.
Но SMART не предупреждает о каждом будущем отказе. В релизе сказано только о признаках деградации. Там нет перечня контролируемых параметров, порогов тревоги и подтверждённого времени обнаружения неисправности.
Не отключайте наблюдение на уровне СУБД и операционной системы. У диска может не быть тревоги SMART, когда запросы уже ждут хранилище из-за сети, очереди или перестроения массива.
На пилоте искусственно создайте доступный и воспроизводимый сценарий деградации. Проверьте, где появляется событие, кто получает уведомление и как меняется состояние после установки резервного накопителя.
Журнал HCP дополняет журналы 1С и СУБД
В HCP 3.2 появился единый журнал безопасности. По анонсу vStack, он фиксирует 49 типов событий: входы, изменение настроек и действия с виртуальными машинами.
Записи связаны SHA-256-хеш-цепочкой. Журнал поддерживает фильтрацию, экспорт и уведомления о критических событиях. В платформе также есть шесть готовых ролей и более 50 прав, а администратор может создавать свои роли.
Эти функции помогают ответить на инфраструктурные вопросы: кто выключил ВМ, изменил сеть или поправил права. Они не показывают, какой документ провёл пользователь и почему СУБД откатила транзакцию.
Для расследования сбоя нужны три линии времени: события HCP, журнал СУБД и технологический журнал 1С. Синхронизируйте часы узлов до пилота. Иначе записи придётся сопоставлять вручную.
Когда HCP 3.2 стоит включить в проект
Если вам не нужен двухузловой кластер, NVMe Fabric или общее хранилище для разных систем, релиз не создаёт отдельной причины менять платформу. Более 200 изменений в версии — характеристика объёма выпуска, а не аргумент для миграции.
Если вы собираете компактный кластер из двух узлов, HCP 3.2 стоит добавить в короткий список. То же относится к проекту, где ВМ должны получать общее хранилище по NVMe-oF/TCP или iSCSI.
До начала пилота запросите у vStack документацию по совместимости, размещению witness и требованиям к сети. Пресс-релиз этих условий не раскрывает.
Рабочий контур допускайте к переносу, только когда выполнены пять проверок:
- Версии платформы 1С, СУБД и гостевой ОС поддерживаются их производителями на выбранной схеме виртуализации.
- Отказ активного узла проверен во время записи в СУБД, а не на пустой ВМ.
- При потере связи два узла не получают одновременный доступ на запись.
- Вернувшийся узел синхронизируется и принимает нагрузку без конфликта данных.
- Выбранный протокол хранения прошёл испытание под нагрузкой 1С и внешних систем.
Если один пункт не закрыт, оставьте HCP 3.2 в пилоте. Если закрыты все пять, решение уже опирается на вашу схему и вашу базу, а не на список функций релиза.
Архитектура пилота зависит от размещения СУБД, witness, сетей хранения и запаса второго узла. Если эти части ещё не сведены в одну схему, закажите проверку проекта виртуализации для конкретного контура 1С до миграции.