Hey Habr! Mən Artem Karamışev, sistem administrasiyası qrupunun rəhbəriyəm . Keçən il ərzində biz bir çox yeni məhsul təqdim etmişik. API xidmətlərinin asanlıqla miqyaslana bilən, nasazlığa dözümlü olmasını və istifadəçi yükündə sürətli artıma hazır olmasını təmin etmək istəyirdik. Platformamız OpenStack-də həyata keçirilir və mən xətaya dözümlü sistem əldə etmək üçün hansı komponentin nasazlığa dözümlülük problemlərini bağlamalı olduğumuzdan danışmaq istəyirəm. Məncə, OpenStack-də məhsullar hazırlayanlar üçün də maraqlı olacaq.
Platformanın ümumi nasazlıqlara qarşı dözümlülüyü onun komponentlərinin sabitliyindən ibarətdir. Beləliklə, biz riskləri tapdığımız və onları bağladığımız bütün səviyyələri tədricən keçəcəyik.
Əsas mənbəyi tərəfindən təşkil edilən Uptime day 4 konfransındakı hesabat olan bu hekayənin video versiyası , Sən görə bilərsən .
Fiziki Memarlıq Qüsurlarına Dözümlülük
MCS buludunun ictimai hissəsi indi iki Tier III səviyyəli məlumat mərkəzinə əsaslanır, onların arasında 200 Gb/s ötürmə qabiliyyəti ilə müxtəlif marşrutlarla fiziki səviyyədə qorunan öz qaranlıq lifi var. III səviyyə fiziki infrastruktur üçün tələb olunan davamlılıq səviyyəsini təmin edir.
Qaranlıq lif həm fiziki, həm də məntiqi səviyyədə qorunur. Kanalın rezervasiyası prosesi iterativ idi, problemlər yarandı və biz data mərkəzləri arasında əlaqəni daim təkmilləşdiririk.
Məsələn, bir müddət əvvəl məlumat mərkəzlərindən birinin yaxınlığındakı quyuda işləyərkən bir boru ekskavator tərəfindən deşildi, həm əsas, həm də ehtiyat optik kabel bu borunun içərisində idi. Məlumat mərkəzi ilə xətaya dözümlü rabitə kanalımız bir nöqtədə, quyuda həssas oldu. Müvafiq olaraq, biz infrastrukturun bir hissəsini itirmişik. Biz nəticə çıxardıq, bir sıra tədbirlər gördük, o cümlədən qonşu quyu boyunca əlavə optika çəkdik.
Məlumat mərkəzlərində BGP vasitəsilə prefikslərimizi yayımladığımız rabitə provayderlərinin mövcudluq nöqtələri var. Hər bir şəbəkə istiqaməti üçün müxtəlif müştərilərə ən yaxşı əlaqə keyfiyyətini təmin etməyə imkan verən ən yaxşı metrik seçilir. Bir provayder vasitəsilə əlaqə kəsilərsə, biz marşrutumuzu mövcud provayderlər vasitəsilə yenidən qururuq.
Provayder nasazlığı halında avtomatik olaraq növbəti birinə keçirik. Məlumat mərkəzlərindən birinin nasazlığı halında, bütün yükü öz üzərinə götürən ikinci məlumat mərkəzində xidmətlərimizin güzgü nüsxəsi var.
Fiziki İnfrastruktur Dayanıqlığı
Tətbiq səviyyəsində nasazlığa dözümlülük üçün nədən istifadə edirik
Xidmətimiz bir sıra açıq mənbə komponentləri üzərində qurulub.
ExaBGP - BGP əsasında dinamik marşrutlaşdırma protokolundan istifadə edərək bir sıra funksiyaları həyata keçirən xidmət. İstifadəçilərin API-yə daxil olduğu ağ siyahıya alınmış IP ünvanlarımızı elan etmək üçün ondan geniş şəkildə istifadə edirik.
HAProxy - OSI modelinin müxtəlif səviyyələrində çox çevik trafik balanslaşdırma qaydalarını konfiqurasiya etməyə imkan verən yüksək yüklənmiş yük balanslayıcısı. Biz ondan bütün xidmətlərdən əvvəl balanslaşdırmaq üçün istifadə edirik: verilənlər bazası, mesaj brokerləri, API xidmətləri, veb xidmətləri, daxili layihələrimiz - hər şey HAProxy-nin arxasındadır.
API tətbiqi - python dilində yazılmış veb proqram, onun köməyi ilə istifadəçi öz infrastrukturunu, xidmətini idarə edir.
İşçi tətbiqi (bundan sonra sadəcə işçi) - OpenStack xidmətlərində bu, API əmrlərini infrastruktura yayımlamağa imkan verən infrastruktur demonudur. Məsələn, diskin yaradılması işçidə, yaratma sorğusu isə API proqramında baş verir.
Standart OpenStack Tətbiq Memarlığı
OpenStack üçün hazırlanmış xidmətlərin əksəriyyəti tək bir paradiqmaya əməl etməyə çalışır. Xidmət adətən 2 hissədən ibarətdir: API və işçilər (backend icraçılar). Bir qayda olaraq, API ya müstəqil proses (daemon) kimi, ya da hazır Nginx, Apache veb serverindən istifadə edən WSGI python proqramıdır. API istifadəçinin sorğusunu emal edir və əlavə təlimatları icra üçün işçi tətbiqinə ötürür. Köçürmə mesaj brokerindən istifadə etməklə baş verir, adətən RabbitMQ, qalanları zəif dəstəklənir. Mesajlar brokerə çatdıqda işçilər tərəfindən işlənir və lazım gələrsə, cavab qaytarılır.
Bu paradiqma təcrid olunmuş ümumi uğursuzluq nöqtələrini nəzərdə tutur: RabbitMQ və verilənlər bazası. Lakin RabbitMQ tək bir xidmət daxilində təcrid olunub və nəzəri olaraq hər bir xidmət üçün fərdi ola bilər. Beləliklə, MCS-də biz bu xidmətləri mümkün qədər ayırırıq, hər bir fərdi layihə üçün ayrıca verilənlər bazası, ayrıca RabbitMQ yaradırıq. Bu yanaşma yaxşıdır, çünki bəzi həssas nöqtələrdə qəza baş verdikdə, bütün xidmət deyil, yalnız bir hissəsi pozulur.
İşçi tətbiqlərinin sayına heç bir məhdudiyyət yoxdur, buna görə də performans və nasazlığa dözümlülüyünü artırmaq üçün API asanlıqla balanslaşdırıcıların arxasında üfüqi şəkildə miqyaslana bilər.
Bəzi xidmətlərdə xidmət daxilində koordinasiya zəruridir - API və işçilər arasında mürəkkəb ardıcıl əməliyyatlar baş verdikdə. Bu halda, vahid koordinasiya mərkəzindən, Redis, Memcache və s. kimi klaster sistemindən istifadə olunur ki, bu da bir işçinin digərinə bu tapşırığın ona tapşırıldığını söyləməsinə imkan verir ("zəhmət olmasa, onu götürməyin"). və s. istifadə edirik. Bir qayda olaraq, işçilər məlumat bazası ilə aktiv şəkildə əlaqə saxlayır, oradan məlumat yazır və oxuyurlar. Verilənlər bazası olaraq biz multimaster klasterdə olan mariadb-dən istifadə edirik.
Belə bir klassik vahid xidmət OpenStack üçün ümumi qəbul edilən tərzdə təşkil edilmişdir. O, qapalı sistem hesab oluna bilər ki, bunun üçün miqyaslaşdırma yolları və nasazlıqlara dözümlülük olduqca açıqdır. Məsələn, API xətalarına dözümlülük üçün onların qarşısına balanslaşdırıcı qoymaq kifayətdir. İşçi miqyası onların sayını artırmaqla əldə edilir.
Bütün sxemdəki zəif nöqtə RabbitMQ və MariaDB-dir. Onların arxitekturası ayrıca məqaləyə layiqdir.Bu məqalədə mən API-nin nasazlıqlara dözümlülüyünə diqqət yetirmək istəyirəm.
Openstack Tətbiq Memarlığı. Bulud platformasının balanslaşdırılması və nasazlığa dözümlülüyü
ExaBGP ilə HAProxy Balancer Failover edilməsi
API-lərimizi miqyaslana bilən, sürətli və xətaya dözümlü etmək üçün onların qarşısına balanslaşdırıcı qoyuruq. Biz HAProxy-ni seçdik. Fikrimcə, o, bizim vəzifəmiz üçün bütün lazımi xüsusiyyətlərə malikdir: bir neçə OSI səviyyələrində balanslaşdırma, idarəetmə interfeysi, çeviklik və miqyaslılıq, çoxlu sayda balanslaşdırma metodları, sessiya masalarına dəstək.
Həll edilməli olan ilk problem balanslaşdırıcının özünün nasazlıqlara qarşı dözümlülüyü idi. Sadəcə balanslaşdırıcı quraşdırmaq həm də uğursuzluq nöqtəsi yaradır: balanslaşdırıcı pozulur - xidmət çökür. Bunun baş verməməsi üçün biz ExaBGP ilə birlikdə HAProxy-dən istifadə etdik.
ExaBGP sizə xidmətin vəziyyətini yoxlamaq mexanizmini həyata keçirməyə imkan verir. Biz bu mexanizmdən HAProxy-nin sağlamlığını yoxlamaq üçün istifadə etdik və problem olarsa, BGP-dən HAProxy xidmətini söndürdük.
ExaBGP+HAProxy Sxemi
- Lazımi proqram təminatını üç serverdə, ExaBGP və HAProxy-də quraşdırırıq.
- Serverlərin hər birində biz geri dönmə interfeysi yaradırıq.
- Hər üç serverdə biz bu interfeysə eyni ağ IP ünvanını təyin edirik.
- Ağ IP ünvanı ExaBGP vasitəsilə İnternetə elan edilir.
Səhvlərə dözümlülük hər üç serverdən eyni IP ünvanını reklam etməklə əldə edilir. Şəbəkə nöqteyi-nəzərindən eyni ünvan üç müxtəlif növbəti hop-dan mövcuddur. Router üç eyni marşrut görür, öz metrikasına uyğun olaraq onlardan ən prioritetini seçir (bu adətən eyni seçimdir) və trafik yalnız serverlərdən birinə gedir.
HAProxy ilə bağlı problemlər və ya server nasazlığı halında ExaBGP marşrutu elan etməyi dayandırır və trafik problemsiz şəkildə başqa serverə keçir.
Beləliklə, balanslaşdırıcının nasazlığa dözümlülüyünə nail olduq.
HAProxy balanslaşdırıcılarının nasazlıqlara qarşı dözümlülüyü
Sxem qeyri-kamil oldu: biz HAProxy-ni necə rezerv etməyi öyrəndik, lakin xidmətlər daxilində yükü necə bölüşdürməyi öyrənmədik. Buna görə də, biz bu sxemi bir qədər genişləndirdik: bir neçə ağ IP ünvanı arasında balanslaşdırmaya keçdik.
DNS plus BGP əsasında balanslaşdırma
HAProxy-miz qarşısında yük balansı məsələsi həll olunmamış qalır. Buna baxmayaraq, bizim vəziyyətimizdə etdiyimiz kimi, olduqca sadə şəkildə həll edilə bilər.
Üç serveri balanslaşdırmaq üçün sizə 3 ağ IP ünvanı və yaxşı köhnə DNS lazımdır. Bu ünvanların hər biri hər bir HAProxy-nin geri dönmə interfeysində müəyyən edilir və İnternetdə reklam olunur.
OpenStack-də, müəyyən bir xidmətin API-nin son nöqtəsinin göstərildiyi resursları idarə etmək üçün bir xidmət kataloqu istifadə olunur. Bu kataloqda biz üç müxtəlif IP ünvanı ilə DNS vasitəsilə həll olunan public.infra.mail.ru domen adını qeydiyyatdan keçiririk. Nəticədə DNS vasitəsilə üç ünvan arasında yük balansını əldə edirik.
Ancaq ağ IP ünvanlarını elan edərkən, balanslaşdırılana qədər server seçim prioritetlərinə nəzarət etmirik. Tipik olaraq, yalnız bir server IP ünvanı üstünlüyü ilə seçiləcək, digər ikisi isə BGP-də heç bir ölçü göstərilmədiyi üçün boş olacaq.
ExaBGP vasitəsilə müxtəlif ölçülərlə marşrutlar verməyə başladıq. Hər bir balanslaşdırıcı hər üç ağ IP ünvanını reklam edir, lakin onlardan biri, bu balanslaşdırıcı üçün əsas olan, minimum metrik ilə reklam olunur. Beləliklə, hər üç balanslaşdırıcı işləyərkən birinci İP ünvana edilən zənglər birinci balanslaşdırıcıya, ikinciyə edilən zənglər ikinciyə, üçüncüsünə edilən zənglər üçüncüyə gedir.
Balanslaşdırıcılardan biri qəzaya uğradıqda nə baş verir? Hər hansı balanslaşdırıcı uğursuz olarsa, onun əsas ünvanı hələ də digər ikisindən elan edilir, trafik onlar arasında yenidən bölüşdürülür. Beləliklə, istifadəçiyə DNS vasitəsilə eyni anda bir neçə IP ünvanı veririk. DNS və müxtəlif ölçüləri balanslaşdırmaqla biz hər üç balanslaşdırıcıda yükün bərabər paylanmasını əldə edirik. Və eyni zamanda, biz səhvlərə dözümlülüyü itirmirik.
DNS + BGP əsasında HAProxy-nin balanslaşdırılması
ExaBGP və HAProxy arasında qarşılıqlı əlaqə
Beləliklə, marşrutların elanının dayandırılmasına əsaslanaraq, serverin ayrılması halında uğursuzluğu həyata keçirdik. Lakin HAProxy server nasazlığından başqa digər səbəblərə görə də kəsilə bilər: idarəetmə xətaları, xidmət daxilindəki uğursuzluqlar. Bu hallarda da pozulmuş balanslaşdırıcını yükdən çıxarmaq istəyirik və fərqli mexanizmə ehtiyacımız var.
Buna görə də, əvvəlki sxemi genişləndirərək, ExaBGP və HAProxy arasında ürək döyüntüsünü həyata keçirdik. Bu, ExaBGP proqramların statusunu yoxlamaq üçün xüsusi skriptlərdən istifadə etdiyi zaman ExaBGP və HAProxy arasında qarşılıqlı əlaqənin yumşaq həyata keçirilməsidir.
Bunu etmək üçün ExaBGP konfiqurasiyasında siz HAProxy statusunu yoxlaya bilən sağlamlıq yoxlayıcısını konfiqurasiya etməlisiniz. Bizim vəziyyətimizdə HAProxy-də sağlamlıq backendini konfiqurasiya etdik və ExaBGP tərəfdən sadə GET sorğusu ilə yoxlayırıq. Elan baş verməyi dayandırarsa, o zaman HAProxy çox güman ki, işləmir və bunu elan etməyə ehtiyac yoxdur.
HAProxy Sağlamlıq Yoxlanışı
HAProxy Peers: sessiya sinxronizasiyası
Növbəti iş seansları sinxronlaşdırmaq idi. Paylanmış balanslaşdırıcılar vasitəsilə işləyərkən müştəri seansları haqqında məlumatın saxlanmasını təşkil etmək çətindir. Lakin HAProxy Peers funksionallığı sayəsində bunu edə bilən bir neçə balanslaşdırıcılardan biridir - müxtəlif HAProxy prosesləri arasında sessiya cədvəllərini ötürmək imkanı.
Müxtəlif balanslaşdırma üsulları var: kimi sadə üsullar , və uzadılır, müştərinin sessiyası yadda qalanda və hər dəfə əvvəlki kimi eyni serverə daxil olduqda. Biz ikinci variantı həyata keçirmək istəyirdik.
HAProxy bu mexanizmin müştəri seanslarını davam etdirmək üçün stick masalardan istifadə edir. Onlar müştərinin orijinal IP ünvanını, seçilmiş hədəf ünvanını (backend) və bəzi xidmət məlumatlarını saxlayırlar. Tipik olaraq, çubuq cədvəlləri mənbə-IP + təyinat-IP cütünü saxlamaq üçün istifadə olunur ki, bu da digər balanslaşdırıcıya keçərkən, məsələn, RoundRobin balanslaşdırma rejimində istifadəçinin sessiya kontekstini keçə bilməyən proqramlar üçün xüsusilə faydalıdır.
Əgər çubuq masasına müxtəlif HAProxy prosesləri arasında hərəkət etmək öyrədilirsə (bu aralar balanslaşdırılır), balanslaşdırıcılarımız bir çubuq masası hovuzu ilə işləyə biləcəklər. Bu, balanslaşdırıcılardan biri uğursuz olduqda müştəri şəbəkəsini problemsiz şəkildə dəyişməyə imkan verəcək və müştəri seansları ilə işləmək əvvəllər seçilmiş arxa tərəflərdə davam edəcək.
Düzgün işləmək üçün sessiyanın qurulduğu balanslaşdırıcının mənbə IP ünvanı problemi həll edilməlidir. Bizim vəziyyətimizdə bu, geri dönmə interfeysində dinamik bir ünvandır.
Həmyaşıdların düzgün işləməsi yalnız müəyyən şərtlərdə əldə edilir. Yəni, TCP fasilələri kifayət qədər böyük olmalıdır və ya keçid kifayət qədər sürətli olmalıdır ki, TCP sessiyasının bitməsinə vaxt olmasın. Bununla belə, problemsiz keçid etməyə imkan verir.
Eyni texnologiyadan istifadə edərək qurulmuş IaaS xidmətimiz var. Bu Octavia adlanır. O, iki HAProxy prosesinə əsaslanır və yerli olaraq həmyaşıdları dəstəkləyir. Onlar bu xidmətdə üstündürlər.
Şəkil sxematik olaraq üç HAProxy nümunəsi arasında həmyaşıd cədvəllərinin hərəkətini göstərir, bunun necə konfiqurasiya oluna biləcəyi bir konfiqurasiya təklif olunur:
HAProxy Peers (sessiya sinxronizasiyası)
Eyni sxemi həyata keçirsəniz, onun işləməsi diqqətlə sınaqdan keçirilməlidir. 100% hallarda eyni formada işləyəcəyi faktı deyil. Ancaq ən azı müştərinin mənbə IP-sini xatırlamaq lazım olduqda stick cədvəllərini itirməyəcəksiniz.
Eyni müştəridən eyni vaxtda sorğuların sayının məhdudlaşdırılması
API-lərimiz də daxil olmaqla, ictimaiyyətə açıq olan istənilən xidmətlər sorğuların uçqununa məruz qala bilər. Onların səbəbləri istifadəçi səhvlərindən tutmuş məqsədyönlü hücumlara qədər tamamilə fərqli ola bilər. Biz vaxtaşırı IP ünvanları ilə DDoSed olunuruq. Müştərilər tez-tez skriptlərində səhv edirlər, bizi mini-DDoS-lər edirlər.
Bu və ya digər şəkildə əlavə qorunma təmin etmək lazımdır. Aşkar həll yolu API-yə sorğuların sayını məhdudlaşdırmaq və zərərli sorğuların işlənməsi üçün CPU vaxtını sərf etməməkdir.
Bu cür məhdudiyyətləri həyata keçirmək üçün biz eyni çubuq cədvəllərindən istifadə edərək HAProxy əsasında təşkil edilmiş tarif limitlərindən istifadə edirik. Limitlər olduqca sadədir və istifadəçini API-yə sorğuların sayı ilə məhdudlaşdırmağa imkan verir. Alqoritm sorğuların edildiyi mənbə IP-ni xatırlayır və bir istifadəçidən eyni vaxtda sorğuların sayını məhdudlaşdırır. Əlbəttə ki, biz hər bir xidmət üçün orta API yükləmə profilini hesabladıq və limiti bu dəyərin ≈ 10 qatına təyin etdik. Biz hələ də vəziyyəti diqqətlə izləyirik, barmağımızı nəbzdə saxlayırıq.
Praktikada nə kimi görünür? Avtomatik ölçmə API-lərimizdən daim istifadə edən müştərilərimiz var. Səhər gec iki yüz və ya üç yüzə yaxın virtual maşın yaradırlar və günortadan sonra onları silirlər. OpenStack üçün virtual maşın yaratmaq üçün, həmçinin PaaS xidmətləri ilə, ən azı 1000 API sorğusu lazımdır, çünki xidmətlər arasında qarşılıqlı əlaqə API vasitəsilə də baş verir.
Tapşırıqların bu cür ötürülməsi kifayət qədər böyük bir yükə səbəb olur. Biz bu yükü qiymətləndirdik, gündəlik pikləri topladıq, on dəfə artırdıq və bu, bizim tarif limitimiz oldu. Biz barmağımızı nəbzdə saxlayırıq. Biz tez-tez işlədilə bilən CGA skriptlərimizin olub-olmadığını görməyə çalışan botları, skanerləri görürük, biz onları aktiv şəkildə kəsdik.
Kod bazasını istifadəçilərə səssizcə necə yeniləmək olar
Biz səhvlərə dözümlülüyünü kodun yerləşdirilməsi prosesləri səviyyəsində də həyata keçiririk. Təqdimat zamanı uğursuzluqlar olur, lakin onların xidmətlərin mövcudluğuna təsiri minimuma endirilə bilər.
Biz xidmətlərimizi daim yeniləyirik və kod bazasının yenilənməsi prosesinin istifadəçilərə heç bir təsiri olmamasını təmin etməliyik. Biz HAProxy idarəetmə imkanlarından və xidmətlərimizdə Graceful Shutdown tətbiqindən istifadə edərək bu problemi həll edə bildik.
Bu problemi həll etmək üçün balanslaşdırıcıya nəzarəti və xidmətlərin "düzgün" bağlanmasını təmin etmək lazım idi:
- HAProxy vəziyyətində idarəetmə mahiyyətcə bir yuva olan və HAProxy konfiqurasiyasında müəyyən edilmiş stats faylı vasitəsilə həyata keçirilir. Siz stdio vasitəsilə ona əmrlər göndərə bilərsiniz. Lakin bizim əsas konfiqurasiyaya nəzarət alətimiz uyğundur, ona görə də HAProxy-ni idarə etmək üçün daxili modula malikdir. fəal şəkildə istifadə edirik.
- API və Mühərrik xidmətlərimizin əksəriyyəti zərif söndürmə texnologiyalarını dəstəkləyir: onlar söndürüldükdə, http sorğusu və ya bir növ xidmət tapşırığı olsun, cari tapşırığın tamamlanmasını gözləyirlər. Eyni şey işçi ilə də olur. Gördüyü bütün işləri bilir və hər şey uğurla başa çatdıqdan sonra bitir.
Bu iki nöqtə sayəsində yerləşdirməmizin təhlükəsiz alqoritmi aşağıdakı kimidir.
- Tərtibatçı yeni kod paketi qurur (bizdə RPM var), onu inkişaf mühitində sınaqdan keçirir, mərhələdə sınaqdan keçirir və mərhələ deposunda buraxır.
- Tərtibatçı “artefaktların” ən ətraflı təsviri ilə yerləşdirmə tapşırığını təyin edir: yeni paketin versiyası, yeni funksionallığın təsviri və lazım olduqda yerləşdirmə ilə bağlı digər təfərrüatlar.
- Sistem administratoru təkmilləşdirməyə başlayır. Ansible oyun kitabını işlədir, o da öz növbəsində aşağıdakıları edir:
- Səhnə deposundan paket götürür, ondan istifadə edərək məhsul anbarında paketin versiyasını yeniləyir.
- Yenilənən xidmətin arxa tərəflərini sadalayır.
- HAProxy-də ilk yenilənmiş xidməti söndürür və proseslərin bitməsini gözləyir. Zərif bağlanma sayəsində biz əminik ki, bütün cari müştəri sorğuları uğur qazanacaq.
- API tam dayandırıldıqdan sonra işçilər HAProxy-ni söndürərək kod yenilənir.
- Ansible xidmətlərə başlayır.
- Hər bir xidmət üçün o, bir sıra əvvəlcədən təyin edilmiş əsas testlərdə vahid testini həyata keçirən müəyyən “tutacaqları” çəkir. Yeni kodun əsas yoxlanışı var.
- Əvvəlki addımda heç bir səhv tapılmadısa, arxa uç aktivləşdirilir.
- Gəlin növbəti backend-ə keçək.
- Bütün backendləri yenilədikdən sonra funksional testlər işə salınır. Əgər onlar kifayət deyilsə, onda tərtibatçı etdiyi hər hansı yeni funksiyaya baxır.
Bu, yerləşdirməni tamamlayır.
Xidmət yeniləmə dövrü
Bir qaydamız olmasaydı, bu sxem işləməzdi. Biz eyni zamanda köhnə və yeni versiyaları dəstəkləyirik. Əvvəlcədən, proqram təminatının hazırlanması mərhələsində, xidmət bazasında dəyişikliklər olsa belə, əvvəlki kodu pozmayacaqları qoyulur. Nəticə kod bazasının tədricən yenilənməsidir.
Nəticə
Qüsurlara dözümlü WEB-arxitektura haqqında öz fikirlərimi bölüşərək, onun əsas məqamlarını bir daha qeyd etmək istəyirəm:
- fiziki qüsurlara dözümlülük;
- şəbəkə xətasına dözümlülük (balanslaşdırıcılar, BGP);
- istifadə olunan və hazırlanmış proqram təminatının nasazlıqlara qarşı dözümlülüyü.
Bütün sabit iş vaxtı!
Mənbə: www.habr.com
