Как скрестить ужа с ежом или построение HLD ИТ-инфраструктуры по принципам C4

Любой инфраструктурный проект, будь то внедрение системы виртуализации, миграция со статической маршрутизации на динамическую, разработка модуля 1С или даже ремонт в квартире является проектом, который нужно структурировать, чтобы ответить на вопросы «что мне сделать?», «зачем мне это делать?», «что я хочу увидеть в конечном результате?» и только после этого «как мне это сделать, чтобы ничего не сломать?». В противном случае получится ситуация из анекдота «… один сломал, второй потерял…» и наш проект останется далеким от желаемого результата.

Таким образом мы подходим к пониманию основных этапов ИТ-проектирования. Обязательно отметим ключевые:

• Техническое задание. Основной документ, который должен ответить на главный вопрос «что я хочу получить», притом ответ должен быть четким и измеримым. На примере квартиры это набор требований, вроде, «использование ламината класса 33 высотой не менее 8 мм в спальне 12 м², кабинете 11 м², зале 18 м² с допустимым объемом брака 2 упаковки», а не «сделайте красиво, парни». Более конкретная постановка задачи уменьшит для вас стоимость решения и максимально полно будет соответствовать вашим ожиданиям, так как это будет именно что, хотите ВЫ.

Disclaimer: характеристики ламината взяты почти наобум, перед подборкой лучше проконсультируйтесь с профильными специалистами.

• HLD, он же High Level Design, он же Высокоуровневое проектирование. Здесь вы уже крупными мазками описываете, как ваш проект (квартира) будет выглядеть с минимальной декомпозицией. Например:

  

  • Архитектурный стиль: это будет монолит, микросервисы или что-то еще. Например, в рамках примера, стиль квартиры Прованс. Уже под это вы будете подбирать материалы.

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

• Взаимодействие: определение основных протоколов и потоков данных. В терминах ИТ это похоже на описание того, какие подсистемы между собой общаются, по каким интерфейсам и какие есть ограничения. Для нашей квартиры это будет уже не «какой именно кабель идет в каждую розетку», а понимание базовых связей между зонами и инженерными системами. Например:

  • из прихожей должен быть удобный доступ в санузел и жилую часть;

  • кухня должна быть логично связана с обеденной зоной;

  • электрический щит должен быть размещен так, чтобы от него было удобно разводить линии по квартире;

  • рабочее место должно иметь доступ к электропитанию, освещению и, возможно, слаботочной сети;

  • Технологический стек: выбор решений, баз данных, языков программирования. Для квартиры это будет набор основных параметров для каждого помещения, например:

    • на кухне стены обклеиваются текстурированными обоями, пол — плитка;

    • в санузле стены и пол выкладываются разноформатной плиткой.

• LLD, он же Low-Level Design, он же Низкоуровневое проектирование. Включает в себя полную детализацию HLD декомпозируя основные вещи на составные части. То есть отвечает не на общий вопрос “как будет устроено в целом?”, а на более предметный “как именно будет реализовано?”. Например, если в HLD у нас указано “обеспечить спальню 6 силовыми розетками”, LLD уже ответит:

  • на какой высоте розетки будут;

  • к каким группам подключаются;

  • каким кабелем выполняются;

  • в какой штробе проходят и т.д.

• Реализация — непосредственно выполнение работ. В инфраструктуре это могут быть работы по монтажу, настройке, написанию кода, в ремонте — демонтаж, разведение электрики, возведение перегородок и так далее. Полное раскрытие здесь не необходимо, шаг понятен.

• Тестирование и внедрение — проверка, что результат соответствует требованиям и ожиданиям (может и лучше на стенде), затем ввод в промышленную эксплуатацию. В разрезе ремонта вы убеждаетесь, что вашей свежеотремонтированной квартирой можно пользоваться, как задумано, без неожиданностей “открыл воду на кухне — включился телевизор”.

Вот и самый главный вопрос — если мы этапы ИТ-проектов можем переложить на что-то бытовое, вроде ремонта, сможем ли мы применить практически любой подход к HLD как в разработке ПО так и в проектированию ИТ-инфраструктуры.

