Введение

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

Более того, мы будем обсуждать, как и почему нужно тестировать ваше хранилище. Эти процессы относятся к ранним этапам планирования Exchange 2010, потому что если вы не тестировали ваше хранилище до перемещения на него пользователей, то исправлять его гораздо болезненнее, чем что-то другое, исправляемое без нарушения работы пользователей.

Почему теме хранилища посвящена целая статья?

ROBERT’S RULES OF EXCHANGE – это серия статей, в которых мы создадим фиктивную компанию, опишем ее существующую инфраструктуру Exchange, и затем пройдем весь путь проектирования, установки и конфигурирования Exchange 2010. Полный список опубликованных в блоге команды разработки Exchange статей из этой серии можно увидеть здесь.

Немного истории о хранилище Exchange

Исторически во внедрениях Exchange хранилище составляло значительную часть стоимости внедрения как в капитальных затратах (стоимость хранилища), так и в эксплуатационных затратах (обслуживание хранилища). Во времена Exchange 2003 для того, чтобы получить некоторую «высокую доступность», вам нужно было то, что мы теперь называем single copy clusters – кластеры с единственной копией данных, и что обычно подразумевает инфраструктуру сетей хранения данных (Storage Area Network, SAN), которые являются дорогими и сложными.  В те времена мы могли  видеть компании, которые вынуждены были резко ограничивать размер почтовых ящиков из-за высокой стоимости дисков, и при этом они были вынуждены использовать RAID 10 или другие аналогичные решения для того, чтобы обеспечить требуемую производительность дисковой подсистемы. Покупатели приобретали столько пространства на дисках, сколько могли себе позволить, а потом устанавливали размер почтовых ящиков таким, чтобы не выходить за его рамки.

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

