Tappara.co palvelinympäristön kehitys

Tässä on nyt monta asiaa päällekkäin ja limittäin.

  • Kuten on huomattu, nykyisellään systeemin tehot eivät riitä hetkinä jolloin live-seuranta kiihtyy (maalit, jäähyt, yms.).
  • UpCloudilla olevan serverin käyttöjärjestelmä Ubuntu 16.04 tulee kohta elinkaarensa looppuun :arrow_right: jotain on pakko tehdä. Meillä on edelleen käyttämättömiä UpCloudin krediittejä.
  • Discourse taustayhtiö on tarjonnut heidän Enterprise-hosting palveluaan merkittävällä alennuksella, jotta pääsevät tutkimaan Discoursen käytöstä kuormituspiikeissä.
  • Nyt on myös iso riski sille, että kausi keskeytyy tai peruuntuu, joten kohta ei välttämättä kallista suorituskykyä tarvita taas hetkeen.

Discourse yhteistyö tuskin on lopullinen tai pitkäaikainen ratkaisu, eli vaikka tällä tietoa olemme sopivassa välissä muuttamassa sinne, niin joku oma hosting-ratkaisu pitää kehittää.

1) Minulla on tuossa dedi-palvelin jo valmiina. Jos aikataulut menevät sopivasti, niin sillä ajetaan ensi viikon pelit. 14 päivän kohdalla minun pitää joko maksaa asennusmaksut tai perua tilaus. Hetzner AX41, Tuusulassa. Tarkoitus ei ole muuttaa sille pysyvästi, vaan ainoastaan testata ratkaiseeko tämän tason rauta meidän ongelmat.

2) Asia johon nähtävästi tarvitsen apua: Discoursen asennus, kahdelle palvelimelle jaettuna (data, web_only).

Tämä on yksinkertaisin mahdollinen horisontaalinen skaalaus ja antaisi enemmän pelivaraa palvelinten kokojen optimointiin.

Sinänsä ymmärrän mitä pitää tehdä ja rakenne on hyvin looginen. Otetaan kaksi palvelinta ja asennetaan toiselle web_only ja toiselle data containerit. Tämä on hyvin helpoksi tehty ja selkeää. Mutta näiden yhdistämistä ei ole Discoursessa dokumentoitu.

Periaateessa data-palvelimen tiedot laitetaan web_only.yml:aan ja ajetaan rebuild. Data-containerista ja/tai palvelimesta pitää avata jotain portteja, mutta mitkä ja mihin? Onko data-containeriin/palvelimeen syytä tehdä jotain palomuurien kovennuksia?

Pystyisikö joku tutkimaan kahden palvelimen asennusprosessia hands-on tasolla ja vääntämään asiaa rautalangasta, jotta pääsisin paremmin kärryille. Haluaisin koeponnistaa sen pienellä testisivustolla, jotta vastaava ympäristö on tarvittaessa mahdollista laittaa nopeasti pystyyn. UpCloudin krediitit kannattaa kuitenkin käyttää ja heillä luultavasti on halua tehdä jotkossakin yhteistyötä.

Sysadmin osaamista on ainakin: @Spartak @Luppakorva @a1r6 @ozzi

11 tykkäystä

Mahtaisiko tuo Enterprise-hosting suostua tekemään kahden kontin asennuksen (eli tuo data ja web_only)?

Tällöin vähimmän työn ratkaisu voisi olla, että hostaa siellä vähän aikaa ja katsoo että miten he olivat palikat konffanneet.

Ei, he hoitavat ylläpidon eikä palvelimille ole itsellä edes pääsyä.

Ok, tätä pelkäsinkin.

Tämä lienee tuttu:

On. Tuossa containerit ovat samalla palvelimella, joten niiden yhdistäminen on varsin helppoa.

En ole Discrouseen ikinä perehtynyt mutta:

Huono dokumentointi (tai sen täydellinen puute) kieltämättä vähän yllätti mutta tässähän tämä:

DISCOURSE_DB_USERNAME: db käyttäjä
DISCOURSE_DB_PASSWORD: db:n passu
DISCOURSE_DB_HOST: (tähän ip DB serverille)
DISCOURSE_DB_NAME: kannan nimi

Mikäli eri portissa kun default:

DISCOURSE_DB_PORT: 54311 (portin numero)

Tuolla webasto osaa etsiä kantaa oikeasta paikasta.

En tiedä millaiset säädöt postgre:ssä on, mutta voi joutua tuon kantaservun muuriin ja mahdollisesti postgre:hen availemaan portit ja varsinkin postgre:hen varmasti pitää vielä erikseen antaa web serverin ip:lle lupa ottaa yhteyttä, muutenhan tuohon porttiin ei pitäisi sitten kenelläkään muulla olla asiaa.

Ymmärrän nyt tämän siis niin että tuo DATA on nimenomaan vain ja ainoastaan kantapalvelin?

2 tykkäystä

Postgresin pg_hba.conf-fileellä täytyy postgresin puolella konffata sallitut yhteydet.

1 tykkäys

Ok, mä käytän itse mysliä / mariadb:tä niin postgresistä ei niin tietoa mutta arvelinkin että siellä varmasti samanlainen asetus on.

1 tykkäys

Postgres ja Redis

Oletan että nämä menee data.yml asetuksella expose

1 tykkäys

Ok. Silloin varmaan samaisessa .env filussa on myös Redikselle ip, passu ja portti?

Tässä tapauksessa redisin confia pitää hieman muokata. se pitää ensinnäkin bindata tiettyyn ip:seen:

Etsit redis.conf filusta: bind

löytyy varmaan jotain #bind 127.0.0.1
sen alle bind (serverin ip)

Seuravaavksi täytyy laittaa salasana

Hae riviä requirepass

varmaan #kommentoitu pois eli # pois rivin edestä ja salasana sen jälkeen tyyliin:

requirepass tamaOnSalaSana

Restarttia ja homma tulisi olla sillä selvä Rediksen kanssa

Edit:

Itse Dockerin kanssa mä en osaa auttaa, pitäis opetella se roska jossain vaiheessa mutta ei ole toistaiseksi ehtinyt.

Yllättävää tilannekehitystä parina viime päivänä.

  • Ensinnäkin Liigan pelit ovat keskeytymässä, joten ei tehoille ei olekaan välitöntä tarvetta, eikä sellaisiin kannata välittömästi lisärahaa investoida.
  • Harjoittelin pari iltaa ja Discoursen jakaminen kahdelle palvelimelle oli yllättävän helppo prosessi
    • Web-palvelimelle määritellään tietokanta
    • Tietokantapalvelimelle tehdään muutaman portin avaus sisäverkon IP-osoitteeseen. @Luppakorva Discourse on paketoitu Docker-kontteihin ja tällaiset parametrit viedään ympäristöön .yml konfiguraatiotiedostojen kautta – ei suoraan containeriin sisälle.

Tein operaation testiympäristööni ja ilmeisesti se jopa toimii. Seuraava vaihe olisi miettiä samaa operaatiota tälle sivustolle. Mehän olemme useamman kauden ajaneet ja pärjänneet UpCloudin 80$ palvelimella, kunnes tällä kaudella liven hidastelua ja palvelimen ylikuormittumista on alkanut tapahtumaan toistuvasti. Nosto 160$ palvelinpakettiin paransi asioita jonkin verran, mutta ei korjannut ongelmaa lähellekään.

Nyt pitäisikin sitten arpoa, että minkälaisella kahden palvelimen yhdistelmällä sitä lähitisi kokeilemaan. Live-chatin pysähtymisen aiheuttaa Unicornien loppuminen kesken. Palvelimen ylikuormitus tulee suurelta osin Redisin ja Postgresin kuormasta. Kun nämä eriytetään, niin eivät ainakaan tallo toistensa varpaille. Pienissä palasissa ostamalla muistia ja CPU:ta tulee vähän eri suhteessa.

Ideoita tai ehdotuksia?

2 tykkäystä

Jonkinlainen nyrkkisääntö on että kantapalvelimet ovat ne minne pitäisi osoittaa hauista.

