Insight IT

Архитектура YouTube 2012

Иван Блинков — Sat, 24 Mar 2012 16:50:00 +0400

Выбирайте самое простое решение с наиболее общими гарантиями, которые практически полезны.

- Дао YouTube

YouTube практически на протяжении всех 7 лет своего существования является мировым лидером в сфере интернет-видео. С точки зрения технической реализации проект оказался достаточно консервативным - команда придерживается того же курса и стека технологий, с которых все начиналось еще до приобретения проекта Google. Но с 2008 года, когда я написал первый обзор архитектуры YouTube, все же произошли интересные изменения, о которых я и хотел бы сегодня вкратце рассказать.

Статистика

4 млрд. просмотров страниц в день
60 часов видео загружается каждую минуту
350 миллионов устройств подключено к YouTube
На февраль 2012 года в США по данным comScore:
- 147,4 млн. уникальных зрителей
- 16,7 млрд. просмотров видео (в октябре 2011 было больше 20 млрд.)
- Каждый зритель посмотрел в среднем 7 часов видео за месяц
- 1.1 млрд. просмотров видео рекламы, суммарной длительностью в 10.8 млн. часов

Технологии

Linux - операционная система
Apache - основной HTTP-сервер
lighttpd - отдача видео из YouTube CDN
Zookeeper - распределенные блокировки, хранение конфигураций
Python:
- wiseguy - FastCGI-прослойка между Apache и Python
- pycurl - лучшая доступная реализация HTTP-клиента, но в итоге все равно заменили на самописное низкоуровневое решение, выиграв 8% в потреблении вычислительных ресурсов.
- spitfire - высокопроизводительный шаблонизатор на основе абстрактного синтаксического дерева с регулируемым уровнем оптимизации (как в gcc)
- bson в качестве формата сериализации
BigTable - хранение изображений
MySQL - используется просто как хранилище данных, версия 5.1.52 с InnoDB
Vitess - система для масштабирования MySQL-кластера

Vitess

Основная цель проекта - предоставление всех необходимых инструментов и серверов для горизонтального масштабирования баз данных на основе MySQL, с учетом потребностей современных интернет-проектов.
Реализован на Go - все еще экзотическом языке программирования, также родившемся в стенах Google. Сравним по производительности с C++ и Java, но несколько более "выразителен".
Опубликован в opensource 24 февраля 2012 года, совсем недавно, так что YouTube - по-прежнему единственный пример его использования на практике в крупном проекте.
Готовые клиентские библиотеки пока только для Python и Go, что не удивительно, но есть и универсальные интерфейсы на основе HTTP и просто TCP-сокетов.
Основной формат данных - bson, как и в MongoDB, но по словам разработчиков Vitess их реализация выполняет (де)сериализацию в 10-15 раз быстрее.
Ядром проекта выступает Vtocc, SQL-прокси с RPC интерфейсом, позволяющий перераспределять запросы от большого количества (более 10 тыс.) одновременно подключенных клиентов в сравнительно небольшое количество соединений с базами данных. Пропускная способность порядка 10 тыс. запросов в секунду.
Встроенные возможности Vtocc:
- парсер и анализатор SQL-запросов для оптимизации их выполнения;
- заполнение типичных запросов переменными с поддержкой кэширования результатов;
- управление транзакциями и сроками их выполнения ("убивает" затянувшиеся);
- для каждого пространства ключей (логической таблицы) можно указать фактор репликации, что создаст необходимое количество второстепенных баз данных в дополнение к мастеру;
- можно явно указать, что чтение необходимо произвести с мастера (важно когда пользователь только что выполнил какое-то действие и должен сразу же увидеть его результат);
- отдельные пулы соединений для выполнения операций чтения и записи;
- исключение "зависших" соединений из пулов;
- перезапуск без простоя системы;
- поддержка DML.

Партиционирование

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

Подводим итоги

