У меня раньше была идея в создании failover кластера просто с виртуальным именем и IP-адресом, которые бы ездили между узлами, и добавлением службы Print Spooler как ресурс Generic Service в кластере. Но как раз был вопрос в синхронизации принтеров между двумя узлами. Ручной вариант (создать принтер и тут, и там) не устроил, поэтому этот тему приостановили.
А вот теперь с PrintBrm есть интересный вариант. Тем более, что можно также создать кластерное задание планировщика задач, которое выполняется на узле владельце роли (который будет определять направление репликации).
Таким образом будет и автоматический failover (упала служба/сервер) и автоматическая синхронизация принтеров.
Если бы потом ещё с очередью разобраться, было бы вообще хорошо :)
Может ещё глянуть продукт STOR2RRD, мониторинг достаточно большого количества разных СХД, бесплатная версия почти полносьтю полнофункциональна. Хоть там все и очень просто сделано
Если на сервер именно для AutoCAD и терминалов, зачем там вообще виртуализация? Выкинуть гипервизор, оставить чистую Windows Server 2016 Standard, на ней сделать терминальный сервер. Сокращение затрат, увеличение производительности
Так как настроен FastTrack, то никакой нагрузки от этого, в общем-то, нет. И даже относительно старенький RB750GL (1x400 MHz CPU) нормально пережёвывает гигабитный трафик
Я делал немного по другому, чем в комментарии выше.
У меня OpenVPN на удаленном хосте. Также есть address-list со списком нужных адресов, через mangle маркируются пакеты, которые должны уходить через VPN, и в /ip route настроена отправка этих пакетов с такой маркировкой pastebin.com/GSSSr7qB
Т.о. весь трафик до заблокированных адресов идет через VPN, остальное через обычный инет.
А я с удовольствием в декабре '17 прошел Готику 1 8)
(*правда с каким-то модом на графику с нормальными FHD разрешениями, но всё остальное примерно тоже самое*)
Думаю, много факторов.
Планшет на Атоме, 2 ГБ ОЗУ, Вин10. Сама винда летает. Когда браузеры начинают отъедать много памяти, начинаются небольшие притормаживания. Но всё вполне комфортно для офисной работы.
Сабака, нужен под 1С с аппаратными ключами (особенно когда 1С не продает программные, а также когда перенос ВМ с хоста на хост рушит лицензирование 1С). Но это больше проблемы 1С, чем гипервизора, что VMware, что Hyper-V.
Пользуемся аппаратной ключницей SEH myUTN, в т.ч. для 1С, работает без нареканий, ни разу не отваливалось ничего.
Наврное, эту историю можно отнести в эту категорию. Середина 2000-х. Небольшая фирма. Небольшой сервер HP DL360 G* (за давностью лет не помню модель) с терминальным сервером 1С на Windows Server 2003, с 512 МБ оперативной памяти… и 30 пользователями!
Оптимизировано было всё по максимуму, отключены все ненужные службы (часть нужных, да не критичных), и даже при входе пользователей загружался не Проводник (ака explorer.exe), а самописная консольная утилита (типа меню для старта разных 1С).
Но как в и известной сказке, из маленькой овечьей шкуры можно сшить хоть 7 шапок… и результат будет всё равно плачевный.
Также и здесь, когда количество пользователей приближалось к максимуму, сервер нещадно тормозил, пользователи жаловались, работа останавливалась. Контора бедная, а серверы в основном требуют память то с ECC, простую не поставишь. Так и жили.
Как обычно, до руководства порой сложно донести потребности IT-службы, были применены все методы риторики, и оно вникло в проблему и выделило бюджет. Было докуплено ЕЩЕ АЖ 512 МБ памяти. Казалось бы, всего 512, но в рамках сервера — это же удвоение ОЗУ. Сервер вздохнул новой жизнью, пользователи возрадовались, работа продолжилась.
И вот возвращаясь к теме истории — каким бы ты ни был скилловым, выше головы не прыгнуть, железо всё равно тащит!
Мне кажется, сим-карта просто находится всегда в роуминге в любом операторе, а не в emergency call
За утилиту PrintBrm спасибо.
У меня раньше была идея в создании failover кластера просто с виртуальным именем и IP-адресом, которые бы ездили между узлами, и добавлением службы Print Spooler как ресурс Generic Service в кластере. Но как раз был вопрос в синхронизации принтеров между двумя узлами. Ручной вариант (создать принтер и тут, и там) не устроил, поэтому этот тему приостановили.
А вот теперь с PrintBrm есть интересный вариант. Тем более, что можно также создать кластерное задание планировщика задач, которое выполняется на узле владельце роли (который будет определять направление репликации).
Таким образом будет и автоматический failover (упала служба/сервер) и автоматическая синхронизация принтеров.
Если бы потом ещё с очередью разобраться, было бы вообще хорошо :)
Может ещё глянуть продукт STOR2RRD, мониторинг достаточно большого количества разных СХД, бесплатная версия почти полносьтю полнофункциональна. Хоть там все и очень просто сделано
Искомый адрес: 34.192.86.119
Всего найдено записей: 1
РЕЗУЛЬТАТ ПОИСКА
Искомый адрес: 54.174.162.19
Всего найдено записей: 1
У меня OpenVPN на удаленном хосте. Также есть address-list со списком нужных адресов, через mangle маркируются пакеты, которые должны уходить через VPN, и в /ip route настроена отправка этих пакетов с такой маркировкой
pastebin.com/GSSSr7qB
Т.о. весь трафик до заблокированных адресов идет через VPN, остальное через обычный инет.
(*правда с каким-то модом на графику с нормальными FHD разрешениями, но всё остальное примерно тоже самое*)
Ведь в играх не только графика важна)
Планшет на Атоме, 2 ГБ ОЗУ, Вин10. Сама винда летает. Когда браузеры начинают отъедать много памяти, начинаются небольшие притормаживания. Но всё вполне комфортно для офисной работы.
www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-perfbest-practices-vsphere6-0-white-paper.pdf
Под разные версии VMware
Пользуемся аппаратной ключницей SEH myUTN, в т.ч. для 1С, работает без нареканий, ни разу не отваливалось ничего.
Оптимизировано было всё по максимуму, отключены все ненужные службы (часть нужных, да не критичных), и даже при входе пользователей загружался не Проводник (ака explorer.exe), а самописная консольная утилита (типа меню для старта разных 1С).
Но как в и известной сказке, из маленькой овечьей шкуры можно сшить хоть 7 шапок… и результат будет всё равно плачевный.
Также и здесь, когда количество пользователей приближалось к максимуму, сервер нещадно тормозил, пользователи жаловались, работа останавливалась. Контора бедная, а серверы в основном требуют память то с ECC, простую не поставишь. Так и жили.
Как обычно, до руководства порой сложно донести потребности IT-службы, были применены все методы риторики, и оно вникло в проблему и выделило бюджет. Было докуплено ЕЩЕ АЖ 512 МБ памяти. Казалось бы, всего 512, но в рамках сервера — это же удвоение ОЗУ. Сервер вздохнул новой жизнью, пользователи возрадовались, работа продолжилась.
И вот возвращаясь к теме истории — каким бы ты ни был скилловым, выше головы не прыгнуть, железо всё равно тащит!