Hostolt adatbázis - digitalocean?

Sziasztok!

 

Üzemeltetéssel jó sok éve nem foglalkozom, az új technikákkal szemben teljesen laikus vagyok, a kérdésem is ilyen.

 

15 év után megszűnik egy szerverem, ami napi használatban van. A config 8-9 éves lehet, 2GB ram, mysql elég lassú rajta, a dump 80MB tömörítve, de egyes táblák 30-40e rekordot tartalmaznak.

 

Azon gondolkoztam, hogy az adatbázist adott hostoltatnám. Mi erről a véleményetek? Milyen hátulütői lehetnek?

 

Az első google találat a digitalocean volt, így ezt nézegettem kicsit meg, aminek a legközelebbi központja Frankfurtban. Milyen hátulütői lennének? Az elmúlt években (10 évben) többször előfordult, hogy ilyen-olyan okokból órákig (talán napokig) nem lehetett elérni Magyarországon kívüli területet, vagy azok egy részét.

 

Tapasztalatok, és ajánlatok érdekelnének? Van itthoni, csak mysql hosttal foglalkozó szolgáltató is, akit akár ajánlanátok? Milyen ez a digitalcoean?

 

Átlagban 20-40 query van másodpercenként, sajnos byteszerű információm erről nincs.

Hozzászólások

Nem működik ez a történet egy sima shared hosting tárhelyen? Ha nagyon egyedi az app, akkor virtuális gép és kész. Mennyire naprakész az app amúgy? Ezt a 15 évet hogy kell érteni?

A 15 évet úgy kell érteni, hogy egy gépet használtam ilyen olyan célokra, bérszerver, és most megszűnik, lényege nincs.

 

A lényeges app még python 2.7, itt nincs is jelentősége, de így legalább megvan a motiváció egy python 3.x-re történő migrálásra.

 

Csak az adatbázist szeretném külső dolgokra tenni, virtuális gép meg nem igazán játszik (2-5 TB tárterület ott igen magas haviösszegre jönne ki tudtommal).

Csak a szokásos problémák: nem érhető el, "messze van" azaz nagy válaszidő, változó válaszidő stb... Jellemzően egy olyan problémát veszel a nyakadba, amit igazából nem akartál és rájössz, hogy a dedikált szerver igazából tökre megéri. Azt szoktam mondani, hogy az igényekhez kell rendelni az erőforrásokat. Ha leadsz a 2-5TB-ból, akkor máris nagyot lépsz előre egy VM felé.

Ez főleg akkor jöhet elő, ha távol vannak egymástól, és akkor is ritka lesz. Ezek azért jellemzően bosszantóak, mert tudsz mit kezdeni hálózati issueval. Nekünk van monitoring szerverünk külföldön, és rendszeresen jönnek a fals pozitív (legalábbis itthonról nézve megy minden) jelentések, vagy esetleg flappel a hálózat. Ha szépen egyben van minden, akkor tök jó.

Ez főleg akkor jöhet elő, ha távol vannak egymástól, és akkor is ritka lesz.

Na most ez így bullshit.

Ezek azért jellemzően bosszantóak, mert tudsz mit kezdeni hálózati issueval.

Az lesz akkor is, ha az ember maga futtatja az adatbázist.

Nekünk van monitoring szerverünk külföldön, és rendszeresen jönnek a fals pozitív (legalábbis itthonról nézve megy minden) jelentések, vagy esetleg flappel a hálózat. Ha szépen egyben van minden, akkor tök jó.

Hát, a kontinensek között lehet ilyen baj, de ha kontinensek között akarunk adatbázis kapcsolatot, akkor arra fel kell készülni. És amúgy akkor se lesz másképp, ha magunk telepítjük.

Kontinensen belül vagyunk. Semmi izgalom csak a fanszia - magyar viszonylat, meg nyilván az adott szolgáltatók.

Hát azért ilyen viszonylatban nem nagyon kellene meglepetésnek lennie.

Tegnap este pl. a válaszidő szaladt fel a duplájára.

És az mennyi? 25 ms helyett 50 ms? A hálózat nagyjából ennyit kellene számítson... ha ennél lényegesen nagyobb változások vannak, akkor annak más oka van.

