پرو ہوسٹر > بلاگ > انتظامیہ > اپنا CDN بنانا اور ترتیب دینا

اپنا CDN بنانا اور ترتیب دینا

مواد کی ترسیل کے نیٹ ورکس (CDNs) کا استعمال ویب سائٹس اور ایپلیکیشنز میں بنیادی طور پر جامد عناصر کی لوڈنگ کو تیز کرنے کے لیے کیا جاتا ہے۔ یہ مختلف جغرافیائی خطوں میں واقع CDN سرورز پر فائلوں کی کیشنگ کی وجہ سے ہوتا ہے۔ CDN کے ذریعے ڈیٹا کی درخواست کرنے سے، صارف اسے قریبی سرور سے وصول کرتا ہے۔

تمام مواد کی ترسیل کے نیٹ ورکس کے آپریشن اور فعالیت کا اصول تقریباً ایک جیسا ہے۔ فائل ڈاؤن لوڈ کرنے کی درخواست موصول ہونے کے بعد، CDN سرور اسے اصل سرور سے ایک بار لیتا ہے اور اسے صارف کو دیتا ہے، اسی وقت اسے مخصوص مدت کے لیے کیش کرتا ہے۔ تمام بعد کی درخواستوں کا جواب کیشے سے دیا جاتا ہے۔ تمام CDNs کے پاس فائلوں کو پہلے سے لوڈ کرنے، کیشے کو صاف کرنے، میعاد ختم ہونے کی تاریخ سیٹ کرنے اور بہت کچھ کرنے کے اختیارات ہوتے ہیں۔

ایسا ہوتا ہے کہ، کسی نہ کسی وجہ سے، آپ کو اپنے مواد کی ترسیل کے نیٹ ورک کو منظم کرنے کی ضرورت ہے، اور پھر - اگلی موٹر سائیکل کو اسمبل کرنے کی ہدایات ہمارے لیے مددگار ثابت ہوں۔

اپنا CDN بنانا اور ترتیب دینا
ماخذ: انفوگرافک ویکٹر pikisuperstar - www.freepik.com کے ذریعہ بنایا گیا ہے۔

جب آپ کو اپنے CDN کی ضرورت ہو۔

ان معاملات پر غور کریں جہاں آپ کا اپنا CDN چلانا معنی خیز ہے:

  • جب پیسے بچانے کی خواہش ہو، اور اخراجات چلانے کے باوجود سستے CDNs جیسے استعمال کرتے وقت بنی سی ڈی این ماہانہ کئی سو ڈالر کی رقم
  • اگر ہم سرور اور چینل کے پڑوسیوں کے بغیر مستقل کیش یا کیش حاصل کرنا چاہتے ہیں۔
  • CDN سروسز کے پاس آپ کے مطلوبہ علاقے میں موجودگی کے پوائنٹس نہیں ہیں۔
  • کوئی خاص مواد کی ترسیل کی ترتیبات درکار ہیں۔
  • ہم پروڈکشن سرور کو صارفین کے قریب رکھ کر متحرک مواد کی ترسیل کو تیز کرنا چاہتے ہیں۔
  • اس بات کا خدشہ ہے کہ فریق ثالث سی ڈی این سروس غیر قانونی طور پر صارف کے رویے (ہیلو نان جی ڈی پی آر کے مطابق خدمات) کے بارے میں معلومات اکٹھا یا استعمال کر سکتی ہے یا دیگر غیر قانونی سرگرمیوں میں ملوث ہو سکتی ہے۔

زیادہ تر دیگر معاملات میں، موجودہ تیار شدہ حل استعمال کرنا زیادہ مناسب ہے۔

آپ کو شروع کرنے کی کیا ضرورت ہے۔

