Psono-tiedostopalvelin

Ongelma

Ihmiset ovat pyytäneet turvallista mekanismia tiedostojen vaihtoon. Tänään meillä on ilo esitellä uusi avoimen lähdekoodin tiedostopalvelinmoduuli. Uusimpana komponenttina Psonon ekosysteemissä se ratkaisee useita ongelmia:

• Sähköpostitse jaettavat tiedostot käyvät usein liian suuriksi. Yleensä kaikki yli 20mb hylätään.
• Tiedostojen lähettäminen muille SFTP:llä, GPG-sähköposteilla jne. on liian monimutkaista tavallisille käyttäjille.
• Tiedostojen lähettäminen Google Driven tai Dropboxin kautta voi olla ongelmallista arkaluonteisen datan kohdalla.
• HR- tai johdon tietojen suojaaminen sisäisiltä työntekijöiltä, esim. tiedostopalvelimen ylläpitäjiltä.
• Hakkeri saa pääsyn tiedostopalvelimeesi.
• Kaistanleveysongelmat, kun työskentelet etätoimipisteessä ja kaikki lataavat pieneltä toimistosi tiedostopalvelimelta.

Tässä kohtaa Psono astuu kuvaan. Psono on suunniteltu kaikki nämä ongelmat mielessä ja on erittäin joustava.

Käytettävyys

Miltä tämä siis näyttää käyttäjän näkökulmasta? Yksinkertaiselta.

• Käyttäjä avaa verkkosovelluksen.
• Valitsee tiedoston.
• Klikkaa "lataa" (upload) -painiketta.
• ... ja jos haluaa, jakaa tiedoston oikealla hiiren painikkeella.

Toivottavasti tämä on riittävän yksinkertaista.

Konepellin alla

Konepellin alla asiakasohjelma suorittaa joitakin monimutkaisempia vaiheita, jotka kaikki kuitenkin on piilotettu käyttäjältä:

• Asiakas kysyy palvelimelta kaikki saatavilla olevat tiedostopalvelimet.
• Palvelin arvioi pyynnön ja päättää eri käyttäjäattribuuttien (oikeudet, IP, käyttöoikeudet) perusteella, mitkä shardit (tiedostosijainnit) ja tiedostopalvelimet ovat sopivia.
• Palvelin luo tiedoston latauslipun.
• Asiakasohjelma lukee tiedoston koon.
• Asiakasohjelma ilmoittaa tiedoston jaon ja shardin lataamisesta palvelimelle.
• Asiakasohjelma pilkkoo tiedoston osiin, joiden maksimikoko on 128mb, jos tiedosto on liian suuri.
• Asiakasohjelma salaa jokaisen osan.
• Asiakasohjelma laskee osan tarkistussumman.
• Asiakasohjelma lataa osan tiedostopalvelimelle yhdessä latauslipun kanssa.
• Tiedostopalvelin lähettää latauslipun palvelimelle.
• Palvelin tarkistaa lipun oikeellisuuden.
• Tiedostopalvelin hyväksyy osan lataamisen.
• Asiakas jatkaa seuraavaan osaan, kunnes kaikki osat on käsitelty.
• Asiakas päivittää tietovarastonsa, salaa sen ja lähettää palvelimelle.

Tällä mekanismilla voimme ratkaista minkä tahansa tiedostokoon tuoman ongelman, sillä tiedostot pilkotaan paloihin. Voimme jakaa yksiinkin tiedostoihin kohdistuvat lataukset eri palvelimille. Kaikki tiedostot (kuten kaikki Psonossa) salataan ennen kuin ne poistuvat asiakkaalta ja lähetetään palvelimelle.

Tyypillinen Psono-tiedostopalvelimen rakenne

Ylimpänä kuvassa näkyy tyypillinen rakenne. Välityspalvelin (yksinkertainen reverse proxy) tarjoaa joitakin staattisia tiedostoja (verkkosovellus). Verkkosovellus toimitetaan selaimelle, joka tämän jälkeen kutsuu REST API -päätepisteitä palvelimella. Palvelin käyttää Postgres-tietokantaa kaiken pysyvän datan tallentamiseen. Sekä Psono-verkkosovellus että Psono-palvelin voidaan katsoa tilattomiksi, kaikki data tallennetaan Postgres-tietokantaan.

Jos haluat liittää tiedostopalvelimen, sinun tulee ensin luoda shard- ja klusterikonfiguraatio palvelimella, jonka jälkeen voit käyttää sitä tiedostopalvelimen asetuksissa. Kun tiedostopalvelin käynnistyy, se rekisteröityy automaattisesti ja jatkaa saavutettavuutensa ilmoittamista 10 sekunnin välein. Jos tiedostopalvelin kuolee, palvelin tunnistaa tämän ja lakkaa ohjaamasta asiakkaita kuolleelle palvelimelle. Kun palvelin palaa verkkoon, se rekisteröityy automaattisesti uudelleen ja alkaa jälleen vastaanottaa pyyntöjä. Kuvassa yllä kaikki palat tallennetaan paikalliseen tallennustilaan ja välityspalvelin (voi olla sama kuin normaalille palvelimelle ja verkkosovellukselle pienissä ympäristöissä) toimii SSL:n kevennyksessä.

