| Новые программы oszone.net |  |
В первой части этого цикла статей мы рассмотрели то, как средние компании обычно разворачивали решение устойчивости сайта с Exchange 2007. К тому же, я описал два сценария, которые будут самыми интересными для средних организаций. В этой части я опишу шаги по развертыванию, необходимые для первого сценария, то есть для модели из двух центров данных. В этом сценарии каждый центр данных будет использовать разное пространство имен и оба центра данных будут иметь подключение к интернету. К тому же, только в основном центре данных будут активные пользователи, если не принимать во внимание те короткие промежутки времени, в течение которых копия активной базы данных переключается на аварийный центр данных по определенным причинам.
Рисунок 1: Устойчивость сайта в Exchange 2010 (модель активный/активный центр данных) Тестовая средаСреда была создана с помощью виртуальных машин на базе Hyper-V R2. Как показано на рисунке 1, среда, используемая в качестве основы в этом цикле статей, имитирует два центра данных: Основной центр данныхОсновной центр данных состоит из:
Аварийный центр данныхАварийный центр данных состоит из:
Поскольку Hyper-V не включает никакой функциональности маршрутизации, я использовал виртуальный роутер Vyatta для изоляции сетей. Я создал четыре сети в роутере и каждой сети репликации разрешено взаимодействовать друг с другом на всех портах. Но все взаимодействия между MAPI сетями и сетями репликации запрещены, так как это не рекомендуется и не поддерживается Microsoft. Все четыре сервера Exchange 2010 работают на базе сервера Windows Server 2008 R2 Enterprise версии, так как для использования DAG группы необходима именно версия Enterprise. Все потому, что как и в случае с CCR и SCR, группа DAG также использует часть компонента Windows Failover Cluster (импульсы, свидетель файлового ресурса и кластерную базу данных). Следует учитывать, что функция Exchange 2010 DAG сама по себе не требует Exchange 2010 Enterprise версии (только версии Windows Server 2008 R2 Enterprise). Это означает, что вы можете использовать версию standard для Exchange 2010, если собираетесь настроить такую конфигурацию в своей тестовой среде. Версия standard лишь ограничивает вас до максимального общего количества в 5 баз данных (включая активные и пассивные копии) на каждом сервере Exchange 2010. На каждый Exchange 2010 сервер установлено по 2 сетевых карты, одна подключена к производственной сети (MAPI), вторая – к изолированной сети репликации. Хотя полезно использовать как минимум две сетевых карты на каждом участнике группы DAG (одна для MAPI доступа и одна для целей репликации, заполнения и импульсов), следует упомянуть, что Microsoft поддерживает использование одной сетевой карты для всех этих целей. Active DirectoryРассмотрение шагов по развертыванию леса Active Directory и настройке AD топологии не входит в цель этой статьи, но, вкратце, среда состоит из 4 контроллеров домена и AD под названием 'Exchangeonline.dk'. Есть два сайта AD, подсеть '192.168.2.0/24' связана с 'Datacenter-1' и подсеть '192.168.6.0/24' связана с 'Datacenter-2'.
Рисунок 2: Подсети и сайты Active Directory Подготовка серверов Exchange 2010В этом разделе мы рассмотрим конфигурацию виртуальных машин, на которые будет установлен Exchange 2010. Сетевые настройкиДве сетевые карты были установлены на каждом из четырех серверов Exchange. Давайте рассмотрим настройки каждой сетевой карты. Для этого откроем 'Сетевые подключения (Network Connections)'. Здесь у нас в списке есть две сетевые карты, и, как вы видите, у нас есть PROD (подключенный к производственной/MAPI сети) и REPLICATION интерфейс (подключенный к изолированной сети, используемой для репликации баз данных, заполнения и импульсов).
Рисунок 3: Сетевые подключения Давайте откроем страницу свойств интерфейса 'PROD'. Здесь можно оставить все по умолчанию. Можно, при желании, убрать галочку с опции 'QoS Packet Scheduler' и 'Internet Protocol Version 6 (TCP/IP v6)'.
Рисунок 4: Свойства карты PROD Откройте страницу свойств 'Internet Protocol Version 4 (TCP/IPv4)'. Здесь у нас настроен статический IP адрес, а также прочие необходимые параметры (основной шлюз, маска подсети и DNS сервер).
Рисунок 5: TCP/IP Version 4 свойства сетевой карты PROD Когда вы настроили сетевую карту должным образом, закройте страницу свойств, дважды нажав кнопку 'OK'. Теперь перейдем к настройке сетевой карты 'REPLICATION'. Для этого открываем страницу свойств карты 'REPLICATION'. Убираем галочки с 'Клиент для сетей Microsoft (Client for Microsoft Networks)' и 'Общий доступ к файлам и принтерам в сетях Microsoft (File and Printer Sharing for Microsoft Networks)', как показано на рисунке 6. К тому же, можно убрать галочки с опций 'Планировщик пакетов QoS' и 'Интернет протокол версии 6 (TCP/IPv6)'.
Рисунок 6: Свойства интерфейса REPLICATION Теперь откройте страницу свойств 'Интернет протокол версии 4 (TCP/IPv4)' и введите IP адрес и маску подсети для изолированной сети репликации. Хотя каждый сервер Exchange должен иметь возможность взаимодействовать с серверами Exchange, расположенными в другой подсети другого центра данных, не следует указывать основной шлюз или DNS серверы, поскольку несколько основных шлюзов через графический интерфейс на сервере Windows 2008 R2 с установленным Exchange 2010 не поддерживаются. Я покажу вам, как решить эту небольшую проблемку маршрутизации чуть позже.
Рисунок 7: TCP/IP Version 4 свойства интерфейса REPLICATION Теперь нажмите кнопку 'Дополнительно (Advanced)' и уберите флажок с опции 'Зарегистрировать адреса этого подключения в DNS (Register this connection's addresses in DNS)', а затем дважды нажмите 'OK'.
Рисунок 8: Дополнительные TCP/IP свойства интерфейса REPLICATION Теперь, когда мы настроили каждую сетевую карту, мы должны убедиться в том, что сетевая карта 'PROD' стоит первой в списке порядка привязки. Для вызова списка порядка привязки необходимо нажать клавишу ALT и выбрать Дополнительно (Advanced) > Дополнительные настройки (Advanced Settings).
Рисунок 9: Выбор дополнительных настроек в меню сетевых подключений Если это еще не так, передвиньте карту 'PROD' в самый верх списка, как показано на Рисунке 10.
Рисунок 10: Порядок привязки сетевых карт Нажмите OK и закройте окно сетевых подключений. Примечание: Конечно, необходимо выполнить вышеописанные шаги на всех четырех серверах. Настройка статических маршрутов для сетей репликацииПоскольку у нас есть две сетевые карты в разных подсетях на каждом сервере и поскольку невозможно указать основной шлюз на нескольких сетевых картах одного сервера, нам нужно создать статические маршруты для сети репликации на каждом сервере Exchange.
Рисунок 11: Окно предупреждения при настройке нескольких основных шлюзов Если вы настроили устройство маршрутизации правильно, каждая подсеть MAPI и каждая подсеть репликации должна быть настроена так, чтобы были разрешены подключения между MAPI интерфейсами и между интерфейсами репликации соответственно. Это означает, что сервер в основном центре данных должен пинговать сервер в аварийном центре данных по Netbios имени (сервера) или IP адресу и наоборот.
Рисунок 12: Пинг с одной MAPI подсети в другую Однако пинг сервера по IP адресу подсети репликации в другом центре данных не должен пройти, так как Windows пытается использовать основной шлюз сети MAPI.
Рисунок 13: Превышение интервала ожидания запроса при пинге сети репликации в другом центре данных Мы можем исправить эту проблему путем создания статического маршрута для подсети репликации в другом центре данных. Если вам доводилось создавать статические маршруты на машинах Windows, вы, скорее всего, использовали для этого команду 'Route Add'. Хотя команда 'Route add' должна добавить маршрут, рекомендации для Windows Server 2008 и R2 изменились. Вместо этого теперь нужно использовать инструмент 'Netsh'. Но не стоит бояться инструмента 'Netsh', поскольку он так же прост, как и 'Route add', небольшое отличие состоит в синтаксисе. Итак, для создания статического постоянного маршрута от подсети 10.10.10.0/24 к 10.10.11.0/24, используя 'Route add', мы бы воспользовались следующей командой: Route add 10.10.11.0 mask 255.255.255.0 10.10.10.203 'p Это бы направляло весь трафик, предназначающийся для 10.10.11.0/24, на шлюз 10.10.10.203, с которого он бы уже направлялся на соответствующие серверы в подсети 10.10.11.0/24. Для создания такого же статического маршрута с помощью инструмента 'Netsh' мы воспользуемся следующей командой: Netsh interface ipv4 add route 10.10.11.0/24 'REPLICATION' 10.10.10.203
Рисунок 14: Создание статического маршрута с помощью Netsh где имя интерфейса сети репликации будет 'REPLICATION', а основной шлюз 10.10.10.203. Примечание: Команда 'Netsh' по умолчанию (в отличие от 'Route add') создаст постоянный статический маршрут. Теперь мы должны иметь возможность пинговать IP адрес в подсети 10.10.11.0/24 и наоборот.
Рисунок 15: Пинг IP адреса подсети репликации в другом центре данных Итак, сетевые подключения настроены должным образом. Подготовка хранилищаВ своей среде я создал четыре виртуальных диска (LUNs) для каждого Exchange сервера. Это сделано потому, что мы будем создавать четыре базы данных почтовых ящиков, каждая из которых будет использовать группу DAG, где у нас есть копия базы данных на каждом сервере Exchange. Это означает, что нам понадобится четыре хранилища LUN для баз данных на каждом сервере в этой конкретной среде. Поскольку у нас более трех копий баз данных, мы включим функцию циклического ведения журналов и расположим файлы журналов в ту же папку, в которой расположены базы данных EDB. На рисунке 16 показаны LUN в диспетчере дисков.
Рисунок 16: LUN хранилища для баз данных на каждом сервере Exchange Итак, на этом завершим 2 часть этого цикла статей. Третья часть будет опубликована в ближайшее время.
Комментарии посетителей
25.02.2015/18:40
Alexchandr
Не подскажите как в Hyper-V можно добавить сетевой адаптер и привязать его к конкретному физическому сетевому адаптеру (для создания сети репликации)? Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
