Szeretnék egy gépet azure vm-re költöztetni. A gép 1-2 TB tárhellyel, ami jelentősen, de napi szinten változik. Néha azonban vannak nagyobb műveletek is, akkor minden változik.
Szeretnék a rendszerről backup és rollback célokkal snapshotokat csinálni, de azure tapasztalatlanságom miatt nem tudom mi a célravezető megoldás. Rollback esetén fontos a gyors visszaállás, a backupnál meg a költséghatékonyság (naponta letölteni a 2 TB-t tisztán nyilván drága mulatság az azure adatforgalomra való tekintettel). Örülnék, ha lehetne távolra backupolni inkrementálisan egy adott időpontbeli állapotot. Alapvetően elegendő néhány mappa snapshotolása, nem feltétlen cél a teljes gép pillanatképe, ha ez egyszerűsít/gyorsít/pénzt kímél.
Ti hogy oldanátok meg ezt? Azure natív gép szintű snapshottal, esetleg zfs snapshot/clone/send távolra másolás?
Szeretném kérni a tanácsotokat, meg mindenfajta ötletet és irányítgatást (pl van értelme egyáltalán az azure backup mellett távoli gépre backupolni? vagy jó ötlet azure diskre zfs-t rakni egy diskkel?).
- 1619 megtekintés
Hozzászólások
en app oldalrol oldanam meg, es zfs snapshot+send
- A hozzászóláshoz be kell jelentkezni
Egy ilyet találtam, ami szimpatikusnak tűnik, de nem tudom mennyi adatforgalmat generál és mennyi plusz erőforrást eszik.
https://stephanvaningen.net/node/14
Érdemes ezt ilyesmi módon csinálni?
Illetve van-e abból gond vagy disk lassulás, hogy a zfs egyetlen virtuális disken van? (nem használtam még zfs-t, eddig btrfs volt mögötte, de kiszerettem belőle)
- A hozzászóláshoz be kell jelentkezni
Ugyan nem ismerem az Azure-t behatoan (meg :D), de en azt gondolom, hogy az ottani objectstore megoldas tokeletes lenne a backup/restor-a, plane, ha ott is van glacier(aws) vagy Coldline(gcp), hogy oda backupolj, ha nem surun allsz vissza. Ezek jo koltseghatekonyak, viszont lassu a visszallas roluk. A masik megoldas, hogy ket szintu backup lesz, a full meg a lassu, hosszutavuba, az incrementalsak a rovidtavu gyors tarba.
Hogy milyen megoldast valasztasz Azure eseten magara a konyvtarak backup-olasara az a kepessegektol fugg, mert a masik kettonel siman mehet cron-bol az awscli vagy a gsutil. De lehet fel is tudod csatolni az objectstore teruletet a gepbe valamilyen FUSE fs-en keresztul.
A kerdesek:
- Tenyleg eleg nehany mappa backupolasa?
- Ezek a mappak helyben kell legyenek, vagy ki lehet valtani oket managed service-ekkel? (pl. nem biztos, hogy local SQl szervert uzemeltetnek felhoben hanem inkabb hasznalnam a cloud megoldasat erre, de nem tudom miket taroltok a gepen)
- A hozzászóláshoz be kell jelentkezni
Van snapshot lehetoseg azureknal is, de a visszaallas valami tarolocseres mokaval oldhato meg, legalabbis ilyet olvastam. Ha azt mondjatok, hogy ez gyors es koltseghatekony, akkor termeszetesen kiprobalom es kialakitom a jo workflowt, igy az erdekel igazan, hogy ez ertelmesen jarhato ut-e a tapasztalatok alapjan.
Linux alapu php szerver lenne, sok fileal, az adatbazis csak 1.5giga de kulon vm lenne, nem ez a kritikus kerdes, mindamellett ha van mariadb/mysql service azureban, akkor az meger egy miset, koszonom az otletet.
Tenyleg eleg nehany mappa mentese.
Az azure helyett aws es tarsai sajnos nem opcio.
Az objectstore visszaallas lassusaga alatt mennyi idore kell gondolnom mondjuk 2 terra adat eseten?
- A hozzászóláshoz be kell jelentkezni
Utolso kerdesedre a valasz az, hogy kiprobalod :D
Altalaban az objectstore-ok feltoltesre gyorsabbak, mint letoltesre. De mi ez a ket terra, ha az adatbazis csak 1.5 giga? Kepek?
Mert akkor ertelmesebb mar alapvetoen az objectstore-ban tarolni a statikus tartalmat es onnan szedni. Siman van altalaban http endpointja egy-egy bucketnek. Vagy CDN, ha multigerional a rendszer.
Alapvetoen jo lenne tundi mit csinalsz, mivel es miert. Ezek utan lehet adni egy cloud-native megoldast.
- A hozzászóláshoz be kell jelentkezni
Igen, jóllátod, nekem új ez a felhő alapú dolog, nem teljesen tudom milyen szolgáltatások vannak, így köszönöm az ötleteket, a fél szavak is segítenek, aminek utána tudok olvasni.
Akkor kicsit leírva konkrétabban a célokat:
Van egy website, amit ki kell szolgálnom, php alapú, nagy látogatottságú és sok adattal bír. A site az rengeteg pdf, képek, doksi stb kiszolgálásval foglalkozik, azokat írja, olvassa, mozgatja, de maguk a fájlok nincsenek DB-ben, csak a referenciájuk, ezért kicsi a DB. A fájlokat nem direktben hanem a php-n keresztül érik el a webes felhasználók, akik leginkább csak magyarországról dolgoznak.
Mivel a site-on SSO hitelesítés, meg egyéb feladatok is vannak, ezért VM-ben gondolkodnék magamtól. Egyrészt mert nincs tapasztalatom containerekben, vagy azure servicekben, kevésbé fog meglepetés érni. Ettől még persze lehet nem ez a jó/optimális megoldás. Másrészt így akkor tudok egyéb feladatokat is egyszerűen tervezni, mint ez a backup dolog és a migrálás is valószínüleg könyebben/hibamentesen megvalósítható. Néha fájl szinten is hozzá kell férnem az adatokhoz adminisztrációs célokkal, nem csak php-n keresztül.
Ezt a rendszert kéne backupolni rendszeresen (lehetőleg távoli gépre is, nem csak azure-be) másrészt félévente esedékes rendszerfrissítések esetén biztosítani a rollback lehetőségét.
A
https://docs.microsoft.com/en-us/azure/storage/common/storage-introduct…
alapján csak akkor lenne nekem jó a blob storage, ha fel lehetne mountolni egy könyvtárba. Az Azure Files az SMB mount miatt nem bizalomgerjesztő, de ebben meggyőzhető vagyok.
- A hozzászóláshoz be kell jelentkezni
Na hat akkor ha sok statikus allomanyrol van szo, akkor mindenkeppen object store-ban gondolkodnek. Ahogy nezem van erre php-s modul is (https://docs.microsoft.com/hu-hu/azure/storage/blobs/storage-quickstart…),ha irni kell, olvasahoz meg egyszeruen csak legeneralod az object html-es url-jet.
Mi mondjuk sok petabyte-nyi kepet tarolunk az egesz vilagon szetszorva multi-regionalisan ilyen modon. Hasznaljuk meg a cloud-ok (aws, gcp) cache funkciojat is, hogy meg gyorsabban elerjuk a tartalmakat.
Szocal itt nem kell cotainer, meg semmi, jo a VM, de a storage szolgaltatás az legyen objectstore inkabb, igy nem kell menteni (azt megcsinalja neked a cloud provider 5x9-ben, a vilagon barhonnan hozzaferhetsz, persze csak ha mutli-regionalis), sot nem csak a programbol hanem barhonnan elered, mondjuk statisztikat nezni, vagy szamlazni (osszekotve a cloud provider bigdata vagy etl szolgaltatasaval).
Szoval en tuti ugy csinalnam, hogy a php-kodban updatelnem azt a reszt, ami a storage-re irja az adatot, hogy lehessen "s3, gcs, azure"-ba is irni akar, majd migralnam az egeszet az objectstore-ba, bekapcsolnam, hogy http-n el lehessen erni az objectumokat (az kb. ugyanaz lenne mint most a konyvtarszerkjezet, csak lenne elotte egy http://azure-objectstore-endpoint/dir/subdir/object.pdf), aztan hajra.
- A hozzászóláshoz be kell jelentkezni
Bevallom ettől kicsit fázok, mert nem tudom hány helyen van file írás a rendszerben, nem én fejlesztettem, elég nagy és komplex rendszer, cachel is rendesen magában.
Az objectstore visszaállítás mennyi idő, szóval mit nyerhetek és mit veszthetek, ha ilyen lesz a rendszerem?
E mellett amúgy megfontolandó a rendszert webapp-ba is áttennem, arra most nagyobb esélyt látok és az objectstore-t is inkább SMB-n csatolnám.
- A hozzászóláshoz be kell jelentkezni
Neked nem kell visszaállítani az objectszore-t. Az van és kész. Magas rendelkezésre állással, a háttérben kitudja hol, hány disken, melyik régióban. De ha nagyon paranoid vagy akkor beállítást egy lifecycle-t az objektumokat, stb. stb. Olvasd el az Azure blob doksijat. Mint mondtam én csak gcp és aws vonalon mozgok egyelőre, de majd megszerzem ebből is a solution architect ha lesz időm. :)
Én a helyedben elkezdenek foglalkozni a cloud rendszerekkel, mert az a jövő, akár tetszik akár nem. Lehet bohóckodni VMekkel, de nem véletlenül vannak managed szervizek, hiszen így csaknem nulla adminisztrációval kapod ugyanazt, csak biztonságosabban, magasabb rendelkezésre állással, olcsóbban (ami azért nem biztos, ki kell számolni).
Én a te helyedben tuti managed sql-t hasznalnek, meg objectszore-t a jövőben. Kezdetnek persze lehet vért izzadni a VM-el, de a felhőben kurvanehéz megoldani managed szervizek nélkül azt amit akarsz, mert pont a másik oldalról közelítik meg a dolgot.
- A hozzászóláshoz be kell jelentkezni
Köszönöm a tanácsokat, már ma is sokat tanultam!
Rollback azért kellene néha, mert vannak olyan nagy változásokat eredményező változások (php kód változik, db változik, fájlok változnak), amik félre tudnak menni (ezen a folyamaton is segítene amúgy az eredeti topicindítóban szereplő remote snapshot, hogy ott lehetne próbálkozni távoli másolaton). És ezt nem árt, ha vissza tudom vonni viszonylag gyorsan, tehát nem az azureban nem bízom, hanem "magamban".
Ez lenne a managed SQLservice?
https://docs.microsoft.com/en-us/azure/mysql/concepts-backup
Ha igen, akkor tetszik, kivéve, hogy itt azt írják, hogy: The recovery time is usually less than 12 hours.
Találtam azure-an olyan App Service-t, hogy "Web App On Linux + MySQL" ami jó kiindulásnak tűnik, de ez alá kéne egyrészt begyógyítanom az SSO-t, másrészt valahogy elérni az objectstore-t.
- A hozzászóláshoz be kell jelentkezni
A gyors visszaalasra javaslom a lifcycle-t ahol ha van versioning bekapcsolva az a tuti. Altalaban meg tudod mondani, hogy mennyi verziot taroljon (mondjuk az utolso 5-ot), aztan ha gebasz van, visszaallitod. Tuti van versioning az azure blob storeban is.
SQL-hez. Sajnos nem ertek az azure-hoz mint mondtam. AWS es GCP eseten egyszeruen multi-az (availability zones) kiepitesben hazsnalnam es kesz, vagy egyszeruen hasznalnam a cloudsql-t (gcp) vagy az RDS-t (aws) es le se szarnam mi hol van. Kell az endpoint aztan annyi. A tobbi a provider dolga. Ezekben az esetekben csak megmondod mekkora legyen a tarterulet, van egy checkbox, hogy legyen e multi-az, ha esetleg felrobbanna egy datacenter teged ne erintsen, meg hogy hogyan backupoljak, ha nem jo a default. Oszt hatradolok. A hatterben meg majd intezkedik a provider, hogy szetszorja a slave-eket valahova, ami engem nem is erdekel. Ha meg beut a mennyko, akkor az egyik atveszi a master helyet es kesz. De ezzel nekem nem kell foglalkoznom. Eygszeruen mindig lesz egy mukodo endpointom, akarhol is legyen az.
Szerintem az Azure-ban is lennie kell ilyennek, kulonben senki sem hasznalna. :D
Sajnalom, hogy nem tudok segiteni az Azure-ban. De ezek szerint van: https://docs.microsoft.com/en-us/azure/mysql/tutorial-design-database-u…
Amugy en azert csinalnek valami cost estimation-t arra, hogy mennyibe fog fajni ez havonta es hogy mennyi lenne, ha nem csinalnad meg beleszamolva a plusz koltsegeit az uzemeltetesnek, a backupolasnak, visszallas/kieses idejere az elvesztett penzt, stb., stb. Mert ha az SLA azt engedi meg, hogy a disater eseten az RTO orak lehetnek, akkor mehet a VM-el bohockodas. Ha viszont azt tudod mondani, hogy ez par masodperc, vagy az SQl sosem fog leallni es kesz, akkor az eleg shiny. :D
Szoval ez mar egy kicsit penzugy is az architektes dolgok mellett. (ITIL Service Design resz)
Huhh, messzire vezet ez :D
- A hozzászóláshoz be kell jelentkezni
Szerintem először meg kell értened a cloud fogalmát és megismerni elemeit. A cloud arról szól, hogy adott szinten nem neked kell üzemeltetni, hanem kvázi készen kapod az adott megoldást. Az kapott megoldást nem kell ismerned részletesen ,mert a szolgáltató megoldja helyetted.
Ajánlom a Pizza as a Service tanulmányozását:)
Pizza as a Service
Rengeteget tudnék írni,de jobb lenne ha bővítenéd tudásod. Vannak elég jó videó alapú oktató anyagok (udemy.com-on biztos), ahol az Azure specifikus szolgáltatásokat át tudod tanulmányozni.
Másik kérdés, ami felmerült bennem, hogy mi alapján választottad az Azure-t?
Ha van lehetőséged, akkor csinálj egy kalkulációt több cloudban,hogy melyikben jársz jobban funkcionalitásban, teljesítményben és főleg árban!
- A hozzászóláshoz be kell jelentkezni
Na igen. En altalaban az AWS-t preferalom, de itt lehet a GCP lenne a jobb. Mondjuk abbol amennyit hallottam barmelyik jo lehet, de erzesre itt GCP-t valasztanek. :D
- A hozzászóláshoz be kell jelentkezni
Koszonom a kommenteket, sokat segitett igy is, azota olvasgatok. Mar tudom melyik iranyba erdemes tesztelnem es koltseget becsulnom.
Jelentkezni fogok, de most visszavonulok tesztelni/terbezni.
Az aws vagy gcp sajnos nem jatszik, nem csak szakmai (es nem is politikai) ervek kerultek figyelembevetelre.
- A hozzászóláshoz be kell jelentkezni
:D
Ismerek en is nehany ilyen projektet, ahol meg lett mondva, hogy Azure es kesz. Az mindegy, hogy a masik kettoben egyszerubb lenne megoldani valamit, mert az Azure.ban meg csak managed szerviz sincs ra. :D
De hat ezt hivjak marketingnek/megvesztegetesnek/stb,/stb. :D
Ahogy a vajarok mondjak: Joszerencset!
- A hozzászóláshoz be kell jelentkezni