Как это работает? Дело в том, что спам рассылается специальным программным обеспечением, которое ведет себя так же как обычный почтовый сервер, но с некоторыми особенностями. Оно перебирает почтовые сервера и пытается отправить нежелательную корреспонденцию на известные ему адреса. Если почтовый сервер, к которому обращается программа рассылки, сообщает о временной ошибке, то она просто пропускает его и продолжает рассылку дальше. Объемы рассылаемой спамерами почты огромны, а ошибки в доставке таких писем возникают постоянно, поэтому этими ошибками обычно пренебрегают. Нормальный же почтовый сервер всегда пытается повторно доставить письмо, если он получил сообщение о временной ошибке. Суть грейлистинга заключается в том, что при первой попытке отправить почту на определенный адрес сервер сообщает о временной проблеме и заносит данные о сервере отправителе и письме в свою базу данных. Если сервер повторил попытку отправить через некоторое время, то его письмо уже будет принято, а адрес сервера попадет на определенный период в белый список. Почта с серверов из белого списка принимается без задержки. В отличие от честного SMTP сервера, программа, рассылающая спам, обычно не будет предпринимать попыток повторной отправки письма, если при первой попытке возникла ошибка. Таким образом адреса, с которых идет рассылка спама не будут попадать в белый список и эта нежелательная корреспонденция не будет доставлена ее предположительному адресату. Практика показывает, что грейлистинг является на данный момент очень эффективным средством борьбы со спамом и позволяет решить эту проблему почти на сто процентов.
Ну а теперь ложка дегтя. Основным недостатком такого подхода являются задержки в доставке почты, причем задержки эти по сути никак не регулируются на стороне принимающего сервера, где используется грейлистинг. Дело в том, что отправляющий сервер будет предпринимать повторную попытку отправки после определенного таймаута, который определяется его настройками. Например, в случае нашей почты, для попадания в белый список достаточно повторить попытку через 10 минут, но сервер может сделать это и через час. Конечно, после попадания в белый список, задержка пропадает, но при доставке первых писем она всегда будет проявляться. К сожалению с нашей стороны мы не можем повлиять на величину этой задержки, как уже было сказано выше, она полностью зависит от администрации других серверов электронной почты.
Удобно это или нет — решать вам, в любом случае вы можете включить грейлистинг отдельно для любого из ваших адресов электронной почты, расположенных на наших серверах. Стоит так же заметить, что если код вашего проекта будет отправлять почту на ваши адреса, например, какие-нибудь уведомления о регистрации посетителей или иных событиях, то эти сообщения будут доходить без задержки, так как грейлистинг касается только той почты, что приходит от внешних серверов.
По умолчанию грейлистинг выключен, включить его вы можете в подробных настройках учетной записи в разделе «ПОЧТА» вашей панели управления.

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

Хостинговые технологии не должны отставать от технологий создания web-проектов. Необходимо обеспечивать работоспособность широкого спектра фреймворков, написанных на очень разных языках: от традиционного PHP до нетривиального Lisp.

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

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

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

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

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

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

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

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

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

С каждым днем отрасль IT бурно прогрессирует и новые технологии растут как грибы после дождя. С одной стороны, такие темпы радуют, но с другой — создают достаточно много сложностей. Хостерам (мы же все живые люди!) за динамикой развития технологий уследить также непросто. Отсюда и возникают проблемы при выполнении важнейшей задачи для любой хостинговой компании — как предоставить клиентам возможность использовать самые передовые IT-достижения, при этом не нарушив работу старых проектов? Ведь, с одной стороны, нельзя отставать от прогресса и конкурентов, а с другой — хочется стабильности и проверенных временем решений.

В таких ситуациях часто приходится балансировать на грани, к тому же разработчики языков программирования, фреймворков и серверов приложений иногда недостаточно заботятся об обратной совместимости своих продуктов.  Это сильно усложняет работу хостеров. Посудите сами: код, написанный под php 4, вовсе не обязательно будет стабильно работать с пятой версией этого популярного языка, с ruby 1.9 будет работать rails, но половина популярных gem-ов — не будет.

Многим IT-специалистам известен золотой принцип: «Работает — не трогай!». Он действительно помогает избежать лишних проблем, но, к сожалению, не универсален. С таким подходом легко превратиться в этакого IT-ретрограда, ведь на современном рынке хостинга можно и сейчас встретить серверы под управлением FreeBSD 4.11 (вышедшей еще в 2005 году), на которых предоставляется хостинг с php 4 и mysql четвертой ветки. В такой ситуации и сотрудники хостинговой компании, и их клиенты не могут использовать множество новых возможностей, появившихся в последующих версиях операционной системы и прочего программного обеспечения. В итоге хостер имеет стабильность ради стабильности, пожертвовав ради нее как своим удобством, так и новыми клиентами, которые хотят пользоваться всеми современными технологиями.
Постоянное обновление до последних версий в день их появления на свет тоже не будет разумным решением. Ведь помимо очевидных проблем с безопасностью и стабильностью это может привести к ситуации, когда у половины клиентов перестанут работать их проекты (просто потому, что разработчики не очень хорошо подумали о вопросах обратной совместимости, или были сделаны слишком принципиальные изменения, и добиться совместимости со старым кодом не представлялось возможным).
Таким образом, хороший хостер вынужден постоянно балансировать на грани между ретроградством и переднем краем разработок, изучать вопрос совместимости старого кода с новыми версиями языков и платформ, выделять новые сервера для запуска новых решений, а потом тестировать все это для выявления проблем с безопасностью и стабильностью работы.

