В прошлой статье Миграция с Exchange 2003 на Exchange 2010 – от сомнений к реализации я писал о том, почему пора мигрировать на Echange 2010. Теперь хочу рассказать о более конкретных вещах. О своем опыте и опыте других, с кем пришлось общаться.
Очевидное.
Многие ниже описанные вещи очевидны. Но мы чаще всего испытываем трудности именно на самых простых вещах: одна ошибка, вторая и путь обратно это уже лабиринт Минотавра. Только взгляд со стороны, чье-то мнение или опыт, помогает перешагнуть «непреодолимое» препятствие высотой в 5 см.
Первое это документация.
Качество документации мне понравилось. Она, конечно, не идеальна, но сделана добротно, хорошо структурирована, содержит практически все, что может пригодиться.
Прежде чем хоть что-то начать делать, обязательно просмотрите документацию, хотя бы бегло, чтобы понять где и что находится – потом это сэкономит вам кучу времени. Документация организована классическим для Microsoft способом:
· Getting started
· Planning
· Deployment
· Operations (такого раздела явно нет, но есть разделы с описанием настройки ролей, прав и т.п., которые собственно и образуют Operations)
· Understanding – это подразделы в разных частях документации, название говорит само за себя: читайте, чтобы понять суть вещей. Именно из-за этих разделов стоит предварительно пролистать всю документацию.
Каждый раздел обязательно содержит что-то полезное, и этого не будет в других разделах. Поэтому не игнорируйте своим вниманием «неважные» разделы.
Подготовка.
Установка Exchange 2010 требует минимум:
· домен—контроллеры Windows Server 2003 Standard Edition with Service Pack 1 (SP1)
· и уровень леса Windows Server 2003 forest functionality mode .
Таким образом, установка возможна в достаточно старом домене – нет обязательного требования домена на Windows Server 2008 и обновления схемы до уровня 2008. Если у вас задача только мигрировать на Exchange 2010, то не надо беспокоиться: когда придет время вы спокойно мигрируете свои домен-контроллеры и схему на новую версию – Exchange 2010 будет работать.
В моем случае процесс шел практически одновременно. Я сначала обновил схему до уровня 2008. Проверил по логам, что все прошло гладко. Поднял один домен-контроллер 2008 R2. Потом была миграция на Excahnge 2010. А уже после полный переход на домен-контроллеры 2008 R2. Даже при таком «непоследовательном» подходе все прошло без катастроф.
Виртуализация.
Найти раздел по виртуализации непросто: Exchange 2010 System Requirements. Разобраться в нем нелегко: написал он несколько путано, но понять можно.
Виртуализировать можно все кроме роли Unified Messaging. Действительно у меня все роли легко поставились на виртуалки и вполне хорошо себя на них чувствуют. С учетом того, что Exchange 2010 предъявляет минимальные требования к дискам системы хранения, можно без опаски использовать сетевые хранилища iSCSI. Если же у вас выделенный сервер, то помните – официально поддерживаются SATA диски. При любой конфигурации можно не тратиться на дорогостоящие варианты хранилища. Даже не верится, что в Exchange 2010 настолько оптимизировали работу с хранилищами, но это действительно так. Самое интересное, что это сильно упрощает нам жизнь, когда приходится проектировать хранилище. Это мы ясно увидим ниже при расчете размера хранилища.
Особо надо отметить, что при использовании DAG на MailBox серверах нельзя использовать никакие «быстрые миграции» ни на Hyper-V (LM), ни на VMVare (HA):
1. Answering Exchange Virtualization Questions and Addressing Misleading VMware Guidance
2. http://technet.microsoft.com/en-us/library/aa996719.aspx
Это не только лишние затраты на лицензии VMVare, но и риск краха всей почтовой системы, т.к. конфигурация не тестировалась и не поддерживается Microsoft. Удивляет подход VMWare: они так обеднели, что готовы продавать бесполезное?
Также обратите внимание на расчет виртуальных процессоров. На одно физическое ядро должно приходиться не больше двух виртуальных процессоров распределенных в виртуальные машины с Exchange 2010. Почему так? Потому что тут кроется фундаментальный обман всех виртуальных платформ: при большом количестве виртуальных сущностей, даже если совокупная нагрузка вроде бы маленькая, но работает медленно – чудес не бывает, и тут издержки примерно такие же, как при многозадачности. Далее. В случае с Hyper-V хостовая система должна иметь достаточно виртуальных процессоров, чтобы обслуживать и себя, и все виртуальные машины с Exchange 2010. Примерное соотношение такое же 2 к 1. К сожалению, как мы видели, VMVare подходит неадекватно к виртуализации Exchange 2010, поэтому нет объективной информации о расчетах для этой платформы. И поэтому я рекомендую опираться на расчеты для Hyper-V и использовать при этом консервативный подход – прелести виртуализации это хорошо, но из одного физического процессора сделать два эквивалентных по мощности виртуальных и преодолеть все законы сохранения ей не под силу.
Еще один момент. Виртуальные машины с Exchange 2010 могут иметь много виртуальной памяти и, соответственно, большой файл свопинга. Когда рассчитываете размер хранилища, в котором будут храниться образы виртуальных машин (а файлы свопинга обычно лежат рядом), то не забудьте учесть эти расходы.
Объем системного диска виртуальный машины мной был выбран размером в 60 Гб. Расчет простой. Система, page-файл, дополнительные программное обеспечение и сам Exchange 2010 занимают около 20-25 Гб. Еще 15-20 Гб на системные расходы: установка обновлений, системные логи и т.п. Еще 20 Гб рабочее место Exchange 2010: очереди, логи и т.п.
Аппаратные ресурсы.
В документации есть разделы по расчету оборудования. Эта как раз та часть документации, которая размещена «нелогично» и часть информации надо искать. Раздел Performance and Scalability –> Understanding Exchange Performance содержит информацию по расчету всех ролей, кроме MailBox. Для него персональный раздел: Planning and Deployment –> Planning for Exchange 2010 – > Mailbox Server Storage Design
Там так все разжевано с примерами, что вопросов не должно возникнуть.
При расчетах учтите, что вам придется ставить антивирус, который потребует для себя процессорных ресурсов и оперативной памяти. При современных тенденциях развития антивирусы чрезвычайно прожорливы. Для расчета можно оценочно ориентироваться на требования Forefront Capacity planning for Forefront Protection 2010 for Exchange Server (Там же инструмент для расчетов).
После первых прикидок мне показалось, что расчеты имеют смысл только для больших инсталляций. Но потом понял, что их надо делать в любом случае: для меня было полезно узнать, сколько ресурсов платформы виртуализации скушает моя инсталяция Exchange.
Хранилище для почтовых ящиков
Расчеты дело хорошее, но рассчитывать можно исходя из разных предпосылок и разных критериев – получим разные результаты. Например, у вас размер базы 50 Гб и вам надо мигрировать на Exchange 2010 – вопрос: какой размер нового хранилища сделать? Расчет даст примерно 75 Гб (Mailbox Server Storage Design).
А реально? Надо же брать размер «на вырост». Рекомендуемый максимальных размер базы 100 Гб. Путь будет так. А вот дальше… Если пользоваться официальной методикой, то рекомендуемый размер хранилища получится 135-150 Гб. Но а если мы хотим сделать DAG? Значит нужно еще одно хранилище такого же размера. Будем использовать циклическое логирование с DAG? Тогда вроде можно сделать хранилище поменьше. Но использовать циклическое логирование при миграции почтовых ящиков с Exchange 2003 слишком рискованно. Значит все-таки побольше. Но тогда потери места будут большие. Сделать поменьше? Но при работе DAG может возникнуть отказ одной базы и как следствие рост ее текущих логов… Вот и получается Гордеев узел.
Решение: самое неприятное это переполнение хранилища (особенно при нештатной ситуации), а раз хранилище на дешевых дисках – вот этот главный фактор решения, то его можно сделать с запасом и на вырост, и на накопление логов без опасности потратить слишком большие деньги. Если принять время жизни реализуемой конфигурации не менее трех лет и соответствующий рост базы за это время до 100 Гб, то хранилища размером в 200 Гб будет достаточно для любых ситуаций и любых манипуляций (сжатие, восстановление…) с базой.
Как видите база с типичного, для времен Exchange 2003 сервера, SCSI винчестера размером в 72 Гб, переезжает на типичный на сегодняшний день SATA винчестер размером 300 Гб, при этом последний значительно выигрывает у своего предшественника относительно затрат – удельные затраты на Exchange 2010 ниже!
Когда я делал такие выкладки, то у меня возникло такое чувство, что сетевое хранилище для Exchange 2010 излишество, и только выгоды виртуализации (это отдельная история) склонили решение в пользу сетевого хранилища. (Это кстати для размышления тем, кто думает, что виртуализация это всегда экономия).
Замечание 1. DAG это двойной расход места в хранилищах.
Замечание 2. DAG с циклическим логированием требует столько же места как при обычном логировании: если синхронизация баз в кластере нарушится, то логи начнут копиться!
Размер базы
Как уже было отмечено, рекомендуемый максимальных размер базы 100 Гб. В тоже время максимальный размер базы 2 Тб.
Почему не надо делать большую базу? Да просто с большим файлом все операции занимают много времени: одно дело скопировать 100 Гб, а другое 1 Тб. Тоже касается операций архивирования и восстановления, сжатия и прочих. Несколько пятиминутных операций на 100 гигабайтной базе вы можете сделать в обед, а на терабайтной базе тоже самое у вас займет всю ночь! Когда рассчитываете количество и размер баз, то учитывайте количество своих бессонных ночей.
Сеть.
Ничего особенного тут нет. Все как обычно. На физическом сервере можно применять средства поставщика сетевого адаптера для обеспечения резервирования физических линков. При виртуализации эту задачу решает сама платформа виртуализации, и усложнять гостевую систему, я не вижу смысла.
Роли
Если число пользователей Exchange невелико (100-200), то можно установить все роли на одном сервере, аппаратном или виртуальном, кроме роли UM.
Если число пользователей больше 200, то становится оправданным разделение ролей для распределения нагрузки и увеличения надежности. Рекомендую схему CA/HUB + MB, т.е. разместить роли CA и HUB на одном сервере, а MB на другом. Схема CA+HUB/MB менее удачная, т.к. транспортный сервер никогда не пишет на локальный MB – только на удаленный, чтобы обеспечить транзакционность и гарантированную доставку письма.
С ростом числа пользователей и увеличением нагрузки нужно следить за производительностью компонентов и добавлять экземпляры нужных ролей.
Первое с чем придется столкнуться это балансировка роли CA: в то время как несколько MB уже есть по сути распределение нагрузки, с балансировкой подключений пользователей придется потрудиться, но это уже отдельная история.
На этом рассуждения о подготовке закончены и дальше речь пойдет о различных ситуациях, которые возникли при миграции с Exchange 2003 на Exchange 2010, и том, как они решались.
Filed under: Exchange | 2 комментария »
ILYA Sazonov: ITPro 