Rambler's Top100
Статьи ИКС № 3 2019
Николай НОСОВ  09 октября 2019

«Кубик Рубика» ИТ-архитектуры

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

В 80-х годах прошлого века, на заре компьютерной революции, предприятия мало задумывались об архитектуре своей ИТ-инфраструктуры. Как правило, использовался большой компьютер (мейнфрейм), в терминологии нашего времени – централизованная система. За ее архитектуру – принципиальную организацию ИТ-инфраструктуры, воплощенную в ее элементах, их взаимоотношениях друг с другом и со средой, а также за принципы, направляющие развитие системы, – отвечал разработчик мейнфрейма.

В 90-е с широким распространением персональных компьютеров эволюция ИТ повернула в сторону децентрализации, и предприятиям пришлось задуматься об ИТ-архитектуре. Они должны были оценивать перспективность технологий, выбирать программные комплексы, компьютеры и топологию сети. Пришлось обратить внимание и на архитектуру приложений – какое ПО и на какие компьютеры устанавливать, и на архитектуру информации – как организовать информационное взаимодействие между внутренними и внешними пользователями, приложениями и базами данных. Бизнес требовал установки все новых приложений, нужно было исключать дублирование бизнес-функций, использовать общие источники информации и разграничивать доступ пользователей к ним, думать о дальнейших шагах по развитию ИТ-инфраструктуры.

Не удивительно, что в 2000-е предприятия занялись осмыслением бизнес-процессов, формулировкой целей, политик, переносом оргструктур на уровень ИТ с автоматизацией ролей и выделением прав доступа.

Бизнес-архитектура усложнялась. Спираль эволюции ИТ сделала виток, место мейнфреймов заняли серверные и дата-центры, а распространение сервисной модели привело к появлению облаков.

Сегодня опять набирают силу процессы децентрализации. Не все вычисления целесообразно производить в облаке, некоторые лучше приблизить к анализируемому объекту и выполнять непосредственно на границе сети (Edge Computing), на конечных устройствах, которые становятся все более мощными и «умными». Вычисления снова делаются распределенными. Пользователи задействуют несколько облачных платформ (мультиоблако) и гибридные облака, ИТ-инфраструктура определяется программно, стремительно растет число подключенных к интернету устройств.

Архитектура предприятия

Архитектура предприятия становится самостоятельной дисциплиной со своей историей развития (рис. 1). Сформулировавший теоретические основы нового направления еще в 80-е Джон Захман из IBM разработал матрицу, в которой строки представляют собой различные уровни абстракции (перспективы), а наборы столбцов – представления (области) архитектуры (рис. 2).

Рис. 1. Эволюция ИТ-архитектур предприятия

Заполнение клеток матрицы Захмана помогает архитектору информационной системы решить проблемы разобщенности и несогласованности данных, возникающие при интеграции корпоративных систем или их отдельных модулей. В 2000-е гг. идеи Дж. Захмана вошли в международный стандарт по ИТ-архитектуре ISO-42010, переведенный на русский в виде ГОСТ Р 57100-2016.

Необходимость архитектурного подхода к построению информационных систем предприятий стала осознаваться и на государственном уровне. Первыми были США, где в 1996 г. был принят федеральный закон Клингера – Коэна, направленный на развитие и поддержание архитектуры информационных технологий (АИТ) федеральными агентствами для максимизации преимуществ использования ИТ в правительственных органах. На базе него стала создаваться общенациональная АИТ США.

Рис. 2. Матрица Захмана

В 90-х гг. прошлого века получила признание концепция многоуровневой архитектуры, выделения уровней представления, бизнеса, аппаратных средств, обработки и хранения данных. Разделяя систему на уровни абстракции, разработчики получили возможность вносить изменения на определенный слой без переработки системы в целом.

В начале 2000-х стала набирать популярность сервис-ориентированная архитектура (SOA), предполагающая использование независимых, вызываемых стандартным образом сервисов с четко определенными интерфейсами. Системы, основанные на SOA, независимы от технологий разработки и платформ. Сервисы, работающие на одних платформах, могут вызывать работающие на других, что облегчает повторное использование компонентов. Впоследствии на эти принципы опирались при проектировании архитектуры отдельных приложений – появилась микросервисная архитектура, которую удобно применять в сочетании с контейнеризацией.

