Als je in de IT werkt, begin je te merken dat systemen hun eigen karakter hebben. Ze kunnen flexibel, stil, excentriek en streng zijn. Ze kunnen aantrekken of afstoten. Op de een of andere manier moet je met hen ‘onderhandelen’, tussen ‘valkuilen’ manoeuvreren en ketens van hun interactie opbouwen.
We hadden dus de eer om een cloudplatform te bouwen, en hiervoor moesten we een aantal subsystemen ‘overtuigen’ om met ons samen te werken. Gelukkig hebben we een ‘API-taal’, directe handen en veel enthousiasme.
Dit artikel zal technisch gezien niet hardcore zijn, maar beschrijft de problemen die we tegenkwamen tijdens het bouwen van de cloud. Ik besloot ons pad te beschrijven in de vorm van een lichttechnische fantasie over hoe we met systemen naar een gemeenschappelijke taal zochten en wat daaruit voortkwam.
Welkom bij kat.
Begin van een reis
Enige tijd geleden kreeg ons team de opdracht om een cloudplatform voor onze klanten te lanceren. We hadden managementondersteuning, middelen, hardwarestack en vrijheid bij het kiezen van technologieën om het softwaregedeelte van de service te implementeren.
Er waren ook een aantal vereisten:
- de dienst heeft een handig persoonlijk account nodig;
- het platform moet worden geïntegreerd in het bestaande facturatiesysteem;
- software en hardware: OpenStack + Tungsten Fabric (Open Contrail), die onze ingenieurs vrij goed hebben leren “koken”.
Als de Habra-gemeenschap geïnteresseerd is, vertellen we u een andere keer hoe het team is samengesteld, de persoonlijke accountinterface is ontwikkeld en ontwerpbeslissingen zijn genomen.
De tools die we besloten te gebruiken:
- Python + Flask + Swagger + SQLAlchemy - een volledig standaard Python-set;
- Vue.js voor frontend;
- We hebben besloten om de interactie tussen componenten en services uit te voeren met behulp van Celery via AMQP.
Anticiperend op vragen over het kiezen van Python, zal ik het uitleggen. De taal heeft zijn plek gevonden in ons bedrijf en er heeft zich een kleine, maar nog steeds cultuur omheen ontwikkeld. Daarom werd besloten om de dienst daarop te gaan bouwen. Bovendien is de snelheid van ontwikkeling bij dergelijke problemen vaak doorslaggevend.
Laten we dus beginnen met onze kennismaking.
Stille factuur - facturering
Wij kennen deze man al heel lang. Hij zat altijd naast mij en telde stilletjes iets. Soms stuurde hij gebruikersverzoeken naar ons door, stelde klantfacturen op en beheerde diensten. Een gewone, hardwerkende man. Toegegeven, er waren moeilijkheden. Hij is stil, soms nadenkend en vaak in zijn eigen gedachten.
Facturering is het eerste systeem waarmee we vrienden probeerden te maken. En de eerste moeilijkheid die we tegenkwamen was bij het verwerken van diensten.
Wanneer een taak bijvoorbeeld wordt gemaakt of verwijderd, wordt deze in de interne factureringswachtrij geplaatst. Zo wordt een systeem van asynchroon werken met services geïmplementeerd. Om onze servicetypen te verwerken, moesten we onze taken in deze wachtrij "plaatsen". En hier kwamen we een probleem tegen: gebrek aan documentatie.
Afgaande op de beschrijving van de software-API is het nog steeds mogelijk om dit probleem op te lossen, maar we hadden geen tijd om aan reverse engineering te doen, dus hebben we de logica naar buiten gebracht en een takenwachtrij bovenop RabbitMQ georganiseerd. Een bewerking op een dienst wordt door de klant vanuit zijn persoonlijke account geïnitieerd, verandert in een Celery-"taak" aan de backend en wordt uitgevoerd aan de facturerings- en OpenStack-kant. Met Celery is het heel handig om taken te beheren, herhalingen te organiseren en de status te controleren. U kunt bijvoorbeeld meer lezen over “selderij”, .
Bovendien kon de facturering een project dat geen geld meer had, niet tegenhouden. Toen we met de ontwikkelaars communiceerden, kwamen we erachter dat er bij het berekenen van statistieken (en we moeten precies dit soort logica implementeren) een complexe onderlinge relatie bestaat tussen stopregels. Maar deze modellen passen niet goed bij onze realiteit. We hebben het ook geïmplementeerd via taken op Celery, waarbij we de servicemanagementlogica naar de backend hebben gebracht.
Beide bovenstaande problemen hebben ertoe geleid dat de code een beetje opgeblazen is geworden en in de toekomst zullen we moeten herstructureren om de logica voor het werken met taken naar een aparte service te verplaatsen. We moeten ook wat informatie over gebruikers en hun services in onze tabellen opslaan om deze logica te ondersteunen.
Een ander probleem is stilte.
Billy antwoordt stilletjes “Ok” op sommige API-verzoeken. Dit was bijvoorbeeld het geval toen we tijdens de test beloofde betalingen uitbetaalden (daarover later meer). De verzoeken zijn correct uitgevoerd en we hebben geen fouten gezien.
Ik moest de logboeken bestuderen terwijl ik via de gebruikersinterface met het systeem werkte. Het bleek dat de facturering zelf soortgelijke verzoeken uitvoert, waarbij de reikwijdte wordt gewijzigd naar een specifieke gebruiker, bijvoorbeeld admin, en deze wordt doorgegeven in de su-parameter.
Over het algemeen verliep alles redelijk goed, ondanks de hiaten in de documentatie en kleine API-fouten. Logboeken kunnen zelfs onder zware belasting worden gelezen als u begrijpt hoe ze zijn gestructureerd en waar u op moet letten. De structuur van de database is sierlijk, maar vrij logisch en in sommige opzichten zelfs aantrekkelijk.
Kortom, de belangrijkste problemen die we in de interactiefase tegenkwamen, houden verband met de implementatiekenmerken van een specifiek systeem:
- ongedocumenteerde ‘kenmerken’ die ons op de een of andere manier beïnvloedden;
- closed source (facturering is geschreven in C++), waardoor het onmogelijk is om probleem 1 op een andere manier op te lossen dan met vallen en opstaan.
Gelukkig beschikt het product over een vrij uitgebreide API en hebben we de volgende subsystemen geïntegreerd in ons persoonlijke account:
- module voor technische ondersteuning - verzoeken van uw persoonlijke account worden 'geproxyed' voor transparante facturering voor serviceklanten;
- financiële module - hiermee kunt u facturen uitreiken aan huidige klanten, afschrijvingen doen en betalingsdocumenten genereren;
- servicecontrolemodule - hiervoor moesten we onze eigen handler implementeren. De uitbreidbaarheid van het systeem speelde ons in de kaart en we ‘leerden’ Billy een nieuw soort dienstverlening.
Het was een beetje gedoe, maar op de een of andere manier denk ik dat Billy en ik wel met elkaar overweg kunnen.
Wandelen door wolfraamvelden – Tungsten Fabric
Wolfraamvelden zijn bezaaid met honderden draden, waardoor duizenden stukjes informatie worden doorgegeven. Informatie wordt verzameld in “pakketten”, ontleed, waardoor complexe routes worden opgebouwd, als bij toverslag.
Dit is het domein van het tweede systeem waarmee we vrienden moesten maken: Tungsten Fabric (TF), voorheen OpenContrail. Zijn taak is het beheren van netwerkapparatuur en het bieden van een softwareabstractie aan ons als gebruikers. TF - SDN omvat de complexe logica van het werken met netwerkapparatuur. Er is bijvoorbeeld een goed artikel over de technologie zelf: .
Het systeem is geïntegreerd met OpenStack (hieronder besproken) via de Neutron-plug-in.
Interactie van OpenStack-services.
De jongens van de afdeling Operations hebben ons kennis laten maken met dit systeem. We gebruiken de API van het systeem om de netwerkstack van onze services te beheren. Het heeft ons nog geen ernstige problemen of ongemakken opgeleverd (ik kan niet voor de jongens van de OE spreken), maar er zijn enkele eigenaardigheden in de interactie geweest.
De eerste zag er zo uit: opdrachten die het uitvoeren van een grote hoeveelheid gegevens naar de instanceconsole vereisten bij het verbinden via SSH, verbraken eenvoudigweg de verbinding, terwijl via VNC alles correct werkte.
Voor degenen die niet bekend zijn met het probleem, het ziet er best grappig uit: ls /root werkt correct, terwijl bijvoorbeeld top volledig “bevriest”. Gelukkig zijn we eerder soortgelijke problemen tegengekomen. Er werd besloten door de MTU af te stemmen op de route van de rekenknooppunten naar de routers. Overigens is dit geen TF-probleem.
Het volgende probleem lag om de hoek. Op één ‘mooi’ moment verdween de magie van routing zomaar. TF is gestopt met het beheer van de routering op de apparatuur.
We werkten met Openstack vanaf het admin-niveau en gingen daarna over naar het vereiste gebruikersniveau. SDN lijkt de reikwijdte van de gebruiker door wie de acties worden uitgevoerd te ‘kapen’. Feit is dat hetzelfde beheerdersaccount wordt gebruikt om TF en OpenStack te verbinden. Bij de stap van het overschakelen naar de gebruiker verdween de ‘magie’. Er werd besloten om een apart account aan te maken om met het systeem te kunnen werken. Hierdoor konden we werken zonder de integratiefunctionaliteit te onderbreken.
Silicium-levensvormen - OpenStack
In de buurt van wolfraamvelden leeft een bizar gevormd siliconenwezen. Bovenal lijkt het op een overgroeid kind dat ons met één zwaai kan verpletteren, maar er komt geen duidelijke agressie van hem uit. Het veroorzaakt geen angst, maar de omvang ervan boezemt angst in. Net als de complexiteit van wat er rondom gebeurt.
OpenStack is de kern van ons platform.
OpenStack kent meerdere subsystemen, waarvan wij momenteel Nova, Glance en Cinder het meest actief gebruiken. Elk van hen heeft zijn eigen API. Nova is verantwoordelijk voor computerbronnen en het maken van instances, Cinder is verantwoordelijk voor het beheer van volumes en hun snapshots, Glance is een beeldservice die OS-sjablonen en meta-informatie daarover beheert.
Elke service draait in een container en de berichtenmakelaar is het ‘witte konijn’: RabbitMQ.
Dit systeem bezorgde ons de meest onverwachte problemen.
En het eerste probleem liet niet lang op zich wachten toen we probeerden een extra volume op de server aan te sluiten. De Cinder API weigerde botweg deze taak uit te voeren. Om precies te zijn: als je OpenStack zelf gelooft, is de verbinding tot stand gebracht, maar bevindt er zich geen schijfapparaat in de virtuele server.
We besloten een omweg te nemen en vroegen dezelfde actie aan de Nova API. Het resultaat is dat het apparaat correct verbinding maakt en toegankelijk is binnen de server. Het lijkt erop dat het probleem optreedt wanneer blokopslag niet reageert op Cinder.
Een andere moeilijkheid wachtte ons bij het werken met schijven. Het systeemvolume kan niet worden losgekoppeld van de server.
Nogmaals, OpenStack zelf “zweert” dat het de verbinding heeft verbroken en dat je nu correct met volume afzonderlijk kunt werken. Maar de API wilde categorisch geen bewerkingen op de schijf uitvoeren.
Hier hebben we besloten om niet speciaal te vechten, maar om onze kijk op de logica van de dienst te veranderen. Als er een instance is, moet er ook een systeemvolume zijn. Daarom kan de gebruiker de “systeemschijf” nog niet verwijderen of uitschakelen zonder de “server” te verwijderen.
OpenStack is een nogal complexe set systemen met zijn eigen interactielogica en sierlijke API. We worden geholpen door redelijk gedetailleerde documentatie en natuurlijk door vallen en opstaan (waar zouden we zijn zonder).
Proefdraaien
Vorig jaar december hebben we een testlancering uitgevoerd. De belangrijkste taak was om ons project in gevechtsmodus te testen, zowel vanuit de technische kant als vanuit de UX-kant. Het publiek werd selectief uitgenodigd en de test werd gesloten. Wij hebben echter ook de mogelijkheid gelaten om toegang tot testen op onze website aan te vragen.
De test zelf was natuurlijk niet zonder grappige momenten, want hier beginnen onze avonturen nog maar net.
Ten eerste hebben we de interesse in het project enigszins verkeerd ingeschat en moesten we tijdens de test snel rekennodes toevoegen. Een veelvoorkomend geval voor een cluster, maar er waren ook hier enkele nuances. De documentatie voor een specifieke versie van TF geeft de specifieke versie van de kernel aan waarop het werken met vRouter is getest. We hebben besloten knooppunten met recentere kernels te lanceren. Als gevolg hiervan ontving TF geen routes van de knooppunten. Ik moest dringend de kernels terugdraaien.
Een andere nieuwsgierigheid houdt verband met de functionaliteit van de knop ‘wachtwoord wijzigen’ in uw persoonlijke account.
We hebben besloten om JWT te gebruiken om de toegang tot ons persoonlijke account te organiseren, zodat we niet met sessies werken. Omdat de systemen divers en wijd verspreid zijn, beheren we onze eigen token, waarin we sessies van facturering en een token van OpenStack “inpakken”. Wanneer het wachtwoord wordt gewijzigd, gaat het token uiteraard “slecht”, omdat de gebruikersgegevens niet langer geldig zijn en opnieuw moeten worden uitgegeven.
We zijn dit punt uit het oog verloren en er waren simpelweg niet genoeg middelen om dit stuk snel af te maken. We moesten de functionaliteit eruit halen vlak voordat we de test lanceerden.
Momenteel loggen we de gebruiker uit als het wachtwoord is gewijzigd.
Ondanks deze nuances verliep het testen goed. Binnen een paar weken kwamen ongeveer 300 mensen langs. We konden het product door de ogen van gebruikers bekijken, het in actie testen en hoogwaardige feedback verzamelen.
Wordt vervolgd
Voor velen van ons is dit het eerste project van deze omvang. We hebben een aantal waardevolle lessen geleerd over hoe we als team moeten werken en architecturale en ontwerpbeslissingen kunnen nemen. Hoe je complexe systemen met weinig middelen kunt integreren en in productie kunt nemen.
Natuurlijk is er iets om aan te werken, zowel qua code als op de raakvlakken van systeemintegratie. Het project is nog vrij jong, maar we zitten vol ambities om het uit te laten groeien tot een betrouwbare en handige dienst.
Wij hebben de systemen al kunnen overtuigen. Bill handelt plichtsgetrouw af met tellen, factureren en gebruikersverzoeken in zijn kast. De ‘magie’ van wolfraamvelden biedt ons stabiele communicatie. En alleen OpenStack wordt soms wispelturig en roept iets als “WSREP heeft de node nog niet voorbereid voor toepassingsgebruik.” Maar dat is een heel ander verhaal...
We hebben de dienst onlangs gelanceerd.
Alle details vindt u op onze .
CLO-ontwikkelingsteam
Nuttige links
OpenStack
Wolfraam stof
Bron: www.habr.com