Content Delivery Networks (CDN) are used on websites and applications primarily to speed up the loading of static elements. This is achieved by caching files on CDN servers located in different geographical regions. When data is requested via a CDN, the user receives it from the nearest server.
The principle of operation and functionality of all content delivery networks is roughly the same. Upon receiving a request to load a file, the CDN server retrieves it once from the original server and delivers it to the user, while caching it for a specified period. For all subsequent requests, the response is delivered from the cache. All CDNs have options for pre-loading files, clearing the cache, setting the storage duration, and much more.
Sometimes, for various reasons, there is a need to organize your own content delivery network, and then — may this guide help us in building another bicycle.
Kilde:
When a private CDN is needed
Let's consider situations when launching your own CDN makes sense:
- when there is a desire to save, and current expenses even when using inexpensive CDNs like amount to several hundred dollars per month
- if we want to have a permanent cache or a cache without neighbors on the server and channel
- in the region you need, there are no points of presence for CDN services
- special settings for content delivery are required
- we want to speed up the delivery of dynamic content by placing production servers closer to users
- there are concerns that a third-party CDN service may illegally collect or use information about user behavior (hello to services without GDPR compliance) or engage in other illegal actions
In most other cases, it is more expedient to use existing ready-made solutions.
What is needed to launch
It is great if you have your own Autonomous System (AS). With it, you can assign the same IP to multiple servers and direct users to the nearest one at the network level. It is worth mentioning that even with a block of addresses /24, it is possible to build a content delivery network. Some server providers allow making an announcement for use in all available regions.
Hvis du ikke er en heldig ejer af et IP-adresseblok, har du brug for følgende for at starte en simpel CDN:
- et domænenavn eller subdomæne
- mindst to servere i forskellige regioner. Serveren kan være både dedikeret og virtuel
- et geoDNS-værktøj. Med det vil en bruger, der tilgår domænet, blive dirigeret til den nærmeste server
Registrer et domæne og bestil servere
Registreringen af domænet er enkel — registrer i enhver zone hos enhver registrar. Du kan også bruge et subdomæne til CDN, som for eksempel cdn.ditdomæne.com. I vores eksempel vil vi gøre netop det.
Når det gælder bestilling af servere, bør de lejes i de regioner og lande, hvor din brugeraudience befinder sig. Er projektet interkontinentalt, er det praktisk at vælge hostingudbydere, der tilbyder servere over hele verden. Eksempler: , og — for dedikerede servere, og — for virtuelle cloud*-server.
Til vores private CDN bestiller vi 3 virtuelle servere på forskellige kontinenter. U Vultr den server til $5/måned får vi 25GB SSD plads og 1TB trafik. Ved installation vælger vi den nyeste Debian. Vores servere:
Frankfurt, ip: 199.247.18.199
Chicago, ip: 149.28.121.123
Singapore, ip: 157.230.240.216
* Vultr og DigitalOcean tilbyder $100 kredit til brugere, der tilmelder sig via links i artiklen, straks efter at betalingsmetoden er tilføjet. Forfatteren modtager også en lille belønning, hvilket er meget betydningsfuldt for ham i øjeblikket. Vi beder dig venligst om at vise forståelse.
Konfigurer geoDNS
For at brugeren, når de tilgår domænet eller subdomænet til CDN, bliver dirigeret til den rigtige (nærmeste til dem) server, har vi brug for en DNS-server med geoDNS-funktion.
Princippet og arbejdsmetoden for geoDNS er følgende:
- Den identificerer IP'en på klienten, der sendte DNS-anmodningen, eller IP'en på den rekursive DNS-server, der anvendes til at håndtere klientens anmodning. Disse rekursive servere er typisk DNS'er fra udbyderne.
- Fra klientens IP kan den identificere deres land eller region. Dette gøres ved hjælp af GeoIP-databaser, der findes i stort antal. Der er nogle gode .
- Afhængigt af klientens placering sender den den IP-adresse til den nærmeste CDN-server.
En DNS-server med geoDNS-funktion kan man , men det er bedre at bruge færdige løsninger med et netværk af DNS-servere over hele verden og out of the box:
- fra $9.95/måned, GeoDNS-plan, der som standard inkluderer en DNS Failover
- fra $25/måned, inkluderet DNS Failover
- fra $35/måned for op til 50M geo-forespørgsler. DNS Failover faktureres separat
- fra $125/måned, der indeholder 10 DNS Failover
- , funktionen 'Geo Steering' er tilgængelig i Enterprise-planer
Når man bestiller geoDNS, skal man være opmærksom på antallet af inkluderede forespørgsler i planen og huske, at det reelle antal henvendelser til domænet kan overstige forventningerne dramatisk. Millioner af robotter, crawlere, spammerere og andre uønskede elementer arbejder uafbrudt.
Næsten alle DNS-tjenester inkluderer en uundgåelig service til opbygning af CDN — DNS Failover i prisen. Med denne kan man indstille overvågning af sine servere og automatisk erstatte adressen på en ikke-fungerende server i DNS-svar med en backup i tilfælde af manglende aktivitetsindikatorer.
Til opbygning af vores CDN vil vi bruge , GeoDNS-plan.
Vi tilføjer en ny DNS-zone i kontrolpanelet ved at angive vores domæne. Hvis vi bygger CDN på et subdomæne, og hoveddomænet allerede er i brug, så glem ikke at tilføje de eksisterende arbejds-DNS-poster umiddelbart efter tilføjelse af zonen. Det næste skridt er at oprette flere A-poster for CDN-domenet/subdomænet, hvor hver enkelt vil blive anvendt til det område, vi har angivet. Regioner kan angives som kontinenter eller lande, subregioner er tilgængelige for USA og Canada.
I vores tilfælde vil CDN blive oprettet på subdomænet cdn.sayt.in. Ved at tilføje zonen sayt.in, vil vi oprette den første A-post for subdomænet og dirigere hele Nordamerika til serveren i Chicago:
Vi gentager handlingen for de andre regioner og husker at oprette én post for standardregionerne. Her er, hvad det ender med:
Den sidste standardpost på skærmbilledet betyder, at alle udefinerede regioner (som Europa, Afrika, brugere af satellit-internet osv.) vil blive dirigeret til serveren i Frankfurt.
Den grundlæggende DNS-konfiguration er nu afsluttet. Det er tid til at gå til domæneregistratorens hjemmeside og erstatte de nuværende NS-poster for domænet med dem givet af ClouDNS. Mens NS-posterne bliver opdateret, vil vi forberede serverne.
Installation af SSL-certifikater
Vores CDN vil fungere via HTTPS, så hvis du allerede har SSL-certifikater til domænet eller subdomænet, — upload dem til alle servere, for eksempel i mappen /etc/ssl/вашдомен/
Hvis du ikke har certifikater, kan du få et gratis fra Let’s Encrypt. Det kan nemt gøres med . Kunden er let og simpel at konfigurere, og vigtigst af alt - det muliggør validering af domæne/subdomæne via DNS gennem ClouDNS API.
Vi installerer acme.sh kun på en af serverne - den europæiske 199.247.18.199, hvorfra certifikaterne vil blive kopieret til alle andre. For at installere skal vi udføre:
root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/ .bashrcUnder installationen af skriptet vil en CRON opgave blive oprettet for fremadrettet opdatering af certifikaterne uden vores indblanding.
Domænevalidering ved udstedelse af certifikatet vil blive udført via DNS ved brug af API, så i ClouDNS brugerkontrolpanel under menuen Reseller API skal der oprettes en ny API-bruger og tildeles en adgangskode. Den modtagne auth-id med adgangskoden skal indsættes i filen ~/ .acme.sh/ dnsapi/ dns_cloudns.sh (forveksles ikke med filen dns_clouddns.sh). Her er de linjer, der skal afkommenteres og redigeres:
CLOUDNS_AUTH_ID=
CLOUDNS_AUTH_PASSWORD=""
Nu anmoder vi om at modtage SSL-certifikatet til cdn.sayt.in
root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"I parametrene har vi angivet kommandoen til automatisk genstart af webserverens konfiguration efter hver fornyelse af certifikatets gyldighed i fremtiden.
Hele processen med at få certifikatet kan tage op til 2 minutter, så afbryd den ikke. Hvis der opstår en valideringsfejl, så prøv at køre kommandoen igen. Til sidst vil vi se, hvor certifikaterne blev gemt:
Husk disse stier, de skal angives ved kopiering af certifikatet til andre servere, samt i webserverens indstillinger. Vi ignorerer fejl ved genstart af konfigurationerne i Nginx - på en fuldt konfigureret server vil der ikke være nogen ved opdatering af certifikater.
Alt hvad vi mangler med hensyn til SSL, er at kopiere det modtagne certifikat til de to andre servere under bevarelse af stierne til filerne. Vi opretter de samme mapper på hver af dem og laver en kopi:
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/
For at sikre regelmæssig opdatering af certifikaterne opretter vi en daglig CRON opgave på begge servere med følgende kommando:
scp -r root@199.247.18.199:/root/ .acme.sh/ cdn.sayt.in/* /root/ .acme.sh/ cdn.sayt.in/ && service nginx reload
Her skal adgangen til den eksterne kilde-server være indstillet , det vil sige uden indtastning af adgangskode. Glem ikke at gøre dette.
Installation og konfiguration af Nginx
For serving static content, we will use Nginx configured as a caching proxy server. We will update the package lists and install it on all three servers:
root@cdn:~# apt update
root@cdn:~# apt install nginxInstead of the default configuration, we will use the config from the spoiler below:
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;
}
}
}In the config, we edit:
- max_size — the size of the cache not exceeding the available disk space
- inactive — the time the cached data is kept when not accessed by anyone
- ssl_certificate og ssl_certificate_key — paths to the SSL certificate and key files
- proxy_cache_valid — the duration for which cached data is stored
- proxy_pass — the address of the origin server from which the CDN will request files for caching. In our example, this is sayt.in
As we can see, it's straightforward. The only complexity may arise in setting the caching time due to the similarity of the directives inactive og proxy_cache_valid. We will analyze them using our example. Here’s what happens with inactive=7d og proxy_cache_valid 90d:
- if the request is not repeated within 7 days, the data will be removed from the cache after this period
- if the request occurs at least once within 7 days, the data in the cache will be considered stale after 90 days, and on the next request, Nginx will update it by fetching from the origin server
Once we finish editing nginx.conf, we will reload the configuration:
root@cdn:~# service nginx reloadOur CDN is fully ready. For $15/month, we got points of presence on three continents and 3 Tb of traffic: 1 Tb in each location.
Testing CDN functionality
Let’s check the pings to our CDN from different geographical locations. Any ping services will do for this.
Launch point
Vært
IP
Avg time, ms
Germany, Berlin
cdn.sayt.in
199.247.18.199
9.6
Netherlands, Amsterdam
cdn.sayt.in
199.247.18.199
10.1
France, Paris
cdn.sayt.in
199.247.18.199
16.3
United Kingdom, London
cdn.sayt.in
199.247.18.199
14.9
Canada, Toronto
cdn.sayt.in
149.28.121.123
16.2
USA, San Francisco
cdn.sayt.in
149.28.121.123
52.7
USA, Dallas
cdn.sayt.in
149.28.121.123
23.1
USA, Chicago
cdn.sayt.in
149.28.121.123
2.6
USA, New York
cdn.sayt.in
149.28.121.123
19.8
Singapore
cdn.sayt.in
157.230.240.216
1.7
Japan, Tokyo
cdn.sayt.in
157.230.240.216
74.8
Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9
Results are good. We will now upload a test image to the root of the main site test.jpg and check its loading speed via CDN. It has been said, — . Content is delivered quickly.
We will write a small script in case we want to clear the cache at the CDN point.
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
To remove the entire cache, just run it; a separate file can be cleared like this:
root@cdn:~# ./purge.sh /test.jpgI stedet for konklusioner
Lastly, I want to give a few useful tips to help avoid the pitfalls that once gave me a headache:
- To increase the fault tolerance of the CDN, it is recommended to configure DNS Failover, which helps to quickly change the A record in case of server failure. This is done in the DNS management panel of the domain
- Websites with a wide geographical reach undoubtedly require a large number of CDN points, but let’s avoid going overboard. Most likely, the user will not notice a significant difference compared to a paid CDN if you deploy servers in 6-7 locations: Europe, North America (east), North America (west), Singapore, Australia, Hong Kong or Japan
- Sometimes hosts do not allow rented servers to be used for CDN purposes. Therefore, if you decide to deploy a content delivery network as a service, make sure to read the specific rules of the hosting provider in advance
- Study , to understand how continents are connected and consider this when building the content delivery network
- Try to check to your servers. This way you can see the regions closest to the CDN points and better configure GeoDNS
- Depending on your tasks, it may be helpful to further configure Nginx for specific caching requirements and with regard to server load. I found articles on Nginx caching — and improving performance under heavy loads very helpful: og
Kilde: habr.com
