ProHoster > blog > administrasi > Membangun dan mengonfigurasi CDN Anda

Membangun dan mengonfigurasi CDN Anda

Jaringan Pengiriman Konten (CDN) digunakan di situs web dan aplikasi terutama untuk mempercepat pemuatan elemen statis. Hal ini terjadi karena file disimpan dalam cache di server CDN yang berlokasi di wilayah geografis berbeda. Dengan meminta data melalui CDN, pengguna menerimanya dari server terdekat.

Prinsip pengoperasian dan fungsionalitas semua jaringan pengiriman konten kurang lebih sama. Setelah menerima permintaan untuk mengunduh file, server CDN mengambilnya satu kali dari server asli dan memberikannya kepada pengguna, sekaligus menyimpannya dalam cache untuk jangka waktu tertentu. Semua permintaan berikutnya dijawab dari cache. Semua CDN memiliki opsi untuk memuat file terlebih dahulu, menghapus cache, mengatur tanggal kedaluwarsa, dan banyak lagi.

Kebetulan, karena satu dan lain alasan, Anda perlu mengatur jaringan pengiriman konten Anda sendiri, dan kemudian - biarkan instruksi untuk merakit sepeda berikutnya dapat membantu kami.

Membangun dan mengonfigurasi CDN Anda
Sumber: Vektor infografis dibuat oleh pikisuperstar - www.freepik.com

Saat Anda membutuhkan CDN Anda sendiri

Pertimbangkan kasus-kasus di mana menjalankan CDN Anda sendiri masuk akal:

  • ketika ada keinginan untuk menghemat uang, dan biaya operasional bahkan ketika menggunakan CDN murah seperti KelinciCDN berjumlah beberapa ratus dolar sebulan
  • jika kita ingin mendapatkan cache permanen atau cache tanpa tetangga server dan saluran
  • Layanan CDN tidak memiliki titik kehadiran di wilayah yang Anda butuhkan
  • diperlukan pengaturan pengiriman konten khusus
  • kami ingin mempercepat pengiriman konten dinamis dengan menempatkan server produksi lebih dekat dengan pengguna
  • ada kekhawatiran bahwa layanan CDN pihak ketiga mungkin secara ilegal mengumpulkan atau menggunakan informasi tentang perilaku pengguna (halo layanan yang tidak mematuhi GDPR) atau terlibat dalam aktivitas ilegal lainnya

Dalam kebanyakan kasus lain, lebih tepat menggunakan solusi siap pakai yang sudah ada.

Apa yang Anda perlukan untuk memulai

Alangkah baiknya jika Anda memiliki Sistem Otonomi (AS) sendiri. Dengan itu, Anda dapat menetapkan IP yang sama ke beberapa server dan sesuai dengan instruksi ini di tingkat jaringan, arahkan pengguna ke jaringan terdekat. Perlu dikatakan bahwa bahkan dengan blok alamat /24, dimungkinkan untuk membangun jaringan pengiriman konten. Beberapa penyedia server mengizinkan Anda membuat pengumuman untuk digunakan di semua wilayah yang tersedia bagi mereka.

Jika Anda bukan pemilik blok alamat IP yang bahagia, maka untuk menjalankan CDN sederhana Anda memerlukan:

  • nama domain atau subdomain
  • setidaknya dua server di wilayah berbeda. Server dapat berupa dedicated atau virtual
  • alat geoDNS. Dengan itu, pengguna yang telah mengalamatkan domain tersebut akan diarahkan ke server terdekat

Daftarkan domain dan pesan server

Dengan pendaftaran domain, semuanya sederhana - kami mendaftar di zona mana pun dengan registrar mana pun. Anda juga dapat menggunakan subdomain untuk CDN, misalnya seperti cdn.namadomain.com. Sebenarnya, dalam contoh kita, kita akan melakukan hal itu.

Sedangkan untuk pemesanan server, sebaiknya disewa di wilayah dan negara tempat audiens pengguna Anda berada. Jika proyeknya antarbenua, maka akan lebih mudah untuk memilih penyedia hosting yang menawarkan server di seluruh dunia sekaligus. Contoh: OVH, web sewa и 100 TB - untuk server khusus, Vultr и DigitalOcean — untuk awan virtual*.

