Salam, Habr!
Sizə xatırladırıq ki, yeni, son dərəcə maraqlı və faydalı Kubernetes naxışları haqqında. Hər şey "" Brendan Burns-dan başlayıb, və əslində, bu sahədki işimiz . Bu gün sizlərə MinIO bloqundakı bir məqaləni təqdim edirik ki, bu, Kubernetes-də məlumat saxlama naxışlarının tendensiyalarını və spesifikalarını qısa şəkildə izah edir.
Kubernetes, tətbiqlərin inkişafı və yerləşdirilməsi üçün ənənəvi naxışları fundamental şəkildə dəyişib. İndi bir komandanın müəyyən bir tətbiqi müxtəlif mühitlərdə inkişaf etdirmək, sınaqdan keçirmək və yerləşdirmək üçün yalnız bir neçə gün sərf etməsi mümkündür - bütün bunlar Kubernetes klasterləri çərçivəsində. Əvvəlki nəsil texnologiyalarla belə işlər adətən tam həftələr, bəlkə də aylar çəkirdi.
Bu sürətlənmə, Kubernetes-in aşağı səviyyəli fiziki və ya virtual maşınlarla qarşılıqlı əlaqəni öz üzərinə götürməsi sayəsində mümkün olub — yəni istifadəçilərin istədikləri prosessoru, lazım olan yaddaş həcmini və konteyner nümunələrinin sayını elan etmələrinə imkan tanıyır. Kubernetes-in dəstəklədiyi geniş bir icma var və Kubernetes-in tətbiq sahəsi davamlı olaraq genişlənir, buna görə də, o, konteyner orkestrasiyası platformaları arasında liderliyini böyük fərqlərlə qoruyur.
Kubernetes-in istifadəsi genişləndikcə, məlumat saxlama naxışları ilə bağlı qarışıqlıq da artır.
Kubernetes (yəni, məlumat saxlama) uğrunda bütün rəqabət zamanı, məlumat saxlama söhbəti getdikdə, burada siqnal güclü səs-küyün içində itir.
Kubernetes, tətbiqlərin müasir inkişaf və yerləşdirmə modelini həyata keçirir. Bu müasir model, məlumat saxlama ilə hesablama proseslərini ayırır. Kubernetes kontekstində bu ayrılmanı tam başa düşmək üçün, həm də vəziyyəti saxlayan və saxlamayan tətbiqlərin nə olduğunu və bunun məlumat saxlama ilə necə uyğunlaşdığını anlamaq lazımdır. H именно burada S3 tərəfindən tətbiq olunan REST API yanaşmasının, digər həllər üçün xarakterik olan POSIX/CSI yanaşması ilə müqayisədə açıq üstünlükləri var.
Bu məqalədə biz Kubernetes-də məlumat saxlama naxışları haqqında danışacağıq və ayrıca vəziyyəti saxlayan və saxlamayan tətbiqlər arasındakı mübahisəyə toxunacağıq ki, bunların arasındakı fərqin nə olduğunu və niyə vacib olduğunu yaxşı başa düşək. Sonrakı mətndə, konteynerlər və Kubernetes ilə işin ən yaxşı praktikaları işığında tətbiqlər və onlarda istifadə olunan məlumat saxlama naxışları nəzərdən keçiriləcək.
Vəziyyəti saxlamayan konteynerlər
Konteynerlər doğası etibarilə yüngüldür və efemerikdir. Onları asanlıqla dayandırmaq, silmək və ya başqa bir node-də genişləndirmək mümkündür – bütün bunlar bir neçə dəqiqə içində baş verir. Böyük konteyner orkestrasiyası sistemində, bu əməliyyatlar daim baş verir və istifadəçilər bu dəyişiklikləri belə hiss etmir. Lakin, hərəkət etmələr mümkün deyil, əgər konteynerin yerləşdiyi node-də heç bir asılılıq yoxdursa. Bu cür konteynerlər haqqında deyilir ki, onlar hala vəziyyəti qoruyur.
Vəziyyət qoruyan konteynerlər
Əgər konteyner lokal olaraq bağlı cihazlarda (ya da blok cihazında) məlumat saxlayırsa, o zaman məlumat üçün istifadə olunan anbar yeni node-ə konteynerlə birlikdə köçürülməlidir – sistemin iflası halında. Bu vacibdir, çünki əks halda, konteynerdə çalışan tətbiq düzgün fəaliyyət göstərə bilməz, çünki ona lokal saxlama vasitələrində saxlanılan məlumatlara müraciət etmək lazımdır. Bu cür konteynerlər haqqında deyilir ki, onlar vəziyyət qoruyur.
Tam texniki baxımdan, vəziyyət qoruyan konteynerləri də digər node-lərə köçürmək mümkündür. Bu, adətən, konteynerlərin işlədiyi bütün node-lara birləşdirilmiş paylanmış fayl sistemləri və ya blok şəbəkə məlumat anbarları vasitəsilə təmin edilir. Beləliklə, konteynerlər məlumatların mühafizəsi üçün həcmlərə çıxış əldə edir və məlumatlar şəbəkə boyunca olan disklərdə saxlanılır. Bu metodu «vəzifə qoruyan konteyner yanaşmasıdeyə adlandıracağam və məqalənin qalan hissəsində onu bu cür adlandıracağam, vahidlik naminə.
Tipik vəziyyət qoruyan konteyner yanaşmasında bütün tətbiq podları bir paylanmış fayl sisteminə qoşulur - bu, bir növ paylaşılmış saxlama yaradır, burada bütün tətbiq məlumatları toplanır. Bəzi dəyişikliklər mümkün olsa da, bu, yüksək səviyyəli bir yanaşmadır.
İndi isə gəlin başa düşək ki, nəyə görə vəziyyət qoruyan konteyner yanaşması bulud yönümlü dünyada antipattern hesab olunur.
Bulud yönlü tətbiq inkişafı
Ənənəvi olaraq tətbiqlər, strukturlu məlumatları saxlamaq üçün məlumat bazalarından və lokala bağlı disklərdən və ya bütün şəbəkədə yayılan qeyri-strukturlu və ya yarı-strukturlu məlumatların yerlərini saxlamaq üçün paylanmış fayl sistemlərindən istifadə edirdi. Qeyri-strukturlu məlumatların həcmi artdıqca, inkişaf etdiricilər başa düşdülər ki, POSIX fazlaca "sosialdır", əhəmiyyətli xərcə yol açır və nəticədə, tətbiqin əsl böyük ölçülərə keçidində mane olur.
Bu, əsasən, REST API əsasında işləyən bulud əsaslı saxlama standartının yaranmasına səbəb oldu və proqramları yerli verilənlər bazasının ağır idarəsindən azad etdi. Beləliklə, proqram faktiki olaraq vəziyyət saxlanılmayan bir iş rejiminə keçir (çünki vəziyyət uzaq saxlama sistemindədir). Müasir proqramlar bu faktoru nəzərə alaraq sıfırdan yaradılır. Adətən, müasir verilənləri (jurnal, metadata, blob və s.) işləyən hər bir proqram bulud əsaslı paradigma əsasında qurulur, burada vəziyyət onun saxlanması üçün xüsusi ayrılmış proqram sistemi ilə daşınır.
Dövrü mühafizə edən konteyner yanaşması, bu paradigmanı tam olaraq başladığı yerə geri qaytarır!
POSIX interfeyslərindən istifadə edərək verilənlərin saxlanmasında, proqramların vəziyyət saxlayırmış kimi eyni ruhda işlədiyi üçün, bulud əsaslı dizaynın ən vacib prinsiplərindən, yəni proqram iş proseslərinin ölçülərini gələn yükə görə dəyişdirmək, aktual nod uğursuz olduqda yeni bir nodun üzərinə keçmək və s. prinsiplərindən kənara çıxırlar.
Bu vəziyyətə daha yaxından baxanda, bulud tərəfindən yaradılmış verilənlər bazalarını seçərkən, yenidən dəfələrlə "POSIX x REST API" dilemması ilə qarşılaşdığımızı, AMMA POSIX-in problemlərinin sıralı xarakteri ilə daha da pisləşdiyini görürük. Xüsusilə,
- POSIX danışıqlıdır: POSIX-in semantikası, hər bir əməliyyatla əlaqəli metadata və fayl descriptorlarını birləşdirməyi tələb edir, bu da əməliyyatın vəziyyətini qorumağa kömək edir. Bu, heç bir real dəyəri olmayan əhəmiyyətli xərclərə gətirib çıxarır. Obekt saxlama API-ləri, xüsusən S3 API, bu tələblərdən azad olduqda, proqramın işə düşməsini və sonra çağırışı "unutmasını" təmin edir. Saxlama sisteminin cavabı, hər hansı bir əməliyyatın uğurla icra edilib-edilmədiyini göstərir. Uğursuzluq halında, proqram təkrarlama edə bilər.
- Şəbəkə məhdudiyyətləri: Dağıtılmış sistemdə bir çox tətbiqin eyni birləşmiş saxlama cihazına məlumat yazmağa çalışa biləcəyi nəzərdə tutulur. Buna görə də, tətbiqlər yalnız məlumat ötürmə genişliyi üçün bir-biri ilə rəqabət aparmayacaq, eyni zamanda məlumat saxlama sistemi də məlumatları fiziki disklərə yayaraq bu genişlik üçün mübarizə aparacaq. POSIX-in nitq xeyli olduğundan, şəbəkə çağırışlarının sayı bir neçə dəfə artır. Digər tərəfdən, S3 API müştəridən serverə gələn şəbəkə çağırışları ilə server daxilində baş verənlər arasında aydın ayırma təmin edir.
- Təhlükəsizlik: POSIX təhlükəsizlik modeli insanın aktiv iştirakını nəzərdə tutur: administratorlar hər bir istifadəçi və ya qrup üçün xüsusi giriş səviyyələrini konfiqurasiya edirlər. Belə bir paradigma bulud mərkəzli dünyaya uyğunlaşdırmaq çətindir. Müasir tətbiqlər API ilə bağlı təhlükəsizlik modellərinə arxalanır, burada giriş hüquqları siyasətlərin dəstinə əsasən müəyyən edilir, xidmət hesabları ayrılır, müvəqqəti kimliklər və s.
- İdarəolunaqlıq: Davamlı konteynerlərin idarə olunması müəyyən xərcləri gətirir. Bunlara, məlumatlara paralel girişin senkronizasiyası, məlumatların tutarlılığının təmin edilməsi, bütün bunlar məlumatlara müraciət etmək üçün hansı naxışların istifadə ediləcəyini diqqətlə düşünməyi tələb edir. Əlavə proqramların qurulması, idarə olunması və konfiqurasiya edilməsi lazımdır, əlavə inkişaf üçün sərf olunan əlavə səy barədə danışmıram.
Konteyner məlumat saxlama interfeysi
Konteyner məlumat saxlama interfeysinin (CSI) Kubernetes həcm səviyyəsinin yayılmasında mükəmməl köməyi oldu, bunu üçüncü tərəf məlumat saxlama satıcılarına qismən ötürdü, lakin eyni zamanda konteyner yanaşmasının davamlı olması, Kubernetes-də məlumatların saxlanılması üçün tövsiyə olunan üsul olduğu inancını təsadüfən artırdı.
CSI, Kubernetes ilə işləyən irs tətbiqetmələrinə təsadüfi blok və fayl saxlama sistemlərinin təqdim edilməsi üçün standart kimi hazırlanmışdır. Bu məqalədə göstərildiyi kimi, konteyner yanaşmasının davamlı olması (və CSI-nin indiki formasında) yalnız irs sisteminin özünün olduğu, informasiya saxlanmasını dəstəkləmək üçün API-nin əlavə edilməsinin mümkün olmadığı bir vəziyyətdir.
Başqa bir şey anlayışında olmaq vacibdir ki, CSI-nin indiki formasında olan zaman, müasir tətbiqlərlə işləyərkən həcm montajı zamanı, POSIX stilində təşkil olunmuş sistemlərdəki eynilə belə problemlərlə qarşılaşacağıq.
Daha keyfiyyətli yanaşma
Bu vəziyyətdə başa düşmək vacibdir ki, əksər tətbiqlər öz mahiyyətinə görə vəziyyəti saxlamağa yönəlməyib və ya bunun əksinədir. Bu cür davranış sistemin ümumi arxitekturasından və layihələndirmədə seçilmiş konkret variantlardan asılıdır. Gəlin vəziyyəti saxlayan tətbiqlər haqqında bir az danışaq.
Əslində, tətbiq məlumatlarını bir neçə geniş növə bölmək mümkündür:
- Log məlumatları
- Zaman möhürü məlumatları
- Ödəniş məlumatları
- Meta məlumatlar
- Konteyner görüntüləri
- Blob məlumatları (böyük ikili obyektlər)
Bütün bu məlumat növləri müasir məlumat saxlama platformalarında çox yaxşı dəstəklənir və hər bir bu konkret formatda məlumat təqdim etməyə uyğunlaşmış bir neçə bulud-əsaslı platforma mövcuddur. Məsələn, ödəniş məlumatları və meta məlumatlar müasir bulud-əsaslı verilənlər bazasında, məsələn, CockroachDB, YugaByte və s. yerləşə bilər. Konteyner görüntüləri və ya blob məlumatları MinIO-ya əsaslanan docker registrində saxlanıla bilər. Zaman möhürü məlumatları isə, məsələn, InfluxDB kimi zaman seriyaları verilənlər bazasında saxlanıla bilər. Burada hər bir məlumat növü və müvafiq tətbiqlər haqqında detallara girməyək, amma əsas fikir lokalde disk montajı əsaslana bilən davamlı məlumat saxlamağa qaçınmaqdır.
Bundan əlavə, tez-tez tətbiqlərə müvəqqəti faylların saxlanması üçün bir növ müvəqqəti önbellek təklif etmək effektiv olur, lakin tətbiqlər bu səviyyədən həqiqət mənbəyi kimi asılı olmamalıdır.
Vəziyyəti saxlayan tətbiqlər üçün saxlama
Əksər hallarda vəziyyəti saxlamayan tətbiqlərin üstünlük təşkil etməsi faydalıdır, lakin məlumat saxlamağı nəzərdə tutan tətbiqlər - məsələn, verilənlər bazaları, obyekt saxlama sistemləri, açar-dəyər saxlama sistemləri - vəziyyəti saxlamalıdır. Gəlin bu tətbiqlərin Kubernetes-də necə yayılmasına baxaq. Misal olaraq MinIO-nu götürək, lakin oxşar prinsiplər digər böyuk bulud-əsaslı məlumat saxlama sistemlərinə də şamil edilir.
Bulud-əsaslı tətbiqlər konteynerlərin təklif etdiyi elastikliyindən maksimum dərəcədə faydalanmaq məqsədilə layihələndirilmişdir. Bu, onların yayılacağı mühit haqqında heç bir fərziyyə edilmir deməkdir. Məsələn, MinIO, sistemə yarısının disk uğursuzluğu halında belə işlək qalmaq üçün kifayət qədər davamlılıq təmin edən daxili artıqlıq kodlaşdırma mexanizmini istifadə edir. Eyni zamanda, MinIO öz server tərəfində şifrələmə və hash etmə üsulları ilə məlumatların bütövlüyü və təhlükəsizliyini təmin edir.
Belə bulud-əsaslı tətbiqlər üçün arxiv saxlama kimi lokal davamlı həcmlər (PV) ən rahat seçimdir. Lokal PV, xammal məlumatların saxlanmasına imkan tanıyır, eyni zamanda bu PV-lər üzərində işləyən tətbiqlər, məlumatların miqyasını artırmaq və artan məlumat tələblərini idarə etmək üçün lazım olan məlumatları toplayır.
Bu yanaşma, sistemdə öz məlumat idarəetmə və redundantlıq səviyyələrini gətirən CSI-ə əsaslanan PV-lərlə müqayisədə çox daha sadədir və əhəmiyyətli dərəcədə daha yaxşı miqyaslanır; çünki bu səviyyələr, adətən durumu qoruyan prinsiplərlə layihələşdirilmiş tətbiqlərlə ziddiyyət təşkil edir.
Məlumatların hesablama prosesindən ayrılması istiqamətində inamla irəliləmə
Bu məqalədə tətbiqlərin vəziyyəti qorumaqdan imtina edərək işləməyə necə yönəldiyini müzakirə etdik, yani, məlumatların saxlanması onlarla aparılan hesablama prosesindən ayrılır. Nəticə olaraq, bu trendin bir neçə real nümunəsini nəzərdən keçirək.
, tanınmış məlumat analizi platforması, ənənəvi olaraq vəziyyəti qorumaqla və HDFS fayl sistemində yayılma ilə istifadə olunmuşdur. Lakin, Spark bulud-əsaslı dünyaya keçdikcə, bu platforma vəziyyəti qorumaqdan imtina edərək daha aktiv şəkildə `s3a` istifadə edilir. Spark, vəziyyəti digər sistemlərə ötürmək üçün s3a-dan istifadə edir, eyni zamanda Spark konteynerləri tamamilə vəziyyəti qorumaqdan imtina edərək işləyir. Böyük verilənlər analitikası sahəsində digər iri müəssisə iştirakçıları, xüsusən də , , həmçinin məlumatların saxlanması ilə hesablama prosesinin ayrılması istiqamətinə keçirlər.
Belə naxışlar, Presto, Tensorflow to R, Jupyter kimi digər iri analitik platformalarda da görünür. Vəziyyəti uzaq bulud saxlama sistemlərinə yüklədikdə, tətbiqinizi idarə etmək və onun miqyasını artırmaq daha asan olur. Həmçinin, bu, tətbiqin müxtəlif mühitlərdə portativliyini artırır.
Mənbə: habr.com
