2009-05-24

Введение в nginx, часть 2: Другие возможности

Данная статья была опубликована в электронном приложением к журналу "Системный администратор"- "Open Source #042"

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

Failover и балансировка

Крупные проекты редко состоят из одного сервера приложений. Часто их два или больше, и возникает задача балансировки клиентов по этим серверам, а также выполнения failover — необходимо чтобы выход из строя одного из серверов не был заметен для клиентов.
Простейший способ рещить эту задачу — dns round-robin, т.е. назначение доменному имени нескольких ip-адресов. Но это решение имеет ряд недостатков, и гораздо лучше выглядит решение балансировки запросов по бакендам на фронтенде nginx. В конфигурационном файле выглядит это примерно так:

# объявляем upstream — список бакендов
upstream  backend  {
  # перечисляем dns-имена или ip-адреса серверов и их «вес»
  server   web1                 weight=5;
  server   1.2.3.4:8080         weight=5;
  # а так можно подключаться к бакенду через unix-сокет
  server   unix:/tmp/backend3   weight=1;
}
# конфигурация виртуального сервера
server {
  listen <...>;
  server_name myserver.com;
  # отправляем все запросы из локейшена / в апстрим
  location / {
    proxy_pass  http://backend;
  }
}

Запросы, приходящие к nginx, распределяются по бакендам соответственно указаному весу. Кроме того, можно сделать так, чтобы запросы с одних и тех же IP-адресов отправлялись на одни и те же серверы (для этого в upstream нужно указать директиву ip_hash). Так можно решить проблему с сессиями, но все же лучше найти какой-нибудь способ их репликации или (что еще лучше) использовать RESTful-подход.
В случае, если один из серверов откажется принимать соединения или соединение к нему отвалится по таймауту, он на некоторое время будет исключен из upstream.

2009-04-24

Введение в nginx, часть 1

Данная статья была опубликована в электронном приложением к журналу "Системный администратор"- "Open Source #041 (27.03.2009)"

Введение


nginx (engine x) — это HTTP-сервер и IMAP/POP3 прокси-сервер для UNIX-подобных платформ (FreeBSD и GNU/Linux). Nginx начал разрабатываться Игорем Сысоевым, сотрудником компании Рамблер весной 2002 года, а осенью 2004 года появился первый публично доступный релиз. Он, как и все последующие, распространяется под лицензией BSD.
На данный момент nginx работает на большом количестве высоконагруженных сайтов (среди них — Рамблер, Яндекс, В Контакте, wordpress.com, Wrike и другие). Текущая версия, 0.6.x, рассматривается как стабильная с точки зрения надежности, а релизы из ветки 0.7 считаются нестабильными. При этом важно заметить, что функциональность некоторых модулей будет меняться, вследствие чего могут меняться и директивы, поэтому обратной совместимости в nginx до версии 1.0.0 не гарантируется.

Чем же nginx так хорош и почему его так любят администраторы высоконагруженных проектов? Почему бы просто не использовать Apache?

2009-03-30

GNUnet: свободный и анонимный обмен файлами

Общий обзор проекта.

Автор: Vladimir Rusinov, Murano Software
Для конкурса статей проекта opennet.

Введение



GNUnet - это программный пакет для безопасного peer-to-peer соединения, не нуждающегося в серверах. Проект GNUnet возник в 2001 году и был вдохновлён целым рядом технических идей, призванных обеспечить безопасный файлообмен в пиринговых (P2P) сетях.

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

Основные технические вопросы работы GNUnet подробно описаны в ряде научных публикаций. Среди этих идей — улучшенное кодирование содержимого (ECRS) и новый протокол анонимной маршрутизации (gap). Вы можете найти все материалы на сайте gnunet. Когда началась работа над GNUnet, были изучены существующие системы (в частности, Freenet и Mnet) на основе которых можно было бы начать новую работу. Однако задуманная система слишком отличалась от существовавших реализаций, чтобы строить GNUnet на основе одной из существовавших систем.

