ProHoster > Blog > Pentadbiran > Membina dan mengkonfigurasi CDN anda

Membina dan mengkonfigurasi CDN anda

Rangkaian Penghantaran Kandungan (CDN) digunakan dalam laman web dan aplikasi terutamanya untuk mempercepatkan pemuatan elemen statik. Ini berlaku disebabkan caching fail pada pelayan CDN yang terletak di kawasan geografi yang berbeza. Dengan meminta data melalui CDN, pengguna menerimanya daripada pelayan terdekat.

Prinsip operasi dan kefungsian semua rangkaian penghantaran kandungan adalah lebih kurang sama. Setelah menerima permintaan untuk memuat turun fail, pelayan CDN mengambilnya sekali daripada pelayan asal dan memberikannya kepada pengguna, pada masa yang sama menyimpannya dalam cache untuk tempoh masa tertentu. Semua permintaan seterusnya dijawab daripada cache. Semua CDN mempunyai pilihan untuk pramuat fail, mengosongkan cache, menetapkan tarikh tamat tempoh dan banyak lagi.

Ia berlaku bahawa, untuk satu sebab atau yang lain, anda perlu mengatur rangkaian penghantaran kandungan anda sendiri, dan kemudian - biarkan arahan untuk memasang basikal seterusnya membantu kami.

Membina dan mengkonfigurasi CDN anda
Sumber: Vektor infografik dicipta oleh pikisuperstar - www.freepik.com

Apabila anda memerlukan CDN anda sendiri

Pertimbangkan kes di mana menjalankan CDN anda sendiri masuk akal:

  • apabila ada keinginan untuk menjimatkan wang, dan menjalankan kos walaupun menggunakan CDN yang murah seperti BunnyCDN berjumlah beberapa ratus ringgit sebulan
  • jika kita ingin mendapatkan cache kekal atau cache tanpa pelayan dan saluran jiran
  • Perkhidmatan CDN tidak mempunyai tempat kehadiran di rantau yang anda perlukan
  • sebarang tetapan penghantaran kandungan khas diperlukan
  • kami ingin mempercepatkan penyampaian kandungan dinamik dengan meletakkan pelayan pengeluaran lebih dekat dengan pengguna
  • terdapat kebimbangan bahawa perkhidmatan CDN pihak ketiga mungkin mengumpul atau menggunakan maklumat secara haram tentang tingkah laku pengguna (hello perkhidmatan yang tidak mematuhi GDPR) atau terlibat dalam aktiviti haram yang lain

Dalam kebanyakan kes lain, adalah lebih sesuai untuk menggunakan penyelesaian sedia ada.

Apa yang anda perlukan untuk mulakan

Sangat bagus jika anda mempunyai Sistem Autonomi (AS) anda sendiri. Dengan itu, anda boleh menetapkan IP yang sama kepada beberapa pelayan dan mengikut arahan ini di peringkat rangkaian, arahkan pengguna ke yang terdekat. Perlu dikatakan bahawa walaupun dengan blok alamat /24, adalah mungkin untuk membina rangkaian penghantaran kandungan. Sesetengah pembekal pelayan membenarkan anda membuat pengumuman untuk digunakan di semua wilayah yang tersedia untuk mereka.

Jika anda bukan pemilik senang blok alamat IP, maka untuk menjalankan CDN mudah anda perlukan:

  • nama domain atau subdomain
  • sekurang-kurangnya dua pelayan di kawasan yang berbeza. Pelayan boleh sama ada berdedikasi atau maya
  • alat geoDNS. Dengan itu, pengguna, setelah menangani domain, akan diarahkan ke pelayan terdekat

Daftar domain dan pesan pelayan

Dengan pendaftaran domain, semuanya mudah - kami mendaftar di mana-mana zon dengan mana-mana pendaftar. Anda juga boleh menggunakan subdomain untuk CDN, contohnya seperti cdn.domainname.com. Sebenarnya, dalam contoh kami, kami akan melakukan perkara itu.

Bagi memesan pelayan, ia harus disewa di wilayah dan negara tempat khalayak pengguna anda berada. Jika projek itu adalah antara benua, maka adalah mudah untuk memilih penyedia pengehosan yang menawarkan pelayan di seluruh dunia sekaligus. Contoh: OVH, web pajakan ΠΈ 100TB - untuk pelayan khusus, Vultr ΠΈ DigitalOcean β€” untuk awan maya*.

