🥇Budowanie i konfigurowanie CDN

Sieci dostarczania treści (CDN) są wykorzystywane w witrynach internetowych i aplikacjach przede wszystkim w celu przyspieszenia ładowania elementów statycznych. Dzieje się tak z powodu buforowania plików na serwerach CDN zlokalizowanych w różnych regionach geograficznych. Żądając danych poprzez CDN, użytkownik otrzymuje je z najbliższego serwera.

Zasada działania i funkcjonalność wszystkich sieci dostarczania treści jest w przybliżeniu taka sama. Po otrzymaniu żądania pobrania pliku serwer CDN pobiera go jednorazowo z serwera pierwotnego i przekazuje użytkownikowi, jednocześnie buforując go na określony czas. Odpowiedzi na wszystkie kolejne żądania pochodzą z pamięci podręcznej. Wszystkie sieci CDN oferują opcje wstępnego ładowania plików, czyszczenia pamięci podręcznej, ustawiania daty wygaśnięcia i nie tylko.

Zdarza się, że z jakiegoś powodu trzeba zorganizować własną sieć dostarczania treści, a potem – niech pomoże nam instrukcja montażu kolejnego roweru.

Źródło: Wektor infograficzny stworzony przez pikisuperstar - www.freepik.com

Kiedy potrzebujesz własnego CDN

Rozważ przypadki, w których prowadzenie własnego CDN ma sens:

gdy istnieje chęć zaoszczędzenia pieniędzy i kosztów bieżących, nawet przy korzystaniu z niedrogich sieci CDN, takich jak BunnyCDN wynoszą kilkaset dolarów miesięcznie
jeśli chcemy uzyskać stałą pamięć podręczną lub pamięć podręczną bez sąsiadów serwera i kanału
Usługi CDN nie mają punktów obecności w regionie, którego potrzebujesz
wymagane są wszelkie specjalne ustawienia dostarczania treści
chcemy przyspieszyć dostarczanie treści dynamicznych, umieszczając serwer produkcyjny bliżej użytkowników
istnieje obawa, że zewnętrzna usługa CDN może nielegalnie gromadzić lub wykorzystywać informacje o zachowaniach użytkowników (witaj usługi niezgodne z RODO) lub angażować się w inne nielegalne działania

W większości pozostałych przypadków bardziej wskazane jest skorzystanie z istniejących, gotowych rozwiązań.

Czego potrzebujesz, aby zacząć

To wspaniale, jeśli masz swój własny System Autonomiczny (AS). Dzięki niemu możesz przypisać ten sam adres IP do kilku serwerów i zgodnie z tą instrukcją na poziomie sieci kieruj użytkowników do najbliższej. Warto dodać, że nawet przy bloku adresu /24 możliwe jest zbudowanie sieci dostarczania treści. Niektórzy dostawcy serwerów umożliwiają opublikowanie ogłoszenia do użytku we wszystkich dostępnych dla nich regionach.

Jeśli nie jesteś szczęśliwym posiadaczem bloku adresów IP, to do uruchomienia prostego CDN będziesz potrzebować:

nazwa domeny lub subdomena
co najmniej dwa serwery w różnych regionach. Serwer może być dedykowany lub wirtualny
narzędzie geoDNS. Dzięki niemu użytkownik po zaadresowaniu domeny zostanie przekierowany do najbliższego serwera

Zarejestruj domenę i zamów serwery

W przypadku rejestracji domeny wszystko jest proste - rejestrujemy się w dowolnej strefie u dowolnego rejestratora. Możesz także użyć subdomeny dla CDN, na przykład czegoś takiego cdn.nazwadomeny.com. Właściwie w naszym przykładzie właśnie to zrobimy.

Jeśli chodzi o zamawianie serwerów, należy je wynajmować w regionach i krajach, w których znajdują się Twoi odbiorcy. Jeśli projekt ma charakter międzykontynentalny, wygodnie jest wybrać dostawców hostingu, którzy oferują serwery na całym świecie jednocześnie. Przykłady: OVH, Dzierżawa sieci и 100 TB - dla serwerów dedykowanych, Vultr и DigitalOcean — dla chmury wirtualnej*.

