ProHoster > Log > administrasjon > Bygge og konfigurere CDN

Bygge og konfigurere CDN

Content Delivery Networks (CDN) brukes i nettsteder og applikasjoner primært for å øke hastigheten på lasting av statiske elementer. Dette skjer på grunn av bufring av filer på CDN-servere som ligger i forskjellige geografiske regioner. Ved å be om data via CDN, mottar brukeren den fra nærmeste server.

Prinsippet for drift og funksjonalitet for alle innholdsleveringsnettverk er omtrent det samme. Etter å ha mottatt en forespørsel om å laste ned en fil, tar CDN-serveren den en gang fra den opprinnelige serveren og gir den til brukeren, samtidig som den bufres i en spesifisert tidsperiode. Alle påfølgende forespørsler besvares fra cachen. Alle CDN-er har alternativer for å forhåndslaste filer, tømme hurtigbufferen, angi utløpsdatoen og mer.

Det hender at du av en eller annen grunn må organisere ditt eget innholdsleveringsnettverk, og deretter - la instruksjonene for montering av neste sykkel være til hjelp for oss.

Bygge og konfigurere CDN
Kilde: Infografisk vektor laget av pikisuperstar - www.freepik.com

Når du trenger ditt eget CDN

Tenk på tilfellene der det er fornuftig å kjøre ditt eget CDN:

  • når det er et ønske om å spare penger, og driftskostnader selv når du bruker rimelige CDN-er som BunnyCDN beløpe seg til flere hundre dollar i måneden
  • hvis vi ønsker å få en permanent cache eller en cache uten server- og kanalnaboer
  • CDN-tjenester har ikke tilstedeværelsespunkter i regionen du trenger
  • eventuelle spesielle innholdsleveringsinnstillinger som kreves
  • vi ønsker å fremskynde leveringen av dynamisk innhold ved å plassere produksjonsserveren nærmere brukerne
  • det er en bekymring for at en tredjeparts CDN-tjeneste ulovlig kan samle inn eller bruke informasjon om brukeratferd (hei ikke-GDPR-kompatible tjenester) eller delta i andre ulovlige aktiviteter

I de fleste andre tilfeller er det mer hensiktsmessig å bruke eksisterende ferdige løsninger.

Hva trenger du for å starte

Det er fantastisk hvis du har ditt eget Autonome System (AS). Med den kan du tilordne samme IP til flere servere og i henhold til denne instruksen på nettverksnivå, diriger brukerne til den nærmeste. Det er verdt å si at selv med /24-adresseblokken er det mulig å bygge et innholdsleveringsnettverk. Noen serverleverandører lar deg gjøre en kunngjøring for bruk i alle regioner som er tilgjengelige for dem.

Hvis du ikke er en lykkelig eier av en blokk med IP-adresser, trenger du for å kjøre en enkel CDN:

  • domenenavn eller underdomene
  • minst to servere i forskjellige regioner. Serveren kan enten være dedikert eller virtuell
  • geoDNS-verktøy. Med den vil brukeren, som har adressert domenet, bli dirigert til nærmeste server

Registrer et domene og bestill servere

Med domeneregistrering er alt enkelt - vi registrerer oss i hvilken som helst sone hos hvilken som helst registrar. Du kan også bruke et underdomene for et CDN, for eksempel noe sånt cdn.domenenavn.com. Faktisk, i vårt eksempel, vil vi gjøre nettopp det.

Når det gjelder bestillingsservere, bør de leies i regionene og landene der brukerpublikummet ditt befinner seg. Hvis prosjektet er interkontinentalt, er det praktisk å velge vertsleverandører som tilbyr servere over hele verden på en gang. Eksempler: OVH, leie web и 100Tb - for dedikerte servere, Vultr и DigitalOcean — for virtuell sky*.

For vårt private CDN vil vi bestille 3 virtuelle servere på forskjellige kontinenter. På Vultr på serveren for $5/md vi vil få 25GB SSD steder og 1 TB trafikk. Når du installerer, velg den nyeste Debian. Våre servere:

Bygge og konfigurere CDN Frankfurt, IP: 199.247.18.199

Bygge og konfigurere CDN Chicago, IP: 149.28.121.123

Bygge og konfigurere CDN Singapore, IP: 157.230.240.216

* Vultr og DigitalOcean lover $100 kreditt til brukere som registrerer seg via lenkene i artikkelen umiddelbart etter å ha lagt til en betalingsmetode. Forfatteren får også et lite kompliment av dette, som er svært betydningsfullt for ham nå. Vær forståelsesfull.

Sette opp geoDNS

For at brukeren skal ledes til ønsket (nærmeste) server ved tilgang til et domene eller CDN-underdomene trenger vi en DNS-server med geoDNS-funksjonen.

Prinsippet og driften av geoDNS er som følger:

  1. Spesifiserer IP-en til klienten som sendte DNS-forespørselen, eller IP-en til den rekursive DNS-serveren som brukes ved behandling av klientforespørselen. Slike rekursive servere er vanligvis DNS-er fra leverandører.
  2. IP-en til klienten gjenkjenner hans land eller region. Til dette benyttes GeoIP-databaser, som det er svært mange av i dag. Det er gode gratis alternativer.
  3. Avhengig av plasseringen til klienten, gir ham IP-adressen til nærmeste CDN-server.