Untuk CDN peribadi kami, kami akan memesan 3 pelayan maya di benua yang berbeza. Pada Vultr pada pelayan untuk $5/bln kita akan dapat 25GB SSD tempat dan 1TB trafik. Semasa memasang, pilih Debian terkini. Pelayan kami:

Membina dan mengkonfigurasi CDN anda Frankfurt, ip: 199.247.18.199

Membina dan mengkonfigurasi CDN anda Chicago, ip: 149.28.121.123

Membina dan mengkonfigurasi CDN anda Singapura, ip: 157.230.240.216

* Vultr dan DigitalOcean menjanjikan kredit $100 kepada pengguna yang mendaftar melalui pautan dalam artikel serta-merta selepas menambah kaedah pembayaran. Penulis juga menerima sedikit pujian daripada ini, yang sangat bermakna baginya sekarang. Harap faham.

Menyediakan geoDNS

Untuk membolehkan pengguna diarahkan ke pelayan yang dikehendaki (paling dekat) apabila mengakses domain atau subdomain CDN, kami memerlukan pelayan DNS dengan fungsi geoDNS.

Prinsip dan operasi geoDNS adalah seperti berikut:

  1. Menentukan IP klien yang menghantar permintaan DNS, atau IP pelayan DNS rekursif yang digunakan semasa memproses permintaan klien. Pelayan rekursif seperti itu biasanya DNS-s pembekal.
  2. IP pelanggan mengiktiraf negara atau wilayahnya. Untuk ini, pangkalan data GeoIP digunakan, yang mana terdapat banyak sekali hari ini. Ada yang bagus pilihan percuma.
  3. Bergantung pada lokasi pelanggan, berikan dia alamat IP pelayan CDN terdekat.

Pelayan DNS dengan fungsi geoDNS boleh berhimpun sendiri, tetapi lebih baik menggunakan penyelesaian siap pakai dengan rangkaian pelayan DNS di seluruh dunia dan Anycast Dari kotak itu:

  • CloudDNS daripada $9.95/bln, Tarif GeoDNS, secara lalai terdapat satu DNS Failover
  • Zilore daripada $25/bln, DNS Failover didayakan
  • Amazon Route 53 daripada $35/bln untuk permintaan geo 50 juta bersih. DNS Failover dibilkan secara berasingan
  • DNS Dipermudahkan daripada $125/bln, terdapat 10 DNS Failovers
  • CloudFlare, ciri "Geo Steering" tersedia dalam rancangan Perusahaan

Apabila memesan geoDNS, anda harus memberi perhatian kepada bilangan permintaan yang disertakan dalam tarif dan perlu diingat bahawa bilangan sebenar permintaan ke domain boleh melebihi jangkaan beberapa kali. Berjuta-juta labah-labah, pengimbas, spammer dan roh jahat lain bekerja tanpa jemu.

Hampir semua perkhidmatan DNS termasuk perkhidmatan yang sangat diperlukan untuk membina CDN - DNS Failover. Dengan bantuannya, anda boleh menyediakan pemantauan operasi pelayan anda dan, jika tiada tanda-tanda kehidupan, secara automatik menggantikan alamat pelayan yang tidak berfungsi dengan satu sandaran dalam respons DNS.

Untuk membina CDN kami, kami akan menggunakan CloudDNS, tarif GeoDNS.

Mari tambah zon DNS baharu dalam akaun peribadi anda, dengan menyatakan domain anda. Jika kita sedang membina CDN pada subdomain, dan domain utama sudah digunakan, maka sejurus selepas menambah zon, jangan lupa untuk menambah rekod DNS yang berfungsi sedia ada. Langkah seterusnya ialah mencipta beberapa rekod A untuk domain / subdomain CDN, setiap satunya akan digunakan pada wilayah yang kami tentukan. Anda boleh menentukan benua atau negara sebagai wilayah, sub-rantau tersedia untuk AS dan Kanada.

Dalam kes kami, CDN akan dinaikkan pada subdomain cdn.sayt.in. Dengan menambah zon sayt.in, buat rekod A pertama untuk subdomain dan halakan semua Amerika Utara ke pelayan di Chicago:

Membina dan mengkonfigurasi CDN anda
Mari ulangi tindakan untuk wilayah lain, mengingati untuk membuat satu entri untuk wilayah lalai. Inilah yang berlaku pada akhirnya:

Membina dan mengkonfigurasi CDN anda

