athacker

man на предмет командлета Get-EventLog, Люк. Вот, например, статейка, как работать с виндовыми логами из powershell: windowsitpro.com/powershell/access-security-event-...

Ну и аудит событий безопасности должен быть предварительно включен, разумеется.

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

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

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

Вероятнее всего, оно лезет куда-то в интернеты для проверки чего-нибудь. Когда шлюз в системе не указан -- оно обламывается быстро, так как система знает, что маршрутов до удалённых сетей нет. Когда же шлюз просто отключен -- то оно ждёт в течение некоего таймаута обращения, и по его истечении обламывается. Вероятно, таймаут в софте меньше таймаута TCP/IP, и софт просто не в состоянии эту ситуацию корректно обработать.

Запустите снифалку трафика, и посмотрите, ломится ли клиент куда-нибудь в интернеты при запуске этого защищённого ПО.

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

Всё это ОБЯЗАТЕЛЬНО нужно поднимать на виртуалках. Но проц можно попроще, а памяти -- побольше. Я бы начал с 64 Гб. 2 таких хоста в кластере + общее хранилище (NAS, DAS, СХД -- без разницы) позволят вам виртуализовать не только это, но и пачку других серверов. Единственное -- согласно best practices, один контроллер домена всё же лучше сделать железным. Для 35 юзеров под контроллер хватит любого самого простого сервака, можно даже БУ. Можно даже HP Microserver поставить, при желании, он потянет.

SATA-диски -- вполне ОК для этой нагрузки, если из них собирать RAID10 в несколько пар. Но надо понимать, что "внутренний" вариант в случае организации кластера не подойдёт -- никакой отказоустойчивости не получится, нужно общее хранилище, которое будет одновременно доступно всем хостам кластера виртуализации, независимо от состояния других хостов кластера.

at-hacker.in/?go=all/samba-zfs-acl -- настройка самбы и как сделать виндовые права на расшаренной через самбу папке с ZFS.

Чего только не придумают люди, лишь бы документацию не читать...

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

Если у вас PPPoE именно средствами Kerio поднимается, то вот в методичке: kb.kerio.com/product/kerio-control/interfaces/conf...

указано, что в настройках PPPoE есть некая вкладка Dialing Settings, на которой можно якобы выбрать исходящий интерфейс.

Либо сконфигурьте этот винт как JBOD, либо, если контроллер не умеет JBOD, то создать RAID0, состоящий из одного диска.

Если встаёт вопрос ограниченности бюджета, то лучше самосбор. FreeBSD+ZFS, плюс SSD-диск под L2ARC-кэш. Хотя это зависит от типа нагрузки, если будет в основном запись данных и мало чтения, то можно обойтись и без L2ARC.

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

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

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

В AD есть поле в свойствах учётки, которое позволяет указать, на каких хостах пользователю разрешено логиниться.

tcpdump что показывает?

Очень любят почему-то спрашивать про роли FSMO :-) Их состав, назначение и что будет, если какая-то из них сломается.

Почтовый сервер поднять не так уж сложно, как тут ряд ораторов утверждает. В целом же -- если вас не парит, что конторскую почту может читать "потенциальный противник", то можно пользоваться публичными сервисами -- гуглом, яндексом, чем угодно. Лично я предпочитаю, чтобы почта ходила через свой сервер.

1) Пробросить порт достаточно.

2) Домен нужно регистрировать в любом случае, свой у вас DNS-сервер или не свой. Как-то же снаружи к вам почта должна приходить? А для этого нужно, чтобы доменное имя и MX-записи были публично доступны.

3) Обратную зону прописывать обязательно, иначе будут постоянные проблемы с тем, что от вас почта не будет приниматься адресатами в других доменах. SPF -- тоже должна быть обязательно. Обратную зону нужно просить прописать вашего провайдера, а SPF нужно прописывать на том публично доступном DNS-сервере, куда вы делегируете своё доменное имя.
4) MX и A должны быть прописаны там же, где и SPF :-) Вы регистрируете домен и делегируете его на какой-то DNS-сервер. Можете поднять свой, можно воспользоваться DNS-серверами регистратора (как правило, регистраторы доменных имён предоставляют такую возможность, и некоторые даже бесплатно, если регистрируете домен у них).

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

man xbmc