Платформа

• Linux — операционная система
• Python — язык программирования
• Django — основной framework
• Apache 2.2 + mod_wsgi — веб-сервер
• PostgreSQL — СУБД
• memcached — кэширование
• HAProxy — балансировка нагрузки
• Slony — репликация данных
• heartbeat — обеспечение доступности

Статистика

• До 17 тысяч запросов в секунду
• 500 000 сайтов
• 15 миллионов зарегистрированных пользователей
• 75 миллионов комментариев
• 250 миллионов посетителей (на август 2010г.)

Основные трудности

• Непредсказуемость нагрузки (основными причинами шумихи в Интернете являются катастрофы и выходки знаменитостей)
• Обсуждения никогда не теряют актуальность (нельзя держать в кэше все дискуссии с 2008 года)
• Нельзя угадать на каком сайте из тысяч возникнет пик трафика
• Персональные настройки, динамическое разбиение на страницы и сортировки снижают эффективность кэширования
• Высокая доступность (из-за разнообразия сайтов и их аудитории сложно запланировать технические работы)

Архитектура

Архитектура DISQUS

• Оборудование, в сумме около 100 серверов:
  • 30% веб-серверов (Apache + mod_wsgi)
  • 10% серверов баз данных (PostgreSQL)
  • 25% кэш-серверов (memcached)
  • 20% балансировка нагрузки и обеспечение доступности (HAProxy + heartbeat)
  • 15% прочие сервера (Python скрипты)
• Балансировка нагрузки:
  • HAProxy:
    • Высокая производительность
    • Интеллектуальная проверка доступности
    • Неплохая статистика
• Репликация:
  • Используется Slony-I
  • Основана на триггерах
  • Master/Slave для обеспечения большего объема операций чтения
• Высокая доступность:
  • heartbeat
  • Пассивная копия мастер баз данных на случай сбоя основной
• Партиционирование:
  • Реализовано на уровне кода
  • Простая реализация, быстрые положительные результаты
  • Два метода разделения данных:
    • Вертикальное:
      • Создание нескольких таблиц с меньшим количеством колонок вместо одной (она же нормализация)
      • Позволяет разделять базы данных
      • Данные объединяются в коде (медленнее, чем на уровне СУБД, но не намного)
      • Бартер производительности на масштабируемость
      • Более эффективное кэшировние
      • Механизм роутеров в Django позволяет достаточно легко реализовать данный функционал
    • Горизонтальное:
      • Некоторые сайты имеют очень большие массивы данных
      • Партнеры требуют повышенного уровня доступности
      • Помогает снижать загрузку по записи на мастер базе данных
      • В основном используется все же вертикальное партиционирование
• Производительность базы данных:
  • Особое внимание уделяется тому, чтобы индексы помещались в оперативную память
  • Логгирование медленных запросов (автоматизировано с помощью syslog-ng + pgFouine + cron)
  • Использование пулов соединений (Django не умеет этого, используется pgbouncer, позволяет экономить на ресурсоемких операциях установления и прекращения соединений)
  • Оптимизация QuerySet’ов:
    • Не используется чистый SQL
    • Встроенный кэш позволяет выделять части выборки
    • Но это не всегда нужно, они убрали этот кэш
  • Атомарные операции:
    • Поддерживают консистентность данных
    • Использование update(), так как save() не является thread-safe
    • Отлично работают для таких вещей, как счетчики
  • Транзакции:
    • TransactionMiddleware поначалу использовалось, но со временем стало обузой
    • В postgrrsql_psycopg2 есть опция autocommit:
      • Это означает что каждый запрос выполняется в отдельной транзакции
      • Обработка каждого пользовательского HTTP-запроса не начинает новую транзакцию
      • Но все же транзакции из нескольких операций записи в СУБД нужны (сохранение нескольких объектов одновременно и полный откат в  случае ошибки)
      • В итоге все HTTP-запросы по-умолчанию начинаются в режиме autocommit, но в случае необходимости  переключаются в транзакционный режим
• Отложенные сигналы:
  • Постановка в очередь низкоприоритетных задач (даже если они не длинные по времени)
  • Асинхронные сигналы очень удобны для разработчика (но не так, как настоящие сигналы)
  • Модели отправляются в очередь в сериализованном виде
• Кэширование:
  • Используется memcached
  • Новый pylibmcна основе libmemcached в качестве клиента (проекты django-pylibmc и django-newcache)
  • Настраиваемые алгоритмы поведения клиента
  • Используется _auto_reject_hosts и _retry_timeout для предотвращения повторных подключений к вышедшим из строя кэш-серверам
  • Алгоритм размещения ключей: консистентное хэширование на основе libketama
  • Существует проблема, когда одно очень часто используемое значение в кэше инвалидируется:
    • Множество клиентов одновременно пытаются получить новое значение из СУБД одновременно
    • В большинстве случаев правильным решением было бы вернуть большинству устаревшие данные и позволить одному клиенту обновить кэш
    • django-newcache и MintCache умеют это делать
    • Заполнение кэша новым значением вместо удаления при инвалидации также помогает избежать этой проблемы