YouTube - еще один проект мирового масштаба, который с самого начала использовал MySQL и оказался не в силах от него отказаться, не смотря на трудности с горизонтальным масштабированием.
По аналогичному пути пошли и другие проекты, схожие с Vitess надстройки над MySQL используются в Facebook и Twitter:
- В Facebook она дополнена сильной интеграцией с memcached и сильно ограниченным интерфейсом, не имеющим практически ничего общего с SQL. Планы о публикации в opensource, кажется, были, но я не слышал чтобы они воплотились в жизнь. // Уже почти дописав статью случайно заметил в коде, а потом и мелким шрифтом в документации, что в Vitess тоже используется memcached для кэширования из-за проблем со сборщиком мусора Go.
- Twitter по-прежнему использует свою связку FlockDB + Gizzard на Scala, которые уже пару лет публично доступны. В отличии от Vitess она заточена на хранение информации о социальных графах, по-этому сфера её применения как в Twitter, так и за его пределами ограничена.
Vitess - пожалуй первая относительно успешная попытка построить распределенную горизонтально масштабируемую СУБД на основе реляционной базы данных, сохранив при этом SQL-интерфейс, пускай и с некоторыми ограничениями.
Выбирайте подходящее хранилище для каждого типа данных в системе - если Vitess стал подходящим решением для структурированных данных вроде информации о пользователях, метаданных видео и комментариев, это не значит, что он хорошо (или плохо) справится, например, с медиа-файлами вроде изображений и видео (для них в YouTube по-прежнему используют стек технологий Google, подробности не публикуются).
Python - вполне пригодный инструмент для реализации бизнес-логики интернет-проектов, свет клином на PHP не сошелся. Python предлагает широкий ассортимент инструментов для решения любых типичных для интернет-проектов задач, хотя субъективно выбор некоторых из них разработчиками YouTube мне кажется странным.

В комментариях предлагаю обсудить слабые и сильные стороны использования надстроек над реляционными базами данных, скажем по сравнению с использованием изначально-распределенных СУБД, таких как Riak, Cassandra и многих других. Может быть кто-то уже успел прикрутить к своему проекту Vitess или хотя бы FlockDB и готов поделиться впечатлениями?

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

Mike Solomon на PyCon'12 (один из первых разработчиков проекта)
О проекте Vitess
Статистика comScore на февраль '12

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

Иван Блинков — Fri, 28 Mar 2008 15:32:00 +0300

Wikimedia является платформой для Wikipedia, Wiktionary и еще семи менее крупных wiki-проектов. Этот документ очень пригодится новичкам, пытающимся довести свои проекты до масштабов гигантских вебсайтов. Здесь можно найти множество интересных деталей и инновационных идей, которые уже успели доказать свою работоспособность на самых посещаемых сайтах всего Интернета.

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

Перевод статьи. Автор - Todd Hoff.

Архитектура Wikimedia
Серверы Wikimedia
scale-out vs scale-up из блога "Oracle to MySQL"

Платформа

Apache
Linux
MySQL
PHP
Squid
LVS
Lucene для поиска
Memcached для распределенного кэширования объектов
lighttpd для работы с изображениями

Статитстика

8 миллионов статей распределены по сотням языковых подпроектов (английские, голландские, ...)
В десятке самых высоконагруженных проектов по данным Alexa
Экспоненциальный рост: в терминах посетителей, трафика и серверов удвоение происходит каждые 4-6 месяцев
30000 HTTP запросов в секунду в периоды пиковой нагрузки
3 GBps трафик данных
3 датацентра: Тампа, Амстердам, Сеул
350 серверов, конфигурации варьируются от однопроцессорных Pentium 4 с 512 MB оперативной памяти до двухпроцессорных Xeon Quad-Core с 16 GB RAM.
Управляется ~6 людьми
Три кластера на трех разных континентах

Архитектура

