Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
  • Role Based Access Control (RBAC) – новая модель управление доступом к Exchange 2010 (часть 2)

    logo В прошлой статье (http://itband.ru/2010/04/rbac/) мы рассмотрели основные механизмы работы RBAC. Теперь пришло время закрепить полученные знания на практике. Прежде чем приступать к решению конкретных задач, необходимо понять, как происходит процесс аутентификации пользователей на Exchange сервере.

  • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
    • Архивирование средствами Exchange 2010

      archВ финальной версии Exchange 2010 появилась новая функция создания архива почтового ящика. Доступна она в контекстном меню учётной записи почтового ящика оснастки Exchange Management Console в разделе Recipient Configuration.

    • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
      • Role Based Access Control (RBAC) – новая модель управление доступом к Exchange 2010

        loo

        До выхода Exchange 2010 наделение пользователей дополнительными возможностями осуществлялось при помощи функционала делегирования управления и списков управления доступом (ACL). В Exchange 2010 сердцем модели авторизации стала новая система разрешений Role Based Access Control (RBAC).

      • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
        • MS Exchange 2010 и Outlook 2010 – планирование встреч.

          kalendars В Microsoft Outlook 2010 есть новая функция – Расписание (Schedule View), которая делает процесс планирования собраний со своими коллегами и подчиненными более наглядным и быстрым.

           

        • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
          • Аварийное восстановление сервера Exchange 2010

            BackupRecovery UPDATE: Веб-каст по мотивам этой статьи: Теория, Практика.

            Как правило, после успешной установки и настройки сервера, следующее, о чем задумывается системный администратор – это о том, как он его будет восстанавливать в случае аварии. В этой статье мы поговори о том, как можно восстановить полностью вышедший из строя Exchange Server 2010.

          • Главная Exchange/UC, Без рубрики, Новое Exchange 2007, Exchange 2010, Конкурс
            • Миграция с Exchange 2007 на Exchange 2010 в системах с кластерами

              BOX_Microsoft-Exchange2010 Добрый день! Хочу рассказать о своем опыте внедрения Exchange Server 2010. Первоначально этот документ планировался как Step-By-Step Guide для коллег, однако позже он перерос в доклад на заседании MCP-клуба.

              Я работаю системным администратором в небольшой организации, начитывающей 200-250 рабочих мест. Отрасль – энергетика. Регион – Сибирь. Предприятие является головным для нескольких подконтрольных компаний с общей численностью в 4’000 рабочих станций, но при этом само является звеном федерального холдинга. Работа части сотрудников связана с регулярными командировками по разным часовым поясам. В связи со всем вышеперечисленным, почтовый сервис является бизнес-критическим приложением.

            • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Storages, Конкурс
              • Exchange 2010 и SIS

                Small Single Storage Unit В Exchange Server 2010 больше нет системы Единого экземпляра хранения объектов – SIS, Single Instance Storage.

              • Главная Security, Без рубрики, Новое Security, Конкурс
                • Безопасность при работе с мобильными устройствами на предприятии

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

                • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
                  • 10 мифов о хранилищах Exchange 2010

                    computer-mailbox Многие уже слышали о кардинальных изменениях, произошедших в Exchange 2010, которые в совокупности позволили использовать почтовые ящики огромных размеров и доступные хранилища низкой стоимости. И было множество дискуссий о выборе систем хранения для Exchange, среди которых члены команды Exchange Team нашли и несколько интересных высказываний. Для окончательного прояснения ситуации были собраны наиболее часто встречающиеся мифы и заблуждения, а также объяснения к ним, подкреплённые авторитетными источниками.

                    Для лучшего понимания управления почтовыми ящиками больших размеров Microsoft опубликовала Large Mailbox Vision Whitepaper.

                    А теперь — 10 самых распространённых мифов о хранилищах Exchange, поехали!

                    Миф #1: Exchange требует дорогие высокопроизводительные хранилища. «Мы не можем позволить себе большие почтовые ящики!»

                    Правда: Exchange 2010 позволяет легко хранить огромные почтовые ящики на недорогих системах хранения данных. Такие системы показывают приемлемый уровень производительности на дисках низкой стоимости и предоставляют массу опций хранения. Смотрите в Large Mailbox Vision Whitepaper.

                    Миф #2: Exchange 2010 не поддерживает Сети хранения данных SAN (Storage Area Network).

                    Правда: Microsoft в Exchange 2010 отказалась от поддержки NAS (Network Attached Storage, хранилищ, подключаемых к сети) (выглядит похоже, может быть поэтому путают), но масса поддерживаемых вариантов хранилищ включает в себя SAN и DAS (Directly Attached Storage, напрямую подключаемые массивы). В зависимости от вашей модели отказоустойчивости, хранилища могут быть сконфигурированы в RAID массив, или без RAID – JBOD (просто последовательный набор дисков). Разные заказчики используют различные решения, основанные на собственных требованиях, но при этом все имеют возможность размещения почтовых ящиков больших размеров на доступных хранилищах низкой стоимости.

                    Миф #3: «У нас уже есть SAN (или мы только что купили), так что теперь нет смысла применять DAS для Exchange. И кстати, в наш SAN можно подключить и эти дешёвые SATA-диски тоже.»

                    Правда: Это не совсем миф, а просто некоторое недопонимание. Развёртывание SAN имеет смысл, поскольку вы также получаете возможность использования больших почтовых ящиков по низкой стоимости. Помните, что Exchange поддерживает широкий диапазон хранилищ, включая SAN и DAS. Если вы рассчитываете получить преимущество множества независимых копий баз данных – вам следует рассчитывать полную стоимость такого решения.

                    Миф #4: Дисковые конфигурации JBOD непрактичны, потому что процедура повторного насаждения баз данных занимает много времени и требует слишком много усилий.

                    Правда: Microsoft IT очень успешно применяет JBOD конфигурацию при достаточно низкой стоимости такого решения. Однако для управления подобной структурой требуется достаточный уровень опыта администраторов. Существует несколько факторов, влияющих на скорость развёртывания почтовых баз данных, и по внутренним исследованиям Microsoft, там эта процедура с JBOD проходит примерно в 35-70 GB/час.

                    Миф #5: Большие почтовые ящики плохо обрабатываются в Outlook.

                    Правда: Exchange 2010 поддерживает до 100,000 объектов в папке, по сравнению с 20,000 в Exchange 2007. Вдобавок к этому Outlook 2007 SP1, Outlook 2007 SP2 и Outlook 2010 с февральским обновлением 2009г. выдают в режиме кэширования (Cached Exchange Mode) хорошие показатели производительности обработки почтовых ящиков вплоть до 10 GB, и даже больше – до 25 GB на быстрых 7200 или SSD дисках. Ещё больше почтовые ящики? Хранилище Exchange 2010 спроектировано для поддержки очень больших почтовых ящиков – 100 GB+ при использовании Online режима и OWA. Кроме того, вы всегда можете использовать Личные архивы (Personal Archive) Exchange 2010 для снижения общего объёма основного почтового ящика клиентов в кэшированном режиме (Cached Exchange Mode).

                    Миф #6: При миграции на Exchange 2010 базы данных катастрофически увеличатся в размере, поскольку Exchange 2010 не поддерживает Единый экземпляр хранения объектов (SIS, Single Instance Storage).

                    Правда: Руководства по планированию хранилищ Exchange всегда требуют расчёта объёмов без учёта технологии SIS. Технология SIS снижает возможности последовательного доступа Exchange Server к данным, а новые изменения помогают обеспечить снижение количества операций ввода-вывода, I/O, до 70%! Помимо этого, Exchange 2010 умеет сжимать до 20% базы данных на HTML/текстовых сообщениях. Более подробно о SIS в Exchange 2010 читайте здесь, в статье Exchange 2010 и SIS.

                    Миф #7: «Наш администратор Exchange не разбирается в системах хранения данных, это дело экспертов по СХД. Мы считаем, что управление более дешёвыми хранилищами требует больше усилий и времени.»

                    Правда: Microsoft наблюдая и обсуждая с множеством партнёрских организаций применение DAS (в том числе и в собственной сети Microsoft), достоверно выяснила, что нет необходимости в дополнительных администраторах для обслуживания множества менее дорогих хранилищ или увеличении времени на их обслуживание. В дорогих системах хранения данных можно потратить массу времени и ресурсов на их оптимизацию. А более доступные хранилища позволяют вам применять классический подход к их управлению и планированию ресурсов. И хранилища в таком случае требуют внимания не более чем на обновление прошивок или замену дисков при отказе. При этом обычные администраторы серверов могут управлять такими хранилищами (обновление драйверов и прошивок), без специальных навыков.

                    Миф #8: Большие базы данных Exchange невозможно бэкапить.

                    Правда: Имея функционал множественных копий баз данных (DAG), отложенной репликации баз и восстановления отдельных писем – традиционная архивация перестаёт быть острым моментом. Эти технологии позволяют реже проводить архивацию, вплоть до полной архивации раз в неделю или даже в две. Архивировать можно пассивные копии баз данных, а также задействовать экспресс-архивацию DPM, для экономии дискового пространства.

                    Миф #9: «Нам понадобится сторонне решение архивации, потому что базы Exchange нужно хранить в крутом и мощном хранилище, а у нас такого нет.»

                    Правда: Данные Exchange можно держать на любых хранилищах! И не только архивные копии. При достаточной степени продуманности можно совмещать «горячие» и резервные данные, для лучшей утилизации огромного дискового пространства по низкой цене, что также упрощает управление.

                    Миф #10: «Все проекты хранилища для Exchange должны досконально соответствовать показаниям Exchange Mailbox Role Requirements Calculator! В противном случае получится неподдерживаемое решение.»

                    Правда: Exchange Mailbox Role Requirements Calculator (для Exchange 2010 / Exchange 2007) предоставляет рекомендации по проектированию, а не поддерживаемым решениям хранения. А вот Exchange Solution Reviewed Program (ESRP) – содержит информацию от партнёров специализирующихся на выпуске хранилищ.

                    Не верьте мифам!

                    Maxim E. Zinchenko

                  • Главная Exchange/UC, Без рубрики, Новое DAG, Exchange 2010, NLB, Конкурс
                    • Отказоустойчивый Exchange 2010 (DAG + NLB)

                      exchange20102

                      UPD: Исправлен недочет в разделе организации NLB-массива.

                      Сегодня ни кто уже не будет спорить, что почтовая система в каждой организации является одним из самых важных и уязвимых мест. Сточки зрения бизнеса, корпоративная почта должна быть доступна в режиме 24/7, т.к. часто запоздалая отправка, либо несвоевременное получение всего одного письма может принести компании ощутимый финансовый и имиджевый урон. В связи с этим, ИТ-администраторы предпринимают всяческие меры по обеспечению отказоустойчивости почтовых серверов. До выхода Exchange 2007 это было достаточно не простой задачей. Затем в 2007-м Exchange`е компания Microsoft изменила эту ситуацию, введя две новые функции CCR и SCR, которые, надо заметить, были весьма успешными в деле организации безаварийной работы.

                      С выходом Exchange 2010, Microsoft пошла ещё дальше и улучшила функции CCR и SCR, соединив две функции в одном компоненте DAG (Database Availability Group), DAG стала новой функцией непрерывной доступности баз данных почтовых ящиков. Функция DAG, как и CCR, зависит от ограниченного набора компонентов отказоустойчивой кластеризации Windows (Failover Cluster), в основном, от базы данных кластера, файлового ресурса-свидетеля и функции импульса синхронизации. Группы DAG обеспечивают защиту на уровне базы, сервера и узла и делают развертывание решения высокой доступности и аварийного восстановления на уровне сайта гораздо проще, нежели в предыдущих версиях Exchange.

                      Но обеспечить отказоустойчивость баз данных это ещё пол дела, также нужно обеспечить непрерывный доступ самих пользователей к этим базам данных. Как известно, за работу с почтовыми клиентами в Exchange отвечает CAS (Client Access Service). Для организации отказоустойчивости этой службы существует Client Access Array, который позволяет объединить несколько CAS серверов в массив, а затем настроить доступ к FQDN этого массива при помощи стандартного Windows NLB (Network Load Balancing) кластера.

                      Кроме ролей Mailbox Server и Client Access Server существует ещё и роль транспортного сервера-концентратора (Hub Transport Server), как же быть с ней в плане отказоустойчивости? А с ней совсем делать ни чего не надо, достаточно установить на два или более сервера Exchange 2010 эту роль и отказоустойчивость будет обеспечена автоматически, т.к. транспортные серверы-концентраторы Exchange отказоустойчивы по умолчанию. То есть, при наличии более чем одного транспортного сервера-концентратора, развернутого на сайте Active Directory, и в случае недоступности одного из транспортных серверов-концентраторов в этом сайте Active Directory исходный транспортный сервер-концентратор, пытающийся доставить сообщение, перейдет к следующему транспортному серверу-концентратору в этом сайте Active Directory. Это проделывается с помощью механизмов циклического опроса DNS (если первый транспортный сервер-концентратор в списке не отвечает, переходим к следующему). Так что когда речь заходит о связи между двумя транспортными серверами-концентраторами или между сервером почтового ящика и транспортным сервером-концентратором (то есть внутренней), нам не нужно заботиться о высокой доступности (или балансировке, если на то пошло), поскольку это собственные функции Exchange 2010. Но не забывайте, что в случае установки роли транспортного сервера-концентратора на компьютере, где также установлена роль сервера почтовых ящиков, роль сервера почтовых ящиков будет предпочитать локальный транспортный сервер-концентратор любым другим транспортным серверам-концентраторам в сайте Active Directory (даже если локально установленный транспортный сервер-концентратор недоступен), когда служба отправки почты Microsoft Exchange отправляет сообщения. Но данный факт не относится к серверам, включенным в DAG группу. В случае, если Hub Transport`ы установлены на сервера MailBox, входящие в DAG, то сервера почтовых ящиков будет предпочитать любой другой Hub Transport в сайте AD, и только в последнюю очередь будут обращаться к локальным.

                      Теперь перейдем от теории к практике и посмотрим, как обеспечить отказоустойчивость Exchange 2010.

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

                      Рис.1. Принципиальная схема почтовой системы предприятия

                      Примечание: Настройку сервера EDGE Transport в этой статье рассматривать не будем (о ней можно почитать тут). Так же не будем рассматривать процедуру установки Exchange серверов (это совсем не сложно), единственное, в чем хочу вас предостеречь, так это в том, что не стоит пытаться устанавливать несколько серверов одновременно (даже в тестовой среде), необходимо дождаться окончания установки одного сервера, а затем приступать к инсталляции другого, в противном случае системные ошибки неизбежны.

                      Перейдем к настройке Database Availability Group

                      Важно отметить, что в каждую DAG группу может входить до 16 серверов почтовых ящиков, таким образом, вы сможете иметь до 16 копий каждой базы (хранение более одной копии базы почтовых ящиков на каждом сервере не поддерживается, а также активной может быть только одна копия), причем нужно не забывать, что каждый Exchange 2010 Standard может поддерживать только 5 баз данных, а Enterprise версия – до 100 баз. Время переключение между базами в Exchange 2010 заметно снижено, и теперь составляет порядка 30 секунд, а если учесть тот факт, что клиенты общаются с базами данных через Client Access Servers, то они совсем не заметят этого перехода. Также в Exchange 2010 предпринята попытка отказаться от публичных папок (Public Folders), и хотя они все ещё поддерживаются, но теперь их нельзя включить в группу DAG и обеспечивать их доступность придется при помощи стандартных механизмов репликации баз данных публичных папок.

                      Как уже говорилось выше, группы DAG в своей работе используют часть компонентов системы отказоустойчивых кластеров (Failover Clusters), таким образом, как и в классическом отказоустойчивом кластере, серверам нужно иметь по два сетевых интерфейса: один для MAPI-доступа клиентов, другой для трафика heartbeat/replication, по которому будет отслеживаться состояние узлов кластера. Хотя решения с одним сетевым интерфейсом на каждом сервере поддерживаются, но мы не будем экспериментировать и возьмем две сетевых карты, одна будет смотреть в локальную сеть предприятия и будет иметь адрес из диапазона 192.168.0.0/24, другая – в изолированную сеть с адресным пространством 192.168.1.0/24.

                      Рис.2: Принципиальная схема Database Availability Group

                      На интерфейсе для Heartbeat`ов можно отключить такие компоненты сетевого взаимодействия, как TCP/IPv6, Client for Microsoft Network, File and Printer Sharing и
                      даже QoS. Затем надо проверить что локальный сетевой интерфейс находится первым в списке порядка привязки, для этого пойдем в меню Advanced (Дополнительно) > Advanced Settings (Дополнительные параметры) и посмотрим в раздел Connections.

                      Что касается организации хранилищ для баз данных почтовых ящиков, то теперь вам не придется приобретать высокоскоростные, а, следовательно, и дорогие жесткие диски. В связи с изменениями в механизме расширяемого хранилища (ESE), с Exchange 2010 вы получаете вариант использования таких дисков с низкой производительностью, как диски SATA 7200! Фактически, вы можете размещать активную копию базы данных на одном SATA диске, а все остальные копии вместе – на другом, и ни каких проблема с производительность дисковой подсистемы у вас быть не должно. Правда тут надо заметить, что вместе с улучшениями в организации работы с жесткими дисками, у Exchange 2010 ещё более возрос аппетит к оперативной памяти сервера и теперь, Microsoft говорит, что !каждую роль! Exchange 2010 необходимо обеспечить 4 Гб оперативной памяти. Возможно это и некоторое преувеличение, но практика покажет, как дела обстоят на самом деле.

                      Для функционирования DAG, кроме самих серверов Exchange 2010 необходим ещё один сервер, не входящий в группу DAG, он будет выполнять роль сервера-свидетеля, это что-то вроде кворума в классическом отказоустойчивом кластере и именно с помощью него отслеживается состояние серверов, входящих в DAG. Для организации сервера-свидетеля подойдет любой сервер в сайте Active Directory, даже без установленного Exchange 2010, единственным условием его функционирования является то, что в группу его локальных администраторов должна входить доменная группа Exchange Trusted Subsystem.

                      Рис.3: Доменная группа
                      Exchange Trusted Subsystem в группе локальных администраторов сервера-свидетеля.

                      Итак, все подготовительные работы завершены, теперь давайте создадим новую DAG-группу. Для этого перейдем в раздел Organization Configuration (DAG находится именно на уровне организации), откроем вкладку Database Availability Groups и в меню Действия выберем New Database Availability Group… Откроется мастер конфигурирования DAG:

                      Рис.4: Мастер настройки DAG

                      Здесь нужно вписать имя группы, имя сервера-свидетеля (не забываем, что он не должен входить в DAG) и имя папки, где будет храниться информация о состоянии Exchange серверов (мастер создаст папку на удаленном сервере сам). Далее, если все настроено правильно, то мастер создаст группу и следующим шагом нам нужно будет добавить в неё сервера, для этого нажмем на группе правой кнопкой мыши и выберем пункт Manage Database Availability Group. В данном мастере необходимо добавить сервера с установленной ролью Mailbox, которым мы хотим обеспечить высокую доступность:

                      Рис.5: Добавление серверов в группу DAG

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

                      Примечание: Если что-то пошло не так и кластер не собрался, то часто бывает трудно оценить проблему по тексту ошибки, выданному Exchange`м, в такой ситуации может помочь функция проверки узлов кластера в Диспетчере отказоустойчивости кластеров, которая дает гораздо больше информации по присутствующим проблемам:

                      Рис.6: Проверка кластера.

                      Если у вас в сети нет DHCP сервера, то DAG соберется, но будет в неактивном состоянии, т.к. группе не будет назначен IP адрес (состояние кластера можно также посмотреть в Диспетчер отказоустойчивости), чтобы исправить эту неприятность, необходимо воспользоваться командлетом New-DatabaseAvailabilityGroup с параметром DatabaseAvailabilityGroupIPAddresses, вот как-то так:

                      New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 192.168.0.5

                      Когда группа DAG у вас будет собрана и активна, необходимо сделать копии баз данных на «соседних» серверах (не забывайте, что каждый сервер может хранить только одну копию базы). Чтобы создать копию базы данных, нажмите правой кнопкой мыши на исходной базе и выберите пункт меню Add Mailbox Database Copy…, далее откроется мастер, в котором нужно указать на каком сервере будет размещена копия и приоритет её активации:

                      Рис.7: Создание копии базы данных.

                      Если вам не нравится GUI, то можно это сделать с помощью командлета:

                      Add-MailboxDatabaseCopy -Identity MDB2 -MailboxServer Server3 -ActivationPreference 2
                      

                      Создать копию базы данных с временем задержки воспроизведения и временем задержки усечения можно только из командной консоли Exchange (здесь 10 и 15 минут соответственно):

                      Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 00:10:00 -TruncationLagTime 00:15:00 -ActivationPreference 2
                      

                      Таким образом, мы получаем несколько копий исходной базы данных, расположенные на разных серверах и в разных хранилищах. Чтобы активировать одну из копий, нужно нажать на ней правой кнопкой мыши и из выпадающего меню выбрать Activate Database Copy, после чего в открывшемся окне решить стоит ли перезаписывать параметры базы и нажать ОК, далее база данных будет автоматически смонтирована на другом сервере и её состояние измениться с Healthy на Mounted:

                      Рис.8: Переключение баз почтовых ящиков.

                      Примечание: Если вам необходимо сделать заполнение (обновление) одной из копий баз данных, то перед этим нужно приостановить её работу командой Suspend Database Copy, а затем выбрать пункт Update Database Copy…

                      Рис.9: Обновление копии базы данных почтовых ящиков.

                      Перейдем к настройке массива серверов CAS

                       

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

                      Рис.10: Принципиальная схема взаимодействия серверов в CAS массиве.

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

                      Т.к. массив CAS используется только клиентами Outlook MAPI, то для обеспечения отказоустойчивости таких сервисов как Outlook Webb App, Exchange ActiveSync, Autodiscover и других, необходимо решить, что именно у вас будет выполнять роль балансировщика сетевой нагрузки (NLB). Microsoft рекомендует использовать для этих целей внешние аппаратные устройства, но если у вас таковых нет, то служба Windows Network Load Balancing вполне подойдет. Здесь нужно иметь в виду, что службы Windows NLB и Failover Cluster на одном сервере не живут!

                      Для работы WNLB (как и других систем балансировки), необходимо иметь на DNS сервере запись, указывающую на виртуальный IP-адрес этой системы:

                      Рис.11: Настройка DNS сервера.

                      Далее давайте настроим Windows NLB кластер, для этого установим соответствующие компоненты в диспетчере сервера, затем откроем Диспетчер балансировки сетевой нагрузки в меню Администрирование и создадим новый кластер.

                      Рис.12: Создание нового кластера NLB.

                      В открывшемся мастере введем имя первого узла кластера и укажем локальный сетевой интерфейс. В следующем окне менять ни чего не нужно. Далее, добавим IP-адрес нашего кластера и укажем маску. Затем нужно настроить параметры кластера:

                      Рис.12: Настройка параметров кластера.

                      Снова введем IP-адрес и FQDN имя, указанное ранее в DNS сервере. Следующим шагом, нужно будет определить, какой режим работы выбрать, если кратко, то в одноадресном режиме, МАС адрес сетевого адаптера каждого сервера будет заменен виртуальным МАС адресом кластера и будет использоваться всеми серверами кластера. В многоадресном режиме МАС адрес добавляется в адаптер кластера на каждом сервере и каждый сервер сохраняет свой МАС адрес. Рекомендуется использовать Одноадресный режим!

                      Подробнее про принцип работы NLB можно посмотреть здесь.
                       Отдельное спасибо Александру Станкевичу за детальное описание данного механизма!

                      Примечание: Если вы развертываете Exchange 2010 сервера в виртуальной среде, то при работе WNLB могут возникнуть проблемы, поэтому, если вы разворачиваете узлы кластера на платформе виртуализации VMware ESX Server, то вам придется использовать Многоадресный режим. Если же вы работаете с MicrosoftHyper-V, то лучше включить Одноадресный режим, но при этом внести некоторые изменения в настройки виртуального сетевого адаптера, а именно – настроить Статический МАС-адрес и включить функцию спуфинга МАС адресов.

                      Рис.14: Настройка сетевых интерфейсов в Hyper-V

                      В следующем окне мастера нужно определить какие порты будут использоваться в данном кластере. Вы можете по-умолчанию оставить открытыми все порты, а можете открыть следующие:

                      • TCP/135 – для работы CAS-массива (убедитесь, что в Filtering Mode свойство Affinity включено в Single);
                      • TCP/1024-65535 – диапазон RPC портов для MAPI-клиентов и CAS (если у вас не указаны статические порты);
                      • TCP/443 – для Outlook Anywhere, Exchange ActiveSync и Outlook Web App;
                      • TCP/993 – для Secure IMAP (Affinity включено в None);
                      • TCP/995 – для Secure POP (Affinity включено в None);
                      • TCP/80 – для внутреннего IIS перенаправления (HTTP > HTTPS).

                      Далее нажимаем Готово и добавляем ещё один узел к кластеру, нажав на созданном кластере правой кнопкой мыши и выбрав пункт Добавить узел к кластеру. У нового узла значение приоритета выставляем в 2 и все остальные параметры оставляем по-умолчанию.

                      Теперь осталось только собрать сам CAS массив.

                      Для этой цели воспользуемся командлетом New-ClientAccessArray:

                      New-ClientAccessArray -FQDN "mail.test-mail.local" –Site "Default-First-Site-Name"
                      

                      И подключить к массиву базы данных почтовых ящиков командлетом Set-MilboxDatabase:

                      Set-MailboxDatabase -RpcClientAccessServer "mail.test-mail.local"
                      

                      Рис.15: Создание CAS массива.

                      Проверить результат можно командлетом Get-MilboxDatabase.

                      На этом настройка массива CAS серверов заканчивается, проверить работоспособность массива можно запустив MS Outlook, служба Autodiscover должна разрешить имя сервера как FQDN массива.

                      Рис.16: Настройка MS Outlook.

                      Статьи для подробного изучения:

                       

                      PS. Нужно иметь ввиду, что отказоустойчивые решения для систем виртуализации, в частности Failover Cluster для Hyper-V, использующие Live Migration, нельзя комбинировать с решениями репликации Exchange (ССR или DAG). Рекомендуется настраивать CCR или DAG на узлах Hyper-V не включенных в Failover Cluster и, соответственно, не использующих Cluster Shared Volumes.

                      Запуск CCR или DAG на кластере с Live Migration не поддерживается!

                      PPS. Если вам потребуется изменить URL`ы таких служб, как OWA (Outlook Web App), ECP (Exchange Control Panel), Exchange ActiveSync (EAS) и Outlook Anywhere (OA), то об этом вы сможете почитать тут.

                      Алексей Богомолов (Alexx)