Paikallisen tallennuksen lisäksi voit käyttää erilaisia tallennusalustoja ja voit jopa yhdistellä niitä.

Eri tallennustaustojen yhdistely

Tällä hetkellä tuetaan (paikallisen tallennuksen lisäksi) Amazon S3, GCP Cloud Storage ja Azure Blob Storage.

Voit käyttää useampaa tiedostopalvelinta ratkaistaksesi esimerkiksi suorituskykyongelmia, jotka johtuvat rajallisesta kaistanleveydestä. Toimistollasi voi olla kapea internet-yhteys vaikka työntekijät työskentelevät etänä. Toinen käyttötapaus voisi olla, että haluat suojata paikallisia tiedostoja entistä paremmin ja

• et salli sisäisten tiedostojen lataamista ulkoiseen tallennustilaan
• sallit ulkopuolisten jakaa tiedostoja sisäisten kanssa ilman eri työkalua

Rakenne, joka ratkaisee suorituskykyongelman ja tarjoaa paremman eristyksen, voisi näyttää tältä:

Etätoimipiste

Tämä rakenne jakaa kaiken "ulkoisen" shardin liikenteen sivustojen välillä kaksisuuntaisesti, mahdollistaen ulkopuolisten ladata tiedostoja, joita työntekijät voivat ladata myöhemmin ja päinvastoin.

Sen sijaan on-premise-shardia ei synkronoida etäpaikkaan ja se pysyy suojatumpana. Koska "ulkoiseen" shardiin tallennetut tiedostot synkronoidaan vain kerran, kun tiedosto muuttuu, 100 työntekijää voi hakea saman tiedoston ilman että sitä tarvitsee ladata sata kertaa etäpaikasta. Tai jos lataat tiedoston, voit jakaa sen sadalle ulkoiselle ilman että joudut lataamaan sitä sata kertaa.

Kaistanleveysetua voidaan käyttää myös etätoimipisteiden yhdistämiseen tällä tavoin:

Kahdella etätoimistolla

Tässä rakenteessa jokaisella sivustolla on oma tiedostopalvelimensa ja kaikki tiedostot jaetaan sivustojen välillä. Kirjoitukset menevät vain tiettyyn shardiin, mikä mahdollistaa jokaisen shardin yksisuuntaisen synkronoinnin. Tämä rakenne antaa New Yorkin ihmisille mahdollisuuden käyttää tiedostoja ilman viivettä.

Seuraava iso aihe on kuormantasaus. Kaikki tämä on hienoa, jos sinulla on vain muutama työntekijä eivätkä kyllästä kaistanleveyttä. Jos sinulla on 1000 työntekijää, jotka kaikki käyttävät tiedostopalvelinta säännöllisesti, muodostuu yhdelle palvelimelle kaistanleveysrajoja. Onneksi Psono pystyy käsittelemään myös tämän. Tässä on kaksi vaihtoehtoa, jotka Psonon tiedostopalvelin tarjoaa kuormantasausta varten.

Sinulla saattaa jo olla kuormantasaaja, jota haluat hyödyntää, jolloin rakenteesi voisi näyttää tältä:

Kuormantasaus tiedostopalvelimella ja kuormantasaajalla

Tässä rakenteessa kuormantasaajaa käytetään SSL:n kevennykseen. Varsinaiset pyynnöt käsittelevät kaksi taustalla olevaa tiedostopalvelinta. Molemmat ilmoittavat saman shardin, joten niiden tulee joko synkronoida shard tai käyttää jaettua tallennustilaa. Tähän voi käyttää GlusterFS:ää tai yksinkertaista rsync:iä.

Vaihtoehto on antaa asiakkaan huolehtia kuormantasauksesta ja säästää hieman ylläpitoa ja kustannuksia. Rakenne ilman erillistä kuormantasaajaa voisi näyttää tältä:

Kuormantasaus tiedostopalvelimella ilman kuormantasaajaa

Kaikkia näitä rakenteita voi pinota, esim. 3 klusteria, joissa jokaisessa 2 palvelinta. Jokainen klusteri palvelee samaa shardia ja sen alla oleva tallennustila on synkronoitu (tai jaettu).

Toivottavasti sain annettua hyvän kuvan Psonon uuden ja mahtavan tiedostopalvelinmoduulin ominaisuuksista.