Exchange в вопросах и ответах: Уходим в группы обеспечения доступности баз данных

  • Статья

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

Хенрик Вальтер

Загадка адресации

Вопрос: Мы развернули Exchange 2010 и обеспечили высокую доступность всех серверов почтовых ящиков за счет использования групп обеспечения доступности базы данных (DAG). Все отлично и работает, как ожидается, за исключением одной небольшой детали.

Когда получивший сообщение, отправленное сотрудником с почтовым ящиком, размещенном в DAG, в свою очередь отправляет другое сообщение сотруднику или получателю в другой организации, заголовок интернет-сообщения полученного сообщения информирует, что серверу почтовых ящиков присвоен APIPA-адрес, например 169.254.5.133. Мы назначили статические IP-адреса всем нашим серверам Exchange 2010, поэтому нам непонятно, почему они отображаются как APIPA-адреса (рис. 1). Может, вы сможете прояснить ситуацию?

Ответ Отлично выбрано время для этого вопроса. Это очень интересный вопрос. Короткий ответ таков: это происходит только тогда, когда серверы почтовых ящиков на базе Exchange 2010 были превращены в высокодоступные за счет использования одной или нескольких групп DAG, а функциональность DAG базируется на WFC-кластере (Windows Failover Cluster). На серверах почтовых ящиков, не входящих в DAG, такое поведение не наблюдается.

Давайте узнаем поближе, что же здесь происходит. Компонент WFC в Windows Server 2008 R2 ожидает, что приложения, использующие WFC, такие как SQL Server, Exchange и файловые серверы, находят кластерные ресурсы определенным образом. Приложение должно подключаться к кластерному ресурсу, находя нужную информацию, используя DNS-сервер.

Эта информация называется точкой клиентского доступа (Client Access Point, CAP). CAP состоит из NetBIOS-имени и одного или нескольких IP-адресов ресурсов. В Windows Server 2008 R2, если сервер поддерживает динамические обновления, информация о CAP регистрируется в DNS, как только CAP переходит в интерактивный режим в WFC.

К сожалению, есть приложения, которые пропускают операцию с DNS и вместо этого подключаются непосредственно к узлу кластера, обращаясь к первому сетевому адаптеру в списке привязки. По умолчанию первым в списке привязки указан виртуальный адаптер WFC-кластера (рис. 2). Этому адаптеру назначается APIPA-адрес.

Figure 1 An APIPA address in an Internet header

Рис. 1. APIPA-адреса в интернет-заголовке

Figure 2 The Microsoft Failover Cluster Virtual Adapter

Рис. 2. Виртуальный адаптер WFC-кластера

Итак, догадайтесь с одного раза, какое приложение не использует DNS для нахождения и подключения кластерного ресурса? Правильно — это Exchange 2010 (к Exchange 2007 это также относится).

Так как же избавиться от этой небольшой неприятности? К счастью, это легко сделать с помощью небольшой утилиты nvspbind, которую можно загрузить с сайта MSDN Code Gallery code.msdn.microsoft.com/nvspbind. Nvspbind специально разработана для изменения сетевой привязки из командной строки.

Давайте проверим порядок привязки адаптеров на сервере командой nvspbind.exe /o ms_tcpip. Как видно на рис. 3, первым указан адаптер Local Area Connection* 9 (это виртуальный адаптер WFC-кластера).

Figure 3 Viewing a binding order list using nvspbind

Рис. 3. Просмотр списка привязки с помощью nvspbind

Нужно переместить Local Area Connection* 9 в нижнюю часть списка. Выполните следующую команду:

nvspbind.exe /- “Local Area Connection* 9” ms_tcpip

Figure 4 Moving Local Area Connection* 9 down the binding order list

Рис. 4. Перенос Local Area Connection* 9 вниз списка

Как видите на рис. 4, подключение Local Area Connection* 9 перенесено ниже в списке привязки. Теперь попытайтесь отправить сообщение электронной почты. Интернет-заголовок теперь должен указывать на реальный IP-адрес сервера (рис. 5).

Figure 5 An Internet header showing the real IP address of the mailbox server

Рис. 5. Интернет-заголовок с реальным IP-адресом сервера почтовых ящиков

Копирование вручную