Географическая балансировка нагрузки, основываясь на IP клиента, перенаправляет их на ближайший кластер. Происходит статическое отображение множества IP адресов на множество стран, а затем и на множество кластеров.
Кэширование с помощью Squid группируется по типу контента: текст для wiki отдельно от изображений и больших статических файлов.
На данный момент функционирует 55 Squid серверов, плюс еще 20 подготавливается к запуску.
1000 HTTP запросов в секунду на каждый сервер, в периоды повышенной нагрузки эта цифра может достигать 2500.
~ 100-250 MBps на сервер.
~ 14000-32000 открытых соединений на каждом сервере.
До 40 GB дискового кэша на каждом Squid сервере.
До 4 дисков в каждом сервере (1U серверы).
8 GB оперативной памяти, половину использует Squid.
PowerDNS предоставляет геораспределение.
В основном и региональных датацентрах текстовые и медиа кластеры построены на LVS, CARP Squid, кэш Squid. В основном датацентре также находится хранилище медиа-данных.
Для того, чтобы обеспечить предоставление только последних версий страниц, всем Squid-серверам отправляются инвалидационные запросы.
Централизованно управляемая и синхронизированная установка программного обеспечения для сотен серверов.
MediaWiki отлично масштабируется с несколькими процессорами, так что закупаются двухпроцессорный четырех ядерные серверы (8 ядер на сервер).
Одно и то же оборудование выполняет как задачи внешнего хранения данных, так и кэширования Memcached.
Memcached используется для кэширования метаданных изображений, данных парсера, различий между ревизиями, пользователей, сессий. Метаданные, такие как история ревизий, отношений статей (ссылки, категории и так далее), учетные записи пользователей хранятся в основных базах данных
Сам текст находится во внешних хранилищах данных.
Статические (загруженные пользователями) файлы, например изображения, хранятся отдельно на сервере изображений, а метаданные (размер, тип и так далее) кэшируются в основной базе данных и объектном кэше.
Отдельная база данных для каждой вики (не отдельный сервер!).
Один master и много реплицированных slave серверов.
Операции чтения равномерно распределяются по slave серверам, операции записи направляются на master.
Иногда master используется и для операция чтения, когда репликация на slave еще не завершена.
Внешнее хранение данных:
- Текст статей хранится на отдельных кластерах, которые представляют собой простой средство хранения данных с возможностью только дописывания новых данных. Такой подход позволяет сохранить дорогостоящее место в высоконагруженных основных базах данных от редко используемой информации.
- Благодаря этому появляются дополнительные неиспользованные ресурсы на серверах приложений (порой 250-500 GB на сервер).
- На данной момент используются реплицируемые кластеры из 3 MySQL серверов, но в будущем это может измениться, так как требуется более удобное управление ими.

Подводим итоги

Сфокусируйтесь на архитектуре, а не на операциях или чем-то другом.
Иногда кэширование обходится дороже, чем повторные вычисление или поиск данных в исходном источнике.
Старайтесь избегать сложных алгоритмов, запросов к базе данных и тому подобного.
Кэшируйте каждый результат, который дорого вам обошелся и является относительно локальным.
Сфокусируйтесь на "горячих точках" в коде.
Масштабируйтесь разделением:
- операций чтения и записи (master/slave);
- сложных операций и более частых и простых (группы запросов);
- больших, популярных вики и более мелких.
Улучшайте кэширование: временная и пространственная локализация данных, а также уменьшение набора данных на каждом сервере.
Выполняйте компрессию текстовых данных, храните только изменения в статьях.
Казалось бы простые вызовы библиотечных функций порой на практике могут занимать слишком много времени.
Скорость поиска данных на диске ограничена, так что чем больше дисков - тем лучше!
Масштабирование с использованием обычного оборудование не означает использование самых дешевых вещей, которые удастся найти. Серверы баз данных Wikipedia сегодня представляют собой 16GB RAM, двух- или четырех-ядерные серверы с 6 15000 rpm SCSI дисками, организованными в RAID 0. Возможно они бы и использовали более дешевые системы, но 16 GB как раз хватает для размещения основного объема данных, а остальное берут на себя жесткие диски, это вполне соответствует потребностям системы, которую они построили. Примерно по таким же причинам их веб-сервера имеют 8 ядер, так как это позволяет достичь неплохой производительности PHP при достаточно простой организации балансировки нагрузки.
Для масштабирования требуется выполнение массы работы, но если заранее этого не предусмотреть - понадобится сделать еще больше. MediaWiki изначально была написана для одного master сервера баз данных. Затем добавилась поддержка slave. Затем добавилось распределение по языкам и проектам. Дизайн системы с тех пор прекрасно выдерживает все нагрузки, но без очистки от новых узких мест системы не обошлось.
Каждый, кто хочет разработать свою базу данных таким образом, чтобы она позволила недорого масштабироваться с уровня одного сервера до уровня десятки лучших сайтов Интернета, должен начать с обработки слегка устаревших данных на реплицированных slave серверах, при этом не забывать балансировать нагрузку операций чтения между slave серверами. Если это возможно - блоки данных (группы пользователей, учетных записей, или чего угодно) должны размещаться каждый на разных серверах. Можно делать это с самого начала используя виртуализацию, чтобы удостовериться в работоспособности архитектуры, когда вы еще "маленькие". Это намного проще, чем когда вы делаете то же самое, но под ежемесячно удваивающейся нагрузкой.

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