• Мониторинг:
  • Информация о производительности запросов к БД, внешних вызовов и рендеринге шаблонов записывается через собственный middleware
  • Сбор и отображение с помощью Ganglia
• Отключение функционала:
  • Необходим способ быстро отключить новый функционал, если оказывается, что он работает не так, как планировалось
  • Система должна срабатывать мгновенно, по всем серверам, без записи на диск
  • Позволяет запускать новые возможности постепенно, лишь для части аудитории
  • Позволяет постоянно использовать основную ветку кода
  • Аналогичная система используется и в Facebook
• Масштабирование команды разработчиков:
  • Небольшая команда
  • Месячная аудитория / количество разработчиков = 40 миллионов
  • Это означает:
    • Автоматическое тестирование
    • И максимально простой процесс разработки
  • Новый сотрудник может начать работать уже через несколько минут, нужно лишь:
    • Установить и настроить PostgreSQL
    • Скачать исходный код из git
    • С помощью pip и virtualenv установить зависимости
    • Изменить настройки в settings.py
    • Выполнить автоматическое создание структуры данных средствами Django
• Непрерывное тестирование:
  • Ежедневное развертывание с помощью Fabric
  • Hudson обеспечивает регулярно осуществляет и тестирует сборки
  • Интегрирован Selenium
  • Быстрое тестирование с помощью Pyflakes и post-commit hooks
  • 70 тысяч строк Python кода, 73% покрытие тестами, прогон всех тестов занимает 20 минут
  • Собственная система исполнения тестов с поддержкой XML, Selenium, подсчета количества запросов, тестирования Master/Slave базы данных и интеграцией с очередью
• Отслеживание проблем и задач:
  • Переключились с Trac на Redmine (из-за поддержки под-задач)
  • Отправка исключений на e-mail — плохая идея
  • Раньше использовали django-db-log, но теперь опубликовали свою систему сбора ошибок и логов под названием Sentry

Делаем выводы

• Язык программирования, каким бы он ни был, не является проблемой
• Django в целом очень хорош (но приходится все же использовать набор собственных патчей)
• Даже при использовании низкопроизводительного framework можно построить масштабируемую систему
• Вертикальное партиционирование позволяет пожертвовать производительностью в пользу масштабируемости
• Даже небольшой командой разработчиков можно добиться высоких результатов, если не пренебрегать автоматизацией тестирования
• Большое значение имеет возможность вовремя отслеживать и оперативно реагировать на сбои

Источник информации

Данная статья написана на основе выступления Jason Yan и David Cramer на DjangoConf 2010. В презентации можно найти примеры кода, ссылки на упоминаемые проекты и дополнительные материалы:

Другие статьи по масштабируемости высоконагруженных систем можно почитать в соответствующем разделе, а вовремя узнавать о новых — подписавшись на RSS. Вчера, кстати, прикрутил DISQUS к Insight IT, приглашаю постоянных читателей и всех остальных потестировать

Но, к счастью, времена меняются, и на сегодняшний день покупка даже серверного оборудования связана с достаточно скромными затратами, сопоставимыми с бюджетом покупки настольного компьютера или ноутбука. Но возникает другой вопрос — а что же с этим оборудованием делать? Вполне логичным ответом было бы: «использовать по прямому назначению», о чем мы с Вами сегодня и поговорим в компании с замечательным персонажем по имени Beastie и операционной системой FreeBSD, с которой он частенько ассоциируется.

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

Предистория

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

Ассортимент оборудования, спрятанного внутри 1U корпуса, был вполне стандартным, ничего особенного: процессор Intel Xeon 5335, оперативная память Kingston 2х2 GB ECC Full-buffered, жесткий диск изначально только один — WD 150 GB 10000rpm SATA, а вот модель материнской платы, к сожалению, на память назвать не могу, вроде что-то от SuperMicro, с простенькой встроенной видеокартой, сетевой картой с двумя гигабитными Ethernet портами и встроенным же видимо software RAID-контроллером. Опытный глаз наверняка заметил бы в этом списке сильную недоукомплектацию, особенно проявляющуюся при упоминании процессора в единственном числе, отсутствии RAID, и скромным объемам оперативной памяти. Объясняется это достаточно просто — проект еще предстоит тестировать перед запуском, а этой платформы для этого будет более чем достаточно.

Перед запуском проекта в открытое плавание естественно предстоит upgrade оборудования.

День первый

Подготовка

