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

Выдалось немного свободного времени, поэтому сегодня я решил написать, как обстоят дела с работой Ubuntu 10.04 под Hyper-V.

Не смотря на то, что Ubuntu не входит в список официально поддерживаемых Linux дистрибутивов работает он под Hyper-V отлично. Более того никаких дополнительных компонентов интеграции ставить не пришлось. Все что нужно для работы с Hyper-V давно находится в свежих ядрах Linux.

Ну что, приступим?

Наблюдая выводы таких команд, как top, htop, uptime, w и, возможно, других, пользователь наверняка обращал внимание на строку load average:

Вчера получил письмо примерно следующего содержания:

Мы рады анонсировать бета-релиз Amazon Simple Email Service (Amazon SES) — хорошо масштабируемого и дешевого сервиса для отправки электронной почты для бизнеса и разработчиков. Amazon SES избавляет от необходимости построения собственного дорогостоящего и сложного решения или лицензирования, установки и обслуживания готового решения. Новый сервис интегрируется с другими сервисами Amazon (AWS), упрощая отправку писем из приложений, работающих на таких платформах как Amazon EC2. С Amazon SES не нужно заключать долгосрочные договора и проводить согласования — просто наслаждайтесь низкими тарифами за количество отправленных писем + траффик.

В свое время работая в узком кругу программистов, отдельными задачами и даже проектам, мы не задумывались о проблемах связанными с текучкой кадров. Точнее думать — думали, но ни каких мер не применяли, да и в целом коллектив был сплоченный никто не уходил и никого «не уходили». С ростом внутренних проектов и корпоративных клиентов, штат начал разрастаться и казалось, что все отлично — нас больше, значит будем больше успевать и делать, но не тут то было. Мы начали тратить кучу времени на “бесполезные” обсуждения, проверки, излишние проектирование и т.д, больше всего раздражает — это проверка кода. И тут я начал думать, что “мудрые и древние” наверняка решали эти проблемы с сотнями, тысячами программистов, неужели мы не справимся? Я решил провести эксперимент, под названием “автоматизированная проверка стиля кода при комитах”. Для большинства из Вас это не новость и наверняка вы этим пользуетесь, но поделиться опытом внедрения думаю, не будет лишним.

Как известно, все люди делятся на два вида: те, кто ещё не делает бэкапы, и те, кто их уже делает. У тех, кто только начинает делать бэкапы, первым обычно встаёт вопрос о том, каким способом архивировать данные. Простые варианты (вручную нарезать болванки, целиком архивировать каталоги на другие серверы) рассматривать не будем — у них весьма скромные возможности по индексированию и поиску архивных файлов. Вместо этого обратимся к автоматическим системам бэкапов, в частности bacula. Данная статья не рассматривает вопрос, почему bacula. Главные причины — она распространяется под свободной лицензией, доступна для кучи платформ и обладает огромной гибкостью.

Второй вопрос после выбора системы архивации — выбор места, где хранить бэкапы. Bacula позволяет использовать стриммеры, компакт-диски, писать архивы в FIFO-устройства и в обычные файлы. Стриммер удобен на корпоративных серверах, где есть постоянный физический к железу. Хранение архивов в файлах подойдёт, когда объём архивов не превышает объёма жёстких дисков, плюс для надёжности хранения желательно делать RAID-массив с избыточностью, а то и несколько физических серверов для бэкапов, желательно в разных помещениях. Иначе всё это до первого пожара. Нарезать на болванки — это домашний вариант, главный недостаток которого — необходимость регулярного втыкания свежих дисков. Мы же настроили bacula для архивации данных на Amazon S3.

Спешу поделиться цветовой схемой Xoria256 для Midnight Commander, которую я сделал, взяв за основу одноимённую схему для редактора vim.

Для тех, кто не знает что такое Midnight Commander — это популярный двухпанельный файловый менеджер для UNIX систем (в т.ч. Linux и Mac OS X). Он работает в текстовом режиме, что делает его незаменимым для визуализации файловой системы и операций с файлами на удалённой UNIX-системе не загружая SSH-соединение.

Для использования схемы необходимо следующее:

В данном обзоре я расскажу о реализации кластера состоящего из двух нод с резервированием популярной связки для веб сервера Apache + MySQL + FreeBSD (или любой Linux).

Ежедневно десятки людей загораются идеей создать нечто своё, реализовать свой web-проект. В большинстве случаев все эти начинания ни к чему не приводят. Как не удивительно, основной причиной провала проекта служит отсутствие или недоработаность концепции.
В этой статье рассмотрены анализ успешности «зелёных» web-проектов, причины их провалов и методика написания концепции проекта. Статья рекомендуема для прочтения всем людям, решившим создать свой web-проект впервые.

На данный момент, порт VirtualBox на FreeBSD уже достаточно стабилен и вполне пригоден для постоянного использования. Но при установке на gui-less машинах возникает несколько проблем. Дальше речь пойдет об установке и использовании VirtualBox на FreeBSD машине без X11.

