Aquest article va ser escrit per ajudar-vos a triar la solució adequada per a vosaltres mateixos i entendre les diferències entre SDS com ara Gluster, Ceph i Vstorage (Virtuozzo).
El text utilitza enllaços a articles amb una divulgació més detallada de determinats problemes, de manera que les descripcions seran el més breus possibles, utilitzant punts clau sense pelusa innecessària i informació introductòria que, si ho desitgeu, podeu obtenir de manera independent a Internet.
De fet, per descomptat, els temes plantejats requereixen els tons del text, però al món modern cada cop més gent no li agrada llegir molt))), de manera que podeu llegir ràpidament i triar, i si hi ha alguna cosa. no està clar, seguiu els enllaços o google paraules poc clares))), i aquest article és com un embolcall transparent per a aquests temes profunds, que mostra el farcit: els principals punts clau de cada decisió.
Glúster
Comencem per Gluster, que és utilitzat activament pels fabricants de plataformes hiperconvergents amb SDS basades en codi obert per a entorns virtuals i que es pot trobar al lloc web de RedHat a l'apartat d'emmagatzematge, on podeu triar entre dues opcions de SDS: Gluster o Ceph.
Gluster consta d'una pila de traductors: serveis que realitzen tota la feina de distribució de fitxers, etc. Brick és un servei que dóna servei a un disc, el volum és un volum (pool) que uneix aquests maons. A continuació ve el servei per distribuir fitxers en grups mitjançant la funció DHT (taula hash distribuïda). No inclourem el servei Sharding a la descripció, ja que els enllaços següents descriuran els problemes associats amb ell.
Quan s'escriu, el fitxer sencer s'emmagatzema al brick i la seva còpia s'escriu simultàniament al brick al segon servidor. A continuació, el segon fitxer s'escriurà al segon grup de dos maons (o més) en servidors diferents.
Si els fitxers tenen aproximadament la mateixa mida i el volum només consta d'un grup, tot està bé, però en altres condicions sorgiran els problemes següents a partir de les descripcions:
- L'espai en grups s'utilitza de manera desigual, depèn de la mida dels fitxers i si no hi ha prou espai al grup per escriure un fitxer, rebreu un error, el fitxer no s'escriurà i no es redistribuirà a un altre grup. ;
- quan escriu un fitxer, IO només va a un grup, la resta estan inactius;
- no podeu obtenir IO de tot el volum quan escriviu un fitxer;
- i el concepte general sembla menys productiu a causa de la manca de distribució de dades en blocs, on és més fàcil equilibrar i resoldre el problema de la distribució uniforme, i no com ara tot el fitxer entra en un bloc.
De la descripció oficial també involuntàriament arribem a entendre que gluster funciona com a emmagatzematge de fitxers a la part superior del RAID de maquinari clàssic. Hi ha hagut intents de desenvolupament per tallar fitxers (Sharding) en blocs, però tot això és un afegit que imposa pèrdues de rendiment a l'enfocament arquitectònic ja existent, a més de l'ús de components distribuïts lliurement amb limitacions de rendiment com Fuse. No hi ha serveis de metadades, cosa que limita el rendiment i les capacitats de tolerància a errors de l'emmagatzematge quan es distribueixen fitxers en blocs. Es poden observar millors indicadors de rendiment amb la configuració "Replicat distribuït" i el nombre de nodes hauria de ser almenys 6 per organitzar una rèplica fiable 3 amb una distribució òptima de càrrega.
Aquestes troballes també estan relacionades amb la descripció de l'experiència de l'usuari i en comparació amb , i també hi ha una descripció de l'experiència que condueix a la comprensió d'aquesta configuració més productiva i més fiable
La imatge mostra la distribució de càrrega en escriure dos fitxers, on les còpies del primer fitxer es distribueixen entre els tres primers servidors, que es combinen al grup del volum 0, i tres còpies del segon fitxer es col·loquen al segon grup volum1 de tres. servidors. Cada servidor té un disc.
La conclusió general és que es pot utilitzar Gluster, però tenint en compte que hi haurà limitacions en el rendiment i la tolerància a errors que creen dificultats en determinades condicions d'una solució hiperconvergent, on també es necessiten recursos per a les càrregues de càlcul dels entorns virtuals.
També hi ha alguns indicadors de rendiment de Gluster que es poden aconseguir sota determinades condicions, limitades a
Ceph
Ara mirem Ceph a partir de les descripcions d'arquitectura que vaig poder fer També hi ha una comparació entre , on podeu entendre immediatament que és aconsellable desplegar Ceph en servidors separats, ja que els seus serveis requereixen tots els recursos de maquinari en càrrega.
arquitectura més complex que Gluster i hi ha serveis com els serveis de metadades, però tota la pila de components és força complexa i poc flexible per utilitzar-la en una solució de virtualització. Les dades s'emmagatzemen en blocs, el que sembla més productiu, però en la jerarquia de tots els serveis (components), hi ha pèrdues i latència en determinades càrregues i condicions d'emergència, per exemple les següents
A partir de la descripció de l'arquitectura, el cor és CRUSH, gràcies al qual es selecciona la ubicació per emmagatzemar les dades. A continuació ve PG: aquesta és l'abstracció (grup lògic) més difícil d'entendre. Els PG són necessaris per fer que CRUSH sigui més efectiu. L'objectiu principal de PG és agrupar objectes per reduir el consum de recursos, augmentar el rendiment i l'escalabilitat. Abordar objectes directament, individualment, sense combinar-los en un PG seria molt car. OSD és un servei per a cada disc individual.
Un clúster pot tenir un o més conjunts de dades per a diferents propòsits i amb diferents configuracions. Les piscines es divideixen en grups d'ubicació. Els grups d'ubicació emmagatzemen objectes als quals accedeixen els clients. Aquí és on acaba el nivell lògic i comença el nivell físic, perquè a cada grup de col·locació se li assigna un disc principal i diversos discs de rèplica (quants depenen exactament del factor de rèplica de l'agrupació). En altres paraules, a nivell lògic l'objecte s'emmagatzema en un grup de col·locació específic i, a nivell físic, als discs que se li assignen. En aquest cas, els discs es poden localitzar físicament en diferents nodes o fins i tot en diferents centres de dades.
En aquest esquema, els grups de col·locació es veuen com un nivell necessari per a la flexibilitat de tota la solució, però al mateix temps, com una baula addicional d'aquesta cadena, que involuntàriament suggereix una pèrdua de productivitat. Per exemple, quan escriu dades, el sistema ha de dividir-les en aquests grups i després a nivell físic en el disc principal i els discos per a les rèpliques. És a dir, la funció Hash funciona en cercar i inserir un objecte, però hi ha un efecte secundari: són costos molt elevats i restriccions a l'hora de reconstruir el hash (quan s'afegeix o s'elimina un disc). Un altre problema hash és la ubicació clarament clavada de les dades que no es poden canviar. És a dir, si d'alguna manera el disc està sota una càrrega més gran, el sistema no té l'oportunitat de no escriure-hi (seleccionant un altre disc), la funció hash obliga a localitzar les dades d'acord amb la regla, per molt dolentes que siguin. el disc ho és, de manera que Ceph menja molta memòria quan es reconstrueix el PG en cas d'autocuració o d'augment de l'emmagatzematge. La conclusió és que Ceph funciona bé (encara que lentament), però només quan no hi ha escala, situacions d'emergència o actualitzacions.
Per descomptat, hi ha opcions per augmentar el rendiment mitjançant la memòria cau i la compartició de la memòria cau, però això requereix un bon maquinari i encara hi haurà pèrdues. Però, en general, Ceph sembla més temptador que Gluster per productivitat. A més, a l'hora d'utilitzar aquests productes, cal tenir en compte un factor important: aquest és un alt nivell de competència, experiència i professionalitat amb un gran èmfasi en Linux, ja que és molt important desplegar, configurar i mantenir-ho tot correctament, que imposa encara més responsabilitat i càrrega a l'administrador.
Vemmagatzematge
L'arquitectura sembla encara més interessant , que es pot utilitzar juntament amb un hipervisor als mateixos nodes, al mateix , però és molt important configurar-ho tot correctament per aconseguir un bon rendiment. És a dir, desplegar aquest producte des de la caixa en qualsevol configuració sense tenir en compte les recomanacions d'acord amb l'arquitectura serà molt fàcil, però poc productiu.
Què pot coexistir per a l'emmagatzematge al costat dels serveis de l'hipervisor kvm-qemu, i aquests són només uns quants serveis on s'ha trobat una jerarquia òptima de components compacta: servei de client muntat mitjançant FUSE (modificat, no de codi obert), servei de metadades MDS (Servei de metadades), blocs de dades del servei Chunk, que a nivell físic és igual a un disc i això és tot. En termes de velocitat, per descomptat, és òptim utilitzar un esquema tolerant a errors amb dues rèpliques, però si utilitzeu la memòria cau i registres a les unitats SSD, la codificació tolerant a errors (esborrar la codificació o raid6) es pot overclockejar decentment en un esquema híbrid o encara millor en tots els flash. Hi ha algun inconvenient amb EC (esborrar codificació): quan es canvia un bloc de dades, cal tornar a calcular les quantitats de paritat. Per evitar les pèrdues associades a aquesta operació, Ceph escriu a EC amb retard i es poden produir problemes de rendiment durant una determinada sol·licitud, quan, per exemple, cal llegir tots els blocs i, en el cas de Virtuozzo Storage, es duu a terme l'escriptura de blocs modificats. utilitzant l'enfocament del "sistema de fitxers estructurat en registre", que minimitza els costos de càlcul de paritat. Per estimar aproximadament les opcions amb acceleració de treball amb i sense EC, hi ha – les xifres poden ser aproximades en funció del coeficient de precisió del fabricant de l'equip, però el resultat dels càlculs és una bona ajuda per planificar la configuració.
Un diagrama simple dels components d'emmagatzematge no vol dir que aquests components no absorbeixin però si calculeu tots els costos per avançat, podeu comptar amb la col·laboració al costat de l'hipervisor.
Hi ha un esquema per comparar el consum de recursos de maquinari dels serveis d'emmagatzematge Ceph i Virtuozzo.
Si abans era possible comparar Gluster i Ceph utilitzant articles antics, utilitzant les línies més importants d'ells, llavors amb Virtuozzo és més difícil. No hi ha molts articles sobre aquest producte i la informació només es pot obtenir de la documentació o en rus si considerem Vstorage com a emmagatzematge utilitzat en algunes solucions hiperconvergents en empreses com ara i Acronis.
Intentaré ajudar amb una descripció d'aquesta arquitectura, de manera que hi haurà una mica més de text, però es necessita molt de temps per entendre la documentació vostè mateix, i la documentació existent només es pot utilitzar com a referència revisant la taula. de continguts o cerca per paraula clau.
Considerem el procés d'enregistrament en una configuració de maquinari híbrida amb els components descrits anteriorment: l'enregistrament comença a dirigir-se al node des del qual el client l'ha iniciat (el servei de punt de muntatge FUSE), però el component principal del servei de metadades (MDS), per descomptat, ho farà. dirigir el client directament al servei de bloc desitjat (blocs CS del servei d'emmagatzematge), és a dir, MDS no participa en el procés d'enregistrament, sinó que simplement dirigeix el servei al bloc requerit. En general, podem donar una analogia a l'enregistrament amb l'abocament d'aigua en bótes. Cada barril és un bloc de dades de 256 MB.
És a dir, un disc és un nombre determinat d'aquests barrils, és a dir, el volum del disc dividit per 256 MB. Cada còpia es distribueix a un node, la segona gairebé en paral·lel a un altre node, etc... Si tenim tres rèpliques i hi ha discs SSD per a la memòria cau (per llegir i escriure registres), aleshores la confirmació de l'escriptura es produirà després d'escriure. el registre a l'SSD i el restabliment paral·lel de l'SSD continuarà a l'HDD, com si estigués en segon pla. En el cas de tres rèpliques, el registre es confirmarà després de la confirmació del SSD del tercer node. Pot semblar que la suma de la velocitat d'escriptura de tres SSD es pot dividir per tres i obtindrem la velocitat d'escriptura d'una rèplica, però les còpies s'escriuen en paral·lel i la velocitat de latència de la xarxa sol ser superior a la de l'SSD, i de fet el rendiment d'escriptura dependrà de la xarxa. En aquest sentit, per veure IOPS reals, heu de carregar correctament tot el Vstorage per , és a dir, provant la càrrega real, i no la memòria i la memòria cau, on cal tenir en compte la mida correcta del bloc de dades, el nombre de fils, etc.
El registre d'enregistrament esmentat anteriorment a l'SSD funciona de manera que tan aviat com hi entren dades, el servei les llegeix immediatament i escriu a l'HDD. Hi ha diversos serveis de metadades (MDS) per clúster i el seu nombre està determinat per un quòrum, que funciona segons l'algorisme de Paxos. Des del punt de vista del client, el punt de muntatge FUSE és una carpeta d'emmagatzematge del clúster que és simultàniament visible per a tots els nodes del clúster, cada node té un client muntat segons aquest principi, de manera que aquest emmagatzematge està disponible per a cada node.
Per a la realització de qualsevol dels enfocaments descrits anteriorment, és molt important, en l'etapa de planificació i desplegament, configurar correctament la xarxa, on hi haurà un equilibri a causa de l'agregació i l'ample de banda del canal de xarxa correctament seleccionat. En l'agregació, és important triar el mode hashing i les mides de fotograma adequats. També hi ha una diferència molt forta amb l'SDS descrit anteriorment, es tracta d'un fusible amb la tecnologia de camí ràpid a Virtuozzo Storage. El que, a més del fusible modernitzat, a diferència d'altres solucions de codi obert, augmenta significativament les IOPS i permet no estar limitat per l'escala horitzontal o vertical. En general, en comparació amb les arquitectures descrites anteriorment, aquesta sembla més potent, però per tal plaer, és clar, cal comprar llicències, a diferència de Ceph i Gluster.
En resum, podem destacar el primer dels tres: Virtuozzo Storage ocupa el primer lloc pel que fa a rendiment i fiabilitat de l'arquitectura, Ceph ocupa el segon lloc i Gluster ocupa el tercer lloc.
Els criteris pels quals es va seleccionar Virtuozzo Storage: és un conjunt òptim de components arquitectònics, modernitzat per a aquest enfocament de Fuse amb un camí ràpid, un conjunt flexible de configuracions de maquinari, menys consum de recursos i la capacitat de compartir amb la informàtica (informàtica/virtualització), és a dir, és completament adequat per a una solució hiperconvergent, de la qual forma part. En segon lloc ocupa Ceph perquè és una arquitectura més productiva en comparació amb Gluster, pel seu funcionament en blocs, així com escenaris més flexibles i la capacitat de treballar en clústers més grans.
Hi ha plans per escriure una comparació entre vSAN, Space Direct Storage, Vstorage i Nutanix Storage, provant Vstorage en equips HPE i Huawei, així com escenaris per integrar Vstorage amb sistemes d'emmagatzematge de maquinari externs, així que si us ha agradat l'article, seria Encantat de rebre comentaris de la teva part, la qual cosa podria augmentar la motivació per als nous articles, tenint en compte els teus comentaris i desitjos.
Font: www.habr.com