Простое решение для распределения нагрузки в пуле принтеров

в 4:44, , рубрики: printer load balancing, принтеры, принтеры на терминальном сервере, пул принтеров, системное администрирование, метки:

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

Имеем:

1) терминальную ферму Win2008R2
2) 3 одинаковых принтера

Расскажу немного о самой проблеме. У нас есть отдел заявок в службе доставки. За одну ночь они спечатывают суммарно 8 тысяч листов А4. Нагрузка на принтеры ложится именно ночью — когда все заказы и маршруты сформированы. Последнее время качество неоригинального тонера стало хуже, и из-за этого в аппарате наблюдается перегрев. С оплавлением пластика и попаданием на движущиеся элементы.

Решение 1. Замена принтера на более мощный.

Я специально постараюсь не приводить марки принтеров. Скажу лишь, что в моём принтере ресурс заправки картриджа 25 тысяч листов А4, месячный ресурс принтера 300 тысяч. Мой принтер покупался за 25 тысяч рублей. Первое что было придумано — купить более крутой принтер. Но исследование яндекс-маркета показало, что либо у аналогов высокая цена эксплуатации и себестоимости на лист бумаги, либо изначально несоразмерно бОльшая цена(>200тыс.р.), даже по старому курсу $. Всё таки решили не менять…

Решение 2. Объединение принтеров в пул.

Логичным решением перегрева мы посчитали самый просто вариант — дать принтеру остывать. Как это сделать? Естественно — распределить печать на несколько устройств! И лучше сразу это автоматизировать дабы исключить «человеческий фактор».

Перечислю несколько вариантов распределения нагрузки на пул.

Вариант 1. Стандартная группировка в пул.
Использовалась стандартная статья MS в качестве инструкции. Но тут же выяснилась проблема — второй и последующий принтеры печатают ТОЛЬКО в том случае, если предыдущие заняты. Получается неравномерный износ и перегрев первого принтера… Это решение подходит в случае, если у нас очень мощный и надёжный первый принтер. Решение нам не подходит, опять ввиду цены мощного принтера.

Вариант 2. Стороннее ПО.
Признаюсь честно — с большим трудом нагуглил всего 2 программы под мои задачи… Первая — попалась очень глючная, постоянно блокировала спулер на терминальной ферме так, что приходилось ребутать серваки. И требовала постоянного висения в трее. Вторую — не осилил. Вроде всё просто — но выскакивает одно и то же окошко и всё тут. Обе программы платные, но с триальным периодом. Вобщем, пока что рынок ничего адекватного и рабочего «из коробки» не предлагает.

Вариант 3. Оказывается, всё очень просто. Round robin DNS
Меня смутило поле «имя или IP адрес» в окошке "установка принтера". И я попробовал указать DNS имя… работает!
Это уже намного интереснее. Мы можем на одно DNS имя посадить несколько принтеров. Получается выбор принтера теперь зависит от DNS-установок! А это уже автоматизация как минимум на уровне скриптов!

Итак. У меня домен AD. Я создаю домен 3го уровня printers, и прописываю A-хост c именем нашего «пула» — oz. Полное имя oz.printers.mydomen.local. В качестве IP-адреса указываем наш первый принтер. Следом создаём такую же запись, но с другим IP-адресом(адрес второго принтера). На обоих записях настраиваю TTL=0, дабы резолв не кешировался, и был честный рандом.
Если нужно скорректировать более приоритетную нагрузку на какой то принтер — можете поиграться с TTL.

Теперь немного изысканий.
1) один принтер выключен — второй ВСЕГДА напечатает задание.
2) если на первом открыта крышка или какие то другие логические проблемы, то… Если у нас по резолву придёт печать этот принтер, то с сервера задание «как будто» уйдёт на печать, но напечатано на РАБОЧЕМ принтере не будет. Как только вставляем картридж, или закрываем крышку — принтер отпечатывает всё, что было отправлено конкретно ему.
3) такая схема не работает с разными принтерами. Исключение — принтеры с универсальным или одинаковым драйвером. Но тоже криво(всегда проблемы с дуплексом)… Нормально работает на идентичных принтерах, проверено.
4) всплывающие информационные сообщения пользователю от принтера при TTL=0 не работают. Но этому я даже рад. Думаю это зависит от принтера.
5) у меня маршрутные листы печатались из 1С. Печать была сборная — человек нажимал кнопку печати, и 1С-клиент собирал документы из разных мест, и по мере поиска — тут же выводил на печать. При TTL=0 получался жуткий фарш из цельного маршрутного листа на всех принтерах. Выхода тут 2 — использовать TTL>0, и сократить вероятность таких ситуаций к минимуму, либо вариант 2 — переписывать 1Ску на вывод печати.

Как итог. Я считаю мой опыт окажется кому то полезным. Спасибо за Ваше внимание!
PS: Вот фото валика после оплавления пластика

Автор: derwin

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js