СМ-Консалт
 

Глава 16

Статьи Технологии Microsoft: .NET, Visual Studio Team System Коллективная разработка с использованием Visual Studio Team Foundation Server Часть VIII - Настройка и обслуживание среды коллективной разработки

Глава 16 - Развертывание Team Foundation Server

Содержание


Полезные материалы в тему статьи:


Область применения

  • Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)
  • Microsoft Visual Studio Team System

Задачи

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

Обзор

Данная глава рассматривает основные подходы к развертыванию Microsoft® Visual Studio® Team Foundation Server (TFS) и ключевые решения при развертывании TFS в организации. Здесь обсуждаются два варианта развертывания, и описывается, на основании чего принимается решение об использовании того или иного варианта развертывания. Два варианта развертывания TFS – это установка на один сервер или на два сервера. При установке на один сервер уровни данных и приложений размещаются на одном сервере. При установке на двух серверах уровни данных и приложений располагаются на разных серверах. Кроме того, на отдельных серверах можно настроить сервер сборки и прокси-сервер системы контроля версий. Каждый клиент, желающий иметь доступ к серверам, должен установить соответствующие клиентские инструментальные средства.

Как использовать данную главу

Эта глава поможет выбрать стратегию развертывания TFS. Чтобы использовать ее с максимальной пользой, следует:

  • Понять архитектуру TFS. Убедитесь, что вы полностью понимаете архитектуру TFS. Об архитектуре Team Foundation Server рассказывает раздел «Архитектура TFS». Более подробную информацию можно найти в Главе 2 «Архитектура Team Foundation Server».
  • Выбрать стратегию развертывания. Выбрать стратегию развертывания, наиболее соответствующую нуждам вашей организации. Чтобы определиться, какая из стратегий лучше всего подойдет вашей группе, прочитайте раздел «Сценарии развертывания».

Архитектура TFS

На рис. 16.1 представлена архитектура TFS.

 

 

Рис. 16.1 Архитектура TFS

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

Для хранения рабочих элементов, данных системы контроля версий, результатов тестирования и всевозможных отчетов уровень данных TFS использует Microsoft SQL Server™.

Уровень приложений включает клиентский интерфейс на базе Веб-технологий, интегрированный в Internet Information Services (IIS), Веб-сервисы TFS и сервисы Microsoft Office SharePoint®. Также к уровню приложений относятся все серверы сборки и прокси-серверы системы контроля версий.

Клиентский уровень – это приложения, осуществляющие доступ к TFS. Для соединения с Team Server разработчики используют Team Explorer, установленный как самостоятельный инструмент или как часть Visual Studio 2005. Руководители проектов используют Microsoft Office Excel® или Microsoft Office Project. Также соединение с сервером можно осуществлять посредством инструментальных средств сторонних производителей.

Более подробно смотрите в Главе 2 «Архитектура Team Foundation Server». Примечание: TFS 2005 и TFS 2008 обладают очень высокой степенью совместимости. При обновлении до TFS 2008 нет необходимости переводить всех клиентов на VS 2008. Также можно обновлять клиентов до VS 2008 без обновления серверов до TFS 2008.

Сценарии развертывания

Развертывание TFS может выполняться по следующим схемам:

  • Развертывание на одном сервере
    • В рамках рабочей группы.
    • Используя службу каталогов Microsoft Active Directory®.
  • Развертывание на двух серверах

Развертывание на одном сервере с использованием рабочей группы

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

Развертывание на одном сервере с Active Directory

При наличии Active Directory возможны два варианта развертывания. Можно установить уровень данных и уровень приложений на одном сервере или на разных серверах.

Какой тип развертывания подходит для моей организации?

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

  • Сколько пользователей необходимо поддерживать? В TFS 2005 при количестве пользователей более 400 лучше прибегнуть к развертыванию на двух серверах. В TFS 2008 этот порог будет 450 пользователей.
  • Сколько проектов будет поддерживать TFS? Если требуется поддерживать большое количество проектов, следует прибегнуть к развертыванию на двух серверах. Каждый экземпляр TFS может поддерживать до 500 проектов. Если требуется поддерживать более 500 проектов, рассмотрите возможность настройки нескольких экземпляров Team Foundation Server.
  • Есть ли в моем распоряжении сервер, который может быть полностью отдан под TFS? При развертывании Team Foundation Server на одном сервере сервер должен полностью выделяться под функциональность TFS. TFS не должен использоваться ни для каких других задач, он не должен быть почтовым сервером, сервером файлов или сервером баз данных для других приложений.