یہ بہت اچھا ہے اگر آپ کا اپنا خود مختار نظام (AS) ہے۔ اس کے ساتھ، آپ ایک ہی IP کو کئی سرورز کو تفویض کر سکتے ہیں اور اس ہدایت کے مطابق نیٹ ورک کی سطح پر، صارفین کو قریب ترین تک پہنچاتا ہے۔ یہ کہنے کے قابل ہے کہ /24 ایڈریس بلاک کے ساتھ بھی، مواد کی ترسیل کا نیٹ ورک بنانا ممکن ہے۔ کچھ سرور فراہم کرنے والے آپ کو ان کے لیے دستیاب تمام خطوں میں استعمال کے لیے اعلان کرنے کی اجازت دیتے ہیں۔

اگر آپ IP پتوں کے بلاک کے خوش مالک نہیں ہیں، تو ایک سادہ سی ڈی این چلانے کے لیے آپ کو ضرورت ہو گی:

  • ڈومین کا نام یا ذیلی ڈومین
  • مختلف علاقوں میں کم از کم دو سرورز۔ سرور یا تو سرشار یا مجازی ہوسکتا ہے۔
  • geoDNS ٹول۔ اس کے ساتھ، صارف، ڈومین کو ایڈریس کرنے کے بعد، قریبی سرور پر بھیج دیا جائے گا۔

ڈومین رجسٹر کریں اور سرور آرڈر کریں۔

ڈومین رجسٹریشن کے ساتھ، سب کچھ آسان ہے - ہم کسی بھی زون میں کسی بھی رجسٹرار کے ساتھ رجسٹر ہوتے ہیں۔ آپ CDN کے لیے ذیلی ڈومین بھی استعمال کر سکتے ہیں، مثال کے طور پر کچھ ایسا cdn.domainname.com. دراصل، ہماری مثال میں، ہم ایسا ہی کریں گے۔

جہاں تک سرورز کو آرڈر کرنے کا تعلق ہے، انہیں ان خطوں اور ممالک میں کرایہ پر لینا چاہیے جہاں آپ کے صارف سامعین موجود ہیں۔ اگر پروجیکٹ بین البراعظمی ہے، تو ہوسٹنگ فراہم کرنے والوں کا انتخاب کرنا آسان ہے جو پوری دنیا میں ایک ساتھ سرور پیش کرتے ہیں۔ مثالیں: OVH, لیز ویب и 100 ٹی بی - سرشار سرورز کے لیے، مصنف и ڈیجیٹل اوسن - ورچوئل کلاؤڈ کے لیے*۔

اپنے نجی CDN کے لیے، ہم مختلف براعظموں پر 3 ورچوئل سرورز کا آرڈر دیں گے۔ پر مصنف کے لیے سرور پر $5/ماہ ہم حاصل کریں گے 25GB SSD مقامات اور 1TB ٹریفک. انسٹال کرتے وقت، تازہ ترین Debian منتخب کریں۔ ہمارے سرورز:

اپنا CDN بنانا اور ترتیب دینا فرینکفرٹ, ip: 199.247.18.199

اپنا CDN بنانا اور ترتیب دینا شکاگو, ip: 149.28.121.123

اپنا CDN بنانا اور ترتیب دینا سنگاپور, ip: 157.230.240.216

* Vultr اور DigitalOcean ان صارفین کو $100 کریڈٹ دینے کا وعدہ کرتے ہیں جو ادائیگی کا طریقہ شامل کرنے کے فوراً بعد آرٹیکل میں لنکس کے ذریعے اندراج کرتے ہیں۔ مصنف کو اس سے ایک چھوٹی سی داد بھی ملتی ہے، جو اب اس کے لیے بہت اہم ہے۔ براہ کرم سمجھنا۔

geoDNS ترتیب دینا

ڈومین یا CDN ذیلی ڈومین تک رسائی کرتے وقت صارف کو مطلوبہ (قریب ترین) سرور کی طرف لے جانے کے لیے، ہمیں geoDNS فنکشن کے ساتھ DNS سرور کی ضرورت ہے۔

