Comments 17
В данный момент эксплуатируем 3Par 7400 и кучу MSA2000 G3, готовимся к апгрейду их контролеров на MSA 2040. Судя по тому, какой функционал был засунут в 2040 с последним обновлением прошивки, хочется назвать этот массив «микро-3Par». И да, работа c 3Par после массивов одной из фирм на 3 буквы, это глоток свежего воздуха. Рекомендую всем, кто в стадии выбора.
сколько примерно стоит замена контроллеров MSA2000G3 --> 2040?
Ритейл за один контролер где-то 270к рублей. Однако, хочу заметить, что если покупать много и напрямую у НР, то всегда можно договориться о значительных (вплоть до 40%) скидках. Так же замечу, что у 2040 четыре FC-порта, в отличие от двух на G3, что позволяет получить значительную экономию, если наращивать простые кластера, например, VmWare из 2-х машин до трех или четырех, так как в этом случае отпадает необходимость в покупке SAN-свитчей, которые сами по себе могут стоить по 300к за штуку.
после апдета до 2040, «гарантия» будет по прежнему привязана к серийнику шаси MSA2000 G3?
в 2015 году в сравнении с 2014 кер паки выросли в цене 1200 уе против 700 уе за пакет U2MR4PE (1 year post warranty Next business day). =\
в 2015 году в сравнении с 2014 кер паки выросли в цене 1200 уе против 700 уе за пакет U2MR4PE (1 year post warranty Next business day). =\
Или картинка про Exchange не правильная, или в описании пункт 5 лишний.
К Thin Provisioning для серверов стоит подходить с осторожностью. Если у вас нет мониторинга (или вы на него не обращаете внимание), то Thin Provisioning рано или поздно приведет к неприятностям. Встречал на практике ситуацию, когда существенная часть сервисов одновременно остановилась из-за нехватки места.
Хотелось бы напомнить, что best practice для Microsoft Exchange 2013 является размещение продукта на физических серверах.
Еще несколько комментариев:
Очевидно, что возможность создания DAG никак не зависит от использования виртуализации. Более того, виртуализация и DAG (на базе Microsoft Failver Cluster) — это довольно неприятная в настройке конструкция. Миграция виртуальных машин, VMware DRS развалят ваш кластер за минуту. Хорошо, что на работу продукта и клиентов это скорее всего не повлияет. Немало приятных вещей будет ждать вас и при настройке NLB-кластера для CAS серверов в виртуальной среде.
В этом нет сомнений. Ведь для 750 Tier-1 ящиков понадобится (700*0,335)*2= 469 IOPS
blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange-2013-deployments.aspx
Что вы предлагаете делать с 82 000 — 469 = 81531 IOPS? Запустить на них еще 121 688 ящиков? :) Тактической ядерной ракетой по воробьям.
«Увеличивается надёжность системы: виртуализация позволяет администраторам создавать группы Database Availability Group (DAG) и использовать средства репликации баз данных Exchange, задействуя минимум аппаратных ресурсов.»
Очевидно, что возможность создания DAG никак не зависит от использования виртуализации. Более того, виртуализация и DAG (на базе Microsoft Failver Cluster) — это довольно неприятная в настройке конструкция. Миграция виртуальных машин, VMware DRS развалят ваш кластер за минуту. Хорошо, что на работу продукта и клиентов это скорее всего не повлияет. Немало приятных вещей будет ждать вас и при настройке NLB-кластера для CAS серверов в виртуальной среде.
«на серверах ProLiant DL380p Gen8 с дисковыми массивами HP MSA 2040 можно поддерживать порядка 750 почтовых ящиков Exchange 2013»
В этом нет сомнений. Ведь для 750 Tier-1 ящиков понадобится (700*0,335)*2= 469 IOPS
blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange-2013-deployments.aspx
Что вы предлагаете делать с 82 000 — 469 = 81531 IOPS? Запустить на них еще 121 688 ящиков? :) Тактической ядерной ракетой по воробьям.
В этом примере виртуальных машин VMware вообще нет, виртуализация средствами Hyper-v.
Можно настроить массив MSA так, чтобы виртуальные машины VMware и Exchange жили на разных пулах, не мешая друг другу.
У Microsoft есть рекомендация не использовать на одном и том же железе NLB и failover cluster: «These two components work well together in a two or three tier application model running on separate computers. Be aware that running these two components on the same computer is unsupported and is not recommended by Microsoft due to potential hardware sharing conflicts between Cluster service and Network Load Balancing.»
support.microsoft.com/en-us/kb/235305
Для frontend/backend конструкции можно использовать NLB, чтобы распределить нагрузку равномерно по frontend. А для backend серверов уже настроить Failover Cluster, т.к. почти уверен, что пока Microsoft не поддерживает конфигурацию нескольких серверов (физических или виртуальных) с общим datastore в среде Exchange.
Для Exchange 82000 IOPs не нужны, нужно порядка 0.335 IOPs на ящик, в референсной архитектуре массива не используются SSD и SAS диски.
Цифра 82000 актуальна для виртуализации в среде VMware, здесь уже требования к IOPs выше.
Можно настроить массив MSA так, чтобы виртуальные машины VMware и Exchange жили на разных пулах, не мешая друг другу.
У Microsoft есть рекомендация не использовать на одном и том же железе NLB и failover cluster: «These two components work well together in a two or three tier application model running on separate computers. Be aware that running these two components on the same computer is unsupported and is not recommended by Microsoft due to potential hardware sharing conflicts between Cluster service and Network Load Balancing.»
support.microsoft.com/en-us/kb/235305
Для frontend/backend конструкции можно использовать NLB, чтобы распределить нагрузку равномерно по frontend. А для backend серверов уже настроить Failover Cluster, т.к. почти уверен, что пока Microsoft не поддерживает конфигурацию нескольких серверов (физических или виртуальных) с общим datastore в среде Exchange.
Для Exchange 82000 IOPs не нужны, нужно порядка 0.335 IOPs на ящик, в референсной архитектуре массива не используются SSD и SAS диски.
Цифра 82000 актуальна для виртуализации в среде VMware, здесь уже требования к IOPs выше.
Проблемы виртуализации Exchange — это не проблемы ESXi, это архитектурная проблема виртуализации продукта. Не проблема в общем-то, а определенные нюансы и ограничения.
Что же касается использования Failover Clustering и NLB на одном сервере, то еще с Exchange 2010 это несопровождаемая конфигурация
technet.microsoft.com/en-us/library/jj898588(v=exchg.150).aspx
Если отбросить техномаркетинговые документы, то упоминание Microsoft Exchange совместно с массивом HP MSA выглядит просто странным. Для 750 ящиков достаточно производительности 2 x SAS 15k дисков. Не надо сбивать людей с толку, чтобы они под почтовую систему купили эту СХД — пустая трата денег. Если хочется сделать с нуля что-то хорошее, то лучше не использовать дизайн из вашего документа. Ориентируйтесь на «The Preferred Architecture» blogs.technet.com/b/exchange/archive/2014/04/21/the-preferred-architecture.aspx, и вы построите более надежную и простую систему.
Что же касается использования Failover Clustering и NLB на одном сервере, то еще с Exchange 2010 это несопровождаемая конфигурация
technet.microsoft.com/en-us/library/jj898588(v=exchg.150).aspx
WNLB can't be used on Exchange servers where mailbox DAGs are also being used because WNLB is incompatible with Windows failover clustering. If you're using an Exchange 2010 DAG and you want to use WNLB, you need to have the Client Access server role and the Mailbox server role running on separate servers.
Если отбросить техномаркетинговые документы, то упоминание Microsoft Exchange совместно с массивом HP MSA выглядит просто странным. Для 750 ящиков достаточно производительности 2 x SAS 15k дисков. Не надо сбивать людей с толку, чтобы они под почтовую систему купили эту СХД — пустая трата денег. Если хочется сделать с нуля что-то хорошее, то лучше не использовать дизайн из вашего документа. Ориентируйтесь на «The Preferred Architecture» blogs.technet.com/b/exchange/archive/2014/04/21/the-preferred-architecture.aspx, и вы построите более надежную и простую систему.
Спасибо, это ваше мнение.
Применение MSA для Exchange — это только один из возможных сценариев, как минимум, имеющий преимущество в гибкости инфраструктуры с точки зрения роста ресурсов, так и в том, что вы используете меньше серверов, т.к. в этом случае роли виртуализиованы.
Только два диска SAS 15k не сможем поставить, этого, скорее всего, хватит для ОС, из этого же документа: «Each server houses a single RAID1 disk pair for the operating system, Exchange binaries, protocol/client logs, and transport database».
Применение MSA для Exchange — это только один из возможных сценариев, как минимум, имеющий преимущество в гибкости инфраструктуры с точки зрения роста ресурсов, так и в том, что вы используете меньше серверов, т.к. в этом случае роли виртуализиованы.
Только два диска SAS 15k не сможем поставить, этого, скорее всего, хватит для ОС, из этого же документа: «Each server houses a single RAID1 disk pair for the operating system, Exchange binaries, protocol/client logs, and transport database».
В части производительности, конечно, это мнение, основанное на типичных IOPS 15k SAS диска, которое обязательно надо подтверждать тестированием. Предпочитаемая архитектура — это мнение вендора, основанное на практике эксплуатации в среде Office 365.
Обратите внимание, что «достаточно производительности 2 x SAS 15k дисков» это не то же самое, что и «установите в сервер только два диска».
Обратите внимание, что «достаточно производительности 2 x SAS 15k дисков» это не то же самое, что и «установите в сервер только два диска».
Производительность MSA 1040 составляет 29 000 IOPS, а MSA 2040 – 82 000 IOPS при произвольном чтении, а пропускная способность – 3,1 и 6,2 Гбайт/с соответственно.
Когда будете заниматься сайзингом, учитывайте, что это суммарные цифры для двух контроллеров, а дисковой группой и томами на них владеет только один из контроллеров. Т.е. если вам известно, что с определённого LUN'а вам нужно будет 60-70 тыс. IOPS, то вы их не получите.
Второй момент: с MSA2040 (и его OEM-близнецом DotHill 4004) в вашем распоряжении только два пула, по одному на контроллер.
Бояться Thin Provisioning как такового не стоит, ведь в данном случае можно просто отключить overcommit на пуле, и СХД просто не даст выйти за пределы ёмкости пула при создании томов.
Sign up to leave a comment.
Внедрение MSA в виртуализированном окружении предприятия