Первый реализованный сервис позволяет обмениваться файлами (анонимно и без какой либо цензуры). Анонимность обеспечивается за счет того, что исходящие от узла сети сообщения неотличимы от чужих сообщений, в передаче которых участвует узел. Все узлы действуют как маршрутизаторы, установленные между ними соединения шифруются, а уровень использования пропускной способности канала поддерживается постоянным. GNUnet использует простую, основанную на избытках экономическую модель для выделения ресурсов. Узлы в GNUnet следят за поведением друг друга, с уважением к использованию ресурсов; узлы, которые больше дают сети награждаются лучшим обслуживанием.

GNUnet продолжает развиваться: появляются новые идеи и улучшается программный код. Часто улучшения GNUnet являются результатом дискуссий с разработчиками других проектов. Наверное, один из наиболее известных таких проектов — это Tor — децентрализованная сеть, действующая как анонимный прокси для TCP трафика с низкой латентностью. Tor спроектирован как универсальное решение, и в нем отсутствуют некоторые возможности специфичные для анонимного файлообмена, например поиск, дублирование данных, параллельная загрузка с нескольких узлов.

Кроме всего прочего, впечатляет список протоколов, которые может использовать GNUnet для передачи. Это стандартные tcp и udp, и необычные для p2p http (причем может работать и через прокси) и smtp. Ко всему прочему GNUnet вполне хорошо работает за NAT.

GNUnet является частью проекта GNU. Страница проекта на сайте gnu имеет адрес http://www.gnu.org/software/gnunet/. Кроме того, существует отдельный сайт gnunet: http://gnunet.org/.

Текущая версия 0.8.0c написана на С (однако существует проект реализации GNUnet на Java), работает под ОС GNU/Linux, *BSD, Mac OS X, Solaris, Windows и распространяется под лицензией GNU GPL. В данный момент в проект входит демон gnunetd, несколько библиотек и два фронтенда: gnunet-gtk и gnunet-qt (соответственно написанные с использованием GTK и Qt).

2009-03-14

Нужно ли переходить с MyISAM на Innodb?

Автор: Peter, Percona
Перевод: Vladimir Rusinov

Существует значительная часть проектов, которые используют MyISAM и задаются вопросом, стоит ли им перейти на InnoDB, или же лучше продолжить использовать MyISAM?

Я предпочитаю Innodb в качестве основного движка, потому что для большинства пользователей это делает жизнь намного проще - не приходится беспокоиться о восстановлении таблиц после сбоя, таблицы не блокируются целиком, "горячие" бекапы делать гораздо проще, но есть несколько вещей о которых нужно подумать перед принятием решения о переходе.

MyISAM используется по умолчанию, или это был осмысленный выбор? Это самый главный вопрос. Иногда MyISAM используется только потому что он выбран по умолчанию. В других случаях это намеренный выбор для системы, которая учитывает ограничения MyISAM. В таком случае должен быть хороший аргумент для перехода на Innodb.

2009-03-08

Denyhosts - блокировка перебора паролей ssh

Denyhosts - весьма полезная утилита для пресечения попыток подобрать пароль к ssh.

Устанавливается без каких-либо проблем: emerge denyhosts в Gentoo, для других дистрибутивов пакеты также существуют и как правило находятся в основном репозитории.

Denyhosts работает следующим образом: он проверяет логи и добавляет в /etc/hosts.deny ip адреса, с которых наблюдается много попыток неудачного входа. Для того чтобы это работало, ssh должен быть собран с tcpwrappers (что всегда разумно и делается по умолчанию).

У denyhosts достаточно гибкие настройки, можно указать после скольких неудачных попыток блокировать хост, на какой период это делать и т.п. Настойки по умолчанию на мой взгляд черезчур суровы, поэтому имеет смысл отредактировать файл /etc/denyhosts.conf, который весьма прост для понимания и имеет подробные комментарии.