Entri lalai terakhir dalam tangkapan skrin bermakna semua wilayah yang tidak ditentukan (dan ini adalah Eropah, Afrika, pengguna Internet satelit, dll.) akan dihantar ke pelayan di Frankfurt.

Ini melengkapkan persediaan DNS asas. Ia kekal untuk pergi ke tapak web pendaftar domain dan menggantikan NS domain semasa dengan yang dikeluarkan oleh ClouDNS. Dan sementara NS akan dikemas kini, kami akan menyediakan pelayan.

Pemasangan sijil SSL

CDN kami akan berfungsi melalui HTTPS, jadi jika anda sudah mempunyai sijil SSL untuk domain atau subdomain, muat naiknya ke semua pelayan, contohnya, ke direktori /etc/ssl/yourdomain/

Jika tiada sijil, anda boleh mendapatkan sijil percuma daripada Let's Encrypt. Sempurna untuk ini ACME Shellscript. Pelanggan adalah mudah dan mudah untuk disediakan, dan yang paling penting, ia membolehkan anda mengesahkan domain/subdomain oleh DNS melalui API CloudDNS.

Kami akan memasang acme.sh pada hanya satu pelayan - Eropah 199.247.18.199, dari mana sijil akan disalin kepada semua yang lain. Untuk memasang, jalankan:

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

Semasa pemasangan skrip, kerja CRON akan dibuat untuk memperbaharui sijil selanjutnya tanpa penyertaan kami.

Apabila mengeluarkan sijil, domain akan disemak menggunakan DNS menggunakan API, jadi dalam akaun peribadi ClouDNS dalam menu API Penjual Semula, anda perlu membuat API pengguna baharu dan menetapkan kata laluan untuknya. Pengesahan yang terhasil dengan kata laluan akan ditulis dalam fail ~/.acme.sh/dnsapi/dns_cloudns.sh (jangan dikelirukan dengan fail dns_clouddns.sh). Berikut ialah baris yang perlu dinyahkomen dan diedit:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<ΠΏΠ°Ρ€ΠΎΠ»ΡŒ>"

Sekarang kami akan meminta sijil SSL untuk cdn.sayt.in

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

Dalam pilihan, untuk masa hadapan, kami telah menetapkan arahan untuk memuat semula konfigurasi pelayan web secara automatik selepas setiap pembaharuan tempoh sah sijil pada masa hadapan.

Keseluruhan proses mendapatkan sijil boleh mengambil masa sehingga 2 minit, jangan ganggunya. Jika ralat pengesahan domain berlaku, cuba jalankan arahan itu sekali lagi. Pada akhirnya kita akan melihat di mana sijil telah dimuat naik:

Membina dan mengkonfigurasi CDN anda

Ingat laluan ini, ia perlu ditentukan apabila menyalin sijil ke pelayan lain, serta dalam tetapan pelayan web. Kami tidak memberi perhatian kepada ralat memuat semula konfigurasi Nginx - ia tidak akan berada pada pelayan yang dikonfigurasikan sepenuhnya semasa mengemas kini sijil.

Apa yang kami tinggalkan untuk SSL ialah menyalin sijil yang diterima ke dua pelayan lain sambil mengekalkan laluan ke fail. Mari buat direktori yang sama pada setiap satu daripadanya dan buat salinan:

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/

Untuk mengemas kini sijil dengan kerap, buat kerja CRON harian pada kedua-dua pelayan dengan arahan:

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

Dalam kes ini, akses kepada pelayan sumber jauh mesti dikonfigurasikan dengan kunci, iaitu tanpa memasukkan kata laluan. Jangan lupa buat.

Memasang dan mengkonfigurasi Nginx

Untuk menyampaikan kandungan statik, kami akan menggunakan Nginx yang dikonfigurasikan sebagai pelayan proksi caching. Kemas kini senarai pakej dan pasangkannya pada ketiga-tiga pelayan:

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

Daripada lalai, kami menggunakan konfigurasi daripada spoiler di bawah:
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;
    }
  }
}

Edit dalam konfigurasi:

  • max_size β€” saiz cache, tidak melebihi ruang cakera yang tersedia
  • aktif - masa penyimpanan data cache yang tidak diakses oleh sesiapa
  • ssl_sijil ΠΈ ssl_certificate_key β€” laluan ke sijil SSL dan fail utama
  • proxy_cache_valid - masa penyimpanan data cache
  • laluan proksi β€” alamat pelayan asal dari mana CDN akan meminta fail untuk caching. Dalam contoh kami, ini sayt.in

