Child pages
  • Миграция на NOC Tower

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Если у вас уже есть установленный NOC Tower и развёрнутый NOC данный раздел можно пропустить и перейти к разделу Развёртывание бэкапов.

Установка NOC Tower

NOC Tower это средство для автоматизации развёртывания NOCa. Используется во всех новых версиях с его появлением установка NOCa без его использования не поддерживается.

Сам Tower - это веб-интерфейс для настроек. Рекомендумая процедура установки через Docker контейнер.

Архив:

...

Сама процедура описана в руководствах по установке. Замечу только, что в случае сомнений - , выбирайте значение по умолчанию (Install Everything) - устанавливать всё на одном хосте. В последствии разнести какие-то компоненты на отдельные машины проблемы не составляет.

При первоначальной установке необходимо в опциях выбирать пункт Everything. После установки необходимо проверить работоспособность NOC'a. Внести пару хостов, посмотреть что всё нормально запускается. При миграции все данные будут удалены(smile) Все данные занесенные данные, во время миграции будет удалены(smile). Если они необходимы, можно либо сделать бэкап БД, либо сделать экспорт в csv.

Получения бэкапов

Expand
titleДля ленивых (кто держит базы на отдельном хосте)

Если в вашем окружении БД NOC'a вынесены на отдельные хосты и вы не хотите менять данную традицию, то для PosgreSQL есть возможность сделать клон базы. Это делается командой:

CREATE DATABASE <new<pg_db_noc> new> WITH TEMPLATE <old_noc> OWNER <noc<pg_db_old> OWNER <pg_user>;

где <new_noc> <pg_db_new> - бд для нового НОК'a

<old_noc>  <pg_db_old> - имя БД для старого НОК'а

<noc<pg_user> user> - пользователь, с которым будет подключиться новый НОК 

 

Для процедуры миграции понадобятся дампы баз данных со "старого"  со старого NOC'a: PostgreSQL и MongodbMongoDB. Миграция данных по производительности (Performance) не предусмотрено. По умолчанию НОК настроен на выполнение бэкапов своих баз. Проверить включен ли данный функционал бэкапы НОКа не включены. Проверить это можно зайдя в пункт меню Main -> Setup -> Schedulers. В столбце Enabled? должна стоять галочка и . Зелёный значок справа должен быть зелёнымпоказывает, что бэкап выполнен успешно. Если бэкапы не выполняются (галочка не установлена) - необходимо их включить. Если значок красного цвета - необходимо разобраться, что не работает. Обычно, причиной является

Info

Вероятные причины не выполнения бэкапов:

  • отсутствие директории на диске или неправильные права на неё (владельцем должен быть пользователь noc), куда настроены выполняться бэкапы. Настройки бэкапов находятся в

...

  • файле noc.conf. Посмотреть их можно в пункте Main -> Setup -> Configs.
  • не правильный путь до исполняемых файлов pg_dump и mongodump (проверить noc.conf раздел path)
  • бэкап выполняется, но нет файлов бэкапа баз postgres (pg_dump*), необходимо дать пользователю noc права superuser на базу (или выполнить бэкап вручную, командой "pg_dump -Fc -f /tmp/noc-db-bkp.dump -U noc noc", из-под пользователя с правами superuser на базу).

Бэкап пишет логи в файл noc-scheduler.log под процессом main.backup. Там можно посмотреть причину не выполнения бэкапа.

Развёртывание бэкапов
Anchor
DeployBackup
DeployBackup

...

  1. Есть развёрнутый и рабочий NOC
  2. Есть дампы баз PostgreSQL и MongoDB (см. пункт Получение бэкапов выше)
  3. Необходимо остановить NOC командой service noc stop

