Cum oglinda noastră - blog-ul companiei Selektel

Aceasta se numește o copie în oglindă a datelor dintr-o resursă de informații pe o alta. Oglinzile sunt folosite pentru a asigura accesul la copiile de informații prin mai multe surse. Prin utilizarea oglinzi, de exemplu, se realizează distribuțiile răspândire * nix-sisteme: copia stocată a depozitului de la mai multe oglinzi situate în diferite părți ale lumii. Utilizarea oglinzi permite distribuirea rațional și sarcina de a oferi de mare viteza de download de pachete.

Pachetul oglindă, care stochează copii ale registrelor centrale de populare sisteme Linux, există în compania noastră. În acest articol, ne-ar dori să dea detalii cu privire la structura sa.

Oglinda principală am ales mirror.yandex.ru, deoarece este situat îndeaproape și conține toți clienții noștri au nevoie de depozit. La început a fost bine cu noi. Dar apoi sa întâmplat ceva neașteptat. Numărul de plante a crescut, inginerii se sprijini pe testarea modelelor; în cele din urmă, Yandex, a stârnit o mare cantitate de interogări identice, doar accesul închis la oglinda lui pentru subrețele noastre.

Am început să caute o soluție cu care ar putea oferi stabilitate și pentru a reduce riscul de situații anormale la un nivel minim. Am avut următoarea idee: ridica Nginx ca server proxy pentru mai multe oglinzi. Această decizie părea să ne rezonabil și de încredere: chiar dacă una dintre Uplink toamna, vom putea descărca fișiere de pe celălalt, fără nici o problemă. Cu toate acestea, suntem imediat confruntă cu problema de oglinzi eterogene structura: de exemplu, CentOS depozit pe unul ar putea fi în legătura ascendentă / CentOS, pe de altă parte - în / CentOS, iar al treilea - toate în / www / oglinda / SRV / pub / CentOS.

Deoarece magazia în oglindă universală care conține toate distribuțiile relevante noi (CentOS, Debian, Ubuntu, openSUSE) pot fi numărate pe, pentru fiecare dintre distribuții a trebuit să fie o listă separată de oglinzi.

Punerea descris ideea de a vieții, ne confruntăm cu probleme mult mai grave:

• Viteza de uplink este volatilitatea diferită: foarte adesea cazul în care una și aceeași gazdă trimite o 5-10 Mb / s, iar alternanța deja câteva ore - nu mai mult de 5-20 kb / s. Deoarece programul de instalare se va descărca unul pachete de unul, din cauza diferențelor în stabilirea vitezei poate fi amânată pe termen nelimitat;
• unele uplink poate fi configurat incorect: sa întâmplat că, ca răspuns la o solicitare în loc de RPM-pachet pe care o primesc HTML pagina «Funcționează!»;
• unele uplink pot fi absente în aceste pachete director. Sau pachete au fost prezente, dar au fost checksum incorecte. Acest lucru ar putea avea loc, de exemplu, ca urmare a încălcării ordinului din sinhronizaztsii amonte: în primul rând, fișiere index, și apoi pachete, nu invers. Erorile pot apărea, de asemenea, din cauza rsync de configurare incorecte, care a înregistrat fișiere în loc, și nu salvează conținutul într-un fișier temporar, urmată de înlocuirea atomică.

Creați propria oglindă, am rezolvat toate problemele menționate mai sus. Printre avantajele obținute prin propria oglindă, trebuie să includă, de asemenea, următoarele:

• sincronizarea cu uplink fără a întrerupe serviciul pentru clienți și nu afectează copia de lucru dat lor;
• copie sincronizate înlocuiește curent numai dacă toate noile pachetele converg checksum;
• în cazul în care legătura în sus pentru un motiv oarecare nu este disponibil, sau returnează date incorecte, date în oglindă continuă să dea vechi, dar copia de lucru;
• sincronizare de uplink împărțit de distribuție: pentru unele distribuții se poate face mai puțin frecvent decât altele. Există, de asemenea, posibilitatea de a clona parțială unor arhive.

Cu această oglindă fiind sisteme de operare instalate pe servere dedicate.

Cum sunt arhive

De regulă, magazia este alcătuit din două părți principale: catalogul (Index) si piscina (magazin pachet).

Catalogul conține informații despre toate pachetele disponibile în depozit numele, descrierea, arhitectura, versiunea, suma de control, iar în unele cazuri, informații cu privire la dependențe, și conținutul pachetului. Catalogul indică de asemenea în cazul în care în piscină este un fișier de o versiune specială a fiecărui pachet.

Piscina în sine este stocat fișierele pachet. Acestea pot fi extinse, în conformitate cu o ierarhie sau pur și simplu stivuite într-un singur director.

RPM-depozit

