🥇CDN'nizi oluşturma ve yapılandırma

İçerik Dağıtım Ağları (CDN'ler), web sitelerinde ve uygulamalarda öncelikle statik öğelerin yüklenmesini hızlandırmak için kullanılır. Bunun nedeni, dosyaların farklı coğrafi bölgelerde bulunan CDN sunucularında önbelleğe alınmasıdır. Kullanıcı, CDN aracılığıyla veri talep ederek bu bilgiyi en yakın sunucudan alır.

Tüm içerik dağıtım ağlarının çalışma prensibi ve işlevselliği yaklaşık olarak aynıdır. Bir dosyayı indirme isteği alan CDN sunucusu, dosyayı orijinal sunucudan bir defaya mahsus alır ve kullanıcıya verir, aynı zamanda dosyayı belirli bir süre boyunca önbelleğe alır. Sonraki tüm istekler önbellekten yanıtlanır. Tüm CDN'lerde dosyaları önceden yükleme, önbelleği temizleme, son kullanma tarihini ayarlama ve daha pek çok seçenek bulunur.

Öyle ya da böyle, kendi içerik dağıtım ağınızı organize etmeniz ve ardından bir sonraki bisikletin montajına ilişkin talimatların bize yardımcı olmasına izin vermeniz gerekir.

Kaynak: Pikisuperstar tarafından oluşturulan infografik vektör - www.freepik.com

Kendi CDN'nize ihtiyacınız olduğunda

Kendi CDN'nizi çalıştırmanın anlamlı olduğu durumları göz önünde bulundurun:

gibi ucuz CDN'leri kullanırken bile paradan tasarruf etme isteği ve işletme maliyetleri olduğunda TavşanCDN ayda birkaç yüz dolar tutarında
kalıcı bir önbellek veya sunucu ve kanal komşuları olmayan bir önbellek almak istiyorsak
CDN hizmetlerinin ihtiyacınız olan bölgede varlık noktaları yok
herhangi bir özel içerik yayınlama ayarı gerekli
üretim sunucusunu kullanıcılara daha yakın yerleştirerek dinamik içeriğin dağıtımını hızlandırmak istiyoruz
Üçüncü taraf bir CDN hizmetinin, kullanıcı davranışı hakkında (Merhaba GDPR uyumlu olmayan hizmetler) yasa dışı olarak bilgi toplayabileceği veya kullanabileceği ya da başka yasa dışı faaliyetlerde bulunabileceğine dair endişeler var

Diğer birçok durumda mevcut hazır çözümlerin kullanılması daha uygundur.

Başlamak için neye ihtiyacınız var?

Kendi Otonom Sisteminizin (AS) olması harika bir şey. Bununla birlikte, aynı IP'yi birden fazla sunucuya atayabilirsiniz ve bu talimata göre ağ düzeyinde kullanıcıları en yakındakine yönlendirin. /24 adres bloğuyla bile içerik dağıtım ağı oluşturmanın mümkün olduğunu söylemekte fayda var. Bazı sunucu sağlayıcıları kendilerine sunulan tüm bölgelerde kullanılmak üzere duyuru yapmanıza izin verir.

Bir IP adresi bloğunun mutlu sahibi değilseniz, basit bir CDN çalıştırmak için ihtiyacınız olacak:

alan adı veya alt alan adı
farklı bölgelerdeki en az iki sunucu. Sunucu özel veya sanal olabilir
geoDNS aracı. Bununla birlikte, etki alanını adresleyen kullanıcı en yakın sunucuya yönlendirilecektir.

Bir alan adı kaydedin ve sunucuları sipariş edin

Alan adı kaydıyla her şey basittir - herhangi bir bölgede herhangi bir kayıt şirketiyle kayıt oluyoruz. Ayrıca bir CDN için bir alt alan adı da kullanabilirsiniz; örneğin şunun gibi bir şey: cdn.alanadı.com. Aslında örneğimizde tam da bunu yapacağız.

Sunucu siparişi vermek gerekirse kullanıcı kitlenizin bulunduğu bölge ve ülkelerde kiralanmalıdır. Proje kıtalararası ise, dünyanın her yerinde sunucuları aynı anda sunan barındırma sağlayıcılarını seçmek uygundur. Örnekler: OVH, kiralama ağı и 100Tb - özel sunucular için, Vultr и DigitalOcean — sanal bulut için*.

Özel CDN'miz için farklı kıtalarda 3 adet sanal sunucu siparişi vereceğiz. Şu tarihte: Vultr için sunucuda 5$/ay alacağız 25GB SSD yerler ve 1TB trafik. Kurulum sırasında en güncel Debian'ı seçin. Sunucularımız:

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapur, ip: 157.230.240.216

*Vultr ve DigitalOcean, ödeme yöntemi ekledikten hemen sonra makaledeki bağlantılar aracılığıyla kaydolan kullanıcılara 100 ABD Doları kredi vaat ediyor. Yazar bundan küçük bir iltifat da alıyor ki bu onun için artık çok önemli. Lütfen anlayışlı olun.

GeoDNS'i ayarlama

Kullanıcının bir alan adına veya CDN alt alanına erişirken istediği (en yakın) sunucuya yönlendirilebilmesi için geoDNS fonksiyonuna sahip bir DNS sunucusuna ihtiyacımız var.

GeoDNS'in prensibi ve işleyişi aşağıdaki gibidir:

DNS isteğini gönderen istemcinin IP'sini veya istemci isteğini işlerken kullanılan yinelemeli DNS sunucusunun IP'sini belirtir. Bu tür özyinelemeli sunucular genellikle sağlayıcıların DNS'leridir.
Müşterinin IP'si ülkesini veya bölgesini tanır. Bunun için günümüzde çok sayıda bulunan GeoIP veritabanları kullanılmaktadır. iyiler var ücretsiz seçenekler.
İstemcinin konumuna bağlı olarak ona en yakın CDN sunucusunun IP adresini verir.

GeoDNS işlevine sahip DNS sunucusu kendiniz toplayın, ancak dünya çapında bir DNS sunucuları ağıyla hazır çözümler kullanmak daha iyidir ve anycast kutudan:

LouDNS itibaren 9.95$/ay, GeoDNS tarifesi, varsayılan olarak bir DNS Yük Devretme vardır
Zilor itibaren 25$/ay, DNS Yük Devretme etkin
Amazon Rota 53 itibaren 35$/ay net 50 milyon coğrafi istek için. DNS Yük Devretme ayrı olarak faturalandırılır
DNS Kolaylaştırıldı itibaren 125$/ay, 10 DNS Yük Devretmesi var
Cloudflare, "Coğrafi Yönlendirme" özelliği Kurumsal planlarda mevcuttur

geoDNS siparişi verirken tarifeye dahil olan istek sayısına dikkat etmeli ve alana gelen gerçek istek sayısının beklentileri birkaç kat aşabileceğini aklınızda bulundurmalısınız. Milyonlarca örümcek, tarayıcı, spam gönderici ve diğer kötü ruhlar yorulmadan çalışıyor.

Hemen hemen tüm DNS hizmetleri, CDN oluşturmak için vazgeçilmez bir hizmet içerir - DNS Yük Devretme. Onun yardımıyla, sunucularınızın çalışmasının izlenmesini ayarlayabilir ve yaşam belirtileri olmadığında, çalışmayan bir sunucunun adresini DNS yanıtlarında otomatik olarak yedek bir sunucuyla değiştirebilirsiniz.

CDN'mizi oluşturmak için kullanacağız CloudDNS, GeoDNS tarifesi.

Kişisel hesabınıza etki alanınızı belirterek yeni bir DNS bölgesi ekleyelim. Bir alt alan adı üzerinde bir CDN oluşturuyorsak ve ana alan adı zaten kullanımdaysa, bölgeyi ekledikten hemen sonra mevcut çalışan DNS kayıtlarını eklemeyi unutmayın. Bir sonraki adım, CDN alanı/alt alanı için her biri belirttiğimiz bölgeye uygulanacak birkaç A kaydı oluşturmaktır. Kıtaları veya ülkeleri bölge olarak belirtebilirsiniz, ABD ve Kanada için alt bölgeler mevcuttur.

Bizim durumumuzda CDN bir alt alanda yükseltilecek cdn.sayt.in. Bölge ekleyerek sayt.in, alt alan adı için ilk A kaydını oluşturun ve Kuzey Amerika'nın tamamını Chicago'daki sunucuya yönlendirin:

Varsayılan bölgeler için bir giriş oluşturmayı unutmadan, işlemi diğer bölgeler için de tekrarlayalım. İşte sonunda ne oluyor:

Ekran görüntüsündeki son varsayılan giriş, belirtilmemiş tüm bölgelerin (ve bunlar Avrupa, Afrika, uydu İnternet kullanıcıları vb.) Frankfurt'taki sunucuya gönderileceği anlamına gelir.

Bu, temel DNS kurulumunu tamamlar. Geriye alan adı kayıt kuruluşunun web sitesine gitmek ve mevcut alan adı NS'lerini ClouDNS tarafından verilenlerle değiştirmek kalıyor. NS'ler güncellenirken biz de sunucuları hazırlayacağız.

SSL sertifikalarının kurulumu

CDN'miz HTTPS üzerinden çalışacaktır; dolayısıyla, bir alan adı veya alt alan adı için zaten SSL sertifikalarınız varsa, bunları tüm sunuculara, örneğin dizine yükleyin. /etc/ssl/alanınız/

Sertifika yoksa Let's Encrypt'tan ücretsiz bir sertifika alabilirsiniz. Bunun için mükemmel ACME Shellscript'i. İstemcinin kurulumu kullanışlı ve kolaydır ve en önemlisi, bir etki alanını/alt etki alanını ClouDNS API aracılığıyla DNS ile doğrulamanıza olanak tanır.

Acme.sh'yi yalnızca sertifikaların diğerlerine kopyalanacağı Avrupa 199.247.18.199 sunucularından birine kuracağız. Yüklemek için şunu çalıştırın:

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

Komut dosyasının kurulumu sırasında, katılımımız olmadan sertifikaların daha fazla yenilenmesi için bir CRON işi oluşturulacaktır.

Sertifika verirken, alan adı API kullanılarak DNS kullanılarak kontrol edilecektir, bu nedenle Reseller API menüsündeki ClouDNS kişisel hesabında yeni bir kullanıcı API'si oluşturmanız ve bunun için bir şifre ayarlamanız gerekir. Ortaya çıkan kimlik doğrulama kimliği, şifreyle birlikte dosyaya yazılacaktır. ~/.acme.sh/dnsapi/dns_cloudns.sh (dosya ile karıştırılmamalıdır) dns_clouddns.sh). Yorumlanması ve düzenlenmesi gereken satırlar şöyle:

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

Şimdi bir SSL sertifikası isteyeceğiz. cdn.sayt.in

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

Seçeneklerde, gelecekte sertifika geçerlilik süresinin her yenilenmesinden sonra web sunucusu yapılandırmasının otomatik olarak yeniden yüklenmesini sağlayacak bir komut belirledik.

Sertifika alma sürecinin tamamı 2 dakika kadar sürebilir, kesintiye uğratmayın. Etki alanı doğrulama hatası oluşursa komutu yeniden çalıştırmayı deneyin. Sonunda sertifikaların nereye yüklendiğini göreceğiz:

Bu yolları unutmayın; sertifikayı diğer sunuculara kopyalarken ve web sunucusu ayarlarında belirtilmeleri gerekecektir. Nginx yapılandırmalarını yeniden yükleme hatasına dikkat etmiyoruz - sertifikaları güncellerken tam olarak yapılandırılmış bir sunucuda olmayacaktır.

SSL için geriye kalan tek şey, dosyaların yolunu korurken alınan sertifikayı diğer iki sunucuya kopyalamaktır. Her birinde aynı dizinleri oluşturalım ve bir kopyasını oluşturalım:

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/

Sertifikaları düzenli olarak güncellemek için her iki sunucuda da şu komutla günlük bir CRON işi oluşturun:

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

Bu durumda uzak kaynak sunucuya erişim yapılandırılmalıdır anahtarlayani şifre girmeden. Bunu yapmayı unutmayın.

Nginx'i yükleme ve yapılandırma

Statik içerik sunmak için önbelleğe alma proxy sunucusu olarak yapılandırılmış Nginx'i kullanacağız. Paket listelerini güncelleyin ve üç sunucuya da yükleyin:

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

Varsayılan yerine aşağıdaki spoilerdeki yapılandırmayı kullanıyoruz:
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;
    }
  }
}