Tässä olettaen että Discoursen saa konffattua yhtä helposti kolmeen eri instanssiin, esim:
Redis: 2 GB / 1 CPU palvelimelle
Postgres: 8 GB / 4 CPU palvelimelle
Discourse: 8 GB / 4 CPU palvelimelle

Tuossa oikeastaan voi olla että Discourselle riittäisi pykälää kevyempikin paketti. Perhana kun olisi statistiikkaa pullonkauloista, se helpottaisi ja kovasti.

Sitäkin ehkä kannattaa kysytä UpCloudilta saako paketteja mitenkään räätälöityä. Kanta/Redis eivät juurikaan tarvitse kaistaa (muuta kuin sisäverkkoon), mutta taas Discourse sitä tarvitsee.

Discourse on kai vaan todella riippuvainen Redisistä, se on todella kovilla tän kanssa joten CPU puolella pitäis olla jerkkua. itse webasto puoli ei taas sitten ole niin kovilla.

Se on juuri näin, nyt kun Redis 6 toi multi-threading mahdollisuuden.

Ja tämä menee nyt tosiaan kahteen purkkiin - ei kolmeen.

  1. Frontti (web_only)
  2. Data
1 tykkäys

Eli nyt sulla on eri pannuilla Data ja Web, plus Redis ja Postgre säädetty ottamaan yhteyttä “remoteen”?

Eli periaatteessa identtinen testiympäristö?

Tuli sekin mieleen että ovatko Discourselta antaneet minkäänlaisia suosituksia mitä rautaan tulee?

Discourse toimittaa valmiiksi templatet web_only.yml ja data.yml. Jälkimmäisessä on Redis ja Posgres. Konfigurointi oli tosiaan yksinkertainen, eli ensimmäiseen määriteltiin missä tietokanta sijaitsee ja toisessa avattiin pari porttia sisäverkon IP:lle. Ja tätä setuppia siis kokeilin testimielessä ja näyttää toimivan.

Discourse ei suosittele yhtään mitään. Heidän business case on tarjota erittäin helposti käyttöönotettavaa perusasennusta, mutta kaikki joiden foorumi menestyy törmäävät tilanteeseen, jossa yksinkertainen asennus ei enää riitä. Siinä vaiheessa monelle on helppo myydä ylläpito hosting-palveluna. Heidän firmansa menestyy - ovat saaneet tunnettujakin asiakkaita ja työtekijöitäkin tuntuu olevan kuin vastustajia KooVeen maalilla.

5 tykkäystä

Okei joo, eli pidetään kortit kädessä ja rahastetaan tuolla “osta palvelu tai arvuuttele ja kärsi” meiningillä.

1 tykkäys

Juuri näin. Hosting-palvelussakin heillä on jo 2-tieriä, kun itse hoitavat ns. enterprise asiakkaat, mutta tekevät vielä yhteistyötä hollantilaisen DiscourseHostingin kanssa, joka tarjoaa vähän edullisempaa palvelua, paremmin pienasiakkaille sopivaa.

Suomen suosituimmista foorumeista mm. Inderes on Discoursen asiakas, vaikka kovaa osaamista löytyy itseltäänkin.

@Luppakorva

Toisaalta, realiteetit meillä on sikäli selvät että tiedämme ettei nykyinen konfiguraatio riitä (CPU-laskentateho), Toisaalta tässä tuli peleistäkin taukoa, eli voisi aloittaa suht pienilä, tarkkailla ja nostella pikkuhiljaa.

2 tykkäystä

Puhuu ehkä sen puolesta, ettei Discoursen kanssa kannata mennä naimisiin asti. Hyvä foorumisofta tämä on, muttei kuitenkaan sen enempää.

Huomasin, että myös Braven foorumi on kovin tutun oloinen kun kävin siellä valittamassa paskoista uudistuksista, joten kyllä tämä suosiota näyttää keräävän.

1 tykkäys

Twitter, Blizzard, Cloudflare, Docker ja niin edelleen - isoja referenssejä löytyy.

4 tykkäystä