В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
Similar a Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine / Дмитрий Самсонов (Одноклассники)
Илья Кудинов «Развитие процессов тестирования в Badoo за три года, или как мы...WrikeTechClub
Similar a Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine / Дмитрий Самсонов (Одноклассники) (20)
Java и Linux — особенности эксплуатации / Алексей Рагозин (Дойче Банк)
Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine / Дмитрий Самсонов (Одноклассники)
1. Как не положить тысячи
серверов с помощью системы
централизованного управления
конфигурацией на примере
CFEngine
Дмитрий Самсонов
2. Дмитрий Самсонов
Ведущий системный администратор в OK.RU
Компетенция:
● Zabbix
● CFEngine
● Linux tuning
dmitry.samsonov@odnoklassniki.ru
https://www.linkedin.com/in/dmitrysamsonov
6. Разоблачение
Я предвзят
У меня есть опыт использования CFEngine только версии 3.3.x-3.4.x
CFEngine не лидер и не аутсайдер рынка
7. Разоблачение
Я предвзят
У меня есть опыт использования CFEngine только версии 3.3.x-3.4.x
CFEngine не лидер и не аутсайдер рынка
Я не буду сравнивать configuration management на сегодняшний день
8. Разоблачение
Я предвзят
У меня есть опыт использования CFEngine только версии 3.3.x-3.4.x
CFEngine не лидер и не аутсайдер рынка
Я не буду сравнивать configuration management на сегодняшний день
У меня есть опыт использования только CFEngine и Ansible
16. dssh-command
# cqn feeds-portlet-cdb | dssh-command -t 300 "hostname"
How much is 5 + 8 = 13
Correct
srvd1352:O:0:srvd1352
Executing: "hostname"
Do you want to execute the command on servers in DL? [Yes/No]: Yes
srvd1353:O:0:srvd1353
17. dssh-command
# cqn feeds-portlet-cdb | dssh-command -t 300 "hostname"
How much is 5 + 8 = 13
Correct
srvd1352:O:0:srvd1352
Executing: "hostname"
Do you want to execute the command on servers in DL? [Yes/No]: Yes
srvd1353:O:0:srvd1353
Executing: "hostname"
Do you want to execute the command on servers in M100? [Yes/no]: Yes
srve1993:O:0:srve1993
srve2765:O:0:srve2765
...
Full output saved in /tmp/dsshFullOutput_29606_2016-10-14_13-17.log
file.
19. Как мы выбирали и что выбрали в 2012
● Интеграция с CMDB
● Установка пакетов
● Работа с файлами (копирование/редактирование/атрибуты)
● Контроль файлов (содержимое/атрибуты)
● Управление процессами и сервисами
● Ручной запуск политик
● Контроль версий, логирование изменений, отчеты
● Масштабирование, резервирование
● Поддержка Linux и Windows
● Проверка на наличие серверов без работающего CM
22. Как мы выбирали и что выбрали в 2012
● Производительность
● Зрелость
23. Современная история CM
“A theory of configuration maintenance was worked out by Mark Burgess with a practical implementation on present day computer systems in
the software CFEngine able to perform real time repair as well as preventive maintenance.”
https://en.wikipedia.org/wiki/Configuration_management#Operating_System_configuration_management
24. Как мы выбирали и что выбрали в 2012
● Зрелость
● Производительность
● Популярность
38. “В одну тихую весеннюю ночь, а именно с 4-
го на 5-ое апреля 2013-го года, ничто не
предвещало беды — юзеры непринуждённо
общались, грузили и комментили фоточки,
и собирали урожай, как вдруг всё ё***лось, и
что, с**а, характерно, обратно не
поднялось. Ни через час, ни через два, ни
через три. И даже не через 20 часов! … Что
это за централизованная система
управления, которая лёгким движением
руки позволяет отправить несколько
тысяч серверов в /dev/null, знают только её
разработчики…”
https://lurkmore.to/Одноклассники
39. Можно ли было избежать?
● Проверка синаксиса
● Тестовые окружения
● Ревью
● Мониторинг ошибок
42. Как мы работаем
1. Проверка в git hooks
2. Проверка в тестовом окружении
3. Проверка на части прод серверов с
автоматизированным контролем нагрузки
4. Ревью
5. Плавное распространение по проду
45. GIT hooks
● Проверка синтаксиса
● Автокоррекция стиля
● Автозаполнение и проверка commit message
46. Как мы работаем
1. Проверка в git hooks
2. Проверка в тестовом окружении
3. Проверка на части прод серверов с
автоматизированным контролем нагрузки
4. Ревью
5. Плавное распространение по проду
49. Как мы работаем
1. Проверка в git hooks
2. Проверка в тестовом окружении
3. Проверка на части прод серверов с
автоматизированным контролем нагрузки
4. Ревью
5. Плавное распространение по проду
52. Stable
● Прод сервера
● От каждого нового кластера
берётся один сервер
● Все варианты железа и
приложений
53. Stable
● Прод сервера
● От каждого нового кластера
берётся один сервер
● Все варианты железа и
приложений
● Потеря прозрачна для
пользователей
54. Stable
● Прод сервера
● От каждого нового кластера
берётся один сервер
● Все варианты железа и
приложений
● Потеря прозрачна для
пользователей
● Обновления плавно в течение
одного часа
55. Stable
● Прод сервера
● От каждого нового кластера
берётся один сервер
● Все варианты железа и
приложений
● Потеря прозрачна для
пользователей
● Обновления плавно в течение
одного часа
● Для серверов автоматически
контролируется нагрузка
56. Как мы работаем
1. Проверка в git hooks
2. Проверка в тестовом окружении
3. Проверка на части прод серверов с
автоматизированным контролем нагрузки
4. Ревью
5. Плавное распространение по проду
57. Ревью
Ревью политики:
1. Соблюдение style guide (большая часть проверяется pre-commit хуком в git)
2. “Адекватность” кода
3. Использование последних версий методов
4. …
58. Ревью
Соблюдение всех условий для продвижения в прод:
1. Нет ошибок выполнения
2. Нет проблем с нагрузкой
3. “Промариновалось”
60. Ещё пара слов про ревью
● Исключение - инциденты!
● Кто ревьювит?
61. Как мы работаем
1. Проверка в git hooks
2. Проверка в тестовом окружении
3. Проверка на части прод серверов с
автоматизированным контролем нагрузки
4. Ревью
5. Плавное распространение по проду
63. Production
● Поделен на независимые
части
● Каждая часть применяет
изменения равномерно в
течение часа
64. Production
● Поделен на независимые
части
● Каждая часть применяет
изменения равномерно в
течение часа
● Обновления работают только
с 8:00 до 20:00
65. Как мы работаем
1. Проверка в git hooks
2. Проверка в тестовом окружении
3. Проверка на части прод серверов с
автоматизированным контролем нагрузки
4. Ревью
5. Плавное распространение по проду
70. Это надо делать обязательно
● Тестировать в разных условиях
● Долго тестировать на части прода
● Делать ревью
● Распространять обновления в продакшене плавно и
поэтапно
● Иметь план на случай аварии
71. Спасибо за внимание!
● Блог Одноклассников на Хабре
http://habrahabr.ru/company/odnoklassniki/
● Больше о нас и наших докладах
http://v.ok.ru/
Дмитрий Самсонов
dmitry.samsonov@odnoklassniki.ru
https://www.linkedin.com/in/dmitrysamsonov