Несмотря на то, что еще нет официальных сообщений о выходе 6ой версии дистрибутива Debian «Squeeze», в твиттере уже сообщают о переносе stable с lenny в squeeze и действиях по созданию образов:
Debian's CD team is also warming up: As 09:57 UTC we now have squeeze versions of the CD generation scripts.

Цитата из чернового варианта release notes: «Новый выпуск Debian опять содержит намного больше программ, чем предшественник, lenny. Дистрибутив включает в себя более 10352 новых пакетов, всего их стало более 29050. Большая часть программ, входящих в дистрибутив, была обновлена: более 15436 пакетов (что составляет 67% дистрибутива lenny). Также, по различным причинам многие пакеты (более 4238, 18% дистрибутива lenny) были удалены из дистрибутива. Эти пакеты не будут обновлены, в программах управления пакетами они будут помечены как „устаревшие“ (obsolete).»

Более подробно прочитать можно в информации о выпуске и новое в squeeze

По этому поводу состоятся вечеринки, со списком мест можно ознакомиться на wiki.debian.org/ReleasePartySqueeze, на момент написания поста в России было запланировано две — в Москве и Новосибирске.

UPD1: Как сообщают в комментах появилась официальная новость

UPD2: Ссылки на скачивание — www.debian.org/CD/index.en.html

Проходя как-то ближе к концу лета мимо стойки в одном из датацентров, увидел там коробку размером в 4-5 юнитов, покрытую чем-то, подозрительно напоминающим ржавчину. В коробке оказались мини серверочки возможно дедикейтед хостинга.
На материнке процессор похожий на Intel Atom с пассивным охлаждением, 2.5" винты, сеть.
Фотки под катом.

Вопрос номер 0 — зачем?

В посте про pnp4nagios я писал «Nagios/Pnp4Nagios не замена комплексу сбора статистики о состоянии системы». Почему я так думаю? Потому что 1) статистика состояния системы обширна и включает множество показателей 2) не всегда есть смысл их мониторить, точнее генерировать алерты. Например, знать сколько сколько операций ввода-вывода делает диск или происходит переключений контекста неплохо, но почти никогда не критично. Ну и кроме того, Nagios просто не предназначен для этого. В данной статье я не буду делать полное описание системы, ограничусь лишь особенно интересными, с моей точки зрения, моментами.

Вопрос номер 1 — почему collectd?

Основные моменты почему из Munin, Cacti и прочих я выбрал collectd:

1. Масштабируемость
2. Легковесность
3. Концепция — всё есть плагины
4. Сбор и запись данных разделены
5. Количество собираемых показателей
6. Расширяемость

Об чем

RRD и RRDTool прочно вошли в нашу жизнь как средство хранения статистических данных данных и отрисовки графиков по ним. Если с графиками в принципе все понятно, то из поля легенды можно извлечь еще немного пользы. В частности, можно выводить сумму всех значений источника данных (datasource), например входящий траффик за промежуток времени, что можно использовать в дальнейшем для приблизительных прикидок. Мой пример для pnp4nagios, но верно для всех остальных систем на основе rrdtool.

В процессе обсуждения онлайн миграций с Щорсом, родились 2 видео с онлайн миграцией OpenVZ контейнеров между нодами.

В первом видео мигрирует контейнер в котором запущен nginx, к нему идут запросы из ab в два потока на /status, запросы пишутся в лог, т.е. размер занятого места динамически изменяется.



Во втором мигрирует контейнер в котором происходит копирование таблицы внутри mysql'я (select into blabla2 select * from blabla1), размер базы 350мб, 850к записей.



Основная хост машина — core quad q6600 с вистой, внутри запущены VMware виртуалки, а в них уже Linux с OpenVZ.

3е — из виртуалки на vmware в виртуалку hyper-v, разные физические машины, через свитч длинк 100мбит

Введение.

Выбрав Nagios в качестве системы мониторинга, получаем систему слежения за качественными характеристиками окружения и историю изменения состояний. И, если посмотреть текст сообщения пробника на данный момент и во время прошлых изменений состояния еще возможно, то данные по периодам между изменениями отсутствуют как класс. При любой более-менее активной работе с мониторингом, возникает желание просмотра истории изменений количественных характеристик тоже, что стандартный Nagios обеспечить не может. Можно, конечно, продублировать все необходимые пробники в тот же Cacti, но это как минимум дополнительные накладные расходы как на конфигурирование так и на машину с поллером. К счастью, Nagios умеет переложить это на плечи пользователя, обеспечивая механизм так называемых «данных производительности» (performance data). В данной статье рассматривается одно из решений по сбору и визуализации полученных данных – Pnp4Nagios.