Иван Блинков — Sat, 01 Mar 2008 16:07:00 +0300

Рост YouTube был феноменально быстр, количество просмотров видео превысило 100 миллионов в сутки при том, что только около пяти человек работало над масштабированием проекта. Как им удается управлять предоставлением всех этих видеороликов своим посетителям? Как они развивались с тех пор, как были приобретены Google?

Платформа

Apache
Python
Linux (SuSe)
MySQL
psyco, динамический компилятор Python → C
lighttpd для видео

Что внутри?

Статистика

Поддержка обработки более 100 миллионов видеороликов в сутки
Сервис был запущен в феврале 2005 года
В марте 2006 года в среднем производилось около 30 миллионов просмотров видео в день
К июлю 2006 года эта цифра достигла 100 миллионов просмотров в день
Над проектом работают: 2 системных администратора, 2 архитектора масштабируемости программного обеспечения, 2 разработчика новых возможностей, 2 инженера по сетям, 1 архитектор баз данных

Рецепт управления огромными темпами роста

while (true)
{
   identify_and_fix_bottlenecks();
   drink();
   sleep();
   notice_new_bottleneck();
}

Этот цикл проходит далеко не одну итерацию ежедневно.

Веб-серверы

NetScalar используется для балансировки нагрузки и кэширования статического контента.
Apache работает с включенным mod_fast_cgi
Запросы отправляются на обработку с помощью серверного приложения на Python.
Приложение взаимодействует с различными базами данных и другими источниками информации для формирования финальной HTML-страницы.
Масштабирование обычно происходит просто добавлением дополнительных компьютеров.
Код на Python обычно не является узким местом системы, он проводит большую часть времени заблокированным RPC.
Python предоставляет быстроту и гибкость в процессе разработки и развертывания. Этот факт является очень актуальным, если учесть кто является их конкурентами.
На формирование страницы обычно уходит не более 100 миллисекунд.
psyco, динамический компилятор Python → C, использует JIT подход к компилированию для оптимизации внутренних циклов
Для интенсивных вычислений, таких как шифрование, используются расширения, написанные на C.
Какая-то часть заранее сгенерированного HTML хранится в кэше.
Кэширование данных в СУБД на уровне строк.
Кэшируются полностью сформированные объекты Python.
Некие данные вычисляются и отправляется каждому серверу для кэширования в локальной оперативной памяти. Эта стратегия годится далеко не всегда, чаще всего более эффективен другой метод: самым быстрым кэшем является само серверное приложение, а отправка уже готовых данных остальным серверам для дальнейшей обработки обычно не занимает так много времени. Для организации такого подхода необходимы агенты, осуществляющие отслеживание изменений, предварительную обработку и отправку данных.

Управление видео

Издержки включают в себя затраты на пропускную способность каналов связи, приобретение нового оборудования и оплату огромных счетов за электроэнергию.
Каждый видеоролик расположен на мини-кластере, что означает управление работой с ним группой из нескольких компьютеров.
Использование кластеров влечет за собой: – увеличение производительности пропорционально количеству дисков, на которых расположен контент; – возможность поддержания функционирования всей системы даже в случае прекращения работоспособности части компьютеров; – возможность организации создания резервных копий online.
В роли HTTP-сервера для работы с видео используется lighttpd: – Он способен дать фору Apache в плане производительности предоставления статического контента; – Для работы с событиями ввода-вывода используется epoll; – Многопоточная конфигурация способна обрабатывать большее количество соединений одновременно;
Самая популярная часть контента размещается в CDN – CDN реплицирует весь контент в разных частях системы; – Компьютеры CDN в основном предоставляют данные напрямую из кэша в оперативной памяти, так как ассортимент популярного видео с течением времени меняется достаточно медленно.
Менее популярный контент, количество просмотров в день которого варьируется в диапазоне от одного до двадцати, обычно размещается на серверах YouTube, расположенных в датацентрах на colocation: – Не смотря на тот факт, что такое видео может быть просмотрено всего несколько раз за день, количество таких роликов велико, что приводит к случайным блокировкам данных на жестких дисках; – В такой ситуации кэширование практически бесполезно, инвестиции в кэширование контента с низкой вероятностью востребованности обычно является пустой тратой средств; – Более детальная настройка низкоуровневых компонентов системы, таких как, например, RAID-контроллеры, в этой ситуации может достаточно положительно повлиять на производительность; – Выбор оптимального размера оперативной памяти на каждой машине также очень важен: как недостаточное, так и излишнее ее количество не являются эффективными решениями.

