Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux,Nginx,PHP-FPM(+APC),MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx:

на соединения

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 100;

и скорость запросов на динамику (fastcgi_pass на php-fpm)

limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s;
limit_req zone=dynamic burst=10 nodelay;

Сильно полегчало, по логам видно, что в первую зону никто не попадает, зато вторая отрабатывает по полной.

Но плохиши продолжали долбить, и захотелось их отбрасывать раньше — на уровне фаервола, и надолго.

Сначала сам парсил логи, и особо настырных добавлял через iptables в баню. Потом парсил уже по крону каждые 5 минут. Пробовал fail2ban. Когда понял, что плохишей стало очень много, перенёс их в ipset ip hash.

Почти всё хорошо стало, но есть неприятные моменты:
— парсинг/сортировка логов тоже приличное (процессорное) время отнимает
— сервер тупит, если началась новая волна между соседними разборками (логов)

Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм.

При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться!

Для каждого location создаём свою страничку с ошибкой

error_page 503 =429 @blacklist;

И соответствующий именованный location

location @blacklist {
    fastcgi_pass    localhost:1234;
    fastcgi_param   SCRIPT_FILENAME    /data/web/cgi/blacklist.sh;
    include         fastcgi_params;
}

Дальше интересней.
Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd.

Сам CGI-скрипт

Приветствую, уважаемые хабрачитатели.

Предлагаю Вашему вниманию свою небольшую наработку, которая, по моему мнению, может облегчить жизнь администраторам операционных систем «породы» UNIX. Мне, как администратору Unix серверов, часто приходится предоставлять некую информацию по множеству серверов архитектурному комитету, по этому пришла идея написания «всего этого безобразия».

Смысл работы скрипта — выдача всей (ну почти всей) информации о сервере, работающем на Linux или AIX (других ОС семейства UNIX под рукой нет, но я над этим работаю).

Автор: Piotr Siwczak

Когда я разрабатывал свою первую инфраструктуру OpenStack, я с трудом находил информацию о том, как следует распределять многочисленные ее компоненты по оборудованию. Я изучил множество документов, в том числе справочник по архитектуре Rackspace (который ранее был размещен по ссылке referencearchitecture.org, но сейчас, похоже, эта ссылка устарела). Я также просмотрел проектные схемы в документации OpenStack. Должен признать, что тогда у меня были только базовые знания о том, как взаимодействуют компоненты, поэтому я остановился на достаточно простой схеме: один “управляющий узел”, который включал все компоненты, в том числе API-сервисы, nova-scheduler, Glance, Keystone, базу данных и RabbitMQ. Под управление узла я поместил ферму “рабочих лошадок” — вычислительных узлов. Я также организовал три сети: частную (для трафика с фиксированным IP-адресом и управления серверами), общедоступную (для трафика с динамическим IP-адресом) и для хранения (для трафика по протоколу iSCSI сервиса nova-volume).

Когда я начал работать в Mirantis, я значительно изменил свой подход. Я понял, что все мои идеи по созданию фермы выделенных вычислительных узлов с одним или двумя управляющими узлами, были неверными. С одной стороны, мой подход был хорош в плане разделения компонентов, но на практике мы можем с легкостью смешивать и компоновать рабочие компоненты без перегрузки OpenStack (например, сервис nova-compute с сервисом nova-scheduler на одном узле). Оказывается в OpenStack “управляющий узел” и “вычислительный узел” могут иметь разные значения в зависимости от того, как гибко распределены компоненты OpenStack.

В общем, можно предположить, что в каждой установке OpenStack должны быть как минимум три типа узлов (и, возможно, четвертый), которые описал мой коллега Олег Гельбух:

В поисках решения для построения HA кластера на linux, я наткнулся на довольно интересный продукт, который, по моим наблюдениям, несправедливо обделен вниманием уважаемого сообщества. Судя по русскоязычным статьям, при необходимости организации отказоустойчивости на уровне сервисов, более популярно использование heartbeat и pacemaker. Ни первое, ни второе решение у нас в компании не прижилось, уж не знаю почему. Может сыграла роль сложность конфигурации и использования, низкая стабильность, отсутствие подробной и обновляемой документации, поддержки.

После очередного обновления centos, мы обнаружили, что разработчик pacemaker перестал поддерживать репозиторий для данной ОС, а в официальных репозиториях была сборка, подразумевающая совершенно другую конфигурацию (cman вместо corosync). Переконфигурировать pacemaker желания уже не было, и мы стали искать другое решение. На каком-то из англоязычных форумов, я прочел про Red Hat Cluster Suite, мы решили его попробовать.

