Первый дизайн Exchange 2013 для локального SMB. Я что-нибудь пропустил?
Поскольку это мой первый проект, я надеюсь убедиться, что не пропустил ни одной серьезной проблемы перед развертыванием.
Предпочтительная архитектура (PA) группы Exchange для Exchange 2013 включает следующие цитаты:
Стоимость и сложность системы хранения на основе SAN, которая лежала в основе Exchange до выпуска 2007 года, побудили команду Exchange увеличить инвестиции в стек хранилища и развить приложение Exchange для интеграции важных элементов хранилища непосредственно в его архитектура. Мы понимали, что каждая система SAN в конечном итоге выйдет из строя, и что внедрение системы с высокой степенью резервирования с использованием технологии SAN было бы непомерно затратным. В ответ на это Exchange превратился из необходимости в дорогостоящих, масштабируемых, высокопроизводительных хранилищах SAN и связанных периферийных устройств до возможности работать на дешевых масштабируемых серверах с обычными низкопроизводительными дисками SAS / SATA в конфигурации JBOD. с товарными дисковыми контроллерами. Эта архитектура позволяет Exchange быть устойчивым к любым сбоям, связанным с хранилищем, при этом позволяя развертывать большие почтовые ящики по разумной цене.
[..]
Развертывается физическое оборудование, а не виртуальное, по двум причинам:
Виртуализация добавляет дополнительный уровень управления и сложности, что вводит дополнительные режимы восстановления, которые не добавляют ценности, поскольку Exchange предоставляет аналогичные функциональные возможности прямо из коробки.
Имея виртуальные машины, которые могут выполнять аварийное переключение и внешнее хранилище SAN, но затем размещая поверх Exchange DAG, вы не обязательно становитесь «лучше», но вы определенно получаете «более сложные, дорогостоящие и дополнительные накладные расходы».
Имея два физических сервера, два виртуальных сервера, вы делаете много разделения, но затем вы поддерживаете все с помощью одного и того же виртуального диска RAID5, который устраняет некоторые точки отдельных серверов Exchange - если хранилище выходит из строя, оба ваши резервные серверы выходят из строя. Это также добавляет некоторую конкуренцию за ввод-вывод - ваши записи пойдут в базу данных, в журналы базы данных, а затем будут реплицированы в другую базу данных и другой журнал базы данных, при этом все записи будут записываться в один и тот же RAID5 и генерировать журналы на тех же дисках. Вы делали какие-либо оценки IOPS или пропускной способности электронной почты?
В вашей настройке довольно много дисков, так что это не может быть узким местом, но из 13 ТБ, доступных на виртуальном диске, ваши LUN для Exchange составляют только 1,5 ТБ. Означает ли это, что вы планируете иметь 11,5 ТБ несвязанных виртуальных машин на одних и тех же дисках?
35-40 пользователей. 120 почтовых ящиков. > Размер почтового ящика 10 ГБ. и диски базы данных Exchange на 500 ГБ, каждый с живой БД и копией? Потому что похоже, что они с самого начала будут более чем полными.
В соответствии с Предпочитаемая архитектура сервера Exchange Ignite нет смысла делать DAG в вашей ситуации. Проще говоря, базовая инфраструктура превосходит единственную цель DAG. Рассматривали ли вы Office365 для такого развертывания? К тому времени, когда вы закончите оплату лицензий 2xExchange и CAL, клиент, вероятно, начнет миграцию на следующую версию Exchange (не 2016, а следующую). Если вы собираетесь разместить там много виртуальных машин, возможно, стоит подумать о назначении ресурсов vCPU и vMemory нескольким другим виртуальным машинам? Обмен - это чудовище памяти. Так было и так будет всегда. Следующая версия использует больше памяти, чем предыдущая, так было всегда.
P.S. Просмотр презентации настоятельно рекомендуется, она даст четкое представление о том, как лечить и ухаживать за Exchange.