Если верить бумажкам, идущим в комплекте с сервером, на единственный жестком диск в магазине установили демо-версию одной из серверных операционных систем от одной мало кому известной корпорации. Смотреть что это за зверь такой у меня особого желания не было, по-этому я не долго думая пошел искать среди своей коллекции дистрибутивов болванку с заранее выбранным opensource решением вопроса об операционной системе — FreeBSD 6.2.

Почему выбор пал именно на эту ОС объяснить не так уж и просто, но я все же попробую. Выбор был достаточно классический: Unix vs Linux, возникали еще некоторые сомнения насчет решений от Sun в виде Solaris и OpenSolaris, но от них я отказался достаточно быстро в основном из-за более чем скромной документации и проприетарного происхождения, попутно закрыв глаза на все положительные отзывы, которые я видел в Сети.

Так как мне хотелось иметь иметь перед собой конструктор для сбора системы именно таким образом, как было бы удобно мне, а не разработчикам дистрибутива, то список вариантов, выступавших на стороне Linux быстро начал сокращаться, начиная с CentOS. Предпоследним вычеркнутым из списка дистрибутивов Linux был Debian, что оставило в нем лишь Gentoo Linux. Финальный выбор между FreeBSD и Gentoo был сделан уже легче: во-первых, по своему опыту с ноутбуком я уже понял, что с Gentoo предстояло бы немало хлопот, а, во-вторых, в новый конструктор, как ни крути, «играть» намного интереснее, чем в старый, так что долго думать не пришлось

Установка

Найдя наконец диск с FreeBSD, я попытался решить следующий возникший вопрос: а как же установить операционную систему с компакт-диска на компьютер, не имеющий соответствующего привода? Так как сервер был запломбирован и находился на гарантии, вариант частично разобрать и подключить обычный привод отпал сразу же, ровно как и вариант с подключением внешнего привода по причине его отсутствия. Подходящее решение было найдено практически сразу же, благо жесткие диски подключались по принципу hotswap: вытащив жесткий диск без развинчивания корпуса, я подключил его к подвернувшемуся под руку настольному компьютеру, обладающему DVD-приводом. Загрузка прошла успешно и я приступил к установке, руководствуясь FreeBSD Handbook, пересказывать его особого желания у меня нет, остановлюсь лишь на некоторых особенностях этого процесса.

Первым этапом установки, где пришлось задуматься, был fdisk (разбиение диска на так называемые slice). Для избежания путаницы для самого себя, я решил, что размещу рабочие директории http-сервера и базы данных в /var, которую и выделил в отдельный slice, занимающий большую часть доступного дискового пространства. В ассортимент доступного при установке программного обеспечения я особо вникать не стал, так как знал, что у меня всегда будет возможность заняться им позже, и как следствие этого выбрал что-то очень близкое к стандартному набору ПО.
Подтвердив установку и подождав достаточно непродолжительный период времени, я перезагрузил систему, вытащив установочный диск в процессе. Установка оказалась на удивление элементарной, что привело к полученной с первой попытки работоспособной системе. Увидев долгожданное приглашение к вводу логина и пароля я убедился, что могу беспрепятственно получить доступ к консоли и сразу же выключил систему, чтобы перенести жесткий диск обратно на сервер.

Так как сетевое подключение еще только предстояло настроить, то на сервер переносить пришлось не только жесткий диск, но и монитор с клавиатурой. На новом оборудовании все так же прекрасно запустилось, и я принялся за настройку подключения. Особых проблем не возникло — в Handbook‘е все более чем качественно задокументировано, самым сложным был процесс выбора драйвера, вернее осознавание того, что он изначально правильно сам установился. Следующей маленькой проблемой было угадывание какой же из Ethernet-портов был только что настроен, и, соответственно, подключение кабеля именно в него, а не в его соседа. После завершения всех манипуляций я с радостью обнаружил, что ping от сервера до gateway’а успешно проходит, что по сути и означало окончание настройки сетевого подключения.
Следущей целью было избавить себя от необходимости пользоваться позаимствованными у другого компьютера клавиатурой и монитором. Дело тоже оказалось достаточно нехитрым, sshd установился и настроился вполне самостоятельно где-то в процессе установки, от меня потребовалось лишь создать дополнительного пользователя, написать нехитрую строчку в rc.conf: sshd_enable=»YES» и собственно запустить daemon’а. Этого было вполне достаточно, чтобы набрав на своем ноутбуке ssh в консоли, с указанием необходимых параметров, получить удаленный доступ к серверу по протоколу SSH.

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

День второй

Программное обеспечение

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

Прежде чем что-либо устанавливать, очень не пожалел, что ознакомился как с соответствующим разделом handbook’a, так и с доступным ассортиментом ПО. После этого я перешел-таки собственно к выбору и установке ПО:

• Так как одной из основных составных частей практически любого веб-сервера является http-daemon, именно с его выбора я и решил начать. Причем начал еще задолго до описываемых событий, вся многофункциональность Apache мне была не нужна, а аналоги mod_auth и mod_rewrite есть и в более легких http-серверах. Cамо веб-приложение, которое там предполагалось располагать, работает по большей части на PHP, так что ничего особенного от httpd совсем не требовалось. В итоге финальный выбор был между быстрыми и легкими вариантами: nginx и lighttpd, какой-либо весомой причины по которой я выбрал lighttpd с mod_fastcgi привести не могу, основным фактором был мой некоторый опыт работы с ним в прошлом, и отсутствие такового в отношении nginx. Установка прошла легко и непринужденно с помощью в сжатые сроки найденного в Google мануала.
• Другим немаловажным компонентом сервера является ftpd, как известно используемый для передачи файлов. Собственно говоря, если активное его использование не планируется, то особого значения какой именно сервер будет использоваться значения не имеет: любой из доступных устанавливается настраивается в пару простых шагов без каких-либо проблем (если это имеет значение — я выбрал vsftpd, так как мне уже далеко не один раз доводилось его настраивать на домашних компьютерах, и, как следствие, даже инструкция не понадобилась). Но при потенциальной возможности работы через Интернет, этот протокол является достаточно уязвимым, так как не использует никакого шифрования. Эта проблема решается с помощью механизма FTP over SSH, который представляет собой использование SSH в роли туннеля для передачи файлов по FTP. О том, как воспользоваться этим механизмом вам подскажет man ssh, какой-либо дополнительной конфигурации он не требует, разве что настройки соответствующим образом firewall’а, но об этом я расскажу позже.
• Сам PHP установлен последней доступной в ports версии и , как уже упоминалось, был подключен к lighttpd с помощью mod_fastcgi, какой-либо дополнительной конфигурации с моей стороны не потребовалось, я разве что выбрал список модулей (в общем-то тоже занятие не сложное, достаточно лишь осознавать какие именно используются, плюс я еще решил Suhosin установить) и просто просмотрел по диагонали все конфиги (в основном сам php.ini и lighttpd.conf) на предмет их соответствия потребностям моего приложения. Отдельная история возникла с лишь одним модулем — Blitz, который на данный момент все еще отсутствует в репозиториях как FreeBSD, так и подавляющего большинства (если не всех) дистрибутивов Linux. Его пришлось устанавливать вручную из исходников по соответствующему мануалу, что правда тоже дело не хитрое и заняло всего несколько минут.
• СУБД особо выбирать не пришлось — приложение написано было с расчетом на PostrgeSQL, ее соответственно и прикручивал к PHP. Этот этап был пожалуй одним из самых проблематичных, так как сразу после классического make install clean соответствующий daemon запускаться отказался. Какого-либо осознанного сообщения об ошибке /usr/local/etc/rc.d/postgresqld start не выводило как в консоль, так и в логи, но тем не менее консольный клиент psql и само веб-приложение жаловались на отсутствие запущенной СУБД. Этот факт сильно затруднял поиск возможных вариантов решения на просторах Сети, так что не найдя ничего полезного я решил заняться диагностикой проблемы и поиском решения для нее самостоятельно. Методом проб и ошибок, перебрав множество возможных вариантов запуска daemon’а, я пришел к выводу, что у пользователя от имени которого он должен был запускаться явно проблемы с доступом к файловой системе. Видимо так получилось из-за нестандартного расположения самой базы данных — в директории /var. Не смотря на тот факт, что chown и chmod были использованы по прямому назначению в отношении соответствующих директорий для установления прав доступа. В итоге оказалось, что директория указанная для этого пользователя как домашняя (по памяти пишу, могу ошибиться, но вроде /usr/local/pgsql) по каким-то причинам не создалась и соответственно именно этот факт и мешал запуску daemon’а. Восстановив справедливость в отношении этого пользователя, я обнаружил, что PostrgeSQL успешно запустился-таки, а мое приложение тоже стало функционировать именно так, как ему было положено. Проверив содержимое соответствующего конфига, я решил его больше не трогать, а то как говорится «premature optimization is the root of all evil»&copyright;. За компанию решил установить веб-интерфейс к PostrgeSQL — phppgadmin. Собравшись из портов, он повел себя как-то не очень адекватно, совсем не так каким я привык его видеть у себя на ноутбуке, разбираться в причинах было не охота — простое копирование и замена соответствующей директории по ftp буквально за минуту решило проблему.
• Вариантов фильтров сетевого трафика в FreeBSD имеется предостаточно: pf, ipf, ipfw. Опыта работы ни с одним из них у меня не было, так что выбор происходил из достаточно субъективных критериев — очевидности принципов работы правил и достаточности документации. Так как я был уверен, что каждый из них сможет обеспечить достаточный уровень безопасности, основываясь на указанных выше критериях в итоге я выбрал ipf. Документация позволила легко и непринужденно все установить и настроить, правда за компанию пришлось разбираться и с пересборкой ядра. В качестве базы для построения собственного списка правил я использовал приведенный все там же, в документации, пример. Само собой пришлось доработать его под конкретную систему, но методом проб и ошибок эта задача выполняется достаточно быстро (будте осторожны с 22 портом, используемым для SSH — очень легко на этом этапе случайно заблокировать самому себе доступ к серверу). Получившийся в итоге список правил приводить не буду, так как его еще предстоит довести до ума на активно работающей системе.