Общая информация

RHCS состоит из нескольких основных компонентов:

• cman — отвечает за кластеризацию, взаимодействие между нодами, кворум. По сути, он и собирает кластер.
• rgmanager — менеджер ресурсов кластера, занимается добавлением, мониторингом, управлением групп ресурсов кластера.
• ricci — демон для удаленного управления кластером
• luci — красивый веб интерфейс, который подключается к ricci на всех нодах и предоставляет централизованное управление через веб-интерфейс.

Как и в heartbeat и pacemaker, ресурсы кластера управляются стандартизированными скриптами (resource agents, RA). Кардинальное отличие от pacemaker состоит в том, что redhat не подразумевает добавления пользовательских кастомных RA в систему. Но это с лихвой компенсируется тем, что есть универсальный resource agent для добавления обычных init скриптов, он называется script.

Управление ресурсами идет только на уровне групп сервисов. Сам по себе ресурс невозможно включить или выключить. Для распределения ресурсов по нодам и приоритезации запуска на определенных нодах используются failover domains, домен представляет собой правила запуска групп ресурсов на определенных нодах, приоритезацию и failback. Одну группу ресурсов можно привязать к одному домену.

Доброго времени суток, уважаемое сообщество.
Решил поделиться небольшой идеей, возможно кому-то будет интересно и полезно.

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

25 апреля в Санкт-Петербурге, при поддержке портала Айти-Событие.рф, состоится High Performance Conference #4 — конференция по высоким нагрузкам.


Цель конференции — дать возможность профессионального роста в различных сферах проектирования, разработки, тестирования, администрирования и поддержки высоконагруженных систем её участникам.

Добрый день, в своей статье, хочу рассказать, всем известную практику разработки ПО — Continuous Integration или Непрерывная интеграция.
Чтобы сразу пояснить в чем особенность статьи объясню, что в нашей команде стояла задача построить единый процесс для всех наших проектов. А проекты у нас бывают как мобильные (iOS, Android) и веб (верстка, сервисы, сайты).

Что такое NAXSI ?

NAXSI = NGINX ANTI XSS & SQL INJECTION
Проще говоря, это файрвол веб-приложений (WAF) для NGINX, помогающий в защите от XSS, SQL-инъекций, CSRF, Local & Remote file inclusions.
Отличительными особенностями его являются быстрота работы и простота настройки. Это делает его хорошей альтернативой например mod_security и апачу.

Зачем нужен NAXSI ?

Очевидно, лучше всего защищаться от вышеперечисленных атак правильно написанным кодом. Но есть ситуации, когда WAF (и в частности naxsi), поможет:

• Низкое качество кода сайта, при отсутствии возможности/ресурсов все выкинуть и переписать нормально.
• “Закрытый” код, в котором невозможно исправить ошибки.
• Неизвестное качество кода в важном для бизнеса участке.

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

Большинство приложений в интернете сейчас начинает встраивать карты местности.
Работе с картами, используя Google Map API, посвящена данная статья.

Есть несколько идентичных серверов (4 ноды) на Amazon EC2 с Ubuntu. Каждый генерирует и хранит у себя на диске кэш, который хотелось бы синхронизировать. Но простой rsync тут не подойдет — файлов несколько миллиардов, nfs — слишком медлителен, и т. д. Полный список рассмотренных вариантов с пояснениями ниже.

К тому же, время от времени нужно удалять устаревшие файлы сразу на всех серверах, что пока делается вручную и занимает несколько суток. Вопрос наиболее быстрой для такого Use Case файловой системы планирую описать позже. Оговорюсь только, что по нескольким причинам была выбрана XFS.

После теста нескольких кластерных технологий и файловых систем, по совету старшего товарища, решили использовать тот же rsync, но в связке с inotify. Немного поискав в интернете готовое такое решение, дабы не изобретать велосипед, наткнулся на csyncd, inosync и lsyncd. На хабре уже была статья о csyncd, но он тут не подходит, т.к. хранит список файлов в базе SQLite, которая вряд-ли сможет сносно работать даже с миллионом записей. Да и лишнее звено при таких объемах ни к чему. А вот lsyncd оказался именно тем, что нам и было нужно.

UPD: Как показала практика, необходимо ощутимое измение и дополние в тексте. Я решил внести лишь незначительные правки в основную часть, а новыми выводами поделиться в конце статьи.

Предыстория: моя жена постоянно норовит как-нибудь мне напортачить: поставить будильник на 3 часа ночи, поменять мелодию звонка, снести настройки синхронизации, удалить свою смс и потом доказывать, что она этого не говорила.
Шутки шутками, но в какой-то момент я решил: “Довольно!” — и поставил графический пароль на свой андроид.



