The first prototype of object storage was seen in 1996. Ten years later, Amazon Web Services launched Amazon S3, and the world began to gradually go crazy over flat address space. Thanks to its handling of metadata and ability to scale without performance degradation, object storage quickly became the standard for most cloud data storage services and beyond. Another important feature is its good adaptability for storing archives and similar rarely used files. Everyone involved in data storage rejoiced and embraced this new technology.
However, there were rumors that object storage is only about big clouds, and if you don’t want solutions from cursed capitalists, creating your own would be very difficult. A lot has been written about deploying your own cloud, but there's little information on creating so-called S3-compatible solutions.
So today we will explore the options of "To have it like the adults, and not CEPH and a larger file", deploy one of them, and check if everything works with Veeam Backup & Replication. It claims to support working with S3-compatible storage, and we will verify that claim.
And what about others?
I suggest starting with a brief overview of the market and options for object storage. The widely recognized leader and standard is Amazon S3. The two closest competitors are Microsoft Azure Blob Storage and IBM Cloud Object Storage.
Is that really all? Are there no other competitors? Of course, there are competitors, but some go their own way, like Google Cloud or Oracle Cloud Object Storage, with incomplete support for the S3 API. Some use old versions of the API, like Baidu Cloud. And some, like Hitachi Cloud, require the application of special logic, which will inevitably cause its own difficulties. In any case, everyone is compared to Amazon, which can be considered the industry standard.
In on-premise oplossingen is de keuze veel groter, dus laten we de belangrijke criteria aanduiden. In principe zijn er maar twee nodig: ondersteuning voor S3 API en gebruik van v4 handtekeningen. Eerlijk gezegd zijn wij als toekomstige klant voornamelijk geïnteresseerd in interfaces voor interactie; de interne werking van de opslag zelf interesseert ons minder.
Aan deze eenvoudige voorwaarden voldoen heel veel oplossingen. Bijvoorbeeld, de klassieke zware bedrijfsoplossingen:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix Buckets
- Pure Storage FlashBlade en StorReduce
- Huawei FusionStorage
Er is een niche van puur softwareoplossingen die out-of-the-box werken:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
En zelfs voor de liefhebbers die graag alles na de assemblage tot in de puntjes afwerken, zijn er opties:
- CEPH in zijn puurste vorm
- Minio (Linux versie, want er zijn veel vragen over de Windows versie)
De lijst is verre van volledig, dit kan in de opmerkingen besproken worden. Vergeet alleen niet om naast de API-compatibiliteit ook de systeemprestaties te controleren voordat je implementeert. Het laatste wat je wilt, is het verlies van terabytes aan gegevens door vastlopende aanvragen. Wees dus niet bang voor belastingtesten. Over het algemeen heeft alle volwassen software die werkt met grote hoeveelheden gegevens minimaal rapporten over compatibiliteit. In het geval van Veeam bestaande voor wederzijdse testen, waarmee we vol vertrouwen kunnen stellen dat onze producten volledig compatibel zijn met specifieke hardware. Dit is al een tweezijdige samenwerking, niet altijd snel, maar we breiden voortdurend de geteste oplossingen uit.
Laten we onze opstelling samenstellen.
Ik wil graag even praten over de keuze van het proefobject.
Ten eerste wilde ik een optie vinden die direct uit de doos werkt. Of op zijn minst met een maximale kans dat het zonder extra moeite zal werken. Dansjes en nachtenlang rommelen met de console zijn erg interessant, maar soms wil je gewoon dat het meteen werkt. En de algehele betrouwbaarheid van zulke oplossingen is meestal ook hoger. En ja, de avontuurlijkheid in ons is verdwenen; we zijn gestopt met in de ramen van onze geliefden klimmen, enz. (c).
Ten tweede, om eerlijk te zijn, komt de noodzaak om met objectopslag te werken vooral voor bij vrij grote bedrijven, dus dit is het geval waarin het niet alleen niet beschamend is om naar enterprise-oplossingen te kijken, maar het zelfs aangemoedigd wordt. Voor zover ik weet, zijn er nog geen voorbeelden van mensen die zijn ontslagen voor het aanschaffen van dergelijke oplossingen.
Gegeven al het bovenstaande, is mijn keuze gevallen op Dell EMC ECS Community Edition. Dit is een zeer interessant project, en ik vind het noodzakelijk om u hierover te vertellen.
Het eerste wat in me opkomt bij het zien van de toevoeging Community Edition is dat het gewoon een kopie is van de volledige ECS met enkele beperkingen die worden opgeheven door een licentie aan te schaffen. Dat is echter niet het geval!
Vergeet niet:
!!!Community Edition is een apart project, gemaakt voor testdoeleinden, en zonder ondersteuning van Dell!!
En je kunt het niet omzetten naar een volledige ECS, zelfs niet als je dat heel graag zou willen.
Laten we het uitzoeken
Veel mensen beschouwen Dell EMC ECS als een van de beste oplossingen wanneer je behoefte hebt aan objectopslag. Alle projecten onder het merk ECS, inclusief commerciële en enterprise-oplossingen, zijn te vinden op . Een gebaar van goede wil van Dell. En naast de software die draait op hun merkhardware, is er een open source versie die je kunt implementeren in de cloud, op een virtuele machine, in een container, of op je eigen hardware. Vooruitlopend hierop - er is zelfs een OVA-versie, die we zullen gebruiken.
De Dell ECS Community Edition is een mini-versie van de volledige software die draait op de merkservers van Dell EMC ECS.
Ik heb vier belangrijke verschillen geïdentificeerd:
- Geen ondersteuning voor encryptie. Jammer, maar niet kritiek.
- Afwezigheid van de Fabric Layer. Dit is verantwoordelijk voor het opbouwen van clusters, resourcebeheer, updates, monitoring en opslag van Docker-images. Hier is het al heel jammer, maar dat is ook weer te begrijpen voor Dell.
- Het meest vervelende gevolg van het vorige punt: de grootte van de node kan niet worden uitgebreid na de installatie.
- Geen technische ondersteuning. Dit is een testproduct dat niet verboden is voor gebruik in kleine installaties, maar persoonlijk zou ik er geen petabytes belangrijke gegevens in willen uploaden. Maar technisch gezien kan niemand je hierin tegenhouden.
En wat is er in de grotere variant?
Laten we met grote stappen door Europa rennen om een completer beeld te krijgen van het ecosysteem.
Ik zal de bewering dat DELL ECS de beste on-prem object storage is, niet bevestigen of ontkrachten, maar als je daar iets over wilt zeggen, lees ik dat graag in de reacties. In elk geval volgens Dell EMC staat stevig in de top vijf van de OBS-markt. Hoewel cloud-based oplossingen daar niet bij worden geteld, is dat een apart gesprek.
Technisch gezien is ECS een objectopslag die toegang tot gegevens biedt via cloudopslagprotocollen. Het ondersteunt AWS S3 en OpenStack Swift. Voor file-enabled buckets ondersteunt ECS NFSv3 voor bestandsgewijze export.
Het proces voor het schrijven van informatie is vrij ongebruikelijk, vooral na de klassieke block storage-systemen.
- Bij het ontvangen van nieuwe gegevens wordt een nieuw object gecreëerd met een naam, gegevens en metadata.
- Objecten worden in chunks van 128 MB verdeeld, en elke chunk wordt meteen op drie nodes geschreven.
- Het indexbestand wordt bijgewerkt, waarin identificatoren en opslaglocaties zijn vastgelegd.
- Het logbestand (write log) wordt bijgewerkt en ook op drie nodes geschreven.
- De klant ontvangt een bericht over een succesvolle registratie
Alle drie de kopieën van de gegevens worden parallel geschreven. De registratie wordt alleen als succesvol beschouwd als alle drie de kopieën succesvol zijn geschreven.
Lezen gaat eenvoudiger:
- De klant vraagt om gegevens.
- In de index wordt de opslaglocatie van de gegevens opgezocht.
- Gegevens worden van één node gelezen en naar de klant gestuurd.
Er zijn behoorlijk wat servers, dus laten we kijken naar de kleinste Dell EMC ECS EX300. Deze begint vanaf 60 TB, met de mogelijkheid om uit te breiden tot 1,5 PB. Zijn grotere broer, de Dell EMC ECS EX3000, kan zelfs 8,6 PB per rek opslaan.
Deploy
Technisch gezien kan Dell ECS CE in principe onbeperkt worden uitgerold. In elk geval heb ik geen duidelijke beperkingen gevonden. Het is echter handig om schaalvergroting te doen door de eerste node te klonen, waarvoor we het volgende nodig hebben:
- 8 vCPU
- 64GB RAM
- 16GB voor het besturingssysteem
- 1TB voor opslag
- De laatste release van CentOS minimal
Dit is een optie voor wanneer je alles zelf vanaf het begin wilt installeren. Voor ons is dit geen relevante optie, omdat ik een OVA-image zal gebruiken voor de deployment.
Maar in elk geval zijn de vereisten behoorlijk streng, zelfs voor één node, en als we de letter van de wet volgen, hebben we vier van dergelijke nodes nodig.
Echter, de ontwikkelaars van ECS CE leven in de echte wereld en de installatie verloopt succesvol, zelfs met één node. De minimale vereisten zijn als volgt:
- 4 vCPU
- 16 GB RAM
- 16 GB voor het besturingssysteem
- 104 GB opslagruimte
Dit zijn precies de middelen die nodig zijn voor het implementeren van de OVA-afbeelding. Al veel menselijker en realistischer.
De installatie-node kan worden verkregen op de officiële . Daar is ook gedetailleerde documentatie te vinden voor de alles-in-één deploy, maar er kan ook verder worden gelezen op de officiële . Daarom zullen we niet diep ingaan op het uitrollen van de OVA, dat kan zonder poespas. Het belangrijkste is om te onthouden dat je voor je opstart beslist de schijf moet uitbreiden tot de vereiste grootte of de benodigde schijven moet koppelen.
Laten we de machine opstarten, de console openen en de beste standaard inloggegevens gebruiken:
- inlog: admin
- wachtwoord: ChangeMe
Vervolgens starten we sudo nmtui en configureren we de netwerkinstellingen — IP/masker, DNS en gateway. Vergeet niet dat er in CentOS minimal geen net-tools zijn, dus controleren we de instellingen via ip addr.
En omdat alleen de dapperen de zeeën bedwingen, doen we een yum update, waarna we rebooten. In feite is dit vrij veilig, aangezien de hele uitrol wordt gedaan via playbooks en alle belangrijke Docker-pakketten op de huidige versie zijn vergrendeld.
Nu is het tijd om het installatie-script te bewerken. Geen mooie vensters of pseudo UI — alles via je favoriete teksteditor. Hoewel er technisch gezien twee paden zijn: je kunt elke opdracht handmatig uitvoeren of direct de configurator videploy starten. Deze opent gewoon de configuratie in vim en start na het afsluiten de controle. Maar het opzettelijk vereenvoudigen van je leven is niet interessant, dus laten we twee opdrachten meer uitvoeren. Hoewel daar geen zin in zit, heb ik je gewaarschuwd =)
Dus, laten we vim ECS-CommunityEdition/deploy.xml doen en de optimaal-minimale wijzigingen aanbrengen zodat ECS kan worden ingeschakeld en werken. De lijst met parameters kan worden ingekort, maar ik heb het als volgt gedaan:
- licensed_accepted: true Je kunt het ook laten zoals het is, dan word je bij de uitrol expliciet gevraagd dit te accepteren en krijg je een leuke zin te zien. Misschien is het zelfs een easter egg.
- De regels autonames: en custom: worden ontcommentarieerd. Geef minimaal één gewenste naam voor de node op — de hostname zal tijdens de installatie door deze naam worden vervangen.
- install_node: 192.168.1.1 Geef het werkelijke IP van de node op. In ons geval gebruiken we hetzelfde als in nmtui.
- dns_domain: geef je eigen domein op.
- dns_servers: schrijf je eigen dns op.
- ntp_servers: je kunt elke server opgeven. Ik heb de eerste de beste uit de pool 0.pool.ntp.org genomen (het werd 91.216.168.42)
- autonaming: custom Als je dit niet uitcommentarieert, wordt de maan Luna genoemd.
- ecs_block_devices:
/dev/sdb
Om onbekende redenen kan hier een niet-bestaande block storage-apparaat aanwezig zijn \/dev\/vda - storage_pools:
leden:
192.168.1.1 Hier geven we weer het echte IP van de node op - ecs_block_devices:
/dev/sdb Повторяем операцию вырезания несуществующих устройств.
Eigenlijk is het hele bestand zeer gedetailleerd beschreven in , maar wie gaat dat nu lezen in zulke onrustige tijden. Daar staat ook dat het minimaal noodzakelijk is om IP en subnetmasker op te geven, maar in mijn lab was zo'n set niet goed op te starten, dus moest ik uitbreiden tot wat hierboven is vermeld.
Na het verlaten van de editor moet je update_deploy \/home\/admin\/ECS-CommunityEdition\/deploy.yml uitvoeren, en als alles goed is gedaan, wordt dit duidelijk aangegeven.
Daarna moet je toch videploy starten, wachten op de omgevingsupdate, en kun je de installatie starten met het commando ova-step1, en na succesvolle uitvoering het commando ova-step2. Belangrijk: stop de scripts niet handmatig! Sommige stappen kunnen aanzienlijke tijd in beslag nemen, kunnen niet in één keer slagen en lijken misschien te falen. Wacht in ieder geval tot het script op natuurlijke wijze is voltooid. Aan het einde moet je ongeveer zo'n bericht zien.
Nu kunnen we eindelijk het WebUI-dashboard openen via het ons bekende IP. Als je tijdens de configuratie niets hebt veranderd, dan zal de standaardaccount root\/ChangeMe zijn. Je kunt zelfs meteen gebruikmaken van onze S3-compatibele opslag. Deze is toegankelijk op poorten 9020 voor HTTP en 9021 voor HTTPS. Nogmaals, als je niets hebt veranderd, zijn de access_key: object_admin1 en secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Maar laten we niet te ver vooruitlopen en beginnen met de basis.
Bij de eerste login word je gedwongen je wachtwoord te wijzigen naar iets passends, wat volledig terecht is. Het hoofd dashboard is uiterst duidelijk, dus laten we iets interessanters doen dan het uitleggen van de voor de hand liggende statistieken. Laten we bijvoorbeeld een gebruiker creëren die we zullen gebruiken om toegang te krijgen tot de opslag. In de wereld van serviceproviders worden deze tenants genoemd. Dit doe je in Manage > Users > New Object User.
Bij het aanmaken van een gebruiker worden we gevraagd een namespace op te geven. Technisch gezien staat niets ons in de weg om er zoveel als er gebruikers zullen zijn te creëren. En omgekeerd. Dit maakt het mogelijk om bronnen onafhankelijk te beheren voor elke tenant.
Daarom kiezen we de benodigde functies en genereren we de gebruikerssleutels. S3/Atmos is voldoende voor mij. Vergeet niet de sleutel op te slaan 😉
De gebruiker is aangemaakt, nu is het tijd om een bucket toe te wijzen. Ga naar Beheren > Bucket en vul de vereiste velden in. Dit is eenvoudig.
Nu is alles klaar voor het echte gebruik van onze S3-opslag.
Stel Veeam in
Zoals we weten, is een van de belangrijkste toepassingen van objectopslag het langdurig opslaan van informatie die zelden wordt geraadpleegd. Een ideaal voorbeeld is de noodzaak om back-ups op een externe locatie op te slaan. In Veeam Backup & Replication wordt deze functie Capacity Tier genoemd.
Laten we de configuratie starten door onze Dell ECS CE in de Veeam-interface toe te voegen. In het tabblad Backup Infrastructure starten we de wizard voor het toevoegen van een nieuwe repository en kiezen we de optie Object Storage.
Kies datgene waarvoor alles is opgezet — S3 Compatible.
In het verschenen venster typen we de gewenste naam in en gaan we naar stap Account. Hier moet je het Service point opgeven in de vorm van , de regio kan je zo laten staan en de aangemaakte gebruiker toevoegen. Een gateway-server is nodig als je opslag op een externe locatie staat, maar dat is een onderwerp voor infrastructuuroptimalisatie en een apart artikel, dus dit kan je gerust overslaan.
Als alles correct is ingevuld en ingesteld, verschijnt er een waarschuwing over het certificaat en vervolgens een venster met de bucket, waar je een map voor onze bestanden kunt aanmaken.
Voltooi de wizard en geniet van het resultaat.
In de volgende stap moet je ofwel een nieuwe Scale-out Backup Repository aanmaken, of onze S3 aan de bestaande toevoegen — deze zal worden gebruikt als Capacity Tier voor archiefopslag. In de huidige release is het niet mogelijk om S3-compatibele opslag direct als een gewone repository te gebruiken. Er zijn te veel vrij onduidelijke problemen die daarvoor opgelost moeten worden, maar het kan allemaal.
Ga naar de repository-instellingen en schakel Capacity Tier in. Het is allemaal transparant, maar er is een interessant detail: als je wilt dat alle gegevens zo snel mogelijk naar de objectopslag worden verzonden, stel dan gewoon 0 dagen in.
Na het doorlopen van de wizard, als je niet wilt wachten, kun je ctrl+rechter muisklik op de repository drukken, de Tiering-job geforceerd starten en bekijken hoe de grafieken omhoogschieten.
Dat was het voorlopig. Ik denk dat ik in mijn opdracht om te laten zien dat block storage niet zo eng is als vaak wordt gedacht, geslaagd ben. Ja, er zijn talloze oplossingen en varianten, maar je kunt niet alles in één artikel behandelen. Laten we daarom ervaringen delen in de comments.
Bron: habr.com
