Я ищу отзывы от всех, кто использует файлер NETapp с Snap Manager for Exchange. Мы планируем установить один, и консультант сказал нам, что наш текущий виртуальный сервер, на котором запущен Exchange 2003, может оставаться виртуальным, но диски, содержащие файлы журналов и хранилище информации обмена, должны быть перемещены за пределы vmware, т.е. не могут храниться внутри файл vdmk.
Насколько я понимаю, журнал и информационное хранилище необходимо будет хранить на отдельных LUN в фильтре, и виртуальная машина будет монтировать эти LUN.
Мой вопрос: я просмотрел все лучшие практики NetApp и не нашел аналогичной установки. Я верю консультанту, но мне было бы интересно получить дополнительное подтверждение того, что это предпочтительная установка, или руководство по передовой практике.
Спасибо
я нашел этот информация на форумах vmware:
Простой ответ - «да», вы можете запускать Exchange, используя vmdks, хранящиеся в хранилище NFS, и обычно в средах малого и среднего размера это правильный путь. Если у вас 2-4 тысячи активных пользователей Exchange на сервере почтовых ящиков, возможно, вам стоит пересмотреть свое решение.
Более сложный ответ заключается в том, что это следует тщательно рассмотреть в контексте нескольких вещей.
1.Существует ли какое-либо приложение SAN или резервного копирования, которому требуется собственный доступ к LUN (RDM или iSCSI). Такие вещи, как Snap Manager for Exchange, должны использовать iSCSI или FC LUN, представленные непосредственно виртуальной машине Exchange. Если это так, вы все равно будете запускать свою операционную систему на VMDK, хранящемся в NFS, а затем предоставить гостю iSCSI или FC LUN для таких вещей, как база данных или транслоги.
2. Вы должны профилировать свое приложение с помощью perfmon и определить среднюю (но с учетом всплесков) пропускной способности и операций ввода-вывода в секунду и сравнить это с пропускной способностью, которую вы можете получить с помощью NFS, которая будет зависеть от того, как вы настроили свою сеть.
Здесь есть еще несколько хороших ответов. Я просто отвечу из личного опыта, что для небольшого развертывания обмена / AD SME - пустая трата времени и денег. Это здорово, если у вас есть большой набор данных обмена, но для нескольких десятков гигабайт, которыми я управлял, это просто добавило сложности. Это довольно сложно, и для работы требуется целая куча очень специфических версий программного обеспечения.
Обмен в виртуальной машине будет ОПРЕДЕЛЕННО работать, и если вы откажетесь от SME, вы можете использовать для загрузки собственную репликацию обмена с несколькими главными серверами. NetApp, очевидно, хотела бы, чтобы вы приобрели SME, и, скорее всего, не захочет брать на себя ответственность за повреждение данных, если вы ее не используете, но простота настройки, управления и создания снимков виртуальной машины, вероятно, компенсирует это.
Это просто зависит от размера вашего развертывания ... если у вас меньше 50-100 пользователей, я не думаю, что буду рассматривать SME.
Я работаю с Netapp, но я не знаком с Snapmanager for Exchange напрямую, поэтому, надеюсь, кто-нибудь, имеющий непосредственный опыт работы с SME и виртуализированным Exchange, сможет лучше понять. Точно так же приношу свои извинения, если это всего лишь повторение того, что вы исследовали до сих пор. Я быстро просмотрел документацию, специально посвященную этому вопросу, и не нашел ничего явного. В руководстве администратора Snapmanager для Exchange есть ссылки на физические и виртуальные ресурсы, но я считаю, что они относятся к ресурсам кластера Exchange, а не к виртуальным дискам или виртуальным машинам.
Если подумать, становится логичным, что SME требует LUN, а не vmdks, если принять во внимание то, что он будет делать снимками. Использование моментального снимка массива в сравнении с vmdk довольно сложно, поскольку рассматриваемый диск на самом деле является файлом, находящимся в хранилище данных, которое, в свою очередь, находится в некотором пуле хранилища на основе массива. Чтобы получить правильную картину файловой системы внутри файла vmdk, потребуется моментальный снимок VMware. Чтобы сделать этот моментальный снимок VMware полезным на уровне массива, необходима некоторая координация между VMware и массивом хранения, чтобы второй моментальный снимок (моментальный снимок на основе хранилища) фактически захватил файловую систему vmdk в состоянии, достойном моментального снимка (буферы очищаются , операции приостановлены и т. д. с помощью первого снимка состояния VMware). Кроме того, поскольку моментальные снимки Netapp основаны на томах, для получения моментального снимка vmdk весь том, в котором находится хранилище данных VMware, в котором находится vmdk, должен быть снят с массива, и вы не сможете легко выполнить "развертку" и просто сделать снимок ту часть тома, где находится vmdk, или вытащите его после того, как был сделан снимок всего массива.
Snapmanager for Virtual Infrastructure выполняет некоторую координацию между моментальными снимками VMware и моментальными снимками массива NetApp, чтобы упростить все это, но я не знаю, есть ли у Snapmanager for Exchange такое понимание.
Руководство администратора SME: http://now.netapp.com/NOW/knowledge/docs/SnapManager/relsme50/pdfs/admin.pdf (СЕЙЧАС требуется вход в систему)
Я работаю в среде, в которой мы используем SME с Exchange 2010. Я понимаю, что это отличается от вашей среды, однако я подумал, что этим стоит поделиться. В отличие от вашей среды, наши серверы Exchange являются физическими, хотя журнал и информация хранятся на отдельных физических логах, обслуживаемых NetApp через iSCSI, что соответствует тому, что вам сказал консультант.
Я не могу говорить ни о чем, связанном с визуализацией, однако мой опыт показывает, что было бы неплохо иметь отдельные физические логические файлы для журнала и хранилища информации, особенно если вы планируете делать снимки. У нас есть среда обмена среднего размера, однако количество изменений, вносимых Exchange 2010 в том, в частности, ошеломляет. Объем памяти, необходимый для хранения снимков в течение 2 недель, впечатляет. Имейте в виду, что снимки фиксируют все изменения громкости (объем содержит lun). Это особенно заметно, если вы выполняете перемещение или обслуживание почтовых ящиков в Exchange.
Также стоит отметить, что Exchange постоянно записывает данные в NetApp, поэтому по соображениям производительности хорошо иметь журнал и хранилище информации в отдельных агрегатах (на отдельных дисках).
В любом случае, это может быть немного за пределами вашего вопроса, но это может быть хорошей пищей для размышлений, если вы решите пойти по пути NetApp.
Я работаю в службе поддержки NetApp, поддерживаю продукты SnapManager и могу подтвердить, что любой текущий выпуск SnapManager for Exchange (SME) не поддерживает диски VMDK любого типа. SnapManager for SQL (SMSQL) поддерживает его, но в настоящее время не поддерживает SME.