Tänane hommik algas väga hästi! Leidsime lahenduse ennast painanud probleemile.

Joel oli mulle öösel saatnud Eesti X-tee õpetuse, kuidas HAProxyt käivitada/kasutada turvaserveri koormusjaoturina. Eestikeelne abimaterjal on hea infoallikas. Nüüd teeb proksiserver seda, mida ta peab tegema. On üllatav, et ma selles kahtlesin (et ta seda oskab teha). Aga nagu ikka – ise ei jõua kõike õppida ja lugemine tuleb kasuks.  Cybernetica AS on välja andnud avaliku dokumendi – https://x-road.ee/docs/est/haproxy_kasutamine_turvaserverite_koormusjaotuseks.pdf

Meeldetuletuseks:
Koormusjaoturil on mitmeid põhimõtteid ja lahendusi. Üks levinumatest on inglise keeles round-robin, mis kasutab võrdset jaotust. Ja kui oletame, et meil on 3 serverit, siis käib koormuse jaotamine võrdselt ja enamvähem sellise skeemi järgi: A-B-C ja A-B-C. Lihtne.
Meie probleem seisneb aga selles, et kui veebiliidese ühendus tehti näiteks serveri A suunas ja seal avatakse konsool (millega arvuti ekraanipilt ette võetakse), siis see (konsooli ühenduse port) on vaja ka serveri A suunas avada. Küll aga kasutas siis proksi ära oma suurepärast oskust võrdselt ühendusi jagada. Oletame, et konsooli päring suunati serverile B. Server B vastas aga umbes midagi sellist: “sellist ühendust siin ei ole, käi minema!”
Ja siis jäimegi pika ninaga ja kirjutasime “jõuga” sisse, et kasutatakse vaid üht serverit ja teisi kasutatakse siis, kui see eelmine peaks töötama lakkamast.
Ehk siis kasutasime proksi võimalustest healjuhul poolt?
Tänu nüüd sellele leiule saime ära määrata, et jäetakse meelde päringu tegev IP aadress (ehk siis minu kui kliendi arvuti) ja kõik sellelt tehtud päringud saadetakse ühe serveri suunas. Esialgne test näitab õnnestumist, kolme erineva arvutiga sai proovitud, konsoolid avanesid kenasti ja statistika näitab, et päringud saadeti 2 serveri suunas. Noh, ju siis tundus niimoodi mõistlikum.

Hardi tõi välja hea aspekti – Kuutõrvajat (ja teisi eestikeelseid) materjale on ikka vaja (mõtet) kirjutada! Nüüd, kus ma loen ingliskeelset juhendit, näen ma tõesti seda sama punkti ja suudan sealt välja lugeda, et sellist lahendust saaks kasutada. Küll aga ei oska ma öelda, miks ma seda siis ei teadnud.

Serveritel saab muuta “kaalu” (teada varasemast). Ehk siis kui mõni server on tugevama konfiguratsiooniga (mida meil ka on), siis saab tema kaalu tõsta näiteks 30 peale. Tegelikult ongi soovitatav, et kui on 3 serverit, millest üks on kõige parem, teine on keskmine ja kolmas kõige lahjem, siis võiks seadistada koormuse niimoodi: kõige parem 30, keskmine 20 ja kõige lahjem 10. See annab ruumi lihtsalt laienemiseks – saab lisada serveri, millel on 15, 13, 11 jne. Küll aga võib kasutada ka 25 50 100 numbreid näiteks. Kaal tähendab, et rohkem päringuid saadetakse kõige võimsamale serverile (kõige suurema kaaluga), millel pole ju nende töötlemisega probleeme. Lahjem server võib aga hingest kinni jääda, kui suured rahvamassid kõik oma virtuaalservereid tulevad haldama.

Lisaks tegelesin virtuaalserveri teenuse kirjelduse välja töötamisega. Saatsin selle ka esimesele lugemisele, tõenäoliselt tuleb kolinal tagasi, aga ongi hea – kõik selleks, et saaks paremaks vormida.
Kui olen juba piisavalt kindel, et teenus vastupidav ja kirjeldus adekvaatne, siis võiks saata laiemale ringile arutamiseks ja seejärel juba teenuse lansseerida.

Tegelesime ka oma suurteenuse uue andmebaasi seadistamisega. Tahame teha testi, nagu rääkisime. Selleks peame kirjutama skripti, mis kõik lehed läbi käib ja võrdleb praeguseid ja meie poolt võetud lehti. Küll aga tekib probleem – meie lehed on eelmise kolmapäeva seisuga. Selle ajaga jõuavad aga esilehed näiteks muutuda – tekib palju suuruste muutumisi juba sellest tulenevalt. Küll aga saame otsida näiteks lehtedelt sõna “mysql” või “error”. Tõenäosus, et aktiivne ja hetkel töötav leht neid näitab (meie klientide hulgas) on üsna minimaalne ja seetõttu saame sellega väga suure portsu probleeme kinni püüda. Loomulikult võib mõni märkamata jääda, aga sellega me tegeleme.