Эта статья о некоторых технических аспектах реализации бесплатного сервиса для загрузки, хранения и просмотра видео. Будут рассмотрены вопросы настройки серверного программного обеспечения, даны примеры команд для конвертации видео и примеры кода на языке PHP.

После запуска я получил много вопросов о том, как именно учитываются ресурсы в облаке. Некоторые интуитивно понимают, что такое «час процессорного времени» но есть и те, кто хочет подробного объяснения. Поскольку в общем анонсе подробные объяснения заняли бы много места, я вынес его в отдельный топик. Заодно, такой формат позволит более подробно описать, как Зен и виртуальные машины взаимодействуют. Уровень этого текста научно-популярный, то есть я не буду вдаваться в дебри кольцевых буферов, маскировки событий, «кредитного планировщика» и т.д., вместо этого я попробую рассказать относительно человеческим языком о том, как гипервизор управляет гостевыми машинами.


Что такое «процессорное время»? Сначала мы его хотели назвать более привычным «машинное время», благо, такой термин использовался во времена мейнфреймов, когда идея разделения машинного времени только-только зародилась, но вовремя остановились. Машинное время тех лет подразумевало все ресурсы, которые использовались машиной, а в нашем случае речь идёт именно о процессоре, так как каждый ограниченный ресурс учитывается раздельно.

Итак, что такое «процессорное время» и как может оказаться, что у одной виртуальной машины его насчитывается 4 часа в сутки, а у другой накручивает 30 «часов» за часов десять?

Облако Селектел работает под управлением Xen, точнее, Xen Cloud Platform, в котором гипервизором выступает Xen.

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

Как выглядит работа виртуальной машины?

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

Отсюда следует простой вывод — Ваши рекурсивные DNS сервера должны быть всегда доступны и в состоянии обслужить запросы клиента.

В прошлой заметке мы рассматривали некоторые аспекты тюнинга роутера под Linux, предназначенного для работы в условиях высоких нагрузок: Linux под нагрузкой. Маршрутизатор, NAT-сервер Теперь же речь пойдет о шейперах.

Допустим, вы развиваете какой-нибудь сайт в интернете. У вас есть постоянные пользователи, кто-то заходит к вам от случая к случаю. И вы конечно же ищете способы удержания аудитории на вашем сайте, придумывая всякие оригинальные функции и оттачивая до блеска интерфейс. Почему бы тогда не использовать имя вашего сайта в качестве экспортной монеты? Можно ведь предоставить вашим пользователям в качестве дополнительного бонуса почтовый адрес и соответствующий адрес Jabber в вашем домене.

Конечно, я не предлагаю становится очередным провайдером почты. Это глупо, когда есть такие игроки, как gmail.com и yandex.ru. Кроме того, вы естественно можете использоваться услуги вышеупомянутых Google и Yandex для подключения своего домена к их сервисам. Но тогда вы не получите никакой интеграции с вашей базой пользователей и никакого контроля над доступной функциональностью.

Но есть простой и элегантный способ прозрачно совместить почту и Jabber в вашем домене с профилями пользователей на сайте. У пользователя при этом везде будет единый логин и единый пароль и не будет необходимости в совершении никаких дополнительных действий для подключения почты и Jabber аккаунта. Просто дополнительный бонус, идущий в комплекте с регистрацией на вашем портале.

О чем речь

Доброго времени суток, %username%.

Сегодня я хотел бы рассказать как легко и ненавязчиво создать свой rpm-репозиторий, а так же заполнить его оптимизированными под ваш любимый дистрибутив пакетами. И так, для этого нам надо: дистрибутив любимый одна штука(в моём случае это VZшка с Centos 5.5), rpm-build, mock, createrepo. Все пакеты можно обнаружить в стандартных репозиториях centos.

Имею на администрировании несколько серверов, на которых хостятся восновном свои проекты, но кроме них ещё довольно много пришлось разместить левых сайтов — клиентов, знакомых, знакомых знакомых и т.п. За время администрирования встречались разные проблемы, поэтому настроены кое-какие мониторинги (zabbix и самописные скрипты).

И вот вчера на одном из серверов скрипт, проверяющий активные соединения, забил тревогу: постоянно висит исходящее соединение на неизвестный хост на порт 433, уже более 9 часов на момент когда я осилил прочитать почту в понедельник утром ;)

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

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

Я оказываю услуги по настройке web- и БД-серверов. На днях ко мне обратился Иван Усачёв — владелец портала ochevidets.ru с просьбой избавить сайт от торможения.

Страницы в пиковое время стали долго загружаться, вплоть до 5 минут на страницу.

UPDATE: Статья была написана в 2010 году. Кое-что изменилось: вышли новые версии программ, у nginx изменились некоторые директивы и появились новые. Учитывайте это.

В этой статье будут описаны различные настройки MySQL, преимущественно те, которые влияют на производительность. Для удобства все переменные разделены по разделам (базовые настройки, ограничения, настройки потоки, кэширование запросов, тайминги, буферы, InnoDB). Сначала уточним имена некоторых переменных, которые изменились в версии 4 MySQL, а в сети продолжают встречаться и старые и новые варианты имен, что вызывает вопросы.