По вопросу статистики в общем, и netflow в частности, есть довольно много довольно обширных статей (изучение которых требует приличного времени). Здесь я приведу свои скрипты as-is для не очень сложного ТЗ по сбору и отправке месячной статистики арендаторам.

Вводная

Несколько арендаторов получают интернет через NAT (сам NAT завязан через policy-routing на двух провайдеров). У каждого арендатора свой вилан. Вилан «разворачивается» в сеть арендатора через управляемый коммутатор. Каждому арендатору выдаётся свой сегмент локальной сети с запретом ходить в соседние сегменты.

Задача: сказать каждому арендатору и управляющему зданием в конце месяца сколько он съел интернетов и ткнуть на тех пользователей, кто перепользовал слишком много трафика. Т.е. нам нужны: суммарная статистика по сегменту, потребление интернета каждым адресом (destination) в учитываемой сети.

Инструменты: используется netflow на циске, flow-tools на линуксе, MTA, cron.

Memory on demand — автоматическое выделение памяти виртуальной машине по необходимости.

Я уже чуть раньше писал об этой идее: Управление памятью гостевой машины в облаке. Тогда это была теория и некоторые наброски с доказательствами, что эта идея сработает.

Сейчас, когда эта технология обрела практическое воплощение, и клиентская и серверная часть готовы и (вроде бы) отлажены, можно поговорить уже не про идею, а про то, как это работает. Как с пользовательской, так и с серверной части. Заодно, поговорим и о том, что получилось не так идеально, как хотелось бы.

Суть технологии memory on demand заключается в предоставлении гостю того количества памяти, которое ему нужно в каждый конкретный момент времени. Изменение объёма памяти происходит автоматически (без необходимости что-то менять в панели управления), на ходу (без перезагрузки) и в очень короткие сроки (порядка секунды и меньше). Если быть точным, выделяется объём памяти, который заняли приложения и ядро гостевой ОС, плюс небольшой объём на кеш.

Предупреждение: Описанное в статье несколько устарело, т.к. я забросил винды в эпоху Windows 2003.

Каждый раз, когда меня знакомые спрашивают: «какой антивирус лучше?», я могу сказать только одно: «антивирус — как придворный шаман. Бывают лучше, бывают хуже, но определить, кто лучше камлает, не получится». Антивирус не гарантирует защиту от вирусов, более того, у него есть полное моральное право пропустить новую заразу и начать её детектить дня через 2-3 после «инцидента». Т.е. как основное средство защиты он годится не очень.

Ниже описывается настройка windows, которая позволит защититься от любых реальных (т.е. встречающихся в природе) вирусов без использования антивирусов. Данная конфигурация уже 3 с половиной года работает на терминальном сервере, где пользователи (в лучшие времена до 70 человек) совсем не стесняются притаскивать на флешках всяких засранцев, лазать по сети где попало и т.д.

Теория

Любой уважающий себя вирус, оказавшись запущенным, тем или иным методом стремится в системе закрепиться, т.е. создаёт исполняемый файл или библиотеку, которая прописывается тем или иным образом в запуск. «Авто» запуск или в форме «дополнения» к другим исполняемым файлам (debugger, hander, плагин, и т.д.) — не важно. Важно: существует барьер под названием «запуск кода». Даже старые-добрые вирусы, дописывающие себя в исполняемые файлы, всё равно должны иметь возможность писать в файлы, которые предполагается запускать.

Безусловно, есть вирусы, размножающиеся без создания файлов (например, мс-бласт). Но условием появления этого вируса должна быть доступность сервера для обращений с носителей вируса или запуск кода через эксплоит в браузере\сетевой компоненте. В случае дыры в браузере дальнейшее размножение не возможно (т.к. нужно обращаться к браузерам на других машинах, а это требует поднятия сервера, куда будут ходить другие пользователи и мотивации пользователям ходить именно на этот узел). В случае дыры в сетевой компоненте и размножения без сохранения на диск, описанная мною методика с большой вероятностью работать не будет и возможна эпидемия. Однако, я не уверен, что антивирусы поймают такой 0day эксплоит, плюс, их (дыры) довольно резво фиксят, так что этот сценарий я откладываю как маловероятный. Наличие же файрволов ещё более уменьшает их опасность. От не-0day вполне же спасает своевременная (автоматизированная) установка обновлений.

