В этой лекции описан общий подход к развертыванию Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) , а также основные решения, которые необходимо принимать при развертывании TFS в организации. В лекции рассказывается о двух вариантах развертывания и объясняется, как выбрать между двумя этими вариантами.
Два этих варианта - односерверная и раздельная установка. В первом случае уровень данных и уровень приложений размещаются на одном сервере. Во втором случае эти уровни размещаются на разных серверах. Кроме того, вы вольны установить на отдельных компьютерах сервер сборки и прокси управления исходным кодом. Доступ к этим серверам требуется каждому клиенту, и потому на клиентской стороне необходимо установить соответствующие инструменты.
Архитектура TFS показана на рис.16.1.
(рис 16.1) Архитектура TFS С точки зрения архитектуры TFS разделен на три уровня - уровень данных ( data ), уровень приложений ( application ) и клиентский уровень ( client ). Разделение это логическое, и все три уровня вполне можно установить на одном и том же компьютере.
На уровне данных Team Foundation находится Microsoft SQL Server™ 2005. С ним устанавливается ряд баз данных для хранения рабочих элементов, версий, результатов испытаний и любых отчетов.
На уровне приложений содержатся веб-интерфейс, встроенный в Internet Information Services (IIS) , веб-службы Team Foundation и службы Microsoft Office SharePoint®. Также на уровне приложений находятся серверы сборки и прокси управления исходным кодом.
На клиентском уровне находятся приложения, осуществляющие доступ к TFS. Разработчики используют для подключения к Team Server обозреватель Team Explorer, установленный как самостоятельное приложение или как часть Visual Studio 2005. Менеджеры проекта пользуются Microsoft Office Excel® или Microsoft Office Project. Для подключения к серверу можно применять и инструменты сторонних разработчиков.
Подробнее - в лекции 2.
Существуют следующие способы развертывания TFS:
Microsoft Active Directory®.В этом варианте создается рабочая группа без использования контроллера домена Active Directory. Такой подход удобен в небольших коллективах. Для подключения к серверу каждому пользователю необходима локальная учетная запись на нем. При использовании рабочих групп раздельное развертывание не поддерживается.
Если вы используете Active Directory, вам доступны оба варианта развертывания. Вы вольны установить уровни данных и приложений как на одном, так и на нескольких серверах.
Чтобы выбрать вариант развертывания, максимально отвечающий потребностям вашей организации, ответьте на следующие вопросы:
TFS на нескольких серверах. Каждый экземпляр TFS способен поддерживать до 5000 проектов. Если у вас более 5000 проектов, одним экземпляром Team Foundation Server вам не обойтись.TFS компьютер не должен выполнять никакие иные функции, то есть, не должен быть почтовым сервером, файловым сервером или сервером баз данных для других приложений.У односерверного развертывания есть следующие преимущества:
TFS управляются на одном сервере.У раздельного развертывания есть следующие преимущества:
Типичное развертывание с одним сервером показано на рис.16.2. На сервере установлены уровни данных и приложений TFS, а также SharePoint Services и SQL Server 2005.
(рис 16.2) Типичное развертывание с одним сервером
Типичный вариант развертывания с несколькими серверами показан на рис.16.3. Уровень приложений TFS установлен совместно с SharePoint Services. На другом компьютере размещены уровень данных TFS и SQL Server 2005.
(рис 16.3) Типичное раздельное развертывание
Как в односерверном, так и в раздельном варианте вы вольны установить также сервер сборки и прокси-сервер. Их можно установить как на том же сервере, что и уровень приложений, так и на других серверах.
Чтобы повысить производительность сборки и снизить нагрузку на уровень приложений, разместите службы сборки на отдельном сервере. Например, это нужно сделать, если сборки планируется проводить достаточно часто.
Прокси-сервер Team Foundation кеширует копии файлов, включенных в систему управления исходным кодом. Используйте прокси-сервер, если вы обращаетесь к серверу управления исходным кодом по сети и испытываете проблемы с ее быстродействием.
Выбрав вариант установки, вы должны затем выбрать одну из нескольких топологий. К вашим услугам как простые, так и сложные топологии - для команд самых различных размеров.
На рис.16.4 показана самая простая топология TFS - уровни приложений и данных развернуты на одном и том же сервере. Прокси-сервер TFS развернут на отдельном сервере. Доступ к серверу имеется с клиентских рабочих станций в том же домене.
Эта конфигурация подходит для команд разработчиков и для пилотных проектов с числом пользователей не более 400.
(рис 16.4) Простая топология TFS
На рис.16.5 показан вариант с топологии с разделением уровней. Службы приложений развернуты на одном сервере, базы данных - на другом.
(рис 16.5) Топология TFS умеренной сложности На рис.16.5 показано также испытательное оборудование и серверы сборки, развернутые на отдельных узлах. Клиентские узлы находятся либо в том же домене, что и серверы, либо в доменах, которые связаны с серверами отношениями доверия. Топологии этого уровня сложности уместны в больших командах разработки с количеством пользователей от 400 до 2000.
Сложная топология, показанная на рис.16.6, близка к предыдущему случаю. Однако теперь в нее добавлены компоненты отказоустойчивости - резервный сервер уровня приложений и уровень данных с использованием технологий кластеризации SQL.
(рис 16.6) Сложная топология TFS Кроме того, на рис.16.6 показан географически удаленный дочерний домен, связанный с основным доменом при помощи низкоскоростного соединения. Клиенты в этом домене для более эффективного доступа к системе управления исходным кодом используют прокси-сервер TFS.
При развертывании TFS учитывайте следующее:
Планируя установку и развертывание Team Foundation Server, вы должны среди прочего решить, как будете управлять архивацией серверов и их восстановлением после сбоев. Выбор соответствующих стратегий определяется размером системы и доступными ресурсами. Поскольку уровень данных опирается на SQL Server 2005, подбор стратегии зависит от того, какой подход к архивации SQL Server вы в данный момент используете.
Если вы используете зеркалирование или кластеризацию SQL Server 2005, тот же самый подход можно применить и к уровню данных TFS. Вам также предстоит решить, как поступать в случае сбоя на сервере уровня приложений. Чтобы добиться отказоустойчивости, подготовьте резервный сервер уровня приложений и обеспечьте возможность быстрого переключения на него.
Выбирая стратегию установки архивации и восстановления TFS, учитывайте следующие соображения:
Как правило, небольшие команды с незначительным числом проектов могут работать в односерверной среде, тогда как большим командам необходима раздельная установка и более быстрое оборудование. Выбор между односерверной и раздельной установкой влияет также на механизмы архивации и восстановления после сбоев.
Таб.16.1 поможет вам решить, какой вариант установки стоит выбрать и какое оборудование использовать.
| Конфигурация | Уровень | ЦП | Жесткий диск | Память |
|---|---|---|---|---|
| Один сервер, менее 20 пользователей | Сервер уровня приложений и данных | Одиночный процессор, 2,2 ГГц | 8 Гб | 1 Гб |
| Один сервер; от 20 до 100 пользователей | Сервер уровня приложений и данных | Двойной процессор, 2,2 ГГц | 30 Гб | 2 Гб |
| Несколько серверов; от 100 до 250 пользователей | Сервер уровня приложений | Одиночный процессор, 2,2 ГГц | 20 Гб | 1 Гб |
| Сервер уровня данных | Двойной процессор, 2,2 ГГц | 80 Гб | 2 Гб | |
| Несколько серверов; от 250 до 2000 пользователей | Сервер уровня приложений | Двойной процессор, 2,8 ГГц | 40 Гб | 4 Гб |
| Сервер уровня данных | Счетверенный процессор, 2,7 ГГц | Накопитель прямого подключения, 14 000-15 000 RPM RAID 0 | 16 Гб |
Выбирая стратегию архивации и восстановления, необходимо, конечно, учитывать, какой ущерб вашей команде будет нанесен в результате выхода из строя конкретного сервера.
Планирование стратегии архивации является частью плана развертывания TFS. Учитывайте следующие соображения:
Вы вольны использовать ту же методику архивации, что используете для любой БД SQL Server 2005. Восстановление TFS из архивов проводится по одному из трех сценариев:
Восстановление только данных применяется в случае сбоя на уровне данных. С помощью архивных данных и журналов вы полностью восстановите БД. Восстановление серверов требуется при их выходе строя. В этом случае вы можете восстановить полную БД на втором компьютере.
На серверах уровня приложений нет никаких данных, которые нуждались бы в архивации, но это не делает их неуязвимыми. Чтобы минимизировать последствия сбоя, подумайте о подготовке "теплого" резервного сервера, на который можно было бы оперативно переключиться.
Оценивая необходимость отказоустойчивого решения для TFS, принимайте во внимание стоимость оборудования для резервных серверов и сопоставляйте ее с возможными потерями от временной недоступности TFS. Обеспечение отказоустойчивости повышает сложность установки и накладные расходы на ее обслуживание. Не забудьте включить обслуживание в свои расчеты.
Особенно велики затраты на создание и обслуживание кластеров, поэтому кластеризацию рекомендуется использовать лишь в тех случаях, когда ресурсы для создания кластера в вашей организации уже имеются.
С зеркалированием также связаны расходы, но они несравнимы с расходами на кластеризацию. Причем в этом случае у вас появляется возможность временно отключить основной сервер, скажем, для мелких ремонтных работ. Подумайте о зеркалировании, если ваша организация может позволить себе установку и обслуживание второго сервера уровня данных.
Если у вашей организации есть необходимые ресурсы, создайте кластер с выделенными серверами. Кластер обеспечит непрерывный доступ к уровню данных. Правда, за это придется заплатить высокую цену с точки зрения как создания, так и обслуживания кластера.
Работая в кластере, TFS поддерживает конфигурацию с пассивным узлом, активным узлом и одним сервером кворума. Когда уровень данных после сбоя передается на пассивный узел, этот узел принимает на себя владение кворумом и уровнем данных.
Устанавливать .
Зеркалирование сервера состоит в синхронизации данных на этом сервере с их копией на другом сервере. Сервер уровня данных является главным, а сервер с зеркалированными данными - резервным или зеркальным сервером. Если сервер уровня данных выходит из строя, переключиться на зеркальный сервер можно вручную.
Наличие зеркального сервера позволяет отключать главный сервер для обслуживания или ремонта, а также обеспечивает возможность быстрого восстановления в случае выхода из строя главного сервера уровня данных.
Зеркалирование может быть синхронным или асинхронным. Можно также менять главный и зеркальный серверы ролями. Когда производится смена ролей (role switching), зеркальный сервер становится главным, а бывший главный - зеркальным. В принципе, смену ролей можно производить неоднократно.
Автоматическое переключение TFS с главного на зеркальный сервер не поддерживается, это нужно делать вручную.
Чтобы настроить зеркалирование SQL для уровня данных, выполните следующие действия:
Reporting Services.SQL Server 2005.Configure Database Mirroring Security WizardЧтобы вручную переключиться на зеркальный сервер, выполните следующие действия:
TFS:Report Service на использование нового сервера.SharePoint Web.SharePoint Timer.TfsServerScheduler.ReportServer.TFS App Pool.TFSAdminUtil RenameDT MirrorDataTierServer.IIS.Reporting Services, включив в нее ссылку на зеркальный сервер уровня данных.SharePoint использование зеркального сервера уровня данных.SharePoint Timer.TfsServerScheduler.ReportServer.TFS App Pool. и. Запустите Reporting Services.StampWorkItemCache.Настроив главный сервер уровня приложений, подготовьте также резервный компьютер для "теплой замены" на случай выхода главного сервера из строя.
Резервный сервер необязательно должен быть идентичен главному серверу, но он должен удовлетворять аппаратным требованиям к серверу уровня приложений. На него необходимо установить ПО уровня приложений TFS. Убедитесь, что у обоих серверов одинаковая конфигурация, включая одинаковые учетные записи пользователей, одинаковые разрешения и обновления ПО. Применяя на главном компьютере очередное обновление, не забудьте применить его и на резервном сервере.
Чтобы свести проблемы с обеспечением отказоустойчивости к минимуму, настройте сетевые адаптеры главного и резервного компьютеров на использование одного и того же имени хоста. Сделать это можно многими способами.
Переключение на резервный сервер уровня приложений производится вручную. Если главный сервер вышел из строя, выполните следующие действия:
TFSAdminUtil с параметром ActivateAT.TFS.Архитектура TFS состоит из трех уровней: уровня приложений, уровня данных и клиентского уровня. Устанавливая сервер, вы выбираете между установкой уровней данных и приложений на одном и том же или на разных серверах. Выбор конкретного варианта развертывания TFS определяется, главным образом, количеством пользователей, которых вам предстоит поддерживать. Выбрав топологию, отвечающую потребностям команды, решите также, какой способ архивации и восстановления вам подходит.
На уровне данных удобно использовать тот же механизм архивации, который принят в вашей организации для других архивов SQL Server 2005. Отказоустойчивость можно обеспечить при помощи зеркалирования или кластеризации.
Автоматическое восстановление уровня данных после сбоя не производится. Если вам нужно быстро вернуть систему в рабочее состояние, подготовьте резервный сервер для быстрого "теплого" переключения.
TFS, перечитайте лекцию 2.В этой лекции описан общий подход к развертыванию Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) , а также основные решения, которые необходимо принимать при развертывании TFS в организации. В лекции рассказывается о двух вариантах развертывания и объясняется, как выбрать между двумя этими вариантами.
Два этих варианта - односерверная и раздельная установка. В первом случае уровень данных и уровень приложений размещаются на одном сервере. Во втором случае эти уровни размещаются на разных серверах. Кроме того, вы вольны установить на отдельных компьютерах сервер сборки и прокси управления исходным кодом. Доступ к этим серверам требуется каждому клиенту, и потому на клиентской стороне необходимо установить соответствующие инструменты.
Архитектура TFS показана на рис.16.1.
(рис 16.1) Архитектура TFS С точки зрения архитектуры TFS разделен на три уровня - уровень данных ( data ), уровень приложений ( application ) и клиентский уровень ( client ). Разделение это логическое, и все три уровня вполне можно установить на одном и том же компьютере.
На уровне данных Team Foundation находится Microsoft SQL Server™ 2005. С ним устанавливается ряд баз данных для хранения рабочих элементов, версий, результатов испытаний и любых отчетов.
На уровне приложений содержатся веб-интерфейс, встроенный в Internet Information Services (IIS) , веб-службы Team Foundation и службы Microsoft Office SharePoint®. Также на уровне приложений находятся серверы сборки и прокси управления исходным кодом.
На клиентском уровне находятся приложения, осуществляющие доступ к TFS. Разработчики используют для подключения к Team Server обозреватель Team Explorer, установленный как самостоятельное приложение или как часть Visual Studio 2005. Менеджеры проекта пользуются Microsoft Office Excel® или Microsoft Office Project. Для подключения к серверу можно применять и инструменты сторонних разработчиков.
Подробнее - в лекции 2.
Существуют следующие способы развертывания TFS:
Microsoft Active Directory®.В этом варианте создается рабочая группа без использования контроллера домена Active Directory. Такой подход удобен в небольших коллективах. Для подключения к серверу каждому пользователю необходима локальная учетная запись на нем. При использовании рабочих групп раздельное развертывание не поддерживается.
Если вы используете Active Directory, вам доступны оба варианта развертывания. Вы вольны установить уровни данных и приложений как на одном, так и на нескольких серверах.
Чтобы выбрать вариант развертывания, максимально отвечающий потребностям вашей организации, ответьте на следующие вопросы:
TFS на нескольких серверах. Каждый экземпляр TFS способен поддерживать до 5000 проектов. Если у вас более 5000 проектов, одним экземпляром Team Foundation Server вам не обойтись.TFS компьютер не должен выполнять никакие иные функции, то есть, не должен быть почтовым сервером, файловым сервером или сервером баз данных для других приложений.У односерверного развертывания есть следующие преимущества:
TFS управляются на одном сервере.У раздельного развертывания есть следующие преимущества:
Типичное развертывание с одним сервером показано на рис.16.2. На сервере установлены уровни данных и приложений TFS, а также SharePoint Services и SQL Server 2005.
(рис 16.2) Типичное развертывание с одним сервером
Типичный вариант развертывания с несколькими серверами показан на рис.16.3. Уровень приложений TFS установлен совместно с SharePoint Services. На другом компьютере размещены уровень данных TFS и SQL Server 2005.
(рис 16.3) Типичное раздельное развертывание
Как в односерверном, так и в раздельном варианте вы вольны установить также сервер сборки и прокси-сервер. Их можно установить как на том же сервере, что и уровень приложений, так и на других серверах.
Чтобы повысить производительность сборки и снизить нагрузку на уровень приложений, разместите службы сборки на отдельном сервере. Например, это нужно сделать, если сборки планируется проводить достаточно часто.
Прокси-сервер Team Foundation кеширует копии файлов, включенных в систему управления исходным кодом. Используйте прокси-сервер, если вы обращаетесь к серверу управления исходным кодом по сети и испытываете проблемы с ее быстродействием.
Выбрав вариант установки, вы должны затем выбрать одну из нескольких топологий. К вашим услугам как простые, так и сложные топологии - для команд самых различных размеров.
На рис.16.4 показана самая простая топология TFS - уровни приложений и данных развернуты на одном и том же сервере. Прокси-сервер TFS развернут на отдельном сервере. Доступ к серверу имеется с клиентских рабочих станций в том же домене.
Эта конфигурация подходит для команд разработчиков и для пилотных проектов с числом пользователей не более 400.
(рис 16.4) Простая топология TFS
На рис.16.5 показан вариант с топологии с разделением уровней. Службы приложений развернуты на одном сервере, базы данных - на другом.
(рис 16.5) Топология TFS умеренной сложности На рис.16.5 показано также испытательное оборудование и серверы сборки, развернутые на отдельных узлах. Клиентские узлы находятся либо в том же домене, что и серверы, либо в доменах, которые связаны с серверами отношениями доверия. Топологии этого уровня сложности уместны в больших командах разработки с количеством пользователей от 400 до 2000.
Сложная топология, показанная на рис.16.6, близка к предыдущему случаю. Однако теперь в нее добавлены компоненты отказоустойчивости - резервный сервер уровня приложений и уровень данных с использованием технологий кластеризации SQL.
(рис 16.6) Сложная топология TFS Кроме того, на рис.16.6 показан географически удаленный дочерний домен, связанный с основным доменом при помощи низкоскоростного соединения. Клиенты в этом домене для более эффективного доступа к системе управления исходным кодом используют прокси-сервер TFS.
При развертывании TFS учитывайте следующее:
Планируя установку и развертывание Team Foundation Server, вы должны среди прочего решить, как будете управлять архивацией серверов и их восстановлением после сбоев. Выбор соответствующих стратегий определяется размером системы и доступными ресурсами. Поскольку уровень данных опирается на SQL Server 2005, подбор стратегии зависит от того, какой подход к архивации SQL Server вы в данный момент используете.
Если вы используете зеркалирование или кластеризацию SQL Server 2005, тот же самый подход можно применить и к уровню данных TFS. Вам также предстоит решить, как поступать в случае сбоя на сервере уровня приложений. Чтобы добиться отказоустойчивости, подготовьте резервный сервер уровня приложений и обеспечьте возможность быстрого переключения на него.
Выбирая стратегию установки архивации и восстановления TFS, учитывайте следующие соображения:
Как правило, небольшие команды с незначительным числом проектов могут работать в односерверной среде, тогда как большим командам необходима раздельная установка и более быстрое оборудование. Выбор между односерверной и раздельной установкой влияет также на механизмы архивации и восстановления после сбоев.
Таб.16.1 поможет вам решить, какой вариант установки стоит выбрать и какое оборудование использовать.
| Конфигурация | Уровень | ЦП | Жесткий диск | Память |
|---|---|---|---|---|
| Один сервер, менее 20 пользователей | Сервер уровня приложений и данных | Одиночный процессор, 2,2 ГГц | 8 Гб | 1 Гб |
| Один сервер; от 20 до 100 пользователей | Сервер уровня приложений и данных | Двойной процессор, 2,2 ГГц | 30 Гб | 2 Гб |
| Несколько серверов; от 100 до 250 пользователей | Сервер уровня приложений | Одиночный процессор, 2,2 ГГц | 20 Гб | 1 Гб |
| Сервер уровня данных | Двойной процессор, 2,2 ГГц | 80 Гб | 2 Гб | |
| Несколько серверов; от 250 до 2000 пользователей | Сервер уровня приложений | Двойной процессор, 2,8 ГГц | 40 Гб | 4 Гб |
| Сервер уровня данных | Счетверенный процессор, 2,7 ГГц | Накопитель прямого подключения, 14 000-15 000 RPM RAID 0 | 16 Гб |
Выбирая стратегию архивации и восстановления, необходимо, конечно, учитывать, какой ущерб вашей команде будет нанесен в результате выхода из строя конкретного сервера.
Планирование стратегии архивации является частью плана развертывания TFS. Учитывайте следующие соображения:
Вы вольны использовать ту же методику архивации, что используете для любой БД SQL Server 2005. Восстановление TFS из архивов проводится по одному из трех сценариев:
Восстановление только данных применяется в случае сбоя на уровне данных. С помощью архивных данных и журналов вы полностью восстановите БД. Восстановление серверов требуется при их выходе строя. В этом случае вы можете восстановить полную БД на втором компьютере.
На серверах уровня приложений нет никаких данных, которые нуждались бы в архивации, но это не делает их неуязвимыми. Чтобы минимизировать последствия сбоя, подумайте о подготовке "теплого" резервного сервера, на который можно было бы оперативно переключиться.
Оценивая необходимость отказоустойчивого решения для TFS, принимайте во внимание стоимость оборудования для резервных серверов и сопоставляйте ее с возможными потерями от временной недоступности TFS. Обеспечение отказоустойчивости повышает сложность установки и накладные расходы на ее обслуживание. Не забудьте включить обслуживание в свои расчеты.
Особенно велики затраты на создание и обслуживание кластеров, поэтому кластеризацию рекомендуется использовать лишь в тех случаях, когда ресурсы для создания кластера в вашей организации уже имеются.
С зеркалированием также связаны расходы, но они несравнимы с расходами на кластеризацию. Причем в этом случае у вас появляется возможность временно отключить основной сервер, скажем, для мелких ремонтных работ. Подумайте о зеркалировании, если ваша организация может позволить себе установку и обслуживание второго сервера уровня данных.
Если у вашей организации есть необходимые ресурсы, создайте кластер с выделенными серверами. Кластер обеспечит непрерывный доступ к уровню данных. Правда, за это придется заплатить высокую цену с точки зрения как создания, так и обслуживания кластера.
Работая в кластере, TFS поддерживает конфигурацию с пассивным узлом, активным узлом и одним сервером кворума. Когда уровень данных после сбоя передается на пассивный узел, этот узел принимает на себя владение кворумом и уровнем данных.
Устанавливать .
Зеркалирование сервера состоит в синхронизации данных на этом сервере с их копией на другом сервере. Сервер уровня данных является главным, а сервер с зеркалированными данными - резервным или зеркальным сервером. Если сервер уровня данных выходит из строя, переключиться на зеркальный сервер можно вручную.
Наличие зеркального сервера позволяет отключать главный сервер для обслуживания или ремонта, а также обеспечивает возможность быстрого восстановления в случае выхода из строя главного сервера уровня данных.
Зеркалирование может быть синхронным или асинхронным. Можно также менять главный и зеркальный серверы ролями. Когда производится смена ролей (role switching), зеркальный сервер становится главным, а бывший главный - зеркальным. В принципе, смену ролей можно производить неоднократно.
Автоматическое переключение TFS с главного на зеркальный сервер не поддерживается, это нужно делать вручную.
Чтобы настроить зеркалирование SQL для уровня данных, выполните следующие действия:
Reporting Services.SQL Server 2005.Configure Database Mirroring Security WizardЧтобы вручную переключиться на зеркальный сервер, выполните следующие действия:
TFS:Report Service на использование нового сервера.SharePoint Web.SharePoint Timer.TfsServerScheduler.ReportServer.TFS App Pool.TFSAdminUtil RenameDT MirrorDataTierServer.IIS.Reporting Services, включив в нее ссылку на зеркальный сервер уровня данных.SharePoint использование зеркального сервера уровня данных.SharePoint Timer.TfsServerScheduler.ReportServer.TFS App Pool. и. Запустите Reporting Services.StampWorkItemCache.Настроив главный сервер уровня приложений, подготовьте также резервный компьютер для "теплой замены" на случай выхода главного сервера из строя.
Резервный сервер необязательно должен быть идентичен главному серверу, но он должен удовлетворять аппаратным требованиям к серверу уровня приложений. На него необходимо установить ПО уровня приложений TFS. Убедитесь, что у обоих серверов одинаковая конфигурация, включая одинаковые учетные записи пользователей, одинаковые разрешения и обновления ПО. Применяя на главном компьютере очередное обновление, не забудьте применить его и на резервном сервере.
Чтобы свести проблемы с обеспечением отказоустойчивости к минимуму, настройте сетевые адаптеры главного и резервного компьютеров на использование одного и того же имени хоста. Сделать это можно многими способами.
Переключение на резервный сервер уровня приложений производится вручную. Если главный сервер вышел из строя, выполните следующие действия:
TFSAdminUtil с параметром ActivateAT.TFS.Архитектура TFS состоит из трех уровней: уровня приложений, уровня данных и клиентского уровня. Устанавливая сервер, вы выбираете между установкой уровней данных и приложений на одном и том же или на разных серверах. Выбор конкретного варианта развертывания TFS определяется, главным образом, количеством пользователей, которых вам предстоит поддерживать. Выбрав топологию, отвечающую потребностям команды, решите также, какой способ архивации и восстановления вам подходит.
На уровне данных удобно использовать тот же механизм архивации, который принят в вашей организации для других архивов SQL Server 2005. Отказоустойчивость можно обеспечить при помощи зеркалирования или кластеризации.
Автоматическое восстановление уровня данных после сбоя не производится. Если вам нужно быстро вернуть систему в рабочее состояние, подготовьте резервный сервер для быстрого "теплого" переключения.
TFS, перечитайте лекцию 2.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.