Работая в сфере ИТ, вы начинаете замечать, что системы имеют свой собственный характер.
Они могут быть гибкими, молчаливыми, эксцентричными и суровыми.
Они могут притягивать или отталкивать.
Так или иначе, с ними приходится «договариваться», лавировать между «подводными камнями» и выстраивать цепочки их взаимодействия.
Итак, нам выпала честь построить облачную платформу, и для этого нам нужно было «уговорить» пару подсистем работать с нами.
К счастью, у нас есть «язык API», прямые руки и много энтузиазма.
Эта статья не будет технически сложной, но опишет проблемы, с которыми мы столкнулись при построении облака.
Наш путь я решил описать в виде легкой технической фантазии о том, как мы искали общий язык с системами и что из этого вышло.
Добро пожаловать в кот.
Начало пути
Некоторое время назад нашей команде была поставлена задача запустить облачную платформу для наших клиентов.У нас была управленческая поддержка, ресурсы, аппаратный стек и свобода в выборе технологий для реализации программной части сервиса.
Также был ряд требований:
- для сервиса необходим удобный личный кабинет;
- платформа должна быть интегрирована в существующую биллинговую систему;
- программное и аппаратное обеспечение: OpenStack + Tungsten Fabric (Open Contrail), которое наши инженеры научились неплохо «готовить».
Инструменты, которые мы решили использовать:
- Python + Flask + Swagger + SQLAlchemy — вполне стандартный набор Python;
- Vue.js для интерфейса;
- Мы решили реализовать взаимодействие между компонентами и сервисами, используя Celery поверх AMQP.
Язык нашел свою нишу в нашей компании и вокруг него сложилась небольшая, но все же культура.
Поэтому было решено начать строить сервис на нем.
Более того, скорость развития подобных задач зачастую имеет решающее значение.
Итак, начнем наше знакомство.
Тихий Билл - выставление счетов
Мы знаем этого парня уже давно.Он всегда сидел рядом со мной и молча что-то считал.
Иногда он пересылал нам запросы пользователей, выставлял счета клиентам и управлял услугами.
Обычный трудолюбивый парень.
Правда, были трудности.
Он молчалив, иногда задумчив, а часто сам по себе.
Биллинг — первая система, с которой мы попытались подружиться.
И первая трудность, с которой мы столкнулись, была при оформлении услуг.
Например, при создании или удалении задача попадает во внутреннюю очередь выставления счетов.
Таким образом реализуется система асинхронной работы с сервисами.
Чтобы обрабатывать типы наших сервисов, нам нужно было «поместить» наши задачи в эту очередь.
И тут мы столкнулись с проблемой: отсутствием документации.
Судя по описанию программного API, решить эту проблему еще можно, но у нас не было времени заниматься реверс-инжинирингом, поэтому мы вынесли логику наружу и организовали очередь задач поверх RabbitMQ. Операция над сервисом инициируется клиентом из личного кабинета, превращается в «задачу» Celery на бэкенде и выполняется на стороне биллинга и OpenStack. Celery позволяет довольно удобно управлять задачами, организовывать повторы и следить за статусом.
Подробнее о «сельдерее» можно прочитать, например, Здесь .
Кроме того, выставление счетов не остановило проект, у которого закончились деньги.
Общаясь с разработчиками, мы выяснили, что при подсчете статистики (а нам нужно реализовать именно такую логику) существует сложная взаимосвязь правил остановки.
Но эти модели плохо вписываются в наши реалии.
Мы также реализовали это через задачи на Celery, перенеся логику управления сервисами на бэкенд-сторону.
Обе вышеперечисленные проблемы привели к тому, что код стал немного раздутым и в будущем нам придется провести рефакторинг, чтобы вынести логику работы с задачами в отдельный сервис.
Нам также необходимо хранить некоторую информацию о пользователях и их услугах в наших таблицах для поддержки этой логики.
Другая проблема – тишина.
Билли молча отвечает «ОК» на некоторые запросы API. Так было, например, когда мы производили выплаты обещанных платежей во время теста (об этом позже).
Запросы были выполнены корректно и ошибок мы не увидели.
Пришлось изучать логи при работе с системой через UI. Оказалось, что сам биллинг выполняет аналогичные запросы, меняя область действия на конкретного пользователя, например, admin, передавая его в параметре su. В целом, несмотря на пробелы в документации и мелкие недочёты API, всё прошло вполне хорошо.
Логи можно читать даже при большой нагрузке, если понимать, как они структурированы и на что обращать внимание.
Структура базы данных витиеватая, но вполне логичная и в чем-то даже привлекательная.
Итак, подводя итог, основные проблемы, с которыми мы столкнулись на этапе взаимодействия, связаны с особенностями реализации конкретной системы:
- недокументированные «особенности», так или иначе затронувшие нас;
- закрытый исходный код (биллинг написан на C++), как следствие - проблему 1 невозможно решить никаким другим способом, кроме как «методом проб и ошибок».
- модуль технической поддержки – запросы из личного кабинета «проксируются» в биллинг прозрачно для клиентов сервиса;
- финансовый модуль – позволяет выставлять счета текущим клиентам, производить списания и формировать платежные документы;
- модуль управления сервисом — для этого нам пришлось реализовать собственный обработчик.
Расширяемость системы сыграла нам на руку и мы «научили» Билли новому виду сервиса.
Это было немного хлопотно, но так или иначе, я думаю, мы с Билли поладим.
Прогулка по вольфрамовым полям – Вольфрамовая ткань
Вольфрамовые поля усеяны сотнями проводов, через которые передаются тысячи бит информации.Информация собирается в «пакеты», анализируется, выстраивая сложные маршруты, как по волшебству.
Это домен второй системы, с которой нам пришлось подружиться — Tungsten Fabric (TF), ранее OpenContrail. Его задача — управлять сетевым оборудованием, предоставляя нам как пользователям программную абстракцию.
TF — SDN, инкапсулирует сложную логику работы с сетевым оборудованием.
Есть хорошая статья про саму технологию, например, здесь .
Система интегрируется с OpenStack (обсуждается ниже) через плагин Neutron. 
Взаимодействие сервисов OpenStack. С этой системой нас познакомили ребята из оперативного отдела.
Мы используем API системы для управления сетевым стеком наших сервисов.
Никаких серьезных проблем или неудобств нам это пока не доставило (не могу говорить за ребят из О?), но были некоторые странности во взаимодействии.
Первый выглядел так: команды, требующие вывода большого количества данных на консоль экземпляра при подключении по SSH, просто «обрывали» соединение, а через VNC все работало корректно.
Для тех, кто не знаком с проблемой, это выглядит довольно забавно: ls /root работает корректно, тогда как, например, top полностью «зависает».
К счастью, мы уже сталкивались с подобными проблемами.
Решилось настройкой MTU на маршруте от вычислительных узлов до роутеров.
Кстати, это не проблема ТФ.
Следующая проблема была не за горами.
В один «прекрасный» момент магия маршрутизации исчезла, вот так.
TF перестал управлять маршрутизацией на оборудовании.
Мы работали с Openstack с уровня администратора и после этого перешли на необходимый уровень пользователя.
Похоже, что SDN «захватывает» область действия пользователя, которым выполняются действия.
Дело в том, что для подключения TF и OpenStack используется одна и та же учетная запись администратора.
На этапе перехода к пользователю «волшебство» исчезло.
Было решено создать отдельный аккаунт для работы с системой.
Это позволило нам работать, не нарушая функционал интеграции.
Кремниевые формы жизни — OpenStack
Силиконовое существо причудливой формы обитает вблизи вольфрамовых полей.Больше всего он похож на ребенка-переростка, который может раздавить нас одним взмахом, но явной агрессии от него не исходит. Он не вызывает страха, но его размеры внушают страх.
Как и сложность происходящего вокруг.
OpenStack — это ядро нашей платформы.
OpenStack имеет несколько подсистем, из которых мы сейчас наиболее активно используем Nova, Glance и Cinder. У каждого из них есть свой API. Nova отвечает за вычислительные ресурсы и создание экземпляров, Cinder отвечает за управление томами и их снимками, Glance — сервис изображений, который управляет шаблонами ОС и метаинформацией на них.
Каждый сервис запускается в контейнере, а брокером сообщений является «белый кролик» — RabbitMQ. Эта система доставила нам самые неожиданные неприятности.
И первая проблема не заставила себя долго ждать, когда мы попытались подключить к серверу дополнительный том.
Cinder API наотрез отказался выполнять эту задачу.
Точнее, если верить самому OpenStack, соединение установлено, но дискового устройства внутри виртуального сервера нет. 
Мы решили пойти в обход и запросили то же действие у Nova API. В результате устройство подключается правильно и доступно на сервере.
Похоже, проблема возникает, когда блочное хранилище не отвечает на Cinder. Еще одна трудность ждала нас при работе с дисками.
Системный том не удалось отключить от сервера.
Опять же сам OpenStack «ругается», что разрушил соединение и теперь можно корректно работать с томом отдельно.
Но API категорически не хотел выполнять операции с диском.
Здесь мы решили особо не воевать, а изменить взгляд на логику сервиса.
Если есть экземпляр, должен быть также системный том.
Поэтому пользователь пока не может удалить или отключить системный «диск», не удалив «сервер».
OpenStack — это довольно сложный набор систем со своей логикой взаимодействия и витиеватым API. Нам помогает достаточно подробная документация и, конечно же, метод проб и ошибок (куда бы мы без него).
Тестовый забег
Тестовый запуск мы провели в декабре прошлого года.Основной задачей было протестировать наш проект в боевом режиме с технической стороны и со стороны UX. Зрителей приглашали выборочно и тестирование было закрытым.
Однако мы также оставили возможность запрашивать доступ к тестированию на нашем сайте.
Само испытание, конечно, не обошлось без забавных моментов, ведь здесь наши приключения только начинаются.
Во-первых, мы несколько неправильно оценили интерес к проекту и пришлось оперативно добавлять вычислительные узлы прямо во время теста.
Обычный случай для кластера, но и здесь были свои нюансы.
В документации конкретной версии TF указана конкретная версия ядра, на которой тестировалась работа с vRouter. Мы решили запускать ноды с более свежими ядрами.
В результате TF не получил маршруты от узлов.
Пришлось срочно откатывать ядра.
Еще один курьез связан с функционалом кнопки «сменить пароль» в личном кабинете.
Мы решили использовать JWT для организации доступа к личному кабинету, чтобы не работать с сессиями.
Поскольку системы разнообразны и широко разбросаны, мы управляем собственным токеном, в который «заворачиваем» сессии от биллинга и токена от OpenStack. При смене пароля токен, естественно, «испортится», так как данные пользователя перестают быть действительными и его необходимо перевыпустить.
Мы упустили этот момент из виду, и ресурсов, чтобы быстро закончить этот кусок, просто не хватило.
Нам пришлось вырезать функционал непосредственно перед запуском теста.
В настоящее время мы выходим из системы, если пароль был изменен.
Несмотря на эти нюансы, тестирование прошло хорошо.
За пару недель заглянуло около 300 человек.
Нам удалось посмотреть на продукт глазами пользователей, протестировать его в действии и собрать качественные отзывы.
Продолжение следует
Для многих из нас это первый проект такого масштаба.Мы усвоили ряд ценных уроков о том, как работать в команде и принимать архитектурные и дизайнерские решения.
Как интегрировать сложные системы с небольшими ресурсами и запустить их в производство.
Конечно, есть над чем работать как в плане кода, так и над интерфейсами системной интеграции.
Проект достаточно молодой, но мы полны амбиций вырастить из него надежный и удобный сервис.
Нам уже удалось убедить системы.
Билл послушно занимается подсчетом, выставлением счетов и запросами пользователей в своем шкафу.
«Магия» вольфрамовых полей обеспечивает нам стабильную связь.
И только OpenStack иногда капризничает, крича что-то вроде «WSREP еще не подготовил узел для использования приложения».
Но это совсем другая история.
Недавно мы запустили эту услугу.
Все подробности вы можете узнать на нашем Веб-сайт .
команда разработчиков CLO Полезные ссылки OpenStack
- https://docs.openstack.org/nova/latest/
- https://docs.openstack.org/keystone/latest/
- https://docs.openstack.org/cinder/latest/
- https://docs.openstack.org/glance/latest/
- http://docs.tungsten.io/en/latest/user/getting-started/index.html
- https://www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html
-
Электронное Обучение И Его Преимущества
19 Oct, 24