Сейчас и узнаем!

Основные подходы к HLD

Вообще для HLD используется много способов от банальной логики до определенных моделей, стандартов и рекомендаций, например:

• Модель 4+1

• ISO/IEC/IEEE 42010

• C4

Разберем основные подходы каждой модели.

Модель 4+1

Модель была предложена Филиппом Крутченом, как способ описать архитектуру через несколько представлений:

• Логическое представление — функционал предоставляемый конечным пользователям (UML диаграммы, ключевые абстракции);

• Процессное представление — динамические аспекты системы, объясняет сами процессы и их взаимодействие;

• Представление разработки — система с перспективы программиста;

• Физическое представление (представление развертывания) — система с перспективы системного инженера;

• Сценарии — небольшой сет кейсов использования, описывает последовательность взаимодействия между объектами и между процессами системы.

Модель ориентирована на разных стейкхолдеров и не пытается уместить все в одну диаграмму. Однако требует реально больших компетенций и доверия внутри команды для наполнения каждого представления.

ISO/IEC/IEEE 42010

Эволюция прекрасного стандарта ANSI/IEEE 1471-2000.

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

С его помощью можно правильно организовать описание любой архитектуры, можно связать даже с другими подходами, включая 4+1 и C4.

Описывать долго не имеет смысла, лучше просто почитать введение на официальном сайте, поэтому перейдем сразу к гвоздю программы.

Модель C4

Модель создана Саймоном Брауном не так давно, быстро снискала популярность и используется от бородатых админов до любителей смузи, делающих онлайн магазинчики на React.

Строится на 4-х уровнях приближения:

• Контекст системы;

• Контейнеры;

• Компоненты;

• Код.

Даже на официальном сайте позиционируется как способ создавать “map of your code” на разных уровнях детализации.

Но не забываем, что это не ISO, а просто практическая модель документирования и визуализации, очень удобная для командной коммуникации.

Однако наша задача попробовать применить модель не на код, а на “сотворении” ИТ-инфраструктуры со стороны инженера.

Поехали!

C4 в ИТ-инфраструктуре на примере проекта создания отказоустойчивого кластера виртуализации

Вот для чего мы собрались! Попытаемся же принципы C4 перенести в чисто инженегрский проект и описать HLD.

Вводные данные

Задача: построение отказоустойчивого кластера на базе oVirt-основанных программных продуктов и последующая миграция из других систем виртуализации.

Допущения и условия:

• 2 ЦОД

• В каждом ЦОД 2 кластера по 4 хоста

• В каждом ЦОД по СХД

• Подключение к СХД при помощи iSCSI

• Синхронная репликация данных средствами СХД между ЦОД

• 2 сервера РК в каждом ЦОД

• СХД для РК в каждом ЦОД, подключение NFS

• интеграция  AD LDAP

• интеграция с системой мониторинга

• интеграция с SIEM

• Расположение DNS-сервисов вне системы виртуализации

• Используются в текущем контуре VMware ESXi и Microsoft Hyper-V

Возьмем выбранную систему, недельку покурим документацию и… пойдем по каждому уровню модели C4, составим диаграммы и краткое описание.

C4 — Level 1. Context

Если мы рассматриваем классическое представление Level 1 — здесь обычно указываются взаимодействие пользователей с программным продуктом и основные интеграции.

То есть без проблем можно ответить на вопрос “кто взаимодействует с сервисом” с высоты птичьего полета и уже на этом этапе составить представление об архитектуре сервиса.

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

Но как же переложить это на проект ИТ-инфраструктуры?

На самом деле тут несколько проще. У нас так же есть пользователи системы (Администраторы, Эксплуатация, Владельцы сервисов), есть интеграции (DNS, NTP, AD/LDAP, Мониторинг, Сбор логов/SIEM, ПО Резервного копирования), а так же добавляются внешние системы, которые так же будут являться участниками данного процесса в проекте миграции ВМ (VMware ESXi и Microsoft Hyper-V).

Все эти вещи мы отмечаем на самой простой в мире диаграмме и выстраиваем отношения, дополняя их комментариями для понимания “а что здесь происходит”.