Преимущества развертывания на одном сервере

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

Преимущества развертывания на двух серверах

Принимая решение о схеме развертывания, следует учитывать следующие преимущества развертывания на двух серверах:

  • Масштабируемость. Схема развертывания на одном сервере обеспечивает работу до 400 пользователей в TFS 2005 и 450 пользователей в TFS 2008, тогда как развертывание на двух серверах позволяет увеличить количество пользователей до 2000 в TFS 2005 и до 2200 в TFS 2008.
  • Передача нагрузки при сбое. В случае отказа или на время обслуживания можно перенаправить сервер уровня приложений на другой сервер уровня данных. Также можно конфигурировать и развернуть дополнительный сервер, который может выполнять роль резервного или дублирующего сервера уровня приложений.

Развертывание на одном сервере

На рис. 16.2 представлено типовое развертывание на одном сервере. На сервере установлены уровни приложений и данных TFS, а также SharePoint Services и SQL Server.

 

 Рис. 16.2 Типовая установка на одном сервере

 

Развертывание на двух серверах

На рис. 16.3 представлена типовая установка на двух серверах. Уровень приложений TFS вместе с SharePoint Services установлен на одном сервере, а уровень данных TFS и SQL Server – на другом сервере.

 

 

Рис. 16.3 Типовая установка на двух серверах

 Другие серверы

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

Установка сервера сборки

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

Прокси-сервер Team Foundation

Прокси-сервер Team Foundation кэширует копии файлов системы контроля версий. Прокси-сервер необходим, если доступ к серверу системы контроля версий осуществляется по сети и наблюдается большая задержка.

Топологии Team Foundation Server

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

Простая топология

На рис. 16.4 показана простая топология развертывания, при которой компоненты уровня приложений и данных TFS располагаются на одном сервере. Прокси-сервер TFS установлен на отдельном сервере. Сервер доступен с клиентских рабочих станций того же домена

Такая конфигурация подходит группам разработки или для пилотных проектов с количеством участников до 400 в TFS 2005 и до 450 в TFS 2008.

 

 

Рис. 16.4 Простая конфигурация Team Foundation Server

 Топология средней сложности

На рис. 16.5 представлен TFS, установленный на разных уровнях. Сервисы приложений развернуты на одном сервере, а базы данных – на другом сервере уровня данных.

 

 

Рис. 16.5 Топология Team Foundation Server средней сложности

 На рис. 16.5 также показаны средства тестирования и серверы сборки, развернутые на отдельных серверах. Клиентские сервера или находятся в одном домене с этими серверами, или между ними и данными серверами установлены доверительные отношения. Топологии такого уровня сложности ориентированы на более крупные группы разработки от 450 до 3600 участников.

Сложная топология

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

 

 

Рис. 16.6 Сложная топология Team Foundation Server

На рис. 16.6 также показан дочерний домен, удаленный географически, использующий соединение с ограниченной полосой пропускания. Этот клиент использует прокси-сервер TFS для сокращения времени доступа к системе контроля версий.

Дополнительные рекомендации

При развертывании TFS необходимо учесть следующее:

  • Если принято решение разместить сайт Team Foundation Server SharePoint на уже установленном SharePoint-сервере, можно перенести сайт TFS SharePoint на другой сервер. Более подробно об этом рассказывается по адресу http://blogs.msdn.com/bharry/archive/2006/10/30/moving-your-tfs-sharepoint-site.aspx .
  • Перенос механизма аналитической обработки данных и OLAP-куба на третью машину доказал свою эффективность для больших групп. Можно настроить кластеризацию SQL на уровне данных и получить конфигурацию со всеми активными узлами с SQL на одном сервере и OLAP на другом, каждый из которых является резервным для своего двойника. Более подробно смотрите на http://msdn2.microsoft.com/en-us/library/aa721760(vs.80).aspx и http://msdn2.microsoft.com/en-us/library/ms252505(VS.80).aspx .

Примечание: TFS 2008 поддерживает Windows SharePoint Services v3 и Microsoft Office SharePoint Server 2007, выполняющиеся на любом из серверов, участвующих в развертывании.

Стратегия масштабирования и резервирования Team Foundation Server

