ProHoster > وبلاگ > اداره > ساخت و پیکربندی CDN شما

ساخت و پیکربندی CDN شما

شبکه‌های تحویل محتوا (CDN) در وب‌سایت‌ها و برنامه‌ها عمدتاً برای سرعت بخشیدن به بارگذاری عناصر استاتیک استفاده می‌شوند. این به دلیل ذخیره فایل ها در سرورهای CDN واقع در مناطق جغرافیایی مختلف اتفاق می افتد. با درخواست داده از طریق CDN، کاربر آن را از نزدیکترین سرور دریافت می کند.

اصل عملکرد و عملکرد همه شبکه های تحویل محتوا تقریباً یکسان است. سرور CDN پس از دریافت درخواست دانلود یک فایل، یک بار آن را از سرور اصلی می گیرد و در اختیار کاربر قرار می دهد و در عین حال آن را برای مدت زمان مشخصی کش می کند. تمام درخواست های بعدی از حافظه پنهان پاسخ داده می شود. همه CDN ها گزینه هایی برای پیش بارگیری فایل ها، پاک کردن حافظه پنهان، تنظیم تاریخ انقضا و موارد دیگر دارند.

این اتفاق می افتد که به هر دلیلی باید شبکه تحویل محتوای خود را سازماندهی کنید و سپس - اجازه دهید دستورالعمل های مونتاژ دوچرخه بعدی به ما کمک کند.

ساخت و پیکربندی CDN شما
منبع: وکتور اینفوگرافیک توسط pikisuperstar - www.freepik.com

زمانی که به CDN خود نیاز دارید

مواردی را در نظر بگیرید که اجرای CDN خود منطقی است:

  • زمانی که میل به صرفه جویی در پول و هزینه های جاری وجود دارد، حتی در هنگام استفاده از CDN های ارزان قیمت مانند BunnyCDN به چند صد دلار در ماه می رسد
  • اگر بخواهیم یک کش دائمی یا یک کش بدون سرور و کانال همسایه داشته باشیم
  • خدمات CDN در منطقه مورد نیاز شما نقاط حضور ندارند
  • هر گونه تنظیمات ویژه تحویل محتوا مورد نیاز است
  • ما می خواهیم با نزدیک تر کردن سرور تولید به کاربران، تحویل محتوای پویا را تسریع کنیم
  • این نگرانی وجود دارد که یک سرویس CDN شخص ثالث ممکن است به طور غیرقانونی اطلاعات مربوط به رفتار کاربر را جمع آوری یا استفاده کند (سلام سرویس های غیر منطبق با GDPR) یا درگیر سایر فعالیت های غیرقانونی شود.

در بیشتر موارد دیگر، استفاده از راه حل های آماده موجود مناسب تر است.

برای شروع به چه چیزی نیاز دارید

اگر سیستم خودمختار (AS) خود را داشته باشید، فوق العاده است. با آن می توانید همان IP را به چندین سرور اختصاص دهید و طبق این دستورالعمل در سطح شبکه، کاربران را به نزدیکترین آنها هدایت کنید. شایان ذکر است که حتی با بلوک آدرس /24 نیز می توان یک شبکه تحویل محتوا ساخت. برخی از ارائه دهندگان سرور به شما این امکان را می دهند که برای استفاده در همه مناطقی که در دسترس آنها است، اعلامیه ایجاد کنید.

اگر شما مالک خوشبخت بلوکی از آدرس های IP نیستید، برای اجرای یک CDN ساده به موارد زیر نیاز دارید:

  • نام دامنه یا ساب دامنه
  • حداقل دو سرور در مناطق مختلف. سرور می تواند اختصاصی یا مجازی باشد
  • ابزار geoDNS. با استفاده از آن، کاربر با آدرس دادن به دامنه، به نزدیکترین سرور هدایت می شود

ثبت دامنه و سفارش سرور

