Az első objektumtároló prototípus 1996-ban jelent meg a világban. Tíz évvel később az Amazon Web Services elindítja az Amazon S3-at, és a világ fokozatosan megőrül a lapos címrendszerért. A metadaták kezelésével és a skálázhatóságával, amely lehetővé teszi a terhelés alatti folytatást, az objektumtárolók gyorsan a legtöbb felhőtárolási szolgáltatás szabványává váltak, nemcsak ott. Egy másik fontos jellemző a jó alkalmazhatóság az archívumok és hasonló, ritkán használt fájlok tárolására. Mindenki, aki adatkezeléssel foglalkozott, ujjongott, és a vállára vette az új technológiát.
De az emberek pletykái azt állították, hogy az objektumtárolók csak a nagy felhőkről szólnak, és ha nem akarsz a megátkozott kapitalisták megoldásaival élni, akkor sajátot csinálni nagyon nehéz lesz. Az önálló felhő kiépítéséről már sokat írtak, de a S3-kompatibilis megoldások létrehozásáról kevés információ áll rendelkezésre.
Ezért ma megvizsgáljuk, milyen lehetőségek vannak "Ahhoz, hogy úgy csináljunk, mint a felnőttek, ne pedig a CEPH-t használva és a fűrészt nagyobbra venni", kiépítünk egyet, és ellenőrizzük, hogy minden jól működik-e a Veeam Backup & Replication segítségével. Ez a szoftver hirdeti az S3-kompatibilis tárolókkal való együttműködés támogatását, és ezt az állítást fogjuk ellenőrizni.
De mi a helyzet a többiekkel?
Azt javaslom, hogy egy rövid piaci áttekintéssel kezdjük és az objektumtárolók lehetőségeivel. Az elismert vezető és szabvány az Amazon S3. Két közvetlen követője a Microsoft Azure Blob Storage és az IBM Cloud Object Storage.
De tényleg ennyi? Tényleg nincsenek más versenytársak? Természetesen vannak versenytársak, de valaki más utat jár be, mint a Google Cloud vagy az Oracle Cloud Object Storage, amelyek nem teljes támogatással rendelkeznek az S3 API-hoz. Valaki régi API verziókat használ, mint a Baidu Cloud. Mások, mint a Hitachi Cloud, különös logika alkalmazását követelik meg, ami mindenképpen nehézségeket okoz. Minden esetben a versenytársakat az Amazonhoz hasonlítják, amelyet iparági szabványnak lehet tekinteni.
Az on-premise megoldások esetében a választék lényegesen nagyobb, ezért jelöljük meg a számunkra fontos kritériumokat. Elvben elegendő lenne kettő: az S3 API támogatása és a v4 aláírás használata. Őszintén szólva, mint potenciális ügyfelet, csak az interakciós felületek érdekelnek, a tároló belső működése már annyira nem lényeges számunkra.
Ezekhez a egyszerű feltételekhez nagyon sok megoldás illeszkedik. Például a klasszikus vállalati nehézsúlyúak:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix Buckets
- Pure Storage FlashBlade és StorReduce
- Huawei FusionStorage
Van egy niche, amely tisztán szoftveres megoldásokat kínál, dobozból működnek:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
Sőt, még azokat sem hagyták figyelmen kívül, akik gondosan szeretnék a legyártott terméket finomhangolni:
- CEPH tiszta formában
- Minio (Linux verzió, mert a Windows verzióval sok kérdés merül fel)
A lista messze nem teljes, ezt meg lehet beszélni a megjegyzésekben. Csak ne felejtsétek el a bevezetés előtt ellenőrizni nemcsak az API kompatibilitást, hanem a rendszer teljesítményét is. Az utolsó dolog, amire szükségetek van, az adatvesztés tucatnyi terabájtnyi mennyiség miatt a felfüggesztett kérések miatt. Szóval ne habozzatok a terheléses tesztelésekkel. Valójában minden komoly szoftver, amely nagy mennyiségű adattal dolgozik, legalábbis kompatibilitási jelentéseket tartalmaz. A Veeam tartalmaz közös tesztelés céljából, amely lehetővé teszi, hogy bátran kijelentsük a termékeink teljes kompatibilitását a konkrét berendezésekkel. Ez már egy kétirányú munka, nem mindig gyors, de folyamatosan bővítjük a tesztelt megoldásokat.
Összegyűjtjük a standunkat
Szeretnék egy kicsit beszélni a kiválasztás módjáról.
Először is, olyan lehetőséget szerettem volna találni, amely azonnal dobozból működik. Vagy legalábbis a lehető legnagyobb valószínűséggel működik felesleges mozdulatok nélkül. A dobolás és a konzol éjszakai ütögetése nagyon izgalmas, de néha szeretném, ha azonnal működne. Ráadásul az ilyen megoldások általános megbízhatósága általában magasabb. Igen, mi elvesztettük a kalandvágyat, már nem mászunk be az ablakokon kedvenc hölgyeinkhez, stb. (c).
Másodszor, ha őszintén nézzük, az objektumtárolókkal való munka szükséglete általában nagy cégek esetében merül fel, így ez az az eset, amikor érdemes az enterprise szintű megoldások felé nézni, nemcsak hogy nem szégyen, hanem egyenesen ösztönözve van. Mindenesetre nem tudok olyan példát, ahol valakit elbocsátottak volna hasonló megoldások megvásárlása miatt.
Mindezekből kiindulva, a választásom a következőre esett Dell EMC ECS Community Edition. Ez egy nagyon érdekes projekt, és szükségesnek tartom, hogy meséljek róla.
Elsőnek, ami eszembe jut a kiegészítés láttán, Community Edition — hogy ez egyszerűen a teljes értékű ECS egy korlátozásokkal teli másolata, amit a licensz megvásárlásával lehet eltüntetni. De nem!
Emlékezzetek:
!!!A Community Edition egy külön projekt, amelyet tesztelésre hoztak létre, és nem jár Dell részéről támogatással!!
És ezt nem lehet teljes értékű ECS-vé alakítani, még ha nagyon szeretnénk is.
Nézzük meg alaposabban
Sokan úgy vélik, hogy a Dell EMC ECS talán a legjobb megoldás, ha objektum tárolásra van szükség. Minden ECS márkájú projekt, beleértve a kereskedelmi és vállalati verziókat is, a . Ez egyfajta jóakarat a Delltől. És a saját hardveren futó szoftver mellett létezik egy nyílt forráskódú verzió, amelyet fel lehet állítani felhőben, virtuális gépen, konténerben vagy bármilyen saját hardveren. Előreugorva— létezik még OVA verzió is, amelyet mi is használni fogunk.
A DELL ECS Community Edition egy mini változata a teljes szoftvernek, amely Dell EMC ECS márkájú szervereken működik.
Négy fő különbséget emeltem ki:
- Nincs titkosítási támogatás. Szomorú, de nem kritikus.
- Hiányzik a Fabric Layer. Ez a dolog felel a klaszterek felépítéséért, az erőforrások kezeléséért, frissítésekért, megfigyelésért és Docker képek tárolásáért. Itt már nagyon sajnálatos, de a Dellt is meg lehet érteni.
- A legrosszabb következmény az előző pontból: a csomópont mérete nem bővíthető a telepítés befejezése után.
- Nincs technikai támogatás. Ez egy tesztelésre szánt termék, amelyet kicsi telepítésekhez szabad használni, de én személy szerint nem merném petabájtnyi fontos adatot beletenni. De technikailag senki sem akadályozhatja meg, hogy ezt megtegye.
Mi a helyzet a nagyobb verzióval?
Fussunk gyorsan át az hardveres megoldásokon, hogy teljesebb képet kapjunk az ökoszisztémáról.
Nem akarom megerősíteni vagy cáfolni azt az állítást, hogy a DELL ECS a legjobb on-prem objektum tároló, de ha van véleményed erről, szívesen olvasom a megjegyzésekben. Mindenesetre az a Dell EMC magabiztosan a vezető OBS piac öt legnagyobb szereplője között van. Bár a felhőalapú megoldásokat nem veszik figyelembe, de ez már egy másik téma.
Műszaki szempontból az ECS egy objektumtároló, amely adatokat biztosít a felhőtárolás protokolljain keresztül. Támogatja az AWS S3-at és az OpenStack Swift-t. Az ECS a fájlokkal rendelkező tárolók számára NFSv3-at támogat a fájlszintű exportálás lehetőségére.
Az információ rögzítési folyamata meglehetősen szokatlan, különösen a klasszikus blokktároló rendszerek után.
- Új adatok érkezésekor egy új objektum jön létre, amelynek van neve, maguk az adatok és metaadatok.
- Az objektumok 128 MB-ra oszlanak, és minden darab azonnal három csomópontra kerül rögzítésre.
- Frissül az indexfájl, amelyben az azonosítók és a tárolás helyei vannak rögzítve.
- Frissül a naplófájl (rögzítési napló) is, és azt is három csomópontra írják.
- Az ügyfél értesítést kap a sikeres rögzítésről.
Mindhárom adatmásolat párhuzamosan íródik. A rögzítés csak akkor tekinthető sikeresnek, ha mindhárom másolat sikeresen íródott.
Az olvasás sokkal egyszerűbb:
- Az ügyfél adatokat kér.
- Az indexben megkeressük az adatok tárolási helyét.
- Az adatok egy csomópontból kerülnek olvasásra és az ügyfélnek elküldésre.
Több szerver is létezik, így most a legkisebb Dell EMC ECS EX300-at nézzük meg. Ez 60 TB-tól kezdődik, a mérete pedig 1,5 PB-ra növelhető. A nagyobb testvére, a Dell EMC ECS EX3000 már akár 8,6 PB-ot is tárol egy állványon.
Deploy
Műszakilag a Dell ECS CE tetszőlegesen nagyra méretezhető. Mindenesetre kifejezetten nincsenek explicit korlátozások. Azonban az összes méretezés kényelmesen a legelső csomópont klónozásával történik, amihez szükség lesz:
- 8 vCPU
- 64GB RAM
- 16GB az operációs rendszerhez
- 1TB a tényleges tárolásra
- A legújabb CentOS minimal kiadás
Ez a lehetőség akkor jöhet szóba, ha mindent magunk akarunk telepíteni az elejétől. Számunkra ez a lehetőség nem releváns, mivel az OVA képet fogom használni a telepítéshez.
De mindenesetre az igények nagyon bonyolultak, még egy csomópontra is, és ha a törvény betűje szerint járunk el, akkor négy ilyen csomópont szükséges.
Azonban az ECS CE fejlesztői a valós világban élnek, és a telepítés sikeresen végbemegy egy csomóponttal is, a minimális követelmények a következők:
- 4 vCPU
- 16 GB RAM
- 16 GB az operációs rendszerhez
- 104 GB a tárolásra
Ezekre az erőforrásokra van szükség az OVA kép telepítéséhez. Ez már sokkal emberségesebb és reálisabb.
Magát a telepítési csomópontot hivatalos forrásból is beszerezhetjük. Itt található részletes dokumentáció az egyben való telepítésről, de érdemes elolvasni a hivatalos oldalon is. Ezért nem fogunk részletesen beszélni az OVA telepítéséről, az viszonylag egyszerű. A legfontosabb, hogy ne felejtsük el a futtatása előtt bővíteni a lemezt a megfelelő méretre, vagy csatlakoztatni a szükséges eszközöket.
Indítsuk el a gépet, nyissuk meg a konzolt, és használjuk a legjobb alapértelmezett hitelesítő adatokat:
- felhasználónév: admin
- jelszó: ChangeMe
Ezután futtassuk a sudo nmtui parancsot, és állítsuk be a hálózati interfészt – IP/maska, DNS és átjáró. Ne feledjük, hogy a CentOS minimalban nincs net-tools, a beállításokat az ip addr paranccsal ellenőrizzük.
Mivel csak a bátor emberek hódítják meg a tengereket, végezzünk el egy yum update-et, majd utána reboot. Valójában ez eléggé biztonságos, mivel az egész telepítés playbookokon keresztül történik, és minden fontos Docker csomag rögzítve van a jelenlegi verzióra.
Most itt az ideje szerkeszteni a telepítő scriptet. Nincsenek szép ablakok vagy ál UI – minden a kedvenc szövegszerkesztőddel. Technikai szempontból két út van: vagy kézzel futtatod minden parancsot, vagy azonnal elindítod a videploy konfigurálót. Ez egyszerűen megnyitja a konfigurációt vim-ben, és a kilépéskor elindítja a validálását. De tudatosan nem érdekes megkönnyíteni az életünket, így két parancsot többet hajtunk végre. Bár semmi értelme ennek, figyelmeztettelek =)
Tehát nyissuk meg a vim ECS-CommunityEdition/deploy.xml fájlt, és végezzük el az optimális minimum módosításokat, hogy az ECS működjön. A paraméterek listáját lehetne rövidíteni, de én így csináltam:
- licensed_accepted: true Nem kötelező megváltoztatni, akkor a telepítés során nyíltan megkérik, hogy fogadd el, és megmutatnak egy kedves üzenetet. Lehet, hogy ez egyfajta húzás is.
- Kommentáljuk ki az autonames: és custom: sorokat. Legalább egy kívánt nevet be kell írni a csomóponthoz – a hostname a telepítés során erre fog cserélődni.
- install_node: 192.168.1.1 Adja meg a csomópont valós IP címét. Ebben az esetben a nmtui-ben megadottal megegyezőt használunk.
- dns_domain: írja be a saját doménjét.
- dns_servers: írja be a saját DNS szervereit.
- ntp_servers: bármelyik megadható. Én az első, a 0.pool.ntp.org poolból választottam (a választott 91.216.168.42 lett).
- autonaming: custom Ha nem kommentálja ki, akkor a hold Luna néven fog működni.
- ecs_block_devices:
/dev/sdb
Valamilyen oknál fogva itt megjelenhet egy nem létező block storage eszköz /dev/vda. - storage_pools:
members:
192.168.1.1 Itt ismét a csomópont valódi IP-jét kell megadni. - ecs_block_devices:
/dev/sdb Повторяем операцию вырезания несуществующих устройств.
Az egész fájl nagyon részletesen van leírva a , de ki fogja ezt olvasni ilyen nyugtalan időben. Ott van írva, hogy a minimálisan elegendő az IP és a maszk megadása, de nekem a laborban ezzel a készlettel nem ment jól, és ki kellett bővíteni a fentiekben megadottak szerint.
A szerkesztőből való kilépés után futtatni kell az update_deploy /home/admin/ECS-CommunityEdition/deploy.yml parancsot, és ha minden rendben ment, erről egyértelműen értesítést kapunk.
Ezután mégis el kell indítani a videploy-t, meg kell várni a környezet frissítését, és elindíthatjuk magát az telepítést az ova-step1 parancs segítségével, majd a sikeres végrehajtás után az ova-step2-t. Fontos: ne állítsuk le a scriptet kézzel! Néhány lépés jelentős időt vehet igénybe, nem mindig sikerül elsőre, és úgy tűnhet, hogy minden tönkrement. Mindenesetre meg kell várni a script természetes befejezését. A végén valami ilyesmit kell látnunk.
Most végre megnyithatjuk a WebUI vezérlőpultot a jól ismert IP-n. Ha a konfigurációs lépésnél nem változtattunk, a alapértelmezett felhasználónév root/ChangeMe lesz. Az S3-kompatibilis tárolónkat is azonnal használhatjuk. Hozzáférhető a 9020-as porton HTTP-n, és a 9021-es porton HTTPS-en. Újra, ha semmit nem változtattunk, a access_key: object_admin1 és secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
De ne siessünk ennyire, kezdjük a legelején.
Első belépéskor kötelezően kérni fogják, hogy változtassunk egy megfelelő jelszót, ami abszolút helyénvaló. A fő irányítópult rendkívül érthető, ezért csináljunk valami érdekesebbet, mint az nyilvánvaló metrikák magyarázata. Például létrehozunk egy felhasználót, amelyet tárolóra való hozzáféréshez fogunk használni. A szolgáltatók világában ezt tenantnak nevezik. Ezt a Manage > Users > New Object User menüpont alól lehet megtenni.
A felhasználó létrehozásakor meg kell adnunk a namespace-t. Technikai értelemben nincs akadálya, hogy annyi felhasználót hozzunk létre, ahány csak szükséges. És fordítva. Ez lehetővé teszi az erőforrások független kezelését minden egyes tenant számára.
Ezért válasszuk ki a szükséges funkciókat és generáljuk le a felhasználói kulcsokat. Nekem elegendő lesz az S3/Atmos. És ne felejtsük el elmenteni a kulcsot 😉
A felhasználó létrehozása után ideje, hogy létrehozzunk neki egy bucketet. Menjünk a Manage > Bucket menüpontra, és töltsük ki a szükséges mezőket. Itt minden egyszerű.
Most már minden készen áll az S3 tárolónk harci jellegű használatára.
Beállítjuk a Veeam-et.
Tehát, ahogy emlékszünk, az objektum tárolók egyik fő alkalmazása a ritkán használt információk tartós tárolása. Ideális példa a távoli helyszínen történő biztonsági mentések tárolásának szükségessége. A Veeam Backup & Replication programban ezt a funkciót Capacity Tier-nek hívják.
Kezdjük a konfigurálást azzal, hogy hozzáadjuk a Dell ECS CE-t a Veeam felületéhez. A Backup Infrastructure fülön elindítjuk az új tároló hozzáadását segédprogramot, és kiválasztjuk az Object Storage lehetőséget.
Válasszuk ki azt, amiért mindez készült – S3 Compatible.
A megjelenő ablakban megadjuk a kívánt nevet, majd áttérünk az Account lépésre. Itt meg kell adni a Service point-ot a következő formátumban: , a régiót hagyhatjuk úgy, ahogy van, és hozzáadhatjuk a létrehozott felhasználót. A gateway szerver szükséges, ha a tárolónk távoli helyszínen található, de ez már az infrastruktúra optimalizálásának témája és egy külön cikk, így ezt itt nyugodtan átugorhatjuk.
Ha minden helyesen van megadva és beállítva, akkor figyelmeztetés jelenik meg a tanúsítványról, majd az ablak megnyílik, ahol létrehozhatunk mappát a fájljaink számára.
Végigmegyünk a varázslón, és élvezzük az eredményt.
A következő lépésben új Scale-out Backup Repository-t kell létrehozni, vagy hozzá kell adni a meglévő S3-hoz — ez a Capacity Tier-ként fog szolgálni az archív tároláshoz. A S3-compatibilis tárolók közvetlen használata, mint egy normál tároló, a jelenlegi kiadásban nem lehetséges. Túl sok meglehetősen nem nyilvánvaló problémát kell megoldani ehhez, de minden elképzelhető.
Belépünk a tároló beállításaiba, és engedélyezzük a Capacity Tier-t. Ott mindent tisztán láthatunk, de van egy érdekes szempont: ha azt szeretnénk, hogy minden adat a lehető leghamarabb kerüljön az objektum tárolóra, egyszerűen állítsuk 0 napra.
A varázslón való végigmenetel után, ha nem akarunk várni, megnyomhatjuk a Ctrl+jobboldali kattintást a tárolón, hogy kényszerített Tiering job-ot indítsunk el, és figyelemmel kísérhetjük, hogyan emelkednek a grafikonok.
Eddig ennyit. Úgy érzem, sikerült demonstrálnom, hogy a blokktárolók nem olyan ijesztőek, mint ahogyan azt sokan gondolják. Igen, rengeteg megoldás és végrehajtási lehetőség létezik, de egyetlen cikkben mindent nem lehet lefedni. Ezért osszák meg tapasztalataikat a hozzászólásokban.
Forrás: habr.com