В описании в документе детализируем отношение элементов друг к другу, к примеру, обычным маркированным списком (разумеется после небольшого вступительного слова “о чем раздел”).

Описываем основные группы пользователей и их метод взаимодействия с системой:

• Администраторы платформы: взаимодействие с системой одностороннее (подключение к системе и внесение изменений); основные задачи группы конфигурация, управление, обслуживание.

• Эксплуатация/дежурная смена: взаимодействие с системой одностороннее (подключение к системе и чтение метрик, решение простых задач); основные задачи группы осуществление мониторинга и первичная реакция на инциденты, не требующими внесения изменений в конфигурацию платформы.

• Владельцы сервисов (при необходимости): взаимодействие с системой одностороннее (подключение к системе и доступ к контролируемым сервисам); основные задачи группы – контроль работы необходимых сервисов без внесения изменений в саму платформу.

Так же описываем основные внешние системы, требующие интеграции:

• Сервис DNS: взаимодействие одностороннее (от платформы к сервису); процесс однозначного определения имен.

• Сервис NTP: взаимодействие одностороннее (от платформы к сервису); процесс определения текущего времени для последующего использования в задачах и отметках времени в логах.

• Интеграция с AD/LDAP: взаимодействие одностороннее (от платформы к сервису); однозначное определение учетных данных для доступа к платформе (не входит в состав работ).

• Интеграция с используемой системой мониторинга: взаимодействие двустороннее (активный запрос из системы мониторинга, так же периодическая отправка сообщений от платформы); своевременное оповещение и реагирование на определенные инциденты (не входит в состав работ).

• Интеграция с системой сбора логов/SIEM: взаимодействие одностороннее (от платформы к сервису); передача лог-сообщений платформы по протоколу syslog для последующей обработки сторонними сервисами (не входит в состав работ).

• Интеграция с ПО РК: взаимодействие двустороннее (процедура РК на уровне платформы, процедура восстановления на уровне платформы); операции резервного копирования (не входит в состав работ).

C4 — Level 2. Containers

Верхнеуровнево инфраструктура описана, но пока это больше похоже на концепт. Тут вступает в дело следующий уровень модели C4 под названием Контейнеры.

В нем описываются основные контейнеры и их базовое взаимодействие с указанием применяемых технологий .

Данная диаграмма уже способна ответить на вопрос “как взаимодействуют элементы сервиса”, правда все еще верхнеуровнево.

Диаграмма так же полезна всей команде разработки, включая системных аналитиков и архитекторов, давая ключевое понимание  применяемых технологий.

Возвращаемся к нашему вопросу, как же переложить это все на инфраструктуру?

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

Так же необходимо сделать пояснения к элементам схемы.

Пользователи платформы имеют доступ к платформе на основе RBAC-правил, проходя аутентификацию на стороне Hosted Engine VM, уже предоставляющей прокси доступ к ВМ внутри кластеров и физических хостов.

• Неограниченный доступ допускается только у администратора системы в соответствии с политиками информационной безопасности Компании.

• Доступ дежурной смены допускается к основным метрикам платформы.

• Доступ владельцев сервисов допускается только к ВМ сервисов в соответствии с политиками информационной безопасности Компании.

• Во время миграции Hosted Engine выполняет подключение к VMware vCenter для инвентаризации ВМ и последующей загрузки в инфраструктуру платформы виртуализации данных ВМ с последующей конвертацией (диски ВМ, конфигурационные файлы).

• При миграции из Microsoft Hyper-V Администратор платформы вручную выполняет загрузку диска ВМ с последующей конвертацией во внутренний формат платформы виртуализации.

Внутри платформы виртуализации Hosted Engine VM располагается в одном из кластеров платформы, осуществляет динамическое распределение ресурсов, управление агентами хостов и ВМ, HA, выполняя роль центрального элемента управления платформой виртуализации. Взаимодействие с хостами возможно по нескольким протоколам и определяется в отдельном приложении.