Службы архитекторов предприятия

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

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

Например, архитектурный совет Сбербанка устанавливает стандарты по всем направлениям – по информационной, технической, интеграционной, прикладной архитектуре. Кроме того, в банке утвержден процесс управления архитектурой. Архитекторы разрабатывают стратегию ИТ как раздел стратегии предприятия. Для любого нового проекта рассматриваются текущая, промежуточная и целевая архитектуры.

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

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

Кубик архитектур

Матрица Захмана – взгляд на архитектуру предприятия с точки зрения организации работ. Но есть и другие подходы. Габриэль Бечара из компании Oracle-BEA предложил рассматривать четыре плана (уровня). Первый – основные бизнес-процессы предприятия. Упрощенный пример: население кладет деньги в банк на депозит, банк выдает эти деньги в виде кредитов, расплачивается с населением и сотрудниками, переводит акционерам прибыль. Этот уровень полностью определяется бизнесом.

Второй план – функциональный, определяющий основные блоки, связанные с различными направлениями деятельности организации. В примере с банком это блоки приема депозитов, получения денег через интернет, авторизации и зарплаты. За этот план отвечают бизнес- и ИТ- подразделения.

Третий план – план приложений, используемых для реализации функций. Например, программные модули АБС, «Банк – клиент», «Зарплата». Четвертый – технический, обеспечивающий работу приложений. За два последних плана отвечает служба ИТ.

Некоторые эксперты вместо функционального плана используют информационный, рассматривая работу предприятия с точки зрения движения информации. В последнее время возросли риски информационной безопасности и зависимости от поставщиков сторонних решений (санкции, барьеры для смены поставщика – vendor lock-in), поэтому в модель ИТ-архитектуры предприятия, по нашему мнению, целесообразно добавить планы «Безопасность» (отвечает служба ИБ) и «Независимость» (службы ИБ, ИT и главный архитектор). Кроме того, поскольку планы взаимозависимы, имеет смысл представить архитектуру предприятия в виде «кубика Рубика», каждая грань которого определяется точкой зрения на архитектуру (рис. 3).

При этом каждый квадратик грани, по сути, тоже «кубик Рубика». Так, АБС (план «Приложения») нужно рассматривать с точки зрения бизнеса (покупка неоправданно дорогой АБС разорит небольшой банк), функциональности, безопасности, требуемых аппаратных средств и зависимости от разработчиков. В разных областях бизнеса важных для архитектуры граней может быть меньше или больше. Например, для ЦОДа существенным для ИТ-архитектуры планом (гранью, уровнем) становится инженерная инфраструктура.

Рис. 3. Грани «кубика Рубика» ИТ-архитектуры предприятия

Техническая грань архитектуры предприятия

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

ИТ и диалектика Гегеля

ИТ-архитектура проекта сильно зависит от технологических ограничений, вносимых ее элементами – процессорами, памятью, системами хранения данных и сетевым оборудованием. Прежде всего, речь идет о скорости передачи данных. В 80-е годы прошлого века при низких скоростях передачи и обработки данных топология сети была максимально простой – все работали в дисплейных классах в непосредственной близости от мейнфрейма. Вычислительные мощности выросли и подешевели – пользователи пересели на персональные компьютеры. В 90-е десятимегабитный Ethernet сделал возможной коллективную работу, объединив персональные компьютеры в локальные сети. Повышение скорости передачи данных у телеком-провайдеров по выделенным линиям позволило создавать ИТ-архитектуры предприятий, охватывающие целые страны. Увеличение скорости доступа в интернет превратило во «всемирную деревню» всю планету.

Рост вычислительной мощности – фактор, способствующий децентрализации: многое можно посчитать на отдельном компьютере и на даже мобильном устройстве. Но увеличение разнообразия и сложности задач ведет к тому, что для решения специализированных задач выделяется все большее количество компьютеров (серверов, систем хранения данных и т.п.), которые размещаются в серверных и дата-центрах предприятий, а доступная высокая скорость внешних каналов способствует переносу вычислительной нагрузки в облако. То есть возврату к централизованной архитектуре, но на новом витке развития ИТ.