Есть два способа запустить denyhosts: в качестве демона или в качестве cron-задания. Памяти он потребляет немного, поэтому проще первое:
/etc/init.d/denyhosts start
rc-upade add denyhosts default

2009-03-06

Скрипт для проверки состояния рейд-массива для 3ware

Недавно возникла задача периодический проверки статуса raid'а в контроллере 3ware. Решается следующим образом:

1. Качаем утилитку 3ware cli: http://www.3ware.com/download/Escalade9500SSeries/9.3.0.4/tw_cli-linux-x86_64-9.3.0.4.tgz (замените x86_64 на x86 если у вас 32-битная архитектура).

2. Распаковываем ее куда-нибудь.



3. Пишем скриптик и помещаем его в /etc/cron.daily/ (или по желанию в cron.hourly):

#!/bin/bash
com=`/opt/3ware/tw_cli info c0 u0 status | awk '{print $4}'`
if [ "$com" != "OK" ];
then
        /opt/3ware/tw_cli info c0 u0 status | mail -s "RAID WARNING" root@e.mail
fi

2009-02-10

Оптимизация производительности Apache

Введение


По данным Netcraft, Apache - самый популярный веб-сервер в интернет, он обслуживает множество серверов и сайтов. Часто возникает необходимость увеличить производительность веб-сервера. Наверное лучший способ это сделать - перейти к схеме frontend+backend, но это может потребовать достаточно серьезных изменений в приложении (например, у вас наверняка отвалятся всяческие индикаторы прогресса аплоада файлов).

Другой способ - просто увеличить производительность сервера - поставить более быстрый процессор и больше памяти.

Однако и первое и второе требует много времени и ресурсов, так что на первое время можно попробовать ускорить apache путем оптимизации его конфигурации. Существуют оптимизации, которые можно применить только при пересборке apache, другие же можно применять без перекомпиляции сервера.

Загружайте только необходимые модули


Apache - модульная программа, бОльшая часть функций которой реализуется в модулях. При этом эти модули могут быть как вкомпилированы, так и собраны в виде DSO - динамических библиотеках. Большинство современных дистрибутивов поставляет apache с набором DSO, так что не нужные модули можно легко отключить без перекомпиляции.

Запускайте apache только с необходимыми модулями, чтобы уменьшить потребление памяти. Если вы решили скомпилировать apache самостоятельно, то либо тщательно подходите к выбору списка модулей, которые вы включите, либо компилируйте их как DSO используя apxs в apache1 и apxs2 в apache2. Для того чтобы отключить ненужные DSO-модули, достаточно закомментировать лишние строчки LoadModule в httpd.conf. Apache со статически скомпилированными модулями будет потреблять чуть меньше памяти, однако вам придется каждый раз его перекомпилировать для изменения списка модулей.

2009-02-02

Как определить оптимальный размер innodb_log_file_size

Как известно, при коммите InnoDB записывает данные не сразу в файлы данных, а сначала записывает изменения в innodb_log_file. Дело в том что записать данные непосредственно в таблицу - существенно более дорогая операция, чем записать изменения в бинарный лог.
Ведение innodb_log_file позволяет проводить оптимизацию i/o: записывать данные большими последовательными кусками, а также более быстрее обслуживать клиентов (клиент быстро сделал коммит, а данные в табличное пространство записываются в фоне). Поэтому чем больше файл, тем больше возможности для InnoDB оптимизировать ввод/вывод. В настоящее время суммарный размер innodb_log_file ограничен 4 Гб, что более чем достаточно для большинства случаев.
При старте после неожиданного отключения MySQL просматривает innodb_log_file, откатывая транзакции, которые не успели завершиться перед крахом и отмечая коммиты, которые успели (и были полностью записаны в innodb_log_file). И естественно, чем больше файл, тем больше времени требуется серверу чтобы просмотреть его.
Как же определить наиболее оптимальный размер?