Заключение

Не прошло и двух дней, как из простого набора оборудования получился вполне готовый к работе веб-сервер, конечно же доводить до ума его придется еще достаточно долго, но просто стабильно работать он был в состоянии уже тогда. Дальше его отвезли в место постоянного его прибывания, подключили к более-менее приличному интернет-каналу, с моей стороны при этом потребовалось лишь слегка поменять настройки сетевого подключения, и вот — он уже доступен из Сети. Практически сразу же обнаружился один мой недочет в плане выбора ПО — буквально в первую же ночь после открытия публичного доступа к серверу нашлась масса желающих попытаться подобрать по словарю логин и пароль для доступа к серверу по SSH, но он был открыт лишь для одной учетной записи, у которой было мягко говоря нестандартное имя пользователя, даже его никто за ночь не смог угадать, а до более чем 20-символьного пароля дело так и не дошло. На следующее утро я, не долго думая, установил программу под названием sshguard, которая сразу же предотвратила все последующие попытки подобным образом издеваться над сервером. Дальше надо было настроить запись на DNS-сервере для ассоциации домена с IP нашего сервера, настроить почту, закончить работу над самим веб-приложением и много чего еще, но это уже совсем другая история.

Но, к счастью, времена меняются, и на сегодняшний день покупка даже серверного оборудования связана с достаточно скромными затратами, сопоставимыми с бюджетом покупки настольного компьютера или ноутбука. Но возникает другой вопрос — а что же с этим оборудованием делать? Вполне логичным ответом было бы: «использовать по прямому назначению», о чем мы с Вами сегодня и поговорим в компании с замечательным персонажем по имени Beastie и операционной системой FreeBSD, с которой он частенько ассоциируется.

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

Предистория

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

Ассортимент оборудования, спрятанного внутри 1U корпуса, был вполне стандартным, ничего особенного: процессор Intel Xeon 5335, оперативная память Kingston 2х2 GB ECC Full-buffered, жесткий диск изначально только один — WD 150 GB 10000rpm SATA, а вот модель материнской платы, к сожалению, на память назвать не могу, вроде что-то от SuperMicro, с простенькой встроенной видеокартой, сетевой картой с двумя гигабитными Ethernet портами и встроенным же видимо software RAID-контроллером. Опытный глаз наверняка заметил бы в этом списке сильную недоукомплектацию, особенно проявляющуюся при упоминании процессора в единственном числе, отсутствии RAID, и скромным объемам оперативной памяти. Объясняется это достаточно просто — проект еще предстоит тестировать перед запуском, а этой платформы для этого будет более чем достаточно.

Перед запуском проекта в открытое плавание естественно предстоит upgrade оборудования.

День первый

Подготовка

Если верить бумажкам, идущим в комплекте с сервером, на единственный жестком диск в магазине установили демо-версию одной из серверных операционных систем от одной мало кому известной корпорации. Смотреть что это за зверь такой у меня особого желания не было, по-этому я не долго думая пошел искать среди своей коллекции дистрибутивов болванку с заранее выбранным opensource решением вопроса об операционной системе — FreeBSD 6.2.

Почему выбор пал именно на эту ОС объяснить не так уж и просто, но я все же попробую. Выбор был достаточно классический: Unix vs Linux, возникали еще некоторые сомнения насчет решений от Sun в виде Solaris и OpenSolaris, но от них я отказался достаточно быстро в основном из-за более чем скромной документации и проприетарного происхождения, попутно закрыв глаза на все положительные отзывы, которые я видел в Сети.

Так как мне хотелось иметь иметь перед собой конструктор для сбора системы именно таким образом, как было бы удобно мне, а не разработчикам дистрибутива, то список вариантов, выступавших на стороне Linux быстро начал сокращаться, начиная с CentOS. Предпоследним вычеркнутым из списка дистрибутивов Linux был Debian, что оставило в нем лишь Gentoo Linux. Финальный выбор между FreeBSD и Gentoo был сделан уже легче: во-первых, по своему опыту с ноутбуком я уже понял, что с Gentoo предстояло бы немало хлопот, а, во-вторых, в новый конструктор, как ни крути, «играть» намного интереснее, чем в старый, так что долго думать не пришлось

Установка