Do naszego prywatnego CDN zamówimy 3 serwery wirtualne na różnych kontynentach. Na Vultr na serwerze dla 5 USD/mies dostaniemy 25GB SSD miejsca i 1 TB ruchu. Podczas instalacji wybierz najnowszego Debiana. Nasze serwery:

Frankfurt, ip: 199.247.18.199

Chicago, ip: 149.28.121.123

Singapur, ip: 157.230.240.216

* Vultr i DigitalOcean obiecują kredyt w wysokości 100 USD użytkownikom, którzy zarejestrują się za pomocą linków zawartych w artykule natychmiast po dodaniu metody płatności. Autor otrzymuje też z tego powodu mały komplement, co jest dla niego teraz bardzo istotne. Prosimy o zrozumienie.

Konfiguracja geoDNS

Aby użytkownik podczas uzyskiwania dostępu do domeny lub subdomeny CDN został przekierowany na żądany (najbliższy) serwer, potrzebujemy serwera DNS z funkcją geoDNS.

Zasada i działanie geoDNS jest następująca:

Określa adres IP klienta, który wysłał żądanie DNS, lub adres IP rekurencyjnego serwera DNS używanego podczas przetwarzania żądania klienta. Takie serwery rekurencyjne są zwykle serwerami DNS dostawców.
IP klienta rozpoznaje jego kraj lub region. W tym celu wykorzystywane są bazy danych GeoIP, których obecnie jest bardzo wiele. Są dobre bezpłatne opcje.
W zależności od lokalizacji klienta podaje mu adres IP najbliższego serwera CDN.

Serwer DNS z funkcją geoDNS może być zmontuj samodzielnie, ale lepiej skorzystać z gotowych rozwiązań z siecią serwerów DNS na całym świecie i Anycast z pudełka:

ChlouDNS od 9.95 USD/mies, taryfa GeoDNS, domyślnie jest jeden DNS Failover
Zilor od 25 USD/mies, Włączono przełączanie awaryjne DNS
Amazon trasy 53 od 35 USD/mies za 50 milionów żądań geograficznych netto. Opłaty za przełączanie awaryjne DNS są rozliczane osobno
Łatwe DNS od 125 USD/miesistnieje 10 przełączeń awaryjnych DNS
Cloudflare, funkcja „Geo Steering” jest dostępna w planach Enterprise

Zamawiając geoDNS należy zwrócić uwagę na ilość żądań ujętą w taryfie i mieć na uwadze, że rzeczywista ilość żądań do domeny może kilkukrotnie przekroczyć oczekiwania. Miliony pająków, skanerów, spamerów i innych złych duchów pracują niestrudzenie.

Prawie wszystkie usługi DNS obejmują usługę niezbędną do budowy CDN - DNS Failover. Za jego pomocą możesz skonfigurować monitorowanie pracy swoich serwerów i w przypadku braku oznak życia automatycznie zastąpić w odpowiedziach DNS adres niedziałającego serwera adresem zapasowym.

Aby zbudować nasz CDN, użyjemy CloudDNS, taryfa GeoDNS.

Dodajmy nową strefę DNS na Twoim koncie osobistym, podając Twoją domenę. Jeśli budujemy CDN na subdomenie, a domena główna jest już w użyciu, to od razu po dodaniu strefy nie zapomnij dodać istniejących, działających rekordów DNS. Następnym krokiem jest utworzenie kilku rekordów A dla domeny/subdomeny CDN, z których każdy zostanie zastosowany do określonego przez nas regionu. Możesz określić kontynenty lub kraje jako regiony, podregiony są dostępne dla USA i Kanady.

W naszym przypadku CDN zostanie podniesiony w subdomenie cdn.sayt.in. Dodając strefę Sayt.in, utwórz pierwszy rekord A dla subdomeny i skieruj całą Amerykę Północną na serwer w Chicago:

Powtórzmy akcję dla pozostałych regionów, pamiętając o utworzeniu jednego wpisu dla regionów domyślnych. Oto, co się dzieje na końcu:

Ostatni domyślny wpis na zrzucie ekranu oznacza, że wszystkie nieokreślone regiony (a są to Europa, Afryka, użytkownicy Internetu satelitarnego itp.) zostaną przesłane na serwer we Frankfurcie.