При установке и развертывании Team Foundation Server необходимо также принять решение о резервировании серверов и передаче нагрузки при сбое. Стратегии резервирования и передачи нагрузки выбираются в зависимости от размера установки, средств и ресурсов, доступных организации. Поскольку уровень данных использует SQL Server 2005, стратегии принимаются соответственно подходу, применяемому к резервированию SQL Server.

Если используется отображение или кластеризация экземпляров SQL Server 2005, этот же подход можно применять к уровню данных TFS. Также необходимо выбрать стратегию поведения при сбоях сервера уровня приложений. Если требуется поддерживать передачу нагрузки при сбое на уровне приложений, понадобится резервный сервер уровня приложений и возможность быстрого переноса нагрузки на него.

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

При установке TFS необходимо принять несколько решений о стратегиях установки и резервирования/восстановления. Выбирая стратегию установки необходимо учитывать следующее:

  • Размер групп
  • Количество проектов
  • Размер проектов
  • Дислокацию групп
  • Необходимость в передаче нагрузки при сбое
  • Необходимость резервирования

Рекомендуемое оборудование для Team Foundation Server

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

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

 

 Конфигурация  Уровни CPU
 Жесткий диск  Память
 Один сервер, менее 20 пользователей  Сервер уровня приложений и данных  Одиночный процессор, 2.2 гигагерца (GHz)  8 гигабайта (GB)  1 GB
 Один сервер; от 20 до 100 пользователей  Сервер уровня приложений и данных  Два процессора, 2.2 GHz  30 GB  2 GB
 Два сервера; от 100 до 250 пользователей  Сервер уровня приложений  Одиночный процессор, 2.2 GHz  20 GB  1 GB
 Сервер уровня данных  Два процессора, 2.2 GHz  80 GB  2 GB
 Два сервера; от 250 до 2000 пользователей  Сервер уровня приложений  Два процессора, 2.8 GHz  40 GB  4 GB
 Сервер уровня данных  Четыре процессора, 2.7 GHz  Хранилище прямого доступа, RAID 0 массив дисковых накопителей с частотой вращения шпинделя 14 000 – 15 000 оборотов в минуту  16 GB

 Таблица 16.1 Оборудование, необходимое для развертывания TFS

Стратегия резервирования и передачи нагрузки при сбое

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

Резервирование

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

  • Частоту выполнения резервных копий.
  • Частоту выполнения полных и инкрементных резервных копий.
  • Требования к хранилищу резервных копий, такие как должно ли оно располагаться на или вне территории организации.

Здесь могут использоваться те же стандартные практики резервирования, которые применяются для любой базы данных SQL Server 2005.

Существует три сценария использования резервных копий для восстановления TFS:

  • Восстановление только данных.
  • Полное восстановление при развертывании на одном сервере.
  • Полное восстановление при развертывании на двух серверах.

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

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

Резервный сервер уровня приложений

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

Передача нагрузки при сбое

Принимая решение об обеспечении передачи нагрузки при сбое для TFS, следует сравнить, сколько будут стоить для компании резервные сервера, с тем, во что обойдется компании потеря производительности в случае недоступности TFS.

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

Кластеризация – довольно дорогое удовольствие с точки зрения ресурсов и обслуживания, поэтому ее применение рекомендуется, только если организация уже предоставляет ресурсы для обслуживания кластеризованного сервера.

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

Уровень данных

Кластеризация серверов уровня данных

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

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

Кластер должен быть подготовлен к установке до установки TFS в кластер. Более подробно о кластеризации SQL Server 2005 рассказывается в материале «SQL Server 2005 Failover Clustering White Paper» (Техническое описание организации кластера для передачи нагрузки при сбоях SQL Server 2005), который можно скачать по адресу http://www.microsoft.com/downloads/details.aspx?familyid=818234dc-a17b-4f09-b282-c6830fead499&displaylang=en .

Зеркальное копирование серверов уровня данных

Зеркальное копирование подразумевает синхронизацию данных одного сервера с копией этих данных на другом сервере. Сервер уровня данных – это основной сервер, сервер с копией данных – это резервный или зеркальный сервер. В случае выхода из строя сервера уровня данных можно вручную переключиться на зеркальный сервер.

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

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

TFS не поддерживает автоматическое переключение ролей, поэтому переключение должно выполняться вручную.

