athacker

Заходите на страничку vcloudproviders.vmware.com
Выбираете там в строке поиска страну, и смотрите на список сертифицированных провайдеров облачных услуг VMware. Если будете работать с отечественными -- работать с Cloud4y категорически НЕ рекомендую.

Если у вас устройства подключены по COM-портам, то чем вам поможет проброс PCI? У вас на хосте виртуализации должно быть соответствующее количество доступных COM-портов, которые можно аппаратно пробросить внутрь виртуалки. Один порт можно пробросить в одну виртуалку. Соответственно, если у вас есть 10 аппаратных COM-портов, вы их можете пробросить в 10 виртуальных машин.

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

Есть, конечно, ещё вариант USB-to-COM, но тут вам точно не по пути с Hyper-V, потому что у Microsoft проброса USB внутрь виртуалок нет, и не будет. А в VMware это есть. Есть ещё всякие штути, типа USB Anywhere, но вот как будет работать связка "USB-COM-переходник ---> USB AnyWhere hub --> TCP/IP ---> виртуальная машина" -- это большой вопрос, и боюсь, ничего, кроме смелого практического эксперимента, на него тветить не сможет.

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

Поснифать протокол работы управляющего приложения пробовали? Вряд ли там бинарный самопальный протокол, скорее всего что-то на базе HTTP/REST сделано.

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

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

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

Вы прям VDI хотите, или просто пачку виртуальных рабочих станций? :-) VDI подразумевает под собой всякое, типа создание golden image, развёртывание виртуалок по запросу и так далее.

Если всё-таки VDI, то там вопрос не стоит "какой гипервизор", вопрос стоит "какое решение". И это решение будет диктовать и выбор гипервизора. VMware Horizon, Microsoft RDS, XenDesktop -- понимаете из названий производителей, какие гипервизоры каждое из них использует? :-) Есть ещё некий foss-cloud, тоже VDI решение, как я понял, на базе KVM.

Если же просто виртуализацию, то VMware жутко платная, например. Xen как-то сдал позиции. Остаются бесплатный Hyper-V и KVM. Ну и разная остальная экзотика типа VirtualBox. А, ну ещё Proxmox есть, тоже можно попробовать. Hyper-V сервер бесплатный, и даже можно кластеры собирать, тоже бесплатно. Общее хранилище -- шары SMB 3.0 или NFS, или блочное по iSCSI.

Про KVM и Proxmox ничего не скажу, но там тоже есть свои управлялки виртуальной инфрастуктурой. Общие хранилища -- NFS и iSCSI. На KVM можно замутить использование чего-нибудь типа ScaleIO и получить конвергентную систему -- это когда у вас виртуализация и хранилище реализуется на одних и тех же серверах. Но там надо число узлов не менее 3, а на мой взгляд, меньше 4-х и вообще лучше не начинать -- слишком большой оверхед на дисковое просранство. ScaleIO платный, но "для тестовых целей можно использовать без всяких ограничений". Т.е. можно качать, ставить и использовать, триального периода там нет, и ограничения по функционалу тоже.

Ну так в чём затруднения?

(RAM одной виртуалки * на кол-во машин) + 30% = кол-во RAM на гипервизорах
CPU одной виртуалки * на кол-во машин = кол-во CPU на гипервизорах

Это ж простая арифметика, какие тут ещё калькуляторы нужны?

А вы как ядро пересобирали? Конфиг покажите. Ну и /etc/make.conf тоже.

Модуль не надо засовывать, его нужно собрать и проинсталлить, если его действительно нет.

Делается это так (в случае с vmm.ko):

cd /usr/src/sys/modules/vmm
make && make install

Конечно же, перед сборкой модуля в /usr/src у вас должны быть установлены актуальные исходники системы.

Шлюз по умолчанию в VPN-соединение при таком сценарии вы засунуть не сможете. Точнее, сможете, но только если через этот белый IP на эту виртуалку ходят только с фиксированного набора IP-адресов в интернете. Тогда можно на эти IP-адреса прописать выделенно шлюз.

Обычно задача решается в виде наоборот -- для сетей, которые проходят через VPN задаются статические маршруты, а вот шлюз по умолчанию остаётся на месте без изменений.

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

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

Для ограничения ресурсов нет смысла городить огород с виртуализацией

На линуксе man ulimit, man 5 limits.conf

Там можно задать ограничения и для CPU, и для памяти на по-юзерной основе.

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

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

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

Вам 10 Гбит куда? Только на общение с СХД? Если да, то может, попробовать на fiber channel построить? Там старые карточки 4 гигабита умели. По одному адаптеру в хосты виртуализации, и один в СХД.