Найдя наконец диск с FreeBSD, я попытался решить следующий возникший вопрос: а как же установить операционную систему с компакт-диска на компьютер, не имеющий соответствующего привода? Так как сервер был запломбирован и находился на гарантии, вариант частично разобрать и подключить обычный привод отпал сразу же, ровно как и вариант с подключением внешнего привода по причине его отсутствия. Подходящее решение было найдено практически сразу же, благо жесткие диски подключались по принципу hotswap: вытащив жесткий диск без развинчивания корпуса, я подключил его к подвернувшемуся под руку настольному компьютеру, обладающему DVD-приводом. Загрузка прошла успешно и я приступил к установке, руководствуясь FreeBSD Handbook, пересказывать его особого желания у меня нет, остановлюсь лишь на некоторых особенностях этого процесса.

Первым этапом установки, где пришлось задуматься, был fdisk (разбиение диска на так называемые slice). Для избежания путаницы для самого себя, я решил, что размещу рабочие директории http-сервера и базы данных в /var, которую и выделил в отдельный slice, занимающий большую часть доступного дискового пространства. В ассортимент доступного при установке программного обеспечения я особо вникать не стал, так как знал, что у меня всегда будет возможность заняться им позже, и как следствие этого выбрал что-то очень близкое к стандартному набору ПО.
Подтвердив установку и подождав достаточно непродолжительный период времени, я перезагрузил систему, вытащив установочный диск в процессе. Установка оказалась на удивление элементарной, что привело к полученной с первой попытки работоспособной системе. Увидев долгожданное приглашение к вводу логина и пароля я убедился, что могу беспрепятственно получить доступ к консоли и сразу же выключил систему, чтобы перенести жесткий диск обратно на сервер.

Так как сетевое подключение еще только предстояло настроить, то на сервер переносить пришлось не только жесткий диск, но и монитор с клавиатурой. На новом оборудовании все так же прекрасно запустилось, и я принялся за настройку подключения. Особых проблем не возникло — в Handbook‘е все более чем качественно задокументировано, самым сложным был процесс выбора драйвера, вернее осознавание того, что он изначально правильно сам установился. Следующей маленькой проблемой было угадывание какой же из Ethernet-портов был только что настроен, и, соответственно, подключение кабеля именно в него, а не в его соседа. После завершения всех манипуляций я с радостью обнаружил, что ping от сервера до gateway’а успешно проходит, что по сути и означало окончание настройки сетевого подключения.
Следущей целью было избавить себя от необходимости пользоваться позаимствованными у другого компьютера клавиатурой и монитором. Дело тоже оказалось достаточно нехитрым, sshd установился и настроился вполне самостоятельно где-то в процессе установки, от меня потребовалось лишь создать дополнительного пользователя, написать нехитрую строчку в rc.conf: sshd_enable=»YES» и собственно запустить daemon’а. Этого было вполне достаточно, чтобы набрав на своем ноутбуке ssh в консоли, с указанием необходимых параметров, получить удаленный доступ к серверу по протоколу SSH.

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

День второй

Программное обеспечение

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

Прежде чем что-либо устанавливать, очень не пожалел, что ознакомился как с соответствующим разделом handbook’a, так и с доступным ассортиментом ПО. После этого я перешел-таки собственно к выбору и установке ПО:

• Так как одной из основных составных частей практически любого веб-сервера является http-daemon, именно с его выбора я и решил начать. Причем начал еще задолго до описываемых событий, вся многофункциональность Apache мне была не нужна, а аналоги mod_auth и mod_rewrite есть и в более легких http-серверах. Cамо веб-приложение, которое там предполагалось располагать, работает по большей части на PHP, так что ничего особенного от httpd совсем не требовалось. В итоге финальный выбор был между быстрыми и легкими вариантами: nginx и lighttpd, какой-либо весомой причины по которой я выбрал lighttpd с mod_fastcgi привести не могу, основным фактором был мой некоторый опыт работы с ним в прошлом, и отсутствие такового в отношении nginx. Установка прошла легко и непринужденно с помощью в сжатые сроки найденного в Google мануала.
• Другим немаловажным компонентом сервера является ftpd, как известно используемый для передачи файлов. Собственно говоря, если активное его использование не планируется, то особого значения какой именно сервер будет использоваться значения не имеет: любой из доступных устанавливается настраивается в пару простых шагов без каких-либо проблем (если это имеет значение — я выбрал vsftpd, так как мне уже далеко не один раз доводилось его настраивать на домашних компьютерах, и, как следствие, даже инструкция не понадобилась). Но при потенциальной возможности работы через Интернет, этот протокол является достаточно уязвимым, так как не использует никакого шифрования. Эта проблема решается с помощью механизма FTP over SSH, который представляет собой использование SSH в роли туннеля для передачи файлов по FTP. О том, как воспользоваться этим механизмом вам подскажет man ssh, какой-либо дополнительной конфигурации он не требует, разве что настройки соответствующим образом firewall’а, но об этом я расскажу позже.
• Сам PHP установлен последней доступной в ports версии и , как уже упоминалось, был подключен к lighttpd с помощью mod_fastcgi, какой-либо дополнительной конфигурации с моей стороны не потребовалось, я разве что выбрал список модулей (в общем-то тоже занятие не сложное, достаточно лишь осознавать какие именно используются, плюс я еще решил Suhosin установить) и просто просмотрел по диагонали все конфиги (в основном сам php.ini и lighttpd.conf) на предмет их соответствия потребностям моего приложения. Отдельная история возникла с лишь одним модулем — Blitz, который на данный момент все еще отсутствует в репозиториях как FreeBSD, так и подавляющего большинства (если не всех) дистрибутивов Linux. Его пришлось устанавливать вручную из исходников по соответствующему мануалу, что правда тоже дело не хитрое и заняло всего несколько минут.
• СУБД особо выбирать не пришлось — приложение написано было с расчетом на PostrgeSQL, ее соответственно и прикручивал к PHP. Этот этап был пожалуй одним из самых проблематичных, так как сразу после классического make install clean соответствующий daemon запускаться отказался. Какого-либо осознанного сообщения об ошибке /usr/local/etc/rc.d/postgresqld start не выводило как в консоль, так и в логи, но тем не менее консольный клиент psql и само веб-приложение жаловались на отсутствие запущенной СУБД. Этот факт сильно затруднял поиск возможных вариантов решения на просторах Сети, так что не найдя ничего полезного я решил заняться диагностикой проблемы и поиском решения для нее самостоятельно. Методом проб и ошибок, перебрав множество возможных вариантов запуска daemon’а, я пришел к выводу, что у пользователя от имени которого он должен был запускаться явно проблемы с доступом к файловой системе. Видимо так получилось из-за нестандартного расположения самой базы данных — в директории /var. Не смотря на тот факт, что chown и chmod были использованы по прямому назначению в отношении соответствующих директорий для установления прав доступа. В итоге оказалось, что директория указанная для этого пользователя как домашняя (по памяти пишу, могу ошибиться, но вроде /usr/local/pgsql) по каким-то причинам не создалась и соответственно именно этот факт и мешал запуску daemon’а. Восстановив справедливость в отношении этого пользователя, я обнаружил, что PostrgeSQL успешно запустился-таки, а мое приложение тоже стало функционировать именно так, как ему было положено. Проверив содержимое соответствующего конфига, я решил его больше не трогать, а то как говорится «premature optimization is the root of all evil»&copyright;. За компанию решил установить веб-интерфейс к PostrgeSQL — phppgadmin. Собравшись из портов, он повел себя как-то не очень адекватно, совсем не так каким я привык его видеть у себя на ноутбуке, разбираться в причинах было не охота — простое копирование и замена соответствующей директории по ftp буквально за минуту решило проблему.
• Вариантов фильтров сетевого трафика в FreeBSD имеется предостаточно: pf, ipf, ipfw. Опыта работы ни с одним из них у меня не было, так что выбор происходил из достаточно субъективных критериев — очевидности принципов работы правил и достаточности документации. Так как я был уверен, что каждый из них сможет обеспечить достаточный уровень безопасности, основываясь на указанных выше критериях в итоге я выбрал ipf. Документация позволила легко и непринужденно все установить и настроить, правда за компанию пришлось разбираться и с пересборкой ядра. В качестве базы для построения собственного списка правил я использовал приведенный все там же, в документации, пример. Само собой пришлось доработать его под конкретную систему, но методом проб и ошибок эта задача выполняется достаточно быстро (будте осторожны с 22 портом, используемым для SSH — очень легко на этом этапе случайно заблокировать самому себе доступ к серверу). Получившийся в итоге список правил приводить не буду, так как его еще предстоит довести до ума на активно работающей системе.

Заключение

Не прошло и двух дней, как из простого набора оборудования получился вполне готовый к работе веб-сервер, конечно же доводить до ума его придется еще достаточно долго, но просто стабильно работать он был в состоянии уже тогда. Дальше его отвезли в место постоянного его прибывания, подключили к более-менее приличному интернет-каналу, с моей стороны при этом потребовалось лишь слегка поменять настройки сетевого подключения, и вот — он уже доступен из Сети. Практически сразу же обнаружился один мой недочет в плане выбора ПО — буквально в первую же ночь после открытия публичного доступа к серверу нашлась масса желающих попытаться подобрать по словарю логин и пароль для доступа к серверу по SSH, но он был открыт лишь для одной учетной записи, у которой было мягко говоря нестандартное имя пользователя, даже его никто за ночь не смог угадать, а до более чем 20-символьного пароля дело так и не дошло. На следующее утро я, не долго думая, установил программу под названием sshguard, которая сразу же предотвратила все последующие попытки подобным образом издеваться над сервером. Дальше надо было настроить запись на DNS-сервере для ассоциации домена с IP нашего сервера, настроить почту, закончить работу над самим веб-приложением и много чего еще, но это уже совсем другая история.

