none
Какое правильное значение количество процессоров выставить в Hyper-V для Exchenge 2013 RRS feed

  • Вопрос

  • Подскажите пожалуйста, на сервере 2 процессора по 4 ядра, какое правильное значение необходимо выставить в Hyper-V в разделе процессора, для максимального быстродействия Exchenge 2013. (2 или 8) Что там указывается количество ядер или количество процессоров?

    И второй вопрос по оперативки, для хорошего быстродействия Exchenge 2013 сколько оперативки надо на 80 пользователей?

    19 июля 2016 г. 8:58

Ответы

  • Если не хотите заморачиваться, то просто забудьте про гипертридинг. Холиваров на эту тему много, а по факту разница в производительности в положительную/отрицательную сторону минимальна. Оставьте как есть. Если у вас ЦП нагружен менее чем на 60% в среднем, то и смысл гнаться за какими-то 1-2% прироста?

    С рейдами точно такая же ситуация - ставьте десятку и не парьтесь. Размеры кластера, как вам советовали выше, лучше вообще оставлять как предлагает контроллер, это справедливо для большинства ситуаций. В конце концов разработчики этого самого контроллера лучше вас знают что лучше и безопаснее в большинстве вариантов. На деле манипуляции с размером кластера могут дать прирост в производительности, но не всегда и поэтому надо тестировать разные варианты на вашей нагрузке. Оно вам надо? Единственное, что надо знать про рейды - не используйте нулевой и пятый в продакшене. 1, 10 - ваш выбор.

    9ГБ оперативки для Exchange в продакшене - непозволительно мало. у меня на тестовой виртуалке выделено 8ГБ и при этом постоянно используется файл подкачки. Нарастите хотя бы до 16ГБ.

    лучше разнести как минимум системный диск и базы данных Exchange. Класть логи на отдельный диск уже смысла нет. Разнесение системы и полезных данных на разные диски - общая рекомендация вообще для любых ситуация (ms sql, exchange, что угодно).

    Вам Роман выше кинул ссылку на очень важный и нужный документ - лучшие практики по виртуализации Exchange 2013, обязательно прочитайте

    • Помечено в качестве ответа Forest_IT 22 июля 2016 г. 8:58
    22 июля 2016 г. 7:07
  • хочу немного дополнить отвечающих.

    У вас виртуальная среда и это как минимум очень хорошо.

    Во-первых, вы можете динамически менять ресурсы виртуальной машины - выставлять необходимое количество виртуальных процессоров, оперативной памяти и т.п.

    Во-вторых, если текущее оборудование вас не будет удовлетворять в плане производительности, вы с легкостью сможете мигрировать на новое железо просто путем копирования виртуальной машины. То есть вы не привязаны практически никак к конкретному серверу.

    Вывод: в вашем случае самым оптимальным вариантом будут наблюдения за производительностью виртуалки и в случае явных подозрений на нехватку ресурсов - их динамическое увеличение.

    Отслеживать потребление ресурсов виртуальной машины вы можете из неё же самой с помощью счетчиков производительности (подробнее читайте тут - https://technet.microsoft.com/en-us/library/dn904093%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396).

    Также есть возможность отследить нагрузку на ЦП виртуалки из операционной системы хоста виртуализации. Для этого вам потребуются счетчики группы Hyper-V Hypervisor Virtual Processor и в ней просто выберите виртуальные процессоры необходимой виртуальной машины.

    • Помечено в качестве ответа Forest_IT 20 июля 2016 г. 8:39
    19 июля 2016 г. 12:30
  • Лучше начните с максимальных значений и уже потом уменьшайте, после пары дней наблюдений. 

    90% это конечно много. На мой взгляд средняя нагрузка не должна подниматься выше 60%. При том кратковременные пики до максимумов вполне допустимы.


    • Помечено в качестве ответа Forest_IT 20 июля 2016 г. 8:39
    19 июля 2016 г. 19:15

Все ответы

  • для такого количества пользователей вполне достаточно 4-6 ядер (2 сокета по 2 или 3 ядра) и порядка 16 GB оперативной памяти, если у вас роли совмещены. И еще, необходимо уточнить производительность каждого ядра физического процессора. Обычно для таких расчетов используют калькулятор Echange, но он больше подходит для больших внедрений, так что примите рекомендованные выше значения.

    Do not multiply entities beyond what is necessary

    19 июля 2016 г. 9:06
  • Тоесть в значении гиперви, там как раз необходимо указать количество ядер сколько использовать? (там же только 1 значение можно указать) количество сокетов то не прописывается!
    19 июля 2016 г. 9:39
  • да, значит либо 4 либо 6 ядер. В зависимости от загрузки хоста. потому что у вас их всего 8 (с HT, если поддерживается - 16).

    Do not multiply entities beyond what is necessary

    19 июля 2016 г. 10:01
  • спасибо, понятно теперь!
    19 июля 2016 г. 10:41
  • Следует заметить, что важно не количество пользователей, а интенсивность их переписки.

    Ящиков может быть хоть миллион, но если они не используются, соответственно не потребляют ресурсы.

    19 июля 2016 г. 10:52
    Отвечающий
  • хочу немного дополнить отвечающих.

    У вас виртуальная среда и это как минимум очень хорошо.

    Во-первых, вы можете динамически менять ресурсы виртуальной машины - выставлять необходимое количество виртуальных процессоров, оперативной памяти и т.п.

    Во-вторых, если текущее оборудование вас не будет удовлетворять в плане производительности, вы с легкостью сможете мигрировать на новое железо просто путем копирования виртуальной машины. То есть вы не привязаны практически никак к конкретному серверу.

    Вывод: в вашем случае самым оптимальным вариантом будут наблюдения за производительностью виртуалки и в случае явных подозрений на нехватку ресурсов - их динамическое увеличение.

    Отслеживать потребление ресурсов виртуальной машины вы можете из неё же самой с помощью счетчиков производительности (подробнее читайте тут - https://technet.microsoft.com/en-us/library/dn904093%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396).

    Также есть возможность отследить нагрузку на ЦП виртуалки из операционной системы хоста виртуализации. Для этого вам потребуются счетчики группы Hyper-V Hypervisor Virtual Processor и в ней просто выберите виртуальные процессоры необходимой виртуальной машины.

    • Помечено в качестве ответа Forest_IT 20 июля 2016 г. 8:39
    19 июля 2016 г. 12:30
  • Спасибо! выставлено сейчас значение 4, скачет сильно процесоры, от 20 до 90 доходит, порой даже в админку не удается войти, попробую в виртуалку до 6 поставить а на хосте 2 тогда пусть пока побудут.
    19 июля 2016 г. 18:24
  • Лучше начните с максимальных значений и уже потом уменьшайте, после пары дней наблюдений. 

    90% это конечно много. На мой взгляд средняя нагрузка не должна подниматься выше 60%. При том кратковременные пики до максимумов вполне допустимы.


    • Помечено в качестве ответа Forest_IT 20 июля 2016 г. 8:39
    19 июля 2016 г. 19:15
  • Best Practices for Virtualizing & Managing Exchange 2013



    Roman Levchenko, MVP, MCSE, MCSA, MCITP, MCTS, VCP6-DCV http://www.rlevchenko.com

    20 июля 2016 г. 8:23
  • Best Practices for Virtualizing & Managing Exchange 2013



    Roman Levchenko, MVP, MCSE, MCSA, MCITP, MCTS, VCP6-DCV http://www.rlevchenko.com

    Именно!! Причем не забывайте, что на хосте с Hyper-V лучше отключить Гипертрейдинг.  Если 80 юзеров и не очень большая интенсивность, то нормально и на виртуалке.. У меня на виртуалке на сервере 4 ядра\16 гиг\ 4 диска вертится порядка 70 юзеров с интенсивностью порядка 300 писем в день. Но учтите, лучше разделить базы и установку+ логи на разные дисковые массивы.
    20 июля 2016 г. 20:22
  • У меня побольше получаеться интенсивность, плюс спам валиться. И стоит 4 ядра, но оперативки всего получилось выделить только 9 гиг, на мониторинге показывает что занято постоянно 8,5. Бывает сейчас днем по раза 2 у всех начинает запрашивать пароль к оутлуку, я так подозреваю что это наверное у сервака экченьжа какаято пиковая нагрузка и пользователи начинают отваливаться. Наверное надо попробовать увеличить ядер до 6 и памяти наверное докупить надо хотябы чтоб на экченьже 16 гигов было. Массив я не понял как отдельно то ставить, ведь я включил рейд 10 на 4 диска и создал виртуалку потом диск, это как надо было? несколько виртуальных дисков создавать и подключать их к виртуальной машине и разносить все, базы,логи, установку? И по Гипертрейдингу подскажите, это что еще за зверь и на что влияет?
    21 июля 2016 г. 15:37
  • Нашел рекомендации по гипертрейтингу. Отключите технологию Hyper-Threading на физических серверах Exchange. Если применяется виртуализация, на физическом сервере можно включить технологию Hyper-Threading, однако при этом каждому виртуальному серверу необходимо выделить только необходимое количество виртуальных процессоров (не допускайте избыточного распределения виртуальных процессоров), а для расчета размера используйте только количество ядер физических процессоров.

    Тогда не понятно, всетаки если используется виртуалка, на физическом серваке (хостовом) включать или не включать гипертрейдинг.

    21 июля 2016 г. 19:41
  • Ну тут много споров.. У Вас на сервере этом еще что то вертится?? Если нет, я бы отключил гипердрейдинг. Про диски - на два "зеркала" мне кажется лучше будет + посмотрите обязательно рекомендации по размерам кластера RAID. Если контроллер позваляет, то его можно сделать 512 для дисков базы, потому как большая часть файлов на нем будет 1 мегабайт ))
    22 июля 2016 г. 5:53
  • Если не хотите заморачиваться, то просто забудьте про гипертридинг. Холиваров на эту тему много, а по факту разница в производительности в положительную/отрицательную сторону минимальна. Оставьте как есть. Если у вас ЦП нагружен менее чем на 60% в среднем, то и смысл гнаться за какими-то 1-2% прироста?

    С рейдами точно такая же ситуация - ставьте десятку и не парьтесь. Размеры кластера, как вам советовали выше, лучше вообще оставлять как предлагает контроллер, это справедливо для большинства ситуаций. В конце концов разработчики этого самого контроллера лучше вас знают что лучше и безопаснее в большинстве вариантов. На деле манипуляции с размером кластера могут дать прирост в производительности, но не всегда и поэтому надо тестировать разные варианты на вашей нагрузке. Оно вам надо? Единственное, что надо знать про рейды - не используйте нулевой и пятый в продакшене. 1, 10 - ваш выбор.

    9ГБ оперативки для Exchange в продакшене - непозволительно мало. у меня на тестовой виртуалке выделено 8ГБ и при этом постоянно используется файл подкачки. Нарастите хотя бы до 16ГБ.

    лучше разнести как минимум системный диск и базы данных Exchange. Класть логи на отдельный диск уже смысла нет. Разнесение системы и полезных данных на разные диски - общая рекомендация вообще для любых ситуация (ms sql, exchange, что угодно).

    Вам Роман выше кинул ссылку на очень важный и нужный документ - лучшие практики по виртуализации Exchange 2013, обязательно прочитайте

    • Помечено в качестве ответа Forest_IT 22 июля 2016 г. 8:58
    22 июля 2016 г. 7:07
  • Ну про гипертрейдинг, если УЖЕ все работает то конечно не стоит трогать. А вот про размер кластера рейд .. Странное у Вас представление, а если в контроллере можно выбрать размер от 64 до 1 мегабайта - это какой тогда рекомендуют?? Просто 64 - для большинства задач. Могу сказать что пока я не сделал именно так, не переделал RAID, не разнес логи и сам Exch на разные диски у меня постоянно была ошибка перегрузки очереди сообщений(хотя системный диск у меня 520 INTEL и два железных сервера с 6 ядерными процессорами, 64 гигабайтами оперативки и 12 корзинами ))) И почему так категоричны к нулевому рейду? Чем он так плох? Да я понимаю про его ненадежность, но в случае если например два Exchange, базы в DAG, но при этом как у меня нужна производительность дисков, то почему бы и нет. Ведь рекомендации MC вообще использовать JBOD. Это так же не надежно.
    22 июля 2016 г. 7:20
  • :)

    контроллер ведь сам предлагает значение по умолчанию, вот его и оставляйте. Эта рекомендация не для вас)) Для тс'а. 

    Конкретно в вашем случае вы уверены, что проблема именно с дисками была? какая была на них нагрузка?

    Если вы понимаете чем потенциально чревато использование raid 0, то вы можете его использовать совершенно спокойно. В случае двух Exchange со всеми базами в DAG использовать RAID0 все также нежелательно. При падении одного сервера у вас остается только один рабочий, который как назло сдохнет тоже в этот же момент))) закон подлости. Минимум 3 сервера. 

    22 июля 2016 г. 7:44
  • Контроллер предлагает значение по умолчанию для того чтобы эта настройка была приемлема для большинства задач. Посмотрите на цены контроллеров. Чем дороже тем больше размер они предлагают и большее колличество разнообразных Рейдов.  Так что тут не все так просто ))

    А по поводу самих массивов. Нуууу.. Понимаете, а сдохнет один и второй в случае JBOD тогда что? На RAID1 все же медленный если использовать обычные диски.  У нас например в конторе практика - не покупаем модные понтовые диски - используем самые обычные Конселейшены Сигейт, которые можно сходить и купить в соседнем здании в ситилинке.. И Вы знаете, такой подход за 10 лет ни дал ни разу сбоев ))) Да дохли БП, сами сервера, но из за выхода из строя дисков ни разу сервисы не останавливались )) а на закон подлости есть еще бекап )))

    22 июля 2016 г. 7:50
  • ладно, не будем продолжать холивар))

    Ситуаций много, вариантов тоже. В контексте этого топика мы обсуждаем случай именно его автора. Для этого случая мой совет - не возиться с гипертридингом, рейды использовать только 10 или 1 (сервер у тс'а наверно один без всяких DAG, так что raid 0 исключен по определению)

    Кстати, у нас тоже практика подобна вашей - самые простые enterprise-диски, чтобы можно было купить в любом "ларьке" (используем WD Re, WD Red, но не суть)

    В идеале до бэкапов доходить не должно)

    22 июля 2016 г. 9:08
  • Да все верно, Диски использую WD Re, Raid 10. Все на одной машине виртуальной крутиться. Но по не опытности и не знанию, а руководство просило скорее скорее ставь на то что есть, вот все и установил без разделения логов и баз. Вот еще начудил, стал заполнять пользователей, увидел возможность делать архивы для некоторых ящиков в другую базу, создал базу еще одну, и некоторых пользователей включил данную возможность, хотя потом подумал зачем дублировать когда бэкап можно делать потом, но в итоге стал далее вносить пользователей, не обратив внимания что в какую базу устанавливается пользователей и теперь получилась такая ерунда, что половина пользователей на одной базе , вторая половина в другой базе. (влияет ли быстродействие экченьжа на количестве баз, как было бы быстрее если бы ящики на одной базе крутились или в нескольких?)
    • Изменено Forest_IT 22 июля 2016 г. 14:22
    22 июля 2016 г. 14:19
  • на быстродействие не влияет. Разве что при очень большом количестве ящиков в базе, но лично я не проверял. 
    22 июля 2016 г. 14:52