Облачные вычисления не стали «серебряной пулей» – для многих задач время отклика критично, да и весь трафик отправлять в дата-центр не всегда целесообразно. Нагрузку стали выносить на границу сети (Edge Computing), некоторые приложения вернулись в частное облако.

Эволюция идет в соответствии с диалектикой Гегеля – саморазвитие на основе взаимопроникновения противоположностей: процессов централизации – децентрализации, композиции – декомпозиции. Мейнфрейм – единственный «кирпич» архитектурного здания ИТ-системы 80-х – разбивается в 90-е на множество локальных серверов (декомпозиция). Затем серверы собираются в ЦОДы (композиция), а дальнейшее увеличение вычислительных мощностей позволяет вновь вернуть нагрузку на периферию (декомпозиция).

Можно прогнозировать, что использование квантовых компьютеров, которые сегодня трудно представить на рабочих столах пользователей, повернет спираль развития ИТ-архитектуры в сторону централизованных систем – уже сейчас доступ к некоторым квантовым вычислителям можно получить удаленно по сервисной модели. А неизбежное при массовом производстве удешевление сделает их впоследствии доступными и на предприятиях (декомпозиция).

Развитие серверной архитектуры

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

Примеры декомпозиции – переход к кластерной архитектуре с внешними СХД, вынос систем хранения (дисков) из серверных корпусов в отдельные устройства. Из корпусов вынимают и материнские платы и вставляют их как «лезвия» в блейд-корзины с общим блоком питания (блейд-серверы). Следующий шаг – компонуемая инфраструктура, когда программно выбираются не только лезвия, но и системы хранения данных и сетевые устройства. Иллюстрацией такого решения может служить платформа HPE Synergy.

ИТ-архитектура должна соответствовать современным требованиям бизнеса, быть гибкой. «Кирпичи» ИТ-архитектуры (процессоры, системы хранения и память), используемые в одном проекте, должны легко перебрасываться в другой. Особенно это важно в ЦОДах гиперскейлеров, где архитекторов-клиентов много и даже небольшой выигрыш в утилизации вычислительных ресурсов дает значительный экономический эффект.

Увеличение пропускной способности каналов с помощью технологий кремниевой фотоники в будущем может полностью «развязать» между собой установленные в стойке процессоры, память и СХД с тем, чтобы собирать из них любые произвольные программно определяемые инфраструктуры по требованию. В результате дезагрегации можно будет получить три независимых пула ресурсов – пул процессоров, пул памяти и пул систем хранения данных – и предоставлять их по сервисной модели разработчикам систем в режиме полноценного bare metal, удаленного гибкого самостоятельного выбора клиентом необходимых невиртуализированных вычислительных ресурсов.

Гибкость архитектуры ЦОДа могут обеспечить и крупные «кирпичи» – модульные блоки и контейнеры. Google строит дата-центры контейнерного типа с 2005 г., применение prefab-модулей помогло компании beCloud при создании Республиканского ЦОДа в Белоруссии за год пройти путь от чистого поля до готового объекта. Типовые prefab-ЦОДы выгодно использовать при выносе нагрузки на границу сети, и даже можно разместить кластер из контейнеров-микроЦОДов на спутниках.

Решение – космос

Выбор места вычислений – одна из важнейших задач разработки дизайна системы. При переносе вычислительной нагрузки из облака на край сети (Edge Computing) значительно уменьшается нагрузка на каналы связи с дата-центром и снижаются задержки передачи данных, существенные при работе в режиме реального времени. Становятся не нужны широкополосные дорогие каналы связи для быстрой передачи больших объемов информации, что критично для многих решений, например, использующих спутниковую связь. Да и само edge-облако можно разместить в космосе.

Это предлагает сделать калифорнийская компания Vector, анонсировавшая на прошедшей в Атланте конференции Citrix Synergy 2019 запуск до конца года программно определяемого спутника GSky-1. Цель проекта – развертывание на микроспутниках облачной платформы GalacticSky. Планируется предоставлять пользователям космические вычислительные мощности по сервисной модели.