Если подойти к этому вопросу "в лоб", то код станет очень неудобен как для понимания, так и для использования: код станет переполнен различными функциями соединения с БД, отправки запросов, преобразования результатов запросов в массивы PHP, подсчета строк, которые затронул запрос, а также многие и многие другие.

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

Этим способом будет являться написание класса, реализующего интерфейс между СУБД и PHP-скриптами. Для начала стоит определиться с ассортиментом функций, которые будет призван выполнять наш класс:

• установка соединения, а также проверка успешности выполнения этого действия;
• отправка запросов, как заданных извне так и, возможно, из какого-либо ассортимента заранее написанных запросов;
• обработка результатов запросов, не ограничивающаяся одним SELECT, должны быть предоставлены методы обработки результатов любых видов запросов (или хотябы большинства).

Вполне очевидным является тот факт, что методы этого класса будут использоваться практически повсеместно в большинстве проектов. Вследствии чего становится нецелесообразным создание объекта нашего класса и передача его по всем функциям и методам всех скриптов, в таких случае намного предпочтительнее делать владельцем методов и переменных сам класс, а не экземпляр класса, с помощью ключевого слова static. Это позволит пользоваться услугами нашего класса из любого места кода. Приступим-с собственно к кодингу, начать стоит с заготовки пустого класса:

В зависимости от предпочитаемой Вами СУБД набор конкретных функций, используемых в реализации нашего класса, будет вариироваться. В большинстве случаев предпочитаю пользоваться PostgreSQL, на это причин у меня несколько, но это тема для отдельного разговора. Благодаря этому факту приводимый в качестве примера код будет использовать функции для работы именно с этой СУБД. Для поклонников же других этот систем вопрос в подавляющем большинстве случаев заключается лишь в замене этих функций на аналогичные из других модулей PHP, например для популярной и широкораспространенной MySQL достаточно будет всеголишь пройтись автозаменой pg_ => mysql_ и слегка подредактировать параметры некоторых функций.

Перейдем к реализации установления соединения с СУБД, не стоит ожидать увидеть здесь ничего необычного:

static function connect()  // установка соединения
{
  self::$connection=pg_pconnect("host=localhost dbname=pgsql user=pgsql password=MyPassword");
  // не забываем менять указанные данные для авторизации на правильные
  if(!isset(self::$connection))
  {
    echo "Сайт не работает по техническим причинам.Просим прощения за доставленные неудобства.";
    exit;	// ни в коем случае не выводим более информативных сообщений об ошибке, чем это
  }
}

А вот с отправкой и обработкой результатов запросов ситуация далеко не так однозначна. Помимо простой передачи самого текста запроса в СУБД, необходимо правильно определить тип запроса и в соответствии с этим обработать результат. Можно конечно попытаться сделать это автоматически на основе вытаскивания первого слова из текста запроса, но мне всетаки кажется более предпочтительным определение "вручную" желаемого вида представление результата. Выполнение произвольных запросов может выглядеть, например, следующим образом:

static function query($str,$bool=false) // произвольный запрос
{
  //echo $str.""; // очень удобно на стадии разработки в процессе поиска ошибок
  $result=@pg_query(self::$connection,$str); // @ - для сокрытия теоретически возможных ошибок
  // or die('Query failed: '.pg_last_error());
  // не забываем убирать в комментарий в финальном варианте проекта
  // или совсем удалять
  if($result)  // Если получен результат, отличный от false
  {
    if($bool)  // Если выбран результат в виде boolean
    {
      return true;
    }
    else  // Если выбран результат в виде массива
    {
      $n=pg_num_rows($result);	// для создания универсального формата массива
      if($n==1)return pg_fetch_array($result,0,PGSQL_ASSOC);
      else  // даже когда результат содержит только одну строку
      {
        $j=pg_num_rows($result);
        $list=array();
        for($i=0;$i<$j;$i++)
        $list[]=pg_fetch_array($result,$i,PGSQL_ASSOC);
        return $list;
      }
    }
  }else return false;
}

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

static function selectAll($table)
{ // пример метода отправки чаcтоиспользуемых запросов
  return self::query("select * from ".$table.";");
}

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

Что ж, осталось лишь собрать весь код в единый листинг:

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

Эта статья является частью серии статей "Джентельменский набор PHP программиста", если Вам понравилась эта статья то очень вероятно, что Вам придутся по душе и остальные статьи.

Не забываем подписываться на RSS блога, а также на ленту комментариев.