geoDNS کا اصول اور عمل درج ذیل ہے:

  1. اس کلائنٹ کے IP کی وضاحت کرتا ہے جس نے DNS درخواست بھیجی ہے، یا ریکسریو DNS سرور کا IP جو کلائنٹ کی درخواست پر کارروائی کرتے وقت استعمال کیا جاتا ہے۔ اس طرح کے تکراری سرورز عام طور پر فراہم کنندگان کے DNS-s ہوتے ہیں۔
  2. کلائنٹ کا IP اس کے ملک یا علاقے کو پہچانتا ہے۔ اس کے لیے، GeoIP ڈیٹا بیس استعمال کیے جاتے ہیں، جن میں سے آج بہت زیادہ ہیں۔ اچھے ہیں۔ مفت اختیارات.
  3. کلائنٹ کے مقام پر منحصر ہے، اسے قریب ترین CDN سرور کا IP پتہ فراہم کرتا ہے۔

geoDNS فنکشن والا DNS سرور ہو سکتا ہے۔ اپنے آپ کو جمع کرو، لیکن یہ بہتر ہے کہ دنیا بھر کے DNS سرورز کے نیٹ ورک کے ساتھ تیار حل استعمال کریں۔ کوئی بھی ڈھبے سے:

  • CloudDNS سے $9.95/ماہ, GeoDNS ٹیرف، پہلے سے طے شدہ طور پر ایک DNS فیل اوور ہوتا ہے۔
  • زیلور سے $25/ماہ، DNS فیل اوور فعال ہے۔
  • ایمیزون روٹ 53 سے $35/ماہ خالص 50M جیو درخواستوں کے لیے۔ DNS فیل اوور کا بل الگ سے لگایا جاتا ہے۔
  • DNS کو آسان بنا دیا گیا۔ سے $125/ماہ، 10 DNS فیل اوور ہیں۔
  • CloudFlare کے"جیو اسٹیئرنگ" فیچر انٹرپرائز پلانز میں دستیاب ہے۔

geoDNS آرڈر کرتے وقت، آپ کو ٹیرف میں شامل درخواستوں کی تعداد پر توجہ دینی چاہیے اور یہ بات ذہن میں رکھیں کہ ڈومین کی درخواستوں کی اصل تعداد توقعات سے کئی گنا زیادہ ہو سکتی ہے۔ لاکھوں مکڑیاں، سکینر، سپیمرز اور دیگر بری روحیں انتھک کام کرتی ہیں۔

تقریباً تمام DNS سروسز میں CDN - DNS فیل اوور بنانے کے لیے ایک ناگزیر سروس شامل ہے۔ اس کی مدد سے، آپ اپنے سرورز کے آپریشن کی مانیٹرنگ ترتیب دے سکتے ہیں اور، زندگی کی علامات کی عدم موجودگی میں، DNS جوابات میں بیک اپ والے سرور کے ایڈریس کو خود بخود تبدیل کر سکتے ہیں۔

ہمارا CDN بنانے کے لیے، ہم استعمال کریں گے۔ کلوڈ این ایس، جیو ڈی این ایس ٹیرف۔

آئیے آپ کے ڈومین کی وضاحت کرتے ہوئے آپ کے ذاتی اکاؤنٹ میں ایک نیا DNS زون شامل کریں۔ اگر ہم ذیلی ڈومین پر CDN بنا رہے ہیں، اور مرکزی ڈومین پہلے سے استعمال میں ہے، تو زون کو شامل کرنے کے فوراً بعد، موجودہ کام کرنے والے DNS ریکارڈز کو شامل کرنا نہ بھولیں۔ اگلا مرحلہ CDN ڈومین / ذیلی ڈومین کے لیے کئی A-ریکارڈ بنانا ہے، جن میں سے ہر ایک کا اطلاق اس خطے پر کیا جائے گا جسے ہم نے بیان کیا ہے۔ آپ براعظموں یا ممالک کو خطوں کے طور پر بتا سکتے ہیں، امریکہ اور کینیڈا کے لیے ذیلی علاقے دستیاب ہیں۔

ہمارے معاملے میں، CDN کو ذیلی ڈومین پر اٹھایا جائے گا۔ cdn.sayt.in. ایک زون شامل کرکے sayt.inسب ڈومین کے لیے پہلا A-ریکارڈ بنائیں اور پورے شمالی امریکہ کو شکاگو میں سرور کی طرف اشارہ کریں:

اپنا CDN بنانا اور ترتیب دینا
آئیے پہلے سے طے شدہ علاقوں کے لیے ایک اندراج بنانا یاد رکھتے ہوئے دوسرے علاقوں کے لیے کارروائی کو دہراتے ہیں۔ آخر میں کیا ہوتا ہے یہ ہے:

اپنا CDN بنانا اور ترتیب دینا

اسکرین شاٹ میں آخری ڈیفالٹ اندراج کا مطلب یہ ہے کہ تمام غیر متعین علاقے (اور یہ یورپ، افریقہ، سیٹلائٹ انٹرنیٹ صارفین وغیرہ ہیں) فرینکفرٹ کے سرور کو بھیجے جائیں گے۔

یہ بنیادی DNS سیٹ اپ کو مکمل کرتا ہے۔ ڈومین رجسٹرار کی ویب سائٹ پر جانا اور موجودہ ڈومین NSs کو CloudDNS کے جاری کردہ ڈومین سے تبدیل کرنا باقی ہے۔ اور جب NSs کو اپ ڈیٹ کیا جائے گا، ہم سرور تیار کریں گے۔

SSL سرٹیفکیٹ کی تنصیب

ہمارا CDN HTTPS پر کام کرے گا، لہذا اگر آپ کے پاس پہلے سے ہی کسی ڈومین یا ذیلی ڈومین کے لیے SSL سرٹیفکیٹ ہیں، تو انہیں تمام سرورز پر اپ لوڈ کریں، مثال کے طور پر، ڈائریکٹری میں /etc/ssl/yourdomain/

اگر کوئی سرٹیفکیٹ نہیں ہیں، تو آپ Let's Encrypt سے مفت حاصل کر سکتے ہیں۔ اس کے لیے کامل ACME شیل اسکرپٹ. کلائنٹ آسان اور ترتیب دینے میں آسان ہے، اور سب سے اہم بات یہ ہے کہ یہ آپ کو clouDNS API کے ذریعے DNS کے ذریعے ڈومین/سب ڈومین کی توثیق کرنے کی اجازت دیتا ہے۔

ہم acme.sh کو صرف ایک سرور پر انسٹال کریں گے - یورپی 199.247.18.199، جس سے سرٹیفکیٹس کو باقی تمام سرورز پر کاپی کیا جائے گا۔ انسٹال کرنے کے لیے، چلائیں:

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

اسکرپٹ کی تنصیب کے دوران، ہماری شرکت کے بغیر سرٹیفکیٹس کی مزید تجدید کے لیے ایک CRON جاب بنایا جائے گا۔

سرٹیفکیٹ جاری کرتے وقت، API کا استعمال کرتے ہوئے DNS کا استعمال کرتے ہوئے ڈومین کو چیک کیا جائے گا، لہذا Reseller API مینو میں clouDNS ذاتی اکاؤنٹ میں، آپ کو ایک نیا صارف 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 configs کو دوبارہ لوڈ کرنے کی غلطی پر توجہ نہیں دیتے ہیں - سرٹیفکیٹس کو اپ ڈیٹ کرتے وقت یہ مکمل طور پر کنفیگر شدہ سرور پر نہیں ہوگا۔

ہم نے صرف 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;
    }
  }
}

ترتیب میں ترمیم کریں:

  • max_size - کیشے کا سائز، دستیاب ڈسک کی جگہ سے زیادہ نہ ہو۔
  • غیر فعال - ذخیرہ شدہ ڈیٹا کا ذخیرہ کرنے کا وقت جس تک کسی نے رسائی حاصل نہیں کی۔
  • ssl_certificate и ssl_certificate_key - ایس ایس ایل سرٹیفکیٹ اور کلیدی فائلوں کے راستے
  • proxy_cache_valid - کیش شدہ ڈیٹا کا ذخیرہ کرنے کا وقت
  • proxy_pass - اصل سرور کا پتہ جس سے CDN فائلوں کی کیشنگ کے لیے درخواست کرے گا۔ ہماری مثال میں، یہ sayt.in