Развёртывание бэкапа PostgreSQL

  1. Подключаемся к PostgreSQL с базой нового NOC'a под пользователем postgres (pgsql для FreeBSD).

    Code Block
    languagebash
    titleLinux
    # su - postgres 
    # psql -d template1


  2. Пересоздаём базу нового НОКа. Вместо <newВместо <pg_noc> db> необходимо подставить имя базы, которое задавали при настройки Environments в Башне (по умолчанию noc).

    Code Block
    languagebash
    postgres=# DROP DATABASE <new<pg_noc>db>;
    postgres=# CREATE DATABASE <new<pg_noc>db> ENCODING 'UTF8' OWNER noc;<pg_user>;
    postgres=# \q


  3. Заливаем бэкап от старого НОК'a в созданную БД. Делать это необходимо из-под пользователя postgres (pgsql для FreeBSD).

    Warning

    Будьте осторожны если старый NOC установлен на версии PostgreSQL ниже 9 (н-р 8.4). По умолчанию новый NOC устанавливает версию PostgreSQL 9.4. Прямое развёртывание дампов версий ниже 9 может приводить к ошибкам. Поэтому необходимо вначале провести миграцию данных PostgreSQL Также, в новом НОКе не используется плагин PostGIS, поэтому при импорте из бэкапа данных ГИС будут выдаваться ошибки.

    Можно провести миграцию всех данных Postgres в версию 9.4. Для этого можно воспользоваться официальным руководством Миграция данных между версиями PostgreSQL.

    Code Block
    languagebash
    themeRDark
    titleПроцедура миграции PostgreSQL
    collapsetrue
    #### На ноде со старой версией PostgreSQL
    # 
    psql -d noc -U noc -W < noc-db-2016-07-13-13-10.dump
    su - postgres
    # cd /tmp/
    # pg_dumpall > pg_backup.dump
    # еxit
    #### Переносим pg_backup.dump на хост с новым PostgreSQL (н-р scp /tmp/pg_backup.dump root@<new_nodeIP>:/tmp/)
    #### На новой ноде
    # su - postgres
    # cd /tmp/
    # psql -d template1
    postgres=# DROP DATABASE <pg_db>;
    postgres=# \q
    # psql -f /tmp/pg_backup.dump


    Warning
    При выполнении полной миграции, если имя пользователя NOC в старой и новом PostgreSQL совпадают, то пароль пользователя из старой БД заменит новый. Необходимо будет либо заменить пароль в Environments, либо вернуть пароль к актуальному в PostgreSQL командой: 
    ALTER USER <pg_user> WITH PASSWORD <pg_user_password>;



    Code Block
    languagebash
    # su - postgres
    # pg_restore -d noc <dump_file_name>


  4. Убеждаемся что во время импорта критических ошибок не появлялось (при критичных ошибках восстановление прервётся).

Развёртывание бэкапа MongoDB

Info
titleСокращения
  • <noc_mongo_admin_user> - Пользователь MongoDB с привилегиями администратора. Обычно, с ролью userAdminAnyDatabase (по умолчанию root)
  • <noc_mongo_admin_password> - Пароль пользователя <noc_mongo_admin_user>
  • <noc_mongo_database> - Имя базы НОКа, задаётся в настройках Environments Башни
  • <noc_mongo_user> - Пользователь, из под которого происходит работа с БД, также задаётся в настройках Environments Башни
  1. Подключаемся к MongoDB из под пользователя с административными правами. В случае, если монго разворачивалась из Башни, узнать пользователя можно выбрав созданный Environment и нажав кнопку Inventory сверху. Там необходимо найти пункты noc_mongo_admin_user (по умолчанию root) и noc_mongo_admin_password

    Code Block
    languagebash
    themeConfluencelanguagebash
    # mongo -u <noc_mongo_admin_user> -p --authenticationDatabase admin 127.0.0.1

    Image Added

  2. Создаём роль "executeFunctions" и выдаём её пользователю <noc_mongo_user>

    Code Block
    languagebash
    themeRDark
    languagebash
    rs0:PRIMARY> use admin
    rs0:PRIMARY> db.createRole( { role: "executeFunctions", privileges: [ { resource: { anyResource: true }, actions: [ "anyAction" ] } ], roles: [] } )

    Пересоздаём базу

    Code Block
    themeConfluence
    languagebash
    
    rs0:PRIMARY> use <noc_mongo_db>database>
    rs0:PRIMARY> db.dropDatabase()
    rs0:PRIMARY> db.runCommand( { dropAllUsersFromDatabase: 1, writeConcern: { w: "majority" } } )

    Создаём базу и пользователя

    Code Block
    themeRDark
    languagebash
    rs0:PRIMARY> use <noc_mongo_db>
    rs0:PRIMARY> grantRolesToUser("noc", [ { role: "executeFunctions", db: "admin" } ])
    rs0:PRIMARY> exit


  3. Пересоздаём базу

    Info

    При выполнении команды db.dropDatabase(), начиная с версии MongoDB 2.6, пользователь не удаляется. Если в этом есть необходимость, можно воспользоваться командой db.runCommand( { dropAllUsersFromDatabase: 1 } ).

    Для создания пользователя применяется команда: db.createUser({user:<noc_mongo_user>,

    pwd:<noc_mongo_user_password>,

    roles:

    [

    {

    role:

    "dbAdmin",

    db:

    "noc_work"

    <noc_mongo_database>},{

    role:

    "readWrite",

    db:

    "noc_work"

    <noc_mongo_database>},{

    role:

    "executeFunctions",

    db:

    "admin"

    } ])
    Импортируем

    } ]})


    Code Block
    languagebash
    themeConfluence
    # mongo -u <noc_mongo_user> -p --authenticationDatabase <noc_mongo_database> 127.0.0.1
    rs0:PRIMARY> use <noc_mongo_database>
    rs0:PRIMARY> db.dropDatabase()
    rs0:PRIMARY> use <noc_mongo_database>
    rs0:PRIMARY> exit


  4. Распаковываем бэкап и импортируем данные старого НОКа в пересозданную базу.

    Code Block
    languagebash
    themeRDark
    languagebash
    # tar -xzf noc-mongo-2016-05-05-10-47.tar.gz
    # mongorestore --host=localhost --username=<noc_mongo_user> --password --authenticationDatabase=<noc_mongo_database> --db=<noc_mongo_database> ./noc

