Cisco ACE ilə işləyən administratorun qarşısında qəribə vəziyyət dayanır: cihaz zəngin funksiyalara malikdir, trafik yolunun tam ortasındadır, amma özü artıq keçmiş nəsil platformadır. Buna görə konfiqurasiyaya yalnız “request hansı serverə getsin?” sualı ilə baxmaq kifayət etmir. Tətbiqin sağlamlığı, session davranışı, SSL sərhədi və cihaz sıradan çıxanda baş verəcək hadisələr eyni xəritədə görünməlidir.
Problem də budur.
ACE 4710 ayrıca appliance kimi, ACE modulları isə şəbəkə avadanlığının daxilində application delivery funksiyası verirdi. Cisco bu iki məhsulu data center üçün load balancing və application delivery həlli kimi təsvir edir. Bu sinif cihaz client ilə backend arasında reverse proxy və ya Layer 4 load balancer rolunda dayanır; client virtual IP-yə qoşulur, ACE uyğun server farm-ı tapır, işlək real server seçir və bağlantını ora ötürür. Kağız üzərində sadədir. Production-da isə hər oxun öz state-i və nasazlıq ssenarisi var.
Trafik ACE-dən necə keçir?
Konfiqurasiyanı oxumağın rahat yolu ayrı-ayrı komandaları əzbərləmək deyil, obyektlər arasındakı yolu izləməkdir. Virtual IP xidmətin xarici ünvanıdır. Class map trafiki tanıyır, policy map həmin trafikə load balancing davranışı bağlayır, server farm backend hovuzunu saxlayır, real server isə konkret tətbiq instansiyasıdır. Health probe real serverin rotasiyada qalıb-qalmayacağına qərar verir.
Diaqram — orijinal məqalədə
Bu axında class map və policy map giriş trafikinin hansı xidmətə aid olduğunu müəyyən edir. Server farm seçildikdən sonra predictor işlək real serverlər arasından birini seçir. Cavab client-ə ACE üzərindən qayıdırsa, cihaz connection state-i saxlayır; asimmetrik routing yaranarsa paketlərin bir hissəsi bu state-dən yan keçə və bağlantı qırıla bilər. Deməli, routing dizaynı load balancer konfiqurasiyasından ayrı məsələ deyil.
Predictor serverin həqiqi yükünü həmişə bilmir
ACE-də round-robin və least connections davranışları fərqli məqsədlərə xidmət edir. Weighted round-robin standart predictor-dur. Weight böyükdürsə, server daha çox yeni bağlantı alır; eyni gücdə və oxşar workload daşıyan backend-lər üçün bu, proqnozlaşdırılması asan seçimdir.
Least connections açıq bağlantısı daha az olan serverə üstünlük verir. Uzunömürlü bağlantılar və qeyri-bərabər request müddətləri olan sistemdə bu, faydalı görünür, amma connection sayı CPU, yaddaş və ya queue dərinliyi deyil. On min yüngül keep-alive bağlantısı bəzən yüz ağır hesablama request-indən ucuz başa gəlir. Siqnal natamamdır.
Yeni serveri bir anda tam trafikə salmaq da yaxşı fikir deyil. ACE-nin least-connections predictor-u üçün slow start mexanizmi yeni real serverə əvvəlcə az bağlantı göndərir, sonra yükü tədricən artırır. Bu, cache-i soyuq olan və ya connection pool-u yenicə qurulan instansiyanın ilk saniyələrdə boğulmasının qarşısını ala bilər.
Hash əsaslı seçim başqa ehtiyacı həll edir. ACE ünvan, cookie, HTTP header və URL əsasında server seçə bilir. Müəyyən açar eyni backend-ə düşür. Açarlar bərabər paylanmırsa isə serverlərdən biri həddindən artıq yüklənə bilər, buna görə qərarı alqoritmin adı yox, tətbiqin real trafik forması müəyyən edir.
Health probe port yoxlamasından artıq olmalıdır
Probe-un işi backend-in trafik qəbul edib-etmədiyini müəyyənləşdirməkdir. ACE ICMP, TCP, HTTP, HTTPS, DNS və başqa yoxlama növləri ilə konfiqurasiya oluna bilir. TCP probe portun bağlantı qəbul etdiyini göstərir, daha artığını yox. Tətbiq database-ə çata bilmirsə və bütün request-lərə xəta qaytarırsa, açıq portun çox təsəllisi yoxdur.
HTTP probe üçün ayrıca, ucuz health endpoint seçmək daha düzgün siqnal verir. Endpoint tətbiqin trafik qəbul edə bildiyini yoxlamalıdır, amma hər probe-da bütün asılılıqlara ağır sorğu göndərməməlidir. Interval həddən artıq qısa, uğursuzluq həddi isə çox sərt seçiləndə qısa şəbəkə titrəyişi serverləri növbə ilə rotasiyadan çıxara bilər. Bu dəfə load balancer problemi azaltmır, özü trafik dalğası yaradır.
Server probe-dan keçməyəndə mövcud bağlantıların taleyi əvvəlcədən məlum olmalıdır. Yeni bağlantıları dayandırmaqla aktiv connection-ları dərhal sıfırlamaq eyni davranış deyil. Fərq böyükdür. Uzun download, WebSocket və ya stateful transaction daşıyan sistemdə istifadəçi bunu dərhal görür; nasazlıq testi buna görə backend-i söndürüb bir yeni request yoxlamaqla bitməməli, aktiv bağlantını, bərpanı və serverin yenidən rotasiyaya qoşulmasını da əhatə etməlidir.
Stickiness rahatlıq verir, sonra hesabını istəyir
ACE eyni client-in sonrakı bağlantılarını eyni real serverə bağlamaq üçün source IP, cookie, HTTP header və SSL session ID kimi stickiness üsullarını dəstəkləyir. Lokal yaddaşda session saxlayan köhnə tətbiq üçün bu, zəruri ola bilər; backend dəyişəndə istifadəçi login vəziyyətini itirmir.
Amma source IP stickiness NAT arxasındakı minlərlə istifadəçini bir serverə yığa bilər. Cookie əsaslı üsul daha dəqiqdir, bunun müqabilində cookie-nin müddəti, adı və təhlükəsizlik atributları idarə olunmalıdır. Server rotasiyadan çıxanda sticky qeydin hara yönələcəyi də ayrıca failover qərarıdır. Stateless tətbiq və ortaq session store mümkündürsə, load balancer-də yığılan bu gizli state-dən qurtulmaq sistemi xeyli sadələşdirir.
SSL termination tətbiq serverlərindən kriptoqrafik işi götürür və HTTP səviyyəli routing imkanı açır. RFC 7098 SSL reverse proxy-nin session boyu SSL, TCP və bəzən HTTP state-i saxladığını qeyd edir. State artır. Bunun əvəzində sertifikatın yenilənməsi, private key-in qorunması, cipher siyasəti və ACE-dən backend-ə gedən trafikin şifrələnib-şifrələnməməsi cihazın məsuliyyətinə çevrilir; load balancer trafik paylayan qutu olmaqdan çıxıb təhlükəsizlik sərhədinə çevrilir.
Əsas risk artıq cihazın yaşıdır
Cisco ACE üçün köhnəlmə nəzəri risk deyil. ACE ailəsi artıq retired və dəstəksiz platformadır. Üstəlik, CVE-2016-6399 qeydində ACE30 və ACE 4700 cihazlarında xüsusi SSL və ya TLS paketləri ilə uzaqdan denial-of-service yaradıb cihazı reload etməyin mümkün olduğu göstərilir. Bu ciddi fərqdir. İşlək cihaz dəstəklənən cihaz demək deyil.
Legacy ACE saxlanılırsa, inventarda yalnız model və IP ünvanı olmamalıdır. Software versiyası, konfiqurasiya backup-ı, lisenziyalar, sertifikatlar, ehtiyat cihaz, failover nəticəsi və cihazı əvəz edə biləcək platformaya keçid planı birlikdə sənədləşdirilməlidir. Xüsusilə SSL termination aktivdirsə, dəstəklənməyən proqram təminatını internet trafikinin qarşısında saxlamaq təhlükəsizlik riskini böyüdür.
Miqrasiyada ən asan hissə virtual IP yaratmaqdır. Çətin hissə illər ərzində yığılmış sticky qaydalarını, probe davranışını, timeout-ları, NAT siyasətini, SSL sertifikatlarını və qeyri-adi routing asılılıqlarını tapmaqdır. Mövcud konfiqurasiya obyekt-obyekt deyil, xidmət-xidmət xəritələnəndə boşluqlar daha tez görünür: hansı client gəlir, hansı qayda işə düşür, hansı backend seçilir, cavab hansı yolla qayıdır və nasazlıq zamanı aktiv bağlantı necə bağlanır.
Cisco ACE-ni idarə etmək bu gün daha çox legacy sistem mühəndisliyidir. Cihazın predictor və probe imkanları hələ də load balancing məntiqini öyrətmək üçün yaxşı modeldir, amma production qərarında əsas ölçü funksiyaların sayı yox, təhlükəsiz yenilənmə və bərpa imkanının qalıb-qalmamasıdır.
Tez-tez verilən suallar
Cisco ACE hələ production mühitində istifadə oluna bilərmi?
Texniki olaraq işlək cihaz mövcud trafiki daşıya bilər, lakin platforma rəsmi dəstəkdən çıxıb. Təhlükəsizlik yeniləmələri, ehtiyat hissə, vendor dəstəyi və bərpa müddəti nəzərə alınmadan onu production-da saxlamaq ciddi əməliyyat riskidir.
Round-robin ilə least connections arasında fərq nədir?
Round-robin yeni bağlantıları serverlər arasında növbə ilə paylayır. Least connections isə mövcud açıq bağlantı sayını nəzərə alaraq daha az bağlantısı olan serverə üstünlük verir.
Stickiness nə vaxt lazımdır?
Tətbiq session vəziyyətini yalnız lokal yaddaşda saxlayırsa, eyni istifadəçinin ardıcıl bağlantılarını eyni backend-ə yönəltmək lazım gələ bilər. Stateless tətbiqdə isə stickiness çox vaxt yükün qeyri-bərabər paylanmasına səbəb olur.
Mənbələr
This article was originally published by DEV Community and written by Jamal Ali.
Read original article on DEV Community