Компания позиционирует решение как революционное, и с этим трудно не согласиться. Ракета-носитель Vector выводит на орбиту созвездие микроспутников, по сути – контейнерных микроЦОДов (длина контейнера менее метра), в каждом из которых работают до 16 виртуальных машин (процессоры Intel I5 и Intel I7, до 64 Гбайт ОЗУ, 1 Тбайт SSD). Спутники имеют каналы связи с Землей и друг с другом. Источником питания служат солнечные батареи (130 Вт), размещаемые на корпусе. На основе кластера микроспутников с одинаковыми орбитами разворачивается облачная платформа GalacticSky, использующая гипервизор Citrix.

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

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

Первый прототип, который будет использоваться для проверки функциональности GalacticSky, разработан Vector в сотрудничестве с Научно-исследовательским центром космической техники Южно-Калифорнийского университета. Как пройдет реальная эксплуатация космического микроЦОДа, покажет рассчитанная на 90 дней программа испытаний первого спутника.

В интервью нашему изданию вице-президент компании Vector Джон Метзгер пояснил, что космический ЦОД на микроспутниках может служить для обеспечения связи, проведения финансовых транзакций, наблюдения за космическими объектами, погодой и поверхностью Земли. Пользователи смогут отслеживать перемещения транспорта, например морских судов. Микроспутники можно использовать для навигации, поисковых и спасательных работ, причем с меньшими затратами на запуск и эксплуатацию, чем традиционные.

Виртуализация устройств

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

Сначала появились виртуальные машины, потом системы хранения и устройства сети. Облачные провайдеры стали предлагать виртуализированные ресурсы по сервисной модели, начали завоевывать популярность гиперконвергентные системы – программно определяемые вычислительные ресурсы, как правило, на серверах архитектуры x86.

На ИТ-инфраструктуру большое влияние будут оказывать технологии построения программно определяемых функций на базе стандартных серверов архитектуры x86, включая вычисления, хранение, коммутацию и резервное копирование. Дальнейшее развитие архитектуры ИТ-инфраструктур пойдет по модели гиперконвергенции. Именно такая модель позволяет в полной мере раскрыть потенциал программно определяемых функций и микросервисов, обеспечивая при этом необходимую экономическую эффективность.

Владимир Рубанов, управляющий директор, «Росплатформа»

Следующим шагом развития систем виртуализации стало появление контейнеров и бессерверных вычислений (serverless computing) – запуск в контейнере приложений, ничего не знающих о вычислительных мощностях, на которых они запускаются. Все вопросы предоставления необходимых для работы ресурсов решаются автоматически на стороне облачного провайдера.

Виртуализация плохо работает в случае высоконагруженных приложений. Один из способов решения проблемы – обратная виртуализация, т.е. объединение ресурсов отдельных стандартных серверов в единый программно определяемый сервер (ПОС), количественные показатели которого могут легко модифицироваться в зависимости от нагрузки (подробнее см. «ИКС» № 2’2019, с. 67).

Стремительными темпами развиваются системы хранения данных. Наибольшей популярностью пользуются реляционные СУБД, но все шире используются фреймворки для массовой параллельной обработки неструктурированных данных (Hadoop, Spark) – ключевых решений технологий больших данных. Дезагрегация стала применяться и для структурированных данных. Так, Oracle Sharding разделяет базу данных на ферму независимых баз данных для снятия ограничений в масштабируемости и доступности при использовании одной БД.

Основное направление развития современных ИT-инфраструктур – это распределенные (возможно, даже децентрализованные) системы и отказ от внешнего облачного сервиса с объединением всех устройств пользователя в одноранговую сеть. Этот подход обеспечивает достаточный уровень безопасности хранения данных с точки зрения их резервного копирования, вместе с тем пользователь не передает свои данные на хранение третьим лицам.

Алексей Архипов, директор по развитию криптотехнологий, ГК Qiwi

Дезагрегация в виде использования внешних библиотек давно существует на уровне программ. В наше время все большую популярность приобретает микросервисная архитектура (Cloud Native). Вычислительные ресурсы уходят в облако – туда же перемещается разработка программ, опирающаяся на облачные платформенные решения (PaaS). Упрощается и сам процесс разработки, которую могут теперь вести не только профессиональные программисты, но и специалисты в конкретных областях, задействуя знакомые им категории разработки.

 «Инженерка» становится ИТ-инфраструктурой

