Просмотреть исходный

Описание

Миграция создаёт в AuP 2.10 устройства и аккаунты, присутствующие в AuP 1.4, пересоздает все связки и пишет дополнительную информацию (additional_info).
Далее вся информация сортируется по additional_info и группируется в несколько цепочек внутри одного потока.
Каждый пайплайн содержит комплексные узлы BLF и SIP, а также два дополнительных узла с общими и специфическими параметрами.

Если устройства прописались в 2.10 по иному пути, например, через LLDP без интеграции, то они не войдут в поток. Мигратор посчитает, что устройство или аккаунт были добавлены в 2.10 ранее, и они уже имеют конфигурации, добавленные администратором. А раз так, то миграция устаревших настроек из 1.4 не требуется.
Поэтому в новый поток уходят только вновь загруженные объекты и параметры. Впрочем, администратор сможет включить их в поток вручную позднее.
Если миграция была аварийно прервана, то устройства и аккаунты, которые уже были добавлены, так и останутся в системе, но не будут включены в поток. Поток строится на BLF, поэтому добавленные устройства можно будет включить позднее.
Миграцию ни в коем случае нельзя прерывать. Если кажется, что она работает слишком долго — пусть продолжает работать.
Единожды прерванная миграция уже не построит полноценного потока и администратору придётся собирать его из отдельных импортированных устройств и аккаунтов.
Миграция должна быть первичной операцией при настройке AuP 2.10 рядом с AuP 1.4. Если на AuP 2.10 были аккаунты/устройства, то при миграции они не обновятся, так как миграция не распространяется на ранее созданные устройства и аккаунты.

Логика работы интеграции:

AuP 2.10 получает устройства, если полученные устройства не зарегистрированы, они записываются в БД;
AuP 2.10 получает аккаунты, если полученные аккаунты не зарегистрированы (а также имеют тип local, то есть созданы вручную, а не импортированы из SSW), они записываются в БД;
Создаются линки в БД между вновь созданными устройствами и вновь созданными аккаунтами. Ранее созданные устройства и аккаунты не затрагиваются, предполагая, что они уже могут иметь некие ручные настройки внутри AuP 2.10;
AuP 2.10 получает дополнительные данные для аккаунтов и устройств и записывает их в БД;
Создаются потоки для NodeRed.

Поток формируется с использованием простой эвристики, может быть от одной до трёх:

Первая — 2/3 всех устройств;
Вторая — более 1/3, при условии, что множество MAC с обособленными свойствами не входят в первую группу;
Третья — все MAC, не сопоставленные с известными свойствами;

Все цепочки содержат четыре узла конфигуратора [BLF complex node], [SIP complex node], [Common] и [SIP static params]:

Узел [BLF complex node] — автоматически распределяет известные параметры между программируемыми клавишами;
Узел [SIP complex node] — автоматически настраивает SIP-аккаунты на основании привязанных к устройству аккаунтов и их дополнительных параметров;
Узел [Common] — содержит общие настройки, такие как часовой пояс, настройки адресной книги базовых протоколов, вроде NTP;
Узел [SIP static params] — содержит настройки SIP-аккаунта, но по-умолчанию деактивирован, может быть включен, если по какой-либо причине комплексный узел не приемлем.

На рисунке ниже показан вариант, где первая цепочка включает в себя большинство из известных устройств, которые также имеют второстепенные общие Common параметры.

Вторая цепочка содержит только базовые параметры, достаточные для настройки SIP complex node, но второстепенные общие Common параметры или отсутствуют, или присутствуют у менее чем трети доступных устройств, а потому проигнорированы.

Третья цепочка имеет деактивированный узел Common, не содержащий параметров. При этом узел выбора устройств содержит идентификаторы всех устройств, которые имели уникальные свойства и не были включены ни в первую, ни во вторую цепочку.

Eltex Documentation > Миграция 1.4 - 2.10 > clipboard-202410100953-nqxbp.png

Процедура миграции 1.4 → 2.10

Заходим внутрь контейнера:

docker exec -it autoprovision-stable-core-1 bash

Запускаем оболочку Elixir:

./ecss_aup_core remote

Рекомендуется запускать миграцию данных в синхронном режиме, для отслеживания прогресса и возникающих проблем. Однако, при таком запуске консоль будет заблокирована до окончания выполнения и ее придется держать открытой. Асинхронный же запрос создаст фоновую задачу.

Команда для синхронного запуска (следует указать актуальный хост размещения ecss-autoprovision 1.4, порт, актуальные учётные данные и размер request_chunk_size (количество объектов обрабатываемых за раз, по умолчанию = 4)):

data = %CoR.Data{
  assigns: %{
    data: %{
      payload: %{
        host: "http://10.24.0.101:1350/",
        login: "root",
        password: "ecss-autoprovision",
        default_ttl: 480_000,
        request_chunk_size: 4,
        chunk_size: 20
      }
    },
  },
  private: %{}
}

EcssAupCore.CoR.AupLegacy.Action.Migrate.call(data, [])

Команда для асинхронного запуска:

payload = %{
      host: "http://10.24.0.101:1350/",
      login: "root",
      password: "ecss-autoprovision",
      default_ttl: 480_000,
      request_chunk_size: 4,
      chunk_size: 20
}
EcssAupCore.Subscriber.request("/ecss_aup_core/request/aup_legacy/migrate", %{payload: payload}, ttl: 180_000_000)

Ожидаем завершения миграции.

Проверить количество устройств можно командой:

import Ecto.Query
EcssAupDb.Models.Device |>
Ecto.Query.select([a], count(a.uuid)) |>
EcssAupDb.Repo.one()