Ключевые моменты

Чем проще - тем лучше;
Старайтесь минимизировать количество устройств (маршрутизаторов, коммутаторов и тому подобных) между контентом и пользователями: далеко не факт, что все они будут способны выдерживать интенсивную нагрузку;
Старайтесь использовать самое обыкновенное оборудование. Hi-end оборудование обычно влечет за собой рост издержек, связанных с сопутствующими процессами, например технической поддержкой, а также уменьшает вероятность нахождение решения той или иной проблемы с оборудованием в Сети;
Используйте самые простые распространенные утилиты. YouTube использует идущий в комплекте с Linux набор утилит для построения системы именно на их основе;
Не забывайте о случайных доступах к жестким дискам, эту, казалось бы, мелочь тоже стоит настроить.

Управление миниатюрами видео

На удивление сложно решаемая задача, особенно если необходима эффективность;
Для каждого видео хранится 4 миниатюры, что приводит к существенному преобладанию количества миниатюр над количеством видеороликов;
Миниатюры хранятся всего на нескольких компьютерах;
Некоторые проблемы наблюдаются в связи с работой с большим количеством маленьких объектов: – Проблемы на уровне операционной системы, связанные с большим количеством запросов на поиск данных, а также кэшем страниц и inode'ов файловой системы; – Ограничение на количество файлов в одной директории (особенно актуально для ext3), возможно частичное решение в виде перехода к более иерархической структуре хранения данных, а также переходе к ядру Linux версии 2.6, что может привести к более чем стократному росту производительности, но в любом случае хранение такого огромного количества файлов в локальной файловой системе - не самая лучшая идея; – Большое количество запросов в секунду, так как одна страница может содержать до 60 миниатюр различных видеороликов; – В условиях таких нагрузок Apache показывает плохую производительность; – Проводились эксперименты с использованием squid (обратной proxy) между Apache и посетителями. Какое-то время такой вариант казался работоспособным, но с ростом нагрузки производительность начала падать. С обработки 300 запросов в секунду она упала до 20; – Попытки использовать lighttpd также не завершились успехом: однопоточный режим не справлялся с задачей, а многопоточный требовал отдельного кэша для каждого потока, что сводило на нет его эффективность; – С таким количеством изображений добавление в систему нового компьютера могло занимать более 24 часов; – Перезагрузка занимала 6-10 часов, так как кэш должен был "разогреться" прежде чем перестать использовать данные с жестких дисков.
Решением всех описанных выше проблем стала распределенная система хранения данных BigTable от Google: – Она позволяет избежать проблем, связанных с большим количеством файлов, так как объединяет маленькие файлы вместе. – Она работает быстро и устойчива к сбоям, помимо этого она прекрасно приспособлена для работы по ненадежной сети. – Уменьшает задержки, так как использует распределенный многоуровневый кэш, который способен работать даже между удаленными датацентрами.

Базы данных

Раньше: – MySQL использовалась для хранения данных: пользователей, тэгов, описаний и так далее. – Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков; – Оборудование арендовалось, что негативно сказывалось на состоянии их кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день. – Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре. – Поначалу их система страдала от задержек, связанных с реплицированием. Основной сервер, обрабатывающий операции записи, являлся мощным сервером, работающим в многопоточном режиме, это было необходимо для своевременного выполнения большого объема работы. Второстепенные сервера, которые обрабатывали только операции чтения, асинхронно реплицировали данные в одном потоке, что влекло за собой возможность серьезного отставания некоторых из них. – Обновления были причиной частого отсутствия необходимой информации в кэше, что заставляло сервера читать данные с жестких дисков. Этот факт сильно замедлял процесс чтения и репликации. – Реплицирующая архитектура требует немалых вложений в оборудование, необходимого для поддержания постоянно растущих темпов записи информации. – Основным из кардинальных решений, принятых в архитектуре системы было отделение обеспечения процесса просмотра видео от основного кластера. Основной целью посетителей является просмотр видео, а второстепенные задачи можно возложить и на менее производительный кластер.
Сейчас: – Используются распределенные базы данных; – Сегментированная система (прим.: по аналогии с Flickr); – Распределенные чтение и запись; – Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками; – Такая архитектура привела к 30%-й экономии на оборудовании; – Задержки в реплицировании сведены к нулю; – Размеры базы данных могут расти практически неограниченно