Seperti yang anda lihat, semuanya mudah. Kesukaran hanya boleh timbul dalam menetapkan masa caching kerana persamaan arahan aktif ΠΈ proxy_cache_valid. Mari analisa mereka dengan contoh kami. Inilah yang berlaku apabila tidak aktif=7d ΠΈ proxy_cache_valid 90h:

  • jika permintaan tidak diulang dalam masa 7 hari, maka data akan dipadamkan daripada cache selepas tempoh ini
  • jika permintaan diulang sekurang-kurangnya sekali setiap 7 hari, maka data dalam cache akan dianggap usang selepas 90 hari dan Nginx akan mengemas kininya dengan permintaan seterusnya, mengambilnya dari pelayan asal

Selesai mengedit nginx.conf, muat semula konfigurasi:

root@cdn:~# service nginx reload

CDN kami sudah sedia. Untuk $15/bln. kami menerima titik kehadiran di tiga benua dan 3 TB trafik: 1 TB di setiap lokasi.

Menyemak kerja CDN

Mari lihat ping ke CDN kami dari lokasi geografi yang berbeza. Sebarang perkhidmatan ping akan berfungsi untuk ini.

Titik pelancaran
Tuan rumah
IP
Purata masa, ms

Jerman Berlin
cdn.sayt.in
199.247.18.199
9.6

Belanda, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Perancis Paris
cdn.sayt.in
199.247.18.199
16.3

United Kingdom, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

Amerika Syarikat, San Francisco
cdn.sayt.in
149.28.121.123
52.7

Amerika Syarikat, Dallas
cdn.sayt.in
149.28.121.123
23.1

Amerika Syarikat, Chicago
cdn.sayt.in
149.28.121.123
2.6

Amerika Syarikat, New York
cdn.sayt.in
149.28.121.123
19.8

Singapura
cdn.sayt.in
157.230.240.216
1.7

Jepun Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australia, Sydney
cdn.sayt.in
157.230.240.216
95.9

Hasilnya bagus. Sekarang kami akan meletakkan imej ujian di akar tapak utama test.jpg dan semak kelajuan muat turunnya melalui CDN. Dikatakan - dibuat. Kandungan dihantar dengan cepat.

Mari kita tulis skrip kecil sekiranya kita ingin mengosongkan cache pada titik CDN.
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

Untuk memadam keseluruhan cache, jalankan sahaja, fail berasingan boleh dibersihkan seperti ini:

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

Daripada kesimpulan

Akhir sekali, saya ingin memberikan beberapa petua berguna untuk segera melangkah ke atas garu yang membuat kepala saya sakit pada masa itu:

  • Untuk meningkatkan toleransi kesalahan CDN, disyorkan untuk mengkonfigurasi DNS Failover, yang membantu menukar rekod A dengan cepat sekiranya berlaku kerosakan pelayan. Ini dilakukan dalam rekod DNS panel kawalan domain.
  • Tapak dengan liputan geografi yang luas sudah pasti memerlukan sejumlah besar CDN, tetapi jangan fanatik. Kemungkinan besar pengguna tidak akan melihat perbezaan yang ketara berbanding CDN berbayar jika anda meletakkan pelayan di 6-7 lokasi: Eropah, Amerika Utara (timur), Amerika Utara (barat), Singapura, Australia, Hong Kong atau Jepun
  • Kadangkala hoster tidak membenarkan penggunaan pelayan yang disewa untuk tujuan CDN. Oleh itu, jika anda tiba-tiba memutuskan untuk menggunakan rangkaian penghantaran kandungan sebagai perkhidmatan, jangan lupa untuk membaca peraturan penyedia pengehosan tertentu terlebih dahulu
  • Meneroka peta komunikasi bawah airuntuk mewakili cara benua disambungkan dan mengambil kira perkara ini apabila membina rangkaian penghantaran kandungan
  • Cuba semak ping dari tempat yang berbeza kepada pelayan anda. Dengan cara ini anda boleh melihat kawasan yang paling hampir dengan titik CDN dan mengkonfigurasi GeoDNS dengan lebih betul
  • Bergantung pada tugasan, adalah berguna untuk memperhalusi Nginx untuk keperluan caching tertentu dan mengambil kira beban pada pelayan. Artikel tentang cache Nginx banyak membantu saya dalam hal ini - di sini dan pecutan kerja di bawah beban berat: di sini ΠΈ di sini

Sumber: www.habr.com