A világ 1996-ban látta meg az objektumtároló első prototípusát. 10 év múlva az Amazon Web Services elindítja az Amazon S3-at, és a világ szisztematikusan megbolondul a lapos címtér miatt. A metaadatokkal való munkavégzésnek és a terhelés alatti megereszkedés nélküli méretezhetőségnek köszönhetően az objektumtárolás gyorsan a legtöbb felhőalapú adattárolási szolgáltatás szabványává vált, és nem csak ez. További fontos tulajdonsága, hogy kiválóan alkalmas archívumok és hasonló, ritkán használt fájlok tárolására. Mindenki, aki az adattárolásban részt vett, örült, és a karjában viselte az új technológiát.
De az emberek pletykái tele voltak olyan pletykákkal, miszerint az objektumtárolás csak a nagy felhőkről szól, és ha nincs szükséged megoldásokra az átkozott kapitalistáktól, akkor nagyon nehéz lesz saját magadat készíteni. Sokat írtak már a saját felhő telepítéséről, de nem áll rendelkezésre elegendő információ az úgynevezett S3-kompatibilis megoldások létrehozásáról.
Ezért ma kitaláljuk, milyen lehetőségek vannak „Hogy ez olyan, mint a felnőttek, ne a CEPH és egy nagyobb fájl”, telepítjük az egyiket, és ellenőrizzük, hogy minden működik-e a Veeam Backup & Replication segítségével. Azt állítja, hogy támogatja az S3-kompatibilis tárolókkal való munkát, és ezt az állítást tesztelni fogjuk.
Mi van másokkal?
Azt javaslom, hogy kezdje egy kis áttekintéssel a piacról és az objektumtárolási lehetőségekről. Az általánosan elismert vezető és szabvány az Amazon S3. A két legközelebbi követő a Microsoft Azure Blob Storage és az IBM Cloud Object Storage.
Ez minden? Tényleg nincs más versenytárs? Természetesen vannak versenytársak, de néhányan a saját útjukat járják, például a Google Cloud vagy az Oracle Cloud Object Storage, az S3 API hiányos támogatásával. Néhányan az API régebbi verzióit használják, mint például a Baidu Cloud. És néhány, mint például a Hitachi Cloud, különleges logikát igényel, ami minden bizonnyal saját nehézségeket okoz. Mindenesetre mindenkit az iparági szabványnak tekinthető Amazonhoz hasonlítanak.
Az on-premise megoldásokban azonban sokkal nagyobb a választék, ezért vázoljuk fel a számunkra fontos kritériumokat. Elvileg csak kettő elég: az S3 API támogatása és a v4 aláírás használata. Kéz a szívünkben, minket, leendő ügyfelet csak az interakciós felületek érdekelnek, maga a tároló belső konyhája nem annyira.
Számos megoldás megfelel ezeknek az egyszerű feltételeknek. Például a klasszikus vállalati nehézsúlyúak:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix vödrök
- Pure Storage FlashBlade és StorReduce
- Huawei FusionStorage
Van egy rés a tisztán szoftveres megoldásoknak, amelyek már a dobozból is működnek:
- Red Hat Ceph
- SUSE Enterprise Storage
- Felhős
És még azok sem sértődtek meg, akik szeretnek gondosan reszelni összeszerelés után:
- CEPH a legtisztább formájában
- Minio (Linux verzió, mert sok kérdés merül fel a Windows verzióval kapcsolatban)
A lista még korántsem teljes, kommentben meg lehet vitatni. Csak ne felejtse el ellenőrizni a rendszer teljesítményét az API-kompatibilitás mellett a megvalósítás előtt. Az utolsó dolog, amit szeretne, az az, hogy terabájtokat veszítsen az elakadt lekérdezések miatt. Tehát ne szégyellje magát a terhelési tesztekkel. Általában minden felnőtt szoftvernek, amely nagy mennyiségű adattal dolgozik, van legalább kompatibilitási jelentés. Esetében Veeam van a kölcsönös tesztelésről, amely lehetővé teszi számunkra, hogy magabiztosan kijelenthessük, hogy termékeink kompatibilisek bizonyos berendezésekkel. Ez már kétirányú munka, nem mindig gyors, de folyamatosan bővülünk tesztelt megoldások.
Állványunk összeszerelése
A tesztalany kiválasztásáról szeretnék egy kicsit beszélni.
Először is olyan lehetőséget szerettem volna találni, amely azonnal működik. Nos, vagy legalábbis a legnagyobb valószínűséggel, hogy szükségtelen mozdulatok nélkül működni fog. A tamburával táncolni és éjszaka a konzollal bütykölni nagyon izgalmas, de néha azt akarod, hogy azonnal működjön. És az ilyen megoldások általános megbízhatósága általában magasabb. És igen, eltűnt bennünk a kalandozás szelleme, nem másztunk be szeretett asszonyaink ablakaiba stb. (c).
Másodszor, hogy őszinte legyek, meglehetősen nagy cégeknél felmerül az igény az objektumtárolásra, így éppen ez a helyzet, amikor a vállalati szintű megoldások felé nézni nemhogy nem szégyen, de még bátorított is. Mindenesetre még nem tudok olyan példáról, hogy valakit kirúgtak volna ilyen megoldások vásárlása miatt.
A fentiek alapján a választásom esett Dell EMC ECS Community Edition. Ez egy nagyon érdekes projekt, és szükségesnek tartom, hogy meséljek róla.
Az első dolog, ami eszedbe jut, amikor meglátod a kiegészítőt Közösségi kiadás -, hogy ez csak egy teljes értékű ECS másolata, néhány korlátozással, amely a licenc megvásárlásával megszűnik. Szóval nem!
Ne feledje:
!!!A Community Edition egy különálló projekt, amelyet tesztelésre hoztak létre, és a Dell technikai támogatása nélkül!!
És akkor sem lehet teljes értékű ECS-t csinálni, ha nagyon akarod.
Találjuk ki
Sokan úgy gondolják, hogy a Dell EMC ECS szinte a legjobb megoldás, ha objektumtárolásra van szüksége. Az ECS márkanév alatti összes projekt, beleértve a kereskedelmi és a vállalati projekteket is, a . Egyfajta jóindulatú gesztus a Delltől. A márkás hardverükön futó szoftverek mellett pedig létezik egy nyílt forráskódú verzió is, amely a felhőben, virtuális gépen, konténerben vagy bármilyen saját hardveren telepíthető. A jövőre nézve van még egy OVA verzió is, amit használni fogunk.
Maga a DELL ECS Community Edition egy teljes értékű szoftver mini-verziója, amely márkás Dell EMC ECS szervereken fut.
Négy fő különbséget azonosítottam:
- Nincs titkosítási támogatás. Szégyen, de nem kritikus.
- Hiányzik a szövetréteg. Ez a dolog felelős a fürtök felépítéséért, az erőforrás-kezelésért, a frissítésekért, a Docker-képek figyeléséért és tárolásáért. Itt már nagyon sértő, de a Dellt is meg lehet érteni.
- Az előző pont legundorítóbb következménye: a csomópont mérete a telepítés befejezése után nem bővíthető.
- Nincs technikai támogatás. Ez egy tesztelésre szánt termék, amit nem tilos kis telepítésekben használni, de én személy szerint nem mernék oda feltölteni petabájtnyi fontos adatot. De technikailag senki sem akadályozhatja meg ebben.
Mi van a nagy verzióban?
Vágtázzuk át Európát, és menjünk végig vaskalapos megoldásokon, hogy teljesebben megértsük az ökoszisztémát.
Valahogy nem fogom megerősíteni vagy cáfolni azt az állítást, hogy a DELL ECS a legjobb on-prem objektumtároló, de ha van valami mondanivalója a témában, szívesen olvasom kommentben. Legalábbis a verzió szerint A Dell EMC magabiztosan az öt legjobb OBS-piacvezető közé tartozik. Bár ott a felhő alapú megoldásokat nem veszik figyelembe, ez egy külön beszélgetés.
Technikai szempontból az ECS egy objektumtároló, amely felhőalapú tárolási protokollok segítségével biztosít hozzáférést az adatokhoz. Támogatja az AWS S3-at és az OpenStack Swiftet. A fájl-kompatibilis gyűjtőknél az ECS támogatja az NFSv3-at a fájlonkénti exportáláshoz.
Az információk rögzítésének folyamata meglehetősen szokatlan, különösen a klasszikus blokktároló rendszerek után.
- Amikor új adat érkezik, egy új objektum jön létre, amelynek neve, maga az adat és metaadatok is vannak.
- Az objektumok 128 MB-os darabokra vannak osztva, és mindegyik darab egyszerre három csomópontba kerül.
- Frissül az indexfájl, amelyben rögzítésre kerülnek az azonosítók és a tárolási helyek.
- A naplófájl (naplóbejegyzés) frissül, és három csomópontra is be van írva.
- A sikeres rögzítésről üzenetet küldünk az ügyfélnek
Az adatok mindhárom példányát párhuzamosan írjuk. Az írás csak akkor tekinthető sikeresnek, ha mindhárom példány megírása sikeres volt.
Az olvasás könnyebb:
- Az ügyfél adatokat kér.
- Az index azt keresi, hogy hol tárolják az adatokat.
- Az adatok egy csomópontból kerülnek kiolvasásra és elküldésre az ügyfélnek.
Jó néhány szerver létezik, ezért nézzük a legkisebb Dell EMC ECS EX300-at. 60 TB-tól kezdődik, és akár 1,5 PB-ig is megnőhet. Idősebb testvére, a Dell EMC ECS EX3000 pedig rackenként akár 8,6 PB tárolását is lehetővé teszi.
Telepítés
Technikailag a Dell ECS CE tetszőleges méretben telepíthető. Mindenesetre nem találtam kifejezett korlátozást. Kényelmes azonban az összes skálázást a legelső csomópont klónozásával elvégezni, amelyhez szükségünk van:
- 8 vCPU
- RAM 64GB
- 16 GB operációs rendszerhez
- 1 TB közvetlen tárhely
- A CentOS minimal legújabb kiadása
Ez egy olyan lehetőség, amikor mindent saját maga akar telepíteni a kezdetektől fogva. Ez a lehetőség számunkra nem releváns, mert... A telepítéshez az OVA képet fogom használni.
De mindenesetre a követelmények még egy csomópont esetében is nagyon gonoszak, és ha szigorúan betartja a törvény betűjét, akkor négy ilyen csomópontra van szüksége.
Az ECS CE fejlesztői azonban a való világban élnek, és a telepítés akár egy csomóponttal is sikeres, a minimális követelmények pedig a következők:
- 4 vCPU
- 16 GB RAM
- 16 GB az operációs rendszerhez
- Maga a tárhely 104 GB
Ezek az OVA lemezkép telepítéséhez szükséges erőforrások. Már sokkal humánusabb és valósághűbb.
Magát a telepítési csomópontot a hivatalostól szerezheti be . Részletes dokumentáció is található az all-in-one telepítésről, de a hivatalos oldalon is olvashat . Ezért nem fogunk részletesen foglalkozni az OVA kibontásával, ott nincsenek trükkök. A lényeg az, hogy elindítása előtt ne felejtse el bővíteni a lemezt a kívánt kötetre, vagy csatolni a szükségeseket.
Elindítjuk a gépet, megnyitjuk a konzolt, és a legjobb alapértelmezett hitelesítő adatokat használjuk:
- bejelentkezés: admin
- jelszó: ChangeMe
Ezután futtatjuk a sudo nmtui-t, és beállítjuk a hálózati interfészt - IP/maszk, DNS és kapu. Figyelembe véve, hogy a CentOS minimal nem rendelkezik net-eszközökkel, az ip addr segítségével ellenőrizzük a beállításokat.
És mivel csak a bátrak hódítják meg a tengereket, csinálunk egy yum frissítést, ami után újraindítjuk. Valójában teljesen biztonságos, mert... minden üzembe helyezés playbookokon keresztül történik, és minden fontos docker-csomag az aktuális verzióhoz van zárva.
Itt az ideje a telepítő szkript szerkesztésének. Nincsenek díszes ablakok vagy pszeudo felhasználói felület – minden a kedvenc szövegszerkesztőjén keresztül történik. Technikailag két módja van: mindegyik parancsot manuálisan futtathatja, vagy azonnal elindíthatja a videoploy konfigurátort. Egyszerűen megnyitja a konfigurációt a vim-ben, és kilépéskor elkezdi ellenőrizni. De nem érdekes szándékosan egyszerűsíteni az életét, ezért futtassunk még két parancsot. Bár ennek semmi értelme, de figyelmeztettelek =)
Tehát készítsük el a vim ECS-CommunityEdition/deploy.xml fájlt, és végezzük el az optimális minimális változtatásokat, hogy az ECS működjön. A paraméterek listája lerövidíthető, de én így csináltam:
- Licensed_accepted: true Nem kell megváltoztatni, akkor a telepítéskor kifejezetten felkérjük, hogy fogadja el, és egy szép kifejezést fog látni. Talán ez még egy húsvéti tojás is.
- Törölje az autoname: és custom sorok megjegyzését: Adjon meg legalább egy kívánt nevet a csomópontnak - a telepítési folyamat során a gépnév lecserélődik erre.
- install_node: 192.168.1.1 Adja meg a csomópont valós IP-címét. Esetünkben ugyanazt jelöljük, mint az nmtui-ban
- dns_domain: adja meg a domainjét.
- dns_servers: adja meg a DNS-ét.
- ntp_servers: bármelyiket megadhatja. A 0.pool.ntp.org készletből vettem az elsőt, amivel találkoztam (91.216.168.42 lett)
- autonaming: custom Ha nem hagyod ki a megjegyzéseket, a holdat Lunának fogják hívni.
- ecs_block_devices:
/ Dev / sdb
Valamilyen ismeretlen okból előfordulhat, hogy a /dev/vda blokktároló eszköz nem létezik - storage_pools:
tagjai:
192.168.1.1 Itt ismét megadjuk a csomópont valós IP-címét - ecs_block_devices:
/dev/sdb Megismételjük a nem létező eszközök kivágásának műveletét.
Általánosságban elmondható, hogy a teljes fájl nagyon részletesen le van írva , de ki fogja elolvasni ilyen zaklatott időben. Azt is írja, hogy minimum az IP és a maszk megadása elegendő, de az én laboromban egy ilyen beállítás elég rosszul indult, és ki kellett bővítenem a fent megadottra.
A szerkesztőből való kilépés után le kell futtatnia az update_deploy /home/admin/ECS-CommunityEdition/deploy.yml parancsot, és ha minden helyesen történik, akkor erről kifejezetten beszámolunk.
Ezután még le kell futtatni a videoploy-t, megvárni a környezet frissítését, és az ova-step1 paranccsal elindíthatjuk magát a telepítést, majd annak sikeres befejezése után az ova-step2 paranccsal. Fontos: ne állítsa le kézzel a szkripteket! Előfordulhat, hogy egyes lépések jelentős időt vesznek igénybe, első próbálkozásra nem fejeződnek be, és úgy tűnhet, mintha minden elromlott. Mindenesetre meg kell várnia, amíg a szkript természetesen befejeződik. A végén egy ehhez hasonló üzenetet kell látnia.
Most végre megnyithatjuk a WebUI vezérlőpultját az általunk ismert IP használatával. Ha a konfigurációt nem módosították a szakaszban, az alapértelmezett fiók a root/ChangeMe lesz. Akár az S3-kompatibilis tárolónkat is azonnal használhatja. Elérhető a 9020-as portokon a HTTP-hez és a 9021-es portokon a HTTPS-hez. Ismét, ha semmi sem változott, akkor access_key: object_admin1 és secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
De ne menjünk túl magunk elé, és kezdjük sorrendben.
Amikor először jelentkezik be, kénytelen lesz jelszót megfelelőre cserélni, ami teljesen helyes. A fő műszerfal rendkívül áttekinthető, ezért tegyünk valami érdekesebbet, mint a nyilvánvaló mutatók magyarázata. Például hozzunk létre egy felhasználót, akivel hozzáférünk a tárhelyhez. A szolgáltatók világában ezeket bérlőknek hívják. Ezt a Kezelés > Felhasználók > Új objektumfelhasználó menüpontban teheti meg
Felhasználó létrehozásakor meg kell adnunk egy névteret. Technikailag semmi sem akadályoz meg bennünket abban, hogy annyit hozzunk létre, ahány felhasználó. És fordítva. Ez lehetővé teszi az erőforrások önálló kezelését minden bérlő számára.
Ennek megfelelően kiválasztjuk a szükséges funkciókat, és felhasználói kulcsokat generálunk. Nekem elég lesz az S3/Atmos. És ne felejtsd el menteni a kulcsot 😉
A felhasználó létrehozása megtörtént, most ideje kiosztani neki egy vödröt. Nyissa meg a Kezelés > Vödör menüpontot, és töltse ki a kötelező mezőket. Itt minden egyszerű.
Most már minden készen áll az S3 tárolónk harci használatához.
A Veeam beállítása
Emlékszünk tehát, hogy az objektumtárolás egyik fő felhasználási módja a ritkán hozzáférhető információk hosszú távú tárolása. Ideális példa a biztonsági mentések távoli helyen történő tárolásának szükségessége. A Veeam Backup & Replication alkalmazásban ezt a szolgáltatást kapacitásszintnek nevezik.
Kezdjük a beállítással a Dell ECS CE hozzáadásával a Veeam felülethez. A Biztonsági mentési infrastruktúra lapon indítsa el az Új tárhely hozzáadása varázslót, és válassza az Objektumtárolás lehetőséget.
Válasszuk ki, mitől kezdődött – S3-kompatibilis.
A megjelenő ablakban írja be a kívánt nevet, és lépjen a Fiók lépésre. Itt meg kell adnia a Szolgáltatási pontot az űrlapon , a régiót úgy hagyhatjuk, ahogy van, és hozzáadhatjuk a létrehozott felhasználót. Gate szerverre akkor van szükség, ha a tárhelyed távoli helyen található, de ez már az infrastruktúra optimalizálásának témaköre és külön cikk, így itt nyugodtan kihagyhatod.
Ha minden megfelelően meg van adva és konfigurálva, akkor megjelenik egy figyelmeztetés a tanúsítványról, majd egy ablak egy vödörrel, ahol mappát hozhat létre fájljaink számára.
Végigmegyünk a varázslón, és élvezzük az eredményt.
A következő lépés egy új Scale-out Backup Repository létrehozása, vagy az S3 hozzáadása a meglévőhöz – az archívum tárolására szolgáló kapacitásszintként lesz használva. A jelenlegi kiadásban nincs olyan funkció, amely az S3-kompatibilis tárhelyet közvetlenül használja, mint egy normál tárolóhoz. Túl sok, nem nyilvánvaló problémát kell megoldani ahhoz, hogy ez megtörténjen, de bármi lehetséges.
Nyissa meg a lerakat beállításait, és engedélyezze a Kapacitásszintet. Ott minden átlátszó, de van egy érdekes árnyalat: ha azt szeretnénk, hogy minden adat minél hamarabb kerüljön az objektumtárba, csak állítsa 0 napra.
A varázsló végigfutása után, ha nem akar várni, nyomja meg a ctrl+RMB billentyűkombinációt a tárolón, erőteljesen elindítja a Tiring feladatot, és figyelje a grafikonok feltérképezését.
Ez minden most. Azt hiszem, sikerült megmutatnom, hogy a blokktárolás nem olyan ijesztő, mint azt az emberek gondolják. Igen, vannak megoldások és lehetőségek egy kocsira és egy kiskocsira, de nem lehet mindent egy cikkben tárgyalni. Tehát osszuk meg tapasztalatainkat a megjegyzésekben.
Forrás: will.com