Первый Exchange 2013 дизайн для предварительной SMB. Я что-то пропустил?

Поскольку это мой первый дизайн, я надеюсь, что перед развертыванием я не пропустил ни одного вопиющего вопроса.

https://i.s tack.imgur.com/0Mcga.png

2 ответа

Предпочтительная архитектура (PA) команды Exchange для Exchange 2013 включает в себя следующие цитаты:

стоимость и сложность системы хранения на основе SAN, которая была в центре Exchange до выпуска 2007 года, побудила группу Exchange увеличить свои инвестиции в стек хранения и развить приложение Exchange для интеграции важных элементов хранилища непосредственно в его архитектура. Мы осознали, что каждая система SAN в конечном итоге выйдет из строя и что внедрение системы с избыточным резервированием с использованием технологии SAN будет непомерно затратным. В ответ на это Exchange превратился из требующего дорогостоящего масштабированного высокопроизводительного хранилища SAN и связанных с ним периферийных устройств к возможности работать на дешевых масштабируемых серверах с обычными низкопроизводительными дисками SAS/SATA в конфигурации JBOD. с товарными дисковыми контроллерами. Эта архитектура позволяет Exchange быть устойчивым к любым сбоям, связанным с хранением, и в то же время позволяет развертывать большие почтовые ящики по разумной цене.

[..]

Физическое оборудование развернуто, а не виртуализировано по двум причинам:

Виртуализация добавляет дополнительный уровень управления и сложности, который вводит дополнительные режимы восстановления, которые не увеличивают ценность, поскольку Exchange предоставляет эквивалентную функциональность из коробки.

Имея виртуальные машины, которые могут отработать отказоустойчивость и внешнее хранилище SAN, а затем размещая сверху группы DAG Exchange, вы не обязательно становитесь "лучше", но вы, безусловно, становитесь "более сложными, дорогостоящими и более затратными".

Имея два физических сервера, два виртуальных сервера, вы делаете большое разделение, но затем вы поддерживаете все с одним и тем же виртуальным диском RAID5, который удаляет некоторые точки отдельных серверов Exchange - если происходит сбой хранилища, оба ваших избыточные серверы отключаются. Это также добавляет некоторую конкуренцию ввода-вывода - ваши записи будут идти в базу данных, в журналы базы данных, а затем реплицироваться в другую базу данных и другой журнал базы данных, все записи в тот же RAID5 и генерации журналов на тех же дисках. Вы сделали какие-либо IOPS или оценки пропускной способности электронной почты?

В вашей настройке достаточно много дисков, поэтому это не может быть узким местом, но из 13 ТБ, доступных в виртуальном диске, ваши LUN для Exchange составляют всего 1,5 ТБ. Означает ли это, что вы планируете разместить 11,5 ТБ несвязанных виртуальных машин на одних и тех же дисках?


35-40 пользователей. 120 почтовых ящиков. > Размер почтового ящика 10 ГБ. и 500 ГБ дисков базы данных, каждый с живой БД и копией? Потому что, похоже, они будут более чем полными с самого начала.

Согласно предпочтительной архитектуре Ignite для Exchange Server, в вашей ситуации нет смысла использовать DAG. Проще говоря - базовая инфраструктура превосходит единственную цель DAG. Рассматривали ли вы Office365 для такого развертывания? К тому времени, когда вы закончите платить за лицензии 2xExchange и CAL, клиент, вероятно, начнет миграцию на следующую версию Exchange (а не на 2016 год, следующую). Если вы собираетесь разместить там множество виртуальных машин, возможно, стоит подумать о назначении ресурсов vCPU и vMemory нескольким другим виртуальным машинам? Обмен это зверь-память. Так было всегда и так будет всегда. Следующая версия использует больше памяти, чем предыдущая, так было всегда.

PS Просмотр презентации настоятельно рекомендуется, она предоставит четкую картину того, как нужно ухаживать и готовить Exchange.

Другие вопросы по тегам