omnimod

Под ваши требования подходит Symantec Backup Exec или Simpana CommVault, или HP DataProtector, или IBM TSM, или Symantec NetBackup, однако я бы порекомендовал Veeam Backup & Replication, он хоть и не умеет бекапить отдельные приложения и файлы внутри ВМ, но является одним из лучших решений по резервному копированию ВМ на VMware vSphere.

Среди плюсов Veeam Backup & Replication:
-Консистентный бекап файлов и данных приложений внутри ВМ, без необходимости установки агентов.
-Встроенная дедупликация и архивирование бекапов.
-Возможность гранулярного восстановление отдельных файлов и данных приложений (SQL, Exchange, AD).
-Возможность запуска ВМ прямо из бекапа с последующей миграцией ВМ с помощью vMotion или Storage Migration.
-Возможность автоматической проверки резервных копий по расписанию.
-Возможность создавать консистентные реплики ВМ по расписанию.

Недостатки:
-Напрямую не может бекапить на ленты, однако у одного из наших заказчиков бекапы Veeam на ленты забируются с помощью Backup Exec.
-Бекапит только виртуальные машины (VMware vSphere или Microsoft Hyper-V). Для бекапа физической инфраструктуры потребуется использовать что-то другое.

P.S. обратите внимание, что далеко не все СРК поддерживают ESXi Free, будучи у вас таковой.

Используем в Production у себя и разворачиваем у Заказчиков, как vSphere 4.1, так и vSphere 5.0. В инсталляциях более одного сервера, базы, как правило, размещаются на виртуальных дисках, хранящихся на СХД. Проблем не наблюдали. Рекомендую перед развертыванием ознакомиться с best practices от вендоров (VMware, Microsoft).

Самая большая проблема в развертывании — это лицензирование SQL в виртуальной среде, зачастую, стоимость лицензий может превышать плюсы от виртуализации.

Большинство из тех сервисов, о которых вы написали, можно кластеризовать на уровне самих сервисов, например несколько контроллеров домена, DNS, DHCP, файловых серверов (DFS), Exchange серверов (DAG), SQL (например, Database Mirroring). В большинстве случаев это обеспечит больший уровень доступности сервисов (поскольку защитит не только от отказа железа), хотя и может потребовать большее количество лицензий на ПО (Exchange, SQL), а также позволит устранить единую точку отказа в виде общего хранилища; эффективнее утилизировать ресурсы серверов (нежели просто резервировать их под Failover Cluster); использовать DAS (sas/scsi хранилище или внутренние диски сервера) в качестве хранилища виртуальных машин и данных приложений, вместо общего хранилища.

exchange с разнесением ролей

Вы уверены, что это необходимо делать? Конечно, зависит от нагрузки и количества пользователей, но если <300 человек — не стоит слишком заморачиваться, кроме, пожалуй, установки выделенного front-end'а (например Exchange Edge или другой mail relay) для антиспам или антивирусной проверки входящих сообщений.

По сути, получается, что требуется реализация двух независимых кластеров: (a) файлового сервера

NAS (CIFS или NFS) официально не поддерживается в качестве хранилища вирутальных машин Hyper-V, тем более с DFS. Если вы планируете как-то иначе кластеризовать файловое хранилище (например с тем же Failover Cluster) вам все-равно понадобится общее блочное хранилище данных (DAS, SAN). Смысл тогда огород городить?

(а с учетом политики лицензирования Enterprise-версии windows — еще, вроде, и возможность нести 16 виртуальных машин — поправьте, если неправ)

Не совсем, при использовании Enterprise лицензий вы сможете запустить до 4-х экземпляров ОС на том же сервере, к которому данная лицензия привязана, если у вас будет всего 2 Hyper-V сервера, то значит, что вы сможете поднять 4-ре ВМ на одном и 4-ре на другом.

Вопрос: как правильно организовать отказоустойчивые NAS?

Что касается правильного NAS — как уже писал выше — не поддерживается. Если хочется отказоустойчивое хранилище (сравнительно дешевое), посмотрите в сторону Starwind или самосборном Linux + ietd + drbd + heartbeat (но, естественно, такое решение поддерживаться не будет).

Достаточно ли для нормального функционирования двух указанных выше кластеров существующего сетевого оборудования?

50/50 либо хватит, либо не хватит.