CDN-nin qurulması və konfiqurasiyası

Məzmun Çatdırılma Şəbəkələri (CDN) vebsaytlarda və tətbiqlərdə ilk növbədə statik elementlərin yüklənməsini sürətləndirmək üçün istifadə olunur. Bu, müxtəlif coğrafi bölgələrdə yerləşən CDN serverlərində faylların keşləşdirilməsi səbəbindən baş verir. CDN vasitəsilə məlumat tələb etməklə istifadəçi onu ən yaxın serverdən alır.

Bütün məzmun çatdırılması şəbəkələrinin işləmə prinsipi və funksionallığı təxminən eynidir. Faylı yükləmək üçün sorğu aldıqdan sonra CDN server onu birdəfəlik orijinal serverdən götürür və istifadəçiyə verir, eyni zamanda müəyyən müddət ərzində onu keşləyir. Bütün sonrakı sorğular keşdən cavablandırılır. Bütün CDN-lərdə faylları əvvəlcədən yükləmək, keşi təmizləmək, son istifadə tarixini təyin etmək və s. seçimləri var.

Belə olur ki, bu və ya digər səbəbdən öz məzmun çatdırma şəbəkənizi təşkil etməlisiniz və sonra - növbəti velosipedi yığmaq üçün təlimatlar bizə kömək etsin.

CDN-nin qurulması və konfiqurasiyası
Mənbə: Pikisuperstar tərəfindən yaradılmış infoqrafik vektor - www.freepik.com

Öz CDN-nə ehtiyacınız olduqda

Öz CDN-ni işə salmağın mənalı olduğu halları nəzərdən keçirin:

  • kimi ucuz CDN-lərdən istifadə edərkən pula qənaət etmək istəyi və cari xərclər olduqda BunnyCDN ayda bir neçə yüz dollar təşkil edir
  • server və kanal qonşuları olmadan daimi bir önbellek və ya bir önbellek əldə etmək istəyiriksə
  • CDN xidmətlərinin sizə lazım olan bölgədə mövcudluq nöqtələri yoxdur
  • tələb olunan hər hansı xüsusi məzmun çatdırılması parametrləri
  • istehsal serverini istifadəçilərə yaxın yerləşdirməklə dinamik məzmunun çatdırılmasını sürətləndirmək istəyirik
  • üçüncü tərəfin CDN xidmətinin istifadəçi davranışı (salam, GDPR-a uyğun olmayan xidmətlər) haqqında məlumatı qanunsuz olaraq toplaya və ya istifadə edə və ya digər qeyri-qanuni fəaliyyətlərlə məşğul ola biləcəyi ilə bağlı narahatlıq var

Əksər digər hallarda, mövcud hazır həllərdən istifadə etmək daha məqsədəuyğundur.

Başlamaq üçün nə lazımdır

Öz Avtonom Sisteminiz (AS) varsa, çox gözəldir. Bununla eyni IP-ni bir neçə serverə təyin edə bilərsiniz və bu təlimata uyğun olaraq şəbəkə səviyyəsində istifadəçiləri ən yaxın birinə yönləndirin. Qeyd etmək lazımdır ki, hətta /24 ünvan bloku ilə məzmun çatdırılması şəbəkəsi qurmaq mümkündür. Bəzi server provayderləri onlara mövcud olan bütün bölgələrdə istifadə üçün elan verməyə imkan verir.

Əgər siz IP ünvanları blokunun xoşbəxt sahibi deyilsinizsə, sadə CDN-ni işə salmaq üçün sizə lazım olacaq:

  • domen adı və ya alt domen
  • müxtəlif bölgələrdə ən azı iki server. Server xüsusi və ya virtual ola bilər
  • geoDNS aləti. Bununla istifadəçi domenə müraciət edərək ən yaxın serverə yönləndiriləcək

Domeni qeydiyyatdan keçirin və serverləri sifariş edin