Итак, основную бытовую опасность представляют вирусы, запускающиеся «из файла» (хотя бы потому, что они переживают перезагрузку компьютера). Если мы запретим каким-то образом запуск «неправильных» файлов, то проблема будет решена (т.к. несохраняющийся в файле вирус не сможет пережить перезагрузку, а в случае запуска с правами пользователя, даже банального релогина).

В Windows существует технология — политика ограниченного запуска приложений. Её можно активировать в режиме «запрещать всё, что не разрешено». Если поставить запрет полный — для всех, включая администраторов, все файлы, включая библиотеки, то мы получим точную гарантию того, что посторонний (не входящий в список разрешённых) файл не будет запущен. По-крайней мере я пока не слышал, чтобы в этой технологии были дыры. Обращаю внимание, нужно запрещать и библиотеки тоже, потому что печально известный конфикер запускается с флешек именно с помощью запуска библиотеки обманом rundll32.

Однако, запреты и разрешения не будут иметь смысла, если не сформулировать правила, которые запретят запуск «чужаков».

Модель безопасности

Перед тем, как описать подробно конфигурацию, сформулирую теоретические принципы её организации:

1. То, куда пользователь может писать закрыто для запуска.
2. То, что пользователь может запускать, закрыто для записи.

В ходе отладки облака собралась статистика по потреблению ресурсов инсталляторами различных версий Linux.

