{"id":52389,"date":"2019-11-07T00:00:00","date_gmt":"2019-11-06T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions"},"modified":"2020-02-18T14:00:05","modified_gmt":"2020-02-18T11:00:05","slug":"kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kak-realizuetsya-otkazoustojchivaya-veb-arhitektura-v-platforme-mail-ru-cloud-solutions","title":{"rendered":"Hur \u00e5terfinns en robust webbarkitektur p\u00e5 plattformen Mail.ru Cloud Solutions.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hur
\n
\nHej, Habr! Jag heter Artyom Karamyshev och \u00e4r chef f\u00f6r systemadministrationsteamet Mail.Ru Cloud Solutions (MCS)<\/a><\/noindex>. Under det senaste \u00e5ret har vi haft m\u00e5nga lanseringar av nya produkter. Vi vill att API-tj\u00e4nsterna ska vara l\u00e4tta att skala, vara motst\u00e5ndskraftiga och redo f\u00f6r snabb \u00f6kning av anv\u00e4ndarbelastningen. V\u00e5r plattform \u00e4r baserad p\u00e5 OpenStack, och jag vill ber\u00e4tta om vilka problem med komponenternas motst\u00e5ndskraft vi beh\u00f6vde l\u00f6sa f\u00f6r att f\u00e5 en robust system. Jag tror att detta kommer att vara intressant f\u00f6r dem som ocks\u00e5 utvecklar produkter p\u00e5 OpenStack.<\/p>\n

Den totala motst\u00e5ndskraften hos plattformen best\u00e5r av motst\u00e5ndskraften hos dess komponenter. S\u00e5 vi kommer gradvis att g\u00e5 igenom alla niv\u00e5er d\u00e4r vi har uppt\u00e4ckt risker och \u00e5tg\u00e4rdat dem.<\/p>\n

Videoversionen av denna historia, som har sitt ursprung i en presentation p\u00e5 konferensen Uptime Day 4, organiserad av ITSumma<\/a><\/noindex>, kan ses p\u00e5 YouTube-kanalen Uptime Community<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Motst\u00e5ndskraft hos den fysiska arkitekturen<\/h2>\n

\nDen offentliga delen av MCS-molnet \u00e4r f\u00f6r n\u00e4rvarande baserad i tv\u00e5 Tier III-datacenter, mellan dem finns egen m\u00f6rk fiber som \u00e4r reserverad p\u00e5 fysisk niv\u00e5 med olika sp\u00e5r, med en kapacitet p\u00e5 200 Gbit\/s. Tier III-niv\u00e5n ger den n\u00f6dv\u00e4ndiga motst\u00e5ndskraften f\u00f6r den fysiska infrastrukturen. <\/p>\n

Den m\u00f6rka fibern \u00e4r reserverad b\u00e5de p\u00e5 fysisk och logisk niv\u00e5. Processen f\u00f6r reservkanaler var iterativ, vi st\u00f6tte p\u00e5 problem och vi f\u00f6rb\u00e4ttrar st\u00e4ndigt kommunikationen mellan datacentren. <\/p>\n

Till exempel, f\u00f6r inte s\u00e5 l\u00e4nge sedan, under arbete i en brunn n\u00e4ra ett av datacentren, tr\u00e4ffade en gr\u00e4vmaskin r\u00f6ret, och b\u00e5de huvud- och reserv optisk fiberkabel hamnade i denna r\u00f6rledning. V\u00e5r motst\u00e5ndskraftiga kommunikationskanal med datacenter var s\u00e5rbar vid en punkt, i brunnen. D\u00e4rf\u00f6r f\u00f6rlorade vi en del av infrastrukturen. Vi drog slutsatser, vidtog en rad \u00e5tg\u00e4rder, inklusive att vi lade en extra optisk fiber genom den n\u00e4rliggande brunnen.<\/p><\/blockquote>\n

\nI datacentren finns det punkter d\u00e4r leverant\u00f6rer av kommunikation har n\u00e4rvaro, till vilka vi s\u00e4nder v\u00e5ra prefix via BGP. F\u00f6r varje n\u00e4tverksriktning v\u00e4ljs den b\u00e4sta metrik, vilket g\u00f6r att vi kan erbjuda olika kunder den b\u00e4sta kvalit\u00e9n p\u00e5 anslutningen. Om en f\u00f6rbindelse via en leverant\u00f6r bryts, omkonfigurerar vi v\u00e5r routing via tillg\u00e4ngliga leverant\u00f6rer.<\/p>\n

Vid ett leverant\u00f6rsfel v\u00e4xlar vi automatiskt till n\u00e4sta. Om ett av datacentren slutar fungera har vi en spegelkopi av v\u00e5ra tj\u00e4nster i det andra datacentret, som tar hela belastningen.<\/p>\n

\"Hur
\nFelutst\u00e4llning av fysisk infrastruktur<\/i><\/p>\n

Vad vi anv\u00e4nder f\u00f6r felutst\u00e4llning p\u00e5 applikationsniv\u00e5<\/h2>\n

\nV\u00e5r tj\u00e4nst \u00e4r byggd p\u00e5 en rad \u00f6ppna komponenter. <\/p>\n

ExaBGP<\/b> \u2014 en tj\u00e4nst som implementerar en rad funktioner med hj\u00e4lp av protokollet f\u00f6r dynamisk routing baserat p\u00e5 BGP. Vi anv\u00e4nder den aktivt f\u00f6r att annonsera v\u00e5ra vita IP-adresser, genom vilka anv\u00e4ndare f\u00e5r tillg\u00e5ng till API:t.<\/p>\n

HAProxy<\/b> \u2014 en h\u00f6gbelastad balans- re \u00e4r, som m\u00f6jligg\u00f6r mycket flexibla regler f\u00f6r trafikbalansering p\u00e5 olika niv\u00e5er av OSI-modellen. Vi anv\u00e4nder den f\u00f6r att balansera framf\u00f6r alla tj\u00e4nster: databaser, meddelandehanterare, API-tj\u00e4nster, webb-tj\u00e4nster, v\u00e5ra interna projekt \u2014 allt st\u00e5r bakom HAProxy.<\/p>\n

API-applikation<\/b> \u2014 en webbapplikation skriven i Python, med vilken anv\u00e4ndaren hanterar sin infrastruktur och sina tj\u00e4nster.<\/p>\n

Arbetarapplikation <\/b>(h\u00e4refter bara worker) \u2014 i OpenStack-tj\u00e4nster \u00e4r det en infrastrukturdemon som g\u00f6r det m\u00f6jligt att \u00f6verf\u00f6ra API-kommandon till infrastrukturen. Till exempel sker skapandet av disk just i worker, medan beg\u00e4ran om skapande g\u00f6rs i API-applikationen. <\/p>\n

Standardarkitektur f\u00f6r OpenStack-applikationer<\/h2>\n

\nDe flesta tj\u00e4nster som utvecklas f\u00f6r OpenStack f\u00f6rs\u00f6ker f\u00f6lja en enhetlig paradigm. Tj\u00e4nsten best\u00e5r vanligtvis av tv\u00e5 delar: API och arbetare (backend-executors). I allm\u00e4nhet \u00e4r API:et en WSGI-applikation i Python som antingen k\u00f6rs som en frist\u00e5ende process (demon) eller via en redan etablerad webbserver som Nginx eller Apache. API:et behandlar anv\u00e4ndarens f\u00f6rfr\u00e5gan och vidarebefordrar instruktionerna till arbetarapplikationen f\u00f6r utf\u00f6rande. \u00d6verf\u00f6ringen sker med hj\u00e4lp av en meddelandebroker, vanligtvis RabbitMQ, medan andra st\u00f6ds d\u00e5ligt. N\u00e4r meddelandena n\u00e5r brokern behandlas de av arbetarna och, om det beh\u00f6vs, returnerar de ett svar. <\/p>\n

Denna paradiigm inneb\u00e4r isolerade gemensamma felpunkter: RabbitMQ och databasen. Men RabbitMQ \u00e4r isolerat inom ramen f\u00f6r en tj\u00e4nst och kan i teorin vara individuellt f\u00f6r varje tj\u00e4nst. S\u00e5 vi p\u00e5 MCS separerar dessa tj\u00e4nster s\u00e5 mycket som m\u00f6jligt, f\u00f6r varje separat projekt skapar vi en separat databas och en separat RabbitMQ. Denna metod har den f\u00f6rdelen att om det uppst\u00e5r en n\u00f6dsituation p\u00e5 n\u00e5got s\u00e5rbart st\u00e4lle, s\u00e5 bryts inte hela tj\u00e4nsten utan bara en del av den.<\/p>\n

Antalet arbetarapplikationer \u00e4r o\u00e4ndligt, s\u00e5 API:et kan enkelt skalas horisontellt bakom belastningsbalanserare f\u00f6r att \u00f6ka prestandan och redundansen.<\/p>\n

\u0412 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0441\u0435\u0440\u0432\u0438\u0441\u0430\u0445 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u0430 \u043a\u043e\u043e\u0440\u0434\u0438\u043d\u0430\u0446\u0438\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u2014 \u043a\u043e\u0433\u0434\u0430 \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u044f\u0442 \u0441\u043b\u043e\u0436\u043d\u044b\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 API \u0438 worker’\u0430\u043c\u0438. \u0412 \u044d\u0442\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u0435\u0434\u0438\u043d\u044b\u0439 \u0446\u0435\u043d\u0442\u0440 \u043a\u043e\u043e\u0440\u0434\u0438\u043d\u0430\u0446\u0438\u0438, \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0442\u0438\u043f\u0430 Redis, Memcache, etcd, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u0435\u0442 \u043e\u0434\u043d\u043e\u043c\u0443 worker’\u0443 \u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0434\u0440\u0443\u0433\u043e\u043c\u0443, \u0447\u0442\u043e \u044d\u0442\u0430 \u0437\u0430\u0434\u0430\u0447\u0430 \u0437\u0430\u043a\u0440\u0435\u043f\u043b\u0435\u043d\u0430 \u0437\u0430 \u043d\u0438\u043c (\u00ab\u0442\u044b, \u043f\u043e\u0436\u0430\u043b\u0443\u0439\u0441\u0442\u0430, \u0435\u0435 \u043d\u0435 \u0431\u0435\u0440\u0438\u00bb). \u041c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c etcd. \u041a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e \u0432\u043e\u0440\u043a\u0435\u0440\u044b \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u043e\u0431\u0449\u0430\u0435\u0442\u0441\u044f \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u0438\u0448\u0435\u0442 \u0438 \u0447\u0438\u0442\u0430\u0435\u0442 \u043e\u0442\u0442\u0443\u0434\u0430 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044e. \u0412 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c mariadb, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0443 \u043d\u0430\u0441 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0432 \u043c\u0443\u043b\u044c\u0442\u0438\u043c\u0430\u0441\u0442\u0435\u0440-\u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435.\n<\/p><\/blockquote>\n

\nS\u00e5dan en klassisk ensam tj\u00e4nst \u00e4r organiserad p\u00e5 ett allm\u00e4nt accepterat s\u00e4tt f\u00f6r OpenStack. Den kan betraktas som ett slutet system, f\u00f6r vilket skalnings- och redundantl\u00f6sningarna \u00e4r ganska uppenbara. Till exempel, f\u00f6r redundans \u00e4r det tillr\u00e4ckligt att s\u00e4tta en belastningsbalanserare framf\u00f6r API:et. Skalningen av arbetarna uppn\u00e5s genom att \u00f6ka deras antal. <\/p>\n

En svaghet i hela systemet \u00e4r RabbitMQ och MariaDB. Deras arkitektur f\u00f6rtj\u00e4nar en egen artikel. I den h\u00e4r artikeln vill jag fokusera p\u00e5 API:ns felbest\u00e4ndighet.<\/p>\n

\"Hur
\nArkitektur f\u00f6r OpenStack-applikationen. Belastningsbalansering och felbest\u00e4ndighet f\u00f6r molnplattformen.<\/i><\/p>\n

Vi g\u00f6r HAProxy-belastningsbalanseraren felbest\u00e4ndig med hj\u00e4lp av ExaBGP.<\/h2>\n

\nF\u00f6r att v\u00e5ra API:er ska vara skalbara, snabba och felbest\u00e4ndiga installerade vi en belastningsbalanserare. Vi valde HAProxy. Enligt min \u00e5sikt har den alla n\u00f6dv\u00e4ndiga egenskaper f\u00f6r v\u00e5r uppgift: belastningsbalansering p\u00e5 flera OSI-niv\u00e5er, hanteringsgr\u00e4nssnitt, flexibilitet och skalbarhet, m\u00e5nga belastningsbalanseringsmetoder och st\u00f6d f\u00f6r sessions-tabeller.<\/p>\n

Det f\u00f6rsta problemet som m\u00e5ste l\u00f6sas \u00e4r felbest\u00e4ndigheten hos sj\u00e4lva belastningsbalanseraren. Att bara installera en belastningsbalanserare skapar ocks\u00e5 en punktsvaghet: om belastningsbalanseraren g\u00e5r s\u00f6nder, faller tj\u00e4nsten. F\u00f6r att undvika detta anv\u00e4nde vi HAProxy tillsammans med ExaBGP.<\/p>\n

ExaBGP m\u00f6jligg\u00f6r implementering av en tj\u00e4nsteh\u00e4lsokontroll. Vi anv\u00e4nde denna mekanism f\u00f6r att kontrollera HAProxy:s funktionalitet och st\u00e4nga av HAProxy-tj\u00e4nsten fr\u00e5n BGP vid problem. <\/p>\n

Diagram \u00f6ver ExaBGP+HAProxy<\/b><\/p>\n

    \n
  1. Vi installerar den n\u00f6dv\u00e4ndiga programvaran, ExaBGP och HAProxy, p\u00e5 tre servrar. <\/li>\n
  2. P\u00e5 varje server skapar vi en loopback-gr\u00e4nssnitt.<\/li>\n
  3. Vi konfigurerar samma offentliga IP-adress p\u00e5 detta gr\u00e4nssnitt p\u00e5 alla tre servrar.<\/li>\n
  4. Den offentliga IP-adressen annonseras p\u00e5 internet via ExaBGP. <\/li>\n<\/ol>\n

    \nFelbest\u00e4ndighet uppn\u00e5s genom att annonsera samma IP-adress fr\u00e5n alla tre servrar. Fr\u00e5n n\u00e4tverkets synvinkel \u00e4r samma adress tillg\u00e4nglig fr\u00e5n tre olika n\u00e4sta hopp. Routern ser tre identiska rutter, v\u00e4ljer den mest prioriterade baserat p\u00e5 sin egen metric (detta \u00e4r oftast samma alternativ), och trafiken g\u00e5r endast till en av servrarna. <\/p>\n

    Vid problem med HAProxy eller en server som g\u00e5r ner slutar ExaBGP annonsera rutten, och trafiken v\u00e4xlar smidigt till en annan server. <\/p>\n

    P\u00e5 s\u00e5 s\u00e4tt har vi uppn\u00e5tt felbest\u00e4ndighet f\u00f6r belastningsbalanseraren.<\/p>\n

    \"Hur
    \nFelbest\u00e4ndighet f\u00f6r HAProxy-belastningsbalanserare.<\/i><\/p>\n

    Schemat \u00e4r inte perfekt: vi har l\u00e4rt oss att reservera HAProxy, men vi har inte l\u00e4rt oss att f\u00f6rdela belastningen inom tj\u00e4nsterna. D\u00e4rf\u00f6r har vi ut\u00f6kat denna plan: vi har \u00f6verg\u00e5tt till belastningsbalansering mellan flera offentliga IP-adresser.<\/p>\n

    DNS-baserad balansering plus BGP<\/h2>\n

    \nFr\u00e5gan om lastbalansering med v\u00e5ra HAProxy \u00e4r fortfarande ol\u00f6st. \u00c4nd\u00e5 kan det l\u00f6sas ganska enkelt, precis som vi har gjort med oss sj\u00e4lva.<\/p>\n

    F\u00f6r att balansera tre servrar beh\u00f6vs 3 offentliga IP-adresser och den gamla hederliga DNS. Varje av dessa adresser definieras p\u00e5 loopback-gr\u00e4nssnittet f\u00f6r varje HAProxy och annonseras p\u00e5 internet. <\/p>\n

    I OpenStack anv\u00e4nds en tj\u00e4nstkatalog f\u00f6r att hantera resurser, d\u00e4r API-endpointen f\u00f6r olika tj\u00e4nster anges. I denna katalog skriver vi in dom\u00e4nnamnet \u2013 public.infra.mail.ru, som resolveras via DNS till tre olika IP-adresser. Resultatet blir att vi f\u00e5r lastbalansering mellan tre adresser via DNS. <\/p>\n

    Men eftersom vi vid annonseringen av offentliga IP-adresser inte hanterar prioriteter f\u00f6r serverval, \u00e4r detta fortfarande inte lastbalansering. Vanligtvis v\u00e4ljs endast en server baserat p\u00e5 IP-adressens rang, medan de tv\u00e5 andra blir inaktiva, eftersom inga metrikv\u00e4rden anges i BGP.<\/p>\n

    Vi b\u00f6rjade annonsera rutter via ExaBGP med olika metrikv\u00e4rden. Varje lastbalanserare annonserar alla tre offentliga IP-adresser, men en av dem, den prim\u00e4ra f\u00f6r den aktuella lastbalanseraren, annonseras med l\u00e4gsta metrik. S\u00e5 l\u00e4nge alla tre lastbalanserare \u00e4r aktiva, g\u00e5r beg\u00e4rningar till den f\u00f6rsta IP-adressen till den f\u00f6rsta lastbalanseraren, beg\u00e4rningar till den andra till den andra, och till den tredje till den tredje.<\/p>\n

    Vad h\u00e4nder i det \u00f6gonblicket n\u00e4r en av lastbalanserarna faller? Vid fel p\u00e5 n\u00e5gon lastbalanserare annonseras dess grundl\u00e4ggande adress fortfarande av de tv\u00e5 andra, och trafiken omf\u00f6rdelas mellan dem. S\u00e5ledes ger vi anv\u00e4ndaren flera IP-adresser via DNS. Genom DNS-balansering och olika metrikv\u00e4rden f\u00e5r vi en j\u00e4mn f\u00f6rdelning av belastningen p\u00e5 alla tre lastbalanserarna. Och vi f\u00f6rlorar inte heller redundansen.<\/p>\n

    \"Hur
    \nHAProxy-lastbalansering baserad p\u00e5 DNS + BGP<\/i><\/p>\n

    Interaktion mellan ExaBGP och HAProxy<\/h2>\n

    \nS\u00e5, vi har implementerat redundans f\u00f6r serveravbrott baserat p\u00e5 att annonseringen av rutter upph\u00f6r. Men HAProxy kan ocks\u00e5 st\u00e4ngas av av andra sk\u00e4l \u00e4n serverns fel: administrationsfel, inre tj\u00e4nstfel. Vi vill undanr\u00f6ja en trasig lastbalanserare fr\u00e5n belastningen \u00e4ven i dessa fall, och d\u00e4rf\u00f6r beh\u00f6vs en annan mekanism. <\/p>\n

    D\u00e4rf\u00f6r implementerade vi heartbeat mellan ExaBGP och HAProxy genom att bygga p\u00e5 den tidigare schemat. Det h\u00e4r \u00e4r en mjukvaruimplementation av interaktionen mellan ExaBGP och HAProxy, d\u00e4r ExaBGP anv\u00e4nder skr\u00e4ddarsydda skript f\u00f6r att kontrollera applikationernas status.<\/p>\n

    F\u00f6r detta beh\u00f6ver man konfigurera en h\u00e4lsokontrollare i ExaBGP som kan kontrollera HAProxy:s status. I v\u00e5rt fall konfigurerade vi en health backend i HAProxy, och fr\u00e5n ExaBGP g\u00f6r vi en enkel GET-f\u00f6rfr\u00e5gan. Om annonseringen slutar ske, \u00e4r det troligt att HAProxy inte fungerar, och vi beh\u00f6ver inte annonsera det. <\/p>\n

    \"Hur
    \nHAProxy H\u00e4lsokontroll<\/i><\/p>\n

    HAProxy Peers: session synkronisering <\/h2>\n

    \nN\u00e4sta steg var att synkronisera sessionerna. Vid arbete genom distribuerade lastbalanserare \u00e4r det sv\u00e5rt att bevara information om kundsessioner. Men HAProxy \u00e4r en av de f\u00e5 lastbalanserarna som kan g\u00f6ra detta tack vare funktionaliteten Peers - m\u00f6jligheten att \u00f6verf\u00f6ra sessionstabeller mellan olika HAProxy-processer. <\/p>\n

    Det finns olika metoder f\u00f6r lastbalansering: enkla, som round-robin<\/a><\/noindex>, och avancerade, d\u00e4r kundens session sparas, och han alltid hamnar p\u00e5 samma server som tidigare. Vi ville implementera det andra alternativet.<\/p>\n

    I HAProxy anv\u00e4nds stick-tables f\u00f6r att spara kundsessioner. De lagrar den ursprungliga IP-adressen f\u00f6r kunden, den valda m\u00e5ladressen (backend) och viss metadata. Vanligtvis anv\u00e4nds stick-tabeller f\u00f6r att spara paret source-IP + destination-IP, vilket \u00e4r s\u00e4rskilt anv\u00e4ndbart f\u00f6r applikationer som inte kan \u00f6verf\u00f6ra anv\u00e4ndarsessionens kontext n\u00e4r de v\u00e4xlar till en annan lastbalanserare, till exempel i RoundRobin-l\u00e4get.<\/p>\n

    Om stick-tabellen l\u00e4r sig att flytta mellan olika HAProxy-processer (mellan vilka lastbalansering sker) kan v\u00e5ra lastbalanserare arbeta med en gemensam upps\u00e4ttning stick-tabeller. Detta kommer att m\u00f6jligg\u00f6ra s\u00f6ml\u00f6s n\u00e4tverksv\u00e4xling f\u00f6r kunden vid nedg\u00e5ng av en av lastbalanserarna, och arbetet med kundsessionerna kan forts\u00e4tta p\u00e5 de samma backends som valdes tidigare.<\/p>\n

    F\u00f6r att det ska fungera korrekt m\u00e5ste problemet med source IP-adressen f\u00f6r lastbalanseraren, fr\u00e5n vilken sessionen skapades, l\u00f6sas. I v\u00e5rt fall \u00e4r detta en dynamisk adress p\u00e5 loopback-gr\u00e4nssnittet. <\/p>\n

    Korrekt arbete med peers uppn\u00e5s endast under vissa f\u00f6ruts\u00e4ttningar. Det vill s\u00e4ga att TCP-tidsgr\u00e4nserna m\u00e5ste vara tillr\u00e4ckligt stora eller att omkopplingen m\u00e5ste ske tillr\u00e4ckligt snabbt f\u00f6r att TCP-sessionen inte ska avbrytas. \u00c4nd\u00e5 m\u00f6jligg\u00f6r detta s\u00f6ml\u00f6s omkoppling. <\/p>\n

    Vi har en tj\u00e4nst inom IaaS som \u00e4r byggd med samma teknologi. Det \u00e4r Load Balancer som tj\u00e4nst f\u00f6r OpenStack<\/a><\/noindex>, som heter Octavia. Den \u00e4r baserad p\u00e5 tv\u00e5 processer av HAProxy, och st\u00f6d f\u00f6r peers inbyggs fr\u00e5n b\u00f6rjan. I den h\u00e4r tj\u00e4nsten har de visat sig fungera mycket bra.<\/p>\n

    P\u00e5 bilden visas schematiskt hur peers-tabeller flyttas mellan tre instanser av HAProxy, med en konfiguration som visar hur detta kan st\u00e4llas in:<\/p>\n

    \"Hur
    \nHAProxy Peers (session synkronisering)<\/i><\/p>\n

    Om du ska implementera en liknande l\u00f6sning, b\u00f6r dess funktion testas noggrant. Det \u00e4r inte s\u00e4kert att det fungerar p\u00e5 samma s\u00e4tt i 100 % av fallen. Men \u00e5tminstone kommer du inte att f\u00f6rlora stick-tabeller n\u00e4r du beh\u00f6ver komma ih\u00e5g k\u00e4ll-IP f\u00f6r klienten.<\/p>\n

    Begr\u00e4nsning av antalet samtidiga f\u00f6rfr\u00e5gningar fr\u00e5n samma klient<\/h2>\n

    \nAlla tj\u00e4nster som \u00e4r offentligt tillg\u00e4ngliga, inklusive v\u00e5ra API:er, kan uts\u00e4ttas f\u00f6r stormar av f\u00f6rfr\u00e5gningar. Orsakerna till detta kan vara helt olika, fr\u00e5n anv\u00e4ndarfel till avsiktliga attacker. Vi blir periodvis DDoSat via IP-adresser. Kunder g\u00f6r ofta misstag i sina skript och orsakar mini-DDoS attacker.<\/p>\n

    P\u00e5 ett eller annat s\u00e4tt \u00e4r det n\u00f6dv\u00e4ndigt att f\u00f6rutse ytterligare skydd. En uppenbar l\u00f6sning \u00e4r att begr\u00e4nsa antalet f\u00f6rfr\u00e5gningar till API:et och inte sl\u00f6sa processortid p\u00e5 att hantera skadliga f\u00f6rfr\u00e5gningar.<\/p>\n

    F\u00f6r att implementera s\u00e5dana begr\u00e4nsningar anv\u00e4nder vi rate limits, organiserade p\u00e5 basen av HAProxy, med hj\u00e4lp av samma stick-tabeller. Gr\u00e4nserna st\u00e4lls in ganska enkelt och g\u00f6r det m\u00f6jligt att begr\u00e4nsa anv\u00e4ndaren vad g\u00e4ller antalet f\u00f6rfr\u00e5gningar till API:et. Algoritmen kommer ih\u00e5g k\u00e4ll-IP:n som g\u00f6r f\u00f6rfr\u00e5gningarna och begr\u00e4nsar antalet samtidiga f\u00f6rfr\u00e5gningar fr\u00e5n en anv\u00e4ndare. Naturligtvis har vi ber\u00e4knat det genomsnittliga belastningsprofilen f\u00f6r API:et hos varje tj\u00e4nst och satt gr\u00e4nsen till cirka 10 g\u00e5nger detta v\u00e4rde. Vi forts\u00e4tter att noggrant \u00f6vervaka situationen och h\u00e5ller ett \u00f6ga p\u00e5 l\u00e4get.<\/p>\n

    Hur ser det ut i praktiken? Vi har kunder som st\u00e4ndigt anv\u00e4nder v\u00e5ra API:er f\u00f6r automatisk skalning. De skapar ungef\u00e4r tv\u00e5 till tre hundra virtuella maskiner p\u00e5 morgonen och tar bort dem p\u00e5 kv\u00e4llen. F\u00f6r att skapa en virtuell maskin i OpenStack, \u00e4ven med PaaS-tj\u00e4nster, kr\u00e4vs minst 1000 API-anrop, eftersom interaktionen mellan tj\u00e4nsterna ocks\u00e5 sker via API. <\/p>\n

    Dessa \u00f6verflyttningar av uppgifter medf\u00f6r en ganska stor belastning. Vi har uppskattat denna belastning, samlat in dagliga toppar, \u00f6kat dem tio g\u00e5nger, och det blev v\u00e5r rate-limit. Vi h\u00e5ller ett \u00f6ga p\u00e5 situationen. Vi ser ofta botar och skannrar som f\u00f6rs\u00f6ker ta reda p\u00e5 om vi har n\u00e5gra CGA-skript som kan k\u00f6ras, och vi tar aktivt bort dem.<\/p>\n

    Hur man uppdaterar kodbasen utan att anv\u00e4ndarna m\u00e4rker n\u00e5got<\/h2>\n

    \nVi implementerar ocks\u00e5 redundans p\u00e5 niv\u00e5n f\u00f6r kodutplaceringens processer. Vid utplaceringar sker det ibland fel, men deras p\u00e5verkan p\u00e5 tj\u00e4nsternas tillg\u00e4nglighet kan minimeras.<\/p>\n

    Vi uppdaterar st\u00e4ndigt v\u00e5ra tj\u00e4nster och m\u00e5ste s\u00e4kerst\u00e4lla att processen f\u00f6r att uppdatera kodbasen sker utan att p\u00e5verka anv\u00e4ndarna. Vi lyckades l\u00f6sa denna uppgift genom att anv\u00e4nda m\u00f6jligheterna f\u00f6r HAProxy-hantering och implementering av Graceful Shutdown i v\u00e5ra tj\u00e4nster.<\/p>\n

    F\u00f6r att l\u00f6sa denna uppgift beh\u00f6vs det att s\u00e4kerst\u00e4lla hantering av belastningsbalanseraren och \"korrekt\" avst\u00e4ngning av tj\u00e4nster:<\/p>\n