İç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:
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 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 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: , и - özel sunucular için, и — 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 trafikKurulum sırasında en güncel olanı seçeceğiz. DebianSunucuları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 .
- İstemcinin konumuna bağlı olarak ona en yakın CDN sunucusunun IP adresini verir.
GeoDNS işlevine sahip DNS sunucusu , ancak dünya çapında bir DNS sunucuları ağıyla hazır çözümler kullanmak daha iyidir ve kutudan:
- itibaren 9.95$/ay, GeoDNS tarifesi, varsayılan olarak bir DNS Yük Devretme vardır
- itibaren 25$/ay, DNS Yük Devretme etkin
- itibaren 35$/ay net 50 milyon coğrafi istek için. DNS Yük Devretme ayrı olarak faturalandırılır
- itibaren 125$/ay, 10 DNS Yük Devretmesi var
- , "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 , 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 . İ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 ~/.bashrcKomut 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 root@199.247.18.199:/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 root@199.247.18.199:/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 yani ş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 nginxVarsayı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 reloadCDN'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 - . İç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.jpgSonuç 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 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 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 - ve ağır yükler altında işin hızlandırılması: и
Kaynak: habr.com
