Проект москва.ком представял из себя главный городской портал Москвы. С посещамостью 100к-300к хостов в день.
Используемые технологии Debian Linux (etch), Nginx 0.4-0.6, Apache 2.X, PHP 5, MySQL 5.0, Memcache, Xdebug, DRBD.
Теперь по порядку
Изначально сайт работал на 3-х серверах, каждый из которых выполнял свою роль, frontend, backend, database + backups, для организации fail-over решения, этого было недостаточно, точнее fail-over решение вообше отсутствовало в каком либо виде. По скольку планировалось обслуживать большой трафик посетителей, было решено пересмотреть мощности и реализовать highload и failover систему.
Hardware
Было приобретено:
- 2 x Dell SC1435 (2 x Duo Core AMD 2200Mhz / 2GB RAM / 70GB SATA) Спецификация
- 4 x Dell PowerEdgeTM 2950 (4 x Core Duo Intel(R) Xeon(TM) MP CPU 3.16GHz / 16GB RAM / 300GB SCSI) Спецификация
-
2 x SuperMicro (4 x Intel(R) Xeon(R) CPU 5130 @ 2.00GHz / 3GB RAM / 16 x 750GB SCSI Дисков + RAID 50 / 60 )
- 2 x KVM ALTUSEN 16 ports
- 2 x POWER CONTROL ALTUSEN 16 ports
Всего получилось 10 серверов и еще один маршрутизатор cisco express 500, и все это железо предстояло подключить и настроить. подробнее об этом дальше.
Highload n Failover
10 делились на 3 логические группы (уровни):
На каждом уровне было как минимум 2 сервере, для обеспечения отказоустойчивости 99,9% (3 уровень отказоустойчивости)
1. Уровень Loadbalance и статический контент
Это балансировщик нагрузки, в качестве которого выступал nginx(тогда еще версии 0.3) и failover демон heartbeat который следил за серверами и в случае отказа, переключал нагрузку на доступный сервер.
2. Уровень Backend workers and database
На этом уровене было 4 сервера. 2 из которых были чистыми application серверами на apache для php, и принимали запросы только с первого уровня. 2 другие сервера это Mysql база данных с Master-Slave репликацией и резервным копированием со Slave
3. Уровень Storage
Два огромных сервер по 16 x 750GB SCSI дисков на каждом и RAID 50 итого на каждом получалось по 2ТБ хранилища. Но не все так просто, была задача обеспечить отказоустойчивость, то есть если один storage полетит надо было переключать на второй и встал вопрос, как при этом синхронизировать данные при больших обьемах, а это были пользовательские файлы, в основном видео и фотографии от 1MB до 1000MB. После всяких тестов, было принято решение использовать DRBD
Суть DRBD показан на этой картинке, вкратце это демон который в реалтайме синхронизирует диски, работет он на уровне драйвера
Вещь эта очень сложная, и на тот момент в первых версиях, нельзя было держать оба раздела смонтированным, смонтированным должен был быть только один раздел, поэтому на всякий случай имелся bash скрипт, который умел менять местами эти разделы.
Вот так выглядел эта отказоустойчивая система в процессе разработки. (На фото нет двух больших 4U Supermicro серверов)
Теперь собственно сама архитектура
Linux
- Был выбран стабильный дистрибутив Debian(Etch) Linux
- Проблемы возникли с несертифицированных железом, но проблемы исправимые, пришлось повозится с драйверами для SCSI контроллера обоих storage серверов
PHP
- Использовался потомучто “так исторически сложилось””
- Поначалу все работало быстро, при большой нагрузке понадобились оптимизаторы кода APC на тот момент был самым быстрым
- Отладка с помощью Xdebug
MySQL
- Очень плотное использование MySQL хранимые процедуры и триггеры
- Репликация помогла избежать dead locks, и смягчала нагрузку на сервисы которые работали с данными readonly
- Репликация не раз спасала при восстановлении данных
- Настройка и управление репликацие требует полного понимания просиходящего
- Постоянный мониторинг с помощью MyTop
Apache
- Использовался mod_rewrite
- Постоянный мониторинг server-status для выяснения проблем
Memcache
- Все что мало изменялось хранилось и часто использовалось в memcache
NFS
- Код хранился на одном сервер и распределялся на другие через NFS
- Также по NFS ходили большие пользовтельские данные video и фотографии, которые отдавались с первого уровня балансерами
- Правильно настроенный NFS отлично справлялся со своей задачей очень важно тонко настраивать такие вещи как NFS
Сеть
- Каждый сервер имел 2 x 1Gb карты чтобы обеспечивало безполезенную передачу данных с минимальной задержкой по локальной сети
Nginx
- Так обеспечивалась отдача статического контента, в частности изображений
location /p/ {
expires max;
add_header Cache-Control public;
if ($request_filename ~* ".*\.php") {
return 403;
}
if (!-f $request_filename)
{
break;
proxy_pass http://backend-grp-1;
}
}KVM и Powerswitch
- Огромную роль сыграло дополнительно железо в частности KVM и PowerSwitch, с помошью KVM нераз удавалось удаленно установить проблемы в датацентре по вине провайдера, в частности проблемы маршрутизации из-за которых нероботал сайт.
Итого
Все работало, стабильно,всего пришлось 2 раза восстанавливать базу данных, один раз по случайсти один из разработчиков удалил таблица, второй раз из-за MyISAM corruption. DRBD переключение зеркала, также пришлось использовать один раз, но только для проверки накопившехся данных и для того чтобы сделать с него бекап на отдельный диск. Сильно помогла поддержка KVM и Powercontrol, позволял понять что неисправно и заходить в bios RAID контроллеров.
Comments powered by Talkyard.