ساخت CDN شخصی روی سرور اختصاصی و مجازی ( آموزش گام‌به‌گام)

ساخت CDN شخصی روی سرور

آنچه در مقاله می‌خوانید

از شبکه‌های توزیع محتوا یا همان CDN (مخفف عبارت Content Delivery Networks) برای افزایش سرعت بارگذاری عناصر استاتیک در سایت‌ها و اپلیکیشن‌ها استفاده می‌شود. برای اینکار، فایل‌ها در سرور‌های CDN که در مناطق مختلف جهان قرار دارند کش می‌شوند و کاربر با درخواست دادن از طریق CDN می‌تواند این فایل‌ها را از نزدیک‌ترین سرور موجود دریافت کند. عملکرد و اصول اساسی در پشت تمام شبکه‌های تحویل محتوا یکسان است: پس از اینکه CDN درخواست یک فایل را دریافت کرد، سرور CDN آن فایل را از سرور اصلی می‌گیرد و به کاربر می‌فرستد و سپس، یک کپی از فایل را برای یک دوره زمانی کش می‌کند. درخواست‌های بعدی برای داده‌ها با استفاده از حافظه پنهان مدیریت می‌شوند. همه شبکه‌های تحویل محتوا دارای گزینه‌هایی برای پیش-بارگیری (pre-loading) فایل‌ها، پاکسازی حافظه پنهان، زمان نگهداری حافظه پنهان و بسیاری موارد دیگر هستند. گاهی‌اوقات، بنا‌به دلایل مختلف لازم است که CDN شخصی خود را بسازیم. اگر شما هم قصد ساخت cdn شخصی با راحت‌ترین و بهترین روش ممکن را دارید، ادامه این مقاله را از دست ندهید.

چه زمانی به ساخت CDN شخصی نیاز داریم؟

چه زمانی به ساخت CDN شخصی نیاز داریم

در ادامه، موقعیت‌هایی که در آن‌ها به ساخت CDN شخصی نیاز دارید را بررسی می‌کنیم:

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

اگر مشمول شرایط بالا نیستید، بهتر است از یک cdn رایگان از پیش آماده‌شده مانند CDN کلودفلر استفاده کنید. اگر برای ساخت CND مردد هستید، برای آشنایی بهتر با شبکه‌های تحویل محتوا، از شما دعوت می‌کنیم مقاله cdn چیست را مطالعه کنید. در این مقاله، ما به تعریف این شبکه‌ها و مزایای آن‌ها پرداختیم. پس از اینکه با این ابزار به خوبی آشنا شدید، می‌توانید تصمیم بگیرید که آیا استفاده از آن برای کسب‌و‌کارتان لازم است یا خیر.

ساخت CDN شخصی

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

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

برای ساخت CDN شخصی، مراحل زیر را دنبال کنید:

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

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

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

در‌صورتی که یک پروژه بین‌قاره‌ای یا بین‌المللی دارید، انتخاب از بین ارا‌ئه‌دهندگانی که میزبانی سرور در سراسر جهان را ارائه می‌دهند مانند PQ.hosting و DigitalOcean (برای سرور‌های ابری)، یا OVH و Leaseweb (برای سرور‌های اختصاصی) گزینه بهتری است.

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

2.  پیکربندی geoDNS

برای مطمئن‌شدن از اینکه کلاینت‌ها پس از ارسال درخواست به دامنه یا زیر‌دامنه، به سمت سرور‌های مناسب (که در اینجا نزدیک‌ترین سرور‌ها هستند) هدایت می‌شوند، به یک سرور DNS با عملکرد geoDNS نیاز دارید.

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

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

شما می‌توانید خودتان یک سرور DNS با عملکرد geoDNS را بسازید، اما توصیه می‌کنیم به جای اینکار، از گزینه‌های آماده‌ای استفاده کنید که دارای سرور‌های مختلف در سراسر جهان هستند و همچنین، از گزینه خارج از جعبه Anycast نیز استفاده می‌کنند. Anycast یک روش آدرس‌دهی و مسیریابی شبکه است که توسط آن، یک آدرس IP واحد توسط دستگاه‌ها (یا همان سرورها) در مکان‌های جغرافیایی مختلف به اشتراک گذاشته می‌شود. با انجام این‌کار، سرعت بارگذاری وب‌سایت یا اپلیکیشن شما بسیار زیاد خواهد بود.

در زمان سفارش geoDNS باید به مواردی مانند تعداد درخواست‌های موجود در پکیج توجه کنید و یادتان باشد که ممکن است تعداد درخواست‌های واقعی شما بسیار بیشتر از چیزی که انتظار دارید باشد. به‌عنوان مثال، میلیون‌ها وب‌ کراولر یا خزنده وب (Web Crawler)، اسکنر‌ها، هرزنامه‌نویس‌ها و سایر برنامه‌های مخرب وجود دارند که در همین لحظه در حال کار کردن هستند و می‌توانند سیل عظیمی از درخواست‌ها را ارسال کنند.