На авито такие адаптеры продаются занедорого, вот, например: https://www.avito.ru/moskva/tovary_dlya_kompyutera...

Hyper-V Server. Бесплатный, развернуть можно на железе.

Старые и/или дешёвые комплектующие вполне можно использовать. Главное -- обеспечить должную степень резервирования. Я бы порядком удивлён, когда смотрел документальный фильмец про крутой датацентр какой-то крупной западной компании. И увидел там знакомые крышечки дисковых отсеков на серверах, с характерной коричневой защёлкой. Т. е. даже в крутых конторах могут использоваться дешёвые супермикровские сервера :-)

Мораль -- вполне можно использовать и дешёвое железо, если ваша архитектура построена правильно, и имеет определённую степень избыточности. Условно говоря, если у вас кластер виртуализации под вашу нагрузку требует N серверов, то купите и поставьте в этот кластер N+3 сервера. Тогда даже если один из дешёвых серверов выпадет, у вас всё автоматически перебалансируется и вы в спокойном режиме можете заказать и купить новый дешёвый сервер.

1) Поддерживаю ораторов, которые говорят о разворачивании машин с нуля в виртуалке, без попыток конвертации P2V. При конвертации могут разные артефакты всплывать, ну нафиг. Грамотно спланированный перенос не потребует даже даунтайма сервисов.

2) СХД отдать только под виртуализацию, никаких бэкапов там. В вашем случае -- это примерно как из пушки по воробьям. Под бэкапы -- вытащить все винты из ваших пролиантов и сложить их на один какой-то сервак, и на его основе сделать бэкапохранилку. ESX может грузиться и по iSCSI, и с флэшки. У пролиантов есть отсек для SD-карточки, можете туда флэшку с ESX воткнуть. Иными словами -- для хостов виртуализации жёсткие диски не нужны.

3) Kerio -- фу-фу-фу! :-) Карточки вам не нужны, аппаратный роутер, в принципе, тоже. Каждого провайдера в отдельный VLAN, оба VLAN -- в виртуалку, на виртуальный сервер с FreeBSD, например. И всё, маршрутизируйте как угодно.

4) QNAP в качестве СХД -- фу-фу-фу! Уж лучше самосбор какой-нибудь (сервак с большой дисковой корзиной, или отдельно пара серверов+корзинка DAS), с FreeBSD и ZFS внутри, да даже с виндой. Оно и дешевле обойдётся, и обслуживать проще. У NAS-ов из дешёвого сегмента артефакты бывают очень разнообразные и зело причудливые. Отваливаются LUNы, слетают права, вообще из сети пропадает. Короче, нахлебались, было дело.

5) Подумайте в сторону винды. Учтите, что Windows 2012 R2 Standard в качестве хоста виртуализации (Hyper-V) даёт возможность внутри себя виртуализовать 2 виндовых сервера по этой же лицензии. Иными словами, если у вас 3 лицензионных Win2012 R2 стоят на хостах, то с их помощью вы можете виртуализовать 6 серверов с виндой, не покупая никаких доп. лицензий.

Hyper-V умеет запускать виртуалки прямо на файловых шарах SMB 3.0. То есть, не нужно iSCSI, FC и прочих модных технологий из области NAS/SAN. Достаточно Win2012 R2 и открытой файловой шарой на нём. Винда умеет технологию Storage Spaces. Которая (технология) умеет даже автоматически tiering, причём из коробки. QNAP, который это умеет, будет стоить тысяч под 300 рублей. Это без дисков.

Исходя из набора сервисов, который у вас есть в сети, вам, в принципе, СХД и не нужна. Не те скорости, не те объёмы. У вас же нет 10-гигабитных линков, правильно я понимаю? Посмотрите вместо СХД на какие-нибудь сервера с большими корзинками. Ну, допустим, от 8 до 24 дисков. 8 есть практически у всех, у Dell есть 10 и 20 дисков, у STSS есть сервера с корзиной на 24 диска (вот так оно выглядит). Либо на DAS (direct attached storage). Нужен сервер (практически любой), в сервер SAS-HBA адаптер с парой внешних портов, и корзинка DAS, которая SAS-кабелями подключается к этому адаптеру.

Примите во внимание также, что брендовые СХД (даже QNAP) -- это вещь в себе, и диагностику там провести достаточно сложно. Поэтому обычно покупается поддержка у вендора. А она стоит тоже порядком денег. А без поддержки самому лазить в потроха СХД -- чревато граблями вооооооот такого размера. Самосбор же проще диагностировать и проще чинить (менять компоненты), если вдруг что.