Domen qeydiyyatı ilə hər şey sadədir - biz istənilən zonada istənilən qeydiyyatçı ilə qeydiyyatdan keçirik. Siz həmçinin CDN üçün subdomendən istifadə edə bilərsiniz, məsələn, kimi bir şey cdn.domainname.com. Əslində, nümunəmizdə biz bunu edəcəyik.

Serverlərin sifarişinə gəlincə, onlar istifadəçi auditoriyanızın yerləşdiyi regionlarda və ölkələrdə icarəyə götürülməlidir. Layihə qitələrarasıdırsa, o zaman bütün dünyada serverlər təklif edən hostinq provayderlərini bir anda seçmək rahatdır. Nümunələr: OVH, İcarəyə verilən veb и 100 TB - xüsusi serverlər üçün, Vultr и DigitalOcean — virtual bulud üçün*.

Şəxsi CDN-miz üçün müxtəlif qitələrdə 3 virtual server sifariş edəcəyik. At Vultr üçün serverdə $5/ay alacağıq 25GB SSD yerlər və 1TB trafik. Quraşdırarkən ən son Debian seçin. Serverlərimiz:

CDN-nin qurulması və konfiqurasiyası Frankfurt, ip: 199.247.18.199

CDN-nin qurulması və konfiqurasiyası Chicago, ip: 149.28.121.123

CDN-nin qurulması və konfiqurasiyası Sinqapur, ip: 157.230.240.216

*Vultr və DigitalOcean, ödəniş üsulu əlavə etdikdən dərhal sonra məqalədəki keçidlər vasitəsilə qeydiyyatdan keçən istifadəçilərə 100 dollar kredit vəd edir. Müəllif bundan kiçik bir kompliment də alır ki, bu da onun üçün indi çox əlamətdardır. Xahiş edirəm anlayışlı olun.

GeoDNS qurulması

Domenə və ya CDN alt domeninə daxil olarkən istifadəçinin istədiyi (ən yaxın) serverə yönləndirilməsi üçün bizə geoDNS funksiyası olan DNS server lazımdır.

GeoDNS-in prinsipi və işləməsi aşağıdakı kimidir:

  1. DNS sorğusunu göndərən müştərinin İP-sini və ya müştəri sorğusunu emal edərkən istifadə olunan rekursiv DNS serverinin IP-ni müəyyən edir. Belə rekursiv serverlər adətən provayderlərin DNS-ləridir.
  2. Müştərinin IP-si onun ölkəsini və ya bölgəsini tanıyır. Bunun üçün bu gün çox sayda olan GeoIP verilənlər bazası istifadə olunur. Yaxşılar var pulsuz seçimlər.
  3. Müştərinin yerindən asılı olaraq ona ən yaxın CDN serverinin IP ünvanını verir.

geoDNS funksiyası ilə DNS server ola bilər özünüz toplayın, lakin bütün dünyada DNS server şəbəkəsi ilə hazır həllərdən istifadə etmək daha yaxşıdır və Hər hansı bir qutudan:

  • SlouDNS etibarən $9.95/ay, GeoDNS tarifi, standart olaraq bir DNS Failover var
  • Zilore etibarən $25/ay, DNS Failover aktivləşdirildi
  • Amazon marşrutu 53 etibarən $35/ay xalis 50M geo-tələblər üçün. DNS Failover ayrıca hesablanır
  • DNS asanlaşdırdı etibarən $125/ay, 10 DNS Failover var
  • Cloudflare, "Geo Sükan" funksiyası Müəssisə planlarında mövcuddur

GeoDNS sifarişi verərkən, tarifə daxil olan sorğuların sayına diqqət yetirməli və nəzərə alın ki, domenə edilən sorğuların faktiki sayı gözləntiləri bir neçə dəfə üstələyə bilər. Milyonlarla hörümçəklər, skanerlər, spamerlər və digər pis ruhlar yorulmadan işləyirlər.