To kończy podstawową konfigurację DNS. Pozostaje udać się na stronę rejestratora domen i zastąpić obecne NS domen tymi wydanymi przez ClouDNS. Podczas gdy NS zostaną zaktualizowane, my przygotujemy serwery.

Instalacja certyfikatów SSL

Nasz CDN będzie działał po HTTPS, więc jeżeli posiadasz już certyfikaty SSL dla domeny lub subdomeny wgraj je na wszystkie serwery np. do katalogu /etc/ssl/twojadomena/

Jeśli nie ma żadnych certyfikatów, możesz otrzymać darmowy od Let's Encrypt. Idealny do tego Skrypt ACME. Klient jest wygodny i łatwy w konfiguracji, a co najważniejsze pozwala na walidację domeny/subdomeny przez DNS poprzez API ClouDNS.

Zainstalujemy acme.sh tylko na jednym z serwerów - europejskim 199.247.18.199, z którego certyfikaty zostaną skopiowane na wszystkie pozostałe. Aby zainstalować, uruchom:

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

Podczas instalacji skryptu zostanie utworzone zadanie CRON umożliwiające dalsze odnawianie certyfikatów bez naszego udziału.

Podczas wydawania certyfikatu domena zostanie sprawdzona za pomocą DNS za pomocą API, dlatego w koncie osobistym ClouDNS w menu Reseller API należy utworzyć nowe API użytkownika i ustawić dla niego hasło. Wynikowy identyfikator autoryzacji wraz z hasłem zostanie zapisany w pliku ~/.acme.sh/dnsapi/dns_cloudns.sh (nie mylić z plikiem dns_clouddns.sh). Oto wiersze, które należy odkomentować i edytować:

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

Teraz poprosimy o certyfikat SSL dla cdn.sayt.in

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

W opcjach na przyszłość określiliśmy polecenie automatycznego przeładowania konfiguracji serwera www po każdym odnowieniu okresu ważności certyfikatu w przyszłości.

Cały proces uzyskania certyfikatu może zająć do 2 minut, nie przerywaj go. Jeśli wystąpi błąd sprawdzania poprawności domeny, spróbuj ponownie uruchomić polecenie. Na koniec zobaczymy, gdzie zostały przesłane certyfikaty:

Zapamiętaj te ścieżki, należy je określić podczas kopiowania certyfikatu na inne serwery, a także w ustawieniach serwera WWW. Nie zwracamy uwagi na błąd przeładowania konfiguracji Nginx - nie będzie to na w pełni skonfigurowanym serwerze podczas aktualizacji certyfikatów.

Jedyne co nam pozostało w przypadku SSL to skopiowanie otrzymanego certyfikatu na dwa inne serwery z zachowaniem ścieżki do plików. Utwórzmy na każdym z nich te same katalogi i zróbmy 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/

Aby regularnie aktualizować certyfikaty, utwórz codzienne zadanie CRON na obu serwerach za pomocą polecenia:

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

W takim przypadku należy skonfigurować dostęp do zdalnego serwera źródłowego według klucza, tj. bez podawania hasła. Nie zapomnij tego zrobić.

Instalacja i konfiguracja Nginxa

Do obsługi treści statycznych użyjemy Nginx skonfigurowanego jako buforujący serwer proxy. Zaktualizuj listy pakietów i zainstaluj je na wszystkich trzech serwerach:

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

Zamiast domyślnej używamy konfiguracji ze spoilera poniżej:
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;
    }
  }
}

Edytuj w konfiguracji:

największy rozmiar — wielkość pamięci podręcznej, nieprzekraczająca dostępnego miejsca na dysku
nieaktywny - czas przechowywania danych w pamięci podręcznej, do których nikt nie miał dostępu
ssl_certificate и ssl_certificate_key — ścieżki do certyfikatu SSL i plików kluczy
proxy_cache_valid - czas przechowywania danych w pamięci podręcznej
hasło_proxy — adres pierwotnego serwera, z którego CDN będzie żądać plików do buforowania. W naszym przykładzie to Sayt.in

