Менеджер по снимку NETAPP для Exchange
Мы управляем сотнями доменных имен для клиентов и имеем несколько различных процессов.
Во-первых, мы возобновляем в течение нескольких лет, когда это возможно. Это уменьшает потребность возобновить год за годом, и мы можем обычно использовать в своих интересах многолетние скидки обновления. Для них мы затем помещаем запись в расписание системного администрирования для рассмотрения информации WHOIS каждый год и затем записи для возобновления снова за 90 дней до того, как это истечет.
Затем, мы используем автоматическое обновление с регистратором для некоторых имен, которые возобновляют каждый год. Это помогает гарантировать, что они возобновляются, даже если мы не получаем уведомление по любой причине.
И наконец, у нас есть установка адреса электронной почты конкретно для получения доменных уведомлений об обновлении. Это переходит к нескольким различным людям сюда в офисе. Я ответственен за получение их и обработку тех, которые должны быть обработаны. Если уведомление наталкивается на то, которое составляет меньше чем 30 дней, то несколько других людей в офисе знают для или прибытия, прослушивают меня об этом или согласовывают с клиентом и обрабатывают его, если я не доступен (отпуск или безотносительно).
Я описал статью блога некоторое время назад под названием Важность Доменов, которая обрисовывает в общих чертах некоторые общие советы для управления доменным именем. Это нацелено на клиенты, но любой, кто владеет доменным именем, может извлечь выгоду из него.
Я нашел эту информацию на форумах VMware:
Простой ответ - "да", можно выполнить Exchange с помощью vmdks сохраненный на устройстве хранения данных NFS, и обычно в малых и средних средах размера это - способ пойти. Если у Вас есть 2-4 тысячи тяжелых пользователей Exchange на сервере почтовых ящиков, Вы могли бы хотеть пересмотреть.
Более сложный ответ, это нужно рассмотреть тщательно в контексте нескольких вещей.
1. Есть ли любой SAN или приложение резервного копирования, для которых нужен собственный доступ к LUN (RDM или iSCSI). Things как Поспешный менеджер для Exchange должна использовать iSCSI или LUN FC, представленный непосредственно Exchange VM. Если это верно, Вы все еще выполнили бы свою операционную систему на VMDK, сохраненном на NFS, и затем представили бы iSCSI или LUN FC гостю для вещей как База данных или Трансжурналы.
2. Необходимо представить приложение с помощью perfmon и определить среднее число (но включать скачки) для пропускной способности и I/Os в секунду, и сравните это с пропускной способностью, что можно получить использование NFS, который будет зависеть от того, как Вы настраиваете свои сети.
-
1Эта информация корректна. Мы выполняем SnapManager для Exchange на сервере Exchange 2007, виртуализированном с VMware vSphere 4. Наше единственное требование состояло в том, чтобы использовать iSCSI LUN для данных и дисков журнала, потому что SnapDrive потребовал этого. Я верю более новым версиям SnapDrive, чем мы установили, может также использовать FC в VM, но мне haven' t попробованный или проверенный это. Don' t путают это с присоединением устройства хранения данных к VMware через FC. Мы имеем подключенную систему хранения FC, но должны были использовать iSCSI, потому что VM рассматривает наше устройство хранения данных как VMDK, и этому был нужен " raw" доступ к дискам, не VMDKs – Kevin Kuphal 29 August 2009 в 00:01
-
2Спасибо Kevin! We' ll использовать NFS для присоединения нашего хранилища данных VMware к FAS2050, и поскольку Вы упомянули это, походит на we' ll отображают iSCSI LUN в виртуальном Exchange Server для банка сообщений и журналов. I' ve, читая все, я могу достать, но я haven' t сталкиваются с ' Don' t путают это с присоединением устройства хранения данных к VMware через FC'. можете Вы объяснять или указывать на меня в правильном направлении на том, что это означает. Еще раз спасибо – Aaron 29 August 2009 в 15:40
Некоторые другие хорошие ответы здесь. Я просто отвечу от личного опыта, что для маленького обмена / AD SME развертывания является пустой тратой времени и деньгами. Замечательно, если у Вас есть большой обменный набор данных, но в течение нескольких 10-х гигабайтов я справлялся, это была просто добавленная сложность. Это вполне сложно и требует, чтобы работала целая груда очень определенного программного контроля.
Exchange в VM будет ОПРЕДЕЛЕННО работать, и если Вы предшествуете SME, можно использовать собственную обменную мультиосновную репликацию для начальной загрузки. NetApp, очевидно, хотел бы, чтобы Вы купили SME и скорее всего не захочет брать на себя ответственность за повреждение данных, если Вы не используете его, но простота установки VM, управления, и снимки, вероятно, восполнят его.
Это просто зависит от размера Вашего развертывания..., если бы Вы находитесь под контролем 50-100 пользователей, я не думаю, что рассмотрел бы SME.
Я работаю с NetApp, но я не непосредственно знаком с Snapmanager для Exchange так, надо надеяться, кто-то с прямым опытом w/SME и виртуализированный Exchange может предложить лучшее понимание. Аналогично, извинения, если это - просто общее рехеширование того, что Вы исследовали до сих пор. Я сделал беглый взгляд для некоторой документации, которая конкретно имеет дело с этим, и я ничто не нашел явным. Существуют ссылки на физические и виртуальные ресурсы в Snapmanager для администраторского руководства Exchange, но я полагаю, что они связаны с ресурсами кластера Exchange и не виртуальными дисками или виртуальными машинами.
Продумывая его, он имеет смысл, что SME требует LUN, а не vmdks, если бы Вы принимаете во внимание то, что это было бы создание снимков. Усиление снимка массива против vmdk довольно хитро, так как рассматриваемый диск является на самом деле файлом, находящимся в хранилище данных, которое в свою очередь находится в некотором пуле основанного на массиве устройства хранения данных. Для получения надлежащего снимка файловой системы в vmdk файле создание снимков VMware требовалось бы. Для создания этого снимка VMware полезным на уровне массива должна была бы быть некоторая координация между VMware и массивом хранения данных так, чтобы 2-й снимок (основанный на устройстве хранения данных снимок) на самом деле получил vmdk файловую систему в состоянии, стоящем создания снимков (буферные сбросы, замороженная операция в секунду, и т.д. первым снимком VMware). Кроме того, так как снимки NetApp основаны на объеме, для получения снимка vmdk весь корпус объема, хранилище данных VMware, в котором находится vmdk, должно было бы быть массивом-snapshotted, и Вы не можете легко "выполнить развертку" и просто привязать ту часть объема, где жизни vmdk или щипают его после того, как снимок массива целого пожирателя ресурсов был взят.
Snapmanager для Виртуальной инфраструктуры делает некоторую координацию между снимками VMware и снимками массива NetApp для оптимизации всего этого, но я не знаю, что Snapmanager для Exchange имеет ту осведомленность.
Администраторское руководство SME: http://now.netapp.com/NOW/knowledge/docs/SnapManager/relsme50/pdfs/admin.pdf (ТЕПЕРЬ требуемый вход в систему)
-
1
Я работаю в среде, в которой мы используем SME с Exchange 2010. Я понимаю, что это отличается от вашей среды, однако я подумал, что этим стоит поделиться. В отличие от вашей среды, наши серверы Exchange являются физическими, хотя журнал и информация хранятся на отдельных физических логах, обслуживаемых NetApp через iSCSI, что согласуется с тем, что вам сказал консультант.
Я не могу говорить ни с чем, связанным с визуализацией, однако По моему опыту, неплохо иметь отдельные физические логические файлы для журнала и хранилища информации, особенно если вы планируете делать снимки. У нас есть среда обмена среднего размера, однако количество изменений, вносимых Exchange 2010 в том, в частности, ошеломляет. Объем памяти, необходимый для хранения снимков в течение 2 недель, впечатляет. Имейте в виду, что снимки фиксируют все изменения громкости (объем содержит lun). Это особенно заметно, если вы выполняете перемещение или обслуживание почтовых ящиков в Exchange.
Также стоит отметить, что Exchange постоянно пишет в NetApp, поэтому для повышения производительности желательно иметь журнал и хранилище информации в отдельных агрегатах (отдельных дисках). .
В любом случае, это может немного выходить за рамки вашего вопроса, но это может быть хорошей пищей для размышлений, если вы решите пойти по пути NetApp.
Jeg arbejder for NetApp Support og understøtter SnapManager-produkterne og kan bekræfte, at enhver aktuel frigivelse af SnapManager for Exchange (SME) ikke understøtter VMDK-diske af nogen art. SnapManager til SQL (SMSQL) understøtter det dog ikke SMV på nuværende tidspunkt.