Вопрос: Мы только что развернули серверы Exchange 2010. Мы планируем использовать группы DAG для обеспечения высокой доступности наших баз данных почтовых ящиков. Мы хотим создать восемь копий каждой базы данных почтовых ящиков. Копии каждой базы данных будут храниться в трех местах, а размер каждой будет примерно 500 ГБ. Из-за ограниченной пропускной способности линии связи к одному из указанных мест, мы ожидаем длительную задержку загрузки копии БД. Поэтому нас интересует, нельзя ли вручную копировать файлы базы данных в удаленную точку, используя USB-диск?

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

Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $false

Далее отключите базу данных…:

Dismount-Database MDB01 -Confirm $false

…и скопируйте базу данных и все журналы в другое место, например на USB-диск.

По завершении копирования обратно подключите копию базы данных:

Mount-Database MDB01

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

Далее добавьте копию базы данных, используя параметр -SeedingPostponed командлета Add-MailboxDatabaseCopy, например так:

Add-MailboxDatabaseCopy -Identity MDB01 -MailboxServer E2K10EX04–SeedingPostponed

Обратите внимание, что операция заполнения (seeding) не выполняется, потому что EDB-файл базы данных и относящиеся к ней журналы уже имеются. Наконец, включите обратно циклическое ведение журналов:

Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $true

Кое-что о странствующих рыцарях

Вопрос: Мы используем Exchange 2010, и у нас много «странствующих рыцарей», активно перемещающихся пользователей, работа которых сильно зависит от Outlook Web App (OWA) (то, что раньше называлось Outlook Web Access). Эти пользователи не могут подключиться к OWA, если их пароль устарел. Мы также обнаружили, что новые сотрудники, у которых при создании учетной записи был включен параметр User must change password at next logon (Требовать смены пароля при следующем входе в систему) (рис. 6), не могут войти в OWA, пока не изменят свой пароль, используя другие способы.

Figure 6 User must change password at next logon enabled

Рис.6. Включение политики смены пароля при следующем входе в систему

Мы миримся с этим неудобством много лет — с тех пор, как перешли с Lotus Domino на Exchange 2003. Не подскажете, можно ли как-то исправить ситуацию?

Ответ: Отлично выбрано время для этого вопроса. Когда в команде разработчиков Exchange начали планировать Exchange 2007 SP3 и Exchange 2010 SP1, разработчики решили устранить невозможность войти в OWA, когда пароль пользователя устарел или действует политика смены пароля при следующем входе в систему. Они придумали утилиту сброса пароля OWA Password Reset Tool. Это модуль IIS 7, который обнаружив факт устаревания пароля, перенаправляет пользователей на совершенно новую страницу смены пароля.

Figure 7 The Outlook Web App 2010 forms-based authentication logon page

Рис. 7. Основанная на формах аутентификационная страница входа в систему приложения Outlook Web App 2010

Давайте посмотрим, как это работает. Пользователь пытается войти в OWA 2007 или 2010, используя страницу входа в систему на основе форм (FBA) (рис. 7). Пользователь перенаправляется на новую страницу Change Password для смены пароля (рис. 8.). Здесь ему придется ввести текущий и новый пароли, после чего щелкнуть кнопку Submit.

Figure 8 The Outlook Web App 2010 Change Password page

Рис. 8. Страница смены пароля в Outlook Web App 2010

Теперь пароль изменен, и пользователь может войти, используя новый пароль. Просто и удобно, не так ли?

Имейте в виду, что после установки Exchange 2007 SP3 или Exchange 2010 SP1 по умолчанию страница смены пароля отключена. Ее придется активизировать, изменив один параметр реестра. Точнее, на каждом сервере Exchange 2007 или сервере клиентского доступа (CAS) Exchange 2010 надо запустить редактор реестра

и в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA создать новый параметр ChangeExpiredPasswordEnabled типа REG_DWORD и присвоить ему значение 1 (рис. 9).

Figure 9 The registry key required to enable Change Password for OWA

Рис. 9. Параметр реестра, включающий смену пароля в OWA

Теперь ваши «странствующие рыцари» всегда смогут подключиться к OWA, независимо от того, устарел ли их пароль или требует ли он смены.

_***Хенрик Уолтер***носит звание Microsoft Certified Master, а также MVP по Exchange 2007 и обладает более чем 15-летним опытом работы в ИТ. Занимает должность архитектора технологий в forTimengoConsulting   (компании, находящейся в Дании и обладающей званием Microsoft Gold Certified Partner), а также работает в качестве технического писателя для Biblioso Corp.(находящейся в США компании, специализирующейся в области услуг по управлению документацией и локализации). Связаться с Хенриком можно по электронной почте v-henwal@microsoft.com. _

Связанные материалы