Чтобы сконфигурировать зеркальное копирование SQL Server 2005 для уровня данных

  1. Создайте резервную копию всех баз данных и протокола транзакций.
  2. Создайте резервную копию ключа шифрования Reporting Services.
  3. Установите SQL Server 2005 на зеркальный сервер.
  4. Восстановите данные уровня данных на зеркальном сервере.
  5. Чтобы конфигурировать зеркальный сервер для каждой базы данных основного сервера уровня данных запустите Configure Database Mirroring Security Wizard (Мастер настройки безопасности зеркального копирования базы данных).
  6. Начните зеркальное копирование.

Передача нагрузки при сбое зеркальному серверу

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

  1. На уровне приложений TFS
    1. Меняется конфигурация Report Service для использования другого сервера.
    2. Останавливается Веб-сайт по умолчанию.
    3. Останавливается Веб-сайт SharePoint.
    4. Останавливается сервис SharePoint Timer.
    5. Останавливается сервис TfsServerScheduler.
    6. Останавливается пул приложений ReportServer.
    7. Останавливается пул приложений TFS App Pool.
  2. На зеркальном сервере уровня данных проверяется правильность добавленных учетных записей сервисов.
  3. Выполняется перенос всех баз данных с основного сервера на зеркальный.
  4. Создается хранилище данных на новом сервере.
  5. Сервер уровня приложений конфигурируется для использования зеркального сервера следующим образом:
    1. Из окна командной строки запускается TFSAdminUtil RenameDT MirrorDataTierServer.
    2. Выполняется перезапуск IIS.
    3. Вносятся изменения в строки соединения Reporting Services, чтобы они ссылались на зеркальный сервер уровня данных.
    4. Вносятся изменения в SharePoint-сервер для использования зеркального сервера уровня данных
    5. Запускается сервис SharePoint Timer.
    6. Запускается сервис TfsServerScheduler.
    7. Запускается пул приложений ReportServer.
    8. Запускается пул приложений TFS App Pool.
    9. Запускаются Reporting Services.
    10. Выполняется запуск Веб-сервиса StampWorkItemCache.

Уровень приложений

Передача нагрузки при сбое на уровне приложений

Настроив основной сервер уровня приложений, можно добавить компьютер «горячего» резерва, чтобы обеспечить возможность передачи нагрузки при сбое уровня приложений «нагорячо».

Резервное оборудование и программное обеспечение

Не обязательно, чтобы резервный сервер был идентичен основному, но он должен соответствовать требованиям к аппаратным средствам уровня приложений. На сервер «горячего» резерва устанавливается программное обеспечение уровня приложений TFS.

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

Чтобы свести до минимума проблемы при передаче нагрузки, необходимо конфигурировать сетевые адаптеры на использование одного имени хоста как с основного, так и с резервных компьютеров. Это можно сделать по-разному.

Передача нагрузки при сбое между серверами уровня приложений

Передача нагрузки при сбое между серверами уровня приложений выполняется вручную. При выходе из строя основного сервера, необходимо вручную активировать сервер «горячего» резерва, выполнив шаги, представленные ниже. Чтобы передать нагрузку с основного сервера на резервном сервере можно выполнить утилиту TFSAdminUtil, передавая команду ActivateAT.

Чтобы передать нагрузку на сервер «горячего» резерва:

  1. Активировав резервный сервер уровня приложений, переведите исходный сервер в автономный режим.
  2. На резервном сервере
    1. Зарегистрируйтесь как администратор.
    2. Запустите TFSAdminUtil, передавая команду ActivateAT
    3. Запустите Веб-сервисы на резервном сервере.
      Эта команда
      • Зарегистрирует имя сервера «горячего» резерва в базе данных сервисов интегрирования TFS.
      • Соединит сервер «горячего» резерва уровня приложений с активным сервером уровня данных.
      • Проверит соответствие соединенных серверов уровня приложений и уровня данных.

Более подробно об активации резервного сервера уровня приложений при передаче нагрузки не него рассказывается в статье «How to: Activate a Fail-Over Application-Tier Server» (Как: активировать резервный сервер уровня приложений) по адресу http://msdn2.microsoft.com/en-us/library/ms252501(VS.80).aspx .

Заключение

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

Для уровня данных может использоваться тот же механизм резервирования, который организация использует для резервирования других экземпляров SQL Server 2005. Поддержку механизма передачи нагрузки при сбое можно реализовать посредством зеркальных серверов или кластеризации.

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

