ПРОПАТЧИЛGLIBC???
CVE-2015-0235
GHOST
КолёсаРаньше и сейчас
2011 — 2015
Кто здесь?
● Максим, администратор серверных систем● Отвечаю за производительность● Состою в скромной команде архитекторов● Холю и лелею инфраструктуруДо Колёс:
● много VoIP’а на цисках и линуксах● линуксы дома, на работе, в отпуске…
2011 год
● 3 разработчика● 0 админов (аутсорс)● ~ 12 серверов-десктопов● 4.5М просмотров● 260k визитов
9 миллионов4 сервера:● 2 процессора● 48 Гб ОЗУХранилка:● 12 дисков● 12 ТБ (RAID10)Адская избыточность, высокая надежность, расширяемость, управляемость, печеньки!
2011 год (уиии, блэйд!)
● 3 разработчика● 0 админов (аутсорс)● 4 блэйд-сервера● 5.6M просмотров● 270к визитов
2012 год, начало
● 3 разработчика● 1 админ (ура!)● 4 блэйд-сервера● ~15 контейнеров OpenVZ● одна плоская сеть /24
Знаменитая трёхзвенная (плюшки)
OpenVZ
Плюсы:● быстрый● дерзкий● как пуля резкий● 1-3% накладных расходов● простой, как палка
OpenVZМинусы:
● одно ядро на всех● «хитрое» управление памятью (MongoDB и JVM передают
привет!)● ФС для контейнеров● видимость ограничена● постоянные танцы с бубном вокруг user_beancounters
KVMПлюсы:
● полная изоляция ВМ друг от друга и от хоста● MongoDB и JVM улыбаются и пляшут● быстрая работа с диском● видимость всех ресурсов ВМ● virtio, vhost_net, KSM
KVM
Минусы:● сложный● теоретически медленнее, чем OpenVZ
(аппаратная виртуализация спасает)● мало опыта администрирования и отладки
OpenVZ, давай, до свидания!● Несколько недель не спим● Переносим контейнеры в ВМ● …● PROFIT!
P.S. До сих пор KVM ни разу не становился настолько узким местом, чтобы хотелось от него отказаться.
Proxmox VE (proxmox.com)
● кластер KVM-серверов● multimaster● CLI● web● HA● API
Немного про overprovisioning
Он же оверселлинг, он же оверсабскрайбинг, он же большая радость хостера и засада клиента:
● позволяет продать больше, чем имеешь● провоцирует «драку» за ресурсы● распределение ресурсов становится
«тяжелой», но приоритетной задачей● совершенно нам не подходит
Блэйд-система в Колёсах
Почему же?
● большая коробка — половину в другой ЦОД не отпилишь
● аренда места в ЦОД стоит космических денег● заполненность на 25% экономически невыгодна● сэкономили на сетевой части● недешевый бренд
Наш выбор — Supermicro Twin²● один такой заменит блэйд● компактный● производительный● в 4 раза меньше● в 2 раза дешевле● недорогой бренд● даже с учётом электричества, аренда обходится
дешевле
GlusterFS
● как NFS, только от Red Hat● плюшки в виде репликации● и распределенности● которые никто не заюзал● ибо хранилище было одно● в самом низу — родная ФС (ext3/4, xfs)
Что лежало на хранилкеОбъявления:
/mnt/data/live/0007/654/321/data.xml
Фотографии:
/mnt/data/live/0007/654/321/photos/1/60x45.jpg
/mnt/data/live/0007/654/321/photos/1/120x90.jpg
/mnt/data/live/0007/654/321/photos/1/400x300.jpg
/mnt/data/live/0007/654/321/photos/1/full.jpg
~ 2 ТБ данных к середине 2012-го
Цифры
● 10M объявлений● ~ 10М файлов data.xml● ~ 40М каталогов для фото● ~ 160M файлов *.jpg
● ~ 200М объектов● ~ 50-60 Гб метаданных
И чо?подумаешь, много файлов…
fsck youвот чо
Проблема
Задержки:● HDD● сетевая ФС● ФС как структура вообще● множественный доступ (кэш не спасёт)● бэкап данных за неделю длится неделю
Решение для объявлений
● Никаких каталогов● Никаких файлов● Вкусный JSON вместо XML● Репликация● Резервное копирование (с бубном)
В итоге
● драматическое падение задержек● катастрофический прирост производительности● ещё два года Колёса живут без шардинга
Решение для фотографий
● храним объекты● намного меньше метаданных● доступ по HTTP● nginx для кэша и HTTPS● распределенная система● избыточно (3 копии данных)● задержки по-прежнему высоковаты :(
Цифры (Swift vs Хранилка)
● стоимость: 30% старой системы● расходы: на 20% выше● тройная избыточность● защита от сбоев● распределенность
Миграция1. поднимаем новую систему2. включаем запись в обе системы3. запускаем перенос данных из старой в новую
систему4. начинаем читать с новой системы5. дожидаемся окончания переноса6. ждём «на всякий случай»7. отключаем старую систему
Фотографии (сейчас)
● 2к запросов/сек● 260 Мбит/сек● 220 ГБ кэш (memcached)● кэш спасает, но продолжаем ускоряться● SSD для метаданных
2013 год● 5-8 разработчиков● 1 админ● 1 тестировщик!● ~ 150 ВМ
Колёса:● 8.2М просмотров● 450k визитов
Крыша:● 1.8М просмотров● 114к визитов
2013 …
● появились мобильные приложения● доросли до конца года до 1.5М просмотров и
120к визитов● масштабируемся каждый день● все хотят в API, а API всех ненавидит● присутствуем в двух ЦОДах
Оптимизация
Постоянные «фоновые» задачи:1. найти узкое место2. всё переделать3. перейти к шагу 1
Немного уже не узких мест● CDN для фотографий и статики
○ два ЦОДа○ балансировка на уровне DNS
● загрузка фото○ кэш для свежезагруженных изображений○ фоновый перенос в Swift
● жесткие диски○ SSD уже не дорого○ и очень быстро
Автоматизация
● серверов всё больше● конфигурации всё изощрённее● зависимость A->B->C->D->A● нужно же что-то делать, Петька!
Chef● сервер управления конфигурацией● для всех *nix● пишем рецепты, а оно их исполняет● только там, где нужно● попутная инвентаризация● только pull● пришлось учить ruby● программисты смеялись :(
Примеры
● добавлять все новые серверы в мониторинг● установить nginx на серверы группы web● найти все серверы, с драйвером e1000 и
наложить патч
Плюшки
● NTP● IPv6● SPDY
2014-2015● 11 разработчиков● 5 тестировщиков● 2 админа (ура! ура!)● ~ 520 ВМ
Сайты:
● 11.5М просмотров● 660к визитов
Мобильные приложения:
● 7.5М просмотров● 250k визитов
Что дальше?
● вчерашние паттерны уже антипаттерны● на горизонте маячит HTTP2● оптимизация под dial-up снова в моде● только теперь 1080p и 4K● зато даже в самолёте
Вопросы?
Максим Кравецадминистратор серверных системТОО «Колёса»[email protected]: zeelax
Спасибо!