Примеры сложной топологии для Azure DevOps Server
Вы можете настроить Azure DevOps Server в одной из нескольких конфигураций топологии. Как правило, чем проще топология, тем проще поддерживать развертывание Azure DevOps Server. Необходимо развернуть простую топологию, которая соответствует вашим бизнес-потребностям.
В этой статье описываются две сложные топологии Azure DevOps Server. Сложная топология содержит Azure DevOps Server компоненты, распределенные по нескольким серверам. Доступ к нему осуществляется клиентами в нескольких доменах в географически удаленных физических расположениях. Прокси-сервер Azure DevOps устанавливается в дополнение к дополнительным компонентам, таким как продукты SharePoint и SQL Server Reporting Services. Существует несколько разных баз кода, и каждая из них имеет собственную коллекцию проектов для проектов, использующих их. Базы данных для коллекций командных проектов хранятся на нескольких разных серверах, работающих SQL Server.
Сложная топология с одним доменом
Сложная топология серверов использует несколько серверов в кластерах или других конфигурациях отработки отказа для размещения логических данных Azure DevOps и компонентов уровня приложений. На следующей схеме показана сложная топология с одним доменом:
В этом примере топология аналогична умеренной топологии. Azure DevOps Server службы развертываются на одном сервере, а базы данных Azure DevOps Server устанавливаются на отдельном сервере с team Foundation Build и агентами тестирования команды и контроллерами агентов тестирования, развернутыми на дополнительных серверах. Кроме того, добавлены компоненты отработки отказа. Базы данных Azure DevOps установлены в кластере SQL Server.
На схеме примера показаны дочерние домены в Сиэтле и Кливленде с двусторонним транзитивным доверием к родительскому домену. Учетная запись службы для Azure DevOps Server является доверенной в обоих доменах. Каждый географически удаленный дочерний домен использует подключение с ограниченной пропускной способностью. Так как получение зачисления из компонента управления кодом версии Azure DevOps Server может занять очень много времени в таких условиях ограниченной пропускной способности, прокси-сервер Azure DevOps устанавливается в каждом дочернем домене для работы в качестве кэша прокси-сервера управления версиями. Все клиентские запросы переходят непосредственно на уровень приложений, за исключением кода управления версиями, получают запросы. Эти запросы направляются через прокси-сервер Azure DevOps, который затем кэширует все исходные файлы, скачиваемые на прокси-сервере.
Топология в этом примере также связана с отказоустойчивостью и высокой производительностью. Отказоустойчивость уровня данных обеспечивается благодаря преимуществам технологий кластеризации SQL Server. Несколько веб-приложений SharePoint настраиваются для использования проектами в коллекциях в веб-ферме SharePoint. Базы данных коллекции проектов распределяются между SQL Server экземплярами для повышения производительности и простоты индивидуального управления. SQL Server Reporting Services и SQL Server analysis Servers работают на отдельных серверах для повышения производительности.
Этот пример предназначен для большой группы разработчиков продуктов с 2000 пользователями.
Сложная многодоменная топология
Сложная топология серверов с несколькими доменами использует несколько серверов в двух или более доменах. Как и в случае с сложной топологией с одним доменом, развертывание использует кластеры или другие конфигурации отработки отказа для размещения компонентов уровня данных для Azure DevOps. Администраторы этого развертывания настроили балансировку сетевой нагрузки и добавили несколько серверов уровня приложений для распределения рабочей нагрузки. На следующем рисунке показана сложная топология с несколькими доменами:
Как и в приведенном выше примере, эта топология настроена для отказоустойчивости и высокой производительности. Кроме того, эта топология распределяется по нескольким доменам, некоторые из которых являются полностью доверенными дочерними доменами родительских доменов, но один из которых (IsolatedLab.com) является полностью отдельным доменом. Учетные записи служб, используемые Azure DevOps Server, являются полностью доверенными членами всех доменов, и учетные записи пользователей были настроены как в родительском домене, так и в отдельном домене при необходимости для пользователей, которые должны работать в обоих доменах. Брандмауэры настроены для разрешения трафика через порты, необходимые для Azure DevOps Server.
Похожие статьи
Топологии компьютерных сетей
Топология КС — это схема соединения компьютеров в сеть.
Существуют четыре основные топологии: шинная, кольцевая, звездообразная, коммутируемая. Шинная топология – это соединение всех сетевых узлов одним кабелем с разомкнутыми концами.
Конец кабеля должен заканчиваться специальной заглушкой с резистором.
Этот кабель в данной топологии называют шиной. Все подключенные устройства прослушивают трафик (поток сигналов) шины и принимают только те пакеты сигналов, которые адресованы им. Затраты на развертывание такой одноранговой сети весьма невелики. Однако эта сеть имеет ограниченные функциональные возможности, малое расстояние соединения. Поэтому она применяется сейчас лишь для домашних сетей и сетей небольших офисов.
Кольцевая топология. Первоначально это была схема буквально кольцевого соединения ПК (кольцо на физическом уровне). Недостаток такого соединения в том, что при выходе из строя даже одной рабочей станции сеть прекращает функционировать. В целом одноранговая кольцевая топология сети была признана неработоспособной. Однако применение ретранслирующего концентратора привело к продлению жизни технологии кольцевого соединения. Однако термин «кольцевая топология» применима к этим сетям только на логическом уровне. Физическое соединение компонентов звездообразное, а метод доступа при этом — циклическое обслуживание, т.е кольцо виртуальное.
Физическое кольцо Логическое кольцо
Топология Token Ring появилась в середине 70-х и опиралась на технологии корпорации IBM. Достоинством этой технологии является определенность времени, за которое будут данные доставлены адресату. Поэтому в случаях, когда существенным является требование своевременной доставки данных, эта архитектура долгое время была единственным конкурентоспособным решением. Однако теперь появились новые конкурентоспособные решения, и эта технология постепенно уходит на задний план.
Топология типа «звезда»
В центре такого соединения находится концентратор, а его лучи – соединения с устройствами. Эти устройства, в отличие от кольцевой технологии, имеют право независимого друг от друга доступа к среде передачи. Причины широкой популярности звездообразных топологий – гибкость в применении этой конфигурации, возможность расширения, надежность, относительно низкая стоимость в сравнении с топологией Token Ring. Эта топология сделала шинные и кольцевые топологии принципиально устаревшими
Рис. 21 Пример реализации топологии типа «звезда» в компьютерной сети малого офиса
Коммутируемая топология
При такой топологии физически устройства соединяются с коммутатором (переключателем –switch’ем). Внешне эта топология похожа на звезду. Однако действительно коммутатор создает лишь временное соединение между отправителем порции данных и получателем на момент передачи этой порции данных. Для этого коммутатор держит в памяти адреса всех устройств сети. Поскольку каждое соединение используется лишь для передачи его данных, то для передачи может использоваться вся пропускная способность соединения канала. Таким образом коммутаторы повышают производительность сети в целом.
Сложные топологии
Последовательная цепочка — последовательное соединение концентраторов сети (звезд). Допустимый максимальный размер сети определяется максимальным диаметром сети – произведение допустимого расстояния между устройствами на количество устройств. Однако проблемы возникают обычно еще до достижения максимального диаметра. Эту топология рекомендуют использовать в сетях с ограниченным количеством концентраторов.
Сеть и ее топология должны выбираться с учетом будущего развития. Топология ЛС является одним из самых критичных факторов, влияющих на производительность. Основным критерием выбора топологии являются требования пользователей к производительности.