Дополнительные источники

  • Более подробно об установке TFS смотрите в статье «Visual Studio 2005 Team Foundation Installation Guide» (Руководство по установке Visual Studio 2005 Team Foundation) по адресу http://go.microsoft.com/fwlink/?linkid=40042 .
  • Более подробно о возможностях масштабирования TFS рассказывается в статье «Team Foundation Server Capacity Planning» (http://blogs.msdn.com/bharry/archive/2006/01/04/509314.aspx ).
  • Подробнее о переносе OLAP-куба и механизма анализа на отдельный сервер рассказывает статья «How To: Move the Data Warehouse SQL Server Analysis Services Database to a Separate Server» (Как: перенести базу данных хранилища SQL Server Analysis Services на отдельный сервер) (http://msdn2.microsoft.com/en-us/library/aa721760(vs.80).aspx ).
  • Чтобы получить подробную информацию о кластеризации SQL Server 2005, скачайте «SQL Server 2005 Failover Clustering White Paper» по адресу http://www.microsoft.com/downloads/details.aspx?familyid=818234dc-a17b-4f09-b282-c6830fead499&displaylang=en .
  • Более подробно о создании кластера серверов SQL Server для передачи нагрузки при сбое рассказывает статья «How To: Create a New SQL Server 2005 Failover Cluster (Setup)» (Как: создать новый кластер серверов SQL Server 2005 для передачи нагрузки при сбое (настройка)) по адресу http://uat.technet.microsoft.com/en-us/library/ms179530(SQL.90).aspx .
  • Подробнее о том, как настроить кластер серверов SQL Server для уровня данных, рассказывается в статье «Clustering the Data-Tier Server» (Кластеризация сервера уровня данных) (http://msdn2.microsoft.com/en-us/library/ms252505(VS.80).aspx ).
  • О переносе сайта TFS SharePoint на другой сервер подробно рассказывает статья «Moving your TFS SharePoint site» (Перенос сайта TFS SharePoint) по адресу http://blogs.msdn.com/bharry/archive/2006/10/30/moving-your-tfs-sharepoint-site.aspx .
  • Более подробную информацию о масштабируемости Team Foundation Server можно найти в блоге Брайана Гарри (Brian Harry) по адресу http://blogs.msdn.com/bharry/archive/2005/12/09/502190.aspx .
  • Подробнее о планировании восстановления после сбоя рассказывает статья «Visual Studio Team System User Education» (Обучение пользователей Visual Studio Team System) по адресу http://www.microsoft.com/technet/itshowcase/content/vs05teamsystemnote.mspx .
  • Более подробно о сбоях и восстановлении Team Foundation Server рассказывается в статье «Ensuring Team Foundation Server Availability» (Как гарантировать доступность Team Foundation Server) (http://msdn2.microsoft.com/en-gb/library/ms253159(VS.80).aspx ).
  • Кластеризация серверов уровня данных подробно рассматривается в статье «Clustering the Data-Tier Server» (http://msdn2.microsoft.com/en-gb/library/ms252505(VS.80).aspx ).
  • Зеркальное копирование уровня данных Team Foundation Server подробно рассматривается в статье «Mirroring the Team Foundation Data-Tier Server» (Зеркальное копирование Team Foundation Data-Tier Server) по адресу http://msdn2.microsoft.com/en-gb/library/aa980644(VS.80).aspx .
  • Подробнее о конфигурировании зеркального копирования SQL Server для уровня данных рассказывает статья «How to: Configure SQL Server Mirroring for the Team Foundation Data-Tier Server» (Как: конфигурировать зеркальное копирование SQL Server для Team Foundation Data-Tier Server) по адресу http://msdn2.microsoft.com/en-us/library/aa980629(VS.80).aspx .
  • Более подробно о передаче нагрузки при сбое сервера уровня данных рассказывается в статье «How To: Fail Over to a Mirrored Data-Tier Server» (Как: передать нагрузку зеркальному серверу уровня данных) по адресу http://msdn2.microsoft.com/en-gb/library/aa980627(VS.80).aspx .
  • Более подробно о передаче нагрузки при сбое сервера уровня данных в случае недоступности основного сервера рассказывается в статье «How To: Fail Over to a Mirrored Data-Tier Server if the Principal Data-Tier Server is Unavailable» (Как: передать нагрузку зеркальному серверу уровня данных, если основной сервер уровня данных недоступен) по адресу http://msdn2.microsoft.com/en-gb/library/aa980528(VS.80).aspx .
  • Как активировать сервер уровня приложений при передаче нагрузки подробно рассказывается в статье «How To: Activate a Fail-Over Application-Tier Server» по адресу http://msdn2.microsoft.com/en-us/library/ms252501(VS.80).aspx .
  • Как активировать сервер уровня приложений при передаче нагрузки подробно рассказывается в статье «Activating a Fail-Over Application-Tier Server» (Как активировать сервер уровня приложений для передачи нагрузки при сбое) по адресу http://msdn2.microsoft.com/en-us/library/ms252486(VS.80).aspx .

 

02.04.2009

Комментарии

  • 2353
    Автор: Coach australia  ·  02.06.2015 15:52:23
    MCM Canada Coach australia
  • 6385
    Автор: Parajumpers australia  ·  19.05.2015 16:52:30
    Tommy Hilfiger UK Parajumpers australia
  • 1145
    Автор: coach factory  ·  21.08.2014 02:39:02
    coach outlet store online [url=http://www.coachoutletstoreonline2014.net][b]coach outlet store online[/b][/url] coach outlet online [url=http://www.coachoutletstoreonline2014.net][b]coach outlet online[/b][/url] coach factory
  • 9554
    Автор: coach outlet store online  ·  17.08.2014 22:39:24
    [url=https://www.doyleland.com/sample/coach.html][b]Coach Factory Online[/b][/url] [url=http://co.slcolibrary.org/aspnet_client/system_web/Michael_Kors.cfm][b]Michael Kors Hamilton[/b][/url] [url=http://www.aussieholdempoker.com.au/coach.cfm][b]Coach Factory Outlet[/b][/url] coach outlet store online http://yesjobsearch.com/freeDemo/Coach.cfm
  • 2427
    Автор: michael kors purses  ·  31.07.2014 07:48:02
    Thanks for another wonderful post. Where else could anybody get that type of information in such an ideal way of writing? I have a presentation next week, and I’m on the look for such information. michael kors purses http://factoringconference.com/Exhibitors.asp
  • Spraypaint besides stencils would equate an smooth way to customize the case, but that cede different protect aesthetic value. 52046
    Автор:   ·  02.10.2013 14:39:43
    info. In certain communities like Nigeria, having access to World wide web remains relatively new as well as having the ability to actually buy online is even more modern. Listed here are 12 advantages of folks surviving inFitflop Sandals places just like Nigeria to search on the internet just one. Less expensive costs as well as Ensure about items purchaseConsider this cost savings. One example is At the Arden, Helianthus fragrance can be sold for whatever 'tween N8000 to help N12000 inwards malls inside Nigeria. But when you acquire via a trustworthy Web firm it could possibly run you merely N5000 with regard to 100ml, including delivery2. twenty four/vii accessFortunately the world wide web just isn't available to opening or even ending multiplication. It is accessible to you at once that is certainly hassle-free for you personally. The ability to access the top models, most advanced technology, or maybe best-selling e-book twenty-four/7 is unquestionably a good reason to search online. iii. SelectionGone is the time if you are restricted to a couple of trustworthy stores that will Fitflop Sandals share a limited option. The shopping is having entry to an extensive option close to hand and also shopping online offers an probability to select many goods. 5. Preserves timeNigeria can be well known with regard to targeted traffic over-crowding. Cheap fitflop shoes It could take that you simply total morning to visit one department store searching for a set of Nike tennis shoes. Online shopping saves serious amounts of the strain involving being placed in dealings for the complete day.5. Will save on vacation costOk, which means you have now seated within dealings for the complete morning nevertheless can not uncover those people Nike trainers. What spend associated with gas income!! Shopping on-line removes the price of some sort of wasted trip. But additionally consider this to be, you can shop online inside very best retailers in London without needing to obtain a good airline ticket.half-dozen. Entry to Sales along with PromotionsSales normally function each in britain. Winter season along with Summer time product sales. Simply by shopping on the web you happen to be free to make use of sales along with offers that will manage throughout the year.seven. Comparison shoppingBack to our situation. It's got obtained you the total day to go to Palms plaza within Lekki to take into consideration Electronic Arden, Crimson Door. But now an individual

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Вышла версия BIPULSE 6.2

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Новые статьи в библиотеке

Мифы про ГОСТ 34

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2017.
Карта сайта