Даже если вы объединяете сети и инфраструктуры хотя бы двух продуктовых магазинов, это легко может вылиться в непростую задачу. Внезапно всплывут разные нюансы, связанные с организацией сети — например, с замурованным в неизвестной подсобке D-Link'ом, который работает, делая вид, что он ядро сети. Когда речь идет о компаниях масштаба ВТБ и ВТБ24, все выходит на новый уровень — прибавляются требования со стороны огромного количества отделов, руководителей, служб безопасности… О том, как мы с этим справились, расскажем под катом.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/6d0/390/ea1/6d0390ea136c8556845a264157f65727.jpg)
Итак, перед нами стояла задача объединить инфраструктуры нескольких крупных компаний в условиях приличного набора legacy-инструментов, капризных к архитектуре.
В основу созданной инфраструктуры лег «ресурсный лес» — система, объединяющая мессенджер, единую адресную книгу, портал, файловый сервис и другие ключевые ресурсы. Изначально ресурсный лес задумывался как фреймворк для взаимодействия различных юрлиц, состоящих в одной банковской группе. Для объединения группы компаний такой вариант оказался оптимальным.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/efe/b7c/c95/efeb7cc95861bc82397c4a56b09aadc9.png)
Технически нужно было решить две задачи: создать общий сетевой сегмент, где будут размещаться сервисы, и обеспечить единую доменную аутентификацию. И все это — безболезненно и не нарушая режим работы банков.
Все сегменты сети маршрутизируются на территориях двух ЦОД, и инженерам нужно было объединить ресурсы. Для каждого банка создали отдельный сегмент с прозрачной маршрутизацией, а файрволы поставили уже на границе между этими сегментами и внутренними ресурсами самих компаний.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/287/650/ac6/287650ac6609235c7c2b418b002a12ba.jpg)
Ресурсный лес подразумевает отдельный домен и наличие трастовых отношений с участниками группы. К счастью, нам удалось найти пул сетевых адресов, который у всех объединяемых банков не пересекается с локальными. В итоге на площадках двух дата-центров все сегменты каждого из банков прозрачно взаимодействуют в едином адресном пространстве. Такая многослойная структура помогает обеспечить максимально прозрачную маршрутизацию.
Бывает, что серверу приложений необходимо подключиться к клиенту, инициировав call-back в сторону его машины. Клиентом может быть какая-нибудь рабочая станция со своей периферией, например, видеокамерой. В банке есть некоторое количество надежных, но уже не новых legacy-приложений, которым требуется такая возможность. Мы заложили в архитектуру прозрачный call-back доступ — это дает безболезненную совместимость с унаследованными системами и поможет впоследствии поэтапно отойти от legacy, не сломав текущую функциональность.
Единое адресное пространство также позволило нам избежать нестандартных обходных решений при работе с Active Directory, связанных с тем, что Microsoft официально не поддерживает создание доверительных отношений между независимыми серверами при наличии NAT. Мы пробовали в тестовом режиме работать в нескольких адресных пространствах, но решили отказаться от не поддерживаемого официально варианта реализации.
Самое интересное — это как мы организовали маршрутизацию. Ломали голову долго, но в итоге все получилось достаточно просто. Сегменты каждого банка в инфраструктурном ядре — это растянутые по MPLS’у VPN, которые присутствуют на двух площадках. Мы планировали организовать между ними маршрутизацию через политики импорта/экспорта меток MPLS. Но вместе эти компоненты работать слаженно отказывались, поскольку на разных площадках у нас разное оборудование. Если писать по каждой проблеме в техподдержку вендора, можно сорвать все возможные сроки проекта (а они в нашем случае были весьма сжатыми). Все это нас совершенно не устраивало. В итоге мы просто сделали между VPN отдельные физические линки.
Еще одной сложностью была настройка правил фильтрации маршрутов между двумя площадками — в процессе объединения VPN-сетей есть вероятность возникновения непредвиденных «петель», которые чреваты падением сетевой инфраструктуры.
Чтобы упростить доступ к сервисам компаний из любого уголка «ресурсного леса», мы реализовали концепцию «витрин данных».
Каждый из банков публикует в своем сетевом сегменте набор прокси для доступа к своим задачам. То есть в витрине каждый банк публикует те приложения, которые необходимо использовать совместно с другими участниками. Например, ВТБ24 вынес в свой сегмент шлюз для доступа в их VDI.
После активации шлюза на файрволе открываются соответствующие правила, и у пользователей, подключенных к «лесу», появляется возможность работать за виртуальными рабочими местами ВТБ24. Мы выделили «витрины» для терминальных и веб-приложений. Терминальные приложения публикуются на Citrix-ферме, а для веба применяется технология, которая уже много лет используется в банке. С ней интегрировано порядка 70 приложений. Построена она на базе продукта Oracle Access Manager.
С приложениями других банков всё пока гораздо сложнее, так как они не интегрированы с Access Manager. Поэтому было решено поставить витрины, работающие в режиме reverse proxy.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/057/57e/fe9/05757efe94cf71257b64bd38b20b46ed.jpg)
Еще одним обязательным условием оказалась доменная аутентификация, которую запрашивает витрина. Для корректного пробрасывания через нее был выбран HAProxy – свободное ПО, входящее в комплектацию Red Hat Enterprise Server. Это отличный готовый продукт, с помощью которого можно делать как реверсные HTTP Proxy, так и прокси многих других вещей. Проксировать можно не только HTTP-, но и любой другой трафик, в том числе закрытых протоколов, которые используются в приложении для обмена данными.
Другая важная задача, которую мы сейчас решаем, — это приведение к единому стандарту системы коммуникации в наших компаниях. При всей своей консервативности банковский сектор требует очень быстрого принятия решений и отлаженных коммуникаций. Сейчас мы стали использовать Skype for Business. Основные работы по развертыванию уже почти завершены.
Между отдельными серверами со Skype есть федеративные отношения, то есть доверенные отношения между независимыми равноправными серверами. Благодаря объединению и синхронизации учетных записей теперь можно легко найти контакт сотрудника для связи. Skype for Business интегрирован с телефонией и ВКС. Можно по PSTN позвонить на обычный телефонный аппарат со Skype и обратно, если для сотрудника заведен номер в аккаунте Skype. При наличии гарнитуры и видеокамеры можно со своего рабочего места через Skype for Business позвонить в переговорную комнату. Естественно, все виды связи должны соответствовать жестким стандартам безопасности.
Помимо специфических задач, связанных с функционированием банков как коммерческих структур, в новой архитектуре мы попутно решили очень много насущных проблем. Например, синхронизацию паролей, учетных записей и почты.
Новая архитектура с ресурсным лесом — это некий фреймворк, фундамент для дальнейшего информационного обмена с дочками группы. Сюда входят как приложения (например, почта), так и, скажем, доступ к порталу с контактами. В дальнейшем на основе новой архитектуры будут формироваться стандартизированные наборы требований для подключения к платформе, например, дочерних банков. Это поможет упростить всю процедуру.
Сейчас мы постарались предусмотреть все возможные нюансы развития архитектуры и тем самым обеспечить отсутствие проблем с интеграцией в будущем.
![](https://habrastorage.org/getpro/habr/post_images/6d0/390/ea1/6d0390ea136c8556845a264157f65727.jpg)
Итак, перед нами стояла задача объединить инфраструктуры нескольких крупных компаний в условиях приличного набора legacy-инструментов, капризных к архитектуре.
В основу созданной инфраструктуры лег «ресурсный лес» — система, объединяющая мессенджер, единую адресную книгу, портал, файловый сервис и другие ключевые ресурсы. Изначально ресурсный лес задумывался как фреймворк для взаимодействия различных юрлиц, состоящих в одной банковской группе. Для объединения группы компаний такой вариант оказался оптимальным.
![](https://habrastorage.org/getpro/habr/post_images/efe/b7c/c95/efeb7cc95861bc82397c4a56b09aadc9.png)
Технически нужно было решить две задачи: создать общий сетевой сегмент, где будут размещаться сервисы, и обеспечить единую доменную аутентификацию. И все это — безболезненно и не нарушая режим работы банков.
Сетевая инфраструктура
Все сегменты сети маршрутизируются на территориях двух ЦОД, и инженерам нужно было объединить ресурсы. Для каждого банка создали отдельный сегмент с прозрачной маршрутизацией, а файрволы поставили уже на границе между этими сегментами и внутренними ресурсами самих компаний.
![](https://habrastorage.org/getpro/habr/post_images/287/650/ac6/287650ac6609235c7c2b418b002a12ba.jpg)
Ресурсный лес подразумевает отдельный домен и наличие трастовых отношений с участниками группы. К счастью, нам удалось найти пул сетевых адресов, который у всех объединяемых банков не пересекается с локальными. В итоге на площадках двух дата-центров все сегменты каждого из банков прозрачно взаимодействуют в едином адресном пространстве. Такая многослойная структура помогает обеспечить максимально прозрачную маршрутизацию.
Бывает, что серверу приложений необходимо подключиться к клиенту, инициировав call-back в сторону его машины. Клиентом может быть какая-нибудь рабочая станция со своей периферией, например, видеокамерой. В банке есть некоторое количество надежных, но уже не новых legacy-приложений, которым требуется такая возможность. Мы заложили в архитектуру прозрачный call-back доступ — это дает безболезненную совместимость с унаследованными системами и поможет впоследствии поэтапно отойти от legacy, не сломав текущую функциональность.
Единое адресное пространство также позволило нам избежать нестандартных обходных решений при работе с Active Directory, связанных с тем, что Microsoft официально не поддерживает создание доверительных отношений между независимыми серверами при наличии NAT. Мы пробовали в тестовом режиме работать в нескольких адресных пространствах, но решили отказаться от не поддерживаемого официально варианта реализации.
Самое интересное — это как мы организовали маршрутизацию. Ломали голову долго, но в итоге все получилось достаточно просто. Сегменты каждого банка в инфраструктурном ядре — это растянутые по MPLS’у VPN, которые присутствуют на двух площадках. Мы планировали организовать между ними маршрутизацию через политики импорта/экспорта меток MPLS. Но вместе эти компоненты работать слаженно отказывались, поскольку на разных площадках у нас разное оборудование. Если писать по каждой проблеме в техподдержку вендора, можно сорвать все возможные сроки проекта (а они в нашем случае были весьма сжатыми). Все это нас совершенно не устраивало. В итоге мы просто сделали между VPN отдельные физические линки.
Еще одной сложностью была настройка правил фильтрации маршрутов между двумя площадками — в процессе объединения VPN-сетей есть вероятность возникновения непредвиденных «петель», которые чреваты падением сетевой инфраструктуры.
Уровень приложений
Чтобы упростить доступ к сервисам компаний из любого уголка «ресурсного леса», мы реализовали концепцию «витрин данных».
Каждый из банков публикует в своем сетевом сегменте набор прокси для доступа к своим задачам. То есть в витрине каждый банк публикует те приложения, которые необходимо использовать совместно с другими участниками. Например, ВТБ24 вынес в свой сегмент шлюз для доступа в их VDI.
После активации шлюза на файрволе открываются соответствующие правила, и у пользователей, подключенных к «лесу», появляется возможность работать за виртуальными рабочими местами ВТБ24. Мы выделили «витрины» для терминальных и веб-приложений. Терминальные приложения публикуются на Citrix-ферме, а для веба применяется технология, которая уже много лет используется в банке. С ней интегрировано порядка 70 приложений. Построена она на базе продукта Oracle Access Manager.
С приложениями других банков всё пока гораздо сложнее, так как они не интегрированы с Access Manager. Поэтому было решено поставить витрины, работающие в режиме reverse proxy.
![](https://habrastorage.org/getpro/habr/post_images/057/57e/fe9/05757efe94cf71257b64bd38b20b46ed.jpg)
Еще одним обязательным условием оказалась доменная аутентификация, которую запрашивает витрина. Для корректного пробрасывания через нее был выбран HAProxy – свободное ПО, входящее в комплектацию Red Hat Enterprise Server. Это отличный готовый продукт, с помощью которого можно делать как реверсные HTTP Proxy, так и прокси многих других вещей. Проксировать можно не только HTTP-, но и любой другой трафик, в том числе закрытых протоколов, которые используются в приложении для обмена данными.
Другая важная задача, которую мы сейчас решаем, — это приведение к единому стандарту системы коммуникации в наших компаниях. При всей своей консервативности банковский сектор требует очень быстрого принятия решений и отлаженных коммуникаций. Сейчас мы стали использовать Skype for Business. Основные работы по развертыванию уже почти завершены.
Между отдельными серверами со Skype есть федеративные отношения, то есть доверенные отношения между независимыми равноправными серверами. Благодаря объединению и синхронизации учетных записей теперь можно легко найти контакт сотрудника для связи. Skype for Business интегрирован с телефонией и ВКС. Можно по PSTN позвонить на обычный телефонный аппарат со Skype и обратно, если для сотрудника заведен номер в аккаунте Skype. При наличии гарнитуры и видеокамеры можно со своего рабочего места через Skype for Business позвонить в переговорную комнату. Естественно, все виды связи должны соответствовать жестким стандартам безопасности.
Помимо специфических задач, связанных с функционированием банков как коммерческих структур, в новой архитектуре мы попутно решили очень много насущных проблем. Например, синхронизацию паролей, учетных записей и почты.
Перспективы
Новая архитектура с ресурсным лесом — это некий фреймворк, фундамент для дальнейшего информационного обмена с дочками группы. Сюда входят как приложения (например, почта), так и, скажем, доступ к порталу с контактами. В дальнейшем на основе новой архитектуры будут формироваться стандартизированные наборы требований для подключения к платформе, например, дочерних банков. Это поможет упростить всю процедуру.
Сейчас мы постарались предусмотреть все возможные нюансы развития архитектуры и тем самым обеспечить отсутствие проблем с интеграцией в будущем.