Хосты каждого кластера подключены к своим СХД с использованием iSCSI, так же между СХД разных ЦОД настроена синхронная репликация поверх сетевого стека Компании. При наступлении катастрофы имеющаяся схема репликации позволит развернуть на РЦОД Hosted Engine VM с минимальными RTO/RPO.

Взаимодействие платформы с внешними сервисами происходит либо каждым отдельным элементом, либо Hosted Engine VM.

• Запросы DNS для корректного функционирования кластеров исходят от каждого элемента платформы.

• Запросы NTP так же исходят от каждого элемента платформы и отвечают за синхронизацию времени всех элементов.

• Запросы LDAP исходят от Hosted Engine VM для синхронизации пользователей и обеспечения единой точки управления RBAC.

• Мониторинг работает в режиме агента и SNMP и может обеспечивать активные проверки, соответственно запросы двухсторонние.

• Для отправки логов элементов платформы используется SYSLOG со стороны платформы в сторону SYSLOG коллектора или сервера.

• Резервное копирование осуществляется файловой части, на уровне гипервизора и внутри ВМ application-aware, в связи с чем допускается двухстороннее взаимодействие.

C4 — Level 3. Components

Детализирует структуру внутри контейнера системы, то есть описывает более детально только один контейнер из предыдущего уровня. Используется для проектирования и документирования внутренней структуры компонентов системы.

Вот только детализация одного компонента зачастую является идеальным решением, редко применяемым на практике. В тех же инфраструктурных проектах одно зачастую цепляется за другое и диаграмма вырастает до неприличных размеров, поэтому нужно просто не забывать, что «краткость — сестра таланта» и мы составляем все‑таки HLD.

Отдельно необходимо отметить, что данный раздел уже полезен архитектору и продуктовой команде, а аналитикам уже постольку‑поскольку.

Указываем базовые элементы платформы и взаимодействие уже внутри платформы с небольшой детализацией самых основных вещей.

Контейнер «Сети» содержит общие для инфраструктуры элементы и частично маршрутизирован между ЦОД.

Части контейнера «Сети»:

• CG – сеть репликации, групп консистентности между СХД. Рекомендуется использовать отдельный канал передачи данных не менее 10 Гбит/с, либо гарантировать пропускную способность не менее указанной на текущих каналах.

• OOB – сеть, включающая в себя сеть управления оборудованием (IPMI, BMC, Management СХД и т.д.).

• MGMT – сеть подключения и управления кластером виртуализации.

• iSCSI-A – отдельная от остальной инфраструктуры сеть для доступа кластеров к СХД одним путем.

• iSCSI-B – отдельная от остальной инфраструктуры сеть для доступа кластеров к СХД другим путем.

• PROD – основная сеть Компании для размещения сервисов. Отдается на вычислительные сервера в виде Trunk со сконфигурированным LACP.

• Backup – сеть для взаимодействия серверов РК с СХД РК.

Контейнеры «Кластер 1» и «Кластер 2» содержат в себе вычислительные сервера для работы виртуализации (по 4 шт.) и связаны со всеми сетями, кроме CG, Backup. Связь с серверами РК допустима через общие PROD сети Компании.

В рамках ОЦОД так же располагается Engine ВМ, LUN реплицируется в рамках синхронной репликации между СХД. В случае события DR перезапускается в РЦОД.

Контейнеры «Host OC-BAK-01», «Host OC-BAK-02», «Host RC-BAK-01», «Host RC-BAK-02» в рамках своих ЦОД подключены к сетям OOB, Общий PROD трафик, РК Трафик для обеспечения возможности резервного копирования как элементов платформы, так и других защищаемых ресурсов.

Контейнеры «СХД Backup (ОЦОД) NFS Backup», «СХД Backup (РЦОД) NFS Backup» подключаются к сетям OOB и РК Трафик для возможности настройки, управления и мониторинга и основного трафика резервного копирования.

Настройка ПО резервного копирования не входит в перечень текущих работ.

Контейнеры «СХД (ОЦОД) LUN Engine + LUN VM Data» и «СХД (РЦОД) LUN Engine + LUN VM Data» подключаются к сетям CG, OOB, iSCSI-A, iSCSI-B, что обеспечивает синхронную репликацию, управление и мониторинг,  и разделенный MPIO для подключения вычислительных серверов кластеров.

