Калькулятор требований к роли сервера почтовых ящиков Exchange 2010 – часть 2
Продолжение…
начало статьи - Калькулятор требований к роли сервера почтовых ящиков Exchange 2010
Конфигурация окружения ( EnvironmentConfiguration )
На первом этапе вводится соответствующая информация о конфигурации почтового окружения: схема отказоустойчивой архитектуры и копий баз данных, параметры данных и ввода-вывода, объем входящей информации для ЦП.
Внимание: для оптимизации объема число почтовых серверов должно быть кратно выбранному общему количеству копий баз данных.
Конфигурация окружения Exchange (Exchange Environment Configuration)
1. Ограничивается ли роль серверов только ролью почтового сервера? Наличие ролей транспортного сервера-концентратора и сервера клиентского доступа одновременно с выполнением задачи почтового сервера влияет на проект с точки зрения распределения нагрузки клиентских запросов, использования памяти и ЦП.
2. Будут ли использоваться группы доступности баз данных ( DAG )? Использование DAG обеспечивает большую гибкость и свободу выбора в вопросе аварийного восстановления: наличие нескольких копий почтовых баз данных, гибкая защита почтовых ящиков вместо традиционного резервного копирования и свободу выбора технологии хранилища (например, RAID или JBOD).
3. Будет ли использоваться катастрофоустойчивая конфигурация? DAG можно "растянуть" на два или более центра обработки данных (калькулятор позволяет только один) без "растягивания" сайта AD или подсети.
4. Какая модель распределения пользователей будет использоваться в катастрофоустойчивой архитектуре? При планировании отказоустойчивой модели в Exchange 2010 необходимо учитывать два момента: модель пространства имен и модель распределения пользователей. Что касается моделей пространства имен или центров обработки данных, Exchange 2010 требует, чтобы оба центра имели конфигурацию «активный/активный». Это значит, что оба центра обработки данных, задействованных в DAG, должны иметь активные, доступные пространства имен и быть способными поддерживать активную нагрузку в любой момент времени. Относительно модели распределения пользователей необходимо отметить, что схема может поддерживать как «активную/пассивную», так и «активную/активную» модель пользовательского распределения. В настоящее время калькулятор поддерживает только «Активную/пассивную» модель. «Активная/пассивная» архитектура пользовательского распределения подразумевает под собой только размещение копий баз данных в резервном центре обработки данных, без активных почтовых ящиков. Также не предусматривается активация копий баз данных (исключение – аварийные ситуации). Тем не менее, центр обработки данных должен поддерживать как переключение отдельных баз данных, так и полную активацию центра обработки данных.
5. Какова допустимая задержка при доставке журналов между ЦОД в условиях катастрофоустойчивой архитектуры? Цель RPO (директивного срока восстановления) – оценить пиковые часы (см. шаг 5), например, 8 утра и 4 вечера, и определить окончательные требования к пропускной способности, принимая во внимание, что период между 8 и 4 часами будет использован для компенсации отставания (в рамках указанного RPO, конечно). Отложенная репликация дает следующие результаты: 1. Active Manager не остановит свой выбор на копии базы данных с большой длиной очереди (если нет иной приемлемой альтернативы). 2. Если длина очереди копии больше, чем установленный параметр AutoDatabaseMountDial, автоматического подключения базы данных после активации не последует. Ручное подключение этой базы данных приведет к потере нескопированных данных.
6. Сколько почтовых серверов будет в главном центре обработки данных? Если имеется больше одного сервера (напоминаем, что для DAG их требуется как минимум два, как максимум - 16), то калькулятор распределит пользовательские ящики поровну между всеми почтовыми серверами и определит рекомендуемую производительность и пропускную способностью для каждого сервера и для всего окружения. Для резервного центра обработки данных калькулятор определяет необходимое количество почтовых серверов на основании требований (количество баз данных, количество копий и т.д.).
7. Сколько DAG планируется использовать? Если DAG больше одной, калькулятор распределяет пользовательские почтовые ящики по всему набору DAG и предлагает рекомендации относительно производительности и пропускной способности для каждого сервера, каждой DAG и для всего окружения.
Продолжение следует…
Перевод: Михаил Даньшин