Successfully reported this slideshow.
Your SlideShare is downloading. ×

Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine / Дмитрий Самсонов (Одноклассники)

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 71 Ad

Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine / Дмитрий Самсонов (Одноклассники)

Download to read offline

В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.

В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.

В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.

В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine / Дмитрий Самсонов (Одноклассники) (20)

More from Ontico (20)

Advertisement

Recently uploaded (20)

Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine / Дмитрий Самсонов (Одноклассники)

  1. 1. Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine Дмитрий Самсонов
  2. 2. Дмитрий Самсонов Ведущий системный администратор в OK.RU Компетенция: ● Zabbix ● CFEngine ● Linux tuning dmitry.samsonov@odnoklassniki.ru https://www.linkedin.com/in/dmitrysamsonov
  3. 3. Одноклассники >11000 серверов >150 приложений >600 кластеров
  4. 4. Разоблачение Я предвзят
  5. 5. Разоблачение Я предвзят У меня есть опыт использования CFEngine только версии 3.3.x-3.4.x
  6. 6. Разоблачение Я предвзят У меня есть опыт использования CFEngine только версии 3.3.x-3.4.x CFEngine не лидер и не аутсайдер рынка
  7. 7. Разоблачение Я предвзят У меня есть опыт использования CFEngine только версии 3.3.x-3.4.x CFEngine не лидер и не аутсайдер рынка Я не буду сравнивать configuration management на сегодняшний день
  8. 8. Разоблачение Я предвзят У меня есть опыт использования CFEngine только версии 3.3.x-3.4.x CFEngine не лидер и не аутсайдер рынка Я не буду сравнивать configuration management на сегодняшний день У меня есть опыт использования только CFEngine и Ansible
  9. 9. Классические средства конфигурации ● ssh + scp + winexe
  10. 10. Классические средства конфигурации ● ssh + scp + winexe ● dssh-command + dscp + dwinexe-command
  11. 11. Классические средства конфигурации ● ssh + scp + winexe ● dssh-command + dscp + dwinexe-command ● Образ OS (регулярные обновления)
  12. 12. dssh-command # cqn feeds-portlet-cdb | dssh-command -t 300 "hostname"
  13. 13. dssh-command # cqn feeds-portlet-cdb | dssh-command -t 300 "hostname" How much is 5 + 8 =
  14. 14. dssh-command # cqn feeds-portlet-cdb | dssh-command -t 300 "hostname" How much is 5 + 8 = 50, 100, 200...
  15. 15. dssh-command # cqn feeds-portlet-cdb | dssh-command -t 300 "hostname" How much is 5 + 8 = 13 Correct srvd1352:O:0:srvd1352
  16. 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. 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.
  18. 18. Сервера настроены неправильно
  19. 19. Как мы выбирали и что выбрали в 2012 ● Интеграция с CMDB ● Установка пакетов ● Работа с файлами (копирование/редактирование/атрибуты) ● Контроль файлов (содержимое/атрибуты) ● Управление процессами и сервисами ● Ручной запуск политик ● Контроль версий, логирование изменений, отчеты ● Масштабирование, резервирование ● Поддержка Linux и Windows ● Проверка на наличие серверов без работающего CM
  20. 20. Как мы выбирали и что выбрали в 2012 ● Производительность
  21. 21. Производительность 3000 клиентов
  22. 22. Как мы выбирали и что выбрали в 2012 ● Производительность ● Зрелость
  23. 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. 24. Как мы выбирали и что выбрали в 2012 ● Зрелость ● Производительность ● Популярность
  25. 25. Популярность CM
  26. 26. CFEngine в Одноклассниках
  27. 27. CFEngine может быть простым
  28. 28. Типичная политика настройки приложения "app_ok_feed" or => {"cmdb_group_feeds_proxy", “cmdb_group_feeds_cache}; ... bundle agent app_ok_feed { vars: "application" string => "ok-feed"; methods: "app_ok" usebundle => app_ok("$(application)"); }
  29. 29. Библиотека настройки приложений bundle agent app_ok(application) { vars: "file[/ok/bin/$(application)][policy]" string => "copy"; "file[/ok/bin/$(application)][mode]" string => "0755"; "file[/ok/conf/$(application).conf][policy]" string => "copy"; "file[/root/ok/ok.properties][policy]" string => "edit"; "file[/root/ok/ok.properties][suffix]" string => "$(application)"; "file[/root/ok/ok.properties][type]" string => "file"; methods: "files" usebundle => files_manage("$(this.bundle).file"); }
  30. 30. CFEngine может быть простым в использовании Добавить пользователя: "user[git][policy]" string => "add"; Запустить сервис: "service[mysql][policy]" string => "start"; Добавить крон: "cron[do_well][cron]" string => "* * * * * do_well"; Установить пакет: "package[rsyslog][policy]" string => "add";
  31. 31. Количество политик по типам Библиотека Служебные Приложения
  32. 32. Возможно всё! ● IP routes ● HW RAID Write cache ● SELinux ● IPMI SOL ● Kernel modules ● RSS/RPS/RFS
  33. 33. Чем он нам не нравится ● Высокий порог вхождения
  34. 34. Чем он нам не нравится ● Высокий порог вхождения ● Сильно отстаёт от конкурентов
  35. 35. Чем он нам не нравится ● Высокий порог вхождения ● Сильно отстаёт от конкурентов ● Нет возможности расширять функционал
  36. 36. Чем он нам не нравится ● Высокий порог вхождения ● Сильно отстаёт от конкурентов ● Нет возможности расширять функционал ● Плохие шаблоны
  37. 37. Чем примечательна дата 4 апреля?
  38. 38. “В одну тихую весеннюю ночь, а именно с 4- го на 5-ое апреля 2013-го года, ничто не предвещало беды — юзеры непринуждённо общались, грузили и комментили фоточки, и собирали урожай, как вдруг всё ё***лось, и что, с**а, характерно, обратно не поднялось. Ни через час, ни через два, ни через три. И даже не через 20 часов! … Что это за централизованная система управления, которая лёгким движением руки позволяет отправить несколько тысяч серверов в /dev/null, знают только её разработчики…” https://lurkmore.to/Одноклассники
  39. 39. Можно ли было избежать? ● Проверка синаксиса ● Тестовые окружения ● Ревью ● Мониторинг ошибок
  40. 40. CFEngine по-прежнему работает постоянно и проверяет политики каждые 5 минут
  41. 41. Как мы работаем 1. Проверка в git hooks 2. Проверка в тестовом окружении 3. Проверка на части прод серверов с автоматизированным контролем нагрузки 4. Ревью 5. Плавное распространение по проду
  42. 42. GIT hooks ● Проверка синтаксиса
  43. 43. GIT hooks ● Проверка синтаксиса ● Автокоррекция стиля
  44. 44. GIT hooks ● Проверка синтаксиса ● Автокоррекция стиля ● Автозаполнение и проверка commit message
  45. 45. Как мы работаем 1. Проверка в git hooks 2. Проверка в тестовом окружении 3. Проверка на части прод серверов с автоматизированным контролем нагрузки 4. Ревью 5. Плавное распространение по проду
  46. 46. Проверка в тестовом окружении ● Unstable - виртуалки
  47. 47. Проверка в тестовом окружении ● Unstable - виртуалки ● Testing - физические сервера
  48. 48. Как мы работаем 1. Проверка в git hooks 2. Проверка в тестовом окружении 3. Проверка на части прод серверов с автоматизированным контролем нагрузки 4. Ревью 5. Плавное распространение по проду
  49. 49. Stable ● Прод сервера
  50. 50. Stable ● Прод сервера ● От каждого нового кластера берётся один сервер
  51. 51. Stable ● Прод сервера ● От каждого нового кластера берётся один сервер ● Все варианты железа и приложений
  52. 52. Stable ● Прод сервера ● От каждого нового кластера берётся один сервер ● Все варианты железа и приложений ● Потеря прозрачна для пользователей
  53. 53. Stable ● Прод сервера ● От каждого нового кластера берётся один сервер ● Все варианты железа и приложений ● Потеря прозрачна для пользователей ● Обновления плавно в течение одного часа
  54. 54. Stable ● Прод сервера ● От каждого нового кластера берётся один сервер ● Все варианты железа и приложений ● Потеря прозрачна для пользователей ● Обновления плавно в течение одного часа ● Для серверов автоматически контролируется нагрузка
  55. 55. Как мы работаем 1. Проверка в git hooks 2. Проверка в тестовом окружении 3. Проверка на части прод серверов с автоматизированным контролем нагрузки 4. Ревью 5. Плавное распространение по проду
  56. 56. Ревью Ревью политики: 1. Соблюдение style guide (большая часть проверяется pre-commit хуком в git) 2. “Адекватность” кода 3. Использование последних версий методов 4. …
  57. 57. Ревью Соблюдение всех условий для продвижения в прод: 1. Нет ошибок выполнения 2. Нет проблем с нагрузкой 3. “Промариновалось”
  58. 58. Ещё пара слов про ревью ● Исключение - инциденты!
  59. 59. Ещё пара слов про ревью ● Исключение - инциденты! ● Кто ревьювит?
  60. 60. Как мы работаем 1. Проверка в git hooks 2. Проверка в тестовом окружении 3. Проверка на части прод серверов с автоматизированным контролем нагрузки 4. Ревью 5. Плавное распространение по проду
  61. 61. Production ● Поделен на независимые части
  62. 62. Production ● Поделен на независимые части ● Каждая часть применяет изменения равномерно в течение часа
  63. 63. Production ● Поделен на независимые части ● Каждая часть применяет изменения равномерно в течение часа ● Обновления работают только с 8:00 до 20:00
  64. 64. Как мы работаем 1. Проверка в git hooks 2. Проверка в тестовом окружении 3. Проверка на части прод серверов с автоматизированным контролем нагрузки 4. Ревью 5. Плавное распространение по проду
  65. 65. План “Б” ● Альтернативный минимальный набор политик ● Изменяется очень редко
  66. 66. План “В” cf-stop - остановка CFEngine на всём проде за несколько минут
  67. 67. cf-update exit status=0 update+execute execute stop exit status=0 batch size x2 continue
  68. 68. Это надо делать обязательно ● Тестировать в разных условиях ● Долго тестировать на части прода ● Делать ревью ● Распространять обновления в продакшене плавно и поэтапно ● Иметь план на случай аварии
  69. 69. Спасибо за внимание! ● Блог Одноклассников на Хабре http://habrahabr.ru/company/odnoklassniki/ ● Больше о нас и наших докладах http://v.ok.ru/ Дмитрий Самсонов dmitry.samsonov@odnoklassniki.ru https://www.linkedin.com/in/dmitrysamsonov

×