Что-то надо было менять, и Microsoft услышал своих покупателей четко и ясно. В Exchange 2007 мы уменьшили количество обращений к диску ((Input/Output Operations per Second, IOPS) более чем на 70% по сравнению с Exchange 2003. В Exchange 2010 мы уменьшили количество дисковых операций ввода-вывода еще более чем на 70% по сравнению с Exchange 2007. Это означает, что Exchange 2010 генерирует примерно 10% от операций ввода-вывода эквивалентно нагруженной системы Exchange 2003.

Это открывает нам совершенно новый набор возможностей для использования очень больших, очень медленных, очень дешевых дисков, таких как 2-терабайтных дисков SATA 7200 об/мин или дисков SAS.

Суть в простоте

Одна из самых важных вещей, про которые надо помнить при планировании архитектуры Exchange 2010 (или любого другого решения, если уж на то пошло) – сохраняйте простоту. Каждый раз, когда вы усложняете свое решение, вы увеличиваете шанс провала при внедрении, вы вносите риск увеличения капитальных затрат или стоимости внедрения, и вы скорее всего увеличиваете эксплуатационные расходы решения. Чем сильнее вы усложние свое решение, тем выше вероятность сбоя или увеличения расходов. Таким образом, каждое проектное решения, которое мы принимаем, мы будем упрощать насколько это возможно. В рамках этой статьи мы рассматриваем сложность системы хранения.

Когда вы проектируете инфраструктуру SAN, цель заключается в том, чтобы обеспечить высокую доступность корпоративного хранилища. Необходимость в высокой доступности ведет к усложнению. Обычно, в случае SAN-хранилища, ваши серверы подключаются через несколько адаптеров Fibre Channel к нескольким (для надежности) коммутаторам Fibre Channel, которые, в свою очередь, через дублированные каналы подключаются к контроллерам ввода-вывода систем хранения.  Контроллеры, в свою очередь, через дублированные каналы подключаются к дисковым «полкам», которые содержат много-много дисков. Такая инфраструктура хранения включает в себя множество элементов: компьютеры, контроллеры, прошивки, программное обеспечение, и все это требует управления. Так что если вы внедряете SAN и имеете требования к высокой доступности (24×7), то вам придется держать штат специалистов, которые не обучены ничему другому, кроме как управлению инфраструктурой хранения, плюс в большинстве случаев вам не обойтись без услуг консультантов производителя SAN-системы на ближайшие 3-5 лет, пока вы будете использовать эту систему хранения. Системы SAN имеют очень интересные встроенные технологии репликации и резервного копирования, но каждая такая возможность, которую вы хотите добавить, увеличивает стоимость и сложность.

Если вы вместо этого используете JBOD, то есть прямое подключение SCSI-дисков к серверам, поддерживаете дублирование в виде копий ваших данных (скажем, 2 копии в локальном центре обработки данных и две в удаленном – вполне популярный сценарий), то картина сильно отличается. Вам не нужно дублировать сетевые подключения и каналы Fibre Channel. Вам не нужны RAID-контроллеры (нет, конечно, они нужны, например, для дисков ОС, но не для дисков Exchange). Вам не нужны дублированные коммутаторы сетей клиентского доступа и сетей хранения данных. Вы можете очень сильно упростить решение, используя для каждого сервера единственное сетевое подключение для клиентского доступа, одно или два подключения для репликации, единственное подключение к массиву дисков без RAID. При этом в случае аварии Exchange сможет переключаться на резервные базы данных или серверы. Если двух копий в центре обработки данных вам недостаточно, держите три копии. Или даже четыре. В общем, столько, сколько требуется в вашей ситуации.

Важно отметить, что мы должны избегать сложности всякий раз, когда это возможно. Когда идет обсуждение дисковых массивов с моими клиентами, я всегда начинаю с JBOD. Не каждый клиент собирается внедрять JBOD, но мы должны это обсудить. Мы должны понимать последствия внедрения более сложного, чем JBOD, решения. Я твердо настаиваю на том, чтобы не уходить от простейшего решения до тех пор, пока нет объективных причин для этого. И я люблю говорить, что «у нас так не принято делать» не является объективной причиной.

RAID или JBOD, DAS или SAN

Большинству людей не нравится идея отказаться от RAID для хранения важных почтовых сообщений. Однако вы должны знать, что в вашей частной жизни вы, скорее всего, храните ваши драгоценные данные, письма или что-то другое на JBOD. Google использует JBOD в их Google File System – да-да, ваша почта Gmail хранится без RAID. Большинство «облачных» сервисов Microsoft Office 365 использует JBOD в качестве хранилища (старые системы Exchange 2007 используют инфраструктуру хранения RAID, но инфраструктура Exchange 2010 в Office 365 развернута с использованием JBOD). Собственная почтовая система Microsoft на базе Exchange 2010 для более чем 180 тысяч пользователей использует JBOD. Кроме того, Microsoft TerraServer использует JBOD для хранения всей информации этого веб-сайта, так что не только почтовые системы движутся в направлении этого технологического решения.

Другая вещь, которая отпугивает клиентов – это идея о том, что диски SATA/SAS выходят из строя чаще, чем диски FC/SCSI класса предприятия, и что отказ одного диска в RAID не приводит к отказу всего сервиса, так что RAID выглядит более предпочтительным решением. Таким образом, если у меня диски класса предприятия в RAID-массиве, то они отказывают не так часто, а когда это происходит, то отрицательное воздействие на пользователя минимально. Чтобы ответить на это, давайте посмотрим на два этих утверждения отдельно. Во-первых, действительно ли обычные диски отказывают чаще, чем диски FC/SCSI класса предприятия? Согласно многим исследованиям (“Understanding disk failure rates: What does an MTTF of 1,000,000 hours mean to you?”, “Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?”, “Failure Trends in Large Disk Drive Population” и “Empirical Measurements of Disk Failure Rates and Error Rates” ) обычные диски отказывают не чаще, чем диски уровня предприятия, и, кроме того, все диски выходят из строя чаще, чем их заявленное среднее время наработки на отказ.

Отметим, что в инфраструктуре Microsoft’s Live@EDU мы используем обычные диски SATA 7200 об/мин, и при этом наблюдаем 5% отказов в год, в то же время в самой корпорации Microsoft мы используем обычные SAS-диски 7200 об/мин, и наблюдаем 2,75% отказов в год. Поэтому Microsoft рекомендует, если вы рассматриваете возможность использования обычных дисков в JBOD, выбирать вместо SATA диски SAS 7200 об/мин.

Что же относительно отрицательного воздействия отказов RAID-систем по сравнению с системами без RAID ? Действительно ли отказы дисков в RAID оказывают меньшее отрицательное воздействие на пользователей, чем отказы дисков в JBOD? В случае RAID мы должны учитывать фактор перестроения массива. RAID-решения имеют диск «горячего» резерва, который система подключает автоматически вместо отказавшего диска. Во время последующего за этим перестроения массива происходит снижение производительности ввода-вывода, которое ощущается операционной системой, а еще более Exchange. Это происходит потому, что чтение с оставшихся целыми дисков в  RAID должно производиться так, чтобы не прерывать восстановление данных на резервный диск, в результате мы имеем необычно медленные операции чтения даже с целых дисков и необычно медленные операции записи на новый диск. Чтобы правильно построить систему хранения для Exchange, вы должны учитывать процесс перестроения RAID в часы наибольшей нагрузки, что увеличивает стоимость системы хранения: вам нужно больше дисков, чтобы обеспечить нужную производительность (IOPS) в часы перестроения RAID. Чтобы увидеть отрицательные последствия этого на число дисков, посмотрите RAID Rebuild numbers в Калькуляторе требований к роли сервера почтовых ящиков Exchange 2010. Постройте RAID-решение с помощью этого калькулятора, прейдите на закладку “Storage Design” и измените RAID rebuild overhead percentages, чтобы увидеть, как это реально повлияет на количество дисков. Заметим, что вы должны консультироваться с  производителем системы хранения, чтобы получить правильное значение  RAID rebuild overhead percentages.

В случае с Exchange 2010 мы переместили большую часть решения по защите информации с RAID (где дублирование основывалось на дублировании дисков, а не данных) на архитектуру высокой доступности Exchange 2010 (где само приложение заботится обо всех экземплярах данных). Как детально описано в статье TechNet «Новые возможности высокой доступности и устойчивости сайтов», Exchange 2010 позволяет поддерживать несколько копий ваших почтовых баз (до 16-ти, что, как правило, слишком много, обычно мы видим от 2 до 6 копий, где 2 и 6 – это крайние варианты) и даже позволяет «починить» конкретную копию, если в ней обнаруживается поврежденная страница, с помощью нашей технологии восстановления отдельной страницы. Худшим вариантом является повреждение единственной копии вашей базы до такой степени, что ее больше нельзя использовать, и если это была «живая» копия базы, то приходится переключаться на другой сервер. Обычно это приводит к отключению менее чем на 30 секунд, но так как пользователи подключены к серверу клиентского доступа, а не к серверу почтовых ящиков, то они могут даже и не заметить отключения!

Вы все же можете возразить, что «RAID автоматически включит резервный диск в массив и запустит его перестроение, а JBOD не может это сделать». Это так. Каким-то образом вы должны включить резервный диск, отформатировать его на уровне ОС и заново поместить на него базу, которая была потеряна. Система хранения в некоторых случаях сможет автоматически подключить резервный диск и предоставить его соответствующему серверу. И совсем несложно написать скрипт для монтирования и форматирования LUN и переноса на него базы Exchange (с пассивной копии, так что, как вы понимаете, это не будет оказывать воздействия на пользователей). Это позволит вам нанять вместо консультантов стоимостью 200 долларов в час молодых специалистов, которые будут ходить по серверной комнате, отыскивать красные мерцающие огоньки и заменять диски.

Что же мне выбрать?

Я общался с клиентами, которые утверждали, что система хранения составляет половину стоимости от расходов на внедрение Exchange в пересчете на один почтовый ящик. Microsoft проделала большую работу, чтобы позволить вам выбирать такие системы хранения, которые чрезвычайно сильно уменьшают расходы на них. В этой статье я не могу сказать вам, какую архитектуру хранения выбрать. Microsoft поддерживает SAN и DAS+RAID, так же как и  DAS+JBOD, потому что не существует единственно правильного решения на все случаи.

Что я могу сказать с уверенностью, так это то, что если вы не находитесь в ситуации, когда «куры денег не клюют», то вам следует серьезно оценить доступные решения для хранения данных. Если вы просто развертываете Exchange 2010 на некоторой системе хранения, потому что вы так делали с Exchange 2003, или вы выбрали архитектуру хранения согласно политике вашего предприятия, которая требует от вас использовать корпоративную систему хранения, то вы совершите для себя и для вашей компании неверный поступок.

Большие дешевые диски означают, что организация, которая активно движется к архитектуре хранения DAS+JBOD (без RAID), может снизить удельную стоимость почтового ящика.  Когда почтовые провайдеры «облаков», такие как Google и Microsoft, предлагают почтовый ящик  за 5 долларов в месяц, организации, которые хотят держать свою собственную почтовую систему, тоже должны искать пути снижения своих расходов до этих же рамок. Являетесь ли вы компанией, которая имеет акционеров, перед которыми вы отвечаете, или государственным учреждением, которое отвечает перед налогоплательщиками, снижение расходов при одновременном выборе лучшего решения для ваших пользователей  должно быть исключительно важным.

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

Размер или производительность

Сайзинг хранилища для Exchange всегда был предметом компромисса между размером и производительностью. Такое средство, как Exchange Profile Analyzer, позволяет проанализировать почтовые профили пользователей: сколько сообщений в день отправлено и получено, какого размера эти сообщения, сколько сообщений в почтовых ящиках и т.д.  С помощью этой информации мы можем очень точно оценить требования к производительности (операций ввода-вывода в секунду) вашей дисковой подсистемы. Затем вы должны определить, какой размер почтовых ящиков вам нужен. Мы объединили все это вместе в Калькуляторе требований к роли сервера почтовых ящиков Exchange 2010, который говорит, сколько дисков вам необходимо, чтобы обеспечить эти требования, и какой тип системы хранения, RAID или JBOD, вам нужен. Затем мы можем найти баланс между размером и производительностью хранилища, изменяя исходные данные в таблице Excel (размер диска, размер почтового ящика, количество пользователей и т.п.).

Мы можем также рассмотреть варианты «что-если» и сравнить небольшие быстрые диски (с RAID) с большими медленными дисками (без RAID). Чтобы сделать это, внесите небольшие изменения  в калькулятор, скачанный с веб-сайта. Значения по умолчанию в калькуляторе: 6-ти узловая группа доступности с 3-мя копиями, которые находятся в одном центре обработки данных. По умолчанию для почтовой конфигурации задано: 24000 почтовых ящиков, 100 сообщений размером по 75 Кбайт, размер почтового ящика 2 Гбайт и период хранения удаленных писем 14 дней. Поизменяйте параметры дисков, не трогая другие параметры.

Сначала обратите внимание на маленькие быстрые диски в RAID-массиве.  Выключим «consider JBOD». Выберите все диски как FC размером 600 Гбайт и скоростью 15K об/мин. Такое решение потребует 666 дисков. Если мы увеличим количество операций ввода-вывода в секунду (IOPS) для каждого пользователя вдвое, то это не изменит требуемого количества дисков. Если мы вернем IOPS в исходное значение и уменьшим  размер почтового ящика вдвое до 1 Гбайт, то необходимое количество дисков будет 378. (При уменьшении до 256 Мбайт потребуется 246 дисков).

Теперь давайте рассмотрим тот же самый сценарий, но возьмем диски по 2 Тбайт и скоростью 7200 об/мин в JBOD. Включим «consider JBOD» и выберем такие диски. В результате получим 168 дисков для 2-гигабайтных почтовых ящиков (что на 68 дисков меньше, чем для 256-мегабайтных почтовых ящиков в примере выше). Такая конфигурация выглядит хорошо сбалансированной между производительностью (IOPS) и эффективностью использования дискового пространства. Если уменьшить размер почтового ящика вдвое, то количество дисков не изменится, это означает, что в этой конфигурации заложен достаточно большой запас по вводу-выводу . Увеличение размера почтового ящика до 2,5 Гбайт увеличит количество дисков только до 186.

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

168 дисков (7,2K 2 Тбайт SATA) * (стоимость диска)  = (общая стоимость всех дисков)

по сравнению с

666 дисков (15K 600 Гбайт FC) * (стоимость диска)  = (общая стоимость всех дисков)

Большинство клиентов, с которыми я работал, были поражены разницей в затратах.  Проблемы с PST-файлами (недоступны в OWA, Windows Phone 7, iPhone или BlackBerry , не поддерживается их размещение на сетевой папке, недоступны для сквозного поиска, не могут быть легко заархивированы с компьютеров пользователей, и т.п.), пользователи, которые требуют увеличения почтовых ящиков, дороговизна сторонних решений для архивации, которые уменьшают потребность в маленьких быстрых дисках – существует очень  много причин, по которым использование больших, медленных и недорогих дисков является очень привлекательным.

Архивный почтовый ящик

В Exchange 2010 появилась новая возможность – архивный почтовый ящик. Это, если говорить просто, второй почтовый ящик пользователя. Архивные почтовые ящики доступны только «онлайн-пользователям», то есть тем, у кого Outlook 2007/Outlook 2010 или OWA 2010 и кто в данный момент подключен к сети, но не доступны всем предыдущим версиям Outlook (поддержка Outlook 2007 требует установки обновления Outlook 2007 December 2010 Cumulative Update или более позднего), «оффлайн-пользователям» Outlook любой версии независимо от режима кэширования, а также клиентам IMAP, Exchange ActiveSync, Blackberry и большинству клиентов Exchange Web Services (EWS имеет поддержку архивных почтовых ящиков, но клиенты пока нет). Другими словами, в январе 2011 с архивными почтовыми ящиками работают только клиенты OWA 2010, Outlook 2007 и Outlook 2010, которые подключены к сети, где опубликован Exchange – Интернет в случае Outlook Anywhere и корпоративная сеть в случае подключений RPC/MAPI. Это означает, что существуют некоторые ограничения. Но возможности, несмотря на это, очень интересные и привлекательные.

Например, ваши пользователи имеют чрезвычайно большие почтовые ящики, скажем 20-40 Гбайт, и им необходимо совершать поездки с ноутбуками. OST-файлы, которые поддерживают подобные размеры, плохо работают на обычных дисках с 5400 или 7200 об/мин (но очень хорошо работают на последних моделях дисков SSD). Вы, вероятно, сможете разбить их почтовые ящики, дав 2-5 Гбайт на основной почтовый ящик, который синхронизируется с клиентом в режиме кэширования, и дав 20-35 Гбайт на архивный почтовый ящик, который доступен только при подключении к сети,  для старых, редко используемых писем.

Вот другой очень привлекательный сценарий. Предположим, что вы подключены к Microsoft Office 365, на котором размещены архивные почтовые ящики размером 35 Гбайт. Т.е. ваш основной почтовый ящик расположен на локальном Exchange, а архивный почтовый ящик на Microsoft Office 365. Что касается меня, то полагаю, что это очень интересный сценарий для целого ряда пользователей!

Имейте в виду, что почти каждая функция, которая ассоциируется с архивным почтовым ящиком, также доступна для основного почтового ящика. Политики хранения (политики, которые удаляют сообщения на основе их возраста), а также такие функции, как удержание или восстановление отдельного элемента, которые некоторые покупатели ассоциируют с архивным почтовым ящиком, доступны вам даже при отсутствии архивного почтового ящика.  Только очень немногие из возможностей являются специфическими для архивного почтового ящика, и они не связаны с фактическим разделением данных, поэтому можно переместить архивные почтовые ящики на другие физические серверы, в другие группы доступности и даже в «облако» на Microsoft Office 365.

Что касается цикла статей  Robert’s Rules, использование подобных архивных почтовых ящиков не представляет интереса для большинства наших пользователей. Наша идея простоты развертывания диктует, чтобы бы мы не реализовывали возможность, если она не требуется. Мы реализуем несколько архивных почтовых ящиков, чтобы показать, как можно использовать политики для того, чтобы манипулировать информацией в разных почтовых ящиках, а также для того, чтобы показать, как пользователи могли бы использовать такие почтовые ящики, и я надеюсь показать, как организовать гибридное решение, разместив некоторые архивные почтовые ящики в «облаке» Office 365. Но все это будет только ради демонстрации и не будет частью внедрения Exchange 2010  в нашей фиктивной компании, которую мы рассматриваем в рамках цикла статей Robert’s Rules.

Хранилище Exchange или сторонние системы архивации

Вот еще один вопрос, который я обсуждал со своими клиентами, и где Exchange имел фантастический успех. Как я упомянул выше, во времена Exchange 2003 покупатели, чтобы контролировать размер почтовых ящиков, внедряли сторонние решения, которые использовали в том или ином виде технологию «заглушек». В зависимости от размера сообщения и/или его возраста полезная часть сообщения удалялась из базы Exchange и сохранялась в другой системе, при этом в Exchange оставался только «указатель» или «заглушка». «Заглушка» использовалась для извлечения полезной части сообщения, когда пользователь хотел открыть это сообщение.

Заказчики Microsoft рассказывали нам о некоторых ограничениях подобных систем. Я слышал много раз, что пользователям не нравятся системы на основе «заглушек». Эти системы затрудняют доступ к данным, и в разных ситуациях, например, в Outlook и в OWA, способ доступа различается. Довольно часто в таких системах пользователи не имеют доступа к их данным с мобильных устройств, или возможности такого доступа значительно ограничены.

Еще одна особенность таких систем заключается в том, что они вносят дополнительную сложность и связанное с этим увеличение стоимости. Упрощение и удешевление почтовой системы чрезвычайно соблазнительно. В Exchange 2010 Microsoft проделала огромную работу для того, чтобы сделать возможной работу с большими почтовыми ящиками. Почтовые ящики размером в 5, 10 и даже 25 Гбайт становятся все более распространенными среди наших клиентов. Используя простое хранилище JBOD и большие медленные дешевые диски (например, диски 2 Тбайт 7200 RPM),  мы можем получить большие почтовые ящики дешевле и с большей доступностью, чем мы могли добиться с любой предыдущей версией Exchange.

Таким образом, вопрос стоит так: если вы можете реализовать ваше хранилище на более дешевой инфраструктуре, и вы можете предоставить вашим пользователям возможность хранить все нужное в их почтовых ящиках в течение 5 или 10 лет, то захотите ли вы связываться с решением на основе «заглушек», которое  увеличивает сложность, добавляя свое программное обеспечение и свое хранилище?

Пожалуйста, учтите, что мы не говорим о соблюдении требований закона. Мы не говорим о ситуации, когда мы должны хранить любое отправленное сообщение в течение 7 или 10 лет: для этого нужны специальные сложные системы поддержки расследований или подобные им. Такой системой может быть система журналирования, так как Exchange включает в себя технологии взаимодействия с такими системами. Это могло бы быть предметом отдельного обсуждения (как-нибудь в другой раз).

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

Тестирование с помощью Jetstress

После того, как вы приняли решение относительно вашего хранилища, спроектировали дисковую подсистему, приобрели и запустили оборудование, вам нужно протестировать ваше хранилище.  Прелесть в том, что мы имеем отличный инструмент – JetStress, который использует движок базы Exchange ESE, чтобы манипулировать базой на дисках точно так же, как это будет делать Exchange в производственной среде.

Замечательно, что совсем недавно мой хороший друг Нил Джонсон опубликовал руководство Jetstress Field Guide в блоге Exchange Team. Этот фантастический документ позволит вам точно понять, что вы должны делать, чтобы протестировать вашу подсистему хранения, и почему вы должны это делать. Разумеется, я использовал этот документ, чтобы освежить свои знания о JetStress перед обновлением моего статуса Exchange 2010 MCM (Microsoft Certified Master).  Я не могу не рекомендовать эту документацию тем, кому необходимо запускать JetStress. Нет ничего такого, что я мог бы добавить здесь, и чего нет в этом документе. Так что скачайте его, если вы еще этого не сделали.

Заключение

Хранилище и его производительность важны для Exchange 2010 точно так же, как для любой другой версии Exchange. Вот почему мы начали планирование Exchange с роли почтовых ящиков – самого хранилища, вычислительной мощности и памяти, необходимых для того, чтобы обеспечить доступ к этому хранилищу. Все идет от серверов почтовых ящиков.

Также, когда вы думаете об инфраструктуре хранения, помните, что надо начинать с простого. Проектируйте как можно проще. Усложняйте только тогда, когда это неизбежно, и только тогда, когда это идет от требований системы обмена сообщениями. Не пытайтесь проектировать Exchange 2010 так, как вы это делали с Exchange 2003. Попытайтесь использовать новые возможности Exchange 2010 для того, чтобы поддерживать функциональность, необходимую вашим пользователям для лучшего выполнения их работы.

Благодарности

Спасибо Эндрю Эрензингу, Россу Смиту IV и Мэтту Госсиджу за некоторые ссылки  и информацию о хранилищах. И как всегда спасибо Россу (еще раз) и Бхарату Сунедже за рецензирование и помощь в публикации. Бывает, я не всегда повторяю это, но всегда благодарен за вашу помощь!

Роберт Джиллис

Перевод: Илья Сазонов, MVP

источник: тут