Жена усмехнулась и сказала, что подберёт. Я посмеялся в ответ, на том и разошлись. Только теперь её волновал вопрос, как подобрать, а меня какова вероятность этого события.

Мне поступила задача организовать отказоустойчивость веб-приложения из двух серверов. Веб-приложение включает в себя статические файлы и данные в СУБД MySQL.
Основное требование заказчика — веб-приложение должно быть всегда доступно и в случае сбоя в течении 5 минут сбой должен быть восстановлен.
2 сервера, территориально разнесенные в разных ЦОДах, должны удовлетворить данное требование.

Базы данных иногда пропадают. Человеческий фактор и всё-такое… Если вы не делали бекапов (а надо бы) или они уже устарели, не отчаивайтесь, — есть ещё возможность восстановить утерянную информацию.

Недавно я наткнулся на топик "Сервер онлайн-вещаний на базе nginx" о замечательном модуле Романа Арутюняна (@rarutyunyan) для nginx: nginx-rtmp-module. Модуль очень прост в настройке и позволяет на основе nginx создать сервер публикации видеозаписей и живого вещания.

Про сам модуль можно прочитать на его странице на GitHub, я же хочу привести несколько простых примеров использования. Надеюсь, топик поможет новичкам в видеоделах (таким как я).

От переводчика

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

Начав выкладывать на хабре некоторые свои статьи и переводы, касающиеся тематики мониторинга ИТ-инфраструктуры, мне опять пришлось столкнуться с очень узким и техническим пониманием этой темы, которое у меня уже когда-то было и поэтому у меня однажды возникла идея изложить это системно. Я даже начал, не торопясь, писать статью на эту тему, но интуитивно понятные вещи не очень хорошо ложились на бумагу – за деревьями не получалось леса. Конечно, у нас у всех есть Google и возможность подсмотреть что пишут другие авторы, но не тут-то было. Бесчисленные статьи и заметки в блогах были посвящены техническим аспектам взгромождения очередной системы мониторинга на очередную версию операционной системы и связанное с этим героическое преодоление трудностей. Cтатей по методологии мониторинга, принципами выбора метрик, правильного построения процесса и увязывания его с бизнесом было очень мало и они также описывали некоторые частные случаи применения мониторинга для решения той или иной проблемы и не более того. А потом мне случайно попалась в руки совсем небольшая книга Дона Джонса «Создание унифицированной системы ИТ-мониторинга в вашем окружении (ENG)».

Продолжаем перевод. В этой главе разговор пойдёт о организации сервис-деска и способах построения взаимодействий с пользователями, а также получении от них обратной связи. Увидим почему 'хорошо' с точки зрения ИТ, не всегда означает 'хорошо' с точки зрения пользователя и как можно уравновесить эти две оценки.

Как обещал в прошлой статье, сегодня напишу как настроить файловый сервер на базе Samba 3 для пользователей домена Active Directory.
В чём отличие данной инструкции от, например, этой? Мы сегодня не будем использовать winbind. Наш kerberos клиент будет работать с kdc своего сайта AD и нам не потребуется заботится о его перенастройке при смене сайта.

Предполагается, что перед выполнением описанных действий Linux сервер введён в домен как было описано ранее.

Компания DotCloud разработала и выложила в открытый доступ систему Docker — высокоуровневые интерфейсы для доступа к Linux-контейнерам (LXC). Это идеальный инструмент для работы с контейнерами на любом сервере x64, для развёртывания крупномасштабных веб-инсталляций, кластеров БД, частных PaaS и т.д.

LXC — система виртуализации на уровне операционной системы для запуска нескольких изолированных экземпляров Linux на одном компьютере. LXC не использует виртуальные машины, а создаёт виртуальное окружение с собственным пространством процессов и сетевым стеком. Все экземпляры LXC используют один экземпляр ядра ОС.

Ключевые особенности Docker

• Изоляция файловой системы: каждый контейнер процесса работает полностью отдельной корневой файловой системе
• Изоляция ресурсов: системные ресурсы, как CPU и память, можно выделять по-разному для каждого контейнера процесса, используя cgroups
• Сетевая изоляция: каждый контейнер процесса работает в своём собственном пространстве имён, с виртуальным интерфейсом и собственным IP-адресом

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

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

Хочу сказать большое спасибо всем, кто оставлял комментарии в прошлой статье (и оставит в этой) — все ваши дельные советы будут включены в этот или последующий мануалы.