DNS-server med geoDNS-funksjon kan være sette sammen selv, men det er bedre å bruke ferdige løsninger med et nettverk av DNS-servere rundt om i verden og anycast fra esken:

  • CloudDNS fra $9.95/md, GeoDNS-tariff, som standard er det én DNS-failover
  • Zilore fra $25/md, DNS-failover aktivert
  • Amazon Route 53 fra $35/md for netto 50 millioner geo-forespørsler. DNS Failover faktureres separat
  • DNS gjort enkelt fra $125/md, det er 10 DNS-failovers
  • CloudFlare, "Geo Steering"-funksjonen er tilgjengelig i Enterprise-planer

Når du bestiller geoDNS, bør du være oppmerksom på antall forespørsler som er inkludert i tariffen og huske på at det faktiske antallet forespørsler til domenet kan overgå forventningene flere ganger. Millioner av edderkopper, skannere, spammere og andre onde ånder jobber utrettelig.

Nesten alle DNS-tjenester inkluderer en uunnværlig tjeneste for å bygge en CDN - DNS Failover. Med dens hjelp kan du sette opp overvåking av driften av serverne dine og, i fravær av tegn på liv, automatisk erstatte adressen til en ikke-fungerende server med en sikkerhetskopi i DNS-svar.

For å bygge vårt CDN, vil vi bruke CloudDNS, GeoDNS-tariff.

La oss legge til en ny DNS-sone i din personlige konto, og spesifisere domenet ditt. Hvis vi bygger et CDN på et underdomene, og hoveddomenet allerede er i bruk, så umiddelbart etter å ha lagt til sonen, ikke glem å legge til de eksisterende fungerende DNS-postene. Det neste trinnet er å lage flere A-poster for CDN-domenet / underdomenet, som hver vil bli brukt til regionen vi spesifiserte. Du kan spesifisere kontinenter eller land som regioner, underregioner er tilgjengelige for USA og Canada.

I vårt tilfelle vil CDN bli hevet på et underdomene cdn.sayt.in. Ved å legge til en sone sayt.in, opprett den første A-posten for underdomenet og pek hele Nord-Amerika til serveren i Chicago:

Bygge og konfigurere CDN
La oss gjenta handlingen for andre regioner, og husk å opprette én oppføring for standardregionene. Her er hva som skjer til slutt:

Bygge og konfigurere CDN

Den siste standardoppføringen i skjermbildet betyr at alle uspesifiserte regioner (og disse er Europa, Afrika, satellittinternettbrukere osv.) vil bli sendt til serveren i Frankfurt.

Dette fullfører det grunnleggende DNS-oppsettet. Det gjenstår å gå til domeneregistratorens nettsted og erstatte de nåværende domene-NS-ene med de som er utstedt av ClouDNS. Og mens NS-ene vil bli oppdatert, vil vi klargjøre serverne.

Installasjon av SSL-sertifikater

Vårt CDN vil fungere over HTTPS, så hvis du allerede har SSL-sertifikater for et domene eller underdomene, last dem opp til alle servere, for eksempel til katalogen /etc/ssl/dittdomene/

Hvis det ikke er noen sertifikater, kan du få et gratis fra Let's Encrypt. Perfekt for dette ACME Shellscript. Klienten er praktisk og enkel å sette opp, og viktigst av alt, den lar deg validere et domene/underdomene med DNS via ClouDNS API.

Vi vil installere acme.sh på bare én av serverne - European 199.247.18.199, hvorfra sertifikater vil bli kopiert til alle de andre. For å installere, kjør:

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

Under installasjonen av scriptet vil det bli opprettet en CRON-jobb for ytterligere fornyelse av sertifikater uten vår deltagelse.

Når du utsteder et sertifikat, vil domenet bli kontrollert ved hjelp av DNS ved hjelp av API, så i den personlige ClouDNS-kontoen i Reseller API-menyen må du opprette en ny bruker-API og angi et passord for den. Den resulterende auth-ID-en med et passord vil bli skrevet i filen ~/.acme.sh/dnsapi/dns_cloudns.sh (ikke å forveksle med fil dns_clouddns.sh). Her er linjene som må ikke kommenteres og redigeres:

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

Nå vil vi be om et SSL-sertifikat for cdn.sayt.in

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

I alternativene, for fremtiden, har vi spesifisert en kommando for automatisk å laste nettserverkonfigurasjonen på nytt etter hver fornyelse av sertifikatets gyldighetsperiode i fremtiden.

Hele prosessen med å få et sertifikat kan ta opptil 2 minutter, ikke avbryt den. Hvis det oppstår en domenevalideringsfeil, prøv å kjøre kommandoen på nytt. På slutten vil vi se hvor sertifikatene er lastet opp:

Bygge og konfigurere CDN