20-30ms körülről 100-ra ment fel. Igazából az önmagában engem nem zavar. Még az is lehet, hogy itt mókoltak valamit a külföldi vonallal. Egyébként ezen kár ennyit rágódni. A kérdező figyelmét próbáltam rá felhívni, hogy ezzel tisztában legyen, hogy ez előfordulhat, hiszen ő írta, hogy a MySQL teljesítménnyel problémája van.

Ja egyébként van MySQL replikációm (VPN felett természetesen) ezek között a DC-k között, de névszerverekhez. Ott végképp nem okoz a fenti gondot.

Amazon egyébként tud kb. ingyen health monitoring-ot huszon-akármennyi helyről riasztással, Route53 része, mint health check alapú IP re-routing, de emlékeim szerint bármire működik, nem kell ott legyen a figyelt domain és/vagy szolgáltatás...

Szerintem ez attól függ, hogy van felépítve az app.

a legtöbb microservice olyan, hogy a DBje saját magán belül van, egy fizikai gépen, de legalábbis egy szerverközpontban, aztán REST API-n beszélget a rendszer többi részével, meg a kliensekkel.

meg lehet azt is csinálni, hogy a DB kinn van a francba, aztán az app vagy működik vele, vagy nem. Ha jól fel van készítve, semmi baja nem lesz tőle, ha meg nem, hát… az esetek 70%-ában akkor is működhet jól, kérdés, mit zagyvál össze a maradék 30%-ban. 
 

Ha az app főleg olvas (azt nehéz elrontani, max újraolvasod), meg nincsenek nagy összefüggések félig szarul lekezelve, amik miatt a timeout kinyírhatja a konzisztenciát (rendes appban a DB függvény figyel erre, de nem rendes appban a php/python backend akar okos lenni), meg nem létszükséglet, elfut ez egy jobb rammal felszerelt VM-ben magában.

A backendje és a db közé azért raknék valami vpn-t, mysql port az interneten publikus IP-n nem jó ómen, ezért is szokták a backenddel együtt tartani.

Hogy jön ki a 2-5 TB? Van még más is a mysql-en kívül?

Egyébként nem sokat veszíthetsz ha ide _is_ meg máshova _is_ felrakod a cuccot.

Nem tudom h digitalocean ad-e 10 éves mysql-t. AWS ad.

Önmagában egy 80MB-s adatbázist simán fel lehet gyűrni egy 2 eurós vps-re, teljesen jó lesz.

Gábriel Ákos

Jó pár éve volt velük egy rossz tapasztalatom, hogy elkeverték az utalásomat, és minden figyelmeztetés nélkül törölték az adataimat egy VPS-ről, aztán amikor megtalálták az utalást, akkor már nem tudták visszaállítani a dolgokat.

 

No de ha ezt nem számítjuk, elég jó lett a palettájuk:

 

https://www.hetzner.com/dedicated-rootserver

 

.

 

Ezek valós, fizikai szerverek, és nem VPS-ek, igaz? 40 Euróért elég erős gépet lehet kapni. Legalábbis az a 64GB ram nem kevés a mostani 2GB-s szerveremhez képest :- ).

Jó pár éve volt velük egy rossz tapasztalatom, hogy elkeverték az utalásomat, és minden figyelmeztetés nélkül törölték az adataimat egy VPS-ről, aztán amikor megtalálták az utalást, akkor már nem tudták visszaállítani a dolgokat.

Mentés, mint olyan? Sok minden ellen véd...

Na állj. "Vannak problémák". Illyen nincs. Olyan van, hogy megnézed a lekérdezést (mindet, de van slow query log), hogy pontosan mivel, és mennyire sakkozik. Aztán utána látod, hogy minek van értelme. Rendszeresen derül ki, hogy 10-20 miillió sorokkal próbálnak párhuzamosan bohóckodni, és esetleg MyISAM-mal súlyosbítva, aztán néznek.

Hetznernel van 25€ per ho vas 100T trafic, ha ez belefer neked, akkor ezt erdemes megcsekkolni. Tenyleges dedi vas, nem vps.

http://karikasostor.hu - Az autentikus zajforrás.

Szerintem az aukciós gépekre gondolt: https://www.hetzner.com/sb

Nekem is ilyen van sok éve, cseréltem is már kétszer (kellett plusz erőforrás, vagy találtam jobb ajánlatot). IP-k átvihetőek, support rugalmas, mindegyik csere gyorsan lezajlott, előre egyeztetett időpontban elvégezték a kért munkákat (de asszem volt egy egyszeri díja ennek).

