Moscow Python Meetup №105. Антон Важнецов (K2 Cloud, Тимлид). Подход к глубоким изменениям. Миграция SDN в боевом облаке на Python

Расскажу, как мы в продакшене публичного облака полностью заменили ключевой компонент виртуальной сети, SDN, так, чтобы (почти) ни один клиент этого не заметил. Этот доклад — о том, как спроектировать архитектуру, способную к таким изменениям, как минимизировать риски при большой миграции, и какие инженерные и организационные решения помогли нам пройти этот путь.

Видео: https://moscowpython.ru/meetup/105/deep-change/

Moscow Python: http://moscowpython.ru
Курсы Learn Python: http://learn.python.ru
Moscow Python Podcast: http://podcast.python.ru
Заявки на доклады: https://bit.ly/mp-speaker

Transcript

1. Подход к глубоким изменениям миграция SDN в боевом облаке на Python Антон Важнецов ведущий инженер- разработчик K2 Сloud
2. 2 Публичное облако B2B, с 2009 года IaaS, PaaS Собственная разработка не VMware, не OpenStack 🤬 >1000 серверов и коммутаторов Стек технологий Linux, QEMU-KVM, OVN, Ceph, EMC ScaleIO, K8s, etc. SDN >40k logical switch ports >15k logical router ports [ Про ]
4. 4 [Доклады по теме ] Hab r YouTube
5. 5 [Что на мешало: ] Внесение изменений затрагивает почти всё облако Риск ухудшения сервиса
6. 6 [Шаг 0: ]
7. 7 [ Connectivity-тесты ]
8. 8 [ Проблема 1 ] Масштаб изменений. Взаимодействие сервисов CL Внешний endpoint-сервис, принимает запросы пользователей Внутренний сервис, понимает какие ресурсы нужно настроить до запуска виртуальной машины Сервис производит конфигурацию виртуальных сетей Сервис производит конфигурацию виртуальных машин AC RC NC
9. 9 [ Проблема 1 ] Масштаб изменений. Взаимодействие сервисов
11. 11 // Решение [ Шаг 1 ] Зоны ответственности
12. 12 [ Проблема 1.5 ] Отсутствие абстракций Код сетевых ресурсов невозможно переиспользовать Взаимодействие с SDN реализовано по-своему
13. 13 // Решение Архитектура и Абстракции Каждый сетевой ресурс — класс-модель Взаимодействие с SDN — класс-драйвер Бизнес-логика + управление моделью и драйвером — контроллер
14. 14 // Решение Архитектура и Абстракции
15. 15 Новая архитектура сервиса настройки сетей
16. 16 [ Проблема 2 ] Риск для пользователей Научиться работать с двумя SDN одновременно Ошибки миграции никак не должны влиять на инфраструктуру заказчика и работу облака
17. 17 Новая архитектура сервиса настройки сетей
18. 18 // Решение MigrationController и RC-syncer
19. 19 // Решение MigrationController и RC-syncer
20. 20 // Решение MigrationController и RC-syncer
21. 21 Процесс миграции виртуальной сети
22. 22 Админский тулинг
23. 23 Админский тулинг
24. 24 [ Выводы ] Архитектурная дисциплина — основа масштабных изменений Абстракции и интерфейсы — ваш страховой полис Изоляция изменений в сервисе настройки сетей Параллельная поддержка старого и нового SDN Возможность тестировать компоненты изолировано Асинхронность для «невидимости» изменен ий Минимизировать downtime для пользователей Возможность «докручивать» миграцию в фоне Откат без последствий при ошибках Тесты > интуиция Возможность рефакторить весь legacy-код без страха
25. Будьте в курсе новостей K2 CLOUD k2.cloud info@k2.cloud +7 (495) 019-36-66 Антон Важнецов ведущий инженер- разработчик K2 Сloud