Yapılandırmada düzenleyin:

maksimum_boyut — kullanılabilir disk alanını aşmayan önbellek boyutu
pasif - kimsenin erişmediği önbelleğe alınmış verilerin saklanma süresi
ssl_certificate и ssl_certificate_key — SSL sertifikasına ve anahtar dosyalarına giden yollar
proxy_cache_valid - önbelleğe alınan verilerin saklanma süresi
proxy_pass — CDN'nin önbelleğe alma için dosya talep edeceği orijinal sunucunun adresi. Örneğimizde bu sayt.in

Gördüğünüz gibi her şey basit. Yönergelerin benzerliği nedeniyle yalnızca önbellekleme süresinin ayarlanmasında zorluk ortaya çıkabilir pasif и proxy_cache_valid. Örneğimize bir göz atalım. İşte ne zaman olur? etkin değil=7d и proxy_cache_valid 90d:

Talep 7 gün içerisinde tekrarlanmazsa bu süre sonunda veriler önbellekten silinecektir.
istek en az 7 günde bir tekrarlanırsa, önbellekteki veriler 90 gün sonra eskimiş sayılacak ve Nginx, verileri orijinal sunucudan alarak bir sonraki istekle güncelleyecektir.

Düzenleme tamamlandı nginx.conf, yapılandırmayı yeniden yükleyin:

root@cdn:~# service nginx reload

CDN'miz hazır. Aylık 15$ karşılığında. üç kıtada varlık noktaları ve her konumda 3 TB olmak üzere 1 TB trafik aldık.

CDN'nin çalışmasını kontrol etmek

Farklı coğrafi konumlardan CDN'mize gönderilen pinglere bakalım. Bunun için herhangi bir ping servisi işe yarayacaktır.

Fırlatma noktası
Ev sahibi
IP
Ortalama süre, ms

Almanya Berlin
cdn.sayt.in
199.247.18.199
9.6

Hollanda, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Fransa Paris
cdn.sayt.in
199.247.18.199
16.3

İngiltere, Londra
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

ABD, San Francisco
cdn.sayt.in
149.28.121.123
52.7

ABD, Dallas
cdn.sayt.in
149.28.121.123
23.1

ABD, Chicago
cdn.sayt.in
149.28.121.123
2.6

ABD, New York
cdn.sayt.in
149.28.121.123
19.8

Singapur
cdn.sayt.in
157.230.240.216
1.7

Japonya Tokyo
cdn.sayt.in
157.230.240.216
74.8

Avustralya, Sidney
cdn.sayt.in
157.230.240.216
95.9

Sonuçlar iyi. Şimdi ana sitenin köküne bir test görüntüsü yerleştireceğiz test.jpg ve indirme hızını CDN aracılığıyla kontrol edin. Söylendi - tamam. İçerik hızlı bir şekilde teslim edilir.