تقریبا تمام سرویس‌های DNS دارای ویژگی ماشه DNS Failover هستند که در‌صورت خرابی نام دامنه فعال می‌شود. با استفاده از این ویژگی، می‌توانید نظارت بر فعالیت را طوری پیکربندی کنید که در‌صورت از کار افتادن یک سرور، کلاینت‌ها به‌صورت خودکار به سرور‌های فعال دیگر هدایت شوند.

در این آموزش، می‌خواهیم برای ساخت cdn شخصی خود از ClouDNS و پکیج GeoDNS استفاده کنیم.

در ‌بخش profile، یک منطقه DNS جدید اضافه کرده و نام دامنه را مشخص کنید. در‌صورتی که از زیر‌دامنه استفاده می‌کنید و دامنه اصلی در حال استفاده است، یادتان باشد که بلافاصله پس از اضافه کردن منطقه (zone)، رکورد‌های DNS موجود را هم اضافه کنید.

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

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

هدایت کلاینت‌ها به یک منطقه دیگر

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

تکرار فرایند هدایت کلاینت‌های به یک منطقه دیگر برای رکوردهای باقی مانده

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

در اینجا، پیکربندی اولیه DNS را به پایان رساندیم. حالا تنها کاری که باید انجام دهید این است که به وب‌سایت هدایت‌کننده بروید و نیم‌سرور (nameserver) فعلی را با مواردی که توسط ClouDNS ارائه شده‌اند، جایگزین کنید. ما این سرور‌ها را همچنان که در حال بروزرسانی هستند، تنظیم می‌کنیم.

3.  نصب گواهینامه‌های SSL

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

در‌صورتی که هیچ گواهینامه‌ای ندارید، می‌تواند از Let’s Encrypt یک گواهینامه رایگان تهیه کنید. اسکریپت ACME Shell نیز یک گزینه عالی است که با داشتن یک کلاینت کاربر‌پسند، به شما اجازه می‌دهد تا اعتبار دامنه یا زیردامنه را از طریق DNS و با استفاده از API توسط ClouDNS اجرا کنید.

در این آموزش، ما acme.sh را فقط بر روی یک سرور (سرور اروپایی با آدرس 199.247.18.199) نصب می‌کنیم و در ادامه، گواهینامه از آن به سایر سرور‌ها کپی می‌شود. برای نصب این گواهینامه، دستور زیر را اجرا کنید:

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

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

برای تایید دامنه پس از صدور گواهی، باید با استفاده از API و از طریق DNS اقدام کنید. برای انجام این‌کار، در پروفایل ClouDNS و در قسمت Reseller API، یک کاربر API جدید ایجاد کرده و یک رمز عبور برای آن مشخص کنید. در ادامه، auth-id ایجاد‌شده را به همراه رمز عبور در فایل زیر وارد کنید:

~/.acme.sh/dnsapi/dns_cloudns.sh

در این قسمت، باید برخی از خطوط را ویرایش کنید:

CLOUDNS_AUTH_ID=<auth-id>

CLOUDNS_AUTH_PASSWORD="<password>"

حالا با اجرای دستور زیر، اجازه درخواست صدور گواهی SSL برای cdn.sayt.in را می‌دهید:

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

در دستور بالا، پارامتر‌هایی برای راه‌اندازی مجدد پیکربندی خودکار پس از هر بار تمدید گواهینامه را قرار دادیم.

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

فرایند دریافت گواهینامه SSL

مسیر‌های بالا را ذخیره کنید. این مسیر‌ها در زمان کپی کردن گواهینامه‌ها در سرور‌های دیگر و تنظیمات سرور باید مشخص شوند. در ادامه، خطای بارگیری مجدد 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 در هر دو سرور ایجاد کنید. برای انجام این کار، دستور زیر را به CRON jobs اضافه کنید:

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

یادتان باشد که برای اتصال ریموت به سرور اصلی، به دسترسی با کلید بدون وارد کردن رمز عبور نیاز دارید. بنابراین، این مورد را هم باید ایجاد کنید.

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

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

root@cdn: ~# apt update

root@cdn: ~# apt install nginx

در اینجا به جای دستورات پیش‌فرض، از پیکربندی زیر استفاده می‌کنیم:

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; }   } }

در دستورات بالا، گزینه‌های زیر را داریم که با ویرایش‌شان، می‌توانیم تنظیمات دلخواه خود را اضافه کنیم:

  • max_size: با مشخص کردن این مورد، اندازه حافظه پنهان از فضای موجود دیسک تجاوز نمی‌کند.
  • Inactive: زمان نگهداری برای داده‌های کش درخواست‌نشده را مشخص می‌کند.
  • ssl_certificate و ssl_certificate_key: مسیرهایی به گواهی SSL و کلید ایجاد می‌کند.
  • proxy_cache_valid: زمان نگهداری برای داده‌های کش‌شده را مشخص می‌کند.
  • proxy_pass: آدرس‌دهی سرور مبدا که CDN از آن داده‌ها را برای ذخیره‌سازی درخواست می‌کند را مشخص می‌کند. برای مثال ما در اینجا از sayt.in استفاده کردیم.