Demək olar ki, bütün DNS xidmətlərinə CDN - DNS Failover qurmaq üçün əvəzsiz xidmət daxildir. Onun köməyi ilə siz serverlərinizin işinə nəzarəti qura və həyat əlamətləri olmadıqda avtomatik olaraq işləməyən serverin ünvanını DNS cavablarında ehtiyat nüsxə ilə əvəz edə bilərsiniz.

CDN-mizi qurmaq üçün istifadə edəcəyik CloudDNS, GeoDNS tarifi.

Domeninizi göstərərək şəxsi hesabınıza yeni DNS zonası əlavə edək. Əgər alt domendə CDN qururuqsa və əsas domen artıq istifadədədirsə, zonanı əlavə etdikdən dərhal sonra mövcud işləyən DNS qeydlərini əlavə etməyi unutmayın. Növbəti addım CDN domeni / alt domeni üçün bir neçə A-qeydləri yaratmaqdır, onların hər biri qeyd etdiyimiz bölgəyə tətbiq olunacaq. Siz qitələri və ya ölkələri regionlar kimi göstərə bilərsiniz, sub-regionlar ABŞ və Kanada üçün mövcuddur.

Bizim vəziyyətimizdə CDN bir alt domendə qaldırılacaq cdn.sayt.in. Zona əlavə etməklə sayt.in, subdomen üçün ilk A-rekordunu yaradın və bütün Şimali Amerikanı Çikaqodakı serverə yönəldin:

CDN-nin qurulması və konfiqurasiyası
Defolt bölgələr üçün bir giriş yaratmağı xatırlayaraq, digər bölgələr üçün hərəkəti təkrarlayaq. Sonda nə baş verir:

CDN-nin qurulması və konfiqurasiyası

Ekran görüntüsündəki sonuncu standart giriş o deməkdir ki, bütün təyin olunmamış bölgələr (və bunlar Avropa, Afrika, peyk İnternet istifadəçiləri və s.) Frankfurtdakı serverə göndəriləcək.

Bu, əsas DNS quraşdırmasını tamamlayır. Domen qeydiyyatçısının veb saytına daxil olmaq və mövcud domen NS-lərini ClouDNS tərəfindən buraxılanlarla əvəz etmək qalır. Və NS-lər yenilənərkən, biz serverləri hazırlayacağıq.

SSL sertifikatlarının quraşdırılması

CDN-miz HTTPS üzərində işləyəcək, ona görə də domen və ya subdomen üçün SSL sertifikatlarınız varsa, onları bütün serverlərə, məsələn, kataloqa yükləyin /etc/ssl/yourdomain/

Heç bir sertifikat yoxdursa, Let's Encrypt-dən pulsuz sertifikat əldə edə bilərsiniz. Bunun üçün mükəmməldir ACME Shellscript. Müştəri rahat və quraşdırmaq asandır və ən əsası, o, ClouDNS API vasitəsilə bir domeni/alt domeni DNS ilə təsdiq etməyə imkan verir.

Biz acme.sh-ni serverlərdən yalnız birinə - Avropa 199.247.18.199-a quraşdıracağıq, sertifikatlar bütün digərlərinə kopyalanacaq. Quraşdırmaq üçün çalıştırın:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

Skriptin quraşdırılması zamanı bizim iştirakımız olmadan sertifikatların daha da yenilənməsi üçün CRON işi yaradılacaq.

Sertifikat verərkən, domen API istifadə edərək DNS istifadə edərək yoxlanılacaq, buna görə də Reseller API menyusundakı ClouDNS şəxsi hesabında yeni istifadəçi API yaratmalı və onun üçün parol təyin etməlisiniz. Nəticədə parol ilə auth-id fayla yazılacaq ~/.acme.sh/dnsapi/dns_cloudns.sh (fayl ilə qarışdırılmamalıdır dns_clouddns.sh). Budur şərh edilməli və redaktə edilməli olan sətirlər:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

İndi biz SSL sertifikatı tələb edəcəyik cdn.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