جیسا کہ آپ دیکھ سکتے ہیں، سب کچھ آسان ہے. ہدایات کی مماثلت کی وجہ سے صرف کیشنگ ٹائم سیٹ کرنے میں دشواری پیدا ہو سکتی ہے۔ غیر فعال и proxy_cache_valid. آئیے اپنی مثال کے ساتھ ان کا تجزیہ کریں۔ یہاں ہے جب کیا ہوتا ہے۔ غیر فعال = 7 ڈی и proxy_cache_valid 90d:

  • اگر درخواست 7 دنوں کے اندر دہرائی نہیں جاتی ہے، تو اس مدت کے بعد ڈیٹا کو کیش سے حذف کر دیا جائے گا۔
  • اگر درخواست کو کم از کم ہر 7 دنوں میں ایک بار دہرایا جاتا ہے، تو کیش میں موجود ڈیٹا کو 90 دن کے بعد متروک سمجھا جائے گا اور Nginx اسے اصل سرور سے لے کر اگلی درخواست کے ساتھ اپ ڈیٹ کر دے گا۔

ترمیم کرنا مکمل ہو گیا۔ nginx.conf، کنفیگریشن کو دوبارہ لوڈ کریں:

root@cdn:~# service nginx reload

ہمارا CDN تیار ہے۔ $15/ماہ کے لیے۔ ہمیں تین براعظموں پر موجودگی کے پوائنٹس اور ٹریفک کے 3 TB موصول ہوئے: ہر مقام پر 1 TB۔

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 فیل اوور کو کنفیگر کرنے کی سفارش کی جاتی ہے، جو سرور کے خراب ہونے کی صورت میں A ریکارڈ کو تیزی سے تبدیل کرنے میں مدد کرتا ہے۔ یہ ڈومین کے کنٹرول پینل DNS ریکارڈز میں کیا جاتا ہے۔
  • بلاشبہ وسیع جغرافیائی کوریج والی سائٹس کو بڑی تعداد میں CDNs کی ضرورت ہوتی ہے، لیکن آئیے جنونی نہ ہوں۔ زیادہ امکان ہے کہ صارف ادا شدہ CDN کے مقابلے میں کوئی خاص فرق محسوس نہیں کرے گا اگر آپ 6-7 مقامات پر سرور رکھتے ہیں: یورپ، شمالی امریکہ (مشرق)، شمالی امریکہ (مغرب)، سنگاپور، آسٹریلیا، ہانگ کانگ یا جاپان
  • بعض اوقات میزبان CDN مقاصد کے لیے کرائے کے سرورز کے استعمال کی اجازت نہیں دیتے۔ لہذا، اگر آپ اچانک مواد کی ترسیل کے نیٹ ورک کو بطور سروس تعینات کرنے کا فیصلہ کرتے ہیں، تو پہلے سے کسی خاص ہوسٹنگ فراہم کنندہ کے قواعد کو پڑھنا نہ بھولیں۔
  • دریافت کریں۔ پانی کے اندر مواصلات کا نقشہاس بات کی نمائندگی کرنے کے لیے کہ براعظم کیسے جڑے ہوئے ہیں اور مواد کی ترسیل کا نیٹ ورک بناتے وقت اس کو مدنظر رکھیں
  • چیک کرنے کی کوشش کریں۔ مختلف جگہوں سے آوازیں آتی ہیں۔ آپ کے سرورز پر۔ اس طرح آپ CDN پوائنٹس کے قریب ترین علاقوں کو دیکھ سکتے ہیں اور GeoDNS کو زیادہ درست طریقے سے ترتیب دے سکتے ہیں۔
  • کاموں پر منحصر ہے، مخصوص کیشنگ کی ضروریات اور سرور پر بوجھ کو مدنظر رکھتے ہوئے Nginx کو ٹھیک کرنا مفید ہوگا۔ Nginx کیشے کے بارے میں مضامین نے اس میں میری بہت مدد کی۔ یہاں اور بھاری بوجھ کے تحت کام کی رفتار: یہاں и یہاں

ماخذ: www.habr.com