Максим Гришин

https://discourse.haproxy.org/t/shared-frontends-h...
я так понимаю, что перед фронтом, который занимается терминированием SSL, ставится ещё один фронтэнд в режиме tcp, который занимается роутингом по бэкам с использованием списков по совпадению TLS SNI. В нем ставишь ACL на тот сервер, который требует HTTPS, ACL под его SNI и бэк по условию, а остальной трафик проваливаешь на второй фронт самого себя (то есть трафик отправляется по loopback на соседний порт, где висит тот же самый haproxy, но трафик уже остается тот, где нужно терминировать SSL). На нем терминируешь SSL и раскидываешь трафик по бэкам.

То есть схема такая: Интернет -> TCP frontend -> ACL фильтр по SNI, если фильтр не пройден, то default backend localhost:port2, на нем уже HTTP frontend -> SSL termination -> backend по имени. Если фильтр пройден, то простой редирект на SSL backend:443.

Если твой трафик с ВМ НАТится, IP не утечет, разве что на ВМ появится некое ПО, передающее фактическую конфигурацию вовне. И от такого вам защищаться уже нужен NGFW (L7-фильтрация), сильно сомневаюсь, что вообще потребуется защита подобного уровня. Проще говоря, если в Интернет выходите через NAT, и не используете протоколов, которые в данных передают локальные IP-адреса (ЕМНИП SIP/RTP их передают, и для нормального проксирования SIP нужен модуль на прокси для подмены этих адресов), то ваш IP не утечет.

Смысл ставить ESXi на виртуалку иногда бывает - как пример, запускать appliance в виде VMware VM, когда в окрестностях нет ни одного доступного сервера с ESXi, но имеется гипервизор другой системы с достаточным доступом, чтобы можно было разрешить nested virtualization для ВМ с ESXi. Так же иногда есть смысл в учебных целях разворачивать гипервизоры на ВМ, скажем, учиться управлять distributed virtual switch'ом или просто кластером ESXi в окружении, которое не страшно потерять. В случае продакшн смысла обычно нет, вплоть до того, что если требуется запускать ВМ именно на вмвари, заложить в требования ESXi хост или кластер.

Если нужен просто виртуальный DC, поднимайте новый, перекидывайте роли и выводите старый - вуаля, контроллер домена на виртуалке. Главное потом заморочиться на синхронизацию времени, чтобы не было такого, что КД получает время от хоста, а хост от КД.

По-хорошему, ни к чему настраивать дополнительный уровень RAID на уровне хоста, достаточно в самом vSAN настроить корректно избыточность распределенного хранения данных с требующейся по техзаданию надежностью, и потом гонять перф-тесты с целью выяснить предел нагрузки, который сей vSAN потянет, так как он зависит от метода обеспечения надежности.

Боюсь, что никак.
https://docs.microsoft.com/en-us/previous-versions... упоминает PhysicalLocation как " free-form string indicating where the hardware is located" и тип доступа read-only, и если вдруг (а именно на это и похоже) Микрософт захотела сменить его формат, то мало что можно сделать в противовес.

Как-то так: https://docs.vmware.com/en/VMware-Workstation-Pro/...
Создать роль, которая не будет иметь прав на создание/удаление ВМ, но будет иметь права на запуск/остановку ВМ и работу в консоли, и присвоить её пользователю.

RTP-соединение НАТится в несовпадающие порты до и после ната. Вам нужен SIP/RTP-прокси, который умеет изменять на лету SIP-пакеты и открывать соответствующие согласованным порты NAT для проксируемого астериска. С первым вам просто повезло, что по умолчанию (поведение наблюдал на CentOS7) при попытке НАТить соединение, проверяется, можно ли не изменять порт, и если да, в него и НАТится. Как альтернативу, укажите другой диапазон RTP-портов на втором астериске, и выделите проброс портов на НАТе в неизменном виде до этой ВМ, то же с SIP-портом, может даже сработать.

1) Нельзя. VMware умеет один диск назначить только одной ВМ. Golden Image - это всего лишь шаблон ВМ с установленными обновлениями, ПО и последующей очисткой временных файлов, из которого клонируются ВМ для нормальной работы (VDI как вариант, там ВМ временная и удаляется после завершения работы с ней пользователя). Возможно, удастся сэкономить место на хранилище, если включить на нем дедупликацию для дисков с операционной системой, но это не гарантировано, плюс будут проблемы по производительности в случае обновления ВМ без дополнительного диска avhd (т.е. без снапшота) - в этом случае постоянно будут кластеры, которые будут выходить из дедуплицированного состояния, и место на хранилище начнет заполняться, на это в общем случае хранилище будет реагировать медленнее, чем в ситуации без дедупликации.
2) Thin provision диски будут расти как обычно, thick provision не потеряют в производительности, но они сразу занимают максимальный размер, ещё при создании.
3) Неприменимо. Если разговор о Golden Image, он обновляется как обычная отдельная ВМ с последующим экспортом обратно в шаблон.
4) Неприменимо - придется сравнивать диски от разных ВМ, а у них первичный образ диска будет не один. То есть будет доступна только конфигурация с 10 отдельными дисками.
5) Туда же.

Данные по VMware ESXi 6.0 и моему опыту работы с ним. Если 6.5 что-то изменил, буду рад узнать.