با ثبت دامنه، همه چیز ساده است - ما در هر منطقه با هر ثبت کننده ثبت نام می کنیم. شما همچنین می توانید از یک زیر دامنه برای CDN استفاده کنید، به عنوان مثال چیزی شبیه به cdn.domainname.com. در واقع، در مثال خود، ما دقیقاً این کار را انجام خواهیم داد.

در مورد سفارش سرورها، آنها باید در مناطق و کشورهایی که مخاطبان کاربر شما در آن قرار دارند، اجاره شوند. اگر پروژه بین قاره ای است، انتخاب ارائه دهندگان میزبانی که سرورها را به طور همزمان در سراسر جهان ارائه می دهند، راحت است. مثال ها: OVH, اجاره وب и 100 ترابایت - برای سرورهای اختصاصی، ولتر и DigitalOcean — برای ابر مجازی*.

برای CDN خصوصی خود، ما 3 سرور مجازی در قاره های مختلف سفارش خواهیم داد. در ولتر روی سرور برای 5 دلار در ماه خواهیم گرفت 25GB SSD مکان ها و 1 ترابایت ترافیک. هنگام نصب، آخرین Debian را انتخاب کنید. سرورهای ما:

ساخت و پیکربندی CDN شما فرانکفورت, IP: 199.247.18.199

ساخت و پیکربندی CDN شما شیکاگو, IP: 149.28.121.123

ساخت و پیکربندی CDN شما سنگاپور, IP: 157.230.240.216

* Vultr و DigitalOcean به کاربرانی که بلافاصله پس از افزودن روش پرداخت از طریق پیوندهای موجود در مقاله ثبت نام می کنند، 100 دلار اعتبار قول می دهند. نویسنده از این بابت تعارف کوچکی هم دریافت می کند که اکنون برای او بسیار قابل توجه است. لطفا درک کنید

راه اندازی geoDNS

برای اینکه کاربر هنگام دسترسی به دامنه یا زیر دامنه CDN به سرور مورد نظر (نزدیک ترین) هدایت شود، به یک سرور DNS با عملکرد geoDNS نیاز داریم.

اصل و عملکرد geoDNS به شرح زیر است:

  1. IP کلاینت ارسال کننده درخواست DNS یا IP سرور DNS بازگشتی که هنگام پردازش درخواست مشتری استفاده می شود را مشخص می کند. چنین سرورهای بازگشتی معمولاً DNS ارائه دهندگان هستند.
  2. IP مشتری کشور یا منطقه او را می شناسد. برای این کار از پایگاه داده های GeoIP استفاده می شود که امروزه تعداد زیادی از آنها وجود دارد. خوب وجود دارد گزینه های رایگان.
  3. بسته به مکان مشتری، آدرس IP نزدیکترین سرور CDN را به او می دهد.

سرور DNS با عملکرد geoDNS می تواند باشد خودت جمع کن، اما بهتر است از راه حل های آماده با شبکه ای از سرورهای DNS در سراسر جهان و آنیکاست از جعبه:

  • CloudDNS از 9.95 دلار در ماه، تعرفه GeoDNS، به طور پیش فرض یک DNS Failover وجود دارد
  • زیلوره از 25 دلار در ماه، DNS Failover فعال شد
  • مسیر آمازون 53 از 35 دلار در ماه برای خالص 50 میلیون درخواست جغرافیایی. DNS Failover جداگانه صورتحساب می شود
  • DNS ساخته شده آسان از 125 دلار در ماه، 10 خطای DNS وجود دارد
  • CloudFlare را، ویژگی "Geo Steering" در طرح های Enterprise موجود است

هنگام سفارش geoDNS باید به تعداد درخواست های درج شده در تعرفه توجه کنید و در نظر داشته باشید که تعداد واقعی درخواست ها به دامنه می تواند چندین برابر انتظارات را بیشتر کند. میلیون ها عنکبوت، اسکنر، ارسال کننده هرزنامه و دیگر ارواح شیطانی به طور خستگی ناپذیر کار می کنند.

