по ip адресу МФУ, принтер устанавливается без проблем, но не работает сканерЭто дешевое МФУ, у него нет функции сканирования по сети, только локальное сканирование. Для производителя добавить такую функцию ничего бы не стоило, но - маркетинг. Производитель не хочет, чтобы дешевое устройство конкурировало с дорогим, поэтому урезает функции в дешевом. Так что сканирование - только через USB.
broadcast 192.168.0.254 - как бы намекает на небрежность настройки сети, и фиг знает какие косяки, если копнуть глубже.
user@maru:~$ cat /etc/qemu/bridge.conf
allow virbr0если учитывать внешний трафик, а не внутренний между виртуалками на той же машинеа я и говорил про внутренний, в моём первом комментарии было уточнение:
между виртуалками на одном хостеЯ могу поднять на одном хосте десяток виртуалок, и скорость сети между ними будет огромная. На реальном слабом железе я такой скорости не получу.
разве что реальное железо мощнее, чем эмулируемоеЭто с чего бы? У меня есть рельный хост с сетевым интерфейсом на 100 Мбит/c, на нём под KVM крутится виртуалка, которая считает, что у неё сеть 10 Гбит/c (Red Hat VirtIO Ethernet Adapter). Возможно, реальная скорость передачи (между виртуалками на одном хосте) будет меньше, чем 10 Гбит/c, но она больше, чем скорость передачи через реальную сетевую карту. И это не теория, а практика. Скорость виртуальных дисков тоже существенно больше, чем скорость реальных, за счёт кеширования (не на огромных файлах, разумеется, а на типичной реальной нагрузке, когда происходит множество мелких дисковых операций). И это тоже практика.
(39–20) × 2020 = 38 380 долларов - не сходится ?а если посмотреть на симметричную яхейку (Rainbow 38, а Lean 39), то увидим, что в книге просто опечатка. 38860 - опечатка, 36860 - правильно.
вариант A: реальной (хоть как-то обоснованной) потребности в новых серверах нет, просто много лишних денег, и срочно надо их потратить.
решение: брать самое дорогое в пределах выделенного бюджета. :)
вариант Б: работающие сейчас сервера не справляются с нагрузкой.
решение: смотреть на конфигурацию имеющихся серверов, анализировать, какой ресурс стал узким местом: оперативка, скорость процессора, скорость дисков, скорость сети. Исходя из этого, делать упор на недостающем ресурсе при выборе новых серверов.
вариант В: работающие сейчас сервера справляются, но они старые, и есть опасения, что могут умереть.
решение: смотреть на конфигурацию имеющихся серверов и покупать новые с конфигурацией не хуже старых. Этого достаточно, ведь старые и так справляются.
вариант Г: работающие сейчас сервера справляются, но ожидается существенное увеличение нагрузки, и они могут не справиться.
решение: ???
Самый сложный случай. Требуется не просто единовременное решение. Нужно разработать стратегию обновления\расширения инфраструктуры. Что купить сразу, что потом (и когда "потом", и по каким критериям принимать решения). Чтобы не выбрасывать деньги на ветер. И чтобы не было потом мучительно больно. И может оказаться, что узкое место - сеть... или пользователи... или бизнес-процессы... а вовсе не сервера. Это выходит за пределы вопроса на Тостере, это отдельная работа для специалистов, которая должна отдельно оплачиваться (если специалисты не в штате компании).