La rădăcina fiecărui depozit este RPM-director pentru fișierele director - repodata. O descriere a tuturor secțiunilor din catalog sunt stocate într-un fișier repomd.xml. Fiecare secțiune este reprezentată printr-un fișier separat în directorul director. În descrierea calea către fișierul care conține secțiunea, și suma de verificare.

fișier repomd.xml de conținut ar putea arăta astfel:

RPM-catalog cuprinde următoarele secțiuni:

• primar - conține o descriere a tuturor pachetelor stocate în magazia, căile de fișier ale pachetelor și checksum lor;
• filelists - conțin liste de fișiere incluse în fiecare pachet;
• grupă - conține o descriere a grupurilor de pachete care sunt instalate folosind yum groupinstall;
• altele - furnizează informații suplimentare (de exemplu, jurnalele de schimbare -) de schimbări.

Structurarea și gruparea de pachete pentru diferite sisteme de operare sunt organizate în mod diferit. De exemplu, CentOS stochează toate fișierele din directorul Pachete situat în rădăcina magaziei. În plus, pentru fiecare dintre arhitectura existentă a creat un depozit separat.

OpenSUSE păstrează pachete pentru toate arhitecturile într-un singur depozit, cu bazine separate, în i686 / x86_64 / etc directoare.

DEB-depozit

DEB-magaziile, toate pachetele sunt stocate în piscină comună. Astfel se evită dublarea pachetelor aparținând diferitelor versiuni. Pentru fiecare lansare în repertoriul instituit un director separat.

Parsarea director începe cu fișierul / dists / [distribuție] / Release (distribuție aici înseamnă numele de cod de eliberare - stoarce / wheezing / jessie). Acesta conține o listă a componentelor de eliberare, precum și informații cu privire la dimensiunea și control a tuturor fișierelor index. Arhiva podpicyvaetsya meyntenerami lansare-fișier; semnătură Release.gpg este stocată în fișierul (uneori Release conținut împreună cu semnătura poate fi stocată în fișierul InRelease).

Descrierea conținutului piscinei se află în indexul fișierelor de două tipuri: Pachete (acestea sunt pachetele binare) și surse (surse enumerate în respectiva anexă).

Calea către fișierul de pachete - / dists / [distribuție] / [component] / binary- [arhitectura] / pachete și surse de fișiere - / dists / [distribuție] / [componente] / sursă / surse.

Notă: uneori fișierele indexului sunt comprimate cu gzip sau bzip2 - în acest caz, numele fișierului sau .GZ extensia .bz2 adăugat respectiv. Unii clienti sprijini LZMA (.lzma), XZ (.xz) și LZIP (.lz).

Aici este o intrare de probă din dosar Pachete:

Cum oglinda noastră

Repository fiecare distributie pe oglinda este stocată în două exemplare: umbra (fundal) și de lucru (prim-plan). Ambele părți se află pe un singur LVM-volum, permițându-le să meargă pentru a adăuga spațiu pe disc. În partea stocată copie testată oglinda de lucru, l distribui prin intermediul Nginx. Porțiunea umbra este sincronizat cu amonte-oglindă, și apoi este bine verificată valabilitatea.

Procedura de validare constă în verificarea catalogului, semnătura sa digitală (dacă este cazul), și checksum tuturor fișierelor index. Verificați checksum toate pachetele destul de dificil: în unele bazine arhive pot fi stocate pachete pentru zeci, sau chiar sute de gigabytes. Prin urmare, checksum sunt verificate doar la noile pachete, la care „a atins» rsync. După verificarea umbra și funcționarea schimbul. Această operație se realizează cu ajutorul unui simplu mv. Astfel, este posibil să se asigure de substituție Atomicitate practic (doar trei mv apel rapid, pentru a schimba directorul) și pentru a minimiza potențialul de nefuncționare. Fișierele Giving deschise în timpul înlocuirii nu se oprește.

După cele două părți sunt inversate, partea umbra la nivel local pentru a „prinde“ la starea actuală a copiei de lucru.

Oglinda-sincronizare

În multe dintre serviciile noastre avem nevoie în mod regulat pentru a oferi clienților cu diverse informatsiyu.Klientam statistice închirierea unor servere dedicate nevoie de informații cu privire la consumul de trafic. Utilizatorii de servere cloud nevoie de statistici cu privire la utilizarea resurselor hardware și de rețea și utilizatorii de stocare cloud - Statistici descărca fișiere.

creșterea continuă a datelor și de a crește rata de creștere de prelucrare și de generare a problemelor de stocare. Nu este surprinzător faptul că tema „mari de date» (Big Data) este una dintre cele mai vorbit despre în comunitatea IT de astăzi. Materialele pe teoria „mari de date“, în reviste de specialitate și site-uri de astăzi a publicat destul de mult. Dar publicațiile teoretice nu sunt întotdeauna clar cum să-l folosească.