مشاهده می‌کنید که این‌کار چقدر راحت است، تنها مشکلی که وجود دارد پیکربندی زمان نگهداری است؛ زیرا بین پارامتر‌های inactive و proxy_cache_valid شباهت‌هایی مشاهده می‌شود. در این مثال، ما از inactive=7d و proxy_cache_valid=90d استفاده کردیم. این به این معنی است که:

  • در‌صورتی که درخواست ظرف ۱۰ روز تکرار نشود، داده‌ها از حافظه پنهان حذف خواهند شد.
  • در‌صورتی که درخواستی در طول ۷ روز حتی ۱ بار تکرار شود، کش پس از ۹۰ روز منسوخ در‌نظر گرفته می‌شود و با درخواست بعدی، Nginx آن را از سرور اصلی بروزرسانی می‌کند.

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

root@cdn: ~# service nginx reload

حالا CDN ما قابل‌استفاده است!

 

بررسی CDN ساخته‌شده

بیایید نگاهی به پینگ از مکان‌های مختلف به CND ساخته‌شده بیاندازیم:

سرور پینگ هاست IP متوسط زمان به میلی‌ثانیه
Germany, Berlin cdn.sayt.in 192.247.18.199 9.6
Netherlands, Amsterdam cdn.sayt.in 192.247.18.199 10.1
France, Paris cdn.sayt.in 192.247.18.199 16.3
UK, London cdn.sayt.in 192.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

نتایج بدست‌آمده خوب است. حالا می‌خواهیم یک تصویر آزمایشی با نام test.jpg را روی سرور اصلی قرار داده و بررسی کنیم که با چه سرعتی از طریق CDN بارگذاری می‌شود. برای اینکار، می‌توانیم از سرویس Ping Admin استفاده کنیم.

در‌صورتی که نیاز به پاک کردن حافظه پنهان در یک نقطه CDN داشته باشیم، می‌توانیم کد زیر را اجرا کنیم:

#!/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 اجرا کنید.

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

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

  • هزینه‌ها و دوام CDN ساخته‌شده را در‌نظر بگیرید. در بسیاری از موارد، خرید یک CDN از پیش ساخته‌شده بسیار به‌صرفه‌تر از ساخت آن است؛ زیرا این نوع CDN‌ معمولا پایدار‌تر است و کیفیت بهتری هم دارد.
  • برای بهبود تحمل خطای CDN، بهتر است یک DNS Failover را راه اندازی کنید تا در‌صورت خرابی سرور، رکورد A را با سرعت بیشتری تغییر دهید. برای انجام این کار از کنترل پنل رکورد‌های DNS استفاده کنید.
  • وب‌سایت‌های بزرگ به تعداد زیادی PoP نیاز دارند. اگر سرور‌هایی در 6 الی 7 مکان مختلف داشته باشید، CDN شما فرقی با یک CDN پولی نخواهد داشت.
  • گاهی‌اوقات، ارا‌ئه‌دهنده هاست به شما اجازه استفاده از سرور‌های اجاره‌ای برای CDN را نمی‌دهد. اگر می‌خواهید یک CDN را ایجاد کنید، برای جلوگیری از مواجه با این مشکل بهتر است شرایط و ضوابط ارا‌ئه‌دهنده مورد‌نظرتان را به‌دقت مطالعه کنید.
  • در زمان ساخت cdn شخصی،‌ بخش submarine cable را به‌دقت مطالعه کنید تا متوجه شوید که چطور قاره‌ها را به هم متصل کنید.
  • برای اینکه نزدیک‌ترین مناطق به PoP خود را شناسایی کنید، بهتر است سرور‌های خود را از مناطق مختلف پینگ کنید.

سخن پایانی

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

همچنین باید به جزئیات فنی مانند نصب گواهی‌های SSL و پیکربندی Nginx به‌عنوان سرور پروکسی کش نیز توجه داشته باشیم. با انجام این مراحل، در کمترین زمان ممکن می‌توانید CDN شخصی خود را بسازید و از آن استفاده کنید.

5/5 - (1 امتیاز)
دیدن نظرات
small

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

نه − 9 =

عضویت در خبرنامه مبین هاست
مطالب کدام دسته‌بندی‌ها برای شما جذاب‌تر است؟

آنچه در مقاله می‌خوانید

مقالات مرتبط
فریمورک Django
آموزش برنامه نویسی

همه چیز درباره فریمورک Django و نحوه استفاده از آن

فریم ورک Django یک ابزار متن‌باز بر پایه زبان برنامه‌نویسی پایتون است که از آن برای ساخت انواع وب‌سایت‌ها و پلتفرم‌های پیچیده استفاده می‌شود. این

خدمات مبین هاست