Администратор выдаёт новому сотруднику виртуальный стол с 1С. Для этого он связывает пользователя, пул машин, профиль подключения и политики безопасности. При переводе сотрудника часть назначений приходится менять отдельно.
В Inscale 3.0.0 эти сущности объединяют группы доставки. Версию стоит брать в пилот, если ручные назначения, несколько кластеров или обрывы связи уже отнимают время. Переносить обновление в рабочий контур пока рано: официальных примечаний к выпуску и матрицы совместимости с версиями 1С среди опубликованных материалов нет.
Что известно о выпуске Inscale 3.0.0
О выпуске сообщило издание CISOCLUB со ссылкой на разработчика — «Лабораторию Виртуализации». Главные изменения касаются групп доставки, управления несколькими кластерами и пользовательских сессий на нестабильных каналах.
Официальная документация Inscale подтверждает базовую архитектуру платформы. Она работает на KVM/QEMU, поддерживает постоянные и непостоянные пулы, публикацию приложений, живую миграцию и автоматический перезапуск виртуальных машин после отказа узла.
Но документация не содержит описания выпуска 3.0.0. Поэтому новые функции стоит воспринимать как основание для пилота, а не как подтверждение готовности к рабочей нагрузке 1С.
Группы доставки связывают пользователя, стол и политики
Группа доставки объединяет пользователей, рабочие столы, пулы, профили подключения и политики безопасности. Когда администратор назначает сотруднику стол или пул, Inscale применяет связанные настройки.
Это меняет саму единицу управления. Администратор работает не с пятью разрозненными назначениями, а с одним объектом, который описывает рабочее место.
CISOCLUB также сообщает о поиске пользователей в Active Directory и LDAP по дополнительным атрибутам. Среди примеров названы табельный номер и адрес электронной почты.
Права можно подготовить до появления учётной записи в каталоге. После синхронизации Inscale применит назначения автоматически. Такой порядок подходит для массового приёма сотрудников, если кадровая система заранее передаёт нужные атрибуты.
| Операция | Как её приходится организовывать без группы | Что заявлено в Inscale 3.0.0 | Что проверить в пилоте |
|---|---|---|---|
| Приём сотрудника | Создать учётную запись, найти пользователя, назначить пул, профиль и политики | Права можно подготовить до синхронизации каталога | Получит ли новый пользователь нужный стол после первой синхронизации |
| Перевод в другое подразделение | Отдельно сменить пул, профиль подключения и ограничения | Назначения собраны в группе доставки | Снимутся ли старые политики и применятся ли новые |
| Временная блокировка | Удалить назначение или отключить учётную запись в каталоге | Локальную учётную запись можно заблокировать без удаления | Закроет ли блокировка новые подключения и что произойдёт с активной сессией |
| Возврат машины в floating-пул | Проверить завершение сессии и доступность машины для следующего пользователя | Машина возвращается в непостоянный пул после отключения | Очистятся ли пользовательские данные, токены и подключённые устройства |
Группы доставки сокращают число ручных назначений. Но наследование политик надо проверить на своей структуре Active Directory или LDAP, особенно при вложенных группах и нескольких подразделениях.
Отдельный риск — конфликт настроек. Политика может действовать на уровне машины, пула или группы доставки. В доступном описании выпуска нет правил приоритета для таких пересечений.
Поэтому в пилоте нужен не только новый пользователь. Проверьте сотрудника с действующими назначениями, перевод между группами и временную блокировку. Соседний сценарий подробно разобран в материале о централизованной выдаче приложений и устройств в Basis Workplace.
Единая панель собирает состояние нескольких кластеров
После выдачи доступа возникает следующая задача: найти причину жалобы. Пользователь видит неподключившийся стол, зависший экран или повторный вход. Администратору надо определить, где произошёл сбой: в клиенте, шлюзе, узле VDI, сервере 1С или СУБД.
По данным CISOCLUB, Inscale 3.0.0 выводит состояние всех кластеров на одну панель. Из консоли можно перезапустить сервис, получить журналы и собрать диагностический пакет для технической поддержки.
Групповая операция меняет уровень журналирования сразу на всех узлах кластера. Это пригодится при плавающем сбое, который не удаётся привязать к одной машине.
| Что видит пользователь | Что доступно администратору | Где заканчиваются данные Inscale |
|---|---|---|
| Сессия не подключается | Проверка состояния кластера, получение журналов, диагностический пакет | Консоль не подтверждает исправность тонкого клиента и учётной записи |
| Клиент сообщает о недоступном шлюзе | Состояние шлюзов и профиль подключения | Причину вне платформы придётся искать в DNS, маршруте и сетевых фильтрах |
| Сервис на узле не отвечает | Состояние узла, журналы и удалённый перезапуск сервиса | Перезапуск не объясняет исходную причину остановки |
| Статус ВМ не обновился после выключения | Проверка актуального состояния машины в консоли | Доступность ВМ не подтверждает работу службы 1С внутри неё |
| Пользователь вошёл, но документы проводятся медленно | Состояние сессии и узлов VDI | Задержка может находиться в кластере 1С, запросе или СУБД |
Единая панель сокращает путь до журналов платформы. Она не доказывает, что задержку создаёт VDI: после успешного подключения диагностика должна перейти к серверу 1С и базе данных.
Пилот стоит построить вокруг нескольких заранее заданных сбоев. Остановите сервис на тестовом узле, сделайте недоступным тестовый шлюз и принудительно выключите одну ВМ. После каждого события проверьте, что консоль показывает нужный кластер и собирает журналы с правильных узлов.
Если виртуальный стол открывается, но операция в 1С тормозит, нужен другой маршрут диагностики. Для него пригодится переход от сеанса 1С к SQL-статистике в PPEM 2.9.
Улучшения соединения надо проверять на реальном канале
В клиенте Inscale 3.0.0 появились индикаторы потери сети и повторного подключения. CISOCLUB также сообщает об улучшенном сжатии и обработке недоступных шлюзов в профилях.
Для филиала это полезнее абстрактного заявления о скорости. Пользователь должен видеть, что сессия не зависла, а ждёт сеть. После восстановления канала клиенту нужно вернуться в прежнюю сессию без повторного запуска 1С.
Официальная страница Inscale называет несколько ориентиров по пропускной способности:
- от 50 кбит/с на одно рабочее место как технический минимум;
- 100–110 кбит/с для офисной работы в HD;
- около 1,5 Мбит/с для мобильного профиля при активном изменении изображения;
- до 10 Мбит/с для изображения 4K.
Эти числа нельзя переносить в проект как требования к каналу. На странице нет методики испытаний: состава экрана, частоты кадров, задержки, потерь пакетов и действий пользователя. Работа с формой 1С и просмотр отчёта создают разный поток.
У платформы есть 27 параметров профиля подключения. Среди них — разрешение, частота кадров, количество цветов, плотность пикселей и сжатие изображения. Каждый параметр меняет и качество картинки, и расход канала.
Вместо расчёта по рекламному минимуму воспроизведите рабочий день филиала. Откройте форму 1С, проведите документ, сформируйте отчёт, скопируйте текст через буфер и подключите разрешённое USB-устройство. Затем повторите сценарий с задержкой и потерями, характерными для филиала.
| Проверка | Действие в пилоте | Признак прохождения | Что записать |
|---|---|---|---|
| Потеря канала | Прервать связь во время работы в 1С | Клиент показывает состояние соединения, процесс 1С не запускается заново | Время до индикации и возврата в сессию |
| Недоступный шлюз | Отключить один тестовый шлюз | Клиент следует настройкам профиля и не уходит в бесконечное ожидание | Поведение клиента и записи в журнале |
| Ограниченная полоса | Запустить рабочий сценарий на канале филиала | Формы и ввод данных остаются управляемыми | Параметры профиля, задержка и потери |
| Буфер обмена | Скопировать разрешённый текст между устройством и ВМ | Политика пропускает только заданное направление | Применённая политика и результат |
| USB-периферия | Подключить используемое в филиале устройство | Устройство доступно в сессии согласно политике | Модель, драйвер, способ перенаправления |
Пилот проходит не тогда, когда клиент один раз открылся. Он проходит после обрыва, возврата в ту же сессию и повторения рабочей операции без повреждения пользовательского контекста.
Совместимость с 1С нельзя вывести из функций VDI
Официальная страница Inscale описывает два способа запуска 1С: терминальный сервер и отдельные виртуальные рабочие столы. В VDI тонкий клиент устанавливают в исходную машину, затем из неё создают новую золотую реплику.
Фирма «1С» рекомендует уточнять требуемую версию платформы перед скачиванием тонкого клиента. Это особенно важно при обновлении шаблона: новый образ может разойтись по всему пулу, а ошибка затронет сразу несколько рабочих мест.
В опубликованных материалах Inscale нет матрицы совместимости версии 3.0.0 с выпусками платформы 1С. Нет и перечня проверенной периферии для конкретного контура: сканеров, токенов, кассового оборудования, принтеров этикеток и устройств подписи.
Поддержка USB, звука, камеры, микрофона, буфера обмена и передачи файлов заявлена на уровне политик. Наличие переключателя ещё не подтверждает работу нужной модели устройства и её драйвера внутри виртуальной машины.
Версию клиента Inscale тоже надо включить в проверку. Официальная страница перечисляет Windows, macOS и несколько дистрибутивов Linux, но рабочий результат зависит от конкретной ОС устройства, графической подсистемы и периферии.
Когда Inscale 3.0.0 стоит брать в пилот
Пилот оправдан, если выпуск закрывает уже существующую ручную операцию. Сам номер версии не создаёт причины для проекта.
| Ситуация в вашем контуре | Решение | Почему |
|---|---|---|
| Сотрудникам вручную назначают стол, профиль и несколько политик | Брать 3.0.0 в пилот | Группы доставки нацелены именно на этот набор операций |
| Администраторы переключаются между консолями нескольких кластеров | Брать 3.0.0 в пилот | Единая панель должна собрать состояние и журналы в одном месте |
| Филиалы теряют сессии при обрывах связи | Брать 3.0.0 в пилот | В выпуске заявлены индикация переподключения, сжатие и обработка шлюзов |
| Нужна только виртуализация серверов 1С | Не связывать миграцию с этим выпуском | Главные изменения версии относятся к VDI и эксплуатации кластеров |
| Текущая версия работает, а ручных операций нет | Отложить пилот до появления официальных примечаний | Польза обновления не покрывает риск изменений рабочего контура |
| Нужна подтверждённая совместимость с конкретной периферией | Сначала запросить документы и провести стендовые проверки | Общего описания политик недостаточно для решения |
Граница простая: пилот нужен при совпадении функции выпуска с вашей текущей болью. Если такого совпадения нет, обновление добавит работу, но не даст проверяемого результата.
Для одной лишь виртуализации серверов 1С оснований ещё меньше. Inscale поддерживает KVM/QEMU, живую миграцию и автоматический перезапуск ВМ, но эти возможности существовали независимо от групп доставки. Опубликованных результатов для вашей конфигурации 1С и СУБД нет.
Как провести пилот Inscale 3.0.0
Выделите отдельный контур. Не обновляйте рабочий кластер ради проверки функций, которые пока описаны сторонним изданием.
Подход совпадает с испытанием других инфраструктурных обновлений: сначала воспроизводят связи и политики, затем проверяют отказные сценарии. Похожий порядок описан в материале о пилоте изменений доменной инфраструктуры для 1С.
Пилоту нужен один сквозной маршрут:
- Создайте тестовую учётную запись в AD или LDAP.
- Добавьте её в группу доставки.
- Назначьте dedicated- или floating-пул.
- Проверьте применение профиля подключения и политик.
- Запустите тонкий клиент нужной версии 1С.
- Проверьте USB, буфер обмена и передачу файлов по правилам компании.
- Оборвите связь и дождитесь возврата в ту же сессию.
- Вызовите тестовый сбой сервиса и соберите журналы из единой панели.
- Завершите сеанс и проверьте возврат машины в floating-пул.
Для проверки обновления образа создайте новую золотую реплику с требуемой версией тонкого клиента. Назначьте её только тестовой группе. Старый образ сохраните до завершения проверки и отката.
Отдельно зафиксируйте границы диагностики. Inscale должен показать состояние VDI, шлюзов и своих сервисов. Скорость проведения документов и запросов к СУБД проверяйте инструментами контура 1С.
Правило допуска в рабочий контур
Берите Inscale 3.0.0 в пилот, если у вас есть хотя бы одна из трёх проблем: ручная выдача политик, раздельное управление кластерами или потеря пользовательских сессий при обрывах.
Считайте пилот пройденным только после всей цепочки: учётная запись → группа доставки → виртуальный стол → тонкий клиент 1С → периферия → обрыв и восстановление связи → журналы.
Новость о выпуске подтверждает направление разработки, но не совместимость вашего контура. До рабочего обновления запросите у разработчика примечания к версии 3.0.0, правила приоритета политик и перечень известных ограничений. Если архитектура зависит от версии 1С, устройств и филиальных каналов, закажите проверку схемы удалённого доступа для вашего контура.