Wanneer er meer gegevens zijn dan op ƩƩn schijf past, is het tijd om na te denken over RAID. In mijn jeugd hoorde ik vaak van ouderen: 'Op een dag zullen RAID-systemen tot het verleden behoren, object storage zal de wereld veroveren, en jij weet zelfs niet wat CEPH is,' - daarom was de eerste stap in mijn onafhankelijke leven het creƫren van mijn eigen cluster. Het doel van het experiment was om het interne ontwerp van Ceph te leren kennen en te begrijpen in welke situaties het toepasbaar is. Hoe gerechtvaardigd is de implementatie van Ceph in het MKB, en in het kleinbedrijf? Na een paar jaar gebruik en enkele onomkeerbare dataverliezen begon ik de nuances te begrijpen: het is niet zo zwart-wit. De bijzonderheden van CEPH vormen obstakels voor de brede verspreiding, en hierdoor zijn de experimenten in een impasse beland. Hieronder volgt een beschrijving van alle stappen die zijn doorlopen, de verkregen resultaten en de conclusies die zijn getrokken. Als ingewijde mensen hun ervaringen delen en enkele punten verduidelijken, zou ik dankbaar zijn.
Opmerking: de commentatoren wezen op ernstige fouten in enkele aannames, waardoor het noodzakelijk is om het hele artikel te herzien.
CEPH-strategie
Het CEPH-cluster combineert een willekeurig aantal K-schijven van willekeurige grootte en slaat gegevens op deze schijven op, waarbij elk stukje (standaard 4 MB) een aantal N keren wordt gedupliceerd.
Laten we een eenvoudig geval met twee gelijke schijven overwegen. Je kunt ofwel RAID 1 opzetten, of een cluster met N=2 ā het resultaat zal hetzelfde zijn. Als er drie schijven zijn van verschillende groottes, dan is het gemakkelijk om een cluster met N=2 op te zetten: een deel van de gegevens staat op schijven 1 en 2, een deel op 1 en 3, en een deel op 2 en 3, terwijl dit bij RAID niet mogelijk is (je kunt zo'n RAID opzetten, maar dat zou een perverse situatie zijn). Als er nog meer schijven zijn, dan kan RAID 5 worden gecreĆ«erd; CEPH heeft een analogie ā erasure_code, die in strijd is met de eerdere concepten van de ontwikkelaars, en daarom wordt deze niet overwogen. RAID 5 gaat ervan uit dat er een klein aantal schijven is, en dat ze allemaal in goede staat verkeren. Bij een storing van Ć©Ć©n schijf moeten de andere standhouden totdat de schijf is vervangen en de gegevens daarop zijn hersteld. CEPH echter, bij N>=3, moedigt het gebruik van oude schijven aan, vooral als je meerdere goede schijven hebt voor het opslaan van een kopie van de gegevens, terwijl de resterende twee of drie kopieĆ«n worden opgeslagen op een groot aantal oude schijven. Hierdoor blijft de informatie veilig, zolang de nieuwe schijven functioneren ā zijn er geen problemen, en als er een van hen defect raakt, dan is de gelijktijdige storing van drie schijven die meer dan vijf jaar oud zijn, bij voorkeur van verschillende servers ā een uiterst onwaarschijnlijke gebeurtenis.
Er zijn nuances in de replicatie van kopieĆ«n. Standaard wordt aangenomen dat de gegevens worden verdeeld over een groter aantal (~100 per schijf) distributiegroepen van PG, waarbij elke groep op verschillende schijven wordt gedupliceerd. Stel dat K=6, N=2, dan worden bij uitval van twee willekeurige schijven gegarandeerd gegevens verloren, omdat er volgens de waarschijnlijkheid ten minste Ć©Ć©n PG zal zijn die zich op deze twee schijven bevindt. Het verlies van Ć©Ć©n groep maakt alle gegevens in de pool ontoegankelijk. Als de schijven echter in drie paren worden verdeeld en het is toegestaan om gegevens alleen op schijven binnen Ć©Ć©n paar te bewaren, dan is deze verdeling ook bestand tegen de uitval van een willekeurige schijf, maar bij uitval van twee is de kans op gegevensverlies niet 100%, maar slechts 3/15, en zelfs bij uitval van drie schijven is dat slechts 12/20. Hieruit volgt dat de entropie in de gegevensverdeling niet bijdraagt aan de fouttolerantie. Ook merken we op dat voor een bestandsserver de vrije RAM het responsvermogen aanzienlijk verhoogt. Hoe meer RAM in elke node, en hoe meer RAM in alle nodes ā hoe sneller het zal zijn. Dit is ontegensprekelijk een voordeel van een cluster ten opzichte van een enkele server en, nog meer, een hardware NAS, waar een erg klein volume aan geheugen in is ingebouwd.
Hieruit volgt dat CEPH een goede manier is om met minimale investeringen uit verouderde apparatuur een betrouwbaar opslagsysteem voor gegevens van tientallen TB te creƫren met de mogelijkheid tot schaalvergroting (daarvoor zijn natuurlijk kosten nodig, maar deze zijn gering in vergelijking met commerciƫle SANS).
Implementatie van het cluster
Voor het experiment nemen we een afgeschreven computer Intel DQ57TM + Intel Core i3 540 + 16 GB RAM. We organiseren vier schijven van 2 TB in een soort RAID10, na succesvolle tests voegen we een tweede node en evenveel schijven toe.
We installeren Linux. Van de distributie is het belangrijk dat deze aanpassingen en stabiliteit biedt. Debian en Suse voldoen aan deze eisen. Suse heeft een flexibeler installatiesysteem waarmee je elk pakket kunt uitschakelen; helaas begreep ik niet welke ik zonder schade voor het systeem kon verwijderen. We installeren Debian via debootstrap buster. De optie min-base installeert een niet-functioneel systeem, waarvoor stuurprogramma's ontbreken. Het grootteverschil ten opzichte van de volledige versie is niet zo groot dat we ons daar druk om moeten maken. Aangezien we werken op een fysieke machine, willen we snapshots maken zoals bij virtuele machines. Deze mogelijkheid biedt LVM of btrfs (of xfs of zfs ā het verschil is niet groot). Bij LVM zijn snapshots niet echt sterk. We kiezen voor btrfs. En de bootloader wordt in MBR geplaatst. Het heeft geen zin om de schijf te vervuilen met een FAT-partitie van 50 MB, wanneer we het in een gebied van 1 MB van de partition-table kunnen proppen en alle ruimte voor het systeem kunnen toewijzen. Het nam 700 MB op de schijf in beslag. Hoeveel de basisinstallatie van SUSE was, weet ik niet meer, het leek ongeveer 1.1 of 1.4 GB te zijn.
We installeren CEPH. We negeren versie 12 in de Debian-repository en verbinden direct met de site voor 15.2.3. We volgen de instructies in de sectie 'CEP install handmatig' met de volgende opmerkingen:
- Voordat we de repository verbinden, moeten we gnupg, wget en ca-certificates installeren.
- Na het verbinden van de repository, maar vĆ³Ć³r de installatie van het cluster, is de installatie van de pakketten weggelaten: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr.
- Bij de installatie van CEPH zal om onduidelijke redenen lvm2 proberen te installeren. In principe is het niet erg, maar de installatie eindigt in een fout, waardoor CEPH ook niet geĆÆnstalleerd kan worden.
Deze patch hielp:
cat <> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers Architecture: all Multi-Arch: foreign Version: 113.118 Description: No-install EOF
Cluster overzicht
ceph-osd ā is responsible for data storage on the disk. For each disk, a network service is started that accepts and executes read or write requests for objects. Two partitions are created on the disk. One of them contains information about the cluster, disk number, as well as keys for the cluster. This 1KB information is created once when the disk is added and has never been observed to change. The second partition has no file system and stores binary data of CEPH. Automatic installation in previous versions created an xfs partition of 100MB for administrative information. I converted the disk to MBR and allocated only 16MB ā the service has no complaints. I think xfs could easily be replaced with ext without issues. This partition is mounted in /var/lib/ā¦, where the service reads information about the OSD and also finds a reference to the block device where the binary data is stored. Theoretically, auxiliary services can be placed directly in /var/lib/ā¦, and the disk can be entirely allocated for data. When creating an OSD via ceph-deploy, a rule for mounting the partition in /var/lib/ā¦ is automatically created, and read permissions on the necessary block device are assigned to the ceph user. With manual installation, this must be done manually, as it is not mentioned in the documentation. It is also advisable to specify the osd memory target parameter to ensure sufficient physical memory.
ceph-mds. At a low level, CEPH is an object store. The capability of block storage is reduced to saving each 4MB block as an object. File storage works on the same principle. Two pools are created: one for metadata and the other for data. They are combined into a file system. At this moment, some type of entry is created, so if the file system is deleted but both pools are kept, it cannot be restored. There is a procedure for extracting files by blocks, which I have not tested. The ceph-mds service is responsible for access to the file system. A separate instance of the service is needed for each file system. There is an 'index' option that allows creating a semblance of multiple file systems within one ā this has also not been tested.
ceph-mon ā deze service bewaart de clusterkaart. Het bevat informatie over alle OSD's, het algoritme voor het verdelen van PG's naar OSD's en, het belangrijkst, informatie over alle objecten (de details van dit mechanisme zijn mij niet duidelijk: er is een catalogus /var/lib/ceph/mon/.../store.db, waar een groot bestand van 26 MB in staat, en in de cluster zijn er 105K objecten, wat iets meer dan 256 byte per object betekent. Ik denk dat de monitor een lijst van alle objecten en de PG's waarin ze zich bevinden, opslaat). Beschadiging van deze catalogus leidt tot dataverlies in de cluster. Daarom wordt geconcludeerd dat CRUSH toont hoe PG's zijn verdeeld over OSD's, terwijl de objecten gecentraliseerd worden opgeslagen binnen de database, hoezeer ontwikkelaars ook proberen dit woord te vermijden. Als gevolg hiervan kunnen we, ten eerste, het systeem niet installeren op een USB-stick in RO-modus, aangezien er voortdurend naar de database wordt geschreven, extra schijf is nodig voor deze (waarschijnlijk niet meer dan 1 GB), en ten tweede moet er real-time een kopie van deze database zijn. Als er meerdere monitors zijn, gebeurt failover automatisch, maar in ons geval is er Ć©Ć©n monitor, maximaal twee. Er is een theoretische procedure om de monitor te herstellen op basis van OSD-gegevens; ik heb deze drie keer om verschillende redenen gebruikt, en drie keer waren er geen foutmeldingen, en ook geen gegevens. Helaas werkt dit mechanisme niet. Ofwel gebruiken we een miniatuurpartitie op de OSD en construeren we RAID om de database op te slaan, wat waarschijnlijk een zeer negatieve invloed zal hebben op de prestaties, ofwel bieden we minstens twee betrouwbare fysieke opslagmedia, bij voorkeur USB, om de poorten niet in gebruik te nemen.
rados-gw ā exporteert objectopslag via het S3-protocol en soortgelijke. CreĆ«ert vele pools, maar het is onbekend waarom. Heb er niet echt mee geĆ«xperimenteerd.
ceph-mgr ā bij het installeren van deze service worden verschillende modules gestart. Een daarvan is de niet-deactiveerbare autoscale. Het probeert het juiste aantal PG/OSD te behouden. Als je de verhouding handmatig wilt beheren, kun je het schalen voor elke pool verbieden, maar in dat geval crasht de module door deling door 0, en wordt de clusterstatus ERROR. De module is in Python geschreven, en als je de benodigde regel in het script commentarieert, leidt dit tot deactivatie. Details schuif ik liever aan de kant.
Lijst van gebruikte bronnen:
Scriptlijsten:
Installatie van het systeem via debootstrap
blkdev=sdb1
mkfs.btrfs -f /dev/$blkdev
mount /dev/$blkdev /mnt
cd /mnt
for i in {@,@var,@home}; do btrfs subvolume create $i; done
mkdir snapshot @/{var,home}
for i in {var,home}; do mount -o bind @${i} @/$i; done
debootstrap buster @ http://deb.debian.org/debian; echo $?
for i in {dev,proc,sys}; do mount -o bind /$i @/$i; done
cp /etc/bash.bashrc @/etc/
chroot /mnt/@ /bin/bash
echo rbd1 > /etc/hostname
passwd
uuid=`blkid | grep $blkdev | cut -d '"' -f 2`
cat < /etc/fstab
UUID=$uuid / btrfs noatime,nodiratime,subvol=@ 0 1
UUID=$uuid /var btrfs noatime,nodiratime,subvol=@var 0 2
UUID=$uuid /home btrfs noatime,nodiratime,subvol=@home 0 2
EOF
cat <> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
Package: sudo
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
EOF
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6
apt -yq install --no-install-recommends linux-image-amd64 bash-completion ed btrfs-progs grub-pc iproute2 ssh smartmontools ntfs-3g net-tools man
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6Cluster maken
apt -yq install --no-install-recommends gnupg wget ca-certificates
echo 'deb https://download.ceph.com/debian-octopus/ buster main' >> /etc/apt/sources.list
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
apt update
apt -yq install --no-install-recommends ceph-common ceph-mon
echo 192.168.11.11 rbd1 >> /etc/hosts
uuid=`cat /proc/sys/kernel/random/uuid`
cat < /etc/ceph/ceph.conf
[global]
fsid = $uuid
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
mon allow pool delete = true
mon host = 192.168.11.11
mon initial members = rbd1
mon max pg per osd = 385
osd crush update on start = false
#osd memory target = 2147483648
osd memory target = 1610612736
osd scrub chunk min = 1
osd scrub chunk max = 2
osd scrub sleep = .2
osd pool default pg autoscale mode = off
osd pool default size = 1
osd pool default min size = 1
osd pool default pg num = 1
osd pool default pgp num = 1
[mon]
mgr initial modules = dashboard
EOF
ceph-authtool --create-keyring ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
ceph-authtool --create-keyring ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *'
cp ceph.client.admin.keyring /etc/ceph/
ceph-authtool --create-keyring bootstrap-osd.ceph.keyring --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r'
cp bootstrap-osd.ceph.keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
ceph-authtool ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
ceph-authtool ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
monmaptool --create --add rbd1 192.168.11.11 --fsid $uuid monmap
rm -R /var/lib/ceph/mon/ceph-rbd1/*
ceph-mon --mkfs -i rbd1 --monmap monmap --keyring ceph.mon.keyring
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-mon@rbd1
systemctl start ceph-mon@rbd1
ceph mon enable-msgr2
ceph status
# dashboard
apt -yq install --no-install-recommends ceph-mgr ceph-mgr-dashboard python3-distutils python3-yaml
mkdir /var/lib/ceph/mgr/ceph-rbd1
ceph auth get-or-create mgr.rbd1 mon 'allow profile mgr' osd 'allow *' mds 'allow *' > /var/lib/ceph/mgr/ceph-rbd1/keyring
systemctl enable ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1
ceph config set mgr mgr/dashboard/ssl false
ceph config set mgr mgr/dashboard/server_port 7000
ceph dashboard ac-user-create root 1111115 administrator
systemctl stop ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1Toevoegen van OSD (deel)
apt install ceph-osd
osdnum=`ceph osd create`
mkdir -p /var/lib/ceph/osd/ceph-$osdnum
mkfs -t xfs /dev/sda1
mount -t xfs /dev/sda1 /var/lib/ceph/osd/ceph-$osdnum
cd /var/lib/ceph/osd/ceph-$osdnum
ceph auth get-or-create osd.0 mon 'profile osd' mgr 'profile osd' osd 'allow *' > /var/lib/ceph/osd/ceph-$osdnum/keyring
ln -s /dev/disk/by-partuuid/d8cc3da6-02 block
ceph-osd -i $osdnum --mkfs
#chown ceph:ceph /dev/sd?2
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-osd@$osdnum
systemctl start ceph-osd@$osdnumSamenvatting
Het belangrijkste marketingvoordeel van CEPH is CRUSH ā een algoritme voor het berekenen van de gegevenslocatie. De monitors verspreiden dit algoritme naar de klanten, waarna de klanten rechtstreeks de benodigde node en OSD kunnen opvragen. CRUSH zorgt voor decentralisatie. Het is een klein bestand dat je zelfs kunt afdrukken en aan de muur kunt hangen. De praktijk heeft aangetoond dat CRUSH geen uitputtende kaart is. Wanneer je de monitors vernietigt en opnieuw creĆ«ert, terwijl je alle OSD's en CRUSH behoudt, is dat onvoldoende om het cluster te herstellen. Hieruit volgde de conclusie dat op elke monitor bepaalde metadata over het gehele cluster wordt opgeslagen. De geringe hoeveelheid metadata legt geen beperkingen op aan de grootte van het cluster, maar vereist wel dat je ervoor zorgt dat deze behouden blijft, wat het besparingen op schijfruimte uitsluit door het systeem op een flashstation te installeren en uitsluit clusters met minder dan drie nodes. Het agressieve beleid van de ontwikkelaars met betrekking tot optionele functies. We zijn ver van minimalisme. De documentatie is van het niveau: 'voor wat er is, dank, maar het is erg, erg schraal'. Er is de mogelijkheid om met laag-niveau diensten te interageren, maar de documentatie behandelt dit onderwerp te oppervlakkig, dus het is eerder nee dan ja. Bijna geen kans op gegevensherstel uit een noodsituatie.
Opties voor verdere actie: afstand doen van CEPH en gebruik maken van de eenvoudige multi-schijf btrfs (of xfs, zfs), nieuwe informatie over CEPH verzamelen die het mogelijk maakt om het onder de aangegeven omstandigheden te gebruiken, of als een vorm van bijscholing proberen een eigen opslag te schrijven.
Bron: habr.com