Seçimlərdə, gələcək üçün, gələcəkdə sertifikatın etibarlılıq müddətinin hər yenilənməsindən sonra veb server konfiqurasiyasının avtomatik olaraq yenidən yüklənməsi əmrini təyin etdik.

Sertifikat əldə etməyin bütün prosesi 2 dəqiqəyə qədər çəkə bilər, onu kəsməyin. Domenin doğrulanması xətası baş verərsə, əmri yenidən işə salın. Sonda sertifikatların harada yükləndiyini görəcəyik:

CDN-nin qurulması və konfiqurasiyası

Bu yolları yadda saxlayın, onlar sertifikatı digər serverlərə köçürərkən, həmçinin veb server parametrlərində göstərilməlidir. Nginx konfiqurasiyalarının yenidən yüklənməsi səhvinə diqqət yetirmirik - sertifikatları yeniləyərkən tam konfiqurasiya edilmiş serverdə olmayacaq.

SSL üçün bizə qalan yalnız sənədlərin yolunu saxlayarkən alınan sertifikatı digər iki serverə köçürməkdir. Gəlin onların hər birində eyni kataloqları yaradaq və surətini çıxaraq:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

Sertifikatları mütəmadi olaraq yeniləmək üçün hər iki serverdə əmrlə gündəlik CRON işi yaradın:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Bu halda, uzaq mənbə serverinə giriş konfiqurasiya edilməlidir açarla, yəni. parol daxil etmədən. Bunu etməyi unutmayın.

Nginx-in quraşdırılması və konfiqurasiyası

Statik məzmuna xidmət etmək üçün keşləmə proxy serveri kimi konfiqurasiya edilmiş Nginx-dən istifadə edəcəyik. Paket siyahılarını yeniləyin və onu hər üç serverə quraşdırın:

root@cdn:~# apt update
root@cdn:~# apt install nginx

Defolt əvəzinə aşağıdakı spoylerdəki konfiqurasiyadan istifadə edirik:
nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;            

    proxy_temp_path    /var/cache/tmp;
    proxy_cache_path   /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d;
    proxy_cache_bypass $http_x_update;

server {
  listen 443 ssl;
  server_name cdn.sayt.in;

  ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer;
  ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key;

  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://sayt.in;
    }
  }
}

Konfiqurasiyada redaktə edin:

  • maksimum_ölçü — keşin ölçüsü, mövcud disk sahəsindən artıq olmayan
  • effektiv deyil - heç kimin daxil olmadığı keşlənmiş məlumatların saxlanma müddəti
  • ssl_sertifikatı и ssl_certificate_key — SSL sertifikatı və əsas faylların yolları
  • proxy_cache_valid - keşləşdirilmiş məlumatların saxlanma müddəti
  • proxy_pass — CDN-nin keşləmə üçün faylları tələb edəcəyi orijinal serverin ünvanı. Bizim nümunəmizdə bu sayt.in

Gördüyünüz kimi, hər şey sadədir. Yalnız direktivlərin oxşarlığına görə keşləmə vaxtını təyin etməkdə çətinlik yarana bilər effektiv deyil и proxy_cache_valid. Onları nümunəmizlə təhlil edək. Nə zaman baş verir qeyri-aktiv = 7g и proxy_cache_valid 90d:

  • sorğu 7 gün ərzində təkrarlanmazsa, bu müddətdən sonra məlumatlar keş yaddaşdan silinəcəkdir
  • sorğu ən azı 7 gündə bir dəfə təkrarlanarsa, keşdəki məlumatlar 90 gündən sonra köhnəlmiş hesab ediləcək və Nginx onu orijinal serverdən götürərək növbəti sorğu ilə yeniləyəcək.

Redaktə etmək tamamlandı nginx.conf, konfiqurasiyanı yenidən yükləyin:

root@cdn:~# service nginx reload

CDN-miz hazırdır. $15/ay üçün. üç qitədə mövcudluq nöqtələri və 3 TB trafik aldıq: hər yerdə 1 TB.