Untuk CDN pribadi kami, kami akan memesan 3 server virtual di benua berbeda. Pada Vultr di server untuk $5/bln kita akan mendapatkan 25GB SSD tempat dan lalu lintas 1TB. Saat menginstal, pilih Debian terbaru. Server kami:

Membangun dan mengonfigurasi CDN Anda Frankfurt,ip: 199.247.18.199

Membangun dan mengonfigurasi CDN Anda Chicago,ip: 149.28.121.123

Membangun dan mengonfigurasi CDN Anda Singapura,ip: 157.230.240.216

*Vultr dan DigitalOcean menjanjikan kredit $100 kepada pengguna yang mendaftar melalui tautan di artikel segera setelah menambahkan metode pembayaran. Penulis juga menerima sedikit pujian dari hal ini, yang sangat berarti baginya saat ini. Mohon pengertiannya.

Menyiapkan geoDNS

Agar user dapat diarahkan ke server yang diinginkan (terdekat) saat mengakses suatu domain atau subdomain CDN, maka diperlukan server DNS dengan fungsi geoDNS.

Prinsip dan cara kerja geoDNS adalah sebagai berikut:

  1. Menentukan IP klien yang mengirimkan permintaan DNS, atau IP server DNS rekursif yang digunakan saat memproses permintaan klien. Server rekursif seperti itu biasanya merupakan penyedia DNS.
  2. IP klien mengenali negara atau wilayahnya. Untuk ini, database GeoIP digunakan, yang saat ini jumlahnya sangat banyak. Ada yang bagus opsi gratis.
  3. Tergantung pada lokasi klien, berikan dia alamat IP server CDN terdekat.

Server DNS dengan fungsi geoDNS bisa merakit sendiri, tetapi lebih baik menggunakan solusi yang sudah jadi dengan jaringan server DNS di seluruh dunia dan siaran apa saja dari kotak:

  • CloudDNS dari $9.95/bln, Tarif GeoDNS, secara default ada satu DNS Failover
  • Zilore dari $25/bln, Kegagalan DNS diaktifkan
  • Amazon Route 53 dari $35/bln untuk permintaan geografis bersih 50 juta. Failover DNS ditagih secara terpisah
  • DNS Menjadi Mudah dari $125/bln, ada 10 Kegagalan DNS
  • cloudflare, fitur "Geo Steering" tersedia di paket Perusahaan

Saat memesan geoDNS, Anda harus memperhatikan jumlah permintaan yang termasuk dalam tarif dan perlu diingat bahwa jumlah sebenarnya permintaan ke domain dapat melebihi ekspektasi beberapa kali lipat. Jutaan laba-laba, pemindai, spammer, dan roh jahat lainnya bekerja tanpa lelah.

Hampir semua layanan DNS menyertakan layanan yang sangat diperlukan untuk membangun CDN - DNS Failover. Dengan bantuannya, Anda dapat mengatur pemantauan pengoperasian server Anda dan, jika tidak ada tanda-tanda kehidupan, secara otomatis mengganti alamat server yang tidak berfungsi dengan alamat cadangan dalam respons DNS.

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

Mari tambahkan zona DNS baru di akun pribadi Anda, tentukan domain Anda. Jika kita sedang membangun CDN pada subdomain, dan domain utama sudah digunakan, maka segera setelah menambahkan zona, jangan lupa untuk menambahkan data DNS yang berfungsi. Langkah selanjutnya adalah membuat beberapa A-record untuk domain/subdomain CDN yang masing-masing akan diterapkan pada region yang kita tentukan. Anda dapat menentukan benua atau negara sebagai wilayah, sub-wilayah tersedia untuk Amerika Serikat dan Kanada.

Dalam kasus kami, CDN akan dimunculkan pada subdomain cdn.sayt.in. Dengan menambahkan zona katakan di, buat A-record pertama untuk subdomain dan arahkan seluruh Amerika Utara ke server di Chicago:

Membangun dan mengonfigurasi CDN Anda
Mari kita ulangi tindakan untuk wilayah lain, ingat untuk membuat satu entri untuk wilayah default. Inilah yang terjadi pada akhirnya:

Membangun dan mengonfigurasi CDN Anda

