Планирование миграции
Это руководство описывает шаги, необходимые для планирования успешной миграции в InfraVision. Хотя оно написано в контексте полностью новой установки, описанный подход также применим для добавления новых данных в существующие развёртывания InfraVision.
Определение текущих источников истины
Прежде чем начать использовать InfraVision для своих данных, важно понять, где находятся ваши существующие источники истины. «Источник истины» — это любое хранилище данных, которое является авторитетным для определённой области. Например, у вас может быть электронная таблица, отслеживающая все IP-префиксы в вашей сети. Пока все заинтересованные стороны согласны, что эта таблица авторитетна для всей сети, она является вашим источником истины для IP-префиксов.
Что угодно может быть источником истины при соблюдении двух условий:
- Все заинтересованные стороны согласны, что этот источник данных является корректным.
- Область применения чётко определена.
Уделите время инвентаризации ваших источников истины для инфраструктуры. При попытке их каталогизировать вы, скорее всего, столкнётесь с некоторыми проблемами:
- Множество конфликтующих источников для одной области. Например, может существовать несколько версий электронной таблицы, каждая из которых содержит противоречивые данные.
- Источники без определённой области. Разные команды в вашей организации могут использовать разные инструменты для одной цели без чёткого определения, когда какой использовать.
- Труднодоступное форматирование данных. Некоторые инструменты лучше подходят для программной обработки. Например, электронные таблицы легко парсить и экспортировать, тогда как свободные заметки в wiki обрабатывать гораздо сложнее.
- Источник истины отсутствует. Иногда оказывается, что источника истины для области просто не существует. Например, при назначении IP-адресов операторы могут использовать любой (предположительно) свободный IP из подсети, не фиксируя его использование.
Постарайтесь определить каждую область данных инфраструктуры вашей организации и источник истины для каждой. После их составления вам нужно будет решить, что переносить в InfraVision.
Определение данных для переноса
Общее правило при определении данных для InfraVision: если для чего-то есть модель, это должно быть в InfraVision. Например, InfraVision имеет специализированные модели для стоек, устройств, кабелей, IP-префиксов, VLAN и т.д. Их использование очень простое. Однако вы неизбежно достигнете границ модели данных InfraVision и зададитесь вопросом, какие дополнительные данные имеет смысл хранить. Например, стоит ли InfraVision быть источником истины для DNS-записей инфраструктуры или DHCP-скоупов.
InfraVision предоставляет два основных механизма расширения модели данных. Первый — пользовательские поля: большинство моделей поддерживают добавление полей для хранения данных, для которых нет встроенного поля. Например, можно добавить поле «инвентарный номер» к модели устройства. Второй механизм — плагины. Пользователи могут создавать собственные плагины для добавления полностью новых моделей, представлений и эндпоинтов API. Это невероятно мощный инструмент, обеспечивающий быструю разработку и тесную интеграцию с базовыми моделями.
При этом не всегда имеет смысл переносить область данных в InfraVision. Например, многие организации используют только компоненты IPAM или только DCIM, интегрируясь с другими источниками истины для других областей. Это вполне допустимый подход (при условии, что все согласны, какой инструмент авторитетен для каждой области). В конечном счёте вам нужно взвесить ценность хранения неродных моделей данных в InfraVision против усилий по их определению и поддержке.
Учитывайте также, что InfraVision постоянно развивается. Хотя текущая версия может не поддерживать определённый тип объекта, его поддержка может быть запланирована в будущих релизах.
Валидация существующих данных
Последний шаг перед миграцией данных в InfraVision самый важный: валидация. Принцип GIGO (мусор на входе — мусор на выходе) работает в полную силу: ваш источник истины хорош настолько, насколько хороши данные в нём. Хотя InfraVision имеет мощные инструменты валидации данных (включая поддержку пользовательских правил валидации), в конечном счёте ответственность за определение корректности данных лежит на человеке. Например, InfraVision может проверить подключение кабеля между двумя интерфейсами, но не может сказать, должен ли там быть этот кабель.
Несколько советов для импорта только валидных данных в InfraVision:
- Убедитесь, что вы начинаете с полных, хорошо отформатированных данных. Для лучшей переносимости рекомендуется JSON или CSV.
- Рассмотрите определение пользовательских правил валидации в InfraVision до импорта (например, для соблюдения схем именования устройств).
- Используйте скрипты для автоматического заполнения шаблонных данных (например, для автоматического создания стандартного набора VLAN для каждой площадки).
Существует несколько методов импорта данных в InfraVision, которые мы рассмотрим в следующем разделе.
Порядок действий
При работе с полностью пустой базой данных может быть неочевидно, с чего начать. Многие модели в InfraVision зависят от предварительного создания других типов. Например, нельзя создать тип устройства до создания его производителя.
Ниже приведён (примерный) рекомендуемый порядок создания или импорта объектов InfraVision. Хотя следовать этому порядку строго не обязательно, это обеспечит наиболее гладкий процесс.
- Группы арендаторов и арендаторы
- Регионы, группы площадок, площадки и местоположения
- Роли стоек и стойки
- Производители, типы устройств и типы модулей
- Платформы и роли устройств
- Устройства и модули
- Провайдеры, аккаунты провайдеров и сети провайдеров
- Типы каналов связи и каналы связи
- Группы беспроводных сетей и беспроводные сети
- Route target и VRF
- RIR и агрегаты
- Роли IP/VLAN
- Префиксы, IP-диапазоны и IP-адреса
- Группы VLAN и VLAN
- Типы кластеров, группы кластеров и кластеры
- Виртуальные машины и интерфейсы ВМ
Это не исчерпывающий список, но его должно быть достаточно для первоначального импорта данных. После этого порядок добавления объектов практически не имеет значения.
Графы ниже иллюстрируют некоторые основные зависимости между различными моделями в InfraVision для справки.
Вложенные объекты
Символ ↻ означает, что объект поддерживает вложенность (может содержать дочерние объекты того же типа). Например, регионы могут представлять как страны, так и города, при этом последние вложены в первые.
Арендаторы
flowchart TD
TenantGroup["Группа арендаторов ↻"] --> Tenant["Арендатор"]
Tenant --> Site["Площадка"]
Tenant --> Device["Устройство"]
Tenant --> Prefix["Префикс"]
Tenant --> VLAN
click Device "../../models/dcim/device/"
click Prefix "../../models/ipam/prefix/"
click Site "../../models/dcim/site/"
click Tenant "../../models/tenancy/tenant/"
click TenantGroup "../../models/tenancy/tenantgroup/"
click VLAN "../../models/ipam/vlan/"Площадки, стойки и устройства
flowchart TD
Region["Регион ↻"] --> Site["Площадка"]
SiteGroup["Группа площадок ↻"] --> Site
Site --> Location["Местоположение ↻"]
Location --> Rack["Стойка"]
Manufacturer["Производитель"] --> DeviceType["Тип устройства"]
Manufacturer --> ModuleType["Тип модуля"]
DeviceRole["Роль устройства"] --> Device["Устройство"]
Platform["Платформа"] --> Device
DeviceType --> Device
Rack --> Device
Location --> Device
ModuleType --> Module["Модуль"]
Device --> Module
Device --> Interface["Интерфейс"]
Module --> Interface
click Device "../../models/dcim/device/"
click DeviceRole "../../models/dcim/devicerole/"
click DeviceType "../../models/dcim/devicetype/"
click Interface "../../models/dcim/interface/"
click Location "../../models/dcim/location/"
click Manufacturer "../../models/dcim/manufacturer/"
click Module "../../models/dcim/module/"
click ModuleType "../../models/dcim/moduletype/"
click Platform "../../models/dcim/platform/"
click Rack "../../models/dcim/rack/"
click RackRole "../../models/dcim/rackrole/"
click Region "../../models/dcim/region/"
click Site "../../models/dcim/site/"
click SiteGroup "../../models/dcim/sitegroup/"VRF, префиксы, IP-адреса и VLAN
flowchart TD
VLANGroup["Группа VLAN"] --> VLAN
Role["Роль"] --> VLAN
Role --> IPRange["IP-диапазон"]
Role --> Prefix["Префикс"]
RIR --> Aggregate["Агрегат"]
RouteTarget["Route Target"] --> VRF
Aggregate --> Prefix
VRF --> Prefix
VRF --> IPRange
VRF --> IPAddress["IP-адрес"]
Prefix --> VLAN
Prefix --> IPRange
Prefix --> IPAddress
click Aggregate "../../models/ipam/aggregate/"
click IPAddress "../../models/ipam/ipaddress/"
click IPRange "../../models/ipam/iprange/"
click Prefix "../../models/ipam/prefix/"
click RIR "../../models/ipam/rir/"
click Role "../../models/ipam/role/"
click VLAN "../../models/ipam/vlan/"
click VLANGroup "../../models/ipam/vlangroup/"
click VRF "../../models/ipam/vrf/"Каналы связи
flowchart TD
Provider["Провайдер"] --> ProviderNetwork["Сеть провайдера"]
Provider --> Circuit["Канал связи"]
CircuitType["Тип канала связи"] --> Circuit
Circuit --> CircuitTermination["Терминация канала"]
click Circuit "../../models/circuits/circuit/"
click CircuitTermination "../../models/circuits/circuittermination/"
click CircuitType "../../models/circuits/circuittype/"
click Provider "../../models/circuits/provider/"
click ProviderNetwork "../../models/circuits/providernetwork/"Кластеры и виртуальные машины
flowchart TD
ClusterGroup["Группа кластеров"] --> Cluster["Кластер"]
ClusterType["Тип кластера"] --> Cluster
Site["Площадка"] --> Cluster
Cluster --> VirtualMachine["Виртуальная машина"]
Site --> VirtualMachine
Device["Устройство"] --> VirtualMachine
Platform["Платформа"] --> VirtualMachine
VirtualMachine --> VMInterface["Интерфейс ВМ"]
click Cluster "../../models/virtualization/cluster/"
click ClusterGroup "../../models/virtualization/clustergroup/"
click ClusterType "../../models/virtualization/clustertype/"
click Device "../../models/dcim/device/"
click Platform "../../models/dcim/platform/"
click VirtualMachine "../../models/virtualization/virtualmachine/"
click VMInterface "../../models/virtualization/vminterface/"