АртемЪ,
"А проф, энтерпрайзы и ультимэйт - все работает."
https://docs.microsoft.com/ru-ru/windows-server/ne...
"В следующих операционных системах BranchCache не поддерживает функции HTTP и SMB, но поддерживает функции BranchCache BITS. - Windows 10 профессиональная, только поддержка BITS - Windows 8.1 Pro, поддержка BITS - Windows 8 Профессиональная, только поддержка BITS"
Насколько я понимаю это без SMB.
На счет AD, я это делал только на стенде и достаточно давно( server 2008 ), он был нужен для определения ближайшего сервера через сайты, возможно сейчас это работает как-то иначе.
В без серверной версии, опять таки это было давно, оно работало примерно как торрент, но все равно нужен был минимум один сервер( но не нужен был сервер в филиале ), при это в "кэш" попадали, только файлы востребованные другими пользователями того же филиала, если файлы в этом филиале больше никому не нужны или часто меняются, эффекта не будет.
Не очень понимаю как он будет определять где брать кэш без домена и поймет "границы" медленных каналов, если вы поясните как это работает на актуальной версии windows, я буду вам благодарен.
АртемЪ, насколько я помню для branchcache требует enterprise версии windows и есть ограничения на сервер. Плюс по идее вам нужен контроллер домена в филиале, иначе как он ближайшее хранилище выбирать будет.
Геннадий Уваров, rms это right management services, это не AD.
Microsoft Windows Server CAL 2019 - это и есть требуемая лицензия, я бы сказал на основные службы. Она бывает на user или на device.
RDS это удаленный рабочий стол, для нужд администрирования сервера данная лицензия не требуется, только для работы пользователей, ну или если у вас множество административных аккаунтов которые будет проводить работы на сервере одновременно.
Вы путаете отслеживание соединений на сетевом уровне и на уровне приложений, делая допущение, что они совпадают. Для написания подобного сценария нужно анализировать состояния коннекшен трекера и анализировать пакеты, и не факт, что все не развалится при использовании другого клиента или после обновления прошивки.
Akina, то что вы описываете называется закрытие "уязвимости" орг.мерами. Тоже решение, но не решение поставленной автором задачи, фильтрация по макам это не безопасность.
Bohdan Zadorozhniy, изучите packet flow diagram.
У вас правила на цепочке input, это цепочка с тарифом для самого mikrotik, транзитный трафик это цепочка forward.
Тут этапы.
Сначало каждый раз руками на квалификации сотрудника.
Потом чек листы
Дальше более менее детальная документация
Дальше версионность документации
Дальше к этому всему добавляем базовые образы которые требуют минимально возможного конфигурирования.
Дальше версионность образов.
Дальше скрипты на повторяющиеся действия.
Дальше максимальная сприптизация и выявление скриптуемых кейсов
Дальше управление конфигурациями, типа ansible.
Конечная цель infrastructure as a code.
Можно ещё докеризацию добавить если есть проблемы с зависимостями и команда большая.
Обычно в итоге приходят к тому, что облака с их готовой обвязкой дешевле чем всю эту компетенцию держать внутри команды. Потому как токая компетенция это дорого.
Думаю у вас будет достаточно базовые образы, скрипты и чеклисты в git.
ettaluni,
Настройка требует корректировки при разворачивании на конкретной точки, можно ли эту корректировку "заскриптовать" или она требует принятия решений от человека?
Как часто делается развертывания?
Руслан Федосеев, с этим я как бы не спорю, но сделать вероятно можно.
Тогда по уму нужно вообще все в облако вынести, поскольку схема с двумя серверами не отказоустойчива.
Руслан Федосеев, с ssl можно попробовать "белый mitm", но не уверен, что микротик такое умеет. Плюс там есть tls host, но я не пробовал им пользоваться.
Рональд Макдональд, эти занимается очень не большое кол-во программистов.
Взять то же DB. Это же не только работа с индексами и спецификой хранения данных, но и еще и целый набор обвязок, конфигурационных систем, IDE и средства администрирования.
Полагаю объем кода со сложной математикой очень не большой, по отношению к общему объёму кода.
При это мат. подготовка на ИТ специальностях, во всяком случае когда я учился, была достаточно сильная, это конечно не МехМат, но большинству и это никогда не потребуется.
AntHTML,
"1С и практически любая БД критична к пингам, а если пинги большие, то и транзакции будут подвисать отнимая время работы сервера и забивая канал доступа."
Но этого не должно происходить при использовании сервера 1С Предприятия, поскольку транзакцию держит не конечный клиент, а сервер 1С Предприятия, а он находиться близко к базе. Если в 1С это не так, и сервер 1С Предприятия не отпускает транзакцию к базе до завершения соединения с клиентом, то это просто эпик фэйл архитектуры 1С.
"А RDP прекрасно параллелится,"
Какое это имеет значение? Если сама 1С не параллелится, то параллельность RDP не будет иметь значения( да и параллельность RDP вызывает большие вопросы, вроде бы да, но это стоит в ресурсах ОЧЕНЬ дорого в расчете на одну сессию ).
"сейчас подобие режима терминального сервера реализовано в связке 1С сервер - 1С тонкий клиент, из-за чего, при нормально написанной конфе, разница в скорости работы снижается"
Каким образов 1С сервер - 1С тонкий клиент является аналогом терминального сервера? Так знаете и VK какой-нибудь можно аналогом терминального сервера считать, да и вообще любое приложение которое обращается к api, а не напрямую к данным.
ИМХО 1С Сервера - 1С тонкий клиент с точки зрения производительности, за исключением отдельных случаев, когда пинг очень большой, а разработчик на отображение одного окна написал 100 запросов и не распараллелил их( а за такое нужно сразу много не хорошего делать ), разницы быть не должно.
А учитывая стоимость лицензирования RDP, может быть проще пользователю с большим пингом отдельный сервер поставить и синхронизировать их.