Entri default terakhir di tangkapan layar berarti bahwa semua wilayah yang tidak ditentukan (yaitu Eropa, Afrika, pengguna Internet satelit, dll.) akan dikirim ke server di Frankfurt.

Ini menyelesaikan pengaturan DNS dasar. Tetap mengunjungi situs web pendaftar domain dan mengganti NS domain saat ini dengan yang dikeluarkan oleh ClouDNS. Dan sementara NS akan diperbarui, kami akan menyiapkan servernya.

Pemasangan sertifikat SSL

CDN kami akan bekerja melalui HTTPS, jadi jika Anda sudah memiliki sertifikat SSL untuk domain atau subdomain, unggah ke semua server, misalnya ke direktori /etc/ssl/domainanda/

Jika tidak ada sertifikat, Anda bisa mendapatkan yang gratis dari Let's Encrypt. Sempurna untuk ini Skrip Shell ACME. Kliennya nyaman dan mudah diatur, dan yang terpenting, klien ini memungkinkan Anda memvalidasi domain/subdomain dengan DNS melalui ClouDNS API.

Kami akan menginstal acme.sh hanya di salah satu server - Eropa 199.247.18.199, dari mana sertifikat akan disalin ke server lainnya. Untuk menginstal, jalankan:

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

Selama instalasi skrip, pekerjaan CRON akan dibuat untuk pembaruan sertifikat lebih lanjut tanpa partisipasi kami.

Saat menerbitkan sertifikat, domain akan diperiksa menggunakan DNS menggunakan API, jadi di akun pribadi ClouDNS di menu Reseller API, Anda perlu membuat API pengguna baru dan mengatur kata sandi untuk itu. ID autentikasi yang dihasilkan dengan kata sandi akan ditulis dalam file ~/.acme.sh/dnsapi/dns_cloudns.sh (jangan bingung dengan file dns_clouddns.sh). Berikut adalah baris yang perlu dihapus komentarnya dan diedit:

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

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

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

Dalam opsi, untuk masa depan, kami telah menentukan perintah untuk memuat ulang konfigurasi server web secara otomatis setelah setiap pembaruan masa berlaku sertifikat di masa mendatang.

Seluruh proses mendapatkan sertifikat bisa memakan waktu hingga 2 menit, jangan diganggu. Jika terjadi kesalahan validasi domain, coba jalankan kembali perintah tersebut. Pada akhirnya kita akan melihat di mana sertifikat telah diunggah:

Membangun dan mengonfigurasi CDN Anda

Ingat jalur ini, jalur tersebut harus ditentukan saat menyalin sertifikat ke server lain, serta dalam pengaturan server web. Kami tidak memperhatikan kesalahan saat memuat ulang konfigurasi Nginx - kesalahan tersebut tidak akan ada di server yang dikonfigurasi sepenuhnya saat memperbarui sertifikat.

Yang tersisa untuk SSL adalah menyalin sertifikat yang diterima ke dua server lain sambil mempertahankan jalur ke file. Mari buat direktori yang sama pada masing-masing direktori dan buat salinannya:

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/

Untuk memperbarui sertifikat secara rutin, buat pekerjaan CRON harian di kedua server dengan perintah:

scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Dalam hal ini, akses ke server sumber jarak jauh harus dikonfigurasi dengan kunci, yaitu. tanpa memasukkan kata sandi. Jangan lupa melakukannya.

Menginstal dan mengkonfigurasi Nginx

Untuk menyajikan konten statis, kami akan menggunakan Nginx yang dikonfigurasi sebagai server proxy caching. Perbarui daftar paket dan instal di ketiga server:

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

Daripada default, kami menggunakan konfigurasi dari spoiler di bawah ini:
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 di konfigurasi:

  • ukuran_maks — ukuran cache, tidak melebihi ruang disk yang tersedia
  • non-aktif - waktu penyimpanan data cache yang tidak diakses oleh siapa pun
  • ssl_certificate и ssl_certificate_key — jalur ke sertifikat SSL dan file kunci
  • proxy_cache_valid - waktu penyimpanan data cache
  • proxy_pass — alamat server asli tempat CDN akan meminta file untuk di-cache. Dalam contoh kita, ini katakan di