CDN işinin yoxlanılması

Fərqli coğrafi yerlərdən CDN-mizə pinglərə baxaq. Bunun üçün istənilən ping xidməti işləyəcək.

Başlama nöqtəsi
Ev sahibi
IP
Orta vaxt, ms

Almaniya Berlin
cdn.sayt.in
199.247.18.199
9.6

Hollandiya, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Fransa Paris
cdn.sayt.in
199.247.18.199
16.3

Böyük Britaniya, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

ABŞ, San Fransisko
cdn.sayt.in
149.28.121.123
52.7

ABŞ, Dallas
cdn.sayt.in
149.28.121.123
23.1

ABŞ, Çikaqo
cdn.sayt.in
149.28.121.123
2.6

ABŞ, Nyu York
cdn.sayt.in
149.28.121.123
19.8

Sinqapur
cdn.sayt.in
157.230.240.216
1.7

Yaponiya Tokio
cdn.sayt.in
157.230.240.216
74.8

Avstraliya, Sidney
cdn.sayt.in
157.230.240.216
95.9

Nəticələr yaxşıdır. İndi test şəklini əsas saytın kökünə yerləşdirəcəyik test.jpg və CDN vasitəsilə yükləmə sürətini yoxlayın. Bu deyilib - hazırlanmışdır. Məzmun tez çatdırılır.

CDN nöqtəsindəki önbelleği təmizləmək istədiyimiz halda kiçik bir skript yazaq.
purge.sh

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

Bütün keşi silmək üçün onu işə salmaq kifayətdir, ayrı bir fayl belə təmizlənə bilər:

root@cdn:~# ./purge.sh /test.jpg

Xülasə yerinə

Nəhayət, o vaxt başımı ağrıdan dırmıqdan dərhal keçmək üçün bəzi faydalı məsləhətlər vermək istəyirəm:

  • CDN-nin nasazlığa dözümlülüyünü artırmaq üçün DNS Failover-i konfiqurasiya etmək tövsiyə olunur ki, bu da serverin nasazlığı zamanı A qeydini tez dəyişməyə kömək edir. Bu, domenin idarəetmə panelindəki DNS qeydlərində edilir.
  • Geniş coğrafi əhatəyə malik saytlar, şübhəsiz ki, çox sayda CDN tələb edir, lakin fanatik olmayaq. Çox güman ki, serverləri 6-7 yerdə yerləşdirsəniz, istifadəçi ödənişli CDN ilə müqayisədə əhəmiyyətli fərq görməyəcək: Avropa, Şimali Amerika (şərq), Şimali Amerika (qərb), Sinqapur, Avstraliya, Honq Konq və ya Yaponiya
  • Bəzən hosterlər CDN məqsədləri üçün icarəyə götürülmüş serverlərdən istifadə etməyə icazə vermirlər. Buna görə də, birdən-birə məzmun çatdırılması şəbəkəsini xidmət kimi yerləşdirmək qərarına gəlsəniz, müəyyən bir hosting provayderinin qaydalarını əvvəlcədən oxumağı unutmayın.
  • Kəşf edin sualtı rabitə xəritəsiqitələrin necə əlaqəli olduğunu təmsil etmək və məzmun çatdırılması şəbəkəsi qurarkən bunu nəzərə almaq
  • Yoxlamağa çalışın müxtəlif yerlərdən ping serverlərinizə. Bu yolla siz CDN nöqtələrinə ən yaxın bölgələri görə və GeoDNS-i daha düzgün konfiqurasiya edə bilərsiniz
  • Tapşırıqlardan asılı olaraq, Nginx-i xüsusi keşləmə tələbləri üçün və serverdəki yükü nəzərə alaraq tənzimləmək faydalı olacaq. Nginx cache haqqında məqalələr bu işdə mənə çox kömək etdi - burada və ağır yüklər altında işin sürətləndirilməsi: burada и burada

Mənbə: www.habr.com