Я не первый год работаю администратором в интернет-провайдерах, администрирую в том числе DNS. Чем мериться будем? :)
Проблема 1 — согласен. Впрочем, я говорил о самом очевидном решении, а не самом оптимальном :)
Проблемы 2 у меня не наблюдалось, несмотря на то, что пользователи между pptp-серверами раскидывались через round-robin. И если один из серверов мёртв, они преспокойно уходили на следующий.
А происходит это потому, что резольверы ОС получают не по одному адресу на запрос, а сразу пачку. round-robin определяет только то, в каком порядке эти адреса в пачке будут идти. Поэтому закешированная копия клиента будет содержать все возможные адреса.
Таким образом, если локальный кеш не используется, клиент будет получать при каждом запросе новый адрес, что даёт 50% вероятность, как Вы уже указали. А если используется, то будет браться следующий адрес из локального кеша (если программист прикладного софта не полный идиот). Здесь тоже 50% вероятность. Ни в том, ни в другом случае никто лапу сосать не будет. Поэтому, если не стоит задачи подключаться всегда с первого раза, что бы ни случилось, то такая система вполне имеет право на жизнь. Разумеется, если нагрузка распределяется более-менее равномерно.
А есть ещё и стандартизированный механизм динамического обновления зон. Несложно достаточно быстро выводить из зоны упавший сервер.
С XDMCP терминалами я игрался только ради собственного удовольствия, поэтом о промышленном внедрении сказать ничего не могу. Но попытаюсь ответить в меру своего понимания.
чтобы клиенты имели единую точку входа для терминальной работы, но автоматически распределялись по нескольким терминальным серверам?
Самое очевидное решение — балансировка подключений через round-robin dns. К тому же это надёжнее, чем единая точка входа, поскольку отказ последней больше не страшен.
не целиком интерактивную сессию запускали с десктопом терминалки в окошке, а чтобы могли запустить отдельное опубликованное терминальное приложение
Если я правильно понимаю вопрос, то здесь не нужен даже XDMCP, достаточно ssh X forwarding.
Согласен, хотя под спецификой я подразумевал скорее ресурсоёмкость задачи каждого отдельного сотрудника.
Разумеется, один сервер (или тысяча, но в одном месте) на всю планету — не самое лучшее решение. Я понял условие задачи так, что 100+ машин будут сконцентрированы в одном месте, потому внёс предложение с точки зрения упрощения администрирования.
Хотя я считаю, что при достаточно больших масштабах нужно в первую очередь обращать внимание на планирование — что действительно нужно каждому пользователю, в какие группы их можно объединить и какую это даст возможность для оптимизации.
Помните «перламутровые пуговицы»? Продавали же контрафакт в универмагах, значит можно. Другое дело, что с этим должны бороться соответствующие органы, причём бороться адекватно, а не лечить топором головную боль. Иначе меня, как администратора интернет-провайдера, смогут посадить за то, что через мои серваки и свичи этот нелегальный контент прокачивается. А там и до энергетиков дело дойдёт, обеспечивающих это оборудования электричеством :)
Мне кажется, что 100+ рабочих машин проще делать терминальными клиентами, если это позволяет специфика работы использующих их сотрудников. Если initrd забирает по tftp с одного сервера, то абсолютно неважно, 1 человек его заберёт или тысяча.
Нельзя. Да и с продавцом ножей тоже нельзя. Админ не занимается распространением контента, будь он легальным или нет. Админ обеспечивает функционирование системы распространения этого контента. Поэтому сравнивать его можно, например, с владельцем какой-то торговой площадки. Чем там торгуют — он может и не знать. Торгуют ли кухонными ножами, продают ли из-под полы нелегальные товары — он всего лишь обеспечивает место и условия для того, чтоб произошла торговля.
Может и дешевле. Но опять же, сейчас речь не о том :)
Я говорю о том, что если уж принято решение о смене ОС, то изменение шаблонов — далеко не самая большая проблема, которая возникнет.
Тред о неоднородном ПО внутри одной организации. Что и как происходит снаружи — совсем другой вопрос и он здесь не обсуждается. Вы же сами привели в пример конфликт двух сотрудниц одной компании, а вовсе не бухгалтера фирмы и налогового инспектора, к примеру.
Никогда не видел смысла в таком софте, но статья годная. Пойду попробую, авось не придётся ручками писать загрузку/сохранение правил iptables для дебиана :)
Поддерживаю. Прошёл долгий путь от akregator'а через claws-mail-rssyl и liferea к Опере. А потом поставил chrome и пользуюсь нынче google reader'ом. Привыкнув к некоторым неудобствам хрома и гугль ридера, перестаёшь их замечать и остаётся чистое удобство :)
Да, писали все и все вкладывались. Всё закончилось тем, что понимание одного из участников о распределении ролей и власти радикально разошлось с остальными.
Проблема 1 — согласен. Впрочем, я говорил о самом очевидном решении, а не самом оптимальном :)
Проблемы 2 у меня не наблюдалось, несмотря на то, что пользователи между pptp-серверами раскидывались через round-robin. И если один из серверов мёртв, они преспокойно уходили на следующий.
А происходит это потому, что резольверы ОС получают не по одному адресу на запрос, а сразу пачку. round-robin определяет только то, в каком порядке эти адреса в пачке будут идти. Поэтому закешированная копия клиента будет содержать все возможные адреса.
Таким образом, если локальный кеш не используется, клиент будет получать при каждом запросе новый адрес, что даёт 50% вероятность, как Вы уже указали. А если используется, то будет браться следующий адрес из локального кеша (если программист прикладного софта не полный идиот). Здесь тоже 50% вероятность. Ни в том, ни в другом случае никто лапу сосать не будет. Поэтому, если не стоит задачи подключаться всегда с первого раза, что бы ни случилось, то такая система вполне имеет право на жизнь. Разумеется, если нагрузка распределяется более-менее равномерно.
А есть ещё и стандартизированный механизм динамического обновления зон. Несложно достаточно быстро выводить из зоны упавший сервер.
Самое очевидное решение — балансировка подключений через round-robin dns. К тому же это надёжнее, чем единая точка входа, поскольку отказ последней больше не страшен.
Если я правильно понимаю вопрос, то здесь не нужен даже XDMCP, достаточно ssh X forwarding.
Разумеется, один сервер (или тысяча, но в одном месте) на всю планету — не самое лучшее решение. Я понял условие задачи так, что 100+ машин будут сконцентрированы в одном месте, потому внёс предложение с точки зрения упрощения администрирования.
Хотя я считаю, что при достаточно больших масштабах нужно в первую очередь обращать внимание на планирование — что действительно нужно каждому пользователю, в какие группы их можно объединить и какую это даст возможность для оптимизации.
Я говорю о том, что если уж принято решение о смене ОС, то изменение шаблонов — далеко не самая большая проблема, которая возникнет.