RStarun

В 12-13 лет может им не с технологий начать, а с примеров целей и задач? Оля с Леной переписываются насчет личности Петрова, а Сидоров при передаче их записок не просто их читает, но еще переписывает. А Зайнаб раздавала в долг фантики турбо и записывала в тетрадочку. Резервной копии не было, тетрадочку потеряла. Ну и конечно - как включить комп на биос которого предки поставили пароль.
И потом технические решения tcp там, разграничения прав, питоны.

Лучше исходить из поставленых задач.
Вот есть у вас задача - AD DC поднять. Она понятна и для нее есть рекомендации от вендора. Там вендор прописывает сколько CPU надо на каждую тысячу юзеров и т.п. В целом один DC заберет у вас 2 ядра и 2 гига, может чуть больше. 80 гб пзу, пусть SSD.
При это использование одного DC не рекомендуется, желательно иметь 2 шт. И по возможности на разных железках. Если нет второго hyper-v, то найдите любой ПК для этих целей.

Облачный файлообменник это что-то на linux скорее всего будет. Тот же nextcloud. Ну то есть у МС есть sharepoint, но его поднять и сопровождать это отдельную команду нужно. (может windows storage server что-то может, но их мало в продакшн) Требования есть. Грубо 2 гига, 2 ядра. Емкость - неизвестно сколько вы планируете хранить информации. Ну пусть 2 тб. медленных hdd

Еще можно просто общие папки, они прекрасно доступны в локалке, а удаленно к ним получать доступ через VPN. Решает примерно те же задачи, но уже не "облачное" решение.

Почту проще держать у внешнего сервис провайдера. Лучше не тащить ее в дом. Если хочется почту на MS, то это exchange. Дорого, богато. Требования как и у всех, зависят от нагрузки. Без 2х процессорного сервера с 256 гигами лучше не подходить. На старых версиях работало с 64 гб и 8 цпу, емкость по 100-300 гб на юзера. HDD + OS на SSD 200 гб.

Веб сайт можно впихнуть куда угодно. Но зависит от .... сюрприз - нагрузки! Требования к веб сайтам тоже есть у всех cms, движков и тп. В среднем 2 гига, 2 ядра, 100 гб ssd :) для визитки достаточно. Только, как и с почтой, рекомендация - разместить у хостера и не знать горя.

Под контролем доступа непонятно что имеется в виду. Есть системы для служб безопасности, они отслеживают кто в какой файл полез, какие изменения внес и много чего еще. Это отдельные железяки и много. Стоимость софта затмевает стоимость железок. Если просто прокси + дать доступ к вконтакту или заблокировать, то usergate умеет. Ну или Squid на Linux. Usergate 4 цпу, 10 гб, 300 гб SSD.

Kaspersky Security Center тоже может, но менее гибко и нужно много времени на обучение. Но вам все равно антивирус ставить, так что под него закладываем еще 4 цпу, 8 гб, 300 гб SSD.

У MS ранее был продукт ISA - для контроля доступа к интернет ресурсам. Это ооочень давно было. С тех пор нет вроде ничего такого.

Linux машины прекрасно на WS Hyper-v поднимаются и работают если что.

А еще это все ведь бэкапить нужно время от времени. И под это нужно емкость посчитать раза в 3 превышающую данные самих сервисов. Ну и подумать как, чем и куда бэкапить.

Старайтесь не использовать снэпшоты в работе на постоянной основе. Снэпшоты нужны для тестирования изменений, для снятия резервных копий. После окончания таких работ снэпшоты лучше удалять, иначе вм может занять слабо прогнозируемое количество места на диске. Это к любой системе виртуализации относится, не только к VB.

включить hyper-v, поднять любую требуемую ОС (если удобна Win server, значит ее) и поднять все необходимое там. И бэкап снять проще и администрировать и перенести если что можно на любую железку.

По ограничениям были статьи по win7, может помогут.

Все зависит от многих факторов.
1. Модель контроллера и версия прошивки. На некоторых нельзя произвести подобную операцию, на некоторых можно.
2. Должен быть только один virtual drive на этом raid. Если их несколько, то операцию провернуть не выйдет.
Вот один из примеров ограничений.
Перед любыми операциями необходимо сделать резервные копии всех данных которые возможно.

Технически ничего сложного. Заменяем один диск, делаем ребилд. Заменяем второй диск, делаем ребилд. Делаем расширение VD. Сообщаем ФС что нужно расширить том.

1. Сервер DC всегда должен быть единственным dns сервером для клиентских ПК.
2. Сервер DC (DNS) должен быть настроен на пересылку запросов которые ему неизвестны вышестоящему серверу DNS (провайдера или гугла или яндекса, или дяди Феди). Это делается из оснастки DNS, закладка "сервер персылки" в свойствах DNS сервера.
3. В настройках сетевых адаптеров сервера в качестве DNS должны быть указаны адреса самого сервера (127.0.0.1)
4. DHCP клиентам лучше чтобы раздавал так же сервер. Для этого роутер настраиваем как релей DHCP, а на сервере заводим новый сегмент.
Для проверки работы DNS используйте утилиту nslookup.