А вот теперь, если у вас все хорошо с головой, для ИТ-инфраструктуры на этом уровне можно остановиться, ведь как связать понятия “код” и “проект с железками”?

Если интересно, то продолжим.

C4 — Level 4. Code

Как бы забавно ни звучало, но сам автор нотации C4 (Саймон Браун) признает, что этот шаг просто ну очень и совсем опционален.

Вообще этот уровень используется для структурирования как на примере с сайта автора.

Как видно из примера — представляет собой типичную диаграмму последовательности (UML) и, хоть и везде утверждают, что уровень не имеет смысла, для элемента приложения очень полезная вещь для продуктовой команды точно, для архитектора постольку-поскольку, для аналитика… аналитик обычно так далеко не погружается.

И продолжаем рубрику “вопрос-ответ”, как переложить это в инфраструктурный ИТ -проект? а на деле оказывается очень просто. Тут можно отказаться от диаграмм и включить набор исполняемых артефактов и процедур, обеспечивающих повторяемость развертывания, тестирования и эксплуатации. То есть будут относиться верхнеуровневые скрипты проверки готовности, шаблоны конфигурации и экспортов, процедуры проверки HA/DR, а также состав доказательной базы для приемки платформы.

Например:

Каталог артефактов и связь с этапами

В виде таблицы расписываем основные этапы проекта, получаемые артефакты на этапах, назначение и исполнителя

Проверки готовности

Проверки готовности выполняются до развертывания платформы и проведения испытаний. Повторяются после существенных изменений элементов платформы, включая изменения в физическом оборудовании (обновление прошивок, перекоммутация, изменение ACL, изменение внешних сервисов).

Цель проверок – фиксация соблюдения базовых зависимостей платформы.

Примечание: команды могут меняться в зависимости от используемых ОС и установленных пакетов.

И далее по аналогии можно включить базовые сценарии DR Failover и Failback, базовые сценарии HA, зафиксировать основные документы, протоколы и их кодировки и т.п., что уже не обязательно раскрывать.

Финальные разделы документа

В этих разделах уже можно зафиксировать основные риски проектных решений, которые видно именно “свысока”, что позволяет увидеть при ведении проекта основные узкие места, с которыми можно столкнуться. Да, все предусмотреть в принципе невозможно, но вам и вашим коллегам это поможет структурировать то, что известно о проблемах сейчас и, по возможности, дополнить при внедрении системы.

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

Вывод

В данной статье объяснены основные этапы проектной деятельности в ИТ, применена вроде бы исключительно кодерская нотация С4 к проекту по внедрению системы виртуализации, представлен основной разбор каждого уровня из нотации по применимости к ИТ-инфраструктуре. Как видно, применять можно, и даже нужно, в подготовке и реализации проектов. И главным плюсом С4 является гибкость, т.е. можно применить именно так, как удобнее вам. Однако, отсутствие стандартизации по типу ISO создает небольшие проблемы для больших и неповоротливых компаний, т.к. каждый архитектор будет писать так, как представляет именно он.

Так когда же применять C4 к проектированию архитектуры? Отмечу, что очень хорошо нотация ложится в новых проектах и для миграции откуда куда-то, а вот для поддержки legacy инфраструктуры может наоборот внести определенную сумятицу.

Вообще нотация — отличный инструмент для построения HLD целевой архитектуры ИТ-инфраструктуры, однако требует адаптации и не заменяет общепринятые стандарты (те же ISO или наши ГОСТ), но является прекрасным их дополнением.

В любом случае — каждому инструменту свое применение.

Всем спасибо за внимание!

P.S.

Для создания статьи использовались так же материала с Хабра, на которых я учился подходу:

1. https://habr.com/ru/articles/778726/ (отсюда утащил несколько картинок)

2. https://habr.com/ru/companies/sovcombank_technologies/articles/1005872/

3. https://habr.com/ru/companies/quadcode/articles/590719/