تقریباً تمام خدمات DNS شامل یک سرویس ضروری برای ساخت CDN - DNS Failover است. با کمک آن می توانید نظارت بر عملکرد سرورهای خود را تنظیم کنید و در صورت عدم وجود علائم حیات، به طور خودکار آدرس یک سرور غیرفعال را با یک نسخه پشتیبان در پاسخ های DNS جایگزین کنید.

برای ساخت CDN خود، از آن استفاده خواهیم کرد CloudDNS، تعرفه GeoDNS.

بیایید یک منطقه DNS جدید به حساب شخصی شما اضافه کنیم و دامنه خود را مشخص کنید. اگر در حال ساختن یک CDN بر روی یک زیر دامنه هستیم و دامنه اصلی از قبل در حال استفاده است، بلافاصله پس از افزودن منطقه، فراموش نکنید که رکوردهای DNS موجود را اضافه کنید. مرحله بعدی ایجاد چندین رکورد A برای دامنه / زیر دامنه CDN است که هر کدام در منطقه ای که ما مشخص کرده ایم اعمال می شود. شما می توانید قاره ها یا کشورها را به عنوان مناطق مشخص کنید، مناطق فرعی برای ایالات متحده آمریکا و کانادا در دسترس هستند.

در مورد ما، CDN در یک زیر دامنه افزایش می یابد cdn.sayt.in. با اضافه کردن یک منطقه sayt.in، اولین رکورد A را برای زیر دامنه ایجاد کنید و تمام آمریکای شمالی را به سرور در شیکاگو هدایت کنید:

ساخت و پیکربندی CDN شما
بیایید عمل را برای مناطق دیگر تکرار کنیم، به یاد داشته باشیم که یک ورودی برای مناطق پیش فرض ایجاد کنیم. این چیزی است که در پایان اتفاق می افتد:

ساخت و پیکربندی CDN شما

آخرین ورودی پیش فرض در تصویر به این معنی است که تمام مناطق نامشخص (و اینها اروپا، آفریقا، کاربران اینترنت ماهواره ای و غیره) به سرور در فرانکفورت ارسال می شوند.

این راه اندازی اولیه DNS را تکمیل می کند. باقی مانده است که به وب سایت ثبت کننده دامنه بروید و NS های دامنه فعلی را با موارد صادر شده توسط ClouDNS جایگزین کنید. و در حالی که NS ها به روز می شوند، سرورها را آماده می کنیم.

نصب گواهینامه های SSL

CDN ما روی HTTPS کار می‌کند، بنابراین اگر قبلاً گواهی‌های SSL برای یک دامنه یا زیر دامنه دارید، آنها را در همه سرورها، به عنوان مثال، در دایرکتوری آپلود کنید. /etc/ssl/yourdomain/

اگر گواهی وجود ندارد، می‌توانید یک گواهی رایگان از Let's Encrypt دریافت کنید. ایده آل برای این اسکریپت ACME Shell. سرویس گیرنده راحت و آسان برای راه اندازی است، و مهمتر از همه، به شما اجازه می دهد تا یک دامنه/زیر دامنه را توسط DNS از طریق ClouDNS API تأیید کنید.

ما acme.sh را فقط بر روی یکی از سرورها نصب خواهیم کرد - European 199.247.18.199، که از آن گواهینامه ها برای سایر سرورها کپی می شود. برای نصب، اجرا کنید:

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

در طول نصب اسکریپت، یک کار CRON برای تمدید بیشتر گواهینامه ها بدون مشارکت ما ایجاد می شود.

هنگام صدور گواهی، دامنه با استفاده از DNS با استفاده از API بررسی می شود، بنابراین در حساب شخصی ClouDNS در منوی Reseller API، باید یک API کاربر جدید ایجاد کنید و یک رمز عبور برای آن تعیین کنید. auth-id حاصل با رمز عبور در فایل نوشته می شود ~/.acme.sh/dnsapi/dns_cloudns.sh (با فایل اشتباه گرفته نشود dns_clouddns.sh). در اینجا خطوطی وجود دارد که باید بدون نظر و ویرایش شوند:

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