Все ОС ставятся полностью автоматом (preseed и kickstart), в минимальной конфигурации с незначительными коррекциями (в частности, openssh-server для дебиана и специальное Xen'овское ядро). Так как собрать статистику «только за установку» не получается, приведена статистика за операцию «установка + первая загрузка».

Установка целиком идёт с репозитория (т.е. сетевой трафик большей частью — это скачивание пакетов).

Показатели:

• процессорное время — реальное время работы процессора. Время установки системы больше, так как во время операций ввода/вывода процессор простаивает. (фактически, это использованные такты процессора, поделенные на частоту)
• потребление памяти — благодаря memory on demand объём выделенной памяти меняется «на лету». Для подсчёта получившегося потребления введена синтетическая величина Гб*ч (1Гб*ч = 1 Гигабайт памяти на 1 час или 512 Мб на 2 часа, или 2Гб на пол-часа)
• Сеть и диск интутитивно понятны. Учитывается как объём, так и количество запросов.

ОС	Процессорное время	Потребление памяти	Запись на диск (Мб, операций)	Чтение с диска (Мб, операций)	Передано в сеть (Мб, пакетов)	Получено из сети (Мб, пакетов)
Debian Lenny i386	2 мин. 39 с	0.065 Гб*ч	1216 Мб, 60657	25 Мб, 3695	1.02 Мб, 19444	130.18 Мб, 91672
Ubuntu Lucid Lynx i386	4 мин. 19 с	0.128 Гб*ч	2324 Мб, 144350	39 Мб, 4430	3.76 Мб, 70887	213 Мб, 154146
Ubuntu Lucid Lynx amd64	3 мин. 39 с	0.563 Гб*ч	2510 Мб, 191514	45 Мб, 4749	4.41 Мб, 83386	214.28 Мб, 155494
Centos 5.4 i386	1 мин 48 с	0.127 Гб*ч	1191 Мб, 153543	137 Мб, 9348	8.65 Мб, 163729	365.39 Мб, 267416
Centos 5.4 amd64	1 мин. 46 с	0.149 Гб*ч	1408 Мб, 185964	139 Мб, 9209	9.01 Мб, 172613	416.75 Мб, 306086

Я не совсем могу объяснить эти результаты (в частности, такая большая разница по времени между ubuntu 32 и 64 бита), однако, центос сильно удивил — время установки у него ощутимо больше, чем у debian, а реальной нагрузки на процессор — меньше.

Объявление: Требуется сотрудник технической поддержки. Обязанности: ответы на звонки клиентов, помощь в погрузо-разгрузочных работах. Требование: высшее образование, опыт работы от 5 лет на аналогичной должности.

Немного утрирую. Но что значит высшее образование в применении к IT? Безусловно, выпускник MIT или Berkley со специализацией в Computer Science — это реально круто.

… но мы же про Россию, да? Менеджер по продажам с дипломом по морской навигации, финансовый директор с диссертацией по органической химии, лингвист-сисадмин…

Впрочем, нет, не лингвист. Прикладная математика и физика. Кафедра гидрогазодинамики. Уравнение Навье-Стокса, эпюры перерезывающих сил… Это очень важная информация, когда мы начинаем обсуждать особенности работы ядра гостевой системы в паравиртулизированной среде. Ну или, хотя бы, ковыряться в питоновском коде, развлекаясь с фрагментами функционального программирования.

Зачем айтишнику высшее образование? Зачем айтишнику какое-нибудь высшее образование (т.е. зачем галочка «есть хоть какое-то в/о»)?

Я слышал несколько аргументов, и ни один из них меня не устроил.

Итак, аргументы от адвоката дьявола:

Доллары в квадрате уже достаточно повеселили досточтимую публику.

Однако, есть вещь, которая в гугле (яндексе и т.д.) сильно огорчает, не смотря на все их попытки «понимать», что ищет пользователь. Это отказ воспринимать спецсимволы.

Ведь понятно, что если я ищу «system()» (exit(), open() и т.д.) — это не то же самое, что просто «system», «exit», «open». Если я ищу "[:lower:]" это не то же самое, что «lower» (ладно, регэкспов в поисковиках не будет никогда, но хотя бы просто по заданной строке искать...). Ведь я явно говорю, что хочу найти. Ну просто бери man-страницу и показывай. Статья про system() на opengroup просто обязана быть пришлёпнута первой в результатах поиска… Но нет.

Пробегал мимо сборочного стола в пятницу, инженеры прикручивали уши к очередной партии оборудования. Не смог удержаться, вот фотографии Extreme Summit X650. Каждый порт — 10Гб. В три раза быстрее SATA2/300, в полтора раза быстрее SATA3/600. Каждый коммутатор в сумме даёт 240 гигабит. Объединяются в стек (фотография кабеля и разъёма под катом).

Два коммутатора дают чуть меньше полутерабита в секунду. SFP'ы ещё не приехали, так что пока там красуются резиновые заглушки. Увы.

Собственно, писать больше нечего, зато можно смотреть (картинки кликабельны).

Большинство опытных пользователей Windows знают про возможность ввода символа по его коду: Alt-[номер на дополнительной клавиатуре]. Самые опытные знают, что поведение различается у юникодных и неюникодных программ (юникодные хотят двухбайтный код, неюникодные — код в текущей кодировке). Особенно приятно пользоваться этим методом на ноутбуках, где дополнительная клавиатура либо отсутствует, либо доступна с использованием регистра Fn.

Большинство пользователей линукса знают о Compose key. И о том, что с её помощью можно вводить часто необходимые знаки, такие как кавычки-ёлочки (« == Compose < <, » = C > > ), тире (— = Compose ---), символ параграфа (§ = Compose s o), всякие умляуты и диакриты (àãå, Compose `a, Compose ~ a, Compose o a), символ фунта (£ = Compose L -), неразрывный пробел (Сompose и два пробела) и т.д.

Но иногда хочется вводить странные символы (например, Ѧ или забавные значки из раздела «различные символы» таблицы юникода: ☭, или даже символы других языков: シツ, あ, красивые нестандартные скобки: 【такие】 или 〘「такие」, или даже 《такие 》。

Есть унылый вариант — ковыряться в таблице символов. Интересно первые два-три раза. Дальше их хочется вводить быстрее. И этот метод есть: Ctrl-Shift-U — после этого удерживая шифт нужно ввести нужный код в шестнадцатиричном виде (т.е. 1 — 4 символа).

Сами коды можно посмотреть в той же таблице символов. Однако, метод работает только в gnome-приложениях (например, в опере с момента ухода с Qt она работать перестала). А в Inkscape оно работает даже интереснее — там после нажатия Ctrl-Shift-U в подсказке появляется будущий символ, и можно поправить опечатку в вводе кода символа.

Одна из первых проблем, с которой сталкиваешься, когда решаешь сделать в облаке «неограниченную память» — это то, что современные операционные системы не готовы к «неограниченной памяти». Связано это с дисковым кешем.

Ядро забирает себе всю свободную память для кеша. Если есть дисковые операции и есть свободная память — кеш будет расти. В случае сервера с единолично пользуемой памятью это благо, однако, если мы говорим о том, что все мегабайты платные, платить за дисковый кеш в 10-20Гб откровенно не хочется.

Я пытался найти возможность ограничить размер дискового кеша для линукса, но всё, что нашёл — это странный патч 2003 года (который, разумеется, в основную ветку не взяли).

Получается, что чем больше гость работает, тем больше его ядро берёт себе памяти от (неограниченного) объёма. Результат — если не ограничивать систему вообще, то она за весьма незначительное время вырастает либо до размера дисковых устройств (спасибо, дискового кеша больше, чем размер диска, не бывает), либо до максимально доступного на платформе объёма памяти. Заметим, что в этих условиях пасуют все технологии — и компрессия памяти, и дедупликация страниц памяти (у каждой ВМ свой кеш). Эта проблема стоит перед любой системой виртуализации. Ниже описываются варианты решения с оглядкой на Xen Cloud Platform.

Слова «облако», «облачные вычисления», «облачный» используются для чего попало. Новое модное слово, buzzword. Мы видим «облачные антивирусы», «облачные блейд-сервера». Даже именитые вендоры сетевого оборудования, не стесняются выставлять коммутаторы с ярлыком «for cloud computing». Это вызывает инстинктивную неприязнь, примерно, как «органические» продукты питания.

Любой технарь, который попытается разобраться с технологиями, лежащими в основе «облака», после нескольких часов борьбы с потоком рекламных восторгов, обнаружит, что это облака — это те же VDSы, вид сбоку. Он будет прав. Облака, в том виде, как их делают сейчас — обычные виртуальные машины.

Однако, облака, это не только маркетинг и переименованные VDS. У слова «облако» (или, точнее у фразы «облачные вычисления») есть есть своя техническая правда. Она не такая патетичная и восхитительно-инновационная, как рассказывают маркетологи, но она всё-таки есть. Придумана она была много десятилетий назад, но только сейчас инфраструктура (в первую очередь, Интернет и технологии виртуализации x86) доросла до уровня, который позволяет реализовать её в массовом порядке.

Итак, сначала о причине, которая вообще породила потребность в облаках:

Вот как выглядит предоставляемая услуга для обычного VDS (на месте этого графика может быть любой ресурс: процессор, память, диск):


Обратите внимание: это недельный график. Существующие технологии временного увеличения лимита потребления ресурса (burst, grace period) не способны решить эту проблему на таких длинных интервалах. Т.е. машина недополучает ресурсы тогда, когда они ей больше всего нужны.

Вторая проблема — посмотрите на огромные интервалы (голубой цвет), когда ресурсы, фактически, пришлось оплатить, но использовать не удалось. Виртуальной машине ночью просто не нужно столько ресурсов. Она простаивает. И не смотря на это — владелец платит по полной.

Возникает проблема: человек вынужден заказывать ресурсов больше, чем нужно в среднем, для того, чтобы переживать без проблем пики. В остальное время ресурсы простаивают. Провайдер видит, что сервер не нагружен, начинает продавать ресурсов больше, чем есть (это называют «оверселл»). В какой-то момент, например, из-за пика нагрузки на нескольких клиентов, провайдер нарушает свои обязательства. Он обещал 70 человекам по 1Ггц — но у него есть только 40 (2.5*16 ядер). Нехорошо.

Продавать полосу честно (без оверселла) невыгодно (и цены нерыночные получаются). Оверселлить — снижать качество сервиса, нарушать условия договора.

Эта проблема не связана с VDS или виртуализацией, это общий вопрос: как честно продавать простаивающие ресурсы?

Именно ответом на эту проблему и стала идея «облачных вычислений». Слова хоть и модные, но своей основой уходящие во времена больших мейнфреймов, когда продавалось машинное время.

Облачные вычисления делают то же самое — вместо лимитов и квот, которые оплачиваются вне зависимости от реального потрбления, пользователям предоставляется возможность использовать ресурсы без ограничения, с оплатой реального потребления (и только того, что было реально использовано). Это и есть суть «облака».

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

Суть проблемы: Системы виртуализации с высокой степенью виртуализации (я это говорю, чтобы отмести в сторону openvz) предоставляют место виртуальным машинам в форме виртуального диска. Или, точнее, виртуального блочного устройства. Иногда эмулируется скази (VMWare Server, Virtual PC), иногда «неопределённое блочное устройство», иногда прямым текстом «виртуальный диск» (Xen для PV-машин). Важным является то, что это устройство полностью повторяет свойства блочного устройства — набор секторов, которые можно читать и писать.

Большинство систем виртуализации позволяет изменять размер дисков. Многие системы позволяют это делать на ходу, в онлайне.

Вопрос звучит так: а может ли гостевая ОС воспользоваться этим местом свободно? Этот вопрос выходит за рамки виртуализации и является общим вопросом: есть ли у нас файловые системы, которые способны динамически изменяться в размере в штатном режиме?

Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:

как называть узлы и интерфейсы узлов в сети?

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

Давным-давно я написал набор костылей для автоматического копирования дисков под windows.

Сейчас мне приспичило то же самое под linux.

Скрипт сильно полагается на отрабатывание udev'ом автомонтирования и заточен под текущее состояние дел в lenny (и, вероятнее всего, в бубунтах). Предусмотрена ситуация нескольких CD (обрабатывается первый) и наличия loop-device'ов (монтированных ISO), они пропускаются.

Принцип работы: запустили скрипт, вставили диск, он скопировался, диск выдвинулся, как только вставили следующий, он снова скопировался. Отлично подходит для копирования пачки дисков без отвлечения на нажатия кнопок на клавиатуре.

#!/bin/sh
target="/pub/anime/from_cd"

while true
do
        mounted_cd_path=`mount|grep -v /dev/loop|grep iso9660|head -n 1|awk '{print $3}'`
        mounted_cd_device=`mount|grep "$mounted_cd_path"|awk '{print $1}'`
        if [ $mounted_cd_path- = - ]
        then
                sleep 5
                continue
        else
                name=`volname $mounted_cd_device`
                echo $name: $mounted_cd_device mounted to $mounted_cd_path
                mkdir $target/$name
                cp -R $mounted_cd_path/* $target/$name
                eject $mounted_cd_device
                echo "ejected, please instert next disc or press Ctrl-C to exit"
        fi
done

Недавно был пост о том, что плохо в облачных вычислениях. Пост был не очень, но там прозвучало невысказанное.

Так что правильнее было бы поговорить, чего боятся в облачных вычислениях?

Сокращение персонала

Сейчас на обслуживание IT-инфраструктуры предприятия тратятся существенные ресурсы. 35-40 тысяч в месяц — это минимум. Обычно, суммы от 60 до 100+ тысяч. Это не только услуги связи, электричества, но зарплаты персонала. (разумеется, размер компаний разный, и у кого-то расходы могут быть миллионными). Персонал объективно ощущает, что если завтра все пересядут на хромос/ипады (или их наследников) и будут работать в гугльдоксах, то за что им будут платить деньги? Это подспудное ощущение, которое слегка кусает любого сисадмина. Скайп «каннибализирует» не только воип, но и навыки специалистов по астериску/офисным АТС. Гугльдоксы пока страшно выглядят, но стремятся к всё более приличному состоянию. Интернет становится всё доступнее, его всё меньше хочется заворачивать через прокси, системы контроля доступа, системы учёта трафика и все прочие признаки корпоративной сети. Компанию на 20 человек прекрасно обслужит SOHO-железяка, а возможно, и просто WiFi точка доступа с ноутбуками вокруг. Всего IT — один принтер, воткнутый в сетевой порт того же самого WiFi. На компьютерах скайп, гугльдоки и веб-почта.… Вы действительно думаете, что тут нужен сисадмин?

Страшно. Казавшиеся сложными и требовавшими Высоких Знаний технологии низводятся до уровня обычного домашнего пользователя… и работают. Active Directory, Exchange, sharepoint, офисы на локальных машинах, ISA, сервер WSUS, squd, собственный DNS-сервер, MX'ы, групповые политики…

В прошлом топике про СКС меня упрекнули, что нет красивых картинок правильной СКС. Откровенно, мне никогда не удавалось самому сделать красивую серверную, на моей предыдущей работе после меня осталось «гнездо паука» (со стороны СКС, со стороны серверов там более-менее хорошо). С СКС я боролся несколько лет, но так и не одолел. После того, как я перешёл на работу в Селектел и посмотрел на машинный зал, у меня загорелись глаза пофотографировать. Свои ошибки я понял только после того, как посмотрел, как работают монтажники. Всё, стойки, кроме той, что на последней фотографии, оформлял yuhenobi, последнюю Саша Тугов (которого, увы, на хабре нет).

После долгих уговоров начальства, со скрипом, мне таки разрешили пофотографировать.(А, посмотрев на результат, решили перенести в блог компании).

Под катом фотографии из дата-центра Селектела (каждая фотография кликабельна на фулл-сайз) и комментарии.



Обратите внимание: провода перед попаданием в вертикальный толстый пучок, собираются в маленькие жгуты, благодаря этому операция с каждым жгутом может быть выполнена довольно просто: его просто расплести, найти нужный провод, сплести обратно. В данном конкретном случае не планируется провода перекроссировать, так что провода стягиваются очень плотно. Вторая важная вещь, которая достигается за счёт тонких жгутов: до момента, пока жгут не притянут к кабель-органайзеру, он создаёт минимальное сопротивление воздуху (который перегоняется из холодного коридора в горячий вентиляторами стоечных устройств).

RSS-фиды для торрент-файлов позволили заменить старые-добрые файловые эхо-конференции Фидо. По ним новые файлы по заранее выбранной тематике «приходили сами», т.е. о новинках можно было узнавать не по обзорам на сайтах, а разбирая пришедшие файлы.

Удобство подобного трудно описать. Считайте, тот же ютуб, но с настоящим FullHD (которое FullHD, а не то, что ютуб HD называет), в своём, удобном, плеере, без лагов и рекламы… В свободное от работы время компьютер скачивает все новинки сам, а вы лишь выбираете, что из этого смотреть (а что прибить). Непозволительная трата интернета, роскошь, ставшая доступной лишь в последние годы с увеличением скоростей и почти повсеместной отменой тарификации по трафику.

Как это работает?

Сайт, сопровождающий трекер (mononova, rutracker, bakabt, thepiratebay, animesuki, demonoid и т.д.) имеет возможность формировать фиды — страницы в формате RSS [wiki], содержащие в себе ссылки на новые torrent-файлы.

Обычно при этом есть возможность отфильтровать (прямо на сайте, при выборе нужного RSS) что именно интересует. Например, на tokyotosho позволяют сформировать правильную ссылку RSS с выбором интересующих типов файлов: tokyotosho.info/rss_customize.php.

В хорошем случае, по ссылке будет torrent-файл. В плохом — ссылка на html-страницу, на которой уже будет ссылка на torrent-файл. (об этой тонкой подлости мы поговорим в разделе реализации).

Дальше всё просто: некий клиент (торрент-клиент с встроенным RSS или специализированная программа) скачивает периодически RSS, скачивает torrent-файлы из неё, скачивает содержимое торрентов (ну или передаёт на скачивание торрент-клиенту). RSS скачивается раз в N минут (у меня — раз в час), файлы появляются на диске сами собой.

Вот такая красота на javascript нашлась при пристальном изучении исходных текстов xen cloud platform: pastebin.com/FyN3pSh5

Может, ассемблер всё-таки лучше?

Я понимаю, что кому-то не хочется показывать свой исходный текст, но это настоящее издевательство…

Вышла новая версия Xen Cloud, версии 0.5. Традиционно для XCP, список новинок и изменений сокрыт во мраке.

На основной странице зена про это ни слова, однако, появилась страница: www.xen.org/products/cloud_source_0.5.html и сообщение от Vern Burke в рассылке.

PS А вот и новый логотипчик XCP:

Предыдущий топик про ddccontrol, открыл для меня, что по DDC можно мониторы выключать. Не вгонять в сон, не включать энергосберегающий режим, а реально выключать. Так, чтобы гасла (и совсем не мигала!) лампочка питания на морде. Как от нажатия выкл на той же самой морде. Разумеется, можно не только выключать, но и включать. Программно!

1) Это можно сделать программно (ddccontrol)
2) Это можно прописать в скрипт
3) Скрипт можно повесить на хоткей
…
5) PROFIT??

В список профитов можно записать возможность включения/выключения ОДНОЙ кнопкой на клавиатуре ВСЕХ мониторов (у меня их сейчас два, и я планирую больше в будущем). Кнопка на клавиатуре куда приятнее для нажатия, чем кнопка монитора (по которой её целиться надо, да и монитор от нажатия может слегка поворачиваться, что раздражает).

Немного случайно получившегося экстремального тестирования сетевого оборудования.

Исходная конфигурация: между компьютером и серверной примерно 40 метров витой пары. С одной стороны компьютер с кривым блоком питания, подающим 220 В (относительно земли) на все контакты. (т.е. напряжение между контактами пары было правильным, а вот каждый из них относительно земли имел потенциал ~200В). До момента, когда эникейщик, разбиравшийся с барахлящим компьютером обраружил это методом «ой б#$ на #&@ в %&@#!» история с периодическим пропаданием сети тянулась больше года, за это время было перепробовано довольно много железа. Всё осложнялось тем, что БП подавал 220 на корпус не сразу, так что первичные замеры (где-то на третью жалобу о пропаже связи) ничего крамольного не показали.

Итак, вынужденно протестированное оборудование:

SOHO:

• Intel Business Hub (4 порта) — переставал работать через часа-два, и не работал, пока не включат/выключат
• Zyxel ES-2108 — пожёг порт
• Dlink DES-1005D — погорел полным комплектом (перестали работать все порты).
• Cisco 1750 — молча делала порт down (так, как будто там нет сигнала) до перезапуска железки

19" оборудование:

• 3COM 4200 — через пару суток выключал порт до полного обесточивания коммутатора (после выключения-включения порт вновь оживал)
• 3COM 4200G — аналогично выключал, но порт «приходил в себя» в течение суток после отключения кабеля
• Allied Telesis Rapier AT24i — игнорировал и работал
• Cisco 1841 с карточкой с switchports — игнорировала и работала
• Edimax ES-3124RL — единственный из стоечных, пожегший себе порт

Я пытался найти информацию о «выносливости» устройств, но судя по всему, это нештатный режим работы устройств…