Докато работите в ИТ, започвате да забелязвате, че системите имат свой собствен характер. Те могат да бъдат гъвкави, мълчаливи, ексцентрични и сурови. Те могат да привличат или отблъскват. По един или друг начин трябва да „преговаряте“ с тях, да маневрирате между „клопките“ и да изграждате вериги на тяхното взаимодействие.
Така че имахме честта да изградим облачна платформа и за това трябваше да „убедим“ няколко подсистеми да работят с нас. За щастие имаме „API език“, директни ръце и много ентусиазъм.
Тази статия няма да бъде технически хардкор, но ще опише проблемите, които срещнахме при изграждането на облака. Реших да опиша нашия път под формата на лека техническа фантазия за това как сме търсили общ език със системите и какво се е получило от това.
Добре дошли в котка.
Началото на пътуването
Преди време екипът ни беше натоварен със задачата да пусне облачна платформа за нашите клиенти. Имахме управленска поддръжка, ресурси, хардуерен стек и свобода при избора на технологии за внедряване на софтуерната част от услугата.
Имаше и редица изисквания:
- услугата се нуждае от удобен личен акаунт;
- платформата трябва да бъде интегрирана в съществуващата система за таксуване;
- софтуер и хардуер: OpenStack + Tungsten Fabric (Open Contrail), които нашите инженери са се научили да „готвят“ доста добре.
Ще ви разкажем друг път за това как беше сглобен екипът, разработеният интерфейс на личния акаунт и взетите дизайнерски решения, ако общността на Хабра се интересува.
Инструментите, които решихме да използваме:
- Python + Flask + Swagger + SQLAlchemy - напълно стандартен комплект на Python;
- Vue.js за интерфейс;
- Решихме да направим взаимодействието между компоненти и услуги с помощта на Celery върху AMQP.
Очаквайки въпроси относно избора на Python, ще обясня. Езикът намери своята ниша в нашата компания и около него се разви малка, но все пак култура. Затова беше решено да започне изграждането на услугата върху него. Освен това скоростта на развитие при подобни проблеми често е решаваща.
И така, нека започнем нашето запознанство.
Silent Bill - таксуване
Познаваме този човек от много време. Винаги седеше до мен и мълчаливо броеше нещо. Понякога той препраща потребителски заявки към нас, издава клиентски фактури и управлява услуги. Обикновен трудолюбив човек. Вярно, имаше трудности. Той е мълчалив, понякога замислен и често на себе си.
Billing е първата система, с която се опитахме да се сприятелим. И първата трудност, която срещнахме, беше при обработката на услугите.
Например, когато е създадена или изтрита, дадена задача отива във вътрешната опашка за таксуване. По този начин се реализира система за асинхронна работа с услуги. За да обработим нашите типове услуги, трябваше да „поставим“ нашите задачи в тази опашка. И тук се натъкнахме на проблем: липса на документация.
Съдейки по описанието на софтуерния API, все още е възможно да се реши този проблем, но нямахме време да направим обратно инженерство, така че изнесохме логиката навън и организирахме опашка със задачи върху RabbitMQ. Операция по услуга се инициира от клиента от неговия личен акаунт, превръща се в „задача“ на Celery в бекенда и се изпълнява от страна на таксуването и OpenStack. Celery го прави доста удобен за управление на задачи, организиране на повторения и наблюдение на състоянието. Можете да прочетете повече за „целина“, например, .
Освен това фактурирането не е спряло проект, който е свършил парите. Комуникирайки с разработчиците, разбрахме, че при изчисляване на статистиката (а ние трябва да приложим точно този вид логика) има сложна взаимовръзка на правилата за спиране. Но тези модели не се вписват добре в нашата реалност. Ние също така го внедрихме чрез задачи на Celery, пренасяйки логиката за управление на услугата към задната страна.
И двата горни проблема доведоха до това, че кодът стана малко раздут и в бъдеще ще трябва да преработим, за да преместим логиката за работа със задачи в отделна услуга. Също така трябва да съхраняваме известна информация за потребителите и техните услуги в нашите таблици, за да поддържаме тази логика.
Друг проблем е тишината.
Били мълчаливо отговаря с „ОК“ на някои заявки за API. Такъв беше случаят например, когато извършихме плащания на обещани плащания по време на теста (повече за това по-късно). Заявките бяха изпълнени правилно и не видяхме никакви грешки.
Трябваше да проуча регистрационните файлове, докато работех със системата през потребителския интерфейс. Оказа се, че самото таксуване изпълнява подобни заявки, променяйки обхвата на конкретен потребител, например администратор, като го предава в параметъра su.
Като цяло, въпреки пропуските в документацията и дребните пропуски в API, всичко вървеше доста добре. Дневниците могат да се четат дори при голямо натоварване, ако разбирате как са структурирани и какво да търсите. Структурата на базата данни е богато украсена, но доста логична и в някои отношения дори привлекателна.
И така, за да обобщим, основните проблеми, които срещнахме на етапа на взаимодействие, са свързани с характеристиките на внедряване на конкретна система:
- недокументирани „характеристики“, които са ни засегнали по един или друг начин;
- затворен код (фактурирането е написано на C++), като резултат - невъзможно е да се реши проблем 1 по друг начин освен „проба и грешка“.
За щастие, продуктът има доста обширен API и сме интегрирали следните подсистеми в нашия личен акаунт:
- модул за техническа поддръжка - заявките от вашия личен акаунт се „препращат“ към фактуриране прозрачно за клиенти на услугата;
- финансов модул - позволява издаване на фактури на настоящи клиенти, извършване на отписвания и генериране на платежни документи;
- модул за управление на услугата - за това трябваше да внедрим собствен манипулатор. Разширяемостта на системата ни изигра в ръцете и ние „научихме“ Били на нов тип услуга.
Беше малко караница, но по един или друг начин мисля, че с Били ще се разберем.
Разходка през волфрамови полета – Tungsten Fabric
Волфрамови полета, осеяни със стотици жици, пропускащи хиляди битове информация през тях. Информацията се събира в „пакети“, анализира се, изграждайки сложни маршрути, сякаш с магия.
Това е домейнът на втората система, с която трябваше да се сприятелим - Tungsten Fabric (TF), бивша OpenContrail. Неговата задача е да управлява мрежово оборудване, предоставяйки софтуерна абстракция на нас като потребители. TF - SDN, капсулира сложната логика на работа с мрежово оборудване. Има добра статия за самата технология, напр. .
Системата е интегрирана с OpenStack (обсъден по-долу) чрез плъгина Neutron.
Взаимодействие на OpenStack услуги.
Момчетата от оперативния отдел ни запознаха с тази система. Ние използваме API на системата, за да управляваме мрежовия стек на нашите услуги. Все още не ни е създало сериозни проблеми или неудобства (не мога да говоря от името на момчетата от OE), но имаше някои странности във взаимодействието.
Първият изглеждаше така: команди, които изискваха извеждане на голямо количество данни към конзолата на екземпляра при свързване чрез SSH, просто „закачиха“ връзката, докато чрез VNC всичко работеше правилно.
За тези, които не са запознати с проблема, изглежда доста смешно: ls /root работи правилно, докато например top „замръзва“ напълно. За щастие и преди сме се сблъсквали с подобни проблеми. Беше решено чрез настройка на MTU по маршрута от изчислителните възли към рутерите. Между другото, това не е TF проблем.
Следващият проблем беше точно зад ъгъла. В един „красив“ момент магията на маршрутизирането изчезна, точно така. TF спря да управлява маршрутизирането на оборудването.
Работихме с Openstack от администраторско ниво и след това преминахме на необходимото потребителско ниво. SDN изглежда „отвлича“ обхвата на потребителя, от който се извършват действията. Факт е, че един и същ администраторски акаунт се използва за свързване на TF и OpenStack. На етапа на превключване към потребителя „магията“ изчезна. Беше решено да се създаде отделен акаунт за работа със системата. Това ни позволи да работим, без да нарушаваме интеграционната функционалност.
Силициеви форми на живот - OpenStack
Силиконово създание със странна форма живее близо до волфрамови находища. Най-вече изглежда като пораснало дете, което може да ни смачка с един замах, но от него няма видима агресия. Не предизвиква страх, но размерът му вдъхва страх. Както и сложността на случващото се наоколо.
OpenStack е ядрото на нашата платформа.
OpenStack има няколко подсистеми, от които в момента използваме най-активно Nova, Glance и Cinder. Всеки от тях има свой собствен API. Nova отговаря за изчислителните ресурси и създаването на екземпляри, Cinder отговаря за управлението на томове и техните моментни снимки, Glance е услуга за изображения, която управлява шаблони на OS и метаинформация върху тях.
Всяка услуга работи в контейнер, а брокерът на съобщения е „белият заек“ - RabbitMQ.
Тази система ни създаде най-неочакваните проблеми.
И първият проблем не закъсня, когато се опитахме да свържем допълнителен обем към сървъра. Cinder API категорично отказа да изпълни тази задача. По-точно, ако вярвате на самия OpenStack, връзката е установена, но във виртуалния сървър няма дисково устройство.
Решихме да заобиколим пътя и поискахме същото действие от Nova API. Резултатът е, че устройството се свързва правилно и е достъпно в сървъра. Изглежда, че проблемът възниква, когато блоковото съхранение не отговаря на Cinder.
Друга трудност ни очакваше при работа с дискове. Системният том не можа да бъде прекъснат от сървъра.
Отново самият OpenStack „се кълне“, че е унищожил връзката и сега можете правилно да работите с обем отделно. Но API категорично не искаше да извършва операции на диска.
Тук решихме да не се караме особено, а да променим виждането си за логиката на услугата. Ако има екземпляр, трябва да има и системен том. Следователно потребителят все още не може да премахне или деактивира системния „диск“, без да изтрие „сървъра“.
OpenStack е доста сложен набор от системи със собствена логика на взаимодействие и богато украсен API. Помага ни доста подробна документация и, разбира се, опит и грешка (къде бихме били без тях).
Пробно изпълнение
Проведохме тестово изстрелване през декември миналата година. Основната задача беше да тестваме нашия проект в боен режим от техническа страна и от страна на UX. Публиката беше поканена избирателно и тестването беше закрито. Въпреки това оставихме и възможността да поискате достъп до тестване на нашия уебсайт.
Самият тест, разбира се, не мина без забавни моменти, защото тук тепърва започват нашите приключения.
Първо, донякъде неправилно оценихме интереса към проекта и трябваше бързо да добавим изчислителни възли точно по време на теста. Често срещан случай за клъстер, но и тук имаше някои нюанси. Документацията за конкретна версия на TF посочва конкретната версия на ядрото, на която е тествана работата с vRouter. Решихме да стартираме възли с по-нови ядра. В резултат на това TF не получи маршрути от възлите. Трябваше спешно да върна ядрата.
Друго любопитство е свързано с функционалността на бутона „промяна на паролата“ в личния ви акаунт.
Решихме да използваме JWT, за да организираме достъпа до нашия личен акаунт, за да не работим със сесии. Тъй като системите са разнообразни и широко разпръснати, ние управляваме наш собствен токен, в който „опаковаме“ сесии от таксуване и токен от OpenStack. Когато паролата се промени, токенът, разбира се, се „разваля“, тъй като потребителските данни вече не са валидни и трябва да бъдат преиздадени.
Изгубихме от поглед тази точка и просто нямаше достатъчно ресурси, за да завършим бързо тази част. Трябваше да изключим функционалността точно преди стартирането на теста.
Понастоящем излизаме от системата, ако паролата е променена.
Въпреки тези нюанси, тестването мина добре. За няколко седмици около 300 души се отбиха. Успяхме да погледнем продукта през очите на потребителите, да го изпробваме в действие и да съберем висококачествена обратна връзка.
За да се продължи
За много от нас това е първият проект от такъв мащаб. Научихме редица ценни уроци за това как да работим в екип и да вземаме архитектурни и дизайнерски решения. Как да интегрирате сложни системи с малко ресурси и да ги пуснете в производство.
Разбира се, има върху какво да се работи както по отношение на кода, така и в интерфейсите на системната интеграция. Проектът е доста млад, но сме пълни с амбиции да го превърнем в надеждна и удобна услуга.
Вече успяхме да убедим системите. Бил послушно обработва преброяването, фактурирането и потребителските заявки в гардероба си. „Магията“ на волфрамовите полета ни осигурява стабилна комуникация. И само OpenStack понякога става капризен, извиквайки нещо от рода на „'WSREP все още не е подготвил възел за използване от приложението.“ Но това е съвсем различна история...
Наскоро пуснахме услугата.
Можете да научите всички подробности на нашия .
Екип за разработка на CLO
Полезни връзки
OpenStack
Волфрамова тъкан
Източник: www.habr.com