1.
ПРОПАТЧИЛ
GLIBC???
CVE-2015-0235
GHOST

2.
Колёса
Раньше и сейчас
2011 — 2015

3.
Кто здесь?
● Максим, администратор серверных систем
● Отвечаю за производительность
● Состою в скромной команде архитекторов
● Холю и лелею инфраструктуру
До Колёс:
● много VoIP’а на цисках и линуксах
● линуксы дома, на работе, в отпуске…

4.
2011 год
● 3 разработчика
● 0 админов (аутсорс)
● ~ 12 серверов-десктопов
● 4.5М просмотров
● 260k визитов

5.
9 миллионов
4 сервера:
● 2 процессора
● 48 Гб ОЗУ
Хранилка:
● 12 дисков
● 12 ТБ (RAID10)
Адская избыточность, высокая надежность, расширяемость,
управляемость, печеньки!

6.
2011 год (уиии, блэйд!)
● 3 разработчика
● 0 админов (аутсорс)
● 4 блэйд-сервера
● 5.6M просмотров
● 270к визитов

7.
2012 год, начало
● 3 разработчика
● 1 админ (ура!)
● 4 блэйд-сервера
● ~15 контейнеров OpenVZ
● одна плоская сеть /24

8.
Знаменитая трёхзвенная (плюшки)

9.
OpenVZ
Плюсы:
● быстрый
● дерзкий
● как пуля резкий
● 1-3% накладных расходов
● простой, как палка

10.
OpenVZ
Минусы:
● одно ядро на всех
● «хитрое» управление памятью (MongoDB и JVM передают
привет!)
● ФС для контейнеров
● видимость ограничена
● постоянные танцы с бубном вокруг user_beancounters

11.
KVM
Плюсы:
● полная изоляция ВМ друг от друга и от хоста
● MongoDB и JVM улыбаются и пляшут
● быстрая работа с диском
● видимость всех ресурсов ВМ
● virtio, vhost_net, KSM

12.
KVM
Минусы:
● сложный
● теоретически медленнее, чем OpenVZ
(аппаратная виртуализация спасает)
● мало опыта администрирования и отладки

13.
OpenVZ, давай, до свидания!
● Несколько недель не спим
● Переносим контейнеры в ВМ
● …
● PROFIT!
P.S. До сих пор KVM ни разу не становился настолько
узким местом, чтобы хотелось от него отказаться.

14.
Proxmox VE (proxmox.com)
● кластер KVM-серверов
● multimaster
● CLI
● web
● HA
● API

15.
Немного про overprovisioning
Он же оверселлинг, он же оверсабскрайбинг, он же
большая радость хостера и засада клиента:
● позволяет продать больше, чем имеешь
● провоцирует «драку» за ресурсы
● распределение ресурсов становится
«тяжелой», но приоритетной задачей
● совершенно нам не подходит

16.
Блэйд-система в Колёсах

17.
Почему же?
● большая коробка — половину в другой ЦОД не
отпилишь
● аренда места в ЦОД стоит космических денег
● заполненность на 25% экономически невыгодна
● сэкономили на сетевой части
● недешевый бренд

18.
Наш выбор — Supermicro Twin²
● один такой заменит блэйд
● компактный
● производительный
● в 4 раза меньше
● в 2 раза дешевле
● недорогой бренд
● даже с учётом электричества, аренда обходится
дешевле

19.
GlusterFS
● как NFS, только от Red Hat
● плюшки в виде репликации
● и распределенности
● которые никто не заюзал
● ибо хранилище было одно
● в самом низу — родная ФС (ext3/4, xfs)

20.
Что лежало на хранилке
Объявления:
/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-го

21.
Цифры
● 10M объявлений
● ~ 10М файлов data.xml
● ~ 40М каталогов для фото
● ~ 160M файлов *.jpg
● ~ 200М объектов
● ~ 50-60 Гб метаданных

22.
И чо?
подумаешь, много файлов…

23.
fsck you
вот чо

24.
Проблема
Задержки:
● HDD
● сетевая ФС
● ФС как структура вообще
● множественный доступ (кэш не спасёт)
● бэкап данных за неделю длится неделю

25.
Решение для объявлений
● Никаких каталогов
● Никаких файлов
● Вкусный JSON вместо XML
● Репликация
● Резервное копирование (с бубном)

26.
В итоге
● драматическое падение задержек
● катастрофический прирост производительности
● ещё два года Колёса живут без шардинга

27.
Решение для фотографий
● храним объекты
● намного меньше метаданных
● доступ по HTTP
● nginx для кэша и HTTPS
● распределенная система
● избыточно (3 копии данных)
● задержки по-прежнему высоковаты :(

28.
Цифры (Swift vs Хранилка)
● стоимость: 30% старой системы
● расходы: на 20% выше
● тройная избыточность
● защита от сбоев
● распределенность

29.
Миграция
1. поднимаем новую систему
2. включаем запись в обе системы
3. запускаем перенос данных из старой в новую
систему
4. начинаем читать с новой системы
5. дожидаемся окончания переноса
6. ждём «на всякий случай»
7. отключаем старую систему

30.
Фотографии (сейчас)
● 2к запросов/сек
● 260 Мбит/сек
● 220 ГБ кэш (memcached)
● кэш спасает, но продолжаем ускоряться
● SSD для метаданных

31.
2013 год
● 5-8 разработчиков
● 1 админ
● 1 тестировщик!
● ~ 150 ВМ
Колёса:
● 8.2М просмотров
● 450k визитов
Крыша:
● 1.8М просмотров
● 114к визитов

32.
2013 …
● появились мобильные приложения
● доросли до конца года до 1.5М просмотров и
120к визитов
● масштабируемся каждый день
● все хотят в API, а API всех ненавидит
● присутствуем в двух ЦОДах

33.
Оптимизация
Постоянные «фоновые» задачи:
1. найти узкое место
2. всё переделать
3. перейти к шагу 1

34.
Немного уже не узких мест
● CDN для фотографий и статики
○ два ЦОДа
○ балансировка на уровне DNS
● загрузка фото
○ кэш для свежезагруженных изображений
○ фоновый перенос в Swift
● жесткие диски
○ SSD уже не дорого
○ и очень быстро

35.
Автоматизация
● серверов всё больше
● конфигурации всё изощрённее
● зависимость A->B->C->D->A
● нужно же что-то делать, Петька!

36.
Chef
● сервер управления конфигурацией
● для всех *nix
● пишем рецепты, а оно их исполняет
● только там, где нужно
● попутная инвентаризация
● только pull
● пришлось учить ruby
● программисты смеялись :(

37.
Примеры
● добавлять все новые серверы в мониторинг
● установить nginx на серверы группы web
● найти все серверы, с драйвером e1000 и
наложить патч

38.
Плюшки
● NTP
● IPv6
● SPDY

39.
2014-2015
● 11 разработчиков
● 5 тестировщиков
● 2 админа (ура! ура!)
● ~ 520 ВМ
Сайты:
● 11.5М просмотров
● 660к визитов
Мобильные приложения:
● 7.5М просмотров
● 250k визитов

40.
Что дальше?
● вчерашние паттерны уже антипаттерны
● на горизонте маячит HTTP2
● оптимизация под dial-up снова в моде
● только теперь 1080p и 4K
● зато даже в самолёте

41.
Вопросы?
Максим Кравец
администратор серверных систем
ТОО «Колёса»
zeelax@gmail.com
skype: zeelax

42.
Спасибо!