Стратегия размещения в датацентрах

Поначалу использовались хостинг провайдеры, предоставляющие услуги colocation. Не самый экономичный подход, но тогда не было другого выхода.
Хостинг провайдеры не могут поспеть за темпами роста проекта. Не всегда получается получить контроль над необходимым оборудованием или сделать необходимые соглашения о предоставлению сетевых услуг.
Решением этой проблемы стало создание собственной базы для размещения оборудования. Появилась возможность настраивать абсолютно все и подписывать свои собственные контракты такого рода.
Было использовано 5 или 6 разных датацентров в дополнение к CDN.
Видео поступает из случайного датацентра, никаких специальных проверок не проводится. Если ролик становится достаточно популярным - он перемещается в CDN.
Основным фактором, влияющим на доступность того или иного ролика является пропускная способность канала связи.
Для изображений же более актуальны задержки, особенно если на одной страницы должно быть размещено под 60 изображений.
Репликация изображений производится средствами BigTable. В этом случае используются различные меры для определения ближайшего места, откуда можно получить необходимые данные.

Подводим итоги

Остановитесь на секунду. Креативные и рискованные трюки могут помочь справиться с задачей в краткосрочном периоде, но со временем понадобятся более продуманные решения.
Расставьте приоритеты. Определите какие части Вашего сервиса являются более важными и стройте систему обеспечения ресурсами и усилиями именно в соответствии с поставленными приоритетами.
Выбирайте свои битвы. Не бойтесь пользоваться аутсорсингом в некоторых ключевых сервисах. YouTube использует CDN для распределения своего наиболее популярного контента. Создание своей собственной подобной сети стоило бы им слишком много и потребовало бы слишком много времени. Возможно у Вас появятся подобные возможности в отношении Вашей системы.
Будьте проще! Простота позволяет изменять архитектуру более быстро, что позволяет своевременно реагировать на возникающие проблемы. Никто на самом деле не знает что такое простота, но если Вы не боитесь делать изменения, то это неплохой знак что вашей системе свойственна та самая простота.
Сегментирование. Сегментирование позволяет изолировать и ограничить дисковое пространство, процессорное время, оперативную память и ввод-вывод. Оно выполняется не только для повышения производительности операций записи.
Постоянная работа над поиском и устранением узких мест в системе: – на программном уровне это чаще всего бывает кэширование и работа с СУБД; – на уровне операционной системы - операции ввода-вывода; – на уровне оборудования - оперативная память и RAID массивы.
Залог Вашего успеха - командная работа. Хорошая команда разного рода специалистов должна понимать принцип системы вцелом и того, что лежит под ней. Каждый должен знать свое дело: настраивать принтеры, подключать к системе новые компьютеры, строить сети и так далее. С отличной командой Вам по силам все что угодно.

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

В отличии от остальных, этот перевод статьи от Todd Hoff'а уже был выполнен до меня (при желании можно найти в любой поисковой системе), но я все равно решил опубликовать свою версию просто для собственного развития и полноты коллекции, да и многим читателям, возможно, покажется интересным. Что ж, перейдем к источнику информации оригинала:

Google Video

Веб-сервер за два вечера

Иван Блинков — Thu, 14 Feb 2008 15:59:00 +0300

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

Но, к счастью, времена меняются, и на сегодняшний день покупка даже серверного оборудования связана с достаточно скромными затратами, сопоставимыми с бюджетом покупки настольного компьютера или ноутбука. Но возникает другой вопрос - а что же с этим оборудованием делать? Вполне логичным ответом было бы: "использовать по прямому назначению", о чем мы с Вами сегодня и поговорим в компании с замечательным персонажем по имени 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 нашего сервера, настроить почту, закончить работу над самим веб-приложением и много чего еще, но это уже совсем другая история.