اکنون ما یک گواهی SSL برای آن درخواست خواهیم کرد cdn.sayt.in

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

در گزینه‌ها، برای آینده، دستوری را برای بارگیری خودکار پیکربندی وب سرور پس از هر تجدید دوره اعتبار گواهی در آینده مشخص کرده‌ایم.

کل فرآیند دریافت گواهی می تواند تا 2 دقیقه طول بکشد، آن را قطع نکنید. اگر خطای اعتبارسنجی دامنه رخ داد، دوباره دستور را اجرا کنید. در پایان خواهیم دید که گواهینامه ها در کجا آپلود شده اند:

ساخت و پیکربندی CDN شما

این مسیرها را به خاطر بسپارید، هنگام کپی کردن گواهینامه در سرورهای دیگر و همچنین در تنظیمات وب سرور باید مشخص شوند. ما به خطای بارگیری مجدد پیکربندی های Nginx توجه نمی کنیم - هنگام به روز رسانی گواهی ها روی یک سرور کاملاً پیکربندی شده نخواهد بود.

تنها چیزی که برای SSL باقی می‌ماند این است که گواهی دریافتی را در دو سرور دیگر کپی کنیم و در عین حال مسیر فایل‌ها را حفظ کنیم. بیایید دایرکتوری های یکسانی را روی هر یک از آنها ایجاد کنیم و یک کپی ایجاد کنیم:

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/

برای به‌روزرسانی مرتب گواهی‌ها، یک کار روزانه CRON در هر دو سرور با دستور زیر ایجاد کنید:

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

در این حالت، دسترسی به سرور منبع راه دور باید پیکربندی شود توسط کلید، یعنی بدون وارد کردن رمز عبور انجام آن را فراموش نکنید.

نصب و پیکربندی Nginx

برای ارائه محتوای ثابت، از Nginx پیکربندی شده به عنوان سرور پروکسی کش استفاده خواهیم کرد. لیست های بسته را به روز کنید و آن را در هر سه سرور نصب کنید:

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

به جای پیش فرض، از پیکربندی اسپویلر زیر استفاده می کنیم:
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;
    }
  }
}

ویرایش در تنظیمات:

  • حداکثر_اندازه - اندازه حافظه نهان، از فضای موجود دیسک تجاوز نمی کند
  • غیر فعال - زمان ذخیره سازی داده های کش که هیچ کس به آن دسترسی نداشته است
  • ssl_certificate и ssl_certificate_key - مسیرهای گواهی SSL و فایل های کلیدی
  • proxy_cache_valid - زمان ذخیره سازی داده های کش
  • پروکسی_گذر - آدرس سرور اصلی که CDN از آن فایل‌ها را برای ذخیره‌سازی درخواست می‌کند. در مثال ما، این sayt.in

همانطور که می بینید، همه چیز ساده است. مشکل تنها می تواند در تنظیم زمان کش به دلیل شباهت دستورالعمل ها ایجاد شود غیر فعال и proxy_cache_valid. بیایید با مثال خود آنها را تحلیل کنیم. در اینجا چه اتفاقی می افتد زمانی که غیر فعال = 7d и proxy_cache_valid 90d:

  • اگر درخواست طی 7 روز تکرار نشود، پس از این مدت داده ها از حافظه پنهان حذف می شوند
  • اگر درخواست حداقل هر 7 روز یک بار تکرار شود، داده های کش پس از 90 روز منسوخ تلقی می شوند و Nginx با درخواست بعدی، آن را از سرور اصلی به روز می کند.

ویرایش به پایان رسید nginx.conf، پیکربندی را دوباره بارگیری کنید:

root@cdn:~# service nginx reload

CDN ما آماده است. برای 15 دلار در ماه. ما نقاط حضور در سه قاره و 3 ترابایت ترافیک دریافت کردیم: 1 ترابایت در هر مکان.

بررسی کار CDN