...

  1. <old_mongo_db_name>


Миграция.

Note

Если, при восстановление бэкапов, вы изменили имя базы или пользователя, или заменили пароль то необходимо актуализировать настройки в Environments.

После выполнения всех действий запускаем Deploy из башни, отмечаем в башне опции "Do database migration" и "Restart quick". Затем нажимаем Deploy, в процессе произойдёт миграция данных в новый НОК.

...

.

Image Added

Info

Если возникли какие-то проблемы с миграцией через башню. Можно выполнить миграцию вручную. Команды для этого (выполняются из папки НОКа):

  1. ./noc migrate
  2. ./noc ensure-indexes
  3. ./noc collection sync
  4. ./noc sync-perm
  5. ./noc sync-mibs
  6. Если миграция выполняется в первый раз - необходимо выполнить: ./scripts/deploy/apply-pools

Проверка

Warning

Если у вас после миграции не запускается ВЕБ - проверьте что НОК запущен!

После успешной миграции необходимо зайти в НОК и проверить что все данные переехали нормально. Если возникли проблемы, необходимо поискать ответы в пункте Возможные проблемы и затем спросить в общем чате, возможно, кто-то уже с ними сталкивался(smile)

Возможные проблемы

В: После миграции не открывается Веб.

О: Проверьте что НОК запущен.

Code Block
languagebash
titleПроверка состояние процессов.
collapsetrue
# cd /opt/noc
# ./noc ctl
### Все процессы должны быть RUNNING

 В: После миграции не отображаются MO.

О: Обычно, такое может произойти при ошибках миграции - например, если не была очищена база Монги, перед заливкой туда бэкапа. Необходимо повторить шаги миграции.

В: 

 

 Всем устройствам назначем странный пул P0001

О: Это пул "затычка" создался при миграции. Необходимо вручную пройтись по устройствам и назначить рабочий пул или воспользоваться noc shell (вмeсто <pool_name> необходимо указать имя своего пула (по умолчанию - default)):

Code Block
languagepy
collapsetrue
# ./noc shell
from noc.sa.models.managedobject import ManagedObject
from noc.main.models.pool import Pool
p = Pool.objects.get(name=<pool_name>)
for m in ManagedObject.objects.filter(is_managed=True):
    m.pool = p
    m.save()


В: После миграции с устройств не собираются данные.

О: Необходимо проверить Managed Object Profiles (Service Activation -> Setup -> Managed Object Profiles). По умолчанию все методы сбора отключены. Также необходимо просмотреть логи discovery и активаторов на предмет ошибок и трейсов.