Seperti yang Anda lihat, semuanya sederhana. Kesulitan hanya dapat muncul dalam mengatur waktu caching karena kesamaan arahan non-aktif и proxy_cache_valid. Mari kita menganalisisnya dengan contoh kita. Inilah yang terjadi ketika tidak aktif=7d и proxy_cache_valid 90d:

  • jika permintaan tidak diulangi dalam waktu 7 hari, maka data akan dihapus dari cache setelah jangka waktu tersebut
  • jika permintaan diulang setidaknya setiap 7 hari sekali, maka data dalam cache akan dianggap usang setelah 90 hari dan Nginx akan memperbaruinya dengan permintaan berikutnya, mengambilnya dari server asli

Selesai untuk diedit nginx.conf, muat ulang konfigurasi:

root@cdn:~# service nginx reload

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

Memeriksa pekerjaan CDN

Mari kita lihat ping ke CDN kita dari lokasi geografis yang berbeda. Layanan ping apa pun bisa digunakan untuk ini.

Titik peluncuran
Tuan rumah
IP
Waktu rata-rata, Bu

Jerman Berlin
cdn.sayt.in
199.247.18.199
9.6

Belanda, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Prancis Paris
cdn.sayt.in
199.247.18.199
16.3

Inggris Raya, London
cdn.sayt.in
199.247.18.199
14.9

Kanada, Toronto
cdn.sayt.in
149.28.121.123
16.2

AS, San Francisco
cdn.sayt.in
149.28.121.123
52.7

AS, Dallas
cdn.sayt.in
149.28.121.123
23.1

AS, Chicago
cdn.sayt.in
149.28.121.123
2.6

AS, New York
cdn.sayt.in
149.28.121.123
19.8

Singapura
cdn.sayt.in
157.230.240.216
1.7

Jepang Tokyo
cdn.sayt.in
157.230.240.216
74.8

Australia, Sidney
cdn.sayt.in
157.230.240.216
95.9

Hasilnya bagus. Sekarang kita akan menempatkan gambar uji di root situs utama test.jpg dan periksa kecepatan unduhnya melalui CDN. Dikatakan - dibuat. Konten dikirimkan dengan cepat.

Mari kita tulis skrip kecil jika kita ingin menghapus cache pada titik CDN.
pembersihan.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 menghapus seluruh cache, jalankan saja, file terpisah dapat dibersihkan seperti ini:

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

Alih-alih kesimpulan

Terakhir, saya ingin memberikan beberapa tips bermanfaat agar dapat segera melangkahi penggaruk yang membuat kepala saya sakit saat itu:

  • Untuk meningkatkan toleransi kesalahan CDN, disarankan untuk mengonfigurasi DNS Failover, yang membantu mengubah catatan A dengan cepat jika terjadi kerusakan server. Hal ini dilakukan di panel kontrol catatan DNS domain.
  • Situs dengan cakupan geografis yang luas tentu memerlukan CDN dalam jumlah besar, namun jangan terlalu fanatik. Kemungkinan besar pengguna tidak akan melihat perbedaan yang signifikan dibandingkan CDN berbayar jika Anda menempatkan server di 6-7 lokasi: Eropa, Amerika Utara (timur), Amerika Utara (barat), Singapura, Australia, Hong Kong atau Jepang
  • Terkadang hoster tidak mengizinkan penggunaan server sewaan untuk tujuan CDN. Oleh karena itu, jika Anda tiba-tiba memutuskan untuk menggunakan jaringan pengiriman konten sebagai layanan, jangan lupa untuk membaca aturan dari penyedia hosting tertentu terlebih dahulu.
  • Mengeksplorasi peta komunikasi bawah airuntuk mewakili bagaimana benua terhubung dan mempertimbangkan hal ini ketika membangun jaringan pengiriman konten
  • Cobalah untuk memeriksa ping dari tempat yang berbeda ke server Anda. Dengan cara ini Anda dapat melihat wilayah yang paling dekat dengan titik CDN dan mengonfigurasi GeoDNS dengan lebih tepat
  • Tergantung pada tugasnya, akan berguna untuk menyempurnakan Nginx untuk kebutuhan caching tertentu dan dengan mempertimbangkan beban di server. Artikel tentang cache Nginx banyak membantu saya dalam hal ini - di sini dan percepatan pekerjaan pada beban berat: di sini и di sini

Sumber: www.habr.com