В свое время мы заметили, что требования Exchange 2003 к хранилищам данных очень завышены. Программный продукт просто купался в дорогостоящей памяти и полностью занимал ресурсы сложных в обслуживании сетей хранения данных (SAN). Все было хорошо, пока крупные компании оплачивали счета, но необходимо было уменьшить требования к размерам хранилищ данных. Путь к этой цели занял приблизительно 12 лет и завершился большим успехом: Exchange получил возможность работать с недорогими хранилищами данных. Точнее, с теми самыми типами дисков, которые широко используются в Office 365.
История программного обеспечения богата примерами грандиозных стратегических изменений, последствия реализации которых оказались ничтожными. Попытка уменьшить число операций дискового ввода-вывода, формируемых в секунду для одного пользователя (IOPS), — пример того, как разработчики пошли на крупный риск и выиграли.
Во времена Exchange 2003, чтобы развернуть программный продукт, обслуживающий больше нескольких сотен почтовых ящиков, приходилось покупать дорогостоящее оборудование для сетей хранения данных SAN. Технология SAN приобрела нежелательную репутацию сложного и подверженного сбоям решения. Такое мнение сохраняется и сегодня, но, если правильно развернуть, настроить и управлять SAN, можно получить значительный выигрыш в производительности для ряда приложений.
К сожалению, стоимость сетей SAN высока. Логика хранения данных, быстродействующие соединения, дорогостоящие диски высокой надежности и прочности и все сопутствующие технологии превращают SAN в продукт, который дорого обслуживать и эксплуатировать. Словом, необходимость в хранилище данных качества SAN создает лишнюю зависимость для Exchange.
Целенаправленные меры к снижению показателей IOPS, необходимых для информационного хранилища Information Store, были приняты вскоре после появления Exchange 2003. Как показано в приведенной таблице, эти усилия были вознаграждены снижением показателя IOPS для одного пользователя с 1,0 до приблизительно 0,05 на сегодня (еще ниже в Exchange 2016, если использовать дополнительные копии баз данных). Как и в случае с любыми данными производительности, необходимо помнить, что входные параметры оказывают огромное влияние на результаты. Данные в этом примере основываются на профиле IOPS для 100 сообщений в день.
.jpg) |
По официальным данным Microsoft, число операций ввода-вывода в секунду Exchange 2016 и Exchange 2013 примерно одинаковое. Я проверил нижний показатель перед публикацией и рад сообщить, что он достижим, а это указывает на безусловный прогресс в данной области. В целях планирования предпочтительно задействовать высокий показатель, который используется такими инструментами, как Exchange Server Role Sizing Calculator (https://gallery.technet.microsoft.com/office/Exchange-2013-Server-Role-f8 a61780) компании Microsoft.
Диски SATA и SAS могут применяться в Exchange 2013 или Exchange 2016. Компания Microsoft предпочитает SAS и опубликовала следующее заявление о желательной архитектуре: 7.2 K RPM serially attached SCSI (SAS) disks (while SATA disks are also available, the SAS equivalent provides better IO and a lower annualized failure rate) (http://blogs.technet.com/b/exchange/archive/2015/10/12/the-exchange-2016-preferred-architecture.aspx).
Изменение стало следствием перемен в программном обеспечении в слое базы данных ESE и Information Store в сочетании с фундаментальными изменениями архитектуры в сфере высокой доступности, ориентированными на группы обеспечения доступности баз данных (DAG). В сочетании со снижающимися затратами на хранение данных и растущей популярностью JBOD это привело к радикальному изменению акцентов при обсуждении темы хранения данных для Exchange.
После того как исчезла необходимость в хранилищах высокого уровня, удалось значительно сократить затраты на этапе развертывания. Благодаря резкому снижению стоимости появилась возможность предоставить такие службы, как Exchange Online, по ценам, которые были бы нереальны при использовании сетей SAN.
Усилия, затраченные на снижение показателей IOPS, оказались не напрасными. В результате компания Microsoft смогла заложить фундамент для перемещения огромного количества пользовательских данных в Office 365 за последние пять лет и обслуживания более 60 млн активных почтовых ящиков в рамках коммерческого «облачного» проекта, в настоящее время приносящего ежегодный доход 9,4 млрд долл.
В противном случае Microsoft никогда не удалось бы предоставлять 50 Гбайт пространства для хранения данных для каждого почтового ящика и назначать цены, которые сегодня действуют для планов Office 365. На самом деле 50 Гбайт — это только начало, так как имеются еще расширяемый архивный почтовый ящик, пространство для элементов с возможностью восстановления и т. д. В результате единственный пользователь Office 365 может легко заполнить привычный накопитель SAN корпоративного класса на 146 Гбайт.
Как Поль Каннингем, обладатель статуса MVP, указывает в статье, размещенной по адресу: http://blog.enowsoftware.com/solutions-engine/with-exchange-2016-are-sans-finally-dead, по-прежнему существуют весомые причины для использования SAN в качестве хранилища для Exchange, особенно если в компании применяется ориентированный на хранение данных, а не приложения, подход к распределению ресурсов. Выигрыш от решения, принятого разработчиками 12 лет назад, заключается в том, что теперь у потребителя есть выбор. SAN или JBOD — решать вам.