Главная → Тезисы и презентации Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование Доклад принят в Программу конференции Никита Духовный Одноклассники Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование. Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала. Тезисы Проект Одноклассники начинал свою жизнь в одном датацентре. С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы: - Ни один, даже самый мощный, сервер больше не справляется в одиночку. - Нагрузка растёт, а в датацентре нет места для нового оборудования. - Падение датацентра безоговорочно приводит к даунтайму. - Сетевой сбой выводит портал из строя. - Пользователи в удалённых регионах страдают от низкой скорости. Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем: - CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях. - Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними. - Сеть - как и до чего мы балансируем трафик. - Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик. - Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.

1. Балансировка нагрузки
и отказоустойчивость в
Одноклассниках
Никита Духовный

2. Никита Духовный
• Ведущий системный администратор

3. Инфраструктура Одноклассников
• >11000 физических серверов
• 3 основных дата-центра
• CDN
• >1 Tbps внешнего трафика

4. Системный администратор в
Одноклассниках
• Системы автоматизации
• Исследовательская работа
• Помощь разработчикам

5. Балансировка нагрузки и
отказоустойчивость на примере
Одноклассников

6. На заре проекта
1. www.odnoklassniki.ru
2. redirect
3. wg13.odnoklassniki.ru
• Имя привязано к серверу

7. На заре проекта
• Недостатки
• Отказ сервера
• Имя добавлено в закладки
• Что-то нужно менять

8. Балансировщики нагрузки
• IP + port = Layer 4 балансировка
• Опции
• Проприетарные
• LVS

9. Балансировщики нагрузки
• IP + port = Layer 4 балансировка
• Опции
• Проприетарные
• LVS
• Выбор - LVS

10. LVS
•

11. LVS
•

12. LVS
•

13. Управление LVS
• ldirectord
• Добавляет сервера в таблицу LVS
• Проверяет реальные сервера
• Корректирует таблицу LVS

14. • ldirector - однопоточный
• Проблема
• 200 web
• 5 секунд timeout
• Вывод половины - более 8 минут
Управление LVS

15. Управление LVS
• ok-lvs-monitor
• Многопоточность проверок
• Интегрирован с системой конфигурации
портала

16. LVS - патчи
• расхождение между master и standby
• sync - на core0
• sync >50% CPU Usage на standby
• ipvsadm не различал Active/InAct

17. LVS и persistence
• Для чего нам persistence
• LVS - по client IP
• Мобильный оператор Армении - с
нескольких IP
• mobile-web - неравномерно нагружены

18. Балансировщик для мобильной
версии
• Persistence по cookie
• Layer 7

19. Балансировщик для мобильной
версии
• Persistence по cookie
• Layer 7
• HAProxy

20. HAProxy

21. HAProxy

22. HAProxy

23. HAProxy

24. HAProxy

25. HAProxy
• Балансировщик за балансировщиком?

27. HAProxy
• Почему бы и нет:
• LVS: 45 мастеров, 600 Mbit каждый
• HAProxy: 36 серверов, 70 Mbit каждый
• Почему да:
• Малый вес после реконфигурации
• Оценить
• Применить везде

28. Аварии в дата-центре

29. Аварии в дата-центре
• Сгорела и основная, и резервная оптика

30. Аварии в дата-центре
• Сгорела и основная, и резервная оптика
• Стала плавиться изоляция
электропитания

31. Аварии в дата-центре
• Сгорела и основная, и резервная оптика
• Стала плавиться изоляция
электропитания
• Крыша прилетела на систему
охлаждения

32. Аварии в дата-центре
Проект должен работать в случае отказа
любого дата-центра!

33. Системы хранения данных
• СХД осведомлены о дата-центрах
• Replication factor = 3
• Quorum = 2

34. Frontend и дата-центры
• В 3 дата-центрах
• Запас мощности
• 3 IP адреса

35. GSLB DNS
• Автоматическая обработка аварии
• Проверка
http:path=/getstatus;method=head;on=20/20;
off=10/20;timeout=3000
• За 5 минут переходят 80% пользователей

36. Сеть

37. Сеть

38. Сеть

39. Сеть

40. Сеть

41. Сеть

42. Сеть

43. Сеть

44. Тяжёлый контент
• Видео, музыка, фотографии
• Плохие интернеты
• Медленный зарубежный трафик
• Нестабильное соединение
• Узкий канал

45. CDN
• Сервера близко к пользователю
• Кеширование контента

46. CDN - IP Anycast

47. CDN - IP Anycast
• Плюсы
• Автономность
• Минусы
• Нет прямого контроля
• Неожиданный переход на другую площадку

48. CDN - DNS

49. CDN - DNS

50. CDN - DNS

51. CDN - DNS

52. CDN - DNS
• IP-based geolocation
• Плюс
• высокий контроль
• Минус
• Физически близко != лучший сетевой путь
• Не учитывают изменений в топологии

53. CDN - Одноклассники
• Проекты “Трафик до ОК - бесплатно”
• Отправляем на площадку только сети
партнёра
• Обычные решения - не подходят

54. CDN - Одноклассники

55. CDN - Одноклассники

56. CDN - Одноклассники

57. CDN - Одноклассники

58. CDN - Одноклассники

59. CDN - Одноклассники

60. CDN - Одноклассники

61. CDN - Одноклассники

62. CDN - Одноклассники

63. CDN - Одноклассники

64. CDN - Одноклассники

65. CDN - Одноклассники

66. CDN - Одноклассники

67. CDN - Одноклассники
• In-house
• Контент - с соседней ноды
• nginx

68. Будущее

69. 1 IP
• Прозрачный отказ дата-центра
• 100% решение проблем с DNS cache
• Устранение лишних переходов между
дата-центрами

70. Userspace Layer 4 load balancers
• Отсутствие переходов между user space и
kernel space
• Лёгкий сетевой стек
• Очень быстро (по слухам :) )!

71. Спасибо!
https://v.ok.ru/vacancies.html
https://v.ok.ru/publishing.html
nikita.dukhovny@corp.mail.ru
• 7 ноября, 18:00 - “Как не положить тысячи серверов
с помощью системы централизованного
управления конфигурацией на примере CFEngine”