بیایید به پینگ های CDN خود از مکان های جغرافیایی مختلف نگاه کنیم. هر سرویس پینگ برای این کار کار می کند.

نقطه پرتاب
میزبان
IP
میانگین زمان، ms

آلمان برلین
cdn.sayt.in
199.247.18.199
9.6

هلند ، آمستردام
cdn.sayt.in
199.247.18.199
10.1

فرانسه پاریس
cdn.sayt.in
199.247.18.199
16.3

انگلستان، لندن
cdn.sayt.in
199.247.18.199
14.9

کانادا، تورنتو
cdn.sayt.in
149.28.121.123
16.2

ایالات متحده آمریکا، سانفرانسیسکو
cdn.sayt.in
149.28.121.123
52.7

ایالات متحده آمریکا، دالاس
cdn.sayt.in
149.28.121.123
23.1

ایالات متحده آمریکا، شیکاگو
cdn.sayt.in
149.28.121.123
2.6

ایالات متحده آمریکا، نیویورک
cdn.sayt.in
149.28.121.123
19.8

سنگاپور
cdn.sayt.in
157.230.240.216
1.7

ژاپن توکیو
cdn.sayt.in
157.230.240.216
74.8

استرالیا، سیدنی
cdn.sayt.in
157.230.240.216
95.9

نتایج خوب است. اکنون یک تصویر آزمایشی را در ریشه سایت اصلی قرار می دهیم test.jpg و سرعت دانلود آن را از طریق CDN بررسی کنید. گفته می شود - ساخته شده. محتوا به سرعت ارائه می شود.

بیایید یک اسکریپت کوچک بنویسیم در صورتی که بخواهیم حافظه پنهان را در نقطه 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

برای حذف کل کش، کافی است آن را اجرا کنید، یک فایل جداگانه می تواند به این صورت پاک شود:

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

به جای نتیجه گیری

در نهایت، می‌خواهم نکات مفیدی را ارائه دهم تا فوراً از چنگک‌هایی که در آن زمان سرم را به درد می‌آورد رد شوم:

  • برای افزایش تحمل خطا در CDN، توصیه می شود DNS Failover را پیکربندی کنید، که به تغییر سریع رکورد A در صورت خرابی سرور کمک می کند. این کار در رکوردهای DNS کنترل پنل دامنه انجام می شود.
  • سایت هایی با پوشش جغرافیایی گسترده بدون شک به تعداد زیادی CDN نیاز دارند، اما بیایید متعصب نباشیم. اگر سرورها را در 6-7 مکان قرار دهید: اروپا، آمریکای شمالی (شرق)، آمریکای شمالی (غرب)، سنگاپور، استرالیا، هنگ کنگ یا ژاپن، به احتمال زیاد کاربر تفاوت قابل توجهی را در مقایسه با CDN پولی متوجه نخواهد شد.
  • گاهی اوقات میزبان ها اجازه استفاده از سرورهای اجاره ای را برای اهداف CDN نمی دهند. بنابراین، اگر به طور ناگهانی تصمیم به استقرار یک شبکه تحویل محتوا به عنوان یک سرویس گرفتید، فراموش نکنید که قوانین یک ارائه دهنده میزبانی خاص را از قبل بخوانید.
  • کاوش کنید نقشه ارتباطات زیر آببرای نشان دادن نحوه اتصال قاره ها و در نظر گرفتن این موضوع هنگام ایجاد یک شبکه تحویل محتوا
  • سعی کنید بررسی کنید پینگ از جاهای مختلف به سرورهای شما به این ترتیب می توانید نزدیک ترین مناطق به نقاط CDN را ببینید و GeoDNS را به درستی پیکربندی کنید
  • بسته به وظایف، تنظیم دقیق Nginx برای نیازهای کش خاص و در نظر گرفتن بار روی سرور مفید خواهد بود. مقالات مربوط به کش Nginx در این امر به من کمک زیادی کرد - اینجا و تسریع کار تحت بارهای سنگین: اینجا и اینجا

منبع: www.habr.com