Прежде чем внедрить какую-либо новую технологию в проект LOCUM, мы тщательно изучаем опыт других специалистов, чтобы убедиться в готовности данного решения для практического использования. Затем тестируем его на некотором количестве размещаемых у нас ресурсов, чтобы выявить очевидные проблемы с совместимостью старого кода. И уже только после этого предлагаем нашим клиентам использовать новинку. Если у кого-то после перехода на нее возникают проблемы, мы всегда готовы дать советы по запуску проекта под новой версией или предложить вариант с возможностью сохранения старой версии языка, фреймворка или сопутствующего программного обеспечения. Конечно, этот путь намного хлопотнее, чем просто не трогать то, что уже работает. Но  топтаться на месте — занятие бесполезное и скучное. А нам и нашим клиентам нужны широкие перспективы.

Для создания работоспособного виртуального хостинга, который мог бы предоставлять клиентам возможность размещать Django-проекты, мы изучили три основных способа их размещения: с использованием mod_python web-сервера Apache2, FastCGI и mod_wsgi.

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

Установка и настройка:

Чем привлекает FastCGI? Он прост в настройке, принципы работы с ним хорошо известны и его внедрение не представляет никаких сложностей. Для нормальной работы django-приложения достаточно правильным образом сконфигурировать VirtualHost web-сервера Apache2 и написать простой сценарий запуска для FastCGI:

  #user defined
  ServerAdmin admin@django-test.locum.ru
  ServerName django-test.locum.ru
  #end
  DocumentRoot "/home/versus/projects/django-test.locum.ru"
  SuexecUserGroup versus customers
  AddType fastcgi-script .fcgi
  Alias /media/ /home/versus/projects/django-test.locum.ru/media/
  ScriptAlias / /home/versus/projects/django-test.locum.ru/django.fcgi/ 

  CustomLog "/var/log/apache2/django-test.locum.ru.custom.log" combined
  ErrorLog "/var/log/apache2/django-test.locum.ru.error.log"

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

#!/usr/bin/python
import os
import sys
from flup.server.fcgi import WSGIServer
from django.core.handlers.wsgi import WSGIHandler 

sys.path.insert(0, '/home/versus/projects/django-test.locum.ru/app/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' 

WSGIServer(WSGIHandler()).run()

Основным преимуществом FastCGI является, пожалуй, возможность устанавливать переменные Django прямо в файле конфигурации Apache. Теоретически это дает возможность иметь один на всех сценарий запуска проекта. Кроме того, изменения в любом файле проекта сразу же становятся видны: какое-либо кеширование отсутствует.
Процедура запуска WSGI во многом идентична FastCGI: в систему необходимо установить соответствующий пакет с mod_wsgi и так же, как и в предыдущем случае, создать необходимые конфигурационные файлы.

  #user defined
  ServerAdmin admin@django-test.locum.ru
  ServerName django-test2.locum.ru
  #end 

  DocumentRoot "/home/versus/projects/django-test2.locum.ru"
  Alias /media/ /home/versus/projects/django-test2.locum.ru/media/ 

  WSGIDaemonProcess django-test2 user=versus group=customers threads=2
  WSGIProcessGroup django-test2 

  WSGIScriptAlias / /home/versus/projects/django-test2.locum.ru/django.wsgi 

  CustomLog "/var/log/apache2/django-test.locum.ru.custom.log" combined
  ErrorLog "/var/log/apache2/django-test.locum.ru.error.log"

Каталог, содержащий статические документы, обрабатывается непосредственно web-сервером.

#!/usr/bin/python
import os
import sys 

sys.path.insert(0, '/home/versus/projects/django-test2.locum.ru/app/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' 

import django.core.handlers.wsgi 

application = django.core.handlers.wsgi.WSGIHandler()

В этой ситуации все необходимые переменные необходимо устанавливать уже в файле сценария запуска, поэтому придется создавать отдельные файлы для каждого django-проекта. С одной стороны, это не очень хорошо — появляется дублирование и возможны проблемы с неправильной конфигурацией. С другой стороны, такой подход дает большую гибкость.
WSGI кеширует модули python, поэтому изменения в проекте вступают в силу не сразу, а только либо после перезагрузки web-сервера (что недопустимо в коммерческой эксплуатации), либо при изменении timestamp конфигурационного файла.

Тестируем производительность

Так какой же способ быстрее? Для ответа на этот вопрос мы взяли стандартное django-приложение, которое отображает всего одну страничку текста и картинку.

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

#!/bin/bash 

for i in `seq 1 1000`; do
	wget -O /dev/null "http://django-test2.locum.ru/" > /dev/null 2> /dev/null
done

В процессе выполнения при помощи системной утилиты time замерялось время, необходимое для загрузки всех 1000 запросов. Сценарий выполнялся на локальной машине, чтобы избежать возможных накладок сети. И вот какие результаты мы получили:

Разница получилась больше, чем в 20 раз! После этого эксперимента мы однозначно выбрали mod_wsgi в качестве сервера для django-проектов. Конечно, пришлось учесть особенности такого подхода: в любой момент прямо с панели управления хостингом можно отдать команду на перезапуск сервера (touch для сценария запуска) и восстановить содержимое индивидуального сценария по умолчанию на тот случай, если пользователь случайно что-то неправильно написал.