Jak widać, wszystko jest proste. Trudności mogą pojawić się jedynie przy ustawianiu czasu buforowania ze względu na podobieństwo dyrektyw nieaktywny и proxy_cache_valid. Przeanalizujmy je na naszym przykładzie. Oto, co się stanie, kiedy nieaktywny=7d и proxy_cache_valid 90d:

jeżeli żądanie nie zostanie powtórzone w ciągu 7 dni, to po tym okresie dane zostaną usunięte z pamięci podręcznej
jeśli żądanie będzie powtarzane przynajmniej raz na 7 dni, to dane w pamięci podręcznej po 90 dniach zostaną uznane za przestarzałe i Nginx zaktualizuje je przy kolejnym żądaniu, pobierając je z oryginalnego serwera

Zakończono edytowanie nginx.conf, załaduj ponownie konfigurację:

root@cdn:~# service nginx reload

Nasz CDN jest gotowy. Za 15 USD miesięcznie. otrzymaliśmy punkty obecności na trzech kontynentach i 3 TB ruchu: 1 TB w każdej lokalizacji.

Sprawdzanie pracy CDN

Przyjrzyjmy się pingom do naszej sieci CDN z różnych lokalizacji geograficznych. Każda usługa ping będzie działać w tym przypadku.

Punkt startowy
Gospodarz
IP
Średni czas, ms

Niemcy Berlinie
cdn.sayt.in
199.247.18.199
9.6

Holandia, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Francja Paryż
cdn.sayt.in
199.247.18.199
16.3

Wielka Brytania, Londyn
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

Stany Zjednoczone, 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, Nowy Jork
cdn.sayt.in
149.28.121.123
19.8

Singapur
cdn.sayt.in
157.230.240.216
1.7

Japonia Tokio
cdn.sayt.in
157.230.240.216
74.8

Australii, Sydney
cdn.sayt.in
157.230.240.216
95.9

Wyniki są dobre. Teraz umieścimy obraz testowy w katalogu głównym witryny głównej test.jpg i sprawdź prędkość pobierania za pośrednictwem CDN. Mówi się - gotowy. Treść jest dostarczana szybko.

Napiszmy mały skrypt na wypadek, gdybyśmy chcieli wyczyścić pamięć podręczną w punkcie CDN.
oczyścić.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

Aby usunąć całą pamięć podręczną, po prostu ją uruchom, oddzielny plik można wyczyścić w następujący sposób:

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

Zamiast wniosków

Na koniec chcę dać kilka przydatnych wskazówek, aby od razu przejść przez grabie, od których bolała mnie wówczas głowa:

Aby zwiększyć odporność CDN na awarie, zaleca się skonfigurowanie DNS Failover, które pomaga szybko zmienić rekord A w przypadku awarii serwera. Odbywa się to w panelu sterowania rekordami DNS domeny.
Witryny o szerokim zasięgu geograficznym bez wątpienia wymagają dużej liczby sieci CDN, ale nie bądźmy fanatyczni. Najprawdopodobniej użytkownik nie zauważy znaczącej różnicy w porównaniu z płatnym CDN, jeśli umieścisz serwery w 6-7 lokalizacjach: Europa, Ameryka Północna (wschód), Ameryka Północna (zachód), Singapur, Australia, Hongkong lub Japonia
Czasami hostingodawcy nie pozwalają na korzystanie z wynajmowanych serwerów do celów CDN. Dlatego jeśli nagle zdecydujesz się na wdrożenie sieci dostarczania treści jako usługi, nie zapomnij wcześniej zapoznać się z regulaminem konkretnego dostawcy usług hostingowych
Badać mapa komunikacji podwodnejaby przedstawić sposób połączenia kontynentów i uwzględnić to przy budowaniu sieci dostarczania treści
Spróbuj sprawdzić pingi z różnych miejsc do swoich serwerów. W ten sposób możesz zobaczyć regiony najbliżej punktów CDN i lepiej skonfigurować GeoDNS
W zależności od zadań przydatne będzie dostrojenie Nginxa pod konkretne wymagania dotyczące buforowania i uwzględnienia obciążenia serwera. Artykuły o pamięci podręcznej Nginx bardzo mi w tym pomogły - tutaj i przyspieszenie pracy pod dużymi obciążeniami: tutaj и tutaj

Źródło: www.habr.com

Budowanie i konfigurowanie sieci CDN