CDN noktasındaki önbelleği temizlemek istersek diye küçük bir script yazalım.
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

Önbelleğin tamamını silmek için çalıştırmanız yeterlidir; ayrı bir dosya şu şekilde temizlenebilir:

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

Sonuç yerine

Son olarak o zamanlar başımı ağrıtan tırmıkların üzerinden hemen geçmek için bazı faydalı ipuçları vermek istiyorum:

CDN'nin hata toleransını artırmak için, sunucu arızası durumunda A kaydının hızlı bir şekilde değiştirilmesine yardımcı olan DNS Yük Devretme'nin yapılandırılması önerilir. Bu, etki alanının kontrol paneli DNS kayıtlarında yapılır.
Geniş coğrafi kapsama sahip siteler şüphesiz çok sayıda CDN gerektirir, ancak fanatik olmayalım. Sunucuları 6-7 konuma yerleştirirseniz, kullanıcı büyük olasılıkla ücretli bir CDN'ye kıyasla önemli bir fark görmeyecektir: Avrupa, Kuzey Amerika (doğu), Kuzey Amerika (batı), Singapur, Avustralya, Hong Kong veya Japonya
Bazen barındırma sağlayıcıları, kiralanan sunucuların CDN amacıyla kullanılmasına izin vermez. Bu nedenle, aniden bir içerik dağıtım ağını hizmet olarak dağıtmaya karar verirseniz, önceden belirli bir barındırma sağlayıcısının kurallarını okumayı unutmayın.
keşfetmek sualtı iletişim haritasıKıtaların nasıl bağlantılı olduğunu temsil etmek ve bir içerik dağıtım ağı oluştururken bunu dikkate almak
Kontrol etmeyi dene farklı yerlerden gelen pingler sunucularınıza. Bu sayede CDN noktalarına en yakın bölgeleri görebilir ve GeoDNS'i daha doğru yapılandırabilirsiniz.
Görevlere bağlı olarak, belirli önbellekleme gereksinimleri için ve sunucudaki yükü dikkate alarak Nginx'e ince ayar yapmak faydalı olacaktır. Nginx önbelleğiyle ilgili makaleler bu konuda bana çok yardımcı oldu - burada ve ağır yükler altında işin hızlandırılması: burada и burada

Kaynak: habr.com