Exchange Server в VMWare ESXi 4

Шаги:

  1. В Active Directory создают доменную локальную группу "Группа приложений"
  2. В Active Directory создают глобальную группу "Пользователи приложения", добавляет глобальная группа Пользователей приложения как участник к домену Application Group локальная группа.
  3. В Active Directory добавьте как участники пользователи, которым нужен доступ к этому приложению "Пользователям приложения"
  4. На сервере дают чтение и выполняют полномочия NTFS (как минимум) на папке приложения к домену "Application Group" локальная группа. Дайте полномочия записи выходной папке PDF.
  5. На сервере создайте долю на папке приложения. Удаленный Все совместно используют полномочия и добавляют чтение-запись (запись, если выходная папка PDF в той же иерархии), полномочия для "Группы приложений"
  6. Создайте или измените существующий пакетный файл для вызова, приложение с желаемыми параметрами командной строки (удостоверьтесь, что пути UNC в порядке, или подключают диски по мере необходимости).
  7. Тест с пользователем в Пользователях приложения (кто не администратор на сервере),
  8. Передайте методы доступа для конечных пользователей.
2
задан 27 August 2010 в 15:07
4 ответа

Это - официальная позиция Microsoft на предмете: http://technet.microsoft.com/en-us/library/cc794548 (EXCHG.80) .aspx; это связано с Exchange 2007, но никакая более свежая статья не доступна; однако, я не думаю, что намного больше изменило с Exchange 2010.

Длинная короткая история: это будет работать, и это поддерживается, но необходимо запланировать вещи хорошо для вытаскивания хорошей производительности из него.

Надежность так же хороша как базовый физический хост (хосты); ESX/ESXi VMware являются очень стабильными и сформировавшимися решениями для виртуализации, таким образом, Вам не придется волноваться о Вашем хосте (хостах) или VMs, ведущем себя беспорядочно и/или отказывая.

О производительности... это сильно зависит от Вашей рабочей нагрузки. Но если Вы следуете инструкциям для планирования мощностей Exchange 2010 и добавляете еще некоторый ЦП/RAM для компенсации виртуализации наверху (который является, так или иначе, довольно маленьким), система должна работать, а также физическая.

Единственная наиболее критическая точка является, конечно, устройством хранения данных. С ESX/ESXi можно использовать устройство хранения данных SAN точно так же, как Вы использовали бы его с физическим хостом, и в этом случае потеря производительности незначительна; но если Вы вместо этого выполняете VMs от локального устройства хранения данных хоста, затем необходимо будет проявить дополнительную заботу в планировании ДИСКА/КОНФИГУРАЦИИ RAID. Эмпирическое правило: попытайтесь не поместить слишком много VMs на тот же диск/массив и абсолютно не поместить два или больше IO-intensive VMs (такой как серверы почтовых ящиков Exchange и/или SQL Server) на том же.

9
ответ дан 3 December 2019 в 08:40

Считайте RAM по сравнению с диском вводом-выводом.

Exchange 2007 и 2010 с их 64-разрядной архитектурой обменял больше использования RAM на существенно пониженное использование диска. 2010 Exchange может легко поддерживать сотни, если не тысячи пользователей с приемлемой производительностью на единственном SATA управляют. Это предполагает, что у Вас есть 16 ГБ + доступной RAM. Это не было возможно в обмен 2003 без существенной установки RAID или многих luns на SAN.

Также рассмотрите использование функции на 2 010 даг поддержания доступности с помощью нескольких хостов VMware, распространенных в различных точках в сети.

И VMware ESXI и Exchange 2010 доступны в течение пробных периодов. Я предлагаю создать хранилище NFS с помощью Linux или Даже Windows Server и использования что разместить Вас Exchange VM. Затем используйте loadgen инструмент от Microsoft для наблюдения, какую производительность можно получить.

Будущим является Виртуализация и, прямо сейчас, Вы не можете стать намного лучше, чем VMware. Лаборатория все и Вы будете хороши для движения.

1
ответ дан 3 December 2019 в 08:40

Мы делаем точно это. У нас есть среда Exchange 2007, поддерживающая приблизительно 4 400 пользователей в ESX3.5 базирующийся кластер. У нас есть четыре сервера почтовых ящиков, два сервера Концентратора/CA, и два, граничные серверы, все из которых находятся в VM. VM поддерживается массивом хранения данных EVA6100. В течение регулярных производственных часов наши IOps очень хорошо в возможностях массива, и только во время процесса Дефрагментации Онлайн мы, кажется, продвигаем устройство хранения данных к его пределу (о 8K IOps). Это solveable путем поражения, когда мы переделываем дефрагментации, когда мы не делаем резервных копий.

Это было очень надежно для нас.

1
ответ дан 3 December 2019 в 08:40

Ничего себе... У меня есть почти идентичная установка как sysadmin1138...

Exchange 2007

  • 4 сервера почтовых ящиков
  • 2 CAS
  • 2 сервера Концентратора

Это счастливо выполняло четырнадцать кластеров узла ESXi 4.1, поддержанных USP-V Hitachi / AMS2300. Мы работали на EVA 5000 и 4400, но по некоторым причинам эти 5000 просто слишком блин стары, чтобы быть совместимыми с ESXi 4.1. Вы будете видеть, что LUN не исчезают ни на каком серьезном основании. Но это - история в течение другого дня.

Мы были очень довольны нашим Exchange VMs и не имели никаких проблем вообще.

0
ответ дан 3 December 2019 в 08:40

Теги

Похожие вопросы