К программам, инициируемым известными поставщиками, мы относимся с определенной степенью доверия. Поиск настроек хранилища Exchange 2013 приводит нас на сайт microsoft.com, где опубликованы результаты тестирования по программе Exchange Reviewed Solution Program (ERSP). Здесь представлены всевозможные архитектуры хранилищ от разных производителей, но лишь немногие из них могут похвастаться чем-то большим, чем пройденный тест JetStress для определенного количества почтовых ящиков, что удручает.

Год назад в одной из статей я рассказывал о решениях от Hitachi и IBM, призванных удовлетворить потребности в хранилищах, обслуживающих 120 000 почтовых ящиков Exchange 2013. Вообще-то я не рассматриваю такие архитектуры всерьез, поскольку их группы обеспечения доступности базы данных (DAG) предусматривают создание лишь двух копий каждой базы данных. Это абсолютно неприемлемо при развертывании большой среды Exchange.

Поставщики хранилищ могут придумать любую схему, отвечающую, по их мнению, определенному требованию. В данном случае таким требованием является успешное прохождение теста Jetstress и теста по программе Microsoft Exchange Reviewed Solution Program (ERSP). Прохождение такого тестирования означает лишь то, что данное решение способно обеспечить платформу для обработки некоторых синтетических транзакций для определенного числа почтовых ящиков с набором баз данных Exchange за определенный период. Однако это не гарантирует, что такая архитектура, будучи развернутой, окажется жизнеспособной. Нет ни контроля качества, ни подтверждения работоспособности решения от экспертов с опытом управления большими рабочими средами. Тем не менее, поставщики стремятся проходить эти тесты, чтобы попасть на веб-страницы Microsoft. Согласно осторожной формулировке Microsoft, ESRP – это программа, содействующая тестированию сторонних хранилищ и публикации решений для Exchange Server. Однако содействие не означает официального одобрения, разрешения или поддержки. Такая обманчивая формулировка может привести клиентов к предположению о реальной работоспособности представленных решений.

В частности, 11 июня 2014 года, было опубликовано сообщение о решении от Nimble Storage (nimblestorage.com/products/overview.php). Признаюсь, я мало знаю об этой компании и ее уникальном коммерческом аргументе в пользу решения, основанного на «патентованной последовательной архитектуре с ускоренным кэшем (Cache Accelerated Sequential Layout – CASL)». За счет использования уникальных свойств флеш-памяти и диска обеспечивается высокая производительность при чрезвычайно малых потребляемых ресурсах, как указано в описании продукта. Из прочтения этого материала ясно, что необходимые данные хранятся на SSD («адаптивная флеш-память»), а не на традиционных жестких дисках (что, в принципе, хорошо).

Дополнительное исследование показывает, что присутствие Nimble Storage на рынке Exchange невелико. В немногочисленных опубликованных примерах описана реализация Exchange в небольшом банке (200 пользователей) и в компании, работающей в сфере здравоохранения. Возможно, именно относительно малое присутствие на данном рынке, по сравнению с HP, EMC, IBM, NetApp и т.д., является причиной, по которой компания Nimble Storage опубликовала сообщение о своем решении и о результатах его тестирования по программе ESRP.

Предлагаемая архитектура рассчитана на 100 000 почтовых ящиков. Однако мои сомнения прежде всего связаны в нерациональностью этой архитектуры в рабочих условиях. Четыре физических сервера Windows 2012 с Hyper-V поддерживают 20 почтовых серверов Exchange 2013, организованных в две группы обеспечения доступности баз данных (DAG). Сразу возникает вопрос: почему две группы DAG? Какую надежность обеспечат четыре сервера Hyper-V при обслуживании 100 000 почтовых ящиков? Почему только 100 баз данных (50 активных) и только по две копии для каждой базы данных? Получается две тысячи 1-гигабайтных почтовых ящиков на каждую базу данных при 2-терабайтном пределе (передовая практика) для базы данных почтовых ящиков. Конечно, пользователи с самого начала не выберут квоту для своих почтовых ящиков, и на практике эти базы данных будут гораздо меньше (по крайней мере, сначала).

Материалы компании этих вопросов не касаются. Гораздо больше внимания в них уделяется вопросам хранения, таким как число операций ввода-вывода в секунду (IOPS), производительность и задержки. Несомненно, эти вопросы имеют значение, что не умаляет важности такого аспекта, как жизнеспособность решения на уровне приложения.

Таким образом, есть много фактов, которые заставят опытного администратора Exchange не принимать всерьез эту архитектуру как решение для развертывания в рабочей среде. Можно утверждать, что одна группа DAG в составе 16-ти узлов способна справиться с нагрузкой в 100 000 почтовых ящиков, тем более что такая группа DAG может поддерживать до 1600 подключенных баз данных, то еть 400 активных баз данных, каждая из которых имеет по три пассивных копии. Но при этом едва ли будет достигнут предел возможностей DAG при поддержке 100 000 почтовых ящиков на 16 серверах (6250 почтовых ящиков на сервер). Анализ подобных вопросов требует знания реальных рабочих аспектов в сочетании с большим опытом работы с Exchange.

Было бы хорошо, если бы хоть одно из этих решений, прошедших тестирование по программе ESRP, действительно годилось для практического использования. Другими словами, возьмите продуманное решение (возможно, с участием серверов, выполняющих несколько ролей) и проверьте его в работе со сторонним хранилищем, чтобы оценить его работоспособность в реальных условиях.

Хорошим началом было бы использование в качестве основы для предлагаемой архитектуры результата, полученного с помощью калькулятора требований к ролям сервера Exchange 2013 (http://gallery.technet.microsoft.com/office/Exchange-2013-Server-Role-f8a61780), с необходимой корректировкой, для максимальной реализации всех преимуществ платформы. По крайней мере, тогда можно было бы утверждать, что представленная информация чего-то стоит. От текущих же данных по результатам тестирования по программе ESRP клиентам мало проку.