На сервере должна стоять служба hasp lm и файрволы должны пропускать на нее трафик по требуемым ей портам из нужных подсетей. 475 UDP
Для диагностики можно применять aladdin монитор, он показывает ключ и клиентов. Но только если хотя бы один клиент забрал себе лицензию с ключа.
Поскольку сервер и клиенты находятся теперь в разных подсетях, то на клиентах должен быть напрямую прописан адрес сервера с ключом.
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.0.х

Проверить доступность ключа можно так же telnet'ом по порту 475.

1. Администрировать один сервер терминалов проще чем десятки компов в удаленных офисах. Если нужно обновить платформу, то делается это на сервере за 15 минут. А на всех клиентах 15*n если не настроено или не сработало автообновление от 1с.
2. Лицензии раздавать возможно проще. Ключи воткнуты в основном офисе все, для удаленных не требуется возить туда ключи и распределение их будет более грамотным. Хотя ключами может и сервер 1с управлять, тут нужно смотреть.
3. Про трафик уже сказали, но в принципе тонкий клиент может и немного потреблять, с учетом заданий на печать даже значительно меньше.
4. Если вдруг нужно запустить какую-то базу файловую, то на rdp это легко.

Насколько я понимаю удаленные офисы подключаются к терминальному серверу и запускают 1с там.

Это возможно, но нужно понять архитектуру вашего решения.
Если это стандартный вариант - сервер 1с + сервер бд, то:
- сервер бд кластеризуется штатными средствами (MS SQL умеет в кластер, но только enterprise, в стандарте он умеет log shipping и failover, что для вас является решением)
- сервера 1с вроде тоже умеют в кластер, но это уже к 1с никам, точно не помню как оно работает. И даже если не умеет, то поскольку данные у нас в бд, то можем тупо поднимать сервер 1с и направлять запросы на второй сервер бд.

Если это что-то типа файловой, то... Например DFS для хранения БД.

Может CyberDuck ?

Litemanager https://www.litemanager.ru/

Должно заработать. Мат плата поддерживает до 128 (вероятно есть ограничения у проца).
На сайте просто указано что протестировали работу системы с 2 такими планками и они работали. Это все.
Некоторые планки протестировали по 4 шт, некоторые по 2 шт.
Установив 4 вы рискуете, т.к. их работу не тестировал вендор. Но вероятность что что-то пойдет не так - низкая.

Если софт более или менее новый, то у него будет не GUI, а веб интерфейс на localhost:2463
При этом должна работать служба LSAService, порт не должен закрываться файрволом.
Если софт постарше, то тоже какая-то служба должна быть запущена, не помню (maxviewWebServer). И тоже веб - https://localhost:8443
Есть еще с GUI, там тоже служба должна порт слушать.
Ну и никто не мешает переустановить полностью этот софт с удалением настроек.
А еще на серваке, скорее всего можно поуправлять контроллером через BMC, иногда оно умеет.

веб сервисы
Там дальше еще указать права из раздела directory и api. Указываются теперь поиском, а не выбором из списка.
Но я думаю вы уже эти вопросы решили давно, на дворе апрель. Просто вдруг кто искать будет.

Если в спектр хобби и рабочих обязанностей не входит поднятие серверов, мониторинг, работы с рейдами и бэкапами, то наверное лучше использовать коробочные решения. QSAN, QNAS, QNAP - любые штуки с Q.
Продавцы сами подберут под требования железяку, ибо такое обычно в магазине на полках не валяется.
Скорее всего подойдет то что позиционируется производителем под видеонаблюдение, исходя из того что кроме объема требований не озвучено.
И диски продаваны тоже подберут. Лучше сразу в пару контор обратиться (больше не стоит, много волокиты). Тринити, например, слышал что адекватны. И по текущим условиям гарантий что-то скажут.

Да, диски объемом больше 6 тб я бы не советовал. Ну то есть при любом уровне рейда перестроение может идти очень долго на дисках большого объема. Получается уже хранилка на 24 бэя. Хотя опять же - тз нет.

Ни разу не маркетолог, но почему нельзя присутствовать во всех соц сетях? Есть же всякие сервисы для постинга везде, чтобы меньше времени на это уходило. Ну и нужно понимать где заказчики находятся. Если есть в РФ, то придется VK тоже подключать. Тут Youtube к концу года могут и заблочить.
Хотя Instagram FB заблочены, но все кто хочет пользуются... В любом случае не понимаю зачем себя ограничивать какой-то одной сетью.

Идея так себе. Спрашивать мнение в интернетах. Ответственность за потраченные деньги Вася Пупкин с Хабра будет нести? Regard хоть как-то потом сможет ответить, ну хоть промычать.
Отвечая на ваш вопрос - взлететь вроде должно.

• Кулер не всегда в базе платформы идет, нужно читать
  
• Памяти не надо по 8 гиг брать, берите по 32 хотя бы.
  
• Диски по 8 тб в рейде будут перестраиваться так долго что успеет сдохнуть еще диск. Берите по 6 тб, но большее количество.
  
• 2 тб непонятно зачем, хотя в целом задачи не указаны
  
• про ssd люди пишут
  
• Intel РФ не любит, может лучше Supermicro? А то потом VPN для скачивания дров использовать.
  

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