athacker

Ну так и отдайте гипервизорам прямо по iSCSI этот LUN. Они, как правило, сами разбираются. ESXi, Hyper-V, KVM сами понимают, что если iSCSI storage, то они на этом луне не одни, и работают соответственно.

Либо, если вам нужно ещё и сами файлы виртуалок зачем-то глазками просматривать -- раздайте датастор по NFS.

Slimb, Варю можно перенести целиком на другое железо (вместе с гипервизором, имеется в виду). Hyper-V -- это винда, при переносе на другое железо, отличное от того, на котором конкретная копия устанавливалась, рискуете не загрузиться ;-) Варя же скорее всего запустится и на другом железе. Поколдовать с сетями придётся, но на крайняк можно начисто ESXi переставить и зарегистрировать на ней виртуалки с дисков -- это дело 15 минут, винда потребует больше времени.

У Вари есть один существенный плюс -- она может стартовать с флэшки, и не занимать места на дисках. Hyper-V, думаю, тоже можно утоптать, но придётся повозиться, да и делать так не рекомендуется. Плюс винда есть винда -- там постоянно какая-то активность дисковая присутствует, поэтому флэшку он будет потихоньку убивать. Варя при запуске с флэшки практически ничего туда потом не пишет, разве что крэш-дампы.

С другой стороны, бесплатный Hyper-V сервер умеет немножко поболе, чем бесплатный ESXi (в кластеризацию, например, умеет, а Варя без vCenter -- нет). Но при одном сервере это неактуально.

Про десктопные SSD вам уже выше сказали -- при более или менее постоянной и высокой нагрузке они быстро упадут в скорости до обычных шпиндельных SATA-шных винтов. Чем выше нагрузка -- тем быстрее. При хорошей нагрузке их может хватать буквально на несколько минут, а потом IOPS'ы падают 100-150 на один диск. Оставьте тесты производительности на несколько часов и посмотрите, что они будут показывать под конец тестирования -- будете неприятно удивлены.

Бэкапьте машины любой утилитой во временную папку, которую уже и настройте на синхронизацию с дропбоксом.

Либо, если совсем места нет, используйте какой-нибудь сервис, типа DropDAV. Он реализует WebDAV интерфейс к дропбоксу. Винда умеет подключать WebDAV-хранилища как локальный диск. Подключите WebDAV как сетевой диск, и настройте резервное копирование на этот диск.

1) Сервера могут быть какого угодно вендора, но вот модели и поколения процессоров у них должны совпадать. В вашем случае же этого не наблюдается. У VMware есть технология EVC, которая позволяет уравнять наборы команд процессоров разного поколения по самому старому из них. Насколько я помню, у Hyper-V такого ничего нет. Поэтому если у вас в кластере будут процы разного поколения и моделей -- как бы не огрести проблем, так что покурите этот вопрос.

2) Если уж гулять на полную высокую доступность, то коммутаторов должно быть минимум два, а какие конкретно -- это от нагрузок зависит. Может, хватит 1G, а может и InfiniBand потребуется какой-нибудь :-) Два коммутатора, в каждый из которых подключено по одному интерфейсу от каждого сервера и каждого NAS-а. Чтобы при выходе из строя любого из компонентов -- сетевушки, патчкорда, порта на коммутаторе, коммутатора целиком, связь не прерывалась. Но для этого потребуется, разумеется, iSCSI multipath и/или бондинг интерфейсов.

3) В вашем случае лучше сразу подключать оба хранилища к хостам. А бэкапы хранить где-то ещё. Для уменьшения времени простоя на восстановление виртуалок из бэкапов можно воспользоваться механизмом репликации с одного хранилища на другое. Например, Veeam это умеет. Акронис, я полагаю, тоже, да и встроенные средства какие-то в винде есть на этот счёт, нужно только поразбираться. Тогда время даунтайма будет минимально, и потери данных незначительны.

В свойства виртуального свича задаётся сетевой адаптер, через который этот свич будет работать. Соответственно, вам надо создать два таких свича, и в свойствах виртуалок выбирать один из них.

А при чём тут Hyper-V вообще?

Присоединяюсь к оратору выше. Виртуалка для игр -- идея не фонтан. Хотя, с прямым пробросом видео-карты -- ну, можно играть во что-нибудь не очень мощное.

Также не очень понятно, зачем нужны тонкие клиенты. Сейчас тонкие клиенты таковы, что рутинные задачи они могут решать вполне самостоятельно, так что делать из него просто терминал к виртуалке... Ну, в общем, профит, на мой взгляд, не очевиден. К тому же, всё равно потребуется монитор-клава-мышь, т.е. полноценное рабочее место. Подключать этот IdeaStick к телевизору хорошо для просмотра фотографий или видео, но для работы -- это ад и угар, телевизоры пока по чёткости изображения порядком отстают от мониторов. Разве что 4к какой-нибудь телек, но он всяко дороже монитора будет :-)

