ХостингНевидимая архитектура

Superблог LOCUM: Невидимая архитектура

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

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

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

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

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

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

  1. […] Думаю из описания примерно понятно как организована работа, так же об этому у нас была статья в блоге: Невидимая архитектура. […]