Husk disse banene, de må spesifiseres når du kopierer sertifikatet til andre servere, samt i webserverinnstillingene. Vi tar ikke hensyn til feilen med å laste inn Nginx-konfigurasjoner på nytt - den vil ikke være på en fullt konfigurert server når du oppdaterer sertifikater.

Alt vi har igjen for SSL er å kopiere det mottatte sertifikatet til to andre servere mens vi opprettholder banen til filene. La oss lage de samme katalogene på hver av dem og lage en kopi:

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/

For å oppdatere sertifikater regelmessig, opprett en daglig CRON-jobb på begge serverne med kommandoen:

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

I dette tilfellet må tilgang til den eksterne kildeserveren konfigureres med nøkkel, dvs. uten å angi passord. Ikke glem å gjøre det.

Installere og konfigurere Nginx

For å levere statisk innhold, vil vi bruke Nginx konfigurert som en caching proxy-server. Oppdater pakkelistene og installer den på alle tre serverne:

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

I stedet for standard bruker vi konfigurasjonen fra spoileren nedenfor:
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;
    }
  }
}

Rediger i konfigurasjonen:

  • maks_størrelse — størrelsen på hurtigbufferen, som ikke overskrider tilgjengelig diskplass
  • inaktiv - Lagringstid for hurtigbufrede data som ingen fikk tilgang til
  • ssl_certificate и ssl_certificate_key — stier til SSL-sertifikat og nøkkelfiler
  • proxy_cache_valid - lagringstid for hurtigbufrede data
  • proxy_pass — Adressen til den opprinnelige serveren som CDN vil be om filer for caching fra. I vårt eksempel, dette sayt.in

Som du kan se, er alt enkelt. Det kan bare oppstå vanskeligheter med å stille inn hurtigbuffertiden på grunn av likheten mellom direktivene inaktiv и proxy_cache_valid. La oss analysere dem med vårt eksempel. Her er hva som skjer når inaktiv=7d и proxy_cache_valid 90d:

  • hvis forespørselen ikke gjentas innen 7 dager, vil dataene bli slettet fra cachen etter denne perioden
  • hvis forespørselen gjentas minst en gang hver 7. dag, vil dataene i hurtigbufferen bli ansett som foreldet etter 90 dager, og Nginx vil oppdatere den med neste forespørsel, og ta den fra den opprinnelige serveren

Ferdig med å redigere nginx.conf, last inn konfigurasjonen på nytt:

root@cdn:~# service nginx reload

Vår CDN er klar. For $15/md. vi mottok tilstedeværelsespunkter på tre kontinenter og 3 TB trafikk: 1 TB på hvert sted.

Sjekker arbeidet til CDN

La oss se på pingene til vårt CDN fra forskjellige geografiske steder. Enhver ping-tjeneste vil fungere for dette.

Startpunkt
Vert
IP
Gj.sn. tid, ms

Tyskland Berlin
cdn.sayt.in
199.247.18.199
9.6

Nederland, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Frankrike Paris
cdn.sayt.in
199.247.18.199
16.3

Storbritannia, 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

Resultatene er gode. Nå skal vi plassere et testbilde i roten av hovedsiden test.jpg og sjekk nedlastingshastigheten via CDN. Det er sagt - laget. Innhold leveres raskt.

La oss skrive et lite skript i tilfelle vi ønsker å tømme hurtigbufferen på CDN-punktet.
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

For å slette hele cachen, bare kjør den, en separat fil kan renses slik:

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

I stedet for konklusjoner

Til slutt vil jeg gi noen nyttige tips for umiddelbart å tråkke over raken som gjorde vondt i hodet på den tiden:

  • For å øke feiltoleransen til CDN, anbefales det å konfigurere DNS Failover, som hjelper til med å raskt endre A-posten i tilfelle serverbrudd. Dette gjøres i kontrollpanelets DNS-poster for domenet.
  • Nettsteder med bred geografisk dekning krever uten tvil et stort antall CDN-er, men la oss ikke være fanatiske. Mest sannsynlig vil brukeren ikke merke noen signifikant forskjell sammenlignet med et betalt CDN hvis du plasserer servere på 6-7 steder: Europa, Nord-Amerika (øst), Nord-Amerika (vest), Singapore, Australia, Hong Kong eller Japan
  • Noen ganger tillater ikke hostere bruk av leide servere for CDN-formål. Derfor, hvis du plutselig bestemmer deg for å distribuere et innholdsleveringsnettverk som en tjeneste, ikke glem å lese reglene til en bestemt vertsleverandør på forhånd
  • Utforske undervannskart for kommunikasjonå representere hvordan kontinentene henger sammen og ta hensyn til dette når du bygger et innholdsleveringsnettverk
  • Prøv å sjekke pinger fra forskjellige steder til serverne dine. På denne måten kan du se regionene nærmest CDN-punktene og konfigurere GeoDNS mer korrekt
  • Avhengig av oppgavene vil det være nyttig å finjustere Nginx for spesifikke bufringskrav og ta hensyn til belastningen på serveren. Artiklene om Nginx cache hjalp meg mye med dette - her og akselerasjon av arbeid under tung belastning: her и her

Kilde: www.habr.com