Еще в начале 2000-х инженерная инфраструктура предприятия – системы, обеспечивающие электропитание вычислительной нагрузки и отвечающие за отвод тепла, – не воспринималась как часть ИТ-архитектуры. Изменения произошли недавно и наиболее ярко проявились в ЦОДах. Инженерные системы дата-центров становятся все более «умными». Появилось, в частности, программно определяемое электропитание (SD-Power). Такие системы в рабочее время, когда тарифы на электроэнергию максимальны, питают оборудование ЦОДа электричеством от батарей ИБП и переходят на магистральное электричество для полезной нагрузки и зарядки батарей ночью при сниженных тарифах. На климатические системы устанавливаются контроллеры, экономящие ресурсы при отводе тепла. ИТ-системы начинают использоваться и в средствах обеспечения безопасности вычислительных систем, например, в системах пожаротушения. Границы между инженерными и ИТ-инфраструктурами все больше размываются: инженерные системы подключаются в общую ИТ-сеть и становятся частью ИТ-архитектуры в качестве периферийных устройств, подобно принтерам и сканерам. Эта тенденция получит дальнейшее развитие, в инженерные системы все чаще будут встраивать модули автоматизации на основе микроконтроллеров и специализированных программ, включая системы искусственного интеллекта.

ИБ и независимость

Несколько слов о других гранях кубика. Первоначально на предприятиях развертывались автоматизированные системы физической безопасности (видеонаблюдение, СКУД), никак не связанные с ИТ-системами. Сегодня это узлы информационной системы, в которые все чаще встраиваются элементы искусственного интеллекта. Безопасность рассматривается как часть ИТ-архитектуры, пронизывающая все уровни системы – от установленных микропроцессоров до бизнес-уровня предприятия. Система ИБ начинает создаваться на стадии разработки проекта, а не является внешней надстройкой над уже готовым ИТ-решением, и эта тенденция будет в дальнейшем усиливаться. При этом никуда не деться от обеспечения информационной безопасности бизнес-процессов, аппаратных и программных средств. Решения будут все более интегрированными, будут включать анализ всех возможных векторов атак.

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

Юрий Петров, независимый эксперт

Риски -- это не только атаки хакеров, но и зависимость от поставщиков решений.

После начала войны санкций в 2014 г. активизировалось движение в направлении импортозамещения. Запрет американским компаниям сотрудничать с Huawei, санкции Японии против Южной Кореи, отзыв британской компанией ARM лицензии на свою процессорную архитектуру у Huawei, поставивший под удар разработки китайских процессоров, показали, что тема зависимости ИТ-архитектуры от геополитики актуальна не только для нашей страны.

На уровне предприятия зависимость от поставщиков ИТ-решений выливается в необоснованное повышение цен на их услуги. Предприятию удобно иметь одного вендора, занимающегося подбором «кубиков» и согласованием работы их граней, но нужно сохранять баланс, иметь внутреннюю экспертизу по развернутым решениям и возможность замены поставщика. Самый независимый от вендора путь – разработка собственного ПО – является и самым затратным и в полном масштабе невыполним.

Тенденцией становится использование продуктов Open Source, снижающее риски зависимости от лицензий. Общее направление – уменьшение зависимости от вендоров путем диверсификации поставщиков, сокращение доли проприетарных решений, внедрение своих разработок (импортозамещение), продуктов Open Source и создание команд, обладающих экспертизой по их поддержке.

Мы попытались посмотреть на архитектуру предприятия с точки зрения ИТ и проанализировать тенденции в развитии технологического уровня. Кубиков и их граней может быть больше, например, к архитектуре можно подходить с точки зрения удобства для пользователя, простоты и стоимости поддержки. Можно рассмотреть технологический слой на более низком уровне: архитектур микропроцессов, сетевых протоколов, аппаратных средств хранения информации. Выбор зависит от важности того или иного «кубика» для бизнеса конкретного предприятия.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!