В качестве площадки для экспериментов я бы поставил какой-нибудь ящичек типа HP Microserver или просто в корпусе типа thermaltake core v1 собрал на Mini-ITX систему под виртуализацию.

У вас же VLAN based. Широковещательный домен -- он в пределах VLAN. Не сажайте в один VLAN много серверов, и будет вам щастье :-) А в одной они там стойке, или на разных концах города -- это без разницы (ну, если задержки при передаче не критичны). Всё зависит от задач. Где-то география на первом месте как критерий группировки, а где-то -- смысловая/функциональная группировка. Т.е. сервера могут разным заниматься, и разное виртуализовать. Логично, что их стоит объединять в кластеры, исходя из функций, возложенных на эти сервера. И сажать управление этими серверами в разные VLAN'ы.

1) Hyper-V Server (который бесплатный) не даёт никаких дополнительных лицензий. Лицензии будут только в случае приобретения Windows Server Standard, на котором вы поднимете роль Hyper-V. Вот внутри этого Hyper-V уже можно будет развернуть две виртуалки с виндой.

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

3) Поддерживаю предыдущего оратора насчёт мониторинга производительности NAS. Полагаю, там будет упираться в IOPSы, предоставляемые дисками. Для сравнения можно попробовать в нерабочее время натравить на эти диски какой-нибудь дисковые бенчмарк, чтобы получить эталонное значение IOPS, и потом сравнить с тем значением, которое получается при работе 1С. Если цифры близки -- делаем вывод, что упираемся в диски.

Ну очевидно, проблемы с сетевой связностью. Проверьте настройки MTU на всех гипервизорах и портах коммутаторов, к которым они подключены. Запустите пинги с большими размерами пакетов, и посмотрите, будут ли они столь же чётко ходить, как и обычные.

Вы бы текст ошибки приложили, что ли?

Учебные центры-то есть, но стоимость этого обучения...

Поэтому обучаться лучше дома. На youtube каком-нибудь порядком всяких видео. Пару мануалов почитайте, и начинайте осваивать прямо на домашнем компе. Если будут вопросы -- задавайте прямо здесь. Начните с одиночного гипервизора -- поставьте на один комп, разверните одну виртуальную машину, посмотрите, как это делается, какие настройки у неё могут быть, какое виртуальное железо оно увидит, настройте выход в сеть для неё. Ну и по мере ознакомления будут возникать конкретные вопросы, на которые уже будет гораздо проще гуглом искать ответы :-)

На Win10 только один вариант -- поставить какую-нибудь хрень, которая умеет делать NAT и порт-маппинг. Типа Kerio Winroute, или как оно там называется сейчас. И настроить на нём маппинг соответствующих портов между белым IP на физическом интерфейсе и серым IP в виртуальной сети.

Хотя я не очень понимаю, что вам мешает на каком-нибудь авито купить домашний роутер за 300 рублей, и настроить порт-маппинг на нём. Винду с белым IP-шником вам сломают из интернета в первые же часы, инфа 146%.

Есть, например, скрипты на powershell для бэкапа виртуалок: https://hypervbackup.codeplex.com/

Есть вот такая штука, например: www.powershellserver.com

Возможно, ваша Клонзилла сделала полную посекторную копию диска. Конечно, ей будет нужно 2 Тб. Пересмотрите режим, в котором делаете клон диска -- полная посекторная копия не нужна, нужны только реально занятые блоки на диске.

Теоретически, чем больше спанов (зеркал) у вас в RAID10, тем лучше производительность -- дисковый обмен размазывается на бОльшее количество дисков и получается выше отдача по IOPS. Чем обусловлены рекомендации для V3700 -- лучше почерпнуть в документации на хранилку. Возможно, это связано с особенностями функционирования самой хранилки, и для неё реально 8-дисковый массив (4 зеркала в RAID0) будет работать быстрее, чем 6 зеркал в RAID0.

Но есть ещё соображения удобства обслуживания. Если придётся реконфигурировать массив, то лучше иметь два дисковых LUNa -- вывез все машины на один, а второй ломай, как хочешь. Но в целом, для подобных целей лучше иметь две хранилки :-)

Use backups, Luke! Иначе такие ситуации будут повторяться не раз, и не два.

Что касается битого винта -- поищите какой-нибудь софт и попробуйте сделать полный посекторный образ диска, смонтируйте этот образ и попробуйте выдернуть из него уже файлы. На линуксе или фре можно с помощью dd попробовать этот образ снять.