Ezek felmondott szerződésekből származó lerakott vasak, jellemzően régebbiek. Amelyiknél látszik hogy nem brand vas (Dell, stb..), vagy nem Xeon van benne, azok mezei desktop gépek, jellemzően Asus alaplappal. Viszont ha elegendő a teljesítményük, akkor tök jó deal, mert ugyanaz a support jár hozzájuk, és nyilván a karbantartás/javítás felelőssége is a Hetzneré. Egyszer volt egy hdd hibám, azt e-mailben jelezve valami 20 percen belül lezavarták a cserét, amiben benne volt a gép leállításának leegyeztetése is. Leállásom 6 év alatt nem volt soha, csak magam által tervezett (gépcsere, és az említett disk csere).

Továbbá tök jó még benne, hogy 2 hétig nem kell fizetni, és ezen időszakban a gép lemondható. Ez nagyon jól jött, mert eleinte ESXi-t használtam, ahol ugye elég fontos a komponensek pontos típusa/verziója, viszont az aukciós listában nem túl részletes a specifikáció. Valami 5-6db-ot próbáltam végig, mire meglett a megfelelő intel nic + hwraid kontroller páros az egyikben. Ja, és a diskek SMART adatait is végignyálaztam, az egyik ilyen tesztgépben 8 éve folyamatosan pörgő WD-k voltak pl. Ha találsz egy jobbat, azt persze talonba teheted, és mellé rendelheted a következőt, arra kell csak figyelni, hogy a 2 hétből ne csússzon ki a dolog. A végén a legszimpibbet meg lehet tartani, a többit pedig el lehet "dobni".

Amúgy egyáltalán nem zavarja őket ez a dolog, automatizált az egész, szóval lehet nyugodtan próbálgatni, persze biztos lenne az a mennyiség aminél már szólnának :)

Egy kicsit most nem értem mi lenne neked a jó, vagyis mire kell neked, mi ez a rendszer.
Van egy adatbázisod, meglátásom szerint kicsi lekérdezési számmal. Igaz nem tudjuk 1-1 lekérdezés mennyire akasztja meg a rendszert, pl akár adatokból adódóan, vagy akár rossz adatbázis-szervezés vagy rossz lekérdezés miatt.
Van emelett egy sok TB-os adatgyüjteményed is.
Nekem ez egyfajta fájl iktató rendszernek tűnik, ahol nagy fájlok vannak tárolva akár, de a fájlok adatai és kereshetősége pedig adatbázis alapu.

Viszont egy érdekes megoldás is az eszembe jutott, nem tudom neked mennyire illeszkedne a rendszeredbe.

Raspberry Pi + 1 db HDD kombinációja. A rapsberry Pi elvileg elég lehet neked kiszolgálni a rendszert, bár ezt neked kell tudnod. Viszont kell sok tárhely + tárhely a DB-nek, azt nem szabad SD kártyára tenni, mert hamar meggyilkolja. Csak az alap rendszer van SD-n vagy csak annyi hogy bootoljon HDD-ről. Direkt minimál a cucc, mert a redundanciát több ilyen modullal teremted meg. 
Az adatbázis mehet online master-slave replikációval akár, az adatok pedig időszakos rsync-el a node-ok között.
Elhelyezése az eszköznek lehet akár valami értelmesem otthoni internet kapcsolat, adatközpont, vagy akár több helyen is lehetnek a node-ok, persze megteremtve a kapcsolat közöttük pl VPN-el.

Elvileg kicsi a fogyasztása, a redundancia megoldott lehet a node-okkal. Kellehet egy terv, az esetleges node kiesésre, hogy ne akkor kamillázd össze a netről éppen mit kell tenni, hogy pl a slave-ből master legyen vagy ilyesmi. Ugyanígy pl HDD vagy Rpi cserére is.
A jól sejtem ez nem saját dolog hanem ügyfélnek szolgáltatod, vagy karban tartod. Így pedig akár az ügyfélnél is lehet node, ami akár belső hálózati eléréssel van, viszont szinronban van a külsőkkel. Így az ügyfélnél vannak adatok, helyileg is, akár rendelkezhet is vele, pl. a szolgáltatás megszüntetésekor, tehát nem kell neked kiadni az adatait, amik az Ő tulajdona.
A slave node-ok jók teljesen arra, hogy lekérdezésekre válaszoljanak, onnan szedj le adatot, fájl.